Do we include if conditions/alternate scenarios in a use case diagram?
Actually, I am making a use case diagram for a book order application. It has this condition that if the number of copies ordered are less than the copies of book available then it will create a shipping as well as back order and if all copies are available then it will only create a shipping order. So will this condition be included with "extend" in Check copies of book in USE CASE DIAGRAM? Or will this condition be specified only in a sequence diagram.
Use cases are about added value the system under consideration delivers to its primary actors. A use case contains activities which describe various paths how this goal can be achieved. But that's not exposed on a use case diagram. «includes» is to re-use a large goal within another use case unconditionally. And «extends» is used for optional parts which themselves must be "sub-goals". To actually show the conditional paths you create one or more activity diagrams per use case.
In your case the "Create shipping order" as single use case will be an extension of "Order book". When and under which conditions this extension is performed is hidden in the activities of "Order book". Your use case diagram only shows the «extends» relation between both UCs.
Related
So basically i'm wondering if I'm thinking correctly. In an e-commerce environment does the order of a product have a relationship to the admin use case of managing orders? Once an order has gone through is the admin then going to be able to see the order through a relationship between the 2 use cases. I've provided an image for reference in my case.Here is the image
TL;DR
No, there is no extension here. Those will be two separate UCs.
Explanation
First let me focus on the goal of the Use Case diagram. This diagram is intended to show functions of the system and users (or more broadly actors) engaged in those functions. It is not used to show how data flow through the system or what are steps of the processing. There are other diagrams to do that.
As a rule of thumb, something is a good use case if you can log into the system, perform only the action of this single use case and then log out.
Extends (Includes works pretty much the same, it's just stronger) means that when you run the extended UC you can include the other use case as well. In other words in your specific example when Customer logs to E-Commerce to place an order he can while placing an order also choose to additionally receive and manage order (BTW I would reconsider this UC, you probably have few separate UCs here like Complete order, Dispatch order or Reject order) in which case additionally an Admin is need. Even if you invert Extends, it's still not what you want. Those two UC happen totally separately even though the order processed by Admin is the very same one placed by Customer.
I did not search for too long but I did not find a case where a given use case, associated to one actor, is extended or included by another use case, associated to another actors.
A use case describe the usage of your system by a given actor so you do not have any other actor involved.
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.
I need to create a UML use case diagram based on use cases that I already have specified in an event table.
The event table has a source column which in my case is the same thing that I would specify as the actors used in the use case diagram.
My question is what is the difference between the actor and the source?
They're pretty much the same thing.
Event tables are just another way of writing up a system, similar to a use case narrative. A use case narrative is a way of documenting the activity of a single use case element in a use case diagram. The event table can form the basis for a use case narrative; you can also add an activity diagram for a visual representation of what happens in the use case.
Event tables have events, triggers, sources, use cases, responses and destinations. Analogous sections of a use case narrative are triggers, which are sort of a combination of events and triggers (How the use case starts), actors, use cases, post-conditions and exit points. A use case narrative can also have entry points, preconditions, and assumptions (assumptions are not tested, preconditions are), includes and extension points, and will also have a detailed description of the steps on the paths through a use case.
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 a system will generate reports every month. In the event table, I capture that event, but do I include that in a Use Case diagram? If so how?
Do all entries in an event table need to have a place in the use case diagram?
No: the event table contains the use cases, but the use case diagrams don't dontain the events which trigger them, just the actors involved in each use case.
When you elaborate the use cases, you can add the event as a Receive Event at the beginning of the activity (provided you're using activity diagrams for elaboration).
As to the second part of your question, if by "entries" you mean use cases, then yes: they all have to be shown in use case diagrams, because they explain how each actor interacts with the system. But you are of course free to use as many diagrams as you wish, and it's also a good idea to group the use cases into packages.
One way of grouping would be into packages "external", "internal" and "temporal", but whether that's suitable in your specific case is impossible to answer without the actual list of use cases.
In case your system generate report monthly, I suggest using the "System Timer" as the actor who trigger this use case. You can read more on this article
http://www.umlchannel.com/en/uml/item/24-use-case-actor-system-timer/24-use-case-actor-system-timer