Reposted with permission from the original author
Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.com

Section 5 - Dynamic Modeling.

Interaction Diagrams.

• Interaction Diagrams are models that describe how groups of objects collaborate in some behavior. Typically an interaction diagram captures the behavior of a single use case.
• Interaction Diagrams is a generalization of two more specialized diagram types: Sequence Diagrams and Collaboration Diagrams.
• In practice the creation of interaction and class diagrams happens in parallel.
• Not every interaction diagram starts with a system event message. They can start with any message.
• The way to indicate objects that implement an interface in an interaction diagram is by specifying the implementation class as Object in the instance box. The name of the interface must be shown above the instance box.
• In an interaction diagram an active object (like a thread) may be tagged with the property {active}.
• In an interaction diagram a class of active objects that owns its own thread can be stereotyped with <<thread>>.
• An active object that owns a thread is represented within a thick box line.
• All asynchronous messages including exceptions are illustrated with a stick arrowhead.
• Exceptions are shown as messages indicated by the exception class name.
• An optional <<exception>> or <<signal>> stereotype is legal.
• Interaction diagrams must be used when you want to look at the behavior of several objects within a single use case.

Instance Syntax.

• Instance syntax is used in both Collaboration and Sequence diagrams.
• An instance is represented within a box.
• The syntax is: Instance Name:Class Name
• The designator is underlined.
• The Instance Name is optional.
• A Class is represented with a classbox with a name in it.

Message Expression Syntax.

• Message Expression syntax is used in both Collaboration and Sequence diagrams.
• The syntax is: return := message(parameter : parameterType) : returnType.
• A message is represented with an arrow between two life lines in sequence diagrams and between two objects in collaboration diagrams.
• Type information may be excluded.
• Each message is labelled at minimum with the message name.

Collaboration Diagrams.

• It is legal to use a collaboration diagram for each system event message.
• A link is a connection path between two objects; it indicates some form of navigation and visibility between the objects. A link is an instance of an association.
• Multiple messages and messages both ways can flow along the same single link.
• Each message between objects is represented with a message expression and small arrow indicating the direction. Many messages may flow along this link. A sequence number may be added to show the sequential order of messages, for example: 1:msg2()
• A message can be sent from an object to itself (this). This is illustrated by a link to itself with messages flowing along the link.
• Any message can be used to create an instance, by UML convention a message named "create" must be used. If another message name is used may be annotated with a stereotype. The "create" message may include parameters, which indicates a constructor call with parameters in Java. Furthermore a UML property {new} may optionally be added to the instance box to highlight the creation.
• The order of messages is illustrated with sequence numbers.
• The first message is not numbered.
• The order and nesting of subsequent messages is shown with a legal numbering scheme. Nesting is denoted by pre-pending the incoming message number to the outgoing message number. For example: Message 1. and the nested message 1.1
• A conditional message is shown by following a sequence number with a conditional clause in square brackets. The message is only sent if the clause evaluates to true. For example: 1[color=red]: calculate()
• When either one or another message could execute, mutually exclusive messages notation is used. A letter is appended to the sequence number, examples: 1a. The letter "a" is first used by UML convention. Nested messages are still consistently prepended with their outer message sequence, for example the message 1b.1 is nested message within 1b.b.
• Iteration or looping is indicated with a "*" and an optional iteration clause following the sequence number. For example: 1*[i:1..N]:num:=nextInt().
• The term "multiobject" is used to denote a set of instances for example a Vector. A double box indicates a multiobject.
• An iteration or looping and a "*" symbols are used together to imply iteration over the multiobject. The "*" multiplicity marker at the end of the link is used to indicate that the message is being sent to each element of the collection, rather that being repeatedly sent to the collection itself. For example: 1*:st:=getSubtotal() *.
• When a message is sent to a multiobject and there is not a multiplicity marker "*" at the end of the message means that the message is really being sent to the data structure representing the multiobject such as java.util.Vector rather than an implicit broadcast to the collection's members.
• If a message is being sent to a multiobject such as java.util.Vector then the name of the message represents the method of the multiobject's interface. Consequently is incorrect to add "addElement()" to a multiobject of type java.util.Vector.
• Messages may be sent to a Class rather than an instance to invoke class or static methods.
• A message is sent to a class box whose name is not underlinded, indicating the message is being sent to a class rather than an instance.

Sequence Diagrams.

• It is legal to use a sequence diagram for each system event message.
• System events may include parameters.
• Sequence Diagrams don't show links.
• Each message between objects is represented with a message expression on an arrowed line between the objects.
• The time ordering is organized from top to bottom.
• An "activation box" is used to show the focus of control that is in a regular blocking call the operation is on the call stack. The box is optional.
• A sequence diagram may optionally show the return from a message as a dashed open-arrowed line at the end of an activation box.
• A message can be illustrated as being sent from an object to itself (this) by using a nested activation box.
• A creation instance is notation is illustrated by sending a message to an instance box that is placed at the same level of the message not at the top of the Sequence Diagram.
• Any message can be used to create an instance, by UML convention a message named "create" must be used. If another message name is used may be annotated with a stereotype. The "create" message may include parameters, which indicates a constructor call with parameters in Java. Furthermore a UML property {new} may optionally be added to the instance box to highlight the creation.
• "Object lifelines" is illustrated by showing vertical dashed lines underneath the objects. These indicate the extent of the life of the object in the diagram. If it is desirable to show explicit destruction of an object the <<destroy>> stereotyped message with a large X and a short lifeline is used.
• Each message is represented by an arrow between the lifelines of two objects. The order in which these messages occur is shown top to bottom of the page.
• A conditional message is shown prepending a conditional clause in square brackets to the message. The message is only sent if the clause evaluates to true. For example: [color=red]:calculate().
• A mutually exclusive conditional message is illustrated with a kind of angled message line emerging from a common point.
• Iteration or looping is indicated wit a "*" and an optional iteration clause. For example: *[i:1..N]:num:=nextInt().
• Iterations are shown within a box that is used to enclose an iteration area. The * [...] is used as an iteration marker.
• The term "multiobject" is used to denote a set of instances for example a Vector. Double box indicates a multiobject.
• With collaboration diagrams the UML specifies a "*" multiplicity marker at the end of the role (next to the multiobject) to indicate sending a message to each element rather than repeatedly to the collection itself. However UML does not specify how to indicate this with sequence diagrams.
• If a message is being sent to a multiobject such as java.util.Vector then the name of the message represents the method of the multiobject's interface. Consequently is incorrect to add "addElement()" to a multiobject of type java.util.Vector.
• As in a collaboration diagram class or static method class are shown by not underlining the name of the classifier, which signifies a class object rather than an instance.
• An asynchronous message is illustrated with a half-arrowhead. An asynchronous message does not block the caller so it can carry on with its own processing. An asynchronous message can do on of three things:
  • Create a new thread.
  • Create a new object.
  • Communicate with a thread that is already running.
• Object deletion is shown with a large X. An object can be self-destructed or can be destroyed by another message.

System Sequence Diagrams.

• Is a picture that shows for a particular scenario of a use case the events that external actors generate, their order and inter-system events. All systems are treated as a black box.
• SSDs are part of the Use-Case Model.
• An SSD should be done for the main success scenario of the use case and frequent or complex alternative scenarios.
• SSDs can also be used to illustrate collaborations between systems.
• System events and their associated system operations should be expressed at the level of intent rather than in terms of the physical input medium or interface widget level.
• It is sometimes desirable to show at least fragments of the use case text for the scenario to enhance the two views.

State Diagrams.

• State diagrams describe all the possible states that a particular object can get into and how the object's state changes as result of events that reach the object.
• Usually state diagrams are drawn for a single class to show the lifetime behavior of a single object.
• An event is a significant or noteworthy occurrence.
• A state is the condition of an object at a moment in time, the time between events.
• A transition is a relationship between two states that indicates that when an event occurs the object moves from the prior state to the subsequent state.
• A UML state diagram illustrates the interesting events and states of an object and the beheavior of an object in reaction to an event.
• It is common to include an initial pseudo-state which automatically transitions to another state when the instance is created.
• A state diagram shows the lifecycle of an object: what event it experiences, its transitions and the states it is in between these events.
• A state diagram may be applied to a variety of UML elemens including, classes (conceptual or software) and use cases.
• A useful application of state diagrams is to describe the legal sequence of external system events that are recognized and handled by a system in the context of a use case.
• A use case state chart diagram is a state diagram that depicts the overall system events and their sequence within a use case.
• State Diagrams may be created for virtually any type or class or use case.
• If an object always responds the same way to an event then it is considered state-dependent with respect to that event.
• If for all events of interest an object always reacts the same way, it is a state-independent object, by contrast state-dependent objects react differently to events depending on their state.
• State diagrams must be created for state-dependent objects with complex beheavior like Use Cases, Stateful session, systems, windows, controllers, transactions, devices and role mutators.
• External Event also known as a system event is caused by something outside our system boundary.
• Internal Event is caused by something inside our system boundary.
• Temporal event is caused by the occurrence of a specific date and time or passage of time.
• Prefer using state chart diagrams to illustrate External and Temporal events (no Internal) and the reaction to them, rather than using them to design object beheavior based on internal events.
• A Transition Action is a transition that can cause an action to fire.
• A Transition Guard Condition is a transition that may also have a conditional guard or boolean test. The transition only occurs if the test passes.
• Nested States is a substate. A state allows nesting to contain substates, a substate inherits the transitions of its superstate.
• Actions are associated with transitions and are considered to be processes that occur quickly and are not interrupted.
• Activities are associated with states and can take longer. An activity may be interrupted by some event.
• When a transition has no event within its label it means that the transition occurs as soon as any activity associated with the given state is completed.
• A guard is a logical condition that will return only true or false.
• A guarded transition occurs only if the guard resolves to true.
• Only one transition can be taken out of a given state, so we intend the guards to be mutually exclusive for any event.
• A superstate encloses all the substates in a single state box and defines its name in a little square at the top.
• The substates simply inherit any transitions on the superstate.
• If a state responds to an event this can be put in text in the form eventName/actionName in the state box.
• When an event is generated after a period of time this is indicated with the keyword "after", for instance you may say after(20 minutes).
• An event can be generated when a condition becomes true. You show this with the keyword "when", for instance you could have when (temperature>100 degrees).
• There are two special events "entry" and "exit". Any action that is marked as linked to the entry event is executed whenever the given stat is entered via transition. The action associated with the exit event is executed whenever the state is left via transition.
• If there is a transition that goes back to the same state (this is called "self-transition") with an action the exit action would be executed first, then the transition's action and finally the entry action. If the state has an associated activity as well that activity is executed after the entry action.
• Concurrent state diagrams are useful when a given object has sets of independent behaviors.
• State Diagrams are good at describing the behavior of an object across several use cases. State diagrams are not very good at describing behavior that involves a number of objects collaborating.
• The syntax for a transition label has three parts all of which are optional: Event [Guard] / Action
• Activities are shown inside the class name section of the state and follows the syntax: do/activity
• States are shown in rounded rectangles.
• Concurrent state diagrams are illustrated by enclosing two state diagrams within a state box. The state box is splited by a dashed line at the middle.
• A state diagram doesn't show object interactions or collaborations.

Activity Diagrams.

• The activity diagram describes the sequencing of activities with support for both conditional and parallel behavior.
• The core symbol is the activity state or simple activity. An activity is a state of doing something either a real-world process such as typing a letter or the execution of a software routine such as a method on a class.
• Conditional behavior is delineated by branches and merges.
• A branch has a single incoming transition and several guarded outgoing transitions. Only the outgoing transitions can be taken so the guards should be mutually exclusive.
• Using [else] as a guard indicates that the "else" transition should be used if all the other guards on the branch are false.
• A merge has multiple input transitions and a single output. A merge marks the end of conditional behavior started by a branch. Diamonds are used to make the branches and merges clear in the diagram.
• Parallel behavior is indicated by forks and joins.
• A fork has one incoming transition and several outgoing transitions. When the incoming transition is triggered all of the outgoing transitions are taken in parallel.
• The diagram allows activities occur in parallel. Essentially this means that the sequence between them is irrelevant.
• A join closes a parallel transition. With a join the outgoing transition is taken only when all the states on the incoming transitions have completed their activities.
• Forks and Joins must match. This means that every time you have a fork you must have a join that joins together the threads started by that fork.
• A thread that comes out of a fork can itself fork with the new threads coming back together before reaching the matching join.
• If a thread coming out of a fork goes straight into another fork, you can remove the second fork and just have the threads from the second fork coming out of the first fork.
• An advanced construct called the synch state allows you to synchronize in places where the matching forks and joins rule would otherwise prevent you from doing so.
• You can add a condition to a thread coming out of a fork. The result is a conditional thread.
• An activity can be broken down into subactivities.
• Dynamic concurrency allows you to show iterations without having to construct a loop. The multiplicity marker (*) indicates that the activity is executed many times.
• Activity diagrams tell you what happens but they don't tell you who does what. Swimlanes are a way around this. To use swimlanes you must arrange your vertical activity diagrams into vertical zones separated by lines.
• Each zone represents the responsibilities of a particular class.
• The great strength of activity diagrams lies in the fact that they support and encourage parallel behavior.
• Activity diagrams can be used in the following situations: Analyzing a use case, Understanding workflow, Describing a complicated sequential algorithm, Dealing with multithreaded applications.
• Don't use activity diagrams in the following situations:
• Trying to see how objects collaborate,
• Trying to see how an object behaves over its time,
• Representing complex conditional logic.
• An activity diagram doesn't show objects.

Contributors:

• Ezequiel Cuellar - prime
• cfw
• SZ