Bài giảng công nghệ phần mềm - Phần 2 Các giai đoạn trong chu trình sống của phần mềm - Chương 12 pdf

Huúnh Xu©n HiÖp - CNPM

138
1
1
2
2


g
g
i
i
a
a
i
i


®
®
o
o
¹
¹
n
n


t

t
h
h
i
i
Õ
Õ
t
t


k
k
Õ
Õ
(
(
D
D
E
E
S
S
I
I
G
G
N
N

P
P
H
H
A
A
S
S
E
E
)
)


Néi dung:
 Kh¸i qu¸t chung
 ThiÕt kÕ vµ trõu t−îng hãa
 ThiÕt kÕ h−íng sù kiÖn
 ThiÕt kÕ h−íng d÷ liÖu
 ThiÕt kÕ h−íng ®èi t−îng
 KiÓm thö
 §¸nh gi¸





Huỳnh Xuân Hiệp - CNPM

139
1
1
1
2
2
2
.
.
.
1
1
1



K
K
K
h
h
h
á
á
á
i
i
i

q
q
q
u
u
u
á
á
á
t
t
t



c
c
c
h
h
h
u
u
u
n
n
n
g
g

g
(overview)

Hàng trăm kỹ thuật thiết kế đã ra đời trong hơn 30 năm qua
Thiết kế hớng sự kiện (action-oriented)
phân rã sản phẩm thành các mô-đun có tính chặt chẽ cao và ít gắn kết
với nhau
Thiết kế hớng dữ liệu (data-oriented)
phụ thuộc vào cấu trúc dữ liệu mà các xử lý đợc thực hiện trên đó
các kỹ thuật nổi tiếng nh [Jackson, 1975;1983], [Wanier, 1976;1981]
và [Orr, 1981]
Thiết kế hớng đối tợng
dạng tổng hợp, bao gồm cả sự kiện và dữ liệu

Đầu vào:
tài liệu đặc tả, cho biết sản phẩm phải làm gì (what ?)
Đầu ra:
để đạt đợc những công việc đã mô tả ở đầu vào, sản phẩm phải
thực hiện nh thế nào (how ?)

Huỳnh Xuân Hiệp - CNPM

140
1
1
1
2
2
2
.

.
.
2
2
2



T
T
T
h
h
h
i
i
i
ế
ế
ế
t
t
t



k
k
k
ế

ế
ế



v
v
v
à
à
à



t
t
t
r
r
r
ừ
ừ
ừ
u
u
u



t

t
t



ợ
ợ
ợ
n
n
n
g
g
g



h
h
h
ó
ó
ó
a
a
a
(design and abstraction)

Giai đoạn thiết kế phần mềm có 3 hoạt động chính: kiến trúc, chi tiết và
kiểm thử

Thiết kế kiến trúc (architectural design, general design, logical design,
high-level design): theo quan điểm trừu tợng hóa là phân chia sản phẩm
thành các mô-đun
Thiết kế chi tiết (detailed design, modular design, physical design, low-
level design): chi tiết hóa từng mô-đun
chọn giải thuật
chọn cấu trúc dữ liệu
Kiểm thử thiết kế (design testing)






Huỳnh Xuân Hiệp - CNPM

141
1
1
1
2
2
2
.
.
.
3
3
3

P
P
P
h
h
h
â
â
â
n
n
n



t
t
t
í
í
í
c
c
c
h
h
h

d
d
d
ò
ò
ò
n
n
n
g
g
g



d
d
d
ữ
ữ
ữ



l
l
l
i

i
i
ệ
ệ
ệ
u
u
u
(data flow analysis - DFA)

Thiết kế hớng sự kiện, tạo ra các mô-đun với tính chặt chẽ cao
đầu vào: sơ đồ dòng dữ liệu (data flow diagram - DFD)
sau khi hoàn thành DFD, nhà thiết kế phần mềm phải hoàn tất các
thông tin vào/ra của từng module
Điểm trừu tợng hóa cao nhất đầu vào (point of highest abstraction of
input): điểm biến chuyển dữ liệu đầu vào thành dữ liệu nội tại
Điểm trừu tợng hóa cao nhất đầu ra (point of highest abstraction of
output): điểm biến chuyển dữ liệu nội tại thành đầu ra







a b c d e
f
g
h
đầu vào đầu ra

Hình 12.1 Thể hiện dữ liệu và sự kiện của sản phẩm bằng DFD

Huỳnh Xuân Hiệp - CNPM

142








Ví dụ về DFA : đếm số từ (words) trong tập tin









mô-đun chu
y
ển đổi
a b c d e
f
g
h

đầu vào đầu ra
Hình 12.2 Các điểm trừu tợng hóa cao nhất đầu vào và đầu ra
mô-đun đầu vào mô-đun đầu ra
điểm trừu tợng hóa
cao nhất đầu vào
điểm trừu tợng hóa
cao nhất đầu ra
đọc tên
tập tin
công
nhận tập
tin hợp lệ
đếm số
từ
hiển thị
số từ
định dạng
số lợng từ
đã đếm
tên
tập tin
tên
tập tin
công
nhận tên
tập tin
đếm số
từ
định
dạng số

từ đã
đếm
đầu ra
mong
đợi
điểm trừu tợng hóa
cao nhất đầu vào
điểm trừu tợng hóa
cao nhất đầu ra
đầu vào tại đây đầu ra tại đây
Hình 12.3 DFD tại lần làm
m
ị
n thứ nhất

Huỳnh Xuân Hiệp - CNPM

143

Nhận đầu vào
Thực hiện đếm số từ
Đ
ếm số lợng từ
Tạo đầu ra
Thể hiện số từ đã đếm
Đ
ịnh dạng số từ đã đếm Công nhận tên tập tin
Đ
ọc tên tập tin
dữ li
ệ
u
điều khiển
tên
tập tin
tên tập tin
hợp lệ
tên tập tin
hợp lệ
số lợng
từ đã đếm

số lợng
từ đã đếm
số từ đếm
đợc đã
định dạng
số từ đếm
đợc đã
định dạng
số lợng
từ đã đếm
cờ trạng
thái
tên
tập tin
cờ trạng
thái
Hình 12.4 Biểu đồ cấu trúc

Huỳnh Xuân Hiệp - CNPM

144
Thiết kế chi tiết 4 mô-đun

Tên mô-đun
Đọc tập tin
Kiểu trả về String
Các tham số đầu vào không
Các tham số đầu ra không
Các thông báo lỗi không
Các tập tin truy xuất không

Các tập tin có thay đổi trên đó không
Các mô-đun đợc gọi không
Mô tả Sản phẩm đợc thi hành khi ngời dùng gõ lệnh:
word count <tên tập tin>
Sử dụng một lời gọi hệ thống, mô-đun này sẽ truy xuất nội dung
chuỗi lệnh do ngời sử dụng nhập vào, tách ra tên tập tin và trả
về kết quả là tên tập tin đã tách đợc.

Tên mô-đun
Công nhận tên tập tin hợp lệ
Kiểu trả về boolean
Các tham số đầu vào tên tập tin: String
Các tham số đầu ra không
Các thông báo lỗi không
Các tập tin truy xuất không
Các tập tin có thay đổi trên đó không
Các mô-đun đợc gọi không
Mô tả Mô-đun này tạo một lời gọi hệ thống để xác định sự tồn tại của
tập tin với tham số đầu vào là tên tập tin. Mô-đun trả về kết quả
true nếu tập tin đã tồn tại và false nếu ngợc lại.


Huỳnh Xuân Hiệp - CNPM

145
Tên mô-đun
Đếm số lợng từ
Kiểu trả về integer
Các tham số đầu vào tên tập tin hợp lệ: String
Các tham số đầu ra không

Các thông báo lỗi không
Các tập tin truy xuất không
Các tập tin có thay đổi trên đó không
Các mô-đun đợc gọi không
Mô tả Mô-đun này xác định với tên tập tin hợp lệ đầu vào là tập tin văn
bản. Khi đó mô-đun sẽ trả về số từ có trong tập tin văn bản ,
ngợc lại trả về -1.

Tên mô-đun
Tạo đầu ra
Kiểu trả về void
Các tham số đầu vào số lợng từ: integer
Các tham số đầu ra không
Các thông báo lỗi không
Các tập tin truy xuất không
Các tập tin có thay đổi trên đó không
Các mô-đun đợc gọi
Định dạng số từ
các tham số: số từ:integer, số từ đã đợc định dạng:String
Thể hiện số từ đ đếm
các tham số: số từ đã đợc định dạng:integer: String
Mô tả Mô-đun này lấy tham số đầu vào là số từ đã đếm đợc bắng
cách gọi mô-đun Định dạng số từ và sau đó gọi mô-đun Thể
hiện số từ đ đếm để thể hiện số từ đã đếm đợc.

Hình 12.5 Thiết kế chi tiết các mô-đun

Huỳnh Xuân Hiệp - CNPM

146

1
1
1
2
2
2
.
.
.
4
4
4



P
P
P
h
h
h
â
â
â
n
n
n

t
t
t
í
í
í
c
c
c
h
h
h



g
g
g
i
i
i
a
a
a
o
o
o

d
d
d
ị
ị
ị
c
c
c
h
h
h
(transaction analysis - TA)

Thiết kế hớng sự kiện
Một giao dịch là một thao tác theo quan điểm của ngời sử dụng sản phẩm
VD:
xử lý một yêu cầu, in ra danh sách các đặt hàng trong ngày

Xử lý giao dịch
Bộ điều vận
Bộ phân tích
Ghi vào sổ kế toán
Hiệu chỉnh một số giao dịch Cập nhật một số tập tin
Xử lý giao dịch
t5
Xử lý giao dịch
t4
Xử lý giao dịch
t3
Xử lý giao dịch
t2
Xử lý giao dịch
t1
Hình 12.6 Thiết kế dạng giao dịch-xử lý

Huỳnh Xuân Hiệp - CNPM

147
1
1
1
2
2
2
.
.
.
5

5
5



T
T
T
h
h
h
i
i
i
ế
ế
ế
t
t
t



k
k
k
ế
ế
ế

h
h
h



ớ
ớ
ớ
n
n
n
g
g
g



đ
đ
đ
ố
ố
ố
i
i
i

t
t
t



ợ
ợ
ợ
n
n
n
g
g
g
(object-oriented design - OOD)

Thiết kế sản phẩm thành các đối tợng(object) là các thể hiện của các lớp
(classe) hay các lớp con (subclass)
Các ngôn ngữ lập trình hớng đối tợng thông dụng nh Smalltalk
[Goldberg và Robson, 1989], C++ [Stroustrup, 1991], Eiffel [Meyer,
1992b], Ada95 [ISO/IEC 8652, 1995] và Java [Flanagan, 1996]
Khi cài đặt trên các ngôn ngữ lập trình không hớng đối tợng tiến hành
thiết kế trên các kiểu dữ liệu trừu tợng (abstract data type design)

Bao gồm 4 bớc:

xây dựng sơ đồ tơng tác cho từng kịch bản

xây dựng sơ đồ lớp chi tiết
thiết kế sản phẩm theo các đối tợng của khách hàng
tiến hành thiết kế chi tiết



Huỳnh Xuân Hiệp - CNPM

148

ứng dụng thang máy
Nút Các tiện ích thang máy
sáng lên: boolean

tắt nút (abstract)
bật nút (abstract)





Nút trong thang máy

Nút tại các tầng
tắt nút
bật nút
tắt nút
bật nút
mn
2m-2

điều khiển

điều khiển




n
Bộ điều khiển thang máy
1



1

Các cửa thang máy
điều khiển cửa mở: Boolean

n
cửa đóng
cửa mở

Thang máy

cửa mở: boolean
chuyển thang máy lên trên
chuyển thang máy xuống

Hình 12.7 Sơ đồ lớp chi tiết

Huúnh Xu©n HiÖp - CNPM

149


















øng dông thang m¸y
bé ®×Òu khi
Ó
n thang m¸y c¸c tiÖn Ých thang m¸y
c¸c cöa thang m¸y nót t
¹
i c¸c tÇng nót trong thang m¸y thang m¸y
H×nh 12.8 Quan hÖ kh¸ch hµng-®èi t−îng

Huỳnh Xuân Hiệp - CNPM

150
1
1
1
2
2
2
.
.
.
6
6
6



K
K
K
i
i
i
ể
ể
ể
m
m
m

t
t
t
h
h
h
ử
ử
ử



t
t
t
r
r
r
o
o
o
n
n
n
g
g
g

g
g
g
i
i
i
a
a
a
i
i
i



đ
đ
đ
o
o
o
ạ
ạ
ạ
n
n
n

t
t
t
h
h
h
i
i
i
ế
ế
ế
t
t
t



k
k
k
ế
ế
ế
(testing during the design phase)

Tìm thấy lỗi trong giai đoạn này là rất quan trọng

Có thể sử dụng
walkthroughs
thanh tra tơng tự nh trong giai đoạn đặc tả nhng có thể không có
đại diện của khách hàng
Phải phản ánh đợc hớng thiết kế


1
1
1
2
2
2
.
.
.
7
7
7



Đ
Đ
Đ
á
á
á
n
n

n
h
h
h



g
g
g
i
i
i
á
á
á



g
g
g
i
i
i
a
a
a
i
i

i



đ
đ
đ
o
o
o
ạ
ạ
ạ
n
n
n



t
t
t
h
h
h
i
i
i
ế
ế

ế
t
t
t



k
k
k
ế
ế
ế
(metrics for the design phase)

Có nhiều phơng pháp đánh giá trên các mặt của giai đoạn thiết kế
số lợng các mô-đun: đánh giá thô về kích thớc của sản phẩm
độ gắn kết của mô-đun: đánh giá về chất lợng

Huỳnh Xuân Hiệp - CNPM

151
độ nối kết giữa các mô-đun: thống kê về lỗi
Độ phức tạp của thiết kế chi tiết M bằng số lợng quyết định nhị phân cộng
với 1 [McCabe, 1976] (hay số lợng nhánh trong một mô-đun)
VD:
độ phức tạp khi viết một mô-đun toascii:
có sử dụng switch có 128 nhánh : 128
sử dụng bảng chuyển đổi trực tiếp: 1
[Henry và Kafura, 1981] M = length

ì
(fan-in
ì
fan-out)
2

length : kích thớc mô-đun
fan-in : số lợng các luồng đi vào mô-đun + số lợng cấu trúc dữ liệu
mà mô-đun truy xuất
fan-out : số lợng các luồng đi ra mô-đun + số lợng các cấu trúc dữ
liệu toàn cục mà mô-đun cập nhật
Phơng pháp thành công nhất cho thiết kế hớng đối tợng: CDM
[Kitchenham, Pickard và Linkman, 1990; Shepperd, 1990]
Một số phơng pháp khác : [Chidamber và Kemerer, 1994], [Binkley and
Schach, 1996;1997;1998]