Zachary Cleaver

Analysis Definition and Purpose Architectural analysis is the activity of discovering important system properties using the system’s 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 Analysis 1) Goals of analysis 2) Scope of analysis 3) Primary architectural concerns being analyzed 4) Level of formality between models

Facets of Analysis: Goals 1) Completeness 2) Consistency 3) Compatibility 4) Correctness

Completeness The main goal of assessing an architecture’s 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.

Consistency Definition: 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: Name Interface Behavioral Interaction Refinement

Name Inconsistency Same-name components providing similar services. Is the right one being used? Accessing a nonexistent class or method resulting in compile-time errors

Interface Inconsistency ReqInt: 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 Inconsistency Subtract(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 Inconsistency Occurs when a component’s provided operations are accessed in a manner that violates certain interaction constraints. Ex. pop_back() in c++

Refinement Inconsistency Refinement inconsistencies stem from a system’s 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.

Compatibility Compatibility ensures that the model adheres to the design guidelines imposed by an architectural style, reference architecture, or architectural standard.

Correctness Correctness 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.

Scope of Analysis Component and Connector Level Subsystem and System Level Data Exchanged in (sub)system Architectures at Different Abstraction Levels Comparison of Two or More Architectures

Component and Connector Level Analysis Ensures the given component or connector provides the services expected of it However, this does not ensure services are modeled correctly Checks name consistency

Subsystem and System Level Analysis Pair-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) Petry’s “Honey-baked ham” syndrome

Data Exchanged in the System or Subsystem Assess data elements to ensure the system’s data is properly modeled, implemented, and exchanged among structural elements Structure 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 Levels A B C D

Comparisons of Two or More Architectures Comparing current architecture to a model of the desired architecture Comparing two architectures for properties such as processing and storage capabilities

Architectural Concern Being Analyzed Structural Characteristics Behavioral Characteristics Interaction Characteristics Non-functional Characteristics

Structural Characteristics Determines whether the architecture is well formed Focuses 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 Characteristics Concerned with the behavior of individual components and their behaviors as a whole within the architecture Internal behaviors of individual components is considered, as well as the composite behaviors of components as they interact

Interaction Characteristics Helps 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 Characteristics Difficult to assess since they can span multiple components and connectors Their definitions can be much more informal, making it difficult to properly understand them in the architecture

Level of Formality of Architectural Models Informal Semiformal Formal

Informal Models Typically captured in box-and-line diagrams Great for showing high-level representations of a system Can be dangerous to use because of a lack of information and an ambiguous nature

Semiformal Models Aims to be useful to both technical and nontechnical stakeholders UML

Formal Models Designed for technical stakeholders These type of models can suffer from scalability problems

Kata Morovat

Outline  Type of Analysis  Level of Automation  System Stakeholders  Analysis Techniques

Type of Analysis o Static Analysis o Dynamic Analysis o Scenario-Based Analysis

Static Analysis - Definition o Infer the properties of a software system from of its models without executing those models o Static analysis can be automated (compilation) or manual ( inspection)

Static Analysis - Example o A 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) o All architectural modeling notations are agreeable to static analysis o Formal notations, includes: Axiomatic notations, use logical declaration Algebraic notations, use collection of equivalence relations Temporal logic notations, use order of execution and timing

Dynamic Analysis - Definition o Dynamic analysis involves the execution or simulation the execution of a model of the software system

Dynamic Analysis - Example o State- transition diagrams

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

Level of Automation o Depends on the completeness of the architectural model and property being defined o A 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 notation

Level of Automation – Manual Analysis o Manual analysis requires human involvement. o This can be used when multiple clashing properties must be ensured in tandem o Many manual analysis techniques are used for specifying a detail process o The 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 - Example o Inspection-based techniques falls in Manual analysis category o One well-known example is architecture trade-off analysis method

Level of Automation – Partially Automated o Architecture analyses can be automated by involving software tools and human intervention o Architectural analysis techniques can be describes as covering a spectrum of automation, with manually and fully automated analysis

Level of Automation – Fully Automated o Architectural analysis can be considered fully automatable o It means it is possible to complete them without human involvement

System Stakeholders o Stakeholders in a software project will have different objectives o Architects Take a global view of the architecture Interested in establishing all four C’s in the architecture Rely on all types of architectural models at all levels of scope o Developers Take a limited view of architecture – modules or subsystem Interested in establishing the consistency of their modules and other parts of the system Interested in using formal model

System Stakeholders o Managers Interested in architecture’s completeness – all requirements are satisfied Interested in architecture’s correctness –the requirements are realized in the architecture and eventually will be realized in the implementation Interested in architecture’s compatibility if the architecture and implementation are close to standards Prefer to use the less formal architecture models o Customers Interested in commissioned system’s completeness and correctness Interested in the system’s compatibility with certain standards

System Stakeholders Interested in overall models and system’s key properties Interested in scenario-driven assessment of the structure, behavior and dynamic characteristic of the system o Vendors Interested in combining of components and connectors Interested in compatibility with certain standards Analysis of the individual elements and their properties

Analysis Techniques o Three categories of architectural analysis techniques: Inspection and review-based Model-based Simulation-based

Inspection and Review-based o Manual techniques o Architectural models are conducted by different human stakeholders to ensure a variety of properties, such as architecture satisfies a given non-functional properties o Architectural models considers to multiple architectural properties. o Useful in the case of informal architectural descriptions o Useful in establishing “soft” system properties, such as scalability or adaptability o Type of analysis for inspections and reviews are static and scenario-based

Inspection and Reviews Analysis Summary o Analysis Goals – any o Analysis Scope – any o Analysis Concern – any, but particularly suited for non-functional properties o Architectural Models – any, but must be covered stakeholder needs and analysis objectives o Analysis Types – mostly static and scenario-based o Automation Level – manual, human intensive o Stakeholders – any, except perhaps component vendors

Example - ATAM o Stands for Architectural Trade-Off Analysis Method. o A human-centric process for identifying risk early in a software design o Two key inputs into the ATAM process : Business drivers and System software architecture. o Project’s manager or customers present the system’s major business drivers, including : 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) goals

o Focuses specifically on four quality attributes (NFPs) Modifiability Security Performance Reliability o Reveals how well an architecture satisfies quality goals and how those goals trade-off

ATAM Process

ATAM Scenarios o Use-case scenarios Describe how the system is envisioned by the stakeholders to be used o Growth scenarios Describe planned and envisioned modifications to the architecture o Exploratory scenarios Try to establish the limits of architecture’s adaptability with respect to system’s functionality Scenarios are prioritized based on importance to stakeholders

ATAM Analysis : Key Steps o Objective is to establish relationship between architectural approaches and quality attributes o For each architectural approach a set of analysis questions are formulated Targeted at the approach and quality attributes in question o 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 o Based on answers, further analysis may be performed

ATAM Analysis Summary o Analysis Goals - completeness, consistency, compatibility, correctness o Analysis Scope – system, system-level and data exchange o Analysis Concern – non-functional o Architectural Models – informal, semi-formal o Analysis Types – scenario-driven o Automation Level – manual o Stakeholders – architects, developers, managers, customers

Model-Based Analysis o Analysis techniques that manipulate architectural description to discover architectural properties o Tool-driven, hence potentially less costly o Typically useful for establishing “hard” architectural properties o Usually focus on a single architectural aspect, such as syntactic correctness o Scalability may be an issue o Techniques typically used in tandem to provide more complete answers

Model-Based Analysis Summary o Analysis Goals – consistency, compatibility, correctness o Analysis Scope – any o Analysis Concern – structural, behavioral, interaction, and possibly non-functional properties o Architectural Models – semi-formal and formal o Analysis Types – static o Automation Level – partially and fully automated o Stakeholders – mostly architects and developers

Model-Based Analysis Enabled by ADLs o ADL stands for Architecture Description Language o ADL parsers and compilers – ensure syntactic and semantic correctness, like Rapide’s generation of executable architectural simulations o Enforcement of constraint, parsers and compilers enforce constraints implicit in type information, non- functional attributes, components and connectors interfaces, and semantic models o Architectural refinement across multiple levels of detail like SADL and Rapide

ADLs Analysis Summary o Analysis Goals – consistency, compatibility, completeness o Analysis Scope – component and connector-level, subsystem and system level, data exchange, different abstraction level, architecture comparison o Analysis Concern – structural, behavioral, interaction, non-functional properties o Architectural Models – semi-formal and formal o Analysis Types – static o Automation Level – partially and fully automated o Stakeholders – architects, managers, developers, customers

Architectural Reliability Analysis o Reliability is the probability that the system will perform its intended functionality under specified design limits, without failure o A failure is the occurrence of an incorrect output as a result of an input value that is received, with respect to the specification o An error is a mental mistake made by the designer or programmer o A 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 function A requirements, design, or implementation flaw or deviation from a desired or intended state

Reliability Metrics o Time to failure o Time to repair o Time between failures

Architecture Level of Assessing Reliability o Challenged by unknowns Failure and recovery history o Challenged by uncertainties Multiple development scenarios Varying granularity of architectural models Different information sources about system usage o Architectural reliability values must be qualified by assumptions made to deal with the above uncertainties o Reliability modeling techniques are needed that deal effectively with uncertainties like Hidden Markov Models (HMMs)

Aspects of Reliability Analysis Summary o Analysis Goals – consistency, compatibility, correctness o Analysis Scope – component and connector-level, subsystem and system level o Analysis Concern – non-functional properties o Architectural Models – formal o Analysis Types – static and Scenario-based o Automation Level – partially automated o Stakeholders – architects, managers, customers, vendors

Simulation-Based Analysis

Simulation-Based Analysis Summary o Analysis Goals – any o Analysis Scope – any o Analysis Concern –behavioral, interaction, and non- functional properties o Architectural Models – formal o Analysis Types – dynamic and scenario-based o Automation Level – fully automated; model mapping may be manual o Stakeholders – any

Example XTEAM o eXtensible Tool-chain for Evaluation of Architectural Models o Targeted at mobile and resource-constrained systems o Combines two general purpose ADLs xADL and FSP To capture important features of mobile system o Implements simulation-based analysis capabilities for One-to-one latency, memory utilization, reliability, energy consumption

XTEAM Analysis Summary o Analysis Goals – consistency, compatibility, correctness o Analysis Scope – component and connector-level, subsystem and system level, data exchange o Analysis Concern – structure, behavior, interaction, non- functional o Architectural Models – formal o Analysis Types – dynamic and Scenario-based o Automation Level – automated o Stakeholders – architects, managers, developer, customers, vendors

Remark points o Architectural analysis is neither easy nor cheap o The benefits typically far outweigh the drawbacks o Early information about the system’s key characteristics is vital o Multiple analysis techniques often should be used in concert o “How much analysis?” This is the key aspect of an architect’s job Too many will expend resources unnecessarily Too few will carry the risk of propagating defects into the final system Wrong analyses will have both drawbacks

Thank you