I have loaded an xmi file with an uml diagram. As a result I get an org.eclipse.uml2.uml.Package.
Now I want to programmatically convert it to Ecore (ePackage).
I've already taken a look at the UML2EcoreConverter from org.eclipse.uml2.uml.util.UMLUtil. But it's convert-method is not clear to me.
Instead of going directly for the UML2EcoreConverter, take a look at
org.eclipse.uml2.uml.util.UMLUtil.convertToEcore(Package, Map)
It takes a package and a Map of options and returns the converted EPackage(s). The options map can be fed the options from UMLUtil.UML2EcoreConverter.OPTION__* as keys. Possible values are UMLUtil.OPTION_DISCARD/OPTION_IGNORE/OPTION_PROCESS/OPTION_REPORT. All options default to OPTION__IGNORE.
Most of these options are for processing concepts of UML2 class diagrams that don't map cleanly to Ecore, so you can control how they should be handled.
For extended feature mapping (subset/union, redefines ...), see OPTION_REDEFINING*, OPTION_SUBSETTING*, OPTION__UNION_PROPERTIES, OPTION_DUPLICATE*. It should be okay to set all of these to OPTION_PROCESS.
One option you might want to disable is OPTION__SUPER_CLASS_ORDER. This will reorder the generalizations and interface realizations in alphabetical order, which might cause implementation concerns when you want to inherit a specific super implementation. Another one is OPTION__CAMEL_CASE_NAMES, which will process class and feature names to force a strict camel case scheme. This only makes sense in cases where your UML artifacts don't have valid java names. Just set them to OPTION_IGNORE, or, to see where they would change something, to OPTION_REPORT.
There's also a convertFromEcore(...) for the reverse.
In case you would like to understand the inner workings of UML2EcoreConverter better: It's basically a simple recursive visitor that traverses the UML model, converting each artifact to its Ecore equivalent and doing some cleaning up. It extends UMLSwitch to handle the different metaclasses. So to see for example how a UML Property is converted to an EStructuralFeature, have a look at caseProperty(...)
You can only convert one way from Ecore to UML.
Related
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
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
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.
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.
I am reverse engineering some Java code into a class diagram. Now I'm wondering how to model classes that are from a library that I didn't design. If I'm writing them down as classes, I should maybe also know what interfaces they implement, etc, and put that in the diagram. How far do I go with this? Is it better to write them down as attributes of my own classes?
Include whatever classes and interfaces your code uses in the diagram for your code.
Place the elements from the library into a package which represents the library's package.
Use whatever level of detail is sufficient for what the diagram represents.
If you only want to record that your code uses the library, a «uses» relationship to the package representing the library
If you have associations to elements in the library, model the elements you relate to but no detail in them.
If you or extend or implement classes or interfaces, model the attributes and operations of those elements.
If your code relies on a sequence of operations on elements in the library, you may model the operations, or may just use messages which are not directly linked to them, depending what your tool allows.
I found an interesting link which could help: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html
You can reverse your java project to show .java classes and then just drag and drop .class classes coming from the jar to your diagram. You can make a differentiation between them by adding the package name in the class name, or by changing the color of the class etc....