Agile Software Development: principles, patterns and practices--the 14th chapter uses UML

The 14th chapter uses UML

Before exploring the details of UML, we should first talk about when and why to use it. The misuse and misuse of UML has caused too much harm to the software project.

14.1 Why Modeling

Modeling is to figure out whether something is feasible. When models are much cheaper than real entities to build, we use models to study designs.

14.1.1 Why build a software model

UML is used when we have some definite things to test, and using UML is less expensive than testing with code. For example, I have an idea about a design. I wanted to know if other developers on the team thought it was a good idea, so I drew a uml diagram on the whiteboard and asked the team members for their comments.

Should I build a design that is exhaustive before 14.1.2 coding?

In fact, we have no clear idea of whether it is a cost-effective choice to create a UML design that is exhaustive before writing code.

14.2 using UML effectively

We cannot use UML as lightly as other engineering disciplines, using blueprints and models. So, what should we do with UML?

Illustrations are most useful in communicating with others and helping to solve design problems. The important point is that the level of detail in the diagram should be only necessary to achieve the goal. You can draw illustrations with lots of decorations, but that's a way to damage productivity. Make sure the diagram is simple and clean. UML diagrams are not source code and should not be used as a place to declare all methods, variables, and relationships.

14.2.1 Communicate with others

It is very convenient to use UML to communicate design ideas between software developers. UML is not very suitable for the details of the AC algorithm.

14.2.2 context Diagram

UML is also useful in creating a structural context diagram (road map) for large systems. This diagram allows developers to quickly find dependencies between classes and provides a reference to the entire system.

14.2.3 Project End Document

The best time to write a design document that needs to be saved is at the end of the project and as the team's last job. This document accurately reflects the state of the design and is useful for subsequent teams. UML diagrams must be carefully considered, and we do not need a thousands of-page sequence diagram. What we want is a few important illustrations that describe the key points of the system.

14.2.4 to keep and to discard.

Please form the habit of discarding UML diagrams. Most UML diagrams should not exist for long. Only those illustrations that have high long-term presence value need to be preserved.
Some diagrams remain useful: those that express the public design scheme in the system. Save a diagram of a complex protocol that is difficult to identify from the code. These illustrations provide a context diagram of the less frequently mentioned part of the system. They document the designer's intentions in a way that is more expressive than the code.

14.3 iterative Improvements

14.3.1 Behavior First
I like to start with the behavior. If I thought that UML would help me to think about a problem, I would first draw a simple sequence diagram or a collaboration diagram of the problem. Take the phone call to complete the example.

We can imagine that the software detects every keystroke and sends a message to an object that controls dialing. So we draw a button object and a dialer object, and the button sends multiple digit messages to dialer.

This number is displayed on the screen when dialer receives a message.

Dialer It is best to make the speaker sound. So we let it send a tone message to the Speaker object.

At some point, the user presses the Send button to indicate that the number has been dialed out. At this point, we have to let the mobile phone wireless communication device area connected to the mobile phone network and the dialed telephone number to pass out.

Once the connection is established, Rado can let screen light up the "in use" light. This message is undoubtedly emitted from a different control thread, which is indicated by the letter preceding the message ordinal. The final collaboration diagram is as follows:

14.3.2 Inspection Structure

To study what this collaboration diagram means for the code structure, we created a class diagram:

In order to isolate the button and dialer:

Dialer does not require a method called buttonpressed, in order to isolate dialer and Buttonlistener, the adapter is used:

14.3.3 Imagination Code

If a drawing cannot imagine the code it represents, it is building castles in the castle. Stop drawing and think about how to translate it into code. Never draw pictures for drawing.

Evolution of 14.3.4 graphs
We probably do this in front of a whiteboard and may not record the work we do. We don't want to be very prescriptive or very precise. The purpose of using the Whiteboard is not to make every point in the message sequence correct, but to let everyone standing in front of the whiteboard understand what is being discussed, in order to stop the discussion quickly and begin coding.

14.4 when and how to draw a diagram

Do not specify a rule such as "Everything Must be illustrated". A lot of time and energy will be wasted on drawing icons that no one will look at.

The following scenarios can be plotted:

• Several people need to understand the structure of a particular part of the design, because they will all work on it at the same time. When everyone thinks they understand, stop.
• You want the team to agree, but there are two or more people who disagree with the design of a particular element. Limit the discussion to a time box and then choose a strategy, such as voting or fair adjudication. End when the time box terminates or is able to make a decision. Then erase the diagram.
• You want to try out a design idea, and the diagram can help you think. Stop when you can use the code to finish thinking. Discard the diagram.
• You want to explain the structure of some parts of the code to someone else or yourself. When you are better able to interpret by browsing the code, stop.
• is nearing the end of the project, and the customer requests that the diagram be part of a set of documents that are provided to others.

Do not draw a picture as follows:

• Process requirements.
• Not drawing will be guilty or think it's a good thing for a designer to do. Writing code is a good thing for a designer to do. They only draw when necessary.
• In order to create an exhaustive design-time document before encoding. This kind of document is basically worthless, but it wastes a lot of time.
• In order for others to encode it. A real software architect is involved in the code that he or she designs.

14.5 Conclusion

UML is a tool, not the end result. As a tool, it can help you to think and communicate the design. If you use it sparingly, it will bring you great benefits. If used excessively, it will waste you a lot of time. When using UML, less is better.

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 14th chapter uses UML