Three Common Errors in Whiteboard Job Interviews with UML Diagrams
BY MARKUS SPRUNCK
There are two important differences between drawing a Unified Modeling Language (UML) 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.
Recommendations
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.