This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Sequence Diagram and executing another use case

 
Ronald Havelock
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic