How do architects draw system architecture blueprints?

Preface

Today, let's learn some basic knowledge about software design documents , In this way, when you study the following specific cases , You can more clearly understand how documents are organized .

First , Please imagine such a scenario ： If the company arranges you to be an architect , You should design the software architecture in the early stage of project development , How do you carry out your work ？ How to output the results of your work ？ How to determine whether your design meets user needs ？ Are you sure that the final software delivered will meet the requirements ？ Are you sure to let each engineer in the team know his scope of responsibility and complete the development work effectively ……

These problems are actually the core demands of software development management and technical architecture , The core work of an architect is to do a good job in software design , Solve these appeals . These problems are solved , The development process and results of the software are guaranteed . How to realize these demands ？ Our main means is Software modeling , And organize these software models into a valuable software design document .

Software modeling

Software modeling , Is to build models for the software to be developed .

A model is an abstraction of an objective being , For example, the famous physics formula E=mc2, It is the mathematical model of the physical law of mass energy conversion . In addition to physical formulas , Some other things are also models , For example, maps are the modeling of geographical space ; Mechanical devices 、 electronic circuit 、 Various drawings of architectural design are the modeling of physical entities . And software , You can also model through various diagrams .

The software system is huge and complex , Through software modeling , We can abstract the main features and components of software systems , Sort out the relationship between these key components . In the process of software development, develop according to the constraints of the model , The overall pattern and relationship of the system will be controllable . Relevant personnel can clearly understand the blueprint and current progress of the software from beginning to end , Different development engineers will be clear about the relationship and dependence between their own modules and the work content of other colleagues , And develop code according to these models .

So what is the basis of software modeling ？ To answer this question , You need to know , In software development , There are two objective existence .

One is the domain problem we need to solve . For example, we need to develop an e-commerce website , So the objective problem is how to do business , How do sellers manage goods 、 Manage orders 、 Service users , How do buyers choose goods , How to place an order , How to pay, etc . The abstraction of these objective domain problems is all kinds of functions and their relationships 、 Various model objects and their relationships 、 Various business processes .

Another objective existence is the software system finally developed . The problems to be solved by the software system include which main classes the software is composed of , How are these classes organized into components , What are the dependencies between these classes and components , How the runtime calls , How many servers need to be deployed , How to communicate between servers .

And the means of abstracting these two objective beings , Is our software model .

 

On the one hand, we should analyze the domain problems and the software system to be designed 、 Design 、 abstract , On the other hand , We develop according to the abstract model , Finally, a software system is realized , This is the main process of software development . And analyze domain problems and software systems 、 The process of design and abstraction , Software modeling and design .

Software design method

therefore , Software design is actually the process of software modeling . We use software modeling tools , Draw the software model , Realize software design .

In practice , The tool commonly used for software modeling and drawing is UML, Unified modeling language .UML The included software models are 10 Kind of , The common ones are 7 Kind of ： Class diagram 、 Sequence diagram 、 Component diagram 、 Deployment diagram 、 Use case diagram 、 State diagrams and activity diagrams .

Now let's briefly understand this 7 Common use UML Usage scenarios and basic examples of figure . In the design document behind the column , You will see them many times , To see more , You will understand , It will naturally draw . Of course , If you want to study in more detail UML knowledge , I am also very encouraged , And I recommend you to read Martin Fuller's 《UML Essence 》 A Book .

Class diagram

Class diagrams are the most common UML graphics , Used to describe the Characteristics of classes and static relationships between classes .

A class has three parts ： The name of the class 、 Class attribute list and class method list . There are 6 A static relationship ： relation 、 rely on 、 Combine 、 polymerization 、 Inherit 、 generalization . Draw a picture of a group of related classes and their relationships , Class diagram .

For example, you will encounter the following picture in the later course , It is the class diagram . You can compare the elements in the class diagram I mentioned above with the pictures one by one , Feel the usage of class diagram .

 

Sequence diagram

Outside the class diagram , Another commonly used diagram is the sequence diagram , Class diagrams describe static relationships between classes , Sequence diagram is used to describe Dynamic invocation relationship between participants .

 

Component diagram

Components are design elements that are more granular than classes , A component usually contains many classes . Sometimes, the purpose of component diagram is similar to that of package diagram , Component diagrams are often used to describe physical components , For example, a JAR、 One DLL wait . In practice , When we design modules , What we use more is component diagram .

 

The component diagram describes the Static relationship , Mainly dependency , If you want to describe the dynamic calling relationship between components , You can use component sequence diagrams , Take components as participants , Describe the message calling relationship between components .

Deployment diagram

The deployment diagram describes the final deployment of the software system , For example, how many servers need to be deployed , Which servers are the key components deployed on .

 

The deployment diagram is the blueprint of the final physical presentation of the software system , According to the deployment diagram , All those involved , Such as customers 、 Boss 、 Engineers can clearly understand what the final running system looks like physically , Relationship with existing system servers , Relationship with third party servers . According to the deployment diagram , You can also estimate the purchase cost of servers and third-party software .

Therefore, the deployment diagram is in the whole software design model , A kind of macro chart , It is a kind of model drawing that needs to be drawn in the early stage of design . According to the deployment diagram , All parties can discuss whether to approve the scheme . Only a consensus on the deployment map , To continue the detailed design later .

Use case diagram

Use case diagrams reflect Interaction between users and software systems , Describe the of the system functional requirement .

 

The elements of the image of small and medium-sized people , It's called a character , Characters can be people , It could be another system . The functions of the system can be complex , Therefore, a use case diagram may contain only a small part of the functions , These functions are framed by a rectangle , This rectangle is called the boundary of the use case . The ellipses in the box represent functions one by one , Dependencies can be called between functions , It can also be expanded .

State diagram

State diagrams are used to show State transition in the life cycle of a single object .

In the business system , Many important domain objects have complex state changes , For example, account number , There is creation status 、 active 、 Frozen state 、 The state of arrearage and so on . Besides , user 、 Order 、 goods 、 These common domain models have multiple states .

The transition description of these states can be described in words in the use case diagram , It changes with the operation of the character , But describe in this way , The state is scattered everywhere , Don't say it's easy to make mistakes when developing , When the product manager is designing by himself , It's also easy to get the state change of the object wrong .

UML The state diagram can solve this problem well , A state diagram describes the various states of an object's life cycle , And its changing relationship . As shown in the figure , The door is open Opened、 Turn off Closed And lock Locked Three , The relationship between state and transition can be solved with a state diagram .

 

Activity diagrams

Activity diagram is mainly used for Describe process logic and business processes .UML There is no flowchart in , A lot of times , People use activity diagrams instead of flow charts .

 

Activity diagrams are also very close to the graphical elements of earlier flowcharts , A solid circle represents the beginning of the process , The hollow circle represents the end of the process , Rounded rectangles represent activities , Diamond means branch judgment .

Besides , Activity diagrams introduce an important concept —— lane . The activity diagram can be based on the scope of activities , According to the field 、 Systems and roles are divided into different lanes , Make process boundaries clearer .

We introduced above UML Modeling commonly used 7 Kind of model , So this 7 At what stage of software design are these models applied ？ What kind of design intention is it used to express ？

Software document design

Software design documents are the main work of architects , It needs to explain the various appeals mentioned at the beginning of this article , Describe the complete blueprint of the software , The main component of the software design document is the software model .

The software design process can be divided into Demand analysis 、 Outline design and Detailed design Three stages .

stay Demand analysis stage , It mainly describes the function and use scenario of the system through use case diagram ; For critical business processes , It can be described by activity diagram ; If it is proposed to integrate with some existing subsystems in the requirement stage , Then the calling relationship between the new system and the original subsystem can be described through the sequence diagram ; The domain model can be abstracted through the simplified class diagram , And describe the relationship between the core domain objects ; If there are complex state changes inside some objects , Such as user 、 Order these , It can be described with a state diagram .

stay Outline design stage , Describe the final physical blueprint of the system through the deployment diagram ; Design the main modules and their relationships of the software through component diagram and component sequence diagram ; The process logic between components can also be described through component activity diagram .

stay Detailed design stage , The main output is class diagram and class sequence diagram , Guide the final code development , If there is more complex logic inside a class method , Then the logic of this method can be described with an activity diagram .

We use several at each design stage UML Model models the domain or system , Then write these models together with the necessary text descriptions into the document , It can form a software design document .

More than a dozen software design cases in our column , Are organized in this way , You can learn , On the one hand, understand how various system software is designed , On the one hand, we can also learn from how design documents are written .

At the same time, it should also be explained , There is no set rule for writing design documents , The most important thing is whether this document can Convey the complete design intention of the architect to the reader . Different readers have different concerns , Boss 、 Customer 、 Operation and maintenance 、 test 、 Developing these roles are readers of design documents , What they want to see is obviously different .

Customers and testers may pay more attention to functional requirements and implementation logic , Bosses and operation and maintenance personnel may pay more attention to non functional requirements and the overall architecture , Developers may pay more attention to the overall architecture and key technical details .

The case of our column is basically Written from the perspective of developers , When you read these cases , I will obviously feel that my way of expression is different from other columns , The wording will be more “ hard ” One o'clock , The distance between words and readers is also a little “ alienation ”, This is the nature of the design document itself .

framework 、 System , file 、 Refer to the following figure for the relationship between relevant personnel .

 

Every software system needs an architecture , Each architecture contains several architectural elements . The architecture element is the server mentioned above 、 Components 、 class 、 news 、 Use cases 、 Status and so on . What is the relationship between these elements ？ How to organize them together ？ We can use deployment diagram 、 Component diagram 、 Sequence diagram and other model diagrams .

Finally, the architecture needs a document to carry , Put these model diagrams into this document , Accompanied by appropriate text , It is an architecture design document . And design documents are for people to read , These people are the interested parties of the system . Different interested parties have different concerns , It also needs to be expressed by different model diagrams , therefore Architects should target different stakeholders , Use different model diagrams to output different architecture documents .

Summary

Software design is before software development , Think about the business problems to be solved and the software system to be realized , And express the result of this thinking through the software model .

As the spirit of all things , The biggest characteristic is , The process of action and the results of action have been built into a blueprint in the mind before action , Then put this blueprint into practice . When our ancestors polished the first stone into stone tools , You already have this ability . The development of software system is a complex intellectual activity , We who participate in it need to have the ability to build blueprints and put them into practice .

At present, there is a very popular word called “ Meta universe ”,“ element ” informally , Is where everything starts , It's about how to describe yourself , It's an abstraction above abstraction . such “ element ” Capabilities for architects , It's very important . Architects can only master the technology behind various technologies , Understand the problems behind various problems , To transcend the current constraints , Design a future oriented architecture .

If this article helps you , Don't forget to give me a 3 even , give the thumbs-up , forward , Comment on ,

I'll see you next time ！ How to get answers ： Liked Commented Closed ~

Learn more knowledge and skills , Follow up with private bloggers （03）