1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 4 Class Models (Based on Fowler (2004, Chapters 3 & 5) and Stevens and Pooley (2006, Chapters 5 & 6)) David Meredith

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

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 Associations correspond to verbs 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 –An object of class A creates an object of class B –An object of class A has an attribute whose values are objects of class B or collections of objects of class B –An object of class A receives a message with an object of class B as an argument

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 of class B is a member of class A e.g., Every member of the class MemberOfStaff is a member 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 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 consistency

16 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., the course CIS109 is part of several different computing degree 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 (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 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 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 Benefits window Employee Employee data gateway Benefits data gateway

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