Lecture 5:

Class Models and Diagrams

• Class models
– What makes a good class?
– Developing the class model
• Finding classes and associations (Part 1)
– Noun identification
• Basics of UML Class Diagrams
– Class notation
– Associations
• ATM Case Study: initial class model

BK - Spring 2006
 What is a Class Model?
• Model of the static structure of a system
– What classes are there?
– How are these classes related?
• Allocation of class responsibilities:
– Management of data within the system
– Behavioural responsibilities of classes
• May not be immediately concerned with:
– functional requirements
– how classes interact to achieve behaviour

BK - Spring 2006
 What Makes a Good Class Model?
A good class model consists of classes that
1. can provide all of the required system behaviour
2. represent (as far as possible) enduring domain objects
If 1 is self-evident, 2 is more like an act of faith:
– part of the object oriented design philosophy
– modelling the application domain can provide a good basis
for developing the required software
– in practice, need to compromise between 1 and 2

BK - Spring 2006
 Developing the Class Model
Class model typically developed in stages:
• Analysis phase:
– Classes in problem domain of primary interest
– Basic relationships between classes
– Little detail about class responsibilities
• Design phase:
– Additional classes provided for implementation
– Class responsibilities (attributes, operations) refined
– Relationships between classes refined

BK - Spring 2006
Finding Classes and Associations
• How do we find classes?
– Doesn’t really matter, as long as the resulting class model is good!
• We’re unlikely to get it right first time:
– Probably shouldn’t even try!
– Finding classes and associations is a process of:
• Refinement
• Revolution

BK - Spring 2006
 Noun Identification
• A way of finding “enduring domain objects”:
• A “data driven development” (DDD) method
– Useful in early stages of development (analysis)
– Provides “first-cut” set of problem classes

• Useful in analysis of requirements:

– Pick out all nouns/noun phrases in requirements documentation
– Filter out ‘inappropriate’ expressions
– Use remaining phrases as candidate classes

BK - Spring 2006
 ATM Case Study:
Finding Candidate Domain Classes
Step 1: identify nouns/noun phrases:

An ATM is an electronic device designed for automated

dispensing of money. A card holder can get a balance, or
withdraw money from an account after authorization. Customers
interact with the system through a simple interface consisting of
a display screen, a card reader and a numeric keypad. Cash is
obtained from a dispenser. Bank members are card holders who
can access additional functions such as ordering a statement
from the bank.

BK - Spring 2006
 ATM Case Study:
Finding Candidate Classes
Stage 2: Discard candidates that are:
– Events: dispensing of money, authorization
– Vague: function, device
– Meta-language terms: system
– Redundant terms: customer same as card holder; cash
same as money
– Outside scope of system: bank
• but retain actors such as card holder?
– Constitute everything: ATM (system)
• Avoid monolithic design!

BK - Spring 2006
 ATM Case Study:
Finding Candidate Classes
• Remaining nouns represent candidate domain
objects/classes:
– Actor/Role entities: card holder, bank member
– Boundary (interface) objects: interface, card reader, keypad,
display screen, cash dispenser
– Entity (domain) objects: balance, money, account, statement
• This analysis provides the initial set of classes in the ATM
class model.

BK - Spring 2006
 Basics of UML Class Diagrams
Notation for documenting class models:
• Notation for classes:
– Rectangle with class name (minimally)
– Details of attributes and operations (additionally)
• Notation for relationships:
– Associations: model dependencies between classes
– Generalizations: model “is a” relationships between classes
• Model represented by one or more class diagrams

BK - Spring 2006
 Basics of UML Class Notation
Only class name shown Operations shown

CardHolder CardHolder
authorize()
Both attributes
Attributes shown and operations
CardHolder CardHolder shown, with type
lastName lastName:String information
firstName firstName:String
authorize()

BK - Spring 2006
 Basics of UML Associations
In the banking domain
each CardHolder has Simple association
an Account between classes

CardHolder Account

holds
CardHolder Account

Named
association

BK - Spring 2006
 What Do Associations Imply?
• An association implies collaboration between instances of
two classes
– Classes A and B are associated if an instance of A needs to “know
about” an instance of B
• A needs to “know about” B if an instance of A:
– sends a message to an object of class B, or
– has an attribute with a value of class B, or
– creates an object of class B, or
– receives a message with an object of class B as an argument

BK - Spring 2006
 ATM Case Study:
Initial Class Model
holds has
CardHolder Account Balance

CashDispenser ATMUI

Initial class diagrams Screen CardReader KeyPad

for the ATM System

BK - Spring 2006
 Summary
• Class model represents static structure of system
– Classes and their relationships
• Developing class model is a staged process:
– May begin by identifying classes in application domain
– Later add classes required for implementation reasons
• Noun identification is a simple analysis technique for
finding domain classes
• UML class diagrams used to document class model

BK - Spring 2006