• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

OCMJEA/SCEA passed today

 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Bartender
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yegor Bugayenko,
Congrats!!!
Thanks for sharing this information.
How long it took for them to evaluate your assignment and part3?
 
Yegor Bugayenko
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One month.
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yegor Bugayenko,

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).

Please clarify.

Thanks,
Bhanu

 
grapes are vegan food pellets. Eat this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic