Over the course of several weeks, we’ve been working with a modeling language called Unified Modeling Language (UML). UML is a visual language that visualizes the structure of a program using UML Diagrams so that its behavior can be analyzed by developers. Different objects and classes, such as a class hierarchy or object composition between classes can be easily represented1. By visualizing the software’s code, the UML Diagrams allow a far quicker way for a developer to analyze its behavior and if necessary, allow refactoring in the code.
Code that is poorly designed can contain what is called Technical Debt. Technical Debt of poor design implements at least one of the seven Design Smells; Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity2. Code that is difficult to change has the “smell” of Rigidity, and must be refactored in order to allow change and flexibility in design.
In class and in homework, we’ve been given code and a UML diagram providing the structure of said code. Using the UML Diagrams, we can understand where the code is going wrong, and what to do to refactor the code to remove its Design Smells. Without the UML Diagrams, we’d only have one or two objects or classes at a time to look through, making its structure far more difficult than it would otherwise be without using them.
On the other side of development, creating software while implementing a UML Diagram is very easy to implement, even for a university student. This ease of implementation and its low cost has allowed UML to become a standard through the International Organization for Standardization (ISO)1. As such, there does not exist a good reason why a developer would not want to document his implementation using a UML Diagram.
I wanted to discuss UML Diagrams and the Design Smells because I’ve developed software consisting of over 10,000 lines, and it is very easy to establish a confusing nexus of classes and objects. It is also very easy to lose track of the design, or hard to understand the system’s design without something like a UML Diagram. The Diagrams we’ve discussed in class and gone through in the homework is another big reason, as I understood the logic of the code and what needed to be done before I even saw a line of code. I will be using UML Diagrams from now on so I may be able to document my code for myself, maybe even for the students I help tutor that need help understanding class hierarchies.
Links:
1. https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
(Provided a good explanation of UML)
2. https://learnbycode.wordpress.com/2015/08/01/401/
(Good explanation of the Design Smells)
From the blog CS@Worcester – Chris's CS Blog by Chris and used with permission of the author. All other rights reserved by the author.