
- •СОДЕРЖАНИЕ
- •1.1. Основные понятия и определения
- •1.2. Жизненный цикл программных средств
- •2.1. Стратегии разработки программных средств и систем
- •2.1.1. Базовые стратегии разработки программных средств и систем
- •2.1.2. Каскадная стратегия разработки программных средств и систем
- •2.1.3. Инкрементная стратегия разработки программных средств и систем
- •2.1.4. Эволюционная стратегия разработки программных средств и систем
- •2.2.1. Общие сведения о каскадных моделях
- •2.2.2. Классическая каскадная модель
- •2.2.3. Каскадная модель с обратными связями
- •2.2.5. V-образная модель
- •2.3.1. Базовая RAD-модель
- •2.4.1. Общие сведения об инкрементных моделях
- •2.4.2. Инкрементная модель с уточнением требований на начальных этапах разработки
- •2.5.1. Общие сведения об эволюционных моделях
- •2.5.3. Структурная эволюционная модель быстрого прототипирования
- •2.5.5. Спиральная модель Боэма
- •2.5.6. Упрощенные варианты спиральной модели
- •3.1. Классификация проектов по разработке программных средств и систем
- •3.2. Процедура выбора модели жизненного цикла разработки программных средств и систем
- •3.3. Адаптация модели жизненного цикла разработки ПС и систем к условиям конкретного проекта
- •4.1. Модульное проектирование программ
- •4.2. Метод нисходящего проектирования
- •4.2.1. Пошаговое уточнение
- •4.2.2. Кодирование программы с помощью псевдокода и управляющих конструкций структурного программирования
- •4.2.3. Использование комментариев для описания обработки данных
- •4.2.4. Анализ сообщений
- •4.3. Метод восходящего проектирования
- •4.4. Метод иерархического проектирования модулей (метод Джексона)
- •4.4.1. Основные конструкции построения структур данных
- •4.4.2. Построение структур данных
- •4.4.3. Проектирование структур программ
- •4.4.4. Этапы конструирования программы
- •4.5.1. Связность модуля
- •4.5.2. Сцепление модулей
- •5.1. Общие сведения о CASE-технологиях
- •5.2. Методология структурного анализа и проектирования SADT
- •5.2.2. Основные понятия IDEF0-модели
- •5.2.3. Синтаксис диаграмм
- •5.2.4. Синтаксис моделей
- •5.2.6. Процесс моделирования в IDEF0
- •5.3. Информационное моделирование
- •5.3.1. Сущности
- •5.3.2. Атрибуты
- •5.3.3. Способы представления сущностей с атрибутами
- •5.3.4. Классификация атрибутов
- •5.3.5. Правила атрибутов
- •5.3.6. Связи
- •5.3.7. Безусловные связи
- •5.3.8. Условные формы связи
- •5.3.9. Формализация связи
- •5.3.10. Подтипы и супертипы
- •5.3.11. Рабочие продукты информационного моделирования
- •6.1. Эволюция Case-средств
- •6.2. Концептуальные основы Case–средств
- •6.3.1. Поддержка графических моделей
- •6.3.2. Контроль ошибок
- •6.3.3. Организация и поддержка репозитория
- •6.3.4. Поддержка процесса проектирования и разработки
- •6.4. Классификация CASE–средств
- •6.4.1. Классификация по типам
- •6.4.2. Классификация по категориям
- •6.4.3. Классификация по уровням
- •6.5. Инструментальные средства компании Telelogic, предназначенные для автоматизации жизненного цикла программных средств и систем
- •6.5.1. Telelogic DOORS
- •6.5.2. Telelogic TAU
- •6.5.3. Telelogic SYNERGY
- •6.5.4. Telelogic DocExpress
- •6.5.5. Telelogic TAU Logiscope
- •7.2. Реализация процесса документирования в соответствии со стандартом ISO/IEC 15910:1999
- •7.2.2. Выполнение процесса документирования
- •7.2.3. Содержание плана документирования
- •7.2.4. Требования к содержанию спецификации стиля документации
- •ЛИТЕРАТУРА

Процесс продолжается до принятия решения о прекращении дальнейшей детализации. В этом случае все действия, записанные в последней программе в виде комментариев, которые не были реализованы, необходимо оформить в виде подпрограмм.
4.2.4. Анализ сообщений
Анализ сообщений является второй из стратегий, реализующих метод
нисходящего |
проектирования. |
Анализ сообщений |
используется |
в первую |
|
очередь для структуризации программ обработки информации. |
|
||||
Анализ |
сообщений |
основывается |
на |
анализепотока |
данных, |
обрабатываемых программой.
Рисунок 4.1 иллюстрирует потоки информации и обрабатывающие их процессы для программы обработки пакетов записей[12], рассмотренной в пп. 4.2.2, 4.2.3 (см. примеры 4.1, 4.2).
|
|
Правильные |
|
|
|
Входные Проверка |
пакеты |
Результаты |
Проверка |
||
данные |
пакетов |
Обработка |
результа- |
||
|
пакетов |
|
|
тов |
|
|
|
|
|
||
Неправильные |
|
Неправильные |
Правильные |
||
пакеты |
|
|
результаты |
|
результаты |
Печать
ошибок Печать Запоминание ошибок правильных
результатов
Сообщения об ошибках
Рисунок 4.1 – Диаграмма потоков данных для программы обработки пакетов
Первоначальный поток данных разбивается на три :потокапервый содержит непреобразованные входные данные, а последний только выходную информацию. Границы, разделяющие эти потоки, показаны штриховыми линиями (см. рисунок 4.1). Они делят диаграмму на три части.
72

Данные, подлежащие обработке с помощью процесса«Обработка пакетов», могут не включать всю входную информацию, но это еще часть входных данных. Процесс «Обработка пакетов» может включать кодирование, декодирование, вычисления и другие преобразования данных. Результаты данного процесса могут представлять собой еще не отформатированные, отредактированные, возможно, неверные данные, но это уже выходные данные.
Три части программы, соответствующие трем потокам данных, принято называть соответственно истоком, преобразователем и стоком.
Преобразователь — это основная часть программы, исток выполняет функцию управления входным потоком данных, сток выполняет функцию управления выходным потоком данных.
Рисунок 4.2 представляет диаграмму разбиения программы на исток– преобразователь – сток. Линии на диаграмме показывают потоки передачи данных между процессами.
А В
С
Исток |
Преобразователь |
Сток |
Рисунок 4.2 – Диаграмма разбиения любой программы на исток-преобразователь-сток
Рисунок 4.3 содержит соответствующую схему иерархии модулей программы. В схеме иерархии линии указывают связи по управлению между модулями, а также изображают отношения типа вызывающий–вызываемый. Каждый из блоков на данном рисунке– это программный модуль, который может быть реализован в зависимости от назначения, сложности и размера как
независимый |
модуль, |
внутренняя |
подпрограмма |
или |
некоторая |
часть |
|
программы. |
|
|
|
|
|
|
|
Процесс |
декомпозиции |
программы |
заключается |
в |
рекурсивн |
||
использовании |
метода |
разбиения |
на исток– |
преобразователь |
– сток |
на |
отдельных ветвях древовидной модульной структуры программы. В результате получаются модули нижнего уровня.
Не все модули разбиваются обязательно на три модуля более низкого уровня. Результат декомпозиции модуля-стока должен обязательно содержать сток, модуля-преобразователя – преобразователь, модуля-истока – исток. Вызывающий модуль – это главный сток для модуля-истока и главный исток для модуля-стока.
73

Управление
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
А |
|
В |
|
|
С |
|||
|
|
|
|
|
|
|
|
|
Рисунок 4.3 – Схема иерархии модулей программы
Если структуры данных имеют большие размеры, управление ими осуществляется на уровне детализации данных для модулей истока и стока.
Рисунок 4.4 представляет иерархическую структуру модулей для первого уровня декомпозиции программы обработки пакетов, рисунок 4.5 – для второго уровня декомпозиции.
Обработка
пакетов
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
|
2 |
|
|
3 |
|||
|
|
|
|
|
|
|
|
|
Рисунок 4.4 – Анализ сообщений при проектировании программы обработки пакетов
(декомпозиция первого уровня)
На данных рисунках приняты следующие обозначения:
1)чтение правильного пакета (исток)
2)обработка пакетов (преобразователь)
3)запоминание правильных результатов (сток)
4)чтение пакета (исток модуля-истока 1);
5)проверка пакета (преобразователь модуля-истока 1);
6)запоминание неправильного пакета (сток модуля-истока 1);
7)чтение записи (исток модуля-преобразователя 2);
8)обработка записи (преобразователь модуля-преобразователя 2);
9)проверка результатов (преобразователь модуля-стока 3);
10)запоминание результатов (сток модуля-стока 3).
74

Каждый модуль программы при информационном обмене использует определенную часть данных. Однако в иерархической структуре программы информационные связи между модулями не отражены. Поэтому описание иерархической структуры должно содержать таблицу взаимодействия модулей, показывающую передачу данных между различными модулями.
Обработка
пакетов
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
|
|
2 |
|
|
|
3 |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4 |
5 |
6 |
7 |
8 |
9 |
10 |
Рисунок 4.5 – Анализ сообщений при проектировании программы обработки пакетов
(расширенная декомпозиция)
В этой таблице должны быть определены все способы информационного обмена, задаваемые как при помощи формальных параметров, так и с помощью глобальных переменных.
Таблица 4.1 представляет информационные связи между модулями для программы обработки пакетов.
Таблица 4.1 – Таблица межмодульных связей
Модуль |
Вход |
Выход |
|
|
|
|
|
1 |
— |
Правильный пакет |
|
Конец файла |
|||
|
|
||
2 |
Правильный пакет |
Результаты пакета |
|
|
|
|
|
3 |
Результаты пакета |
— |
|
|
|
|
|
4 |
— |
Данные пакета |
|
Конец файла |
|||
|
|
75