Architectural Style Notes

Pipe and Filter Style
   In a pipe/filter style software architecture, each component has a set of inputs and outputs. The component reads the input data stream, processes it internally, and then produces the output data stream. This process is usually done by transforming and incrementally computing the input stream, so that the output is produced before the input is fully consumed. Therefore, the components here are called filters, and this style of connector is like a pipeline for data flow, passing the output of one filter to the input of another filter. Filters for which this style is particularly important must be a separate entity, it cannot share data with other filters, and a filter does not know its upstream and downstream identities. The correctness of the output of a pipe/filter network does not depend on the order in which the filters are incrementally computed.
  An example of a typical pipe/filter architecture is a program written in the Unix shell. Unix provides both a notation to connect the components (Unix processes) and some kind of process runtime mechanism to implement pipes. Another well-known example is the traditional compiler. Traditional compilers have always been thought of as a pipeline system in which the output of one stage (including lexical analysis, syntax analysis, semantic analysis, and code generation) is the input of another stage.
The pipeline/filter style software architecture has many good characteristics:

(1) It makes the software components have good concealment, high cohesion and low coupling characteristics;
(2) It allows the designer to connect the input/output of the whole system The behavior is regarded as a simple synthesis of the behavior of multiple filters;
(3) Software reuse is supported. It is important to provide data suitable for transmission between two filters, and any two filters can be connected;
(4) System maintenance and enhancement of system performance are simple. New filters can be added to existing systems; old ones can be replaced by improved filters;
(5) allow analysis of properties such as throughput and deadlock;
(6) support parallel execution. Each filter is done as a separate task, so it can be executed in parallel with other tasks.

However, there are several disadvantages to such a system.
(1) The structure that usually causes the process to become a batch. This is because although filters process data incrementally, they are independent, so the designer must treat each filter as a complete transformation from input to output.
(2) Applications that are not suitable for handling interactions. This problem is especially acute when changes need to be displayed incrementally.
(3) Because there is no common standard for data transmission, each filter increases the work of parsing and synthesizing data, which leads to a decrease in system performance and increases the complexity of writing filters.

Data
abstraction and object-oriented style    The concept of abstract data types plays an important role in software systems, and the software industry has generally turned to object-oriented systems. This style is based on data abstraction and object orientation, where the representation of data and their corresponding operations are encapsulated in an abstract data type or object. The components of this style are objects, or instances of abstract data types. An object is a component called a manager because it is responsible for maintaining the integrity of the resource. Objects interact
through .
   Object-oriented systems have many advantages and have long been known:
(1) Because an object hides its representation from other objects, it is possible to change the representation of one object without affecting other objects.
(2) The designer can decompose the problem of some data access operations into a set of interacting agents.
However, object-oriented systems also have some problems:
(1) In order for one object to interact with another object through procedure calls, etc., the identity of the object must be known. Whenever an object's identity changes, all other objects that explicitly call it must be modified.
(2) All other objects that explicitly call it must be modified, and some side effects caused by this must be eliminated. For example, if A uses object B and C uses object B, then the effect of C's use of B on A may be unexpected.

Event-based implicit calling style
The idea of ​​the event-based implicit invocation style is that the component does not invoke a procedure directly, but instead triggers or broadcasts one or more events. Procedures in other components in the system are registered in one or more events. When an event is triggered, the system automatically calls all procedures registered in this event. In this way, the triggering of an event leads to a procedure in another module. call.
   Architecturally, the components of this style are modules, which can be either procedures or collections of events. Procedures can be called in a generic way, or you can register some procedures in system events, and when these events occur, procedures are called.
   The main feature of the event-based implicit invocation style is that event triggers do not know which components will be affected by these events. This way it is not possible to assume the order in which the components are processed, or even know which procedures will be called, so many systems with implicit calls also include explicit calls as a complementary form of component interaction.
   There are many application systems that support event-based implicit calls. For example, it is used in programming environments to integrate various tools, in database management systems to ensure data consistency constraints, in user interface systems to manage data, and in editors to support syntax checking. For example, in a system, editors and variable monitors can register breakpoint events for the corresponding Debugger. When the Debugger stops at the breakpoint, it declares the event, and the system automatically calls the handler. For example, the editor can scroll to the breakpoint, and the variable monitor refreshes the variable value. The Debugger itself only declares events, and does not care which processes will be started or what these processes do.

The main advantages of the implicit calling system are:
(1) It provides strong support for software reuse. When a component needs to be added to an existing system, it is simply registered to the system's events.
(2) It brings convenience for improving the system. When one component is substituted for another, the interfaces of the other components are not affected.

The main disadvantages of the implicit call system are:
(1) The component relinquishes control of the system computation. When a widget fires an event, it cannot be determined whether other widgets will respond to it. And even if it knows which components the event is registered with, it cannot guarantee the order in which these procedures are called.
(2) The problem of data exchange. Sometimes data can be passed by an event, but in other cases event-based systems must rely on a shared repository for interaction. In these cases, global performance and resource management becomes an issue.
(3) Since the semantics of the procedure must depend on the contextual constraints of the triggered event, reasoning about correctness is problematic.

Hierarchy System Style
    Hierarchy is organized into a hierarchy, with each layer serving the upper layer and serving as the lower layer customers. In some hierarchical systems, except for some carefully selected output functions, inner layers are only visible to adjacent layers. Components in such systems implement virtual machines at some layers (layers are partially opaque at other layers). Connectors are defined by protocols that determine how layers interact, and topological constraints include constraints on interactions between adjacent layers.
   This style supports designs based on layers of abstraction that can be added. In this way, a complex problem is allowed to be decomposed into the realization of a sequence of incremental steps. Since each layer only affects two layers at most, and as long as the adjacent layers are provided with the same interface, each layer is allowed to be implemented in different ways, and it also provides strong support for software reuse.
   The most widespread application of a hierarchical system is a layered communication protocol. In this application domain, each layer provides an abstract function as the basis for upper layer communication. The lower layers define low-level interactions, and the lowest layers usually define only hardware physical connections.
   Hierarchical systems have many desirable properties:
(1) Support system design based on increasing levels of abstraction, enabling designers to decompose a complex system in incremental steps;
(2) Support functional enhancement, since each layer is at most adjacent to The upper and lower layers interact with each other, so the change of function affects the adjacent upper and lower layers at most;
(3) Support reuse. Different implementations of the same layer can be used interchangeably as long as the provided service interface definition remains unchanged. In this way, a standard set of interfaces can be defined, allowing a variety of different implementations.

However, the hierarchical system also has its shortcomings:
(1) Not every system can be easily divided into hierarchical modes, even if the logical structure of a system is hierarchical, for the consideration of system performance, System designers have to combine some low-level or high-level functions;
(2) It is difficult to find a suitable and correct level abstraction method.

Warehouse style
   In the warehouse style, there are two different components: the central data structure describes the current state, the independent components execute on the central data store, and the interaction between the warehouse and the external components can vary greatly in the system.
   The choice of control principles yields two main sub-categories. If some kind of time-triggered selection of process execution in the input stream, the warehouse is a traditional database; on the other hand, if the current state of the central data structure triggers the selection of process execution, the warehouse is a blackboard system.

The blackboard system mainly consists of three parts:
(1) Knowledge source. Knowledge sources contain independent, application-related knowledge, and there is no direct communication between knowledge sources, and the interaction between them is only done through the blackboard.
(2) Blackboard data structure. Blackboard data is problem-solving data organized in layers relevant to the application, and knowledge sources solve problems by constantly changing the blackboard data.
(3) Control. Control is entirely driven by the state of the blackboard, and changes in the state of the blackboard determine the specific knowledge used.
C2 style
The C2 architectural style can be summarized as: a network of parallel components that operate according to a set of rules, bound together by connectors. The system organization rules in the C2 style are as follows:
(1) The components and connectors in the system have a top and a bottom;
(2) The top of the member should be connected to the bottom of a connector, and the bottom of the member should be connected to the top of a connector, and direct connection between members is not allowed;
(3) A connector can be connected with Any number of other components and connectors are connected;
(4) When two connectors are directly connected, they must be from the bottom of one to the top of the other.
The C2 style is the most commonly used style of software architecture. From the organization rules and structure diagram of the C2 style, we can conclude that the C2 style has the following characteristics:
(1) The components in the system can realize the application requirements, and can encapsulate functions of any complexity together;
(2) All The communication between components is realized through the asynchronous message exchange mechanism mediated by connectors;
(3) The components are relatively independent, and the dependencies between the components are less. There is no dependency assumption in the system that some components will execute in the same address space, or that some components share a particular thread of control.

The Nuances Between Architectural Styles and Architectural Patterns An

architectural style is the primary, organizational design of a system.
Architectural patterns describe coarse-grained solutions at the level of subsystems or modules, and the relationships between them.
Systems metaphors are more conceptual, involving more real-world concepts than software engineering concepts.

David Calvert gave a partial list of architectural styles/patterns in 1996:

Data Flow Systems - Batch, Pipes - Filters.
Call-return system - main program and subroutine, object-oriented system, layered.
Independent components - communication process, event system.
Virtual Machine - Interpreter, rule-based system.
Data-centric systems (warehouses) - databases, hypertext systems, blackboards.