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

2. Contents
The Need for xUML
The Notational Subset
The xUML Process
The xUML Action Language
System Generation from xUML Models
An xUML Case Study
Summary
Click on a subject or just use the down and up arrow keys to browse through the tutorial

3. Executable UML
The Need for xUML

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

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

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

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

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

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

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

11. <TypicalClass>
Why an Executable UML ?
A solid specification
Supports multiple development teams
Well defined models mean well defined interfaces
Easier Transition to Design and Code
No ambiguity in the models - the models have a single clear interpretation
Design can be specified using abstract patterns
GenericContainer
HashTable
LinkedList
BoundedArray
GenericClass
0..* 1
<TypicalClass>
..... eliminates maintenance problems due to redundant analysis and design models
Supports extensive code generation if desired
Lack of ambiguity means automatic code generation will deliver functionally correct code

12. Why an Executable UML ?
and finally It’s more fun !
Analysts see the results of their efforts more rapidly and have more confidence that what they are doing is correct
Managers get more confidence that progress is being made

13. Executable UML
The Notational Subset

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

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

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

17. xUML has no Hierarchical Notations - Just Model Layers
Operations
hopNegotiated
this.currentState = ‘journeyComplete’
Train Management
Hardware
Interface
Domains
Hop
negotiateHop
accelCurvePerformed
finalAccelCurvePerformed
startDate
endDate
distanceCovered
currentState
Train
currentSpeed
timerId
hopNegotiated
finalHopNegotiated
0..1 1 R2
Classes
2. Waiting For Next Hop
entry/
nextHop = this -> R2
generate TIM10:setAbsoluteTimer \
generate timeToNegotiateNextHop () at \ nextHop.startTime to this
timeToNegotiateNextHop
(trainId)
3. Negotiating Hop
generate H1:negotiateHop() to nextHop
hopNegotiated
States

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

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

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

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

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

23. xUML Based Development
Design
Patterns
small team of
technology
experts
the
“software
architecture”
Analyse
xUML
Model
complete,
precise & testable
small teams of
application
experts
Implement
Software
System
automatically in
minutes or hours

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

25. Executable UML
The xUML Process Steps

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

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

28. The Preparation of Inception Phase
Preparation or Inception Phase aim is to:
scope the project
engineer the requirements
partition the system into domains
identify new, reused or COTS domains
produce first cut class and interaction diagrams for new domains
consider system and software architecture issues
identify key risks
produce size and cost estimates
This phase does not produce any executable models but provides the foundation for the next phase

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

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

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

32. The xUML Action Language
Executable UML
The xUML Action Language

33. The Action Specification Language
A key component of xUML is the Action Language
This section provides a broad summary of the capabilities of ASL , supported by some examples.
Preferable to use relationship navigation whenever feasible - faster.
Error if not exactly one customer. When testing, exceptions raised.

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

35. Instance Manipulation
Instances are manipulated using instance handles is
owned by
Customer
custId
custAddress
currentState
Account
accountId
dateOpened
balance
ownerId
currentState
owns 1 R1
1..*
Account Instances
account id
date
opened
current
state 32
inGoodStanding 33
frozen
balance
22,504.96
-5,427.75
owner
462
216
an instance handle is a reference to a specific instance
an optional identifier is a set of one or more attributes whose values uniquely distinguish each instance
Preferable to use relationship navigation whenever feasible - faster.
Error if not exactly one customer. When testing, exceptions raised.
myAccount = find-only Account where accountId=33
In many contexts, a special instance handle named “this” is always available which contains the instance handle of the instance that is executing the current action.

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

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

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

39. Assigning Attribute Values
Any action may assign local variables and attribute values...
“current-date” is a pre-defined ASL feature which returns the current date
OPERATION: createAccount
INPUTS: owningCustomer: Customer, openingBalance: Real
OUTPUTS: newAccount: Account
# create a new account with a unique id & the specified opening balance
newAccount = create unique Account with balance = openingBalance
# assign today's date to the 'dateOpened' attribute
today = current-date
newAccount.dateOpened = today
# link the new account via relationship R1 to the owning customer
link newAccount R1 owningCustomer
This assignment would have more appropriately been made as part of the 'create' statement
“newAccount” is an instance handle
“=“ is the assignment operator
“today” is a local variable which is declared by first use
the 'dateOpened' attribute is assigned the value returned by the operation 'current_date'
Keywords can be in any case.
If “dateOpened” not of type date, type mismatch error at compile time.
Everything typed by 1st use.
“dateOpened” is an attribute name
Object Diagram
myCustomer : Customer
myAccount : Account is
owned by
Customer
custId {I-=1}
custAddress
currentState
Account
accountId {I=1}
dateOpened
balance
ownerId {R=1}
1..* 1
owns R1

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

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

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

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

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

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

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

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

48. Software Design Model – The Elements
To implement a software design model, we will construct:
A class model of the abstract software design.
Design Patterns (archetypes).
Code Patterns in the target language.
Mapping rules from xUML.
A tagging scheme.
Mechanisms….
Queues
Scheduler
xUML Timer
Signal
Communication

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

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

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

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

53. Analysis Model Element
Instantiating an Archetype
C++ Code Archetype
class Class<ClassName> {
public:
<returnType1> <operationName1>();
<returnType2> <operationName2>();
//……….
private:
static char *className;
static char *classKeyLetter;
//…….
<attribute1Type> <attributeName1>;
<attribute2Type> <attributeName2>;
<attribute3Type> <attributeName3>;
<attribute4Type> <attributeName4>; };
Mapping Rules in ASL
{allClasses} = find-all Class
for eachClass in {allClasses} do
# create a class called Class<ClassName>
# with the attributes of Class as static items
{theAttributes} = eachClass -> R1
for eachAttribute in {theAttributes} do
# create a private member data item
# corresponding to the attribute
# with type eachAttribute.dataType
endfor
Customer
getCustAddress
custId
custAddress
currentState
Analysis Model Element
Generated C++ Code
class ClassCustomer {
public:
custAddressType getCustAddress();
private:
static char *className;
static char *classKeyLetter; //
int custId;
custAddressType custAddress;
int currentState };
Use mapping rules to apply the archetype to each analysis model element to produce code

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

55. Executable UML
An xUML Case Study

56. An xUML Case Study
This section presents a Case Study problem and (part of) a solution as xUML models
The Case Study is a Petrol (Gas) Station control system
The same Case Study is used in the turorial for the iUML toolset. Using this you can:
Interactively develop your models
See the models executing

57. xUML Case Study: The Problem
Executable UML
xUML Case Study:
The Problem

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

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

60. Four Star Example Data Representations
Cost/Litre
Quantity
Cost
80.0p
20.00
£16.00
Four
Star
FOSSIL FUELS
FOSSIL FUELS
Plundering Earth’s Natural Resources for You
25 Feb :25
Pump 3 - Four Star p = £16.00
including = £2.38
Thank You for Choosing Fossil

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

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

63. Definition of “Make Fuel Delivery” Use Case
Use Case Name Make Fuel Delivery.
Purpose To allow a paying customer to deliver fuel of a customer selected grade.
Preconditions The desired fuel grade is available.
Invariants Tank level > 4% tank capacity while pump is turned on.
Primary Scenario 1. Customer removes gun from holster;
2. Attendant enables pump;
3. Customer selects one fuel grade;
4. Pump motor is started;
5. Customer uses trigger to control fuel delivery, causing the system to engage/disengage pump clutch as trigger is depressed/released;
6. Customer replaces gun in holster;
Pump motor is stopped.
Postconditions At least two litres of fuel have been delivered.
The pump gun is in the holster.
The pump motor is off.
Secondary Scenario 1 Customer delivers less than two litres of fuel.
Postconditions Less than two litres of fuel have been delivered.
Secondary Scenario 2 Tank level falls below 4%..
Postconditions All pumps connected to tank are disabled..
Secondary Scenario 3 Customer releases trigger but does not return gun to holster.
Postconditions Pump switched off after timeout period..
Performance Specification
Trigger Customer removes gun from holster.
Periodicity Aperiodic.
Rate 60/hour.

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

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

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

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

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

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

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

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

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

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

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

75. Executable UML
Summary

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

77. Contacts
More papers on xUML are available at:
The authors can be contacted at:
Ian Wilkie
Chris Raistrick
Colin Carter
The Action Semantics Consortium has a Web Site: