A Process Model for Specifying System Behaviour with UMf

Ana Moreira, Joo Ara6jo and Fernando Brito e Abreu

Departamento de InformticaFaculdade de Ci8ncias e Tecnologia, Universidade Nova de Lisboa

2825-114 Caparica, PORTUGAITEL: + 351-21-2948536; FAX: + 351-21-2948541

{amrn, ja, fba}@di.fct~unLpt

Abstract

Sofhrare development projects g raw a reputation for poorquality" This situation is in part due to the Lack ofappropriate mechanisms to identijy and expressfunctz`onal requirements in a flexible yet rz"gorousfashion.LJML is a standard modeLling language that is able tospeci!y applz.cations in dzerent levels of abstractions as itprovides a wide range of notatz`ons. Among them, we havecollaborations that serve to reaLise use cases, a powezfitlabstraction concept. The behaviour part of acollaboration is rendered usz"ng sequence or collaborationd!agralns. However, the lack of abstraction andrefinement mechanisms compromz.ses the understand-ability and modular.zty of a specification. In general, wecan say that abstraction and refznement mechanisms helpobtaining a more maintainable system Our aim ts toprovide abstraction and refinement mechanismsaccomplished byproposz"ng a modelling process.

Keywords: UML, sequence diagrams,collaborations

fnfroducfionIt is often the case that software projects fail to

meet user expectations" When looking for root causes ofthis sorrow state we often come across the problem ofinadequate requirements elicitation and evolution. Thus, itis of utmost importance the availability of powerfulformalisms to help expressing functional requirementsiteratively and incrementally.

The Unified Modelling Language (UM][ ) provides severalconcepts, techniques and respective notations to be usedat different levels of abstraction throughout thedevelopment process [2]. For example, at a higherabstract level use cases, as proposed by Jacobson. areused to describe the outwardly visible requirements of asystem {8]; they describe functional requirements of asystem, are used in the requirements analysis phase of a

project and contribute to test plans and user guides (13).Use cases are a fundamental tool to help identify acomplete set of user requirements. A use case describes acomplete transaction, including error situations andexceptions, and normally involves several objects andmessages. Software developers are easily seduced by thesimplicity and potential of use cases; they claim that usecases are an easily understood technique for capturingrequirements.Use cases are "a society of classes, interfaces and otherelements that work together to provide some cooperativebehanioux' [2]. They can be refined throughcollaborations, each consisting of two parts: the structuraland the behavioural ones. The structural part is specifiedin a class diagram, The behavioural part is rendered usingone or more interaction diagrams, like, for example,sequence diagrams. A sequence diagram shows howmessages exchanged among considered objects areordered in time.

In general, abstraction and refinement mechanismshelp obtaining more maintainable systems. Sequencediagrams are limited since they only provide one level ofabstraction. Besides. there is no explicit support, in UMI ,to their refinement. The inability to represent refinementin those diagrams compromises the understandability andmodularity of a specification, and as such, the overallquality of this kind of behaviour models.

The aim of this paper is to investigate the specificationsteps from uses cases to sequence diagrams, proposing aprocess to model our findings. This process shouldinclude a mechanism to support refinement of sequencediagrams. The process should be iterative andincremental. The availability of a complete set of detaileduse cases and collaborations is not mandatory before westart drawing sequence diagrams and their refinements.We can start with the subset of the best understood andmore representative informal requirements, define its usecases and respective collaborations, and specify the initial

QuaTIC'2ool / 215

sequence diagrams for each collaboration, and then starttheir refinement.

In Section 2 we describe the process model.In Section 3 we apply the process to a casestudy. In Section 4 we discuss some relatedwork. Finally, in Section 5, we draw someconclusions.

The processOur goal is to investigate how sequence diagrams can

be refined so that we can specify, step by step, thebehaviour of a system using UML. Our idea is to propose

a process that derives object-oriented specifications forthe behaviour part of collaborations, starting from a usecase model. Each collaboration is translated into a set ofsequence diagrams, each one offering a partial view of theobjects involved in that transaction. The full integration ofall these views gives the complete functionality of thesystem.

The process, depicted in Figure I , is composed of threemain tasks: define the use case model, specify thecollaborations and specify the formal model or build aprototype~ In the next sections we describe each task interms of its subtasks.

Define use caso model

identifyactors & usecaacs

Describe

acto Ts & u Sc

ca ses

::::B LA lid u seca sc

diagra ms

identify and

dcscnbescenarios

Speclfy collaboratlons

B u iLd & rc H n esequcnccdiagra ms

Figure 1. The process model

The process is iterative and incremental. We do notpropose that a complete set of use cases and collaborationsbe found and described before we Start drawing sequencediagrams and their refinements. Instead, we can start withthe subset of the informal requirements we understandbetter, define its use cases and respective collaborations,specify the initial sequence diagrams for primary scenariosand from here refine them as shown in Section 4. In lateriterations we deal with the secondary scenarios.

Task 1: Define the use case model

To define the use case model we need to start byidentifying the actors and corresponding use cases of thesystem. An actor represents a coherent set of roles thatusers of the use cases play when interacting with the usecases [2]. A use case is a description of a set of sequencesof actions that a system performs that yields an observable

result of value to an actor. The major subtasks of this taskare: identify actors and use cases; describe actors and usecases; identify and describe scenarios; build the use casediagram

Subtask 1.1: Identify actors and use cases. The firstsubtask is to identify the actors of the system. Actors areanything that interfaces with our system. Some examplesare peOplf:, other software, hardware devices, data storesor networks. Each actor assumes a role in a given use case.Then we need to go through all the actors and identify usecases for each one. Use cases describe things actors wantthe system to do. In the UML a use case is always startedby an actor, however there are situations where we havefound it useful to initiate use cases from inside the system.These situations usually appear when the functionality istime related.

216 / QuaTIC2001

Task 2: Specify the coHaborations

The second task is composed of the two main subtasks:identify collaborations; build and refine sequencediagrams.

Subtask 2.1: Identify collaboraOons. Having specifiedthe use cases we can start identifying and associatingcollaborations to realise them. The collaborations willrealise the use cases through class diagrams andinteraction diagrams (i.e. sequence and collaborationdiagrams). We associate a collaboration to each use caseand start modelling it usmg a sequence diagram- The newobjects identified in each sequence diagram will originatea corresponding class in the class diagram. Therefore. theclass diagram can be built in parallel with the sequencediagrams. The collaboration diagrams can then begenerated from each sequence diagram by using anyCASE tool such as the Rational Rose 2000 [1I]-

Subtask 2.2: Build and refine sequence diagrams. Eachsequence diagram draws a scenario- In the first iterationswe only deal with the primary scenarios, leaving thesecondary scenarios for later iterations, when the mainfunctionality of the system is already specified.

The different levels of abstraction of sequence diagramsdepend on the kind of objects that we want to have at eachlevel. We propose that the most abstract level containsonly one object that represents the system. The next levelcontains boundary objects, the next one contains controlobjects and, the final one, provides the entity objects.

Having this in mind, we can follow the steps below torefine each sequence diagram of a collaboration:

- Consider the system as a black box, represented inthe diagram as an object, and identify theinteractions between it and the users (actors) thatactivate the scenario;

. Look at the object that represents the whole systemand "open" it to show a boundary object and againan object that represents the rest of the system(constituted of control and entity objects);

* Draw another sequence diagram where we showthe boundary and the control objects, and theobject that represents all the entity objects;

. Finally, another sequence diagram has to be drawnto show the entity objects.

Each of the sequence diagrams above can have levels ofabstraction in terms of the "granularity" of messages, i.e.,a message can be refined into a subsequence of messagesbetween two objects.

Other refinements include, for example, the refinementof the boundary object into its component objects, if any.Entity objects can also be complex objects that we.maywant to decompose in later iterations.

Subtask 12: Describe actors and use casea Havingidentified all the actors and use cases, we have to describethem- Each use case must include details about what has tobe done to accomplish the functionality of the use case.These include the basic functionality, but also alternatives,error conditions, preconditions and post conditions. Theuse case may include conditionals, branching and loops.

In the first iteration we can start by giving anarne and a brief description, one or twosentences long, to each actor and use case. Inlater iterations we can describe each use caseusing natural language, scenarios, or pseudo-code. (The Rational Unified Process gives abasic format for a use case [9].) We prefer touse scenarios, described as a list of numberedsteps. A scenario is a particular path of executionthrough a use case.

Subtask 1.3: Identify and describe scenarios- Use casescan be fully described using a primary scenario andseveral secondary scenarios, depending on the use casecomplexity. The primary scenario represents the main pathof the use case, i.e. the optimistic view. If everything goeswell, then what happens is the primary scenario. Thesecondary scenarios describe alternative path, includingerror conditions and exception handling. Therefore, oneimportant step here is to identify and describe, for each usecase, its primary and secondary scenarios. The initialiterations should handle only primary scenarios, leavingsecondary scenarios for later iterations-

Subtask 1.4: Baud the use case diagram The use casemodel shows the system boundaries, the actors and the usecases. Actors may be related between themselves and withthe use cases they activate. Some use cases can also berelated to other use cases.

A use case diagram uses four types of relationships:generalization, include, extend and association. Whilegeneralization is a relationship that can be used betweenactors and between use cases, include and extend arerelationships between use cases. On the other hand, anassociation is the cornmunication path between an actorand a use case. Actors that have similar roles, andtherefore activate (are associated with) the same subset ofuse cases, can inherit from each other, so that thecomplexity (number of associations from actors to usecases) of the diagram can be alleviated. Include allows theinsertion of additional behaviour into a base use case thatexplicitly describes the insertion. Extend allows theinsertion of additional behaviour into a base use case thatdoes not know about it [12].

QuaTIC,2001 / 217

Define the use case model

A use case model shows a set of actors and use casesand the relationships among them; it addresses the staticuse case view of a system. In our example, the actorsidentified are:

* Vehicle driver: this comprises the vehicle, the gizmoinstalled on it and its owner;

* Bank: this represents the entity that bolds the vehicleowners account;

* Operator: this may change the values of thesystem, and ask for monthly debits.

The use cases identified are:* Register a vehicle: this is responsible for registering a

vehicle and communicate with the bank toguarantee a good account;

*Pass a single tollgate: this is responsible for readingthe vehicle gizmo, checking on whether it is a goodone. If the gizmo is ok the light is turned green,and the amount to be paid is calculated anddisplayed; if the gizmo is not ok, the light turnsyellow and a photo is taken.

* Pass a two-point tollgate: this can be divided into twoparts. The in toll checks the gizmo, turns on thelight and registers a passage. The out toll alsochecks the gizmo and if the vehicle has an entrancein the system, turns on the light accordingly,calculates the amount to be paid (as a function ofthe distance travelled), displays it and records thispassage. (If the gizmo is not ok, or if the vehicledid not enter in a green lane, the behaviour is as inthe previous case.)

*Pay bill: this, for each vehicle, sums up all passagesand issues a debit to be sent to the bank and a copyto the vehicle owner.

Having identified and briefly described use cases, weneed to identify their primary scenarios. Each use case iscomposed of a primary scenario, obviously, and severalsecondary scenarios. For example the use case "pass asingle toll gate" has the primary scenario "pass single tollgate ok" and the secondary scenarios "pass single toll gatewithout a gizmo" and `.pass single toll with an invalidgizmo . In this paper we will use the primary scenario toillustrate the process. Figure 2 shows the primary scenario`pass single ton gate ok".

Task 3: Specify the formal modelfDuild theprototype

At this point we can follow different directions,depending on the organization interests and the applicationbeing built- One alternative is to keep specifying thesystem building a formal, or at least rigorous, model. Wehave been working on that line of research, by formalizingthe UML models using LOTOS [3], Object-Z [6], SDL[7]. The formalisation process is not alwaysstraightforward and depends on the skills andfamiliarisation with the formal description techniques ofthe analysts involved in the specification. Therefore,derivation rules should be provided to generate acorresponding formal specification of a collaboration, inorder to encourage and speed the forma!isation process~

Another different perspective is to build a prototype ofthe future system by using an evolutionary approach. Themain advantages are to accelerate the delivery of thesystem and stimulate the user engagement with the system.Here we can use high-level languages for prototyping asfor example Smalltalk, Lisp, Prolog and 4GL.

Applying the process to a case study

To exemplify the process described in the previoussection consider the case study we have chosen [4].

"In a road traffic pricing system, drivers of authorisedvehicles are charged at toll gates automatically. Theyare placed at special lanes called green lanes. For that,a driver has to install a device (a gizmo) in his vehicle~The registration of authorised vehicles includes theowners personal dam and account number (fromwhere debits are done automatically every month),and vehicle details. A gizmo has an identifier that isread by sensors installed at the toll gates. Theinformation read by the sensor will be stored by thesystem and used to debit the respective account. Theamount to he debited depends on the kind of thevehicle.

When an authorised vehicle passes through a greenlane, a green light is turned on, and the amount beingdebited is displayed. If an unauthorised vehicle passesthrough it a yellow light is turned on and a cameratakes a photo of the plate (that will be used to fine theowner of the vehicle).

There are green lanes where the same type vehiclespay a fixed amount (e.g. at a toll bridge), and oneswhere the amount depends on the type of the vehicleand the distance unveiled (e.g. on a motorway). Forthis, the system must store the entrance toll gate andthe exit toll gate."

218 f QuaTIC2001

Figure 3. The use case diagram of the Road TrafficPricing System

Later versions of the use case diagram could showrelationships between use cases, in particular some of theuse cases share a common set of events in the beginning(which could be shown by adding an extra use case relatedto the original use cases with the "include" relationship).Extend relationship could also be applied to deal witherror situations, for example.

Spcccollaborations

Collaborations realise uses cases, through a realisationrelationship (represented by a dashed arrow). Toexemplify this, we choose the use casePa s s S ingleTo I I Gat e, which deals with the threescenarios already mentioned in the previous section. The

primary scenario deals with authorised vehicles and thetwo secondary scenarios deal with non-authorisedvehicles. The associated collaboration for that isPa s s S ingl eTol lGat eMana gement" Figure 4 showsthe realisa, tion of the use case by that collaboration.

_-...,,( N .. ..~-.-......~..~.~~~ J `

, J\_ --" `, _'

,-~..-

PassSingleTollGate PassSingleTollGateManagement

Figure 4. The realisation of the use case for vehiclepassing a single tollgate

In the next Section, we show in detail theprocess concerning the refinement of sequencediagrams.

Build and refine sequence diagrams. In a sequencediagram, objects are shown as icons whose namingscheme takes the form ob ectName : C a s sName .However, the name of the class can be omitted, as inFigure 5. Arrows represent the messages. Messages arenumbered and may carry arguments. between brackets.

Figure 5 shows the initial sequence diagram for theprimary scenario authorised vehicles, passing a single ton(PassSingleTollGateOk), with the actor :VehicleDriverand the object that represents the collaboration. Thesystem reads the gizmo and, if this is OK, the actorVehicleDriver sees the light green and the amount to bepaid in the display. This represents the externally visiblebehaviour of the system.

Figure 5. Initial sequence diagram

Figure 2. "Pass single tollgate ok" primary scenario

Secondary scenarios are described in a similar way. Theset of all use cases can represented in a use case diagram,where we can see the existing relationships between usecases and the ones between use cases and actors. Figure 3shows the use case diagram of the road traffic system.

As a rule of thumb, boundary objects receive all theevents to the system. The system outputs are also madeavailable through this type of objects. In the fnst iteration,and to start with, we can only represent the interactionpoint, without having to detail the exact boundary objects.

QuaTIC 2001 / 219

Figure 6 shows the sequence diagram with the boundaryobject SingleToll.

Figure 6. Sequence diagram with boundary object

Boundary objects should only be responsible foraccepting inputs to the system or displaying outputs fromthe system. Therefore, we need a control object wheneverwe have complex functionality to deal with. Note thatcontrol objects are not always needed. As a rule, we mayjust ignore them to start with, and then add them if theboundary objects handle the major decisions of thecollaboration. Other strategy is to accept a control object`no matter the complexity of the functionality of thecollaboration, and in a �validation step" remove the onesthat we see as unnecessary, removing all those that onlyplay the role of intermediary, i"e., those that receive anevent and delegate that same event without processing it"We will follow this strategy. Figure 7 shows the sequencediagram with a boundary and a control object.

Figure 7. Sequence diagram with boundary andcontrol objects

Now we need to deal with the DataManagementobject. Having dealt with the two external layers(boundary and control) we have to identify the entityobjects", i.e., the key abstractions of the system. Entityobjects hold the information that must be provided for thecompletion of the functionality of the scenario. Figure 8shows the sequence diagram with the entity objects.

From here we could jump to task 3 (specify the formalmodel or build the prototype). In later iterations we couldadd still more detail to the sequence diagram. In particular,there ,`1-S more we can do about boundary objects. We knowthat a toll gate has to have a sensor to detect the vehiclesand to read their id number. We can also see that a lightmay be turned green or yellow, depending on whether weare authorised users or unauthorised ones. Also, we see theamount to be paid being shown on a display. Finally, if wewant to deal with unauthorised vehicles, a camera shouldphotograph their plate numbers. Therefore, single toll gateis composed of: sensor, light, display, camera. Figure 9refines the previous sequence diagram by incorporatingthese objects. As we are dealing with the primary scenariowe do not need to represent the camera object in thisdiagram.

In summary, after the sensor reads the gizmo, this mustbe checked to see if it is valid; the toll gate turns the lightgreen and shows the amount that will be debited from the

220 / QuaTIC2001

vehicles owner bank account. The amount must becalculated according to the type of the vehicle anddisplayed. Finally, the passage must be recorded in usagedetails.

Specdy the formal model/Build aprototype

The objective of this work is not to describe theformalisation process or to build the prototype. In theformer alternative, the approach described in [I], whichformaJises collaborations using Object-"Z, can be appliedhere. An evolutionary prototype can be built by usingadequate tools, e.g. 4GL.

Related workThere is some work that describes a process to specify

system behaviour. Dano et al. [5] present an approachbased on the concept of use case to support therequirements engineering process. This is a "domainexpert""orien!:ed" where the domain expert activelyparticipates in the specification of the use cases. These aredescribed by tables and Petri nets. Rolland and Archour[ 10) have developed CREWS. This is a model of use casetogether with a guidance process for authoring use cases,The approach involves contextual description of the usecases and writing and refining scenarios. Sendai} andStrohmeir [14] describe an approach that supplements usecase descriptions with operation schemas. These aredeclarative specifications of system operations written inOCL [15].

Figure 8. Sequence diagram with boundary, control and entity objects

QuaTIC,2001 I 221

] / / | / J / J I J

Figure 9. Refined sequence diagram showing the S~ngl e T011 components

Our previous work [l} shows the formalisation ofuse cases and respective collaboration usingObject-Z, but refinement is not considered.

Related areas of interest are the transformationof dynamic models and the cOnstruction ofsupporting tools, In [17] he proposes a mechanismto transform sequence diagrams into state charts. In{161 work has been done where the Maude system(based on rewriting logic) is used to automatetransformations of ̀ UMI behaviour models, andcan be applied to our process.

Conclusions and future workThe process described in this paper provides a

systematic way to specify the behaviour of asystem starting from use cases, identifyingcollaborations, and describing the respectivesequence diagrams. These are refined to differentlevels of abstraction according to the kind ofobjects represented in each level" This improvesthe work of the analyst as he/she can look at thesystem from different levels of abstraction,enhancing the communication among the differentmembers of the development team. The outcome is

a quality result is a better quality for thespecification.

For future work we are planning to formaliseand automate the refinement process. ThefOrrnalisation is important if we want to guaranteeconsistency the different levels of abstraction ofthe diagrams. The automation is essential asupdating the models is a highly time-consumingand error-prone activity if done manually. Otherrelated area of interest is the transformation ofdynamic models. We are investigating, fOrexample, how sequence diagrams can betransformed into state diagrams.

References[1] Ara6jo, J. and Morena A.: "Specifying the

Behaviour of UML collaborations Using Object-Z"', America Conference on Information Systems,Long Beach, California August 2000.

[2] Booch, G., Rumbaugh, J. and Jacobson, I.: TheUnified Modeling Language User Guide Addison"Wesley, Reading, Massachusetts, 1998.

[3] Brinksrl:1a. E.: LOTOS: a Formal DescriptionTechnQue Based on Temporal ObservationalBehaviour, ISO 8807, 1988.

222 / QuaTIC2001

Clark, R" and Moreira A.: Constructing FormalSpecifications from Informal Requirements,Software Technology and Engineering Practice,IEEE Computer Society, Los Alarn:itos, CaliforniaJuly 1997, pp. 68-75.Dana, B., Briand, H. and Barbier, F.: "AnApproach Based on the Concept of Use Case toProduce Dynamic Object-Oriented Specifications",Proceedings of the 3rd IEEE InternationalSymposium on Requirements Engineering, 1997.Duke, D., King, P., Rose, G. A. and Smith, G.:"The Object-Z Specification Language," TechnicalReport 91-l, Department of Computing Science,University of Queensland, Australia 1991.Ellsberger, J., Hogrefe, D. and Sarma A.: SOL,Prentice-Hall, 1997.Jacobson, I.: Object-Oriented SoftwareEngineering - a Use Case Driven Approach.Addison-Wesley. Reading Massachusetts, 1992.Jacobson, 1., Booch, G. and Rumbaugh, J.; "1"heUnified Software Development Process, Addison-Wesley, 1999.Rolland C. and Achour, B.: "Guiding theConstruction of Textual Use Case Specifications"~Data and Knowledge Engineering Journal, Vol. 25."No 1-2, North-Holland March 1998.ROSE, CASE tool,http:!Iwww.rational.com/products/rose.Rumbaugh, J., Jacobson, I. And 8ooch, G.: TheUnified Modeling language Reference Manual,Addison-wesley, 1999.Schneider, G. and Winters, J. P.: Applying UseCases - A Practical Guide. Addison-Wesley. 1998.Sendall, S. and Strohmeier, A.:, "From Use Casesto System Operation Specifications". UML 2000 -Advancing the Standard, Lecture Notes inComputer Science, Vol 1939 Springer-Verlag,October 2000.Warmer, J. and Kleppe, A.: The Object ConstraintLanguage: Precise Modeling with UML, Addison"Wesley, 1998.Whittle, J., AraOjo, J., Alernan, J.L,F., and Tonal,A.: Rigorously Automating Transformations ofUML Behaviour Models, Workshop on DynamicBehaviour, UML 2000, York, October 2000.Whittle, J. and Schumann, J.: GeneratingStatecharts from Scenarios, Proceedings of theInternational Conference on Software Engineering,Limerick, Ireland, 2000.

[4]

[5]

[6]

[71

[8]

[9]

[IO]

[II]

[12]

[13]

[14]

[151

[16]

[17]

QuaTIC`2001 / 223