System Architect study note _ Chapter 5 (I) _ serialization

Chapter 5 Software Architecture Design

Software Architecture (SA)

5.1.2 Software Architecture Design and lifecycle

1. Demand analysis stage

The requirement and SA design face different objects: one is the problem space, and the other is the solution space. Keep tracing and conversion between the two.

2. Design Phase

1. The traditional design concept only includes components. With the deepening of research, the interconnection mechanism between components gradually becomes independent and becomes an entity of the same level as the component.

2. Architecture Description Language ADL (Architecture Description Language ADL) attaches importance to connectors and becomes one of the important features of distinguishing ADL from other modeling languages.

3. Multiple Views are obtained from different perspectives, which are organized to describe the overall SA model. Different views on different sides reflect specific aspects of the system and reflect the idea of separation of concerns.

3. Implementation Phase

The team structure should correspond to the architecture model to improve the efficiency and quality of software development.

Analyzes and records the evolution between components and connectors of different versions.

A typical method to bridge the gap between the high-level SA model and the underlying implementation is as follows:

1. introduce the concept of implementation phase.
2. The SA model is gradually refined.
3. encapsulation of the underlying layer is called a large-granularity component.

4. Component Assembly stage

Reusable Component Assembly can implement the system at a higher level. The research contents include:
1. How to interconnect.
2. How to detect and eliminate architecture mismatch issues.

Middleware cross-platform interaction.
The product-oriented middleware ensures the quality of the final system and the middleware-oriented architecture.

Mismatch refers to the conflict between the architecture and environment setup (assumption) of the final system by the components to be reused in the reuse process and the actual situation.

5. deployment phase

Software components, hardware topology, and hardware resource occupation.

6. Post-development stage

Software in implementation is often dynamic. One is the architectural change caused by internal execution of the software, and the other is the reconfiguration of the software by external requests of the software system.

You cannot stop the service during upgrade or other modifications.

Sa reconstruction refers to the process of obtaining the architecture from the implemented system.

5.2 architecture-based software development

5.2.1 Architecture Design Method Overview

Architecture-based software design absd method.

Driven by architecture refers to the combination of business, quality, and functional requirements that constitute the architecture.

The beginning of the design activity does not mean that the demand extraction and analysis activities can be terminated, but parallel design should be necessary to quickly start the design.

The absd method has three foundations: functional decomposition, architectural style selection, and use of software templates.

5.2.2 concepts and terminology

1. Design Elements

The absd method is a top-down, recursive refinement method.

2. View Angle and view

It is important to check from different perspectives and consider the different attributes of the architecture.

3. Use Cases and quality scenarios

When you use the case capture function, you can define a specific scenario to capture quality requirements. This is called a quality scenario. Capture changes, performance, reliability, and interactivity. Quality scenarios must include expected and unexpected ones.

5.2.4 architecture requirements

It can be retrieved, used, and modified from the requirement library.

To obtain requirements, the architecture requirements generally come from three aspects: system quality objectives, system business goals, and developer business goals.

5.2.6 docized Architecture

Architecture specifications and quality design specifications for testing architecture requirements.

The precise and formal description of requirement model components is a contract between users and developers.

From the user's perspective, you must ensure that the documents on the developer's hand are up-to-date.

5.2.7 architecture Review

Based on the architecture design, build a workable minimal system to evaluate and test whether the architecture meets the needs. Whether there are identifiable technical and collaboration risks.

The purpose of review is to identify potential risks and detect defects and errors early.

5.2.8 architecture implementation

Split into specified components and interact with each other in the specified way.