- •Тема 1. Введение. Основы методологии проектирования информационных систем 5
- •Жизненный цикл программного обеспечения
- •Модели жизненного цикла программного обеспечения
- •Макетирование
- •Спиральная модель жизненного цикла
- •Компонентно-ориентированная модель
- •Тема 2. Структурный анализ и проектирование Определение структурного анализа
- •Средства структурного анализа
- •Моделирование потоков данных
- •Контекстная диаграмма
- •Построение иерархии диаграмм потоков данных
- •Методология функционально стоимостного анализа
- •Методология функционального моделирования sadt (Structured Analysis and Design Technique)
- •Состав функциональной модели sadt
- •Иерархия диаграмм
- •Словарь данных
- •Тема 3. Построение информационной модели системы. Проектирование баз данных Диаграммы сущность-связь (erd)
- •Сущности, отношения и связи в нотации Чена
- •Типы связей в нотации Чена
- •Ассоциативная связь
- •Диаграммы атрибутов в классической модели Чена
- •Диаграмма категоризации
- •Нотация Баркера. Модель сущность- связь в нотации Баркера
- •Методология idef1x
- •Тема 4. Методика построения информационной модели данных (модели «сущность-связь»)
- •Идентификация отношений между сущностями
- •Разрешение неспецифических отношений
- •Использование средств и техники структурного системного анализа
- •Основные виды работ, рекомендуемые при построении логической и физической моделей программной системы
- •Подход Мартина (ie–методология)
- •Тема 5. Методология rad (Rapid Application Development)
- •Основные принципы методологии rad
- •Состав, структура и функциональные особенности case-средств
- •Поддержка графических моделей
- •Требования к современному диаграммеру
- •Тема 6. Структурное тестирование программного обеспечения Основные понятия и принципы тестирования программного обеспечения
- •Особенности тестирования белого ящика
- •Способ тестирования базового пути
- •Потоковый граф
- •Цикломатическая сложность
- •Шаги способа тестирования базового пути
- •Способы тестирования условий
- •Тестирование ветвей и операторов отношения
- •Способ тестирования потоков данных
- •Тестирование циклов
- •Тема 7. Функциональное тестирование программного обеспечения Особенности тестирования черного ящика
- •Способы разбиения на эквивалентности
- •Способ анализа граничных значений
- •Способ диаграмм причин–следствий
- •Тема 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование итераций
- •Восходящее тестирование интеграции
- •Тестирование правильности
- •Системное тестирование
Поддержка графических моделей
Case-пакеты всегда являются графически ориентированными пакетами. Это означает, что программы представляются схематическими проектами и формами, которые всегда значительно проще в использовании, чем текстовое описание.
Для представления программ применяются структурные диаграммы разных типов, которые могут использоваться в качестве документации по проекту.
Диаграммы, применяющиеся на этапе проектирования, как правило, описывают отношения между модулями и внутримодульную структуру. Создание диаграммы осуществляется с помощью диаграммеров, являющихся сервисными средствами на этапах анализа требований и проектирования.
Требования к современному диаграммеру
Возможность создания иерархически связанных диаграмм, на которых взаимодействуют графические и текстовые объекты.
Создание и редактирование объектов в любом месте диаграммы.
Создание, перемещение и выравнивание двух объектов, изменение размеров объектов и масштабирование.
Сохранение связи между объектами при перемещении и изменении размеров.
Автоматический контроль ошибок.
Важность автоматического контроля ошибок на этапах анализа требований и проектирования определяется тем, что на ранних этапах жизненного цикла ошибки можно обнаруживать автоматически. Поэтому case-пакет должен обеспечивать автоматическую верификацию и контроль проекта на полноту, и состоятельность на ранних этапах жизненного цикла.
На этапе сопровождения программного обеспечения обнаружить ошибки в проектировании во много раз труднее. Поэтому в case-пакете диаграммеры и верификаторы выполняют следующие типы контроля:
контроль синтаксиса диаграмм и типов их элементов. Такой контроль осуществляется при вводе и редактировании элементов диаграмм.
Контроль полноты и состоятельности диаграммы, то есть все элементы диаграммы должны быть идентифицированы и отражены в репазитарии. При анализе репазитария должны выявляться циклические определения, эквивалентные определения и неопределенные объекты.
Контроль декомпозиции функций.
Сквозной контроль диаграмм на состоятельность по уровням, то есть вертикальное и горизонтальное балансирование диаграмм.
При вертикальном балансировании диаграмм одного типа выявляются несбалансированные потоки данных между детализируемой и детализирующей диаграммами.
Горизонтальное балансирование определяет некорректности между несколькими видами диаграмм одного уровня. Например, DFD и ERD. При этом может, например, контролироваться соответствие хранилищ данных и информационных потоков на DFD сущностям и их атрибутам на ERD.
Вопросы для самоконтроля по теме 5:
Перечислите основные особенности методологии RAD
Перечислите и опишите фазы жизненного цикла программного обеспечения в соответствии с методологией RAD
Перечислите основные принципы методологии RAD
Опишите состав и структуру современных case-средств
Охарактеризуйте функциональные особенности case-средств.
Тема 6. Структурное тестирование программного обеспечения Основные понятия и принципы тестирования программного обеспечения
Тестирование – это процесс выполнения программы с целью обнаружения ошибок.
Шаги процесса задаются тестами. Каждый тест определяет:
свой набор исходных данных и условий для запуска программы;
набор ожидаемых результатов и работы программы.
Другое название теста – тестовый вариант. Полную проверку программы гарантирует только исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов. На практике исчерпывающее тестирование практически никогда не выполняется из-за ресурсных ограничений, прежде всего ограничений по времени.
Хорошим считается тестовый вариант с высокой вероятностью обнаружения еще нераскрытой ошибки. Успешным называется тест, который обнаруживает до сих пор не найденную ошибку. Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.
Тестирование обеспечивает:
обнаружение ошибок;
демонстрацию соответствия функций программы ее назначению;
демонстрацию реализации требований характеристикам программы;
отображение надежности, как индикатора качества программы.
Тестирование не может показать отсутствие дефектов, оно может показать только присутствие дефектов.
Рисунок 12 – Информационные потоки процесса тестирования
На входе процесса тестирования 3 потока: текст программы, исходные данные, ожидаемые результаты.
После выполнения тестов полученные результаты оцениваются. Это значит, что результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение и фиксируется ошибка, начинается отладка. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Процесс отладки непредсказуем по времени. На поиск места возникновения ошибки и исправление может потребоваться час, день или месяц. Неопределенность в отладке приводит к большим трудностям в планировании действий.
После сброса и оценивания результата тестирования начинается оценка качества и надежности программного обеспечения. Если регулярно встречаются серьезные ошибки, требующие значительных проектных изменений, то качество и надежность программного обеспечения становятся подозрительными и констатируется необходимость усиления тестирования.
С другой стороны, если функции программного обеспечения реализованы правильно, а обнаруживаемые ошибки легко исправляются, может быть сделан один из двух выводов: либо качество и надежность программного обеспечения полностью удовлетворительны, либо используемые тесты неспособны обнаружить серьезных ошибок. В конечном счете, если тесты не обнаруживают ошибок, появляются сомнения в том, что тестовые варианты достаточно продуманы и что в программном обеспечении нет скрытых ошибок.
Такие ошибки будут, в конечном счете, обнаруживаться пользователями и корректироваться разработчиками на этапе сопровождения, когда стоимость исправления возрастет в 100 раз по сравнению с этапом разработки.
Результаты, накопленные в ходе тестирования, могут оцениваться и более формальным способом. Для этого используются модели надежности программного обеспечения, выполняющие прогноз надежности по реальным данным об интенсивности ошибок.
Существуют 2 основных принципа тестирования программ:
функциональное тестирование (тестирование черного ящика);
структурное тестирование (тестирование белого ящика).
При тестировании черного ящика известны функции программы и исследуется работа каждой функции на всей области определения.
Местом приложения тестов черного ящика является интерфейс программного обеспечения.
Рисунок 13 –Схема тестирования черного ящика
Тесты черного ящика демонстрируют:
как выполняются функции программ;
как принимаются исходные данные;
как вырабатываются результаты;
как сохраняется целостность внешней информации.
При тестировании черного ящика рассматриваются системные характеристики программ, но игнорируется их внутренняя логическая структура.
Исчерпывающее тестирование черного ящика также, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется тестовых вариантов.
Необходимо также отметить, что тестирование черного ящика не реагирует на многие особенности программных ошибок.
При тестировании белого ящика известна внутренняя структура программы, а исследуются внутренние элементы программы и связи между ними.
Рисунок 14 –Схема тестирования белого ящика
При тестировании белого ящика объектом тестирования является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. При этом обычно анализируются управляющие связи элементов, реже информационные.
Тестирование по принципу белого ящика характеризуется степенью, в которой тесты выполняют логику, т.е. исходный текст программы.