It's not a secret anymore!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Can a usecase diagram be an actor for some other usecase diagram ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Can a usecase diagram be an actor for some other usecase diagram ?" Watch "Can a usecase diagram be an actor for some other usecase diagram ?" New topic
Author

Can a usecase diagram be an actor for some other usecase diagram ?

Pratibha Malhotra
Ranch Hand

Joined: Dec 21, 2003
Posts: 199
Can a usecase diagram be an actor for some other usecase diagram ?


~ Pratibha Malhotra<br /> <br />Sun Certified Java Programmer<br />SCEA 1.4 (In Progress)<br />~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />"Many of life's failures are people who did not realize how close they were to success when they gave up!!"
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
Yes, sure.

One actor, can have in multiple use case. and you can extends actor.


SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
Pratibha Malhotra
Ranch Hand

Joined: Dec 21, 2003
Posts: 199
What i mean is,

use case 1 -----> usecase 2

ie case a use case diagram act as an actor for another use case diagram..
Vagner Freitas
Ranch Hand

Joined: Aug 02, 2004
Posts: 85
Hi Rewa,

I'm not sure, but I think an use case can't act like an actor of another use case. An use case can have "include", "extend", "depend" or "generalize" another use case.
An use case represents a interation between an actor and a sistem, how can you represent a interation between two use cases?

Vagner


SCJA, SCJP, SCBCD & SCEA (Part I)
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
I believe I've run into cases in which this does happen.

For example, let's say you're going to create an online ordering system. One of the requirements of the system would be to, obviously, order an item. Perhaps another requirement is that the user should be able to query the system to see if something is currently in stock. Therefore, you might come up with these use cases:

Order Item
Query Item In Stock

If you think much about the Order Item use case, you'd probably soon realize that, before you order an item, you should first query to make sure that the item is in stock. So, while the user is interacting with the "Order Item" use case, during part of that process, you'd be executing the same process as "Query Item In Stock." That would make it seem as if the Order Item use case was the "actor" of the Query Item In Stock use case.

My UML (and certainly my terminology) is a little rusty, but I believe this is considered a "depends upon" relationship (perhaps it's an include). In this case, one use case "depends upon" another. How you look at it is probably up to you - some people might say that one use case is the actor (the initiator) of another use case while others would say that the actor is the user - even though you're executing a different use case than what the actor initiated, the user is still the one that started the whole process. What's the right way to look at it? I don't know - I'll leave that to the experts.
[ October 28, 2004: Message edited by: Corey McGlone ]

SCJP Tipline, etc.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I haven't found the distinctions between "uses" and "extends" another use case very interesting. Knowing that one has some relationship to the other is enough information to tell me I need to read them both before developing either.

That said, for our team we decided "uses" is like a subroutine. Many use cases "use" customer search. Step 4 of some flow might say See Customer Search. "extends" is more like B does all that A does and then goes on to do some more.

Again about all I need to know is that they are related and I should understand them together.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Sunder Ganapathy
Ranch Hand

Joined: Apr 01, 2003
Posts: 120
An Actor is external to the System being modeled . An Actor is only a role
played . I read recently that while translating the original works of Ivor Jacobson, it was a mistake to use the term 'Actor' instead of 'Role' while
describing Usecases . Well, when an Actor is external to the system, one usecase being input to another usecase can be explained with terms like 'extends' or 'includes' depending on the situation if one is a case of reuse or a behavior executed in optional circumstances .
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Although Sunder's explanation sounds accurate, I think I'm more inline with what Stan said prior to that. Although you can get very carried away talking about exactly how one use case interacts with another, it's usually going to cost you more time to make that distinction than it would be to simply read both use cases.

In my (granted, rather limited) experience, I've never worked in a place in which everyone knew all the "ins and outs" of UML and/or use cases. In general, people had a good feel for them but, if someone started adding seldom used decorations to the diagram, those trying to use the diagram would have to go back to the author and ask what they were - or simply read both use cases to figure out what it meant in the first place.

To me, it's good enough to simply know that 2 use cases interact in some way. Maybe one does everything another does and more. Maybe one kicks off another one. The fact that they are associated on the use case diagram is enough for me to know that I should understand them both before going to work on either.
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Corey McGlone:
I believe I've run into cases in which this does happen.

If you think much about the Order Item use case, you'd probably soon realize that, before you order an item, you should first query to make sure that the item is in stock. So, while the user is interacting with the "Order Item" use case, during part of that process, you'd be executing the same process as "Query Item In Stock." That would make it seem as if the Order Item use case was the "actor" of the Query Item In Stock use case.

My UML (and certainly my terminology) is a little rusty, but I believe this is considered a "depends upon" relationship (perhaps it's an include).
[ October 28, 2004: Message edited by: Corey McGlone ]


There are two ways of looking into this.

1. If the 'query' happens ONLY as a part of the 'ordering' (that is, no one independently queries for something), then the "Order Item" would <<include>> "Query Item in Stock".

2. If the 'query' can be performed even without ordering anything, then, the "Order Item" would <<depend upon>> "Query Item in Stock".

In both cases, these are still use cases - which means, they are actions performed by the system or processes of a system. They are still acted upon by someone else - like the person 'ordering the item' or 'querying the item'.

In both cases, the actors are entities outside the system, acting on the system, resulting in the system performing a use case.

In short, a use case will not be an actor for another use case. However, the use case may depend upon or include other use cases in order to complete its process. This is slightly different from being acted upon.


Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Sunder Ganapathy
Ranch Hand

Joined: Apr 01, 2003
Posts: 120
One thing that must be kept in mind is that Usecase diagrams are not the
important one. It is the Usecase text which is important . Actually writing
effective Usecases adds value than drawing Usecase diagrams showing
extends / includes . In the Systems developed by us, we give utmost importance to the text portion than the diagrams . We also ensure that the
Usecase texts DO NOT exceed a page at the most, keeping in mind the
comprehensibility of the issue at hand .
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
There are a couple of interesting issues here:
1. If you want to show a use case on a sequence diagram, it's perfectly legal. See my example at http://www.agilemodeling.com/style/sequenceDiagram.htm#Figure3 .

2. Use case diagrams are not actors, period. Actors represent roles which people, organizations, or other systems take with respect to whatever it is that you're modeling. If the other use case diagram represents the usage requirements for another system, then show the other system as an actor.

3. If you want to create a hierarchy of use case diagrams, use packages. See http://www.agilemodeling.com/style/packageDiagram.htm#UseCasePackageDiagrams for an example. You may also find the discussion at the top of http://www.agilemodeling.com/artifacts/useCaseDiagram.htm to be of interest.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Originally posted by Sunder Ganapathy:
One thing that must be kept in mind is that Usecase diagrams are not the
important one.


I've almost always ignored use case diagrams, but recently realized it was largely because our actor list isn't very interesting. Then we started talking about a "lite" version of our app for people outside our normal user groups. Suddenly which actors work with which use cases got very interesting. For a day.
 
wood burning stoves
 
subject: Can a usecase diagram be an actor for some other usecase diagram ?
 
Similar Threads
sequence diagrams
Seq Diag: Customer vs. Travel Agent
about sequence diagram
A question about uml use cases , should i use include or extends ?
When "extend" stereotype in UML can be used?