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

Software architecture should be layered, sub-module, in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find an easier way.

I. Preface

In this article, let's continue to talk about what we should do in the outline design and detailed design stage. What tools or means do you use to do it? What is the output?

According to convention, for the convenience of content description, I will use the design process of an Internet of things gateway to string all the content together.

1. Use case diagram

As mentioned in the previous article, use case diagrams are a very useful tool for requirements research and requirements analysis. Through the use case diagram, we can present all the functions that need to be completed in a system at a glance from the coarse granularity.

The following diagram is a use case diagram of the gateway (the use case drawn here is not complete):

two。 Use case description

The use case diagram only describes the functions of the system, but does not describe the behavior of each use case, that is, the execution process.

As mentioned in the previous article, we don't need to analyze every use case, but we need to identify the key use cases in these use cases, and then write a use case description for these key use cases, because the key use cases are the determinants of the system architecture.

So another question arises: if all use cases are prioritized in terms of importance, how many, or percent, key use cases should be selected from top to bottom? It depends on the complexity of the whole system, 30% is not too little, 50% is not too much, according to your time.

In terms of the use case diagram in the gateway above, I think: adding devices, deleting devices, controlling devices, rule configuration, rule triggering these use cases are more critical, so I write a use case description for these use cases.

(1) add device use case description

There are two points to pay attention to:

In the event flow, we describe the gateway as a black box, because we are doing requirements analysis, not designing, so we do not need to consider the internal execution process of the gateway.

The red part is an executive body, which can be a person, an interface, a device, a system, and so on.

The event flow can be described in words (as shown in the figure), or you can draw a sequence diagram to show the process, as follows (no more detailed execution process is described here, mainly schematic):

(2) delete the device use case description

(3) use case description of control equipment

(4) use case description of rule configuration

(5) description of rule trigger use case

III. Outline design

The summary design can be understood as a rough, abstract architectural diagram that reflects high-level components and the relationships between them. So what should be done to get such an architecture diagram?

What we have now is the use case diagram and the use case description, and the system to be designed is described as a black box in the basic event flow of the use case description.

What we need to do now is to open the black box, enter into it, and analyze the execution process: which modules are required to complete what actions.

Attention, this is our goal. To do this, use the robust graph tool.

In other words, we now need to use the robust graph tool to disassemble the event flow in the use case description, find out all the participating elements within the system and needed to complete the use case, and mark the relationship between them.

1. Draw a robust diagram for the use case description of each key use case

First of all, let's talk about the concept that is easy to be confused: robustness, also known as robustness, means that the program can be executed smoothly even if there are some errors. It describes the fault tolerance of the program.

Robust graph refers to whether the description of a use case is correct and perfect by means of graphical modeling.

Mainly through three kinds of elements: boundary object, control object and entity object, to draw a use case description, the interaction between the functional modules of the system to be designed.

Boundary object: an element that needs to interact with the outside world within the system. It is responsible for receiving external input and outputting internal processing results to the outside.

Control object: describes the dynamic control behavior, emphasizing the transition from one execution link to another.

Entity object: describes the content of a message, such as a device description information in a gateway, a rule configuration information, etc.

With regard to boundary objects, it may be easier to understand in Web projects, which is the interface that interacts with users and external systems. But in embedded systems, there is no interface in most cases, but we just need to grasp one fundamental thing: receiving external input and outputting data to the outside.

Here we simply draw a picture of adding devices, control devices, and rule triggers, and these three use cases describe the corresponding robust graphs (ignore the colors in these images first):

Add a device:

Control equipment:

Rule trigger:

In the process of adding rules, most of the work is done on the mobile phone APP (select source device-trigger condition-target device). The gateway only stores the configured rule, and there are no other too many operations.

The more important part of the rule is the processing of rule trigger. for example, when the infrared device (source device) detects the human body, if it is currently in the state of defense (trigger condition), activate an acousto-optic alarm (target device). Therefore, the following figure describes the execution process of a rule, which has a long chain of execution and can connect many modules together.

two。 The modules in the robust graph are classified and the subsystems are summarized.

Assuming that we have now drawn the robust diagrams of all the key use cases, the next step is to classify these modules. In the above pictures, some modules are marked with different colors, and the same color indicates that they belong to the same category.

The modules in the yellow part are related to wireless communication, so these modules can be classified as wireless communication management subsystem.

The green modules are all device-related, so they are classified as device management subsystems.

The modules in the blue part are related to rules, so they are classified as rule management subsystems.

Continue to find other subsystems.

Finally, we draw these subsystems (or functional groups) into a diagram as follows:

From the perspective of upper-level components, this diagram divides the whole system into several subsystems, each of which is an independent and deliverable entity module.

This diagram is still very useful, it can be used to report to the leader (the leader does not have time to read the detailed design), it can also be used in the technical architecture description section of the product specification, and it can also be used for the division of labor among team members. because each part is an independent unit, coupled with other subsystems. It is isolated from both static and dynamic aspects (explained later in the development architecture design).

Communication is needed between these subsystems, so after drawing this design diagram, we need to make the following decisions:

Technology stack used: development language C, communication mode between processes: message bus

Concurrency: each subsystem runs in the system with the process as the execution unit, and implements the mosquitto library through the C language of the MQTT message bus to access the bus system.

The system does not support secondary development.

IV. Detailed design

In the above outline design diagram, all functional modules have been divided into different subsystems, which can also be called functional groups. The next step is to find out the internal objects, functions and interaction processes in each functional group. specifically, it is to analyze the logical architecture, operating architecture and development architecture of the system.

1. Logical architecture

Logical architecture is to subdivide each subsystem into finer-grained functional blocks, which can also be disassembled to the class level if you want to have a finer granularity. In addition, the interactive interface between the modules needs to be defined.

According to the above description, we have decided to design each subsystem as an independent process, and each process exchanges data through the message bus, and this message bus is based on the topic topic for message routing. Therefore, we need to design which data interactions each process needs to handle:

Entry: respond to requests from which other modules

Export: which other modules do you need to rely on to provide services in order to complete your work?

In a word, it is to find out which other modules you need to interact with in order to complete your work. What is the interface (function, method, or protocol) that interacts?

So how do you find these objects and interfaces? Use sequence diagrams or class diagrams to do this. Here is a simple sequence diagram of the control device:

Each arrow in the figure represents an interface and, for this gateway, a topic topic being processed.

If you use class diagram to analyze, for object-oriented development language, it may be easier to understand, such as: can clearly define the properties of each object, private functions, common functions, and can clearly build the relationship between objects.

two。 Operational architecture

The running architecture describes the dynamic state of each execution unit and the control flow during execution. The key point to consider is: is the system secure? Does the performance meet the quality requirements? What is the scalability?

As far as gateways are concerned, each subsystem is executed in a process, and each process is connected to the message bus through a third-party attachment (that is, a dynamic library), as shown in the following figure:

The concurrency of the system is realized by multiple processes, and the security of the system is mainly managed by the security mechanism of the message bus.

For example, in the development phase, the message bus allows other clients outside the system to access, so that you can write a debug program on the PC computer, access to the bus, and listen to all the data. At this time, the data can be unencrypted, all of which are human readable. But in the release phase of the project, then turn off this permission, the client on the PC machine can not access the bus, and all the data in the bus need to be encrypted and compressed to further improve the security of the system.

3. Development architecture

As the main force of the development code, the development architecture is easy to understand, which is nothing more than defining the project structure, compilation process, testing steps, and so on.

Specifically, we can make regulations from the following aspects:

Parallel development: each subsystem is an independent process, so it can be divided into a separate project to improve development efficiency.

Third-party library: used as the basic common module (SSL encryption, message bus access, communication protocol parsing)

Code security: each developer can only have access to the code he or she is responsible for, and only the administrator has access to all the code

Code control: use git, svn and other tools to manage code versions

Integrated compilation: use Jenkins + git module function, automatically pull all the subsystem code, automatic compilation. If automatic deployment is required, you can also use scripts to do so.

Fifth, architecture verification

Finally to the last link, in fact, the project has experienced a lot, whether the above designed architecture can meet the functional and quality requirements put forward in the requirements, we already know the answer in mind.

To be on the safe side, we still need to verify some of these key parts. This verification process is valuable, or the results of this verification process can be submitted as formal code.

The general direction of verification has two points: whether the framework of the system is reasonable and stable, and whether some technical bottlenecks can be solved. If these two parts are all right, then you can move forward boldly.

This is the answer to the question about how the software architecture should be layered and divided into modules. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.