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

§¹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Ỹ

HƯNG YÊN 2/2008

-2-

§¹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



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

-2-

MỤC LỤC
LỜI CẢM ƠN. 1
MỤC LỤC 2
DANH MỤC CÁC HÌNH 5
DANH MỤC CÁC BẢNG 6
MỞ ĐẦU 7
1. Giới thiệu 7
2. Mục tiêu của luận văn 8
3. Cấu trúc và nội dung của luận văn 8
CHƢƠNG 1: TỔNG QUAN VỀ PHƢƠNG PHÁP ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM –
SOFTWARE EVALUATION 9
1.1 Tổng quan 9
1.1.1 Một số định nghĩa về kiến trúc phần mềm 9
1.1.2 Tầm quan trọng của kiến trúc phần mềm 10
1.1.3 Kiến trúc và khung nhìn kiến trúc 11
1.1.4 Lý do cần phải đánh giá một kiến trúc 12
1.1.5 Khi nào thì đánh giá kiến trúc 13
1.1.6 Những thành phần tham gia đánh giá kiến trúc 13
1.1.7 Kết quả của phiên đánh giá kiến trúc 14
1.1.8 Thuộc tính chất lượng nào trong kiến trúc cần phải đánh giá 14
1.1.9 Lợi ích và chi phí của việc đánh giá kiến trúc. 15
1.1.10 Phong cách kiến trúc & Mẫu kiến trúc (Architecture Styles & Pattern) 16
1.1.11 Các quyết định kiến trúc – Architecture Decisions 16
1.2 Thuộc tính chất lƣợng 17
1.3 Một số thuật ngữ thông dụng 18
1.3.1 Senario 18

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.2.10. Những ưu điểm và đầu ra của ALMA 29
2.2.11. Một số lưu ý về ALMA. 29
2.3. Phƣơng pháp đánh giá kiến trúc FAAM (Family-Architecture Assessment Method) 30
2.3.1. Ngữ cảnh sử dụng FAAM 30
2.3.2. Mục tiêu của FAAM 30
2.3.3. Những yếu tố dẫn đến sự hình thành của FAAM 30
2.3.4. Các yêu cầu và đầu vào của FAAM 30
2.3.5. Các bước trong một phiên đánh giá FAAM. 31
2.3.6. Các đối tượng tham gia phiên đánh giá FAAM 32
2.3.7. Ước lượng chi phí khi áp dụng FAAM. 32
2.3.8. Công cụ hỗ trợ FAAM. 32
2.3.9. Các thay thế cho FAAM 33
2.3.10. Các ưu điểm và đầu ra của FAAM. 33
2.4. Phƣơng pháp phân tích cân bằng kiến trúc-ATAM (Architecture Tradeoff Analysis Method)
33
2.4.1 Giới thiệu phương pháp
33
2.4.2 Mô tả thuộc tính chất lượng 36
2.4.3 Scenario 41
2.4.4 Đầu ra của ATAM. 45
2.4.5. Chi tiết các bước thực hiện phiên đánh giá ATAM. 47
2.4.6 Đối tượng tham gia phiên đánh giá ATAM. 53
2.4.7. Ước lượng chi phí khi áp dụng phương pháp ATAM. 54
2.4.8. Công cụ hỗ trợ ATAM. 54
2.4.9. Các phương pháp thay thế cho ATAM 54
2.4.10. Đầu ra và điểm mạnh của ATAM. 54
2.4.11 Lịch biểu thực hiện một phiên đánh giá ATAM điển hình 55
2.5. Phƣơng pháp đánh giá kiến trúc phần mềm CBAM (Cost-Benefit Analysis Method) 56
2.5.1. Bối cảnh hình thành phương pháp CBAM 56

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

-4-

PHỤ LỤC 1 75
Vanco-NetDirect Software Requirement Specification 75
1. Functional requirements Overview 75
2. Core modules 75
3. Non-Functional core requirements 76
3.1 Performance 76
3.2 Scalability 76
3.3 Reliability 76
3.6 Supportability 76
PHỤ LỤC 2 DANH MỤC CÁC TỪ VIẾT TẮT 77
TÀI LIỆU THAM KHẢO 78

-5-

DANH MỤC CÁC HÌNH
Hình 1 - Ví dụ mô tả kiến trúc điển hình nhưng không đem lại thông tin 9
Hình 2 - Sáu thuộc tính chất lượng phần mềm theo ISO-9126 17
Hình 3 - Mô hình tiến trình của SAAM 21
Hình 4 - Mô hình phân tích ATAM 34
Hình 5 - Mô hình tiến trình của ATAM 35
Hình 6 – Mô tả thuộc tính chất lượng – Performance Stimuli 37
Hình 7 – Mô tả thuộc tính chất lượng – Performance Response 38
Hình 8 - Mô tả thuộc tính chất lượng – Performance Parameters 38
Hình 9 - Mô tả thuộc tính chất lượng – Modifiability Param 39
Hình 10 - Mô tả thuộc tính chất lượng – Modifiability Availability 39
Hình 11 – Ví dụ về cây tiện ích (Utility Tree) 44
Hình 12 – Đầu vào, đầu ra của ATAM 46
Hình 13 - Các khung nhìn khác nhau về hệ thống 56

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

quả của hoạt động này cho ta bản thiết kế ở mức cao của hệ thống đó - hay còn
được gọi là kiến trúc hệ thống (System Architecture). Kiến trúc cũng có thể được
định nghĩa như là Tổ chức cơ bản của hệ thống, được thể hiện bởi các thành phần,
các mối quan hệ và môi trường, cũng như các nguyên tắc để quản lý tiến trình và
sự phát triển (IEEE standard. Page 1471) [1].
Tương tự như vậy, trong qui trình phát triển phần mềm (SLC) thì kiến trúc phần
mềm (Software Architecture) đóng một vai trò vô cùng quan trọng, bởi nó ảnh
hưởng trực tiếp đến tất cả các công đoạn còn lại của cả chu trình. Việc lựa chọn
kiến trúc phù hợp có ý nghĩa rất lớn tới chất lượng của dự án (thể hiện qua các
thuộc tính chất lượng phần mềm, như: tính bảo mật, hiệu năng, khả năng sửa
đổi,…). Tuy nhiên vấn đề đặt ra là liệu có thể đánh giá sớm được một kiến trúc
nào đó là ―Tốt‖ hơn hay không ? để từ đó giúp những nhà quản lý đạt được hiệu
quả cao nhất trong quá trình phát triển phần mềm đồng thời giảm thiểu tối đa các
rủi ro có thể xảy ra.
Câu trả lời ở đây là ―Các kiến trúc hoàn toàn có thể được phân tích‖, vì vậy chúng
ta đều có thể đánh giá một kiến trúc là tốt hay tồi theo một khía cạnh hay ngữ cảnh
nào đó trước khi tiến hành quá trình thiết kế dự án.
Chính vì tầm quan trọng đó mà trong những năm gần đây việc nghiên cứu về đánh
giá kiến trúc phần mềm (Software Architecture Evaluation – SWA) đã nhận được
rất nhiều sự quan tâm của những nhà nghiên cứu trong lĩnh vực kỹ nghệ phần
mềm (Software Engineering).
Ở nước ta hiện nay, lĩnh vực nghiên cứu về Kiến trúc phần mềm chưa thực sự
được quan tâm nhiều, hơn nữa việc áp dụng các kết quả có liên quan đến kiến trúc
phần mềm trong các dự án còn gặp nhiều hạn chế. Cụ thể là, đối với các dự án
phát triển phục vụ Outsourcing thì kiến trúc cho hệ thống đều được phía đối tác
nước ngoài phân tích và xây dựng sẵn, còn đối với những dự án trong nước hay
những dự án mà chúng ta xây dựng từ A-Z thì kiến trúc phần mềm được lựa chọn
chủ yếu dựa theo kinh nghiệm mà ít có sự phân tích một cách bài bản, khoa học.
Thực tế ở một số công ty phát triển phần mềm cho thấy rằng, việc xem nhẹ hoặc
hiểu biết không sâu sắc về kiến trúc có thể gây ra những hậu quả nghiêm trọng.

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

Method). Trong đó hai phương pháp ATAM và CBAM được mô tả chi tiết hơn.
Ngoài ra, chương này cũng thực hiện việc so sánh 5 phương pháp này ở một số
khía cạnh, cho biết rõ hơn về những điểm mạnh, yếu và phạm vi áp dụng của từng
phương pháp.
Chương 3: Tích hợp ATAM –CBAM và đề xuất qui trình đánh giá. Chương
này phân tích một số đặc điểm của phương pháp ATAM và CBAM, cải tiến và bổ
sung một số hoạt động bên trong để có một phương pháp phân tích mới, tốt hơn và
tối ưu hơn (nhưng vẫn trên nền 2 phương pháp đó). Trên cơ sở tích hợp này, đề
xuất ra một qui trình đánh giá tương ứng. Qui trình này sẽ được dùng để đánh giá
kiến trúc cho một dự án phần mềm thực tế tại FSoft, đó là : Vanco-NetDirect.
Chương 4: Áp dụng ATAM – CBAM vào đánh giá kiến trúc cho hệ thống
phần mềm Vanco-NetDirect tại công ty cổ phần phần mềm FSoft. Nội dung
của chương này tập trung chủ yếu vào việc đánh giá kiến trúc phần mềm cho dự
án thực tế (Vanco-NetDirect) của công ty phần mềm FSoft bằng chính hai phương
pháp ATAM và CBAM và qui trình đã xây dựng được ở chương 3.




-9-

CHƢƠNG 1:
TỔNG QUAN VỀ PHƢƠNG PHÁP ĐÁNH GIÁ
KIẾN TRÚC PHẦN MỀM – SOFTWARE EVALUATION
1.1 Tổng quan
1.1.1 Một số định nghĩa về kiến trúc phần mềm
Kiến trúc phần mềm tuy là lĩnh vực mới nhưng đang phát triển rất nhanh chóng, vì
vậy sẽ không có một định nghĩa duy nhất được chấp nhận. Hay nói theo cách khác
là có vô số những định nghĩa liên quan đến khái niệm này. Tuy vậy, trong các định
nghĩa đó đều có những đặc điểm chung là đề cập đến các khái niệm như Cấu trúc,

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:

Hình 1 - Ví dụ mô tả kiến trúc điển hình nhưng không đem lại thông tin
Control Process
MODP
MODR
MODN

-10-

Với biểu đồ này, chúng ta có 4 phần tử, trong đó có 3 phần tử cùng mức với nhau
và chúng có một loại quan hệ nào đó (vì chúng hoàn toàn được kết nối với nhau).
Câu hỏi là liệu đây có phải là kiến trúc không?. Rõ ràng nếu nếu chúng ta coi kiến
trúc là một tập các thành phần/phần tử (ở đây có 4), tập các kết nối (đã có như
trong hình vẽ) và tập các quan hệ giữa chúng thì rõ ràng có vẻ như đây là kiến trúc
của một hệ thống nào đó. Nhưng ngay cả khi chúng ta chấp nhận thì một loạt
những câu hỏi cần đặt ra cho Diagram này:
 Các phần tử đó thuộc loại gì? Ý nghĩa của sự phân cấp đó? Các phần tử có
bao gồm các tiến trình, chương trình hay cả hai? Chúng có miêu tả các cách
thức để từ đó phân chia dự án không? Chúng là các đối tượng, chức năng,
tiến trình, chương trình phân tán hay một thứ nào khác?
Vai trò của các phần tử? Chúng làm việc gì? Chức năng của chúng trong hệ
thống ra sao?
Ý nghĩa của các kết nối? Các kết nối có nói lên rằng các phần tử giao tiếp,
điều khiển, gửi dữ liệu, sử dụng lẫn nhau, triệu gọi lẫn nhau hay đồng bộ
với nhau hay không? Các cơ chế để truyền thông là gì? Luồng thông tin đi
cùng với các cơ chế đó (nếu có) là gì?
Ý nghĩa của việc bố trí (Layout) sơ đồ đó là gì? Tại sao CP lại ở mức riêng
biệt (trên cùng)? Nó có gọi đến 3 thành phần kia hay không hay 3 thành
phần đó có được phép gọi CP hay không?
Như vậy, rõ ràng một kiến trúc không chỉ đơn thuần là các thành phần, kết nối mà

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

quản lý dự án không chỉ quan tâm đến tiến độ và ngân sách mà còn quan tâm xem
kiến trúc đó phải cho phép nhóm làm việc độc lập hơn, có sự tương tác dưới sự
kiểm soát nào đó; nhà kiến trúc thì lại quan tâm đến các chiến lược để đạt được tất
cả các mục tiêu đó.
Kiến trúc cung cấp cho chúng ta một ngôn ngữ chung mà ở đó các vấn đề liên
quan có thể được mô tả, được thảo luận và được giải quyết ngay cả đối với các hệ
thống lớn và phức tạp. Nếu không có một ngôn ngữ như vậy thì sẽ rất khó khăn để
có thể hiểu đầy đủ về hệ thống có qui mô lớn, để từ đó đưa ra các quyết định sớm
hơn, tác động đến cả tính hữu dụng và chất lượng phần mềm. Công cụ giao tiếp
này sẽ làm cơ sở cho việc phân tích các kiến trúc về sau.
1.1.3 Kiến trúc và khung nhìn kiến trúc
Đối với những dự án lớn và phức tạp, chúng ta cần có rất nhiều những khung nhìn
(cách nhìn) liên quan đến kiến trúc của hệ thống đó. Một khung nhìn (View) là sự
mô tả một số phần tử của hệ thống và mối quan hệ đi cùng với chúng. Các khung
nhìn sẽ giúp ta hiểu rõ từng thành phần liên quan thông qua hệ thống khái niệm
trừu tượng. Các khung nhìn khác nhau đáp ứng cho những người dùng khác nhau
– ở đây là những người quan tâm đến kiến trúc. Những khung nhìn nào liên quan
đến nhau còn tùy vào đối tượng người tham gia và các thuộc tính hệ thống mà họ
quan tâm. Chúng ta có thể lấy kiến trúc của một tòa nhà làm ví dụ, sẽ có rất nhiều
người liên quan đến xây dựng tòa nhà đó (kỹ sư xây dựng, thợ ống nước, thợ
điện…) đều quan tâm đến việc toàn nhà được xây dựng như thế nào. Tuy nhiên
mối quan tâm của họ đến các phần tử, sự quan hệ giữa chúng lại khác nhau và mỗi
khung nhìn (quan điểm) của họ đều đúng – mỗi khung nhìn đó đều mô tả một cấu
trúc được ánh xạ vào một mục tiêu là xây dựng tòa nhà. Đối với người kỹ sư thì
kiến trúc đầy đủ về tòa nhà với một tập các khung nhìn là rất cần thiết để mô tả
kiến trúc đó cho những người liên quan.
Tương tư như vậy, một kiến trúc phần mềm cũng có những đối tượng người tham
gia rất khác nhau, trong đó có thể bao gồm cả tổ chức, người dùng cuối, kỹ sư bảo
trì hệ thống, thao tác viên… Mỗi người tham gia đều có mối quan tâm riêng về các
thuộc tính chất lượng và mục tiêu của hệ thống, và như vậy tương ứng sẽ có các

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.

 Khung nhìn triển khai (Deployment view), cho biết các thành phần phần mềm
được cấp phát phần cứng như thế nào, ví dụ như bộ xử lý, thiết bị lưu trữ, thiết
bị ngoài, các bộ cảm biến đi cùng với các đường truyền thông kết nối chúng.
Khung nhìn triển khai cho ta cái nhìn rõ hơn về hiệu năng, độ tin cậy và các
đặc tính chất lượng khác trong thời gian thực.
1.1.4 Lý do cần phải đánh giá một kiến trúc
Trong các dự án phần mềm, chi phí để sửa một lỗi được tìm thấy trong khi phân
tích yêu cầu hoặc trước pha thiết kế nhỏ hơn rất nhiều so với chi phí sửa chữa khi
nó được phát hiện trong pha kiểm thử (Testing). Kiến trúc là một sản phẩm của
pha trước khi thiết kế và ảnh hưởng của nó lên toàn hệ thống và dự án là vô cùng
lớn.
Một kiến trúc không phù hợp có thể gây ra thảm họa cho dự án. Các mục tiêu - ví
dụ về hiệu năng, bảo mật sẽ không đạt được. Khách hàng càng sốt ruột vì hệ thống
hoạt động thiếu hụt chức năng và rất khó để chỉnh sửa. Thời gian sau đó, các thay
đổi có thể đã được đoán và được lên kế hoạch trước sẽ bị hủy bỏ bởi vì chúng quá
tốn kém.
Kiến trúc cũng chỉ ra cấu trúc của dự án đó: Các thư viện kiểm soát cấu hình, tiến
độ và ngân sách, các mục tiêu hiệu năng, cấu trúc nhóm, tổ chức tài liệu và kiểm
định các hoạt động bảo trì… tất cả đều được tổ chức xung quanh kiến trúc của hệ
thống. Nếu thay đổi các thành phần trong khi đang phát triển do một số thiếu hụt
chức năng mới được phát hiện thì khi đó toàn bộ dự án có thể rơi vào tình trạng

-13-

hỗn loạn (chaos) Như vậy sẽ tốt hơn nếu ta thay đổi kiến trúc trước khi nó được
chuyển cho các pha xây dựng tiếp theo .
Tuy nhiên, để chọn được kiến trúc tối ưu nhất thì chắc chắn người ta phải có một
phương pháp nào đó để kiểm tra xem kiến trúc nào là phù hợp, kiến trúc nào là tốt
nhất v.v… Đây là công việc của đánh giá kiến trú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á.

1.1.6 Những thành phần tham gia đánh giá kiến trúc
Có hai nhóm người sau đây liên quan đến phiên đánh giá kiến trúc:
 Nhóm đánh giá (Evaluation team). Đây là những người sẽ phụ trách phiên
đánh giá và thực hiện quá trình phân tích.
 Những người liên quan (Stakeholders). Là những người có sự quan tâm đến
kiến trúc hay hệ thống mà chúng ta đang xây dựng. Một số người trong nhóm

-14-

này cũng có thể là thành viên của nhóm phát triển, như: Coders, Integrators,
testers, maintainers, v.v…
1.1.7 Kết quả của phiên đánh giá kiến trúc
Sau khi kết thúc phiên đánh giá thì kết quả đầu ra sẽ là các báo cáo. Hình thức và
nội dung của báo cáo này có thể sẽ rất khác tùy theo kiến trúc mà chúng ta lựa
chọn. Tuy nhiên, về cơ bản thì kết quả đó cho ta một thông tin để trả lời 2 loại câu
hỏi:
 Kiến trúc đó có phù hợp với hệ thống được thiết kế hay không?
 Kiến trúc nào (trong hai hoặc nhiều kiến trúc ứng cử) là phù hợp nhất?
Một kiến trúc được gọi là phù hợp nếu nó phù hợp với những yêu cầu cho trước và
những yêu cầu đặt ra sau đó trong quá trình nghiên cứu, phân tích. Cụ thể là:
1. Hệ thống sinh ra phải phù hợp với các mục tiêu về chất lượng. Chẳng hạn, hệ
thống phải chạy như chúng ta mong đợi, phải đủ nhanh để đáp ứng được các
yêu cầu về hiệu năng hay có thể sửa đổi lại được theo cách nào đấy mà chúng
ta đã dự định, đồng thời hệ thống cũng phải thỏa mãn được các ràng buộc về
tính bảo mật. Tuy không phải bất kỳ một thuộc tính chất lượng nào cũng là kết
quả trực tiếp từ kiến trúc đó nhưng nhiều thuộc tính bị ảnh hưởng trực tiếp của
việc thiết kế kiến trúc. Một kiến trúc là phù hợp nếu như nó cung cấp được một
bản thiết kế để từ đó xây dựng được hệ thống đáp ứng được các yêu cầu này.
2. Hệ thống có thể được xây dựng sử dụng các tài nguyên sẵn có như: con người,
thời gian, ngân sách, phần mềm… Hay nói cách khác kiến trúc phải có khả

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

gian mà hệ thống cần để hoàn thành một giao dịch.
 Tính tin cậy (Reliability): Là khả năng duy trì hoạt động của hệ thống theo
thời gian. Độ tin cậy thường được đo bởi chỉ số thời gian hệ thống dẫn đến
trục trặc.
 Tính sẵn sàng (Availability): Là khả năng phục vụ của hệ thống. Tính sẵn
sàng thường được đo bởi tỉ lệ giữa thời gian mà hệ thống sẵn sàng hoạt
động và thời gian hệ thống gặp trục trặc.
 Tính bảo mật (Security): Là thước đo về khả năng của hệ thống chống lại
các xâm nhập trái phép và từ chối các dịch vụ trong khi vẫn cung cấp các
dịch vụ đối với những người dùng hợp pháp.
 Tính sửa đổi (Modifiability): Là khả năng thực hiện thay đổi hệ thống một
cách nhanh chóng với một chi phí hợp lý. Tính hiệu quả được đo lường bởi
các thay đổi và chi phí cần cho những thay đổi này.
 Tính khả chuyển (Portability): Là khả năng của hệ thống có thể chạy trên
những môi trường tính toán khác nhau mà không cần có sự thay đổi. Các
môi trường này có thể là phần cứng, phần mềm hoặc kết hợp cả hai. Trong
trường hợp khi chuyển sang môi trường mới mà đòi hỏi có sự thay đổi thì
đơn giản đó là dạng đặc biệt của Tính sửa đổi.
 Chức năng hoạt động (Functionality): là khả năng thực hiện đúng vf chính
xác các chức năng của hệ thống, các chức năng này thường được đặc tả
trong bản đặc tả yêu cầu phần mềm (SRS).
1.1.9 Lợi ích và chi phí của việc đánh giá kiến trúc.
Rõ ràng, lợi ích chủ yếu của việc đánh giá kiến trúc đó là phát hiện ra các vấn đề
mà nếu không sẽ càng làm tăng thêm chi phí lên gấp bội nếu phải sửa chữa nó sau
đó. Nói cách khác, việc đánh giá kiến trúc sẽ cho ta kiến trúc tốt hơn. Vì giả sử có
không phát hiện ra vấn đề trong kiến trúc đó thì ít nhất nó cũng làm cho mọi người
tin tưởng vào kiến trúc đang được xây dựng.
Tuy nhiên, còn có rất nhiều lợi ích khác nữa. Dù một số kiến trúc rất khó để có thể
đo đếm được nhưng tất chúng cả đều góp phần vào sự thành công của dự án. Một
số lợi ích có thể liệt kê dưới đây:

 Đặ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ẫu thiết kế (design patterns) và mức code (code-level).
Các mẫu có rất nhiều ưu điểm. Thứ nhất, nó được công nhận là giải pháp kỹ thuật
tốt cho một số loại bài toán nào đó. Vì vậy, thay vì tốn nhiều thời gian để nghiên
cứu ra một cái gì đó thì người ta đã có ngay giải pháp tốt cho vấn đề. Thứ hai, các
mẫu cũng tạo dựng nên một vốn từ vựng chung giữa các nhà phát triển, bởi vậy
các nhà phát triển khác nhau sẽ hiểu ngay được những ý tưởng của hệ thống được
xem là tương thích với một mẫu nào đó.
Mỗi phong cách kiến trúc thường giải quyết một số vấn đề chuyên biệt, có liên
quan đến chất lượng. Chẳng hạn, kiến trúc Client-Server được xem như hỗ trợ rất
tốt thuộc tính liên tác (Operability), phong cách kiến trúc đa tầng (n-tiers) hỗ trợ
rất tốt thuộc tính bảo trì (Maintainability), tính bảo mật (security).
1.1.11 Các quyết định kiến trúc – Architecture Decisions
Luận văn này sử dụng thuật ngữ ―Tiếp cận‖ (approaches) để thay cho một số thuật
ngữ đôi lúc gọi là ―Phong cách‖ (Style) hay ―Mẫu‖ (Pattern). Thuật ngữ ―Tiếp
cận‖ rất hay được Viện kỹ nghệ phần mềm Carnegie Mellon's Software
Engineering Institute ( sử dụng. Các phong cách và mẫu
thường được xem như là những giải pháp mẫu (có sẵn) cho một lớp các bài toán.
Các phong cách phổ biến bao gồm mô hình Client-Server, mô hình đối tường phân

-17-

tán (DOM), mô hình phân tầng, mô hình hướng dịch vụ SOA Mỗi một phong
cách đều có sẵn một tập các đặc tả để có thể dễ dàng cài đặt, thường là hiệu quả,
khả chuyển cũng như có nhiều ưu điểm khác.
1.2 Thuộc tính chất lượng
Mục tiêu của bất kỳ hệ thống phần mềm nào đều hướng tới mục tiêu đó là chất
lượng. Tuy nhiên, thế nào thì được coi là phần mềm chất lượng thì cũng có rất
nhiều định nghĩa khác nhau tùy thuộc vào quan điểm của từng người. Ví dụ với
người sử dụng thì họ quan niệm phần mềm chất lượng là dễ sử dụng và đáp ứng
được các yêu cầu công việc. Với nhà phát triển thì phần mềm chất lượng là phần

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 ?

Are the required
function a available in
the software ?
How reliable is the
software?
How easy is to
modify the software ?

-18-

chức năng của người dùng
theo như đặc tả hay không
 Interoperability
 Compliance
 Security
2
Reliability
Cho biết hệ thống có hoạt
động tin cậy hay không
ngay cả trong các tình
huống bất thường.
 Maturity
 Fault tolerance
 Recoverability
3
Usability
Cho biết hệ thống có dễ sử
dụng và vận hành đối với
người dùng hay không.
 Understandability

 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

trên thực tế còn có những yếu tố (thuộc tính) có thể coi là tối quan trọng đó là yếu
tố kinh doanh của doanh nghiệp. Các yếu tố này cũng được đưa vào để phân tích
kiến trúc phần mềm, như: Ngân sách (Money budget), quỹ thời gian (Time
budget), rủi ro, thời gian đưa sản phẩm ra thị trường,…
1.3 Một số thuật ngữ thông dụng
Một số thuật ngữ dưới đây thường xuyên được sử dụng trong các phương pháp
đánh giá kiến trúc phần mềm. Vì vậy, để tránh hiểu sai các khái niệm này trong
luận văn, nội hàm của mỗi khái niệm sẽ được mô tả một cách chi tiết.
1.3.1 Senario
Đối với mỗi hệ thống phần mềm, đều có rất nhiều đối tượng sử dụng khác nhau.
Việc sử dụng của mỗi lớp người này xét cho cùng thực chất là tập các tình huống
sử dụng chức năng của hệ thống. Các tình huống sử dụng này trong phân tích kiến
trúc vô cùng quan trọng bởi nó làm cơ sở để phát hiện ra các yêu cầu thuộc tính
chất lượng. Dựa vào các thuộc tính chất lượng này mà các bước tiếp theo mới tiếp
tục được thực hiện. Scenario được định nghĩa như sau:
Scenario là mô tả ngắn gọn về sự tương tác giữa người dùng với hệ thống phần
mềm (CMU/SEI).

-19-

Scenario là mô tả được xây dựng để thể hiện các bước cần thiết để thực hiện
một phần cụ thể công việc. Khi nhà phân tích hiểu đầy đủ về công việc thì họ sử
dụng các scenario để tạo ra các yêu cầu. (Robertson et al. 1999).
Scenario hoặc là một sự mô tả sống động phần công việc hoặc trường hợp cụ
thể của một tác vụ (Lauesen 2002).
Scenario là một thể hiện cụ thể, một kinh nghiệm, một trường hợp, một câu
chuyện xảy ra theo thời gian. Một scenario chứa bản mô tả về môi trường, bối
cảnh, tác nhân và các hành động. (McGraw et al. 1997).
Một số tác giả còn định nghĩa scenario như là những trường hợp sử dụng (use-
cases), như (Robertson et al. 1999), (Lauesen 2002), (Carroll 1995), hay (McGraw

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

lớn đến doanh nghiệp hay tổ chức. Vì vậy, khi phát triển các hệ thống phần mềm
thì họ đều đưa ra các yếu tố này và bắt buộc phải được đáp ứng. Ví dụ với một
doanh nghiệp thì business driver của họ có thể yêu cầu cụ thể như: Phần mềm phải
xong trước năm 2008; Chi phí phần mềm không được vượt quá 100.000 $; Tốc độ
tính toán trên mỗi giao dịch không được vượt quá 5s; hay hệ thống phải tuyệt đối
bảo mật….

-20-

1.3.4 Architecture Driver
Thông thường, mỗi kiến trúc phần mềm đều có một số thuộc tính chất lượng đặc
trưng, ví dụ với kiến trúc Đa tầng thì thuộc tính bảo trì và bảo mật được coi là nét
đặc trưng; Kiến trúc hướng dịch vụ (SOA) có đặc trưng là tính khả chuyển
(Portability) và dễ bảo trì… Vì vậy, thuật ngữ Architecture Driver là ám chỉ đến
những thuộc tính chất lượng chính tạo nên đặc trưng của kiến trúc.

-21-

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
Gần đây một số phương pháp đánh giá kiến trúc phần mềm dựa trên tình huống
(Scenario) đã được phát triển bởi rất nhiều nhóm nghiên cứu khác nhau. Chúng đã
được xuất bản ở rất nhiều dạng sách. Một số phương pháp trong đó phát triển từ
phương pháp SAAM và ATAM (ATAM được phát triển bởi SEI) bằng cách tinh
chỉnh lại một số điểm. Chẳng hạn phương pháp ALMA thừa kế từ SAAM nhưng
có điều chỉnh để dùng đánh giá sự thay đổi của hệ thống thông tin doanh nghiệp;
phương pháp FAAM được dùng để đánh giá tính liên tác và tính mở rộng của các
hệ thống thông tin.
Dưới đây xin đưa ra một tập các phương pháp hiện đang sử dụng để hỗ trợ cho
quá trình phân tích các thuộc tính chất lượng của kiến trúc phần mềm.

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

Or

-22-

thực tế. Qua thực tế, SAAM được chứng minh là rất hữu ích trong việc đánh giá
nhanh chóng rất nhiều thuộc tính chất lượng như : Modifiability, Portability,
Extensibility, Integrability và Functionality.
Phương pháp này cũng được sử dụng để đánh giá các khía cạnh chất lượng khác
của kiến trúc như là Hiệu năng và độ tin cậy. Tuy nhiên, ATAM (một phương
pháp khác được phát triển từ SAAM) giải quyết các thuộc tính này chi tiết hơn.
Nếu chỉ một kiến trúc được đưa vào phân tích thì SAAM chỉ ra các điểm yếu và
điểm mạnh của kiến trúc đó, đồng thời chỉ ra các điểm mà kiến trúc đó không đáp
ứng được các yêu cầu về tính sửa đổi.
Còn nếu có hai hoặc nhiều hơn các kiến trúc để lựa chọn đều cung cấp cùng chức
năng và cần so sánh về khía cạnh sửa đổi thì SAAM sẽ cho biết là kiến trúc nào là
tốt hơn.
2.1.3 Các yếu tố dẫn đến sự hình thành của SAAM
Việc phát triển SAAM bắt nguồn từ thực tế là có rất nhiều kiến trúc phần mềm để
lựa chọn trong khi lại thiếu hụt các phương pháp luận để lựa chọn kiến trúc phù
hợp. Các nhà thiết kế và kiến trúc không thể biết được chất lượng của phần mềm
mà họ đang phát triển cho đến khi dự án được hoàn thành. Hệ quả là, các thuộc
tính chất lượng cơ bản như tính sửa đổi, tính linh hoạt, hay tính bảo trì không được
đo lường và phân tích trực tiếp bởi các phương tiện phần mềm. Do vậy, một
phương pháp như SAAM ra đời chính là nhằm giải quyết những hạn chế đó.
2.1.4 Các yêu cầu và đầu vào của SAAM
Các thuộc tính chất lượng cần trong phiên đánh giá SAAM phải được xác định
trong rõ ràng trong một ngữ cảnh nhất định. Hay nói cách khác, các scenario sẽ
được xem là phương tiện dùng để xác định và đánh giá các thuộc tính chất lượng.
Bên cạnh các scenario thì cũng cần phải cung cấp các tài liệu, công cụ tham chiếu
mà các scenario ánh xạ đến cho tất cả những người tham gia.

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.

Do SAAM tập trung đánh giá tính sửa đổi của hệ thống nên các scenario đưa vào
bỏ phiếu là những scenario gián tiếp.
SAAM Step 4 – Đánh giá từng scenario gián tiếp
Trong trường hợp của scenario trực tiếp thì nhà kiến trúc sẽ chỉ ra scenario được
thực hiện bởi kiến trúc đó như thế nào, còn trong trường hợp scenario gián tiếp thì
nhà kiến trúc sẽ mô tả kiến trúc cần phải thay đổi như thế nào để thích nghi với
scenario đó.
SAAM Step 5 – Xác định scenario tương tác
Khi có hai hoặc nhiều hơn scenario yêu cầu thay đổi trên cùng một thành phần của
kiến trúc thì chúng được xem là tương tác với nhau. Trong trường hợp đó, các
thành phần bị tác động cần phải được sửa đổi hoặc phải được chia thành các thành
phần con để tránh sự tương tác của các scenario.
SAAM Step 6 – Đánh giá tổng thể
Tại bước này, mỗi scenario được gán một trọng số theo mức độ quan trọng của
chúng đối với sự thành công của hệ thống. Các trọng số này có sự ràng buộc chặt
chẽ với các mục tiêu của doanh nghiệp thể hiện qua các scenario, ngoài ra nó còn
phụ thuộc vào các yếu tố khác như chi phí, rủi ro, thời gian đưa ra thị trường v.v…
Dựa vào việc đánh trọng số scenario này, có thể đề xuất ra thứ hạng tổng thể cho
các kiến trúc nếu có nhiều kiến trúc được đưa vào phân tích.
2.1.6 Các đối tƣợng tham gia phiên đánh giá SAAM
Vai trò của những đối tượng tham gia phiên đánh giá SAAM có thể chia làm 3
lớp:
a. External Stakeholders: là những người không tham gia trực tiếp vào quá trình
phát triển kiến trúc nhưng có liên quan đến hệ thống. Vai trò của họ là mô tả các
mục tiêu doanh nghiệp, cung cấp các thuộc tính chất lượng và mức độ kỳ vọng

-24-

vào việc đạt được chất lượng này; Họ cũng cung cấp các scenario trực tiếp và gián
tiếp cùng với mức độ ưu tiên tương ứng. Những External Stakeholders có thể kể ra

ở đâ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.

2.1.10 Điểm mạnh và đầu ra của SAAM
Điểm mạnh của SAAM:
 Những người liên quan hiểu rất sâu về kiến trúc đang được phân tích
 Trong nhiều trường hợp, sau khi kết thúc phiên đánh giá SAAM thì tài liệu
cho kiến trúc được cải thiện đáng kể (những người tham gia đóng góp)
 Tăng cường giao tiếp về hệ thống giữa những người liên quan.
Trên cơ sở những ưu điểm kể trên của SAAM, đầu ra sau phiên đánh giá SAAM sẽ
là:
Tạo ánh xạ giữa những scenario được thảo luận với kiến trúc có liên quan đến sự
thay đổi trong tương lai của hệ thống. Kết quả là các phần có độ phức tạp tiềm tàng