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

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

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

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

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

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

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

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

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

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

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

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

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

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

Statechart for Delivery Class

Statechart for Delivery Class

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

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

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

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