3. Cấu trỳc và nội dung của luận văn
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
trung vào khả năng giải quyết cỏc business drivers của kiến trỳc đú.
Pha II: Nghiờn cứu và phõn tớch
Bƣớc 4. Xỏc định cỏc tiếp cận kiến trỳc. Cỏc tiếp cận kiến trỳc được xỏc định bởi cỏc nhà kiến trỳc, tuy cỏc tiếp cận này chưa được phõn tớch.
Bƣớc 5. Sinh ra cõy tiện ớch thuộc tớnh chất lƣợng. Cỏc yếu tố chất lượng tạo nờn sự ―tiện ớch‖ của hệ thống (như hiệu năng, tớnh sẵn sàng, tớnh bảo mật, tớnh sửa đổi…) được đưa ra và được mụ tả tới mức scenario, cỏc scenario này được thể hiện bởi cỏc tỏc nhõn, đỏp ứng và được phõn mức ưu tiờn.
Bƣớc 6. Phõn tớch cỏc tiếp cận kiến trỳc. Dựa trờn cỏc yếu tố cú độ ưu tiờn cao ở bước 5, cỏc tiếp cận kiến trỳc cú khả năng đỏp ứng được cỏc yếu tố này sẽ được lựa chọn và phõn tớch (Vớ dụ, một tiếp cận kiến trỳc đỏp ứng được mục tiờu về hiệu năng sẽ được đưa ra khi phõn tớch hiệu năng). Trong bước này, cỏc rủi ro, cỏc điểm nhạy cảm và điểm cõn bằng sẽ được xỏc định.
Pha III: Kiểm tra (Testing)
Bƣớc 7. Phõn độ ƣu tiờn cho mỗi scenario. Dựa vào cỏc scenario được tạo ra trong cõy tiện ớch, một tập cỏc scenario sẽ được lựa chọn bởi toàn bộ những người tham gia. Tập scenario này được phõn mức độ ưu tiờn thụng qua tiến trỡnh bỏ phiếu.
Bƣớc 8. Phõn tớch cỏc tiếp cận kiến trỳc. Bước này lặp lại bước 6. Tuy nhiờn, cỏc scenario cú thứ hạng cao (mức ưu tiờn lớn) ở bước 7 sẽ được sử dụng làm cỏc test case cho việc phõn tớch cỏc tiếp cận kiến trỳc. Cỏc scenario này cú thể sẽ giỳp phỏt hiện thờm cỏc tiếp cận kiến trỳc, cỏc rủi ro, điểm nhạy cảm, điểm cõn bằng để làm cơ sở ghi vào tài liệu về sau.
Pha IV: Bỏo cỏo (Reporting)
Bƣớc 9. Trỡnh bày kết quả. Dựa vào thụng tin thu được từ phiờn đỏnh giỏ ATAM (phong cỏch kiến trỳc, scenario, cỏc cõu hỏi thuộc tớnh, cõy tiện ớch, rủi ro, điểm nhạy cảm, điểm cõn bằng) nhúm ATAM trỡnh bày kết quả đú cho những người tham gia và viết bỏo cỏo chi tiết cho mỗi kiến trỳc được đề xuất.
2.4.2 Mụ tả thuộc tớnh chất lƣợng
Việc đỏnh giỏ yờu cầu đối với cỏc thuộc tớnh chất lượng của một thiết kế kiến trỳc rất cần mụ tả chớnh xỏc cỏc thuộc tớnh cú liờn quan đến chất lượng. Chẳng hạn, để hiểu được kiến trỳc về tớnh sửa đổi đũi hỏi phải hiểu rừ phương phỏp đo lường hay quan sỏt tớnh sửa đổi cũng như cỏc loại quyết định kiến trỳc ảnh hưởng đến sự đo lường đú.
Để thuận tiện, người ta chia cỏc thuộc tớnh chất lượng thành cỏc nhúm khỏc nhau, bao gồm: Hiệu năng (Performance), Tớnh sửa đổi (Modifiability), tớnh sẵn sàng (Availability), tớnh tiện dụng (Usability), tớnh bảo mật (Security)…
Việc mụ tả cỏc thuộc tớnh này được xem như là điểm khởi đầu và cú thể được bổ sung thờm trong quỏ trỡnh xõy dựng ATAM.
Mỗi mụ tả ở trờn được chia làm 3 nhúm: Tỏc nhõn ngoài (External stimuli), cỏc quyết định kiến trỳc (architectural decisions/Parameters) và cỏc đỏp ứng
(Responses). Tỏc nhõn ngoài (hay núi gọn lại là tỏc nhõn) là cỏc sự kiện khiến
cho kiến trỳc phải đỏp ứng hoặc phải thay đổi. Để phõn tớch xem một kiến trỳc cú gắn với cỏc yờu cầu chất lượng hay khụng thỡ cỏc yờu cầu đú cần phải được mụ tả bởi cỏc thuật ngữ cụ thể và cú thể đo lường hay quan sỏt được. Cỏc con số đo lường hay quan sỏt này sẽ được mụ tả trong phần đỏp ứng khi mụ tả thuộc tớnh.
Cỏc quyết định kiến trỳc là những thành phần cấu tạo nờn kiến trỳc (bao gồm cỏc
thành phần, kết nối và cỏc thuộc tớnh), nú ảnh hưởng trực tiếp đến việc cú đạt được cỏc yờu cầu thuộc tớnh hay khụng.
Cấu trỳc tổng quỏt mụ tả thuộc tớnh chất lượng như sau:
Vớ dụ về tỏc nhõn ngoài đối với hiệu năng là cỏc sự kiện như Thụng bỏo, ngắt hay sự nhấn phớm của người dựng…cỏc quyết định kiến trỳc về hiệu năng bao gồm bộ xử lý, cơ chế phõn chia mạng; cỏc cấu trỳc song song gồm cỏc bộ xử lý, cỏc tiến trỡnh, cỏc luồng; cỏc thuộc tớnh bao gồm độ ưu tiờn của tiến trỡnh và thời gian thực
thi. Cỏc đỏp ứng được mụ tả bởi những con số cú thể đo lường được như độ trễ
hay thụng lượng.
Đối với khả năng sửa đổi, tỏc nhõn ngoài là cỏc yờu cầu thay đổi đối với phần mềm của hệ thống. Cỏc quyết định kiến trỳc bao gồm sự đúng gúi và cỏc cơ chế giỏn tiếp, cỏc đỏp ứng được đo bởi số thành phần, số kết nối, số giao diện bị ảnh hưởng và cụng sức phải bỏ ra để thay đổi cỏc thành phần bị ảnh hưởng này.
Dưới đõy là một số vớ dụ về mụ tả thuộc tớnh chất lượng:
Hỡnh 7 – Mụ tả thuộc tớnh chất lượng – Performance Response
Hỡnh 9 - Mụ tả thuộc tớnh chất lượng – Modifiability Param
Hỡnh 10 - Mụ tả thuộc tớnh chất lượng – Modifiability Availability
Mục tiờu mụ tả thuộc tớnh khụng phải nhằm mục đớch phõn chia hết từng loại mà là để đưa ra một bộ khung (framework) cho mọi người cựng thống nhất cỏch suy nghĩ về cỏc thuộc tớnh chất lượng.
Để hiểu rừ hơn về cỏc thuộc tớnh chất lượng, thường trong phiờn đỏnh giỏ ATAM những người tham gia sẽ đặt cỏc cõu hỏi và mỗi cõu hỏi này sẽ liờn quan đến một ngữ cảnh cụ thể của thuộc tớnh chất lượng. Vớ dụ, với một tỡnh huống (scenario)
cho trước là ―Mở khúa tất cả cỏc cửa của xe trong khoảng một giõy khi nhấn chuỗi phớm hợp lệ‖ thỡ mụ tả hiệu năng sẽ phỏt sinh cỏc cõu hỏi kiểu như:
Hạn định 1 giõy cú phải là hạn định cứng khụng (đỏp ứng)?
Chuỗi phớm khụng đỳng với yờu cầu một giõy là gỡ (đỏp ứng)?
Cỏc thành phần liờn quan đến đỏp ứng sự kiện mở cửa đú là gỡ (quyết định
kiến trỳc)?
Thời gian thực thi của cỏc thành phần này là gỡ (quyết định kiến trỳc)?
Cỏc thành phần cú nằm trong cựng một bộ xử lý hay khỏc (cỏc quyết định
kiến trỳc)?
Điều gỡ xảy ra nếu như cú nhiều sự kiện ―mở khúa cửa‖ xuất hiện đồng thời (tỏc nhõn)?
Dưới đõy là một số vớ dụ thờm về những cõu hỏi liờn quan đến thuộc tớnh chất lượng:
Cõu hỏi liờn quan đến hiệu năng:
Cỏc server hỗ trợ đơn tuyến hay đa tuyến?
Độ ưu tiờn được gỏn như thế nào cho cỏc tiến trỡnh?
Cỏc tiến trỡnh được cấp phỏt phần cứng như thế nào ?
Vị trớ vật lý cũng như kết nối của phần cứng là gỡ?
Đặc điểm băng thụng của mạng là gỡ?
Việc sắp đặt và ưu tiờn trong mạng như thế nào?
Sử dụng giao thức đồng bộ hay khụng đồng bộ?
Ảnh hưởng của cỏc giao thức unicast hay multicast là gỡ?
Vị trớ của firewall và tỏc động của nú đến hiệu năng?
Thụng tin được cached với thụng tin được tạo lại là gỡ? Dựa trờn nguyờn tắc
nào?
Ảnh hưởng tới hiệu năng của mụ hỡnh thin client và thick client?
Cỏc tài nguyờn cấp phỏt cho cỏc yờu cầu dịch vụ như thế nào?
Cỏc mụ tả tải client như thế nào (vớ dụ: cú bao nhiờu phiờn tồn tại đồng thời, cú bao nhiờu người dựng)?
Đặc điểm về hiệu năng của cỏc thành phần trung gian (middleware) là gỡ:
cõn bằng tải, giỏm sỏt, cấu hỡnh lại dịch vụ.
Cỏc cõu hỏi liờn quan đến tớnh sửa đổi:
Nếu kiến trỳc này bao gồm cỏc tầng (Layers) thỡ liệu cú tầng nào đú bị phỏ
vỡ khụng?
Nếu kiến trỳc bao gồm một kho chứa dữ liệu thỡ cú bao nhiờu chỗ khỏc nhau trong kiến trỳc biết rừ cỏc kiểu dữ liệu của chỳng?
Nếu cú một kiểu dữ liệu dựng chung thỡ cú bao nhiờu phần trong kiến trỳc
bị ảnh hưởng khi kiểu dữ liệu đú thay đổi?
Nếu cơ chế dự phũng được sử dụng trong kiến trỳc thỡ kiểu dự phũng đú là gỡ và sự lựa chọn là như thế nào? Cỏc trục trặc được xỏc định ra sao?
Cú thể xỏc định cỏc trục trặc đú một cỏch chủ động hay khụng?
Nếu cơ chế dự phũng được sử dụng thỡ cần phải mất bao lõu để chuyển đổi
giữa cỏc thành phần dự phũng đú?
2.4.3 Scenario.
Trong một số dự ỏn lý tưởng thỡ cỏc yờu cầu chất lượng đều được đặc tả kỹ lưỡng trong tài liệu SRS, tuy nhiờn thực tế cho thấy cỏc yờu cầu này thường khụng đầy đủ, mơ hồ hoặc khụng xỏc định. Trong khi đú, điều cần nhất đối với nhà phõn tớch kiến trỳc là phải chọn lọc được chớnh xỏc cỏc mục tiờu chất lượng đối với mỗi kiến trỳc được đưa ra. Cơ chế mà chỳng ta sử dụng để lựa chọn ở đõy chớnh là
scenario.
Scenario là một phỏt biểu ngắn gọn, mụ tả sự tương tỏc của người dựng đối với hệ thống. scenario cũng cú thể xem như cỏc Use case trong phõn tớch thiết kế hướng đối tượng. Vớ dụ, scenario của người bảo trỡ là mụ tả nõng cấp hệ điều hành hay thờm một chức năng của hệ thống. Đối với nhà phỏt triển thỡ việc mụ tả sử dụng kiến trỳc để xõy dựng hệ thống hay để dự bỏo hiệu năng cũng được xem là một scenario. Scenario của khỏch hàng cú thể là mụ tả xem kiến trỳc đú được sử dụng lại như thế nào đối với sản phẩm tiếp theo…
2.4.3.1 Cỏc loại scenario
Trong ATAM người ta sử dụng 3 loại scenario là: use case scenarios; growth
scenarios ; và exploratory scenarios. Ba loại scenario này được dựng để xem xột
hệ thống dưới cỏc gúc nhỡn khỏc nhau. Dưới đõy là mụ tả chi tiết về từng loại scenario này.
Use case scenario
Use case scenarios mụ tả sự tương tỏc của người dựng với hệ thống, vớ dụ:
1. Khi khỏch hàng chọn sản phẩm từ danh sỏch thỡ phần mềm mất 5s để hoàn
thành (scenario về Performance)
2. Người dựng muốn duyệt cỏc sản phẩm theo danh mục và tổ chức cỏc danh
mục này theo hỡnh cõy để di chuyển dễ dàng (scenario về usability).
3. Khi một ngoại lệ (Exception) xuất hiện thỡ chi tiết về lỗi sẽ được gửi tới những người phụ trỏch và giao dịch đú được hủy bỏ (scenario về reliability)
4. Người dựng thay đổi kiểu hiển thị (theme) của trang web chỉ mất thời gian
khoảng 2s (scenario về performance)
5. Người dựng yờu cầu thực hiện bỏo cỏo chi tiết đơn hàng sau khi đặt và hệ
thống chỉ mất thời gian 5 s để hoàn thành (scenario về performance)
6. Người dựng chỉ cú thể đặt hàng nếu như quỏ trỡnh đăng nhập là hợp lệ (scenario về security)
Xin lưu ý rằng, mỗi scenario ở trờn đều mụ tả mong muốn của một nhúm người liờn quan nào đú. Vớ dụ scenario 1,2,5 là mong muốn của người dựng ; scenario 2 là mong muốn của nhà phỏt triển; scenario 4,6 là mong muốn của khỏch hàng…
Growth Scenarios
Growth scenarios mụ tả cỏc thay đổi cú thể thấy trước đối với hệ thống trong tương lai. Vớ dụ:
1. Khi số người dựng truy cập đồng thời lờn tới 10000 thỡ chức năng in bỏo