Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - McMannus

Pages: [1] 2 3
Hi guys,

in model-based engineering, a core means for complexity reduction is to use multiple views (EA diagrams) for the same component (EA element) for depicting certain development aspects. For instance in the embedded system domain, there are architectural perspectives containing data flow views or dependency views. For the same component, there also exist quality perspectives such as the failure propagation through the component, which is related to the quality safety.

A typical model structure for this setting is illustrated in the image at the following link: Example

The example contains the architectural component "MyComponent" having 3 views, where the first one contains full details and the other two contain only certain aspects (in this case a subset of the interface). The "FailureModel MyComponent" is a separate element having 3 views, too.

To indicate that the failure propagation model is targeting "MyComponent", EA connectors can be used to formally relate both elements with each other. However, the aspects, which are solely existent through the notion of diagrams, don't offer the possibility for formal relation, although this would be very beneficial for automated consistency validation, i.e. if I add a port to e.g. aspect 1, I only want it to be shown in aspect 1 of the failure view as well, but not in aspect 2.

Is there a way in EA to formally relate or link two diagrams with each other, so that uambiguous programmatical navigation from a diagram of one element to a diagram of another element gets possible? (blue double arrows in the image)

As I'm quite fit in writing add-ins for EA, I know there is always the possibility to keep a custom programmatical map between the diagrams somewhere in the add-in. However, this would not be my first choice, as it means manual maintenance of consistency, when the user deletes or changes diagrams. I'm rather thriving to a native EA solution to the problem and hope I just overlooked a feature in the past 10 years of using EA :-)

Many thanks for your help.


Hi all,

I'm currently having a customer from Japan using the Japanese edition of EA. I wonder, if the different language and in particular the different characters might brake something in our add-ins. I mainly think about plain SQL query interpretation going through Rep.SQLQuery() and Rep.Execute().

Did someone of you guys experience problems with that?

Many thanks!

Hi guys,

I'm modeling and analyzing component architectures with a custom profile + add-in. The syntax and semantics are pretty close to SysML and therefore I'd like to have an arbitrary number of diagrams (like Internal Block Diagrams) per component. As far as I understand, EA's SysML extension derives the association of a diagram to a block only through the implicit containment in the project browser, i.e. when I move the diagram somewhere different in the model, the "formal" relation gets lost.

This is exactly the problem I'm trying to solve. The possibilities I thought about are:
1. Introduce a reference list tagged value to the component that is manually maintained in the add-in.
2. If a list of associated diagrams should be retrieved, search through the diagram elements of existing diagrams and take the ones, where the component is used largest element containing its realization.

In the past, we used Option 1 in similar use cases, but it proved to be a pain in the ass to maintain tagged value lists of GUIDs manually during deletion and creation. In addition, reuse model parts in different projects is pretty hard, because the GUIDs get outdated quickly in that case.
Option 2 is again implicit and not very robust.

Does anyone of you have a better idea, how this could be solved? The ideal solution would be a connector between an element and a diagram, but that is not possible as far as i know.

Thanks for any insight!

Hi guys,

I have defined several relation stereotypes in our profiles that serve for traceability and containment. The containment relations aim at specifying a containment structure being independent from the implicit containment existent through the project browser. The driver for this decision was EA's automatic model movement of elements to other parents based on diagram movement.

When elements are created from the toolbox or programmatically, the relations are automatically created. As we know, a connector is shown by default, if both source and target element appear together in a diagram. This clutters diagrams a lot for my specific use case, therefore I'd like to hide these connectors by default. My approach for doing so was to hide the diagram links in code directly after I put the elements and the connector in the diagram programmatically.

The problem is that the hiding doesn't have any effect, because the diagram link is apparently not created immediately, when the elements (connected already in the model) are put in the diagram.

I wonder if it's possible to hide certain stereotyped connectors through the profile definition directly.

I didn't find anything in the docs w.r.t such a feature. If this is not possible, I have to solve that programmatically somehow.

In this case: Did someone face a similar issue in the past that diagram links only appear delayed in t_diagramlinks and probably has a solution for this issue?

Another option, we used for similar things in the past was to use refGUID tagged values referencing the related elements. However, I remember, they had to be maintained manually (i.e. potential inconsistencies because of deletions of referenced elements) and therefore we discarded this approach back then.

Thanks for your help, guys :-)


Bugs and Issues / Model Root Package API inconsistency
« on: August 18, 2016, 11:37:04 pm »
Hi guys,

I'm currently developing with EA 12.1 Build 1229.

The repository context item getter methods are somehow inconsistent for model root packages as can be seen in the following pictures.

For the "Model" root package:

For the "Bugs" normal package:

As can be seen, the context item types differ in the first case.

The million-dollar question: Is this a bug or a feature with a well-thought reason behind?

Thanks for enlightenment!

Hi guys,

because not everybody is reading the community resources plus we have a neat search in this forum, I'd like to link my article about diffing release changes here as well:


Hi guys,

today I played around with the EA13 beta and found the new Diagram.FilterElements property interesting from its advertisement in the API docs.
However, I don't quite understand the effect of this feature.

What I thought, this feature is doing: I'm currently applying a diagram filter to a diagram, where everything is greyed out. By adding a comma-separated list of element IDs to the property, exactly these elements are not greyed out anymore.
Could of course also be vice versa, but nothing happened in my case :-(

May someone bring light in the dark?


General Board / Memo tagged values in shapescripts
« on: September 09, 2015, 09:28:47 pm »
Hi guys,

is there any way to display memo tagged values correctly within element shapescripts?

Code: [Select]
unfortunately only prints "<memo>" and there is no way to access the tag's notes by using shapescript attributes.

Performing an add-in call to get the notes is incredibly slow for a medium number of elements per diagram, so this is also not an option.

Any ideas?

General Board / Pure black as background color of stereotypes
« on: September 17, 2015, 06:17:25 pm »
Hi guys,

I just tried in vain to set the background color of a stereotype extending the "Provided Interface" meta-class to pure black RGB=(0,0,0).
I tried both the default appearance approach as well as using the following Shapescript with no success.

Code: [Select]

Interestingly, the stereotype in the output profile has the bgcolor attribute set to -2 instead of 0.

I solved the problem by using RGB=(1,1,1) which is of course still dark enough but it's not the proper solution, why I believe this was not intended by Sparx  :)

General Board / Synchronize secondary stereotypes
« on: August 29, 2013, 09:29:54 pm »
Version 7.0 - Released (Build 813) - Extended Synch Tagged Values and Constraints command to synchronize secondary stereotypes.

The situation: I have some stereotypes in a toolbox which can be dragged in a diagram. Optionally, more stereotypes existing in my profile (but not in the toolbox) are added to the diagram elements later. If those optional stereotypes change in the profile, I don't see any way to synchronize them in my existing projects. Since they aren't available in the toolbox, the approach right-klick>Synchronize Stereotype doesn't work.

I think it would work if I programmatically delete and reassign the stereotypes, but the quoted release note seems to me like there is a built in solution for that task, because the optional stereotypes are in my opinion exactly these secondary stereotypes.

Thanks for help!

General Board / Multiplicity on Tagged Values
« on: August 12, 2013, 09:05:14 pm »
Hi all,

I have just added an attribute to a stereotype:
+ result : double [0..*]
As I found in the help, this is treated internally as tagged value. Additionally, I understand this attribute as an array of doubles. When it comes to fill in this attribute (by hand or by addin) I just don't know how to perform the task of adding values to it.
Actually the ordinary approach through the TaggedValue.Value field is not appropriate since it is a string.
So this boils down to the questions:

1) Does EA in any sense care about the datatype that is assigned to the tagged value (maybe by assigning the doubles in a particular way, e.g. a semicolon separated list) or is it up to me to organize the TaggedValue string in a way fitting to my needs?

2) Which consequences does it have to set the multiplicity field for tagged values?

General Board / Dependent Tagged Values
« on: August 08, 2013, 08:59:13 am »
Hi all,

I have the following problem: Stereotype A has a tagged value, which is an enumeration with three entries. Based on the user selection of this tagged value additional stereotypes should be assigned to the element so that there will be more detailed tagged value fields to fill out dependent on the first selection.

Is this possible in EA and if yes, how can I react on the selection within an addin?

Thanks in advance!

General Board / Hide { from <packagename>} label
« on: July 24, 2013, 06:59:48 pm »
Hi all,

I've been searching the EA help for a couple of hours now and I unfortunately did not find the right information.
The question is as easy as this:

How can I hide the { from <packagename>} label when I put a link to a package in another package?

Thanks in advance!

General Board / Shape Script Element border problem
« on: June 12, 2013, 11:42:00 pm »
Hi all,

I just developed the following shape script for a stereotype of metaclass Property:

Code: [Select]
shape main

AndGate.bmp is 30x30 px and the stereotype has properties _sizeX=30 and _sizeY=30.

When I drag the stereotype from my toolbox in a diagram the element is created with the right size and also has a border around it with the right size. The problem arises, when I move the element to another position in the diagram: Suddenly selection border resizes to the original size of Property elements which is a rectangle.

Any ideas?

General Board / Slash before port labels at component instances
« on: June 03, 2013, 08:38:43 pm »
Hi guys,

I'm trying to instantiate a Component as an Instance into a diagram. As usual the Structural Elements window pops up where I can choose the ports of the component to be displayed at the instance. My ports are stereotyped to give them a new color. In the Structural Elements window the port is still correctly stereotyped. As soon as I finish this window, the port
1) is not stereotyped anymore
2) has a label "/ portname" which is not the name specified in properties (this field is empty for the instantiated port)

top: how it is intantiated
bottom: how it should be


1) The slash is to my knowledge sign for a derived property. How can I at least suppress this label and just display the original name instead?
2) Why is the stereotype not inherited from the Component?

Please take into consideration, that I have to do these things automatically at the the instantiation - preferably by profile means, if not possible through addin.

Thanks in advance!

Pages: [1] 2 3