Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1 Building a “Good” Class Model
Stevens Chapters 3 and 5
 A class model is used to statically represent the structure of the system.
 When does Analysis stop and Design begin?
o Some high-level Class modeling can be done with an end user present. In fact it might
be useful to have the user participate in building a conceptual class model.
o We are on the edge between What and How or Analysis and Design.
1.1 Identifying objects and classes
Identifying the objects that a system should have is the first step.
1.1.1 What makes a good class model?
Two objectives for the system that are often in opposition:
 Build a system as cheaply as possible that satisfies our current requirements.
 Build a system, which is adaptable and maintainable.
If we have done a good job of requirements engineering, we are off to a good start – what’s next?
 Find good objects that will provide all of the needed functionality helps with the first objective,
building a system cheaply that satisfies our current requirements.
 Generally, low coupling and high cohesion helps with the second objective, building a system
that is adaptable and maintainable.
We want the classes to represent enduring domain objects that will provide the basis for future
evolution of the system.
1.1.2 How to build the class model?

Don’t expect to get it right the first time.

Domain objects – These are the objects taken clearly from the domain – things we can identify
and touch.

Solution space objects – Software objects that help us manipulate and maintain the domain
objects – these are our linked lists and collections

Two major approaches Data Driven and Responsibility Driven.
©2011 Mike Rowe
Page 1
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
o Data Driven – find entities and then define their functionalities
o Responsibility Driven – build the system around clients and servicers. The servers have
responsibilities to the clients.
From Terry Quatrani, UML Evangelist, Introduction to the Unified Modeling Language
1.1.3 Noun Identification Technique
What is an object? It is some “thing” that has
 State
 Identity,
 Behavior, and
 Responsibility.
Behavior and Responsibility can be very related in many objects
©2011 Mike Rowe
Page 2
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Noun Identification approach to finding Objects:
Underline all nouns and noun phrases in either requirements or use case scenarios.
See page 33 of Stevens (with some local additions):
Books and Journals: The library contains books and journals. It may have several copies of a given
book. Some of the 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 members of the staff may borrow up to 12 items at one time. Only members of staff may borrow
journals. If a library member, who has University Holds in the PeopleSoft System may not borrow
books.
Borrowing: The system must keep track of when books and journals are borrowed and returned,
enforcing the rules described.
After underlining:
Books and Journals: The library contains books and journals. It may have several copies of a given
book. Some of the 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 members of the staff may borrow up to 12 items at one time. Only members of staff may borrow
journals. If a library member, who has University Holds in the PeopleSoft System may not borrow
books.
Borrowing: The system must keep track of when books and journals are borrowed and returned,
enforcing the rules described.
1.2 Nouns and Noun Phrases are candidate classes














Library
Books
Journals
Copies of a given book
Short term loan
Library member
Weeks
Members of the library
Items
Members of the staff
Rules
Time
University Holds
PeopleSoft System
©2011 Mike Rowe
Page 3
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Next discard candidates that are:
 Redundant terms can be combined – or perhaps generalized/specialized (inheritance):
o “Members of library” and “Library member” are the same.
o Also, “item” turns out to be either a “book” or a “journal”. We can generalize here.

Look for items that are beyond the scope of the system (the Task-level Goal List and Design
Scope/Context Diagram should assist with this):
o Library – we may need just certain interfaces to other parts/systems of the library
o PeopleSoft – out of scope but we definitely need an interface to it.

Events, the kind of which don’t have state. These are not objects:
o Short term loan

Units of time are generally not objects (although might want a Date Class):
o Weeks

Time as in “at a time” does not represent a thing but a way of doing things.

“Rules” in this context does not represent something tangible. In some systems (like expert
systems), “rules” could represent objects.
We are left with:
 Book
 Journal
 Copies of books (many books)
 Library member
 Members of the staff (Librarian)
 University Holds
 PeopleSoft System
 Maybe (Library)
Remember that Objects have
 Identity,
 State,
 Behavior, and
 Responsibility
Can we identify these capabilities in each of the above?
 For instance: Librarian
o Identity: Name of person, title, . . .
o State: On duty, on lunch break, helping someone, . . .
o Behavior: Check out book, check for holds, reshelf a book, Check book in, . . .
o Responsibilities: provide book checkouts to library users, . . .
©2011 Mike Rowe
Page 4
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
If we have a noun that doesn’t have State and Behavior or Responsibility then is may be part of an object
(an attribute).
If we look at actors – we may find good candidates for objects in the model. We had Library Member,
Librarian, and PeopleSoft before.
 PeopleSoft is an actor that represents an abstraction of an existing system, which is outside the
scope of this system.
o A class can serve as an abstraction of this external PeopleSoft system.
o It is often advantageous to use a class for the interface to an external system as it
decouples our system from the other system.

Library Member clearly has state, in that we need to keep track of which books each Library
member has checked out and keep track of how many books each member has checked out
(they are only allowed to check out 6 books).

Member of the staff (Librarian) may also check out books and journals so we need to keep this
state data.
1.3 Relations between classes

It is important to clarify our understanding of the domain by defining how objects work
together, and also look into the coupling of the objects.
1.3.1 Relationships




“a Copy of book” is-a “book“ ( a book is defined as a title or ISBN number)
a library member borrows and returns a copy of a book
a members of staff borrows and returns a copy of a book
a member of staff borrows and returns a journal
1.3.2 Multiplicities
Help define the associations.
Potential
Multiplicity Values
0..1
1
0..* or *
1..*
N
0..n
1..n
©2011 Mike Rowe
They define the ratio of one object to another for two classes.
Indicator Meaning
Zero or one
One only
Zero or more
One or more
Only n (where n > 1)
Zero to n (where n > 1)
One to n (where n > 1)
Page 5
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
See p36 of Stevens for Initial Class Model
Book
1
is a copy of
1...*
borrows/returns
LibraryMember
0..*
0..1
ns
s/retur
borrow
Copy
0..*
0..1
borrows/returns
Journal
MemberOfStaff
0..1
0..*
A Book is a title. We can have many copies of the same book in a library. A LibraryMember can
checkout zero or one of these copies of a book, and a can check out a copy of many books.


There are two multiplicities that do not agree with the brief/description listed previously. Can
you find which ones are inconsistent?
o Members of the library can normally borrow up to six items at a time, but members of
the staff may borrow up to 12 items at one time.
o Thus, the 0..* from LibraryMember to Copy should be 0..6 and the associations from
MenberofStaff to Copy and Journal should be 0..6 and 0..12 rescpectively.
One way to get multiplicities right is to put yourself in the place of a class and look down each
association and see how many possible copies of an object you can see at the end of the
association. Then put that number at the far end of the association as the multiplicity.
©2011 Mike Rowe
Page 6
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
MemberOfStaff is a specialization of LibraryMember, in that they can do all actions that a
LibraryMember can, plus they can check out and check in books to other people, and borrow Journals.
We may or may not end up implementing MemberOfStaff as a derived class of LibraryMember.
Book
1
is a copy of
1...*
borrows/returns
LibraryMember
0..*
0..1
Copy
0..*
Generalize
borrows/returns
MemberOfStaff
Journal
0..*
0..1
Above is an analysis level Class Diagram, it only has domain level classes, names of classes, important
relationship between classes, and multiplicities.
BankAccount
-owner : string = ""
-balance : double = 0
+deposit(in amount : double) : double
+withdraw(in amount : double) : double
SavingsAccount
CheckingAccount
-insufficientFunds : double = 0
-annualInterestRate : double = 0.035
+processCheck(in checkToProcess) : bool
-depositMonthlyInterest() : bool
This is a design-level class diagram.
 Note that we have specified Attributes (including their type and initial values) and Operations
(including return values and parameters with types).
 We also specify access (private, public protected).
 CheckingAccount and SavingsAccount inherit attributes: owner and balance as well as operations
deposit and withdraw from BankAccount.
©2011 Mike Rowe
Page 7
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1.4 CRC Method – class-responsibility-collaboration


Used to develop classes and show interactions among classes.
If designers have domain expertise or good scenarios using CRC (class-responsibilitycollaboration) cards can be helpful. This dates back to late 1980s. (Beck and Cunningham, 1989
-- of XP fame 1999)
o Collaborators: other objects that work together with this class, either provide services or
use services of this class. (coupling indicator).
o Responsibilities: functionality that the class must perform (methods).
o The process:

For each candidate class the team fills in a card that contains the name of the
class, the functionality of the class (Responsibility), and a list of the other classes it
invokes to achieve that functionality (Collaboration). This information comes from
requirements and /or use cases.

Next the Cards are taped to a wall and line or string connect the public methods
and data of all classes.

Too many lines means high coupling.

This could be caused to low cohesion -- an object is doing too many things
thus it has associations to lots of other objects.

After these CRC have been stated, details of attributes and methods can be added.

The CRC card were becoming less popular as non-paper and pencil techniques
have become better. It looks like their use may be coming back. A number of
books are using similar methods in conjunction with Use Case Centric approaches.
Also, Beck and Cunningham seem to have evolved these into Extreme
Programming “Stories”.
Class: Elevator Button:
Superclass or Subclass :
Responsibilities
©2011 Mike Rowe
Collaborators
Page 8
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Class: Elevator Button:
Superclass or Subclass : Button
Responsibilities
Collaborators
Request floor desired
Request to close door
Request to open (keep door open)
Request alarm
Request elevator halt
User
Elevator Controller
There are a lot of responsibilities for this class. This is a sign of low cohesion. We may want to consider
breaking this into multiple classes. For instance, in an elevator we have many different types of buttons
that command very different activities: Floor Button (request a particular floor), Door Button (hold door
open), Alarm Button (call 911), …
If we have a lot of collaborators we have signs of high coupling. In this case it is caused by low cohesion.
Again, one solution to this might be to specialize the class by breaking it into multiple classes.
Example: The Elevator System Scenario (user is standing by the elevator on floor 3):
1. User A presses Up Floor Button at Floor 3 to request Elevator. { user A wishes to go to Floor 7 }
2. Floor button sends a signal to the Elevator Controller
3. Elevator Controller send signal that turns on the UP Floor button
4. Elevator Controller sends a message that starts the elevator moving to the 3 rd Floor.
5. An Elevator arrives at Floor 3 and sends message to the Elevator Controller that it is at the 3 rd floor.
6. Elevator Controller sends a message to open the elevator door.
7. Elevator door opens
8. Elevator door sends a message to the Elevator controller that the door is open.
9. Elevator controller requests a 15 second interval from the timer
10. User A enters the elevator
11. User A pressed the 7th Floor button in the Elevator
12. The 7th Floor button sends a message to the Elevator controller requesting the 7 th floor.
13. The Elevator controller added the 7th floor to the stops requested list.
14. It contains User B who has entered the Elevator at Floor 1 and pressed the Elevator Button for Floor
9.
15. Elevator controller turns off the Up Floor Button on floor 3
16. Timer sends a message to the Elevator Controller indicating a timeout.
17. Elevator controller sends a message to the door to close
18. The door sends a message to the Elevator controller indicating the door has closed.
19. The Elevator Controller sends a message to the Elevator to move to Floor 7.
20. The Elevator sends a message that it has arrived at Floor 7.
21. Elevator Controller sends a message to open the elevator door.
©2011 Mike Rowe
Page 9
2/6/2016 12:50:00 PM
Notes: 005 – Introduction Class Diagrams
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
22. Elevator door opens
23. Elevator door sends a message to the Elevator controller that the door is open.
24. Elevator controller requests a 15 second interval from the timer
25. User A leaves the elevator
26. The Elevator controller turns of the elevators 7th floor request button.
27. Timer sends a message to the Elevator Controller indicating a timeout.
28. Elevator controller sends a message to the door to close
29. Elevator proceeds to Floor 9 with User B.
UpButton
+pushBttn
User
+turnLightOff
Button
+turnOnLight
+getOff
+pushBttn
7thFloorButton
turnOffLight
+requestFloor
turnOnLight
+requestFloor
+getOn
ElCntrl
+startTimer
Timer
+moveToFloor
Elevator
+openDoor
+closeDoor
ElDoor
©2011 Mike Rowe
Page 10
2/6/2016 12:50:00 PM