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 - Paolo F Cantoni

Pages: [1] 2 3 ... 421
We are having problems with EA "Hijacking" our MDG stereotypes (on items created via the API) - even though we ONLY have our MDG selected in the lists.

Normally, our stereotype names are encoded (using an algorithm) so that they DON'T conflict with any other MDG technologies.  However, sometimes, the algorithm (as it currently stands) will generate a conflict - as we discovered with "Goal" today.

We have observed, that even with our encoded stereotypes, if a stereotype with the same name (such as Otcm) exists in the general stereotype list, then EA will use the general version (thus the t_xref entry has a GUID, rather than an FQName).  So we try to ensure that such entries are purged.  But since it's not clear as to how these are created it seems to be a post-facto event (the purging).

So, our own MDG is the only one selected and it is set as the active Technology.  Is it, therefore, a bug that under these circumstances, if I get the API to set the stereotype to "Goal", the t_xref entry should be @STEREO;Name=Goal;FQName=<OurMDG>::Goal;@ENDSTEREO;  and nothing else?

As far as I'm aware, I don't need to set the stereotype in the API to "<OurMDG>::Goal" and, indeed, when we do that, we may get a general stereotype of "<OurMDG>::Goal" at no extra charge and with anomalous consequences.

Can anyone advise on how to specify stereotypes to ensure that our MDG is used when setting via the API?


Automation Interface, Add-Ins and Tools / EPPRofile:: ?
« on: Today at 05:52:26 pm »
We are having problems with EA "Hijacking" our MDG stereotypes - even though we ONLY have our MDG selected in the lists.

One such was the "Goal" stereotype which ended up in our t_xref tables as: @STEREO;Name=goal;FQName=EPProfile::goal;@ENDSTEREO;
Anyone know where the EPProfile comes from?  BTW- note the change of case in the stereotype.


Automation Interface, Add-Ins and Tools / Re: Reverse engineer MDG
« on: December 10, 2018, 03:45:15 pm »
Bugger it's been forever since I've created an MDG.  I guess I'll have to relearn how to extend ArchiMate :-0
We're going through (essentially) the same process - trying to convert our handcrafted MDG to a model based one.

Anyone (Sparxian) know if there is even an XSD for the MDG file?


Then you'll still require multiple passes through the list, won't you? Check each object against all possible parents/children. You can optimize by starting after the element you're checking, but I can't see that you'll only need a single pass.
Neither did we, initially, but the algorithm seems to work.  It doesn't calculate the enclosure level correctly, but it DOES figure out who is enclosed by whom.

When we're done, I'll post here.


Automation Interface, Add-Ins and Tools / "option explicit" - does it work?
« on: December 06, 2018, 03:18:08 pm »
Being careful coders, we put option explicit at the top of each VBScript.

We had a weird bug today which we traced down to an undefined variable name NOT being picked up by the option explicit setting.

Code: [Select]
option explicit
dim GoodOne
GoodOne = 10
BadOne = 20
should fail on the second assignment, but doesn't.

We've discovered that if in Debug mode, the option explicit functionality DOESN'T WORK!

So to check for option explicit you need to run the script in a normal manner.

"It's a bug, Joyce!"


I'd say that the order is a product of the internal ordering rather than something official.

That said, I can't see a reason why it would be changed.

PS. Looking for a single object enclosing "the rest" of the selection?
More general - looking for objects visually enclosing other objects.  In the selection, there may be more than one set of enclosures.


Automation Interface, Add-Ins and Tools / Selected Objects Collection Order
« on: December 03, 2018, 12:40:36 pm »
We are reinvestigating Visual Enclosure with some scripts to help with the relationships between the enclosed and enclosing objects.

We have observed that the selected objects collection seems to have a special property.  The objects in the collection appear to be returned in reverse Z-Order.

Is this intentional?  Can we rely on this behaviour?  It seems eminently reasonable that they are returned in that order.  If we can rely on this behaviour we can simplify our code tremendously and determine enclosure in one pass.


Bugs and Issues / Re: Data Modeling Diagram with version control and VCE
« on: November 30, 2018, 12:16:41 pm »
Hello everyone,

EA Version 14.1.1427

When using a Data Modeling Diagram with version control and VCE. After making the changes in the diagram and arranging it I make a check-in.

However, when doing the next check out the organization of the diagram is thus lost with the VCE used. From what I could realize this problem only occurs when I use VCE.
I suspect this is another problem caused by NOT storing the VCE as a REAL diagram object in the repository.

I have argued that they should be stored as real diagram objects but categorised as VCEs.  To a simple user, the downstream benefits are legion and I can't really see any downside - but what would I know?


I think you are looking for the option Preferences | Objects | Support for Composite objects.


Ask, and ye shall receive!

Thanks Geert!  That did the trick - so I guess it was NOT always thus.

Seems like another misnomer to me.  The objects are not composed, they are nested.


We have had issues in the past with EA confusing Visual Enclosure with Nesting.  But we developed a technique that allowed us to visually embed the items on the diagram as required WITHOUT having EA nest them in the browser.

Recently, we have returned to the exploration of visual enclosure and its impact on the model.  (It's a LONG time since we played with any new visual enclosure so it may have always been thus, and we didn't notice it.)

Anyway, we have found that if we accidentally move a visually enclosed item the item will be suddenly (and for us unexpectedly) NESTED under the enclosing item.  We are able to move the items out from being nested to their correct locations (we have specific folder for specific item metatypes).  The visual enclosure is NOT affected.  So we're VERY annoyed with the behaviour (espeically since it can be shown to be theoretically incorrect - particularly in the case of ArchiMate)

Is there any way to stop this behaviour (out of the box)?


It actually is documented in the help file, you are right.
Strange enough, searching for the exact string results in:
The search "_HideUmlLinks" did not match any documents

So the question is...  Why?


General Board / Re: Problem using custom tag of type association
« on: November 23, 2018, 10:56:38 am »
Hi Paolo,
you wrote "However, why not just link one relationship to the other?  We do that increasingly.".
That sounds good, but how do I do that? My associations do not show any link option - or at least I didn't find anything like that...
Would be great if you could point me where to find it.


Hi Dirk,

It's not clear if you are asking about manual or automated creation of the relationship.  But since in order to get the automation right, you'll need a worked manual example, I'll show you how to do it manually, and then you can investigate what the result is in the DB.

So, to create a relationship between a relationship and another relationship, you need to:
1) Select the origin relationship
2) In the "centre" of the rendered line, you should find a QuickLinker widget
3) Grab the widget and drag it to the other relationship (or even a shape) when you release, you'll get the QuickLinker options to select which relationship you want to create.

That's it!

You'll find that the new relationship is drawn from the "centre" to the "centre" of the other line.  "Centre" is emphasised because depending upon the line style and the underlying shape script, the "centre" may not be where you are expecting it.

Where one relationship joins the other relationship, EA creates a misnamed "Proxy Connector".  It is misnamed because it is actually a shape (and therefore in t_object) that is a Connector Proxy.  If you are connecting two relationships with another, you get two connector proxies - one at each end.  These can now be selected and moved (to some extent) along the relationship they are attached to.


General Board / Re: Problem using custom tag of type association
« on: November 22, 2018, 11:39:20 am »
The problem may also be related to the fact that there are TWO "Association" types in EA.  The relationship (arc) and the n-ary Association element (vertex).

I think if you added one of these "Association" vertices to the project, it would turn up on your list.

Also, note that when you use a RefGUID, EA tries to locate the element and return its name.  Since your association relationship is unlikely to have a name, it most likely will return "blank".

Geert's solution is the only viable one if you intend to go via the RefGUID route.  However, why not just link one relationship to the other?  We do that increasingly.


General Board / Re: MDG Issue_13.5 & 14
« on: November 21, 2018, 11:55:43 am »
Hi Aariyeh,

It may be that your "Objective" stereotype in v14 is being "hijacked" by another MDG.  Check the t_xref stereotypes entry for the element.

We deliberately "encrypt" our stereotypes so that they don't clash with any other MDG, but we made a mistake on one.  We found our ABB (Architecture Building Block) was being hijacked by the TOGAF MDG, even though we had not enabled the MDG.  We renamed the stereotype and now all is fine.

As I understand it, in v14, ALL the "visible" MDGs are loaded into EA, but only the ones you enable are supposed to be activated.  We've found that functionality less than optimal as of v14.1.  Eventually, they'll sort it out.


Bugs and Issues / Insert related elements- NOT!
« on: November 16, 2018, 12:46:15 pm »
The "Insert Related Elements" functionality needs to be renamed to "Insert Connected Elements" since it does not include some pretty fundamental relationships which are not implemented as connectors, to wit: Nesting and Classification.  The functionality only references elements related to the root element by an entry in t_connector.


Pages: [1] 2 3 ... 421