đề tài “ kiến trúc phần mềm hiện đại ”

1
ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
o0o

THỰC TẬP CHUYÊN NGÀNH
KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI
Sinh viên: Nguyễn Đức Trọng
MSV: DTC0851200034
Giáo viên hướng dẫn: ThS Ngô Thị Lan
Bộ môn: Công Nghệ Phần Mềm

Thái Nguyên 2012
2
ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG


THỰC TẬP CHUYÊN NGÀNH
KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI
Sinh viên: Nguyễn Đức Trọng
MSV: DTC0851200034
Giáo viên hướng dẫn:ThS Ngô Thị Lan
Bộ môn: Công Nghệ Phần Mềm
3
MỤC LỤC
4
LỜI NÓI ĐẦU
Trong tiến trình kĩ nghệ phần mềm hiện nay, xây dựng một kiến trúc phần mềm tối
ưu luôn là một trong những vấn đề then chốt đước các tổ chức phát triển phần mềm

lớn trên toàn thế giới quan tâm. Đó là lí do vì sao mà các hội thảo đình đám với các
nội dung liên quan tới kiến trúc phần mềm được các tập đoàn công nghệ thông tin lớn
trên thế giới như IBM, Microsoft… tổ chức ngày một nhiều hơn (Hội thảo kiến trúc
hướng dịch vụ và quản lí dịch vụ - IBM, Hội thảo kiến trúc phần mềm và thiết bị di
động – Microsoft…).
Theo nhiều chuyên gia đầu ngành về công nghệ thông tin ở Việt Nam, lĩnh vực sản
xuất phần mềm ở nước ta đang gặp phải một thực trạng báo động đó là vấn đề thiết kế
kiến trúc trong xây dựng, phát triển phần mềm chưa được các nhà phát triển phần
mềm trong nước quan tâm đúng mức. Đó là một trong các lí do giải thích vì sao với
lực lượng làm việc trong lĩnh vực đông đảo như hiện nay (khoảng 200.000 người và
dự kiến sẽ tăng lên 600.000 người đến năm 2020) nhưng về cơ bản chúng ta vẫn chỉ là
một nước gia công phần mềm và sản xuất phần mềm theo đơn đặt hàng, các phần
mềm do chính chúng ta thiết kế và sản xuất vẫn chưa tao ra được chỗ đứng trên thị
trường quốc tế. Các giáo viên luôn than phiền rằng sinh viên học trong ngành công
nghệ phần mềm của chúng ta hiện nay hầu hết quan tâm tới lập trình hơn là thiết kế,
trong khi lập trình là công việc có mức thu nhập cũng như được đánh giá ít nhất trong
các dự án công nghệ thông tin.
Hiện nay hầu hết sinh viên công nghệ thông tin ở các trường đại học lớn trên thế
giới đều được học các kiến thức liên quan tới kiến trúc phần mềm một cách bài bản và
chuyên sâu. Tuy nhiên sinh viên công nghệ thông tin ở Việt Nam lại không được đào
tạo nhiều về kiến trúc phần mềm, bằng chứng là hiện chúng ta gần như chưa có một
tài liệu chuyên sâu nào về kiến trúc phần mềm viết bằng tiếng Việt(cả ebook cũng như
giáo trình xuất bản thành sách).
Nhận thức được tầm quan trọng của kiến trúc phần mềm trong phát triển phần
mềm, thực trạng ngành phần mềm ở Việt Nam hiện nay cũng như sự thiếu hụt các tài
liệu chuyên môn trong lĩnh vực này chính là lí do thôi thúc em đề xuất và thực hiện đề
tài này.
Đề tài “Kiến trúc phần mềm hiện đại” được thực hiện dưới sự hướng dẫn nhiệt
tình của cô Ngô Thị Lan – bộ môn Công Nghệ Phần Mềm, cô đã giúp em trong xây
dựng ý tưởng cho đề tài, phác thảo chi tiết nội dung đề tài, cung cấp các tài liệu hữu

ích và hướng dẫn chi tiết các nội dung nghiên cứu. Ngoài ra em còn nhận được rất
5
nhiều sự giúp đỡ của các thầy cô khác trong bộ môn Công Nghệ Phần Mềm, em xin
chân thành cảm ơn các thầy cô đã nhiệt tình giúp đỡ và giúp em hoàn thành đề tài.
Đồng thời em rất mong nhận được sự đóng góp nhiệt tình của thầy cô và các bạn để
đề tài này được hoàn thiện hơn nữa, giúp em tiếp tục phát triển đề tài này cho đợt thực
tập tốt nghiệp sắp tới cũng như phục vụ cho công việc sau khi ra trường.
Em xin chân thành cảm ơn.
Sinh viên
Nguyễn Đức Trọng
6
NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………

…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
……………………………………………………………………………………
7
TÓM TẮT NỘI DUNG
Bản báo cáo được chia thành 5 chương với nội dung như sau:
- Chương 1: Các khái niệm cơ bản về kiến trúc phần mềm, bản chất, ý nghĩa của
kiến trúc phần mềm trong việc phát triển phần mềm, nguyên tắc tổng quan của
quy trình thiết kế kiến trúc, các yếu tố đánh giá chất lượng kiến trúc phần mềm.
- Chương 2: Một số xây dựng tần trung gian trong kiến trúc phần mềm.
- Chương 3: Các kiến trúc phần mềm hiện đại đang dành được sự chú ý hiện
nay: Một số kỹ thuật xây dựng tầng trung gian trong kiến trúc phần mềm
(Middleware), Kiến trúc phần mềm cho dòng sản phẩm phần mềm
(ProductLine), Kiến trúc phần mềm phát triển theo hướng mô hình (Model-
Driven Architecture) , Kiến trúc phần mềm phát triển theo hướng dịch vụ
(Service- Oriented Architecture)
- Chương 4: Tổng quan về ngôn ngữ UML và sử dụng UML trong thiết kế kiến
trúc phần mềm
- Chương 5: Xây dựng kiến trúc website bán điện thoại với UML

8

Chương I. TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM
I. Khái niệm kiến trúc phần mềm và vai trò của kiến trúc phần mềm
Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ
trước. Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian
thực phức tạp, kiến trúc phần mềm nổi lên như là một kiến trúc cơ sở của việc phát
triển phần mềm và công nghệ hệ thống chủ lực.
Như bất kỳ lĩnh vực nghiên cứu nào khác, kiến trúc phần mềm cũng có những
thách thức ban đầu của nó. Một kiến trúc phần mềm thể hiện các phương diện cấu trúc
và hành vi của một hệ thống, nó có thể được định nghĩa như sau:
“Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc
hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính
có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa
chúng.”
Ðịnh nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse-
grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ
phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the
architecture). Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số
nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ
phận kiến trúc cơ bản còn lại. Các chi tiết bên trong của sự thiết kế và cài đặt thành
phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần
mềm đặc biệt chỉ như một hộp đen. Hộp đen này có các thuộc tính nhất định mà nó
biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung
các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm xác định các khối
kiến trúc cơ bản, với một mức độ chi tiết thích hợp. Nó cũng xác định và viết tư liệu
việc các bộ phận cơ bản liên quan lẫn nhau như thế nào.
Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân
vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây dựng theo
kiểu lặp lại, gia tăng, và độc lập. Các bộ phận riêng lẻ có các mối quan hệ hiện với
nhau. Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ
chức, hoặc ứng dụng.

Có một số nhầm lẫn về sự khác nhau giữa kiến trúc với thiết kế. Tất cả các kiến
trúc là thiết kế nhưng không phải tất cả các thiết kế là kiến trúc. Các thiết kế mà cần
9
phải ràng buộc, về mặt hệ thống, để đáp ứng các nhu cầu chức năng và phi chức năng
và các mục tiêu của nó, là có tính kiến trúc về bản chất. Trong khi kiến trúc coi một bộ
phận kiến trúc cơ bản là một hộp đen, thì thiết kế xử lý cấu hình, tuỳ biến, và các công
việc bên trong của một bộ phận kiến trúc cơ bản. Kiến trúc ràng buộc một thành phần
phần mềm với các thuộc tính bên ngoài của nó. Thiết kế thường lỏng hơn nhiều so với
kiến trúc, vì nó cho phép nhiều cách gắn kết các thuộc tính bên ngoài của thành phần
này. Thiết kế cũng cân nhắc các cách khác nhau để thực hiện các chi tiết bên trong của
thành phần.
Kiến trúc phần mềm có thể được sử dụng một cách đệ quy. Hãy xem xét một thành
phần phần mềm (C1) mà là một bộ phận của một kiến trúc phần mềm của một hệ
thống. Kiến trúc sư phần mềm chuyển thành phần này đến nhà thiết kế hệ thống, cùng
với các thuộc tính của nó, các khả năng về chức năng và phi chức năng nó phải thể
hiện, và mối quan hệ của nó với các bộ phận phần mềm khác. Nhà thiết kế sau khi
phân tích thành phần phần mềm C1, quyết định nó sẽ được phân tích thành các thành
phần chi tiết hơn (C11, C12, và C13), mỗi cái cung cấp một chức năng có thể dùng lại
được mà sẽ được sử dụng để thực thi các thuộc tính đã gán cho C1. Nhà thiết kế chi
tiết hoá C11, C12, C13 và các giao diện của chúng.
Tại điểm này, đối với nhà thiết kế, C11, C12, và C13 là các bản dựng kiến trúc
(hoặc các thành phần); mỗi cái đều có các giao diện bên ngoài được xác định rõ ràng.
Ðối với nhà thiết kế, C11, C12, và C13 là kiến trúc của thành phần phần mềm C1, và
các bản dựng cần được soạn thảo và thiết kế công phu hơn nữa để nhằm đến các cài
đặt bên trong của chúng. Kiến trúc có thể được sử dụng một cách đệ quy bằng cách
phân chia hệ thống lớn, phức tạp thành các bộ phận nhỏ, và tập trung vào từng bộ
phận.
Kiến trúc ràng buộc hệ thống bằng cách sử dụng các bộ phận kiến trúc cơ bản mà
thoả mãn chung các mục tiêu hành vi và chất lượng. Các cổ đông phải có khả năng
hiểu được kiến trúc. Như vậy điều cốt yếu là một kiến trúc phải được viết tư liệu thoả

đáng, như được thảo luận trong phần kế tiếp.
II. Các nhân tố đánh giá chất lượng kiến trúc phần mềm
1. Các nhân tốt chất lượng
Các nhà thiết kế kiến trúc phần mềm dành hầu hết thời gian của mình cho việc thiết kế
ra các hệ thống đảm bảo tập các yêu cầu chất lượng của hệ thống. Các yêu cầu chất
10
lượng là một phần của các yêu cầu phi chức năng. Có 4 nhất tố chất lượng mà các nhà
thiết kế luôn hướng tới đó là:
- Khả năng mở rộng
- Tính bảo mật
- Hiệu năng
- Độ tin cậy
2. Hiệu năng
Yêu cầu hiệu năng chỉ ra một lượng xác định các công việc mà hệ thống cần phải
thực hiện trong khoảng thởi gian nào đó . Thông thường các ứng dụng cần có khả
năng xử lí hàng trăm, đôi khi là hàng ngàn hoặc vạn giao dịch (transaction) mỗi giây,
những yêu cầu này thường thấy trong các hệ thống lớn của các tổ chức, đặc biệt trong
các tổ chức tài chính, viễn thông và các chính phủ.
a. Throughput
Throughput là sự đo lường lượng công việc mà một ứng dụng phải thực hiện trong
một đơn vị thời gian. Nó thường được đo bằng số giao dịch mỗi giây (pts) hay số
thông điệp được xử lí mỗi giây (mps).
Ví dụ một ứng dụng online của ngân hàng phải đảm bảo nó có thể thực hiện được tối
thiểu 1000, giao dịch online mỗi giây (1000pts), hay một hệ thống quản lí bán hàng có
thể cần sử lí 50 thông điệp yêu cầu mua hàng từ các khách hàng mỗi giây (50mps).
b. Thời gian đáp ứng (Response time)
Thời gian đáp ứng chỉ ra độ trễ về thời gian khi ứng dụng sử lí một giao dịch. Thời
gian đáp ứng thường gắn liền với thời gian ứng dụng sử dụng để phản hội lại một đầu
vào nào đó. Thời gian đáp ứng càng ngắn hiệu quả làm việc của người dùng càng cao.
Một ví dụ tiêu biểu là ứng dụng hộ trợ việc bán hàng tại các cửa hàng lớn, với lượng

khách hàng đông, khi một sản phẩm được quét tại các quầy thanh toán, việc hệ thống
hiển thị giá của sản phẩm trong thời gian ngắn giúp cho việc phục vụ khách hàng
được nhanh hơn, đây là mong muốn của cả khác hàng và cửa hàng.
c. Thời hạn hoàn thành (Deadlines)
11
Các ứng dụng yêu cầu nghiêm ngặt về thời gian hoàn thành một yêu cầu người
dùng thường là các ứng dụng phục vụ các công việc liên quan tới phân phối sản phẩm
hàng hóa, thư tín, thực hiện các giao dịch tài chính…
Chẳng hạn một hệ thống thanh toán trực tuyến (paypal là một ví dụ tiêu biểu), khi
người sử dụng gửi tiền vào t ài khoản của mình, nó phải hoàn thành trong một thời
gian nhất định yêu cầu của người dùng. Nếu trong thời gian đó mà hệ thống không thể
thực hiện được yêu cầu của người dùng thì họ sẽ không thể thực hiện được các giao
dịch tài chính của mình và đây là một vấn đề không thể chấp nhận được.
3. Khả năng mở rộng
Một cách tổng quan, khả năng mở rộng cho chúng ta biết một thiết kế sẽ ứng phó
thế nào khi mà các yêu cầu của ứng dụng ở một số khía cạnh nào đó tăng nên. Chúng
ta hãy xem xét một số khía cạnh sau:
a. Yêu cầu tải (Request load)
Ví dụ một ứng dụng server được thiết kế cho phép xử lí 100 giao dịch mỗi giây
(100pts) với một kiến trúc nào đó, nhưng khi ứng dụng cần nâng cấp để nó có thể xử lí
số giao dịch tăng gấp 100 lần thì kiến trúc này còn phù hợp ko?
Thông thường có hai giải pháp thường được sử dụng để nâng cao khả năng đáp
ứng của hệ thống khi tải trọng lên nó tăng gấp nhiều lần:
- Thiết kế các ứng dụng đa luồng hay nhiều luồng đơn được sử lí trên cùng một máy
tính (Scale up works). Để thực hiện được điều này chắc chắn yêu cầu về bộ nhớ và
các tài nguyên khác sẽ tăng nên, tuy nhiên tốc độ sử lí của hệ thống sẽ tăng nên đáng
kể.
- Phân bố tải đồng đều trên các máy tính khác nhau (Scale out works), mục đích là làm
cho các máy tính cố hiệu quả làm việc như nhau vì việc đầu tư vào phần cứng sẽ trở
lên lãng phí nếu như một máy tính nào đó phải làm việc quá tải trong khi các máy tính

khác thì không hoạt động hết công suất.
Hình 1.1 mô tả quá trình scale-up và scale-out
12
Hình 1.1 Scale out versus scale up
b. Nhiều kết nối đồng thời (Simultaneous connections)
Một kiến trúc được thiết kế để phục vụ 1000 lượt truy cập trong cùng một thời
điểm nhưng nó sẽ đáp ứng ra sao khi số lượt truy cập tăng lên? Nếu mỗi lượt truy cập
của người dùng yêu cầu một lượng nhất định nào đó tài nguyên của hệ thống thì chắc
chắn hệ thống chỉ có thể thực phục vụ có hiệu quả với một giới hạn số lượt truy cập
nhất định.
c. Kích thước dữ liệu (Data size)
Một kiến trúc tốt cần có khả năng mở rộng khi yêu cầu về kích thước dữ liệu mà
nó sử lí tăng nên. Chẳng hạn với một ứng dụng chat online như ta thường thấy chúng
được thiết kế cho phép sử lí những mẩu tin của người dung trong một giới hạn kích
thước nhất định (thông thường là giới hạn về số kí tự). Tuy nhiên trong một số trường
hợp các mẩu tin mà người dùng mướn gửi đi vượt quá giới hạn mà ứng dụng cho
phép, thông thường trong trường hợp này người sử dụng sẽ phải cắt ngắn bản tinh
mình muốn gửi thành nhiều đoạn và gửi từng đoạn đi. Điều này đặt ra câu hỏi nếu
một ngày nào đó ta cần nâng cấp ứng dụng cho phép gửi đi các mẩu tin với kích thước
lớn đáp ứng yêu cầu của người sử dụng (đôi khi là các file dữ liệu, âm thành, hình
ảnh…) thì kiến trúc hiện tại của hệ thống có đáp ứng được ko?
d. Triển khai ứng dụng (Deployment)
13
Ở đây ta xem xét tới việc hệ thống được thiết kế thế nào để đảm bảo rằng nó có thể
được triển khai hiệu quả (thậm chí khi cần thay đổi) khi số lượng người sử dụng hệ
thống tăng nên (ở đây muốn nói tới số khách hàng), hay nói cách khác là hệ thống đó
có dễ dàng được cài đặt trên nhiều máy tính khác nhau không? Nó bao gồm các nỗ lực
để cấu hình, phân phối và cập nhật các phiên bản mới.
Một giải pháp lí tưởng là tạo ra một cơ chế tự động cài đặt và triển khải hệ thống
đến người sử dụng mới dựa trên những thông tin đăng kí của người sử dụng. Cơ chế

này đang được sử dụng rộng rãi với các ứng dụng phân phối trên Internet.
e. Khả năng sửa đổi (Modifiability)
Khả năng sửa đổi là yếu tố sống còn quyết định thời gian tồn tài của phần mềm khi
mà các yêu cầu người dùng luôn thay đổi theo thời gian. Khả năng sửa đổi có thể
được coi như là thước đo phản ánh việc phần mềm có dễ dàng được sửa đổi khi có sự
phát sinh các yêu cầu chức năng và phi chức năng hay không?
f. Tính bảo mật (Security)
Tính bảo mật của hệ thống là một chủ đề phức tạp, trong giới hạn nghiên cứu kiến
trúc phần mềm chúng ta chỉ nghiên cứu tới các yêu cầu bảo mật của một ứng dụng và
đưa ra một cơ chế thích hợp hỗ trợ nó.
Các yêu cầu bảo mật phổ biến bao gồm:
- Xác thực (Authentication): Các ứng dụng cần có khả năng xác nhận xem đối tượng
mà nó đang giao tiếp ( con người hay các ứng dụng khác) có hợp thức hay không.
- Sự cấp quyền (Authorization): Những người sử dụng hay các ứng dụng đã được xác
thực chỉ được phép truy cập những tài nguyên nhất định của hệ thống. Chẳng hạn một
số người dùng nào đó chỉ có quyền đọc dữ liệu của hệ thống trong khi những người
khác lại có quyển đọc và ghi…
- Mã hóa (Encryption): Hệ thống phải đảm bảo rằng những thông tin quan trọng khi
được gửi/ nhận giữa các ứng dụng hay giữa người sử dụng với hệ thống được mã hóa
an toàn.
- Toàn vẹn (Integrity): Đảm bảo các thông tin khi truyền nhận không bị thay đổi.
14
- Không thoái thác (Nonrepudiation): Có một cơ chế an toàn tin cậy nhằm đảm bảo cả
người gửi tin và người nhận tin không thể thoái thác trách nhiệm với mẩu tin đã trao
đổi (một ví dụ tiêu biểu và nổi bật là ứng dụng chữ kí số).
g. Khả năng sẵn sàng (Availability)
Khả năng sẵn sàng của ứng dụng liên quan chặt chẽ tới độ tin cậy của nó. Nếu một
ứng dụng không sẵn sãng khi người sử dụng cần điều đó có nghĩa nó chưa đáp ứng
được yêu cầu chức năng.
h. Khả năng tích hợp (Integration)

Các hệ thống cần thiết kế cho phép nó có thể tích hợp với các ứng dụng khác trong
bối cảnh và phạm vi hoạt động rộng hơn. Thông thường giá trị của một hệ thống phần
mềm sẽ tăng lên nếu nó có thể tích hợp để cũng hoạt động thống nhất với các hệ
thống khác. Các ứng dụng khác có thể truy cập trực tiếp tới dữ liệu của hệ thống tuy
nhiên một giải pháp hay được sử dụng hơn là xây dựng một API như hình 3.2.
1.2 Các kiểu tích hợp
Cách duy nhất để các ứng dụng ngoài hệ thống tích hợp với hệ thống và truy cập
dữ liệu của nó là thông qua API
Việc tích hợp dữ liệu cần phải mềm mỏng và đơn giản. Các ứng dụng có thể viết
bằng một ngôn ngữ nào đó để xử lí văn bản, truy cập cơ sở dữ liệu quan hệ sử dụng
SQL… Cho nên việc xây dựng một API yêu cầu nhiều công sức nhưng nó sẽ cung cấp
một môi trường có khả năng kiểm soát nhiều hơn, nâng cao sự chuẩn xác và bảo mật
khi tích hợp các hệ thống với nhau.
15
Ngoài các nhân tố đánh giá chất lượng đã đề cập ở trên, tùy vào từng hệ thống cụ
thể trong một vài trường hợp người ta còn xem xét tới các nhân tố quan trọng khác
như: khả năng cài đặt dễ dàng trên các nền tảng phần cứng/phần mềm khác nhau
(Portability), dễ dàng kiểm thử (Testability), dễ dàng cho việc hộ trợ vận hàng khi hệ
thống đã được triển khai trong thực tế (Supportability)
III. Quy trình thiết kế kiến trúc phần mềm
1. Phác thảo quy trình
Vai trò của kiến trúc sư phần mềm không đơn giản chỉ là đưa ra các hoạt động thiết
kế kiến trúc cũng như kiến trúc của hệ thống. Kiến trúc sư phần mềm cần:
- Làm việc với đội phân tích yêu cầu hệ thống: đội phân tích yêu cầu chú trọng tới các
yêu cầu chức năng từ phía khách hàng và kiến trúc sư giữ vai trò quan trọng trong
việc tập hợp các yêu cầ đó bởi sự hiểu tổng thể hệ thống cần gì và đưa ra các nhân tố
chất lượng của hệ thống.
- Làm việc với các stakeholder khác nhau: Kiến trúc sư phần mềm giữ vai trò quan
trọng trong việc chắc chắn tất cả những gì stakeholder cần cho hệ thống đã được hiểu
chính xác và được đưa vào trong thiết kế. Chẳng hạn người quản trị hệ thống có thể

yêu cầu ứng dụng cần dễ dàng được cài đặt, theo dõi, quản lí và cập nhật…
- Lãnh đạo đội thiết kế kiến trúc: Xác định kiến trúc ứng dụng là một hoạt động thiết
kế. Kiến trúc sư lãnh đạo đội thiết kế, bao gồm các thiết kế viên hệ thống (hay trong
các hệ thống lớn là các kiến trúc sư khác) và đưa ra các dẫn dắt kĩ thuật để cuối cùng
đưa ra bản thiết kế chi tiết (architecture blueprint) của hệ thống cần triển khai.
- Làm việc với bên quản trị dự án: Kiến trúc sư phần mềm làm việc mật thiết với người
quản trị dự án nhằm giúp đưa ra nhằm đưa ra kế hoạch dự án, các ước lượng, nhiệm
vụ và kế hoạch thực hiện dự án.
Có 3 bước trong tiến trình thiết kế kiến trúc đó là: xác định yêu cầu kiến trúc, thiết
kế kiến trúc và chuẩn hóa (hình 1.3)
16
Hình 1.3 Tiến trình thiết kế kiến trúc
- Xác định yêu cầu kiến trúc: Liên quan tới việc tạo ra một tuyên bố hoặc mô hình các
yêu cầu, nó sẽ thúc đẩy việc thiết kế kiến trúc.
- Thiết kế kiến trúc: liên quan tới việc xác định cấu trúc và vai trò của các thành phần
trong kiến trúc hệ thống.
- Chuẩn hóa: liên quan tới việc kiểm tra (testing) kiến trúc dựa trên tập các yêu cầu hệ
thống.
2. Xác định yêu cầu kiến trúc
Trước khi một giải pháp thiết kế kiến trúc có thể được chính thức tiến hành nhằm
đưa ra bản thiết kế hệ thống, ta cần xem xét chi tiết các yêu cầu kiến trúc mà hệ thống
cần đáp ứng. Hình 1.4 thể hiện quá trình xác định các yêu cầu kiến trúc:
17
Hình 1.4 Input và output của quá trình xác định yêu cầu kiến trúc
Việc xác định các yêu cầu kiến trúc chủ yếu dựa trên các yêu câu chức năng và các
yêu cầu khác do stakeholder cung cấp. Quá trình xác định yêu cầu kiến trúc sẽ đưa ra
môt tập các yêu cầu về kiến trúc của hệ thống. Tất nhiên thực tế các thông tin mà kiến
trúc sư cần vẫn chưa được tài liệu hóa đầy đủ ở mức này. Cách duy nhất để kiến trúc
sư phần mềm có được đầy đủ các thông tin cần thiết cho việc thiết kế kiến trúc hệ
thống đó là họ phải trực tiếp làm việc với các stakeholder và nhiệm vụ này sẽ khó

khăn hơn nhiều nếu như kiến trúc sư phần mềm không phải là một chuyên gia trong
lĩnh vực nghiệp vụ của dự án họ đang triển khai.
Không phải tất cá các yêu cầu kiến trúc đều có giá trị tương đương nhau, rất nhiều
trong số đó là các yêu cầu ở mức ưu tiên thấp hay không cần thiết. Vì vậy chúng ta
cần phần loại các yêu cầu theo mức độ ưu tiên khác nhau. Người ta thường sử dụng 3
mức độ sau để phần loại:
- Cao (high): hệ thống phải hỗ trợ các yêu cầu này, đây là các yêu cầu sống còn của hệ
thống.
- Trung bình: các yêu cầu này cần thiết ở một số trạng thái nhất định của hệ thống
nhưng không phải lúc nào nó cũng có ý nghĩa đối với hệ thống.
18
- Thấp: các yêu cầu ở mức này chủ yếu là các mong đợi của khách hàng và nhà phát
triển với hệ thống đang xây dựng. Tuy nhiên nó không có ý nghĩa quyết định với việc
thiết kế kiến trúc hệ thống.
3. Thiết kế kiến trúc
Nhiệm vụ của kiến trúc sư hệ thống là cực kì quan trọng và chất lượng của thiết kế
kiến trúc thực sự là vấn đề đề phải quan tâm. Các tài liệu yêu cầu hoàn hảo cũng như
công sức làm việc cùng stakeholder sẽ trở lên vô nghĩa nếu như rút cuộc một thiết kế
tồi được được ra.
Hình 2.5 chỉ ra các input và output của quá trình thiết kế kiến trúc.
Hình 1.5 Input và output của quá trình thiết kế kiến trúc
Có hai bước trong gia đoạn thiết kế kiến trúc chúng được lặp đi lặp lại một cách tự
nhiên. Bước đầu tiên liên quan tới việc lựa chọn một chiến lược tổng thể cho kiến trúc
dựa trên các mẫu kiến trúc đã được chứng minh (framework). Bước thứ 2 liên qua tới
việc xác định các thành phần riêng lẻ sẽ tạo nên ứng dụng, chúng phù hợp với
framework và phân bổ cho chúng các vai trò nhất định trong hệ thống. Đầu ra của
19
quá trình này là một tập các khung nhìn kiến trúc (thể hiện thiết kế kiến trúc) và các
tài liệu thiết kế nhằm giải thích cho thiết kế đưa ra.
4. Chuẩn hóa

Trong suốt tiến trình thiết kế kiến trúc, mục tiêu của pha chuẩn hóa là nhằm đảm
bảo kiến trúc đưa ra thỏa mãn các mục tiêu của hệ thống. Việc chuẩn hóa kiến trúc hệ
thống luôn luôn là một thử thách đối với các kiến trúc sư hệ thống bởi vì nó không thể
được kiểm thử một cách tường minh để xác định xem liệu nó đã hoàn toàn đáp ứng
các các yêu cầu hay chưa. Thậm chí nó có thể bao gồm các thành thành phần mới cần
được xây dựng hay các “hộp đen” các thành phần đó như là tầng trung gian, các thư
viện và các ứng dụng đã tồn tại sẵn.
20
Chương II. KỸ THUẬT XÂY DỤNG TẦNG TRUNG GIAN (MIDLEWARE)
I. Giới thiệu
Để minh họa cho vai trò của tầng trung gian trong kiến trúc phần mềm chúng ta
hãy đi xem xét quá trình xây dựng kiến trúc của một ngôi nhà.
Khi kiến trúc sư thiết kế một ngôi nhà, họ sẽ tạo các bản vẽ, về cơ bạn một bản vẽ
sẽ cho thấy cái nhìn từ các góc khác nhau của ngôi nhà, cấu trúc và kết cấu của từng
phần trong ngôi nhà. Sự thiết kế này dựa trên những yêu cầu thiết kế của ngôi nhà
chẳng hạn như các khoảng không, loại hình thiết kế (văn phòng, nhà thờ, trung tâm
mua sắm, nhà ở…), yêu cầu thẩm mĩ, yêu cầu chức năng, giới hạn tài chính. Những
bản vẽ này thể hiện cái nhìn trừu tượng của ngôi nhà mong đợi.
Người ta vẫn còn cần tới rất nhiều cô gắng khác để biến bản vẽ kiến trúc ở trên
thành cái gì đó mà thực tế có thể bắt đầu xây dựng ngôi nhà. Chẳng hạn, cần thiết kế
chi tiết của tường, sàn nhà , cầu thang, hệ thống điện nước… Và mỗi một thành phần
này lại cần có một sự thiết kế chi tiết như: vật liệu, các thành phần để xây dựng.
Vật liệu và các thành phần dùng để xây dựng này là các khối cơ bản dùng để xây
lên ngôi nhà chúng được thiết kế để cho người ta có thể xây lên bất cứ kiến trúc gì mà
họ mong muốn.
Chúng ta hãy nghĩ đến tầng trung gian trong kiến trúc phần mềm như là những cái
ống nước hay dây dẫn trong kiến trúc của một phần mềm. Lí do là:
- Tầng trung gian trong kiến trúc phần mềm đã được chứng minh là cách để gắn kết các
thành phần khác nhau giúp chúng có thể dễ dàng trao đổi thôi tin với nhau. Tầng trung
gian cung cấp những đường ống dẫn để vận chuyển dữ liệu giữa các thành phần và nó

có thể được sử dụng trong miền rộng lớn các loại ứng dụng khác nhau.
- Tầng trung gian có thể được sử dụng để nối kết một số lượng lớn các thành phần khác
nhau theo một cách hiệu quả và dễ hiểu. Các kết nói có thể là: một – một, một – nhiều
và nhiều – nhiều.
- Từ phối cảnh ứng dụng của người dùng, tầng trung gian hoàn toàn bị ẩn đi. Người sử
dụng chỉ cần chạy ứng dụng và họ không cần quan tâm xem dữ liệu bên trong nó được
trao đổi như thế nào. Khi mà phần mềm vẫn còn hoạt động bình thường, tầng trung
gian như một cơ sở hạ tầng không nhìn thấy từ mắt của người sử dụng.
- Người sử dụng chỉ nhận thức được sự tồn tại của tầng trung gian khi nó bị hỏng hóc ở
đâu đó. Điều này cũng giống như đường ống dẫn nước và đường dây điện trong ngôi
nhà vậy.
21
Tầng trung gian cung cấp một cơ sở hạn tầng sẵn sàng để cho việc kết nối các
thành phần phần mềm khác nhau nó có thể được sử dụng trong nhiều miền ứng dụng
khác nhau. Bởi vì nó được thiết kế một cách chung chung và có khá năng cấu hình
trên những nền tảng phổ biến của ứng dụng phần mềm.
II. Phân loại các kĩ thuật xây dựng tầng trung gian
Sở dĩ người ta sử dụng thuật ngữ tầng trung gian là bởi vì nó nằm giữa ứng dụng
và hệ điều hành tức là nằm giữa của kiến trúc ứng dụng.
Các miền ứng dụng khác nhau chứa đựng những kĩ thuật và công nghệ phức tạp
khác nhau điều này làm cho tầng trung gian cũng trở nên phức tạp hơn rất nhiều. Tuy
nhiên trong khuôn khổ tài liệu này chúng ta sẽ chỉ đi tìm hiểu về các xu hướng chính
trong xây dựng tần trung gian. Hình 2.1 đưa ra một sự phân loại các kĩ thuật này và
tên của một vài sản phẩm cho mỗi kĩ thuật này.
Hình 2.1 Các kĩ thuật xây dựng tầng trung gian
- Tầng chuyển vận (Transport layer) tạo nên một đường ống (pipe) cơ bản để gửi và di
chuyễn dữ liệu giữa các thành phần phần mềm. Những đường ống này tạo nên một
nền tảng cho phép di chuyển dữ liệu một các mềm dẻo và đơn giản trong các kiến trúc
ứng dụng phân bổ.
- Application server được xây dựng trên nền tảng các dịch vụ chuyển vận. Nó cung cấp

khả năng vận chuyển, bảo mật và dẫn đường. Nó hỗ trợ cho việc lập trình, xây dựng
các ứng dụng đa luồng dựa trên server.
- Message brokers khai thác các dịch vụ chuyển vận hoặc các application server và
thêm vào đó các máy sử lí thông điệp chuyên gia. Các máy này cung cấp khả năng
vận chuyển thông điệp nhanh, tính năng lập trình ngôn ngữ bậc cao để định nghĩa các
trao đổi, xử lí và điều hướng các thông điệp giữa các thành phần khác nhau của một
ứng dụng.
22
- Business process orchestrators (BPOs) là một sự ra tăng các tính năng của Message
brokers nhằm hỗ trợ nhiều ứng dụng kiểu luồng công việc khác nhau. Trong các ứng
dụng này, quá trình xử lí nghiệp vụ có thể mất nhiều giờ và nhiều ngày để hoàn thành.
BPOs cung cấp các công cụ để mô tả quá trình nghiệp vụ thực hiện chúng và quản lí
các trạng thái trun gian trong khi mỗi bước trong quá trình xử lí vẫn được thực hiện.
III. Các đối tượng phân bổ
Các đối tượng phân bổ là một kĩ thuật quan trọng trong các kĩ thuật xây dựng tầng
trung gian. Xây dựng tầng trung gian dựa trên các đối tượng phân bổ đã được sử dụng
từ trước năm 1990 và được mô tả tốt nhất bởi CORBA.
Xét một ví dụ đơn giản, một client gửi một yêu cầu lên server trên một đối tượng
yêu cầu thành phần môi giới (object request broker - ORB).
2.2 Các đối tượng phân bổ sử dụng CORBA
Trong CORBA những đối tượng phục vụ hỗ trợ giao diện được đặc tả sử dụng
ngôn ngữ đặc tả gian diện của CORBA (Interface description language – IDL), nó
định nghĩa những phương thức mà một đối tượng server hỗ trợ. Với đầu vào là các
tham số và trả về một kiểu dữ liệu nào đó. Một đoạn code đơn giản như sau:
23
Ở đây giao diện IDL định nghĩa một đối tượng CORBA với một hàm duy nhất
isAlive(), nó trả về một xâu và không nhận tham số nào. Một chương trình biên dịch
IDL sẽ được sử dụng để xử lí định nghĩa giao diện này. Trình biên dịch đó sinh ra một
bộ khung đối tượng trong một ngôn ngữ lập trình đích. Các bộ khung đối tượng cung
cấp cơ chế để gọi các phương thức trên server. Người lập trình viên sau đó phải viết

phần code cho mỗi phương thức của server trong một ngôn ngữ lập trình tự nhiên nào
đó.
Server phải tạo một thể hiện của của đối tượng Myservant và làm cho nó có khả
năng gọi được từ ORB.
Bây giờ client có thể khởi tạo một ORB và tham chiếu tới các phương thức nằm
trên server. Server lưu trữ một tham chiếu tới chính các phương thức của nó tại một
thư mục nào đó trên server. Client truy vấn tới thư mục này sử dụng tên logic của các
phương thức.
Lời gọi tớ các phương thức trên server trong có vẻ như được đồng bộ với các đối
tượng địa phương (local). Tuy nhiên nền tảng ORB vận chuyển, thống chế các yêu cầu
và các thông số kết hợp trên mạng đến server. Ở đây các mã lệnh được thực hiện và
kết quả được gửi trở lại client đang trong trạng thái chờ.
24
Trên đây là một mô tả rất đơn giản về kĩ thuật các đối tượng phân bổ. Có rất nhiều
các chi tiết khác cần phải được giải quyết để có thể triển khai xây dựng một hệ thống
thực. Chẳng hạn như xử lí ngoại lệ, định vị phương thức trên server, xử lí đa luồng…
Từ phối cảnh kiến trúc, để xây dựng một hệ thống hoàn chỉnh, ta cần giải quyết được
các vấn đề sau:
- Yêu cầu tới server là các lời gọi từ xa (remote call) thông qua ORB và môi trường
mạng điều này gây ra tác động đến hiệu năng của hệ thống. Do vậy ta cần thiết kế các
giao diện để các lời gọi từ xa có thể thủ nhỏ tối đa và hiệu năng hệ thống được nâng
cao.
- Trong bất kì các ứng dụng phân bổ nào, đều có thể xảy ra hiện tượng server hay mạng
bị hư hại trong một khoảng thời gian nhất định nào đó do vậy các ứng dụng cần có cơ
chế để đối phó với ngoại lệ này và có khả năng khởi động lại server.
- Nếu server lưu giữ các trạng thái của một tương tác giữa client và server (ví dụ đối
tượng customer lưu giữ tên, địa chỉ…), nếu server bị hư hại thì các trạng thái này có
thể mất vì vậy cần có một cơ chế cho phép khôi phục các trạng thái trước đó.
IV. Message-Oriented Middleware
Message-oriented middleware (MOM) là một trong những kĩ thuật then chốt

hướng tới việc xây dựng các hệ thống ứng dụng thương mại trên phạm vi rộng lớn. Nó
giúp kết dính các ứng dụng độc lập trên nhiều nền tảng khác nhau vào trong một hệ
thống tích hợp chung. Người sử dụng ko cần viết lại các ứng dụng có sẵn hay tạo ra
những sự thay đổi để các ứng dụng này có thể chạy trong hệ thống ứng dụng thương
mại rộng lớn. Bởi vì nó được thay thế bằng việc tạo ra các hàng đợi (queue) giữa
người gửi và người nhận, đây là một mức trung gian được tạo ra trong suốt quá trình
giao tiếp. MOM tạo ra các software bus để tích hợp các hệ thống phần mềm với nhau.
Hình 2.3 minh họa ứng dụng của MOM trong các tổ chức
25