Information Analysis:Activity diagrams
8.8 Activity diagrams
An activity diagram, at the conceptual level, shows a set of tasks that need to be accomplished to achieve a business outcome. Activity diagrams are useful for modeling business processes and work flows, especially where there is parallel activity and interaction between different actors.
In an activity diagram an activity is represented by a rectangle with rounded corners. Arrows are used to show sequential activities, such as 'receive ticket orders' and 'check ticket order details' (figure 8.22). Although activity diagrams look like flow charts they are, more formally, extended state diagrams. Once the activity 'receive ticket orders' completes a state change takes place (this could be written against the arrow coming out of the activity box): the process is now in the state 'ticket order received'. The completion of the activity also triggers the next activity; this is a multiple activity (indicated by an asterisk) that involves the box office clerk checking each line of the ticket order to see if all of the information needed has been provided (e.g., performance time) and whether it is valid. The allocation of seats leads to a synchronization bar, in this case a fork. If there are insufficient seats available for a performance then the request is put on the wait list. In parallel to allocating seats the payment is checked. The diamond is a control condition indicating that a decision is taken. If all goes well, all the requests for seats are satisfied, payment is authorized and the tickets are dispatched. If not, then the order is held pending seats becoming re-available. Ticket returns are received by the box office clerk and the box office manager allocated the returned tickets to those on the wait list.
A particularly useful aspect of activity diagrams is the swim lane notation. These are vertical lines that show not only what is done, but who does it. For complex business processes there will be multiple interactions between actors (classes, people, departments, computer systems, etc.) to achieve a business process outcome. The activity diagram might be for a single use case, such as 'perform operator ticket sale', or it might span a number of use cases (this activity diagram also includes the use case 'process ticket return').
Summary
• UML use cases are used to model the information requirements from the user, or business, perspective.
• Class diagrams are used to model the data structures of the information system and their behaviours (operations).
• The interactions between structural objects are modeled using interaction diagrams (sequence and collaboration).
• The internal states and state transitions of a structural class are modeled with state transition diagrams.
• Business proces
• Business processes are modeled using activity diagrams to show how business areas interact.
Exercises
1. Develop use cases for the current research student admission application (appendix B) taking into account the needs of applicants, administrators, academic supervisors, the research director, and interfacing information systems.
2. Develop a range of scenarios for how the admissions business process could be transformed through the novel use of the Internet and other communication technologies.
3. Develop use cases for your proposed research student admission application.
4. Draw an activity diagram with swim lanes showing how the various parties would work together to process research applications.
5. Develop a class diagram to meet the data requirements of the proposed research student admissions application. Show how one of the use cases can be satisfied by the classes and operations in the class diagram by developing a sequence diagram and a collaboration diagram.
6. Which class is central to the admissions application? Model the state transitions of this class.
Further reading
Alexander, C., (1964). Notes on the Synthesis of Form. Harvard University Press,Cambridge, MA.
Booch, G., (1994). Object-Oriented Design with Applications. Second edition. Benjamin Cummings, Redwood City, CA.
Booch, G., Rumbaugh, J. and Jacobson, I., (1999). The Unified Modeling Language. Addison Wesley, Reading MA.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W., (1991).Object-Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs, New Jersey.
Jacobson, I., Ericsson, M., and Jacobson, A., (1994). The Object Advantage:business process reengineering with object technology. Addison-Wesley.
Comments
Post a Comment