Bài giảng Kiến trúc phần mềm: Chương 3 - Nguyễn Trung Hiệp

Bài giảng Kiến trúc phần mềm - Chương 3: Các mẫu kiến trúc phổ dụng cung cấp cho người học các kiến thức: Kiến trúc trong các hệ thống phần mềm, các mẫu kiến trúc phổ dụng, kết chương. Mời các bạn cùng tham khảo nội dung chi tiết.

Trang 1

Khoa Khoa học & Kỹ thuật Máy tính Trường ĐH Bách Khoa Tp.HCM

áp dụng nhất quán thông qua tất cả các bước của dự án phần mềm

₫ược

toàn vẹn kiến trúc ₫ược giữ nguyên

Trang 2

database, object, ADT

các thành phần gọi thủ tục, pipe, phát tán sự kiện

dựng : chữ ký, ₫iều kiện pre/post, ₫ặc tả RT

3.1 Kiến trúc trong các hệ thống phần mềm

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

Trang 3

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

program & subroutines), các cấp có thứ bậc (Hierarchical layers),

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

luật (Rule-based system)

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

Blackboard

3.2 Các mẫu kiến trúc phổ dụng

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 :

Trang 4

Môn : Kiến trúc phần mềm

Chương 3 : Các mẫu kiến trúc phổ dụng

Slide 7

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 ₫ịnh rồi tạo kết quả ₫ầu ra theo ₫ịnh dạng xác ₫ịnh

Filter Filter Filter Filterdata 1 data 2 data 3 data 4 data 5

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 5

Slide 9

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 dụng

Project Android quản lý ứng dụng androidNgười thiết kế

giao diện ₫ặc tả bản File XML

thiết kế

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

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 :

chúng có thể là các thread chạy trong 1 chương trình

Filter

Filter Filter

FilterFilter Filter

Trang 6

Slide 11

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ấp bằ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

Parser Phân tích

cú pháp

Phân tích ngữ nghĩa

Tạo code mục tiêucây cú pháp

hoàn chỉnh

cây ngữ nghĩa object codecây cú pháp

thô

Trang 7

Slide 13

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ácdịch vụ cho layer ngay trên mình Layer cấp thấp nhất chứa cácdịch vụ cơ bản nhất và ₫ược dùng cho toàn hệ thống

Layer 1Layer 2

Layer nLayer n-1

interface sử dụng của layer 1

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

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 1 chức năng nào ₫ó

Trang 8

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

Client dùng Server

Trang 9

Slide 17

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 server thà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ứckhác nhau thì có vấn ₫ề về quản lý chúng

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

Trang 10

Slide 19

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

cho client

serverdùng

Trang 11

Slide 21

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

Client 1

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

Client 2 Client 3 Client n

Internet

DBMS ds thư viện

DBMS Films

DBMS Photo

DBMSthông tinInternet

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 12

Slide 23

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

Client 1

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

Client 2 Client 3 Client n

Internet

DBMS ds thư viện

DBMS Films

DBMS Photo

DBMSthông tinInternet

Trang 13

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

cho user

chuột… và gởi thông tin tương tác này tới View và/hoặc Model

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

Trang 14

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

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

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

Trang 15

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

cho user

chuột… và gởi thông tin tương tác này tới View và/hoặc Model

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

Trang 16

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

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

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

Trang 17

Slide 33

Kiến trúc kho (Repository Architecture)

Đặc tả : Tất cả dữ liệu của hệ thống ₫ược quản lý trong 1 kho

chứa tập trung, mọi thành phần chức năng của hệ thống ₫ều cóthể truy xuất kho chứa này Các thành phần không tương tác trựctiếp với nhau, chỉ thông qua kho chứa tập trung

Component 1

Kho dữ liệu (repository)Component 2 Component 3 Component n

Tình huống nên dùng : khi hệ thống tạo và chứa 1 lượng rất lớn

thông tin trong thời gian dài, hay trong các hệ thống dựa vào dữliệu, ở ₫ó việc chứa thông tin vào kho sẽ kích hoạt 1 tool hay 1 chức năng hoạt ₫ộng

Ưu ₫iểm : các thành phần ₫ộc lập nhau, không ai biết gì về ai

khác

Khuyết ₫iểm : kho là ₫iểm yếu nhất, nếu có lỗi sẽ ảnh hưởng

toàn bộ các thành phần chức năng Có vấn ₫ề về truy xuất ₫ồngthời kho, phân tán kho trên nhiều máy cũng khó khăn

Trang 18

Slide 35

Thí dụ : Môi trường IDE gồm nhiều thành phần dùng chung kho

thông tin, mỗi tool tạo thông tin và ₫ể trong kho ₫ể các tool khácdùng

Trang 19

Slide 37

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

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

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

Trang 20

Slide 39

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

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 21

Trang 22

Slide 43

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

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

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

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 23

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

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ướng dịch vụ là :

Trang 24

Slide 47

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

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

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

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ạng và

máy chạy service

Trang 25

thiết thường ₫ược gộp thành module

Trang 26

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 27

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

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ện xả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ẫn event handler Có thể có các dạng tương tác khác giữa các phần tử như gọi thủ tục, truy xuất dữ liệu

Trang 28

Slide 55

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

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

Trang 29

Slide 57

Kiến trúc bảng ₫en (Blackboard Architecture)

blackboard : là vùng nhớ toàn cục có cấu trúc của phần mềm, nó

chứa các ₫ối tượng của bài toán cần giải quyết, còn ₫ược gọi làcác nút, chúng ₫ược tổ chức dạng phân cấp

Knowledge sources : là những module chức năng chuyên dụng

có cách biểu diễn riêng biệt Mỗi KS ₫ược ₫ặc trưng bởi 1 tập các

₫iều kiện kích hoạt xác ₫ịnh và ₫oạn code xử lý dữ liệu từblackboard rồi ₫óng góp kết quả vào quá trình giải quyết bài toán

Control : là phần tử ₫iều khiển chung, nó cấu hình, chọn lựa và

thi hành các KS Việc xác ₫ịnh KS nào là dựa vào trạng thái của quá trình giải quyết bài toán (₫ược miêu tả trong blackboard)

Kiến trúc bảng ₫en (Blackboard Architecture)

Tình huống nên dùng : trong các hệ chuyên gia giải quyết vấn

₫ề mà không có cách giải quyết tất ₫ịnh và có thể tin tưởng ₫ược

Khuyết ₫iểm : ?

Định dạng
Số trang	30
Dung lượng	549,69 KB