Software Architecture Concepts

A few days ago, a few former colleagues came to my home to play, during which we discussed the current popular software architecture. Most of these colleagues are currently working with software architect engineers, and some want to grow into software architecture engineers. The common feeling is to put aside specific projects and talk about software architectures that are simple, not Rup's 4+1 view and software architecture documentation. But for specific projects, always feel powerless, not to start, the design of the software architecture work products must not be led and colleagues of the recognition, not some problems leaders and colleagues feel not clear, is that some things leaders and colleagues feel too Russell or complex lock. I've been asked to tell you what the software architecture should be, and to what extent, based on years of experience in software architecture.

And I have always focused on learning a theoretical knowledge of the spirit and guiding ideology and combined with the specific work how to apply, not too much focus on the concept and theory, so we ask this question, although I know that the concept of software architecture and understanding of the existence of a certain fuzzy, but I can not explain to you. Instead, I use one of the projects I've mentioned as an example, from a number of aspects point out that everyone's lack of understanding and correct approach, said a lot, and finally see a little imitation of the dawu of the expression and vaguely have a lot of doubts, I have to say, I will go back to tidy up the idea, after a few days to discuss with you.

Just this one time I went to the ZTE Network letter interview, with a senior leader once again privileged to talk about the topic of software architecture. The senior leader gave me an interview question and asked me to define the software architecture according to my own experience. I had a deep search from the depths of memory, I have always focused on learning a theoretical knowledge of the spirit and guiding ideology and combined with the specific work how to apply and not too much attention to the concept and theory, and I remember all the software architecture learning books and materials are avoided to the software architecture for a unified definition, We are all from their respective explanations and focus on the point of view of the exposition. So I also from the work experience of the software architecture from a number of different angles I have the ability to explain and explanation, said a lot. Finally, the senior leader said that I have a more detailed description of the software architecture from the perspective of divergent thinking, but we can make a concise definition of software architecture from the angle of thinking convergence. I shook my head and it was hard to explain it in a streamlined statement. But this senior leader in a nutshell: Software architecture is the main element of software system and the relationship between these elements.

Although I did not receive a reply from ZTE, but when I heard the leader's generalization, I really wanted to astounding-though I still vaguely felt that the definition was missing something important.

But I have all the Learning software architecture of books and materials to learn again, and online search related knowledge. Or to follow the definition of the senior leader and combine work experience with learning experience, I define the software architecture: the main elements of the software system, the important constraints and the key decisions, and the relationships between them and how to interact with each other to meet the different stakeholder needs of the software system .

First, talk about the main elements. The elements mentioned here include not only interfaces, classes, components, but also frameworks, subsystems, stand-alone programs (such as database servers), pipelines, messages, and so on. Why is the primary element, not all elements. First, from the point of view of the needs of users and primarily focus on the core business needs to meet, if the core business needs can not be met, everything else need not speak. This is like to buy a mobile phone, if the phone can not be normal call, is again beautiful, there are many auxiliary functions, also can not become its mobile phone, there will be no one to buy. Software architecture, as a tool to communicate with clients and other stakeholders, cannot focus on how to meet the requirements of these core business needs, and lose its meaning. If you can effectively grasp these major core business needs, it is not far from the success of the software project. Second, from the reality of software project development, most software projects face the pressure of project duration, the software architect must decide the architecture design plan within a certain time, otherwise there is no sufficient guidance to the technology provided by the software architecture and sufficient limitation to the division of labor, the development design coding team will face the risk of project failure. So software architecture engineers don't have time to analyze all the elements in depth. Third, the human energy, capacity is limited, if you can not spend the main energy and time to determine the success of the software project core business needs, but all the software requirements and elements, and ultimately lead to all the requirements and elements are not in-depth analysis, such software architecture can only be a mere formality of the software architecture, To improve the quality of the software will not help but damage the software project failure.

The most likely to be overlooked is an important constraint. Before explaining the importance of important constraints, look at such an example: C/S software system needs to achieve high concurrent real-time network communication with little information, for most experienced software architect engineers will abandon the select mode, whether synchronous or asynchronous, blocking or non-blocking socket communication mode, and will choose IOCP. But if the software system has a running constraint: The system must run under Linux, the architecture of the entire software system is facing a huge impact: Linux does not support IOCP. You must use Epoll. Therefore, many constraints in fact hidden some of the requirements, it is through the following three ways to affect the software system: first, direct control of design decisions. As the above example, the architecture engineer must follow directly and affect key decisions. Second, the extension and transformation into functional requirements. In this case, the elements of the software system may be added, and if no necessary instructions are made in the software architecture, the stakeholders of the software project may be puzzled by the elements that "suddenly come out of nowhere". Third, the extension and conversion to non-functional requirements. In this case, the key decisions may also be affected.

It can be said that every step of the software architecture is a series of important design decisions. But the hardest thing to understand is how the software architecture includes decisions. Here are two misconceptions: one is that the software architecture is the RUP's 4+1 view and software architecture document, so it is not possible to explain these decisions. The second is that every design pattern and framework introduced in the software architecture actually shows a series of decisions. So while people do not understand how software architectures contain decisions, every architectural engineer is unconsciously involved in making decisions. I am proposing that I want to consciously include these key decisions in the architecture process.

Main elements, the important constraints and key decisions explain the components of the software system from the local static isolation, and the relationship between them is to show how they compose an organic software system as a whole, and how to collaborate with each other is to explain the behavior of software system from the dynamic point of view. How to meet the different stakeholder needs of software systems.

I decided to use blogging as a way to learn about software architecture, is the knowledge of their own understanding or one-sided side, hoping to write their own learning experience, one can communicate, share, save, and I hope that there will be generous enlighten the same can be a constructive pat brick, help me improve.