Shulou(Shulou.com)06/03 Report--

I. opening

In the early stage, we wrote two pieces of content, "HRMS (Human Resource Management system)-from stand-alone applications to SaaS applications-Architecture Analysis (functional, non-functional, critical constraints)-the first part" HRMS (Human Resources Management system)-from stand-alone applications to SaaS applications-Architecture Analysis (functional, non-functional, critical constraints)-the second part ".

The main body of this article will elaborate on the main points of outline architecture design in the process of architecture design to communicate with you, grasp how to strengthen the role of summary architecture design in architecture design, and help us quickly identify the direction of the architecture and the core framework.

Before describing the specific working methods of the summary architecture, please refer to our defined business scenarios:

1. The introduction of HRMS system? (what features are covered? What is the value and function? What about the industry? )

Please read "HRMS (Human Resource Management system)-from stand-alone Application to SaaS Application-system introduction"

2. The analysis of this chapter will focus on the business scenarios represented by four types of enterprises. (distinguish the concerns of enterprises of different sizes, and the scale will determine the design of the system.)

This article will focus on four types of enterprise representatives to explain the needs and applications of HRMS in enterprises of different sizes.

A, small and medium-sized enterprises with less than 100 employees

B, large and medium-sized enterprises with less than 500 employees

C, large collectivized enterprises with more than 1000 employees

D, global type of corporate system (tens of thousands of people)

3. What are the responsibilities and core competencies of the architect when designing the system?

Please read "system Architecture Series-introduction"

I. definition of outline architecture stage 1.1 and outline architecture

The conceptual architecture is the initial idea of the system design, which is to determine the most key design elements and interaction mechanism of the system, and then consider the specific technical application to design the actual architecture. The conceptual architecture stage focuses on the overall situation, does not adhere to details, and does not pay too much attention to the details of the design and implementation.

Characteristics of the outline architecture phase:

Z. satisfies the basic definition of "architecture = component + interaction" (none of the architectures can escape this pattern)

The "responsibility" of high-level components is generally defined and the relationship between high-level components is given.

Z. should not involve interface details

Before we talk about specific outline architecture design practices, please consider the following questions:

Why is the architecture of different systems different?

When should the difference in the general direction of the architecture be established in the design of the Z. architecture? (function, quality, constraint

1.2, industry status 1.2.1, mistakenly equating "summary architecture" with "ideal architecture"

Architectural design is functional requirements-driven, right?

Architectural design is use-case-driven, right?

In fact, the driving force of architectural design: function + quality + constraint

1.2.2. Mistaking "phase" for "view"

Summary architecture phase or conceptual view?

The stage embodies the priority relationship, and the view embodies the juxtaposition relationship.

The outline architecture phase forms stable high-level architecture design results according to major requirements, special requirements and high-risk requirements.

1.3. Main work contents and objectives

Conceptual architecture is an architecture design stage, which must be aimed at major requirements, characteristic requirements, high-risk requirements, and documented high-level architecture design results before refining the architecture design stage.

Major requirements shape the conceptual framework, where major requirements cover the key contents of three types of requirements, such as function, quality, and constraints.

If we only consider the functional requirements to design the conceptual architecture, the conceptual architecture will be reduced to an "idealized architecture". This fragile architecture will soon face the pressure of "major change", and even directly lead to the failure of the project.

Second, what is the method and scientific practice process of the outline architecture stage?

The whole can be divided into three stages:

1. Through the robust graph: the goal of the preliminary design is to find the responsibility, and draw the robust diagram using the principle of "responsibility cooperation chain".

2. High-level segmentation: using mature experience and methodology, combined with the scene to choose the appropriate architecture model to determine the hierarchical relationship of the system.

3. Challenge-driven: consider non-functional requirements to continuously drive the outline architecture design process.

2.1. The goal of preliminary design is to discover responsibilities and draw robust diagrams using the principle of "responsibility collaboration chain".

Three objects of robust graph:

Boundary objects model the interaction between the simulated external environment and the future system. The boundary object is responsible for receiving external input, processing the interpretation of internal content, and expressing or transmitting the corresponding results.

The control object encapsulates the behavior and describes the control behavior of the event flow in the use case.

Entity objects describe the information, which often comes from the domain concept and has a good corresponding relationship with the objects in the domain model.

Preliminary design principle

The goal of the preliminary design is to "discover responsibility" and lay the foundation for high-level segmentation.

Preliminary design is not necessary, but when the system to be designed does not have much direct experience for the architect, preliminary design is strongly recommended

Initial design based on key functions (rather than all functions) and with the help of robust diagrams (rather than sequence diagrams, which are too detailed)

For the differences between these objects, please refer to the basic usage instructions for describing robust diagrams in "HRMS (Human Resource Management system)-from stand-alone applications to SaaS applications-Architecture Analysis (functional, non-functional, critical constraints)-previous article". The following article will directly use without repeating the specific usage.

After looking at the robust graph, we find that the robust graph also has entities, controls and boundary objects, which is so similar to the MVC mode used in web systems, so let's compare the similarities and differences of these two modes:

Through the above comparison, we find that the robust graph can more fully reflect the content involved in the architecture design process, and the separate architecture pattern pays more attention to some of the architecture levels, such as the logical architecture adopts the MVC pattern.

2.2. High-level segmentation (specific operation methods for the formation of conceptual architecture)

1), direct layering

2), first divided into subsystems, and then layered for each subsystem

For high-level segmentation, we can adopt a phased model to carry out landing practice:

1. Direct hierarchical division: directly divide the system into multiple levels, and sort out the relationship between each level.

2. It is divided into two stages: first, it is divided into multiple subsystems, and then the levels of the subsystems are sorted out to clarify the hierarchical relationship of the ungridded subsystems.

For the introduction of hierarchical patterns, here are several types of partitioning patterns and methods:

1. Logical layer: the logical layer, the upper layer uses the concept of the lower layer, and pays no attention to physical division and generality.

2. Physical layer: distributed on different machines

3. Universal layering: the more versatility, the lower the level.

2.2.1, Layer: logic layer

Layer: logical layer, the upper layer uses the concept of the lower layer; does not pay attention to physical partition, nor does it care about generality. Layer is a form of logically organizing code. For example, in the logical layer, the presentation layer, the service layer, the business layer and the domain layer are divided by software functions. It does not refer to being deployed on that specific server or a physical location.

Multi-tier Layer architecture model

Such as our common three-tier architecture model, the three-tier architecture (3-tier architecture) usually divides the whole business application into three layers: interface layer (User Interface layer), business logic layer (Business Logic Layer) and data access layer (Data access layer). The purpose of distinguishing levels is for the idea of "high cohesion and low coupling". Hierarchical structure is the most common and important structure in software architecture design. The hierarchical structure recommended by Microsoft is generally divided into three layers, from bottom to top: data access layer, business logic layer (or domain layer), presentation layer.

The architecture at the logical level can help us to solve the logical coupling and achieve flexible configuration and migration. A good logical hierarchy can lead to:

A, logic organization code / clarity of code logic

B, easy to maintain (maintainability)

C, better code reuse (reusability)

D, better team development experience (development process support)

2.2.2, Tier: physical layer Tier: physical layer, each layer is distributed on different machines. Tier refers to the specific location where the code is run and deployed, which is defined as a physical level, and Tier refers to the specific operation location of the logical layer Layer. So the logical layer can be deployed or migrated to different physical layers, and one physical layer can be deployed to run multiple logical layers.

Tier refers to where the code runs, where multiple Layer can run on the same Tier, and different Layer can run on different Tier, provided, of course, that the application itself supports this architecture. Take the J2EE and .NET platforms as an example, most of the time, calls between different Layer are done directly through DLL or JAR package references (for example, the business logic layer needs to reference the data access layer). In this way, multiple Layer can only be deployed on one server at the same time. On the contrary, if the communication calls between different Layer are realized through RPC, when deploying, different Layer can be deployed on different servers, which is also a common decoupling design.

A good physical architecture can bring:

A. performance improvement

B, scalability

C, fault tolerance

D, security

2.2.3. Universal stratification adopts the universal hierarchical model, and the principle is that the more versatility, the lower the level.

And the call relationship of each layer is from top to bottom, and the lower the call relationship, the higher the versatility.

2.3, query-driven, constantly improve the system architecture (quality attributes and constraints determine the evolution of the architecture)

To shape the high-level framework of the conceptual framework based on the major functions of the system, it is necessary to constantly question the preliminary conceptual framework through non-functional requirements such as quality and constraints, and gradually improve the conceptual framework. Be able to meet and support all kinds of quality and constraint requirements. The specific operation method can be realized by "goal-scenario-decision table" introduced in the previous article "HRMS (Human Resource Management system)-from stand-alone application to SaaS application-architecture analysis (functional, non-functional, critical constraints)-previous article".

The goal-scenario-decision table is used to analyze the non-functional requirements:

Through the analysis of the key quality and constraint content, we give the specific scenarios and coping strategies, sort out a clear decision table, integrate the scheme given in the decision table in the conceptual architecture stage, and finally give the preliminary conceptual architecture design.

Third, based on the HRMS system analyzed above? How do we start?

Combined with the key points of the needs carding mentioned above, we combine the HRMS system to carry on the application practice, and gradually form the outline architecture design.

A. Draw the robust graph and determine the boundary and key content of the system based on RelationRose.

1) analyze the participants in the system and the functional boundaries of the application:

Based on the above, we can find our core function points:

Organizational management: mainly realize the management of the company's organizational structure and its changes; manage the position information and the working relationship between positions, and staff according to the vacancy of the position; plan the manpower according to the organizational structure, calculate and manage the personnel cost, and support the generation of organization table, organization chart, etc.

Personnel files: mainly realize the management of all kinds of information and the change management of personnel information in the whole process from probation, probation to dismissal or retirement, and provide various forms and angles of inquiry and statistical analysis means.

Labor contract: provide the management of signing, changing, rescinding, renewing, labor dispute and economic compensation of employee labor contract. Automatic prompts for probationary period and contract expiration can be set as needed.

Recruitment management: realize the whole process management from planning recruitment positions, issuing recruitment information, collecting candidates' resumes, selecting personnel according to post qualifications, managing interview results and notifying trial.

Salary and benefits: salary management system is suitable for all kinds of enterprises, administrative, institutions and scientific research institutions, directly integrate attendance, performance assessment and other data, mainly provide wage accounting, payroll, funds calculation, statistical analysis and other functions. Support multiple or step-by-step payment of wages; support withholding tax or withholding tax; payroll support bank distribution, provide data output function, but also support cash distribution, provide sub-money list function. The content and ratio of funds provision can be set; the welfare management system provides the extraction and management functions of employees' welfare funds. It mainly includes defining the type of fund, setting the conditions for fund withdrawal, carrying out the daily management of the fund, and providing corresponding statistical analysis. The daily management of the fund includes regular withdrawal of the fund, supplementary payment of the fund, transfer and transfer, and so on. In addition, it provides the function of submitting relevant reports to the relevant regulatory authorities.

Administrative management: mainly provide the management of employee attendance to help enterprises improve the operating system. It mainly includes the setting of various holidays, classes, related attendance items, as well as shift transfer, overtime, public release, leave management, late and early departure statistics, attendance statistics and so on. Provide the interface with all kinds of attendance machine systems, and provide relevant data for the salary management system. Support notice distribution, support conference rooms / vehicles and other resources to book and synchronize calendars, support research and voting questionnaires, support event management registration / check-in / statistics, support personnel reward and punishment management and related to personnel files, support activity lottery management, etc.

Training management: according to the post setting and performance evaluation results, determine the necessary training needs; formulate a training plan for employees' career development; manage the training objectives, course contents, teachers, time, place, equipment, budget, etc., and manage the training personnel, training results and training expenses.

Performance management: through performance appraisal, we can evaluate the effectiveness of staffing and training, reward and punish employees, and provide a basis for personnel decision-making. According to the requirements of knowledge, skills, ability and performance of different positions, the system provides a variety of assessment methods and standards, allows free setting of assessment items, and makes qualitative and quantitative evaluation of employees' characteristics, behavior, work results, etc.

Configuration management: in order to enhance the compatibility and flexibility of the system, many system switches and configurations are added to provide support for subsequent scenarios. It needs the functions of dynamic classification, dynamic addition and modification of configuration items.

Rights management: general rights management system, supporting organizations, employees, roles, menus, buttons, data, etc., covering functions and comprehensive data rights management functions.

Process management: provide workflow engine services, support custom forms and processes, and fully support the approval flow in the HRMS system.

Human resources planning and analysis: provide a full range of statistical analysis functions to meet the enterprise human resources management and planning, and provide data basis for follow-up business decisions.

2), system boundary

Based on the above core function points, we can sort out the boundaries of the system, including the following aspects:

I, administrator's system boundary

Since the role of the administrator has been defined, he needs to have a special operation and maintenance management background. The function provided by this background is completely different from the background function and interface of the business operator, so a separate entrance is required. The functional modules are also different. So we can get the access mode and boundary of the administrator when using the system.

System boundaries of ii and HR

The role of HR undertakes the relevant responsibilities of business management, such as the approval link in the HR module, they have both business-initiated operations and approval operations, so relatively speaking, the boundary of use of the HR role will be more extensive than that of employees. We find that when using HR, we need to have a separate system entry and assign them corresponding business modules and functions.

Iii, system boundaries of employees

For employees, there are only some modules in the HRMS system that can be operated and used, such as attendance, reimbursement, performance, viewing and maintenance of personal information, etc., other information is filled in by HR and users can view it, so from the point of view of convenient operation, employees and HR can be the same entrance to the business system, and access boundaries can be restricted through permissions.

Iv, the boundary of company managers

Compared with the employees, the managers of the company have the corresponding business and data management authority, and at the same time, they will assume the identity of the examiner in the examination and approval flow, and many business processes are related to the managers, so compared with the employees, the managers of the company have larger business and operation authority, and more business content of superior and subordinate management. at the same time, they can also complete the related business of employee role operation.

3), data object

I, basic data: the system contains metadata, service management, logs, modules, basic configuration, data dictionary, system management and other basic data management

Ii, business data: covers institutions, employees, HRMS system business and process data, external third-party business linkage data, etc.

Iii, other data: cover other types of data, such as files, pictures, videos, etc.; the result data after statistical analysis; data that interact with or retain with third-party systems, and other related content. Other data information, such as log logs.

B. Division of high-level subsystems

Based on the core requirements of the above robust graph analysis, we give a macro architectural outline of the system, where only user roles and responsibility chains are considered to form the above high-level segmentation.

C. The basic principles of quality requirements affecting the architecture: further questioning

Combined with the key qualities and constraints we have combed previously, please refer to "HRMS (Human Resource Management system)-from stand-alone applications to SaaS applications-Architecture Analysis (functional, non-functional, critical constraints)-the second part". Because of the space, I will not list in detail. Based on these quality attributes and constraints, we will further improve the summary architecture:

1) considering the continuous availability and scalability in the key quality attributes, the intermediate results of the summary architecture are obtained:

2) further optimize the intermediate results of the profile architecture by considering the interoperability in the key quality attributes:

3) to consider high performance, in addition to high load, you also need to consider static, caching and other improvements in system performance:

The above basically formed an embryonic form of a summary architecture, but this is not enough, we still have a key content that we have not analyzed, that is, system constraints, we need to analyze and disassemble the previously identified key constraints into functional or quality requirements:

D. the basic principle of analyzing the influence of constraints on architecture: direct restriction and transformation into functional or quality requirements

Analyze the contents of the above table, and verify it with the summary architecture given after several rounds of analysis to see if these constraints will affect the content of the architecture, and then optimize and adjust:

I, business environment and constraints: at present, the above profile architecture can be supported and will not affect the current profile architecture.

Ii, using environmental constraints: the above scenarios have been taken into account in the previously proposed access model for PC and App, which can be considered in the detailed design of the application layer for multiple languages.

Iii, development environment constraints: the outline architecture does not involve the details, and the current constraints will not have a significant impact on the architecture

Iv, technical environment constraints: no impact, belong to the level of detail

E, based on the above, we get a preliminary outline architecture, which basically meets the various requirements and scenarios of functions, quality and constraints, and obtains the following outline architecture design diagram.

IV. Summary of the main points of the outline architecture stage

Based on the previous practice of the summary architecture design deduction process, we summarize the three core points of the summary architecture process as follows:

1. First of all, we need to analyze and find the key functions, quality and constraints in the HRMS system.

2. Secondly, the robust graph is used to find the users, key functions and responsibility chains of the system, to form a preliminary split of the subsystem, and to form a hierarchical structure with the help of high-level segmentation, constantly through questioning + solution mode. to meet and improve the requirements of quality and constraints.

3. Finally, through the practice process of 1 and 2 steps, the preliminary outline architecture is deduced, which provides the basis for the next step to refine the architecture.

I hope you can provide some help in the process of system architecture design practice through the demonstration of the above examples.

5. More information

For more knowledge about the system architecture, I have set up a communication group, and the relevant information will be shared in the group as soon as possible. You are welcome to join the group and learn from each other:

WeChat group: (scanning code to join the group-limited quota)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.