Giáo trình Nhập môn Công nghệ phần mềm - Trần Đình Quế (Phần 2)

Submit 
Thông báo hiện ra: phòng đã tồn tại ! 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
166 
click vào nút OK của thông báo quay trở lại giao diện thêm phòng cho người 
dùng sửa lại các thông tin để tránh bị trùng 
CSDL sau khi test: 
10.5.2 Test case cho modul sửa thông tin phòng của khách sạn 
a. Lập kế hoạch test 
Có hai trường hợp phải test cho modul này: 
 Sửa một phòng đã có trong CSDL 
 Sửa một phòng chưa có trong CSDL 
b. Các test case 
+ Test case 1: sửa một phòng đã có trong CSDL 
CSDL trước khi test: 
Các bước thực hiện Kết quả mong đợi 
Click vào chức năng sửa thông tin phòng từ 
giao diện quản lí phòng 
Giao diện tìm kiếm phòng theo mã hiện ra 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
167 
Nhập id = 7 và click vào nút Search Giao diện hiện lên thông tin phòng có mã là 7 
ở dạng edit được: 
- id = 7 (không sửa được) 
- hotel id = 4 (không sửa được) 
- name = 302 
- type = single 
- display price = 900 000 
- description = 
và nút Submit 
Sửa thông tin giá phòng: 
- id = 7 (không sửa được) 
- hotel id = 4 (không sửa được) 
- name = 302 
- type = single 
- display price = 1 200 000 
- description = 
và click vào nút Submit 
Thông báo hiện lên: sửa phòng thành công! 
Click vào nút OK của thông báo Quay về giao diện chính của quản lí thông tin 
phòng 
CSDL sau khi test: 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
168 
+ Test case 2: sửa một phòng chưa có trong CSDL 
CSDL trước khi test: 
Các bước thực hiện Kết quả mong đợi 
Click vào chức năng sửa thông tin phòng trong 
menu quản lí thông tin phòng 
Giao diện tìm kiếm phòng theo mã hiện ra 
Gõ id = 8 và click vào nút tìm kiếm Thông báo hiện ra: không tồn tại phòng 
click vào nút OK của thông báo Quay trở lại Giao diện tìm kiếm phòng theo 
mã 
CSDL sau khi test: 
10.5.3 Test case cho modul đặt phòng 
a. Lập kế hoạch test 
Có hai trường hợp phải test cho modul này: 
 Đặt phòng: có phòng trống và chưa có khách hàng trong CSDL 
 Đặt phòng: có phòng trống và đã có khách hàng trong CSDL 
 Đặt phòng: không có phòng trống 
b. Các test case 
+ Test case 1: có phòng trống và chưa có khách hàng trong CSDL 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
169 
CSDL trước khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
Các bước thực hiện Kết quả mong đợi 
Chọn chức năng đặt phòng 
từ menu chính 
Giao diện tìm phòng trống hiện ra 
Nhập : 
- Ngày bắt đầu = 04 - 09 - 
2013 
- Ngày kết thúc = 08 – 09 – 
2013 
Và click vào nút Search 
Kết quả hiện ra danh sách gồm 2 phòng trống: 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
170 
Click chọn phòng 202 Quay trở về giao diện đặt phòng (cập nhật thông tin phòng chọn 
và ngày bắt đầu, ngày kết thúc) 
Click chọn tìm kiếm khách 
hàng 
Giao diện tìm kiếm khác hàng theo tên hiện ra 
Nhập vào: 
- Name = Bắc 
Và click vào nút Search 
kết quả hiện ra thông tin khách hàng: 
Click vào nút Thêm khách 
hàng 
Giao diện thêm khách hàng mới hiện ra 
Nhập: 
- id = 4 
- name = Bắc Đẩu 
- id card = 2233445566 
- id type = CMTND 
- address = Đà Nẵng 
và click Submit 
Thông báo: Thêm khách hàng thành công! 
Clock vào nút OK của thông 
báo 
Quay trở lại giao diện đặt phòng (cập nhật thông tin khách hàng 
mới vào form) 
Click nút Submit Thông báo: đặt phòng thành công! 
Click nút OK của thông báo Quay trở về trang chủ của nhân viên bán hàng 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
171 
CSDL sau khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
+ Test case 2: có phòng trống và đã có khách hàng trong CSDL 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
172 
CSDL trước khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
Các bước thực hiện Kết quả mong đợi 
Chọn chức năng đặt phòng 
từ menu chính 
Giao diện tìm phòng trống hiện ra 
Nhập : 
- Ngày bắt đầu = 04 - 09 - 
2013 
- Ngày kết thúc = 08 – 09 – 
2013 
Và click vào nút Search 
Kết quả hiện ra danh sách gồm 2 phòng trống: 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
173 
Click chọn phòng 202 Quay trở về giao diện đặt phòng (cập nhật thông tin phòng chọn 
và ngày bắt đầu, ngày kết thúc) 
Click chọn tìm kiếm khách 
hàng 
Giao diện tìm kiếm khác hàng theo tên hiện ra 
Nhập vào: 
- Name = Bắc 
Và click vào nút Search 
kết quả hiện ra thông tin khách hàng: 
Click chọn khách hàng 
“Xuân Bắc” 
Quay trở về giao diện đặt phòng phòng (cập nhật thông tin khách 
hàng mới vào form) 
Click nút Submit Thông báo: đặt phòng thành công! 
Click nút OK của thông báo Quay trở về trang chủ của nhân viên bán hàng 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
174 
CSDL sau khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
+ Test case 3: không có phòng trống 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
175 
CSDL trước khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
Các bước thực hiện Kết quả mong đợi 
Chọn chức năng đặt phòng từ menu chính Giao diện tìm phòng trống hiện ra 
Nhập : 
- Ngày bắt đầu = 24 - 08 - 2013 
- Ngày kết thúc = 28 – 08 – 2013 
Và click vào nút Search 
Thông báo hiện ra: không còn phòng trống 
trong khoảng thời gian đã cho! 
Click vào nút OK của thông báo Quay trở về giao diện tìm kiếm phòng trống 
P
T
I
T
Chương 10: Pha cài đặt và tích hợp 
176 
CSDL sau khi test: 
Bảng tblRoom: 
Bảng tblClient: 
Bảng tblBooking: 
P
T
I
T
 Chương 11. Pha bảo trì 
177 
CHƯƠNG 11: PHA BẢO TRÌ 
11.1 PHA BẢO TRÌ SAU KHI CHUYỂN GIAO 
Bất cứ thay đổi nào ở bất cứ thành phần nào của phần mềm (bao gồm tài liệu) sau khi 
phần mềm đó đã trải qua kiểm thử chấp nhận 
11.1.1 Tại sao bảo trì sau khi chuyển giao là cần thiết 
 Bảo trì sửa lỗi 
o Để sửa lỗi còn sót lại 
 Phân tích, thiết kế, cài đặt, tài liệu hoặc bất cứ các loại lỗi khác 
 Bảo trì hoàn thiện (Perfective maintenance) 
o Các yêu cầu khách hàng thay đổi để cải thiện hiệu năng phần mềm 
 Thêm các chức năng 
 Làm cho phần mềm chạy nhanh hơn 
 Cải thiện việc bảo trì 
 Bảo trì thích hợp 
o Đáp ứng những thay đổi với môi trường mà phần mềm hoạt động 
 Phần mềm được chuyển sang trình biên dịch mới, hệ điều hành hoặc/và 
phần cứng mới 
 Thay đổi mã thuế 
 Mã ZIP 9 số 
11.1.2 Người lập trình bảo trì sau khi chuyển giao yêu cầu những gì? 
 Ít nhất 67 % tổng số chi phí của phần mềm được dồn lại trong suốt quá trình bảo trì sau 
khi chuyển giao 
 Bảo trì là một nguồn thu nhập chính 
 Tuy nhiên, ngày nay nhiều tổ chức chỉ định việc bảo trì cho 
o Những người bắt đầu không bị giám sát và (Unsupervised beginners) 
o Ít người lập trình thành thạo 
 Bảo trì sau khi chuyển giao là một trong những khía cạnh khó của sản phẩm phần mềm 
bởi vì 
o Bảo trì sau khi chuyển giao kết hợp các khía cạnh của các luồng công việc khác 
 Cho rằng một bản ghi khuyết điểm được chuyển giao cho người lập trình bảo trì 
o Nhớ là “khuyết điểm” là một thuật ngữ chung của lỗi, thất bại 
 Nguyên nhân là gì? 
o Không có cái gì sai 
o Sổ tay người dùng có thể bị sai, khổng phải ở mã lệnh 
o Tuy nhiên, thường có một lỗi nằm trong mã lệnh 
a- Bảo trì sửa lỗi 
 Công cụ nào mà người lập trình bảo trì phải dùng để tìm ra lỗi? 
o Bản ghi khuyết điểm được đưa ra bởi người dùng 
o Mã nguồn 
o Thuờng không còn gì khác 
 Do đó người lập trình bảo trì phải có kỹ năng gỡ lỗi xuất sắc 
o Lỗi có thể nằm ở bất cứ chỗ nào trong phần mềm 
o Nguyên nhân đầu tiên của lỗi có thể nằm ở đặc tả không tồn tại hoặc tài liệu thiết 
kế 
P
T
I
T
Chương 11: Pha bảo trì 
178 
 Giả sử rằng người lập trình bảo trì đã định vị được lỗi 
 Vấn đề: 
o Cách cố định lỗi mà không đưa ra lỗi hồi quy 
 Cách cực tiểu lỗi hồi quy 
o Tham khảo tài liệu chi tiết của tòan bộ sản phẩm 
o Tham khảo tài liệu chi tiết của mỗi mô đun riêng lẻ 
 Cái gì thường xuyên xảy ra 
o Không có tài liệu nào, hoặc 
o Tài liệu không hoàn thiện, hoặc 
o Tài liệu bị lỗi 
 Người lập trình phải xem xét lại mã nguồn để tránh đưa ra lỗi hồi quy 
 Người lập trình thay đổi mã nguồn 
 Kiểm thử để thấy phần chỉnh sửa làm việc một cách chính xác 
o Đặc biệt, việc sử dụng những trường hợp kiểm thử cấu trúc 
 Người lập trình phải 
o Kiểm tra đối với các lỗi hồi quy 
 Sử dụng dữ liệu kiểm thử đã lưu trữ 
o Thêm các trường hợp kiểm thử đã xây dựng một cách đặc biệt vào dữ liệu kiểm 
thử đã lưu trữ để cho việc kiểm thử hồi quy trong tương lai 
o Viết tài liệu tất cả các thay đổi 
 Những kỹ năng chính được yêu cầu cho bảo trì sửa lỗi 
o Kỹ năng chuẩn đoán giỏi 
o Kỹ nưng kiểm thử giỏi 
o Kỹ năng viết tài liệu giỏi 
b- Bảo trì hoàn thiện và bảo trì thích ứng 
 Người lập trình bảo trì phải đi xuyên suốt các luồng công việc 
o Xác định các yêu cầu 
o Viết các đặc tả 
o Thiết kế 
o Cài đặt và tích hợp 
 Việc sử dụng các phần mềm có sẵn từ ban đầu 
 Khi người lập trình đã phát triển 
o Các đặc tả được đưa ra bởi những chuyên gia phân tích 
o Thiết kế được đưa ra bởi các chuyên gia thiết kế 
o Mã nguồn được viết bởi các chuyên viên lập trình 
o Nhưng những người lập trình bảo trì phải là chuyên gia ở cả ba lĩnh vực trên và cả 
lĩnh vực kiểm thử và viết tài liệu 
Kết luận 
 Không có khuôn mẫu cho bảo trì 
o Có phải đó là một công việc cho những người bắt đầu không bị giám sát hoặc 
o Bảo trì nên được thực hiện bởi chuyên gia máy tính không có kỹ năng 
c- Phần thưởng của bảo trì 
 Bảo trì là một công việc bạc bẽo theo mọi cách 
o Người bảo trì thương lượng với những người dùng không hài lòng về phần mềm 
o Nếu người dùng vui, thì phần mềm sẽ không cần bảo trì 
P
T
I
T
Chương 11: Pha bảo trì 
179 
o Vấn đề của người dùng thường bắt nguồn từ những cá nhân đã phát triển sản phẩm 
phần mềm, không phải người bảo trì 
o Bản thân mã lệnh có thể được viết rất tồi 
o Bảo trì sau khi chuyển giao bị nhiều người phát triển phần mềm xem thường 
o Trừ khi dịch vụ bảo trì tốt được đưa ra thì khách hàng sẽ thực hiện những giao 
dịch phát triển trong tương lai ở một nơi khác 
o Bảo trì sau khi chuyển giao là một khía cạnh thử thách nhất của phần mềm và bạc 
bẽo nhất 
 Những người quản lý phải chỉ định công việc bảo trì cho những người lập trình giỏi nhất 
và 
 Trả lương cho họ phù hợp 
11.1.3 Quản lý bảo trì sau khi chuyển giao 
 Các vấn đề khác nhau về mặt quản lý bảo trì sau khi chuyển giao cần được xem xét 
 Trước tiên, người lập trình bảo trì nên xem xét tệp bản ghi khuyết điểm 
 Nó bao gồm 
o Tất cả các lỗi đã được ghi lại mà chưa sửa và 
o Những đề nghị về các công việc sẽ thực thiện về những khuyết điểm đó 
 Trong một thế giới lý tưởng 
o Sửa tất cả mọi lỗi ngay lập tức 
o Sau đó chúng ta công bố phiên bản phần mềm mới ở mọi vị trí 
 Trong thế giới thực 
o Phân bố các bản ghi lỗi ở tất cả các vị trí 
o Không có nhân viên để bảo trì ngay lập tức 
o Thực hiện nhiều thay đổi ở cùng một lúc sẽ rẻ hơn, đặc biệt nếu có nhiều vị trí cài 
đặt 
a- Các bản ghi khuyết điểm 
 Cần một cơ chế đối với việc thay đội sản phẩm phần mềm 
 Nếu sản phẩm phần mềm xuất hiện một chức năng không đúng, thì người dùng đưa ra 
một bản ghi khuyết điểm 
o Bản ghi đó phải đủ thông tin để cho phép người lập trình bảo trì tái tạo lại vấn đề 
 Theo lý tưởng, mỗi khuyết điểm nên được cố định ngay lập tức 
o Trong thực tế, tốt nhất chúng ta có thể làm là nghiên cứu sơ bộ ngay lập tức 
 Nếu khuyết điểm đã được ghi lại trước đó: Đưa thông tin trong tệp bản ghi khuyết điểm 
tới người dùng 
 Nếu nó là một khuyết điểm mới: 
o Người lập trình bảo trì nên cố gắng tìm 
 Nguyên nhân, 
 Cách để sửa khuyết điểm đó, và 
 Cách làm việc xung quanh vấn đề đó 
o Khuyết điểm mới được ghi lại vào tệp tường trình phát hiện lỗi, cùng với tài liệu 
 Dánh sách (Listings) 
 Thiết kế (Designs) 
 Sổ tay (Manuals) 
P
T
I
T
Chương 11: Pha bảo trì 
180 
o Tệp bản ghi khuyết điểm cũng nên chứa những yêu cầu cảu khách hàng để bảo trì 
thích hợp và hoàn thiện chức năng 
 Nội dung của tệp phải được định độ ưu tiên bởi khách hàng 
 Những chỉnh sửa tiếp theo là một trong những nội dung có độ ưu tiên cao 
nhất trong tệp 
o Các bản sao của bản ghi khuyết điểm phải lưu hành tới tất cả 
 Bao gồm: ước lượng khi nào khuyết điểm được sửa 
o Nếu cùng thất bại xảy ra ở một vị trí khác, người dùng có thể xác định 
 Khả năng làm việc xung quanh khuyết điểm 
 Thời gian mà khuyết điểm được sửa 
b- Cho phép thay đổi phần mềm 
 Bảo trì sửa lỗi 
o Chỉ định một người lập trình bảo trì xác định lỗi và nguyên nhân của lỗi, sau đó 
sửa lỗi đó 
o Kiểm thử sửa chữa, kiểm thử toàn bộ phẩn mềm (kiểm thử hồi quy) 
o Cập nhật tài liệu để phản ánh những thay đổi đã thực hiện 
o Cập nhật những lời giải thích ban đầu để phản ánh 
 Những gì đã thay đổi, 
 Tại sao nó được thay đổi, 
 Ai thực hiện thay đổi, và 
 Khi nào 
 Bảo trì thích hợp và hoàn thiện 
o Giống với bảo trì sửa lỗi, ngoại trừ không có bản ghi khuyết điểm 
o Thay vì có thay đổi trong yêu cầu 
 Điều gì sẽ xảy ra nếu người lập trình không kiểm thử những lỗi đã được sửa một cách 
thích đáng? 
o Trước khi phần mềm được phân phối, thì phần mềm phải được kiểm thử bởi nhóm 
SQA 
 Bảo trì sau khi chuyển giao là cực kỳ khó 
 Kiểm thử là khó và tiêu tốn thời gian 
o Được thực hiện bởi nhóm SQA 
 Kỹ thuật phiên bản cơ sở và các bản sao riêng phải được sử dụng 
 Người lập trình thực hiện các thay đổi đối với các bản sao chép riêng của các mô đun mã 
và kiểm thử chúng 
 Người lập trình đóng băng phiên bản trước đó, và đưa ra phiên bản chỉnh sửa cho nhóm 
SQA để kiểm thử 
 SQA thực hiện kiểm thử trên phiên bản cơ sở của tất cả các mô đun mã 
c- Bảo đảm việc bảo trì 
 Bảo trì không là sự cố gắng một lần (Maintenance is not a one-time effort) 
 Phải lập kế hoạch cho bảo trì xuyên suốt toàn bộ vòng đời phần mềm 
o Luồng công việc thiết kế - sử dụng kỹ thuật ẩn dấu thông tin 
o Luồng cài đặt – lựa chọn đặt tên có ý nghĩa để thuận tiện cho những người lập 
trình trong tương lai 
P
T
I
T
Chương 11: Pha bảo trì 
181 
o Tài liệu phẩi được hoàn thiện và chính xác và phản ánh đúng phiên bản hiện thời 
của mỗi mô đun mã 
 Trong suốt quá trình bảo trì sau khi chuyển giao, bảo trì không phải giàn 
o Luôn luôn biết rõ việc bảo trì trong tương lai là không thể tránh được 
d- Vấn đề của bảo trì lặp 
 Việc thay đổi những yêu cầu phần mềm gây nhiều khó khăn cho đội phát triển 
 Việc thay đổi thường xuyên thường gây bất lợi cho việc bảo trì phần mềm 
Thay đổi bài toán đích 
 The problem is exacerbated during postdelivery maintenance 
 Càng nhiều thay đổi 
o Thì sản phẩm phần mềm càng khác xa so với thiết kế ban đầu 
o Việc thay đổi trong tương lai càng trở nên khó hơn 
o Tài liệu trở nên kém tin cậy hơn bình thường 
o Các file kiểm thử hồi quy không được cập nhật 
o Viết lại toàn bộ có thể cần thiết đối với bảo trì trong tương lai 
 Giải pháp hiển nhiên 
o Đóng băng các đặc tả khi chúng được ký đến tận khi chuyển giao sản phẩm phần 
mềm 
o Sau mỗi yêu cầu của bảo trì hoàn thiện, đóng băng các đặc tả trong 3 tháng hoặc 1 
năm 
 Trong thực tế 
o Khách hàng có thể đưa ra những thay đổi ngay ngày hôm sau 
o Nếu bằng lòng với giá cả, thì khách hàng có thể đưa ra những thay đổi hàng ngày 
 “Ai trả tiền thì người ấy có tiền”(“He who pays the piper calls the tune”) 
11.1.4 Bảo trì sau khi chuyển giao với kỹ năng phát triển 
 Những kỹ năng cần thiết cho bảo trì gồm 
o Khả năng xác định nguyên nhân gây ra lỗi của một phần mềm lớn 
 Cũng cần thiết trong suốt quá trình tích hợp và kiểm thử sản phẩm 
o Khả năng thực hiện chức năng có hiệu quả mà không cần có tài liệu chính xác 
 Tài liệu hiếm khi được hoàn thiện đến tận khi chuyển giao 
o Kỹ năng phân tích, thiết kế, cài đặt và kiểm thử 
 Tất cả bốn hoạt động được thực thi trong suốt quá trình phát triển 
 Những kỹ năng cần thiết cho bảo trì sau khi chuyển giao giống với những kỹ năng của tất 
cả các luồng công việc khác 
 Điểm chính 
o Người lập trình bảo trì không phải chỉ có kỹ năng rộng ở mọi lĩnh vực mà những 
kỹ năng đó phải ở trình độ cao 
o Sự chuyên môn hóa không thể có ở những người lập trình bảo trì 
11.1.5 Kỹ nghệ ngược 
 Khi nào tài liệu duy nhất đối với bảo trì sau khi chuyển giao là mã nguồn thì 
o Bắt đầu với mã 
o Tái tạo lại thiết kế 
o Tái tạo lại các đặc tả (cực kỳ khó) 
o Công cụ CASE có thể trở giúp ((flowcharters, các mục đích trực quan khác) 
P
T
I
T
Chương 11: Pha bảo trì 
182 
 Kỹ nghệ lại 
o Kỹ nghệ ngược, được sinh ra bởi kỹ nghệ tiên tiến (Reverse engineering, followed 
by forward engineering) 
o Mức độ thấp hơn tới cao hơn tới thấp hơn của trừu tượng (Lower to higher to 
lower levels of abstraction) 
 Xây dựng lại 
o Việc cải thiện sản phẩm phần mềm mà không có thay đổi chức năng phần mềm 
o Ví dụ: 
 Cải thiện việc bảo trì 
 Xây dựng lại(XP, agile processes) 
 Điều gì sẽ xảy ra nếu chúng ta chỉ có mã thực thi? 
o Xem xét phần mềm như hộp đen 
o Suy luận những đặc tả từ hành vi của phần mềm hiện thời 
11.1.6 Công cụ CASE cho bảo trì sau khi chuyển giao 
 Công cụ điểu khiển cấu hình là cần thiết 
o Công cụ thương mại 
 CCC 
o Công cụ mã nguồn mở 
 cvs 
 Các công cụ kỹ nghệ lại 
o Các công cụ thương mại 
 IBM Rational Rose, Together 
o Các công cụ mã nguồn mở 
 Doxygen 
 Các công cụ theo dõi – phát hiện 
o Công cụ thương mại 
 IBM Rational ClearQuest 
o Công cụ mã nguồn mở 
 Bugzilla 
10.1.7 Thước đo của bảo trì sau khi chuyển giao 
 Về bản chất, các hoạt động của bảo trì sau khi chuyển giao là những hoạt động của quá 
trình phát triển 
o Các thước đo đối với luồng công việc phát triển 
 Các thước đo bản ghi khuyết điểm (Defect report metrics) 
o Sự phân loại khuyết điểm 
o Trạng thái khuyết điểm (Defect status) 
10.1.8 Những thách thức của bảo trì sau khi chuyển giao 
 Chương này miêu tả rất nhiều thách thức 
 Thách thức khó nhất cần giải quyết 
o Bảo trì khó hơn phát triển, nhưng 
o Những người phát triển có xu hướng nhìn xuống (tend to look down) những người 
bảo trì và 
o Thường xuyên được trả tiền lương nhiều hơn 
P
T
I
T
Chương 11: Pha bảo trì 
183 
11.2 BẢO TRÌ HỆ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 
 Bề ngoài, mô hình hướng đối tượng khuyến kích việc bảo trì theo bốn cách 
o Phần mềm bao gồm các đơn vị độc lập 
o Đóng gói (độc lập về mặt khái niệm) 
o Ẩn giấu thông tin (độc lập về mặt vật lý) 
o Truyền tham số là các giao tiếp duy nhất (Message-passing is the sole 
communication) 
 Thực thế hơi khác (The reality is somewhat different) 
 Ba cản trở 
Một là: Cây phân cấp kế thừa có thể lớn 
 Để hình dung ra những gì displayNode làm trong BalancedBinaryTreeClass, chúng 
ta phải kiểm tra tỉ mỉ cây hoàn thiện 
o Cây hoàn thiện có thể trải rộng toàn bộ phần mềm 
o Khác xa “những đơn vị độc lập ” (A far cry from “independent units” ) 
o Giải pháp 
o Công cụ CASE có thể dàn mỏng cây kế thừa (A CASE tool can flatten the 
inheritance tree) 
Hai là:Hậu quả của liên kết động và đa hình 
P
T
I
T
Chương 11: Pha bảo trì 
184 
 Hệ thống không hoạt động khi gọi myFile.open () 
 Phiên bản nào của open có chứa lỗi? 
o Công cụ CASE không thể trợ giúp (công cụ tĩnh) 
o Chúng ta phải theo dõi (kiểm tra) 
 Liên kết động và đa hình có thể có 
o Ảnh hưởng tích cực tới đội phát triển nhưng 
o Ảnh hưởng tiêu cực đối với bảo trì 
Ba là: Hậu quả của kế thừa 
 Tạo một lớp mới qua kế thừa 
 Lớp con mới 
o Không ảnh hưởng tới lớp cha, và 
o Không ảnh hưởng tới bất cứ lớp con 
o Chỉnh sửa lớp con mới này 
o Một lần nữa, không ảnh hưởng 
o Chỉnh sửa lớp cha 
o Tất cả các lớp con kế thừa đều bị ảnh hưởng 
o “Fragile base class problem” 
 Kế thừa có 
o Ảnh hưởng tích đối với người phát triển, nhưng 
o Ảnh hưởng tiêu cực đối với bảo trì 
11.3 KIỂM THỬ PHA BẢO TRÌ 
 Người bảo trì xem xét phần mềm như một tập các thành phần có liên quan lỏng lẻo 
o Chúng không liên quan đến sự phát triển phần mềm 
 Kiểm thử hồi quy là cần thiết 
o Lưu giữ các trường hợp kiểm thử và đầu ra của chúng, chỉnh sửa nếu cần thiết 
P
T
I
T