Công nghệ phần mềm ôn tập chương 6

Software Architecture Design
Chủ đề bao gồm :
o
o
o
o

Các quyết định thiết kế kiến trúc ( Architecture Design Decisions )
Các quan điểm về kiến trúc ( Architecture Views )
Các mơ hình kiến trúc ( Architecture patterns )
Kiến trúc ứng dụng ( Application architectures)

1. Software Architecture : là kế hoạch chi tiết cho một xây dựng và phát triển hệ
thống phần mềm , là các tổ chức cơ bản của một hệ thống , thể hiện trong các
thành phần của nó , các mối quan hệ của các tổ chức với nhau và môi trường , và
các nguyên tắc điều chỉnh thiết kế và phát triển tổ chức và là những gì kiến trúc sư
phần mềm phải làm .
a. Architecture Design : là quá trình thiết kế cho việc xác định các sub-systems
tạo nên 1 hệ thống ( system ) và framwork cho việc điều khiển và truyền các
thông tin liên lạc giữa các sub-systems( hệ thống con )
Kết quả đạt được của quá trình thiết kế ( design proccess ) là 1 bản mơ tả
cho Software Architecture .
b. Tính chất của Architecture Design :
Là giai đoạn đầu của thiết kế hệ thống ( the system design proccess )
Đại diện cho mối liên hệ giữa đặc tả kỹ thuật và quá trình thiết kế .
Thường thì tiến hành song song với 1 vài hoạt động đặc tả kỹ thuật
Bao gồm ( liên quan ) đến việc xác định thành phần hệ thống quan
trọng và thơng tin liên lạc giữ các thành phần đó .


c. Cần phải có Software Architecture vì :

Giống như bất kỳ cấu trúc phức tạp khác, phần mềm phải được xây
dựng trên một nền tảng vững chắc.
Hệ thống cần được thiết kế với việc xem xét cho người sử dụng, hệ
thống (cơ sở hạ tầng CNTT), và các mục tiêu kinh doanh. Đối với
mỗi lĩnh vực, chúng ta cần có bản phác thảo chính và xác định các
thuộc tính quan trọng
Kiến trúc tập trung vào cách các yếu tố chính và các thành phần trong
một ứng dụng được sử dụng , hoặc tương tác với các yếu tố lớn khác
và các thành phần bên trong ứng dụng. chúng ta có thể xây dựng các
giải pháp kiến trúc nhằm giải quyết tất cả các vấn đề có liên quan, có
thể được triển khai trên cơ sở hạ tầng của bạn lựa chọn, và cung cấp
kết quả đáp ứng các mục tiêu và mục tiêu ban đầu .
2. Architectural abstraction (trừu tượng hóa kiến trúc ): Kiến trúc cho các phần mềm
sử dụng trừu tượng hóa phong phú để mơ tả các thành phần hệ thống, bản chất của
sự tương tác giữa các thành phần, và các mơ hình để hướng dẫn các thành phần
của các thành phần vào hệ thống. Các khái niệm trừu tượng cao cấp hơn so với các
yếu tố thường được hỗ trợ bởi ngơn ngữ lập trình và các công cụ. Các khái niệm


trừu tượng được sử dụng trong thực hành bởi nhà thiết kế phần mềm. Nó phân biệt
khác nhau giữa các loại thành phần và cách thức khác nhau các thành phần này có
thể tương tác . Hỗ trợ thực hiện các khía cạnh cao cấp như khía cạnh cao cấp của
hệ thống như tổ chức tổng thể, phân hủy thành các thành phần , phân công chức
năng cho các thành phần, và cách các thành phần tương tác.
a. Đối với các kiến trúc nhỏ : có liên quan với kiến trúc của các chương trình cá
nhân. Ở cấp độ này, chúng tơi quan tâm với cách mà một chương trình cá
nhân bị phân hủy thành các thành phần.
b. Đối với các kiến trúc lớn : là quan tâm đến kiến trúc của hệ thống doanh
nghiệp phức tạp bao gồm các hệ thống khác, các chương trình, và các thành
phần chương trình. Các hệ thống doanh nghiệp được phân phối trên các máy

tính khác nhau, có thể được sở hữu và các công ty khác nhau quản lý.
3. Decomposition ( Phân hủy ) OR Modularizing: Đề cập đến quá trình hệ thống
được chia thành các phần từ đó dễ dàng hơn để hiểu chương trình, và duy trì hoặc
hệ thống ( độ phức tạp cao ) = tập hợp các chương trình nhỏ ( ít phức tạp )
a. Mục tiêu :
Tối đa hóa sự gắn kết
Hạn chế tối đa khớp nối ( coupling )
Cohesion : mức độ thông tin
liên lạc giữa các yếu tố đưa
ra của module.
Coupling : mức độ giao tiếp
giữa các module

4. Begin Selecting a Basic Architecture :


a. B1: Xây dựng mơ hình mental của các ứng dụng cấp cao như thể nó là ứng
dụng nhỏ .
Ví dụ : ứng dụng tài chính cá nhân : hoạt động bằng cách nhận các khoản
tiền hoặc trả bằng tiền mặt , theo thứ tự , kiểm sốt thơng qua một giao diện
người dùng .
Metal model : có thể hiểu là mơ hình đại diện của thực tế mà mọi
người sử dụng để hiểu các hiện tượng cụ thể , ở đây là mơ hình đại
diện cho các ứng dụng cấp cao để có thể hiểu rõ các về các ứng dụng
này .
b. B2: Phân hủy thành các thành phần cần thiết : tìm sự liên kết cao ( high
cohesion ) và low coupling .
Ví dụ : ứng dụng tài chính cá nhân : phân hủy ( phân chia ) thành tài sản ,
nhà cung cấp và giao diện .
c. B3: lặp lại quá trình này cho các thành phần .

5. Advantages of explicit architecture ( ưu điểm của kiến trúc rõ ràng ) :
a. Stakeholder communication ( thông tin liên lạc giữa các bên liên quan ) :
Kiến trúc có thể được sử dụng như là tiêu điểm của cuộc thảo luận của các
bên liên quan đến hệ thống .
b. System analysis ( phân tích hệ thống ) : phân tích xem liệu hệ thống có thể
đáp ứng u cầu phi chức năng của nó hay khơng ?
c. Large – scale reuse ( tái sử dụng quy mô lớn ) : Các kiến trúc có thể được tái
sử dụng trong một loạt các hệ thống .
6. Architectural representations ( kiến trúc đại diện ) : đại diện cho kiến trúc phần
mềm là rất quan trọng, bởi vì các đại diện sẽ ảnh hưởng như thế nào kiến trúc
phục vụ như một phương tiện truyền thơng, như thế nào nó chuyển tải quyết định
thiết kế ban đầu, và cách chính xác nó mơ tả trừu tượng quan trọng của hệ thống.


Như vậy, rõ ràng, đầy đủ, và độ chính xác của các đại diện kiến trúc có tầm quan
trọng then chốt.
Nói 1 cách đơn giản : sơ đồ khối khơng chính thức cho thấy các thực thể và
các mối quan hệ là phương pháp thường được sử dụng cho tài liệu kiến trúc
phần mềm. Tuy nhiên, những điều này đã bị chỉ trích vì thiếu ngữ nghĩa,
khơng hiển thị các loại mối quan hệ giữa các thực thể cũng không nhìn thấy
được của các đơn vị trong kiến trúc. Phụ thuộc vào việc sử dụng mơ hình
kiến trúc. Các u cầu đối với ngữ nghĩa mơ hình phụ thuộc vào các mơ
hình được sử dụng.
Cần phải có Kiến trúc đại diện cho kiến trúc phần mềm .
7. Box and line diagrams : Rất là trừu tượng , sơ đồ này không hiển thị bản chất của
mối quan hệ thành phần cũng như các thuộc tính bên ngồi có thể nhìn thấy của
các Sub – Systems . Tuy nhiên, sơ đồ này khá hữu ích cho việc giao tiếp với các
bên liên quan và lập kế hoạch cho dự án.
8. Use of architectural models ( Sử dụng các mơ hình kiến trúc ) vì :
a. Như một cách để tạo điều kiện thảo luận về thiết kế hệ thống

b. 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 việc giao
tiếp với các bên liên quan hệ thống và lập kế hoạch dự án bởi vì các chi tiết
được thể hiện rõ ràng không lộn xộn , rối rắm . Các bên liên quan hiểu 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 các chi tiết cụ thể .
c. Như một cách để ghi lại một kiến trúc đã được thiết kế .
d. Mục đích ở đây là để tạo ra một mơ hình hệ thống hồn chỉnh cho thấy các
thành phần khác nhau trong một hệ thống, giao diện và kết nối của các thành
phần đó .
9. Architectural design decisions ( các quyết định thiết kế kiến trúc ) : Thiết kế kiến
trúc là một quá trình sáng tạo nên quá trình này khác nhau tùy thuộc vào loại hệ


thống được phát triển.Tuy nhiên, một số quyết định chung rộng ra tất cả các quá
trình thiết kế và những quyết định ảnh hưởng đến những đặc tính phi chức năng
của hệ thống.
a. Lý do có các quyết định kiến trúc này : Một kiến trúc phần mềm có thể được
coi là tập hợp các quyết định quan trọng liên quan đến việc thiết kế các phần
mềm của một hệ thống. Kiến thức về thiết kế này, tức là kiến thức kiến trúc,
là chìa khóa cho sự hiểu biết một kiến trúc phần mềm và do đó bản thân
phần mềm. Kiến thức kiến trúc chủ yếu chỉ tồn tại trong đầu của những
người sáng tạo. Một vấn đề là loại kiến thức có thể dễ dàng bị mất .Để giải
quyết vần đề này cần tập trung vào một hình thức quan trọng của kiến trúc:
các quyết định thiết kế kiến trúc ( Architectural design decisions ) . Hình
thức này rất là quan trọng, là quá trình kiến trúc , là tất cả về việc đưa ra
những quyết định quan trọng.
b. Một khi đã hệ thống hóa, một kiến trúc phần mềm có thể được xem như là
tập hợp các quyết định kiến trúc (thiết kế). Đặt một kiến trúc phần mềm vào
một viễn cảnh mới và làm sâu sắc thêm sự hiểu biết của các bên liên quan.
Như công việc tương lai, chúng ta sẽ có kế hoạch để điều tra các loại kiến

thức cần cho kiến trúc và mối quan hệ của các kiến thức để quyết định thiết
kế kiến trúc .
c. Khi đưa ra các quyết định kiến trúc ta có thể xem xét các câu hỏi sau :
Làm thế nào hệ thống sẽ được phân phối?
Những phong cách kiến trúc nào là phù hợp?
Phương pháp gì sẽ được sử dụng để cấu trúc hệ thống?
Làm thế nào hệ thống sẽ được chia ra thành các mô-đun?
Chiến lược kiểm sốt gì nên được sử dụng?
Làm thế nào để đánh giá thiết kế kiến trúc?
Nên tạo document cho kiến trúc như thế nào ?
10.

Architecture reuse (tái sử dụng kiến trúc ) :


a. Hệ thống trong cùng một tên miền thường có kiến trúc tương tự như phản
chiếu bản chất của tên miền đó . ( tạo nét đặc trưng riêng )
b. Những dòng sản phẩm ứng dụng được xây dựng dựa trên một kiến trúc cốt
lõi với các biến thể ( biến thể ở đây là các thứ bên cạnh có khả năng tiện
dụng , dễ dàng thay đổi ) đáp ứng yêu cầu của khách hàng cụ thể.
c. Các kiến trúc của một hệ thống có thể được thiết kế theo một trong những
mơ hình kiến trúc hoặc phong cách kiến trúc khác .
Những phải nắm được bản chất của kiến trúc và có thể được khởi tạo
trong cách khác nhau.
11.
):

Architecture and system characteristics ( các đặc điểm kiến trúc và hệ thống

a. Hiệu suất : Xác định các hoạt động quan trọng và giảm thiểu thông tin liên

lạc.
b. Bảo mật : Sử dụng một kiến trúc lớp với tài nguyên quan trọng trong các lớp
bên trong.
c. An toàn : Xác định các tính năng an tồn - quan trọng trong một số ít các hệ
thống phụ.
d. Sẵn sàng : Bao gồm các thành phần và cơ chế cho khả năng chịu lỗi khơng
cần thiết.
e. Bảo trì : Sử dụng thành phần thay thế.
12.
Choosing an Architecture ( chọn kiến trúc như thế nào ) :


Chọn kiến trúc 1 vì tổng điểm cao nhất

13.
Architectural views ( Quan điểm kiến trúc ) : Để có thể đưa ra các quan điểm
kiến trúc hợp lý ta cần trả lời được các câu hỏi sau :
a. Những quan điểm nào hay các quan điểm rất hữu ích khi thiết kế và lập tài
liệu kiến trúc của hệ thống?
b. Những ký hiệu nên được sử dụng để mô tả mơ hình kiến trúc?
c. Mỗi mơ hình kiến trúc chỉ cho thấy một cái nhìn hay quan điểm của hệ
thống.
Nó có thể hiển thị như thế nào một hệ thống được phân rã thành các
mô-đun, làm thế nào các quá trình thời gian chạy tương tác hoặc
những cách khác nhau, trong đó các thành phần hệ thống được phân
phối qua mạng. Đối với cả hai thiết kế và tài liệu hướng dẫn, bạn
thường cần phải trình bày nhiều quan điểm của kiến trúc phần mềm
 4+1 view model of software architecture gồm Bốn điểm là hợp lý ( logical view
) , phát triển( development view ), quá trình( process view ) và vật lý( physical
view ) . Ngoài ra lựa chọn use cases or scenarios được sử dụng để minh họa

cho kiến trúc như là “+1” view :


o A logical view : Quan điểm hợp lý liên quan đến các chức năng mà hệ
thống cung cấp cho người dùng cuối và cho thấy các khái niệm trừu tượng
quan trọng trong hệ thống như các đối tượng hoặc các lớp đối tượng.
Biểu đồ UML được sử dụng để đại diện cho quan điểm hợp lý bao gồm
Class diagram , Communication diagrams , Sequence diagram
o A process view : Quan điểm q trình với các khía cạnh động của hệ
thống, bao gồm các q trình tương tác, giải thích các quy trình hệ thống
và cách nó giao tiếp, và tập trung vào các hành vi thời gian chạy của hệ
thống. Quan điểm quá trình giải quyết đồng thời, phân phối, tích hợp, hiệu
suất và khả năng mở rộng, ,v.v… Biểu đồ UML để đại diện cho quan
điểm quá trình bao gồm các Activity diagram .
o A development view : Quan điểm phát triển minh họa một hệ thống từ
quan điểm của một lập trình viên và liên quan đến phần mềm quản lý hay
nói cách khác là tách ra để phát triển . Nó sử dụng UML Component
diagram để mô tả các thành phần hệ thống. Biểu đồ UML được sử dụng
để đại diện cho quan điểm phát triển bao gồm các Package diagram .
o A physical view : : Quan điểm vật lý mô tả các hệ thống từ một kỹ sư hệ
thống , cho thấy các hệ thống phần cứng và làm thế nào 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 . Nó liên
quan với các cấu trúc liên kết của các thành phần phần mềm trên lớp vật
lý, cũng như các kết nối vật lý giữa các thành phần này. Quan điểm này
cũng được biết đến như là điểm triển khai. Biểu đồ UML được sử dụng để
đại diện cho quan điểm vật lý bao gồm các Deployment diagram .
 Use-case or Scenarios : Các mô tả của một kiến trúc được minh họa bằng một
tập nhỏ các use-case , hoặc Scenarios mà trở thành một điểm thứ năm. Các
Scenarios mơ tả trình tự của các tương tác giữa các đối tượng, và giữa các quá
trình. Chúng được sử dụng để xác định các yếu tố kiến trúc và để minh họa và

xác nhận thiết kế kiến trúc. Nó cũng phục vụ như là một điểm khởi đầu cho các
bài kiểm tra của một nguyên mẫu kiến trúc. Quan điểm này cũng được biết đến


như sử dụng use-case .
14.
a.
b.
c.
d.
15.

Architectural patterns ( Mơ hình kiến trúc ) :
Pattern ( Mơ hình ) là một phương tiện đại diện, chia sẻ và tái sử dụng kiến
thức.
Một mơ hình kiến trúc là một mơ tả cách điệu của thực hành thiết kế tốt, đã
được thử và thử nghiệm trong mơi trường khác nhau.
Các mơ hình nên bao gồm thơng tin về khi họ đang có và khi khơng hữu ích.
Các mơ hình có thể được đại diện bằng cách sử dụng bảng và mô tả đồ họa.
The Model-View-Controller (MVC) pattern :
Ngăn cách trình bày và tương tác từ hệ thống dữ liệu. Hệ thống này được kết cấu
thành ba thành phần logic 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 đến dữ liệu đó. Các thành phần View xác
đị nh và quản lý như thế nào dữ liệu được trình bày cho người dùng. Các thành phần
điều khiển quản lý tương tác người dùng (ví dụ, bấm phím, con chuột nhấp chuột,
v..v….) và vượt qua được những tương tác cho View và Model.
Ví dụ bên dưới 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
bằng cách sử dụng mơ hình MVC.
Được sử dụng khi có nhiều cách để xem và tương tác với dữ liệu. Cũng được sử
dụng khi các yêu cầu tương lai cho sự tương tác và trình bày các dữ liệu khơng rõ.

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 của cùng một dữ liệu theo những 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
Có thể liên quan đến việc bổ sung mã và mã phức tạp khi mà mô hình dữ liệu và tương tác rất
đơn giản.


16.
MVC pattern : là một mơ hình phần mềm để thực hiện các giao diện người
dùng . Nó chia một phần mềm ứng dụng cho thành ba phần liên kết với nhau, để
phân biệt đại diện nội bộ của thông tin từ những cách mà thơng tin được trình bày
hoặc được chấp nhận từ người sử dụng. Các thành phần trung tâm, mơ hình, bao
gồm các dữ liệu ứng dụng , quy tắc kinh doanh, logic, và các chức năng. Một quan
điểm có thể là đại diện đầu ra của thông tin, chẳng hạn như một biểu đồ hoặc một
sơ đồ. Nhiều quan điểm của các thông tin tương tự có thể xảy ra, chẳng hạn như
một biểu đồ thanh để quản lý và xem một bảng cho kế toán. Phần thứ ba, bộ điều
khiển, chấp nhận đầu vào và chuyển đổi nó để lệnh cho các mơ hình hoặc xem.


Một sự hợp tác điển hình của các thành
phần MVC

 Ngoài cách chia ứng dụng thành ba loại của các thành phần, các ModelView-Controller (MVC) thiết kế xác định sự tương tác giữa chúng.
o Một bộ điều khiển ( Controller ) có thể gửi các lệnh đến các mơ hình
để cập nhật trạng thái của mơ hình (ví dụ, chỉnh sửa tài liệu). Nó cũng
có thể gửi các lệnh để xem liên quan của nó để thay đổi trình bày của
quan điểm của các mơ hình (ví dụ, bằng cách di chuyển thơng qua một
tài liệu).
o Một mơ hình ( Model ) thông báo quan liên quan và các bộ điều khiển
của nó khi đã có một sự thay đổi trong trạng thái của nó. Thơng báo

điều này cho phép các quan điểm để sản xuất ra được cập nhật, và các
bộ điều khiển để thay đổi các thiết lập có sẵn các lệnh. Một thực hiện
thụ động của MVC bỏ qua các thơng báo, bởi vì các ứng dụng khơng
địi hỏi họ hoặc các nền tảng phần mềm khơng hỗ trợ họ.
o Một quan điểm ( View ) yêu cầu thơng tin từ các mơ hình mà nó cần
để tạo ra một đại diện đầu ra cho người sử dụng
MVC là một trong những hiểu biết sâu sắc tinh của lĩnh vực đầu giao diện
người dùng đồ họa


17.
Layered architecture ( kiến trúc Layered ) : Tổ chức hệ thống vào lớp với
chức năng liên quan liên kết với mỗi lớp. Một lớp cung cấp dịch vụ cho lớp trên
để các lớp mức thấp nhất đại diện cho các dịch vụ cốt lõi có khả năng được sử
dụng trên tồn hệ thống.
a. Sử dụng để mơ hình interfacing của sub – systems
b. Tổ chức các hệ thống vào một tập hợp các lớp (hoặc các máy trừu tượng)
mỗi trong số đó cung cấp một tập hợp các dịch vụ.
c. Hỗ trợ sự phát triển gia tăng của các tiểu hệ thống trong các lớp khác nhau.
Khi một giao diện lớp thay đổi, chỉ có lớp kế cận bị ảnh hưởng.
d. Thường nhân tạo cấu trúc hệ thống theo cách này.

Tổ chức hệ thống vào lớp với chức năng liên quan liên kết với mỗi lớp. Một lớp
cung cấp dị ch vụ cho lớp trên để các lớp mức thấp nhất đại diện cho các dị ch
vụ cốt lõi có khả năng được sử dụng trên tồn hệ thống.
Một mơ hình lớp của một hệ thống chia sẻ tài liệu bản quyền được tổ chức tại
thư viện khác nhau,
Được sử dụng khi xây dựng cơ sở mới trên hệ thống hiện có, khi sự phát triển được
lan truyền trên một số team với mỗi team chị u trách nhiệm 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.

Cho phép thay thế toàn bộ lớp, miễn là giao diện được duy trì. Cơ sở vật chất dư
thừa (ví dụ, xác thực) có thể được cung cấp trong mỗi lớp để tăng độ tin cậy của
hệ thống.
Trong thực tế, cung cấp một sự riêng biệt giữa các lớp thường rất khó và một
lớp cao cấp có thể tương tác trực tiếp với các lớp cấp dưới chứ không phải
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 lớp.


Mơ hình Respository:
1. Mơ tả: Tất cả dữ liệu trong một hệ thống được quản lý trong một kho lưu trữ trung
tâm có thể truy cập đến tất cả các thành phần hệ thống. Thành phần không tương
tác trực tiếp, chỉ có thơng qua kho lưu trữ
2. Khi nào cần sử dụng: Khi hệ thống chứa một lượng lớn thông tin được tạo ra và
lưu trữ trong một thời gian dài, bạn cũng có thể sử dụng hệ thống này trong các hệ
thống điều khiển dữ liệu nơi bao gồm các dữ liệu đc tạo ra bởi các hành động hay
công cụ.
3. Ưu điểm:
- Các thành phần độc lập với nhau
- Khi thay đổi được thự hiện trên một thành phần thì nó có thể được truyền
đến các thành phần còn lại
- Tất cả dữ liệu quản lý được thống nhất
4. Nhược điểm:
- Tất cả các thành phần đều được lưu trữ trong kho nên nếu có xảy ra sự cố thì
sẽ ảnh hưởng đến tồn bộ hệ thống
- Có thể không hiệu quả trong việc tổ chứ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 máy tính có thể gặp khó khăn

Kiến trúc Client-server
Là mơ hình hệ thống phân phối cho thấy cách mà các data và process đc phân phối
thông qua nhiều thành phần(chả hiểu cái khỉ khơ j hết)
Có thể được thực hiện trên 1 máy tính
Thiết lập các máy chủ độc lập cung cấp các dịch vụ như in ấn, quản lí dữ liệu….
- những thiết lập của khách hàng vào dịch vụ
- hệ thống mạng cho khách hàng truy cập vào máy chủ
Mơ hình Client-server:
1. 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ụ, mỗi dịch vụ đc cung cấp 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à các server để truy cập và sử dụng chúng.
2. Lúc nào thì sử dụng mơ hình này: Khi dữ liệu từ một cơ sở dữ liệu đc truy cập
từ nhiều địa điểm khác nhau, bởi vì các 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.
3. Ưu điểm:
 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 cung cấp
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ụ.
4. Nhược điểm:
 Mỗi dịch là một điểm suy nên dễ bị các server từ chối truy cập
hay bị lỗi từ các máy chủ
 Hiệu suất ko tính tốn đc vì cịn phải phụ thuộc vào mạng và hệ
thống.
 Có thể là vấn đề quản lý nếu máy chủ được sở hữu bởi các tổ
chức khác nhau


Pipe and filter architecture
Các hàm chuyển đổi xử lý đầu vào để cho ra kết quả( đầu ra)

Các biến thể của phương pháp này đc dùng chung, khi chuyển đổi đc thực hiện một
cách tuần tự thì đây là một loạt các mơ hình tuần tự đc sử dụng rộng rãi trong các hệ
thống xử lý dữ liệu
Không thực sự phù hợp cho các hệ thống tương tác.
1. Mô tả: Việc xử lý các dữ liệu trong một hệ thống được tổ chức vì vậy mỗi
thành phần xử lý (lọc) là rời rạc và thực hiện cho ra một loại hình chuyển đổi
dữ liệu. Các luồng dữ liệu (như trong một đường ống) từ một thành phần đc các
thành phần khác xử lý.
2. Khi nào thì sử dụng mơ hình này: đc sử dụng trong các ứng dụng xử lý dữ liệu,
đầu vào đc xử lý trong giai đoạn riêng biệt để tạo ra đầu ra liên quan.
3. ưu điểm:
 Dễ hiểu, hỗ trợ tái sử dụng
 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
 Tiến hóa bằng cách thêm các phép biến đổi là đơn giản
 Có thể thực hiện như một hệ thống tuần tự hay đồng thời
4. Nhược điểm:
 Định dạng cho việc chuyển dữ liệu phải đc sự đồng ý giữa việc giao tiếp
và sự biến đổi
 Mỗi chuyển đổi phải phân tích đầu vào và đầu ra của nó unparse mẫu
đồng ý
 Không thể tái sử dụng việc chuyển đổi chức năng sử dụng cấu trúc dữ liệu
ko tương thích
Kiến trúc ứng dụng
Được thiết kế nhằm đáp ứng nhu cầu của tổ chức


Theo các doanh nghiệp có nhiều điểm chung, hệ thống ứng dụng của họ cũng có
xu hướng có một kiến trúc phổ biến mà các yêu cầu ứng dụng.
Một kiến trúc ứng dụng chung chung là một kiến trúc cho một loại hệ thống phần

mềm có thể được cấu hình và điều chỉnh để tạo ra một hệ thống đáp ứng yêu cầu
cụ thể.
Sử dụng các kiến trúc ứng dụng:
-

Như là một điểm khởi đầu cho thiết kế kiến trúc
Như là một danh sách kiểm tra thiết kế
Như là một cách thức tổ chức công việc của đội ngủ phát triển
Như là một phương tiện đánh giá các thành phần tái sử dụng
Như là một vốn từ vựng để nói về các ứng dụng

Một số loại ứng dụng:
- Data processing applications( ứng dụng xử lý dữ liệu): ứng dụng dữ liệu
động xử lý dữ liệu theo lơ mà khơng có sự can thiệp rõ ràng của người sử
dụng trong quá trình xử lý.
- Transaction processing applications( ứng dụng xử lý giao dịch): ứng dụng dữ
liệu trung tâm, xử lý yêu cầu người sử dụng và cập nhật thông tin trong cơ sở
dữ liệu hệ thống.
- Event processing systems( hệ thống xử lý sự kiện): các ứng dụng mà hành
động hệ thống phụ thuộc vào việc giải thích các sự kiện từ môi trường của hệ
thống
- Language processing systems( hệ thống xử lý ngôn ngữ): các ứng dụng mà ý
định của người sử dụng được quy định trong một ngôn ngữ chính thức được
xử lý và giải thích bởi hệ thống.
Application type examples
Tập trung ở đây là xử lý giao dịch và hệ thống xử lý ngôn ngữ.
Hệ thống xử lý giao dịch:


Q trình người dùng u cầu cho thơng tin từ một cơ sở dữ liệu hoặc yêu cầu để cập

nhật cơ sở dữ liệu.
Từ góc độ người dùng một giao dịch là:
-

Bất cứ trình tự chặt chẽ các hoạt động đều thỏa mãn một mục tiêu

Người sử dụng có những yêu cầu không đồng bộ cho dịch vụ mà sau đó được xử lý bởi
một người quản lý giao dịch.
Cấu trúc của các ứng dụng xử lý giao dịch:

Kiến trúc hệ thống thơng tin:
Hệ thống thơng tin có một kiến trúc chung chung mà có thể được tổ chức như một kiến
trúc lớp.
Đây là những hệ thống giao dịch dựa trên sự tương tác với các hệ thống thường liên
quan đến các giao dịch cơ sở dữ liệu
Các lớp bao gồm:
• Giao diện người dùng
• thơng tin liên lạc người dùng
• Thơng tin thu hồi
• Hệ thống cơ sở dữ liệu
The architecture of the MHC-PMS( tự xem hình nhá, chả biết nó vẻ cái j)


Hệ thống thông tin dựa trên web: Hệ thống quản lý thông tin và tài nguyên bây giờ
thường các hệ thống dựa trên web nơi mà các giao diện người dùng được thực hiện
bằng cách sử dụng một trình duyệt web.
Ví dụ, hệ thống thương mại điện tử là hệ thống quản lý tài nguyên Internet có trụ
sở tại chấp nhận đơn đặt hàng điện tử đối với hàng hóa, dịch vụ và sau đó sắp xếp
giao hàng của các hàng hóa, dịch vụ cho khách hàng.
Trong một hệ thống thương mại điện tử, các lớp ứng dụng cụ thể bao gồm các

chức năng bổ sung hỗ trợ một 'giỏ hàng ", trong đó người dùng có thể đặt một số
mặt hàng trong các giao dịch riêng biệt, sau đó trả tiền cho họ tất cả cùng nhau
trong một giao dịch duy nhất.
Việc thực hiện máy chủ:Các hệ thống này thường được thực hiện như nhiều mơ hình
khách chủ / kiến trúc


Các máy chủ web chịu trách nhiệm cho tất cả các thông tin liên lạc của người
dùng, với giao diện người dùng thực hiện bằng cách sử dụng một trình duyệt web;
Các máy chủ ứng dụng có trách nhiệm thực hiện logic các ứng dụng cụ thể cũng
như lưu trữ thông tin và yêu cầu thu hồi;
Các máy chủ cơ sở dữ liệu di chuyển thông tin đến và đi từ các cơ sở dữ liệu và xử
lý quản lý giao dịch.
Hệ thống xử lý ngôn ngữ:
Chấp nhận một ngôn ngữ tự nhiên hoặc nhân tạo là đầu vào và tạo ra một số đại diện
khác của ngơn ngữ đó.
Có thể bao gồm một thông dịch viên để hoạt động trên các hướng dẫn trong ngôn ngữ
đang được xử lý.
Được sử dụng trong các tình huống mà cách dễ nhất để giải quyết vấn đề là để mô tả
một thuật tốn hoặc mơ tả các hệ thống dữ liệu
Những cơng cụ Meta-case mơ tả quy trình giớ thiệu cơng cụ, quy định phương
pháp, tạo ra công cụ
Kiến trúc của một hệ thống xử lý ngơn ngữ( xem hình nhá)


Thành phần biên dịch:
Một phân tích từ vựng, trong đó có thẻ ngơn ngữ đầu vào và chuyển đổi chúng sang một
hình thức nội bộ.
Một bảng biểu tượng, nắm giữ thông tin về tên của các thực thể (biến, tên lớp, tên đối
tượng, vv) được sử dụng trong các văn bản đang được dịch.

Một phân tích cú pháp, trong đó kiểm tra cú pháp của ngôn ngữ được dịch.
Một cây cú pháp, mà là một cấu trúc nội bộ đại diện cho các chương trình được biên
soạn.
Một phân tích ngữ nghĩa có sử dụng thơng tin từ các cây cú pháp và bảng biểu tượng để
kiểm tra tính chính xác ngữ nghĩa của văn bản ngôn ngữ đầu vào.
A code generator that „walks‟ the syntax tree and generates abstract machine code.(Một
máy phát điện mã 'đi' cây cú pháp và tạo ra mã máy trừu tượng.) không hiểu
A pipe and filter compiler architecture


Một kiến trúc kho lưu trữ cho một hệ thống xử lý ngơn ngữ

TĨM TẮT:
Một kiến trúc phần mềm là một mô tả về cách hệ thống phần mềm được tổ chức.
Quyết định thiết kế kiến trúc bao gồm các quyết định về các loại ứng dụng, phân phối
của hệ thống, các phong cách kiến trúc được sử dụng.


Kiến trúc có thể được ghi lại từ những quan điểm khác nhau hoặc những quan điểm như
một cái nhìn khái niệm, một cái nhìn hợp lý, một quá trình xem, và xem một phát triển.
Mơ hình kiến trúc là một phương tiện tái sử dụng kiến thức về kiến trúc hệ thống chung.
Họ mơ tả kiến trúc, giải thích khi nó có thể được sử dụng và mơ tả những ưu điểm và
nhược điểm của nó.
Mơ hình kiến trúc hệ thống ứng dụng giúp chúng ta hiểu và so sánh các ứng dụng, xác
nhận thiết kế hệ thống ứng dụng và đánh giá các thành phần quy mô lớn để tái sử dụng.
Hệ thống xử lý giao dịch là hệ thống tương tác cho phép các thông tin trong cơ sở dữ
liệu được truy cập và sửa đổi từ xa bởi một số lượng người dùng.
Hệ thống xử lý ngôn ngữ được sử dụng để dịch văn bản từ một ngôn ngữ này sang một
ngôn ngữ khác và thực hiện các hướng dẫn quy định trong ngôn ngữ đầu vào. Chúng
bao gồm một phiên dịch và một máy trừu tượng cái dùng để thực hiện các ngôn ngữ tạo

ra.