An interaction can use another interaction to describe the internal interactions of one of its lifelines this enables a black-box specification style. Interactions can use other interactions as part of their definition to enhance scalability. Each operand may have a guard expression that must be satisfied in order for the operand to be executed. Commonly used operators include par, alt, and loop. A combined fragment includes an operator and operands the operator identifies the ordering of its operands, which may themselves be combined fragments. A combined fragment is a means for specifying different ordering semantics. The default ordering of occurrences imposed by an interaction is weak sequencing, in which unrelated occurrences are sequenced within but not across lifelines. Messages are sent and received by behaviors executing on the lifelines and can be either asynchronous (sender continues executing) or synchronous (sender waits for a response). Messages do not represent data flows, but the flow of data (or other items such as matter or energy) can be captured via arguments of the message. Messages are exchanged between lifelines and typically represent an invocation of an operation or a sending of a signal.
State invariants on the lifelines assert conditions that must hold at that point in the interaction’s execution for the current trace to be valid. Lifelines may be physically nested on a diagram to show a white-box view of the interactions within that lifeline. They also may start and/or end within the sequence diagram, indicating the creation or destruction of instances during execution of the interaction. Lifelines may run from the top to the bottom of a sequence diagram, indicating that the parts they represent exist before and after the execution of the interaction. During execution, a lifeline may represent only one instance so when the part has an upper bound greater than 1, an additional selector expression is required to specify exactly one of all the instances that may be represented by the part. Lifelines represent parts (or references) of the block that owns the interaction. The following list highlights key aspects of interactions: The most significant source of occurrences is the exchange of messages between lifelines, which may trigger executions. When an interaction executes, it evaluates the set of event occurrences generated by instances of its lifelines and determines whether they are valid. An interaction is specified using occurrence specifications, which are organized into a hierarchy, and ordered by interaction operators. Sequence diagrams describe interactions, which are used to capture system scenarios as a set of specified occurrences across several parts of the system, represented by lifelines. At the same time, such a transformation may be used for a formalization of Sequence Diagrams in UML since MSC has a formal semantics based on process algebra. Such a transformation demonstrates the big advantage of MSC concerning composition mechanisms, particularly, in comparison with the rather obscuring branching constructs in Sequence Diagrams. It is argued that Sequence Diagrams can be transformed into MSC diagrams if some enhancements of MSC are introduced. In this context, it has to be noted that the acceptance of a language in the OO community essentially depends on a clear visualization of constructs typical for OO modelling. On the other hand, the application area of MSC might be considerably enlarged. A more formal and powerful notation for Sequence Diagrams may arise, on the one hand. Both notations would benefit from a harmonization. They can be seen as OO variants of the ITU-T standard language Message Sequence Chart (MSC) which is very popular mainly in the telecommunication area.
#Loop in sequence diagram software
Sequence Diagrams as part of UML play an important role within use case driven object oriented (OO) software engineering.
0 kommentar(er)
