Какую диаграмму UML следует использовать для документирования архитектуры системы, управляемой сообщениями, которая использует EIP? - PullRequest
0 голосов
/ 12 апреля 2019

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

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

Какая UML-диаграмма наиболее подходит для этого?

Ответы [ 3 ]

1 голос
/ 12 апреля 2019

Когда вы говорите EIP, я предполагаю, что вы имеете в виду Шаблоны интеграции предприятия , т.е. разнообразный набор шаблонов для интеграции корпоративных приложений, таких как Маршрутизатор сообщений , Брокер сообщений , Канал сообщений , Сервисный вызов и т. д., как задокументировано в нескольких популярных книгах и газетах. Если это так, то ваша ссылка на шаблон Message Channel имеет смысл, и я думаю, что я понимаю, что вы имеете в виду.

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

1 голос
/ 12 апреля 2019

С момента появления enterpriseintegrationpatterns.com:

Профиль UML для EAI [UMLEAI] обогащает семантику диаграмм сотрудничества для описания потоков сообщений между компонентами.Эта нотация очень полезна в качестве точного визуального описания системы, которая может служить основой для генерации кода в рамках архитектуры на основе моделей (MDA).

Диаграммы сотрудничества заменены в UML 2с коммуникационными диаграммами

Однако введение enterpriseintegrationpatterns.com продолжает:

Мы решили не принимать эту запись ... {потому что}.... Профиль UML не охватывает все шаблоны, описанные в нашем языке шаблонов.

В текущее время написания (апрель 2019 г.) выясняется, что в последний раз профиль EAI для UML былопубликовано было март 2004 .Это предшествует выдержкам из enterpriseintegrationpatterns.com, который в соответствии с обратным механизмом был впервые опубликован в августе 2015 .

Это говорит о том, что UML 2 плохо оборудован для описания управляемых сообщениями системных архитектур, которые воплощают EIP.

0 голосов
/ 12 апреля 2019

Вы можете использовать диаграмму компонентов и / или диаграмму составной структуры.Если в вашем случае каждый микросервис создается только один раз, то вам нужна только одна из этих диаграмм.В противном случае было бы хорошо, если бы диаграмма компонентов показывала уровень класса, а диаграмма составной структуры показывала уровень экземпляра.См. Вопрос Зависимость диаграммы компонентов от сборки .

Очередь сообщений может быть смоделирована как отдельный компонент со стереотипом <<queue>> или как интерфейс со стереотипом <<queue>>.Моделирование очереди как отдельного компонента - лучший выбор, если очередь не принадлежит одному сервису.Однако, если он принадлежит (только один сервис помещает / публикует сообщения на нем), тогда отдельный компонент очереди загромождает диаграмму, и было бы лучше смоделировать его как интерфейс, предоставленный производителем сообщения и требуемый потребителями сообщения.

...