Alok Sharma

I suggest this: Define a DTO interface, lets called baseDTO.java and implement this interface by two DTO objects let's say ui1DTO and ui2DTO.These object would define only those attributes which are needed for the respective UIs.

Pass a flag from UI when they send request to server and based on the flag the server should populate corresponding utDTO and send it back to the called UI.

Based on you design of the server object you can choose to define different business methods for each caller UI.

I used "Rational XDE Developer for Java".

After opening the "Modeling" perspective there's a 'Toolbox' view and from 'UML Class' pan, you can drag & drop the objects for class, interface and other class diagram artifacts onto your diagram.

Let me know if it's not clear.

If you have previous experience in designing the J2EE projects or currently working in any j2EE project in you job, then I guess you dont need any of these solutions.Just the cade's book example and this forum is sufficient.

I too was thinking about it but finally didnt go for it and passed the part II.

You dont need to save the itinerary into Database until it is paid.
Before call to pay itinerary, customer need to log in.

So the itinerary could be prepared and remain in session.When customer wants to pay then execute the log-in process and after that get the credit card/reward info from cutmoer.

If the payment is approved then book the seat,save the itinerary and show confirmation screen.

Keep the seat booking and payment in one transaction so that if seat got booked while taking payment info then payment should be reversed.

Please read:
http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/com.ibm.xtools.profiles.doc/topics/tprofstconover.html

I started with the database design.It's not required though but helps to validate the objects structure and communication between them.I didn't modify the BDM.

For class diagram, I used defferent colors for each kinds of objects like enitity objects, utility objects, Boundary object and DAOs( people say it's not required to show DAOs , but I did and I guess it didn't harm).Initially I followed Cade's pattern then modified it.I didn't use entity beans just statless SB as facade , services and utility objects.

I put planty of comments in the class diagram to show the functionality of each object , justified the relationship between them like aggregation, composition etc.Showed the communication link to external systems.Class diagram has around 30 objects.I worked on the "program to interface" model.

There were three components diagrams and components were shown in packages to help understanding the deployment stretagy, so my component diagram is mix of component and deployment diagram.There were common packages which would be deployed in all nodes (like TOs etc).Comments

I submitted 5 sequence diagrams.There were links if the control is to be sent to other sequence diag. from one e.g link to price itinerary and pay itinerary sequence diagram from prepare itin and change itin.Comments for alternate flows and transaction.Make sure to explain the transaction.I guess this is what gave me marks in Seq. diag.Think about all the possible scenarios of transactions.Think about using a batch job for payment reversals if its needed in your design.

I submitted the assumption doc, which had links to all diargrams , assumption, design choices and other explaination.
I explained briefly how the architecture satisfies non-functional and functional requements.
Documents was organized in headings and bullet points ,which made is easy to comprehend I guess.

Look at this post for having a good idea on documentation: https://coderanch.com/t/152466/java-Architect-SCEA/certification/Passed-Part

There were no major dificulties once my class diagram came in a shape.

I used :
Rational XDE developed for class diagram
visual paradigm for component and sequence diagram
MS Word for assumption doc and generated HTML from MS Word itself to create the HTML doc for submission.

Let me know in case if you have any specific question.

Class Diagram (44 maximum) .......................... 36
Component Diagram (44 maximum) ...................... 41
Sequence/Colloboration Diagrams (12 maximum) ........ 12


Thanks to everyone. Posts in this forum were of great help towards achieving it.

Class Diagram (44 maximum) .......................... 36
Component Diagram (44 maximum) ...................... 41
Sequence/Colloboration Diagrams (12 maximum) ........ 12


Thanks to everyone. Posts in this forum were of great help towards achieving it.

>>This one segment belongs to one and only one itinerary
What makes you think this?

if we dont get the reply then treat this as a failure of the transaction and handle exception appropriatly.

Frequent Flyer Mileage System is an extenral application which has the award mileage information about the customer.You need to show that your application iteracts with this in order to get mileage account information of customers.

Congratulations!!
Could you please share your approach about the diagrams?

1. How many classes you had in class diagrams?
2. What were the level of details you showed in these classes?
3. How many diagram you submitted?
4. What design pattern you used?
5. Where did you think you lost the marks?

Thanks and congratulations again.

A Flight corresponds to one segment and is an identification of the segment as per the business domain.

To explain the relationship: ItineraryVO will hold FlightVO and FlightVO will have flightID and segmentVO.

Customer can have ItineraryVOList if has multiple itneraries.

First One seems to be write.

Request --> Filter --> Controller --> Request Handlers

Filter is called before the controllers.

Congratulation.Would you like to tell us about your class diagram.
1. How different it was from business domain class?
2. How many classes?
3. What all did you show there?
4. Where do you think the things went wrong?Since you scored well in other two .