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 - robinch

Pages: [1]
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 / 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 / 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 / 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,


Pages: [1]