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.
Let's take a short look at the States themselves. In the editors 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 and are therefore focused in the second compartment. When the corresponding object enters the concurrent state, all initial sub-states are enabled at once (AND relation).
The following state diagrams show a few examples of this.
Initial
States and
Final
States. These indicate the beginning and end of the observed process.
Action
States. These are the particular activities of which the process consists
that have to 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
also divide the sequence but into concurrent sub-sequences, which are merged
again by Joins.
Synchronization
States. These are used in concurrent sub-sequences to synchronize producer-consumer
relations, so that a consumer can only use a resource which has been produced
in the corresponding amount.
Transitions.
Transitions are 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. In activity diagrams it is possible to model an Object Flow.
Objects are inputs or outputs of activities and are accordingly connected
by transitions to them.
Dependencies.
These are 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.