preface
Just like any living thing, software has a process of birth, birth, growth, maturity and decay, often called the “software life cycle”. The software life cycle is generally divided into several phases: planning, requirements analysis, design, coding, testing, operation, and maintenance. UML supports the process from requirements analysis to design to coding.
Requirements analysis and design occupy two parts of the entire software life cycle, which shows their importance, and many times, the development students often skip these two steps, directly into the coding phase. This paper mainly uses PlantUML open source project, combined with the requirements of some actual projects for analysis and design.
PlantUML is a simple UML graphical drawing language that allows you to draw UML diagrams in just a few lines of code. With proficiency, it can be much more efficient than ordinary drawing tools. More important is the ease of versioning and continuous maintenance in the context of iterating functional requirements.
Requirements analysis – Prelude
The prelude is the key of a song, which determines the style change of the whole song to some extent. Requirement analysis is the foundation of the whole software design.
Many development students wonder: requirements analysis is a product manager to do? What do we have to develop? In fact, the first and most important purpose of requirements analysis for development is to accurately and concisely answer the question “who does what with what system”. We can often use a “use case diagram” to figure this out.
Use case diagram
For example, in the “Listing courtesy” project, there is the following use case diagram:
- “Client users use the Posting system to match the Posting policy”
- “Operation personnel use this system to set the billing policy”
PlantUML code
@startuml
left to right direction
Actor as D
Actor Client user as user
Rectangle {Rectangle (rectangle) {
D –> (single exposure policy): set
User –> (list)
(List) –> (list policy): matches
}
@enduml
parsing
1, @starUML and @endUML plantuml pre-generated start and end labels 2, left to right direction // indicates that the graph is drawn from left to right
3, Actor user (SIMS graphics)
4, Rectangle box, internal code graphics in this box
5, –> solid arrow
The above simple expression, “the client user uses the Posting system to match the Posting policy” and “the operation staff uses the system to set the Posting policy”, can probably answer the question “who uses what system to do what”. But that’s not detailed enough. We can also extend it as follows:
The figure above supplements and explains “Posting” and “Posting strategy”.
- The “post order” entry is from the order list
- There are two actions for singleton policy: Set and Match
- List Posting includes Sending Behavior and Matching List Posting Policy.
- “Set the Posting strategy” includes “Set the incentive type” and “Set the portrait”.
PlantUML code
@startuml
left to right direction
Actor as D
Actor Client user as user
Rectangle {Rectangle = rectangle
D –> (Setting the single list policy)
> (Set portrait): include
> (Set the incentive type): include
User –> (view order list)
(View order list) –> (display order)
> (publish dynamic): “include”
(Listing).> (Matching the listing policy): Include
}
@enduml
parsing
1. In addition to the common associations and generalizations, use case diagrams have the following two types: Extend – an additional feature of a feature. 2, (post orders).> (post orders): include means that post orders include the post action. The colon can be followed by arbitrary text.
In fact, we can refine the use case diagram further, but it is not necessary to do so. The use case diagram usually only needs to be able to clearly describe the two W’s, Who- Who uses the system; What- What to do with the system.
Summary design – Verse
The verse is the central idea, the central theme of the song, and it runs through the song. In the outline design, we need to sort out and understand the context of the whole project.
With the foundation of requirements analysis, we can better conduct the outline design. As mentioned above, requirements analysis requires a Who&What answer, while summary design requires a how-how answer. In summary design, I usually use activity diagrams, state diagrams, and timing diagrams in UML to describe my design.
Activity diagrams
In UML, activity diagrams are more general, such as flow diagrams, swimming lane diagrams, etc. The main focus of the flow chart is to highlight the flow nodes and the direction control of the nodes. The swimlane plan is based on the flow chart, highlighting the position and role of different roles in the whole process. Usually we draw them together.
Let’s look at an example of a self-created circle project:
For lane drawing, it is recommended to use other tools.
Compare a graph drawn using other tools (exactly the same process) :
PlantUML code
@startuml
| | client
| | H5 the front
|ServerAPI|
| | CRM the background
| | client
start
|ServerAPI|
If (does not meet the requirements of building circle) then
| | client
: The entrance to the building circle is not displayed;
stop
else
| | client
: Show the entrance of the building circle;
| | H5 the front
: Fill in the circle form;
|ServerAPI|
Submit the form for review;
| | CRM the background
If (not approved) then
|ServerAPI|
: Private message notification failed;
stop
else
|ServerAPI|
: Private message notification passed;
| | client
: Show the entrance of circle building task;
: Click the mission entry;
| | H5 the front
: Display the task list;
|ServerAPI|
If (unfinished task) then
: The private message notification task failed.
stop
else
: Private message notification task succeeded;
| | client
: Keep self-built circles;
stop
@enduml
parsing
1. | | client
Double vertical lines indicate swimming lanes.
2. Start and stop
The start and end nodes are a required element in the swimlane flowchart.
3、if … then … else
Conditional judgment is generally expressed in a diamond.
Generally speaking, the flow in the swimming lane can only “swim” down, not “swim” back.
State diagram
A state diagram is used to describe the various states of an entity and the transition relationships between the states. For example, the most common “order status” on the e-commerce platform is complex and diverse, and the status diagram can make the project more clear.
In order to show the politeness, there is involved in the order list button status change. In the following example, there are several key points:
– Must have a start state and an end state
– States are relatively static
– Transitions between states must be accompanied by actions
– States can contain states
PlantUML code
@startuml
[*] –> Status of other orders changed
State State change of other orders {
[*] –> Waiting for payment
Waiting for payment –> [*] : Cancel payment
Waiting for payment –> Waiting for shipment: payment
Waiting for shipment –> [*] : Cancel order
}
Other order status change –> Rude confirmation of receipt: polite policy not hit
Other order status change –> Polite confirmation of receipt: Hit polite strategy
Confirm receipt politely –> show the list: click confirm receipt after 14 days
Rude to confirm receipt –> show the list: click confirm receipt
List: view list information
Courtesy to confirm receipt –> list courtesy: click to confirm receipt
List courtesy -> view list: publish dynamic
Check your list –> Be polite check your list: Check and send coupons
Check out the list politely –> Check out the list: get the coupon
Check the list –> [*]
@enduml
parsing
1, [] –> –>[]
The sub-table indicates the start and end states.
2, the state… {}
States can contain sub-states. In this case, Posting orders is not concerned with the other states of the order and can be described simply using this syntax.
Sequence diagram
Sequence diagrams are my favorite UML diagrams. When working with multiple teams, they make communication very efficient, and everyone involved can quickly understand what they are responsible for.
For example, here is a sequence of brand list requirements:
PlantUML code
@startuml
hide footbox
autonumber
Actor “user” as user
participant “APP” as app
Participant “Server” as tag
Participant “number position” as SC
See the participant “algorithm” as ALg
== Click the brand entry ==
User -> app: Click on the brand entry card
activate user
activate app
App -> tag: calls the custom brand data interface
activate tag
Tag –> app: Return “No brand data to select”
deactivate tag
App -> app: The window for selecting a brand is displayed
App -> tag: access the brand data interface
activate tag
Tag -> sc: access the number of stores sort data
activate tag
activate sc #orange
Sc –> tag: returns the brand sorting result
deactivate tag
deactivate sc
Tag -> alg: Queries user community preferred brands
activate tag
activate alg
alg –> tag
deactivate tag
deactivate alg
Tag –> app: brand data (including 2 default options)
deactivate tag
app –> user
deactivate app
deactivate user
@enduml
parsing
1, the autonumber
It is recommended to specify the display number for convenient communication.
2, Actor, participant
Represents users and objects.
3, activate user, deactivate user
Activate an object, terminate an object.
4, activate sc #orange
Here is a trick to use to color the active states of an object for emphasis.
5. In the small figure on the left, steps 6 and 7 are activated again in an activated state. The emphasis here is to start the thread and make concurrent calls.
Detailed design – Chorus
The chorus, the important part sung twice more, is the climax of a song and can sublimate the central idea. In the detailed design, we select some details and core parts from the outline design to do further design.
The detailed design is like the chorus of a song (often called the climax), which is covered in the verse but needs to be emphasized. In general, detailed design is also used to answer How- How to solve the problem, but need to grasp the difficulties of the whole system to focus on the design. In UML, I usually use sequence diagrams, class diagrams, and component diagrams.
Sequence diagram
Seeing this subtitle, some students may ask, “Hey, how is this time sequence again?” . In fact, the sequence diagram can go up to the system level call procedure, down to the method level call procedure, and can even be very close to the code logic. It is often used in detailed design. Here is an example:
PlantUML code
. / / to omit
Loop Ids of the loop order
Server -> extend: Queries whether the trend_extend order exists
activate server
activate extend
Extend -> server: returns whether the order has been bound
deactivate extend
. / / to omit
Alt hit list courtesy
Server ->cserver: Queries coupon information
activate cserver
Cserver -> server: returns coupon information
deactivate cserver
Server ->result: server->result: server->result:
Else not hit the list polite
Server ->result:
end
end
. / / to omit
Code parsing
The code on the left keeps only the core logic, as follows:
1, the loop… End represents a loop, similar to the while statement in every development language.
2, Alt… else … End represents a logical decision, similar to if else in various development languages.
The class diagram
Class diagrams are common UML diagrams that show classes, interfaces, and their static structures and relationships. It describes the structural design of a system.
PlantUML code
@startuml
interface DuDataFlow {
InfoPosts()
InfoAd()
}
class duDataFlow {
grpc.ClientConn
phpservice.Service
context.Context
InfoPosts()
InfoAd()
}
class grpc.ClientConn{}
class phpservice.Service{}
class context.Context{}
DuDataFlow <|-down- duDataFlow
duDataFlow .> grpc.ClientConn
duDataFlow .> phpservice.Service
duDataFlow .> context.Context
@enduml
Code parsing
The code on the left is very close to the class definition and interface definition of the development language.
1, the < | – down – inheritance relationships
2.> Dependencies
The other parts
Detailed design includes not only timing diagram and class diagram, but also DDL, interface document, task division and other modules, which will not be expanded here.
At this point, the design document is only one step away from writing code!!
conclusion
If you compare writing a software design document to writing a song. Then demand analysis is the prelude of a song, and the prelude is the keynote of a song, which determines the style of the whole song to some extent. Summary design is the verse, the central idea, the core theme of a song; Detailed design is the climax of a song, beautiful, important part, of course, to sing twice more, deepen the memory point.
Finally, I will summarize the characteristics of several UML diagrams in a few words:
– Use case diagram – Answer “who does what with the system” – Activity diagram – Highlight the transaction twists in the process, and the position and role of each swimlane – State diagram – Describe the various states of an entity and the transition relationships between states – Timing diagram – Make communication very efficient when working with multiple teams It can also be the detailed structure of the code logic – the class diagram – how is the code organized, the relationships between the classes
Article | BeeOML
Focus on object technology, hand in hand to the cloud bold technology