Win a copy of Python Continuous Integration and Delivery this week in the Python forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

Part II Prepare Itinerary and Change Itinerary  RSS feed

Posts: 3
  • Mark post as helpful
  • send pies
  • 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...
Posts: 22
  • Mark post as helpful
  • send pies
  • 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.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!