Nghiên cứu và thiết kế kiến trúc phần mềm cho các hệ thống lớn và phức tạp

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






VŨ VĂN LĨNH




NGHIÊN CỨU VÀ THIẾT KẾ KIẾN TRÚC PHẦN
MỀM CHO CÁC HỆ THỐNG LỚN VÀ PHỨC TẠP




LUẬN VĂN THẠC SĨ








Hà Nội - 2011

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





VŨ VĂN LĨNH
NGHIÊN CỨU VÀ THIẾT KẾ KIẾN TRÚC PHẦN
MỀM CHO CÁC HỆ THỐNG LỚN VÀ PHỨC TẠP



Ngành CÔNG NGHỆ THÔNG TIN
Chuyên ngành CÔNG NGHỆ PHẦN MỀM
Mã số 60 48 10




LUẬN VĂN THẠC SĨ


NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. Phạm Ngọc Hùng

Hà Nội - 2011




iii
MỤC LỤC

DANH MỤC HÌNH VẼ v
DANH MỤC BẢNG vi
CHƢƠNG 1: GIỚI THIỆU 1
1.1 Đặt vấn đề 1
1.2 Nội dung nghiên cứu 3
1.3 Cấu trúc luận văn 3
CHƢƠNG 2: TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN MỀM 5
2.1 Định nghĩa về kiến trúc phần mềm 5
2.2 Các thành phần chính trong thiết kế kiến trúc phần mềm 5
2.2.1 Thành phần 7
2.2.2 Kết nối 7
2.2.3 Giao diện 10
2.2.4 Cấu hình 11
2.3 Một số kiểu kiến trúc điển hình 11
2.4 Các bƣớc thiết kế kiến trúc phần mềm 13
2.5 Đánh giá ƣu nhƣợc điểm của SAD 22
CHƢƠNG 3: TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ, XỬ LÝ ẢNH
TRONG Y TẾ 24
3.1 Quy trình khám, chữa bệnh 24
3.2 Phân tích xử lý nghiệp vụ 25

CHƢƠNG 4: THIẾT KẾ KIẾN TRÚC CHO HỆ THỐNG QUẢN LÝ, XỬ LÝ
ẢNH TRONG Y TẾ 29
4.1 Thiết kế kiến trúc tổng thể cho hệ thống 29
4.2 Thiết kế cho chức năng lớn trong hệ thống 34
CHƢƠNG 5: CÀI ĐẶT KIẾN TRÚC PHẦN MỀM 40
5.1 Cách thức cài đặt kiến trúc phần mềm 40
5.2 Phƣơng pháp đi từ thiết kế kiến trúc tới thiết kế chi tiết 40
5.3 So sánh SAD và SDD 43
KẾT LUẬN 45
TÀI LIỆU THAM KHẢO 47
PHỤ LỤC 48



iv
BẢNG CÁC CHỮ VIẾT TẮT



STT
Từ viết tắt
Tiếng anh
Nghĩa tiếng Việt
1
SAD
Software Architecture Design
Thiết kế kiến trúc phần mềm
2
SDD
Software Detailed Design

Thiết kế chi tiết phần mềm
3
SRS
System Requirement Specification
Đặc tả yêu cầu hệ thống
4
VB6
Visual Basic 6.0
Ngôn ngữ lập trình visual
basic 6.0
5
SS
Sub System
Hệ thống con
6
UML
Unifield Modeling Language
Ngôn ngữ mô hình hóa
thống nhất


v
DANH MỤC HÌNH VẼ
Hình 1.1: Mô hình phát triển phần mềm hình chữ V [5] 1
Hình 2.1: Thiết kế kiến trúc phần mềm hệ thống quản lý thông tin bệnh nhân. 6
Hình 2.2: Không gian tùy chọn của thủ tục gọi kết nối [2]. 8
Hình 2.3: Không gian tùy chọn của kết nối sự kiện [2]. 9
Hình 2.4: Không gian tùy chọn của kết nối truy cập dữ liệu [2]. 10
Hình 2.5: Kiến trúc gọi trả lại [2]. 11
Hình 2.6: Kiến trúc phân tầng [2]. 12

Hình 2.7: Các bƣớc thiết kế kiến trúc phần mềm [3]. 15
Hình 3.1: Quy trình khám chữa bệnh. 24
Hình 3.2: Sơ đồ ca sử dụng của chức năng quản lý thông tin bệnh nhân. 26
Hình 3.3: Sơ đồ ca sử dụng của chức năng quản lý quá trình chụp ảnh 26
Hình 3.4: Sơ đồ ca sử dụng của chức năng thao tác với ảnh. 27
Hình 4.1: Kịch bản chụp ảnh. 31
Hình 4.2: Kiến trúc tổng thể của hệ thống. 33
Hình 4.3: Tình huống ngƣời dùng, nghiệp vụ, hệ thống trên màn hình kết nối
ảnh. 36





vi
DANH MỤC BẢNG


Bảng 2.1: Các thành phần trong thiêt kế kiến trúc hệ thống quản lý thông tin
bệnh nhân 6
Bảng 2.2: Đặc điểm của kiểu kiến trúc gọi trả lại 12
Bảng 2.3: Đặc điểm của kiểu kiến trúc phân tầng 13
Bảng 2.4: Khung kiến trúc của các điểm nổi bật [3] 18
Bảng 4.1: Đặc điểm của thiết kế kiến trúc tổng thể 34
Bảng 4.2: Đặc điểm của các thành phần trong thiết kế kiến trúc khi mở màn hình
kết nối 38
Bảng 5.1: Ánh xạ các thành phần trong SAD với SDD 40
Bảng 5.2: So sánh SAD với SDD 44
1

CHƢƠNG 1: GIỚI THIỆU
1.1 Đặt vấn đề
Trong phát triển phầm mềm, có rất nhiều mô hình phát triển khác nhau nhƣ
mô hình thác nƣớc, mô hình xoắn ốc, … Hiện nay, mô hình phát triển phần mềm
đƣợc sử dụng rộng rãi là mô hình chữ V, đƣợc cải tiến từ mô hình thác nƣớc.
Trong mô hình phát triển phần mềm hình chữ V, các công việc đƣợc chia thành
các giai đoạn khác nhau, mỗi giai đoạn sẽ thực hiện một số công việc cụ thể. Ví
dụ giai đoạn thiết kế kiến trúc (Architecture Design - AD) sẽ thực hiện chuyển
hóa các đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS)
thành các mô tả thiết kế kiến trúc đƣợc thể hiện thông qua các hình vẽ, tài liệu
mô tả, … Dựa vào kết quả thiết kế kiến trúc đó, các nhà thiết kế chi tiết có thể
tạo ra các bản thiết kế chi tiết cho phần mềm, phục vụ cho quá trình cài đặt
chƣơng trình đƣợc dễ dàng, thuận tiện.

Hình 1.1: Mô hình phát triển phần mềm hình chữ V [5].

Dựa vào hình 1.1 ta thấy thiết kế kiến trúc chính là một giai đoạn trong mô
hình phát triển phần mềm.
Khi xây dựng và phát triển phần mềm nếu phát triển đúng và đầy đủ theo các
giai đoạn của mô hình phần mềm đang áp dụng, đặc biệt là giai đoạn thiết kế,
phần mềm sẽ tránh đƣợc sự rủi ro và có chất lƣợng tốt. Trên thực tế chúng ta
thƣờng làm việc không có kế hoạch cụ thể, làm tới đâu nghĩ tới đó, xem nhẹ
bƣớc thiết kế, coi trọng cài đặt mã nguồn. Kết quả mà chúng ta thu đƣợc thƣờng
là một khối mã nguồn rối rắm hoặc nếu có thì cũng chỉ là một chƣơng trình nhỏ
2


với vài chức năng cần thiết, rất khó cho bảo trì và tái sử dụng. Đôi khi, chúng ta
làm việc có phần chủ quan và mang tính tự phát, nhƣng nếu bình tĩnh nghiên

cứu, làm việc có kế hoạch và áp dụng các tiến trình thiết kế phần mềm vào trong
bài toán của mình, chúng ta có thể thấy đƣợc nhiều hƣớng đi, nhiều cách giải
quyết, mà có thể đó là những lời giải tối ƣu mà trƣớc đó chúng ta không thấy
hoặc đã bỏ qua. Điều quan trọng hơn cả là chúng ta có thể theo dõi và kiểm soát
đƣợc những gì đang xảy ra. Thiết kế là đồng nghĩa với việc tiết kiệm thời gian
và tiền bạn. Nếu không có bản thiết kế hoặc thiết kế không tốt, khi có thay đổi
yêu cầu một vài chức năng trong phần mềm hoặc nâng cấp, cải tiến các chức
năng đó, chúng ta phải làm lại một chƣơng tình hoàn toàn mới hoặc phải nghiên
cứu lại toàn bộ mã nguồn, điều đó đồng nghĩa với việc tiêu tốn của chúng ta khá
nhiều thời gian và tiền bạc. Mặt khác dƣới một góc nhìn rộng và bao quát hơn,
thông qua việc phản ánh các kết quả của quá trình phân tích, thiết kế thƣờng xác
định cho chúng ta nhiều hƣớng đi, nhiều cách thức giải quyết trên cùng một bài
toán, từ đó cho phép chúng ta chọn đƣợc cách thức tốt nhất và con đƣờng ngắn
nhất để đi tới đích [1].
Với sự phát triển nhanh của công nghệ thông tin, ngày nay nhiều lĩnh vực
trong đời sống đã đƣợc tin học hóa, giúp cho quá trình xử lý công việc nhanh và
đơn giản hơn, giúp cho tiết kiệm rất nhiều thời gian và tiền bạc.
Với sự phát triển của kinh tế, ngày nay cuộc sống con ngƣời đƣợc cải thiện
rất nhiều. Nhu cầu về chăm sóc, khám chữa bệnh, phát hiện, chuẩn đoán và chữa
trị bệnh sớm đƣợc tăng lên, khi đó tin học là cánh tay đắc lực giúp cho việc này.
Năm 2009, khi tôi đang làm việc tại công ty phần mềm FPT, chúng tôi nhận
đƣợc đơn đặt hàng của khách hàng bên Nhật Bản, yêu cầu nâng cấp, xây dựng
chức năng mới cho hệ thống quản lý, xử lý ảnh trong y tế. Khi nhận đƣợc bài
toán, chúng tôi đã tiến hành khảo sát và phân tích thấy hệ thống cũ có một số
hạn chế nhƣ sau:
Thứ nhất hệ thống là một chƣơng trình hoàn chỉnh, với mã nguồn rất lớn, hỗn
độn nhƣng rất ít tài liệu mô tả về hệ thống. Kiến thức về các chức năng, xử lý
nghiệp vụ của hệ thống không đƣợc viết thành tài liệu, mỗi ngƣời hiểu một phần
rời rạc. Khi phát triển, phần mềm đƣợc phát triển dựa trên hai công nghệ, môi
trƣờng lập trình khác nhau. Phần giao diện giao tiếp với ngƣời dùng đƣợc viết

bằng VB6, sử dụng nhiều thành phần sẵn có trong VB6. Ngoài ra sử dụng rất
nhiều các thƣ viện của hãng thứ ba nên tính đồng nhất không cao, thƣờng xuyên
phải nâng cấp các phiên bản. Cùng với thời gian phần cứng đƣợc thay đổi nhiều,
khi đó VB6 không thể đáp ứng với phần cứng với các phiên bản mới hơn. Mặt
3


khác có nhiều loại màn hình kích thƣớc khác nhau, chƣơng trình phải đáp ứng
sự tùy biến sao cho phù hợp với các loại màn hình đó, việc này VB6 làm rất khó
khăn, gần nhƣ không thể. Hơn nữa, VB6 là ngôn ngữ lập trình hƣớng thủ tục
nên khả năng mở rộng kém, khi thêm các chức năng mới rất khó khăn. Phần
thuật toán xử lý, lƣu trữ, thao tác với ảnh thì viết bằng C++. Các phần viết rời
rạc, sự sử dụng lại kém, hình nhƣ không có.
Hạn chế thứ hai là quá trình bảo trì và nâng cấp vô cùng khó khăn, khi mở
rộng thì mất nhiều công sức, thậm chí làm ảnh hƣớng tới chức năng đã có, có
thể dẫn tới xử lý sai.
Những khó khăn này đặt ra cho chúng tôi phải có phƣơng pháp đánh giá,
hƣớng tiếp cận phù hợp để có thể nâng cấp, xây dựng chức năng mới cho phù
hợp và xử lý chính xác. Cuối cùng, sau một thời gian phân tích, đánh giá nghiêm
túc, chúng tôi đã tìm ra đƣợc hƣớng đi phù hợp, đó là phải làm tốt ngay từ giai
đoạn phân tích, thiết kế, đặc biệt là thiết kế kiến trúc phần mềm.
1.2 Nội dung nghiên cứu
Luận văn tập trung nghiên cứu lý thuyết về thiết kế kiến trúc phần mềm, các
thành phần chính trong thiết kế kiến trúc phần mềm, đặc điểm của một số kiểu
kiến trúc phần mềm tiêu biểu, các bƣớc thiết kế kiến trúc phần mềm và đánh giá
ƣu nhƣợc điểm của thiết kế kiến trúc phần mềm. Sau đó luận văn tập trung vào
quá trình khảo sát, phân tích hệ thống quản lý, xử lý ảnh trong y tế. Từ kết quả
khảo sát, phân tích đó, luận văn trình bày chi tiết quá trình áp dụng các bƣớc
thiết kế kiến trúc phần mềm vào bài toán quản lý, xử lý ảnh trong y tế.
Luận văn cũng mô cách thức cài đặt thiết kế kiến trúc phần mềm, đề xuất

phƣơng pháp, các bƣớc đi từ thiết kế kiến trúc tới thiết kế chi tiết sau cho hiệu
quả.
1.3 Cấu trúc luận văn
Các phần còn lại của luận văn có cấu trúc nhƣ sau:
Chƣơng 2 trình bày các khái niệm cơ bản về kiến trúc phần mềm, thiết kế
kiến trúc phần mềm, một số kiểu kiến trúc phần mềm tiêu biểu. Sau đó trình bày
các bƣớc thiết kế kiến trúc phần mềm và đánh giá ƣu nhƣợc điểm của thiết kế
kiến trúc phần mềm.
Chƣơng 3 mô tả về quy trình khám chữa bệnh trong y tế. Phân tích xử lý
nghiệp vụ của hệ thống quản lý, xử lý ảnh trong y tế.
Chi tiết quá trình áp dụng các bƣớc thiết kế kiến trúc phần mềm đã nêu ở
4


chƣơng 2 để thiết kế kiến trúc cho hệ thống quản lý, xử lý ảnh trong y tế đƣợc
mô tả chi tiết trong chƣơng 4.
Chƣơng 5 mô tả cách thức cài đặt kiến trúc phần mềm. Đề xuất phƣơng pháp,
các bƣớc đi từ thiết kế kiến trúc tới thiết kế chi tiết sao cho hiệu quả.
Tóm tắt kết quả đã đạt đƣợc, trình bày những hạn chế và hƣớng nghiên cứu
phát triển trong tƣơng lai sẽ đƣợc trình bày trong phần kết luận.
5


CHƢƠNG 2: TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN MỀM
2.1 Định nghĩa về kiến trúc phần mềm
Kiến trúc của hệ thống phần mềm là tập hợp các quyết định thiết kế cơ bản
về hệ thống [2]. Có ba hiểu biết cơ bản về kiến trúc phần mềm là mỗi ứng dụng
có một kiến trúc, mỗi ứng dụng có ít nhất một kiến trúc sƣ và kiến trúc không
phải là một giai đoạn của phát triển phần mềm.
Kiến trúc phần mềm là các kế hoạch chi tiết xây dựng một hệ thống phần

mềm và tiến hóa. Các quyết định thiết kế bao gồm mọi khía cạnh của hệ thống
đƣợc phát triển bao gồm:
i. Kiến trúc hệ thống: Ví dụ các thành phần kiến trúc nên đƣợc bố trí và
tổng hợp chính xác.
ii. Hành vi chức năng: Ví dụ tiến trình xử lý dữ liệu, lƣu trữ, sự ảo hóa sẽ
đƣợc thực hiện một cách tuần tự chính xác.
iii. Sự tƣơng tác: Ví dụ sự giao tiếp bao quanh tất cả các phần tử hệ thống sẽ
đƣợc phát tỏa chỉ cần dùng một sự kiện thông báo.
iv. Thuộc tính phi chức năng: Ví dụ sự phụ thuộc hệ thống sẽ đƣợc đảm bảo
bởi sự nhân bản chức năng xử lý.
v. Triển khai hệ thống: Ví dụ thành phần giao diện ngƣời dùng sẽ đƣợc xây
dựng bởi công cụ Java Swing hay Visual C#.
Kiến trúc phần mềm có phạm vi rộng lớn, xuyên suốt trong quá trình phát
triển phần mềm. Luận văn chỉ tập trung chủ yếu vào một thành phần quan trọng
trong kiến trúc phần mềm là thiết kế kiến trúc phần mềm.
2.2 Các thành phần chính trong thiết kế kiến trúc phần mềm
Thiết kế kiến trúc phần mềm gồm bốn thành phần chính là thành phần
(component), kết nối (connector), giao diện (interface) và cấu hình
(configuration).
Hình 2.1 mô tả một ví dụ về kiến trúc của hệ thống quản lý thông tin bệnh
nhân đƣợc thiết kế theo mô hình ba lớp gồm lớp trình diễn (Presentaion), lớp xử
lý nghiệp vụ (Business) và lớp truy cập, xử lý dữ liệu (Data Access Layer -
ADL). Lớp trình diễn sẽ có nhiệm vụ giao tiếp với ngƣời dùng, nhận yêu cầu từ
ngƣời dùng và hiển thị kết quả cho ngƣời dùng. Khi nhận đƣợc yêu cầu của
ngƣời dùng (thêm mới thông tin về bệnh nhân), lớp trình diễn sẽ yêu cầu lớp xử
lý nghiệp vụ xử lý và nhận kết quả trả về từ lớp nghiệp vụ, sau đó hiển thị kết
6


quả cho ngƣời dùng. Lớp xử lý nghiệp vụ có nhiệm vụ xử lý nghiệp vụ của bài

toán, lớp này sẽ nhận các yêu cầu của lớp trình diễn, xử lý các thao tác liên quan
tới nghiệp vụ, gửi yêu cầu tới tầng truy cập dữ liệu để lấy, cập nhật dữ liệu nếu
cần, sau đó trả kết quả về cho lớp trình diễn. Lớp truy cập dữ liệu có nhiệm vụ
đọc, cập nhật dữ liệu từ các file hoặc cơ sở dữ liệu (CSDL). Sau đó trả về kết
quả cho lớp xử lý nghiệp vụ.
Presentation
(Button Save)
Business
(SaveData)
DAL
(SaveData)
Database
(Server 1)
Database
(Server 2)
Connector
Interface
Component Configuration
In: PatientInfo
Out: ErrorCode
In: PatientInfo
Out: ErrorCode
In: PatientInfo
Out: ErrorCode
In: PatientInfo
Out: ErrorCode
Procedure call
Procedure call
Data Access
Data Access

Hình 2.1: Thiết kế kiến trúc phần mềm hệ thống quản lý thông tin bệnh nhân.
Các thành phần ở hình 2.1 đƣợc mô tả chi tiết trong bảng 2.1 dƣới đây.
Bảng 2.1: Các thành phần trong thiêt kế kiến trúc hệ thống quản lý thông tin
bệnh nhân

Kiểu kiến trúc
Layered
Thành phần
Các lớp Presentaion, Business, DAL và CSDL (Server 1,
Server 2).
Kết nối
Lớp trình diễn, lớp xử lý nghiệp vụ, lớp truy cập dữ liệu
kết nối với nhau theo cơ chế truyền thông điệp của lập trình
hƣớng đối tƣợng. Riêng lớp truy cập dữ liệu sẽ kết nối với
7


CSDL theo cơ chế truy cập dữ liệu để thực hiện truy vấn,
cập nhật dữ liệu.
Giao diện
Đầu vào của lớp xử lý nghiệp vụ, lớp truy cập dữ liệu và
CSDL là các thông tin về bệnh nhân (PatientInfo) nhƣ: Mã
bệnh nhân, tên bệnh nhân…
Đầu ra tƣơng ứng của các lớp đó là các mã lỗi. Khi các
phƣơng thức (SaveData) thực thi xong sẽ trả về các mã lỗi
để cho các thành gọi tới nó có thể biết đƣợc trạng thái của
quá trình thêm mới dữ liệu là thành công hay thất bại.
Cấu hình
Cấu hình sẽ thiết lập các quy định để các thành phần hoạt

động với nhau. Cấu hình sẽ đƣợc thể hiện một file cấu hình
của hệ thống, dựa vào đó lớp truy cập dữ liệu sẽ tƣơng tác
với dữ liệu thuộc thành phần nào (Server hay Server 2).

Sau đây mô tả chi tiết khái niệm về thành phần, kết nối, giao diện và cầu
hình.
2.2.1 Thành phần
Thành phần tóm lƣợc một tập các chức năng con hoặc dữ liệu của hệ thống
và giới hạn sự truy nhập tới các tập con (thành phần con) thông qua định nghĩa
các giao diện.
Thành phần có thể là các hệ thống con (Sub System - SS) trong một hệ thống
lớn, hoặc các dựa án (project), gói (package) trong một SS.
2.2.2 Kết nối
Kết nối là phƣơng tiện trung gian lắp ghép các thành phần với nhau và hỗ trợ
tƣơng tác giữa các thành phần đó. Kết nối cũng thực hiện truyền điều khiển và
dữ liệu giữa các thành phần.
Dựa trên cách thức mà các kết nối thực hiện các dịch vụ tƣơng tác, các loại
kết nối và đặc điểm của kết nối đƣợc trình bày trong [2], có tám loại kết nối: thủ
tục gọi kết nối (Procedure call), sự kiên (Event), truy cập dữ liệu (Data Access),
kết hợp (Linkage), luồng (Stream), phân xử (Arbitrator), thích nghi (Adaptor),
phân tán (Distributor). Dƣới đây sẽ mô tả các kết nối điển hình

8


Thủ tục gọi kết nối (Procedure call connectors):
Thủ tục gọi kết nối là mô hình luồng điều khiển giữa các thành phần thông
qua các kĩ thuật gọi khác nhau, là các tọa độ kết nối (coordination connectors).
Ngoài ra chúng còn thực hiện truyền dữ liệu giữa các thành phần tƣơng tác qua
việc sử dụng các tham số và giá trị trả về. Ví dụ phƣơng thức hƣớng đối tƣợng,

phân nhánh và thực thi trong Unix nơi mà có môi trƣờng giống nhau, hay sự gọi
lại (call back) trong sự kiện hệ thống.
Các thủ tục gọi thƣờng đƣợc dùng làm cơ sở cho kết nối hỗn hợp, chẳng hạn
nhƣ các thủ tục gọi từ xa. Không gian tùy chọn của thủ tục gọi kết nối đƣợc mô
tả trong hình 2.2.
Service Type Dimension
Subdimension
Value
Communication
Coordination
Procedure call
Parameters
Data transfer
Reference
Value
Name
Semantics
Default values
Keyword parameters
Inline parameters
Return values
Invocation record
Push from L to R
Push from R to L
Has table
Entry point
Multiple
Single
Invocation
Explicit

Implicit
Synchronicity
Asynchronous
Synchronous
Cardinatily
Fan out
Fan in
Accessibility
Private
Protected
Public

Hình 2.2: Không gian tùy chọn của thủ tục gọi kết nối [2].
Kết nối sự kiện (Event Connector)
Tƣơng tự nhƣ kết nối thủ tục, kết nối sự kiện tác động lên luồng xử lý giữa
các thành phần và cung cấp các dịch vụ phối hợp.
Các kết nối sự kiện cũng khác nhau từ các thủ tục gọi trong đó kết nối ảo
đƣợc hình thành giữa các thành phần quan tâm đến các chủ đề cùng một sự kiện,
những kết nối đó có thể xuất hiện và biến mất tự động tùy thuộc vào sự quan
tâm thay đổi của các thành phần trong các chủ đề của cùng một sự kiện của các
9


thành phần. Không gian tùy chọn của kết nối sự kiện đƣợc mô tả chi tiết trong
hình 2.3.

Service Type Dimension
Subdimension
Value
Communication

Coordination
Event
Cardinatily
Producers
Observers
Event patterns
Best effort
Exactly once
At most once
Delivery
Outgoing
Incoming
Notification
Synchronicity
Asynchronous
Synchronous
Cardinatily
Fan out
Fan in
Causality
Absolute
Relative
Page faults
At least once
Priority
Time out Asynchronous
Polled
Publish/subscribe
Center update
Queued dispatch

Mode
Hardware
Software
Interrupts
Traps
Signals
GUI input/output
Triggers

Hình 2.3: Không gian tùy chọn của kết nối sự kiện [2].
Kết nối truy cập dữ liệu (Data access Connector)
Kết nối truy cập dữ liệu cho phép các thành phần truy cập dữ liệu đƣợc duy
trì bởi thành phần lƣu trữ dữ liệu, do đó chúng cung cấp các dịch vụ truyền
thông.
Trƣớc khi quyết định lƣu trữ dữ liệu phải tính đến cách thức sẽ truy cập vào
dữ liệu đó ra sao và sẽ dọn dẹp dữ liệu thế nào sau khi truy cập đƣợc hoàn thành,
dữ liệu đƣợc lƣu trữ liên tục hoặc tạm thời. Ví du truy cập dữ liệu liên tục bao
gồm cơ chế truy vấn nhƣ dữ liệu để truy cập CSDL, truy cập dữ liệu trong kho
nhƣ một kho chứa dữ liệu. Truy cập dữ liệu tạm thời bao gồm truy cập vùng nhớ
(heap hoặc stack) và thông tin vùng đệm. Không gian tùy chọn của kết nối truy
10


cập dữ liệu đƣợc mô tả chi tiết trong hình 2.4.
Service Type Dimension
Subdimension
Value
Communication
Coordination
Data Acces

Locality
Thread specific
Process specific
Global
Accessor
Mutator
Register
Access
Transient
Persistent
Accessibility
Repository access
File I/O
Life Cycle
Initialiaztion
Termination
Cache
Availability
Dynamic data exchange
Database Access
Private
Protected
Public
Mode
Defines
Uses
DMA
Heap
Stack

Hình 2.4: Không gian tùy chọn của kết nối truy cập dữ liệu [2].
2.2.3 Giao diện
Giao diện là điểm giao tiếp giữa hai thành phần với nhau. Các thành phần sẽ
hạn chế sự truy cập vào các thành phần con trong đó bằng cách chỉ đƣa ra một
số giao diện chính.
Giao diện cũng thể hiện sự liên kết lỏng lẻo hay chặt chẽ giữa các thành phần.
Trong thiết kế kiến trúc chúng ta thƣờng tuân thủ các nguyên lý hƣớng đối
tƣợng, các thành phần và mô đun (module) rất linh động và độc lập với nhau.
Tuy nhiên, chúng cũng đem lại một số rắc rối do sự linh động và khả năng tái sử
dụng trong phần mềm cũng đồng nghĩa với việc xuất hiện hàng loạt các lớp trừu
tƣợng, các phân tầng trong mô hình thiết kế. Các phân tầng trừu tƣợng này sẽ
làm giảm hiệu năng và tốc độ của hệ thộng. Do đó trong quá trình thiết kế kiến
trúc phần mềm phải cân nhắc phần mềm nào cần ƣu tiên sự linh động và khả
năng tái sử dụng, phần mềm nào ƣu tiên tốc độ và hiệu năng để đƣa ra thiết kế
phù hợp nhất.
11


2.2.4 Cấu hình
Cấu hình là một bộ các thiết lập cụ thể giữa các thành phần và kết nối của
một hệ thống kiến trúc phần mềm.
Một cấu hình có thể đƣợc biểu diễn nhƣ một đồ thị trong đó các nút đại diện
cho các thành phần và kết nối.
2.3 Một số kiểu kiến trúc điển hình
Một kiểu kiến trúc là một tập các quyết định thiết kế kiến trúc áp dụng trong
một ngữ cảnh phát triển phần mềm hoặc dựa trên sự ràng buộc của các quyết
định thiết kế kiến trúc cụ thể cho một hệ thống cụ thể trong phạm vi thiết kế đó.
Tập các quyết định thiết kế cũng dựa trên sự suy luận lợi ích chất lƣợng trong
mỗi kết quả hệ thống.
Kiểu kiến trúc đƣợc trình bày trong [2], có tám kiểu kiến trúc cơ bản là: Main

Program and Subroutines, Layered, Data-flow styles, Shared memory,
Interpreter, Implicit invocation, Peer-to-peer, “Derived” styles. Trong khi đó,
kiểu kiến trúc đƣợc tình bày trong [4] và [6], phân chia các kiểu kiến trúc theo
nhóm dựa trên đặc điểm của kiểu kiến trúc.
Kiểu kiến trúc gọi – trả lại (Main Program and Subroutines)
Đây là kiểu kiến trúc truyền thống bao gồm: Mô hình gọi – trả lại (Main
program and subroutines) và hƣớng đối tƣợng (object-oriented). Hình 2.5 minh
họa kiểu kiến trúc gọi – trả lại.
Main program
Routine 1 Routine 2 Routine 3
Routine 1.1 Routine 1.2
Routine 3.1
Routine 3.2
Procedure call
Procedure call
Procedure call
Procedure call
Procedure call
Procedure call
Procedure call
In: none
Out: Ovalue1
In: IValu2
Out: OValue2
In: IValue3
Out: OValue3
In: none
Out: none
In: none
Out: noe

In: IValue32
Out: OValue32

Hình 2.5: Kiến trúc gọi trả lại [2].
12


Đặc điểm của kiểu kiến trúc gọi trả lại đƣợc mô tả chi tiết trong bảng 2.2.
Bảng 2.2: Đặc điểm của kiểu kiến trúc gọi trả lại
Kiểu kiến trúc
Program and subroutines
Đặc điểm
Theo phong cách hƣớng thủ tục, chức năng lớn đƣợc
phân rã thành các chức năng con. Chƣơng trình gồm một
chƣơng trình chính và gọi tới các chƣơng trình con.
Thành phần
Chƣơng trình chính và các chƣơng trình con.
Kết nối
Lời gọi hàm.
Lý do lựa chọn
Đơn giản, dễ hiểu.
Dễ sử dụng với các hệ thống vừa và nhỏ, độ phức tạp
không lớn.

Kiểu kiến trúc phân tầng (Layered)
Kiểu kiến trúc phân tầng là phân chia các mối quan tâm của ứng dụng thành
các lớp độc lập. Hình 2.6 minh họa kiểu kiến trúc phân tầng.

Network
Procedure call

Server
Client 1 Client 2 Client n
Procedure call
Procedure call
Procedure call

Hình 2.6: Kiến trúc phân tầng [2].
13


Đặc điểm của kiểu kiến trúc phân tầng đƣợc mô tả chi tiết trong bảng 2.3.
Bảng 2.3: Đặc điểm của kiểu kiến trúc phân tầng
Kiểu kiến trúc
Layer
Đặc điểm
Phân chia các mối quan tâm của ứng dụng thành lớp độc
lập.
Thành phần
Các tầng (layer). Các tầng này có thể là các hệ thống con
trong hệ thống lớn hoặc là các dự án (project) hoặc gói
(package) trong hệ thống nhỏ.
Kết nối
Các giao thức của tầng tƣơng tác.
Lý do lựa chọn
Với ứng dụng phức tạp, ta muốn giảm thiểu sự phức tạp
bằng cách nhóm các chức năng có nhiệm vụ và tính chất
giống nhau vào chung một tầng.
Để cải thiện khả năng bảo trì và mở rộng ứng dụng bằng
cách giảm thiểu phụ thuộc.
Khi đã có những ứng dụng trƣớc đó, cung cấp sẵn tình

huống xử lý nghiệp vụ thông qua các giao diện dịch vụ.
Ứng dụng phải hỗ trợ nhiều loại máy khách (client) và
thiết bị khác nhau.
Muốn thực hiện các quy tắc nghiệp vụ phức tạp vào quá
trình.

2.4 Các bƣớc thiết kế kiến trúc phần mềm
Đầu năm 2009, khi đó tôi may mắn đƣợc tham gia vào dự án về xử lý ảnh
trong y tế cho khách hàng Nhật Bản. Hệ thống này rất lớn, cực kì phức tạp nên
có sự tham gia phát triển của nhiều công ty phần mềm ở Nhật Bản, Trung Quốc
và Việt Nam. Công ty tôi chịu trách nhiệm cho một số hệ thống con trong hệ
thống lớn này. Trƣớc đó chúng tôi chỉ quen với việc làm thiết kế chi tiết
(Software Detailed Desgin – SDD) rồi thực hiện viết mã nguồn. Khi khách hàng
yêu cầu chúng tôi viết tài liệu về thiết kế kiến trúc phần mềm (Software
Architecture Design – SAD) cho phần của mình thì tất cả đều bỡ ngỡ, không
biết SAD là gì. Ngƣời quản trị dự án của chúng tôi đã xin sự hỗ trợ từ phía tổng
14


công ty, hi vọng với một công ty phần mềm lớn nhất Việt Nam nhƣ Fsoft thì có
nhiều ngƣời biết. Nhƣng câu trả lời chúng tôi nhận đƣợc là không nhiều ngƣời
biết về vấn đề này, ngƣời có kinh nghiệm thì rất ít và đang tham gia các dự án
khác nên không thể hỗ trợ. Tự thân vận động, chúng tôi cũng thử làm, nhƣng kết
quả thì tạo ra một thứ SAD mà nhƣ SDD, SAD đƣợc tạo ra sau khi có SDD
(điều này đi ngƣợc với quy trình bình thƣờng). Sau lần thất bại này, chúng tôi đã
cử ngƣời sang làm việc trực tiếp với khách hàng để học hỏi. May mắn cho
chúng tôi là khách hàng là công ty phần mềm lớn của Nhật Bản, nơi đó có
những bậc thầy về SAD. Với sự cố gắng hết mình tìm hiểu, tham khảo SAD của
hệ thống cũ, cộng với sự giúp đỡ nhiệt tình của khách hàng, khoảng một năm
sau chúng tôi có sản phẩm SAD hoàn chỉnh, đƣợc khách hàng đánh giá cao, rất

tin tƣởng vào khả năng thành công.
Cá nhân tôi trƣớc đó là lập trình viên, thực hiện tạo SDD và viết mã nguồn.
Sau đó tôi đƣợc hƣớng dẫn, chỉ bảo về SAD, đọc tham khảo và tìm hiểu kĩ về
các tài liệu SAD trƣớc đó. Do hệ thống lớn và phức tạp, có nhiều công ty tham
gia phát triển nên hệ thống đƣợc chia ra làm nhiều SS, mỗi bên chịu trách nhiệm
vài SS. Và mỗi SS này cũng rất lớn và phức tạp, nên chúng đƣợc phân chia ra
thành các mô đun lớn. Mỗi SS đều có SAD tổng quan, sau đó mỗi mô đun lớn
trong SS này sẽ có SAD riêng, dựa vào SAD tổng quan đó. Tôi đƣợc giao phụ
trách một nhóm gồm gần mƣời thành viên, chịu trách nhiệm viết SAD cho nhiều
mô đun lớn, sau đó sẽ đƣa kết quả của mình nhờ các chuyên gia bên phía khách
hàng xem xét, đánh giá. May mắn cho tôi là khách hàng chấp nhận và đánh giá
cao về sản phẩm này. Sau đó SAD đƣợc chuyển cho các thành viên trong nhóm
để tạo SDD và thực hiện viết mã nguồn. Kết quả sản phẩm cuối cùng của chúng
tôi gặp rất ít lỗi khi kiểm thử, sau khi sửa chạy rất ổn định, đáp ứng đủ tính năng,
vƣợt trên cả mong đợi vì đây là mô đun lớn và khó nhất trong dự án. Sản phẩm
của chúng tôi đã hoàn thiện vào cuối năm 2010 và đầu năm 2011 sản phẩm đó
đã đƣa vào sử dụng rộng rãi tại nhiều bệnh viện lớn tại Tokyo, Nhật Bản.
Cùng thời gian này, trên lớp cao học chúng tôi đƣợc học môn các vấn đề hiện
đại trong phát triển phần mềm của thầy Trƣơng Anh Hoàng. Trong môn này thầy
Hoàng đã nói về định nghĩa SAD, các kiểu SAD … Chúng tôi tìm tòi tài liệu
tham khảo trên mạng, thảo luận sôi nổi trong lớp học để hiểu rõ thêm vấn đề.
Tôi cố gắng ngồi suy luận, đánh giá mối liên hệ giữa những gì mình đã làm thực
tế và lý thuyết trong sách vở.
Cuối cùng từ những gì đã làm trong thực tế, cộng với việc đọc tài liệu tham
khảo [2] và [3], tôi xin tóm lƣợc lại, làm rõ các bƣớc thiết kế kiến trúc phần
15


mềm nhƣ dƣới đây.
Các bƣớc thiết kế kiến trúc phần mềm có tính chất lặp, đƣợc mô tả nhƣ hình

2.7 dƣới đây:

Hình 2.7: Các bước thiết kế kiến trúc phần mềm [3].
Hình 2.7 cho thấy, thiết kế kiến trúc phần mềm gồm 5 bƣớc nhƣ sau:
Bƣớc 1: Xác định mục tiêu kiến trúc (Identify Architecture Objectives)
Mục tiêu kiến trúc là những mục tiêu và ràng buộc sẽ giúp xác định và hình
dạng kiến trúc, quy trình thiết kế, phạm vi thiết kế và xác định thời điểm kết
thúc. Các yếu tố sau đây sẽ giúp xác định mục tiêu kiến trúc:
i. Sự hiểu biết về mục tiêu kiến trúc tại thời điểm bắt đầu (Understand your
architecture goals at the start): Lƣợng thời gian ta phải bỏ ra cho mỗi giai
đoạn của thiết kế kiến trúc và thiết kế sẽ phụ thuộc vào các mục tiêu này.
Ví dụ làm bản mẫu (prototype) thì chỉ cần vài ngày để thiết kế, trong khi
thiết kế chi tiết đầy đủ cho một ứng dụng phức tạp có thể cần tới vài tháng
để hoàn thành. Mục tiêu này sẽ khác nhau khi thực hiện thiết kế kiến trúc
tổng quan cho hệ thống lớn ban đầu và thiết kế kiến trúc cho chức năng
lớn cụ thể. Với hệ thống lớn ban đầu, thiết kế kiến trúc cố gắng chia nhỏ
hệ thống thành các SS và đƣa ra các giải pháp có tính định hƣớng, phƣơng
châm thiết kế. Dựa vào đó thiết kế kiến trúc cho chức năng lớn cụ thể sẽ
áp dụng và làm chi tiết nhất có thể cho chức năng của mình.
ii. Sự hiểu biết về đối tƣợng sẽ sử dụng kiến trúc này: Xác định kiến trúc của
16


ta sẽ đƣợc sử dụng bởi đối tƣợng nào? Các kiến trúc sƣ, các nhà phát triển
và thử nghiệm hay nhà quản lý. Đối tƣợng sử dụng thiết kế kiến trúc tổng
quan thƣờng là các kĩ sƣ thiết kế chức năng cụ thể. Đối tƣợng sử dụng
thiết kế kiến trúc cụ thể là các ngƣời thiết kế chi tiết và lập trình viên.
iii. Sự hiểu về các ràng buộc, hạn chế: Hiểu biết về lựa chọn công nghệ và
các ràng buộc. Ví dụ các ràng buộc về môi trƣờng phát triển, môi trƣờng
sẽ triển khai phần mềm, ràng buộc về ngƣời sử dụng … Hiểu đƣợc các

ràng buộc, hạn chế lúc đầu giúp ta không lãng phí thời gian hoặc gặp phải
những tình huống bất ngờ sau này trong quá trình phát triển ứng dụng.
Bƣớc 2: Kịch bản chính (Key Scenarios)
Sự hiểu biết về kịch bản chính giúp ta định hình ứng dụng của mình để đáp
ứng những kịch bản sau này, sau đó sử dụng chúng để kiểm tra các lựa chọn
kiến trúc. Kịch bản chính đƣợc coi là quan trọng nhất cho sự thành công của ứng
dụng. Kịch bản chính có thể đƣợc định nghĩa bởi bất kỳ kịch bản nào đáp ứng
một trong các tiêu chuẩn sau đây:
i. Kịch bản của một ca sử dụng kiến trúc quan trọng.
ii. Kịch bản thể hiện cho các giao điểm của thuộc tính chất lƣợng với chức
năng.
iii. Kịch bản thể hiện sự cân bằng giữa các thuộc tính chất lƣợng.
Ví dụ, chiến lƣợc xác thực của ta là một kịch bản quan trọng bởi vì nó là một
điểm giao của một thuộc tính chất lƣợng (an ninh) với chức năng (làm thế nào
ngƣời dùng đăng nhập vào hệ thống của chúng ta). Một kịch bản khác chính là
yêu cầu bảo mật sẽ ảnh hƣởng tới hiệu suất ứng dụng của chúng ta, bởi vì nó đại
diện cho các giao điểm của hai thuộc tính chất lƣợng.
Các ca kiến trúc quan trọng
Trƣờng hợp sử dụng ca kiến trúc quan trọng có tác động trên nhiều khía cạnh
của thiết kế của chúng ta. Những trƣờng hợp sử dụng đặc biệt quan trọng trong
việc định hình sự thành công của ứng dụng gồm:
i. Ca sử dụng nghiệp vụ quan trọng là ca sử dụng nghiệp có mức độ sử dụng
cao so với các tính năng khác, hoặc ngụ ý sự rủi ro kỹ thuật, công nghệ
cao. Ví dụ với các hệ thống bán hàng trực tuyến thì xử lý nghiệp vụ liên
quan tới thanh toán tiền, bảo mật có mức độ quan trọng hơn, sử dụng cao
hơn.
ii. Trƣờng hợp sử dụng có ảnh hƣởng cao là trƣờng hợp giao cắt với cả hai
17

chức năng và thuộc tính chất lƣợng, hoặc đại diện cho một mối quan tâm
xuyên suốt mà có một tác động điểm cuối tới điểm cuối trên lớp ứng dụng
của chúng ta. Ví dụ trong hệ thống bán hàng trực tuyến, chức năng xem
sản phẩm rồi chọn sản phẩm vào giỏ hàng có ảnh hƣởng cao, vì ảnh
hƣởng trực tiếp tới quá trình thanh toán sau đó của ngƣời dùng. Nếu quá
trình lƣạ chọn rồi lƣu trữ sản phẩm vào giỏ hàng không chính xác có thể
dẫn tới quá trình thanh toán tiền cũng không chính xác.
Các tình huống người sử dụng, hệ thống và nghiệp vụ
Sử dụng những tình huống từ nhiều quan điểm để giúp tiếp xúc với các kịch
bản chính cho hệ thống. Tình huống ngƣời dùng mô tả cách mà ngƣời dùng sẽ
tƣơng tác với hệ thống. Tình huống hệ thống diễn tả hệ thống sẽ làm việc nhƣ
thế nào và tổ chức các chức năng của của chúng. Tình huống nghiệp vụ diễn tả
hệ thống sẽ đáp ứng nghiệp vụ cần nhƣ thế nào hoặc làm việc theo những ràng
buộc nghiệp vụ.
Bƣớc 3: Tổng quan ứng dụng (Application Overview)
Tổng quan về ứng dụng phục vụ khi thiết kế kiến trúc tốt hơn, gắn kết chúng
vào ràng buộc thực tế và lựa chọn. Tổng quan về ứng dụng bao gồm các bƣớc
nhƣ sau:
i. Xác định loại ứng dụng: Đầu tiên xác định loại ứng dụng mà bạn đang
xây dựng. Đó có phải là một ứng dụng di động, ứng dụng trên window,
ứng dụng web hoặc kết hợp một số loại với nhau?
ii. Sự hiểu biết về ràng buộc triển khai: Hiểu môi trƣờng sẽ triển khai và xác
định nó sẽ có những gì tác động vào kiến trúc.
iii. Xác định các kiểu kiến trúc quan trọng: Xác định kiểu kiến trúc bạn sẽ sử
dụng trong thiết kế. Thƣờng có những kiểu kiến trúc cơ bản trƣớc đó, ta
sẽ phân tích, đánh giá ƣu nhƣợc điểm của từng kiểu kiến trúc rồi lựa chọn
xây dựng theo kiến trúc cơ bản đó nhƣ kiến trúc hƣớng dịch vụ (Service
Oriented Architecture - SOA), khách/chủ (client/server), phân tầng
(layered), đƣờng truyền thông điệp (message-bus),… hay kết hợp các kiểu
kiến trúc với nhau rồi chỉnh sửa cho phù hợp với ứng dụng của mình.

iv. Xác định công nghệ liên quan: Cuối cùng xác định, lựa chọn công nghệ
có liên quan dựa vào loại ứng dụng của bạn và hạn chế khác, xác định
công nghệ sẽ tận dụng trong kiến trúc.
Tổng quan ứng dụng này đƣợc sử dụng nhiều cho quá trình Thiết kế kiến trúc
18


tổng quan vì mang tính chất định hƣớng, đƣa ra các phƣơng châm cho thiết kế
sau này.
Bƣớc 4: Các điểm nổi bật
Xác định các điểm nổi bật dựa vào một số tiêu chí sau:
i. Xác định các điểm nổi bật trong kiến trúc ứng dụng để hiểu những vùng
thiếu xót. Các điểm nổi bật chính có thể đƣợc tổ chức xung quanh các
thuộc tính chất lƣợng và mối quan tâm xuyên suốt.
ii. Khung kiến trúc đại diện cho các mối quan tâm xuyên suốt mà sẽ ảnh
hƣởng đến thiết kế của bạn thông qua tầng và lớp. Đây cũng là vùng mà
các sai lầm thiết kế xảy ra. Sử dụng khung kiến trúc để xác định các điểm
“nóng” trong thiết kế của bạn đòi hỏi sự chú ý bổ sung để có đƣợc quyền.
Bạn có thể sử dụng khung kiến trúc sau đây để xác định mối quan tâm
trong suốt quá trình thiết kế.
Khung kiến trúc của các điểm nổi bật đƣợc mô tả chi tiết trong bảng 2.4.
Bảng 2.4: Khung kiến trúc của các điểm nổi bật [3]

Phạm vi
Điểm nổi bật
Xác thực và ủy quyền
Làm thế nào để lựa chọn một chiến lƣợc xác thực.
Làm thế nào để lựa chọn một chiến lƣợc ủy quyền.
Làm thế nào để xác định luồng xử lý thông qua các
lớp và tầng.

Làm thế nào để lƣu trữ danh tính ngƣời dùng khi
không sử dụng dịch vụ thƣ mục (Microsoft Active
Directory).
Bộ nhớ đệm và trạng
thái
Làm thế nào để lựa chọn một công nghệ bộ nhớ đệm
thích hợp.
Làm thế nào để xác định những dữ liệu vào bộ nhớ
đệm (cache).
Làm thế nào để xác định vị trí bộ nhớ đệm chứa dữ
liệu.
19


Làm thế nào để xác định chính sách hết hạn.
Thông báo
(Communication)
Làm thế nào để lựa chọn giao thức thích hợp để giao
tiếp giữa các lớp và các tầng.
Làm thế nào để thiết kế lỏng lẻo qua các lớp.
Làm thế nào để thực hiện truyền thông không đồng
bộ.
Làm thế nào để vƣợt qua các dữ liệu nhạy cảm.
Thành phần
(Composition)
Làm thế nào để lựa chọn một mô hình thành phần giao
diện ngƣời dùng.
Làm thế nào để tránh sự phụ thuộc giữa các mô đun
trong giao diện ngƣời dùng.
Làm thế nào để xử lý các thông tin liên lạc giữa các

mô đun trong giao diện ngƣời dùng.
Đồng nhất và giao
dịch (Concurrency
and Transactions)
Làm thế nào để xử lý đồng bộ giữa các tiến trình
(thread).
Làm thế nào để lựa chọn giữa đồng thời ƣu điểm và
nhƣợc điểm.
Làm thế nào để xử lý các giao dịch phân tán.
Làm thế nào để xử lý các giao dịch chạy trong thời
gian lâu.
Quản lý cấu hình
(Configuration
Management)
Làm thế nào để xác định những thông tin cần phải
đƣợc cấu hình.
Làm thế nào để xác định vị trí và lƣu trữ thông tin cấu
hình.
Làm thế nào để bảo vệ thông tin cấu hình nhạy cảm.
Làm thế nào để xử lý thông tin cấu hình trong một