Years ago, and I mean decades ago, there were all kinds of different ideas when it came to how you would model systems visually. You'd have people getting up on whiteboards drawing out all their sight components or software components and state that this piece is going to communicate with this other piece. It made sense to them, however, when they showed it to someone who had not seen their style of modeling, that person would have no idea what to do. If it was given to a developer, the developer many times would be very confused in how they could translate those diagrams into actionable code.

This was a pretty significant problem in the software industry. In 1994 three gentlemen came up with a system to standardize the process of modeling. By 1996 the Unified Modeling Language was born. The three engineers who came up with the concept of UML were Grady Booch, Ivar Jacobson, and James Rumbaugh. Since being finalized in 1996, the language has gone through a number of updates, just like a regular programming language and it has continually evolved. One thing that's pretty impressive about UML is that the same core concepts that were published in 1996 are still being used today. These will be the same concepts we're going to cover with this course.

Now we've walked through a brief history of UML and how it was created, let's talk about the rationale and why it's important for us to use as software developers and as software engineers. When someone asks me why it's important to learn UML, one of the very first things I point out is that it's "Language Agnostic." That means if I primarily work has a ruby developer building a system, and I want to talk to a Java or Javascript developer (or any other language), it's going to be pretty hard for me to show them code they personally don't work with or understand. What UML would allow me to do in this situation, is create visual models of how systems interact. UML would show how I organize data or build a database, all the way through how messages are sent from one class to another to produce the expected behavior.

Another great reason to use UML is when you're working with non-technical stakeholders on a project. There have been many instances as a freelance consultant or when I worked for large companies and multiple people on the team were not software developers or software engineers, I can't show non-developers a line of code and expect them to understand what it does. Using UML, we can model these systems so non-developers can see what the user behavior is going to be and understand what the system does in order to verify the behavior matches their expectations and requirements of the project.

This also speaks to one of the most important aspects about UML, it gives you a level of abstraction that is very difficult to achieve using any other tool. When I say level of abstraction, what I mean is that I take out the implementation details and remove the code. I focus on the high-level behavior or structure of a system.

In this guide, we've discussed what UML is a brief history of it and also why it's important to use.

In the next guide, we're going to talk about what stages of development UML can be used for and how we can structure our approach to it that way.