Starting from this article, we will enter another different topic, which is different from the previous model focused on organization, process, and method. The model described later will focus more on design. However, the shadows of processes and methods are still vague in our discussion.
The Architecture Vision is a very simple model, and it takes a short time in software development. However, this does not mean that the architecture vision is not important. On the contrary, it will be an indispensable part of the design process.
Context
At the beginning of a single iteration, we have collected the requirements for a single iteration.
Problem
Architecture and analysis design are inseparable. Sometimes it is difficult to clearly define the architecture, but the architecture should be able to describe the entire software. The architecture includes all aspects of the software, but every design detail always needs to be considered separately. At this time, there will be inconsistencies between the design details and the architecture.
The design conflicts between different parts of the architecture design are easy to occur. The probability and frequency of occurrence are directly proportional to the team size and inversely proportional to the frequency and Effect of communication. During many project development processes, we found multiple Code The reason is that the author of the Code does not know that someone else has implemented this function. This may be a waste of energy, but if the design conflicts between different modules lead to the failure of the software, we need to sit down and take a good look at what happened.
Solution
We need to build an architecture vision. The architecture vision should be able to provide a global view of the software, including all the important parts, defining the responsibilities and relationships between each part, and defining the principles to be met by the software design. The design of this architecture vision should meet the needs of the source model. That is to say, part of the division and part of the design are carried out according to the needs. At the same time, the architecture vision should be able to meet other characteristics of the architecture, such as simplicity, scalability, and abstraction. Simply put, we regard the architecture vision as a mini architecture design.
As we discuss the Architecture Vision in a single iteration, the overall architecture vision is constantly changing. This is natural, because the Architecture Vision represents the design of the architecture, and the evolution of the Architecture Vision represents the evolution of the architecture design.
The Architecture Vision is relative to a specific scope. Within a specific scope of software functions, talking about the architecture vision has practical significance, such as the overall situation of the software or a sub-module. In this particular scope, after an architecture vision is established, all design principles within this scope will not violate the Architecture Vision. This is very important and is the greatest use of the Architecture Vision. With this guarantee, we can ensure the consistency and effectiveness of the design. Any design can be integrated into the original architecture to make the software more perfect, rather than more dangerous.
Of course, it is not easy to do this. It is particularly important to note that the Architecture Vision Model is only a road to achieving this goal and is not a sufficient condition. If the vision cannot be implemented in the design, or there is a problem in the vision formulation itself, it is almost impossible to achieve the above effect. In addition, this mode is only the first step to achieve this goal. In the next mode, we will find that there are still many aspects to work.
Architecture Vision hierarchy
Based on the applicability of the architecture, we divide the Architecture Vision into several categories:
Software global
The global architecture of software is what we are most concerned about, so we will spend the most time.
The overall architecture vision of the software is generally difficult to be embodied at the code level. In fact, you will find that, even if it is embodied at the code level, the code will not have much value due to problems in reality. Therefore, the architecture vision set globally for the software can be embodied in principles or pattern names and described in natural language or pseudocode. For example, a system can define a three-tier architecture as its vision and point out the three-tier classification principles. Note: we need to point out the classification principle. Otherwise, the three-tier architecture does not make much sense, because the three-tier architecture varies greatly with the implementation of different platforms and developers, if an Operational Specification cannot be defined, the vision is meaningless. In the Java environment, we can say:
"The client uses the front-end browser interface, the business logic is servlet, And the JSP is used for compiling. The data sent from the browser to the server is centrally processed, the specific method is to use the front control mode between the business logic and the front-end browser, accept the data transmitted by the front-end browser, and assign it to the corresponding business logic for processing. The legitimacy test of data is divided into two parts: the basic legitimacy verification that is irrelevant to the business logic is performed on the frontend using Java script, and the legitimacy verification related to the business logic is performed on the business logic layer, you can use a centralized servlet to handle errors. "
In Windows, we know that the boundaries of the layer-3 structure are different from those in Java. Article We can directly manipulate data at the business logic layer or display layer, which is very convenient. Therefore, the Architecture Vision descriptions in windows are different. In addition, in a non-object-oriented environment, in a distributed environment, the architecture descriptions are different in the Lotus Notes environment.
Note that the architecture vision is developed based on different application environments, which we emphasized at the beginning of the article. The same problem has emerged here. We can use a simple example to deepen our understanding of this issue. In the Java environment, especially in the J2EE environment, the classic design idea is to regard a database table as a class, and each row in the table is a specific instance of this class, each field in the table corresponds to a variable of the class. The class generally supports the find method to obtain instances with different data. This is a natural design concept, and the cumbersome steps of design can be simplified through CMP and other technologies. However, in windows, I believe that not many people will do this. A common method is to use a recordset, that is, to operate on a group of records, rather than a single record. These records can be cross-table (using SQL connections) or single-table. Most Programming Language Supports the record set method. Program Is quite simple. Of course, we can also adopt the J2EE platform programming method, but it will lead to a surge in programming volume, and it is difficult to achieve the expected results. The difference between such platforms leads to the difference in the architecture vision.
In addition, we have noticed that our description of the architecture is not very careful enough. This is normal, because with the development, we will constantly improve the description of the architecture. For example, we can write the class framework of front controll, write the main Servlets, and their relationships. In this case, using UML class diagrams is a good choice. In fact, I highly recommend that you use a large number of class diagrams in architecture design. However, in actual operation, most software teams have their own architectural design ideas, and what tools are used is not the main problem.
From the demand model, we learn that the architecture design comes from the demand, while the architecture applied to the software is from the most important demand. Do you still remember the online pet store example we mentioned in that model? The system adopts the MVC mode. Sun's official documentation first explains why the MVC mode is used and what problems the MVC mode solves, and then analyzes the components of the MVC mode: model, view, and controll. In fact, every part of MVC represents a sub-system in the real code, but at present, we are very clear about what the system will look like, although at this time it is still very obscure.
Do not create a detailed plan in the global architecture vision, or generate a large amount of actual code. Because your architecture vision is not yet stable (we will discuss stability issues in the subsequent stabilization model), without your consent or proof. Therefore, from the perspective of the entire development cycle, the global architecture vision is evolving, modified, and improved with the iteration cycle.
How can we determine the completion of the global architecture vision? In general, your architecture design team can end with a consensus. If the problem domain is familiar to the team, the problem can be solved in an hour or two. Next, the design team will spread the architecture vision to the entire development team, and everyone will have a consistent understanding. Different opinions will be fed back, in this iteration cycle (if the time is relatively short) or in the next iteration cycle (if the time is relatively loose.
Sub-module-level or sub-problem-Level Architecture Vision
At this time, the architecture vision is clear, because there are already clear problem domains. For example, interface design, domain model design, and persistence layer design. The definition of the vision here is basically the same as that of the global vision. Note that you cannot violate the global vision. In terms of operation, the global vision is jointly developed by the design team, and the sub-module-level architecture vision can be assigned to the design team for responsibility, the design team should participate in the review. There are two advantages: one is to ensure that each sub-module (sub-problem) does not conflict with each other or there is a blank area, and the other is that each sub-design team can learn from others.
When designing, we can also refer to other materials, such as related patterns or specifications (Interface Design Guide ). In a team with development experience, development technology is generally accumulated. These are also important materials for reference.
In our vision at this level, we will mainly talk about the coupling between submodules (subproblems. Generally, the coupling degree between sub-modules is relatively small. For example, in a MIS system, the coupling degree between the purchase and sales modules is relatively small, and the coupling degree between sub-problems is relatively large, for example, permission design and finance, these functions will be used by each module. Therefore, we need to develop a contract interface for the submodule (subproblem ). The contract means that this interface is formal and cannot be modified at will, because this structure will be used by other design teams, it will have an unpredictable impact on other teams. The formulation and modification of contract interfaces must be approved by the design team. In addition, it is better to consider some global sub-problems in the system to mention the global vision. For example, in the example of credit accounting mentioned in the demand model, we mentioned a subproblem of interest calculation in the global vision.
Code-level vision
Strictly speaking, the vision at this level is not a real vision, but a specific design. However, to ensure the integrity of our understanding of the architecture design, we should discuss it briefly. This hierarchical vision can generally be expressed using class diagrams and interfaces. However, in the class diagram, you do not need to mark specific attributes and operations. You only need to specify the class responsibilities and the relationships between classes. The audit of this level of vision needs to be approved by the design sub-team.
The design is subdivided into this granularity, and there may be only one or two developers executing the vision design. However, the most important task is how to break down the problem and how to merge it. Decomposition mainly involves two dimensions: one is the problem size dimension and the other is the time length dimension. That is to say, You (design the sub-team owner) need to split the problem into smaller sub-problems based on the size and resolution time and hand it over to different developers. Then combine the solutions proposed by developers.
Construction Process of Architecture Vision
The source of the Architecture Vision is demand. It should be pointed out that the requirements here are mainly those aimed at the fundamental needs of the system. For example, the system is characterized by an interactive system or a distributed system. These requirements will affect the design of the Architecture Vision. Design the architecture vision based on the importance of the requirement after collecting the requirements that affect the Architecture Vision.
The design of the architecture vision does not require a complicated process or a lot of time. We have already mentioned that the main purpose of the architecture vision is to spread the design ideas in the development team. Therefore, the architecture vision includes the basic design ideas and basic design principles.
It is worth noting that there may be multiple perspectives on the architecture vision. The following describes a design model perspective. However, the actual design may also be based on the database to design the Architecture Vision. However, in the design of enterprise information systems, I recommend the design of domain classes, that is, the example discussed below.
After the Architecture Vision is designed, the focus of the problem will be on how to disseminate the Architecture Vision. To achieve the effect of achieving a unified design intent in the development team, you can consider referencing the team design model. In addition, targeted pre-project training is also an effective approach.
Architecture Mode
The architecture model is also a good source of Architecture Vision design ideas. With the in-depth research on design patterns, it is found that some of these design patterns can be expanded or changed as the basis of software design. On this basis, more designs are implemented, and these models form an architecture model. Of course, different software architecture models are also different. In applying pattern, there is an example of a typical Architecture Vision:
Suppose we need to design a Distributed Interactive System. Both distributed systems and interactive systems have specific architecture modes. The former is the broker mode, and the latter is the MVC mode. First, we need to sort the order of patterns according to the importance of the system's characteristics. It is assumed that the distributed feature is more important. First, we should select the broker mode as the basic mode of the Architecture:
Considering the interactive feature, we need to identify the model, Controller, and view from the current basic architecture based on the features of the MVC model. Both model and view are simple. They are distributed in the server and client respectively. The Controller has two options. Assume that the controller is deployed on the client, the evolution is:
In this way, the basic architecture vision has emerged. If we have more requirements, we can continue to improve. However, remember that the architecture vision should not be too complex. As we discussed in the previous section, although we are discussing the architecture vision based on the design model, there are many other perspectives on the Architecture Vision. As for how to choose an architecture vision, the key lies in the understanding of requirements.
(To be continued)
Author profile:
Lin Xing, Senior Project Manager of the Project Management Group of Chen Xun software studio, has many years of project implementation experience. Chen Xun software studio is committed to the application of advanced software ideas and software technology. Its main research direction is software process ideas, Linux cluster technology, OO technology and software factory model. You can contact him by email iamlinx@21cn.com.
