lantrank_vn
New Member
Luận văn: 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 ThS. Công nghệ thông tin
Nhà xuất bản: ĐHCN
Ngày: 2008
Chủ đề: Công nghệ phần mềm
Kiến trúc phần mềm
Phần mềm
Miêu tả: 79 tr. + CD-ROM
Tổng quan về phương pháp đánh giá kiến trúc phần mềm - Software Evaluation. Trình bày một số phương pháp đánh giá kiến trúc phần mềm dựa trên Scenario: phương pháp phân tích kiến trúc phần mềm - SAAM, phương pháp ALMA, phương pháp đánh giá kiến trúc FAAM, phương pháp phân tích cân bằng kiến trúc - ATAM, phương pháp đánh giá kiến trúc phần mềm CBAM. Nêu hướng tiếp cận tích hợp ATAM và CBAM, cải tiến ATAM và CBAM; từ đó đề xuất qui trình đánh giá. Mô tả dự án Vanco-NetDirect và các Business drivers, vận dụng ATAM-CBAM đánh giá kiến trúc
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công nghệ. Đại học Quốc gia Hà Nội, 2008
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 đá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 đá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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 hay 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 hay 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.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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â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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 đá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 hay 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 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 hay 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 đượ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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 hay 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 đá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 hay 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 hay 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ể
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 đạ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 (
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 ?
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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).
KẾT LUẬN
Đánh giá kiến trúc phần mềm luôn là một khâu vô cùng quan trọng vì nó ảnh
hưởng đến toàn bộ các công đoạn phát triển còn lại. Chất lượng của phần mềm
thường do chính kiến trúc của hệ thống phần mềm đó qui định chứ không phải do
thuật toán mà nhiều người vẫn tưởng.
Đối với các dự án lớn thì việc phân tích và tìm ra các giải pháp kiến trúc phù hợp
là điều bắt buộc. Tuy nhiên, đặc thù của phân tích kiến trúc đó là được thực hiện
sớm, trước cả giai đoạn thiết kế vì, vậy rất khó để có thể định lượng được. Hơn
nữa, vì ở giai đoạn đầu nên thông tin thường là không có cấu trúc do vậy nếu
không có một phương pháp phân tích có cấu trúc nào đó thì công sức bỏ ra sẽ rất
lớn.
Nhìn nhận thấy tầm quan trọng đặc biệt của kiến trúc đối với chất lượng của hệ
thống phần mềm cũng như mong muốn tìm ra một phương pháp có cấu trúc trong
phân tích, rất nhiều các phương pháp phân tích kiến trúc đã ra đời, trong đó kiến
trúc dựa trên scenario trên thực tế đã chứng tỏ rất hiệu quả. Và chính những
phương pháp này cũng đã áp dụng thành công cho nhiều dự án trên thực tế, ví dụ
dự án ―NASA ECS‖ của Mỹ, dự án BCS, Avionics Systems, ….
Trong số các phương pháp phân tích kiến trúc phần mềm dựa trên scenario, có thể
kể ra một số phương pháp như: SAAM, FAAM, ALMA, ATAM, CBAM. Đặc biệt
ATAM và CBAM đang được quan tâm đặc biệt bởi nó có khả năng phân tích
nhiều thuộc tính phần mềm hơn so với các phương pháp khác, riêng CBAM thì có
điểm mạnh vượt trội là có thể phân tích được cả về khía cạnh kinh tế và lợi ích.
Nhận thức được tầm quan trọng của kiến trúc phần mềm trong phát triển hệ thống,
hơn nữa lĩnh vực nghiên cứu này cũng đang còn khá mới mẻ tại Việt Nam, do vậy
mà em đã chọn đề tài tìm hiểu phương pháp phân tích kiến trúc phần mềm ATAM
và CBAM làm luận văn tốt nghiệp của mình, dưới sự dẫn dắt và định hướng của
thầy giáo PGS.TS Huỳnh Quyết Thắng. Mục tiêu sau khi nghiên cứu về các
phương pháp này, em đã cố gắng áp dụng nó vào dự án thực tế mà em tham gia tại
công ty cổ phần phần mềm FPT Software.
Bước đầu áp dụng cũng đã thu lượm được một số kết quả đáng kể, ghóp phần
nâng cao chất lượng của dự án phần mềm Vanco-NetDirect. Tuy nhiên, vì nhiều lý
do và điều kiện khách quan khác nhau và trình độ có hạn của bản thân mà toàn bộ
qui trình của phân tích của phương pháp không được thử nghiệm và áp dụng triệt
để, do vậy còn nhiều hạn chế cần khắc phục.
Mặc dù kết quả nghiên cứu chưa thực sự được như ý muốn, nhưng có thể kết luận
rằng việc đi sâu nghiên cứu và tìm hiểu về đánh giá kiến trúc phần mềm sẽ đem lại
những kết quả to lớn, đem lại lợi ích tối đa đồng thời làm giảm thiểu đáng kể
những rủi ro có thể đoán được cho doanh nghiệp.
Lời cuối cùng, em xin được gửi lời Thank chân thành tới các Thầy cô và bè bạn
đã đọc bản luận văn này và mong Thầy cô cho những ý kiến đóng góp để em hoàn
thiện luận văn được tốt hơn !.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
Nhà xuất bản: ĐHCN
Ngày: 2008
Chủ đề: Công nghệ phần mềm
Kiến trúc phần mềm
Phần mềm
Miêu tả: 79 tr. + CD-ROM
Tổng quan về phương pháp đánh giá kiến trúc phần mềm - Software Evaluation. Trình bày một số phương pháp đánh giá kiến trúc phần mềm dựa trên Scenario: phương pháp phân tích kiến trúc phần mềm - SAAM, phương pháp ALMA, phương pháp đánh giá kiến trúc FAAM, phương pháp phân tích cân bằng kiến trúc - ATAM, phương pháp đánh giá kiến trúc phần mềm CBAM. Nêu hướng tiếp cận tích hợp ATAM và CBAM, cải tiến ATAM và CBAM; từ đó đề xuất qui trình đánh giá. Mô tả dự án Vanco-NetDirect và các Business drivers, vận dụng ATAM-CBAM đánh giá kiến trúc
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công nghệ. Đại học Quốc gia Hà Nội, 2008
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 đá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 đá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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 hay 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 hay 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.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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â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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 đá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 hay 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 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 hay 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 đượ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
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 hay 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 đá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 hay 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 hay 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ể
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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 đạ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 (
You must be registered for see links
) sử dụng. Các phong cách và mẫuthườ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 ?
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-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).
KẾT LUẬN
Đánh giá kiến trúc phần mềm luôn là một khâu vô cùng quan trọng vì nó ảnh
hưởng đến toàn bộ các công đoạn phát triển còn lại. Chất lượng của phần mềm
thường do chính kiến trúc của hệ thống phần mềm đó qui định chứ không phải do
thuật toán mà nhiều người vẫn tưởng.
Đối với các dự án lớn thì việc phân tích và tìm ra các giải pháp kiến trúc phù hợp
là điều bắt buộc. Tuy nhiên, đặc thù của phân tích kiến trúc đó là được thực hiện
sớm, trước cả giai đoạn thiết kế vì, vậy rất khó để có thể định lượng được. Hơn
nữa, vì ở giai đoạn đầu nên thông tin thường là không có cấu trúc do vậy nếu
không có một phương pháp phân tích có cấu trúc nào đó thì công sức bỏ ra sẽ rất
lớn.
Nhìn nhận thấy tầm quan trọng đặc biệt của kiến trúc đối với chất lượng của hệ
thống phần mềm cũng như mong muốn tìm ra một phương pháp có cấu trúc trong
phân tích, rất nhiều các phương pháp phân tích kiến trúc đã ra đời, trong đó kiến
trúc dựa trên scenario trên thực tế đã chứng tỏ rất hiệu quả. Và chính những
phương pháp này cũng đã áp dụng thành công cho nhiều dự án trên thực tế, ví dụ
dự án ―NASA ECS‖ của Mỹ, dự án BCS, Avionics Systems, ….
Trong số các phương pháp phân tích kiến trúc phần mềm dựa trên scenario, có thể
kể ra một số phương pháp như: SAAM, FAAM, ALMA, ATAM, CBAM. Đặc biệt
ATAM và CBAM đang được quan tâm đặc biệt bởi nó có khả năng phân tích
nhiều thuộc tính phần mềm hơn so với các phương pháp khác, riêng CBAM thì có
điểm mạnh vượt trội là có thể phân tích được cả về khía cạnh kinh tế và lợi ích.
Nhận thức được tầm quan trọng của kiến trúc phần mềm trong phát triển hệ thống,
hơn nữa lĩnh vực nghiên cứu này cũng đang còn khá mới mẻ tại Việt Nam, do vậy
mà em đã chọn đề tài tìm hiểu phương pháp phân tích kiến trúc phần mềm ATAM
và CBAM làm luận văn tốt nghiệp của mình, dưới sự dẫn dắt và định hướng của
thầy giáo PGS.TS Huỳnh Quyết Thắng. Mục tiêu sau khi nghiên cứu về các
phương pháp này, em đã cố gắng áp dụng nó vào dự án thực tế mà em tham gia tại
công ty cổ phần phần mềm FPT Software.
Bước đầu áp dụng cũng đã thu lượm được một số kết quả đáng kể, ghóp phần
nâng cao chất lượng của dự án phần mềm Vanco-NetDirect. Tuy nhiên, vì nhiều lý
do và điều kiện khách quan khác nhau và trình độ có hạn của bản thân mà toàn bộ
qui trình của phân tích của phương pháp không được thử nghiệm và áp dụng triệt
để, do vậy còn nhiều hạn chế cần khắc phục.
Mặc dù kết quả nghiên cứu chưa thực sự được như ý muốn, nhưng có thể kết luận
rằng việc đi sâu nghiên cứu và tìm hiểu về đánh giá kiến trúc phần mềm sẽ đem lại
những kết quả to lớn, đem lại lợi ích tối đa đồng thời làm giảm thiểu đáng kể
những rủi ro có thể đoán được cho doanh nghiệp.
Lời cuối cùng, em xin được gửi lời Thank chân thành tới các Thầy cô và bè bạn
đã đọc bản luận văn này và mong Thầy cô cho những ý kiến đóng góp để em hoàn
thiện luận văn được tốt hơn !.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
You must be registered for see links
Last edited by a moderator: