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.

s

Biên soạn: PGS TS HUYNH XUAN HIỆP (Chú biên)

ThS VO HUYNH TRAM ThS PHAN PHƯƠNG LAN ThS HUỲNH QUANG NGHỊ

VA THIET KE PHAN MEM

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

& NHÀ XIẤT RAN AL HOE eGN TH

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

005.3 DDC 23 MEN 205657

GiI08

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ơ đề

giáo trình “Kiến trúc và thiết kế phần mềm” được ra mắt bạn đọc

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 ý để

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

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

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

NHÓM TÁC GIÁ.

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

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

2.1 PHAN TÍCH CÁC YÊU CÂU

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

3.1.3 Mue dich sử dung kiến trúc phần mềm

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Ụ:

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

4.4.2 Các mẫu thiết kế giao diện người sử dụng

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

6.1 THIET KE HUGNG MAU

6.1.1 Cac loại mẫu thiết kế

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)

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

7.3 THÁP THIẾT KE CHO UNG DUNG WEB

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

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

8.5 PHÓI HỢP VẢ TÁI SỬ DỤNG DỊCH VỤ TRONG SOA

§.5.1 Phoi hop dich vu

8.5.2 Tai sir dung dịch vụ

CÂU HOI HƯỚNG DẪN ÔN TẬP

ĐỊNH HƯỚNG THẢO LUẬN

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 Kiến trúc luồng dữ liệu (mẫu pipe and filter)

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

Biểu diễn thiết kế đối tượng nội dung

ir dung vào hoạt động giao diện

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

Hinh 8.9 Web client va dich vụ Web trong một ứng dụng các dich vu WWW Hình 8.10 Ví dụ về một bộ môi giới các dịch vụ Web

DANH MUC BANG

Bang 5.1 Ky phap bang quyét định 133 Bang 6.1 Bảng tổ chức theo mẫu 153 Bảng 7.1 - Tóm tắt phương pháp OOHDM 183

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

WSDL Web Services Description Language

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

Phương pháp hướng khía cạnh

Các khía cạnh

Các kết hợp

Tính nguyên tử Các phần tử hành vi

Mô hình hành vỉ Các lớp ranh gi

Client-server

Cohesion

Collaboration

Combinatorial specification of behavior

Commercial and nonprofit

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

Nguyên tắc tái sir dung chung

'Trừu tượng hóa dữ liệu

Kiến trúc lấy dữ liệu làm trung tâm

'Kiến trúc luồng/đòng dữ liệu Bang quyết định

“Tương tác người máy

Siêu phương tiện Định danh

Thiết kế giao diện Các kiến trúc phân lớp

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

Kiến trúc hướng đối tượng Các đối tượng

Các phương thức/toán tửthao tác Dạng thức

Ngôn ngữ thiết kế chương trình Các hệ thống ngang cấp

Hiệu suất

Các lớp bền vững Nền tảng

Các nguyên tắc

Service Oriented Architecture - SOA

Software domain analysis,

Ther vign tai sử dụng

Higu img gon séng

Sự mạnh mẽ

Các mô hình yêu cầu dựa trên

kịch bản Các kịch bản thứ

Đặc tả tuần tự của hành vỉ Tính đơn giản

Bản đồ trang Web

Kiến trúc hướng dich vu Phân tích lĩnh vực phần mềm Quy trinh/tién trình phần mềm Đảm bảo chất lượng phần mềm

Sơ đồ trạng thái

Tính phi trạng thái Tỉnh chỉnh từng bước Các cụm lắp ráp.

Ways of Navigating - WON

Web Services Description Language =

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ô hình người sử dụng Tiện ích

Sự điều hướng trực quan

Ấn tượng từ bên ngoài

Cách điều hướng

'Ngôn ngữ mô tả các dịch vụ Web

Phân tích luỗng công việc

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

ệ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

1.1 và Hình 1.2 Mô hình yêu câu được thẻ hiện dựa trên kịch bản (scenario- based), dựa trên lớp (class-based), hướng luồng/dòng (flow-oriented) và các phan tir hanh vi (behavioral element) cung cấp các nhiệm vụ thiết kế Ký hiệu

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

Mồ hình phần tích yêu câu Mô bình thiết kế

Hình I.2 Chuyển đổi từ mô hình yêu cầu sang mô hình thiết kế (2)

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 í

Tang khéng phan tach giao

Đơn khỏi _ điện người dùng cho máy khách

Hình 1.3 Chuỗi các quyết định thiết kế

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

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

quyết dữ liệu, chức năng, và các lĩnh vực hanh vi tir quan điểm cài đặt

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ứ 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

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

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

nhất, cũng như các đặc trưng cho chất lượng thiết kế Tuy nhiên, tắt cả những phương pháp này có một số đặc điểm chung: (1) một cơ chế cho việc dịch các

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

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

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

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

Với đặc tả cho trước, thiết kế kiến trúc có thể được biểu diễn bằng cách sử dụng một hoặc nhiều mô hình khác nhau Mỏ hinh cau tic (structural models)

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

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

mối quan tâm Phần mềm được chia ra thành các thành phần riêng biệt có tên

và địa chỉ, đôi khi được gọi là mô đun (modules), được tích hợp để đáp img

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

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

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

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

Độ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

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

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

mềm - phụ thuộc vào độ phức tạp giao diện giữa các mô đun, diém ma tai đó những đầu vào hay tham chiếu nào được tạo ra cho mô đun, những dữ liệu nào

đ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

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ế

hoàn chỉnh khi tỉ kế tiến hóa

trợ cơ chế định nghĩa khía cành - mô đun,

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

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

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

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

Demeter), và chỉ nên gửi thông điệp :(miessages) cho các phương thức trong các lớp lân cận

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

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

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 hoành không phải luôn 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

thường bị trì hoãn cho đến khi thiết kế đã được phát triển đầy đủ