These past few weeks, I’ve been getting myself refamiliarized with UML Diagrams. These diagrams have made a frequent appearance in my CS career. From my complete understanding, they are a great way of analyzing one’s code from the top down. At first, I thought it was just another hassle. Some of these UML Diagrams can get rather difficult to understand, and with all terminology and ways to draw out these charts, it can get pretty hectic to understand how the code works. I learned to take in the information given one at a time. In the blog “Types of UML Diagrams” by Lucid Content Team, it explains that when it comes to any formal code training, UML diagrams are essential but take some time to build and become really out of date fairly quickly, in an Agile environment. But they are very useful for quick visual documentation so that employees can give stockholders a quick overview of the system so developers don’t waste time in meetings.
UML stands for Unified Modeling Language, which is a way to visually represent the architecture, design, and implementation of complex software systems. It is supposed to keep track of the relationships and hierarchies within a software system. It’s hard enough to keep track of thousands of lines of code and so the UML diagram is supposed to keep track of all these components of the software. UML diagrams can be used with basically any programming language and so all software developers should be able to understand it. UML diagrams keep things productive and focused, and they are very helpful to engineering teams. This can include bringing in new team members or developers up to speed, source code navigation, and planning out new features before programming them, and it helps communications between a non-technical audience more easily- which means that most people will be able to understand the process regardless of programming experience.
There are many types of UML diagrams. The first is structural UML diagrams, which show how the system is structured, with classes, objects, packages, and the relationships between them. The component diagram is a more specialized version of the class diagram, which breaks a complex system down into smaller components and will visualized the relationship between the components. Deployment diagrams show how software is deployed on hardware components in a system. Composite structure diagrams are essentially blueprints for the internal structure of a classifier. Object diagrams show examples of data structures at a specific time. And package diagrams are used to show dependencies between different packages. Obviously, this doesn’t even cover half of the UML diagram spectrums since we didn’t even Behavioral UML diagrams which are used to visualize how the system behaves and interacts with itself and other systems.
I’ve come to realize that UML diagrams can be very useful, it’s important to read code from the source but that can be rather time-consuming sometimes. UML diagram is a lot easier to take in and can explain how the software works in just minutes. In my future projects, I want to be able to utilize UML diagrams so that I can better explain my own work to others. I feel it would have been very easy to explain my past projects to people if I was able to have one. The blog was quite interesting because it explained the many types of UML diagrams that exist and their practical uses.
Link to “Types Of UML Diagrams” by Lucid Content Team: https://www.lucidchart.com/blog/types-of-UML-diagrams