Create simplified UML Sequence diagram type and palette

[planger]

The UML Sequence diagram shall include the UML concepts listed below. This includes adapting the palette.

• [ ] OccurrenceSpecification
• [ ] Executation Specification
• [ ] Interaction
• [ ] Action Execution Specification
• [ ] Comment
• [ ] Interaction Use
• [ ] Lifeline
• [ ] Message Async
• [ ] Message Sync
• [ ] Message Occurence Specification
• [ ] MessageSort
• [ ] MessageEnd
• [ ] CallEvent
• [ ] SignalEvent
• [ ] OpaqueBehavior
• [ ] Link

[cdamus]

@planger Some clarification is needed.

• messages mentioned are only "sync" and "async". However, these are not real message sorts. Rather, there are sync and async calls and async signals. Also, what about replies? Create and delete messages?
• MessageEnd is abstract; we support message occurrence specifications implicitly by support for drawing messages, and we don't support gates, which are the only other kind of message end. Gates are excluded, correct?
• Does "MessageSort" indicate requirement to support all message sorts? Because it's an enumeration type for an attribute of a message, not a tool ...
• are lost and found messages excluded? (I think they should be)
• are constraints excluded? (the kind supported in other diagrams; I would recommend against including time and duration constraints anyways)I just want to confirm the intent. I think it makes sense to exclude plain constraints because I'm not sure they're useful (time/duration constraints are useful) and we're excluding StateInvariant which encapsulates the only really useful application of a constraint
• what is meant by support for CallEvent and SignalEvent? These don't actually appear in the sequence diagram anyways, except maybe indirectly via time/duration observations, which we aren't including in the UML Light

[planger]

@planger Some clarification is needed.

• messages mentioned are only "sync" and "async". However, these are not real message sorts. Rather, there are sync and async calls and async signals. Also, what about replies? Create and delete messages?

Right, for now I'd include both calls and signals, as well as replies, but not create and delete messages. But we'll have to clarify this with the stakeholders. I'll put a question tag on this issue.

• MessageEnd is abstract; we support message occurrence specifications implicitly by support for drawing messages, and we don't support gates, which are the only other kind of message end. Gates are excluded, correct?

That's correct. I'd only implicitly include message occurrence specs.

• Does "MessageSort" indicate requirement to support all message sorts? Because it's an enumeration type for an attribute of a message, not a tool ...

Not sure, we'll have to clarify. I'd ignore that this is in the list for now, as it doesn't make a lot of sense, as you say. I don't think it was meant to indicate that all message sorts shall be included.

• are lost and found messages excluded? (I think they should be)

Yes, they are excluded.

• are constraints excluded? (the kind supported in other diagrams; I would recommend against including time and duration constraints anyways)I just want to confirm the intent. I think it makes sense to exclude plain constraints because I'm not sure they're useful (time/duration constraints are useful) and we're excluding StateInvariant which encapsulates the only really useful application of a constraint

I completely agree.

• what is meant by support for CallEvent and SignalEvent? These don't actually appear in the sequence diagram anyways, except maybe indirectly via time/duration observations, which we aren't including in the UML Light

Right, I'd ignore that those are in the list for now.

[cdamus]

Thanks, @planger. This helps much. As for async signal messages, I think we had best exclude them because we don't support signals and receptions in the class modeling, so there's no signal structure to reference.