Presentation is loading. Please wait.

Presentation is loading. Please wait.

Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. (http://www.kc.com)http://www.kc.com K E N N E D Y C A R T E R V2.3.

Similar presentations


Presentation on theme: "Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. (http://www.kc.com)http://www.kc.com K E N N E D Y C A R T E R V2.3."— Presentation transcript:

1 Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. (http://www.kc.com)http://www.kc.com K E N N E D Y C A R T E R V2.3

2 2 K E N N E D Y C A R T E R Return to Contents Contents  The Need for xUML The Need for xUML  The Notational Subset The Notational Subset  The xUML Process The xUML Process  The xUML Action Language The xUML Action Language  System Generation from xUML Models System Generation from xUML Models  An xUML Case Study An xUML Case Study  Summary Summary Click on a subject or just use the down and up arrow keys to browse through the tutorial

3 Executable UML The Need for xUML

4 4 K E N N E D Y C A R T E R Return to Contents Why is the the UML 1.4 not executable ?  It is incomplete  UML describes a system in, broadly, two ways:  by specifying the desired results (use cases, sequence diagrams)  by specifying the software that, when executed, will produce the desired results (classes, associations, operations, state machines)  The latter specification of behaviour is the basis for implementing the system, but is missing key ingredients:  the implementation of operations (methods) are specified only by a “language dependent” text string  the actions associated with state machines (and methods) are specified either by a text string, or by using the “action” part of the UML Action Terminate Action DestroyAction Uninterpreted Action CreateAction CallActionReturnAction SendAction

5 5 K E N N E D Y C A R T E R Return to Contents Action Specifications in UML 1.4  Cannot be attached to methods and cannot therefore be used to specify operations  Do not cover the full range of information required to model real behaviour  No conditional logic  Do not deal with internal data within an Action Sequence  Cannot describe reading and writing of attributes  Cannot describe manipulation and navigation of associations  Cannot describe parallel behaviour  Not related to the UML type model  Do not have fully defined semantics..... were intended only as a place holder for future UML development

6 6 K E N N E D Y C A R T E R Return to Contents Why is the current UML not executable ?  It is big  UML was conceived as a Universal as well as Unified modelling language  UML covers many development paradigms  Synchronous and asynchronous behaviour  State dependent and stateless behaviour  Mealy state machines and Moore state machines  Flat state models and Harel state charts  Abstract analysis modelling and code specific design modelling  Language specific modelling and abstract modelling  Sometimes the breadth of coverage can lead to ambiguity... Transaction in Progress Transaction Complete entry/ log transaction Transaction Completed/ if is_aborted then return e.g. what happens if you execute a “return” in a transition action stimulated by “call” (synchronous) event ? I have absolutely no idea because that combination of behaviour is undefined!

7 7 K E N N E D Y C A R T E R Return to Contents Actions and the UML  In 1994 Kennedy Carter created the Action Specification Language, which operates at the same level of abstraction as UML… …but embodies the precision to allow models to be executed and consequently supports translation of the models into any language.  The OMG has recognised the need for a full action specification in the UML  In November 1998 the OMG issued a Request for Proposals on Precise Action Semantics for the UML  Kennedy Carter is a key participant in the main submitting consortium … …and is confident that ASL will be compliant with the emerging standard.  The proposal was submitted in August 2000 and is supported by …

8 8 K E N N E D Y C A R T E R Return to Contents What is xUML? UML V1.4 xUML = Semantically Weak Elements Semantically Weak Elements - Precisely Defined Action Semantics +  xUML is  an executable version of the UML, with…  clearly defined simple model structure  a precise semantics for actions, which will be incorporated into the UML standard  a compliant action specification language  an accompanying process  a proven development process, oriented towards…  executable modelling  large-scale reuse  pattern based design

9 9 K E N N E D Y C A R T E R Return to Contents Why an Executable UML ?  Measurable Deliverables  Models that execute tests correctly  Can be delivered in phases with progressive integration  Use case by use case Admit In Patient User Interface U log incident Patient AdminStatementsResource Alloc 1:dialogue ok hit 2:admit in patient 3:assign bed 4:bed assigned 5:confirm admission 6:display dialogue 8:reject admission 9:display dialogue 1:op selects admit in patient 2: 3:find a suitable bed 4:if bed available then 5: confirm admission 6: display “success” dialogue 7: log admission details 8:else reject admission 9: display “failure” dialogue  Class group by class group  Early Verification  Requirements can be validated before extensive system design and coding This supports iterative and incremental development An executable model can be developed and tested even if it supports only a single use case Groups of classes at the collaboration, subsystem, package or domain level can be modelled and executed

10 10 K E N N E D Y C A R T E R Return to Contents Why an Executable UML ?  Improves the quality of the modelling  Models can be judged not just on subjective criteria, but on whether they exhibit the desired behaviour and thus meet requirements  Focused analyst objective àThe aim is to build models that execute correctly àAvoids “analysis paralysis” àReviews criteria are objective and therefore more useful Aircraft clearedRunway() Runway deallocate() 0..1 is_ allocated_to R Does this identify the correct runway to deallocate ? Does this identify the correct runway to deallocate ? # obtain an instance handle for # the runway we just landed on theRunway = this -> R9.”is_allocated_to” # remove the association unlink this R9 theRunway # tell the runway that aircraft has landed [] = deallocate[] on theRunway

11 11 K E N N E D Y C A R T E R Return to Contents Why an Executable UML ?..... eliminates maintenance problems due to redundant analysis and design models  Supports extensive code generation if desired  Lack of ambiguity means automatic code generation will deliver functionally correct code GenericContainer HashTableLinkedListBoundedArray GenericClass 0..* 1  A solid specification  Supports multiple development teams  Well defined models mean well defined interfaces  Easier Transition to Design and Code  No ambiguity in the models - the models have a single clear interpretation  Design can be specified using abstract patterns

12 12 K E N N E D Y C A R T E R Return to Contents Why an Executable UML ?  and finally..... It’s more fun !  Analysts see the results of their efforts more rapidly and have more confidence that what they are doing is correct  Managers get more confidence that progress is being made

13 Executable UML The Notational Subset

14 14 K E N N E D Y C A R T E R Return to Contents Design aims of UML  The designers of UML did not intend that developers would use all of the formalism at any one time  Rather, they intended it to support a particular paradigm for a particular type of development “It’s like being a cook. You have to know how to use virtually all of the possible ingredients. Just not all at the same time.” Jim Rumbaugh, Executable UML involves choosing the correct ingredients

15 15 K E N N E D Y C A R T E R Return to Contents What is executable UML ?  The primary models Hospital System Domain Chart Patient Administration Resource Allocation Location Tracking User Interface Patient Administration Class Model is using is being used by 1 Out Patient patient no next visit date Bed ward name bed no bed type In Patient patient no name date of birth Patient patient no name date of birth is being used by 0..1  A set of execution rules dealing with  Assumptions about when asynchronous messages are responded to  Order of message processing  Interruption of processing  Parallel execution Each domain encapsulates the models that describe a single subject matter area. Domains will be focused on various subject matters in the system such as : The customer viewpoint Generic services Hardware control Each domain remains independent of other domains and they are connected using Bridges. Bed State Model Bed Available entry/ # find old patient old_patient = this -> R1 # remove link to old patient unlink this R1 old_patient Bed Unavailable entry/ # find new patient new_patient = find-only In_Patient where \ patient_no = new_patient_no # create link to patient link this R1 new_patient B3:bed_assigned_ to_patient B4:bed_ unassigned The class diagram is part of the static model and captures the key abstractions and associations within a domain. It is the foundation of the domain model. The state chart captures the dynamic behaviour of the active classes.

16 16 K E N N E D Y C A R T E R Return to Contents What is executable UML ?  Supported by …. Hospital System Use Cases Admit Out Patient Administrator Admit In Patient Domain Sequence Diagram User Interface U log incident Patient AdminStatementsResource Alloc 1:dialogue ok hit 2:admit in patient 3:assign bed 4:bed assigned 5:confirm admission 6:display dialogue 8:reject admission 9:display dialogue 1:op selects admit in patient 2: 3:find a suitable bed 4:if bed available then 5: confirm admission 6: display “success” dialogue 7: log admission details 8:else reject admission 9: display “failure” dialogue Admit In Patient Object Sequence Diagram Use cases provide an informal description of required behaviour from a user’s perspective. The domain level sequence diagram shows how a use case is realised by the cooperation of the various domains in the system. The lifelines on the sequence diagram correspond to domains. The interactions between domains serve to indicate which services a domain must provide, which services a domain requires of other domains and specifies the bridge requirements. Within each domain an object level sequence diagram shows how the use case will be realised by the interaction between objects. The lifelines on the sequence diagram correspond to objects. The interactions between objects serve to indicate which operations a class must provide and the messages to be sent from on class to another.

17 17 K E N N E D Y C A R T E R Return to Contents xUML has no Hierarchical Notations - Just Model Layers Train Management Hardware Interface Domains Hop negotiateHop accelCurvePerformed finalAccelCurvePerformed startDate endDate distanceCovered currentState Train currentSpeed timerId currentState hopNegotiated finalHopNegotiated R2 Classes 2. Waiting For Next Hop entry/ nextHop = this -> R2 generate TIM10:setAbsoluteTimer \ generate timeToNegotiateNextHop () at \ nextHop.startTime to this timeToNegotiateNextHop (trainId) 3. Negotiating Hop entry/ nextHop = this -> R2 generate H1:negotiateHop() to nextHop hopNegotiated (trainId) StatesOperations hopNegotiated this.currentState = ‘journeyComplete’

18 Executable UML The xUML Process in Outline

19 19 K E N N E D Y C A R T E R Return to Contents Analysis Document An Elaborative Development Process Analyse Design Document Implement Software System manually in months or years manually in months or years “high level” informal no completion criteria “high level” informal no completion criteria large team of technology experts application polluted by technology idiosyncratic components obsolete documentation idiosyncratic components obsolete documentation Require- ments these never stop changing Of course, with any type of development, the exact requirements are almost never known upfront. This means that some iteration must be performed until the final solution is achieved. With elaborative development, the iteration must often include execution of (sections of) the implemented code. Changes that result from iterative development must somehow be applied to the analysis documents, the design documents and to the final code. Reverse engineering (round trip) tools are usually successful only at keeping the design and code in step The analysis document is then quickly abandoned and becomes out of date.

20 20 K E N N E D Y C A R T E R Return to Contents Analysis Model An Alternative View Analyse Apply the Analysis to Design Mapping Design Model Apply the Design to Implementation Mapping Software System A good analysis model is a specification of required behaviour. Executable analysis models are suitable for mapping to design and implementation A good analysis model is a specification of required behaviour. Executable analysis models are suitable for mapping to design and implementation If the mappings are systematic then this view becomes optional This is produced by applying the mappings to the analysis model. The analysis model and the mappings are maintained and the code isn’t. Require- ments Analysis to Design Mapping Design Design is about the specifying the mapping from the implementation independent view in the analysis model to the implementation dependent view in the design model and implementation. This can be done class by class or more systematically. Design is about the specifying the mapping from the implementation independent view in the analysis model to the implementation dependent view in the design model and implementation. This can be done class by class or more systematically. Design to Implementation Mapping Iteration can be achieved directly at this level because the analysis models are precise enough to be executed and subjected to actual tests. Such Iteration can be perfomed on parts of the analysis model (single use cases), class groups or the whole model The design model can also be developed with iterative development and, if required, this can be done before the application analysis is started. This is because the design captures patterns for implementing any xUML model Iteration can be also be achieved at this level in the same way as elaborative development, if required.

21 21 K E N N E D Y C A R T E R Return to Contents Analysis Model An Alternative View - Developed Analyse Apply the Analysis to Implementation Mapping Software System Require- ments Analysis to Implementation Mapping Design Combine the two mappings as they are applied sequentially.These can be captured as Design Patterns This can be done manually or, with a code generator, automatically Automatic code generation means that Iteration can be achieved at this level without any model getting out of step. This is because changes are made either to the design or to the analysis models (depending on the nature of the change) and the system is then regenerated.

22 22 K E N N E D Y C A R T E R Return to Contents Objectives of the xUML Process  The primary objectives of a development process based on xUML are: ObjectiveAchieved by... Promote large-scale reuse by keeping separate concerns separate throughout Partition the system into domains Shorten development times by maximising the scope for concurrent development of different parts of the system Analyse the domains concurrently Reduce cost of defect removal by testing at the earliest opportunity Build executable analysis models Improve code quality by formalising systematic design patterns Formalise a fully-specified abstract design model Reduce coding and maintenance costs by generating a system composed of software units that have uniform quality and structure Automate the application of the abstract design rules

23 23 K E N N E D Y C A R T E R Return to Contents xUML Based Development Implement Software System automatically in minutes or hours automatically in minutes or hours Design Patterns small team of technology experts small team of technology experts the “software architecture” the “software architecture” Analyse xUML Model complete, precise & testable complete, precise & testable small teams of application experts small teams of application experts

24 24 K E N N E D Y C A R T E R Return to Contents Overview of the xUML Process The xUML process can be summarised as: SPECIFY DOMAINS Identify new/reused domains Model system use cases VALIDATE ANALYSIS Execute domain use cases Execute system use cases ANALYSE NEW DOMAINS Build Static Model Build Dynamic Models Specify Actions Model domain use cases Execute and debug xUML models FORMALISE ABSTRACT DESIGN MODEL Select or develop suitable patterns and mechanisms (Build/Buy xUML compiler) PRODUCE TARGET CODE Apply design patterns to xUML models (manually or automatically) Perform target testing

25 Executable UML The xUML Process Steps

26 26 K E N N E D Y C A R T E R Return to Contents The xUML Process Steps  What’s the process for developing executable models ?  No process is linear so this section illustrates only the steps that are taken, not necessarily the precise ordering  The process can be tailored  Iteration takes place within and across the steps  The phases are:  Preparation or Inception Phase  Establish requirements and scope  Modelling or Elaboration Phase  Development of application analysis models  Development of abstract design models  Construction Phase  Manual or automatic application of absract design rules to application models  This section of the tutorial describes the general principles of the Preparation and Modelling Phases. The application of Modelling to abstract design and the automatic execution of the construction phase is described later.

27 27 K E N N E D Y C A R T E R Return to Contents Preparation or Inception Phase Hospital System Use Cases Admit Out Patient Administrator Admit In Patient Capture requirements with use cases Partition system into domains Hospital System Domain Chart Patient Administration Resource Allocation Location Tracking User Interface Admit In Patient Domain Sequence Diagram User Interface Ulog incident Patient AdminStatementsResource Alloc 1:dialogue ok hit 2:admit in patient 3:assign bed 4:bed assigned 5:confirm admission 6:display dialogue 8:reject admission 9:display dialogue 1:op selects admit in patient 2: 3:find a suitable bed 4:if bed available then 5: confirm admission 6: display “success” dialogue 7: log admission details 8:else reject admission 9: display “failure” dialogue Identify domain interactions Patient Administration Class Model is using is being used by 1 Out Patient patient no next visit date Bed ward name bed no bed type In Patient patient no name date of birth Patient patient no name date of birth is being used by 0..1 Produce first-cut class diagram for each domain to be modelled

28 28 K E N N E D Y C A R T E R Return to Contents The Preparation of Inception Phase  Preparation or Inception Phase aim is to:  scope the project  engineer the requirements  partition the system into domains  identify new, reused or COTS domains  produce first cut class and interaction diagrams for new domains  consider system and software architecture issues  identify key risks  produce size and cost estimates  This phase does not produce any executable models but provides the foundation for the next phase

29 29 K E N N E D Y C A R T E R Return to Contents Modelling or Elaboration Phase Produce the interaction diagram Develop state charts for classes and specify actions using an action language Add operations to classes and specify them using an action language Specify bridges between domains Admit In Patient Object Sequence Diagram Bed State Chart Bed Available entry/ # find old patient old_patient = this -> R1 # remove link to old patient unlink this R1 old_patient Bed Unavailable entry/ # find new patient new_patient = find-only In_Patient where \ patient_no = new_patient_no # create link to patient link this R1 new_patient B3:bed_assigned_ to_patient B4:bed_ unassigned Patient Administration Bed Class Bed wardName bedNo bedType CheckAvailability() isOccupied freeBed = find-one Bed where\ isOccupied = FALSE Patient Admin to Resource Alloc Bridge $USE Resource Allocation Generate allocateResource Resource Allocation Patient Admin PatientAdmin > Resource Allocation > PatientAdmin > assignBed allocateResource

30 30 K E N N E D Y C A R T E R Return to Contents Modelling or Elaboration Phase  Executable modelling is ideal for iterative and incremental development  Each iteration takes this form:  Select a scenario from a use case (starting with the primary ones)  Update the domain interaction diagram if necessary  For each domain involved:  Produce the class collaboration diagram  Produce state models for the classes  Update the class diagram as required  Add operations to the classes  Specify the operations and state actions with an action language  Specify initial conditions and test methods with an action language  Specify the provided and required interface of the domain  Build the domain model  Simulate the scenario through the domain  Specify the the bridges which connect the domains  Build the multi-domain model  Simulate the scenario through all involved domains

31 31 K E N N E D Y C A R T E R Return to Contents The xUML Process Overview 1. Capture Requirements2. Partition into Domains3. Define Domain Interfaces Patient Administration Static Model is using is being used by 1 Out Patient patient no next visit date Bed ward name bed no bed type In Patient patient no name date of birth Patient patient no name date of birth is being used by Specify Classes Bed State Chart Bed Available entry/ # find old patient old_patient = this -> R1 # remove link to old patient unlink this R1 old_patient Bed Unavailable entry/ # find new patient new_patient = find-only In_Patient where \ patient_no = new_patient_no # create link to patient link this R1 new_patient B3:bed_assigned_ to_patient B4:bed_ unassigned 6. Specify Behaviour Admit In Patient Object Sequence Diagram 5. Define Class Interfaces

32 Executable UML The xUML Action Language

33 33 K E N N E D Y C A R T E R Return to Contents The Action Specification Language  A key component of xUML is the Action Language  This section provides a broad summary of the capabilities of ASL, supported by some examples.

34 34 K E N N E D Y C A R T E R Return to Contents BRIDGE Banking:informOfExceededOverdraftLimit CLASS: Account INPUTS: OUTPUTS: counterpartDisplayRecord = this -> CPR1 $USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE BRIDGE Banking:informOfExceededOverdraftLimit CLASS: Account INPUTS: OUTPUTS: counterpartDisplayRecord = this -> CPR1 $USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE Bridges, for mapping to other domains Action Specification Language is used for… 1CREATING Account # create a new account with a unique id and the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today= current-date newAccount.dateOpened = today # get the handle of the owning customer instance owningCustomer = find-only Customer where custId = custId # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer AC1:createAccount (custId,openingBalance) Actions, for state- dependent behaviour account_1 = create Account with accountId = 32 & \ dateOpened = & \ balance = & \ currentState = ‘inGoodStanding’ customer_1 = create unique Customer with... link account_1 R1 customer_1... account_1 = create Account with accountId = 32 & \ dateOpened = & \ balance = & \ currentState = ‘inGoodStanding’ customer_1 = create unique Customer with... link account_1 R1 customer_1... Scenarios, for simulation and system initialisation OPERATION: checkAccountbalance CLASS: Account INPUTS: OUTPUT: if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif OPERATION: checkAccountbalance CLASS: Account INPUTS: OUTPUT: if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif Operations, for state independent behaviour

35 35 K E N N E D Y C A R T E R Return to Contents Instance Manipulation Instances are manipulated using instance handles an instance handle is a reference to a specific instance myAccount = find-only Account where accountId=33 In many contexts, a special instance handle named “this” is always available which contains the instance handle of the instance that is executing the current action. Account Instances account id date opened current state inGoodStanding frozen balance 22, , owner id Customer custId custAddress currentState Account accountId dateOpened balance ownerId currentState 1..*1 owns is owned by an optional identifier is a set of one or more attributes whose values uniquely distinguish each instance R1

36 36 K E N N E D Y C A R T E R Return to Contents Association Manipulation Associations are manipulated usingassociation primitives So, to navigate from this instance of Account to the owning customer, do not do this... theOwnerId = this.owner_id owningCustomer = find-only Customer where custId = theOwnerId theOwnerId = this.owner_id owningCustomer = find-only Customer where custId = theOwnerId owningCustomer = this -> R1 do this instead... Account Instances account id date opened current state inGoodStanding frozen balance 22, , owner id is owned by Customer custId custAddress currentState Account accountId dateOpened balance ownerId currentState 1..*1 owns R1

37 37 K E N N E D Y C A R T E R Return to Contents Specifying Actions  The Action Specification Language provides a process modelling formalism that can be used to specify all the processing in a domain.  The most common ASL constructs allow the analyst to:  Create a New Class Instance  Assign Attribute Values  Obtain an Instance Handle  Create an Association Instance  Navigate to a Related Instance  Delete an Association Instance  Navigate to a Set of Instances  Determine if a Set is Empty  Send a Signal Event  Delete a Class Instance

38 38 K E N N E D Y C A R T E R Return to Contents Creating a New Class Instance  The creation operation for Account includes a create statement. Object Diagram myCustomer : Customer myAccount : Account new Account instance created with arbitrary unique integer value assigned to' accountId' by the architecture OPERATION: createAccount INPUTS: owningCustomer: Customer, openingBalance: Real OUTPUTS: newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 “newAccount” is an instance handle “Account” is a class name “balance” is an attribute of the Account class “openingBalance” is an input parameter to this operation “create unique” provides an arbitrary identifier value, use “create” to define specific identifying attributes

39 39 K E N N E D Y C A R T E R Return to Contents Assigning Attribute Values  Any action may assign local variables and attribute values... the 'dateOpened' attribute is assigned the value returned by the operation 'current_date' Object Diagram myCustomer : Customer myAccount : Account OPERATION: createAccount INPUTS: owningCustomer: Customer, openingBalance: Real OUTPUTS:newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns R1 “today” is a local variable which is declared by first use This assignment would have more appropriately been made as part of the 'create' statement “newAccount” is an instance handle “current-date” is a pre-defined ASL feature which returns the current date “dateOpened” is an attribute name “=“ is the assignment operator

40 40 K E N N E D Y C A R T E R Return to Contents Object Diagram Creating an Association Instance  The analyst specifies when and how association instances are created... a new instance of R1 is created, linking the new account instance to the owning customer instance found earlier myCustomer : Customer myAccount : Account OPERATION: createAccount INPUTS:owningCustomer: Customer, openingBalance: Real OUTPUTS:newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 “link” is an ASL keyword which links two instances through a specifed association “newAccount” is an instance handle “R1” identifies the association “owningCustomer” is an instance handle In this case, the class diagram states the policy that each instance of Account is owned by exactly one instance of Customer. The ASL enforces this policy by creating an instance of association R1 whenever an instance of Account is created.

41 41 K E N N E D Y C A R T E R Return to Contents Object Diagram myCustomer : Customer myAccount : Account Navigating to a Related Instance  It is possible to navigate from one instance to another instance by specifying:  1. the starting instance, and  2. the association to navigate. AC6:delete_account (accountId) 1. starting from 'this' Account instance navigate the R1 association instance to obtain the handle of the related Customer instance Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 The ASL keyword 'this' refers to the instance handle of the instance associated with the state machine or instance-based operation executing the current action. “owningCustomer” is the single instance handle that results from the navigation to the “1” end of an association This line can be read as “The owningCustomer can be found by navigating from this through R1”

42 42 K E N N E D Y C A R T E R Return to Contents Object Diagram myCustomer : Customer myAccount : Account Deleting a Association Instance  The analyst specify when association instances are deleted... the R1 association instance linking this Account instance and the owning Customer instance is deleted ‘goodbye, world’ ‘now I'm a dangling customer!’ Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 “this” is the ASL keyword that represents the instance executing the state machine “R1” identifies the association “unlink” is the ASL keyword which removes the link between two associated instances “owningCustomer” is an instance handle In this case, the analyst is about to delete an instance of Account. Prior to this, the dying Account instance must be unlinked from all of its related instances.

43 43 K E N N E D Y C A R T E R Return to Contents Object Diagram myCustomer : Customer myAccount : Account Navigating to a Set of Instances  Navigate to a set of related instances by specifying:  1. the starting instance, and  2. the association to navigate. 3. to obtain a set of Account instance handles (an empty set in this scenario) 2. navigate the R1 association instances (there are none in this scenario) 1. starting from the owning Customer instance Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 In this case, since the analyst is navigating to the “many” end of an association, the navigation will deliver a set of (zero or more) Account instances. The {} symbols are used denote a set.

44 44 K E N N E D Y C A R T E R Return to Contents Object Diagram myCustomer : Customer myAccount : Account Determining if a Set is Empty  The cardinality of a set can be determined using the 'countof' function... ‘I've got a feeling I won't last much longer’ ‘I know how you feel’ Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 In this case, the analyst wishes to determine if the Account instance that is about to die is the last instance owned by the owning Customer instance. If so, then the multiplicity of the association requires that the owning Customer instance be deleted, since it is now related to zero instances of Account. “countof” is an ASL keyword that returns the number of instances of the specified set if then else endif is an ASL control logic construct

45 45 K E N N E D Y C A R T E R Return to Contents Object Diagram myCustomer : Customer myAccount : Account Sending a Signal Event  It is possible to send an event to a specified instance of a class in the same domain using the “generate...to” construct... the signal 'deleteCustomer’ is sent to the specified instance of Customer Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 “generate” is an ASL keyword that denotes a signal send “to” is an ASL keyword that denotes that the signal is sent to the specified instance. “to” must always be followed by a valid instance handle Here, the signal carries no supplemental data, hence the empty parameter list denoted by (). Signal parameters are comma separated if there are any. “deleteCustomer ” is the signal name

46 46 K E N N E D Y C A R T E R Return to Contents Object Diagram myAccount : Account Deleting a Class Instance  The 'delete' statement is used to delete a specified instance... ‘I was right!’ the Account instance for this state machine has been deleted. This is guaranteed to have been deleted by the time this action completes. the Customer instance has been deleted as a result of the deletion event to the owning Customer's state machine (NOTE: it cannot be guaranteed that this event has been processed yet) Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this deleteAccount() Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState 1..*1 owns is owned by R1 “delete” is an ASL keyword In this case, the state is terminal, and therefore this instance of Account must be deleted.

47 Executable UML System Generation from xUML Models

48 48 K E N N E D Y C A R T E R Return to Contents Software Design Model – The Elements To implement a software design model, we will construct: A class model of the abstract software design. Design Patterns (archetypes). Code Patterns in the target language. Mapping rules from xUML. A tagging scheme. Mechanisms…. To implement a software design model, we will construct: A class model of the abstract software design. Design Patterns (archetypes). Code Patterns in the target language. Mapping rules from xUML. A tagging scheme. Mechanisms…. Queues Scheduler xUML TimerSignal Communication

49 49 K E N N E D Y C A R T E R Return to Contents Abstract Design Model Class Diagram is executing for has Domain Class State Model Object State Machine Instance contains is part of holds attribute values for holds attribute for has defines behaviour of is an instance of has Type of Process Data Structure Actual Process Data Area Type of Processor Actual Processor c events are processed by processes events for is executing is running in is server for is accessed via specifies is specified by specifiesis specified by can execute can be executed by attribute values are held in attributes are held in holds code for code is held in Static xUML Runtime xUML Runtime Execution Code Assembly is located on This quadrant is the meta model for the xUML model elements and consequently it doesn’t change. This is a greatly simplified version! This quadrant is the meta model for an executing xUML model at runtime and likewise it doesn’t change. It is a static model of the xUML virtual machine. This quadrant captures the properties of the software build. It may be very simple in some projects. This quadrant captures the target software runtime view. It must meet the requirements of the xUML virtual machine. The classes in this quadrant will depend on the type of system being built, eg real time embedded or information system. Associations that span the quadrants define characteristics of the architecture such as distribution, threading and queuing policies

50 50 K E N N E D Y C A R T E R Return to Contents Archetypal Design and Code Patterns C++ Code Archetype class Class { public: (); //………. private: static char *className; static char *classKeyLetter; //……. ; //……. }; Mapping Rules expressed in ASL {allClasses} = find-all Class for eachClass in {allClasses} do # create a class called Class # with the attributes of Class as static items {theAttributes} = eachClass -> R1 for eachAttribute in {theAttributes} do # create a private member data item # corresponding to the attribute # with type eachAttribute.dataType endfor (): … : … Design Archetype This is a UML class which describes a design pattern which can be applied to each class in the analysis model. It can be used to show how attributes and operations from the analysis classes will map into the design and also how instances will be contained, how associations will be realised, etc. Expressing the design model in the form of patterns keeps it free from application specific concepts and therefore easier to maintain. This is a code version (C++ in this example) of the design pattern. The actual code is created by substituting the corresponding elements of the analysis model into the places denoted by the <> delimiters. Clearly substitution of this form is mechanical and therefore amenable to automatic code generation if desired. This is a meta level description which defines how the elements of the analysis model will be mapped into the target code. It is defined using ASL

51 51 K E N N E D Y C A R T E R Return to Contents Mechanisms  The design patterns provide uniform strategies for common issues… …such as persistence… PersistentClass {abstract} className classNumber saveState{abstract} restoreState{abstract} findFirst findNext Mechanism Pump saveState restoreState Tank saveState restoreState Classes mapped from application and service domain xUML models A mechanism is a part of the design and target code which does not derive from the analysis models by substitution but provides some generic capability. Mechanisms are commonly used to implement signal queuing, instance containers, persistance services and communications

52 52 K E N N E D Y C A R T E R Return to Contents Mechanisms Coded Mechanisms // // Event Queue // class EventQueue { public: EventQueue(); void generate (GenericEvent*); GenericEvent *findEvent (char*); GenericEvent *consumeEvent (); GenericEvent *getFirstEvent (); private: virtual ~EventQueue (); Queue *theQueue; static numberOfEventQueues; }; EventQueue EventQueue() generate (GenericEvent) findEvent (string) : GenericEvent consumeEvent : GenericEvent getFirstEvent : GenericEvent numberOfEventQueues theQueue UML Mechanisms Queue QueueElement > (GenericEvent) Mechanisms can be described using UML…. …. and code

53 53 K E N N E D Y C A R T E R Return to Contents Instantiating an Archetype Use mapping rules to apply the archetype to each analysis model element to produce code Customer getCustAddress custId custAddress currentState Analysis Model Element Generated C++ Code class ClassCustomer { public: custAddressType getCustAddress(); private: static char *className; static char *classKeyLetter; // int custId; custAddressType custAddress; int currentState }; C++ Code Archetype class Class { public: (); //………. private: static char *className; static char *classKeyLetter; //……. ; //……. }; Mapping Rules in ASL {allClasses} = find-all Class for eachClass in {allClasses} do # create a class called Class # with the attributes of Class as static items {theAttributes} = eachClass -> R1 for eachAttribute in {theAttributes} do # create a private member data item # corresponding to the attribute # with type eachAttribute.dataType endfor

54 54 K E N N E D Y C A R T E R Return to Contents Benefits Domain partitioning maintains a clear separation between the operations to be performed on data, and the structure of the data... xUML Models The analysis models specify the required processing in an implementation- independent way Design Patterns The patterns provide templates for a range of data structures, along with rules and a tagging scheme to determine their use The software architecture domain encapsulates the design decisions that define how components of the implementation are to be generated from components of the analysis. This allows the classes to be fully specified in an abstract, implementation-independent, formalism... Target Code Translation Engine The generated code is not a directly maintained deliverable... and translated into a variety of implementations that do not have to be based on classes.

55 Executable UML An xUML Case Study

56 56 K E N N E D Y C A R T E R Return to Contents An xUML Case Study  This section presents a Case Study problem and (part of) a solution as xUML models  The Case Study is a Petrol (Gas) Station control system  The same Case Study is used in the turorial for the iUML toolset. Using this you can:  Interactively develop your models  See the models executing

57 Executable UML xUML Case Study: The Problem

58 58 K E N N E D Y C A R T E R Return to Contents Case Study System Requirements Petrol Station Control System Requirements A computer-based system is required to control the dispensing of petrol, to handle customer payment and to monitor tank levels. The system must be “best of breed”, easy to use, reliable, fast and easy to modify to incorporate requirements yet to be conceived. Before a customer can use the self-service pumps, the pump must be enabled by the attendant. When a pump is enabled, the pump motor is started, if it is not already on, with the pump clutch free. When the trigger in the gun is depressed, closing a micro switch, the clutch is engaged and petrol pumped. When it is released, the clutch is freed. There is also a micro switch on the holster in which the gun is kept which prevents petrol being pumped until the gun is taken out. Once the gun is replaced in the holster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannot dispense more petrol. After a short standby period, the pump motor will be turned off unless the pump is re-enabled. A metering device in the petrol line sends a pulse to the system for each 1/100 litre dispensed. The cost of the fuel is calculated using the amount delivered and unit cost which is displayed on the pump. There are two kinds of pump. The normal kind allows the user to dispense petrol ad lib. The sophisticated pumps, imported from New Zealand, allow the customer to preset an amount and a volume of petrol. Petrol will then be pumped up to a maximum of the required quantity. Transactions are stored until the customer pays. Payment may be either in cash, by credit card or account. A customer may request a receipt (showing price, time, date etc.) and will get a token for every 5 pounds. Customers sometimes abscond without paying and the operator must annotate the transaction with any available information, the vehicle’s registration number for example. At the end of the day, transactions are archived and may be used for ad hoc enquiries on sales. At present, two grades of petrol are dispensed from five pumps on the forecourt. Each pump takes its supply from one of two tanks, one tank for each grade. The tank level must not drop below 4% of the tank’s capacity. If this happens, the pumps serviced by that tank cannot be enabled to dispense petrol. The developer shall provide a complete software system to perform the above control functions and shall provide design documents, code listings and so on. Petrol Station Control System Requirements A computer-based system is required to control the dispensing of petrol, to handle customer payment and to monitor tank levels. The system must be “best of breed”, easy to use, reliable, fast and easy to modify to incorporate requirements yet to be conceived. Before a customer can use the self-service pumps, the pump must be enabled by the attendant. When a pump is enabled, the pump motor is started, if it is not already on, with the pump clutch free. When the trigger in the gun is depressed, closing a micro switch, the clutch is engaged and petrol pumped. When it is released, the clutch is freed. There is also a micro switch on the holster in which the gun is kept which prevents petrol being pumped until the gun is taken out. Once the gun is replaced in the holster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannot dispense more petrol. After a short standby period, the pump motor will be turned off unless the pump is re-enabled. A metering device in the petrol line sends a pulse to the system for each 1/100 litre dispensed. The cost of the fuel is calculated using the amount delivered and unit cost which is displayed on the pump. There are two kinds of pump. The normal kind allows the user to dispense petrol ad lib. The sophisticated pumps, imported from New Zealand, allow the customer to preset an amount and a volume of petrol. Petrol will then be pumped up to a maximum of the required quantity. Transactions are stored until the customer pays. Payment may be either in cash, by credit card or account. A customer may request a receipt (showing price, time, date etc.) and will get a token for every 5 pounds. Customers sometimes abscond without paying and the operator must annotate the transaction with any available information, the vehicle’s registration number for example. At the end of the day, transactions are archived and may be used for ad hoc enquiries on sales. At present, two grades of petrol are dispensed from five pumps on the forecourt. Each pump takes its supply from one of two tanks, one tank for each grade. The tank level must not drop below 4% of the tank’s capacity. If this happens, the pumps serviced by that tank cannot be enabled to dispense petrol. The developer shall provide a complete software system to perform the above control functions and shall provide design documents, code listings and so on. BACK

59 59 K E N N E D Y C A R T E R Return to Contents Tank B Lead Free Tank C Diesel Tank A Four Star Four Star Lead Free Lead Free Four Star Lead Free Diesel FOSSIL FUELS Example Configuration

60 60 K E N N E D Y C A R T E R Return to Contents FOSSIL FUELS Plundering Earth’s Natural Resources for You 25 Feb :25 Pump 3 - Four Star p = £16.00 including = £2.38 Thank You for Choosing Fossil Cost/Litre Quantity Cost 80.0p £16.00 Four Star FOSSIL FUELS Example Data Representations

61 Executable UML xUML Case Study: The xUML Models

62 62 K E N N E D Y C A R T E R Return to Contents Use Cases for Petrol Station > Make Fuel Delivery Specify Fuel Volume Specify Fuel Value Make Credit Card Payment Log Trans-action > Make Payment Attendant Credit Card Validator Buy Non- Fuel Goods Customer Buy Fuel

63 63 K E N N E D Y C A R T E R Return to Contents Definition of “Make Fuel Delivery” Use Case Use Case NameMake Fuel Delivery. PurposeTo allow a paying customer to deliver fuel of a customer selected grade. PreconditionsThe desired fuel grade is available. InvariantsTank level > 4% tank capacity while pump is turned on. Primary Scenario1. Customer removes gun from holster; 2. Attendant enables pump; 3. Customer selects one fuel grade; 4. Pump motor is started; 5. Customer uses trigger to control fuel delivery, causing the system to engage/disengage pump clutch as trigger is depressed/released; 6. Customer replaces gun in holster; Pump motor is stopped. PostconditionsAt least two litres of fuel have been delivered. The pump gun is in the holster. The pump motor is off. Secondary Scenario 1Customer delivers less than two litres of fuel. PostconditionsLess than two litres of fuel have been delivered. Secondary Scenario 2Tank level falls below 4%.. PostconditionsAll pumps connected to tank are disabled.. Secondary Scenario 3Customer releases trigger but does not return gun to holster. PostconditionsPump switched off after timeout period.. Performance Specification TriggerCustomer removes gun from holster. PeriodicityAperiodic. Rate60/hour. Use Case NameMake Fuel Delivery. PurposeTo allow a paying customer to deliver fuel of a customer selected grade. PreconditionsThe desired fuel grade is available. InvariantsTank level > 4% tank capacity while pump is turned on. Primary Scenario1. Customer removes gun from holster; 2. Attendant enables pump; 3. Customer selects one fuel grade; 4. Pump motor is started; 5. Customer uses trigger to control fuel delivery, causing the system to engage/disengage pump clutch as trigger is depressed/released; 6. Customer replaces gun in holster; Pump motor is stopped. PostconditionsAt least two litres of fuel have been delivered. The pump gun is in the holster. The pump motor is off. Secondary Scenario 1Customer delivers less than two litres of fuel. PostconditionsLess than two litres of fuel have been delivered. Secondary Scenario 2Tank level falls below 4%.. PostconditionsAll pumps connected to tank are disabled.. Secondary Scenario 3Customer releases trigger but does not return gun to holster. PostconditionsPump switched off after timeout period.. Performance Specification TriggerCustomer removes gun from holster. PeriodicityAperiodic. Rate60/hour.

64 64 K E N N E D Y C A R T E R Return to Contents Domain Chart for Petrol Station System Petrol Station Control Pump Interface Attendant Interface Hardware Interface

65 65 K E N N E D Y C A R T E R Return to Contents Information Model for Petrol Station Control Domain pumpNumber tankNumber Pump time pumpNumber volumeDelivered cost Delivery tankNumber gradeName tankEmptyFlag tankLevel tankCapacity emptyThreshold Tank gradeName unitPrice Fuel Grade transactionNumber pumpNumber transactionType cost transactionProcessTime deliveryStartTime Transaction transactionNumber observations Evaded Transaction transactionNumber Paid Transaction transactionNumber pumpNumber Pending Transaction is pumping fuel from is providing fuel for 1* is being made using is being used for stores1 is stored in* is pending for 1 delivered fuel for 0..1 has delivered fuel for * records fuel delivery for 1 R3R1 R9 R10 R4 R2

66 66 K E N N E D Y C A R T E R Return to Contents Outline Class Collaboration Diagram for Delivery Management Domain > Meter > Holster > Motor > Clutch > Gun > Customer > Attendant > Tanker Operator Transaction Delivery Pump Tank

67 67 K E N N E D Y C A R T E R Return to Contents Preliminary CCD for Delivery Management Domain > Meter > Holster > Motor > Clutch > Gun > Customer > Attendant > Tanker Operator Transaction Delivery Pump Tank createDelivery pumpEnabled triggerDepressed requestPumpEnable gunRemoved startMotor

68 68 K E N N E D Y C A R T E R Return to Contents Complete CCD for Delivery Management Domain > Meter > Holster > Motor > Clutch > Gun > Customer > Attendant > Tanker Operator Transaction Delivery Pump Tank createTransaction paymentReceived customer Absconds transactionPending createDelivery pumpEnabled fuelUnitDelivered deliveryComplete startMotor stopMotor engageClutch disengageClutch triggerDepressed triggerReleased pumpUnavailable fuelAvailable requestPumpEnable tankerDelivery fuelUsed gunRemoved gunReplaced

69 69 K E N N E D Y C A R T E R Return to Contents (Part of) State Machine for Pump Class Waiting for Customer entry/ # The pump is idle. Wait in this state until # a customer removes the gun from its holster. Gun Replaced The Colloboration Diagram shows that the Pump class receives the following signals… Pump Enabled Trigger Depressed Trigger Released Assume that the “Waiting for Pump Enable” action will also detect the signal: Fuel Available Customer Finished Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity. Gun Removed Fuel Level Low Please identify the remaining states and transitions.

70 70 K E N N E D Y C A R T E R Return to Contents State Machine for Pump Class Fuel Unavailable entry/ # Inform customer that the pump is unavailable. # Wait for fuel to become available for this pump. Fuel Delivery Complete entry/ # Delivery Now Complete, Stop motor and return pump # to waiting state Waiting for Customer entry/ # The pump is idle. Wait in this state until # a customer removes the gun from its holster. Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity. Pumping Paused entry/ # Disengage clutch which stops pumping. # Wait for gun to be replaced into the # holster or for the trigger to be depressed. Ready to Pump entry/ # Start pump motor and wait for the gun trigger to be # depressed or the gun can be replaced. Pumping entry/ # Engage clutch which starts pumping. # Continue until the gun trigger is released Gun ReplacedGun Removed Pump Enabled Trigger Depressed Trigger Released Gun Replaced Fuel Level Low Fuel Available Customer Finished

71 71 K E N N E D Y C A R T E R Return to Contents Outline State Transition Table for Pump Class Gun Removed Gun Replaced Fuel Level Low Fuel Available Non Existent Waiting for Customer Waiting for Pump Enable Ready to Pump Pumping Pumping Paused Pump Enabled State Event Fuel Delivery Complete Fuel Unavailable Trigger Depressed Trigger Released Customer Finished

72 72 K E N N E D Y C A R T E R Return to Contents State Transition Table for Pump Class Gun Removed Gun Replaced Fuel Level Low Fuel Available Non Existent Waiting for Customer Waiting for Pump Enable Ready to Pump Pumping Pumping Paused Pump Enabled State Event Fuel Delivery Complete Fuel Unavailable Trigger Depressed Trigger Released Customer Finished Waiting for Pump Enable Waiting for Customer Fuel Delivery Complete Fuel Unavailable Ready to Pump Fuel Delivery Complete Waiting for Customer Pumping Pumping Paused Ignore Cannot Happen Waiting for Customer Cannot Happen

73 73 K E N N E D Y C A R T E R Return to Contents State Machine with Action Comments for Pump Class Fuel Unavailable entry/ # Inform customer that the pump is unavailable. # Wait for fuel to become available for this pump. Fuel Delivery Complete entry/ # Delivery Now Complete, Stop motor and return pump # to waiting state Waiting for Customer entry/ # The pump is idle. Wait in this state until # a customer removes the gun from its holster. Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity Ready to Pump entry/ # Start pump motor and wait for the gun trigger to be # depressed r the gun can be replaced. Pumping entry/ # Engage clutch which starts pumping. # Continue until the gun trigger is released Gun RemovedGun Replaced Pump Enabled Trigger Depressed Gun Replaced Fuel Level Low Fuel Available Customer Finished Pumping Paused entry/ # Disengage clutch which stops pumping. # Wait for gun to be replaced into the # holster or for the trigger to be depressed. Trigger Depressed Trigger Released Gun Replaced

74 74 K E N N E D Y C A R T E R Return to Contents State Machine with Action Specifications for Pump Class Fuel Unavailable entry/ # Inform customer that the pump is unavailable. # Wait for fuel to become available for this pump. [] = CU1:Pump_Unavailable[] Fuel Delivery Complete entry/ # Delivery Now Complete, Stop motor and return pump # to waiting state current_delivery = this->R3 generate DEL5:Delivery_Complete() to current_delivery [] = MO2:Stop_Motor[] generate PMP12:Customer_Finished() to this Waiting for Customer entry/ # The pump is idle. Wait in this state until # a customer removes the gun from its holster. Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity. supplying_tank = this -> R1 if supplying_tank.Tank_Empty_Flag = TRUE then generate PMP4:Fuel_Level_Low() to this else [] = AT1:Request_Pump_Enable[] endif Ready to Pump entry/ # Start pump motor and wait for the gun trigger to be # depressed r the gun can be replaced. [] = MO1:Start_Motor[] Pumping entry/ # Engage clutch which starts pumping. # Continue until the gun trigger is released [] = CL1:Engage_Clutch[] Gun RemovedGun Replaced Pump Enabled Trigger Depressed Gun Replaced Fuel Level Low Fuel Available Customer Finished Pumping Paused entry/ # Disengage clutch which stops pumping. # Wait for gun to be replaced into the # holster or for the trigger to be depressed. [] = CL2:Disengage_Clutch[] Trigger Depressed Trigger Released Gun Replaced

75 Executable UML Summary

76 76 K E N N E D Y C A R T E R Return to Contents Benefits of The xUML Process The key benefits of the process are: The modelling notations are simple and precise. This makes them easier to learn and use effectively. The xUML models are validated early by simulation. This reduces risk and cuts development costs. The xUML models keep expertise in separate subject matters separate. This delivers large reusable components. The xUML process requires an early study of how best to exploit the implementation technology to deliver the required system performance and reliability. This allows concurrent analysis and design and addresses technical risks early. The xUML models can be translated directly to code. This shortens development time and eliminates redundancy in analysis and design models. The delivered software components have a uniform quality across the entire system. This makes the system easier to understand, and reduces maintenance costs.

77 77 K E N N E D Y C A R T E R Return to Contents Contacts  More papers on xUML are available at:   The authors can be contacted at:  Ian Wilkie  Chris Raistrick  Colin Carter  The Action Semantics Consortium has a Web Site: 


Download ppt "Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. (http://www.kc.com)http://www.kc.com K E N N E D Y C A R T E R V2.3."

Similar presentations


Ads by Google