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

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.

Answer 13

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.