Chapter 3
UML class diagram
What makes a class model good
Build as quickly and cheaply as possible, a system which satisfies our current requirements Build a system which will be easy to maintain and adapt to future requirements (encapsulated module, low coupling and high cohesion) These aims are often seen as being in conflict
How to build a good class model
You will not be able to get it from the first time a class diagram will change over and within the iterations of development you will identify at the beginning the most important class of domain objects (those that belong to the problem) other classes which correspond less clearly to domain objects are harder to identify with confidence
One technique:noun identification
1. Identify candidate classes by picking all the nouns and noun phrases out of a requirements specification of the system (consider them in the singular and do not include phrases containing or as single candidates 2. Discard candidates which are not appropriate for any reason, renaming the remaining classes if necessary
Reasons to discard candidates
Redundant:
same class with multiple name, similar objects represent one class, different objects correspond to different classes, have in mind inheritance
vague:
unambiguous name, can tell the meaning from the a noun. Obviously you have to clear up the ambiguity before you can tell whether the the noun represents a class
noun refers to something done to, by or in the system; Ask your self weather the noun represents a class noun that forms part of the way we define things (requirements, system) noun relevant to describe how the system works but does not refer to something inside the system (actors)
an event or an operation: meta-language:
outside the scope of the system:
an attribute: simple noun with no interesting behavior
Question!
If you are in doubt whether to keep a class, do you think it is better to keep it in or throw it out?
Many point of views keep two lists: one for strong candidates and one for weaker ones useful technique for keeping information
What kind of thing are classes
Tangible or real world things: book, copy, course Roles: library member, student, director of studies Events: arrivals, leaving, request Interaction: meeting, intersection, conference
Association
Association represents relationship between classes Association must reflect real-world relationship We identify associations for two reasons:
to clarify our understanding of the domain: describe objects in terms of how they interact together to sanity-check the coupling in our end system, i.e. make sure that we are following good principles in modularizing our system (maintenance, reuse)
An OO system must reflect the structure of reality
Example
A copy is a copy of a book a library member borrows/returns a copy a member of staff borrows/returns a copy a member of staff borrows/returns a journal
Case study: Library
Books and journal The library contains books and journals. It may have several copies of a given book. Some books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but for members of staff may borrow up to 12 at one time. Only members of staff may borrow journals. Borrowing The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above.
Case study: Library
Books and journal The library contains books and journals. It may have several copies of a given book. Some books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but for members of staff may borrow up to 12 at one time. Only members of staff may borrow journals. Borrowing The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above.
Classes to discard
Library: because its outside the scope of our system short term loan, because a loan is really an event, the lending of a book to a user, which is so far not a useful object in this system member of the library is redundant, same as library member week, measure of time not a thing item, its vague, when we clarify it we see book or journal time, its outside the scope of the system system because it is part of the meta-language of requirements description, not part of the domain rule, for the same reason this leaves:
book, journal, copy (of book), library member, member of staff
Book 1 is a copy of 1..* Copy
LibraryMember
borrows/returns
0..1
0..*
0..*
0..1
borrows/returns
MemberOfStaff borrows/returns 0..1 0..*
Journal
Initial Class model of the library
Book 1 is a copy of 1..* Copy
LibraryMember
borrows/returns
0..1
0..*
MemberOfStaff borrows/returns 0..1 0..*
Journal
Revised library class model
Roles
Roles represent the way the two classes see each other. Another way to document the association We can choose to put roles or the association name or both, however this is likely to be overkill in most situations
Director of Studies
Supervisor
directee
Student
Navigability
Student 1..* is taking 6 Module Shows in which way the message should be sent Module knows about student but not vice versa Dont use navigability unless its required for the current application, or to think there is good to think it will be required in future. Sometimes its essential to allow two-way navigability along an association Such decision should be individually justified, rather than being the default is taking 1..* 6
Student
Module
Qualified association
To give finer detail to the association Consider the following example: Nought and Crosses application of the game framework Suppose a square is identified relative to the Board its on by attributes row and column, each taken a value between 1 and 3
Board
Square
Qualified associations
If we take a Board object, call it b, and specific values for both the attributes row and column, there is exactly one Square object which is associated with the Board object b for each Board we have a look-up table in which we look up a Square by its row and column each Square occurs in just one table, just once Formally row and table are attributes of the association each link between Board and Square has values of row and column, which identified where the Square is on the table
row:{1,2,3} column:{1,2,3}
Board
Square
Qualified associations
If we take a Board object, call it b, and specific values for both the attributes row and column, there is exactly one Square object which is associated with the Board object b for each Board we have a look-up table in which we look up a Square by its row and column each Square occurs in just one table, just once Formally row and table are attributes of the association each link between Board and Square has values of row and column, which identified where the Square is on the table
row:{1,2,3} column:{1,2,3}
Board
Square
Derived associations
Its an association that its existence may be deduced from others associations on a class diagram Student
is taking
Module teaches course
/teaches student Lecturer
In UML there can be derived elements other than associations; derived attribute Avoid showing derived elements in a diagram since they add complexity without new information However add a derived element when it is prominent in the terminology and excluding it impairs comprehension
Constraints
A constraint is a condition that has to be satisfied by any correct implementation of a design We can specify a constraint graphically on the UML diagram or by expressing it in OCL (Object Constraint Language) Example:
self.noOfStudents > 50 implies (not (self.room = 3317)) if the number of student is greater than 50 than the course does not take place in room 3317
Associations classes
An Association Class is that whose attributes are related to the association and its life time is dependent on the association. Association class allows you to add attributes, operations and other features to associations. Clues that an association class might be useful in a domain model:
An attribute is related to an association. Instances of the association class have a life-time dependency on the association. There is a many-to-many association between two classes and information associated with the association itself. There is a many-to-many association between two classes and one or more attributes of a class has multiple values.
Associations classes
Sometimes the way objects are associated is just as important as the objects themselves Consider the association between Student and Module, where should our system record the students marks on this course the marks are collected to the pair student and module we need data to be attached to the association link
Example
Student
1..*
is taking
Module
is taking mark: int
Example
Student
1..*
is taking
Module
1
6 Mark mark: int 1..*
Stereotypes
A stereotype provide the capability to create a new kind of modeling element Its UMLs way of attaching extra classifications to model element; its one of the way that UML is made extensible The stereotype of a class is shown above the class name enclosed in guillemets (<< >>)
Common stereotype
Boundary: class representing an interface to the outside world Entity: class representing an abstraction of some real world entity Control: class responsible for sequencing information Exception: a class representing an exceptional condition; a serious error Interface: class representing a specification for externally visible operations
Interfaces
An interface specifies a list of operations which anything matching the interface must provide No implementations are associated with any of the operations It has no attributes, and no association can be navigable from an interface
An interface and its use
<<interface>> Stringifiable stringify():String
Module
stringify():String
...
<<uses>>
Stringifiable
Printer
Abstract classes
An abstract class means that for at least one of its methods no implementation is defined An abstract class cannot be instantiated
{abstract} Student
Parameterized classes
A parameterized class is not actually a kind of class, it can be seen as kind of function it takes some classes and return a class Sometimes its called a Template classic example is List(T), which given a class C to substitute for the formal parameter T, describes the class of lists of C objects
Parameterized classes
T
List
Add(t:T, pos:int) get(I:int):T <<bind>> (student) List<Game>
An object of type studentList represents a list of students an object of list<Game> represents a list of game
StudentList
Package
A package is a collection of model elements There is several reasons for wanting to package some model element together:
convenience reasons: hide some irrelevant details to define the parts of a system to be implemented by each of several teams to specify and design a component, making sure you understand the interactions between the component and the context in which its used
Packages be nested within other packages
Example of packages
Trading domain
Administration
Services
