Asper School of Business
University of Manitoba
Systems Analysis & Design
Instructor: Bob Travica
Analyzing system data:
Class diagram
Updated: October 2014
3510 Systems Analysis & Design *
Bob Travica
1
Outline








Problem domain classes
Identifying reality aspects to be
represented in information system
Master and Transactional Data
Associations between reality aspects and
between Classes
Attributes, Values, and Objects
Multiplicity
Generalization/Specialization association
Part-Whole association
3510 Systems Analysis & Design * Bob Travica
Identifying aspects of reality to
be represented in system
Customer
customerNumber
customerName
customerAddress
…
addNew()
change() …
Physical reality a person in the
customer role
Information System a class Customer
(older term “Entity”)
3510 Systems Analysis & Design * Bob Travica
Identifying aspects to be
represented in a system (cont.)
CONCEPTS
REALITY ASPECTS
“THINGS”
PEOPLE IN
3510 Systems Analysis & Design * Bob Travica
CUSTOMER SATISFACTION
EMPLOYEE PERFORMANCE
HAPPINESS
*
Identifying aspects to be
represented in system (cont.)

List nouns users mention when
discussing system

Event table/use cases as source of
aspects of interest:
- Use cases (Create new Order)
- Actors (Salesperson, Customer)

Responses (Create Invoice)
3510 Systems Analysis & Design * Bob Travica
Problem domain classes

Problem domain=Area of business a
system supports


Identifying and analyzing aspects within a
problem domain = essential to defining
systems requirements
Problem domain = customer ordering
Problem domain classes = Customer,
Order, Item
3510 Systems Analysis & Design * Bob Travica
Translating reality aspects in
two kinds of classes (data)

Considering the stable/static vs. dynamic reality
aspects, it is useful to differentiate between:

Master classes: “Static, permanent aspects” that
make business foundations (people in roles,
physical things, organizational units – Employee,
Department, Task, Job, Product, Supplier,
Customer…)

Transaction classes: “Dynamic, changing
aspects” that make business operations (events
-- Customer Order, Purchasing Order, Sale,
Payment)
3510 Systems Analysis & Design * Bob Travica
Associations between
aspects of reality

Association = relationship between aspects of
reality
 Example: Customer places Order

Associations apply in both directions
 Order is placed by Customer
3510 Systems Analysis & Design * Bob Travica
Associations between classes
• Associations between reality aspects translate into relationships
between classes.
CUSTOMER
places
ORDER
contains
PRODUCT A
is contained in
PRODUCT B
• The normal direction of reading is left-to-right and top-down.
If violated, an arrowhead shows the direction.
• Whenever possible, arrange symbols to support the normal
direction of reading
3510 Systems Analysis & Design * Bob Travica
Associations between
Master and Transaction Data

A rule of thumb in modeling class diagrams:
Master classes usually are not associated directly to each
other but through the transaction class.
Master Data
Customer
orders
places
Product
contains
Order
Transaction Data
3510 Systems Analysis & Design * Bob Travica
Details of a reality aspect and
class attributes



Specific details of an aspect become class attributes (pieces
of data)
Think of a database record (row)
Understanding attributes is part of system analysis
Class
elements


Class name

Class attributes

Class behaviors
(methods,
processes/functions
working with data)
Course
courseNumber
courseTitle
creditHours
addCourse()
Key attribute: uniquely identifies each instance of a class –
each Object (courseNumber; underlined)
3510 Systems Analysis & Design * Bob Travica
Attribute values
• By specifying values of attributes, class is instantiated
in objects.
Attributes
Values
• Classes define attributes (names & data types)
- “skeleton”; objects are “carved” out of classes.
3510 Systems Analysis & Design * Bob Travica
Multiplicity
• Multiplicity: the number of objects allowed on each side of
a relationship.
Looking from the Order side, the number of associated
objects is as follows:
Each order is placed
by just one Customer.
One order
can contain
several
Products
1
“CONTAINS”
*
(many, as soon as >1)
Note: Multiplicity still unknown on the Order side (two
numbers missing).
3510 Systems Analysis & Design * Bob Travica
Multiplicity
• Multiplicity, looking from the Customer and Product side,
the number of associated objects is as follows:
*
1
CONTAINED ON
PLACES
Places
one or
more
orders.
1
CONTAINED ON
Unique
Products
contained
on just one
Order.
3510 Systems Analysis & Design * Bob Travica
Multiplicity – key attribute design
Consumer electronics is usually keyed on serial number, so that each
instance of a product (item) is unique; thus it can appear just on one
order. For convenience, this key can be called “unique key”.
But a product category can also be keyed (e.g., cables, or
grocery products). This key could be called “generic key”.
In this case, the relationship Order-Item is many-to-many1 (below).
Graphical aid:
Note: In determining multiplicity, it suffices to write maximum number
of objects that can participate in a relationship (1..*; *..*; 1:1) 2.
3510 Systems Analysis & Design * Bob Travica
Associations between class
objects with multiplicity
• Typical relationship involving objects from
two classes.
Section
Course
CourseNumber
CourseTitle
CreditHours
SectionNumber
1 has * Term
StartTime
RoomNumber
openSection()
closeSection()
addCourse()
Reading:
A (one) course has
many sections,
and
each (one) section
belongs to one course.
3510 Systems Analysis & Design * Bob Travica
Associations between classes:
Generalization/Specialization
Class (Superclass)
is
is
Subclasses of
MotorVehicle
Subclasses
of Car
Multiplicity is usually not specified, but is assumed to be 1..1.
3510 Systems Analysis & Design * Bob Travica
Associations between classes:
Part-Whole
1 part of 1
Whole class
1 part of 1
1 part of 1
1 part of 1 (*)
1 part of 1
Part classes
This part-whole association is called composition, or bill-of-materials.
It shows parts that make a computer.
3510 Systems Analysis & Design * Bob Travica