Common use cases

[mhdhallak]

Hi guys

Simple question:

I have two actors: a Mobile Worker, using a handheld device, and a Backend Worker, using a backend application. Both actors descend from a generalized User actor.

Both actors have to login to the system. (hence Login UC)

Is it appropriate to have one Login UC associated with the User UC or should I have seperate Login UC for each actor since the interface of the UC will be different?

Just little something I have been thinking about.

[thomaskilian]

Yes, that's appropriate. All specialized users will inherit from the general User and thus are involved in the same UCs. The goal is the same for any user, hence it will be the same UC.

[Paolo F Cantoni]

Hi guys

Simple question:

I have two actors: a Mobile Worker, using a handheld device, and a Back-end Worker, using a back-end application. Both actors descend from a generalized User actor.

Both actors have to login to the system. (hence Login UC)

Is it appropriate to have one Login UC associated with the User UC or should I have separate Login UC for each actor since the interface of the UC will be different?

Just little something I have been thinking about.

Just echoing Thomas' point, and referring back to Question about optimizing actors catalogue

You need to ask the question, since both descend from User, does every User have to Login?  If the answer is Yes, then you move the UseCase up to User.  Then there's only one.  You may need to use additional lower level UseCase to modify the paths for each user type, but that's in the detail.

Paolo

[mhdhallak]

Just echoing Thomas' point, and referring back to Question about optimizing actors catalogue

You need to ask the question, since both descend from User, does every User have to Login?  If the answer is Yes, then you move the UseCase up to User.  Then there's only one.  You may need to use additional lower level UseCase to modify the paths for each user type, but that's in the detail.

Paolo

Exactly. I've taken that into consideration and moving it up to the User level is the right thing to do since all decending actors have to use this UC.

But I don't get how you would use lower level UC to modify paths? Is  this UC generalization/specialization?

If so, then since Mobile Workers and Backend Workers have different interface (different platform) for performing this UC, does this call for this sort of specialization?

[«Midnight»]

Try thinking abour who does what - or where things are actually happening in the system.

At the scope where you are talking about logging into the system, you will probably see something analogous to logging into a network with a PC. The user is asked to provide a username and password, regardless of whether the user is an administrator, operator, guest or whatever. Thus, you only have a single use case, and it is at the level of the (perhaps abstract) User actor.

If you need to model the determination of privileges for different roles, you can once again look at the login example above. When a user logs in, the system determines what role (or roles) the user should receive and applies the necessary privileges, restrictions, and environmental attributes. This is another use case, but at a different scope and level. Here the primary actors are system components, while the User actor is a secondary actor. In fact, you might create specific use cases - or fragments thereof - which address various user roles. In each such case a concrete specialization of the abstract User actor might appear as the secondary actor.

HTH,
David

[Paolo F Cantoni]

Exactly. I've taken that into consideration and moving it up to the User level is the right thing to do since all descending actors have to use this UC.

But I don't get how you would use lower level UC to modify paths? Is this UC generalization/specialization?

If so, then since Mobile Workers and Back-end Workers have different interface (different platform) for performing this UC, does this call for this sort of specialization?

Now that you have moved the UseCase up one level of genericy, the use case at that level should be pretty common.   Remember, an objective should be to keep both sets of interactions as common as possible.  You can use «extend» to add differentiators where the UseCase needs to vary depending upon the Actor.  Note, I didn't say the platform...  Your UseCase should be dealing with the essential (as in "of the essence") aspects of the interaction - not the implementation details (platform).

Does that help?
Paolo

[mhdhallak]

Now that you have moved the UseCase up one level of genericy, the use case at that level should be pretty common.   Remember, an objective should be to keep both sets of interactions as common as possible.  You can use «extend» to add differentiators where the UseCase needs to vary depending upon the Actor.  Note, I didn't say the platform...  Your UseCase should be dealing with the essential (as in "of the essence") aspects of the interaction - not the implementation details (platform).

Does that help?
Paolo

Absolutely. I had a little doubt (being the UML newbie that I am) of whether a platform or implementation-specific things would affect UCs in anyway but now I know they shouldn't.

Thanks Paolo, David, Thomas  

Cheers