1. 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; 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)

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 B C 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