How to show «include» and «extend» in activity diagram?
And how can I show types in activity diagram. E.g. Vehicle is of 2 types i.e Bike and Car. So how can I show this in activity diagram?
(This answer is independent of whether or not you should use «include» or «extend».)
A use case can be specified any number of ways. For some examples, you can use natural language, tables, or activity diagrams.
It appears that you would like to specify use cases as activities. In that case, each use case is specified by one activity diagram. The one to one correspondence between a use case and an activity also holds true for included use cases and extending use cases.
The way you would specify an inclusion on a use case's activity diagram is as an action that calls the activity of another use case. It's that simple.
The way you would specify in extension is more complicated. The UML 2.5 specification says:
The specific manner in which the location of an ExtensionPoint is
defined is intentionally unspecified.
An extending use case is one that composes one or more extension points. Each extension point may specify a condition that must hold in the extended use case. When that condition holds, the extending use case's behavior will activate. This extension point does not show up in the activity diagram of the extended use case.
Regarding your question about types, none of us really know what you're asking. Please let me know whether or not this other answer is what you need: Linking activity diagram to entities to be accessed.
Simply speaking: you must no show it if you avoid it. I/E are bad constructs since they lead people to using functional decomposition during use case synthesis.
If, for what reason ever, you have a case with I/E you can place the Activity of the according use case as invocation action in your sequence of actions. That will simply represent the I/E. And depending on whether it's optional/mandatory will be clear by the flow of events.
I leave your type-question out until you clarify that.
Related
I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
Hi, I would like to have the receptionist and the manager to be able to view work type and rates and subsequently update it. However, tech personnel can only view but not update. Is the diagram valid?
I read that extended use-case are initiated by actors that initiated the base case. How should I differentiate that tech personnel can only initiate the base case and not the extended case? Should I not place the extension association? What about included use-case?
Sorry if this question has been asked before.
You should neither «include» nor «extend»
View work type and rates and Edit work type and rates are perfectly valid independent use cases.
In general it is a bad idea to chain use cases together just because you usually do one after the other.
You should not try to model the sequence of activities with use cases. Use your business process analysis for that.
You can use the post- and preconditions to constrain the execution of use case. In fact your Edit use case doesn't really require the View use case in particular to be executed does it?. It probably only needs a work type to be selected. So it can be executed right after any use case that has a postcondition stating that work type is selected.
Which use case does that is irrelevant to the Edit use case, as long as a work type is selected before the use case starts. There might be 10 different use cases that result in a work type being selected.
The «extend» I consider to be simply wrong. Extending use cases are usually incomplete use cases that insert their behavior into a complete use case are a particular extension point defined in the extended use case. The extended use case in does not have any knowledge about the extending use case and does not need or use the results of this behavior.
The few cases I which I found «extend» use cases to be applicable were things like monitoring use case. For example a use case that monitors the number of open tickets in the system and sends an alert to an admin in case a certain threshold is surpassed.
If you still insist on linking the use cases together, for example in case you really mean that you can only edit rates after executing the use case View work type and rates I would do it the other way around. Include the use case View work type and rates from the use case Edit work type and rates, probably as the first step.
Both solutions (separate use cases, or include from Edit to View) solve your issue regarding the rights of different users as it is now clear beyond any doubt who can do what.
I'd model it this way:
Manager and Receptionist have the same roles in this context which is why I used a generalization. Without knowing the domain this seems okay, but it's just a proposal.
The <<extend>> is constrained by {not allowed for actor Tech} which clearly excludes this actor from entering this (optional) use case.
There is no need to also associate Receptionist with Update... since it's an extension of View..., except you want to be able to Update without Viewing first.
N.B. about <<include>>/<<extend>>: They are not meant as chaining use cases. The UML spec states (pp. 638):
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.
and
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common.
Now that <<include>> just looks like a bastard. A use case is about a unique added value. And this uniqueness can be questioned if there were behavioral recurrence in more than one use case. In any case these relations are often just taken as functional decomposition. And that would be plain wrong. From my POV the UML spec would be better without these relations.
In context of the above diagram it represent a pattern where you view something and only then can make it editable. It would well be perfect to have two individual bubbles without <<extend>> where you place a constraint in Update telling { can only be reached after View... }.
I would change extend by include. To update the work, you have to view it. It is mandatory to view it.
In your diagram, Manager and Receptionnist are equivalent, with this schema only, you can define one actor only. Or model that Manager inherits from Receptionnist.
And to avoid mistake, if you do that, you have to be sure that Receptionist and Manager can also activate the view use case without the update. Otherwise some associations have to be remove.
Let's assume that there is a UseCase called "Start Pattern Recognition". But when stating pattern recognition, it's mandatory to either to train a new model or import existing (pre trained) model. One of those option must be performed. I tried to represent that in UML as shown below (I used Includes instead of Extends since it's mandatory to perform either one of this UseCases). But I'm not sure whether it is correct to use "Extension Points" with Include UseCases. Is this correct or Is there any other way to do this?
It isn't correct; there is no analogous concept to extension points for includes in the UML spec. As xmojmr has very correctly stated, you really have your inclusion backwards.
This is easy to do, because it's easy to get caught up thinking about the order that use cases occur in over time. The use case diagram doesn't have anything to do with time; it just states what things a system does, who or what interacts with it and what uses what.
When you are ready to think about the flow of a use case, think about it in terms of an activity diagram. Also, look at the idea of a "use case narrative", which documents the behavior of the use case.
By the way, extension points in a use case diagram are optional.
I'm starting to learn UML and I'm a little confused. I have the following use case diagram:
I'm asking this because I want to draw my diagrams correctly in order to anybody with correct knowledge of UML can understand and not just draw the diagrams in a way that just I understand.
Now for the reason I used Use Case Generalization here is why;
After reading the section 5.3 of the book UML 2 and the unified Process, I think that what I'm trying to do is use case generalization, specially after looking at the example in page 100. This example shows a use case called FindProduct that as stated in the page 101 is an abstract use case.
We read that
the FindBook use case is much more concrete. It specializes the more abstract parent to deal with specific type of product, books. If the parent use case has no flow of events or a flow of events that is incomplete, it is an abstract use case. Abstract use cases are quite common because you can use them for capturing behavior at the highest levels of abstraction. Because abstract use cases have a missing or incomplete flow of events, they can never be executed by the system
And that's what I'm trying to represent in my diagram. I have an abstract use case Turn ON and this use case is never going to be executed as it is. It needs child, or in this case, children to specialize it because the system is going to turn on by IR or by KNOB and never just turn ON, that's abstract.
So the thing here is that I'm not sure about the multiple generalization and If doing this is correct. Or shall I change for example the Turn with IR and Turn with KNOB use cases for Turn ON with IR and Turn ON with KNOW use cases and make these the children of Turn ON and add Turn OFF with IR and Turn OFF with KNOB use cases and make these the children of Turn OFF, and so on?
Thanks!!
About you question: the most common approach I have seen, is to have one activity diagram per use case.
A few points about your use case diagram:
1- I have never seen multiple specialization in use case diagrams. you may want to reconsider that. When use case A (child) specializes use case B (parent) it inherits all the preconditions, post-conditions, main flow and alternative flow steps. I can guess that this features are not the same for your parent use cases (for example turn volume up and turn on); therefore multiple specialization does not makes sense here, to say the least.
2- Use case generalization should be avoided unless it adds real value to your model. It is not very intuitive and makes your diagrams vague.
3- This use case diagram seems to have the tendency to view use cases as classes and generalization as inheritance; which is not correct.
4- You may want to reconsider the level of granularity of your use cases as well; turn on with IR/Knob and turn off with IR/Knob may all be integrated in one reasonable sized use case with some alternative flows. But this is a choice you make as a requirements engineer, anyone may do it differently.
I recommend you take a look at section 5.3 of UML 2 and the Unified Process book which is about use case generalization.
Suggestion:
Let's assume you want to keep separate use cases for turning on and off and focus on one use case (turning on):
1- If the steps for turning on with IR are totally different from turning on with knob, make the turn on use case abstract and do not write any spec (text) or draw any activity diagram for it. Then specialize two use cases called turn on with knob and turn on with IR which are concrete with separate specs and/or activity diagrams.
2- If the steps for turning on with IR are almost the same as turning on with knob except for one step where the user chooses IR or Knob; you could use alternative flows. In this case you can have only one use case with one spec and/or one activity diagram.
Do the same for other three use cases.
I came across a situation where a use case has two options to choose from.
Example: Use case "Process data" has options like "Approve" and "Decline"
If approve, update the inventory.
If decline, file the information.
I know how to represent this in an Activity Diagram but I have no idea of showing it in Use case diagrams.
There are two choices here.
A) You make two use cases instead of one. Approve Data and Decline Data
B) You make one use case Process data. In the main scenario you describe the steps for Approve Data and in the exception or alternate scenario you describe the steps for Decline Data. In this case the difference is not visible on the use case diagram, but that is OK. Use case diagrams are meant to give you an overview of the big chunks of behavior in your application, not of the details.
The choice for alternate or exception scenario depends on your post-condition(s). If the Declinescenario meets the post-condition then it is an alternate, else it is an exception scenario.
The term Data is not very specific. I would prefer something more meaningful then data like Order, Application,...
I can't know for sure without knowing all the details, but option B) is probably the best.
A usecase has a specific goal for a specific actor.
Identify the Actor for the usecase(s).
Identify the Goal of the Actor.
Define the usecase with a strong specific verb, process is weak unspecific verb.
I find the requirements ambiguous, it seems you may be conflating two separate Actors.
See the Uml Style Guide : Usecase
You create two views of the same usecase. In the first view you create Process data with Approve and a second one with Decline. Each view is a different usecase diagram but using the same usecase.
It is important to make a clear differentiation between graphical views and model view. I mean that graphical usecase diagrams should be a view which is extracted from the UML model.
if not then use this link http://msdn.microsoft.com/en-us/library/dd409427.aspx