aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Sequence Diagram and executing another use case Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Sequence Diagram and executing another use case" Watch "Sequence Diagram and executing another use case" New topic
Author

Sequence Diagram and executing another use case

Ronald Havelock
Greenhorn

Joined: Aug 01, 2004
Posts: 3
I would like to know how I can represent passing a process to another use case. Let us say that I have two sequence diagrams. Diagram 1) Sequence diagram that lets a customer select itineries and asks the customer to confirm the itinery. Diagram 2) Login sequence diagram where the user enters user info and logs into the system.

For the customer to confirm an itinery, he/she has to be logged-in. When the customer selects to confirm itinery in diagram 1, and when he/she is not logged in, I want to pass the control to Log-in sequence diagram. How do I represent this in diagram 1. Should I have the Diagram 2 as an actor in diagram 1. Or I should not be doing any passing to different diagram but repeat the same process of diagram 2 in diagram 1.

Any suggestions would be highly appreciated.
Ian Roberts
Ranch Hand

Joined: Aug 20, 2003
Posts: 46
There are a number of ways that you can do this:

(a) Duplicate the reused "Use Case" interactions - although this keeps everything together it is not really a good approach and can result in errors due to not keeping all duplicated diagrams updated.

(b) Use a note to reference another use case - some tools (i.e. Rose) allow you to embedd Sequence diagrams within Sequence diagrams (using a note) but alternatively you good just make a simple note to refer the reader to the "reused" use case.

I prefer the latter because Sequence diagrams can become quite complex and messy, hard to maintain and not very useful to the reader. Simple balanced diagrams that represent a "use case" interaction are often easier to understand and relate to. If the "use case" changes, which is often the case in a commercial environment, the whole design documentation does not require reviewing but simply the use case in question. Approach it like you would creating reusable components. If I have to change this, do I need to change every other artefact within my design - if so, am I representing the use cases and components correctly?

Ian R.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Sequence Diagram and executing another use case