This week's book giveaway is in the Python forum.
We're giving away four copies of Python Continuous Integration and Delivery and have Moritz Lenz on-line!
See this thread for details.
Win a copy of Python Continuous Integration and Delivery this week in the Python forum!

Mark Wassermann

+ Follow
since Feb 20, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Wassermann

Originally posted by Matt Rea:

Yes, I including a Cart class in my class diagram. I also included the Cart in the component diagram where it was relevant. My class diagram was completely technology independant. There were a number of classes that appeared in my component diagrams such as session facades for one example.


[ June 22, 2005: Message edited by: Matt Rea ]

Hi Matt,

did you discuss when to persist objects i.e. when itineraries are stored in a database. ShoppingCart sounds like a non-persistent data?

don't forget that HttpSessions are for web clients only, while a SFSB can be used with other clients, i.e. rich clients.

There is a Together Community Edition as well. It's ok for drawing diagrams.

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



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?
It is mentioned that the FFM is currently an internal system, thus it should not be open to the public. As it did cost 500.000$ it must have quiet some business logic and we are not supposed to reimplement it.

Thus the only option I see is to use some sort of html "screen scraper".

Any comments?
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?

I have another question concerning the sequence diagrams:

When you say your approach was simplistic, does it mean that you had that kind of detail as in the study guide by Cade/Roberts where the components interact directly and left out classes like view helpers or business delegates?

Thanks for your help,

Btw, my instructions say that it is not required to have each method name and attribute in the class diagram.

Am am a bit unsure whether this means no attributes or methods at all or "only the important ones" or "just the ones that are not obvious", i.e. just the methods in the remote interface in a session bean.

As you got full score for the class diagrams, it would be very interesting for me to learn about your approach.