I'm very new to UML, especially use case diagrams. I attempted to draw a use case diagram for my application which includes a renter, a seller, and a general user. My renter and seller extend general user. I am having trouble with includes and extends. For example, When you view an office space, you can also see the reviews for it at the bottom of the page. As well as when a renter wants to write a review, he/she must do this on the view office space page. I am not sure if this is an extends or an include. Please correct me if I am wrong with any of my arrow directions. Also, is it okay to say that Renter and Seller include logging in?
As Jim states: I/E are for UCs, not for Actors. I assume you meant a generalization here, so both inherit from General User.
Some further observations:
Use verb-substantive for UCs titles
Think of the "use" in use cases. IOW: the added value. If you don't find it's added value, then it's no use case.
Avoid I/E in general. They often indicate that you try to use functional decomposition which is not the aim of a UC synthesis.
The relation you draw between the UCs is wrong in any case. There is no relation which has a filled triangle and is dotted. You probably meant to use some <<include>> dependency (with an open arrow). But as said above: avoid it. Just create an association to the actors. It's sufficient to just draw one between Reviews and General User as Renter will inherit the relation.
Login/out are no UCs (no added value). The are constraints to other UC (write {must be logged in} and attach to the connector)
You generally should not model login use cases, as they don't directly help the user accomplish anything he or she cares about.
Includes and extends are relationships between use use cases, not actors. The UML 2.5 specification says:
An extension is:
A relationship from an extending UseCase to an extended UseCase that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase.
An include is:
An Include relationship specifies that a UseCase contains the behavior defined in another UseCase.
A generalization / specialization relationship between actors is perfectly fine. That's just a generalization arrow. (e.g., a solid line with a hollow arrow head.)
Related
I want a use case - store information system. I am to present the owner's requirements on a use case diagram, incl. a customer who, after logging in, does shopping, and an admin, who after logging in, manages prices, etc.
Can I log into the system generalize from one use case - two actors combined with one use case (below)? How can I 'improve' the diagram?
UML does not specify the semantic when more than one actor is associated to the same use-case. It can mean for example that one of the actors only is involved without the other, that the two actors are involved at the same time, or that the two actors are involved one after the other.
For sure, actors and use-cases are classifiers. You can therefore use generalization of use-cases or of actors (as explained with an example here) .
But your diagram, while syntactically correct, has some issue:
First Admin account is not a use-case: it does not produce any observable results to the actor; it is an internal detail of the sytem. So it does not correspond to the UML criteria of a use-case.
Then, Login, Confirm password (and perhaps Checkout?) do not correspond to user goals. As explained here, this is not fundamentally wrong according to the UML specifications, but it is a bad practice. Use-cases are meant to describe actor goals, and not details of a process or a user interface.
Maybe i'm old school, but you should also surround the use-cases with a box representing the "subject", i.e. the system under consideration.
There's no special magic about it, UML Use Case describes a case and can have more than one user.
Maybe just moving the shared Use Cases next.
But, since Use Case diagrams support User Inheritance as if they were classes, maybe adding a generic abstract superclass alike GenericUser with the shared Use Cases, and subclass alike User and Admin with their own specific Use Cases would be useful.
I've never made a use-case diagram before so I'm wondering if mine is correct or not.
In short
This is an (almost) valid use-case diagram. But this does not make make them good use-cases. But what matters in the end is if it is useful to you.
More details
Is it formally correct according to UML?
UML is value-agnostic and defines UC on page 637 of the specs (highlight by me):
A UseCase is a kind of BehavioredClassifier that represents a
declaration of a set of offered Behaviors. Each UseCase specifies some
behavior that a subject can perform in collaboration with one or more
Actors. UseCases define the offered Behaviors of the subject without
reference to its internal structure. These Behaviors, involving
interactions between the Actors and the subject, may result in changes
to the state of the subject and communications with its environment.
Let's check the validity of your UC in view of this definition:
Start game, move paddle, restart game, and exit game are behaviors that the game (subject) offers in collaboration with the player (actor). These are valid UC according to UML.
Ball falls, hit all bricks, hit brick, and display score are behaviors that are more questionable: they do not require a collaboration or an interaction with the player. You could nevertheless argue that these make sense only if the user observe these behaviors, so there is an interaction with the player. So it could be claimed that these are also valid UC in regard of the UML definition.
Add score seems to be a purely internal behavior that is done without the user and not even observed by the user. This would not be a valid UC. However labels might be misleading: if Display score would mean the final game-over score and Add score would mean an update of the score on the screen, it could again be argued that it's a valid UC.
The use of extension (optional) and inclusion (systematic) seem also correct.
Is it a good UC?
While UML is value-agnostic, many authors define a use-case in a more ambitiuous way. In particular Ivar Jacobson, the inventor of the Use case defines it as:
A use case is all the ways of using a system to achieve a particular
goal for a particular user. Taken together the set of all the use
cases gives you all of the useful ways to use the system, and
illustrates the value that it will provide.
According to this definition, there is only one single use case here:
Play a game : this is the goal of the user that brings him/her value.
All the other elements are only ways of using the system to achieve this goal. So they belong to the single use-case. A approach would be to represent them as detail of the use-case description:
One suitable way would be to show these in terms of intent in an essential use-case. This approach was invented by Constantine and Lockwood in 1999. It is used centered and leaves full flexibility about the sequence of actions in the user interface.
Another modern way is the Use-Case 2.0, invented by Ivar Jacobson in 2011. These detailes would be shown as use-case slices, in a very similar way than user-stories.
Edit:
Final outcome based on suggestion given by #qwerty_so
This is my use case diagram for View Repository in Source Code Management System.
This system is part of Project Management System.
The system is similar to GitHub, user can select project.
And it will display a list of repository for the project.
User can click a repository to view its details such as file tree and repository information.
Finally, user also can click the file in the tree to view its content.
Is my use of use case generalization correct?
Below use case is the previous version, I learnt that using use case diagram to model process is incorrect (Seidl et al., 2015, p. 37).
Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML # Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
Well, let me just ask a question: can you abstract added value? The only case where that is true is called franchise. So what you did is to introduce a new abstract bubble to connected three concrete use cases with your actor rather than connecting the concrete bubbles directly. What for? Where is the added value for "View repository"?
For the abstract actor it's similar. There is no need to make User abstract since it's already abstract. All actors denote roles, not real things. You can just leave that abstract keyword away and it would not change any semantics.
What often happens (and you are on that way) is that people start functional decomposition rather than synthesizing use cases. Use cases are about added value a system under consideration delivers to its actors. That's just it. Just present these added values. I know it's difficult for techies, but stick to that.
As always I recommend to read Bittner/Spence about use cases.
in my opinion, one use case is one scenario. since we have to make a scenario for every use case model drawn in the diagram, so one use case must have specific pre-condition and specific post-condition but only have one main or basic flow. Use case might have few alternative flows, that are illustrated in extends relationship. while include relationship is used to avoid repetition in several scenarios in main/basic flow of several use cases.
I drawing use case diagram for my club, but i not sure this is the correct way to say administrator can do anything and member only can view profile, update data only the data itself
I build diagram with gliffy, this is my diagram and json data (this is just another representation of the picture below).
In principle your drawing is ok. What is definitely wrong is CRUD. This is not a use case. The same goes for Search. A use case must have substantive and verb at least. It may have an object as well.
Another thing is <<include>> relation. Avoid it! What you're trying here is a functional decomposition. Use cases are synthesized. When it comes to a functional decomposition in the class design you may introduce a general package for searching or CRUD.
There are various approaches on how to draw UCs. I prefer to bind them to Business processes rather than actors, since actor is mostly just any user of the system with some access rights assigned.
In this case I agree with #Thomas Kilian that draw use cases like CRUD or Update member data is not very useful. In use case diagram you are modelling interface of your system - buttons available for the outside world (actors) to press. Update member data is not visible outside so why to model it in Use Case diagram?
I have a CU that extends another CU, let's say: Add inventory extends Add product, so in one product interface I need to use fields from inventory CU, how I can described this in a CU?
"Extends" means that during the "execution" of the extended UC, execution of the extending UC has been voluntarily invoked by an actor. Each UC is described by several scenarios. Scenario is decribed as an ordered sequence of "steps".
You have to specify so called extension points - steps in the scenario(s) of the extended use case, in which the Actor can invoke the extending UC's execution. It can be a single step or a range...
You can think of the extension point as of a method with parameters, tmplemented in the extending UC and invoked by the extended UC. These parameters could be these fields, you need to "pass" to another interface.
In my projects I always "back up" the my case model with the domain model (class diagram) and use elements of it in the specification of the UCs (preconditions, postconditions, scenarios, extension points).
UPDATE (after the comment)
UML does not define the concrete format of the use case specification, it only defines the concepts and their semantic meaning. A UC can have so called Behavior, can extend another one (or be extended), has Extension points.
The way you define Behavior and Extension points are your own choice.
So, in my example:
Behavior of both UC is defined as a textual sequence of steps, as performed by System or User (alternative is a state machine, activity diagram, even user interface prototype)
Extension Point is defined as a step in the sequence and additionally described by this "method" signature, to illustrate the exchanged information
Remember that UCs show INTERACTIONS beetween the System and the outside world. For them is the System kind of black box. Conceptual model I've used here is therefore NOT a DB or system design, but rather a conceptual, implementation-agnostic view on the entities used by the app. They can even be mapped on 2 different systems on the implementation level!
Relationships between the UCs similarly exist purely on the user-system interaction level of abstraction, and DO NOT BY ANY MEANS reflect some internal system dependencies!
(note added after Gangnus's comment)
(Scenarios and concepts are fully invented for the example sake)
UML standard 2.5, p.680, definition:
An Extend is a relationship from an extending UseCase (the extension)
to an extended UseCase (the extendedCase) that specifies how and when
the behavior defined in the extending UseCase can be inserted into the
behavior defined in the extended UseCase. The extension takes place at
one or more specific extension points defined in the extended UseCase.
Extend is intended to be used when there is some additional behavior
that should be added, possibly conditionally, to the behavior defined
in a UseCase.
I wouldn't call what you are describing an extension. Inventory instance is a container that has Product instances as items. So, Add Inventory is a behaviour that depends on existent products, but not on ways of their adding. So, if you use correct OOP strategy, Add Inventory is absolutely independent on Add Product behaviour. They are both independent behaviours.
Yes, they work on structures, that are dependent and associated, but structures mostly are described in other diagrams. So, normally, these two behaviours are two different independent UCs.
On the other hand, according to standard, you can mix elements of different diagrams, and if you MUST show that intermediate dependency on UC diagram, you can draw there appropriate classes(Product and Inventory), connected by an association. Your use cases will be connected to these classes by arrow "dependency" - - - - - - >
Notice, that Use Case "add Product" and method "addProduct" in some class are absolutely different things. The first is behaviour, described in manual, with participation of user, and the second is a piece of code. The first is the task and the test for the second - that is a realization. So, beware, put classes into Use Cases only if you understand what you are doing VERY WELL, it is not the way for starters. Minimally, reread the Use Cases chapter of the UML standard before. Personally, I would show classes in separate classes diagram here. It is much more easy way.