Домены реализации

Домены реализации включают в себя языки программирования, сети, операционные системы общие библиотеки классов. Эти домены обеспечивают концептуальные сущности, в которых будет реализована вся система. Например, предположим, что архитектурный домен приписал объектно-ориентированное проектирование, основывающееся на классах. В языке C++ для реализации архитектурной идеи о классе будет, несомненно, использоваться конструкция класса C++. Если же доменом реализации является Ada, то, вероятно, что архитектурный класс реализовывается как package, который создается определенным предписанным образом. Однако, если язык реализации - ФОРТРАН, класс в архитектурном домене будет обеспечен как набор подпрограмм, каждая из которых обращается к Common Block, который обозначается именем, уникальным для класса.

7.3 Мосты Мосты, пользователи и исполнители (клиенты и сервера)

Когда один домен использует механизмы и возможности, обеспечиваемые другим, мы говорим, что существует мост между двумя доменами. Два домена, соединенные мостом, играют различные роли по отношению один к другому и, следовательно, обозначаются различными терминами: домен, который использует возможности, известен как пользователь, в то время как домен, который их обеспечивает, - как исполнитель. Например, в системе Управления Железной Дорогой прикладной домен (как пользователь) обращается к домену Сигнал (как исполнителю) для сообщения о появлении условий, вызывающих беспокойство. Домен Сигнал (теперь действующий как пользователь), в свою очередь, использует домен

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

Предложения и требования

Во время анализа мост между двумя доменами представляет набор предложений (с точки зрения пользователя) и набор требований (с точки зрения исполнителя):

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

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

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

Атрибуты, основанные на показаниях приборов. Прикладной домен считает, что основанные на показаниях приборов атрибуты, типа Бак Для Приготовления.Действительная Температура, имеют значения в данный момент времени. Это требование определено для домена ПВВ.

События, выходящие за границу. Когда модели домена пользователя в ООА показывают, что событие порождается для сущности вне границ системы, считается, что существует механизм, который может брать событие и преобразовывать его в форму,понятную для получателя. Это составляет требование для домена ПВВ (если,событие направлено на физическое оборудование) или для сервисного домена, который непосредственно или косвенным образом взаимодействует с оператором: обычно это домен Пользовательский Интерфейс или Сигналы. Аналогично, когда модели прикладного домена в ООА показывают, что событие порождается внешней сущностью, считают, что доме}! ПВВ или Пользовательский Интерфейс может обеспечивать это событие в форме, понимаемой прикладным доменом.

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

Двойники. Хотя объект в одном домене не требует существования объекта в другом, экземпляр объекта в одном домене может иметь двойника в другом. Например, поезд (в домене Управление Железной Дорогой) может иметь двойника (пиктограмму поезда) в домене Пользовательский Интерфейс. Цель пиктограммы поезда - представлять поезд для оператора. Следовательно, расположение пиктограммы на экране (экранные координаты) зависит от местоположения поезда в реальном мире.

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