Over the course of my education career (by which I mean receiving education, not partaking in education as a career), I've studied UML in four different courses. Or is it subjects. In Australia they're one thing, in the United States they're another thing, and Singapore tends to drift between the two. So much so, that I've already forgotten which to use. Of course, the adequate one is subject to opinion, as a matter of course.
Golf courses
I've studied UML in high school, at two universities, and once in industry as part of a course. There's that word again. With an exam on much of UML tomorrow, I've been burying my face in them once again, plowing through all these different examples, coming up with alternatives, refining and redefining and refining.
As someone who loves drawing diagrams, flow charts, mind maps and other such visual stuff, UML is a natural fit for me. Or at least, you would think so. To me, it has several problems.
And here are those problems
- My first lecturer in Adelaide said "the great thing about standards is everybody has them". My friend Andrew Cox from the same city has issued similar sentiment, as has my father in an entirely different industry. Needless to say, "standardised UML" no more exists in practical, real world terms than Office Open XML. My high school, workplace and universities all have their own ideas as to what constitutes UML, it's syntax and it's applications, and they're all rigourously enforced.
- Even the software I used is different, from basic tools like Dia and Visio on one end, to IBM Rational software on the other. Unlike, say, a high level programming language where code is portable provided you have an interpreter or compiler, the "code" these tools have you write in are largely incompatible, unless you consider manually transcribing them between tools or using an intermediate format to be acceptable!
- UML's strict syntax make diagrams less fun! As soon as you introduce rules into something, you limit creatively. While a standardised approach (or at least, the pseudo-standard we have now) ensures those who read and use them can pick them up fairly easily, it also means those attempting to express the functionality, purpose and design of a system are limited by the ideas of someone else. I adore mind maps and flowcharts and use them for practically all my study, so I suppose this is more of a gripe with being turned into a tie wearing, white collar cubicle dweller than anything else ;).
- UML attempts to get around this limiting factor by having a suite of diagrams, each tackling different aspects and stages of the modelling process. While this provides reinforcement along the different stages of the design process, it also introduces redundancy, with much of the information being repeated over, and over, and over again in different ways.
- While UML promises to reduce confusion, often times it adds another layer of complexity. For large projects this may be necessary, but for smaller ones I feel as though it's often more trouble than its worth. I also feel somewhat uneasy about developing a solution to a problem based on a model, rather than the feedback directly.
- Finally, and this is perhaps the most concrete criticism I can think of, UML was designed around OOP principals, not programming languages or DBMSs. Often times this means concepts in UML don't translate perfectly into languages or schemas. This introduces the requirement for interpretation, and it's as soon as you do that that you introduce inconsistency, uncertainty and potential confusion. Like interpretive dance, which I can't even do.
- Insert ranting about "design by committee" here!
But but but...!
I can already picture the responses I'd get to these concerns by those who use UML for a living. Even standards that are only loosely enforced across industry and academia are better than no standards at all. Strict syntax ensures consistency. While each of the diagrams in the suite may have redundant information compared to the others, different stakeholders and developers would look at only a subset of them tailored to their needs, so that would be less of a concern for them. Work isn't supposed to be fun, and you can still be creative by colouring inside the lines. Abstraction makes implementation easier.
I understand these points, even if I can't entirely appreciate them at this stage. To be honest, I've been more at the development stage of the cycle than the requirements gathering stage. Still, I worry that buried in the hype and promises, there's a lot of hot air and solutions in search for problems in UML. A quick net search shows I'm not the only one who thinks this, not by a long shot!
UML is better than perhaps other modelling solutions we have at this stage, and I can churn them out and understand them fairly well... or at least as well as someone in my position could! However, there's still far more work to be done in bridging the gap between requirements and development. Whoever figures out how to do it better will be a very, very rich person.
I'd suggest taking a long, hard look at the KISS principle. That sounded terribly, terrible wrong for some reason.
