Questions on Requirements for Assignment..

[Jay Sam]

Hi,

I have some questions about the assignment...
Especially the "Prepare Itinerary Use Case" ..

it doesnt seem very logical to me.

Assumption A: I start from the assumption that one itinerary can be composed of n flights : this conforms to the business domain model provided with the use case. As I clearly understand it, an itinerary can be: 3 segments/flights from Vienna to New York, 7 segments/flights to come back. Do you agree ? The multiplicity relationship in the domain model is 1..*, not 1..2 or 1..3 � it is clearly 1..*, which means n segments are possible � so there is no limit. Well � where is the problem ?

There are many problems - the problems are here.

Problem No. 1:
�System responds with a list of departure flights and return flights. Customer selects the departure flight and return flight.� (quote from the �Prepare Itinerary Use Case�) - this makes no sense. When a customer has entered search criteria, he should not be presented with flights that he must select from � he should select from itineraries proposed to him. So in this case, I changed this step to a selection of itineraries, rather than selection of departure flight and return flight.

Problem No. 2:
after selecting an itinerary from the itineraries proposed to him, the customer is again proposed itineraries, which �cost less and are within one hour of departure and return times�. Well, again, starting from assumption A, let�s discuss how to implement this. Let�s say we have a round-trip itinerary, not a one-way itinerary. In this case, we could divide the itinerary in �outward� segments for the path towards the destination, and �return� segments, for the return from the destination. If we implement the requirements, then this would mean: present the user with alternative itineraries, which cost less, and are within one hour of departure and return times. Let�s say the customer has chosen this itinerary previously:
Outward:
Departure: Vienna, 10.2.2005, 8.00AM Arrival: Berlin 10.2.2005 10.00AM
Departure: Berlin, 10.2.2005, 11.00AM Arrival: London 10.2.2005 12.00AM
Departure: London, 10.2.2005, 12.30AM Arrival: NewYork 10.2.2005 4.00PM
Return:
Departure: NewYork, 10.3.2005, 8.00AM Arrival: London 10.3.2005 12.00AM
Departure: London, 10.3.2005, 1.00 PM Arrival: Berlin 10.3.2005 2.00 PM
Departure: Berlin, 10.3.2005, 2.30 PM Arrival: Vienna 10.3.2005 4.30 PM

This itinerary starts 10.2.2005 8.00AM, arrives at NY on 10.2.2005 at 4.00PM.
For the return, it starts 10.3.2005 8.00AM, arrives at Vienna at 4.30.PM.
Let�s apply the quote from the use case here : �cost less and are within one hour of departure and return times�
Let�s say we find an itinerary that costs less, which starts 10.2.2005 at 7.00AM but arrives at NewYork at 8.00 AM the next day (16 hours later than the first one), then for the return starting at 10.3.2005 7AM in the morning (5 hours earlier), but arriving at 5.30 PM in the evening, it is ok and meets the criteria specified in the use case ?! Well I wonder if I understand this right.

Problem No. 3:
the customer first enters search criteria to get proposed itineraries. Then, the customer selects an itinerary and again gets proposed itineraries. Then, the customer selects again, and gets to seat selection � why are not all possible itineraries possibly matching his needs displayed at the first time, including a price for business and economy class ?! Then, after having selected the seats, he gets a sort of acknowledgement window, and confirms. I think there is really one step too much in here. But maybe I got the requirements totally wrong !!! This use case doesnt seem logical to me.

Problem No. 4:
if the previous �problems� are solved, there is still another one remaining. Again, starting from Assumption A, consider the �Change Itinerary� use case.
They tell us that an itinerary can be changed, but only one segment at a time. The user selects the segment of the itinerary to be changed, and that segment is then deleted and the itinerary sent to the "Prepare Itinerary" use case. This is confusing. If the itinerary which only lacks one segment is sent to "Prepare Itinerary" use case, what shall happen there ? Must the user re-search the whole itinerary ? Must he only search for that segment of the itinerary ? If it is only one segment that needs to be changed, there must be a whole lot of state information transferred to the "Prepare Itinerary" use case, which almost means to program the whole use case another time for this special case !!!
I would design it this way: when changing an itinerary by one segment, there is a set of itineraries proposed to the client meeting his needs, but only differing in this special segment !! He then choses one. He gets proposed alternative itineraries again,, only differing in the chosen segment, and choses again.
This would mean to implement new methods for this special use case. This would also mean to pass a lot of state information from the �change itinerary use case� to the �prepare itinerary use case�. But if I am already wrong with my assumption, I should maybe not implement it right now, and wait for your answers and thoughts.

Please help me out on this, I�m stuck since 2 weeks because of this problems and nobody seems to be able to discuss it with me...

Regards,

J

[subramanian radhakrishnan]

Hey,

I think you are bit complicating life. I am also working on the part II .

Basically, i would not prefer to change the requirements and give a solution.


I would create an itinerary only after the user confirms the seat selection.
I create the intinerary with the user selected flight details [ with layover if he/she prefers so] and price it and would return the entire priced itinerary to the user. Till then, its just search of flights for the given source and destination. System "SHALL" not create lot of itineraries as proposals as given by you.

[Jay Sam]

Hi,

I�m NOT creating itineraries until the user confirms !!!

But I AM generating itinerary OBJECTS for him - this is different !!

These proposals are _not_ written to the database until he confirms !!!

The only thing this is about is the logic in the requirements, please do not think about the whole backend right now - I just try to figure out that use case.

I�m stuck since 2 weeks in this - and nobody - absolutely nobody seems to be able to discuss my arguments - nobody is really discussing what I have to say. This is very sad, and I can�t continue !

Best regards,

Jay

[subramanian radhakrishnan]

Jay,

Even i dont refer database in my explanation. When i say _CREATE_ it just means POJO creation only.

Even for that sake, i dont want to complicate by creating collection of itineraries [proposals]. Rather what the requirements want is that to give a set of flights that matches the criteria supplied by the user.

So u must let the user to choose different flights [onward and/or return]. At this point i wouldnt call this as an itinerary. This is similar to browing a product catalog.....

Only when the user checks the seat availability and confirms the seats i would call it as a "prepared itinerary".

hope this helps.

subra

[Praveen Nagpal]

Am in full agreement with Subra.

The common notion of itinerary is that it is the final set of flight details which generally includes the pricing information in it. I don't see any point in returning 'proposed' itineraries as long as the user is just searching for the appropriate flights. It would become an itinerary when the user creates one, till then they will all be just plain and simple flights.

Praveen

[Jay Sam]

Hi,

then please tell me _exactly_ what happens - according to you - in this use case.

If I understand you right, then the user:

1) enters search criteria, then submits this to the system
2) the system responds with flights - not an itinerary - ok ok. Then the user selects departure and return flight - does this make sense ? What if there are no direct flights ? What does he chose then ? Did you think about that ? Do you want the user to produce his itinerary himself ?! Let�s say you are right. Let�s say the user has to produce the itinerary himself. But then: the requirements says "user selects departure and return FLIGHTS" - it doesnt say anything about the possibility of segmented travel !!! But his itinerary can clearly be composed of more than just a departure and return flights !!! The requirements dont tell us that he selects more than these 2 flights !!! This is not consistent - I�m sorry.

If however you think this is consistent, then please tell me - for the examples I exposed in my first posting - HOW would you HANDLE the use case - clearly - step by step - and with all the data entered and displayed at each step - how EXACTLY would you understand this ?

I need exact answers, I can�t go on with vague descriptions which seem to be inconsistent.

Regards,

Jay

[subramanian radhakrishnan]

Again, life is simple....

When i said flight i never meant it to serve only one source _AND_ destination.
My design does take into account the lay-over requirement as well.

Moreover, user is least bothered as to how the system manage the lay-over.
As long as the search results with flights [round-trip/oneway], he could verywell proceed with that.

Again, for me a flight is a logical entity that uses one physical career and has a code [ex:SQ702] and has a clear-cut source and destination and also configured whether it is a direct one or segmented one.

I think with the above defintiion of flight conceiving the requirements is simple and straight-forward.

[subramanian radhakrishnan]

Originally posted by mahesh manian:
Again, life is simple....

When i said flight i never meant it to serve only one source _AND_ destination.
My design does take into account the lay-over requirement as well.

Moreover, user is least bothered as to how the system manage the lay-over.
As long as the search results with flights [round-trip/oneway], he could verywell proceed with that.

Again, for me a flight is a logical entity that uses one physical career and has a code [ex:SQ702] and has a clear-cut source and destination and also configured whether it is a direct one or segmented one.

I think with the above defintiion of flight conceiving the requirements is simple and straight-forward.

Just to add clarity, whenever a flight is configured to operate with lay-over
my first-statement in the above explanation is to be understood bit differetntly....

i mean, it is a special case of the flight defintion.
so the same flight [ex: SQ 702] would be visualized _AS MANY AS_ flight instances that are necessary to complete the source and destination with lay overs....

For ex:

flight def1: SQ 702 from:SIN to:LAX [configured with layover]
flight def 1.1: SQ 702 from: SIN to: TKY [tokyo] - lay over
flight def 1.2: SQ 702 from: TKY to: LAX

flight def2: LF 912 from:SIN to: LAX [configured without layover]


when the customer searches for singapore to LA, he will be given two choices either def1 or def2.

but if the customer searches for singapore to TKY [tokyo] he would be given only the def2.

Hope this helps.

[subramanian radhakrishnan]

sorry there was a typo,

when the customer selects to singapore to tokyo, the system would give the option of flight def 1.1 only.

[Jay Sam]

Hi Subra,

thanks for your replies.

Ok - I understand your point.

But this doesn�t conform to the domain model, don�t you think so ? The business domain model states that 1 flight corresponds to 1 segment.

If you provide multiple definitions (e.g. with lay-overs) for one flight, then in fact you should be talking about itineraries.

What you are saying in fact is :
what is displayed to the user are "solutions" to his "problem" - you call those solutions "flights" - I call them itineraries.

Why do I insist in calling them itineraries ? Because:
what the solutions are called on the web page is not important !!! They might be called "solutions", or "travels" or "flights" - as you wish.
But for the system, they are itineraries. This consistency in terms has to apply on all parts of the requirements - this is crucial.

If you however think that your model conforms to the business domain model, then please explain to me: what is a segment for you ? One part of an itinerary, with no lay-over I guess ?

Please clarify.

And again, I would like to know your opinion on Problem No. 4 (see first posting example) - how would you solve this with your design ?

Regards,

Jay

[samou Mouloud]

Think of the requirements as "a first step draft", terms are not used accurately, even itenarary, flight, segments are used with different meanings in the use cases.
Use your own definitions but...you must be coherent, according to the airline industry standard.

Mouloud

[subramanian radhakrishnan]

sorry, again. i would never call them as itineraries for the simple reason as they are used in the requirements with a clear-cut business meaning.

flight defintions in my desing is an implemenation stuff and i would not try to call it with the one defined by the business and confuse the whole design.

This is manily because, i mostly believe "Customer is Right" - approach as he/she knows the business beter.

moreover u need to understand onething, i have not violated anything. Still i am one to one with the flight and segmment.

But each flight has many defintiions [this is not equal to itineraries].
that means any flight can be defined to operate on a single day or not as wanted by the flight agency......?? So defintions are not the same as flight.

You need to consider flight as Product and flight definitions as Line Item.
in the BDOM u will never find a line item, but in the implemnentation they are two different things....

oh...i am done.

subra

[Ravi Dhanum]

Hello,

Here is what I get from previous topics:

1) A leg is a segement and a segment is defined as a takeoff and landing.
2) A departure can contain more than one segment. (The same with
a return).
3) According to expedia.com, each segment of say, a departure,
has its own flight number. This is in agreement with the business
model.
4) From the requirements, the itinerary is composed of data identifying
the departure, return, and any layovers. A layover occurs in between
segments.

-Ravi

[subramanian radhakrishnan]

Exactly. This is how i am also looking at it. Each segment having one leg [flightdef with one takeoff and landing]

[subramanian radhakrishnan]

sorry for the typo again.
each segment [leg] of the itinerary has *one* flight[def with defined take off and landing and a flight code]

[Jay Sam]

Hi Subra,

thanks a lot. This clears many things.

Now - there are 3 small questions for me remaining.

Question 1:
a) the user enter search criteria
b) system responds with list of departure and returns (we agree here)
c) the user choses one
d) the system responds with list of departures and returns if less costly and within one hour of departure and re-
turn times.
Well - I don�t think that step d is necessary at all. The user could be presented with the less costly list of
departure/returns right at step b ! What does the system know at step d, that it doesnt know at step b ?

Question 2:
in step b, the user has chosen departure and return. The system will now "keep" his choice "in mind" (or memory) and re-
turn a list of departure/returns matching the criteria mentioned in step c. Well the thing that disturbs me here, is, it
just specifies departure and return times. If the departure from Vienna is let�s say at 10 AM, and we find a less costly
flight at 10.30AM, but which lasts 5 hours longer (!!!), then the system will display it, according to those requirements.
Do you agree ?

Question 3:
how would you implement the "transfer" of the "change itinerary" use case to the "prepare itinerary" use case, in a
logical way (no technical explanation needed, just the logic).
From my point of view, one would have to implement the "prepare itinerary" use case almost another time, just for that
special use case. However, not alternative flows had been specified in the "prepare itinerary" use case.
But to change an itinerary is clearly not as simple as that. One would have to almost recode every method in the
session bean handling the "prepare itinerary" use case to account for the "change itinerary" use case.
What do you think ?

Best regards and thanks very much for your help so far,

Jay

[Jay Sam]

?

[Mark Wassermann]

Hi Mahesh,

Originally posted by mahesh manian:
sorry for the typo again.
each segment [leg] of the itinerary has *one* flight[def with defined take off and landing and a flight code]

This looks a bit contradictory to what you posted earlier, where a flight definition as you call it could contain lay-overs. Are you saying that a flight in the BDOM would have a one-to-many relationship with - let's say - legs, which define point-to-point connections?

Could we then go with a single segment for depature and another for return?

Mark

[Jay Sam]

Hi Mark,

no, what mahesh/subra is saying is the following:
flights are like in the BDOM model.

"Departure" is the part of the itinerary which is "outward"
"Return" is the part of the itinerary which is "return".

When displayed to the user, "Departure flight" (in the use case text) is "Departure part of the itinerary", and "Return flight" is "Return part of the itinerary". The user�s life is kept simple.

Clearly, the business analyst should have employed the terms "Departure part of the itinerary" and "Return part of the itinerary" for those, for consistency, but the analyst doesn�t seem to be an analyst, so.. let�s forget about his document�s "quality"

Nevertheless, this issue cleared, the 3 questions I posted the last time remain open (see 2 postings upward) - can you answer them ?

Cya,

J

[Manik Saha]

I am currently working on Pt 2.

After reading through all the threads and discussions, I have decided to use a more simplified version of the definitions:

1. 1 flight is one take off and landing
2. 1 segment is one flight. A segment is created for the purpose of creating an itinerary.
4. User can select a departure and destination city, the system will work out the flights required to get him there. This could include more than 1 flight. Each stopover is considered a layover.
5. Each itinerary consists of a number of segments. User can choose to delete any segment and choose a new route (number of segments) for that leg of travel.
6. Pricing is done by adding up the pricing for all the segments. Discounts etc may be done after analyzing the segments.

IMHO the main objective is to have an architecture that caters for the simplest business scenario, but can easily scale to meet additional requirements and complexities that may be added in the future.

Essentially, follow the KISS principle.

[Mark Wassermann]

Originally posted by Jay Sam:
[QB]Hi Subra,
...

Question 1:
...
Well - I don�t think that step d is necessary at all. The user could be presented with the less costly list of
departure/returns right at step b ! What does the system know at step d, that it doesnt know at step b ?

I agree, but that's the way the requirement is

Question 2:
in step b, the user has chosen departure and return. The system will now "keep" his choice "in mind" (or memory) and re-
turn a list of departure/returns matching the criteria mentioned in step c. Well the thing that disturbs me here, is, it
just specifies departure and return times. If the departure from Vienna is let�s say at 10 AM, and we find a less costly
flight at 10.30AM, but which lasts 5 hours longer (!!!), then the system will display it, according to those requirements.
Do you agree ?

Sounds reasonable. It's up to the customer to decide what he wants.

Question 3:
how would you implement the "transfer" of the "change itinerary" use case to the "prepare itinerary" use case, in a
logical way (no technical explanation needed, just the logic).

...

Jay

For me, the only way to make these two use cases fit together would be:

The Prepare use case has an itinerary associated with it. It would be initially empty or the itinerary sent from the change use case.

The Change use case would rather than present a search form jump to the second step and search for flights based on the original itinerary departure date/time/city and destination date/time/city and display them. I would pre-select the segments from the associated itinerary. The thing is that the system will have to recombine single segments into a single multi-segment flight that can be selected. Otherwise it would be up to the user to make sure that the path from depature to destination and back is closed.

What do you think?

[Sasmito Adibowo]

Since a degenerate itinerary consists of one flight, it may be useful to think an itinerary as being composed recursively of

flights/segments. Thus the part of the Prepare Itinerary use case that selects flights and seats may be executed recursively.

My idea is this:

1. User enters departure and return, say from point A to point Z
and their respective preferred times

2. The system does a graph search and responds with a list like this:

Option 1: FBN001 Departure A Arrival Z,
total cost: $$$ to $$$
Option 2: FBN002 Departure A Arrival B,
FBN003, Departure B Arrival Z, total cost: $$ to $$
Option 3: FBN004 Departure A Arrival C,
FBN005 Departure C Arrival D,
FBN006 Departure D Arrival Z,
total cost: $ to $

... and so on, with thegaps between departure and arrival times
for each segment are less than one hour.

3. The customer selects Option 2

4. The customer selects the seat numbers desired for FBN002 and FBN003.

5. ...etc. and then the itinerary is saved w/o being paid first.


Let's just say that the customer changes his/her mind and executes the change itinerary use case..

1. The system lists the itineraries of the customer

Itinerary 1: ...
Itinerary 2: ...
Itinerary 3: FBN002 Departure A Arrival B,
FBN003, Departure B Arrival Z,
total cost: $$ to $$
Itinerary 4: ...

2. The customer selects Itinerary 3.

3. The system displays a list of menu

Change Itinerary 3, please select the segments to change:

1) FBN002 Departure A Arrival B, cost: $ [change]
2) FBN003 Departure B Arrival Z, cost: $ [change]

4. The customer selects segment 2 to change, then the system
recursively executes a part of the Prepare Itinerary use case,
defaulting the departure and arrival times set from B to Z.
It might respond with a list like:

Option 1: FBN007 Departure B Arrival D,
FBN006 Departure D Arrival Z,
total cost: $-$
Option 2: FBN008 Departure B Arrival E,
FBN009 Departure E Arrival F,
FBN010 Departure F Arrival Z,
total cost: $-$

5. The customer selects Option 2

6. etc..

Note that the range of costs reflects the fact that there are two price options for each flight, first class or coach.


So, i guess the problem is solved then?

[Jay Sam]

Thanks folks

I really wonder how much "architect" there is in this assignment, and how much "keep yourself calm and do not kill the analyst" ))

[Andrei Kuznec]

Hello!

I think that Sasmito Adibowo�s model is correct from requirement point of view. It is very simple and precise. However there is one problem, it allows complicating itinerary only, i.e. increase number of flights. E.g. if we have one-way itinerary A-B-Z, we can change it to A-B-C-Z and not to A-Z. I just had idea, what if in change itinerary use case, we would allow customer deleting a stopover point (not a flight). E.g. we have itinerary A-B-Z, the user selects point B and prepare itinerary for A-Z route is called. More complicated example: we have itinerary A-B-C-D-Z and the user want to change C. In that case, prepare itinerary use case is called with B-D as source and destination. And the result is inserted into A-B-whatever-D-Z. What do you think of that?

Regards

[william smith]

Hi Sam,
I have seen a lot of discussions and complications in this
thread about requirements and which made me confused.

Can some one tell me what is the final conclusion of class diagram
is it something like this ...

CUSTOMER->ITINERARY->1. DEPARTURE 2.DESTINATION ->SEGMENT->FLIGHT
OR

CUSTOMER->ITINERARY->SEGMENT->FLIGHT

Then what about this ?

"Departure" is the part of the itinerary which is "outward"
"Return" is the part of the itinerary which is "return".


can you explain and let me know what the final conclusion ...