Sequence diagrams

5.2.2 Sequence diagrams

Sequence diagrams in the UML are primarily used to model the interactions between the actors and the objects in a system and the interactions between the objects them- selves. The UML has a rich syntax for sequence diagrams, which allows many dif- ferent kinds of interaction to be modeled. I don’t have space to cover all possibilities here so I focus on the basics of this diagram type.

As the name implies, a sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. Figure 5.6 is an example of a sequence diagram that illustrates the basics of the notation. This diagram models the interactions involved in the View patient information use case, where a medical receptionist can see some patient information.

The objects and actors involved are listed along the top of the diagram, with a dot- ted line drawn vertically from these. Interactions between objects are indicated by annotated arrows. The rectangle on the dotted lines indicates the lifeline of the object concerned (i.e., the time that object instance is involved in the computation). You read the sequence of interactions from top to bottom. The annotations on the arrows indicate the calls to the objects, their parameters, and the return values. In this exam- ple, I also show the notation used to denote alternatives. A box named alt is used with the conditions indicated in square brackets.

You can read Figure 5.6 as follows:

1. The medical receptionist triggers the ViewInfo method in an instance P of the PatientInfo object class, supplying the patient’s identifier, PID. P is a user inter- face object, which is displayed as a form showing patient information.

2. The instance P calls the database to return the information required, supplying the receptionist’s identifier to allow security checking (at this stage, we do not care where this UID comes from).

5.2 ■ Interaction models 127

Medical Receptionist

P: PatientInfo

D: MHCPMS-DB

AS: Authorization

ViewInfo (PID)

Report (Info, PID, UID)

Authorize (Info, UID)

Authorization

Alt [Authorization OK]

Patient Info

[Authorization Fail]

Error (No Access)

Figure 5.6 Sequence diagram for View patient information

3. The database checks with an authorization system that the user is authorized for this action.

4. If authorized, the patient information is returned and a form on the user’s screen is filled in. If authorization fails, then an error message is returned.

Figure 5.7 is a second example of a sequence diagram from the same system that illustrates two additional features. These are the direct communication between the actors in the system and the creation of objects as part of a sequence of operations. In this example, an object of type Summary is created to hold the summary data that is to

be uploaded to the PRS (patient record system). You can read this diagram as follows:

1. The receptionist logs on to the PRS.

2. There are two options available. These allow the direct transfer of updated patient information to the PRS and the transfer of summary health data from the MHC-PMS to the PRS.

3. In each case, the receptionist’s permissions are checked using the authorization system.

4. Personal information may be transferred directly from the user interface object to the PRS. Alternatively, a summary record may be created from the database and that record is then transferred.

5. On completion of the transfer, the PRS issues a status message and the user logs off.

128 Chapter 5 ■ System modeling

Medical Receptionist PRS

P: PatientInfo

D: MHCPMS-DB

AS: Authorization

Login ( ) OK

Alt [SendInfo] UpdateInfo( )

Update PRS (UID ) Authorize (TF, UID)

Authorization

Update (PID) Update OK

Message (OK)

[SendSummary] UpdateSummary( )

Summarize (UID ) Authorize (TF, UID) Authorization

:Summary Update (PID)

Update OK

Message (OK)

Logout ( )

Unless you are using sequence diagrams for code generation or detailed docu-

Figure 5.7 Sequence

diagram for transfer

mentation, you don’t have to include every interaction in these diagrams. If you

data

develop system models early in the development process to support requirements engineering and high-level design, there will be many interactions which depend on implementation decisions. For example, in Figure 5.7 the decision on how to get the user’s identifier to check authorization is one that can be delayed. In an implementa- tion, this might involve interacting with a User object but this is not important at this stage and so need not be included in the sequence diagram.

5.3 ■ Structural models 129

Object-oriented requirements analysis In object-oriented requirements analysis, you model real-world entities using object classes. You may create

different types of object model, showing how object classes are related to each other, how objects are aggregated to form other objects, how objects interact with other objects, and so on. These each present unique information about the system that is being specified.

http://www.SoftwareEngineering-9.com/Web/OORA/