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

This article introduces the relevant knowledge of "how the software architecture is layered and divided into modules". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

I. the life cycle of software architecture design

1. Software development process

two。 About routines

3. First ossified, then optimized, then solidified

4. The Buddha said, "knowing what I say is like a raft metaphor."

Second, demand research and demand analysis

1. Functional requirements

two。 Quality attribute

3. Conditional constraint

4. Draw a use case diagram

5. Write a use case description

6. Identify key requirements

I. the life cycle of software architecture design

What is architecture? If you ask ten people, you may get eleven different answers; if you look at the relevant books, each may give a different definition.

Therefore, we do not need to dwell on those concepts, as long as the method is right, can complete the project task, no matter the black cat or white cat, can catch the mouse is a good cat!

1. Software development process

A software project has experienced many links from the beginning of the project to the final delivery. Specific to the life cycle of software design, it can include these stages: requirements research-requirements analysis-outline design-detailed design-architecture verification-development-unit testing-integration testing.

The above steps are still a very rough concept. In practice, each step can be subdivided into many specific implementation links.

For example:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Demand research: what should be done? In what way? What is the guiding ideology? Do you have any good tools?

Requirements analysis: how should it be analyzed? Should all requirements be analyzed? How to identify key requirements?

Detailed design: what is the better practical method in software engineering? How to layer? How to divide it into modules?

These are all the problems that need to be involved in the process of software design. So what is the ultimate goal of software design? These are the following documents:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Logical architecture

Physical architecture

Operational architecture

Development architecture

two。 About routines

In my opinion, in this world, there are routines for everything, including anything, any field, any industry.

When we enter a new field, for example: let you design a vehicle scheduling system, robot control system, or design a walkie-talkie, an Internet of things gateway, if you are a newcomer in this field, then it must be blackened: I don't know anything about this field, how to design it?

This reminds me of a short story:

Once I just joined a new company and took over the job of a former colleague. At that time, the implementation of KPI assessment, bug pass-through rate (that is, the proportion of getting rid of bug at once, QA staff will no longer kick bug to you), is an important indicator. In the face of so many bug in the system, the leader asked me: how long will it take you to solve these problems? I said: I have not been exposed to this kind of work before, so it is impossible to give an accurate time. The leader said: it doesn't matter, just give me a specific time first. I was confused at that time.

At this time, the most important thing is to quickly understand and master the basic and important background knowledge in this field. So what should be done? Find tricks!

Do not be greedy for perfection, do not expect to master all the relevant content, this is impossible, especially in a short period of time. Our goal is to do a good job and finish the project.

At this time, my general practice is to find tricks!

This may be a bit illusory, so take the architectural design in software development as an example. Look for the following in the books and materials of software engineering or project management:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

How do others design the architecture?

What steps are required in the design process?

What is the input in each step? What is the output?

What are the points to consider in each step?

What good software tools are there?

How to communicate with project stakeholders (project managers, developers, testers, Party A customers)?

Sort out the above experiences of others, sum up a set of "methodology" suitable for you, and then follow this routine step by step in the specific implementation, and make timely dynamic adjustments according to the actual situation. Generally speaking, a project can be promoted smoothly.

3. First ossified, then optimized, then solidified

These nine words were put forward by Ren Zhengfei, the head of Huawei, when he introduced the management system, which is a very practical method.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Fossilization: standing on the shoulders of giants: "cutting feet to fit shoes" in the early stages of learning

Optimization: master the weapon of self-criticism: constantly absorb, improve, innovate and optimize yourself in practice.

Solidification: innovation is phased and constrained. If there is no constraint, innovation is disorganized and disorderly, which needs to be rammed up layer by layer like rammed earth, and solidify the optimization results step by step.

For software architecture design, we can also follow these steps.

The first step is to be rigid, that is, to follow a fixed routine, although it may "fall into a stereotype", it can at least ensure that it will not go crooked on the right path, which is the most important thing!

What does it mean if it is regarded by others as "falling into a stereotype"? It means that others already think that what you are doing is in line with the most "general" process in this field, which is tantamount to recognizing that you have really entered the field, which is a good thing!

As a beginner, shouldn't you be proud to be judged in this way? After all, we know in our hearts that I am just a rookie who has just entered this field.

4. The Buddha said, "knowing what I say is like a raft metaphor."

My main purpose of writing this article is to talk about how I am "ossified" to design software architecture.

When we first entered the software development industry, our daily work was mainly to review the code, perhaps not qualified to design the architecture of the whole system. However, this does not prevent us from taking the initiative to learn, and the opportunities are reserved for those who are prepared. If one day, this hole of architectural design appears in the project team, which radish will the leader find to fill the hole?

Therefore, this article mainly introduces the most basic and basic software design steps, as well as the guiding ideology used in each step, handy tools, and so on.

If you are already a senior software design engineer, then you can drink coffee, enjoy life, of course, you can also share your methodology, we learn from each other!

These contents are not fumbled out by myself, but from flipping through books, searching materials and summing up in the process of project development, which is more suitable for the project I face, and I am just a porter of knowledge.

Before, I mainly referred to several books on software architecture design, learned from each other, and summed up a set of methods suitable for me. Last time I moved, I lost a lot of books, leaving only bits and pieces of notes in the computer. The material source of this article is these notes, of course, most of the content is from books, I just made some choices and cuts.

In the sixth article of the Diamond Sutra, the Tathagata often says, "you, bhikkhu, know me as a metaphor; the Dharma should be given up, let alone illegal."

The Dharma is like a raft for people to cross the river. when you cross the river, you should throw the raft away and stop thinking about it. A raft is like the Dharma, and the Dharma should be discarded, not to mention that it is not part of the Dharma, why do you bother with him?

So, the design routines I'm talking about here are also similar to rafts, which are used to help you get into a scaffolding when you first enter software architecture design. When you enter the second Rank "Optimization", you can throw away the scaffolding.

At that time, you can confidently say: "Brother Dao is writing about what ah, pediatrics things, I need to explore a more advanced Rank." At this time, I would like to sincerely congratulate you!

Second, demand research and demand analysis

Most people agree that "requirements determine the architecture", but how do requirements determine the architecture? Let's talk about my knowledge in this part.

In the project establishment stage, if you are lucky, you may get a document "Software functional requirements Specification" (in other words, some Japanese companies' requirements specifications are really perverted details). If you are unlucky, there are no documents at all, and all the requirements need to be collected and sorted out by yourself.

In a narrow sense, requirement is function; in a broad sense, it also includes non-functional requirements such as quality attributes and conditional constraints.

1. Functional requirements

The functional requirements part is the most intuitive, that is, what needs to be done in the software we design. In a system, it is impossible to have a clear boundary between various functions, and each small module forms a "cooperation chain" to complete the specified function through a certain interaction.

For example, the following figure is an article I wrote before: Internet of things Gateway Development: design process based on MQTT message bus (above), the interaction model between different modules, the red and blue parts are two different collaboration chains.

Of course, this picture is the final design of the system architecture (hierarchical, sub-module). Before we get this picture, we first have to collect and organize all the functional requirements.

At this stage, the most important thing is what to do, not how. In addition, as a designer, you need to often ask yourself a question: do you have all the requirements? Are there any omissions?

two。 Quality attribute

We can classify the quality requirements according to different stages:

Development stage

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Reusability, do not do repetitive work

Flexible and easy to scale (think about the developer's mental activity when requirements change occurs)

Easy to understand (think about when you take over someone else's project)

Convenient testing (unit testing, integration testing)

Portable (especially embedded projects, which need to run on different platforms)

Operation stage

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The system must be reliable.

Performance must meet certain requirements (throughput, response time, etc.)

No vulnerabilities, system security.

Good scalability to facilitate scale-up deployment

3. Conditional constraint

Constraints mainly refer to some restrictions, such as:

The technical stack of the team (if everyone uses C, you don't choose C++)

What are the resources given by the leader?

If you use some open source software, is there a bug? Is it convenient for secondary development?

How long is the project development cycle?

What are the operating platforms of the software? What are the restrictions?

4. Draw a use case diagram

With regard to the concept of use case diagram, I am not good at summarizing it, so I will directly quote the definition in Baidu Zhi:

A use case diagram is a view that describes system functions made up of actors (Actor), use cases (Use Case), boundaries, and the relationship between them.

A use case diagram (User Case) is a model diagram of system functions that can be observed by external users (called participants). The use case diagram is the blueprint of the system. The use case diagram shows some actors, some use cases, and the relationships between them, which are mainly used to model the functional behavior of a system, subsystem, or class.

There are several concepts:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Participant: does not refer specifically to the person, but refers to the role played by people outside the system in using or interacting with the system.

Use case: a description of a sequence of actions, including variables, that the system performs and produces observable results that convey the value of a particular participant.

System boundary: is used to represent the boundary of the system being modeled. The boundary represents the components of the system, and the outside of the boundary represents the outside of the system.

Arrow: an association used to indicate the interaction between a participant and a system by sending signals or messages to each other.

Role: (1) to obtain requirements; (2) to guide testing; and (3) to guide other workflows throughout the process.

I found several use case diagrams from the Internet, each of which represents a function.

Through the use case diagram, you can see all the functions provided by the system at a glance.

5. Write a use case description

But the use case diagram does not describe the execution process of each use case in detail, that is to say, the use case diagram describes the requirements of the system as a whole, but does not describe the behavior process.

Therefore, we can attach a simple or detailed use case description to each use case, thus confirming the behavior process of the use case in more detail.

The following are also two examples of use case descriptions found on the network. You can see that there is no uniform format and needs to be added or subtracted according to the nature of the project.

6. Identify key requirements

Suppose we list all the requirements (functional requirements, quality attributes, constraints) as much as possible in our continuous collection and analysis, what needs to be done next? With so many needs, which demand should we start with?

Key requirements = key functions + key quality. It determines the general direction of the architecture.

First of all, let's be clear: it is impossible for all needs to be equal. We need to identify the following three types of requirements from a large number of use cases:

Key functional requirements: those functions that involve the largest number of modules and the most representative way of collaboration between modules, filter out a subset of key functions

Key quality attributes: which quality attributes have a greater impact on the software architecture during the development and operation phase, and which should be given priority if there are contradictions between the quality attributes?

High-risk part: considering the technical difficulty, which functions are risky in technical implementation and need to be verified by experience in advance?

These three types of requirements are the requirements that we need to focus on, and they are also the input materials for the next step (domain modeling).

This is the end of the content of "how the software architecture is layered and divided into modules". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.