I have a use case here for delete. This is trying to demonstrate that a user can delete Users, Projects and Posts. If you want to do delete a User, you select "User" from the deletion menu, a user menu dialog box will pop up where you will type a name and press "Delete" to confirm deleting that user. For Projects, you select "Project" in the deletion menu and another menu pops up where you type the projects name and click "Delete" to delete the project. That is how I am looking to implement it in software. However displaying it in use case I am a little confused. Is this a good use of extension point use case to demonstrate that functionality or is a specialisation better to use in this scenario where the parent would be "Delete" with children named "Delete User", "Delete Project" etc...
Based on Writing Effective Use Cases by Alistair Cockburn
My personal tendency is to write "Manage X", to get the advantage of less clutter, unless it
turns out not to work well for some reason, usually related to the complexity of the writing, and
only then break it out into "Create X", "Update X", "Delete X"
Specialization
The UML specs explain that:
The extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending UseCase.
In your case, I doubt that Delete is meaning independently of Delete User, Delete Project, and Delete post. The point is that the use-cases are independent of the internal implementation of the software. They should in principle represent user goalds and the set of behaviors needed to achieve them.
In Writing effective use-cases Cockburn dedicates a chapter to CRUD and parameterized use-cases. He provides a useful question:
The question is, are they all part of a bigger case or are they separate? In principle, they are separate because each is a separate goal, possibly carried out by a different person with a different security level. However, they clutter up the use-case set and can tripple the number of items to track.
He proposes several approaches, including the principle of parametric use-cases: a generic use case (i.e. a generalization) describes the general behavior, and parameters are used to specialize the use-case description. ALthough his book is about use-case speicifications and not use-case diagrams, he describes an idea that is much closer to specialization than extension.
Related
I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.
I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:
From the point of view of the semantics, the use-case specialization means that Open presentation is a special form of Check file, and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file
From the point of view of the purpose, a use-case should represent a user goal. It's part of the problem space, i.e. what the user wants to achieve. It's not part of the solution space, i.e. how the user will achieve it. A toolbar is not a goal: it's a user-interface element.
From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:
The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
in The unified software development process, page 164
So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or a a voice-based interface.
While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.
A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.
While naming the use cases, you should only use verbs and actions, for example:
1- Login | 2- Submit a Request | 3- Update Profile Description
You should avoid any nouns in them.
There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:
Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.
In the example above, User is caple of loggin in and submitting a complaint.
Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.
Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.
Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.
Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.
Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.
Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.
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.
What distinguishes a user story/feature from a use case/scenario? Any pointers would be very much appreciated.
Is it just the granularity, similar to epics and user stories?
Much has already been written on the meanings of and difference between "use case" and "user story". Google "stackoverflow difference between use case and user story" to see some of it.
Regarding "feature" and "scenario":
In Gherkin, a Scenario is a series of steps that are executed together.
In terms of user stories: it might take one or many Scenarios to specify a user story, depending on the size of the story.
In terms of use cases: Gherkin's use of "scenario" corresponds almost exactly to the meaning of "scenario" in use case analysis: A use case describes a series of interactions between an actor (usually but not always a human user) and the system, in enough detail to make the system's responsibilities clear; a scenario is an instance of that use case with some values and the resulting details of interactions exactly specified, with the purpose of making some fine point of the system's responsibility (often edge case or error handling) clear. Just like a use case scenario, a Gherkin Scenario necessarily specifies all values completely (even if they're hidden in step definitions and not visible in the Gherkin itself), so "Scenario" was a good choice of name for that Gherkin concept.
A Gherkin Feature is just a collection of Scenarios, which you can use however you like.
In terms of user stories: A Feature can be the set of Scenarios that implement a user story or epic. In my experience, after more than one story has been implemented that touches the same part of an application (the same "feature"), one wants to put the Scenarios for those stories in the same Feature so one knows where to find them -- for example, you might want to put all the Scenarios related to user accounts (create an account, upgrade a subscription plan, cancel an account) in the same Feature rather than in different features, even though they implement quite different stories.
In terms of use cases: It usually takes several Scenarios to specify a use case (e.g. one for the happy path and one for an error path). Clearly these belong together in the same Feature file. As with user stories, one often wants to put the Scenarios for use cases that describe the same feature of the software in the same Feature.
I'm setting the use cases of a project, here are some of the details :
My question is two parts :
first one :
I have an actor user.
The user can register on the website.
He can login, view profile, edit password.
Regarding the previous use cases, I'm confused how to visualize the use cases in the diagram, I was thinking it might be done like the following :
Create a use case "Manage Profile" and connect the other use cases "View Profile,Edit password, etc..." to it with a generalize relationship. and then connect that use case to the "loginCheck" use case with a "include relationship". The actor will indicate "manage profile".
Create a sub-system "Profile" and set the use cases related to within it. then connect it to "loginCheck" with "include relationship". The actor will indicate each use case.
second one :
The user can Add bet : there are some types of bets:
mutual bet :
1- single bets.
2- combination bets
long term bets
championship bets
Should I create a general use case "AddBet" and extend the other types to it.
I can't upload photo directly because I'm new .
First of all, For me I saw a lot of "link" inside your diagram which seems to be use in a wrong way. Maybe you can take a look at some UML ressources and more specifically, association, generalization, include and extend links... BTW I am just curious to know which tool do you use for this? Visio or ArgoUML?
So now concerning your(s) question(s).
When you want to associate an actor to an usecase you have to create an association between them not a generalization
If you want to specifiy that an "manage profile" use case can include (or not) changing password, view its profile, etc for this I would use an extend link.
For modelling the fact that an given use case mandatory include another one I would use include relationship.
the creation of an "add bet" use case "exntended" by the other one would indicate that you have a lot in commmon between all this possible bet.
Please take a look at my screenshots and let discuss about it.
On the Use case diag you should have only actors, visually different systems (such as terminal, client computer, server computer or Profile management system, Betting system ) and real-life actions(use cases).
Systems are shown as blocks, actors as people and use cases as ovals that connect sides of the action.
You should Profile Management as a system, as a protagonist in dialogue user-system. And you'll see, that Mobile bank is NOT a use case, is not an action. Maybe, it is another subsystem, or maybe simply won't belong there.
On your other diagram obviously different sorts of bets are descendents of the "bet" use case. They do not simply extend it.
You have many use cases not connecter to anybody. WHO does these actions? It is the target of UC diagram to show it.
suppose you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.