Document directory
- Sensitistmpoint)
- Tradeoff point)
- Stakeholders)
- Scenario (scenarios)
- (1) Description of ATAM method-present ATAM
- (2) describe business motives-present business drivers
- (3) Describe the architecture-present the architecture
- (4) Identify the architecture-identify achitectural approches
- (5) generate the quality attribute utility tree-generate utility tree
- (6) Analytical architecture method-analyze selected tural approaches
- (7) Discussion and classification scenario-Brainstorm & prioritize scenarios (including new added scenarios)
Software Quality Attributes
1. Performance)
Performance refers to the system's response capability. performance tests often use benchmark tests ).
Benchmark Testing (benchmarking) is an activity for measuring and evaluating software performance indicators. You can establish a known performance level (referred to as a baseline) through benchmarking at a certain time ), when the system's hardware and software environments change, a benchmark test is conducted again to determine the impact of those changes on performance. This is the most common purpose of benchmarking. (Reference: http://www.blogjava.net/qileilove/archive/2012/07/05/382241.html)
2. Reliability)
It is the basic capability of a software system to maintain the functional features of a software system in the face of application or system errors in the case of accidental or incorrect use.
Reliability measurement:
The Reliability measurement standard is usually used to calculate the failure probability of a single solution component. One metric used to define component or system reliability is the average failure interval (MTBF ). MTBF is an average interval of thousands of hours or tens of thousands of hours.PohAfter this interval, the component fails and needs to be repaired. MTBF is calculated using the following formula:
MTBF = (total elapsed time - sum of downtime)/number of failures
The metrics for measuring reliability are fault-tolerant and robust.
Robustness. Protect applications from incorrect use and incorrect input. Ensure that the application system is in a defined State when an unexpected error occurs. That is to say, we should consider as many exceptions as possible and return meaningful error messages to users. Minimize feedback such as system errors.
The main reliability design technologies include:
- Fault Tolerance Design Technology: Common Software Fault Tolerance technologies include fast recovery design, N-Version Programming and Redundancy Design. Quick Recovery design contains several blocks with the same functions and different designs. Each block is instantly running. Once a program fails, it is replaced by a backup block. The core of version n design is to design multiple modules or different versions, perform a majority vote on the operation results with the same initial conditions and the same input (to prevent a software module/version from providing incorrect services for fault tolerance ). The concept of redundancy design comes from the hardware system, but it is different. The Software Redundancy Design Technology uses a variety of different paths, modules or systems with different algorithms or implementation methods as backups, replacing them in case of a fault, and maintaining the normal operation of the system.
- Detection Technology: when there is no need for online fault tolerance or redundancy design technology is not used, but there is a need for high reliability, the detection design is generally used, when a software fault occurs, the system can promptly detect and trigger an alarm. The obvious drawback is that the fault cannot be automatically solved.
- Complexity Reduction design: Software complexity is closely related to software reliability. Software complexity is an important source of Software defects. The idea of Complexity Reduction design is to simplify the software structure on the basis of ensuring the implementation of software functions.
3. Availability)Is the ratio of time when the system can run normally. Availability = system running time/(system running time + system downtime)
Percentage
Of availability = (total elapsed time-sum of downtime)/total elapsed timeAvailability is usually measured by "9. For example, a solution with an availability level of "Three nine" can support its expected functions within 99.9% of the time, equivalent to 24x7x365 (daily
The annual downtime of 365 hours per year based on 24 hours/seven days per week/8.76 days per year.
Availability = MTTF/MTBFMTBF (mean time between failure) = MTTF (mean time to failure) + MTTR (mean time to repaire) average failure interval = average failure wait time + average failure repair time. (Reference: http://book.51cto.com/art/200902/111142.htm) Design Technology to Improve availability: can improve the accuracy of the system through a distributed parallel system, the benefits of parallel system when a node problems, the other node can work
4. Security)It refers to the ability of the system to prevent unauthorized users from attempting or rejecting services while providing services to legitimate users.
5. Modifiability)It refers to the ability to quickly compare system changes at a high performance price. Includes the following four aspects:
- Maintainability)
- Extendibility)
- Reassemble)
- Portability)
6. Functionality)It refers to the ability of the system to complete the desired work.
7. changeability)It refers to the ability to expand or change the architecture into a new architecture.
8. inter-operation)Software as part of the system does not exist independently. It often interacts with other systems or their own environments. To support interoperability, the software architecture must provide a well-designed software portal for externally visible features and data structures.
Important Concepts in evaluation
Sensitistmpoint)
Sensitive points are the characteristics of one or more components (or relationships). For example, if the encryption level is higher and the security is better, the encryption level is the sensitive point of the security quality attribute.
Tradeoff is a sensitive point that affects multiple quality attributes. For example, the higher the encryption level, the better the security, but it may consume more processing time, affecting system performance. The encryption level is
SecurityAnd
Performance. The cache technology can also improve the system performance, but it increases the complexity of the system when maintaining the cache (synchronous, update ).
PerformanceAnd
System Complexity.
Stakeholders)
There are architects, developers, maintenance personnel, integration personnel, testers, performance engineers, security experts, project managers, product managers, users, system administrators, network administrators, field representatives, and system designers.
Scenario (scenarios)
Generally, we need to accurately obtain specific quality objectives and use them as the criteria for binding the advantages and disadvantages of the architecture.
Scenarios are used-Represent stakeholders' interests (which describes stakeholder concerns)-Understand quality attribute requirements (understanding quality attribute Requirements )-
Scenarios shocould cover a range-Anticipated uses of (use case scenarios),-anticipated changes to (growth scenarios), or-unanticipated stresses (exploratory scenarios) to the system. -A good scenario makes clear what thestimulus is that causes it and what responses are of interest.
Scenarios examples:
Use Case Scenario-remote user requests a database report via the Web duringpeak period and has es it within 5 seconds. -growth scenario-Add a new data server to reduce latency inscenario 1 to 2.5 seconds within 1 person-week. -exploratory scenario-half of the servers go down during normal operation withoutaffecting overall system availability. -scenarios shoshould be as specific as possible.
Main Evaluation Methods
1. SAAM (scenarios-Based Architecture Analysis Method) modifier is the main quality attribute of SAAM analysis. 2. ATAM (Architecture Tradeoff analysis method) is a scenario-based analysis method developed on the basis of SAAM. It mainly targets performance, availability, security, and maintainability. Before system development, evaluate and compromise these quality attributes.
The entire ATAM evaluation process consists of nine steps, in the order of numbers: (1) Description of the ATAM method-present ATAM
• Techniques
-Utility Tree Generation
-Architecture elicitation and Analysis
-Scenario brainstorming/mapping
• Outputs
-Architectural approaches
-Utility tree
-Scenarios
-Risks and "non-risks"
-Sensiti1_points and tradeoffs
(2) describe business motives-present business drivers
ATAM customer Representative describes the system's business driversincluding:-business context for the system-High-level functional requirements-High-level quality attribute requirements-Your tural drivers: quality attributes that "shape" the architecture-critical requirements: quality attributes most central to the system's success
(3) Describe the architecture-present the architecture
Effecect presents an overview of the ubuntureincluding (for example):-technical constraints such as an OS, hardware, or middle-ware prescribed for use -- other systems with which the system must interact -- specify tural approaches/styles used to address qualityattribute requirementsevaluation team begins probing for and capturing risks.
(4) Identify the architecture-identify achitectural approches
Identify any predominant restart turalapproaches-for example:-client-server-3-tier-proxy-publish-subscribe-redundant hardware
(5) generate the quality attribute utility tree-generate utility tree
Identify, prioritize, and refine the most importantquality attribute goals by building a utility tree.-A utility tree is a top-down vehicle for characterizing the "Driving" Attribute-specific requirements -- select the most important quality goals to be the High-Level nodes (typically performance, Modifiability, security, and availability) -- scenarios are the leaves of the utility tree output: acharacterization and a prioritization of specific quality attribute requirements.
(6) Analytical architecture method-analyze selected tural approaches
(7) Discussion and classification scenario-Brainstorm & prioritize scenarios (including new added scenarios)
Stakeholders generate scenarios using a facilitatedbrainstorming process.-scenariosat the leaves of the utility tree serve as examples to facilitate the step. -- the new scenarios are added to the utility tree
(8) analyze the architecture method (repeated in Step 6)-analyze using tural approaches (like an iteration process)
- Identify the specified tural approaches impacted by thescenarios generated in the previous step.
- This step continues the analysis started in Step 6 using thenew scenarios.
- Continue identifying risks and non-risks.
- Continue annotating invalid tural information.
(9) Describe the evaluation result-present ATAM results
- Architectural approaches
- Utility tree
- Scenarios
- Risks and "non-risks"
- Sensiti1_points and tradeoffs
Utility treescenariosrisks and "non-risks" sensiti#points and tradeoffs
