So each menu has different categories and each category has products. I'm a bit confused of what usecase I should use.
Use cases are not meant to be used for designing user interfaces and menus. For this purpose, it is better to use more appropriate design practices such as for example wireframe and storyboards.
Use cases are not either meant to present a workflow or a sequence or event, like first do that, then chose then, then that. For this activity diagrams are better options.
Use cases should represent actor goals. The last option seems in this regard acceptable, since a user may be interested to manage each of these items, independently of the user interface and the order it is done.
The second option corresponds to the narrative. But it corresponds to a functional decomposition. Moreover it is misleading, as it suggest that managing products is dependent on the others, whereas one could well imagine an independent management of products.
The first option would be an alternative if the main goal of the actor is to manage products, and navigation through menus and categories would just be means to manage the products. Looking at the context (especially the "reservation" use-case) I understand however, that it's for a restaurant management system, and managing product is only one part of the goals. This option would therefore be misleading.
Related
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
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
so I had this situation where this User(Customer) need to choose between yes or no option for buying a movie ticket option, and then they need to choose again between food choice rather customer want to buy food or drink, I know about use case diagram but it's confused me about the "Option" especially multiple options (because on use-case diagram there is no triangle type thing right(option thing on different UML, I forgot the name of it)),
Thank you in advance for your help!!
In your narrative, there is only one use-case: Buy a movie ticket; this is the actor goal. The fact that there are options are just details of this use-case.
Moreover, use-cases do not show anything about a sequence. If you want to show this kind of logic, you could consider an activity diagram with decision nodes and different flow of control or of objects and actions depending on the choices made.
But if you do so, you have already taken position on the user interface. But user interfaces are not well designed in UML. They are best addressed with UX design techniques such as wireframes: with this kind of tools you can easily find out if it's better to do one choice at a time, or on contrary to offer the full palette immediately (not to mention that options are not mutually exclusive).
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.
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.