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.

Messages - robinch

Pages: [1] 2
General Board / value of ea_localid in XML files
« on: January 27, 2016, 04:23:07 am »

Are the ea_localid tagged values actually useful in exported XMI1.1 files?

The reason I want to get rid of those is that they add a lot of irrelevant changes whenever a model is exported to version control. Sometimes we have to look at the XML representation of a model for reasons I'd better not start to discuss here. Because these local IDs always change when a model is imported/exported between different databases, I interpret those IDs as relevant only within a database or EAP file while EA is relying on the GUIDs exclusively to resolve references stored in XML files.

I tried to strip all the <UML:TaggedValue tag="ea_localid" value="xyz"/> lines from a model exported to several XML files using package control and then to reimport the files in a newly created EAP file, it seems to work.

Are my assumptions correct? Can I safely strip those lines from the XML files before recording changes in the version control tool?


Suggestions and Requests / Re: aggregation/containment navigability
« on: November 24, 2015, 08:57:12 pm »
However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Can your body ignore the hand that wrote this sentence?

Or, to put it another way, Paolo are you suggesting that, for instance, if I design a class "polygon" (whole) containing an instance of "std::vector<point>" (part) then instances of my "polygon" are not supposed to navigate to their vector of points but rather I should ask the C++ standard to add a reference to my "polygon" class in their definition of "std::vector<T>"? Does not sound very practical to me...

Suggestions and Requests / Re: aggregation/containment navigability
« on: November 20, 2015, 08:57:29 pm »
KP, Paolo,

Thank you for you explanations. I totally agree on subject of source/target/client/supplier/etc., my apologies for fueling this lengthy discussion about terminology which unfortunately lies a bit off topic. I'll try one more attempt to explain what I am after.

As illustrated in the picture hopefully accessible through the link below, I have created a class Car which has a part of class Engine, represented by a composite relationship between the two classes, with the black diamond at Car end.

Now, looking at the properties of this relationship, in the Role(s) tab, you see that the Navigability property is set to Non-Navigable at the Engine end whereas it is set to Navigable at the Car end, meaning that the resulting links are navigable from the Engine to the Car but not from the Car to the Engine. What I am trying to say is that this is in general wrong for aggregations.

Hope this clarifies the purpose of my initial request. Anyway, many thanks to everyone for your valuable inputs, much appreciated.


Hi Paolo, Geert,

It is now (fairly) common modelling convention that relationships are drawn from the client (origin) end to the supplier (destination) end.  This provides "directionality".  Navigability on the other hand, is about the ability to traverse the relationship to the navigable end.  EA conflates Directionality and Navigability.  However, if you apply the convention above, it doesn't really matter.
Not sure to understand what you mean by "it doesn't really matter". My initial request was to change the default behavior of having navigability towards the end with the diamond because, usually, this end is at the client side. A concrete example would be, say, a C++ application class containing an std::vector<T>. The  diamond would be at the application class end and obviously navigability should go from the application class to the vector<T> rather than the opposite.

For the majority of relationships, the end with a glyph (Arrow, Triangle, Lozenge etc.) is at the supplier end.
This is where I tend to disagree, perhaps because I am missing something, what you are saying stands for simple dependencies (Arrow) and generalizations/realizations (Triangle). For diamonds, it is exactly the opposite, i.e. the diamonds are at the client ends rarther than the supplier ends. Therefore, EA systematically assigning navigability to the target end of relationships is not optimal in my opinion.

I'm pretty sure tree style is not UML compliant for associations. The problem is that you then don't have a place to put your multiplicity/rolename etc.. anymore.
This is different from things like a Generalization or Realization where there are no properties at the relationship end.
I would advise against using it for associations.
Makes a lot of sense, very good advice which I will follow to the letter.


Hi Geert,

I wrote a little script that switches source and target to make sure the composite end is always on the source.

Thanks for the link, I will definitely have a look into it. I am still pondering whether changing the source<->target ends or just inverting the navigability attributes is the best.

Apparently, when using tree style representations, EA always considers the target ends as the tree root and the source ends as the tree leaves (works well with e.g. generalization relationships). However, most of the times we are using tree style representations for aggregation-like relationships, the root is actually at the diamond ends, hence requiring the diamonds to be kept at the target ends.

That was the option I was referring too. I expected it to control the navigability in the aggregations as well.

Ok, thanks. I'll stop searching then  :).

I think you can turn the default navigability on and off in the options.

Thanks Geert, that would be quite useful to us. The only one I found is the tick box "Links->General->Association default = source-->target" and made sure it is not ticked, but aggregation/composition/... relationships still get the inverted navigability. Perhaps there is another option somewhere (EAUI I think it is called here)? I'll have a look.

True, it is possible to create association first and define an end as an aggregation afterwards. However, EA groups the target ends when using tree style representations, so the notion of source & target ends cannot be completely ignored.

My suggestion was more to not assign navigability by default than to find a workaround. Pepole usally use the fastest way to create relationships (quick linker comes first) but they do not always remember to unset the navigability at the target end. And all those links with inverted navigability look very odd in reports.

Yes, it is possible to select the gesture direction but the diamond (or "+ in a circle" in case of a composite relationship) is always set at the target of the relationship and the navigable end is therefore always set at the diamond end of it.

Basically you can choose to draw from target to source or from source to target but it does not change the final result, model-wise.

Suggestions and Requests / aggregation/composition/containment navigability
« on: November 10, 2015, 08:37:10 pm »

By default, EA creates relationships which are navigable from the source to the target. Unfortunately, for aggregation/composition/containment (and perhaps other) relationships, the definition of the source & target elements are the opposite of what we would intuitively expect, e.g. for composition the whole is the target and the part is the source, thereby creating a relationship which is navigable from the part to the composite by default. However, in most cases, a composition defines links which are navigable from the whole to the part.

Instead of having to manually undo the default navigability, I wish EA could either define relationships which by default are navigable from target to source for these cases or even just leave the navigability undefined in both ends.

(Using EA 12.0.1215, same behavior observed in previous versions)

General Board / Re: Sequence Diagrams
« on: July 07, 2014, 09:01:42 pm »
Recursion is shown by the combination of stacked lifeline activation levels and repeated message name(s). You can also embed the recursive call(s) in "opt" or "alt" fragments to specify the recursion invariant.

General Board / RTF reporting ignores << Document >> artifacts
« on: August 29, 2013, 01:22:58 am »

With Enterprise Architect 10.0.1008 Ultimate Edition, I am trying to generate RTF reports which include RTF fragments from << Document >> artifacts associated with packages.

According to the documentation, the RTF template needs to include a "linked document" section to pull the RTF fragment from either the package's "Linked Document" or from << Document >> artifacts associated with the package. While an RTF fragment defined using the "Linked Document" method appears in the generated report, RTF fragments defined in << Document >> artifacts associated with the package do not.

Maybe I am not associating << Document >> artifacts with the package correctly. The documentation, in my opinion, is unclear on how to do it so what I have tried is:
  • Add the artifacts as children of the package.
  • Add the artifacts at the same level as the package and create << trace >> dependencies from the package to the artifacts.

Does someone see an obvious mistake in what I am doing?

Here follows in more details what I am trying to achieve.

The idea is to generate Word documents that follow company standards on the structure of their contents and their layouts from data exclusively contained in EA projects. The obvious way of achieving this is to create one RTF template for each type of documents but I see two disadvantages with this:
  • All the boilerplate sections such as intro, purpose, scope, review and approval table, ... would have to be edited in the templates, hence making it cumbersome to reuse the templates across projects and, more importantly, adding complexity to version control tasks. We are using the manual way of maintaining EA projects under version control by tracking changes in exported XMI files (top level models under "Package Control"). Having to also frequently export the selected parts of "Reference Data" which contain the templates to track changes in the documentation sounds like a bad idea to me.
  • It seems difficult to collect in a single template selected information spread in various places of the model.
For these reasons, I chose to go for the "Master and Virtual Documents" solution. The boilerplate sections are then stored in << Document >> artifacts associated with dummy packages so the whole documentation is part of the model while keeping generic templates as "Reference Data".

Thanks for any advice,


Bugs and Issues / Re: direction of composition relation
« on: November 18, 2015, 09:53:29 pm »
It is said that once the person that invented the USB plug will die, he will be laid to his grave, taken out and turned around (twice?).
With the introduction of Type-C connectors, USB beat Sparx in solving the problem though. And, whichever the cable, USB communication has always been bi-directional by default :).

Bugs and Issues / Outline level issue with RTF documents
« on: June 24, 2014, 02:20:47 am »
[edit]Duplicate of[/edit]


When generating RTF documents, it seems that the template engine inserts \outlinelevel0 control words for every replacement it performs. This causes replacement text in the output document to be at the same outline level as level 1 Headings.

In my opinion, inserted RTF content should be at the outline level of the current style rather than forced to level 1 Headings.

How to reproduce:
  • Create a new project based on a template (e.g. Basic UML 2 Technology/Domain Model).
  • Generate RTF documentation using the "Model Report" template.
  • Open the generated document in Word in outline view mode.
I may have missed something but the only workaround I have found is to post-process the generated documents to remove all occurrences of \outlinelevelN found after the definition of the stylesheet.

Best regards,


Uml Process / Re: Adding Parts sections to Block Diagrams in Sys
« on: May 14, 2015, 01:54:14 am »

No worry, I share your discomfort as I am trying to climb up the exact same steep learning curve. Starting with SysML and a tool and a template project not perfectly aligned to a specific version of the specifications is not for the faint of heart :-).

Out of curiosity, I had a look at the SysML 1.3 specifications about this (, page 45). Basically, the document just provides hints for labelling the block compartments but the final choice is apparently left to the tool implementor or even to the user.



Pages: [1] 2