Software Architecture Style

Readers may think that "the software architecture is too abstract, too theoretical, and there is nothing practical ". However, any practice must be guided by the theory. If we abandon the theoretical basis and blindly pursue practicality, we can only swallow the question.
A core issue in software architecture design is whether repeated architecture models can be used to achieve architecture-level software reuse. That is, whether the same architecture can be used in different software systems. For this purpose, scholars began to study and practice the style and type of software architecture.
The software architecture style is the usual pattern used to describe the system organization mode in a specific application field. It reflects the structure and Semantic Features shared by multiple systems in the field, and guides how to effectively organize modules and subsystems into a complete system. In this way, the software architecture style defines the glossary used to describe the system and a set of rules that guide the component system.
The Research and Practice of the software architecture style promotes the reuse of the design. Some proven solutions can also be used reliably to solve new problems. The unchanged part of the architecture style allows different systems to share the same implementation code. As long as the system is organized using common and standardized methods, other designers can easily understand the system architecture. For example, if someone describes the system as a "customer/Server" mode, we don't have to give design details, and we will immediately understand how the system is organized and working.
The following describes the classification of General Architecture styles by Garlan and Shaw:
(1) data stream style: batch processing sequence; pipeline/Filter
(2) Call/return style: Main Program/subroutine; Object-oriented style; hierarchical structure
(3) Independent Component style: Process Communication and Event System
(4) Virtual Machine style: Interpreter; rule-based system
(5) warehouse style: database system; hypertext system; Blackboard System
In this article, we will only introduce several major and Classic Architecture styles and their advantages and disadvantages. The new software architecture style will be introduced in subsequent articles.

I. C2 Style
The C2 architecture can be summarized as follows: a parallel component network that is bound together by a connector and operates according to a set of rules. The system organization rules in the C2 style are as follows:
(1) components and connectors in the system both have a top and a bottom;
(2) The top of a component should be connected to the bottom of a connector, and the bottom of the component should be connected to the top of a connector. direct connection between the component and the component is not allowed;
(3) A connector can be connected to any number of other components and connectors;
(4) When two connectors are directly connected, the bottom of one of them must be directed to the top of the other.
Figure 1 is in the C2 style. In the figure, the connection between components and connectors reflects the rules for building a system in the C2 style.

Figure 1 C2 Architecture

The C2 style is the most commonly used software architecture style. From the C2 style Organization rules and structure, we can conclude that the C2 style has the following features:
(1) components in the system can meet application requirements and encapsulate functions of any complexity together;
(2) Communication between all components is achieved through the asynchronous message switch using the connector as the intermediary;
(3) components are relatively independent and less dependent on each other. Some components in the system will be executed in the same address space, or some components share related assumptions such as specific control threads.

Ii. MPS queue/filter Style
In the software architecture of the pipeline/filter style, each component has a set of inputs and outputs. The component reads the input data stream and processes it internally, and then generates the output data stream. This process is usually completed through the transformation and incremental calculation of the input stream. Therefore, the output is generated before the input is completely consumed. Therefore, the component here is called a filter. The connector of this style is like a pipe for data stream transmission, which transmits the output of one filter to the input of another filter. A filter that is particularly important in this style must be an independent entity. It cannot share data with other filters, and a filter does not know its upstream and downstream identifiers. The correctness of the output of an MPS queue/filter network does not depend on the sequence in which the filters perform incremental computing.
Figure 2 shows the MPs queue/filter style. An example of a typical pipeline/filter architecture is a program written in Unix shell. UNIX provides a symbol to connect components (UNIX processes) and a process runtime mechanism to implement pipelines. Another famous example is the traditional compiler. Traditional compilers have always been regarded as a pipeline system in which the output of one stage (including lexical analysis, syntax analysis, semantic analysis, and code generation) is another stage.

Figure 2 architecture of MPs queue/filter Style

Pipeline/filter style software architecture has many good features:
(1) The software components are characterized by good concealment, high cohesion, and low coupling;
(2) allows the designer to regard the input/output behavior of the entire system as a simple synthesis of the behavior of multiple filters;
(3) Support software reuse. Important: provides data suitable for transmission between two filters, and any two filters can be connected;
(4) Easy system maintenance and enhanced system performance. New filters can be added to existing systems; old ones can be replaced by improved filters;
(5) allow analysis of attributes such as throughput and deadlock;
(6) parallel execution is supported. Each filter is completed as a separate task, so it can be executed in parallel with other tasks.
However, such a system also has some disadvantages.
(1) The process usually becomes the batch processing structure. This is because although filters can process data incrementally, they are independent, so the designer must regard each filter as a complete conversion from input to output.
(2) It is not suitable for interactive applications. This problem is especially serious when you need to incrementally display changes.
(3) because there are no general standards for data transmission, each filter adds data parsing and synthesis, which leads to a reduction in system performance, and added the complexity of writing filters.

Iii. Data abstraction and object-oriented Style
ABSTRACT Data Types play an important role in software systems. At present, the software field has generally switched to object-oriented systems. This style is based on data abstraction and object-oriented, and the Data Representation Methods and their corresponding operations are encapsulated in an abstract data type or object. The component of this style is an object, or an instance of the abstract data type. An object is a component called a manager because it maintains the integrity of resources. Objects are interacted by calling functions and procedures.

Figure 3 data abstraction and object-oriented Architecture

Object-Oriented systems have many advantages that have long been known:
(1) because an object hides its representation from other objects, it can change the representation of an object without affecting other objects.
(2) designers can break down some data access problems into a set of interactive proxies.
However, the object-oriented system also has some problems:
(1) In order for an object to interact with another object through a process call, the Object ID must be known. Once the identifier of an object changes, you must modify all other objects that explicitly call it.
(2) You must modify all other objects that explicitly call it and eliminate any side effects. For example, if a uses Object B and Object C also uses Object B, the effect of C on object B may be unexpected.

Iv. Event-based implicit call style
The idea of event-based implicit calling style is that a component triggers or broadcasts one or more events instead of directly calling a process. The process of other components in the system is registered in one or more events. When an event is triggered, the system automatically calls all the processes registered in this event. In this way, the trigger of an event leads to the call of the process in another module.
In terms of architecture, the components of this style are some modules. These modules can be both processes and collections of some events. The process can be called in a common way, or you can register some processes in system events. When these events occur, the process is called.
The main feature of the event-based implicit call style is that the event trigger does not know which components will be affected by these events. In this way, the processing sequence of the component cannot be assumed, or even the processes that will be called are unknown. Therefore, many implicit calling systems also include explicit calling as a complementary form of component interaction.
Many application systems support event-based implicit calls. For example, it is used in a programming environment to integrate various tools, ensure data consistency constraints in the database management system, manage data in the user interface system, and support syntax check in the editor. For example, in a system, the editor and variable monitor can register the breakpoint events of the corresponding debugger. When the debugger stops at the breakpoint, it declares the event and the system automatically calls the handler. For example, the editing program can roll the screen to the breakpoint, and the variable monitor refreshes the variable value. The debugger itself declares only events, and does not care about the processes that will be started or what to do.
The main advantages of the implicit call system are:
(1) It provides powerful support for software reuse. To add a component to an existing system, you only need to register it to the system event.
(2) convenience for improving the system. When one component is used to replace another component, the interfaces of other components are not affected.
The main disadvantages of the implicit call system are:
(1) components give up control over system computing. When a component triggers an event, you cannot determine whether other components will respond to it. Even if it knows which components the event registers, it cannot guarantee the order in which these processes are called.
(2) data exchange issues. Sometimes data can be transmitted by one event, but in other cases, the event-based system must rely on a shared repository for interaction. Under these circumstances, global performance and resource management become a problem.
(3) Since the process semantics must depend on the context constraints of the triggered event, there is a problem with reasoning about correctness.

V. hierarchical system Style
The hierarchy system is organized into a hierarchy where each layer serves the upper layer and serves as the lower layer customer. In some hierarchical systems, apart from some well-selected output functions, the internal layer is only visible to adjacent layers. In such a system, components implement virtual machines at some layers (in other layers, the system middle layer is partially opaque ). The connector is defined by a protocol that determines how the layers interact. Topology constraints include constraints on the interactions between adjacent layers.
This style supports the design based on the added abstraction layer. In this way, the implementation of a complex problem can be decomposed into an incremental step sequence. Since each layer only affects two layers at most, as long as the same interface is provided to the adjacent layers, each layer can be implemented in different ways, it also provides powerful support for software reuse.
Figure 4 shows the hierarchical system style. Hierarchical communication protocols are the most widely used hierarchical systems. In this application field, each layer provides an abstract function as the basis for upper-layer communication. The lower layer defines the interaction at the lower layer. The lower layer usually only

Figure 4 hierarchical system architecture

Hierarchical systems have many optional attributes:
(1) Support for an increasing degree of abstraction-based system design, allowing designers to break down a complex system in ascending steps;
(2) function enhancement is supported. Because each layer interacts with the adjacent upper and lower layers at most, function changes affect the adjacent upper and lower layers at most;
(3) Support reuse. As long as the definition of the provided service interface remains unchanged, different implementations of the same layer can be used for exchange. In this way, you can define a set of standard interfaces and allow different implementation methods.
However, hierarchical systems also have their shortcomings:
(1) Not every system can be easily divided into a hierarchical model. Even if the logical structure of a system is hierarchical, for the sake of system performance, system designers have to combine some low-level or advanced functions;
(2) It is difficult to find a proper and correct hierarchical abstraction method.

6. Warehouse Style
In the repository style, there are two different components: the central data structure shows the current status, and the independent components are executed on the central data storage, the interaction between the warehouse and external components changes greatly in the system.
The selection of control principles generates two main child classes. If a process execution is triggered at a certain time in the input stream, the repository is a traditional database. On the other hand, if the current state of the Central Data Structure triggers the process execution selection, the repository is a blackboard system.
Figure 4 consists of a blackboard system. The traditional applications of blackboard systems are in the signal processing field, such as speech and pattern recognition. Another application is loose coupling.

Figure 4 Composition of the blackboard System

As shown in figure 4, the blackboard system consists of three parts:
(1) knowledge source. The knowledge source contains independent and application-related knowledge. The knowledge source does not directly communicate with each other, and the interaction between them is completed only through the blackboard.
(2) Data Structure of the blackboard. Blackboard data is the data that solves the problem at the application-related level. knowledge sources constantly change the blackboard data to solve the problem.
(3) control. The control is completely driven by the state of the blackboard, and the change of the state of the blackboard determines the specific knowledge used.

VII. Conclusion
The software architecture style provides the possibility of large-granularity software reuse. However, for the application architecture style, system designers have a lot of room to choose from because of their different points of view. To select or design an architecture style for the system, you must analyze and compare it based on the specific characteristics of a specific project before confirming that the use of the architecture style is almost entirely special.
In this article, we only talk about the "pure" architecture. However, from the above introduction, we know that different structures have different strengths and weaknesses in processing capabilities. The architecture of a system should be selected based on actual needs to solve actual problems. In fact, there are also some systems that are made up of these pure architecture, that is, the heterogeneous software architecture. We will introduce the heterogeneous Software Architecture in subsequent articles.