This question already has answers here:
UML Diagrams: Can I use same actor on one diagram couple of times?
(2 answers)
Closed 4 years ago.
Is it allowed in Use Case Diagrams to place the same actor at different places in the Same Use Case Diagram because of overview issues?
I have a lot of Use Cases spread all over the diagram but drawing a line to every Use Case from a single actor that is placed on top of the diagram makes the whole Diagram very very confusing, because a lot of association lines strikethrough some of the Use Cases.
Yes it is allowed, there is no rule saying it is forbidden.
However that could indicate a problem concerning your actors/UCs, or of course your diagram is just too complex and you have to divide it in several.
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 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 6 years ago.
Improve this question
I have a problem in "include" & "extend" relation between my principal use cases.
I`m using IBM Rational harmony-SE in IBM rhapsody tools. The issue is, how to depict the link between them self, in activity or in sequence diagrams?
In rhapsody, when you want to create a sequence diagram of a use cases, you can use Harmony Toolkit that draws automatically do that, but in a generated Sequence diagram, Harmony Toolkit doesn't consider the "include" and "extend" relation between use cases.
How can I solve this?
Disclaimer
There is no definite answer to this question. This is only one of possibilities, however fully conforming UML and working quite well. Moreover it doesn't provide redundancy in models (each UC flow is defined at most once and the included/extending ones are the only referenced).
Activity diagram
On UC Activity Diagram use Action that is a call to included/extending UC Activity (as part of your flow). Depending if it's includes or extends the action will either have to happen for includes (i.e. it'll be on a flow that is always executed or on all alternative flows) or will be possible to use either a flow containing it or not for extends (i.e. it will be on only some but not all of alternative flows).
Sequence diagram
On UC Sequence Diagram use Interaction Use block (ref), referencing the included/extending UC Sequence Diagram. Like for Activity Diagram it will either have to happen for includes or be on only some of Combined Fragment sections allowing to pass the whole sequence either including or omitting the referenced part for extends.
Note about automated generation
I don't think there is any diagram generation tool that will automatically support inclusion/extension on Activity Diagram or Sequence Diagram of a UC and there are many reasons for that. You'll have to draw diagrams yourself or correct the automatically generated ones accordingly.
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 8 years ago.
Improve this question
How to model logic of complex operations? For example save methods for root entities where state, versions and various atributes should be handled according to some logic. DTOs and entities exist.
I was thinking about sequence diagram, activity diagram, natural language and some abstract code.
I think sequence diagram is not appropriate because it's more likely for modeling of an interaction.
Activity diagram seems to me too clumsy and I don't know where to put instructions like assignments of attributes. It doesn't look right in a note or description of an activity.
Natural language is ambiguous and there is little information in large volume.
Mayby abstract code could be the right choice. Or its combination with natural language. Is there any recommended form? I don't want to write Java code.
If you mean - complex algorithms, they are probably best modelled by activity diagrams. Since UML 2.0 they have actions for practically all kind of operations (including assignements). That's not the problem.
I agree though that in some cases it would maybe better to use some more informal approach. Activity diagrams are very slow to draw and to layout and the added value is questionable (if no automation is used later on). Regarding the statement that they are "clumsy" - you can always overcome this problem by a nice structuring and hierarchical breaking your model in several levels (as single activities can contain whole diagram inside them).
Maybe a mix would do the work - outline the main steps of the algorithm, maybe main decisions, loops, invocations, whatever is importang for you. Later add detailed description of those single activitis: using pseudo-code, natural language or even another embedded diagram (states, activities).
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 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 5 years ago.
Improve this question
I know about use case diagrams. But is there something called a use case relationship diagram? How is it different?
A use case diagram contains one use case. In RUP, there's a use case domain model that displays the relationship between the different use cases. In a use case, you can also include and extend other use cases, which also displays a certain relationship between use cases.
RUP stands for Rational Unified Process, it's a widely used development process, especially in a bit more formal organisations. It makes heavy use of UML diagrams. http://nl.wikipedia.org/wiki/Rational_Unified_Process
You must be thinking of Use Case relationships. Quoting wikipedia:
Use Case Relationships
Three relationships among use cases
are used often in practice.
Include
In one form of interaction, a given
use case may include another. "Include
is a Directed Relationship between two
use cases, implying that the behavior
of the included use case is inserted
into the behavior of the including use
case"1.
The first use case often depends on
the outcome of the included use case.
This is useful for extracting truly
common behaviors from multiple use
cases into a single description. The
notation is a dashed arrow from the
including to the included use case,
with the label "«include»". This usage
resembles a macro expansion where the
included use case behavior is placed
inline in the base use case behavior.
There are no parameters or return
values. To specify the location in a
flow of events in which the base use
case includes the behavior of another,
you simply write include followed by
the name of use case you want to
include, as in the following flow for
track order.
Extend
In another form of interaction, a
given use case (the extension) may
extend another. This relationship
indicates that the behavior of the
extension use case may be inserted in
the extended use case under some
conditions1. The notation is a
dashed arrow from the extension to the
extended use case, with the label
"«extend»". Notes or constraints may
be associated with this relationship
to illustrate the conditions under
which this behaviour will be executed.
Modelers use the «extend» relationship
to indicate use cases that are
"optional" to the base use case.
Depending on the modeler's approach
"optional" may mean "potentially not
executed with the base use case" or it
may mean "not required to achieve the
base use case goal."
Here's more information about showing relationships between use cases: UML Use Case Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409427%28VS.100%29.aspx
Include: An including use case calls or invokes the included one. Inclusion is used to show how
a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend: An extending use case adds goals and steps to the extended use case. The extensions
operate only under certain conditions. The extended use case is at the arrowhead end.
Include and Extend relationships on a use case diagram http://i.msdn.microsoft.com/Dd409427.UML_UCOvStructure(en-us,VS.100).png