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.
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.
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
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.
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:
I need to model a few business processes in an orchard. These business processes should be enchanced with a system I need to build. In my case these are:
Store process
Sales process
Harvest process
Firstly, I needed to create a Business Use Case diagram. And I have created something like this:
Let me explain this. When we need to harvest, we contact with work agency to get some workers, we give them a job etc...
When we want to sale or store our harvests we need to call transport company to transport our stuff to warehouse or wholesale to sell it.
Ofc, this is so much simplified then it is in real life.
My problem is: becouse system I'm bulding will be used inside a company/orchard there is no external actor in this diagram that USE an usecase. There is noone who can USE use cases. Is it correct? Next step is to create a sequence diagram, and it looks like the Orchard needs to initiate the flow.
Or maybe I should exculde some actors like: Manager. He will initiate flow. But where i can put him in my Business Use Case diagram then?
Can someone give me some advices how this should look like?
An use case and an actor have a 1:1 relation (despite what you might read about secondary actors). The use case describes the added value which its actor receives. If you identify both the actor and the added value you can describe the use case. Else you can't. If you have an actor that does not play a role then it is not an actor. Also forget about "internal" and "external" actors. An actor is always external. The use case sits at the boundary of the system under consideration. And the actor outside.
In case of your manager you should think about the added value. Starting a process sounds simple but it takes a bit to actually do it (or why is his salary so high?). So most likely there is a use case. Often it's just hard to find.
You say you need to create a business use case diagram. Why do you need to? Are you using a particular method, like Rational Unified Process, which you have to follow?
Personally, I think a business use case diagram is not a very good technique for specifying business processes. They can't be used for internal processes, exactly as you point out. Instead, I would use activity diagrams. A business process is a UML 'activity'. This gives a good starting point to further decompose each business process using activity diagrams that model the process flows. I have explained my objections against business use case diagrams in more detail in my paper "Which UML models should we make?. See the paragraph titled "More business analysis".
To capture a high-level view of the Business, sometimes we are talking to non technical individuals to gather the business story via interviews to try to ascertain the functional requirements of the business. The context and system DFD can be a good way to bounce your understanding of the business with the client/ maybe handy when meeting again with the business/customer.
These tasks, may well lead to further discussions about what you can do for the business; i.e. to improve a system they use as part of their business GOAL. For example an improve an accounting program by expanding the functions.