Home » Software Development » Common Errors in Whiteboard Job Interviews with UML Diagrams

About Markus Sprunck

Markus Sprunck works as senior software engineer and technical lead. In his free time he maintains the site Software Engineering Candies and experiments with different technologies and development paradigms.

Common Errors in Whiteboard Job Interviews with UML Diagrams

There are two important differences between drawing a Unified Modeling Language Diagram in a design tool and depict a design at a whiteboard (i) usually the tool prevents you from some common errors with build in syntax checks and (ii) you have a lot more time to refer to your records. To avoid humiliation during a job interview and/or a design meeting with you next project team – it is maybe necessary to train design at whiteboards.
In the following basic knowledge of UML 2.x is premised. If you are not yet familiar with UML then the UML® Resource Page of OMG [ 1] would be a good starting point to study.  

UML Activity Diagrams – Deadlock Error

Missing knowledge about the token flow in UML Activity Diagrams is a very common source of errors.
In Figure 1 a typical error is depicted. To execute an activity at each incoming connector needs one token – otherwise a deadlock will happen. In the wrong sample action X will wait for ever. Correct is an additional Merge Node before the action X.
Figure 1: Deadlock Error Sample

A innocent question like ‘How would you implement this in Java?’ shows your real knowledge about token flows in UML 2 Activity Diagrams.

UML Activity Diagrams – Initial Node Error

A similar token flow problem happens in Figure 2. Here the start node has two edges. This means that it is not clear if action X or Y will be executed. In the correct version a Fork Node splits the token for both actions.
Figure 2: Initial Node Error Sample

 UML Class Diagrams – Composition Relationship to Self

In Figure 3 the composition relationship to self is wrong. In UML 2 the filled diamond symbol indicates that the relation is a composition. This means that all related OrderItem instances would be destroyed if the owning OrderItem is deleted. In almost all cases an aggregation would be correct solution.
Figure 3: Composition Relationship to Self Sample
In the aggregation relationship (not filled diamond symbol) the object does not take part in the life cycle of the component object. So, the related OrderItems can outlive the destroyed instance.
In Wikipedia [ 2] you find a good sample : “For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university.”
Knowing the exact difference between composition and aggregation is crucial for a lot of design questions.  
In most industries just some of the 14 standard UML diagrams are really needed. My perception is that Use Case Diagram, Activity Diagram, Sequence Diagram, Class Diagram, Component Diagram and Deployment Diagram are most important. For embedded system development also State Machine Diagrams may be needed. So, when you start to learn UML focus on the 6 most important diagram types.
[1] UML® Resource Page; http://www.uml.org
[2] Wkipedia – Object Composition; http://en.wikipedia.org/wiki/Object_composition

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....



Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.