Модели процессов

В предыдущем параграфе было выведено понятие действие. Действие – это операция, которая должна выполняться объектом, когда он достигает состояния. Действия рассматривались как одно целое. Цель составления модели процессов – расчленить каждое действие на процессы, которые взятые вместе, определяют требуемое функциональное содержание системы. Каждый процесс имеет входные и выходные данные. Поэтому удобно представить модели процессов на диаграммах потоков данных (ДПД). Общие принципы построения ДПД изложены в п. 1.1. если действия простые и их структура очевидна, то модели процессов можно отдельно не создавать.

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

А

С

В

В1

В2

А1

А2

С1

С2

С3

Рис. 2.9. Миграция классов В и С суперкласса А

В дополнение к рассмотренным в п. 1.1. обозначениям появились потоки управления. В традиционной ДПД любой узел обработки может быть запущен при наличии всех его входных данных. Может возникнуть необходимость определения дальнейшего пути обработки в зависимости от результатов предыдущих шагов при одном и том же составе исходных данных, но разных значениях. В таком случае на ДПД кроме потоков данных используют еще и потоки управления. Пример ДПД приведен на рис. 2.10.

Обозначения: поток данных поток управления

Условие

Рис. 2.10. Диаграмма потоков данных с потоками данных и управления

Для облегчения проектирования и реализации программного обеспечения целесообразно уже на стадии ООА выделить многократно используемые процессы. Цель – уменьшение объема программной реализации. Для выявления одинаковых процессов проверяют какие процессы:

выполняют одну и ту же функцию;

читают (записывают) одни и те же данные из (в) одних и тех же файлов;

имеют на входе и выходе одни и те же данные;

создают одни и те же события как выходы;

создают одни и те же выводы условного управления.

Подсистемы

Если исследуемая предметная область велика, то при проведении ООА целесообразно ее разделить на подсистемы. В одну подсистему входят объекты, наиболее тесно связанные друг с другом. Между подсистемами, в принципе, существуют те же самые отношения, что и между классами. Поэтому можно говорить об информационной модели, модели состояний и модели действий на уровне подсистем, имея при этом в виду, что каждый компонент на этих моделях имеет сложную внутреннюю структуру.

Подведем итоги. В результате ООА должны быть составлены:

Информационная модель., включающая описание классов и отношений между ними. Описание класса включает перечень атрибутов с множеством допустимых значений.

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

Модель процессов, включающая все действия (сообщения), передаваемые классам извне и действия, выполняемые классами после их принятия (после достижения классом определенного состояния). Последние могут быть направлены и за пределы данной модели. Часто используется следующая терминология. Объекту (экземпляру объекта) передается сообщение, объект реагирует на него и может выдать новое сообщение другому объекту или система возвращается в исходное состояние.