How to extend a use case from the Scenario Builder

[Michael Albers]

Hi,

I just seem not to be able to grasp this. I've searched a lot, but can't find an answer. I might be using the wrong terms while searching, in which case I apologize if the answer is somewhere on the website or in the forum.

For instance, how would I get the extend relation in the Login use case on http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/standard_uml_models/usecase.html in a scenario.
Should it be a step on it's own? Is it an alternate path, since it is optional?
And how would one get another extend relationship in a scenario as well?

In my situation  I have a use case similar to Add hotel and in that use case it should be possible to optionally choose the use cases Add hotel chain and Add loyalty program.
I think the correct activity diagram should be like this: https://flic.kr/p/rrwDU1.
If this isn't correct, I would appreciate it if someone could point me in the right direction.

These use cases are fictional, but the issue is exactly the same as my issue. My contract prevents me from talking about the real deal to third parties.

Thanks,
Michael

[qwerty]

My few cents: this is a very bad example. Login is not a use case at all! It does not bring any value to the actor. It is a simple constraint needed for any use case behind.

Second: do not use include/extend. Use cases are synthesized. You will not do a functional analysis here. There are only very few cases where they make a bit of sense. But in most cases they just are wrong.

I recommend to read Bittner/Spence.

q.

[Michael Albers]

Thanks for answering. I will check out Bittner/Spence.

Anyway, I'm still learning, but I guess whether login is a use case or not, is a whole debate on itself where you have supporters on both views.
I would say it is, because the value of an actor is to use the system, which  is not possible without login in my particular project.
Also, if it isn't a use case, then each use case should have the steps: user logs in, system authenticates and this means there is a lot of duplicate content, which is turn not the best practice maintenance wise

Second, isn't include and extend used for respectively mandatory and optionally 'using' other use cases and being able to reuse those other use cases?

Additionally, how would you make an activity diagram with multiple options that can be chosen in any order and as many times as needed?
What's your opinion on the linked activity diagram? My goal is to have a page where someone adds details about the hotel and adds a hotel chain and/or a loyalty program but also has the option to go to the page for adding those if they are not already available as a choice.

Lastly, I wonder if you just stated that Sparx is wrong with a quite a few examples on their website. ;)

[qwerty]

I just referred to this very example. And read my words: Login is not a use case, it is a constraint. If you make Login a use case (a use case is describe by a sentence with verb and subject and optionally an object) then you need to include it in ALL your use cases since none of them would work without. A login does not give me any value. I get value by doing something that is restricted by a login.

If your use case diagrams resemble a spider's web, your design is broken.

I will not deepen this discussion any more at this place.

q.

[KP]

Imagine this conversation with your boss...

Boss: What have you done to earn your pay this week?
You: Well, I have logged in...

See, it's not a use case! (With thanks to sargasso, former resident of this forum)

[Eve]

Imagine this conversation with your boss...

Boss: What have you done to earn your pay this week?
You: Well, I have logged in...

See, it's not a use case! (With thanks to sargasso, former resident of this forum)

And yet, there is a "Login" use case in our example model. I don't have a problem with that. Regardless of your views, if you want to describe how your login requirements (eg 3 factor identification) are implemented in your system you need to attach them to something.

Personally, if I was in that situation I would create a use case "Login to System" (it may also be relevant the role that is being played) I would then have a dedicated diagram showing the precedes relationship to anything that requires a log-in. Including it as part of other use cases (especially the scenario) seems wrong unless they need to login once for each action they perform.

It's about communicating. If a login usecase helps you to communicate something then go ahead. If it makes it harder for you, there's probably a better way to do it.

PS. As an aside, is reversing a precedes relationship the same as a not. I could say that Create Account -> precedes -> Login to forum. But that procedes has a very different scope to Login to forum -> precedes -> Reply to thread.

[AndyJ]

I'm going to chime in here.

One of my systems has a use case "Log in".

This is because the application delivers different functionality to logged in and non-logged in users.

It is also because, in this case, the login function is technically very complex, managing various states of users (connecting to multiple things on the back end, by a complex set of networks), joining and leaving patrols.

From memory, the complexities of log in were such, that it took the team considerable amount of time to get it working. (i.e. weeks).

Some of the other use cases have a PRE-CONDITION of log in, and others do not.

YMMV.  

[JohnDoe]

Maybe you should think about modelling business processes, instead of misusing UseCases as processes. Novice users tend to paint processes as UseCase diagrams, while BPMN is the more adequate diagram type to clarify processes. IMHO UseCases are activity chains that should fulfill a concrete atomic business step.

My common workflow for analysis is: BPMN for business flow, then UseCase analysis per BPMN step, then Activity diagram (with alternate/exception paths) per UseCase, then requirements and tests. That is my drilldown roadmap when writing specs. It helps a lot to jump back to business processes, when the client wants to overload UseCases.

[Geert Bellekens]

I agree with JohnDoe.

Geert

[qwerty]

+1 for JohnDoe

Most people tend to focus on technic rather than business.

q.

[Michael Albers]

Let's just say I'm happy I don't have a boss.

After reading up even more, I am convinced of your points of view.
But of course I could have written "Gain access to the system" instead of 'login' ;D

Anyway Bittner/Spence was ordered. Thanks for clearing this up.

Still leaves my original question open: "How would I get an extend relationship into a scenario?"

I know qwerty says stay away from extends and includes and I have read that on different sites as well. But, I just want to know how to do that if I want to use extends.

Login was merely an example I found on the Sparx website

[Geert Bellekens]

The thing is, you can't.
The scenario isn't supposed to know about extending use cases, so you can't say: at this point in the extending use case will be executed.

You can do that with includes, because there the direction is reversed. Your main use case knows about all the use cases it includes, and it decides when to execute an included use case.

With extends you only define an extension point. The extending use case links to that extension point to insert its behavior in that of the main use case.

Geert

[JohnDoe]

Please verify, that you don't mix business analysis and technical analysis.

[AndyJ]

I'm in agreement with the above concept regarding BPMN and then a jump to Use Cases.

To be specific, where you have an Actor (Participant, Swimlane) interacting with a System Actor (Participant, Swimlane) to achieve a particular business outcome/goal, then you have likely identified a potential Use Case.

At the lowest level of BPMN diagrams, you may have many interactions between users and systems which take place in a single Use Case but this is just because your BPMN diagram is showing things from a different view.

Having said all that. I try to rarely use include and extend relationships between Use Cases. They add complexity for the users.

Looking at my earlier example...

A pre-condition of "The Actor must be logged in to the system" takes care of relationships between the "Log on for Duty" Use Case, and the other Use Cases which require a logged in user.

[JohnDoe]

When I see heavy use of extends and includes, then UML modellers often enough misunderstand UseCases as a medium to model processes. Best approach is to NOT spend too much time in include and extend scenarios, but concentrate on BPMN process flows and derive atomic UseCases from these BPMN steps.

In a second step you can harmonize and reduce those UseCases and use extend/include associations to organize them, but this is done to reuse the number of UseCases to be implemented, but NOT to model processes.

You always need a business process guideline beyond the UseCases to give them a higher context and meaning from a business perspective.

Best approach is to regard a UseCase as an atomic function with a clear technical goal, well defined starting points and logical endpoints (ideal result, alternate result, exceptions path).

The easiest way to understand PBMN and UseCases is:  
One BPMN step INVOKES a UseCase.