Design and UML Class Diagrams

Suggested reading:
Practical UML: A hands on introduction for developers
http://dn.codegear.com/article/31863
UML Distilled Ch. 3, by M. Fowler
1
 How do people
draw / write down
software architectures?
 Design phase
• design: specifying the structure of how a software
system will be written and function, without actually
writing the complete implementation

• a transition from "what" the system must do, to

"how" the system will do it
– What classes will we need to implement a system that
meets our requirements?
– What fields and methods will each class have?
– How will the classes interact with each other?
 Big questions
• What is UML?
– Why should I bother? Do people really use UML?

• What is a UML class diagram?

– What kind of information goes into it?
– How do I create it?
– When should I create it?
 What is UML?
• pictures of an OO system
• lots of companies use it
• a descriptive language: rigid formal syntax (like programming)
• can omit things from UML diagrams if they aren't needed by
team/supervisor/instructor
 Uses for UML

• as a sketch: to communicate aspects of system

– backward design (after design is done, to document it)
– forward design (use diagram to build & improve design as it develops)

• as a blueprint: a complete design to be implemented/coded

• for tools that automatically create code from UML

– only good if this is faster than coding in a "real" language
 UML
In an effort to promote Object Oriented designs,
three leading object oriented programming
researchers joined ranks to combine their
languages:

– Grady Booch (BOOCH)

– Jim Rumbaugh (OML: object modeling technique)
– Ivar Jacobsen (OOSE: object oriented software eng)

and come up with an industry standard [mid 1990’s].

UML – Unified Modeling Language
• Union of all Modeling Languages
– Object diagrams
– Class diagrams
– Use case diagrams
– Sequence diagrams
– Collaboration diagrams
– Statechart diagrams
– Activity diagrams
– Component diagrams
– Deployment diagrams
– ….
• Very big, but a nice standard that has been
embraced by the industry.
 Object diagram (≠ class diagram)
• individual objects
– objectName : type
– attribute = value

• lines show field

references
An object diagram shows a
possible snapshot of the system
at some point in time, in terms of
a few objects & their connections

It is easier to understand any concept if you are shown a small example of such a
thing. Object diagrams are useful in this way, as they’re simpler than class diagrams
 UML class diagrams
• UML class diagram: a picture of
– the classes in an OO system
– their fields and methods
– connections between the classes
• that interact with, or inherit from, each other
• Not represented in a UML class diagram:
– details of how the classes interact with each other
– algorithm details; how a particular behavior is
implemented. E.g. the methods can include
+ calcGPA( ) : int
which does not show how GPA will be calculated
 How do we design classes?
• class identification from project spec / requirements
– nouns are potential classes, objects, fields
– verbs are potential methods or responsibilities of a class
• CRC card exercises
– write down classes' names on index cards
– next to each class, list the following:
• responsibilities: jobs/services it will provide; short verb phrases
• collaborators: other classes that are sent messages by this class
(asymmetric)
• UML diagrams
– class diagrams (today)
– sequence diagrams
– ...
 Peeping ahead (details next term):
An abstract class is a class where one or more
methods have no code body yet
Eg. abstract class Pet: methods like age will have a code
body (today – dob; for all kinds of pet), but makeSound
will have no code body yet (depends what kind of pet!)

An interface is a list of method headings

E.g. Jo makes class X, how can Jo get other classes to
call its methods? Jo can “advertise” using an interface!
Ann wants to call a method of class X, but what is its
name? parameters? Oh great, the interface lists them!
 Diagram of one class
• class name in top of box
– write <<interface>> on top of interfaces'
names
– use italics for an abstract class name

• attributes (optional)
– should include all fields of the object

• operations / methods (optional)

– may omit trivial (get/set) methods
• but don't omit any methods from an interface!
– should not include inherited methods
Interfaces and Abstract classes shown
differently at the top
an interface

an abstract
class

a (ordinary)
class
Class attributes (fields, instance variables)
– visibility name : type [count] = default_value

– visibility: + public
# protected
- private
~ package (default)
/ derived

– underline static attributes

– derived attribute: not stored, but can

be computed from other attribute values

– attribute example:
- balance : double = 0.00

Omit [count] and default if not array or no

default value (else count is no. elements)
 Class operations / methods
– visibility name (parameters) : return_type

– visibility: + public
# protected
- private
~ package (default)

– underline static methods

– parameter types listed as (name: type)
– omit return_type on constructors and
when return type is void

– method example:
+ distance(p1: Point, p2: Point): double
 Comments
• represented as a folded note, attached to the
appropriate class/method/etc by a dashed line
 Relationships between classes
• generalization: an inheritance relationship
– inheritance between classes
– Inheritance between interfaces

• association: a usage relationship

– dependency
– aggregation
– composition
 Peeping Ahead: what’s inheritance ?

Generalisation/inheritance is used when you have a general kind of object, and you
also have different specialized kinds of that object.
Here, a company has Employees, but there are 9 different kinds of Employee, which
have a lot in common but a few differences.
E.g. all Employees have an ID, phone, email etc but HourlyEmployees have
hourlyPay & overtimePay, while SalariedEmployees have monthlyPay & xmasBonus.
TechnicalStaff & Executives are different kinds
7-19 of SalariedEmployees, etc.
Copyright © 2017 Pearson Ltd. All rights reserved.
Generalization (inheritance) relationships
• hierarchies drawn top-down
• arrows point upward to parent
• line/arrow styles indicate whether parent is
a(n):
– class:
solid line, black arrow
– abstract class:
solid line, white arrow
– interface:
dashed line, white arrow

• often omit trivial / obvious generalization

relationships, such as drawing the Object class
as a parent
Generalization (inheritance) relationships
Arrow style indicates if parent is a(n):
– class:
solid line, black arrowhead

– abstract class:
solid line, white arrowhead

– interface:
dashed line, white arrowhead
RectangularShape is an abstract
class because of the solid line with
white arrowhead, & because its name
is in italics
 Associational relationships
• associational (usage) relationships
1. multiplicity (how many are used)
* ⇒ 0, 1, or more
1 ⇒ 1 exactly
2..4 ⇒ between 2 and 4, inclusive
3..* ⇒ 3 or more (also written as “3..”)
2. name (what relationship the objects have)

3. navigability (direction)
 Association types Car

1
aggregation
• aggregation: “is part of” 1
Engine
– symbolized by a clear white diamond

• composition: “is entirely made of” Book

composition
– stronger version of aggregation
1
– the parts live and die with the whole
*
– symbolized by a black diamond
Page

• dependency: “uses temporarily”

– symbolized by dotted line dependency
– often is an implementation
detail, not an intrinsic part of Lottery Random
that object's state
Composition/aggregation example

If the movie theater goes away

so does the box office =>composition
but movies may still exist =>aggregation
Aggregation : part can exist even if the aggregate doesn’t exist
clear white diamond

Composition : part cannot exist without the composite

solid black diamond
 Part / whole Relationships
Association Aggregation Composition

CheeseBurger and
Only a Packaging are related, but A cheeseburger must comprise
relationship one can exist without the (be made of) a bun, a patty and
between classes other cheese; if the cheeseburger goes,
then the bun, patty & cheese go
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/uml-aggregation-vs-composition/
https://sparxsystems.com/resour
ces/tutorials/uml2/class-
diagram.html
 Multiplicity of associations
 one-to-one
 each student must carry exactly one ID card

 one-to-many The diamonds are on

the wrong end! They
 one rectangle list can contain many rectangles should be by Student
& RectangleList !!!!
Example: people

Must still add the visibility,

parameters and types
Class diagram example
No arrows; info can
flow in both directions

Aggregation – Order class

contains OrderDetail
classes. Could be
composition?
 Using only 1
arrowhead when
there are 3
special kinds (like
here) can ONLY
be done for
generalisation

www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 Class diagram example: video store
Multiplicity

Customer Simple
1
Class Aggregation

Abstract Rental Invoice

Class

Rental Item 1..*

1 0..1

Composition Simple
Generalization Association

Checkout Screen
DVD Movie VHS Movie Video Game
https://www.edrawmax.
com/article/uml-class-
diagram-explained.html
 Tools for creating UML diagrams
• Violet (free)
– http://horstmann.com/violet/

• Rational Rose
– http://www.rational.com/

• Visual Paradigm UML Suite (trial)

– http://www.visual-paradigm.com/
– (nearly) direct download link:
http://www.visual-paradigm.com/vp/download.jsp?product=vpuml&edition=ce

(there are many others, but most are commercial)

 Class diagram pros/cons
• Class diagrams are great for:
– discovering related data and attributes
– getting a quick picture of the important entities in a system
– seeing whether you have too few/many classes
– seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
– spotting dependencies between one class/object and another

• Not so great for:

– discovering algorithmic (not data-driven) behavior
– finding the flow of steps for objects to solve a given problem
– understanding the app's overall control flow (event-driven?
web-based? sequential? etc.)
UML Examples
 Problem Statement
• We want to model a system for management of flights and pilots.
• An airline operates flights. Each airline has an ID.
• Each flight has an ID a departure airport and an arrival airport: an
airport as a unique identifier.
• Each flight has a pilot and a co-pilot, and it uses an aircraft of a
certain type; a flight has also a departure time and an arrival time.
• An airline owns a set of aircrafts of different types.
• An aircraft can be in a working state or it can be under repair.
• In a particular moment an aircraft can be landed or airborne.
• A company has a set of pilots: each pilot has an experience level:
• 1 is minimum, 3 is maximum.
• A type of aeroplane may need a particular number of pilots, with a
different role (e.g.: captain, co-pilot, navigator): there must be at least
one captain and one co-pilot, and a captain must have a level 3.
Analyse - nouns are candidate class or instance variable names

• We want to model a system for management of flights and pilots.

• An airline operates flights. Each airline has an ID.
• Each flight has an ID, a departure airport and an arrival airport: an
airport as a unique identifier.
• Each flight has a pilot and a co-pilot, and it uses an aircraft of a certain
type; a flight has also a departure time and an arrival time.
• An airline owns a set of aircrafts of different types.
• An aircraft can be in a working state or it can be under repair.
• In a particular moment an aircraft can be landed or airborne.
• A company has a set of pilots: each pilot has an experience level:
• 1 is minimum, 3 is maximum.
• A type of aeroplane may need a particular number of pilots, with a
different role (e.g.: captain, co-pilot, navigator): there must be at least
one captain and one co-pilot, and a captain must have a level 3.
Classes (and their instance variables) designed from the nouns in that example.

1
 UML Class Diagram: Exercise
What classes and associations to use here?
We need a software system for a consortium of 4 banks. Customers can
open any number of accounts at each bank, and can be customers of
any number of the 4 banks. At every bank, there is only 1 customer that
holds that account. There are 2 types of account, Savings accounts and
Loan accounts. All accounts have a history of their balance as it
changes over time; loan accounts also have a minimum (monthly
payment) and a terms value (number of months within which they must
be fully paid back) . Customers can perform 3 kinds of transaction on
their accounts: deposits, withdrawals and transfers (of money from 1
account to another). Customers can have any number of credit cards,
and each credit card belongs to only one customer.