1. Architectural Analysis

2. Introduction Models help to force the architects to identify issues that might missed or ignored To get useful information precisely from specific model helps in identifying incorrect decisions before they get propagated to implementation phase Identifying these aspects from model is architectural analysis Stakeholders need to know how to extract those details

3. Definition Architectural Analysis: It is the activity of discovering important system properties using the system’s architectural models. Important to know 1.which questions to ask 2.why to ask them 3.how to ask them 4.how to ensure that they can be answered

4. Informal architectural models help in identifying scope and goal of architecture Helpful for getting customer clarification, help managerial level Formal or rigorous models are more advantageous They provide detail information about implementation level, helps in automated code generation. Helpful for developer. These models are not helpful in communication with non technical people

5. Concerns Relevant to Architectural Analysis Goals of analysis (why) Scope of analysis (what) Primary architectural concern being analyzed Level of formality of architectural models Type of analysis Level of automation System stakeholders interested in analysis 5

6. Analysis Goals Analysis of software model can have several goals These goals may include early estimation of system’s size, complexity, cost; satisfaction of system requirements; correctness of system as per requirements These goals are categorized in 4 categories: – Completeness – Consistency – Compatibility – Correctness

7. Completeness Completeness can be external or internal External goal is with respect to system’s requirements Whether it captures system’s key functional and non functional requirements Architecture centric systems are complex, dynamic in nature In these complex systems capturing requirements and modeling are also complex and done using various notations of various levels of rigor and formality System’s engineers need to carefully select the points at which external completeness can be assessed meaningfully

8. Analyzing internal completeness include checking whether all the elements have been fully captured Have all elements properly modeled? Have all design decisions properly captured? Syntactic and semantic rules of notations Checking if Everything is captured in models is completeness Completeness

9. Consistency Consistency is an internal property of the system Goal of consistency is different elements of the model do not conflict with each other Software system and their architectural models are complex and multifaceted which inadvertently introduce inconsistency Examples of inconsistency: – Name Inconsistency – Interface Inconsistency – Behavioral Inconsistency – Interaction Inconsistency – Refinement Inconsistency

10. Name inconsistency – It appears at the level of components and connectors – Components and connectors having same name or the services exported by a component have same name – At programming level identifying name inconsistency is easier e.g. variables with same name are not accepted, trying to use function name which is a name of inbuilt function – At documentation level it is difficult to identify name inconsistency – Architecture is highly adaptable and dynamic. One component or service present at one level may be not in use at next point of time and might be available after some time – Managing this is difficult task Name Inconsistency

11. Interface Inconsistency: interface inconsistency encompass name inconsistency. Name inconsistency is subset of interface inconsistency Component’s required service may have same name as another component’s provided service but parameter list, return type are different Consistency in terms of interface is not present Interface Inconsistency

12. Inconsistency in terms of behavior of the system. The name of the required service is same as service provided by other component, data type, return type that is interface are also same but behavior is different Behavioral Inconsistency

13. Interaction inconsistency: Name, interface, behavior matches but still the components are not able to interact properly This may occur because of violating certain constraints like the order in which the service or component should be extracted Refinement inconsistency: inconsistency at multiple levels of abstraction Interaction & refinement Inconsistency

14. Compatibility It is an external property of the system It ensures that model is according to guidelines and constraints of style, reference architecture and an architectural standard Models captured Strictly according to rules are compatible Checking compatibility with Semiformal or informal guideline is challenging Checking compatibility with reference architectures is easy as they are specified formally using ADL Checking compatibility with styles is difficult and challenging

15. Correctness This is external property of the system The systems architecture is said to be correct with respect to an external specification if the architectural design decisions fully realize those specifications Captures all design decisions with their exact meaning

16. Scope of Analysis A software system’s architecture can be analyzed from different perspectives and at different levels Scope tells what will be analyzed Components, connectors, ports can be analyzed Mostly architects are interested in composition, configuration of the system Scope can be at lower level where all small elements will also be analyzed or at higher level where structures or compositions are being analyzed

17. Component and connector level analysis: – Simplest and basic level of analysis – Components and connectors are created to provide specific services – Components: application specific functionality and connectors: application independent functionalities – Analyze these elements provide expected services – Mostly architects are interested in composition of connectors and components – Components and connectors are analyzed to identify basic inconsistencies. It doesn't ensure system’s correct working – Interface can be inspected if any service is missing from expected services Scope of Analysis

18. Subsystem and system level analysis: – Components and connectors desired properties does not guarantee about composition of them will behave as expected – Interplay of components and connectors can be complex – This analysis can be done at a whole system level or incrementally by focusing on particular subsystem – Most manageable level is pair-wise conformance. Two interacting components are considered at a time and name, behavior, interface conformance is done – Then take set of components interacting probably through single connector – And then to higher level of subsystem is analyzed – Example: Data encryption component is intended to provide data security with data compression component with communication efficiency Scope of Analysis

19. Data exchange in a system or subsystem: – In large, distributed systems, large amount of data are processed, exchanged and stored – Data intensive systems appear in wide range like scientific computing,many web based applications, e- commerce and multimedia – In such system along with basic components, it is important to ensure that the system’s data is properly modeled, implemented and exchanged among the structural elements. – Structure of data, flow of data through the system, properties of data exchange Scope of Analysis

20. Architectures at different levels of abstraction: – During the process of architecture creation, architects address most critical issues first, and then introduce additional elements into the architecture – Lastly refine the architecture to include additional details – High level architecture includes overview and lower level architecture includes details – Abstraction is done at proper level or not is analyzed – Sometimes components are more abstract and the properties can not be understand well, whereas sometimes abstraction is at very low level – It has to be verified if it is done at required level or not Scope of Analysis

21. Comparison of two or more architectures: – It is important to understand the relation of architecture with the baseline architecture – Verifying compliance of architecture with reference architecture – This the highest scope of analysis – Complete Architecture is analyzed, whether it is compatible with provided standards, style or reference architecture Scope of Analysis

22. Architectural Concerns Being Analyzed Architectural techniques analyzes different features of the system In practice given analysis technique or suite of techniques focuses more than one architectural concern at a time Different features can be: – Structural characteristics – Behavioral characteristics – Interaction characteristics – Non functional characteristics

23. Structural characteristics : – Concerns such as connectivity among components and connectors, containment of lower level architectural elements with higher level elements are analyzed – Example: missing pathway between components which want to interact, component or subsystems that are disconnected from the rest of architecture Behavioral characteristics: – Individual level behavior is analyzed, where every components behavior is verified – System level behavior is analyzed, where system as a whole is behaving properly or not is verified Architectural Concerns Being Analyzed

24. Interaction characteristics: – Interaction protocol is analyzed – Component interacting through appropriate connector or not is verified Non-functional characteristics: – Forms critical dimensions of almost all software systems – Not properly understood because of their informal nature – Whether all these characteristics are modeled properly is verified Architectural Concerns Being Analyzed

25. Level of Formality of Architectural Models Informal Models – Captured in boxes-lines, diagrams – High level picture of the system – Analyzed manually by stakeholder or non technical people – Have to be analyzed casually

26. Semiformal Models – Most architectural models are semiformal in nature – Syntax is defined formally semantic informally – Notations need to maintain balance between high degree of precision and formality on one hand and expressiveness and understandability on other – UML notations – Partial imprecision makes it difficult to analyzed Level of Formality of Architectural Models

27. Formal Models – Formally defined syntax and semantics – Wright – Formal, automated analysis can be done – Intended for technical stakeholders – Scalability problem and painstaking Level of Formality of Architectural Models

28. Type of Analysis Static Analysis: – Checking properties of model without executing it – It can check syntax of the system – It can be automated or manual – Automated: compilation – Manual: inspection Dynamic Analysis: – Actual execution or simulation of the system – Simulation is dynamic analysis of system where the actual system model is constructed

29. Scenario-Based Analysis: – For complex systems which are very large, specific use cases are selected – This is a combination of static and dynamic analysis – Analyses system statically or dynamically based on the scenario Type of Analysis

30. Level of Automation Different architectural analysis techniques are present at different level of automation Level of automation depends on several factors including formality, completeness etc More formal model is more capable for automated analysis Different level of automation are: – Manual – Partially Automated – Fully Automated

31. Manual: – Human involvement is required – Expensive – Inspection based techniques Partially automated: – Most popular – Involves both manual and automated analysis Fully automated: – Done completely by s/w tools, no human involvement required – Most of the models are semiformal in nature hence this technique individually can not work Level of Automation

32. System Stakeholders Different stakeholders have different objectives All stakeholders have different angles and different purpose of work, analysis done by all is also different Stakeholders: – Architect – Developer – Manager – Customer – Vendor

33. Architects: – Global view and considers all 4 C’s – Prefer automated analysis techniques – Rely on partial and manual techniques also Developers: – Limited view of architecture is considered – Modules or subsystem for which they are directly responsible – Do not bother about completeness – Focus on consistency of their module with other System Stakeholders

34. Manager: – Interested in compatibility and completeness – They are concerned about system’s external properties Customer: – They are interested in systems Completeness and correctness – System’s overall working Vendors: – Vendors sell individual components and connectors rather than the whole system – They are usually interested in compatibility of the system System Stakeholders

35. Analysis Techniques Large number of techniques are available These techniques are divided into three categories – Inspection and review based – Model based – Simulation based

36. Inspection and Review Based These are usually code analysis techniques Reviews and inspection is conducted by different stakeholders to ensure different properties of the system Different views are inspected for specific properties In architecture review board, all stakeholders defines the objective of analysis Stakeholder in review board decides goal and scope of analysis along with other dimensions These are manual analysis and hence expensive Useful in informal or semiformal models

37. Goal: It can have any of 4 goals, 4 C’s Scope: nothing specific. Stakeholders may be interested in component and connector level or system level. Scope can be data exchange or level of abstraction Concerns: well suited for non functional type of properties where manual interpretation is required. structural, behavioral and interaction concerns are difficult to analyze manually. Inspection and Review Based

38. Level of formality: Informal models can be best analyzed. Highly formal models are not useful to non technical stakeholders. But they can be analyzed by technical stakeholders Type of analysis: Static and scenario based Automation level: Manual obviously Stakeholders: All stakeholders participate in inspection and review except vendors Inspection and Review Based

39. Architectural Trade-off Analysis Method It was designed to identify risk in software design at early phase of the development cycle ATAM mainly focuses on quality attributes or non functional properties Gathering of software architects, other stakeholders and evaluation team is required The ATAM gets its name because it not only reveals how well an architecture satisfies particular quality goals, but it also provides insight into how those quality goals interact with each other—how they trade off against each other. The whole process take 3-4 days

40. Business Drivers Quality Attributes Scenarios S/W Architecture Arch Approaches Arch Decisions Trade-Off Sensitivity Points Non-Risk RiskRisk Themes Analysis Architectural Trade-off Analysis Method

41. Two major inputs are business drivers and system’s software architecture Project decision makers (mostly manager and customer) presents business drivers Business drivers includes: – System’s critical functionality – Any technical, managerial, economical or political constraints – The projects business goals and context – The major stakeholders – The principal quality attribute (NFP) goals that impact and shape the architecture Architectural Trade-off Analysis Method

42. The quality attributes identify and categorize business drivers into representative scenario – Use case scenario: describes how system is seen – Growth scenario: describes how the modification or changes are described – Exploratory scenario: establish limits of adaptability These scenarios are prioritized in terms of importance by the system’s stakeholders Another thread involves software project’s architecture Architectural Trade-off Analysis Method

43. Projects architecture includes: – Technical constraints = hardware platform, O.S., middleware, programming languages – Architectural approach: refers to any other set of architectural design decisions made to solve the problem at hand. Typically styles and pattern Based on the answers the category will be decided like risk, no risk, sensitivity point or trade-off Architectural Trade-off Analysis Method

44. Model Based Analysis Solely rely on system’s architectural description and manipulate that description to discover properties of architecture techniques involve analysis tools which are guided by the architects Much less human intensive hence less costly Only hard properties can be analyzed which can be encoded in a model Properties which has to be understood from available information can not be analyzed

45. Model based techniques can not handle soft aspects like rationale or intent of architecture Focus on single specific facet of the system’s architecture It is not scalable Goal: Consistency, compatibility and internal completeness. It does not include external completeness and correctness Does not provide all the needed answers to an architect and couple with techniques from two other categories Model Based Analysis

46. Scope: Span can be component and connector level to whole system level Concerns: structural, behavioral and interaction properties. Analyzing behavioral and interaction properties it takes help of simulation based technique Type of Models: Formal models are best analyzed. Informal models are not specifically of any use. Model Based Analysis

47. Type of Analysis: static analysis. Works on architectural description Automation level: partially automated is minimum requirement. Fully automated is best suited Stakeholders: technical stakeholders namely architects and developers Model Based Analysis

48. Simulation Based Analysis It requires dynamic executable model of a given system or of a part of a system Simulation need not produce similar results as of execution Results of simulation are ranges rather than a particular value Goal: goal can be any of 4 C’s. but with limited confidence Scope: usually entire system or a particular subsystem. Lover level analysis is possible but usually not preferable

49. Concerns: behavioral and interaction concerns are best analyzed Level of formality: formal models are expected Type of Analysis: dynamic or scenario based Level of automation: fully automated Stakeholders: all type of stakeholders can take participation, but technical expertise are needed of setting up the analysis Simulation Based Analysis