Can you create an extend relationship between actors?
Can you create an extend relationship between a use case and an actor?
I can't find anything online.
The « extend » relationship is exclusively defined between use-cases. It means that in some cases, the use case will be enriched with additional behavior, depending on sole conditions. Technically speaking, the use-case that is extended shall have some predefined extension points where the behavior will be extented by the extension
This relationship makes no sense between actors. However, actors are classifiers and could hence have a specialization relationship, even if this is nit explicitly stated in the UML specs.
This relation also makes no sense between an actor and a use case. Actors are involved in a use case: what would an extension mean? Philosophically speaking you could think (but not write) that every use-case somehow extend actors in the sense that it allows them to do more and allows for interactions (so behaviors that the actor would exhibit) that would not take place without the use-case. But from an UML modelling perspective this would be wrong.
Related
I read that it is not correct to connect more than one primary actor to a use case so a situation like the image below is not correct
So I used inheritance like this
But the use case has an extended use case that is for only one actor (the second actor does not have that extended use case).
So in my example both manager and HR can browse users but only the manager can block a user.
How can I represent that in the diagram?
Two (or more actors) connected to one use case mean that all actors are involved in this use case. If you want to show, that either one of multiple actors can be involved, a generalization is a good possibility.
The notion of "primary" actor is not specified in UML. Therefore, I talked about actors involved in a use case. Of course, in the description of the use case you will be clear about which actor initiates the use. This will be the primary actor.
All the problems you have with «extend» can be solved by simply omitting it. In my opinion «extend» doesn't contribute to a better model. If you want to say that there is an overlap in the description of several use cases, you could use «include». But actually, you should not worry too much about these relationships. After all, you want to describe what actors are using the system for. Each actor goal is an own use case.
I'm with Axel: stay away from «extend» unless you know what it's meant for. I would guess that in your case it's legit. So what you can do is to just add a constraint to either the extend relation or to the actors explaining the restriction. Simply show it as a note with the constraint { in curly brackts}.
Otherwise there is a convention to put primary actors (the one that triggers the UC) to the left and involved actors to the right. Your approach with generalization is just fine. An actor represents role (like in a screenplay). And identifying those roles is an essential part during UC synthesis.
As always I recommend to read Bittner/Spence about use case modeling.
This notion of "primary" actor is not in the latest (2.5.1) version of the UML Specification. You just associate the right actor/s (Manager, HR or both) to each of your use cases without using generalization (inheritance).
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'm working on a high-level Use Case Diagram for a business system and want to express a relationship between 2 separate Use Cases, as follows:
Actor1 performs UseCase1
Actor2 performs UseCase2
But the results of UseCase2 are in someway affected by UseCase1.
Is it correct to represent this relationship as a dependency,
UseCase2 ---> UseCase1?
There is nothing in the norm about that, so it is not possible to understand the role of the dependency looking at your diagram.
It is very common for an UC to affect the system so to have consequences on other UCs execution, and we don't try to show that (look at How to draw a use case diagram when an actor can change the other actor's use cases?
Of course if you really want you can add a profile&stereotype for instance <<affect>> and use it for your dependency, with associated explanations. But if you start to do that you will have a lot the dependencies <<affect>> in your diagrams and they will be unreadable.
The right way is to not only do diagrams but also to add textual descriptions explaining the goal/effects of each UC (and of course actors) more possible pre/post conditions etc
hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper.
But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part?
You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in #Amir's example International Student inherits from Student.
I'd simply up-vote the latter example but it has <<include>>/<<extend>> which is no favorable with use case synthesis. Moreover it uses a generalization which is very bad practice with UCs since a UC represent an individual added value and inheritance from added value does not make sense (unlike in a class context).
I don't understood your language (In your use-cases). Generally most of time we have some common feature so You can use inheritance in UML diagram. For example if you have different kinds of students (or Actors) that have some common feature you can do something like below picture:
I think there is too many of use cases. I had the same problem. Try using CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Also, you can divide your diagram into few use case diagrams for each actor. Or put all actors on the one side of the diagram and use cases on other. Hope this helps.
I completely agree with the given suggestions (CRUD, inheritance and responsibility by roles) and I additionally recommend not to try to create an overview about the whole universe. Instead, try to separate your use cases into groups based on similarities, differences etc. and explain your modeling on smaller pieces.
Avoid too complex structures and mutual/cyclic dependencies - they are almost always a sign of poor design. Remember, you have to implement and test every connection in your diagram somehow. Less connections, less effort, less errors.
I discuss with my friend our project and we are in a way to draw the sequence diagram ( UML 2).
He told me that the sequence diagram is drawn by the use case. It means that for each use case we should draw a Sequence Diagram.
Is it correct ?
Thank you for any suggestion.
Well, taken as dogma it is not correct. A sequence diagram (SD) shows the behavior of objects in the way they interchange messages (and also if needed their lifetime and some minor additional information). You "can" also use a sequence diagram to describe scenarios in use cases. But simply speaking, a SD is more technically oriented (class design/programmers) rather than business (business design/stakeholders). To visualize a use case scenario you're better off using activity diagrams (AD). And even better if you dive into BPMN (which brings ADs to a new level).
It is possible though, to convert ADs to SDs and vice versa without information loss (if you forget about the afore mentioned bits and pieces).
Now another point: you will not necessarily need a diagram for each use case. I found that often use cases are more easily (and even clearly) described in a textual way (see Cockburn or Bittner/Spence) rather than diagrammatically. Especially if you have UC scenarios that are very linear in their single actions. So you can leave out the AD for those and just fall back to simple text. You should further avoid describing UC scenarios in both ways (i.e. text and diagram) as this introduces unwanted redundancy (means you would need to maintain always both when changes happen; and they happen often; and people are lazy -> so which one holds the truth: text or diagram?).
Generally, as Thomas points out, use case detail is set forth in an activity diagram. As he also mentions, a use case scenario would use a sequence diagram, when necessary. A use case scenario is a single path through a use case.
Sequence diagrams aren't good at diagramming multiple simultaneous behaviors and multiple decision points, and use cases generally have both of these features in their behavior. Activity diagrams do these things very well. A single path through a use case, by definition, doesn't have simultaneous behaviors and decision points, so a sequence diagram is more appropriate.
Googling "use case scenario sequence diagram" gives a number of links that explain the use of sequence diagrams for use case scenarios in detail, of which this is an example.
UseCase is declaration of behavior (service or usefull behavior) of system which is executed by system with collaboration (interaction) with system's actors.
Any type of diagram defined in UML could by used to describe behavior on any level of abstraction. All of diagrams could be also used to describe both business or technical aspects of system.
UseCase is declaration of behavior, it means that UseCase does not define behavior at all. UML does not define scenarios of UseCase ,scenarios are usually defined in methodology not in UML.
If you need to describe behavior of system in context of UseCase you can use some of behavior diagrams defined in UML for each UseCase.