Agile Thinking - Methodology in Architecture Design (3)

xiaoxiao2021-03-06  108

Third, from demand

We said that the weight is different from the plan, the process and intermediate products are different, and the agile method is more important and communicated. People and communication will always be the first, and plan, process and intermediate products are only guaranteed to communicate and achieve goals. This is not a plan, process, and intermediate products are not important, but can't be inverted

Note: We define the intermediate product as documents, models, and code to be developed in order to implement cross-boundary communication. For example, design documentation, data model, etc. Refer to RUP Artifact.

There are a lot of standards for judging software success. For agile methodology, successful standards are first delivered. In order to ensure the availability of software, the most important thing is to do demand. There are a lot of ways to do demand (see practice of the need for demand), but this is not the theme we discussed. For the work we want to start, design architectures from demand, this is a basic guarantee for ensuring software availability.

Context

How do we start our architecture design?

Problem

When we are designing architectural design, we often consider some basic issues such as platforms, language, development environments, databases, but some issues closely related to customers are closely related. There is even a misunderstanding that architecture design is nothing more than writing some empty talks, and the set of words. This is the architecture design, how to guide the implementation of the software?

The technical layer of the IT industry has emerged, facing such a multi-technical, platform, framework, and function library, how do we choose a set of technologies suitable for software?

Every customer's software has its own characteristics, how can I design a structure in line with customer interests?

Software often floods a lot of questions. When you start all the questions, it is often difficult to do, but if you don't solve the problem, the risk is high.

Solution

Design architecture for demand design.

The architecture design is the main channel of laying software (Example 1). What do we develop factors such as the thickness, path of the main management? Obviously, it is determined by factors such as the population, geographic location, and water source of the city. The corresponding software design is also the same. The factors of the city are various needs in the software: functional requirements, non-functional requirements, change cases, etc.

In general, functional demand determines business architecture, non-functional demand decisions technology architecture, and the change case determines the scope of architecture. Demand knowledge tells us that functional demand defines what software can do. We need to design business architecture based on business needs to enable future software to meet customer needs. Non-functional demand defines some of the performance and efficiency of some constraints, rules. And our technical architecture must meet these constraints and rules. The change case is an estimate of the possible changes in the future, combined with functional requirements and non-functional needs, we can determine the range of demand, which in turn determine the scope of an architecture.

From Example 2, we see examples of several needs of the word processing software. Real word processing software should be more complicated. And our most important thing is to recognize that the architecture is from demand. What kind of architecture is there? Imagine if we don't have a speed request, do we need to consider this design? We mentioned that several types of demand for the architecture, in fact, there is still a very important need, which is the needs of the environment. This is not a very important need, but it is especially important for deployment architecture design. After all, the software we have developed is to "battlefield", which is very necessary to fully consider deployment.

Example 1: The setup of tap water pipes in the city is a very complex project. In order to meet the needs of each household, the tap water pipe forms a huge network. In such a complex network, how to complete the laying task. The general approach is to identify the roots of the problem, that is, the source of water. Locating a pipeline from the water source to the city, then divided according to the region of the city, design the supervisor, the rest is the problem, each of the per household is ultimately connected to the main pipeline. Therefore, although the tap water network is huge. But the real supervisor is very simple. Example 2: We intend to develop a word processing software, functional requirements can be simple to format the text of the user's input, non-functional demand may be a format size of 1000K, the processing speed of a piece of text cannot be less than 10s, and the change case may be launched. A variety of language versions. Then we are designing business architecture, we will focus on how to express words, images, media, etc., we need to have additional technical architectures to handle speed problems, such as buffer technology, and we must consider corresponding The architecture, such as the design of the font being independent of the package.

From demand to architecture.

In the demand phase, we can get some intermediate products that represent demand research results. For example, CRC card, basic use case model, user material, interface prototype, interface prototyping diagram, non-functional demand, change cases, etc. Our main job in the architecture design phase is to convert the intermediate products of these demand stages into an intermediate product in the architectural design phase.

Figure 3. Intermediate product in the demand stage

In fact, architecture design is to complete two work, one is to analyze, and the other is design. Analysis is analyzing demand, design is a general structure of design software. Maximum methodology separates the two activities of analysis and design, but in fact, the two will be difficult to distinguish, how to design when analyzing, and think about how to design how to effect the effect of the analysis. It can be said that between them is interrelated and overlapping. This form will discuss in detail in later iterative design patterns.

In agile methodology, the demand is preferably an iterative, which is to say a little bit of demand. This approach is especially suitable in projects that have changed fast demand. Since we use the process is an iterative process, here we will face the problem of how to treat the middle product of the previous iteration. If we need to modify the existing intermediate products in each iteration, the cost of this maintenance is too large. Therefore, the basic practice of agile methodology is to throw away the intermediate products that have not been used. I still remember that when I first chapter, we emphasize that software is more important than documentation. The purpose of our generation of the intermediate product is to generate the final procedure, and there is no additional maintenance cost for these models that have completed the role.

Don't break down the approximate approach to the model. Because, the practice of abandoning the model requires a suitable support for the environment. There will be a wide range of discussions on this topic. Here we make a simple understanding:

· Simply: Simple model and simple procedure. The more complicated models and procedures, and more energy needs to be used to handle them. Therefore, we simplify them as much as possible, which is more easier to handle them.

· Efficient communication channels: reduce the need for intermediate products by enhance communication. Imagine if I can get the details of the demand from the customer at any time, the previous demand research is not necessary to do.

· Cross-rotation of the role: Building a mechanism for switching roles between developers, so that the situation can be avoided as much as possible.

· Clear process: or we can call it a clear process. The process is always a key point in methodology, and agile methodology is no exception. Developers can know clearly, what to do today, what to do tomorrow. The process is not to see someone, but it is used by yourself.

· Tools: It takes a lot of time to save a lot of time, and the tools here do not only refer to the Case tool, as well as version control tools, automated test tools, drawing tools, document production, and management tools. Use tools to pay attention to costs and benefits. · Standards and styles: language is unlocked is a big obstacle to communication. Language is a standard, a style from a certain angle. Therefore, if a team adopts the same coding standard, document standard, annotation style, chart style, then the team's communication efficiency must be very high.

If you don't have any of the above environments, or have a shortcomings, the model of your document is still staying.

Designed for demand design

The meaning of the design architecture only for the demand design is not to be a thing in the future. Sometimes, we will consider the architecture very complicated, the main reason is that we put many future factors to now. Or, we make a perfect framework when we develop the first product. Is there any fault of these two kinds of ideas? There is no mistake, this is just how to look at the problem, some people want to invest more when they begin, so subsequent investment will save. However, in reality, due to the uncertainties of demand, I hope that by increasing the input of the starting phase will reduce future investment is often difficult, the frame design is definitely not able to be able to make a good one, this practice is not a good way of doing. So we focus on the simplicity of architecture design and iterative processes, which is because this reason.

mode

The mode will help us seize the focus. The design pattern is discussed in the beginning of the book (Chapter 2) discusses a problem with a document editor. In order to solve seven problems arising from the design document editor, 8 different modes are used. The combination of these 8 modes is actually architectures because they solve them are the highest level of problems in the system.

In practice, people find that the architecture is also a mode. For example, for system structure design, we use layer mode; for distributed systems, we use proxy models; for interactive systems, we use MVC (Model-View-Controller) mode. The mode is originally a solution for a specific problem, so we can design the architecture accordingly for the characteristics of demand.

Provided on the Sun website

In the case of the pet store, the idea of ​​MVC mode is expanded into the idea of ​​architecture, used to provide different interface views:

MVC architectural diagram, here provides an overview of the original image, see its source, please click

Here .

We can understand the need behind the figure: the system needs to support a variety of user interfaces, including the HTML interface provided for ordinary users, for the WML interface provided by wireless users, the Swing interface provided by the administrator, and B2B business Designed WebService interface. This is the most important requirement of the system, so the system's designer needs to determine a stable architecture to solve the problem of multi-interface. The logic of the back-end business processing logic is consistent relative to the problem of multi-interface. For example, the function of the HTML interface and the WML interface is not much different. The processing logic and interface are separated and there are additional benefits, and while adding functions, it does not involve changes in the interface, and vice versa. This is the problem of coupling mentioned in the second article.

The MVC mode is applicable to resolving this issue. The system uses the controller to select a different interface for business logic, which completes the design idea of ​​the MVC architecture. In the work of architecture design, we have a good brand on the hand, what reasons do not use it?

get the point

At the beginning of the architecture design, we say that the architecture is an abstraction, that is, the architecture design has abandoned the specific details, just seizing the concept of the software's highest level, which is the top level, the highest priority, the most risk, the most risk demand.

We consider, analyze, solve a problem, must have a gradual process. The architecture design is to solve problems in a stage of comparative early, we will not invest too much during the architecture design (specific reasons will be discussed below), so the key point is to grasp the demand in architecture design. the key of. For example, we mentioned the distributed system and interactive system, distribution and interaction in the Mode section. The focus of these two systems. So, if we face a distributed interactive system, we need to make these two features as a focus, and this is based on this, design the architecture. And the example of our pet stores is also similar. In addition to the MVC architecture, there are many design problems that need to be solved, such as data objects for database access, for view management front-end controllers, etc. (specifically Architecture mode can access Sun's website). However, these relative to the MVC mode, partial, lower priority, can be designed after the architecture is determined. Architecture design and domain experts

A architecture is designed to design, and understanding of the needs is not disconnected. So in reality, we have found that the business sector experts can help developers designed outstanding architectures with his understanding of the business sector. The architecture is an abstract, it is a basic model of real society, while models in business areas are hard to design with developers. In the history of ERP, we see that MRP has developed into MRPII, developing into closed-loop MRP, until the development becomes the current ERP, the main factors are the evolution of management ideas, that is, the understanding of the business areas, the architecture It is possible to advance.

Therefore, in the process of agile architecture design, we also emphasize the role of field experts.

Example 3: Credit System

In a bank's credit account processing system, how should we grasp the initial architecture? From a demand, this credit account processing system has several features:

It is not a separate system, it needs to interact with other systems, such as credit business systems, online banking, data warehouse systems, etc.

In all required, the most complicated is the need for its interest calculation, which requires supporting a variety of interest algorithms.

Therefore, our architecture design is first considering from the global environment of the system. How other systems and this system should design the interface between the system. Through the survey investigation, the system's interface is divided into 4 categories:

And the interface of the enterprise external system. The credit system needs to connect to the Ministry of People's Bank.

And the interface of the internal system of the company. The credit system needs to provide data to the data warehouse system and online banking system.

The interface of the peaceful level system. The credit system needs to take data from a flat account, fund, and financial system, and send data to an account, a deposit system.

The specific implementation strategy is not within our discussion, but it can be seen that the formulation of architectural strategies is based on demand. We can summarize this part of the demand as a technical architecture or platform architecture.

Then the problem of interest algorithms, we have four kinds of interest calculation methods, and there are two kinds of foreseen. At the beginning of the beginning, we don't need to consider the implementation of the specific algorithm, but we need to consider the implementation framework of the algorithm, so we naturally think that the Strategy mode can be competent and package different interest algorithms. And our focus will go to the interface problem of defining interest algorithms. Through analysis, a variety of interest algorithms, we define a initial algorithm interface and then achieve an algorithm interface by different interest algorithms. Although this interface is not very complete, it will slowly improve during the development process of the next development. This part of the demand belongs to a part of the business architecture.

Considering that the structure of the system is very complicated, we use a layered mode as the basic structure of the system in the processing of the system structure. In addition, in each layer, we also define several sub-modules to handle specific issues. In this way, we can organize complex functionality. After the above analysis, we have a simple understanding of the system's architecture, but it has not yet ended, and an architecture should include all basic parts of the system. Therefore, we also consider the bill processing, report, account processing, etc., but At the beginning, I considered a summary, which spent a lot of time, so we just simply defined an original architecture and then perfected this architecture during subsequent development.

转载请注明原文地址:https://www.9cbs.com/read-103855.html

New Post(0)