Upload
horia-constantin
View
293
Download
7
Embed Size (px)
DESCRIPTION
Improved slides from the Software Architecture: Foundations, Theory, and Practice book.
Citation preview
Software Architecture: Foundations, Theory, and Practice
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Analysis of Software Architectures
Software ArchitectureHoria Constantin & original
authors
Software Architecture: Foundations, Theory, and Practice
2
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Objective: Not needing to read that chapter of the book unless you have a really specific question.
Assumption: minimal participation from you
Tip for not getting bored: ASK QUESTIONS whenever something is unclear.
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis in a Nutshell
3
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
4
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 know1. which questions to ask2. why to ask them3. how to ask them4. how to ensure that they can be answered
5
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
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
Software Architecture: Foundations, Theory, and Practice
8
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals
The four “C”s Completeness Consistency Compatibility Correctness
9
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
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
Software Architecture: Foundations, Theory, and Practice
Consistency fun test incoming
12
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
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
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
Software Architecture: Foundations, Theory, and Practice
Interaction Consistency
16
Names, interfaces, and behaviors of interacting components may match, yet they may still be unable to interact properly
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
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
Software Architecture: Foundations, Theory, and Practice
Refinement Consistency Example
18
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
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
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
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
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals?
The four “C”s – TEST C _ _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _
22
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
Software Architecture: Foundations, Theory, and Practice
Data Exchange Example
24
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Open question: How would you fix this?
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
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
Software Architecture: Foundations, Theory, and Practice
Level of Formality
Informal models Semi-formal models Formal models
27
Software Architecture: Foundations, Theory, and Practice
Informal Architectural Models and Analysis
Helps architects get clarification from system customers
Helps managers ensure project scope
Not as useful to developers
28
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Formal Architectural Models and Analysis
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
29
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Component UserInterface Port getValues Port calculate ComputationConnector 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.CalleeEnd LunarLander.
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
Software Architecture: Foundations, Theory, and Practice
Level of Automation
Manual Partially automated Fully automated
31
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 SemiAbbr Name
Cnst Consistency
Comp Compatibility
Cmplt Completeness
Corr Correctness
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
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