Giáo trình kiến trúc và thiết kế phần mềm

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 2

Bié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 4

LOT 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 6

LOI 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 8

MUC 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 9

2.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 10

32

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 11

thiế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 12

6.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 13

7.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 14

8.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 15

Hì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 16

Hì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 17

Hì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 18

DANH MUC BANG

Trang 19

DANH 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 20

DANH 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 21

Client-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 22

Dependencies 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 23

Implementation 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 24

Problem-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 25

Subordinate 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 26

Chuong 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 29

Trong 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 32

su 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 36

Sử 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 40

1.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