UML models are a good way to visualize the design of a system. They can be used as a way to communicate between the various stakeholders. However, there are some errors that are often made by those using UML.
We’re taking a look at 5 of these common errors to help you avoid them!
1. Too much detail/too complicated
You know the saying “Less is more”? Well, the same goes for UML models. Models that show too much information or that are too complicated often convey less information than models that are much simpler.
Models that contain too much information are also harder to maintain if the requirements change.
You should be careful to choose the appropriate level of detail to show the “big picture”. It may also be necessary to adapt the model according to the stakeholder. For example, showing a model of the code to a designer might not be the best approach.
2. Mixing up composition and aggregation
Both compositions and aggregations are associations. The best way to avoid choosing the wrong type is to understand the difference between them. Then, you will be able decide which association applies to your system.
Compositions (represented by a filled diamond) usually have a strong life cycle dependency – the parts are bound to the container. If the container is deleted, normally every element that it contains is also deleted.
Aggregations (an empty diamond shape) are used when a class is a container of other classes, but these classes do not have a strong life cycle dependency on the container. What does that mean in simple terms? It means that if the container is deleted, the contained classes are not.
3. Forgetting to use the fork node
The fork node indicates that both actions should be carried out from a node and not just one of them. If you forget to use the fork node, it becomes unclear which action should be executed.
4. Use case diagram: Inconsistency, incorrectness, and creating too many use cases
For use case diagrams, it is important to remain consistent and keep all use cases at the same level and in the same format.
It is also important to communicate with the stakeholders that you’ve understood and portrayed the correct steps and information for the system.
A very common error is creating too many use cases. For instance, several use cases may center around one class or a minor class. These use cases could possibly be combined into one use case. A good rule of thumb is to decide if they represent the same or different goals for the users.
5. Infinite cyclic association
When using the multiplicity symbol “1”, it is implied that each component has one parent. But in a relationship to self, this poses a problem.
If you use “1”, that means that in our example below, “Component X” must always have 1 parent. It becomes an infinite loop where you must always add 1 parent. To avoid this problem, you can use the multiplicity “0…1”. This means that “Component X” can have 0 parents or 1 parent.
What other UML errors do you come across often?