Introduction to Software Architecture Design

How to better design the software architecture is an eternal key topic in the software engineering field. Over the past few decades, the international software engineering community has made great strides in Software Architecture Design. A large number of books, articles, and documents have recorded mature experiences and achievements in this field. Software Architecture Design is often a very complex task, involving many details and aspects, and there are many topics to discuss. Due to space limitations, the following can only be based on the author's personal understanding, to select some key points of software architecture design, combined with the current popular agile software engineering ideas, I would like to share with you my experiences and experiences in software architecture design.

Architecture determines success or failure

Software Architecture is the main structure and main contradiction in the design of software products and software systems. Any software has an architecture, even a short helloworld program. The success or failure of software architecture design determines the success or failure of software product and system R & D. The attributes and features of the software architecture determine the complexity and difficulty of the software architecture design.

Over the past few years, there has been a popular saying (Management slang): "Details determine success or failure." In fact, this sentence is only half right. The details are really important. Many projects and products are lost in the execution of details. On the one hand, tactical details are important, but on the other hand, the overall strategy is equally important. We can say that "Strategy determines success or failure ". Strategic failure is like the next go game. It looks pretty and fierce in some places. If you ignore the dashboard, you will not be able to leave it empty. Is there a chance for the boss (detail) to win? It must be a medium disk.

Similarly, correct software architecture design should include both strategic and global design and tactical details (key paths. There is a wrong idea that the software architecture design should be divided into layers and packages to draw a rough outline sketch. This "paper discussion" type of architect behavior is very harmful. In fact, since the software architecture is the main structure, hidden engineering, load-bearing wall and key parts of the software architecture, the software architecture must also implement the actual algorithms and code, not only need to implement code, it also includes code that tests the architecture to ensure that the architecture meets the requirements of various functional and non-functional quality attributes is of high quality. In addition to completing the concept and model design, the software architect must participate in the actual coding, testing, and debugging to be a real hands-on practitioner, this has become the mainstream culture advocated by agile software engineering.

Two Architectures

In our daily software product and system development, we actually encounter two types of software architecture: the software architecture of the application to be developed ("application architecture" for short "), and the software architecture of the existing basic platform ("Infrastructure" for short "). These two architectures are mutually dependent and complementary. They constitute the architecture of the entire software product and system.

Examples of the infrastructure include :. net, J2EE, and other mainstream basic platforms and various public application frameworks, composed of basic library APIs, object models, event models, various development and application extension rules, and so on. Only by familiarizing ourselves with the construction details and application mechanism of the infrastructure can we effectively develop high-quality and high-performance upper-layer applications. However, it is obviously not enough to develop an end-user-oriented software application system and product to master general high-level computer programming language knowledge, basic platform architecture, and API usage knowledge, we also need to design high-quality application software that meets user requirements based on the customer's application types and features on the infrastructure.

Familiar with OOA, Ood abstract modeling technology, design principles, architecture patterns, design patterns, and other methods and technologies, not only helps us better understand and use the basic platform architecture, it also helps us design and develop a higher quality application software architecture.

Risk-driven and agile iterative Architecture Design and Development

The software architecture will evolve along with the lifecycle of software products and systems. Its Life Cycle often exceeded a project, a release, or even several years, therefore, software architecture is an extremely important asset for both customers and developers.

What development process should the software architecture design follow? Or is there a better and mature software architecture design and development process? The answer is that the 21 st century software architecture design should give priority to agile iterative development methods and methods. Unlike traditional practices, agile iterative development advocates that the software architecture adopts an evolutionary design. The architecture of a software product or system is implemented through multiple iterations or even multiple releases, it is gradually established and improved in the development lifecycle.

A good software architecture is not achieved overnight. In the process of architecture design and development, we should try our best to avoid disruptive thinking, complete the system architecture design and even detailed design through an "architecture design phase", and then follow the architecture drawings and models, in the coding implementation phase, the architecture is coded and implemented according to the figure below. The mistake of this traditional practice is that the software architecture is the model on the drawing, rather than the source code that can be truly executed with high quality. Decades of software engineering practices show that architecture design without code implementation, testing, and user validation often has unreliable assumptions, guesses, overdesigns, and excessive engineering, it is easy to cause waste and rework, resulting in a high failure rate.

Risks are any potential factors and problems that may impede and lead to software product/system R & D failures. Software Architecture is the main contradiction between software products and system R & D and the main technical risks. The quality of software architecture determines the quality of the entire software system and product. Uncertainty is often the biggest potential risk in software architecture design. Therefore, the design and development of software architecture should follow the risk-driven principle and maintain a list of risk issues from the beginning to the end of the entire development lifecycle, based on the real-time and dynamic changes of risks, the primary architecture risks are resolved and handled, and secondary architecture risks are resolved and handled in sequence.
Visual Modeling of Architecture Design

The difficulty of software architecture design comes from the complexity of software design issues. A complex software system often has a large number of complicated details and uncertainties that are hard to be understood by humans. Abstract and modeling are methods that humans have mastered since their birth to understand complex things. Therefore, the software design work that humans are engaged in is essentially a process of continuous modeling. Through various abstract models and views, we can understand the complex software architecture from different levels, macro and micro perspectives to ensure correct and effective design.

Some people think that "software architecture is source code" and "source code is design ". This is actually one-sided. What is real software? We know that the real software that can be executed on a computer is actually binary code 0 and 1. With the help of compilers, we translate advanced programming languages into underlying assembly languages and machine languages, no one can directly and completely view the actual running status of the binary program on the CPU (runtime ), most people can only indirectly and dynamically observe the running fragments of these real software through various debugging tools and window views. Therefore, the source code of design time (such as Java, C #, and C ++) is essentially a model. Although it is a static model that can be executed after processing, but obviously they are not the whole of real software and software architecture. It can be seen that the source code model (sometimes called the implementation model) and the UML model are both a model of the software architecture (logical reflection). The difference lies in the different abstract layers. The complete software architecture (Architecture) includes not only the source code (Implementation Model), but also the requirement model, analysis model, design model, implementation model, test model, and many other models, the software architecture itself is a set of models.

UML and sysml are currently popular Visual modeling languages for software/system architecture. Before writing the actual code, use the package diagram, class diagram, activity diagram, InterAction diagram, state diagram, and other standard graphical symbols to model the software architecture, discuss and exchange various feasible design schemes, discover potential design problems, and ensure the correctness of the abstract design before the specific code is implemented, practice has proved to be a very effective, efficient, and agile way of working.

Reuse of Architecture Design

Reuse is a basic means and main way to achieve efficient and high-quality product and system development in software engineering practices. Through organized, systematic, and effective reuse, we can often improve the efficiency by more than 10. The more reuse of an excellent and long-term Software Architecture (for example, some mainstream framework software) itself or its components, the more value it represents. Software reuse involves various scopes, layers, granularities, and types, including function reuse, class reuse, component/Component reuse, and library (API) reuse, in terms of framework reuse, architecture reuse, Pattern Reuse, software design knowledge, and idea reuse, the efficiency and effect of reuse vary.

After decades of development, software engineering has accumulated a large number of software architecture patterns and design patterns. They record and possess a large number of mature and verified software design knowledge, ideas, and experiences. We usually use and call basic platforms, mainstream frameworks, and APIs, which is the most common form of reuse. An excellent and mature software R & D organization will inevitably collect various software design knowledge and experience in daily development, establish and maintain a software reuse Knowledge Base Based on architecture and design patterns, and actively and frequently use various software models to solve practical engineering problems.

Framework is a type of software with high reusability. It has a flexible and highly scalable software architecture for a type of application or field. So how can we design Reusable Software Architectures or their components? Abstract analysis and design technologies such as OOA and Ood are an important method. In practice, people often find that the more abstract they are, the wider their adaptability is, and the higher their reusability is. On the contrary, the more specific they are, the narrower their adaptability is, the lower the availability. Reuse means to make full use of existing and existing things and achievements to solve new problems or duplicate problems, so as to "remain unchanged" and "renew ". In the software architecture design, we should take the initiative to distinguish between "unchanged" and "variable" in the software architecture, and systematically manage these stability points and change points to adapt to future changes, this is also an important way to improve the software architecture reuse and obtain high-quality framework design.

Architecture Design trade-offs

As in all other engineering industries, software engineering is essentially a science and art that focuses on trade-offs. The most difficult part of software architecture design is how to make optimal trade-offs under various constraints of mutual competition and conflict. The trade-off level of software architecture design is also the best place to reflect the design experience, capabilities and skills of software architects.

In the process of software development and software architecture design, from selecting a platform, to selecting a language, selecting a framework, selecting a design mode, and selecting a tool... And so on. We need to make trade-offs from time to time and make reasonable judgments on various candidates. Under the guidance of architects, software R & D teams often need to focus on the short-term and long-term objectives, quality and speed and efficiency, quality and cost, functions and performance, flexibility and complexity... Many conflicting design options, factors, and constraints are carefully weighed, careful, and rational.

Rational trade-offs mean scientific decision-making. Effective architecture design trade-offs are inseparable from scientific methods, that is, how to use techniques such as quantitative analysis and qualitative analysis, causal logic, and root cause analysis, find the final dessert (sweet spot ). In many cases, the ability to make rapid, decisive, and correct scientific trade-offs and trade-offs within a short period of time constitutes part of the core competitiveness of a software R & D team.