• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

68/70 frustration

 
kaiser eblovich
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone

I just got 68 out of 70 for part II, and there are not enough words in any language to describe my frustration.
But OK, I've managed to put myself together and would like to bother this respectable society with my sad story. Maybe I can get some idea what went wrong here.

So I got 10/12 for sequence, 42/44 for component but just 16/44 for class diagram. So it looks like something went awfully wrong with my class diagram, while all the rest was quite OK.

Maybe it rings a bell already?

If not, I can briefly describe my solution, trying my best not to get into prohibited level of details.
* View: web view (Front Controller, View Helper patterns), GUI view (just Swing forms)
* Controller: facade (stateful session bean), Command pattern to perform chunks of business functionality
* Model/Persistence: Local entity beans, Session Facade, Value Object.
Some changes in the model (mileage account removed from schema; a flight has a segment - per passenger, thus 1:N, not 1:1 relation as in original model)
* Three external subsystems - all coupled with Controller
* state is managed via stateful session bean
* total 24 classes in class diagram

Hope my story was vague enough

But I just can't understand what went wrong there. I've got about 4 years of commercial J2EE experience and drew a system as if I have to implement it myself.
Should I leave domain model classes intact?
Should I manage client state via persistence?
Should I throw away Command pattern from controller and use just a method-per-business-function instead (leads to unmaintainable code, but fits into J2EE model nicely)?

Any suggestions, ideas and other input are appreciated.
 
kaiser eblovich
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After reading a little bit here and there, I got an idea that I messed up with domain model

My assumption was that "a flight" is a representation of the fact that a particular aircraft at a certain date/time is departing from point A and after a while arrives in point B

Thus I thought that FBN builds something like "flight schedule" where they put all flights in. When a flight is available in this schedule, a customer could include his/her seat into this flight, thus creating an itinerary segment, a seat reservation, which belongs to this flight. Now I see it could be wrong, because in their model a _flight_ is something I thought to be _flight reservation_ so yes indeed it's 1:1 relationship with itinerary segment... and I'm wrong all the way down.

Please confirm/reject.
 
Pierrefoids samuel
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Really sorry but try it again, we learn more from our failures.

The problem isn't in your patterns choices (command or another) nor in the client state management.

Ask yourself: did you missed some domain objects? Is your class diagram consistent with your asumptions ? Is any change in the BDM well documented and justified ?Is there any broken requirement? Is there any error in your logic? Did you meet ALL REQUIREMENTS.Review all your associations, multiplicities...

The best definition i found for segment: SCTM conference sept 2004 (Vail Colorado
"A segment represents a single flight as booked in a GDS and ticketed on one paper flight coupon. A segment may involve a stop without a change of plane. In rare cases a segment can include a change of plane � usually because the airline is eager to use a single flight number for a particular itinerary � with the notation �equipment change�.
A round-trip LAX-JFK, JFK-LAX using non-stop flights consists of two segments. If there is a change of plane in Chicago each way (LAX-ORD-JFK, JFK-ORD-LAX) it consists of four segments."
I think that this means that a segment is "the flight info" portion of a flight reservation coupon In a coupon you have the following info: reservation number, FLIGHT NUMBER, DATE, CITY FROM, CITY TO,DEPARTURE TIME, ARRIVAL TIME, TYPE OF AIRPLANE, class, seat number...)
In the airline jargon: Airline enterprises "sell segments" (cf: Sabre, Worldspan...)
Many who passed with a high score assumed that a segment is a flight reservation...

You can do it !
Good luck
Samuel
 
Pierrefoids samuel
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing: assume that a flight is "an air transportation" between two airports: It' the product that the airline sells.

Regards
Samuel
 
Jeremy Hsu
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remember I read it somewhere on the forum that people who scores low on the class diagram did not account for all domain objects.

For example, how do you address equipment in your class diagram. Also, it seems people who got ultra high score on class diagram usually just address the domain model without anything regards to J2EE stuff like this should be an entity bean, and that should be a session bean, etc.

In other words, it is very technology independent, and no showing like DTO or other helper classes just to address J2EE.
 
Lucy Hummel
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeremy Hsu:
I remember I read it somewhere on the forum that people who scores low on the class diagram did not account for all domain objects.

For example, how do you address equipment in your class diagram. Also, it seems people who got ultra high score on class diagram usually just address the domain model without anything regards to J2EE stuff like this should be an entity bean, and that should be a session bean, etc.

In other words, it is very technology independent, and no showing like DTO or other helper classes just to address J2EE.


As far as I can juge, Jeremy is right.

I can recommend that you do not put any J2EE stuff in the BDM. So, keep the BDM as technology independent as you can.

The Business Delegate, Service Locator, Session Facades, Data Access Objects, .. are mentioned in the other two diagrams (component & sequnence/collaboration diagram) and not in the BDM.

Lucy
 
Lucy Hummel
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eblovich

I just want to mention that your not the only one who does not passed, see topic Failed Part 2.

Lucy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic