💎 UML Adoption & Some Thoughts

[wxxedu]

Just saw this article online: https://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf

Disclaimer: I am biased against the usage of UML.

This article got me thinking: what's the point of UML?

To dive a little deeper into this conversation: what is UML modeling? More specifically, should UML be a design tool, or should it be a documentation tool?

Let's first consider UML as a design tool. If it is used as a design tool, then we will need to consider the granularity at which we design. One such example is whether we should include private/public access modifiers. I would like to argue that if we do take such things into consideration, we are thinking about the implementation details of the software, but not the behaviors/features, hence this could not be considered Agile.

Therefore, if we were to use modeling methods like UML to design software, we should not be considered things like private/public methods. We should mainly be focusing on the interactions between different components operating in this system. Only modeling the interactions does not need such a complicated system like UML.

The difference between tests and UMLs, as I perceive, however, is that UML, by nature, is loosely coupled with the codebase, despite that UML designs are often very coupled with the codebase. Drawing UMLs requires you to consider the interfaces and behaviors, but there is no way to enforce this. This will be very bug-prone. Let's consider the case with multiplicity. It is the assumption of a UML diagram that the programmer will follow the multiplicity specified. Let's consider a design specifying the multiplicity as 0..1. Designing a diagram that has a field that may have a multiplicity of 0 (null), is a very bad idea already, as it has been commonly agreed upon that the creation of null is a billion dollar mistake. What is even worse is that UMLs cannot enforce this, i.e. UMLs rely on the programmer reading the diagram to know the multiplicity, which, unlike testing, would not let you pass if the specified behavior is not satisfied.

Then let's consider UML as a documentation tool. Because of the loosely connected nature of the codebase, it is very hard to keep updating the UML diagram. Say if you have a rename of one of the items, you will need to go and open your UML tool and then rename that as well...

[damithc]

@wxxedu The purpose and cost/benefit of UML is a good topic for reflection and discussion. Thanks for raising this here in the forum.

For reference, the following questions were raised (and answered) during various lectures too:

• Is UML used a lot in the industry?
• Is there a better alternative to UML?
• For what purpose do UML is used, in this module, and in the industry?
• Are we 'overdoing' UML in this module?
• How can we reduce the burden of maintaining UML diagrams?

[salty-flower]

Wow! Interesting article 🤔

[jiasheng59]

@wxxedu I just want to make a comment on your last paragraph, in fact, keeping UML as a documentation tool is rather easy (as compared to using a as a design tool) given that there're many tools that automate the process of converting code to UML diagram.

See https://medium.com/nerd-for-tech/how-to-generate-uml-diagrams-from-your-existing-code-814d27bd1537

[francisyzy]

Are we allowed to use tools to generate UML diagrams? If so how should we credit it?

[damithc]

Are we allowed to use tools to generate UML diagrams? If so how should we credit it?

@francisyzy The third point in https://nus-cs2103-ay2223s2.github.io/website/admin/tp-w10.html#admin-tp-deliverables-dg-tips covers both choice of UML tools and the use of auto-generated diagrams.

[damithc]

To continue from my previous post ...

This paper is indeed a good read. Recommended to have a look if you can find the time. Thanks to @wxxedu for sharing it.

In the context of this paper, I would like to reiterate the answers to some relevant question that were discussed in earlier lectures:

Q: Is UML used a lot in the industry? Answer: No. This paper reports similar findings. To quote the first paragraph of the 'Conclusions' section:

This empirical study complements and resonates with other studies of UML use in industry, finding (as others do) that practitioners take a broad view of what constitutes ‘modeling’, and that, even if UML is viewed as the ‘de facto’ standard, it is by no means universally adopted. The majority of those interviewed simply do not use UML, and those who do use it tend to do so selectively and often informally.

The paper was written in 2013. The current level of UML (in my estimate) likely to be even less than reported in the paper.

Q: Is there a better alternative to UML? A: No general alternative that is better or more used. However, there are domain-specific modelling notations that can be more useful in that specific domain.

Q: For what purpose do UML is used, in this module, and in the industry? A: In this module, we certainly don't use UML as a blueprint for coding. Doing so requires a more precise notation than the UML covered in this module anyway. We don't use it for generating tests either. We do use it for communication, either to explain our code to future developers, or for whiteboard discussions. As such, it is to be used to be in a minimally yet sufficient manner e.g., include only what is relevant to the purpose of the diagram. As per the paper, the use in the industry seems to be similar.

Q: Are we 'overdoing' UML in this module? A: Yes. Precisely because it is not used a lot in the industry (hence, less opportunities to learn by practice), we would like you to learn it well enough in this module itself.

Q: But why even bother to learn it at all if it is not used that much? A: While most of the time one doesn't need UML, there are times when UML can be useful. Also, while most SWEs can survive without it, those in higher end roles such as architects find it more useful than those in regular SWE roles. As we hope some of you will end up in such higher end roles some day, it is good for you to learn it just in case. In addition, as the paper mentions, there is an educational value of learning to model. This is because one needs to be able to visualize design in some form in our heads even if we don't use tangible diagrams. But before we can do it in our heads, we should practice it in a more concrete and visible form.

Quoting the paper:

One might conjecture that UML is effective in software engineering education, because of what it captures, and where it directs attention, rather than as a prescription for design actions. This is a matter for further research.

A: How can we reduce the burden of maintaining UML diagrams? Q: The third point in https://nus-cs2103-ay2223s2.github.io/website/admin/tp-w10.html#admin-tp-deliverables-dg-tips

@wxxedu said,

We should mainly be focusing on the interactions between different components operating in this system.

This is debatable. In some cases modeling the behavior is more important (interactions is an aspect of behavior); at other times the structure is more important. Usually, modeling some aspects of behavior and some aspects of structure are likely to be of value.

[wxxedu]

Thanks so much. I now have a more balanced view of UML. I think I wasn't being very clear here:

We should mainly focus on the interactions between different components operating in this system.

My thinking is that public/private is more like an implementation detail, hence they should not be of importance when we try to see the whole system, i.e. the structure/interactions. I do see many similar patterns in UML.

Regardless, I think that many of the problems that I had with UMLs have now been cleared. Thanks so much for that.

[damithc]

My thinking is that public/private is more like an implementation detail, hence they should not be of importance when we try to see the whole system, i.e. the structure/interactions. I do see many similar patterns in UML.

@wxxedu Yup, visibility of class members should only be shown if they have some relevance to the purpose of the diagram. In fact some irrelevant members can be omitted entirely.

[dohaduong]

thanks for sharing, the article is very interesting!