UML: Aside – Completeness vs Clarity and other CvCs

imageOne of the recurring issues I have experienced with UML, or more generally Model Driven Design is the continual struggle between definition and interpretation. One of the tenants of UML is to abstract upwards towards a level that avoids implementation specifics. However, this introduces the potential for a need of a “Leap of Faith”, something that was discussed my post UML: Modelling User Interfaces Part 1.

In tools that allow a complete forward driven Modelling approach (by this I mean where the model generates code for implementation) the gap between abstraction and implementation must be bridged, generally by propriety extensions, properties or mechanisms. Ignoring some of the practical issues, this seems to work counter to the benefit of the abstraction in the first place, putting a larger burden on the Modeller. However, a counter argument is that these additional decorators offer and capture the bridging formally and explicitly; this could be view as beneficial in comparison to implicit knowledge held withing a group. Whether the Model is the best place to document such information is a topic for another day. Continue reading

UML: Modelling User Interfaces Part 1 – Hierarchy and Navigation

This is the first post in a series that looks at the modelling of User Interface (UI) related software using UML.

The main purpose of the post is to explore how we effectively model the navigation of a tree-like hierarchy, especially when considering the premise “In a tree structure there is one and only one path from any point to any other point”.

The tl;dr is that UML does not necessarily have the ability to represent UI concepts of hierarchy and navigation effectively.


In the design stages of UI, whether it be be a Desktop application, Mobile app or Web site a useful tool for understanding and modelling the interaction is to define a logical hierarchy.

The details of such hierarchies is domain dependent and much has been written on the topic, which I shall not attempt to retread. Broadly speaking, we would attempt to create categories and align “Pages” or “Views” to these categories, usually resulting in a tree structure. There are a few approaches to describing hierarchies but the more commonly used examples are

  • Text-based “Outline”- e.g. a list using indentation and/or bullets to represent the hierarchy
  • Graphical “Node  linked” – e.g a graph of connected nodes with a single path from one node to another

In narrow-scope or simple applications the scope of the hierarchy will be small, however as complexity increases the breadth and depth will increase also. A typical problem encountered here will be deciding the most appropriate place for placing a node – this has a large effect on the User Experience (UX) as the location should match the user expectation; a task made harder when catering for multiple personas, cultures or languages. This part of the process will often result in compromises such as bending rules (categorisation rules) or duplication.

The UI design process must consider User tasks or workflows and an easy trap to fall into is to concentrate these within a single “Page” or “View”, indeed this may be the most appropriate approach. However, once the complexity begins to increase there comes an overload of information and a degradation of the UX, often leading to a separation of concerns and a build out of the hierarchy.

However as a hierarchy begins to grow, the interaction sequences may get more complicated and it can become more difficult to model user tasks or the overall UX of the application. The sequences must consider the navigation of the hierarchy and herein we explore that problem

Continue reading