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 - Geert Bellekens

Pages: 1 [2] 3 4 ... 565
General Board / Re: How to enable the "Find Command..." widget
« on: October 15, 2018, 05:51:08 pm »
For the visual styles that don't support the Find Command in the top bar.
If you click the top left EA Icon-Menu, the last option is the same Find Command.


General Board / Re: EA just won't v14, v13, v12...
« on: October 13, 2018, 01:27:08 am »
Have you tried a system restore?
If you are on Windows 10 then it should have created a system restore point the moment you installed EA v14.1

Saved my ass this week after all of my add-ins suddenly stopped loading (and all I got from EA was a lousy hex error code)

What I would also try is to remove the EAAddins key from the registry (both from HKLM as from HKCU) to make sure no add-in is somehow causing the issue.


General Board / Re: Configuring Element Label in Project Browser
« on: October 12, 2018, 11:21:38 pm »
No, not in the current version, but you can always send in a feature request


If all else fails there's still the undocumented/unsupported backdoor Repository.Execute(SQL)



I'm not saying you are wrong, but quickly renaming a set of requirements is much easier when you do "View as List"


General Board / Re: Auto creation of a composition with ArchiMate
« on: October 12, 2018, 07:49:24 pm »
In fact I'm not inclined to use the project browser nesting all to much, mostly for pragmatical reasons.

One of main reasons is version control and model security.

Version control only works on package level.
If I were to put all the business processes of my entire enterprise under one root process, all of them would be controlled in a single version control file.
That means that there would only be one person at a time who could work on the business processes.

Same story more or less with security.

Another reason to use explicit composition relations is that you also see them when you add two related elements on a diagram.
The project browser ownership/nesting relation is implicit and not visible on diagrams.
And it is all to easy to move an element up or down the tree by mistake. If you are using only te ownership/nesting relation you might not even know you changed something crucial to your model.


Hi Uwe,

I don't know if there is a standard, out of the box, solution, but there is no reason why it shouldn't work with scripting.
It's just a matter of figuring out exactly how EA stores all these elements and relations.


PS. Hooking up a profiler that records all SQL traffic to the model often helps in figuring out things like that.

So it seems like in a very distant past (v10?) the trace was a stereotypes dependency.
Then they seem to have introduced the Abstraction connector type and trace because a stereotyped Abstraction, just like the UML specs say.

It now going back to dependency when you don't have "Filter to Toolbox" checked then seems like a regression, where the v10 behavior somehow pops up again from beyond the grave.


Did some more testing.

So I guess the bug is in the Filter to toolbox functionality

Actually, Geert, I think the problem is elsewhere.  You may find you have a «trace» relationship in the "Common" stereotype list.  Filter to Toolbox should exclude it (only the MDG version is selected), whereas unmarked Filter to Toolbox, doesn't - because the common one "kicks in" first.

That's why we purge ANY common stereotype that matches our MDG defined stereotypes in our overnight processing.


Hmm, but in v12, where the Filter to toolbox doesn't exist I never have this problem.
Did they then change the default stereotype loading order?

Deleting the default trace stereotype from the common stereotypes list doesn't influence the behavior.


Did some more testing.
Disabled all add-ins and MDG's and actually removed the MDG's loaded in the model (apparently disabling them doesn't "really" disable them as I can still select the toolboxes from those MDG's. But that's a different issue)

Then tried it again using the quicklink and still a Dependency.
Then tried it with the trace connector from the common relationships toolbox and that creates an Abstraction ???

I'm using it on a class diagram from a class to another class and from a package to another package. Both Class as Package have the same results.

Then to be sure I created a new empty .eap file.
Disabled all but Basic UML2 technology MDG
Created a class diagram
Created a trace relationship using the quicklinker with "Filter to toolbox" checked => Abstraction
Created a trace relationship using the quicklinker with "Filter to toolbox" unchecked => Dependency

The same test (except that "Fitler to toolbox" doesn't exist) in v12.1.1230 results in Abstraction.

So I guess the bug is in the Filter to toolbox functionality


General Board / Re: Auto creation of a composition with ArchiMate
« on: October 11, 2018, 11:33:43 pm »
That is to the feature to link a "composite diagram" to an element -> drill-down.
Not related to composition relations.


General Board / Re: Auto creation of a composition with ArchiMate
« on: October 11, 2018, 11:20:03 pm »
No, it doesn't.
You'll have to write a little script or add-in if you want to do that.


When I create a «trace» relation in v12.1.1230 I get a connector of type Abstraction with stereotype «trace»
When I create the exact same «trace» relation in v14.1.1427 I get a connector of type Dependency with stereotype «trace»

WTF! >:(


So now we are getting a nice mix of abstractions and dependencies in our models.
Not to mention the countless queries that are now broken, and a number of add-ins that depend on this relation being an Abstraction.

Was this an intentional change (I didn't see anything about it in the release notes) or a mistake?
In case of the latter I hope it gets rectified real soon.


PS. I'm not arguing Abstraction is better somehow than Dependency.

Automation Interface, Add-Ins and Tools / Re: Create MDG via script?
« on: October 10, 2018, 01:47:55 am »
What's even better with assembling the MDG from XMLs yourself is that you can look into the latter and detect whether they contain what they should (so is it a profile, for toolboxes, patterns, etc.). EA does not do that but blindly copies the files you pointed it to. I can't count how often I saved a profile at the wrong place (since EA does not remember the preferred place to save) which led to a just not working MDG ("go, figure" EA lets me stand in the rain) - well, until I did the assembly myself.

Version 14.1 now remembers where you last save the package/diagram as a profile thus avoiding these common mistakes.
You see sometimes they listen to us  :)


General Board / Re: Status property of diagrams
« on: October 09, 2018, 08:38:08 pm »
Hi Jörg,

No, the Use Case is the entity that is relevant, and that use case can be shown on different diagrams.
The use case should have a status, not the diagram.

Even more so with activity diagrams. An Activity diagram should only exist nested under an Activity. It is the Activity (and it's status) that is relevant in your model, not the diagram.


Pages: 1 [2] 3 4 ... 565