Bài giảng Các mẫu thiết kế hướng đối tượng: Chương 5 - ĐH Bách khoa TP.HCM

Bài giảng Các mẫu thiết kế hướng đối tượng - Chương 5: Các mẫu kiến trúc phần mềm phổ dụng cung cấp cho người học các kiến thức: Đặc tả phần mềm, đặc tả kiến trúc phần mềm, các mẫu kiến trúc phổ dụng. Mời các bạn cùng tham khảo.

Trang 2

 Máy tính số là thiết bị tổng quát hóa, nó có thể giải quyết nhiềuvấn ₫ề mà con người cần giải quyết.

 Tại từng thời ₫iểm, ₫ể nhờ máy tính giải quyết 1 vấn ₫ề nào ₫ó, taphải lập trình cho máy tính hiểu

 Qui trình phát triển phần mềm miêu tả các công việc chức năngcần phải thực hiện cùng cách thức, trình tự thực hiện các côngviệc chức năng này

 Kết quả của qui trình phát triển phần mềm là bản ₫ặc tả ₫ầy ₫ủ vềphần mềm

Trang 3

 Đặc tả ₫ầy ₫ủ về phần mềm là ₫ặc tả phần mềm theo nhiều gócnhìn khác nhau :

 Góc nhìn người dùng : tập các yêu cầu chức năng và phi chứcnăng của phần mềm

 Góc nhìn vĩ mô ₫ể người hiểu : kiến trúc phần mềm và phát sơlược về cách giải quyết từng chức năng

 Góc nhìn chi tiết ₫ể người hiểu : bản thiết kế chi tiết về phầnmềm

 Góc nhìn chi tiết ₫ể máy hiểu : các file mã nguồn và các filekhả thi của chương trình

 …

Trang 4

 Kiến trúc phần mềm cho thấy cấu trúc tổng quát, vĩ mô của phầnmềm.

 Kiến trúc phần mềm bao gồm các phần tử sau :

 các thành phần : ₫ịnh nghĩa ₫ịa ₫iểm tính toán, thí dụ filter,database, object, ADT

 các mối nối (Connector) : làm trung gian cho tương tác giữacác thành phần gọi thủ tục, pipe, phát tán sự kiện

 các thuộc tính : xác ₫ịnh thông tin cho việc phân tích và xâydựng : chữ ký, ₫iều kiện pre/post, ₫ặc tả RT

Trang 6

Chọn cấu trúc nào ₫ể xây dựng phần mềm lớn ?

Cấu trúc ₫ơn thể bên trái chắc chắn không phù hợp Do ₫ó ta sẽ chọn cấu

Trang 7

Chủng loại các phần tử cấu thành phần mềm như thế nào và mối quan hệ

giữa chúng ra sao ₫ể ta có thể dễ dàng quản lý chúng theo thời gian?

Các phần tử cấu thành phần mềm lớn thường có số lượng rất lớn, nhưng ₫ể

dễ xây dựng và quản lý chúng, ta ₫òi hỏi chúng phải thuần nhất cùng một

chủng loại Mô hình hướng ₫ối tượng gọi phần tử này là ₫ối tượng Như vậy

Trang 8

Để dễ dàng quản lý các phần tử, ta phải hạn chế tối ₫a sự tương tác giữa

chúng Tính ₫óng gói của mô hình hướng ₫ối tượng giải quyết vấn ₫ề này

Hạn chế sự tương tác của từng ₫ối tượng là :

 Che dấu tối ₫a các chi tiết hiện thực của mình, chỉ cho các phần tử khác

bên ngoài thấy và dùng 1 ít các dịch vụ của mình.

 Hạn chế tối ₫a sự nhờ vả các phần phần bên ngoài : ta cần làm các thành

Trang 9

Nếu dùng cấu trúc dạng phẳng cho phần mềm lớn thì cũng rất khó quản lý vì

số lượng thành phần quá lớn Thường ta sẽ dùng cấu trúc dạng phân cấp

gồm nhiều mức trừu tượng khác nhau.

2 9

5 6

7 12

Trang 10

2 9

Trang 11

Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1

Trang 12

Layer 6

Layer 4 Layer 3 Layer 2 Layer 1

Trang 13

Mẫu/Kiểu kiến trúc (Architecture Pattern/Style)

 Kiểu kiến trúc ₫ịnh nghĩa 1 họ các kiến trúc phần mềm cụ thể

₫ược giới hạn bởi :

 từ vựng thành phần/mối nối

 các luật topology

 các ràng buộc ngữ nghĩa

Trang 14

Các ₫ặc ngữ kiến trúc phổ biến

 Các hệ thống xử lý dòng dữ liệu : lô tuần tự (Batch sequential),

₫ường ống và lọc (Pipe and filters)

 Các hệ thống gọi-trả về : chương trình chính và thủ tục (mainprogram & subroutines), các cấp có thứ bậc (Hierarchical layers),

hệ thống hướng ₫ối tượng (OO system)

 Các máy ảo : Trình thông dịch (Interpreters), hệ thống dựa vàoluật (Rule-based system)

(Communicating processes), các hệ thống xử lý sự kiện (Eventsystems)

 Các hệ thống tập trung quanh dữ liệu (Repositories) : Database,

Trang 15

Kiến trúc ₫ơn thể (Monolithic)

 Đặc tả : Hệ thống chỉ gồm duy nhất 1 module, module này chứa

mọi thứ của chương trình : danh sách các lệnh thực thi miêu tả giảithuật cần thực hiện + danh sách các biến dữ liệu bị xử lý

 giao tiếp giữa các thành phần là cục bộ và rất hiệu quả

 thích hợp cho những phần mềm nhỏ, ₫ơn giản

 không thích hợp cho những phần mềm lớn và phức tạp

Trang 18

Kiến trúc các thành phần (Components based Architecture)

Trang 19

 Thành phần : là nguyên tử cấu thành phần mềm, nó có 1 số tính

chất sau :

 Reusable : dễ dàng dùng lại cho ứng dụng khác

 Replaceable : dễ dàng ₫ược thay thế bởi thành phần mới

 Not context specific : không có ngữ cảnh

 Extensible : dễ nới rộng

 Encapsulated : ₫óng gói và ẩn chi tiết hiện thực

 Independent : ₫ộc lập cao

Trang 20

 Ưu ₫iểm của kiến trúc các thành phần :

 Ease of deployment : dễ dàng triển khai

 Reduced cost : chi phí thấp

 Ease of development : dễ dàng phát triển

 Reusable : dễ dàng dùng lại

 Mitigation of technical complexity : giảm nhẹ ₫ộ phức tạp kỹthuật

Trang 21

 Tình huống nên dùng : bất kỳ hệ thống phần mềm phức tạp nào.

 Khuyết ₫iểm : là mẫu kiến trúc có ₫ộ tổng quát cao nên khi hiện

thực ta phải tốn nhiều chi phí ₫ể vận dụng nó

Trang 22

Kiến trúc hướng ₫ối tượng (Objects based Architecture)

Trang 23

 Đối tượng : là nguyên tử cấu thành phần mềm, nó có 1 số tính

chất sau :

 Reusable : dễ dàng dùng lại cho ứng dụng khác

 Replaceable : dễ dàng ₫ược thay thế bằng ₫ối tượng mới hơn

 Extensible, Heritable : thừa kế và dễ nới rộng

 Encapsulated : ₫óng gói và ẩn chi tiết hiện thực

 Independent : ₫ộ ₫ộc lập cao

 Persistent : thường trù ₫ể sẵn sàng phục vụ

 Aggregation : bao gộp từ nhiều ₫ối tượng nhỏ

Trang 24

 Các nguyên tắc chính yếu của kiến trúc hướng ₫ối tượng :

 Abstraction : trừu tượng

Trang 25

 Ưu ₫iểm của kiến trúc hướng ₫ối tượng :

Trang 26

 Tình huống nên dùng : bất kỳ hệ thống phần mềm phức tạp nào.

 Khuyết ₫iểm : là mẫu kiến trúc có ₫ộ tổng quát cao nên khi hiện

thực ta phải tốn nhiều chi phí ₫ể vận dụng nó

Trang 27

Kiến trúc dựa trên sự kiện (Event-based Architecture)

 Đặc tả : Hệ thống phần mềm gồm 1 tập các thành phần ₫ộc lập

₫ược ghép nối lỏng lẻo dựa trên việc tạo/xử lý sự kiện

Component 1

Component nComponent 3

Component 2

tạo sự kiện xử lý sự kiện

Trang 28

 Emitter : là phần tử tạo và phát tán 1 hay nhiều sự kiện.

 Handler : là phần tử muốn xử lý sự kiện, nó ₫ăng ký thủ tục xử lý

sự kiện vào danh sách xử lý của sự kiện tương ứng Khi sự kiệnxảy ra, nó ₫ược kích hoạt chạy (bởi module quản lý sự kiện) Lưu

ý thứ tự chạy các thủ tục xử lý sự kiện cho 1 sự kiện xác ₫ịnh làkhông xác ₫ịnh

 Event chanel : là phương tiện truyền dẫn sự kiện từ emitter tới

handler

 Lưu ý là phần tử nào trong hệ thống ₫ều có thể là event emitterlẫn event handler Có thể có các dạng tương tác khác giữa cácphần tử như gọi thủ tục, truy xuất dữ liệu

Trang 29

 Tình huống nên dùng : trong các hệ thống :

 tương tác bẩm sinh như giao diện người dùng, mạng máy tính

 trả kết quả về từ việc thi hành bất ₫ồng bộ (thread)

 gia tăng khả năng việc dùng lại từng thành phần

 cải tiến hệ thống dễ dàng : thay ₫ổi thành phần này bằngthành phần khác

 Khuyết ₫iểm : khó kiểm thử ₫ơn vị từng thành phần, không biết

sự kiện do mình gởi có ₫ược xử lý hay không và ai xử lý

Trang 30

Kiến trúc các process liên lạc nhau (Communication process

Trang 31

Kiến trúc các process liên lạc nhau (Communication process

Architecture)

 Process : là nguyên tử cấu thành phần mềm, nó là 1 phần mềm

chạy ₫ộc lập, mỗi process thực hiện 1 chức năng xác ₫ịnh

 Connector : phương tiện tương tác (truyền thông báo) giữa các

Trang 32

Kiến trúc hướng dịch vụ (Service-Oriented Architecture)

Trang 33

 Service : phần tử cung cấp 1 số chức năng ₫a dụng nào ₫ó và

thường ₫ã có sẵn Các nguyên tắc chính yếu của kiến trúc hướngdịch vụ là :

 Services are autonomous : tự trị

 Services are distributable : dễ dàng phân phối

 Services are loosely coupled : nối ghép rất lỏng

 Services share schema and contract, not class : dùng chung

mô hình và hợp ₫ồng chứ không phải là class cụ thể

 Compatibility is based on policy : ₫ộ tương thích phụ thuộc vàochính sách cụ thể

Trang 34

 Ưu ₫iểm của kiến trúc hướng dịch vụ :

Trang 35

 Tình huống nên dùng : bất kỳ hệ thống phần mềm phức tạp nào

mà muốn chạy trên nền Internet

 Khuyết ₫iểm : ₫ộ hiệu quả phụ thuộc vào cơ sở hạ tầng mạn và

máy chạy service

Trang 36

Kiến trúc lô tuần tự (Batch Sequential)

 Đặc tả : Chương trình gồm n phần mềm ₫ộc lập và ₫ược chạy

theo cơ chế tuần tự : phần mềm i chạy trước, khi xong rồi thìtruyền kết quả cho phần mềm thứ i+1 Mỗi phần mềm i trong lô

₫ược gọi là filter, nó xử lý dữ liệu ₫ầu vào theo ₫ịnh dạng xác ₫ịnhrồi tạo kết quả ₫ầu ra theo ₫ịnh dạng xác ₫ịnh

Trang 37

 Tình huống nên dùng : trong các ứng dụng xử lý dữ liệu mà dữ

liệu nhập cần ₫ược xử lý bởi nhiều công ₫oạn khác nhau và cótính ₫ộc lập cao trước khi tạo ra kết quả cuối cùng

 Ưu ₫iểm : dễ dàng thay ₫ổi/bảo trì/dùng lại từng filter của hệ

thống, phù hợp với nhiều hoạt ₫ộng nghiệp vụ, dễ dàng nâng cấpbằng cách thêm filter mới

 Khuyết ₫iểm : 2 filter kề nhau cần tuân thủ ₫ịnh dạng dữ liệu

chung

Trang 38

 Thí dụ : Thiết kế trực quan cửa sổ giao diện và dùng nó trong

phần mềm android

Chương trình thiết kế trực quan giao diện cửa sổ

ứng ụng

Project Android quản lý ứng dụng

Chương trình android dùng giao diện ₫ược thiết kế

Trang 39

Kiến trúc ₫ường ống và lọc (Pipe and filter Architecture)

 Đặc tả : Nới rộng kiến trúc lô tuần tự lên tầm cao mới :

 Các filter không nhất thiết là phần mềm ₫ộc lập lẫn nhau,chúng có thể là các thread chạy trong 1 chương trình

 Có thể có nhiều ống con trong từng ₫oạn xử lý

FilterFilter

Trang 40

Kiến trúc ₫ường ống và lọc (Pipe and filter Architecture)

 Tình huống nên dùng : trong các ứng dụng xử lý dữ liệu mà dữ

liệu nhập cần ₫ược xử lý bởi nhiều công ₫oạn khác nhau và cótính ₫ộc lập cao trước khi tạo ra kết quả cuối cùng

 Ưu ₫iểm : dễ dàng thay ₫ổi/bảo trì/dùng lại từng filter của hệ

thống, phù hợp với nhiều hoạt ₫ộng nghiệp vụ, dễ dàng nâng cấpbằng cách thêm filter mới, hiệu quả cao hơn kiến trúc lô tuần tự

 Khuyết ₫iểm : 2 filter kề nhau cần tuân thủ ₫ịnh dạng dữ liệu

chung

Trang 41

Kiến trúc ₫ường ống và lọc (Pipe and filter Architecture)

cây cú pháp hoàn chỉnh

Tạo code mục tiêu

cây ngữ nghĩa

Trang 42

Kiến trúc nhiều cấp (Layered architecture)

 Đặc tả : Hệ thống gồm nhiều cấp chức năng dạng chồng lên

nhau, mỗi layer có chức năng cụ thể, rõ ràng và cung cấp các dịch

vụ cho layer ngay trên mình Layer cấp thấp nhất chứa các dịch

vụ cơ bản nhất và ₫ược dùng cho toàn hệ thống

Layer nLayer n-1

Layer 2

interface sử dụng

Trang 43

 Tình huống nên dùng : xây dựng thêm khả năng mới trên hệ

thống có sẵn, hay khi có nhiều nhóm phát triển khác nhau, mỗinhóm chịu trách nhiệm về 1 layer chức năng cụ thể, hay khi cóyêu cầu bảo mật nhiều cấp

 Ưu ₫iểm : cho phép hiệu chỉnh bên trong layer bất kỳ sao cho

interface không ₫ổi Có thể giải quyết 1 chức năng nào ₫ó (xácnhận user) ở nhiều cấp theo cách thức tăng dần

 Khuyết ₫iểm : khó tách bạch chức năng của từng cấp, layer trên

khó tương tác với layer phía dưới nó nhưng không liền kề Hiệuquả giảm sút khi nhiều layer phải tương tác nhau ₫ể giải quyết 1chức năng nào ₫ó

Trang 44

 Thí dụ : Kiến

trúc mạng OSI

và kiến trúc

mạng internet

Trang 45

Kiến trúc client-server (client-server Architecture)

 Đặc tả : Hệ thống gồm 2 loại phần tử chức năng : server cung cấp

1 số dịch vụ, client là phần tử sử dụng dịch vụ bằng cách truy xuất

₫ến server tương ứng

Trang 46

 Tình huống nên dùng : khi database dùng chung từ nhiều vị trí

khác nhau hay khi tải hệ thống thay ₫ổi ₫ộng (nhân bản serverthành nhiều phần tử)

 Ưu ₫iểm : server có thể phân tán tự do trên mạng.

 Khuyết ₫iểm : ₫ộ hiệu quả phụ thuộc vào mạng và hệ thống nên

khó lường trước Nếu các server ₫ược quản lý bởi các tổ chức khácnhau thì có vấn ₫ề về quản lý chúng

Trang 47

 Thí dụ : Hệ thống quản lý phim ảnh dùng mô hình client-server

Trang 48

Kiến trúc 3 ₫ối tác (3-tiers Architecture)

 Đặc tả : Sự cải tiến của kiến trúc client-server Hệ thống gồm 3

loại phần tử chức năng : client, server, và server của server

client

server

dùng

Trang 49

Trang 50

 Thí dụ : Hệ thống quản lý phim ảnh dùng mô hình 3-tiers

InternetServer tiếp nhận các request từ client và xử lý luận lý

DBMS

Client nClient n

Internet

Trang 51

Kiến trúc n ₫ối tác (n-tiers Architecture)

 Đặc tả : Sự tổng quát của kiến trúc 3-tiers Hệ thống gồm n loại

phần tử chức năng : client, server, và server của server,

Trang 52

Trang 53

 Thí dụ : Hệ thống quản lý phim ảnh dùng mô hình n-tiers

Server tiếp nhận các request từ client và xử lý luận lý

Trang 54

Kiến trúc MVC (Model-View-Controller)

 Đặc tả : Hệ thống gồm 3 thành phần luận lý tương tác lẫn nhau :

 Model quản lý dữ liệu và các tác vụ liên quan ₫ến dữ liệu này

 View ₫ịnh nghĩa và quản lý cách thức dữ liệu ₫ược trình bàycho user

 Controller quản lý các tương tác với user như ấn phím, clickchuột… và gởi thông tin tương tác này tới View và/hoặc Model

Trang 55

Trang 56

 Tình huống nên dùng : Hệ thống có nhiều cách ₫ể view và tương

tác với dữ liệu, hoặc ta chưa biết trước các yêu cầu tương lai về sựtương tác và biểu diễn dữ liệu của chương trình

 Ưu ₫iểm : cho phép dữ liệu thay ₫ổi ₫ộc lập với cách thức thể hiện

nó và ngược lại

 Khuyết ₫iểm : có thể cần nhiều code hơn và code có thể phức

tạp hơn khi mô hình dữ liệu và sự tương tác chỉ ở mức ₫ộ ₫ơngiản

Trang 57

 Thí dụ : Hệ thống web dùng kiến trúc MVC :

Trang 58

Kiến trúc MVP (Model-View-Presenter)

 Đặc tả : Hệ thống gồm 3 thành phần luận lý tương tác lẫn nhau :

 Model quản lý dữ liệu và các tác vụ liên quan ₫ến dữ liệu này

 View ₫ịnh nghĩa và quản lý cách thức dữ liệu ₫ược trình bàycho user, quản lý các tương tác với user như ấn phím, clickchuột… và gởi thông tin tương tác này tới Presenter ₫ể nhờ xử

lý chi li hơn

 Presenter xử lý chi li về luận lý nghiệp vu, nhờ Model truy xuất

dữ liệu khi cần

Trang 60