Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
Great question. Your professor's attitude is possibly a symptom of the current disconnect between some of the skills being learned at college & the skills required in the "real" world. –  Paddyslacker Sep 6 '10 at 6:59
@Paddy, the aim of education (especially in places where "professors" do the teaching) is not to use only skills that are required by real world. –  Pavel Shved Sep 6 '10 at 19:34
In principle you are right @Pavel, but at the risk of going off topic, I'd like to clarify my point. I don't think there are any people with a degree in accounting who cannot count, but there are people with Computer Science degrees who cannot code. There have been several questions on Stack Overflow regarding this. Rightly or wrongly, there is often a disconnect between the skill set that employers employing graduates expect and what graduates are leaving college knowing. –  Paddyslacker Sep 7 '10 at 0:12
@paddy Computer Science != Software Engineering Though, I do lament the large number of CS grads that cannot code, programming is not necessarily the focus of Computer Science. –  George Marian Sep 8 '10 at 17:40
@George Marian: Myth. Programming and software development is taught in CS courses. Saying "cs != se" is a half-assed excuse for not teaching it right. –  Steve Evers Oct 13 '10 at 15:14

12 Answers 12


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.

share|improve this answer
+1 I agree completely. I realize I'm probably jinxing myself and my next client will demand formal UML in the documentation! –  Paddyslacker Sep 6 '10 at 6:55
I think as long as the informal UML is understood by everyone in the room, it doesn't matter what symbols you use. –  Richard Sep 6 '10 at 11:03
+1 Agreed. I can't recall the last time we used any UML. Too much time needed and too little return, no ROI. –  Walter Sep 6 '10 at 13:53
UML seems to be going down a path to becoming its own programming language (because you can generate crappy code from the diagrams with some systems). People who evangelize are usually architect astronauts who spend all their time in theory and little on application. Personally, I'd much rather just write code because it's faster and a lot less tedious. –  Evan Plaice Sep 11 '10 at 21:42
@Evan: the problem ends up being that the amount of detail necessary for a model accurate enough to actually generate the system causes it to approach the complexity of the system itself - rendering it impractical. Of course there are always people, like your astronauts, who would rather live in their simulacrum than in the world it represents. –  Shog9 Sep 11 '10 at 22:00

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
really??! people actually use that feature? –  Ozz Feb 17 '11 at 19:04
"used". Past tense. –  FeatureCreep Feb 17 '11 at 21:26

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.

share|improve this answer

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".

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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 !!

share|improve this answer
I disagree that MDD is useless. I've worked in a couple of projects where it's been successful. It takes a certain work context to make it work. We still do not know enough about software engineering to apply it effectively in all situations. –  luis.espinal Oct 15 '10 at 19:32

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.

share|improve this answer

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.

share|improve this answer
this post is rather hard to read (wall of text). Would you mind editing it into a better shape? –  gnat Jan 14 at 3:40
Yes. Wall of text. Fair enough. –  JLG Jan 14 at 4:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.