Спецификация возникновения и выполнения в диаграммах последовательностей, когда использовать каждую?

Хорошее резюме терминов можно найти на uml-diagrams.org.

В спецификации UML говорится на стр. 578

ExecutionOccurrenceSpecification представляет на линии жизни начальное или конечное событие ExecutionSpecification.

и

ExecutionOccurrenceSpecification представлена ​​начальной или конечной конечной точкой вертикального блока для ExecutionSpecification на линии жизни. См. Рисунок 17.2.

Таким образом, они просто отмечают момент времени, когда что-то происходит. На самом деле в спецификации есть несколько примеров, где временные ограничения также применяются вместе с ExecutionOccurrenceSpecification.

On p. 567:

Технические характеристики выполнения представлены в виде тонких прямоугольников (серого или белого) на линии жизни (см. 17.3.4 (Линия жизни)).

Мы также можем представить ExecutionSpecification в виде более широкого помеченного прямоугольника, где метка обычно идентифицирует действие, которое было выполнено. Пример этого можно увидеть на рисунке 17.16.

Проще говоря: в черном ящике что-то происходит.

Теперь для OccurrenceSpecification есть рекурсивное определение в спецификациях на стр. 566:

Семантика OccurrenceSpecification - это просто след этой единственной OccurrenceSpecification.

Понимание и более глубокий смысл спецификации OccurrenceSpecification зависит от связанного сообщения и информации, которую оно передает.

(Вау!) Но потом на стр. 567:

OccurrenceSpecification - это просто синтаксические точки в конце Messages или в начале / конце ExecutionSpecification.

На самом деле OccurrenceSpecification - это просто более общая форма ExecutionOccurrenceSpecification.

Хотя рис. 17.2 использует ExecutionSpecification следующие рисунки 17.3 и т. Д., Не используйте их. Так что вы можете использовать их по своему желанию.

Точка, в которой сообщение начинается / заканчивается, всегда встречается.

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

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

Хотя часто бывает, что отправитель выполняет какое-то поведение, в ходе которого отправляется какое-то сообщение, а получатель сообщения выполняет поведение в ответ на получение сообщения, это не всегда так. Отправитель может отправить сообщение спонтанно, а получатель может проигнорировать сообщение. Даже если что-то выполняется, разработчик модели может не упоминать об этом. Диаграмма взаимодействия показывает некоторые интересные события, но ни в коем случае не требуется отображать все возможные вхождения.

Сообщение может начинаться или заканчиваться на ExecutionOccurrenceSpecification, но это также может быть просто MessageOccurrenceSpecification. ExecutionSpecification также может быть независимым от сообщения. Может быть, разработчик модели хочет выразить, что Объект что-то выполняет, не беспокоясь о каких-либо сообщениях. Можно даже определить выполняемое поведение. Однако я не нашел инструмента, поддерживающего эту обязательную функцию UML.

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