Bài giảng Phân tích và thiết kế hệ thống - Chương 4: Phân tích và thiết kế hướng đối tượng

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM
KHOA CÔNG NGHỆ THÔNG TIN
Chương IV
Trần Thị Kim Chi 1
NỘI DUNG
1. Tổng quan về phân tích và thiết kế
2. Mục đích của phân tích
3. Qui trình phân tích yêu cầu
4. Các bước phân tích theo hướng đối tượng
5. Mục đích của thiết kế
6. Qui trình thiết kế
7. Phương pháp phân tích và thiết kế hướng đối tượng
8. Phân tích Use case
9. Đặc tả Use Case
10. Phân tích Use case nghiệp vụ
Trần Thị Kim Chi 2
MỤC ĐÍCH CỦA PHÂN TÍCH VÀ THIẾT KẾ
The purposes of Analysis and Design 
are to:
 Transform the requirements into a 
design of the system-to-be. 
 Evolve a robust architecture for the 
system. 
 Adapt the design to match the 
implementation environment, 
designing it for performance.
Trần Thị Kim Chi 3
TỔNG QUAN VỀ PHÂN TÍCH VÀ THIẾT KẾ
Supplementary
Specification
Use-Case Model
Data Model
Architecture
Document
Analysis and 
Design
Glossary
Design Model
Trần Thị Kim Chi 4
ANALYSIS VERSUS DESIGN
Analysis Design
 Focus on understanding 
the problem
 Idealized design
 Behavior
 System structure
 Functional requirements
 A small model
 Focus on understanding 
the solution 
 Operations and attributes
 Performance
 Close to real code 
 Object lifecycles
 Nonfunctional 
requirements
 A large model
Trần Thị Kim Chi 5
Analysis and Design Are Not Top-Down or Bottom-Up
Design Classes
Subsystems
Use Cases
Bottom
Up
Top
Down
(Define a 
middle level)
Analysis and Design
Analysis Classes
Trần Thị Kim Chi 6
• Mục đích của hoạt động phân tích yêu cầu là xây dựng mô
hình phân tích với các đặc điểm sau :
 dùng ngôn ngữ của nhà phát triển để miêu tả mô hình.
 thể hiện góc nhìn từ bên trong của hệ thống.
 được cấu trúc từ các class phân tích và các package phân
tích.
 được dùng chủ yếu bởi nhà phát triển để hiểu cách thức
tạo hình dạng hệ thống.
 loại trừ mọi chi tiết dư thừa, không nhất quán.
 phát họa các hiện thực cho các chức năng bên trong hệ
thống.
 định nghĩa các dẫn xuất use-case, mỗi dẫn xuất use-case
cấp phân tích miêu tả sự phân tích 1 use-case.
Mục đích của phân tích yêu cầu 
Trần Thị Kim Chi 7
CÁC BƯỚC CHÍNH CỦA PHÂN TÍCH
• Phân tích yêu cầu
– Phân tích nghiệp vụ
– Phân tích các yêu cầu theo quy trình xử lý
– Bổ sung các quy trình cho phù hợp với máy tính
– Yêu cầu bổ sung các thông tin
• Xác lập tính năng hệ thống
– Xác lập các chức năng mà hệ thống sẽ bao gồm
– Xác lập các điều kiện và môi trường hoạt động
• Xác thực tính năng hệ thống
– Xác thực với người dùng về tính hợp lý và đầy đủ của các
tính năng
– Xác thực các quy trình nghiệp vụ
– Xác thực các ràng buộc
Trần Thị Kim Chi 8
PHÂN TÍCH NGHIỆP VỤ
Mô hình nghiệp vụ mô tả: 
• các chức năng nghiệp vụ của một tổ chức 
• mối quan hệ bên trong giữa các chức năng đó cũng như các 
mối quan hệ của chúng với môi trường bên ngoài 
Mô hình phân rã chức năng 
• Là mô hình nghiệp vụ của hệ thống 
• Mô tả sự phân chia các chức năng nghiệp vụ của tổ chức thành 
các chức năng nhỏ hơn theo một thứ bậc xác định. 
Chức năng nghiệp vụ: 
• Tập hợp các công việc mà tổ chức cần thực hiện trong hoạt 
động của nó. 
Trần Thị Kim Chi 9
PHÂN TÍCH NGHIỆP VỤ
• Chức năng được xem xét ở các mức độ từ tổng hợp đến chi 
tiết: 
– Một lĩnh vực hoạt động (area of activites) 
– Một hoạt động (activity) 
– Một nhiệm vụ (task) 
– Một hành động (action) 
Trần Thị Kim Chi 10
PHÂN TÍCH NGHIỆP VỤ
Quy tắc phân rã 
• Mỗi chức năng được phân rã phải là một bộ phận thực sự tham 
gia thực hiện chức năng đã phân rã ra nó 
• Việc thực hiện tất cả các chức năng ở mức dưới phải đảm bảo 
thực hiện chức năng ở mức trên đã phân rã ra chúng 
Bố trí mô hình 
• Ở mỗi mức, các chức năng cùng mức sắp xếp trên cùng một 
hàng. Riêng mức cuối cùng có thể sắp xếp theo hàng dọc. 
• Bố trí cân đối, rõ ràng để dễ kiểm tra, theo dõi 
Trần Thị Kim Chi 11
PHÂN TÍCH NGHIỆP VỤ
Đặt tên chức năng 
• Mỗi chức năng có một tên duy nhất 
• Công thức 
Mô tả chi tiết chức năng ở mức cuối 
• Tên chức năng 
• Các sự kiện kích hoạt 
• Quy trình thực hiện 
• Dữ liệu vào, ra 
• Công thức tính toán sử dụng (nếu có) 
• Quy tắc nghiệp vụ cần tuân thủ 
Trần Thị Kim Chi 12
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
• Nhằm xác định mối liên hệ giữa các chức năng và thực thể 
trong hệ thống 
• Bao gồm các dòng là các chức năng ở mức tương đối chi tiết, 
các cột là thực thể 
• Mỗi ô giao giữa dòng và cột có thể là 
– C (Create - chức năng tạo ra dữ liệu mới trong thực thể) 
– R (Read - chức năng đọc dữ liệu trong thực thể) 
– U (Update - chức năng cập nhật dữ liệu trong thực thể) 
• Cho phép xem xét, phát hiện ra những khiếm khuyết trong 
khảo sát, loại bỏ những chức năng và thực thể thừa 
Trần Thị Kim Chi 13
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 14
PHÂN TÍCH NGHIỆP VỤ
Các bước xây dựng mô hình nghiệp vụ
• Mô tả bài toán 
• Lập bảng phân tích: 
– Lập danh sách các danh từ và các nhóm động từ+bổ ngữ 
– Cột nhận xét: 
• Bỏ qua danh từ chỉ khái niệm hay vật thể 
• Đánh dấu các danh từ là tác nhân và vật mang tin (thực thể 
dữ liệu) 
Trần Thị Kim Chi 15
PHÂN TÍCH NGHIỆP VỤ
Các bước xây dựng mô hình nghiệp vụ
• Lập danh sách các công việc và các hồ sơ dữ liệu sử dụng 
• Lập biểu đồ phân rã chức năng 
• Lập ma trận thực thể dữ liệu - chức năng 
•  
Trần Thị Kim Chi 16
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán 
• Một bãi gửi xe có 2 cổng: một cổng xe vào, một cổng xe ra. 
Người ta chia bãi thành 4 khu dành cho 4 loại xe khác nhau: 
xe máy, xe buýt, xe tải và công-ten-nơ. 
• Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng 
phân loại, sau đó kiểm tra chỗ trống trong bãi. Nếu chỗ dành 
cho loại xe đó đã hết thì thông báo cho khách. Ngược lại thì 
ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi 
những thông tin trên vé vào sổ xe vào. 
Trần Thị Kim Chi 17
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán
• Khi khách lấy xe, người coi xe kiểm tra vé xem vé là thật hay
giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì
không cho nhận xe. Ngược lại thì viết phiếu thanh toán và thu
tiền của khách, đồng thời ghi các thông tin cần thiết vào sổ xe
ra.
• Khi khách đến báo cáo có sự cố thì kiểm tra xe trong sổ xe vào
và sổ xe ra để xác minh xe có gửi hay không và đã lấy ra chưa.
Nếu không đúng như vậy thì không giải quyết. Trong trường
hợp ngược lại tiến hành kiểm tra xe ở hiện trường. Nếu đúng
như sự việc xảy ra thì tiến hành lập biên bản giải quyết và
trong trường hợp cần thiết thì viết phiếu chi bồi thường cho
khách.
Trần Thị Kim Chi 18
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Mô tả bài toán
Trần Thị Kim Chi 19
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Lập bảng phân tích
Trần Thị Kim Chi 20
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Lập bảng phân tích
Trần Thị Kim Chi 21
PHÂN TÍCH NGHIỆP VỤ
Cách nhóm các chức năng theo phuơng pháp từ dưới lên 
Trần Thị Kim Chi 22
PHÂN TÍCH NGHIỆP VỤ
Cách nhóm các chức năng theo phuơng pháp từ dưới lên 
Mô hình phân rã chức năng quản lý trông gửi xe 
Trần Thị Kim Chi 23
PHÂN TÍCH NGHIỆP VỤ
• Danh sách hồ sơ dữ liệu 
Trần Thị Kim Chi 24
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 25
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 26
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 27
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 28
CÁC ARTIFACTS CẦN TẠO RA TRONG PHÂN TÍCH YÊU CẦU
Mô hình phân tích = hệ thống phân tích :
 các class phân tích 
– boundary class
– entity class.
– control class
 các dẫn xuất use-case cấp phân tích :
– các lược đồ class phân tích
– các lược đồ tương tác (cộng tác,...).
– 'flow of events' ở cấp phân tích
– các yêu cầu đặc biệt của use-case
 các package phân tích
 đặc tả kiến trúc (view of analysis model)
Trần Thị Kim Chi 29
CÁC WORKERS TRONG PHÂN TÍCH YÊU CẦU
Component
Engineer
Analysis 
Model
Use-Case
Engineer
Architect
Architecture 
Description
Use-Case 
Realization -
Analysis
Analysis 
class
Analysis 
package
chịu trách nhiệm về chịu trách nhiệm về chịu trách nhiệm về
Trần Thị Kim Chi 30
QUI TRÌNH PHÂN TÍCH YÊU CẦU
Architect
Use-Case
Engineer
Architectural 
Analysis
Analyze a 
Use-Case
Analyze a 
Class
Analyze a 
Package
Component
Engineer
Trần Thị Kim Chi 31
Phân tích kiến trúc : nhận dạng các package phân tích
Supplementary
Specification
Glossary
Use-Case Model
Architectural
Analysis
Design Model
Reference 
Architecture
Deployment Model
Vision
Document
Software 
Architecture Doc
Project-Specific
Guidelines
Trần Thị Kim Chi 32
Phân tích kiến trúc : nhận dạng các package phân tích
• Mục đích của phân tích kiến trúc là phát họa mô hình phân tích và
kiến trúc hệ thống bằng cách nhận dạng các package phân tích, các
class phân tích dễ thấy và các yêu cầu đặc biệt chung cho hệ thống.
• Các package phân tích giúp tổ chức hệ thống thành những đơn vị
nhỏ dễ quản lý. Mỗi package chứa 1 số use-case với tính chất sau :
 các use-case hỗ trợ cho cùng 1 qui trình nghiệp vụ.
 các use-case hỗ trợ cho cùng 1 actor.
 các use-case có quan hệ lẫn nhau : tổng quát hóa, include và
extend.
• Theo thời gian, khi việc phân tích tiến triển, sự tinh chế cấu trúc các
package sẽ tiến triển theo.
Trần Thị Kim Chi 33
Phân tích kiến trúc : nhận dạng các class thực thể dễ thấy
• Từ các class lĩnh vực hay các class nghiệp vụ nắm bắt yêu cầu, đề 
nghị 1 số class thực thể quan trọng nhất (từ 10-20).
• Các class phân tích còn lại sẽ được nhận dạng trong hoạt động phân 
tích use-case.
• Các yêu cầu đặc biệt cũng được nhận dạng để được xử lý trong các 
bước sau, chúng gồm :
 tính bền vững.
 sự phân tán & đồng thời.
 các tính chất an toàn dữ liệu. 
 đề kháng với lỗi.
 quản lý giao tác.
• Tính chất của mỗi yêu cầu đặc biệt sẽ được cân nhắc sau trong từng 
class và từng dẫn xuất use-case.
Architecture
Design
Implementation
Code
Trần Thị Kim Chi 34
Phân tích use-case
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance, scalability, throughput
System integrators
System topology, delivery, 
installation, communication
System engineering
Analysts/Designers
Structure
Trần Thị Kim Chi 35
Phân tích use-case
Phân tích use-case là để :
 nhận dạng các class phân tích
có đối tượng của chúng tham
gia vào việc thực hiện 'flow
of events' của use-case.
 phân phối hành vi của use-
case bằng cách cho các đối
tượng phân tích tương tác
nhau.
 nắm bắt 1 số yêu cầu đặc biệt
cho dẫn xuất use-case.
Trần Thị Kim Chi 36
Phân tích use-case : nhận dạng các class phân tích
• Trong bước này ta nhận dạng các class điều khiển, biên, thực thể 
cần thiết để hiện thực use-case và phát họa tên, trách nhiệm, thuộc 
tính và các mối quan hệ giữa chúng. 
• Cách nhận dạng các thành phần :
 nhận dạng các class thực thể bằng cách chú ý các thông tin trong 
đặc tả use-case và trong mô hình lĩnh vực.
 nhận dạng class biên cơ sở cho mỗi class thực thể vừa tìm được. 
 nhận dạng class biên trung tâm cho mỗi actor là con người.
 nhận dạng class biên trung tâm cho mỗi actor là hệ thống ngoại 
hay thiết bị I/O.
 nhận dạng class điều khiển có trách nhiệm xử lý trong dẫn xuất 
use-case.
• Tập hợp các class phân tích tham gia vào dẫn xuất use-case thành 1 
(hay nhiều) lược đồ class. Trần Thị Kim Chi 37
Phân tích use-case : nhận dạng các class phân tích
Trần Thị Kim Chi 38
Phân tích use-case : Hiện thực hóa use case (Use-Case 
Realization)
Trần Thị Kim Chi 39
Thí dụ về lược đồ class phân tích cho use-case Pay Invoice
Payment Request UI
Order Configmation
Order Handler
Payment Request
Payment Scheduler
Invoice
Buyer
(f rom Use-Case Model)
Trần Thị Kim Chi 40
Phân tích use-case : miêu tả sự tương tác giữa các đối 
tượng phân tích
Các bước phân tích Use Case:
1. Bổ sung vào đặc tả use case
2. Hiện thực hóa use case (UC realization)
– Tìm các lớp từ hành vi của use case
– Phân phối hành vi của use case vào các lớp
3. Phân tích lớp (analysis class)
– Mô tả thuộc tính và sự kết hợp
– Mô tả nhiệm vụ
– Gán cơ chế phân tích
4. Hợp nhất các lớp phân tích
Trần Thị Kim Chi 41
Phân tích class
• Mục đích của việc phân tích class là :
 nhận dạng và duy trì các nghĩa vụ, trách nhiệm của class phân 
tích dựa vào vai trò của nó trong dẫn xuất use-case.
 nhận dạng và duy trì các thuộc tính và các mối quan hệ của class 
phân tích. 
 nắm bắt các yêu cầu đặc biệt liên quan đến việc hiện thực class 
phân tích
 Tổ hợp các vai trò mà class đóng trong các dẫn xuất use-case 
khác nhau sẽ cho ta 1 số nghĩa vụ của class.
 Nghiên cứu các lược đồ class và lược đồ tương tác trong các dẫn 
xuất use-case có class tham gia. 
 Đôi khi cần nghiên cứu 'flow of events cấp phân tích' của dẫn 
xuất use-case để tìm thêm các nghĩa vụ các class
Trần Thị Kim Chi 42
Phân tích class
Trần Thị Kim Chi 43
Phân tích class : nhận dạng mối quan hệ giữa các class
• Các đối tượng tương tác nhau thông qua các lược đồ cộng tác.
• Mối quan hệ gộp nên được dùng khi các đối tượng miêu tả :
 các khái niệm chứa vật lý khái niệm khác (xe chứa tài xế và
khách)
 các khái niệm được xây dựng từ các khái niệm khác (xe
gồm các bánh xe và động cơ).
 các khái niệm tạo thành tập hợp ý niệm nhiều đối tượng
(gia đình gồm cha, mẹ và con).
• Để rút trích các hành vi chung của nhiều class phân tích, ta có
thể dùng class tổng quát hóa, nhưng chỉ nên ở cấp ý niệm.
Trần Thị Kim Chi 44
Phân tích class : nhận dạng mối quan hệ giữa các class
System 
boundary
Use-case 
behavior 
coordination
System 
information
>
>
>
System 
information
>
System 
boundary
>
System 
boundary
Use-case 
behavior 
coordination
System 
information
System 
information
System 
boundary
Trần Thị Kim Chi 45
LỚP GIAO DIỆN -BOUNDARY CLASS
• Thực hiện chức năng giao tiếp với actor
• Thường chứa các phần tử giao diện hoặc điều khiển 
giao diện người dùng( button, listbox, option group, 
menu)
• Trong UML được gán stereotype là >
• Khó nhận biết các thuộc tính và tác vụ trong mô hình 
phân tích
• Ví dụ: đối với hệ thống quản lý thư viện, các đối 
tượng biên như: TheMuonForm, BanDocForm, 
Form_DangNhap
Trần Thị Kim Chi 46
LỚP GIAO DIỆN -BOUNDARY CLASS
• Là lớp trung gian giữa giao diện và hệ thống bên
ngoài
• Phân loại
– User interface classes
– System interface classes 
– Device interface classes
• Cách xác định lớp boundary:
• One boundary class per actor/use-case pair
Trần Thị Kim Chi 47
LỚP THỰC THỂ
• Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong 
hệ thống
• Thông tin về các đối tượng thực thể có thể phải được lưu trữ 
lâu dài (database,file)
• Trong UML được gán stereotype là >
• Dễ nhận diện các thuộc tính của chúng
• Ví dụ: đối với hệ thống quản lý thư viện đã mô tả ở phần 
trước, nhận diện các đối tượng thực thể như:
– Sách, Bạn đọc, Thẻ mượn, Thủ thư.
Trần Thị Kim Chi 48
LỚP THỰC THỂ
Glossary
Business-Domain 
Model
Environment independent.
Analysis class 
stereotype
Use Case
Architectural Analysis 
Abstractions
Trần Thị Kim Chi  ... cenario Step Action
Step # This is the “main success scenario” or “happy path.”
 Description of steps in successful use case “execution”
 This should be in a “system-user-system, etc.” format.
Extensions Step Branching Action
Step # Alternative paths that the use case may take
Open Issues Issue # Issues regarding the use case that need resolution
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
Trần Thị Kim Chi
144
Number 1
Name Withdraw Money
Summary User withdraws money from one of his/her accounts
Priority 5
Preconditions User has logged into ATM
Postconditions User has withdrawn money and received a receipt
Primary Actor(s) Bank Customer
Secondary Actor(s) Customer Accounts Database
Use Case Specification Template Example
Continued 
Trần Thị Kim Chi
145
Trigger User has chosen to withdraw money
Main Scenario Step Action
1 System displays account types
2 User chooses account type
3 System asks for amount to withdraw
4 User enters amount
5 System debits user’s account and dispenses money
6 User removes money
7 System prints and dispenses receipt
8 User removes receipt
9 System displays closing message and dispenses user’s ATM card
11 User removes card
10 System displays welcome message
Extensions Step Branching Action
5a System notifies user that account funds are insufficient
5b System gives current account balance
5c System exits option
Open Issues 1 Should the system ask if the user wants to see the balance?
Trần Thị Kim Chi
BÀI TẬP USE CASE
1. Với hệ thống đặt vé máy bay, người dùng có thể đặt
vé, thay đổi hay huỷ vé. Use case của hệ thống là
gì??
2. Nếu cần xây dựng hệ thống quản lý máy ATM, thì
use case “withdrawing cash” có những scenario
nào?
Trần Thị Kim Chi 146
Phân tích package
• Một gói (Package) là một cơ chế có mục đích tổ chức các yếu tố 
thành các nhóm. Một gói chứa các phần tử mô hình khác.
• Một gói có thể được sử dụng:
– Để tổ chức các mô hình phát triển.
– Là một đơn vị quản lý cấu hình.
University 
Artifacts 
Client Package Supplier 
Package
Dependency relationship
Trần Thị Kim Chi 147
Phân tích package
• Mục đích của phân tích package là :
 đảm bảo từng package độc lập với các package khác 
 đảm bảo package hoàn thành mục đích của nó là hiện thực 1 số 
class lĩnh vực hoặc 1 số use-case.
 miêu tả các phụ thuộc sao cho có thể ước lượng ảnh hưởng của 
các thay đổi trong tương lai. 
• Cách phân tích:
 đảm bảo package chứa các class đúng, cố gắng cho tính kết dính 
cao bằng cách gộp các class có mối quan hệ chức năng.
 hạn chế tối đa sự phụ thuộc giữa các package, phân phối lại các 
class quá phụ thuộc vào package khác.
Trần Thị Kim Chi 148
Phân tích package
C
A
B
Hierarchy 
should be 
acyclic
A
B
C
A'
Circular dependencies make it impossible 
to reuse one package without the other.
A
B
Trần Thị Kim Chi 149
PACKAGE USE CASE
• Khi nào dùng:
– Khi hệ thống lớn,sơ đồ use case phức tạp
– Package: gom một số use case liên quan tạo nên một sub 
system của hệ thống
• Ký hiệu:
• Ví dụ: hệ thống ATM gồm các package
Tên
Trần Thị Kim Chi 150
PACKAGE USE CASE
Trần Thị Kim Chi 151
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Mô hình hóa nghiệp vụ (Business Modeling)
– Là kỹ thuật mô hình hóa tiến trình nghiệp vụ
– Mô hình hóa các chức năng của tổ chức
– Quan tâm đến góc nhìn chức năng. Không phân biệt các tiến 
trình nghiệp vụ sẽ được tự động hóa hay thực hiện thủ công
• Biểu diễn mô hình nghiệp vụ bằng biểu đồ nghiệp vụ
– Chỉ ra tương tác giữa các tiến trình nghiệp vụ với các vai trò
(roles) thực hiện nghiệp vụ như customers hay vendors
– Biểu diễn vai trò bên ngoài nghiệp vụ
• Hai lĩnh vực của mô hình hóa nghiệp vụ
– Biên của tổ chức và nó cần giao tiếp với ai?
– Luồng công việc bên trong tổ chức và tối ưu nó như thế nào?
Trần Thị Kim Chi 152
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Không tập trung vào mô hình hóa hệ thống sẽ xây dựng
• Tập trung vào nghiệp vụ trên hệ thống
– Mục tiêu là để hiểu rõ môi trường nghiệp vụ trước khi xây dựng hệ 
thống
• Mô hình hóa nghiệp vụ
– Nghiên cứu về tổ chức
– Khảo sát cấu trúc tổ chức, quan sát các vai trò trong tổ chức và quan 
hệ của chúng với nhau như thế nào.
– Khảo sát luồng công việc trong tổ chức
• Tiến trình chính, họ làm việc thế nào
• Tính hiệu quả
• Các hạn chế
• Nghiên cứu các tổ chức bên ngoài và quan hệ với chúng?
• Làm tài liệu về các thông tin bằng mô hình nghiệp vụ của 
UML Trần Thị Kim Chi 153
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Khi nào không cần mô hình hóa nghiệp vụ?
– Khi đã hiểu biết rõ ràng cấu trúc, mục đích tác nghiệp, 
stackholders của tổ chức
– Khi xây dựng phần mềm sử dụng cho một phần nhỏ của tổ 
chức, không ảnh hưởng đến nghiệp vụ khác
– Luồng công việc khá rõ ràng và có tài liệu đầy đủ
– Khi không có đủ thời gian!!!!????
Trần Thị Kim Chi 154
CÁC KHÁI NIỆM CƠ BẢN CỦA MÔ HÌNH HÓA 
NGHIỆP VỤ (Business Modeling)
• Các khái niệm cơ bản bao gồm
– Business actors
– Business workers
– Business use case
– Biểu đồ Business use case
– Quan hệ giao tiếp giữa Business use case và 
Business actor
– Thực thể Business 
– Các biểu đồ hoạt động
Trần Thị Kim Chi 155
TÁC NHÂN NGHIỆP VỤ
• Ai đó, cái gì đó bên ngoài tổ chức nhưng tương tác với nó
– Customers, Investors, Suppliers...
– Có thể là nguời hay nhóm nguời
• Tìm kiếm tác nhân nghiệp vụ?
– Quan sát phạm vi dự án để tìm ra những gì nằm ngoài dự án
– Những gì (ai, cái gì) nằm ngoài dự án có liên quan đến nghiệp
vụ
• Nghiên cứu tài liệu mô tả dự án, thị trường tổ chức, mục tiêu
nghiệp vụ... để xác định thực thể bên ngoài liên quan
– Thí dụ: Hãng hàng không liên quan đến nhà sản xuất máy bay,
nhà sản xuất đồ ăn uống cho khách, khách hàng, hiệp hội hàng
không...
• Có 2 loại: tác nhân thực hiện các công việc bên trong hệ thống và
các tác nhân tương tác trực tiếp với các tác nhân bên ngoài hệ thống.
Trần Thị Kim Chi 156
WORKER NGHIỆP VỤ
• Là vai trò (role) trong tổ chức
– Một người có thể có nhiều vai trò
– không phải là chức vụ
• Mô tả worker
– Có trách nhiệm gì?
– Kỹ năng cần có để thực hiện trách nhiệm?
– Tương tác với worker nào?
– Tham gia vào luồng công việc nào?
– Trách nhiệm của worker trong luồng công việc
• Tìm kiếm worker nghiệp vụ
– Quan sát phạm vi dự án – bắt đầu từ biểu đồ tổ chức
– Khi đã có danh sách worker thì làm tài liệu cho chúng
• Thí dụ worker nghiệp vụ trong công ty hàng không
– Phi công, người dẫn đường, thợ máy, tiếp viên, nhân viên an ninh...
Trần Thị Kim Chi 157
USE CASE NGHIỆP VỤ
• Business use case là nhóm các luồng công việc liên quan có ý 
nghĩa với tác nhân nghiệp vụ
– Cho biết tổ chức làm gì
– Tập các ca nghiệp vụ mô tả đầy đủ nghiệp vụ của tổ chức
• Ðặt tên: Theo hình thức “”: 
VD: “Price Products”
• Làm tài liệu luồng công việc
– Thí dụ với use case nghiệp vụ Price Products
• Nhân viên yêu nguời cầu quản lý cung cấp danh sách các mặt hàng
mới cần định giá
• Nhân viên kiểm tra hóa đơn kho để biết phải trả cho kho bao nhiêu
kho hàng bán
• Nhân viên cộng thêm 10% để có giá bán
• Nhân viên trình giá để nguời quản lý phê duyệt
• Nhân viên làm các thẻ sản phẩm
• Gắn thẻ giá sản phẩm vào từng sản phẩ
Trần Thị Kim Chi 158
TƯƠNG TÁC GIỮA CÁC PHẦN TỬ
• Biểu diễn tương tác
– Quan hệ association:
• giữa tác nhân nghiệp vụ, worker nghiệp
vụ với use case nghiệp vụ
• mũi tên cho biết ai khởi xướng 
tiến trình
– Quan hệ generalization 
• chỉ ra cấu trúc kế thừa giữa các
phần tử mô hình nghiệp vụ
 áp dụng cho hai hay nhiều phần
 tử tương tự nhau
Trần Thị Kim Chi 159
BIỂU ĐỒ USE CASE NGHIỆP VỤ
• Chỉ ra mô hình đầy đủ 
– cái công ty làm
– ai ở trong công ty
– ai ở ngoài công ty
• Cho biết phạm vi của tổ chức
• Nếu có nhiều use case nghiệp vụ
có thể tạo nhiều biểu đồ UC
nghiệp vụ và mỗi biểu dồ 
chứa tập các UC nghiệp vụ
• Mũi tên đi từ tác nhân nghiệp
vụ và worker nghiệp vụ đến 
• UC nghiệp vụ cho thấy ai khởi
động tiến trình nghiệp vụ. Trần Thị Kim Chi 160
THỰC THỂ NGHIỆP VỤ
• Business entity là đối tuợng mà tổ chức sử dụng để điều hành 
tác nghiệp hay sản xuất.
• Thực thể bao gồm tất cả những gì mà worker nghiệp vụ có liên 
quan hàng ngày
– Thí dụ: Sales Order, Account, Shiping Box, Contract, Ghim giấy...
• Trả lời các câu hỏi sau để tìm thực thể nghiệp vụ:
– Sản phẩm của công ty?
– Công ty có các dịch vụ?
– Công ty phải mua vật liệu gì để sản xuất?
– Khách hàng cung cấp/nhận gì từ công ty?
– Các worker nghiệp vụ trao đổi nhau cái gì khi sản xuất?
• Tìm kiếm thực thể nghiệp vụ ở nơi khác
– Các danh từ trong use case nghiệp vụ
Trần Thị Kim Chi 161
THỰC THỂ NGHIỆP VỤ
• Ví dụ:
• Bổ sung các thuộc tính cho thực thể nghiệp vụ
– Thí dụ, thực thể nghiệp vụ Account có các thuộc tính 
account number, account type, balance, date opened, 
status...
– Chú ý rằng chưa có thiết kế CSDL ở đây
– Chỉ bổ sung các thuộc tính để dễ hiểu nghiệp vụ 
Trần Thị Kim Chi 162
ÐƠN VỊ TỔ CHỨC
• Ðơn vị tổ chức (Organization Unit) là tập hợp các 
worker
nghiệp vụ, thực thể nghiệp vụ và các phần tử mô hình 
nghiệp vụ khác
• Là cơ chế đuợc sử dụng để tổ chức mô hình nghiệp 
vụ
• Nhiều công ty tổ chức theo phòng, ban, đơn vị...
– Mỗi chúng được mô hình hóa như đơn vị tổ chức
– Mỗi đơn vị tổ chức sẽ bao gồm các worker nghiệp vụ bên 
trong phòng, ban, đơn vị đó.
• Biểu tượng
Trần Thị Kim Chi 163
BIỂU ĐỒ USE CASE NGHIỆP VỤ
• Thực tế: luồng công việc (Workflow) không đơn giản mà có 
nhiều logíc điều kiện
– worker nghiệp vụ có thể thực hiện một vài actions khi điều 
kiện A xảy ra và thực hiện một vài actions khác khi điều kiện 
B xảy ra...
– hãy sử dụng biểu đồ hoạt động (Activity Diagram) để mô 
hình hóa các luồng công việc
• Nếu trong biểu đồ UC nghiệp vụ có nhiều UC nghiệp vụ,
tác nhân nghiệp vụ và worker nghiệp vụ thì có thể nhóm 
chúng thành các đơn vị tổ chức (Organizational Units)
– tổ chức lại mô hình để dễ dọc và dễ hiểu
– sau đó xây dựng biểu đồ UC nghiệp vụ cho từng đơn vị tổ 
chức
Trần Thị Kim Chi 164
BIỂU ĐỒ USE CASE NGHIỆP VỤ
Ví dụ: các loại use case nghiệp vụ của một tổ chức nhà hàng
Trần Thị Kim Chi 165
BIỂU ĐỒ USE CASE NGHIỆP VỤ
Ví dụ: mô hình use case mô tả nghiệp vụ của siêu thị Co-op Mart
Trần Thị Kim Chi 166
CÂU HỎI VÀ BÀI TẬP
1. Hỏi: Một tác nhân (Actor) trong một Use Case luôn là 
một con người
Đáp: Sai, tác nhân là một người hoặc một vật nào đó tương 
tác với hệ thống.
2. Hỏi: Hệ thống khác cũng có thể đóng vai trò tác nhân 
trong một Use Case?
Đáp: Đúng 
3. Hỏi: Mỗi hệ thống chỉ có một Use Case? 
Đáp: Sai 
4. Hỏi: Biểu đồ Use case mô tả chức năng hệ thống? 
Đáp: Đúng 
Trần Thị Kim Chi 167
CÂU HỎI VÀ BÀI TẬP
Trần Thị Kim Chi 168
CÂU HỎI VÀ BÀI TẬP
• Đặc tả Use case cho các bài toán nghiệp vụ trên
Trần Thị Kim Chi 169
CÂU HỎI VÀ BÀI TẬP
• Là trưởng ban It của trường ĐH KHTN, bạn được yêu cầu
phát triển một hệ thống đăng ký học phần mới hệ thống mới
cho phép sinh viên đăng ký học phần và xem phiếu điểm
từ máy tính cá nhân được kết nối vào mạng nội bộ của
trường. Các giảng viên cũng có thể truy cập hệ thống này
để đăng ký lớp dạy và nhập điểm cho các môn học.
• Trường sẽ giữ lại CSDL sẵn có về danh mục học phần mà
trong đó lưu trữ toàn bộ thông tin về học phần. Đây là
CSDL quan hệ và có thể truy cập bằng các câu lệnh SQL
thông qua các server của trường. Hệ thống mới sẽ đọc các
thông tin học phần trên CSDL cũ nhưng sẽ không cập
nhập chúng. Phòng đào tạo sẽ tiếp tục duy trì các thông tin
học phần thông qua hệ thống khác.
Trần Thị Kim Chi 170
CÂU HỎI VÀ BÀI TẬP
• Ở đầu mỗi học kỳ, sinh viên có thể yêu cầu danh sách các
học phần được mở trong học kỳ đó. Thông tin về mỗi học
phần, ví dụ như là tên giáo sư, khoa, và các môn học phần tiên
quyết sẽ được cung cấp để giúp sinh viên chọn lựa.
• Hệ thống mới cho phép sinh viên được chọn 4 học phần
được mở cho học kỳ tới. Mỗi sinh viên có thể đưa ra hai
môn học thay thế trong trường hợp không thể đăng ký
theo nguyện vọng chính. Các học phần được mở tối đa là 100
và tối thiểu là 30 sinh viên. Các học phần có ít hơn 30 sinh
viên sẽ bị hủy bỏ.
• Đầu mỗi học kỳ, sinh viên có một khoảng thời gian để thay
đổi các học phần đã đăng ký. Sinh viên chỉ có thể thêm hay
hủy các học phần đăng kí trong khoảng thời gian này.
Trần Thị Kim Chi 171
CÂU HỎI VÀ BÀI TẬP
• Khi quá trình đăng ký đã hoàn tất cho mỗi sinh viên, hệ thống
đăng kí sẽ gửi thông tin tới hệ thống thanh toán (billing
system) để sinh viên có thể đóng học phí. Nếu một lớp bị
hết chỗ trong quá trình đăng ký, sinh viên sẽ được thông báo
về sự thay đổi trước khi xác nhận việc đăng ký học
• Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để
xem phiếu điểm. Vì thông tin về điểm của sinh viên phải
được giữ kín, nên hệ thống cần có cơ chế bảo mật để ngăn
cản việc truy cập không hợp lệ
• Các giảng viên có thể truy cập vào hệ thống để đăng ký
những học phần mà họ sẽ dạy. Họ có thể xem danh sách các
sinh viên đã đăng ký vào lớp của họ, cũng như nhập điểm sau
mỗi khóa học.
Trần Thị Kim Chi 172
CÂU HỎI VÀ BÀI TẬP
Lập bảng chú giải (Glossary) của ứng dụng Course Registration:
• Course (Học phần): Một môn học được dạy trong trường.
• Course Offering (Lớp): Một lớp học cụ thể được mở trong
mỗi học kỳ cụ thể cùng một học phần cụ thể được mở song
song nhiều lớp trong mỗi học kỳ. Thông tin gồm cả ngày học
trong tuần và giờ học.
• Course Catalog (Danh mục học phần): Danh mục đầy đủ
của tất cả các học phần được dạy trong trường.
• Faculty: Toàn bộ cán bộ giảng dạy của trường.
• Finance System (Hệ thống thanh toán): Hệ thống dùng để
xử lý các thông tin thanh toán học phí.
Trần Thị Kim Chi 173
CÂU HỎI VÀ BÀI TẬP
Lập bảng chú giải (Glossary) của ứng dụng Course Registration:
• Grade (Điểm số): Điểm của mỗi sinh viên trong một lớp cụ 
thể. 
• Professor (Giáo sư): Người giảng dạy trong trường.
• Report Card (Phiếu điểm): Toàn bộ điểm số cho tất cả học 
phần một sinh viên đã học trong một học kỳ xác định.
• Roster (Danh sách sinh viên đăng ký): Tất cả sinh viên đăng 
ký vào một lớp học cụ thể.
• Student (Sinh viên): Người đăng ký học các lớp của trường.
• Schedule (Lịch học): Các học phần mà sinh viên đã chọn học 
trong học kỳ hiện tại.
• Transcript (Bản sao học bạ): Bản sao tất cả điểm cho tất cả 
các học phần của một sinh viên cụ thể được chuyển cho hệ 
thống thanh toán để hệ thống này lấp hóa đơn cho mỗi sinh 
viên.
Trần Thị Kim Chi 174
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 175
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 176
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 177
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Lap BC
Trần Thị Kim Chi 178
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 179
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 180
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán 
nghiệp vụ trên
Trần Thị Kim Chi 181
Trần Thị Kim Chi182