PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Nội dung

v Hệ thống thông tin (HTTT)

• Một số khái niệm cơ bản
• Biểu diễn hệ thống thông tin
v Phương pháp luận phát triển các HTTT
• Tiếp cận định hướng tiến trình
• Tiếp cận định hướng dữ liệu
• Tiếp cận định hướng cấu trúc
• Tiếp cận định hướng đối tượng
v Mô hình hoá trực quan
• Tầm quan trọng
• Giới thiệu một số loại mô hình
• 4 nguyên tắc cơ bản 2
 Hệ thống

v Hệ thống là tập hợp các thành phần có quan hệ chặt chẽ với nhau
tạo thành một thể thống nhất.
v Cấu tạo: Môi trường, mục đích, giới hạn, thành phần, mối quan hệ,
giao diện, đầu vào, đầu ra và các ràng buộc.

3
Ví dụ một hệ thống

Môi trường: Khách hàng, nhà cung cấp …

Đầu vào: Đầu ra:

Băng đĩa, Kho Băng đĩa,
Phòng
tiền mặt, kinh tiền mặt,
lao động,
doanh bảng giá,
tài sản Văn phòng
... hóa đơn
…
Giới hạn
4
 Các khái niệm

v Dữ liệu là tập hợp các dấu hiệu hoặc các quan sát được ghi lại tại thời
điểm không gây nên các tác động đến hành vi, đến việc ra quyết định.
v Thông tin là sự hiểu biết có được từ số liệu; là sự phát biểu về cơ cấu
của một thực thể mà nó giúp cho con người ra quyết định hoặc đưa ra
một cam kết; là nội dung chứa trong các văn bản, tài liệu hoặc lời nói.

Thông
Dữ liệu Xử lý
tin

5
 Thông tin

v Thuộc tính:
• Chi phí
• Giá trị
v Thông tin tốt:
• Phải thích hợp
• Phải kịp thời
• Phải chính xác
• Làm giảm điều chưa rõ
• Chứa yếu tố gây bất ngờ

6
 Hệ thống thông tin

v Một nhóm các thành phần tương tác với nhau để tạo ra thông tin.
v Một hệ thống xử lý thông tin để hỗ trợ cho các hệ thống công việc.
• Thu thập, truyền tải, lưu trữ, phục hồi, phân tích, xử lý và hiển thị thông tin.
• Chức năng chính là xử lý thông tin.
• Quá trình xử lý thông tin giống như một hộp đen.
v Một tập hợp và kết hợp của các thành phần sử dụng để thu thập, tạo, tái
tạo, phân phối và chia sẻ các dữ liệu, thông tin và tri thức nhằm phục vụ
các mục tiêu của tổ chức.

7
Phân loại các hệ thống thông tin

8
 Biểu diễn các hệ thống thông tin
v Không gian biểu diễn các HTTT là một không gian ba chiều.
Các mức nhận thức

Quan niệm

Tổ chức
Vật lý
Các thành phần
Dữ liệu Bộ xử lý CPU Con người Cơ sở
hạ tầng
- Lập kế hoạch
- Nghiên cứu tính khả thi
Các bước phát triển 9
-…
 Vòng đời phát triển hệ thống

v Vòng đời phát triển hệ thống SDLC (System Development Life Cycle)
bao gồm nhiều giai đoạn, kể từ khi bắt đầu phát triển hệ thống cho
đến khi kết thúc khai thác hệ thống.
v Các bước chính phát triển hệ thống trong thực tiễn:
• Lập kế hoạch
• Nghiên cứu tính khả thi, khảo sát hiện trạng
• Hợp đồng ràng buộc trách nhiệm
• Phân tích, thiết kế
• Cài đặt và thử nghiệm
• Triển khai
• Bảo trì, thích ứng 10
 Phương pháp luận phát triển các HTTT

v Tiếp cận định hướng tiến trình:

• Thay đổi một tiến trình xử lý -> thay đổi dữ liệu tương ứng.
• Không thể chia sẻ dữ liệu giữa các ứng dụng với nhau.
• Các ứng dụng khác nhau có thể chứa những phần tử dữ liệu giống nhau.
Ø Tạo ra sự dư thừa dữ liệu.
Ø Tốn công sức và thời gian để thu thập và tổ chức lại dữ liệu.

Hệ thống quản lý tiền lương Hệ thống quản lý dự án

• Dữ liệu nhân sự • Dữ liệu nhân sự

• Dữ liệu thuế • Dữ liệu dự án
• … • …

11
 Phương pháp luận phát triển các HTTT (tt.)
v Tiếp cận định hướng dữ liệu: Tự động hoá các quá trình xử lý
và tổ chức dữ liệu.

Ứng dụng 1 Ứng dụng 2 Ứng dụng n

Cơ sở dữ liệu

• Ý tưởng: Tách dữ liệu ra khỏi các quá trình xử lý, tách cơ sở dữ liệu khỏi các ứng
dụng.
• Ưu điểm: Tối ưu về phương diện lưu trữ và sử dụng, dữ liệu được tổ chức một cách
tập trung và nhất quán.
• Nhược điểm: Trong thực tiễn rất khó tổ chức dữ liệu một cách tập trung. 12
 Phương pháp luận phát triển các HTTT (tt.)

v Tiếp cận định hướng cấu trúc:

• Cải tiến của tiếp cận định hướng dữ liệu.
• Cải tiến cấu trúc các chương trình -> mô-đun hoá.
Ø Dễ theo dõi, quản lý và bảo trì.
• Đặc tính cấu trúc được thể hiện qua cấu trúc dữ liệu, cấu trúc HTTT,
cấu trúc chương trình và mô-đun.
• Cung cấp đầy đủ các đặc tả hệ thống, logic hệ thống.
• Nhược điểm:
Ø Rất khó thay đổi cấu trúc HTTT và cơ cấu tổ chức của cơ quan doanh nghiệp để
thích ứng với nhu cầu của môi trường kinh doanh.

13
 Phương pháp luận phát triển các HTTT (tt.)
v Mô hình hệ thống định hướng cấu trúc:

14
 Phương pháp luận phát triển các HTTT (tt.)
v Tiếp cận định hướng đối tượng: Hướng tới việc xây dựng hệ thống
gồm các đối tượng liên kết với nhau.

15
 Phương pháp luận phát triển các HTTT (tt.)
v Tiếp cận định hướng đối tượng (tt.):
• Các đối tượng thường tương ứng với các thực thể trong HTTT.
• Các đối tượng chứa dữ liệu và hành vi (xử lý).
• Hoạt động của một đối tượng không làm ảnh hưởng đến các đối tượng khác.
• Các đối tượng được ghép nối với nhau thành một hệ thống hoàn chỉnh thông qua
việc trao đổi thông điệp.
• Cải thiện đáng kể chất lượng của hệ thống.
Ø Hệ thống được “lắp ghép” và “tháo dỡ” dễ dàng.
Ø Dễ bảo trì.
Ø Có khả năng tái sử dụng.
Ø Có thể mở rộng phạm vi của hệ thống.
Ø Tăng năng suất của hoạt động phân tích và thiết kế.
• Nhược điểm:
Ø Việc quản lý các đối tượng và mối quan hệ giữa chúng tương đối phức tạp. 16
 Mô hình hoá trực quan
v Một mô hình là một mô tả về các đặc tính tĩnh và(hoặc) động của một chủ
thể, nó thường được mô tả dưới dạng một biểu đồ hoặc văn bản thông qua
một số khung nhìn nào đó. (Applying UML and Patterns, 2004)
v Các mô hình giúp đơn giản hoá thế giới thực.

17
Ví dụ về mô hình

Thế giới thực Mô hình: Quả địa cầu

Thế giới thực

Làm chủ Đọc

Ô tô Con người Sách Mô hình

18
 Các đội dự án xây dựng ứng dụng thường
không mô hình hoá

v Bắt đầu lập trình ngay khi có được yêu cầu.

v Mất rất nhiều thời gian và công sức.
v Tạo ra rất nhiều mã nguồn.
v Không có bất kỳ một kiến trúc nào.
v Gặp khó khăn với những lỗi phát sinh.
-> Mô hình hoá là một con đường dẫn đến thành công của
các dự án phát triển phần mềm.

19
 Tại sao phải mô hình hoá?

v Hình dung về hệ thống như mong đợi.

v Chỉ định cấu trúc hoặc hành vi cho hệ thống.
v Đưa ra một khuôn mẫu hướng dẫn xây dựng hệ thống.
v Tài liệu hoá hệ thống.
v Hiểu rõ hơn về hệ thống cần phát triển.

20
Mô hình phân cấp chức năng
v Phân rã một chức năng tổng hợp thành những chức năng chi tiết hơn.
Chức năng

Hệ thống quản lý
cửa hàng
Quan hệ bao hàm

Kinh doanh Kế toán Quản lý kho

Quản lý đơn Quản lý Quản lý nhập Quản lý Quản lý

Bán lẻ hàng công nợ hàng xuất hàng hàng tồn

21
Mô hình luân chuyển (hệ thống)
v Quá trình xử lý đơn đặt hàng:

22
Mô hình dòng dữ liệu DFD (Data Flow Diagram)
v Mô hình DFD xử lý đơn đặt hàng:
ĐĐH
Kiểm hợp lệ Lưu
Đơn đặt hàng tra ĐĐH ĐĐH mới
ĐĐH Xử lý
Đơn đặt hàng
Khách hàng
ĐĐH không hợp lệ ĐĐH Dòng dữ liệu
Đầu cuối
ĐĐH bị từ chối Tính
Thông tồn kho Kho dữ liệu
báo từ Tồn kho băng đĩa

Băng đĩa giao + hóa đơn chối Thông tin tồn kho
ĐĐH
ĐĐH đủ hàng giao

Lập hóa
Hóa đơn giao hàng
đơn giao
hàng Hoá đơn giao hàng
23
Mô hình động (mô hình trạng thái)
v Các trạng thái của một đơn đặt hàng:

24
 Mô hình dữ liệu (mô hình quan hệ)

v BANGDIA(MA_BD, TEN_BD, LOAI, DVTINH, DON_GIA)

v ĐĐHANG_NGK(SO_DDH, NGAY_DAT, KHACH_HANG,

NGAYGIAO, TRANG THAI)

v CHITIET_DDH(MA_BD, SO_DDH, SL_DAT, DONGIA_DAT)

25
Mô hình dữ liệu (mô hình thực thể kết hợp)

26
Mô hình đối tượng
v Mô hình đối tượng theo OOA:

BANGDIA
n Mã số
Đối tác
Tên
Mã số
Đơn giá
Tên
Địa chỉ Lớp & đối Kết hợp
1 tượng
n
n BD đặt
Số lượng đặt
Nhà cung ứng Khách hàng
Trị giá()
Công nợ tối đa Tổng quát hoá Thành phần
Trị giá đặt hàng() (Is – Part - Of)
(IS – A)
1
ĐĐ Hàng
Mã số
Tổng trị giá Thông điệp
n Tính trị gia ĐĐ hàng() (Message)

27
 4 nguyên tắc cơ bản trong mô hình hoá

v Việc lựa chọn mô hình đóng vai trò rất quan trọng:
• Trong phát triển phần mềm, các mô hình được chọn bị ảnh hưởng từ
thế giới quan.
• Mỗi thế giới quan dẫn đến một loại hệ thống riêng biệt.

v Mỗi mô hình mô tả hệ thống với mức độ chính xác khác nhau:

• Việc lựa chọn mức độ chi tiết phụ thuộc:
• Ai đang xem mô hình?
• Tại sao cần phải xem mô hình?

28
 4 nguyên tắc cơ bản khi mô hình hoá (tt.)

v Các mô hình tốt nhất là các mô hình liên kết với thế giới thực:
• Tất cả các mô hình đều là quá trình đơn giản hoá thế giới thực.
• Một mô hình tốt sẽ phản chiếu các đặc tính bất thường tiềm ẩn.
v Không mô hình đơn lẻ nào là đầy đủ:
• Cách tiếp cận tốt nhất để xây dựng một hệ thống phần mềm là thông qua
một tập các mô hình gần như độc lập với nhau.

29
PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
Nội dung

v Giới thiệu về UML

v Lịch sử phát triển của UML

v Mục đích sử dụng UML

v Các khối cơ bản trong UML

v Các khung nhìn UML

2
 Giới thiệu về UML

v UML (Unified Modeling Language) là một ngôn ngữ mô hình hoá

trực quan và mang tính khái quát.
v UML có thể được sử dụng cho mọi quy trình phát triển, xuyên
suốt vòng đời phát triển, cho hầu hết các miền ứng dụng và độc
lập với các công nghệ cài đặt.
v UML bao gồm các khái niệm, các ký pháp đồ hoạ, các biểu đồ và
các quy tắc …
v UML là một tiêu chuẩn được sử dụng rộng rãi trong cộng đồng IT.

3
 Lịch sử phát triển của UML

v Vào 1994 có hơn 50 phương pháp mô hình hoá hướng đối tượng
(Fusion, ROOM, BOOM, Ooram, DOORS …)
• Các ký pháp đồ hoạ khác nhau.
• Quy trình khác nhau hoặc không rõ ràng.
-> Cần chuẩn hoá và thống nhất các phương pháp.
v 3 chuyên gia hướng đối tượng hợp nhất các kỹ thuật của họ vào năm
1994 -> UML.
• Booch91 (Grady Booch): Conception, Architecture
• OOSE (Ivar Jacobson): Use Cases
• OMT (Jim Rumbaugh): Analysis
v UML được công nhận là chuẩn chung vào năm 1997 -> một phương
thức thống nhất để xây dựng và mô hình hoá các yêu cầu, thiết kế
hướng đối tượng trong quá trình PTTK phần mềm. 4
Lịch sử phát triển của UML (tt.)
Meyer Harel Gamma, et al
State charts
Before and after Frameworks, patterns, notes
conditions
HP Fusion
Operation descriptions and
Booch message numbering
Booch method

Embley
Rumbaugh Singleton classes and
Object Modeling high-level view
Technique

Jacobson Wirfs-Brock
Object-Oriented Responsibilities
Software Engineering
Shlaer - Mellor Odell
Object lifecycles Classification

-> UML là một ngôn ngữ hợp nhất 5

Lịch sử phát triển của UML (tt.)

Lý giải tính thống nhất của ngôn ngữ mô hình hoá UML? 6
Lịch sử phát triển của UML (tt.)

UML 2.0
(2004)
UML 1.5
(March, ‘03)

UML UML 1.1

(Sept. ‘97)
Partners’
Expertise UML 1.0
(Jan. ‘97)
UML 0.9 and UML 0.91
(June, ‘96) (Oct. ‘96) Public
Unified Method 0.8 Feedback
(OOPSLA ’95)

Booch ’93 OMT - 2

OOSE Other
Booch ‘91 OMT - 1 7
Methods
Mục đích sử dụng UML

v UML là một ngôn ngữ được sử dụng để:

• Mô hình hoá
• Biểu diễn
• Đặc tả
• Xây dựng
• Tài liệu hoá
-> các chế tác (artifact) của một hệ thống phần mềm.
v UML còn được sử dụng để mô hình hoá các hệ thống phi phần
mềm như luồng công việc hay cho hoạt động thiết kế phần cứng.

8
UML là ngôn ngữ mô hình hoá

v UML là phương tiện để diễn đạt các mô hình hệ thống dựa

trên sự tổ hợp các từ vựng có sẵn của UML theo tập quy tắc
xác định.
v Tập từ vựng và quy tắc ngôn ngữ UML cung cấp cơ sở để
xây dựng và đọc hiểu các mô hình.
• Không xác định thời điểm và trình tự tạo các mô hình.

9
UML là ngôn ngữ trực quan hoá để hiển thị

v Sự giao tiếp giữa các mô hình mức khái niệm dễ phát sinh lỗi
trừ khi những người liên quan dùng chung một ngôn ngữ
diễn đạt.
v Một số yếu tố trong hệ thống phần mềm cần phải mô hình
hoá mới có thể hiểu được.
v Một số thông tin sẽ bị mất đi (không được cài đặt) nếu nhóm
phát triển không tài liệu hoá các mô hình đang hình dung.

10
UML là ngôn ngữ để đặc tả

v UML mô tả vấn đề một cách chính xác, không nhập nhằng.

v UML hỗ trợ đặc tả phân tích, thiết kế và các giải pháp cài
đặt trong vòng đời phát triển hệ thống.

11
UML là ngôn ngữ để xây dựng hệ thống

v Một số biểu đồ UML có thể được chuyển thành mã nguồn của

nhiều ngôn ngữ lập trình khác nhau (Java, C++ …).
• Cho phép kỹ nghệ xuôi (chuyển các mô hình UML thành mã nguồn).
• Cho phép kỹ nghệ ngược (xây dựng mô hình hệ thống từ mã nguồn).
v Tăng khả năng tự động hoá trong quá trình phát triển phần mềm.

12
 UML là ngôn ngữ để tài liệu hoá

v Các biểu đồ UML đóng vai trò là các tài liệu phát triển hệ thống.
v UML hỗ trợ tạo tài liệu kiến trúc hệ thống cùng các chi tiết của nó.
v UML cho phép diễn đạt các yêu cầu.
v UML cung cấp ngôn ngữ để mô hình hoá các hoạt động trong dự
án cũng như việc quản lý chuyển giao phiên bản.

13
Các khối cơ bản trong UML

v Các khối hình thành nên các mô hình UML: Phần tử cấu trúc
Phần tử hành vi
• Phần tử Phần tử nhóm gộp
• Quan hệ Phần tử chú thích
• Biểu đồ
v Các phần tử là các trừu tượng hoá căn bản trong các mô hình
UML, các quan hệ gắn các phần tử lại với nhau, biểu đồ nhóm
các phần tử có mối quan hệ lại với nhau.
v Các phần tử là các khối xây dựng hướng đối tượng của UML.

14
Các phần tử cấu trúc

Person
name Borrow
age
eat() Comparable Use Case
talk()
Interface
Class

Server

Collaboration Component Node

15
Các phần tử hành vi

call Cancelled

Message State

16
Phần tử nhóm và phần tử chú thích

Tên gói

Note Package

17
Các quan hệ trong UML

Dependence

Association

Generalization

Realization

18
Các biểu đồ trong UML

Biểu đồ

Ca sử dụng Lớp Máy trạng thái Hoạt động Triển khai

Đối tượng Tuần tự Giao tiếp Thành phần

v Ngoài ra, trong UML còn có biểu đồ gói, biểu đồ cấu trúc bên
trong, biểu đồ cộng tác, biểu đồ thời gian. 19
Biểu diễn hệ thống theo 3 loại mô hình

Biểu đồ ca sử dụng Mô hình chức năng

Biểu đồ lớp
Biểu đồ đối tượng

Biểu đồ tuần tự Mô hình cấu trúc

Biểu đồ giao tiếp
Biểu đồ trạng thái
Biểu đồ hoạt động

Mô hình thời gian

20
Các khung nhìn UML

v Một khung nhìn (view) UML là một tập con của các cấu trúc mô hình
hoá UML, nó đại diện cho một khía cạnh của hệ thống. (The Unified
Modeling Language Reference Manual, 2005)
v Các khung nhìn UML giúp tổ chức và trình bày các khái niệm UML.
v Các khung nhìn UML có thể được chia thành 4 góc nhìn chính:
• Cấu trúc mô tả những thứ bên trong hệ thống và mối quan hệ giữa chúng
(khung nhìn tĩnh, khung nhìn thiết kế, khung nhìn ca sử dụng).
• Động mô tả hành vi của hệ thống hoặc các classifier theo thời gian (khung nhìn
máy trạng thái, khung nhìn hoạt động, khung nhìn tương tác).
• Vật lý mô tả các tài nguyên vật lý trong hệ thống và việc triển khai các chế tác
trên chúng (khung nhìn triển khai).
• Quản lý mô hình mô tả việc tổ chức các mô hình thành các phần tử phân cấp
(khung nhìn quản lý mô hình).
21
 Khung nhìn tĩnh

v Mô hình hoá các khái niệm trong miền ứng dụng một cách logic.
v Không mô tả hành vi hệ thống.
v Các thành phần chính của khung nhìn tĩnh là các lớp và mối
quan hệ giữa chúng (association, generalization, dependency,
realization).
v Khung nhìn tĩnh được thể hiện trong các biểu đồ lớp.

22
Khung nhìn tĩnh (tt.)
v Biểu đồ lớp của hệ thống quản lý thư viện:

23
 Khung nhìn thiết kế

v Khung nhìn thiết kế mô hình hoá cấu trúc thiết kế của ứng dụng.
v Khung nhìn thiết kế ánh xạ các lớp vào các thành phần thực thi.
v Khung nhìn thiết kế bao gồm:
• Biểu đồ cấu trúc bên trong.
• Biểu đồ cộng tác.
• Biểu đồ thành phần.

24
Khung nhìn thiết kế (tt.)

v Biểu đồ thành phần của hệ thống đăng ký môn học:

Billing.exe Register.exe
Billing
System

People.dll
Course.dll User
Course

Student Professor
Course Course
Offering

25
 Khung nhìn ca sử dụng

v Khung nhìn ca sử dụng biểu diễn các chức năng và môi

trường dự kiến của hệ thống dưới góc nhìn của người
dùng cuối.
v Khung nhìn ca sử dụng nắm bắt các hành vi của hệ thống.

26
 Khung nhìn ca sử dụng (tt.)
v Biểu đồ ca sử dụng của hệ thống đăng ký môn học:

27
 Khung nhìn máy trạng thái

v Một máy trạng thái (state machine):

• Mô hình hoá lịch sử vòng đời có thể có của một đối tượng.
• Chứa các trạng thái được kết nối với nhau bởi các chuyển tiếp
(transitions).
• Mỗi trạng thái mô hình hoá một khoảng thời gian trong vòng đời
của một đối tượng.
• Khi một sự kiện xảy ra -> kích hoạt một chuyển tiếp -> chuyển
đối tượng sang một trạng thái mới.

28
 Khung nhìn máy trạng thái (tt.)

v Biểu đồ trạng thái của một đơn đặt hàng:

29
 Khung nhìn hoạt động

v Biểu đồ hoạt động là trường hợp đặc biệt của biểu đồ trạng thái.
v Biểu diễn luồng hoạt động trong hệ thống.
v Biểu đồ hoạt động chứa các nút hoạt động được kết nối với nhau
bởi các luồng điều khiển.
v Biểu đồ hoạt động nhấn mạnh luồng điều khiển giữa các đối tượng.

30
Khung nhìn hoạt động (tt.)

v Biểu đồ hoạt động của ca sử dụng Đăng ký môn học:

31
 Khung nhìn tương tác

v Một tương tác là hành vi được mô tả bằng cách chỉ ra chuỗi thông
điệp trao đổi (truyền và nhận) giữa các đối tượng.
v Các đối tượng tương tác với nhau để thực hiện một kịch bản.
v Khung nhìn tương tác mô tả trình tự trao đổi thông điệp giữa các đối
tượng của hệ thống.
v Khung nhìn tương tác cung cấp một cái nhìn toàn diện về hành vi
của hệ thống, chỉ ra luồng điều khiển trên nhiều đối tượng.
v Khung nhìn tương tác được thể hiện trong:
• Biểu đồ tuần tự.
• Biểu đồ giao tiếp.

32
Khung nhìn tương tác (tt.)
v Biểu đồ tuần tự cho luồng con "Create a Schedule" của ca sử dụng
"Register for Course":

33
 Khung nhìn triển khai

v Khung nhìn triển khai biểu diễn cấu hình của các nút xử lý và các
chế tác trên các nút xử lý đó tại run-time.
• Một chế tác (artifact) là một thành phần thực thi dạng vật lý, một
phần thông tin được sử dụng hoặc được tạo ra trong quy trình phát
triển phần mềm.
• Một nút (node) là một tài nguyên tại run-time, biểu diễn một
thực thể vật lý của hệ thống (máy tính, bộ nhớ, thiết bị …).
v Biểu đồ triển khai mô tả khung nhìn triển khai tĩnh của một kiến trúc.

34
 Khung nhìn triển khai (tt.)
v Biểu đồ triển khai của một Website:

35
 Khung nhìn quản lý mô hình

v Khung nhìn quản lý mô hình mô hình hoá việc tổ chức của

các mô hình được tạo ra.
v Bao gồm một tập các gói, mỗi gói chứa các phần tử mô hình
(các lớp, các ca sử dụng …).
v Một gói có thể chứa nhiều gói khác.
v Thông tin quản lý mô hình thường được hiển thị trên biểu đồ gói.

36
Công cụ UML

v StarUML
v ArgoUML
v EclipseUML
v UmlDesigner
v Enterprise Architect
v IBM Rational Software Architect

37
PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Nội dung

v Các khái niệm hướng đối tượng

v Quy trình phát triển hướng đối tượng

v Tổng quan về phân tích và thiết kế hướng đối tượng

2
 Các khái niệm hướng đối tượng

v 4 nguyên tắc chính trong mô hình hoá hướng đối tượng

• Sự trừu tượng hoá

• Tính đóng gói

• Tính mô-đun hoá

• Sự phân cấp

v Tính đa hình

v Tổng quát hoá và kế thừa

3
4 nguyên tắc chính trong mô hình hoá
hướng đối tượng

4
 Trừu tượng hoá

v Mô hình hoá là quá trình trừu tượng hoá các đối tượng trong thế giới thực vào
ngữ cảnh của hệ thống.
v Trừu tượng hoá có thể được định nghĩa là các đặc điểm cần thiết của một
thực thể để phân biệt nó với tất cả các loại thực thể khác.
v Trong mô hình hoá hướng đối tượng, trừu tượng hoá là việc xây dựng
một mô hình chỉ bao gồm các đặc điểm quan trọng, cần thiết để phân biệt
nó với tất cả các loại mô hình khác.
• Tạo ra mô hình có các đặc tính riêng biệt.
• Cho phép quản lý sự phức tạp của mô hình.
v Sự trừu tượng hoá theo các mức độ khác nhau là nguyên tắc cơ bản để
xây dựng các khái niệm hướng đối tượng.
5
Ví dụ về sự trừu tượng hoá

Professor
Student

6
 Tính đóng gói

v Tính đóng gói là sự quy tụ các tính chất (các thuộc tính và các hành
vi) của một thực thể vào trong một hộp đen trừu tượng.
v Cho phép người sử dụng dùng đối tượng mà không biết bên trong
đối tượng có những gì.
v Tính đóng gói -> khái niệm che dấu thông tin.
v Tính đóng gói dữ liệu của OOP:
• Cho phép che dấu sự cài đặt bên trong các phương thức.
• Cho phép che dấu dữ liệu bên trong các đối tượng.
• Cho phép giảm thiểu việc viết lại mã nguồn chương trình.

7
 Tính đóng gói (tt.)

v Trong OOP, dữ liệu luôn được tổ chức thành các thuộc tính của lớp
đối tượng.
• Việc truy nhập vào dữ liệu phải thông qua các phương thức cho phép
của đối tượng tương ứng.
v Cho phép che dấu sự cài đặt bên trong các client.
• Các client phụ thuộc vào interface.

8
 Tính mô-đun hoá

v Sự phân rã về mặt vật lý hoặc logic một thứ gì đó phức tạp thành các
phần nhỏ hơn, cấu trúc đơn giản hơn và có thể quản lý được.
v Phân rã các hệ thống phần mềm lớn và phức tạp thành các mô-đun
nhỏ hơn, các mô-đun này được phát triển độc lập và có thể tương tác
được với nhau.

9
 Sự phân cấp

v Sự sắp xếp thứ tự hoặc phân hạng sự trừu tượng hoá của các đối
tượng theo một cấu trúc cây.
v Sự phân cấp là một cách tổ chức theo kiểu phân loại.
• Phân cấp lớp.
• Phân cấp sự kế thừa.
• Phân cấp theo kiểu của đối tượng.
v Trong kỹ thuật hướng đối tượng, sự phân cấp được sử dụng
để tổ chức các đối tượng trong hệ thống.

10
Ví dụ về sự phân cấp

v Các phần tử cùng cấp bậc trong hệ thống phân cấp sẽ

có cùng mức độ trừu tượng hoá. 11
 Tính đa hình

v Trong kỹ thuật hướng đối tượng, tính đa hình có thể được định nghĩa là
khả năng mang nhiều kiểu khác nhau của đối tượng.
v Tính đa hình cho phép cùng một thông điệp gửi đi, có thể được xử lý
theo các cách khác nhau tuỳ thuộc vào đối tượng nhận nó.
v Tính đa hình cho phép che dấu nhiều sự cài đặt khác nhau đằng sau
một giao diện duy nhất.

Manufacturer A Manufacturer B Manufacturer C

12
 Tính đa hình (tt.)

v Trong lập trình hướng đối tượng:

• Đa hình phương thức: Phương thức trùng tên, phân biệt bởi
danh sách tham số (Overload và Override).
• Đa hình đối tượng:
• Nhìn nhận đối tượng theo nhiều kiểu khác nhau (Upcasting và
Downcasting).
• Các đối tượng khác nhau thực hiện cùng một thông điệp nhưng
giải nghĩa thông điệp đó theo những cách thức khác nhau.

13
 Tổng quát hoá

v Tổng quát hoá (generalization) là một mối quan hệ giữa các lớp (hoặc các ca
sử dụng), trong đó tồn tại một lớp (hoặc một ca sử dụng) sẽ chia sẻ cấu trúc
và/hoặc hành vi cho một hoặc nhiều lớp (ca sử dụng) khác.
v Xác định một sự phân cấp mức độ trừu tượng hoá, trong đó tồn tại một
lớp con kế thừa từ một hoặc nhiều lớp cha.
• Đơn kế thừa.
• Đa kế thừa.
v Mối quan hệ kiểu “is a kind of”.
v Phân biệt hai thuật ngữ “Tổng quát hoá” và “Kế thừa”?

14
Ví dụ về đơn kế thừa

Ancestor
Account
- balance
Superclass - name
(parent) - number

+ withdraw()
+ createStatement()

Generalization
Relationship

Subclasses Savings Checking

(children)

Descendents 15
 Ví dụ về đa kế thừa

v Cơ chế đa kế thừa được sử dụng để mô tả chính xác thế giới quan và làm
giảm độ phức tạp trong các mô hình hướng đối tượng.

16
 Quy trình phát triển hướng đối tượng
v 3 đặc trưng chính của việc phát triển các HTTT theo phương pháp
tiếp cận hướng đối tượng:
• Định hướng bởi các ca sử dụng
• Lấy kiến trúc làm trung tâm
• Phát triển lặp và gia tăng
v Một số khía cạnh trong phát triển phần mềm:
• Triệu chứng
• Căn nguyên
• Hướng giải quyết
v Quy trình phát triển RUP (Rational Unified Process):
• Giới thiệu
• Các pha
• Các hoạt động
• Bộ kinh nghiệm thực tiễn 17
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng

v Định hướng bởi các ca sử dụng:

• Một ca sử dụng là một chuỗi các hành động mà hệ thống sẽ thực hiện
để đạt được một kết quả có thể quan sát được bởi một tác nhân cụ
thể. Nó định nghĩa một chức năng có thể sử dụng được từ hệ thống.
• Đặc tả ca sử dụng mô tả cách người dùng tương tác với hệ thống.
• Các ca sử dụng là công cụ mô hình hoá chính.
• Các ca sử dụng được dùng để xác định hành vi của hệ thống.

18
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng (tt.)

v Lấy kiến trúc làm trung tâm:

• Kiến trúc phần mềm chứa đựng một tập các quyết định thiết yếu về
thiết kế và tổ chức hệ thống phần mềm. Kiến trúc phần mềm phản
ánh các khía cạnh cấu trúc (khía cạnh tĩnh), hành vi (khía cạnh động)
và cách tổ chức phân cấp trong hệ thống.
• Kiến trúc có thể được xem như là các ràng buộc cho khâu thiết kế và
xây dựng hệ thống.
• Lấy kiến trúc làm nền tảng cho đặc tả, phân tích, thiết kế, xây
dựng và tài liệu hoá hệ thống.
• Việc tạo ra và hợp lệ kiến trúc sớm là mục tiêu chính trong các
lần lặp đầu của hoạt động phân tích và thiết kế.
19
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng (tt.)
v Phát triển lặp và gia tăng:
• Phát triển lặp là một kỹ thuật được sử dụng để chuyển các chức năng của hệ thống
vào một chuỗi liên tục các phiên bản hoàn thiện tăng dần.
• Mỗi phiên bản được phát triển trong một khoảng thời gian xác định -> lần lặp.
• Mỗi lần lặp tập trung vào định nghĩa, phân tích, thiết kế, xây dựng, tích hợp và kiểm
thử một tập các yêu cầu -> một phiên bản thực thi được.
• Mỗi lần lặp sẽ đưa hệ thống ngày càng gần hơn với mong đợi sau cùng của user.
• Các lần lặp đầu tiên hướng đến những rủi ro có mức độ ưu tiên cao nhất.
• Lựa chọn một tập con các chức năng (hoặc một tập tối thiểu các ca sử dụng liên
quan) để phát triển -> kiểm chứng (thông qua một tập các ca kiểm thử thực hiện
được) -> gia tăng.
• Việc thẩm định các phiên bản (thực thi được) sẽ được tiến hành liên tục trong
suốt vòng đời phát triển của hệ thống.
20
 Một số vấn đề trong phát triển phần mềm
Triệu chứng

v Trong kỹ thuật phần mềm, triệu chứng là biểu hiện về sự tồn tại các vấn đề
xấu trong vòng đời phát triển phần mềm.
v Các triệu chứng điển hình:
• Yêu cầu không được đáp ứng.
• Yêu cầu thay đổi quá nhanh.
• Các mô-đun không lắp ghép được.
• Bảo trì khó.
• Phát hiện lỗi muộn.
• Chất lượng kém.

v Hạn chế các triệu chứng -> phát triển phần mềm chất lượng cao theo định
hướng phát triển lặp.
21
 Một số vấn đề trong phát triển phần mềm
Căn nguyên

v Xử lý những căn nguyên -> hạn chế được các triệu chứng.

Yêu cầu không được Các mô-đun không lắp Phát hiện lỗi muộn -
đáp ứng ghép được Chất lượng kém

Định nghĩa yêu cầu phần Giao tiếp nhập nhằng Ít được kiểm thử
mềm không chính xác.
Thu thập yêu cầu thiếu. Tồn tại phi nhất quán Đánh giá chủ quan

22
 Một số vấn đề trong phát triển phần mềm
Hướng giải quyết

v Định nghĩa yêu cầu phần mềm không chính xác -> Phát triển lặp.
v Thu thập yêu cầu thiếu -> Quản lý yêu cầu.
v Giao tiếp nhập nhằng -> Mô hình hoá trực quan (UML).
v Tồn tại phi nhất quán -> Kiểm tra liên tục.
v Ít được kiểm thử -> Kiểm tra chất lượng thường xuyên.
• Kiểm thử chức năng.
• Kiểm thử tính khả dụng.
• Kiểm thử độ tin cậy.
• Kiểm thử hiệu năng.
• Kiểm thử tính hỗ trợ.
23
 Giới thiệu quy trình phát triển RUP
(Rational Unified Process)

v Quy trình phát triển hướng đối tượng, được áp dụng rộng rãi.
v RUP được mô tả từ 3 khung nhìn:
• Khung nhìn động -> chỉ ra các pha của mô hình RUP theo chiều thời gian.
• Khung nhìn tĩnh -> chỉ ra các hoạt động trong quy trình RUP.
• Khung nhìn thực tiễn -> đề xuất bộ kinh nghiệm thực hành tốt được sử
dụng trong quy trình RUP.

24
 Các pha của quy trình phát triển RUP

v H

v Pha khởi đầu (Inception): Định nghĩa phạm vi, xác định tất cả các tác
nhân và các ca sử dụng có thể có, đánh giá các ca sử dụng nào là cần
thiết nhất. Sau đó, phát triển một bản kế hoạch để nghiên cứu, đánh giá
tính khả thi (sự đóng góp mà hệ thống có thể tạo ra cho doanh nghiệp,
sự phù hợp về kinh phí phát triển …).
25
 Các pha của quy trình phát triển RUP (tt.)

v Pha chi tiết (Elaboration): Phát triển khâu nắm bắt yêu cầu, thiết lập
một khung kiến trúc cho hệ thống và xác định các rủi ro chính. Đầu ra
của pha này là một mô hình yêu cầu cho hệ thống, một tài liệu mô tả
kiến trúc và một bản kế hoạch phát triển phần mềm.
v Pha xây dựng (Construction): Thiết kế hệ thống, lập trình và kiểm thử.
Các thành phần của hệ thống được phát triển song song và được tích
hợp trong pha này. Đầu ra của pha này là một hệ thống phần mềm chạy
được và các tài liệu liên quan.
v Pha chuyển giao (Transition): Bàn giao hệ thống tới người dùng cuối,
hỗ trợ cài đặt và sử dụng.
26
 Các hoạt động chính trong quy trình phát triển RUP

v Các hoạt động diễn ra trong quá trình phát triển (khung nhìn tĩnh của
RUP) được gọi là luồng công việc trong mô tả RUP:
• Mô hình hoá nghiệp vụ (Business Modeling): Các quy trình nghiệp vụ
được mô hình hoá bằng cách sử dụng các trường sử dụng nghiệp vụ.
• Yêu cầu (Requirements): Định nghĩa những gì hệ thống cần làm.
• Phân tích và thiết kế (Analysis and Design): Chỉ ra làm thế nào các ca
sử dụng của hệ thống được cài đặt.
• Cài đặt (Implementation): Mã hoá các thành phần phần mềm đáp ứng bộ
tiêu chí chất lượng.
• Kiểm thử (Testing): Tích hợp và kiểm thử hệ thống.

27
 Các hoạt động chính trong quy trình phát triển RUP (tt.)

• Triển khai (Deployment): Cung cấp sản phẩm phần mềm đến tay người
sử dụng.
• Quản lý thay đổi và cấu hình (Configuration and change
management): Hỗ trợ quản lý các thay đổi đối với hệ thống.
• Quản lý dự án (Project Management): Đảm bảo tất cả các công việc
được lên lịch, quản lý việc phát triển hệ thống.
• Môi trường (Environment): Quản lý môi trường mà hệ thống được phát
triển trên đó.
v RUP được thiết kế để có thể kết hợp với UML -> mô tả các hoạt động
trong quy trình RUP được định hướng xoay quanh các mô hình UML
(các biểu đồ tuần tự, các biểu đồ đối tượng).
28
 Bộ kinh nghiệm thực hành của RUP

1. Phát triển phần mềm qua các lần lặp: Lập kế hoạch phát triển gia
tăng cho hệ thống dựa trên mức độ ưu tiên từ phía khách hàng,
phát triển các tính năng của hệ thống có độ ưu tiên cao nhất ngay
từ những giai đoạn ban đầu trong quy trình phát triển.
2. Quản lý các yêu cầu: Tài liệu hoá một cách rõ ràng về các yêu
cầu của khách hàng và theo dõi những thay đổi đối với các yêu cầu
này. Phân tích tác động của những thay đổi đó với hệ thống trước
khi chấp nhận chúng.
3. Sử dụng kiến trúc dựa trên thành phần: Cấu trúc hoá kiến trúc
hệ thống thành các thành phần.
29
 Bộ kinh nghiệm thực hành của RUP (tt.)

4. Mô hình hoá trực quan phần mềm: Sử dụng các mô hình đồ hoạ
UML để biểu diễn các khung nhìn tĩnh và động của phần mềm.
5. Kiểm tra chất lượng phần mềm: Đảm bảo rằng phần mềm đáp
ứng các tiêu chuẩn chất lượng.
6. Kiểm soát các thay đổi đối với phần mềm: Quản lý các thay đổi
đối với phần mềm bằng cách sử dụng một hệ thống quản lý thay
đổi và các công cụ hỗ trợ khác.

30
 Tổng quan về phân tích và thiết kế
hướng đối tượng

v Tầm quan trọng của OOAD

v Mục đích của OOAD

v Tổng quan về OOAD

OOAD (Object-Oriented Analysis and Design): Phân tích và thiết kế hướng đối tượng

31
 Tầm quan trọng của OOAD

v Nhiều kỹ sư phần mềm:

• Nhìn nhận phần mềm chủ yếu được xây dựng bằng cách viết chương trình.
• Không dành đủ thời gian cho quá trình phân tích và thiết kế phần mềm.
-> Khó hoàn thành chương trình do:
• Không hiểu hoặc hiểu sai yêu cầu.
• Giao tiếp, trao đổi giữa các thành viên trong đội ngũ phát triển không tốt.
• Không tích hợp được với mô-đun của đồng nghiệp.
…

32
 Tầm quan trọng của OOAD (tt.)

v Cần một cơ chế hiệu quả để nắm bắt các yêu cầu, phân tích và
thiết kế.
v Cơ chế này phải giống như một ngôn ngữ thống nhất để giúp cho
quá trình cộng tác giữa các thành viên trong nhóm phát triển phần
mềm trở nên hiệu quả hơn.
-> Giải pháp: OOAD.

33
 Mục đích của OOAD
v Chuyển các yêu cầu của bài toán thành một bản thiết kế của hệ thống sẽ
được xây dựng.
v Đảm bảo mục đích và các yêu cầu của hệ thống phải được tài liệu hoá
một cách hợp lý trước khi bắt đầu xây dựng hệ thống.
v Tập trung vào quá trình phân tích các yêu cầu của hệ thống và thiết kế
các mô hình cho hệ thống trước giai đoạn lập trình.
v Hình thành kiến trúc chắc chắn cho hệ thống.
v Đưa ra giải pháp thiết kế nhằm tương thích với môi trường cài đặt và các
yêu cầu phi chức năng.
v Cung cấp cho người dùng, khách hàng, kỹ sư phân tích, kỹ sư thiết kế
nhiều khung nhìn khác nhau về hệ thống. 34
 Phân tích hướng đối tượng (OOA)

v Phân tích là hoạt động chuyển tiếp từ khâu nắm bắt yêu cầu sang
thiết kế hệ thống trong quy trình phát triển phần mềm.
v Phân tích hướng đối tượng là phương pháp phân tích dựa trên
các lược đồ hướng đối tượng.

35
 Vấn đề của thiết kế hướng thủ tục

v Dữ liệu là chung cho cả hệ thống:

• Mọi thủ tục thao tác trên CSDL chung.
• Một thủ tục thao tác sai lên dữ liệu gây sai lan truyền sang phần khác
sử dụng dữ liệu này.
• Sửa đổi một thủ tục có thể ảnh hưởng tới phần khác liên quan.
v Thay đổi cấu trúc dữ liệu dẫn đến thay đổi tổng thể hệ thống -> dữ
liệu cần phải tổ chức tốt.
v Hệ thống lớn, phức tạp -> bảo trì khó khăn.

36
 Thiết kế hướng đối tượng (OOD)

v Một cách tiếp cận khác, nhìn nhận hệ thống theo các quan điểm:
• Tập các đối tượng tương tác với nhau.
• Mỗi đối tượng đóng gói dữ liệu và các xử lý trên chúng.
• Các đối tượng tương tác với nhau bằng cách truyền thông điệp.
• Các đối tượng có thể kế thừa nhau.
v OOD hiện đang trở nên phổ biến.

37
 Ưu điểm của OOD

v Dễ bảo trì: Các đối tượng được xem như các thực thể hoạt động
độc lập.
• Đóng gói thông tin.
• Liên kết lỏng lẻo (trao đổi bằng cách truyền thông điệp).
v Có khả năng tái sử dụng:
• Tính độc lập cao.
• Có khả năng kế thừa.
v Dễ hiểu:
• Có sự ánh xạ tường minh giữa thực thể thế giới thực và đối tượng HT.

38
Nội dung của OOD

v Xác định các tập đối tượng (các lớp) và các đặc trưng
của chúng.
v Xác định vai trò và trách nhiệm của các lớp đối tượng
trong hệ thống.
v Thiết lập sự tương tác giữa chúng để thực hiện chức
năng đặt ra của hệ thống phần mềm.

39
 Mô hình OOAD

v Mô hình phân tích: v Mô hình thiết kế:

• Mô hình nghiệp vụ: • Mô hình cấu trúc gói.
o Mô hình miền. • Mô hình cộng tác.
o Biểu đồ hoạt động.
• Mô hình lớp.
• Mô hình ca sử dụng. • Đặc tả lớp, giao diện.
• Mô hình lớp phân tích.
• Mô hình gói lớp.

40
Tiến trình OOAD

41
PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Mục tiêu

v Mô tả mục đích sử dụng của Biểu đồ ca sử dụng và Biểu đồ hoạt động.

v Nắm được các thành phần chính trong Biểu đồ ca sử dụng và Biểu đồ
hoạt động.

v Có khả năng đọc hiểu Biểu đồ ca sử dụng và Biểu đồ hoạt động.

v Nắm được cách xác định và kiểm tra các tác nhân và các ca sử dụng
của hệ thống.

2
 Biểu đồ ca sử dụng (use case diagram)

v Tổng quan:
• Mỗi hệ thống tương tác với con người hoặc các hệ thống khác để thực
hiện nhiệm vụ.

• Các hành vi của hệ thống có thể được mô tả trong các ca sử dụng.

• Biểu đồ ca sử dụng mô tả các yêu cầu chức năng của hệ thống dưới
dạng các ca sử dụng, tổ chức và mô hình hoá các hành vi của hệ thống.

• Biểu đồ ca sử dụng biểu diễn các chức năng mong đợi của hệ thống
(use case), môi trường của hệ thống (actor) và mối quan hệ giữa chúng.
3
 Mục đích sử dụng

v Đóng vai trò như một bản hợp đồng giữa bên phát triển hệ thống và khách hàng.

v Được sử dụng trong tất cả các giai đoạn của quy trình phát triển hệ thống.
• Khách hàng phải phê duyệt biểu đồ ca sử dụng.

• Bên phát triển hệ thống sử dụng biểu đồ ca sử dụng để thảo luận với khách hàng.

• Các bên liên quan đến dự án sẽ hiểu rõ hơn về hệ thống thông qua biểu đồ ca sử dụng.

4
Mục đích sử dụng (tt.)

5
 Tác nhân (actor)

v Tác nhân là bất cứ thứ gì tương tác với hệ thống, nó có sự trao đổi
dữ liệu với hệ thống.
• Một lớp/loại người dùng chứ không phải một người dùng cụ thể.

• Một người dùng cụ thể có thể đóng vai trò là các tác nhân khác nhau.

• Không phải là một phần của hệ thống.

Thủ thư
• Trao đổi (gửi và nhận) thông tin với hệ thống.

• Có thể là người dùng, thiết bị phần cứng hoặc hệ thống phần mềm khác.

6
 Xác định các tác nhân bên ngoài hệ thống

v Đặt các câu hỏi sau để tìm ra các tác nhân:

• Nhóm người nào yêu cầu hệ thống làm việc cho họ?

• Nhóm người nào kích hoạt chức năng của hệ thống?

• Nhóm người nào sẽ duy trì và quản trị hệ thống?

• Hệ thống có tương tác với các thiết bị phần cứng hoặc các hệ thống
phần mềm ngoại vi nào khác hay không?

v Thông tin về tác nhân:

• Tên tác nhân phải mô tả vai trò của tác nhân đó một cách rõ ràng.

• Tên tác nhân nên là danh từ. 7

 Ca sử dụng (Use Case - UC)

v Ca sử dụng là một chuỗi các hành động mà hệ thống sẽ thực hiện

nhằm thu được một kết quả dễ thấy bởi một tác nhân cụ thể.
• Định nghĩa một chức năng của hệ thống.
• Đặc tả ca sử dụng mô tả cách một hoặc nhiều tác nhân tương tác với hệ thống.

• Kết thúc ca sử dụng, tác nhân phải thu được một giá trị có thể quan sát được.

Login

8
 Xác định các ca sử dụng của hệ thống

v Xem xét các yêu cầu chức năng của hệ thống để tìm ra các UC.
v Đối với mỗi tác nhân tìm được, đặt các câu hỏi sau:
• Tác nhân yêu cầu những gì từ hệ thống?
• Các công việc chính mà tác nhân đó muốn hệ thống thực thi?
• Tác nhân đó có tạo ra hoặc thay đổi dữ liệu gì của hệ thống?
• Tác nhân đó cần thông báo gì cho hệ thống?
• Tác nhân đó cần thông tin thông báo gì từ hệ thống?
v Thông tin về ca sử dụng:
• Tên của ca sử dụng nên chỉ rõ kết quả của quá trình tương tác với tác nhân.
• Tên của ca sử dụng nên là động từ.
• Mô tả ngắn gọn về mục đích của ca sử dụng đó.
9
 Những điều nên tránh khi tạo các UC

v Tạo ra các ca sử dụng quá nhỏ.

v Tạo ra quá nhiều ca sử dụng (hàng chục):

• Nhóm các ca sử dụng liên quan thành một ca sử dụng tổng quát (mức 1).

• Mô tả các ca sử dụng tổng quát ở một biểu đồ khác (mức 2).

v Sử dụng các ca sử dụng quá cụ thể.

• “Nhập PIN vào máy ATM” nên đặt là “Nhập PIN”.

• “Tìm tài liệu theo tên” nên đặt là “Tìm tài liệu”.

10
 Kiểm tra các tác nhân

v Tất cả các tác nhân đã được xác định?

• Đảm bảo rằng tất cả các vai trò trong môi trường của hệ thống đã được xét
tới và mô hình hoá.
v Tác nhân có liên quan đến ca sử dụng nào không?
• Loại bỏ tác nhân không được đề cập trong một mô tả ca sử dụng nào hoặc
không có liên kết với ca sử dụng nào.
v Tác nhân có thực sự là một vai trò? Cần phân tách hoặc hợp
nhất với các tác nhân khác hay không?
• Các tác nhân có vai trò tương tự nhau trong ngữ cảnh hệ thống, chúng nên
được hợp nhất thành một tác nhân duy nhất.
• Một tác nhân cụ thể sử dụng hệ thống theo nhiều cách hoàn toàn khác nhau
hoặc sử dụng ca sử dụng nào đó với một số mục đích hoàn toàn khác nhau,
tác nhân đó nên được phân tách.
11
 Kiểm tra các tác nhân (tt.)

v Có hai tác nhân có vai trò tương tự nhau đối với một ca sử
dụng hay không?
• Nếu có hai tác nhân có vai trò tương tự nhau đối với một ca sử dụng -> sử
dụng mối quan hệ tổng quát hoá để mô hình hoá hành vi tổng quát của
chúng.
v Tên các tác nhân có trực quan hay không?
• Khách hàng và người dùng có hiểu tên các tác nhân hay không?
• Tên các tác nhân phải phù hợp với vai trò của chúng.

12
 Kiểm tra các ca sử dụng

v Ca sử dụng có liên quan đến tác nhân nào không?

• Loại bỏ ca sử dụng không tương tác với một tác nhân nào.
v Ca sử dụng có độc lập với những ca sử dụng khác không?
• Nếu các ca sử dụng luôn được kích hoạt theo cùng một trình tự -> hợp nhất
chúng thành một ca sử dụng duy nhất.
v Có những ca sử dụng có hành vi hoặc luồng sự kiện rất giống
nhau hay không?
• Nếu có -> hợp nhất chúng thành một ca sử dụng duy nhất (người dùng không
bị ảnh hưởng nhiều).
v Tên các ca sử dụng có trực quan và là duy nhất hay không?
• Tên các ca sử dụng phải mô tả hành vi mà chúng hỗ trợ.
v Mô tả các ca sử dụng có rõ ràng và dễ hiểu hay không?
• Khách hàng và người dùng có hiểu được hay không? 13
 Mối quan hệ (relationship)

v Mối quan hệ giữa các actor với nhau:

• Tổng quát hoá (generalization).

• Giao tiếp.

v Mối quan hệ giữa actor và use case:

• Giao tiếp.

v Mối quan hệ giữa các use case với nhau:

• Tổng quát hoá (generalization).
• Bao hàm (include).

• Mở rộng (extend). 14
 Mối quan hệ giữa các actor với nhau

v Tổng quát hoá (generalization):

• Tác nhân con kế thừa tính chất và hành vi của tác nhân cha.

v Giao tiếp:
Đăng ký

Độc giả Thủ thư

15
 Mối quan hệ giữa actor với use case
v Tác nhân và ca sử dụng tương tác bằng cách gửi các tín hiệu cho nhau.
v Chiều của quan hệ chính là chiều của tín hiệu gửi đi.
• Từ tác nhân tới ca sử dụng:
o Kích hoạt ca sử dụng.
o Hỏi/thay đổi thông tin nào đó trong hệ thống.
o Thông báo cho ca sử dụng về một sự kiện nào đó xảy ra với hệ thống.
• Từ ca sử dụng tới tác nhân:
o Nếu như có một sự kiện xảy ra với hệ thống và tác nhân đó cần được biết sự kiện đó.
o Ca sử dụng cần hỏi thông tin nào đó từ một tác nhân trước khi ca sử dụng đó đưa ra
một quyết định.
v Một UC được bắt đầu bởi một actor để gọi một chức năng nào đó trong HT.

16
 Mối quan hệ giữa các use case

v Tổng quát hoá (generalization):

• Một ca sử dụng được đặc biệt hoá thành một hoặc nhiều ca sử dụng con.

• Sử dụng khái niệm kế thừa:

o Mô tả hành vi chung trong ca sử dụng cha.

o Mô tả hành vi riêng trong (các) ca sử dụng con.

17
 Mối quan hệ giữa các use case (tt.)

v Bao hàm (include):

• Một ca sử dụng có thể tích hợp hành vi của các ca sử dụng khác như là các
phần trong hành vi tổng thể của nó.

• Biểu diễn một UC chứa hành vi được định nghĩa trong một UC khác.

• Cho phép một UC sử dụng chức năng của UC khác.

• Sử dụng stereotype là <<include>>.

18
 Mối quan hệ giữa các use case (tt.)

v Mở rộng (extend):
• Một ca sử dụng có thể được định nghĩa như là một sự mở rộng tăng dần
của một ca sử dụng cơ sở.

• Chèn hành vi của ca sử dụng mở rộng vào ca sử dụng cơ sở.

• Cho phép mở rộng chức năng của một ca sử dụng.

• Sử dụng stereotype là <<extend>>.

Rút tiền In biên lai

« extend »
19
Đọc biểu đồ ca sử dụng

20
 Thảo luận về biểu đồ ca sử dụng trong slide 20

v Các chức năng của hệ thống là gì?

v Sinh viên có thể tác động lên những ca sử dụng nào?

v Giảng viên có thể tác động lên những ca sử dụng nào?

v Nếu một người dùng A vừa là Professor vừa là Registrar, người đó

có thể thực hiện được những ca sử dụng nào?

v Những ca sử dụng nào cần thực hiện đầu tiên?

v Biểu đồ ca sử dụng này không nói lên được điều gì?

21
 Biểu đồ hoạt động (activity diagram)

v Tổng quan:
• Cho phép mô tả khung nhìn động của hệ thống.
• Biểu diễn luồng hoạt động trong hệ thống.
• Phương tiện để mô tả:
o Các quy trình nghiệp vụ.
o Luồng hoạt động trong các ca sử dụng.
o Luồng công việc trong các phương thức phức tạp.
• Biểu đồ luồng (flow chart) chỉ ra luồng điều khiển từ hoạt động (hành
động) này đến hoạt động (hành động) khác.

22
 Các thành phần

v Một hoạt động (activity):

• Đặc tả cho hành vi được diễn tả như một luồng thực thi thông qua sự sắp xếp thứ tự
của các đơn vị nhỏ hơn.

• Các đơn vị nhỏ hơn bao gồm các hoạt động lồng nhau và các hành động riêng lẻ.

• Có thể chứa ràng buộc biểu thức Boolean khi hoạt động được gọi hoặc kết thúc.

v Một chuyển tiếp (transition) là việc chuyển đổi giữa các hoạt động.
• Một chuyển tiếp xuất hiện khi tất cả các hành động của một hoạt động hoàn
thành hoặc khi một sự kiện kích hoạt việc thoát khỏi hoạt động đó.
23
 Các thành phần (tt.)
v Điểm quyết định (decision) là điểm trong một luồng công việc mà ở đó
việc chuyển tiếp từ một hoạt động phân theo các nhánh khác nhau tuỳ theo
điều kiện ràng buộc (guard condition).

v Làn bơi (swim lane):

• Sử dụng để mô hình hoá luồng công việc trong quy trình nghiệp vụ.

• Phân hoạch các hoạt động vào từng làn bơi.

• Chỉ ra ai có trách nhiệm làm gì trong từng làn bơi.

• Có thể phân chia theo một chiều (hàng hoặc cột) hoặc hai chiều (cả hàng và cột).

• Chuyển tiếp có thể được vẽ từ làn bơi này tới làn bơi khác.
24
Đọc biểu đồ hoạt động cho UC “Đăng ký môn học”

25
Ví dụ các làn bơi cho “Quy trình bán xe”

Customer Salesman Accountant

Car Selection

[success]

Financing Car Ordering

[not found]

Checking Payment

[Failed]
[Paid]

Car Hand Over

26
 Bài tập

1. Vẽ biểu đồ hoạt động của luồng nghiệp vụ đặt mua sách

trên mạng.

2. Vẽ biểu đồ hoạt động của quy trình nghiệp vụ mua hàng

(sử dụng các làn bơi).

27
PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Mục tiêu
v Mô tả khung nhìn tương tác và khung nhìn tĩnh của hệ thống.

v Mô tả mục đích sử dụng của Biểu đồ tương tác và Biểu đồ lớp.

v Nắm được các thành phần chính trong biểu đồ tuần tự, biểu đồ giao
tiếp và Biểu đồ lớp.

v Có khả năng đọc hiểu biểu đồ tuần tự, biểu đồ giao tiếp và Biểu đồ lớp.

v So sánh biểu đồ tuần tự và biểu đồ giao tiếp.

v Chỉ ra cách mô hình hoá các quan hệ trong Biểu đồ lớp.

2
 Biểu đồ tương tác (interaction diagram)

v Các đối tượng tương tác với nhau như thế nào?
• Thông qua các thông điệp.
• Thông điệp là sự giao tiếp một chiều giữa hai đối tượng ở dạng luồng
điều khiển cùng với các thông tin đính kèm (có thể có các tham số) từ
bên gửi đến bên nhận.
• Một thông điệp cho biết làm thế nào một đối tượng yêu cầu một đối
tượng khác thực hiện hành động.

3
 Cộng tác (collaboration)

v Cộng tác xác định một sự tương tác giữa các đối tượng, biểu diễn
một ngữ cảnh bao gồm các vai trò và các phần tử tương tác với
nhau để cung cấp hành vi cộng tác lớn hơn.
v Mỗi đối tượng có trách nhiệm quản lý hành vi và trạng thái của nó.
v Không một đối tượng nào có thể làm được mọi việc.
-> Các đối tượng cần phải cộng tác với nhau để giải quyết vấn đề.

4
 Vai trò của biểu đồ tương tác

v Mô hình hoá khía cạnh động của hệ thống, mô tả tương tác

giữa các đối tượng.
v Thường dùng để mô tả kịch bản của use case.
v Biểu đồ tương tác bao gồm một tập các đối tượng, các quan hệ và
các thông điệp giao tiếp giữa chúng.
v Biểu đồ tương tác bao gồm 2 loại biểu đồ:
• Biểu đồ tuần tự.
• Biểu đồ giao tiếp.
• Ngoài ra, biểu đồ tương tác có một số biến thể chuyên dụng như Biểu
đồ thời gian, Biểu đồ tương tác tổng quan.
5
 Xây dựng biểu đồ tương tác

v Bắt đầu từ luồng sự kiện.

v Các bước xây dựng biểu đồ tương tác:
• Tìm kiếm các đối tượng.
• Tìm kiếm các tác nhân.
• Bổ sung các thông điệp và các liên kết vào biểu đồ.

6
 Tìm kiếm các đối tượng

v Hình thành biểu đồ tương tác:

• Mức cao: Chỉ ra hệ thống giao tiếp như thế nào?
• Mức rất thấp: Chỉ ra các đối tượng nào cần tham gia vào kịch bản?
v Xem xét kiểu đối tượng sau khi tìm kiếm chúng:
• Đối tượng thực thể (Entity).
• Đối tượng biên (Boundary).
• Đối tượng điều khiển (Control).

7
 Tìm kiếm các tác nhân

v Tác nhân trong biểu đồ tương tác là sự kích hoạt từ bên ngoài
để khởi động luồng sự kiện.
v Tìm kiếm các tác nhân trong luồng sự kiện.
v Có thể có nhiều tác nhân trong một biểu đồ tương tác.
v Nếu một tác nhân nhận hoặc gửi thông điệp tới hệ thống theo
một kịch bản nào đó thì tác nhân này phải có mặt trong biểu đồ
tương tác của kịch bản đó.

8
 Biểu đồ tuần tự (Sequence Diagram - SD)
v Một loại biểu đồ tương tác.
v Nhấn mạnh vào trình tự thời gian của các thông điệp trao đổi
giữa các đối tượng.
v Biểu đồ tuần tự chỉ ra:
• Các đối tượng tham gia tương tác.
• Thời gian sống của các đối tượng.
• Trình tự các thông điệp được trao đổi.
v Đọc biểu đồ từ đỉnh xuống đáy.

9
Ví dụ SD cho luồng con “Create a Schedule”
của UC “Register for Course”

10
 Các thành phần của SD

v Đối tượng (object): Biểu diễn bởi một hình chữ nhật.
v Đường sống (lifeline): Biểu diễn bởi một đường kẻ nối dài phía
dưới đối tượng.

11
 Các thành phần của SD (tt.)

v Tác nhân (actor):

12
 Các thành phần của SD (tt.)

v Thông điệp (message): Biểu diễn bởi một đường mũi tên hướng
từ đối tượng gửi sang đối tượng nhận.

13
 Các thành phần của SD (tt.)
v Các loại thông điệp:
• Thông điệp đồng bộ (synchronous message): Sự giao tiếp hai chiều, đối
tượng gửi sẽ chờ đối tượng nhận phản hồi và sẽ không gửi thông điệp khác
cho đến khi nhận được phản hồi.
• Biểu diễn bởi một đường mũi tên ở đầu được tô đặc.
• Thông điệp không đồng bộ (asynchronous message): Sự giao tiếp một
chiều, không chờ đối tượng nhận phản hồi và tiếp tục với hành động tiếp theo.
• Biểu diễn bởi một đường mũi tên ở đầu không được tô đặc.
• Thông điệp trả về (return message): Thông điệp trả lời lại khi có request
hoặc sau khi kiểm tra tính đúng đắn của một điều kiện nào đó.
• Biểu diễn bởi một đường mũi tên nét đứt ở đầu không được tô đặc.
• Thông điệp gọi chính nó (self-call message): Thông điệp mà đối tượng gửi
cho chính nó để thực hiện các hàm nội tại.
<<create>>
• Thông điệp tạo mới (create message):
• Thông điệp huỷ (destroy message): <<destroy>> 14
 Các thành phần của SD (tt.)

v Kích hoạt (activation): Chỉ ra khoảng thời gian mà một hoạt động
được thực hiện.

15
 Các thành phần của SD (tt.)

v Khung tương tác (interaction frame):

16
 Các thành phần của SD (tt.)

v Các toán tử (operators) trong khung tương tác:

• alt: Nhiều lựa chọn.
• opt: Tuỳ chọn, chỉ thực hiện khi điều kiện được thoả mãn.
• par: Song song, mỗi khung chạy song song.
• loop: Lặp lại, khung có thể thực hiện nhiều lần.
• ref: Tham chiếu đến một tương tác khác, vẽ nối tiếp với các lifeline
liên quan, có thể có tham số và giá trị trả về.
• sd: Vẽ xung quanh một biểu đồ tuần tự nếu cần.

17
Các thành phần của SD (tt.)

18
 Biểu đồ giao tiếp (Communication Diagram - CD)

v Một loại biểu đồ tương tác.

v Nhấn mạnh vào việc tổ chức các đối tượng tham gia vào tương
tác.
v Biểu đồ giao tiếp chỉ ra:
• Các đối tượng tham gia tương tác.
• Các liên kết giữa các đối tượng.
• Các thông điệp trao đổi giữa các đối tượng.

19
Ví dụ CD cho luồng con “Create a Schedule”
của UC “Register for Course”

20
Sự giống nhau của SD và CD

v Tương đương về ngữ nghĩa.

• Cùng đưa ra thông tin về sự tương tác giữa các đối tượng
thông qua các thông điệp.
• Có thể chuyển đổi giữa hai loại biểu đồ mà không làm mất mát
thông tin.
v Mô hình hoá khía cạnh động của hệ thống.
v Mô hình hoá kịch bản ca sử dụng.

21
 Sự khác nhau của SD và CD
v Biểu đồ tuần tự:
• Chỉ ra thứ tự rõ ràng của các
thông điệp.
• Thể hiện luồng công việc tốt
hơn.
• Mô hình hoá trực quan hơn toàn
bộ luồng thực thi (theo thời gian).
• Thể hiện tốt hơn đối với các đặc
tả thời gian thực và các kịch bản
phức tạp.
v Biểu đồ giao tiếp:
• Chỉ ra mối quan hệ rõ ràng giữa
các đối tượng.
• Thể hiện quá trình giao tiếp tốt
hơn.
• Mô hình hoá trực quan hơn tất
cả các ảnh hưởng của đối tượng
• Thể hiện rõ hơn hiệu quả của
quá trình tương tác trên từng đối
tượng.
22
 Bài tập

1. Vẽ biểu đồ tuần tự của UC “Car Ordering”.

2. Vẽ biểu đồ giao tiếp của UC “Car Ordering”.

3. Vẽ biểu đồ tuần tự của UC “Đặt mượn sách”.

4. Vẽ biểu đồ giao tiếp của UC “Đặt mượn sách”.

23
 Biểu đồ lớp (class diagram)

v Mô tả khung nhìn tĩnh của một hệ thống.

v Một kỹ thuật mô hình hoá tồn tại ở tất cả các phương pháp
phát triển hướng đối tượng.
v Biểu đồ hay dùng nhất trong UML.
v Biểu đồ lớp bao gồm các phần tử:
• Lớp.
• Thuộc tính.
• Phương thức.
• Quan hệ.
• Ràng buộc và ghi chú.
24
 Lớp (class)
v Một lớp là một mô tả của một tập các đối tượng có chung thuộc
tính, phương thức và quan hệ.
v Một lớp được biểu diễn bởi một hình chữ nhật gồm 3 thành phần:
• Tên lớp.
• Các thuộc tính.
• Các phương thức.

25
 Biểu diễn thuộc tính

v Chỉ ra tên thuộc tính, kiểu và giá trị mặc định (nếu có):
• attributeName : Type = Default
v Tên thuộc tính phải tuân theo quy ước đặt tên của ngôn ngữ cài đặt
và của dự án.
v Kiểu nên là kiểu dữ liệu cơ bản trong ngôn ngữ thực thi.
• Kiểu dữ liệu có sẵn.
• Kiểu dữ liệu người dùng định nghĩa.

26
 Phạm vi truy cập (visibility)

v Được sử dụng để thực hiện khả năng đóng gói trong OOP.
v Phạm vi truy cập:
• Public: Mọi lớp đều nhìn thấy (+)
• Private: Lớp khác không nhìn thấy (-)
• Protected: Các lớp kế thừa có thể nhìn thấy (#)

27
Ví dụ các lớp

28
 Gói (package)

v Tổ chức các lớp như thế nào?

• Nhóm các lớp thành các module (gói).
v Gói là một cơ chế chung để tổ chức các phần tử thành nhóm.
v Một phần tử trong mô hình có thể chứa các phần tử khác.
v Ví dụ:

29
 Stereotype của lớp

v UML có sẵn nhiều stereotype để sử dụng.

v Trong biểu đồ lớp, stereotype là cơ chế để phân kiểu lớp.
v 3 stereotype của lớp được sử dụng trong pha phân tích:
• Boundary.
• Entity.
• Control.

30
 Stereotype của lớp (tt.)
v BoundaryClass (lớp biên):
• Cầu nối giao tiếp giữa giao diện và những thứ bên ngoài hệ thống (môi trường).
• Mô hình hoá tương tác giữa môi trường hệ thống và phần hoạt động bên trong HT.
• Các thay đổi về giao diện người dùng hay giao thức tương tác sẽ tác động lên các
lớp biên.
• Một số kiểu: Lớp UI, lớp giao diện hệ thống, lớp giao diện thiết bị.
• Khảo sát biểu đồ UC để tìm kiếm lớp biên.
• Mỗi cặp tác nhân và UC sẽ tương ứng với một lớp biên (khuyến cáo).
v EntityClass (lớp thực thể):
• Lớp thực thể là lớp lưu trữ thông tin sẽ ghi vào bộ nhớ ngoài.
• Thông thường phải tạo ra bảng CSDL cho lớp thực thể.
• Lớp thực thể có thể được xác định dựa vào mô tả luồng các sự kiện của UC, tài
liệu từ điển thuật ngữ, mô hình miền nghiệp vụ và các trừu tượng chính. 31
 Stereotype của lớp (tt.)

v ControlClass (lớp điều khiển):

• Đóng vai trò điều phối hành vi trong hệ thống, quản lý giao dịch, điều
phối tài nguyên hoặc điều khiển lỗi.
• Phân tách một cách hiệu quả giữa đối tượng biên và đối tượng thực thể.
• Các thay đổi tại biên của hệ thống sẽ tác động lên các lớp điều khiển.
• Mô hình hoá hành vi điều khiển trong một hoặc nhiều UC.
• Mỗi UC chỉ nên có một lớp điều khiển ở khâu phân tích (khuyến cáo).
• Làm mịn thành nhiều lớp ở khâu thiết kế.
• Không thực hiện chức năng nghiệp vụ nào.
32
 Liên kết (association)

v Một quan hệ ngữ nghĩa giữa hai hoặc nhiều lớp có mối liên hệ
với nhau giữa các thể hiện của chúng.
v Một quan hệ cấu trúc, chỉ ra các đối tượng của lớp này có kết
nối với các đối tượng của lớp khác hoặc chính lớp đó.
• Ví dụ: “Một sinh viên có một lịch học”.
v Một liên kết giữa hai lớp chỉ ra rằng đối tượng ở một đầu của
liên kết nhận ra đối tượng ở đầu kia và có thể gửi thông điệp
cho nhau.

33
 Bội số quan hệ (multiplicity)

v Bội số quan hệ là số thể hiện của một lớp liên quan tới một thể
hiện của lớp khác.
v Mỗi liên kết có hai bội số quan hệ ứng với hai đầu của liên kết.

1 đối tượng 1

0 hoặc nhiều (unlimited) * (0..*)

1 hoặc nhiều 1..*

0 hoặc 1 0..1

Khoảng xác định 2..4

Nhiều khoảng 2, 4..6, 8

34
 Tránh sử dụng bội số quan hệ 1-1 không cần thiết

v Ví dụ:

35
Ví dụ về quan hệ liên kết

36
 Kết tập (aggregation)

v Một dạng đặc biệt của liên kết.

v Mô hình hoá mối quan hệ toàn thể-bộ phận (whole-part) giữa
đối tượng toàn thể và các bộ phận của nó.
v Mối quan hệ “là một phần của” (“is a part of”).
v Ví dụ về quan hệ kết tập:

37
 Kiểm tra quan hệ Kết tập

v Cụm từ “là một phần của” được sử dụng để mô tả quan hệ?

v Một số hành vi của đối tượng toàn thể được áp dụng tự

động cho các bộ phận của nó?

v Một số giá trị thuộc tính của đối tượng toàn thể kéo theo
một vài giá trị thuộc tính của các bộ phận?

v Sự không đảo chiều giữa các lớp cho quan hệ kết tập?
38
 Hợp thành (composition)

v Một dạng đặc trưng của kết tập với quyền sở hữu mạnh và các
vòng đời trùng khớp giữa hai lớp.
• Whole là sở hữu duy nhất của Part, tạo và huỷ Part.
• Part bị bỏ khi Whole bị bỏ, Part không thể tồn tại nếu Whole không tồn tại.

Lecturer

University
39
 Mối quan hệ giữa các lớp

v Liên kết (association): use a

v Kết tập (aggregation) -> strong association: has a / is a part of
v Hợp thành (composition) -> strong aggregation: share life-time
v Tổng quát hoá (generalization): “Các khái niệm hướng đối tượng”
trong Module3.

40
 Phụ thuộc (dependency)

v Một quan hệ ngữ nghĩa giữa hai lớp, trong đó sự thay đổi của lớp
này kéo theo sự thay đổi của lớp kia (lớp phụ thuộc) mặc dù giữa
chúng không có một sự liên kết rõ ràng.
v Ví dụ:

Hoá đơn Hàng giảm giá

41
 Các ràng buộc và ghi chú

v Được sử dụng cho các liên kết, các thuộc tính, các phương thức
và các lớp.
v Các ràng buộc là các hạn chế ngữ nghĩa được viết dưới dạng
các biểu thức Boolean.

42
 Tips

v Không cố gắng sử dụng tất cả các quan hệ.

v Không mô hình hoá mọi thứ, tập trung vào các thông tin
quan trọng.

43
 Các bước chính của mô hình hoá đối tượng

v Xác định các lớp.

v Xác định các liên kết giữa các lớp.

v Xác định các thuộc tính của các lớp.

v Tổ chức và đơn giản hoá các lớp bằng cách sử dụng quan hệ tổng quát hoá.

v Loại bỏ các liên kết thừa.

v Kiểm tra biểu đồ lớp đã bao gồm tất cả các yêu cầu của tài liệu hay chưa?

v Lặp lại các bước trên và làm mịn mô hình.

44
 Bài tập
v Xây dựng biểu đồ lớp dựa vào mô tả sau đây:
• Những người quản lý thư viện mong muốn tự động hóa việc mượn sách.

• Họ cần một phần mềm cho phép người sử dụng biết sách hiện có trong thư viện, có thể
đặt mượn tối đa 2 quyển sách. Ngoài ra, phần mềm đó còn cho phép những người tham
gia mượn sách có thể biết sách nào trong thư viện đã bị mượn hoặc đã bị đặt mượn.

• Những người tham gia mượn sách cần đăng ký một tài khoản để truy nhập hệ thống.

• Việc mượn sách được quản lý bởi các thủ thư. Sau khi kiểm tra người tham gia mượn
sách, họ sẽ biết được người này có được phép mượn sách hay không (mỗi người có
thể mượn tối đa 5 quyển sách) và người này có được ưu tiên mượn sách hay không (đã
đặt mượn trên hệ thống).
45
PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
Mục tiêu

v Có được một cái nhìn tổng quan về khâu nắm bắt yêu cầu.
v Có khả năng đọc, diễn giải và kiểm tra các chế tác của khâu
nắm bắt yêu cầu:
• Phát biểu vấn đề.
• Mô hình ca sử dụng.
• Từ điển thuật ngữ.
• Đặc tả bổ sung.
v Nắm được các chế tác trên ảnh hưởng đến khâu phân tích
và thiết kế hệ thống như thế nào.
2
 Một yêu cầu là gì?

v Một yêu cầu (requirement) là một tuyên bố về những gì hệ thống phải

làm hoặc những đặc tính hệ thống cần phải có (Dennis et al., 2012).
v Trong một SDLC, các yêu cầu mô tả:
• Những gì tổ chức cần (business requirements).
• Những gì người dùng cần phải làm (user requirements).
• Những gì phần mềm cần phải làm (functional requirements).
• Những đặc tính hệ thống cần phải có (nonfunctional requirements).
• Hệ thống cần phải được xây dựng như thế nào (system requirements).

3
 Ví dụ: Các yêu cầu chức năng

v Hướng tiến trình (process-oriented): Tiến trình hệ thống phải thực hiện.
• VD: Hệ thống phải cho phép khách hàng (đã đăng ký tài khoản) xem lại lịch
sử giao dịch của họ trong ba năm qua (một nhu cầu tiến trình).
• VD: Hệ thống phải kiểm tra các đơn đặt hàng của khách hàng để kiểm kê
hàng tồn kho (một nhu cầu tiến trình).
v Hướng thông tin (information-oriented): Thông tin hệ thống phải chứa.
• VD: Hệ thống phải lưu lại lịch sử giao dịch của khách hàng trong ba năm
(một nhu cầu thông tin).
• VD: Hệ thống phải cập nhật thông tin tồn kho theo thời gian thực (một nhu
cầu thông tin).
4
 Ví dụ: Các yêu cầu phi chức năng

v Vận hành: Môi trường vật lý hoặc kỹ thuật mà hệ thống cần phát triển sẽ vận
hành trên đó.
• VD: Hệ thống chạy được trên các hệ điều hành di động.
• VD: Hệ thống hoạt động được trên mọi trình duyệt Web.
v Hiệu năng: Tốc độ, khả năng sao lưu dữ liệu và độ tin cậy của hệ thống.
• VD: Bất cứ tương tác nào giữa người dùng và hệ thống đều không được vượt quá 5s.
• VD: Hệ thống hỗ trợ 300 phiên người dùng đồng thời từ 8h sáng đến 5h chiều.
v An ninh: Ai được uỷ quyền truy cập hệ thống, trong những trường hợp nào?
• VD: Khách hàng chỉ có thể xem lịch sử giao dịch của mình trong giờ làm việc.
• VD: Chỉ manager mới có quyền xem hồ sơ của cán bộ, nhân viên mà mình quản lý.
v Văn hoá và chính trị: Các yêu cầu liên quan đến văn hoá, chính trị và pháp
lý có ảnh hưởng đến hệ thống.
5
 Tầm quan trọng của khâu nắm bắt yêu cầu

v Để tìm ra giải pháp đúng cho hệ thống phần mềm cần phát triển ->
cần phải hiểu rõ những yêu cầu đặt ra cho hệ thống.
v Câu hỏi đặt ra ở đây là ”Hệ thống phải làm gì?”.
v Trong “mô hình hoá nghiệp vụ”:
• Cung cấp ngữ cảnh để xác định và phân tích các yêu cầu.
• Hiểu chính xác về quy trình nghiệp vụ.
v Thu thập và xác định yêu cầu sai -> hệ thống bị phát triển sai, không
đáp ứng được mong đợi của khách hàng.

6
 Mục đích của khâu nắm bắt yêu cầu

v Thiết lập và duy trì những thoả thuận với khách hàng và các bên liên
quan về những gì HT phải thực hiện.
v Giúp các nhà phát triển HT hiểu rõ về những yêu cầu đặt ra cho HT.
v Xác định giới hạn của HT.
v Cung cấp cơ sở để lập kế hoạch cho những lần lặp (chi tiết kỹ thuật).
v Cung cấp cơ sở để ước tính chi phí và thời gian phát triển HT.
v Định hình giao diện tương tác giữa người dùng và HT, qua đó làm rõ
được yêu cầu của người dùng đối với HT.

7
 Các chế tác của khâu nắm bắt yêu cầu

v Phát biểu vấn đề (problem statement).

v Mô hình ca sử dụng (Use-Case model).
v Từ điển thuật ngữ (glossary).
v Đặc tả bổ sung (supplementary specification).

8
 Tài liệu phát biểu vấn đề

v Tài liệu phát biểu vấn đề là một phần của tài liệu tổng thể hệ
thống (vision document).
v Tài liệu phát biểu vấn đề làm rõ thực trạng của hệ thống hiện
thời (vấn đề, khó khăn…) -> chỉ ra được lý do và động lực
chính để phát triển hệ thống.
v Tài liệu phát biểu vấn đề có thể bao gồm các ràng buộc khác
nhau đặt ra cho hệ thống (ràng buộc về kỹ thuật, ràng buộc về
thời gian, ràng buộc về nguồn lực…).

9
 Hành vi hệ thống là gì?

v Không có hệ thống nào hoạt động riêng biệt, mỗi hệ thống tương tác
với con người hoặc các hệ thống khác để phục vụ mục đích nào đó.
• Kết quả có thể dự đoán của những tương tác trên là hành vi hệ thống.
v Hành vi hệ thống là cách một hệ thống hoạt động và phản ứng.
• Hoạt động bên ngoài của hệ thống có thể thấy và kiểm tra được.
v Hành vi hệ thống được nắm bắt trong các ca sử dụng.
• Các ca sử dụng là cơ chế để nắm bắt các hành vi mong muốn của hệ
thống cần phát triển, chúng không chỉ ra cách các hành vi được thực hiện.
v UML chỉ định một loại mô hình để diễn đạt hành vi hệ thống -> mô hình
ca sử dụng.
10
 Các khái niệm chính trong
mô hình ca sử dụng

v Một tác nhân đại diện cho bất cứ thứ gì tương tác với hệ thống.

Actor
v Một ca sử dụng là một chuỗi các hành động mà hệ thống sẽ
thực hiện để thu được một kết quả (một giá trị) có thể quan sát
được bởi một tác nhân cụ thể.

Use Case

11
 Mô hình ca sử dụng là gì?

v Một mô hình mô tả các yêu cầu chức năng của hệ thống dưới
dạng các ca sử dụng.
v Một mô hình về các chức năng dự kiến của hệ thống (các ca sử
dụng) và môi trường của hệ thống (các tác nhân).
v Mô hình ca sử dụng được dùng trong tất cả các giai đoạn của
vòng đời phát triển hệ thống.
v Các chế tác tạo nên mô hình ca sử dụng bao gồm đặc tả ca sử
dụng và các biểu đồ đặc tả ca sử dụng.

12
 Vai trò của mô hình ca sử dụng

v Mô tả những gì hệ thống sẽ làm.

v Đóng vai trò như một cam kết giữa khách hàng, người dùng và
bên phát triển hệ thống.
• Cho phép khách hàng và người dùng kiểm tra xem hệ thống có được xây
dựng đúng như mong muốn của họ hay không.
• Cho phép bên phát triển đảm bảo rằng hệ thống họ đang xây dựng đúng
với mong muốn của khách hàng và người dùng.
v Vai trò quan trọng nhất của mô hình ca sử dụng là diễn đạt các
hành vi của hệ thống cần phát triển.

13
Vai trò của mô hình ca sử dụng (tt.)

14
 Tài liệu đặc tả ca sử dụng
v Mỗi ca sử dụng trong mô hình ca sử dụng mô tả chi tiết:
• Cách hệ thống tương tác với các tác nhân.
• Những gì hệ thống thực hiện trong quá trình tương tác với các tác nhân.
Þ Tài liệu đặc tả ca sử dụng.
v Tài liệu đặc tả ca sử dụng sẽ định hướng cho các hoạt động phân tích
và thiết kế về sau.
v Ca sử dụng có một tập các thuộc tính, chúng có thể xuất hiện trong tài
liệu đặc tả ca sử dụng.
• Brief description: Mô tả ngắn gọn mục đích của ca sử dụng.
• Flow of events: Mô tả dạng văn bản về những gì hệ thống sẽ thực hiện liên quan
đến ca sử dụng (thông thường chứa một luồng sự kiện chính và các luồng sự
kiện thay thế).
• Relationships: Các quan hệ giữa các ca sử dụng với nhau. 15
 Tài liệu đặc tả ca sử dụng (tt.)

• Activity diagrams: Sử dụng để biểu diễn cấu trúc luồng các sự kiện.
• Use Case diagrams: Sử dụng để chỉ ra các mối quan hệ liên quan đến UC.
• Special requirements: Mô tả dạng văn bản về các yêu cầu, thường là các yêu
cầu phi chức năng được sử dụng là các ràng buộc cho giai đoạn thiết kế và
cài đặt.
• Pre-conditions: Định nghĩa các ràng buộc lên hệ thống tại thời điểm ca sử
dụng bắt đầu.
• Post-conditions: Định nghĩa các ràng buộc lên hệ thống tại thời điểm ca sử
dụng kết thúc.
• Other diagrams: Sử dụng để mô tả ca sử dụng (ví dụ, các bản vẽ hoặc ảnh
chụp màn hình từ một bản mẫu giao diện người dùng).
16
 Ví dụ: Tài liệu đặc tả ca sử dụng
“Tạo tài khoản”
Use Case Tạo tài khoản
Actor Visitor
Brief Description Use Case này mô tả cách một Visitor đăng ký một tài khoản trên website XYZ
Pre-conditions Không có
Use Case này bắt đầu khi một Visitor yêu cầu tạo một tài khoản trên website XYZ:
1. Hệ thống hiển thị một form yêu cầu Visitor nhập các thông tin sau đây:
• User ID (required)
• Password (required)
Basic Flows • Email address (required)
• Phone number (required)
• Brief self-introduction (optional)
2. Sau khi Visitor cung cấp các thông tin được yêu cầu, hệ thống kiểm tra User ID và tất cả các trường
bắt buộc. Sau đó, hệ thống sẽ hiển thị một thông báo tới Visitor.
2.1. Nếu bất cứ một trường bắt buộc nào chưa được điền thông tin, hệ thống sẽ hiển thị một thông báo lỗi.
• Visitor có thể nhập lại thông tin đăng ký tài khoản.
• Visitor có thể huỷ thao tác tạo tài khoản.
Alternative Flows 2.2. Nếu bất cứ một trường bắt buộc nào mà Visitor nhập thông tin sai kiểu dữ liệu, hệ thống cũng sẽ hiển
thị một thông báo lỗi.
2.3. Nếu User ID mà Visitor nhập đã tồn tại, hệ thống sẽ hiển thị một thông báo yêu cầu Visitor nhập lại
một User ID khác. Visitor có thể nhập lại một User ID khác hoặc huỷ thao tác tạo tài khoản.

Nếu Use Case này được thực hiện thành công, một tài khoản người dùng mới sẽ được thêm vào hệ
Post-conditions
thống. Ngược lại, trạng thái hệ thống sẽ không thay đổi.
Special 17
Không có
Requirements
 Kịch bản là gì?

v Một kịch bản (scenario) là một thể hiện của ca sử dụng.

v Mỗi ca sử dụng có một kịch bản tương ứng với một thể hiện của một
luồng các sự kiện cụ thể, kịch bản có thể liên quan đến luồng các sự
kiện chính và bất cứ luồng các sự kiện thay thế nào.
v Đối với ca sử dụng phức tạp -> viết kỹ lưỡng các kịch bản.
v Các kịch bản được sử dụng để hiểu, thẩm định các luồng sự kiện của ca
sử dụng.
v Có thể viết các kịch bản trước, sau đó trích xuất ra các ca sử dụng. Có
thể xác định các ca sử dụng trước, sau đó thẩm định chúng bằng cách
viết các kịch bản.
18
 Ví dụ: Một kịch bản của UC “Đặt mượn sách”

Một người dùng đứng trước một máy vi tính:

1. Hệ thống hiển thị một thông điệp chào mừng.
2. Người dùng chọn chức năng đặt mượn.
3. Hệ thống yêu cầu người dùng đăng nhập.
4. Người dùng nhập thông tin để đăng nhập vào hệ thống.
5. Hệ thống yêu cầu chọn sách muốn đặt mượn.
6. Người dùng chọn sách muốn đặt mượn.
7. Hệ thống chuyển trạng thái sách đó thành đã được đặt mượn.

19
 Biểu đồ tuần tự hệ thống

v Biểu đồ tuần tự hệ thống (system sequence diagram) là một

chế tác được tạo ra một cách dễ dàng, nó được sử dụng để biểu
diễn các sự kiện đầu vào và đầu ra liên quan đến hệ thống.
v Trong biểu đồ tuần tự hệ thống:
• UML sử dụng các ký hiệu của biểu đồ tuần tự để biểu diễn các sự kiện từ
các tác nhân bên ngoài hệ thống đến hệ thống.
• Hệ thống như một hộp đen.
v Biểu đồ tuần tự hệ thống được sử dụng để đặc tả các kịch bản ca
sử dụng và các quy trình nghiệp vụ.
20
Ví dụ: Biểu đồ tuần tự hệ thống
đặc tả “Process Sale”

21
 Ví dụ: Biểu đồ hoạt động
đặc tả ca sử dụng “Đăng ký môn học”

Select Course

[ delete course ]
Delete Course
[ add course ]

Check Check
Schedule Pre-requisites

[ checks completed ] [ checks failed ]

Assign to Resolve
Course Conflicts

Update
Schedule

22
 Từ điển thuật ngữ
v Từ điển thuật ngữ định nghĩa các thuật ngữ trong miền vấn đề của hệ
thống, nó chứa các mô tả ở dạng văn bản và được dùng chung cho tất
cả các mô hình của hệ thống.
v Từ điển thuật ngữ cung cấp cho các nhà phát triển một cách hiểu thống nhất
về các thuật ngữ quan trọng của dự án và thuận tiện trong giao tiếp giữa họ
và các chuyên gia miền.
v Từ điển thuật ngữ thường được tạo ra trong pha khởi đầu (Inception) và pha
chi tiết (Elaboration) của quy trình RUP.
v Các chuyên gia miền sử dụng từ điển thuật ngữ để giải thích tất cả các thuật ngữ chuyên
biệt miền, giúp các nhà phát triển hiểu được các kịch bản của ca sử dụng.
v Trong pha xây dựng (Construction), các nhà phát triển sử dụng từ điển thuật ngữ để giải
thích các thuật ngữ về kỹ thuật trong các mô hình thiết kế.

v Tài liệu từ điển thuật ngữ thường có một định dạng cụ thể. 23
 Ví dụ: Từ điển thuật ngữ
của “Hệ thống đăng ký môn học”

24
 Đặc tả bổ sung

v Đặc tả bổ sung chứa các yêu cầu không được nắm bắt bởi các ca
sử dụng (chẳng hạn, các yêu cầu phi chức năng).
v Đặc tả bổ sung cùng với mô hình ca sử dụng sẽ nắm bắt tất cả các
yêu cầu đặt ra cho hệ thống, chúng tạo ra đặc tả yêu cầu hoàn chỉnh
của hệ thống.
v Đặc tả bổ sung chứa các yêu cầu liên quan đến:
• Tính khả dụng (usability).
• Độ tin cậy (reliability).
• Hiệu năng (performance).
• Khả năng hỗ trợ (supportability) và khả năng bảo trì (maintainability).
• Các ràng buộc thiết kế. 25
 Kiểm tra mô hình ca sử dụng

v Mô hình ca sử dụng có dễ hiểu?

v Thông qua mô hình ca sử dụng:
• Có ý tưởng rõ ràng về các chức năng của hệ thống?
• Các chức năng của hệ thống có liên quan với nhau?
v Tất cả các yêu cầu chức năng đã được đáp ứng?
v Mô hình ca sử dụng có chứa hành vi thừa?

26
 Kiểm tra đặc tả ca sử dụng

v Tác nhân thực hiện ca sử dụng có được xác định?

v Có mô tả ngắn gọn về ca sử dụng?
v Có mô tả các ràng buộc lên hệ thống tại thời điểm ca sử dụng
bắt đầu và kết thúc?
v Trình tự trao đổi thông tin giữa tác nhân và ca sử dụng có
chiếu theo mong muốn của người dùng?
v Quá trình trao đổi thông tin giữa tác nhân và ca sử dụng có
được mô tả?
v Đặc tả ca sử dụng quá phức tạp?
27
Kiểm tra từ điển thuật ngữ

v Định nghĩa mỗi thuật ngữ có rõ ràng và súc tích?

v Mỗi thuật ngữ có trong các đặc tả ca sử dụng?
v Các thuật ngữ được sử dụng có tính nhất quán trong các
đặc tả ca sử dụng?

28