Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Online Tutorial Executable UML (xUML) K E N N E D Y C A R T E R

Similar presentations


Presentation on theme: "An Online Tutorial Executable UML (xUML) K E N N E D Y C A R T E R"— Presentation transcript:

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

2 Contents The Need for xUML The Notational Subset The xUML Process The xUML Action Language System Generation from xUML Models An xUML Case Study 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 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 DestroyAction Uninterpreted CreateAction CallAction ReturnAction SendAction

5 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 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... I have absolutely no idea because that combination of behaviour is undefined! e.g. what happens if you execute a “return” in a transition action stimulated by “call” (synchronous) event ? Transaction in Progress Transaction Complete entry/ log transaction Transaction Completed/ if is_aborted then return

7 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 Precisely Defined Action Semantics
What is xUML? 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 UML V1.4 xUML = Semantically Weak Elements - Precisely Defined Action Semantics +

9 This supports iterative and incremental development
Why an Executable UML ? Measurable Deliverables Models that execute tests correctly Can be delivered in phases with progressive integration Use case by use case Class group by class group Early Verification Requirements can be validated before extensive system design and coding This supports iterative and incremental development Admit In Patient User Interface U log incident Patient Admin Statements Resource 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 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 correct runway to deallocate ?
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 Aircraft clearedRunway() Runway deallocate() 0..1 is_ allocated_to R9 # 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 Does this identify the correct runway to deallocate ? Focused analyst objective The aim is to build models that execute correctly Avoids “analysis paralysis” Reviews criteria are objective and therefore more useful

11 <TypicalClass>
Why an Executable UML ? 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 GenericContainer HashTable LinkedList BoundedArray GenericClass 0..* 1 <TypicalClass> ..... 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

12 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 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, 1999 Executable UML involves choosing the correct ingredients

15 Patient Administration
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 name date of birth Patient is being used by 0..1 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 # 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 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. 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. A set of execution rules dealing with Assumptions about when asynchronous messages are responded to Order of message processing Interruption of processing Parallel execution The state chart captures the dynamic behaviour of the active classes.

16 What is executable UML ? Supported by …. Hospital System Use Cases
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. Supported by …. Hospital System Use Cases Admit Out Patient Administrator Admit In Patient Admit In Patient Domain Sequence Diagram User Interface U log incident Patient Admin Statements Resource 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.

17 xUML has no Hierarchical Notations - Just Model Layers
Operations hopNegotiated this.currentState = ‘journeyComplete’ Train Management Hardware Interface Domains Hop negotiateHop accelCurvePerformed finalAccelCurvePerformed startDate endDate distanceCovered currentState Train currentSpeed timerId hopNegotiated finalHopNegotiated 0..1 1 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 generate H1:negotiateHop() to nextHop hopNegotiated States

18 The xUML Process in Outline
Executable UML The xUML Process in Outline

19 An Elaborative Development Process
Changes that result from iterative development must somehow be applied to the analysis documents, the design documents and to the final code. Require- ments Analyse large team of technology experts 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. Analysis Document “high level” informal no completion criteria Design manually in months or years Design Document application polluted by technology Implement The analysis document is then quickly abandoned and becomes out of date. Reverse engineering (round trip) tools are usually successful only at keeping the design and code in step idiosyncratic components obsolete documentation Software System With elaborative development, the iteration must often include execution of (sections of) the implemented code.

20 Implementation Mapping Implementation Mapping
An Alternative View 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 Analysis to Design Mapping Require- ments Analyse Such Iteration can be perfomed on parts of the analysis model (single use cases), class groups or the whole model Apply the Analysis to Design Mapping Design to Implementation Mapping Analysis 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 A good analysis model is a specification of required behaviour. Executable analysis models are suitable for mapping to design and implementation Iteration can be achieved directly at this level because the analysis models are precise enough to be executed and subjected to actual tests. Design Model If the mappings are systematic then this view becomes optional Apply the Design to Implementation Mapping This is produced by applying the mappings to the analysis model. The analysis model and the mappings are maintained and the code isn’t. Software System Iteration can be also be achieved at this level in the same way as elaborative development, if required.

21 An Alternative View - Developed
Design Combine the two mappings as they are applied sequentially.These can be captured as Design Patterns Analysis to Implementation Mapping Require- ments Analyse Analysis Model Apply the Analysis to Implementation Mapping 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. Software System

22 Objectives of the xUML Process
The primary objectives of a development process based on xUML are: Objective Achieved 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 xUML Based Development
Design Patterns small team of technology experts the “software architecture” Analyse xUML Model complete, precise & testable small teams of application experts Implement Software System automatically in minutes or hours

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

25 Executable UML The xUML Process Steps

26 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 Preparation or Inception Phase
Hospital System Use Cases Admit Out Patient Administrator Admit In Patient Hospital System Domain Chart Patient Administration Resource Allocation Location Tracking User Interface Capture requirements with use cases Partition system into domains Admit In Patient Domain Sequence Diagram User Interface U log incident Patient Admin Statements Resource 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 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 name date of birth Patient is being used by 0..1 Identify domain interactions Produce first-cut class diagram for each domain to be modelled

28 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 Modelling or Elaboration Phase
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 # 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 Produce the interaction diagram Develop state charts for classes and specify actions using an action language 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 <<RequiredInterface>> Resource Allocation <<ProvidedInterface>> <<BridgeClass>> assignBed allocateResource Add operations to classes and specify them using an action language Specify bridges between domains

30 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 The xUML Process Overview
1. Capture Requirements 2. Partition into Domains 3. 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 name date of birth Patient is being 0..1 4. Specify Classes Admit In Patient Object Sequence Diagram 5. Define Class Interfaces 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 # 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

32 The xUML Action Language
Executable UML The xUML Action Language

33 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. Preferable to use relationship navigation whenever feasible - faster. Error if not exactly one customer. When testing, exceptions raised.

34 Action Specification Language is used for…
1 CREATING 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 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 BRIDGE Banking:informOfExceededOverdraftLimit CLASS: Account INPUTS: OUTPUTS: counterpartDisplayRecord = this -> CPR1 $USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE Bridges, for mapping to other domains 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 Preferable to use relationship navigation whenever feasible - faster. Error if not exactly one customer. When testing, exceptions raised.

35 Instance Manipulation
Instances are manipulated using instance handles is owned by Customer custId custAddress currentState Account accountId dateOpened balance ownerId currentState owns 1 R1 1..* Account Instances account id date opened current state 32 inGoodStanding 33 frozen balance 22,504.96 -5,427.75 owner 462 216 an instance handle is a reference to a specific instance an optional identifier is a set of one or more attributes whose values uniquely distinguish each instance Preferable to use relationship navigation whenever feasible - faster. Error if not exactly one customer. When testing, exceptions raised. 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.

36 Association Manipulation
Associations are manipulated using association primitives is owned by Customer custId custAddress currentState Account accountId dateOpened balance ownerId 1..* 1 owns R1 Account Instances account id date opened current state 32 inGoodStanding 33 frozen balance 22,504.96 -5,427.75 owner 462 216 So, to navigate from this instance of Account to the owning customer, do not do this... Preferable to use association navigation whenever feasible - faster. Error if not exactly one customer. When testing, exceptions raised. theOwnerId = this.owner_id owningCustomer = find-only Customer where custId = theOwnerId do this instead... owningCustomer = this -> R1

37 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 Creating a New Class Instance
The creation operation for Account includes a create statement. 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 “openingBalance” is an input parameter to this operation “balance” is an attribute of the Account class “newAccount” is an instance handle “create unique” provides an arbitrary identifier value, use “create” to define specific identifying attributes new Account instance created with arbitrary unique integer value assigned to' accountId' by the architecture “Account” is a class name Object Diagram myCustomer : Customer myAccount : Account Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} 1..* 1 owns is owned by R1

39 Assigning Attribute Values
Any action may assign local variables and attribute values... “current-date” is a pre-defined ASL feature which returns the current date 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 This assignment would have more appropriately been made as part of the 'create' statement “newAccount” is an instance handle “=“ is the assignment operator “today” is a local variable which is declared by first use the 'dateOpened' attribute is assigned the value returned by the operation 'current_date' Keywords can be in any case. If “dateOpened” not of type date, type mismatch error at compile time. Everything typed by 1st use. “dateOpened” is an attribute name Object Diagram myCustomer : Customer myAccount : Account is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} 1..* 1 owns R1

40 Creating an Association Instance
The analyst specifies when and how association instances are created... 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 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. “newAccount” is an instance handle “owningCustomer” is an instance handle “link” is an ASL keyword which links two instances through a specifed association a new instance of R1 is created, linking the new account instance to the owning customer instance found earlier Preferable to use relationship navigation whenever feasible - faster. Error if not exactly one customer. When testing, exceptions raised. “R1” identifies the association Object Diagram myCustomer : Customer is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account

41 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. deleteAccount() 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 AC6:delete_account (accountId) This line can be read as “The owningCustomer can be found by navigating from this through 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 Note this is a terminal state, so it has a “delete this”. 3. to obtain the handle of the related Customer instance Object Diagram is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* 2. navigate the R1 association instance... 1. starting from 'this' Account instance... myAccount : Account

42 Deleting a Association Instance
The analyst specify when association instances are deleted... deleteAccount() 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. 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 “unlink” is the ASL keyword which removes the link between two associated instances “this” is the ASL keyword that represents the instance executing the state machine “owningCustomer” is an instance handle “R1” identifies the association Object Diagram is owned by myCustomer : Customer ‘now I'm a dangling customer!’ Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns the R1 association instance linking this Account instance and the owning Customer instance is deleted ‘goodbye, world’ 1 R1 1..* myAccount : Account

43 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. deleteAccount() 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 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. Object Diagram 1. starting from the owning Customer instance is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* 2. navigate the R1 association instances (there are none in this scenario) myAccount : Account 3. to obtain a set of Account instance handles (an empty set in this scenario)

44 Determining if a Set is Empty
The cardinality of a set can be determined using the 'countof' function... deleteAccount() 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. 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 if then else endif is an ASL control logic construct “countof” is an ASL keyword that returns the number of instances of the specified set Object Diagram is owned by myCustomer : Customer ‘I've got a feeling I won't last much longer’ Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account ‘I know how you feel’

45 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... deleteAccount() 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 “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 “deleteCustomer” is the signal name Here, the signal carries no supplemental data, hence the empty parameter list denoted by (). Signal parameters are comma separated if there are any. “generate” is an ASL keyword that denotes a signal send the signal 'deleteCustomer’ is sent to the specified instance of Customer Object Diagram is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account

46 Deleting a Class Instance
The 'delete' statement is used to delete a specified instance... deleteAccount() 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 In this case, the state is terminal, and therefore this instance of Account must be deleted. “delete” is an ASL keyword 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) Object Diagram is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account ‘I was right!’

47 System Generation from xUML Models
Executable UML System Generation from xUML Models

48 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…. Queues Scheduler xUML Timer Signal Communication

49 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 defines behaviour of is an instance of Type of Process Data Structure Actual Area Processor c events are processed by processes events for is executing is running in is server for is accessed via specifies is 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 Associations that span the quadrants define characteristics of the architecture such as distribution, threading and queuing policies 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 is the meta model for the xUML model elements and consequently it doesn’t change. This is a greatly simplified version! 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.

50 Mapping Rules expressed in ASL
Archetypal Design and Code Patterns <ClassName> <operationName1>():<returnType1> <operationName2>():<returnType2> <attributeName1>:<attribute1Type> <attributeName2>:<attribute2Type> <attributeName3>:<attribute3Type> <attributeName4>:<attribute4Type> Design Archetype C++ Code Archetype class Class<ClassName> { public: <returnType1> <operationName1>(); <returnType2> <operationName2>(); //………. private: static char *className; static char *classKeyLetter; //……. <attribute1Type> <attributeName1>; <attribute2Type> <attributeName2>; <attribute3Type> <attributeName3>; <attribute4Type> <attributeName4>; }; 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 Mapping Rules expressed in ASL {allClasses} = find-all Class for eachClass in {allClasses} do # create a class called Class<ClassName> # 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

51 Classes mapped from application and service domain xUML models
Mechanisms The design patterns provide uniform strategies for common issues… …such as persistence… PersistentClass {abstract} className classNumber saveState{abstract} restoreState{abstract} findFirst findNext Mechanism 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 Pump saveState restoreState Tank Classes mapped from application and service domain xUML models

52 Mechanisms can be described using UML….
EventQueue EventQueue() generate (GenericEvent) findEvent (string) : GenericEvent consumeEvent : GenericEvent getFirstEvent : GenericEvent numberOfEventQueues theQueue UML Mechanisms Queue QueueElement <<bind>> (GenericEvent) Coded Mechanisms // // Event Queue class EventQueue { public: EventQueue(); void generate (GenericEvent*); GenericEvent *findEvent (char*); GenericEvent *consumeEvent (); GenericEvent *getFirstEvent (); private: virtual ~EventQueue (); Queue<GenericEvent *> *theQueue; static numberOfEventQueues; }; Mechanisms can be described using UML…. …. and code

53 Analysis Model Element
Instantiating an Archetype C++ Code Archetype class Class<ClassName> { public: <returnType1> <operationName1>(); <returnType2> <operationName2>(); //………. private: static char *className; static char *classKeyLetter; //……. <attribute1Type> <attributeName1>; <attribute2Type> <attributeName2>; <attribute3Type> <attributeName3>; <attribute4Type> <attributeName4>; }; Mapping Rules in ASL {allClasses} = find-all Class for eachClass in {allClasses} do # create a class called Class<ClassName> # 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 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 }; Use mapping rules to apply the archetype to each analysis model element to produce code

54 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 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 xUML Case Study: The Problem
Executable UML xUML Case Study: The Problem

58 Case Study System Requirements
BACK 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.

59 Example Configuration
FOSSIL FUELS 1 2 3 4 5 6 Four Star Lead Free Lead Free Four Star Lead Free Diesel Tank A Four Star Tank B Lead Free Tank C Diesel

60 Four Star Example Data Representations
Cost/Litre Quantity Cost 80.0p 20.00 £16.00 Four Star FOSSIL FUELS 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

61 xUML Case Study: The xUML Models
Executable UML xUML Case Study: The xUML Models

62 Use Cases for Petrol Station
Specify Fuel Volume <<extends>> Make Fuel Delivery <<include>> <<extends>> Buy Non-Fuel Goods Customer Buy Fuel Specify Fuel Value <<include>> Make Payment <<extends>> Attendant <<include>> Make Credit Card Payment <<include>> Log Trans-action Credit Card Validator

63 Definition of “Make Fuel Delivery” Use Case
Use Case Name Make Fuel Delivery. Purpose To allow a paying customer to deliver fuel of a customer selected grade. Preconditions The desired fuel grade is available. Invariants Tank level > 4% tank capacity while pump is turned on. Primary Scenario 1. 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. Postconditions At least two litres of fuel have been delivered. The pump gun is in the holster. The pump motor is off. Secondary Scenario 1 Customer delivers less than two litres of fuel. Postconditions Less than two litres of fuel have been delivered. Secondary Scenario 2 Tank level falls below 4%.. Postconditions All pumps connected to tank are disabled.. Secondary Scenario 3 Customer releases trigger but does not return gun to holster. Postconditions Pump switched off after timeout period.. Performance Specification Trigger Customer removes gun from holster. Periodicity Aperiodic. Rate 60/hour.

64 Domain Chart for Petrol Station System
Control Attendant Interface Pump Interface Invite contributions for application, service and implementation domains. After presenting domain chart, invite suggestions for key classes in each domain., starting with application. e.g. IO - Register, Bit, Card - bit values map to application ideas (see signal list in TN-03) Logging - Actual Log, Type of Log Comms - Message, Type of Message, Type of Field Hardware Interface

65 Information Model for Petrol Station Control Domain
0..1 R3 1 * R1 1 Delivery pumpNumber tankNumber Pump tankNumber gradeName tankEmptyFlag tankLevel tankCapacity emptyThreshold Tank is being used for is being made using is providing fuel for is pumping fuel from time pumpNumber volumeDelivered cost 1 R10 records fuel delivery for is pending for 1 has delivered fuel for is stored in * * R2 transactionNumber pumpNumber transactionType cost transactionProcessTime deliveryStartTime Transaction stores 1 R9 gradeName unitPrice Fuel Grade 0..1 R4 delivered fuel for transactionNumber observations Evaded Transaction transactionNumber Paid Transaction transactionNumber pumpNumber Pending Transaction

66 Outline Class Collaboration Diagram for Delivery Management Domain
<<interface>> Meter <<interface>> Attendant Transaction Delivery Pump <<interface>> Holster <<interface>> Motor <<interface>> Clutch <<interface>> Gun <<interface>> Tanker Operator Tank <<interface>> Customer

67 Preliminary CCD for Delivery Management Domain
<<interface>> Meter <<interface>> Attendant Transaction Delivery gunRemoved Pump <<interface>> Holster pumpEnabled createDelivery startMotor <<interface>> Motor requestPumpEnable <<interface>> Clutch triggerDepressed <<interface>> Gun <<interface>> Tanker Operator Tank <<interface>> Customer

68 Complete CCD for Delivery Management Domain
customer Absconds <<interface>> Meter <<interface>> Attendant Transaction Delivery fuelUnitDelivered paymentReceived transactionPending createTransaction gunRemoved Pump <<interface>> Holster pumpEnabled createDelivery gunReplaced startMotor <<interface>> Motor deliveryComplete stopMotor requestPumpEnable engageClutch <<interface>> Clutch disengageClutch fuelUsed triggerDepressed <<interface>> Gun <<interface>> Tanker Operator Tank triggerReleased tankerDelivery fuelAvailable pumpUnavailable <<interface>> Customer

69 (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. The Colloboration Diagram shows that the Pump class receives the following signals… Gun Removed Gun Removed Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity. Gun Replaced Pump Enabled Trigger Depressed Trigger Released Fuel Available Customer Finished Assume that the “Waiting for Pump Enable” action will also detect the signal: Fuel Level Low Please identify the remaining states and transitions.

70 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. Customer Finished Fuel Available Gun Replaced Gun Removed Fuel Unavailable entry/ # Inform customer that the pump is unavailable. # Wait for fuel to become available for this pump. Fuel Level Low Waiting for Pump Enable entry/ # Determine whether the connected tank contains # more than 4% of its capacity. Gun Replaced Pump Enabled Fuel Delivery Complete entry/ # Delivery Now Complete, Stop motor and return pump # to waiting state Gun Replaced Ready to Pump entry/ # Start pump motor and wait for the gun trigger to be # depressed or the gun can be replaced. Gun Replaced Trigger Depressed Trigger Released Pumping Paused entry/ # Disengage clutch which stops pumping. # Wait for gun to be replaced into the # holster or for the trigger to be depressed. Pumping entry/ # Engage clutch which starts pumping. # Continue until the gun trigger is released Trigger Depressed

71 Outline State Transition Table for Pump Class
Event State Gun Removed Gun Replaced Fuel Level Low Fuel Available Pump Enabled Trigger Depressed Trigger Released Customer Finished Non Existent Waiting for Customer Waiting for Pump Enable Ready to Pump Pumping Pumping Paused Fuel Delivery Complete Fuel Unavailable

72 State Transition Table for Pump Class
Event State Gun Removed Gun Replaced Fuel Level Low Fuel Available Pump Enabled Trigger Depressed Trigger Released Customer Finished Non Existent Cannot Happen Waiting for Customer Waiting for Customer Waiting for Pump Enable Waiting for Customer Fuel Delivery Complete Fuel Unavailable Ready to Pump Pumping Pumping Paused Ignore Waiting for Pump Enable Ready to Pump Pumping Pumping Paused Fuel Delivery Complete Fuel Unavailable

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

74 State Machine with Action Specifications for Pump Class
Waiting for Customer entry/ # The pump is idle. Wait in this state until # a customer removes the gun from its holster. Customer Finished Fuel Available Gun Removed Gun Replaced Fuel Unavailable entry/ # Inform customer that the pump is unavailable. # Wait for fuel to become available for this pump. [] = CU1:Pump_Unavailable[] Fuel Level Low 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 Gun Replaced 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 Pump Enabled Gun Replaced 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[] Gun Replaced Trigger Depressed Trigger Released 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[] Pumping entry/ # Engage clutch which starts pumping. # Continue until the gun trigger is released [] = CL1:Engage_Clutch[] Trigger Depressed

75 Executable UML Summary

76 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 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 "An Online Tutorial Executable UML (xUML) K E N N E D Y C A R T E R"

Similar presentations


Ads by Google