Med4 OOADP Aalborg University, Aalborg

1. Med4 OOADPAalborg University, Aalborg David Meredith dave@imi.aau.dk http://moodle.vrml.aau.dk/course/view.php?id=21 Lecture 7 Class Models (Based on Fowler (2004, Chapters 3 & 5) and Stevens and Pooley (2006, Chapters 5 & 6))

2. Class diagrams • UML class diagrams document the static structure of a system • What classes there are • How the classes are related • Each class represented in UML diagram as a rectangle containing the name of the class

3. What makes a class model good? • Ultimate aim: • Build, as quickly and cheaply as possible, a system which satisfies the users’ requirements • Objects must provide every piece of required behaviour • Build a system which will be easy to maintain and adapt to future requirements • Use encapsulated modules with low coupling and high cohesion • Use classes which represent enduring types of domain concepts

4. How to build a good class model • Can use any method you like! • Unlikely to get it right first time • Classes that correspond to classes of domain object (e.g., book, copy of book, library member) are easiest to identify • What drives the design? • Data-driven design (DDD) • “Identify all the data and divide it up into classes before considering classes’ responsibilities” • Noun identification technique • Responsibility-driven design (RDD) • “Identify all the responsibilities of the system and divide between classes before considering the data” • Class-responsibility-collaboration (CRC) cards • In practice, DDD and RDD can be used together

5. Identifying classes in DDD:Noun identification • Identify candidate classes by selecting all nouns and noun phrases in the requirements specification Use singular form of each noun or phrase Do not include “or” or “and” in a single class name • Discard inappropriate candidate classes to get initial class list

6. Noun identification technique:Discarding candidate classes • Consider discarding candidate classes if they are • Redundant • Different nouns or phrases correspond to the same class (e.g., “library member”, “member of the library”) • Vague • Not clear what the noun or phrase means • Events or operations • Is the event or operation a thing with state, behaviour and identity? If not, discard it! • e.g., “short term loan” • Part of the meta-language • Nouns and phrases that refer to aspects of the project, not domain objects • e.g., “requirements”, “system” • Outside the scope of the system • Nouns and phrases that refer to objects that are not inside the system • e.g., “library” • Actors often discarded for this reason if no need to represent them by objects within the system • Attributes • Nouns and phrases that refer to simple things with no interesting behaviour of their own • e.g., name of library member, duration of loan • May also be other reasons to discard a candidate class…

7. What sorts of things are represented by classes? • Most commonly: • Tangible or ‘real-world’ objects and concepts • e.g., book, copy, course, hovercraft • Roles • e.g., library member, customer, manager • Less commonly • Events • e.g., loan, arrival, departure • Interactions • e.g., match, meeting • Events and interactions can help with identifying associations between classes representing domain concepts and roles • Main class that just provides program entry point usually not included in class model • e.g., class containing main method in Java

8. Associations • Classes correspond to nouns (“substantiver”)Associations correspond to verbs (“verber”) • An association between two classes often represents a real-world relationship between the classes of real-world things or concepts represented by the classes • Just as an object is an instance of a class, a link is an instance of an association • A link connects a pair of objects (not classes) • e.g., link between objects representing David Meredith and copy 4 of Fowler (2004) might represent the fact that David Meredith borrows or returns copy 4 of Fowler (2004)

9. Associations • Class A and class B are associated if an object of class A has to know about an object of class B, i.e., • An object of class A sends a message to an object of class B • “b.message()” occurs in definition of A (where b is an object of class B) • An object of class A creates an object ofclass B • “B b = new B()” occurs in definition of A • An object of class A has an attribute whose values are objects of class B or collections of objects of class B • “private B b = null;” occurs in A • “private B[] bList = null;” occurs in A • An object of class A receives a message with an object of class B as an argument • “public ReturnType message(B b) {…” occurs in A

10. Associations • Class model should represent well the real-world relationships between domain concepts • Class model should make sense to a domain expert • Class model should also permit a sensible implementation that realizes the required use cases • Satisfying both these criteria leads to a system that is easy to maintain because it is easy to understand

11. Association in a class diagram • May be two or more different associations between same pair of classes • e.g., LibraryMember has reserved Copy, LibraryMember has Copy on loan • Represented by multiple labelled lines on class diagram

12. Attributes and Operations • In order for the objects of a class to have state and behaviour, the class must have attributes and operations: • Attributes: variables inside objects where data is stored • Declared in second compartment of class icon • Do not include attributes that implement associations (e.g., copies : Copy[1..*]) • Types of attributes should not be classes in the diagram • Operations: the messages that the objects in a class understand and respond to • Declared in third compartment of class icon • Provide selector, arguments and return type • Same operation may be implemented by different methods in different classes related by inheritance

13. Generalization • MemberOfStaff is specialization of LibraryMember • Can do everything that a LibraryMember can do and more (e.g., borrow a journal) • MemberOfStaff should conform to interface of LibraryMember • Liskov substitution principle • May override methods in LibraryMember • Should be no “conceptual gulf” between what a derived class and its base class do on receipt of the same message

14. Generalization • Class B may be a specialization of class A if • every member ofclass B is a member of class A • e.g., Every member of the class MemberOfStaff is amember of the class LibraryMember • All members of class B share one or more properties or behaviours that they do not share with the other members of class A • e.g., all members of the class MemberOfStaff can borrow journals whereas the other membes of class LibraryMember cannot • But inheritance increases coupling so only use when necessary • Every member of the class Border Collie is a member of the class Dog • But may not need subclass Border Collie if the only relevant property or behaviour that Border Collies do not share with other dogs is the name of their breed • Could implement this as an attribute called Breed in an object of class Dog

15. Class models and class diagrams • Each system has only one class modelor static structural model which describes the static structure of the system, particularly the classes and the relationships between them • Maybe two or more class diagrams used to graphically represent the single class model of a system (e.g., at different levels of detail) • May represent the same class more than once on the same class diagram, but all icons representing a class must be consistent with the single class that they all represent • Suggestion: only represent a class once on any given diagram unless using a tool that enforces consistency

16. Aggregation • An aggregation is a special association that shows that objects of one class are parts ofobjects of another class • e.g., degree programme consists of 12 or more courses • Each instance of the “part” class may be associated with more than one instance of the “whole” class • e.g., might have a course in the first year that is attended by students that do different programmes

17. Composition • A composition is a special association that shows that each object of one class is part of at most one object of another class • If an object of the “whole” class is copied or deleted, so are all the objects of the “part” class that are associated with it • e.g., an object representing a chess board may contain a collection of objects of class Square • Each Square object only associated with one ChessBoard object • Square objects deleted or copied when ChessBoard object deleted or copied

18. Examples of aggregation and composition • Are the associations between the following examples of aggregation or composition? • Player and Team • Aggregation • Wheel and Car • Composition • Account and Customer • Composition (but what about joint accounts…?) • Song and Playlist • Aggregation

19. Role names on associations • Can label roles of classes within relationship represented by association in class model

20. Navigability of associations • If class A must know about class B, then draw arrow with stick arrowhead from class A (source) to class B (target) • Each object of class Course must know which students are taking that course in order to generate a list of students for that course (e.g., to print registers) • Each Course object must be able to send messages to the Student objects that are linked to it (e.g., to retrieve the names of the students) • Each Course object might have an attribute students : Students[0..*]would not explicitly give this attribute in the attribute compartment of the Course icon because implied by the directed association • If class A knows about class B, then class A cannot be reused without class B • Increases coupling • Don’t introduce navigability unless required! • Does the association between Student and Course need to be bidirectional? • What if we want to know the courses that each student is taking?

21. Bidirectional navigability and non-navigability • Show bidirectional navigability by putting arrow heads at both ends of the association • Leaving both arrowheads off means unspecified navigability • Fact that class A does not know about class B indicated by placing a cross on the association near class B (new in UML 2.0)

22. Qualified associations • Multiplicity of 1 at Square end of association indicates that, if we take a ChessBoard object, b, then there is exactly 1 Square object associated with any specific pair of values assigned to the row and column attributes of b • Only one or zero lines in any given order associated with a particular product • Order object has (at most) one OrderLine per product

23. Derived associations • Fact that Lecturer class is associated with Student class is implied by association between Lecturer and Course and association between Course and Student • Three options: • Can leave out association between Lecturer and Student • Can put it in as an ordinary association • Can indicate that it can be derived from other associations by preceding label with a forward slash, / • Indicates that association exists by virtue of other associations – no need to be implemented separately

24. Constraints • A constraint is a condition that must be satisfied by a correct implementation of a design • In UML, a constraint must be given between braces, e.g., {xor}, {total number of items borrowed must be no more than 12} • Can use either formal language, such as Object Constraint Language (OCL), or natural language or a programming language to express a constraint

25. Association classes • An association class allows an association to have attributes and operations • Where do we store the result a student gets for a course? In the Student object or in the Course object? • Can make an association class and store result there • Alternatively can make a Result class and associate it with the Course object and the Student object • If student takes course twice, can make two Result objects, but cannot make two association objects • Can only be at most one association object for any given pair of linked objects

26. Interfaces and abstract classes • Abstract operation is declared but not implemented • Written in italics in class icon • Class is abstract if at least one of its operations is abstract • Class name written in italics • Abstract class cannot be instantiated • All operations of an interface are abstract (i.e., no implementation provided) • Dependency arrow used to show that class requires interface • Dashed generalization arrow shows that class provides or implements interface • Weak form of inheritance • Class may provide more than one interface • Good idea to depend on as general a class as possible to allow for different implementations • Order depends on List interface • get, equals and add operations dynamically bound to implementations in ArrayList

27. Dependency Employee data gateway Employee Benefits window Benefits data gateway • Class A depends on class B if a change in class B may necessitate a change in class A • A is client, B is supplier or server • Dependency indicated by dashed arrow with stick head on class diagram • Difference between dependency and assocation: • Dependency indicates relationship between class definitions • Change in definition of class A may necessitate change in defiinition of class B • Association indicates relationship between objects within classes • Objects of class A need to know about objects of class B • Can usually be more specific about the nature of a dependency than merely stating that it exists (e.g., generalization, implementation of interface) • Dependency can exist between A and B if • A sends a message to B • A has an attribute of class B • A has an operation parameter of class B • Change in Employee might mean Benefits window has to be changed • Change in Benefits window will not affect Employee • Change in Employee data gateway may also necessitate change in Benefits window, but only if it necessitates change in public interface of Employee • See page 62 of the UML 2.2 Superstructure specification (available from Moodle)

28. Summary • UML class diagrams document static structure of system • Object-oriented approach should allow us to build, cheaply and quickly, systems that can be adapted to satisfy changes in requirements • Can use various techniques for identifying the classes in a system • (e.g., noun identification technique) • Classes often represent tangible "real-world" objects and concepts • less often, they represent events and interactions • Associations represent the relationships between classes • Classes are associated if one has to know about the other • Two classes can be connected by two or more associations • Multiplicities • Attributes and operations • Generalization • Distinction between class models and class diagrams • Aggregation and composition • Role names • Navigability • Qualified associations • Derived associations • Constraints • Association classes • Interfaces and abstract classes • Dependency