1. Ф Программа пополнения словаря Ввод исходных данных Ввод а Сортировка- слияние Ввод d Вывод а ункциональная структура:

(ФБ "Сортировка-слияние" может состоять из более мелких блоков, и т.д.). Заметим, что из этой модели не очевидна последовательность выполнения компонентов, например, в данном примере порядок, в котором выполняется ввод А и D, а в более общем случае - выбор между компонентами и их повторение.

2. Алгоритмическая модель - блок-схема:

Здесь явно изображается последовательность выполнения и выбор (разветвление). Зато на одной блок-схеме трудно показать вложенность блоков "Ввод А" и "Ввод D" в блок более высокого уровня иерархии "Ввод исходных данных". Детализация, например, блока "Сортировка-слияние" возможна на другой блок-схеме. Вопрос 4.

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

Блок-схемы нагляднее текстов (особенно для непрофессионалов), как любая графика, но устарели ввиду их громоздкости и сложности автоматической обработки. Они вытеснены псевдокодом - текстовой нотацией, где управляющие конструкции (разветвление, цикл, вызов подпрограммы и т.д.) заимствуются из языка программирования (Паскаля, Си), а содержание ФБ записывается неформально, на естественном языке, как и в блок-схемах. Существуют и специально разработанные псевдокоды, как язык PDL (Program Design Language) фирмы IBM.

Наш пример:

Start;

Ввод файла дополнений D;

If D пуст Then Stop;

Ввод файла словаря А;

Сортировка-слияние;

Вывод файла словаря А;

Stop

Ввод D

D пуст ?

Вывод А

Ввод А

Да

Нет

Сортировка -слияние

3. Схема потока данных:

Cортировка- слияние

А

D

А

Такая модель описывает взаимосвязь ФБ по данным: входным, выходным или общим (глобальным) переменным. Удобна для описания, например, автоматизированного документооборота в АСУ.

4. Диаграмма состояний и переходов:

Состояния изображаются кружками или овалами, переходы - дугами. Дуги нагружаются условиями переходов по ним. Граф в данном случае изоморфен блок-схеме алгоритма. В этой модели хорошо описываются реакции на внешние события и нестандартные ситуации. Например, из состояния "Ввод Х" может исходить еще одна дуга, соответствующая переходу по ошибке чтения файла (возможная реакция - вывод сообщения и повторная попытка чтения). В блок-схеме алгоритма отображение таких асинхронных событий невозможно (так же как и состояний их ожидания). Вопрос 5. (Асинхронный – значит не синхронизированный с командами программы).

Для различных видов ПП и их частей удобны различные виды моделей. Функциональная структура наиболее универсальна; она служит для функциональной декомпозиции проекта – расчленения на части с целью последующего разделения труда и этапности разработки. Например, в технологии Microsoft на основе внешней специ-фикации все основные функции ПП упорядочиваются по убыванию степени важности и разбиваются на 3-4 группы - подпроекты, работа над которыми будет вестись после-довательно. Каждый подпроект заканчивается выпуском промежуточной "контроль-ной" версии ПП (milestone release) в соответствии со спиральной моделью ЖЦ.

Алгоримическая модель (обычно на псевдокоде, С или Паскале) необходима для описания нетривиальных алгоритмов. Схемы потока данных лучше подходят для тех систем обработки данных, где вычисления тривиальны, а обмен – интенсивен. HIPO – технология фирмы IBM 70-х годов ("Hierarchical Input-Processing-Output”) полностью основывалась на DFD. В наши дни DFD применяются в CASE-системах проектирования корпоративных ИС: IDEF и BPwin. Интересно также применение DFD для разработки программ для суперкомпьютеров (см. Приложение; Вопрос 6.).

Модель баз данных “сущность-связь” – более общая и наглядная, чем реляционная. Она используется в популярной CASE ERwin. На рис. ниже – пример: фрагмент модели базы данных предприятия в нотации Чена. Прямоугольниками изображаются сущности, ромбами – отношения (связи).

Событийная модель удобна для описания реактивных (responsive) систем, к которым относятся системы реального времени и диалоговые программы. В них состояния соответствуют приостановке вычислений в ожидании некоторого события, вызывающего переход в другое состояние - в зависимости от вида события. Windows и другие ОС с оконным интерфейсом построены по такой модели и поэтому называются системами, продвигаемыми событиями (event-driven systems). Проекты сложных ПП обычно требуют описания несколькими видами моделей, взаимно дополняющими друг друга, и именно таков подход UML. (Многомодельность вообще характерна для описания сложных систем.) Однако смешение средств разных видов в одной модели недопустимо.