Translated from English to Vietnamese - www.onlinedoctranslator.

com

25/2/21

1 2

Nội dung
MẪU THIẾT KẾ S
1.Thiết kế mô-đun
01. GIỚI THIỆU CÁC NGUYÊN
2.Mô-đun tốt
TẮC VÀ MẪU THIẾT KẾ
3.Thiết kế tốt: Làm thế nào?
Nguyễn Thị Thu Trang
trangntt@soict.hust.edu.vn

1 2

3 4

mô-đun Tại sao mô đun?

• mô-đun • Dễ hiểu và giải thích hơn
• Một thuật ngữ tương đối chung cho một chức năng, một lớp hoặc • Tài liệu dễ dàng hơn
một loại hoặc bất kỳ loại đơn vị thiết kế nào trong phần mềm
• Lập trình một mô-đun riêng lẻ dễ dàng
• Thiết kế mô-đun (Modularity) hơn
• Những mô-đun nào được xác định
• Kiểm tra và gỡ lỗi dễ dàng hơn
• thông số kỹ thuật của họ là gì
• Theo dõi và sửa lỗi dễ dàng hơn và nhanh hơn
• Chúng liên quan với nhau như thế nào
• tái sử dụng
• Nhưng không thường xuyên về việc thực
hiện các mô-đun

3 4

1
 25/2/21

5 6

Mà bạn thích làm gì? Nội dung

những thách thức của mỗi là gì?
• Tìm các bộ phận cần thay đổi
Biết những gì các bộ phận làm!
1.Thiết kế mô-đun
• Biết điều gì sẽ xảy ra khi bạn thay đổi chúng
• Biết cách ghép chúng lại với nhau Làm thế nào họ kết nối? 2.Mô-đun tốt
Thay tã?
3.Thiết kế tốt: Làm thế nào?

Thay đổi một bộ lọc nhiên liệu?

5 6

7 số 8

Mô-đun tốt và xấu Thiết kế xấu và tốt

• Bản thân các mô-đun không “tốt”
• Phải thiết kế chúng để có những đặc tính tốt
i) CPU sử dụng 3 chíp (module) ii) CPU sử dụng 3 chip (module)

chíp 1 chip 2

chíp 1 chip 2

cổng AND cổng HOẶC

đăng ký
AALLUU

chíp 3

SHIFhiTftErR
e KHÔNG cổng
chíp 3

vấn đề ở đây là gì?

7 số 8

2
 25/2/21

9 10

Lý tưởng của phần mềm mô-đun Thiết kế tốt

• có thể phân hủy–có thể được chia thành • Dễ dàng phát triển, thử nghiệm,
các mô-đun để giảm độ phức tạp và
cho phép làm việc theo nhóm • Dễ đọc, dễ hiểu
• tổng hợp– “Đã chia để trị, phải hợp
• Dễ dàng giao tiếp
lại để trị [M. Jackson].”
• Dễ dàng mở rộng (thêm tính năng mới)
• Có thể hiểu được–một mô-đun có thể được
kiểm tra, suy luận, phát triển, v.v. một cách
• Dễ dàng bảo trì
riêng biệt
• Liên tục–một thay đổi nhỏ trong các
yêu cầu sẽ ảnh hưởng đến một số lượng
nhỏ các mô-đun
• Sự cách ly–một lỗi trong một mô-đun nên được
chứa càng nhiều càng tốt

9 10

11 12

Nội dung Cấp độ thiết kế

1.Thiết kế mô-đun Kiến trúc/Khung (Hệ

thống tài chính, J2EE,…)
2.Mô-đun tốt
Mẫu OOD
3.Thiết kế tốt: Làm thế nào?
Nguyên tắc OOD

Cấu trúc dữ liệu cụ thể Phương

pháp tiếp cận thuật toán

Khái niệm chung + OO

11 12

3
 25/2/21

@Nguyễn Thị Thu Trang, trangntt@soict.hust.edu.vn 13 14

Khái niệm SE cơ bản Khái niệm OO Cấp độ thiết kế (khóa học này)

• tính mô đun • Lớp/Giao diện Kiến trúc/Khung (Hệ

• Sự gắn kết • Di sản thống tài chính, J2EE,…)

• khớp nối • Sự kết hợp Mẫu thiết kế GoF Mẫu OOD

• trừu tượng • đa hình Nguyên tắc RẮN Nguyên tắc OOD

• Ẩn thông tin • đóng gói
Cấu trúc dữ liệu cụ thể Phương

pháp tiếp cận thuật toán

Sự gắn kết
khái niệm thiết kế khớp nối
Khái niệm chung + OO

13 14

•15 16

Tại sao những chủ đề này? 3.1. khái niệm thiết kế

• Khái niệm chung & OO • Sự gắn kết

• Mức độ mà các phần tử của một mô-đun
• Kiến thức cơ bản về thiết kế phần thuộc về nhau
mềm và SE • Tại sao các mô-đun con được đặt trong cùng một
• Đánh giá chất lượng thiết kế mô-đun? Các trách nhiệm của một mô-đun có liên
quan chặt chẽ hoặc tập trung đến mức nào?
• Nguyên tắc thiết kế • khớp nối
• Chẩn đoán các vấn đề với thiết kế • Mức độ mà mỗi mô-đun chương trình phụ
• mẫu thiết kế thuộc vào từng mô-đun khác
• Làm thế nào các yếu tố là độc lập?
• Giải quyết các vấn đề

15 16

4
 25/2/21

17 18

Sự gắn kết trong các mô-đun và khớp nối

giữa các mô-đun
Thiết kế tốt
• Dễ dàng phát triển, thử nghiệm,
• Dễ đọc, dễ hiểu
• Dễ dàng giao tiếp
• Dễ dàng mở rộng (thêm tính năng mới)
• Dễ dàng bảo trì

è“Khớp nối lỏng lẻo và độ gắn kết cao”

17 18

19 20

Tại sao khớp nối lỏng lẻo và sự gắn kết cao?
• Trong một mô-đun
• Số lượng lớn trách nhiệm: Khó hiểu
• Số nhỏ, liên quan chặt chẽ: Dễ hiểu hơn
nhiều
• Kết nối giữa các module
• Một thay đổi trong một module sẽ kéo theo
nhiều module khác: Khó bảo trì/sửa lỗi
• Một thay đổi trong một mô-đun hầu như không thay đổi những mô-
đun khác: Bảo trì / sửa lỗi dễ dàng hơn nhiều
3.2. Nguyên tắc thiết kế RẮN
• Bởi Robert C. Martin trong bài báo năm 2000 của mình,
Thiết kế Nguyên tắc và mẫu thiết kế .
• Các thực hành giúp phát triển phần mềm
OO với các cân nhắc để duy trì và mở rộng
khi dự án phát triển
• Quản lý phụ thuộc làm cho khả năng bảo trì dễ dàng
hơn
• Tạo phần mềm dễ bảo trì, dễ hiểu và linh hoạt
hơn
• Các nguyên tắc và kỹ thuật khác nhau có sẵn
để chẩn đoán các vấn đề với thiết kế

19 20

5
 25/2/21

21 22

Nguyên tắc RẮN 3.3. mẫu thiết kế

• SRP: Nguyên tắc chịu trách nhiệm duy nhất • Một giải pháp tiêu chuẩn cho một chương trình phổ biến
vấn đề tôi
• ÔCP: Nguyên tắc Mở Đóng • một cấu trúc thiết kế hoặc thực hiện đạt được một
• LSP: Nguyên tắc thay thế Liskov mục đích cụ thể
• một thành ngữ lập trình cấp cao
• TÔISP: Nguyên tắc phân tách giao diện • Một kỹ thuật để làm cho mã linh hoạt hơn
• Đ.IP: Nguyên tắc đảo ngược phụ thuộc • giảm khớp nối giữa các thành phần chương trình
• Viết tắt để mô tả thiết kế chương trình
• mô tả các kết nối giữa các thành phần
chương trình (cấu trúc tĩnh)
• hình dạng của ảnh chụp nhanh heap hoặc mô hình đối tượng (hành
vi động)

21 22

23

Các mẫu GoF: ba loại

• Mô hình sáng tạo–những cái này trừu tượng quá trình
khởi tạo đối tượng
• Factory Method, Abstract Factory, Singleton, Builder,
Prototype
• mô hình cấu trúc–những trừu tượng này làm thế nào các đối tượng/lớp có
thể được kết hợp
• Bộ điều hợp, Cầu nối, Hợp chất, Trang trí, Mặt tiền,
Flyweight, Proxy
• Mẫu hành vi–những giao tiếp trừu tượng giữa các
đối tượng
• Chỉ huy, Thông dịch viên, Trình lặp, Người hòa giải,
Người quan sát, Trạng thái, Chiến lược, Chuỗi trách
nhiệm, Khách truy cập, Phương thức mẫu

23