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.
Related
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.
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 came across a situation where a use case has two options to choose from.
Example: Use case "Process data" has options like "Approve" and "Decline"
If approve, update the inventory.
If decline, file the information.
I know how to represent this in an Activity Diagram but I have no idea of showing it in Use case diagrams.
There are two choices here.
A) You make two use cases instead of one. Approve Data and Decline Data
B) You make one use case Process data. In the main scenario you describe the steps for Approve Data and in the exception or alternate scenario you describe the steps for Decline Data. In this case the difference is not visible on the use case diagram, but that is OK. Use case diagrams are meant to give you an overview of the big chunks of behavior in your application, not of the details.
The choice for alternate or exception scenario depends on your post-condition(s). If the Declinescenario meets the post-condition then it is an alternate, else it is an exception scenario.
The term Data is not very specific. I would prefer something more meaningful then data like Order, Application,...
I can't know for sure without knowing all the details, but option B) is probably the best.
A usecase has a specific goal for a specific actor.
Identify the Actor for the usecase(s).
Identify the Goal of the Actor.
Define the usecase with a strong specific verb, process is weak unspecific verb.
I find the requirements ambiguous, it seems you may be conflating two separate Actors.
See the Uml Style Guide : Usecase
You create two views of the same usecase. In the first view you create Process data with Approve and a second one with Decline. Each view is a different usecase diagram but using the same usecase.
It is important to make a clear differentiation between graphical views and model view. I mean that graphical usecase diagrams should be a view which is extracted from the UML model.
if not then use this link http://msdn.microsoft.com/en-us/library/dd409427.aspx
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
If you believe that a use case flow of events creates an actor, how would you model that?
I have a use case that creates a windows service, which (in my mind) is another system with its own set of use cases and actors.
At the moment it is not obvious from the use case diagram that an actor gets created as part of the flow of events.
Aidan.
Use case diagrams do not display a sequence of actions. There is no time dimension. As a result, it makes no sense to create or delete an actor.