I'm so confused about the difference between extension use case and parent use case in Use case diagram.
I would like to know when can I use the extend and when can I use the parent use case?
For example :
Print Slip extend Confirm
pay through PayPal inherits Payment.
pay through credit card inherits Payment.
What's the difference between inherits and extend ?
Image source : https://t4tutorials.com/use-case-diagrams/
All proportions kept to compare the extend and the include + generalizations is like to compare the aggregations a and b + generalizations in :
In your diagram because of the extend the behavior defined in the UC Print Slip can be inserted into the behavior defined by the UC Confirm Order
The generalizations are like they are elsewhere in UML, pay through paypal is a Payment and pay through credit card is a Payment too. The diagram indicates the UC Confirm Order includes the UC Payment or one of the two inheriting UCs. So the behavior of the UC Confirm Order contains unconditionally the behavior of the UC Payment or the behavior of the UC pay through paypal or the behavior of the UC pay through credit card.
There is an example of inheritance between UCs in the norm, see figure 18.11 page 646 in chapter 18.1.5 of formal/2017-12-05
The two blue bubbles right bottom inherit from Payment through the generalization relation. That's, well, not advisable although looking convenient. Unlike for class inheritence which is clearly defined, a UC inheritence is an open field. The UML spec uses a generalization in just one single diagram and makes absolutely no definition of what a generalization for UCs actually means!
A use case is very much in the world of prose and informal language. It (probably, since there's no definition) means that you take the description of the parent UC and replace parts of it (override) with text defined in the inheriting UC. From a context that sometimes partially works. However, paying via credit card and Paypal is very different (you know) and there's not much in common. So a better way would be to «extend» Payment with the various ways to pay. This way you have a fixed payment procedure which optionally can go the credit card or Paypal way (or even a mix if so designed).
N.B.: The above example is just a bad one. It starts functional decomposition. Use cases shall show a single unique added value a system under consideration shall bring to its actor(s). Print slip is definitely a pure function and no real added value (who needs a paper slip these days?). Selection of product just the same: what's the added value here? Calculate... is telling just that it's a function. Basically you have two use cases: Confirm order and Make payment (note that using verb+substantive is mandatory in describing a use case in the title).
As always I shall recommend Bittner/Spence as excellent read about use cases.
Related
Can you tell me if I understand extension points correctly in use cases (and in the diagram)?
For use case 'Card Payment' and and extend use case 'Pay by credit card' is it properly identified that extension point wil be "User clicks pay by card button"? Or should it be "system asks for the payment method"?
The identification of the extension points is correct.
The problem is however that the extensions should not be extensions at all.
From the UML specs 2.5:
The extended UseCase is defined independently of the extending UseCase
and is meaningful independently of the extending UseCase. On the other
hand, the extending UseCase typically defines behavior that may not
necessarily be meaningful by itself.
So your use case make a payment should be indedepent from the extending use cases pay by credit card and pay by cash. This is clearly not the case since you need the extending use cases to have a meaningful and complete behavior.
There are several alternative solutions to using extensions in this case.
A single use case: Simply incorporate the extending use cases into the main make a payment use case. You can create alternate scenarios for the different payment options. This is probably the best option as your use cases are way too granular anyway. Use cases should be about the main goals a user should have when using the system. Not about functions the system provides.
Include: You can use an include relation to (conditionally) include the other use cases behavior into your main use case. This would be more appropriate because the main use cases relies in the result of the included use cases and is incomplete without them.
Generalization: You could specialize make a payment with pay by cash and pay by credit card. Generalization between use cases is allowed, but generally discouraged by a lot of practitioners.
I've never made a use-case diagram before so I'm wondering if mine is correct or not.
In short
This is an (almost) valid use-case diagram. But this does not make make them good use-cases. But what matters in the end is if it is useful to you.
More details
Is it formally correct according to UML?
UML is value-agnostic and defines UC on page 637 of the specs (highlight by me):
A UseCase is a kind of BehavioredClassifier that represents a
declaration of a set of offered Behaviors. Each UseCase specifies some
behavior that a subject can perform in collaboration with one or more
Actors. UseCases define the offered Behaviors of the subject without
reference to its internal structure. These Behaviors, involving
interactions between the Actors and the subject, may result in changes
to the state of the subject and communications with its environment.
Let's check the validity of your UC in view of this definition:
Start game, move paddle, restart game, and exit game are behaviors that the game (subject) offers in collaboration with the player (actor). These are valid UC according to UML.
Ball falls, hit all bricks, hit brick, and display score are behaviors that are more questionable: they do not require a collaboration or an interaction with the player. You could nevertheless argue that these make sense only if the user observe these behaviors, so there is an interaction with the player. So it could be claimed that these are also valid UC in regard of the UML definition.
Add score seems to be a purely internal behavior that is done without the user and not even observed by the user. This would not be a valid UC. However labels might be misleading: if Display score would mean the final game-over score and Add score would mean an update of the score on the screen, it could again be argued that it's a valid UC.
The use of extension (optional) and inclusion (systematic) seem also correct.
Is it a good UC?
While UML is value-agnostic, many authors define a use-case in a more ambitiuous way. In particular Ivar Jacobson, the inventor of the Use case defines it as:
A use case is all the ways of using a system to achieve a particular
goal for a particular user. Taken together the set of all the use
cases gives you all of the useful ways to use the system, and
illustrates the value that it will provide.
According to this definition, there is only one single use case here:
Play a game : this is the goal of the user that brings him/her value.
All the other elements are only ways of using the system to achieve this goal. So they belong to the single use-case. A approach would be to represent them as detail of the use-case description:
One suitable way would be to show these in terms of intent in an essential use-case. This approach was invented by Constantine and Lockwood in 1999. It is used centered and leaves full flexibility about the sequence of actions in the user interface.
Another modern way is the Use-Case 2.0, invented by Ivar Jacobson in 2011. These detailes would be shown as use-case slices, in a very similar way than user-stories.
Given the following scenario:
If the credit card is declined, the card will be ejected. Otherwise, some amount will be charged.
How do I model this in a Use Case Diagram?
As far as I understand extends, (A) extending (B) means that: "If A happens, B can happen aswell". But this doesn't quite express the above scenario since one of these events/activities has to follow.
I think my main problem is that I have not quite internalised what you express and what you leave out in a Use Case Diagram.
It's neither. The Use Case is Pay X or Buy Y or the like. This is shown in the UC bubble connected to the Actor getting that added value. Your description only shows an alternative in the flow of the UC, not another UC being included or extended. A UC is only about added value, not about functions.
As always I recommend reading Bittner/Spence.
Looks like Payment using credit card is the use case here and two scenarios are possible
1.Payment successful
2.Payment declined
These are mutually exclusive paths of the use case and dont fit into the extends or includes relationships between use cases.
Includes relationship indicates a mandatory relationship while extends indicates a optional relationship
I just want to determine if I am using extend and include correctly. If I am using either incorrectly somewhere here please indicate where, and if possible, why it is incorrect.
https://imageshack.com/scaled/large/163/nlnk.jpg
Cheers.
Rules for using <<include>> and <<extend>> are simple:
<<include>> defines a sub use-case which is always included in the general use-case: use-case -include--> sub use-case. Usually it's used to denote a distinct part of a use-case or a common part that can be reused by other use-cases.
<<extend>> defines an optional sub use-case that can be executed upon certain conditions (which should be defined at a lower level design, not in use-case diagram). Here the direction of the relation is opposite to the <<include>> relation: use-case <--extend- sub use-case.
Apply these rules to your diagram and figure out if it's correct.
It looks as though "secure login" is required to be performed prior to the other activities that you link with <<include>>. Include implies that the use case also runs the included use case every time which in this case is probably not what you intend (just one login per session). You can always create new stereotypes, such as <<precedes>> or <<requires>>. Using them consistently will allow you to convey your meaning.
I find this piece of advice before when I'm trying to distinguish the difference between using extend and intend in use case diagram.. I hope it helps you too. The original advice comes from this StackOverflow answer.
Difference between extend and include
Extend is used when a use case conditionally adds steps to another
first class use case. For example, imagine "Withdraw Cash" is a use
case of an ATM machine. "Assess Fee" would extend Withdraw Cash and
describe the conditional "extension point" that is instantiated when
the ATM user doesn't bank at the ATM's owning institution. Notice that
the basic "Withdraw Cash" use case stands on its own, without the
extension.
Include is used to extract use case fragments that are duplicated in
multiple use cases. The included use case cannot stand alone and the
original use case is not complete without the included one. This
should be used sparingly an only in cases where the duplication is
significant and exists by design (rather than by coincidence). For
example, the flow of events that occurs at the beginning of every ATM
use case (when the user puts in their ATM card, enters their PIN, and
is shown the main menu) would be a good candidate for an include.
Also, from every book I've read, it is always recommended to use include and extend sparingly. Keep It Simple Silly.
Many relationships are clearly not correct here. However, I think the main issue with this diagram is not the correct use of include and extend, but rather to complex and overall unclear relationships. Although sitactically valid, you should avoid using more than one level of these relationships.
Your diagram is really hard to follow and to interpret.
Some refactoring ideas and corrections:
show "Secure login" class separately, linked only with Actor and then apply the following precondition for all use cases that "include" it: "User is securelly logged in"
"Logout after 5 mins" should be own use case, only connected to Actor as well, with 2 preconditions: "User is securelly logged in" and "User was inactive for 5 mins"
Remove the include between "Logout after 5 mins" and "Initiate a call". Extend might be more appropriate
reverse the direcction of the include between "Transfer funds..." and "Insure adequate funds..." - it is clear that the first one includes the second one and not vice versa
consider breaking a diagram in 2 or more simple and small diagrams of only related UCs: all login/logout could for example be shown separate and simplify the view. You should not have more than 5-7 use cases on one diagram
UML Use Case Diagrams allow for two seemingly equivalent ways to show that a given use case might be realised in several different ways namely use case generalizations as opposed to use case extensions. I have seen the following basically example modelled using either approach with equal frequency, sometimes within a single source.
To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.
It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.
void makePayment(const PaymentDetails* pd)
{
pd->pay();
}
as opposed to
void makePayment(const PaymentDetails* pd)
{
switch(pd->type)
{
case EFT:
payViaEFT(pd);
break;
case PAYPAL:
payViaPayPal(pd);
break;
case CREDITCARD:
payViaCreditCard(pd);
break;
}
}
Isn't the Use Case stage far too early for such implementation specific concerns to be modelled? There are much more appropriate UML diagrams for that. Is there a hard and fast rule regarding which of the two to use and if so what is it?
To my mind an extension is a weaker relationship than generalization
as a direct substitution of the specialised use case for the base case
must be possible in generalization but not necessarily in extensions.
That is true.
It seems to me that generalisation implies a polymorphic
implementation is desired while extension implies some branching
structure is to be used.
The diagram does not dictate any implementation.
You can interpret a hint from the diagram for yourself, though. UML remains independent of language and solution there.
Isn't the Use Case stage far too early for such implementation
specific concerns to be modelled?
Well, as indicated above, UML does not enforce any specific kind of implementation.
However, you are gathering some important functional requirements here that might greatly influence your time schedule and workload. ("Pay with credit card" is way more complex to handle than "pay in advance by bank transfer"). So you'd strive to capture that but remain open to different solution approaches.
There are much more appropriate UML
diagrams for that.
You can really use them in parallel :) as they are different views on the same subject.
Is there a hard and fast rule regarding which of
the two to use and if so what is it?
I prefer the generalization in this case because the extensions falsely suggest there could be a way of paying without using any of the three named options. As you indicated yourself.
Addendum (as per comments): The high-level purpose of the example diagram is to outline the foreseen payment means. A payment needs at least one means (unless payment is cancelled), just like "print" is too vague without clarifications such as "what" and "where". Hence my preference for using the generalization, despite "make payment" being a valid use case in itself.
When modelling with an extend relationship, the extending use case (pay via xxx) is executed when the extended use case (make payment) is at a precise location (given by the extension point, payment type) if the condition for such extend relationship holds (e.g. for "Pay via Paypal", the condition would be payment_type=PAYPAL). In this model, "Pay via Paypal" does only deals with the details of completing a payment transaction with Paypal, while "Make Payment" specifies all the behaviors that are independent of the payment method (such as computing the total amount, and saving the result of the transaction once that it was performed).
On the other hand, generalization (which is defined not only for use cases, but also for any classifier) is a broader concept, since it do not detail (at the diagram level) the details of when and how the specialized behaviors are executed. If "Pay via Paypal" were a specialization of "Make Payment" it would redefine the behavior of "Make Payment", which could be substantially different from the behavior of "Pay via credit card".
Being an extending use case does not means that the alternatives have to be hardcoded. Indeed, your first example is also a valid implementation of a extend relationship, since pd->pay(pd) will invoke different behaviors depending on the selected payment type. Actually, use case diagram models what a system is supposed to do, while low-level implementation details are better specified in activity diagrams.
An example of an extension would be a "Discount Payment" use case. Discounting a payment has to do with making a payment, but you don't have to discount a payment in order to make the payment.
You can look at the "is a" relationship to make the determination of which to use. Pay by PayPal "is a" make payment, a specific way of making a payment. Discounting a payment isn't. It's something additional you can do while making a payment.