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

В этой главе мы рассматриваем методику анализа большого домена.

8.1 Понятие подсистемы

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

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

Рис.8.1.1. Разделение большого домена на подсистемы

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

8.2 Начальное определение подсистем Проблема начальной инициализации

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

Начало

Вот некоторые предложения создания начального определения для подсистем большого домена.

Блиц-идентификация объектов. Идентифицируйте максимально возможное количество кандидатов в объекты проведением блиц-идентификации объектов: общим сеансом плодотворных идеи, в котором члены проекта описывают максимальное количество кандидатов в объекты. Часто это может быть сделано просто общим ознакомлением с предметной областью. Если у Вас есть предварительная концепция проекта или документ требований, используйте их как источник идей.

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

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

Роли пользователей, основанные на объектах. Совершенно другой подход основан на понятии ролей, которые исполняют различные пользователи системы. В задаче Управления Железной Дорогой, например, обязанности по управлению работой железной дороги могут быть разделены так, что один оператор пли отдел несет ответственность за сопровождение подвижного состава, другая группа ответственна за движение поездов и третья группа отвечает за обеспечение электричеством поездов, использующих третьи рельсы или верхние токоприемники. Если кажется, что роли пользователей связаны с четким набором объектов, тогда подсистему базируют вокруг каждой роли: Сопровождение Подвижного Состава, Движение Поезда и Электрификация.

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

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

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

Пример 1. (описывает подсистему в терминах объектов). Подсистема Отправление Поездов - о составлении графика работы, выходных, маршрутах, станциях и перевозках пассажиров при всевозможных обстоятельствах.

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

Описание подсистемы в примере 2 более предпочтительно.