Lecture 7 Class Models Based on Fowler 2004

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

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 2

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 3

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 4

Identifying classes in DDD: Noun identification 1. 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 2. Discard inappropriate candidate classes to get initial class list 5

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… 6

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 7

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) 8

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 of class 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[] b. List = null; ” occurs in A – An object of class A receives a message with an object of class B as an argument • “public Return. Type message(B b) {…” occurs in A 9

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 10

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

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 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 12

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

Generalization • Class B may be a specialization of class A if – every member of class B is a member of class A • e. g. , Every member of the class Member. Of. Staff is a member of the class Library. Member – 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 Member. Of. Staff can borrow journals whereas the other membes of class Library. Member 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 14

Class models and class diagrams • Each system has only one class model or 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 15 consistency

Aggregation • An aggregation is a special association that shows that objects of one class are parts of objects 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 16

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 Chess. Board object • Square objects deleted or copied when Chess. Board object deleted 17 or copied

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 18

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

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? 20

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 21 in UML 2. 0)

Qualified associations • Multiplicity of 1 at Square end of association indicates that, if we take a Chess. Board 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 Order. Line per product 22

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 23

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 24

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 25 linked objects

Interfaces and abstract classes • Abstract operation is declared but not implemented • 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 – – • • Written in italics in class icon 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 Array. List 26

Dependency Employee data gateway Benefits window Employee 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 27 only if it necessitates change in public interface of Employee See page 62 of the UML 2. 2 Superstructure specification (available from Moodle)

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 28