Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 4: Mô hình hóa đối tượng - Đỗ Ngọc Như Loan

Mô hình hóa đối tượng
Nội dung trước

Mô hình hóa yêu cầu:
 Lược đồ Use-case
 Khái niệm Actor và Usecase
 Ví dụ

Mô hình hóa các dòng dữ liệu của mỗi Use-case
4 – Mô hình hóa đối tượng– Class Diagram 2
 Giới thiệu Mô hình DFD
 Sử dụng mô hình DFD để mô hình hóa yêu 
cầu lưu trữ, tra cứu, tính toán, kết xuất
Nội dung

Quản lý yêu cầu:
 Giới thiệu
 Chi tiết quản lý yêu cầu
 Các kỹ năng
4 – Mô hình hóa đối tượng– Class Diagram 3

Mô hình hoá đối tượng

Class & Class Diagram 
Giới thiệu

 Một trong những hoạt động đầu tiên

 Mục tiêu: tìm cái cần xây dựng

 Giao tiếp giữa người dùng và người phát triển, vì vậy
 Không có ký hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn)
 Thường dùng ngôn ngữ tự nhiên
 Hợp đồng
4 – Mô hình hóa đối tượng– Class Diagram

 Các cách thức để xác định yêu cầu

 Các cách thức để chuẩn hóa yêu cầu
 Scenarios, Use Cases, Mockups / Prototypes, Feature, Lists

 Stakeholders
 Những người quan tâm đến sản phẩm
4
Thế nào là quản trị yêu cầu

Là tiến trình tìm hiểu, sưu liệu và quản lý 
các yêu cầu.

 Sử dụng những kỹ thuật mang tính hệ
4 – Mô hình hóa đối tượng– Class Diagram
thống để đảm bảo yêu cầu:
 Complete (đầy đủ)
 Consistent (nhất quán)
 Relevant (thích đáng)
5
Thế nào là quản trị yêu cầu

Diễn tả bằng văn xuôi,
 Tìm hiểu cái người dùng muốn
 Tổ chức thông tin này lại
 Sưu liệu thông tin này
4 – Mô hình hóa đối tượng– Class Diagram
 Theo vết thay đổi thông tin này
 Quản lý tất cả thay đổi
 Đáp ứng nhu cầu người dùng cuối

Thiết lập quy trình và thực hiện theo nó
6
Thế nào là quản trị yêu cầu

Hầu hết các tổ chức phát triển phần mềm đều làm việc
này theo những cách thức khác nhau.

Nhưng thường chúng không mang tính hình thức và mang
tính không thống nhất từ dự án này qua dự án khác
4 – Mô hình hóa đối tượng– Class Diagram

CMM Level 1 vs. CMM Level 2
= Định nghĩa được tiến trình quản lý yêu câu
7
Thế nào là một yêu cầu

 Là một khả năng của phần mềm được
người dùng yêu cầu, để giải quyết một
vấn đề nhằm đạt một mục tiêu nào đó
4 – Mô hình hóa đối tượng– Class Diagram

Thành công của dự án = thoả mãn các
yêu cầu
8
Nguồn yêu cầu: Khách hàng

 Phỏng vấn khách hàng
 Người trả tiền cho chúng ta
 Những stakeholders
• Người sử dụng
• Người quản lý

 Vấn đề:
 Khách hàng có thể không biết họ muốn gì
4 – Mô hình hóa đối tượng– Class Diagram
• Phần mềm là một khái niệm trừu tượng và phức tạp
 KH có thể thay đổi ý kiến
 KH không có khả năng diễn tả nhu cầu theo những thuật ngữ
chuyên môn
• Giao tiếp giữa người chuyên làm p.mềm người bình thường

 Các kỹ thuật
 Giao diện & Hệ thống đã tồn tại
9
Nguồn yêu cầu: thị trường

 Đánh giá các sản phẩm cạnh tranh
 Những gì trước đây đã thực hiện?
 Nơi nào là nơi thích hợp cho chúng ta
 Lưu ý vấn đề bản quyền, thương hiệu sáng chế
Tự đánh giá khả năng của chúng ta
4 – Mô hình hóa đối tượng– Class Diagram


 Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh
 Những kiến thức, kỹ năng, ý tưởng mà chúng ta có
10
Nguồn yêu cầu: thị trường

Khảo sát thị trường
 Phỏng vấn khách hàng (cũ, tiềm năng, )
 Lưy ý tới những quảng cáo, tạo nhu cầu thị trường
 Quan tâm tới xu hướng phát triển của thị trường
4 – Mô hình hóa đối tượng– Class Diagram

Vấn đề
 Người ta không biết người ta muốn gì?
 Thị trường thay đổi rất nhanh
 Bảo mật ý tường ???
11
Nguồn các yêu cầu: các chuẩn

 Các chuẩn và các hệ thống chuyển đổi
 System standard, file formats, network protocols 
 Usability standards 
 Domain standards 

 Official standards
 written by a standards body 
4 – Mô hình hóa đối tượng– Class Diagram
• ANSI 
• ISO (e.g. Unicode) 
• IEEE (e.g. Posix) 

 Industry standards 
 Java, Dot-Net 
 Wimp user interface 
 WAMP, LAMP 
12
Các loại yêu cầu

 Chức năng
 Features
 User interface
 Input/Output

 Phi chức năng
4 – Mô hình hóa đối tượng– Class Diagram
 Hướng người dùng
• Performance, Precision, Reliability
 Hướng người phát triển
• Maintainability, Reusability, Interoperability
13
Những vấn đề quản trị yêu cầu

 Nhiều hệ thống thường
 Chuyền giao trễ và vượt ngân sách cho phép
 Không đáp ứng đầy đủ yêu cầu người dùng
 Không hoạt động hiệu quả

 Bước đầu tiên để giải quyết vấn đề
4 – Mô hình hóa đối tượng– Class Diagram
  xác định nguyên nhân cốt lõi

 Ví dụ về những nguyên nhân cốt lõi
 Thiếu dữ liệu người dùng
 Yêu cầu đặc tả không đầy đủ
 Yêu cầu và đặc tả thay đổi
14
Tăng chi phí do yêu cầu sai hoặc thiếu sót
0.1
0.5
1
Requirements
Design
Coding
4 – Mô hình hóa đối tượng– Class Diagram
2
5
20
15
Tỷ lệ chi phí để sửa chữa theo từng giai đoạn
Unit testing
Acceptance - testing
Maintenance
Thế nào là quản trị yêu cầu tốt

Ngăn:
 Vượt chi phí và thời gian
 Huỷ dự án

Một dự án thành công cần các yếu tố:
 Sự quan tâm của người dùng
4 – Mô hình hóa đối tượng– Class Diagram
 Hỗ trợ của người quản lý
 Yêu cầu rõ ràng
16
Chất lượng của yêu cầu: tính ổn định

Ổn định
 Không có mâu thuẫn
 Chương trình sẽ không thể hoạt động nếu yêu cầu 
mâu thuẫn

Khó đảm báo vì
4 – Mô hình hóa đối tượng– Class Diagram
 Số lượng yêu cầu lớn
 Mâu thuẫn tiềm ẩn

Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ 

Vấn đề
 Khó giải thích mâu thuẫn cho khách hàng
 Khách hàng muốn những thứ không thể
17
Chất lượng yêu cầu: có thể quản lý được

 Tài nguyên phải có thể đáp ứng các yêu cầu
 Có thể làm đúng thời gian
 Với chi phí cho phép
 Trong khả năng (kỹ năng) có thể?

 Quản lý rủi ro
 Xếp độ ưu tiên các yêu cầu
4 – Mô hình hóa đối tượng– Class Diagram
 Phải có thay thế nếu cái chính không hoạt động
 Mở ra những vấn đề không thể để nói đến những yêu cầu có 
thể làm

 Quản lý độ phức tạp
 Đừng làm mọi thứ cùng một lúc
 Qui trình lặp
 Prototyping
18
Chất lượng yêu cầu: sự đặc tả

 Càng chính xác và chi tiết càng tốt

 Không tốt
 “program shall be fast” 
 “it takes a number as input” 

 Tốt
 “program shall give a response in less than 1s” 
4 – Mô hình hóa đối tượng– Class Diagram
 “it takes a 16-bit signed integer as input” 

 Những định nghĩa
 Luôn là những ý tưởng tốt
 Vd: “by 'Number', we always mean a 16-bit signed 
integer” 

 Qui tắc định nghĩa
 Không định nghĩa xoay vòng (phụ thuộc)
19
Chất lượng yêu cầu không thiên về cài đặt

 Thiên về cài đặt:
 Đưa thông tin thiết kế
 Đưa thông tin về mã nguồn

 Sử dụng những thuật ngữ chuyên môn
 Không dùng từ ngữ chuyên môn kỹ thuật
 Bạn muốn tập trung vài CÁI GÌ
4 – Mô hình hóa đối tượng– Class Diagram
 Bỏ LÀM THẾ NÀO lại phần sau

 Ví dụ không tốt
 “store the checked-out books in an array”
 “calculate the square root with Newton's algorithm”

 Ví dụ tốt
 •“the library knows which books are checked out”
 “return the square root with 5-digit precision”
20
Đội ngũ phát triển phần mềm

Quản lý yêu cầu đụng đến từng cá nhân
trong đội ngũ phát triển

Nếu nhóm xác định yêu cầu làm việc tốt
4 – Mô hình hóa đối tượng– Class Diagram
 ảnh hưởng tốt đến kết quả của toàn
nhóm phát triển dự án
21
Những kỹ năng xác định yêu cầu
6 kỹ năng cần thiết

 Phân tích vấn đề

 Hiểu nhu cầu người dùng
4 – Mô hình hóa đối tượng– Class Diagram

 Định nghĩa được hệ thống

 Quản lý được phạm vi

 Tinh lọc được hệ thống

 Xây dựng đúng hệ thống cần thiết
22
Kỹ năng làm việc
Cũng cần phải có

Giao tiếp

Phân tích và suy nghĩ
4 – Mô hình hóa đối tượng– Class Diagram

Diễn giải

Lập báo cáo

Trình diễn
23
Chi phí cho việc xác định yêu cầu

Chi phí:
 Chiếm từ 15% đến 30% kinh phí toàn dự án

Khi bỏ ra càng nhiều thời gian cho công
đoạn xác định yêu cầu, chúng ta sẽ càng
4 – Mô hình hóa đối tượng– Class Diagram
tiết thời gian cho:
 Thiết kế
 Triển khai
 Kiểm chứng
24
Qui trình lấy yêu cầu
Requirememts
eliciation
Requirememts
Analysis & 
Negotiation
Requirememts
documentation
Requirememts
validation
4 – Mô hình hóa đối tượng– Class Diagram 25
Requirememts
document
System
specification
User needs 
domain 
information, 
existing system 
information, 
regulations, 
standards, etc.
Agreed
Requirements
Phân tích kiến trúc trong ngữ cảnh
4 – Mô hình hóa đối tượng– Class Diagram 26
Tổng quan về phân tích
4 – Mô hình hóa đối tượng– Class Diagram 27
Mô hình “4+1 View”
4 – Mô hình hóa đối tượng– Class Diagram 28
UML trong mô hình 4+1 view

 Use case View: đây là hướng nhìn chỉ ra khía cạnh chức 
năng của một hệ thống, nhìn từ hướng tác nhân bên 
ngoài.
Use case Diagrams

 Logical View: chỉ ra chức năng sẽ được thiết kế bên 
4 – Mô hình hóa đối tượng– Class Diagram
trong hệ thống như thế nào
Class Diagrams
Object Diagrams
Package Diagrams
Composite Structure Diagrams
State Machine Diagrams
29
UML trong mô hình 4+1 view

 Process View: chỉ ra sự tồn tại song song/ trùng hợp trong 
hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong 
hệ thống.
Sequence Diagrams
Communication Diagrams
Activity Diagrams
4 – Mô hình hóa đối tượng– Class Diagram
Timing Diagrams
Interaction Overview Diagrams
30

 Implementation View/ Development View: chỉ ra
khía cạnh tổ chức của các thành phần code.
Component Diagrams

 Deployment View/ Physical View: chỉ ra khía cạnh 
triển khai hệ thống vào các kiến trúc vật lý (các máy tính 
UML trong mô hình 4+1 view
4 – Mô hình hóa đối tượng– Class Diagram
hay trang thiết bị được coi là trạm công tác).
Deployment Diagrams
31
Class Diagram 

Class Diagram là sơ đồ mô tả các lớp, các giao 
diện (interface) và các mối liên hệ giữa chúng, cho 
ta một khung nhìn tĩnh của các lớp trong mô hình.
4 – Mô hình hóa đối tượng– Class Diagram 32
Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 33
Object & Class

 Class (Lớp)
 Là 1 nhóm Object chung thuộc tính và hành vi
 Chung mối quan hệ và chung ngữ nghĩa
 Là khuôn mẫu để tạo ra đối tượng

 Object (Đối tượng): là thể hiện thực tế của 1 
4 – Mô hình hóa đối tượng– Class Diagram
lớp
Ví dụ: Lớp Sinh viên có thể tạo ra 2 đối tượng là
sinh viên A và sinh viên B.
34
Analysis Class

 Bước đầu cho một hệ thống có khả năng 
thực thi
4 – Mô hình hóa đối tượng– Class Diagram 35
Tìm các class từ Use Case Behavior

 Toàn bộ hành vi của Use Case phải được
phân bổ về cho các analysis class 
4 – Mô hình hóa đối tượng– Class Diagram 36
Các Stereotyle của lớp
Trong biểu đồ lớp, stereotype là cơ chế để phân lớp. Có
3 loại lớp phân tích: 
4 – Mô hình hóa đối tượng– Class Diagram 37
Boundary Class

Là lớp trung gian thể hiện sự tương tác giữa hệ
thống và những gì bên ngoài hệ thống

Các lớp biên:
 Lớp giao diện giữa người dùng và hệ thống
 Lớp giữa hệ thống và các hệ thống bên ngoài
4 – Mô hình hóa đối tượng– Class Diagram 38
• Ví dụ giao dịch với “Hệ thống tài vụ”
 Lớp giữa hệ thống và thiết bị ngoại vi
• Ví dụ “Thiết bị giải mã vạch”

Với mỗi cặp Actor/Use-Case bao giờ cũng có 1 
lớp biên
Boundary Class
4 – Mô hình hóa đối tượng– Class Diagram 39
Mô hình hoá sự tương tác giữa hệ thống và môi trường
bao quanh nó
Entity Class

Là các lớp mô tả những thực thể chính xuất hiện 
trong hệ thống

Thực thể là những thông tin tồn tại và được lưu 
trữ lâu dài trong hệ thống

Chỉ mô tả ở mức trừu tượng, không mô tả quá 
4 – Mô hình hóa đối tượng– Class Diagram 40
chi tiết các thuộc tính của thực thể này
Entity Class
4 – Mô hình hóa đối tượng– Class Diagram 41
Lưu trữ và quản lý các thông tin trong System
Tìm kiếm Entity Class

 Nguồn thông tin có thể tìm Entity Class:
 Các Use case
 Các yêu cầu
 Nghiên cứu hệ thống tương tự đã có
 Sự trợ giúp của các chuyên gia ứng dụng
4 – Mô hình hóa đối tượng– Class Diagram 42
Tìm kiếm Entity Class

Sử dụng luồng sự kiện của Use-Case là đầu vào. 
Lọc các danh từ:
 Tìm các mệnh đề danh từ trong luồng sự kiện
 Loại bỏ các từ mô tả cụ thể một thuộc tính thông tin 
nào đó, nhưng lưu lại để sau này có thể sử dụng cho:
• Thuộc tính
4 – Mô hình hóa đối tượng– Class Diagram 43
• Thao tác

 Ngoài ra, cần nghiên cứu:
 Các danh từ trong yêu cầu
 Kiến thức chuyên ngành thuộc phạm vi bài toán
 Xem xét các hệ thống tương tự
Loại bỏ các Entity Class không thích hợp

Lớp dư thừa: định nghĩa cùng 1 thực thể

Lớp không thích hợp: không liên quan đến vấn đề hiện
tại

Lớp không rõ ràng: không có chức năng cụ thể

Các lớp chỉ vai trò (Roles) đối với 1 lớp khác cũng được
4 – Mô hình hóa đối tượng– Class Diagram
lọc để giữ lại lớp chính
44
Ví dụ
Xem xét, với ví dụ ATM chúng ta có thể thấy các đối tượng là Entity 
Class như sau:

 Customers: khách hàng giao dịch là một thực thể có thật và quản 
lý trong hệ thống.

 Accounts: Tài khoản của khách hàng cũng là một đối tượng thực 
tế.

 ATM Cards: Thẻ dùng để truy cập ATM cũng được quản lý trong 
hệ thống.
4 – Mô hình hóa đối tượng– Class Diagram

 ATM Transactions: Các giao dịch được lưu giữ lại, nó cũng là một 
đối tượng có thật.

 Banks: Thông tin ngân hàng bạn đang giao dịch, nếu có nhiều nhà 
Bank tham gia vào hệ thống bạn phải quản lý nó. Lúc đó Bank trở 
thành đối tượng bạn phải quản lý.

 ATM: Thông tin ATM bạn sẽ giao dịch. Nó cũng được quản lý tương 
tự như Banks.
45
Ví dụ
Ví dụ: Đặc tả uscase đăng ký môn học
1. Sinh viên: Đưa vào mật khẩu và tên đăng 
nhập
2. Hệ thống xác nhận mật khẩu và tên đăng 
nhập
4 – Mô hình hóa đối tượng– Class Diagram
3. Sinh viên chọn học kỳ và năm học
4. Hệ thống hiển thị các môn học có thể có 
trong học kỳ
Xác định các class trong trường hợp này?
46
Lưu ý

Cần phân biệt giữa khái niệm và thuộc
tính.

Ví dụ: Cần xây dựng phần mềm quản lý
các chuyến bay. Đích đến của chuyến bay 
là thuộc tính của chuyến bay hay một lớp
4 – Mô hình hóa đối tượng– Class Diagram
khác?
47
Control Class

Được sử dụng để thực hiện một hoặc nhiều
hành động nào đó trong hệ thống
Là lớp thực hiện chức năng chính trong các UC
Với những Use Case phức tạp, có thể có nhiều hơn
một lớp điều khiển
4 – Mô hình hóa đối tượng– Class Diagram 48
Control Class
4 – Mô hình hóa đối tượng– Class Diagram 49
Thể hiện hành động, chức năng của từng Use Case
Tóm tắt các Stereotyle của class
4 – Mô hình hóa đối tượng– Class Diagram 50
Trách nhiệm của các lớp phân tích

Lớp biên (Boundary Class)
 Chịu trách nhiệm thể hiện sự tương tác giữa hệ thống
và tác nhân bên ngoài
 Chịu trách nhiệm kiểm tra dữ liệu qua lại trong quá trình
tương tác

Lớp thực thể (Entity Class)
4 – Mô hình hóa đối tượng– Class Diagram 51
 Chịu trách nhiệm quản lý thông tin của nó
 Đóng gói thông tin, và thay đổi trạng thái của nó

Lớp điều khiển (Control Class)
 Chịu trách nhiệm chính cho một Use Case nào đó
 Tránh để lớp điều khiển làm quá ít việc
Class trong Class Diagram

 Class là thành phần chính của bản vẽ Class Diagram. Class 
mô tả về một nhóm đối tượng có cùng tính chất, hành động 
trong hệ thống. Class Name
Attributes
Operations
4 – Mô hình hóa đối tượng– Class Diagram

 Class Name: là tên của lớp.

 Attributes (thuộc tính): mô tả tính chất của các đối tượng. Ví 
dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa 
chỉ, Ngày sinh v.v

 Operations (thao tác/phương thức): chỉ các hành động mà đối 
tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành 
vi của các đối tượng do lớp này tạo ra.
52
Biểu diễn thuộc tính

 Chỉ ra tên, kiểu và giá trị mặc định nếu có
AttributeName : Type = Default

 Tuân theo quy ước đặt tên của ngôn ngữ cài đặt và của
dự án.
Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ
4 – Mô hình hóa đối tượng– Class Diagram


thực thi

 Kiểu dữ liệu có sẵn, kiểu dữ liệu người dùng định nghĩa, 
hoặc lớp tự định nghĩa.
Ví dụ: CustomerID: int
53
Mô tả phương thức

 Tên phương thức:
 Mô tả kết quả
 Sử dụng góc nhìn của đối tượng khách (client – đối 
tượng gọi)
 Nhất quán giữa các lớp
4 – Mô hình hóa đối tượng– Class Diagram
OperationName(parameter:type,...):returnType
Ví dụ: GetCustomerName(CustomerID:int): string
54
Gói (Package)

Một cơ chế chung để tổ chức các phần tử thành nhóm.

Một phần tử trong mô hình có thể chứa các phần tử
khác.

Vd: Registration Package
4 – Mô hình hóa đối tượng– Class Diagram 55
Phạm vi truy cập (Visibility)

 Phạm vi truy cập được sử dụng để thực hiện khả 
năng đóng gói
 Public : + Public access
 Private: - Private access
4 – Mô hình hóa đối tượng– Class Diagram
 Protected: # Protected access
 Package: ~ Package access
56
Phạm vi (Scope)

 Xác định số lượng thể hiện của thuộc tính/thao tác:
– Instance: Một thể hiện cho mỗi thể hiện của mỗi lớp
– Classifier: Một thể hiện chung cho tất cả các thể hiện của
lớp (static)

 Phạm vi Classifier được ký hiệu bằng cách gạch dưới tên 
4 – Mô hình hóa đối tượng– Class Diagram
thuộc tính/thao tác.
57
4 – Mô hình hóa đối tượng– Class Diagram 58
Class Diagram -Khung tĩnh cho hệ thống

Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 59
Relationships (Mối quan hệ giữa các lớp)

 Association (Kết hợp) – Bản số và chiều
 Aggregation (Thu nạp): toàn thể và bộ phận
 Composition (Cấu thành) 

 Dependency (Phụ thuộc)
Generalization (Tổng quát hóa) Đơn/Đa kế thừa
4 – Mô hình hóa đối tượng– Class Diagram



 Realization (Hiện thực hoá)
60
Association

Mối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự
liên kết giữa các thể hiện của chúng

Mối quan hệ về mặt cấu trúc chỉ ra các đối tượng của
lớp này có kết nối với các đối tượng của lớp khác.
4 – Mô hình hóa đối tượng– Class Diagram 61
Bội số quan hệ (Multiplicity)

 Bội số quan hệ là số lượng thể hiện của một lớp liên 
quan tới MỘT thể hiện của lớp khác.

 Với mỗi liên kết, có hai bội số quan hệ cho hai đầu của 
liên kết.
– Với mỗi đối tượng của Professor, có nhiều Course
4 – Mô hình hóa đối tượng– Class Diagram
Offerings có thể được dạy.
– Với mỗi đối tượng của Course Offering, có thể có 1 hoặc 
0 Professor giảng dạy.
62
Biểu diễn bội số quan hệ
4 – Mô hình hóa đối tượng– Class Diagram 63
Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 64
Aggregation

 Là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ
toàn thể-bộ phận (whole-part) giữa đối tượng toàn thể và các 
bộ phận của nó.
– Thu nạp là mối quan hệ “là một phần” (“is a part-of”).
Bội số quan hệ được biểu diễn giống như các liên kết khác
4 – Mô hình hóa đối tượng– Class Diagram


65
Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 66
Association hay Aggregation
4 – Mô hình hóa đối tượng– Class Diagram 67
Cấu thành (Composition)

 Một dạng của kết tập với quyền sở hữu mạnh và các
vòng đời trùng khớp giữa hai lớp
– Whole sở hữu Part, tạo và hủy Part.
– Part bị bỏ đi khi Whole bị bỏ, Part không thể tồn tại
4 – Mô hình hóa đối tượng– Class Diagram
nếu Whole không tồn tại.
68
Association, Aggregation and Composition

 Mối quan hệ giữa các lớp
(relationship)
 Liên kết (Association)
• Sử dụng (use-a)
 Thu nạp (Aggregation)
4 – Mô hình hóa đối tượng– Class Diagram
• Strong association
• has-a/is-a-part
 Hợp thành (Composition)
• Strong aggregation
• Share life-time
69
Tổng quát hóa (Generalization)

Mối quan hệ giữa các lớp trong đó một lớp chia sẻ
cấu trúc và/hoặc hành vi với một hoặc nhiều lớp
khác

Xác định sự phân cấp về mức độ trừu tượng hóa
trong đó lớp con kế thừa từ một hoặc nhiều lớp
4 – Mô hình hóa đối tượng– Class Diagram
cha
– Đơn kế thừa (Single inheritance)
– Đa kế thừa (Multiple inheritance)

 Là mối liên hệ “là một loại” (“is a kind of”)
70
Abstract and Concrete Class

Lớp trừu tượng không thể có đối tượng
 Chứa phương thức trừu tượng
 Chữ nghiêng

Lớp cụ thể có thể có đối tượng
4 – Mô hình hóa đối tượng– Class Diagram 71
Đơn kế thừa

 Một lớp kế thừa từ MỘT lớp khác
4 – Mô hình hóa đối tượng– Class Diagram 72
Đa kế thừa

Một lớp có thể kế thừa từ nhiều lớp khác

Sử dụng đa kế thừa khi cần thiết và cẩn thận khi
sử dụng vì có thể dẫn đến nhiều rắc rối, phức
tạp.
4 – Mô hình hóa đối tượng– Class Diagram 73
Đa kế thừa

 Phụ thuộc vào ngôn ngữ lập trình
Xung đột về tên trên
các thuộc tính hoặc phương thức
Kế thừa lặp lại
4 – Mô hình hóa đối tượng– Class Diagram 74
Đa hình (Polymorphism)

Khả năng che giấu các thực thi khác nhau dưới
một giao diện duy nhất.
4 – Mô hình hóa đối tượng– Class Diagram 75
Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 76
Ví dụ
4 – Mô hình hóa đối tượng– Class Diagram 77
Xây dựng Class Diagram cần chú ý

 Quản lý sự toàn vẹn (xét theo trình tự)
 Dư thừa trách nhiệm giữa các lớp
 Các trách nhiệm bị tách rời giữa các lớp
 Lóp chỉ có 1 trách nhiệm
 Lớp không có trách nhiệm
 Sự phân tán các hành vi
4 – Mô hình hóa đối tượng– Class Diagram
 Lớp có quá nhiều tương tác với các lớp khác
78
Checkpoints: Analysis Classes

Các class có hợp lý không?

Tên của các class có phản ánh đúng vai trò của
chúng?

Class có biểu diễn 1 single well-defined 
abstraction? 
4 – Mô hình hóa đối tượng– Class Diagram

Tất cả các attribute và responsibility có gắn kết
với nhau về mặt chức năng không?

Class có cung cấp các hành vi được yêu cầu?

Tất cả các yêu cầu cụ thể đã được thể hiện trên
class chưa?
79
Tham khảo

Tham khảo: GeekCorps 2004

 IBM - RUP

 Introduction to Rational Rose 98i
4 – Mô hình hóa đối tượng– Class Diagram

 Bài giảng: Công cụ và môi trường phát triển
phần mềm – ĐHKHTN

 Bài giảng: OOLT, Ms.Trang, Vietnam & 
Japan Joint ICT HRD Program.
80
Thực hành
81
Thực hành 

 Làm việc với công cụ Rational Rose

 Làm bài tập theo mẫu
 5 – Business.Vision.pdf
4 – Mô hình hóa đối tượng– Class Diagram
 6 - Business.Glossary.pdf

 Xác định Class

 Thực hành vẽ Class Diagram
82
Lập biểu đồ lớp

 Giúp người phát triển 
quan sát, lập kế hoạch 
cấu trúc hệ thống trước 
khi viết code
4 – Mô hình hóa đối tượng– Class Diagram

 Trong Rose
 Hình thành trong 
Logical View
83