Architecture-based software development (ABSD)

I. Development Model

Traditional software development processes can be divided into problem definition, requirement analysis, software design, software implementation, software testing, and other processes. If a traditional development process is adopted, the establishment of the software architecture should be prior to the outline design after requirement analysis.

The architecture-based software development model (ABSDM) divides the entire software process into six sub-processes, including architecture requirements, design, documentation, review, implementation, and evolution.

1. architecture requirements

The requirement is only the user's expectation for the target software system in terms of functions, behavior, performance, design constraints, etc. Architecture requirements are reflected by the experience of technical environments and architecture designers. The requirement process is mainly to obtain user requirements and identify the components used in the system.

1.1 requirement acquisition

Architecture requirements generally come from three aspects: system quality objectives, system business goals, and system developers business goals. The software architecture requirement acquisition process mainly defines the software functions that developers must implement and allows users to complete their tasks to meet the functional requirements of their businesses. At the same time, we also need to obtain software quality attributes to meet non-functional requirements.

1.2 identify component

This step can be further implemented in three steps:

Step 1: generate a class chart. Use the CASE tool to generate a class chart.

Step 2: group classes. After grouping, the class graph structure is simplified to make it clearer and readable. Generally, grouping is performed based on the Coupling Degree and cohesion between classes. For example, when practicing DDD, You can group one aggregation. Multiple aggregation groups are divided into multiple groups.

Step 3: Package classes into components. Achieves component-Level Reuse. Components and components can be packaged into larger components.

1.3 Requirement Review

A group composed of different representatives is formed to carefully review architecture requirements and related components. The main content of the review includes whether the obtained requirements reflect the user's requirements, whether the grouping of classes is reasonable, and whether the component merging is reasonable.

If necessary, iteration can be performed between requirement acquisition, identification component, and Requirement Review.

 

2. Architecture Design

Architecture design is an iterative process. The procedure is as follows:

2.1 propose a Software Architecture Model

In the initial stage of building an architecture, choosing an appropriate architecture style is the first priority. Based on this style, developers can get an understanding of the relevant architecture attributes through the architecture model.

2.2 map identified components to the software architecture

Ing the components identified in the architecture requirement phase to the architecture generates an intermediate structure that only contains components that can identify the appropriate architecture model.

2.3 interaction between Analysis Components

To integrate all identified components into the architecture, the interaction and relationship between these components must be carefully analyzed.

　　

2.4. Generate Software Architecture

Once the relationship and interaction between components are determined, the intermediate structure can be obtained in the second stage.

2.5 Design Review

Once the software architecture is designed, external personnel independent of systems outside the system must be invited to review the architecture.

 

3. Documented Architecture

The vast majority of architectures are abstract and contain conceptual components. Therefore, to enable system analysts and programmers to implement the architecture, you also need to document the architecture.

The main output structure of the Architecture documentation is the architecture Requirement Specification and quality design specification (document for testing the architecture requirements ). Precise and formal description is a contract between users and developers.

 

4. Architecture Review

Architecture Design, docization, and review are iterative processes. After a Software Architecture Analysis in the main version, a review with external personnel (user representatives and field experts) should be arranged.

The purpose of review is to identify potential risks and detect defects and errors in the architecture design as soon as possible, including whether the system structure can meet the requirements, whether the quality requirements are embodied in the design, whether the layers are clear, whether the component division is reasonable, whether the document expression is clear, and whether the component design meets the functional and performance requirements requirements.

 

5. Implementation of the Architecture

 

 

The article is not complete ...... First go to bed ......