This week, we have started talking about UML (or Unified Modeling Language) in class, and while I can see some of the usefulness of UML, I wanted to see how people actually use it in the context of a workplace environment. So as a part of this, I found a blog post by Lucidchart talking about different types of UML diagrams. While this blog post is made by a company, and they are trying to get the reader to use their product, I don’t think detracts from the usefulness of the post.

So in this blog post they talk about how Agile developers can incorporate UML into their development process, as well as 7 different types of UML diagrams and how each one is useful, and which context it is useful for. It is largely just an overview of these different models, and I know there are more types of UML diagrams, but this gives a fairly good breakdown of what UML is and how it can be used in a more real-world context. I chose this post as I personally found it useful in understanding why anyone would actually want to use UML outside of a planning stage, since you are essentially planning out the whole class structure before you design it, so in my mind why wouldn’t you just write the code? Well this post makes the case that UML makes very good documentation for your code. If you have a class diagram, like the kind we worked with in class, you can use that as a sort of blueprint for your code. So you don’t have to scroll through hundreds of lines of code just to find all of the methods that are in it and how they interact with other classes, you can just look at the UML diagram. They also make the case that UML can be a valuable tool in explaining code to others.

From this blog post, I think I have a better understanding of how UML is (and should be) used in a workplace. There are a lot of different types of diagrams that were shown that I didn’t know were part of the point of UML, as I have only ever seen the class diagrams. But there are many models that fit under the purview of UML, each with different use cases. Some model runtime behavior in a way that it could be easily explained to someone who has no knowledge of programming, and some are able to show how different methods or classes communicate with one another, creating a diagram that can be easily looked at to make sure you aren’t going to mess with interactions in a system by making certain changes. I think that, given the proper context, UML could make a much more significant impact in understanding how we code, and has the ability to explain code to others in a way that even more traditional documentation methods lack.

Source: https://www.lucidchart.com/blog/types-of-UML-diagrams

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.