Cụng cụ hỗ trợ ALMA

Một phần của tài liệu 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 (Trang 29)

3. Cấu trỳc và nội dung của luận văn

2.2.8. Cụng cụ hỗ trợ ALMA

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

2.2.9. Cỏc phƣơng phỏp thay thế cho ALMA.

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

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

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

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

b. Đỏnh giỏ scenario dựa vào việc phõn tớch sự ảnh hưởng của chỳng. Cụng việc này bao gồm việc xỏc định cỏc thành phần bị ảnh hưởng và chỉ ra được sự tỏc động lờn cỏc thành phần đú.

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

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

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

f. Cung cấp cỏc kỹ thuật thực hiện cỏc bước, cú tớnh lặp lại được. Đầu ra của phương phỏp này bao gồm:

a. Kết quả ước lượng sự ảnh hưởng của mỗi scenario. kết quả này được mụ tả bằng (1) kớch thước của cỏc thành phần hiện tại cần sửa đổi hoặc (2) kớch thước của cỏc thành phần được ước lượng cần phải được xem xột.

b. Một mụ hỡnh dự bỏo tớnh sửa đổi dựa trờn khối lượng thay đổi được ước lượng.

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

c. Một tiờu chuẩn dừng việc sinh ra scenario (1) nếu tất cả cỏc loại scenario đó được xem xột tường minh hoặc (2) việc sinh ra cỏc change scenarios mới khụng ảnh hưởng đến cấu trỳc phõn loại.

2.2.11. Một số lƣu ý về ALMA.

Nhỡn chung, phương phỏp này thiếu cỏc phương tiện để quyết định về độ chớnh xỏc của cỏc kết quả phõn tớch. ALMA khụng thể tớnh chớnh xỏc cỏc con số dự bỏo về bảo trỡ cũng như khụng thể xỏc định được tớnh đầy đủ của việc đỏnh giỏ rủi ro.

2.3. Phương phỏp đỏnh giỏ kiến trỳc FAAM (Family-Architecture Assessment Method)

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

FAAM là một phương phỏp đỏnh giỏ kiến trỳc của cỏc dũng hệ thống thụng tin, tập trung vào 2 khớa cạnh liờn quan đến chất lượng: tớnh liờn tỏc và tớnh mở rộng (interoperability and extensibility).

2.3.2. Mục tiờu của FAAM

Mục tiờu của FAAM là thiết lập một qui trỡnh đỏnh giỏ cỏc kiến trỳc thuộc dũng hệ thống thụng tin. Điểm khỏc của FAAM so với cỏc phương phỏp trước đõy là FAAM gúp phần:

 Những người liờn quan thuộc họ sản phẩm tham gia chủ động vào quỏ trỡnh

tạo ra sản phẩm,

 Tập trung vào cỏc thuộc tớnh chất lượng là tớnh liờn tỏc và tớnh mở rộng của

cỏc dũng hệ thống thụng tin,

 Nhấn mạnh đến cỏc kỹ thuật và tri thức thực tế nhằm cho phộp cỏc nhúm

phỏt triển trong tổ chức cài đặt phương phỏp này.

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

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

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

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

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

 Sự cần thiết phải cú cỏc kỹ thuật cú thể tạo ra cỏc cơ sở về kiến trỳc cho

những người tham gia.

 Cần khả năng suy đoỏn về tớnh liờn tỏc và tớnh mở rộng của dũng hệ thống

này sớm trong cỏc phase phõn tớch và xõy dựng kiến trỳc.

2.3.4. Cỏc yờu cầu và đầu vào của FAAM

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

 Những người được mời tham gia phải cú kinh nghiệm với cỏc kỹ thuật liờn

quan nhằm thiết lập lờn cỏc yờu cầu và mục tiờu khởi đầu cho phiờn đỏnh giỏ.

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

FAAM.

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

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

 Cỏc mẫu Change-case đặc tả cỏc thay đổi cú thể xảy ra đối với tớnh liờn tỏc

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

 Cỏc mẫu hoặc cỏc kỹ thuật sinh bảng ỏnh xạ đặc tớnh, cỏc biểu đồ và tiờu

chuẩn phõn hạng cỏc yờu cầu. Cỏc qui tắc cũng cú thể được sử dụng để hỗ trợ quỏ trỡnh sinh ra cỏc change-case. Việc mụ tả kiến trỳc dựa trờn cỏc khung nhỡn của ―mụ hỡnh 4+1‖, nhưng thường thỡ tập trung vào sự logic, qui trỡnh, và cỏc khung nhỡn.

2.3.5. Cỏc bƣớc trong một phiờn đỏnh giỏ FAAM.

FAAM được mụ tả bởi 6 bước theo thứ tự về thời gian. Tuy nhiờn, điểm cần lưu ý đú là cỏc bước của phiờn đỏnh giỏ FAAM phải thớch ứng với kinh nghiệm đỏnh giỏ kiến trỳc núi chung của tổ chức đú.

FAAM Bước 1 – Xỏc định mục tiờu đỏnh giỏ.

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

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

 Xõy dựng kế hoạch tương lai cho cỏc thay đổi về tớnh liờn tỏc và tớnh mở

rộng;

 Cung cấp cỏc nguyờn tắc cho người tham gia để trợ giỳp họ đưa ra cỏc yờu

cầu;

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

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

Tại bước này, những người liờn quan cần xỏc định và phõn mức ưu tiờn cỏc yờu cầu về chất lượng hệ thống. Thỏch thức ở đõy là vấn đề cung cấp phương tiện cho người tham gia thực hiện trỡnh diễn cỏc yờu cầu ở dạng cú cấu trỳc để cú thể làm cơ sở cho việc đỏnh giỏ về sau.

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

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

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

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

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

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

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

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

2.3.6. Cỏc đối tƣợng tham gia phiờn đỏnh giỏ FAAM

Như phương phỏp đó được mụ tả ở bước trước, FAAM cú một số vai trũ tham gia tớch cực, bao gồm:

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

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

b. Internal stakeholders: là những người liờn quan trực tiếp tới quỏ trỡnh đỏnh giỏ kiến trỳc phần mềm . Họ cú vai trũ phõn tớch, định nghĩa và trỡnh diễn cỏc khỏi niệm và khung nhỡn kiến trỳc trong phiờn đỏnh giỏ FAAM. Vớ dụ về những internal stakeholders, đú là nhà kiến trỳc hay nhúm kiến trỳc.

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

2.3.7. Ƣớc lƣợng chi phớ khi ỏp dụng FAAM.

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

2.3.8. Cụng cụ hỗ trợ FAAM.

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

2.3.9. Cỏc thay thế cho FAAM

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

2.3.10. Cỏc ƣu điểm và đầu ra của FAAM.

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

 Phương phỏp này cung cấp phương thức giỳp cho nhúm phỏt triển cú khả

năng tự đỏnh giỏ, coi đú như là phương tiện để liờn tục cải tiến.

 Qui trỡnh đỏnh giỏ nhỡn chung là thớch hợp cho lĩnh vực thuộc dũng hệ thống thụng tin.

 Qui trỡnh FAAM được mụ tả rừ ràng. Điều này rất hữu ớch trong việc hỗ trợ

những người tham gia cú kỹ thuật thực tế để tạo ra cỏc phương tiện cần thiết phục vụ đỏnh giỏ tớnh liờn tỏc và tớnh mở rộng.

 FAAM được xõy dựng dựa trờn cỏc phương phỏp đỏnh giỏ kiểu như SAAM

và ATAM, vỡ vậy nú thừa kế cỏc ưu điểm của cỏc phương phỏp này.

2.4. Phương phỏp phõn tớch cõn bằng kiến trỳc-ATAM (Architecture Tradeoff Analysis Method)

2.4.1 Giới thiệu phƣơng phỏp

ATAM là một phương phỏp phõn tớch kiến trỳc phần mềm với mục tiờu nhằm hỗ trợ sự hài hũa (cõn bằng) trong thiết kế. Sau này nú được xem như là một mụ hỡnh dựng cho phõn tớch kiến trỳc phần mềm.

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

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

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

tài liệu húa dưới nhiều khung nhỡn khỏc nhau.

ATAM khụng yờu cầu phải cú cỏc kỹ thuật đặc biệt khi đỏnh giỏ mà chỉ sử dụng cỏc mụ hỡnh cú tớnh chất lý thuyết khi phõn tớch và ỏp dụng cỏc kỹ thuật heuristics để suy diễn chất lượng theo cỏc thuật ngữ của phong cỏch kiến trỳc dựa trờn thuộc tớnh (ABSA), cỏc mẫu kiến trỳc hay cỏc scenario cú liờn quan đến chất lượng. ATAM được xem như là một cỏch tiếp cận hoàn thiện vỡ đó được kiểm chứng trong rất nhiều lĩnh vực khỏc nhau. Hiện nay cụng cụ hỗ trợ cho ATAM là ArchE đang được phỏt triển[33].

Dưới đõy là hỡnh mụ tả mụ hỡnh của phương phỏp ATAM và cỏc bước thực hiện một phiờn đỏnh giỏ ATAM:

Hỡnh 5 - Mụ hỡnh tiến trỡnh của ATAM

Pha I : Pha trỡnh diễn

Bƣớc 1. Trỡnh bày phƣơng phỏp ATAM. Phương phỏp này được mụ tả lại cho những người tham gia (thường là đại diện khỏch hàng, kiến trỳc sư phần mềm, nhúm kiến trỳc, nhà bảo trỡ, nhà quản trị, nhà quản lý, kiểm thử viờn, nhà tớch hợp…). việc mụ tả lại là để mọi người biết rừ về ATAM và qui trỡnh đỏnh giỏ sử dụng ATAM.

Bƣớc 2. Trỡnh bày cỏc business drivers. Người quản lý dự ỏn sẽ mụ tả cỏc mục tiờu doanh nghiệp cần hướng tới, vỡ vậy cũng cho biết cỏc architectural drivers là gỡ (vớ dụ độ sẵn sàng cao, thời gian phỏt hành sản phẩm nhanh, bảo mật…).

Bƣớc 3. Trỡnh bày kiến trỳc. Nhà kiến trỳc sẽ mụ tả kiến trỳc được đề xuất, tập

Step 4: Xỏc định cỏc tiếp cận kiến trỳc architectural approaches

Step 1-3: Trỡnh diễn ATAM, business drivers & architecture

Step 5: Sinh ra cõy tiện ớch của thuộc tớnh chất lượng

Step 6: Phõn tớch cỏc tiếp cận kiến trỳc

Step 7: Phõn mức ưu tiờn cỏc scenario Step 8: Phõn tớch cỏc scenarios Step 9: Trỡnh diễn kết quả Cỏc Business drivers & SA Cỏc tiếp cận kiến trỳc Cỏc thuộc tớnh chất lượng &scenario kốm mức ưu tiờn

Sensitivities points & Trade-off points

Túm tắt nội dung và kết quả cỏc bước 1-6

Hiểu rừ cỏc kết quả từ pha I,II

Cỏc scenario và mức ưu tiờn tương ứng.

Risks, Sensitivities points & Trade-off points

AT AM p h a I ,I I AT AM p h a II I , IV

Một phần của tài liệu 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 (Trang 29)

Tải bản đầy đủ (PDF)

(80 trang)