1) admin / login / home jsp-s are mentioned on component diagram, but neither they (ok I would understand that) nor supporting classes are shown on class diagram. Could I do the same without losing points? Did anyone try it?
2) Can I state that particular MVC framework doesn't matter (heck, to be honest, neither persistence framework does) in my case and most will do, on sequence diagram showing, like Cade did, jsp => noname controller => business delegate? (in real life, I would decide it taking teams experience / company's standards into account)
3) Do I have to mention that I use particular logging framework or any logging framework at all, if I don't use custom, app specific one?
4) Doe 18 classes (plus JSPs) on class diagram sound right or did I omit too much details?
1. Instead of exact JSP and class names for these functionalities(Login, Admin), You can mention them at a high level. Example: For login, logout, home JSP's, You can put something like "standard JSPs(login, logout, home)". In the business layer you can mention as "Authentication and authorization business and persistence classes" without mentioning the exact names. In this way, You don't contradict your class diagram and also telling the examiner that you are taking care of this not-mentioned but important requirements in your design.
2.Though the class diagram is framework agnostic, I suggest you to fix on some framework or the other. In the Part-3 of the exam you may get a question on what technologies/frameworks you are considering for the implementation. At that point in time, whatever answer you give should be in sync with your design. So better you draw the sequence diagrams and component diagram accordingly. What framework to be used is an architect's decision, Not that of team's.
3.Its not required to name any particular logging framework. But it's helpful to depict the usage of a logging framework using a small package diagram in the class diagram(Similar/Exactly like Cade's example)
4.Number of classes depends on your assignment question. But looking at the complexity of the exam, 18 should be OK. Make sure you don't leave out anything mentioned in the domain model. DON'T SIMPLIFY THE DOMAIN MODEL. You may enhance it little more, But not certainly the opposite.
I felt that this is too much of details (which is very likely to change because and has little to do with architecture) for an architecture.
In the end it didn't spoil my fun, today I've got "passed" email today.
Sharing my experience (hm, list tag doesn't seem to work for me):
[*]I don't have any architect experience
[*]Cade's book (the 2010 one) was my most valuable asset, for taking ALL parts of the exam. It was the only book that I've fully read (well, I skipped through the UML part). If you don't get what pattern is about, it's better to work out a sample code for yourself and realize it, than read, cough, books by Fowler and the likes IMO. (writing entire books about refactoring? seriously?)
[*]Passed part 1 with 83 or 87% (don't remember exactly)
[*]Took part 3, didn't write much (don't think it was right though) A number of answers was a bit messy, didn't mention all of patterns I've used, wrote wrong info about what kind of EJBs was used for what, answered that I use JPA to the question about "persistence strategy" (oh dear).
[*]Sent my assignment a bit more than one week after taking part
[*]Had only about 20 classes (besides JSPs) in class diagram. Most my diagrams looked quite similar to that of Cade. Mentioned only a couple of patterns in notes on class diagram. (just one word like "Composite" or "ValueListHandler details skipped"). Wrote only 2 sentences as foreword, mentioning that backing beans are used, and what kind of restriction apply to them (no a.b.c.omg.so.deep property references etc)
[*]All my diagrams were on the same HTML page, with table of content links on the top, and titles / "back to top" links next to each diagram.
[*]Didn't use gazillion of "uses" strings, IMO it only makes it harder to read, without providing with any kind of useful info
[*]All diagrams would fit on the same page, design comments / "Author of this page is" and boxes had different colors.
[*]Only used StarUML
[*]Used stereotypes to describe what will be a EJB of what sort
[*]Class/Component Diagrams were very concise in regards to relations between objects, who uses whom, who belongs to whom.
[*]In general, always kept in mind that I don't want to annoy the guy who'll check it on the one hand, and he/she should clearly see what where why on the high level.
The confusing part is " Certification Account Address Validation" afterwards. What is a "site number"/ Which registration number? Heck, "test date" of which part? Sent email to prometric...