Except for the context of UML,if A extends B,then B is a subset of A.
But in UML, it's the opposite,say,if A extends B,then A is a subset of B,
why is it so strange?
The <<extend>> dependency is only used for Use cases. It means that one use case extends the other under certain circumstances. In the following:
The client views account details. Under certain circumstances, the client may also "View Open Orders" as part of "View Account Details". It's also possible that the client will "View History" as part of "View Account Details".
This has nothing to do with generalization / specialization.
<<extend>> is confusing in use case diagrams. The smallest part of the confusion is that use case diagrams are not use cases!
A use case is a document, not a diagram. For example, the diagram above might have been drawn from the following use case text:
Client views account details.
Extensions:
1a. If client clicks "Open Orders" link
Client views open orders
1b. If client clicks "View history" link
Client views history
In a more-detailed model, these "extension points" would be listed on the "View Account details" use case element on the diagram. But this clutters the diagram terribly, in my opinion.
I first really learned UML by reading "UML Distilled" by Martin Fowler. I just checked that book before posting this answer, and found that Fowler suggests ignoring <<extend>>.
To write it in terms of use cases (I believe this is context you meant - if not, correct me), lest think about ordering a meal in your favorite fast food restaurant.
Basic use case is to order a meal, but it can be extended if you present a discount coupon. Every time you go trough this use cale, you get a meal, but only under special circumstances you pay less than usually (or get an extra sandwich).
I found quite a good example here: http://www.agilemodeling.com/essays/useCaseReuse.htm. As you can see enrolment for international student includes additional security check, and is applied only to a subset of enrollments. Hope that will help more.
UML doesn't use the term "to extend/extension". Instead, it uses the term "to generalize/generalization"; people also often refer to it as "to inherit/inheritance".
If B is a generalization of A (i.e. A inherits from B), then A is a subset of B. This should become clear from the "is-a" relationship: if every A is a B, then A is clearly a subset of B. In your terminology, if A extends B, A is a subset of B.
A type is a predicate: for every object, you can determine whether it belongs to the predicate. Extending the predicate means to make it more restrictive.
Related
I have a use case "manage login and security" (MA01) which is described as follows: As a user I want to be able to navigate to the login & security screen in myaccount to be able to manage my credentials.
There is another use case called "Manage account details" (MA03) which is described as follows: As a user I want to manage my access data (email, password).
There are many more use cases like the second one. There are more use cases which are more and more specific. So for example the use case "change email" (MA03 001) which is a possible use case for managing the account details.
How do I show that in a use case diagram?
Is this a generalization relationship between the use cases? The first is very general and wants to manage the login and security; the other use case is more specific and wants to manage the account details.
Workflow of use case manage login and security looks like this
There are various opinions on how to apply the use-case technique. Your team seems to have an unfamiliar approach, but I won't comment on that. You have use cases and detailed flow descriptions and now you want to create a use case diagram to get a visual overview of these use cases. The question is which relationships to use between the use cases in the diagram. I will summarize the available relationship types and when to use them. Finally, I will draw conclusions about which relationships are applicable in the examples you have provided.
«include»
If the flow of use case UC1 contains a step that says "Now execute UC2" or "Perform UC2" or whatever, then the use case diagram should have an «include» relationship between UC1 and UC2, with the arrow pointing from UC1 to UC2.
Side note: Many people interpret UML such, that the «include» relationship only exists if UC1 always executes UC2, but in my opinion, it also exists if UC1 executes UC2 only under certain conditions.
«extend»
If the flow of use case UC1 contains an extension point EX1 (i.e. a point in the flow where UC1 can be extended, without any reference to a use case that contains the extension) and use case UC2 specifies steps to be inserted at extension point EX1 in UC1, then the use case diagram should have an «extend» relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. In the use case diagram, you may also mention the names of the extension points. If you want details about this, please refer to the UML 2.5.1 specification, chapters 18.1.4 and 18.1.5.
generalization
If UC1 and UC2 are similar, but UC1 is more general than UC2 and UC2 is more specific than UC1, then the use case diagram may have a generalization relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. For example, UC1 is "Buy a product" and UC2 is "Buy a food product". The description of UC2 says how it differs from UC1, but UC1 does not have any reference to more specific use cases. If UC1 shall not be executed on its own, but only the more specific use cases, then UC1 shall be marked as {abstract}.
Conclusion
There may be a generalization from use case MA03 "Manage account details" to MA01 "Manage login and security", but only if all account details can be regarded as login and security details and MA01 does not refer to MA03.
The relationship between MA03 and MA03.001 depends on how the flows of these use cases are specified. Please refer to the descriptions above to determine which relationship applies here.
There shall be an «include» relationship from use case "Display Login & Security" to use case "Set password", because the former use case says, at step 3: "Perform process UC-MA11 - Set password".
The description of Display login & security in the history of your post corresponds indeed to the step by step description of a very detailed use-case at sub-function level. Although UML allows to do such a functional decomposition, it is not recommended, as it leads to cluttered use-case diagrams with little added value compared to the tabular description that you already have.
I think Admiraal's answer provides all the necessary information if you want to pursue this way. I'd just add that Change email is in no way a specialization of Manage account details, since you cannot use the former as a substitue for the latter, it's just a part of it.
It appears however, the wording of your question (e.g. "workflow") and of your UC description (e.g. "action", "perform process UC-MA11-Set password") suggests that you're not really modelling use-cases but that you're rather modelling activities. For this an activity diagram would be much more suitable and value adding than an UC, because it allows you to show the successive steps, the sequencing of steps, and the call of activities ("processes") that can be specified in more detail in another diagram. In this case, you'd keep as use-case only the highest level of your current UC modeling, which may then more probably look as user goals.
I have seen examples of people representing CRUD use cases in use case diagrams as "Manage X", but I wanted to know whether I can use a generalisation like the one in the screenshot to group many of them.
My intention is that "manage item" applies to the current catalogue being browsed. Would this be fine?
Use case diagram:
Yes, you can use a generalization to convey the intent that the actor manages items, and that items can be of different kind.
But your diagram looks very detailed and appears to be more a user interface model rather than a real goal-oriented use-case. I.e it describes more the “how” than the “what”. This is not forbidden according to the UML specifications, but not advised, as it leads to complex diagrams, distracts the modeler from the user goals, and leads to a premature design of a user-interface, whereas other modeling techniques are better suited to ensure an optimal user experience.
See also this question, that addresses similar concerns but at a lower level of abstraction.
P.S - Unrelated thoughts: The diagram might create ambiguity, since it suggests on one side that browsing is specialized by types of items (browse X and browse Y), but at the same time it suggests that any browsing can be extended with managing any kind of items (manage X, manage Y). This could be one more symptom that the use case was created with some class design in mind and not centered on user goals
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.
Edit:
Final outcome based on suggestion given by #qwerty_so
This is my use case diagram for View Repository in Source Code Management System.
This system is part of Project Management System.
The system is similar to GitHub, user can select project.
And it will display a list of repository for the project.
User can click a repository to view its details such as file tree and repository information.
Finally, user also can click the file in the tree to view its content.
Is my use of use case generalization correct?
Below use case is the previous version, I learnt that using use case diagram to model process is incorrect (Seidl et al., 2015, p. 37).
Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML # Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
Well, let me just ask a question: can you abstract added value? The only case where that is true is called franchise. So what you did is to introduce a new abstract bubble to connected three concrete use cases with your actor rather than connecting the concrete bubbles directly. What for? Where is the added value for "View repository"?
For the abstract actor it's similar. There is no need to make User abstract since it's already abstract. All actors denote roles, not real things. You can just leave that abstract keyword away and it would not change any semantics.
What often happens (and you are on that way) is that people start functional decomposition rather than synthesizing use cases. Use cases are about added value a system under consideration delivers to its actors. That's just it. Just present these added values. I know it's difficult for techies, but stick to that.
As always I recommend to read Bittner/Spence about use cases.
in my opinion, one use case is one scenario. since we have to make a scenario for every use case model drawn in the diagram, so one use case must have specific pre-condition and specific post-condition but only have one main or basic flow. Use case might have few alternative flows, that are illustrated in extends relationship. while include relationship is used to avoid repetition in several scenarios in main/basic flow of several use cases.
I'm very new to UML, especially use case diagrams. I attempted to draw a use case diagram for my application which includes a renter, a seller, and a general user. My renter and seller extend general user. I am having trouble with includes and extends. For example, When you view an office space, you can also see the reviews for it at the bottom of the page. As well as when a renter wants to write a review, he/she must do this on the view office space page. I am not sure if this is an extends or an include. Please correct me if I am wrong with any of my arrow directions. Also, is it okay to say that Renter and Seller include logging in?
As Jim states: I/E are for UCs, not for Actors. I assume you meant a generalization here, so both inherit from General User.
Some further observations:
Use verb-substantive for UCs titles
Think of the "use" in use cases. IOW: the added value. If you don't find it's added value, then it's no use case.
Avoid I/E in general. They often indicate that you try to use functional decomposition which is not the aim of a UC synthesis.
The relation you draw between the UCs is wrong in any case. There is no relation which has a filled triangle and is dotted. You probably meant to use some <<include>> dependency (with an open arrow). But as said above: avoid it. Just create an association to the actors. It's sufficient to just draw one between Reviews and General User as Renter will inherit the relation.
Login/out are no UCs (no added value). The are constraints to other UC (write {must be logged in} and attach to the connector)
You generally should not model login use cases, as they don't directly help the user accomplish anything he or she cares about.
Includes and extends are relationships between use use cases, not actors. The UML 2.5 specification says:
An extension is:
A relationship from an extending UseCase to an extended UseCase that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase.
An include is:
An Include relationship specifies that a UseCase contains the behavior defined in another UseCase.
A generalization / specialization relationship between actors is perfectly fine. That's just a generalization arrow. (e.g., a solid line with a hollow arrow head.)