Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm working now on a big system that consists of many subsystems , each subsystem depends on the other. I wrote a usecase for this system , but I note that I have many processes in my usecase ( more than 40 processes ! ) . it looks like this :
Group subsystem:
add Group.
remove Group.
join to Group.
upload file.
create poll.
remove file.
remove poll.
write post/topic
close post.
edit post.
....
Messages Centers
send message
view inbox
read message.
and so on ..
this is a screenshot, just to know that is a large usecase :)
http://farm2.static.flickr.com/1308/4691773979_4c5a30f26c_b.jpg
each user interacts with these processes .
How can I reduce the number of these processes?
Is it possible to divide the usecase processes into many pages?
I'm not sure of what you meant by dividing it into many pages but you can certainly divide it into multiple use cases, or multiple subsystems... but is it worth it?
Use cases, as far as I know(which isn't much), are used to show clearly what kind of interactions an user can make with a system, or even a system with another system. It is possible to produce a comprehensive use case with only one system having all these options, but it is also possible to do it while separating everything into smaller subsystems.
I would suggest you use whatever you're more comfortable with, as long as whoever need to see that diagram can have a clear idea of how each actors interacts together.
Furthermore, if you're working on uses cases, chances are you've made a package diagram/list before. If you did, you could simply do one use case for each package.
Your terminology isn't quite right.
From the picture, that's not ONE use case.
That's dozens of use cases. Each oval is a separate use case. Each box is a separate system. You're showing 7 systems with 32 use cases.
Read this: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
I don't know what you think a "process" is. Guessing from your picture, each thing you're calling a "process" is a use case. An actor interacts with the system to create something of value.
Since you've got the terminology wrong, it's difficult to say if it's "normal". It is quite common, however, to get the terminology wrong.
It is possible to divide in several pages. You can divide the diagram according to the actors. So you can have one actor and all use cases associated that that actor in one page.
Try to analyze if its necessary to include all the use cases in the diagram, but of course this depends for what and who are you ding this diagram.
You should group your use case. For example create a use case "Manage Group" which would include the 3 use cases:
add Group.
remove Group.
join to Group.
You can then choose the granularity of your view to show details or not.
See other examples here:
http://askuml.com/files/2010/06/yuml-use-case-diagram03.png
http://askuml.com/files/2010/06/yuml-use-case-diagram02.png
taken from http://askuml.com/blog/yuml-use-case/
Related
I just create this diagram can anyone tell me if these 2 pictures are correct or wrong and which one should I use?, can anyone tell which is correct in these 2 pictures.
Both diagrams are ok, except:
the association between an actor and a use case should be straight lines and not directed arrows. These arrows are an obsolete practice.
the subject rectangle should be closed
actors not related to anything are useless and should be removed
The question of whether add and edit should be in the same use case or in distinct ones is up to you to decide:
grouping them has the benefit of simplifying the model. Manage students could be even more generic and is quite common.
keeping them separate may appear more granular but makes sense if there are different actors or if the business needs are very different.
You may read more to make up your mind, googling for CRUD Use case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to write use case diagram for a wireless NIC driver. There is no direct interaction of the user with the driver. How can one write use case diagram for drivers?
The 'user' in a use case is not necessarily a person hitting keys or anything. It is an 'actor' external to the system being described who can interact with the system being described.
Here, such actors could include routers or other bits of hardware that your NIC wants to connect to or that want to connect to it; it includes the hardware and OS the NIC is plugged into which the NIC exchanges signals with; and devices it is connected to and the signals they exchange.
Use cases would include:
The NIC detects available routers....
The NIC receives a request from......
Et cetera, to cover what you want the NIC to do.
Extending the previos 2 answers with a bit more info and an example...
The key aspect of the use case model is its context, or the system scope (depicted with a Boundary element on the diagram itself - see example). Everything that is "inside" the scope is abstracted by a UC and everything from the "outside" is modelled by an actor (human or system). Use cases model the interaction, the dialogue, the exchange of information between the two of them.
I see at least two system actors in your case, a controlled device and a client program. Another possible actor has been added in the following example, to show some eventual periodic communication with the device through the driver:
This is a very nice example on how different UML diagrams play together to show the whole truth. UC diagram focuses on the meaningful interactions between the System and its environment, showing no technical info about it.
In order to do this you need another diagram (here component, but classes are also ok, even both). This diagram is the place to define interfaces, APIs, method signatures, dependencies...
You can of course go a step further and use a sequence/interaction diagram to connect the Use cases with the corresponding components (on my example are only shown the "traces" to clear up which actors are implemented by which components). Something like this:
Note that something called "Data" is sent to the Driver (and the Device). This can further be defined in a class diagram, making a whole new point of view on this system.
It is common practice to put all this info in use case description. Although this approach might even be syntatically correct, the full power of UML is released by separating the concerns in different diagrams, keeping each one as simple and clear as possible, focused on only one concern and clean of others.
In your scenario Actor is system. You can include a system into use case as an actor, if that system is outside of the system you are developing and if it directly interacts with that system you are developing.
You may also need to define boundary of your system, which means its scope and interfaces. For example: you may want to create an actor for Routers. Preferable actions would be how they will interact with the driver of yours, as they are directly interacting with the system you are developing.
Hope this helps.
If you need further explanation with example, please comment below.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
If I use include or extend, will I have to use the same primary actors for those extending or included use cases? (In the screenshot: Could AddProspectiveIngredient have a different primary actor than CreateRecipe? Same question for include)
EDIT: I don't think the question is asked broadly: If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
I agree, as this was one of my first questions on Stackoverflow, that there is some unnecessary boilerplate in the beginning. If that is the case, I can edit my question to keep it open. I am still hoping for someone to stumble upon it and provide me with more knowledge or sources.
If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
Extend means that one Use case is a variation of another one. It is the definition, sorry. So, I am not sure you really meant it, but different variations of activity can be easily conducted by different actors.
As for include, it is not so simple. One behaviour is inserted in another one. It is some variation for generalizations for use cases.
So, if behaviour A includes B, and actor X is connected only to A and actor Y is connected only to B, that means, that Y really makes A, too, only not all of it. X has all behaviour of Y and some additional behaviour. And that means that X is derived from Y, or X is a subclass of Y.
Simply, if you have different not-tied actors for A and B, you have simply mistaken. They ARE tied.
This question already has an answer here:
Have I to use the same actors for those extending or included use cases? [closed]
(1 answer)
Closed 6 years ago.
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
Can extending or included use cases be accessed independently? If I do it as in the screenshot, can AddProspectiveIngredient be used without going through the CreateRecipe use case? Same question for included use cases.
EDIT: I don't think this is a duplicate of this question. In the linked question (1), I ask if I have to use the same actor for extending and included use cases as in the extended or including use case. In this answer (2), however, I merely ask about reuse between use cases.
In (1) it is all about the actor, and I am very satsified with this answer, as I now understand that the primary actor of an extending use case will inevitably be a subclass of the primary actor of the extended use case.
(2) addresses reusability of extending and included use cases, but is not necessarily connected to actors. It is about reusing them in other use cases. So if I have two use case CreateRecipe (a) and AddIngredientToDatabase (b), where (b) extends (a), can I also extend a third use case with (b)? Here I also received my answer, that they can and should be reused.
Maybe the questions seem similar because I created them on the same day with the same example and the answers both mention actors, which make them seem as duplicates. As they are both answered and I am satisfied with both answers, why close the questions as "too broad" or "duplicates"? If it was answered succesfully with different answers, how can it be too broad or a duplicate?
I am also happy to rephrase them slightly to keep them open, if I am told what the core issues. More answers and comments on the topics are still interesting to me.
Can extending or included use cases be accessed independently?
They rather should be. It is a good and correct style. Use case is some activity conducted between one or more actors and system. You should try not to show here some inner operations, that are not connected to users. Nothing invisible to users can be shown here. USER cases, remember?
So, no inner structure here.
You can collect some cases in groups - subsystems. But it is not inner structure, they are not IT systems, they are simply common themes of activities, obvious for users. Such subsystems should get later at least common UI style.
As for logic that could be used by users, it can be shown on other diagrams. Many diagrams can exist on this level - State machines, Activities, Timing. But don't try to show processes on the Use case diagram, too.
So, I don't know how well have you interviewed the client, but you use case diagram looks almost correct. Only the AddProspectiveIngredient Use Case should get its user or more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm begging a new project (oh, how I love the fresh taste of a new project!) and we are just starting to design it. In short: The application is a UI that will enable users to model an execution flow (a Visio like drag & drop interface). So our greatest concern is usability and features that will help the users model fast and clearly the execution flow.
Our established methodology makes extensive use of Use Cases in order to create a harmonious view of the application between the programmers and users. This is a business concern, really: I'd prefer to use an Agile Method with User Stories rather than User Cases, but we need to define a clear scope to sell the product to our clients.
However, Use Cases have a number of flaws, most of which are related to the fact that they include technical details, like UI, etc, as can be seem here. But, since we can't use User Stories and a fully interactive design, I've decided that we compromise: I will be using Essential Use Cases in order to hide those details.
Now I have another problem: it's essential (no pun intended) to have a clear description of UI interaction, so, how should I document it? In other words, how do I specify a application through the use of Essential Use Cases where the UI interaction is vital to it?
I can see some alternatives:
Abandon the use of Use Cases since they don't correctly represent the problem
Do not include interface descriptions in the use case, but create another documentation (Story Boards) and link then to the Essential Use Cases
Include UI interaction description to the Essential Use Cases, since they are part of the business rules in the perspective of the users and the application itself
Getting user feedback with UI prototypes is essential to creating a user interface that your user community will understand and be productive with. The best way to do this IMO is with paper prototyping. Your use cases can drive the initial creation of these prototypes, and the user interaction sessions with your clients can refine the UI design.
If you prefer electronic prototypes, you can use something like PowerPoint to rapidly prototype them.
See also http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html and http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html
First gather information about the users' workflow and goals. This is best done by physically going to see how the users are doing their work today (for example using contextual inquiry). Document those goals as goal-based use cases (see the link below), which contain only the goal - they should not contain any details of how the system will be used, because those details are what we are just starting to design based on the use cases.
Based on the use cases, create a quick paper prototype of the UI, and try step-by-step that how the users would reach their goals using the prototyped system. If the use cases can not be executed well enough with the UI prototype, keep on improving it until all use cases are supported. Show the prototype to the users and use usability testing and other techniques to find out problems with the UI.
When the UI design is good enough (~85% ready - some fine details are best tweaked after implementation), you can document it for example by taking picture sequences of the prototype, which show how the use cases can be executed with the system. But communicating the UI design to the programmers is best done face-to-face, by showing manually how the prototype works and answering their questions. Don't just "throw the documentation over a wall", but follow through to see how it is implemented and test whether the implementation matches what was designed.
See the longer process description at http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf