Optimize the architecture from the perspective of quality attributes and response policies

By analyzing and organizing requirements from the perspective of system engineering, we have obtained a framework
Architecture prototype, but it is only an approximate structure of the architecture. Prior to the specific architecture design, the architect must carry out the architecture
Further analysis and design, from different perspectives of architecture design, multi-angle, multi-level modification of the architecture design scheme,
To obtain a reasonable architecture baseline product.
The first aspect of the preliminary architecture outline is to carefully consider the architecture requirements of quality requirements from the demand analysis.
In other words, it is to obtain the architecture factor. The essence of Architecture Analysis is to identify factors that may affect the architecture and understand its
Ease of change and priority, and solve these problems. The difficulty is to understand what problems have been raised and to weigh them,
Measure the test taker's knowledge about many ways to solve the problems that affect the architecture.
1. Architecture Analysis
Architecture Analysis is a high-priority and influential activity. Architecture Analysis is valuable for the following tasks:
Reduces the risk of missing the core part of the system design;
Avoid spending too much effort on low-priority issues;
Locate the product for the business target.
Architecture Analysis refers to activities related to identifying non-functional requirements in the Process of functional requirements.
Is the most noteworthy.
The general steps for Architecture Analysis are as follows:
Identify and analyze non-functional requirements that affect the architecture.
For those who have important impacts, analyze the optional schemes and make decisions to deal with these impacts,
This is architecture decision-making.
2. Identify and analyze architectural factors
1) architecture Factors
Any requirement has an important impact on a system architecture. These impacts include reliability, schedules, skills, and costs
Constraints. For example, when time is short, skills are limited, and funds are sufficient, a better way is to purchase and outsource, while
Not all components are developed internally. However, the most influential factors to the architecture include functionality, reliability, performance, and support.
And interfaces. Usually non-functional attributes (such as reliability and performance) determine the uniqueness of an architecture.
It is not a functional requirement.
2) Quality scenarios
When defining quality requirements during architecture factor analysis, we recommend Application quality scenarios. It defines quantifiable (at least
Is an observed response, and therefore can be verified. In quality scenarios, fuzzy and non-measurable descriptions are rarely used.
For example, "the system must be easy to modify ". Quality scenarios are briefly described in the form of <stimulating factors> <quantifiable response>, for example:
When the sales volume is sent to the remote tax calculation server for tax calculation, the "majority" must be returned within 2 seconds.
Back. This result is measured under an "average" load condition.
When a system test volunteer submits an error report, he/she must reply by phone within one business day.
Here, the "majority" and "average" require the software architect to further investigate and define. Quality scenarios
It is effective to be tested. This requires a detailed description.
3) Description of architecture Factors
An important goal of Architecture Analysis is to understand the impact, priority, and variability of architecture factors (flexibility and the future ).
The direct need for evolution ). Therefore, most architecture Methods advocate creating an architecture factor table for the following information.
Variable factors measurement and quality scenarios (current flexibility and future evolution)
Customer impact, architecture and
Other factors
Excellent
First
Level
Difficult
Or wind
Risks
Reliability-recoverability
Slave
Yuan Cheng
Service
Failure
Medium recovery
.
When the remote service fails
When listening to remote
Service re-Online
Within minutes.
Establish contact in the product environment
To achieve normal storage
Load.
Current flexibility-our SME considers direct
Before re-establishing the connection, the local customer is simplified
Is acceptable (and desirable)
).
Evolution-within two years, some retailers
May choose to pay local full copy Remote Server
Service functions (such as tax calculator ). Possible
Sex? High.
Impact on large-scale design
Loud.
Retailers do not want
The remote service fails because
This will limit or block
They use POS
Sales.
High and low
...... ...... ...... ......
Note: SME indicates the topic expert.
4) Obtain architecture factors from the requirement documents
In the architecture design, the central function requirement database is a use case. Its conception and supplementary specifications are the duplicates of the factor table creation.
Source. In use cases, special requirements, technical changes, and pending issues should be reviewed repeatedly. Its implicit or clear frame
The construction factors should be unified into the supplementary specifications.
3. Analysis of architecture Factors
The architecture design skill is to make appropriate choices for solving architecture factors based on trade-offs, mutual dependencies, and priorities.
Select. However, this is not comprehensive. Sophisticated architects have knowledge in a variety of fields (such as Architecture styles and patterns, technology, and production ).
Products, defects, and trends), and can apply this knowledge to their decisions.
1) record the options, decisions, and motivations of the Architecture
Regardless of the principles of current architecture decision-making, in fact, all architecture methods are recommended to record:
Optional Architecture Scheme; decision; influencing factors; significant problems; motivation.
These records are called technical memos, problem cards, and architecture paths in different forms or levels.
File. An important aspect of the technical memorandum is motivation or principle. When a developer or architect needs to modify the system
The architect may have forgotten his original design basis (when a senior architect takes multiple projects at the same time ).
The memorandum is extremely useful for understanding the motives behind the design at that time. Explain the reason for giving up the selected Solution
Important: In the future of product evolution, architects may need to reconsider these alternatives, at least knowing that
Which of the following options is selected. The format of the technical memorandum is not important. The key is simplicity, clarity,
Complete information.
Technical Memorandum
Problem: Reliability-recovery from remote service faults
Solution Overview: You can use the query service to achieve location transparency, remote to local fault recovery, and partial replication of local services.
Architecture Factors
Reliable recovery from remote services
Reliable recovery from remote product database faults
Solution
Create an adapter in the service factory ......
Motivation
Retailers do not want to stop retail activities ......
Legacy problems
None
Proposed alternatives
Sign "golden service agreement" with remote service providers ......
2) Priority
The following are guidelines for determining the architecture goals:
Unchangeable constraints, including security and Legal Affairs
Business objectives
All other targets
In the early stage, it was necessary to decide whether to avoid future design. We should consider what is to be postponed to the future.
How many codes need to be changed? What is the workload? Carefully consider what potential changes will help reveal
This is the primary concern. A product with low coupling and high cohesion is often easier to adapt to future changes, but it also needs
Careful analysis of the price, in this case, the architect's attention is often the lifeline of this project.