• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can a usecase diagram be an actor for some other usecase diagram ?
 
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, sure.

One actor, can have in multiple use case. and you can extends actor.
 
Pratibha Malhotra
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What i mean is,

use case 1 -----> usecase 2

ie case a use case diagram act as an actor for another use case diagram..
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Sunder Ganapathy
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 .
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic