UML cheatsheet

Every once in awhile, I have to draw a UML diagram. I rarely do serious designs with UML, however sometimes I do need to depict some piece of code in a diagram and UML seems to be the best notation around.

Unfortunately, various sources of information on UML tend to over-complicate things. I am not software architect and drawing UMLs is not my job. So my UML skills are poor by definition. Moreover, I am happy with this situation and don’t see it changing in the future (even if I get promoted ;-) ).

So from time to time I need a simple UML reference card. Simple search finds references like this one, which are excellent if you are serious about UML, and I am not.

Eventually, I decided to write a short UML class diagram reference card for myself. I hope you will enjoy it as well.


So, this is how classes inherit one from another. Here Child class inherits from Parent Class.


This is how User class uses Resource class.

Contains and manages

Here, Whole class contains and manages Part class. This type of relation can be extended to one of the following:

  • One to One
  • One to Many
  • Many to One
  • Many to Many


Here, Whole class references to Part class, but does not manage it. Again, can be extended with:

  • One to One
  • One to Many
  • Many to One
  • Many to Many


This is enough information for now. I’ll probably extend it over time. In any case, please post your corrections and suggestions.

Did you know that you can receive periodical updates with the latest articles that I write right into your email box? Alternatively, you subscribe to the RSS feed!

Want to know how? Check out
Subscribe page


  1. Nico says:

    I must say I strongly disagree with this statement: “I am not software architect and drawing UMLs is not my job”. With the same reasoning, writing tests is not my job, it’s QA’s job. And documenting how my software works is not my job either, it’s the technical writers’ responsibility. Although, depending on each project, these three statements might hold some degree of truth a successful software engineer should be able to perform all three tasks with proficiency.

    You may dislike some of the support tasks that software development requires, but knowing your way around each one will give an invaluable insight on how different people in different roles see your software, what these people require and ultimately how to deliver a better work.

  2. @Nico
    Indeed what I’ve written is inviting a comment like yours.

    Anyway, there’s a difference between designing stuff and drawing UML diagrams. I work on a project where there is no habit of drawing UML diagrams and therefore I rarely do it myself. I do write design documents and write tests.

  3. ehab says:

    i almost have the same quick reminder of how UML is like, but i must say the only way you can talk with other about your app architecture is using UML.

    How about SysML?


  4. Nico says:

    You may want to check
    Even if it looks a little bit rough, it’s a good way to start learning UML in depth.

  5. @Nico
    This is the kind of things that I didn’t want to use. It’s very long. Way too long to be practical for me. I am sure that someone who is using UML more frequently will enjoy it.

  6. @ehab
    Didn’t use it. But I am curious, so I’ll put it into my “stuff to read” list.

  7. josh says:

    The way some people talk about UML, you would think you could earn a BSUML degree.

Leave a Reply

Prove you are not a computer or die *