- Software System Quality Attributes
Software system quality familiarity is divided into development period quality attributes and runtime quality attributes.
quality attribute
- Performance: refers to the responsiveness of the system , such as response time and throughput.
Design strategy: priority queue, increasing computing resources, reducing computing overhead, introducing concurrency mechanism, and adopting resource scheduling .
- Reliability: The maintenance of software system functional characteristics under accidental or misuse conditions. Such as MTTF, MTBF, MTTR.
MTTF: Mean Time To Failure.
MTBF: mean time between failures.
MTTR: mean time to repair failure.
Design strategy: heartbeat, PING/Echo, redundancy, election .
- Availability: The moment when the system is up and running. such as the time between failures .
Design strategy: heartbeat, PING/Echo, redundancy, election .
- Security: Refers to the ability to prevent unauthorized users from using an enterprise or to deny service. Such as confidentiality, integrity, non-repudiation, and controllability.
Design strategy: intrusion detection, user authentication, user authorization, trace audit .
- Modifiability: making changes to the system at a cost-effective manner.
Design strategy: interface-implementation separation, abstraction, information hiding.
- Functionality: The system's ability to perform the desired tasks and capabilities.
- Variability: refers to the ability of the architecture to become a new system structure through expansion or change . (Scalable)
- Interoperability: Software that is part of a system does not exist independently, and often interacts with other systems or its own environment .
- Mass Attribute Scenario
A quality attribute scenario is a requirement for a specific quality attribute . It consists of six parts.
Stimulus source (source): refers to an entity that generates the stimulus. (human, computer system, or any other stimulator)
Stimulus: Refers to the conditions that need to be considered when a stimulus reaches the system. (Want to add, delete, modify, change functions, quality attributes, capacity, etc.)
Environment: The stimulus occurs within certain conditions. (system design time, compile time, build time, runtime)
Artifact: An artifact is excited , the object of the stimulation, the subject of the stimulation. (system user interface, platform, or system that interacts with the target system)
Response: The response is the action taken after the stimulus arrives . (Find the location where the architecture needs to be modified, and make the modification without affecting other operations)
Response measurement: It should be possible to measure it in some way. (The impact of the modifications made during the response on other modules of the system)
- Software Architecture Evaluation
The software quality was introduced earlier, and the architecture was evaluated from the aspect of quality.
Sensitive point: In order to achieve a certain quality attribute , one or more components have characteristics. (affects only one, such as security)
Trade-off point: It is a characteristic that affects multiple quality attributes, and it is a sensitive point for multiple quality attributes. (when affecting multiple, such as efficiency and safety)
Risk points and non-risk points, risk points may cause risk factors. Something acceptable and feasible is not a risk.
After the software architecture design and before the system design, the software architecture evaluation aims to solve the system requirements, but not only to solve the system requirements.
Three ways to assess architecture:
- Questionnaire-based (checklist) approach: Questionnaire survey.
- Metric-based: Formulate some quantitative metrics to measure the architecture, such as the number of lines of code.
- Scenario-based approach:
- Determine the mapping between the functionality of the referenced domain and the structure of the software architecture. (Stimulate)
- Scenarios used to embody the quality attributes to be assessed. (environment, the environment in which an event occurs)
- Analyze how well the software architecture supports the scenario. (architecture responds to stimulus process)
A is the input, C is the output, and B is the real scene.
There are three main methods of scenario-based architecture analysis:
- TOGETHER
An architectural analysis method for non-functional quality attributes , which was the first to be used.
- Specific goals, the goals of SAAM verify the underlying architectural assumptions and principles against documents that describe the properties of an application.
- Quality attributes, the basic feature of this method is to concretize any form of quality attributes into scenarios, but modifiability is the main quality attribute of SAAM.
- Architecture description, SAAM is used for the final version of the architecture, but earlier than the detailed design, the description form of the architecture is understood by all participants.
- Functionality, structure, and allocation are defined as the three main aspects that describe the architecture.
- Method activities, the main input of SAAM is problem description, requirements statement and architecture description.
The main five steps are scene development, architecture description, single scene evaluation, scene interaction and overall evaluation .
- ATAM (emphasis)
Architectural trade-off analysis method ATAM allows architects to clarify how to weigh multiple quality attributes . Participants include evaluation teams, project decision makers and other project stakeholders .
Four main areas of activity: Scenario Requirements Gathering, Architectural Views and Scenario Realization, Attribute Model Construction and Analysis, (Architecture Review makes one) Tradeoffs .
The entire evaluation process emphasizes attributes as the core concept of architecture evaluation .
These quality attributes are evaluated and compromised prior to system development.
description stage
- First, the ATAM method will be described. (similar to reading rules)
- Describe the business motivation.
- Describe the schema.
Architecture Analysis Phase
- Confirm architectural approach.
- Generate quality attribute utility tree (very important)
- Analytical architectural approach.
Testing phase:
- Discuss the scenario to grade the scenario.
- Analytical architectural approach.
- Describe the review results.