Win a copy of Machine Learning Systems: Designs that scale this week in the Scala forum
or Xamarin in Action: Creating native cross-platform mobile apps in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

The strange Change Itinerary use-case  RSS feed

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am writing part II of the SCEA, and I must say I find the change itinerary use-case somewhat strange.

First of all: the brief description says that both customers and travel agents may change an itinerary. This indicates that we are talking about itineraries that have already been paid for - and hance persisted to DB.

Second: nowhere in 'prepare itinerary', 'price itinerary' or 'pay for itinerary' does it say that the itinerary payment may be made later. It is described as a single workflow. Does this mean that only itineraries that have already been paid for, can be changed? How else will there be unpaid itineraries - they only exist the few minutes it takes to get from 'prepare itinerary' to 'pay for itinerary'...

Third: If only paid for itineraries may be changed, the post-conditions of the 'change itinerary' makes little sense: It states that the 'prepare itinerary' should be executed after the 'change itinerary', and that the result of the 'prepare itinerary' should be an UNPAID itinerary.

The 'new' itinerary may very well - depending on the changes made - contain flights / segments you have already paid for.

Any thoughts on this?

I would challenge you to a battle of wits, but I see you are unarmed - shakespear. Unarmed tiny ad:
Rocket Oven Kickstarter - from the trailboss
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!