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.
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.
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'm setting the use cases of a project, here are some of the details :
My question is two parts :
first one :
I have an actor user.
The user can register on the website.
He can login, view profile, edit password.
Regarding the previous use cases, I'm confused how to visualize the use cases in the diagram, I was thinking it might be done like the following :
Create a use case "Manage Profile" and connect the other use cases "View Profile,Edit password, etc..." to it with a generalize relationship. and then connect that use case to the "loginCheck" use case with a "include relationship". The actor will indicate "manage profile".
Create a sub-system "Profile" and set the use cases related to within it. then connect it to "loginCheck" with "include relationship". The actor will indicate each use case.
second one :
The user can Add bet : there are some types of bets:
mutual bet :
1- single bets.
2- combination bets
long term bets
championship bets
Should I create a general use case "AddBet" and extend the other types to it.
I can't upload photo directly because I'm new .
First of all, For me I saw a lot of "link" inside your diagram which seems to be use in a wrong way. Maybe you can take a look at some UML ressources and more specifically, association, generalization, include and extend links... BTW I am just curious to know which tool do you use for this? Visio or ArgoUML?
So now concerning your(s) question(s).
When you want to associate an actor to an usecase you have to create an association between them not a generalization
If you want to specifiy that an "manage profile" use case can include (or not) changing password, view its profile, etc for this I would use an extend link.
For modelling the fact that an given use case mandatory include another one I would use include relationship.
the creation of an "add bet" use case "exntended" by the other one would indicate that you have a lot in commmon between all this possible bet.
Please take a look at my screenshots and let discuss about it.
On the Use case diag you should have only actors, visually different systems (such as terminal, client computer, server computer or Profile management system, Betting system ) and real-life actions(use cases).
Systems are shown as blocks, actors as people and use cases as ovals that connect sides of the action.
You should Profile Management as a system, as a protagonist in dialogue user-system. And you'll see, that Mobile bank is NOT a use case, is not an action. Maybe, it is another subsystem, or maybe simply won't belong there.
On your other diagram obviously different sorts of bets are descendents of the "bet" use case. They do not simply extend it.
You have many use cases not connecter to anybody. WHO does these actions? It is the target of UC diagram to show it.
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
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.