File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes I failed scea part 2: time to learn from mistakes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "I failed scea part 2: time to learn from mistakes" Watch "I failed scea part 2: time to learn from mistakes" New topic
Author

I failed scea part 2: time to learn from mistakes

Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
I failed. My grade: 66/100 = F. javascript: x()
Frown

Class Diagram (44 maximum) ............................... 32
Component Diagram (44 maximum) ........................... 25
Sequence/Colloboration Diagrams (12 maximum) ............. 9

I was devastated. I followed this forum closely, and I thought I had pretty much nailed it. At first, I didn't know where to begin to revise my submission. However, I put my mind to the task, searching and reading every and any post in the forum that could possibly be spelling out mistakes I made in my submission. And I did find some. Here are my findings:

Class diagram (32/44):
- I had a Cade style diagram with around 19 classes, and pretty much followed the BDOM exactly, except...
- I made an assumption which did not follow exactly the BDOM. It is with regards to the Itinerary->Segment->Flight associations. That could be one area where I lost some marks. Some posts from this forum led me to believe that I didn't need to change the BDOM, and so I deleted my assumption, and changed my class diagram to follow suit. Of course, I still kept my other extensions to the BDOM so that the Pay for Itinerary use case could be satisfied properly.
- A couple of the multiplicity specifications in my associations were specified wrongly. Probably lost marks here.
- I didn't specify any attributes before in my class diagrams, for this reasons: that I wanted to be "consistent". i.e., if I was going to specify, I must specify very thoroughly an exhaustive list of attributes. Otherwise, I wasn't going to specify any. I now think this is stupid, and I will add attributes so that the evaluator can better understand my design.
- I now feel I should add more elaborative notes to explain how some classes would be implemented and even what some attributes mean (can't assume the evaluator to understand all my attribute names).

Component diagram (25/44):
- Based on my assumptions and design, my component diagram includes: Forms (JSP), ApplicationClient, FrontControllers, BusinessDelegates, SessionFacades, SLSBs, Entity Beans, DAOs. It is more or less a Cade style diagram. I used stereotypes to identity component types ( e.g. JSP, servlet, SLSB, etc.), and notes to identity patterns used.
- Initially, I found it very difficult to find anything majorly wrong with my component diagram, but I did lose the most marks here. So something definitely was very wrong. Further digging and reviewing generated some results...
- I realized that I had neglected to include components related to the Login use case. Major bummer. Definitely lost marks here.
- I didn't specify detailed components of the Java Swing Application Client. I just had one component labeled "Application Client". Perhaps I should have split it into a few more major components. I'm guessing I might have lost marks here.
- I did add notes to specify which J2EE patterns I was using in the diagram. However, perhaps I wasn't consistent enough to specify them all.
- Other than the above, I have no more guesses on what else could have gone wrong.
- Could it be I lost marks for a spiderweb diagram that looks messy because I had many SLSBs pointing to the ServiceLocator? I think this is minor.

Sequence diagram (9/12):
- I lost 3 marks here... hm... probably because I had overwritten my "View Frequent Flyer Miles" use case with the diagram of the "Login" use case. Bummer.

Conclusion:
A valuable lesson I've learned: triple-check is not good enough. Must always quadruple, quintuple, googuple-check and re-read every single detail of my submission before submitting. I know that by now, I probably have made enough improvements to my submission to get a passing grade (hopefully I didn't make more mistakes in the changes, but I'll review and re-review many times before I submit). However, as any good architect would, I'd like to create an architecture that would get me a 100% grade (I'm sure everyone aims for it). Hence, I have further questions that I hope the architects here in this forum can help me out with in carrying out this important mission: learn from my mistakes, overcome them, and try to regain my confidence. I need all the help I can get!

Questions:
1. This is a J2EE/EJB solution. Hence, must everything in the class diagram be brought over into component diagram as an EJB? I figure that some objects can be viewed as Transfer Objects, which would seem to do just fine. My instincts say yes, and I certainly don't see any reason why not. But due to my low grade in my component diagram, I really would like confirmation.
2. How elaborate should the Java Swing Application Client be in my component and sequence diagrams? For the component diagram: is one component enough to represent the application client? I'm not sure what level of detail should be sufficient here. For the sequence diagram: same question. How detailed must I go? Should I actually show Window, Front Controller, Service Locator... these kind of details?
3. One thing that I've been thinking about is the use of SFSB. My design only uses SLSB, and I always hesitate to use SFSB, unless absolutely necessary. IMO, storing things in session is usually convenient and may improve performance but sacrificing memory resources. And I found that I can manage user session state by storing everything at client-side. Any arguments on why SFSB is a must?

That's all the questions I have at this time. Any useful advice and suggestions would be greatly appreciated. A million thanks to all the architects here.
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
I think you don't have any problems in you diagrams but you have problem with your assumptions/design choices.

What do you think? Did you explain security, protocols, CMTxBMT, BMPxCMP, patterns that you have used and why did you use them, ect ... ?

Best Regards
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1180
Hi Nelson,

Great attitude! As one educator once told me, a major force in learning is .... frustration. If we treat frustration correctly, we can greatly benefit from it and you Nelson seem to be on the right track.


3. One thing that I've been thinking about is the use of SFSB. My design only uses SLSB, and I always hesitate to use SFSB, unless absolutely necessary. IMO, storing things in session is usually convenient and may improve performance but sacrificing memory resources. And I found that I can manage user session state by storing everything at client-side. Any arguments on why SFSB is a must?


The attitude in this forum, for some reason, is against SFSB. Statefull beans are absolutely _huge_ when used correctly and in my opinion they are really needed in our assignment.

Look, computer memory is cheap in comparison to the cost of a bad and unscalable design and caching is key for better performance.

If you read carefully the Core J2EE Patterns book you'll realize how they advocate SFSB and the authors of this book are experts in this area.

Good luck to you!
Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Santiago Urrizola
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
grate grate grate very grate actitude.

In my opinion you must put all your effort in component diagrams (there is wehere you lost major points) and i agree with dan SFSB could be and interest option from evaluator perspective point of view.
I dont think punting loggin components gets you a problem, if you put good notes on it and clarify why you put it.

Congrats again, whe all learn from you !!!


Santiago Urrizola : La Plata - Argentina<br />SCEA (89%-92%)<br /><a href="http://gpitech.wordpress.com/" target="_blank" rel="nofollow">http://gpitech.wordpress.com/</a>
adewale shobajo
Greenhorn

Joined: Nov 11, 2005
Posts: 4
Hello,

I also didnt make my part2 with roughly the same marks as yours. I lost alot of marks in my component diagrams. I was so looking up to the title scea that i left out the subsystem(s) in my component diagrams which i think is highly essential.(wondering if you did same)? I Also didnt represent the Application Clients in much detail. hence the reason(s) for scoring low marks in that section.

Just my two cents as to what might be missing in your component diagram.

Regards.
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Originally posted by Samuel Pessorrusso:
I think you don't have any problems in you diagrams but you have problem with your assumptions/design choices.

What do you think? Did you explain security, protocols, CMTxBMT, BMPxCMP, patterns that you have used and why did you use them, ect ... ?

Best Regards


Hi Samuel, I must admit, I think I did make some assumptions that I could have done without. But I did explain my design choices, including security, CMT/BMT, BMP/CMP, but quite briefly. Perhaps I should elaborate more, and also include some words on protocols. Thanks for the tip!
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Great attitude! As one educator once told me, a major force in learning is .... frustration. If we treat frustration correctly, we can greatly benefit from it and you Nelson seem to be on the right track.


Hi Dan, thanks for the encouragement.

The attitude in this forum, for some reason, is against SFSB. Statefull beans are absolutely _huge_ when used correctly and in my opinion they are really needed in our assignment.


Indeed, I am now seriously considering incorporating SFSB into my design. Perhaps I can do without, but the performance improvement is tempting. I will try to make some more analyses to see whether this is really worth it. However, I have one related question that you might be able to answer that had me puzzling me before. Ever realize that Cade's class diagram specifies a shopping basket, but he's using SLSB? Why not just use SFSB to maintain session state? Is it a printing error? Please enlighten me.
[ July 25, 2006: Message edited by: Nelson Karan ]
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
grate grate grate very grate actitude.
...
Congrats again, we all learn from you !!!


Hey Santiago, thanks for the encouragement, but don't congrats me... I haven't passed yet! hahaha. I will definitely look to put more effort into adding more notes to my diagrams, so that the evaluator could more easily understand my design. Though I hope cluttering the diagrams too much won't have an opposite effect and frustrate the evaluators, instead.
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
I lost alot of marks in my component diagrams. I was so looking up to the title scea that i left out the subsystem(s) in my component diagrams which i think is highly essential.(wondering if you did same)? I Also didnt represent the Application Clients in much detail. hence the reason(s) for scoring low marks in that section.


Hi Adewale. I did include a Payment subsystem in my diagram. Based on my assumptions and designs, it seems like the only subsystem I need to include. Any arguments otherwise? And so how much "detail" do you think is sufficient for the Application Client? I will do further digging in this forum for any elaboration on this.
Hari Private
Greenhorn

Joined: Aug 03, 2006
Posts: 1
Hi Nelson,
You did a great analysis of the problem. You have answered all your questions yourself if you see carefully into your analysis. I just passed my SCEA with 90% (39+39+12)

Before I answer your questions, when you think you have completed all your design, pay close attention to your diagram by looking at a printout. Identify gaps, go back to the tool to build the diag. and check it again after few days. When you are working with the tool you may not be paying attention to minor details that may look a big deal for the examiner.

>>>>>>>must everything in the class diagram be brought over into component diagram as an EJB? ---- No. Component diagram only deals with high level components - You don't put a transfer object or Itinerary object as a component. You deal with Service Locator, EJB, delegate and DAO (if you have used one). You can imagine component to be the primary class for that layer (follow J2EE business patterns). But in component diagram you should be able to show components required for satisfying all the use cases - basically you show how best you can re-use some of the components.

>>>>>>>>>>>> How elaborate should the Java Swing Application Client be in my component and sequence diagrams? --- No need to be elaborate. I hjust showed that agent application client uses a delegate that talks to the
SFSB/SLSB

>>>>>>>>>>> Any arguments on why SFSB is a must? -- Because there is an agent app (SWING APPLICATION) that wants to access this business tier. You want to kind of maintain same structure for the agent and web interface. If the agent app does not require access to this mid tier business system then you can say it is defintely not required. With a java swing client wanting to access, I don't think it's easy to implement session tracking mechanism in swing, although it may be theoratically possible to code one. Hence you want to leverage the benefits of SFSB. Although they are kind of unfriendly in terms of implementation and performance, but you get guaranteed predictable results than trying to implement your own tracking mechanisms. It may not be the best practice but follows industry std. However if you are using SLSB in place of SFSB, you better provide detailed diagrams to convince the evaluator.

Good luck!
Biswaranjan Das
Greenhorn

Joined: Aug 01, 2006
Posts: 6
Hats off to you Nelson. You have the courage to face mass after a failure.
I just got certified and scored 95%.

Now it is just a matter of time before you get yours.

Suggestions
#Do not put everything you want to show evaluator but put those things what evaluator wants to see.
#Respect evaluators time, so do not deliver a bit extra than what is asked(1+1+4) diagrams.
#My BDM was containing hardly a dozen of classes so do not deviate from the track.
#Prefer to draw the diagrams using UML 2.0 specification where you will not need dependent use cases to be shown as separate diagrams.
#Prepare a review checklist like spellcheck, consistency (not EJB/SLSB/Session Bean/Session Facade),multiplicity,aggregation/composition.
#Try to PUT your self in evaluator position and start contradicting each of your own decision.


Biswaranjan Das<br />SCEA(95%),SCBCD(98%),SCWCD(84%), SCJP meagre(75%) victim of Tiger
Maris Orbidans
Ranch Hand

Joined: Mar 08, 2004
Posts: 149

#Respect evaluators time, so do not deliver a bit extra than what is asked(1+1+4) diagrams.


Did you submit only 4 sequence diagrams ?

There are more use cases in use case diagram, are you sure we need only 4?
Biswaranjan Das
Greenhorn

Joined: Aug 01, 2006
Posts: 6
I delivered

1 BDM containing 12-13 classes.
1 Component Diagram around 40 components.
4 sequence diagrams one per use case.

Use UML 2.0 you can do it in just 4 diagrams. And I have not lost single mark on component diagram and sequence diagrams.

Loosing 5 marks in Class Diagram I accept as did not put efforts in elaborating them.
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Originally posted by Hari Private:
I just passed my SCEA with 90% (39+39+12)


Congrats Hari!

...Component diagram only deals with high level components - You don't put a transfer object or Itinerary object as a component....


Right. Thanks for confirmation here. So not everything in the class diagram is brought over to the component diagram. So there's nothing wrong with my way of thinking. Good.

I just showed that agent application client uses a delegate that talks to the SFSB/SLSB


Okay. I did actually include a Front Controller in there before as well. But after reading more posts in this forum, I think some people here have done fine just by including the application client as a single component, and then perhaps elaborating how it communicates with the travel system.

With a java swing client wanting to access, I don't think it's easy to implement session tracking mechanism in swing, although it may be theoratically possible to code one. Hence you want to leverage the benefits of SFSB.


I get what you're trying to say. I actually did a lot more searching on this topic. There's a quote from the PetStore example that says, "Furthermore, placing session state in the EJB tier makes the state accessible to all enterprise beans clients, instead of only to Web clients." (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html)
This reference gives further analysis on that:
http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
So I've decided to include SFSB in my design, and it has really helped simplify my sequence diagrams. Moreover, I think it certainly speeds up the workflow of the system. But I can't help keep thinking how much memory this would cost when there are many concurrent users accessing the system. But I guess this is what we have to do, to make such decisions, and then state the tradeoffs in such a decision.

Thanks for your help, Hari.
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Originally posted by Biswaranjan Das:
Hats off to you Nelson. You have the courage to face mass after a failure. I just got certified and scored 95%. Now it is just a matter of time before you get yours.


Congrats Biswaranjan! And thanks for the words of encouragement. Hopefully my grade for my corrected submission will pay off in the end. I have been making careful improvements to my architecture and design, and am feeling good about it all, and hope it'll finally pay off.

Suggestions
...
#Prepare a review checklist like spellcheck, consistency (not EJB/SLSB/Session Bean/Session Facade),multiplicity,aggregation/composition.
#Try to PUT your self in evaluator position and start contradicting each of your own decision.


Thank you for your valuable tips. I will contemplate thoroughly and carefully, and make the most to improve my final submission.
[ August 08, 2006: Message edited by: Nelson Karan ]
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Thanks to everyone who has taken the time to provide me feedback so far. Words of encouragement from you all have put me back on track with motivated determination.

I feel like I've gained a lot from this forum, and I would like to give back. So I'll keep this thread updated. The mistakes I've made, I sure hope others here won't have to learn the hard way as I have.

Hence, the following are further mistakes that I've found in my submission:
- class diagram: Slight changes to the BDOM had probably cost me. I have "re-thinked" the itinerary-flight-segment relationship, and it is so damn clear to me now that I didn't need to change the original BDOM at all. Just needed to extend it slightly to meet requirements (and add plenty notes).
- component diagram: I discovered my misuses of the Session Facade and Composite Entity patterns, which I thought I had understood clearly before. But there are minor details I missed after re-reading their descriptions. That is embarassing. This affected my component diagrams. Furthermore, I took others' advice to group components (i.e. what some call "template" components). Also, adding elaborative notes.
- sequence diagram: Always making sure I don't overwrite one diagram with another now, my new understanding of design patterns and my integration of the SFSB for shopping cart management has caused me to redraw all my sequence diagrams. And again, always making sure to review and add notes to elaborate on any parts that I think the developer would require clarifications.
- overall: I've made additional assumptions, explained more in design decisions (decisions w/reasons, tradeoffs), elaborated on persistence and security, made a glossary, and improved the overall flow and comprehensiveness of my submission.
- keep in mind at all times:
- requirements: functional and non-functional
- each time i review my assignment, i put myself in the shoes of a developer, and try to think about if everything is clear enough to make an implementation of the design.
- making sure of consistency between diagrams: class, component, sequence
- making sure that all decisions are justifiably made and *explained*

That's it. I'll be submitting again soon. Hoping for the best! Wish me luck (although we don't need luck). Cheers to all.
Mike Van
Ranch Hand

Joined: Apr 06, 2006
Posts: 83
Originally posted by Nelson Karan:
[QB]However, I put my mind to the task, searching and reading every and any post in the forum that could possibly be spelling out mistakes I made in my submission. QB]


Am I to understand that they did not tell you why you scored so low? That would be quite an arrogant thing to do, especially considering the great investment in time and money you made in taking the exam.


Mike Van
If at first you don't succeed, try, try again. Unless you really suck at it. Then, you might just want to try something else, if you dont' want to be a loser I mean.
Sreenivasan Ganti
Greenhorn

Joined: Jun 09, 2006
Posts: 2
Hi All,
THis is my first post.
I have one major doubt for the usage of SFSB. Considering there are two Web servers and One App Server, If we Use SFSB, then How will the application work? Will the Web cluster (software ) automatically synchronize SFSB handle across the webservers? As i understand we have to provide a J2EE solution to the given problem, Is this Session replication and Synchronization is defined as part of J2EE? WHat will happen to my SFSB if we do a horizontal scaling of App Server?
[ August 10, 2006: Message edited by: Sreenivasan Ganti ]
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1180
Hi Sreenivasan,

> This is my first post.
No worries � we'll be nice

> I have one major doubt for the usage of SFSB. Considering there are two Web servers and One App Server....

Before we move on, we need to be clear about the meaning of a web server and an app server.

Many definitions are available on the web, as we can see at http://www.google.com/search?hl=en&lr=&defl=en&q=define:Web+server&sa=X&oi=glossary_definition&ct=title

One of them is:
A term often used to describe a computer that hosts a Web site. In actual fact the term refers to software running on that computer allowing Web pages to be requested and then sent to a user's Web browser.
www.bized.ac.uk/educators/16-19/business/marketing/lesson/sup_glossary.htm


About the app server, http://www.google.com/search?hl=en&lr=&q=define%3Aapplication+server&btnG=Search

An application server is a software platform that delivers content to the Web. This means that an application server interprets site traffic and constructs pages based on a dynamic content repository. This content is typically personalized based on site visitor information, such as the content he/she has viewed up to that point, his/her past buying history, or preferences he/she has set during previous visits. ...
www.cylogy.com/library/glossary.html


Ok, if we read the definitions, the consensus is that the app server prepares the page while the web server delivers the page.

> Will the Web cluster (software ) automatically synchronize SFSB handle across the webservers?

The SFSBs live on the app server side, and so we have no issue of synchronization. We do have, however, the issue of server affinity as described at http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html.

If it was up to me, I would change the architecture of the assignment to have one web server and two app servers as the system burden is invariably on the app layer.

Regards,
Dan
[ August 10, 2006: Message edited by: Dan Drillich ]
Cleuton Sampaio
Ranch Hand

Joined: Nov 11, 2005
Posts: 181
Hi,

I do not agree with having two App Servers and just one Web Server. The main feature of web clients will be browsing the flights and searching the best time and price. This could be handlet in the Web Tier by a ValueListHandler.

It is not a common behavior to search flights at every request. The tipical user will:

1 - inform the destination, the departure and the date.
2 - A list of flights will be assembled and a ValueListHandler will handle the browsing (in the user�s session).
3 - The user will browse the list and choose a flight.

The browsing process is not fast, as the user needs to read the information and make a decision, so, IMO, the Web Servers will handle this browsing operation.


Cleuton (Brazil)


Cleuton Sampaio<br />Systems Architect<br />(SCEA,SCWCD,SCBCD,MCSE,MCSD)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: I failed scea part 2: time to learn from mistakes