Use Case with Include - How to draw the sequence

[Brett Bailey]

Hi.

I'm trying to add sequence diagrams to my use cases. The problem is when you have linked (include / extend etc)  use cases Im not sure how to draw the the sequence diagram, to show some other interactions are taking place.

As an example you could have a telephone call use case. The sequence for this would be along the lines of

1 Lift Receiver
2 Dial
3 Hangup

you could have 2 extensions to this : voice call and automated service.

for voice call the extra events would be
Talk
Listen (if you are polite :-) )

and for automated service the extra events would be
Listen to menu announcement
Dial Options

so my question is, at last, how do I mark on the extended use cases that this event sequence takes place between Dial and Hang up in the base telephone call use case?

[thomaskilian]

Hmm. Sequence Diagrams are intended to picture message exchange between objects. Starting from the use case point you do not have them at all. Probably you mean Activity Diagrams?

Thomas

[Brett Bailey]

Thomas,

I'm modelling an existing system. I'm using use cases with sequence diagrams to show how the various parts of the system interact in response to given use cases. I'm pretty sure sequence diagrams are correct.

[mchiuminatto]

Hi Brett.

I fully agree with thomaskilian. You should move this problem to another view of your model, since Use Case has nothing to do with implementation or design issues and this is one of the use case modeling gold rules.

So, you should move this problem to a Use Case Realization Model, where you define one or more collaborations (or Use Case Realization) that realize each of your Use Cases,and here you must show which objects collaborate to achieve the use case goal, adding collaboration or sequence diagrams as you need.

Going back to the telephone call Use Case, I think you should define a single use case named telephone call and define one basic path: voice call, and one alternate scenario: auomated service call.

MCH.

[Brett Bailey]

OK,

The sequence diagrams might be in the wrong place, but I was thinking of them as use case realisations. So I will do that.

However my question about sequence diagrams still remains. If I changed to 2 use cases, voice call and automated voice call, can I just model the differences in some way?

The telephone example was ment to simplfy my current problem. (I thought it would be an easy answer!)

I'm *really* modeling  web server software which performs standard processing for each request (such as loading sessions, deserialise objects, queue tasks update logs)

it then performs what ever action is required by the request and then performs the sandard closure tasks (serialise objects etc..)

the standard tasks involve interactions with about 20 objects. So I thought I could wrap this up in a "Handle Request" use case so that I don't have to keep redrawing it when I model the sequence of events for handling each specific request (which I was thinking would be seperate use cases, each including handle request).

So is this possible or am I running off in completely the wrong direction here?

[mchiuminatto]

I can se clearly now (the rein has gone).

Do you have a single entry point (message, or service call ) for the standard sequence? If the answer is yes, I agree with you on describing the Request Handling UCR with it's associated sequence diagram. So when you model a specific request event, include the first object belonging to the standard sequence and call the starter message or service for that secuence.

If the answer is no, I'm keep on thinking.

MCH

[Brett Bailey]

Yes, There is a single entry point for the whole thing.

I'm not sure I understand your answer, I include the first object (not last?) from the standard sequence and just model the extra interactions.

Can I show at which point in the standard sequence the extra interactions take place?

~Brett

[Rob_M]

A use case extension (i.e. extends relationship), by definition, is an optional flow path the use case can take. The use case can complete its main path just as well without taking the extension path.

Modelling optional paths on sequence diagrams is difficult unless you move to UML 2.0. The optional path on a sequence diagram can be modelled with 'ref' (more like a call) and 'opt' (similar to an if statement) interactions. (I believe in EA 4.0 they are identified as 'fragments'.)
You essentially 'refer' to another interaction, which in the case of Use Cases, can be the extension.

So you could have two sequence diagrams, one showing the main path of the primary use case, and one showing the main path of the extension.  The primary sequence diagram 'ref's the extension sequence based on some condition.

Have a look at UML 2.0, as well as downloading the EA 4.0 beta and look at the new sequence diagram fragments. That should give an idea on how this can be modelled.

This can be simulated somewhat in EA 3.6 by dragging the extension sequence diagram onto the primary sequence diagram, then changing the text to mimic a ref interaction. Also change the border to make it 'look' more like an interaction.

Rob

[Brett Bailey]

thanks, that makes sense.

~Brett