Read Software Architecture Design

1. Transferred from Baidu Encyclopedia "MVC mode ":

Http://baike.baidu.com/view/739359.htm

 

2. Key requirements determine the architecture

The software architect does not have time to conduct in-depth analysis on "all requirements". This is a reality-most projects are facing pressure on the project schedule. The software architect must decide the architecture design scheme within a certain period of time; otherwise, without adequate technical guidance provided by the software architecture and sufficient restrictions on division of labor and collaboration, team development in the future will face great risks.

Software architects do not need to conduct in-depth analysis on "all requirements". This is a strategy-to spend most of their time and energy on the most important part of the decision-making architecture, so that the steel works well, in the end, the quality of the software architecture you designed will be higher; otherwise, the analysis of all requirements will not be deep enough, resulting in the final design of the software architecture may flow into the form.

 

3. The key first step is to narrow down the scope.

"John Grillos, my first boss, once said that he would fight for it. The battle selection criteria are as follows: they must be important, they must be possible, and they must be fewer ."

 

4. FAQs in practice

Problem 1: complain that the time left for architecture design is too short, rather than accepting the reality that the project pace is generally accelerated.

Basically, this is a business background that is not realized that software development is rooted in-of course, I believe it is more or less affected by the waterfall model. Whether for enterprise or individual businesses, in a complex and rapidly changing economic environment, under the conditions of competition from competitors, software systems are too slow to be put on the horse, which poses huge risks. In the 50th issue of non-programmers, there was a paper from Markus völter and Jorn Bettin, "model-driven software development model". the development period of new commercial applications cannot exceed 9 months:

......

Deliver code at least every three months.

Ideally, code should be deployed to the product every three months for actual feedback.

New commercial applications must be developed within nine months. Otherwise, the life of the "mother" (Development Group) or "baby" (Application) may be endangered ......

 

 

Question 2: All requirements must be analyzed in detail. Only in this way can the software architecture meeting all requirements be designed.

This is often seen in historical novels, but it often appears in brave military commanders. Similarly, if you want to analyze all the requirements, have you ever thought: Is this true? In a limited period of time, the problem is often caused by excessive energy distribution.

Our strategy is: the key requirements determine the architecture, and the rest of the requirements verify the architecture.

Following the strategy of "fully understanding the needs", it is easy to ask: Are you talking about Waterfall development? Of course not. Our strategy is: During the architecture design period, key requirements determine the architecture, and other requirements verify the architecture. That is to say, the "key requirements determine the architecture" and the "comprehensive understanding of the needs" strategy are not in conflict.

Non-critical requirements can be used to verify the architecture. For example, the architecture scheme is reviewed from the perspective of non-critical requirements.

 

 

Question 3: the software architecture must be a perfect technical solution.

In this regard, Philip Kruchten explicitly criticized the Common Misconceptions about Software Architecture in his paper, and pointed out that the Architecture is "enough ":

Generally, time is critical for system architecture design. Architects do not have time to systematically study every possible solution to find the best solution. Instead, they must make quick decisions so that software development can proceed. Project development is like a "battle". If you find the best solution, you are afraid that the entire "battle" has already ended. This is obviously meaningless. I often describe the architect's work like this: when something is not completely clear, quickly make a series of design decisions that are not perfect. The architecture is not static, so it cannot be optimized to the best-neither the design constraints nor the thorny issues will remain unchanged for a long time and you will find the best solution. The architecture should not be perfect, but satisfied. (Usually, time is of the essence when designing system ubuntures. the specified ts have no latitude to systematically study all possible solution paths and their combinations in order to come up with the optimal solution; they must rapidly make decisions to allow work to proceed. there is no point in coming up with the ideal solution after the battle is lost. I often describe the life of a software architect as a long and rapid succession of suboptimal design decisions taken partly in the dark. it is not a static function that we are optimizing anyway. neither the constraints nor any parts of the problem are static enough for long enough to approach anything "optimal ". architecture is not about the optimal, or ideal; it is about the adequate, or satisfactory .)

 

5. How to determine key requirements-priority of requirements

Key requirements for software architecture include functional requirements, quality (attributes) requirements, and business requirements.

The key functional requirement for the software architecture is that it involves the most (or serial) modules, the most typicalFunctional requirements.

The quality attribute requirements that are critical to the architecture are those that are supported by trade-offs and final decisions.Quality attribute requirements.