UML failed so here we have AML (Arbitrary Modeling Language)

UML is a failure. It failed for several reasons. Mainly, it failed because it falls into the cracks between technical people (developers, architects) and non-technical people (business analysts, project managers, etc). UML is too technical for non-technical people, and not technical enough for technical people. By this, I mean that it isn't really technical enough to do serious work on design by techies. At the same time, it's obscure enough to be mostly incomprehensible to non-techies.

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.

References
0
Average: 4 (2 votes)

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.

(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

I second Neal Ford's thoughts on this subject. Couldn't agree more!

Cay Horstmann replied on Thu, 2009/06/11 - 10:14pm

Well, I am glad someone is willing to go after the sacred cows. I used to obsess over "aggregation vs. association", but when UML sprouted more metamodels than you can shake a stick at, I realized that it was a lost cause. I am all for standardized class and sequence diagrams, but beyond that, I can't think of any part of UML that has caught on. One reason is...just try using the damn things. There is a lot of complexity that basically says you aren't allowed to draw what you want to. I know it must be my fault because I can't comprehend the metamodel :-(

Bruno Sofiato replied on Mon, 2009/06/15 - 6:15pm

It's all about how deep you would go on the design phase. It's sure overkill to drawn every diagram to every single element of your system, but it would not hurt drawing some activity diagram representing a complex business process, or a class diagram showing the class hierarchy of a system's plugin API.

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.