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
Related
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 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 you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.