This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have David & Dawn Griffiths on-line!
See this thread for details.
Win a copy of Head First Android this week in the Android forum!

Nelson Karan

Greenhorn
+ Follow
since Jul 13, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nelson Karan

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.

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 ]

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.

Originally posted by Darya Akbari:
So, in other words, the preparation for SCEA is making you a big step forward in becoming a good architect, not the certificate by itself.



I agree. Getting the SCEA does not make you an architect, but it puts you on the right track towards becoming one. Experience is of course a key. I myself wouldn't trust to hire an architect with just a few years of development experience and holding an SCEA (who would?). Of course, you would be probably be biased toward the Sun Java technologies with the SCEA.

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.

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.

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 ]

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

Originally posted by Jonathan Gerrish:

There is also the issue that the user could book two itineraries in quick succession using the same set of mileage, if the back end processes are not quick enough. I'll make a note of this in my document.
Cheers, Jon.



IMO, that sounds really bad. That poses a data integrity issue, which a good architect should address.

It sounds like what you could do, based on your approach, is just keep track (in the FBN db) the mileage points that the customer has used today. Assume the batch job would update both databases nightly. Each time the customer attempts Award Travel, you could just do a quick check to see if the customer still has sufficient mileage points remaining. This solves problems: (1) tx atomicity, and (2) data integrity. Let me know if you think otherwise.

Originally posted by arvind patel:
I think you can't access the database directly as it would as good as rewriting the FFMS.
I would recommend using a Wrapper for perl/cgi system.



I understand your point, that updating the database directly is a little like rewriting the system. But from another perspective, we can view it as keeping the mileage system intact, while we just "extend" our travel system to be able to update the mileage points. But why would we choose this route?

One thing that I think *must* be considered is transaction processing. Is it possible to do a transaction that consists of: (1) calling remote PERL module API, and (2) updating the travel system database to confirm that payment has been made? If not, we need to find a way to do this, don't we?