This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
As the email from Oracle says from today I'm a proud holder of OCMJEA/SCEA certification. First of all I have to say big thanks to this forum. Without it my certification process would take much longer and would be much more difficult. Let me share a few thoughts which may sound not very typical comparing to what was already said here. Maybe they will help some of you:
"Mention development environment". My deployment diagram contained nodes from the development environment, including continuous integration server, source code repository, and issue tracking system. I explained visually how these nodes are connected to the production environment. I think that in modern systems development environment is as important as production and they have to be designed together.
"Risks are not issues". I clearly separated risks from issues. Issue is something that the designed architecture is solving. Risk is what is not solved by the architecture, but is documented. For example, my architecture contained a Demilitarized Zone (DMZ) as a a response to security threat. Since this issue (the threat) is solved it is not in the risk list any longer. At the same time there is a risk that once this DMZ is penetrated all data inside are not encrypted. I decided not to encrypt them, but document this potential threat in the risk list. See the difference?
"Document your assumptions". I listed a number of assumptions on top of my assignment document. By an assumption I've meant something that is not explicitly explained in the requirements document, but was understood by me in some way. For example, the requirements said nothing about "admin functionality" and I assumed that there is no such functionality required. I have documented this assumption in the first chapter of the architecture document. Thus I have explicitly filled an existing gap in the requirements.
"Make calculations". My requirements document had a number of non-technical statements about performance NFRs, e.g. "the client will have up to 100 orders every hour". I did some calculations in order to convert such statements into more specific numbers, like "pages per second", "RMI calls per hour", "Mbits/second", etc. I documented my calculations and based all other technical decisions on them.
Again, thanks to the JavaRanch forum for the help provided!
First of all, My heartiest congratulations to you.
I am bit confused about component diagram and not able to proceed. Could you please clarify below question:
How much detail should be show in component diagram. Is it enough we show something like in Cade's example. One diagram showing all components very high level.
Or Is it better to split into multiple component diagrams and show all controllers, classes, DAOs, Session beans etc separately?
Could you please mention something about your component diagram (number of diagrams, level of detail, any other info).