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.
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 wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
It is not included because the "User is paid cash in hand from job" is outside the scope of a project and would not be needed for what you are trying to create.
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.