Software Architecture Design Study Notes & excerpt (1)

Architecture concept

In the software industry, the concept of architecture has never been a complete and unified definition. The concept of software architecture is divided into major factions: composition and decision-making. Consortium believes that the software architecture is: the architecture of the software system describes the system as a computing component and the interaction between the components. The "component" is a broad element, it does not refer to specific technical components. The definition of composition School focuses on the objects in architecture practice-software, and software itself is the descriptive object. In addition, it analyzes the composition of software, that is, software is composed of components that undertake different computing tasks, these components interact with each other to complete high-level computing. The decision-making school believes that the software architecture protects important decisions on some issues in the software design process. The software architecture not only focuses on the structure and behavior of the software, but also on other features: usage, functions, performance, elasticity, reuse, comprehensibility, economics, and computing constraints, trade-offs, and aesthetics. The decision-making school's definition focuses more on the subject-person in architecture practice, describes the object of human decision-making, and summarizes the types of architecture decision-making, it is pointed out that architecture decision-making includes not only the Organization, element, subsystem and architecture style of software systems, but also the decision-making on a large number of non-functional requirements.

More broadly speaking, the decision-making school focuses on the architecture process. The author believes that,The architecture is an evolution process. There is no static architecture, and there is no one-stop architecture. The architecture needs to be adjusted based on the business development, therefore, we should pay more attention to the evolution of the architecture and the reasons, as well as the trade-offs and compromises made in the Context at that time. There is no perfect architecture, and there is no standard solution for the architecture, because there are different architectural design solutions for different business needs and different objective factors, that is, there are different design decisions. The architecture concepts of the Composition School and the decision-making school are not in conflict. They are just different perspectives: in actual software architecture, these two "school" architecture concepts are always embodied at the same time.

Architecture decisions are made in different layers. The decision-making sequence is usually the process of making decisions that are not relevant to the technology, and then the technology-related decisions. The latter is guided by the former. Architects must consider more technical issues involved in actual development, so as to continuously refine the architecture scheme so as to provide more guidance and restrictions for developers, in order to reduce the major technical risks in subsequent development. Therefore, the architect's architecture scheme is not high, but must be implemented. The architect must participate in solving the technical details encountered during the implementation process. In this way, architects can seamlessly connect with developers and architecture solutions can guide developers in development.

 

Subsystem, framework, and architecture

A good architecture must separate each focus. Package the change points in different parts of the software system in a different way (I feel that the idea of encapsulation is everywhere in software engineering !), To this end, you must separate the concerns. Through separation of concerns, we can achieve the goal of "a part of the system has changed without affecting other parts. You can use the following methods:

1. Separation of concerns by division of duties. The key to object-oriented design is responsibility identification and allocation. Whether it is an object, a module, or a subsystem, their responsibilities should all be highly cohesive. Otherwise, the loose coupling between objects will lose the foundation and become an empty talk. Therefore, we have been proposing "High Cohesion and low coupling". High Cohesion is the basis for low coupling. The frequently used design and architecture modes provide a general division of duties solution for repeated problems in a specific context, which is also a problem solution.

2. Separation of concerns by using the versatility of each part of the software system. Different degree of universality means that the possibility of change is different. This is similar to the reuse and release Equivalence Principle in object-oriented design.

3. Consider subsystems with a large granularity, while temporarily ignoring how subsystems are made up by smaller granularity modules and classes. To avoid getting into too many details, the so-called "Forgetting" means that architects must have the ability to think at a higher level.

Separation of focus based on duties, separation of focus based on versatility, and separation of focus based on different levels of granularity are three ways of thinking that are located in different "dimensions". We can use these methods comprehensively.

 

Whether it is an architecture or design model, the focus is on how to provide a "Collaboration model", which defines the responsibilities of different role locks in collaboration, achieve the goal of "providing solutions for problems in specific contexts.

The framework technology helps to separate general points of attention and special points of attention. The result is better modification and reusability.

As an architect, you must consider the question of "how a software unit makes up a more granular whole. Classes, modules, subsystems, systems, and integrated systems are all specific forms of software units, but with different granularities. The more complex the software system is, the more levels of decomposition at different granularities. The so-called system refers to a logical entity composed of multiple elements. It fulfills a specific set of goals or bears certain responsibilities. The system can only contain software, hardware, or both. A subsystem is a special system, but in a specific context, it appears as part of a larger system. System architecture design is required, and architecture design is also required if subsystems are complex enough. Different types of software systems require different software architecture designs. Different subsystems of a system should also have different software architectures.

Of course, the granularity of a system is relative. In different scenarios, the same software unit is regarded as different granularity. All systems have subsystems, and all systems are subsystems of larger systems. Different scenarios make software component units progressive. By understanding the details, software architects can easily ignore the details that should be ignored and grasp the overall design situation.

Framework is a semi-finished product. Is a semi-finished product of a software system or subsystem that can be extended through a callback mechanism. To some extent, the framework aims to reuse software. Software reuse itself has an internal contradiction, that is, the contradiction between reuse probability and reuse value, reuse probability and reuse value. The larger the granularity of a software unit, the smaller the chance of reuse, but the greater the value it brings. On the contrary, the smaller the granularity of the software unit, the greater the chance of reuse, however, the value of reuse is smaller. The wisdom of the framework lies in this: in order to maximize the value brought by reuse, the easily changed parts are encapsulated into expansion points, and the callback mechanism is used to include them within the control scope of the framework.

One of the most common misunderstandings about the software architecture is to confuse the architecture (acrchitecture) with the Framework. The framework is software, but the architecture is not software. A framework is a special software that does not provide a complete solution (specifically, it does not provide a complete solution for business applications, the framework itself is also designed to solve a certain type of problems), but provides a good foundation for building a solution (the solution here is the solution for business applications). Therefore, the framework is a semi-finished product. Services in the framework can be directly called by the final application, and the extension points in the framework are the "changeable points" customized by developers ". Software architecture is not software, but an important decision on how to design software. Software Architecture decision-making involves how to break down a software system into different parts, static structural relationships and dynamic interaction relationships between parts, etc. These architecture decisions will be reflected in the final software system. After the software framework is introduced, the entire development process is divided into two steps, and architecture decisions are often reflected in the Framework. The software architecture is an abstract level higher than the specific code. The architecture is bound to be reflected and followed by the code, but any specific piece of code does not represent the architecture (here it is a bit absolute. A specific piece of code cannot represent the entire architecture, sometimes it can represent a certain architecture decision ). The emergence of framework technology and architecture technology is to solve the difficulties brought about by the increasingly complex software systems and adopt the idea of "divide and conquer. First, the overall situation is followed by a local structure. First, the architecture is available and then dedicated. Architecture is an abstract solution to the problem. It focuses on the overall situation and ignores details. The framework is a common semi-finished product and must be further customized and developed based on specific needs before it can be converted into an application system. Of course, the framework also has an architecture and is very important. The framework and architecture are different and related. The former is a special case of composite components, and the latter is the overall design of composite components. The software architecture needs to be implemented and detailed, but there is no need to implement all design decisions in detail, but to focus on "important decisions ". The scope of decision-making for software architecture design should be focused on the design that "affects the global", rather than all design details.

For object-oriented development, class libraries and frameworks have many similarities, but they are indeed different. A class library is a collection of classes, which may be independent of each other. Compared with the class library, the framework and the class library share similar forms, that is, the framework is often a collection of classes, but the difference is that the classes in the framework are not isolated, the business logic code in the Framework "connects" different classes and establishes collaboration between them. The framework encapsulates the control logic of the processing process to make it transparent to developers and simplify development. This encapsulation is also one of the differences between the framework and the class library.

The framework can be divided into three categories: Application Framework, middleware framework and infrastructure framework, forming a macro structure of "Application Software-middleware-Infrastructure. Frameworks can also be divided into technical frameworks and business frameworks. The technical framework is also called a horizontal framework, and the business framework is called a vertical framework. The entire development process of the framework consists of four major stages: analysis, design, implementation, and stability. Like application development, framework development must first determine the scope and objectives of the framework. Both the framework layer of a specific domain and the Cross-Domain framework layer should identify common points and expansion points. Second, they should design the framework architecture and use it as a blueprint for the implementation phase. In the design phase, you can also create an application framework prototype, then build a sample application on it, and gain insight into potential improvements in the framework design. Corresponding framework documents should also be provided in the stable stage of framework development. The development of object-oriented technology greatly improves the capability of the framework and promotes the widespread acceptance of the framework technology. An Object-Oriented Framework consists of specific classes, abstract classes, and interfaces. Abstract methods are the key to object-oriented support for "polymorphism". The object-oriented framework uses Abstract methods to implement reverse control. While using abstract methods to support extension, many object-oriented frameworks also use "configuration-driven" to reduce the difficulty of using the framework. Architecture design is also required for the Framework, but in turn, it can be achieved through the architecture framework to achieve the purpose of "Architecture reuse.

 

Role of software architecture

The software architecture plays an important role in software maintenance and even software upgrades with significant changes. Because the software architecture provides a global perspective of the software system. The constant modification of the software system will make the system architecture slowly become chaotic, because the business development will gradually corrode the existing system architecture, so the architecture needs to evolve according to the business development.

Why is software architecture design so difficult? Because it is a bridge that spans the gap between the real world and the computer world. From business-oriented needs to the final technology-oriented software system, we must bridge a large gap. The software architecture design is to complete the transformation from business-oriented to technology-oriented, and build a bridge between the gaps. The software architecture includes important decisions in terms of structure, collaboration, and technology, and lays the foundation for systematic development activities.

The architecture has the following functions:

1. Fulfill the business objectives: fulfill the business objectives for overall planning.

2. Technical Decision-Making below: The software architect converts business-oriented requirements into technical-oriented software architecture design solutions, which provides practical guidance and restrictions for subsequent technical development work.

3. control complexity: the architecture design is implemented first, and then detailed design and coding implementation are carried out. The concept of "in-depth isolation and governance based on problems" is used to exploit the complexity of control.

4. Organizational Development: the software architecture lays the foundation for systematic team development. It defines how each element of the software system makes mutually relevant design decisions, in this way, different modules can be allocated to different groups for parallel execution, and the software architecture design scheme plays a "bridge" and "cooperation contract" among these groups.

5. iterative development and incremental Interaction

6. Quality Improvement: a clear software architecture separates the responsibilities of each module, and each module has a clear interface, which indirectly reduces the development difficulty.

 

The software architecture will be "worn out"-as software systems are constantly being modified, the software architecture will become messy.

Software Architecture restructuring refers to making major changes and adjustments to the software architecture to meet new requirements and development and maintenance needs. Software Architecture reconstruction is a "re-engineering" situation. It generally goes through three steps: reverse engineering, re-planning, and forward engineering. Only by fully understanding the design ideas of the original architecture can we assess the "benefits" and "disadvantages" of the current demand, retain a reasonable design, and modify the improper design.