Bai Giang Ptich

CHƯƠNG 1
TỔNG QUAN
PHÂN TÍCH VÀ THIẾT KẾ HTTT
OVERVIEW OF ANALYSIS AND DESIGN INFORMATION SYSTEMS
PGS.TS. Nguyễn Mậu Hân

Khoa CNTT-ĐHKH
HUẾ
nmhan2009@gmail.com
NỘI DUNG
1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ

HTTT
2. HỆ THỐNG THÔNG TIN QUẢN LÝ
3. MÔ HÌNH HÓA MỘT HTTT
4. GIỚI THIỆU MỘT VÀI PHƯƠNG

PHÁP PTTK
5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT
6. CÁC CÁCH TIẾP CẬN TRONG PHÁT TRIỂN

PHẦN MỀM
1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT
• Thông tin (Informations):

 những sự kiện
 những khái niệm
 những hiểu biết và
 những phán đoán
có được ở một thời điểm ấn định về một hiện
tượng, một sự việc hay một con người.
3
1.1. CÁC KHÁI NIỆM CƠ BẢN VỀ THÔNG TIN VÀ HTTT
• Hệ thống - Hệ thống thông tin

Hệ thống
Tập hợp các phần tử có quan hệ qua lại với nhau
cùng hoạt động hướng đến một mục tiêu chung
thông qua việc tiếp nhận các đầu vào và sản xuất
các đầu ra nhờ một quá trình chuyển đổi được tổ
chức.
Hệ thống này còn được gọi là hệ thống động
(Dynamic System)
4
1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT
Hệ thống mở (hệ thống có tính xác suất) trong

đó đầu vào, đầu ra không thể xác định chính xác
nhưng có thể dự đoán được.
Ví dụ:
•Hệ thống đặt chổ vé máy bay không thể đoán
chính xác bao nhiêu chỗ sẽ được đặt cho một
chuyến bay nào đó.
• Hệ thống thông tin dự báo thời tiết
5
Hệ thống đóng
Hệ thống có thể đoán trước kết quả đầu ra nếu
biết đầu vào.
Vd: HTTT QL NHÂN SỰ & TIỀN LƯƠNG
 hệ thống đóng dễ quản lý hơn hệ thống mở.
Cấu tạo của một hệ thống
INPUT OUTPUT
SYSTEM
HỘP ĐEN
6
Thông tin và Ra quyết định

Mục đích của thông tin:
 giúp nhà quản lý / lãnh đạo RQĐ.
Ra Quyết định
một hành động (hay sự thực hiện) nhằm thay
đổi trạng thái hiện tại tới 1 trạng thái mong muốn.
Các loại quyết định:
 QĐ có cấu trúc
 QĐ bán cấu trúc
 QĐ không có cấu trúc
Hệ thống thông tin (information system)

Về hình thức- là một hệ thống, gồm nhiều
thành
phần mà mối liên hệ giữa các thành phần này cũng
như liên hệ giữa chúng với các hệ thống khác là liên
hệ thông tin.
Về nội dung - Là một hệ thống sử dụng công nghệ
thông tin để thu thập, truyền, lưu trữ, xử lý và biểu
diễn thông tin trong một hay nhiều quá trình nghiệp
vụ.
8
Tại sao phải phân tích thiết kế HT thông tin?

 Có một cái nhìn đầy đủ, đúng đắn và chính xác
về hệ thống thông tin được xây dựng.
 Tránh sai lầm trong thiết kế và cài đặt.
 Tăng vòng đời (life cycle) của hệ thống
 Dễ sửa chữa, bổ sung và phát triển hệ thống.
9
IBM đã thống kê được trong giai đoạn 1970-1980.
Phân tích về sai sót:

 Quan niệm : 45%
 Mã hóa : 25%
 Soạn thảo : 7%
 Các sai sót ở mức 2 : 20%
 Các sai sót không xếp loại : 3%
10
IBM đã thống kê được trong giai đoạn 1970-1980.
Phân tích về chi phí

 Bảo trì: 54%
 Phát triển: 46%
Phân tích phân bổ hoạt

động
 Sản xuất mã: 15%
 Phát hiện và sửa chữa sai sót:
 50% Khác:
35%
11
Microsoft đã thống kê được (2003)
12
13
Nhận xét: Các số liệu trên cho thấy:

 Sai sót lớn nhất trong tất cả các loại sai sót:
mức quan niệm, tức là nằm trong việc PT và TK.
 Chi phí chiếm tỉ trọng lớn nhất:

bảo hành
 Lượng công việc chiếm tỷ lệ lớn nhất:

phát hiện và sửa chữa.
14
ĐỊNH NGHĨA HÌNH THỨC MỘT HTTT
 Hệ thống thông tin của một tổ chức là

tập hợp các phương tiện, nhân lực, vật
lực, thông tin và phương pháp xử lý tin
nhằm cung cấp các thông tin cho quá
trình ra quyết định đúng thời hạn và đủ
độ tin cậy.
15
CÁC THÀNH PHẦN CỦA MỘT HTTT QUẢN LÝ
Trong đó:
*Tổ chức: có thể là cơ quan, xí nghiệp, trường học...
*Phương tiện (phần cứng-phần mềm): cơ sở vật
chất dùng để thu nhập, xử lý, lưu trữ, chuyển tải
thông tin trong hệ thống như máy tính, máy in, điện
thoại lực
*Nhân ... : bao gồm tập thể, cá nhân tham gia vào
việc phát triển và duy trì HT
*Thông tin: Các thông tin sử dụng trong hệ thống,
các thông tin từ môi trường bên ngoài vào hệ
thống, các thông tin từ hệ thống ra môi trường bên
ngoài.
*Phương pháp xử lý tin: các tài nguyên phi vật chất
như các mô hình toán học, các thuật toán, tri
thức của con người trong hệ thống, các phần
mềm. 16
1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ
(Management Information System, MIS)
 Phục
Mục vụ cho
đích của MIScông tác quản lý.
 Tạo ra các báo cáo thường xuyên hoặc theo
yêu cầu dưới dạng tóm tắt về hiệu quả hoạt
động nội bộ của tổ chức.
 MIS chỉ quan tâm đến hiệu quả hoạt động của
các đối tượng trong và ngoài tổ chức để có
các biện pháp đối xử và phân bổ nguồn lực
thích hợp.
(Management Information System, MIS)
Chức năng của MIS
– Cung cấp thông tin cho việc quản lý tổ chức
– Cho phép các nhà quản lý kiểm soát và điều
khiển các tổ chức
– Cung cấp những thông tin phản hồi chính
xác
– Cung cấp các báo cáo đặc biệt trên cơ sở đã
được lập kế hoạch
Đặc điểm MIS

 MIS Hỗ trợ cho trong xử lý và lưu trữ giao dịch
 MIS sử dụng CSDL hợp nhất và hỗ trợ cho
nhiều chức năng trong tổ chức
 MIS đủ mềm dẻo để có thể thích ứng được với
những nhu cầu về thông tin của tổ chức
 MIS tạo lớp vỏ an toàn cho HT và phân quyền
cho việc truy nhập HT
 MIS cung cấp thông tin theo thời gian cho các
nhà QL, chủ yếu là các thông tin có cấu trúc
Ví dụ về HTTT quản lý
Một số MIS thông dụng:
 Dự báo bán hàng (Sales forecasting)

Dự báo & quản lý tài chánh (Financial
management and forecasting)
Lập lịch & lập kế hoạch sản xuất
(Manufacturing planning and scheduling)
Lập kế hoạch & quản lý tồn kho (Inventory
management and planning)
Định giá sản phẩm & Quảng cáo
(Advertising and product
pricing)
Có 3 thành phần:
 Thành phần quyết định:
Chức năng: ra quyết định.
 Thành phần thông tin:
Chức năng tiếp nhận, xử lý, truyền tin và lưu
trữ thông tin.
 Thành phần tác nghiệp:
Chức năng: bảo đảm các hoạt động cơ sở của
tổ chức.
22
23
VAI TRÒ, NHIỆM VỤ CỦA HTTT QUẢN LÝ

Vai trò
 Hệ thông tin đóng vai trò trung gian giữa hệ
quyết định và hệ tác nghiệp trong hệ thống

quản lý.
Nhiệm vụ
 Trao đổi thông tin với môi trường ngoài
 Thực hiện việc liên lạc giữa các bộ phận và
cung cấp thông tin cho các thành phần tác

nghiệp và thành phần quyết định.
24
CÁC THÀNH PHẦN CỦA MỘT HTTT
25
1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN
Mô hình hóa là gì?

 Mô hình hóa (MHH) là đơn giản hóa cái có thật
 Mô hình là một dạng trừu tượng hoá hệ thống thực
của bài toán mà chúng ta đang xét.
 Bài toán này được diễn đạt một cách hình thức, dễ
hiểu bằng văn bản, biểu đồ, đồ thị, công thức hay
phương trình toán học, ...
 Tóm lại, Mô hình là một cách mô tả của một vật thể
nào đó. Vật đó có thể tồn tại trong một số giai đoạn
nhất định của quá trình phân tích thiết kế hệ thống.
Ví dụ về mô hình hóa
Mô hình: Quả địa

cầu học sinh
Thế giới thực
Thế giới thực
Làm chủ Con người Đọc  Sách

Ôtô Mô hình
Ví dụ về mô hình
A model is a complete
description of a
system from a
particular perspective
1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN...
Tại sao phải mô hình hóa HTTT?

 Nhu cầu của người phân tích thiết kế hệ thống
 Tìm hiểu quá trình nhận thức, diễn tả sự phức
tạp của hệ thống thông qua mô hình.
 Giới hạn vấn đề nghiên cứu bằng cách chỉ tập
trung vào một khía cạnh trong phạm vi không
gian và thời gian nhất định.
Mục đích của mô hình hoá
 Giúp trực quan hóa hệ thống mà bạn muốn tìm
hiểu.
 Mô hình hóa cho phép đặc tả được cấu trúc và
hành vi của hệ thống:
 Đảm bảo hệ thống đạt được mục đích đã xác định
trước.
 Kiểm tra được các qui định về cú pháp, ngữ nghĩa,
tính chặt chẽ và đầy đủ của mô hình, khẳng định
được tính đúng đắn của thiết kế, phù hợp với yêu
cầu đặt ra.
Tóm lại, 4 mục đích quan trọng của mô hình hoá ...
 Hình dung một hệ thống theo thực tế hay

theo mong muốn của chúng ta.
 Cho phép đặc tả cấu trúc hoặc hành vi
của hệ thống.
 Tạomột khuôn mẫu hướng dẫn nhà phát
triển trong suốt quá trình xây dựng hệ thống.
 Lập tài liệu về các quyết định đã đưa ra
để sử dụng sau này.
Các yêu cầu của mô hình hoá:

Việc biểu diễn mô hình phải thỏa mãn các yếu tố sau:
Chính xác (accurate): Mô tả đúng hệ thống cần xây
dựng.
Đồng nhất (consistent): Các view khác nhau không
được mâu thuẩn với nhau.
Có thể hiểu được (understandable): Cho những
người xây dựng lẫn sử dụng
 Dễ thay đổi (changeable)
 Dễ dàng liên lạc với các mô hình khác.
MỤC ĐÍCH, YÊU CẦU ĐỐI VỚI MỘT PH PHÁP PTTK
Mục đích:
 HTTT có vòng đời dài (long life cycle)
 Có chức năng là một hệ hỗ trợ ra quyết định
 Chương trình dễ cài đặt, sửa chữa, bảo hành
 Hệ thống dễ sử dụng, có độ chính xác cao.

MỤC ĐÍCH, YÊU CẦU ĐỐI VỚI MỘT PH PHÁP PTTK
Yêu cầu
Quan điểm tiếp cận tổng thể:
Từ tổng quát đến chi tiết
Xem mọi bộ phận, dữ liệu, chức năng là các phần tử trong
hệ thống.
Quan điểm top-down:
Quan điểm phân tích từ trên xuống theo hướng tiếp cận từ
tổng thể đến riêng biệt.
Nhận dạng được các mức trừu tượng và bất biến của hệ
thống ứng với chu trình phát triển hệ thống
Nhận dạng được các thành phần dữ liệu và xử lý của HT
Định ra được các kết quả cần đạt được cho từng giai đoạn
phát triển hệ thống và các thủ tục cần thiết trong mỗi giai
đoạn.
XÂY DỰNG THÀNH CÔNG MỘT HTTT
Khái niệm về một dự án CNTT thành công

 Chưa có một tiêu chuẩn cụ thể để xác định một HTTT được
xem là thành công
Một HTTT được gọi là có hiệu lực nếu nó góp phần nâng
cao chất lượng hoạt động quản lý tổng thể của tổ chức, và thể
hiện cụ thể trên các mặt:
Đạt được mục tiêu thiết kế đề ra.
Chi phí vận hành là chấp nhận được.
Có độ tin cậy cao, đáp ứng được các chuẩn mực của một
HTTT
Sản phẩm có giá trị: thtin đưa ra là đúng đắn, kịp thời, có
ý nghĩa thiết thực đối với hoạt động chức năng và quản lý.
Dễ học, dễ nhớ và dễ sử dụng.
Mềm dẽo, hướng mở, dễ bảo trì.
1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK
Một số công cụ mô tả quá trình phát triển một HTTT:
Lưu đồ hệ thống: đồ thị về những đầu vào (input), đầu ra
(output) và dòng dữ liệu giữa các điểm chính trong hệ thống.
Sơ đồ khối chương trình: đồ thị về lôgic dòng điều khiển của
chương trình.
Sơ đồ ngữ cảnh: mô tả các dòng dữ liệu lưu chuyển giữa các
thành phần (điểm công tác) khác nhau của hệ thống.
Từ điển dữ liệu: tập hợp có cấu trúc các dữ kiện về dữ liệu.
Từ điển dữ liệu chứa danh sách các cấu trúc dữ liệu và các định
nghĩa về tất cả thành phần dữ liệu cơ sở trong các kho dữ liệu.
Lược đồ cấu trúc: đồ thị về lôgic điều khiển các chức năng
của hệ thống.
Phương pháp phân tích thiết kế có cấu trúc SADT:
Nguồn gốc: xuất phát từ Mỹ,

Ý tưởng cơ bản:
 Một hệ thống được xem như một bộ
sưu tập của các chức năng.
 Phân rã một hệ thống lớn thành các

hệ thống con đơn giản.
Phương pháp phân tích thiết kế SADT:
Công cụ để phân tích:
 Sơ đồ chức năng nghiệp vụ BFD (Business Function Diagram)
 Sơ đồ luồng dữ liệu DFD (Data Flow Diagram) .
 Mô hình dữ liệu quan hệ (Relation data Mode)
 Ngôn ngữ có cấu trúc (Structured Language)
 Từ điển dữ liệu (Data Dictionary)
 Bảng và cây quyết định (Warnier/orr)
 Đặc tả các tiến trình (Process Specification).
Ưu điểm:
 Dựa vào nguyên lý phân tích có cấu trúc
 Thiết kế theo lối phân cấp, bảo đảm từ một dữ liệu vào sản xuất
nhiều dữ liệu ra.
Nhược điểm:
 không chứa toàn bộ các tiến trình phân tích do đó nếu không thận
trọng có thể đưa đến tình trạng trùng lặp thông tin.
Phương pháp phân tích thiết kế MERISE:
Nguồn gốc:
MERISE viết tắt từ cụm từ Methode pour
Rassembler les Ideés Sans Effort (phương pháp tập
hợp các ý tưởng không cần cố gắng).
Ra đời vào những năm cuối của thập niên 70. Xuất
phát từ những suy nghĩ của một nhóm nghiên cứu
đứng đầu bởi J.L.Lemoigne tại trường đại học Aix-
En-Provence - Pháp và những nghiên cứu hiện thực
đồng thời ở Trung tâm nghiên cứu trang bị kỹ thuật
(CETE), dưới sự lãnh đạo của H.Tardien.
Nguồn gốc:
MERISE viết tắt từ cụm từ Methode pour
Rassembler les Ideés Sans Effort (phương pháp tập
hợp các ý tưởng không cần cố gắng).
Ra đời vào những năm cuối của thập niên 70. Xuất
phát từ những suy nghĩ của một nhóm nghiên cứu
đứng đầu bởi J.L.Lemoigne tại trường đại học Aix-
En-Provence - Pháp và những nghiên cứu hiện thực
đồng thời ở Trung tâm nghiên cứu trang bị kỹ thuật
(CETE), dưới sự lãnh đạo của H.Tardien.
Đặc trưng của phương pháp Merise:
 Tách rời dữ liệu và xử lý nhằm đảm bảo tính khách quan
trong quá trình phân tích và cung cấp đầy đủ các mô hình
để diễn đạt các bước cập nhật.
Mô tả hệ thống: bao gồm dữ liệu và xử lý được biểu diễn ở ba

mức:
 Mức quan niệm (Concept): xác định mục đích của hệ
thống, các thành phần của dữ liệu và xử lý.
 Mức tổ chức (Oganization): chi tiết hóa những quan hệ
giữa chúng.
 Mức vật lý (Physic): các thành phần được thể hiện
trong
thực tế như thế nào.
Công cụ để phân tích:
MỨC DỮ LIỆU XỬ LÝ
Mức quan niệm MH quan niệm về dữ MH quan niệm về
liệu xử lý
Mức tổ chức MH tổ chức về dữ liệu MH tổ chức về xử lý
Mức vật lý MH vật lý về dữ liệu MH vật lý về xử lý
Phương pháp phân tích thiết kế hướng đối tượng
 Ra đời vào giữa thập niên 80
 Phát triển từ các ý tưởng của lập trình hướng đối tượng.
 Dựa trên một số khái niệm cơ bản sau:
• Ðối tượng (Object): gồm dữ liệu và thủ tục tác động lên
dữ liệu này
• Lớp (Class): Tập hợp các đối tượng có chung một cấu
trúc dữ liệu và cùng một phương pháp.
• Kế thừa (Heritage): tính chất kế thừa là đặc tính cho
phép định nghĩa một lớp mới từ các lớp đã có bằng
cách
thêm vào đó những dữ liệu mới, các phương pháp mới
có thể kế thừa những đặc tính của lớp cũ.
• Ðóng gói (Encapsulation): Không cho phép tác động
trực
tiếp lên dữ liệu của đối tượng mà phải thông qua
Phương pháp phân tích thiết kế hướng đối tượng (tt)
 Sử dụng ngôn ngữ mô hình hoá hợp nhất UML để mô tả.
 UML sử dụng 9 biểu đồ để mô hình hóa một hệ thống:
NHỮNG SAI LẦM CÓ THỂ XẢY RA KHI PTTK MỘT HTTT
 Thiếu sự tiếp cận tổng thể trong phát triển HT

 Thu thập thông tin nhiều lần về một đối tượng
 Dùng các thuật ngữ khác nhau đối với cùng một
quan niệm
 Sự phiến diện, không đầy đủ của hồ sơ
 Sự bất hợp tác của người sử dụng.
 Thiếu một chuẩn thống nhất:
Người phân tích thiếu một chuẩn thống nhất để mô
tả,
cài đặt các ứng dụng trong hệ thống
1.4. CÁC GIAI ĐOẠN XÂY DỰNG MỘT HTTT TIN HỌC HÓA
 Nghiên cứu nhu cầu (hệ thống cần gì?)
 Nghiên cứu khả thi (cân nhắc giữa nhu cầu và

khả năng)
 Đề xuất một kiểu kiến trúc mới của HT
 Mã hóa (tổ chức dữ liệu và lập trình)
 Thử nghiệm và khai thác

1.4. CÁC GIAI ĐOẠN XÂY DỰNG MỘT HTTT TIN HỌC HÓA
a. Giai đoạn lập kế hoạch (khảo sát hệ thống)
 Xác định các công việc cần thiết trước khi có thể
tiến hành nghiên cứu các lĩnh vực, bộ phận, hệ
thống con, các tổ chức có liên quan đến hệ thống
thông tin cần xây dựng.
 Làm rõ được ý muốn của chủ đầu tư là: xây dựng 1
hệ thống thông tin mới hay nâng cấp một hệ thống
thông tin cũ.
b. Giai đoạn phân tích
Là giai đoạn trung tâm khi xây dựng 1 hệ thống thông tin, giai
đoạn này khởi sự ngay trong giai đoạn lập kế hoạch. Phân
tích bao gồm các công việc sau:
1. Phân tích hiện trạng
Mục đích: hiểu rõ tình trạng hoạt động của hệ thống cũ
trong mục đích hoạt động của tổ chức.
Nội dung công việc:
Tìm hiểu hiện trạng: thông qua việc nghiên cứu hồ sơ, tài
liệu để tìm hiểu thông tin chung về ngành dọc của tổ
chức.
 Tìm hiểu hoạt động hiện tại của tổ chức
 Xác định các thành phần tham gia trong tổ chức
 Các nhiệm vụ của các tổ chức thành viên và các tổ
chức bên ngoài có liên quan
 Các mối quan hệ thông tin giữa các thành viên trong
tổ chức
2. Phân tích khả thi và lập hồ sơ

nhiệm vụ:
. Phân tích khả thi về kỹ thuật: xem xét khả năng
kỹ thuật hiện có để đề xuất giải pháp kỹ thuật áp
dụng cho httt mới.
. Phân tích khả thi kinh tế: xem xét khả năng tài
chính để chi trả cho việc xây dựng hệ thống thông
tin mới cũng như chỉ ra những lợi ích mà hệ thống sẽ
đem lại.
. Phân tích khả thi hoạt động: khả năng vận hành hệ
thống trong điều kiện khuôn khổ, điều kiện tổ chức và
quản lý cho phép của tổ chức.
Tóm lại, trong giai đoạn này người phân tích phải tìm
ra một điểm cân bằng giữa nhu cầu và khả năng.
Lập hồ sơ nhiệm vụ. Công việc này nhằm

mục đích:
• Định hình các chức năng hệ thống cần đạt được.
• Định ra các thủ tục xây dựng quan niệm và thực
hiện hệ thống
• Định hình sơ lược giao diện của hệ thống với
người sử dụng trong tương lai.
• Làm các bản mẫu (prototype) để NSD hình dung
được hệ thống trong tương lai.
Tóm lại, lập hồ sơ nhiệm vụ là một thỏa thuận
không chính thức giữa 3 phía: Người phân tích,
Chủ đầu tư và Người sử dụng.
c. Giai đoạn thiết kế
 Thiết kế dữ liệu: xác định các đối tượng và cấu trúc dữ

liệu được sử dụng trong hệ thống.
 Thiết kế chức năng: định ra các modun xử lý thể hiện

các chức năng xử lý của hệ thống thông tin.
 Thiết kế giao diện: chi tiết hóa hình thức giao tiếp
người - máy
 Thiết kế an toàn hệ thống
 Thiết kế phần cứng: tính toán các yêu cầu kỹ thuật, cơ

sở vật chất cho hệ thống
 Dự kiến nhân sự tại các vị trí công tác của hệ thống.

d. Giai đoạn thực hiện
 xây dựng hệ thống bao gồm xây dựng các file cơ

bản.
 viết các chương trình thực hiện các chức năng của
hệ thống mới tương ứng với các kiểu khai thác đã
đặt ra.
 làm tài liệu sử dụng để hướng dẫn cho người sử
dụng
 làm tài liệu kỹ thuật cho các chuyên gia tin học
phát triển hệ thống sau này.
e. Giai đoạn chuyển giao hệ thống
 Hiệu chỉnh hệ thống

 Vận hành thử bằng số liệu giả để phát hiện sai
sót
 Đưa hệ thống vào khai thác thử nghiệm
 Đào tạo người sử dụng tại mỗi vị trí trong hệ
thống.
 Chuyển giao hệ thống
f. Giai đoạn bảo trì hệ thống
 Sửa đổi, khắc phục những thiếu sót của

hệ thống
 Làm cho hệ thống thích nghi hơn, thuận
tiện hơn trong sử dụng.
Quá trình xây dựng một HTTT có thể mô tả

theo sơ đồ dưới đây:
Sơ đồ mô tả quá trình phân tích và thiết kế một HTTT
LẬP KẾ HOẠCH
PHÂN TÍCH
THIẾT KẾ
THỰC HIỆN
CHUYỂN GIAO
BẢO TRÌ
Mô hình thác nước - Water Fall Model
Mô hình thác nước - Water Fall Model
Giai đoạn phân tích
Giai đoạn thiết kế
Giai đoạn mã hóa
Giai đoạn kiểm thử
Giai đoạn bảo trì
5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT
Xuất phát từ các nhu cầu:
 Cần có một mô hình hoặc một ngôn ngữ đặc tả

đơn giản nhưng đơn nghĩa để xác định những
yêu cầu trong mỗi giai đoạn phân tích.
 Cần có một mô hình hoặc một ngôn ngữ để đối
thoại với những người không chuyên tin học
trong hệ thống thông tin.
 Cần có một ngôn ngữ mô tả các mức quan niệm
khác nhau của hệ thống thông tin liên quan
đến chu kỳ sống của hệ thống.
1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT
a. Mức quan niệm:

1.Ý nghĩa:
Mô tả mục đích hệ thống thông tin và những ràng buộc
phải tôn trọng trong mối quan hệ với mục đích của hệ
thống. Các mô tả này phải độc lập với mọi giải pháp
cài đặt
2. Những đối tượng cần phải mô tả ở mức quan
niệm:
• Các đối tượng được sử dụng trong hệ thống.
• Các hiện tượng và các mối quan hệ thông tin giữa các đối
tượng, giữa các hệ thống con trong hệ thống và giữa hệ
thống với môi trường bên ngoài.
• Thứ tự công việc được thực hiện trong hệ thống.
• Các qui tắc biến đổi, công thức tính toán, thuật toán.

Có 3 loại quy tắc:
+ Qui tắc quản lý: qui định mục tiêu và ràng buộc của
hệ thống (thường là những quy định, luật lệ áp đặt từ
môi trường ngoài). Một cách để xem xét một quy tắc có
phải là quy tắc quản lý không là nếu hủy bỏ quy tắc
này thì
hệ thống có nguy cơ bị phá vỡ không?
+ Qui tắc tổ chức: qui tắc liên quan đến giải pháp
họat động của hệ thống.
+ Qui tắc kỹ thuật: qui tắc liên quan đến các yêu cầu
kỹ thuật để đảm bảo hệ thống có thể họat động được.
Ở mức quan niệm cần trả lời các câu hỏi: WHAT?
 Chức năng của hệ thống thông tin là gì?
 Hệ thống thông tin cần những yếu tố gì?
 Hệ thống có dữ liệu và những quy tắc quản lý gì?
b. Mức tổ chức:
 Mục đích: xác định các phương tiện, nhân lực,
máy móc, cách tổ chức để cung cấp các thông tin
cho
người sử dụng đúng thời hạn và đủ độ tin cậy.
 Tại mức này, cần trả lời các câu hỏi:
 Ai làm? (WHO?)
 Làm ở đâu? (WHERE?)
 Làm khi nào? (WHEN?)
 Thông tin ở mức tổ chức được mô tả theo giải pháp
CSDL và thực chất là quan hệ logic của chúng. Do đó,
c. Mức vật lý:

Mục
đích:
 Xác định cách thực hiện của hệ thống thông tin
trong một môi trường cài đặt nào đó
 Đây là mức ít trừu tượng nhất vì nó chính là hệ
thống có thể họat động và vận hành.
 Tại mức này, cần trả lời câu hỏi hệ thống hoạt
động như thế nào? (HOW?)
 Thông tin ở mức vật lý được mô tả với các cấu
trúc, giá mang và phương thức truy nhập.
1.6. CÁC CÁCH TIẾP CẬN TRONG PHÁT TRIỂN PHẦN MỀM
1. Cách tiếp cận theo hướng chức

năng
Đặc điểm:
 Dựa vào chức năng là chính
 Tập trung khảo sát chức năng, hành vi của hệ
thống
 Khi các chức năng của hệ thống đã được xác
định thì chúng khó thay đổi trong suốt quá trình
thiết kế
 Dữ liệu sẽ được xác định cấu trúc dựa vào các
chức năng
1.6.1 CÁCH TIẾP CẬN THEO HƯỚNG CHỨC NĂNG
Đặc điểm:
 Phân rã chức năng và làm mịn dần theo cách
tiếp cận Top/Down
 phân tách nhỏ các chức năng chính thành các
chức năng đơn giản hơn theo cách từ trên
xuống- nguyên lý chia để trị.
 Kết quả của việc phân rã là một BFD của hệ
thống
 Các đơn thể chức năng trao đổi với nhau bằng
cách truyền tham số hay sử dụng dữ liệu chung
Đặc điểm:
Bị ảnh hưởng bới các ngôn ngữ lập trình ALGOL,
Pascal, C
Các hàm của hệ thống phần mềm được xem như
tiêu chí cơ sở khi phân rã
 Tách chức năng khỏi dữ liệu
 Chức năng có hành vi
 Dữ liệu chứa thông tin bị các chức năng tác động
Phân tách top-down chia hệ thống thành các hàm
để chuyển sang mã trình, dữ liệu được gửi giữa
chúng.
Hệ thống quản lý thư viện
Quản lý bạn đọc quản lý tài liệu Theo dõi mượn Thống kê
trả
Dữ liệu chung Dữ liệu chung
Chức năng 1 Chức năng 2
Dữ liệu riêng Dữ liệu riêng

1.6.2 CÁCH TIẾP CẬN THEO HƯỚNG ĐỐI TƯỢNG
Đặc điểm:
 Đặt trọng tâm vào dữ liệu (thực thể)
 Xem hệ thống như là tập các thực thể, các đối
tượng
 Các lớp đối tượng trao đổi với nhau bằng
các thông điệp
 Tính mở và thích nghi của hệ thống cao
 Hỗ trợ sử dụng lại và cơ chế kế thừa
1.6.2 CÁCH TIẾP CẬN THEO HƯỚNG ĐỐI TƯỢNG
 Tiệm cận hướng đối tượng tập trung vào cả thông tin và
hành vi
 Cho khả năng xây dựng hệ thống mềm dẻo, “co dãn”
 Phương pháp này dựa trên các nguyên tắc sau
• Tính đóng gói
• Kế thừa
• Đa trị
1.6.3 NHẬN XÉT
Ưu điểm chính của phương pháp HĐT

 là cơ sở để kết hợp các đơn thể có thể sử dụng
lại thành hệ thống lớn hơn, tạo ra những sản
phẩm có chất lượng cao
 Qui ước truyền thông điệp giữa các đối tượng
đảm bảo cho việc mô tả các giao diện giữa các
đối tượng thành phần bên trong hệ thống và
những hệ thống bên ngoài trở nên dễ dàng hơn
 Nguyên lý bao gói, che giấu thông tin hỗ trợ cho
việc xây dựng những hệ thống thông tin an toàn.
1.6.3 NHẬN XÉT
Ưu điểm chính của phương pháp HĐT:

 Nguyên lý bao gói, che giấu thông tin hỗ trợ cho
việc xây dựng những hệ thống thông tin an toàn.
 Lập trình HĐT với kỹ thuật kế thừa cho phép dễ

dàng xác định các đơn thể và sử dụng ngay khi
chúng chưa thực hiện đầy đủ các chức năg (đơn
thể mở) và sau đó mở rộng được mà không làm
ảnh hưởng tới các đơn thể khác.
1.6.3 NHẬN XÉT
Ưu điểm chính của phương pháp HĐT (tt)

 Định hướng đối tượng cung cấp những công cụ,
môi trường mới, hiệu quả để phát triển phần
mềm theo hướng công nghiệp và hỗ trợ để
tận dụng được những khả năng kế thừa, sử
dụng lại ở phạm vi diện rộng để xây dựng được
những hệ thống phức tạp như: hệ thống động,
hệ thống thời gian thực, v,v.
 Xoá bỏ được hố ngăn cách giữa các pha phân
tích, thiết kế và cài đặt trong quá trình xây dựng
phần mềm.
Những hạn chế của phương pháp hướng CN
 Sản phẩm khó bảo trì
 Mọi chức năng đều chia sẻ khối dữ liệu lớn
 Các chức năng phải hiểu rõ dữ liệu được lưu trữ
thế nào
 Khi thay đổi cấu trúc dữ liệu kéo theo thay đổi mọi
hàm liên quan
 Tiến trình phát triển không ổn định
 Thay đổi yêu cầu kéo theo thay đổi các chức
năng
 Rất khó bảo toàn kiến trúc thiết kế ban đầu khi hệ
thống tiến hóa
Không hỗ trợ lập trình bằng ngôn ngữ hướng đối
HẾT CHƯƠNG 1
82
CHƯƠNG 2

THEO HƯỚNG CHỨC NĂNG
ANALYSIS AND DESIGN INFORMATION SYSTEMS

IN FUNCTIONAL-ORIENTED
Khoa CNTT-ĐHKH
HUẾ
83
NỘI DUNG
1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT
2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC

NĂNG
3. MÔ HÌNH QUAN NIỆM CỦA HTTT
4. MÔ HÌNH TỔ CHỨC CỦA HTTT
5. MÔ HÌNH VẬT LÝ CỦA HTTT
6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN

HỆ THỐNG
1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT
1. Mục đích:
Tiếp cận với nghiệp vụ chuyên môn, môi trường hoạt
động của hệ thống.
Tìm hiểu các chức năng, nhiệm vụ và cách hoạt
động của hệ thống.
Chỉ ra các ưu điểm của hệ thống cũ để kế thừa và
các khuyết điểm của hệ thống để nghiên cứu khắc
phục.
85
2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT
2.1.2. Nội dung khảo sát và đánh giá hiện trạng:
Thu thập và mô tả các quy tắc quản lý, tổ chức, kỹ
thuật.
Thu thập và tìm hiểu các chứng từ giao dịch. Mô tả
các luồng thông tin và tài liệu giao dịch.
Thống kê các phương tiện và tài nguyên đã và có
thể sử dụng.
Thu thập và tìm hiểu các ý kiến khen chê về HTTT
cũ và những yêu cầu, đòi hỏi về hệ thống tương lai.
 Lập hồ sơ tổng hợp về hiện trạng
86
2.1.3. Nghiên cứu các tài liệu

 Qua các tài liệu của hệ thống phân tích viên có thể
nắm được: các công việc, các chức năng, các quy tắc
làm việc.
 Các tài liệu nghiên cứu bao gồm:
Các văn bản pháp quy, quy định về chức năng,
nhiệm vụ của tổ chức và của mỗi điểm công tác.
Các văn bản pháp quy, quy định về tiêu chuẩn,
quy tắc, phương thức làm việc.
Các chủ trương chính sách mà tổ chức, mà nhà
nước đã ban hành.
 Các báo cáo, báo biểu, thống kê đã có.
87
Tóm lại, phải trả lời cho được các câu hỏi sau:
 Hệ thống đang làm gì?
 Gồm những công việc gì?
 Đang quản lý cái gì?
Những công việc trong hệ thống do ai làm? Làm ở
đâu? Khi nào làm?
Mỗi công việc được thực hiện như thế nào? Mỗi
công việc liên quan đến dữ liệu nào?
 Chu kỳ, tần suất, khối lượng công việc?
Đánh giá các công việc hiện tại: tầm quan trọng như
thế nào? Các thuận lợi, khó khăn? Nguyên nhân dẫn
đến khó khăn? 88
2.1.2. Các công việc sau khảo sát hiện trạng:
a. Xử lý sơ bộ kết quả khảo sát
 Làm rõ các chức năng của hệ thống
Xác định được các chức năng và dữ liệu của hệ
thống: như các đối tượng, các điểm công tác, các
hoạt động.
Đối với mỗi chức năng cần làm rõ: điều kiện khởi
động, kết quả thu được, thời gian thực hiện, tần số,
chu kỳ, các quy tắc phải tuân thủ.
89
 Rà soát lại dữ liệu:

 Tên dữ liệu: do người phân tích lựa chọn
 Định nghĩa về dữ liệu: mô tả bằng lời hoặc bằng
công thức
 Kiểu dữ liệu (số, chuỗi,...)
 Loại: là dữ liệu cơ sở hay dữ liệu được suy từ dữ
liệu khác.
 Ràng buộc về giá trị
90
b. Tổng hợp kết quả khảo sát

 Tổng hợp các xử lý
Mục đích là làm rõ các thiếu sót và sự rời rạc của
các yếu tố liên quan đến công việc khi phỏng vấn.
 Có hai cách tổng hợp các xử lý:
tổng hợp kết hợp với yếu tố tổ chức
tổng hợp tách rời các yếu tố tổ chức.
 Tổng hợp các dữ liệu
Mục tiêu là liệt kê ra tất cả các dữ liệu có liên quan
đến hệ thống nhằm xây dựng một từ điển dữ liệu
chung cho toàn nhóm phân tích.
91
c. Hợp thức hoá kết quả khảo sát

 Mục đích:
xác định tính đúng đắn của thông tin và dữ liệu
phản ánh yêu cầu thông tin của hệ thống
bảo đảm tính pháp lý của nó cho việc sử dụng sau
này.
 Hợp thức hoá kết quả khảo sát gồm các công
việc:
 Hoàn chỉnh và trình bày các dữ liệu thu được để người sử
dụng xem xét và cho ý kiến.
 Tổng hợp các tài liệu để các nhà quản lý và lãnh đạo
đánh giá và bổ sung.
Đề đạt thêm một số quy tắc mới (như các quy tắc về
an 92
sẽ đốitoàn
mặt hệ
vớithống,
nhữngcác
khóyêu
khăn
cầukhông lường
về nhân khi triển khai.
sự,...)
Giới thiệu một số nghiên cứu hiện trạng

a. Hệ thống thông tin "Quản lý kho hàng"
Một công ty sản xuất bánh kẹo, có nhiều kho để chứa
vật tư và hàng hoá:
 Kho nguyên liệu: chứa đường, bột, hương liệu,
bao bì,...
Kho nhiên liệu: chứa xăng, dầu, than
Kho phụ tùng: chứa các thiết bị thay thế
Kho thành phẩm: chứa bánh kẹo đã sản xuất
được
(Xem tiếp trong giáo trình)
....... 93
Giới thiệu một số nghiên cứu hiện trạng

a. Hệ thống thông tin "Quản lý Công chức"
Một cơ quan hành chính sự nghiệp cần tin học hoá
việc quản lý cán bộ công chức của cơ quan mình. Qua
nghiên cứu hiện trạng phân tích viên đã nắm được
các thông tin sau:
Mỗi công chức được cơ quan quản lý các thông tin
sau đây: Họ tên, đơn vị công tác, giới tính, ngày sinh,
nơi sinh, địa chỉ, dân tộc, tôn giáo, chính trị, trình độ
văn hóa, ngoại ngữ, loại hình đào tạo, cựu chiến binh,
ngày vào cơ quan, ngày vào biên chế, cha mẹ, vợ
chồng, con, khen thưởng, kỷ luật.
....... (Xem tiếp trong giáo trình) 94
2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG
1. Các mức độ mô tả chức năng

a. Mô tả vật lý :
Mô tả chức năng ở mức độ vật lý đòi hỏi phải nói rõ
mục đích và cách thực hiện của quá trình xử lý,
nghĩa là phải trả lời câu hỏi: làm gì? và làm như thế
nào?
b. Mô tả logic:
Mô tả chức năng ở mức độ logic lại đơn giản hơn,
chỉ cần trả lời đầy đủ câu hỏi làm gì? Nghĩa là chỉ
diễn tả mục đích, bản chất của quá trình xử lý mà
không cần quan tâm đến các yếu tố về thực hiện,
cài đặt như phương pháp, phương tiện, tác nhân,
thời điểm, thời gian,... 95
2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG
c. Mô tả đại thể và mô tả chi tiết:

 Ở mức độ đại thể
Một chức năng được mô tả dưới dạng hộp đen.
Nội dung bên trong hộp đen không được chỉ rõ mà
chỉ mô tả các thông tin vào và ra hộp đen đó.
 Ở mức độ chi tiết
Nội dung của quá trình xử lý phải được chỉ rõ hơn:
 Các chức năng con
 Các mối quan hệ thông tin và điều khiển giữa
những chức năng đó.
 Nếu một chức năng có nhiều chức năng con
thì
để mô tả chi tiết người phân tích phải phân rã các
chức năng con này thành nhiều mức. Các mức
này
năngđược
dướibiểu
đây.diễn qua biểu đồ phân cấp chức 96
2.2.2. Biểu đồ chức năng nghiệp vụ BFD

(Business Function Diagram)
BFD là một sơ đồ hình học dùng để mô tả sự phân
rã có thứ bậc các chức năng của hệ thống từ đại thể
đến chi tiết.
Mỗi nút trong biểu đồ là một chức năng, các chức
năng này có quan hệ bao hàm với nhau và chúng
được nối với nhau bằng các cung để tạo nên một cấu
trúc cây.
Ký hiệu: một chức năng được biểu diễn bởi một hình
chữ nhật hoặc một vòng tròn (SADT)
<Tên
<Tên chức năng> chức
năng> 97
Ví dụ: Biểu đồ chức năng nghiệp vụ của hệ thống thông

tin “quản lý doanh nghiệp”
Quản lý
Doanh nghiệp
Quản lý Quản lý Quản lý

Nhân sự Vật tư Tài chính
Tài sản Thiết Lương Kế

cố bị tiền toán
định
98
Ví dụ: BFD về “Quản lý trông giữ xe”

Quản lý trông giữ xe
1. Nhận xe 2. Trả xe 3. Giải quyết sự cố
1.1 Nhận dạng xe 3.1 Kiểm tra sổ gửi

2.1 Kiểm tra vé
1.2 Ktra chổ trống 2.2 Đối chiếu vé 3.2 Ktra hiện trường
1.3 Ghi vé xe 2.3 Thanh toán 3.3 Lập biên bản
1.4 Ghi số xe vào 2.4 Ghi số xe ra 3.4 Thanh toán sự cố
99
2.2.3. Mô hình hoá các tiến trình của hệ thống

a. Biểu đồ luồng dữ liệu DFD (Data Flow Diagram )
DFD là một sơ đồ hình học nhằm diễn tả các luồng dữ
liệu thông qua các chức năng của hệ thống.
Những hỗ trợ của DFD

 Xác định yêu cầu của người dùng.
 Lập kế hoạch và minh hoạ những phương án cho
phân tích viên và người dùng xem xét.
 Trao đổi giữa những phân tích viên và người dùng
trong hệ thống.
 Làm tài liệu đặc tả yêu cầu hình thức và đặc tả
thiết kế hệ thống. 100
b. Các thành phần của một DFD:
 Luồng dữ liệu (Data flow):
Một luồng dữ liệu là một tuyến truyền dẫn thông tin
vào hay ra một chức năng nào đó. Được dùng để mô
tả dữ liệu di chuyển từ vị trí này đến vị trí khác.
Ký hiệu:
Một luồng dữ liệu được mô tả bởi một mũi tên với
tên dữ liệu kèm theo, chiều của mũi tên chỉ hướng di
chuyển của dữ liệu. Tên của luồng dữ liệu thể hiện
trạng thái logic của thông tin chứ không phải dạng
vật lý của nó.
Phiếu nhập Nhập kho Thẻ kho
101
 Kho dữ liệu (Data store) – Tài liệu lưu trữ
Về mặt vật lý, kho dữ liệu là các tập tin dữ liệu
trong máy tính hoặc những tập tài liệu được lưu trữ
ở văn phòng.
Kho dữ liệu là các dữ liệu được lưu giữ trên giá
mang nó, vì vậy người ta thường lấy tên của vật
mang nó làm tên của kho dữ liệu.
 Ký hiệu:
Phiếu
Phiếu xuất
Phiếu xuất
xuất
102
 Tiến trình (Proccess):
 Là một công việc hoặc một hành động có tác động
lên dữ liệu làm cho chúng di chuyển, thay đổi hoặc
được phân phối.
 Chỉ được xem là một tiến trình trong DFD nếu
chúng nhận thông tin đầu vào và có thông tin đầu ra.
103
 Tác nhân ngoài (extenal entity):
 Là một cá nhân hoặc một tổ chức ở bên ngoài lĩnh
vực nghiên cứu của hệ thống.
 Tác nhân ngoài là phần sống còn của hệ thống, bởi
vì chúng là nguồn cung cấp thông tin cho hệ thống
và là nguyên nhân kích hoạt hệ thống.
 Ví dụ: một luồng dữ liệu là “Đơn đặt hàng” đến một
tác nhân ngoài là “Nhà cung cấp”.
Nhà cung cấp
Đơn đặt hàng
104
 Tác nhân ngoài (extenal entity):
 Là một cá nhân hoặc một tổ chức ở bên ngoài hệ
thống.
 Tác nhân trong (intenal entity):
 Là một cá nhân, chức năng hoặc một hệ thống con
của hệ thống.
 Ví dụ: một luồng dữ liệu là “Phiếu xuất/nhập” đến
một tác nhân trong là “Thủ kho”
Thủ kho
Phiếu nhập/xuất
105
c. Các chú ý khi xây dựng một DFD

 Dựa vào biểu đồ chức năng nghiệp vụ
Sử dụng BFD để xác định các tiến trình theo từng
mức cho DFD. Bởi vì BFD được thực hiện phân rã
thành các mức nên nó dùng để chỉ ra các mức tương
ứng trong DFD.
Tuy nhiên để kiểm tra tính đúng đắn của các thành
phần trong một DFD cần phải dựa vào các đặc trưng
dưới đây.
106
Tiến trình:
Không một tiến trình nào chỉ có thông tin vào mà
không có thông tin ra. Nếu một đối tượng nào đó mà
chỉ có thông tin vào mà không có thông tin ra thì đó có
thể là một tác nhân ngoài (đích-thu nhận thông tin).
Không một tiến trình nào chỉ có thông tin ra mà
không có thông tin vào. Nếu một đối tượng nào đó mà
chỉ có thông tin ra mà không có thông tin vào thì đó có
thể là một tác nhân trong (nguồn-phát sinh thông tin).
Thông tin vào của một tiến trình phải khác với thông
tin ra của tiến trình đó.
Tên một tiến trình phải duy nhất và là một mệnh đề
chỉ hành động. 107
Kho dữ liệu:
 Tên một kho dữ liệu phải là một mệnh đề danh từ.
Dữ liệu không thể di chuyển trực tiếp từ một kho dữ
liệu này đến một kho dữ liệu khác.
Không thể di chuyển trực tiếp dữ liệu từ một tác
nhân đến một kho dữ liệu.
Không thể di chuyển trực tiếp dữ liệu từ một kho dữ
liệu đến một tác nhân.
Tác nhân:
 Tên một tác nhân phải là một mệnh đề danh từ.
 Dữ liệu không thể di chuyển trực tiếp từ một tác
108
nhân này đến một tác nhân khác.
Luồng dữ liệu:
 Tên một luồng dữ liệu phải là một mệnh đề danh từ.
Một luồng dữ liệu chỉ có một hướng chỉ hướng di
chuyển của dữ liệu.
Một luồng dữ liệu không thể quay lui nơi nó vừa đi
khỏi.
Một luồng dữ liệu đi vào một kho có nghĩa là kho
được cập nhật dữ liệu.
Một luồng dữ liệu đi ra khỏi một kho có nghĩa là dữ
liệu được đọc từ kho.
109
d. Kỹ thuật phân mức trong DFD

Căn cứ vào việc phân rã chức năng của một BFD:
 Mô tả một DFD theo nhiều mức khác nhau.
 Mỗi mức được thể hiện trong một hoặc nhiều trang.
 Mức 0: còn gọi là mức bối cảnh
 Chỉ gồm một DFD, trong đó chỉ có một chức năng
duy nhất (chức năng tổng quát của hệ thống) trao
đổi các luồng thông tin với các tác nhân ngoài.
Tên của trang mức 0 là tên của hệ thống.
 Mức 1: còn gọi là mức đỉnh
 Chỉ gồm một DFD
110
2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG
Các mức 2,3,4,... mỗi mức gồm nhiều DFD được

thành lập như sau:
 Cứ mỗi chức năng ở mức trên, ta thành lập một
DFD ở mức dưới, gọi là biểu diễn DFD ở mức con.
 Phân rã chức năng đó thành nhiều chức năng
con
 Vẽ lại các luồng dữ liệu vào và ra chức năng trên,
nhưng bây giờ phải vào hoặc ra chức năng con thích
hợp.
 Nghiên cứu các quan hệ về dữ liệu giữa các chức
năng con, nhờ đó bổ sung các luồng dữ liệu nội bộ
hoặc các kho dữ liệu nội bộ.
 Các chức năng được đánh số theo ký pháp chấm
111
(.) để tiện theo dõi vệt triển khai từ trên xuống.
112
Tổng quát, có thể định nghĩa một cách quy nạp biểu
đồ luồng dữ liệu các mức như sau:
Biểu đồ luồng dữ liệu mức n là biểu đồ luồng dữ

liệu nhận được từ việc phân rã một tiến trình thuộc
biểu đồ luồng dữ liệu mức n-1.
Như vậy biểu đồ luồng dữ liệu ở mỗi mức là tập

hợp các DFD ở mức đó.
113
VÍ DỤ- Kỹ thuật phân mức
114
Mức 0:
 chức năng tổng quát của HT: “Quản lý tín dụng”.
 Tác nhân của hệ thống: “Khách vay”.
Trả lời đơn vay
Đơn vay
Khách vay QUẢN LÝ TÍN DỤNG
Nợ hoàn trả
DFD ở mức 0 (mức bối cảnh) 115

Mức 1
 Chức năng ở mức 0 được phân rã thành 2 chức năng con là
“Cho vay” và “Thu nợ”.
 Ngoài ba luồng dữ liệu đã có ở mức 0 phải được bảo toàn, thì
ta thấy luồng dữ liệu trao đổi giữa hai chức năng “Cho vay” và
“Thu nợ” không trực tiếp mà phải thông qua một kho dữ
liệu đó là “Sổ nợ”. Ta có DFD mức đỉnh như hình dưới đây.
Trả lời đơn vay
1. Cho vay
Khách vay Đơn vay Sổ nợ
2. Thu nợ
Nợ hoàn trả
116
DFD ở mức 1 (mức đỉnh)
Mức 2:
Chức năng “Cho vay” ở mức 1 được phân rã
thành 3 chức năng con là “Nhận đơn”, “Duyệt vay”
và “Trả lời đơn”;
Chức năng “Thu nợ” ở mức 1 được phân rã
thành 3 chức năng con là “Xác định kỳ hạn trả”,
“Xử lý nợ trả trong hạn” và “Xử lý nợ trả ngoài
hạn”.
Để bảo toàn các luồng dữ liệu vào/ra và thêm các
luồng dữ liệu nội bộ ta thành lập được hai DFD định
nghĩa cho hai chức năng 1 và 2 như sau:
117
Mức 2
Đơn đã
Đơn vay
kiểm tra
Khách vay 1.1 Nhận đơn 1.2 Duyệt vay
Đơn đã
duyệt
S
ổ
Từ chối vay
1.3 Trả lời đơn n

ợ
Đáp ứng vay
DFD ở mức 2 (định nghĩa chức năng 1: Chovay) 118

Mức 2 Nợ trả
trong hạn
2.2 Xử lý nợ
Nợ hoàn trả trong hạn
trả
Khách vay 2.1 Xác định

kỳ hạn trả Sổ nợ
2.3 Xử lý nợ
Nợ trả
ngoài hạn
trả ngoài hạn
DFD ở mức 2 (định nghĩa chức năng 2: Thu nợ)

119
2.3. MÔ HÌNH QUAN NIỆM CỦA HTTT
Mô hình quan niệm của một HTTT được thiết lập từ hai mô
hình liên quan đến nhau là mô hình quan niệm về dữ liệu
và mô hình quan niệm về xử lý.
a. Mô hình quan niệm về dữ liệu:
 là sự mô tả toàn bộ dữ liệu của hệ thống, những mô tả
này độc lập với các lựa chọn môi trường cài đặt
 là công cụ cho phép người phân tích thể hiện dữ liệu
của hệ thống ở mức quan niệm.
 Mô hình có thể mô tả bằng ngôn ngữ tự nhiên hoặc
bằng hình vẽ.
b. Mô hình quan niệm về xử lý:
 mô tả toàn bộ các quy tắc xử lý được áp dụng cho
dữ
liệu của hệ thống.
Mô hình quan niệm cũng là cơ sở để trao đổi giữa những
120
người phân tích thiết kế hệ thống.
1. Mô hình quan niệm về dữ liệu
Nhắc lại một số kiến thức cần thiết
 Mô hình thực thể-mối quan hệ (ER)
 Các tập thực thể
 Các mối quan hệ giữa các tập thực thể
 Các thuộc tính của các tập thực thể và các mối quan hệ:
thuộc tính đơn, phức hợp, đa trị
Các loại quan hệ giữa các tập thực thể (1-1, 1-n,
n-n, isa)
Chiều của mối quan hệ
 Mối quan hệ một chiều (đệ quy-phản xạ)
 Mối quan hệ hai chiều
 Mối quan hệ nhiều chiều
 Bản số
121
2. Một vài nhận xét để rà soát lại mô hình ER
a. Đối tượng nào có thể làm tập thực thể?
Một đối tượng có thể làm tập thực thể nếu nó
được tạo thành từ một lớp các cá thể tương ứng.
b.Yếu tố TT gì có thể làm thuộc tính cho một tập
thực thể?
Các thông tin đặc trưng để xác định các thực thể
trong một tập thực thể đều có thể làm thuộc tính
cho tập thực thể đó.
c. Loại bỏ các thuộc tính vô nghĩa
Loại bỏ các thông tin không bao giờ sử dụng
đến.
122
2.3.2 Một vài nhận xét để rà soát lại mô hình ER
d.Tính độc lập của các thuộc tính
Thuộc tính của một tập thực thể không được suy
từ những thuộc tính khác của tập thực thể đó.
123

Thuộc tính của một tập thực thể không được suy từ
những thuộc tính khác của tập thực thể đó.
e. Xác định thuộc tính khóa
Trong mỗi tập thực thể nên chọn khóa chỉ có
một thuộc tính để tiện việc xử lý.
Nếu trong tập thực thể không có một thuộc tính
nào để làm khóa thì nên áp đặt một thuộc tính
bên ngoài để làm khóa. Thông thường thuộc tính
áp đặt này có dạng:
Mã + <Tên tập thực thể>
124
Thuộc tính của một tập thực thể không được suy
từ những thuộc tính khác của tập thực thể đó.
f. Tách thuộc tính có dung lượng lớn
Nếu một thuộc tính của tập thực thể có nhiều giá
trị, mỗi giá trị chiếm một dung lượng lớn và lặp lại
nhiều lần thì nên tách thành một tập thực thể
riêng có tên là <tên thuộc tính> và có hai thuộc
tính là:
 Mã + <tên thuộc tính>
 Tên + <tên thuộc tính> 125
g. Xử lý một thuộc tính lặp nằm trong một tập thực thể
Nếu trong tập thực thể có thuộc tính lặp (đa trị) thì
tách thuộc tính này thành một tập thực thể có tên:
<tên thuộc tính đa trị> và có hai thuộc tính là:
• Mã + <tên thuộc tính> và
• Tên + <tên thuộc tính>
Ví dụ: một nhân viên có thể có nhiều sđt
126
h. Xử lý 1 nhóm thuộc tính lặp nằm trong 1 tập th.thể

Nếu trong một tập thực thể có một nhóm thuộc tính
lặp thì tách chúng (các thuộc tính lặp) thành một tập
thực thể riêng.
Tập thực thể này nhận các thuộc tính lặp làm
thuộc tính và nhận thuộc tính khóa của tập thực thể
gốc làm khóa.
 Ví dụ:
127
h. Các tập thực thể có mối quan hệ ISA
Khi một thuộc tính của tập thực thể mà chỉ có một số phần
tử có giá trị, nếu phần tử nào có giá trị thì có thêm một số
thuộc tính riêng của nó thì chuyển thành một tập thực thể
riêng có tên là <tên thuộc tính> và có thuộc tính là các thuộc
tính riêng của nó.
Tập thực thể gốc gọi là tập thực thể Cha, tập thực thể được
tách ra gọi là tập thực thể Con.
 Ví dụ
128
2.3.3 Cách mô tả mô hình quan niệm về dữ liệu
Mô hình quan niệm dữ liệu là mô hình liên hoàn các

tập thực thể và mối quan hệ của hệ thống.
Để mô tả mô hình quan niệm về dữ liệu của một
HTTT, cần mô tả thông tin theo các bước sau:
 B1: Mô tả toàn bộ các tập thực thể và các
thuộc tính
tương ứng của chúng.
B2: Mô tả toàn bộ các mối quan hệ. Ý nghĩa của mỗi
mối quan hệ và các thuộc tính tương ứng của chúng
(nếu có). Bản số của mỗi tập thực thể qua mối quan
hệ. Loại mối quan hệ: một chiều, hai chiều (1-1, 1-n,
n-n,
 B3:isa,...),
Vẽ mônhiều
hình chiều.
thực thể - mối quan hệ. 129
2.3.4 Mô hình quan niệm về xử lý
a. Mục đích:
Mô hình quan niệm xử lý nghiên cứu mặt động
của hệ thống thông tin, nhằm xác định hệ thống
gồm những chức năng gì, các chức năng đó liên hệ
với nhau như thế nào?
b. Một số thuật ngữ và khái niệm

a. Biến cố (event): một sự việc gây ra sự thay đổi
trạng thái của hệ thống. Một biến cố có thể xuất hiện
bên trong hay bên ngoài hệ thống, tạo phản ứng
cho hệ thống thông qua một qui tắc quản lý nào đó.
130
4. Mô hình quan niệm về xử lý
Phân loại biến cố :
Biến cố vào: biến cố tham gia vào việc kích hoạt
một công việc nào đó của hệ thống.
Biến cố ra: biến cố được sinh ra sau khi thực hiện
một hoặc nhiều công việc của hệ thống.
Biến cố trong: biến cố xảy ra bên trong hệ thống
để các hệ thống con trao đổi thông tin cho nhau.
Biến cố ngoài: biến cố đến từ môi trường bên
ngoài hệ thống.
Biến cố thời gian: biến cố gắn liền với thời gian,
có tính chu kỳ.
131
b. Công việc:
Là một xử lý nhỏ nhất mà hệ thống thực hiện khi
một biến cố trong hệ thống xuất hiện.
 Thông thường một công việc chưa đủ để xác
định được một chức năng hoặc một nhiệm vụ của
hệ thống.
 Ví dụ, công việc "Kiểm tra hàng nhập về" chưa
đủ điều kiện để thực hiện nhiệm vụ "nhập kho",
bởi vì nhiệm vụ này chỉ được hoàn tất sau khi các
công việc kiểm tra và làm phiếu nhập được thực
hiện xong.
Sau khi một công việc được thực hiện thì thông
thường một trong hai trạng thái sẽ xảy ra: thành
công (OK) và không thành công (⌐OK). Hai trạng
thái này sẽ kèm theo các biến cố ra tương ứng. 132
c. Điểm đợi
Thời điểm để đợi các biến cố xảy ra thì công việc mới
thực hiện được gọi là điểm đợi. Các biến cố này kích
hoạt công việc theo hai chế độ:
Chế độ AND: khi tất cả các biến cố tại điểm đợi
cùng xảy ra thì công việc mới được thực hiện.
Chế độ OR: khi một trong các biến cố tại điểm
đợi xảy ra thì công việc mới được thực hiện.
Ví dụ: Biến cố "sách đã cho mượn" được thực
hiện bởi công việc "CHO MƯỢN SÁCH" nếu tại
điểm đợi các biến cố xảy ra:
[(Độc giả yêu cầu)(Đủ tư cách độc giả)(có lệnh của
GĐ)]
(có 133
Mô tả một công việc, biến cố, điểm đợi
134
Chức năng của một hệ thống thông tin được
mô tả một cách tổng quát như sau:
135
Ví dụ, trong hệ thống thông tin “Quản lý kho hàng” Chức năng
“Bán hàng” sẽ bao gồm các công việc: kiểm tra tư cách khách
hàng, kiểm tra hàng tồn kho, viết phiếu xuất, thanh toán, xuất
kho.
136
137
2.4. MÔ HÌNH TỔ CHỨC CỦA HTTT
2.4.1. Khái niệm:
Mô hình tổ chức được thiết lập từ hai mô hình:
a. Mô hình tổ chức về dữ liệu:
Mô hình này được hình thành do sự chuyển đổi các
tập thực thể và các mối quan hệ trong mô hình ER.
Ở mức tổ chức thông tin được mô tả theo giải pháp
cơ sở dữ liệu và thực chất chính là quan hệ logic của
chúng, nên mức tổ chức còn được gọi mức logic.
b. Mô hình tổ chức về xử lý:
Mô tả về mặt tổ chức của các xử lý. Mô hình này trả
lời cho các câu hỏi: Ai?, Khi nào?, Ở đâu?, Như thế
nào? 138
2.4. MÔ HÌNH TỔ CHỨC CỦA HTTT
Nhắc lại một số kiến thức về CSDL quan hệ
 Cơ sở khoa học – Nền tảng - Lịch sử
 Quan hệ
 Lược đồ quan hệ
 Phụ thuộc hàm
 Phép tách:
Bảo toàn thông tin
Bảo toàn phụ thuộc hàm
 Lý thuyết chuẩn hóa:
1NF, 2NF, 3NF, BCNF
139
2.4.2. Mô hình tổ chức dữ liệu
Các quy tắc chuyển đổi từ mô hình ER sang mô hình
dữ liệu quan hệ
a. Chuyển một tập thực thể thành quan hệ
Quy tắc 1: Mỗi tập thực thể trong mô hình quan niệm
dữ liệu được chuyển thành một quan hệ: có tên là
tên của tập thực thể; có thuộc tính và khóa là thuộc
tính và khóa của tập thực thể và có thể có thêm
thuộc tính là khóa ngoại nếu có.
Nhân viên
Chuyển thành
-Mã NV
-Họ tên
-Ngày sinh
Nhân viên (Mã NV , Họ tên, Ngày sinh, Mã đơn vị)
-Mã đơn vị 140
Quy tắc 2: Tập thực thể tham gia vào mối quan hệ hai
ngôi có cặp bản số (1,1) ----- (1,n) thì quan hệ sinh ra
bởi tập thực thể ở nhánh (1,1) sẽ nhận khóa của tập
thực thể ở nhánh (1,n) làm khóa ngoại
Nhân viên
(1,1) Thuộc (1,n) Đơn vị Chuyển thành
-Mã NV -Mã đơn vị
-Họ Tên -Tên đơn vị
-Ngày Sinh
Nhân viên (Mã NV , Họ Tên, Ngày Sinh, Mã đơn vị)

Đơn vị (Mã đơn vị, Tên đơn vị)
2. Mô hình tổ chức dữ liệu
Quy tắc 3: Chuyển tập thực thể trong mối quan hệ ISA
Tập thực thể con trong mối quan hệ ISA của mô
hình quan niệm dữ liệu được chuyển thành một quan
hệ, với tên là tên của tập thực thể con, có các thuộc
tính là thuộc tính của tập thực thể con và nhận khóa
của tập thực thể cha làm khóa.
Trường hợp xảy ra quan hệ ISA trong một quan hệ

ISA thì lược đồ quan hệ sinh ra từ tập thực thể "cháu"
nhận thuộc tính khóa của tập thực thể "Ông" làm
thuộc tính khóa.
Quy tắc 3: Chuyển tập thực thể trong mối quan hệ ISA
Ví dụ:
Bộ đội n 1 Nhân viên 1 n Đảng viên

is is
-Ngày NN -Mã NV -Ngày VĐ
a a
-Ngày XN -Họ NV -Ngày CT
-Tên NV
-Ngày sinh
Chuyển thành
Đảng viên (Mã NV,Ngày VĐ, Ngày CT)

Bộ đội (Mã NV,Ngày NN, Ngày
Nhân viên XN)
(Mã NV,Họ NV, Tên NV,
Ngày sinh)
a. Chuyển một mối quan hệ thành quan hệ
Quy tắc 4:
i. Mối quan hệ hai ngôi không có thuộc tính riêng, có
cặp bản số (1,1) ---- (1,n) thì không chuyển thành một
quan hệ.
Huyện Tỉnh
(1,1) H-T (1,n)
-Mã huyện -Mã tỉnh
-Tên huyện -Tên tỉnh
Chuyển thành
Huyện (Mã huyện, Tên huyện, Mã tỉnh)

Tỉnh (Mã tỉnh,Tên tỉnh)
Quy tắc 4:
ii. Mối quan hệ hai ngôi có thuộc tính riêng, có cặp bản
số (1,1) ---- (1,n) thì chuyển thành một quan hệ, có
tên là tên của mối quan hệ, có thuộc tính là thuộc tính
của mối quan hệ và có khoá là khoá của các tập thực
thể tham gia vào mối quan hệ.
Cán bộ (1,1) Thuộc
Đơn vị
(1,n)
-Mã CB - Năm -Mã ĐV
-Tên CB -Tên ĐV
-HSL chuyển thành
Cán bộ (Mã CB, Tên CB, HSL)

Đơn vị (Mã ĐV, Tên ĐV)
Thuộc (Mã CB, Mã ĐV, Năm)
2.Mô hình tổ chức dữ liệu
Quy tắc 5:
Mối quan hệ hai ngôi có cặp bản số (1,n) ---- (1,n) hay
mối quan hệ nhiều hơn hai ngôi (không phân biệt bản
số) được chuyển thành một quan hệ:
 có tên là tên của mối quan hệ
có khóa là khóa của tất cả các tập thực thể tham gia
vào mối quan hệ
 có thuộc tính là các thuộc tính riêng của nó (nếu
có).
2.Mô hình tổ chức dữ liệu
Quy tắc 5:
Mối quan hệ hai ngôi có cặp bản số (1,n) ---- (1,n) hay
mối quan hệ nhiều hơn hai ngôi (không phân biệt bản
số) được chuyển thành một quan hệ:
 có tên là tên của mối quan hệ
có khóa là khóa của tất cả các tập thực thể tham gia
vào mối quan hệ
 có thuộc tính là các thuộc tính riêng của nó (nếu
có).
Định nghĩa
Mô hình tổ chức dữ liệu, còn gọi là mô hình cơ sở dữ
liệu, là toàn bộ các quan hệ của bài toán được chuyển
đổi từ mô hình quan niệm dữ liệu theo các quy tắc
chuyển đổi trên.
Ví dụ:
Mô hình tổ chức dữ liệu của HTTT “Quản lý kho hàng”
Mô tả dưới dạng bảng

Nhắc lại các dạng chuẩn
a. Mục đích của chuẩn hóa
Chuẩn hóa dữ liệu là một quá trình chuyển một
cấu trúc dữ liệu phức hợp thành các cấu trúc dữ
liệu đơn giản, rõ ràng và nhằm các mục đích sau:
 Tối ưu hóa lưu trữ
 Tránh dư thừa dữ liệu
 Thông tin nhất quán
 Đảm bảo các phụ thuộc dữ liệu theo đúng mô
hình mà vẫn không làm tổn thất thông tin.
•Dạng chuẩn 1 (1NF)
Một lược đồ quan hệ được gọi là ở dạng chuẩn 1 nếu
mọi thuộc tính của nó là thuộc tính đơn (các thuộc tính
không có nhu cầu phân rã trong các xử lý).
Ví dụ: lược đồ quan hệ dưới đây không phải ở 1NF:
SINHVIEN(MSSV, HTEN, QQUAN, SOTHICH)
Một lược đồ quan hệ được gọi là ở dạng chuẩn 2 nếu
nó là dạng chuẩn 1 và mọi thuộc tính không khoá
phải phụ thuộc hàm đầy đủ vào khoá chính.
Ví dụ: lược đồ quan hệ R(ABCD) với tập phụ thuộc
hàm F={AB  C, B  D, C  D} không phải ở 2NF
vì D không phụ thuộc hàm đầy đủ vào khóa.
Phụ thuộc hàm bắc cầu: cho lược đồ quan hệ R và
tập phụ thuộc hàm F xác định trên R; X, Y R, AR.
Nếu ta có: X  Y , Y X, Y A và AXY thì ta nói A
phụ thuộc hàm bắc cầu vào X. A được gọi là thuộc
tính phụ thuộc bắc cầu, Y là các thuộc tính cầu.
Định nghĩa 1: Lược đồ quan hệ R với tập phụ thuộc
hàm F xác định trên R được gọi là ở 3NF nếu nó là
2NF và không tồn tại thuộc tính không khoá phụ thuộc
hàm bắc cầu vào khoá.
Định nghĩa 2: Lược đồ quan hệ R với tập phụ thuộc
hàm F xác định trên R được gọi là ở 3NF nếu mọi phụ
thuộc hàm XA đúng trong R, AX thì X phải là siêu
3. Chuẩn hoá và kiểm tra lại mô hình ER
a. Trường hợp LĐQH chưa là 1NF:

Khi một LĐQH chưa là 1NF thì nó có chứa thuộc tính
lặp hoặc thuộc tính phức hợp.
Nếu lược đồ có thuộc tính lặp thì ta tách thành hai
lược đồ con:
LĐ quan hệ 1: gồm các thuộc tính lặp và khoá chính
xác định chúng.
LĐ quan hệ 2: gồm các thuộc tính còn lại (đơn) và
khoá chính.
Ví dụ
2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER
1NF
0NF SỐPHIẾUXUẤT
SỐPHIẾUXUẤT NGÀY
NGÀY NGƯỜI MUA
NGƯỜI MUA ĐẠILÝ
ĐẠILÝ SỐCMND
SỐCMND ĐỊACHỈ
ĐỊACHỈ MỤCĐÍCH
MỤCĐÍCH
TÊNHÀNG (lặp) 1NF
MÃHÀNG (lặp)
SỐPHIẾUXUẤT
ĐƠNVỊ (lặp)
TÊNHÀNG
ĐƠNGIÁ (lặp)
MÃHÀNG
SỐLƯỢNG
(lặp) ĐƠNVỊ
ĐƠNGIÁ
SỐLƯỢN
G 156

Khi một LĐQH là 1NF nhưng không là 2NF thì
trong quan hệ sẽ tồn tại thuộc tính không khoá phụ
thuộc vào một bộ phận của khoá chính.
Khi đó ta tách thành hai lược đồ quan hệ con:
LĐ quan hệ 1: gồm các thuộc tính phụ thuộc không
đầy đủ vào khoá chính và phần khoá bị phụ thuộc.
LĐ quan hệ 2: gồm các thuộc tính còn lại và khoá
chính
Ví dụ
2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER
2NF
SỐPHIẾUXUẤT
1NF NGÀY
SỐPHIẾUXUẤT NGƯỜI MUA
NGÀY ĐẠILÝ
NGƯỜI MUA SỐCMND
ĐẠILÝ ĐỊACHỈ
SỐCMND MỤCĐÍCH
ĐỊACHỈ
MỤCĐÍCH 2NF
SỐPHIẾUXUẤT
1NF MẪHÀNG
SỐPHIẾUXUẤT SỐLƯỢNG
TÊNHÀNG
MẪHÀNG 2NF
ĐƠNVỊ MẪHÀNG
ĐƠNGIÁ TÊNHÀNG
SỐLƯỢNG ĐƠNVỊ
ĐƠNGIÁ 158

Khi một quan hệ là 2NF nhưng không là 3NF thì
sẽ tồn tại phụ thuộc hàm bắc cầu trong quan hệ.
Khi đó ta tách thành hai lược đồ quan hệ con:
LĐ quan hệ 1: gồm các thuộc tính phụ thuộc bắc
cầu và thuộc tính cầu.
LĐ quan hệ 2: gồm các thuộc tính còn lại và thuộc
tính cầu.
Ví dụ
3NF
2NF SỐPHIẾUXUẤT
SỐPHIẾUXUẤT NGÀY
NGÀY SỐ
NGƯỜI MUA CMND
ĐẠILÝ MỤCĐÍCH
SỐCMND
ĐỊACHỈ NGƯỜI MUA 3
MỤCĐÍCH ĐẠILÝNF
SỐCMND
2NF ĐỊACHỈ
SỐPHIẾUXUẤT
3NF
MẪHÀNG
SỐLƯỢNG SỐPHIẾUXUẤT
MẪHÀNG
2NF SỐLƯỢNG
MẪHÀNG 3NF
TÊNHÀNG
MẪHÀNG
ĐƠNVỊ
TÊNHÀNG
ĐƠNGIÁ
ĐƠNVỊ 160
ĐƠNGIÁ
Quá trình chuẩn hoá có thể mô tả bằng sơ đồ dưới đây.
Quan hệ với các

thuộc tính lặp
Tách các thuộc tính lặp
Chuẩn hoá
thành 1NF
Tách các phụ thuộc
hàm bộ phận
Chuẩn hoá
thành
2NF Tách các phụ thuộc
hàm bắc cầu
Chuẩn hoá
161
thành
Ví dụ: chuẩn hóa một chứng từ nhập trong HTTT “Quản lý kho
hàng”
Ví0NF chứng từ hập trong2NF
dụ: chuẩn hóa một 1NF HTTT 3NF
uản lý kho
SỐPHIẾUNHẬP nSỐPHIẾUNHẬP “Q
SỐPHIẾUNHẬP hàng”
SỐPHIẾUNHẬP
MÃSỐ_NCC MÃSỐ_NCC MÃSỐ_NCC MÃSỐ_NCC
TÊN_NCC TÊN_NCC TÊN_NCC NGÀY
ĐỊACHỈ_NCC ĐỊACHỈ_NCC ĐỊACHỈ_NCC
NGÀY NGÀY NGÀY 3NF
TÊNHÀNG (lặp) MÃSỐ_NCC
MẪHÀNG (lặp) 1NF 2NF TÊN_NCC
ĐƠNVỊTÍNH (lặp) SỐPHIẾUNHẬP SỐPHIẾUNHẬP ĐỊACHỈ_NCC
ĐƠNGIÁ (lặp) TÊNHÀNG MẪHÀNG
SỐLƯỢNG (lặp) MẪHÀNG SỐLƯỢNG 3NF
ĐƠNVỊTÍNH SỐPHIẾUNHẬP
ĐƠNGIÁ 2NF MẪHÀNG
SỐLƯỢNG MẪHÀNG SỐLƯỢNG
TÊNHÀNG
ĐƠNVỊTÍ 3NF
NH MẪHÀNG
ĐƠNGIÁ TÊNHÀNG
ĐƠNVỊTÍNH
ĐƠNGIÁ
Chuẩn hóa chứng từ nhập 163
Chuyển sang mô hình dữ liệu quan hệ
164
2.4.4. Mô hình tổ chức về xử lý
Mục đích:
Mô hình tổ chức về xử lý nhằm xác định rõ các công việc do
ai làm, làm ở đâu, làm khi nào, làm theo phương thức nào?
Các khái niệm
a. Nơi làm việc:
• một hệ thống thông tin quản lý được chia thành nhiều bộ
phận, mỗi bộ phận được gọi là một nơi làm việc.
• Nơi làm việc bao gồm: vị trí, con người, trang thiết bị tại
nơi làm việc.
b. Phương thức xử lý:
là cách thức thực hiện công việc. Mỗi công việc có thể được
thực hiện bởi một trong ba phương thức xử lý:
• Xử lý thủ công: do con người trực tiếp thao tác trên đối
tượng.
• Xử lý tự động
• Xử lý tương tác người -máy
c. Biến cố ở mức tổ chức:

là biến cố của hệ thống nhưng được đặt ở nơi phát
sinh ra nó hay là nơi nhận biết nó. Ở mức tổ chức,
một biến cố còn phải quan tâm:
• Thời gian phản ứng: là thời gian tối đa được chờ
đợi từ khi biến cố xuất hiện cho đến khi công việc
được kích hoạt.
• Tần suất: số lần xuất hiện lại biến cố trong một đơn
vị thời gian.
• Chu kỳ: là khoảng thời gian mà biến cố sẽ xuất
hiện
trở lại
d. Bảng công việc

 Ở mức tổ chức công việc phải được xác định rõ:
nơi làm việc, phương thức làm việc, tần suất và
chu kỳ của nó.
 Các đặc trưng này được thể hiện trong bảng
công việc sau đây:
2.5. MÔ HÌNH VẬT LÝ
 Mô hình vật lý sẽ là thể hiện cụ thể trên máy tính

cho giải pháp dữ liệu đã được lựa chọn. Nó được
thể hiện ở hai khía cạnh: cấu trúc dữ liệu cụ thể và
phương thức truy nhập.
 Cũng như các mô hình đã khảo sát ở trước, mô
hình vật lý được mô tả qua mô hình vật lý về
dữ liệu và mô hình vật lý về xử lý.
 Thiết kế cơ sở dữ liệu vật lý là quá trình ánh xạ cấu
trúc dữ liệu logic được xây dựng ở mô hình tổ
chức dữ liệu vào mô hình bên trong hệ thống.
2.5. MÔ HÌNH VẬT LÝ
1.Mô hình vật lý về dữ liệu

Thiết kế cơ sở dữ liệu vật lý
Đa số các hệ thống thông tin hiện nay đều sử dụng
một hệ quản trị cơ sở dữ liệu nào đó để tạo ra cơ sở
dữ liệu cho hệ thống.
Thiết kế cơ sở dữ liệu vật lý bao gồm các bước sau:
Thiết kế cơ sở dữ liệu: mô tả các file dữ liệu, file
chỉ mục,... sẽ được truy cập trong bộ nhớ máy tính
như thế nào.
Thiết kế hệ thống và cấu trúc chương trình: mô tả
các chương trình và các mô đun chương trình khác
nhau tương ứng với sơ đồ luồng dữ liệu và những
yêu cầu đặt ra trong các bước phân tích trước.
2.5.1. Mô hình vật lý về dữ liệu
Thiết kế cơ sở dữ liệu
a. Thiết kế các trường
Các yêu cầu về việc thiết kế các trường
Tiết kiệm không gian nhớ
Biểu diễn được mọi giá trị có thể
Cài đặt các ràng buộc toàn vẹn của dữ liệu
Đặt giá trị mặc định (Default) để giảm
thiểu thời gian nhập dữ liệu
Chọn kiểu dữ liệu và độ rộng của trường
Khai báo độ rộng vừa đủ
Chọn đúng kiểu dữ liệu
Không làm phức tạp cấu trúc dữ liệu của hệ
thống.
a. Thiết kế các trường

Các yêu cầu về việc thiết kế các trường
 Tiết kiệm không gian nhớ
 Biểu diễn được mọi giá trị có thể
 Cài đặt các ràng buộc toàn vẹn của dữ liệu
 Đặt giá trị mặc định (Default) để giảm thiểu
thời gian nhập dữ liệu
Chọn kiểu dữ liệu và độ rộng của trường
 Khai báo độ rộng vừa đủ
 Chọn đúng kiểu dữ liệu
 Không làm phức tạp cấu trúc dữ liệu của hệ
thống.
b. Thiết kế các file
File giao dịch ( transaction file): là file dữ liệu tạm
thời phục vụ cho các hoạt động hằng ngày của tổ
chức. File này thường được thiết kế để phục vụ việc
xử lý nhanh các tình huống có thể xảy ra.
File làm việc (work file): file tạm thời để lưu kết quả
trung gian, file này tự động xoá đi khi không cần thiết.
File bảo vệ (protection file): file được thiết kế để lưu
trữ các file khác nhau có nguy cơ bị sai hỏng trong quá
trình làm việc.
File lịch sử (history file): file chứa những dữ liệu cũ
hiện không sử dụng, nhưng có thể sử dụng để làm
một việc gì đó khi cần thiết.
c. Một ví dụ về thiết kế file dữ liệu
Trong hệ thống thông tin “Quản lý kho hàng ” chúng ta
đã có mô hình tổ chức dữ liệu của hệ thống là các
quan hệ sau:
2.5.2. Mô hình vật lý về xử lý
a. Mục đích:
Trả lời cho câu hỏi cuối cùng là: các công việc hoạt
động như thế nào?
 Từ mô hình tổ chức xử lý đã có, người phân tích
sẽ
tiến hành xem xét, biến các chức năng, công việc
thành các đơn vị chương trình.
 Ứng với mỗi đơn vị chương trình này người
phân
tích phải viết một đặc tả chi tiết để chuẩn bị cho việc
lập trình.
b. Mô đun xử lý
Mô đun xử lý là thể hiện các công việc có liên quan
với nhau và được thực hiện liền mạch nhằm thực hiện
một chức năng nào đó.
Thông thường một mô đun xử lý thể hiện một công
việc có bản chất là cập nhật hoặc tra cứu dữ liệu và
thao tác trên một nhóm dữ liệu nhỏ.
Ví dụ, Chức năng làm phiếu xuất kho sẽ bao gồm các
mô đun sau:
Tra cứu danh sách các đại lý để kiểm tra khách hàng
Kiểm tra hàng tồn kho
Lấy yêu cầu để lập phiếu xuất và cập nhật tồn kho
2.5.2. Mô hình vật lý về xử lý ...
c. Phân rã mô đun
Mục đích:
Để dễ dàng trong việc mã hoá, cài đặt chương trình
và sửa chữa
Phân rã mô đun nhỏ đến một mức nào đó có thể
xuất hiện các mô đun chung, điều này sẽ giảm nhẹ
công sức lập trình sau này
Phân rã mô đun cũng gợi ra giao diện chọn chức
năng theo kiểu thực đơn trong chương trình tổng thể
d. Sơ đồ phân rã chức năng

Một mô đun có thể phân rã thành nhiều mô đun con.
Mô đun con không thể phân rã thêm được nữa được
gọi là mô đun sơ cấp.
Việc phân rã này phải bảo đảm mối liên hệ giữa mô
đun lớn với các mô đun con...
Dùng sơ đồ phân rã chức năng để mô tả việc phân
rã:
d. Sơ đồ tổng thể phân rã chức năng

Dựa trên kết quả phân rã mô đun, người phân tích
phải lên một sơ đồ tổng thể các chức năng để hướng
đến cấu trúc hoá chương trình.
Hiện nay có một vài quan điểm về việc gộp các mô
đun thành từng nhóm chức năng trong chương
trình.
 Gộp các mô đun theo hướng đối tượng: nhóm các chức
năng theo dữ liệu hoặc theo tập thực thể
 Gộp các mô đun theo hướng chức năng: Gộp theo sự kiện
là gộp theo hoạt động của hệ thống
 Gộp các mô đun theo sự tiện lợi: gộp các mô đun theo
tiêu chuẩn tiện dụng hoặc theo người sử dụng cụ thể hoặc
Gộp các mô đun theo hướng đối tượng:
ĐÀO TẠO SINH VIÊN CẬP NHẬT LÝ LỊCH SINH VIÊN
CẬP NHẬT ĐIỂM THI
THÔNG KÊ KẾT QUẢ HỌC TẬP
GIÁO VIÊN CẬP NHẬT LÝ LỊCH GIÁO VIÊN
GHI NHẬN KHỐI LƯỢNG GDẠY
THÔNG KÊ GIẢNG DẠY
MÔN HỌC CẬP NHẬP MÔN HỌC
LẬP CHƯƠNG TRÌNH ĐÀO TẠO
PHÂN CÔNG GIẢNG DẠY
Gộp các chức năng theo đối tượng

Gộp các mô đun theo hướng chức năng:
QUẢN LÝ KHO NHẬP HÀNG CẬP NHẬT SỐ LIỆU, CẬP NHẬT PHIẾU
NHẬP, CẬP NHẬT TỒN KHO
IN PHIẾU NHẬP
XUẤT HÀNG CẬP NHẬT SỐ LIỆU, CẬP NHẬT PHIẾU

XUẤT, CẬP NHẬT TỒN KHO
IN PHIẾU XUẤT
BÁO CÁO BÁO CÁO TỒN KHO
CÂN ĐỐI KHO
Gộp các chức năng theo hướng chức năng

Gộp các mô đun theo mạch công việc
Gộp các chức năng theo mạch công việc

e. Mô tả các mô đun
Sau khi phân rã các mô đun, người phân tích phải
chuyển giao các kết quả phân tích thiết kế cho người
lập trình để chuẩn bị cài đặt.
Các mô đun này phải được mô tả một cách chi tiết

thông qua các biểu đồ được gọi là IPO Chart như sau:
e. Mô tả các mô đun
2.6. THIẾT KẾ GIAO DIỆN CỦA HỆ THỐNG
2.6.1. Mục đích

Thiết kế môi trường giao tiếp giữa người sử dụng và
hệ thống, thoả mãn điều kiện:
Dễ sử dụng: Giao diện dễ sử dụng ngay cả với
những người không có kinh nghiệm.
Dễ học: Các chức năng gần gũi với tư duy của người
sử dụng để họ có thể nắm bắt dễ dàng nhanh chóng.
Tốc độ thao tác: Giao diện không đòi hỏi các thao tác
phức tạp hay dài dòng, hỗ trợ các phím tắt, phím
nóng.
Dễ phát triển: Giao diện được xây dựng dễ dàng, sẵn
sàng đáp ứng các yêu cầu thay đổi của người sử
2. Các loại giao diện

Hộp hội thoại: Là các giao diện phục vụ cho việc
kiểm soát hệ thống, trao đổi thông tin giữa người sử
dụng và hệ thống, kiểm tra quyền truy nhập (Tên, mật
khẩu), các hướng dẫn sử dụng hệ thống, các thông
báo lỗi sử dụng hay lỗi hệ thống nếu có...
Màn hình nhập dữ liệu: là các khung nhập liệu cho
phép người sử dụng tiến hành nhập dữ liệu cho hệ
thống hay cung cấp thông tin cho việc tìm kiếm dữ
liệu, đưa ra các báo cáo theo yêu cầu.
Màn hình báo cáo: là các biểu mẫu hiển thị các
thông tin được thu thập và tổng hợp theo yêu cầu của
người sử dụng.
3. Các nguyên tắc chung khi thiết kế giao diện

Thông tin phản hồi: Luôn cung cấp thông tin phản
hồi về công việc đang tiến hành.
Thông tin trạng thái: cung cấp cho người sử dụng
thông tin về trạng thái của hệ thống.
Công việc tối thiểu: Hạn chế tối đa sự cố gắng
không cần thiết của người sử dụng.
Trợ giúp: Sẵn sàng cung cấp các trợ giúp khi người
sử dụng cần.
Dễ dàng thoát ra: Cho phép người sử dụng thoát ra
khỏi hộp thoại dễ dàng bằng các thao tác quen thuộc.
Làm lại: Cho phép huỷ bỏ các thao tác đã tiến hành,
tăng khả năng thứ lỗi của chương trình.
2.7. THIẾT KẾ BÁO BIỂU
 Hình thức tài liệu xuất: Đĩa, màn hình, giấy in,..
 Dạng tài liệu xuất
Có cấu trúc: Bảng biểu, phiếu
Không có cấu trúc: Trả lời theo nhu cầu
 Yêu cầu đối với tài liệu xuất

Đầy đủ, chính xác
Dễ hiểu, dễ đọc
Kích thước tài liệu phải phù hợp, các mục phải bố
trí hợp lý.
được người sử dụng đồng ý
2.7. THIẾT KẾ BÁO BIỂU
 Các hình thức xuất tài liệu
Khung in sẵn
Không có khung in sẵn
 Cách trình bày một tài liệu: gồm 3 phần
Phần đầu: Các tiêu đề
Phần thân: Chứa nội dung cơ bản thường được
gom thành nhóm và có mối liên hệ logic với nhau
Phần cuối: ngày tháng, các chữ ký nếu có
 Có hai loại đưa ra
Đơn chiếc
Tập thể
2.8. THIẾT KẾ AN TOÀN HỆ THỐNG
1. Thiết kế kiểm soát:

Mục đích: nhằm hạn chế các lỗi sau:
 Lỗi từ các thông tin thu thập
 Lỗi do các sự cố kỹ thuật gây ra
 Sự thâm nhập trái phép của người trong và ngoài
hệ thống.
 Rủi ro về môi trường như: cháy, bão lụt,...
 Đề xuất các biện pháp nhằm đảm bảo:
 Tính chính xác
 Tính an toàn
 Tính riêng tư
2.7.2 Kiểm soát các xâm phạm từ phía con người

a. Xác định những điểm hở của hệ thống:
Điểm hở của hệ thống là điểm mà tại đó thông tin
của hệ thống có khả năng bị truy cập trái phép, bị sửa
đổi, lấy cắp, thậm chí phá huỷ thông tin, có thể gây
thiệt hại lớn cho cơ quan chủ quản hệ thống.
 Trong một hệ thống các điểm hở có thể là:
Luồng dữ liệu đi và đến tác nhân của hệ thống
Luồng dữ liệu cắt ngang giữa phần thực hiện bằng
máy tính và phần thực hiện thủ công.
Các kho dữ liệu hoặc các tệp.
Các đường truyền trên mạng (đối với hệ phân
tán),
...
b. Các biện pháp phòng ngừa, khắc phục:

 Bảo mật vật lý: khoá, chuông báo động
Nhận dạng nhân sự
Mật khẩu
Tạo mật mã: mã hoá dữ liệu sang dạng mã không
hiểu được. Người hiểu được phải có quy tắc giải mã.
Bảo mật bằng gọi lại: sự truy nhập thực hiện một
cách gián tiếp, qua một trạm kiểm soát, tương tự như
gọi điện thoại qua tổng đài, OTP.
 Phân biệt riêng tư
Gán cho mỗi loại người dùng một số quyền truy
nhập nhất định.
Cho phép một số người dùng được phép uỷ quyền
tức giao quyền truy nhập cho người khác.
HẾT CHƯƠNG 2
195
CHƯƠNG 3

THEO HƯỚNG ĐỐI TƯỢNG
ANALYSIS AND DESIGN INFORMATION SYSTEMS

IN OBJECT ORIENTED
Khoa CNTT-ĐHKH
HUẾ
196
nmhan2005@yahoo.com
NỘI DUNG
3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM

HƯỚNG ĐỐI TƯỢNG
2. PHÂN TÍCH YÊU CẦU HỆ THỐNG
3. ĐẶC TẢ CÁC YÊU CẦU CỦA HT
4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
5. CÁC NHÓM MẪU THIẾT KẾ
6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN

HỆ THỐNG
3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT
Nhận xét:
Quá trình xây dựng một sản phẩm phần mềm hoặc
nâng cấp một sản phẩm đã có được gọi là quá trình
phát triển phần mềm (Software Development Process).
Quá trình phát triển một phần mềm là quá trình xác
định:
 làm cái gì (WHAT?),
 làm ở đâu (WHERE?)
 làm khi nào (WHEN?)
 làm như thế nào (HOW?).
198
3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT
Có 5 bước chính cần thực hiện trong quá trình phát
triển phần mềm theo hướng đối tượng:
1. Nghiên cứu hiện trạng và xác định các yêu
cầu
2. Phân tích hệ thống
3. Thiết kế hệ thống
4. Lập trình và kiểm thử hệ thống
5. Vận hành và bảo trì hệ thống.
199
3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ...
3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Từ các yêu cầu của khách hàng chúng ta xác định
được mục tiêu của phần mềm cần phát triển.
Thường đó là các yêu cầu chức năng về những gì
mà hệ thống phải thực hiện. Ở giai đoạn này chưa cần
chỉ ra các chức năng đó thực hiện như thế nào.
Việc xác định đúng và đầy đủ các yêu cầu của bài
toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho các
bước tiếp theo.
 Do đó, phải đặc tả được các yêu cầu của hệ thống
(Sử dụng các Use Case để đặc tả các yêu cầu). 200
Các công việc cần phải làm trong giai đoạn này:
 Hiểu rõ miền xác định của bài toán (Domain Understanding)
 Nắm bắt các yêu cầu của khách hàng/người sử dụng
Phân loại (Classification): theo tầm quan trọng hay
theo chức năng chính của những người sử dụng.
Thẩm định (Validation): Kiểm tra xem các yêu cầu có
thống nhất với nhau và đầy đủ không, đồng thời tìm
cách giải quyết các mối mâu thuẫn giữa các yêu cầu
nếu có.
201
Nghiên cứu khả thi (Feasibility Study):

Tính khả thi của một dự án tin học phải được thực
hiện dựa trên các yếu tố bao gồm các khía cạnh:
 tài chính
 chiến lược
 thị trường
 con người, đối tác
 kỹ thuật
 công nghệ và phương pháp mô hình hoá, v.v.
202
Tóm lại, giai đọan nghiên cứu sơ bộ, cần xem xét:
Các yêu cầu của NSD, những nguồn tài nguyên có
thể sử dụng, công nghệ, các ý tưởng của người sử
dụng đối với hệ thống mới.
Có thể thực hiện thảo luận, nghiên cứu, xem xét
khía cạnh thương mại, phân tích khả năng lời-lỗ
Thường trong giai đoạn này người ta cũng tiến
hành tạo một phiên bản thô của lịch trình và kế hoạch
sử dụng tài nguyên.
Kết quả của giai đoạn nghiên cứu sơ bộ là bản Báo
Cáo Kết Quả Nghiên Cứu Tính Khả Thi.
Khi hệ thống tương lai được chấp nhận dựa trên
bản báo cáo này cũng là lúc giai đoạn Phân tích bắt 203
đầu.
Mục đích cụ thể của bước xác định yêu cầu:

 Đi đến thỏa thuận với khách hàng và người dùng
về các chức năng của hệ thống-Những gì mà hệ
thống phải thực hiện
 Cho phép các System Developer hiểu rõ hơn các
yêu cầu đối với hệ thống
 Phân định ranh giới của hệ thống
 Cung cấp cơ sở để hoạch định nội dung kỹ thuật
của các vòng lặp
 Xác định giao diện người dùng cho hệ thống
204
Khi nào thì kết thúc giai đoạn này?

Khách hàng/người sử dụng (NSD) và những người
phát triển đã hiểu hoàn toàn hệ thống chưa?
Đã nêu được đầy đủ các yêu cầu về chức năng (dịch
vụ), đầu vào/ra và những dữ liệu cần thiết chưa?
205
Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu
206
2. Phân tích hướng đối tượng
Là giai đoạn quan trọng của quá trình phát triển
phần mềm, trong đó mô hình khái niệm phải được mô
tả chính xác.
Phân tích hướng đối tượng tập trung vào việc tìm
kiếm các đối tượng, khái niệm trong lĩnh vực bài toán
và xác định mối quan hệ của chúng trong hệ thống.
Phân tích hệ thống cần trả lời các câu hỏi sau:
 Hệ thống gồm những thành phần, bộ phận, đối
tượng nào?
 Hệ thống cần thực hiện những cái gì?
Kết quả chính của việc phân tích hệ thống hướng
đối tượng là: biểu đồ lớp, biểu đồ trạng thái, biểu đồ
trình tự, biểu đồ cộng tác và biểu đồ thành phần. 207
2. Phân tích hướng đối tượng ...
Tóm lại, mục tiêu cụ thể của giai đoạn phân tích là:
 Xác định hệ thống cần phải làm gì.
Nghiên cứu đầy đủ các chức năng cần cung cấp và
những yếu tố liên quan.
Xây dựng một mô hình nêu bật bản chất vấn đề từ
một hướng nhìn có thực (trong đời sống thực).
 Nhờ chuyên gia lĩnh vực đánh giá, góp ý.
Kết quả của giai đoạn phân tích là bản Đặc Tả Yêu
Cầu (Requirements Specifications).
208
3.1.3 Thiết kế hướng đối tượng
 Hệ thống được tổ chức thành tập các đối tượng
tương tác với nhau và mô tả được cách để hệ
thống thực thi nhiệm vụ của bài toán.
 Giai đoạn này cần trả lời các câu hỏi:
Hệ thống làm như thế nào? (HOW?)
 Trong hệ thống có những lớp đối tượng nào, trách
nhiệm của chúng như thế nào?
 Các đối tượng tương tác với nhau như thế nào?
 Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện
như thế nào?
 Dữ liệu nghiệp vụ và các giao diện được xây dựng
như thế nào?
 Kiến trúc và cấu hình của hệ thống như thế nào?
209
Tóm lại, nhiệm vụ chính của thiết kế hệ thống là:
Xây dựng các thiết kế chi tiết mô tả các thành phần
của hệ thống ở mức cao hơn (khâu phân tích) để
phục vụ cho việc cài đặt.
Đưa ra được kiến trúc của hệ thống để đảm bảo
cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì,
thân thiện với NSD, ...
Những kết quả trên được thể hiện trong các biểu
đồ: biểu đồ lớp (chi tiết), biểu đồ hành vi, biểu đồ
thành phần và biểu đồ triển khai.
 Trong các tài liệu thiết kế phải mô tả cụ thể
những
thành phần nào, làm những gì và làm như thế nào. 210
Một số các công việc thường được thực hiện trong
giai đoạn thiết kế:
 Thiết kế database
Thiết kế các chức năng, thủ tục mô tả các quá trình
xử lý từ input đến output.
Thiết kế các forms nhập dữ liệu tùy theo các thành
phần dữ liệu cần nhập.
Thiết kế các reports và những output mà hệ thống
mới phải sản sinh
Kết quả giai đoạn thiết kế là bản Đặc Tả Thiết Kế
(Design Specifications).
Bản Đặc Tả Thiết Kế Chi Tiết sẽ được chuyển sang
cho các lập trình viên để thực hiện giai đoạn xây 21
dựng phần mềm. 1
3.1.4 Lập trình và kiểm thử hệ thống
Trong giai đoạn này, mỗi thành phần đã được thiết
kế sẽ được lập trình thành những mô đun chương
trình (chương trình con).
Mỗi mô đun này sẽ được kiểm chứng hoặc thử
nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế.
 Công việc này được mô tả như sau:
Quá trình xây dựng phần mềm 212

4. Lập trình và kiểm thử hệ thống
Phần kiểm thử được chia thành hai bước chính:
Thử nghiệm đơn vị:

Người viết code chạy thử các phần chương trình
của mình với dữ liệu giả (test/dummy data).
Mục đích chính trong giai đoạn kiểm thử này là xem
chương trình có cho ra những kết quả mong muốn.
Giai đoạn thử nghiệm đơn vị còn được gọi là “Kiểm
thử hộp trắng" (White Box Testing)
213
3.1.4 Lập trình và kiểm thử hệ thống
Kiểm thử đơn vị độc lập
 Công việc này do một thành viên khác đảm trách.
Cần chọn người không có liên quan trực tiếp đến
việc viết code của đơn vị chương trình cần thử
nghiệm để đảm bảo tính “độc lập”.
Kiểm thử hệ thống
Sau khi các thủ tục đã được thử nghiệm riêng, cần
phải thử nghiệm toàn bộ hệ thống.
Mọi thủ tục được tích hợp và chạy thử, kiểm tra
xem mọi chi tiết ghi trong Đặc Tả Yêu Cầu.
Dữ liệu kiểm thử cần được chọn lọc đặc biệt, kết
quả cần được phân tích để phát hiện các sai sót so
với bản thiết kế. 214
3.1.5 Vận hành và bảo trì hệ thống
Cài đặt hệ thống phần mềm trong môi trường sử
dụng của khách hàng
Chỉnh sửa phần mềm đúng như những gì đã thiết
kế và yêu cầu của người sử dụng
 Về bảo trì phần mềm:
 Nâng cao hiệu quả của hệ thống
 Đảm bảo sự thích nghi đối với sự thay đổi của
môi trường của hệ thống hay sự sửa đổi cho phù
hợp với những thay đổi của chính sách, qui chế
mới
215
3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ...
Qui trình xây dựng các biểu đồ UML trong phân tích, thiết kế hệ thống HĐT216
3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG
BÀI TOÁN 1: HỆ THỐNG BÁN HÀNG (HBH)

Một Công ty muốn xây dựng HTTT để phục vụ và quản lý
các hoạt động kinh doanh. Công ty có nhiều điểm bán hàng
đầu cuối (POST: Point Of Sale Terminal), đó là những cửa
hàng, siêu thị, ... Do đó hệ thống cần phải ghi nhận các hoạt
động bán hàng và xử lý các công việc thanh toán với khách
hàng, chủ yếu khách hàng mua lẻ. Ngoài ra hệ thống còn giúp
lãnh đạo Công ty theo dõi được các hoạt động kinh doanh, tự
động kiểm kê các mặt hàng tồn đọng trong kho, các mặt hàng
bán chạy,... để hỗ trợ ra quyết định trong các hoạt động kinh
doanh của Công ty. Trong mỗi cửa hàng đầu cuối đều có các
thiết bị phần cứng như: máy tính, máy đọc mã vạch và phần
mềm hệ thống để chạy hệ thống sẽ được xây dựng”.
217
Mục đích của hệ thống HBH
 Tăng nhanh hoặc tự động hoá việc bán hàng, ghi nhận các
mặt hàng: loại sản phẩm, mô tả sản phẩm, số lượng và xác
định giá bán, tính tiền, v.v., đáp ứng mọi yêu cầu của khách
hàng,
 Thanh toán nhanh với khách hàng bằng các phương thức:
tiền mặt, thẻ tín dụng, hay séc.
 Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để
hỗ trợ quyết định trong các hoạt động kinh doanh.
 Thực hiện tự động kiểm kê các mặt hàng trong kho, theo dõi
được những mặt hàng bán chạy, những mặt hàng tồn kho để
có được những quyết định kịp thời trong kinh doanh.
 Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động
kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ
hơn.
218
Trong giai đoạn phân tích
Đối với bài toán 1, giai đoạn OOA sẽ nhận biết được các
đối tượng như:
- Cửa hàng, siêu thị
- Khách hàng
- Mặt hàng
- Người thanh toán
- ...
Tương tác và quan hệ giữa các đối tượng trên là:
- Khách hàng chọn hàng
- Khách hàng trả tiền
- ...
219
BÀI TOÁN 2: HỆ THỐNG ATM
 Ngân hàng VietinBank có các máy rút tiền tự động
(ATM) đặt ở những vị trí khác nhau trong thành
phố. Chúng được nối với Trung tâm tại trụ sở
Ngân hàng thông qua hệ thống mạng máy tính.
Máy tính trung tâm lưu trữ và quản trị CSDL khách
hàng, xử lý những công việc chuyên ngành của
ngân hàng và yêu cầu ATM trả tiền.
 Máy rút tiền tự động bao gồm máy đọc thẻ từ, màn
hình và bàn phím để tương tác với người sử
dụng.
 Khách hàng có thể rút tiền tự động, chuyển tiền,
xem số dư trong tài khoản và thực hiện thanh toán
với hệ thống tín dụng của Ngân hàng. 220
BÀI TOÁN 2: HỆ THỐNG ATM ...
 Trong những trường hợp đặc biệt như bị mất thẻ,
hay muốn thay đổi số thẻ thì khách hàng có thể
thay đổi mật khẩu cá nhân (PIN) và tương tự như
vậy, khi khách hàng báo bị mất thẻ thì Ngân
hàng cũng có thể quyết định thay đổi số thẻ và
báo cho khách hàng biết để đảm bảo không cho
những người không phải chủ sở hữu rút được
tiền.
221
BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN
 Đại học Huế cần xây dựng một hệ thống thông tin giúp sinh
viên (SV) đăng ký học phần (HP) mới. Hệ thống cho phép SV
đăng ký học phần và xem điểm từ một máy tính cá nhân được
kết nối vào hệ thống mạng của ĐHH. Các giáo viên cũng có thể
truy cập vào hệ thống này để biết được lớp dạy và nhập điểm
cho các HP.
 Vào đầu mỗi học kỳ SV dựa vào TKB và giáo viên sẽ phụ trách
môn học để đăng ký HP được giảng dạy trong học kỳ đó.
Thông tin về mỗi HP bao gồm: tên HP, tên giáo viên giảng dạy,
Khoa chuyên môn, các HP tiên quyết,... để giup SV đăng ký.
 Hệ thống mới cho phép SV chọn 4 học phần được mở trong
học kỳ tới. SV cũng có thể chọn 2 HP tự chọn trong trường hợp
không thể đăng ký theo nguyện vọng chính.
 Số tối thiểu và tối đa SV cho mỗi HP là 30 và 60. Các HP có ít
hơn 30 SV sẽ bị hủy. Đầu mỗi HP SV có một khoảng thời gian
để thay đổi các HP đã đăng ký.
BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN
 Khi quá trình đăng ký hoàn tất cho mỗi SV hệ thống sẽ gửi
thông tin đến ngân hàng VietinBank để SV có thể đóng học
phí qua thẻ ATM
 Nếu một lớp bị hết chỗ trong quá trình đăng ký, SV sẽ được
thông báo về sự thay đổi trước khi xác nhận đăng ký HP
 Cuối học kỳ SV có thể truy cập vào hệ thống để xem phiếu
điểm. Hiễn nhiên, mỗi SV được hệ thống cung cấp một tài
khoản cá nhân để bảo mật thông tin của mình.
 Các giáo viên có thể truy cập vào hệ thống để biết TKB và
danh sách SV của HP sẽ dạy
 Giáo viên có nhiệm vụ nhập các điểm QTHT, điểm thi, kiểm
tra sau khi HP kết thúc
223
Các công cụ để mô tả yêu cầu người dùng
224
Các chức năng, nhiệm vụ của hệ thống là gì?
 Chức năng của hệ thống là những gì mà hệ thống
được yêu cầu thực hiện.
 Các chức năng có thể phân loại theo lĩnh vực chức
năng để tránh sự nhầm lẫn giữa chúng. Các chức
năng hệ thống có thể chia thành:
 Chức năng hiển (Evident): chọn hàng, tính
tiền,...
 Chức năng ẩn (Hiddent): cập nhật dữ liệu, tồn
kho
 Chức năng tuỳ chọn (optional): tăng mức độ thân
thiện của hệ thống nhưng không ảnh hưởng tới
225
giá trị cũng như các chức năng khác.
Các chức năng, nhiệm vụ của hệ thống là gì?
Chú ý:
 Các chức năng của hệ thống phải được chia thành
các nhóm theo các mối liên hệ với nhau.
 Dựa vào cách phân chia các chức năng để sau này
chia nhỏ hệ thống thành các gói, các hệ thống con
trong quá trình phân tích và thiết kế hệ thống.
 Ví dụ: Các chức năng của hệ thống HBH có thể chia
thành hai nhóm chính:
 Các chức năng bán hàng
 Các chức năng thanh toán.
226
Bảng liệt kê các chức năng
227
Bảng liệt kê các chức năng
Các chức năng hệ thống thường được đánh số theo các qui
tắc tham chiếu (Reference Rule) để tiện cho việc sử dụng tham
chiếu trong các mục phân tích sau này.
228
3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HỆ THỐNG
1. Use Case
 Use Case mô tả tập các hoạt động của hệ thống
theo quan điểm của các tác nhân (Actor). Nó mô tả
các yêu cầu của hệ thống và trả lời cho câu hỏi:
Hệ thống phải làm gì (What ?)
 Một Use Case có thể bao gồm nhiều biểu đồ Use
Case
 Use Case mô tả rõ ràng và nhất quán về việc hệ
thống cần phải làm gì (What?).
 Use Case mô tả các yêu cầu về mặt chức năng của
hệ thống -các chức năng này có từ sự thỏa
thuận giữa khách hàng và nhóm phát triển phần
229
mềm.
2. Mục tiêu của Use Case
 Làm cơ sở để:
 người phân tích viên hiểu
 người thiết kế xây dựng các kiến trúc
 người lập trình cài đặt các chức năng
 người kiểm thử kiểm tra các kết quả thực hiện
của hệ thống.
 Làm công cụ giao tiếp cho những người phát triển,
đảm bảo hệ thống thỏa mãn đúng những yêu cầu
của Users
230
3. Ai cần Use Case? - Để làm gì?
 Nhà phát triển cần đến các mô hình Use Case để
hiểu hệ thống cần phải làm gì, và qua đó có được
một nền tảng cho những công việc tương lai
 Customers/Users quan tâm đến Use Case vì nó đặc
tả chức năng của hệ thống và mô tả xem hệ thống có
thể và sẽ được sử dụng như thế nào.
 Tester cần đến Use Case để thử nghiệm và kiểm tra
xem hệ thống có đảm bảo sẽ thực hiện đúng chức
năng đã được đặc tả trong giai đoạn đầu.
 Những người liên quan đến những hoạt động liên kết
đến chức năng của hệ thống như nhóm tiếp thị, bán
hàng, hỗ trợ khách hàng và nhóm soạn thảo tài liệu2.31
4. Cách thể hiện một biểu đồ Use Case
Một biểu đồ Use Case thể hiện:
 Hệ thống
Actors Hệ thống
 Tác nhân
 Use Case. Use
Case
Ví dụ biểu đồ Use Case trong UML:
232
a. Hệ thống
 Hệ thống là một thành phần của Use Case nên ranh
giới của hệ thống cần phải được xác định rõ ràng.
 Một hệ thống không nhất thiết là một hệ thống phần
mềm; nó có thể là một chiếc máy, hoặc là một doanh
nghiệp.
 Ký hiệu của hệ thống: hình chữ nhật có kèm theo tên
hệ thống
System
B o u n d a ry
UseCase
233
b. Tác nhân
 Người hoặc một vật nào đó tương tác
với hệ thống, sử dụng hệ thống.
 Một tác nhân có thể là người, thiết bị mà cũng có thể
là một hệ thống khác.
 Tên gọi của tác nhân được mô tả bằng các danh từ
(chung) và thường phải đặc tả được vai trò của nó
đối với hệ thống.
 Một tác nhân là một dạng tập thực thể (một lớp) chứ
không phải một thực thể. Tác nhân mô tả và đại
diện cho một vai trò, chứ không phải là một người
sử dụng thật sự và cụ thể của hệ thống.
234
c. Bảng chú giải
 Dùng để giải thích các khái niệm, định nghĩa, thuật ngữ, ngôn
ngữ công việc trong hệ thống
235
5. Cách xác định các tác nhân và các Use Case
a. Để xác định các tác nhân là dựa trên các câu trả
lời những câu hỏi sau:
 Ai sẽ sử dụng các chức năng chính của hệ thống?
 Ai cần sự hỗ trợ của hệ thống để thực hiện các
công việc hàng ngày?
 Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống
hoạt động thường xuyên?
 Hệ thống quản lý, sử dụng những thiết bị nào?
 Hệ thống cần tương tác với những bộ phận, hệ
thống nào khác?
 Ai hay cái gì quan tâm đến kết quả xử lý của
hệ
thống? 236
5. Cách xác định các tác nhân và các Use Case
b. Có hai phương pháp để xác định các Use Case

 Xác định Use Case dựa vào các tác nhân:
 Xác định những tác nhân liên quan đến hệ thống
hoặc đến tổ chức, nghĩa là tìm và xác định những
tác nhân là NSD hay những hệ thống khác tương tác
với hệ thống cần xây dựng.
 Với mỗi tác nhân, tìm những tiến trình (chức năng)
được khởi đầu, hay giúp các tác nhân thực hiện,
giao tiếp/tương tác với hệ thống.
237
 Xác định các Use Case và các sự kiện
 Xác định những sự kiện bên ngoài có tác động đến

hệ thống hay hệ thống phải trả lời.
 Tìm mối liên quan giữa các sự kiện và các UC.
 Hãy trả lời những câu hỏi sau để tìm ra các UC:
 Nhiệm vụ chính của các tác nhân là gì?
 Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ
thông tin hay không?
 Những thay đổi bên ngoài hệ thống thì tác nhân có cần
phải thông báo cho hệ thống hay không?
 Những tác nhân nào cần được thông báo về những thay
đổi của hệ thống?
 Hệ thống cần có những đầu vào/ra nào? từ đâu và đến
đâu? 238
Ví dụ1: Xác định các Actor và Use Case của HBH
a. Xác định các actor: Danh sách các actor

+ Khách hàng: là những người được hệ HBH phục vụ,
là khách hàng.
+ Người bán hàng: những người cần sử dụng chức
năng bán hàng của hệ thống để thực hiện nhiệm vụ
của mình.
+ Người quản lý: những người được phép khởi động
hay kết thúc cả hệ thống tại các điểm bán hàng đầu
cuối.
+ Người quản trị hệ thống: có thể bổ sung, thay đổi
những NSD.
239
Ví dụ1: Xác định các Actor và Use Case của HBH ...
b. Xác định các Use Case: Danh sách các Use Case
 Bán hàng, mua hàng (Buy Items) là nhiệm vụ của
hệ thống HBH liên quan trực tiếp tới khách hàng và
người bán hàng. Use Case Use Case này liên
quan đến cả người bán hàng và khách hàng.
 Thanh toán, trả tiền mua hàng hay thu tiền là chức
năng của hệ thống phải thực hiện để thanh toán với
khách hàng bằng phương thức mà họ lựa chọn: trả
tiền mặt, thẻ tín dụng, hay trả bằng séc. Use Case
này cũng liên quan đến cả người bán hàng và
khách hàng.
240
Ví dụ1: Xác định các Actor và Use Case của HBH ...
 Đăng nhập hệ thống (Log in): Người bán hàng cần
sử dụng để nhập vào hệ thống và sử dụng nó để
bán hàng.
 Khởi động, đóng hệ thống: Người quản lý thực hiện
để khởi động hay kết thúc hoạt động của hệ
thống.
 Bổ sung NSD mới, Loại bỏ NSD: Người quản trị hệ
thống có thể bổ sung thêm người sử dụng mới
hay loại bỏ những NSD không còn cần sử dụng
hệ thống.
241
Các Actor và Use Case của hệ thống HBH
Tác nhân Use Case
Người bán hàng (Cashier) Đăng nhập hệ thống (Log In)
Thu tiền bán hàng (Cash Out)
Khách hàng (Customer) Mua hàng (Buy Items)

Thu tiền, thanh toán (Refund Items)
Người quản lý (Manager) Khởi động hệ thống (Start Up)

để
Hay gian hàng trưởng người bán hàng có thể sử dụng HT.
Đóng hệ thống khi hết giờ
Quản trị hệ thống Bổ sung NSD (Add New Users)
(System Adminitrator) Loại bỏ NSD (Delete User)
242
Biểu đồ Use Case của hệ thống HBH
243
Ví dụ2: Các Actor và Use Case của hệ thống ATM
a. Xác định các actor: Danh sách các actor

 Khách hàng: những đối tượng chính mà hệ thống
ATM phục vụ việc rút/gửi tiền tự động.
 Hệ thống tín dụng: bộ phận tín dụng của Ngân hàng
quản lý và phục vụ tín dụng cho khách hàng.
 Nhân viên ngân hàng: những người được quyền
thay đổi PIN của khách hàng khi cần thiết, chuyển
tền vào máy.
244
Ví dụ2: Các Actor và Use Case của hệ thống ATM
 Rút tiền: những khách hàng có tiền trong tài khoản
của Ngân hàng, khi cần rút tiền thì nhập số PIN, nhập
số lượng tiền cần rút.
 Chuyển tiền: khách hàng có thể chuyển tiền từ một tài
khoản khác về tài khoản của mình hoặc gửi tiền trực
tiếp vào tài khoản.
 Xem số dư trong tài khoản: khách hàng biết được
mình còn bao nhiêu tiền trong tài khoản.
 Thanh toán: khách hàng có thể sử dụng để thanh toán
với hệ thống tín dụng của Ngân hàng.
 Thay đổi PIN: khách hàng, hoặc nhân viên Ngân hàng
245
có thể thay đổi PIN khi cần thiết.
Biểu đồ Use Case của hệ thống ATM
246
6. Đặc tả các Use Case
b. Mục đích : Để hiểu rõ hơn về tiến trình xử lý các yêu

cầu của hệ thống.
Mẫu đặc tả Use Case có dạng:
 Tên Use Case: tên của Use Case bắt đầu

bằng động từ, gợi nhớ.
 Các tác nhân: danh sách các tác nhân liên
quan đến Use Case.
 Mô tả mục đích :Mô tả tóm tắt tiến trình xử lý
công việc cần thực hiện.
 Tham chiếu: Các chức năng, Use Case và
những hệ thống liên quan.
247
Ví dụ
Use Case: Bán hàng (Buy Items)

Tác nhân: Khách hàng, người bán hàng.
Mô tả: Khách hàng sau khi đã chọn đủ các mặt
hàng cần mua để ở trong giỏ hàng thì đưa hàng
đến quầy thu tiền. Người bán (cashier) lần lượt
ghi nhận các mặt hàng trong giỏ hàng của
khách và thu tiền. Sau khi thanh toán xong
khách hàng được mang số hàng đã mua đi ra
khỏi cửa hàng.
Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3,
R1.6, R1.7, R1.8, R3.1, R3.2, R3.3.
248
Ví dụ
Use Case cho chức năng Bán hàng (Buy items)
Bán hàng
Khách hàng Người bán hàng
249
Ví dụ
Use Case: Thu tiền (Cash Out)
Tác nhân: Khách hàng, người bán hàng.
Mô tả: Khách hàng có thể trả tiền theo 3 phương thức:
1. Trả tiền mặt (Pay by Cash)
3. Trả bằng thẻ tín dụng (Pay by Credit)
3. Trả bằng séc (Pay by Check)
Người bán nhận tiền mặt/thẻ tín dụng/sec rồi thanh
toán tiền thừa cho khách hàng sau khi thẻ tín
dụng/sec đã được kiểm duyệt.
Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3,
R1.9, R3.1, R3.2, R3.3.
250
Use Case cho chức năng Thu tiền (Cash Out)
Pay by Check
Bộ phận kiểm
Bộ phận kiểm Pay by Credit duyệt sec
duyệt thẻ
<<uses>> Pay by Cash
<<uses>>
<<uses>>
Khách hàng Cash Out

Người bán hàng
251
Use Case cho chức năng Thu tiền (Cash Out)
Chú ý:
Ngoài những đặc tả nêu trên, ta còn có thể xây
dựng các kịch bản (scenario) hành động để mô tả các
sự kiện xảy ra trong hệ thống.
 Mỗi kịch bản có thể mô tả theo hai luồng:
 Luồng thực hiện của các tác nhân
 Luồng tương ứng với hệ thống.
(Xem thêm phần xây dựng kịch bản ở trang 57, 58

của giáo trình)
252
7. Mối quan hệ giữa các Use Case
Giữa các Use Case có ba quan hệ chính:

 Quan hệ mở rộng (extends)
<<extends>>
 Quan hệ sử dụng (uses/include)

<<uses>>
 Quan hệ theo nhóm hay theo gói (package).
253
8. Checkpoint - Use Case Model
Kiểm tra đã hoàn tất việc xác định yêu cầu của
người dùng chưa?
a. Kiểm tra về Use Case Model và Use Case
1.Use-case model có dễ hiểu không?
2.Sau khi nghiên cứu Use Case model, bạn có hình
thành được một ý tưởng rõ ràng về các chức năng
của hệ thống và cách thức mà chúng liên hệ với
nhau?
3.Đã xác định hết các actor chưa? Tất cả các yêu cầu
chức năng được thỏa mãn chưa?
4.Use-case model có chứa các hành vi vô dụng nào
không?
8. Checkpoint
5. Việc chia các Use Case thành các Package có xác

đáng không?
6. Mỗi Use Case có ít nhất một actor tương tác?
7. Các Use Case có độc lập với nhau?
8. Tồn tại các Use Case có các luồng sự kiện và các
hành vi tương tự nhau không?
9. Liệu các Use Case có tên duy nhất, gợi nhớ, dễ
hiểu để chúng không bị nhầm lẫn trong các giai
đọan sau?
10.Các customers và users có hiểu tên và mô tả của
các Use Case không?
8. Checkpoint - Actors
b. Kiểm tra các Actors

1. Đã xác định hết các actor chưa?
2. Mỗi actor có tham gia vào ít nhất một Use Case?
3.Mỗi actor thật sự có một vai trò (role)? Có cần
ghép hoặc tách các actor không?
4. Có tồn tại 2 actor đóng cùng một vai trò đối với 1
Use Case không?
5. Tên của các actor có gợi nhớ không? Users và
customers có hiểu tên của chúng?
8. Checkpoint - Glossary
c. Kiểm tra các Glossary

1. Các thuật ngữ có định nghĩa rõ ràng và súc tích?
2. Mỗi thuật ngữ có sử dụng đâu đó trong các mô tả
Use Case?
3. Các thuật ngữ có được sử dụng hợp lý trong các
mô tả ngắn về các actors và Use Case?
3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
3.4.1. Vai trò của thiết kế

 Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển
phần mềm; là bước chuyển tiếp của giai đoạn phân tích và
là bước chuẩn bị trước khi tiến hành xây dựng phần mềm.
 Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu
mẫu của phần mềm. Các mô hình này chính là những nét
phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm
chúng ta đang xây dựng là gì, đã có, đang có và sẽ có
những gì.
 Thiết kế là nơi mà ta có thể trả lời câu hỏi :
 “Liệu phần mềm này có thể chạy được không?”
 “Phần mềm có thể đáp ứng được các yêu cầu của
khách
màhàng haycần
không không?”
đợi đến công đoạn phát triển sau. 258
3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG ...
3.4.2. Các nguyên lý thiết kế
 Nguyên lý ‘đóng mở’: một modun cần “mở” đối
với việc phát triển thêm tính năng nhưng phải
“đóng” đối với việc sửa đổi mã nguồn
 Nguyên lý thay thế Liskov: Các chức năng của
hệ thống vẫn thực hiện đúng đắn nếu ta thay bất kì
một lớp đối tượng nào bằng một lớp đối tượng kế
thừa.
 Nguyên lý nghịch đảo phụ thuộc: phụ thuộc vào
mức trừu tượng, không phụ thuộc vào mức chi tiết.
 Nguyên lý phân tách giao diện: nên có nhiều
giao diện đặc thù với bên ngoài hơn là chỉ có một
259
giao diện dùng chung cho một mục đích.
3.5. CÁC NHÓM MẪU THIẾT KẾ
3.5.1. Sự quan trọng của mẫu thiết kế

 Trong bất kỳ một hệ thống hướng đối tượng nào
cũng có thể gặp các vấn đề lặp lại. Do đó, một mẫu
thiết kế là một giải pháp tổng thể cho các vấn đề
chung trong thiết kế phần mềm.
 Mẫu thiết kế tuân thủ nghiêm ngặt các nguyên lý
thiết kế hướng đối tượng ở trên.
 Mẫu thiết kế không phụ thuộc vào ngôn ngữ lập
trình, công nghệ, và nó có các quy tắc biểu
diễn của ngôn ngữ UML.
260
3.5. CÁC NHÓM MẪU THIẾT KẾ ...
3.5.2. Sự quan trọng của mẫu thiết kế ...

 Mẫu thiết kế sẽ giúp cho việc giải quyết vấn đề
nhanh, gọn hơn và hợp lý hơn.
 Mẫu thiết kế còn được sử dụng nhằm cô lập các
thay đổi trong mã nguồn, từ đó làm cho hệ
thống có khả năng tái sử dụng cao.
 Chúng ta sẽ tìm hiểu một số mẫu thiết kế kinh điển
GoF - Gang of Four - bốn tác giả Erich Gamma,
Richard Helm, Ralph Johnson và John Vlissides
của cuốn sách Design Patterns: Elements of
Reusable Object-Oriented Software (Download ở site:
http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf)
261
3.5. CÁC NHÓM MẪU THIẾT KẾ ...
3.5.3. Các loại mẫu thiết kế

 GoF đề xuất 23 mẫu thiết kế được chia theo 3
nhóm theo mục đích sử dụng:
 Creational Patterns – Các mẫu kiến

tạo
 Structural Patterns – Các mẫu kiến

trúc
 Behavioral Patterns – Các mẫu

262
tương tác
a. CÁC NHÓM MẪU THIẾT KẾ
1. Các mẫu thuộc nhóm kiến tạo - Creational Patterns
2. Các mẫu thuộc nhóm kiến trúc - Structural Patterns
263
a. CÁC NHÓM MẪU THIẾT KẾ ...
1. Các mẫu thuộc nhóm tương tác - Behavioral Patterns
264
b. CÁC MẪU THUỘC NHÓM KIẾN TẠO - CREATIONAL PATTERNS
Mục đích chung:

 Các mẫu này được dùng để khởi tạo các đối tượng
trong hệ thống.
 Hầu hết các hệ thống hướng đối tượng phức tạp
yêu cầu nhiều đối tượng được thể hiện theo
thời gian, và các mẫu này hỗ trợ cho việc tạo
các tiến trình bằng việc cung cấp các khả năng:
 Sự thể hiện chung – Điều này cho phép các đối tượng
được tạo ra trong hệ thống không cần phải định nghĩa
một đặc tả kiểu lớp trong mã nguồn
 Đơn giản – Một vài mẫu làm cho việc khởi tạo đối tượng
trở nên dễ dàng, vì vậy lớp “gọi” khởi tạo đối tượng không
phải viết mã nhiều cũng như phức tạp
265
Mẫu Abstract Factory
1.Ý nghĩa:
 Abstract Factory cung cấp 1 giao diện để tạo ra đối
tượng mà không phải mô tả các lớp cụ thể.
 Abstract Factory dùng để đóng gói một nhóm gồm
những lớp đóng vai trò là “phân xưởng” (Factory)
trong ứng dụng, đây là những lớp được dùng để tạo
lập các đối tượng. Các lớp “phân xưởng” này có
chung một giao diện lập trình được kế thừa từ một
lớp cha thuần ảo gọi là “lớp phân xưởng ảo”
266
2. Cấu trúc mẫu:
267
Trong đó:
AbstractFactory: là lớp trừu tượng, tạo ra các đối tượng thuộc
2 lớp trừu tượng là: AbstractProductA và AbstractProductB
ConcreteFactoryX: là lớp kế thừa từ AbstractFatory, lớp này sẽ
tạo ra một đối tượng cụ thể
 AbstractProduct: là các lớp trừu tượng, các đối tượng cụ thể
sẽ là các thể hiện của các lớp dẫn xuất từ lớp này. 268
1 game, trong đó
có thú ăn thịt và
thú ăn cỏ
 Thú ăn thịt: Sư
tử, Sói
Thú ăn cỏ: Linh
dương, Bò rừng
 Phân biệt theo
các châu
 Châu Phi: Sư
tử, Linh dương
 Châu Mỹ: Sói,
Bò rừng
269
The classes and/or objects participating in
this pattern are:
 AbstractFactory (ContinentFactory)
declares an interface for operations that
create abstract products
 ConcreteFactory (AfricaFactory,
AmericaFactory)
implements the operations to create
concrete product objects
 AbstractProduct (Herbivore,
Carnivore)
declares an interface for a type of product
object
 Product (Wildebeest, Lion, Bison, Wolf)
defines a product object to be created by
the corresponding concrete factory
implements the AbstractProduct interface
 Client (AnimalWorld)
uses interfaces declared by
AbstractFactory and
270
AbstractProduct classes
Xem code in C# tại: http://www.dofactory.com/Patterns/PatternAbstract.aspx
Mẫu Abstract Factory
3. Tình huống áp dụng
 Phía trình khách sẽ không phụ thuộc vào việc những
sản phẩm được tạo ra như thế nào.
 Ứng dụng sẽ được cấu hình với một hoặc nhiều họ
sản phẩm.
 Các đối tượng cần phải được tạo ra như một tập
hợp để có thể tương thích với nhau.
 Chúng ta muốn cung cấp một tập các lớp và chúng
ta muốn thể hiện các ràng buộc, các mối quan hệ
giữa chúng mà không phải là các thực thi của chúng
(interface).
271
Mẫu Abstract Factory ...
4. Ví dụ:
Giả sử ta cần viết một ứng dụng quản lý địa chỉ và
số điện thoại cho các quốc gia trên thế giới. Điạ chỉ
và số địa thoại của mỗi quốc gia sẽ có 1 số điểm
giống nhau và 1 số điểm khác nhau. Ta xây dựng sơ
đồ lớp như sau:
272
Ta sẽ xây dựng các phương thức
tạo Address, và PhoneNumber cụ
thể trong các lớp:
• USAAddressPhoneFactory
• FrechAddressPhoneFactory.
Với phương thức
createProductAddress() của lớp
USAAddressPhoneFactory sẽ trả
về đối tượng của lớp USAAddress
Với phương thức
createProductAddress() của lớp
FrechAddressPhoneFactory sẽ trả
về đối tượng của lớp FrechAddress
 Tương tự với PhoneNumber.
273
Mẫu Builder
1.Ý nghĩa:
Tách các thành phần của một đối tượng phức hợp,
để có thể cùng khởi tạo một lần mà có thể tạo nên
nhiều định dạng khác nhau.
274
Trong đó,
 Director: là lớp điều khiển tạo ra một đối tượng Product
Builder: là lớp trừu tượng cho phép tạo ra đối tượng Product từ
các phương thức nhỏ khởi tạo từng thành phần của Product
 ConcreteBuilder: là lớp dẫn xuất của Builder, khởi tạo từng đối
tượng cụ thể, lớp này sẽ khởi tạo đối tượng. 275
Mẫu Builder ...
 Có cấu trúc bên trong phức tạp (đặc biệt là một biến
là một tập các đối tượng liên quan với nhau)
 Có các thuộc tính phụ thuộc vào các thuộc tính
khác
 Sử dụng các đối tượng khác trong hệ thống mà có
thể khó khởi tạo hoặc khởi tạo phức tạp.
4. Ví dụ
Ta lại xét đối tượng Address, có các thành phần sau:
Street, City và Region. Ta phân tách việc khởi tạo 1
đối tượng Address thành các phần : buildStreet, 276
buildCity và buildRegion.
Mẫu Builder ...
Trong đó:
 AddressDirector: là lớp tạo ra đối tượng Address
AddressBuilder: là lớp trừu tượng cho phép tạo ra 1 đối tượng
Address bằng các phương thức khởi tạo từng thành phần của
Address
 USAddressBuilder: là lớp tạo ra các Address.
sẽUSAddressBuilder
tạo ra địa chỉ theo chuẩn của USA 277
Mẫu Factory Method
1.Ý nghĩa:
Định nghĩa một phương thức chuẩn để khởi tạo đối
tượng, như là một phần của phương thức tạo,
nhưng việc quyết định kiểu đối tượng nào được tạo
ra thì phụ thuộc vào các lớp con.
278
Trong đó,
 Creator là lớp trừu tượng,
khai báo phương thức factoryMethod() nhưng không cài đặt
 Product cũng là lớp trừu tượng
ConcreteCreatorA và ConcreteCreatorB là 2 lớp kế thừa từ lớp Creator để
tạo ra các đối tượng riêng biệt
 ConcreteProductA và ConcreteProductB là các lớp kế thừa của lớp
Product, các đối tượng của 2 lớp này sẽ do 2 lớp ConcreteCreatorA và 279
ConcreteCreatorB tạo ra
Mẫu Factory Method ...
 Khi bạn muốn tạo ra một framework có thể mở rộng,
có nghĩa là nó cho phép tính mềm dẻo trong một số
quyết định như chỉ ra loại đối tượng nào được tạo
ra
 Khi bạn muốn 1 lớp con, mở rộng từ 1 lớp cha,
quyết định lại đối tượng được khởi tạo.
 Khi bạn biết khi nào thì khởi tạo một đối tượng
nhưng không biết loại đối tượng nào được khởi tạo
 Bạn cần một vài khai báo chồng phương thức tạo
với danh sách các tham số như nhau, điều mà Java
không cho phép. Thay vì điều đó ta sử dụng các
280
Factory Method với các tên khác nhau.
4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract Pattern
281
4.3.4. Mẫu Prototype
1.Ý nghĩa:
Giúp khởi tạo đối tượng bằng cách copy một đối
tượng khác đã tồn tại (đối tượng này là “prototype” –
nguyên mẫu).
282
Mẫu Prototype
Trong đó:
Prototype là lớp trừu tượng cài đặt phương thức myClone() là
phương thức copy bản thân đối tượng đã tồn tại.
ConcretePrototype1 và ConcretePrototype2 là các lớp kế thừa
lớp Prototype. 283
Mẫu Prototype
 Khi bạn muốn khởi tạo một đối tượng bằng cách sao
chép từ một đối tượng đã tồn tại.
4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract
Pattern
284
Mẫu Singleton
1. Ý nghĩa:
Mẫu này được thiết kế để đảm bảo cho một lớp chỉ
có thể tạo ra duy nhất một thể hiện của nó.

Trong đó:
Singleton cung cấp một
phương thức tạo private,
duy trì một thuộc tính tĩnh để
tham chiếu đến một thể
hiện của lớp Singleton này,
và nó cung cấp thêm một
phương thức tĩnh trả về
thuộc tính
tĩnh này. 285
Mẫu Singleton ...
 Khi bạn muốn lớp chỉ có 1 thể hiện duy nhất và nó
có hiệu lực ở mọi nơi.
286
c. NHÓM CÁC MẪU CẤU TRÚC- Structural Patterns
Mục đích chung:

 Đề cập đến việc các đối tượng kết hợp với nhau để
tạo thành các cấu trúc hữu dụng hơn
 Các mẫu Structural diễn tả một cách có hiệu quả
cả việc phân chia hoặc kết hợp các phần tử trong
một ứng dụng.
 Những cách mà các mẫu Structural áp dụng vào
ứng dụng rất rộng: chẳng hạn,
 Mẫu Adapter có thể làm cho hai hệ thống không tương
thích có thể giao tiếp với nhau,
 Mẫu Façade cho phép bạn làm đơn giản hóa một giao
tiếp để sử dụng mà không cần gỡ bỏ tất cả các tùy
biến
đã có trong hệ thống. 287
Mẫu Adapter
1. Ý nghĩa: Tạo một giao diện trung gian để gắn kết vào hệ
thống một lớp đối tượng mong muốn nào đó.
 Tagret là một interface định
nghĩa chức năng, yêu cầu mà
Client cần sử dụng
 Adaptee là lớp chức các chức
năng mà Target cần sử dụng để
tạo ra được chức năng mà
Target cần cung cấp cho Client
 Adapter thực thi từ Target và
sử dụng đối tượng lớp Adaptee,
Apdater có nhiệm vụ gắn kết
Adaptee vào Target để có được
chức năng mà Client mong
muốn 288
Mẫu Adapter
 Muốn sử dụng 1 lớp có sẵn nhưng giao tiếp của nó không
tương thích với yêu cầu hiện tại
 Muốn tạo 1 lớp có thể sử dụng lại mà lớp này có thể làm việc
được với những lớp khác không liên hệ gì với nó, và là
những lớp không cần thiết tương thích trong giao diện.
4. Ví dụ:
 Có một hệ thống PhoneTarget cần thực hiện một chức năng
gì đó, trong đó có một phương thức trả về số điện thoại trong
một chuỗi đầu vào
 Trước đó ta đã có một lớp có một chức năng là lấy các kí tự
số trong một chuỗi
 Giờ ta muốn sử dụng chức năng lấy kí tự số vào hệ thống
số điện thoại
lấy 289
Mẫu Bridge
1. Ý nghĩa: Một thành phần trong OOP thường có 2 phần:
phần ảo – định nghĩa các chức năng và phần thực thi –
thực thi các chức năng được định nghĩa trong phần ảo.
Hai phần này liên hệ với nhau qua quan hệ kế thừa.
Những thay đổi trong phần ảo dẫn đến các thay đổi trong
phần thực thi.
Mẫu Bridge được sử dụng để tách thành phần ảo và thành
phần thực thi riêng biệt, do đó các thành phần này có thể
thay đổi độc lập và linh động. Thay vì liên hệ với nhau
bằng quan hệ kế thừa hai thành phần này liên hệ với nhau
thông qua quan hệ “chứa trong”.
290
4.4.2 Mẫu Bridge
Trong đó:
o Abstraction: là lớp trừu tượng khai báo các chức năng và cấu trúc cơ bản,
trong lớp này có 1 thuộc tính là 1 thể hiện của giao tiếp Implementation, thể
hiện này bằng các phương thức của mình sẽ thực hiện các chức năng
abstractionOp() của lớp Abstraction
oImplementation: là giao tiếp thực thi của lớp các chức năng nào đó của
Abstraction
o RefineAbstraction: là định nghĩa các chức năng mới hoặc các chức
năng đã
có trong Absrtaction.
o ConcreteImplement:
giao tiếp Implementationlà các lớp định nghĩa tường minh các thực thi 291
Mẫu Bridge
Khi bạn muốn tạo ra sự mềm dẻo giữa 2 thành phần
ảo và thực thi của một thành phần, và tránh đi mối
quan hệ tĩnh giữa chúng.
Khi bạn muốn những thay đổi của phần thực thi sẽ
không ảnh hưởng đến client.
 Bạn định nghĩa nhiều thành phần ảo và thực thi.
Phân lớp con một cách thích hợp, nhưng bạn muốn
quản lý 2 thành phần của hệ thống một các riêng biệt
292
Mẫu Composite
1. Ý nghĩa:
Mẫu này nhằm gom
các đối tượng vào
trong một cấu trúc
cây để thể hiện
được cấu trúc tổng
quát của nó. Trong
khi đó cho phép mỗi
phần tử của cấu trúc
cây có thể thực
hiện một chức năng
theo một giao tiếp
chung.
2. Cấu trúc mẫu: 293

Mẫu Composite
Trong đó:
Component: là một giao tiếp định
nghĩa các phương thức cho tất cả các
phần của cấu trúc cây. Component có
thể được thực thi như một lớp trừu
tượng khi bạn cần cung cấp các hành
vi cho tất cả các kiểu con. Bình
thường, các Component không có các
thể hiện, các lớp con hoặc các lớp
thực thi của nó, gọi là các nốt, có thể
có thể hiện và được sử dụng để tạo
nên cấu trúc cây.
Composite: là lớp được định nghĩa bởi các thành phần mà nó chứa. Composite chứa
một nhóm động các Component, vì vậy nó có các phương thức để thêm vào hoặc loại
bổ các thể hiện của Component trong tập các Component của nó. Những phương thức
được định nghĩa trong Component được thực thi để thực hiện các hành vi đặc tả cho
lớp Composite và để gọi lại phương thức đó trong các nốt của nó. Lớp Composite được
gọi là lớp nhánh hay lớp chứa
Leaf: là lớp thực thi từ giao tiếp Component. Sự khác nhau giữa lớp Leaf và
Composite là lớp Leaf không chứa các tham chiếu đến các Component khác, lớp Leaf
đại diện cho mức thấp nhất của cấu trúc cây. 294
Mẫu Composite
Khi có một mô hình thành phần với cấu trúc nhánh
– lá, toàn bộ – bộ phận, …
 Khi cấu trúc có thể có vài mức phức tạp và động
Bạn muốn thăm cấu trúc thành phần theo một cách
qui chuẩn, sử dụng các thao tác chung thông qua mối
quan hệ kế thừa.
4. Ví dụ:
Trở lại ví dụ về dự án, một Project (Composite) có
nhiều tác vụ Task (Leaf), ta cần tính tổng thời gian của
dự án thông qua thời gian của tất cả các tác vụ 295
Mẫu Decorator
1. Ý nghĩa:
Bổ sung trách nhiệm
cho đối tượng tại thời
điểm thực thi. Đây
được xem là sự thay
thế hiệu quả cho
phương pháp kế thừa
trong việc bổ sung
trách nhiệm cho đối
tượng và mức tác động
là ở mức đối tượng
thay vì ở mức lớp như
phương pháp kế thừa.
296
Mẫu Decorator
Trong đó:
Component: là một interface chứa các
phương thức ảo (ở đây là
defaultMethod)
ConcreteComponent: là một lớp kế
thừa từ Component, cài đặt các phương
thức cụ thể (defaultMethod được cài
đặt tường minh)
Decorator: là một lớp ảo kế thừa từ
Component đồng thời cũng chứa 1 thể
hiện của Component, phương thức
defaultMethod trong Decorator sẽ được
thực hiện thông qua thể hiện này.
ConcreteDecoratorX: là các lớp kế
thừa từ Decorator, khai báo tường minh
các phương thức, đặc biệt trong các
lớp này khai báo tường minh các “trách
nhiệm” cần thêm vào khi run-time
297
Mẫu Decorator

Khi bạn muốn thay đổi động mà không ảnh hưởng
đến người dùng, không phụ thuộc vào giới hạn các lớp
con.
Khi bạn muốn thành phần có thể thêm vào hoặc rút
bỏ đi khi hệ thống đang chạy
Có một số đặc tính phụ thuộc mà bạn muốn ứng
dụng một cách động và bạn muốn kết hợp chúng vào
trong một thành phần.
298
4. Ví dụ:
Giả sử trong thư viện có
các tài liệu: sách, video…
Các loại tài liệu này có các
thuộc tính khác nhau,
phương thức hiển thị của
giao tiếp LibraryItem sẽ
hiển thị các thông tin này.
Giả sử, ngoài các thông tin
thuộc tính trên, đôi khi ta
muốn hiển thị độc giả
mượn một cuốn sách (chức
năng hiển thị độc giả này
không phải lúc nào cũng
muốn hiển thị), hoặc muốn
xem đoạn video(không
299
thường xuyên).
Mẫu Façade
1. Ý nghĩa:
Cung cấp một giao
tiếp hợp nhất của
một tập các giao
tiếp trong hệ thống
con. Façade định
nghĩa một giao tiếp
mức cao hơn để
làm cho hệ thống
con dễ sử dụng
300
Mẫu Façade
Trong đó:
Class1 và Class2 là
các lớp đã có trong hệ
thống
Façade là lớp sử
dụng các phương
thức của Class1 và
Class2 để tạo ra một
giao diện mới, thường
được sử dụng, đỡ
phức tạp hơn khi sử
dụng riêng Class1 và
Class2
301
Mẫu Façade

Làm cho một hệ thống phức tạp dễ sử dụng hơn
bằng cách cung cấp một giao tiếp đơn gian mà không
cần loại bỏ các lựa chọn phức tạp
Giảm bớt sự ràng buộc giữa client và các hệ thống
con.
302
Mẫu Façade
4. Ví dụ:
Giả sử hệ thống cũ đã
có các lớp: Địa chỉ, Số điện
thoại, Tên tuổi về thông tin
của một người, giờ ta muốn
quản lý các thông tin
trên của một người, ta tận
dụng lại hệ thống cũ, xây
một lớp Người sử dụng lại
các lớp ở trên.
303
Mẫu Flyweight
1.Ý nghĩa:
Làm phương tiện dùng chung để quản lý một cách hiệu quả
một số lượng lớn các đối tượng nhỏ có các đặc điểm chung,
mà các đối tượng nhỏ này lại được sử dụng tuỳ thuộc vào
hoàn cảnh, điều kiện ngoài.
304
4.4.6 Mẫu Flyweight
Trong đó:
o FlyweightFactory: tạo ra và quản lý các đối tượng Flyweight
o Flyweight là một giao tiếp định nghĩa các phương thức chuẩn
o ConcreteFlyweightX: là các lớp thực thi của Flyweight, các thể hiện của305
các lớp này sẽ được sử dụng tuỳ thuộc vào điều kiện ngoài.
Mẫu Flyweight
Ứng dụng sử dụng nhiều đối tượng giống hoặc gần
giống nhau
Với các đối tượng gần giống nhau, những phần
không giống nhau có thể tách rời với các phần giống
nhau để cho phép các phần giống nhau có thể chia sẻ
Nhóm các đối tượng gần giống nhau có thể được
thay thế bởi một đối tượng chia sẻ mà các phần không
giống nhau đã được loại bỏ
Nếu ứng dụng cần phân biệt các đối tương gần
giống nhau trong trạng thái gốc của chúng
306
Mẫu Flyweight
4. Ví dụ:
Một ví dụ cổ điển của mẫu flyweight là các kí tự được
lưu trong một bộ xử lí văn bản (word processor). Mỗi kí tự đại
diện cho một đối tượng mà có dữ liệu là loại font (font face),
kích thước font, và các dữ liệu định dạng khác. Bạn có thể
tưởng tượng là, với một tài liệu (document) lớn với cấu trúc dữ
liệu như thế này thì sẽ bộ xử lí văn bản sẽ khó mà có thể xử
lí được. Hơn nữa, vì hầu hết dữ liệu dạng này là lặp lại, phải
có một cách để giảm việc lưu giữ này – đó chính là mẫu
Flyweight. Mỗi đối tượng kí tự sẽ chứa một tham chiếu đến
một đối tượng định dạng riêng rẽ mà chính đối tượng này sẽ
chứa các thuộc tính cần thiết. Điều này sẽ giảm một lượng lớn
sự lưu giữ bằng cách kết hợp mọi kí tự có định dạng giống
nhau trở thành các đối tượng đơn chỉ chứa tham chiếu đến
cùng một đối tượng đơn chứa định dạng chung đó. 307
Mẫu Flyweight
308
Mẫu Proxy
1. Ý nghĩa:
Đại diện một đối tượng phức tạp bằng một đối tượng đơn giản,
vì các mục đích truy xuất, tốc độ và bảo mật
309
Mẫu Proxy
Trong đó:
oService: là giao tiếp định nghĩa các phương thức chuẩn cho một dịch vụ nào
đó
o RealService: là một thực thi của giao tiếp Service, lớp này sẽ khai báo
tường
yêu
minhcầu
cáctừphương
Servicethức của Service, lớp này xem như thực hiện tốt tất cả các310
o Proxy: kế thừa Service và sử dụng đối tượng của RealService
Mẫu Proxy
Sử dụng mẫu Proxy khi bạn cần một tham chiếu
phức tạp đến một đối tượng thay vì chỉ một cách bình
thường
Remote proxy – sử dụng khi bạn cần một tham chiếu
định vị cho một đối tượng trong không gian địa
chỉ(JVM)
Virtual proxy – lưu giữ các thông tin thêm vào về một
dịch vụ thực vì vậy chúng có thể hoãn lại sự truy xuất
vào dịch vụ này
Protection proxy – xác thực quyền truy xuất vào một
đối tượng thực
311
Mẫu Proxy
4. Ví dụ:
Ví dụ lớp Image là một interface định nghĩa các phương thức xử lý
ảnh, nó có các lớp con là GIFImage và JPGImage.
Theo hướng đối tượng thì thiết kế như thế có vẻ hợp lý, Client
chỉ cần sử dụng lớp Image là đủ, còn tuỳ thuộc vào loại ảnh sẽ có các
phương thức khác nhau
Nhưng trong trường hợp, trên ứng dụng web chẳng hạn, một lúc
ta đọc lên hàng trăm ảnh các loại và ta còn muốn xử lý tuỳ vào một điều
kiện nào đó (ví dụ chỉ xử lý khi là ảnh JPG hoặc GIF). Nếu ta đặt điều kiện
IF Image (sau đó sẽ tùy điều kiện này rồi xử lý riêng) thì không hợp lý, nếu
đặt trong Client, nếu mỗi lần cần thay đổi IF ta lại sửa Client => không hợp
lý khi Client là một ứng dụng lớn.
Ta sử dụng Proxy, lớp ImageProxy chỉ là lớp đại diện cho Image,
kế thừa từ Image và sử dụng các lớp GIFImage hay JPGImage. Khi cần
thay đổi ta chỉ cần thay đổi trên Proxy mà không cần tác động đến Client
và Image.
312
Mẫu Proxy
313
d. NHÓM CÁC MẪU TƯƠNG TÁC- Behavioral Patterns
1. Mục đích chung:

 mục đích mô tả sự tương tác giữa các đối tượng
314
Mẫu Chain of Responsibility
1. Ý nghĩa: Mẫu này thiết lập một chuỗi bên trong một hệ
thống, nơi mà các thông điệp hoặc có thể được thực hiện
ở tại một mức nơi mà nó được nhận lần đầu hoặc là được
chuyển đến một đối tượng mà có thể thực hiện điều đóTạo
một giao diện trung gian để gắn kết vào hệ thống một lớp
đối tượng mong muốn nào đó.
315
Trong đó:
o Handler: là một giao tiếp định nghĩa phương thức sử dụng để chuyển thông
điệp qua các lần thực hiện tiếp theo.
o ConcreteHandler: là một thực thi của giao tiếp Handler. Nó giữ một tham
chiếu đến một Handler tiếp theo. Việc thực thi phương thức handleMessage có
thể xác định làm thế nào để thực hiện phương thức và gọi một
handlerMethod, chuyển tiếp thông điệp đến cho Handler tiếp theo hoặc kết 316
hợp cả hai
 Có một nhóm các đối tượng trong một hệ thống có
thể đáp ứng tất cả các loại thông điệp giống nhau
 Các thông điệp phải được thực hiện bởi một vài các
đối tượng trong hệ thống
 Các thông điệp đi theo mô hình “thực hiện – chuyển
tiếp”, một vài sự kiện có thể được thực hiện tại
mức mà chúng được nhận hoặc tại ra, trong khi số
khác phải được chuyển tiếp đến một vài đối tượng
khác
317
4. Ví dụ:
Hệ thống quản lý thông tin cá nhân có thể được sử dụng để
quản lý các dự án như là các liên hệ.
Ta hình dung một cấu trúc cây như sau; đỉnh là một dự án,
các đỉnh con là các tác vụ của dự án đó, và cứ như vậy, mỗi
đỉnh con tác vụ lại có một tập các đỉnh con tác vụ khác.
Để quản lý cấu trúc này ta thực hiện như sau:
-Ở mỗi đỉnh ta lưu các thông tin như sau: tên tác vụ, đỉnh cha,
tập các đỉnh con
-Ta xét thông điệp sau: duyệt từ đỉnh gốc (project cở sở) in ra
các thông tin
-Như vậy với thông điệp này, việc in thông tin ở một đỉnh là
chưa đủ, ta phải chuyển tiếp đến in thông tin các đỉnh con
của đỉnh gốc và chuyển tiếp cho đến khi không còn đỉnh con
thì mới dừng 318
319
Mẫu Command
1. Ý nghĩa: Gói một mệnh lệnh vào trong một đối tượng mà
nó có thể được lưu trữ, chuyển vào các phương thức và
trả về một vài đối tượng khác.
Trong đó:
o Command: là một giao tiếp định
nghĩa các phương thức cho Invoker sử
dụng
o Invoker: lớp này thực hiện các
phương thức của đối tượng Command
oReceiver: là đích đến của Command
và là đối tượng thực hiện hoàn tất yêu
cầu, nó có tất cả các thông tin cần thiết
để thực hiện điều này
oConcreteCommand: là một thực thi
của giao tiếp Command. Nó lưu giữa
một tham chiếu Receiver mong muốn
320
Mẫu Command
Luồng thực thi của mẫu Command như sau:
321
Mẫu Command
Client gửi yêu cầu đến GUI của ứng dụng

Ứng dụng khởi tạo một đối tượng Command thích hợp cho yêu
cầu đó (đối tượng này sẽ là các ConcreteCommand)
Sau đó ứng dụng gọi phương thức executeCommand() với
tham
số là đối tượng Command vừa khởi tạo
Invoker khi được gọi thông qua phương thức
executeCommand() sẽ thực hiện gọi phương thức execute() của
đối tượng Command tham số
Đối tượng Command này sẽ gọi tiếp phương thức doAction()
của thành phần Receiver của nó, được khởi tạo từ đầu,
doAction() chính là phương thức chính để hoàn tất yêu cầu của
Client 322
Mẫu Command
 Hỗ trợ undo, logging hoặc transaction
 Thực hiện hàng đợi lệnh và thực hiện lệnh tại các
thời điểm khác nhau
 Hạn chế sự chặt chẽ của yêu cầu với đối tượng thực
hiện hoàn tất yêu cầu đó
323
Mẫu Interpreter
1. Ý nghĩa:
 Ý tưởng chính của Interpreter là triển khai ngôn ngữ máy
tính đặc tả để giải quyết nhanh một lớp vấn đề được định
nghĩa. Ngôn ngữ đặc tả thường làm cho vấn đề được giải
quyết nhanh hơn ngôn ngữ thông thường từ một cho đến
vài trăm lần.
 Ý tưởng tương tự như vậy biểu diễn các biểu thức tính
toán theo cú pháp Ba Lan
324
Mẫu Command
Trong đó:
Expression: là một giao tiếp mà thông qua nó, client tương tác với các biểu
thức
o TerminalExpression: là một thực thi của giao tiếp Expression, đại diện
cho
các nốt cuối trong cây cú pháp
oNonterminalExpression: là một thực thi khác của giao tiếp Expression, đại
diện cho các nút chưa kết thúc trong cấu trúc của cây cú pháp. Nó lưu trữ một
tham chiếu đến Expression và triệu gọi phương thức diễn giải cho mỗi phần tử
con
oContext: chứa thông tin cần thiết cho một vài vị trí trong khi diễn giải. Nó có
thể phục vụ như một kênh truyền thông cho các thể hiện của Expression
oClient: hoặc là xây dựng hoặc là nhận một thể hiện của cây cú pháp ảo. Cây
cú pháp này bao gồm các thể hiện của TerminalExpression và
NoterminalExpression để tạo nên câu đặc tả. Client triệu gọi các phương thứ3c25
Mẫu Interpreter
 Có một ngôn ngữ đơn giản để diễn giải vấn đề
 Các vấn đề lặp lại có thể được diễn giải nhanh bằng
ngôn ngữ đó
4. Ví dụ: Xét biểu thức 5 + 3 x 3 + 6, với bài tóan này ta có thể
chia thành các bài các bài tóan nhỏ hơn
-Tính 3 x 3 = a
-Sau đó tính 5 + a = b
-Sau đó tính b + 6
Ta biểu diễn bài tóan thành cấu trúc

cây và duyệt cây theo Ba Lan
326
Mẫu Interpreter
327
References
1. http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf
2. http://duydo.com/design-patterns-l%E1%BA%ADp-trinh-
vien-c%E1%BA%A7n-ph%E1%BA%A3i-bi%E1%BA%BFt/
Giới thiệu các mẫu thiết kế hướng đối tượng (Design Pattern)
3. http://duriangroup.wordpress.com/2007/10/27/gi%E1%BB%
9Bi-thi%E1%BB%87u-cac-m%E1%BA%ABu-
thi%E1%BA%BFt-k%E1%BA%BF-
h%C6%B0%E1%BB%9Bng-d%E1%BB%91i-
t%C6%B0%E1%BB%A3ng-design-pattern/
328
HẾT CHƯƠNG 3
329

Bai Giang Ptich

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bai Giang Ptich

Uploaded by

Copyright:

Available Formats

CHƯƠNG 1

PGS.TS. Nguyễn Mậu Hân

1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ

3. MÔ HÌNH HÓA MỘT HTTT

4. GIỚI THIỆU MỘT VÀI PHƯƠNG

5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT

6. CÁC CÁCH TIẾP CẬN TRONG PHÁT TRIỂN

• Thông tin (Informations):

• Hệ thống - Hệ thống thông tin

Hệ thống mở (hệ thống có tính xác suất) trong

Thông tin và Ra quyết định

Hệ thống thông tin (information system)

Tại sao phải phân tích thiết kế HT thông tin?

IBM đã thống kê được trong giai đoạn 1970-1980.

Phân tích về sai sót:

IBM đã thống kê được trong giai đoạn 1970-1980.

Phân tích về chi phí

Phân tích phân bổ hoạt

Microsoft đã thống kê được (2003)

Nhận xét: Các số liệu trên cho thấy:

 Chi phí chiếm tỉ trọng lớn nhất:

 Lượng công việc chiếm tỷ lệ lớn nhất:

 Hệ thống thông tin của một tổ chức là

(Management Information System, MIS)

Đặc điểm MIS

 Dự báo bán hàng (Sales forecasting)

VAI TRÒ, NHIỆM VỤ CỦA HTTT QUẢN LÝ

quyết định và hệ tác nghiệp trong hệ thống

 Thực hiện việc liên lạc giữa các bộ phận và

cung cấp thông tin cho các thành phần tác

Mô hình hóa là gì?

Mô hình: Quả địa

Thế giới thực

Làm chủ Con người Đọc  Sách

Tại sao phải mô hình hóa HTTT?

 Hình dung một hệ thống theo thực tế hay

Các yêu cầu của mô hình hoá:

 Có chức năng là một hệ hỗ trợ ra quyết định

 Chương trình dễ cài đặt, sửa chữa, bảo hành

 Hệ thống dễ sử dụng, có độ chính xác cao.

Khái niệm về một dự án CNTT thành công

Nguồn gốc: xuất phát từ Mỹ,

 Phân rã một hệ thống lớn thành các

Mô tả hệ thống: bao gồm dữ liệu và xử lý được biểu diễn ở ba

 Thiếu sự tiếp cận tổng thể trong phát triển HT

 Nghiên cứu nhu cầu (hệ thống cần gì?)

 Nghiên cứu khả thi (cân nhắc giữa nhu cầu và

 Mã hóa (tổ chức dữ liệu và lập trình)

 Thử nghiệm và khai thác

2. Phân tích khả thi và lập hồ sơ

Lập hồ sơ nhiệm vụ. Công việc này nhằm

 Thiết kế dữ liệu: xác định các đối tượng và cấu trúc dữ

 Thiết kế chức năng: định ra các modun xử lý thể hiện

 Thiết kế an toàn hệ thống

 Thiết kế phần cứng: tính toán các yêu cầu kỹ thuật, cơ

 Dự kiến nhân sự tại các vị trí công tác của hệ thống.

 xây dựng hệ thống bao gồm xây dựng các file cơ

 Hiệu chỉnh hệ thống

 Sửa đổi, khắc phục những thiếu sót của

Quá trình xây dựng một HTTT có thể mô tả

Xuất phát từ các nhu cầu:

 Cần có một mô hình hoặc một ngôn ngữ đặc tả

a. Mức quan niệm: