Модель предметной области

Сегодня мы будем описывать предметную область - основу представления пользователя.

Чтобы описать предметную область, у нас, по сути, всё есть. При условии, конечно, что мы аккуратно собрали и систематизировали пользовательские истории и корректно сделали модель прецедентов.

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

Я буду строить модель сущностей и отображать её посредством диаграммы классов UML. В Enterprise Architect есть отдельная модель предметной области (domain model), но по сути она является той же моделью классов и использует ту же нотацию UML.

Альтернативой может быть ER-модель (модель "сущность-связь"). В этом случае отличается только нотация, а принципы проектирования модели предметной области остаются теми же.

Сущности могут быть двух видов: субъекты и объекты. Субъекты - это сущности, которые управляют другими сущностями. Объекты - это сущности, которые являются управляемыми.

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

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

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

• Сама учётная запись Account, связанная с авторизованным пользователем;

• Роль пользователя Role, которая может быть назначена учётной записи, причём ролей у одной учётки может быть несколько;

• Сертификат Certificate, выдаваемый пользователю для подписи заявок.

Очевидно, что сертификатов у одной учётной записи может быть несколько: пока один ещё действует, пользователь получает новый.

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

Теперь переходим к переносу сущностей из пакета ServiceLog. Тут у нас несколько сущностей, представляющих три агрегата.

Агрегатом называется структура (дерево) взаимосвязанных сущностей, изменяемых как единое целое. Агрегат состоит из одной или более сущностей, причём в случае нескольких сущностей они входят в состав друг друга (т.е. имеет место агрегация или композиция).

Итак, у нас три агрегата. Один сложный - сама сервисная книжка и её записи. Второй простой - заявка. Третий тоже простой - карточка обслуживаемого автомобиля.

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

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

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

Вообще, я рекомендую разбивать сущности по пакетам по числу агрегатов. В пакете ServiceLog я создал три подпакета Log, Request и Car. Ведь информацию книжки пользователь просматривает на одной форме, заявку вводит в другой, а информацию об автомобиле просматривает и изменяет в третьей. То же касается обработки агрегатов на уровне бизнес-логики. То же касается структуры хранения данных. Т.е. мы имеем естественные функциональные границы, которые закладываются в модель в виде структуры пакетов, которая потом транслируется в структуру программных модулей (об этом я расскажу, когда буду рассматривать представление разработки).

В итоге, я получаю модель, представленную на заглавном рисунке этой статьи. Если что-то не понятно, задавайте вопросы в комментариях.

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

• Сущности-значения - типы данных, такие, как перечисления, единицы измерения и т.п.;

• Сервисы предметной области - некоторые внешние источники бизнес-данных, независимо от их реализации и реализации взаимодействия с ними;

• События предметной области - состояния предметной области, при достижении которых происходит определённая реакция: от оповещения акторов до автоматического запуска или останова бизнес-процессов;

• Сущности, которые являются составляющими частями сущностей, упоминаемых в сценариях.

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

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

Все эти сущности характерны для модели предметной области, но их рассмотрение выходит за рамки рассматриваемой темы.

Появление сервисов, событий и составных сущностей, кстати, может привести к пересмотру сценариев. Этот обратный процесс всегда присутствует в проектировании. В Enterprise Architect для этого применяется связь "трассировка" и соответствующий инструмент, отслеживающий трассируемость элементов в единой архитектурной модели.

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

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