3. Cấu trỳc và nội dung của luận văn
2.4.4 Đầu ra của ATAM
Mặc dự cụng việc chủ đạo trong phiờn đỏnh giỏ kiến trỳc là gạn lọc cỏc yờu cầu và đặc tả kiến trỳc nhưng mục tiờu chớnh của phiờn đỏnh giỏ là tỡm ra cỏc quyết định cú ý nghĩa then chốt đến sự thành cụng của hệ thống. Cụ thể là phải tỡm ra cỏc điểm nhạy cảm (Sensitivity points), cỏc rủi ro (risk points), phi rủi ro (non-risk points), cỏc điểm cõn bằng (Tradeoff-points).
Hỡnh 12 – Đầu vào, đầu ra của ATAM
2.4.4.1 Cỏc rủi ro và phi rủi ro (Risks and Non-Risks)
Rủi ro là những quyết định liờn quan đến kiến trỳc cú thể nảy sinh ra cỏc vấn đề tiềm ẩn ảnh hưởng đến hệ thống. Cũn phi rủi ro là cỏc quyết định tốt, khụng gõy ra những rủi ro tiềm tàng. Cả hai yếu tố này đều cần phải được hiểu thấu đỏo và ghi nhận trong tài liệu.
Vớ dụ về rủi ro:
Cỏc qui tắc viết module nghiệp vụ trong ở tầng thứ hai trong phong cỏch kiến trỳc client-server 3 tầng khụng được định nghĩa rừ ràng. Điều này cú thể dẫn tới sự lặp lại về chức năng khi cú sự sửa đổi ở tầng thứ 3. Cỏc qui tắc khụng rừ ràng khi viết logic nghiệp vụ như vậy cú thể khiến sự ghộp nối (coupling) cỏc thành phần khụng được như mong muốn (đú là nguyờn nhõn dẫn đến cỏc hệ lụy tiờu cực).
(Cỏc rủi ro cũng cú thể phỏt sinh từ nhiều nguồn khỏc. Chẳng hạn, nếu cấu trỳc về quản lý và cấu trỳc về kiến trỳc khụng ăn khớp với nhau cú cú thể sinh ra rủi ro về tổ chức. Hay việc thiếu giao tiếp giữa những nhúm tham gia và nhà kiến trỳc cũng gõy ra rủi ro về quản lý).
2.4.4.2 Cỏc điểm nhạy cảm và điểm cõn bằng (Sensitivity and Tradeoff Points)
Khỏi niệm điểm nhạy cảm, điểm cõn bằng là một trong những khỏi niệm rất quan trọng trong ATAM. Phần này sẽ trỡnh bày chi tiết về cỏc thuật ngữ quan trọng này. Điểm nhạy cảm là một thuộc tớnh của một hoặc nhiều thành phần cú ảnh hưởng quyết định đến việc đạt được thuộc tớnh chất lượng cụ thể. Vớ dụ:
Mức độ bảo mật của một mạng riờng ảo cú thể là nhạy cảm đối với số bit
mó húa.
Độ trễ xử lý một message quan trọng cú thể nhạy cảm đối với tiến trỡnh tham gia xử lý message cú mức độ ưu tiờn thấp nhất.
Số ngày cụng trung bỡnh cần để duy trỡ hệ thống cú thể nhạy cảm đối với mức độ đúng gúi của giao thức truyền thụng và khuụn dạng của file.
Dựa vào cỏc điểm nhạy cảm này mà cỏc nhà thiết kế, cỏc nhà phõn tớch biết nờn tập trung vào cỏi gỡ khi muốn đạt được mục tiờu chất lượng. cỏc điểm nhạy cảm cú chức năng giống như những cờ bỏo hiệu, kiểu như: ―Hóy chỳ ý khi thay đổi thuộc tớnh này của kiến trỳc !‖. Mỗi giỏ trị cụ thể của điểm nhạy cảm cú thể gõy ra một mức độ rủi ro nhất định khi được thực hiện. Chẳng hạn, như vớ dụ ở trờn nếu độ dài mó húa là 32 hay 64 bit thỡ sẽ mức độ rủi ro tương ứng. Hay nếu độ trễ xử lý message quỏ thấp thỡ kiến trỳc đú cũng gõy ra một mức độ rủi ro nào đú.
Điểm cõn bằng là một điểm nhạy cảm nhưng nú ảnh hưởng tới nhiều hơn một thuộc tớnh. Vớ dụ, việc thay đổi mức độ mó húa cú thể ảnh hưởng đỏng kể tới cả mức độ bảo mật cũng như hiệu năng. Việc tăng mức độ mó húa sẽ cải thiện mức độ bảo mật nhưng đũi hỏi nhiều thời gian xử lý hơn. Như vậy, mức độ mó húa đú cú thể gọi là điểm cõn bằng (vỡ ảnh hưởng tới ớt nhất là 2 thuộc tớnh). Điểm cõn bằng là những quyết định quan trọng nhất cần tạo ra trong một kiến trỳc, chớnh vỡ vậy mà người ta thường phải tập trung vào cụng việc này hết sức cẩn thận.
2.4.5. Chi tiết cỏc bƣớc thực hiện phiờn đỏnh giỏ ATAM.
Quỏ trỡnh đỏnh giỏ ATAM bao gồm 9 bước như đó mụ tả vắn tắt ở phần trước. Tuy nhiờn, khụng nhất thiết phải thực hiện theo trỡnh tự tuyến tớnh này mà tựy vào tỡnh hỡnh cụ thể cú thể điều chỉnh sao cho hợp lý. Tức là, nhà phõn tớch cú thể bỏ qua một số bước, cũng cú thể lặp lại hay quay trở về bước trước đú. Điểm quan trọng ở đõy là tại mỗi bước cần phải chỉ rừ cỏc hoạt động bờn trong và kết quả đầu ra của mỗi bước đú.
Thời gian đến tiến hành đỏnh giỏ ATAM cũng rất khỏc nhau, tựy vào kớch cỡ của dự ỏn cũng như năng lực của nhúm kiến trỳc. Thực tế cho thấy thời gian tiến hành ATAM mất khoảng vài ngày liờn tục (3-5 ngày).
2.4.5.1 Bước 1 - Trỡnh diễn ATAM (Present ATAM)
Trong bước này, người lónh đạo nhúm đỏnh giỏ sẽ trỡnh bày phương phỏp ATAM cho tất cả những người tham gia. Giải thớch qui trỡnh thực hiện mà mọi người phải tuõn theo và trả lời cỏc cõu hỏi. Mục đớch cuối cựng là mọi người đều biết thụng tin cần thu lượm là gỡ và chỳng sẽ được xem xột như thế nào, cần bỏo cỏo cho ai. Cụ thể cụng việc của bước này bao gồm:
Mụ tả vắn tắt cỏc bước của ATAM
Cỏc kỹ thuật được sử dụng để lựa chọn và phõn tớch: Cõy tiện ớch, lựa chọn/phõn tớch dựa trờn tiếp cận kiến trỳc, ỏnh xạ scenario.
Mụ tả đầu ra của phiờn đỏnh giỏ: cỏc scenario được lựa chọn và gỏn mức ưu
tiờn, cỏc cõu hỏi được dựng để hiểu / đỏnh giỏ kiến trỳc, cõy tiện ớch, bản mụ tả và mức ưu tiờn cỏc yờu cầu kiến trỳc nũng cốt, tập cỏc phong cỏch và tiếp cõnhj kiến trỳc, tập cỏc rủi ro và phi rủi ro, tập cỏc điểm nhạy cảm và cỏc điểm cõn bằng.
2.4.5.2 Bước 2 - Trỡnh diễn cỏc Business drivers
Để cú kết quả tốt thỡ điều kiện bắt buộc là tất cả những người tham gia phiờn đỏnh giỏ đều phải hiểu rừ về hệ thống đú. Tại bước này, project manager sẽ trỡnh diễn tổng quan hệ thống theo gúc nhỡn của doanh nghiệp.
Template dưới đõy cho thấy một vớ dụ về mụ tả hệ thống theo cỏch nhỡn của doanh nghiệp.
Business Context/Drivers Presentation (~ 12 slides; 45 minutes)
- Mụ tả mụi trường, lịch sử doanh nghiệp, cỏc yờu cầu chủ yếu, những người liờn quan, nhu cầu hiện tại và hệ thống đề xuất sẽ đỏp ứng cỏc yờu cầu này như thế nào (3-4 slides)
- Mụ tả cỏc ràng buộc doanh nghiệp (như thời gian đưa ra thị trường, đũi hỏi của khỏch hàng, cỏc tiờu chuẩn, chi phớ…) (1-3 slides)
- Mụ tả cỏc ràng buộc kỹ thuật (vớ dụ vấn đề liờn tỏc với cỏc hệ thống khỏc, cỏc yờu cầu phần cứng và phần mềm, việc sử dụng lại mó nguồn của hệ thống hiện cú…) (1-3 slides)
- Cỏc thuộc tớnh chất lượng mong muốn (vớ dụ về hiệu năng, tớnh sẵn sàng, tớnh bảo mật, tớnh sửa đổi, tớnh liờn tỏc, tớch hợp) (2-3 slides)
- Chỳ giải thuật ngữ (1 slide)
Bảng 3 - Bảng mẫu mụ tả Business drivers
Bản thõn hệ thống đú cũng phải được mụ tả cho tất cả những người tham gia, tuy rằng chỉ ở mức trừu tượng cao. Nội dung mụ tả thường bao gồm:
Những yờu cầu chức năng quan trọng nhất
Cỏc ràng buộc về chớnh trị, kinh tế, kỹ thuật và quản lý
Bối cảnh và mục tiờu của doanh nghiệp
Những người liờn quan chủ yếu
Cỏc architectural drivers (Cỏc mục tiờu thuộc tớnh chất lượng tạo nờn kiến
trỳc đú)
2.4.5.3 Bước 3 – Trỡnh diễn kiến trỳc
Nhúm kiến trỳc hoặc trưởng nhúm kiến trỳc sẽ trỡnh diễn kiến trỳc ở một mức chi tiết nào đú sao cho phự hợp. mức độ chi tiết phụ thuộc và rất nhiều yếu tố: như lượng tài liệu, thời gian sẵn cú hay mức độ rủi ro mà hệ thống phải đối mặt. Đõy là bước rất quan trọng vỡ lượng thụng tin kiến trỳc và tài liệu ghi chộp được sẽ ảnh hưởng trực tiếp đến quỏ trỡnh phõn tớch. Thụng thường, nhúm kiến trỳc cần phải xỏc định thờm một số thụng tin kiến trỳc khỏc nữa trước khi tiến hành giai đoạn phõn tớch tiếp theo.
Kiến trỳc trong phần trỡnh diễn này cần phải nờu được:
Cỏc hệ thống tương tỏc khỏc
Cỏc tiếp cận kiến trỳc được sử dụng để đỏp ứng cỏc yờu cầu về thuộc tớnh
chất lượng
Tại thời điểm này, nhúm đỏnh giỏ bắt đầu đi tỡm hiểu về cỏc tiếp cận kiến trỳc. Dưới đõy là một template cho phần trỡnh diễn kiến trỳc
Architecture Presentation (~20 slides; 60 minutes)
+Trỡnh bày cỏc yờu cầu kiến trỳc chủ đạo (vớ dụ về hiệu năng, tớnh sẵn sàng, tớnh bảo mật, tớnh sửa đổi, tớnh liờn tỏc, tớnh tớch hợp) và cỏc chỉ số cú thể đo lường cỏc yờu cầu này; cỏc chuẩn, cỏc mụ hỡnh, cỏc tiếp cận mà đỏp ứng cỏc yờu cầu đú (2-3 slides)
+Cỏc khung nhỡn kiến trỳc ở mức cao (4-8 slides) + Chức năng: cỏc chức năng, luồng dữ liệu….
+ khung nhỡn module/phõn tầng/ hệ thống con: Cỏc hệ thống con, cỏc tầng và module mụ tả sự phõn ró hệ thống về chức năng.
+ Tiến trỡnh/ luồng: cỏc luồng, tiến trỡnh cựng với sự đồng bộ, luồng dữ liệu và cỏc sự kiện kết nối chỳng.
+ Phần cứng: CPUs, thiết bị lưu trữ, cỏc cảm biến, thiết bị ngoài cựng với cỏc mạng, thiết bị truyền thụng kết nối chỳng với nhau.
- Cỏc tiếp cận hay phong cỏch kiến trỳc được ỏp dụng, bao gồm những
phong cỏch mà ở đú cỏc thuộc tớnh cú liờn quan và bao gồm mụ tả cỏch thức phong cỏch đú giải quyết cỏc thuộc tớnh (3-6 slides)
- Việc sử dụng COTS (Commercial Off The Shelf) và cỏch thức lựa chọn/
tớch hợp (1-2 slides)
- Chỉ ra 1-3 scenario use case quan trọng nhất. Nếu cú thể, bao gồm cả cỏc
tài nguyờn được sử dụng lỳc runtime ứng với mỗi scenario (1-3 slides)
- Chỉ ra 1-3 change scenario quan trọng nhất. Nếu cú thể, mụ tả tỏc động
thay đổi đú theo số thành phần bị thay đổi, cỏc kết nối hay cỏc giao diện (1-3 slides)
- Cỏc rủi ro hay vấn đề về kiến trỳc (2-3 slides)
- Glossary (1 slide)
Bảng 4 - Mẫu trỡnh diễn kiến trỳc
2.4.5.4 Bước 4 – Xỏc định cỏc tiếp cận kiến trỳc (Identify Architectural Approaches)
Phương phỏp ATAM tập trung vào phõn tớch kiến trỳc thụng qua cỏc tiếp cận kiến trỳc của nú. Tại bước này, cỏc tiếp cận được xỏc định bởi nhà kiến trỳc và được nhúm phõn tớch ghi nhận lại.
Lý do người ta tập trung xỏc định cỏc tiếp cận và phong cỏch kiến trỳc bởi vỡ chỳng là phương tiện giải quyết cỏc thuộc tớnh chất lượng cú mức ưu tiờn cao nhất; tức là, cỏc phương tiện để đảm bảo rằng cỏc yờu cầu quan trọng nhất là phự hợp theo một nghĩa nào đấy. cỏc tiếp cận kiến trỳc này định ra cấu trỳc quan trọng của hệ thống và mụ tả cỏc cỏch mà ở đú hệ thống cú thể phỏt triển, đỏp ứng với những thay đổi , tớch hợp với cỏc hệ thống khỏc, v.v…
2.4.5.5 Bước 5 – Sinh cõy tiện ớch thuộc tớnh chất lượng (Generate Quality Attribute Utility Tree)
Tại bước này, nhúm đỏnh giỏ làm việc cựng với nhúm kiến trỳc, nhà quản lý và đại diện khỏch hàng để tỡm, gỏn mức ưu tiờn và tinh chỉnh cỏc mục tiờu thuộc tớnh chất lượng quan trọng nhất. Đõy là bước quyết định tới cỏc bước phõn tớch cũn lại. Và để tất cả những người liờn quan đều cú một cỏi nhỡn thống nhất về hệ thống, người ta xõy dựng ra một cõy tiện ớch.
Kết quả của việc sinh ra cõy tiện ớch là cỏc yờu cầu thuộc tớnh chất lượng (được xem như cỏc scenario) đều được gỏn một mức ưu tiờn cụ thể. Danh sỏch này sẽ được sử dụng cho cỏc bước cũn lại của ATAM. Nhờ vào mức ưu tiờn mà nhúm ATAM biết được nơi nào cần đầu tư thời gian, cụ thể là nơi nào cần nghiờn cứu cỏc tiếp cận kiến trỳc cũng như cỏc rủi ro, điểm nhạy cảm, điểm cõn bằng đi cựng với mỗi kiến trỳc đú là gỡ. Ngoài ra, cõy tiện ớch cũn giỳp cụ thể húa cỏc yờu cầu thuộc tớnh chất lượng, buộc nhúm đỏnh giỏ và khỏch hàng phải xỏc định chớnh xỏc cỏc yờu cầu về ―ility‖ của họ.
2.4.5.6 Bước 6 – Phõn tớch cỏc tiếp cận kiến trỳc (Analyze Architectural Approaches)
Tại bước này, tất cả cỏc tiếp cận kiến trỳc đều được đưa vào phõn tớch. Thụng thường, mỗi cỏch tiếp cận đều cú khả năng đỏp ứng tốt một số thuộc tớnh nào đấy, nhưng đi cựng với nú là những rủi ro (mặt hạn chế). Vỡ vậy, sau khi phõn tớch từng cỏch tiếp cận thỡ kết quả đầu ra phải là danh sỏch cỏc điểm nhạy cảm, cỏc điểm cõn bằng và cỏc rủi ro tương ứng với mỗi cỏch tiếp cận.
Để hiểu rừ từng cỏch tiếp cận cũng như khỏm phỏ thờm cỏc điểm nhạy cảm, điểm cõn bằng thỡ những người tham gia sẽ đưa ra cỏc cõu hỏi chuyờn biệt về kiến trỳc và thuộc tớnh chất lượng. Chẳng hạn, với những yờu cầu đặt ra về thuộc tớnh chất lượng được thể hiện trong cõy tiện ớch, thỡ một loạt cõu hỏi sẽ được đặt ra đối với cỏc tiếp cận kiến trỳc để xem chỳng cú đỏp ứng được cỏc yờu cầu chất lượng đú hay khụng. Những cõu hỏi này cú thể xuất phỏt từ kinh nghiệm của những người tham gia hoặc từ cỏc tài liệu về kiến trỳc phần mềm. Nhờ vào đú mà ta cú thể:
Hiểu rừ hơn về tiếp cận kiến trỳc được đề xuất
Biết được cỏc điểm yếu của mỗi cỏch tiếp cận
Nắm bắt được cỏc điểm nhạy cảm
Tỡm ra được sự tương tỏc và cỏc điểm cõn bằng.
Việc phõn tớch cỏc tiếp cận kiến trỳc thường được ghi nhận bởi cỏc mẫu như sau:
Scenario: <Tờn của scenario lấy tư cõy tiện ớch sau khi đó được tập trung lựa chọn >
Attribute: <vớ dụ performance, security, availability,...>
Environment: <Cỏc giả thiết liờn quan đến mụi trường mà ở đú hệ thống tồn tại >
Stimulus: <Một phỏt biểu chớnh xỏc về tỏc nhõn thuộc tớnh chất lượng (vớ dụ; sự trục trặc, mối nguy hiểm hay sự sửa đổi, …) tiểu biểu của scenario đú >
Response: <Một phỏt biểu chớnh xỏc về đỏp ứng thuộc tớnh chất lượng (vớ dụ, thời gian phản hồi, mức độ khú khi sửa đổi)>
Architectural Decisions Risk Sensitivity Tradeoff
<Danh sỏch cỏc quyết định kiến trỳc <risk #> <sens. point #> <tradeoff #> ảnh hưởng đến đỏp ứng thuộc tớnh chất lượng>
Reasoning:
<Cỏc yếu tố định tớnh và/hoặc định lượng cho biết tại sao danh sỏch cỏc quyết định kiến trỳc lại đỏp ứng được cỏc yờu cầu đỏp ứng thuộc tớnh chất lượng>
Biểu đồ kiến trỳc:
<Cỏc biểu đồ về khung nhỡn kiến trỳc kốm với thụng tin kiến trỳc để hỗ trợ cho việc suy luận ở trờn. Cỏc biểu đồ này cú thể bao gồm thờm phần văn bản giải thớch.>
Bảng 5 - Mẫu ghi nhận cỏc tiếp cận kiến trỳc (Architectural approach)
Dưới đõy là một mẫu cụ thể:
Scenario: S12 (Phỏt hiện và khắc phục hỏng húc phần cứng của bộ chuyển mạch chớnh)
Attribute: Độ sẵn sàng
Environment: Bỡnh thường
Stimulus: Hỏng CPU
Response: Độ sẵn sàng của bộ chuyển là 0.999999
Architectural decisions Risk Sensitivity Tradeoff
Cú CPU dự phũng R8 S2
Khụng cú kờnh sao lưu dữ liệu R9 S3 T3
Cơ chế chú canh (watchdog) S4
Heartbeat S5
Failover routing S6
Suy luận:
Đảm bảo khụng gặp trục trặc khi sử dụng cỏc hệ điều hành và phần cứng khỏc nhau (Xem rủi ro R8)
Đảm bảo phỏt hiện hỏng húc trong khoảng thời gian 2 giõy nhờ vào heartbeat và watchdog…
watchdog là cơ chế đơn giản và đó được chứng minh là tin cậy
Yờu cầu về tớnh sẵn sàng cú thể gặp phải rủi ro vỡ thiếu kờnh dữ liệu dự phũng (Risk 9)
Biểu đồ kiến trỳc:
Sau bước này, nhúm đỏnh giỏ sẽ cú một tập hợp cỏc điểm nhạy cảm, điểm cõn bằng và tập cỏc rủi ro/ phi rủi ro. Tập hợp này sau đú được chia thành 3 nhúm riờng biệt tương ứng. Nhờ vào danh sỏch này mà nhúm đỏnh giỏ biết rừ những đặc điểm quan trọng nhất của từng kiến trỳc, từ đú biết được kiến trỳc nào là phự hợp nhất (giải quyết tốt nhất) những thuộc tớnh chất lượng đặt ra.
2.4.5.7 Bước 7 – Brainstorming và phõn mức ưu tiờn cho cỏc scenario
Tại bước này, những người tham gia và nhúm đỏnh giỏ sẽ đưa ra một số lượng lớn cỏc scenario để cựng thảo luận về cỏc scenario sau đú phõn mức ưu tiờn dựa trờn qui trỡnh bỏ phiếu (Voting).