1. Chapter 8 Analysis Zachary Cleaver

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

3. Facets of Architectural Analysis • 1) Goals of analysis • 2) Scope of analysis • 3) Primary architectural concerns being analyzed • 4) Level of formality between models

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

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

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

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

8. 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;

9. Behavioral Inconsistency Subtract(int x, int y) returns int; intmyVal = Subtract(427, 27) • The method behavior treats it as a date subtraction, subtracts 27 days from April 27, and returns 331 (March 31)

10. Interaction Inconsistency • Occurs when a component’s provided operations are accessed in a manner that violates certain interaction constraints. • Ex. pop_back() in c++

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

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

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

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

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

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

17. 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.)

18. Architecture at Different Abstraction Levels A C B D

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

20. Architectural Concern Being Analyzed • Structural Characteristics • Behavioral Characteristics • Interaction Characteristics • Non-functional Characteristics

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

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

23. 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)

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

25. Level of Formality of Architectural Models • Informal • Semiformal • Formal

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

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

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

29. Chapter 8 Analysis Kata Morovat

30. Outline • Type of Analysis • Level of Automation • System Stakeholders • Analysis Techniques

31. Type of Analysis • Static Analysis • Dynamic Analysis • Scenario-Based Analysis

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

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

34. Dynamic Analysis - Definition • Dynamic analysis involves the execution or simulation the execution of a model of the software system

35. Dynamic Analysis - Example • State- transition diagrams

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

37. Level of Automation • Depends on the completeness of the architectural model and property being defined • 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

38. Level of Automation – Manual Analysis • Manual analysis requires human involvement. • This can be used when multiple clashing properties must be ensured in tandem • Many manual analysis techniques are used for specifying a detail process • 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

39. Manual Analysis - Example • Inspection-based techniques falls in Manual analysis category • One well-known example is architecture trade-off analysis method

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

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

42. System Stakeholders • Stakeholders in a software project will have different objectives • 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 • 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

43. System Stakeholders • 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 • Customers • Interested in commissioned system’s completeness and correctness • Interested in the system’s compatibility with certain standards

44. 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 • Vendors • Interested in combining of components and connectors • Interested in compatibility with certain standards • Analysis of the individual elements and their properties

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

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

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

48. Example - ATAM • Stands for Architectural Trade-Off Analysis Method. • A human-centric process for identifying risk early in a software design • Two key inputs into the ATAM process : Business drivers and System software architecture. • 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

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

50. ATAM Process