guys how can I make conditions in use case diagram ? Something like decision node in activity diagram.
For example, If there is "evaluate" usecase which can lead either to Y or N, there is simply no way to express it. There is only constrain feature, that would lead to repeating { if evaluated } {if evaluated } ......
What you probably want to use is alternative paths, basically what you do is you repeat part of your use case like this:
In step 5, if there is not enough money on the account
5.a Show a message to the user
5.b User press "Try a lesser amount" button
5.c System goes to step 3
The Use Case Diagram doesn't seem to fit at all with conditions. Usually, when depicting multiple scenarios, one would make multiple use cases for each one. An activity diagram would be more fitting to display conditional logic.
Usually, conditions (IF) exist somewhere in the use case's activity that would cause the extended use case to occurs. You can add to extended use case to represent yes/no scenarios.
Related
I'm practicing drawing a use case diagram for a very simple case, a color-guessing game.
I don't have a picture but it is really simple, with two bubbles for the Player actor to interact with, Play Game and Reset Game.
I would like to add a condition "initialize game" for both use cases, in Play Game it is a precondition and in Reset Game it is a post condition.
It cannot be another use case because the actor would be then System or Game and that's not feasible. Only Player benefits from performing the two current use cases.
How should I include that condition in the use case diagram? Or should I?
No.
Use cases are about added value. A single use case shows a single added value brought to its primary actor by the system under consideration. Nothing else! Use cases are a very high business view on the system under consideration.
The conditions you are talking about are part of scenarios you design to implement reaching that added value. And it's hidden in activities inside the use cases.
Other conditions like "user must be logged in" are constraints and attached to use cases somehow. No need to show these on a diagram (though you may if needed).
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.
How to show «include» and «extend» in activity diagram?
And how can I show types in activity diagram. E.g. Vehicle is of 2 types i.e Bike and Car. So how can I show this in activity diagram?
(This answer is independent of whether or not you should use «include» or «extend».)
A use case can be specified any number of ways. For some examples, you can use natural language, tables, or activity diagrams.
It appears that you would like to specify use cases as activities. In that case, each use case is specified by one activity diagram. The one to one correspondence between a use case and an activity also holds true for included use cases and extending use cases.
The way you would specify an inclusion on a use case's activity diagram is as an action that calls the activity of another use case. It's that simple.
The way you would specify in extension is more complicated. The UML 2.5 specification says:
The specific manner in which the location of an ExtensionPoint is
defined is intentionally unspecified.
An extending use case is one that composes one or more extension points. Each extension point may specify a condition that must hold in the extended use case. When that condition holds, the extending use case's behavior will activate. This extension point does not show up in the activity diagram of the extended use case.
Regarding your question about types, none of us really know what you're asking. Please let me know whether or not this other answer is what you need: Linking activity diagram to entities to be accessed.
Simply speaking: you must no show it if you avoid it. I/E are bad constructs since they lead people to using functional decomposition during use case synthesis.
If, for what reason ever, you have a case with I/E you can place the Activity of the according use case as invocation action in your sequence of actions. That will simply represent the I/E. And depending on whether it's optional/mandatory will be clear by the flow of events.
I leave your type-question out until you clarify that.
What is corret use of this model .. the 1. or 2. ? ... or should have 1. extends instead of include ?
I guess the UC in #1 should read "item selection" and not section.
Both of your designs are wrong in the one or other way. "item selection" is not a use case. It does not deliver any value to Actor (at least none I could imagine). So you are trying to put a CRUD into a use case. Re-think on what the actual value is the Actor expects.
Now for include/extend: Avoid them where possible. Once you start decomposing use cases you got it wrong and if your use case diagrams resemble spider webs your design is simply broken. Use cases are synthesized, not analyzed. While the first tried to build a complete picture, the latter is something you need in code design to cut it into manageable pieces.
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