executable uml (xuml)

Executable UML (xUML)

An Online Tutorial

Kennedy Carter Ltd. (http://www.kc.com)K E N N E D Y C A R T E R

V2.3

http://www.kc.com/

http://www.kc.com/

2 K E N N E D Y C A R T E R

Return to Contents

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

Executable UML

The Need for xUML


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 UMLAction

TerminateAction

DestroyActionUninterpreted

Action

CreateAction CallActionReturnAction

SendAction


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


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 inProgress

TransactionCompleteentry/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!


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 …


Return to Contents

What is xUML?

UML V1.4UML V1.4xUMLxUML = SemanticallyWeak

Elements

SemanticallyWeak

Elements-Precisely Defined Action

Semantics

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


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

AdmitIn Patient

User Interface

U log incident

Patient AdminStatements 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 admission9: 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


Return to Contents


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

R90..1

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 ontheRunway = this -> R9.”is_allocated_to”

# remove the associationunlink this R9 theRunway

# tell the runway that aircraft has landed[] = deallocate[] on theRunway


Return to Contents


..... 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

HashTable LinkedList BoundedArray

GenericClass

0..*1

<TypicalClass>

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


Return to Contents


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

Executable UML

The Notational Subset


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, 1999

...... Executable UML involves choosing the correct ingredients


Return to Contents

What is executable UML ?

The primary models

Hospital SystemDomain Chart

PatientAdministration

ResourceAllocation

LocationTracking

UserInterface

Patient AdministrationClass Model

is using

isbeing used by

1

Out Patient

patient nonext visit date

Bed

ward namebed nobed type

In Patient

patient nonamedate of birth

Patient


is beingused 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 controlEach domain remains independent of other domains and they are connected using Bridges.

BedState Model

Bed Available

entry/# find old patientold_patient = this -> R1

# remove link to old patientunlink this R1 old_patient

Bed Unavailable

entry/# find new patientnew_patient = find-only In_Patient where \ patient_no = new_patient_no

# create link to patientlink 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.


Return to Contents

What is executable UML ?

Supported by ….

Hospital SystemUse Cases

AdmitOut Patient

Administrator AdmitIn Patient

Admit In PatientDomain Sequence Diagram

User Interface

U log incident


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


2:







Admit In PatientObject Sequence Diagram

administrator patient:1 bed:2resource

allocationdomain

admit patient

assign bed

bed assignedpatient now in bed

request case notespatientadmitted

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.


Return to Contents

xUML has no Hierarchical Notations - Just Model Layers

TrainManagement

HardwareInterface

Domains

Hop

negotiateHopaccelCurvePerformedfinalAccelCurvePerformed

startDateendDatedistanceCoveredcurrentState

Train

currentSpeedtimerIdcurrentStatehopNegotiatedfinalHopNegotiated

0..1

1

R2

Classes

2. Waiting For Next Hop

entry/nextHop = this -> R2generate TIM10:setAbsoluteTimer \generate timeToNegotiateNextHop () at \

nextHop.startTime to this

timeToNegotiateNextHop(trainId)

3. Negotiating Hop

entry/nextHop = this -> R2generate H1:negotiateHop() to nextHop

hopNegotiated(trainId)

States

Operations

hopNegotiated

this.currentState = ‘journeyComplete’

Executable UML

The xUML Process in Outline


Return to Contents

AnalysisDocument

An Elaborative Development Process

Analyse

Design

DesignDocument

Implement

SoftwareSystem

manually inmonths or years

manually inmonths or years

• “high level”• informal

• no completion criteria

• “high level”• informal

• no completion criteria

large team of technology

experts

large team of technology

experts

application pollutedby technology

application pollutedby technology

• idiosyncratic components• obsolete documentation

• idiosyncratic components• obsolete documentation

Require-ments

these never stop changing

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.


Return to Contents

AnalysisModel

An Alternative View

Analyse

Apply theAnalysis to

Design Mapping

DesignModel

Apply the Design to Implementation Mapping

SoftwareSystem

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

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.

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.


Return to Contents

AnalysisModel

An Alternative View - Developed

Analyse

Apply theAnalysis to

Implementation Mapping

SoftwareSystem

Require-ments

Analysis to Implementation Mapping

Design

Combine the two mappings as they are applied

sequentially.These can be captured as Design Patterns

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

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.


Return to Contents

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


Return to Contents

xUML Based Development

Implement

SoftwareSystem

automatically inminutes or hours

automatically inminutes or hours

Design

DesignPatterns

small team oftechnology

experts

small team oftechnology

experts

the“software

architecture”

the“software

architecture”

Analyse

xUMLModel

complete,precise & testable

complete,precise & testable

small teams ofapplicationexperts

small teams ofapplicationexperts


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 ModelBuild 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

Executable UML

The xUML Process Steps


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.


Return to Contents

Preparation or Inception Phase


AdmitOut

Patient

AdministratorAdmitIn

Patient

Capture requirements with use cases

Partition system into domains



ResourceAllocation

LocationTracking

UserInterface


User Interface

U log incident


1:dialogue ok hit2:admit in patient

3:assign bed4:bed assigned

5:confirm admission6:display dialogue

8:reject admission9:display dialogue


2:3:find a suitable bed4:if bed available then5: confirm admission6: display “success” dialogue



Identify domain interactions

Patient AdministrationClass Model

is using

isbeing used by

1

Out Patient


Bed


In Patient


Patient



Produce first-cut class diagram for each domain to be modelled


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


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


Administrator Patient:1 Bed:2 ResourceAllocation

LocationTracking

admitPatient

assignBed

bedAssignedpatientNow InBed

requestCaseNotespatientAdmitted

BedState Chart

Bed Available



Bed Unavailable




B4:bed_unassigned

Patient Administration Bed Class

BedwardNamebedNobedType

CheckAvailability()

isOccupied

freeBed = find-one Bed where\ isOccupied = FALSE

Patient Admin to Resource Alloc Bridge

$USE Resource AllocationGenerate allocateResource

ResourceAllocation

PatientAdmin

PatientAdmin<<RequiredInterface>>

Resource Allocation<<ProvidedInterface>>

PatientAdmin<<BridgeClass>>

assignBed

assignBed

allocateResource


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


Return to Contents

The xUML Process Overview


AdmitOut Patient

Administrator AdmitIn Patient

1. Capture Requirements



ResourceAllocation

LocationTracking

UserInterface

2. Partition into Domains


User Interface

U log incident


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


2:






8:else reject admission

9: display “failure” dialogue

3. Define Domain Interfaces

Patient Administration Static Model

is using

isbeing used by

1

Out Patient


Bed


In Patient


Patient



4. Specify Classes

BedState Chart

Bed Available



Bed Unavailable




B4:bed_unassigned

6. Specify Behaviour


5. Define Class Interfaces

Administrator Patient:1 Bed:2 ResourceAllocation

LocationTracking

admitPatient

assignBed

bedAssignedpatientNow InBed

requestCaseNotespatientAdmitted

Executable UML

The xUML Action Language


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.


Return to Contents

BRIDGE Banking:informOfExceededOverdraftLimitCLASS: AccountINPUTS:OUTPUTS:

counterpartDisplayRecord = this -> CPR1$USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE

BRIDGE Banking:informOfExceededOverdraftLimitCLASS: AccountINPUTS:OUTPUTS:

counterpartDisplayRecord = this -> CPR1$USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE

Bridges, for mapping to

other domains

Bridges, for mapping to

other domains

Action Specification Language is used for…

1 CREATING Account

# create a new account with a unique id and the specified opening balancenewAccount = create unique Account with balance = openingBalance# assign today's date to the 'dateOpened' attribute

today= current-datenewAccount.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

Actions, for state-dependent

behaviour

account_1 = create Account with accountId = 32 & \dateOpened = 2000.10.31 & \balance = 22504.96 & \currentState = ‘inGoodStanding’

customer_1 = create unique Customer with ...link account_1 R1 customer_1...

account_1 = create Account with accountId = 32 & \dateOpened = 2000.10.31 & \balance = 22504.96 & \currentState = ‘inGoodStanding’

customer_1 = create unique Customer with ...link account_1 R1 customer_1...

Scenarios, for simulation and system initialisation

Scenarios, for simulation and system initialisation

OPERATION: checkAccountbalanceCLASS: AccountINPUTS:OUTPUT:

if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif

OPERATION: checkAccountbalanceCLASS: AccountINPUTS:OUTPUT:

if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif

Operations, for state

independent behaviour

Operations, for state

independent behaviour


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=33myAccount = 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 Instancesaccount

iddate

openedcurrentstate

32 1996.10.31 inGoodStanding

33 1993.11.05 frozen

balance

22,504.96

-5,427.75

ownerid

462

216

Customer

custIdcustAddresscurrentState

Account

accountIddateOpenedbalanceownerIdcurrentState

1..*1

owns

isowned by

an optional identifier is a set of one or more attributes whose values uniquely distinguish each

instance

R1


Return to Contents

Association Manipulation

Associations are manipulated using association 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 -> R1owningCustomer = this -> R1

do this instead...

Account Instancesaccount

iddate

openedcurrentstate

32 1996.10.31 inGoodStanding

33 1993.11.05 frozen

balance

22,504.96

-5,427.75

ownerid

462

216

isowned by

Customer


Account

accountIddateOpenedbalanceownerIdcurrentState

1..*1

owns

R1


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


Return to Contents

Creating a New Class Instance

The creation operation for Account includes a create statement.

Object DiagramObject Diagram

myCustomer : Customer

myAccount : Account

new Account instance created with arbitrary unique integer value assigned to' accountId' by the

architecture

OPERATION: createAccountINPUTS: owningCustomer: Customer, openingBalance: RealOUTPUTS: newAccount: Account

# create a new account with a unique id & the specified opening balancenewAccount = create unique Account with balance = openingBalance# assign today's date to the 'dateOpened' attributetoday = current-datenewAccount.dateOpened = today# link the new account via relationship R1 to the owning customerlink newAccount R1 owningCustomer

Customer

custId {I-=1}custAddresscurrentState

Account

accountId {I=1}dateOpenedbalanceownerId {R=1}currentState

1..*1

owns

isowned 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


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'



myAccount : Account



isowned byCustomer


Account


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


handle

“current-date” is a pre-defined ASL

feature which returns the current date

“dateOpened” is an attribute

name

“=“ is the assignment

operator


Return to Contents


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


myAccount : Account



Customer


Account


1..*1

ownsisowned by

R1

“link” is an ASL keyword which

links two instances through

a specifed association


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.


Return to Contents



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...

2. navigate the R1 association instance...

3. to obtain the handle of the

related Customer instance

Deleting Account

# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink 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 instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this

deleteAccount()

Customer


Account


1..*1

owns

isowned 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”


Return to Contents



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


deleteAccount()

Customer


Account


1..*1

owns

isowned 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.


Return to Contents



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


deleteAccount()

Customer


Account


1..*1

owns

isowned 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.


Return to Contents



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


deleteAccount()

Customer


Account


1..*1

owns

isowned 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


Return to Contents



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


deleteAccount()

Customer


Account


1..*1

owns

isowned 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


Return to Contents


myAccount : Account

Deleting a Class Instance

The 'delete' statement is used to delete a specified instance...

‘I was right!’

the Account instance for thisstate 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


deleteAccount()

Customer


Account


1..*1

owns

isowned by

R1

“delete” is an ASL keyword

In this case, the state is terminal, and therefore this instance of Account

must be deleted.

Executable UML

System Generation from xUML Models


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….

QueuesScheduler

xUML TimerSignalCommunication


Return to Contents

Abstract Design Model Class Diagram

is executing for

has

Domain

Class

StateModel

Object

State Machine Instance

contains

is part of

holdsattribute

valuesfor

holdsattributeforhas

defines behaviour of

is aninstance of has

Type ofProcess

DataStructure

ActualProcess

DataArea

Type ofProcessor

ActualProcessor

c

events areprocessed by

processesevents for

isexecuting

isrunningin

is server for

is accessed via

specifiesisspecifiedby

specifiesis specified by

canexecute

can beexecutedby

attributevalues are

held inattributesare held in

holds code for

code is held in

StaticxUML

RuntimexUML

RuntimeExecution

CodeAssembly

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


Return to ContentsArchetypal Design and Code Patterns

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 expressed in ASL

{allClasses} = find-all Classfor 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 endforendfor

<ClassName>

<operationName1>():<returnType1><operationName2>():<returnType2>…

<attributeName1>:<attribute1Type><attributeName2>:<attribute2Type><attributeName3>:<attribute3Type><attributeName4>:<attribute4Type> …

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


Return to Contents

Mechanisms

The design patterns provide uniform strategies for common issues……such as persistence…

PersistentClass{abstract}

classNameclassNumber

saveState{abstract}restoreState{abstract}

findFirstfindNext

Mechanism

Pump

saveStaterestoreState

Tank

saveStaterestoreState

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


Return to ContentsMechanisms

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;};

EventQueue

EventQueue()generate (GenericEvent)findEvent (string) : GenericEventconsumeEvent : GenericEventgetFirstEvent : GenericEvent

numberOfEventQueuestheQueue

UML Mechanisms

Queue

QueueElement

<<bind>> (GenericEvent)

Mechanisms can be described using

UML….

…. and code


Return to ContentsInstantiating an Archetype

Use mapping rules to

apply the archetype to

each analysis model

element to produce

code

Customer

getCustAddress


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<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 Classfor 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 endforendfor


Return to Contents

Benefits

Domain partitioning maintains a clear separation between the operations to be performed on data, and the structure of the

data...

xUMLModels

The analysis models specify the required

processing in an implementation-independent way

DesignPatterns

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 ...

TargetCode

TranslationEngine

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.

Executable UML

An xUML Case Study


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

Executable UML

xUML Case Study:

The Problem


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


Return to Contents

Tank B

LeadFree

Tank C

Diesel

Tank A

FourStar

FourStar

LeadFree

LeadFree

FourStar

LeadFree Diesel

FOSSIL FUELS

Example Configuration

1 2 3 4 5 6


Return to Contents

FOSSIL FUELS

Plundering Earth’s Natural Resources for You

25 Feb 2001 16:25

Pump 3 - Four Star 20.00 litres @ 80.0p = £16.00

including VAT @17.5% = £2.38

Thank You for Choosing Fossil

Cost/Litre

Quantity

Cost

80.0p

20.00

£16.00

FourStar

FOSSIL FUELS

Example Data Representations

Executable UML

xUML Case Study:

The xUML Models


Return to Contents

Use Cases for Petrol Station

<<include>> <<extends>>

Make Fuel Delivery

Specify Fuel

Volume

Specify Fuel Value

Make Credit Card

Payment

LogTrans-action

<<extends>>

<<extends>>

<<include>>

<<include>>

<<include>>

Make Payment

Attendant

Credit Card Validator

Buy Non-Fuel Goods

Customer

Buy Fuel


Return to Contents

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.

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.


Return to Contents

Domain Chart for Petrol Station System

PetrolStationControl

PumpInterface

AttendantInterface

HardwareInterface


Return to Contents

Information Model for Petrol Station Control Domain

pumpNumbertankNumber

Pump

timepumpNumbervolumeDeliveredcost

Delivery

tankNumbergradeNametankEmptyFlagtankLeveltankCapacityemptyThreshold

Tank

gradeNameunitPrice

Fuel GradetransactionNumberpumpNumbertransactionTypecosttransactionProcessTimedeliveryStartTime

Transaction

transactionNumberobservations

Evaded Transaction

transactionNumber

Paid Transaction

transactionNumberpumpNumber

Pending Transaction

ispumpingfuel from

is providing fuel for

1*

is beingmade using

is being used for

10..1

stores 1

is stored in *

is pending for

1

delivered fuel for

0..1

has delivered fuel for *

records fuel delivery for

1

R3 R1

R9

R10

R4

R2


Return to ContentsOutline Class Collaboration Diagram for Delivery Management Domain

<<interface>>

Meter

<<interface>>

Holster

<<interface>>

Motor

<<interface>>

Clutch

<<interface>>

Gun

<<interface>>

Customer

<<interface>>

Attendant

<<interface>>

Tanker Operator

Transaction

Delivery

Pump

Tank


Return to Contents

Preliminary CCD for Delivery Management Domain

<<interface>>

Meter

<<interface>>

Holster

<<interface>>

Motor

<<interface>>

Clutch

<<interface>>

Gun

<<interface>>

Customer

<<interface>>

Attendant

<<interface>>

Tanker Operator

Transaction

Delivery

Pump

Tank

createDelivery

pumpEnabled

triggerDepressed

requestPumpEnable

gunRemoved

startMotor


Return to Contents

Complete CCD for Delivery Management Domain

<<interface>>

Meter

<<interface>>

Holster

<<interface>>

Motor

<<interface>>

Clutch

<<interface>>

Gun

<<interface>>

Customer

<<interface>>

Attendant

<<interface>>

Tanker Operator

Transaction

Delivery

Pump

Tank

createTransaction

paymentReceived

customer Absconds

transactionPending

createDelivery

pumpEnabled

fuelUnitDelivered

deliveryCompletestartMotor

stopMotor

engageClutch

disengageClutch

triggerDepressed

triggerReleased

pumpUnavailable

fuelAvailable

requestPumpEnable

tankerDelivery

fuelUsed

gunRemoved

gunReplaced


Return to Contents

(Part of) State Machine for Pump Class

Waiting for Customerentry/# 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 Enableentry/# Determine whether the connected tank

contains# more than 4% of its capacity.

Gun Removed

Gun Removed

Fuel Level Low

Please identify the remaining states and transitions.


Return to Contents

State Machine for Pump Class

Fuel Unavailableentry/# Inform customer that the pump is

unavailable.# Wait for fuel to become available for this

pump.

Fuel Delivery Completeentry/# Delivery Now Complete, Stop motor and return

pump# to waiting state



contains# more than 4% of its capacity.

Pumping Pausedentry/# Disengage clutch which stops pumping.# Wait for gun to be replaced into the# holster or for the trigger to be depressed.

Ready to Pumpentry/# Start pump motor and wait for the gun trigger to

be# depressed or the gun can be replaced.

Pumpingentry/# Engage clutch which starts pumping.# Continue until the gun trigger is released

Gun Replaced Gun Removed

Pump Enabled

Trigger Depressed

Trigger Depressed

Trigger Released

Gun Replaced

Gun Replaced

Gun Replaced

Fuel Level Low

Fuel Available

Customer Finished


Return to Contents

Outline State Transition Table for Pump Class

GunRemoved

GunReplaced

FuelLevel Low

FuelAvailable

Non Existent

Waiting for Customer

Waiting for Pump Enable

Ready to Pump

Pumping

Pumping Paused

PumpEnabledState

Event

Fuel Delivery Complete

Fuel Unavailable

TriggerDepressed

TriggerReleased

CustomerFinished


Return to Contents

State Transition Table for Pump Class

GunRemoved

GunReplaced

FuelLevel Low

FuelAvailable

Non Existent

Waiting for Customer


Ready to Pump

Pumping

Pumping Paused

PumpEnabledState

Event

Fuel Delivery Complete

Fuel Unavailable

TriggerDepressed

TriggerReleased

CustomerFinished


Waiting for

CustomerFuel

Delivery Complete

Fuel Delivery

Complete

Fuel Unavailable

Ready to Pump

Fuel Delivery

Complete

Waiting for

Customer

Pumping

Pumping

Pumping Paused

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore Ignore

Ignore Ignore

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Cannot Happen

Waiting for

Customer

Cannot Happen


Return to Contents

State Machine with Action Comments for Pump Class



pump.


pump# to waiting state



contains# more than 4% of its capacity


be# depressed r the gun can be replaced.

Pumpingentry/# Engage clutch which starts pumping.# Continue until the gun trigger is released

Gun Removed Gun Replaced

Pump Enabled

Trigger Depressed

Gun Replaced

Gun Replaced

Fuel Level Low

Fuel Available

Customer Finished

Pumping Pausedentry/# 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


Return to Contents

State Machine with Action Specifications for Pump Class



pump.[] = CU1:Pump_Unavailable[]


pump# to waiting statecurrent_delivery = this->R3generate DEL5:Delivery_Complete() to

current_delivery[] = MO2:Stop_Motor[]generate PMP12:Customer_Finished() to this



contains# more than 4% of its capacity.supplying_tank = this -> R1if supplying_tank.Tank_Empty_Flag = TRUE

then generate PMP4:Fuel_Level_Low() to thiselse [] = AT1:Request_Pump_Enable[]endif


be# depressed r the gun can be replaced.[] = MO1:Start_Motor[]

Pumpingentry/# Engage clutch which starts pumping.# Continue until the gun trigger is released[] = CL1:Engage_Clutch[]

Gun Removed Gun Replaced

Pump Enabled

Trigger Depressed

Gun Replaced

Gun Replaced

Fuel Level Low

Fuel Available

Customer Finished

Pumping Pausedentry/# 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

Executable UML

Summary


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.


Return to Contents

Contacts

More papers on xUML are available at: http://www.kc.com

The authors can be contacted at: Ian Wilkie [email protected] Chris Raistrick [email protected] Colin Carter [email protected]

The Action Semantics Consortium has a Web Site: http://www.umlactionsemantics.org

executable uml (xuml)

Documents