Messages

1

Automation Interface, Add-Ins and Tools / Mirror Nodes - An alternative to External References

« on: December 27, 2025, 05:54:13 pm »

Following our adventures with External References (where we need to transport one or more specific packages between two or more repositories), we’ve considered the issue and decided we need a more robust solution for our purposes. (see https://sparxsystems.com/forums/smf/index.php/topic,49201.0.html)
So we came up with the concept of “Mirror Nodes”.  A Mirror Node is a clone of its “Master” Node, so that if the Master is updated, we (automation) will also update the “Mirror” to maintain the “Mirror” status.
A new edge metatype, mirroring, will connect the two nodes.
We can thus use the Mirror node in the package to be exported, and it will appear as a full participant in the other repository.  We can also use Mirror Nodes within the same repository.
Architecturally, we propose adding a property, MirrorStatus, to the node, with the following enum values: None, Master, and mirror.  Note that the absence of the property implies None.  The node will also have the property LastMirrorActionTimepoint, which specifies when the last Mirroring action occurred.  If the MirrorStatus is None (whether set or implied), then the LastMirrorActionTimepoint is set to Not Applicable.  If implied, then the LastMirrorActionTimepoint property may be absent.
Additionally, the mirroring edge will also have the LastMirrorActionTimepoint property.
While conceptually we could allow a two-way link (i.e., will enable the mirror to change and the change to be pushed back to the Master), we have opted to allow only forward mirroring.
We have also decided not to allow “Mirrors of Mirrors”!  That is, if the user attempts this, they will be guided to mirror the original Master.
As you can see, this is a mix of the existing Sparx functionality for Time-Aware Modelling (TAM) and Virtual Connector Ends (VCEs), with an extra one thrown in.
I will leave it to the reader to consider what would happen if the mirror were transported to another repository, while the Master is not.

Before we go ahead with implementation, can anyone see any issues with the proposal?

TIA,
Paolo

2

General Board / Season's Greetings to all forum members!

« on: December 25, 2025, 10:54:57 am »

Have a great holiday season and please stay safe and look out for all your loved ones (and anyone else...).

Paolo

3

Automation Interface, Add-Ins and Tools / XEA Transfer losing external references

« on: December 21, 2025, 08:42:05 pm »

I need to move a package with subpackages between at least two repositories regularly for the present.

I usually use the XMI 1.1 format.  I have set it up as a Controlled Package with the "create placeholders for external references" marked.  The package transfers (almost) correctly (see below), with the external references indicated on the diagram.

I tried using the XEA format since it's a direct EA-EA transfer.  The external references weren't transported, and the Project integrity check "went berserk"!

This seems to be a defect, but I thought I'd check if this was the expected (or even correct?) behaviour.

The "almost correct" note above was that even though the nodes transferred as external references, there were two nodes connected by two edges but only one edge came across as an external reference.  Is this also correct behaviour?  I'd see it as a defect.

TIA,
Paolo

PS: I haven't investigated further because I’ve wasted a lot of time in the past, before checking what the expected behaviour ought to be.

4

Bugs and Issues / Re: v17.1 - Extended character issue with Name field in Properties window

« on: November 24, 2025, 10:05:14 am »

I can confirm this behavior in v17, but also in v15.2.1560

Geert

Thanks, Geert,
I rechecked my v15.2.1560, and I must have waved a magic wand because this morning it also behaves as the others.
Did you notice the 32-bit - 64-bit difference also?

Paolo

5

Bugs and Issues / v17.1 - Extended character issue with Name field in Properties window

« on: November 23, 2025, 06:27:21 pm »

I need to rename some items to add guillemets «» to some words.  Imagine my surprise as I went into the Name field of the Properties window and added the left guillemet « to the beginning of the word in question (using the keystroke Alt0171), only to find that the field was cleared and the « was the only character left in the field.

I was surprised because I was sure it didn’t use to behave like that, and indeed it behaves correctly in v15!

To enter guillemets successfully, I have to open the item (using [Alt-Enter]) and use the Name field therein.

The problem occurs in both v16 and v17, and in both the 32-bit and 64-bit versions, although the behaviour of the 64-bit version is subtly different (EAUI!).  If the guillemets are added at the end of the field, they are entered.  Elsewhere in the field, they replace the original value!

Is this just on my machine, or do others observe this weird behaviour?

Reported,
Paolo

6

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« on: November 15, 2025, 08:14:51 pm »

You could also say it’s a prototype model.
You are making prototypes of the concepts to illustrate their usage.

Geert

Good thought!  Maybe a Metatype diagram, since that’s what’s going to be on it!


Paolo

7

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« on: November 15, 2025, 01:28:45 pm »

Thanks, guys, for your input.  Most valuable!

I think, using (mainly) Geert’s reply, that what I am building is a profile diagram.  Its intent is similar to the poster, but drawn from an individual node’s perspective (like my Neighbourhood diagrams).

The next problem is that, unlike the paper or PDF poster, I’m creating a model.  So I think I need to distinguish my Concept Node item from the Concept item.  Perhaps I could name the Concept node “«Concept»”, since it embodies the metatype?  Thoughts, other suggestions?

Paolo

8

Automation Interface, Add-Ins and Tools / Re: ArchiMate Grouping and Alternatives

« on: November 15, 2025, 12:36:02 pm »

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature.  But I will blame the forum’s poor search engine for not allowing me to quickly find one of the posts where we discussed this in the past.  Perfectly happy with “nesting” meaning physical nesting, and using “visual embedding” to describe the ability to move an item in or out of another item on a diagram.  Having said this, Sparx EA doesn’t do “visual embedding” very gracefully at times. 

It wasn’t trouble, merely a gentle correction.   I agree with your point about the searching capability.  Why is searching SO hard (as a functionality)?  It’s not just here that one can criticise the searching as being less than optimal.  Anyway, another gentle correction (to myself, not the least), Nesting doesn’t actually apply to physical nesting; it applies to referential or access nesting - as I have indicated in the past, nesting defines the namespace of the meronym - in other words, you have to access the higher level items to get to the lower level item  (x.y.z).  The physical nesting in the browser is just a manifestation of that concept.

Also, “nesting” is really a form (de-)composition, but AFIK, there is no relationship for it in any modelling language I am familiar with.  Is this not the same as representing “car” as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements?

Yes, you are correct, it is a form of composition, but from the point of view of accessing the item via its FQN.  We use the Nestign Connector as described in the User Guide:
Index > Modeling Languages > Unified Modeling Language (UML) > UML Connectors > Nesting
extensively so that if the meronym and the holonym are on the same diagram, there will be a visual indication that there is a referential nesting, even if the name doesn’t show that (we use use-friendly Aliases a LOT).  The UG places it under UML Connectors (as you can see above), but I couldn't find any reference to it in the Superstructure. 

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG.  Actually, I have done it myself.  My point is two-fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change, not very high up in their plans.I, too, have observed this.

2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visually embedded.  If the browser could be hidden for certain users, this view could serve as the main entry point for work by some of the users we typically collaborate with.  After all, some relationships are a natural visual embedding: specialisation, aggregation, and composition.

Since we gave away the notion of the browser indicating any form of holonymy, we basically haven’t had that problem.  Only items that require referential nesting are nested.  All other items are in a "flat" structure (by type).  The diagrams are in a separate branch of the repository and can be structured however you like.  Consequently, we don't have as much of a problem as you do.

Paolo

9

Automation Interface, Add-Ins and Tools / When is a Metamodel not a metamodel?

« on: November 14, 2025, 07:52:01 pm »

We are familiar with creating an MDG, particularly in this section of the website.  The MDG defines the nodes that the technology allows you to create and the edges that can connect them.  It also allows you to define how the various nodes and edges will be rendered, along with any constraints that may apply.  It further allows you to define the nature and properties of the items.  This sounds suspiciously like a metamodel, but is it?  If it’s not a metamodel, what is it then?

I’m asking for your thoughts.

We currently create our MDGs in a separate repository that contains the MDG definitions.  We then generate the MDG and apply it to the repository that holds the actual models we are developing.  As the MDG developer, I can review the diagrams (in the MDG repository) for the items and visualise how they will appear in the model repository.  But this is too difficult for the user who just wants to model and understand the rules.  “The thigh bone’s connected to the knee bone, the knee bone’s connected to the leg bone... etc.”.  So I thought we’d create the equivalent diagram to the one in the MDG, but with the «stereotype» item replaced by the generated item and the «stereotyped relationship» replaced by the generated edge and so on.  This would provide a visual view of what the MDG can do.

What kind of diagram would this be?  Could I call it a metamodel diagram?  What about the items, both nodes and edges, on the diagram?  Are they the generated items or something else?
For example,  I have «stereotype» in the MDG whose _metatype is Concept.  Concepts are represented as nodes in the model (in fact, they look suspiciously like ArchiMate Meaning items).  Do I place a Concept on the diagram, or do I place a Concept Node on the diagram?  Similarly, do I place a Composition or a Composition Edge on the diagram?

Thoughts and suggestions would be much appreciated.

Paolo

10

Automation Interface, Add-Ins and Tools / Re: ArchiMate Grouping and Alternatives

« on: November 13, 2025, 04:06:07 pm »

We can indeed use Guillaume’s solution. I think I used it once in the past.

The Standard says: (4.5.1 Grouping)
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”

As noted by Paolo, in a much more sophisticated language, the issue with the way this is implemented is that, from memory, it is not possible to draw aggregations and compositions between a grouping and the elements it groups.

This, of course, brings to the forefront the way the browser was designed and implemented —and one of Paolo’s favourite subjects: visual nesting vs. physical nesting (Paolo, sorry for paraphrasing).

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

The issue is that the browser enforces physical nesting, meaning an element can exist only in one package or as a composite of another element—i.e., it can have only 1 parent element (package or standard).  This means, the same version of an element can only exist once in the browser.  I suspect Sparx Systems sees implementing the ArchiMate grouping, which could be argued is a form of visual nesting (not physical nesting), as a complete redesign of both the browser and the underlying data model; something they may not want to undertake.

Not quite; Grasshopper...  The ArchiMate Grouping is a Holonym (either an aggregate or composite - as required), consequently, the convention of suppressing the holonymic relationships when visually embedding applies.  That is, the impetus is reversed from what your statement implies.

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Cheers,
Paolo

11

Suggestions and Requests / Re: Connector multiple selection

« on: November 13, 2025, 03:52:51 pm »

I've recently become a user of Enterprise Architect again after several years away and this was the first pain point I ran into when trying to change the line style of my connectors.

I found a workaround for my (Data Model) case:
 - Select all diagram elements (Ctrl + a)
 - Open the "Relationships" window
 - Multi-select the relationships/connectors that you want
 - Right click - change line style

“Noice!”

Paolo

12

Automation Interface, Add-Ins and Tools / Re: ArchiMate Grouping and Alternatives

« on: November 12, 2025, 03:51:31 pm »

A key challenge in the Sparx Systems implementation of both the UML Package and the ArchiMate Grouping element is the conflation of an element’s type with its role as a container.  This design choice, while pragmatic in some respects, restricts the ability to create relationships to or from the container itself and other “proper” elements, fundamentally complicating modelling efforts such as the one described by the OP.

I basically agree with Modesto (surprise, surprise! ) with a few, hopefully minor, caveats (see below).  We also used Guillaume’s solution to create our own Grouping Element (with a set of supporting scripts).

The Standard says: (4.5.1 Grouping)
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”
Now, you’ll note that there is NO mention of a boundary!  Notwithstanding the way the element is depicted in the associated diagram - the dotted borders to the Element, suggesting, in Sparx terms, a Boundary (a non-UML item), there is no mention of boundary in the entire definition section!

Just as “Correlation is NOT Causation”, “Rendering is NOT Implementation”! 

Now to the question of containment...  Our view is that, while the standard mentions aggregation and composition relationships, the definition of a grouping element is actually that of a holonym (the whole-holonym, rather than the parts-meronym)!  Also, the mention of aggregation and composition is to determine the nature of the holonymy (and thus the nature of the relationship between the meronym and the holonym).  That is, if a meronym can exist in more than one grouping at the same time, then the holonymy is an aggregate; otherwise, it is a composition.  This becomes a property of the Grouping element (which we surface as required with our shapescript).  There is NO implication of structural containment!

Consequently, the Grouping Element is neither a boundary nor a container, merely a normal element indicating that a set of other elements may be considered a group of related things.  Indeed, one could argue (and we do that the example shown in 4.5.1 of the Standard is a little misleading.  The REAL relationships are between the Service, the two processes, and the object.  The Grouping Element is merely a shorthand view—albeit a formal and rigorous one—to reduce visual complexity.

As I said earlier, we implemented our own Grouping Element that supports the Standard while providing the properties identified above.

HTH,
Paolo

13

Automation Interface, Add-Ins and Tools / Re: EA and ChatGPT 5 - the death of the forum?

« on: November 12, 2025, 10:42:57 am »

I've had the same experience. It's a great timesaver if you know what the result should look like.

If you have no clue, it might be very time-consuming to figure out where exactly it goes astray.

Geert

This seems to be the problem with all AI tools: if you know what you are doing or what you are expecting, they can be a good productivity tool.  If you don’t, they just generate rubbish.

(my emphasis)
Not quite Modesto...
They MAY generate rubbish. The problem is that if you don't know what you’re doing, you can't tell if it is rubbish!  This is worse than consistently creating rubbish.

Paolo

14

Automation Interface, Add-Ins and Tools / Re: how to change default apperance for MDG stereotypes

« on: July 25, 2025, 10:12:22 am »

I downloaded the Lieber c4 model from Sparx website
I tried to change the appearance of some stereotypes changing the attribute cx, cy and bgcolor inside the XML file before loading into EA
Changed cx and cy are taken into account but the bgcolor change don't work
I weant only to change the default appearance when the stereotype is created living the user the option to modify
thanks for your answer.
Fausto

Ciao Fausto,
The usual reason for this behaviour is that the shapescript contains a statement overriding the "default" value shown in the XML file.
Remember the definition of "default" is:  "In the absence of a countervailing instruction, do this...".  Unfortunately, the shapescript - hidden in the base64 encoding - contains that "countervailing instruction".  It would appear the shapescript doesn't have an override for the cx and cy values.
HTH,
Paolo

15

General Board / Re: Can no longer post SQL Statements to this forum

« on: July 17, 2025, 08:11:41 pm »

Interesting, this is very specific and a very Sparxian solution was implemented. A simple select statement can be posted, please below.

Code: [Select]

SELECT * FROM t_object
But any statement starting with anything other than a SELECT statement cannot be posted.

SQL statements for most RDBMS do not have to start with a SELECT statement. A plea to Sparx Systems, please address that at least in the forum and, if possible, in the software.

(my emphasis)
Not necessarily, Modesto.  SQL injection is usually used to make some change to the database (i.e. delete it). SELECTS don't do that, so they are allowed.  It may be a more generic setting in the Cloudflare system.

My AU$0.05
Paolo