Задача: Model Subsystem Dependencies
This task extends the traditional RUP subsystem design with details specific to a SOA solution, especially where subsystems were identified from business analysis models. Once we make the transition from the business domain to the IT domain, we map identified functional areas defined by the former to subsystems, their IT counterparts.
Назначение

To link the business models to their IT counterparts we perform the following:

  • Identify the relationship between Functional Areas (Concept: Functional Area Analysis) in the Artifact: Business Analysis Model to corresponding Artifact: Design Subsystem.
  • To define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained design elements and external subsystems/interfaces.
  • To document the internal structure of the subsystem, in terms of Artifact: Service Components that realize the Subsystem.
  • To define realizations between the subsystem's interfaces and contained components and classes.
  • To determine the dependencies upon other subsystems.
Взаимосвязи
РолиОсновной: Дополнительно: Помощь:
ВходыОбязательный: Необязательный: Внешний:
  • Нет
Выходы
Основное описание

We begin with the determination and documentation of the dependencies between subsystems that correspond to the functional areas that have been identified during Task: Functional Area Analysis. Usually a functional area will correspond to a single subsystem; that is, the simplifying assumption that has been found to be accurate in many, if not most cases. If we decide to map a functional area to several subsystems, that can also be feasible and valid; but usually means the domain decomposition did not go deep enough and the functional areas are not granular enough.

Шаги
Опишите зависимости подсистемы
Цель: Описать интерфейсы, от которых зависит подсистема.  

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

Причин тому две:

  • Элементы модели (включая подсистемы) должны быть взаимозаменяемы при условии, что их поведение одинаково. Поведение описывается в терминах интерфейсов, поэтому любые обстоятельства, от которых зависит поведение элемента, также должны быть описаны в терминах интерфейсов.
  • У разработчика должна быть полная свобода в отношении внутреннего поведения подсистем, постольку поскольку обеспечивается правильное внешнее поведение. Если элемент модели одной подсистемы ссылается на элемент модели другой подсистемы, разработчик уже не может просто удалить этот элемент модели или распределить его поведение на другие элементы. В результате система становится более "хрупкой".

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

Зависимости между подсистемами, равно как зависимости между подсистемами и пакетами, можно описать напрямую, как показано ниже. В данном случае одна подсистема (например, Invoice Management) напрямую зависит от другой (например, Payment Scheduling Management).


Диаграмма, описанная в тексте.

Пример структуры подсистем с непосредственными зависимостями.

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


Диаграмма, описанная в тексте.

Пример структуры подсистем с зависимостями через интерфейсы

 

Свойства
Несколько вхождений
Управляется событиями
Выполняющийся
Необязательный
Запланированный
Повторяющийся
Дополнительные сведения