1. Analysis of Software Architectures

2. What Is Architectural Analysis?
Architectural analysis is the activity of discovering important system properties using the system’s architectural models.
Early, useful answers about relevant architectural aspects
Available prior to system’s construction
Important to know
which questions to ask
why to ask them
how to ask them
how to ensure that they can be answered

3. Case in Point: Distributed Event-Based Systems
Spacecraft
Clock
Highly decoupled
Non-functional properties
Scalability, Adaptability, Heterogeneity
Message-oriented middleware (MOM)
In 2011, $8.7 billion
By 2018, $26.1 billion
Status
Event Connector
At the price of complex maintenance
BurnFuel
Game Logic
GUI

4. Issues with DEB Systems
+ Highly decoupled
+ Non-functional properties
Scalability, Adaptability, Heterogeneity
Obfuscate control and data flow
Hamper system maintenance
DEB Application
Message-Oriented Middleware
Operating System

5. Three Sources of Maintenance Difficulties
Reliance on ambiguous interfaces
Use of attribute-based message types
Unclear message flow

6. 1. Ambiguity of Interfaces
Maintenance Challenges:
1. Ambiguous interfaces
2. Attribute-based message types
3. Message flow
1. Ambiguity of Interfaces
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
consume
Adder

7. 1. Ambiguity of Interfaces
Maintenance Challenges:
1. Ambiguous interfaces
2. Attribute-based message types
3. Message flow
1. Ambiguity of Interfaces
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
add
result
Adder
Message
Dispatching

8. 2. Attribute-Based Message Types
Maintenance Challenges:
1. Ambiguous interfaces
2. Attribute-based message types
3. Message flow
2. Attribute-Based Message Types
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
Consumed Message
“name” : “add”
add
result
Adder
“num1”
“num2”
Message type is scattered

9. 3. Message Flow public class Adder extends Component{ …
Maintenance Challenges:
1. Ambiguous interfaces
2. Attribute-based message types
3. Message flow
3. Message Flow
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
Consumed Message
add
result
“name” : “add”
“num1”
“num2”
sum
Published Message
“name” : “sum”
“val”

10. Resulting Technique – Eos
Goal - Determine message flow for attribute-based systems
Consumed
Attribute-Based Message Types
MOM Specification
Eos
Insight – Message Revealing statements
Published
Attribute-Based Message Types
DEB System Implementation
Message Flow

11. Identifying Consumed Message Types (CMTs)
For each method m
Identify the message object that is consumed
Determine attributes extracted from the message object along program paths
Define message types based on sets of attributes

12. CMT Example Adder public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
Consumed Message
add
result
Adder
“name” : “add”
“name”
“num1”
“num2”
sum

13. Identifying Published Message Types (PMTs)
For each method m
Identify creation of message objects
Determine attributes added to message objects
Track if message objects reach publish statement

14. Must reach publish statement
PMT Example
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
Message
“name” : “sum”
“val”
add
result
Adder
sum
Must reach publish statement

15. Identifying Message Flow
Message flow represented by message dependencies
Intra-flow dependencies
Inter-flow dependencies
Adder
add
result
sum
Printer
sum
sum

16. Identifying Intra-Flow Dependencies
Goal: Within a component, identify types published as a result of types consumed
For each published message type
Identify the statement at which the type is published
Determine the consumed types that flow into the statement
Create dependencies between the consumed types and the published types

17. Intra-Flow Dependency Example
public class Adder extends Component{ …
public void consume(Message m) {
String nameAttr = (String)m.getAttr("name");
if ("add".equals(nameAttr)) {
Message sumMsg = this.add(m);
this.publish(sumMsg);}
else if ("result".equals(nameAttr)){
…}}
private Message add(Message m3){
Integer n1 = m3.getAttr("num1");
Integer n2 = m3.getAttr("num2");
sum = n1 + n2;
Message m4 = new Message();
m4.setAttribute("name", "sum");
m4.setAttribute("val", sum);
return m4;}
Consumed Message
add
result
“name” : “add”
tadd
“num1”
tadd
“num2”
sum
intra
Published Message
“name” : “sum”
“val”
tadd
tadd
tadd
tadd
tadd

18. Identifying Inter-Flow Dependencies
Goal: Identify pairs of components that communicate with each other
How: Match published and consumed types of the components
Definition of “match”: Published type provides superset of a consumed type’s attributes

19. Simple Inter-Flow Dependency Example
Adder’s Published Message
Adder
“name” : “sum”
“val”
sum
inter
Printer
sum
Printer’s Consumed Message
“name” : “sum”
“val”

20. Subtle Inter-Flow Dependency Example
Adder’s Published Message
Adder
“name” : “sum”
“val”
sum
inter
Printer
sum
Printer’s Consumed Message
“name” : “sum”

21. All Information Identified for Our Example
Adder
Consumed Message
Consumed Message
“name” : “add”
“name” : “result”
“num1”
“num2”
Printer
intra
intra
Published Message
“name” : “sum”
“val”
Published Message
“name” : “sum”
“val”
Published Message
“name” : “lastResult”
“val”
inter

22. Informal Architectural Models and Analysis
Helps architects get clarification from system customers
Helps managers ensure project scope
Not as useful to developers
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

23. Formal Architectural Models and Analysis
Component UserInterface
Port getValues
Port calculate
Computation
Connector Call
Role Caller =
Role Callee =
Glue =
Configuration LunarLander
Instances
DS : DataStore
C : Calculation
UI : UserInterface
CtoUIgetValues, CtoUIstoreValues, UItoC, UItoDS : Call
Attachments
C.getValues as CtoUIgetValues.Caller
DS.getValues as CtoUIgetValues.Callee
C.storeValues as CtoUIstoreValues.Caller
DS.storeValues as CtoUIstoreValues.Callee
UI.calculate as UItoC.Caller
C.calulate as UItoC.Callee
UI.getValues as UItoDS.Caller
DS.getValues as UItoDS.Callee
End LunarLander.
Helps architects determine component composability
Helps developers with implementation- level decisions
Helps with locating and selecting appropriate OTS components
Helps with automated code generation
Not as useful for discussions with non- technical stakeholders
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

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

25. Architectural Analysis Goals
The four “C”s
Completeness
Consistency
Compatibility
Correctness

26. Architectural Analysis Goals – Completeness
Completeness is both an external and an internal goal
It is external with respect to system requirements
Challenged by the complexity of large systems’ requirements and architectures
Challenged by the many notations used to capture complex requirements as well as architectures
It is internal with respect to the architectural intent and modeling notation
Have all elements been fully modeled in the notation?
Have all design decisions been properly captured?

27. Architectural Analysis Goals – Consistency
Consistency is an internal property of an architectural model
Ensures that different model elements do not contradict one another
Dimensions of architectural consistency
Name
Interface
Behavior
Interaction
Refinement

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

29. 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)
ProvInt2: getSubQ(Natural first, Natural last, Boolean remove)
returns Queue;

30. 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?
Example: QueueClient and QueueServer components
QueueClient – getFront
precondition q.size > 0;
postcondition ~q.size = q.size;
QueueServer – getFront
precondition q.size > 1;
postcondition ~q.size = q.size - 1;

31. Interaction Consistency
Names, interfaces, and behaviors of interacting components may match, yet they may still be unable to interact properly
Example: QueueClient and QueueServer components
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

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

33. Refinement Consistency Example
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

34. Architectural Analysis Goals – Compatibility
Compatibility is an external property of an architectural model
Ensures that the architectural model adheres to guidelines and constraints of
a style
a reference architecture
an architectural standard

35. Architectural Compatibility Example – Lunar Lander
What is the style of this architecture?
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

36. Architectural Analysis Goals – Correctness
Correctness is an external property of an architectural model
Ensures that
the architectural model fully realizes a system specification
the system’s implementation fully realizes the architecture
Inclusion of OTS elements impacts correctness
System may include structural elements, functionality, and non-functional properties that are not part of the architecture
The notion of fulfillment is key to ensuring architectural correctness

37. Scope of Architectural Analysis
Component- and connector-level
Subsystem- and system-level
Beware of the “honey-baked ham” syndrome
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

38. Data Exchange Example
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

39. Architectures at Different Abstraction Levels
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

40. Architectural Concern Being Analyzed
Structural characteristics
Behavioral characteristics
Interaction characteristics
Non-functional characteristics

41. Level of Formality
Informal models
Semi-formal models
Formal models

42. Type of Analysis Static analysis Dynamic analysis
Scenario-driven analysis
Can be both static and dynamic

43. Level of Automation
Manual
Partially automated
Fully automated

44. Analysis Stakeholders
Architects
Developers
Managers
Customers
Vendors

45. Architectural Analysis in a Nutshell
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.