4 ms·

"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

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