I am trying to draw a part decomposition diagram with EA10. It should look like below.
But I couldn't find how. Is this UML diagram ever supported by EA?
Found it. I need to activate the "More tools..." -> "Composite" first. And choose "Port".
BTW, this is really a bad user experience.
You're doing it wrong. Sorry, but there's no kinder way to say it. :)
If the lifeline (:Class) is associated with a classifier (Class) which has properly defined ports (as it should be), then the following applies:
If you create the lifeline by dropping the classifier onto the sequence diagram, you get the option of displaying the ports (aka "structural elements") immediately.
Regardless of how the lifeline was created, you can right-click it and select "Structural Elements" which allows you to select the ports from the classifier (which may have been added since the lifeline was created).
If you want to create ports under a lifeline which has no classifier, you can do that too. Simply right-click and select "Structural Elements". The dialog allows you to create new ports.
The :Class lifeline presumably gets its type information from a Class element, so the first thing you need to do is find the Class element and give it two ports. Once you have done that, you can right-click the lifeline, select the Embedded Elements dialog and include the ports on the lifeline. (The Embedded Elements dialog may have been renamed Structural Elements in recent versions).
Related
From the diagram on page 570 of the UML spec I concluded that a Lifeline should have the events property, holding an OrderedSet(OcurrenceSpecification). Unfortunately it is not there, at least in the QVTo implementation that I use.
All I have is the coveredBy property, serving me with an (unordered) Set(InteractionFragment). Since my transformation relies on the correct order of MessageOcurrenceSpecification I somehow need to implement myself what I expected to be implemented by the missing events property.
This is what I have so far:
helper Lifeline::getEvents (): OrderedSet(OccurrenceSpecification) {
return self.coveredBy->selectByKind(OccurrenceSpecification)->sortedBy(true);
}
Obviously sortedBy(true) does not get me far, but I don't know any further. Who can help?
All I could find so far were other people struggling with the same issue years ago, but no solution:
https://www.eclipse.org/forums/index.php/m/1049555/
https://www.eclipse.org/forums/index.php/m/1050025/
https://www.eclipse.org/forums/index.php/m/1095764/
Based on the answer by Vincent combined with input from a colleague of mine I came up with the following solution for QVTo:
-- -----------------------------------------------------------------------------
-- Polyfill for the missing Lifeline::events property
query Lifeline::getEvents (): OrderedSet(OccurrenceSpecification) {
return self.interaction.fragment
->selectByKind(OccurrenceSpecification)
->select(os: OccurrenceSpecification | os.covered->includes(self))
->asOrderedSet();
}
I don't know if it is possible, using directly coveredBy to get an ordered collection. As coveredBy is unordered, if you access it directly by the feature, you will have an unpredictible order and if you try to access it using the eGet(...) stuff, the same result will occur.
However, if I understood correctly, there is a "trick" that could work.
It relies on the assumption that each OccurrenceSpecification instance you need is held by the same Interaction that contains the Lifeline and uses the way EMF stores contained elements. Actually, each contained element is always kind of 'ordered' relatively to its parent (and for each collection so EMF can find elements back when XMI references are expressed using the element position in collections). So, the idea would be to access all the elements contained by the Interaction that owns the lifeline and filter the ones that are contained in coveredBy.
Expression with Acceleo
This is easy to write in MTL/Acceleo. In know you don't use it, but it illustrates what the expression does:
# In Acceleo:
# 'self' is the lifeline instance
self.interaction.eAllContents(OccurrenceSpecification)->select(e | self.coveredBy->includes(e))->asOrderedSet()
with self.interaction we retrieve the Interaction, then we get all the contained elements with eAllContents(...) and we filter the ones that are in the self.coveredBy collection.
But it is way less intuitive in QVT as eAllContents(...) does not exist. Instead you have to gain access to eContents() which is defined on EObject and returns an EList which is transtyped to a Sequence (in QVT,eAllContents() returns a ETreeIterator which is not transtyped by the QVT engine).
So, how to gain access to eContents() in the helper? There is two solutions:
Solution 1: Using the emf.tools library
The emf.tools library give you the ability to use asEObject() which casts your object in a pure EObject and give you more methods to access to (as eClass() for example...etc).
import emf.tools; -- we import the EMF tools library
modeltype UML ...; -- all your metamodel imports and stuffs
...
helper Lifeline::getEvents (): OrderedSet(OccurrenceSpecification) {
return self.interaction.asEObject().eContents()[OccurrenceSpecification]->select(e | self.coveredBy->includes(e))->asOrderedSet();
}
Solution 2: Using oclAstype(...)
If for some reason emf.tools cannot be accessed, you can still cast to an EObject using oclAsType(...).
modeltype UML ...; -- all your metamodel imports and stuffs
modeltype ECORE "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore'); -- you also register the Ecore metamodel
...
helper Lifeline::getEvents (): OrderedSet(OccurrenceSpecification) {
return self.interaction.oclAsType(EObject).eContents()[OccurrenceSpecification]->select(e | self.coveredBy->includes(e))->asOrderedSet();
}
Limitation
Ok, let's be honest here, this solution seems to work on the quick tests I performed, but I'm not a 100% sure that you will have all the elements you want as this code relies on the strong assumption that every OccurrenceSpecification you need are in the same Interaction as the Liteline instance. If you are sure that all the coveredBy elements you need are in the Interaction (I think they should be), then, that's not the sexiest solution, but it should do the work.
EDIT>
The solution proposed by hielsnoppe is more eleguant than the one I presented here and should be prefered.
You are correct. The Lifeline::events property is clearly shown on the diagram and appears in derived models such as UML.merged.uml.
Unfortunately Eclipse QVTo uses the Ecore projection of the UML metamodel to UML.ecore where unnavigable opposites are pruned. (A recent UML2Ecore enhancement allows the name to be persisted as an EAnnotation.) However once the true property name "events" has been pruned the implicit property name "OccurrenceSpecification" should work.
All associations are navigable in both directions in OCL, so this loss is a bug. (The new Pivot-based Eclipse OCL goes back to the primary UML model in order to avoid UML2Ecore losses. Once Eclipse QVTo migrates to the Pivot OCL you should see the behavior you expected.)
I have two similar (if not identical) node instances that are appearing differently in a deployment diagram (and anywhere else that I use them).
I may have done some odd things in the past while beating EA into submission.
But, now ... by pulling every lever I can imagine, I can't get them to appear the same (or behave the same). The one on the right is consistent with all the other nodes I have.
The colour is off and the "properties" (maybe they're tags?) showing in the body of the one on the left appear but I can't figure out where to edit / remove them.
I've tried:
Element ... Advanced ... Change type (Node --> Device and back to Node just to try and get it to 'forget' anything it's holding onto)
Remove & re-add stereotype to both the Node type (i.e. type from which instance was made) and the instance itself.
Creating a new instance from the same type, just to see what happens. It creates a node instance more like the one on the right.
Early on in developing this model, I created my own MDG technology. My guess is that the node on the left was created from a type in that MDG, which had some attributes available. It's conceivable to me that Sparx is hanging onto those attributes and not providing a way to edit because of the type was changed.
Any guidance on how to manipulate the under lying data (without creating a new node instance and replacing on all diagrams and re-configuring all relationships)?
Those are different elements. You see that the name (FQN) is different on both. Click each and issue Ctrl-G to locate them in the browser.
The green dot on top makes me think that you use your own MDG which puts the dot on <<SUSE>> stereotyped elements. So the MDG is likely what also makes them appear different depending on tagged values.
Regarding the Version and OS shown in the lower compartment of the left class: those are run states. You can edit them via Context/Features../Run State
For the colour of the element, I think what happened is this ... at some point, I selected (Element Context Menu) --> Appearance --> "Default Appearance" and clicked Reset to defaults. Even with a stereotype applied, this reverts to the "unstereotyped" appearance. I grabbed the RGB values from one the element on the right in the image and set the element on the left's values to those numbers and it's all consistent now.
The main question was the Run State variables, which #(Thomas Killian) addresses in another answer.
I have a custom toolbox with a foo element.
I would like the foo to be green on an class diagram and red on flow chart diagram by default.
Adding more than one stereotype to non- UML type is impossible (as far as I know).
Is it possible to create 2 toolboxes- one for class diagrams and one for flow charts, specifying the default diagram for each toolbox in the profile?
Not quite the way you describe it.
Toolboxes don't specify which diagram they open, it's the other way around: you create a custom diagram type and associate it with a toolbox. Different custom diagrams may use the same custom toolbox.
You can create two custom diagram types, one for class ("Logical") and one for flow chart ("Activity"), but if you're only after getting the same stereotyped element (foo) to display differently in the diagrams, you don't need to.
The solution is to create a shape script for the stereotype, which checks the diagram type and changes the color accordingly. The diagram type can be queried from the shape script using the diagram.type property (for the base UML diagram type), or diagram.mdgtype (for the custom diagram type, if you've defined one). There is no need to create an Add-In, as another answer suggests, at least not in EA 11.
Check the help file under Extending UML Models -- MDG Technology SDK -- Shape Scripts -- Write Scripts -- Display Element/Connector Properties.
A simple script might look like this:
shape main {
if (hasproperty("diagram.type", "Logical")) {
setfillcolor(0, 255, 70);
} else if (hasproperty("diagram.type", "Activity")) {
setfillcolor(255, 87, 87);
}
drawnativeshape();
};
No. You need to have two different stereotypes. The target diagram is independent of the element. If you want the element appear different on the type of the diagram where you use it you need to adapt the shape script so it calls an add-in which detects the diagram type.
Well, writing the last sentence I would not know how to detect the diagram where the element in question is in. Needs investigation. But other than that - no solution I know of.
Edit: Since the add-in just receives the element GUID it has no way to figure out the diagram from where the call is made. Probably worth a feature request. But the time where we saw those realized in the next build are gone (since more than 10 years).
A last though: template packages. I almost never used them. Maybe they offer coloring depending on diagram/element.
Edit2: Last resort EA_OnPostNewDiagramObject. Catch that and you can get all information you need to apply the color.
I am trying to create an editor where the user can either select an existing item or create a new one inline. For example, imagine the typical person-address relationship. I want a form where the user, when editing a person, can either select an address from a set of existing addresses or create a new address without moving to a separate form.
Naively, this seems to require two different editors for the same property. Say I have a Person which has Address getAddress() and setAddress(Address). My PersonEditor class would need to have two sub-editors named address of differing types; one to select an existing person and the another a composite of editors to descend into the Address type and allow editing of its properties.
From reading the documentation on CompositeEditor, it seems like I have to make use of it to dynamically select the sub-editor. However, the documentation isn't detailed enough for me to really understand how I should implement the interface. I've tried looking at how ListEditor and OptionalFieldEditor are implemented for clues, but to avail. ListEditor doesn't seem like a straight fit as my sub-editors edit different paths.
For instance, trying to use CompositeEditor, I'm unclear on what createEditorForTraversal and getPathElement should return in my case.
How do I dynamically attach one of two different types of editors to one property?
I managed to do this in the end. I simply added two editors with the same #Path annotation. I was not expecting the editor framework to allow this, but it seems to work!
I have a custom node type for which I want to have a field that uses a special combobox based on list_text. When one chooses the type list_text it is normally possible to enter a static list of selectable texts, however, I want this list to be dynamic, i.e. based on the results of a db_query. What is the best way to do this using Drupal 7?
A simple example for clarification: A node of this custom type X contains a field that points to another node, so whenever a node of type X is created I want a combobox that contains all other nodes.
(Best solution would be to only display the combobox during node creation, and no longer during edit. But I could also live with it if the combobox was shown during the edit as well.)
I have tried to customize options_select by defining my own data type and implementing hook_options_list accordingly. The combobox was displayed during creation with the correct values, however, I could not save it.. I have no idea what went wrong there, but on the first submit it would change to a different theme, and when I tried again I got an internal server error. Am I on the right track at all with defining a completely new data type for the field? there surely must be a simpler way?
You're right in that you don't need a new datatype. Here's a good tutorial on how to do this. It's not specifically for D7 but I didn't see much that wasn't still applicable. There may be a better way to do it in D7 specifically but I would love to know it too if so :)
The tutorial linked by allegroconmolto sent me on the right way. Thanks for that.
Here's the simpler way of doing it: tutorial
Basically, it is, as I assumed, a common problem and hence a simple solution for it was included in the webform module by now. It provides a hook_webform_select_options_info which can be used to register a callback method. The callback method is then called each time a corresponding option select of a webform is shown, so that you can easily fill it with the results of a dbquery or anything else. Works like a charm and takes next to no time to implement.