Activity diagrams are created by asking what happens first, what happens second, and so on. You must determine whether activities are done in sequence or in parallel. If physical data flow diagrams (as described in Chapter “Using Data Flow Diagrams“) have been created, they may be examined to determine the sequence of activities. Look for places where decisions are made, and ask what happens for each of the decision outcomes. Activity diagrams may be created by examining all the scenarios for a use case.
Each path through the various decisions included on the use case is a different scenario. In the main path would be Logon System, Receive Web Form, Get Student Record, Display Current Student Data, Enter Changes, Validate Changes, Update Student Record, Create Change Student Journal Record, and Display Confirmation.
This isn’t the only scenario that comes from this use case. Other scenarios may occur. One possibility could be Logon System, Receive Web Form, Get Student Record, and Display Error Message. Another scenario could be Logon System, ReceiveWeb Form, Get Student Record, Display Current Student Data, Enter Changes,Validate Changes, and Display Error Message.
The swimlanes are useful to show how the data must be transmitted or converted, such as from Web to server or from server to mainframe. For example, the Change Student Record activity diagram has three swimlanes.
The swimlane on the left shows activities that occur on the client browser. Web pages must be created for these activities. The middle swimlane shows activities that happen on the server. Events, such as Form Transmitted, represent data transmitted from the browser to the server, and there must be programs on the server to receive and process the client data.
The swimlane on the right represents the mainframe computer. In large organizations it is typical for many Web applications to work with a mainframe computer. Much of the data in large organizations exists on mainframe databases and there is an enormous number of mainframe programs in existence.
When an event crosses the swimlane from the server to the mainframe computer, there must be a mechanism for transmitting the event data between the two platforms. Servers use a different format to represent data (ASCII) than do mainframe computers (they use a format called EBCDIC). Middleware must be present to take care of the conversion. IBM computers often use an mqueue (for message queue). The mqueue receives data from the server programs, places it in a holding area, and calls a mainframe program, usually written in a language called CICS. This program retrieves or updates the data, and sends the results back to the mqueue.
In the example activity diagram shown, the decision below the Get Student Record state is made on the mainframe computer. This means that the message queue receives either a “Not Found” message or the database record for the student. If the mainframe simply placed the Record Status Received in the message queue and the decision was evaluated on the server, the server would have to call the mainframe again to obtain the valid data. This would slow down the response to the person waiting at the browser.
Swimlanes also help to divide up the tasks in a team. Web designers would be needed for the Web pages displayed on the client browser. Other members would work with programming languages, such as Java, PHP, Ruby on Rails, PERL, or .NET, on the server. Mainframe CICS programmers would write programs that would work with the message queue. The analyst must ensure that the data that the various team members need is available and correctly defined. Sometimes the data in the message queue is an XML document. If an outside organization is involved, the data also might be an XML document.
The activity diagram provides a map of a use case, and allows the analyst to experiment with moving portions of the design to different platforms and ask “What if?” for a variety of decisions. The use of unique symbols and swimlanes makes this diagram one that people want to use to communicate with others.
Activity diagrams may be used to construct test plans. Each event must be tested to see whether the activity diagram goes to the next state. Each decision must be tested to see whether the correct path is taken when the decision conditions occur.
Activity diagrams are not used for all use cases. Use the activity diagram when:
- It helps to understand the activities of a use case.
- The flow of control is complex.
- There is a need to model workflow.
- All scenarios need to be shown.
The analyst would not need an activity diagram when the use case is simple or there is a need to model the change of state.
Activity diagrams may also be used to model a lower-level method, showing detailed logic.
Repository Entries for an Activity Diagram
Each state and event may be further defined using a text description in a repository, which is a collection of text descriptions for the project. Describe states with information about the state, such as the Web page name, elements on the Web page, and so on. Describe events with the information that is required to communicate with the next state, such as the data from the Web form, the data that is put into a message queue, or with a description of the event that caused the transition, such as a button click.
