UML-диаграмма для зависимости между системами

Какая UML-диаграмма лучше всего показывает зависимость между нашей ИТ-системой и другими внешними ИТ-системами?

Например, я хотел бы показать на диаграмме:

  1. система A получает данные из системы B
  2. Система B может вызывать некоторые функции из системы A

Я задаюсь вопросом между диаграммой компонентов и диаграммой последовательности.

Как вы думаете?

Источник

3 ответа

Решение

Компоненты определенно, и зависимости. Зависимость идет не в направлении потока данных, а от компонента, который "знает" другой компонент (вызывает из него что-то, создает объект и т. Д.).

Следующая диаграмма показывает идею.

введите описание изображения здесь

Распространенной (и очень рекомендуемой) практикой является использование интерфейсов между компонентами и зависимостей каналов через интерфейс. Это позволяет более четкую спецификацию и лучший дизайн (если возможно, конечно).

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

Источник

Ваш вопрос не очень специфичен, так как все диаграммы UML показывают какую-то зависимость или способ получения данных или выполнения вызова, поэтому я не уверен, правильно ли я понял суть вашего вопроса

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

Обычно вы моделируете одну систему (+ несколько черных ящиков в окружающей среде) и одну модель UML. В лучшем случае используемый вами инструмент должен поддерживать Model Driven Architecture (MDA) и, возможно, даже исполняемый UML, так что результатом вашего моделирования может быть больше, чем набор "картинок". Он может стать основой исходного кода, образующего основу приложения, или даже продуктом "нажми и запускай модель".

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

(Это было трудной частью для меня, чтобы понять)

2. прежде чем решить, какие диаграммы использовать, сделайте несколько бумажных и карандашных прототипов

Очень важно убедиться, какая диаграмма соответствует вашим потребностям, прежде чем вы начнете рисовать ее в привлекательной форме с использованием инструмента. Даже рисование в Enterprise Architect требует некоторого времени, чтобы привыкнуть и сделать это правильно.

Очень хорошее руководство, как делать бумажные и карандашные диаграммы и какие из них использовать, на что и как тратить столько времени, сколько необходимо:

3. Диаграммы последовательности очень просты и полезны для программистов.

Есть даже инструменты, которые могут превратить диаграммы последовательности в код или инструменты, которые могут превратить исходный код в диаграмму последовательности.

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

5. обзорные диаграммы высокого уровня, полезные для программистов и других (не UML)

6. = 1 + 2 + ты

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

Источник

В дополнение к вашим мыслям и тому, что сказал Алекс, люди обычно используют сочетание того и другого, чтобы сформулировать межсистемные отношения

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

Диаграммы компонентов и диаграммы последовательности, использующие одни и те же компоненты

Источник
Другие вопросы по тегам