So here is the relationship. Actor user is going to borrow from Actor Librarian. librarian uses the system to check if it is available and verify user thru a company id card.
I am aware that we don't put Actor user in the use case model since he will never use the system. It is only the librarian who can access it and since we are also not allowed to put relationship actor to actor.
How am I going to represent that this user interacts directly to the librarian and not the system?
Usually use cases are used to model things in the Platform Independent Model (PIM) aka Logical Model aka Functional Model.
In this case we describe only the behavior that will actually be automated by the system. That means that the interaction between the user and the librarian is out of scope.
The complete picture is drawn in the Computation Independent Model (CIM) aka Contextual Model aka Business Model
In this model the most popular notation these days is not use cases but BPMN.
So the user should play a role in your CIM, but not in the PIM.
You can always extend notations to your needs to convey your idea. E.g. you can do this:
Related
I'm stuck and confuse if I need to identify Database as an Actor since the database is given in the scenario.
I tried first to make it as an actor since based on the scenario, the data needed is from database. I Also tried to create a use case for the whole scenario but not sure if correct.
Here is the link of the scenario: https://justpaste.it/7tljo
The Use Case Diagram I created:
Is the database an actor?
A database should in principle not be an actor in a use-case. Two reasons for that:
A database is in general a component used to implement a system, so it is part of the system's internals (even if it is bought from a third party and installed on a separate server). But actors must be external to the system.
Actors may represent separate systems that interact with the system. But some degree of autonomy is expected since they play a role in the case: either the system actor supports the use-case, like a human actor could do, or it uses the system for achieving its own goals.
More generally, some useful question to ask yourself about candidate system actors: does the business need to know? are users or business stakeholders interested in? is the system actor a system that would be useful if your system wouldn’t exist? could we imagine the same use case with a human user instead of a system actor?
Is the overall diagram ok?
Syntactically, the diagram looks ok. But it methodically break down features/functionality in smaller pieces. This is called functional decomposition: Although it is not forbidden by UML, it leads to complex and unreadable diagrams. This is why the use-case community recommends not to do this, and instead prefer to align use case on user goals.
Hint: if you start to think about workflows, order of operations or user interface components when you design your use-cases (e.g. review contract, approve contract), you probably should consider using an activity diagram instead.
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 am trying to make a use case diagram with the help of my class diagram but the problem is i am here confused that what should i take as actors and what will come and what attributes shall i take and where to use <<extend>> ?
Kindly help. Thank you in advance.
As Thomas pointed out, there is no algorithmic way to go from a class design to a use case. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors).
However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:
1) Identify candidate actors
An actor specifies a role played by a user or any other system that interacts with the subject. Candidates in your diagram are: visitor, admin, and registered user
The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.
2) Identify candidate use cases
A use case defines the interactions of a system and an actor in order to achieve some goal. So let's brainstorm a little bit to find everything that looks like an interaction:
Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user)
Less explicit candidate use cases or interactions: View movie (relation and method of Registered user), update movie (relation), Add movie record (method of admin), Update movie record (method of admin), delete movie record (method of admin), Confirm registration of visitor (inferred from relation), 'Get registered(method of a user),cancel ticket(and method ofRegistered user),Login(method ofRegistered user),Logout(method ofRegistered user),Update Seats available(method ofBook tickets), confirm transaction (method), refund money of cancelled ticket (method)
Implicit/inferred use cases or interactions : create and maintain admin , create a visitor, register and maintain a registered user account, anything else ?
3) Sort out the use cases
Among all the potential use cases and interaction identified, not all should get the use case status. You have then to find which are use cases and which are just interactions part of the same use case. For example:
update movie catalog would be composed of update movie, Add movie record, Update movie record, delete movie record.
Get registered and Confirm registration of visitor are obviously part of the same use case, because the goal is the same: registering a user.
...
I let you as an execise sort out the rest.
4) Review the actors
After having identified meaningful use cases you may want to review your candidate actors:
Some candidate actors might appear to be in fact only objects that are unrelated to users (it's not the case here, but it could be, for example, if you'd have a Movie producer, which is just an info related to a movie but not a user of the system).
Identify obviously missing actors for important use case that you have identified. Here for example, I first thought it was an internet movie business. But the method Update Seats makes obvious that we are talking of a real theater. So who would get the payment from the user, hand out the ticket, reimburse money in relation with the system ? If it's just the online booking system, we are fine. If the cahs desk operator shall use the system as well, then we should add this actor.
Find out relationship between candidate actors. A registered user was first a visitor. Shall we represent both of them in the diagram or not ?
5) Draw your use case diagram
Now you have all the elements, you can make your use case diagram. But you still have to decide on the level of detail you want to represent. Here a proposal:
You can not create a use case from a class design. Only the other way around. Form follows function, not vice versa.
Your class diagram indicates that you are not yet familiar with class modeling. Your classes Book Ticket and Make Payment sound like use cases rather than proper classes. A class is a container of data and functionality working on those data, whereas a use case is a piece of work that an actor performs with the help of the system.
Giving you the help you need might be too broad for this platform. Study introductory texts on UML modeling to get a feeling for what can be expressed by which type of model. And don't feel obliged to use all elements the language offers. There are plenty of use case models that don't need include and extend relations.
Can I business actor use normal use case on use case diagram in UML or maybe he needs business use case?
Also I would appreciate explanation of difference between actor and bussines actor.
UML does not define business actor or business usecase. It is simply Actor and UseCase.
You can created business model of Bank for example using standard Actors and UseCases. But, methodologies can extend UML elements by stereotypes like "business actor" just to say, that model is defined on business level.It is again standard UML usage.
Extending the answer from Vladimir. As answered, there is only use case concept in UML:
UML extension mechanism based on stereotypes permits modeller to give the particurar meaning to general UML concepts.
Use case model base semantic idea is to model interactions between Actors and System. Use cases are units of this interaction. By default the context is a software system, so Actors are system users and the System is a software system. Use cases model usage of software system by actors.
"Business use cases" are one of UML extensions, pretty well known. It defines business actors and business use cases (among other elements).
It shifts the default concret model meaning. System is not more a software system, but rather a Business process. Actor is not a software system user, but rather a business process participant (a worker). A business use case is an interaction between a worker and business process and must not mandatory involve software system.
Back to your question... You should not directly mix business use case elemnts and "normal" use case elements, simply because they live in different apstractions! Thea are interrelated and a business actor can easily give a corresponding system aytor, but they are two sepaarate model concepts.
An example:
A business use case could be "Create an invoice", business actor "sales agent". This business task can be performed different ways, e.g. manually and via system.
In the first case (manual), there is no corresponding system use case, because there is no system involved.
In the second case, we could use a software system to enter the invoice. The actor can be a "Sales Agent", but it's a different entity from the first one (although might refer to the same physical person).
Note that the ampping between two models is not 1-1. They will always be quite different as they focus on different abstractions. SOme actors might overlap, some new can be introduced in the system model, some can exist only on business level.
How would you model in UML the following state of affairs:
A restaurant management system is used by waiters to keep track of
servings to tables. It is also used to keep track of which waiters
serve which tables.
This means that the concept of a waiter is both an actor (as
waiters are users of the system) and an entity object (because the
system keeps track of which waiter serves which tables).
Yet according to the UML a concept can't be both an entity and an
actor because by definition "An actor is an external entity that interacts with the system."
I could always use different names to separate these concepts but that
seems artificial.
What do you think?
The system's entity representing a waiter is not the same as the actual waiter who is an external agent acting on the system.
Either use different names, or put the actor and entity in separate namespaces or models.
Just because waiters use the system does not force you to name that actor as a 'waiter'. Think about other employees who might use the system in the same way, e.g. the host/hostess or a shift manager.
Actors who are using the system are usually fulfilling a role which can shared among different actors. You have to generalize the role the actor is playing. If any employee could participate in that use case, the role might be 'Employee'.
Even if you didn't take that approach, you still have other synonyms to distinguish between the entity and the actor. The actor may be 'waitstaff' and the entity could be 'server'. It is worth the time to come up with good names especially for frequently used terms. And if it comes down to it, forget what UML 'says' about using different names. People have been using bits and peices of UML since it came out, no one's going to shut you down if you decide to reuse a name.
What I would say is UML is trying to give you some good advice that if you are using the same name, it will cause problems later and is also an indication that there is more to the story.