Graphics, Text, And Source Code
On the left, we have words of wisdom from Grady Booch and friends. On the right, we have sage advice hatched from the “gang of four“. So, who’s right?
Why, both groups are “right“. If all you care about is “recording the design in source code“, then you’re “wrong“…
If you’re a software “anything” (e.g. architect, engineer, lead, manager, developer, programmer, analyst) and you haven’t read these two classics, then either read them or contemplate seeking out a new career.
But wait! All may not be lost. If you think object orientation is obsolete and functional programming is the way of the future, then forget (almost) everything that was presented in this post.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
I think UML is pretty much useless. If a UML diagram has enough detail to tell you THAT much about a program, you may as well look at the code. Plus, the OMG is in charge of it, which automatically means that it is a gigantic out of control pile of crap that no one can possibly implement. Reverse engineering into UML, in my experience, is also pretty useless as a means to understand a code base. If well-tested common libraries (in the form of an application framework, perhaps) with well defined APIs are used to build a system, a group will have a better common understanding of a system or set of systems.
I’ve recently been looking at DSM/DSL; IMO a much better way to help customers and programmers develop software. It helps raise the level of abstraction, which UML does not do AT ALL; UML is essentially just another general purpose language. Look at MetaEdit+, for instance. But it doesn’t take an expensive tool. Martin Fowler has a recent book about it (http://www.amazon.com/o/ASIN/0321712943?tag=betteraddons-20) that shows lots of techniques.
Thanks for your passionate input Mark. Any tool, including UML, that represents the source code at a level of understanding/viewing above the code (which is itself a model of a specific solution) raises the level of abstraction by omtting a myriad of details, no?
With UML, you can use as much notational detail or as little as you need to communicate and reason about “meaning and intent” to yourself and/or others. You don’t need an expensive compile-ready tool to use UML. Visio or pencil/paper can do the trick.
Martin Fowler uses UML class, state machine, and sequence diagrams extensively throughout his DSL book. He “bends it like Fowler“, of course :).
Sure, UML is useful for high-level communication of inheritance and ownership (I use it that way, as generated by Doxygen mainly, sometimes with Visio). Activity and sequence diagrams are cool, but to specify every possible path through code, including error conditions, is extremely tedious, and I can’t see a reverse engineering tool helping with that. The idea that code can be generated from UML, or that UML can be executed, is not, I think, very viable and kind of pointless, and so it doesn’t really raise the level of abstraction. It’s just C++ (or Java, C#, whatever) in boxes.
Looks like we basically agree, from the post you referenced above.