1. The Models are the Code - Executable UML
Lecture 10 – Wrapping things up
Paul Krause

2. Subject Matter Partitioning
Sally Shlaer and Stephen Mellor established the foundations for this approach in 1988
Object-oriented Systems Analysis - Modelling the World in Data
Recognises that a system consists of a set of subject matters - domains
Each domain consists of a set of classes
Domains are represented as packages in UML
A Domain Chart captures the dependencies between domains

3. What is a Domain?
A domain is an autonomous, real, hypothetical or abstract world inhabited by a set of conceptual entities that behave according to characteristic rules and policies
Mellor and Balcer, p30
Real Worlds
Air traffic control, patient administration, banking, …
Hypothetical Worlds
3D geometry, statistical analysis, …
Abstract Worlds
User interface, messaging, workflow, …

4. Example Domain Chart Fuel Sales Shopping Forecourt Hardware
Interfacing
User Interface
Logging
Checkout
Telecommunications
Interface

5. Advantages of Subject Matter Partitioning
Reuse
Well-defined interfaces
Effective use of subject-matter knowledge
Stability to changing requirements
Stability to changing technology
Incorporation of third party software
Effective integration with Use-Case driven development

6. Use Case Description Use Case Name Purpose Preconditions Invariants
Primary Scenario
Postconditions
Make Fuel Delivery
To allow a paying customer to deliver fuel of a selected grade
The desired fuel grade is available
Tank level >4% tank capacity while pump is on
Customer removes nozzle from holster;
Attendant enables pump;
Customer selects one fuel grade;
Pump motor is started;
Customer uses trigger to control fuel delivery;
Customer replaces nozzle in holster;
Pump motor is stopped.
At least 2 litres of fuel have been delivered

7. Domain Level Sequence Diagram
Forecourt Hardware Interfacing
User Interface
Fuel Sales
Checkout
<Boundary>
1: binaryInputChanges
1: Customer removes nozzle 2:
3:Request pump enable
4: Alert attendant of Customer
5: Attendant enables pump 6:
7: Create Transaction Item 8:
9: Pump motor enabled
10: Customer presses trigger
11:
12: Start pumping fuel
13: loop until trigger released
14: Unit of fuel is delivered
15: …
2: nozzleRemoved
3:requestPumpEnable
4:alertAttendantToRequestForPumpEnable
5:pumpEnableButtonPressed
6:pumpEnabled
7:GO creation
8:enablePump
9:setBinaryOutput
10:binaryInputChanges
11:triggerDepressed
12:startPumping
13:impellorPulse
14:fuelUnitDelivered

8. Domain Class Diagram - Fuel Sales
PumpSpecification
FillingStation
Pump
FuelGrade
Nozzle
Tank

9. Domain Class Diagram - Fuel Sales
PumpSpecification
FillingStation
isSpecifiedBy 1
specifies *
1 isDispensingFuelFor
1..* dispensesFuelAt R4
R10 R6 R5 R1 R2
Pump
FuelGrade
isInUseAt
hasInUse
1 isLocatedAt
1..* isLocationFor
1 currentlyStores
0..* isCurrentlyStoredIn
Nozzle
suppliesFuelTo
0..* 1
acquiresFuelFrom
Tank

10. Domain Class Diagram - Fuel Sales
PumpSpecification
FillingStation
isSpecifiedBy 1
specifies *
1 isDispensingFuelFor
1..* dispensesFuelAt R4
R10 R6 R5 R1 R2
Pump
FuelGrade
isInUseAt
hasInUse
1 isLocatedAt
1..* isLocationFor
1 currentlyStores
0..* isCurrentlyStoredIn
Nozzle
suppliesFuelTo
0..* 1
acquiresFuelFrom
Tank
Delivery
1 wasMadeFrom
0..* wasUsedToMake

11. Active vs Passive Classes
Active Classes
The behaviour of instances of active classes (“active objects”) varies over time
e.g. Instances of a Thread class can be started, paused, continued, stopped
This behaviour can be captured in a Statechart
Passive Classes
Passive objects have the same behaviour at all times
Operations on a class are sufficient to define its behaviour
Information classes, e.g. Address, are typically of this kind

12. Operations are used to model state-independent behaviour
Modelling Operations
Operations are used to model state-independent behaviour
An operation is the invocation of some action via a parameterised interface
think of a method call in Java or a function call in C
Operations are executed synchronously
the caller waits until the action has been executed and a result returned before continuing
The resulting action may in turn invoke (synchronously) other actions, or asynchronous behaviour by generating signals

13. UML Statecharts Closed Down Idle Entry / display Welcome startup
closedown
Processing
Customer
Input
card inserted / get pin
validation received [invalid card] / confiscate
Terminating
Transaction
withdrawal selected [valid card] / display wait

14. Good Practice for Statecharts
Express the behaviour of Active Classes using a Statechart for each active class
Restrict usage to a subset of the full Statechart notation for clarity:
Actions are specified on entry into a state (not on exit, or on the transition itself)
An individual event can only cause a single transition out of a given state
This usage corresponds to expressing behaviour as a “Moore” machine

15. Statechart for Delivery Class

16. Statechart for Delivery Class

17. Statechart for Delivery Class
Action Language specifies
the detailed action
that is performed here
in terms of the concepts
in the associated
domain model

18. Interactions within Domains
Operations can be invoked on objects or classes within a Domain.
Signals can be sent to (active) objects or classes within a domain.
Object-level sequence diagrams
Collaboration diagrams

19. Interactions with other domains
Domain-level sequence diagrams
Operations can be invoked on other domains
Signals can be sent to other domains

20. Next Actions
Final Lab Class Tomorrow
Example Exam papers will put up on the Website tomorrow
If you have any further questions, please me or come along to office hours pm on Mondays