3 ms·

Graphical modelling is an incredibly powerful tool, and it saddens me that UML is not valued more by hackers. I suspect one of the reasons it's not used, is tha

by biofox 13y ago

Graphical modelling is an incredibly powerful tool, and it saddens me that UML is not valued more by hackers. I suspect one of the reasons it's not used, is that people simply don't need it most of the time. When I started in software I was apathetic about UML, in fact I thought the whole thing was a bit silly. I used the occasional class diagram to communicate an idea, but I could never see the point of modelling. Most of the time I know what needs coding and have a good intuition for how to implement it; but with experience, that has changed. Only twice in my life have I had anything close to a religious epiphany: 1) the first time I tried psychedelics, and 2) the time I finally 'got' UML: I was faced with an enormously complex software project that was far beyond my level of experience and skill set, and I didn't have the faintest clue where to start... it was the sort of project that makes you feel slightly terrified and incompetent. After several false starts, I realised I needed to try a different approach, so out of desperation I dug up an old college textbook on systems analysis and tried to design the entire system on paper away from the computer. I started with a use case diagram, then numerous class diagrams, then sequence diagrams, then activity diagrams. In a matter of hours, I'd nailed the ENTIRE project, without straining my brain the slightest. I was ecstatic! It felt like I'd just acquired a superhuman power or a secret black art -- I'd transcended the capabilities of mere mortals, into the realm of gods! In that moment, I saw the essence of UML, and it was power! As nerdy as it sounds, it was certainly one of the most profound and memorable experience I've had -- taking something I knew moderately well (UML), and seeing an aspect of it that I could never have anticipated, and using it to solve a problem that was completely beyond me. Saying all that, I should qualify that I'm not a UML fundamentalist, nor do I think everything should be modelled. People often criticise over-abstraction and "architecture astronauts", and rightfully so. There is an inherent danger to modelling, but if you're an experienced coder (and more importantly the person who's going to be implementing the designs, so as to stay grounded and realistic) then there's immense power in abstracting away the code and the limitations that come with "thinking in code". Under the right conditions, modelling enables you to see the essence of the problem and derive a well-structured solution. That, at least, is my opinion. ...and on the topic of Agile doing away with the need for modelling: the whole point of modelling is to enable fast iterations. It's amazing how fast ideas can develop with just a whiteboard and some thinking space. Why waste time coding?

biofox 13y ago
I should also add that I think a lot of the criticisms of UML itself are fair. I'm talking exclusively about using it as a problem solving tool before the implementation stage. I do wish there were better alternatives for graphically tracking and documenting large code-bases... or even generating UML diagrams for that matter.
- bane 13y ago
  One of the problems is that there's an awful lot in the way of "Architecture Astronauts" who sit down for a few days and build (in UML) a brilliant and complex system design that has no grounding in reality. I remember vaguely one argument with an EA who had built a very nice looking system blueprint in UML, who didn't understand that several of the ways various components needed to interact either required very large amounts of computing power or an algorithm that didn't exist. "But I carefully looked at that in the sequence diagrams here and here!" In the usual best case, when the implementation starts to diverge away from the UML (as it usually does), it becomes nightmarish to keep the UML synched to the codebase. It's usually just easier to wait for the code to freeze, then go in and document what's there...which of course is not really the point of UML.
davesims 13y ago
I agree with everything you say, this has been my experience as well. UML, even a lightweight truncated version of it, is incredibly powerful. The graphical syntax is not that hard to understand. The biggest benefit to me has been that it expresses object relationships, imo, better than code. At a high level it's much easier to visualize fundamental design mistakes or solutions when object relationships have actual shape. OOP, for better or worse, was designed to model real world objects, actions or relationships, and graphical shapes, rather than sequential instructions, express that best. I've found class diagrams very helpful for visualizing complex domains, and sequence diagrams extremely helpful when modeling service architectures especially. I understand why many coders avoid it, but I also think it's unfortunate that UML has the reputation it does. I read Martin Fowler's UML Distilled (and I still recommend it) years ago. It made sense to me then, still does.

by biofox 13y ago

biofox 13y ago

I should also add that I think a lot of the criticisms of UML itself are fair. I'm talking exclusively about using it as a problem solving tool before the implementation stage. I do wish there were better alternatives for graphically tracking and documenting large code-bases... or even generating UML diagrams for that matter.

bane 13y ago
One of the problems is that there's an awful lot in the way of "Architecture Astronauts" who sit down for a few days and build (in UML) a brilliant and complex system design that has no grounding in reality. I remember vaguely one argument with an EA who had built a very nice looking system blueprint in UML, who didn't understand that several of the ways various components needed to interact either required very large amounts of computing power or an algorithm that didn't exist. "But I carefully looked at that in the sequence diagrams here and here!" In the usual best case, when the implementation starts to diverge away from the UML (as it usually does), it becomes nightmarish to keep the UML synched to the codebase. It's usually just easier to wait for the code to freeze, then go in and document what's there...which of course is not really the point of UML.

davesims 13y ago

I agree with everything you say, this has been my experience as well. UML, even a lightweight truncated version of it, is incredibly powerful. The graphical syntax is not that hard to understand. The biggest benefit to me has been that it expresses object relationships, imo, better than code. At a high level it's much easier to visualize fundamental design mistakes or solutions when object relationships have actual shape. OOP, for better or worse, was designed to model real world objects, actions or relationships, and graphical shapes, rather than sequential instructions, express that best. I've found class diagrams very helpful for visualizing complex domains, and sequence diagrams extremely helpful when modeling service architectures especially. I understand why many coders avoid it, but I also think it's unfortunate that UML has the reputation it does. I read Martin Fowler's UML Distilled (and I still recommend it) years ago. It made sense to me then, still does.