Software Architecture Design Process

To sum up, we can establish a systematic software architecture design process. Typical Software Architecture Design
Shows the process.
I. Concept of Business Architecture
Before building a software architecture, the architect should carefully study the following issues:
Why is the system built for the purpose?
What are the benefits of the system after it is put into operation?
When does a role operate or maintain the system?
How is the business system implemented?
How does the entire business system operate on the system?
To answer these questions, you need to carefully read the business model establishment, problem domain, and solution structure in the requirement analysis document.
Ideas, product model ideas, and other preliminary documents, from the perspective of system architecture, comprehensive and clear establishment of business models, including
Organizational structure relationships, business functions, business processes, business information interaction methods, business geographic distribution, business rules and constraints
Condition. The main activities at this stage are as follows:
Establish important initial information such as product scope, purpose, end user, and business background.
Build a complete Dictionary of business and system terms to ensure that project personnel are consistent in understanding.
Establishes overall business concepts at the macro level, and clarifies the overall process, boundaries of business functions, and ways of interaction and collaboration,
Create a conceptual model for the system.
Summarize the overall organizational structure of the business and the functional relationship of collaboration.
Analyzes the components of the business and the dependency between interaction, collaboration, and information between nodes.
Analyzes the events and messages of business nodes, and the resulting status transition relationship.
Summarize basic data models for business operation to facilitate tracking information flow and format conversion. Analyze business data
.
Understand the problem domain and the problems to be solved by the system.
Analyze basic business rules and constraints at the business operation level.
The activities at this stage are very important. Architects can start from
These concepts extract appropriate architectural factors.
Ii. product architecture concepts
On the basis of understanding the business, we need to further consider the concept of the product architecture. At this stage, we can see from the activity level
In fact, it is the same as building a business architecture, but the focus of thinking is shifted to the following aspects:
After the new system is put into operation, how will the business at the highest level operate?
How does the new system solve the problem of the original working system?
What will happen to the original organizational structure division when the new system is put into operation?
What changes will happen to the distribution of business nodes because the new system replaces some original business functions? Change
Then, how does one exchange and depend on the information between nodes?
What will happen to the transfer of changed business events?
After a new system is added, which business processes will change significantly? Which will not change?
How will the business state transition relationship change with the addition of new systems?
How will the business data model change as the business process changes?
How does a new system affect new business rules and constraints?
From these perspectives, we will re-build the business rules after the new system is put into operation in the future. The corresponding new rules also need
To be established, the business process is reconstructed.
3. Establish a stable architecture baseline
After a deep understanding of the business and problem domains, we need to continue to study the following issues:
How many subsystems should this complex system be divided?
How are subsystems distributed on different business nodes or physical nodes?
What interfaces will these scattered subsystems provide? How do these interfaces interact?
What data does each subsystem need to interact?
What functions do each sub-system need to implement?
What are the functional, performance, and quality requirements of the entire system for each subsystem?
The term "baseline" has two meanings:
This stage will make significant design decisions on the overall architecture strategy. Once these decisions are made
Continuous Development is not subject to major changes.
The work completed at this stage is itself an important achievement of the architecture stage and must be widely recognized and collectively adhered
And have mandatory binding force.
Although in the later stages of evolution, such baselines will actually be constantly refined and optimized, but at first we made efforts to build a stable
A fixed architecture baseline is essential. The activities at this stage are as follows:
Verify and confirm all the information about the business architecture and product architecture in the early stage, and add relevant information when necessary.
Revise and supplement the term dictionary to ensure that all relevant personnel have the same awareness of the term.
Splits the entire system function and splits it into different running nodes to build different system sets and sub-nodes.
System: divides interface and interaction rules globally.
Collects system/subsystem interface information for retrieval and browsing.
Plan the communication links, communication paths, communication networks, and other transmission media of the entire system.
Align the business functions in the product architecture concept with system functions to ensure that the business requirements are met.
Analyze the information that the system/subsystem needs to interact when running dynamic collaboration.
Build and simulate the dynamic characteristics of the entire system in the business environment, and plan the status change process and trigger
Events and constraints.
The process, content, and other auxiliary information of information transmission between subsystems are summarized in detail.
Build a physical data model based on the initial data model.
Summarize the system requirements on quality, and break down these quality requirements into subsystems.
Build the construction and evolution plan of the entire system and subsystem, and build the overall project planning and initial
.
Predict the evolution of technology based on a fixed period of time, and summarize the Application Technology and Its Evolution of the entire system.
Identify and summarize the standards that must be followed by the entire system at different stages.
Map Business constraints to subsystems and add it business constraints when necessary.
Iv. Design and Implementation of subsystem architecture
Through the above processes, we have achieved an important overall architecture baseline. All subsystems are designed
It is carried out under this huge architecture baseline constraint. At this point, the chief architect gradually fades out and designs the subsystem architecture.
Teacher. The task of the subsystem architecture designer is to continue to decompose, refine, and design various subsystems. At this stage, we will consider
For more details, we need to consider the following issues for later Component Design and unit design:
Is the function planned for this subsystem feasible?
What sub-function sets can be divided into within the entire subsystem?
Which sub-functions can be combined into some components within the scope of the entire subsystem?
How are these components and sub-function sets connected to subsystems through interfaces?
In fact, the subsystem architecture design itself is a complete system design. The difference is that the field of view is concentrated on the subsystem.
The activities at this stage are as follows:
Verify and confirm the Business Architecture and product architecture information related to the subsystem in the early stage, and supplement the information if necessary
Information.
The glossary related to the subsystem is added to ensure that all relevant personnel have the same understanding of the terms.
Splits the functions of the entire subsystem into different component nodes to build different sub-function sets,
Divide interfaces and interaction rules within the subsystem.
Summarizes subsystem/Component Interface Information for easy retrieval and browsing.
Plan the communication links, communication paths, communication networks, and other transmission media of the entire subsystem.
The sub-business functions in the product architecture concept correspond to the component functions to ensure that the business requirements are met.
Analyze the information that subsystems/components need to interact when dynamic collaboration starts.
Build and simulate the dynamic characteristics of the entire subsystem in the business environment, plan the internal state change process of the subsystem,
Events triggered and constraints.
The process, content, and other auxiliary information of information transmission between components are summarized in detail.
Build a more detailed data Physical Model Related to the subsystem based on the initial data model.
According to the quality requirements of subsystems, the quality requirements are further decomposed and quantified into various components.
Build a whole subsystem construction and evolution plan, and build a subsystem project plan and more detailed
Iterative planning.
Predict the evolution of technology based on a fixed period of time, and summarize the Application Technology and Its Evolution of subsystems.
Criteria that must be followed by the resolution and summary subsystem at different stages.
Map Business constraints to each component and add it business constraints when necessary.
V. Design of components and implementation units
The component design stage is the detailed design stage. At this stage, the main task is to set interfaces and functions.
. In the iterative model, this stage is largely completed during the iteration process, and a designer leads the entire process.
The development team conducts analysis and design.
In this process, we should consider how to make product demand changes in a small-granularity architecture not to create Product Quality
Impact, you also need to consider the relationship between the business conceptual model and the product functional block. For these questions, we
We will discuss it later with appropriate spaces.
Summary:
The success of large-scale and complex projects depends on reasonable project organization. This organizational concept includes the organization and product of human resources.
The architecture is organized in two aspects. Agile Project Management provides the thinking Foundation for the two reasonable organizations and improves the project's success.
For guarantee. A typical example is the Canadian air transportation system project in 1990s (Chief Architect: Philippe
Kruchten ). 150 programmers are organized into 6 months of long-cycle iteration. However, even in 6 months of iteration,
10 ~ The 20-person sub-system still splits the task into a series of six small iterations for one month. It is the project's
After successful practice, Philip kruchten became the author of the RUP initiative.
The proposal of agile processes directly affects the core thinking of architecture design. It is precisely because of the proposal of agile processes that we have achieved
Architecture-driven, elastic architecture, and skeleton systems. It also directly affects the demand analysis methods, project planning and estimation methods.
And other new ideas in a series of fields. It even promotes business agility and the proposal of a service-based architecture. This
The proposal of some ideas further promotes the development of software engineering to a higher level.
We will discuss several topics below, but we hope to study a way to think about the problem so as to help you understand it.
Provides a platform for thinking about broader problems. These topics do not exist independently, but are integrated into the topics discussed in this chapter.
In each phase. I once again stressed that methods and technologies will change, but excellent ways of thinking will never last forever!