On Using UML: Replies to Comments

A few posts ago I talked about using UML for communicating designs and architectures. This post has my replies to some of the comments.

I warned against using UML with non-technical people and someone (guest) said:

I have had excellent luck sharing some UML diagrams with non-technical people. For example, simple use case diagrams are a great way to show what the system(s) will do, and who is expected to interact with them. Business people of all stripes understand them immediately.

I am not saying don't use UML for non-technical people. I was merely pointing out that you should be aware that non-technical people might not understand them or even worse understand them differently.

Barry Mundi said:

What with articles around the place describing the dearth of use of UML, and my experience within the software engineering industry, I am not surprised people are asking questions like this. The whole opensource community seems to run sans modeling. Most developers have trouble understanding class and sequence diagrams, let alone the other classes of diagrams in UML. Often, if you see a class diagram it has been reversed engineered by a tool rather than the meat of cogitation. Little architectural representation is seen. Some of my colleagues and I are opposed to generally calling everyone a Software Engineer. Developers can't or won't model effectively, given either their imperatives or their bent -- or lack of it. What with Jacobbson's comments about "accidental architecture" being "ok" and the JVM now coming with behavioural journelling -- to allow accidental discovery of your software's purpose -- why do we bother with the pretence?

I don't think that not using UML = not doing design. UML is a good way to express design (esp. UML 2.x which is more expressive) but it isn't the only way and it isn't always the best option (e.g. what about layer
diagrams almost everyone uses, or BPM, business rules, UI etc.)

Regarding developers that can't model -- while not everybody is a good abstractionist, if I see anyone on my team who is completely incapable of doing design (TDD, formal model or otherwise) than he/she does not have a place in my team. I think the days of spoon feeding developers with detailed design documents were (or should have been) over years ago. People who are incapable of thinking about the consequences of the design/code they write will produce poor quality code.

Regarding "accidental architecture". I agree that this is wrong for anything but the most trivial projects. If you have "accidental architecture" don't be surprised when other accidents will happen to your code.

Another guest said:

...One of the main reasons that UML is becoming more attractive, especially to smaller companies, is not all because of a growing general awareness. It is because of the availability of much better and more affordable tools than what was available back then. I am certain you already got your hands of Enterprise Architect (SPARX), the phenom tool that is gaining grounds very rapidly because of its price to quality ratio -- check it out if you haven't.

To your point gentlemen, it's not only what you use UML for, but what you COULD use it for? There is a natural evolution in maturity that an organization can go through in order to move from 'charting pictures' to 'clear communication', then to 'UML for formal specification', then to using UML for expressing model patterns and metamodels (can't imagine doing that without a notation of any sort), and finally, mature to a model driven environment where you are generating much, much more, than just skeletal code.

The promise is there (we have seen it), what is needed is awareness.

Regarding Sparx Enterprise Architect -- this is definitely one of the best UML tools out there. I've been using it since version 4.5 and now with version 6.5 it is even better (by the way it goes beyond UML with diagrams for describing WSDLs or add-ons for SysML etc.). I finally managed to convince our System Engineering and Processes Group to switch everybody to EA over using (the dreadful) XDE.

Regarding the potential of UML for formal specification and MDA scenarios. I used to criticize Jack Greenfield and Keith Short for not basing their Software Factories Initiative on UML 2 (which is extensible) -- but thinking about it I do agree that there is no merit with sticking with UML over to going with DSLs since you would have to annotate (with tagged values and stereotypes) your model so much it would be much sensible to create a specific compact language.

By the way I think the so called "software factories" the patterns and practices group are producing these days are still very far from the vision of software factories that Jack and Kieth painted. The "real" factories are still very far away in my opinion.

Lastly, Duane Strong said:

You mention using the UML as sketch is not "fully compliant" UML. I'm not sure that is correct. To me compliant means that you are simply using UML in a way that complies with the rules of that language. This does in no way mean that you also have to fully document every detail of the model. In my experience deciding what to elide from the diagram is much more important that deciding what to leave in....

I did mean compliant in the sense of complying with the rules. If I would think that putting a port on a class would somehow make my diagram more clear to my audience I would do that. Also I wouldn't bother with the trouble of making sure code can be generated from the diagram.

I agree with you that there is no point in having diagrams that show each and every detail of the underlying code. The whole point of having the model in the first place is to raise the level of abstraction so that we have a better chance of understanding what is going on.

This is also a good opportunity to thank all of you who take the time to comment on my posts. It is nice to see someone out there actually reads this stuff :-). Also note that that the comments system on on this blog does not notify me when there's a new comment, so if you want to make sure I see your comment also copy my email (arnon@rgoarchitects.com )

Posted by Arnon Rotem-Gal-Oz at 04:22 PM  Permalink