1 / 24

Software Architecture Quality

Software Architecture Quality. Outline . Importance of assessing software architecture Better predict the quality of the system to be built How to improve quality A systematic design process and a solid understanding of the problem reduces risks and improves quality Architecture evaluation

tamber
Download Presentation

Software Architecture Quality

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Architecture Quality

  2. Outline • Importance of assessing software architecture • Better predict the quality of the system to be built • How to improve quality • A systematic design process and a solid understanding of the problem reduces risks and improves quality • Architecture evaluation • Evaluation methods are assessment processes using teams of stakeholders • Assessing modifiability • Modifiability can be assessed by applying change cases • Assessing performance • The performance characteristics of a design before constructing the system

  3. Introduction • We evaluate an architectural description into order to verify that the system it describes will possess certain required or desired quality attributes. • We cannot predict every system quality such as validity, usability, and some performance qualities, but we can get a reasonable amount of assurance as to some specific quality attributes relating to modifiability, some aspects of performance and reliability.

  4. Importance of Assessing Software Architecture • The software architecture description provides a way to assess system quality early in the development process. • A key software engineering principle is that quality cannot be testing into the product; it has to be designed into it. • Modifying existing code is much more time-intensive and expensive than modifying design specifications.

  5. How to Improve Quality • Common quality characteristics that can be evaluated at the level of architectural description are modifiability, performance and reliability. • There are two aspects to consider in assessing the quality of a system’s architecture • How to evaluate an architectural description? • How to conduct an architectural assessment? • Architecture assessment allows us to measure the quality of a design. There are other complementary activities and methods for helping improve the quality of a system: • Systematic Design Process • Understand the Right Problem

  6. Systematic Design Process • Systematic design processes lead to high-quality designs. • It helps the designer reason about the problem being solved and how best to solve it. • The design process runs more effective since there is less solution searching. • The process increases the number of potential solutions and thereby increases the chances of discovering a suitable solution.

  7. Understanding the Right Problem • The quality of the requirements ultimately predetermines the quality of the system. • The software architect often performs the role traditionally assumed by a systems analyst, that is, makes sure that the requirements are correct.

  8. Understanding the Right Problem Example • Stated requirement: • Allow users to delete some data that was no longer necessary, but the system would not permanently remove it but rather mark it as hidden. • Correct requirement(s): • Allow users to change the state of some data so that it no longer affects the processing of the system but yet is still available for viewing and other operations. • Allow users to extract data that is no longer needed in the operational database an place it into some archive. • Allow users of the system to permanently delete unwanted data.

  9. System Level View of Requirements • One of the most important things an architect can do is to analyze the dependencies among the requirements. • This leads to a better decomposition of the problem.

  10. Differentiating Design and Requirements • Whenever a feature is specified in a requirements document, there is a design (by human nature). • It is important to be able to have a clear understanding of the problem even if elements of design are included. • The architect must be skilled at analyzing requirements.

  11. Assessing Software Architectures • Architecture assessment is the activity of measuring or analyzing a system’s architecture in order to understand its quality attributes. • Architecture assessments should not only be performed by the architects, but by the other stakeholders as well. • Two basic classes of analysis techniques: • Questioning – generating qualitative questions about the architecture • Measuring – quantitative techniques that address specific qualities

  12. Scenarios: Reifying Nonfunctional Requirements • Most architecture assessment methods use scenarios as a way of simulating a system so that it may be reasoned about. • Three categories of quality attributes: • External stimuli – events that cause the architecture to respond • Architectural decisions – design elements or design rules that have a direct impact on achieving attribute responses • Responses – how the system would react to the stimuli

  13. Scenarios: Reifying Nonfunctional Requirements (Cont’d) • To make nonfunctional quality attributes measurable or observable they must be reified as concrete tasks or scenarios. • Scenarios can be a very powerful specification technique because they make abstract requirements into tangible concrete tasks. • Scenarios can be realized through the creation of a quality attribute utility tree, which is one of the mains steps of SEI’s ATAM (Attribute Trade-off Analysis Method).

  14. Example Quality Utility Tree Deploy a new product without recompiling or redeploying the runtime platform Replace repository with new vendor product Add an additional, possibly heterogeneous, repository to system Retrieve 1,000 edition source files within 1 minute Repository online within 10 minutes Detect database failure and recover within 2 minutes New Products Reconfigure Reposiories Throughput Repository Failure Operational Database Failure Modifiability Performance Availability Utililty Tree

  15. The Role of the Architectural Description • The architectural design models that comprise the architectural description can have a significant impact on the ability of an architect to analyze an architecture. • The architecture must be written down and it must use models that aid in its analysis.

  16. Architecture Evaluation • Architecture evaluation is a development life-cycle activity in which several stakeholders analyze the architecture together in formal or informal ways using an assessment technique such as scenarios. • Formal evaluations should be done as soon as the architecture is stable but before any commitment to development has been made.

  17. Examples of Software Architecture Evaluation Methods • Scenario-based Architecture Analysis Method (SAAM) – the first documented method, originally developed to analyze for modifiability • Architecture Trade-off Analysis Method (ATAM) – the successor of SAAM, uses quality attribute utility trees and quality attribute categories, addresses interactions between quality attributes • SAAM Founded on Complex Scenarios (SAAMCS) – considers the complexity of evaluation scenarios as the most important risk assessment factor • Extending SAAM by Integration of the Domain (ESAAMI) – integrates SAAM with domain-specific and reuse-based software development processes

  18. Examples of Software Architecture Evaluation Methods (Cont’d) • Software Architecture Analysis Method for Evolution and Reusability (SAAMER) – focuses specifically on the quality attributes of evolution and reusability • Scenario-Based Architecture Reengineering (SBAR) – utilizes scenarios, simulation, mathematical modeling, and experience-based reasoning for assessing quality attributes • Architecture Level Prediction of Software Maintenance (ALPSM) – a method for analyzing maintainability using scenarios representing maintenance tasks • Software Architecture Evaluation Model (SAEM) – based on formal and rigorous quality requirements

  19. Assessing Modifiability • Modifiability is a general quality attribute for specifying a change to a system. • Modifiability requirements should be specified as specific scenarios (change cases). • For example: • Deploy a new product without recompiling or redeploying the runtime platform • Replace repository with new vendor product • Add an additional, possibly heterogeneous, repository to system

  20. Assessing Performance • There are two conflicting views with respect to performance: • “make-it-work-then-make-it-fast” • “filter-every-decision-through-a-performance-analysis • When considering architecture you can emphasize performance (this is really “make-it-work” in terms of the architecture). • In detailed design you can concentrate on making it work first because design decisions are localized.

  21. Assessing Performance (Cont’d) • One performance myth is that you have to have something to execute in order to test it for performance. • Some aspects of performance can be predicted by analyzing the architecture. • Many performance problems come from architectural design decisions. • At the architectural level, performance is characterized by the interaction between components. • By analyzing the communication characteristics between the components, performance can be predicted.

  22. Assessing Performance (Cont’d) • Smith and Williams developed a software process engineering (SPE) method based on creating performance models for critical use case scenarios. • The key scenarios are those normal scenarios that are performed frequently. • A sequence diagram can be used to represent a use case scenario.

  23. Summary • Architecture assessment allows the software development team to observe or measure the architecture of a system before it has been constructed in order to better predict the quality of the eventual system. • This helps to lower development risks. • Assessment can be formal or informal. • It is necessary to know that the design has achieved an acceptable balance of quality attributes.

  24. Summary (Cont’d) • The more complex a system is, the more important architectural design becomes. • Architectural assessment gives us the knowledge needed in order to make the best architectural design decisions.

More Related