Registered: Apr 2003
Location:
Posts: 18

Hi,

Is it possible for a use case to include another usecase which requires another role to initiate it. I mean both the usecase have different actors(roles) or roles are different.



Regards
Arun

Report this post to a moderator | IP: Logged

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

I dont think it would make any sense. A use case "execution" is a single interaction, initiated by an actor. It may involve other actors as non-initiators, but I cant see how a different actor could initiate part of a use case. The original initiator would be waiting indeterminately on an un-notifiable action by the other actors.

Consider this, I am going to build a house. I start building happily but stop when I get to the point where the plumber has to come in and run the pipes - but I am never going to tell him that I want the job done. I expect the plumber to initiate this. Is he ever going to do the job? Not likely.

In other words, there would have to be some notification from the original use case to the actor involved in the extending use case in oprder for that actor to know that they need to initiate the extending use case.

Perhaps this notification is what is missing from your model?

hth
Bruce

Report this post to a moderator | IP: Logged

Registered: Apr 2003
Location:
Posts: 18

Hi sargasso

I noticed this in one of the UML2.0 books. I don't know whether it is due to my wrong understanding.

Can a no-initiator have association relationship with the usecase?



Regards
Arun

Report this post to a moderator | IP: Logged

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

Absolutely, consider a use case that achieves a batch transfer of todays transactions from the subject system to another system via a push interface using, say, an FTP client to do the push.

Use case name: "Daily batch transfer"
Actors: <<Clock>> initiates the use case at 7:00pm
<<FTP client>> performs the transfer.
Notes: At 7:00pm each day (365/7), the system automatically prepares a file containing the details of each transaction that occurred on the node and invokes a transfer of that file (to the accounting system) via the FTP client.

That is to say, a use case can have any number of actors involved in it. However, only one could - to my thinking at least - initiate the use case.

Some tools / techniques let you put arrowheads on the use case model diagrams to indicate the "direction" of the interaction. That is, whether the actor is involved as a "initiator" or a "participant" ( for want of some better words). Some purists dont like the arrowheads - stiff cheddar to them I say! If it make sense use it - if it doesn't - then find something that does. The only thing to remember is that an arrow head on a use case diagram does NOT indicate the direction of a message flow!

Report this post to a moderator | IP: Logged

Registered: Apr 2003
Location:
Posts: 18

Thanks for the detailed reply.

I have got one more doubt. what should I do If same set tasks initiated by an actor are performed by more than one usecase initiated by different actors.

For e.g.

File transfer steps initiated by FTP client can be used by some other scenarios need not be always for the batch . I mean explicit invocation

What relationship I sould show between these usecases and the generalised ftp transfer use case.

Regards
Arun

Report this post to a moderator | IP: Logged

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

If I read you correctly, that is the FTP invocation would be made at a particular point in the execution scenario of another use case, then in these other models the FTP would be an <<inclusion>> use case associated with the primary interactive use case.

Are you trying to show all use cases on a single diagram? Is this what is causing the issue?

Consider using different models to better communicate what is happening in the differnet scnarios. Use case models are there to illuminate the activities that the system is involved in, not to obscure them. I find that breaking the use case models up into packages that relate to different business or usage groups often allows the reader to better understand the models and to allow focus on the particular nuances of a group. There is no rule that says the same use case cannot appear in more than one model.

Report this post to a moderator | IP: Logged

Registered: Apr 2003
Location:
Posts: 18

Hi Sargasso,
Yes you got it correct.

What if the FTP is an explicit call? Here FTP is just an example but in real time situation we can have similar situations like this.

We are not showing all use cases in a single diagram, we have different packages.

Regards
Arun

Report this post to a moderator | IP: Logged

Registered: Oct 2003
Location: Sydney, Australia
Posts: 22

Sorry Arun what is an "explicit call"?

Report this post to a moderator | IP: Logged

Registered: Apr 2003
Location:
Posts: 18

Explicit Call , some actions which the role has to initiate/invoke explicitly.

---------------------------------------------------------------------------
"FTP would be an <<inclusion>> use case associated with the primary interactive use case."
----------------------------------------------------------------------------

In the above case suppose the primary interactive and FTP is another actor. I mean FTP is explicitly initiated by an actor (for e.g. Administrator)

In this case can I show inclusion relationship between the use cases?

I am almost sure we can't. But I need more ideas to substantiate this

Regards
Arun

Report this post to a moderator | IP: Logged

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

code:

C  --uses-->   (UC002)
 
D  --uses-->   (UC002)  --??--> B

code:

A  --uses-->  (UC001) --includes-->  (UC002)  --???-->  B
                      C --uses-->
                      D --uses-->

Report this post to a moderator | IP: Logged

Registered: Apr 2003
Location:
Posts: 18

Sargasso

Thanks for the detailed reply.

FTP Example:
No way related FTP but some similiar cases.
As you said I also prefer to model them seperately

Regards

Arun

Report this post to a moderator | IP: Logged