CONCEPTUAL DESIGN:

UML CLASS DIAGRAM

RELATIONSHIPS

1
 A Simplified Object-Oriented
Systems Analysis & Conceptual Design Methodology
Activities

1. Identify the information system’s purpose

2. Identify the information system’s actors and features

3. Identify Use Cases and create a Use Case Diagram

4. Identify Objects and their Classes and create a Class Diagram

5. Create Interaction/Scenario Diagrams

6. Create Detail Logic for Operations

7. Repeat activities 1-6 as required to refine the “blueprints”

2
 Objects

• Objects have three responsibilities:

 What they know about themselves – (e.g., Attributes)
 What they do – (e.g., Operations)
What they know about other objects – (e.g., Relationships)

3
 Defining Class
A CLASS is a template (specification, blueprint)
for a collection of objects that share a common
set of attributes and operations.

HealthClubMember
Class attributes
operations

Objects

4
 UML Class Diagram Notation 1 of 2

Class

Member

{
memberNumber
firstName Expanded view of a
lastName Class into its three
attributes telephone
address sections:
city
Top: Class Name
etc...
Middle: attributes

{
checkOutVideo
operations checkInVideo Bottom: operations
buyItem
etc...

5
UML Class Diagram Notation

6
Analysis Classes

 A technique for finding analysis classes

which uses three different perspectives
of the system:
– The boundary between the system and its
actors
– The information the system uses
– The control logic of the system

7
Boundary Classes

 coordinating the actor's behavior with

the "internals" of the system;
 receiving input from the actor to the
system, e.g., information or requests;
 providing output from the system to the
actor, e.g., stored information or derived
results.

8
Boundary Classes
 Boundary classes are used to model the interaction
between a system and its surroundings, i.e., its
actors.
• User interface classes
– Concentrate on what information is presented to the user
– Don’t concentrate on user interface details
– Example:
• ReportDetailsForm
• ConfirmationDialog
• System / Device interface classes
– Concentrate on what protocols must be defined. Don’t
concentrate on how the protocols are implemented

9
Entity Classes

 Models the key concepts of the system

 Usually models information that is
persistent
 Contains the logic that solves the
system problem
 Can be used in multiple behaviors
 Example: Violation, Report, Offender.

10
Control Classes
 Controls and coordinates the behavior
of the system
 Delegates the work to other classes
• A control class should tell other classes to
do something and should never do
anything except for directing
 Control classes decouple boundary and
entity classes
 Example:
• EditReportController
• AddViolationController

11
Class Diagram Relationships

 Class

• Generalization

 Object

• Association

• Aggregation

• Composition

12
 2 of 2

Class
Generalization
Relationship

Object Object
Aggregation Composition
Object Association Association Association

n n 1..* 1

0..* 0..*

Will always be “1”

13
Generalization (Class-to-Class) (superclass – subclass; supertype – subtype)
 A Generalization follows a “is a” or “is a kind of” heuristic from a specialization class
to the generalization class. (e.g., student “is a” person, video “is a kind of” inventory).
 Common attributes, operations and relationships are located in the generalization
class and are inherited by the specialization classes
 Unique attributes, operations and relationships are located in the specialization
classes.
 Inherited attributes and operations may be overridden or enhanced in the
specialization class depending on programming language support.
 Inherited operations in the specialization classes may be polymorphic.
 Only use when objects do NOT “transmute” (add, copy, delete)
 Multiple inheritance is allowed in the UML but can complicate the class model’s
understanding and implementation (e.g., C++ supports but Java and Smalltalk do
not).

14
 Generalization Example
Others:
<<abstract>> •Transactions
Role •Things
attributes • Places
operations • Etc...

Faculty Student Staff Visitor

attributes attributes attributes attributes

operations operations operations operations

Note: <<abstract>> = no objects

15
 Poor Generalization Example
(violates the “is a” or “is a kind of” heuristic)

Person
attributes
operations

Arm Leg Head

attributes attributes attributes

operations operations operations

16
 Generalization Inheritance Generalization

a1
a2
Generalization
a3
a1 o1
a2 o2
One-Way
Common a3 o3
o1 Inheritance
o2 from the
o3 Specialization
Generalization
a1
to the
a2
Specialization a3
Specialization a4
a4 a5
a5 a6
a6 o1
Unique o4 o2
o5 o3
o6 o4
o5
(a = attribute; o = operation) o6
17
Generalization - Multiple Inheritance
Generalization1 Generalization2
a1 a2
a2 a4
a3 a5
o3 o1
o4 o2
o5 o3

Specialization
a6
a7 a1
a8 a2 (which one?)
inherited attributes a3
o6 a4
o1 o7 a5
o2 o8
(which one?) o3 inherited operations
o4
o5
18
 UML Generalization Notation
Note

Useful text
Supertype

discriminator

Subtype 1 Subtype 2

Note: Supertype = Superclass; Subtype = Subclass

19
20
Generalization - Multiple Classification

Discriminator
Doctor

Female
role
<<abstract>>
Nurse
Person
Gender
Male {complete} patient
Physical-
#1 therapist
Patient
#3
#2 21
Example

22
Rational Rose Class Diagram Example
23
Associations
 Relationships between instances (objects) of
classes
 Conceptual:
• associations can have two roles (bi-directional):
– source --> target
– target --> source
• roles have multiplicity (e.g., cardinality, constraints)
• To restrict navigation to one direction only, an
arrowhead is used to indicate the navigation direction
 No inheritance as in generalizations

24
 Object Association Relationship Patterns
b) Object Whole
attributes
Aggregation operations
Associations
Class A x x
attributes x
operations
x x x x

Part1 Part2 PartN

x attributes
attributes attributes
Class B operations operations operations
attributes
operations

c) Object Whole
attributes
Composition operations
Class A x Class B
attributes attributes
Associations
x (y may not be “1”) 1 1
operations operations 1

y y y
a) Object Associations
Part1 Part2 PartN
attributes attributes attributes
operations operations operations

25
Associations

role B
Class A Class B
role A

Example:

Employee
Company Person
Employer

26
Multiplicities
1
Class exactly one

0..* many
Class (zero or more)
0..1 optional
Class
(zero or one)
m..n numerically
Class specified
Example:

0..*
Course CourseOffering
1
27
Examples

28
Aggregation & Composition
• Aggregation (shared aggregation):
• is a specialized form of ASSOCIATION in which
a whole is related to its part(s).
• is known as a “part of” or containment
relationship and follows the “has a” heuristic
• three ways to think about aggregations:
• whole-parts
• container-contents
• group-members
• Composition (composite aggregation):
• is a stronger version of AGGREGATION
• the “part(s)” may belong to only ONE whole
• the part(s) are usually expected to “live” and
“die” with the whole (“cascading delete”)
• Aggregation vs. Composition vs. Association???
29
 Aggregation Composition

Faculty SalesOrder

(team-teaching 1..* 1
is possible)

0..* 1..*
CourseTeaching SalesOrderLineItem

(another: assembly --> part) (another: hand --> finger)

30
Composition
 Composition is often used in place of Generalization
(inheritance) to avoid “transmuting” (adding, copying,
and deleting of objects)

Person
{abstract} 1
Person FacultyRole
0..1
1
Faculty Student 0..1

StudentRole

FacultyStudent

Note: Attributes may need to be considered to more-fully understand

31
Example

32
Association, Aggregation and Composition

Template/Pattern Example

w
Whole 1 w
Whole 2 w
w
3
4

0..*

p
p 6
0..* p 5
p 4
p
Part p 3
Part 2
1

(association, aggregation &

composition look the same)

33
 Multiplicity Example #1
Whole

3
1
5 2
Part1 PartN

•One Whole is associated with 5 Part1 •One Whole is associated with 2 PartN
•One Part1 is associated with 1 Whole •One PartN is associated with 3 Whole

P
P W
P
W P P P W
P W
P
W W
P

34
 Multiplicity Example #2
Class1

max. 1 2..5
min.
1..n
0..*
Class2 Class3

1..n * C3 2..5 C1
C2 1 C1
C3
C1
C2 C3 C1
C2 C1 C3
C1 C2 C1
C2 C3
C1
C2 C3

etc... etc...
35
 Multiplicity Example #3

FacultyInformation StudentInformation

1 0..* 1 1 1

1..* 0..*
0..*
DegreeHeld CommitteeAssign
CourseCompleted

0..* 0..*
CourseTeach ClubMember

36
Reflexive Association Relationships
Objects within the same class have a
relationship with each other.

Course
0..*

is pre-requisite for

0..*
has pre-requisite of

37
Case study—Courseware Management System
Problem Statement

 Courses and Topics that make up a course

 Tutors who teach courses
 Course administrators who mange the
assignment of the courses to tutors
 Calendar or Course Schedule is generated as
a result of the
 Students who refer to the Course schedule or
Calendar to decide which courses for which
they wish to sign up

38
The potential actors of the system

 Tutors
 Course administrators
 Students

39
use cases of the system were:

 View courses
 Manage topics for a course
 Manage course information
 View course calendar
 View tutors
 Manage tutor information
 Assign courses to tutors

40
First Identify the "active" entities in the system

• Course administrators
• Tutors
• Students

41
Identify business domain ("passive") entities in the
system

• Courses
• Topics that make up a course
• Course calendar generated

42
Identify

 Boundary class

 - Course Administrator

43
Next

 Identify Attributes and methods for the

class.
 Refine

44
Then

 Identify relationship between the

classes.

45
Class Diagram

46
UML Class Diagram

47
 Video Store – UML Class Diagram
1 1
Inventory

SaleItem RentalItem

Video Game ConcessionItem VCR

0..* 0..*
Transaction Employee StoreLocation
1 1

SaleTransaction RentalTransaction Suplier

1 0..* 0..* 1 1
0..1 1 0..*
Member PurchaseOrder
1..* 1..* 1
SaleRentalLineItem 1..*
0..* 0..*
PurchaseOrderLineItem
48
49
50
51
QUITTING TIME

52