It seems somebody caught up the late work at Sun/Prometric today!
I took the Part III examination at June 29, but uploaded Part II only at June 30 - as it happens often, I forgot to ask upload permissions...
The breakdown:
Class Diagram (44 maximum) .......................... 40
Component Diagram (44 maximum) ...................... 39
Sequence/Colloboration Diagrams (12 maximum) ........ 12
Let me answer the default questions

, without, of course, going into infringing details:
My background: I have around 14 years of professional software development experience - it is hard to say how much of it is "architecture", but I believe my role has been more architectural-centric in the last four or five years. Half of these last years' work was Java/J2EE, and the other half Win32/.Net/"LAMP". The FBN system itself is not what I would consider challenging, but Sun's requirements for delivery made me sweat quite a bit.

.
Think I spent around 80 hours working on it (including reading and "thinking about it" time), but never more than two or three a day, except in the last few days. Didn't look to Petstore (had studied a few parts of it in my first days on
J2EE). I used the books I had used previously for Part I: Allen/Bambara's
SCEA book, and the Brazilian Portuguese translations of Design
Patterns, Core J2EE Patterns and UML Distiled. And *A LOT* of JavaRanch. Read it almost daily, and searched it whenever I got stuck. It really pays off!
My assignment had one class diagram, one component digram (each layer was a big component, with classes depcited as smaller components), four sequence diagrams and a four page assumptions HTML. In detail:
Class diagram:
A few properties (just the ones that I thought someone would be asking whether they beleived to this or that class) and fewer methods (only used methods to detail responsibility). It was really an extended BDM, with around 15 classes. It was technology-agnostic (no EJB stuff, for example) but with one or two transport objects that maybe should be left out.
I did not change BDMs cardinality or anything about it. And yes, I puzzled myself with flight-segment-equipment, but there are quite a few ways to keep things as they were and cope with your architecture's needs. Think out of the box and - most important - write detailed definitions for what is one thing and what is another thing. Play God: if the real-life notion of, sey, segment is incompatible with the BDM, define that segment is something else and move along. Just write it down on your assumptions document and it will all fit in the end.
Component Diagram:
Most classes which were not on the class diagram appeared as components on the component diagram. A few clarity tricks were used - for example, instead of having every
JSP, I had a "JSP/view" component (with a note showing JSP names). Keep in mind that this diagram must show all J2EE components - but you can improve readability without omitting information.
Sequence Diagrams:
They were *very* detailed, showing in detail the exchanged messages (mehtod calls) between classes, from the very front JSPs to deep into EJBs and external systems. Being so picky is not not a requirement for SCEA (there are lots of peoople who pass with simplified sequence diagrams), but it is related to my personal modeling methodology: I start with a very bare class diagram (the BDM offered by Sun matched it very well) and start drawing sequence diagrams according to use cases. This work reveals the architectural needs, which I use to fill the component diagram, and also shows the detailed relationships between classes - which help me improve the Class Diagram.
Assumptions:
I went verbose on this one: four pages with diagram clarity decisions, the assumptions themselves, architectural and design choices and, in the end, the links to the diagrams. Bullet-oriented, with very simple formatting (as crude as Sun's assignment document, let's call it justice

). It started as my personal notes, and was developed along with everything else. It's motto was "if someone reads it, he/she will understand why did I choose X instead of Y, even if he disagrees".
My personal advices:
- Don't worry about Part III. Spend this energy on Part II, always questioning if it fits all of the theory that you used in Part I (see section 2 of Part I's exam objectives in
http://www.sun.com/training/catalog/courses/CX-310-051.xml and you will understand what I mean). This make your architecture so solid that you will have no problem at all with explaining or justifying it.
- Take Part III as soon as you finish part II, but REMEMBER to ask upload permissions at least a few days before you need it - Sun's Sharon kindly solved my troubles with it, but why take chances? You are already nervous enough!
- Read the requirements until your eyes pop out. Seriously: most of the confusing areas were clarified after I re-read the requirements.
- This forum is, by far, the *very best* resource of information on the web. Really. The guys here rock, the discussion is very high-level, and I barely could help other people, because by the time a question was posted, complete answers flourished almost immediately (if it did not happen to you, use the search - a few questions get re-posted way too often).
- HOWEVER: don't take everything on the forum as the absolute truth - the absolute truth does not exist, and the only thing that
you should assume to be close to that is the requirements. Listen to John, listen to Paul, but make your own choices. There is very little "right or wrong" here, but there is a lot of justification needed for choices.
Other than that, thanks a lot to everyone participating in this forum. I would be completely lost without it! If I can help with anything, just drop a note!
Best regards for everyone. I'll go celebrate now!
