xUML Tutorial

7/27/2019 xUML Tutorial

1/77

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/77

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


3/77

Executable UML

The Need for xUML


4/77


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 thedesired results (classes, associations, operations, state machines)

The latter specification of behaviour is the basis for implementing thesystem, but is missing key ingredients:

the implementation of operations (methods) are specified only by alanguage dependent text string

the actions associated with state machines (and methods) arespecified either by a text string, or by using the action part of theUML

Action

Terminate

Action

DestroyActionUninterpreted

Action

CreateAction CallActionReturnAction

SendAction


5/775 K E N N E D Y C A R T E R

Return to Contents

Action Specifications in UML 1.4

Cannot be attached to methods and cannot therefore be used to specifyoperations

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 modellinglanguage

UML covers many development paradigms

Synchronous and asynchronous behaviour

State dependent and stateless behaviour

Mealy state machines and Moore state machines

Flat state models and Harel state charts

Abstract analysis modelling and code specific design modelling Language specific modelling and abstract modelling

Sometimes the breadth of coverage can lead to ambiguity...

Transaction in

Progress

Transaction

Completeentry/

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 ideabecause that

combination of behaviouris undefined!



Return to Contents

Actions and the UML

In 1994 Kennedy Carter created the Action Specification Language, whichoperates at the same level of abstraction as UML

but embodies the precision to allow models to be executed andconsequently 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 PreciseAction 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

R t t C t t



Return to Contents

What is xUML?

UML V1.4xUML = SemanticallyWeakElements-

PreciselyDefined Action

Semantics+

xUML is

an executable versionof the UML, with

clearly defined simple model structure

a precise semantics for actions, which will be incorporated into theUML standard

a compliant action specification language

an accompanying process

a proven development process, oriented towards

executable modelling large-scale reuse

pattern based design

R t t C t t



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 admission

9: display failure dialogue

Class group by class group

Early Verification

Requirements can be validated before extensive system design andcoding

This supports iterative andincremental development

An executable model can bedeveloped and tested even ifit supports only a single use

case

Groups of classes at thecollaboration, subsystem,

package or domain level canbe modelled and executed

Return to Contents


10/7710 K E N N E D Y C A R T E R

Return to Contents


Improves the quality of the modelling

Models can be judged not just on subjective criteria, but on whether they exhibitthe 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 thisidentify the

correct runway todeallocate ?

# 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


11/7711 K E N N E D Y C A R T E R

Return to Contents


..... eliminates maintenance problems due to redundant analysis anddesign models

Supports extensive code generation if desired

Lack of ambiguity means automatic code generation will deliverfunctionally correct code

GenericContainer

HashTable LinkedList BoundedArray

GenericClass

0..*1

A solid specification

Supports multiple development teams

Well defined models mean well defined interfaces

Easier Transition to Design and Code

No ambiguity in the models - the models have a single clearinterpretation

Design can be specified using abstract patterns

Return to Contents


12/7712 K E N N E D Y C A R T E R

Return to Contents


and finally ..... Its more fun !

Analysts see the results of their efforts more rapidly and have moreconfidence that what they are doing is correct

Managers get more confidence that progress is being made


13/77

Executable UML

The Notational Subset

Return to Contents


14/77


Design aims of UML

The designers of UML did not intend that developers would use all of theformalism at any one time

Rather, they intended it to support a particular paradigm for a particular

type of development

Its like being a cook. You have to know how to use virtually all ofthe possible ingredients. Just not all at the same time.

Jim Rumbaugh, 1999

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

Return to Contents


15/77


What is executable UML ?

The primary models

Hospital SystemDomain Chart

PatientAdministration

ResourceAllocation

LocationTracking

UserInterface

Patient AdministrationClass Model

is using

isbeingused 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 encapsulatesthe models that describe asingle subject matterarea.Domains will be focused onvarious subject matters in thesystem such as :The customer viewpointGeneric services

Hardware controlEach domain remainsindependent of otherdomains and they areconnected 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 ofthe static model and capturesthe key abstractions andassociations within a domain.It is the foundation of thedomain model.

The state chart captures thedynamic behaviourof theactive classes.

Return to Contents


16/77


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:




6: display success dialogue



9: display failure dialogue

Admit In PatientObject Sequence Diagram

ad min is tr ato r p atient:1 bed:2resource

allocationdomain

admit patient

assign bed

bed ass igned

patient nowin bed

request case notespatientadmitted

Use cases provide aninformal description ofrequired behaviour from ausers perspective.

The domain level sequence diagramshows how a use case is realised bythe cooperation of the variousdomains in the system. The lifelineson the sequence diagram correspondto domains. The interactions between

domains serve to indicate whichservices a domain must provide,which services a domain requires ofother domains and specifies thebridge requirements.

Within each domain an object levelsequence diagram shows how the usecase will be realised by the interactionbetween objects. The lifelines on thesequence diagram correspond toobjects. The interactions betweenobjects serve to indicate whichoperations a class must provide andthe messages to be sent from onclass to another.

Return to Contents


17/77


xUML has no Hierarchical Notations - Just Model Layers

TrainManagement

HardwareInterface

Domains

Hop

negotiateHopaccelCurvePerformedfinalAccelCurvePerformed

startDateendDatedistanceCoveredcurrentState

TraincurrentSpeedtimerIdcurrentState

hopNegotiatedfinalHopNegotiated

0..1

1

R2

Classes

2. Waiting For Next Hopentry/nextHop = this -> R2generate TIM10:setAbsoluteTimer \generate timeToNegotiateNextHop () at \

nextHop.startTime to this

timeToNegotiateNextHop(trainId)

3. Negotiating Hopentry/nextHop = this -> R2generate H1:negotiateHop() to nextHop

hopNegotiated(trainId)

States

Operations

hopNegotiatedthis.currentState = journeyComplete


18/77

Executable UML

The xUML Process in Outline

Return to ContentsAn Elaborative Development Process


19/77


AnalysisDocument

An Elaborative Development Process

Analyse

Design

DesignDocument

Implement

SoftwareSystem

manually inmonths or years

high levelinformal

no completion criteria

large team oftechnology

experts

application pollutedby technology

idiosyncratic componentsobsolete documentation

Require-ments

these never stopchanging

Of course, with any type ofdevelopment, the exactrequirements are almost neverknown upfront. This means thatsome iteration must beperformed until the final solutionis achieved.

With elaborative development,the iteration must often includeexecution of (sections of) theimplemented code.

Changes that result from iterativedevelopment must somehow beapplied to the analysisdocuments, the designdocuments and to the final code.

Reverse engineering(round trip) tools areusually successful only atkeeping the design andcode in step

The analysisdocument is thenquickly abandonedand becomes out ofdate.

Return to ContentsAn Alternative View


20/77


AnalysisModel

An Alternative View

Analyse

Apply theAnalysis toDesign Mapping

DesignModelApply the Design toImplementation Mapping

SoftwareSystem

A good analysis modelis a specification

of required behaviour.Executable analysismodels are suitable

for mapping to designand implementation

If the mappings aresystematic then this

view becomesoptional

This is produced by applying the mappings to theanalysis model. The analysis model and themappings are maintained and the code isnt.

Require-mentsAnalysis toDesign Mapping

DesignDesign is about the specifying the mapping from the

implementation independent view in the analysis model tothe implementation dependent view in the design model and

implementation.This can be done class by class or more systematically.

Design toImplementation Mapping

Iteration can be achieveddirectly at this level becausethe analysis models areprecise enough to beexecuted and subjected to

actual tests.

Such Iteration can beperfomed on parts of theanalysis model (single usecases), class groups or thewhole model

The design model can alsobe developed with iterativedevelopment and, ifrequired, this can be donebefore the applicationanalysis is started. This isbecause the designcaptures patterns forimplementing any xUML

model

Iteration can be also beachieved at this level in thesame way as elaborativedevelopment, if required.

Return to ContentsAn Alternative View - Developed


21/77


AnalysisModel

An Alternative View - Developed

Analyse

Apply theAnalysis toImplementation Mapping

SoftwareSystem

Require-mentsAnalysis toImplementation Mapping

Design

Combine the two mappings asthey are applied

sequentially.These can becaptured as Design Patterns

This can be done manually or,with a code generator,

automatically

Automatic code generation means thatIteration can be achieved at this levelwithout any model getting out of step. Thisis because changes are made either to thedesign or to the analysis models(depending on the nature of the change)and the system is then regenerated.

Return to Contents


22/77


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 separateconcerns separate throughout

Partition the system into domainsShorten development times by maximising the scopefor concurrent development of different parts of thesystem

Analyse the domains concurrently

Reduce cost of defect removal by testing at theearliest opportunity

Build executable analysis models

Improve code quality by formalising systematicdesign patterns

Formalise a fully-specified abstract design model

Reduce coding and maintenance costs by generatinga system composed of software units that haveuniform quality and structure

Automate the application of the abstract design rules

Return to Contents


23/77


xUML Based Development

Implement

SoftwareSystem

automatically inminutes or hours

Design

DesignPatterns

small team oftechnology

experts

thesoftware

architecture

Analyse

xUMLModelcomplete,

precise &testable

small teams ofapplicationexperts

Return to Contents

O i f th UML P


24/77


Overview of the xUML Process

The xUML process can besummarised 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 ABSTRACTDESIGN MODEL

Select or develop suitable patternsand mechanisms

(Build/Buy xUML compiler)

PRODUCE TARGET CODE

Apply design patterns to xUML models(manually or automatically)

Perform target testing


25/77

Executable UML

The xUML Process Steps

Return to Contents

Th UML P St


26/77


The xUML Process Steps

Whats the process for developing executable models ?

No process is linear so this section illustrates only the steps that aretaken, 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 toapplication models

This section of the tutorial describes the general principles of thePreparation and Modelling Phases. The application of Modelling to abstractdesign and the automatic execution of the construction phase is describedlater.

Return to Contents



27/77




AdmitOut

Patient

AdministratorAdmitIn

Patient

Capture requirements with use cases

Partition system into domains


PatientAdministration

ResourceAllocation

LocationTracking

UserInterface

Admit In Patient

Domain Sequence Diagram

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


8:else reject admission9: display failure dialogue

Identify domain interactionsPatient AdministrationClass Model

isusing

isbeingusedby

1

Out Patient

patient nonext visitdate

Bed


In Patient


Patient



Produce first-cut class diagram for eachdomain to be modelled

Return to Contents

The Preparation of Inception Phase


28/77


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 thefoundation for the next phase

Return to Contents

Modelling or Elaboration Phase


29/77



Produce the interaction diagram

Develop state charts for classes and specifyactions using an action language

Add operations to classes and specifythem using an action language

Specify bridges between domains


Administrator Patient:1 Bed:2ResourceAllocation

LocationTracking

admitPatient

assignBed

bedAssigned

patientNowInBed

requestCaseNotes

patientAdmitted

BedState Chart

Bed Available


# remove link to old patient unlink this R1 old_patient

Bed Unavailable





B4:bed_unassigned

Patient AdministrationBed Class

BedwardNamebedNobedType

CheckAvailability()

isOccupied

freeBed = find-one Bed where\isOccupied = FALSE

Patient Admin to Resource Alloc Bridge

$USE Resource Allocation

Generate allocateResource

ResourceAllocation

PatientAdmin

PatientAdmin

Resource Allocation

PatientAdmin

assignBed

assignBed

allocateResource

Return to Contents



30/77



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


31/77



Admit

Out Patient

Administrator Admit

In Patient

1. Capture Requirements


Patient

Administration

Resource

Allocation

Location

Tracking

User

Interface

2. Partition into Domains

Admit I n 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:




6: disp lay success dialogue



9: disp lay failure dialogue

3. Define Domain Interfaces

Patient AdministrationStatic Model

is using

isbeingused by

1

Out Patient

patient nonext visit date

Bed


In Patient


Patient



4. Specify Classes

BedState Chart

Bed Available


# remove link to old patient unlink this R1 old_patient

Bed Unavailable





B4:bed_unassigned

6. Specify Behaviour


5. Define Class Interfaces

Administrator Patient:1 Bed:2ResourceAllocation

LocationTracking

admitPatient

assignBed

bedAssignedpatientNowInBed

requestCaseNotes

patientAdmitted


32/77

Executable UML

The xUML Action Language

Return to Contents

The Action Specification Language


33/77


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

Action Specification Language is used for


34/77


BRIDGE Banking:informOfExceededOverdraftLimitCLASS: Account

INPUTS:

OUTPUTS:

counterpartDisplayRecord = this -> CPR1

$USE UI

[] = DR7:highlightRecord[] on counterpartDisplayRecord

$ENDUSE

Bridges, formapping to other

domains

p g g

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' attributetoday= current-datenewAccount.dateOpened = today# get the handle of the owning customer instanceowningCustomer = find-only Customer where custId = custId# link the new account via relationship R1 to the owning customerlink newAccount R1 owningCustomer

AC1:createAccount(custId,openingBalance)

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

...

Scenarios, forsimulation and

systeminitialisation

OPERATION: checkAccountbalanceCLASS: AccountINPUTS:OUTPUT:

if this.balance < 0 thengenerate overdrawn() to this

elsegenerate accountOk() to this

endif

Operations, forstate independentbehaviour

Return to Contents

Instance Manipulation


35/77


p

Instances are manipulated using instance handles

an instance handleis a referenceto a specific instance

myAccount = find-only Account where accountId=33

In many contexts, a special instance handle named this is always availablewhich contains the instance handle of the instance that is executing thecurrent action.

Account Instances

accountid

dateopened

currentstate

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 identifieris a set of one or more attributeswhose values uniquely distinguish each instance

R1

Return to Contents

Association Manipulation


36/77


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

owningCustomer = 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

is

owned byCustomer


Account

accountIddateOpenedbalanceownerIdcurrentState

1..*1

owns

R1

Return to Contents

Specifying Actions


37/77


The Action Specification Language provides a process modelling formalismthat 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


38/77


The creation operation for Account includes a create statement.

Object Diagram

myCustomer : Customer

myAccount : Account

new Account instance created witharbitrary 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

is

owned by

R1

newAccountis an instance

handle

Account isa classname

balance is anattribute of theAccount class

openingBalance is aninput parameter to this

operationcreate unique

provides an arbitraryidentifier value, usecreate to definespecific identifying

attributes

Return to Contents

Assigning Attribute Values


39/77


Any action may assign local variables and attribute values...

the 'dateOpened' attribute is assigned thevalue returned by the operation

'current_date'

Object Diagram


myAccount : Account


is

owned byCustomer


Account


1..*1

owns

R1

today is a localvariable which isdeclared by first

use

This assignmentwould have more

appropriately beenmade as part of the'create' statement


handle

current-date is apre-defined ASL

feature which returnsthe current date

dateOpenedis an attribute

name

= is theassignment

operator

Return to Contents

Creating an Association Instance


40/77


Object Diagram

The analyst specifies when and how association instances are created...

a new instance of R1 is created, linking the newaccount instance to the owning customer instance

found earlier


myAccount : Account


Customer


Account


1..*1

ownsisowned by

R1

link is an ASLkeyword which

links two instancesthrough a specifed

association


handle

R1 identifiesthe association

owningCustomeris an instance

handle

In this case, the class diagram statesthe policythat each instance of Account

is owned by exactly one instance ofCustomer.

The ASL enforces this policyby creating

an instance of association R1 wheneveran instance of Account is created.

Return to Contents

Navigating to a Related Instance


41/77


Object Diagram


myAccount : Account

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

3. to obtain the handleof 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 thengenerate 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 instancehandle of the instance

associated with the statemachine or instance-based

operation executing thecurrent action.

owningCustomer isthe single instancehandle that resultsfrom the navigationto the 1 end of an

association

This line can be read asThe owningCustomer

can be found bynavigating from this

through R1

Return to Contents

Deleting a Association Instance


42/77


Object Diagram


myAccount : Account

The analyst specify when associationinstances are deleted...

the R1 association instancelinking this Account instanceand the owning Customer

instance is deleted

goodbye, world

now I'm a dangling

customer!


deleteAccount()

Customer


Account


1..*1

owns

is

owned by

R1

this is the ASLkeyword that

represents theinstance executingthe state machine

R1 identifiesthe

association

unlink is the ASLkeyword which

removes the linkbetween two

associated instances

owningCustomer isan instance handle

In this case, theanalyst is about to

delete an instance ofAccount. Prior to

this, the dyingAccount instancemust be unlinked

from all of its relatedinstances.

Return to Contents

Navigating to a Set of Instances


43/77


Object Diagram


myAccount : Account

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 Accountinstance handles (an empty

set in this scenario)

2. navigate the R1 associationinstances (there are none in this

scenario)

1. starting from

the owningCustomer instance


deleteAccount()

Customer


Account


1..*1

owns

is

owned by

R1

In this case, since the analystis navigating to the manyend of an association, the

navigation will deliver a set of(zero or more) Account

instances. The {} symbols areused denote a set.

Return to Contents

Determining if a Set is Empty


44/77


Object Diagram


myAccount : Account

The cardinality of a set can be determinedusing the 'countof' function...

I've got a feeling I

won't last muchlonger

I know howyou feel


deleteAccount()

Customer


Account


1..*1

owns

is

owned by

R1

In this case, the analyst wishesto determine if the Accountinstance that is about to die isthe last instance owned by the

owning Customer instance.

If so, then the multiplicity of theassociation requires that the

owning Customer instance bedeleted, since it is now related to

zero instances of Account.

countof is an ASLkeyword that returns thenumber of instances of

the specified set

if then else endifis an ASL controllogic construct

Return to Contents

Sending a Signal Event


45/77


Object Diagram


myAccount : Account

It is possible to send an event to a specifiedinstance of a class in the same domain usingthe generate...to construct...

the signal 'deleteCustomer is sent to the specifiedinstance of Customer


deleteAccount()

Customer


Account


1..*1

owns

is

owned by

R1

generate is anASL keywordthat denotes a

signal send

to is an ASL keyword thatdenotes that the signal is sentto the specified instance. tomust always be followed by a

valid instance handle

Here, the signal carries nosupplemental data, hencethe empty parameter list

denoted by (). Signalparameters are comma

separated if there are any.

deleteCustomer is the signal

name

Return to Contents

Deleting a Class Instance


46/77


Object Diagram

myAccount : Account

The 'delete' statement is usedto delete a specified instance...

I wasright!

the Account instance for thisstate machine has been deleted. This is guaranteed

to have been deleted by the time this actioncompletes.

the Customer instance has been deleted as a result of the deletion event to theowning Customer's state machine (NOTE: it cannot be guaranteedthat this event has

been processed yet)


deleteAccount()

Customer


Account


1..*1

owns

is

owned by

R1

delete is anASL keyword

In this case, the state isterminal, and therefore

this instance of Accountmust be deleted.


47/77

Executable UML

System Generation fromxUML Models

Return to Contents

Software Design Model The Elements


48/77


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


49/77


is executing for

has

Domain

Class

StateModel

Object

State MachineInstance

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

specifies

is

specifiedby

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 metamodel for the xUML modelelements and consequentlyit doesnt change. This is agreatly simplified version!

This quadrant is the metamodel for an executingxUML model at runtimeand likewise it doesntchange. It is a static

model of the xUML virtualmachine.

This quadrant capturesthe properties of the

software build. It may bevery simple in some

projects.

This quadrant captures thetarget software runtime view. Itmust meet the requirements of

the xUML virtual machine. Theclasses in this quadrant willdepend on the type of system

being built, eg real timeembedded or information

system.

Associations that span thequadrants define

characteristics of thearchitecture such as

distribution, threading andqueuing policies

Return to ContentsArchetypal Design and Code Patterns

C++ Code ArchetypeD i A h t


50/77


C++ Code Archetype

class Class{public: (); ();//.

private:static char *className;static char *classKeyLetter;//. ; ; ; ;//.

};

Mapping Rules expressed in ASL

{allClasses} = find-all Classfor eachClass in {allClasses} do# create a class called Class# with the attributes of Class as static items{theAttributes} = eachClass -> R1

for eachAttribute in {theAttributes} do# create a private member data item# corresponding to the attribute# with type eachAttribute.dataType

endforendfor

():():

::

::

Design Archetype

This is a UML class which describes adesign pattern which can be applied toeach class in the analysis model. It can

be used to show how attributes andoperations from the analysis classes will

map into the design and also how

instances will be contained, howassociations will be realised, etc.Expressing the design model in the formof patterns keeps it free from applicationspecific concepts and therefore easier to

maintain.

This is a code version (C++ in thisexample) of the design pattern. The

actual code is created by substitutingthe corresponding elements of the

analysis model into the places denotedby the delimiters. Clearly substitutionof this form is mechanical and therefore

amenable to automatic code generationif desired.

This is a meta level descriptionwhich defines how the elements

of the analysis model will bemapped into the target code. It

is defined using ASL

Return to Contents

Mechanisms

Th d i tt id if t t i f i


51/77


The design patterns provide uniform strategies for common issuessuch as persistence

PersistentClass{abstract}

classNameclassNumber

saveState{abstract}restoreState{abstract}

findFirst

findNext

Mechanism

Pump

saveStaterestoreState

Tank

saveStaterestoreState

Classes mapped

from applicationand service domain

xUML models

A mechanism is a part of the design andtarget code which does not derive fromthe analysis models by substitution but

provides some generic capability.Mechanisms are commonly used toimplement signal queuing, instance

containers, persistance services andcommunications

Return to ContentsMechanisms


52/77


Coded Mechanisms

//--------------------------------------// Event Queue

//--------------------------------------class EventQueue{public:EventQueue();void generate (GenericEvent*);GenericEvent *findEvent (char*);GenericEvent *consumeEvent ();GenericEvent *getFirstEvent ();

private:

virtual ~EventQueue ();Queue *theQueue;static numberOfEventQueues;

};

EventQueue

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

consumeEvent : GenericEventgetFirstEvent : GenericEvent

numberOfEventQueuestheQueue

UML Mechanisms

QueueQueueElement

(GenericEvent)

Mechanisms can bedescribed using

UML.

. and code

Return to ContentsInstantiating an Archetype

C++ Code ArchetypeMapping Rules in ASL


53/77


Use mappingrules to apply thearchetype toeach analysismodel element toproduce 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

};

class Class{public: (); ();

//.private:static char *className;static char *classKeyLetter;//. ; ; ; ;//.

};

Mapping Rules in ASL

{allClasses} = find-all Classfor eachClass in {allClasses} do# create a class called Class# with the attributes of Class as static items

{theAttributes} = eachClass -> R1for 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


54/77


Domain partitioning maintains a clear separationbetween the operations tobe performed on data, and the structure of the data...

xUMLModels

The analysis models

specify the requiredprocessing in animplementation-independent way

DesignPatterns

The patterns provide

templates for a rangeof data structures,along with rules and a

tagging scheme todetermine their use

The software architecture domainencapsulates the design decisionsthat

define how components of theimplementation are to be generated from

components of the analysis.

This allows the classes to be fully specifiedin an abstract, implementation-independent,

formalism ...TargetCode

TranslationEngine

The generatedcode is not a

directly

maintaineddeliverable... and translatedinto a variety of

implementations ...

... that do not have to be based on classes.


55/77

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


56/77


This section presents a Case Study problem and (part of) a solution asxUML 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 thisyou can:

Interactively develop your models

See the models executing


57/77

Executable UML

xUML Case Study:

The Problem

Return to Contents

Case Study System Requirements

Petrol Station Control System Requirements

BACK
http://localhost/var/www/apps/ian.000/Desktop/Downloaded%20Eudora%20Attachments/C%20-%20Domains%20v2.ppthttp://localhost/var/www/apps/ian.000/Desktop/Downloaded%20Eudora%20Attachments/C%20-%20Domains%20v2.ppthttp://localhost/var/www/apps/ian.000/Desktop/Downloaded%20Eudora%20Attachments/C%20-%20Domains%20v2.ppt


58/77


y q

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

Before a customer can use the self-service pumps, the pump must be enabled by the attendant. When a pump is enabled, thepump motor is started, if it is not already on, with the pump clutch free. When the trigger in the gun is depressed, closing a microswitch, the clutch is engaged and petrol pumped. When it is released, the clutch is freed. There is also a micro switch on theholster in which the gun is kept which prevents petrol being pumped until the gun is taken out. Once the gun is replaced in theholster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannotdispense 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 calculatedusing 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 therequired quantity.

Transactions are stored until the customer pays. Payment may be either in cash, by credit card or account. A customer mayrequest a receipt (showing price, time, date etc.) and will get a token for every 5 pounds. Customers sometimes abscond withoutpaying and the operator must annotate the transaction with any available information, the vehicles registration number forexample. 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 twotanks, one tank for each grade. The tank level must not drop below 4% of the tanks capacity. If this happens, the pumpsserviced 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 designdocuments, code listings and so on.

Return to Contents

FOSSIL FUELS

Example Configuration


59/77


Tank B

LeadFree

Tank C

Diesel

Tank A

FourStar

Four

Star

Lead

Free

Lead

Free

Four

Star

Lead

FreeDiesel

FOSSIL FUELS

1 2 3 4 5 6

Return to Contents

Example Data Representations


60/77


FOSSIL FUELS

Plundering Earths 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

Four

Star

FOSSIL FUELS


61/77

Executable UML

xUML Case Study:

The xUML Models

Return to Contents

Use Cases for Petrol Station


62/77


Make FuelDelivery

Specify FuelVolume

Specify FuelValue

Make CreditCard

Payment

LogTrans-action

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.


63/77


y

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


64/77


PetrolStation

Control

Pump

Interface

Attendant

Interface

HardwareInterface

Return to Contents

Information Model for Petrol Station Control Domain


65/77


pumpNumbertankNumber

Pump

time

pumpNumbervolumeDeliveredcost

Delivery

tankNumbergradeNametankEmptyFlagtankLeveltankCapacityemptyThreshold

Tank

gradeNameunitPrice

Fuel Grade

transactionNumber

pumpNumbertransactionTypecosttransactionProcessTimedeliveryStartTime

Transaction

transactionNumberobservations

Evaded TransactiontransactionNumber

Paid TransactiontransactionNumberpumpNumber

Pending Transaction

ispumpingfuel from

is providingfuel for

1*

is beingmade using

is beingused for

10..1

stores 1

is stored in *

is pendingfor

1

deliveredfuel for

0..1

has deliveredfuel for *

records fueldelivery for

1

R3 R1

R9

R10

R4

R2

Return to Contents

Outline Class Collaboration Diagram for Delivery Management Domain

Meter


66/77


Meter

Holster

Motor

Clutch

Gun

Customer

Attendant

Tanker

Operator

Transaction

Delivery

Pump

Tank

Return to Contents

Preliminary CCD for Delivery Management Domain

Meter


67/77


Meter

Holster

Motor

Clutch

Gun

Customer

Attendant

Tanker

Operator

Transaction

Delivery

Pump

Tank

createDelivery

pumpEnabled

triggerDepressed

requestPumpEnable

gunRemoved

startMotor

Return to Contents

Complete CCD for Delivery Management Domain

Meter

customerAbsconds


68/77


Meter

Holster

Motor

Clutch

Gun

Customer

Attendant

Tanker

Operator

Transaction

Delivery

Pump

Tank

createTransaction

paymentReceived

transactionPending

createDelivery

pumpEnabled

fuelUnitDelivered

deliveryComplete

startMotor

stopMotor

engageClutch

disengageClutch

triggerDepressed

triggerReleased

pumpUnavailablefuelAvailable

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 untilThe Colloboration


69/77


p p# a customer removes the gun from its holster.

Gun Replaced

Diagram shows thatthe Pump classreceives the followingsignals

Pump Enabled

Trigger Depressed

Trigger Released

Assume that theWaiting for PumpEnable action willalso 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 theremaining states andtransitions.

Return to Contents

State Machine for Pump Class

Waiting for Customerentry/# The pump is idle. Wait in this state until

Customer Finished


70/77


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

# a customer removes the gun from its holster.

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

Return to Contents

Outline State Transition Table for Pump Class


71/77


GunRemoved

GunReplaced

FuelLevel Low

FuelAvailable

Non Existent

Waiting forCustomer

Waiting forPump Enable

Ready toPump

Pumping

PumpingPaused

PumpEnabledState

Event

Fuel DeliveryComplete

FuelUnavailable

TriggerDepressed

TriggerReleased

CustomerFinished

Return to Contents

State Transition Table for Pump Class


72/77


GunRemoved

GunReplaced

FuelLevel Low

FuelAvailable

Non Existent

Waiting forCustomer

Waiting forPump Enable

Ready toPump

Pumping

PumpingPaused

PumpEnabledState

Event

Fuel DeliveryComplete

FuelUnavailable

TriggerDepressed

TriggerReleased

CustomerFinished

Waiting forPumpEnable

Waiting forCustomer

FuelDelivery

Complete

FuelDelivery

Complete

FuelUnavailable

Ready toPump

FuelDelivery

Complete

Waiting forCustomer

Pumping

Pumping

PumpingPaused

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore

Ignore Ignore

Ignore Ignore

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

CannotHappen

Waiting forCustomer

CannotHappen

Return to Contents

State Machine with Action Comments for Pump Class

Waiting for Customerentry/# The pump is idle. Wait in this state until# a customer removes the gun from its holster

Customer Finished


73/77


Fuel Unavailableentry/# Inform customer that the pump is unavailable.# Wait for fuel to become available for this pump.


# Delivery Now Complete, Stop motor and return pump# to waiting state


Waiting for Pump Enableentry/# Determine whether the connected tank contains# more than 4% of its capacity

Ready to Pumpentry/# Start pump motor and wait for the gun trigger to 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

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

Waiting for Customerentry/# The pump is idle. Wait in this state until# a customer removes the gun from its holster

Customer Finished


74/77


Fuel Unavailableentry/

# Inform customer that the pump is unavailable.# Wait for fuel to become available for this pump.[] = CU1:Pump_Unavailable[]


# Delivery Now Complete, Stop motor and return pump# to waiting statecurrent_delivery = this->R3generate DEL5:Delivery_Complete() to current_delivery[] = MO2:Stop_Motor[]generate PMP12:Customer_Finished() to this


Waiting for Pump Enableentry/# Determine whether the connected tank contains# more than 4% of its capacity.supplying_tank = this -> R1if supplying_tank.Tank_Empty_Flag = TRUE thengenerate PMP4:Fuel_Level_Low() to this

else[] = AT1:Request_Pump_Enable[]

endif

Ready to Pumpentry/# Start pump motor and wait for the gun trigger to 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

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


75/77

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.


76/77


g p p

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

This delivers large reusable components.

The xUML process requires an early study of how best to exploit theimplementation technology to deliver the required systemperformance and reliability.

This allows concurrent analysis and design and addressestechnical risks early.

The xUML models can be translated directly to code.

This shortens development time and eliminates redundancy inanalysis and design models.

The delivered software components have a uniform quality acrossthe entire system.

This makes the system easier to understand, and reducesmaintenance costs.

Return to Contents

Contacts

More papers on xUML are available at:

http://www.kc.com
http://www.kc.com/http://www.kc.com/


77/77


http://www.kc.com

The authors can be contacted at:

Ian Wilkie [email protected]

Chris [email protected]

Colin Carter [email protected]

The Action Semantics Consortium has a Web Site:

http://www.umlactionsemantics.org
http://www.kc.com/mailto:[email protected]:[email protected]:[email protected]://www.umlactionsemantics.org/http://www.umlactionsemantics.org/mailto:[email protected]:[email protected]:[email protected]://www.kc.com/

Documents

xUML Tutorial