A Survey on Software Architecture Analysis Methods Liliana Bobrica and Eila Niemela IEEE TOSE July 02 740f02presentations22 1 Group 1 and 6 740f02presentations22 2 Software Architecture Analysis Methods Presented By CIS 740 Instructor: Dr. David A. Gustafson 740f02presentations22 1. 2. 3. 4. 5. 6. 7. 8. 9. Vikranth Vaddi Hong Zhang Sudarshan Kodwani Travis Stude Sandeep Pujar Abhinav Pradhan Srinivas Kolluri Kiran Devaram Saravana Kumar 3 Why focus on Architecture…..! purpose & goals Software Architecture definition: “A high level configuration of system components and the connections that coordinate component activities” Architecture is often the first artifact that represents decisions on how requirements of all types are to be achieved.As the manifestation of early design decisions that are hardest to change. SAAM’s goals is to verify basic architectural assumptions and principles against the documents describing the desired properties of any application. SAAM (software) permits the comparison of architectures within the context of any organization’s particular needs. The purpose of SAAM is not to criticize or commend particular architectures, but to provide a method for determining which architecture supports an organization's needs. A good understanding of system design at the architectural level makes it easier to detect design errors early on and easier to modify the system later. 740f02presentations22 4 Background SAAM appeared in 1993, corresponding with the trend for a better understanding of general architectural concepts, as a foundation for proof that a software system meets more than just functional requirements. Establish a method for describing and analyzing software architectures. SAAM was initially developed for application early in design, it is validated in an analysis of several existing industrial systems. Fig. 1. SAAM inputs and activities. 740f02presentations22 5 Evaluating Architectures based on Software Quality Evaluating Architectures is difficult Motivation : Software Quality factors Maintainability Portability Modularity Reusability Perspective : Functionality Structure – Lexicon describing structure Allocation 740f02presentations22 6 Main Activities Characterize a canonical functional partitioning for the domain Map the functional partitioning onto the architecture’s structural decomposition Choose a set of quality attributes with which to assess the architecture Choose a set of concrete tasks which test the desired quality attributes Evaluate the degree to which each architecture provides support for each task. 740f02presentations22 7 Perspectives Functionality: What the system does Structure: How a system is constructed from smaller pieces • Components - represent computational entities • Connections – connections between components Allocation: - how intended functionality is achieved by the developed system. - differentiates architectures within a given domain 740f02presentations22 8 Lexicon for describing structure 740f02presentations22 9 Canonical functional partitioning The Arch/Slinky metamodel Five • • • • • basic functions of user interface software Functional Core (FC) Functional Core Adapter (FCA) Dialogue (D) Logical Interaction (LI) component Physical Interaction (PI) component 740f02presentations22 10 Serpent 740f02presentations22 11 Analyzing Architectural Qualities Evaluate User Interface Architecture with respect to modifiability Example Modifications • Adaptation to new operating environments • Extension of capabilities 740f02presentations22 12 Analysis of Candidate system Changing the toolkit • Modification to the dialogue manager • No architectural support Adding a menu option • Easier to isolate because view controllers subdivide Dialogue Manager • Therefore Architectural support Provided 740f02presentations22 13 Scenario-Based Analysis Of Architecture Why Scenarios..? • 740f02presentations22 14 Scenarios Because……! • Scenarios offer a way to review the vague quality attributes ( modifiability security, safety or portability) in more specific circumstances by capturing system use contexts. • Developers can analyze the architecture with respect to how well or how easily it satisfies the constraints imposed by each scenario. • Scenarios help visualize the candidate architecture with various perspectives System operator System designer and modifier System administrator • Scenarios force designers to consider the future uses of, and changes to the system. • Designers would have to think on the lines of how the architecture will accommodate a particular change in the system and not what degree a system can be modified. 740f02presentations22 15 Scenario Based - SAAM Methodology •Describe the candidate architecture •Develop Scenarios •Evaluate each scenario •Reveal scenario interaction •Weight scenarios & Scenario interaction 740f02presentations22 16 Scenario Based - SAAM Methodology •Describe the candidate architecture: • Develop Scenarios: • Evaluate each scenario: Each scenario should be classified into direct or indirect scenario. Direct Scenario: no architectural changes required. Indirect Scenario: architectural changes required. •Reveal scenario interaction: Weight scenarios & Scenario interaction: 740f02presentations22 17 Architecture -WRCS 740f02presentations22 18 Steps in Analysis Describe the candidate architecture: Figure 3 shows the architecture Develop Scenarios: For the user role, scenario included – Compare binary file representations – Configure the toolbar – Manage multiple projects • For the Maintainer role, scenarios include – Port to another OS – Modify the user interface in minor ways • For the administrator role, scenarios included – Change access permissions for a project – Integrate WRCS functionality with a new development environment – Port to a different network-management system 740f02presentations22 19 Scenario Evaluation Scenario Direct/Indirect Required Changes Modify the user interface in minor ways Indirect Change access permissions from a project Integrate with a new development environment Direct Indirect Modify hook and add a module along the lines of bcext, mcext, and vbext Port to a different network-management system Indirect Modify wrcs 740f02presentations22 Table 1 B Modify one or more components that call the win31 API, specifically main, diff, and ctrls. 20 Interaction By Module Module Number of Changes wrcs 7 main 4 book 4 visdiff 3 ctris 2 report, diff, bindiff, pvcs2rcs, sccs2rcs, nwcalls, nwspxipx, nwnlm 1 each Table 2 740f02presentations22 21 Fish-Eye Representation 740f02presentations22 22 Advantages Enhanced Communication Improvement of Traditional Metrics Proper Description Level Efficient Scenario Generation Deepened Understanding of the System Ability to make high-level comparisons of competing designs and to document those comparisons Ability to consider and document effects of sets of proposed system changes 740f02presentations22 23 References SAAM: A Method for Analyzing the Properties of Software Architecture Scenario-Based Analysis of Software Architecture 740f02presentations22 24 Thank You 740f02presentations22 25 How to apply ATAM (Group 2 and 7) Billy Alexander (Example), Padmaja Havaldar Fengyou Jia, Cem Oguzhan (Intro), Hulda Adongo , Yang Zheng Manmohan Uttarwar, Gautham Kalwala (Conclusion) Based upon paper (#29): “The Architecture Tradeoff Analysis Method (ATAM)”, authored by Kazman et al. (1998) 740f02presentations22 26 Key features of ATAM 1. Tradeoff Analysis among multiple quality attributes (performance, availability, security, etc.), Looking optimal tradeoff points, rather than optimal individual attributes 2. Iterations of the ATAM (spiral model of design) 3. Trend analysis only (not detailed values) 740f02presentations22 27 Steps of the method: 740f02presentations22 28 Iterations of ATAM 1. Following Tradeoff points found (elements that affect multiple attributes) 2. Then we either: 1) refine the models and reevaluate 2) or refine the architectures (change the models to reflect these refinements and reevaluate 3) or change some requirements 740f02presentations22 29 How to apply ATAM 740f02presentations22 30 An Example (ATAM) Analysis: System Description: Remote temperature sensor (RTS) 1. measuring the temperature of a set of furnaces through a hardware device (ADC) 2. reporting those temperatures to operators 3. Sending periodic temperature update to hosts 4. Hosts sending control requests to RTS (changing the frequency of updating) 740f02presentations22 31 5. Scenarios collection (1) For performance analysis (2) For availability analysis 740f02presentations22 32 6. Collect Requirements/ Constraints/ Environment (1) Performance requirements (2) Availability requirements 740f02presentations22 33 6. Collect Requirements/ Constraints/ Environment In addition to these requirements, we will assume that the behavior patterns and execution environment are as follows: • Relatively infrequent control requests • Requests are not dropped. • No message priorities • Server latency = de-queuing time (Cdq = 10 ms) + furnace task computation (Cfnc = 160 ms) • Network latency between client and server (Cnet = 1200 ms) 740f02presentations22 34 7. Describe Architectural Views 7.1 Architectural Option 1 (Client-Server) 740f02presentations22 35 7.2 Architectural Option 2 (Client-Server-Server) 740f02presentations22 36 7.3 Architectural Option 3 (Client-Intelligent Cache-Server) 740f02presentations22 37 8. Realize Scenarios/Performance Analyses 8.1 Performance Analysis of Option 1 8.2 Performance Analysis of Option 2 8.3 Performance Analysis of Option 3 Notes: 740f02presentations22 Detailed calculations about WCCL, ACPL, and Jitter can be found in reference paper: Babacci et al. 38 1997. 9. Realize Scenarios/Availability Analyses 9.1 Availability Analysis of Option 1 1. Major failures: 9.2 Availability Analysis of Option 2 e. g., a burned-out power supply, taking 12 hrs to fix. 2. Minor failures: e. g., SW bugs, taking 10 minutes to repair. 9.3 Availability Analysis of Option 3 Solving the Markov model and getting the results in three tables. 740f02presentations22 39 10. Critique on the Options • Option 1 has poor performance and availability. It is also the least expensive option (in terms of hardware costs; the detailed cost analyses can be found in [1]). • Option 2 has excellent availability, but at the cost of extra hardware. It also has excellent performance (when both servers are functioning), and the characteristics of option 1 when a single server is down. • Option 3 has slightly better availability than option 1, better performance than option 1 (in that the worst-case jitter can be bounded), slightly greater cost than Option 1, and lower cost than Option 2. 740f02presentations22 40 11. Sensitivity Analyses Attributes are sensitive to the number of servers (performance increases linearly as the number of servers increases). 740f02presentations22 41 12. Security Analyses Security requirement: Security Scenarios: 740f02presentations22 42 So, to calculate the probability of a successful attack within an acceptable window of opportunity for an intruder, we define initial values that are reasonable for the functions provided in the RTS architectures. These values are shown in Table 7: 740f02presentations22 43 Three possible ways to succeed for spoof-server attack: Critiques: Table 8 showed that the possible intrusion rates were much higher than expected (requirements), Thus, to refine architecture options is required (need another iteration). 740f02presentations22 44 12.1 Refined Architectural options Adding E/D Note: E/D (Encryption/Decryption) (A most common security “bolt-on” solution, unreasonable change range generated by an intruder will be deemed (recognized) due to the addition of E/D) 740f02presentations22 45 (Before adding E/D) 740f02presentations22 46 13. Sensitivities and Tradeoffs At this point, we have discovered an architectural tradeoff point in the number of servers. Performance and availability are correlated positively, while security and presumably cost are correlated negatively with the number of servers. We cannot maximize cost, performance, availability, and security simultaneously. 740f02presentations22 47 Conclusions RTS Case Study Vague requirements & architectural options. Useful characteristics. Costs & benefits. Trade-offs. Develop informed action plans. Evaluations & iterations. 740f02presentations22 48 CONCLUSION : ATAM Motivated by rational choices among the competing architectures. Concentrates on identification of trade off points. Early clarification of requirements. Enhanced understanding and confidence in systems ability to meet the requirements. This method (ATAM) is still under development in SW engineering. 740f02presentations22 49 Key references 1. Babacci et al. (1997). CMU/SEI-97-TR-29. Pittsburgh, PA: Software Engineering Institute. 1. Dobrica et al. (2002). IEEE Transactions on Software Engineering, Vol. 28 NO. 7, July. 2. Kazman et al. (1999). Proc. Int’l Conf. Software Eng. (ICSE ’99), pp. 54-63, May. 3. Kazman et al. (1998). Proc. Fourth Int’l Conf. Eng. Of Complex Computer Systems (ICECCS ’98), Aug. 740f02presentations22 50 S/W Architecture Reengineering Zhigang Xie Ryan Young Jinhua Wang Vishal Solipuram 740f02presentations22 Feng Chen Ravi Athipatla Shufeng Li Krishan Narasimhan 51 What is SBAR? Abbreviation for Scenario-based Architecture Re- engineering “SBAR estimates the potential of the designed architecture to reach the software quality requirements.” • L. Dobrica: A Survey on Software Architecture Analysis Methods 740f02presentations22 52 Importance of SBAR A system is never a pure real-time system, or a fault-tolerant system, or a re-usable system. Single non-functional requirement (NFR) is not a satisfactory measurement, since NFRs often conflict. In a realistic system a balance of NFRs is needed for an accurate assessment of a software architecture. 740f02presentations22 53 Assessing Quality Attributes 1. Scenarios 2. Simulation 3. Mathematical Modeling 4. Experience-based Reasoning 740f02presentations22 54 An Example….. Beer Can Inspection System: • To illustrate the architecture reengineering method, a beer can inspection system is used. • The inspection system is placed at the beginning of beer can filling process and its goal is to remove dirty beer cans from the input stream. Clean cans should pass the system without any further action. • The system consists of a triggering sensor, a camera and an actuator that can remove cans from conveyer belt. 740f02presentations22 55 740f02presentations22 56 Functions When a can is detected, the system receives a trigger from a hardware trigger. After a predefined amount of time, the camera samples an image of the can. This sampling is repeated a few times and subsequently the measured images are compared to ideal images and a decision about removing or not removing the can is made. If the can should be removed, actuator is invoked at a point in time relative to the point in time when the trigger event took place. 740f02presentations22 57 Object Model 740f02presentations22 58 Author’s Experience Generally we handle S/W quality requirements by an informal process. If found short-comings, then re-design iteratively over system development, but this proves very costly. S/W quality requirements often conflict • Real-time Vs Reusability • Flexibility Vs Efficiency • Reliability Vs Flexibility Conventional design methods focus on a single quality attribute and treat all others as having secondary importance. 740f02presentations22 59 Architecture Reengineering Method S/W engineers need to balance the various quality attributes for any realistic system. The authors propose an architectural re-engineering method that provides an objective approach. Inputs Outputs Architecture Re-Engineering Approach Updated Requirements Specification & Improved Architectural Design Existing Software Architecture 740f02presentations22 60 Method Outlined…… 1. Incorporate new functional requirements in the architecture 740f02presentations22 2. Software quality assessment 3. Architecture transformation 4. Software quality assessment 61 Assessment Assessing Software Quality Requirements 1. Scenario-based evaluation: Develop a set of scenarios that concretize the actual meaning of the attribute. Useful for development related S/W qualities like reusability and maintainability 2. Simulation: Complements scenario-based evaluation. Is useful for evaluating operational software qualities like performance or faulttolerance. 3. Mathematical Modeling: Allows for static evaluation of architectural design models. 4. Experience-based reasoning: Evaluation process is less explicit and more based on subjective factors as intuition and experience. 740f02presentations22 62 Architecture Transformation Iterative Steps :- Complete architecture design. Compare with the requirements. Then update architecture. Note : The transformations made are minor. The functionality does not change, only the quality attributes change. It is not feasible to start bottom-up during design and reengineering. 740f02presentations22 63 Different Approaches Impose architectural style. e.g.. layered architectural style Impose architectural pattern. Apply design pattern. Convert quality requirements to functionality. Distribute requirements. 740f02presentations22 64 S/W Quality Requirements Functional requirements generally can be evaluated relatively easy by tracing the requirements in the design. On the other hand, S/W quality requirements are much harder to assess. Few such quality requirements are: • • • • Reusability Maintainability Real-time Robustness As mentioned previously, development related S/W qualities are easiest assessed using scenarios. 740f02presentations22 65 Reusability This quality attribute should provide a balance between generality and specifics. The architecture and its components should be general since they should be applied in other similar situations. The architecture should provide concrete functionality that provides considerable benefit when it is reused. Five scenarios that are tested in this article: • • • • • R1: Product packaging quality control R2: Surface finish quality control R3: Quality testing of micro-processors R4: Product sorting and labeling R5: Intelligent quality assurance system 740f02presentations22 66 Maintainability The goal here is that the most likely changes in requirements are incorporated in the software system against minimal effort. Five scenarios that are tested in this article are: • M1: The types of input or output devices used in the system is excluded from the suppliers assortment and need to be changed, by the S/W. • M2: The S/W needs to be modified to implement new calculation algorithms. • M3: The method of calibration is modified. • M4: The external systems interface for data exchange change. • M5: The hardware platform is updated, with new processor and I/O interface. 740f02presentations22 67 Applying SBAR Iterative process until quality requirements are met: •Evaluate software quality attributes of the application architecture •Identify the most prominent deficiency •Transform the architecture to remove the deficiency 740f02presentations22 68 Evaluation How much re-use is possible? How much will I be able to reuse the software of Re-used components ‘as-is’ to the total number of components Ratio As close to 1 as possible Presence of high coupling limits the possibility of re-use 740f02presentations22 69 Evaluation Effort needed to maintain How easy is it to fix Ratio of Affected components to Total components As close to 0 as possible Changes usually require many components to be modified 740f02presentations22 70 Transformations Component-level Problem: New item type requires the source code of most components to be changed Transformation: specific type generic type Result: Improves reusability and maintainability 740f02presentations22 71 Transformations Abstraction Problem: Type dependence at component creation Transformation: Use Abstract Factory pattern Results: Improves maintainability 740f02presentations22 72 Transformations Choose Strategy Problem: Changes have to be made in every component performing similar task Transformation: Apply the Strategy pattern Results: Gained maintainability outweighs loss in reusability 740f02presentations22 73 Transformations Decrease Dependence on Global State Problem: Calibration of the measurement system Transformation: Introduce calibration strategy Results: Improves maintainability 740f02presentations22 74 Reduce Coupling between calibration & measurement Problem: Coupling between calibration strategy and the measurement item. Transformation: Apply Prototype design pattern. Results: Improves maintainability and reusability. 740f02presentations22 75 740f02presentations22 76 740f02presentations22 77 Evaluation Overall, the result from the transformations is satisfying and the analysis of the scenarios shows substantial improvement (author’s conclusion). Each iteration seems to solve a problem concerning some attribute. The drawback may be that, we do not have a prior idea of how many iterations it is going to take. Identifying all possible problems that may lead to difficulties in re-use and maintainability is a challenging task in itself. 740f02presentations22 78 References • A Survey on Software Architecture Analysis Methods, L. Dobrica • Scenario-based Software Architecture Reengineering, PerOlof Bengtsson & Jan Bosch 740f02presentations22 79