25 years ago, the ancient Roman architect Vitruwei said: "The ideal architect should be both a literary person and a digital home. He should also know history, passionate about philosophical research, proficiency of music, understand medical knowledge, and , Well-versed astronomy and astronomical calculation. "(It's so, the requirements of the software architect designer? Do you think about it.)
First, several basic concepts related to the architecture:
1, Module: A group of statements that complete the specified function, including: input, output, logic processing, internal information, running environment (corresponding to the function but not one-on-one relationship).
2. Component: It is quite important in the system, which is almost independent alternative to implement exact functions in a clearly defined architecture environment.
3, mode (Pattern): Refers to a solution template (for structural and behavior) of at least a practical environment (more time, several environments. In UML: mode by parameterized collaboration Indicates, but UML does not directly pair other aspects (such as using the results list, use examples, etc., which can be represented by text). There are various ranges and abstraction patterns, such as architecture, analysis mode, design Mode and code mode or implementation mode. Mode will help us seize the focus. The architecture is also modeled. For example, for system structure design, we use layer mode; for distributed systems, we use proxy mode (by using agent) The actual object allows the program to control access to this object); for the interactive system, we use the MVC (M Model (Object) / V View (Output Management) / C Controller (Input Processing)) mode. Mode is for specific The problem of the problem, so we can also use the corresponding model to design the architecture for the characteristics of the demand.
4, Architectural Pattern: Represents the basic structural organization of the software system. It provides a set of predefined subsystems to specify their responsibilities and include rules and guidance for organizing relationships.
5. Layer: a particular way to group the package in the same abstraction level in the model. Through layers, the subsystem is logically divided into a number of collections, while the formation of interlayer relationships should follow certain rules. Through the layering, the dependencies between subsystems can be limited, so that the system is coupled to more loosely, making it easier to maintain. (The layer is the lateral division of the frame, the partition is the longitudinal division of the framework).
6. Several common methods of system layering:
1) Commonly used three-layer service: user layer, business logic layer, data layer;
2) Technical composition model of multi-layer structure: performance layer, intermediate layer, data layer
3) Network system commonly used three-layer structure: core layer, aggregation layer and access layer;
4) RUP typical hierarchical method: application layer, professional business layer, middleware layer, system software layer
5) Based on Java-based B / S mode system structure: browser, server, request receiving layer, request processing layer;
6) A six-layer structure: functional layer (user interface), module layer, assembly layer (software bus), service layer (data processing), data layer, core layer
7. Architecture, art and science is willing to build architecture design and buildings): Definition in RUP: Software system architecture (at a given point) refers to the organization or structure of the system important components, these important The component interacts through the interface and the constant reduced member, and the definition of "Software Architecture Practice": a software architecture of a software or computing system constitutes one or more structures of the system, they constitute a software Each part, forming the external visible attributes of these components and inter-intercom; the definition in IEEE 1471-2000: The Fundamental Organization of a System Emboided in Its Components, Their Relationships To Each Other, and To the Enviroment and The Principles Guiding ITS Design and Evolution, architecture is the highest level of system in its environment. The structure of the software system is an important component (at a specific time point) of an interface interact, which consists of some smaller components and interfaces. ("Soft Frame" can be used as a noun, as a verb, as a "architecture" equivalent to "architecture") 8, the architecture: "4 1" view (with example view, design view, implementation view, process view, " Configuration view) is a model description of a widely used architecture; the RUP process architectural description template adds an optional data view on the basis of the "4 1" view (description of the system from the permanent data storage); HP's software description template is also based on the "4 1" view.
9. Structure: Software architecture is an embodiment of a variety of structures, and the structure is a view produced from different angles of view. Just like the structure of the building, as a variety of meanings as the observer and starting point, the software framework also manifests into a variety of structures. Common software structures include: module structure, logic or conceptual structure, process or coordination structure, physical structure, use structure, call structure, data stream, control flow, class structure, etc.
Second, the factors that the architecture design should be considered:
The module architecture can be considered from the runtime structure of the program and the organizational structure of the source code.
1. Considering the runtime structure of the program:
1) Compliance with demand: correctness, integrity; functional needs, non-functional demand;
2) Overall performance (memory management, database organization and content, non-database information, task parallelism, network multiplayer operation, key algorithm, related network, hardware, and other system interfaces on performance);
3) Run manageability: Easy to control system operation, monitor system status, error handling; simplicity of inter-module communication; different maintenance;
4) Compatibility with other system interface;
5) Compatibility and performance between networks, hardware interface;
6) System security;
7) System reliability;
8) Adjustability of business processes;
9) Adjustability of business information
10) Use convenience
11) Consistency of architecture style
Note: Running load balancing can be considered from system performance, system reliability.
2, the organizational structure of the source code is considered:
1) Develop manageability: Easy to divide staff (module independence, load balancing, progress arrangement, optimization, prevention personnel flow on development), facilitating configuring management, rationality and moderate complexity;
2) Maintainability: Different from running manageability; 3) Expandability: Upgrade, expansion, expansion performance of system solutions;
4) Portability: Different clients, application servers, database management systems;
5) Compliance with demand (considerations in the organizational structure of the source code).
Third, the runtime structure of the program:
1. Compliance with requirements: correctness, integrity; functional demand, non-functional demand
The main goal of software projects is to meet customer needs. When the architecture is performed, you consider which run platforms, compile language, development environments, database management systems, etc., for insufficient considering related to customer needs, not enough system. If you can't satisfy your customer's clear functional demand or non-functional demand, you should be coordinated in the project scope and demand specifications. Otherwise, the architecture design should be to meet the most basic goals of all customers, try to meet their implicit needs. (The customer's non-functional demand may include interface, system security, reliability, transplantability, scalability, etc., in other sub-sections)
In general, functional requirements determine business framework, non-functional demand, determined technology framework, and change cases determine the scope of the architecture. Demand knowledge tells us that functional demand defines what software can do. We need to design business architecture based on business needs to enable future software to meet customer needs. Non-functional demand defines some of the performance and efficiency of some constraints, rules. And our technical framework must meet these constraints and rules. The change case is an estimate of the possible changes in the future, combined with functional requirements and non-functional needs, we can determine the range of demand, and then determine a frame range. (This section from Lin Xing)
Here is a small example of a small number of system performance and reliability issues due to certain incorrect issues in the previous year: This system is relatively simple, which is a relatively simple history of a certain city. The file card scan is stored so that you can query according to the name. The customer said that the customer said that the card has approximately 200,000, demand surveillars, for verifying the total amount of data for the customer's trust. Since it is a small and medium amount of data, the future data does not increase, after calculating the total capacity of 200,000 cards, it is decided to use a small and medium-sized database management system that can be used in the network. When the system completes the start of the data, it is found to have at least 600,000 data, so that the small and medium-sized database management system will not only cause system performance, but the reliability is very fragile, and the system has to be redesigned. From this small lesson, it can be seen that the demand phase not only is clearly investigated for customers, but also some data implicitly non-functional needs should also be investigated, and as the basis for architectural design.
For the correctness of the functional requirements, it may not be good to verify in the architecture document (need to manually, labor). For functional demand integrity, the demand function should be used to track traceability with the corresponding module control table. For non-functional demand correctness and integrity, you can use the requirements non-function and the corresponding design policy control table to track traceability evaluation.
"Software design work is only possible based on user needs, and it is possible to succeed in feasible techniques."
2, overall performance
Performance is actually part of customer needs, of course, may be clear, there are many implicit, here is listed separately in explanation. Performance is an important criterion for design, and performance should be considered for a single client performance, but should consider the total comprehensive performance of the system;
Performance design should be considered from the following aspects: memory management, database organizations, and content, non-database information, task parallelism, network multiplayer operation, key algorithm, and network, hardware, and other system interfaces on performance;
Some Tips: Algorithm optimization and load balancing are the direction of performance optimization. The modules that are often called must be paid to optimization. The variables that occupy more memory will be cleaned up in time. The web topic file that needs to be downloaded is too large to decompose into several parts, allowing users to display the main part first. 3, run manageability
The architecture design of the system should prevent the system to predict the system failure, prevent problems. The current system is gradually complicated, large-scale development, alone, alone or several people, has been distinct, and the response to certain emergencies is not enough. Therefore, through a reasonable system architecture planning system running resources, it is easy to control system operation, monitor system status, effective error handling; in order to achieve the above objectives, the module communication should be as simple as possible, and establish a reasonable and detailed system running log, the system passes Automatic audit operation log, understand the system running status, perform effective error handling; (Different run-manageable and maintenanceability)
4, compatibility with other system interfaces (explanation)
5, compatibility with network, hardware interface (omitted)
6, system security
With the continuous in-depth and expansion of computer applications, the sectors and information involved are increasing, with a large number of confidential information on the network, so considering system security has become the key to system design, need to be from all aspects and The angle is considered to ensure the absolute security of data data.
7, system reliability
The reliability of the system is an important feature of the modern information system. Since people's daily work is more and more, the system must be reliable. System architecture design can consider the redundancy of the system, avoid single point failure as much as possible. The system reliability is the probability of successfully running the program in design requirements under a given time interval and a given environmental conditions. Successfully run not only to ensure that the system can operate correctly, meet functional needs, and also require that the system can restore normal operation as soon as possible, the data is not damaged.
8, adjustability of business processes
It should be considered that the changes in the customer's business process should be considered, so try to exclude the business process in the system architecture, that is, work in the process as an independent object, design into a separate module or component, fully considering They interested in various business objects or components between the various business object modules, which implements various services through the mutual calls of the business object module, so that when the business process changes (each business module itself does not change the business logic In the case where it is possible to easily modify the call relationship between the system program module or the component to achieve new needs. If this call relationship is designed to store the data dictionary stored in the configuration library, even the program code does not have to modify it, just modify the module or component call rules in the data dictionary.
9. Adjustability of business information
The possible changes in customer business information should be considered, so it is necessary to reduce the impact of the adjustment of business information for the code module when designing the system architecture.
10, easy to use
Easy to use is an inevitable requirement that does not need to be mentioned, and the use of convenience and system architecture is closely related. The failure of wince (1.0) and the success of the improved version will explain this problem. WinCE (1.0) has too many levels of window and menu, and users prefer simple interfaces and fast operations. Failure should be corrected in time, but it is best not to wait until the failure is changed, which will waste huge financial resources, so it is best to consider the factors that need to be considered during the system architecture. Of course, the use of convenience must be harmonized with the system security, and the use of convenience must also be unified with the adjustability of the business process and the adjustable coordination of business information. "Meet the user's needs, easy to use, and make the operational process as simple as possible. This is the foundation of the design."
11, consistency of architecture style
Software system architectures are some similar to architectural style (such as Chinese style, gothic, greek vintage). Software architectures can be divided into data streaming patterns, call return architecture, stand-alone component architects, with data-centric architectural style and virtual mechanism style, each style can also be divided into several child styles. The consistency of architecture is not required to require a software system to use a style, just like the building style can be combined with Chinese and Western, software systems can also have heterogeneous framework (divided into local heterogeneous, hierarchical heterogeneous, and different Quality), that is, a combination of a variety of styles, but such synthesis should consider certain aspects of consistency and coordination. Each style has its own timing that should be selected based on the most emphasized quality attributes of the system. Fourth, the organizational structure of the source code is considered:
1. Develop manageability
Easy personnel division (module independence, development work load balancing, progress arrangement optimization, prevention personnel flow on development: a good architecture should also help reduce the pressure and tension of the project team, improve software development efficiency), and benefit Configuration management, the rationality of size, moderate complexity;
1) Easy personnel division-module independence, hierarchical
The module independence, hierarchical is to ensure the relative independence between the project development member work, the module connection mode should be longitudinal instead of the transverse direction, the module should be a tree structure rather than a mesh structure or a cross-structure, so that The communication between developers, the module development restricting relationship is minimized. At the same time, the module independence is also conducive to configuration management work. More and more software development is now carried out in different places, and a member of a development group may be in different cities, even in different countries, so it is necessary to operate the source code organization of personnel to develop from differently developed.
2) Easy to divide the labor - the load balance of development work
Not only the software system developed is required to load balancing, but also is not important in the load balance of the work tasks between the members of the Group during the development process. The load balancing of the so-called work tasks is to assign tasks in accordance with the characteristics of the developer through reasonable tasks, and try to make each person in the project group each time. This requires the need to fully consider the human resources of the project team when designing the architecture, and achieve the load balance of development work on the basis of customer needs to improve overall development efficiency.
3) Easy to divide the division - progress arrangement optimization;
The premise of progress schedule optimization is the module independence and understand the success of module development. Using the work decomposition structure to decompose all program coding work, you can get the input, output, desired resources, duration, before, before completion of work, and work after completion. Then estimated that each module needs time, analyzes the parallel and serial (sequential constraints) of each module, plotting the network diagram, identifying a key module affecting the overall progress, calculating a critical path, and finally adjusting the network map to make progress arrangements optimize.
There is a household-known intelligence title to barbecue strategies: Johnson has a barbecue rack that can bake two pieces of meat at the same time at the same time, and take 10 minutes to roast each piece of meat. a family of three. The problem is how to get three pieces of meat in the shortest time. The general approach spent 20 minutes before roasting the first two pieces, and it took 20 minutes to get the third piece. There is a better way to save 10 minutes, everyone thinks.
4) Easy to divide the division of labor - the impact of preventing the development of employee personnel
The flow of people flow in the software industry is a common risk. As one of the effective countermeasures for this risk, it can take into account the influence of employee personnel flow in the structure. The main idea is to pursue high-end phenomenal coupling on the independence of the module), and componentization is currently popular.
5) Conservancy to configuration management (independence, hierarchical)
It is conducive to configuration management and a certain connection to personnel. In addition to logical module components, the deployment of source code files in the physical source code, the directory structure, and various modules should also be beneficial to personnel division and configuration management. (Although now the management tool has a strong function, a clear source split and module segmentation is very beneficial). 6) Rationality and moderate complexity of the size
The reasonableness and moderate complexity of the size can make the development of the load balance, easy progress, or minus the system to reduce unnecessary memory resources at runtime. There is also a certain benefit to the readability of the code and the maintenanceability of the system. In addition, excessive modules are often insufficient system decomposition, and too small modules may reduce the independence of the module, resulting in complex system interfaces.
2, maintainability
It is easy to find the cause and source location of the fault and source code, which can be easily changed, and can be easily handled in time, and can be easily configured; (can be maintenanceability and operational management)
3, expandability: upgrade, expansion, expansion performance of system scheme
The system will have a long running cycle after completion. In this cycle, the application is increasing, the level of application is constantly upgrading, so the structural design such as architecture design is considering the feasibility and convenience of upgrade, expansion, expansion.
4, portability
Different clients, application servers, database management systems: If the client used by the potential customers may use different operating systems or browsers, their portability must consider the portability of the client program, or try to make the business logic At the client; data processing business logic is placed in the database management system, but if the same database management system cannot be determined in the customer group, the business logic cannot be in the database management system;
Reaching portability must pay attention to standardization and openness: Only widely used international standards, develop open-enabled products, can ensure full interconnection of various types of systems, so that products are more market competitiveness, but also Future system transplants and upgrade extensions provide a foundation.
5, compliance with demand
The symbol of the demand from the source code is mainly considered to consider the software code and the minimum redundancy of the framework for the possible changes in the user's demand (and also make the system have certain scalability).
V. Problems should be considered by writing system architecture
The framework should begin at about 80% of the demand development, and do not have to wait until the demand development is completed, and the project manager needs to evaluate whether it is enough to start building a software architecture at this time.
Give a consistent contour: system overview. A system architecture requires an outlined description, and developers can establish a consistent contour from thousands of details or even dozens of modules or object classes.
The objective of the architecture should be able to clearly illustrate the system concept, the architecture should be as simple as possible, the best framework should be simple, short, clear and unscrupulous, and the solution is natural.
The architecture should first define the main subsystem of the upper layer, and the task of each subsystem should be described, and the preliminary list of each module or object class in each subsystem is provided.
The architecture should describe how to communicate between different subsystems, and a good architecture should minimize communication relationship between subsystems.
An important feature of the success framework is to indicate the most likely changed field, and the most likely changed part of the program should be listed, and how the other parts of the architecture should be indicated.
Reuse analysis, outsourcing: shortening software development cycles, and reducing cost effective programs may not be self-developing software, and can be reused or proof of existing software. The effects of its on the frame should be considered.
In addition to the problem of system organization, the architecture should focus on design decisions on the comprehensive impact, in-depth decision-making areas: external software interface (compatibility, communication method, transfer data structure), user interface (user interface and system level division), database Organization and content, non-database information, key algorithm, memory management (configuration strategy), parallelism, security, portability, multiplayer operation, error handling. To ensure the traceability of the demand, that is, each requirement function has a corresponding module to implement.
The architecture cannot be designed only according to static system objectives, and the dynamic development process, such as the situation of human resources, the progress requirements, and the satisfaction of the development environment. The architecture must support the phased planning, and it should be able to provide how to develop and completed in phased planning. Subsystem architectures that should not be run independently. Find the part of the system, dependence, form a set of development plans.
Sixth, conclusion
The system architecture is closely related to the specific development platform of the thousand and different, so universal solutions cannot be given here, mainly for explaining which factors are needed. The design strategy for each factor and the factors not mentioned herein require software architect designers to flexibly grasp in specific development practice. Different factors are sometimes contradictory, and the architecture needs to be balanced according to the specific situation.
