Grady Booch, please help !!!

[Rudi Vaum]

Originally posted by Jitender Bhatia:
Using another Use Case as a object [in a sequence diagram], is that correct UML ??

I really had to search a lot for this, but I found it in the 17th UML book I reviewed- so i guess it is legitimate.
I'm also getting a bit nerved by the secrecy arround these subjects ;-). There must be some source for examples, that show such uses. UML has been around for a while. Everything you get from books are relatively basic diagrams.
Anybody, heeellllp!
Rudi
PS: Should we invite Grady Booch or some other amigo to clear this?
Has anyone got his email? ;-)
I am actually afraid of the fact that he'll be telling us to use UML (and extend it) as we consider best, and not think that much about little detailes.

[Ajith Kallambella]

One usecase calling another usecase is pretty common however, I have not seen usecases being referred directly in sequence diagrams. What I have seen( and used) is actors being used in seq. diagrams. For instance, you can model a whole subsystem as an actor("payment processing") and use it in the seq. diagram.
If I were you, I will not be using those "rare" UML features and find a way around to represent the same concept in a more standardized way that employs common and easy to understand notations. I am not sure if you have a situation that makes this option inevitable, so I cannot offer you alternatives.
[ May 27, 2003: Message edited by: Ajith Kallambella ]

[Stan James]

One of our Rational mentors used to hammer on me that "a use case is not a subroutine" because I was trying to do functional decomposition on use cases. Referencing a use case in a sequence diagram makes it look a lot like a subroutine. I'd try not to.

[Rudi Vaum]

First, thanx for your answers.
Well, now I tend to agree with you..
After all, it's 2 against 1 ;-)
So what are my options?
Suppose I had: "After confirming the order, the 'Pay' Use-case is executed"
- use an actor an name it "Payment Processing"
- make a note (standard UML adnotation) saying: "Here you Pay / Go to Pay Use-Case"
I really do not like the last one..
Sheriff Ajith, could you tell me in which UML book (or a internet link) I could find such details described? Like things that are ok to do, and things one shouldn't do?
It's just that I wannt to be able to justify my decisions. Not only to Sun, but to a potential developer, you know what I mean?
Thank you,
Rudi
PS: is [email protected] the right address ;-) ?
[ May 27, 2003: Message edited by: Rudi Vaum ]

[Ajith Kallambella]

Sheriff Ajith, could you tell me in which UML book (or a internet link) I could find such details described? Like things that are ok to do, and things one shouldn't do?
[/QB]

http://www.modelingstyle.info/sequenceDiagram.html

[Rudi Vaum]

You just found my second use-case call in a seq. diagram i've seen, right?
http://www.modelingstyle.info/sequenceDiagram.html#Figure3

[Stan James]

That's interesting, awright. I guess I have no real problem with it. Syntactically allowed or not, it tells me what he wanted to tell me and that's what counts.
But he's at a level of abstraction where he shows the <<controller>> for the main use case he's diagramming ... why not show the <<controller>> for the "used" case and be consistent?

[Alex Paransky]

The basic principle behind a Use Case is that it should provide some value to the actor who is corresponding with such a use case. Some use cases could be: Open New Bank Account, Register for BLOG, Transfer funds. Use cases such as: Update Database, Write Log Record, Begin Transaction do not really provide any value to the actor, unless of course, your actor is another system to which Begin Transaction has some value.
On the issue of Use Cases calling other Use Cases, I believe, it is wrong to call it �calling�. A better term is �includes�. For example, Open Bank Account use case could include a Transfer Funds use case in it. Transfer Funds, use case could include Deposit New Funds use case in it.
As another writer pointed out, use cases, are not functions or subroutines that can be called. They are really composed of multiple scenarios. I suppose for the purposes of modeling scenarios one could use state transition or sequence diagrams, however, use cases and code are at different Meta-levels, sort of speak.
-AP_
http://www.myprofiles.com/member/profile/apara_business