I have a use case that is associated with two actors in a system. This use case extends another use case, but only one of the actors can use the extended use case.
Is there some way to represent the conditional nature of the extension of the first use case? Or, do I need to specify in the use case documentation that the initial use case can only possibly be extended for one kind of actor?
Thanks.
If I understand the question, it sounds like you need two kinds of actor. You (possibly) need to make one actor type a generalisation by abstraction. To put it another way, you need to create a specialised actor who inherits permissions of the more general actor.
( Please excuse my horrible ascii people and generalisation arrow!)
O __________________
--- / \
| -----------| Use Case 1 |
/ \ |__________________|
| extension points |
User | if Super User |
^ \__________________/
/ \ /\
/___\ | <<extend>>
| | (if Super User)
| |
| |
O _________________
--- / \
| -----------| Use Case 2 |
/ \ \_________________/
Super User
This specialised actor (Super User) can then engage in both use cases, but the normal user only the first one (the non-extending use case).
Note that a Super User may or may not be able to initiate directly use case two. It depends on the use case and the problem domain as to whether that makes sense or not.
You then probably want to use an extension point (something like "Super User" or "if Super User") in the extended use case which creates a decision point to the extending use case.
Here's an example of a more legible diagram.
Also here's the definition of extension point from The UML Reference Manual (2nd Edition) (p358):
A named marker that identifies a location or set of locations within the behavioural sequence for a use case, at which additional behaviour can be inserted.
The name of the extension point name can be whatever you want. Whatever makes sense to you. There are no syntactic rules. Whatever you put on the diagram should appear somewhere in a textual use case description (i.e., the steps of the use case).
Related
How do you show specialization in a UML diagram when two specialized entities could also be each other. For example:
[Personel]
^
/_\
|
------------
| |
[Employee] [Manager]
Typically, I'd use the empty arrow to show specialization, but how do i show that an employee or manager could also have the other role in some instance? Do I just need to use a line to connect them?
In the most common form Generalization is mutually exclusive. You are either one subclass or the other, but never the two at the same time.
For the example you used you better use the Party-PartyRole pattern.
Employee or Manager are Roles a person can play. With this pattern you can be both Manager and Employee at the same time.
I have this use case, suppose named A, which is in nature an extension of both use cases B and C.
Is there a standard way to illustrate this?
For example is this true?
In UML, you can have an extension of several main use cases at a time without problem.
As for the link you provide, I'd connect the actor to B and C instead of A, because B and C are the "main" use cases. The actor that launches A is the actor that performs the main use case. In this way you could even have a different actor for B and C, and naturally A would be done by one or the other depending on the main use case.
A use case extends 0..* use cases, and is extended by 0..* use cases, but note that the arrow is drawn from the extending use case to the extended use case. In your diagram there is a single base (extended) use case, namely A.
An extend relationship between use cases is shown by a dashed arrow with an open arrowhead from the use case providing the extension to the base use case [UML/2.4.1/Superstructure§16.3.3].
Is it legal to draw up an include relationship between two use cases that are each associated with a different actor?
Yes this is legal, but I think it should not interpreted as #vainolo suggested.
Suppose this scenario
In this case Actor X has direct access to Use Case A and because Use Case B is included by Use case A Actor X also executed the behavior described in Use CAse B
But only Actor Y has direct access Use Case B.
Actor A only has indirect access through Use Case A
At least that is how I interpret it. The UML specs will only tell you this is a valid UML syntax but will not say much about the meaning of such a scenario.
It's completely legal. What this means is that if the including use case calls the included use case, the actor that is connected to this use case is required.
In UML, when drawing a use case diagram, can I include the already included use case? (Or extend the already extended use case?)
Does it make sense? I have such a situation where I think I can include B in A and include C in B; where A, B, C are all use cases.
A ----------------> B ----------------> C
<<include>> <<include>>
Dose it technically make sense?
Technically, it is possible to do what you mentioned, if it fits your scenario. But just remember, use 'include' usually to abstract sequences of steps out of the primary Use Cases that are helpful to the analyst to avoid repetition. This means it comes into picture after you have completed at least the first cut basic flows for all your main Use Cases. The main purpose is to simplify your use-case diagram, not to complicate it.
It depends on whether the usecase A is being called from C directly and not within the scope of B. If A is being used by C directly, then it makes sense to draw that in your C use case and qualify A as included. Else you could ignore.
can two use cases extend or include each other at the same time?
A extend/include B and B extend/include A
I'm pretty sure the answer is "NO".
You've just described the digital equivalent fo the chicken and egg problem.
Circular references are [almost] always Bad Things (tm). The only place I know it to not be horrible is in the context of a linked list, in which each entry has a pointer to another of its own type.
If (A includes/extends B and B includes/extends A) then A = B
Admitting that if A extends/includes B then A >= B
It seems likely not, though I'm sure you could do it if you went generic [and useless] enough. Do you have a specific example? There are always exemptions to the rules and I'd be curious to see one.
below is the senario for business use case (business modelling) not system use case:
USE Case A: Service Vehicle
Use Case B: Authorise Additional repair
Use Case C: Repair Vehicle
Additional repair could be identified during initial repair.
or repair could be identified as a new repair during service,
in both case, customer authorisation is required?
A extend B and B extend C (authorisation and start of repair identified during service)
C extend B (authorisation for additional repair identified during repair)
It's rare but in the general case, there's nothing that prevents use cases from including/using each other.
the answer is no. extend and include are mutually-exclusive relationship types. Most likely the use-cases are incorrectly factored/separated, or you've misunderstood the extend/include relationship definitions, or both.
given the example you posted (fyi it is better for you to edit the question rather than post an answer that does not answer the original question) i would venture that B extends A and B extends C, since in both cases A and C additional repairs (case B) may be identified.
alternately, use cases A and C could conditionally include use case B
offhand, i would model this as Work On Vehicle, which is a composition of 2 use-cases, Obtain Customer Authorization, and Service Vehicle, where the latter includes any kind of service or repair and requires the output of the former before starting the work. The notion of 'additional repairs' is just another instance of Work On Vehicle.
but i don't know the full business context, so your mileage may vary ;-)
EDIT: you wrote "but in this case: work is being carried out and further authorisation is required during the course of work", but i don't see how that really matters.
the first step is to eliminate the confusion about includes and extends. Try modeling each use-case completely and independently, and then look at what is common to see if includes/extends is warranted
"YES" - Checked the Spec.
I just read through the UML specification section for use cases:
http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/
There was no rule that would prevent doing this that I could find. Many people may conceptually have a problem with this, but that is ok, as you are just instinctively trying to objectize or structure use cases logically. Use Cases are a behavior (or set) and are not like classes/"objects". We are not talking about Java objects.
Even in Rational Software Modeler (IBM) allows this "circular reference".
In practice and in trying to map this to Java or other Object languages it may not make sense or get confusing.