Software Architecture: Foundations, Theory, and Practice
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dash...
Software Architecture: Foundations, Theory, and Practice
2
Software Architecture: Foundations, Theory, and Practice; Richa...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis in a Nutshell
3
Software Architecture: Fou...
Software Architecture: Foundations, Theory, and Practice
4
Software Architecture: Foundations, Theory, and Practice
What Is Architectural Analysis?
 Architectural analysis is the a...
Software Architecture: Foundations, Theory, and Practice
Take home! – summary slide
 Analysis means:
Setting a goal (what...
Software Architecture: Foundations, Theory, and Practice
What is the purpose of analysis?
 Early (before development), us...
Software Architecture: Foundations, Theory, and Practice
8
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals
 The four “C”s
Completeness
Consist...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Completeness
 Does the architectu...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Consistency
 Ensures that differe...
Software Architecture: Foundations, Theory, and Practice
Consistency fun test incoming
12
Software Architecture: Foundations, Theory, and Practice
Name Consistency
 Component and connector names
 Component serv...
Software Architecture: Foundations, Theory, and Practice
Interface Consistency
 Encompasses name consistency
 Also invol...
Software Architecture: Foundations, Theory, and Practice
Behavioral Consistency
 Names and interfaces of interacting comp...
Software Architecture: Foundations, Theory, and Practice
Interaction Consistency
16
 Names, interfaces, and behaviors of ...
Software Architecture: Foundations, Theory, and Practice
Refinement Consistency
 Architectural models are refined during ...
Software Architecture: Foundations, Theory, and Practice
Refinement Consistency Example
18
Software Architecture: Foundati...
Software Architecture: Foundations, Theory, and Practice
Consistency test?
19
A. Dequeue function in one interface only
po...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Compatibility
 Ensures that the a...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals –
Correctness
 Ensures that
1. the ...
Software Architecture: Foundations, Theory, and Practice
Architectural Analysis Goals?
 The four “C”s – TEST
C _ _ _ _ _ ...
Software Architecture: Foundations, Theory, and Practice
Scope of Architectural Analysis
 Component- and connector-level
...
Software Architecture: Foundations, Theory, and Practice
Data Exchange Example
24
Software Architecture: Foundations, Theo...
Software Architecture: Foundations, Theory, and Practice
Scope of Architectural Analysis
 Component- and connector-level
...
Software Architecture: Foundations, Theory, and Practice
Architectural Concern Being
Analyzed
 Structural characteristics...
Software Architecture: Foundations, Theory, and Practice
Level of Formality
 Informal models
 Semi-formal models
 Forma...
Software Architecture: Foundations, Theory, and Practice
Informal Architectural Models
and Analysis
 Helps architects get...
Software Architecture: Foundations, Theory, and Practice
Formal Architectural Models and
Analysis
 Helps architects
deter...
Software Architecture: Foundations, Theory, and Practice
Type of Analysis
 Static analysis (e.g. compilers)
 Dynamic ana...
Software Architecture: Foundations, Theory, and Practice
Level of Automation
 Manual
 Partially automated
 Fully automa...
Software Architecture: Foundations, Theory, and Practice
Analysis Stakeholders – different
views
32
Stakeholder Goal Scope...
Software Architecture: Foundations, Theory, and Practice
Project Management triangle
 Where is the economical
analysis?
...
Software Architecture: Foundations, Theory, and Practice
Take home! – summary slide
 Analysis means:
Setting a goal (what...
Prochain SlideShare
Chargement dans…5
×

Analysis of software architectures

759 vues

Publié le

Improved slides from the Software Architecture: Foundations, Theory, and Practice book.

  • Soyez le premier à commenter

Analysis of software architectures

  1. 1. Software Architecture: Foundations, Theory, and Practice Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Analysis of Software Architectures Software Architecture Horia Constantin & original authors
  2. 2. 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.
  3. 3. 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.
  4. 4. Software Architecture: Foundations, Theory, and Practice 4
  5. 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. 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. 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
  8. 8. Software Architecture: Foundations, Theory, and Practice 8
  9. 9. Software Architecture: Foundations, Theory, and Practice Architectural Analysis Goals  The four “C”s Completeness Consistency Compatibility Correctness 9
  10. 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. 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
  12. 12. Software Architecture: Foundations, Theory, and Practice Consistency fun test incoming 12
  13. 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. 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. 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
  16. 16. 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.
  17. 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
  18. 18. 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.
  19. 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. 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. 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. 22. Software Architecture: Foundations, Theory, and Practice Architectural Analysis Goals?  The four “C”s – TEST C _ _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _ _ _ C _ _ _ _ _ _ _ _ _ _ 22
  23. 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
  24. 24. 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?
  25. 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. 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
  27. 27. Software Architecture: Foundations, Theory, and Practice Level of Formality  Informal models  Semi-formal models  Formal models 27
  28. 28. 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.
  29. 29. 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 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.
  30. 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
  31. 31. Software Architecture: Foundations, Theory, and Practice Level of Automation  Manual  Partially automated  Fully automated 31
  32. 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. 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. 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

×