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.  
Recommendation
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.
References
[1] UML® Resource Page; http://www.uml.org
[2] Wkipedia – Object Composition; http://en.wikipedia.org/wiki/Object_composition
Related Whitepaper:

Programming Interviews Exposed: Secrets to Landing Your Next Job

Be prepared for your next job interview with this tried-and-true advice.

In today's tight job market, competition for programming jobs is hotter than ever. This third edition of a popular guide to programming interviews includes new code examples, information on the latest languages, new chapters on sorting and design patterns, tips on using LinkedIn, and a downloadable app to help prepare applicants for the interview. Like its earlier editions, this guide covers what software companies and IT departments want their programmers to know and includes plenty of helpful hints to boost your confidence.

Get it Now!  

Leave a Reply


− two = 1



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

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

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close