Structured analysis and design technique (SADT)

Диаграмма функционального моделирования - инструмент разработки функциональных спецификаций в виде диаграмм, фрагментов текста и глоссария, связанных перекрестными ссылками. В состав диаграммы входят:

- блоки, изображающие активность моделируемой системы; и

- дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между ними.

Место соединения дуги с блоком определяет тип интерфейса:

- управляющая информация входит в блок сверху;

- входная информация, подвергающаяся обработке, показывается с левой стороны блока;

- выходная информация показывается с правой стороны;

- механизм, осуществляющий операцию, представляется дугой, входящей в блок снизу.

 

Class-responsibility-collaboration

Карты класс-ответственность-кооперация - методология объектно-ориентированного проектирования, предназначенная для описания классов и оперирующая понятиями:

- ответственность - суть - высокоуровневое описание функций, которые выполняет класс;

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

 

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

 

Unified Modeling Language (UML)

Универсальный язык моделирования - язык программирования, предназначенный для определения, представления, проектирования и документирования (программных) систем различной природы.

Основными составляющими языка UML являются элементы, связи, механизмы расширения и диаграммы.
Тестирование и отладка ПС. Структурное и функциональное тестирования ПС. Организация процесса тестирования.

Тестирование - процесс выполнения программы с целью обнаружения ошибок.

Шаги процесса задаются тестами (тестовыми вариантами). Каждый тест определяет:

• свой набор исходных данных и условий для запуска программы;

• набор ожидаемых результатов работы программы.

Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов. Увы, но исчерпывающее тестирование во многих случаях остается только мечтой — срабатывают ресурсные ограничения (прежде всего, ограничения по времени).

• Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки.

• Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Важны ответы на вопросы:

• Что может тестирование? Тестирование обеспечивает:

– обнаружение ошибок;

– демонстрацию соответствия функций программы ее назначению;

– демонстрацию реализации требований к характеристикам программы;

– отображение надежности как индикатора качества программы.

• Чего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов)*.

• *Важно помнить это при проведении тестирования.

Информационные потоки процесса тестирования.

На входе процесса тестирования три потока:

– текст программы;

– исходные данные для запуска программы;

– ожидаемые результаты.

Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами.

Когда обнаруживается несовпадение, фиксируется ошибка - начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц. Неопределенность в отладке приводит к большим трудностям в планировании действий.

После сбора и оценивания результатов тестирования начинается анализ качества и надежности ПО.

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

С другой стороны, если функции ПО реализованы правильно, а обнаруженные ошибки легко исправляются, может быть сделан один из двух выводов:

– качество и надежность ПО удовлетворительны;

– тесты не способны обнаруживать серьезные ошибки.

В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

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

Существуют 2 принципа тестирования программы:

– функциональное тестирование (тестирование «черного ящика»);

– структурное тестирование (тестирование «белого ящика»).