Файл: ТРПО-лекции3.pdf

12.04.2011

Computer-Aided Software/System Engineering (CASE)

Достоинства и преимущества case-систем.

1.Единый графический язык. Это значит, что в графическом виде на одном из стандартов все рисуется.

2.Единая база данных проекта (репозиторий). Репозиторий может сохранять свыше 100 типов проекта, это описание данных, модели данных, исходные коды, меню. Т.е. все информационные объектов проекта.

3.Интеграция средств. Могут интегрироваться разные инструменты – БД, программные пакеты и т.д. И на единой платформе они могут взаимодействовать.

4.Поддержка коллективной разработки и управления проектами. Case-технологии поддерживает групповую работу, работу сети, обмен информацией, контроль работы каждого из участников, осуществлять контроль за работой.

5.Макетирование. Case-система дает возможность быстро построить макеты для будущей системы, показать заказчику, оценить и осуществить необходимые изменения.

6.Генерация документация. Автоматически генерируется документация в нужных стандартах, отражающая ход разработки на данный момент.

7.Верификация проекта. Case-технология обеспечивает автономную верификации проекта на ранних стадиях разработки. На этапе проектирования найти ошибку – это в 100 раз дешевле, чем при внедрении.

8.Автоматическая генерация объектного кода. Case-системы делают это автоматически в различные языки программирования. Но на 85-90%. 100% невозможно.

9.Сопровождение и реинжениринг. Это значит, что после построения проекта в коллективе, после проверки проекта я нашел ошибки. И тогда после изменения кода делается реинжениринг, т.е. автоматически применяются все изменения в проекте (переделываются диаграммки и т.п.).

Какими критериями следует руководствоваться при выборе CASE-системы? С первого-то года никакая система не дает никаких положительных эффектов.

1.Выбор зависит от класса решаемых задач. Системы реального времени, коммерческие системы, системы связанные с САПР и т.д. – это все разные классы.

2.Поддержка полного жизненного цикла система. Поддерживает ли case-система полный жизненный цикл и ее модификацию? Есть case-системы, которые поддерживают только один уровень (проектирование, кодирование, тестирование, реинжениринг). Каждый из перечисленных блоков стоит отдельных денег. Если предстоит крупную систему (и не одну), то стоит закупить систему с полным жизненным циклом.

3.Обеспечение целостности проекта и контроля за его состоянием. Поддерживает ли версионность, верификации.

4.Независимость от программно-аппаратной платформы и выбранных СУБД.

5.Открытая архитектура. Если case-система обеспечина этим, то это значит, можно подключать другие компиляторы, подключение новых СУБД и т.д.

6.Качество технической поддержке в той стране, где идет работа, стоимость приобретения и поддержки новых версий, опыт успешного использования этой case-системы в данной стране.

7.Простота освоения и использования. Если ее освоить трудно, а квалифицированных кадров немного – то стоит подумать над покупкой более простой.

Пилотный проект – это проект на маленьком релизе для того, чтобы попробовать, как подходит эта система для реализации конкретных поставленных задач. Как правило, большие проекты (IBM и подобные), пробные релизы предоставляют бесплатно.

Критерии классификации CASE-систем.

По категориям – по следующим признакам:

oИнтегрируемость – оценивается степень интегрированности case-системы с другими средами (средствами) разработки: СУБД, средами визуального проектирования и кодирования, операционными системами.

o Применяемые методологии организации данных (реляционные, объектно ориентированные модели)

oДоступным платформам – имеется в виду и техническим в т.ч.

По типам – она совпадает с компонентным составом case-систем.

По типам:

1.Upper CASE – это case-системы верхнего уровня, средства анализа предметной области. К ним относятся Design/IDEF0, BPWin (бизнес-процесс под windows – позволяет спроектировать бизнес процесс на самом верхнем уровне). Эти системы используются для не очень больших задач.

2.Middle CASE - case-системы среднего уровня. Включают средства анализа и проектирования. К ним относятся

2.1CASE-Аналитик – позволяла в нотации Буча или Рамбо осуществить проектирование системы

2.2Design/2000

2.3Silveran

2.4PRO-IV

3.Case-системы, которые позволяют спроектировать схемы БД и сгенерировать сами БД

(SQL). К ним относятся: ERWin, S-Designer (oracle)

4.CASE-системы, включающие средства разработки приложений. Это языки четвертого поколения (4GL). 4GL – это среды визуального программирования. Это Delphi и прочие.

<<часть (на 10 минут лекций) пропустил. Следует восстановить>>

Тестирование ПО

См. методичку «тестирование ПО».

Тестирование было искусством, каждый тестировал так, как ему казалось правильно. Сценарии тестирования были засекречены. Но, как это всегда бывает, времена меняются.

Лабораторную следует делать в среде автоматического тестирования.

Карл Поупер – философ: «что нужно сделать, чтобы проверить, что разрабатываемая теория верна». Все думали, что следует искать факты, подтверждающие теорию, а он искал факты, опровергающие.

Теоретически доказано, что невозможно оттестировать до конца ни одну, даже маленькую, программу. Можно говорить только о степени.

Майрс – первый теоретик, опубликовавший книгу «теория тестирования». Написал программу из 10 строк со 150 ошибками.

| «Формула оценки степени тестированности программы» - любимый вопрос.

| Ответ есть в методичке.

Этапы тестирования.

Они совпадают с этапами разработки:

1.Анализ предметной области, стадия планирования, создание спецификаций. На этом этапе планируется проект, выставляются предположительные высокоуровневые требования. После этого вся информация передается независимому тестеровщику. Он оценивает риски (финансовые, технические, по квалификации сотрудников), реальность сроков, адекватность требований, совместимые требований. Выполнимые ли данные требования на данной технической платформе. Разумны ли они. Здесь могут приняться решения либо о модернизации, либо об ослаблении требований. Поддаются ли выставленные требования тестированию? Т.е. на этапе проектирования уже задаются методы и средства тестирования: что именно в первую очередь можно тестировать?

2.Стадия проектирования. Здесь идет разработка проекта, более формально описываются все спецификации. Проектируется дизайн пользовательского интерфейса и внутренняя структура программных модулей. Проектируется организация данных и тестируется выбор моделей организации данных. Технологии доступа к данным, модели организации данных. Оценивается правильность выбора технологий. Оценивается и тестируется возможность восстановления базы данных – будут использоваться ЦОДы, зеркальные сервера. Оценивается, полон ли проект – описываются все взаимосвязи, описываются степени реализации каждого модуля.

3.Тестирование на стадии кодировния. Тестировщики работают параллельно с кодировщиками. Сначала модуль тестирует сам разработчик. Используются методы визуальной инспекции за круглым столом. Используется белый (прозрачный) ящик. Тестируются там все условные переходы. Тестирование черного ящика (тестирование функциональности): задаются входные в него потоки, получаем выходные и сравниваем с эталоном, просчитанным теоретически или вычисленным другими ПО. Часто черный работает совместно с белым, особенно если есть разветвленный интерфейс на входе. Используют метод функциональных диаграмм.

Класс эквивалентности – это множество входных значений, каждое из которых имеет одинаковую вероятность обнаружения конкретного типа ошибок.

Как определяют класс эквивалентности? Оценивают правильные исходные данные и «неправильные». Правильные – это те, которые входят в область допустимых значений: «введите значение от 0 до 10».

Класс граничных значений – всегда проверяется: до границы, на границе и после границы. Наибольшее количество ошибок сходится именно вблизи границы. Это метод граничных

значений.

Метод предположений – используется интуиция программиста. Надо прикинуть, где возможна ошибка (болевая точка) в данном коде. Например, идет удаленный вызов. Надо проверить, что будет в случае обрыва канала связи.

Нагрузочное тестирование.

Регрессионное тестирование – выборочное перетестирование ПО или компонента с целью обнаружения, не появились ли новые ошибки при изменении кода.

Тестирование на дым – «огня нет, а дым остался», то есть след ошибки. Искали и нашли саму ошибку. А теперь остался «дым»: какая-то всплывающая подсказка осталась той, какая была до исправления. Ее надо подкорректировать.

Нагрузочное и предельное тестирование

Нагрузочное тестирование:

Например, идет обработка большого объема информация. При тестировании мы даем не только этот объем, но и сверх этой нагрузки. Вместо 3 файлов, даем 4 или 5. Обработает медленнее? Или не обработает вообще из-за каких-то переполнений в буфере или из-за исчерпания системных ресурсов (ОЗУ)?

Если объем оперативной памяти превышает или меньше того, при котором разработка была. Превышаем объем аппаратных ресурсов (напр, объем данных на жестком диске, ОЗУ, обрабатываемых данных), т.е. буфер, массив и т.п.

Предельное тестирование:

Это оценка возможности сисетмы при работе на пределах возможности, проверка выполнимости времени реакции системы.

Пример:

Приходит секретарша устраиваться на работу. Даю работу: напечатать такой-то объем инфомрации. Она справляется за 2 дня. Проверяю на предмет правильности – это нагрузочное.

А если дам тот же объем работы на 2 часа – это предельное тестирование.

Есть еще один момент.

Поскольку тестов много, они сложны, нет эталона (каждая система уникальна, свои задачи, свои особенности, свои подходы), то я как автор все равно могу немного автоматизировать. Например, на вход дается файл, на выходе получаю файл. Могу написать тест-программу, сравнивающую эти файлы.

Или, например, программа обращает матрицу. Как проверить правильность? Можно взять исходную матрицу, умножить на получившуюся – должна получиться единичная. Т.е. такие подбные приемы, позволяющие автоматизировать тестирование, желательно использовать. Генератор случайных чисел – следует проверить, дает ли он повторения в заданных рамках? Например, часто выдает повторения, которые не могут иметь место в реальной жизни.