UML failed so here we have AML (Arbitrary Modeling Language)
This wasn't the Three Amigos fault. They did quite impressive work on the meta-model aspect of UML. It was defeated by two forces. First, the fundamental problem lies with the amorphous nature of software itself. Coming up with a really expressive graphical notation is hard. Most developers know enough to draw boxes for classes and open-arrowheads for inheritance, but don't get much further into the UML specification because it gets quite convoluted (especially if you start looking at the later generations of UML, with Object Constraint Language and its ilk).
The second failure reason is the implicit assumption that you need (nay, must) design all the classes and interactions before you start writing code. Big Design Up Front is a failed technique in almost all software development. The only exceptions are systems that are truly life and death. One of the reasons for the outdatedness of the software on the space shuttle lies with the fact that they have very long iterations. In other words, they are willing to say "once this date passes, we will make no changes to the design of this system. Period." While most business software could make this statement, it ill serves the business. Business processes change like the weather, and you need software that can change just as readily. I don't come to this discussion as a dilettante: for a while, I worked for a company that was a Rational partner. We did the training, and we built software based on the Rational Unified Process. We even had some successes. But it didn't take long for us to realize that the upfront design didn't serve our clients because it hampered the kinds of changes required by their business.
Most developers I know use AML: Arbitrary Markup Language, usually consisting of boxes, circles, and lines. When a given developer writes on a whiteboard, they write in their own version of a diagramming language. It's a shame that we don't have an industry wide diagramming language that everyone feels compelled to use, but that's the reality in most places I've been for the last 5 years. But, having said that, I'm a fan of AML, because it cuts down on irrational artifact attachment: you have nothing except the last 5 minutes invested in the diagram, making it as transient as possible. Transient artifacts are good because you're willing to throw them away, preventing them from becoming a part of the documentation for your project once the actual code has migrated away from that initial stab at design. Out of date documentation is worse than none at all because it actively misleads.
Neal is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. Before joining ThoughtWorks, Neal was the Chief Technology Officer at The DSW Group, Ltd., a nationally recognized training and development firm. If you have an insatiable curiosity about Neal, visit his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com. Neal is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone.
- Login or register to post comments
- 1704 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)















Comments
Reid Atherton replied on Thu, 2009/06/11 - 12:44pm
Oh, for the love of...UML only fails depending on how you (mis)use it to accomplish a particular purpose such as MDA. (And by the way, does AML find the mythical point of "techie but not too technie"?)
Big Design Up Front isn't a guaranteed anti-pattern just because a developer draws a standardized diagram. What is it in UML's specfic recommendations for boxes and arrows that somehow force a developer to write an inflexible design? Is it really a given that modeling and picturing your code objects beforehand will result in software that neglects the need to accomodate change/extension? The right diagrams (and not too many...) can be great for checking that the object design is SOLID.
Having said that, I fully agree that becoming irrationally attached to your UML is indeed counterproductive, and all the convoluted bits of UML you mentioned aren't needed 90% or more of the time. The advantage of (the useful bits of) UML is in not having to explain the meaning behind the ad-hoc layout in your AML.
Dean replied on Thu, 2009/06/11 - 1:06pm
Cay Horstmann replied on Thu, 2009/06/11 - 10:14pm
Bruno Sofiato replied on Mon, 2009/06/15 - 6:15pm
Chris Dempsey replied on Mon, 2009/07/06 - 4:06pm
I couldn't agree with Neal more. I've abandoned the prescribed nature of UML for a more natural and transient "whatever-works-to-get-the-damn-idea-across" notation. I find so few people on the street that understand the UML diagrams themselves let alone the subtles of the notation itself.
Oddly, I've also found that what isn't said in a UML diagram gives people as much trouble understanding an idea as what is in the actual diagram itself.