Nhằm góp phần làm phong phú nguồn tư liệu phục vụ nghiên cứu, học tập cho bạn đọc và sinh viên khoa Công nghệ Thông tin và Truyền thông Trường Đại học Cần Thơ, Nhà Xuất bản Đại học Cần Thơ ấn hành và giới thiệu cùng bạn đọc giáo trình “Kiến trúc và thiết kế phần mềm” do Phó Giáo sư, Tiến sĩ Huỳnh Xuân Hiệp, Thạc sĩ Võ Huỳnh Trâm, Thạc sĩ Phan Phương Lan và Thạc sĩ Huỳnh Quang Nghi biên soạn.
Trang 2Bién soan: PGS TS HUYNH XUAN HIEP (Chit bién)
ThS VO HUYNH TRAM ThS PHAN PHƯƠNG LAN ThS HUỲNH QUANG NGHI
GIÁO TRÌNH
KIENTRUG
VA THIET KE PHAN MEM
Trang 3
UC TRUGC XUAT BAN THUC HIEN BOL
TRUNG TAM HOC LIEU TRUONG DAL HQC CAN THO
Giáo trình kiến trúc và thiết kế phần mềm / Huỳnh Xuân Hiệp [et ai: }— Cần Ther: Nxb- Dai
học Cân Thơ, 2015 232 r.: mình họa; 24 em
“Sách có danh mục lã liệu tham khảo ISBN: 9786049195242
1 Computer software management 2.Thiết kế phần mềm Nhan d II: Huỳnh, Xuân Hiệp
Trang 4LOT GIOT THIEU
Nhiim g6p phin im phong phú nguồn tư liệu phục vụ nghiên cứu, học tập cho bạn đọc và sinh viên khoa Công nghệ Thông tin và Truyền thông - Trường Đại học Cần Thơ, Nhà Xuất bản Đại học Cần Thơ ấn hành và giới thiệu cùng bạn đọc giáo trình “Kiến trúc và thiết kế phần mềm” do Phó Giáo sư, Tiên sĩ Huỳnh Xuân Hiệp, Thạc sĩ Võ Huỳnh Trâm, Thạc sĩ Phan Phương Lan và Thạc sĩ Huỳnh Quang Nghỉ biên soạn
Giáo trình gồm 8 chương với Chương đầu tiên
chương sau, ta sẽ dug
số hướng thiết kế quan trọng
dụng web Thêm vào đó, cuối mỗi chương còn có nhiều bải tập thực hành hữu ích cho bạn đọc, Giáo trình là tài liệu học tập có giá trị cho sinh viên các
ngành có liên quan đến kiến trúc và thiết kế phần mềm
"Nhà Xuất bản Đại học Cần Thơ chân thành cám ơn các tác giả và sự đóng góp
ý kiến của quý ô trong Hội đồng thẩm định trường Đại học Cần Thơ đề
Trang 6LOI NOI DAU
nguyên lý, khái niệm, và phương pháp
lượng cao, Qua giáo trình này, bạn đọc sẽ có kỉ Giáo trình - được
hẳn từ của mô hình thiết kế (các rca 2,3,4, 3) va thiết kế quan trọng hiện nay (các chương 6, 7, 8) Chương 1 gi
iết kế phần mềm Những nội dung được cung trong ngữ cảnh công nghệ phần mềm, tỉ
niệm thiết kế, và mô hình thiết kế Chương 2 tập trung vào thiết kế dữ liệu và
lớp với các n : phân tích các yêu cầu và mô hình hóa dựa trên kịch bản, các cách mô hình hóa theo các hướng tiếp cận như lớp, |
hành vi Chương 3 cung cấp một cách tiếp ó hệ thống cho thiết kế kiến
trúc - dựa trên những bản dựng sơ bộ mà từ đó giản m mềm được tạo (hành,
sử dụng Ngoài ra, chương này còn giới thiệu my ban đọc một s
thiết kế giao diện ứng dung Web hiệu quả Chương Š tập tru lưu ý để g vào thiết kế
thiệu về thiết kế hướng mẫu Mục đích của loại
thiết kế này là tạo ra một ứng dụng mới thông qua một bộ các giải pháp đã
được > hing mỉnh (các mẫu thiết kế) cho một tập các vấn đề được mô tả rõ
thiết kế cho các ứng dụng Web Những thiết kế nội hướng, và mức thành phần cả hướng dịch vụ, thiết lễ kiến trúc hướng d dich vu, sự hoi hẹp va
dịch vụ, và mô tả một số hỗ trợ công nghệ cho loại kiến trú sử dụng
Giáo trình “Kiến trúc và Thiết kế phần mềm” được biên soạn trên cơ sở quyền
sich *Software Enginecring - A Practitioner"s Approach” cua tac gid Roger S Pressman - một nguồn tài liệu được công nhận và sử dụng rộng rãi bởi các nhà
chuyên môn, và Bài giảng Thiết kế phần mềm đã được các tác giả giảng dạy trong nhiều năm cho sinh viên đại học ngành Kỹ thuật phần
Trang 7
của học phần Kiến trúc và Thiết kế phần mềm - một học phản bắt buộc đối với sinh viên năm thứ tư bậc đại học ngành Kỹ thuật phần mềm Bên cạnh đó, lùng làm tài liệu tham kháo cho những ai tham gia trong
iêu sót Nhóm biên soạn tất
phản hồi từ bạn đọc để giáo trình này có chất lượng
ngày càng tốt hơn
Cần Thơ, ngày 10 thắng 04 năm 2015
Trang 8MUC LUC
Chuong 1 TONG QUAN VE THIET KE PHAN MEM
1.1 THIET KE TRONG NGU CANH CONG NGHE PHAN MEM 1.1.1 Thiết kế là một chuỗi các quyết định
1.2 TIEN TRÌNH THIET KE
1.2.1 Hướng dẫn và thuộc tính chất lượng phần mềm
1.2.2 Sự tiến hóa của thi phần mềm
1.3 KHÁI NIỆM THIẾT KÉ 1.3.1 Trừu tượng hóa 1.3.2 Kiến trúc phần mềm
1.3.3 Các mẫu thiết kế
1.3.4 Sự phân tách mối quan tâm
1.3.5 Mô đun hóa
1.3.6 Sự che dấu thông tin 1.3.7 Sự độc lập chức năng 1.3.8 Sự tỉnh chỉnh 1.3.9 Các khía cạnh 1.3.10 Tái cấu trúc 1.3.11 Các khái niệm thiết kế hướng đối tượng 1.3.12 Các lớp th 1.4 MƠ HÌNH THIẾT KE 1.4.1 Các phần tử thiết kế dữ liệu 1.4.2 Các phần tử thiết kế kiến trúc 1.4.3 Các phần tử thiết kế giao diện 1.4.4 Các phần tử thiết kế mức thành phần 'ác phân tử thiết kế mức triển khai mi
CÂU HỘI HƯỚNG DẪN ÔN TẬP
ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH
TÀI LIỆU THAM KHẢO:
Chương 2 THIẾT KẾ DỮ LIỆU
Trang 92.1.3 Phan tích lĩnh vực
2.1.4 Các tiếp cận mô hình hóa yêu cầu
2.2 MƠ HÌNH HĨA DỰA TRÊN KỊCH BẢN
2.2.1 Tạo trường hợp sử dụng ban đầu
2.2.2 Tỉnh chỉnh trường hợp sử dụng ban đầu 2.2.3 Xây dung trường hợp sử dụng chính thức
2.3 CÁC MƠ HÌNH UML HỖ TRỢ TRƯỜNG HỢP SỬ DỤNG 2.3.1 Sơ đồ hoạt động 2.3.2 Sơ đồ lần 2.4 KHÁI NIỆM MƠ HÌNH HÓA DỮ LIỆU 2.4.3 Các môi quan hệ 2.5 MƠ HÌNH HĨA DỰA TRÊN LỚP 2.5.1 Xác định các lớp phân tích 2.5.2 Xác định các thuộc tính 2.5.3 Dinh nghĩa các phương thức
3.5.4 Mô hình hóa lớp-trách nhiệm-cộng tác 2.5.5 Kết hợp và phụ thuộc
2.5.6 Phân tích gói cơng việc
2.6 MƠ HÌNH HÓA HƯỚNG LUÔNG
2.6.1 Khởi tạo mô hình luồng dữ liệu 2.6.2 Khởi tạo mô hình kiểm soát lưỗng 2.6.3 Đặc tả kiếm sốất
2.64 Dac tả xử lý
2.7 MƠ HÌNH HĨA HƯỚNG HÀNH VI
2.7.1 Xác định sự kiện với trường hợp sử đụng 2.7.2 Biểu diễn trạng thái
2.8 MÔ HÌNH HÓA BẰNG MẪU TONG KET
CÂU HỘI HƯỚNG DẪN ÔN TAP ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH TÀI LIỆU THAM KHẢO
Chương 3 THIẾT KẾ KIÊN TRÚC
3.1 KHÁI NIỆM VỀ KIEN TRUC PHAN MEM
3.1.1 Kiến trúc phần mềm
3.1.2 Tầm quan trọng của kiến trúc phần mềm
Trang 1032
33
34
3.1.4 Các thể loại kiến tric (Architectural Genres)
CÁC PHONG CÁCH KIÊN TRÚC (ARCHITECTURAL STYLES) 3.2.1 Kiến trúc lấy dữ liệu làm trung tâm (data-centered architectures) 3.2.2 Kiến trúc luồng dữ liệu (data-flow architectures)
3.2.3 Kién tric goi va tra vé (call and return architectures) 3.2.4 Kién tric hudng déi tugng (object-oriented architectures) 3.2.5 Kiến trúc phân lớp (layered architectures)
THIET KE KIEN TRUC PHAN MEM
3.3.1 Biểu diễn hệ thống trong ngữ cảnh 3.3.2 Định nghĩa các archetype
3.3.3 Tình chỉnh kiến trúc thành các thành phần 3.3.4 Mô tả các thể hiện của hệ thống
PHƯƠNG PHÁP THIET KẾ KIÊN TRÚC
3.4.1 Các kiểu luỗng thông tin
3.4.2 Chuyển luỗng biến đổi (transform mapping) 3.4.3 Chuyển luỗng giao tác (transaction mapping)
TONG KET
CÂU HỎI HƯỚNG DẪN ÔN TẬP ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH TÀI LIỆU THAM KHẢO
Chương 4 THIẾT KÉ GIAO DIỆN NGƯỜI SỬ DỤ: 41 42 43 44 45
BO QUY TAC VANG
4.1.1 Cho phép người sử dụng duy trì sự kiểm soát 4.1.2 Giảm t phải nhớ của người sử dụng,
4.1.3 Tạo sự nhất quản về giao diện
QUY TRINH PHAN TICH VA THIET KE GIAO DIEN NGUOI SU’ DUNG 4.2.1 Cac mô hình phân tích và thiết kế giao diện
4.2.2 Quy trình phân tích và thiết kế giao diện
PHẦN TÍCH GIAO DIEN
4.3.1 Phan tích người sử dụng
4.3.2 Phân tích nhiệm vụ và mô hình hóa 4.3.3 Phân tích nội dung hiển thị
4.3.4 Phân tích môi trường làm việc THIET KE GIAO DIEN
4.4.1 Ap dung cac bude tt
Trang 11thiết kế giao diện Web lo diện cho ứng dụng Web 4.5.1 Nguyên tắc và hướng,
4.5.2 Luồng công việc thiết kí
4.6 DANH GIA THIET KE
TONG KET
CÂU HỎI HƯỚNG DẪN ÔN TẬP ĐỊNH HƯỚNG THẢO LUẬN
BÀI TẬP THỰC HANH
TAI LIEU THAM KHẢO:
Chương 5 THIẾT KẾ THÀNH PHẢN
5.1 GIGI THIEU
5.1.1 Quan diém hướng đổi tượng (An Object-Oriented View)
5.1.2 Quan điểm truyền thống (The Traditional View)
5.1.3 Quan điểm hướng tiến trình (A Process-Related View)
5.2 THIẾT KẾ THÀNH PHẢN DỰA TRÊN LỚP 5.2.1 Nguyên tắc tỉ 5.2.2 Hướng dẫn thiết kế cấp thành phần 5.2.3 Sw gin két (Cohension) 5.2.4 Sự nối kết (Coupling) 5.3 CÁC BƯỚC THIẾT KE THANH PHAN CHO HE THONG HUGNG ĐÓI TƯỢNG
5.4 THIET KE CAC THANH PHAN TRUYEN THONG
5.4.1 Các ký hiệu thiết kế đỗ họa
5.4.2 Các ký hiệu thiết kế dạng bảng
3.4.3 Ngôn ngữ thiết kế chương trình (PDL)
5.5 PHAT TRIEN TREN CAC THANH PHAN
5.5.1 Công nghệ Tinh vue ting dung (Domain Engineering) 5.5.2 Cơ cấu, sự tương thích và chất lượng của thành phần 3.5.3 Phân tích và thiết kế cho việc tái sử dụng
5.5.4 Phân loại và truy xuất các thành phần
TONG KET
CÂU HỘI HƯỚNG DẪN ÔN TAP ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH TÀI LIỆU THAM KHẢO
Chương 6 THIET KE HUONG MAU (PATTERN)
Trang 126.1.4 Kho và Ngôn ngữ mẫu
6.2 THIET KE PHAN MEM HƯỚNG MẪU
6.2.1 Thiết kế hướng mẫu trong bối cảnh 6.2.2 Tư duy trong mẫu
6.2.3 Nhiệm vụ thiết kế
6.2.4 Xây dựng bảng tổ chức theo mẫu 6.2.5 Những sai lâm chung của thiết kế
6.3 MẪU KIÊN TRÚC
6.4 MAU THIET KE MUC THANH PHAN
6.5 MAU THIET KE GIAO DIEN NGUOI SU DUNG 6.5.1 Toàn bộ giao dign ngudi sit dung (Whole Ul) 6.5.2 Dân trang (PageLayout)
6.5.3 Các biểu mẫu và dữ liệu đầu vào (Forms and Input) 6.5.4 Các bảng 6.5.5 Thao tác dữ liệu trực tiếp 6.5.6 Sự điều hướng 6.5.7 Tìm kiếm 6.5.8 Các thành phần của trang 6.5.9 Thương mại điện tử 6.5.10 Miscellaneous 6.6 MAU THIET KE UNG DUNG WEB 6.6.1 Trọng tâm thiết k 6.6.2 Mức độ chỉ tiết thiết kế TONG KET
CÂU HÔI HƯỚNG DẪN ÔN TAP ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH TÀI LIỆU THAM KHẢO:
Chương 7 THIẾT KẾ ỨNG DỤNG WEB
7.1 CHẤT LƯỢNG THIẾT KE UNG DUNG WEB 7.2 MỤC TIÊU CUA THIET KE
7.2.1 Tinh đơn giản
7.2.2 Tính nhất quán
7.2.3 Định danh 7.2.4 Sự mạnh mẽ
7.2.5 Khả năng điều hướng,
7.2.6 Sự Ấn tượng từ bên ngoài 7.2.7 Kha nding tương thích
Trang 137.4 THIET KE GIAO DIEN
7.5 THIET KE THAM MY
ế đồ họa
7.6 THIET KE NOI DUNG
7.6.1 Đối tượng nội dung 7.6.2 Vấn đề thiết kế nội dung
7.7 THIẾT KÉ KIÊN TRÚC
7.7.1 Kiến trúc nội dung 7.7.2 Kiến trúc ứng dụng Web
7.8 THIET KE DIEU HUONG
7.8.1 Ngữ nghĩa của sự điều hướng 7.8.2 Cú pháp của sự điều hướng,
7.9 THIET KE MUC THANH PHAN
7.10 PHUONG PHAP THIET KE SIEU PHƯƠNG TIỆN HƯỚNG ĐÔI TƯỢNG 7.10.1 Thiết kế khái niệm của OOHDM
7.10.2 Thiết kế điều hướng của OOHDM
7.10.3 Thiét ké giao diện trừu tượng va Thực hiện
TONG KET
CÂU HỎI HƯỚNG DẪN ÔN TẬP ĐỊNH HƯỚNG THẢO LUẬN BÀI TẬP THỰC HÀNH TÀI LIỆU THAM KHẢO:
Chương 8 THIẾT KẾ KIÊN TRÚC HƯỚNG $.1 GIỚI THIỆU 8.1.1 Các mẫu cho SOA §.1.2 Nguyên tắc thiết kế dịch vụ 8.2 MẪU MỖI GIỚI 8.2.1 Mẫu Đăng ký dịch vụ
8.2.2 Mau Chuyển tiếp môi giới
8.2.3 Mẫu Xử lý môi giới
8.2.4 Mẫu Phát hiện dịch vụ
8.3 MAU GIAO DICH
8.3.1 Mẫu Giao thức cam kết hai giai đoạn
8.3.2 Mẫu Giao dịch tổ hợp
8.3.3 Mẫu Giao dịch muôn năm (Long-Living Transaction)
8.4 MẪU ĐÀM PHÁN
Trang 148.5.2 Tai sir dung dịch vụ 8.5.3 Thiết kế các SOA §.6 HỖ TRỢ CONG NGHE CHO SOA 8.6.1 Các giao thức dịch vu Web 8.6.2 Các dịch vu Web 8.6.3 Dich vy dang ky 8.6.4 Dịch vụ phát hiện v TONG KET
Trang 15Hình 1.1 Hình 1.2 Hinh 1.3 Hinh 1.8 Hinh 1.9 Hinh 2.1 Hình 2.2 Hình 2.3 h24 Hình 2.5 Hình 2.6 Hình 2.7 Hình 2.8 Hình 2.11 Hình 2.12 1h 2.13 Hinh 2.14 Hinh 2.15 Hinh 2.16 Hình 2.17 ình 2.18 Hình 2.19 Hình 2.20 Hình 2.21 Hình 3 Hình 3.2 DANH MỤC HINH
ôi từ mô hình yêu cầu sang mô hình thiế
Chuyển đổi từ mô hình yêu cầu sang mô hình thiết kế (2)
Mô đun hóa và chỉ phí phần mềm
tế cho FloorPlan và sự kết tập tổng hợp cho lớp
Các chiêu của mô hình thiết kê
Giao diện biểu diễn cho ContolPancl
Một sơ đồ thành phần dang UML
Một sơ đồ triển khai dang UML
Mô hình phân tích yêu cầu như một cầu nồi giữa mô tả hệ thống,
và mô hình thiết kế
Đầu vào và đầu ra cho phân tích lĩnh vực Các phần tử của mô hình yêu
Sơ đồ trường hợp sử dụng ban đầu/sơ bộ cho hệ thông SafeHome
Sơ đồ hoạt động cho camera giám sát trủy cập thông qua Internet - chức năng hiển thị các bức ảnh
Sơ đồ làn cho camera gidm sat'tfuy cap thong quá Internet -
chức năng hiển thị các bức ảnh
Bang biéu diễn các đối tượng đữ liệu
Các mối quan ñiệ giữa các đối tượng dữ liệu
Sơ đồ lớp cho lớp Hệ thống System
Sơ đỗ lớp cho lớp Mặt bằng sàn FloorPlan
Một mô hình thé chi mye (CRC)
Da dang/ban s6
Các phụ thuộc
Các gói
DED mức ngữ cảnh cho chức năng bảo mật SafeHome
DFD mite | cho chite nang bảo mật SafeHome
DED mức 2 tỉnh chỉnh xử lý Giám sát bộ cảm biến
So dé trạng thái cho chức năng bảo mật SafeHome
Bảng kích hoạt xử lý (PAT) cho chức năng bảo mật của SafeHome
Sơ đồ trạng thái cho lớp ControlPanel
Sơ đồ tuần tự bộ phận của chức năng bảo mật SafeHome
én trúc lấy dữ liệu làm trung tâm
Trang 16Hình 3.3 Hình 3.9 Hình 3.10 Hình 3.11 Hình 3.12 lh 3.13 Hình 3.14 Hình 3.15 Hình 3.16 Hình 3.17 Hình 3.18 h3.19 Hinh 3.20 ình 3.21 Hình 3.22 Hình 4.1 Hình 4.2 Hình 5.3 Hình 5.4 Hình 5.5 Hình 5.6 Hình 5.7 hh5.8 Hình 5.9 Hình 5.10 Hình 6.1 Hình 7.1 Hình 7.2 Hình 7.3 Kiến trúc chương trình chính/chương trình phụ Kiến trúc phân lớp
Biểu đồ ngữ cảnh kiến trúc ACD
Biểu đồ ngữ cảnh kiến trúc cho chức năng bảo vệ nhà của SafeHome Quan hg UML cho các archetype của chức năng bảo vệ nhà SafeHome ở mức cao
Kiến trúc tông thê của SafeHome với các thành phí
Một minh họa cho SafeHome với các thành phẫn chỉ tiết
Kiểu luồng biến đổi
Kiểu luồng giao tác
Mô hình ngữ cảnh DED cho chức năng bảo vệ nhà SafeHome
DED mite l cho chức năng bảo vệ nhà SafeHome
DFD mức 2 cho hệ thông con giám sát cảm biển
'DED mức 3 cho hệ thống con giám sát cảm biển với đặc tả biên luỗng Phân tách mức độ một cho hệ thống con giám sát cảm biển
Phân tách mức độ hai cho hệ thống con giám sát cảm biển
Lược đồ cấu trúc cho quá trình giám sát các cảm biến
Lược đỗ cấu trúc đã tỉnh chỉnh cho quá trình giám s
DED mức 2 cho hệ thống con đương tác người sử dụng
Chuyển luỗng giao tác cho hệ thống con đương tác người sử dụng
Phân tách mức độ một cho hệ thống con tương tác người sử dụng
Quy trình thiết kế giao diện người sử dụng
Lược đồ cho chức năng bán thuốc theo toa
Bồ trí màn hình sơ bộ Ánh xạ mục tiêu của ngự
Chu kỳ đánh giá giao diện
Phác thảo chỉ tiết một thiết kế thành phần
Lược đồ cấu trúc cho một hệ thống theo quan điểm truyền thống Thiét ké cp thanh phan cia ComputePageCost
kế theo nguyên tắc OCP
Gắn kết mức lớp
Biểu đỗ hợp tác với thông báo
Các giao diện và lớp tái cấu trúc được định nghĩa cho Printlob
Sơ đồ hoạt động UML cho hoat d6ng computePaperCost()
Biểu đồ trạng thái phân đoạn cho lớp Prinob
Các cấu trúc lưu đồ
“Thiết kế hướng mẫu theo bối cảnh Cây yêu cầu chất lượng,
“Tháp thiết kế cho các ứng dung Web
Trang 17Hình 7.5 Cấu trúc dạng lưới
Cấu trúc phân cấp
Cấu trúc được nối kết mạng Kiến trúc MVC
Tạo một đơn vị ngừ nghĩa điều hướng NSU,
Hình 7.10 Sơ đồ khái niệm thành phần của SafeHomeAssured.com
Hình 8 Đăng ký dich vụ với bộ môi giới
Hình 8.2 _ Mẫu chuyển tiếp môi giới (trang trắng)
Hình 8.3 Mẫu xử lý môi giới
Hình 8.4 Mau phát hiện dich vụ (trang vàng)
\h 8.5 Ví dụ về giai đoạn đầu của giao thức cam kết hai giai đoạn:
chuyển ngân
Hình 8.6 Ví dụ về giai đoạn thứ hai của giao thức cam kết hai giai đoạn: chuyển ngân
Hình 8.7 Ví dụ về mẫu giao dịch tổ hợp
Hinh 8.8 Ví dụ về mẫu giao dich muôn năm
Trang 18DANH MUC BANG
Trang 19DANH MUC KY HIEU VIET TAT
ADV Abstract Data View
ACD Architectural Context Diagram ADL Architectural Description Language CBSE ‘Component-Based Software Engineering cep ‘The Common Closure Principle
CSPEC Control Specification
RP ‘The Common Reuse Principle DFR Design for Reuse
ERD Entity-Relationship Diagram GUI Graphical User Interface HCI Human Computer Interaction MVC Model-View-Controller NSU Navigation Semantic Unit
OOHDM: Object Oriented Hypermedia Des PDL Program Design Language PAT Pfocess Activation Table PSPEC Process Specification
REST Representationak State Transfer SOA Service Oriented Architecture SQA Software Quality Assurance UL User Interface
WON Ways of Navigating
Trang 20DANH MỤC MỘT SÓ THUẬT NGỮ Abstract Data View - ADV Abstractions Architectural Context Diagram - ACD Activity diagram Actor Architectural Description Language - ADL Alternative behavior Architectural description Architectural design Architectural styles Antificial intelligence Aspect-oriented method Aspects Associations Atomicity Behavioral elements Behavioral model Boundary classes Bueprint Category Component-Based Software Engineering - CBSE The Common Closure Principle - CCP Characterist Class-based Class-oriented models Class-responsibility-collaboration model
Khung nhìn dữ liệu trừu tượng Các trừu tượng hóa Sơ đồ ngữ cảnh kiến trúc Sơ đồ hoạt động Tác nhân Ngôn ngữ mô tả kiến trúc Hanh vi thay thé Mô tả về kiến tric “Thiết kế kiến trúc Các phong cách kiến trúc
Trí tuệ nhân tạo
Trang 21Client-server Cohesion Collaboration
Combinatorial specification of behavior Commercial and nonprofit Communication Compatibility Component-level design Components Composability Compound transaction Concept Consistency Constrained dependencies Control Specification - CSPEC Controtled autonomy Controller classes Convergence Counteroffers Counterproposal Coupling The Common Reuse Principle - CRP Data abstraction Data attributes Data flow Data models Data structure Data/class design Data-centered architecture Data-flow architecture Decision table Sự cộng tác/hợp tác Đặc tả tổ hợp của hành vi Thương mại và phi lợi nhuận Truyền thông Khả năng tương thích Thiết kế mức thành phần Các thành phần Tính hợp thành Giao địch tổ hợp Khái niệm Nhất quán Phụ thuộc rằng buộc Đặc tả kiêm soát Tính tự chủ được kiểm soát Các đơn chào giá cạnh tranh Đề xuất phản hồi Sự nối kết
Nguyên tắc tái sir dung chung
'Trừu tượng hóa dữ liệu Các thuộc tính dữ liệu Luỗng dữ liệu Các mô hình dữ liệu Cấu trúc dữ liệu Thiết kế dữ liệu/lớp
Kiến trúc lấy dữ liệu làm trung tâm
Trang 22Dependencies Deployment diagram Deployment-level design Design patterns Design for Reuse - DFR Diagram Discoverability Diversification Domain-specific Dynamic model E-commerce Efficiency Elaborative Entity classes Entity-Relationship Diagram- ERD Ergonomically sound Error handling Flat transaction Flexibility Flowchart Flow-oriented Framework Framework model Functional model Functionality Genres Graphical User Interface - GUI Hierarchical structure Human Computer Interaction - HCL Hypermedia Identifier Các phụ thuộc Sơ đồ triển khai Thiết kế mức triển khai Các mẫu thiết kế Thiết kế để tai sir dung So dd Tinh có thé phát hiện Đa dạng hóa Lĩnh vực cụ thê Mô hình động Thuong mai điện tử Tính hiệu quả Xây dựng chỉ tiết Các lớp thực thể Sơ đồ thực thê-quan hệ Thân thiện với người sir dung Xử lý lỗi Giao dịch phẳng, Linh hoạt Sơ đỗ khối Hướng luồng, Khung làm việc Mô hình khung làm việc Mô hình chức năng Chức năng “Thê loại Giao diện người sử dụng đồ họa Cấu trúc phân cấp
“Tương tác người máy
Trang 23Implementation model Informal use cases Inheritance Instance Integration Interface design Layered architectures Learnability Linear structure Main program/subprogram Mental model Menu Metaphor Middleware Model-driven development Model-View-Controller Architecture MVC Navigability Navigation Semanti¢ Unit~'NSU Object elaboration Object Oriented Hypermedia Design Method - OOHDM Object-oriented architecture Objects Operations Paradigm Program Design Language - PDL Peer-level systems Performance Persistent classes Plaform Principles Mô hình thực hiện Các trường hợp sử dụng chưa chính thức Kế thừa Thể hiện Tích hợp Thiết kế giao diện Các kiến trúc phân lớp Tính có thé hoc Cấu trúc tuyến tính Chương trình chính/chương trình phụ Mô hình tư duy Trình đơn Phép ấn dụ Tầng trung gian
Phát triển hướng đẫn dắt theo mô hình
Kiến trúc mô hình - khung nhìn - bộ
điều khi
'Khả ñiãng điều hướng
Đơn vị ngữ nghĩa điều hướng
"Xây dựng đối tượng
Phương pháp thiết kế siêu phương tiện
hướng đôi tượng
Trang 24Problem-oriented Procedural abstraction Process Activation Table - PAT Process Specification - PSPEC Process view Processing rule Properties Pseudocode Readability Refactoring Reliability Requirements engineering Requirements model Response time Responsibilities Reuse library Ripple effect Robustne: Scenario-based models of requirements Secondary scenarios Sequential specification of behavior ty Site map Simpl
Service Oriented Architecture - SOA Software domain analysis, Software process Software Quality Assurance - SQA Stage diagram Statelessness Stepwise refinement Subassemblies Hướng vấn đề 'Trừu tượng hóa (hủ tục 'Bảng kích hoạt tiến trình Đặc tả tiến trình Khung nhìn tiến trình Quy tắc xử lý Các đặc tính Ngôn ngữ gi: ng đọc Độ tin cậy Kỳ thuậUphân tích yêu cầu Mô hình yêu Th gian đáp ứng Các trách nhiệm
Ther vign tai sử dụng
Trang 25Subordinate systems Superordinate systems Supportability Swimlane diagrams Symbol Template Test-driven development rack state Tranational View Universal Description sability Use case Visible navigation Visual appeal
Ways of Navigating - WON
Web Services Description Language = WSDL Workflow analysis, Các hệ thống phía dưới Các hệ thống phía trên Khả ng hỗ trợ Ký hiệu Biểu mẫu
Phát triển hướng dẫn dắt kiểm thử ‘Trang thai theo vết
Quan điểm truyền thống Mô tả tổng quát Kha nang sir dung Trường hợp s dụng Giao diện người sử dụng Mô hình người sử dụng Tiện ích
Sự điều hướng trực quan Ấn tượng từ bên ngồi
Cách điều hướng
'Ngơn ngữ mô tả các dịch vụ Web
Trang 26Chuong 1
TONG QUAN VE THIET KE PHAN MEM Thiét ké phn mém (software design engineering) bao gém
nguyên tắc (principles), khai niệm (concepts) và thực hinh (practices) dn dén sự phát triển của một hệ thống hoặc sản phẩm phần mềm chất lượng cao Các nguyên tắc thiết kế thiết lập một triết lý quan trọng hướng
Khái niệm thiết kế phải được hiểu trước khi cơ chế thực hành thi ợ
dụng Thực hành thiết kế bản thân nó sẽ dẫn đến việc tạo ra các thể hiện/phiên
bản khác nhau của mềm phục vụ như một hướng dẫn cho hoạt động xây
dựng phần mềm về sau Mục đích của thiết kế là tạo ra một mô hình hoặc một mô tả thể hiện độ vững chắc, tính thương phẩm và sự thích thú Để thực hiện điều này, cần phải thực hành đa dạng hóa (diversification) và sau đó hội tụ (convergence) Chương 1 sẽ cung cấp cho người đọc kiến thức tổng quan về
iết kế ìn 1 và 2 của chương nhắn mạnh tầm quan trọng của
giai đoạn thiết kế phần mềm trong quy trình phát triền phần mềm, và những hướng dẫn mà hoạt động thiết kế nên tuân thủ để đạt được các mục tiêu chất
lượng Phần 3 của chương sẽ cung cấp các khái niệm th é š phần mỗi làm „ thiết kế kiến "mức, những thiết kế này ện, và thiết kế mức thành phản - chỉ ti sẽ được lần lượt trình bảy trong 4 chương kế tiếp
1.1 THIẾT KẾ TRONG NGỮ CẢNH CÔNG NGHE PHAN MEM
kế phần mềm nằm ở lõi kỹ thuật (technical kerel) của công nghệ phần
mềm và được áp dụng không phụ thuộc vào mô hình quy trinh/tién trình phần mềm (software process) được sử dụng Thiết kế phần mềm, được bắt đầu từ mỗi khi yêu cầu phần mềm đã được phân tích và mô hình hóa, là hành động công nghệ phần mềm cuối cùng trong hoạt động mô hình hóa và thiết lập ra giai đoạn xây dựng phần mềm (tạo mã lệnh và kiểm thử)
Mô hình yêu cẩu (requirements model) còn được gọi là mô hình phân tích Để thuận tiên cho vi: ừ đây thuật ngữ mô hình yêu cầu sẽ được sử dụng Mỗi một phẩn tửiyều tố của mô hình yêu cầu cung cấp thông tin can thiết để tạo ra bon md, có cho một đặc tả thiết kế hoàn chỉnh
Luông thông tin trong quá trình thiết kế pI lềm được minh họa trong Hình
Trang 27
thiết kế và phương pháp thiết kế được thảo luận trong các chương sau sẽ bao
gồm thiết kế dữ liệu/lớp (data/class desien), thiết kế kiến trúc (architectural design), thiết kế giao dign (interface design) va thiét ké thanh phần (component design) So wang thi Gi pin ich Mo inh CRC đôn Sodding te Hình 1.1 Chuyển đổi từ mô hinh yêu cầu sang mô hình thiết kế (1) “Thiết kế dữ liệu
Mồ hình phần tích yêu câu Mô bình thiết kế
Trang 28
Thiết kế dữ liệu/lớp chuyền đỗi mô hình lớp vào việc thực hiện thiết kế lớp và
cấu trúc dữ liệu cần thiết được yêu cầu để cài đặt phần mẻm Các đối tượng và các mối quan hệ được xác định trong so dd CRC (class-responsibility- collaboration) và nội dung dữ liệu chỉ tiết được mô tả bởi
ký hiệu khác tạo cơ sở cho hoạt
lớp có thể xây ra kết hợp với thiết kế kiến trúc phản mềm Thiết kể lớp chỉ tiết hơn xảy ra khi mỗi một thành phần phần mềm được thiết kế,
Thiết kế kiến trúc xác định mỗi quan hệ giữa các phần tử cấu trúc chính của
phần mềm, các phong cách kiến trúc (architeetural styles) và các mẫu thiết kế
(design patterns) có thé được sử dụng dé đạt được các yêu cầu được xác định cho hệ thong, và những ràng buộc ảnh hưởng đến cách thức mà kiến trúc có thể được cài đặt Các biểu diễn của thiết kế kiến trúc, có nguồn gốc từ mô hình
các yêu cẩu, chính là khung nền của một hệ thống dựa trên máy tính
Thiết kế giao diện mô tả cách thức phần mềm giao tiếp với các hệ thống tương,
thích với nó, và với con người người sử dụng nó Một giao diện bao hàm một luồng thông tin (ví dụ như dữ liệu và/hoặc kiểm soát) và một loại hình cụ thể của hành vi Vì vậy, kịch bản sử dụng và mô hình hảnh vỉ cung cấp nhiều thông tin cần thiết cho thiết kế giao diện
Thiết kế mức thành phân chuyển đôi các phần từ cấu trúc của kiến trúc phần
mềm thành một mô tả về thủ tục của các thành phần phần mềm Thông tin thu được từ các mô hình dựa trên lớp, các mô hình luông, và mô hình hành vi
phục vụ như là cơ sở đề thiết kế thành phần
1.1.1 Thiết kế là một chuỗi các quyết định
Có thể xem quyết định thiết kế (xem Hình 1.3) với các thi thay thế từ
những lựa chọn khác nhau Trong đó, các đường thăng biểu diễn cho các tùy chọn và các đường đậm nét là tập hợp các quyết định được đưa ra Máy khách phụ thuộc í “Tầng phân tách giao diện người dùng eho a lách ập trình Java trinh Visual Basic Máy khách phụ thuộc nhiêu Lập trình C++
Tang khéng phan tach giao
Đơn khỏi _ điện người dùng cho máy khách
Trang 29Trong quá trình thiết kế, các quyết định được đưa ra cuối cùng sẽ ảnh hưởng
đến sự thành công của việc xây dựng phần mm và rất quan trọng, tạo ra sự dễ dàng mà phần mềm có thể được bảo trì sau này Do đó giai đoạn thiết kế là rất
quan trọng!
Tầm quan trọng của thiết kế phần mềm có thể được ghi bằng một từ duy nhất
là chất lượng Thiết kế là nơi mà chất lượng được “nuôi dưỡng” trong công nghệ phẫn mẻm Thiết kế cung cấp các mô tả của phần mèm có thể được đánh giá về chất lượng Thiết kế là cách duy nhất có thê dịch chính xác yêu cầu của các bên liên quan vào một sản phẩm hoặc hệ thống phần mềm hoàn chỉnh Thiết kế phẫn mềm phục vụ như nên tảng cho tất cả các hoạt động kỹ thuật phần mềm và hỗ trợ phân mềm theo sau Nếu thiết kế không có, nguy cơ xây dựng một hệ thống không ôn định sẽ xuất hiện, và sự thất bại có thể xây ra ngay cả khi một thay đôi nhỏ được thực hiện; sự kiểm thử có thể gặp khó khăn; chất lượng không thê được đánh gid cho dén gan thời điểm cuối trong tiến trình phần mềm khi mà thời gian còn lại ngắn và nhiều kinh phí đã được sử dụng, 1.2 TIEN TRINH THIET KE
Thiết kế phần mềm là một quá trình lặp (iterative process) mà thông qua đó
yêu cầu được chuyển thành một "kế hoạch chỉ tiết" (*bieprint") đề xây dựng phần mềm Ban đâu, kế hoạch chỉ tiết mổ tạ một cái nhìn toàn điện của phần mềm Đó là, các thiết kế được thế hiện ở một mức độ trừu tượng cao - một
mức độ mà nó có thé được truy Vét một cách trực tiếp đến mục tiêu cụ thể của
hệ thống và và các yêu cầu vẻ hành xi chức năng, và dữ liệu chỉ tiết hơn Khi et kế được lặp lạ, các tỉnh chính tiếp theo dẫn đền những thẻ hiện của thiết kế ở các cấp thấp hơn so với cấp trừu tượng, những thiết kế này vẫn có thể được truy nguồn từ yêu cầu, nhưng kết nối là tỉnh tế hơn
2.1 Hướng dẫn và thuộc tính chất lượng phần mềm
Trong suốt quá trình thiết kế, chất lượng của các thiết kế phát triển được đánh
giá bằng một loạt các đánh giá kỹ thuật Trong đó, ba đặc điểm được đề nghị như những hướng dẫn cho việc đánh giá một thiết kế tốt là:
~_ Việc thiết kế phải thực hiện tat cả các tường minh có trong mô
hình yêu cầu, và nó phải chứa tắt cả các yêu cầu tiém ẩn mong muốn của các bên liên quan
~_ Việc thiết kế phải là một hướng dẫn dễ hiểu, đễ đọc đối với người viết
các mã lệnh, người kiểm thử, và sau đó là người hỗ trợ phần mềm
-_ Việc thiết kế nên cung cấp một bức tranh hoàn chỉnh về phần mềm, giải
Trang 30
Mỗi một đặc điểm thực sự là một mục tiêu của quá trình thiết kế, Vậy làm thế
nào để đạt các mục tiêu này? Câu trả lời là sử dụng các hướng dẫn chất lượng và thuộc tính chất lượng
Hướng dẫn chất lượng (qualiqy guidelines)
Để đánh giá chất lượng của một mô tả thiết kế, ta cần phải thiết lập các tiệu
chuẩn kỳ thuật đối với thiết kế tốt mà trong đó các khái niệm thiết kế cần xem như là tiêu chuẩn chất lượng phần mềm Dưới đây là một số hướng dẫn chất lượng
Thứ nhất, một thiết kế nên trình bày một kiến trúc (1) được tạo ra bằng cách
sử dụng phong cách kiến trúc hoặc mô hình đã được ghỉ nhận, (2) bao gồm các thành phần mang những đặc tính thiết kế tốt, và (3) có thẻ được cài
một cách tiến hóa, tạo điều kiện cho cài đặt và kiểm thử
Thứ hai, một thiết kế nên được mô đun hóa và như vậy phần mềm nên được phân chia một cách hợp lý thành các thành phần hoặc hệ thống con
Thứ ba, một thiết kế cần có biểu diễn khác nhau của dữ liệu, kiến trúc, giao
diện, và các thành phần
Thứ tư, một thiết kế nên dẫn đền cấu trúc dữ liệu thích hợp cho các lớp được
cải đặt và được rút ra từ các mẫu dữ liệu đã được nhận biết
Thứ năm, một thiết kế nên dẫn đến các thành phần mang những đặc điểm chức năng độc lập
Thứ sáu, một thiết kế nên dẫn đến giao điện làm giảm sự phức tạp của các
nối giữa các thành phần và với môi trường bên ngoài
Thứ bẩy, một thiết kế nên được bắt nguồn bằng cách sử dụng một phương pháp lặp được dẫn dát bởi thông tin thu được trong quá trình phân tích yêu cầu phần mềm
Cuối cùng, một thiết kế cần được thể hiện bằng cách sử dụng ký hiệu truyền tải một cách hiệu quả ý nghĩa của nó
Các thuộc tính chất lượng (quality attributes)
Hewlett-Packard phat triển một tập hợp các thuộc tính chất lượng phần mềm - được viết tắt là FURPS - gồm chức năng, khả năng sử dụng, độ tin cậy, hiệu
suất, va kha nang hé tro (functionality, usability, reliability, performance,
supportability) Các thuộc tính chất lượng FURPS đại điện cho mục tiêu của
tắt cả các thiết kế phần
Trang 31
Chức năng được đánh giá qua tập tinh năng va các khả năng của chương trình, tính tổng quát của các chức năng được giao và sự an toàn của toàn bộ hệ thống Khả năng sử dụng được đánh giá bằng cách xem xét các con người, thâm mỹ tông thể, tính nhất quán, và tài liệu Độ rửr cậy được đánh giá bằng cách đo tân suất và mức độ nghiêm trọng của thất bại, tính chính xác của kết quả đầu ra - có nghĩa là thời gian dé that bai (MTTF, mean-time-to- failure), kha nang phục hồi từ thất bại, và khả năng dự đoán của chương trình
Hiệu suất được đo bằng cách xem xét tốc độ xử lý, thời gian đáp ứng, sự tiêu thy tai nguyên, và hiệu quả Khả săng hỗ ợ kết hợp các khả năng bảo trì (khả
năng mở rộng, khả năng thích ứng), khả năng kiểm thử, khả năng tương thích, khả năng cấu hình (khả năng tổ chức và các yếu tổ kiểm soát của câu hình phần mềm), sự dễ dàng mà một hệ thống có thê được lắp đặt, và sự dễ dàng mà các vấn đề có thể được bản địa hóa Không phải thuộc tính chất lượng phần mềm có trọng số tương đương như nhau khi việc thiết kế phần mềm được phát triển Một ứng dụng có
thể yêu cầu chức năng với sự nhân mạnh đặc biệt về an ninh Một ứng dụng
khác có thể yêu cầu thực hiện với sự nhấn mạnh đặc biệt về tốc độ xử lý Một
ứng dụng thứ ba có th tập trung vào độ tin cậy Không phụ thuộc vào trọng „ điều quan trọng cần lưu ý là các thuộc tính chất lượng phải được quan tâm khi bất đầu thiết kể, không phải sau khí thiết kế được hoàn tắt và việc xây
dựng đã bắt đầu
1.2.2 Sự tiến hóa của thiết kế phần mềm
Sự tiến hóa của thiết kế phần mềm là một quá trình liên tục và kéo dài qua
nhiều thập kỷ cho đến nay, Công việc thiết kế ban đầu tập trung vào các tiêu chí cho sự phát triên cũa các chương trình mô “đun và phương pháp cho tỉnh
chỉnh cấu trúc phần mềm theo cách từ trên xuống (topdown) Các khía cạnh thủ tục của định nghĩa thiết kế phát triển thành một triết lý gọi là lậ
cấu trúc Sau đó, các phương pháp địch các luỗng dữ liệu (data flow) hoặc cáu
trúc dữ liệu (data strueture) vào một định nghĩa thiết kế được đẻ xuất Những ép cận thiết kế mới hơn được đề xuất là
đây, thiết kế phần mềm nhắn mạnh về kiến trúc phần mềm (software architecture) và các mẫu thiết kế (design patterns) mà chúng có thể được sử dung dé cai đặt các kiến trúc phần mềm và các cấp thấp hơn trong trừu tượng hóa thiết kế Sự phát triển tập trung vào phương pháp hướng khía cạnh (aspect-oriented methods), phát triển hướng dẫn dất mô hình (model-driven development), và phát triển hướng dẫn dất kiểm thử (test-driven development)
nhấn mạnh đến các kỹ thuật để đạt được sự hiệu quả hơn
Mỗi phương pháp thi kế phần mềm giới thiệu một heuristies và ký hiệu duy
Trang 32su diễn thiết kế, (2) một ký hiệu để đại diện cho én, (3) heuristics để tỉnh chỉnh và phân lượng, mô hình yêu cầu thành một các thành phần chức năng và giao vùng, và (4) hướng dẫn đánh giá chí
Không nên phụ thuộc vào phương pháp thiết kế được sử dụng mà nên áp dụng một tập các khái niệm cơ bản vào thiết kế dữ liệu, kiến trúc, giao diện và mức thành phần
1.3 KHÁI NIỆM THIẾT KẾ
Một tập hợp các khái niệm thiết kế phần mềm co ban (fundamental software design concepts) di phat trién theo lịch sử công nghệ phần mềm Mặc dù mức
độ quan tâm của từng khái niệm đã thay đổi trong những năm qua, mỗi khái niệm đã đứng vững trước sự thử thách của thời gian
Mỗi khái niệm cùng cấp cho nhà thiết kế phần mềm một nền tảng mà từ đó
phương pháp thiết kế phức tạp hơn có thể được áp dụng Mỗi khái niệm giúp di: (1) những tiêu chí nào có thể được sử dụng đẻ phân vùng phần mềm thành những thành phần riêng lẻ, (2) cách thức mà chức năng hoặc cấu trúc dữ liệu chỉ tiết được tách ra từ một biểu diễn khái niệm của phần
mềm), (3) các tiêu chí thống nhất nao ịnh chất lượng kỹ thuật của thiết
kế phần mềm?
1.3.1 Trừu tượng hóa
Khi một giải pháp mô đun hóa cho bất cứ vấn đề nào được xem xét, nhiều
mức độ trừu tượng hóa (abstraction) có thể được đặt ra Ở mức cao nhất của sự
trừu tượng hóa, một giải pháp được trình bay rộng và sử dụng ngôn ngữ của môi trường vấn đề Ở cắp trừu tượng hóa thập hơn, một mô tả chỉ tiết hơn
các giải pháp được cung cáp Thuật ngữ hướng vấn đề (problem-oriented)
hợp với các thuật ngữ hướng cài đặt (implementation-oriented) trong nỗ lực
nêu ra một giải pháp Cuối cùng, ở mức thấp nhất của sự trừu tượng hóa, giải
pháp được nêu ra theo cách thức có thể được thực hiện trực tiếp
Khi các mức độ khác nhau của trừu tượng hóa được phát triển, hai dang trừu tượng cần thực hiện là trừu tượng hóa thủ tue (procedural abstraction) và trừu tượng hóa dữ liệu (data abstraction) 7rừu rượng hóa thủ rục đề cập đến chuỗi các chỉ dẫn có một chức năng cụ thể và có giới hạn Tên của một trừu tượng hóa thủ tục ngụ ý các chức năng này nhưng chỉ tiết cụ thể thì chưa được thẻ hiện rõ Một ví dụ về trừu tượng hóa thủ tục là một lời yêu cầu “mở cửa” *Mớ” hàm ý một chuỗi dài các bước thủ tục (ví dụ như đi bộ đến cửa, tiếp cận và năm bắt núm cửa, núm cửa bật ra và kéo cánh cửa, bước ra khỏi cánh cửa đang di chuyển, v.v.)
Trang 33
Một trừu tượng hóa dữ liệu là một tập dữ liệu được đặt tên n ng mô tả một đối tượng dữ liệu Trong ngữ cảnh của trừu tượng hóa thủ tục “mở”, ta có thể định nghĩa một trừu tượng hóa dữ liệu được gọi là "cửa” Giống ¡ như bẾt cử đối tượng dữ liệu nào, trừu tượng hóa dữ liệu cho “cửa” sẽ bao gồm một tập hợp các thuộc tính mô tả “cửa” (ví dụ như loại cửa, hướng quay, cơ chế mở, trọng lượng, kích thước) Sau đó việc trừu tượng hóa thủ tục “mo” sẽ sử dụng các thông tin chứa trong các thuộc tính của trừu tượng hóa dữ liệu “cửa”
1.3.2 Kiến trúc phần mềm
Kiến trúc phần mềm (software architecture) ám chỉ đến “cấu trúc tổng thể của
phan mém va cách thức mà cấu trúc cung cấp tính toàn vẹn khái niệm cho một hệ thống” Trong dạng thức đơn giản nhất, kiến trúc là cấu trúc hoặc tổ chức của các thành phần chương trình (mô đun), cách thức mà các thành phần tương tác với nhau và cấu trúc dữ liệu được sử dụng bởi các thành phần này Theo nghĩa rộng hơn, các thành phần có thẻ được tông quát hóa đê đại diện cho phân tử hệ thống lớn hơn và sự tương tác giữa các phần tử lớn hon nay
Một mục tiêu của thiết kế phần mẻm là lầy được “bản vẽ kiến trúc” của hệ thống Bản về này phục vụ như là một khuôn mẫu mã từ đó các hoạt động thiết kế chỉ tết hơn được tiến hành Một tập hợp các mẫu trúc (architectural patterns) cho phép kỹ sứ phần mềm giải quyết các vấn đề thiết kế phô biển
Tập hợp các tính chất được quy định như là một phần của một thiết kế kiến trúc: tính chất cấu trúc (sructural properties) tính chất chức năng ngoài (extra-functional properties), va họ các hệ thống liên quan (families of related systems)
Khia cạnh đính chất cấu trúc xác định các thành phần của một hệ thống (ví dụ
như các mô đun, các đối tượng, các bộ lọc) và cách thức mà những thành phần
này được đóng gói và tương tác với nhau Ví dụ như các đối tượng được đóng
gói để bao cả dữ liệu và xử lý mà nó thao tác trên dữ liệu và tương tác thông qua lời gọi phương thức
Việc mô tả thiết kế kiến trúc nên đưa ra cách giải quyết đề thiết kế kiến trúc đạt được các yêu cầu về hiệu suất, khả năng, độ tin cậy, bảo mật, tính thích
ứng và các đặc điểm hệ thống khác - Tinh chat chite năng ngoài
Thiết kế kiến trúc sẽ dựa trên các mẫu lặp lại (repeatable patterns) thong gặp trong thiết kế của họ các hệ thống tương ae Về bản chất, việc thiết kế nên có khả năng tái sử dụng các khối kiến trúc được xây dựng
Trang 34
biểu diễn kiến trúc như là một tập có tổ chức các thành phần chương trình Ä⁄ô
hình khung làm việc (ffamework models) tăng mức độ thiết kế trừu tượng tạ cách cố gắng xác định khuôn khổ thiết kế kiến trúc lặp lại được gặp trong ic img dung tuong ty Mé hinh déng (dynamic models) giải quyết các khía
cạnh hành vi của kiến trúc chương trình, chỉ ra cách cấu trúc hoặc cấu hình hệ thống có thể thay đổi như là một chức năng của sự kiện bên ngoài Mỏ hình quá trình (proces models) tập trung vào các thiết kế của quá trình nghiệp vụ
hoặc kỹ thuật mà hệ thống phải đáp ứng Cuối cùng, mó hình chức năng
(functional models) c6 thé duge sit dung dé dai diện cho các hệ thống phân cấp chức năng của một hệ thông
Một số ngôn ngữ mô tá kiến trúc khác nhau (ADLs - architeetural description
languages) đã được phát trin để biều diễn cho các mô hình này Mặc dù nhiều ADLs khác nhau đã được đề xuất, phần lớn chúng cung cấp cơ chế cho việc mô tả các thành phần hệ thống và cách thức mà các thành phần được kết nỗi với nhau 1.3.3 Các mẫu thiết kế Một mẫu thiét ké (design pattern) mô tả một cấu trúc thiết kế có thé gi
quyết một vấn đề thiết kế đặc biệt trong một bối cảnh cụ thể và trong cảnh "sức mạnh" có thể có ảnh hưởng đến cách thức mà mô hình được áp dụng và sử dụng
Mục đích của mỗi mẫu thiết kế là cung cấp một mô tả cho phép nhà thiết kế có
thể xác định (1) khi nào mô hình được áp dụng cho công việc hiện tai, (2) khi nào mô hình có thê được tái sir dung (vi thé sẽ tiết kiệm thời gian thiết kế), và (3 ) khi nào mô hình có thể phục vụ như một hướng dẫn để phát triển một cách
tương tự, nhưng mẫu chức năng hoặc cấu trúc khác nhau 1.3.4 Sự phân tách mối quan tâm
ìy phân tách mi quan tâm (separation of concerns), là một khái niệm thiết kế, đề nghị rằng bất cứ vấn đề phức tạp nào cũng có thẻ dễ đàng được xử lý nếu như nó được chia thành nhiều phần mà mỗi phần có thể được giải quyết hoặc tối ưu hóa một cách độc lập Một mối quan zâm là một tính năng hoặc
hành vi được quy định như một phần của mô hình yêu cầu cho phần mềm
Bảng cách tách thành các mối quan tâm nhỏ hơn và đễ quản lý hơn, một vấn đề do đó sẽ mắt ít công sức và thời gian dé giải quyết
1.3.5 Mô đun hóa
Mô đưn hóa (modularity) là biểu hiện phổ biến nhất của sự phân tách các
Trang 35ệ 3 lảm có
không dễ dàng trong việc nắm bất một phần mềm nguyên khối (ví dụ: một chương trình lớn gồm một mô đun duy nhất) Số lượng các đường dẫn khiễn, khoảng thôi gian tham khảo, số lượng các biển, và phúc tạp ông
i mô đun với hy vọng làm cho sự hiệu
biết dé ding hơn và, như một hệ quả, chi phi can thiết đề xây dựng phản mềm sẽ giảm Tổng chỉ phí phần mém 1 #Chỉ phí tích hợp Ving chỉ phí thấp nhất Chỉ phí nỗ lực | | Chỉ phíMô dun
Số lượng mô đun
Hình 1⁄4 Mô đun hóa và chỉ phí phần mềm
1.3.6 Sự che dấu thông tin
Các khái niệm về mô đun dẫn đến một câu hỏi cơ bản là "Cách thức để phân rã một giải pháp pI tần mềm đếc có được tập các mô đun Nguyên tắc
i rằng các mô đun được
nh được che dấu khỏi định khác", Nói cách khác, mô đun cân được xác định và cho thông tin lữ liệu) được chứa trong mô đun là không thể tiếp cận đến các mô đun khác mà không có nhu cầu thông tin 46 ng quyết
Việc che đấu thông tin ngụ ý rằng sự mô đun hóa hiệu quả là có thể đạt được
bằng cách xác định một tập các mô đun độc lập mà chúng giao tiếp với nhau chỉ thông qua các thông tỉn cần thiết để đạt được chức năng phần mềm Trừu tượng hóa giúp định nghĩa các thực thé thủ tục (hoặc thông tr) tạo
mềm Che dấu thông tin định nghĩa và thực thỉ các ràng buộc truy cập đối với chỉ tiết thủ tục trong một mô đun và bắt cứ cấu trúc dữ liệu cục bộ nào được sử dụng bởi mô dun
Trang 36Sử dụng che dấu thông tin - như là một tiêu chuẩn thiết kế cho các hệ thống
mô đun - cung cấp những lợi ích lớn nhất khi sự sửa đổi được yêu cầu trong quá trình kiểm thử và sau đó trong quá trình bảo trì phần mềm Vì hầu hết các
chỉ tiết về dữ liệu và thủ tục được ân khỏi các bộ phận khác của phần mẻm, lỗi đo sơ xuất trong quá trình thực hiện sửa đổi ít có khả năng lan truyền đến các
vị trí khác trong phần mềm
1.3.7 Sự độc lập chức năng
Khái niệm độc lập chức năng (functional independence) 1a két quả tự nhiên trực tiếp của sự phân tách các mối quan tâm, mô đun hóa, các khái niệm trừu tượng và các che dau thông tin
Độc lập chức năng được thực hiện bằng cách phát tin các mô đun với chúc
năng “rõ ràng” (single-minded function) và một "sự lo ngại" "về tương tác quá
nhiều với các module khác, Nói cách khác, nên thiết kế để mỗi mô đun giải quyết một tập cụ thể các yêu cầu và có một giao diện đơn giản khi được xem
từ những bộ phận khác của cấu trúc chương trình Đó là lý do để thấy độc lập chức năng là rất quan trọng
Phần mềm với tính mô đun hóa hiệu quả nghĩa là với các mô đun độc lập, dễ
phát triển hơn vì chức năng có thể được ngăn lại (compartmentalized) và giao điện được đơn giản hóa Các mô đun độc lập đễ bảo trì (và kiểm thir) hon vì hiệu ứng phụ gây ra do thiết kế hoặc sửa đổi mã lệnh bị hạn chế, sự truyền lỗi bị thu giảm, và sự tái sử dụng mô đun là hoàn toàn có thể Tóm lại, độc lập chức năng là chia khóa cho thiết kế tốt, và thiết kế là chia khóa cho chất lượng phần mềm
Sự độc lập được đánh giá bằng cách sử dụng hai tiêu chí định tính: sự gắn (cohesion) và sự nói kết (coupling) Sự găn kết là một chỉ dẫn của sức mạnh chức năng tương đối của một mô đun Sự nối kết là một chỉ dẫn của sự phụ thuộc lẫn nhau tương đối giữa các mô dun
Sự gắn kết là phần mở rộng tự nhiên của khái niệm che dấu thông tỉn môi đun gắn kết thực hiện một nhiệm vụ duy nhất, đòi hỏi ít tương tác với các
thành phần khác trong những phần khác của chương trình Nói một cách đơn giản, một mô đun gắn kết (lý tưởng) chỉ nên làm một công việc Mặc dù ta nên luôn hướng đến sự gắn kết cao, nhưng khuyến khích và cân thiết có một thành phần phần mềm thực hiện nhiều chức năng Tuy nhiên một mô dun thực hiện
nhiều chức năng không liên quan đến nhau có thể tránh được nếu đó là một thiết kế tốt
Sự nối kết - một chỉ dẫn của kết nói giữa các mô đun trong một cầu trúc phần
Trang 37đi qua giao diện Trong thiết kế phần mềm, ta nên cố gắng sao cho các nói kết là ít nhất có thê Sự nồi kết đơn giản giữa các mô đun sẽ cho kết quả là
phần mềm để hiểu hon, it bi higu ting gon song (ripple effect) - higu img gay ra khi lỗi xáy ra tại một vị tri va sau đó lan truyền trong toàn bộ hệ thống
1.3.8 Sự tỉnh chỉnh
Sự tỉnh chỉnh từng bước (stepwise refñnement) là một chiến lược thiết kế từ trên xuống được đẻ xuất đầu tiên bởi Niklaus Wirth Một chương trình được phát triển bởi sự tỉnh chỉnh các mức độ chỉ tiết thủ tục một cách liên tục Một
hệ thống phân cấp được phát triển bằng cách phân rã một phát biểu vĩ mô về
chức năng (một trừu tượng hóa vẻ thủ tục) thành từng bước cho đến khi đạt
được các phát biểu bằng ngôn ngữ lập trình
Sự tỉnh chỉnh thực sự là một quá trình xây dựng Nhà thiết kế bắt đầu với một phát biểu chức năng (statement of function) (hoặc mô tả các thông tin) được định nghĩa ở một mức độ trừu tượng cao Nghĩa là, phát biểu mô tả chức năng hoặc thông tin về khái niệm nhưng không cung cấp thông tin về hoạt động nội bộ của chức năng hoặc cầu trúc nội bộ của thông tin Sau đó, nhà thiết kế xây
dựng trên các phát biểu ban đầu, cung cấp ngày càng nhiều chỉ tiết hơn
khi tỉnh chỉnh liên tiếp (xây dựng) xảy ra
Trừu tượng hóa và tỉnh chỉnh là những Khái niệm bổ trợ cho nhau (complementary coneepts) Trừu tượng hóa cho phép chỉ định thủ tục và dự
cục bộ nhưng ngăn chặn nhụ cầu tử "phía bên ngoải" đề có thông tin về
các chỉ: tiết mức thấp Sự tỉnh chinh giúp tiết lộ chỉ tiết mức thấp khi thiết kế
tiến triển Cả hai khái niệm cho phép nhà thiết kế tạo ra một mơ hình thiết kế
hồn chỉnh khi tỉ kế tiến hóa
1.3.9 Các khía cạnh
Khi phân tích yêu cầu, một tập các mồi quan tâm sẽ được mở ra Những mồi
quan tâm gồm các yêu cầu, trường hợp sử dụng, tính năng, cấu trúc dữ liệu, các vấn đề về chất lượng của dịch vụ, các biến thể, ranh giới sở hữu trí hợp tác, các mẫu, và các hợp đồng Lý tưởng nhất, một mô hình yêu cầu có th được tổ chức theo cách cho phép cô lập từng mối quan tâm (yêu cẳu) để nó có
thể được xem xét một cách độc lập Tuy nhiên trong thực tế, một số mối quan tâm lan ra toàn bộ hệ thống và không thẻ đễ dàng ngăn lại được
Khi thiết kế, các yêu cầu được tỉnh chinh thành sự biểu diễn thiết kế mô đun Điều quan trọng là xác định các Khia canh (aspeets) để chúng có thể được phục vụ đúng cách khi xảy ra tỉnh chỉnh và mô đun hóa Trong bối cảnh lý tưởng, một khía cạnh quan trong được thực hiện như một mô đun ring bi
Trang 38
3.10 Tái cấu trúc
Một hoạt động thiết kế quan trọng được đề nghị trong nhiều phương pháp
agile la đái cầm trúc (refactoring) Đây là một kỹ thuật sắp xếp lại nhằm đơn giản hóa việc thiết kế (hoặc mã lệnh) của một thành phần mà không thay đổi
chức năng hoặc hành vi của nó Tái cấu trúc có thể được định nghĩa là quá
trình thay đổi một hệ thống phần mềm theo cách không làm thay đổi hành vi bên ngoài của mã lệnh đồng thời cải thiện cấu trúc bên trong của nó
Khi phần mềm được tái cấu trúc, thiết kế hiện tại sẽ được kiểm tra xem có những phần tử thiết kế không được sử dụng/dư thừa, hay các giải thuật không
in thiét hoặc kém hiệu quả, hay các cầu trúc dữ liệu không phù hợp hoặc có ém, hay bắt cứ sai sót thiết kế nào; sau đó chỉnh sửa chúng để tao ra
một thiết kế tốt hơn
1.3.11 Các khái niệm thiết kế hướng đối tượng
Dạng thức hướng đối tượng (object-oriented paradigm - OO) duge sit dụng rộng rãi trong công nghệ phần mềm hiện đại
1.3.12 Các lớp thiết kế
Mô hình yêu cầu định nghĩa một tập các lớp phân tích, mỗi một lớp mô tả một số yêu tổ của lĩnh vực vấn đẻ, tập trung vào các khía cạnh của vấn đề mà người sử dụng có thể nhìn thấy Mức độ trừu tượng của một lớp phân tích là tương đối cao
Khi mô hình thiết kế phát triển/tiền hóa, một tập các lớp thiết kế tỉnh chỉnh các
lớp phân tích i ách cung cấp chỉ tiết thiết kế nhằm cho phép các lớp được triển khai, và cài đặt một cơ sở hạ tầng phần mềm hỗ trợ các giải pháp nghiệp vụ Năm loại khác nhau của các lớp thiết kế, mỗi một
n cho một phân tầng (layer) khác nhau của thiết kế kiến trúc: lớp
giao dign ngudi sir dyng (user interface classes), lớp lĩnh vực nghiệp vụ (business domain classes), 6p tiến trình (process classes), lép bén ving (persistent classes), lép hé thong
Các lớp giao diện người sử dụng xác định tắt ca các trừu tượng hóa cần thiết cho tương tác người máy (human-computer interaction, HCD) Các lớp linh: vực
nghiệp vụ - thường là sự tỉnh chỉnh các lớp thiết kế đã được xác định trước đó -
nhận dạng các thuộc tính và phương thức (dịch vụ) cần cho việc thực thi một phan tử nào đó của lĩnh vực nghiệp vụ Các lớp tién trinh cài đặt các trừu tượng hóa nghiệp vụ cấp thấp cản có đề quản lý đầy đủ các lớp lĩnh vực nghiệp Các lớp bên vững biều diễn cho lưu trữ dữ liệu (ví dụ, một cơ sở dữ liệu) sẽ lệc thực thi của phần mềm Các lớp hệ thống cài đặt phan m quản lý và kiềm soát các chức năng cho phép hệ thống để hoạt động và giao tiếp
trong môi trường máy tính của mình và với thế giới bên ngoài
Trang 39
Bắn đặc điễm của một thiết kế lớp tốt Hoàn chỉnh và đây đủ (complete
gdin két cao (high cohesion), vi
của một thiết kế lớp tốt
id sufficient), nguyên tiy (primitiveness), ¡ kết thấp (low coupling) là bến đặc điểm
Với đặc điêm thứ nhất, một lớp thiết kế phải được đóng gói đầy đủ tắt cả các
thuộc tính và phương thức hợp lý và được mong đợi
Với đặc điểm thứ hai, các phương thức kết hợp với một lớp thiết kế nên tập
trung vào việc hoàn thành dịch vụ cho lớp Một khi địch vụ đã được cài đặt bằng một phương thức, lớp không nên cung cấp những cách khác để thực hiện
điều tương tự
Với đặc điểm thứ ba, một lớp thiết kế gắn kết cao có một tập nhỏ, tập trung sâu về trách nhiệm và áp dụng các thuộc tính và phương thức để thực hiện những trách nhiệm
Với đặc điểm cuối cùng, trong một mô hình thiết kế, việc thiết kế các lớp cộng
tác với nhau là cần thiết Tuy nhiên, sự hợp tác phải được giữ ở mức tối thiêu chấp nhận được Nếu một mô hình thiết kế được đánh giả có nói kết cao (tắt cả các lớp thiết kế hợp tác với tất cả các lớp thiết kế khác), hệ thống này là khó thực hiện, khó kiêm tra, và khó để bảo trì theo thời gian Nói chung, các lớp
thiết kế trong một hệ thống phụ chỉ nên biết hạn chế vẻ các lớp khác (luật của
Trang 401.4 MO HINH THIET KE
Mô hình thiết kế (design model) có thể được xem theo hai chiéu (dimensions)
khác nhau như minh họa trong Hình 1.6 Chiều của tiến trình chỉ ra sự phát triển của mô hình thiết kế trong đó nhiệm vụ thiết kế được thực hiện như một
trong đó mỗi phần tử của mô hình phân tích (mô Lal yi Ga) đợc di: đổi thành một thiết kế tương đương va sau đó được tỉnh chỉnh lặp lại Xem
Hình L6, đường nét đứt chỉ ra ranh hi giữa mô hình phân tích và mô hình
cầu và mô hình thiết kế là có the ‘Tong 1 những trường hợp khác, các mô hình
yêu cầu từ từ hỗn hợp với mô hình thiết kế và sự phân biệt rõ ràng là ít minh bạch hơn nee š |sctevene E |meseu E Ee=ee 5 uy rerien ỗ Toy biệt bê kế lớp He tng con Mo his cfg tc Mô hình tiết kế | Tab hi: The ia tie ip Heth con Thi | Mota ig te kín thc Taye Tem pods EU thi pin en Ka Thun Chiều tiền trình
Hình 1.6 Các chiều của mô hình thiết kế
Các phần tử của mô hình thiết kế sử dụng nhiều sơ đồ UML cùng được sử dụng
trong mô hình yêu cầu Sự khác biệt là những sơ đồ này được tỉnh chỉnh và xâ)
dựng như một phần của thiết kế; chỉ tiết thực hiện được cung cấp cụ thẻ hơn, và
kiến trúc cấu trúc và phong cách, thành phần trong kiến trúc và các giao điện
giữa các thành phần và với thể giới bên ngoài tắt cả đều được nhắn mạnh
Cũng cần lưu ý là các phần tử của mô hình được chỉ ra dọc theo trục hồnh khơng phải ln luôn phát triển một cách tuần tự Trong hầu hết các trường
hợp, thiết kế kiến trúc sơ bộ được thực hiện đầu tiên, sau đó thiết kế giao diện
và thiết kế mức thành phần thường xảy ra song song Mô hình triển khai