Use cases for UML

I had a conversation recently in which the following three use cases for UML were suggested:

  • UML as a precise graphical representation of existing programming languages
  • UML as a higher level full life-cycle development language
  • UML as a means to communicate between stakeholders

Today UML is not particularly good for any of these use cases because it is trying to fulfil all of them at the same time.

Which one do you think is most important?

Comments (5)

  1. iamleeg says:

    Definitely #3. I don't tend to use diagrams except when I'm writing a book, or talking to another developer over a pad of paper or a whiteboard.

  2. Richard Cox says:

    Also #3.

    Using the pieces of UML that are useful in this role, drop unnecessary details and adding anything that will help communicate. If the communication is long term (e.g. part of a design overview document) then I'll be a little more formal. But always the language has to serve the communication, not the other way around.

  3. Jim says:

    Perhaps the need for #2 is greater, but UML would be better served trying to be #3.

  4. Cory Casanave says:

    Yes to all – because all are a part of any systems design, and a view of the system is where code is lacking and visual paradigms shine.  Any view of a system has to be able to cover all the aspects of that systems design – communication (#3), systems synthesis (#3) and implementation components (#1).  Why should we have only part of the solution?

  5. Pat McGovern says:

    #3, #1, #2

    In order to satisfy #2 & #1 I think we've sacrificed some of the simplicity that allowed for effective communications.

    That being said, once the communication is agreed upon, it would be nice to be able to use those diagrams for #1 and #2 so that  it's not just a drawing exercise (valuable as that is) but that the materials used can be taken to the next level.