3 ms·

As long a the "simple boxes and lines" describe the functionality of your design at the level you wish to communicate, then you're doing good. You can stop read

As long a the "simple boxes and lines" describe the functionality of your design at the level you wish to communicate, then you're doing good. You can stop reading here. The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design. Concepts like dependency, multiplicity, inheritance, inclusion, asynchronous message, exception, timed event are all things you can represent with boxes and lines, but unless you adorn the diagram with a huge amount of text you're not going to capture the distinctions between those different types of relationship. It's not unlike any other language: I can use the word thought to describe something in my head that isn't physically manifested, but words like lie, memory, hypothesis, idea, belief, image, nostalgia, forecast, imagination are all used to distinguish between types of thoughts. If I used only simple words like "thought" then I wouldn't be able to express anything more sophisticated while still being concise. In short, if you want to graphically describe something complex, you can either use a sophisticated visual language to do it concisely and unambiguously, or you can use a simple visual language and write tonnes of documentation to support it, with all the problems of attention, ambiguity, and rot that go along with it.

mironathetin 11y ago
"The problem is that complex systems need complex design. " No. Complex systems need more thinking and refactoring until they are less complex.
- arethuza 11y ago
  Exactly - I think the more complex the underlying system the more effort has got to go into finding suitable very high abstractions - you have to step away from the detail and that's something that UML seems to have a really hard time doing. We already have a perfectly good way of representing the details of a system - it's called source code.
  - hiperlink 11y ago
    Except when you are selling a closed source binary which must be specified to the very small details (e.g. accounting systems from an external vendor, sometimes they are not buying the source code - and you don't want to sell it either, since they are going to replace you...).
  - wyldfire 11y ago
    > We already have a perfectly good way of representing the details of a system - it's called source code. Interestingly enough, that's a bit of a false dichotomy. Imagine it's your first day on the team, and there's thirty classes (or thirty functions) in this software package, and you want to understand their inheritance/composition, what's a good way to take a step back and just see how they relate to each other? You can browse some interface files or some source files, accumulating a model in your head. But the visual throughput into your brain is just so much better when you can see it in a diagram. Regardless of whether a human draws the UML representation of the design in advance of the implementation or a machine deduces this from the existing source code, you can still benefit from a class diagram that will cut out the noise of the implementation itself. As long as we're drawing a diagram, why not have a common way to represent the concepts we use in software?
    - arethuza 11y ago
      If I wanted to see a class diagram I'd simply use a tool to generate a class diagram from the code - which I'd then know was completely up to date. Edit: DRY
      - wyldfire 11y ago
        Nothing about UML specifies its use in relation to when or how you wrote the code. Like I said, it's a false dichotomy to suggest that we can have source code or UML but not both. Yes, UML diagrams or any other design docs rot quickly. But like you said, we can generate diagrams after the fact too (or in lieu of ever writing UML diagrams before coding). > perfectly good way of representing the details of a system - it's called source code. ... > simply use a tool to generate a class diagram from the code Once you resolve to generate that class diagram you have a choice in how to represent it. UML is just one way, proposed as a standard way, to represent that visually.
- jeremysmyth 11y ago
  Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device. It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring. Perhaps some can, but when you consider many of the software artefacts we use daily (seeing as that's the context of this subthread), such as operating systems, virtualization platforms, or even good ol' clunky enterprise applications, you can't just wish the complexity away with a bit of hard work.
  - arethuza 11y ago
    I don't think anyone is arguing that complex systems don't need some kind of up front high-level design - what we are arguing about is whether UML is an effective format for design artifacts. I'd be pretty surprised if any of the code that I am using to read this was designed with detailed UML diagrams.
  - crdoconnor 11y ago
    >Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device. It wouldn't have been possible at all if the pieces that make it up weren't loosely coupled. >It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring. It's naive to assume that you can't. Loose coupling pretty much only comes as a result of extensive refactoring.
    - jeremysmyth 11y ago
      ...and one of the ways you can communicate such coupling is by diagramming the (complex) system's design. Google for "linux kernel diagram"[1]. It's quite well designed, displays loose coupling, high cohesion, and all the other things we like about good complex systems. If I want to dig in and start working on a module, I'd still have to understand the relationship between all the bits I work directly with (and probably some that are further away). Don't confuse loose coupling with low complexity. https://www.google.com/search?q=linux+kernel+diagram https://www.google.com/search?q=linux+kernel+diagram
EdiX 11y ago
The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design I've never found any need for a third, intermediate level of sophistication that sits between code and natural language + informal diagrams.
- mannykannot 11y ago
  In programming for science, engineering, finance or cryptography, you may also need the math, but UML does not help there, either.
jcranmer 11y ago
Your statement is only somewhat correct. What complex systems need isn't a single, complex design document but rather levels of simple, intuitive design. It's like OOP--the basic principle of OOP is that you can manage (but not eliminate!) complexity by sharding it into small-ish objects that only need to know about those whom they interact with. Similarly, in a large system, you'd want a high-level, very abstract design detail, and as you peer in closer to the code, you want increasingly concrete design. The problem of UML is that it tries to be the language of all these levels of design (and even different stages of design!), to the point that the highest-level design document is trying to be something so completely specified that there's no abstraction.

mironathetin 11y ago

"The problem is that complex systems need complex design. " No. Complex systems need more thinking and refactoring until they are less complex.

arethuza 11y ago
Exactly - I think the more complex the underlying system the more effort has got to go into finding suitable very high abstractions - you have to step away from the detail and that's something that UML seems to have a really hard time doing. We already have a perfectly good way of representing the details of a system - it's called source code.
- hiperlink 11y ago
  Except when you are selling a closed source binary which must be specified to the very small details (e.g. accounting systems from an external vendor, sometimes they are not buying the source code - and you don't want to sell it either, since they are going to replace you...).
- wyldfire 11y ago
  > We already have a perfectly good way of representing the details of a system - it's called source code. Interestingly enough, that's a bit of a false dichotomy. Imagine it's your first day on the team, and there's thirty classes (or thirty functions) in this software package, and you want to understand their inheritance/composition, what's a good way to take a step back and just see how they relate to each other? You can browse some interface files or some source files, accumulating a model in your head. But the visual throughput into your brain is just so much better when you can see it in a diagram. Regardless of whether a human draws the UML representation of the design in advance of the implementation or a machine deduces this from the existing source code, you can still benefit from a class diagram that will cut out the noise of the implementation itself. As long as we're drawing a diagram, why not have a common way to represent the concepts we use in software?
  - arethuza 11y ago
    If I wanted to see a class diagram I'd simply use a tool to generate a class diagram from the code - which I'd then know was completely up to date. Edit: DRY
    - wyldfire 11y ago
      Nothing about UML specifies its use in relation to when or how you wrote the code. Like I said, it's a false dichotomy to suggest that we can have source code or UML but not both. Yes, UML diagrams or any other design docs rot quickly. But like you said, we can generate diagrams after the fact too (or in lieu of ever writing UML diagrams before coding). > perfectly good way of representing the details of a system - it's called source code. ... > simply use a tool to generate a class diagram from the code Once you resolve to generate that class diagram you have a choice in how to represent it. UML is just one way, proposed as a standard way, to represent that visually.
jeremysmyth 11y ago
Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device. It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring. Perhaps some can, but when you consider many of the software artefacts we use daily (seeing as that's the context of this subthread), such as operating systems, virtualization platforms, or even good ol' clunky enterprise applications, you can't just wish the complexity away with a bit of hard work.
- arethuza 11y ago
  I don't think anyone is arguing that complex systems don't need some kind of up front high-level design - what we are arguing about is whether UML is an effective format for design artifacts. I'd be pretty surprised if any of the code that I am using to read this was designed with detailed UML diagrams.
- crdoconnor 11y ago
  >Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device. It wouldn't have been possible at all if the pieces that make it up weren't loosely coupled. >It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring. It's naive to assume that you can't. Loose coupling pretty much only comes as a result of extensive refactoring.
  - jeremysmyth 11y ago
    ...and one of the ways you can communicate such coupling is by diagramming the (complex) system's design. Google for "linux kernel diagram"[1]. It's quite well designed, displays loose coupling, high cohesion, and all the other things we like about good complex systems. If I want to dig in and start working on a module, I'd still have to understand the relationship between all the bits I work directly with (and probably some that are further away). Don't confuse loose coupling with low complexity. https://www.google.com/search?q=linux+kernel+diagram https://www.google.com/search?q=linux+kernel+diagram

EdiX 11y ago

The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design I've never found any need for a third, intermediate level of sophistication that sits between code and natural language + informal diagrams.

mannykannot 11y ago
In programming for science, engineering, finance or cryptography, you may also need the math, but UML does not help there, either.

jcranmer 11y ago

Your statement is only somewhat correct. What complex systems need isn't a single, complex design document but rather levels of simple, intuitive design. It's like OOP--the basic principle of OOP is that you can manage (but not eliminate!) complexity by sharding it into small-ish objects that only need to know about those whom they interact with. Similarly, in a large system, you'd want a high-level, very abstract design detail, and as you peer in closer to the code, you want increasingly concrete design. The problem of UML is that it tries to be the language of all these levels of design (and even different stages of design!), to the point that the highest-level design document is trying to be something so completely specified that there's no abstraction.