
- •Оглавление
- •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. Пояснительная записка
7.7. Особенность спиральной модели разработки. Реорганизация проекта
Спиральная модель жизненного цикла разработки программного обеспечения предполагает, что процесс разработки программной системы выполняется итерационно. При этом во время проектирования очередной версии может обнаружиться, что хорошо продуманная на начальных итерациях программа утратила свою изначально четкую структуру за счет накопившихся исправлений («заплаток»).
Каждая «заплатка» в свое время ставилась, чтобы ликвидировать «небольшое» несоответствие уже реализованной части и той, что находилась в процессе реализации. Возможно также, что часть кодов при этом становилось неиспользуемой, а какие-то коды - не эффективными. Все это вместе приводит к тому, что разобраться в программе становится достаточно сложно. В такой ситуации необходима реорганизация программ, т. е. их перепроекти-
рование без изменения функциональности. Своевременно выполненная реорганизация позволит сделать структуру программы опять четкой и понятной.
Несмотря на то, что реорганизационные изменения, как правило, невелики, программисты их обычно не любят, так как придерживаются правила «работает - не трогай». Кроме того, сроки обычно ограничены, и тратить время на переделку того, что уже отлажено, кажется нецелесообразным. Практика же показывает, что отказ от реорганизации при накоплении исправлений приводит к усложнению программы и, соответственно, снижению ее технологичности со всеми вытекающими последствиями.
Реорганизацию следует выполнять, если при расширении функциональности обнаруживаются нарушения основных концепций проекта или код стап трудным для понимания. В этом случае проектирование нужно приостановить и провести необходимую реорганизацию.
Перепроектирование программы не следует совмещать с увеличением ее функциональности. После реорганизации программу необходимо протестировать, чтобы убедиться, что ничего не было нарушено, а потом уже расширять ее возможности.
Контрольные вопросы и задания
1. Как описывают структуру программного обеспечения при объектном подходе? Что такое «пакет»? Для чего используют диаграммы пакетов?
2. Какие стереотипы классов введены и почему?
3. Разработайте диаграмму пакетов графического редактора, описанного вами при выполнении задания 9 к гл. 6. Какие пакеты включены в эту диаграмму и почему? Какие пакеты будут связаны между собой?
4. Постройте диаграмму последовательности действий для объектов любых предложенных вами пакетов. Какими сообщениями обмениваются объекты? Какую информацию программист получит, анализируя эту диаграмму?
5. Какую диаграмму используют при уточнении взаимодействия объектов? Постройте эту диаграмму для объектов предыдущего задания.
6. Перечислите основные компоненты классов. Как описывают эти компоненты?
7. В каких случаях используют диаграммы состояний объекта? Постройте диаграмму состояний для любого управляющего объекта.
8. Постройте уточненную диаграмму классов по результатам исследования взаимодействия объектов. Какая еще информация необходима для реализации этих классов?
9. Что понимают под диаграммой компонентов? Какую информацию она содержит? В каких случаях целесообразно строить диаграммы компонентов?
Какую информацию содержит диаграмма размещения? В каких случаях целесообразно использовать эти диаграммы?