Have you ever heard of metonymies? Well, maybe the term is not that well-known, but that’s how you call it when people refer to certain objects by the name of a brand instead of the product’s. At least in Mexico it’s very common to hear somebody refer to crayons as Crayolas, glue sticks as Pritt, tissues as Kleenex, or many other similar cases. I believe this is caused because some brands are greatly preferred over others (mainly because of quality) or because there are only a few offering such products.
Although not exactly a metonymy, the situation of UML diagrams is very similar in a sense. But before I explain myself, I want to briefly remind you what UML is. I have already mentioned this in other blog entries, but UML is the most prominent modeling language out there. It was developed by three people working for Rational Software between 1994 and 1995, then adopted by, you won’t believe it… the Object Management Group (OMG, I know) in 1997 and finally published by the International Organization for Standardization (ISO) as an official standard in 2005. Since then, many versions of UML have been released, with several additions and changes to existing diagrams, and with the creation of new kinds of diagrams as well.
I wanted to compare UML diagrams to metonymies because they have similar effects. If somebody needs a graphical representation of a system and their classes they’ll probably think that they need a class diagram (which is the UML equivalent to such kind of representation) because of one of the following reasons: they do want a class diagram, knowing that it’s the implementation in UML and that there are other alternatives; they want something similar to a class diagram, but since that’s the only name they know, they believe that’s what they are all called; or they believe class diagrams are the only alternative to what they need. Even if none of these is the case, the reference everybody will most likely use is a UML class diagram because of how common they are.
Do you get where my comparison is coming from? Even if a class diagram is not a brand, that’s probably what most people will call that kind of representation. So even if it’s not entirely accurate, it allows us to understand what is needed.
But now, think about this: if there’s already a diagram that depicts exactly what I need and it’s so popular that everyone around me knows it well enough to work as a point of reference, why would I want an alternative to that? To me, it makes no sense to look for an alternative to UML, it works well and practically everybody already uses it so, why waste time and effort looking for something else that does the same? I believe that’s the main reasoning for everyone to keep using UML diagrams. So, in the example I gave two paragraphs above, I believe the reason will almost always be that they do want a class diagram, you know?
So yeah, UML diagrams are super common, hence how useful it is to know how its classification works and some of the basic behavior/structure of some of its diagrams. Oh, would you look at that, that’s exactly what we were told to cover in this entry, so I guess I’ll have to talk about that now.
According to uml-diagrams.org, the classification of a UML diagram is defined by the primary graphical symbols shown on it. Here’s a representation of the current classification of UML diagrams, for this entry I’ll just mention three:
If there’s a sequence of message exchanges between lifelines the diagram would classify as a sequence diagram. Now, if you know as much as me before doing some research you may be thinking: what in the heavens is a lifeline? so I will answer that question for you: they are each of the individual entities that take part in any process of the respective system. Sequence diagrams are the most common kind of interaction diagram, with the focus being the already mentioned messages. According to the examples I saw, the interaction between entities and their respective restrictions are important to successfully achieve a goal or end a process. I understood it as a more complex and complete flowchart, even if there’s not exactly a flow to follow.
If the primary symbols are classes, then the diagram is, surprisingly, a class diagram. These may be easier to understand, since a lot of people are already familiarized with OOP and that kind of classes. I’ve used this type of diagrams since my second semester, they’re useful to get a general idea of the methods and attributes of certain classes (not so much of what they do, but of their definitions), along with the interactions/relationships between them.
Object diagrams are an interesting case. Since UML 2.4 (current version is 2.5) there’s no definition for object diagrams, but previous versions defined them as a way of depicting instances of classes with values for each of their attributes and relationships between them. UML 2.5 states that class and object diagrams are completely unrelated, but other UML sources say that object diagrams are kind of an instance of class diagrams (which is funny if you consider that objects are instances of classes themselves). Anyways, these diagrams can be useful to keep track of certain values at set points or situations inside a program or process. I’ve never used an object diagram, but it seems to be an interesting concept.
Because UML is such a big topic, this is the first part of two about UML, so I’ll wrap everything up in the next post. For now, I’d recommend checking out the link in the paragraph just above the one where I explained sequence diagrams, that website explains every classification considered in UML 2.5.
TL; DR: I said diagram a lot