What is UML?
Unified Modeling Language was created in 1995 and developed until 1996 by Grady Booch, Ivar Jacobson, and James Rumbaugh. During the 1990’s it was difficult for software engineers to discuss ideas and design strategies in a high-level view without getting caught up in minor details and misunderstandings. Eventually, this led to multiple modeling languages to solve the problem at a local level. Meaning, outside engineers(or newcomers) would have to learn the modeling language they were using in the company. It wasn’t until the Object Management Group adopted UML as the standard that it completely solved the problem.
So what is UML? UML is a diagram tool that allows us to communicate with other software engineers. We have 14 different diagrams to help us communicate better, ranging from customer interaction scenarios, system lifecycles, and network and infrastructure.
Why is UML important?
Just like over-engineering, UML diagrams can be misused and overused. UML diagrams are helpful when we’re trying to communicate with others about software design or how to solve software design problems. UML is useful when we’re trying to brainstorm ideas, and we want to include our team(which should be the case most often).
While using UML, we should aim to keep them simple. Once we can get our idea across to others, we shouldn’t add any more complexity, like other methods, or relationships, outside of the scope. We aim to keep our UML diagrams clean and straightforward.
UML can be used as a road map. It can be presented to a team of engineers to see the bigger picture of how the system should be architected. On the hand, it shouldn’t be taken as the system’s requirements. Some things are hard to foresee when designing, which can cause the overall system shift in design while in development.
When to Draw Diagrams
Robert C. Martin and Micah Martin did a great job defining this in their book called Agile Principles, Patterns, and Practices in C#:
Draw diagrams when:
- Several people need to understand the structure of a particular part of the design because they are all going to be working on it simultaneously. Stop when everyone aggres that they understand.
- You want team consensus, but two or more people disagree on how a particular element should be designed. Put the discussion into a time box, then choose a means for deciding, such as a vote or an impartial judge. Stop at the end of the time box or when the decision can be made. Then erase the diagram.
- You want to play with a design idea, and the diagrams can help you think it through. Stop when you can finish your thinking in code. Discard the diagrams.
- You need to explain the structure of some opart of the code to someone else or to yourself. Stop when the explanation would be better done by looking at code.
- It’s close to the end of th eproject, and your customer has requested them as part of a documentation stream for others.
Do not draw diagrams:
- Because the process tells you to.
- Because you feel guilty not drawing them or because. you think that’s what good designers do. Good designers write code. THey draw diagrams only when necessary.
- To create comprehensive documentation of the design phase prior to coding. Such documents are almost never worth anything and consume immense amounts of time.
- For other people to code. True software architects participate in the coding of their designs.
In this course:
In this course, we will cover the five most commonly used UML Diagrams; the State Diagram, the Object Diagram, Use Cases, the Sequence Diagrams, and the Class Diagram. Each diagram will have a lesson explaining its purpose, when and how to use it, and UML examples and how they look in code.