Bài tập lớn môn Công Nghệ Phần Mềm: Thiết kế kiến trúc

1

Chapter 6

■

Architectural design

Bài tââp lớn môn Công Nghêâ Phần
Mềm
Nhóm BLT : nhóm 04
Thành Viên : Đỗ Quốc Viê tâ
Trần Anh Tuấn
Nguyễn Thị Hoa
Làm bài Chapter 6.

6. Thiết kế kiến trúc
Mục tiêu
Mục tiêu của chương này là giới thiệu các khái niệm về phần mềm kiến trúc
và thiết kế kiến trúc. Những việc cần làm khi đọc chương này :
■ hiểu được sự quan trọng các thiết kế kiến trúc của phần mềm ;
■ hiểu các quyết định được thực hiện về hệ thống kiến trúc trong quá trình
thiết kế kiến trúc;
■ phải giới thiệu các ý tưởng của mô hình kiến trúc, chứng tỏ được cách
thức tổ chức kiến trúc hệ thống, có thể sử dụng lại trong thiết kế hệ thống;
■hiểu các mô hình kiến trúc thường được sử dụng trong các loại hệ thống
ứng dụng khác nhau, bao gồm hệ thống xử lý giao dịch và hệ thống xử lý
ngôn ngữ
Nội dung

2

Chapter 6

■

Architectural design

6.1 Quyết định thiết kế kiến trúc
6.2 Quan điểm kiến trúc
6.3 Mô hình kiến trúc
6.4 Ứng dụng kiến trúc

Thiết kế kiến trúc là mối liên quan với sự hiểu biết làm thế nào một hệ
thống cần được tổ chức và thiết kế các cấu trúc tổng thể của hệ thống đó.
Trong mô hình của quá trình phát triển phần mềm , đã được diễn đạt trong
Chương 2 , thiết kế kiến trúc là giai đoạn đầu tiên trong quá trình thiết kế
phần mềm. Đó là liên kết quan trọng giữa thiết kế và yêu cầu kỹ thuật , vì
nó xác định các thành phần cấu trúc chính trong một hệ thống và quan hệ
giữa chúng. Các đầu ra của quá trình thiết kế kiến trúc là một mô hình kiến
trúc mô tả cách hệ thống được tổ chức như là một tập hợp các thành phần
giao tiếp.
Trong quy trình nhanh nhẹn, ai cũng công nhận rằng giai đoạn đầu của
tiến trình phát triển nên có liên quan đến thiết lập kiến trúc hệ thống tổng
thể . Phát triển gia tăng của kiến trúc thường không thành công. Trong khi
tái cấu trúc thành phần để phản ứng lại thay đổi thường khá dễ, tái cấu trúc
kiến trúc hệ thống có thể sẽ đắt .
Để giúp bạn hiểu kiến trúc hệ thống, hãy xem hình 6.1. Điều này cho thấy
mô hình trừu tượng của kiến trúc cho hệ thống rô – bốt đóng gói cho thấy
thành phần đó phải phát triển. Hệ thống người máy này có thể đóng gói

nhiều loại đối tượng. Nó sử dụng thành phần định hướng để chọn ra các đối
tượng trên băng tải, xác định loại đói tượng và chọn đúng loại bao bì. Sau
đó hệ thống di chuyển đối tượng từ băng tải giao hàng để được đóng gói. Nó
đặt đối tượng đóng gói trên băng tải khác. Mô hình kiến trúc cho thấy thành
phần này và mối liên quan giữa chúng.


3

Chapter 6

■

Architectural design

Trên thực tế, thường có sự trùng lặp đáng kể giữa các quá trình kỹ thuật
yêu cầu và kiến trúc thiết kế. Tốt nhất là, một đặc điểm kĩ thuật hế thống
không nên bao gồm mọi thông tin thiết kế. Điều này là không thực tế, ngoại
trừ hệ thống rát nhỏ. Phân tích kiến trúc thường cần thiết để cấu trúc và tổ
chức các đặc điểm kỹ thuật. Do đó,như một phần của quá trình yêu cầu kĩ
thuật, bạn có thể đề xuất một hệ thống kiến trúc trừu tượng mà bạn liên kết
các nhóm chức năng hệ thống hoặc các tính năng với các thành phần có quy
mô lớn hoặc các hệ thống phụ. Sau đó bạn có thể dùng phân tích này để thảo
luận yêu cầu và đặc điểm của hệ thống với những bên tham gia.
Bạn có thể thiết kế kiến trúc phần mềm tại hai lớp trừu tượng, tôi gọi nó
là kiến trúc cỡ nhỏ và kiến trúc cỡ lớn :
1. Kiến trúc cỡ nhỏ có liên quan đến kiến trúc của chương trình cá nhân. Ở
cấp độ này, chúng ta quan tâm đến cách chương trình cá nhân được phân
hủy thành các thành phần. Chương này chủ yếu liên quan về kiến trúc
chương trình.

2. Kiến trúc cỡ lớn có liên quan đến kiến trúc của hệ thống doanh nghiệp
phức tạp bao gồm hệ thống khác, chương trình, và thành phần chương
trình. Hệ thống doanh nghiệp này được phân phối trên máy tính khác, có thể
là sở hữu và quản lý bởi công ty khác. Tôi nói lại về kiến trúc cỡ lớn trong
các chương 18 và 19, nơi tôi thảo luận về phân phối hệ thống kiến trúc.
Chương 6

■

Thiết kế kiến trúc

Hệ thống định hướng

Hệ thống nhận dạng đối tượng

Bộ điều khiển cánh tay Bộ điều khiển kìm

Bộ điều khiển băng tải

Hình 6.1 Kiến trúc
của gói hệ thống

149


Hệ thống
lựa chọn
gói

4

Chapter 6

■

điều khiển robot

Architectural design

Hệ thống
đóng gói

Kiến trúc phần mềm rất quan trọng vì nó ảnh hưởng đến hiệu suất, độ bền,
khả năng phân phối và khả năng bảo trì của hệt thống ( Bosch 2000 ). Khi
thảo luận Bosch, thành phần riêng biệt triển khai yêu cầu hệ thống chức
năng. Các yêu cầu phi chức năng phụ thuộc vào kiến trúc hệ thống - cách
thức mà các thành phần này được tổ chức và giao tiếp. Trong nhiều hệ
thống , yêu cầu phi chức năng cũng bị ảnh hưởng bởi các thành phần cá
nhân, nhưng chắc chắn là các kiến trúc của hệ thống là sự ảnh hưởng chi
phối.
Bass và những người khác . (2003 ) thảo luận về ba ưu điểm của thiết kế
và tài liệu kiến trúc phần mềm một cách rõ ràng :
1. Giao tiếp bên tham gia Kiến trúc là một bài thuyết trình cấp cao của hệ
thống có thể được sử dụng như là một trọng tâm thảo luận của các bên
tham gia khác
2. Phân tích hệ thống Làm kiến trúc hệ thống hiện ở giai đoạn đầu trong
phát triển hệ thống đòi hỏi một số phân tích. Quyết điịnh thiết kế kiến trúc
có một ảnh hưởng sâu sắc về việc có hay không hệ thống có thể đáp ứng yêu
cầu quan trọng như hiệu suất, độ tin cậy và khả năng bảo trì
3. Tái sử dụng quy mô lớn Mô hình kiến trúc hệ thống nhỏ gọn, dễ quản lý

mô tả về cách hệ thống được tổ chức và cách thành phần hoạt động liên
thông. Cấu trúc hệ thống thường là như nhau, cho các hệ thống với các yêu
cầu tương tự và do đó có thể hỗ trợ tái sử dụng phần mềm có quy mô lớn.
Như tôi đã giải thích trong Chương 16 , nó có thể phát triển các dòng sản
phẩm kiến trúc mà các kiến trúc tương tự được tái sử dụng trên một loạt
các hệ thống liên quan.
Hofmeister và những người khác. (2000) đề xuất rằng kiến trúc phần
mềm có thể phục vụ trước hết là một kế hoạch thiết kế cho việc đàm phán
các yêu cầu hệ thống , và thứ hai như là một phương tiện của các cuộc thảo
luận cơ cấu với các khách hàng , các nhà phát triển , và các nhà quản lý. Họ
cũng cho rằng nó là một công cụ cần thiết cho việc quản lý phức tạp. Nó ẩn
thông tin chi tiết và cho phép các nhà thiết kế tập trung vào các khái niệm
trừu tượng hệ thống quan trọng.
Kiến trúc hệ thống thường được mô phỏng bằng các sơ đồ khối đơn giản ,
như trong hình 6.1. Mỗi hộp trong sơ đồ đại diện cho một thành phần. Hộp


5

Chapter 6

■

Architectural design

trong hộp cho thấy thành phần đã được phân hủy để thành phần phụ. Mũi
tên nghĩa là dữ liệu và hoặc tín hiệu điều khiển được chuyển từ thành phần
đến thành phần về phía mũi tên. Bạn thấy được nhiều ví dụ kiểu này của mô
hình kiến trúc trong danh mục kiến trúc phần mềm của Booch ( Booch, 2009
).

Sơ đồ khối giới thiệu hình ảnh cao cấp của cấu trúc hệ thống, mọi người từ
môn học khác, người liên can đến tiến trình phát triển hệ thống, có thể dễ
dàng hiểu. Tuy nhiên, mặc dù sử dụng rộng rãi của chúng, Bass và những
người khác( 2003 ) không thích sơ đồ khối chính thức để mô tả kiến trúc. Họ
cho rằng các sơ đồ chính thức là đại diện kiến trúc nghèo, khi chúng cho
thấy cả loại mối quan hệ giữa thành phần hệ thống cũng không thành phần
của thuộc tính thấy được bên ngoài. Những mâu thuẫn rõ ràng giữa thực
hành và lý thuyết kiến trúc phát sinh bởi vì có hai cách mà một mô hình kiến
trúc của chương trình được sử dụng:
1. Như cách tạo điều kiện thuận lợi thảo luận về thiết kế hệ thống Một quan
điểm kiến trúc cấp cao của một hệ thống rất hữu ích cho giao tiếp với các
bên tham gia và lập kế hoạch dự án , vì nó không phải là lộn xộn với các chi
tiết. Các bên tham gia có thể liên quan đến nó và hiểu được một cái nhìn
trừu tượng của hệ thống. Sau đó, họ có thể thảo luận về các hệ thống như
một toàn thể mà không bị nhầm lẫn bởi chi tiết. Mô hình kiến trúc xác định
các thành phần chính đó sẽ được phát triển để quản lý có thể bắt đầu phân
công nhân viên để có kế hoạch phát triển của các hệ thống này.
2. Như cách của tài liệu kiến trúc đã được thiết kế Mục đích đây là để tạo ra
mô hình hệ thống hoàn chỉnh cho thấy thành phần khác trong hệ thống, giao
diện của chúng, và kết nối của chúng. Lập luận cho rằng đây là một mô tả
kiến trúc chi tiết, như vậy làm cho nó dễ dàng hơn để hiểu và phát triển hệ
thống.
Sơ đồ khối là một cách thích hợp để mô tả kiến trúc hệ thống trong quá
trình thiết kế, chúng là một cách tốt để hỗ trợ thông tin liên lạc giữa những
bên tham gia trong quá trình. Trong nhiều dự án , đây thường là những tài
liệu kiến trúc duy nhất tồn tại. Tuy nhiên , nếu cấu trúc của một hệ thống
được ghi chép kỹ lưỡng sau đó nó sẽ tốt hơn để sử dụng một ký hiệu với ngữ
nghĩa rõ ràng để mô tả kiến trúc. Tuy nhiên , như tôi đã thảo luận trong
Phần 6.2 , một số người nghĩ rằng tài liệu chi tiết không phải là hữu ích,
cũng không thật sự đáng chi phí của phát triển của nó.

6.1

■ Quyết định thiết kế kiến trúc

151

6.1 Quyết định kiến trúc hệ thống
Thiết kế kiến trúc là một quá trình sáng tạo nơi bạn thiết kế một hệ thống tổ
chức mà nó sẽ đáp ứng các yêu cầu chức năng và phi chức năng của một hệ
thống. Vì nó là quy trình sáng tạo, hoạt động trong quy trình tùy vào loại hệ
thống đang phát triển, nền tảng và kinh nghiệm về kiến trúc sư hệ thống, và
yêu cầu cụ thể cho hệ thống. Do đó nó hữu ích để suy nghĩ về thiết kế kiến
trúc như một loạt các quyết định được thực hiện chứ không phải là một
chuỗi các hoạt động. Trong quy trình thiết kế kiến trúc, kiến trúc sư hệ thống
phải thực hiện một số quyết định cấu trúc ảnh hưởng sâu sắc hệ thống và
tiến trình phát triển của nó. Dựa trên kiến thức và kinh nghiệm của họ , họ
phải xem xét các câu hỏi cơ bản sau đây về hệ thống:
1. Có kiến trúc ứng dụng khái quát có thể hoạt động như khuôn mẫu cho hệ
thống được thiết kế?
2. Làm sao hệ thống được phân phối qua một số lõi hoặc bộ xử lý?
3. Những mô hình kiến trúc, phong cách có thể được sử dụng?
4. Điều gì sẽ là phương pháp cơ bản được dùng để cấu trúc hệ thống?
5. Làm thế nào thành phần cấu trúc trong hệ thống sẽ được phân tách thành
các phần con ?
6. Chiến lược nào sẽ được sử dụng để kiểm soát hoạt động của các thành
phần trong hệ thống?
7. Những tổ chức kiến trúc nào là tốt nhất để cung cấp các yêu cầu phi chức
năng của hệ thống?

8. Thiết kế kiến trúc sẽ được đánh giá như thế nào?
9. Kiến trúc của hệ thống được lập tài liệu như thế nào?
Mặc dù mỗi hệ thống phần mềm độc đáo, hệ thống trong cùng miền ứng
dụng thường có kiến trúc tương tự như phản ánh các khái niệm cơ bản của
tên miền. Chẳng hạn như, dòng sản phẩm ứng dụng được ứng dụng được


dựa trên kiến trúc lõi với các biến thể đáp ứng yêu cầu khách hàng cụ thể.
Khi thiết kế một kiến trúc hệ thống , bạn phải quyết định những gì hệ thống
của bạn và các lớp ứng dụng rộng lớn hơn có điểm chung , và quyết định bao
nhiêu kiến thức từ các kiến trúc ứng dụng mà bạn có thể tái sử dụng. Tôi
thảo luận về kiến trúc ứng dụng chung trong Mục 6.4 và sản phẩm ứng dụng
dòng trong Chương 16.
Để nhúng hệ thống và thiết kế hệ thống cho máy tính cá nhân, thường là
chỉ có một bộ xử lý và bạn sẽ không phải thiết kế kiến trúc phân phối cho hệ
thống. Tuy nhiên , hầu hết các hệ thống lớn hiện đang phân phối , trong đó
hệ thống phần mềm được phân phối trên nhiều máy tính khác nhau. Lựa
chọn của kiến trúc phân phối là quyết định then chốt ảnh hưởng hiệu năng
và độ tin cậy của hệ thống. Đây là một chủ đề lớn theo đúng nghĩa của nó và
tôi bao gồm nó riêng trong Chương 18.
Kiến trúc của hệ thống phần mềm có thể được dựa trên đặc biệt kiến trúc
mô hình hoặc kiểu cách. Mô hình kiến trúc là mô tả về tổ chức hệ thống
( Garlan và Shaw, 1993 ), như là một máy khách - máy chủ tổ chức hoặc kiến
trúc phân tầng. Mô hình kiến trúc nắm bắt được bản chất của một kiến trúc
đã được sử dụng trong các hệ thống phần mềm khác nhau . Bạn cần phải
nhận thức của mô hình chung , nơi chúng có thể được sử dụng, ưu điểm và
khuyết điểm của chúng khi đưa ra quyết định về kiến trúc của một hệ thống.
Tôi thảo luận về một số mô hình thường xuyên được sử dụng trong phần 6.3.
Khái niệm của Garlan và Shaw về một phong cách kiến trúc ( phong cách
và mô hình đã đi đến ý nghĩa giống nhau ) bao gồm các câu hỏi 4-6 trong

danh sách trước đó. Bạn phải chọn cấu trúc phù hợp nhất, như là máy khách
- máy chủ hoặc tầng cấu trúc,điều đó sẽ giúp bạn có thể đáp ứng yêu cầu hệ
thống. Để phân tách bộ hệ thống cấu trúc, bạn quyết định chọn chiến lược
cho phân tách thành phần vào thành phần phụ. Phương pháp bạn có thể
dùng cho phép các loại kiến trúc khác nhau được triển khai. Cuối cùng ,
trong quá trình xây dựng mô hình điều khiển, bạn đưa ra quyết định về cách
thức thực hiện của các thành phần được kiểm soát. Bạn phát triển mối quan
hệ mô hình tổng quát của điều khiển giữa các bộ phận khác nhau của hệ
thống.
Do mối quan hệ chặt chẽ giữa các yêu cầu phi chức năng và kiến trúc phần
mềm, đặc biệt là phong cách kiến trúc và cấu trúc mà bạn chọn cho một hệ
thống cần phải phụ thuộc vào các yêu cầu hệ thống không hoạt động :
1.

Hiệu suất Nếu hiệu suất là yêu cầu quan trọng, kiến trúc nên được
thiết kế để định vị thao tác quan trọng trong một vài thành phần, với
thành phần này tất cả triển khai trên cùng một máy tính thay vì phân


phối qua mạng. Điều này nghĩa là sử dụng một vài thành phần tương
đối lớn hơn là thành phần nhỏ , mịn hạt , làm giảm số lượng các thông
tin liên lạc thành phần. Bạn cũng có thể xem xét tổ chức hệ thống thời
gian thực hiện để hệ thống được nhân bản và thi hành trên bộ xử lý
khác.
2.

Bảo mật Nếu bảo mật là một yêu cầu quan trọng, cấu trúc phân lớp
cho các kiến trúc nên được sử dụng , đối với các tài sản quan trọng
nhất bảo vệ trong các lớp trong cùng, với một mức độ cao của việc xác
nhận an ninh áp dụng cho các lớp.

3.

An toàn Nếu an toàn là một yêu cầu quan trọng , kiến trúc cần được
thiết kế để hoạt động an toàn liên quan đến tất cả đều nằm trong hoặc
một thành phần duy nhất hoặc trong một số lượng nhỏ các thành
phần. Điều này làm giảm chi phí và các vấn đề của việc xác nhận an
toàn và làm cho nó có thể cung cấp cho hệ thống bảo vệ liên quan mà
có thể an toàn tắt hệ thống trong trường hợp thất bại.

4.

Tính sẵn sàng Nếu tính sẵn sàng là yêu cầu quan trọng, kiến trúc nên
được thiết kế để bao gồm thành phần dư thừa sao cho có thể thay thế
và cập nhật thành phần mà không cần dừng hệ thống. Tôi mô tả hai
kiến trúc hệ thống chịu lỗi cho hệ thống có tính sẵn sàng cao trong
Chương 13.

5.

Bảo trì Nếu bảo trì là một yêu cầu quan trọng, kiến trúc hệ thống cần
được thiết kế sử dụng tinh hạt , thành phần tự chứa dễ dàng có thể
được thay đổi. Các nhà sản xuất của dữ liệu nên được tách ra từ người
tiêu dùng và các cấu trúc dữ liệu dùng chung nên tránh.

Rõ ràng có mâu thuẫn tiềm ẩn giữa vài kiến trúc này. Ví dụ, sử dụng các
thành phần lớn cải thiện hiệu suất và sử dụng các thành phần nhỏ , tinh
hạt cải thiện khả năng bảo trì. Nếu cả hiệu suất và bảo trì là các yêu cầu
hệ thống quan trọng, một số thỏa hiệp phải được tìm thấysau đó. Điều
này đôi khi có thể đạt được bằng cách sử dụng mô hình kiến trúc khác

nhau hoặc phong cách cho các bộ phận khác nhau của hệ thống.
Đánh giá thiết kế kiến trúc khó khăn vì thử nghiệm thực sự của kiến
trúc là cách tốt hệ thống đáp ứng yêu cầu của nó thiết thực và không
thiết thực khi nó được sử dụng. Tuy nhiên , bạn có thể làm một số đánh
giá bằng cách so sánh thiết kế của bạn đối với các kiến trúc tham khảo
hoặc các mẫu kiến trúc chung. Bosch (2000 ) mô tả những đặc tính phi


chức năng của mô hình kiến trúc cũng có thể được sử dụng để giúp đánh
giá kiến trúc

6.2

■

Quan điểm kiến trúc 153

6.2 Quan điểm kiến trúc
Tôi đã giải thích trong phần giới thiệu chương này là mô hình kiến trúc của
một hệ thống phần mềm có thể được sử dụng để tập trung thảo luận về các
yêu cầu phần mềm hoặc thiết kế. Ngoài ra , chúng có thể được sử dụng để
thiết kế một tài liệu để nó có thể được sử dụng như một cơ sở cho việc thiết
kế và thực hiện chi tiết hơn, và cho sự phát triển tương lai của hệ thống.
Trong phần này , tôi sẽ thảo luận hai vấn đề có liên quan đến cả hai :
1. Những điểm hay quan điểm rất hữu ích khi thiết kế và tài liệu về kiến trúc
của hệ thống?
2. Những ký hiệu nên được sử dụng để mô tả mô hình kiến trúc ?
Không thể đại diện cho tất cả thông tin liên quan về kiến trúc của hệ thống
trong một mô hình kiến trúc, như mỗi mô hình chỉ cho thấy một cái nhìn hay
quan điểm của hệ thống. Nó có thể cho thấy cách hệ thống được phân hủy

thành mô-đun, bao nhiêu tiến trình thời gian thực hiện tương tác, hoặc cách
khác nhau trong đó thành phần hệ thống được phân phát qua mạng. Tất cả
trong số này là hữu ích vào những thời điểm khác nhau, cả về thiết kế và tài
liệu, bạn thường cần phải trình bày nhiều quan điểm của các kiến trúc phần
mềm.
Có nhiều ý kiến khác nhau về những quan điểm là cần thiết. Krutchen
(1995), trong mô hình 4+1 nổi tiếng của ông về kiến trúc phần mềm, gợi ý
rằng nên có bốn điểm kiến trúc cơ bản , được đổi liên quan sử dụng các
trường hợp sử dụng hoặc các kịch bản . Những quan điểm mà ông gợi ý là:
1.

Một quan điểm hợp lý, trong đó cho thấy các khái niệm trừu tượng
chủ chốt trong hệ thống như các đối tượng hoặc các lớp đối tượng.
Nó phải có khả năng liên quan yêu cầu hệ thống cho các đối tượng
theo quan điểm hợp lý này .


Chapter 6

10

■

Architectural design

2.

Một quan điểm quá trình , trong đó cho thấy như thế nào, tại thời gian
chạy , hệ thống bao gồm các quá trình tương tác . Quan điểm này là
hữu ích cho việc nhận định về hệ thống đặc điểm không có chức năng

như hiệu suất và tính sẵn sàng.

3.

Một quan điểm phát triển , trong đó cho thấy cách các phần mềm
được phân hủy để phát triển, nó cho thấy sự phân hủy của các phần
mềm vào các thành phần được thực hiện bởi một nhà phát triển đơn
lẻ hoặc nhóm phát triển. Quan điểm này rất hữu ích cho các nhà quản
lý phần mềm và lập trình.

4.

Một quan điểm vật lý , trong đó cho thấy các hệ thống phần cứng và
cách các thành phần phần mềm được phân phối trên các bộ vi xử lý
trong hệ thống. Quan điểm này rất hữu ích cho các kỹ sư hệ thống có
kế hoạch triển khai hệ thống.

Hofmeister và những người khác( 2000 ) đề nghị việc sử dụng quan điểm
tương tự nhưng thêm vào khái niệm này của quan điểm lý thuyết. Quan
điểm này là một cái nhìn trừu tượng của hệ thống có thể là cơ sở để phân
hủy các yêu cầu cấp cao vào thông số kỹ thuật chi tiết hơn, giúp các kỹ sư
đưa ra quyết định về các thành phần có thể được tái sử dụng, và đại diện
cho một dòng sản phẩm (được thảo luận trong chương 16 ) chứ không phải
là một hệ thống duy nhất . Hình 6.1, trong đó mô tả kiến trúc của một robot
đóng gói , là một ví dụ về một cái nhìn hệ thống khái niệm.
Trong thực tế , quan điểm về khái niệm gần như luôn luôn phát triển trong
suốt quá trình thiết kế và được sử dụng để hỗ trợ việc ra quyết định kiến
trúc. Chúng là một cách để giao tiếp bản chất của một hệ thống để các bên
tham gia khác nhau . Trong quá trình thiết kế, một số quan điểm khác cũng
có thể được phát triển khi các khía cạnh khác nhau của hệ thống sẽ được

thảo luận , nhưng không cần mô tả hoàn toàn từ tất cả các quan điểm. Nó
cũng có thể có thể liên kết các mô hình kiến trúc , thảo luận trong phần tiếp
theo, với những quan điểm khác nhau của một hệ thống.
Có nhiều quan điểm khác nhau về việc có hay không các kiến trúc sư phần
mềm nên sử dụng UML để mô tả kiến trúc ( Clements và những người khác,
2002) . Khảo sát vào năm 2006 ( Lange và những người khác, 2006 ) cho
thấy, khi UML được sử dụng, nó hầu hết đã được áp dụng một cách lỏng lẻo


11

Chapter 6

■

Architectural design

và không chính thức. Các tác giả của bài báo đó cho rằng đó là một điều xấu.
Tôi không đồng ý với quan điểm này. UML được thiết kế để mô tả hệ thống
hướng đối tượng , và ở giai đoạn thiết kế kiến trúc , bạn thường muốn để
mô tả hệ thống ở mức trừu tượng cao hơn. Lớp đối tượng quá gần với việc
thực hiện để có ích cho việc mô tả kiến trúc.
Tôi không thấy sự có ích của UML trong quá trình thiết kế riêng của chính
nó và ở ghi chú chính thức mà là nhanh hơn để viết và có thể dễ dàng rút ra
trên một bảng trắng. UML là có giá trị nhất khi bạn đang ghi một kiến trúc
chi tiết hoặc sử dụng mô hình định hướng phát triển , như đã thảo luận ở
Chương 5.
Một số nhà nghiên cứu đã đề xuất việc sử dụng ngôn ngữ chuyên sâu hơn
mô tả kiến trúc ( ADLs ) ( Bass và những người khác, 2003 ) để mô tả kiến
trúc hệ thống. Các yếu tố cơ bản của ADLs là những thành phần và kết nối,

và chúng bao gồm các quy định và hướng dẫn cho các kiến trúc cũng như
hình thành. Tuy nhiên , vì tính chất chuyên môn của họ , các chuyên gia miền
và ứng dụng cảm thấy nó khó khăn để hiểu và sử dụng ADLs. Điều này làm
cho nó khó khăn để đánh giá tính hữu dụng của chúng cho công nghệ phần
mềm thực tế. ADLs thiết kế cho một tên miền cụ thể ( ví dụ , các hệ thống tự
động ) có thể được sử dụng như một cơ sở cho việc phát triển mô hình định
hướng.
Tên
Mô tả

Ví dụ

MVC (Mô hình – Quan điểm – Người điều khiển)
Tách bản trình bày và tương tác từ các dữ liệu hệ thống. Hệ thống được cấu trúc thành
ba thành phần hợp lý mà tương tác với nhau .
Các thành phần mô hình quản lý hệ thống dữ liệu và các hoạt động liên quan trên dữ liệu
đó . Định nghĩa thành phần quan điểm và quản lý như thế nào dữ liệu được trình bày đến
người dùng. Các thành phần điều khiển quản lý người dùng tương tác ( ví dụ: bàn phím,
con chuột , vv) và vượt qua những tương tác này cho quan điểm và các mô hình. Xem
Hình 6.3 .
Hình 6.4 cho thấy kiến trúc của một hệ thống ứng dụng web dựa trên tổ chức sử dụng mô
hình MVC .

Khi được sử dụng

Được sử dụng khi có rất nhiều cách để xem và tương tác với dữ liệu. Cũng được sử dụng
khi yêu cầu tương lai cho sự tương tác và trình bày các dữ liệu chưa được biết.

Ưu điểm

Cho phép các dữ liệu để thay đổi một cách độc lập đại diện của mình và ngược lại. Hỗ trợ
trình bày số liệu theo nhiều cách khác nhau với những thay đổi được thực hiện trong một
đại diện thể hiện trong tất cả chúng.

Nhược điểm

Có thể liên quan đến mã bổ sung và phức tạp mã khi các mô hình dữ liệu và tương tác rất
đơn giản

Hình 6.2 Bảng mô hình-quan điểm-người điều khiển(MVC)


12

Chapter 6

■

Architectural design

Tuy nhiên, tôi tin rằng mô hình chính thức và ký hiệu , chẳng hạn như UML ,
sẽ vẫn là cách thường được sử dụng nhất của tài liệu kiến trúc hệ thống.
Người sử dụng các phương pháp nhanh nhẹn cho rằng tài liệu hướng dẫn
thiết kế chi tiết chủ yếu là chưa sử dụng. Đây là một sự lãng phí thời giờ và
tiền bạc để phát triển nó. Tôi phần lớn đồng ý với quan điểm này và tôi nghĩ
rằng, đối với hầu hết các hệ thống, nó không đáng phát triển mô tả kiến trúc
chi tiết từ bốn quan điểm này.
Bạn nên phát triển các quan điểm mà có ích cho giao tiếp và không phải lo
lắng về việc có hay không tài liệu kiến trúc của bạn đã hoàn thành. Tuy
nhiên , một ngoại lệ là khi bạn đang phát triển hệ thống quan trọng , khi bạn

cần để thực hiện một phân tích chi tiết cậy của hệ thống. Bạn có thể cần phải
thuyết phục nhà quản lý bên ngoài mà hệ thống của bạn phù hợp với các
quy định của họ và để hoàn thành tài liệu kiến trúc có thể cần thiết.

6.3 Mô hình kiến trúc
Ý tưởng về mô hình như là một cách trình bày , chia sẻ và sử dụng lại các
kiến thức về các hệ thống phần mềm hiện nay được sử dụng rộng rãi . Việc
kích hoạt cho điều này là việc xuất bản một cuốn sách về các mẫu thiết kế
hướng đối tượng (Gamma et và những nươgi khác , 1995) ,mà nhắc sự phát
triển của các loại mô hình , chẳng hạn như mô hình thiết kế tổ chức
( Coplien và Harrison , 2004), mô hình khả năng sử dụng ( nhóm Usability,
1998) , tương tác (Martin và Sommerville , 2004) , quản lý cấu hình
( Berczuk và
Người điều khiển

Quan điểm

Lựa chọn
điểm
Bản đồ Người dùng Hành động đến mô hình Cập nhật
Chọnquan
Tầm Mô
nhìn
hình trả lại
Biến cố người dùng
Yêu cập nhật mô hình
Gửi biến cố người dùng để kiểm soát

Thông báo
thay đổi

Thay đổi trạng thái
Mô hình

Hình 6.3 Các tổ chức của
MVC

Đóng gói ứng dụng
trạng thái
Thông báo về việc theo dõi
thay đổi trạng thái

Truy vấn trạng thái


13

Chapter 6

■

Architectural design

Appleton, 2002 ), vân vân. mô hình kiến trúc được đề xuất trong những năm
1990 dưới tên ' phong cách kiến trúc ' ( Shaw và Garlan , 1996), với một loạt
năm khối lượng của sổ tay về kiến trúc phần mềm mô hình định hướng xuất
bản giữa năm 1996 và 2007 ( Buschmann và những người khác , 1996; .
Buschmann và những người khác, 2007a ; . Buschmann và những người
khác, 2007b ; . Kircher và Jain , 2004; Schmidt và những người khác. ,
2000) .
Ở phần này, Tôi giới thiệu mô hình kiến trúc và mô tả thật nhanh lựa

chọn kiểu mẫu kiến trúc thường được dùng trong các loại các hệ thống khác
nhau. Để biết thêm thông tin về mô hình và việc sử dụng chúng , bạn nên
tham khảo sách hướng dẫn mô hình xuất bản .
Bạn có thể nghĩ mô hình kiến trúc là một cách điệu hóa, trừu tượng mô tả về
thực hành tốt, đã được cố gắng thử nghiệm trong các hệ thống và môi trường
khác nhau. Vì vậy , một mô hình kiến trúc nên mô tả một hệ thống tổ chức đó
đã thành công trong các hệ thống trước đó. Nó sẽ bao gồm các thông tin khi
nó được và không thích hợp để sử dụng khuôn mẫu đó, và thế mạnh và điểm
yếu của mô hình .
Ví dụ, hình 6.2 mô tả các mô hình Mô hình-Quan điểm –Người điều khiển
nổi tiếng . Mô hình này là các cơ sở quản lý tương tác trong nhiều hệ thống
dựa trên web. Mô tả mô hình cách điệu bao gồm tên mẫu , một mô tả ngắn
gọn (với một mô hình đồ liên kết), và một ví dụ về các loại hệ thống mà các
mô hình được sử dụng (một lần nữa , có lẽ với một mô hình đồ họa) . Bạn
cũng nên bao gồm thông tin về việc khi các mô hình nên được sử dụng và
những ưu điểm và nhược điểm của nó. Mô hình đồ họa của kiến trúc kết hợp
với mô hình MVC được thể hiện trong hình 6.3 và 6.4. Những trình bày các
kiến trúc khác nhau từ quan điểm - Hình 6.3 là một cái nhìn khái niệm và
hình 6.4 cho thấy một kiến trúc thời gian chạy có thể khi mô hình này được
sử dụng để quản lý tương tác trong một hệ thống dựa trên web.
một
đoạn
ngắn
của bày
một
chương
nói
chung
,tốt.
nómẫu

là
thể
để
mô
tảTrong
tất
cảvề
các
mô
hình
có
thể
được
sử
dụng
trong
phát
triển
phần
mềm.
Thay
vào
đó,
tôichung
trình
một
số ví
dụ
chọn
các

mà
được
sử
dụng
rộng
rãi
và
được
chụp
nguyên
tắc
thiết
kế
kiến
trúc
Tôikhông
đã
bao
gồm
một
số
ví dụ
các
mô
hình
kiến
trúc
chung
trên
các

trang
web
của
cuốn
sách.


Hình 6.4
kiến trúc ứng dụng web
Browser
Controller
View
Form
to Generation
HTTP Request Processing
Dynamic
Application-Specific
Page
Logic Data Validation
Change
Update
Refresh
Model
sử dụng mô hình MVC
Business
Logic
Database
Display
FormsRequest
Management

Notification
Request

6.3.1 Kiến trúc
Userphân
Events lớp

Các khái niệm tách biệt và độc lập là nền tảng cho thiết kế kiến trúc , vì
chúng cho phép thay đổi được cục bộ. Các mô hình MVC, thể hiện trong hình
6.2, tách các yếu tố của một hệ thống , cho phép họ thay đổi một cách độc lập
. Ví dụ, thêm một quan điểm mới hay thay đổi một quan điểm hiện tại có thể
được thực hiện mà không có bất kỳ thay đổi dữ liệu cơ bản trong mô hình.
Các kiến trúc mô hình lớp là một cách khác để đạt được tách biệt và độc lập.
Mô hình này được thể hiện trong hình 6.5. Ở đây, các chức năng hệ thống
được tổ chức thành các lớp riêng biệt , và mỗi lớp chỉ dựa trên các thiết bị và
dịch vụ cung cấp bởi lớp ngay bên dưới nó.
Cách tiếp cận lớp này hỗ trợ sự phát triển gia tăng của hệ thống. Khi một
lớp được phát triển , một số các dịch vụ được cung cấp bởi lớp có thể được
cung cấp cho người sử dụng. Các kiến trúc cũng là thay đổi và di động . Vì
vậy, miễn là giao diện của nó là không thay đổi , một lớp có thể được thay
thế bởi một người khác , lớp tương đương. Hơn nữa , khi các giao diện lớp
thay đổi hoặc cơ sở mới được thêm vào một lớp , chỉ có lớp kế cận bị ảnh
hưởng. Khi các hệ thống lớp cục bộ máy phụ thuộc vào các lớp bên trong ,
điều này làm cho nó dễ dàng hơn để cung cấp triển khai nhiều hệ của một hệ
thống ứng dụng .
Chỉ có các lớp phụ thuộc bên trong, máy cần được thực hiện lại để lấy tài
khoản của các cơ sở của một hệ điều hành khác hoặc cơ sở dữ liệu .Hình 6.6
là một ví dụ về một kiến trúc nhiều tầng với bốn lớp . Các lớp thấp nhất bao

gồm phần mềm thường hỗ trợ hệ thống cơ sở dữ liệu và hệ điều hành hỗ
trợ . Lớp tiếp theo là lớp ứng dụng bao gồm các thành phần có liên quan với
các thành phần chức năng ứng dụng và tiện ích được sử dụng bởi các thành
phần ứng dụng khác. Lớp thứ ba có liên quan với giao diện người dùng
Name

Kiến trúc lớp

Mô tả

Tổ chức hệ thống thành các lớp với các chức năng liên quan kết hợp
với mỗi lớp . Một lớp cung cấp dịch vụ cho các lớp trên nó để các lớp
cấp thấp nhất đại diện cho các dịch vụ cốt lõi có khả năng được sử

Ví dụ

Một mô hình phân lớp trong một hệ thống chia sẻ tài liệu bản quyền tổ
chức tại thư viện khác nhau , như thể hiện trong hình 6.7.

Khi được sử
dụng

Được sử dụng khi xây dựng cơ sở mới trên đầu trang của các hệ thống
hiện có; khi phát triển được lan truyền trên một số đội với mỗi nhiệm
đội cho một lớp chức năng ; khi có một yêu cầu đối với an ninh đa cấp.

Ưu điểm

Cho phép thay thế toàn bộ các lớp miễn là giao diện được duy trì. cơ sở
vật chất dư thừa ( ví dụ , chứng thực ) có thể được cung cấp trong mỗi

lớp để tăng độ tin cậy của hệ thống.

Nhược điểm

Trong thực tế , cung cấp một lớp sạch giữa các lớp thường là khó khăn
và một lớp cấp cao có thể có tương tác trực tiếp với các lớp dưới hơn là
thông qua các lớp ngay bên dưới nó . Hiệu suất có thể là một vấn đề vì
nhiều cấp độ giải thích của một yêu cầu dịch vụ khi được xử lý tại mỗi

Hình 6.5 Các mô hình
kiến trúc phân lớp

quản lý và cung cấp xác thực người dùng và ủy quyền, với
các lớp trên cơ sở cung cấp giao diện người dùng. Tất nhiên
số lượng các lớp là tùy ý, bất kỳ của các lớp trong hình 6.6 có
thể được chia thành hai hoặc nhiều lớp
Hình 6.7 là một ví dụ về cách kiến trúc mô hình lớp này có
thể được áp dụng cho một hệ thống thư viện được gọi
LIBSYS , cho phép kiểm soát truy cập điện tử vào tài liệu
bản quyền từ một nhóm các thư viện trường đại học.
Điều này có một kiến trúc năm lớp , với lớp dưới cùng là
các cơ sở dữ liệu cá nhân trong mỗi thư viện . Bạn có thể
thấy một ví dụ về mô hình kiến trúc lớp trong hình 6.17
(tìm thấy trong phần 6.4 ). Điều này cho thấy các tổ chức
của hệ thống chăm sóc sức khoẻ tâm thần ( MHC - PMS )
mà tôi đã thảo luận trong chương trước


Hỗ trợ hệ thống hệ điều hành cơ sở dữ liệu, vv

Giao diện người dùng

Giao diện người dùng quản lý xác thực và ủy quyền

Lõi Logic kinh doanh / Ứng dụng chức năng hệ thống tiện ích

Hình 6.6 Một kiến trúc lớp

Giao diện trình duyệt web

Đăng nhập LIBSYS

Các hình thức và Trình quản lý In ấn
truy vấn quản lý

Phân phốiTruy xuất
Tìm kiếmTài liệu

Quyền giám đốc

Kế toán

Mục thư viện

Hình 6.7 Kiến trúc
của hệ thống
LIBSYS

DB3

DB1
DB2

DB4

DBn


6.3.2 Kho kiến trúc
CácHình
kiến
trúc
lớp
và mô Ví
hình
là những
ví dụ
của
môkho
hình( Hình
mà xem
làtả
tổ làm
chứcthế
khái
niệm
của
một
dụMVC
tiếp theo

của tôi
, mô
hình
6.8 giới
) , mô
6.8 Các môhệ thống.
hình kho
Phần lớn các hệ thống sử dụng một lượng lớn dữ liệu được tổ chức
xung quanh một cơ sở dữ liệu được chia sẻ hoặc kho. Do đó mô hình
này là phù hợp với các ứng dụng trong đó
Tên

Kho

Mô tả

Tất cả các dữ liệu trong một hệ thống được quản lý trong một kho lưu trữ
trung ương có thể truy cập đến tất cả các thành phần hệ thống . Các thành
phần không tương tác trực tiếp , chỉ thông qua các kho lưu trữ.

Ví dụ

Hình 6.9 là một ví dụ về một IDE nơi các thành phần sử dụng một kho lưu
trữ các thông tin thiết kế hệ thống. Mỗi công cụ phần mềm tạo ra các thông
tin mà sau đó có thể dùng cho các công cụ khác .

Khi sử dụng

Bạn nên sử dụng mô hình này khi bạn có một hệ thống trong đó khối lượng
lớn thông tin được tạo ra mà đã được lưu trữ trong một thời gian dài . Bạn

cũng có thể sử dụng nó trong các hệ thống điều khiển dữ liệu mà sự bao gồm
các dữ liệu trong kho gây ra một hành động hoặc công cụ .

Ưu điểm

Các thành phần có thể độc lập , họ không cần phải biết về sự tồn tại của các
thành phần khác . Những thay đổi được thực hiện bởi một thành phần có thể
được lan truyền đến tất cả các thành phần. Tất cả các dữ liệu có thể được quản
lý thống nhất ( ví dụ , các bản sao lưu được thực hiện cùng một lúc ) vì nó là tất
cả ở một nơi.
Các kho lưu trữ là một điểm duy nhất của thất bại vì vậy vấn đề trong kho
lưu trữ ảnh hưởng đến toàn bộ hệ thống . Có thể là không hiệu quả trong
việc tổ chức tất cả các thông tin liên lạc thông qua các kho lưu trữ. Phân
phối các kho lưu trữ trên một số máy tính có thể khó khăn .

Nhược điểm


Biên tập ULM

Trình tạo mã
Người biên tập java

Người dịch thiết kế

Kho chứa dự án
Biên tập python
Máy phân tích thiết kế

Bộ tạo bản báo cáo

Figure 6.9 A repository
architecture for an IDE

dữ liệu được tạo ra bởi một thành phần và sử dụng khác.. Ví dụ về các loại hệ thống này
bao gồm các lệnh và kiểm soát hệ thống , hệ thống thông tin quản lý , hệ thống CAD , và
môi trường phát triển tương tác với phần mềm.
Hình 6.9 là một ví dụ về một tình huống trong đó một kho lưu trữ có thể được sử
dụng. Biểu đồ này cho thấy một IDE bao gồm các công cụ khác nhau để hỗ trợ phát
triển mô hình định hướng. Các kho lưu trữ trong trường hợp này có thể là một môi
trường phiên bản kiểm soát ( như đã thảo luận ở chương 25 ) mà theo dõi những thay
đổi phần mềm và cho phép cuộn trở lại với phiên bản trước.
Tổ chức các công cụ xung quanh một kho lưu trữ là một cách hiệu quả để chia sẻ một
lượng lớn dữ liệu .Không cần để truyền tải dữ liệu một cách rõ ràng từ một thành phần
khác. Tuy nhiên , các thành phần phải hoạt động xung quanh một mô hình dữ liệu kho lưu
trữ thống nhất. Chắc chắn , đây là một sự thỏa hiệp giữa các nhu cầu cụ thể của từng
công cụ và nó có thể khó khăn hoặc không thể tích hợp các thành phần mới nếu các mô
hình dữ liệu của họ không phù hợp với sơ đồ thống nhất. Trong thực tế , nó khá khó khăn
để phân phối các kho lưu trữ trên một số máy. Mặc dù nó có thể phân phối một kho lưu
trữ hợp lý tập trung , có thể có vấn đề với dữ liệu dự phòng và không thống nhất .
Trong ví dụ thể hiện trong hình 6.9, các kho là thụ động và kiểm soát là trách nhiệm của
các thành phần sử dụng kho. Một phương pháp khác , mà đã được đặt cho hệ thống AI ,
sử dụng một mô hình ' bảng đen ' kích hoạt các thành phần khi dữ liệu cụ thể trở nên có
sẵn. Điều này là phù hợp khi các hình thức của dữ liệu lưu trữ được cấu trúc ít được. Các
quyết định về những công cụ để kích hoạt chỉ có thể được thực hiện khi dữ liệu đã được
phân tích. Mô hình này được giới thiệu bởi Nii ( 1986 ).
Bosch ( 2000) bao gồm một cuộc thảo luận về phong cách này liên quan đến các thuộc
tính chất lượng hệ thống.
6.3.3 Kiến trúc khách chủ
Các mô hình kho là có liên quan với cấu trúc tĩnh của một hệ thống

và không thể hiện tổ chức thời gian chạy của nó.


Ví dụ tiếp theo của tôi minh họa một tổ chức thời gian chạy rất
thường được sử dụng cho các hệ thống phân phối. Các mô hình
khách-chủ được mô tả trong hình 6.10
Tên

Khách – chủ

Mô tả

Trong một kiến trúc client-server , các chức năng của hệ thống được tổ chức vào
các dịch vụ , với mỗi dịch vụ chuyển giao từ một máy chủ riêng biệt . Khách hàng
là người sử dụng các dịch vụ và máy chủ truy cập để sử dụng chúng .

Ví dụ

Hình 6.11 là một ví dụ về một thư viện phim và video / DVD được tổ chức
như một hệ thống client-server .

Khi sử dụng

Được sử dụng khi dữ liệu trong cơ sở dữ liệu dùng chung đã được truy cập
từ một loạt các địa điểm . Bởi vì máy chủ có thể được nhân rộng, cũng có thể
được sử dụng khi tải trên một hệ thống có thể thay đổi .

Ưu điểm

Ưu điểm chính của mô hình này là các máy chủ có thể được phân phối qua

mạng . chức năng chung ( ví dụ , một dịch vụ in ấn) có thể có sẵn cho tất cả
khách hàng và không cần phải được thực hiện bởi tất cả các dịch vụ

Nhược điểm

Mỗi dịch vụ là một điểm của thất bại rất dễ bị mắc bệnh đến tấn công từ
chối dịch vụ hay thất bại server. Việc thực hiện có thể là không dự đoán
được vì cái đó còn tùy vào mạng cũng như hệ thống. Có thể là vấn đề quản lý
nếu các server thuộc quyền sở hữu của tổ chức khác.

Figure 6.10 Mô hình
client-server

Một hệ thống theo mô hình client-server được tổ chức như một tập hợp các dịch vụ
và máy chủ có liên quan , và khách hàng truy cập và sử dụng các dịch vụ. Các thành
phần chính của mô hình này là:
1. Một tập hợp các máy chủ cung cấp dịch vụ cho các thành phần khác . Ví dụ về
các máy chủ bao gồm các máy chủ in ấn cung cấp dịch vụ in ấn , máy chủ tập
tin cung cấp dịch vụ tệp quản lý , và một máy chủ biên dịch, trong đó cung cấp
các dịch vụ tổng hợp ngôn ngữ lập trình .
2.

Tập hợp các khách hàng yêu cầu dịch vụ đề xuất bởi các server. Bình thường
sẽ có trường hợp của chương trình khách hàng thi hành đồng thời trên máy
tính khác.

3. Một mạng cho phép các khách hàng để truy cập vào các dịch vụ này . Hầu hết
các hệ thống client-server được thực hiện như hệ thống phân phối , kết nối
bằng giao thức Internet .

Kiến trúc client-server thường được coi là hệ thống phân phối các cấu trúc nhưng
mô hình hợp lý của các dịch vụ độc lập chạy trên các máy chủ riêng biệt có thể được
thực hiện trên một máy tính duy nhất. Một lần nữa , một lợi ích quan trọng là tách
biệt và độc lập . Dịch vụ và máy chủ có thể được thay đổi mà không ảnh hưởng đến
các bộ phận khác của hệ thống.
Khách hàng có thể phải biết tên của các máy chủ có sẵn và các dịch vụ mà họ cung
cấp. Tuy nhiên , các máy chủ không cần biết danh tính của khách hàng hoặc có bao
nhiêu khách hàng đang truy cập vào dịch vụ của họ Khách hàng truy cập các dịch vụ
được cung cấp bởi một máy chủ thông qua thủ tục từ xa các cuộc gọi sử dụng một


giao thức yêu cầutrả lời như http


Khách
Khách
1 Khách
2 Khách
3 4
Mạng
internet
Danh mục
Video
máy
Máy
sever
chủ
Máy
chủ chủ
ảnh

Hàng
CCửa
phim
hàng
ảnhweb
Hình 6.11 Kiến trúc
Danh mục thư
Thông
việntin phim và ảnh
chủ-khách cho thư
viện phim
Khách
Khách
1Khách
2Khách
3 4
Mạng
internet
Mục lục
máy
Video
Picture
chủStore
Web
Film
Photo
Store
Danh mụcServer
thư
Server

viện
Server
Film
and Photo
Info. trong WWW. Về cơ bản , một khách hàng làm cho một yêu
giao thức
được
sử dụng

cầu đến máy chủ và chờ đợi cho đến khi nó nhận được một câu trả lời

Figure 6.12 The pipe
and filter pattern

Hình 6.11 là một ví dụ về một hệ thống được dựa trên mô hình client-server. Đây là hệ
đa người dùng, hệ thống qua Internet để cung cấp thư viện phim và chụp ảnh. Trong
hệ thống này , một số máy chủ quản lý và hiển thị các loại khác nhau của các phương
tiện truyền thông. Khung hình video cần phải được truyền một cách nhanh chóng và
đồng bộ nhưng ở độ phân giải tương đối thấp. Họ có thể được nén trong một cửa
hàng , vì vậy các máy chủ video có thể xử lý video nén và giải nén định dạng khác
nhau. Tuy nhiên hình ảnh, tuy nhiên , phải được duy trì ở độ phân giải cao , vì vậy nó
rất thích hợp để duy trì chúng trên một máy chủ riêng biệt .
Các cửa hàng phải có khả năng để đối phó với một loạt các truy vấn và cung cấp
các liên kết vào hệ thống thông tin web bao gồm các dữ liệu về bộ phim và video
clip, và một hệ thống thương mại điện tử hỗ trợ việc bán hình ảnh , phim ảnh, và
video clip.

Tên

Ống và bộ lọc

Mô tả

Việc xử lý các dữ liệu trong một hệ thống được tổ chức để mỗi thành phần xử lý ( lọc) là rời
rạc và thực hiện một loại hình chuyển đổi dữ liệu. chảy dữ liệu ( như trong một ống ) từ một
thành phần khác để xử lý.

Ví dụ

Hình 6.13 là một ví dụ về một hệ thống đường ống và lọc được sử dụng cho các hóa đơn
chế biến

Khi sử dụng

Thường được dùng trong ứng dụng xử lý dữ liệu nơi dữ liệu nhập vào được xử lý trong
giai đoạn riêng biệt để tạo ra đầu ra liên quan.

Ưu điểm

Dễ hiểu và hỗ trợ tái sử dụng chuyển đổi. phong cách công việc phù hợp với cấu trúc của
nhiều quy trình kinh doanh . Sự tiến hóa bằng cách thêm biến đổi là đơn giản. Có thể được
thực hiện như hoặc là một hệ thống tuần tự hoặc đồng thời .

Nhược điểm

Các định dạng để chuyển dữ liệu phải được thoả thuận giữa biến đổi giao tiếp. Mỗi chuyển
đổi phải phân tích đầu vào của nó và bỏ phân tích đầu ra của nó với hình thức thỏa thuận.
Điều này làm tăng hệ thống trên không và có nghĩa rằng nó không thể tái sử dụng biến đổi
chức năng sử dụng các cấu trúc dữ liệu không tương thích.

Biên nhận vấn đề

Đọc hóa đơn

Biên nhận

Xác định thanh toán

Tìm thuế thanh toán Thanh toán vấn về nhắc nhở
Hóa đơn

Nhắc nhở

Thanh toán

Hình 6.13
Một ví dụ của kiến
trúc đường ống và bộ
lọc

Chương trình khách hàng chỉ đơn giản là một giao diện người dùng
tương tác , xây dựng sử dụng một trình duyệt web , để truy cập các
dịch vụ này . Lợi thế quan trọng nhất của mô hình khách-chủ là nó là
một kiến trúc phân tán.
Sử dụng hiệu quả có thể được thực hiện trong hệ thống mạng với
nhiều bộ xử lý phân tán.
Nó rất dễ dàng để thêm một máy chủ mới và tích hợp nó với phần còn
lại của hệ thống hoặc nâng cấp máy chủ rõ ràng mà không ảnh hưởng
đến các bộ phận khác của hệ thống.

Tôi thảo luận về kiến trúc phân tán, trong đó có kiến trúc khách-chủ
và phân phối những kiến trúc kiến trúc , trong Chương 18 .


6.3.4 Ống và kiến trúc bộ lọc

Ví dụ cuối cùng của tôi về một mô hình kiến trúc là mô hình đường ống và bộ
lọc.Đây là một mô hình của các tổ chức thời gian chạy của một hệ thống mà
biến đổi chức năng xử lý đầu vào và đầu ra sản phẩm. Luồng dữ liệu từ một
đến khác và được xuyên hình thành khi nó di chuyển qua các trình tự. Mỗi
bước xử lý được thực hiện như một biến đổi. Dữ liệu đầu vào chảy qua
những biến đổi cho đến khi chuyển đến đầu ra. Các phép biến đổi có thể thực
hiện tuần tự hoặc song song.
Các dữ liệu có thể được xử lý bởi mỗi mục chuyển đổi theo khoản mục hoặc
trong một đợt duy nhất.
Tên ' đường ống và bộ lọc ' đến từ hệ thống Unix gốc, nơi nó đã có thể liên
kết các quá trình sử dụng ' ống ' . Những thông qua một dòng văn bản từ
một quá trình khác. Hệ thống cho phù hợp với mô hình này có thể được thực
hiện bằng cách kết hợp các lệnh Unix , sử dụng đường ống và các thiết bị
kiểm soát của vỏ Unix. Thuật ngữ " bộ lọc " được sử dụng bởi vì một biến đổi
' lọc ra ' dữ liệu nó có thể xử lý từ dòng dữ liệu đầu vào của nó .
Các biến thể của mô hình này đã được sử dụng từ các máy tính lần đầu
tiên được sử dụng để xử lý dữ liệu tự động. Khi biến đổi là tuần tự với dữ
liệu xử lý theo lô , đường ống này và lọc mô hình kiến trúc trở thành một mô
hình tuần tự hàng loạt, một kiến trúc chung cho các hệ thống xử lý dữ liệu
( ví dụ , một hệ thống thanh toán ). Kiến trúc của một hệ thống nhúng cũng
có thể được tổ chức như một đường ống dẫn quy trình, với mỗi quá trình
thực hiện đồng thời. Tôi thảo luận về việc sử dụng các mô hình này trong các
hệ thống nhúng trong Chương 20.
Một ví dụ của loại kiến trúc hệ thống , được sử dụng trong một ứng dụng

xử lý hàng loạt , được thể hiện trong hình 6.13. Một tổ chức đã phát hành
hoá đơn cho khách hàng. Mỗi tuần một lần , thanh toán đã được thực hiện
được hòa giải với các hoá đơn.


Mô hình kiến trúc cho kiểm soát

Có mô hình kiến trúc cụ thể phản ánh những cách thường được sử dụng để tổ chức kiểm
soát trong một hệ thống . Chúng bao gồm các điều khiển tập trung , dựa trên một thành
phần gọi các thành phần khác , và điều khiển dựa trên sự kiện , nơi mà hệ thống phản ứng
với các sự kiện bên ngoài.
/>
Đối với những hoá đơn đã được thanh toán, hóa đơn được phát hành. Đối với những hoá
đơn chưa được thanh toán trong thời gian thanh toán cho phép , một lời nhắc nhở được
ban hành. Hệ thống tương tác rất khó để sử dụng viết mô hình đường ống và bộ lọc bởi vì
sự cần thiết cho một dòng dữ liệu được xử lý. Mặc dù đầu vào văn bản đơn giản và đầu ra
có thể được mô tả theo cách này , giao diện người dùng đồ họa có I / O các định dạng
phức tạp hơn và một chiến lược kiểm soát đó là dựa trên các sự kiện như cú click chuột
hoặc lựa chọn menu. Nó rất khó dịch thành một dạng tương thích với mô hình dây
chuyền .

6.4 Kiến trúc ứng dụng
Hệ thống ứng dụng nhằm đáp ứng một doanh nghiệp hoặc nhu cầu của tổ chức. Tất
cả các ngành kinh doanh có nhiều điểm chung , họ cần phải thuê người, xuất hoá đơn ,
giữ tài khoản , vv. Các doanh nghiệp hoạt động trong ngành cùng sử dụng các ứng
dụng cụ thể khu vực chung. Do đó , cũng như các chức năng kinh doanh nói chung , tất
cả các công ty điện thoại cần hệ thống để kết nối cuộc gọi , quản lý mạng lưới của họ ,
hóa đơn phát hành cho khách hàng, vv. Do đó , các hệ thống ứng dụng được sử dụng
bởi các doanh nghiệp này cũng có nhiều điểm chung .

Những điểm tương đồng đã dẫn đến sự phát triển của kiến trúc phần mềm mô tả cấu
trúc và tổ chức các loại hình cụ thể của hệ thống phần mềm. Kiến trúc ứng dụng đóng gói
các đặc tính chủ yếu của một lớp các hệ thống. Ví dụ , trong các hệ thống thời gian thực ,
có thể có mô hình kiến trúc chung của các loại hệ thống khác nhau , chẳng hạn như hệ
thống thu thập dữ liệu hoặc hệ thống giám sát.
Mặc dù trường hợp của các hệ thống khác nhau về chi tiết, kết cấu kiến trúc thông
thường có thể được tái sử dụng khi phát triển hệ thống mới cùng loại.
Các kiến trúc ứng dụng có thể được tái thực hiện khi phát triển hệ thống mới, nhưng
đối với nhiều hệ thống kinh doanh , ứng dụng tái sử dụng là có thể mà không thực hiện
lại. Chúng tôi thấy điều này trong sự phát triển của hoạch định tài nguyên doanh nghiệp (
ERP ) hệ thống từ các công ty như SAP và Oracle , và các gói phần mềm dọc ( COTS ) cho
các ứng dụng chuyên ngành trong các lĩnh vực kinh doanh khác nhau. Trong hệ thống


này, một hệ thống chung được cấu hình và điều chỉnh để tạo ra một ứng dụng kinh doanh
cụ thể.