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

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

Đạ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

Đạ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Ụ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

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

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

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

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

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

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

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:

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

Để 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

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

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

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

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ể

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 (http://www.sei.cmu.edu/) 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

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

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 ?

chức năng của người dùng theo như đặc tả hay không

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?

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

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)

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

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…

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

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

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ệ

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

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

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

cao sẽ được xác định Ngoài ra, các chi phí và công sức bỏ ra thực hiện các thay đổi cũng được ước lượng Việc dựa vào thứ hạng ưu tiên của các scenario cũng giúp cho chúng ta định hình con đường phát triển hệ thống tiếp theo

2.11 Một số lưu ý về SAAM

Để áp dụng SAAM thành công, thì khi áp dụng SAAM cần lưu ý một số điểm sau:

 Quá trình sinh ra các scenario hoàn toàn dựa vào tầm nhìn của người tham

gia Điều này đòi hỏi họ phải đầu tư suy nghĩ thêm về các scenario gián tiếp

 SAAM không đưa ra được độ đo chính xác cho các thuộc tính chất lượng được đưa vào phân tích

 Việc mô tả kiến trúc chỉ là khái niệm mờ và được chấp thuận mà không có

ký pháp hay phương pháp mô tả được chuẩn hóa Tất cả các kiến trúc phải được coi là các kiến trúc dự tuyển, chưa phải là cuối cùng, vì vậy việc mô tả phải đảm bảo dễ hiểu đối với những người

 Nhóm đánh giá chỉ đề xuất các kiến trúc khác nhau (nếu có) dựa vào kinh nghiệm của những nhà kiến trúc chứ không nên suy luận và đề xuất ra các kiến trúc có thể khác vì nhóm kiến trúc không thể hiểu được đầy đủ các yêu cầu nghiệp vụ của doanh nghiệp

 SAAM là phương pháp tinh chỉnh từng bước khi thực hiện phân tích kiến trúc phần mềm Tuy nhiên, tùy vào kinh nghiệm thực tế của nhà phân tích/ nhà đánh giá mà có thể thực hiện theo các bước khác nhau

2.2 Phương pháp ALMA – Architecture Level Modifiability Analysis

Phương pháp phân tích tính sửa đổi ở mức kiến trúc – ALMA – là kết quả nghiên cứu của 2 tác giả Bengtsson và Lassing

ALMA được phát triển theo quan điểm đánh giá hướng mục tiêu (Goal – Oriented) Việc thiết lập mục tiêu là hoạt động quan trọng nhất của phương pháp này, các hoạt động còn lại được thực hiện chỉ nhằm làm sáng tỏ mục tiêu đánh giá Hình dưới đây thể hiện triết lý của phương pháp này Mục tiêu cụ thể của phương pháp là xác định rõ tính sửa đổi của các vấn đề liên quan ở mức kiến trúc Mục tiêu đó có thể là:

 Dự đoán về chi phí bảo trì – Tức là việc ước lượng công sức bỏ ra để thỏa mãn các scenario thay đổi tới phần mềm

 Đánh giá rủi ro- Xác định các loại thay đổi mà ở đó kiến trúc phần mềm không thể đáp ứng

2.2.1 Ngữ cảnh sử dụng ALMA

Ban đầu, ALMA được phát triển và dùng để kiểm định chỉ cho hệ thống thông tin doanh nghiệp Nó được coi là một phương pháp đánh giá các thuộc tính kiến trúc phần mềm dựa trên scenario ALMA cũng được xem là phù hợp cho các hệ thống nhúng (Embedded systems), tuy nhiên điều này vẫn chưa được chứng minh

Việc phân tích tính sửa đổi thường hướng tới 3 mục tiêu:

 Dự báo các chi phí cho việc sửa đổi trong tương lai

 Xác định các hạn chế của hệ thống

 So sánh hai hoặc nhiều các kiến trúc với nhau

2.2.2 Mục tiêu của ALMA

ALMA là một phương pháp phân tích dựa trên scenario, thích hợp cho việc đánh giá tính sửa đổi của kiến trúc phần mềm bằng cách áp dụng một tập các chỉ báo như: dự đoán chi phí bảo trì, đánh giá rủi ro Trong trường hợp cần so sánh và đánh giá các hệ thống khác nhau, việc phân tích tính sửa đổi được thực hiện bởi ALMA sẽ hỗ trợ lựa chọn kiến trúc phần mềm tốt hơn Vì mục tiêu này mà ALMA sử dụng các Change-Case do những người liên quan cung cấp

Phân tích tính sửa đổi bắt đầu với việc định nghĩa ra một tập các scenario có thể xuất hiện trong quá trình phát triển của hệ thống Các scenario được sử dụng để kiểm tra xem kiến trúc hiện tại hỗ trợ hoặc thích nghi với những thay đổi trong tương lai tốt như thế nào?

2.2.3 Các yếu tố dẫn đến sự hình thành của ALMA

Các hạn chế cơ bản của một số phương pháp đánh giá kiến trúc hiện nay bao gồm:

 Chúng tập trung vào một thuộc tính chất lượng đơn lẻ mà bỏ qua các thuộc tính khác nhưng rất quan trọng

 Chúng quá chi tiết và tỉ mỉ trong phân tích vì vậy đôi khi vượt quá thời gian cho phép

 Các kỹ thuật đó thường dùng cho các phase thiết kế về sau và thường đòi hỏi các thông tin chi tiết, cái mà không có trong giai đoạn thiết kế kiến trúc Mục tiêu xây dựng ALMA là nhằm khắc phục những hạn chế này

Ngoài ra còn phải kể đến một số nhân tố khác như:

 Thực tế cho thấy có đến 50% tới 70% chi phí của toàn bộ chu trình phát triển hệ thống là chi cho công việc cải tiến, phát triển tiếp theo Vì vậy, tính sửa đổi đối với những thay đổi được mong đợi/ không mong đợi rất cần phải được xem xét

 Áp lực cải tiến chất lượng và tối thiểu hóa chi phí ngày càng tăng, khoảng thời gian tồn tại của sản phẩm trong môi trường doanh nghiệp rất ngắn đã ảnh hưởng mạnh mẽ tới tính sửa đổi của hệ thống

 Thiếu hụt các kỹ thuật đánh giá kiến trúc để có thể xác định được số lượng thuộc tính chất lượng của kiến trúc đó

 Thiếu hụt các phương pháp đánh giá tập trung vào tính sửa đổi có khả năng chỉ rõ nhiều mục tiêu phân tích, đưa ra các chứng minh và cung cấp các kỹ thuật xây dựng tài liệu rõ ràng trong quá trình thực hiện

2.2.4 Các yêu cầu và đầu vào của ALMA

ALMA được xây dựng trên cơ sở của SAAM, bởi vậy phương pháp này cũng đòi hỏi một số yêu cầu tương tự như SAAM:

 Những người liên quan được yêu cầu cung cấp các change scenario có thể xuất hiện trong chu trình hệ thống trong tương lai ALMA sử dụng các scenario này để phân tích tính sửa đổi của kiến trúc

 Những nhà phân tích/ đánh giá phải có khả năng đánh giá được sự ảnh hưởng và chi phí mà các scenario này gây ra

Đầu vào cho phiên đánh giá ALMA bao gồm:

 Mô hình ―4+1‖ được Kruchten đề xuất để dùng cho đặc tả kiến trúc

 Ký pháp UML để mô tả kiến trúc phần mềm The UML notation for

software architecture description

2.2.5 Các bước thực hiện phiên đánh giá ALMA

Phương pháp ALMA được thực hiện theo 5 bước Các bước này không nhất thiết phải tiến hành tuần tự Một số bước có thể lặp lại nhiều lần trong quá trình đánh giá

ALMA Bước 1 – Thiết lập mục tiêu phân tích

Hoạt động đầu tiên đó là định ra các mục tiêu phân tích ALMA hướng tới các mục tiêu: đánh giá rủi ro, dự báo các chi phí bảo trì và công sức cần bỏ ra để sửa đổi kiến trúc sao cho thích nghi với những thay đổi

ALMA Bước 2 – Mô tả các kiến trúc phần mềm

Công việc mô tả kiến trúc cần sử dụng một số các khung nhìn kiến trúc, tại đó mô

tả việc phân tách hệ thống thành các thành phần (Components), mối quan hệ giữa các thành phần và các mối quan hệ giữa hệ thống và môi trường của nó

ALMA Bước 3 – Chọn lọc change-scenarios

Lựa chọn Change-scenario là quá trình tìm và lựa chọn các scenario có thể đóng vai trò nào đó liên quan tới tính sửa đổi kiến trúc Các scenario này sẽ được sử dụng trong phiên đánh giá ALMA Việc lựa chọn các Change-scenario thường liên quan đến các hoạt động như xác định những người có liên quan, phỏng vấn họ, xây dựng tài liệu cho các scenario đã được chọn được và cùng những người liên quan đánh giá tính khả thi của các kết quả đạt được

ALMA Bước 4 – Đánh giá các change-scenarios

Tại bước này, các nhà phân tích ALMA kết hợp với các nhà kiến trúc và nhà phát triển đánh giá sự tác động của các change-scenarios tới kiến trúc hệ thống và mô tả kết quả theo cách có thể đo lường được

ALMA Bước 5 – Trình bày kết quả

Sau khi đánh giá các change-scenarios, kết quả sẽ được mô tả như mục tiêu phân tích và được đối chứng với các yêu cầu hệ thống Các kết quả này được sử dụng để

dự báo các chi phí cho bảo trì Chi phí ước lượng này có hạn chế là không phải lúc nào cũng đáng tin cậy vì không có chuẩn hay các ước lượng khác để so sánh cho thuộc tính này

2.2.6 Các đối tƣợng/ vai trò tham gia trong ALMA

Trong phiên đánh giá ALMA thì đối tượng tham gia được chia thành các nhóm người: Người tham gia ngoài (external stakeholders), người trong nội bộ (internal stakeholders) và nhóm ALMA

a External stakeholders là những người không có liên quan trực tiếp trong quá

trình phát triển kiến trúc phần mềm Vai trò của họ chỉ là mô tả tình trạng của doanh nghiệp thuộc dự án, cung cấp các change scenarios và các yêu cầu ban đầu của hệ thống Cuối phiên đánh giá, dựa trên kết quả đạt được mà nhóm người này cần phải quyết định về việc có nên tiếp tục phát triển nữa hay không Những external stakeholders có thể là người dùng, khách hàng, kỹ sư bảo trì, nhà tài trợ, người sở hữu sản phẩm, nhà quản lý v.v

b Internal stakeholders là những người có liên quan trực tiếp tới quá trình phát

triển kiến trúc phần mềm Họ có nhiệm vụ phân tích, định nghĩa và trình diễn các khái niệm và khung nhìn kiến trúc khác nhau Trong phiên đánh giá ALMA thì họ chịu trách nhiệm mô tả và trình diễn các kiến trúc của hệ thống Cùng với nhóm đánh giá, các internal stakeholders ước lượng sự ảnh hưởng của các change scenarios đối với kiến trúc xét về góc độ mục tiêu phân tích; đánh giá độ tin cậy các kết quả của ALMA để biết được công sức cho sửa đổi Ví dụ về các internal stakeholders là nhà kiến trúc phần mềm, nhà phân tích, nhà thiết kế, nhà phát triển

c Nhóm ALMA là những người không có lợi ích trực tiếp từ kiến trúc phần mềm

của hệ thống nhưng họ được mời để xây dựng lên tiến trình đánh giá Nhóm ALMA đóng vai trò là người lãnh đạo trong việc trình diễn, đánh giá các kết quả cuối cùng Nhóm ALMA không có vai trò hỗ trợ những người tham gia trong việc tạo ra các change-scenario cũng như không có hỗ trợ cho những nhà kiến trúc trong việc trình diễn kiến trúc phần mềm Những nhà kiến trúc cùng với nhóm ALMA có nhiệm vụ xác định các change scenarios ảnh hưởng lên các kiến trúc khác nhau và dự báo chi phí cho sửa đổi trong mỗi trường hợp nhóm đánh giá ALMA bao gồm một trưởng nhóm hoặc người phát ngôn, các nhà phân tích kiến trúc và một thư ký

2.2.7 Ƣớc lƣợng chi phí khi áp dụng ALMA

Việc ước lượng chi phí dựa vào hiểu biết của những người tham gia và của những người am hiểu về kiến trúc cũng như dựa vào số change-scenario và độ phức tạp của kiến trúc đang được xem xét

2.2.8 Công cụ hỗ trợ ALMA

Hiện nay chưa có công cụ nào hỗ trợ ALMA Các change-scenarios được sinh ra dựa trên cơ sở phỏng vấn giữa con người với con người, mỗi scenario có thể sử dụng các mẫu, các qui tắc định trước để ghi nhận Các công cụ sử dụng ở đây có thể kể ra như bảng trắng, biểu đồ, bảng ước lượng, sổ ghi chép hay các phương tiện ghi âm Ngoài ra các biểu đồ UML cũng được sử dụng cho việc mô tả kiến trúc

2.2.9 Các phương pháp thay thế cho ALMA

The Architecture Tradeoff Analysis Method (ATAM) is a possible substitute of ALMA with respect to modifiability Both methods are quite similar, since they use scenarios for assessing the quality attributes and provide estimates with respect to the analysis goals

2.2.10 Những ưu điểm và đầu ra của ALMA

Những điểm mạnh và đầu ra của ALMA được phát biểu như sau:

a ALMA tập trung vào các khái niệm có tính kiến trúc thường dùng để thể hiện chức năng của miền ứng dụng và các thuộc tính chất lượng quan trọng

b Đánh giá scenario dựa vào việc phân tích sự ảnh hưởng của chúng Công việc này bao gồm việc xác định các thành phần bị ảnh hưởng và chỉ ra được sự tác động lên các thành phần đó

c Những người liên quan có hai lựa chọn trong việc tạo ra các change scenarios Cách thứ nhất là tiếp cận theo hướng top-down, tức là xuất phát từ change-scenario tổng quát sau đó tinh chỉnh và đi đến các scenario cụ thể Cách thứ hai là theo hướng Bottom up, tức là các change-scenario sẽ được tập hợp lại, sau đó những người liên quan sẽ phân loại các scenario này thành các lớp danh mục riêng

d Khả năng đánh giá tính sửa đổi từ rất nhiều góc độ khác nhau, như: dự báo chi phí và bảo trì, đánh giá rủi ro, và/hoặc lựa chọn kiến trúc phần mềm

e Đưa ra các giả định tường minh

f Cung cấp các kỹ thuật thực hiện các bước, có tính lặp lại được

Đầu ra của phương pháp này bao gồm:

a Kết quả ước lượng sự ảnh hưởng của mỗi scenario kết quả này được mô tả

bằng (1) kích thước của các thành phần hiện tại cần sửa đổi hoặc (2) kích thước của các thành phần được ước lượng cần phải được xem xét

b Một mô hình dự báo tính sửa đổi dựa trên khối lượng thay đổi được ước lượng

Mô hình này giả thiết rằng khối lượng thay đổi là yếu tố chi phối chính đến chi phí, vì vậy mô hình cho ta hình ảnh về tính hiệu quả chi phí khi thêm code mới và sửa đổi code cũ

c Một tiêu chuẩn dừng việc sinh ra scenario (1) nếu tất cả các loại scenario đã

được xem xét tường minh hoặc (2) việc sinh ra các change scenarios mới không ảnh hưởng đến cấu trúc phân loại

2.3 Phương pháp đánh giá kiến trúc FAAM (Family-Architecture

Assessment Method)

2.3.1 Ngữ cảnh sử dụng FAAM

FAAM là một phương pháp đánh giá kiến trúc của các dòng hệ thống thông tin, tập trung vào 2 khía cạnh liên quan đến chất lượng: tính liên tác và tính mở rộng (interoperability and extensibility)

2.3.2 Mục tiêu của FAAM

Mục tiêu của FAAM là thiết lập một qui trình đánh giá các kiến trúc thuộc dòng

hệ thống thông tin Điểm khác của FAAM so với các phương pháp trước đây là FAAM góp phần:

 Những người liên quan thuộc họ sản phẩm tham gia chủ động vào quá trình tạo ra sản phẩm,

 Tập trung vào các thuộc tính chất lượng là tính liên tác và tính mở rộng của các dòng hệ thống thông tin,

 Nhấn mạnh đến các kỹ thuật và tri thức thực tế nhằm cho phép các nhóm phát triển trong tổ chức cài đặt phương pháp này

2.3.3 Những yếu tố dẫn đến sự hình thành của FAAM

Một số những yếu tố liên quan góp phần vào sự phát triển của FAAM bao gồm:

 Nhu cầu cần một phương pháp hỗ trợ những người tham gia xác định và mô

tả các changes-cases của hệ thống trong tương lai

 Sự cần thiết phải có các kỹ thuật giúp cho sự tương tác nhiều hơn giữa những người tham gia và các nhà kiến trúc trong quá trình phát triển kiến trúc

 Sự cần thiết phải có các kỹ thuật có thể tạo ra các cơ sở về kiến trúc cho những người tham gia

 Cần khả năng suy đoán về tính liên tác và tính mở rộng của dòng hệ thống này sớm trong các phase phân tích và xây dựng kiến trúc

2.3.4 Các yêu cầu và đầu vào của FAAM

FAAM cũng dựa trên những nguyên lý đánh giá giống như SAAM và ATAM nhưng có một số yêu cầu riêng như:

 Những người được mời tham gia phải có kinh nghiệm với các kỹ thuật liên quan nhằm thiết lập lên các yêu cầu và mục tiêu khởi đầu cho phiên đánh giá

 Phải có hoặc phải chuẩn bị đặc tả kiến trúc trước khi bắt đầu phiên đánh giá FAAM

 Những người như sponsor, architect hay stakeholders phải sẵn sàng đưa ra

kỳ vọng của mình sau phiên đánh giá

Các đầu vào của phiên đánh giá FAAM gồm:

 Các mẫu Change-case đặc tả các thay đổi có thể xảy ra đối với tính liên tác

và tính mở rộng của hệ thống

 Các mẫu hoặc các kỹ thuật sinh bảng ánh xạ đặc tính, các biểu đồ và tiêu chuẩn phân hạng các yêu cầu Các qui tắc cũng có thể được sử dụng để hỗ trợ quá trình sinh ra các change-case Việc mô tả kiến trúc dựa trên các khung nhìn của ―mô hình 4+1‖, nhưng thường thì tập trung vào sự logic, qui trình, và các khung nhìn

2.3.5 Các bước trong một phiên đánh giá FAAM

FAAM được mô tả bởi 6 bước theo thứ tự về thời gian Tuy nhiên, điểm cần lưu ý

đó là các bước của phiên đánh giá FAAM phải thích ứng với kinh nghiệm đánh giá kiến trúc nói chung của tổ chức đó

FAAM Bước 1 – Xác định mục tiêu đánh giá

Đây là công việc cơ bản để xác định mục tiêu của phiên đánh giá Để trả lời cho cầu hỏi này, trước tiên cần giải quyết một số vướng mắc:

 Xây dựng phạm vi và nội dung của họ hệ thống bởi những người tham gia;

 Xây dựng kế hoạch tương lai cho các thay đổi về tính liên tác và tính mở rộng;

 Cung cấp các nguyên tắc cho người tham gia để trợ giúp họ đưa ra các yêu cầu;

 Cung cấp các nguyên tắc về phân mức ưu tiên các yêu cầu để đánh giá;

FAAM Bước 2 – Chuẩn bị các yêu cầu thuộc tính hệ thống

Tại bước này, những người liên quan cần xác định và phân mức ưu tiên các yêu cầu về chất lượng hệ thống Thách thức ở đây là vấn đề cung cấp phương tiện cho người tham gia thực hiện trình diễn các yêu cầu ở dạng có cấu trúc để có thể làm

cơ sở cho việc đánh giá về sau

FAAM Bước 3 – Chuẩn bị kiến trúc

Bước này của phương pháp liên quan tới việc chuẩn bị sẵn sàng mô tả kiến trúc cho việc trình diễn và đánh giá so với các yêu cầu của người tham gia Vấn đề ở đây là cần phải cung cấp các nguyên tắc cho các nhà kiến trúc khi trình diễn các khung nhìn kiến trúc

FAAM Bước 4 – Rà soát/ điều chỉnh các kết quả Review / Refine Artifacts

Mục tiêu ở đây là đi đến sự thống nhất về tập các yêu cầu và các khung nhìn kiến trúc có liên quan sẽ được tiến cho đến các bước đánh giá tiếp theo Thách thức ở đây là làm rõ các nghiệp vụ và ràng buộc logic, cái mà có thể hưởng đến việc đánh giá tiếp theo

FAAM Bước 5 – Đánh giá sự phù hợp của kiến trúc

Mô tả kiến trúc được kiểm định lại so với các yêu cầu đã được đặc tả bằng việc tập trung vào khả năng và sự dễ dàng tích hợp hay thỏa mã các change-cases đã được đặc tả ở bước 2

Bước 6 – Báo cáo các kết quả và đề xuất

Trong pha này, các kết quả đánh giá được ghi nhận và thông tin ngược trở lại đối với những người tham gia Dựa trên các kết quả của bước 5, những người có khả năng cùng với nhóm kiến trúc sẽ mô tả các bài học đã học được để thực hành việc đánh giá

2.3.6 Các đối tƣợng tham gia phiên đánh giá FAAM

Như phương pháp đã được mô tả ở bước trước, FAAM có một số vai trò tham gia tích cực, bao gồm:

a Family stakeholders (Những người đánh giá) hay còn gọi là những External

Stakeholder, không có sự liên quan trực tiếp trong quá trình phát triển phần mềm Vai trò của họ là mô tả bối cảnh của doanh nghiệp thuộc dự án và phân hạng các yêu cầu hệ thống, tiếp theo là quyết định dựa trên kết quả đánh giá Ví dụ về những người này bao gồm: quản lý doanh nghiệp, quản lý sản phẩm, quản lý hỗ trợ khách hàng, quản lý phát triển v.v…

b Internal stakeholders: là những người liên quan trực tiếp tới quá trình đánh

giá kiến trúc phần mềm Họ có vai trò phân tích, định nghĩa và trình diễn các khái niệm và khung nhìn kiến trúc trong phiên đánh giá FAAM Ví dụ về những internal stakeholders, đó là nhà kiến trúc hay nhóm kiến trúc

c Đội FAAM (Những người tổ chức) là những người không liên quan trực tiếp tới kiến trúc phần mềm của hệ thống nhưng lại là những người tổ chức ra quá trình đánh giá Những nhà tổ chức đóng vai trò hỗ trợ những người tham gia trong việc sinh ra các change-case và yêu cầu, ngoài ra còn giúp những nhà kiến trúc trình diễn kết quả (nếu cần thiết) nhóm đánh giá FAAM bao gồm trưởng nhóm, người phát ngôn, các chuyên gia thuộc lĩnh vực ứng dụng, các chuyên gia kiến trúc ngoài (đây là tùy chọn, mục đích là đảm bảo tính hình thức hơn) Ngoài ra, cũng có thể

cử thêm 1 thư ký

2.3.7 Ƣớc lƣợng chi phí khi áp dụng FAAM

Vì công sức bỏ ra để áp dụng FAAM phụ thuộc vào bản chất của quá trình đánh giá, mức độ kinh nghiệm của những người tham gia, do vậy khoảng thời gian cần thiết để đánh giá nhiều nhất là 3 ngày So sánh với các phương pháp khác và dựa vào thực tế áp dụng FAAM cho thấy công sức đó bỏ ra là tương đối nhỏ Còn về mức độ phức tạp thì luôn phụ thuộc vào dòng hệ thống khi đánh giá

2.3.8 Công cụ hỗ trợ FAAM

Như đã chỉ ra trước đó, FAAM chỉ được hỗ bởi các kỹ thuật liên quan đến family, các nguyên tắc và các mẫu để sinh ra change-scenario, tiêu chuẩn phân hạng yêu cầu, bản đồ family-feature, bản đồ chuyển đổi, biểu đồ family-context Không có công cụ nào hỗ trợ cho các diagram

2.3.9 Các thay thế cho FAAM

FAAM được xây dựng dựa trên SAAM nhưng có thêm các kỹ thuật giúp cho việc đánh giá được thuận lợi hơn ATAM có thể là một thay thế của FAAM Điểm khác nhau giữa FAAM và ATAM là phạm vi đánh giá ATAM vẫn chưa được áp dụng cho các hệ thống family information mặc dù về nguyên tắc là ATAM có hỗ trợ FAAM chỉ được thiết kế để đánh giá tính liên tác và tính mở rộng của các hệ thống family Vì vậy, phương pháp này có các kỹ thuật và qui trình đánh giá chuyên biệt

2.3.10 Các ưu điểm và đầu ra của FAAM

Các điểm mạnh và đầu ra của FAAM là:

 Phương pháp này cung cấp phương thức giúp cho nhóm phát triển có khả năng tự đánh giá, coi đó như là phương tiện để liên tục cải tiến

 Qui trình đánh giá nhìn chung là thích hợp cho lĩnh vực thuộc dòng hệ thống thông tin

 Qui trình FAAM được mô tả rõ ràng Điều này rất hữu ích trong việc hỗ trợ những người tham gia có kỹ thuật thực tế để tạo ra các phương tiện cần thiết phục vụ đánh giá tính liên tác và tính mở rộng

 FAAM được xây dựng dựa trên các phương pháp đánh giá kiểu như SAAM

và ATAM, vì vậy nó thừa kế các ưu điểm của các phương pháp này

2.4 Phương pháp phân tích cân bằng kiến trúc-ATAM (Architecture

Tradeoff Analysis Method)

2.4.1 Giới thiệu phương pháp

ATAM là một phương pháp phân tích kiến trúc phần mềm với mục tiêu nhằm hỗ trợ sự hài hòa (cân bằng) trong thiết kế Sau này nó được xem như là một mô hình dùng cho phân tích kiến trúc phần mềm

Mục tiêu cụ thể của ATAM là phân tích khả năng của các kiến trúc, đặc biệt là về thuộc tính chất lượng Nó trợ giúp thực hiện sự cân bằng giữa các thuộc tính mà ở

đó chúng có sự tác động qua lại/ phụ thuộc lẫn nhau ATAM được cho là có khả năng áp dụng trong bất kỳ giai đoạn phát triển nào của chu trình phần mềm Tuy nhiên, ATAM sẽ hiệu quả nhất khi áp dụng phân tích phiên bản cuối cùng của kiến trúc Đầu vào của ATAM bao gồm các mục tiêu doanh nghiệp (business goals), đặc tả phần mềm và bản mô tả kiến trúc phần mềm Đầu ra của ATAM là danh sách các scenario, các điểm nhạy cảm (sensitivity points), các điểm cân bằng (trade- off points), các rủi ro (risks), các tiếp cận kiến trúc (Software Architecture approaches),…

Các lĩnh vực có thể áp dụng ATAM bao gồm: Hệ thống chiến đấu, hệ thống chạy trên nền web, các hệ thống nhúng…

Quá trình phân tích ATAM được chia làm 4 pha, bao gồm 9 bước [4] như hình # Trong đó một số hoạt động được lặp lại ở cả hai pha Các hoạt động đầu tiên chỉ liên quan đến những người tham gia được lựa chọn - thông thường là những nhân viên kỹ thuật thuộc dự án Trong pha thứ hai, phạm vi của những người liên quan được mời tham dự sẽ nhiều hơn Kết quả của phiên đánh giá ATAM cần phải được

tài liệu hóa dưới nhiều khung nhìn khác nhau

ATAM không yêu cầu phải có các kỹ thuật đặc biệt khi đánh giá mà chỉ sử dụng các mô hình có tính chất lý thuyết khi phân tích và áp dụng các kỹ thuật heuristics

để suy diễn chất lượng theo các thuật ngữ của phong cách kiến trúc dựa trên thuộc tính (ABSA), các mẫu kiến trúc hay các scenario có liên quan đến chất lượng ATAM được xem như là một cách tiếp cận hoàn thiện vì đã được kiểm chứng trong rất nhiều lĩnh vực khác nhau Hiện nay công cụ hỗ trợ cho ATAM là ArchE đang được phát triển[33]

Dưới đây là hình mô tả mô hình của phương pháp ATAM và các bước thực hiện một phiên đánh giá ATAM:

Hình 4 - Mô hình phân tích ATAM

Hình 5 - Mô hình tiến trình của ATAM

Pha I : Pha trình diễn

Bước 1 Trình bày phương pháp ATAM Phương pháp này được mô tả lại cho

những người tham gia (thường là đại diện khách hàng, kiến trúc sư phần mềm, nhóm kiến trúc, nhà bảo trì, nhà quản trị, nhà quản lý, kiểm thử viên, nhà tích hợp…) việc mô tả lại là để mọi người biết rõ về ATAM và qui trình đánh giá sử dụng ATAM

Bước 2 Trình bày các business drivers Người quản lý dự án sẽ mô tả các mục

tiêu doanh nghiệp cần hướng tới, vì vậy cũng cho biết các architectural drivers là

gì (ví dụ độ sẵn sàng cao, thời gian phát hành sản phẩm nhanh, bảo mật…)

Bước 3 Trình bày kiến trúc Nhà kiến trúc sẽ mô tả kiến trúc được đề xuất, tập

Step 4: Xác định các

tiếp cận kiến trúc architectural approaches

Step 1-3: Trình diễn ATAM,

business drivers & architecture

Step 5: Sinh ra cây tiện ích của

& Trade-off points

Tóm tắt nội dung và kết quả

các bước 1-6

Hiểu rõ các kết quả

từ pha I,II

Các scenario và mức ưu tiên tương ứng

Risks, Sensitivities points

& Trade-off points

trung vào khả năng giải quyết các business drivers của kiến trúc đó

Pha II: Nghiên cứu và phân tích

Bước 4 Xác định các tiếp cận kiến trúc Các tiếp cận kiến trúc được xác định

bởi các nhà kiến trúc, tuy các tiếp cận này chưa được phân tích

Bước 5 Sinh ra cây tiện ích thuộc tính chất lượng Các yếu tố chất lượng tạo

nên sự ―tiện ích‖ của hệ thống (như hiệu năng, tính sẵn sàng, tính bảo mật, tính sửa đổi…) được đưa ra và được mô tả tới mức scenario, các scenario này được thể hiện bởi các tác nhân, đáp ứng và được phân mức ưu tiên

Bước 6 Phân tích các tiếp cận kiến trúc Dựa trên các yếu tố có độ ưu tiên cao ở

bước 5, các tiếp cận kiến trúc có khả năng đáp ứng được các yếu tố này sẽ được lựa chọn và phân tích (Ví dụ, một tiếp cận kiến trúc đáp ứng được mục tiêu về hiệu năng sẽ được đưa ra khi phân tích hiệu năng) Trong bước này, các rủi ro, các điểm nhạy cảm và điểm cân bằng sẽ được xác định

Pha III: Kiểm tra (Testing)

Bước 7 Phân độ ưu tiên cho mỗi scenario Dựa vào các scenario được tạo ra

trong cây tiện ích, một tập các scenario sẽ được lựa chọn bởi toàn bộ những người tham gia Tập scenario này được phân mức độ ưu tiên thông qua tiến trình bỏ phiếu

Bước 8 Phân tích các tiếp cận kiến trúc Bước này lặp lại bước 6 Tuy nhiên,

các scenario có thứ hạng cao (mức ưu tiên lớn) ở bước 7 sẽ được sử dụng làm các test case cho việc phân tích các tiếp cận kiến trúc Các scenario này có thể sẽ giúp phát hiện thêm các tiếp cận kiến trúc, các rủi ro, điểm nhạy cảm, điểm cân bằng để làm cơ sở ghi vào tài liệu về sau

Pha IV: Báo cáo (Reporting)

Bước 9 Trình bày kết quả Dựa vào thông tin thu được từ phiên đánh giá ATAM

(phong cách kiến trúc, scenario, các câu hỏi thuộc tính, cây tiện ích, rủi ro, điểm nhạy cảm, điểm cân bằng) nhóm ATAM trình bày kết quả đó cho những người tham gia và viết báo cáo chi tiết cho mỗi kiến trúc được đề xuất

2.4.2 Mô tả thuộc tính chất lượng

Việc đánh giá yêu cầu đối với các thuộc tính chất lượng của một thiết kế kiến trúc rất cần mô tả chính xác các thuộc tính có liên quan đến chất lượng Chẳng hạn, để hiểu được kiến trúc về tính sửa đổi đòi hỏi phải hiểu rõ phương pháp đo lường hay quan sát tính sửa đổi cũng như các loại quyết định kiến trúc ảnh hưởng đến sự đo lường đó

Để thuận tiện, người ta chia các thuộc tính chất lượng thành các nhóm khác nhau, bao gồm: Hiệu năng (Performance), Tính sửa đổi (Modifiability), tính sẵn sàng (Availability), tính tiện dụng (Usability), tính bảo mật (Security)…

Việc mô tả các thuộc tính này được xem như là điểm khởi đầu và có thể được bổ sung thêm trong quá trình xây dựng ATAM

Mỗi mô tả ở trên được chia làm 3 nhóm: Tác nhân ngoài (External stimuli), các quyết định kiến trúc (architectural decisions/Parameters) và các đáp ứng

(Responses) Tác nhân ngoài (hay nói gọn lại là tác nhân) là các sự kiện khiến

cho kiến trúc phải đáp ứng hoặc phải thay đổi Để phân tích xem một kiến trúc có gắn với các yêu cầu chất lượng hay không thì các yêu cầu đó cần phải được mô tả bởi các thuật ngữ cụ thể và có thể đo lường hay quan sát được Các con số đo lường hay quan sát này sẽ được mô tả trong phần đáp ứng khi mô tả thuộc tính

Các quyết định kiến trúc là những thành phần cấu tạo nên kiến trúc (bao gồm các

thành phần, kết nối và các thuộc tính), nó ảnh hưởng trực tiếp đến việc có đạt được các yêu cầu thuộc tính hay không

Cấu trúc tổng quát mô tả thuộc tính chất lượng như sau:

Ví dụ về tác nhân ngoài đối với hiệu năng là các sự kiện như Thông báo, ngắt hay

sự nhấn phím của người dùng…các quyết định kiến trúc về hiệu năng bao gồm bộ

xử lý, cơ chế phân chia mạng; các cấu trúc song song gồm các bộ xử lý, các tiến trình, các luồng; các thuộc tính bao gồm độ ưu tiên của tiến trình và thời gian thực

thi Các đáp ứng được mô tả bởi những con số có thể đo lường được như độ trễ

hay thông lượng

Đối với khả năng sửa đổi, tác nhân ngoài là các yêu cầu thay đổi đối với phần mềm của hệ thống Các quyết định kiến trúc bao gồm sự đóng gói và các cơ chế gián tiếp, các đáp ứng được đo bởi số thành phần, số kết nối, số giao diện bị ảnh hưởng và công sức phải bỏ ra để thay đổi các thành phần bị ảnh hưởng này

Dưới đây là một số ví dụ về mô tả thuộc tính chất lượng:

Hình 6 – Mô tả thuộc tính chất lượng – Performance Stimuli

Hình 7 – Mô tả thuộc tính chất lượng – Performance Response

Hình 8 - Mô tả thuộc tính chất lượng – Performance Parameters

Hình 9 - Mô tả thuộc tính chất lượng – Modifiability Param

Hình 10 - Mô tả thuộc tính chất lượng – Modifiability Availability

Mục tiêu mô tả thuộc tính không phải nhằm mục đích phân chia hết từng loại mà

là để đưa ra một bộ khung (framework) cho mọi người cùng thống nhất cách suy nghĩ về các thuộc tính chất lượng

Để hiểu rõ hơn về các thuộc tính chất lượng, thường trong phiên đánh giá ATAM những người tham gia sẽ đặt các câu hỏi và mỗi câu hỏi này sẽ liên quan đến một ngữ cảnh cụ thể của thuộc tính chất lượng Ví dụ, với một tình huống (scenario)