Structured analysis and design technique (SADT)



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

Structured analysis and design technique (SADT)



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

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

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

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

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

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

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

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

 

Class-responsibility-collaboration

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

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

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

 

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

 

Unified Modeling Language (UML)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Последнее изменение этой страницы: 2016-04-07; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.210.184.142 (0.008 с.)