Hi Dhiren/Jacky,
I apologise if I have added some confusion to the already confusing and vague requirements. I was only stating my interpretation of the requirements
My line of reasoning is that there are 3 parts to the Legacy System - User Interface, Database and Core business logic (the COBOL part). From the requirements, I get that the Database and User Interface parts are to be replaced. Since nothing has been said about the business logic part and the fact that the requirments talk about an application client, I assumed that the business logic part is going to stay. Why else would they need an application client, when the Customer and the Travel Agent have more or less identical resposibilities and are participants in the same set of use cases?.
Anyway, in the real-world, you wouldn't jump into application design without having a few discussions with business analysts to validate/confirm your understanding of the stated requirements. I think Sun understands and acknowledges the situation and has asked the candidate to make the necessary assumptions. I think that it should be Ok as long as the assumptions are supported by reasonable arguments.
Hi Jacky,
I won't get into the details of talking about the number of classes and the specific notations used in my Class diagram. We may be straying off the boundary a bit with that line of discussion. Besides, I think it would only add more confusion to the picture since each person's design is different.
My suggestion to you would be to use those notations that you think would add clarity to the diagrams. Multiplicity, Stereotypes, relevant attributes and methods that clearly show the responsibilities and possible state changes of a class instance and UML notes are all useful notations in the Class Diagram. I can't think of a class diagram for a moderate to complex system that wouldn't make of use of these notations.
>>> Did you change/delete any thinks from the original BDM?
Yes. I changed it a bit and documented my reasons for the changes. Partly because some of the class relationships were not clear from the BDM (they were not even named). Also, I found some abstractions to be more useful from an OO and application design point of view, than what was given in the BDM. Sun didn't seem to mind it.
>>>1.You said,in your class diagram,you showed the class objects only relevant to the given bussiness domain.ie.bussiness logic class and not include any technologic classes.So I feel there are only a few classes can be showed in them,
>>>6.When customer finish booking itinerary ,Is there anything customer can get?I really unclear if customer has no ticket,how can he/she goes on trip.
So is ticket also a class object?
The BDM provides only a partial list of the business entities. You would have quite a few more of those.
For both of your questions, I would recommend that you check out the reservation screens from the web site of any commercial domestic airlines. I looked at
http://www.southwest.com/ and gathered some useful information about the business entities involved in the reservation process. Pay close attention to the data entry forms, fine-prints and other instructions given on the page.
Hope it helps.
Regards
Sridhar