What are some common UML modeling mistakes and how can you avoid them?

La non validation des modèles réalisés La modélisation UML suit un processus et il est important de garder a l'esprit que chaque modèle vient résoudre un niveau de préoccupation (abstraction) précis. Les modèles du niveau statique doivent aider a réaliser les interactions qui ont été desceller lors de l'étude de l'aspect dynamique du système. Ne pas suivre cette cohérence vient a biaiser le système futur d'une certaine manière. La validation des modèles est donc une étape importante dans le processus de modélisation et garantie la fiabilité de l'ensemble du système futur ou actuel. Si on prend l'exemple d'une application de gestion des salaires il faut une cohérence entre le diagramme de cas d'utilisation et le reste des modèles.

What is directly visible to the user makes up most of the software requirements. So, user abstraction is high priority & very important. This is what spun off the UI/UX genre of careers in information technology. The remainder of the software is all about functionality, messaging, interactions, interfaces, communications, transactions, etc. A use case diagram should be used to abstract the system from each user who interacts with it. The user knows something is happening behind the monitor only through helpful messages, tips, dialog boxes, progress bars. If the user is exposed to the internal workings of the system, they may ask for features / abilities far outside of the scope. The right level of abstraction for the right stakeholder(s).

Many a times, the copy-paste function leads us into trouble. Jokes apart, copying a UML diagram, then forgetting/missing out on some of the modifications to fit the current scenario has happened often. UML comes with a recommended notation, symbolism & syntax for its diagrams. It requires some level of patience to learn them & use them consistently across the documentation. The reward of using the correct notations and symbols is actually realizable only after implementation, which is too late a time & then it may blow up into many open issues. So, design reviews are mandatory. Treating UML diagrams like a MS PowerPoint presentation, where you can utilize any symbol to represent anything, with special effects to boot – is not advisable.

Project artefacts go through multiple iterations within the team before being exposed to other stakeholder(s). Listening to the insider feedback reduces chances of getting it wrong at the customer level. Brainstorming within the team also exposes those areas which may have been designed weakly, or overdesigned so much that there is no flexibility. Even in agile teams, where the customer if available, the UML diagrams should be exposed inwardly to an architect, to get feedback & review comments, before the customer gets to know them. Their experience enables them see flaws in the design by just seeing the interactions in the UML diagrams. Implementing feedback earlier saves time, morale of team members & money.

We all fall into the trap of procrastination when there is a speedy, short term sprint cycle going on. We are too excited to up-end the documents / diagrams which are the heart & soul of our work. This can cause gaps in understanding & lack of reference material when a team member needs one urgently. Using simple techniques like reverse engineering the UML diagrams from the code base saves time & at the same time, satisfies goals of having diagrams up-to-date. Versioning UML diagrams helps in multi-release beta projects & rewarding team members who regularly edit UML diagrams & keep them refreshed is a good strategy. Risk management matrices should also cover this point so that the team cannot ignore this hi-priority flag.

To level up our UML diagrams, it is important to keep an eye on whether we are following time-tested & time-trusted practices & guidelines already mentioned in manuals, books & recommended/expert-certified online/offline reference material. A haphazard UML diagram will not serve any purpose – whether to someone inside the team or to external stakeholder(s). A simple checklist will expose the mistakes in case of not conforming to published good practices. UML has existed long enough for us to not need to “reinvent the wheel”. The requirements of a perfect UML diagram are quite predictable – it should be clear, lucid, right-sized, rightly labelled/annotated, serve the purpose of the audience, able to extend to code level, if required, etc.

Given a chance, I would have drawn UML diagrams forever. ??I was that hooked. This is early 2001, when as part of my project thesis for my master’s degree, I had to submit a project report. My suite of Palm applications was quite cutting edge in those years, using J2Me, Java 2 Mobile Edition. My UML drawing tool was Microsoft Word, since as a student, I could not afford the license of a professional UML tool like Rational Rose. I drew use case, class/object, component, sequence, activity, communication & package diagrams. I drew low-level, high-level design & data flow diagrams. My project mentor okayed my work & I got an “S” grade on my project report. I felt UML challenged my analytical abilities & brought out my inner architect.