Eight, architectural vision
From this article, we will enter another different topic, and the models discussed above are focused on organizational, process, and method, and the mode described later is more important. However, the process, the shadow of the method is still visible in our discussion.
The architectural vision is a very simple mode that is also very short in software development. But this does not mean that the architecture vision is not important. Instead, it will be an indispensable part of the design process.
Context
In the start-up phase of a single iteration, we have collected a single iteration requirement.
Problem
Architecture and analysis design is unsualed, sometimes it is difficult to say the definition of the architecture, but the architecture should be able to describe the overall software. Architecture includes all aspects of software, but each design details need to be considered separately, and there will be no design details and inconsistencies between design details and architectures.
The design conflict between the various parts of the architecture design is very easy. The probability and frequency of the occurrence of the occurrence of the team are proportional to the frequency of the team, and the frequency of communication and effects are inversely proportional. During many project development, we have discovered the same function of the same function, because the author of the code did not know that someone has implemented this feature. This may just waste a little effort, but when the design conflict between different modules has caused the software to run normally, we need to sit down and look well, what happened.
Solution
We need to build an architectural vision. The architectural vision should be able to provide a global view, including all important parts, define the responsibility and relationship between the various parts, but also define the principles that the software design needs to meet. The design of this architecture, should be satisfied with the demand model, that is, partial division and partial design is based on the needs. At the same time, the architectural vision should be able to meet the other features of the architecture, such as simple, scalability, and abstraction. Simply, we regard the architectural vision as a MINI architecture design.
Since we are discussing architectural vision in a single iteration, from the whole, the architectural vision is constantly changing. This is natural, because the architectural vision represents the design of the architecture, the evolution of the architectural vision represents the evolution of architecture design.
The vision of the architecture is relative to a range, within a particular software function range, talking about the architectural vision has practical significance, such as for the global or a submodule for the software. In this particular range, after the architectural vision, all the design principles within this range will not be able to violate the architectural vision. It is very important to use the largest use of architectural vision. With this guarantee, we can guarantee the consistency and effectiveness of the design. The addition of any design can be integrated into the original architecture so that software is more perfect, not more dangerous.
Of course, it is not an easy thing to do this. It is important to note that the architectural vision mode is only a road to achieve this, is not a sufficient condition. If the vision in the design is not able to implement its will, or the vision is a problem, then it is almost impossible to achieve the above effects. In addition, this mode is only a first step in which we have achieved this, and we will find many ways in the next mode.
Hierarchical hierarchy
We divide the architectural vision into several categories discussed based on the scope of architecture applicable:
Software global
Software global architecture is our most concerned, so you will also spend the most ink.
The structure of the software in the global structure is generally difficult to be particulartry to the code level. In fact, you will find that even if it is specific to the code level, it will also cause the code not much value because of the problems in the actual. Therefore, architectural vision for software global settings can be embodied in principles, or model names, and description with natural language or pseudo code. For example, a three-layer architecture can be specified for a system as its vision, and it is pointed out of the three-layer classification principle. Note that we need to indicate the principle of classification, otherwise it is not too great to stipulate that the three-layer architecture has different differences in developers with different platforms, if it is not possible to specify an operational Normative, then the vision is meaningless. In a Java environment, we can say this: "The client uses the front-end browser interface. The business logic uses servlets, with the JSP writing, the browser to the server data is concentrated, and the specific method is in business logic and front-end browser. The Front Control mode is used to accept the data transferred from the front-end browser and assigned to the corresponding business logic processing. The legality check is divided into two parts: basic legitimacy verification of business logic is verified to use Java Script processing on the front end. And the legitimacy related to business logic is verified in the business logic layer processing, and a set of servlets can be used to deal with errors. "
In the Windows environment, we know that the three-layer structure of the three-layer structure is not the same in Java (regarding this, there will be a detailed description in the next article), we can directly manipulate directly in the business logic layer or display layer. Data, very convenient, so the description of the architectural vision in Windows is different. In addition, in an inactive environment, in a distributed environment, in the environment in Lotus Notes, the description of its architecture is different.
Note that the development of architectural vision changes according to different application environments, this point we emphasized in the beginning of the article, and there is the same problem here. We can deepen the understanding of this issue through a simple example. In the Java environment, especially the J2EE environment, the classic design idea is to make a table view of the database, and each line in the table is a specific example of this class, each of the tables corresponds to each field. A variable of the class, the class typically supports the Find method to obtain an instance of different data. This is a natural design idea, and can simplify the cumbersome steps of design by CMP. However, in the Windows environment, I believe that there is not much person to do this. The commonly used processing method is to use the record set, that is to say, for a set of records, not a single record. These records can be cross-tables (using SQL connections) or single table. Because most programming languages in the Windows environment can support recordset mode, it is quite simple to write a recordset-based program. Of course, we can also use the J2EE platform programming, but will result in the surge in programming, and it is difficult to achieve the estimated effect. The difference in this platform has led to the difference in architectural vision.
In addition, we noticed that our description of the architecture is still not careful enough, which is very normal, because with the deepening of development, we will constantly improve the description of the architecture. For example, we can write a class framework of Front Controll, write the main servlets, and the relationship between them. At this time, using the UML class chart will be a good choice. In fact, I am very highly advocated in a large number of class diagrams in architecture design. However, in the actual operation, most of the software teams have their own familiar architectural design ideas, and what tools are not the main problem. From the demand model, we learn the architecture design from demand, and architectures applied to the software are from the most important needs. Remember the example of our online pet store mentioned in that pattern? The system uses the MVC mode. The SUN's official documentation describes why the MVC mode is used, and the MVC mode solves what problems, then starts to analyze several components of the MVC mode: Model, View, and Controll. In fact, every part of the MVC, in the real code, most represents a subsystem, but in the current, we are very clear, which is approverained, although it is also very embarrassing.
Don't view in the global architectural vision to develop a very detailed plan, don't view a large number of actual code. Because your architecture vision is still not stable (we will discuss stable problems in its subsequent stabilization mode), have not yet got a certificate of consent, and have not proof. Therefore, from the entire development cycle, the global architecture vision is continuously developed, modified, and perfect with the iterative cycle.
How do we determine the completion of the global architecture vision? In general, your architecture design team can end, if the problem domain is familiar, it can solve the problem in one or two hours. Next, the design team spreads the architecture vision to the entire development team. Everyone has a consistent understanding, and the different opinions will be fed back, and in this iterative cycle (if time is more pressing) or the next iterative cycle (If time is relatively loose) consider.
Submail level, or sub-structured architecture
At this time, the architecture vision is more clear because there is already a clear problem. For example, the design of the interface, the design of the domain model, and the design of the persistent layer. The vision here is almost in nature and the global vision, and the specific example is no longer raised. But pay attention to it, you can't be contrary to the global vision. In operation, the global vision is the design team to develop, while the Sub-module-level architecture vision can be assigned to the design sub-team to be responsible, and its review is still to participate in the joint participation. There are two advantages, one is to ensure that each sub-module (sub-problem) does not conflict with each other or a blank zone, and the other is that each sub-design team can take advantage of design experience from others.
In design, we can also refer to other information, such as related modes, or specifications (interface design guidelines). In a team of developing experience, there is generally developing technology accumulation, which is also an important information available.
We mainly talk about the coupling problem between the child module (sub-problem) in this level. In general, the degree of coupling between each sub-module is relatively small, such as in a MIS system, the coupling degree of the procurement and sales modules is relatively small, while the degree of coupling between sub-problems is relatively large, such as authority design, finance, these The function will be used by each module. So, we need to develop a contract interface (sub-problem). The meaning of the contract is that this interface is formal, not able to modify, because this structure will be used by other design teams, if modified, will have an expected impact on other teams. The development of the contract interface requires the adoption of the design team. In addition, some global sub-problems in the system are best mentioned in the global vision, such as in an example in which a credit account from the demand mode, we mentioned a child problem with interest computing mode. In the global vision. Code level vision
Strictly said that this level of vision is not a real vision, but design. But in order to ensure the integrity of architecture design, it is still a simple discussion. This level of vision can generally use class diagrams, interfaces. But in the class diagram, you don't need to mark the specific properties, the operation, you only need to specify the duties of the class and the interrelationship between the class. The review of this hierarchy requires the adoption of the design of the design.
Designed to subdivision to this particle size, developers who perform vision design may only have one or two. But more important jobs is how the problem is decomposed and how to return. Decomposition is mainly considered from two dimensions, one is the problem of size, one is the time long short dimension. In other words, you (the head of the design team) needs to decompose the problem in size and resolution time into a finer sub-problem, handard different developers. Then combine the solution proposed by the developer.
Formation process of architectural vision
The source of the formation of the architecture is demand, it is important to point out that the needs here are mainly those required for system fundamentals. For example, the system is characterized by an interactive system or a distributed system. These requirements will affect the design of architectural vision. After collecting the needs of the Impact Assessment Vision, the architectural vision is designed in accordance with the importance of demand.
The design of the architectural vision does not require a complicated process, nor does it take much time. We have already mentioned that the main purpose of architectural vision is to be able to spread design ideas in the development team, so architectural vision includes basic design ideas and basic design principles.
It is worth noting that the architecture vision may have a variety of perspectives, which discusses the perspective of design mode. However, the actual design may also design the architectural vision based on the database. However, in the design of the enterprise information system, I recommend the use of the domain type design, that is, the examples discussed below.
After the architectural vision is designed, the focus of the problem will go to how to spread the architectural vision. In order to achieve the effect of the unified design intent in the development team, you can consider the team design mode. In addition, targeted project pre-training training will also be an effective approach.
Using architecture mode
Architecture mode is also a good source of architectural vision design ideas. With the in-depth research of design patterns, some of them have found some of these design patterns to expand, or change to the basis of software design. On this basis, more design is achieved, these modes form architecture mode. Of course, different software, their architectural mode is different. In the article "Applying Pattern", there is a very typical example of the "Applying" Application:
Suppose we need to design a distributed interactive system. Both distributed systems and interactive systems have specific architectural mode, the former is Broker mode, the latter is MVC mode. First we must first arrange the order of the mode according to the importance of the characteristics of the system. It is more important to the distributed characteristics in the demand here. Then we first choose Broker mode as the basic mode of the architecture: Consider interactive features, according to the MVC mode, we need to identify Model, Controller, and View from the current basic architecture. Model and View are very simple, distributed in Server and Client, in the figure, respectively. Controller has two options, assuming that the Controller here is deployed on the client, the above figure evolves to the following figure:
In this way, the basic architecture vision has already appeared. If we have more needs, you can continue to improve. However, remember a little, the architecture is not too complicated. As we discussed in the previous section, we are here to discuss architectural vision based on design patterns, but there are many ways to look at the architectural vision from other perspectives. As for how to choose the perspective of architectural vision, the key is to understand the needs.
