1. Developing Domain Models The most important UML model

2. The Vision Soft Systems Models Use Cases Interaction Models Class Diagrams Programs Databases Business Computing

3. What is a Domain Model? Later we will see that the class diagram in UML is a design for software and databases The class diagram is based on a model of the real world which we will call the Domain Model Our domain model is a class diagram specified at a level of abstraction that models a real world situation We will call this a domain model to distinguish it from the more detailed class diagrams that can be used to generate program code

4. classes consist of A name, e.g. customer Attributes, e.g. name and address Operations, e.g. order, pay for goods

5. Representing classes Customer name address order receive goods pay return goods Invoice customerID customer address invoice lines vat total print

6. Relationships / Associations Provide lines of communication between classes Are used to construct complex systems

7. Relationships dog bites postman man orders meal driver car

8. Relationship types Relationships can fall into any of three basic types often referred to as the relationship’s Multiplicity. One to one One to many Many to many Each end of a relationship on a domain model can have a note displaying a symbol or number which describes the kind of relationship

9. Relationship notation NotationMeaning 1One at this end 1..nOne or more at this end 3..nThree or more at this end 5Exactly five at this end 0..nZero or more at this end 7..10Seven to ten at this end

10. One-to-one Relationships Modelled by a line between the two classes No arrows, so either class may communicate with the other You can label the relationship (but you don’t have to) No label at an end of a relationship indicates a 1 You may also wish to name the relationship manwoman married

11. Directional relationships Arrows indicate that one class communicates with another, but not the other way canarylittle old lady cat eatown

12. One-to-many Relationships These are modelled by a labelled straight line, with a label at the end indicating the “many” end of the relationship A label must be used to indicate how many No label implies one class at the end of the relationship e.g. a player plays for one football team. There are at least 11 players for a given football team. playerteam 111..n1

13. One to many relationships A customer has zero or more invoices

14. One to many relationships A juggler has two hands and a hand can hold zero or one ball

15. Many-to-many Relationships These are modelled by a straight line, with a label at each end A lubricant may be recommended for one or more engines, and an engine may have one or more lubricants recommended for it

16. Many-to-many Relationships A postman might be bitten by zero or more dogs, and a dog may bite zero or more postmen

17. Many-to-many Relationships A suitor may court one or more princesses, and a princess may have zero or more suitors

18. Many-to-many Relationships Frogs and princesses have relationships too!

19. a domain model domain models consist of a number of related classes

20. A domain model

21. a domain model

23. Module Coursework Submission Student 1..n 1 Lecturer 1..n Assessment 2 1..n exam script 1..n 2

24. Other types of Relationship Inheritance and Aggregation

25. Remember Daisy? Daisy: Cow Colour = Brown Pattern = none Weight = 400kg Cow Name Weight Pattern Produce Milk Go “Moo” Eat Grass Object Class

26. Thelma and Madge ThelmaMadge Cow Name Weight Pattern Produce Milk Go “Moo” Eat Grass Daisy All belong to the class COW

27. Introducing Silver Horse Name Weight Height Runs Jumps Eat Grass

28. and Dolly Sheep Name Weight Wool colour Goes “Baah” Produces wool Eat Grass

29. Madge, Silver and Dolly Share some attributes and operations Cow Name Weight Pattern Produce Milk Go “Moo” Eat Grass Horse Name Weight Height Runs Jumps Eat Grass Sheep Name Weight Wool colour Goes “Baah” Produces wool Eat Grass

30. New Class Animal Name Weight Eat Grass This class contains all the shared attributes and operations of the three other classes

31. The concept of inheritance If we were to model sheep, cows and horses in one diagram we may well use the new animal class to make the process much more economical. The diagram would then look like this: Animal Name Weight Eat Grass Cow Pattern Produce milk Go “moo” Sheep Wool colour Produce wool Go “Baah” Horse Height Jump Run

32. The concept of inheritance By doing this we are saying that the Cow, Horse and Sheep classes can INHERIT all the attributes from the animal class. In this instance, the animal class is known as a SUPERCLASS and the Cow, Horse and Sheep classes are SUB-CLASSES Superclass Sub-class

33. The concept of inheritance So in addition to the Horse having Height as an attribute, it also inherits Name and Weight. And as well as having the operations Jump and Run, it also inherits Eat Grass Animal Name Weight Eat Grass Horse Height Jump Run

34. Inheritance Classes can be arranged in inheritance hierarchies A class inherits operations and attributes from its parent This is one of the underlying mechanisms for providing for design and code re-use We use a special relationship to indicate this on the domain model: parent child

35. Inheritance - example student course modules taken person name address Lecturer modules taught Suppose we have already defined the notion of person as an object We now want to add a new kind of person - a student So we make use of the existing person definition, and introduce an inheritance relationship Now students have the same attributes as person, plus some new ones of their own And likewise, we can create a new type of person, a lecturer, that inherits from person

36. Relationships are inherited student course modules taken Lecturer modules taught person name companyaddress Suppose that we find that person and company share addressWe can split address out into a separate objectAnd then add in some relationshipsNow if we add in a studentAnd make the student inherit from personThen students have addresses too by inheritanceAnd we can do the same for a lecturer

37. Inheritance - juggling juggleObject weight throw() catch() pickUp() drop() jugglingBall club rotationSpeed ball diameter tennisBall bounce() egg smash() Consider our juggling objects There are three types of thing to juggle. And balls can be further refined So tennis balls can be bounced, thrown, caught, picked up and dropped Inheritance goes all the way down the hierarchy

38. Inheritance - engines engine cylinders name start() stop() Diesel Engine preheat() Petrol Engine spark plugs Steam Engine boiler light()

39. Inheritance - government Government Organisation tax() elect representatives() Local Government Provide Service() Central Government Legislate() Regional Government Set Transport Policy() Metropolitan Government Set Education Policy()

40. Inheritance - magnitude Magnitude compare() print() Coordinate add() subtract() multiply() Integer add() subtract() multiply() Why not push add, subtract, multiply up the hierarchy? Because, though they have the same name, they do different things!

41. Multiple inheritance An object can get operations and attributes from two or more other objects

42. Problems of multiple inheritance Conflict on inherited attributes and methods Complexity In general avoid it - mostly it can be worked around in better ways (see delegation, later)

43. Finding inheritance If two things are similar, are there common aspects (e.g. employee and customer) If you want to create something new, is there something similar to inherit from (e.g. web customer might be a special case of customer)

44. Aggregation Objects can be made up of other objects, e.g. a car is made up of engine, body, transmission and wheels. Aggregation hierarchies are used to describe this There is no inheritance in an aggregation hierarchy We use a special relationship to indicate aggregation whole part

45. Aggregation - example handjugglerfoot 22 A juggler has hands and feet Hands and feet are “part of” a jugglerAnd there are two of each (normally)

46. Aggregation - lubricants lubricant base oil additive package dispersantantioxidant vi improver detergent

47. Aggregation - Pathways Pathway ModuleLecture Assessment

48. Finding aggregation Break complicated objects into their parts Build objects out of existing objects

49. Inheritance and Aggregation Are important types of relationships Allow developers to re-use existing designs and implementations Adds more meaningful structures Reduces the amount of development and design time that is needed.

50. Delegation Operations on an object can be delegated to component objects (e.g. starting a car is delegated to the engine, which in turn might be delegated to the starter motor and ignition system) Delegation is another way of introducing sharing. Objects with common components can share the implementation of those components. We shall be looking at how objects call each other in more detail later

51. Key Points Inheritance and aggregation are special types of relationship Inheritance passes attributes and operations Aggregation does not pass attributes and operations Aggregate objects delegate functionality to their parts Inheritance allows for re-use of designs and implementation

52. domain modelling The principle output of OOAD is the domain model The domain model consists of all classes and relationships It defines the static structure of a system It evolves and is extended throughout the development life-cycle

53. domain modelling The domain model will expand and increase in detail as analysis and design progresses The first model should only consider real world elements and leave out design and implementation details Dynamic modelling will be used to extend the domain model Design will add new classes such as interfaces and control classes, and partition the system using concepts such as packages and components Implementation will add further detail

54. Tutorial Working in groups we will develop a number of domain models and compare the results