Types of software architecture patterns

types of software architecture patterns

In the design of software architecture, according to different levels of abstraction can be divided into three different levels of the pattern: architectural pattern (architectural pattern), design pattern, code pattern (Coding pattern).

· The architecture pattern is a high-level strategy of a system, involving large-scale components as well as the overall nature and mechanics. The architectural pattern can affect the overall layout and framework structure.

· Design patterns are medium-scale structural strategies. These medium-scale structures implement the behavior of some large-scale components and their relationships. The quality of the model does not affect the overall layout and overall framework of the system. A design pattern defines the microscopic structure of a subsystem or component.

· Code patterns (or precedent) are specific examples and language-specific programming techniques. The quality of the code pattern affects the underlying details of the internal and external structure or behavior of a medium-scale component, but does not affect the medium-sized structure of a part or subsystem, and does not affect the overall layout of the system and the large-scale framework. 1.1 Schema Mode (architectural pattern)

An architectural pattern describes the basic structural organization or outline of a software system. The schema pattern provides some pre-defined subsystems, assigns their responsibilities, and gives the rules and guidelines for organizing them together. called System mode.

· MVC (model-view-controller) mode an architectural pattern can often be decomposed into a combination of many design patterns. The MVC pattern often includes the mediator (mediator) pattern, the Strategy (strategy) pattern, the composition (Composite) pattern, the Observer (Observer) pattern, and so on.

· Layers (layered) mode is sometimes called Tiers mode

· Blackboard (blackboard) mode

· Broker (Mediation) mode

· Distributed Process (dispersion) mode

· Microkernel (micro Core) mode

Architectural patterns are often divided into the following categories:

One, the module structure (from Mud to Structure) type. Help architects divide the system to avoid forming an object's oceans. Includes Layers (layered) mode, Blackboard (blackboard) mode, pipes/filters (pipe/filter) mode, and so on.

Second, the dispersion system (distributed systems) type. Provides a complete architectural design for decentralized systems, including broker-like (mediation) mode.

Third, human-machine interaction (Interactive systems), support the architecture design of the system including the interactive interface of the man-machine, examples include MVC (model-view-controller) mode, PAC (Presentation-abstraction-control) mode and so on.

Four, adaptable systems, support the application system to adapt to the change of technology, software functional requirements change. such as Reflection (reflection) mode, microkernel (micro-core) mode. 1.2 Design Pattern

A design pattern provides an outline design that refines the components of a subsystem or software system, or the relationship between them. The design pattern describes a ubiquitous structure that repeats itself in a communication component that solves a general design problem in a given background. Design patterns are often divided into different types, common types are:

Create design patterns such as (Factory method) mode, abstract Factory, prototype (Prototype) mode, singleton (Singleton) mode, build (builder) mode, etc.

Structural design patterns, such as synthesis (Composite) mode, (Decorator) decoration mode, proxy mode, enjoy meta (Flyweight) mode, façade (facade) mode, bridge mode, etc.

Behavioral patterns, such as template method mode, observer (Observer) mode, Iteration sub (Iterator) mode, responsibility Chain (Chain of Responsibility) mode, Memo (Memento) mode, command (C Ommand) mode, status (state) mode, visitor (Visitor) mode, and so on.

These are three classic types, in fact there are many other types, such as fundamental type, Partition type, Relation type and so on. When design patterns are implemented in a particular programming language, code patterns are often used. For example, the implementation of the Singleton (Singleton) mode often involves a double-check lock (double-check Locking) mode. 1.3 Code mode (Coding pattern)

Code patterns (or precedent) are lower-level patterns and are closely related to programming languages. Code patterns describe how to use the characteristics of a particular programming language to implement specific aspects or relationships of a component. Examples of the more famous code patterns include double check lock (double-check Locking) mode, etc.

Reference from: http://www.cnblogs.com/duanxz/archive/2012/06/05/2536801.html

2 Architectural Patterns

The architecture pattern is the structure organization outline of the software system. Provides a series of predefined subsystems that specify their responsibilities, including rules and organizational relationships between them. This main description describes 8 architectural patterns: Layers (layered), Pipes and Fllters (pipeline/filter), Blackboard (blackboard), Broker (mediation), Model-view-controller (MVC),

Presentation-abstractlon-control (PAC), microkernel (micro-core), and Reflection (reflection).

Before designing a new system, we collected data from users and converted them into specific indicators, which are often more complex than imagined.

In our view, we assume that the requirements for our new system are well defined and stable. The next task is to define the system architecture, which means to find an advanced sub-version for each component of the system. We have to take into account all aspects and organize the messy problem into a working structure.

Type of software	Schema mode	Features and Uses
System software	Layering (layer)	Observing systems from different levels, objects that deal with different levels of problems are encapsulated in different layers
Pipes and Filters (Pipes and Filters)	Observing the system with the data flow viewpoint, the whole system consists of some pipelines and filters, the data that needs to be processed is piped to each filter, and each filter is a processing step. When the data passes through all the filters, all the processing is done and the final result is obtained. The pipeline model of the UNIX operating system is built on this architecture; when developed under UNIX, each process is a filter, and we can connect the process through the pipeline, allowing all the filters to complete the task in collaboration. The compiler for most programming languages is also based on this architectural pattern.
Blackboard (Blackboard)	In this architecture, there are two different components, one is the central data structure that represents the current state, and the other is a set of independent artifacts that manipulate the central data. This architecture is primarily used for the development of databases and artificial intelligence systems.
Distributed software	Brokers (Broker)	In this architecture, the customer and the server communicate through a broker part, and the broker coordinates the operations between the client and the server. and send request and result information for customers and servers. Broker is a typical application of broker mode.
Client/server (Client/server)	The system is divided into customers and servers, the server has been in the state of listening, the customer master active connection server, each server can serve multiple customers.
Point-to-point (peer to peer)	The nodes in the system are all equal, and each node can connect to other nodes. In this architecture, it is generally necessary for a central server to complete the operations of discovering and managing nodes. Most of the applications of our familiar ICQ programs and Web service technologies are typical point-to-point structures.
Interactive Software	Model-View-controller (Model-view-controller)	When the user interface of the application is very complex, and the requirements of the user interface are easily changed, we can abstract the interaction type software into three kinds of component units, the model, the view and the controller, which can well separate the user interface and business logic and adapt to the changing demand. Most modern interactive software conforms to the characteristics of this architecture model in a certain program.
Display-Abstract-controller (Presentation-abstraction-control)	This is another variant of the show-abstract-controller pattern, which is not described in detail here.

Reference from: http://www.cnblogs.com/shinings/archive/2009/07/31/1536180.html

Layers Schema Mode
The layer schema pattern is primarily suitable for applications where schemas can be decomposed into sub-task groups, and each task group is a specific layer of task abstraction. Observing the system from different levels, the objects dealing with different levels of problems are encapsulated in different layers, and the network protocol is the most widely used application of layer pattern.

The main feature of layer mode is that layer J can only be used by layer j+1, and there is not much direct connection between layers. This structure can be compared with a stack, or even an onion. Each individual layer protects its lower layers from direct contact with a higher level layer.

Querying additional details for individual hierarchies may show that they are complex portals (containing different components). In the following illustration, each layer contains three components. In the middle tier, two components interact. Components at different layers can be called directly to each other---other designs protect each layer through a single, unified interface. In this design, component_2.1 does not call component_1.1 directly, but by invoking Layer1 's interface object.

The following scenario is a dynamic behavioral prototype for hierarchical applications. This does not mean that you will encounter all the scenarios in each architecture. In a simple hierarchy, you can only see the first scenario, but most of the applications involve scenario 1 and scene 2.

Scenario 1:

Scenario 1 is well known. The client makes a request to layer n, because layer n cannot handle its own request, he will call layer N-1, layer N-1 call layer N-2, ... Until layer 1 is reached, perform the lowest-level service. If necessary, the recovery of the different requests will be transmitted from Layer1 to Layer2,layer2 to Layer3,... Until Layern. One feature of this top-down communication is that layer J always passes some requests for layer j+1 to layer J-1.

Scenario 2:

Scenario 2 is a bottom-up communication, a series of actions starting from Layer1. For example, whenever the device detects an input, the device translates the input into the internal message format to Layer 2, which is then interpreted at the layer level until the data reaches the highest level. For top-down message control flows, which are often described as "requests", the bottom-up message control flow can be called "Notifications" (notification, disclosure).

As Scenario 1 says, Top-down "requests" often drive requests to the bottom. Conversely, bottom-up notifications may be a "notification" to a higher level, or still a 1:1 relationship.

Scenario 3:

Scenario three describes a scenario in which a request is passed only in a subset of the layer. A high-level request may only be passed to the next low-level N-1 if the layer satisfies the request. An example is the N-1 layer as a canche, the request from the N layer is not passed to the 1 layer or to the remote server can be satisfied. Note that this cache layer retains state information, but the layer that can only forward requests is usually very small. The advantage of a low-state layer is that the program is simple, especially with the re-entry of the relevant layer.

Scenario 4:

Similar to Scenario 3,

Scenario 5:

Once the user requirements for the software are collected, the architecture design begins. The main purpose of architecture design is to divide the system into many "plates". There are usually two ways of dividing, one is the horizontal division, the other is vertical division.

The horizontal division divides the system into commercial purposes. For example, a bookstore management system can be divided into purchase, sales, inventory management, staff management and so on.

Vertical division is different, it according to the level of abstraction, the system is divided into "layers", or layer. For example, a company's intranet management system can often be divided into the following layer:

First, the Web page, that is, the user interface, responsible for displaying data, accept user input;

Second, the domain layer, including the JavaBean or COM object, business services, etc., encapsulates the necessary commercial logic, responsible for determining what data to display according to the business logic, and how to calculate according to the data entered by the user;

Third, the database, is responsible for storing data, according to query requirements to provide the stored data.

Iv. operating system layers, such as Windows NT or Solaris

Five, hardware layer, such as Sun E450 server, etc.

Some people call this layer tier, but the tier has physical meaning, different tiers tend to be located on different computers, connected by the network, and layer is the concept of pure logic, regardless of the physical partition.

The benefits of the layers architecture pattern are:

First, any layer of change can be well confined to this layer, without affecting the other layers.

Second, it is easier to accommodate new technologies and changes. Layers Architecture mode allows any layer of change to be used by the technology