Recent Posts

71

General Board / Re: Does EA allow capturing Win32 UI simulation input and sending it to a database?

« Last post by Geert Bellekens on November 13, 2025, 08:15:37 pm »

EA is a modelling tool that can do some form of simulation.

It is not intended as a subsitute for a real application that can be used in a real environment.

There are other tools that are intended for this purpose (e.g. Camunda)

Geert

72

General Board / Does EA allow capturing Win32 UI simulation input and sending it to a database?

« Last post by sude.ciloglu on November 13, 2025, 07:52:34 pm »

I created a Win32 Login UI and a State Machine in EA, and I am running the simulation. My goal is to take the user input entered in the UI , use these values inside the State Machine, and then send them to a database (or generate Java code that can do this). However, EA does not expose or persist any user-entered values during simulation, and Win32 controls do not provide an event panel, so the Simulation Events window remains empty.
My question is: Does EA support capturing UI input during simulation, passing it into the model, and generating code that can forward this data to a database? Or is the intended workflow that UI + State Machine are only for modeling, and real input handling + DB operations must be implemented externally in Java?

73

Suggestions and Requests / Re: Connector multiple selection

« Last post by Geert Bellekens on November 13, 2025, 06:59:17 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 work around 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

That problem is mostly solved by the "apply line style on diagram" option, and without needing to open yet another property window and applying this quirky workaround.

But the fact remains, it would be very helpful if we could multiselect connectors on a diagram.

Geert

74

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

« Last post by Paolo F Cantoni 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

75

Suggestions and Requests / Re: Connector multiple selection

« Last post by Paolo F Cantoni 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

76

Suggestions and Requests / Re: Connector multiple selection

« Last post by A_Marsh on November 13, 2025, 08:42:07 am »

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 work around 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

77

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

« Last post by Modesto Vega on November 13, 2025, 01:23:39 am »

We can indeed used 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 subject: visual nesting vs physical nesting (Paolo, sorry for paraphrasing).

The issue is that the browser enforces physical nesting where an element can exist only in one package or as a composite of another element - i.e., the element can only have 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 completely redesign of both the browser and the underlying data model; something they may not want to undertake.

78

General Board / Re: MCP (Model Context Protocol) server for Enterprise Architect has been released

« Last post by Takeshi K on November 12, 2025, 06:03:18 pm »

The version 2.2.0 has been released. I found and fixed some issues during my tests, but there may still be others.

79

General Board / Re: MCP (Model Context Protocol) server for Enterprise Architect has been released

« Last post by Viking on November 12, 2025, 05:17:39 pm »

The implementation for adding/modifying attributes and operations (including parameters) has been completed...
I think I can release the new installer today or tomorrow.

Great news

80

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

« Last post by Paolo F Cantoni 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