Công nghệ phần mềm - Thiết kế

1Thiết kế (6)
Nguyễn Thanh Bình
Khoa Công nghệ Thông tin
Trường ðại học Bách khoa
ðại học ðà Nẵng
2
Thiết kế ?

 phân tích bài toán/vấn ñề
 xuất phát từ yêu cầu

 mô tả một hoặc nhiều giải pháp
 ñánh giá các giải pháp, chọn giải pháp tốt nhất

 ở một mức trừu tượng nhất ñịnh
 sử dụng các mô hình

 3 tính chất
 trả lời câu hỏi “như thế nào”
 mô tả chủ yếu là cấu trúc
 bỏ qua các chi tiết cài ñặt
• giải pháp trừu tượng ≠ giải pháp cụ thể
23
Các giai ñoạn thiết kế

 Hoạt ñộng thiết kế xuất hiện trong các mô 
hình phát triển khác nhau

 Hai giai ñoạn thiết kế chính
 Thiết kế kiến trúc
• phân tích giải pháp thành các thành phần
• ñịnh nghĩa giao diện giữa các thành phần
• ñịnh nghĩa phần vấn ñề ñược giải quyết bởi mỗi 
thành phần
• có thể ñược thực hiện bởi nhiều mức trừu tượng
 Thiết kế chi tiết
• thiết kế thuật toán, cấu trúc dữ liệu...
4
Các giai ñoạn thiết kế
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products
35
Các giai ñoạn thiết kế

 Architectural design
 xác ñịnh các hệ thống con

 Abstract specification
 ñặc tả các hệ thống con

 Interface design
 mô tả giao diện các hệ thống con

 Component design
 phân tích hệ thống con thành các thành phần

 Data structure design
 các cấu trúc dữ liệu lưu trữ dữ liệu của bài toán

 Algorithm design
 thiết kế thuật toán cho các hàm/mô-ñun
6
Tại sao phải thiết kế ?

 có một kiến trúc tốt
 làm chủ ñược cấu trúc hệ thống
 “chia ñể trị”

 ñạt ñược các tiêu chuẩn chất lượng
 tái sử dụng / dễ keỉem thử / dễ bảo trì...

 thiết kế hướng ñến sự thay ñổi (design for 
change)
47
Thiết kế và sự thay ñổi

 Thay ñổi = tích chất ñặc trưng của phần 
mềm

 Dự báo thay ñổi là cần thiết
 giảm chi phí bảo trì

 Dự báo thay ñổi là khó khăn
 sự thay ñổi thường không ñược xác ñịnh 
trước
 nhiều yếu tố thay ñổi cùng lúc
 thời ñiểm thay ñổi là khó có thể biết trước
8
Thiết kế và sự thay ñổi

 Các yếu tố có thế thay ñổi
 thuật toán
 cấu trúc dữ liệu
 biểu diễn dữ liệu bên ngoài
 thiết bị ngoại vi
 môi trường xã hội
 yêu cầu khách hàng
59
Thiết kế hướng mô-ñun

 Phần mềm là tập hợp gồm các mô-ñun 
tương tác với nhau

 Mô-ñun hóa ñóng vai trò quan trọng ñể có 
ñược phần mềm chất lượng với chi phí thấp

 Mục ñích thiết kế hệ thống
 xác ñịnh các mô-ñun có thể
 xác ñịnh tương tác giữa các mô-ñun
10
Các tiêu chuẩn của một 
phương pháp thiết kế

 Các tiêu chuẩn ñể ñánh giá một phương 
pháp thiết kế hướng mô-ñun
 tính phân rã (modular decomposability)
 tính tổng hợp (modular composability)
 tính dễ hiểu (modular understandability)
 tính liên tục (modular continuity)
 tính bảo vệ (modular protection)
611
Các tiêu chuẩn của một 
phương pháp thiết kế

 tính phân rã (modular decomposability)
 phân rã vấn ñề thành các vấn ñề con nhỏ 
hơn
 có thể giải quyết các vấn ñề con một cách 
ñộc lập
 các phương pháp thiết kế từ trên xuống (to-
down design) thỏa mãn tiêu chuẩn này
12
Các tiêu chuẩn của một 
phương pháp thiết kế

 tính tổng hợp (modular composability)
 các mô-ñun dễ dàng ñược kết hợp với nhau 
ñể tạo nên các hệ thống mới
 có mối quan hệ chặt chẽ với tính tái sử dụng
 tính tổng hợp có thể xung ñột với tính phân 
rã
• phân rã thành các mô-ñun chuyên biệt thay vì các 
mô-ñun tổng quát
713
Các tiêu chuẩn của một 
phương pháp thiết kế

 tính dễ hiểu (modular understandability)
 thiết kế các mô-ñun một cách dễ hiểu
 tính chất mỗi mô-ñun
• mỗi mô-ñun có dễ hiểu ?
• các tên sử dụng có ý nghĩa ?
• cso sử dụng thuật toán phức tạp ?
 Ví dụ
 sử dụng “goto”
 chương trình vài nghìn dòng lệnh, nhưng không sử
dụng hàm/thủ tục
14
Các tiêu chuẩn của một 
phương pháp thiết kế

 tính liên tục (modular continuity)
 một sự thay ñổi trong ñặc tả yêu cầu chỉ dẫn 
ñến sự thay ñổi trong một (hoặc một số ít) 
mô-ñun
 Ví dụ
☺không sử dụng số hoặc chuỗi ký tự trong chương 
trình, chỉ ñược sử dụng các hằng ñã ñịnh nghĩa
sử dụng mảng
815
Các tiêu chuẩn của một 
phương pháp thiết kế

 tính bảo vệ (modular protection)
 kiến trúc ñươc thiết kế sao cho nếu một ñiều 
kiện bất thường xảy ra, chỉ một (hoặc một số
ít) mô-ñun bị ảnh hưởng
16
Thiết kế kiến trúc

 Kiến trúc = tập hợp các thành 
phần/mô-ñun và quan hệ giữa chúng
 các thành phần/mô-ñun
• hàm / nhóm các hàm / lớp ...
 quan hệ
• sử dụng / gọi / thừa kế ...
917
Chất lượng của kiến trúc

 mỗi mô-ñun có tính kết cố cao (high 
cohesion)
 một mô-ñun là một ñơn vị lô-gíc
 toàn bộ mô-ñun cùng ñóng góp thực hiện 
một mục tiêu

 liên kết lỏng lẽo (low coupling) giữa các mô-
ñun
 ít ràng buộc, phụ thuộc lẫn nhau

 dễ hiểu

 ñịnh nghĩa rỏ ràng
 các mô-ñun và quan hệ giữa chúng
18
Các loại kiến trúc

 Ba loại mô hình kiến trúc thường ñược sử
dụng
 chia sẽ dữ liệu: mô hình “Repository”
 chia sẽ dịch vụ, servers: mô hình “Client-
Server”
 mô hình lớp (layered model)
10
19
Mô hình “Repository”

 Nguyên tắc
 dữ liệu chia sẽ ñược tập trung trong một 
CSDL
 các hệ thống con ñều truy cập vào CSDL 
chung

 Khi một lượng dữ liệu lớn cần chia sẽ giữa 
các hệ thống con
 mô hình “Repository” thường ñược sử dụng
20
Mô hình “Repository”

 Ví dụ kiến trúc một công cụ CASE
11
21
Mô hình “Repository”

 Ưu diểm
 ñơn giản
 hiệu quả khi chia sẽ lượng dữ liệu lớn
 sự ñộc lập của các hệ thống con

 Hạn chế
 các hệ thống con phải thống nhất trên mô 
hình dữ liệu “repository”
 khó khăn khi phân tán dữ liệu
22
Mô hình “Client-Server”

 Nguyên tắc
 mô hình phân tán: dữ liệu và xử lý ñược 
phân tán trên nhiều thành phần khác nhau

 Hệ thống bao gồm
 các servers cung cấp các dịch vụ
• có thể có nhiều servers
 các clients yêu cầu các dịch vụ
 phương thức trao ñổi
• mạng hay trên một máy tính
12
23
Mô hình “Client-Server”

 Ví dụ
24
Mô hình “Client-Server”

 Ưu ñiểm
 sử dụng hiệu quả mạng
 dễ dàng thêm server mới hoặc nâng cấp server hiện 
tại
 phân tán dữ liệu dễ dàng

 Hạn chế
 mỗi hệ thống con quan lý dữ liệu riêng của nó
• có thể dẫn ñến dư thừa
 không có kiến trúc tập trung ghi nhận các dich vụ
• khó khăn ñể xác ñịnh dữ liệu hay dịch vụ sử dụng
13
25
Mô hình lớp

 Nguyên tắc
 tổ chức hệ thống thành tập hợp các lớp
 mỗi lớp cung cấp tập hợp các dịch vụ

 ñược sử dụng ñể mô tả quan hệ giữa các 
hệ thống con

 khi giao diện của một lớp thay ñổi, chỉ lớp 
kế cận bị ảnh hưởng

 hỗ trợ mô hình phát triển tăng trưởng
26
Mô hình lớp

 Ví dụ: hệ thống quản lý phiên bản