Essentially, this means that the sequence between them is irrelevant. The diagram says that these activities can occur in parallel. Thus, in Figure 9-1, after you receive an order, you fill the order and send the invoice in parallel. When the incoming transition is triggered, all of the outgoing transitions are taken in parallel. Parallel behavior is indicated by forks and joins.Ī fork has one incoming transition and several outgoing transitions. Use diamonds if you want to make the branches and merges clear in the diagram.
An activity state, like any state, can have multiple guarded output transitions and multiple input transitions. You don't have to show the explicit diamond for branches and merges. A merge marks the end of conditional behavior started by a branch. If you have a rush order, you do an overnight delivery otherwise, you do a regular delivery.Ī merge has multiple input transitions and a single output. In Figure 9-1, after an order is filled, there is a branch. Using as a guard indicates that the "else" transition should be used if all the other guards on the branch are false. Only one of the outgoing transitions can be taken, so the guards should be mutually exclusive. Thus, much of the terminology follows that of state diagrams.Ĭonditional behavior is delineated by branches and merges.Ī branch has a single incoming transition and several guarded outgoing transitions. An activity diagram is a variant of a state diagram in which most, if not all, the states are activity states. The activity diagram describes the sequencing of activities, with support for both conditional and parallel behavior.
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. In Figure 9-1, the core symbol is the activity state, or simply activity. The reason is that they are one of the least understood areas of the UML, and current UML books are particularly lacking in discussing them. I'm going to describe activity diagrams in more detail than they really warrant in this short book. These diagrams are particularly useful in connection with workflow and in describing behavior that has a lot of parallel processing. Rather, the activity diagram combines ideas from several techniques: the event diagrams of Jim Odell, SDL state modeling techniques, workflow modeling, and Petri nets. Unlike most other techniques in the UML, the activity diagram doesn't have clear origins in the previous works of the three amigos.
Activity diagrams are one of most unexpected parts of the UML.