• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Part II Prepare Itinerary and Change Itinerary

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am little confused about the logic here -
In Prepare Itinerary use case, after seats is confirmed, an itinerary is created. By end of the use case, the itinerary is persistent in the database. Which is fine.

In Change Itinerary use case, customer selects a segment to change. The segment is deleted and Prepare Itinerary use case is execute. I presume system will take departure city and destination city from the deleted segment and send to Prepare Itinerary use case to search the list of flight, then eventually the system will create another new itierary to replace the deleted segment.

It's kind of funny. After you change an itinerary, it breaks into two itineraries.

Any comments...
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jingbo

I feel the same. There is a lot that needs to be assumed and giving the confusing nature of the use cases I can't see away around it without making some assumptions that go against the use case flow.

For instance in the Prepare Itinerary use case is there really a need to persist an unpaid Itinerary. There is no step that says that a user can select an option to search for a different flight thus creating a new Itinerary after confirmation or save the itinerary to purchase a flight later. Rather the use case follows directly through to the pay for itinerary usecase.

The problem with saving an unpaid itinerary is what happens if the seats selected on a particular segment of the itinerary are no longer available and the user selects one segment to delete. There is no indication in the use case that the system rechecks availability but instead calculates a price for changed itinerary.

Also what happens if the user wants to change a paid itinerary among other things a refund may have to be issued if the cost of the newly added segment is less then the old value. At least saving a paid itinerary means there is no need to check seat availability again. Does the transmaster ape support refunds.

To be honest I don't want to waste anymore time on the assignment so I guess I will just document my decision and get this nasty bit of work out of the way.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic