How often do you use Formal UML?

Question

I used ad-hoc MUML (made-up modeling language) to design and explain system fairly frequently. It looks similar to UML and tends to be pretty well understood.

However, I've had a professor or two that harped on the use of strict, formal UML, as close to the spec as possible. I always suspected that strict UML wasn't really as common as they claimed. So, how 'bout it- how often do you actually draw out complete diagrams that use all the proper line endings, multiplicity, member type symbols, etc?

Answer 1

Never.

Heck, it's been years since I last created any UML. Line diagrams on whiteboards and scraps of paper don't count.

In fact, we just removed the sole UML question from the guide we use during interviews, because none of us really cared about the answers.

Answer 2

I use just enough UML (in terms of both the types of diagrams and the content of the information in the diagram) to get my point across to allow myself or someone else to implement the system or subsystem. And the only reason I use UML is because its a widely known set of symbols that each mean something very specific, so there's no ambiguity - any software engineer should be able to look at the diagram and understand what I'm trying to say about the system.

Answer 3

Ironically, UML is supposed to be flexible.

In the real world, it is not supposed to be a pedantic exercise in doing it one right way. It is about effectively communicating and documenting a system/process/idea.

To answer your question, I'm with the others. I've never fully utilized full-on, formal UML.

Answer 4

I used UML very regularly for about four years for a product that generated all (most) of its code skeletons from Rational Rose.

The last five years there have been more of "boxes and arrows" mostly invented on the spot and usually enough to get the general idea across. Formally correct UML only a few times during this time.

Answer 5

However, I've had a professor or two that harped on the use of strict, formal UML, as close to the spec as possible.

Ask your professor when was the last time he used that approach on a real system. Seriously.

I try to be as formal as possible when it comes to UML, but only if/when it makes sense. Zealots on both side of the spectrum (from cowboys to uptight formalists) fail to understand that.

There are contexts in which a less rigid approach (like the one you personally use) is the best approach to follow. A good example is for small systems or changes, where requirements are small and not fully defined; the group in charge is efficient and effective; it is more important to get it out than to get it perfect. It is done iteratively and some deficiencies are acceptable.

Or maybe you are in a stage where you are doing guestimation and sketching as opposed to a full formal modeling phase. Those are examples that would come to mind.

At other times, you need a rigid formal UML approach. For example, you might be contractually bound; you have a very large number of developers in multiple teams (possibly distributed); the scope of the project might be in years; it is a very large system (including software and hardware components); the cost of failure is high, etc.

At other times, you have to use something else instead/in addition to UML (actual mathematical formal models like petri nets, CSP or temporal logic.) Example of this are real-time systems, systems where failures are catastrophic (medical devices) or where you are contractually bound (.ie. as in Europe when developing transportation systems.)

It all depends on the circumstances and what we expect to gain from each approach. A professor that harks on sticking to formality is simply being a blind zealot. The world of engineering is not a black-n-white, right/wrong dichotomy. It is a world of intelligent trade-offs.

If you are intelligent enough to use a casual, informal model in a manner that is effective and appropriate to get the job done, then so be it. By the same token, you will be expected to recognize when NOT to use an informal approach and/or when NOT to use a formal one.

Having said that, you have to play it by ears with professors. Give them a bone so that they give you a grade, and if that means to finally bow to their zealot mantra, that's fine. You know what works for you, and hopefully, you will know when to use what and how in the real world.

Answer 6

As part of my PhD research, I studied how experienced designers use UML in design collaborations (Although in artificial settings).

My findings were that UML metaphors and notations are borrowed, but there is little adherence to the strictness of the tools.

Later on, some models may be iteratively transformed into more strict UML, often when a demanding CASE tool is involved for the purpose of code generation.

The usual caveats of academic research apply, of course :)

A link to the paper abstract and the paper itself (if you don't have ACM access).

Aside from that, I highly recommend Ambler's "Agile Modeling".

Answer 7

We use formal UML for code generation of a hibernate ORM. Most other things are informal or white board. It's only important for us with code generation because the lack of formality would break it.

Answer 8

It depends upon the industry that you are in. If you work for customers that require frequent technical reviews (eg. PDR, CDR etc..) then they prefer some sort of standardization rather than ad-hoc notational systems. In particular government work. It prevents miscommunication and the initial 15 minute explanation of the notation that you invented.

Also, just because you are using UML doesn't mean you have to dot every i and cross every t according to the standard. That's only if you want to do some sort of auto code generation/execution. I don't know anyone who has done that for more than 1 project.

On the other hand, if you are only working for your company with a team of your own developers then who cares what notation you use. Although, if you choose the right tool then it can be a real time saver.

With all that said, you will find it hard to get by in some industries without being able to design using UML. In other industries, you'll never see it.

Also, I think you'll also find a correlation between those industries that require the design to be right because the costs of correction are correspondingly high as being heavy users of UML; versus industries that the costs of design corrections are little more than documentation/code changes as being places that UML is probably never used.

In regards to the original question. Most colleges tend to gear the training of their students for the companies that recruit their students most often. If you professor thinks that UML is important then it would not surprise me that many of the businesses that recruit from your school use UML. Thus, you should learn to use it.

Answer 9

UML is painful if you also try Model Driven development. I mean that UML is a very useful graphical notation only and everything else is useless. I don't spend on modeling but use UML every day in order to create the structure of my projects. What I do is to quickly draw a basic usecase diagram at requirement levels, then immediately switch to class diagrams. I add requirement traceability between usecase and class diagrams. My class diagram also create code because it is live synchronized. No tag in the code all model is saved in the UML model which is mapped to the Java project.

I create the skeleton of my application with few class diagrams, then switch to code. Once I finished the code I merge it with the model. It is a kind of iteration between code and model where the code runs the model. So my class diagrams give me a higher level of abstraction and my code while my code gives me my business logic implementation (e.g. methods).

UML modeling requires less than 10 minutes per day, which is done when I need time to think what I need to develop and how.

UML is great, fantastic and really useful but model driven development is useless !!

Answer 10

I just dropped out of my supposedly top-tier college (at least temporarily) because of their rigid insistence on excessively time-consuming visual modeling activities, forum chores, excessively redundant soft skill stuff that anyone who grew up around computers or has ever leered thoughtfully towards a user-interface would get well-enough that the thought of going deep into debt for it would make one want to break things in utter frustration.

I had to choose between learning what I saw entry-level and junior-level jobs demanding and what hoops CES sets for the university's ABET accreditation, which causes decision-makers to play dumb when there are glaring problems with time-constraints and unrealistic expectations that a PERT assessment would reveal. The university does not practice what it teaches.

In my opinion, the Unified Process has a lot of merit, but the entire practice of minting visual artifacts, what ever the modeling language is a bit ridiculous. An iteratively-refined document containing a seriated list, such as might be produced with Word, Workflowy, Evernote, OpenOffice, or name a word processor is perfectly capable of documenting what is required by the Unified Process. Something this plain-jane can be easily worked on by multiple users, version-controlled, and if one chose the right tool to do it in, a team could even work on it at the same time. This is so much more easily done than when UML seemed like a necessary mode of uniting the hordes.

Answer 11

When I read about UML I tried this on all problems that I was to solve in my C++ course. Fortunatly one of the first examples I tried was to describe a linked list.
Didn't work.
That said, coupled with a good modelling process UML is useful. Just because it is for better or worse a standard.
I would love to see a description language of template meta programming. I think that would help a lot in understanding what is going on in <<<> > >-land

Answer 12

If I'm documenting a system that we've implemented, then I try to lay it down with full formal UML. But the rest of the time, I only use as much as is necessary to get the idea across. I also find myself using more DFDs than UML, as they seem to be more appropriate for the systems we're designing lately.