Диаграммы последовательности UML и связи компонентов

Question

Это обсуждалось с коллегой в качестве пищи для размышлений - каков технически приемлемый способ обработки отношений между компонентами и подкомпонентами в диаграмме UML sequence .

Итак, вот вопрос - в передовых практиках UML должна ли диаграмма последовательности иметь какую-либо связь с отношениями с объектами, описанными на диаграмме? Моим инстинктом было бы «нет» - нарисуйте диаграмму последовательности с каждым отдельным компонентом и дополните ее диаграммами классов или диаграммами развертывания, чтобы показать другие типы отношений в игре.

Если вы скажете "ДА!" Пожалуйста, напишите мне несколько хороших примеров того, как и почему вы бы поступили иначе.

Если "Нет", можете ли вы указать мне некоторые заслуживающие доверия онлайн-ссылки для обоснования? Я попробовал спецификацию UML и ... оу! ... не то, что я хотел, если я не пытался бить себя без сознания.

В частности, вот мой пример - я хочу смоделировать диаграмму последовательности того, как сервер приложений вызывает подключаемый модуль безопасности, а затем вызывает основное приложение, которое было развернуто с помощью JSP и Java. Сервер приложений, безусловно, «содержит» плагин и приложение, но имеет ли это значение для диаграммы последовательности?

В этой ситуации вы просто выбросили бы три вещи как 3 дорожки с сервером приложений в качестве мозговых операций или сделали бы что-то другое, чтобы показать, что ни плагин, ни приложение ничего не будут делать в автономный путь?

Answer 1

Ну

Оба действительны ....

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

> We draw a diagram since we have a purpose.... So Ask yourself which
> one help me more about solving my problem at hand? Which one is
> helpfull for my purpose?

Answer 2

Могут быть веские причины для включения «внутренней жизни» элемента в последовательность.Иногда вы действительно хотите предоставить как можно более полную и подробную информацию, например, если вы отправляете свой проект на проверку безопасности - тогда абстракции не нужны;вам нужно точно показать, что на самом деле происходит.

Другими словами, вопрос не столько в наилучшей практике UML, сколько в том, какую именно информацию нужно донести до конкретной аудитории.

Enterprise Architect от Sparx Systems позволяет включать встроенные элементы (например, порты или предоставляемые интерфейсы) в последовательность, но, честно говоря, я сам не знаю, совместимо ли это с UML или нет.В любом случае, вот пример.Тривиально, но вы поняли:

Answer 3

Это рассказывает о том, что я знаю о спецификации, о том, что я прочитал, и о переживаниях.

Нет. Диаграмма последовательности показывает поведение и отношения компонентов являются частью структуры. Спецификация и книги UML разбиты таким образом, структурные диаграммы и диаграммы поведения; Вики предоставляет изображение этого. Некоторые элементы модели, такие как класс и т. Д., Используются в обоих, но отношения и композиция действительно не в этом смысле. Кроме того, диаграммы поведения предназначены для показа путей выполнения и обычно не являются «полными». Структурные диаграммы и связи компонентов являются более конкретными и определенными в этом смысле. Вы всегда можете раскрасить код, использовать полные имена или стереотипы, чтобы обогатить представление, но что касается модели и стандартного обозначения диаграммы №.