is the relation between the actor and UseCase allowed to be there? since UseCase2 includes UseCase
Sure it's allowed. Actor can perform UseCasestand-alone. And he can perform UseCase2 including UseCase.
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.
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.
Curerntly, I am documenting all the client's requirements using usecase diagrams and ofcourse I am new in design paradigm. I have a highlevel usecase diagram that contain overall system requirements. And then I have detail level usecase diagram for each usecase define in high level usecase diagram. Now, In detail level diagram, I have included usecases that system trigger itself as well.
e.g. High level usecase - Upload Report file
Detail level usecase for Upload Report file:
Here, in the figure above, the usecase 1.3, 1.4 and 1.5 are trigger from system and this usecases are not directly interacted with user.
So, my question is that should I include these type of system level usecase in the details usecase diagram or should I just include those usecase that only interact with user?
P.S. if what I'm doing above is not valid(the way I am producing usecase diagram as in diagram displayed) then please I would like to have your recommendations.
Well, not really an answer, but an advise. The problem here is that I'd need to dump your design so far and start from scratch. And that's of course not possible. So as a guidance:
Look for added value, not functionality.
Do not use (!) include/extend and just draw simple associations between actor and use case.
For each use case ask yourself: is that added value? Only if the answer is yes, then add the bubble.
Name each use case with verb/subject (and eventually an object)
Use only the main actor and leave away any secondary actors in your diagrams.
If your UC diagrams start resembling spider webs your design is likely broken.
There is no absolute number, but you end usually with a handful of actors and a few dozen of UCs.
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.
How I can illustrate Akka actors in UML diagrams? Especially how to illustrate messages passed between actors? Any example will be fine. Thanks.
Be careful, Akka actors and UML actors mean two very different things. For UML, an actor is something (a human or another system) interacting with the system. For Akka, it is an active object.
So, you can use either, a sequence diagram if you want to illustrate the interaction during the time, or communication diagram if you need only to illustrate messages order.
Aka Actors are self-contained entities with their own lifecycle. Akka actors interact by sending each other messages.
Replace "Akka Actors" with "Objects" in the above statement and you have a pretty good description of the OO model underpinning UML. So you can use Class Diagrams, State Diagrams, Sequence Diagrams etc. to model Actor-based systems.
You could make various refinements depending on your needs. For example, each class that represents an actor is <<active>>. Or you could go further and introduce an <<Actor>> stereotype. Depends on your audience & model purpose.
hth.