Activity Diagrams

Activity Diagrams

Jane mentioned in an earlier meeting that the BandSpy application will need to hook into two other third-party systems the ticketing system and the venue reservation system when a new performance is added. To understand the order of events necessary to accomplish this task, you can draw an activity diagram. Activity diagrams are good in any situation when you need to understand the flow of activities going on within a use case. In this example, the use case is the BandSpy administrator booking a performance.

Further conversations with Jane reveal that the BandSpy system will not only have to send a message to the venue reservation system, but will need to receive information back from both systems. The venue system will send a confirmation that the venue is available, and the ticking system will transmit ticking information such as pricing. If the administrator attempts to book a venue on a date or time that is not available, the venue system will indicate that fact to BandSpy, and the administrator will be notified and may try to book another date.

Figure 2-10 shows the activity diagram for the process described previously. Activity diagrams begin with a solid black circle called the starting point. From there the flow of the process follows the arrows, known as transitions, into rounded rectangles representing activities.


Figure 2-10

A black hollow diamond indicates a decision point. As the name suggests, the flow of transitions is split, based on some decision or condition. In the diagram, the decision is whether the venue is available on the requested date.

After the decision, a large black bar called a fork splits the flow to two different activities. In the venue system, a confirmation is generated and will be sent back to the BandSpy system, where the ticket system is fired up to start generating tickets for the event. Both the ticket and venue systems information are sent back to BandSpy where they meet up in another black bar called a join. The join indicates that both external systems messages must reach the join for the activity diagram to proceed to its final step, storing and updating information about the new performance.

The three large rectangles dividing the activities particular to each system are called swimlanes. Although swimlanes are not mandatory, they often help to clarify the diagram when multiple systems are involved.



Professional PHP5 (Programmer to Programmer Series)
Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 182
BUY ON AMAZON

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net