Your SlideShare is downloading. ×
Analysis of software architectures
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Analysis of software architectures

244
views

Published on

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

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

Published in: Technology, News & Politics

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
244
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Completeness Consistency Compatibility Correctness
  • 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.
  • Transcript

    • 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. 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. 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. Software Architecture: Foundations, Theory, and Practice 4
    • 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
    • 8. Software Architecture: Foundations, Theory, and Practice 8
    • 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
    • 12. Software Architecture: Foundations, Theory, and Practice Consistency fun test incoming 12
    • 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
    • 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. 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. 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. 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
    • 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. 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
    • 27. Software Architecture: Foundations, Theory, and Practice Level of Formality  Informal models  Semi-formal models  Formal models 27
    • 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. 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. 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. Software Architecture: Foundations, Theory, and Practice Level of Automation  Manual  Partially automated  Fully automated 31
    • 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