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

# State 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-4. 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

Prev | Home | Next
Activity Diagrams | Up | Sequence Diagrams