Thanks guys.
Here is some further analysis that I hope others may find useful:
Exam The exam was actually quite tough despite my score. I had to make an educated guess on at least 5 questions. Compared to Sun exams, it required a little extra mental stamina to maintain concentration for 84 questions. That's the most number of questions I've had in a certification exam.
Interestingly, only 80 of those questions are scored. The other four (including a disclaimer/NDA etc at the begining) are not scored. If you actually spend the time to read the full agreement at the beginning of the
test you will probably spend your entire exam time of 90 minutes doing so: it is very long. Suggest you just scroll to the bottom and choose the appropriate option.
I'm not 100% sure which other questions where unscored as they must have come at random points during the test.
As per the exam coverage map, the exam is broken down into Class Diagrams (30%), Activity Diagrams (20%), Interaction Diagrams (20%), Use Case Diagrams (20%) and Miscellaneous basic notions (10%)
Out of 80 questions, this maps directly to 24 (30%), 16 (20%) and 8 (10%). As such, you can deduce there will be 16 questions on Use Case Diagrams for example.
The questions were presented in the afore mentioned sequence i.e. the first 24 questions were on Class Diagrams followed by 16 questions on Activity Diagrams. I hope I'm not breaking the terms of the NDA by revealing that information.
The fact that questions were grouped by topic was quite helpful I found. It would have required a little more mental gymnastics if they were randomly assorted.
Questions The questions ranged from very easy to very hard. If English is not your native language, you may struggle with some of the questions. The
word "semantics" appears quite frequently in the certification guide and spec and the semantics of various UML elements forms a very large part of the exam.
What this means is that you have to really
understand the meanings of what is covered by the superstructure not just memorize the text. Sometimes, options will be presented to you using words that are not in the specification but have the same meaning. As a non-native English speaker some of these questions may be very difficult to answer.
There was one question early on which had 3 options out of 4 that really could have been the right answer. There were only subtle differences in the meanings of the three options. Even as a native English speaker, I really struggled to pick the right option.
For each of the sections, about 30-50% of the questions were on notation for a particular type of diagram i.e. what are valid elements in a particular diagram or what does an element represent etc. These are questions that
you should be able to get 100% on.
Section Breakdown Class Diagrams Know your notations. Understand the lot! Elements, Relationships, Associations, Features, Structural Features, Behavioral features -> Operations, Dependencies (know the different kinds and keywords, stereotypes: substitute,use,permit), Interfaces (know the definitions (see glossary) - know the ball/socket notations. What is a provided interface? What is a required interface? Packages (interpret <<import>> and <<access>> diagrams etc.) Properties (as association end or attributes) etc. etc.
Get familiar with the metamodel generalization hierarchies. What inherits from what e.g. Element -> NamedElement -> PackageableElement.
There are 24 questions on this topic so really know your stuff.
Activity Diagrams Be familiar with all of the notations. Recognise elements on an Activity diagram and what they do. Understand what makes up an activity diagram: Edges and Nodes. What are the different kinds of nodes? The grouping of the nodes: control node, executable nodes, object nodes etc.
Understand token flow semantics for control flow and object flow. Recognise from a diagram whether control flow or object flow is taking place.
Understand the "and" semantics and "or" semantics and when they apply.
Understand token flow for decision and merge nodes.
Interaction Diagrams Be familiar with all of the notations. What represents a lifeline? What represents and interaction? What represents synchronous and asynchronous messages.
Know what traces are and how to work them out. What are the simple rules that govern event sequencing? Know how general ordering might impact on traces etc.
Use Case Diagrams In the certification guide, there are only 8 pages on Use Case Diagrams. The exam has 16 questions on this topic. Therefore, make sure you all 8 of those pages inside out.
More specifically, make sure you can interpret Use Case diagrams that have missing keywords as in the example in the certification guide.
Be familiar with all of the notations: what is valid notation for an Actor? What is valid notation for a Use Case?
From textual descriptions, be able to identify what are the Actors and how many Actors there are in the use case. See question 3 of UTI sample exam:
http://www.umlcert.org/en/sample_exam/fundamental.html Really be familiar with the concepts of Actors, Subjects etc.
Miscellaneous Basic Notions Make sure you know what are UML2.0 diagrams and what are not. For example, a circuit diagram is NOT a UML2.0 diagram is it?
Make sure you know which diagrams are structure, behavior and interaction diagrams.
Go over the glossary at least a few times and really try to internalize the meanings of each of the glossary elements. This will also improve and re-inforce some of your knowledge for the other sections e.g. what is an Execution Occurrence in an interaction diagram?
Test yourself on the basics of each of the basic stereotypes.
Summary Most of what I've written above is pretty redundant as it is mostly mentioned in the detailed coverage map that I once saw (can't find it now). Best thing to do is go through each of the items in the detailed coverage map and confirm whether you know each of them.
If you know your notations including:
- which way arrows point and why (at exam time you might have to think twice about arrow directions for permit dependency (Class diagram) and extend relationship (Use Case diagram) etc. and it could be easy to get confused on the direction)
- what belongs on a particular type of diagram and what is from some other kind of diagram (even non-UML)
then you should get at least 50% of question right with relative ease.
Preparation Material As some of you know, I used the UML2 Certification Guide by Tim Weilkeins etc. I did briefly refer to the spec to clarify what were part of the objectives for Interaction Diagrams and read more about Primitive data types (the book omitted
String!) and the FULL list of basic stereotypes.
Pros - It has to be better than reading the specification!
- It is the only certification guide.
- It is currently the best source of exam sample questions with realistic type of question and level of difficulty (exam is perhaps very slightly easier)
- Very concise. Covers fundamental material in less than 100 pages with wide margins.
Cons - Lack of attention to detail. There are too many mistakes and errors for my liking:
This ranges from simple spelling mistakes to more annoying mistakes using entirely the wrong word in a sentence! Worse still, completely the wrong notation was given for Active Classes.
- Lost in translation. There were a few translation errors. Perhaps this has come from the spec being translated to German for the original book and then being translated back in to English for the English-version book! I'm just guessing though. The book makes frequent mention of "rhombus" to describe the symbols for aggregate,composite,decision,merge etc. whereas I believe the spec uses the "diamond" terminology. This is minor though. More annoying were the spelling mistakes.
- Given that the spec is restricted to listing things in alphabetical order for a given section, the book had an opportunity to cover the material in a much more logical order that is conducive to learing. I feel that in certain areas a better approach could have been taken.
- There were only a small sample of questions at the end of the book. Moreover, I believe the
cardinal sin of certification guides was committed. A
wrong answer was given for at least one of the sample questions! This is not what someone preparing for their exam wants to be dealing with to build their confidence.
- Some sections were incredibly poorly explained. In particular, the specification did a much better job on covering Class Diagrams: dependencies and Use Case Diagrams (descriptions etc.)
- Definitions of certain elements were not clear at all and in several cases differed from the
official glossary definitions. It is beyond me why the glossary definitions were not included inline with the relevant sections. In addition, the book did not mention to my recollection that the glossary should be reviewed for exam preparation -
this is vital however, so don't forget to do it.
- There was no background on what the metamodel is etc. that could have been briefly covered to provide some context for the entire book without sacrificing the conciseness of the tome.
- Lack of exam style questions at end of each section
- Very dry and direct presentation of material - very boring to read for the most part. Occasional conversational tone and bizarre mention of eclipse.org.
Summary As far as study guides go, it is not brilliant...but it is the only one available and is better than the spec for covering the exam material, especially for interaction diagrams etc.
You will not get 100% on the exam by relying just on the study guide. In fact, you probably could not get 100% by relying on the spec.
Instead, there are several questions that require you to extrapolate from the material covered based on your understanding to come up with the right answer(s). The study guide covers about 95% of required material.
As mentioned already the study guide is not the best "teaching" material I have ever read but this is just a personal opinion.
Finally That's all for now. If anyone has any questions, please feel free to ask and I shall do my best to answer.
I think this exam is good for those with a high level of attention to detail i.e. pedants and also those who are technically-oriented. You know who you are.