§¹i häc quèc gia Hµ néi
Tr-êng ®¹i häc c«ng nghÖ
Nguyễn Minh Quý
TÍCH HỢP ATAM-CBAM TRONG ĐÁNH GIÁ
KIẾN TRÚC PHẦN MỀM VÀ ÁP DỤNG CHO DỰ ÁN
VANCO-NETDIRECT TẠI CÔNG TY PHẦN MỀM FSOFT
LUẬN VĂN THẠC SỸ

KIẾN TRÚC PHẦN MỀM VÀ ÁP DỤNG CHO DỰ ÁN
VANCO-NETDIRECT TẠI CÔNG TY PHẦN MỀM FSOFT
Ngành : Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số:……………………
LUẬN VĂN THẠC SỸ

Người hướng dẫn Khoa học
PGS.TS HUỲNH QUYẾT THẮNG

Hưng Yên - 2008


1.3.2 Stakeholder 19
1.3.3 Business Driver 19
1.3.4 Architecture Driver 20
CHƢƠNG 2: MỘT SỐ PHƢƠNG PHÁP ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM DỰA TRÊN
SCENARIO 21
2.1. Phƣơng pháp phân tích kiến trúc phần mềm – SAAM (Software Architecture Analysis
Method) 21
2.1.1 Ngữ cảnh sử dụng SAAM 21
2.1.2 Mục tiêu của SAAM 21
2.1.3 Các yếu tố dẫn đến sự hình thành của SAAM 22
2.1.4 Các yêu cầu và đầu vào của SAAM 22
2.1.5 Các bước thực hiện trong phiên đánh giá SAAM 22
2.1.6 Các đối tượng tham gia phiên đánh giá SAAM 23
2.1.7 Ước lượng chi phí áp dụng SAAM 24
2.1.8 Công cụ hỗ trợ SAAM 24
2.1.9 Các phương pháp thay thế SAAM 24
2.1.10 Điểm mạnh và đầu ra của SAAM 24
2.11 Một số lưu ý về SAAM 25
2.2. Phƣơng pháp ALMA – Architecture Level Modifiability Analysis 25
2.2.1. Ngữ cảnh sử dụng ALMA 25
2.2.2. Mục tiêu của ALMA 26
2.2.3. Các yếu tố dẫn đến sự hình thành của ALMA 26
2.2.4. Các yêu cầu và đầu vào của ALMA 26
2.2.5. Các bước thực hiện phiên đánh giá ALMA. 27
2.2.6. Các đối tượng/ vai trò tham gia trong ALMA 28
2.2.7. Ước lượng chi phí khi áp dụng ALMA 28
2.2.8. Công cụ hỗ trợ ALMA. 28
2.2.9. Các phương pháp thay thế cho ALMA 29

-3-

2.5.2.Mục tiêu của CBAM 57
2.5.3. Các yếu tố dẫn đến sự phát triển CBAM. 57
2.5.4. Yêu cầu và đầu vào của CBAM. 57
2.5.5. Các bước thực hiện phiên đánh giá CBAM. 57
2.5.6. Các đối tượng tham gia trong CABM 59
2.5.7. Ước lượng chi phí khi áp dụng CBAM. 59
2.5.8. Công cụ hỗ trợ CBAM. 60
2.5.9. Các phương pháp thay thế CBAM 60
2.5.10. Mục tiêu và ưu điểm của CBAM 60
2.6. So sánh một số đặc điểm của các phƣơng pháp đánh giá kiến trúc 60
Chƣơng 3: TÍCH HỢP ATAM-CBAM VÀ ĐỀ XUẤT QUI TRÌNH ĐÁNH GIÁ. 62
3.1. Hƣớng tiếp cận tích hợp ATAM và CBAM 62
3.2. Cải tiến ATAM 63
3.3 Cải tiến CBAM 64
3.4 Đề xuất qui trình 65
Chƣơng 4: ÁP DỤNG QUI TRÌNH TÍCH HỢP ATAM-CBAM PHÂN TÍCH KIẾN TRÚC CHO DỰ
ÁN VANCO-NETDIRECT 68
4.1 Mô tả dự án Vanco-NetDirect 68
4.1.1 Thông tin sơ bộ 68
4.2 Mô tả các Business drivers 69
4.2.1 Mục tiêu doanh nghiệp (Business goals) 70
4.2.2 Các yêu cầu chính (Yêu cầu về chất lượng) 70
4.2.3 Bối cảnh doanh nghiệp 70
4.3 Vận dụng ATAM-CBAM đánh giá kiến trúc 71
4.3.1 Phát triển các scenario 71
4.2 Gán mức ưu tiên cho các scenario 72
4.3 Xác định các tiếp cận kiến trúc 72
4.5 Đánh giá kết quả 73
KẾT LUẬN 74


Hình 14 - Đầu vào và đầu ra của CBAM 56
Hình 15 - Đầu vào và đầu ra của ATAM-CBAM sau khi tích hợp 63
Hình 16 - Đầu vào, đầu ra và thành phần tham gia ATAM. 63
Bảng 17 - Sự lặp lại một số hoạt động của ATAM trong phiên CBAM. 66
Hình 18 - Vai trò của Vanco trong cung cấp dịch vụ 68
Hình 19 - Sản phẩm của dự án Vanco-Netdirect phase 2 trên website 71 -6-

DANH MỤC CÁC BẢNG
Bảng 1 – Các thuộc tính chất lượng theo chuẩn ISO 9126 18
Bảng 2 – Stakeholder và các mối quan tâm của họ 19
Bảng 3 - Bảng mẫu mô tả Business drivers 48
Bảng 4 - Mẫu trình diễn kiến trúc 49
Bảng 5 - Mẫu ghi nhận các tiếp cận kiến trúc (Architectural approach) 51
Bảng 6 - Ví dụ về mô tả một tiếp cận kiến trúc 51
Bảng 7 - Ví dụ về kết quả Vote các scenario 52
Bảng 8 - Mối liên quan giữa scenario và thuộc tính chất lượng 53
Bảng 9 – Bảng so sánh một số phương pháp phân tích kiến trúc phần mềm 61
Bảng 10 - Cải tiến ATAM. 64
Bảng 11 - Cải tiến CBAM. 65
Bảng 12 - Danh sách những người tham gia dự án. 69 -7-

MỞ ĐẦU
1. Giới thiệu
Kiến trúc là một trong các hoạt động chính của tiến trình phát triển hệ thống. Kết

Chi phí về tiền bạc, thời gian và nhân lực có thể tăng lên rất cao nếu lựa chọn kiến
trúc sai hoặc không phù hợp [2]. Nhiều trường hợp, toàn bộ hệ thống có thể phải
bỏ đi để xây dựng lại từ đầu hoặc tồi tệ hơn đó là dự án bị thất bại hoàn toàn.
Chính nhờ nhận thức về tầm quan trọng đặc biệt của kiến trúc phần mềm, đồng
thời trải nghiệm qua những dự án phần mềm thực tế, em thấy rằng việc đầu tư
nghiên cứu về lĩnh vực này là vô cùng cần thiết.

-8-

2. Mục tiêu của luận văn
Mục tiêu chủ yếu của luận văn này là đi tìm hiểu, phân tích 2 phương pháp phân
tích kiến trúc phần mềm dựa trên Senario là ATAM (Architecture Trade-off
Analysis method) và CBAM (Cost Benefit Analysis Method), sau đó tìm ra qui
trình kết hợp giữa 2 phương pháp này và thực hành áp dụng chúng vào dự án thực
tế - Dự án Vaco-NetDirect - tại công ty cổ phần phần mềm FSoft.
3. Cấu trúc và nội dung của luận văn
Cấu trúc của luận văn bao gồm 4 chương (Không kể mục lục, phụ lục,…), thể hiện
từ khái niệm, phương pháp luận cho đến thực hành áp dụng.
Dưới đây là mô tả nội dung cơ bản của từng chương:
Chương 1: Tổng quan về phƣơng pháp đánh giá kiến trúc phần mềm. Chương
này chủ yếu giới thiệu về các định nghĩa, khái niệm cơ bản liên quan đến kiến trúc
phần mềm, đồng thời cũng cho biết vị trí, vai trò và tầm quan trọng của kiến trúc
phần mềm trong thiết kế phần mềm – đặc biệt là các phần mềm đòi hỏi chất lượng
cao.
Chương 2: Một số phƣơng pháp đánh giá kiến trúc phần mềm dựa trên
scenario. Chương này giới thiệu và phân tích 5 phương pháp đánh giá kiến trúc
phần mềm dựa trên scenario đang được sử dụng rộng rãi hiện nay là: SAAM
(Software Architecture Analysis Method), ALMA (Architecture Level
Modifiability Analysis), FAAM (Family Architecture Analysis Method), ATAM
(Architecture Tradeoff Analysis Method) và CBAM (Cost-Benefit Analysis

phần tử và kết nối giữa các phần tử [2]. Hiện nay, SEI (Software Engineering
Insitute) đang duy trì một danh sách các định nghĩa về kiến trúc phần mềm.
Sở dĩ có nhiều các định nghĩa như vậy là bởi trong các hoạt động thiết kế, tùy theo
từng giai đoạn thiết kế khác nhau, quan điểm nhìn khác nhau và ngữ cảnh khác
nhau mà người ta cần trừu tượng hóa hệ thống theo những cách thích hợp, chẳng
hạn về các khía cạnh như hoạt động của hệ thống, sự truyền thông giữa các thành
phần, các phương pháp tiếp cận, các kết quả, v.v… Dưới đây là một số trong rất
nhiều các định nghĩa về kiến trúc phần mềm:
Kiến trúc là bản thiết kế hệ thống ở mức cao (high-level).
Kiến trúc là cấu trúc tổng thể của hệ thống.
Kiến trúc là cấu trúc các thành phần của một chương trình hay hệ thống, các
nguyên tắc quản lý thiết kế theo thời gian. Đây là định nghĩa lấy tiến trình làm
trung tâm.
Kiến trúc là các thành phần và các kết nối. Các kết nối ở đây là cơ chế truyền điều
khiển và dữ liệu trong khi chạy. Vì vậy định nghĩa này tập trung vào các cấu trúc
thuộc kiến trúc lúc runtime.
Kiến trúc là sự mô tả trừu tượng nhất về hệ thống mà ở đó nó cho phép ta có thể
suy đoán về các yêu cầu có ý nghĩa quyết định đến chất lượng phần mềm.
Tuy nhiên, một điều phải nói ở đây là cần phải phân biệt rõ thế nào thì được coi là kiến
trúc và thế nào thì không coi là kiến trúc. Vì theo một số định nghĩa thì kiến trúc là cấu
trúc của một số thành phần, các kết nối và mối quan hệ giữa các thành phần, nhưng
điều ngược lại thì không phải lúc nào cũng đúng. Xin lấy ra một ví dụ sau đây để thấy rõ
hơn về khái niệm này [2]. Giả sử ta đưa ra một biểu đồ như sau:


quan trọng hơn các kết nối này phải có ý nghĩa (Tức mối quan hệ phải có tính
logic), và chúng phải thể hiện một khung nhìn nào đó về hệ thống đồng thời chúng
phải cộng tác để đạt được một mục tiêu nhất định.
1.1.2 Tầm quan trọng của kiến trúc phần mềm
Kiến trúc phần mềm là công cụ đầu tiên chúng ta dựa vào để xây dựng hệ thống,
nó là nền tảng cơ sở cho các pha tiếp theo. Tầm quan trọng của nó thể hiện qua ba
điểm:
1. Là công cụ để giao tiếp giữa những người có liên quan đến hệ thống. Kiến
trúc phần mềm là sự mô tả chung nhất bản nhất của hệ thống mà hầu hết những
người liên quan đều có thể hiểu được và sẽ sử dụng nó để đàm phán, thảo luận,
biểu quyết cũng như để hiểu rõ hơn về hệ thống.
2. Là quyết định thiết kế (design decisions) sớm nhất. Kiến trúc phần mềm thể
hiện sớm nhất một cách rõ ràng các quyết định về hệ thống và điều này ảnh
hưởng đến toàn bộ phần phát triển và bảo trì hệ thống còn lại. Nó cũng là thời
điểm sớm nhất mà tại đó các quyết định thiết kế có thể được phân tích.
3. Truyền tải các ý tưởng cơ bản về hệ thống. Kiến trúc phần mềm Software là
một mô hình để từ đó ta có thể hiểu được cấu trúc của một hệ thống, cách thức
các phần tử làm việc cùng với nhau và có thể áp dụng cho các hệ thống khác
với các yêu cầu chức năng, các thuộc tính chất lượng tương tự nhau.

-11-

Để thấy rõ được tầm quan trọng của kiến trúc, sau đây xin được phân tích một
cách chi tiết.
Kiến trúc là công cụ truyền tải giữa những ngƣời liên quan đến hệ thống.
Mỗi người liên quan đến hệ thống – như khách hàng, người dùng, quản lý dự án,
lập trình, kiểm thử viên, v.v – đều liên quan đến mặt nào đó của hệ thống và các
mặt này đều có bị tác động bởi kiến trúc của chính hệ thống đó. Ví dụ, người dùng
thì liên quan đến độ tin cậy và tính sẵn sàng; khách hàng thì liên quan đến việc
kiến trúc phải được áp dụng trong khoảng thời gian và ngân sách giới hạn; người

khung nhìn khác nhau đối với từng người. Các thuộc tính và mục tiêu khác nhau
này cũng như các khung nhìn tương ứng là rất quan trọng đối với người kỹ sư và
đối với quá trình phân tích. Tất cả các khung nhìn đó đều làm cơ sở để từ đó nhận
biết tính phù hợp cũng như chất lượng của kiến trúc đó. Như vậy có thể kết luận
rằng tùy vào mối quan tâm của từng đối tượng người liên quan mà có thể có các
khung nhìn về kiến trúc khác nhau trong một hệ thống cụ thể. Một hệ thống cho

-12-

trước có thể xem xét theo nhiều góc độ khác nhau hay có nhiều khung nhìn khác
nhau.
Thực tế đã có một số chuyên gia đề xuất sử dụng một tập các khung nhìn cố định.
Chẳng hạn với RUP (Rational‘s Unified Process), dựa vào cách tiếp cận kiến trúc
phần mềm theo kiểu ―khung nhìn 4+1‖ của Kruchten.
Một số khung nhìn kiến trúc bao gồm [3]
 Khung nhìn dưới góc độ phân chia module, trong đó bao gồm một tập các đơn
vị cài đặt có liên quan với nhau bởi quan hệ ―là một phần của‖, cho biết chức
năng của hệ thống được qui định như thế nào đối với phần mềm. Tính sửa đổi
(Modifiability) của hệ thống được qui định bởi các module.
 Khung nhìn dưới góc độ phân tầng (Layered), cho biết các module của hệ
thống liên quan với nhau như thế nào bằng cách sử dụng quan hệ dạng ―cho
phép sử dụng‖. Các tầng nhóm các phần tử thành các tập, mỗi tập này cho ta
một cái nhìn trừu tượng về hệ thống và cũng cho biết phạm vi sử dụng để các
tầng trên chỉ có thể sử dụng các tầng ở dưới nó, khung nhìn này cho ta cái nhìn
về khả năng sửa đổi và chuyển đổi sang hệ thống khác của kiến trúc đó.
 Khung nhìn tập trung vào truyền thông và tiến trình (communicating-processes
view), bao gồm một tập các tiến trình hay tuyến (thread), cho biết chúng tương
tác với nhau như thế nào trong lúc runtime. Khung nhìn này cho phép người kỹ
sư có cái nhìn tốt hơn về hiệu năng, tiến độ, khả năng xuất hiện khóa chết, và
các thuộc tính chất lượng khác.

Đánh giá kiến trúc là cách làm rẻ nhất để tránh được hiểm họa.
1.1.5 Khi nào thì đánh giá kiến trúc
Việc đánh giá kiến trúc ruyền thống trước đây được áp dụng khi kiến trúc của dự
án đã hoàn toàn được xác định và được tiến hành trước khi cài đặt. Trong các mô
hình phát triển phần mềm tăng trưởng và lặp thì thường thể đánh giá các quyết
định kiến trúc trong chu trình phát triển gần nhất. Tuy nhiên, thực tế thì có thể
đánh giá kiến trúc tại bất kỳ thời điểm nào, vì vậy có 2 dạng đánh giá theo phương
pháp truyền thống (cố điển) là : Sớm và Muộn.
Đánh giá sớm. Khi đó không cần phải chờ cho đến khi đặc tả đầy đủ kiến trúc,
việc đánh giá có thể tiến hành ở bất cứ giai đoạn nào trong quá trình xây dựng kiến
trúc. Việc đánh giá này là để kiểm tra các quyết định kiến trúc được tạo ra cũng
như lựa chọn các kiến trúc đang được xem xét khác.
Tất nhiên, việc đánh giá này có đầy đủ và tin cậy hay không lại phụ thuộc vào tính
đầy đủ và tin cậy của bản mô tả kiến trúc mà người kiến trúc cung cấp.

Đánh giá muộn. Dạng đánh giá thứ hai này được tiến hành khi kiến trúc của hệ
thống đã được ấn định và việc cài đặt hệ thống cũng đã được hoàn tất. Điều này
xảy ra khi một tổ chức thừa kế một hệ thống hiện hành nào đó thường được mua
trên thị trường hoặc cũng có thể được khai thác từ chính thành tựu của đơn vị đó.
Các kỹ thuật đánh giá kiến trúc cho một hệ thống có sẵn cũng giống như đối với
các hệ thống mới sinh ra. Đánh giá kiến trúc là một công việc cần phải được tiến
hành, bởi vì nó giúp cho những người mới tham gia có thể hiểu được hệ thống
hiện tại, đồng thời cho biết liệu hệ thống đang xây dựng có phù hợp với các yêu
cầu về hành vi và chất lượng hay không?.
Tóm lại, khi nào thì việc đánh giá kiến trúc được tiến hành? Câu trả lời là ngay khi
có đủ lượng thông tin về kiến trúc để điều chỉnh. Các tổ chức khác nhau sẽ có
những quan điểm nhìn nhận khác nhau nhưng một qui tắt chung, đơn giản là: Việc
đánh giá được thực hiện nếu như các nhóm phát triển ra các quyết định phụ thuộc
vào kiến trúc nhưng chi phí để làm lại các quyết định này lớn hơn so với chi phí
bỏ ra cho việc đánh giá.

năng thực thi được.
Khái niệm về tính phù hợp (suitability) ở trên được áp dụng cho hầu hết các giai
đoạn phát triển dự án. Tính phù hợp bao hàm 2 khía cạnh: Thứ nhất, tính phù hợp
chỉ có ý nghĩa trong một ngữ cảnh mục tiêu cụ thể. Ví dụ, nếu kiến trúc của một hệ
thống được thiết kế để đạt hiệu năng cao như mục tiêu, khiến cho tốc độ của
chương trình chạy rất nhanh nhưng điều đó có thể phải đòi hỏi nhóm lập trình làm
việc nhiều tháng trời khi cần thực hiện các chỉnh sửa có liên quan tới hệ thống.
Nếu việc sửa đổi quan trọng hơn hiệu năng của hệ thống đó thì kiến trúc như vậy
cũng có thể được coi là không phù hợp cho hệ thống đó.
1.1.8 Thuộc tính chất lƣợng nào trong kiến trúc cần phải đánh giá
Theo định nghĩa của ISO 9126, chất lượng phần mềm được qui định bởi 6 thuộc
tính chính [4]: Functionality, Portability, Maintainability, Reliability, Usability,
Efficiency (Trong mỗi thuộc tính chính lại có một tập các thuộc tính con – gọi là
sub attibutes). Tuy nhiên không phải tất cả các thuộc tính này đều có thể đánh giá
trong quá trình đánh giá kiến trúc. Như thuộc tính Usability (bao gồm 3 thuộc tính
con là: Understandability, Operability, Learnability) chẳng hạn: rõ ràng với những
thuộc tính này thì chất lược của nó thường ít bị ảnh hưởng bởi kiến trúc mà phần
lớn nó phụ thuộc và chất lượng thiết kế giao diện – cái mà chủ yếu mang tính hình
thức hơn là kỹ thuật – tức là làm sao để người dùng sử dụng được hệ thống một
cách tốt nhất. Ngoài thuộc tính Usability ra, các thuộc tính còn lại đều bị ảnh

-15-

hưởng sâu sắc bởi kiến trúc hệ thống. Do vậy, chỉ các thuộc tính còn lại mới
thường được đưa vào để đánh giá. Sau đây xin phân tích nội hàm chi tiết của từng
thuộc tính.
 Hiệu năng (Performance): Hiệu năng là thước đo đánh giá sự đáp ứng
(response) của một hệ thống – sự đáp ứng là khoảng thời gian cần để đáp
ứng (phản hồi) lại tác nhân (các sự kiện). Chất lượng về hiệu năng thường
được đo bởi số giao dịch trên một đơn vị thời gian hoặc bởi khối lượng thời

 Đặt nhiều người liên quan ngồi cùng với nhau.
Đây là dịp để tất cả những người liên quan, thậm chí là cả những nhà kiến trúc gặp
gỡ, trao đổi mục tiêu và sự quan tâm của mình đối với hệ thống. Các mục tiêu của
mỗi người trước đây có thể xung đột với nhau thì đây là thời điểm để họ có thể

-16-

thảo luận, bày tỏ và cùng đi tới sự thống nhất chung, trên tinh thần: Cùng hướng
đến sự thành công của hệ thống.
 Thực hiện đối chứng các mục tiêu chất lượng với mục tiêu do kiến trúc đem
lại.
Vai trò của những người liên quan là làm rõ các mục tiêu chất lượng mà kiến trúc
cần phải đạt được trước khi được xem là thành công. Các mục tiêu này thường
không được nắm bắt trong tài liệu yêu cầu mà thường được thể hiện qua các tình
huống (Scenarios).
 Làm cơ sở để phân mức độ ưu tiên trong số các mục tiêu có xung đột.
Các xung đột có thể phát sinh trong số các mục tiêu được mô tả bởi những người
liên quan. Mỗi phương pháp đều gồm một bước mà ở đó các mục tiêu được được
nhóm đánh giá gán mức ưu tiên. Nếu nhà kiến trúc không thể làm thỏa mãn tất cả
các mục tiêu đang xung đột thì anh ta sẽ nhận được sự hỗ trợ để biết được cái nào
là quan trọng nhất.
1.1.10 Phong cách kiến trúc & Mẫu kiến trúc (Architecture Styles & Pattern)
Trải qua theo thời gian người ta thấy rằng một số giải pháp nào đó được sử dụng
để xây dựng phần mềm đã được chứng minh là rất ―tốt‖. Các giải pháp như vậy
được tổng quát hóa và đã được công bố rộng rãi dưới dạng các mẫu (Pattern) hay
phong cách (Styles) và thường có các tên như ―model-view-controller‖,
―publisher-subscriber‖, ―client-server‖ [5] (Thuật ngữ ―pattern‖ và ―style‖ thường
được dùng thay thế lẫn nhau, trong luận văn này sẽ không có sự phân biệt nào trừ
khi cần thiết). Các mẫu có trong tất cả các mức trừu tượng; theo Buschmann et al
thì các mẫu được chia ra làm 3 mức là: các mẫu kiến trúc (architectural patterns),

mềm không/ ít lỗi; với hệ thống phần mềm trong lĩnh vực ngân hàng thì phần mềm
chất lượng là phần mềm có độ bảo mật cao….
Việc định nghĩa rõ chất lượng phần mềm là gì? là điều rất quan trọng. Vì chất
lượng phần mềm có quan hệ rất chặt chẽ với các kiến trúc mà chúng ta áp dụng để
xây dựng hệ thống. Khái niệm chất lượng được đề cập thường xuyên khi phân tích
kiến trúc phần mềm và trong luận văn này. Do đó, dưới đây sẽ phân tích rõ hơn về
thuộc tính chất lượng của phần mềm.
Theo định nghĩa chuẩn của ISO-9126, chất lượng phần mềm được qui định bởi các
thuộc tính chất lượng sau đây:

Hình 2 - Sáu thuộc tính chất lượng phần mềm theo ISO-9126
Trong đó, mỗi thuộc tính chính lại có một tập các thuộc tính con.
STT
Thuộc tính
Mô tả
Thuộc tính con
1
Functionality
Cho biết hệ thống có đáp
ứng được các yêu cầu
 Suitability
 Accurateness

How easy is to transfer
the software to another
environment?
How efficient is the
software ?
Is the software
easy to use ?

 Learnability
 Operability
4
Efficiency
Cho biết hệ thống có sử
dụng hiệu quả tài nguyên
hệ thống hay không?.
 Time behaviour
 Resource behavior
5
Maintainability
Cho biết hệ thống có dễ
bảo trì hay không?
 Analyzability
 Changeability
 Stability
 Testability
6
Portability
Cho biết hệ thống có thể
dễ chuyển sang môi
trường khác hay không?
 Adaptability
 Installability
 Conformance
 Replaceability
Bảng 1 – Các thuộc tính chất lượng theo chuẩn ISO 9126
Mục tiêu của quá trình phân tích kiến trúc chính là việc chúng ta tìm ra các tiếp
cận (giải pháp) nhằm đạt được các thuộc tính này ở mức độ tốt nhất.
Những thuộc tính được đề cập ở trên mang ý nghĩa thuần túy về mặt kỹ thuật, còn

et al. 1997). Đây là quan điểm được chấp nhận trong hầu hết các phương pháp kỹ
nghệ yêu cầu hiện hành.
1.3.2 Stakeholder
Khi thực hiện một phiên đánh giá kiến trúc phần mềm, có rất nhiều đối tượng
tham gia. Mỗi một người tham gia đều có những mối quan tâm riêng tùy thuộc vào
vai trò của họ. Khái niệm và cách phân loại Stakeholder cũng rất khác nhau ở mỗi
phương pháp phân tích cũng như tùy thuộc vào đặc thù của từng dự án. Dưới đây
là một định nghĩa về stakeholder:
―Stakeholder là bất kỳ người nào có mối quan tâm đến hệ thống‖. Stakeholder có
thể là Customer, Customer representatives, End user, Developer, Maintainer,
system administrator, network administrator, Tester, Integrator… Mỗi người này
có mối quan tâm riêng, ví dụ:
Stakeholder
Quan tâm đến
Customer
Tiến độ và ngân sách; tính hữu dụng của hệ thống; đáp ứng
được sự mong đợi của khách hàng (hoặc thị trường) hay
không?
End User
Chức năng, khả năng sử dụng hệ thống.
Developer
Sự rõ ràng về tính đầy đủ của kiến trúc; sự cố kết và ghép
cặp của các thành phần.
Maintainer
Tính bảo trì, khả năng chỉ ra những vị trí thay đổi.
…
…
Bảng 2 – Stakeholder và các mối quan tâm của họ
1.3.3 Business Driver
Business driver là thuật ngữ ám chỉ đến các yếu tố rất quan trọng, ảnh hưởng rất

2.1. Phương pháp phân tích kiến trúc phần mềm – SAAM (Software
Architecture Analysis Method)
2.1.1 Ngữ cảnh sử dụng SAAM
SAAM là phương pháp phân tích kiến trúc phần mềm dựa trên tình huống
(Scenario) được sử dụng rộng rãi đầu tiên. Nó được tạo ra nhằm đánh giá khả năng
sửa đổi của kiến trúc. Hình 3 - Mô hình tiến trình của SAAM
2.1.2 Mục tiêu của SAAM
Mục tiêu của SAAM là để mô tả các phát biểu về chất lượng của kiến trúc phần
mềm (chẳng hạn như tính sửa đổi, tính linh hoạt, tính bảo trì, …) bằng công cụ là
Scenario, đồng thời cũng để đánh giá xem các thuộc tính chất lượng này so với
Phát triển
scenario
Mô tả các
kiến trúc
Phân loại
scenario
Đánh giá
từng scenario
Các scenario
tương tác
Đánh giá
tổng thể
Lặp
Phân tích
kiến trúc đơn lẻ
So sánh nhiều
kiến trúc

Một số scenario mô tả sự tương tác của người dùng với hệ thống là các đầu vào
chính của phiên đánh giá SAAM.
2.1.5 Các bƣớc thực hiện trong phiên đánh giá SAAM
Phương pháp SAAM bao gồm 6 bước chính, thường được tiến hành trước bởi một
cuộc giới thiệu tổng quan về ngữ cảnh của doanh nghiệp và các yêu cầu chức năng
của hệ thống đó. Cụ thể 6 bước như sau:
SAAM Step 1 – Phát triển các scenario
Bước đầu tiên của SAAM là thực hiện thảo luận tập thể (Brainstorm) nhằm xác
định được các loại hoạt động mà hệ thống phải hỗ trợ. Các hoạt động mà có thể
dẫn tới sự sửa đổi của hệ thống mà những người liên quan tham gia vào được
nhóm thành cái gọi là các scenario hệ thống. Khi phát triển các scenario thì khó
khăn lớn nhất là phải nắm bắt được tất cả các tình huống sử dụng chính yếu,
những người dùng của hệ thống, tất cả các thuộc tính chất lượng và mức độ mà hệ

-23-

thống phải đạt được, và điều quan trọng nhất là tất cả các thay đổi đối với hệ thống
trong tương lại phải thấy được trước.
SAAM Step 2 – Mô tả các kiến trúc
Bước thứ hai của phiên đánh giá SAAM là mô tả các kiến trúc dự tuyển (ứng cử).
Việc mô tả kiến trúc tại bước này đòi hỏi sử dụng các ký pháp dễ hiểu đối với
những người tham gia, đồng thời phải mô tả các thành phần tĩnh (như các thành
phần, các kết nối và quan hệ với môi trường xung quanh) cũng như các hành vi
động của hệ thống. Việc mô tả này có thể thực hiện thông qua ngôn ngữ tự nhiên
hoặc dưới dạng đặc tả hình thức khác.
SAAM Step 3 – Phân loại và đánh giá độ ưu tiên của các scenario.
Tại bước này, các scenario được phân thành hai dạng là scenario trực tiếp (Direct
Scenario) và scenario gián tiếp (tương ứng với ký pháp Use case và Change case
trong UML). Các scenario sau đó được đánh giá mức độ ưu tiên (quan trọng)
thông qua thủ tục bỏ phiếu (Voting), số phiếu càng lớn thì mức ưu tiên càng cao.

ở đây như: khách hàng, người dùng cuối, chuyên viên marketing, quản trị hệ
thống, người bảo trì, v.v…
b. Inernal Stakeholders: là những người có liên quan trực tiếp trong việc đề xuất
các chiến lược kiến trúc để đạt được các yêu cầu chất lượng đặt ra. Họ có vai trò
phân tích, định nghĩa, và mô tả các khái niệm kiến trúc, ước lượng các chi phí và
lên kế hoạch đi kèm với mỗi chiến lược đó. Các nhà kiến trúc phần mềm, các nhà
phân tích hệ thống hay nhóm kiến trúc được coi là những Internal Stakeholders.
2.1.7 Ƣớc lƣợng chi phí áp dụng SAAM
Thông thường, thời gian thực hiện phiên đánh giá SAAM với đầy đủ 6 bước kể trên
được tiến hành trong một ngày, không kể thời gian chuẩn bị và thời gian dành cho
mô tả kiến trúc và đánh giá các scenario. Tùy vào kích thước của dự án và số người
liên quan mà khoảng thời gian của phiên đánh giá có thể khác nhau. Một báo cáo
khi nghiên cứu về SAAM chỉ ra rằng, trong 10 phiên đánh giá được thực hiện với
dự án có kích cỡ từ 5-100 KLOC (Kilo Of Code) thì công sức bỏ ra ước vào khoảng
14 ngày công [9]. Hầu hết những người tham gia đều ghi nhận rằng, chi phí khởi
đầu tăng cao đối với những tổ chức có năng lực hiểu biết về kiến trúc phần mềm
kém. Tập đoàn phần mềm Rational đã thực hiện khoảng 30 phiên đánh giá và kết
quả là: chi phí trung bình 50.000 $ đối với những dự án có kích cỡ tối thiểu 500
KLOC [9].
2.1.8 Công cụ hỗ trợ SAAM
Cho tới thời điểm hiện tại, chưa có bất kỳ một công cụ nào hỗ trợ phiên đánh giá
SAAM. Do vậy, chỉ duy nhất thủ tục biểu quyết (Voting) được sử dụng để đánh giá
mức ưu tiên cho các scenario và tính sửa đổi để ước lượng chi phí và công sức khi
áp dụng một kiến trúc nào đó.
2.1.9 Các phƣơng pháp thay thế SAAM
Khởi nguồn từ SAAM, hiện nay đã có rất nhiều phương pháp khác đã được phát
triển cho phép đánh giá tính sửa đổi của kiến trúc. Một trong số đó là ATAM [10],
cũng do chính nhóm tác giả của SAAM xây dựng. Một phương pháp khác nữa là
ALMA [11], cũng đánh giá dựa trên scenario nhưng rất phù hợp khi đánh giá tính
sửa đổi của kiến trúc phần mềm.