Phân tích & thiết kế HTTT

1. Nguyên lý

Nguyễn Anh Hào

Khoa CNTT2 – HV CNBCVT Cơ sở Tp.HCM
0913609730 – nahao@ptithcm.edu.vn
 2
Nội dung bài giảng
1. Khái niệm PTTK hệ thống
2. Hệ thống
– Hệ thống là gì ?
– Hệ thống & môi trường vận hành của nó
3. Phương pháp PTTK hệ thống thông tin
4. Các hướng tiếp cận
– Hướng cấu trúc
– Hướng đối tượng
 3
Khái niệm PT & TK hệ thống
• PTTK hệ thống là một chuỗi công việc tìm và giải quyết
vấn đề của một hệ thống hiện hữu
– Phân tích hệ thống: Là quá trình tư duy dựa trên chứng cứ
(dữ kiện thu được từ thực tế) để xác định các vấn đề của hệ
thống.
– Thiết kế hệ thống: Là quá trình thêm mới hoặc thay đổi hệ
thống để giải quyết các vấn đề đã biết.
• Ý nghĩa: tạo ra sự thay đổi tích cực lên hệ thống hiện hữu
(cải tiến cho hệ thống).
• Để làm được điều này, trước hết ta cần tìm hiểu hệ thống là
gì.
 4
• C
Vài khái niệm về hệ thống
ó
r
ấ
t
n
h
i
ề
u
t
h
ứ

đ
ư
 5
• H
Định nghĩa của hệ thống
ệ
t
h
ố
n
g
l
à
m
ộ
t
t
ậ
p
h
 6
Ví dụ: Máy ATM là 1 hệ thống
ATM

ATM

Các bộ phận (mô phỏng) của ATM:

Window clerk Book-keeper Dispenser Courier
 7
Các đặc trưng của hệ thống
Thành phần Hệ thống con
Giao tiếp
Đầu ra

A C2

B C1
Môi trường

Đầu vào
Quan hệ nội tại Ranh giới

Mỗi thành phần là một công cụ cho hệ thống (là A,B,C).

Một công cụ của hệ thống có thể là một hệ thống con (C gồm
C1,C2). Các chức năng mà C thực hiện cho hệ thống sẽ do 2
thành phần C1 và C2 của C cùng hợp tác nhau thực hiện.
 8
Các đặc trưng của hệ thống
• Một hệ thống chỉ tồn tại được khi nó có lý do để tồn tại; đó
là mục đích của hệ thống. Mục đích đó được thừa nhận khi
nó có giá trị sử dụng cho môi trường.
• Môi trường là những gì tồn tại bên ngoài ranh giới của hệ
thống và có liên quan tới hệ thống (yêu cầu và ràng buộc).
• Giá trị sử dụng của hệ thống có được từ hoạt động cộng tác
bên trong hệ thống (quan hệ nội tại giữa các thành
phần/hệ thống con), để thực hiện các chức năng của hệ
thống trong môi trường (đầu vào, đầu ra, giao tiếp).
 9
Ví dụ: Nhà hàng là một hệ thống
Tiền trả
Nguyên liệu
Nhà cung câp Kho Văn phòng
(cung ứng) (lưu trữ) (điều khiển)

Ranh giới của nhà hàng

Chính phủ Nguyên liệu
(luật pháp)
Môi trường

Nhà bếp Thông tin,

(chế biến) mệnh lệnh
Đối thủ
(cạnh tranh) Thức ăn
Hàng hóa,
Dịch vụ
Khách hàng Quầy phục vụ
(tiêu thụ) (bán)
Tiền trả Tiền thu
 10
Ví dụ: Hệ thống con trong nhà hàng
• Nếu xem nhà hàng là một hệ thống, thì nhà kho, nhà bếp,
quầy phục vụ và văn phòng đều là công cụ hoặc hệ thống
con của nhà hàng.
• Nếu nhà kho có hệ thống phần mềm quản lý kho cho thủ
kho, thì nhà kho là một hệ thống con có 2 thành phần: hệ
thống phần mềm quản lý kho (tự động), và thủ kho (nhân
công).
• Hệ thống phần mềm quản lý kho cũng là một hệ thống
gồm máy tính (phần cứng) và phần mềm quản lý kho
(chương trình, csdl) để trợ giúp thông tin cho người thủ kho
thực hiện việc quản lý kho.
• Phần mềm quản lý kho (có các mô-đun PM) cũng là hệ
thống đ/v người xây dựng PM này.
 • 11
C
Các tính chất của hệ thống
o
h
e
s
i
o
n

l
à
s
ự

c
ộ
 • 12
S
Suy nghĩ có hệ thống
y
s
t
e
m

t
h
i
n
k
i
n
g
:
 • 13
M
Môi trường của hệ thống
ộ
t
h
ệ
t
h
ố
n
g
l
à
m
ộ
t
t
 • 14
N
Vấn đề của hệ thống
g
ư
ờ
i
t
a
t
ạ
o
r
a
h
ệ
t
h
 15
Phương pháp luận PTTK - HTTT

Thế giới ý niệm

Hệ
Hệ thống
thống củ
củ Phân tích Hệ
Hệ thống
thống mới
mới
đã
đã làm
làm được
được gì
gì sẽ
sẽ phải
phải làm
làm gì
gì
Yêu
Yêu cầu
cầu đối
đối với
với
hệ
hệ thống
thống

Thiết kế
Khảo sát

Hệ
Hệ thống
thống “Phát triển” Hệ
Hệ thống
thống
củ
củ đang
đang hoạt
hoạt động
động mới
mới sẽ
sẽ vận
vận hành
hành
như
như thế
thế nào
nào như
như thế
thế nào
nào

Thế giới thực (môi trường)

 16
Ppl PTTK vs Ppl giải quyết vấn đề

PPL giải quyết vấn đề PPL phân tích & thiết kế

 Nhận thức về bối cảnh phát  Khảo sát hiện trạng, hệ

sinh vấn đề thống hóa (lập mô hình)

 Tìm nguyên nhân, định  Phân tích hệ thống, định

nghĩa vấn đề nghĩa yêu cầu

 Tìm giải pháp từ thực tế  Thiết kế hệ thống

 Kiểm chứng & đánh giá giải  Làm mẫu thử, kiểm lỗi, đánh
pháp áp dụng trong thực tế,… giá …

Sự khác biệt giữa PPL giải quyết vấn đề và PPL phân tích thiết kế hệ thống là gì ?
 17
Hiểu hệ thống
• Hiểu hệ thống là một quá trình thu thập thông tin (biết) và
hệ thống hóa lại thông tin để lý giải được (hiểu) kết cấu và
sự vận hành của hệ thống.
– từ đó mới xác định được đâu là vấn đề của hệ thống.
– Đây là công việc quan trọng nhất và khó nhất.

• Có rất nhiều thứ cần biết và hiểu về hệ thống, vd: công

việc, thành phần, mối quan hệ giữa các thành phần,.... Vậy
chúng ta nên bắt đầu tìm hiểu từ đâu ?
 18
Cách hiểu hệ thống
1. Khảo sát hệ thống trong môi trường (hệ thống lớn)
a. Tìm hiểu các vấn đề cần giải quyết trong môi trường
b. Tìm hiểu cách mà hệ thống có thể giải quyết vấn đề.
2. Hệ thống hóa (liên kết) mọi thứ đã biết
– Phác thảo, tóm lược bằng mô hình (vd: lược đồ)
3. Phân tích (mô hình) để hiểu kết cấu của hệ thống
a. Môi trường đặt ra yêu cầu gì cho hệ thống (chức năng của
hệ thống trong môi trường)
b. Các tương tác (giao tiếp) giữa hệ thống và môi tường trong
việc thực hiện các yêu cầu này.
c. Cách giải quyết yêu cầu của hệ thống (phối hợp các thành
phần trong hệ thống để thực hiện chức năng)
 19
Mô hình & Mô hình hóa
• Mô hình là phương tiện để diễn tả ‘tóm tắt’ các đặc trưng
quan trọng của hệ thống bằng hình ảnh hoặc công thức,
theo một quan điểm (hướng nhìn) nào đó.
– Ví dụ: bản đồ, lược đồ (diagram), flow-chart….
– Mô hình giúp ta khái quát mọi thứ để dể hiểu.
– Mô hình dựa trên ngữ pháp, ngữ nghĩa và ngữ cảnh.
• Mô hình hóa là việc tạo ra mô hình từ những hiểu biết về
thế giới thực.
– Vd: vẽ lược đồ class bằng UML.
– Cách tiếp cận hệ thống là cách dùng để hiểu hệ thống.
– Mỗi cách tiếp cận có cách mô hình hóa khác nhau.
 20
a) Tiếp cận hướng cấu trúc
• Tiếp cận cấu trúc là cách phân tích và giải quyết vấn đề
dựa trên tư duy logic.
– Hiểu trọn vẹn vấn đề (phân tích) để tìm giải pháp (thiết kế) thỏa
mãn cho tất cả các yêu cầu và ràng buộc đã biết.
• Việc hiểu biết về hệ thống chỉ ở 2 khía cạnh (hướng nhìn):
dữ liệu và xử lý.
1. Trừu tượng hóa các đối tượng trong thế giới thực thành ý niệm
về thực thể và quan hệ (ERD) có các thuộc tính cần thiết cho
việc thu thập, lưu trữ và xử lý dữ liệu của hệ thống
2. Định nghĩa và phân rã các chức năng được yêu cầu đến mức đủ
“nhỏ” (đơn giản) để hiểu đúng và làm được (DFD)
 21
Tiếp cận hướng cấu trúc
 Định nghĩa xử lý của hệ thống : DFD (Data Flow Diagram)

Hệ thống
D1 D3 D2 D0
Source P2 P1 Sink

Mức tổng quát: DFD-0

Sự phân rã xử lý

P2
D1 D4 D3
P2.1 P2.2

Mức chi tiết: DFD-1 cho P2

 22
Tiếp cận hướng cấu trúc
 Định nghĩa dữ liệu của hệ thống: ERD (Entity Relationship
Diagram)

x1 b1
1. Các thực thể cần thiết

2. Các quan hệ giữa chúng X B

a1

3. Các thuộc tính (dữ liệu) x2 b2

a2 A
4. Xác định khóa c1

5. Số của quan hệ (cardinality) a3

Y C
6. Loại của quan hệ
y1 c2
 • 23
Đ
b) Tiếp cận hướng đối tượng ố
i
t
ư
ợ
n
g
l
à
ý
n
i
ệ
m

v
ề
 24
Tiếp cận hướng đối tượng

1 Z Communication diagram:
Hệ thống X được sử dụng
UC 1 UC2 trong môi trường vận hành
của nó
Y X
“CRC”

Usecase diagram 2 A Các đối tượng thành

phần trong hệ thống

3
Các tình huống X cần thiết cho các
tương tác của X usecases
với môi trường Y UC1
B

UC1: Sequence diagram

A
4 B
Các tương tác hình thành yêu Y
cầu dịch vụ & thuộc tính từ A’s Service1
các đối tượng thành phần
(A,B) của hệ thống. A’s Service2
B’s Service
 • 25
O
OMT-Các loại mô hình b
j
e
c
t
R
e
l
a
ti
o
n
S
h
i
p
m
 26
OMT-Các công đoạn
Công đoạn ≠ Giai đoạn
• Phân tích yêu cầu
– Coi toàn bộ hệ thống là 1 đối tượng (công cụ), chỉ ra sự cộng tác
của nó trong môi trường (communication)
– Xác định tình huống mà hệ thống được sử dụng (usecases)
• Thiết kế kiến trúc
– Xem xét, tìm các đối tượng thành phần bên trong hệ thống để
thực hiện các usecases
– Models: Object Relationship, Functional
• Thiết kế chi tiết
– Dựa trên các models, định nghĩa dịch vụ & tương tác được mong
đợi từ các đối tượng thành phần
• Hiện thực thiết kế
– Cài đặt cho các đối tượng thành phần (trong package)
 27
Hướng đối tượng: Nguyên lý 1
Đối tượng tự quyết định hành vi ứng xử
• Tom & Mary đang ngồi ăn trong nhà hàng, và Tom cần nhờ Mary lấy
giúp lọ muối ở kế bên cô ta. Tom sẽ nói gì với Mary ?
– “Hãy đưa giúp tôi lọ muối” (1)
– “Hãy rời tay ra khỏi ly của cô và vươn tới lọ muối, cầm lấy nó và
đưa nó về phía tay tôi cho đến khi tôi cầm được” (2)
• (1) là một lời đề nghị (một thông điệp mang yêu cầu dịch vụ) được
sử dụng trong hướng đối tượng. Mọi thứ tiếp theo đều do người nhận
quyết định. Mary có quyền từ chối, hoặc nhờ người khác làm thay
→ cơ chế ủy thác của hướng đối tượng.
• (2) là một lời yêu cầu chi tiết & chính xác cho hành động cần làm
(và không thể làm khác), sử dụng trong tiếp cận hướng cấu trúc →
cơ chế mệnh lệnh.
 28
Hướng đối tượng: Nguyên lý 2
Đối tượng có quyền tự do riêng để phát triển
Cơ chế đóng gói (Encapsulation) bảo vệ quyền này; nó phân lập 2
hướng nhìn về đối tượng: bên trong, và bên ngoài.
 Đ/v bên ngoài, các đối tượng khác chỉ biết các dịch vụ và cách
giao tiếp bằng thông điệp đến đối tượng (what it can do). Ở góc độ
xây dựng hệ thống: chỉ cần biết dịch vụ & cách giao tiếp của đối
tượng để sử dụng nó, không cần biết kết cấu bên trong của nó.
 Đ/v bên trong, tài sản & hành vi của đối tượng được dùng để thực
hiện các dịch vụ của nó (how it does), và có thể thay đổi độc lập
với bên ngoài. Nhờ vậy, đối tượng có thể tự phát triển: tạo thêm
nhiều dịch vụ khác, hoặc tùy biến cho dịch vụ.
 29
Hướng đối tượng: Nguyên lý 3
Đối tượng được nhận biết từ lớp của nó
• Sự phân lớp cho đối tượng là cách đơn giản nhất để biết về đối
tượng.
ví dụ: Bob là một con chó, vậy nó có thể sủa vì loài chó sủa được
(trừ khi Bob không thích sủa hoặc bị tắt tiếng).
• Trong cách phân lớp, thuộc tính và hành vi của các đối tượng thuộc
lớp đều có chung thuộc tính và hành vi của lớp.
• Lớp đối tượng cũng được xếp vào lớp tổng quát hơn (lớp cha); đây
là khái niệm tổng quát hóa.
ví dụ: bác sỹ là nhân viên của BV, nhân viên là công dân (vậy bác
sỹ cũng là công dân).
 30
Hướng đối tượng: Nguyên lý 4
Đối tượng có quyền thừa kế
• Mọi lớp đối tượng con đều có quyền thừa kế mọi thứ từ lớp đối
tượng cha; kể cả các quan hệ của lớp đối tượng cha.
• Một lớp đối tượng con có thể kế thừa từ nhiều lớp đối tượng cha:
đó là tính đa kế thừa (multi-inheritance). Ví dụ: một lớp lập trình
viên kế thừa từ 2 lớp: người nhân viên (có tên, tuổi) và nghề lập
trình (viết được code).
• Sự kế thừa trong phần mềm hổ trợ tối đa cho việc sử dụng lại.
• Các hành vi được kế thừa có thể được thay đổi ở lớp đối tượng con
để hành vi đó trở thành tinh vi hơn, đó là tính đa hình
(polymorphism) trong cách thừa kế.
 31
Hướng đối tượng: Nguyên lý 5
Hành vi của đối tượng phụ thuộc vào trạng thái của nó
• Giá trị cụ thể của thuộc tính quyết định trạng thái của đối tượng.
Một trạng thái của đối tượng là một bộ giá trị thuộc tính của nó, ví
dụ: đối tượng có 2 thuộc tính A và B, a và b là 2 giá trị dữ liệu của
A và B thì 1 trạng thái của đối tượng này là (a,b)
Đối tượng có nhiều trạng thái khác nhau. Ví dụ: 1 cột đèn điều
khiển giao thông có 3 trạng thái: Xanh, Vàng, Đỏ.
• Sự thay đổi trạng thái của đối tượng là do đối tượng tự phản ứng
với các sự kiện kích hoạt (ở cột đèn là tín hiệu timeout của mỗi
màu). Sự chuyển sang trạng thái mới (S2) được quyết định bởi 2
yếu tố: trạng thái hiện tại (S1), và sự kiện kích hoạt e: S2 =  (S1,e),
 được gọi là một hàm chuyển trạng thái.
 • 32
S
Hướng đối tượng vs hướng cấu trúc
ự

k
h
á
c
b
i
ệ
t
l
ớ
n
n
h
 33
Hướng đối tượng vs hướng cấu trúc
• Sự khác biệt trên giúp ta nhận ra vài khuyết điểm của tiếp
cận hướng cấu trúc như sau:
– Việc đồng nhất công đoạn thành giai đoạn (PT, TK, Code,
…) đòi hỏi giai đoạn trước phải hoàn chỉnh để tiến hành giai
đoạn sau (không hổ trợ sửa sai).
– Một yêu cầu bị thay đổi: phải xem xét nhiều xử lý có liên
quan, do xử lý tách biệt với dữ liệu dùng chung.
– Quá trình phân rã luôn có ý giải quyết tốt một vấn đề cụ thể
nào đó, dẫn đến giải pháp (các mô đun đã xây dựng) có tính
đặc thù cao, rất khó dùng lại.

Pei, Daniel, Object Oriented Analysis and Design, Information Systems

Management, Winter 95, Vol 12 Issue 1, p54)