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