Chapter 8 Analysis

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