A Process Model for Specifying System Behaviour with UMf Ana Moreira, Joo Ara6jo and Fernando Brito e Abreu Departamento de Informtica Faculdade de Ci8ncias e Tecnologia, Universidade Nova de Lisboa 2825-114 Caparica, PORTUGAI TEL: + 351-21-2948536; FAX: + 351-21-2948541 {amrn, ja, fba}@di.fct~unLpt Abstract project and contribute to test plans and user guides (13). Use cases are a fundamental tool to help identify a Sofhrare development projects graw a reputationfor poor complete set of user requirements. A use case describes a complete transaction, including error situations and quality" This situation is in part due to the Lackof appropriate mechanisms to identijy and express exceptions, and normally involves several objects and functz`onalrequirements in a flexible yet rz"gorousfashion. messages. Software developers are easily seduced by the LJMLis a standard modeLlinglanguage that is able to simplicity and potential of use cases; they claim that use speci!y applz.cationsin dzerent levels of abstractions as it cases are an easily understood technique for capturing provides a wide range of notatz`ons.Among them, we have requirements. collaborations that serve to reaLiseuse cases, a powezfitl Use cases are "a society of classes, interfaces and other abstraction concept. The behaviour part of a elements that work together to provide some cooperative collaboration is rendered usz"ng sequence or collaboration behanioux' [2]. They can be refined through d!agralns. However, the lack of abstraction and collaborations, each consisting of two parts: the structural refinement mechanisms compromz.sesthe understand- and the behavioural ones. The structural part is specified ability and modular.ztyof a specification. In general, we in a class diagram, The behavioural part is rendered using can say that abstraction and refznementmechanisms help one or more interaction diagrams, like, for example, obtaining a more maintainable system Our aim ts to sequence diagrams. A sequence diagram shows how provide abstraction and refinement mechanisms messages exchanged among considered objects are accomplished byproposz"nga modelling process. ordered in time. In general, abstraction and refinement mechanisms Keywords: UML, sequence diagrams, help obtaining more maintainable systems. Sequence collaborations diagrams are limited since they only provide one level of abstraction. Besides. there is no explicit support, in UMI , fnfroducfion to their refinement. The inability to represent refinement It is often the case that software projects fail to in those diagrams compromises the understandability and meet user expectations"When looking for root causes of modularity of a specification, and as such, the overall this sorrow state we often come across the problem of quality of this kind of behaviour models. inadequaterequirementselicitation and evolution. Thus, it The aim of this paper is to investigate the specification is of utmost importance the availability of powerful steps from uses cases to sequence diagrams, proposing a formalisms to help expressing functional requirements process to model our findings. This process should iteratively and incrementally. include a mechanism to support refinement of sequence The Unified Modelling Language (UM][) provides several diagrams. The process should be iterative and concepts, techniques and respective notations to be used incremental. The availability of a complete set of detailed at different levels of abstractionthroughoutthe use cases and collaborations is not mandatory before we development process [2]. For example, at a higher start drawing sequence diagrams and their refinements. abstractlevel use cases, as proposed by Jacobson. are We can start with the subset of the best understood and used to describe the outwardlyvisible requirementsof a more representative informal requirements, define its use system {8]; they describe functional requirementsof a cases and respective collaborations, and specify the initial system, are used in the requirementsanalysis phase of a QuaTIC'2ool / 215 sequence diagramsfor each collaboration, and then start a process that derives object-oriented specifications for their refinement. the behaviour part of collaborations, starting from a use case model. Each collaboration is translatedinto a set of In Section 2 we describe the process model. sequence diagrams,each one offering a partialview of the In Section 3 we apply the process to a case objects involved in that transaction.The full integrationof study. In Section 4 we discuss some related all these views gives the complete functionality of the work. Finally, in Section 5, we draw some system. The process, depicted in Figure I , is composed of three conclusions. main tasks:define the use case model, specify the The process collaborationsand specify the formalmodel or build a Our goal is to investigate how sequence diagrams can prototype~In the next sections we describe each task in be refined so that we can specify, step by step, the terms of its subtasks. behaviour of a system using UML. Our idea is to propose Define use caso model identify Describe actors & use acto Ts & u Sc caacs ca ses B LA :::: lid u se identify and ca sc dcscnbe diagra ms scenarios Speclfy collaboratlons B u iLd & rc Hn e sequcncc diagra ms Figure 1. The process model result of value to an actor. The majorsubtasks of this task The process is iterative and incremental.We do not are: identify actors and use cases; describe actors and use propose that a complete set of use cases and collaborations cases; identify and describe scenarios; build the use case be found and describedbefore we Startdrawing sequence diagram diagramsand their refinements. Instead,we can start with the subset of the informal requirementswe understand Subtask 1.1: Identify actors and use cases. The first better, define its use cases and respective collaborations, subtask is to identify the actors of the system. Actors are specify the initial sequence diagramsfor primary scenarios anything that interfaces with our system. Some examples and from here refine them as shown in Section 4. In later are peOplf:,other software, hardware devices, data stores iterations we deal with the secondaryscenarios. or networks.Each actor assumes a role in a given use case. Then we need to go through all the actors and identify use Task 1: Define the use case model cases for each one. Use cases describe things actors want the system to do. In the UML a use case is always started To define the use case model we need to start by by an actor, however there are situations where we have identifying the actors and corresponding use cases of the found it useful to initiate use cases from inside the system. system. An actor represents a coherent set of roles that These situations usually appearwhen the functionality is users of the use cases play when interacting with the use time related. cases [2]. A use case is a descriptionof a set of sequences of actions that a system performs that yields an observable 216 / QuaTIC2001 Task 2: Specify the coHaborations Subtask 12: Describe actors and use casea Having identified all the actors and use cases, we have to describe The second task is composed of the two main subtasks: them- Each use case must include details about what has to identify collaborations; build and refine sequence be done to accomplish the functionality of the use case. diagrams. These include the basic functionality, but also alternatives, error conditions, preconditions and post conditions. The Subtask 2.1: Identify collaboraOons. Having specified use case may include conditionals, branching and loops. the use cases we can start identifying and associating In the first iteration we can start by giving a collaborations to realise them. The collaborations will realise the use cases through class diagrams and narne and a brief description, one or two interaction diagrams (i.e. sequence and collaboration sentences long, to each actor and use case. In diagrams). We associate a collaboration to each use case later iterations we can describe each use case and start modelling it usmg a sequence diagram- The new using natural language, scenarios, or pseudo- objects identified in each sequence diagram will originate code. (The Rational Unified Process gives a a corresponding class in the class diagram. Therefore. the class diagram can be built in parallel with the sequence basic format for a use case [9].) We prefer to diagrams. The collaboration diagrams can then be use scenarios, described as a list of numbered generated from each sequence diagram by using any steps. A scenario is a particular path of execution CASE tool such as the Rational Rose 2000 [1I]- through a use case. Subtask 2.2: Build and refine sequence diagrams. Each Subtask 1.3: Identify and describe scenarios- Use cases sequence diagram draws a scenario- In the first iterations can be fully described using a primary scenario and we only deal with the primary scenarios, leaving the several secondary scenarios, depending on the use case secondary scenarios for later iterations, when the main complexity. The primary scenario represents the main path functionality of the system is alreadyspecified. of the use case, i.e. the optimistic view. If everything goes well, then what happens is the primary scenario. The The differentlevels of abstractionof sequence diagrams secondary scenarios describe alternative path, including depend on the kind of objects that we want to have at each error conditions and exception handling. Therefore, one level. We proposethat the most abstractlevel contains important step here is to identify and describe, for each use only one objectthat representsthe system. The next level case, its primary and secondary scenarios. The initial contains boundaryobjects, the next one contains control iterations should handle only primary scenarios, leaving objects and, the final one, provides the entity objects. secondary scenarios for later iterations- Having this in mind, we can follow the steps below to refine each sequence diagramof a collaboration: Subtask 1.4: Baud the use case diagram The use case - Considerthe system as a black box, represented in model shows the system boundaries, the actors and the use the diagramas an object, and identify the cases. Actors may be related between themselves and with interactionsbetween it and the users (actors) that the use cases they activate. Some use cases can also be activate the scenario; related to otheruse cases. . Look at the object that representsthe whole system A use case diagramuses four types of relationships: and "open" it to show a boundary object and again generalization,include, extend and association. While an object that representsthe rest of the system generalization is a relationship that can be used between (constituted of control and entity objects); actorsand between use cases, include and extend are * Draw another sequence diagram where we show relationships between use cases. On the other hand, an the boundary and the control objects, and the association is the cornmunicationpath between an actor objectthat representsall the entity objects; and a use case. Actors that have similarroles, and . Finally, anothersequence diagramhas to be drawn therefore activate (are associated with) the same subset of to show the entity objects. use cases, can inherit from each other, so that the Each of the sequence diagramsabove can have levels of complexity (numberof associations from actorsto use abstractionin terms of the "granularity"of messages, i.e., cases) of the diagramcan be alleviated. Include allows the a message can be refined into a subsequence of messages insertion of additionalbehaviourinto a base use case that between two objects. explicitly describes the insertion. Extend allows the Other refinements include, for example, the refinement insertion of additionalbehaviour into a base use case that of the boundaryobject into its component objects, if any. does not know about it [12]. Entity objects can also be complex objects that we.may want to decompose in later iterations. QuaTIC,2001 / 217 Task 3: Specify the formal modelfDuild the Define the use case model prototype A use case model shows a set of actors and use cases At this point we can follow different directions, and the relationships among them; it addresses the static depending on the organizationinterests and the application use case view of a system. In our example, the actors being built- One alternative is to keep specifying the identified are: system building a formal, or at least rigorous, model. We * Vehicledriver: this comprises the vehicle, the gizmo have been working on that line of research, by formalizing installed on it andits owner; the UML models using LOTOS [3], Object-Z [6], SDL * Bank: this represents the entity that bolds the vehicle [7]. The formalisation process is not always owners account; straightforward and depends on the skills and * Operator: this may change the values of the familiarisation with the formal description techniques of system, and ask for monthly debits. the analysts involved in the specification. Therefore, The use cases identified are: derivation rules should be provided to generate a * Register a vehicle: this is responsible for registering a corresponding formal specification of a collaboration, in vehicle and communicate with the bank to orderto encourageand speed the forma!isationprocess~ guaranteea good account; Another different perspective is to build a prototype of *Pass a single tollgate: this is responsible for reading the future system by using an evolutionary approach.The the vehicle gizmo, checking on whetherit is a good main advantages are to accelerate the delivery of the one. If the gizmo is ok the light is turned green, system and stimulatethe user engagement with the system. and the amount to be paid is calculated and Here we can use high-level languages for prototyping as displayed; if the gizmo is not ok, the light turns for example Smalltalk,Lisp, Prolog and 4GL. yellow and a photo is taken. * Pass a two-point tollgate: this can be divided into two Applying the process to a case study parts. The in toll checks the gizmo, turns on the light and registers a passage. The out toll also To exemplify the process described in the previous checks the gizmo and if the vehicle has an entrance section considerthe case study we have chosen [4]. in the system, turns on the light accordingly, "In a road traffic pricing system, drivers of authorised calculates the amountto be paid (as a function of vehicles are charged at toll gates automatically.They the distance travelled), displays it and records this are placed at special lanes called green lanes. For that, passage. (If the gizmo is not ok, or if the vehicle a driver has to install a device (a gizmo) in his vehicle~ did not enter in a green lane, the behaviour is as in The registrationof authorisedvehicles includes the the previous case.) owners personal dam and account number(from *Pay bill: this, for each vehicle, sums up all passages where debits are done automaticallyevery month), and issues a debit to be sent to the bank and a copy and vehicle details. A gizmo has an identifierthat is to the vehicle owner. read by sensorsinstalled at the toll gates. The informationread by the sensor will be stored by the Having identified and briefly described use cases, we system and used to debit the respective account. The need to identify their primary scenarios. Each use case is amountto he debited depends on the kind of the composed of a primary scenario, obviously, and several vehicle. secondary scenarios. For example the use case "pass a When an authorisedvehicle passes through a green single toll gate" has the primary scenario "pass single toll lane, a greenlight is turnedon, andthe amountbeing gate ok" and the secondary scenarios "pass single toll gate debited is displayed. If an unauthorisedvehicle passes without a gizmo" and `.pass single toll with an invalid throughit a yellow light is turned on and a camera gizmo . In this paper we will use the primary scenario to takes a photo of the plate (that will be used to fine the illustrate the process. Figure 2 shows the primaryscenario owner of the vehicle). `pass single ton gateok". There are green lanes where the same type vehicles pay a fixed amount(e.g. at a toll bridge), and ones where the amountdepends on the type of the vehicle and the distanceunveiled (e.g. on a motorway). For this, the system must store the entrancetoll gate and the exit toll gate." 218 f QuaTIC2001 primary scenario deals with authorised vehicles and the two secondary scenarios deal with non-authorised vehicles. The associated collaboration for that is Pa s s S ingl eTol lGat eMana gement" Figure 4 shows the realisa,tion of the use case by that collaboration. _-...,, ( N .. ..~-.-......~..~.~~~ J ` , J \_ --" `, _' ,-~..- PassSingleTollGate PassSingleTollGateManagement Figure 2. "Pass single tollgate ok" primary scenario Figure 4. The realisation of the use case for vehicle passing a single tollgate Secondary scenarios aredescribed in a similar way. The set of all use cases can represented in a use case diagram, In the next Section, we show in detail the where we can see the existing relationships between use process concerning the refinement of sequence cases and the ones between use cases and actors. Figure 3 diagrams. shows the use case diagramof the road traffic system. Build and refine sequence diagrams. In a sequence diagram, objects are shown as icons whose naming scheme takes the form ob ectName : C a s sName . However, the name of the class can be omitted, as in Figure 5. Arrows represent the messages. Messages are numbered and may carry arguments. between brackets. Figure 5 shows the initial sequence diagram for the primary scenario authorisedvehicles, passing a single ton (PassSingleTollGateOk), with the actor :VehicleDriver and the object that represents the collaboration. The system reads the gizmo and, if this is OK, the actor VehicleDriver sees the light green and the amount to be paid in the display. This represents the externally visible behaviour of the system. Figure 5. Initial sequence diagram Figure 3. The use case diagram of the Road Traffic Pricing System Later versions of the use case diagram could show relationships between use cases, in particularsome of the use cases share a common set of events in the beginning (which could be shown by adding an extra use case related to the original use cases with the "include" relationship). Extend relationship could also be applied to deal with errorsituations, for example. Spcccollaborations Collaborationsrealise uses cases, through a realisation As a rule of thumb, boundary objects receive all the relationship (represented by a dashed arrow). To events to the system. The system outputs are also made exemplify this, we choose the use case available through this type of objects. In the fnst iteration, Pa s s S ingleTo I I Gat e, which deals with the three and to start with, we can only represent the interaction scenarios already mentioned in the previous section. The point, without having to detail the exact boundary objects. QuaTIC2001 / 219 Figure 6 shows the sequence diagram with the boundary object SingleToll. Figure 6. Sequence diagram with boundary object Boundary objects should only be responsible for accepting inputs to the system or displaying outputs from the system. Therefore, we need a control object whenever we have complex functionality to deal with. Note that Figure 7. Sequence diagram with boundary and control objects are not always needed. As a rule, we may control objects just ignore them to start with, and then add them if the boundary objects handle the major decisions of the collaboration. Other strategy is to accept a control object` Now we need to deal with the DataManagement no matter the complexity of the functionality of the object. Having dealt with the two external layers collaboration, and in a validation step" remove the ones (boundary and control) we have to identify the entity that we see as unnecessary, removing all those that only objects",i.e., the key abstractions of the system. Entity play the role of intermediary, i"e., those that receive an objects hold the informationthat must be provided for the event and delegate that same event without processing it" completion of the functionality of the scenario. Figure 8 We will follow this strategy. Figure 7 shows the sequence shows the sequence diagramwith the entity objects. diagramwith a boundaryand a control object. From here we couldjump to task 3 (specify the formal model or build the prototype). In later iterations we could add still more detail to the sequence diagram.In particular, there,`1-Smorewe can do about boundaryobjects. We know that a toll gate has to have a sensor to detect the vehicles and to read their id number. We can also see that a light may be turnedgreen or yellow, depending on whether we are authorisedusers or unauthorisedones. Also, we see the amountto be paid being shown on a display. Finally, if we want to deal with unauthorisedvehicles, a camera should photographtheir plate numbers. Therefore, single toll gate is composed of: sensor, light, display, camera. Figure 9 refines the previous sequence diagram by incorporating these objects. As we are dealing with the primaryscenario we do not need to represent the camera object in this diagram. In summary,after the sensor reads the gizmo, this must be checked to see if it is valid; the toll gate turnsthe light greenand shows the amountthat will be debited from the 220 / QuaTIC2001 vehicles owner bank account. The amountmust be Related work calculated according to the type of the vehicle and There is some work that describes a process to specify displayed. Finally, the passage must be recorded in usage system behaviour. Dano et al. [5] present an approach details. based on the concept of use case to support the requirements engineering process. This is a "domain Specdy the formal model/Build a expert""orien!:ed" where the domain expert actively participatesin the specification of the use cases. These are prototype described by tables and Petri nets. Rolland and Archour The objective of this work is not to describe the [ 10) have developed CREWS. This is a model of use case together with a guidance process for authoringuse cases, formalisation process or to build the prototype. In the former alternative, the approach described in [I], which The approach involves contextual description of the use cases and writing and refining scenarios. Sendai} and formaJises collaborations using Object-"Z, can be applied Strohmeir[14] describe an approachthat supplements use here. An evolutionary prototype can be built by using adequate tools, e.g. 4GL. case descriptions with operation schemas. These are declarative specifications of system operations written in OCL [15]. Figure 8. Sequence diagramwith 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 a quality result is a better quality for the Our previous work [l} shows the formalisation of specification. use cases and respective collaboration using For future work we are planning to formalise Object-Z, but refinement is not considered. and automate the refinement process. The Related areas of interest are the transformation fOrrnalisationis importantif we want to guarantee of dynamic models and the cOnstruction of consistency the different levels of abstraction of supporting tools, In [17] he proposes a mechanism the diagrams. The automation is essential as to transformsequence diagramsinto statecharts. In updating the models is a highly time-consuming {161 work has been done where the Maude system and error-proneactivity if done manually. Other (based on rewriting logic) is used to automate related area of interest is the transformation of transformations of `UMI behaviour models, and dynamic models. We are investigating, fOr can be appliedto our process. example, how sequence diagrams can be Conclusions and future work transformedinto state diagrams. The process described in this paper provides a References systematic way to specify the behaviour of a [1] Ara6jo, J. and Morena A.: "Specifying the system starting from use cases, identifying Behaviour of UML collaborations Using Object- collaborations, and describing the respective Z"',America Conference on Information Systems, sequence diagrams. These are refined to different Long Beach, California August 2000. levels of abstraction according to the kind of [2] Booch, G., Rumbaugh, J. and Jacobson, I.: The objects represented in each level" This improves Unified Modeling Language User Guide Addison" the work of the analyst as he/she can look at the Wesley, Reading, Massachusetts, 1998. system from different levels of abstraction, [3] Brinksrl:1a.E.: LOTOS: a Formal Description enhancing the communication among the different TechnQue Based on Temporal Observational members of the development team. The outcome is Behaviour,ISO 8807, 1988. 222 / QuaTIC2001 [4] Clark, R" and Moreira A.: Constructing Formal Specifications from Informal Requirements, Software Technology and Engineering Practice, IEEE Computer Society, Los Alarn:itos,California July 1997, pp. 68-75. [5] Dana, B., Briand, H. and Barbier, F.: "An Approach Based on the Concept of Use Case to Produce Dynamic Object-OrientedSpecifications", Proceedings of the 3rd IEEE International Symposium on RequirementsEngineering, 1997. [6] Duke, D., King, P., Rose, G. A. and Smith, G.: "TheObject-Z Specification Language," Technical Report 91-l, Department of Computing Science, University of Queensland,Australia 1991. [71 Ellsberger, J., Hogrefe, D. and Sarma A.: SOL, Prentice-Hall,1997. [8] Jacobson, I.: Object-Oriented Software Engineering - a Use Case Driven Approach. Addison-Wesley. Reading Massachusetts, 1992. [9] Jacobson, 1., Booch, G. and Rumbaugh, J.; "1"he Unified Software Development Process, Addison- Wesley, 1999. [IO] Rolland C. and Achour, B.: "Guiding the Constructionof Textual Use Case Specifications"~ Data and Knowledge EngineeringJournal,Vol. 25." No 1-2, North-Holland March 1998. [II] ROSE, CASE tool, http:!Iwww.rational.com/products/rose. [12] Rumbaugh,J., Jacobson, I. And 8ooch, G.: The Unified Modeling language Reference Manual, Addison-wesley, 1999. [13] Schneider, G. and Winters, J. P.: Applying Use Cases - A Practical Guide.Addison-Wesley. 1998. [14] Sendall, S. and Strohmeier, A.:, "From Use Cases to System Operation Specifications". UML 2000 - Advancing the Standard, Lecture Notes in Computer Science, Vol 1939 Springer-Verlag, October2000. [151 Warmer,J. and Kleppe, A.: The Object Constraint Language: Precise Modeling with UML, Addison" Wesley, 1998. [16] Whittle, J., AraOjo,J., Alernan,J.L,F., and Tonal, A.: Rigorously Automating Transformations of UML Behaviour Models, Workshop on Dynamic Behaviour,UML 2000, York, October 2000. [17] Whittle, J. and Schumann, J.: Generating Statecharts from Scenarios, Proceedings of the InternationalConferenceon Software Engineering, Limerick,Ireland, 2000. QuaTIC`2001 / 223