9

So, yes, diagrams can be inappropriate at times. When are they inappropriate? When you create them without code to validate them, and then intend to follow them. There is nothing wrong with drawing a diagram to explore an idea.

Agile Software Development: Principles, Patterns, and Practices - Robert C. Martin

What exactly does he mean by this? Isn't UML designed to help plan out how to structure your code before "diving in"? What's the point of using it if you don't follow the diagrams you came up with?

Context: In this chapter, Uncle Bob makes a UML diagram for the Score Keeper of a Bowling game. Then he goes on to develop the program in a test driven manner, without consulting the UML diagram. The resulting program is nothing like the UML diagram, and Uncle Bob comes to the conclusion quoted above.

  • 4
    Uncle Bob's point is that architecture that emerges from Test-Driven Development can differ radically from the UML diagram. – Robert Harvey Dec 15 '15 at 5:46
  • 1
    Also read is design dead? By Martin fowler for a balanced discussion of this topic and the agile movement – Eliezer Steinbock Dec 15 '15 at 9:08
  • 4
    Upvoting this question in response to poor judgement on the part of @RobertHarvey et al in voting to close what is an important and useful question. – David Arno Dec 15 '15 at 13:27
  • 3
    @DavidArno If you have strong opinions about what should or should not be closed, I would strongly encourage you to get involved in the discussions on our meta site. Everyone who currently posts there (including me) probably falls under "@RobertHarvey et al" except for a few SE employees, and we've been concerned there's another viewpoint not getting represented, but thus far no one has ever shown up to represent it. – Ixrec Dec 21 '15 at 17:33
  • 1
    @Ixrec, I've never involved myself with meta discussions before, other than once to check if I could refer to my own open source libraries in answers (the answer to that was that I could). Maybe I should take your advise though and get more involved. Thanks for the suggestion. – David Arno Dec 21 '15 at 17:44
19

To properly explain this, we need a short history lesson. In the early days of software engineering, an often used analogy was building a house. An architect and structural engineer discuss plans with a customer and come up with a design. Builders then follow that design to build the actual house. Writing code was seen as the equivalent to building the actual house. Thus, there was a perceived need for up front design before that build could take place. Various graphical design tools were created, with UML being one of them.

The idea originally with UML, was that one would fully design a system with UML, then hand it over to coders to translate that design into code. In reality, this just doesn't work, and led to years of programmers being seen as "implementers", rather than "designers", projects being late, the designs having to constantly change after they were supposed to be complete etc.

The reason is simple. Coding is design. With the house analogy, the code is the architect's drawings. The compiler is the builder who takes those designs and builds a program from them. This realisation then led to agile techniques, TDD etc being born: tools to help improve the quality of that code design.

Just as an architect might produce preliminary sketches to help her and her team visualise the overall design, so a developer might use UML, or other tools, to help visualise the design needed. Just as those sketches aren't blindly followed, so the UML should not be blindly followed. The code design should evolve out of agile iterations and using TDD. LIkewise, just as an architect might build a model of the house to help her and her team visualise the drawings, so UML can be used to help visualise the code structure.

As Uncle Bob says, you can't validate the UML, you can only validate the code. Therefore the code is the prime design documentation and UML, if used, is secondary documenation only.

  • 7
    I had a section of the roof of my house lifted earlier this year and it was quite educational. The Architect really did no more that draw what the end product was supposed to look like. He handed the hard calculations and structural design to a building engineer. The builders then had to match the theoretical designs to the actuality of the house (once the plasterboard was off, the beams were found to be in slightly different places) so design was taking place at every step. – Jaydee Dec 15 '15 at 11:23
  • 1
    This is a useful answer, nevertheless it oversimplifies some aspects. One of the main reasons why UML does not work well as a "high level design notation" is IMHO their inventors were too stubborn to add a data flow diagram. That is the only kind of notation I know which suits for top-town design, allowing to express abstractions for components and interfaces between them of different scale, and can also have a well defined mapping to code. Instead, UML contains a lot of nonsense which noone really needs. – Doc Brown Dec 21 '15 at 20:52
3

I guess that not every programming idiom (or design, or code) fits into UML (which I admit I don't know well -only read a few books on it-, I never used it, and I probably dislike it).

Plain C code (e.g. the source code of the Linux kernel) might not be exactly modeled by UML.

Ocaml code (with its modules and functors) or even C++11 code (with lambdas and templates) might not fit into UML.

Multistage programming à la MetaOcaml probably don't fit into UML.

Prolog code or Common Lisp code probably does not fit into UML.

See also this answer & this question of mine.

Read Scott's Programming Language Pragmatics and Van Roy's Concepts, Techniques and Models of Computer Programming books, then ask yourself if every programming model there fit into UML.

See also Martin Fowler's Is Design Dead? blog.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.