ch ng 3 cÁc mẪu kiẾn trÚc phỔ Ụ -...

Khoa Khoa học & Kỹ thuật Máy tính

Trường ĐH Bách Khoa Tp.HCM© 2015

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

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

3.1 Kiến trúc trong các hệ thống phần mềm3.2 Các mẫu kiến trúc phổ dụng3.3 Kết chương

Chương 3

CÁC MẪU KIẾN TRÚC PHỔ DỤNG





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

kiến trúc là cấu trúc các phần tử, không chỉ là cái gì mà là tại saokiến trúc tốt :

kết quả của 1 tập các nguyên tắc và kỹ thuật nhất quán ₫ược áp dụng nhất quán thông qua tất cả các bước của dự án phần mềmkhông nản lòng khi ₫ối diện với các thay ₫ổi không thể tránh ₫ược.nguồn hướng dẫn xuyên suốt thời gian sống của phần mềmbao gồm 1 ít tính chất và luật khóa ₫ể tổ hợp chúng sao cho sựtoàn vẹn kiến trúc ₫ược giữ nguyên.






Các phần tử của ₫ặc tả kiến trúcĐịnh nghĩa kiến trúc cho 1 hệ thống chọn :

các thành phần : ₫ịnh nghĩa ₫ịa ₫iểm tính toán, thí dụ filter, database, object, ADTcác mối nối (Connector) : làm trung gian cho tương tác giữa cá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ây dựng : chữ ký, ₫iều kiện pre/post, ₫ặc tả RT.






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 ₫ượ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.






Các ₫ặc ngữ kiến trúc phổ biếnCá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 (main program & 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ào luật (Rule-based system)Các thành phần ₫ọc lập : các process giao tiếp nhau (Communicating processes), các hệ thống xử lý sự kiện (Event systems).Các hệ thống tập trung quanh dữ liệu (Repositories) : Database, Blackboard





3.2 Các mẫu kiến trúc phổ dụngKiế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 :

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.





3.2 Các mẫu kiến trúc phổ dụngKiế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





3.2 Các mẫu kiến trúc phổ dụngKiến trúc lô tuần tự (Batch Sequential)

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





3.2 Các mẫu kiến trúc phổ dụngKiến trúc lô tuần tự (Batch Sequential)

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

File XML ₫ặc tả bản thiết kế

Chương trình android dùng

giao diện ₫ược thiết kế





3.2 Các mẫu kiến trúc phổ dụngKiế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ý.

Filter

Filter Filter

Filter

Filter Filterdata 1

data 2

data 3

data 4

data 5

data 6

data 7data 8





3.2 Các mẫu kiến trúc phổ dụngKiế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 chung.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc ₫ường ống và lọc (Pipe and filter Architecture)

Thí dụ : Chương trình dịch ngôn ngữ

Scanner

source code chuỗi token

Parser Phân tích cú pháp

Phân tích ngữ nghĩa

Tạo code mục tiêu

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

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





3.2 Các mẫu kiến trúc phổ dụngKiế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ênnhau, 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 1

Layer 2

Layer n

Layer n-1

...

interface sử dụng của layer 1





3.2 Các mẫu kiến trúc phổ dụngKiế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 chointerface 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ênkhó 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 ₫ó.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc nhiều cấp (Layered architecture)

Thí dụ : Kiến trúc mạng OSI và kiến trúc mạng internet.





3.2 Các mẫu kiến trúc phổ dụngKiế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ấp1 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 Serverdùng





3.2 Các mẫu kiến trúc phổ dụngKiến trúc client-server (client-server Architecture)

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ênkhó 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.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc client-server (client-server Architecture)

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





3.2 Các mẫu kiến trúc phổ dụngKiế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 3loại phần tử chức năng : client, server, và server của server.

Client Server cho client

dùng Server cho server

dùng





3.2 Các mẫu kiến trúc phổ dụngKiến trúc 3 ₫ối tác (3-tiers Architecture)






3.2 Các mẫu kiến trúc phổ dụngKiến trúc 3 ₫ối tác (3-tiers Architecture)

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 tin

Internet





3.2 Các mẫu kiến trúc phổ dụngKiế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ạiphần tử chức năng : client, server, và server của server,...

Client Server cho client

dùng Server cho server 1

dùng Server cho server n-2

dùng





3.2 Các mẫu kiến trúc phổ dụngKiến trúc n ₫ối tác (n-tiers Architecture)






3.2 Các mẫu kiến trúc phổ dụngKiến trúc n ₫ối tác (n-tiers Architecture)

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 tin

Internet





3.2 Các mẫu kiến trúc phổ dụngKiế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, click chuột… và gởi thông tin tương tác này tới View và/hoặc Model.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc MVC (Model-View-Controller)






Tình huống nên dùng : Hệ thống có nhiều cách ₫ể view và tươngtá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ệnnó và ngược lại.Khuyết ₫iểm : có thể cần nhiều code hơn và code có thể phứctạp hơn khi mô hình dữ liệu và sự tương tác chỉ ở mức ₫ộ ₫ơngiản.






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





3.2 Các mẫu kiến trúc phổ dụngKiế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. Controller quản lý các tương tác với user như ấn phím, click chuột… và gởi thông tin tương tác này tới View và/hoặc Model.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc MVP (Model-View-Presenter)






Tình huống nên dùng : Hệ thống có nhiều cách ₫ể view và tươngtá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ệnnó và ngược lại.Khuyết ₫iểm : có thể cần nhiều code hơn và code có thể phứctạp hơn khi mô hình dữ liệu và sự tương tác chỉ ở mức ₫ộ ₫ơngiản.






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





3.2 Các mẫu kiến trúc phổ dụngKiế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 khochứ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





3.2 Các mẫu kiến trúc phổ dụngKiến trúc kho (Repository Architecture)

Tình huống nên dùng : khi hệ thống tạo và chứa 1 lượng rất lớnthô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ề aikhác.Khuyết ₫iểm : kho là ₫iểm yếu nhất, nếu có lỗi sẽ ảnh hưởngtoà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.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc kho (Repository Architecture)

Thí dụ : Môi trường IDE gồm nhiều thành phần dùng chung khothông tin, mỗi tool tạo thông tin và ₫ể trong kho ₫ể các tool khácdùng.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc hướng ₫ối tượng (Objects based Architecture) Đặc tả : Hệ thống phần mềm gồm 1 tập các ₫ối tượng ₫ộc lập ₫ược ghép nối lỏng lẻo.

Object 1Object 2

Object 3

Object n

gởi thông ₫iệp





3.2 Các mẫu kiến trúc phổ dụngKiế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 chất sau :

ReusableReplaceableExtensible, HeritableEncapsulatedIndependentPersistentAggregation...





3.2 Các mẫu kiến trúc phổ dụngKiến trúc hướng ₫ối tượng (Objects based Architecture)

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





3.2 Các mẫu kiến trúc phổ dụngKiến trúc hướng ₫ối tượng (Objects based Architecture)Ưu ₫iểm của kiến trúc hướng ₫ối tượng :

UnderstandableReusableTestableExtensibleHighly Cohesive





3.2 Các mẫu kiến trúc phổ dụngKiến trúc hướng ₫ối tượng (Objects 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ó.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc các thành phần (Components 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.

Component 1Component 2

Component 3

Component n





3.2 Các mẫu kiến trúc phổ dụngKiến trúc các thành phần (Components based Architecture)

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 :

ReusableReplaceableNot context specificExtensibleEncapsulatedIndependent





3.2 Các mẫu kiến trúc phổ dụngKiế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 :

Ease of deploymentReduced costEase of developmentReusableMitigation of technical complexity





3.2 Các mẫu kiến trúc phổ dụngKiế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ó.





3.2 Các mẫu kiến trúc phổ dụngKiến trúc hướng dịch vụ (Service-Oriented Architecture) Đặc tả : Cho phép tạo phần mềm bằng cách sử dụng các dịch vụsẵn có.

App Module Service 1 Service 2 Service 3 Service n

Internet





3.2 Các mẫu kiến trúc phổ dụngKiế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à :

Services are autonomousServices are distributableServices are loosely coupledServices share schema and contract, not classCompatibility is based on policy





3.2 Các mẫu kiến trúc phổ dụngKiế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ụ :

Domain alignmentAbstractionDiscoverabilityInteroperabilityRationalization





3.2 Các mẫu kiến trúc phổ dụngKiế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.





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

Kiến trúc Chương trình chính và thủ tục (Main Program/Subroutine Architecture)Đặc tả : Hệ thống phần mềm gồm 1 chương trình chính và 1 tập các thủ tục chức năng cần thiết.dùng cách phân rã theo dạng cây phân cấp : dựa trên mối quan hệ ₫ịnh nghĩa-sử dụng.chỉ có 1 thread kiểm soát duy nhất : ₫ược hỗ trợ trực tiếp bởi các ngôn ngữ lập trình.ẩn chứa cấu trúc hệ thống con : các thủ tục có mối quan hệ mật thiết thường ₫ược gộp thành module.lý do của sự phân cấp : ₫ộ ₫úng ₫ắn của 1 thủ tục phụ thuộc vào sự ₫úng ₫ắn của các thủ tục mà nó gọi.





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

Kiến trúc Chương trình chính và thủ tục (Main Program/ Subroutine Architecture)

Main Program

Sub 1 Sub 2 Sub 3

Sub nSub n-1





3.2 Các mẫu kiến trúc phổ dụngKiến trúc các process liên lạc nhau (Communication process

Architecture) Đặc tả : Hệ thống phần mềm gồm 1 tập các process ₫ộc lập liên lạc lẫn nhau khi cần.

Process 1Process 2

Process 3

Process n





3.2 Các mẫu kiến trúc phổ dụngKiế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 process :

₫iểm tới ₫iểm₫ồng bộ hay bất ₫ồng bộRPC và các giao thức khác có thể ₫ược ₫ặt trên cấp các process này.





3.2 Các mẫu kiến trúc phổ dụngKiế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 2

Component 3 Component n

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





3.2 Các mẫu kiến trúc phổ dụngKiế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ưu ý là phần tử nào trong hệ thống ₫ều có thể là event emitter 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...





3.2 Các mẫu kiến trúc phổ dụngKiế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 :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ằng thành phần khác.

Khuyết ₫iểm : ?





3.2 Các mẫu kiến trúc phổ dụngKiến trúc bảng ₫en (Blackboard Architecture) Đặc tả : Hệ thống phần mềm gồm 3 loại thành phần tương tác nhau như sau :

KB 1

Controller

Blackboard

KB 1 KB 1 KB 1





3.2 Các mẫu kiến trúc phổ dụngKiế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).





3.2 Các mẫu kiến trúc phổ dụngKiế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 : ?





3.3 Kết chương

Chương này ₫ã giới thiệu 1 số mẫu kiến trúc phần mềm phổdụng.

ch ng 3 cÁc mẪu kiẾn trÚc phỔ Ụ -...

Documents