Difference between UML 1 and UML 2? Which one should I be focusing on?

Question

I was given a special task to learn and discuss about UML at work. I have a little background about the topic, though I'm not sure what area should I give more priority since UML has now multiple versions. Should I stick with the the UML first version and give an overview for the UML 2 instead? or should I focus more on the UML 2 since it's the latest version? I'm confuse since I'm not familiar with the difference of the two versions.

I need advise regarding the matter. Thank you in advance. Pardon if this question is irrelevant in this site.

Answer 1

It might be practically difficult to restrain to UML 1 just for the following reason: Nearly all available tools for drawing diagrams implement UML 2 since long time ago. So, each time when drawing some construct, you would manually have to check whether it was already available in UML 1.

The step from 1 to 2 was in a large part motivated by the software engineering hype named MDA (Model Driven Architecture) some 10..15 years ago. This was about generating software directly from the model. To support this, all model elements got defined via some formal semantics. Also, some model and diagram types got enhanced. Sequence diagrams were enriched to control structures to express control flows. Component and deployment diagrams got enhanced.

Now, apart from suggesting that it won't make much sense to go back to UML 1, I read from your question that you need to set priorities. That makes sense, as the definition of UML (1 as well as) 2 is quite lengthy, and you don't want to study every detail of it. So here are a few hints:

• With object oriented technology everywhere around, class modeling is the central notion. So you should be familiar with classes, associations, aggregations, composition, inheritance, attributes, operations and their parameters and results, visibility of methods and attributes, abstract classes and methods, and interfaces.

• Objects of a class change their states by application of their operations. A central, and sometime underestimated, type of model therefore is state modeling. Here, UML offers two partly redundant model and diagram types: State and activity models. You should get familiar with at least one of them -- switching to the other should then be not too difficult.

• Most users of UML are quite fond of use case modeling. I'm not, as those use cases tend to lack either significance (if you constrain to naming use cases and actors) or structure (if you start documenting system data and functionality with your use cases). But the rest of the world will only accept you as an UML expert if you know them, so you won't be able to avoid them. Just before using them extensively, think about how to reach the DRY (don't repeat yourself) principle when describing a system via use cases.