The 16th Chapter Object diagram
Sometimes it is very useful to present the state of a system at a particular point in time. is similar to a snapshot of a running system. The UML object graph shows the objects, relationships, and property values acquired at a given moment.
However, you should be wary of spending too much on the object graph. In most cases, they can be deduced directly from the corresponding class diagram and are therefore of little use.
The 17th Chapter use Cases
In all UML diagrams, use case diagrams are the most confusing and useless. I suggest that all other graphs be ignored outside the system boundary. The system boundary diagram example is as follows:
Large rectangles are system boundaries. Everything inside the rectangle is part of the system that will be developed. Outside the rectangle is the participant of the operating system. Participants can be people or other systems or devices.
18th Chapter Sequence diagram
Sequence diagram The dynamic model that UML users draw most often. However, do not create a sequence diagram for each method. Use a sequence diagram when you need to immediately explain to someone how a group of objects is collaborating or when you want to visualize this collaboration. Use a sequence diagram as a tool to hone your analytical skills occasionally, rather than as a required document.
18.1 Basic Knowledge
18.1.1 objects, lifelines, messages, and more
A typical sequence diagram:
The timeline is vertically oriented, and the lower the message appears, the later it is sent. Note the use of the E variable in the GetEmployee message, employee and e are actually the same object. The return value of GetEmployee points to a reference to the Employee object. Employeedb is a class, so its name is not underlined below. This means that the getemployee can only be a static method.
18.1.2 creation and destruction
Create an object, draw a line end in the object you want to create, as follows:
The corresponding code:
Public class shapefactory{ public Shape makesquare () { returnnew Square (); }}
To release an object to the garbage collector:
Corresponding Code:
Public class treemap{ private TreeNode topnode; Public void Clear () { null; }}
18.1.3 Simple Cycle
The way to draw a simple loop is to draw a box around the message that needs to be sent repeatedly. The loop condition is then included in one of the brackets.
18.1.4 Timing and Occasion
Do not draw a sequence diagram with a large number of objects and messages. No one can understand, and no one wants to see. It's a huge waste of time. If you think the sequence diagram is necessary, ask yourself if you can break it down into a group scenario.
The team should be committed to creating expressive, easy-to-read code. The more the code can describe itself, the less you need the diagram, the better the whole project.
In general, high-level attempts are more useful than low-rise attempts.
18.2 Advanced Concepts
18.2.1 Cycles and Conditions
18.2.2 Time-consuming messages
With a telephone call as an example, the normal calling telephone is as follows:
The failed phone calls are as follows:
18.2.3 Asynchronous messages
Examples are as follows:
18.2.4 Multi-Threading
Example below, T1,t2 is the name of the thread:
18.2.5 Active Object
An object that has a separate internal thread called the active object. They appear as bold borders, as follows:
18.2.6 sending a message to an interface
Examples are as follows:
Send a message to its derived type through an interface:
18.3 Conclusion
A sequence diagram is a tool. To be used in accordance with its design intent. Use them in front of the whiteboard to communicate with others in real time. Use them in short documents to record those core, important collaborations in the system.
In the case of sequence diagrams, too little is better than too much. You can always draw a sequence diagram when you need it later.
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 16th chapter, the 17th chapter, the 18th Chapter sequence diagram