How do I create an abstract use case in enterprise architect 10?
Edit:
Here is an example:
How do I achieve this in Enterprise Architect?
Stereotyping the use case as "abstract" does not change the font face.
I'm not asking how to change the font manually. I was expecting that if a use case is stereotyped as "abstract" then its title font face would automatically be changed to italic. But that does not seem to be the case.
Go to the properties window (not the dialog that pops up when you double click on the element, the windows default posion is in the lower-left corner).
In the "Advanced" section set "Abstract" to "True".
Regardless of the type of element, "abstractness" is not expressed as a stereotype in EA, so that wouldn't work for classes either. Instead, there is an "abstract" checkbox in the element's Properties dialog. You'll find it on the Details page if you open the dialog for a class.
The same dialog for a use case, however, does not include the "abstract" checkbox. However, the underlying data model allows any element to be abstract, including use cases.
Leaving aside the correctness or otherwise of modelling abstract use cases in favor of answering the actual question, there are two ways to achieve an abstract use case in EA. Both are "proper" in that they result in use cases with the appropriate "abstract" property set, as opposed to making purely cosmetic changes in the font or similar.
Use cases made abstract in either of these ways will be displayed with an italic font automatically, they can be distinguished in searches and generated reports, etc.
Method 1: element properties window
In the Element Properties Window (not the dialog but the one you open in Element menu), you can set the "abstract" property under the Advanced branch.
Method 2: use a script
Here's a VB script snippet which makes a single use case abstract.
if (theElement.Type = "UseCase") then
theElement.Abstract = 1
theElement.Update()
end if
If you place that in a diagram or object browser script you can easily make a use case abstract. You'll probably want to modify it to make it a toggle rather than one-way, but you get the idea.
This can be useful if you've already created a number of concrete use cases and want to make them abstract.
It is possible, but useless, and and style both in UML and OOP
If your client insists on the structure, you can show variations of some behaviour by extends and include stereotypes. And some of the variations can have a note that says, that this variation will be never really realized. This is semantically equivalent to your abstract use case. ...And the uselessness of the thing is obvious, too.
You can set Abstrect property directly, as is shown in a neighbouring answer. But it doesn't add to usefullness.
More reasons not to use "abstract" :
What does being abstract means? It means, that this very structure will be never realized by itself, and will only provide some common features to other, concrete structures. I.e., it is setting the way of REALIZATION, the inner construction of your system. And you should NOT solve problems of realization on UC diagrams, they are merely formal way of setting the task you are solving. You should not mix setting the task and solving it.
In technical way, being abstract is a structural piece of information. Use case diagram is a behavioral diagram. You CAN use structural elements borrowed from other diagrams in it, though. For example, abstract classes. But it is for exceptional use, not standard one. For example, you are solving the task and (alas!) you have already some SW/HW rigidly set due to licenses or politics. It is not good, but it can happen. But use case itself if pure behavioral element and you can't simply say it is abstract.
"abstract" is a word used in some languages, but not in all OOP languages. You shouldn't set the language in the UC diagram.
Use case shows behaviour, and will be realized first rather by interface than by class. And all interfaces already are abstract.
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
I'm wandering whether the following use case diagram is correct because I'm not sure if such notations are possible: something is going from extending use case, and this notation of this transition. I haven't found any information regarding such cases and would be glad if someone could help me.
To express that a (partial or secondary) use case is used only under certain cercumstances and you want to express them explicitly, you can use extension points. An extension points defines explicitly the conditions when the Main use case is extended. In reality, this Feature of uml is Quitte rarely used. Because it adds a high degree of concreteness to the abstrakt Level of use cases.
In your example you are using the wrong kind of relation. You are showing an extend relation, which expressed that a Stereotype can be applied to a meta type. Instead you should use an extends relation, which has a dashed line and on open arrow head.
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've taken the course Object Oriented System and Design at Stockholm University. I had to hand in an extra assignment where I had to create a UML Class Diagram reflecting a web site that sold cars (this is not a thread where I'm asking you to do my homework). This is what I handed in:
The teacher said that "this isn't how you use attributes" and seems reluctant to explaining what I should have done differently. It's all in Swedish but I think that the main points are clear regardless of language.
My question is: How should this have been modeled differently? I have aggregation for some objects, enums because the website had a limited amount of attributes for some classes.
Any help is greatly appreciated.
Kind regards,
Hugo
I see some problems in your diagram:
I believe you have some enumerations in your diagram that are not defined properly. An enumeration should look like this.
You define attributes in addition to aggregation (e.g. the Bil has a aggregation relation to this SäkerhetsTilägg, and additionally defines an attribute säkerhet. You should either use a relation or an attribute, see here.
While we are at this, the multiplicities are somewhat confusing. You say that Bil can have any number of SäkerhetsTilägg, while the attribute säkerhet holds exactly one SäkerhetsTilägg.
Afaik, you have to define the visibility of attributes and methods (like +, - etc).
It looks to me like you've got your Enumerations modeled as Classes. Even though visually an Enumeration looks like a Class with an <> stereotype, it's really a different thing altogether and it has EnumerationLiterals in the compartment when Attributes would be for a Class.
In ArgoUML you can create an Enumeration using the fourth button from the right on the toolbar. It's a dropdown menu which defaults to creating a new Datatype, but if you pull it down and select the green rectangle, it'll create an Enumeration. Create your Enumerations first and they'll be available for you to select as the type for your Attributes.
The final result should look like this: