Information Analysis:Interaction diagrams

By -
8.6 Interaction diagrams

There are two types of interaction diagram in UML: the sequence diagram and the collaboration diagram.

8.6.1 Sequence diagram

The sequence diagram models the collaboration between objects and actors, showing the exchange of messages needed to accomplish a specific purpose. Typically, a sequence diagram is prepared to represent a single use case. As with class diagrams, sequence diagrams are elaborated throughout the development process with design detail. At the conceptual level the sequence diagram should be consistent with the use case and the conceptual class model.

Figure 8.16 is a sequence diagram for the use case 'Internet ticket sale'. The dashed vertical line represents an object's lifeline, with time moving from the top of the diagram to the bottom. Objects are spread out across the page. Note that the class name is shown after a colon – this indicates that we are referring to an instance of the class, a particular production or performance rather than the class itself. Arrows represent the passing of messages from object to object. When a message is sent to an object it invokes an operation supported by that object's interface. The period of time that the operation is active is shown by a rectangle on the object's lifeline.

Developing Web Information Systems-0083

In figure 8.16 the collaboration begins with the Internet user finding a production. The production responds to the user by returning the details of the selected production (the return message is not shown, although it can be where it aids understanding). The user then requests a list of performances for the production by invoking the listPerformances() operation of the production object. The production object satisfies the request by sending the message [for all of the production's performances] getPerformanceDetails(). The iteration is shown by an asterisk. The Internet user then finds the prices for the different parts of the theatre by sending a message to the theatre. The next stage of the process is to find available seats.

Developing Web Information Systems-0084

In the second part of the Internet ticket sale use case (figure 8.17) the sequence is to check for an existing customer (and add a new one if needed), to check if the customer is due a discount on the price as a member, take payment and write the transaction, and finally to change the seat at performance status to booked. Note that instances are created for new customers and for the transaction class. The creation is shown at the point in the timeline they are created.

Separating the use case into two parts is rather useful since the find seats and book seats parts of the use case could be reused. As well as creating new objects, a message might invoke the destruction of an object. In the use case 'cancel performance' the performance object then sends messages to invoke the object destruction operation for the seats at performance associated with that performance object (figure 8.18). The performance then sends a message to itself (reflexive) to destroy the performance instance.

Developing Web Information Systems-0085

8.6.2 Collaboration diagram

Collaboration diagrams are the second interaction modeling technique in the UML. They are strongly linked to sequence diagrams. Again, arrows show messages, but in the collaboration diagram numbers are used to show the sequence of messaging.

Both forms of interaction diagram show collaboration between objects. From an analysis and conceptual modeling perspective it is probably sufficient to prepare a sequence diagram. As the diagrams are refined for design purposes then the collaboration diagram becomes more useful, allowing packages of processing to be identified from clusters of interactions. We have introduced some conditional behaviour into the second part of the sequence diagram (figure 8.17) to branch for customers who are members. As more conditional processing is added the interaction diagrams get more and more convoluted and it is wise to consider developing different diagrams for different scenarios, e.g., 'Internet ticket purchase by member' and 'Internet ticket purchase by nonmember'.

Developing Web Information Systems-0086

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

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more