Have you ever seen cartoons/comics in languages you can only imagine where they’re from? Were you able to, at the very least, detect what emotions were being portrayed by any characters?
When you take a look at an image like the one above, you may notice that there are symbols in a language you may not be able to read! (It’s Japanese, by the way) But what you could probably tell is that these deer are quite angry. The lightning-looking marks and the frowned faces may have given that away, those are common ways of showing anger in a drawing, it doesn’t matter where you’re from.
Modeling languages aim to achieve something similar: a way to represent or structure a complex set of information in such a way that just a glance at the representation one could infer how everything has been constructed. Modeling languages define their own rules on how to represent things, some may be simpler than others, some may specialize in certain fields, some may even be only drawings, but all of them have roughly the same goal and stick to their strict norms.
There are several types of modeling languages depending on how the representation comes into play, and I don’t mean the rules themselves, but the method. The two most common types are graphical and textual, which are pretty much self-explanatory, but just to be sure:
Graphical types rely on shapes and lines and many other visual cues to show relationships, interactions and other possible meanings for whatever is being represented, while textual types only use, well, text; plain words and occasionally some symbols other than numbers or letters. There also exist other more specialized types, but I think that these two are enough for now.
At this point, a very logical question may have popped up in your head: is any of these types better than the other? I would say that, indeed, one of them is better. Let me elaborate: for most English speakers seeing a smiley face and reading the word happy could get the same idea into their head, but what would happen if a non-English speaker saw both the word and the drawing? Most likely only the smiley face will evoke the idea of happiness in their mind. What I’m trying to say is simple: shapes and lines are more easily identifiable by most people, so it would make sense to think that graphical modeling languages should be preferred. You probably could even tell so when looking at the deer picture once more, between the cartoon and the text you probably only got a message from the former.
One can’t really talk about modeling languages without mentioning the most popular and famous of them all: the Unified Modeling Language (UML). It is a graphical modeling language, since it’s mostly comprised by diagrams. It was developed by three people working for Rational around 1995, it has since become a standard for software modeling.
UML has a broad variety of diagrams and components, they may vary depending on what kind of process is being covered.
From an activity flowchart to the topic of my last post, use cases; UML has covered practically every kind of process that is related to software. It has defined symbols, representations and arrangements to easily visualize what is being worked on.
I do not plan on going through all of these variants (if you want to know more about any of them, I recommend checking out this post). Since this is an Object-Oriented course, I figured that the most appropriate thing to do would be to focus on class diagrams.
Class Diagrams are yet another type of diagram defined in UML. It includes, in one way or another, graphical representations of most (since I wouldn’t dare to say all) concepts in the Object-Oriented Paradigm, from attributes and methods to class inheritance.
Object-Oriented programming works around the concept of classes and their relationships, and that’s what UML has attempted to represent with this type of diagram (hence, the name). Classes are defined in squares divided into three horizontal segments: the name of the class goes on top, the attributes along with their type come next, and finally the methods and their return type are specified. For both attributes and methods, a symbol just before the name represents whether it’s public, private or protected. Related classes are connected with lines. A line ending in a black diamond indicates composition; but if the end is a white triangle, then it means inheritance. A minimum or maximum number of relationships between classes can also be specified.
There are obviously many more rules to class diagrams, but to explain it all is not the intention of this entry. A person familiarized with UML could take a quick look at the class diagram for a random project and immediately identify its basic structure, even if the words themselves are in another language, they could tell what’s related to what. Although it would obviously help to know said language. Here is a deeper explanation on what class diagrams are and how they work. Fun fact: Lucidchart is actually the website where I create all of my diagrams for whatever graphical modeling language I need.
There is also a variant to class diagrams, it’s known as an object diagram (obviously also closely related to OOP) and it focuses on instances of objects rather than on the class definitions. I thought it was worth mentioning.
To sum all of this up, modeling languages unify the way of representing information. They define rules so we can understand structured projects in an easy way. There are graphical and textual types, but IMO graphical is better. Just ask UML.
TL;DR: 😀 > happy
Roger's Rad Records 