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.
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.