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?

  • 11
    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. Commented Sep 6, 2010 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.
    – P Shved
    Commented Sep 6, 2010 at 19:34
  • 5
    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. Commented Sep 7, 2010 at 0:12
  • 1
    @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. Commented Sep 8, 2010 at 17:40
  • 6
    @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. Commented Oct 13, 2010 at 15:14

13 Answers 13



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.

  • +1 I agree completely. I realize I'm probably jinxing myself and my next client will demand formal UML in the documentation! Commented Sep 6, 2010 at 6:55
  • 4
    I think as long as the informal UML is understood by everyone in the room, it doesn't matter what symbols you use.
    – Richard
    Commented Sep 6, 2010 at 11:03
  • 5
    +1 Agreed. I can't recall the last time we used any UML. Too much time needed and too little return, no ROI.
    – Walter
    Commented Sep 6, 2010 at 13:53
  • 3
    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. Commented Sep 11, 2010 at 21:42
  • 2
    @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
    Commented Sep 11, 2010 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.


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.


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.

  • really??! people actually use that feature?
    – ozz
    Commented Feb 17, 2011 at 19:04
  • 2
    "used". Past tense. Commented Feb 17, 2011 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.


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


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.


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.


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


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

  • 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. Commented Oct 15, 2010 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.


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.

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

UML is necessary to...

a) communicate things to external teams, because it is a standard language, like english for everything IT;

b) describe big systems.

Everyone knows a sequence diagram. Those who say don't use UML is because:

  • they just use words (a really bad solution),
  • they invent diagrams nobody understands (ok if nobody complains),
  • they produce documentation nobody reads,
  • they develop small systems, or
  • they just don't document.

UML is necessary and useful. The problem with UML is that people try to use UML to do things. No. First, you do things, then, you describe them using UML.

Another fallacy: UML is not a method (and if you download a tool that forces you to follow a routine to organize your diagrams, DELETE IT!). If you use a tool that starts describing a database, and then it expresses the solution in UML and then it generates objects for that UML, DELETE IT! System architecture and system engineering are domains where YOU choose the solution. If you choose a solution that is not yours a) you will lose a good solution, the one that is probably in your mind and b) you will feel not comfortable with the foreign solution, you will not understand it, etc., you will FAIL! Prepackaged UML solutions describe a developer's view, not your solution.

Ergo, MU-UML is Ok if you prefer it, and all the target readers can understand it.

Here are some simple rules to use UML:

a) You should understand there are TWO classes of diagrams: static and dynamic. If you want to describe a radio receiver, there are two things you need to describe:

  1. The radio, when it is unplugged (its components, parts, connections, structure, organization, security, etc.), that is, the radio as a thing, and the things that each thing is build of. The radio as a thing can be described using UML static diagrams.
  2. The radio, when it is plugged (how it starts, how do parts interact, how are signals converted, treated, etc.), that is, the radio as a function, and each function's functions. The radio as a function can be described using UML dynamic diagrams.

b) UML is a language, not a tool. You START by describing something in words, AND THEN you select an appropriate diagram type and make your drawing. There is probably your blocking problem. Exercise! Define a problem, describe the approach in words using a UseCase diagram, describe what your solution does using dynamic UML diagrams and describe how it is built using static diagrams.

c) When you describe a system, you typically (it depends on each architect) describe it from at least three perspectives:

  1. The system as a thing (using static diagrams)
  2. The system as a function (using dynamic diagrams)
  3. The environment where the system runs (commonly, using static diagrams)

These depend on you. You can add more (e.g. a stakeholders synthesized description, a developers chapter, etc. The order is not important, but you usually put the thing/function parts at the start. I start with the functional part, then, the static part.

d) You don't need all the UML diagrams. Normally, I use a UseCase diagram to describe what the client wants in an introductory chapter, synthesizing the approach of the solution, then, I normally start with the dynamic view, using sequence, interaction and activity diagrams (others can be added if required). Then, I enter in the details of each component (static description chapter), using normally class and component diagrams. Then, I add a deployment section to describe the conditions and the environment where the system runs, mainly using component and package diagrams.

Regarding the tool, I'm fine with UMLet, because it leaves me the freedom to do whatever I need.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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