What Is a Computer Infrastructure?

Architecture, also known as software architecture , is an abstract description of the overall structure and components of software, and is used to guide the design of all aspects of large software systems. Architecture Description Language (ADL) is used to describe the architecture of the software. There are multiple architecture description languages, such as Wright (developed by Carnegie Mellon University), Acme (developed by Carnegie Mellon University), C2 (developed by UCI), Darwin (developed by Imperial College London). The basic components of ADL include components, connectors, and configurations. ^[1]

Chinese name: Architecture

Foreign name: Software architecture
nickname: Software Architecture

Architecture characteristics

A schema is a description of the categories and attributes of objects stored in Active Directory. For each object category, the schema defines the attributes that the object class must have, it can also have additional attributes, and the object can be its parent object.

Active Directory schema that can be dynamically updated. Applications can extend the architecture with new attributes and classes and can use the extension immediately. Update the schema by creating or modifying the schema objects stored in Active Directory in Active Directory. Like all objects in Active Directory, schema objects have access control lists, so only authorized users can change the schema.

Software architecture

Software architecture is a series of related abstract patterns used to guide the design of all aspects of large software systems. Software architecture is a sketch of a system. The objects described by the software architecture are the abstract components that directly constitute the system. The connections between components describe the communication between components explicitly and relatively finely. During the implementation phase, these abstract components are refined into actual components, such as a specific class or object. In the object-oriented field, the connections between components are usually implemented using interfaces (computer science). Software architecture is the basis for building computer software practices. Just as the architect sets the design principles and goals of the building project as the basis for drawing by the draftsman, a software architect or system architect states the software architecture as the basis for practical system design solutions that meet different customer needs.

Software architecture is an easy-to-understand concept. Most engineers (especially those with little experience) will know it intuitively, but it is difficult to give a precise definition. In particular, it is difficult to clearly distinguish between design and architecture: architecture is one aspect of design and it focuses on certain specific characteristics.

In "Introduction to Software Architecture", David Garlan and Mary Shaw consider software architecture to be a design level for issues such as: "Beyond computing algorithms and data structures, designing and determining the overall structure of the system has become a new problem. Structural issues include General organizational structure and global control structure; protocols for communication, synchronization, and data access; functional allocation of design elements; physical distribution; composition of design elements; calibration and performance; choice of alternative designs. "

But architecture is not just structure. The IEEE Working Group on Architecture defines it as "the highest level concept of a system in its environment." The architecture also includes "compliance" with system integrity, economic constraints, aesthetic needs, and style. It does not only focus on internal considerations, but also considers the system as a whole in the user environment and development environment of the system, that is, it also focuses on external considerations.

In the Rational Unified Process, the architecture of a software system (at a given point) refers to the organization or structure of the important components of the system. These important components interact through the interface with ever-decreasing components and components composed of interfaces.

In terms of connection with purpose, subject, material and structure, software architecture can be compared with the architecture of a building. A software architect needs extensive software theoretical knowledge and corresponding experience to implement and manage advanced design of software products. Software architects define and design software modularity, module interactions, user interface styles, external interface methods, innovative design features, and object operations, logic, and processes for high-level things.

Generally speaking, the architecture of a software system has two elements:

1. It is the highest level division of a software system from whole to part. A system is usually composed of components, and how these components are formed and interact with each other is important information about the structure of the system itself. In detail, it is necessary to include Architecture Component, Connector, and Task-flow. The so-called architectural elements are the core "bricks and tiles" that make up the system, and the connector describes the communication path between these components, the communication mechanism, and the expected result of the communication. The task flow describes how the system uses these components and the connector to complete A need.

2. The highest-level, commercial and technical decisions made to build a system that are difficult to change later. There are many important decisions that need to be made before building a system, and once the system begins detailed design or even construction, these decisions are difficult to change or even impossible to change. Obviously, such a decision must be the most important decision about the success or failure of the system design, and it must be studied and examined very carefully.

Architecture history

As early as the 1960s, concepts such as E.W.Dixtra have been involved in software architecture. Since the 1990s, the concept of software architecture has become increasingly popular due in part to related activities within Rational Software Corporation and Microsoft.

Carnegie Mellon University and the University of California, Irvine have done a lot of research in this area. Mary Shaw and David Garlan of Carnegie Mellon University wrote a book called Software Architecture perspective on an emerging discipline in 1996, which proposed many concepts in software architecture, such as software components, connectors, styles, etc. . The work done by the Software Research Institute at the University of California, Irvine focuses on architectural styles, architectural description languages, and dynamic architectures.

The history of computer software began in the 1950s, and the history is very short. In contrast, construction engineering began from the Stone Age. Human beings have accumulated a lot of experience and lessons in the practice of architectural design for thousands of years. Architectural design basically includes two points, one is the architectural style, and the other is the architectural model. The unique architectural style and properly selected architectural model can make it a unique building.

The photo below shows ancient Central American Mayan architecture, the Chichen-Itza Great Pyramid, nine huge stone-level stacks, ninety-one steps (symbolizing the number of days in four seasons) leading the way, and the temple at the top of the tower towering in Sky. All the figures are as rigorous as the calendar and the style is magnificent. It is hard to imagine this is a stone age building.

Figure 1. Ancient Mayan architecture Figure 1 An ancient Mayan building in Chichen-Itza, Mexico (chi means mouth and chen means well in Mayan). (Photographer: author) The relationship between software and human beings is a core problem that architects must face, and it has also been a problem that has arisen since software entered the stage of history. Similarly, the relationship between architecture and human beings has been a core issue that architects must face since the beginning of architecture. British Prime Minister Churchill said, We shape our buildings, and afterwards our buildings shape us. The House of Commons in the British House of Commons is narrow, and it is impossible for all members of the House of Commons to sit in the same direction. Churchill believes that when parliamentarians are seated, they will naturally choose people who have the same political views as themselves, and this is the origin of the British party system. The original meaning of the word Party is "party", "face". The key to the origin of political parties is the influence of buildings on people.

In the software design world, many people once thought that function is the most important, and form must obey function. Similarly, in the field of architecture, Louis Sullivan, one of the founders of the modernist school of architecture, also believed that forms should follow functions.

Almost all software design concepts can be found in the far-reaching history of architecture. The most famous are of course model theory and XP theory.

Architecture design goals

Just as the software itself has its goals, the software architecture design must achieve the following goals:

1. Reliable. Software systems are extremely important for users' business operations and management, so software systems must be very reliable.

2. Security. The commercial value of transactions undertaken by software systems is extremely high, and system security is very important.

3. Scalability. The software must be able to maintain reasonable performance in situations where user usage and the number of users increase rapidly. Only in this way can we adapt to the possibility of the user's market expansion.

4. Customizable. The same set of software can be adjusted according to different customer groups and changes in market demand.

5. Scalable (Extensible). When new technologies appear, a software system should allow the introduction of new technologies to expand the functionality and performance of existing systems.

6. Maintainability (Maintainable). Software system maintenance includes two aspects, one is to eliminate the existing errors, and the other is to reflect the new software requirements into the existing system. An easy-to-maintain system can effectively reduce technical support costs.

7. Customer Experience. The software system must be easy to use.

8. Time to Market. Software users face competition from the same industry, and software providers face competition from the same industry. It is important to compete for market opportunities as quickly as possible.

Architecture types

According to the perspective we focus on, the architecture can be divided into three types:

Figure 2. An example of a logical architecture

1. Logical architecture, the relationship between components in a software system, such as user interfaces, databases, external system interfaces, business logic components, and so on. The figure is an example of a logical architecture. As can be seen from the figure above, the system is divided into three logical levels, namely the presentation level, the business level, and the data persistence level. Each level contains multiple logic elements. For example, there are HTML service elements, Session service elements, security service elements, and system management elements in the WEB server level.

2. How the physical architecture and software components are placed on the hardware. For example, the following physical architecture diagram describes the physical architecture of a distributed system distributed in Beijing and Shanghai. All components in the diagram are physical devices, including network shunts, proxy servers, web servers, application servers,

Figure 3.An example of a physical architecture

Report server, consolidation server, storage server. Host and so on. Figure is an example of a physical architecture

3. System architecture, non-functional features of the system, such as scalability, reliability, robustness, flexibility, performance, etc. The design of the system architecture requires the architect to have a solid knowledge of the functions and performance of software and hardware. This work is undoubtedly the most difficult task in architecture design.

In addition, from each perspective, you can see two elements of the architecture: component division and design decisions. First of all, the elements in a software system are logic elements. How these logic elements are placed on the hardware, and how these elements contribute to the scalability, reliability, robustness, flexibility, performance, etc. of the entire system are very important information. Second, the decisions that need to be made in software design will necessarily include logical structures, physical structures, and how they affect all non-functional characteristics of the system. Many of these decisions are difficult to change once they are made. In order to discuss and analyze software architecture, you must first define the architecture representation, that is, the way to describe important aspects of the architecture. This description is documented in the Rational Unified Process.

We decided to represent the software architecture in multiple architectural views. Each architectural view is targeted at specific aspects of the development process, such as end users, designers, managers, system engineers, maintenance staff, etc. The architecture view shows how the software architecture is broken down into components, and how the components are connected by connectors to produce useful forms, thereby recording the major structural design decisions. These design decisions must be based on requirements and functional, complementary, and other constraints. These decisions, in turn, impose further constraints on requirements and future design decisions at a lower level.

Architecture is represented by many different architectural views that essentially graphically summarize model elements that are "important in architecture". In the Rational Unified Process, you will start with a typical view set called a "4 + 1 view model." it includes:

Use case view: Includes use cases and scenarios that include behavior, class, or technical risks that are significant in terms of architecture. It is a subset of the use case model.

Logical view: Includes the most important design classes, the organizational form from these design classes to packages and subsystems, and the organizational form from these packages and subsystems to layers. It also includes some use case implementations. It is a subset of the design model.

Implementation view: Includes an overview of the implementation model and its organizational form from modules to packages and layers. It also describes the assignment of packages and classes in the logical view to packages and modules in the implementation view. It is a subset of the implementation model.

Process view: Includes a description of the tasks (processes and threads) involved, their interactions and configurations, and the assignment of design objects and classes to tasks. This view is only needed if the system has a high degree of parallelism. In the Rational Unified Process, it is a subset of the design model.

Configuration view: Includes a description of the various physical nodes of the most typical platform configuration and the assignment of tasks (from the process view) to the physical nodes. This view is required only in distributed systems. It is a subset of the deployment model.

The architecture view is recorded in the software architecture document. You can build other views to express different aspects that require special attention: user interface views, security views, data views, and more. For simple systems, some views in the 4 + 1 view model can be omitted.

Although the above view can represent the overall design of the system, the architecture is only related to the following specific aspects: The structure of the model, that is, the organizational model, such as layering.

The basic elements, namely key use cases, main classes, common mechanisms, etc., are opposite to each element in the model.

Several key scenarios, they represent the main control flow of the entire system.

Services that record modularity, optional features, and product line status.

Architectural views are essentially abstractions or simplifications of the overall design. They highlight important features by discarding specific details. These characteristics are important when considering the following:

1. System evolution, that is, entering the next development cycle.

2. Reuse a framework or part of a framework in a product line environment.

3. Assess supplement quality, such as performance, usability, portability, and security.

4. Allocate development work to teams or subcontractors.

5. Decide whether to include commercially available components.

6. Insert a wider range of systems. ^[1]

Architecture

Architecture mode is a ready-made form to solve complex architecture problems. An architectural framework or architectural infrastructure (middleware) is a collection of components on which a certain architecture can be built. Many of the major architectural difficulties should be addressed in a framework or infrastructure, and are usually targeted to specific areas: command and control, MIS, control systems, and so on.

The architectural patterns are categorized according to the characteristics of the system to which they are most applicable, one of which deals with more general structural problems. The following table shows the categories provided in [BUS96] and the modes contained in these categories.

category	mode
structure	Floor
Pipes and filters
blackboard
Distributed Systems	proxy
Interactive system	Model-view-controller
Representation-abstract-control
Adaptive system	reflection
Microkernel

To clarify their meaning, two of them will be detailed below. For a complete description, please refer to [BUS96].

Patterns are expressed in the following widely used forms: pattern names, environments, problems, impacts, descriptions of different problem areas that should be considered, solutions, basic principles, result environments, examples, pattern name layers, environments, large structures that require structural decomposition Systems, problems must be systems that deal with problems at different levels of abstraction. For example: hardware control issues, common service issues, and issues specific to different areas. It is best not to write vertical components to deal with all levels of abstraction. Otherwise you have to deal with the same problem multiple times in different components (may be inconsistent).

Impact: Some parts of the system should be replaceable; changes in components should not fluctuate; similar responsibilities should be grouped together; component size-complex components may need to be broken down

Solution: Divide the system into component groups, and make the component groups form a layered structure. Make the upper layer use only the services provided by the lower layer (never the upper layer). Try not to use services that are not directly provided by the lower layer (do not jump to the layer to use services, unless the middle layer only adds pass-through components).

Example:

General layer

Common layer The strict hierarchical structure stipulates that design elements (classes, components, packages, subsystems) can only use the services provided by the lower layers. Services can include event handling, error handling, database access, and so on. It includes more obvious mechanisms than the underlying operating system-level calls recorded at the bottom.

Business system layer

Business system layer The figure on the right shows another layered example with vertical application-specific layers, horizontal layers, and infrastructure layers. Note: The goal here is to take a very short business "chimney" and achieve commonality across applications. Otherwise, there may be multiple people working on the same issue, leading to potential differences.

Environment: An area where there is no definitive method (algorithm) to solve the problem or the method is not feasible. Examples include AI systems, speech recognition and surveillance systems.

Problem: Multiple problem solving consultants (knowledge consultants) must collaborate to solve problems that they cannot solve individually. The results of each consultant's work must be accessible to all other consultants so that they can assess whether they can participate in finding a solution and post their results.

Impact: The order in which knowledge consultants are involved in solving the problem is not determined, which may depend on the problem solving strategy; the input (results or partial solutions) of different consultants may have different representations; each consultant does not directly know the existence of the other, Can evaluate work posted by the other party

The solution: Multiple knowledge consultants can access a shared database called a "blackboard." The blackboard provides an interface to monitor and update its content. The control module / object activates a consultant following a certain strategy. After activation, the consultant looks at the blackboard to determine if it can participate in solving the problem. If the consultant decides that it can participate, the controlling object can allow the consultant to place its partial (or final) solution on the blackboard.

Example:

Structural or static views modeled using UML The above shows a structural or static view modeled using UML. It will be part of the parametric collaboration, and will then be bound to the actual parameters to instantiate the pattern.

Architectural style

The software architecture (or just the architecture view) can have an attribute called architecture style, which reduces optional forms and makes the architecture consistent to a certain degree. A style can be defined by a set of patterns or by selecting a specific component or connector as the basic component. For a given system, certain styles can be documented in the architectural style guide (part of the design guide document in the Rational Unified Process) as part of the architectural description. Style plays a major role in the understandability and integrity of the architecture.

Architecture architecture design diagram

The graphical description of the architectural view is called the architectural design drawing. For the various views described above, the design diagram consists of the following unified modeling language diagrams [UML99]: Logical views: class diagrams, state machines, and object diagrams.

Process view: class diagram and object diagram (including tasks-processes and threads).

Implementation view: component drawing.

Deployment view: configuration diagram.

Use case view: Use case diagrams describe use cases, protagonists, and common design classes; sequence diagrams describe design objects and their collaborative relationships.

Architecture Design Process

In the Rational Unified Process, architecture is primarily the result of analyzing and designing workflows. When the project goes through this workflow again, the architecture will continue to evolve, improve, and refine over iterations. Because each iteration includes integration and testing, the architecture is quite robust when the product is delivered. The architecture is the focus of each iteration of the elaboration phase, and the baseline of the architecture is usually determined at the end of this phase.

Architect

There are some software designers with high technical level and rich experience. They need to undertake the architecture design of the software system, that is, how to design the components of the system, how the components interact with each other, and the logical, Making important physical and systematic decisions.

Such people are called architects. In many companies, the architect is not a specialized and formal position. Usually in a development team, the most experienced programmers are responsible for some architectural work. In a department, the most experienced project managers will be responsible for some architectural work.

However, more and more company groups recognize the importance of architectural work and set up specialized architect positions at different organizational levels, who are responsible for the design and configuration of logical, physical, and system architectures at different levels. , Maintenance, etc.

Architect Classification

According to different responsibilities, architects are usually divided into enterprise architects, information architects, database architects, business architects, technical architects, system architects, and so on.