Analysis TechniquesArchitectural Analysis in a NutshellAnalysis Technique CategoriesArchitectural Inspections and ReviewsInspections and Reviews in a NutshellExample – ATAMATAM ProcessATAM Business DriversATAM ScenariosATAM ArchitectureATAM AnalysisATAM in a NutshellModel-Based Architectural AnalysisModel-Based Analysis in a NutshellModel-Based Analysis in ADLsADLs’ Analysis Foci in a NutshellArchitectural Reliability AnalysisReliability MetricsAssessing Reliability at Architectural LevelArchitectural Reliability Analysis in a NutshellSimulation-Based AnalysisArchitectural and Simulation ModelsSimulation-Based Analysis in a NutshellExample – XTEAMExample XTEAM ModelExample XTEAM AnalysisXTEAM in a NutshellClosing RemarksCopyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.Analysis TechniquesSoftware ArchitectureLecture 142Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureArchitectural Analysis in a NutshellSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.3Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureAnalysis Technique CategoriesInspection- and review-basedModel-basedSimulation-based4Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureArchitectural Inspections and ReviewsArchitectural models studied by human stakeholders for specific propertiesThe stakeholders define analysis objectiveManual techniquesCan be expensiveUseful in the case of informal architectural descriptionsUseful in establishing “soft” system propertiesE.g., scalability or adaptabilityAble to consider multiple stakeholders’ objectives and multiple architectural properties5Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureInspections and Reviews in a NutshellAnalysis Goals – anyAnalysis Scope – any Analysis Concern – any, but particularly suited for non-functional propertiesArchitectural Models – any, but must be geared to stakeholder needs and analysis objectivesAnalysis Types – mostly static and scenario-basedAutomation Level – manual, human intensiveStakeholders – any, except perhaps component vendors6Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureExample – ATAM Stands for architectural trade-off analysis methodHuman-centric process for identifying risks early on in software designFocuses specifically on four quality attributes (NFPs)ModifiabilitySecurityPerformanceReliabilityReveals how well an architecture satisfies quality goals and how those goals trade-off7Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM ProcessSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.8Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM Business DriversThe system’s critical functionalityAny technical, managerial, economic, or political constraintsThe project’s business goals and contextThe major stakeholdersThe principal quality attribute (NFP) goals9Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM ScenariosUse-case scenariosDescribe how the system is envisioned by the stakeholders to be usedGrowth scenariosDescribe planned and envisioned modifications to the architectureExploratory scenariosTry to establish the limits of architecture’s adaptability with respect tosystem’s functionalityoperational profilesunderlying execution platformsScenarios are prioritized based on importance to stakeholders10Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM ArchitectureTechnical constraintsRequired hardware platforms, OS, middleware, programming languages, and OTS functionalityAny other systems with which the system must interactArchitectural approaches that have been used to meet the quality requirementsSets of architectural design decisions employed to solve a problemTypically architectural patterns and styles11Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM AnalysisKey step in ATAMObjective is to establish relationship between architectural approaches and quality attributesFor each architectural approach a set of analysis questions are formulatedTargeted at the approach and quality attributes in questionSystem architects and ATAM evaluation team work together to answer these questions and identifyRisks  these are distilled into risk themesNon-RisksSensitivity pointsTrade-off pointsBased on answers, further analysis may be performed12Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureATAM in a NutshellGoalsCompletenessConsistencyCompatibilityCorrectness`ScopeSubsystem- and system-levelData exchangeConcern Non-functionalModelsInformalSemi-formalType Scenario-drivenAutomation Level ManualStakeholdersArchitectsDevelopersManagersCustomersSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.13Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureModel-Based Architectural AnalysisAnalysis techniques that manipulate architectural description to discover architectural propertiesTool-driven, hence potentially less costlyTypically useful for establishing “hard” architectural properties onlyUnable to capture design intent and rationaleUsually focus on a single architectural aspectE.g., syntactic correctness, deadlock freedom, adherence to a styleScalability may be an issueTechniques typically used in tandem to provide more complete answers14Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureModel-Based Analysis in a NutshellAnalysis Goals – consistency, compatibility, internal correctnessAnalysis Scope – any Analysis Concern – structural, behavioral, interaction, and possibly non-functional propertiesArchitectural Models – semi-formal and formalAnalysis Types – staticAutomation Level – partially and fully automatedStakeholders – mostly