Hi there, I'm working on the Part II of SCEA and having some questions about the Login and Create Profile sequence diagrams. Should I draw a separated sequence diagrams for Login and Create Profile use cases? There are only four use case specifications come with the Part II assignment, and Login and Create Profile specs are not included. In the alternative flows of Prepare Itinerary use case, Login and Create Profile use case are executed. I think there are two ways to draw the alternative flow sequence diagrams of Prepare Itinerary use case: 1. Embed the Login or Create Profile use case in the alternative flow sequence diagrams of Prepare Itinerary use case. This means that all the Login and Create Profile logics are shown in the alternative flow sequence diagrams of Prepare Itinerary, and no separated sequence diagrams for Login and Create Profile are needed. 2. Draw separated sequence diagrams for Login and Create Profile and label them or put comments in the alternative sequence diagrams of Prepare Itinerary. I could not find the standard way in sequence diagram to execute another use case in UML. Your comments and responses are greatly appreciated. Thanks. Jim
Hi I have personally not drawn a sequence diagram for login or for creating a profile, since I feel that it is not one of the major flows of the system. Instead I have drawn a sequence diagram for Creating and Itenirary and Paying for an Itenrary. How have you drawn the sequence diagram, I have created 2 types of sequence diagrams one in which the system is considered as a black box , so in these diagrams the only interactiion is between the Actor and the System. The other sequence diagram consistes of the differnt components(objects from the business domian model) from within the system, and so these sequence diagram shows the internal messages that are passed between the various objects from with in the system.
Hi I guess I will be submitting both the sequence diagrams. Moreover I am drawing the sequence diagrams using business domain objects, and not using actualy objects representing say a Controller Servlet or a Session Bean Facade etc. I assume I am making the right decision by drawing the sequence diagram using the business domain objects. Even the class diagram will represent the relations between the Class as identified from the business domain, and not the actual class i.e. EntityBean .etc. In the classs diagram I am just specifiying the important attributes for each of the classes, I am not specifying the methods of the class. I have made these decisions based on the previous posts by various people who have completed the Assignment, and have stated that they provided too much of information by specifying all the methods in each class etc. Can any one who is completed the assignment confirm this... During the desing of the entire system, do I have to specify ( or decide ) on the protocol used by the JDBC driver while commnicating with Oracle Database i.e. If I have to use an Oracle Thin Driver or an OCI Driver, and the reason for my decision ? Rit now I am having a real tough time figuring out how I am supposed to integrated the part of the existing system ( the system that is NOT undergoing the code rewrite ) with the new J2EE based system. I am facing this problem since the existing system all ready has a web based interface , and it has to be integrated within the web based interface of the new J2EE based system, the problems in this integration is the HTTP session management, security etc. Moreover integrating the existing system with a Java Application is going to be a total differnt ball game :-).
I did not go beyond EIS layer. I use DAO to handle all the DB access w/o saying anything about the DB and the drivers although CustomerMileageAccount is based on Oracle and is accessed with JDBC in DAO. The application client can access it through Servlet(tunnel)->EJB->DAO and web client can do it similarly with a different Servlet. The old Perl-HTML-CGI is hard to reuse in the new web client and app client, and only the Oracle stays. DO you think I'm rewriting MileageAccount system?
Hi I think the Application Client should not access the system using the folloing method Servlet - EJB - Database I assume that the Applicaiton Cient used by the Travel Agnets ..will be on the same local network ..so they can dirctly access the EJB. Using RMI/IIOP, as for the CGI-Perl -HTML I assume that it cannot be directly integrated into the new Web system, sicne we have issues about security and Session Management (Web Session)etc, so I have designed it such that only the functionality of the existing is Perl - CGI -HTML is used. So Servelt access a generic compoent ( part of the new system) that acess the existing CGI- PERL- HTML and extracts the information from it ...this same component can b used by the applicatoion client. In this manner I am not rewriting the mileage account styff ..and I used the existing system without any rewrite. I assume wat I am doing is write ....but I guess there are many ways to solve the same problem, provied you have a good reason to do that. I hope I have been helpfull. Do let me know on u'r further progress, discussing about it helps me a lot thanx Vivek
Hi You are assuming there is no firewall. But in reality... . If FBN only has internal travel agents or there is VPN in place, it should be OK. I think the assumption is good so that client application can get better performance as long as SUN ... I'll use EJB-DAO to wrap the old FFM system so the CGI-Perl stuff will stay. I think writing a wrapper should not be considered as rewriting the old FFM system. You mentioned that you will submit both type of sequence diagrams (both system and class levels). Do you mean there will be two sequence diagrams for each flow (basic and alternative) of a use case? Or some of the flow use class level while other use system level? Do you put JSP on your class diagrams or just using stereotype <<View>>? Do you represent them as class in the class diagram? Thanks. Jim
A tiny monkey bit me and I got tiny ads:
SKIP - a book about connecting industrious people with elderly land owners