Skip to main content

The Unwanted Modeling Language

Posted by daniel on November 5, 2003 at 10:18 AM PST

UML 2 is due to be released in the Spring. Martin Fowler blogs that the acronym may more accurately stand for the "Unwanted Modeling Language".

In Projects and Communities , the Java Tools points to Martin Fowler's article on disdain for UML. Earlier Fowler wrote that there are three modes of UML users

  • Sketchers who use UML for sketching in two ways:
    • forward sketching where "you rough out some issues in code you are about to write, usually discussing them with a group of people with your team. Your aim is to use the sketches to help communicate ideas and alternatives about what you're about to do. "
    • reverse engineering where "you use sketches to explain how some part of a system works. You don't show every class, just those that are interesting and worth talking about before you dig into the code."
  • Blueprinters who strive for completeness where the sketchers selected key parts of the code that need communication. Blue printers are documenting the system either in advance to completely specify all of the design decisions for programmers to follow or to reverse engineer code to show every detail about the code in UML diagrams.
  • MDA advocates who take the idea of blueprints a step further and want to use UML as a programming language. "Tools can take the UML diagrams you draw and compile them into executable code."

Martin writes that the sketchers did not take an active role in the UML 2 committees and so their needs were ignored in the new version and the upshot is that sketchers are not very impressed with UML 2. Further, much of the work in "UML 2 was to formalize and complete the UML to support MDA; primarily for UmlAsProgrammingLanguage (and secondarily for UmlAsBlueprint). [ ... But] disdain for UML is pretty rampant amongst theUmlAsProgrammingLanguage community too."

So what's the future? On the one hand it sounds as if Martin worries that we will end up with silos that can't port the UML. He concludes:

I hear more mutterings from sketchers about the growing irrelevance of UML standards. In the MDA community it seems that we will see a rise of tools all using different subsets of the UML standards, probably extended subsets using profiles. What will this mean for the UML as an interchange mechanism between MDA tools? Some people are saying that the UML will not be the interchange mechanism - that the OMG MOF will play that role. This is all very well, but will users of MDA tools get portability in practice, or will each tool turn into its own proprietary language?

In Also in Java Today the UML discussion continues with Granville Miller's article The Latest Status of Version 2 of the UML . Although Miller notes problems with the upcoming UML 2 release, including the issue of compliance. "All UML 2.0 implementations are required to implement a single compliance point, the Kernel. The other thirty-seven compliance points (including Use Cases) are currently optional. However, by looking at these compliance points for your favorite UML modeling tool, you will get a complete understanding which model elements are supported and to what degree."

Supporting the kernel isn't so easy as it is a bit of a moving target right now. As Randy writes "coordinating the finalization among three independent specs, each with its own independent finalization task force [Frank]. The kernel of each of the three specs (Infrastructure, Superstructure, and MOF Core) is shared. As one committee finds problems in the shared part, the changes must be shared with the others. This has been equivalent to the problems that a development organization sees when working on multiple, parallel development streams."

Our other link is to Keld H Hansen's article explaining Handling Messages, Errors and Exceptions in Struts 1.1 . The techniques show you how to get useful information to a client of a Struts based application. This eight page tutorial explains the handling of messages using ActionMessages classes to get data into and out of messages. It ends with an example of exception handling in a Struts 1.1 app.

In today's featured Weblogs , Chris Adamson follows up on his last entry on Java GUI builder tools with Toasting Java GUI's. Chris doesn't think that it is "he lack of better GUI building tools that has held back Java on the desktop? I don't think so - I think the hard part of delivering a Java GUI has to do with things like threading and custom painting and delivering a polished, intuitive user experience... things that a GUI builder doesn't address." His experience echoes many of ours

Sure, you could save some time laying out your GUI with a visual tool... but is that really the hard part of developing Java GUI's? In the last couple of years, I've done complex GUI's, and yeah, I blow half a day on 500 lines of GridBagLayoutcode, but the parts that seemed challenging to me were some of the parts I did myself - multi-line list labels with icons and different fonts, a historical performance widget that rendered itself as a bar with colored segments representing performance over a certain time-slice, a JTree that supported drag-and-drop to its contents by tracking the drag event's (x,y) and repainting the node underneath based on whether it could accept the drop, etc.. A GUI builder isn't going to help with that, and I don't think those kind of tasks are any easier outside the Java world. Sometimes doing Neat Stuff requires getting your fingers dirty.

In today's News Headlines :

Registered users can submit news items for the href=""> News Page using our
news submission form.
All submissions go through an editorial review by news director Steve
Mallet before being posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java Events:

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission form.
All submissions go through an editorial review before being posted to the

This blog is delivered weekdays as the href="">Java Today RSS
feed. Once this page is no longer featured as the front page of href=""> Java Today it will be archived at href=""> You can
access other past issues in the href=""> Archive.