I'm trying to model a use case, basically it's how a round is played in a quiz-show. the actor in the use case is the quizmaster; he asks the questions to the participants.
There's a lot going on in this use case but my problem comes down to the point where the quizmaster has to wait for a player to buzz his button and give an answer to a question he has asked so it can be judged (Right or wrong).
There's a seperate use case the actor "Candidate" follows to answer the question the quizmaster has asked.
How do I model the fact that the quizmaster has to wait for another actor to do a use case before he can continue with his own use case? Or is it better to just seperate them all into smaller-sized use cases. My teacher advised against that though so I was looking for a second opinion here.
You can either do an include as user3934037 suggested, or you could make it separate usecases and work with the pre/postconditions
In that case you would have usecases
Ask Question
-> precondition: Candidates ready
-> postcondition: Question asked
Respond Question
-> precondition: Question asked
-> postcondition: Question responded
Judge Response
-> precondition: Question responed
-> postcondition: Response Judged
Instead of linking use cases in a sequence together you leave them independent of each other. Use Case "Judge Response" isn't waiting for a specific use case to finish, it is waiting until it preconditions are met, however that came to be.
In general I advise to keep order of execution out of use case analysis (and leave it in business process modelling)
UseCase declare usefull functionality of modeled system. There is not any way to define execution aspects as you described in your example.
If you need to define some of event processing or actions, use some of behavioral element (Activity, StateMachine or Interaction).
I agree with Geert on this, except I would more strongly advise his approach. Use cases aren't designed to explain any sort of flow, period. You can use preconditions and postconditions to infer an order of execution, but if you want to be crystal clear on the order of execution of a use case, take Vladimir's advice and map it out with an activity diagram.
I want to say this first.. there is no correct answer in UML. If you can explain your thought correctly with your uml diagram, that is the answer.
I think this can be solved with <<include>> relation. CaseA ---<<include>>-->CaseB means CaseA can be performed when CaseB is satisfied.
for example,
"withdraw money from the account" ----<<include>>----> "authenticate the user"
I guess it can also be used to describe the sequence of each use case. :)
UML explicitly does not cover this need by a recommendation (AFAIK). It seems to indicate that there's something odd in your current Use Case analysis. Maybe structuring your Use Case Diagrams using design scopes and goal levels into several levels of detail would eliminate the sequencing
This is how Alistair Cockburn suggests to balance the Use Case density in article "Use case goals versus design scopes"
See also:
uml-diagrams.org: How to Draw UML Use Case Diagram
Related
The use case should depict this situation:
A shipman can ask questions via radio to either a VL, DM or WL. Depending on the question, they need to look it up in APIC (a software tool), but this is not always the case. They all are apic operators, but depending on their role, they have their speciality that they only can access in apic.
The question the shipman asks can be about lock executions, the nautical weather, etc... but it all comes down to the same question-answer format.
Is my use case correct?
Asking a question is usually not a use case. The goal of the shipman is probably not to ask a question, but to get some answers. So asking and anwering is one use case.
When analysing the use case, several possibilities will show up, such as looking up information in the APICS-system. I would just describe this within the use case (possibly with an Activity Diagram). What is the advantage of using an extend here? (I agree with the other answer, that the arrow is in the wrong direction. Additionally it should be an open arrow).
Each goal is an own use case, even when they have much in common. After describing the essential steps of the use cases, it may save some work to look at them and find those that have a big overlap in the essential steps and then create an abstract use case containing the commonalities. But this should only be done after describing the use cases.
Always remember, that the main goal of use case analysis is to find all functional requirements for the system, especially those that are not immediately obvious. If your use cases are just wrappers of functions you already know, not much insight is gained by them.
Three issues here:
The extends arrow is the wrong way around.
Generalizations of UCs is a bad idea in general.
Just as a side note: your actors miss their legs. This way it's a Female symbol (Venus' mirror).
Let's elaborate a bit on the 2nd. Why is it a bad idea? UCs represent a single added value for an actor a system under consideration will deliver. So each UC is unique (think of unique sales propositions). Generalization of USP is only valid in a franchise. So unless you model McDonalds here, it's likely a wrong approach. Look at the main UC "ask question". Do you consider that added value from a system? I wouldn't. When looking at the bubbles behind they more look like primary use cases. So, just remove that general "ask question" and connect the bubbles behind directly with Shipman.
As always when it comes to UC questions: Bittner/Spence about UC is the best read I can recommend.
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
With this Use Case diagram, I'm unsure if I'm currently doing it correctly or not. Checked online and each site is giving me a different answer. I just need a direction or someone to correct me.
This is interesting as I am currently going through the exact same discussion with a client...
I would say "no" simply because I am unsure of what this actually represents.
A use case must bring a benefit to a user, and I really don't this in this diagram. What does Actor0 actually trying to accomplish? I do not get this from the diagram.
Did you write down statements before trying to do this? I find that going to a whiteboard and writing down what your actor's goal and how you see this happening so that the actor achieves the goal is a good start to better understanding the use case and differentiate the system being built from external systems. One way to do this is through a set of user stories (or use case slices).
And answering Thomas Kilian's excellent questions will also help you in this task!
Also, you are doing something that I see too often from people starting with use cases (and sometimes with UML experience): use case decomposition as a set of actions - basically trying to model a set of activities by breaking it down. Doing that is typically the second step in your analysis (e.g., by using activity and sequence diagrams).
No. Only "Register" (what?) and "Add/View Details" (which?) can be regarded as use cases since they add value. Neither "Login" nor "Main Menu" are use cases. The first is a constraint and the second an implementation detail.
[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.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.