I am working on a use case diagram of a fully automated system. An external system will trigger just one use case of this system. Most of the other use cases are scheduled tasks and invoked by the timer. I have a use case that is invoked by the timer and it includes and extends two other use cases.
When I write the use case discriptions, who will be the actor for UC-2 and UC-3. Can a use case exists without an actor? I have seen lot of use case diagrams which has included or extended use cases without directly conneced to an actor. Please clarify this. Thanks in advance.
EDIT:
My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit.Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database.
Officially this is correct. An included use case is a mandatory part of the including use case and an extending use case will optionally extend some use case. As #Ister notes in the comment, the actor for the included/extending use cases will be that of the main use case.
But, and this from my experience, you best avoid the use of those include/extend relations. In most cases, people tend to use them for functional decomposition which is plain wrong. A use case shall show an added value for its actor, not how a piece of functionality is used somewhere. In most cases a structuring of added value is not present and you can well show each bubble as a stand-alone use case or integrate it into the main use case. I recommend reading Bittner/Spence to get into matters.
Edit1: I just realize the sentence
trigger just one use case of this system
This rather sounds like you mix use cases with activities. It's not a piece of functionality. A use case is added value. There is a scenario (set) for a use case which has a trigger. But saying "a use case is triggered" sounds just wrong. You trigger the activities of a use case (where it starts getting technical). Most techies have difficulties making the cut and abstract to use cases. One more reason to read Bittner/Spence.
Edit2: In your comment you are talking about technical use cases. I admit that I had intensive discussions about this in the past. But you need to differentiate between technic and business. Your business use cases are Analyse DBMS, Check Performance, and Tune database. As such they are no UCs for a Timer but for some institution that cares about performance. The only UC for Timer is Trigger task (or something like that). There is a cut. The Timer does not care about business. It will happily trigger the shutdown of the system in the same way. It does not become a business actor only for that fact that it is technically used to start some business relevant process.
And not to forget: read Bittner/Spence. For me this book was an eye opener since I also had no idea about the intention of use cases.
It is likely that UC2 and UC3 are not really use cases but in fact steps/actions within the UC1. A good way to check to see whether you have real use cases is to ask your self if there is any actor (human, system or time etc.) that would have that use case as a complete goal. In other words would any actor initiate this use case. In addition to this - Occasionally you may have a use case that has no actor initiating. This should occur only in the case that there are multiple other use cases (i.e. at least 2)that will either include or extend that use case. In this case the use case is there for the purpose of facilitating reuse in your model and simplifying the model - in particular when you write your use case narrative. Don't go out of your way to create include and extend relationships always double check - if no actor is using the use case you are including or extending and no other use case is using it then you absolutely don't need it.
Use case is always a scenario executed by actor(s). In your situation primary actor is the system under discussion.
Technically you can introduce a timer as an actor who executes first UC-1 step, but better KISS. Just add a line before UC-1 steps via common convention:
Trigger: timer according to [Link to requirements about timer schedule].
If you have to write something beyond this line (for example timer checks conditions before triggering UC-1) then timer must become an actor.
Overall your use cases structure looks very valid for me, just don't forget to connect UC-1 to some higher goal anyhow. And please remove extends/includes as already mentioned.
Related
I have a question related to Use Case diagram for a mobile app and charging.
So let's say My use case is Set Charging mode. Charging mode can either be Immediately or Scheduled Later. What Relationship should be between the Set Charging Mode UC and the two different options?
I have thought about using Generalization but I am not 100% sure this is correct.
Not knowing much about your context, I nevertheless understand that "Set charging mode" is not really a user goal: it's not a set of behaviors with observable results of value for the user. As such it should not be a use case.
In principle, "Set charging mode" would be part of the description of the real use case (e.g. getting something for which the user will be charged). Or maybe you'll specify the expected behaviors in a separate activity diagram.
If I'd be wrong, or if despite the advise you'd opt for a use case, the use case should require a choice, and a mutually exclusive one. This would be part of description of the use case Set charging mode, or indicated as a comment for the use case.
If I'd still be wrong and if you'd really really want to show two use cases, you could indeed either have two specific extensions to the choice or consider specialization. However, from your description, I still understand that these use cases would not be independent (Set charging mode or Set charging mode to later make no sense on their own). Moreover they seem far too detailed for a use-case. I'd therefore really advise not to follow this way keep UC for the big picture and avoid getting lost in details better documented elsewhere.
To complete Christophe's answer, you have to keep in mind 2 things (at least):
the purpose of a use case diagram is to help you in the specification of the problem and later in programming
UML does not define a level of granularity for a use case except the famous 'observable and tangible goal' but to help you, keep in mind that a use case is detailed with an activity diagram (among others). In your case, the corresponding activity diagram would contain ONE action
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.
Hi, I would like to have the receptionist and the manager to be able to view work type and rates and subsequently update it. However, tech personnel can only view but not update. Is the diagram valid?
I read that extended use-case are initiated by actors that initiated the base case. How should I differentiate that tech personnel can only initiate the base case and not the extended case? Should I not place the extension association? What about included use-case?
Sorry if this question has been asked before.
You should neither «include» nor «extend»
View work type and rates and Edit work type and rates are perfectly valid independent use cases.
In general it is a bad idea to chain use cases together just because you usually do one after the other.
You should not try to model the sequence of activities with use cases. Use your business process analysis for that.
You can use the post- and preconditions to constrain the execution of use case. In fact your Edit use case doesn't really require the View use case in particular to be executed does it?. It probably only needs a work type to be selected. So it can be executed right after any use case that has a postcondition stating that work type is selected.
Which use case does that is irrelevant to the Edit use case, as long as a work type is selected before the use case starts. There might be 10 different use cases that result in a work type being selected.
The «extend» I consider to be simply wrong. Extending use cases are usually incomplete use cases that insert their behavior into a complete use case are a particular extension point defined in the extended use case. The extended use case in does not have any knowledge about the extending use case and does not need or use the results of this behavior.
The few cases I which I found «extend» use cases to be applicable were things like monitoring use case. For example a use case that monitors the number of open tickets in the system and sends an alert to an admin in case a certain threshold is surpassed.
If you still insist on linking the use cases together, for example in case you really mean that you can only edit rates after executing the use case View work type and rates I would do it the other way around. Include the use case View work type and rates from the use case Edit work type and rates, probably as the first step.
Both solutions (separate use cases, or include from Edit to View) solve your issue regarding the rights of different users as it is now clear beyond any doubt who can do what.
I'd model it this way:
Manager and Receptionist have the same roles in this context which is why I used a generalization. Without knowing the domain this seems okay, but it's just a proposal.
The <<extend>> is constrained by {not allowed for actor Tech} which clearly excludes this actor from entering this (optional) use case.
There is no need to also associate Receptionist with Update... since it's an extension of View..., except you want to be able to Update without Viewing first.
N.B. about <<include>>/<<extend>>: They are not meant as chaining use cases. The UML spec states (pp. 638):
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.
and
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common.
Now that <<include>> just looks like a bastard. A use case is about a unique added value. And this uniqueness can be questioned if there were behavioral recurrence in more than one use case. In any case these relations are often just taken as functional decomposition. And that would be plain wrong. From my POV the UML spec would be better without these relations.
In context of the above diagram it represent a pattern where you view something and only then can make it editable. It would well be perfect to have two individual bubbles without <<extend>> where you place a constraint in Update telling { can only be reached after View... }.
I would change extend by include. To update the work, you have to view it. It is mandatory to view it.
In your diagram, Manager and Receptionnist are equivalent, with this schema only, you can define one actor only. Or model that Manager inherits from Receptionnist.
And to avoid mistake, if you do that, you have to be sure that Receptionist and Manager can also activate the view use case without the update. Otherwise some associations have to be remove.
[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.
Does anyone know how to describe (specify) the use-case that includes another usecase in the use-case specification table?
For example, I have a use-case "change password" that includes use-case "login" (this is just an example, i know that login should just be in the pre-condition of the use-case)
May i specify it like this?
Use-case identity: Change password
Actor: User
Pre-condition: ...
Normal flow:
Do use-case "Login"
....
....
....
What is the proper way to specify the use-case that includes another use-case?
It depends on the further rules and conventions used together with the "use-case specification table" document. Consult your company documents for the rules (and some examples).
Overall yes, your approach is valid.
The "Login" use case might be also invoked implicitly if you'd move it to the "Pre-condition: User is logged-in"
Even for free text without any Software Requirements Management tool consider using the "Name and unique-number" referencing best practice
To wrap your head around it I'd recommend (among other Google-able resources) to read the Alistair Cockburn's book "Writing Effective Use Cases", draft version is available online on his site - http://alistair.cockburn.us/get/2465
EDIT: after #BobRodes's challenge to share some alternative methodology
For more serious work consider using a Requirements Management tool, or at least evaluate some tools to adopt the best practices they support/recommend.
For one example see the link below explaining how Sparx Systems Enterprise Architect formalizes work with Use Cases and how Use Case traceability works and how it can generate documentation, UML Activity Diagram etc.
Sparx Systems: Model-Driven Use Case Analysis with Structured Scenarios, Webinar August 2013, 18min video
For another example of managing Use Case traceability and what usually happens after the Use Cases are written see
Jama Software: Jama Recorded Demo, 30min video
You might want to look into "use case narrative". In such a narrative, one of the things you will do is list included use cases and extension points. So, add a section called "Includes:" to your narrative, before the normal flow section.
Edit: Here's a bit more from Tom Pender's "The UML Bible":
The features of a use case narrative aren't standardized, but these
are common elements in wide use:
Use case initiation, or trigger, describes how to start a use case.
Assumptions define conditions that must be true before the use case may execute, but are not tested by the use case.
Preconditions define conditions that must be true before the use case may execute, and are tested by the use case.
The use case dialog explains how the user (whether an actor or another use case) interacts with the system during the execution of
the use case.
Use case terminations define the different mechanisms that can cause the use case to stop execution.
Post conditions define the state of the system that must be true when the use case ends. This helps prevent use cases from leaving
the system in an unstable condition for other use cases that follow.
Minimum guarantees describe what the actors can expect from a use case, no matter what happens during the execution of the use case.
Successful guarantees describe what the actors can expect from a use case when it completes successfully.
Although these elements are valuable, they are by no means exclusive.
Definitely look into other books and online resources on use cases,
and augment the narrative to support your own method of development.
So, perhaps I shouldn't have said that you "will" list included use cases and extension points, instead saying that you "may" do so. I like to put them in, so I don't have to keep referring back to the diagrams to look them up. Of course, you can just mention them in the dialog, too.
In UML there is standard relationship named include. Start relationship from including UseCase and end on included UseCase. See UseCase section of UML Superstructure document. UML website