| This article discusses the various factors that should be considered in the system architecture design from two aspects: the runtime structure of the program and the organizational structure of the source code, and lists some issues that should be considered in the system architecture design documents. I. Several Basic concepts related to architecture:
1. Module: A group of statements that complete the specified function, including: input, output, logical processing, internal information, and runtime environment (corresponding to but not one-to-one functions ).
2. Component: a very important and almost independent component that can be replaced in the system. It implements specific functions in a clearly defined architecture environment.
3. Pattern: A verified solution template (used for structure and behavior) that is applicable to at least one practical environment (usually several environments. In UML: the mode is represented by parameterized collaboration, but UML does not directly represent other aspects of the mode (such as using the result list and examples, which can be represented by text) modeling. There are various scopes and abstract modes, such as architecture mode, analysis mode, design mode and code mode or implementation mode. The mode will help us grasp the key points. The architecture also exists. For example, for system structure design, we use the layer mode; for distributed systems, we use the proxy mode (instead of the actual object by using the proxy, enables the program to control access to this object); for interactive systems, we use MVC (M model (object)/V view (output management)/C controller (input processing )) mode. The mode is the solution to specific problems. Therefore, we can also adopt the corresponding mode to design the architecture based on the characteristics of the requirements.
4. Architecture Pattern: represents the basic structure of the software system. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidance for organizing relationships between them.
5. layer: a specific way to group packets at the same abstraction level in a model. Through hierarchy, subsystems are logically divided into many sets, and the formation of inter-layer relations must follow certain rules. Through layering, the dependencies between subsystems can be restricted, so that the system can be coupled in a more loose way, making it easier to maintain. (The layer is the horizontal division of the architecture, and the vertical division of the Architecture ).
6. Several common methods of system layering:
1) Common layer-3 services: user layer, business logic layer, and data layer;
2) multi-layer technical composition model: presentation layer, intermediate layer, and data layer;
3) three layers of Network Systems: core layer, aggregation layer, and access layer;
4) typical hierarchical methods of RUP: application layer, professional service layer, middleware layer, and system software layer;
5) B/S Mode System Structure Based on Java: browser, server, request receiving layer, and request processing layer;
6) a six-layer structure: function layer (User Interface), Module layer, assembly layer (Software Bus), service layer (data processing), data layer, and core layer;
7. Architecture (architecture, art and science that is willing to design and build for Architecture): definition in RUP: Architecture of software systems (at a given point) it refers to the organization or structure of important components of the system. These important components interact with the components composed of decreasing components and interfaces through interfaces. Definitions in Software Architecture Practice: the software architecture of a software or computing system constitutes one or more structures of the system. They constitute each part of the software, forming the external visible attributes of these components and their relationships; 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 the system in its environment . The architecture of a software system is the organization or structure of an important component (at a specific time point) for interface interaction. These components are composed of smaller components and interfaces. ("Architecture" can be used as a noun or verb. The "architecture" of a verb is equivalent to "Architecture Design ")
8. Architecture Description: The "4 + 1" View (Use Case view, design view, implementation view, process view, and configuration view) is a widely used architecture description model; an optional data view is added based on the "4 + 1" view in the framework Description template of the RUP process (the system is described in terms of permanent data storage ); the HP Software Description template is also based on the "4 + 1" view.
9. structure: the software architecture is the embodiment of multiple structures, and the structure is the view generated by the system architecture from different perspectives. Just as the structure of a building has different meanings with the observation motive and starting point, the software architecture also shows multiple structures. Common Software structures include: module structure, logic or concept structure, process or coordination structure, physical structure, usage structure, call structure, data flow, control flow, and class structure.
Ii. factors to be considered in Architecture Design:
The module architecture design can be considered in terms of the program runtime structure and the source code organization structure.
1. Program runtime structure considerations:
1) requirement conformity: correctness and integrity; functional and non-functional requirements;
2) overall Performance (impact of memory management, database organization and content, non-database information, task concurrency, network multi-user operations, key algorithms, and networks, hardware, and other system interfaces on performance );
3) operation manageability: easy to control system operation, monitor system status, and handle errors; simplicity of Inter-module communication; different from maintainability;
4) compatibility with other system interfaces;
5) compatibility with network and hardware interfaces and performance;
6) system security;
7) system reliability;
8) Business process adjustable;
9) adjustable Business Information
10) ease of use
11) Consistency of architectural styles
Note: During running, Server Load balancer can be considered in terms of system performance and system reliability.
2. Source Code Organization Structure considerations:
1) Development manageability: facilitates the division of labor (module independence, development load balancing, scheduling optimization, and prevention of the impact of staff flow on development) facilitates configuration management, rationality of size, and moderate complexity;
2) maintainability: Unlike operation manageability;
3) Scalability: system solution upgrade, expansion, and expansion performance;
4) Portability: different clients, application servers, and database management systems;
5) requirement compliance (Source Code Organization Structure considerations ). Iii. Program runtime structure considerations:
1. Requirement conformity: correctness and integrity; functional and non-functional requirements
The main goal of a software project is to meet the customer's needs. When designing the architecture, you should consider which operating platform, programming language, development environment, and database management system to use, insufficient or systematic consideration of issues related to customer needs. If no good architecture can meet a specific functional or non-functional requirement, you should coordinate with the customer to delete this requirement in the project scope and Requirement Specification. Otherwise, the architecture design should meet all the customer's specific needs as the basic goal, and try to meet the implied needs. (The customer's non-functional requirements may include interfaces, system security, reliability, portability, and scalability, which are described in other sections)
In general, functional requirements determine the business architecture, non-functional requirements determine the technical architecture, and change cases determine the scope of the architecture. Demand side knowledge tells us that functional requirements define what software can do. We need to design the Business Architecture Based on business needs so that future software can meet customers' needs. Non-functional requirements define some performance and efficiency constraints and rules. Our technical architecture must meet these constraints and rules. The change case is an estimation of future changes. In combination with functional and non-functional requirements, we can determine the scope of a requirement and then determine the scope of a framework. (From Lin xing)
Here is a small example of system performance and reliability problems caused by architecture design problems caused by incorrect customer requirements in the past few years: the requirements of this system are relatively simple, scan and store all history file cards of a business in a city so that you can search by name. In the demand phase, the customer said there were about 0.2 million cards, and the demand investigator did not check the total amount of data out of trust in the customer. Because the data volume is small and medium-sized, and the data will not increase in the future, after calculating the total capacity of 0.2 million cards, it is decided to use a small and medium-sized database management system that can be used standalone or networked. When the system starts to input data, it will find that there are at least 0.6 million of the Data. Using such a small and medium database management system will not only cause system performance problems, but its reliability is very fragile, you have to redesign the system. From this small lesson, we can see that the demand phase should not only clearly investigate the customer's functional requirements, but also investigate some data that implies non-functional requirements and serve as the basis for the architectural design.
The functional requirements may be difficult to verify in the architectural design documents (manual and labor-intensive ). For functional requirement integrity, you should use the requirement function and the corresponding module comparison table to track tracing. For the correctness and integrity of non-functional requirements, you can use the requirement non-functional and corresponding design policy comparison table to track and trace the evaluation.
"Software design can be successful only when it is based on user needs and feasible technologies ."
2. Overall Performance
Performance is actually a part of the customer's needs. Of course it may be clear, and many of them are implicit. Here we will list it separately for illustration. Performance is an important standard for the design scheme. performance should be considered not the performance of a single client, but the overall system performance;
Performance design should consider the following aspects: memory Management, database organization and content, non-database information, task concurrency, network multi-user operations, key algorithms, and network, hardware, and other system interfaces affect performance; TIPS: algorithm optimization and load balancing are the direction of performance optimization. You must pay special attention to optimization for frequently called modules. Variables that occupy a large amount of memory should be cleared in time when they are not used. When the page topic file to be downloaded is too large, it should be divided into several parts so that users can display the main parts first.
3. Operation manageability
The system architecture should be designed to enable the system to predict system faults and prevent unexpected problems. The current system is gradually evolving towards complexity and scale-up. One or more people alone cannot manage the system. Moreover, the response to certain emergencies is obviously insufficient. Therefore, it is easy to control system operation, monitor system status, and effectively handle errors through a reasonable system architecture. To achieve the above objectives, inter-module communication should be as simple as possible, at the same time, a reasonable and detailed system operation log is established. The system automatically audits the operation log to understand the system operation status and perform effective error handling. (The manageability and maintainability of the operation are different)
4. compatibility with other system interfaces (explanation)
5. Compatibility with network and hardware interfaces and performance (explanation)
6. System Security
With the development and expansion of computer applications, more and more departments and information are involved. A large amount of confidential information is transmitted over the network. Therefore, the consideration of system security has become the key to system design, we need to consider various aspects and perspectives to ensure the absolute security of data and materials.
7. System Reliability
System reliability is an important feature of modern information systems. As people rely more and more on systems in their daily work, the system must be reliable. In the system architecture design, system redundancy can be considered to avoid spof as much as possible. System reliability is the probability that the system successfully runs the program according to the design requirements at a given time interval and given environment conditions. The successful operation not only ensures that the system runs correctly and meets the functional requirements, but also requires that the system resume normal operation as soon as possible in case of an unexpected fault, so that data is not damaged.
8. Adjustable business processes
Possible changes to the customer's business processes should be considered. Therefore, we should try to eliminate the constraints of the business processes when designing the system architecture, that is, we should take the work of various business nodes in the process as independent objects, it is designed as an independent module or component, fully considering their interface with other business object modules or components, and implementing various businesses through mutual calls between business object modules between processes. In this way, when the business process has limited changes (the business logic of each business module has not changed ), you can easily modify the call relationships between system program modules or components to meet new requirements. If the call relationship is designed to be stored in the data dictionary of the configuration library, you do not need to modify the program code. You only need to modify the call rules of the modules or components in the data dictionary.
9. Adjustable Business Information
Possible changes to the customer's business information should be considered. Therefore, the impact of business information adjustment on code modules must be minimized during system architecture design.
10. ease of use
Convenience of use is an inevitable requirement, which is closely related to the system architecture. The failure of WinCE (1.0) and the success of later version improvement indicate this problem. WinCE (1.0) has too many levels of windows and menus, while users prefer simple interfaces and quick operations. If a failure occurs, it should be corrected in time, but it is better not to wait until the failure is rectified. This will waste a lot of financial and material resources. Therefore, it is best to take into account all the factors that need to be taken into account in the system architecture phase. Of course, the ease of use must be balanced and balanced with the system security, and the ease of use must also be consistent with the adjustable business processes and the adjustable business information. "To meet users' needs and make it easy for users to use, while making the operation process as simple as possible. This is the foundation of Design ."
11. Consistency of architectural styles
The architectural style of the software system is somewhat similar to the architectural style (such as Chinese style, Gothic style, Greek retro style ). The software architecture style can be divided into data flow architecture style, call return architecture style, independent component architecture style, data-centric architecture style, and virtual machine architecture style, each style can be divided into several sub-styles. The consistency of architectural styles does not require a software system to adopt only one style, just as architectural styles can be integrated with Chinese and Western, software systems can also have heterogeneous Architecture styles (divided into local heterogeneity, hierarchical heterogeneity, and parallel heterogeneity), that is, the integration of multiple styles. However, such a combination should take into account the consistency and coordination in some aspects. Each style has its own time to use and should be selected based on the quality attribute most emphasized by the system.
Iv. Source Code Organization Structure considerations:
1. Development manageability
Facilitates the division of labor (module independence, development load balancing, scheduling optimization, and prevention of the impact of staff flow on Development: A good architecture should also help reduce the pressure and tension of the project team, improve software development efficiency) facilitates configuration management, reasonable size, and moderate complexity;
1) Easy division of labor-module independence and hierarchy
The module independence and hierarchy are designed to ensure the relative independence of project development members. The module connection mode should be vertical rather than horizontal, and the module should be tree structure rather than mesh or cross structure, in this way, the communication and module development constraints between developers can be minimized. At the same time, the module independence is also more conducive to configuration management. Nowadays, more and more software development is happening in different regions, and members of an Development Group may be in different cities or even different countries, therefore, it is necessary to facilitate the division of labor for remote development and the source code structure of configuration management.
2) Easy division of labor-development Load Balancing
Load Balancing is not only required for the developed software systems, but also for the tasks of Members of the development team during the development process. The so-called job load balancing is to allocate jobs according to the characteristics of developers through reasonable job division, and try to make every time in the project team useful. In this case, the human resources at hand of the project team should be fully taken into account in the architecture design, and the development load balancing should be realized based on the customer's needs to improve the overall development efficiency.
3) facilitates the division of labor-optimizes the schedule;
The prerequisite for optimization of the schedule is that the module is independent and the control relationships of the module development are clarified. The work breakdown structure is used to decompose all program coding work to obtain the input, output, required resources, duration, work to be done in the early stage, and work that can be done after completion. Then estimate the time required for each module, analyze the parallel and serial (sequential constraints) of each module, draw a network diagram, find out the key modules that affect the overall progress, and calculate the Key Path, finally, adjust the network diagram to optimize the schedule.
There is a well-known intellectual question called barbecue film strategy: the Johnson family has a barbecue shelf that can bake two slices at the same time, it takes 10 minutes to bake each side of each slice, three slices of meat are to be baked to a hungry family of three. The problem is how to bake three slices of meat in the shortest time. Generally, it takes 20 minutes to finish the first two slices, and then 20 minutes to finish the third part. There is a better way to save 10 minutes.
4) Easy division of labor-preventing the impact of employee turnover on development
People flow is a common risk in the software industry. As one of the effective preventive measures for this risk, we can consider and prevent the impact of employee turnover on development in the architecture design. The main idea is the independence of modules (the pursuit of high cohesion and low coupling). componentization is currently a popular trend.
5) conducive to Configuration Management (Independence and hierarchy)
It is conducive to configuration management and facilitates the division of labor. In addition to logical module components, physical source code hierarchies, directory structures, and deployment of source code files for each module should also facilitate division of labor and configuration management. (Although the configuration management tool has powerful functions, a clear source code segmentation and module segmentation are very advantageous ).
6) rationality and moderate complexity of size
The rationality and moderate complexity of the size can balance the development workload, facilitate the schedule, and reduce unnecessary memory resource waste during running. Code readability and system maintainability are also good. In addition, too many modules are often due to insufficient system decomposition, while too many modules may reduce the independence of modules, resulting in complicated system interfaces.
2. maintainability
It is easy to locate the cause of the fault and the source code location in a timely manner when the system fails, and facilitate local modification and cutting. (the maintainability is different from the manageability of the operation)
3. Scalability: system solution upgrade, expansion, and expansion Performance
After the system is built, there will be a long operation cycle. During this cycle, applications are constantly increasing and application layers are constantly upgrading, therefore, the architecture design and other schemes used fully consider the feasibility and convenience of upgrading, resizing and expansion.
4. Portability
Different clients, application servers, and database management systems: if potential clients may use different operating systems or browsers, the portability of client programs must be considered, or try not to put the business logic on the client; the business logic of data processing in the database management system will have better performance, but if the customer group cannot be sure to use the same database management system, the business logic cannot be in the database management system; To achieve portability, we must pay attention to standardization and openness. Only when international standards are widely adopted and open products are developed can we ensure the full interconnection of various types of systems, this makes the product more competitive in the market and provides the foundation for future system transplantation and upgrade and expansion.
5. Requirement conformity
From the perspective of the source code organization structure, the compliance requirements mainly consider the minimum redundancy of software code and architecture that may change the user requirements (at the same time, the system must be scalable ).
V. Considerations for writing system architecture design documents
The architecture should be started when requirement development is completed about 80%. You do not have to wait until all requirement development is completed. The project manager needs to determine whether the architecture is sufficient to build a software architecture.
Give consistent outlines: System Overview. A system architecture requires a general description to allow developers to create consistent outlines from thousands of details or even dozens of modules or object classes.
The purpose of the architecture should be clear about the concept of the system, and the architecture should be simplified as much as possible. The best architecture documents should be simple, short, clear, and non-messy, and the solution is natural.
The architecture should first define the main subsystems at the upper layer, describe the tasks of each subsystem, and provide a preliminary list of modules or object classes in each subsystem.
The architecture should describe how different subsystems communicate with each other, and a good architecture should minimize the communication relationship between subsystems.
An important feature of a successful architecture is to identify the areas where changes are most likely, to list the most likely changes to the program, and to explain how the rest of the architecture responds.
Reuse analysis and Outsourcing: an effective solution to shorten the software development cycle and reduce costs may not be self-developed software, which can reuse or outsource existing software. The impact on the architecture should be considered.
In addition to system organization issues, the architecture should focus on design decisions that have full impact on the details. In-depth decision-making areas: external software interfaces (compatibility, communication methods, and data transmission structures), user interface (user interface and system hierarchy), database organization and content, non-database information, key algorithms, memory management (Configuration Policy), concurrency, security, portability, network operations, and error handling.
Ensure the traceability of requirements, that is, ensure that each requirement function has a corresponding module to implement.
The architecture cannot be designed only based on static system objectives. dynamic development processes, such as human resources, Progress requirements, and development environment requirements, should also be considered. The architecture must support phased planning, and should be able to provide methods of development and completion in the phase planning. It should not rely on subsystems that cannot run independently. Find out the dependencies of various parts of the system to form a development plan.
Vi. Conclusion
The system architecture design is closely related to different development platforms. Therefore, a general solution cannot be provided here, mainly to illustrate what factors need to be considered. The design strategies for each factor and the factors not mentioned in this article require the software architecture designer to flexibly grasp the specific development practices. There are sometimes contradictions between different factors, and the architecture design should be balanced according to the specific situation.
References
Sei Software Engineering Translation, by Lin basi
Microsoft Project: Survival law by Steve McConnell, translated by Yu mengxue
The second edition of practical software engineering, such as Zheng Renjie, Yin renkun, and Tao yonglei
Software Engineering: Research Methods for practitioners (5th) by Roger S. Pressman
Science and Art of Software Development |
