Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. () K E N N E D Y C A R T E R V2.3.
-
Upload
sterling-fourman -
Category
Documents
-
view
215 -
download
0
Transcript of Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. () K E N N E D Y C A R T E R V2.3.
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
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
4 K E N N E D Y C A R T E R
Return to Contents
Why is the the UML 1.4 not executable ?
It is incomplete UML describes a system in, broadly, two ways:
by specifying the desired results (use cases, sequence diagrams)
by specifying the software that, when executed, will produce the desired results (classes, associations, operations, state machines)
The latter specification of behaviour is the basis for implementing the system, but is missing key ingredients: the implementation of operations (methods) are specified
only by a “language dependent” text string the actions associated with state machines (and methods)
are specified either by a text string, or by using the “action” part of the UMLAction
TerminateAction
DestroyActionUninterpreted
Action
CreateAction CallActionReturnAction
SendAction
5 K E N N E D Y C A R T E R
Return to Contents
Action Specifications in UML 1.4
Cannot be attached to methods and cannot therefore be used to specify operations
Do not cover the full range of information required to model real behaviour No conditional logic Do not deal with internal data within an Action Sequence Cannot describe reading and writing of attributes Cannot describe manipulation and navigation of associations Cannot describe parallel behaviour Not related to the UML type model
Do not have fully defined semantics
..... were intended only as a place holder for future UML development
6 K E N N E D Y C A R T E R
Return to Contents
Why is the current UML not executable ?
It is big UML was conceived as a Universal as well as Unified modelling
language UML covers many development paradigms
Synchronous and asynchronous behaviour State dependent and stateless behaviour Mealy state machines and Moore state machines Flat state models and Harel state charts Abstract analysis modelling and code specific design
modelling Language specific modelling and abstract modelling
Sometimes the breadth of coverage can lead to ambiguity...
Transaction inProgress
TransactionCompleteentry/log transaction
Transaction Completed/ if is_aborted then return
e.g. what happens if you execute a “return” in a transition action
stimulated by “call” (synchronous) event ?
I have absolutely no idea because that
combination of behaviour is undefined!
7 K E N N E D Y C A R T E R
Return to Contents
Actions and the UML
In 1994 Kennedy Carter created the Action Specification Language, which operates at the same level of abstraction as UML…
…but embodies the precision to allow models to be executed and consequently supports translation of the models into any language.
The OMG has recognised the need for a full action specification in the UML
In November 1998 the OMG issued a Request for Proposals on Precise Action Semantics for the UML
Kennedy Carter is a key participant in the main submitting consortium …
…and is confident that ASL will be compliant with the emerging standard.
The proposal was submitted in August 2000 and is supported by …
8 K E N N E D Y C A R T E R
Return to Contents
What is xUML?
UML V1.4UML V1.4xUMLxUML = SemanticallyWeak
Elements
SemanticallyWeak
Elements-Precisely Defined Action
Semantics
Precisely Defined Action
Semantics+
xUML is an executable version of the UML, with…
clearly defined simple model structure a precise semantics for actions, which will be incorporated
into the UML standard a compliant action specification language an accompanying process
a proven development process, oriented towards… executable modelling large-scale reuse pattern based design
9 K E N N E D Y C A R T E R
Return to Contents
Why an Executable UML ?
Measurable Deliverables Models that execute tests correctly Can be delivered in phases with progressive integration
Use case by use case
AdmitIn Patient
User Interface
U log incident
Patient AdminStatements Resource Alloc
1:dialogue ok hit
2:admit in patient
3:assign bed
4:bed assigned
5:confirm admission
6:display dialogue
8:reject admission
9:display dialogue
1:op selects admit in patient
2:
3:find a suitable bed
4:if bed available then
5: confirm admission
6: display “success” dialogue
7: log admission details
8:else reject admission9: display “failure” dialogue
Class group by class group Early Verification
Requirements can be validated before extensive system design and coding
This supports iterative and incremental development
An executable model can be developed and tested even if it supports only a single use
case
Groups of classes at the collaboration, subsystem,
package or domain level can be modelled and executed
10 K E N N E D Y C A R T E R
Return to Contents
Why an Executable UML ?
Improves the quality of the modelling Models can be judged not just on subjective criteria, but on whether
they exhibit the desired behaviour and thus meet requirements
Focused analyst objective The aim is to build models that execute correctly Avoids “analysis paralysis” Reviews criteria are objective and therefore more useful
Aircraft
clearedRunway()
Runway
deallocate()
0..1
is_allocated_to
R90..1
Does this identify the
correct runway to deallocate ?
Does this identify the
correct runway to deallocate ?
# obtain an instance handle for # the runway we just landed ontheRunway = this -> R9.”is_allocated_to”
# remove the associationunlink this R9 theRunway
# tell the runway that aircraft has landed[] = deallocate[] on theRunway
11 K E N N E D Y C A R T E R
Return to Contents
Why an Executable UML ?
..... eliminates maintenance problems due to redundant analysis and design models
Supports extensive code generation if desired Lack of ambiguity means automatic code generation will
deliver functionally correct code
GenericContainer
HashTable LinkedList BoundedArray
GenericClass
0..*1
<TypicalClass>
A solid specification Supports multiple development teams Well defined models mean well defined interfaces
Easier Transition to Design and Code No ambiguity in the models - the models have a single clear
interpretation Design can be specified using abstract patterns
12 K E N N E D Y C A R T E R
Return to Contents
Why an Executable UML ?
and finally ..... It’s more fun ! Analysts see the results of their efforts more rapidly and have
more confidence that what they are doing is correct Managers get more confidence that progress is being made
14 K E N N E D Y C A R T E R
Return to Contents
Design aims of UML
The designers of UML did not intend that developers would use all of the formalism at any one time
Rather, they intended it to support a particular paradigm for a particular type of development
“It’s like being a cook. You have to know how to use virtually all of the possible ingredients. Just not all at the same time.”
Jim Rumbaugh, 1999
...... Executable UML involves choosing the correct ingredients
15 K E N N E D Y C A R T E R
Return to Contents
What is executable UML ?
The primary models
Hospital SystemDomain Chart
PatientAdministration
ResourceAllocation
LocationTracking
UserInterface
Patient AdministrationClass Model
is using
isbeing used by
1
Out Patient
patient nonext visit date
Bed
ward namebed nobed type
In Patient
patient nonamedate of birth
Patient
patient nonamedate of birth
is beingused by 0..1
A set of execution rules dealing with Assumptions about when asynchronous messages are
responded to Order of message processing Interruption of processing Parallel execution
Each domain encapsulates the models that describe a single subject matter area. Domains will be focused on various subject matters in the system such as :•The customer viewpoint•Generic services • Hardware controlEach domain remains independent of other domains and they are connected using Bridges.
BedState Model
Bed Available
entry/# find old patientold_patient = this -> R1
# remove link to old patientunlink this R1 old_patient
Bed Unavailable
entry/# find new patientnew_patient = find-only In_Patient where \ patient_no = new_patient_no
# create link to patientlink this R1 new_patient
B3:bed_assigned_to_patient
B4:bed_unassigned
The class diagram is part of the static model and captures the key abstractions and associations within a domain. It is the foundation of the domain model.
The state chart captures the dynamic behaviour of the active classes.
16 K E N N E D Y C A R T E R
Return to Contents
What is executable UML ?
Supported by ….
Hospital SystemUse Cases
AdmitOut Patient
Administrator AdmitIn Patient
Admit In PatientDomain Sequence Diagram
User Interface
U log incident
Patient AdminStatements Resource Alloc
1:dialogue ok hit
2:admit in patient
3:assign bed
4:bed assigned
5:confirm admission
6:display dialogue
8:reject admission
9:display dialogue
1:op selects admit in patient
2:
3:find a suitable bed
4:if bed available then
5: confirm admission
6: display “success” dialogue
7: log admission details
8:else reject admission9: display “failure” dialogue
Admit In PatientObject Sequence Diagram
administrator patient:1 bed:2resource
allocationdomain
admit patient
assign bed
bed assignedpatient now in bed
request case notespatientadmitted
Use cases provide an informal description of required behaviour from a user’s perspective.
The domain level sequence diagram shows how a use case is realised by the cooperation of the various domains in the system. The lifelines on the sequence diagram correspond to domains. The interactions between domains serve to indicate which services a domain must provide, which services a domain requires of other domains and specifies the bridge requirements.
Within each domain an object level sequence diagram shows how the use case will be realised by the interaction between objects. The lifelines on the sequence diagram correspond to objects. The interactions between objects serve to indicate which operations a class must provide and the messages to be sent from on class to another.
17 K E N N E D Y C A R T E R
Return to Contents
xUML has no Hierarchical Notations - Just Model Layers
TrainManagement
HardwareInterface
Domains
Hop
negotiateHopaccelCurvePerformedfinalAccelCurvePerformed
startDateendDatedistanceCoveredcurrentState
Train
currentSpeedtimerIdcurrentStatehopNegotiatedfinalHopNegotiated
0..1
1
R2
Classes
2. Waiting For Next Hop
entry/nextHop = this -> R2generate TIM10:setAbsoluteTimer \generate timeToNegotiateNextHop () at \
nextHop.startTime to this
timeToNegotiateNextHop(trainId)
3. Negotiating Hop
entry/nextHop = this -> R2generate H1:negotiateHop() to nextHop
hopNegotiated(trainId)
States
Operations
hopNegotiated
this.currentState = ‘journeyComplete’
19 K E N N E D Y C A R T E R
Return to Contents
AnalysisDocument
An Elaborative Development Process
Analyse
Design
DesignDocument
Implement
SoftwareSystem
manually inmonths or years
manually inmonths or years
• “high level”• informal
• no completion criteria
• “high level”• informal
• no completion criteria
large team of technology
experts
large team of technology
experts
application pollutedby technology
application pollutedby technology
• idiosyncratic components• obsolete documentation
• idiosyncratic components• obsolete documentation
Require-ments
these never stop changing
these never stop changing
Of course, with any type of development, the exact requirements are almost never known upfront. This means that some iteration must be performed until the final solution is achieved.
With elaborative development, the iteration must often include execution of (sections of) the implemented code.
Changes that result from iterative development must somehow be applied to the analysis documents, the design documents and to the final code.
Reverse engineering (round trip) tools are usually successful only at keeping the design and code in step
The analysis document is then quickly abandoned and becomes out of date.
20 K E N N E D Y C A R T E R
Return to Contents
AnalysisModel
An Alternative View
Analyse
Apply theAnalysis to
Design Mapping
DesignModel
Apply the Design to Implementation Mapping
SoftwareSystem
A good analysis model
is a specification of required behaviour.
Executable analysis models are suitable
for mapping to design and implementation
A good analysis model
is a specification of required behaviour.
Executable analysis models are suitable
for mapping to design and implementation If the mappings are
systematic then this view becomes
optional
If the mappings are systematic then this
view becomes optional
This is produced by applying the mappings to the analysis model. The analysis model and the mappings are maintained and the code isn’t.
This is produced by applying the mappings to the analysis model. The analysis model and the mappings are maintained and the code isn’t.
Require-ments
Analysis to Design Mapping
Design
Design is about the specifying the mapping from the implementation independent view in the analysis
model to the implementation dependent view in the design model and implementation.
This can be done class by class or more systematically.
Design is about the specifying the mapping from the implementation independent view in the analysis
model to the implementation dependent view in the design model and implementation.
This can be done class by class or more systematically.
Design to Implementation Mapping
Iteration can be achieved directly at this level because the analysis models are precise enough to be executed and subjected to actual tests.
Such Iteration can be perfomed on parts of the analysis model (single use cases), class groups or the whole model
The design model can also be developed with iterative development and, if required, this can be done before the application analysis is started. This is because the design captures patterns for implementing any xUML model
Iteration can be also be achieved at this level in the same way as elaborative development, if required.
21 K E N N E D Y C A R T E R
Return to Contents
AnalysisModel
An Alternative View - Developed
Analyse
Apply theAnalysis to
Implementation Mapping
SoftwareSystem
Require-ments
Analysis to Implementation Mapping
Design
Combine the two mappings as they are applied
sequentially.These can be captured as Design Patterns
Combine the two mappings as they are applied
sequentially.These can be captured as Design Patterns
This can be done manually or, with a code generator,
automatically
This can be done manually or, with a code generator,
automatically
Automatic code generation means that Iteration can be achieved at this level without any model getting out of step. This is because changes are made either to the design or to the analysis models (depending on the nature of the change) and the system is then regenerated.
22 K E N N E D Y C A R T E R
Return to Contents
Objectives of the xUML Process
The primary objectives of a development process based on xUML are:
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 K E N N E D Y C A R T E R
Return to Contents
xUML Based Development
Implement
SoftwareSystem
automatically inminutes or hours
automatically inminutes or hours
Design
DesignPatterns
small team oftechnology
experts
small team oftechnology
experts
the“software
architecture”
the“software
architecture”
Analyse
xUMLModel
complete,precise & testable
complete,precise & testable
small teams ofapplicationexperts
small teams ofapplicationexperts
24 K E N N E D Y C A R T E R
Return to Contents
Overview of the xUML Process
The xUML process can be summarised as:
SPECIFY DOMAINS
Identify new/reused domains
Model system use cases
VALIDATE ANALYSIS
Execute domain use cases
Execute system use cases
ANALYSE NEW DOMAINS
Build Static ModelBuild Dynamic Models
Specify Actions
Model domain use cases
Execute and debug xUML models
FORMALISE ABSTRACT DESIGN MODEL
Select or develop suitable patterns and mechanisms
(Build/Buy xUML compiler)
PRODUCE TARGET CODE
Apply design patterns to xUML models(manually or automatically)
Perform target testing
26 K E N N E D Y C A R T E R
Return to Contents
The xUML Process Steps
What’s the process for developing executable models ? No process is linear so this section illustrates only the steps
that are taken, not necessarily the precise ordering The process can be tailored Iteration takes place within and across the steps
The phases are: Preparation or Inception Phase
Establish requirements and scope Modelling or Elaboration Phase
Development of application analysis models Development of abstract design models
Construction Phase Manual or automatic application of absract design rules to
application models This section of the tutorial describes the general principles of the
Preparation and Modelling Phases. The application of Modelling to abstract design and the automatic execution of the construction phase is described later.
27 K E N N E D Y C A R T E R
Return to Contents
Preparation or Inception Phase
Hospital SystemUse Cases
AdmitOut
Patient
AdministratorAdmitIn
Patient
Capture requirements with use cases
Partition system into domains
Hospital SystemDomain Chart
PatientAdministration
ResourceAllocation
LocationTracking
UserInterface
Admit In PatientDomain Sequence Diagram
User Interface
U log incident
Patient AdminStatements Resource Alloc
1:dialogue ok hit2:admit in patient
3:assign bed4:bed assigned
5:confirm admission6:display dialogue
8:reject admission9:display dialogue
1:op selects admit in patient
2:3:find a suitable bed4:if bed available then5: confirm admission6: display “success” dialogue
7: log admission details
8:else reject admission9: display “failure” dialogue
Identify domain interactions
Patient AdministrationClass Model
is using
isbeing used by
1
Out Patient
patient nonext visit date
Bed
ward namebed nobed type
In Patient
patient nonamedate of birth
Patient
patient nonamedate of birth
is beingused by 0..1
Produce first-cut class diagram for each domain to be modelled
28 K E N N E D Y C A R T E R
Return to Contents
The Preparation of Inception Phase
Preparation or Inception Phase aim is to: scope the project engineer the requirements partition the system into domains identify new, reused or COTS domains produce first cut class and interaction diagrams for new
domains consider system and software architecture issues identify key risks produce size and cost estimates
This phase does not produce any executable models but provides the foundation for the next phase
29 K E N N E D Y C A R T E R
Return to Contents
Modelling or Elaboration Phase
Produce the interaction diagram
Develop state charts for classes and specify actions using an
action language
Add operations to classes and specify them using an
action language
Specify bridges between domains
Admit In PatientObject Sequence Diagram
Administrator Patient:1 Bed:2 ResourceAllocation
LocationTracking
admitPatient
assignBed
bedAssignedpatientNow InBed
requestCaseNotespatientAdmitted
BedState Chart
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
Patient Administration Bed Class
BedwardNamebedNobedType
CheckAvailability()
isOccupied
freeBed = find-one Bed where\ isOccupied = FALSE
Patient Admin to Resource Alloc Bridge
$USE Resource AllocationGenerate allocateResource
ResourceAllocation
PatientAdmin
PatientAdmin<<RequiredInterface>>
Resource Allocation<<ProvidedInterface>>
PatientAdmin<<BridgeClass>>
assignBed
assignBed
allocateResource
30 K E N N E D Y C A R T E R
Return to Contents
Modelling or Elaboration Phase
Executable modelling is ideal for iterative and incremental development
Each iteration takes this form: Select a scenario from a use case (starting with the primary
ones) Update the domain interaction diagram if necessary For each domain involved:
Produce the class collaboration diagram Produce state models for the classes Update the class diagram as required Add operations to the classes Specify the operations and state actions with an action
language Specify initial conditions and test methods with an action
language Specify the provided and required interface of the domain Build the domain model Simulate the scenario through the domain
Specify the the bridges which connect the domains Build the multi-domain model Simulate the scenario through all involved domains
31 K E N N E D Y C A R T E R
Return to Contents
The xUML Process Overview
Hospital SystemUse Cases
AdmitOut Patient
Administrator AdmitIn Patient
1. Capture Requirements
Hospital SystemDomain Chart
PatientAdministration
ResourceAllocation
LocationTracking
UserInterface
2. Partition into Domains
Admit In PatientDomain Sequence Diagram
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
3. Define Domain Interfaces
Patient Administration Static Model
is using
isbeing used by
1
Out Patient
patient nonext visit date
Bed
ward namebed nobed type
In Patient
patient nonamedate of birth
Patient
patient nonamedate of birth
is beingused by 0..1
4. Specify Classes
BedState Chart
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
6. Specify Behaviour
Admit In PatientObject Sequence Diagram
5. Define Class Interfaces
Administrator Patient:1 Bed:2 ResourceAllocation
LocationTracking
admitPatient
assignBed
bedAssignedpatientNow InBed
requestCaseNotespatientAdmitted
33 K E N N E D Y C A R T E R
Return to Contents
The Action Specification Language
A key component of xUML is the Action Language
This section provides a broad summary of the capabilities of ASL , supported by some examples.
34 K E N N E D Y C A R T E R
Return to Contents
BRIDGE Banking:informOfExceededOverdraftLimitCLASS: AccountINPUTS:OUTPUTS:
counterpartDisplayRecord = this -> CPR1$USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE
BRIDGE Banking:informOfExceededOverdraftLimitCLASS: AccountINPUTS:OUTPUTS:
counterpartDisplayRecord = this -> CPR1$USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE
Bridges, for mapping to
other domains
Bridges, for mapping to
other domains
Action Specification Language is used for…
1 CREATING Account
# create a new account with a unique id and the specified opening balancenewAccount = create unique Account with balance = openingBalance# assign today's date to the 'dateOpened' attribute
today= current-datenewAccount.dateOpened = today# get the handle of the owning customer instance
owningCustomer = find-only Customer where custId = custId# link the new account via relationship R1 to the owning customer
link newAccount R1 owningCustomer
AC1:createAccount (custId,openingBalance)
Actions, for state-dependent
behaviour
Actions, for state-dependent
behaviour
account_1 = create Account with accountId = 32 & \dateOpened = 2000.10.31 & \balance = 22504.96 & \currentState = ‘inGoodStanding’
customer_1 = create unique Customer with ...link account_1 R1 customer_1...
account_1 = create Account with accountId = 32 & \dateOpened = 2000.10.31 & \balance = 22504.96 & \currentState = ‘inGoodStanding’
customer_1 = create unique Customer with ...link account_1 R1 customer_1...
Scenarios, for simulation and system initialisation
Scenarios, for simulation and system initialisation
OPERATION: checkAccountbalanceCLASS: AccountINPUTS:OUTPUT:
if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif
OPERATION: checkAccountbalanceCLASS: AccountINPUTS:OUTPUT:
if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif
Operations, for state
independent behaviour
Operations, for state
independent behaviour
35 K E N N E D Y C A R T E R
Return to Contents
Instance Manipulation
Instances are manipulated using instance handles
an instance handle is a reference to a specific
instance
myAccount = find-only Account where accountId=33myAccount = find-only Account where accountId=33
In many contexts, a special instance handle named “this” is always available which contains the instance handle of the instance that is executing the current action.
Account Instancesaccount
iddate
openedcurrentstate
32 1996.10.31 inGoodStanding
33 1993.11.05 frozen
balance
22,504.96
-5,427.75
ownerid
462
216
Customer
custIdcustAddresscurrentState
Account
accountIddateOpenedbalanceownerIdcurrentState
1..*1
owns
isowned by
an optional identifier is a set of one or more attributes whose values uniquely distinguish each
instance
R1
36 K E N N E D Y C A R T E R
Return to Contents
Association Manipulation
Associations are manipulated using association primitives
So, to navigate from this instance of Account to the owning customer, do not do this...
theOwnerId = this.owner_id
owningCustomer = find-only Customer where custId = theOwnerId
theOwnerId = this.owner_id
owningCustomer = find-only Customer where custId = theOwnerId
owningCustomer = this -> R1owningCustomer = this -> R1
do this instead...
Account Instancesaccount
iddate
openedcurrentstate
32 1996.10.31 inGoodStanding
33 1993.11.05 frozen
balance
22,504.96
-5,427.75
ownerid
462
216
isowned by
Customer
custIdcustAddresscurrentState
Account
accountIddateOpenedbalanceownerIdcurrentState
1..*1
owns
R1
37 K E N N E D Y C A R T E R
Return to Contents
Specifying Actions
The Action Specification Language provides a process modelling formalism that can be used to specify all the processing in a domain.
The most common ASL constructs allow the analyst to:
Create a New Class Instance Assign Attribute Values Obtain an Instance Handle Create an Association Instance Navigate to a Related Instance Delete an Association Instance Navigate to a Set of Instances Determine if a Set is Empty Send a Signal Event Delete a Class Instance
38 K E N N E D Y C A R T E R
Return to Contents
Creating a New Class Instance
The creation operation for Account includes a create statement.
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
new Account instance created with arbitrary unique integer value assigned to' accountId' by the
architecture
OPERATION: createAccountINPUTS: owningCustomer: Customer, openingBalance: RealOUTPUTS: newAccount: Account
# create a new account with a unique id & the specified opening balancenewAccount = create unique Account with balance = openingBalance# assign today's date to the 'dateOpened' attributetoday = current-datenewAccount.dateOpened = today# link the new account via relationship R1 to the owning customerlink newAccount R1 owningCustomer
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
“newAccount” is an instance
handle
“Account” is a class name
“balance” is an attribute of the Account class
“openingBalance” is an
input parameter to this operation “create unique”
provides an arbitrary identifier
value, use “create” to define specific
identifying attributes
39 K E N N E D Y C A R T E R
Return to Contents
Assigning Attribute Values
Any action may assign local variables and attribute values...
the 'dateOpened' attribute is assigned the value returned by the
operation 'current_date'
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
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
isowned byCustomer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
R1
“today” is a local variable which is declared by first
use
This assignment would have more
appropriately been made as part of the 'create' statement
“newAccount” is an instance
handle
“current-date” is a pre-defined ASL
feature which returns the current date
“dateOpened” is an attribute
name
“=“ is the assignment
operator
40 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
Creating an Association Instance
The analyst specifies when and how association instances are created...
a new instance of R1 is created, linking the new account instance to the owning customer
instance found earlier
myCustomer : Customer
myAccount : Account
OPERATION: 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
ownsisowned by
R1
“link” is an ASL keyword which
links two instances through
a specifed association
“newAccount” is an instance
handle
“R1” identifies the association
“owningCustomer” is an instance
handle
In this case, the class diagram states the policy that each instance of
Account is owned by exactly one instance of Customer.
The ASL enforces this policy by creating an instance of association R1
whenever an instance of Account is created.
41 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
Navigating to a Related Instance
It is possible to navigate from one instance to another instance by specifying: 1. the starting instance, and 2. the association to navigate.
AC6:delete_account (accountId)
1. starting from 'this' Account instance...
2. navigate the R1 association instance...
3. to obtain the handle of the
related Customer instance
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
The ASL keyword 'this' refers to the instance handle of the instance
associated with the state machine or instance-based
operation executing the current action.
“owningCustomer” is the single instance handle that results from the navigation to the “1” end of an
association
This line can be read as “The
owningCustomer can be found by navigating from this through R1”
42 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
Deleting a Association Instance
The analyst specify when association instances are deleted...
the R1 association instance linking this
Account instance and the owning Customer
instance is deleted
‘goodbye, world’
‘now I'm a dangling
customer!’
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
“this” is the ASL keyword that
represents the instance executing the state machine
“R1” identifies the
association
“unlink” is the ASL keyword which
removes the link between two associated instances
“owningCustomer” is an instance handle
In this case, the analyst is about to
delete an instance of Account. Prior to
this, the dying Account instance must be unlinked
from all of its related instances.
43 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
Navigating to a Set of Instances
Navigate to a set of related instances by specifying: 1. the starting instance, and 2. the association to navigate.
3. to obtain a set of Account instance
handles (an empty set in this scenario)
2. navigate the R1 association instances (there are none in
this scenario)
1. starting from the owning Customer instance
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
In this case, since the analyst is navigating to the “many” end of an association, the
navigation will deliver a set of (zero or more) Account
instances. The {} symbols are used denote a set.
44 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
Determining if a Set is Empty
The cardinality of a set can be determined using the 'countof' function...
‘I've got a feeling I won't last much longer’
‘I know how you feel’
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
In this case, the analyst wishes to determine if the Account
instance that is about to die is the last instance owned by the
owning Customer instance.
If so, then the multiplicity of the association requires that the
owning Customer instance be deleted, since it is now related to zero instances of Account.
“countof” is an ASL keyword that returns
the number of instances of the
specified set
if then else endif is an ASL
control logic construct
45 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myCustomer : Customer
myAccount : Account
Sending a Signal Event
It is possible to send an event to a specified instance of a class in the same domain using the “generate...to” construct...
the signal 'deleteCustomer’ is sent to the specified instance of Customer
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
“generate” is an ASL keyword that denotes a
signal send
“to” is an ASL keyword that denotes that the signal is sent to the specified instance. “to” must always be followed by a
valid instance handle
Here, the signal carries no supplemental data, hence the empty parameter list
denoted by (). Signal parameters are comma
separated if there are any.
“deleteCustomer” is the signal
name
46 K E N N E D Y C A R T E R
Return to Contents
Object DiagramObject Diagram
myAccount : Account
Deleting a Class Instance
The 'delete' statement is used to delete a specified instance...
‘I was right!’
the Account instance for thisstate machine has been deleted. This is
guaranteed to have been deleted by the time this action completes.
the Customer instance has been deleted as a result of the deletion event to the owning Customer's state machine (NOTE: it cannot be guaranteed
that this event has been processed yet)
Deleting Account
# navigate from this account instance to the owning customer instanceowningCustomer = this -> R1# unlink this instance from the owning customer via R1unlink this R1 owningCustomer# find the set of all other account instances owned by that customer{otherOwnedAccounts} = owningCustomer -> R1# if there are no other owned accounts for this customer, then# send a deletion event to the customer instanceif countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomerendif# delete this instance of accountdelete this
deleteAccount()
Customer
custId {I-=1}custAddresscurrentState
Account
accountId {I=1}dateOpenedbalanceownerId {R=1}currentState
1..*1
owns
isowned by
R1
“delete” is an ASL keyword
In this case, the state is terminal, and therefore this instance of Account
must be deleted.
48 K E N N E D Y C A R T E R
Return to Contents
Software Design Model – The Elements
To implement a software design model, we will construct:
A class model of the abstract software design.
Design Patterns (archetypes).
Code Patterns in the target language.
Mapping rules from xUML.
A tagging scheme.
Mechanisms….
To implement a software design model, we will construct:
A class model of the abstract software design.
Design Patterns (archetypes).
Code Patterns in the target language.
Mapping rules from xUML.
A tagging scheme.
Mechanisms….
QueuesScheduler
xUML TimerSignalCommunication
49 K E N N E D Y C A R T E R
Return to Contents
Abstract Design Model Class Diagram
is executing for
has
Domain
Class
StateModel
Object
State Machine Instance
contains
is part of
holdsattribute
valuesfor
holdsattributeforhas
defines behaviour of
is aninstance of has
Type ofProcess
DataStructure
ActualProcess
DataArea
Type ofProcessor
ActualProcessor
c
events areprocessed by
processesevents for
isexecuting
isrunningin
is server for
is accessed via
specifiesisspecifiedby
specifiesis specified by
canexecute
can beexecutedby
attributevalues are
held inattributesare held in
holds code for
code is held in
StaticxUML
RuntimexUML
RuntimeExecution
CodeAssembly
is located on
This quadrant is the meta model for the xUML model elements and consequently it doesn’t change. This is a greatly simplified version!
This quadrant is the meta model for an executing xUML model at runtime and likewise it doesn’t change. It is a static
model of the xUML virtual machine.
This quadrant captures the properties of the
software build. It may be very simple in some
projects.
This quadrant captures the target software runtime view. It must meet the requirements of the xUML virtual machine. The
classes in this quadrant will depend on the type of system
being built, eg real time embedded or information
system.
Associations that span the quadrants define
characteristics of the architecture such as
distribution, threading and queuing policies
50 K E N N E D Y C A R T E R
Return to ContentsArchetypal Design and Code Patterns
C++ Code Archetype
class Class<ClassName> { public: <returnType1> <operationName1>(); <returnType2> <operationName2>(); //………. private: static char *className; static char *classKeyLetter; //……. <attribute1Type> <attributeName1>; <attribute2Type> <attributeName2>; <attribute3Type> <attributeName3>; <attribute4Type> <attributeName4>; //…….};
Mapping Rules expressed in ASL
{allClasses} = find-all Classfor eachClass in {allClasses} do # create a class called Class<ClassName> # with the attributes of Class as static items {theAttributes} = eachClass -> R1 for eachAttribute in {theAttributes} do # create a private member data item # corresponding to the attribute # with type eachAttribute.dataType endforendfor
<ClassName>
<operationName1>():<returnType1><operationName2>():<returnType2>…
<attributeName1>:<attribute1Type><attributeName2>:<attribute2Type><attributeName3>:<attribute3Type><attributeName4>:<attribute4Type> …
Design Archetype
This is a UML class which describes a design pattern which can be applied to each class in the analysis model. It can
be used to show how attributes and operations from the analysis classes will
map into the design and also how instances will be contained, how associations will be realised, etc.
Expressing the design model in the form of patterns keeps it free from application specific concepts and
therefore easier to maintain.
This is a code version (C++ in this example) of the design pattern. The
actual code is created by substituting the corresponding elements of the
analysis model into the places denoted by the <> delimiters. Clearly substitution of this form is mechanical and therefore amenable to automatic code generation
if desired.
This is a meta level description which defines how the elements
of the analysis model will be mapped into the target code. It
is defined using ASL
51 K E N N E D Y C A R T E R
Return to Contents
Mechanisms
The design patterns provide uniform strategies for common issues……such as persistence…
PersistentClass{abstract}
classNameclassNumber
saveState{abstract}restoreState{abstract}
findFirstfindNext
Mechanism
Pump
saveStaterestoreState
Tank
saveStaterestoreState
Classes mapped from application and
service domain xUML models
A mechanism is a part of the design and target code which does not derive
from the analysis models by substitution but provides some generic capability. Mechanisms are commonly used to implement signal queuing, instance containers, persistance services and
communications
52 K E N N E D Y C A R T E R
Return to ContentsMechanisms
Coded Mechanisms
//--------------------------------------// Event Queue//--------------------------------------class EventQueue{public: EventQueue(); void generate (GenericEvent*); GenericEvent *findEvent (char*); GenericEvent *consumeEvent (); GenericEvent *getFirstEvent ();
private: virtual ~EventQueue (); Queue<GenericEvent *> *theQueue; static numberOfEventQueues;};
EventQueue
EventQueue()generate (GenericEvent)findEvent (string) : GenericEventconsumeEvent : GenericEventgetFirstEvent : GenericEvent
numberOfEventQueuestheQueue
UML Mechanisms
Queue
QueueElement
<<bind>> (GenericEvent)
Mechanisms can be described using
UML….
…. and code
53 K E N N E D Y C A R T E R
Return to ContentsInstantiating an Archetype
Use mapping rules to
apply the archetype to
each analysis model
element to produce
code
Customer
getCustAddress
custIdcustAddresscurrentState
Analysis Model Element
Generated C++ Code
class ClassCustomer{ public: custAddressType getCustAddress(); private: static char *className; static char *classKeyLetter; // int custId; custAddressType custAddress; int currentState};
C++ Code Archetype
class Class<ClassName> { public: <returnType1> <operationName1>(); <returnType2> <operationName2>(); //………. private: static char *className; static char *classKeyLetter; //……. <attribute1Type> <attributeName1>; <attribute2Type> <attributeName2>; <attribute3Type> <attributeName3>; <attribute4Type> <attributeName4>; //…….};
Mapping Rules in ASL
{allClasses} = find-all Classfor eachClass in {allClasses} do # create a class called Class<ClassName> # with the attributes of Class as static items {theAttributes} = eachClass -> R1 for eachAttribute in {theAttributes} do # create a private member data item # corresponding to the attribute # with type eachAttribute.dataType endforendfor
54 K E N N E D Y C A R T E R
Return to Contents
Benefits
Domain partitioning maintains a clear separation between the operations to be performed on data, and the structure of the
data...
xUMLModels
The analysis models specify the required
processing in an implementation-independent way
DesignPatterns
The patterns provide templates for a range
of data structures, along with rules and a tagging scheme to determine their use
The software architecture domain encapsulates the design decisions that
define how components of the implementation are to be generated
from components of the analysis.
This allows the classes to be fully specified in an abstract,
implementation-independent, formalism ...
TargetCode
TranslationEngine
The generated code is not a
directly maintained deliverable
... and translated into a variety of implementations ...
... that do not have to be based on classes.
56 K E N N E D Y C A R T E R
Return to Contents
An xUML Case Study
This section presents a Case Study problem and (part of) a solution as xUML models
The Case Study is a Petrol (Gas) Station control system The same Case Study is used in the turorial for the iUML toolset.
Using this you can: Interactively develop your models See the models executing
58 K E N N E D Y C A R T E R
Return to Contents
Case Study System Requirements
Petrol Station Control System Requirements
A computer-based system is required to control the dispensing of petrol, to handle customer payment and to monitor tank levels. The system must be “best of breed”, easy to use, reliable, fast and easy to modify to incorporate requirements yet to be conceived.
Before a customer can use the self-service pumps, the pump must be enabled by the attendant. When a pump is enabled, the pump motor is started, if it is not already on, with the pump clutch free. When the trigger in the gun is depressed, closing a micro switch, the clutch is engaged and petrol pumped. When it is released, the clutch is freed. There is also a micro switch on the holster in which the gun is kept which prevents petrol being pumped until the gun is taken out. Once the gun is replaced in the holster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannot dispense more petrol. After a short standby period, the pump motor will be turned off unless the pump is re-enabled.
A metering device in the petrol line sends a pulse to the system for each 1/100 litre dispensed. The cost of the fuel is calculated using the amount delivered and unit cost which is displayed on the pump.
There are two kinds of pump. The normal kind allows the user to dispense petrol ad lib. The sophisticated pumps, imported from New Zealand, allow the customer to preset an amount and a volume of petrol. Petrol will then be pumped up to a maximum of the required quantity.
Transactions are stored until the customer pays. Payment may be either in cash, by credit card or account. A customer may request a receipt (showing price, time, date etc.) and will get a token for every 5 pounds. Customers sometimes abscond without paying and the operator must annotate the transaction with any available information, the vehicle’s registration number for example. At the end of the day, transactions are archived and may be used for ad hoc enquiries on sales.
At present, two grades of petrol are dispensed from five pumps on the forecourt. Each pump takes its supply from one of two tanks, one tank for each grade. The tank level must not drop below 4% of the tank’s capacity. If this happens, the pumps serviced by that tank cannot be enabled to dispense petrol.
The developer shall provide a complete software system to perform the above control functions and shall provide design documents, code listings and so on.
Petrol Station Control System Requirements
A computer-based system is required to control the dispensing of petrol, to handle customer payment and to monitor tank levels. The system must be “best of breed”, easy to use, reliable, fast and easy to modify to incorporate requirements yet to be conceived.
Before a customer can use the self-service pumps, the pump must be enabled by the attendant. When a pump is enabled, the pump motor is started, if it is not already on, with the pump clutch free. When the trigger in the gun is depressed, closing a micro switch, the clutch is engaged and petrol pumped. When it is released, the clutch is freed. There is also a micro switch on the holster in which the gun is kept which prevents petrol being pumped until the gun is taken out. Once the gun is replaced in the holster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannot dispense more petrol. After a short standby period, the pump motor will be turned off unless the pump is re-enabled.
A metering device in the petrol line sends a pulse to the system for each 1/100 litre dispensed. The cost of the fuel is calculated using the amount delivered and unit cost which is displayed on the pump.
There are two kinds of pump. The normal kind allows the user to dispense petrol ad lib. The sophisticated pumps, imported from New Zealand, allow the customer to preset an amount and a volume of petrol. Petrol will then be pumped up to a maximum of the required quantity.
Transactions are stored until the customer pays. Payment may be either in cash, by credit card or account. A customer may request a receipt (showing price, time, date etc.) and will get a token for every 5 pounds. Customers sometimes abscond without paying and the operator must annotate the transaction with any available information, the vehicle’s registration number for example. At the end of the day, transactions are archived and may be used for ad hoc enquiries on sales.
At present, two grades of petrol are dispensed from five pumps on the forecourt. Each pump takes its supply from one of two tanks, one tank for each grade. The tank level must not drop below 4% of the tank’s capacity. If this happens, the pumps serviced by that tank cannot be enabled to dispense petrol.
The developer shall provide a complete software system to perform the above control functions and shall provide design documents, code listings and so on.
BACK
59 K E N N E D Y C A R T E R
Return to Contents
Tank B
LeadFree
Tank C
Diesel
Tank A
FourStar
FourStar
LeadFree
LeadFree
FourStar
LeadFree Diesel
FOSSIL FUELS
Example Configuration
1 2 3 4 5 6
60 K E N N E D Y C A R T E R
Return to Contents
FOSSIL FUELS
Plundering Earth’s Natural Resources for You
25 Feb 2001 16:25
Pump 3 - Four Star 20.00 litres @ 80.0p = £16.00
including VAT @17.5% = £2.38
Thank You for Choosing Fossil
Cost/Litre
Quantity
Cost
80.0p
20.00
£16.00
FourStar
FOSSIL FUELS
Example Data Representations
62 K E N N E D Y C A R T E R
Return to Contents
Use Cases for Petrol Station
<<include>> <<extends>>
Make Fuel Delivery
Specify Fuel
Volume
Specify Fuel Value
Make Credit Card
Payment
LogTrans-action
<<extends>>
<<extends>>
<<include>>
<<include>>
<<include>>
Make Payment
Attendant
Credit Card Validator
Buy Non-Fuel Goods
Customer
Buy Fuel
63 K E N N E D Y C A R T E R
Return to Contents
Definition of “Make Fuel Delivery” Use Case
Use Case Name Make Fuel Delivery.
Purpose To allow a paying customer to deliver fuel of a customer selected grade.
Preconditions The desired fuel grade is available.
Invariants Tank level > 4% tank capacity while pump is turned on.
Primary Scenario 1. Customer removes gun from holster;
2. Attendant enables pump;
3. Customer selects one fuel grade;
4. Pump motor is started;
5. Customer uses trigger to control fuel delivery, causing the system to engage/disengage pump clutch as trigger is depressed/released;
6. Customer replaces gun in holster;
Pump motor is stopped.
Postconditions At least two litres of fuel have been delivered.
The pump gun is in the holster.
The pump motor is off.
Secondary Scenario 1 Customer delivers less than two litres of fuel.
Postconditions Less than two litres of fuel have been delivered.
Secondary Scenario 2 Tank level falls below 4%..
Postconditions All pumps connected to tank are disabled..
Secondary Scenario 3 Customer releases trigger but does not return gun to holster.
Postconditions Pump switched off after timeout period..
Performance Specification
Trigger Customer removes gun from holster.
Periodicity Aperiodic.
Rate 60/hour.
Use Case Name Make Fuel Delivery.
Purpose To allow a paying customer to deliver fuel of a customer selected grade.
Preconditions The desired fuel grade is available.
Invariants Tank level > 4% tank capacity while pump is turned on.
Primary Scenario 1. Customer removes gun from holster;
2. Attendant enables pump;
3. Customer selects one fuel grade;
4. Pump motor is started;
5. Customer uses trigger to control fuel delivery, causing the system to engage/disengage pump clutch as trigger is depressed/released;
6. Customer replaces gun in holster;
Pump motor is stopped.
Postconditions At least two litres of fuel have been delivered.
The pump gun is in the holster.
The pump motor is off.
Secondary Scenario 1 Customer delivers less than two litres of fuel.
Postconditions Less than two litres of fuel have been delivered.
Secondary Scenario 2 Tank level falls below 4%..
Postconditions All pumps connected to tank are disabled..
Secondary Scenario 3 Customer releases trigger but does not return gun to holster.
Postconditions Pump switched off after timeout period..
Performance Specification
Trigger Customer removes gun from holster.
Periodicity Aperiodic.
Rate 60/hour.
64 K E N N E D Y C A R T E R
Return to Contents
Domain Chart for Petrol Station System
PetrolStationControl
PumpInterface
AttendantInterface
HardwareInterface
65 K E N N E D Y C A R T E R
Return to Contents
Information Model for Petrol Station Control Domain
pumpNumbertankNumber
Pump
timepumpNumbervolumeDeliveredcost
Delivery
tankNumbergradeNametankEmptyFlagtankLeveltankCapacityemptyThreshold
Tank
gradeNameunitPrice
Fuel GradetransactionNumberpumpNumbertransactionTypecosttransactionProcessTimedeliveryStartTime
Transaction
transactionNumberobservations
Evaded Transaction
transactionNumber
Paid Transaction
transactionNumberpumpNumber
Pending Transaction
ispumpingfuel from
is providing fuel for
1*
is beingmade using
is being used for
10..1
stores 1
is stored in *
is pending for
1
delivered fuel for
0..1
has delivered fuel for *
records fuel delivery for
1
R3 R1
R9
R10
R4
R2
66 K E N N E D Y C A R T E R
Return to ContentsOutline Class Collaboration Diagram for Delivery Management Domain
<<interface>>
Meter
<<interface>>
Holster
<<interface>>
Motor
<<interface>>
Clutch
<<interface>>
Gun
<<interface>>
Customer
<<interface>>
Attendant
<<interface>>
Tanker Operator
Transaction
Delivery
Pump
Tank
67 K E N N E D Y C A R T E R
Return to Contents
Preliminary CCD for Delivery Management Domain
<<interface>>
Meter
<<interface>>
Holster
<<interface>>
Motor
<<interface>>
Clutch
<<interface>>
Gun
<<interface>>
Customer
<<interface>>
Attendant
<<interface>>
Tanker Operator
Transaction
Delivery
Pump
Tank
createDelivery
pumpEnabled
triggerDepressed
requestPumpEnable
gunRemoved
startMotor
68 K E N N E D Y C A R T E R
Return to Contents
Complete CCD for Delivery Management Domain
<<interface>>
Meter
<<interface>>
Holster
<<interface>>
Motor
<<interface>>
Clutch
<<interface>>
Gun
<<interface>>
Customer
<<interface>>
Attendant
<<interface>>
Tanker Operator
Transaction
Delivery
Pump
Tank
createTransaction
paymentReceived
customer Absconds
transactionPending
createDelivery
pumpEnabled
fuelUnitDelivered
deliveryCompletestartMotor
stopMotor
engageClutch
disengageClutch
triggerDepressed
triggerReleased
pumpUnavailable
fuelAvailable
requestPumpEnable
tankerDelivery
fuelUsed
gunRemoved
gunReplaced
69 K E N N E D Y C A R T E R
Return to Contents
(Part of) State Machine for Pump Class
Waiting for Customerentry/# The pump is idle. Wait in this state until# a customer removes the gun from its holster.
Gun Replaced
The Colloboration Diagram shows that the Pump class receives the following signals…
Pump Enabled
Trigger Depressed
Trigger Released
Assume that the “Waiting for Pump Enable” action will also detect the signal:
Fuel Available
Customer Finished
Waiting for Pump Enableentry/# Determine whether the connected tank
contains# more than 4% of its capacity.
Gun Removed
Gun Removed
Fuel Level Low
Please identify the remaining states and transitions.
70 K E N N E D Y C A R T E R
Return to Contents
State Machine for Pump Class
Fuel Unavailableentry/# Inform customer that the pump is
unavailable.# Wait for fuel to become available for this
pump.
Fuel Delivery Completeentry/# Delivery Now Complete, Stop motor and return
pump# to waiting state
Waiting for Customerentry/# The pump is idle. Wait in this state until# 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
Customer Finished
71 K E N N E D Y C A R T E R
Return to Contents
Outline State Transition Table for Pump Class
GunRemoved
GunReplaced
FuelLevel Low
FuelAvailable
Non Existent
Waiting for Customer
Waiting for Pump Enable
Ready to Pump
Pumping
Pumping Paused
PumpEnabledState
Event
Fuel Delivery Complete
Fuel Unavailable
TriggerDepressed
TriggerReleased
CustomerFinished
72 K E N N E D Y C A R T E R
Return to Contents
State Transition Table for Pump Class
GunRemoved
GunReplaced
FuelLevel Low
FuelAvailable
Non Existent
Waiting for Customer
Waiting for Pump Enable
Ready to Pump
Pumping
Pumping Paused
PumpEnabledState
Event
Fuel Delivery Complete
Fuel Unavailable
TriggerDepressed
TriggerReleased
CustomerFinished
Waiting for Pump Enable
Waiting for
CustomerFuel
Delivery Complete
Fuel Delivery
Complete
Fuel Unavailable
Ready to Pump
Fuel Delivery
Complete
Waiting for
Customer
Pumping
Pumping
Pumping Paused
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore
Ignore Ignore
Ignore Ignore
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Cannot Happen
Waiting for
Customer
Cannot Happen
73 K E N N E D Y C A R T E R
Return to Contents
State Machine with Action Comments for Pump Class
Fuel 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
Waiting for Customerentry/# The pump is idle. Wait in this state until# a customer removes the gun from its holster.
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
Customer Finished
Pumping Pausedentry/# Disengage clutch which stops pumping.# Wait for gun to be replaced into the# holster or for the trigger to be depressed.
Trigger Depressed
Trigger Released
Gun Replaced
74 K E N N E D Y C A R T E R
Return to Contents
State Machine with Action Specifications for Pump Class
Fuel Unavailableentry/# Inform customer that the pump is
unavailable.# Wait for fuel to become available for this
pump.[] = CU1:Pump_Unavailable[]
Fuel Delivery Completeentry/# 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 Customerentry/# The pump is idle. Wait in this state until# a customer removes the gun from its holster.
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
then generate PMP4:Fuel_Level_Low() to thiselse [] = 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
Customer Finished
Pumping Pausedentry/# Disengage clutch which stops pumping.# Wait for gun to be replaced into the# holster or for the trigger to be depressed.[] = CL2:Disengage_Clutch[]
Trigger Depressed
Trigger Released
Gun Replaced
76 K E N N E D Y C A R T E R
Return to Contents
Benefits of The xUML Process
The key benefits of the process are: The modelling notations are simple and precise.
This makes them easier to learn and use effectively. The xUML models are validated early by simulation.
This reduces risk and cuts development costs. The xUML models keep expertise in separate subject
matters separate. This delivers large reusable components.
The xUML process requires an early study of how best to exploit the implementation technology to deliver the required system performance and reliability. This allows concurrent analysis and design and
addresses technical risks early. The xUML models can be translated directly to code.
This shortens development time and eliminates redundancy in analysis and design models.
The delivered software components have a uniform quality across the entire system. This makes the system easier to understand, and
reduces maintenance costs.
77 K E N N E D Y C A R T E R
Return to Contents
Contacts
More papers on xUML are available at: http://www.kc.com
The authors can be contacted at: Ian Wilkie [email protected] Chris Raistrick [email protected] Colin Carter [email protected]
The Action Semantics Consortium has a Web Site: http://www.umlactionsemantics.org