Hi All
I've mostly been a lurker here and just wanted to say a big thank you to all the people who have contributed to this group. I found most of my invaluable study material here, many thanks to all the members, the list is too large to mention. Without a doubt I wouldn't have done as well without the guidance I found by trawling all the FAQs here. It took a while but was well worth it. After three weeks I received my part 2/3 result and I'm glad to say I passed:
Sun Certified Enterprise Architect for
Java 2 Platform Enterprise Edition Technology Part II (310-061)
Date Taken: 2006-06-16 07:41:52.717
Registration Number: *********
Site: ****
Grade: P
Score: 100
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 44
Component Diagram (44 maximum) ...................... 44
Sequence/Colloboration Diagrams (12 maximum) ........ 12
In addition to all the posts here I found the following resources helpful:
All parts - Sun Certified Enterprise Architect for
J2EE Technology Study Guide - Mark Cade, Simon Roberts
Part 2/3 - Core J2EE
Patterns - Deepak Alur et al
The J2EE blueprints documentation
Designing Enterprise Applications with the J2EE Platform- Singh et al
I don't think my architecture/design was anything spectacular. The most important objective to keep in mind is that you need to communicate the major parts of the system in a simple way to provide a guide for designers to further refine the system. Harish Ramchandani has a great
thread that describes his approach and I think that a well laid out document which leads an evaluator through the design is a good start. That is how most developers will read your document and it is important to start with an overview and then delve into the system details as necessary. Another key point is to thoroughly read the requirements and mark those that need to be addressed by you design. Use these as your milestones, I don't think you need to create new requirements unless they clarify existing requirements.
I tried to keep my diagrams simple and only provided what was required with an additional deployment diagram to make things a little clearer with respect to the physical structure of the system. My sequence diagrams were perhaps oversimplifications but I tried to describe the major component interactions in more detail either through UML notes or the supporting document. The Cade diagrams are a good guide here but
you should also use your judgement to decide whether a competent developer could pick up your document and have a good understanding of the principles communicated.
Overall the most important thing is to keep the design concise. Set aside a few weeks after you have digested the requirements and just get it done. There is no right answer; reinforce your design choices with valid reasons and you should be fine. Please use design patterns where possible but don't get too attached to minor details; start with a rough system and improve the parts that don't seem clear enough. It's hard to know when to stop refining but if you focus on making a system of well-defined components your design decisions will be justified. I wasn't satisfied with my submission but I felt I was going round in circles trying to add more to it when I decided that I should just submit it. As long as you can list all the requirements you've identified and can illustrate how you address them then you should be ready.
Hope this helps
Yilmaz