Trường Đại học Công nghiệp Thành phố Hồ Chí Minh

Class Diagram

Giảng viên: Tiến sĩ Bùi Thanh Hùng

Bộ môn Khoa học dữ liệu
Khoa Công nghệ thông tin
Đại học Công nghiệp TP HCM
Email: buithanhhung@iuh.edu.vn
Website: https://sites.google.com/site/hungthanhbui1980/
 Unified Modeling Language, Version 2.0

• 2 types of diagrams
– Structure Diagrams
• Provide a way for representing the data and
static relationships that are in an information
system
• Class diagram
– Behavior Diagrams
 Structure Diagrams

• Class Diagram
– Describe the structure of the system in terms
of classes and objects
– Primary purpose during analysis workflow:
to create a vocabulary that is used by both
the analyst and users
 What is a Class?

• A general template that we use to create

specific instances or objects in the
application domain
• Represents a kind of person, place, or
thing about which the system will need to
capture and store information
• Abstractions that specify the attributes
and behaviors of a set of objects
 What is an Object?

• Entities that encapsulate state and

behavior
• Each object has an identity
– It can be referred individually
– It is distinguishable from other objects
 Types of Classes

• Ones found during analysis:

– people, places, events, and things about
which the system will capture information
– ones found in application domain
• Ones found during design
– specific objects like windows and forms that
are used to build the system
 2 Kinds of Classes during Analysis

• Concrete
– Class from application domain
– Example: Customer class and Employee
class
• Abstract
– Useful abstractions
– Example: Person class
 Attributes in a Class

• Properties of the class about which we

want to capture information
• Represents a piece of information that is
relevant to the description of the class
within the application domain
 Attributes in a Class

• Only add attributes that are primitive or

atomic types
• Derived attribute
– attributes that are calculated or derived from
other attributes
– denoted by placing slash (/) before name
 Operations in a Class

• Represents the actions or functions that a

class can perform
• Describes the actions to which the
instances of the class will be capable of
responding
• Can be classified as a constructor, query,
or update operation
UML Representation of Class

Class Name

Attributes of Class

Operations/methods
of Class
 Example of a Class Diagram

Video Rental System

visibility multiplicity class name

Customer 1..* 1..*

Video
-CID: int -cassetteID : int
rents
-name: String -cassetteVolumeNo: int
+rentMovie()
+authenticateCustomer ()

attributes relationship methods

 Visibility of Attributes and Operations

• Relates to the level of information hiding

to be enforced
 Visibility of Attributes and Operations

Visibility Symbol Accessible To

Public + All objects within your system.

Protected # Instances of the implementing class and its

subclasses.

Private - Instances of the implementing class.

 Relationships among Classes

• Represents a connection between

multiple classes or a class and itself
• 3 basic categories:
– association relationships
– generalization relationships
– aggregation relationships
 Association Relationship

• A bidirectional semantic connection

between classes
• Type:
– name of relationship
– role that classes play in the relationship
 Association Relationship

• Name of relationship type shown by:

– drawing line between classes
– labeling with the name of the relationship
– indicating with a small solid triangle beside
the name of the relationship the direction of
the association

Provides
Patient Medical History
 Association Relationship

• Role type shown by:

– drawing line between classes
– indicating with a plus sign before the role
name
Patient

+ primary insurance
carrier
 Generalization Relationship

• Enables the analyst to create classes that

inherit attributes and operations of other
classes
• Represented by a-kind-of relationship
 Generalization Relationship

Person

Employee Customer

Manager Engineer
Generalization Relationship
Employee
hireDate

receivePay
performWork

Manager Engineer
department certifications
bonus
hireEmployee analyze
promoteEmployee design
 Generalization Relationship
Person

Employee Contractor

Preferred Secondary
Manager Engineer
Contractor Contractor
 Aggregation Relationship

• Specialized form of association in which

a whole is related to its part(s)
• Represented by a-part-of relationship
 Aggregation Relationship

• Denoted by placing a diamond nearest the

class representing the aggregation

1 provides 0..1
Patient Medical History
 Multiplicity

• Documents how many instances of a

class can be associated with one instance
of another class

1 provides 0..1
Patient Medical History
 Multiplicity

• Denotes the minimum number..

maximum number of instances
Exactly one 1
Zero or more 0..* or 0..m
One or more 1..* or 1..m
Zero or one 0..1
Specified range 2..4
Multiple, disjoint ranges 1..3, 5
 Class Diagram

• 2 approaches to deriving class diagrams:

– from use cases and their scenarios
– from CRC cards
 Deriving Class Diagram from
Use Cases and Scenarios

• Analyze the text in the use-case

descriptions and scenarios
 Guidelines
for Analyzing Use Cases

• A common or improper noun implies a

class of objects
• A proper noun implies an instance of a
class
• A collective noun implies a class of
objects made up of groups of instances of
another class
 Guidelines
for Analyzing Use Cases (2)

• An adjective implies an attribute of an

object
• A doing verb implies an operation
• A being verb implies a relationship
between an object and its class
• A having verb implies an aggregation or
association relationship
 Guidelines
for Analyzing Use Cases (3)

• A transitive verb implies an operation

• An intransitive verb implies an exception
• A predicate or descriptive verb phrase
implies an operation
• An adverb implies an attribute of a
relationship or an operation
 Class Diagram

• Ensure that the classes are both necessary

and sufficient to solve the underlying
problem
– no missing attributes or methods in each
class
– no extra or unused attributes or methods in
each class
– no missing or extra classes
Discarding Unnecessary and Incorrect Classes

• Redundant Classes
• Irrelevant Classes
• Vague Classes
• Attributes
• Operations
• Roles
• Implementation Constructs
 Types of Classes

• Ones found during analysis:

– people, places, events, and things about
which the system will capture information
– ones found in application domain
• Ones found during design
– specific objects like windows and forms that
are used to build the system
 Practice 1- University

In a university there are different classrooms, offices

and departments. A department has a name and it
contains many offices. A person working at the
university has a unique ID and can be a professor or
an employee.
- A professor can be a full, associate or assistant
professor and he/she is enrolled in one department.
- Offices and classrooms have a number ID, and a
classroom has a number of seats.
- Every employee works in an office.
 Practice 2 -Movie-Shop

Design a system for a movie-shop, in order to handle

ordering of movies and browsing of the catalogue of
the store, and user subscriptions with rechargeable
cards.
- Only subscribers are allowed hiring movies with
their own card.
- Credit is updated on the card during rent operations.
- Both users and subscribers can buy a movie and
their data are saved in the related order.
- When a movie is not available it is ordered.
 Practice 3 - Bank system

A bank system contains data on customers (identified

by name and address) and their accounts.
Each account has a balance and there are 2 type of
accounts: one for savings which offers an interest rate,
the other for investments, used to buy stocks.
Stocks are bought at a certain quantity for a certain
price (ticker) and the bank applies commission on
stock orders.
Practice 1- University
Practice 2 -Movie-Shop
Practice 3 - Bank system