I want to create a use case diagram (along with use case scenarios) for my application, but I'm not very familiar with that. My app has a couple of screens, every screen contains some functionality that user can interact with.
Let's assume that it's a car sharing app, and first screen contains two actions to do:
browse cars → which moves the user to another screen, when he can see a list of cars
view rental history → which moves the user to another screen, when he can see a list of cars he has rent in the past
I think that these two actions are two use cases, for examlple action "browse cars" is use case "browse cars" with workflow:
App displays a list
App downloads data (→ it may lose connection here etc.)
App displays data
Am I right? Then, the diagram should look something like this (A is the actor)?:
A __ UC1
|___ UC2
Next, from "browse cars" screen I can, for example, see car's details, from details I can rent it and so on...
I am not sure, if these actions should be treated as <<extend>> relationship, or it should be just standalone use case from actor.
I don't think that renting a car, displaying list or car's details should really depend on each other. It depends in the app, because the screens are grouped by functionality and that is the expected workflow in my case, but in other UI design it may differ. Should I care about the expected workflow or not?
Should it be like this:
A -- UC1 ←extend--- UC3 ←extend--- UC4
|___ UC2
or this:
A __ UC1
|___ UC2
|___ UC3
|___ UC4
My app contains many many features (about 40 defined for now) and I have to present every use case on the diagram.
In first case it will look like a tree and will be similar to this:
[]
(Taken from https://creately.com/diagram/example/i04a0uvo5/Group%20Use%20case.)
Is it a valid use case diagram?
In second case it will look like a big column of ellipses, like this, but with much more use cases:
Which should I choose? If I should draw it as in exapmple 2, what is the purpose of <<extend>> then? Also, "browse cars" and "show car's details" are two independent use cases, or should it be combined to one?
One more question is, if I have two actors which can do the same thing but the result is different, should it be two different use cases or one, and I should include a some kind of condition in use case scenario then?
Thanks
Simply your first approach is a functional decomposition and just wrong. Use cases are about added value a system under consideration brings to its actors. So the 2nd picture is good. I'm not having read the details of your description.
I recommend (as always) to read Bittner/Spence about Use Case Modeling.
Related
I am to create a UseCase diagram for an existing web program. Unfortunately I am very unsure about UseCase, I like to mix it with other UMLs.
For this purpose, I have picked out the order page.
There are 3 different users, the admin, driver and customer.
The admin can view all orders and has the ability to create a new order.
The driver can see his own orders, as well as orders he can accept.
The customer can see his own orders, as well as place a new order.
There is a possibility to choose between the standard view (row view) and a widget view of the meta information of the order.
Last but not least, there is the possibility to click on one of the orders and a single order overview will open.
Based on this I have now created a UseCase diagram, my first question would be: Is this all correct, with the informations i gave?
Will this then become a huge UseCase diagram? Or should this rather be done page by page for web applications? For example, if this is the order overview and I now have the use case that I change the page (In this case, when I go to the single order overview). And is there a way to make this look cleaner? All these extends/includes on 1 place looks confusing.
I'm afraid I don't know if I'm doing this only partially right, or completely missing the point.
What you need to remember is that Use Cases are about added value and not about technical realization. That's really hard for tech people and that's why they always start functional decomposition. So looking at the above, the only use case is Show Order and nothing else.
Login is no use case from that perspective. It is just a constraint you apply to certain use cases.
You just have focused on the Show aspect but likely there's also add/edit/delete. Such CRUD can be dealed with in variuous ways and there's no general rule. There might be a Manage and a Show or what ever combination along with constraints.
Basically, when your UC diagram resembles a spider web your design is likely broken.
So basically i'm wondering if I'm thinking correctly. In an e-commerce environment does the order of a product have a relationship to the admin use case of managing orders? Once an order has gone through is the admin then going to be able to see the order through a relationship between the 2 use cases. I've provided an image for reference in my case.Here is the image
TL;DR
No, there is no extension here. Those will be two separate UCs.
Explanation
First let me focus on the goal of the Use Case diagram. This diagram is intended to show functions of the system and users (or more broadly actors) engaged in those functions. It is not used to show how data flow through the system or what are steps of the processing. There are other diagrams to do that.
As a rule of thumb, something is a good use case if you can log into the system, perform only the action of this single use case and then log out.
Extends (Includes works pretty much the same, it's just stronger) means that when you run the extended UC you can include the other use case as well. In other words in your specific example when Customer logs to E-Commerce to place an order he can while placing an order also choose to additionally receive and manage order (BTW I would reconsider this UC, you probably have few separate UCs here like Complete order, Dispatch order or Reject order) in which case additionally an Admin is need. Even if you invert Extends, it's still not what you want. Those two UC happen totally separately even though the order processed by Admin is the very same one placed by Customer.
I did not search for too long but I did not find a case where a given use case, associated to one actor, is extended or included by another use case, associated to another actors.
A use case describe the usage of your system by a given actor so you do not have any other actor involved.
I would like to show use case diagram me.What is correct use case diagram me about system hotel?
http://i.stack.imgur.com/KPsZU.png
Note :
- outside of system boundary is comment, Not use case
sorry don't have reputation 10. Don't show image this.
After a short review I would say that your use cases don't seem to be cut the right way. You are using <<include>> and <<extend>> in order to perform a functional analysis. This is not what use cases are all about. Each use case must show a piece of added value to its actor. I/E are a means of showing optionality for single UCs (means they can be added later in time or build a system with different level of value to the user). Showing a path of execution is something that goes completely into activity diagrams inside each use case.
As a take home message: If your UC diagrams start resembling a spider's web your design is likely broken.
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.
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.