Основы программирования

Мой процветающий бизнес дома: купить сертификат.
Методы анализа - Описание потоков данных и процессов
Индекс материала
Методы анализа
Описание потоков данных и процессов
Описание потоков данных и процессов
Методы анализа, ориентированные на структуры данных
Методика Джексона
Шаг объект-структура
Шаг начального моделирования
Контрольные вопросы
Основы проектирования программных систем
Особенности этапа проектирования
Структурирование системы
Моделирование управления
Декомпозиция подсистем на модули
Связность модуля
Функциональная связность
Коммуникативная связность
Временная связность
Связность по совпадению
Сцепление модулей
Контрольные вопросы
Классические методы проектирования
Проектирование для потока данных типа «преобразование»
Проектирование для потока данных типа «запрос»
Доопределение функций
Учет системного времени
Структурное тестирование программного обеспечения
Тестирование «черного ящика»
Потоковый граф
Цикломатическая сложность
Шаги способа тестирования базового пути
Тестирование ветвей и операторов отношений
Тестирование циклов
Неструктурированные циклы
Функциональное тестирование программного обеспечения
Способ разбиения по эквивалентности
Способ анализа граничных значений
Способ диаграмм причин-следствий
Организация процесса тестирования программного обеспечения
Тестирование интеграции
Восходящее тестирование интеграции
Системное тестирование
Стрессовое тестирование
Все страницы

 

Расширение возможностей управления

 

Д. Хетли и И. Пирбхаи сосредоточили внимание на аспектах управления программным продуктом [34]. Они выделили системные состояния и механизм перехода из одного состояния в другое. Д. Хетли и И. Пирбхаи предложили не вносить в ПДД элементы управления, такие как потоки управления и управляющие процессы. Вместо этого они ввели диаграммы управляющих потоков (УПД).

Диаграмма управляющих потоков содержит:

q обычные преобразователи (управляющие преобразователи исключены вообще);

q потоки управления и потоки событий (без потоков данных).

Вместо управляющих преобразователей в УПД используются указатели — ссылки на управляющую спецификацию УСПЕЦ. Как показано на рис. 3.7, ссылка изображается как косая пунктирная стрелка, указывающая на окно УСПЕЦ (вертикальную черту).

 

Рис. 3.7. Изображение ссылки на управляющую спецификацию

УСПЕЦ управляет преобразователями в ПДД на основе события, которое проходит в ее окно (по ссылке). Она предписывает включение конкретных преобразователей как результат конкретного события.

Иллюстрация модели программной системы, использующей описанные средства, приведена на рис. 3.8.

 

Рис. 3.8. Композиция модели обработки и управления

 

В модель обработки входит набор диаграмм потоков данных и набор спецификаций процессов. Модель управления образует набор диаграмм управляющих потоков и набор управляющих спецификаций. Модель обработки подключается к модели управления с помощью активаторов процессов. Активаторы включают в конкретной ПДД конкретные преобразователи. Обратная связь модели обработки с моделью управления осуществляется с помощью условий данных. Условия данных формируются в ПДД (когда входные данные преобразуются в события).

Модель системы регулирования давления космического корабля

 

Обсудим модель системы регулирования давления космического корабля, представленную на рис. 3.9.

Начнем с диаграммы потоков данных. Основной процесс в ПДД — Слежение и регулирование давления. На его входы поступают: измеренное Давление в кабине и Мах давление: На выходе процесса — поток данных Изменение давления. Содержание процесса описывается в его спецификации ПСПЕЦ.

Спецификация процесса ПСПЕЦ может включать:

1) поясняющий текст (обязательно);

2) описание алгоритма обработки;

3) математические уравнения;

4) таблицы;

5) диаграммы.

Элементы со второго по пятый не обязательны.

 

Рис. 3.9. Модель системы регулирования давления космического корабля

 

С помощью ПСПЕЦ разработчик создает описание для каждого преобразователя, которое рассматривается как:

q первый шаг создания спецификации требований к программному изделию;

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

В нашем примере спецификация процесса имеет вид

если Давление в кабине > мах

то Избыточное давление:=11;

иначе Избыточное давление:=0;

алгоритм регулирования;

выч.Изменение давления;

конец если;

Таким образом, когда давление в кабине превышает максимум, генерируется управляющее событие Избыточное давление. Оно должно быть показано на диаграмме управляющих потоков УПД. Это событие входит в окно управляющей спецификации УСПЕЦ.

Управляющая спецификация моделирует поведение системы. Она содержит:

q таблицу активации процессов (ТАП);

q диаграмму переходов-состояний (ДПС).

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

ТАП включает три раздела — Входные события, Выходные события, Активация процессов. Логика работы ТАП такова: входное событие вызывает выходное событие, которое активирует конкретный процесс. Для нашей модели ТАП имеет вид, представленный в табл. 3.1.

Таблица 3.1. Таблица активации процессов

Входные события:

Включение системы

1

0

0

Избыточное давление

0

1

0

Норма

0

0

1

Выходные события:

Тревога

0

1

0

Работа

1

0

1

Активация процессов:

Слежение и регулирование давления

1

0

1

Уменьшение давления

0

1

0

 

Видим, что в нашем примере входных событий три: два внешних события (Включение системы, Норма) и одно — условие данных (Избыточное Давление). Работа ТАП инициируется входным событием, «втекающим» в окно УСПЕЦ. В результате ТАП вырабатывает выходное событие — активатор. В нашем примере активаторами являются события Работа и Тревога. Активатор «вытекает» из окна УСПЕЦ, запуская в УПД конкретный процесс.

Другой элемент УСПЕЦ — Диаграмма переходов-состояний. ДПС отражает состояния системы и показывает, как она переходит из одного состояния в другое.

ДПС для нашей модели показана на рис. 3.10.

Системные состояния показаны прямоугольниками. Стрелки показывают переходы между состояниями. Стрелки переходов подписывают следующим образом: в числителе — событие, которое вызывает переход, в знаменателе — процесс, запускаемый как результат события.

 

Изучая ДПС, разработчик может анализировать поведение модели и установить, нет ли «дыр» в определении поведения.