Information Analysis:Activity diagrams

By -
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').

Developing Web Information Systems-0089

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

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However
Read more