I want to use package to group similar use cases. There is a problem about the included login use case, it make the graph not well presented. If I include the login use case in every package, I think it's wrong. Should I remove the login use case or remain?
Create another package "Common things" or "Support" or something like that and put "Login" and eventually other reusable use cases there. You will probably have some more commonly used use cases (like "Print report", "Logout", etc).
Than make all other packages dependent on that one:
This is a common practice of keeping your use cases nicely organized.
In this particular case of "login" I would recommend you not to "include" it in other use cases, but rather to keep it isolated and put the precondition ("User has been logged on to system") in all other use cases. This makes your model much cleaner and easier to follow, keeps the dependency and relationships count low, etc. Just imagine your diagram without this "includes" - looks better, right? :)
If you decide to do it this way, keep the same packages I suggested, but remove the dependencies (as the "login" is not included any more), unless there are other included/extended UCs that justify the dependency.
Login is not a UseCase at level of detail you presented in the diagram. Just remove Login Usecase and your diagram will be correct.
By usecase definition in UML. UseCase represents usefull functionality of system. Login is not a functionality from this point of view, but it is precondition to execute usecases you defined. It means, user must be logged on in order to interract with system within UseCase eecution.
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.
Case(Detailed): User select some files in android applicaiton and send SOAP request to WebService to set the selected files as Favorite.
Case(With few words): User want to set some files as favorites
Sequence Diagram is:
User-->FileBrowser-->WebService-->DbManager-->Database
So, is the below diagram correct or i am missing something?
Your diagram looks fine. However, I noticed from your other question that you are now mixing business and technical aspects. If you want to do a use case synthesis for the business (which is the most common application of that) you must not start mixing technical aspects. Having said this, Login is not a business use case. A use case describes in short terms the added value which an actor receives when applying it. On a business level, a login is just a constraint since it does not add any value.
As an advice:
Start with use cases on a pure business perspective.
Think what actually is added value.
Which are the stakeholders?
What are their requirements?
Which requirements can be synthesized to use cases?
Only after that start a technical design. In that you may use use cases on a technical level where you may describe a Login use case as part of an authentication sub-system.
Should you not include some kind of system, whereby user and server is outside of it? My teachers always commented on involving the system.
List all the users outside the system. The use case serves as an answer to:"What will the system do?". Is the database used by external users/systems? In that case it's better to represent it as a seperate actor.
Perhaps an idea to write a full use case before making a use casediagram.
Two things are not according to UML:
The include dependency should have an open arrowhead pointing to 'selct file'.
The word include must be surrounded by «guillemets»
Recommendations:
Use a consistent naming convention for the use cases. It is common to use imperative style, with at least one verb and one noun e.g. "Select file" and "Choose favorite files".
Draw a system boundary (rectangle) around the use cases, leaving the actors outside of the boundary. Enter a descriptive name inside the boundary, e.g. "Android app".
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
I'm creating a UseCase diagram for a library management system . I have a "Login" usecase which every actor should do befor going to other usecases . in other words , I want to show that "Login" usecase is the prerequisite to other usecases .
anyone know how to show this ?
thanks
There are a few ways to do this:
Use the <<include>> relation, where every UC <<includes>> login as the first step
Set a pre-condition on every UC that User must have logged in
Create an Actor named "Logged in User" (or similar) and show all your Use Cases related to it.
Which you choose depends on a number of factors. (1) is simple and intuitive but doesn't really scale well on a diagram if you've lots of Use Cases. (2) works well if you're documenting Use Cases textually - but doesn't show up on diagrams. (3) might not be conventional, but can provide more scalability than (1) while still be viewable on a diagram. However it breaks down if you have multiple Actors, each of which must be logged in to perform their UCs.
I personally tend to use (2). If I need a UC diagram I'll include a "Login" UC on it but won't show relation from it to other UCs.
One option I wouldn't recommend is the <<extend>> relation, where every UC <<extends>> the login UC. It doesn't really work semantically and suffers the same scalability issues as (1) above.
hth.
An alternative to an <<includes>> relationship in this case is a <<precedes>> dependency. This makes it clearer that login must precede the use case rather than simply occurs at some point during a use case.
Enterprise Architect includes such a stereotyped dependency in its Use Case toolbox, but you could otherwise create your own stereotyped dependency. The EA documentation on this states:
Invokes and Precedes relationships are defined by the Open Modelling Language (OML). They are stereotyped Dependency relationships; Invokes indicates that Use Case A, at some point, causes Use Case B to happen, whilst Precedes indicates that Use Case C must complete before Use Case D can begin.
You may not want to introduce OML idioms to your UML, but the feature does exactly what you want and is visible at the diagram level.
UCs are useful for many things, but most importantly for communication. If you start using relationships on UC diagrams, your communication benefits drop down a notch. Same with copy pasting prerequisite "user X must be logged on" in each UC, etc.
Most importantly UCs are not intended to be complete system specification. So simply put it somewhere else, for example:
as a rule in overall system rules list
as a table in "user access rights" spec section