
- •Оглавление
- •9. Тестирование программных продуктов …………………..263
- •10. Отладка программного обеспечения …………………..287
- •11.Составление программной документации …………………..300
- •Предисловие
- •Введение
- •1. Технология программирования. Основные понятия и подходы
- •1.1. Технология программирования и основные этапы ее развития
- •1.2. Проблемы разработки сложных программных систем
- •1.3. Блочно-иерархический подход к созданию сложных систем
- •1.4. Жизненный цикл и этапы разработки программного обеспечения
- •1.5. Эволюция моделей жизненного цикла программного обеспечения
- •1.6. Ускорение разработки программного обеспечения. Технология rad
- •1.7. Оценка качества процессов создания программного обеспечения
- •Контрольные вопросы
- •2. Приемы обеспечения технологичности программных продуктов
- •2.1. Понятие технологичности программного обеспечения
- •2.2. Модули и их свойства
- •2.3. Нисходящая и восходящая разработка программного обеспечения
- •2.5. Стиль оформления программы
- •2.6. Эффективность и технологичность
- •2.7. Программирование «с защитой от ошибок»
- •2.8. Сквозной структурный контроль
- •Контрольные вопросы и задания
- •3. Определение требований к программному обеспечению и исходных данных для его проектирования
- •3.1. Классификация программных продуктов по функциональному признаку
- •3.2. Основные эксплуатационные требования к программным продуктам
- •3.3. Предпроектные исследования предметной области
- •3.4. Разработка технического задания
- •1.Введение
- •2. Основание для разработки
- •3. Назначение
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •1. Введение
- •2. Основание для разработки
- •3. Назначение
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •3.5. Принципиальные решения начальных этапов проектирования
- •Контрольные вопросы и задания
- •4. Анализ требований и определение спецификаций программного обеспечения при структурном подходе
- •4.1. Спецификации программного обеспечения при структурном подходе
- •4.2. Диаграммы переходов состояний
- •4.3. Функциональные диаграммы
- •4.4. Диаграммы потоков данных
- •4.5. Структуры данных и диаграммы отношений компонентов данных
- •4.6. Математические модели задач, разработка или выбор методов решения
- •Контрольные вопросы и задания
- •5. Проектирование программного обеспечения при структурном подходе
- •5.1. Разработка структурной и функциональной схем
- •5.2. Использование метода пошаговой детализации для проектирования структуры программного обеспечения
- •5.3. Структурные карты Константайна
- •5.4. Проектирование структур данных
- •5.5. Проектирование программного обеспечения, основанное на декомпозиции данных
- •5.6. Case-технологии, основанные на структурных методологиях анализа и проектирования
- •Контрольные вопросы и задания
- •6. Анализ требований и определение спецификаций программного обеспечения при объектном подходе
- •6.2. Определение «вариантов использования»
- •Типичный ход событий (окончание)
- •Альтернатива
- •6.3. Построение концептуальной модели предметной области
- •6.4. Описание поведения. Системные события и операции
- •Контрольные вопросы и задания
- •7. Проектирование программного обеспечения при объектном подходе
- •7.1. Разработка структуры программного обеспечения при объектном подходе
- •7.2. Определение отношений между объектами
- •7.3. Уточнение отношений классов
- •7.4. Проектирование классов
- •7.5. Компоновка программных компонентов
- •7.6. Проектирование размещения программных компонентов для распределенных программных систем
- •7.7. Особенность спиральной модели разработки. Реорганизация проекта
- •Контрольные вопросы и задания
- •8. Разработка пользовательских интерфейсов
- •8.1. Типы пользовательских интерфейсов и этапы их разработки
- •8.2. Психофизические особенности человека, связанные с восприятием, запоминанием и обработкой информации
- •8.3. Пользовательская и программная модели интерфейса
- •8.4. Классификации диалогов и общие принципы их разработки
- •8.5. Основные компоненты графических пользовательских интерфейсов
- •8.6. Реализация диалогов в графическом пользовательском интерфейсе
- •8.7. Пользовательские интерфейсы прямого манипулирования и их проектирование
- •8.8. Интеллектуальные элементы пользовательских интерфейсов
- •Контрольные вопросы и задания
- •9. Тестирование программных продуктов
- •9.1. Виды контроля качества разрабатываемого программного обеспечения
- •9.2. Ручной контроль программного обеспечения
- •9.3. Структурное тестирование
- •9.4. Функциональное тестирование
- •9.5. Тестирования модулей и комплексное тестирование
- •9.6. Оценочное тестирование
- •Контрольные вопросы и задания
- •10. Отладка программного обеспечения
- •10.1. Классификация ошибок
- •10.2. Методы отладки программного обеспечения
- •10.3. Методы и средства получения дополнительной информации
- •10.4. Общая методика отладки программного обеспечения
- •Контрольные вопросы
- •11. Составление программной документации
- •11.1. Виды программных документов
- •11.2. Пояснительная записка
Контрольные вопросы и задания
1.В чем сущность структурного подхода к программированию? Какие этапы охватывает данный подход?
2.Что понимают под термином «спецификации»? В чем сложность их уточнения? Назовите модели, используемые в качестве функциональных спецификаций при структурном подходе. Какие характеристики проектируемого программного обеспечения описывает каждая из них?
3.В каких случаях целесообразно использовать диаграммы переходов состояний? Разработайте диаграмму переходов для калькулятора, техническое задание на который составлялось вами в соответствии заданием к предыдущей главе.
4.В чем заключается основное различие между функциональными диаграммами и диаграммами потоков данных? Постройте оба вида диаграмм для выполнения вычислений с использованием внутренней памяти калькулятора. Проанализируйте сходство и различие. В каких случаях использование диаграмм потоков данных является предпочтительным?
5.Что называют «структурами данных»? Какие данные имеются в виду? В каких случаях структуры данных необходимо описывать? Какие модели используют для описания структур данных?
6.Опишите стек и очередь с использованием предлагаемых моделей описания данных. Какие аспекты этих структур остались не описанными и почему?
7.В каких случаях используют математические модели? Что понимают под адекватностью модели? Зачем необходимо выполнять доказательство адекватности и как строятся подобные доказательства?
5. Проектирование программного обеспечения при структурном подходе
Как уже упоминалось ранее, сущность структурного подхода заключается в декомпозиции программы или программной системы по функциональному принципу. Все предлагаемые методы декомпозиции используют интерфейсы простейшего типа: примитивные интерфейсы и традиционные меню. и рассчитаны на анализ и проектирование как структур данных, так и обрабатывающих их программ.
Причем в большинстве случаев первичным считают проектирование обрабатывающих компонентов, проектирование же структур данных выполняют параллельно. Существует и альтернативный подход, при котором первичным считают проектирование данных, а обрабатывающие программы получают, анализируя полученные структуры данных.
В любом случае проектирование программного обеспечения начинают с определения его структуры.
5.1. Разработка структурной и функциональной схем
Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.
Структурная схема разрабатываемого программного обеспечения. Структурнойназывают схему, отражающуюсоставивзаимодействие по управлениючастей разрабатываемого программного обеспечения.
Структурные схемы пакетов программ не информативны, поскольку организация программ и пакеты не предусматривает передачи управления между ними. Поэтому структурные схемы разрабатывают для каждой программы пакета, а список программ пакета определяют, анализируя функции, укачанные в техническом задании.
Самый простой вид программного обеспечения - программа, которая в качестве структурных компонентов может включать только подпрограммы и
библиотеки ресурсов. Разработку структурной схемы программы обычно выполняют методом пошаговой детализации (см. § 5.2).
Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.
Структурная схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе (рис. 5. 1).
Структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов. В отличие от программного комплекса отдельные части (подсистемы) программной системы интенсивно обмениваются данными между собой и, возможно, с основной программой. Структурная же схема программной системы этого обычно не показывает (рис. 5.2).
Более полное представление о проектируемом программном обеспечении с точки зрения взаимодействия его компонентов между собой и с внешней средой дает функциональная схема.
Функциональная схема.Функциональная схема или схема данных (ГОСТ 19.701 -90) - схема взаимодействия компонентов программного обеспечения
с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Основные обозначения схем данных по ГОСТ 19.701-90 приведены в табл. 5.1.
Функциональные схемы более информативны, чем структурные. На рис.5.3 для сравнения приведены функциональные схемы программных комплексов и систем.
Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании,
так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов.