Chapter 8 Analysis

Chapter 8 AnalysisZachary CleaverAnalysis Definition and PurposeArchitectural analysis is the activity of discovering important system properties using the systems architectural models.Architectural analysis helps identify incorrect/inefficient design decisions, clarifies component functions and objects, and aids in communication between designers and customers.Facets of Architectural Analysis1) Goals of analysis2) Scope of analysis3) Primary architectural concerns being analyzed4) Level of formality between modelsFacets of Analysis: Goals1) Completeness2) Consistency3) Compatibility4) Correctness

CompletenessThe main goal of assessing an architectures completeness is to ensure it adequately capture all key functional and non-functional requirements.

Ideally, all services will be needed by a component, and each component will have a service that provides for it.One-to-many relationship. Dynamic or reused products may not implement all functions as components are modified and added.5ConsistencyDefinition: Internal property of an architectural model that is intended to ensure that different elements of that model do not contradict one another.Types of Inconsistencies:NameInterfaceBehavioralInteractionRefinementName InconsistencySame-name components providing similar services. Is the right one being used?

Accessing a nonexistent class or method resulting in compile-time errorsErrors like in Java. Asynchronous event broadcasts, just-in-time programming7Interface InconsistencyReqInt: getSubQ(Natural first, Natural last, Boolean remove) returns FIFOQueue;

ProvInt1: getSubQ(Index first, Index last) returns FIFOQueue;

ProvInt2: getSubQ(Natural first, Natural last, Boolean remove) returns Queue;Behavioral InconsistencySubtract(int x, int y) returns int;

int myVal = Subtract(427, 27)

The method behavior treats it as a date subtraction, subtracts 27 days from April 27, and returns 331 (March 31)

Interaction InconsistencyOccurs when a components provided operations are accessed in a manner that violates certain interaction constraints.

Ex. pop_back() in c++Refinement InconsistencyRefinement inconsistencies stem from a systems architecture being frequently captured at different levels of abstraction (higher v. lower)

Check that elements were not lost, key properties were not omitted or changed, etc.Looks at major subsystems and dependencies (high) elaborate on details of subsystems and dependencies11CompatibilityCompatibility ensures that the model adheres to the design guidelines imposed by an architectural style, reference architecture, or architectural standard.Make sure it fits the template design youre going for, or that all constraints are met for the desired structure12CorrectnessCorrectness is relative.

It is the result of architecture to some artifact, where the artifact either fulfills the architecture or the architecture elaborates and fulfills the artifact.Meeting the standards.13Scope of AnalysisComponent and Connector LevelSubsystem and System LevelData Exchanged in (sub)systemArchitectures at Different Abstraction LevelsComparison of Two or More ArchitecturesComponent and Connector Level AnalysisEnsures the given component or connector provides the services expected of itHowever, this does not ensure services are modeled correctlyChecks name consistencyGetters and setters are all there. Doesnt ensure theyre modeled correctly; more like name consistency15Subsystem and System Level AnalysisPair-wise conformance: Two interacting components are considered at a time, and name, interface, behavior, and interaction conformance are established.

Compare component properties (efficiency vs. security)

Petrys Honey-baked ham syndromeHoney is fat free, and ham is sugar free, so honey-ham is both16Data Exchanged in the System or SubsystemAssess data elements to ensure the systems data is properly modeled, implemented, and exchanged among structural elementsStructure of the data (typed vs. untyped)Flow of data through the system (point-to-point vs. broadcast)Properties of data exchange (consistency, security, etc.)Architecture at Different Abstraction LevelsABCDComparisons of Two or More ArchitecturesComparing current architecture to a model of the desired architectureComparing two architectures for properties such as processing and storage capabilitiesArchitectural Concern Being AnalyzedStructural CharacteristicsBehavioral CharacteristicsInteraction CharacteristicsNon-functional Characteristics

Structural CharacteristicsDetermines whether the architecture is well formedFocuses on connectivity among architecture components and connectors, points of network distribution, etc.Identify problems such as disconnected components or subsystems, missing pathways between components and connectors, unwanted pathways, etc.Behavioral CharacteristicsConcerned with the behavior of individual components and their behaviors as a whole within the architectureInternal behaviors of individual components is considered, as well as the composite behaviors of components as they interactInteraction CharacteristicsHelps to establish whether the architecture will actually be able to fulfill some of its requirements (efficiency)Concerned with internal behaviors of systems (security)Non-Functional CharacteristicsDifficult to assess since they can span multiple components and connectorsTheir definitions can be much more informal, making it difficult to properly understand them in the architectureLevel of Formality of Architectural ModelsInformalSemiformalFormalInformal ModelsTypically captured in box-and-line diagramsGreat for showing high-level representations of a systemCan be dangerous to use because of a lack of information and an ambiguous natureSemiformal ModelsAims to be useful to both technical and nontechnical stakeholdersUML

Formal ModelsDesigned for technical stakeholdersThese type of models can suffer from scalability problemsChapter 8 AnalysisKata MorovatOutlineType of AnalysisLevel of AutomationSystem StakeholdersAnalysis TechniquesType of AnalysisStatic AnalysisDynamic AnalysisScenario-Based AnalysisStatic Analysis - DefinitionInfer the properties of a software system from of its models without executing those modelsStatic analysis can be automated (compilation) or manual ( inspection)

Static Analysis - ExampleA simple example is syntactic analysis. Determining if the system model adheres to the syntactic rules of the modeling notation (architectural description language or programming language)All architectural modeling notations are agreeable to static analysisFormal notations, includes:Axiomatic notations, use logical declarationAlgebraic notations, use collection of equivalence relationsTemporal logic notations, use order of execution and timingDynamic Analysis - DefinitionDynamic analysis involves the execution or simulation the execution of a model of the software systemDynamic Analysis - ExampleState- transition diagrams

Scenario-Based Analysis - DefinitionFor large and complex software system, declaring all properties for entire system over the entire space is infeasibleUse case which represent the most important or most frequently occurring system scenarios, or a methodology to identify, clarify, and organize system requirementsUse case diagram is a graphic depiction of the interactions among the elements of a system

Level of AutomationDepends on the completeness of the architectural model and property being definedA model with a greater numbers of the architectural design decisions for the given system will be more amenable to automated analysis than a model with informal notationLevel of Automation Manual AnalysisManual analysis requires human involvement. This can be used when multiple clashing properties must be ensured in tandemMany manual analysis techniques are used for specifying a detail processThe manual analysis results are typically qualitative, frequently are also qualified by a particular context in which a system may show a given property, Scenario-based techniques fall in this category

Manual Analysis - ExampleInspection-based techniques falls in Manual analysis categoryOne well-known example is architecture trade-off analysis method Level of Automation Partially AutomatedArchitecture analyses can be automated by involving software tools and human interventionArchitectural analysis techniques can be describes as covering a spectrum of automation, with manually and fully automated analysisLevel of Automation Fully AutomatedArchitectural analysis can be considered fully automatableIt means it is possible to complete them without human involvementSystem StakeholdersStakeholders in a software project will have different objectivesArchitects Take a global view of the architectureInterested in establishing all four Cs in the architectureRely on all types of architectural models at all levels of scopeDevelopersTake a limited view of architecture modules or subsystemInterested in establishing the consistency of their modules and other parts of the systemInterested in using formal model System StakeholdersManagersInterested in architectures completeness all requirements are satisfiedInterested in architectures correctness the requirements are realized in the architecture and eventually will be realized in the implementationInterested in architectures compatibility if the architecture and implementation are close to standardsPrefer to use the less formal architecture modelsCustomersInterested in commissioned systems completeness and correctnessInterested in the systems compatibility with certain standards

System StakeholdersInterested in overall models and systems key propertiesInterested in scenario-driven assessment of the structure, behavior and dynamic characteristic of the systemVendorsInterested in combining of components and connectorsInterested in compatibility with certain standardsAnalysis of the individual elements and their propertiesAnalysis TechniquesThree categories of architectural analysis techniques:Inspection and review-basedModel-basedSimulation-based Inspection and Review-basedManual techniquesArchitectural models are conducted by different human stakeholders to ensure a variety of properties, such as architecture satisfies a given non-functional propertiesArchitectural models considers to multiple architectural properties.Useful in the case of informal architectural descriptionsUseful in establishing soft system properties, such as scalability or adaptabilityType of analysis for inspections and reviews are static and scenario-based

Inspection and Reviews Analysis SummaryAnalysis Goals anyAnalysis Scope any Analysis Concern any, but particularly suited for non-functional propertiesArchitectural Models any, but must be covered stakeholder needs and analysis objectivesAnalysis Types mostly static and scenario-basedAutomation Level manual, human intensiveStakeholders any, except perhaps component vendors

Example - ATAMStands for Architectural Trade-Off Analysis Method.A human-centric process for identifying risk early in a software designTwo key inputs into the ATAM process : Business drivers and System software architecture.Projects manager or customers present the systems major business drivers, including :The systems critical functionalityAny technical, managerial, economic, or political constraintsThe projects business goals and contextThe major stakeholdersThe principal quality attribute (NFP) goals

Focuses specifically on four quality attributes (NFPs)ModifiabilitySecurityPerformanceReliabilityReveals how well an architecture satisfies quality goals and how those goals trade-off

ATAM Process

ATAM ScenariosUse-case scenariosDescribe how the system is envisioned by the stakeholders to be usedGrowth scenariosDescribe planned and envisioned modifications to the architectureExploratory scenariosTry to establish the limits of architectures adaptability with respect tosystems functionalityScenarios are prioritized based on importance to stakeholders

ATAM Analysis : Key StepsObjective is to establish relationship between architectural approaches and quality attributesFor each architectural approach a set of analysis questions are formulatedTargeted at the approach and quality attributes in questionSystem architects and ATAM evaluation team work together to answer these questions and identifyRisks these are distilled into risk themesNon-RisksSensitivity pointsTrade-off pointsBased on answers, further analysis may be performed

ATAM Analysis SummaryAnalysis Goals - completeness, consistency, compatibility, correctnessAnalysis Scope system, system-level and data exchange Analysis Concern non-functionalArchitectural Models informal, semi-formalAnalysis Types scenario-drivenAutomation Level manualStakeholders architects, developers, managers, customers

Model-Based AnalysisAnalysis techniques that manipulate architectural description to discover architectural propertiesTool-driven, hence potentially less costlyTypically useful for establishing hard architectural properties Usually focus on a single architectural aspect, such as syntactic correctnessScalability may be an issueTechniques typically used in tandem to provide more complete answers

Model-Based Analysis SummaryAnalysis Goals consistency, compatibility, correctnessAnalysis Scope any Analysis Concern structural, behavioral, interaction, and possibly non-functional propertiesArchitectural Models semi-formal and formalAnalysis Types staticAutomation Level partially and fully automatedStakeholders mostly architects and developersModel-Based Analysis Enabled by ADLsADL stands for Architecture Description LanguageADL parsers and compilers ensure syntactic and semantic correctness, like Rapides generation of executable architectural simulationsEnforcement of constraint , parsers and compilers enforce constraints implicit in type information, non-functional attributes, components and connectors interfaces, and semantic modelsArchitectural refinement across multiple levels of detail like SADL and Rapide

ADLs Analysis SummaryAnalysis Goals consistency, compatibility, completenessAnalysis Scope component and connector-level, subsystem and system level, data exchange, different abstraction level, architecture comparisonAnalysis Concern structural, behavioral, interaction, non-functional propertiesArchitectural Models semi-formal and formalAnalysis Types staticAutomation Level partially and fully automatedStakeholders architects, managers, developers, customers

Architectural Reliability AnalysisReliability is the probability that the system will perform its intended functionality under specified design limits, without failure A failure is the occurrence of an incorrect output as a result of an input value that is received, with respect to the specification An error is a mental mistake made by the designer or programmerA fault or a defect is the manifestation of that error in the system An abnormal condition that may cause a reduction in, or loss of, the capability of a component to perform a required functionA requirements, design, or implementation flaw or deviation from a desired or intended state

Reliability MetricsTime to failureTime to repairTime between failures

Architecture Level of Assessing Reliability Challenged by unknownsFailure and recovery historyChallenged by uncertaintiesMultiple development scenariosVarying granularity of architectural modelsDifferent information sources about system usageArchitectural reliability values must be qualified by assumptions made to deal with the above uncertaintiesReliability modeling techniques are needed that deal effectively with uncertainties like Hidden Markov Models (HMMs)Aspects of Reliability Analysis SummaryAnalysis Goals consistency, compatibility, correctnessAnalysis Scope component and connector-level, subsystem and system levelAnalysis Concern non-functional propertiesArchitectural Models formalAnalysis Types static and Scenario-basedAutomation Level partially automatedStakeholders architects, managers, customers, vendors

Simulation-Based Analysis

Simulation-Based Analysis SummaryAnalysis Goals anyAnalysis Scope any Analysis Concern behavioral, interaction, and non-functional propertiesArchitectural Models formalAnalysis Types dynamic and scenario-basedAutomation Level fully automated; model mapping may be manualStakeholders any

Example XTEAMeXtensible Tool-chain for Evaluation of Architectural ModelsTargeted at mobile and resource-constrained systemsCombines two general purpose ADLsxADL and FSPTo capture important features of mobile systemImplements simulation-based analysis capabilities forOne-to-one latency, memory utilization, reliability, energy consumption

XTEAM Analysis SummaryAnalysis Goals consistency, compatibility, correctnessAnalysis Scope component and connector-level, subsystem and system level, data exchangeAnalysis Concern structure, behavior, interaction, non-functionalArchitectural Models formalAnalysis Types dynamic and Scenario-basedAutomation Level automatedStakeholders architects, managers, developer, customers, vendors

Remark pointsArchitectural analysis is neither easy nor cheapThe benefits typically far outweigh the drawbacksEarly information about the systems key characteristics is vitalMultiple analysis techniques often should be used in concertHow much analysis?This is the key aspect of an architects jobToo many will expend resources unnecessarilyToo few will carry the risk of propagating defects into the final systemWrong analyses will have both drawbacks

Thank you