§3.3. Информационные технологии проектирования иус

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

Объектно-ориентированный подход¹⁵ представляет собой последовательный итеративный процесс, который позволяет безболезненно вносить какие-либо изменения в уже отлаженный программный продукт и в котором результаты одного из этапов могут влиять на решения, принятые на предыдущих.

Рис. 3.1

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

Этот метод используется, как правило, в контексте программной или системной инженерии.

В формировании типичной большой системы программного обеспечения аналитик, как правило, должен рассматривать ряд чётко определённых предметных областей, или доменов. Каждый домен может рассматриваться как отдельный мир, населённый собственными концептуальными сущностями, или объектами. Каждый домен может существовать более или менее независимо от других.

Некоторые домены довольно малы, чтобы можно было анализировать их как единое целое, в то время как другие содержат так много объектов, что трудно поддаются контролю и обработке, поэтому большие домены разбиваются на подсистемы.

После того как система разбита на домены и подсистемы, можно проводить анализ. Независимо одна от другой каждая подсистема (или маленький домен) анализируется в три этапа: информационное моделирование, моделирование состояний и моделирование процессов.

Информационные модели

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

Цель этапа моделирования состоит в том, чтобы идентифицировать объекты, которые составляют подсистему, для анализа.

Объекты изображаются на информационной модели вместе с характеристиками, или атрибутами.

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

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

Модели состояний

Когда объекты и связи идентифицированы, необходимо обратиться к исследованию их поведения во времени. В ООА каждый объект и связь может иметь жизненный цикл – организованную схему поведения.

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

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

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

Как только разработаны модели взаимодействия объектов для всех подсистем в домене, для описаний взаимодействий событий между подсистемами может быть нарисована модель взаимодействия подсистем.

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

Всё происходящее в системе содержится в действиях моделей состояний. Теперь каждое действие определяется в терминах процессов и архивов данных объектов, где процесс является фундаментальным модулем операции, а архив данных объекта соответствует данным (атрибутам) объекта в информационной модели.

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

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

Описания процессов разрабатываются для документирования деталей любых запутанных процессов, находящихся на ДПД.

Рабочие продукты ООА

Схема домена и проектная матрица создаются для всей системы. Чтобы описать взаимодействие событий между различными подсистемами в пределах домена, для каждого домена создаётся модель взаимодействия подсистем. Большинство рабочих продуктов ООА нужны на уровне подсистем: информационная модель, модель взаимодействия объектов, модель доступа к объектам и вспомогательные таблицы, описания и списки создаются для каждой подсистемы. Ниже подсистемы находятся объекты, которые её составляют: модель состояний создаётся для каждого объекта и связи, которые имеют интересующее нас динамическое поведение. Действия каждой модели состояний обеспечивают следующий уровень: диаграмма потоков данных создаётся для каждого состояния каждой модели состояний. Наконец, описание процесса создаётся для каждого сложного процесса действия.