Software Architecture Concepts

Http://www.cnblogs.com/seaskycheng/archive/2009/11/23/1608943.html

A few days ago, a few former colleagues came to my house to play, during which we discussed the current popular software architecture. Most of these colleagues now turn to software architect engineers and some want to grow into software architect engineers. The common feeling is to put aside specific projects to talk about software architecture is very simple, is not the Rup 4+1 view and software architecture documentation. But for specific projects, always feel overwhelmed, do not know, the design of the software architecture work products have never been the leadership and colleagues to recognize, not some problems leadership and colleagues feel not clear, that is, some things leaders and colleagues feel too Russell or complex lock. I have been asked to talk about what the software architecture should contain and how it should be done, based on years of experience in software architecture.

And I have always focused on learning a theoretical knowledge of the spirit and the guiding ideology and the combination of specific work how to apply, not too much attention to the concept and theory, so we ask this question, I although the knowledge of the concept of software architecture and ideological understanding there is a certain ambiguity, but I also can not explain to you understand. But I use one of the projects mentioned in the example, from a number of points to point out that everyone's understanding and correct practice, said a lot, finally see a bit of imitation of the expression of dawu and vaguely have a lot of doubts, I have to say, I look back a good idea, a few days to discuss with you.

It's just this. Once I went to the ZTE Network letter interview, and a senior leader once again privileged to talk about the topic of software architecture. The senior leader had an interview problem and asked me to define the software architecture according to my own experience. I have deep search from the depths of memory, I always focus on learning a theoretical knowledge of the spirit and guiding ideology and how to apply the specific work and not too much attention to the concept and theory, and secondly, I remember all the software architecture learning books and materials to avoid a unified definition of software architecture, We are all from the respective explanations and focus on the point of view is elaborated. So I also from the work experience to the software architecture from a number of different angles of my power to the explanation and explanation, said a lot. Finally, the senior leader said that I from the perspective of divergent thinking of the software architecture of the more detailed elaboration, but can from the perspective of convergence of thinking on the software architecture to make a concise definition. I shook my head, and it was hard to explain it with a thin statement. Instead, the senior leader summed it up in one sentence: Software architecture is the main element of a software system and the relationship between these elements.

Although I did not receive ZTE's reply, but, when I heard the summary of the leadership, I really wanted to simply astounding-although I still vaguely feel that the definition or missing something important.

Instead, I re-studied all the books and materials that I learned about software architecture and searched the Internet for knowledge. By following the definition of this senior leader and combining work experience and re-learning, I define the software architecture: The main elements of the software system, the important constraints and 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 of all, 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 are the main elements rather than all the elements. First, from the point of view of the needs of users and mainly focus on the core business needs to meet, if the core business needs can not be met, everything else need not say. This is like to buy a mobile phone, if the phone can not be normal call, is again beautiful, there are more auxiliary functions, can not become a mobile phone, it will not be bought. Software architecture, as a tool for communicating with stakeholders such as customers, does not focus on how to meet the requirements of these core business needs, and loses its meaning. If you can effectively grasp these major core business needs, it is not far from the success of software projects. Second, from the reality of software project development, most software projects are faced with the pressure of the project duration, the software architect must decide the architecture design plan within a certain time, otherwise there is no sufficient guidance of the technology provided by the software architecture and sufficient limitations on the division and collaboration, the development design coding team will face the risk of project failure. So the software architect doesn't have time to analyze all the elements in depth. Third, the human energy, ability is limited, if the main energy and time can not be spent in determining 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 analyzed and not deep enough, such a software architecture can only be a mere formality of the software architecture, To improve the quality of software will not help but can harm the software project failure.

The most easily overlooked may be important constraints. Before explaining the importance of important constraints look at such an example: C/S software system needs to achieve a small amount of high concurrent real-time network communication, for most experienced software architects will abandon the select mode of 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 entire software system architecture is facing a huge impact: Linux does not support IOCP at all. You must use Epoll. Therefore, there are some hidden requirements in many constraints, which affect the software system through the following three paths: first, direct control of design decisions. As the above example, the architecture engineer must follow directly and influence the key decisions. Second, the extension and transformation into functional requirements. In this case, the elements of the software system may be increased, and if the necessary instructions are not made in the software architecture, the stakeholders of the software project may be puzzled by these "sudden bursts" of elements. Third, extended and converted to non-functional requirements. This situation can also affect key decisions.

It can be said that each step of the software architecture process is a series of important design decisions. But the hardest thing to understand is how the software architecture contains decisions. Here are two misconceptions: one is that the software architecture is a 4+1 view of RUP and a software architecture document, so these decisions cannot be explained. The second is that every design pattern and framework introduced in the software architecture actually shows a series of decisions. So while people don't understand how software architectures include decisions, every architect is unconsciously involved in making decisions. I propose that I want to proactively include these key decisions in the architecture process.

The main elements, the important constraints and the key decision-making have explained the components of the software system from the local static isolation, and the relationship between them is how they compose an organic software system as a whole, and how to cooperate with each other is to explain the behavior of the software system from the dynamic point of view. How to meet the different stakeholder needs of software systems.

I decided to use the way the blog to learn the software architecture, is the knowledge of their own understanding or one-sided side, I hope to write their own learning experience, one can exchange, share, save, and hope that the same will be willing to enlighten the same can be constructive brick, help me improve.