The 13th chapter to the C # Programmer's UML overview
UML contains 3 main types of illustrations. Static diagram describes classes, objects, data structures, and their relationships, thus showing the unchanging logical structure between software elements. Dynamic diagram shows how a software entity changes during operation, describing how the running process or entity changed state. The physical diagram (physical diagram) shows the immutable physical structure of the software entity, which describes physical entities such as source files, libraries, binaries, data files, and the relationships between them.
Looking at the code below, this program implements a mapping (map) data structure based on a simple binary tree algorithm that is familiar with the code and looks at the following diagram:
usingSystem;namespacetreemap{ Public classTreeMap {PrivateTreemapnode Topnode =NULL; Public voidADD (IComparable Key,Objectvalue) { if(Topnode = =NULL) Topnode=NewTreemapnode (key, value); ElseTopnode.add (key, value); } Public ObjectGet (IComparable key) {returnTopnode = =NULL?NULL: Topnode.find (key); } } Internal classTreemapnode {Private Static ReadOnly intless =0; Private Static ReadOnly intGREATER =1; PrivateIComparable Key; Private Objectvalue; PrivateTreemapnode[] Nodes =Newtreemapnode[2]; PublicTreemapnode (IComparable Key,Objectvalue) { This. Key =key; This. Value =value; } Public ObjectFind (IComparable key) {if(Key.compareto ( This. key) = =0)returnvalue; returnFindsubnodeforkey (Selectsubnode (key), key); } Private intSelectsubnode (IComparable key) {return(Key.compareto ( This. Key) <0) ?Less:greater; } Private ObjectFindsubnodeforkey (intnode, IComparable key) { returnNodes[node] = =NULL?NULL: Nodes[node]. Find (key); } Public voidADD (IComparable Key,Objectvalue) { if(Key.compareto ( This. key) = =0) This. Value =value; ElseAddsubnode (Selectsubnode (key), key, value); } Private voidAddsubnode (intnode, IComparable key,Objectvalue) { if(Nodes[node] = =NULL) Nodes[node]=NewTreemapnode (key, value); ElseNodes[node]. ADD (key, value); } }}
13.1 Class Diagram
The class diagram shows the main classes and relationships in the program.
- A rectangle represents a class, and an arrow represents a relationship.
- In this diagram, all relationships are associative (association) relationships. An association is a simple data relationship in which one object either holds a reference to another object, or invokes its method.
- The name on the association is mapped to the variable name that holds the reference.
- In general, an array adjacent to an arrow represents the number of instances that the relationship contains. If the number is larger than 1, it means a container, usually an array.
- The class icon can be divided into multiple panes. Typically, the top-most lattice holds the name of the class. Functions and variables are described in other inter-lattices.
- The <<interface>> symbol is used to illustrate that IComparable is an interface.
- Most of the symbols shown here are optional.
13.2 Object graph
It shows a set of objects and relationships at a particular point in the system execution. You can think of it as a memory snapshot.
13.3 sequence diagram
It describes how the Add method of TreeMap is implemented.
A humanoid line chart represents an unknown caller. The caller invokes the Add method of the TreeMap object. If the Topnode variable is null,treemap, create a new Treemapnode object and assign it to Topnode. Otherwise, TreeMap sends an add message to Topnode.
The Boolean expression in square brackets is called a Guardianship condition (guard). They indicate which path should be selected. The message arrows ending on the Treemapnode icon represent the object construction. Arrows with small circles are called data taken. The narrow rectangular bar below the treemap is called activation (activation). It represents how much time the Add method executes.
13.4 Collaboration diagram
It describes the case where Topnode is not NULL in Treemap.add. The collaboration diagram contains the same information that is contained in the sequence diagram. However, the sequence diagram is to clearly express the order of the messages, and the collaboration diagram is to clearly express the relationship between the objects.
The object is connected by a relationship called a chain. A chain relationship exists whenever an object can send a message to another object. It is the message itself that passes on the chain. They are represented as smaller arrows. Messages are marked with the message name, message sequence number, and any guardianship conditions used.
The sequential number with dots represents the hierarchy of calls. The Treemap.add function (message 1) calls the Treemapnode.add function (message 1.1). Therefore, message 1.1 is the first message sent by the function called by message 1.
13.5 State diagram
UML can represent a finite state machine in a very comprehensive manner. Shows a state machine for a metro revolving door:
It has two states: locked and unlocked. You can send two events to this machine. Coin said he put a coin into the revolving door. Pass indicates that the user has passed the revolving door.
The arrows in the diagram are called Migrations (transition). The flags on it are the events of the departure migration and the actions performed by the migration. When a migration is triggered, it causes the state of the system to change.
Translate into natural language description:
- If the coin event is received in the locked state, it is migrated to the unlocked state and the unlock function is called.
- If the pass event is received in the unlocked state, it is migrated to the locked state and the lock function is called.
- If the coin event is received in the unlocked state, it remains in the unlocked state and calls the Thankyou function.
- If the pass event is received in the locked state, it remains in the locked state and calls the alarm function.
13.6 Conclusion
The illustrations in this chapter are sufficient for most occasions. Most programmers know so much about UML to be able to handle the actual work.
Excerpt from: "Agile Software Development: principles, patterns and Practices (C # Edition)" Robert C.martin Micah Martin
Reprint please specify the source:
Jesselzj
Source: http://jesselzj.cnblogs.com
Agile Software Development: principles, patterns and practices--the 13th chapter of UML Overview for C # Programmers