Poseidon for UML: User Guide
Prev | Chapter 10. Diagram Reference | Next

# Behavioral Diagrams

Behavioral diagrams are used to show the functionality of the system and include Use Case, Sequence, Collaboration, Statechart, and Activity diagrams.

Poseidon limits the inclusion of certain elements to only one instance in one behavioral diagram. As a result of this policy, the context menu option 'Add to Diagram' may be greyed out when a behavioral diagram is active and the selected element has already been represented in one of these diagrams.

## Use Case Diagrams

The first diagram to look at is the Use Case diagram. The main ingredients for this type of diagram are use cases and actors, together they define the roles that users can play within a system. They are associated to the tasks, or use cases, they are involved in. It is often used in early stages of the design process to collect the intention requirements of a project.

If you are not well-acquainted with UML yet, remember that a use case is not just a bubble noted in the diagram. Along with this bubble, there should be a description of the use case, a typical scenario, exceptional cases, preconditions etc. These can either be expressed in external texts using regular text processing tools, requirements tools or file cards. It can be and is often refined using other diagrams like a sequence diagram or an activity diagram that explain its main scenarios. The basic description of a use case can also be inserted in the Documentation tab of the Details pane.

Figure 10-4. A Use Case diagram.

Extension points can be added to a use case via the extension point button in the Details pane or via the extension point rapid button.

### Diagram Elements

- Actors - Also referred to as Roles. Name and stereotype of an actor can be changed in its Properties tab.

- Inheritance - Refinement relations between actors. This relation can carry a name and a stereotype.

- Use cases - These can have Extension Points.

- Extension Points - This defines a location where an extension can be added.

- Associations - Between roles and use cases. It is useful to give associations speaking names.

- Dependencies - Between use cases. Dependencies often have a stereotype to better define the role of the dependency. To select a stereotype, select the dependency from the diagram or the Navigation pane, then change the stereotype in the Properties tab. There are two special kinds of dependencies: <<extend>> and <<include>>, for which Poseidon offers own buttons (see below).

- Extend relationship - A uni-directional relationship between two use cases. An extend relationship between use case B and use case A means that the behavior of B can be included in A.

- Include relationship - A uni-directional relationship between two use cases. Such a relationship between use cases A and B means, that the behavior of B is always included in A.

- System border - The system border is actually not implemented as model element in Poseidon for UML. You can simply draw a rectangle, send it to the background and use it as system border by putting all corresponding use cases inside the rectangle.

### Toolbar

| Select
| Package
| Actor
| Actor as Classifier
| Use Case
| Generalization
| Dependency
| Association
| Directed Association
| Include
| Extend
| Collaboration
| Classifier Role
| Comment
| Connect Comment to Element
| Text
| Ellipse
| Rectangle
| Polygon
| Polyline
| Repaint

## Sequence Diagrams

A sequence diagram is an easily comprehensible visualization of single scenarios or examples of business processes with regard to their behavior in time. It focuses on when the individual objects interact with each other during execution. The diagram essentially includes a timeline that flows from the top to the bottom of the diagram and is displayed as a dotted line. The interaction between objects is described by specifying the different kinds of messages sent between them. Messages are called stimuli. They are displayed as arrows; the diverse arrowheads stand for different kinds of messages (see below).

The following diagram shows a typical example:

Figure 10-5. A Sequence diagram.

Objects

After creating or changing objects, they are automatically arranged in the Diagram pane. You can specify which of the objects is to have control by enabling the corresponding check box 'Focus of control' in the Properties tab. Afterwards, you'll see how the graphical representation of this object changes: it gets a thick border and its lifeline is no longer a dashed line but a solid rectangular area.

Self messages

In Poseidon, all stimulus types, except create stimuli, can be created as self stimuli. In the case of a stimulus to itself, the arrow starts and finishes on the object's lifeline. A self stimulus is created by dropping the stimulus target point on the source object.

Selecting an operation

A call stimulus is regarded as a procedure call and can be connected with any operation provided by the receiving object, depending on its type. This is achieved by connecting the stimulus with an action that will cause the class operation to be called. The following two figures show an example for selecting an operation and attaching actual arguments to the call.

Figure 10-6. Selecting the action of a stimulus in a sequence diagram.

After selecting the stimulus in the diagram, the Details pane shows the properties of the stimulus. It is there that you have to open the dispatched action field displayed in the Details pane, which is directly below the name field of the stimulus. This causes the Details pane to change the view to the properties of the action.

Figure 10-7. Selecting an operation and attaching arguments to it.

The properties of the action allow you to select an operation and edit the arguments attached to the procedure call. The set of possible operations includes all operations of the receiving object's class, as well as any operations inherited from direct and indirect superclasses or interfaces. If an operation is selected, the name of the action is updated according to the name of the operation and the given values of the arguments. An empty argument value is displayed as an 'x'. Keep in mind that you cannot edit the name field while an operation is selected.

Activations

An activation shows the period of time during which an object will perform an action, either directly or through a subordinate procedure. It is represented as a tall thin rectangle with the top aligned with its point of initiation and the bottom aligned with its point of completion.

Now, let's consider how Poseidon deals with starting and terminating activations. When an object receives a stimulus, an activation is created that starts at the tip of the incoming arrow. When an object sends a stimulus, an existing activation is terminated at the tail of the outgoing arrow. There are two exceptions: First, an outgoing send stimulus does not terminate an existing activation, because it represents an asynchronous message. Second, if an object has explicitly set the focus of control, its activation will continue during the whole lifetime.

### Diagram Elements

- Objects - Elements responsible for sending and receiving messages.

- Call stimuli - Represents a synchronous message, which means that it is regarded as a procedure call.

- Send stimuli - Illustrates an asynchronous message, which means that it is regarded as a signal. As such, the sender doesn't wait for an answer from the receiver.

- Return stimuli - Represents the return statement of a call stimulus.

- Create stimuli - Used to create a new object at a certain point in the sequence. The created object will then be placed at this specific point and not at the top of the Diagram pane.

- Destroy stimuli - Used to destroy an object at a specific point in the sequence. The lifeline of the destroyed object will then end with a cross at this point and not at the bottom of the Diagram pane.

### Toolbar

| Select
| Object
| Call Stimulus
| Create Stimulus
| Destroy Stimulus
| Send Stimulus
| Return Stimulus
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

## Collaboration Diagrams

Collaboration diagrams are another means for representing the interactions and relationships between objects. Unlike sequence diagrams, however, they do not focus on the timeline of interaction, but on the structural connections between collaborating objects. Of central interest are the messages and their intent, when creating a collaboration diagram. The chronological order of messages is represented by numbers preceding each message.

### Diagram Elements

- Objects - In collaborations, objects represent different roles - these are specified as Classifier Roles in Poseidon for UML.

- Associations - Associations illustrate the connections between collaborating objects. Messages are then placed along them.

- Messages - Just like in sequence diagrams, messages are used to describe the interaction between objects. The numbers in front of the given names represent the chronological order of messages. Using the corresponding buttons in the toolbar of the Properties tab, you can specify an action for the message, and you can change the direction of the message .

### Toolbar

| Select
| Object
| Link
| Call Stimulus
| Create Stimulus
| Destroy Stimulus
| Send Stimulus
| Return Stimulus
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

## Statechart Diagrams

Business process models do not lend themselves to implementation in an object-oriented way. If you go the UML way, you will break down the business process and express it in terms of states for each object involved in the process. State diagrams are used to illustrate the possible states of an object and the causes and effects of those state changes within the object.

Let's take a short look at the States themselves. In the diagram toolbar you find three different symbols:

- State

  In a state diagram, each state has at least two compartments, the top one always keeping the name of the state. The name usually is an adjective describing the recent object.

  The states properties are a lot more meaningful and complex than they are in the activity diagrams. Not only does a state have ingoing and outgoing transitions, but also different actions or activities that are to be taken with it.

- Composite State

  Composite States make visual use of the second compartment that encloses refinements of the given state. Enclosed states don't have to have an initial state. Ingoing as well as outgoing transitions might be connected directly to one of them. When the corresponding object is in the composite state, it is exactly in one of the sub-states (OR relation).

  If you find yourself needing to change a simple state to a composite state, you have to delete the former and again add the new state via the toolbar.

- Concurrent State

  Concurrent States are, like the above, refinements; therefore, they are focused in the second compartment. When the corresponding object enters the concurrent state, all initial sub-states all are enabled at once (AND relation).

Figure 10-8. A State diagram

Editing States

Actions and activities are added from within the state's Property tab using the 'Add' button. Whenever you add an action or activity, Poseidon will automatically navigate to the new element. Upon return to the parent element, the 'Add' button will no longer be visible, rather it will be the 'Delete' button, indicating that the element has been successfully added.

To remove an existing element, use the 'Delete' button. Note that this will delete the element entirely from the model.

Some items within the Property tab will appear in blue - these are in effect hyperlinks to the element. Clicking on them will navigate to the element named.

Editing Actions and Activities

Actions and Activities are elements in themselves, just like any other part of the model. As such, editing them is done in the same way as any other element - just like an attribute is a part of a class.

For more information about the specific fields, see the Element section the Section called States in Chapter 12.

### Diagram Elements

- Initial States and Final States - Indicate the beginning and end of the observed process.

- Action States - Specific activities which comprise the process. They must be executed in a specified chronological order. Sometimes you may want to split the sequence. Therefore, you have two different possibilities: Branches (choice) and Forks (concurrency).

- Branches - These divide the sequence into several alternatives specified by different conditions (guards).

- Forks and Joins - Forks divide the sequence into concurrent sub-sequences. Joins merge the sub-sequences.

- Synchronization States - Used in concurrent sub-sequences to synchronize producer-consumer relations.

- Transitions - The ingredient that keep states active and the model elements together. Each transition can be given guards , triggers , and actions as properties to describe its behavioral details.

- Object Flow States - Objects are inputs or outputs of activities and are accordingly connected by transitions to them.

- Dependencies - Always possible between any model elements.

- Choices and Junctions - Both elements are used in sequential systems to define decision points. The difference between them is that choices are dynamic and junctions are static.

- Shallow History and Deep History - History states are used to memorize past active states so that you can return to a marked point and don't have to start again from the beginning. A deep history allows you to return from any sub-state, whereas a shallow one only remembers the initial state of a composite state.

### Toolbar

| Select
| Simple State
| Composite State
| Concurrent State
| Transition
| Initial State
| Final State
| Synchronization State
| Deep History
| Shallow History
| Choice
| Junction
| Fork
| Join
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

## Activity Diagrams

Activity diagrams are often used to model business processes. They simply and quite plainly show how things work, and so function as a good aid to discussions of aspects of the workflow with the domain experts. These are less abstract than the often used object-oriented state diagrams.

The following example shows an activity diagram that depicts the rules and the process of paying an order. In the following example, `Softsale` will not accept an order if you have overdue payments open, will only allow payment by invoice if your e-mail and home address have been verified, and a few other rules. Take a closer look for yourself in order to become more familiar with the notation.

Figure 10-9. An Activity diagram.

### Diagram Elements

- Initial States and Final States - Indicate the beginning and end of the observed process.

- Action States - Specific activities which comprise the process. They must be executed in a specified chronological order. Sometimes you may want to split the sequence; therefore, you have two different possibilities: Branches (choice) and Forks (concurrency).

- Branches - These divide the sequence into several alternatives specified by different conditions (guards).

- Forks and Joins - Forks divide the sequence into concurrent sub-sequences. Joins merge the sub-sequences.

- Synchronization States - Used in concurrent sub-sequences to synchronize producer-consumer relations.

- Transitions - The ingredient that keep states active and the model elements together. Each transition can be given guards , triggers , and actions as properties to describe its behavioral details.

- Object Flow States - Objects are inputs or outputs of activities and are accordingly connected by transitions to them.

- Dependencies - Always possible between any model elements.

### Toolbar

| Select
| Action State
| Object Flow State
| Transition
| Initial State
| Final State
| Synchronization State
| Branch
| Fork
| Join
| Note
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

Prev | Home | Next
Diagram Reference | Up | Using Diagrams