How to inherit attributes in class/block diagram using Eclipse Papyrus? - eclipse

I'm creating a very simple class diagram using the Eclipse Papyrus but I'm not able to represent instances correctly.
First of all, I'm using the SysML 1.6 profile, so my classes are actually represented in a Block Diagram instead of classes, but I believe that this does not change anything in my problem.
After creating a simple class/block in my block definition diagram (bdd) I defined some attributes for my block like the example below:
When I tried to create some instances of my block ("parts" in SysML naming convention) using an "Instance Specification" I'm not able to inherit these attributes and fill them with actual information like the "name" and "quantity" in this example.
It's possible to see that my classifier is correctly set as "My component".
The Papyrus documentation for the Object diagram is clear and says that these Instance Specification should include my attributes so I don't know what I'm doing wrong.
I've tried since now:
Create instances in the same block diagram (bdd);
Create instances in another dedicated diagram of the type internal block definition (ibd);
Use the Papyrus context menu to show/hide all my compartments. Any of them works to show my attributes.
Apparently, the same problem occurs without any SysML profile and using pure UML like this question here (from 2016!!)
Papyrus version: 6.1.0

Related

Generate code from Use Case Diagram creates lots of empty classes

In a Papyrus Model, I clicked the Use Case Diagram (which is quite simple - contains about 5 use-cases), and selected "Designer -> Generate Java Code".
In response, I got hundreds of new packages, each of which contains hundreds of empty classes, with strange names such as "Aaixixnrpr", "Aclywqwwlr", etc...
What is happening?!
Papyrus SW designer does not have a particular code generation support for "use case" elements, i.e. it will treat an Actor or a Use Case just as a UML class. This means that it will create an empty Java class, unless you add operations/opaque behaviors.
But the Java code generator should not create classes for elements that are not in the model. Can you please double check via the model explorer that elements such as "Aaixixnrpr" do not exist in the model?
Which version are you using? (I recommend to use version 1.0.5 from this update site on an Eclipse oxygen). Btw, I also recommend to use the Papyrus forum for questions like this.

Enterprise Architect: Change diagram type (MetaType) by script

i have to change the diagram type of a lot of diagrams within my Enterprise Architect model. The change can be made manually using following option (that works as expected):
Select diagram - Diagram - Advanced - Change Type...
As I have to change a lot of diagrams I have created a script which searches for all concerned diagrams and change the type automatically. I wrote already a lot of JScript EA scripts for changing some modeling elements. Unfortunately, this feature seems not be available over the scripting interface.
I have to change the "MetaType" of the the diagram object. But this is read-only (see http://www.sparxsystems.com/enterprise_architect_user_guide/12/automation_and_scripting/diagram2.html). Therefore, I got an error.
var currentDiagram as EA.Diagram
currentDiagram = theDiagram
currentDiagram.MetaType = MY_DIAGRAM_METATYPE // ERROR
In the next step I searched for appropriate functionalities in the Repository interface (http://www.sparxsystems.com/enterprise_architect_user_guide/12/automation_and_scripting/repository3.html) and in the project interface. But I found nothing appropiate.
I am using Enterprise Architect 12.0.1215 and I used JScript.
Has anyone already tried this by script?
Have I missed something?
Is there another approach to achieve the diagram type change by script?
Thanks in advance!
You have to do that in two steps (if you change to different MDG diagram types). E.g. to change a Class diagram to a BPMN2.0::BPEL you first change Diagram_Type from Logical to Analysis. Additionally you need to add MDGDgm=BPMN2.0::BPEL; to StyleEx. In case your old diagram is from another MDG you need to modify the existing MDGDgm attribute in StyleEx.
As Uffe noted, the diagram type in the API is r/o. So if you need to change that you would need to do something like
Repository.Execute("UPDATE t_diagram SET Diagram_Type='Analysis' WHERE Diagram_ID=<theId>")
where <theId> would be the correct diagram ID.

fUML, Papyrus and Basic Operations

We aim to execute fUML specifications written in Papyrus using the fUML reference implementation. This has not been challenging since an UML model containing a single Class diagram and one or more Activity Diagrams can be directly executed by calling the fUML constructor:
new Fuml(File);
However, it is difficult to specify complex behaviors without basic Integer operations. For example, 'equals', 'greater'...
I am aware that there is some library of such functions that can be selected using OpaqueBehaviors. Therefore, my question is: where and how can those such "basic operations" be found?
Sorry, this question was just pointed out to me recently. But, in case you haven't figured it out yet, I do have an answer for you.
The library you are looking for is the Foundational Model Library, which contains packages such as IntegerFunctions, BooleanFunctions, etc. The normative fUML specification includes a standard XMI file for this library (at http://www.omg.org/spec/FUML/20121019/fUML_Library.xmi, for fUML 1.1). However, to use the library in Papyrus, you need an Eclipse .uml version.
If you want, you can convert the normative XMI yourself: Download the file and open it in the Eclipse UML Editor (not Papyrus). Select File > Save As and save the file with a .uml extension (fUML_Library.uml). You should then be able to import this .uml file into Papyrus and reference the functions in it from your activity models. As long as you maintain the normative element IDs from the original XMI file, the reference implementation will know that these are standard library functions, for which it has built-in implementations.
However, there is actually a .uml version of this library already available for Papyrus. It is included with the additional Moka Model Execution component for Papyrus. If you install this component, then the fUML model library becomes available as a "registered library" that you can import into your model and use as above.
Note that Moka also includes an fUML execution engine that you can use to execute activity models directly within Papyrus (see https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution). However, any models created in Papyrus that can be executed with Moka can also be executed externally from Papyrus using the reference implementation, just as you have done before.

Default diagram for Toolbox

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.

Enterprise Architect: How to show packages as groups in a diagram

I'm trying to import some source code into EA, and make packages. In my root class diagram, I want to show each package as a visual grouping and have all classes inside that package in one group.
Can this be done?
Thanks
Not automatically. When you reverse-engineer source code, you have the option of creating either one class diagram in each package, or no diagrams at all.
Doing it manually, you can create a diagram which simply contains the packages: by default, EA lists the contents of each package when the package is placed in a diagram.
You could also drag the classes into the diagram and group them using boundaries or swimlanes. Boundaries are created from the "Common" diagram toolbox, while swimlanes are accessed by right-clicking an empty area of the diagram.
Finally, you can play around with the diagram's properties (also accessed by right-clicking an empty area), specifically the ones concerning namespaces and fully-scoped object names; these affect how EA displays packages and elements in a diagram.