Should I enter as an use case: "Update database","Add to database" to my UML diagram? (The scenario: the user registers and then the credentials are added into the database)
And if I have and external database for my project should I include it as an actor?
A defining feature of a Use Case is that it must deliver something that is end-to-end business-useful, i.e. it must represent something that is completely useful to the end-user. The oft-used example is an ATM —- “withdraw cash” is useful (and therefore a Use Case), whilst “enter PIN” is not on its own useful (and is therefore merely a function, not a Use Case, though it maybe a step in a Use Case). Given this —- how do you view your proposed Use Cases? Is “update database” itself completely useful, or is it a step in something else like “register User”? To answer your second question — it is unlikely that you’d have a database as an actor. Not impossible, but unlikely. It sounds like the “database” is part of your system, not an actor associated with it, but without more info. that’s a guess.
Related
I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.
I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:
From the point of view of the semantics, the use-case specialization means that Open presentation is a special form of Check file, and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file
From the point of view of the purpose, a use-case should represent a user goal. It's part of the problem space, i.e. what the user wants to achieve. It's not part of the solution space, i.e. how the user will achieve it. A toolbar is not a goal: it's a user-interface element.
From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:
The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
in The unified software development process, page 164
So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or a a voice-based interface.
While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.
A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.
While naming the use cases, you should only use verbs and actions, for example:
1- Login | 2- Submit a Request | 3- Update Profile Description
You should avoid any nouns in them.
There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:
Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.
In the example above, User is caple of loggin in and submitting a complaint.
Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.
Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.
Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.
Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.
Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.
Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.
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.
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.
[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