A core problem of software architecture design is whether repeated architecture mode is used, that is, the software reuse can be reached. That is, it is possible to use the same system structure in different software systems. Based on this purpose, scholars began research and practical software architectural style and type problems. The software architecture style is a usual model that describes the system organization mode in a particular application. It reflects the structure and semantic characteristics of many systems in the field, and guides how each module and subsystem are effectively organized into a complete system. In this way, the software architecture style defines the rules for describing the typographic tables and a set of guiding member systems. Research and practice of software architecture style promotes the reuse of the design, some practical solutions can also be reliably used to solve new problems. The constant portion of the architecture style makes different systems to share the same implementation code. As long as the system is organized to organize commonly used, specifications, other designers can easily understand the system architecture. For example, if someone describes the system as "Customer / Server" mode, we do not have to give design details, we will immediately understand how the system organizes and works. Below is the classification of GARLAN and SHAW to universal architectural style: (1) Data flow style: batch sequence; pipe / filter (2) call / return style: main program / subroutine; object-oriented style (3) Independent component style: process communication; event system (4) Virtual machine style: interpreter; rule-based system (5) warehouse style: database system; hypertext system; blackboard system in two articles, we introduce the software The concept, current situation and development direction of the architecture, readers may feel that "software architecture is too abstract, too theoretical, there is no practical thing". However, any practices must accept the theoretical guidance, if abandon the theoretical foundation, pursue practical use, which can only be swallowed. A core problem of software architecture design is whether repeated architecture mode is used, that is, the software reuse can be reached. That is, it is possible to use the same system structure in different software systems. Based on this purpose, scholars began research and practical software architectural style and type problems. The software architecture style is a usual model that describes the system organization mode in a particular application. It reflects the structure and semantic characteristics of many systems in the field, and guides how each module and subsystem are effectively organized into a complete system. In this way, the software architecture style defines the rules for describing the typographic tables and a set of guiding member systems. Research and practice of software architecture style promotes the reuse of the design, some practical solutions can also be reliably used to solve new problems. The constant portion of the architecture style makes different systems to share the same implementation code. As long as the system is organized to organize commonly used, specifications, other designers can easily understand the system architecture. For example, if someone describes the system as "Customer / Server" mode, we do not have to give design details, we will immediately understand how the system organizes and works.
Below is the classification of GARLAN and SHAW to universal architectural style: (1) Data flow style: batch sequence; pipe / filter (2) call / return style: main program / subroutine; object-oriented style (3) Independent component style: process communication; event system (4) Virtual machine style: interpreter; rule-based system (5) warehouse style: database system; hypertext system; blackboard system is limited to space, in this article, we will only introduce Several major and classic architectures and their advantages and disadvantages. The newly displayed software architecture style will be introduced in subsequent articles. First, the C2 style C2 architecture can be summarized as a parallel component network that is binding together by a set of rules. The system organization rules in the C2 style are as follows: (1) The components and connectors in the system have one top and one 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 a certain The top of the connector 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 one must be taken to the top. Figure 1 is a schematic diagram of a C2 style. The connection between the components and connectors embodied in the C2 style. Figure 1 C2 style architecture C2 style is the most common software architecture style. From the C2 style organizational rules and structural diagrams, we can concatenation that the C2 style has the following features: (1) The components in the system can implement application requirements, and can encapsulate any complexity function; (2) all The communication between the members is achieved by the asynchronous message exchange mechanism of the connector; (3) The member is relatively independent, and the dependence is less dependence. There is no certain component in the system that will execute within the same address space, or some components share the correlation assumptions such as specific control threads. Second, the pipeline / filter style is in the software architecture of the pipe / filter style, each component has a set of inputs and outputs, and the components read input data streams, after internal processing, and then output data streams. This process usually passes through the transformation and incremental calculation of the input stream, so the output is generated before the input is fully consumed. Therefore, the member herein is referred to as a filter, and the connection of this style is like a data stream transmitted, and the output of a filter is transmitted to the input of another filter. This style is particularly important filter must be a separate entity that cannot share data with other filters, and one filter does not know the upstream and downstream identity. The correctness of a pipeline / filter network output does not depend on the order of the filter for incremental calculation processes. Figure 2 is a schematic diagram of a pipe / filter style. An example of a typical pipeline / filter architecture is a program written in UNIX shell. UNIX provides both a symbol to connect each component (UNIX process), and provide some process runtime mechanism to realize the pipe. Another famous example is a traditional compiler. The traditional compiler has been considered a pipe system, in which the output of a phase (including the speech analysis, grammar analysis, semantic analysis, and code generation) is another phase of input.
Figure 2 The software architecture of the pipeline / filter style of the pipe / filter style has many good features: (1) makes the soft structure with good concealment and high internal polymerization, low coupling characteristics; (2) Allow designers to view the input / output behavior of the entire system as simple synthesis of behavior of multiple filters; (3) Support software reuse. Important provides data that is suitable for transmitting between two filters, and any two filters can be connected; (4) System maintenance and enhancement system performance is simple. The new filter can be added to the existing system; the old filter can be replaced by a filter; (5) Allows analysis of some attributes such as throughput, deadlock; (6) support parallel execution. Each filter is done as a separate task, so it can be executed in parallel with other tasks. However, such systems have several unfavorable factors. (1) Normally lead the process to become a batch. This is because although the filter can increase the data, they are independent, so the designer must see each filter as a complete conversion from the input to the output. (2) Not suitable for processing interaction. This problem is particularly serious when the incremental display changes. (3) Because there is no universal standard on the data transfer, each filter has increased the work of parsing and synthesizing data, which results in a decrease in system performance and increasing the complexity of the filter. Third, data abstraction and object-oriented style abstract data type concept has an important role in the software system, and the current software industry has generally turned to use the object-oriented system. This style is based on data abstraction and object-oriented basis, and the data representation and their respective operation are packaged in an abstract data type or object. This style of component is an object, or an example of an abstract data type. Objects are components called managers because it is responsible for maintaining resource integrity. Objects interacts through the calls of functions and processes. Figure 3 is a schematic diagram of data abstraction and object-oriented style. Figure 3 Data Abstraction and object-oriented system-oriented systems have many advantages, and have already known: (1) Because the object hides other objects, you can change an object, without affecting Other objects. (2) Designers can break down some data access operations into a collection of some interactions. However, some problems are there in the object-oriented system: (1) In order to interact with another object and another object, the identity of the object must be known. As long as an identity of an object changes, you must modify the objects that clearly call it. (2) You must modify all other objects of all explicit calls, and eliminate some of the side effects. For example, if A uses objects B, C also uses object B, then the effect caused by C on B using the B-to-B may not be expected. Fourth, an event-based implicit call style is based on an incident implicit call style. The component does not directly call a process, but triggers or broadcasts one or more events. The process in the 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, so that the trigger of an event has caused the process in another module. Call. From the architecture, this style of component is some modules that can be either some process, and can also be a collection of events. The process can be called in a general manner, or some processes can be registered in the system event, and when these events occur, the process is called. The main feature of an incident-based implicit call style is that the trigger of the event does not know which components will be affected by these events.
This cannot be assumed to assume the sequence of processing, and even which procedures will be called, so many implicitly called systems also include explicit calls as a supplementary form of component interaction. There are many applications that support event-based implicit calls. For example, in a programming environment for integrating a variety of tools, secure 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 a breakpoint event of the corresponding debugger. When Debugger stops at the breakpoint, it declares that the event is automatically called by the system. If the editor can be rolled into the breakpoint, the variable monitor refreshes the value value. Debugger itself only declares an incident, does not care about which process will start, and do not care about what these processes do. The main advantages of implicit calling systems are: (1) Providing powerful support for software reuse. When you need to add a component to an existing system, simply register it to the system's event. (2) It has brought convenience to the improvement system. When using one component instead of another member, the interface of other components is not affected. The main disadvantages of implicit calling systems are: (1) The component abandoned the control of the system. When a component triggers an event, you cannot determine if other components will respond. And even if it knows what components have been registered, it does not guarantee the order of these processes being called. (2) Data exchange issues. Sometimes data can be passed by an event, but in other cases, an event-based system must rely on a shared warehouse to interact. In these cases, global performance and resource management have become a problem. (3) Since the semantics of the process must rely on the context constraints of the triggered events, there is a problem about the correctness. 5. The hierarchical system style hierarchy system organizes a hierarchy, and each layer is a superior service and as a lower customer. In some hierarchical systems, in addition to some carefully selected output functions, the internal layers are only visible to adjacent layers. The components in such systems have realized a virtual machine in some layers (in the middle layer of the other hierarchy). The connector is defined by a protocol that interacts between the intercommunications, including constraints between interactions between adjacent layers. This style support is based on the design of the abstract layer. In this way, a complex problem is allowed to decompose into an implementation of an incremental step sequence. Since each layer only affects two layers, as long as it provides the same interface to the neighboring layer, it allows each layer to be implemented in different ways, and a powerful support is provided for software reuse. Figure 4 is a schematic diagram of a hierarchical system style. The most widely used application of hierarchies is a hierarchical communication protocol. In this application field, each layer provides an abstract function as the basis of the upper communication. Lower levels define low-level interactions, the lowest layer usually only defines hardware physical connections. Figure 4 Hierarchical System Style Architecture Hierarchical System There are many desirable properties: (1) Support for system design based on abstract degree, so that designers can decompose a complex system in increment; (2) Support function enhancement, Because each layer is at most and adjacent upper and lower layers, the function changes up to the adjacent upper and lower layers; (3) supports reuse. As long as the service interface provided is defined unchanged, different implementations of the same layer can be exchanged. In this way, a set of standard interfaces can be defined while allowing various implementation methods.
