Published on Architects Zone (http://architects.dzone.com)
UML failed so here we have AML (Arbitrary Modeling Language)
By nealford
Created 2009/06/11 - 8:30am

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.




[Non-text portions of this message have been removed]