This question already has an answer here:
Have I to use the same actors for those extending or included use cases? [closed]
(1 answer)
Closed 6 years ago.
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
Can extending or included use cases be accessed independently? If I do it as in the screenshot, can AddProspectiveIngredient be used without going through the CreateRecipe use case? Same question for included use cases.
EDIT: I don't think this is a duplicate of this question. In the linked question (1), I ask if I have to use the same actor for extending and included use cases as in the extended or including use case. In this answer (2), however, I merely ask about reuse between use cases.
In (1) it is all about the actor, and I am very satsified with this answer, as I now understand that the primary actor of an extending use case will inevitably be a subclass of the primary actor of the extended use case.
(2) addresses reusability of extending and included use cases, but is not necessarily connected to actors. It is about reusing them in other use cases. So if I have two use case CreateRecipe (a) and AddIngredientToDatabase (b), where (b) extends (a), can I also extend a third use case with (b)? Here I also received my answer, that they can and should be reused.
Maybe the questions seem similar because I created them on the same day with the same example and the answers both mention actors, which make them seem as duplicates. As they are both answered and I am satisfied with both answers, why close the questions as "too broad" or "duplicates"? If it was answered succesfully with different answers, how can it be too broad or a duplicate?
I am also happy to rephrase them slightly to keep them open, if I am told what the core issues. More answers and comments on the topics are still interesting to me.
Can extending or included use cases be accessed independently?
They rather should be. It is a good and correct style. Use case is some activity conducted between one or more actors and system. You should try not to show here some inner operations, that are not connected to users. Nothing invisible to users can be shown here. USER cases, remember?
So, no inner structure here.
You can collect some cases in groups - subsystems. But it is not inner structure, they are not IT systems, they are simply common themes of activities, obvious for users. Such subsystems should get later at least common UI style.
As for logic that could be used by users, it can be shown on other diagrams. Many diagrams can exist on this level - State machines, Activities, Timing. But don't try to show processes on the Use case diagram, too.
So, I don't know how well have you interviewed the client, but you use case diagram looks almost correct. Only the AddProspectiveIngredient Use Case should get its user or more.
Related
I just create this diagram can anyone tell me if these 2 pictures are correct or wrong and which one should I use?, can anyone tell which is correct in these 2 pictures.
Both diagrams are ok, except:
the association between an actor and a use case should be straight lines and not directed arrows. These arrows are an obsolete practice.
the subject rectangle should be closed
actors not related to anything are useless and should be removed
The question of whether add and edit should be in the same use case or in distinct ones is up to you to decide:
grouping them has the benefit of simplifying the model. Manage students could be even more generic and is quite common.
keeping them separate may appear more granular but makes sense if there are different actors or if the business needs are very different.
You may read more to make up your mind, googling for CRUD Use case.
I am trying to design a Use Case Diagram for an app like Stack Overflow. I have tried to add some basic functionalities in this diagram.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow, but have no idea of how to do so. Also, should there be another actor for Admin who manages user accounts, or not? And if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
What if other than these two actors, I decide to add a Mediator actor too, who forwards the problems to the mentor, and when a mentor solves it, it is the responsibility of mediator to mark it solved?
If you want to map all the use cases and actors in StackOverflow you can take the Tour and search for some known Q&A in the Help Center.
And yes, if you want to make an exhaustive list, then you should include every actor - including Admin and Mediator. However, I'm not sure that you can figure out the admin's use cases (or other managing roles in this platform) since you are a user and it isn't reflected to you.
If there are use-cases that are unique to a specific actor, then you should add that actor to the diagram - and use inheritance! (When actor b has all the cases of a plus more, then b is inherits a) - this one is called "Generalization of an Actor" (you can google search some examples).
As for your other questions:
Please note that Use Case Diagram is an addition to the Use Case Modeling, more like an appendix. When you are modeling - you explain lots of details about the use case (some of them you've mentioned), such as: Primary actor, Scope, User Story, Postconditions, Preconditions, Triggers, Flow, and many more... There are a lot of templates actually. You can review them Here.
You do not describe visually* any preconditions or post-conditions, however, you have some tools that can describe which cases are **included in a specific case (in order to use feature Y - you should go over feature X). Or, which cases extends other cases (while you are using feature X, you can (but not have to) use feature Y).
Hope it helped :)
I encourage you to use a modeler rather than to draw your diagram by hand.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow
The exhaustive list of the features of S.O. is certainly very be long, and you will have problem too see it because surely some parts are hidden to 'standard' users. What is your goal, to model S.O. or to use it as an exercise ? On the second case it is not necessary to manage all
should there be another actor for Admin who manages user accounts, or not?
Sure they are admins or 'super' users.
if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
A use case is not only an ellipse in a diagram, and a model is not ajust a list of diagrams. Yes each UC must have its description and the possible pre/post conditions etc
What if other than these two actors, I decide to add a Mediator actor too ...
I don't know if there are mediators, but I am quite surprised by the 'mentor' whose role is to answer. If you have him you make a separation between the roles consisting to ask and to answer, so the other role cannot be the very general user but probably must be more specific
You will have lot of remarks about the UC login for sure ;-)
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a scenario which involves a vending machine and then asks us to create to "model the problem domain". I've covered modelling very loosely and was hoping someone would clear this up.
From research it looks like a problem domain is just a domain model which in turn is pretty much a UML Class Diagram.
The examples I've seen look they're almost database schemas with a customer entity, order entity etc etc.
I'm just not sure what the differences are exactly.
So I just wondered if I was on the right track and would anyone mind elaborating on this or perhaps pointing me towards a concise definition. Thanks.
The "problem domain" is just the stuff you're interested in. In your case, it's all the stuff a vending machine does, and who interacts with it.
It boils down to a collection of use cases, which can be diagrammed in a use case diagram. What does the vending machine do? It takes coins from a buyer (the actor), gives change (maybe...so make sure you understand "extension points"), spits out stuff (always, because we aren't in the real world), and so on. Then maybe you can get creative with a different actor. A maintenance person takes out money, adds change, fills up the machine, runs a diagnostic stack, whatever. Each one of these is a use case. Put them together into a use case diagram.
If you want to go into detail about what each use case does, then use an activity diagram. One for each use case.
Any system (software or not and modeled or not) has structural and behaviour aspects.
The structural aspects are non-time bound aspects of your system, such as which classes your system is made up of, their associations and dependencies, how they are divided into subsystems, etc. Most of these elements are often referred to as classifiers.
The behaviour aspects shows how these structural aspects collaborates together over time to achieve the goals of the system, such as methods, state machines, workflows, use case realisations, etc.
The structural and behaviour aspects are what you specify when you are writing your code or creating a model.
Objects, are by definition instances of classes. This means that objects are the "things" that actually exists when the system executes. Hence, you do not program an object; you program a class, which when executed, is instantiated into one or several objects.
However, in many modelling languages (but not common in programming languages), you can also model specifications of scenarios, which show specifications of objects and how they interact, for example in UML you may create an object diagram, showing one example of how the system of objects (i.e., instantiated classes) might be structured and collaborate during execution.
Now, a system always strives to a achieve one or several goals for it's surrounding. The surrounding is made up of persons and/or another systems (actors) interacting with the system. This "surrounding" or "background", on which the system is situated in and makes sense in, is often called the "domain".
These "actors" have a "problem" they would like that the system helps them to solve. When this problem is modelled, one calls that model the "problem domain model" for the system. It states the logical structural and behaviour aspects of the problem domain, without stating how it is going to be implemented in a specific implementation of a system. I.e., it is not referring to implementation aspects, like Java, SQL, primary keys, transactions, reflection, angular, etc; it is instead focusing on the core structures of the domain, like Orders, Parties, Contracts, Products, etc.
The problem domain model is one of the most important "contracts" between the system developers and the persons paying for the system or being owners and users of the system. It makes it possible for you all to understand the problem to be solved in the same way and are makes sure that you all are using the same concepts to reason about it. Since it, by definition, is not a technical artefact, you should describe it using as simple notation (but still stringent and crisp clear) as possible so that also non-software professionals could understand and agree on it. Class diagrams (stripped from all technical details) and use case diagrams are two notation techniques available. But also object diagrams and activity diagrams could come in handy.
If you are interested in this, I deliver a course in advanced concept domain modeling on Udemy. Here is link and 90%-off code: https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29
Regards
Per
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
As far as I'm concerned, included use cases can be reused, meaning included by other use cases or associated with other actors as well. But is that also possible with extending use cases? Can 'AddProspectiveIngredient' extend 'VerifyIngredient' as well (although it would not make any sense for this system)?
You could have many use cases, extending each other. For extending is a variation. Only that would be excessive. You don't need draw extend connection between A and C, if A-B and B-C are already so connected.
But you can have problems with the tool limitations. VP-UML works with "extend" not so well. Even the usual delete won't work correctly on "extension points"
Yes, you can reference a use case by one or more other use cases (using either one of the include and extend relations) and you can also associate included or extended use cases with your actors.
This discussion is helpful for distinguishing the include and extend relations in a use case diagram.