Gadgets

9 views

Synthesizing State-Machine Behaviour from UML Collaborations and Use Case Maps

Synthesizing State-Machine Behaviour from UML Collaborations and Use Case Maps
of 21

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Tags
Transcript
  Synthesizing State-Machine Behaviour fromUML Collaborations and Use Case Maps Humberto Nicol´as Castej´on Mart´ınez Norwegian University of Science and Technology,Department of Telematics, N-7491 Trondheim, Norway humberto.castejon@item.ntnu.no Abstract.  Telecommunication services are provided as the joint effortof components, which collaborate in order to achieve the goal(s) of theservice. UML 2.0 collaborations can be used to model services. Further-more, they allow services to be described modularly and incrementally,since collaborations can be composed of subordinate collaborations. Forsuch an approach to work, it is necessary to capture the exact depen-dencies between the subordinate collaborations. This paper presents theresults of an experiment on using Use Case Maps (UCMs) for describingthose dependencies, and for synthesizing the state-machine behaviourof service components from the joint information provided by the UMLcollaborations and the UCM diagrams. 1 Introduction Telecommunication services are provided as the joint effort of active objects,which collaborate in order to achieve a goal for their environment. Initiatives maysrcinate from any side, be simultaneous and possibly conflicting. This is whatmakes tele-services interesting, but at the same time particularly challenging todesign.Traditional service engineering approaches have been object-oriented. Theyhave focused on modeling the total behaviour of objects, normally in termsof state-machines. The disadvantage of focusing on the complete behaviour of objects is that we only get a partial view of the services we want to design,which makes it difficult to understand and analyze them. Since telecommunica-tion services are the result of collaborations among objects pursuing a goal, acollaboration-oriented approach to service engineering seems more suitable [1,2]. A collaboration view helps to see the service as a whole, to define what roles areplayed by which objects, and to express what service goal combinations must bemet for the successful provision of the service.UML 2.0 collaborations [3,4] are intended to describe partial functionalitiesinvolving interactions among participating roles played by objects. Therefore,they fit well with our understanding of service. An interesting characteristic of UML collaborations is that they can be bound to a specific context, becomingcollaboration uses, which in turn can be used in the definition of larger collabo-rations. This feature enables a compositional and incremental design of services, A. Prinz, R. Reed, and J. Reed (Eds.): SDL 2005, LNCS 3530, pp. 339–359, 2005.c  Springer-Verlag Berlin Heidelberg 2005  340 H.N. Castej´on Mart´ınez which is desirable, but which will only succeed if the dependencies between thecollaborations that are composed are explicitly captured [5].This paper presents our approach to incremental service modeling usingUML 2.0 collaborations and motivates the need for explicitly expressing col-laboration dependencies in this approach (see section 2). It continues with theresults of an experiment on using Use Case Maps (UCMs) [6,7] for describingsuch dependencies (see section 3) and synthesizing the state-machine behaviourof service components from the joint information provided by the UML collab-orations and the UCM diagrams (see section 4). The paper finishes with a com-parison between our synthesis approach and other existing work (see section 5),and with a summary of the presented work (see section 6). 2 Goal-Oriented Service Collaborations In our service engineering approach we model services by means of UML 2.0collaborations. They describe a structure of roles that collaborate to collectivelyaccomplish some task, that is – to achieve some goal. The collaboration rolesspecify the properties that object instances must have in order to participatein the collaboration. The UML standard allows the association of behaviourwith collaborations in several forms, such as sequence diagrams involving thecollaborating roles, or as state-machines for the roles. Since our approach iscollaboration-oriented, we prefer to describe the behaviour of collaborations assequence diagrams that show the interactions between roles, rather than usingstate-machines for the roles.Figure 1 shows a UML collaboration diagram describing a  UserLogon  ser-vice. From the diagram we can see that there are five roles involved in thecollaboration (represented by boxes). We can also see the relationships that areneeded between these roles to achieve the goal of the collaboration. For exam-ple,  Terminal  is associated with  TerminalClientSession , which in turn is apart of   TerminalAgent  and it is associated with  UserTerminalSession . Thediagram also shows one interesting aspect of UML collaborations: they can con-tain other sub-collaborations in their definition, expressed as collaboration uses.When this happens, the roles of the collaboration uses are bound to the rolesof the container collaboration (for example  rr1 ’s  requested  role is bound to TerminalAgent ). Collaboration uses enable a modular design with small collab-orations as units of reuse. Modularity is a well-proven approach to break downthe complexity of systems; here we use it to structure services. It also promotesseparation of concerns and reuse. These aspects are reflected in the  UserLogon collaboration, which contains four sub-collaborations, namely  rr1 ,  rr2  ,  lo  and  ua  .The two first,  rr1 and  rr2  , are instances of a  RoleRequest  collaboration, while lo  and  ua   are instances of a  Logon  and a  UserAuthenticate  collaboration, re-spectively. We can see that the  RoleRequest  collaboration has been reused.We also appreciate how separation of concerns has been achieved by separatelydefining the interactions between  Terminal  and  TerminalClientSession , andbetween  TerminalClientSession  and  UserTerminalSession . Indeed, although  State-Machine Behaviour from UML Collaborations and Use Case Maps 341 logon and authentication protocols are related, they are not exactly the same.For example, it may be perfectly possible for two different logon protocols tomake use of the same authentication protocol. TerminalTerminalAgentTerminalClientSessionUserAgentUserTerminalSession rr1:RoleRequestrequestorrequested invoked rr2:RoleRequestrequestor invoked requested ua:UserAuthenticate lo:Logon loTerm loAgent uaAgentuaTermUserLogOns_goal.loggedOn =loTerm.s_goal:loggedOn loAgent.s_goal:loggedOns_goal.userLoggedOn =rr1.s_goal:playing rr2.s_goal:playing ua.s_goal:authenticated lo.s_goal:loggedOnCollaborationCollaboration UseCollaboration UseroleCollaborationrole Fig.1.  UML 2.0 Collaboration for  UserLogon  Service We have just seen the benefits of defining collaborations in terms of othersmaller collaborations. However, when looking at fig. 1 we can guess how UserLogon  works, but we do not exactly know how it does it. Even if we knowhow each of the four small sub-collaborations works in isolation, we do not knowhow they work together. Does  rr1  happen before  lo  or afterwards? Does  lo  fin-ish before  ua   starts or do they overlap? Can  lo  succeed with independence of what happens to  ua   or does it depend on its result? These are questions that wehave to answer if we really aim at composing collaborations, and we can do itby explicitly describing the dependencies between collaborations, that is, theirinter-relationships.Sanders [8] has proposed associating goals with services considered as col-laborations as a means to express liveness properties.  Event goals   (e goals) aredesired events, while  state goals   (s goals) are properties of collaboration globalstates that we wish to reach and entail combinations of role goals. Sanders foundthat service goals may also be used to express the dependencies that exist be-tween collaborations. These goals become then synchronization points betweencollaborations. For example, we may say that when  rr1 ’s goal is achieved,  lo  isenabled, that is, it can happen. Following this approach the problem of show-ing the dependencies between collaborations turns into the problem of show-ing the dependencies between their goals, but we still miss a good solution toshow such dependencies. Sanders, for example, defined the goal of   UserLogon  342 H.N. Castej´on Mart´ınez ( s goal:userLoggedOn  ) as a logical AND-operation over the goals of its subor-dinate collaborations, as depicted in fig. 1. However, while such an expressionreveals that  UserLogon  only succeeds if all its subordinate collaborations alsosucceed, it still does not tell us the order in which the collaboration goals areachieved. To overcome that limitation Sanders also experimented with severalUML concepts to describe goal dependencies, such as activity diagrams and in-teraction overview diagrams. These diagrams are good at expressing sequentialand parallel relationships, but they do not meet all our needs, since they fail toexpress finer relationships between intermediate goals, as those existing whentwo collaborations overlap. For example, in UML activity diagrams activitiescan be nested, so if we represent collaborations as activities, it would be possibleto show (to some extent) that, for example,  lo  only succeeds if   ua   also succeeds,by nesting  ua   inside  lo . However it does not seem possible to show, for example,that a collaboration starts, after certain time enables a second collaboration,and from then on both run in parallel (see fig. 3c).Since UML diagrams do not meet all our needs, we have analysed Use CaseMaps to see if they offer better support for expressing goal dependencies, sincethey are well known for their ability to explicitly capture inter-scenario relation-ships. The result has been promising, since we have been able to successfullydescribe several types of dependencies. Moreover, we have experimented withthe synthesis of state-machines for collaboration roles using the UCM informa-tion to guide the process, and the results are again promising. We take a closerlook at these two aspects in the next sections. 3 UCMs for Describing the Goal-Based Progress of Collaborations and Their Inter-relationships Use Case Maps (UCMs) [6,7] are a scenario-based graphical notation used todescribe causal relationships between responsibilities (tasks, actions, etc), whichmay be bound to abstract components. Basically, UCMs order responsibilitiesalong a path and link causes (preconditions or triggering events) to effects (post-conditions). With UCMs several scenarios can be easily integrated in a singlediagram. This is quite useful for showing interactions between the scenarios andunderstanding their combined behaviour.In section 2 we argued that the dependencies between collaborations can beexpressed in terms of their goals. That is, by relating the event and state goals of different collaborations we can effectively capture their inter-relationships. Ouraim is to use UCMs to:1. describe the goal-based progress of each collaboration (i.e. the causal rela-tionships between its event and state goals) in isolation;2. integrate the individual UCMs into more elaborated diagrams that show thedependencies between the individual collaborations.An example is given in fig. 2, where separated UCMs for the  RoleRequest , UserAuthenticate  and  Logon  collaborations are shown in the upper box, and  State-Machine Behaviour from UML Collaborations and Use Case Maps 343 rr.start rr.s_goal:playingrr.fail (a)  UCM for RoleRequest and Plug-in for rr1  and rr2 stubs  (b)  UCM for UserAuthenticate and Plug-in for ua   stubua.startua.failua.s_goal:userAuthenticatedlo.start lo.s_goal: loggedOnlo.e_goal:logonRequestedlo.fail (c)  UCM for Logon  (d)  UCM for UserLogon  IN1 IN1OUT1OUT1OUT2 UserLogon.fail OUT2 loCCrr1UserLogon.startUserLogon.s_goal:userLoggedOn (e)  Plug-in for loCC   stublo.startlo.s_goal:loggedOn IN1 lo.e_goal:logonRequested OUT1 IN1OUT2 OUT2OUT1 [ua.s_goal:userAuthenticated][rr2.fail OR ua.fail]lo.failrr2 ua rr1's binding:{(IN1,rr1.start),(OUT1,rr1.s_goal:playing),(OUT2,rr1.fail)}rr2's binding:{(IN1,rr2.start),(OUT1,rr2.s_goal:playing),(OUT2,rr2.fail)}ua's binding:{(IN1,ua.start),(OUT1,ua.s_goal:userAuthenticated),(OUT2,ua.fail)}loCC's binding:{(IN1,lo.start),(OUT1,lo.s_goal:loggedOn),(OUT2,lo.fail)} rr2_ua_WPStart-pointWaiting-placesResponsibilityStubEnd-pointCondition Fig.2.  UCMs for the UserLogon Service their integration into more complex UCMs for the UserLogon collaboration isshown in lower box. We will explain the dependencies expressed by these UCMsin section 3.2, but before that we will briefly explain the basic UCM elementsand how we use them.
Advertisement
Related Documents
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks