My last blog post was about my experience with the OCMJEA Part-1 multiple choice exam. That was based on JEE5 though I don’t think there is much difference in the approach that one has to follow for the JEE6 version.
This post will talk about my experience and approach towards the Part2/Part3 of the OCMJEA certification. These two parts are common for the JEE5 and the JEE6 versions.
Part 2 is the assignment. You have to pay and you are given a link to download the assignment. Once you download it, the timer starts ticking. You need to remember that BOTH the assignment (Part-2) and the essay exam (Part-3) should be completed within six months time of you downloading the assignment. Another thing to remember is that you can’t register for the Part-3 essay exam unless you have uploaded the assignment solution (part-2) — so time your moves well.
OK. So, this is going to be a long read. If I may sound preachy, well, bear with me but do make it a point to email me your comments.
My first advice about Part 2 is also the most underrated one – Once you have downloaded the assignment, go through it. Oracle’s guidelines prohibit you to take a printout of the downloaded PDF (I know, yes, they have gone too far with that) but it can be a good thing. Write it down on paper – at least the most important aspects. Go through it again and again- trust me, it is not what it looks like. Once you start with the assignment you would read it multiple times and each time you may have a different interpretation of the assignment. Those are the “grey” areas that you have to deal with. Identify the non-functional requirements (NFRs) here. Some NFRs are written clearly (For example a sentence like “customer security should be in focus” obviously asks you to focus on Security NFR) but be on the lookout for NFRs that aren’t obvious.
My second advice about Part 2 is also as much underrated as the first one – don’t take breaks. I know that clearing part-1 feels like an accomplishment (and trust me, it is) and there is nothing wrong to have a breather between the two. But chances are that you are reading this AFTER you have downloaded the assignment and the clock is already ticking. The first few weeks you can still lay low and afford to stay away but don’t prolong it. You may have spent a month wandering around after you have downloaded the PDF and it is OK – but once you decide to work on the assignment, do not take any breaks more than 2 days at a stretch. I found it *really* hard to come back to my assignment after taking those mini-breaks. How do you deal with it? Well, the days when you can’t sit on your desk to work, keep thinking about some aspects of it. Think over the problem statement, the grey areas and in all directions. The idea is similar to what the great Rahul Dravid describes as being “in the zone” (remember the shadow batting?). You end up carrying that mental aspect with you everywhere – so even when you are having a quiet evening with your friends you are still “working” in the background. It is important that you come into this frame of mind as soon as you can.
The assignment does not ask you to code but if thinking on the lines of code helps you, don’t hesitate to write a few classes. One thing that helped me was that I created dummy classes to ease myself into the assignment. As new architects, we come from a coding background and many of us find solace in code. It is a comfort zone of sorts. But remember not to overdo this.
When you start working on your assignment by sitting on your desk with a pen and a paper – don’t be surprised if you spend hours on it without anything scribbled on your notepad. During my initial days on the assignment I used to sit for hours without anything written down while pondering over stuff. That is work. When you do this a few times you will realize that the thinking is the real work – creating a class diagram is just putting your finalized thoughts on the paper and that does not take much time. Thinking brings clarity and this sounds cliched but the more you spend your time thinking, the better your solution will turn out to be.
The first few days as you ease into the assignment – spend some time creating your work environment on your PC. If you have no prior experience on UML, you may need to spend some time working on that. I read a lot of IBM tutorials on UML and of course, Martin Fowler’s classic UML Distilled. The choice of UML tool matters as it will be something you will spend a lot of time on. I did not have much UML experience/knowledge. I used StarUML (not the new Beta!) for my assignment. If you have not used the chosen UML tool before, you will have a small learning curve before you get comfortable with that as well. You need to take all this into account.
I think that the order you go about for creating the diagrams is important. Start with the Class diagram. This is because identifying the Classes and the main methods should be the one of the first things you should do when you start with the assignment. This is also an area which requires constantly coming back to – you might think of X as a class and then one day you’d say, “wait why can’t that be an interface?”. So, this back and forth is a very common thing to happen even as you work on other diagrams towards the end of your assignment. That means your Class diagram is constantly changing and that is why this should be the first to be attempted.
One point here. Remember the “grey areas” that I talk about above? There will be points where you would be unable to move forward until you have a concrete answer. What do you do then?
Consider a real life scenario. The use case is where the grey area is. You have a project to deliver. Things are vague. You want exact specifications. What do you do? You talk to the customer. Except that in the assignment there is no real customer. So you have to assume and move on. Now remember – maintain all your assumptions and notes. Write everything that comes to your mind. Document every doubt and every thought. As you move ahead and achieve more clarity, some of your assumptions will cease to exist. Don’t forget to strike them out from your notes then.
As your class diagram nears maturity, a rough draft of your component diagram should be ready. Actually if you do things right, you should not be spending a lot of time on the first draft of the component diagram. The module and tier segregation should be fairly clear once your class diagram is in good shape. You can always revisit it to “beautify” the Component diagram but the basic structure should be ready and stable.
A word on design patterns – Do not use a design pattern because you think it is cool. Do not use a design pattern because you think you understand it better than the others and because you have used it in your job. On the other hand, some design patterns are no longer in use because of the advent of technology frameworks (Business Delegate, DAO, Service Locator). If you think you can justify their usage, and there is a case for them still, please do not hesitate to use them. Remember that there can be more than one solutions to a problem. Also remember that it is you, who will be required to defend the use of that design pattern so be ready with an explaination. Many people told me not to use Business Delegate but I did. On the other hand, I know people who have used a flow like “JSF->ManagedBean->EJB” and still passed with good marks.
Sequence Diagrams will be something that you have to handle with care. Now here’s the tricky part – Sequence diagrams take the longest time. They go on and on. They also have the least marks (with no minimum passing score – in theory you can get a Zero here and still get your certification!) Here’s another tricky one – There is a good chance that while doing Sequence diagrams you may encounter some things that you may not have thought of earlier and want to go back to the drawing board. Why? Because Sequence diagrams makes us think at the lowest level details, just one level above coding, and it is generally in the details wherein lies the devil.
It is inevitable that you will spend a lot of time in Sequence diagrams so prepare for it accordingly. Use the notations introduced in the UML2.0 to your advantage – for example, the “Ref” notation which allows one sequence diagram to “refer” to another. Identify a small series of sequence that you think is common to every use case – for example, a rendering of a “workqueue” page for a user. Or a service locator looking up a service. Or a series of “if-then-else” sequences that is common in more than one use cases. Create a Sequence diagram and refer it in your use cases with the “Ref” notation. This helps in many ways – (1) it saves your time, (2) it makes your sequence diagram more readable and (3) it tells the examiner that you have used the tools at your disposal in an optimum way.
Remember to document only the main aspects of your use cases in the Sequence Diagrams. Try not to get too detailed. And this is important — it is suicide if you refer to a Class in your Sequence diagram which is NOT in your Class diagram. Cross check that all your mentioned Classes are present in your Class diagram. Having said that, I had a couple of Classes that were there in the Sequence diagram but not present in the Class diagram – the EntityManager (JPA) and CacheManager (From EhCache framework which I had used in my solution). You don’t need to have System classes in your Class diagram but you can show them in the Sequence diagrams for the sake of continuity and clarity. This should be mentioned as a side note in the diagram and/or in the assignment notes section. Lastly – you should ideally have the same number of Sequence diagram sections as the number of use cases in your assignment. So, if you have four use cases, you should have at least four sections for Sequence diagrams (broken down further for clarity).
Deployment diagram takes less time. It took me 3 days to do my deployment diagram. Your deployment diagram should most clearly reflect the NFRs you are focusing on. For example, if you have to make your system on high-availability, your system should have some disaster recovery mechanism. Also, do not use an infrastructure only because you think it is the “in” thing (For example – cloud). Not every deployment has a case for Cloud infrastructure. As you near completion, you can also spend some time on researching on the servers available in the market for the kind of hardware you are going to suggest but from what I hear it is not a mandatory requirement. If you do it though, it shows up positively on your effort (I did it).
You might be wondering on how much “text” to include as notes/comments/side-notes on your diagrams. I do not think there is anything wrong in putting a side-note that helps the examiner understand your diagrams better. Having said that, I also think that it is your diagram that should do most of the talking. Try to strike a balance here – write a few notes that supplement the diagram but overdoing them could make your diagrams look cluttered (and may also signal a lack of confidence).
Now the final documentation part – remember the notes that I suggested you to document? They finally come in real use here. Writing everything down as notes DURING the assignment is very critical because it tells about your thoughts, as they were, at THAT time. When you go over them again and again, with your thoughts getting refined, you will see changes in them and you might strike out a few things as they will no longer be valid. What remains of them at the end of your work is what should now go in that zip file to Oracle as notes and assumptions.
Sorry to break this for you but the most important tip for part 3 isn’t exciting at all. In fact it sounds like an age old wisdom: Don’t take a long break between your assignment submission and your essay exam. If you follow this, you do NOT need any preparation for your part 3. You can have a good night’s rest after your assignment submission and simply go to the exam center and be done with it.
The second thing I would like to insist on for Part-3 is that be prepared to type. They ask you questions on the NFRs, design patterns and technology choices and you have to justify your decisions taken. What kind of design patterns did you use? Why did you use them? What have you done to make sure your system is secure? How have you ensured availability?
Alright then – This has been such a long post. If you have read it till here, I guess you must be really serious about it. In which case, I should wish you Good luck! Please feel free to reach out on email in case you have any doubts.