Reusing a Use Case, generic or template?

[anton.chertok]

Hi All,

a colleague is modelling a system and has asked me if it is possible to make a generic type of Use Case, he has has several system use cases that do a similar thing (following is 3 steps in a basic scenario for the use case):

1 - System A sends request to System B
2 - System B validates request
3 - User gains access System B

This scenario plays out between 3 different systems in an authentication protocol (sort of a proxy oidc authentication), in the first use case, A is a relying party and B is an authentication proxy, in the next use case A is the proxy, and B is the identity provider, same basic path scenario in both, just different source and targets.

Is it possible/wise/appropriate to somehow have a generic (super-class?) Use Case , and have other use cases as sub-classes or implementations of the use case, a-la OO classes?

Or is it better to just clone one to create the other, no inheritance or relationship between them, then change the source and target systems, and some labels (or have some sort of template use case)?

The rationale is that we don't want to create unnecessary objects, and to re-use if possible, or is this idea taking that concept too far (this is a business process model, not a class diagramme)?

I was a bit stumped by this, so I thought I'd throw it to the community.

Cheers.

[qwerty]

Generalizing use cases is, to be polite, absolute humbug. You are trying to tell the added value of a system brought to it's actors. And if you have a general use case, where is the added value? Something general??

I'm just thinking you're talking about a scenario being used in various use cases, like the validation of something. Well, if there's something like that, the class design guys should take care and design their libs/components in a way that this functionality is available somewhere. but definitely, it's not a use case.

q.

[anton.chertok]

Generalizing use cases is, to be polite, absolute humbug.

Yeah, the whole idea sounds wrong to me, so I agree to your sentiment, but I promised the guy I'd throw it out here for the community to comment on

Bring it on 

[Geert Bellekens]

What you are describing seems exactly what including use cases has been invented for.
You have a shared serious of steps that are to be executed by several use cases.

You can extract these steps into a separate use case and include it in all the others.

Geert

[anton.chertok]

You can extract these steps into a separate use case and include it in all the others.

I can embed/inherit/include a use case in a use case? Or have I misunderstood you?

Side note: what's with the reCAPTCHA? I have to click it 20 times to prove I'm not a robot???

[KP]

You can extract these steps into a separate use case and include it in all the others.

I can embed/inherit/include a use case in a use case? Or have I misunderstood you?

Side note: what's with the reCAPTCHA? I have to click it 20 times to prove I'm not a robot???

From UML 2.5 specification:

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition ) is
inserted into the behavior of the including UseCase (the includingCase ). It is also a kind of NamedElement so that it can have a
name in the context of its owning UseCase (the includingCase ). The including UseCase may depend on the changes produced by
executing the included UseCase. The included UseCase must be available for the behavior of the including UseCase to be
completely described.

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This
common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the
primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in
itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the
base UseCase depends on the addition but not vice versa.

All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the
including UseCase is resumed.

The Include relationship allows hierarchical composition of UseCases as well as reuse of UseCases.

Regarding the captcha, no idea. It clearly doesn't work 100% because I am having to delete spam posts every day...

[Geert Bellekens]

I can embed/inherit/include a use case in a use case? Or have I misunderstood you?

Embedding, inheriting and including use cases are three different things.

- Embedding means you nest a use case under another use case (ownership). I don't really see the point in doing that.
- Inheriting means you have a generalization relation between use cases. (UseCaseA is a UseCaseB) Haven't seen much useful constructs like that as there is really a standard defines set of rules that determine how this generalization will manifest itself. (unlike in Class generalization where we know exactly what happens if you inherit from another class)

In general I only use include, and only if I have a reasonable chunk of behavior that is shared between use cases.

Geert

[Paolo F Cantoni]

See in-line...

I can embed/inherit/include a use case in a use case? Or have I misunderstood you?

Embedding, inheriting and including use cases are three different things.  <<<=== YES!

- Embedding means you nest a use case under another use case (ownership). I don't really see the point in doing that.  <<<=== NO! Embedding is NOT Nesting! (but in both cases, there's not much point)
- Inheriting means you have a generalization relationship between use cases. (UseCaseA is a UseCaseB) Haven't seen much useful constructs like that as there is really a standard defines set of rules that determine how this generalization will manifest itself. (unlike in Class generalization where we know exactly what happens if you inherit from another class)

In general, I only use include, and only if I have a reasonable chunk of behavior that is shared between use cases.

Geert

In graphical terms Embedding means placing one object inside the shape of another.  Nesting is not a graphical term, but a structural one.  Embedding may imply nesting, but it need not (and in Archimate - notionally doesn't).

Paolo

[qwerty]

I only can recommend Bittner/Spence. Use case synthesis is a rather simple thing. But sometimes simple things are harder to understand than complex ones. IT people tend to analyze things and dissect them once they start with it. But UCs are just the other way around. I always see the same sort of questions (yes, I had them too in the beginning when working with UCs). The only remedy is to understand what UCs are good for. It's like teaching people Zen. So simple. So difficult.

q.

[Richard Freggi]

I only can recommend Bittner/Spence. Use case synthesis is a rather simple thing. But sometimes simple things are harder to understand than complex ones. IT people tend to analyze things and dissect them once they start with it. But UCs are just the other way around. I always see the same sort of questions (yes, I had them too in the beginning when working with UCs). The only remedy is to understand what UCs are good for. It's like teaching people Zen. So simple. So difficult.

q.

What q. said.  Really good and easy book.

[Paolo F Cantoni]

I only can recommend Bittner/Spence. Use case synthesis is a rather simple thing. But sometimes simple things are harder to understand than complex ones. IT people tend to analyze things and dissect them once they start with it. But UCs are just the other way around. I always see the same sort of questions (yes, I had them too in the beginning when working with UCs). The only remedy is to understand what UCs are good for. It's like teaching people Zen. So simple. So difficult.

q.

Is that: Managing iterative software development projects / Kurt Bittner, Ian Spence?

Paolo

[matthew.james]

Is that: Managing iterative software development projects / Kurt Bittner, Ian Spence?

I'm guessing "Use Case Modelling" by the same guys

[qwerty]

As mathew.james said. Just google for "bittner spence use case".

q.

[Richard Freggi]

Yes that one and when you finished it (a couple of afternoons max), "Applying use cases" by Schneider and Winters is a great next step.

By the way to the original poster: what you are describing below is best modeled via a sequence diagram
1 - System A sends request to System B
2 - System B validates request
3 - User gains access System B

What request is sent?  What classes are impacted by that message? What objects sent, what operations invoked?  How does that change your class diagram?  How about the validation?  That's where things get interesting.

[Glassboy]

What request is sent?  What classes are impacted by that message? What objects sent, what operations invoked?  How does that change your class diagram?  How about the validation?  That's where things get interesting.

I suspect it is something like OAUTH or SAML (or even Kerberos) and there is a lack of good available sequence diagrams for those protocols, which is odd given that they are fairly well understood.