sargasso
...
Registered: Oct 2003
Location: Sydney, Australia
Posts: 22 |
Arun, I think we're pretty close here.
Actor A invokes the primary (interactive) use case, say UC001.
At some point in the steps involved there is an unconditional invocation of a second use case. This second use case, say UC002, involves interactions with another actor (say Actor B).
In addition UC002 may be involved in other business scenarios that involve an entirely different actors (say C & D ) and do not involve UC001, but may or may not involve Actor B.
Here, I go with the one dimensional diagramming tool again.
Scenario 1
========
code:
A ---uses---> (UC001) ---includes---> (UC002) --???--> B
( I haven't decided on what label or stereotype to place on the right hand side association yet)
Scenario 2
========
code:
C --uses--> (UC002)
D --uses--> (UC002) --??--> B
Note I have used the direction arrows. These indicate that B does not initiate the use case but does interact with it (explicitly). Also to me it is clear that the two scenarios are different as they are in two different diagrams. The actors involved in the scenarios differ and it is clear where they do and do not interact. If I tried to combine them I would loose the simplicity and clarity of the scenarios, as :
code:
A --uses--> (UC001) --includes--> (UC002) --???--> B
C --uses-->
D --uses-->
implies, to me, that Actor B is always involved in UC002.
Getting back to our FTP example. Is your model soimething like:- "during the day AnyClerk enters transactions into the system and then at the end of day batches them up for posting - but each batch has to be approved by the supervisor before posting (via FTP)."
This I would model as completely separate use cases, say "MakeBatch" and "ApproveBatch" with no association between them at all. MakeBatch also has no reference to the FTP transfer initiation.
Report this post to a moderator | IP: Logged
|