The Models are the Code - Executable UML

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. Fuel Sales Shopping Forecourt Hardware Interfacing Checkout User Interface Logging Telecommunications Interface Example Domain Chart

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 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 Use Case Description

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. Pump PumpSpecification FillingStation Nozzle Tank FuelGrade Domain Class Diagram - Fuel Sales

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

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

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. 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. Closed Down startup closedown card inserted / get pin Idle Entry / display Welcome Processing Customer Input Terminating Transaction validation received [invalid card] / confiscate Processing Transaction withdrawal selected [valid card] / display wait UML Statecharts

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 e-mail me or come along to office hours 2-4.00pm on Mondays