1. Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes

2. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes2 UML diagrams Use case diagrams —Describe user tasks and points of contact with the system Class diagrams —describe classes and their relationships Interaction diagrams —show the behaviour of systems as interactions between objects State diagrams and activity diagrams —show how systems behave internally Component and deployment diagrams —“big picture” of how the components of a system are related

3. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes3 UML features It has detailed semantics It has extension mechanisms It has an associated textual language —Object Constraint Language (OCL) The objective of UML is to assist in software development —It is not a methodology “Design by Contract” also assists in software development —It is a methodology —It has an associated specification language called JML (Java Modeling Language -- it’s like OCL but better!) —We will study it carefully later

4. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes4 What constitutes a good model? A good model should 1.use a standard notation (e.g., UML and JML) 2.be understandable by clients and users (documentation and prototypes) 3.provide technical insights about the software design I.e., close contact between the model and the program 4.provide abstraction I.e., classes, objects, features, inheritance 5.help create designs (e.g., Eclipse/UML environment) I.e., permit analysis and review of those designs 6.document the system’s requirements and specifications

5. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes5 5.2 Essentials of UML Class Diagrams The main symbols shown on class diagrams are: Classes —represent the types of data themselves Attributes —are simple data found in classes and their instances Operations —the functions performed by classes and their instances Associations —represent linkages between instances of classes Generalizations —group classes into inheritance hierarchies

6. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes6 Classes A class is simply represented as a box with the name of the class inside The diagram may also show the attributes and operations The UML signature of an operation is: operationName(parameterName: parameterType …): returnType

7. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes7 5.3 Associations and Multiplicity An association is a line that relates two classes Symbols indicating multiplicity are shown at each end

8. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes8 Labelling associations An association can be labeled, to clarify its nature

9. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes9 Interpreting associations Many-to-one —A company has many employees, —An employee can only work for one company. -No moonlighting! —A company can have zero employees -E.g. a ‘shell’ company —Every employee must work for some company

10. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes10 Interpreting associations Many-to-many —A secretary can work for many managers —A manager can have many secretaries —Secretaries can work in pools —Managers can have a group of secretaries —Some managers might have zero secretaries. —Is it possible for a secretary to have, perhaps temporarily, zero managers?

11. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes11 Interpreting associations One-to-one —For each company, there is exactly one board of directors —A board is the board of only one company —A company must always have a board —A board must always be of some company

12. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes12 Interpreting associations Avoid unnecessary one-to-one associations Avoid this do this

13. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes13 Another example A booking is always for exactly one passenger —no booking with zero passengers —a booking could never involve more than one passenger. A Passenger can have any number of Bookings —a passenger could have no bookings at all —a passenger could have more than one booking

14. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes14 Association classes Sometimes, an attribute shared by two associated classes cannot be placed in either one. E.g., the following are equivalent: Registration grade StudentCourseOffering ******* Registration grade StudentCourseOffering **

15. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes15 Reflexive associations An association can connect a class to itself Course * isMutuallyExclusiveWith * * prerequisite successor *

16. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes16 Directionality in associations Associations are by default bi-directional The direction can be limited by adding an arrow: ** Note Day

17. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes17 5.4 Generalization Specializing a superclass into two or more subclasses The label that describes the criterion for specialization

18. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes18 Avoid unnecessary generalizations rockbluesclassicaljazzmusic video videoaudio RecordingCategory * subcategory description Recording * hasCategory subcategory :RecordingCategory 9th Symphony :Recording Let it be :Recording The Beatles Beethoven title artist An inappropriate class hierarchy -- instances are not apparent An improved class diagram and its instance diagram

19. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes19 Course offerings encoded title instructor SPAN210A c INTRO TO MODERN HISPANIC LITERATURE Cueto-Asin capacity: 25 time slot: MW 11:30-12:55 same as: [LAM210] SPAN210B c INTRO TO MODERN HISPANIC LITERATURE Turner capacity: 25 time slot: TTH 10:00-11:25 same as: [LAM210] SPAN325 c SPANISH CIVIL WAR IN LIT AND FILM Cueto-Asin capacity: 15 prerequisites: [SPAN2(07|08|09|10), SPAN2(07|08|09|10)] time slot: MW 2:30-3:55 SPAN330 c POETRY AND EMPIRE Turner capacity: 15 prerequisites: [SPAN2(07|08|09|10), SPAN2(07|08|09|10)] time slot: TTH 2:30-3:55 id distrib

20. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes20 Some Initial StressFree classes: a poor design 1. Claims that “a Course is a particular kind of CourseStub.” 2. Ignores differences in lifetime between courses and course offerings. 2. Ignores that a prerequisite is an association between courses. 3. Misses class definition and association opportunities

21. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes21 Initial StressFree classes: a better design

22. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes22 Handling multiple discriminators Creating higher-level generalization

23. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes23 Using multiple inheritance Handling multiple discriminators Animal habitat typeOfFood HerbivoreCarnivoreLandAnimalAquaticAnimal AquaticCarnivoreAquaticHerbivoreLandCarnivoreLandHerbivore

24. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes24 Avoid having instances change class An instance should never need to change class

25. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes25 5.5 Instance Diagrams A link is an instance of an association (as an object is an instance of a class) Carla:Employee Ali:Employee Wayne:Employee OOCorp:Company OOCorp's Board: UML inc's Board UML inc:Company Pat:Employee Terry:Employee

26. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes26 Associations versus generalizations in instance diagrams Associations describe relationships between instances at run time —An instance diagram is generated from a class diagram —It shows an instance of both classes joined by each association Generalizations describe static relationships between classes —They do not appear in instance diagrams at all —An instance of a class is also an instance of all its superclass(es)

27. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes27 5.6 More Advanced Features: Aggregation Aggregations are associations that represent ‘part-whole’ relationships. —The ‘whole’ side is often called the assembly or the aggregate —This symbol is a shorthand notation association named isPartOf **** ****** Region VehiclePart Country Vehicle

28. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes28 When to use an aggregation An association is an aggregation if: You can state that —the parts ‘are part of’ the aggregate —or the aggregate ‘is composed of’ the parts When something owns or controls the aggregate, then they also own or control the parts

29. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes29 A composition is a strong kind of aggregation —if the aggregate is destroyed, the parts are also destroyed Two alternatives for addresses Advanced Features: Composition ***** RoomBuilding

30. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes30 Aggregation hierarchy ** * WheelTransmissionEngineFrame DoorBodyPanelChassis Vehicle

31. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes31 Propagation An operation in an aggregation can be implemented by having the aggregate perform that operation on its parts Properties of the parts can be propagated to the aggregate Propagation is to aggregation as inheritance is to generalization. —The major difference is: inheritance is an implicit mechanism, while propagation has to be programmed when required

32. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes32 Interfaces An interface describes a portion of the visible behaviour of a class. An interface is similar to a class, except it lacks instance variables and method bodies «interface» Cashier withdraw deposit Machine ATMEmployee Person Machine ATMEmployee Person Cashier

33. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes33 Notes and descriptive text Descriptive text and other diagrams —Embed class diagrams in a larger document —Text can explain aspects of the system using any notation you like —Highlight and expand on important features, and provide rationale Notes: —A note is a small block of text embedded in a UML diagram —It acts like a comment in a program

34. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes34 Object Constraint Language (OCL) OCL is a specification language designed to formally specify constraints in software modules An OCL expression simply specifies a logical fact (a constraint) about the system that must remain true A constraint cannot have any side-effects —it cannot compute a non-Boolean result nor modify any data. OCL statements in class diagrams can specify what the values of attributes and associations must be

35. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes35 OCL statements Built from References to role names, association names, attributes and the results of operations The logical values true and false Logical operators such as and, or, =, >, (not equals) String values such as: ‘a string’ Integers and real numbers Arithmetic operations *, /, +, -

36. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes36 Example: Comments and OCL constraints on Polygons LinearShape startPoint: Point 1..* edge LineSegment Path LinePolygon RegularPolygon endPoint: Point {startPoint <> endPoint} {ordered} {edge->size=1} {edge->forAll(e1,e2 | e1.length = e2.length)} {edge->forAll(e1,e2 | e1 <> e2 implies e1.startPoint <> e2.startpoint and e1.endPoint <> e2.endpoint)} length : int length {length = edge.length->sum} {edge->first.startPoint = edge->last.endPoint} a LinearShape is any shape that can be constructed of line segments (in contrast with shapes that contain curves).

37. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes37 5.7 Detailed Example: A Class Diagram for Genealogy Problems —A person must have two parents —Marriages not properly accounted for

38. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes38 Genealogy example: Possible solutions Person name placeOfBirth dateOfBirth placeOfDeath dateOfDeath Union placeOfMarriage dateOfMarriage dateOfDivorce parents 0..1 child * **** * partner 0..2 sex Person name placeOfBirth dateOfBirth placeOfDeath dateOfDeath Union placeOfMarriage dateOfMarriage dateOfDivorce parents 0..1 child * *** malePartner *0..1 child ** femalePartner 0..1 WomanMan {partner->forAll(p1,p2 | p1 <> p2 implies p1.sex <> p2.sex)}