《軟件體系結構體系結構評審ArchitecturalRev》由會員分享，可在線閱讀，更多相關《軟件體系結構體系結構評審ArchitecturalRev（49頁珍藏版）》請在裝配圖網(wǎng)上搜索。
1、軟件體系結構 體系結構評審 Architectural Reviews 孫志崗 2 2021/4/6 Architectural Reviews Architectural reviews are a key step in architecture- based development. They include a method (such as SAAM or ATAM), but the full practice includes more than that. 體系結構評審是開發(fā)過程中的一個重要環(huán)節(jié)。有專門的評 審方法 (SAAM、 ATAM)，但在實踐中并不僅僅是這些 We
2、will discuss cost/benefits of architectural reviews different architectural review techniques preconditions for an architectural review architectural review activities outputs from an architectural review 3 2021/4/6 Costs of Architectural Reviews There are three different types of costs of holding
3、regular architectural reviews. direct staff costs 直接員工開銷 organizational overhead 組織管理開銷 indirect staff costs 間接員工開銷 4 2021/4/6 Examples of Direct Staff Costs AT each has a different cost and provides different information. 有很多種評審技術。每種需要不同的開銷，提供不同的信 息 These techniques fall into one of two categories
4、. questioning techniques: applied to evaluate any aspect of an architecture for any given reason 提問技術 ：用來評價體系結構的任何方面 measuring techniques: applied to answer questions about a specific quality 度量技術 ：回答關于某項質量的問題 15 2021/4/6 Questioning Techniques Scenario-based techniques describes a specific interac
5、tion between stakeholders and a system 描述角色與系統(tǒng)交互的過程 example: SAAM, ATAM (partially) Questionnaire-based techniques（基于問卷的技術） Some questions apply to all architectures (especially those in a single domain). 有些問題被用于所有的體系結構，尤其是在單一領域內 Some questions ask about details of a specific architecture. 有些問題詢問一個特
6、定結構的細節(jié) Some ask about the development process. “Is there a single architect?” “How do you ensure conformance?” “你們怎樣保證一致性？” 16 2021/4/6 Questioning Techniques Questionnaires are reused; they reflect more maturity or experience within a domain. 問卷可以重用；它們體現(xiàn)了在一個領域內 的成熟度和經(jīng)驗是否豐富 Scenarios must be develo
7、ped anew for each system. 場景必須為每個系統(tǒng)重新開發(fā) 17 2021/4/6 Measuring Techniques Metrics: quantitative interpretations of observable measures 量度：可測質量的定量說明 complexity metrics identify areas where modifications may be difficult 復雜度的測量指明在哪個區(qū)域修改會很困難 performance metrics suggest areas where bottlenecks may occur
8、 性能的測量提示瓶頸會在哪里發(fā)生 Reviews tend to focus on results of metrics 度量的結果 assumptions underlying the interpretation of the metrics (e.g., assumed event distribution) 對度量的解釋中的潛在假定 18 2021/4/6 Measuring Techniques Simulations, prototypes, experiments: domain specific models of an architecture or performance
9、 model 仿真、原型、實驗：建立體系模型或者性能模型 are expensive to create often exist as part of development anyway May answer issues raised by questioning technique 可以回答提問技術提出的問題 “ What evidence do you have that performance is adequate?” “你憑什么說可以達到這個性能？” 19 2021/4/6 Properties of Review Techniques 評審技術 通用性 細節(jié)等級 階段 被評審
10、對象 提問 技術 問卷 通用 粗糙 早期 設計和過程 場景 特定系統(tǒng) 中等 中期 設計 度量 技術 度量 通用或者特定領域 好 中期 設計 仿真 原型 實驗 特定領域 不定 早期 設計 20 2021/4/6 Review Process An architectural review has three major elements. preconditions: the set of necessary assets and conditions that must be in place before a review can be performed successfully 前提
11、：評審成功進行之前，必要的資源和條件必須到 位 activities of the review itself 活動 ：評審本身 outputs: the report of review results 輸出 ：評審結果報告 21 2021/4/6 Review Preconditions Understand the context of the review 理解評審的上下文 Assemble the right people 集合正確的人 Set organizational expectations and support 期望和支持 Prepare for review 為評審做
12、準備 Obtain representation of the architecture 獲得體系結構文檔 22 2021/4/6 Preconditions: Context Planned review part of normal development activity 正常開發(fā)活動的一部分 non-adversarial（非敵對性的） scheduled well in advance（事先安排好日程） built into projects schedule and budget 包含在項目日程和預算之內 Unplanned usually occurs when project
13、 is in trouble 通常在項目出現(xiàn)問題時采用 often devolves into finger-pointing 導致互相責備 can be painful for project already struggling 對于已經(jīng)苦苦掙扎了很久的項目而言，有些痛苦 23 2021/4/6 Preconditions: Context Timing of the review early “architecture discovery review” is done after requirements are set, but before the architecture is
14、 firm 需求分析之后，體系結構還沒有確定之前進行 is used to understand implications of requirements on architecture 用來理解需求在體系結構方面的隱含內容 checks for requirements feasibility（檢查需求的可行性） prioritizes architectural goals（為質量目標排序） full architectural review is done when architectural documentation is available 體系結構文檔可用時進行 is used
15、to evaluate qualities of proposed architecture 評價被評體系結構的質量 24 2021/4/6 Preconditions: People Representatives of project（項目代表） architect designers of major modules stakeholders representatives Review team members (ideally, a separate unit) 評審團成員 (理想情況下是一個獨立組織 ) at least one domain expert included 至少
16、有一個領域專家 someone to handle logistics (e.g., meeting rooms, supplies) 后勤人員 (會議室、茶水、食品 ) librarian to organize documentation 文檔管理員 “ apprentice reviewer” for growth 成長中的評審員學徒 25 2021/4/6 Preconditions: Review Team The review team must be assembled so that members are perceived as impartial, objective,
17、 and respected 成員要公正、客觀和被尊重 members devote their full-time effort to the review 成員全心加入評審 members are fluent in architecture and architectural issues 成員要訓練有素而且口才好 it is located close to artifacts being examined 有足夠的權限檢查被評審材料 26 2021/4/6 Preconditions: Review Team The team must have access to applica
18、ble domain knowledge (perhaps via consultants to the team) 適當?shù)念I域知識 design documents 設計文檔 review criteria 評審標準 support staff 支持人員 27 2021/4/6 Preconditions: Organizational Expectations A contract between the review team and the sponsor of the review must be established. Who will be told what upon co
19、mpletion? 結束后，哪些內容可以被告訴哪些人 What will (not) be the review criteria? 什么是 (不是 )評審標準？ What/who will be made available to team? 哪些人和物是評審團可以使用的？ What follow-up is expected? 希望評審的結果如何？ How long will the review take? 要評審多久？ 28 2021/4/6 Preconditions: Organizational Expectations Organizational culture and s
20、upport must be considered. Are reviews part of the standard project life cycle? 評審是項目的基本生命周期的一部分嗎？ Is serving on a review team considered good for ones career? 為評審團服務是份好差事嗎？ Will the organization allow its superior designers time off from their projects to serve on review teams? 企業(yè)允許它的高級設計師把他的項目放在一邊
21、來參加評審嗎？ Is there a standing review organization (even though members may rotate on and off)? 有常設的評審組織嗎 (即便成員常進進出出 )？ 29 2021/4/6 Preconditions: Read-Ahead Material For project being reviewed questionnaires scenarios (These are created as part of the review, but time should be allowed for project me
22、mbers to digest the information.) For review team description of architecture rationale for architecture Ideally, material will address the review questions. (Passing this test because the questions were known in advance is not cheating, but good engineering!) 理想情況，材料要能說明評審時的問題 30 2021/4/6 Precondi
23、tions: Ranked Quality and Behavioral Requirements Plan to examine three to five quality and behavioral requirements. 計劃檢查 3到 5個質量和行為需求 A particular representation medium (language) for the architecture is not necessary. As long as the information can be extracted (using project members as necessary)
24、, the form of the representation is not important. 一個專門的體系結構表述媒體 (語言 )目前并不是 必須的。由項目成員來講解信息，表述的形式并 不重要 31 2021/4/6 Review Activities Evaluate “Run” the scenarios and ask the questions, or answer the items in the checklist. 按場景執(zhí)行，并詢問相關問題；或者回答問卷里的問 題 Perform the experiments.（演示實驗） Execute the prototyp
25、es or simulations. 運行原型或仿真程序 Record critical issues highlighted in the review 評審中發(fā)現(xiàn)的嚴重問題 comments of project members on these issues 項目成員對這些問題的說明 32 2021/4/6 Review Activities Rank the issues project-threatening（生死攸關） major minor Each issue raised should be addressed in terms of changing the archit
26、ecture relaxing the requirements 33 2021/4/6 Review Activities Warning signs architecture forced to match organization 組織模式影響體系結構 top-level components number over 25 頂層組件數(shù)超過 25個 one requirement drives entire design 一項需求決定整個設計 architecture depends on alternatives in the operating system 體系受操作系統(tǒng)選擇的影響
27、 34 2021/4/6 Review Activities Warning signs choice of software components is dictated by hardware personnel 由硬件人員選擇軟件組件 redundancy not needed for reliability 面對可靠性時，不考慮冗余手段 design is exception driven 零散的小的事件影響設計 no identifiable architect 沒有確定的架構師 35 2021/4/6 Output from Review Set of ranked issue
28、s supporting data contained in formal report feedback to project Enhanced system documentation 增強的系統(tǒng)文檔 Set of scenarios for future use 將來會用到的場景集 Identification of potentially reusable components 認定潛在的可重用組件 Estimation of costs and benefits 估算成本和收益 36 2021/4/6 SAAM: Software Architecture Analysis Met
29、hod 一種簡單的基于場景的評審技術 37 2021/4/6 Qualities Are Too Vague for Analysis Is the following system modifiable? 這個系統(tǒng)具有適應性嗎？ Background color of the user interface is changed merely by modifying a resource file. 通過修改資源文件，可以改變界面的背景色 Dozens of components must be changed to accommodate a new data file format.
30、必須修改許多組件才能適應新的文件格式 A reasonable answer is 一個合理的答案： yes with respect to changing background color 有 ，從改變背景色的角度來看 no with respect to changing file format 沒有 ，從改變文件格式的角度來看 38 2021/4/6 Qualities Are Too Vague for Analysis Qualities only have meaning within a context. 質量因素只在一定的上下文里才有意義 SAAM specifies co
31、ntext through scenarios. SAAM通過場景指定上下文 39 2021/4/6 Scenarios A scenario is a brief description of a stakeholders interaction with a system. 場景就是一個角色與系統(tǒng)交互過程的簡單描述 When creating scenarios, it is important to consider all stakeholders. 建立場景的時候，一定要考慮到所有的角色 Customer、 User、 Developer、 Maintainer、 Attacker
32、 The scenarios that are of most interest in a SAAM evaluation are change scenarios. SAAM最關心的是 變化 場景 40 2021/4/6 Steps of a SAAM Evaluation Identify and assemble stakeholders 確認和召集角色 Develop and prioritize scenarios 制定場景，并排好優(yōu)先級 Describe candidate architecture(s) 描述候選的體系結構 Classify scenarios as direc
33、t or indirect 把場景分類為 直接場景 和 間接場景 Perform scenario evaluation 進行場景評估 Reveal scenario interactions 展現(xiàn)場景間的相互影響 Generate overall evaluation 整體評估 41 2021/4/6 Step 1: Identify and Assemble Stakeholders Stakeholder Interest Customer Schedule and budget; usefulness of system; meeting customers (or markets)
34、 expectations End User Functionality, usability Developer Clarity and completeness of architecture; high cohesion and limited coupling of parts; clear interaction mechanisms Maintainer Maintainability; ability to locate places of change 42 2021/4/6 Step 1: Identify and Assemble Stakeholders Stakeho
35、lder Interest System Administrator Ease in finding sources of operational problems Network Administrator Network performance, predictability Intergrator Clarity and completeness of architecture; high cohesion and limited coupling of parts; clear interaction mechanisms 43 2021/4/6 Step 1: Identify a
36、nd Assemble Stakeholders Stakeholder Interest Tester Integrated, consistent error handling; limited component coupling; high component cohesion; conceptual integrity Application Builder Architectural clarity, completeness; interaction mechanisms; simple tailoring mechanisms Representative of the dom
37、ain Interoperability 44 2021/4/6 Step 2: Stakeholders Develop and Prioritize Scenarios Scenarios should be typical of the kinds of evolution that the system must support: 場景應該是系統(tǒng)必須支持的各種演化的典型： functionality development activities change activities Scenarios should represent tasks relevant to all sta
38、keholders. 所有角色都應該能在場景中體現(xiàn)出來 Rule of thumb: 10-15 prioritized scenarios 應該有 10-15個優(yōu)先的場景 45 2021/4/6 Step 3: Describe Candidate Architectures It is frequently necessary to elicit appropriate architectural descriptions. 通常，對體系結構進行適當?shù)拿枋鍪欠浅?重要的 Structures chosen to describe the architecture will depend
39、on the type of qualities to be evaluated. 以我們需要的質量為依據(jù)，選擇用來描述 體系結構的結構 46 2021/4/6 Step 4: Classify Scenarios There are two classes of scenarios. Direct scenarios are those that can be executed by the system without modification. 直接場景是那些不需要修改系統(tǒng)就能執(zhí)行的場景 Indirect scenarios are those that require modific
40、ations to the system. 間接場景是那些需要修改系統(tǒng)的場景 The classification depends upon both the scenario and the architecture. 場景的類型因系統(tǒng)而異 For indirect scenarios we gauge the order of difficulty of each change: e.g. a person-day, person- week, person-month, person-year. 對間接場景，我們要度量適應每個變化的難度（工作量） 47 2021/4/6 Step 5:
41、 Perform Scenario Evaluation For each indirect scenario identify the components, data connections, control connections, and interfaces that must be added, deleted, or modified 明確其組件、數(shù)據(jù)連結件、控制連結件和要被增加、刪除或修改 的接口 estimate the difficulty of modification 估算修改的難度 Difficulty of modification is elicited from
42、 the architect and is based on the number of components to be modified and the effect of the modifications. 修改的難度體現(xiàn)在被修改的組件個數(shù)和修改的效果 A monolithic system will score well on this step, but not on next step. 只有一個模塊的系統(tǒng)在此項評估可以得到高分，但是 48 2021/4/6 Step 6: Reveal Scenario Interactions When multiple indirect
43、scenarios affect the same components, this could indicate a problem. 當多個間接場景影響同一個組件時，可能引發(fā)問題 could be good, if scenarios are variants of each other 可能是好事，當場景是彼此的變體 change background color to green change background color to red could be bad, indicating a potentially poor separation of concerns 可能是壞事，
44、說明模塊劃分有問題 change background color to red port system to a different platform 49 2021/4/6 Step 7: Generate Overall Evaluation Not all scenarios are equal. 場景生來不平等 The organization must determine which scenarios are most important. 必須明確哪些場景是最重要的 Then the organization must decide as to whether the design is acceptable “as is” or if it must be modified. 評審團得出結論，當前的體系結構設計可行，還 是必須要修改
軟件體系結構體系結構評審ArchitecturalRev
