Bài giảng Công nghệ phần mềm - Huỳnh Xuân Hiệp - Bài 13: Giai đoạn cài đặt

Huỳnh Xuân Hiệp - CNPM 
152
13 giai đoạn cμi đặt(IMPLEMENTATION PHASE)
Nội dung: 
ƒ Khái quát chung 
ƒ Kỹ năng lập trình tốt 
ƒ Viết mã lệnh chuẩn 
ƒ Lựa chọn tr−ờng hợp kiểm thử mô-đun 
ƒ Các ph−ơng pháp tạo dữ liệu kiểm thử 
ƒ Kỹ thuật Cleanroom 
Huỳnh Xuân Hiệp - CNPM 
153
13.1 Khái quát chung
(overview)
ƒ Quá trình chuyển đổi từ thiết kế chi tiết sang mã lệnh 
ƒ Do nhiều ng−ời thực hiện (programming-in-the-many) 
ƒ Lựa chọn ngôn ngữ lập trình 
‰ phụ thuộc vào hợp ngữ của máy tính 
‰ phụ thuộc vào số l−ợng ngôn ngữ lập trình sẵn có 
‰ thói quen sử dụng ngôn ngữ lập trình 
ƒ Các ngôn ngữ lập trình thế hệ thứ t− (fourth generation languages – 4GL): 
Focus, Nature,... 
‰ mã máy (1) 
‰ hợp ngữ (2) 
‰ ngôn ngữ mức cao (3) : FORTRAN, ALGOL 60, COBOL,... 
⇒ Mục tiêu là sản phẩm sẽ do chính ng−ời lập trình sử dụng (end-user 
programming) 
ƒ Có đánh giá rủi ro khi chọn ngôn ngữ lập trình 
Huỳnh Xuân Hiệp - CNPM 
154
13.2 Kỹ năng lập trình tốt
(good programming practice)
ƒ Hiểu rõ ngôn ngữ (language-specific) 
ƒ Sử dụng tên biến thích hợp và có nghĩa (use of consistent and meaningful 
variable names) 
‰ có nghĩa theo quan điểm của các nhà lập trình bảo trì 
‰ chú ý đến ngôn ngữ mẹ đẻ của các lập trình viên, thống nhất ngôn 
ngữ để đặt tên biến (tiếng Anh,...) 
‰ tên biến phải rõ ràng và không gây lầm lẫn 
‰ dễ dàng hiểu các mã lệnh 
ƒ Chú thích tự thân (the issue of self-documenting code) 
‰ không có các dòng chú thích 
‰ các tên biến phải đ−ợc diễn giải ngay từ đầu (prologue comments) 
ƒ Nên có các chú thích bên trong mô-đun (inline comments) 
ƒ Sử dụng tham số (use of parameters) 
ƒ Dễ đọc (code layout for increased readability), sử dụng các cặp dấu 
ngoặc, canh đầu dòng, các dòng trắng để định rõ các công việc,... 
Huỳnh Xuân Hiệp - CNPM 
155
ƒ Thông tin tối thiểu của một mô-đun (the minimum information) 
‰ tên mô-đun 
‰ mô tả vắn tắt các công việc mô-đun phải thực hiện 
‰ tên của lập trình viên 
‰ ngày viết mô-đun 
‰ ngày mô-đun đ−ợc chấp thuận và đ−ợc chấp thuận bởi ai 
‰ các tham số 
‰ danh sách các tên biến (nên theo thứ tự chữ cái) và cách sử dụng 
‰ tên các tập tin mà mô-đun có truy xuất 
‰ tên các tập tin bị thay đổi bởi mô-đun (nếu có) 
‰ nhập/xuất của mô-đun (nếu có) 
‰ các khả năng lỗi xảy ra 
‰ tên tập tin sẽ đ−ợc sử dụng để kiểm thử 
‰ danh sách các cập nhật đã đ−ợc tiến hành với ngày t−ơng ứng, ng−ời 
chấp thuận 
‰ các lỗi đã biết (nếu có) 
Huỳnh Xuân Hiệp - CNPM 
156
ƒ Các lệnh if lồng nhau (nested if statement) 
90° 
60° 1 
30° 2 
l
a
t
i
t
u
d
e
 90° 120° 150° 180° 
 longitude 
 if (latitude>30 && longitude>120) 
{ 
 if (latitude<=60 && longitude<=150) 
mapSquareNo = 1; 
 else if (latitude<=90 && longitude<=150) 
mapSquareNo = 2; 
 else 
System.out.println(“Not on the map”); 
} 
else 
System.out.println(“Not on the map”); 
Hình 13.1 Các tọa độ trên bản đồ Hình 13.2 Định dạng tốt nh−ng nhiều if lồng nhau 
if (latitude>30 && longitude>120) { if (latitude<=60 && longitude<=150) mapSquareNo = 1; else if (latitude<=90 && 
longitude<=150) mapSquareNo = 2; else System.out.println(“Not on the map”);} else System.out.println(“Not on the 
map”); 
Hình 13.3 Định dạng xấu và nhiều if lồng nhau 
if (longitude>120 && longitude30 && latitude<=60) 
mapSquareNo = 1; 
 else if (longitude>120 && longitude60 && latitude<=90) 
mapSquareNo = 2; 
 else 
System.out.println(“Not on the map”); 
Hình 13.4 Các câu if chấp nhận đ−ợc 
Huỳnh Xuân Hiệp - CNPM 
157
13.3 Viết m∙ lệnh chuẩn
(coding standards)
ƒ Thống nhất quy −ớc về cách đặt tên mô-đun, tên biến,... 
ƒ Nên sử dụng các quy tắc sau: 
‰ độ lồng nhau của lệnh if tối đa là 3 
‰ mỗi mô-đun có khoảng 35 đến 50 mã lệnh thực thi 
‰ không sử dụng lệnh goto, có thể sử dụng để bắt lỗi 
ƒ Chịu sự kiểm thử của nhóm SQA 
ƒ Có khả năng sử dụng lại (reuse) 
‰ một số phần trong đặc tả, hợp đồng, kế hoạch, thiết kế, các mô-đun 
‰ một số thiết bị phần cứng liên quan 
Huỳnh Xuân Hiệp - CNPM 
158
13.4 Lựa chọn tr−ờng hợp kiểm thử mô-đun
(module test case selection)
ƒ Một mô-đun phải chịu hai lần kiểm thử 
‰ không hình thức (informal testing), do lập trình viên tiến hành 
‰ theo ph−ơng pháp (methodical testing), do nhóm SQA thực hiện sau 
khi khi lập trình viên xác nhận rằng mô-đun đã vận hành tốt: 
 → không dựa trên việc thực thi (nonexecution-based testing) 
 → dựa trên việc thực thi (execution-based testing) 
ƒ Cách kiểm thử dở nhất là sử dụng dữ liệu kiểm thử bừa bãi, khi đó sẽ 
không có đủ thời gian để thực hiện 
ƒ Các kiểm thử tốt nhất là xây dựng các tr−ờng hợp kiểm thử có hệ thống, 
các bộ dữ liệu kiểm thử đ−ợc tạo ra có chọn lọc 
Huỳnh Xuân Hiệp - CNPM 
159
13.5 Các ph−ơng pháp tạo dữ liệu kiểm thử
(constructing test data to test a module)
ƒ Kiểm thử dựa trên đặc tả, không chú ý đến mã lệnh 
‰ các tên gọi khác: hộp đen (black-box), cấu trúc (structural), dữ liệu dẫn 
(data-driven), chức năng (functional), xuất/nhập dẫn (input/output 
driven) 
‰ VD: 5 dạng hoa hồng và 7 dạng khấu hao, số tr−ờng hợp kiểm thử ít 
nhất sẽ là 35 
ƒ Kiểm thử dựa trên mã lệnh, không chú ý đến đặc tả; mọi phân nhánh trong 
mô-đun phải đ−ợc thực thi ít nhất một lần 
‰ các tên gọi khác: hộp kính (glass-box), hộp trắng (white-box), hành vi 
(behavioral), logic dẫn (logic-driven), định h−ớng đ−ờng đi (path-
oriented) 
Huỳnh Xuân Hiệp - CNPM 
160
13.6 Kỹ thuật kiểm thử dạng hộp đen
(black-box module-testing techniques)
ƒ Kiểm thử t−ơng đ−ơng và phân tích giá trị biên (equivalence testing and 
boundary value analysis) 
‰ lớp t−ơng đ−ơng 
‰ phân tích giá trị biên trong khoảng (R1,R2) sẽ có 5 tr−ờng hợp kiểm 
thử: R1và R2 
ƒ Kiểm thử chức năng (functional testing) 
‰ dựa trên dữ liệu theo từng chức năng 
 ::== if 
; 
 else 
; 
⇒ , , còn 
 sẽ kiểm thử dạng hộp kính(ở phần tiếp theo) 
Huỳnh Xuân Hiệp - CNPM 
161
13.7 Kỹ thuật kiểm thử dạng hộp kính
(glass-box module-testing techniques)
ƒ Kiểm thử cấu trúc lệnh, phân nhánh và đ−ờng đi (statement, branch, and 
path coverage) 
‰ lệnh: các chuỗi dữ liệu thử phải đảm bảo mỗi lệnh đ−ợc thực hiện ít 
nhất một lần. VD: 
if (s > 1 && t == 0) 
x = 9; 
Tr−ờng hợp kiểm thử: s = 2, t = 0. 
‰ phân nhánh: các chuỗi dữ liệu thử phải đảm bảo mỗi nhánh đ−ợc thực 
hiện ít nhất một lần 
⇒ Còn gọi kiểm thử cấu trúc với hai dạng trên 
‰ đ−ờng đi: hiệu quả nhất, kiểm thử tất cả các h−ớng đi có thể 
- sử dụng ph−ơng pháp định nghĩa toàn bộ các đ−ờng đi có sử 
dụng (all-definition-use-path coverage) nhằm giảm thiểu số 
l−ợng đ−ờng đi phải kiểm thử [Rapps và Weyuker, 1985] 
- ứng với mỗi đ−ờng đi tạo một bộ dữ liệu kiểm thử 
Huỳnh Xuân Hiệp - CNPM 
162
ƒ Đo độ phức tạp (complexity metrics) 
‰ số l−ợng dòng lệnh [Basili và Hutchens, 1983; Takahashi và 
Kamayachi, 1985] 
‰ số l−ợng các quyết định nhị phân + 1 [McCabe, 1976] 
‰ độ đo Halstead 
- n1: số l−ợng các toán tử khác nhau 
- n2: số l−ợng các toán hạng khác nhau 
- N1: tổng số các toán tử 
- N2: tổng số các toán hạng. VD: 
if (k < 2) 
{ 
if (k > 3) 
x = x*k; 
} 
các toán tử khác nhau: if ( = * ; } 
các toán hạng khác nhau: k 2 3 x 
n1 = 10, n2 = 4, N1 = 13, N2 = 7 
‰ kích th−ớc dữ liệu: O, Ω 
Huỳnh Xuân Hiệp - CNPM 
163
13.8 Kỹ thuật Cleanroom
ƒ Đề xuất bởi [Cobb và Mills, 1990; Dyer, 1992; Linger, 1994], tổ hợp một số 
kỹ thuật phát triển phần mềm khác nhau 
‰ mô hình tăng tr−ởng 
‰ các kỹ thuật đặc tả và thiết kế hình thức 
‰ kỹ thuật kiểm thử mô-đun không dựa trên thực thi: đọc mã lệnh, 
walkthroughs và thanh tra 
Một số ứng dụng: 
‰ Ericsson Telecom OS32 với 350000 dòng lệnh do 70 ng−ời thực hiện 
(1.0 lỗi /KLOC),... 
‰ 17 sản phẩm với 1 triệu dòng lệnh (2.3 lỗi/KLOC) [Linger, 1994]