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 - Marc Vanstraelen

Pages: [1] 2 3
General Board / Re: package connections
« on: April 28, 2018, 12:05:20 am »
Not sure if I understand your requirement correctly...

If you want these associations to be visible on your diagram, then "Insert Related Elements..." seems indeed the way to go.

If you simply want to explore what relationships exist, you can also use the Relationships window or the Traceability window.
Or you could use the document generator to produce a report that lists all associations for the elements on your diagram.

General Board / Re: Excel Import
« on: April 27, 2018, 11:51:47 pm »

Following steps are useful:

1. SHIFT+right-click on background of a target Class diagram and select 'Create Multiple Elements...'
2. select all cells which contain names in the spreadsheet and press Ctrl+C (i.e. copy to clipboard)
3. right-click the Name cell in the Create Multiple Elements dialog of Enterprise Architect, and select 'Import name from clipboard'


To save one more keystroke  ;), in step 1 you can also use the space bar instead of SHIFT+right-click...

Suggestions and Requests / Re: Relationship between/to Attributes
« on: January 25, 2018, 11:22:07 pm »
EA has a function called "link to element feature," with which you can fake connections to attributes and operations (which is what qwerty's talking about and something you've already tried). However, this is mainly visual. Crucially, these fake (well, semi-fake) attribute connections are not available to other core functions like basic document generation or relationship matrices: these functions only see relationships between elements (classes, components, etc).

For document generation, it is possible to include linked element features in the RTF template by checking the "Linked Feature" under the Source or Target of a Connector. I used this to document links from screen elements to class attributes.

I do the same for testing newer versions while keeping also the version currently used in our organisation (12.1). Works perfectly.

Well, in the footer I mention the template that is used to generate that (part of) the document, and in the header the type of content (e.g. Information Model). Which obviously is not the same across all parts of a virtual document. As long as we were working with a single template starting from the documented package, this wasn't an issue.

General Board / Re: menu maps for 13.5 ribbon detail
« on: October 26, 2017, 11:18:41 pm »
Thanks, that's a useful resource!

I now noticed another small issue: although both sections use their associated template, the second part continues using the page header and footer from the first, even though in the template a different one is defined...

Thanks Geert, that indeed solved it.

I'm setting up a virtual document to generate a document that contains the contents of two different packages, each generated with its own RTF template (via two model documents). The resulting document contains those as required. However, it also contains a section for the <<Master document>> package, listing the classes it contains, being the two model documents. Obviously this is not what I want to see, as these only serve to define the document structure and are not part of the content itself.

What am I doing wrong? Is there some option that I need to set? I'm using EA 12.1.

Thanks Geert, that's indeed what I thought.

One of our analysts is specifiying screens in EA (v12.1) that contain wireframe tables. She would like to output the contents of the different cells in the generated RTF documentation, but for now we can only get the visual representation on the diagram.

I found that the definition of the table is stored in a "Properties" tag, so I'm afraid that to extract the content in a readable format, the only way to go is via a scripting template fragment. As I don't (yet) master scripting, I'd like to know if there is any other possibility?

It appears you can now see the effects of a diagram filter in a generated document, by simply applying the diagram filter and then generating the document. The possibility was pointed out to me in a recent forum thread:,38744.0.html

I don't know since when this is possible; I tried it in version 12.1 and it works.

Just tried this and it works... Almost too simple to be true  :)

You could consider adding a Diagram Legend to your diagrams, with the option "apply auto colour". This allows to automatically change the appearance of elements based on a property, e.g. the Phase or Status. You can change the fill colour as well as the appearance of the borders.

This of course impacts your diagrams directly, not only the generated documentation.

There are also diagram filters that can gray out or hide elements based on selection criteria, but I have no idea if these can be made to be applied during document generation...

Bugs and Issues / The wonderful world of stereotypes
« on: April 13, 2017, 12:59:46 am »
I stumbled on some "interesting" behaviour of the stereotypes functionality in EA (I'm using version 12.1 build 1230).

Say you create a use case element and type a value in the "Stereotype" box that is not yet defined in the UML Types, e.g. "user story"
Later you use the menu Project > settings > UML Types...  to add this stereotype "user story" to the list.

When checking in the table t_stereotypes, you now have two entries with STEREOTYPE = 'user story', but interestingly:
- one has APPLIESTO = 'UseCase' (the one created by typing it directly in the element, as I found out)
- the other has APPLIESTO = 'usecase' (this is the one created via UML Types)

They both appear in the UML types dialog, but there in the "Applies to" column, both show 'usecase' (no difference in caps visible).
They also both seem to have the same GUID.

Say you now want to only use the stereotype you explicitly defined in the list. You go into UML Types and delete one, but now both have disappeared (*).
So you create it again via UML Types. All seems to work well: the elements that use the stereotype display correctly in the defined style associated to the stereotype.
But the newly created stereotype has a different GUID. The table t_xref stores in its field DESCRIPTION all stereotypes associated to an element (to allow for multiple stereotypes). Here, you'll still find the old GUID of the deleted entry. Only if you remove the stereotype and then add it again, the new GUID appears. I have no idea if this could cause issues.

All in all, using stereotypes risks creating some confusion if you don't set up some good conventions with your users...

(*) I also noticed that if you edit one of the two, both seem to change.

Pages: [1] 2 3