UML for Java programmers

1. When you make a graph, you can imagine that your code is extremely important. We use graphs as a shortcut to understand the code, rather than replacing the code. If you draw a picture but cannot imagine what code it represents, you are building a castle in the air. Stop what you are doing and think about how to convert it into code. Do not draw pictures for purpose. You must always remember that the code is what you want to do.

---Designers evolved from coder, coder experience (code --> repetitive code habits --> patterns) --> designers

When designing, the designer is exactly the opposite direction of the above process. Specific problems in the field --> abstract mode --> similar experience --> code (Implementation) that has been written ).

2. The purpose of using a whiteboard is not to properly map the serial number point on the whiteboard, but to make everyone who discusses it before the whiteboard understand it, the final goal is to stop painting on the whiteboard and start coding.

--- The purpose of the project is to end the project.

The purpose of UML (Communication Mode-design and development personnel) is to implement, design implementation, and communication and understanding are processes.

 

3. When do I start drawing?

When multiple developers develop, everyone needs to understand the specific part and start drawing. Everyone understands and stops drawing.

There is a different opinion on the design of a certain place: drawing. When making a decision, stop drawing and erase the drawing.

When you need to discuss a design idea, drawing can help you think better. When you get the key points of the code that can help you think about, You can discard these graphs.

You can draw a picture when you need to explain the structure of some code to others or yourself. When you think it is best to look at the code for explanation, stop drawing.

Draw a picture when the customer needs it.

When do I stop drawing?

Not because of the process.

It is not to draw a picture for a good designer, as if not to draw a picture, it is not a good designer.

You do not need to draw a picture for others to implement the Code, but for your own implementation.

---Drawing is needed for real purpose (the goal of drawing is implementation)

4 dependency JAVA Implementation

 

5 can code be used to describe a part of the system? In fact, this should be the goal of every designer and developer. The team should try to create code with clear expressions and strong readability so that more code can describe themselves and less need to be illustrated. It is best that the entire project does not need a diagram.

 

6. One thing to note about use cases is that they will change tomorrow.

If something will change tomorrow, you do not need to capture details today. In fact, you should try to delay the capture of details until the last possible time.

 

7. Martin documents: Write only those meaningful documents that you really need.