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.
Inheritance
So, this is how classes inherit one from another. Here Child class inherits from Parent Class.
Use
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
References
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.
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.
@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.
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?
regards
ehab
You may want to check http://www.agilemodeling.com/essays/umlDiagrams.htm
Even if it looks a little bit rough, it’s a good way to start learning UML in depth.
@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.
@ehab
Didn’t use it. But I am curious, so I’ll put it into my “stuff to read” list.
Thanks.
The way some people talk about UML, you would think you could earn a BSUML degree.