Joe Law

Greenhorn
+ Follow
since Oct 30, 2004
Merit badge: grant badges
For More
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 Joe Law

Hi guys,

Just seen my result for Part II/III. Failed for 74%... But the passing mark is supposed to be 70%. So I should pass, right??

Does anyone know why? Is there a email that I can contact to clarify this?

Grade: F
Score: 74
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 39
Component Diagram (44 maximum) ...................... 23 Sequence/Colloboration Diagrams (12 maximum) ........ 12

Rgds,
Joe Law
Hi all,

How authenication is done if your Java application client directly calls the EJB tier?

Rgds,
Joe Law
Hi Ganesh,


But connecting to the FFM db directly is not a correct approach since you are violating the requirement given by the assignment.



Can you tell me why connecting to the FFM DB directly is violating the requirement? Thanks.

Joe
Hi Ganesh,

By changing one segment, you will at most change the 2 adjcent segments. Therefore, at most 3 segments are affected but not the whole departure/returning flight.

However, for the following 2 reasons, I am not very comfortable on this approach:

1) You need to do a lot more things or have a lot of extra alternative flow in Prepare Itinerary in order to support Change Itinerary.

2) In the specification of Change Itinerary and Price Itinerary, various places show that only one segment should be affected.

Anyway, I am now convinced that there is no definition of segment that has no conflict with the requirements. It is just a matter of more or less. And I believe that more than one definition can be used in this certification.

Joe
Hi Ajith,


Hi Joe,
I think your definition of the segment is definitely CORRECT.

You will need to take a few steps backwards ( to understand the Forest and Trees ) To solve the problem that you are facing with your interpretation of the usecase : "I can only select A segment to change".

Nowhere it says that users CANNOT iterate this usecase to mean "User Select SEGMENTS to change" applying this usecase iteratively if it needs.

Whether the change is applied to a single segment or a bunch of them, The user would anyways be changing it one by one...That is how I have interpreted "Select A SEGMENT to change"



The problem is most of the time when you change a segment, you will affect the adjcent segments. And this is not supported in Prepare Itinerary. E.g.,

If you have an itinerary A->X->Y->C and you want to change X->Y to E->F, then the A->X and Y->C segments will also be changed.

If you want to remove the X->Y segment, the itinerary will become A->X, Y->C and it is not valid anymore.

Therefore, you cannot change the segment one by one as suggested in your message.

Joe
Hi Ramon,


How about an Itinerary can only have 1 (one-way) or 2 (return) segments, with each segment consisting of 1 flight? Any other journey combination (A->B->C) would have to be set up as a series of iterations?

This would simplify the 'Change Itinerary'.



I've thought about this also. But in the post-condition of Price Itinerary and Pay Itinerary, it mentioned ".... for each segment of the flight". Your definition doesn't fit into this sentence?

Joe
Hi sioud abla,


I think that if you have an Itenerary like A-->X, X-->Y, Y-->C and you decide to change the segment X-->Y, the Segment X->Y is deleted and another segment is created Z-->T for example, and the iteneray become A-->Z-->T-->C.
then you can not change the trip A-->C, but you can change A-->X-->C, A-->Y-->C.



Acccording to your approach, you have not only changed the selected segment X->Y but you have also changed the original segments A->X and Y->C to A->Z and T->C respectively.

And even if this approach is used, there is still a lot of restriction on changing an itinerary...

Joe
Hi,

I am using the following definition of segment:

A segment is an air journey which has exactly one takeoff and one landing. E.g., If you've a trip from A to C via B, you have 2 segments: A->B and B->C.

This definition seems to be quite common and reasonable to me.

However, if I apply this definition to the Change Itinerary use case, it will become very strange. I can only select a segment to change in the Change Itinerary use case. Let say if I have one trip from A to C and I will stop at X and Y, then I have 3 segments A->X, X->Y, Y->C. If I select the X->Y segment to change, I can only change to another trip like A->X->Z->Y->C. I can't change my trip to A->C or A->X->C or A->Y->C. Meaning that I can only make my trip more complicated but not simplied.

Any idea?

Joe
In the Price Itinerary use case:

"System calculates the price of each segment...."

Obviously, the price of each segment is the input of the calculating the itinerary price. If the route between source and destination does not matter, you don't need the price of each segment.

Also, in the Prepare Itinerary use case, if the route between the source and destination does not matter, all the alternative flights will have the same price....

I think how to calculate the itinerary price is quite clear indeed.

Joe