I wonder how much details are supposed to be in the Part II sequence diagrams? My unfinished sequence diagram for the "prepare for itinerary" use case already spans 7x3 A4 pages and is beginning to be hard to navigate in. I've included most of the significant participants in the diagram, all of the Transfer Objects, Data Access Objects, EJBs, Bean Delegates, Service Locators, JSPs and then some. Am I being too detailed in the diagram or are they supposed to be large?
A readable sequence diagram must not have more than 15-20 objects...Use components or stereotyped subsystems instead of simple objects: sample: "<<UI>>", you can list your jsps or other objects in the text. Mouloud
Are you including only the happy path (Basic Flow), or are you including the Basic Flow and all Alternatre Flows?
Thanks in advance.
Joined: Dec 30, 2004
The "change itinerary" sequence diagram has only 17 objects (lifelines, including the Client actor), but it is already very big in my opinion. But it spans 5x2 A4 portrait pages (using 8-10pt Arial fonts) already. I've included the JSPs as object, the front controller, as well as the transfer objects involved.
The "prepare itinerary" sequence diagram is even worse.
Since the example in Mark Cade's book also include the JSPs and their controller, I opt to do the same in the assignment. But then this raise the question, should I also draw the same diagram for the GUI clients? The interaction from the point of the UI's controller backwards will be mostly the same, being different only in the request/response paradigm of HTTP to the more interactive GUI-based systems.
My question is this now: - Should I draw two sequence diagrams for every use case, for each type of client? Are GUI vs JSP clients that different? - Would it be appropriate to leave out the transfer objects in the sequence diagrams? - Should I leave out the Home interface of EJBs in the process of creating a bean instance in the sequence diagrams?