Evaluating UML (Unified Modeling Language)

UML is a way of modeling the design of software applications before coding. It uses specialized diagrams and flowcharts to manage large software projects. [1]

I studied it at length last summer for the purpose of embarking on a large data mining project, and because I wanted to be able to track what was going on between work sessions. When one has thousands of lines of code that are sometimes left untouched for weeks at a time, it becomes nearly impossible to review and understand what one was thinking during the last session. In essence, it's like receiving the code from somebody else, since what was being done earlier is so quickly forgotten. Even copious commentary within the source code itself has limited value, since often what seems obvious at one time becomes mysterious at a later time.

Now that I've had a few months to work with UML, I've formed some opinions about it, which I'll eventually share. But first, let me review what some professional programmers wrote on Slashdot [2] about UML. I noted therein that many were not impressed with UML. The reasons were varied, but the essential positions were as follows:

1. UML is merely a bunch of pretty diagrams that give power-point addicted managers lots of excitment but give over-worked programmers yet one more layer of interference in the project development cycle.
2. UML effort is usually wasted in the end, since by the time the project gets to the coding stage, the after-the-fact discoveries about design and performance negate the earlier UML design work.
3. UML is an extraneous activity, since good coding practices pretty much carry along project development anyway.
4. UML is a fine way of avoiding the hard work of actual coding. There were a few other minor issues, but these four seem to capture the bulk of the complaints.

It is no accident I've placed the complaints in the order that I have, since they roughly reflect the chronology of the development cycle. I'm not so much interested in giving rebuttals to 1-4 as I am in remarking about why programmers might hold the negative views that they do on UML. For the record, I do not agree with the comments, but that doesn't mean such comments are necessarily misguided either.

First, it hardly takes a sociology study to see that many programmers have a professional psychology that exists somewhere between libertarian and anarchist. Accountability to managers who may not know the first thing about coding structures is highly irritating to programmers who regularly rule the kingdom of algorithm/data structure abstraction from within the fortress of their own heads. (Sometimes this goes under the moniker of "taking ownership of the code".) There is something like an old-school social contract theory operating here: The manager agrees to leave fingers out of the programmer's structures, and the programmer agrees to meet design specs. Whether it meets explicit specs--that's the manager's problem. Whether it has bugs--that's the coder's problem.

UML violates this social contract. Because some of the diagrams are so intuitive, even nonprogamming-trained managers can get some idea of how a project gets designed, and since, as a discipline, businesses (and business training schools) typically use organizational diagrams and flow diagrams, such managers can quickly pick up on the aesthetics of efficient flow and balanced breakdown of algorithm/data structures. This allows nonprogamming-trained managers to now ask questions that are much more direct and difficult, and which (per above old school social contract view) seems to violate the professional psychology of programmers. Think of it this way: If a programmer liked using UML for his own purposes, it would merely be a question of style, much like the selection of a text editor or IDE, and nothing important would ride on complaints against UML. What is really at issue, I think, is a breech in the walls of programmer privacy. (As a side note, if one finds, as I have, that UML offers distinct advantages to exclusively personal coding development, then the use of UML is unquestionably advised.)

Second, UML effort need not be wasted in the end by after-the-fact discoveries about design and performance issues. This is the advantage of automated code generators. With such generators, one does not change the code, but the CASE tool designs that produce the code; hence, just as newly discovered design issues would otherwise be re-coded where needed, likewise new issues can be re-generated by the CASE tool where needed. The issue is one of merely deciding up-front to stick to the development method (in this case a UML code-generation tool). If the UML tool produces bad or incomplete code, that's not a UML problem! It's merely a tool problem. (In my own case, I was mostly interested in program structure, and not in code generation; thus I sought ease of printing from a no-cost tool. I found UML Pad [3] to work best for me, since it was simple to use and was not bogged-down by a Java machine and/or by crippleware.)

Third, it is claimed that good coding practices pretty much carry along project development, so UML design is extraneous. An awful lot rides on the particular circumstances of this complaint. a) Is it true that most programmers use good coding practices? For those that don't, UML would indeed improve their coding practices, thus it is advisable and not extraneous on that basis. b) Is it true that all projects are manageable by good coding practices? The answer is clearly No, since there would have been no drive to invent, or reasons to use, UML if good coding practices were sufficient for every project. Projects with hundreds of thousands of lines of code need their own cartography for explaination and for task assignments. UML suffices for this task. c) Is software project development merely about good coding? Of course not, for there are also the matters of robust documentation and client explanation as to what the project is and does. UML tools can manage and generate these other components of project development, ones which are otherwise acknowledged as very labor intensive and burdensome. (As I have found, and if for nothing else, automated software documentation is very important for reference in maintaining and modifying a software project. Many UML tools do this and do it well. Also, when I'm presenting what I'm working on at a particular time, class diagrams are very intuitive for tracking and reporting coding progress; thus, they can be sent to nonprogrammers who have connection to the greater implementation of the project.)

Finally, UML modeling is perceived as a fine way of avoiding the hard work of actual coding. This is probably a perception of those who have not used UML at length or well (or both). Again, if one committed to a tool which has code generation and document generation, then much of the time spent modeling just is time spent coding and documenting; hence, UML contributes to the work of a software project. Moreover, often times the work of actual coding is "hard" because there has not been sufficient modeling either to conceptualize the project to begin with or to avoid unexpected programming bugs. Thus, and in my own experience, UML indeed avoids the hard work of actual coding -- yes, by merit of making coding easier to manage overall.


REFERENCES

[1] A quick history and overview can be found under "Unified Modeling Language" Wikipedia (Accessed July 21, 2006)
http://en.wikipedia.org/wiki/Unified_Modeling_Language

[2] "How Do You Use UML?" Slashdot (Accessed July 21, 2006)
http://developers.slashdot.org/article.pl?sid=05/01/02/1820207&tid=156

[3] "UML Pad" (Accessed July 21, 2006)
http: //web.tiscali.it/ggbhome/umlpad/umlpad.htm

_