Why modeling?

1. Why modeling? • A model is a simplification of reality • We build models so that we can better understand the system we are developing • We build models of complex systems because we cannot comprehend such a system in its entirety

2. Why Build Models? • To understand the problem better • To communicate with stakeholders • To find errors or omissions • To plan out the design • To generate code

3. Mental Models Mental models are • assumptions • generalizations • pictures • images that influence how we understand the world and take action

4. Mental Models • We all have mental models of the world • We all have mental models of the bussinesses which we work at and which we deal with • Mental models also influence our behavior toward the world

5. Mental Models • Mental Models are often not shared by all stakeholders in the business • This results in dysfunctional and provincial attitudes and behavior • It is essential to develop a shared meta model

6. UML Model Views • Requirements (use case diagrams) • Static structure (class diagrams) • kinds of objects and their relationships • Dynamic behavior (state machines) • possible life histories of an object • Interactive behavior (activity, sequence, and collaboration diagrams) • flow of control among objects to achieve system-level behavior • Physical implementation structures (component and deployment diagrams) • software modules and deployment on physical nodes

7. FinancialInstitution client creditor 0..* 0..* owner 0..* Mortgage principal rate term Bank TrustCompany 0..* 1 Class Diagram - Static Structure • Shows the entities in a system and their general relationships association class Person generalization association residence 0..* {ordered} House

8. RoyalBank : Bank JoeYu:Person first : Mortgage second : Mortgage cottage : House home : House Object Instance Diagram • Shows object instances in a particular case link

9. InitializeObject Wait forEvent created start/^master.ready() HandleEvent ready stop/ poll/^master.ack() TerminateObject State Machine Diagram • Each state corresponds to a selective receive action state machine initial state state trigger action expression final state transition

10. poll/defer ready start created created start/^master.ready() ready ready stop/ start/ State Machine Behavior • Event handling details depend on state start/^master.ready()

11. ActiveObject: Active Objects in the UML • Concurrent incoming events are queued and handled one-at-a-time regardless of priority • run-to-completion (RTC) execution model

12. Object-Oriented Modeling • Main building block is the object or class • An object is a thing, generally drawn from the vocabulary of the problem space or the solution space • A class is a description of a set of common objects • Every object has identity, state and behavior

13. Object-Oriented Modeling • The world is made of objects • The system is made of objects • Real world objects communicate with each other • A system is made up of objects communicating with each other

14. Classes and Objects • Classes, Objects and their relationships are the primary way to model. • A class is like a type and therefore an object is like a variable.

15. An Object has ... • Attributes (data). • Behaviour (operations). • State (memory) • Identity • Responsibilities

16. What´s the time? It is 8 p.m. Messages

17. Time Request Message Time Response Message … Message/Information Flow Messages

18. What´s the time? It is 8 p.m. Communicating with objects

19. What´s the time? You will never ask a stop watch for the time, because you know that you do not get an answer. Communicating with objects

20. An example Object ... • A sensor: • Attributes (data): Value, Rate of change • Behaviour (operations): acquire, report ... • State (memory) Last value, Last Rate • Identity: Robot arm joint sensor • Responsibilities: Gives co-ordinates for arm

21. The Class: Sensor • All sensors share certain characteristics hence we have a class of sensors. • But each individual example is an object. • (An instance of the class)

22. Attributes • Describe the state and characteristics of the object. • Must be typed, primitives like integer, real, Boolean, point, area, enumeration. May be language specific. • Visibility may be public (+), private (-) or protected (#).

23. Attributes (Contd.) • Class variables have scope across every instance of class, change one changes all. • Property strings may be used to define allowable properties of an attribute. Used for enumeration types. • Syntax • visibility name : type-expression = initial-value {property-string} • Only name and type are mandatory.

24. Attributes hours : Hour minutes : Minute seconds : Second hours : Hour minutes : Minute seconds : Second AMorPM : Boolean

25. Example Class Name, bold Public, typed Sensor + Linear_Value :Real + Rate_Of_Change : Real = 0.0 + Sensor_Name : String + Sensor_Location: String - Controller: String = “Unspecified” - number_of_sensors: Integer + status: Status = ON{ON, OFF} Default value Private, typed, default value Class variable Property

26. Operations • Operations describe the „Services“ an object is able perform • An Operation takes some Input • An Operation produces some output Output operation (Input)

27. Operations • Operations manipulate attributes and perform other tasks. • Scope is the Class. • Operation signature is composed of name, parameters and return type. • name(parameter-list) return-type-expression • Scope and visibility rules apply.

28. Syntactic Constructs • Formal syntax is as follows • visibility name(parameter-list) return-type-expression {property-string} • parameter-list specified as … • name: type-expression=default-value • All operations must have unique signature. • Default values on parameters are Ok.

29. Operations getHour getMinutes getSeconds start stop getElapsedTime getHour getMinutes getSeconds getPMorAM getTime

30. Operations Hour getHour () Minute getMinutes () Second getSeconds () void start () void stop () Time getElapsedTime () Hour getHour () Minute getMinutes () Second getSeconds () Boolean getPMorAM () Time getTime ()

31. Hour getHour () 8 <- getHour () … Operation Call (not Information Flow) Operation Calls

32. PMorAMFlag getPMorAM () void start () Time getTime () Time getElapsedTime () Operation Calls

33. On the Class Diagram Figure Signatures ? Class scope ? Defaults ? -size: Size -pos: Position +figCounter: Integer +draw() +resize(percentX: Integer=25, percentY=30) +returnPos(): Position incCounter(): Integer percentX=10, percentY=10 percentX=27, percentY=30 percentX=25, percentY=30 MyFigure.resize(10,10) MyFigure.resize(27) MyFigure.resize()

34. Cardinality Examples Employee Dept 1..* Name:String Number:EmpNo Name:Name * Rent 0..1 Member Video Has Customer Account AccNo:Account Balance: Real

35. Class & Object Representation 0..1 * Rent Member Video Night for day: Video John Doe: Member Sunset Boulevard: Video

36. Navigable Associations • Used to indicate responsibility, later may be translated into pointer mechanism. • May be bi-directional. owns 0..* Person Car

37. Recursion • Self referential construct. • Complex construct, may not be supported by target language. * owner User container Directory * * 0..1 authorised user * contents

38. Qualified Associations • A qualified association relates two Object Classes and a “qualifier”. • One-to-many and many-to-many associations may be qualified. • The qualifier distinguishes among the set of objects at the “many” end of an association.

39. Qualified Associations * File Directory Is more clearly expressed as ..... File Directory File name

40. Or-Association • A constraint on two or more associations. • Objects of a class may participate in at most one of the associations at a time. 0..* 1 0..* Insurance Contract Insurance Co {or} 1..* 1..* Person Company

41. Ordered Association • Shows implicit order of associations. • Default is unordered. {ordered} Screen Window * Visible on {ordered} Sensor Controller * polls

42. Association Class • Class may be attached to association, and not another class. * employer Company Person 0..1 Employment Association Class Period: dateRange

43. Shared Aggregation • One person may be a member of many teams. • Person is part of team, shared by N teams. * * Person Team Members

44. Composition Aggregation • More restrictive. Strong ownership here. • Rules • Parts live inside whole, parts die with whole, like automatic variables. • Multiplicity on whole side must be “0..1”, on part side may be anything. • Composition aggregation forms a tree of parts, shared forms a network of parts.

45. Three Composition Notations * Text * Listbox Window * Button menu *

46. Window * • Component not bold. • May use syntax • rollname:classname • Multiplicity shown. Text * Listbox * Button * menu

47. Generalisation • Generalisation and Inheritance allow sharing of similarities among Classes while also preserving differences. • Inheritance refers to mechanism of sharing attributes & operations between subclasses and their superclass. • Default values of attributes & methods for operations may be overridden in subclass.

48. Clock StopWatch hours : Hour minutes : Minute seconds : Second AMorPM : Boolean hours : Hour minutes : Minute seconds : Second Hour getHour () Minute getMinutes () Second getSeconds () void start () void stop () Time getElapsedTime () Hour getHour () Minute getMinutes () Second getSeconds () Boolean getPMorAM () Time getTime () Classes

49. Clock GenericClock hours : Hour minutes : Minute seconds : Second Hour getHour () Minute getMinutes () Second getSeconds () StopWatch AMorPM : Boolean void start () void stop () Time getElapsedTime () Boolean getPMorAM () Time getTime () Inheritance

50. Example General Financial service Specific Pension Mortgage Personal Loan Insurance