Software architecture is a series of related abstract patterns used to guide the design of various aspects of a large software system. A software architecture is a system sketch. The object of the software architecture description is the abstract component that directly forms the system. The connections between components clearly and in a relatively detailed manner describe the communication between components. In the implementation phase, these abstract components are refined into actual components, such as a specific class or object. In the Object-Oriented field, the connection between components is usually implemented through interfaces _ (computer science.
Software Architecture is the basis for building computer software practices. The same as the design principles and objectives set by architects for building projects, which serves as the basis for drawing by drafters, A software architect or System Architect states the software architecture to serve as the basis for the actual system design scheme meeting the needs of different customers.
Software Architecture is an easy-to-understand concept. Most engineers (especially those with little experience) will come to understand it intuitively, but it is difficult to give accurate definitions. In particular, it is difficult to clearly define the regional design and architecture: the architecture belongs to the design aspect, which focuses on some specific characteristics.
In the "Software Architecture Introduction", David Garlan and Mary Shaw think that software architecture is a design level related to the following issues: "In addition to computing algorithms and data structures, designing and determining the overall structure of the system becomes a new problem. Structural issues include the overall organizational structure and global control structure; Communication, synchronization and data access protocols; functional allocation of design elements; physical distribution; composition of design elements; calibration and performance; select an alternative design."
However, the architecture is not only a structure; IEEE Working Group on Architecture defines it as "the highest level concept of the system in its environment ". The architecture also includes "compliant" system integrity, economic constraints, aesthetic needs and styles. It not only focuses on internal considerations, but also on the overall considerations of the system in the user and development environments of the system, that is, it also focuses on external considerations.
In Rational Unified Process, the architecture of a software system (at a given point) refers to the organization or structure of important system components, these important components interact with components composed of decreasing components and interfaces.
In connection with the purpose, subject, material, and structure, the software architecture can be comparable to the architecture of a building. A software architect must have extensive theoretical knowledge and relevant experience in fact and manage the advanced design of software products. Software architects define and design software modularization, interaction between modules, user interface style, external interface methods, innovative design features, and object operations, logic, and processes of high-level things.
In general, the architecture of a software system has two elements:
· It is the highest level of division of a software system from the whole to the part.
A system is usually composed of components, and how these components form and interact with each other is an important information about the structure of the system.
Specifically, it includes architecture components, connectors, and task-flow ). The so-called architecture element is the core "brick" of the system, and the connector describes the path of communication between these components, the mechanism of communication, and the expected results of communication, the task flow describes how the system uses these components and connectors to fulfill a requirement.
· The highest level of commercial and technical decisions made by building a system that will be difficult to change in the future.
There are many important decisions that need to be made prior to building a system. Once the system starts to be designed or built in detail, these decisions are hard to change or even unable to be changed. Obviously, such a decision must be the most important decision on the success or failure of system design and must be carefully studied and investigated.
As early as the 1960 s, such as E. W. Dykstra had already involved the concept of software architecture. Since the 1990 s, the concept of software architecture has become increasingly popular thanks to activities within Rational Software Corporation and Microsoft.
Carnegie Mellon University and University of California's Elvin have done a lot of research in this field. Mary Shaw and David Garlan from Carnegie Mellon University wrote a book called software architecture perspective on an emerging discipline in 1996, proposing many concepts in the software architecture, such as software components, connectors and styles. The work done by the Institute of Software Research at the University of California, Elvin, focuses on the architectural style, Architecture Description Language, and dynamic architecture.
The history of Computer Software began in 1950s, and its history was very short. In contrast, construction engineering started from the Stone Age, and humans have accumulated a lot of experience and lessons in architectural design practices for thousands of years. Architectural Design basically includes two points: architectural style and architectural model. The unique architectural style and the appropriate architectural model can be unique.
The relationship between software and human beings is the core issue that architects must face. It is also a problem that has occurred since the software entered the stage of history. Like this, the relationship between architecture and human beings has been the core issue that architects must face since building. British Prime Minister Churchill said that we constructed a building and then constructed us (we shape our buildings, and afterwards our buildings shape us ). The conference hall in the lower House of Commons is narrow, so that all members of the lower House of Commons cannot be seated in the same direction, but must be divided into two sides. Churchill believes that Members of Parliament will naturally choose to sit at the same time as their political views, which refer to the origins of British political parties. The original intention of party is "fang" and "face ". The key to the origins of political parties is the influence of buildings on people.
In the software design field, many people think that the function is the most important, and the form must obey the function. Like this, Louis Sullivan, one of the creators of modern architecture schools in the architectural field, also believes that the form should be subject to the function (Forms follows function ).
Almost all software design concepts can find more distant historical echoes in the vast history of architecture. The most famous, of course, is the model theory and XP theory.
What is the goal of the architecture?
Just as the software has its own goals, what are the goals of architecture design? In general, the software architecture design should achieve the following goals:
· Reliability ). Software systems are extremely important for users' business operations and management. Therefore, software systems must be very reliable.
· Secure ). The business value of the transactions undertaken by the software system is extremely high, and the security of the system is very important.
· Scalable ). The software must be able to maintain reasonable performance when the user's usage and number of users increase rapidly. Only in this way can we adapt to the possibility of expanding the user's market.
· Customizable ). The same set of software can be adjusted based on different customer groups and changes in market demands.
· Extensible ). When the emergence of new technologies, a software system should allow the import of new technologies to expand the functions and performance of existing systems.
· Maintainable ). Maintenance of software systems includes two aspects: first, to eliminate existing errors, and second, to reflect new software requirements to existing systems. An easy-to-maintain system can effectively reduce the cost of technical support
· Customer experience ). Software systems must be easy to use.
· Time to market ). Software Users must face intra-industry competition, and software providers must also face intra-industry competition. It is very important to compete for market opportunities as quickly as possible.
Architecture type
Based on our concerns, we can divide the architecture into three types:
· Logical architecture, relationships between components in software systems, such as user interfaces, databases, external system interfaces, and commercial logic components.
For example, the following figure shows the logical architecture of a software system that I have personally experienced.Figure 2. Example of a logical architecture
From the figure above, we can see that the system is divided into three logical layers: appearance level, business level and data persistence level. Each layer contains multiple logical components. For example, the web server layer includes HTML service components, session service components, security service components, and system management components.
· How the physical architecture and software components are put on the hardware.
For example, the following physical architecture diagram describes the physical architecture of a distributed system distributed in Beijing and Shanghai. All the components in the diagram are physical devices, including Network Shunt, proxy server, web server, application server, Report Server, consolidation server, storage server, host, and so on. Figure 3. A physical architecture example
· System architecture and non-functional features of the system, such as scalability, reliability, robustness, flexibility, and performance.
The design of the system architecture requires the architect to have excellent knowledge of the functions and performance of software and hardware, which is undoubtedly the most difficult task in architecture design.
In addition, from each perspective, we can see two elements of the Architecture: component division and design decision.
First, components in a software system are logical components first. How these logical components are put on the hardware, and how they contribute to the scalability, reliability, robustness, flexibility, and performance of the entire system are very important information.
Second, the decisions that need to be made for software design will inevitably include the logical structure, physical structure, and how they affect all the non-functional features of the system. Many of these decisions are hard to be changed once made.
Based on the author's experience, a database-based system architecture, how many data tables will be there on how many pages of architecture design documents. For example, a medium database application system usually contains about one hundred data tables. Such a system design usually requires about one hundred pages of architecture design documents.
Architecture Description
To discuss and analyze the software architecture, you must first define the Architecture Representation, that is, the method that describes the important aspects of the architecture. In rational uniied process, this description is recorded in the software architecture documentation.
Architecture View
We decided to express the software architecture with multiple architectural views. Each architectural view focuses on specific aspects of the development process, such as end users, designers, Administrators, System Engineers, and maintenance personnel.
The architecture view shows how the software architecture is broken down into components and how the component is connected by a connector to generate a useful form [pw92], which records major structural design decisions. These design decisions must be based on requirements and functional, complementary, and other constraints. These decisions impose further constraints on requirements and future design decisions at a lower level.
Typical architecture view Gallery
The architecture is represented by many different architectural views. These views are essentially a graphical summary of the model elements that indicate "significant architectural significance. In Rational Unified Process, you will start with a typical visual gallery called the "4 + 1 view model" [kru95]. It includes:
Use Case view: includes use cases and scenarios. These use cases and scenarios include behavior, class, or technical risks that are significant in architecture. It is a subset of the use case model. Logical view: includes the most important design classes, the organization form from these design classes to packages and subsystems, and the organization form from these packages and subsystems to layers. It also includes some use cases. It is a subset of the design model. Implementation view: includes an overview of the implementation model and its organizational form from module to package and layer. It also describes how to allocate 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 descriptions of involved tasks (processes and threads), their interaction and configuration, and the allocation of design objects and classes to tasks. This view is required only when the system has a high degree of parallelism. In rational uniied process, it is a subset of the design model. Configuration view: describes the various physical nodes configured on the most typical platform and assigns tasks (from process view) to physical nodes. This view is only required in a distributed system. 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 view, security view, data view, and so on. For a simple system, some views in the 4 + 1 view model can be omitted.
Architecture focus
Although the above view can represent the overall design of the system, the architecture is only relevant to the following specific aspects:
The structure of the model, that is, the organizational model, such as hierarchy. Basic elements, such as key cases, primary classes, and common mechanisms, are opposite to each element in the model. In several key scenarios, they represent the main control process of the entire system. A service that records module level, optional features, and product line status.
Architectural View is essentially an abstraction or simplification of the overall design. They highlight important features by dropping details. These features are important when considering the following:
System Evolution: enters the next development cycle. Reuse a part of the architecture or architecture in the product line environment. Evaluate supplemental quality, such as performance, availability, portability, and security. Allocate development work to teams or subcontractors. Determine whether to include commercial components. Insert a wider range of systems.
Architecture Mode
The architecture mode is a ready-made solution to the recurrence architecture problem. A framework or architecture infrastructure (middleware) is a set of components on which a certain architecture can be built. Many of the major architectural difficulties should be addressed in the framework or infrastructure, and are usually targeted at specific areas: command and control, MIS, control systems, and so on.
Architecture mode example
[Bus96] classifies the architecture based on the characteristics of the most suitable system, and one category handles more common structural problems. The following table shows the categories provided in [bus96] and the patterns contained in these categories.
CATEGORY mode structure layer pipelines and filters blackboard distributed system proxy Interaction System Model-View-controller representation-Abstraction-control adaptive system reflection microkernel Software Architecture is an easy-to-understand concept. Most engineers (especially those with little experience) will come to understand it intuitively, but it is difficult to give accurate definitions. In particular, it is difficult to clearly define the regional design and architecture: the architecture belongs to the design aspect, which focuses on some specific characteristics.
In the "Software Architecture Introduction", David Garlan and Mary Shaw think that software architecture is a design level related to the following issues: "In addition to computing algorithms and data structures, designing and determining the overall structure of the system becomes a new problem. Structural issues include the overall organizational structure and global control structure; Communication, synchronization and data access protocols; functional allocation of design elements; physical distribution; composition of design elements; calibration and performance; select an alternative design." [Gs93]
However, the architecture is not only a structure; IEEE Working Group on Architecture defines it as "the highest level concept of the system in its environment" [ieee98]. The architecture also includes "compliant" system integrity, economic constraints, aesthetic needs and styles. It not only focuses on internal considerations, but also on the overall considerations of the system in the user and development environments of the system, that is, it also focuses on external considerations.
In Rational Unified Process, the architecture of a software system (at a given point) refers to the organization or structure of important system components, these important components interact with components composed of decreasing components and interfaces.
To clarify its meaning, two of them are described below. For a complete description, see [bus96]. Mode the following columns are widely used for representation:
Impact of the mode name environment problem, description of different aspects to be considered solution basic principles result environment example mode name Layer
Large systems that require structural decomposition in the environment.
The problem must be addressed by a system with different levels of abstraction. For example, hardware control problems, common service problems, and problems in different fields. It is best not to write vertical components to deal with all abstract levels. Otherwise, the same problem must be handled multiple times in different components (which may be inconsistent ).
Impact
Some parts of the system should be the changes in replaceable components and should not fluctuate. the responsibility should be similar to the size of a group of components. complex components may need to be decomposed. A solution should be used to divide the system into component groups, and make the component group form a cascade structure. Make the upper layer only use the services provided by the lower layer (never the upper layer. Do not use services not provided in the lower-layer as far as possible (do not skip the layer to use services, unless the middle layer is added only through components ).
Example:
1. General Layer
Strict Hierarchical Architecture specifies that only lower-level services can be used for design elements (classes, components, packages, and subsystems). Services can include event processing, error processing, and database access. Compared with the underlying original operating system-level calls recorded, it includes a more obvious mechanism.
2. Business System Layer
An example of another layer is displayed, which consists of a specific vertical application layer, a horizontal layer, and an infrastructure layer. Note: The goal here is to adopt a very short business "chimney" and achieve the versatility among various applications. Otherwise, multiple people may solve the same problem, resulting in potential disagreements.
For an in-depth discussion of this mode, see the Guide: layering.
Model name blackboard
The environment does not have a domain for determining the method (algorithm) or method to solve the problem. Such as ai systems, voice recognition and monitoring systems.
Problem-solving consultants (Knowledge consultants) must collaborate to resolve issues that they cannot resolve independently. The work results of each consultant must be accessible to all other consultants so that they can assess whether they can participate in the search for a solution and publish their work results.
Impact
The order in which the knowledge consultant participates in solving the problem is not fixed, which may depend on the problem solving strategy.
Input (results or some solutions) of different consultants may have different representations
Consultants do not directly know the other party's existence, but they can evaluate the work published by the other party.
Solution: Multiple Knowledge consultants can access a shared database named "Blackboard. The blackboard provides interfaces for monitoring and updating its content. A policy-based Advisor for control module/object activation. After activation, the consultant checks the blackboard to determine whether it can participate in solving the problem. If the consultant decides that it can participate, the control object can allow the consultant to place part (or final) of the solution on the blackboard.
Example:
The above shows the structure or static view modeled using UML. It will be part of parameterized collaboration and then bound to real parameters to instantiate the mode.
The architectural style Software Architecture (or only the Architectural View) can have an attribute named architectural style. This attribute reduces the Optional Form and makes the architecture consistent to a certain extent. Styles can be defined in a set of modes or by selecting a specific component or connector as the basic component. For a given system, some styles can be recorded as part of the architectural description in the architectural style guide (part of the design guide document in Rational Unified Process. Styles play a major role in structural comprehensibility and integrity.
The Graphical description of the architectural design diagram is called the architectural design diagram. For the various views described above, the design diagram consists of the following Unified Modeling Language diagram [uml99]:
Logical view: class chart, state machine, and object graph. Process view: class diagram and object diagram (including task-process and thread ). Implementation view: component diagram. Deployment view: configuration chart. Use Case view: the use case diagram describes the use case, the main character, and the general design class. The sequence diagram describes the design object and its collaboration relationship. In the Rational Unified Process, the architecture mainly analyzes the results of the design workflow. When the project goes through this workflow again, the architecture will evolve, improve, and refine over and over again. Since each iteration includes integration and testing, the architecture is quite strong when delivering products. Architecture is the focus of each iteration in the final stage, and the baseline of the architecture is usually determined at the end of this stage.
Architect
Software designers who have high technical skills and rich experience need to design the architecture of the software system, that is to say, we need to design how the system's components are divided, how components interact, and how logical, physical, and important decisions are made in the system.
Such a person is called an architect ). In many companies, architects are not specialized and formal roles. Generally, the most experienced programmer in a Development Group is responsible for some architectural work. The most experienced project manager in a department is responsible for some architecture work.
However, more and more companies recognize the importance of architecture work and set specialized architect positions at different organizational levels, they are responsible for the design, configuration, and maintenance of logical architecture, physical architecture, and system architecture at different levels. |
