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

This article focuses on "what is the design method of the architecture". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the design method of architecture"?

Concept analysis

There are a few concepts that need to be understood before the article begins:

What is methodology?

We take an input and expect an output based on that input, and describing the process in the middle is the methodology. So the architect methodology we are talking about in this article is that the architect first gets the input from the requirements analysis, and then completes the architecture design, and this process is the architecture design methodology.

What is design?

Design is a written expression of intention, not a verbal one.

The purpose of design is to enable the implementer to understand the designer's intention and to show it to others rather than to himself.

The design is to make the things made by different implementers similar.

The design is serious, and the subsequent implementers should not deviate from the design at will.

What is a system architect

As a system architect, you need to jump out of the design at the code level and grasp it from a broader perspective.

You focus on the whole system rather than one or two query modules, and you see more elements: people, hardware, software, and the network.

Overview of business analysis

Business analysis is the research process of the business area to be solved by the system before the system development, in order to understand the concept of the business area and the operation process of the business.

The purpose of developing a system is generally to optimize business processes and make business run more efficiently and economically.

The value of the system mainly lies in how much business value it can bring to customers after implementation.

Business is usually the same with or without a system

Activity model of business analysis phase

In the business analysis phase, the business analysts output the results of the business analysis phase based on their own business knowledge and the reference of similar products, combined with the consultation and guidance of customers and domain experts, including domain models and business models.

Domain model

A domain model is a visual representation of conceptual classes in a domain or objects in the real world. Also known as conceptual model, domain object model, analytical object model. It focuses on analyzing the problem domain itself, discovering important business domain concepts, and establishing the relationship between business domain concepts. The concept is more esoteric, in fact, to put it bluntly, we draw a class diagram based on the understanding of the business, and draw the relationship between these classes (object-oriented). Let's look at an actual domain model and deepen our understanding.

The following two typical errors often occur when drawing a domain model:

Put the system to be developed into the domain model.

Whether the system to be developed will appear in the domain model depends on whether your business can play without the system to be developed. For example: if you are developing an information system for sharing bikes, sharing bikes will not work without the information system, so the information system needs to appear in the domain model.

The concept is not clearly defined, and the relationship is not drawn in place.

For example, attributes are drawn as classes, and inheritance relationships are mistaken.

The role of domain model

The domain model can sort out the concepts and relationships in the business and help the members of the team to have a consistent understanding of the business; in the future, they can guide database design, system function design, and development.

Now there is a development mode based on UI to guide the development, according to UI database design, code writing, we call it "quick success and instant benefit" development mode. Because UI is a superficial thing of the system, it is changeable and unstable, so our design may need to change after the change of UI in this mode.

On the right, based on domain-driven development, think about the nature of the business before development, first analyze the domain layer, and then carry out interface design, architecture design, and code development according to the analyzed domain layer, which is designed from the inside out. The system will be more stable.

Business model

The domain model mentioned earlier is based on static relationship, so to understand the business actually needs to understand the process of business operation from a dynamic point of view, so it is necessary to do business model at this time. Understanding the business model requires understanding the following concepts:

Business object

The main business subjects are business executors, business workers and business entities.

To understand these three objects, we first need to know what business is, which means that an organization can provide services to people outside the organization.

Business Actor: people outside the organization who come to enjoy this service are called business executors.

Business worker (Business worker): internal support staff of the organization that provides the business

Business entity (Business Entity): the internal information system of the organization that provides business

It's a bit of a mouthful to understand these concepts. Let's take a look at the following picture, a business modeling of a restaurant object.

The big black box on the right is the organization that provides the business, which is the restaurant; on the left side of the picture is a business executor and a customer; and inside the restaurant, it is divided into business workers (ushers, ordering staff, cooks, etc.) and business entities (restaurant ordering management system).

When we do business modeling, we need to note that all business objects need to have a slash at the lower right of the circle, which is a modeling specification.

Business use case

Concept: the business services provided by the organization

A bank is an organization that provides business, which is the business use case, and the object is the organization of the bank, not the system.

Business proc

Business use case is the most basic definition, and to analyze the process of business dynamics requires business processes, which are generally represented by sequence diagrams.

The current business process of the restaurant, at this time, all the action steps rely on people to participate.

Business process after building the system

With the system, the system can undertake part of the work, with the system can improve business processes, increase value, reduce costs, this is the value and significance of building the system, otherwise there is no need to do system construction.

The role of business process analysis

Dynamically express the process of business operation

Only with a good understanding of the business process can a better system be designed to support the business.

By comparing the process changes before and after the implementation of the system, the optimization point is analyzed and the value of the system is evaluated.

Summary

Before preparing to build a system, you need to analyze the business and understand the business clearly. Understanding the business includes both static understanding (domain model) and dynamic understanding (business process). Only by understanding the business clearly can we make a good system.

Demand analysis

Requirement analysis is a part of demand engineering, and the whole requirement engineering is divided into two parts.

The early stage is mainly to do demand development, including demand research, demand analysis, demand definition; the later need to do demand management, including demand confirmation, requirements tracking, requirements change control.

Our architects mainly focus on requirements analysis and requirements definition.

Activity model in the stage of demand analysis

In the requirements analysis stage, the system analyst outputs the results of the requirements analysis phase based on the domain model and business model output by the business analyst, including the system context, functional requirements (use case model) and non-functional requirements (performance, etc.).

System context

System context refers to the relationship between the system and surrounding users and other systems.

The drawing of the system context is very simple, that is, the system to be developed is drawn in the middle, and the user and the docking peripheral system are drawn. this is called the system context.

System use case

The system use case refers to the case in which the system is used, mainly derived from the business process. The naming specification of the system use case is mainly to use verb phrases, such as: add users, query phone charges and other phrases.

We can refine the use case of the system, as above, to refine the use case of registration information.

The difference and relationship between system use case and Business use case

The business use case describes the capabilities provided by the organization, while the system use case describes the capabilities provided by the system, and the two examine different objects.

The system use case is an operation to the system in the corresponding process of the business use case.

The difference and relationship between function and use case

The use case is the product of requirements analysis, which describes what kind of business a user uses the system to accomplish.

The function is the product of the design phase and is derived from the system use cases and components in the architecture.

Functions are static and use cases are dynamic

From a grammatical point of view, the use case is a verb phrase and the function is a noun phrase: use case naming (query vacancy), function naming (vacancy query)

Common mistake: come up with a list of features when describing requirements

Non-functional requirements

The main purpose is to determine some non-functional requirements, such as availability, performance, security, economy, scalability, scalability, portability and other availability, performance, security and so on. We'll talk about it later.

Architectural Design (focus)

The previous business analysis and requirements analysis are generally done by other people, so the content of this area is the work of the architect and needs to be paid more attention to.

When the system is simple, we need to decompose and split the system from a functional point of view. At this time, we only need to do the general design and detailed design.

In the complex system, we need to decompose and split the system from the component point of view, at this time we need to do architecture design and outline design.

Components, functions, modules

The component is the unit (process level) considered in the architecture design stage, and the function and module are the units considered in summary design and detailed design; a component can contain multiple modules, involving multiple functions; the implementation of a function may require the corresponding modules of multiple components to cooperate.

We use a picture to understand the relationship between the three of them

A project separated from the front and rear ends is divided into three components from the process point of view, namely, the web front end, the back end interface service and the background service. In order to realize the function of user query, there must be corresponding modules in the corresponding components.

There can be many different modules in a component, and the modules in each component cooperate with each other to complete a function.

Architecture

If architecture is described in one sentence, it should be defined as follows: architecture is the internal structure of the system (components and the relationship between them) and includes the technical elements of the system. In fact, architectural design is to do these two things.

Architectural design has two goals:

Meet functional requirements

Meet non-functional requirements

Activity model in architecture design phase

In the architecture design phase, the system architect refers to the product of requirements analysis (SRS), and then outputs the results of the architecture design phase through consultation with system analysts and project managers, including architecture work plan, logical architecture, physical architecture, development component list, deployment component list, technology selection list.

So how to measure the design of an architecture?

When the design is completed, we can verify it through the standardization of the design data and the rationality of the design idea, scheme decision and technical selection.

After the implementation of the system, it can be verified by the degree of satisfaction of functional and non-functional requirements.

Logical architecture design (non-technical)

The system is decomposed into several logical components from a non-technical point of view, and the relationship between them is established to meet the system requirements. The relationship is divided into static and dynamic, in which the static relationship is represented by the component diagram and the dynamic relationship is represented by the sequence diagram.

In a logical architecture, component names are in their mother tongue for understanding

The logical architecture does not involve technical elements, but is purely conceptual.

The readers of logical architecture can be non-technical personnel.

After the logical architecture design is completed, it should be confirmed with the system analyst, product manager and other personnel to check whether the requirements are met.

Let's look at a typical logical architecture.

Physical architecture design (technical)

Convert components in a logical architecture into technical physical components with English names that should be followed when implemented

The granularity of physical components varies from large to small, and can be expressed in many forms, such as subsystems, processes, objects, etc.

The physical architecture also needs to address non-functional requirements

The physical architecture also needs to be connected with the subsequent design and implementation.

It may be difficult for non-technical personnel to understand

Let's look at a typical physical architecture.

Summary

The architecture design is the overall design of the system, which determines the component division of the system, the decision-making of the key technical scheme, and the connecting requirements of the technology selection architecture design, followed by further design and implementation. it is the key stage to determine the quality, efficiency and cost of system implementation.

Summary design and detailed design outline design

The main content of the outline design phase is to divide the function module and define the interface (interface name, function summary, parameter, return value).

Summary design phase activity model

In the summary design phase, the development team leader outputs the summary design phase results based on the system use case, the development component list and the consultation to the architect and system analyst, including the function list and the interface specification.

Detailed design

The main content of the detailed design phase is to describe the internal module implementation, interface design and database design.

Detailed design phase activity model

The detailed design stage may be divided according to the work content, mainly combined with the previous output to output the results of the detailed design phase, including interface design, module internal design, database design.

Activity model of development phase in follow-up engineering phase

In the development phase, developers write the corresponding code by combining the products of architecture design and the products of detailed design.

Test phase activity model

In the testing phase, testers combine the products of architecture design and detailed design to carry out functional testing, including functional requirements and non-functional requirements, and need to output test plans, test cases and test reports.

Deployment phase activity model

The deployment phase is mainly carried out by the deployer with the product of architecture design and consultation with the developer, and this stage requires the output of deployment plan, deployment plan, deployment manual, deployment script, deployment implementation, and so on.

Activity model in operation and maintenance phase

In the operation and maintenance phase, the system operation and maintenance is mainly carried out by the operation and maintenance personnel combined with the products of architecture design, which requires the output of operation and maintenance plan, operation and maintenance plan, operation and maintenance manual, operation and maintenance script, operation and maintenance report, etc.

At this point, I believe you have a deeper understanding of "what is the design method of the architecture?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.