Robert C. Martin's views on UML and CASE

I recently read Agile Principles, Patterns, and Practices in C #, written by Robert C. martin and his son Micah Martin. their views on the use of UML and CASE are somewhat unconventional. I think it is very helpful to share them with you. My understanding may be biased. It cannot fully represent Robert's point of view. It is purely the title party that attracts attention.

1. Do you need to have a full grasp of multiple types of UML n images?

UML has many types of Class Diagrams, state Diagrams, and so on. But for programmers, there are only a few types of classes used: Class Diagrams and Objects Diagrams) sequence Diagrams, Collaboration Diagrams, and State Diagrams );

2. Why modeling?

Some people may say: Is it still called an architect to draw a lot of images without using UML? But Robert said, No. architects use code instead of a bunch of messy UML diagrams. UML diagrams are just a tool for communication, and they are used to draw on whiteboards or white paper, instead of binding it into a seemingly formal document to decorate the facade.

3. Do I have to model the development process?

Also, the purpose of modeling is to test whether a scheme is feasible. Since it is a test, of course it is used at a low cost. If the cost of directly using code is similar to that of drawing a complex UML diagram, it is better to use code directly.

4. When do I need to draw a UML diagram or when?

Situations to be drawn:

• Several people need their colleagues to do something, so they need to understand the entire structure and draw a unified idea of UML diagrams. Once we reach a consensus, these figures are successful and can be erased and discarded.
• You want the team to reach a consensus, but one or two of them disagree with your solution. You need to discuss the problem within a fixed period of time. When the discussion time is used up, you should set the result and avoid endless discussions and discussion. It can be determined by a vote or an authoritative person.
• When you are thinking about a design, you can use UML to help you think about it. If you think about it, you can discard it.
• When you want to explain your code to others, you need to draw some.
• The project is over. You have to draw a UML diagram when submitting it as a document.

The following situations do not need to be illustrated:

• It seems that the software development process requires UML and then in coding?
• You don't think you will feel guilty if you don't want to draw a UML diagram.
• Creating Complex UML is more troublesome than writing code.

5. CASE tools

Think carefully before you plan to invest in a CASE tool ~

• Isn't the CASE tool easier for us to draw UML diagrams?No, it can only increase complexity. Because you have to spend half a day learning this software.
• Isn't the CASE tool making it easier for a big unity to work together when drawing a UML diagram?Sometimes, however, a large team does not need to draw so many complex UML diagrams.
• Isn't the CASE tool able to automatically produce code?Yes, but maintaining and modifying the production code won't save much for you to write. Therefore, we recommend that you measure how much productivity can be improved before you spend money on the case tool.
• How about integrating the CASE tool with IDE?Well, this is a good idea. But frankly speaking, I would rather spend the money I spent on CASE on IDE's programming improvements.

6. Sometimes, text format is simpler than graphics. We also have the opportunity to use automated tools for further processing. For example, SMC (Statce Machine Compiler) for State Transitions Tables can refer to http://www.objectmentor.com

 

Well, conclusion:

Do not go to UML for the purpose of UML; UML is just a communication tool, and you can discard it if you are clear about the communication; you should be able to imagine the corresponding code implementation when drawing a UML image; otherwise, do not draw it.