They are in the sequential order on the lifeline. The messages depict the interaction between the objects and are represented by arrows. It describes that time period in which an operation is performed by an element, such that the top and the bottom of the rectangle is associated with the initiation and the completion time, each respectively. It is represented by a thin rectangle on the lifeline. Several distinct roles can be played by an actor or vice versa. An actor may or may not represent a physical entity, but it purely depicts the role of an entity. It represents the role, which involves human users and external hardware or subjects. ActorĪ role played by an entity that interacts with the subject is called as an actor. It is positioned at the top of the diagram. It either models generic interactions or some certain instances of interaction.Īn individual participant in the sequence diagram is represented by a lifeline. To model interaction among objects inside a collaboration realizing a use case.To model high-level interaction among active objects within a system.It incorporates the iterations as well as branching. In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented by a vertical dotted line that extends across the bottom of the page. It portrays the communication between any two lifelines as a time-ordered sequence of events, such that these lifelines took part at the run time. It helps in envisioning several dynamic scenarios. And of course the current behaviour very likely is quite useful for many use cases.The sequence diagram represents the flow of messages in the system and is also termed as an event diagram. Seen as a 2-dimensional document such rendering appears more confusing to me than if logic ('alt' statements) was rendered close to those objects it actually belongs to. The (still simplified) example below renders all 'alt' statements as horizontally global. In complex documentations as well as in complex source code I'd like to see related artifacts show up as close as possible (as long as useful). Programming books and articles such as the linked one rarely present examples of a complexity where documentation gets its relevance just because of the complexity. Note over C: proposal: allow 'dashed' arrows to cross for the reply. Note over C: How could I let those arrows *cross* the border\nof that 'alt' block instead of enlarging it ? 7 participants all calling each other\nconditioned by 'alt' conditions:\nall 'alt' blocks become 'global': what a mess ! Note over C: this simplified example still looks pretty\nnow think of e.g. Note over C: reason (my guess): the arrows between B,C and D Note over C: but the logic appears all over B,C and D Note over B: the alt block visually includes B\nbut B is not part of the logic\n -> bad!Īlt this alt logic is coded exclusively in 'C' Note over C: some if-else logic in C should be horizontally limited to its scope: 'C' Is there any way to control the horizontal size of such 'alt' blocks ? I now kind of adapt the logic I want to document just in order to get my diagrams, which is of course not what documentation should do. Unfortunately that makes the diagram unreadable. Since routines may have multiple calls to other participants and as well have more than one return statement my 'alt' blocks are printed much bigger than I'd like to see: they include all participants called from within the 'alt' and all callers being returned to from within the 'alt' block. Unfortunately the size of these alt blocks seems to be determined as well by all arrows within an 'alt' and its closing 'end' statement. It appears essential that within 'participants' some logic needs to be expressed.Ĭurrently I am using 'alt'. I am about to document quite some procedures using sequence diagrams.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |