Software architecture style arrangement (7 DSSA, ha, agent, orthogonal, etc ).

1.1 Agent-Oriented Software Architecture

The basic idea of Agent-Oriented is to start from the human, things, and the environment in the real world, and think that the attributes of things, especially the dynamic characteristics, are largely influenced by the people and environment closely related to them, emphasize the interaction between understanding, thinking, and objective things and their environments, combine subjective and objective characteristics of things, and abstract them into agents in the system as the basic unit of the system, the overall goal of the system is achieved through cooperation between agents.

Definition and main features of Software Agent

What is software agent? Because the researchers of software agent come from many different fields, the meaning of software agent also has multiple features. In summary, an agent can be defined as a software entity that can actively take decisions and actions based on its perception of its environment"

The key attributes of the agent are autonomous, interactive, adaptive, intelligent, collaborative, and mobile. Autonomous means that no external direct interference can be performed based on your own experience; interaction means to communicate with the environment and other agents; adaptability means to be able to respond to other agents or environments to some extent; intelligence refers to the interaction between the status of knowledge and other agents using the symbolic language; coordination means that the agent can work together in a multi-agent system environment to execute and complete complex tasks that mutually benefit from each other. mobility means that the agent can transfer itself from one environment to another. In fact, it is difficult to see that an agent has the above features. Generally, the first three items are necessary.

Agent-Oriented Software Architecture

Some scholars have explicitly proposed to study the multi-agent system as a new software architecture style. In terms of the component elements of such systems-agent, it is a component type different from any previous system. Although in system implementation, the agent is more or less associated with traditional architecture elements such as objects and control processes, in terms of the agent itself, its autonomy, intelligence, interaction, and social nature are not available to objects. In addition, the connector in the multi-agent system also has its unique attributes. In general, in a traditional architecture, a connector explicitly associates two different components. For example, an object directly calls the method of another object. However, in multiple agent systems, the connections between different agents are almost invisible in the static model. Before the system runs, agent A does not know that the services it needs are provided by Agent B. Although agent B has this service capability, it also needs to decide whether to provide this service based on its current status [11].

Agent components are software entities that are highly abstract to system processing and highly flexible and intelligent. They are not sensitive to system requirements, its ability can be dynamically changed by modifying its obligations and selecting a set of knowledge, while its own form remains unchanged. The agent connector is a connection to a composite component. It can provide communication, coordination, conversion, and connection services, and can transmit the required data between components through parameters, the control flow is transmitted through service requests, process calls, and other methods. The transmitted data types and formats can be converted or packaged to enhance data interoperability and eliminate system structure mismatch, by providing a unified interface to enhance the stability of the component's living environment, you can control the adjustment of the connection relationship through interaction.

1.2 Process Control (loop)

1) Background

When a software is used to operate a physical system, the software and hardware can be roughly expressed as a feedback loop. This feedback loop determines a series of outputs by receiving certain input, eventually, the Environment enters a new state.

Suitable for embedded systems, involving continuous actions and states.

Control System Model Structure

Computing Model

Process Definition: includes the mechanism for operating certain process variables.

Control Algorithm: used to determine how to manipulate Process Variables

Data Element

Process Variables: specified input and manipulate Variables

Setting point: Reference Value of Controlled Variables

SENSOR: used to obtain the process variable value required for control

Control Ring Model

Establishes the relationship between control algorithms and collects information about the process.

Actual and desired status, and adjust process variables,

To make the actual status develop towards the target status

1.3 heterogeneous architecture (heterogeneous)

◇ Why use heterogeneous Structures

N 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.

N there are many standards for software packages, frameworks, communications, and other architecture issues. Even if a standard is dominant for a certain period of time, the change will eventually be absolute.

N in actual work, we will always encounter some legacy code, which is still effective, but is not in coordination with the new system to some extent. However, in many cases, when considering both technology and economy, it is always decided not to rewrite them.

N even if a Unit defines criteria for sharing a common software package or relationship, there are still differences in interpretation or representation habits.

1.4 Software Architecture in specific fields

◇ Definition
◎ Hayes-Roth: "DSSA is dedicated to a specific type of task (field) the set of software components that can be effectively used in the entire field and that have defined a standard combination structure for successful construction of application systems ".

◎ Tracz is defined as: "DSSA is the development basis composed of Domain Models, reference requirements, and reference architecture that support a group of applications in a specific problem domain, the goal is to support the generation of multiple applications in a specific field ".

Analysis of Software Architecture in a specific application field makes it easier to extract reusable components with a high degree of reusability and form a reusable system architecture, it can increase the granularity of System Component Reuse and improve the success rate of System Component reuse.

◇ DSSA features
1) a strictly defined problem domain and/or solution domain;

2) It is universal and can be used for the development of a specific application in the field;

3) abstraction of the appropriate degree in the entire field;

4) have fixed and typical elements that can be reused in the development process in this field.

◎ Vertical domain: defines a specific system family, including multiple systems in the entire system family, the result is a general software architecture that can serve as a feasible system solution in this field.

◎ Horizontal domain: defines a common part of the functional areas in multiple systems and multiple system families, and covers specific functions of multiple system families at the subsystem level, it is impossible to provide a complete general architecture for the system.

◇ Basic activities
◎ Domain analysis ◎ Domain Design ◎ domain implementation

◇ Domain Analysis
Domain Knowledge Resources Technical Documentation Classification Methods completed software project standards user reviews function models expert suggestions domain analysis domain languages current and future needs domain implementation personnel domain designers domain analysts domain experts

◇ Creation process
◎ Define domain scope: Determine what is in the field of interest and when the process ends.

◎ Define domain-specific elements: compile a dictionary of domain dictionaries and synonyms of domain terms. Identifies commonalities and differences between applications in the field;

◎ Define specific design and implementation requirements constraints in the field: Describe the characteristics with different space. Not only do we need to identify constraints, but we also need to record the consequences of constraints on design and implementation decisions, as well as the discussion of all issues arising when dealing with these issues;

Define Domain Models and architectures: generate general architectures and describe the syntax and semantics of the modules or components that constitute them;

◎ Generate and collect reusable product units: Add components for DSSA so that it can be used to generate new applications in the problem domain.

◇ DSSA and architecture style comparison
◎ DSSA is based on the problem domain, and the architecture style is based on the solution domain.

◎ DSSA only extracts, stores, and organizes the knowledge of design experts in a certain field, but can use multiple Architecture styles at the same time; when organizing expert knowledge of Architecture Design in an architectural style, the extracted public structures and design methods can be extended to multiple application fields.

◎ DSSA generally selects one or more architectures suitable for the research field and designs a specialized Architecture Analysis and Design Tool for this field.

◎ The definition of the architectural style and the field of application of this style are directly transferred. The extracted design knowledge is wider than the design expert knowledge extracted by DSSA.

◎ DSSA and architectural style are complementary technologies.

1.5 orthogonal Software Architecture

The orthogonal software architecture consists of components of the Organization layer and clues. A layer is composed of a group of components with the same abstraction level. A clue is a special case of a subsystem. It is composed of components that complete different levels of functions (through mutual calls). Each clue completes a relatively independent part of the system. The implementation of each clue has little or no relationship with the implementation of other clues. Components in the same layer do not call each other.

If the clues are independent of each other, that is, the components in different clues do not call each other, then the structure is completely orthogonal. From the above definition, we can see that the orthogonal software architecture is a hierarchical structure based on the vertical clue component family, the basic idea is to vertically divide the structure of an application system into several clues (subsystems) based on the orthogonal correlation of functions. The clues are divided into several levels, each clue consists of multiple components with different levels of functions and different abstract levels. Components at the same level of each clue have the same abstraction level. Therefore, we can summarize the main features of orthogonal software architecture as follows:

(1) orthogonal software architecture consists of n (n> 1) clues (subsystems) that complete different functions;

(2) The system has m (M> 1) layers of different abstraction levels;

(3) clues are mutually independent (orthogonal );

(4) The system has a public driver layer (generally the highest level) and a public data structure (generally the lowest layer ).

For large and complex software systems, subclues (level-1 subclues) can also be divided into lower-level subclues (level-2 subclues) to form a multi-level orthogonal structure. Frame 1 of the orthogonal software architecture is shown in.

　　

Figure 1 is a three-level clue, five-layer structure of orthogonal software architecture framework, in which abdfk forms a clue, acejk is also a clue. Because B and C are at the same level, mutual calls are not allowed. H and J are at the same level, and mutual calls are not allowed. Generally, the fifth layer is a physical database connection component or device component for the whole system to public.

In the process of Software Evolution, system requirements will constantly change. In the orthogonal software architecture, each demand change affects only one clue due to the orthogonal nature of the clue, but does not involve other clues. In this way, the changes in software requirements are localized, and the impact is limited within a certain range, so it is easy to implement.

Orthogonal software architecture has the following advantages:

(1) The structure is clear and easy to understand. The form of orthogonal software architecture is helpful for understanding. Because the clue functions are independent from each other and do not call each other, the structure is simple and clear. The position of the component in the structure diagram shows which level of abstraction it implements and what functions it carries.

(2) Ease of modification and strong maintainability. Because clues are independent from each other, modifications to one clue will not affect other clues. Therefore, when the software requirements change, the new requirements can be divided into independent sub-requirements, and each sub-requirement can be processed with clues and components as the main objects, in this way, software modifications are easy to implement. With the increase or decrease of system functions, you only need to add or delete the clue component family without affecting the entire orthogonal architecture. Therefore, you can easily adjust the structure.

(3) High portability and large granularity of reuse. Because orthogonal structures can be shared by all applications in a field, these software has the same or similar layers and clues, and can be reused at the architecture level.