軟件系統(tǒng)設(shè)計與體系結(jié)構(gòu)：Ch7 Software Architectures Evaluation

1、 Ch7 Software Architectures Evaluation (Analysis)Software System Design and ArchitectureMain ContentsBasic of Design EvaluationATAMDesign evaluationTestingsystem testingReviewChecklistScenario MethodsMeasurementMain ContentsBasic of Design EvaluationATAMATAM StepsStep 1: Present ATAMEvaluation Team

2、presents an overview of the ATAM ATAM steps in brief Techniques- utility tree generation- architecture elicitation and analysis- scenario brainstorming/mapping Outputs- architectural approaches (design decisions)- utility tree- scenarios- risks and “non-risks”- sensitivity points and tradeoffsStep 2

3、: Present Business DriversATAM customer representative describes the systems business drivers including: Business context for the system High-level functional requirements High-level quality attribute requirements Architectural drivers: quality attributes that “shape” the architecture Critical requi

4、rements: quality attributes most central to the systems successPurchase2Pay: Business Context and DriversMajor stakeholders and usersStakeholdersProcurementFinanceLegalUsersScannerPosterReviewerApproverPurchase2Pay: Business ConstraintsTime to marketVery fastUser demandsEasy to useFastStandardsSAPDo

5、cumentumCostTo be minimized Purchase2Pay: Quality Attribute RequirementsUsabilityE-documents can easily be read when displayed on screenAvailabilityVery High availability during Bratislava business hoursHigh availability 24/7 for other business workersPerformanceThroughputInfrastructure must allow t

6、o process at least 400 invoices per hour every 9 sec a request for a document upload is submitted; there will be a download every 3 sec!UI responsiveness average 5 s worse case 10 sStep 3: Present the ArchitectureArchitect presents an overview of the architecture including (for example):Technical co

7、nstraints such as an OS, hardware, or middle-ware prescribed for useOther systems with which the system must interactArchitectural approaches/styles used to address quality attribute requirementsEvaluation team begins probing for and capturing risks.Step 4: Identify Architectural ApproachesStart to

8、identify places in the architecture that are key for realizing quality attribute goals.Identify any predominant architectural approachesPurchase2Pay: Architectural ApproachesClient ServerSap client Sap serverDocumentum client Documentum ServerMultistep process integrationPosting tool spawns acrobat

9、viewerVerification tool spawns acrobat viewerData consistency integration eConnector creates invoice objects in SAP based on documents posted to DocumentumStep 5: Generate Utility TreeIdentify, prioritize, and refine the most important quality attribute goals by building a utility tree.A utility tre

10、e is a top-down vehicle for characterizing the “driving” attribute-specific requirementsSelect the most important quality goals to be the high-level nodes (typically performance, modifiability, security, and availability)importance, difficultyScenarios are the leaves of the utility tree Output: a ch

11、aracterization and a prioritization of specific quality attribute requirements.Step 5: Utility Tree /cont.importance, difficultyStep 5- ScenariosScenarios are used toRepresent stakeholders interestsUnderstand quality attribute requirementsScenarios should cover a range ofAnticipated uses of (use cas

12、e scenarios),Anticipated changes to (growth scenarios), orUnanticipated stresses (exploratory scenarios) to the system.A good scenario makes clear what the stimulus is that causes it and what responses are of interest.General scenarios for qualities requirements in software architecture designScenar

13、io: Detect and recover from HW failure of prim CPUAttribute(s): AvailabilityEnvironment: Normal operationsStimulus:One CPU failsResponse:99,999% availabilityPurchase2Pay: Quality Attribute TreeQA-L1QA- L2BPTPScenarioPerformanceLatencyHHOpening a e-invoice for reading takes less that 3 seconds from a

14、ny site that is in scope of p2pPerformanceThroughputHHOpening documents at a continuous rate of 2 documents per second has average response time better than 3 sec per doc for any of the sites in scope of p2pAvailabilityOverallHHA site that is disconnected due to network failure is re-connected with

15、full bandwidth in less than 2 hoursAvailabilityOverallHMHardware failure of one CPU in the infrastructure components (SAP, Documentum) has no effect on realization of QAAvailabilityOverallHHThere will be no more than 4 unavailability situations per year18Step 6: Analyze Architectural ApproachesPurpo

16、se:Architect to make the compelling case why the architecture supports the scenarios. If not, risks are identified.MechanismInterviewing the architect. Architect needs to convince evaluator.Identify and record risks and non-risks, sensitivity points and tradeoffsSensitivity A property of a component

17、 that is critical to success of system.Tradeoff point- A property that affects more than one attribute or sensitivity point.Step 6: Analyze the Architectural ApproachesScenario: Detect and recover from HW failure of prim CPUAttribute(s): AvailabilityEnvironment: Normal operationsStimulus:One CPU fai

18、lsResponse:99,999% availabilityArchitectural decisionsArch. decisionSensitivityTrade-offRiskNonriskBackup CPUsS2R8No backup channelS3T3R9WatchdogS4N12HeartbeatS5N13Failover routingS6N14Scenario:E-connector looses connection with SAPAttribute:Availability-Overall AvailabilityStimulus: Temporary netwo

19、rk faultResponse:The system has an overall availability of 99,25% (max 2 hour down/ month)Architectural decisionSensitivityTrade-offRiskNon-riskDCTM content server runs on a clustered environment with 2 nodesCommon mode failure can not be handledProbability of common mode failure is lowIntegration r

20、elationship between SAP and Documentum is data consistency and is not protectedHuman user must report malfunctionFrom complaint to resolution 2 hoursScenario:Invoice poster needs e-document for data entry in SAP/R3Attribute:Perfomance-LatencyStimulus: Document request to DocumentumResponse:Document

21、is available for processing in less than 10 sArchitectural decisionSensitivityTrade-offRiskNon-riskE-documents are scanned in color at 200 dpiSize of document is sensitive to quality of scanningUsability vs PerformanceDocument too large for roundtrip in 10 s.E-documents are not cachedEvery document must be fetched from DMTMDevelopment cost vs bandwidth costDocument roundtrip time exceeds 10 s.Step 7: Brainstorm & Prioritize ScenariosStakeholders generate