Управление большим доменом

В [7] маленьким считается домен, состоящий из 50 или менее классов. В этом случае он может анализироваться как единичный модуль. Домены с большим количеством объектов должны быть расчленены, для того, чтобы можно было успешно выполнить анализ.

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

При определении подпакетов вначале выполняется блиц идентификация классов. Для этого необходимо идентифицировать максимально возможное количество кандидатов в классы, а затем отсортировать этих кандидатов по принципу связности. При выполнении этой работы должны участвовать все члены проекта. Могут использоваться следующие подходы при определении подпакетов. Первый основан на понятии ролей пользователей, основанных на классах. Если окажется, что роли пользователей связаны с четким набором классов, тогда подпакет базируют на классах, связанных с каждой ролью. Например, Слесарь работает со слесарным оборудованием, электромонтер – с электрооборудованием и т.п. Второй основан на понятии ролей пользователей, основанных на времени или функции. В некоторых ситуациях роли пользователей основываются главным образом на времени выполнения их функций. Например, в приложении Управление Боем различные пользователи связаны с различными этапами планирования боя, его проведения и оценки результатов. Здесь каждая из фаз рассматривает одну и ту же предметную область в различное время и с различными целями.

При начальном определении подпакета определяется его имя, составляется описание работы (мини-руководство) и список классов, пробно назначенных подпакету. При этом при описании четко определяется все то, что должен делать подпакет.

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

Разработка домена

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

Рисунок 3 - Итеративный процесс проектирования

Цель выяснения семантики классов и объектов - определить поведение и атрибуты каждой абстракции.

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

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

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

Структура приложения

Любое приложение разбивается на: основную программу, архитектурные классы и прикладные классы.

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

- создание и инициализацию всех предварительно существующих экземпляров классов;

- ввод или имитацию внешних событий;

- диспетчеризацию внутренних событий.

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