5. Software Architecture: Foundations, Theory, and Practice
What Is Architectural Analysis?
Architectural analysis 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
5
6. Software Architecture: Foundations, Theory, and Practice
Take home! – summary slide
Analysis means:
Setting a goal (what do we want to analyze?)
Defining the scope (what area are we focusing on?)
Defining the concern – not sure about this one
Establishing the formality level
(optional) Analysis type/automation?(how will the
analysis be done?)
Don’t forget about the economical analysis of
architecture!
6
7. Software Architecture: Foundations, Theory, and Practice
What is the purpose of analysis?
Early (before development), useful answers about
relevant architectural aspects
discover components to be grabbed off the shelf.
Just having the architecture is not enough…
7
9. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals
The four “C”s
Completeness
Consistency
Compatibility
Correctness
9
10. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Completeness
Does the architecture capture all of a system's key
functional and non-functional requirements?
Have all elements been fully modeled in the notation?
Have all design decisions been properly captured?
10
Client Client Client
Server
Incomplete!
Client Client
Server
Complete
Client
Server
11. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Consistency
Ensures that different model elements do not
contradict one another
Dimensions of architectural consistency
Name
Interface
Behavior
Interaction
Refinement
11
13. Software Architecture: Foundations, Theory, and Practice
Name Consistency
Component and connector names
Component service names
May be non-trivial to establish at the architectural level
Multiple system elements/services with identical
names
Loose coupling via publish-subscribe or
asynchronous event broadcast
Dynamically adaptable architectures
13
14. Software Architecture: Foundations, Theory, and Practice
Interface Consistency
Encompasses name consistency
Also involves parameter lists in component services
A rich spectrum of choices at the architectural level
Example: matching provided and required interfaces
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;
14
15. Software Architecture: Foundations, Theory, and Practice
Behavioral Consistency
Names and interfaces of interacting components may match, but
behaviors need not
Example: subtraction
subtract(Integer x, Integer y) returns Integer;
Can we be sure what the subtract operation does?
15
17. Software Architecture: Foundations, Theory, and Practice
Refinement Consistency
Architectural models are refined during the design
process
A relationship must be maintained between higher and
lower level models
All elements are preserved in the lower level model
All design decisions are preserved in the lower-level
model
No new design decisions violate existing design
decisions
17
19. Software Architecture: Foundations, Theory, and Practice
Consistency test?
19
A. Dequeue function in one interface only
polls the queue and the other one also
removes the element
B. Interface present in Product Architecture
is missing in the zoomed-in module
architecture
C. Invoke an operation after a close event or
before a component has been initialized
D. Included in another type
E. Client: getSubQ(Natural first, Natural
last, Boolean remove) Server:
getSubQ(Index first, Index last)
1. Name
2. Interface
3. Behavior
4. Interaction
5. Refinement
20. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Compatibility
Ensures that the architectural model adheres to
guidelines and constraints of
a style
a reference architecture
an architectural standard
20
21. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Correctness
Ensures that
1. the architectural model fully realizes a system
specification
2. the system’s implementation fully realizes the
architecture
Inclusion of OTS elements impacts correctness – what
proposition is not respected?
21
22. Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals?
The four “C”s – TEST
C _ _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _
22
23. Software Architecture: Foundations, Theory, and Practice
Scope of Architectural Analysis
Component- and connector-level
Subsystem- and system-level
Data exchanged in a system or subsystem
Data structure
Data flow
Properties of data exchange
Architectures at different abstraction levels
Comparison of two or more architectures
Processing
Data
Interaction
Configuration
Non-functional properties
23
25. Software Architecture: Foundations, Theory, and Practice
Scope of Architectural Analysis
Component- and connector-level
Subsystem- and system-level
Data exchanged in a system or subsystem
Data structure
Data flow
Properties of data exchange
Architectures at different abstraction levels
Comparison of two or more architectures
25
26. Software Architecture: Foundations, Theory, and Practice
Architectural Concern Being
Analyzed
Structural characteristics
Behavioral characteristics
Interaction characteristics
Non-functional characteristics
Food for thought: does this classification add any value?
26
30. Software Architecture: Foundations, Theory, and Practice
Type of Analysis
Static analysis (e.g. compilers)
Dynamic analysis (executing the model)
Scenario-driven analysis
Can be both static and dynamic
30
32. Software Architecture: Foundations, Theory, and Practice
Analysis Stakeholders – different
views
32
Stakeholder Goal Scope Formality
Architect All All All
Developer Cnst, comp C&C, subsystem Semi, formal
Manager Cmplt, corr, comp ??? Informal
Customer Cmplt, corr ??? Informal
Vendor comp C&C Semi
Abbr Name
Cnst Consistency
Comp Compatibility
Cmplt Completeness
Corr Correctness
33. Software Architecture: Foundations, Theory, and Practice
Project Management triangle
Where is the economical
analysis?
See Chapter 23 from
Software Architecture in
Practice (3rd Edition)
Cost Benefit Analysis
Method – method with 9
activities
33
34. Software Architecture: Foundations, Theory, and Practice
Take home! – summary slide
Analysis means:
Setting a goal (what do we want to analyze?)
Defining the scope (what area are we focusing on?)
Defining the concern – not sure about this one
Establishing the formality level
(optional) Analysis type/automation?(how will the
analysis be done?)
Don’t forget about the economical analysis of
architecture!
34
Hinweis der Redaktion
I read the chapter twice and the whole book once.
As you will listen to me going through the concepts I’m sure that you will see the analysis is not something really complex. Arthur Dent : “I think we have different value systems.” Ford Prefect : “Well mine’s better.” — Douglas Adams, Mostly Harmless
4c c&c, system level, data or arch vs arch? Analysis type – static/dynamic, use case.
can help identify inappropriate or incorrect design decisions after you’ve created it, it will change and for that, you need to think about it, to analyze it and see how the new requirements fit the old arch. Analysis is usually a default action when you have an architecture.
The image that I’ve always missed from the book… the real reason for which we have software architecture. Always during this presentation keep in mind that we are talking about big software products… if you are a startup you definitely don’t need a formal architecture. If you are designing lunar lander, it is definitely not
There is a difference between internal and external… internal is easier and can be automated.
Could happen even if no architectural design decisions are invalidated
Think of a getTime function that is expected to return the current hour and minute, but actually returns the time since the system has been started.
a component's provided operations are accessed in a manner that violates certain interaction constraints They happen when the the component's interaction protocol (state-transition diagrams) is not respected.
Details can be lost when zooming in or out.
Both high and low level elements are incomplete. And once it is a connector, and once a component. But it’s not visible in the picture.
The difficulty of this part depends on the formality by which the guidelines and constraints are specified. If formal it’s easy. This could fail for a ots product that is integrated to an existing architecture.
The architecture takes into account all specifications. The implementation fully realizes the architecture and nothing more. Second proposition is not respected. System may include structural elements, functionality, and non-functional properties that are not part of the architecture
Scope – what will the analysis focus on? Comp & connector - a full analysis of the interfaces as well as its connection to the next element Subsystem- and system-level composition of components at system or subsystem level. How there components interact with each other (What sometimes happens is that you have a component with some characteristics that are good, but you integrate it with another with also good characteristics, but the 2 are incompatible and cancel each others advantages.) caching component vs real time data component Data exchanged in a system or subsystem such as typed versus untyped or discrete versus streamed point-to-point versus broadcast, and any other problems that might appear from this exchange. consistency, security, and latency.
Flow of data and properties of data exchange
Architectures at different abstraction levels - refinement inconsistencies. Comparison of two or more architectures – ensuring the COMPATIBILITY of a given system's architecture with a reference architecture/style/pattern encompasses all the previous scopes.
A really short slide… Answers the what are we studying from the architecture question… What it does: architecture is well formed?; adherence to architectural constraints, patterns, and styles; system concurrency and distribution; connectivity, composition internal behaviours of individual components + the composite behaviour of all to make the desired system behaviour Interaction Characteristics - the numbers and types of distinct software connectors, and their values for different connector dimensions; establish whether the architecture will actually be able to fulfill some of its requirements. Non-Functional Characteristics - cut across multiple components and connectors, which makes them particularly difficult to assess. architectural analysis techniques focusing on these characteristics are scarce.
What the system's stakeholders want to be able to analyze will influence what software architects capture in their architectural models. Informal Models - boxes-and-lines diagrams support informal and manual analyses by various stakeholders, but they can be ambiguous and lack detail. Semiformal Models - most models used in practice; think of uml that is not 100% precise, but is a lot more precise that native language. Analysis can be manual or partially automated. Formal Models - formally defined syntax, formally defined semantics; automated analysis only for technical stakeholders; in practice they have scalability problems because they are hard to create.
Go for the easy one... just thinking about it for a while can make problems emerge and you can fix them in the planning stage, when the cost is minimum. (native language or even visio diagrams)
(semantics and syntactic rules). Remember that automated code generation still requires that templates are made by the developers.
Static Analysis - inferring the properties of a software system from one or more of its models, without actually executing those models; model adheres to the syntactic rules of the modeling notation. Good for all models. Dynamic Analysis - executing or simulating the execution of a model of the software system; the system semantics should be executable. Scenario-Based Analysis - For large and complex software systems, specific-use cases are identified that represent the most important or most frequently occurring system usage scenarios, and the analysis is focused on those
In general, an architectural model provided in a more formal notation will be more amenable to automated analysis than a model provided in a more informal notation Manual - requires significant human involvement, expensive; many non-functional properties, which are critical to the success of most all software systems, are understood at the level of intuition, anecdote, and informal guideline; requires a detailed process that must be followed by the system architects and other stakeholders participating in the analysis. Partially Automated - Most architecture modeling notations presented in Chapter 6 are amenable to ensuring a given architectural description's syntactic correctness, as well as different degrees of semantic correctness Fully Automated - in practice, fully automated architectural analysis techniques must be combined with other techniques, which themselves may need human intervention, in order to get more comprehensive answers.
You have heard a lot about arch analysis. Listen to what you should be taking home. 4c c&c, system level, data or arch vs arch? Analysis type – static/dynamic, use case.