I have an account based system,it means that every feature of the system can be used only after Log In.Also,as far as I know in use case diagrams we 'include' something in the base case if it is meaningless without the included action.Back to my problem,I have to draw the use case diagram of the system mentioned above and since every feature of the system can be used after login do I have to 'include' LogIn in every use case?
No. It is common practice to define "The user is logged in" as a postcondition for use case "Log in" and as a precondition for the other use cases.
In the use case community, people disagree on whether "Log in" should be a use case at all. According to UML, every use case must yield an observable result that is of value for actors or other stakeholders. A use case like "Log in" does not satisfy this requirement, in my view. Still, this use case is a useful way to describe the system's behavior during the log in process, so I would just keep your "Log in" use case.
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.
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.
How to present on the diagram of use cases that
before any activity an actor needs to be logged in into the system?
e.g Use case "Display information about an employee" uses server and the another use case ("Search the employee in the database")?
Is my use case diagram correct?
You need to set pre-condition constraints for UCs telling { user must be logged on}.
Your UC diagram start resembling a spider's web (and is hardly recognizable). A good indicator that your design went wrong somewhere. Look at the single UCs and ask yourself: does this represent added value for the actor? If the answer is yes, you're fine.
After some zoom I see "Employee management", "Account management" and others that simply do not name UCs meaningful (they are likely processes). Use verb-substantive. And keep above question in mind.
A quick google indicates that use case preconditions are a useful way to represent the requirement that a user be logged in first. However, preconditions can clutter the UC diagram with text and possibly restrict the number of use cases on a particular diagram. I suggest creating a new actor that is an "authenticated user". This differentiates the actor from a user that has not yet logged in and allows clear representation of the use cases available to each.
In a use case diagram for a web based hire system that I have, the following two functionality were required.
1. To validate a user's login before carrying out a payment function.
2. To check the availability of a certain tool and a time before the user is allowed to hire it.
So, for Case 1, I believe the following is correct. Is this the proper use of an include condition, or is there some other use as well?
An actor has an association with a MAKE PAYMENT use case. An include statement is drawn from the MAKE PAYMENT use case to a VALIDATE USER LOGIN use case.
For Case 2, I mapped it like this. However I feel that this isn't correct.
An actor has an association with a CHOOSE TOOL use case and a CHOOSE TIME. An include statement is drawn from them to a CHECK AVAILABILITY use case.
I think first that the two use case to choose might be more accurately depicted in a single use case, but I can't think of how the availability is to be mapped. Should it be in the specification only?
I would post diagrams, but I don't have enough reputation to.
Welcome to Stackoverflow.
Make "Validate user login" a precondition to "make payment", i.e. do not make it an extra use case. The user will not validate that he himself is logged in, the system does that for him and it's trivial. The precondition is noted in the use case description.
"choose tool" <<include>>s "choose time". That is what the user needs to do, while
"check availability" is what the system does for the user. So that goes to the use case description as well, and is not a use case of its own.
"make payment" <<extend>>s "choose tool", of course.
I just want to determine if I am using extend and include correctly. If I am using either incorrectly somewhere here please indicate where, and if possible, why it is incorrect.
https://imageshack.com/scaled/large/163/nlnk.jpg
Cheers.
Rules for using <<include>> and <<extend>> are simple:
<<include>> defines a sub use-case which is always included in the general use-case: use-case -include--> sub use-case. Usually it's used to denote a distinct part of a use-case or a common part that can be reused by other use-cases.
<<extend>> defines an optional sub use-case that can be executed upon certain conditions (which should be defined at a lower level design, not in use-case diagram). Here the direction of the relation is opposite to the <<include>> relation: use-case <--extend- sub use-case.
Apply these rules to your diagram and figure out if it's correct.
It looks as though "secure login" is required to be performed prior to the other activities that you link with <<include>>. Include implies that the use case also runs the included use case every time which in this case is probably not what you intend (just one login per session). You can always create new stereotypes, such as <<precedes>> or <<requires>>. Using them consistently will allow you to convey your meaning.
I find this piece of advice before when I'm trying to distinguish the difference between using extend and intend in use case diagram.. I hope it helps you too. The original advice comes from this StackOverflow answer.
Difference between extend and include
Extend is used when a use case conditionally adds steps to another
first class use case. For example, imagine "Withdraw Cash" is a use
case of an ATM machine. "Assess Fee" would extend Withdraw Cash and
describe the conditional "extension point" that is instantiated when
the ATM user doesn't bank at the ATM's owning institution. Notice that
the basic "Withdraw Cash" use case stands on its own, without the
extension.
Include is used to extract use case fragments that are duplicated in
multiple use cases. The included use case cannot stand alone and the
original use case is not complete without the included one. This
should be used sparingly an only in cases where the duplication is
significant and exists by design (rather than by coincidence). For
example, the flow of events that occurs at the beginning of every ATM
use case (when the user puts in their ATM card, enters their PIN, and
is shown the main menu) would be a good candidate for an include.
Also, from every book I've read, it is always recommended to use include and extend sparingly. Keep It Simple Silly.
Many relationships are clearly not correct here. However, I think the main issue with this diagram is not the correct use of include and extend, but rather to complex and overall unclear relationships. Although sitactically valid, you should avoid using more than one level of these relationships.
Your diagram is really hard to follow and to interpret.
Some refactoring ideas and corrections:
show "Secure login" class separately, linked only with Actor and then apply the following precondition for all use cases that "include" it: "User is securelly logged in"
"Logout after 5 mins" should be own use case, only connected to Actor as well, with 2 preconditions: "User is securelly logged in" and "User was inactive for 5 mins"
Remove the include between "Logout after 5 mins" and "Initiate a call". Extend might be more appropriate
reverse the direcction of the include between "Transfer funds..." and "Insure adequate funds..." - it is clear that the first one includes the second one and not vice versa
consider breaking a diagram in 2 or more simple and small diagrams of only related UCs: all login/logout could for example be shown separate and simplify the view. You should not have more than 5-7 use cases on one diagram