Information for use case descriptions is primarily derived from system sequence diagrams.

Model consistency

Interaction diagrams bring together many existing models and modelling elements: from the use case model, the use cases, the actors, use case scenarios and descriptions; from the class diagram, the objects involved in each scenario and the operations on classes. A good CASE tool (see Chapter 1) will support model consistency by allowing the developer to link the objects on the interaction diagram to a list of classes it knows about from the class diagram. Similarly, it allows the developer to choose a label for the message arrow from a list of operations defined on the target object's class. Figure 6.15 shows a CASE tool offering a choice of operations (findBike() and getCharges()) for message number 2. The operations findBike() and getCharges() are defined on the class Bike in the class diagram.

Sequence diagrams are also useful for checking existing models; we may find, when doing the sequence diagrams, that we need an extra operation, or that we never use one that we did specify. A good CASE tool will allow us to add or delete operations and will update models (such as the class diagram) that are affected by our decision.

Basis for interaction diagrams.

Use cases are closely related to interaction diagrams, i.e. sequence diagrams and collaboration diagrams (see Chapter 6). A use case provides a description of a particular task; the corresponding interaction diagram shows how that use case will work in terms of messaging between objects (see Chapter 6). Like the scenario, an interaction diagram shows what happens in a specific instance; loosely speaking the scenario gives a step-by-step account of what happens on the user's side of the computer screen and the interaction diagram gives a step-by-step account of what happens on the other side of the screen.

1.2.2.4 Sequence Diagram

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages sent between objects. It shows a set of objects or roles and messages sent and received by them. Sequence diagram has two features that distinguish them from communication diagrams—presence of lifeline and focus of control. The sequence diagram is included in UML specification since the first (1.1) version, it includes following elements:

Object or role—shows object or role which is involved in the communication with other objects or roles.

Lifeline—a vertical dashed bar showing the lifeline of object. The time dimension visually is going from top to down thus we can track the creation and destruction of an object along with the messages sent and received by it.

Message—specifies a particular communication between objects or roles. It is represented as a directed relationship pointing from sender to receiver. Message can be an invocation of an operation, raising a signal, creating or destroying object. The message has a name and it can include also parameters. Using different notations of messages, we can model both synchronous and asynchronous interactions.

Control—shows a period of time during which an object is performing an action requested by the message received, i.e., we can visually show the period of the execution of specific procedure; if we have nested procedure calls then we can visually as soon as possible show the possible bottlenecks raising performance issues in the future. Visually it is represented as a tiny vertical rectangle on the corresponding object’s lifeline.

Structured control—while control and messages allows us to model simple communication between objects, in many situations we need to model decision taking, parallel execution, and optional execution. To accomplish this modeling task, there are special graphical notation elements allowing us to model such cases.

Fig. 1.29 shows an example of diagram which is developed as a part of data synchronization system development project.

1 Introduction

Sequence Diagrams in UML [10] resulted from two sources: Ivar Jacobson’s interaction diagrams (Objectory) [3] and the 1992 version of the MSC language (MSC-92)1 [11]. From MSC-92 first an OO variant, called OMSC, was developed at Siemens [2] which essentially combined a subset of MSC with constructs typical for OO design, in particular, the construct for method calls. Sequence Diagrams are a further development and adjustment of OMSC. They do not claim to have the same degree of formality yet as MSC. This refers to both syntax and semantics. The syntax is not equally fixed in UML as in the ITU-T Recommendation Z.120 [12]. Therefore, different authors referring to UML use slightly different variants and take over some more constructs from MSC.

Sequence Diagrams and use cases are closely related within UML [1,10]. Sequence Diagrams are derived from use cases. A use case diagram shows the relationship among actors and use cases within a system. A use case diagram is a graph of actors, a set of use cases enclosed by a system boundary, communication associations between the actors and the use cases, and generalizations among the use cases. A given use case is typically characterized by multiple scenarios. Scenarios are described by means of Sequence Diagrams.

Sequence Diagrams are used whenever dynamic aspects are considered. The interaction between objects always arises from methods or processes being attached to objects. Such processes need time, have to be ordered possibly with respect to other processes, can be called only under certain guards, need parameters and provide results. Sequence Diagrams are useful whenever such correlations shall be visualized without showing the concrete programming code of a special programming language. Thereby, an abstraction of details of the later implementation is essential. Often, only a rather coarse overall view of the interplay of the concerned objects is important. Nevertheless, in its strongest refinement, Sequence Diagrams in OO systems can take over a similar role which in a procedural paradigm flow diagrams can play.

MSC is an ITU-T standard trace language for the specification and description of the communication behaviour of system components and their environment by means of message exchange [12]. In general, MSC applications can be attached to the area of reactive and distributed systems, and its main application area lies in the field of telecommunication systems. Traditionally, MSC is used primarily in connection with SDL. Indeed, it also arose from the same ITU-T study group as SDL. Contrary to Sequence Diagrams, MSC is a rather advanced language with a well defined syntax and semantics [4,6,9,12,13].

After the 1996 edition, MSC has been considered several times by Rational as a candidate for the trace description of object interaction in UML. A main obstacle essentially was the missing notion of flow of control in MSC. A harmonization of MSC and Sequence Diagrams certainly will enhance the application area of MSC by bringing it more to the attention of the OO community. However, the introduction of flow of control into MSC is more than a pure marketing strategy. It also pays attention to the fact that traditional telecommunication developing methods and OO techniques grow together. Beyond that, the introduction of flow of control to MSC appears as a challenging and promising subject in itself. The explicit representation of flow of control, in addition to the message flow representation, offers a completely new view of the implicit event trace which may contribute considerably to transparency and expressiveness of the description. It is also a natural place to introduce new communication mechanisms into MSC, e.g., synchronous communication, remote procedure call, etc. [8]. Though the role of flow of control in MSC appears to be not yet completely settled, it may be looked at already as a description, supplementary to the message flow. In this paper the role of flow of control within MSC will be clarified and the benefits of its explicit representation will be explained. A particular problem is how and on which level flow of control patterns can be embedded into the MSC language. Last not least, an intuitive graphical representation is crucial.

Within Chapter 2, the constructs of Sequence Diagram are presented and compared with corresponding constructs in MSC. In Chapter 3, a proposal for the introduction of flow of control into MSC is given and an interpretation of flow of control based on event structures is presented. The possible interpretation as critical region in case of shared resources is mentioned. Chapter 4 contains concluding remarks and an outlook.

13.2.2 Buffer Pattern

Fig. 13.3 shows a buffer pattern with an example of capability analysis for a reliable editing system.

As shown in Fig. 13.3, the application background of the buffer pattern shows that there is an autonomous entity or a causal entity whose interaction speed does not exactly match the system's interaction speed. The problem is to reconstruct the system to keep the unprocessed interactions in a state of allowing the process of them in the right order later when the system is available. This is to enhance the reliability of the system. The related NFR of the buffer pattern is also reliability.

We also use the editor as an example to illustrate the features. Here the requirements are the same but the operator's interaction speed does not match the system's speed. Without losing generality, we assume that the former is faster than the latter. The original interaction diagram is shown in Fig. 13.3A. It does not consider the interaction speeds of the system and the operator. This issue is important. If the operator is too quick to submit requests to the system and the system cannot process them in a timely manner, some requests will be lost without responding. The reliability of the system must be improved. This problem satisfies the application condition of the buffer pattern. When applying the buffer pattern into this problem, the interaction diagram is updated, as shown in Fig. 13.3B, by introducing a buffer. There is a queue of requests and those unprocessed requests are placed into the queue. Accordingly, shared phenomena between the system and this new entity have been included.

The capability analysis process of the new problem is shown as a sequence of argumentations attached to the interaction diagram in Fig. 13.4, in which (1) stipulates that the request is correct. If the system is not available to respond to it, the system causes corresponding events, i.e., to push the interaction into the buffer (3). The buffer's structural properties (2) need to guarantee the request is saved correctly. When the system is ready for the next request, it obtains one request from the buffer (4). Then the system responds to the request and updates the workpiece accordingly (5). The domain properties (6) of the workpiece will guarantee the required effects (7). Then the new specification can be obtained:

The editing system receives the operators' request.

The editing system pushes the request into the buffer.

The editing system pops in front of the next request.

The editing system processes the request by triggering the event to update the workpiece accordingly.

We can see from the new specification that the system will keep the operator's request first, which needs less time than dealing with the request. Then the system obtains the request from the buffer again and deals with it when the system is available.

12.2 APPROACH TO MODELLING AND DESIGN

Since the existing software design constrains the design of new function, we found it was necessary to have some OO model of the current behaviour to build upon. This model had to be generated by hand as there were no tools available to the developer at that time to extract the design from the code automatically [1], The schedule was short so the aim was to spend as little time on modelling existing code as possible.

The source code and its inline function descriptions were the only reliable form of documentation for the product. Not surprisingly, looking at the code gave little inspiration for producing the OO model as the level of detail was too great and the format unhelpful to “see” how it could appear in an OO model.

So, as a starting point, outline descriptions of the product's key functions were written and from these candidate classes and relationships were identified. This led to a model with about a dozen classes in it. Using the developer's experience of the product's function and internal design it was possible to determine how the resulting OO model mapped to some of the key software modules of the system.

Although the level of detail of this initial model was insufficient for the new design work it provided some context for the next phase where a new enhancement to the product is designed.

The requirements document for a planned enhancement identifies which part of the software was likely to change. More detailed descriptions of the product behaviour for these areas were generated and used to develop additional classes.

With a reasonable set of class diagrams in place, creating the design for an enhancement could begin.

Object interaction diagrams and scenario diagrams were used to determine how objects of existing classes interacted with new objects.

Classes were defined for the new objects and added to the appropriate places in the class diagrams.

The internal processing of the new classes was described using state diagrams.

The processes of modelling existing functionality and creating new design were never completely separate. As use cases were identified from the requirements, each was modelled by blending together old and new functionality. We discovered and used some simple heuristic principles that helped us find good cohesive abstractions.

If a class is too complex its state diagram becomes impossible to draw. A complex behaviour often hides more than one abstraction - introducing a new class may produce a more balanced design.

Associations between classes define where objects interact - basically the dependencies between objects. The class diagram looks crowded if the classes are too tightly coupled. Dependencies can sometimes be simplified by redesigning a mechanism or introducing new classes.

If an object interaction diagram/scenario diagram shows that two objects exchange many messages in order to perform a task, it suggests the sharing of responsibilities between these objects is poor. If too many objects are required to complete a scenario it can indicate a possible performance problem.

Once each view of the design looks reasonable, the structure is usually good. The ability to reposition objects/classes in a diagram provided by the OO design tool was important in this process as it helped identify symmetry in the design, common patterns and inconsistencies.

The structure of classes modelling existing function was extracted as much as possible from the code. (See section 12.3.) This avoided having to re-implement parts of the software that did not need reengineering and minimised the distance between the model and the code. In effect we considered the code as part of the problem domain that must be taken into account in building the model.

The level of detail used was different according to how much impact a new use case had on a particular area. New classes, or old classes that were affected by the new functionality, were modelled in great detail. Those that were involved but did not require modifications were only modelled at the level of their interfaces, without considering their internal behaviour or structure. Areas of function unaffected by the change were not modelled at all, or were represented by a high-level class which contained no detail. Thus, modelling effort was only spent where it was relevant and useful.

As the OO model was reused for subsequent enhancements (which occurred three times during the study) different areas of the product's function were affected and so were added to the OO model. This way, more and more of the product received the OO treatment. However, stable areas of the product were unaffected.

When the OO design of an enhancement was detailed enough, English descriptions were added to the standard internal design document usually produced. This was not strictly necessary but helpful for those in the team not used to the OO models.

In fact we found that the use of the design tool, and all the models and diagrams produced with it, did not require significant changes to the structure and contents of the in-house documentation produced during maintenance. It merely added a new level between the external and internal descriptions of the product, which helped to bridge the semantic gap between the two (see Fig. 12.1).

Although the model was never truly free of the constraints of the existing design, working at a level of abstraction above the code made it easier to come up with better solutions and discover and exploit commonalities between different areas of the design. Section 12.3 describes the structure and content of this model in more detail.

This chapter shows how to design interaction among objects (dynamic modeling) in order to implement system operation contracts using UML interaction diagrams (communication and sequence). Initially, object responsibility and visibility are explained in order to show that objects may only communicate to each other to perform their responsibilities if they have a visibility line to follow. Next, the chapter discusses how to build dynamic models in which objects change messages in order to perform the actions that are necessary to meet the postconditions of a contract, and how the preconditions and exceptions affect it. Design patterns for responsibility distribution among objects are presented in order to improve the design of object-oriented code with delegation and low coupling. Finally, the chapter explains how to use the information learned during dynamic modeling to improve the design class diagram.

Constructing a state diagram

In our second example we show you how to build a state diagram.11 You can find a list of all the steps involved in the summary at the end of the chapter. This example concerns a Human Resources system, where one class, Job Application, is complex enough to justify drawing a state diagram. The diagram will illustrate all the different possible behaviours of objects of the Job Application class.

A Job Application object is created when an application form is received and the details recorded. The application will then be read by the manager and may be shortlisted or rejected. If rejected, the application is filed for six months. At the end of this time it is discarded. If it is shortlisted, interview details are sent out and the interview is usually confirmed by the applicant. Once the interview has taken place, the applicant may not be successful; in this case a rejection letter is sent and the application is filed for six months and then discarded. If the applicant is offered the job, an offer letter is sent. If the offer is rejected by the applicant the application is filed for six months, and then discarded; if accepted, the application terminates and other procedures take over. The applicant may withdraw at any time during the application process.

In order to draw a state diagram, we need to sort out the events that can occur and the different states that a Job Application object can be in (see Table 7.4). An object always begins life in the start state, before anything happens to it.

Table 7.4. Events and states for objects of the Job Application class

We can see from the list that this diagram will be more complex than the previous BankAccount example, as it not only has more states, but there are three different ways in which a stop state may be reached. Multiple stop states are common in state diagrams, as the way an object ends its life will depend on the specific series of events that it undergoes. In contrast, there is only ever one start state on a state diagram, as all objects of a class are created in the same way.

A number of the events that appear separately in the list are actually the same event, but with different conditions, for example the ‘read by manager’ event has the conditions ‘rejected’ and ‘shortlisted’. These conditions will be represented in the state diagram in square brackets in the guard section of the relevant transition labels.

We should also check at this stage to see if there are any actions that the system has to perform in response to an event. These will be included in the labels on the relevant transitions. In the Job Application example there are two actions, ‘send rejection letter’ and ‘send offer letter’.

We start to construct the state diagram by beginning with the start state, the event that creates a Job Application object, and the state that the object moves into. Figure 7.4 shows the first stage of the diagram.

We can build up the diagram by deciding what events can happen to a Job ‘Application object while it is in the ‘Application logged’ state and adding them. Figure 7.5 shows the next stage in the process.

We work through the events and states in the list and add them to the diagram, until every item on the list has been included, then we go back to make sure that we have not forgotten any of the guards or actions that should be included in transitions. It is worth noting here that actions can also be contained in states (indicated by the keyword ‘do/ …’ in the state label). This type of action is usually referred to as an activity; it is ongoing (not instantaneous) and can be interrupted by an event. For example, there might be an activity ‘send for references’ associated with the ‘Shortlisted’ state.

The state diagram at this stage is shown in Figure 7.6.

There is still one event that we have not included in the diagram. The description of the behaviour of the Job Application class states that an applicant may withdraw at any time. In order to include this in the diagram in Figure 7.6, we would need to add a third stop state and draw transitions to it with the event ‘applicant withdraws’ from each of the four states on the diagram. This would make the existing diagram cluttered and very difficult to read. In order to avoid clutter, we can draw a superstate round the main body of the diagram, and show a single ‘applicant withdraws’ transition from it, indicating that an applicant can withdraw at any time during the application process.

Finally, we need to check the completed diagram against the original description of the behaviour of the Job Application class, in order to confirm that it is an accurate representation. The completed diagram with the superstate is shown in Figure 7.7.

7.4.3 Architecture and Code Structure

The ENS and DS fall into the category of common services discussed in Chapter 6. The combined use of these services facilitates full decoupling between application components, as shown in the interaction diagram in Figure 7.17; the application components do not communicate directly.

Figure 7.17 shows a typical interaction involving the ENS, the DS, and a pair of application components: one publisher and one consumer. In this sequence, the ENS first registers with the DS. The publisher component is then started and obtains the address details of the ENS from the DS and using this information connects to the ENS. The publisher then publishes a new event type “E” with value “27.” The consumer component is then started, and it too obtains the address of the ENS from the DS, and it also establishes a connection with the ENS. The consumer subscribes to event type “E,” and the ENS sends back its cached value for this event type, which is “27.” The publisher then publishes a new value of “33” for event type “E.” The ENS responds by pushing the new value for the event type to the consumer. The consumer now unsubscribes to event type “E.” Subsequently, the publisher publishes a new value of “47” for event type “E.” The ENS does not push the new value for the event type to the consumer.