We said that, unlike heavy-duty methods, which focus on planning, processes, and intermediate products, agile methods focus more on people and communication. People and communication are always the first, and planning, processes, and intermediate products are just a means to ensure communication and achieve goals. This does not mean that the Plan, process, and intermediate product are not important, but they cannot put the cart before the horse.
Note: We define intermediate products as documents, models, and, Code . For example, design documents and data models. Refer to the artifact of RUP. There are many criteria for judging the success of software. For Agile Methodology, the first criterion for success lies in the delivery of available software. In order to ensure the availability of software, the most important thing is to do a good job of demand. There are many ways to do a good job of demand (see the practice of pipeline as a requirement), but this is not the topic we discuss. For the architecture design that we want to begin, design the architecture based on requirements. This is a basic guarantee for ensuring software availability.
Context
How do we start our architecture design?
Problem
When designing the architecture, we usually mainly consider some basic problems such as platforms, languages, development environments, and databases, however, there are few questions that are closely related to the specific situation of the customer. There is even a misunderstanding that architecture design is nothing more than empty talk and rhetoric. How can we use this architecture design to guide the implementation of software?
There are endless technologies in the IT field. In the face of so many technologies, platforms, frameworks, and function libraries, how can we choose a group of technologies suitable for software?
Every customer's software has its own characteristics. How can we design an architecture that meets the customer's interests?
Software is often filled with a large number of problems. It is often difficult to figure out all the problems at the beginning, but if the problem is not solved, the risks remain high.
Solution
Design architecture based on requirements
The architecture design is to build the main pipeline of the software (Example 1 ). What are the factors for determining the width and path of the main pipeline? Obviously, it is determined by the population, geographic location, water source, and other factors of the city. The same is true for software design. Various factors in the city are various requirements in the software: functional requirements, non-functional requirements, change cases, and so on.
In general, functional requirements determine the business architecture, non-functional requirements determine the technical architecture, and change cases determine the scope of the architecture. Demand side knowledge tells us that functional requirements define what software can do. We need to design the Business Architecture Based on business needs so that future software can meet customers' needs. Non-functional requirements define some performance and efficiency constraints and rules. Our technical architecture must meet these constraints and rules. The change case is an estimation of the potential changes in the future. Combined with functional and non-functional requirements, we can determine the scope of a requirement and then determine the scope of an architecture.
From example 2, we can see examples of several requirements of our own word processing software. Real word processing software is much more complicated. The most important thing is to realize that the architecture comes from the needs. What kind of architecture is needed. Imagine if we do not have a speed requirement, do we still need to consider this design? We mentioned the impact of several types of requirements on the architecture. In fact, there is also an important requirement, that is, the needs of the environment. This is not a very important requirement, but it is especially important for deployment architecture design. After all, the software we developed must go to the "Battlefield" and it is necessary to fully consider the deployment issue.
Example 1: The establishment of tap water pipes in cities is a very complicated project. To meet the needs of each household, the tap water pipe is a large network. In such a complex network, how can we complete the laying task. The general practice is to first find the source of the problem, that is, the source of water. Build a pipeline from the water source to the city, and then design the main pipeline Based on the regional division of the city. The rest is the problem of use. Each household's pipeline will eventually be connected to the main pipeline. Therefore, although the tap water network is huge and complex. But the real main pipeline is very simple.
Example 2: We plan to develop a word processing software. The functional requirements can be summarized as formatting user input text, the non-functional requirement may be that the processing speed of a section of Text formatted with a size of KB cannot be less than 10 s, and the change case may be the release of multi-language versions. When designing the business architecture, we will focus on how to express elements such as text, images, and media. We need another technical architecture to handle speed problems, such as buffering technology, for the case of changes, we also need to consider the corresponding architecture, for example, the font is independentProgramPackage Design. |
|
From demand to Architecture
In the demand stage, we can get some intermediate products that represent the demand research results. For example, CRC cards, basic use case models, user materials, interface prototypes, interface prototype flowcharts, non-functional requirements, and change cases. Our main task in the architecture design stage is to convert the intermediate products of these demand stages into the intermediate products of the architecture design stage.
Figure 3. intermediate product of the demand stage
In fact, architecture design is to complete two tasks: analysis and design. Analysis is the analysis requirement, while design is the general structure of the design software. Many methodologies separate the analysis and design activities, but in fact they are difficult to distinguish. When doing analysis, we will think about how to design them, thinking about how to design, in turn, will affect the analysis results. It can be said that they are interconnected and constantly iterated. This form will be discussed in detail in the subsequent iterative design patterns.
In the Agile Methodology, the demand should preferably be iterated, that is, the requirement of 1.1 points. This method is especially applicable to projects with fast demand changes. Because the process we adopt is an iterative process, we will face the issue of how to deal with the intermediate product of the previous iteration. If we need to modify the existing intermediate product for each iteration, the maintenance cost will not be too large. Therefore, the basic practice of Agile Methodology is to discard intermediate products that are no longer useful. I still remember that in chapter 1, we emphasized that software is more important than documentation. The purpose of generating the intermediate product is to generate the final program. For these completed models, there is no additional maintenance cost.
Do not discard the model unless otherwise specified. Because the method of abandoning the model requires support suitable for the environment. A wide range of discussions will be held later on this topic. Here is a simple introduction:
Simplicity: simple models and simple programs. The more complex the models and programs are, the more energy you need to process them. Therefore, we try to simplify them so that they can be processed more easily.
Efficient communication channels: enhance the communication effect to reduce the need for intermediate products. Think about it. If I can get detailed information from the customer at any time, there is no need to make a thorough investigation of the demand in the early stage.
Cross-rotation of roles: developers establish a mechanism for switching roles, so as to avoid the situations where various subsystems cut data as much as possible.
Clear process: or we can call it a clear process. Process has always been a focus in methodology, and Agile Methodology is no exception. Developers can clearly understand what to do today and what to do tomorrow. The process is not for others, but for themselves.
Tools: easy-to-use tools can save a lot of time. The tools here are not only CASE tools, but also version control tools, automated testing tools, drawing tools, document production and management tools. Pay attention to cost and efficiency when using tools.
Standard and style: language barriers are a major obstacle to communication. Language is a standard and style from a certain perspective. Therefore, if a team adopts the same encoding standard, document standard, comment style, and drawing style, the communication efficiency of the team must be very high.
If you do not have any of the above environments or do not have several items, your document model will be well preserved.
Design architecture only for requirements
The purpose of designing an architecture based on requirements is not to do anything useful in the future. Sometimes, we will consider the architecture very complicated. The main reason is that we put a lot of future factors into consideration now. Or, when developing the first product, the view will make it a perfect framework. Are there any mistakes in the above two ideas? There is no error. This is just a question about investment. Some people hope to invest more in the beginning, so that subsequent investment will be saved. However, in reality, due to the uncertainty of demand, it is often difficult to reduce future investment by increasing the investment in the initial stage. The design of the framework cannot be achieved overnight, this is not a good practice. Therefore, we will focus on the simplicity and iteration process of Architecture Design in the later part, because of this reason.
Example 3:Credit System
in a bank's credit account processing system, how should we grasp the initial architecture ideas? From the perspective of demand, this credit account processing system has several features:
it is not a separate system and needs to interact with other external systems, for example, credit business systems, online banking, and data warehouse systems.
among all the requirements, the most complex is the demand for interest calculation, it requires support for multiple interest algorithms .
therefore, our architecture design starts from the global environment of the system. What are the relationships between other systems and the system? How should we design interfaces between systems. According to the requirement survey, the system interfaces are divided into four categories:
and external system interfaces of the enterprise. The credit system must be connected to the People's Bank of China system.
interface with the enterprise's internal system. The credit system must be able to provide data for Data Warehouse systems and online banking systems.
interfaces of the Peace-level system. The credit system needs to retrieve data from a level-1 account, fund, and financial system, and send data to the account and remittance system.
the specific implementation strategy is not within the scope of our discussion. However, we can see that the formulation of architecture policies is based on requirements. We can summarize these requirements into technical or platform architectures.
then there is a problem with the interest algorithm. After statistics, there are currently four interest calculation methods, and we can predict two. In the first phase, we do not need to consider the implementation of specific algorithms, but we need to consider the implementation framework of algorithms. Therefore, we naturally think that the strategy model can be competent for this job, encapsulate different interest algorithms. Our work focuses on the interface problem that defines the interest algorithm. By analyzing and comparing multiple interest algorithms, we define the initial algorithm interface, and then implement the algorithm interface through different interest algorithms. Although this interface is not complete yet, it will be gradually improved in the subsequent development process. This requirement is part of the business architecture.
considering the complex structure of the system, we adopt the layer mode as the basic structure of the system in terms of system structure processing. In addition, at each layer, we also define several sub-modules to handle specific problems. In this way, we can organize complex functions in an orderly manner.
after the above analysis, we have a simple understanding of the system architecture, but it is not over yet. An architecture should include all the basic parts of the system. Therefore, we also need to consider the bill processing, report, accounting processing and other aspects, but it takes a lot of time to consider carefully at the beginning. Therefore, we just defined a simple Original architecture, then the architecture will be improved in the subsequent development process.
|
|
Mode
The mode will help us grasp the key points. At the beginning of the book (chapter 2), the design pattern discusses the question of designing a document editor. In order to solve the seven problems caused by the design document editor, a total of eight different modes are used. The combination of these eight models is actually the architecture, because they solve the most advanced problems in the system.
In practice, we found that the architecture also exists. For example, for system structure design, we use the layer mode; for distributed systems, we use the proxy mode; for interactive systems, we use the MVC (Model-View-Controller) mode. The model is intended to solve specific problems. Therefore, we can also design the architecture based on the characteristics of the requirements.
In the example of a pet store provided by Sun, the idea of MVC mode is extended into an architectural idea to provide different interface views:
The MVC Architecture diagram provides an overview of the source image. Click here to view its source.
We can understand the hidden requirements behind the image: The system needs to support a variety of user interfaces, including HTML interfaces provided for common users and WML interfaces provided for wireless users, the swing interface provided by the Administrator and the WebService Interface Designed for B2B businesses. This is the most important requirement of the system. Therefore, the system designer needs to determine a stable architecture to solve the problem of multiple interfaces. Compared with multi-interface problems, the backend service processing logic is consistent. For example, the functions of the HTML interface and the WML interface are not very different. Separating the processing logic from the interface also provides additional benefits. You can add functions without modifying the interface, and vice versa. This is the coupling problem we mentioned in the second article.
The MVC mode can be used to solve this problem. The system uses controllers to select different interfaces for the business logic. This completes the design of the MVC Architecture. In the architecture design work, we have such a good model on hand. Why not use it?
Focus
At the beginning of architecture design, we say that architecture is an abstraction. That is to say, Architecture Design abandons the specific details and only captures the concept of the highest level of software, that is, the demand with the highest level, highest priority, and highest risk.
There must be a gradual process for us to consider, analyze, and solve a problem. Architecture design is an early stage in solving the problem. We will not invest too much time in Architecture Design (the specific reasons are discussed below ), therefore, the key point is that we must be able to grasp the needs in the architecture design. For example, we mentioned distributed systems and interactive systems in the mode section. Distribution and interaction are the key points of these two systems. Then, if we are dealing with a distributed interactive system, we need to take these two features into consideration and design the architecture based on them. The pet store examples we mentioned are similar. In addition to the MVC Architecture, there are still many design problems to be solved, such as data objects used for database access and front-end controllers used for view management, and so on (the specific architecture mode can be used to access Sun's website ). However, compared with the MVC model, these components are local and have a lower priority and can be designed after the architecture is determined.
Architecture Design and field expert
A well-designed architecture is inseparable from the understanding of requirements. Therefore, in reality, we find that experts in the business field can help developers design excellent architectures with their understanding of the business field. The architecture needs to be abstracted. It is a basic model of social activity, and it is difficult for developers to design models in the business field. In the history of ERP development, we can see that MRP has evolved into MRPII and has evolved into a closed-loop MRP. The main factor is the evolution of management ideas, that is, an improved understanding of the business field makes the architecture possible.
Therefore, we also emphasize the role of field experts in the design of the agile architecture.
(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.
