UML-разъем Направление
При моделировании архитектуры в диаграммах компонентов UML как вы одновременно показываете различные атрибуты соединителей? подобно
- информационный поток бизнес-объекта (A-> B, B-> A, A<->B)
- направление запроса / ответа
- синхронное / асинхронное поведение
Мне известны другие типы диаграмм, такие как диаграммы последовательности. Однако наличие этой информации, видимой на диаграммах компонентов, будет иметь значение.
Что возможно за пределами ассоциаций (просто показывает, что компоненты связаны) или "леденцы на палочке" (запрос / ответ)?
3 ответа
Для начала, не пытайтесь объяснить это динамическое сотрудничество, используя соединители на диаграмме классов.
Направление стрелки соединителей на диаграмме классов просто указывает, кто знает, кто. Это означает, что зависимости между классами. С помощью этих стрелок вы можете указать, какие классы нужны другим классам, но вам не нужно объяснять, какова динамика взаимодействия между этими предложениями. Вот для чего нужны динамические диаграммы UML.
Начните со своей диаграммы классов, которая представляет собой статическое представление системы, а затем добавьте несколько динамических диаграмм.
В качестве динамических диаграмм, наряду с диаграммами последовательности, которые являются наиболее распространенными, вы также можете использовать:
- Диаграммы деятельности
- Диаграммы состояний
- Диаграммы сотрудничества
У каждого из них есть своя собственная достопримечательность, и основная стратегия заключается в том, чтобы повторно использовать некоторые объекты, определенные на диаграмме классов, для описания конкретных сценариев.
Для каждого из "интересных" сценариев в вашей системе вы должны создать одну из этих динамических диаграмм, чтобы описать, что происходит между объектами, которые вы указали на диаграмме классов.
Как правило, каждый вариант использования будет описываться одной диаграммой классов и одной или несколькими динамическими диаграммами. Вся эта информация о дизайне вместе называется реализацией варианта использования, потому что они описывают дизайн, который сделает ваш сценарий использования реальным при создании кода.
Ознакомьтесь с UML Distilled Фаулера, чтобы получить краткое, но превосходное объяснение этого рабочего процесса проектирования с использованием UML.
Вы можете использовать отношение InformationFlow, как описано в разделе 17.2 надстройки UML:
Информационные потоки описывают циркуляцию информации в системе в общем виде. Они не определяют характер информации (тип, начальное значение), а также механизмы, с помощью которых эта информация передается (передача сообщений, сигнал, общее хранилище данных, параметр операции и т. Д.). Они также не определяют последовательности или какие-либо условия контроля. Предполагается, что при подробном моделировании связи представления и реализации смогут указывать, какой элемент модели реализует указанный поток информации и как информация будет передаваться.
Возможно, вы захотите использовать диаграммы последовательности вместо диаграмм классов (т.е. компонентов).
Если вы хотите придерживаться статической диаграммы, вы также можете рассмотреть возможность добавления << sterotypes>> к различным соединителям или даже использовать классы ассоциации.
Если возможно, вы можете использовать соединители из диаграмм последовательности для соединения классификаторов в диаграммах компонентов (например, стрелки синхронной / асинхронной передачи сообщений).