Messages

1

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

« on: November 25, 2025, 11:18:25 pm »

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.

The issue that I have always faced with Sparx EA, specially with enterprise level or multi-project repositories, is that I have never managed to dispel the notion, for me and some of my colleagues, of the browser not indicating a semantic relationship between the whole and the part, irrespective of whether there is referential nesting or not. The browser looks like a folder structure, is used like a folder structure, and it is way too easy to create a very deep folder structure.

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.

I have used Sparx EA, like that, but it is very cumbersome and leads to duplication. This is because when creating an element from a diagram Sparx EA always places the element in the package containing the diagram. As a result, we switched to having elements and diagrams of a similar type in dedicated packages but this still does not solve the duplication problem.

Ideally, I would like to restrict the use of the browser to advanced users and use views for most people contributing to a model. Of course, it does not help the way Sparx Systems has implemented views, including the capability of creating (non-dynamic) views under the root node. TBH, I have never understood what views are and how they work, other than another way of referring to a folder.

2

General Board / Re: Importing stereotype extending PackagingComponent via CSV

« on: November 25, 2025, 10:54:19 pm »

Hi Mauricio,

The PackingComponent is one of those elements I have previously described in the forum as having a dual personality - i.e., it is an element but it also a package. It exists twice in the repositories.

With previous version of Sparx EA (v13 to v16), we tried using it as a component, or to be more specific as a way to model an Information System Service or a complex application. We gave up because of a combination of issues importing and exporting data and limitations on how this element is rendered by Sparx EA when used in diagrams.

3

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

« on: November 14, 2025, 10:33:08 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 poor search engine for not allowing me to quickly find one of the posts where we discussed this is 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, at times, doesn't do "visual embedding" very graciously.

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

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.
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 visual embedded. If the browser could be hidden for certain users, this view could be the main entry point for any work done by some of the users we typically collaborate with. After all, some relationships are a natural visual embedment: specialisation, aggregation, and composition.

4

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

« on: November 14, 2025, 09:21:33 pm »

I now follow a similar approach to Geert, with possibly one exception I am still thinking about.

I typically have the following:

1) A conceptual model, using UML class diagrams, without attributes. Depending on the size of the MDG, I will use multiple diagrams.
2) A Logical model, again using UML class diagrams, with attributes. I use as many diagram as I used in the conceptual model.
3) The EA profile used to generate the profile.
4) And, often but not always, a poster leveraging the conceptual model, typically breaking down the model into, for example, aspects or layers.

I always keep all the above in the same repository or branch of the repository.

The exception I have not worked out yet, is how well the above works for an MDG based on, for example, Sparx EA implementation of ArchiMate. The main reason is that is that I don't want to get caught in reverse translation exercise.

5

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

« 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.

6

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

« on: November 11, 2025, 11:09:19 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.

7

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

« on: November 11, 2025, 10:55:31 pm »

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.

8

General Board / Re: How to deal with multiple target platforms

« on: November 11, 2025, 10:52:36 pm »

The only suggestion I can think of is to use ArchiMate, specifically the grouping composite element described here https://www.opengroup.org/sites/default/files/docs/downloads/n190p_5.pdf.

This is likely going to involve creating a grouping per platform.

The biggest problem is how Sparx EA implement the grouping element. Unfortunately, in version 16, it was not implemented as a proper element, this limits drastically the relationships that can created between groupings and proper elements.

9

General Board / Re: PCS & SQL Server 2022

« on: November 11, 2025, 10:39:45 pm »

I got an e-mail from Sparx Systems support about this. In a nutshell:

• SQL Server 2022 is fully compatible,
• Windows Server 2025 has not yet been officially tested, and
• The latest officially tested version of Windows Server is 2022.

10

General Board / Re: PCS & SQL Server 2022

« on: November 03, 2025, 07:27:27 pm »

Hi Guillaume,

I haven’t experienced any issues, I am just exercising caution. We need to upgrade our current setup to SQL Server 2022 and the latest Windows Server OS supported by that version of SQL Server.

Just reaching out to the forum for comments before to avoid getting into a technical rabbit hole.

11

General Board / PCS & SQL Server 2022

« on: October 16, 2025, 12:59:38 am »

Is anybody aware of any issues with PCS using a SQL Server 2022 database? Am I correct to assume there are no compatibility issues?

12

General Board / Re: Best Practices for Modeling a Multi-System Integration?

« on: October 14, 2025, 07:57:51 pm »

1c: do not let your notation drive your model documentation: pick a methodology and then document your systems, processes and data accordingly

This is an excellent point: notation should not drive model documentation. Having said that I find the current version of ArchiMate more intuitive than UML, but I do have some UML nostalgia like almost everything I extensively used in the 19902 and early 2000s.

2c: Archimate is not the best for understanding the relationships and constraints between data, processes and systems, I think it's easier and more effectively done with UML

ArchiMate is not the best for modelling data from a logical and physical point of view. I would not recommend use it for modelling data from a logical and physical point of view. From a conceptual point of view ArchiMate can be used to model relationships between data processes and systems.

13

General Board / Re: MDG - Override Attribute Initializers - set value for inherited attribute

« on: October 02, 2025, 07:20:27 pm »

I'm not sure, what you mean by "inelegant way" here... is it how EA itself handles that case?

A more accurate word could be counterintuitive. The goal is to redefine a classifier - e.g., a class - not to define two classifiers and then refine one of them to make it a redefinition of the other. A more intuitive way would be to right click on a class or component, select a a "Redefine" menu item, specify on a screen how it would be redefine -  e.g., through an specialisation, what attributes are inherited, and what are redefined - and create the redefined class or component on pressing "OK/Save".

UML-compliant "redefinition" is a way to do it. :-)

The result may be UML compliant, with the exception that it does not allow specifying that the default value is the result of a redefinition. But it is a very convoluted way of achieving a compliant result.

Which one of the following options do you prefer?

• 2000 + 25 = 2025
• (6!/2) x 5 + 225 = 2025

Sparx EA does too many things, mostly advanced, using ways similar to option 2. It produces a compliant result but it takes a long time to figure it out and verify it. It also gives the tool a bit of reputation.

AFAIK UML standard decides on that:
"The set of members that are inherited is called the inheritedMembers. Unless specified differently for a particular kind of
Classifier, the inheritedMembers are members that do not have private visibility"

Indeed but, AFIK, Sparx EA inherits all attributes by default and there is not an easy way to just inherit some attributes.

14

General Board / Re: MDG - Override Attribute Initializers - set value for inherited attribute

« on: October 01, 2025, 11:43:02 pm »

Just an update, redefinition can be done closer to the UML specification in a very inelegant way.

Quick steps:
1) Create 2 classes A and B
2) Add 2 attributes to class : a and b
3) Create a relationship between classes B and A, with the realisation arrow on the A side
4) Add an attribute to class B: a
5) Edit the attribute and click on the 3 dots next to "Redefined property" and select the redefined attribute from class A. If it needs to be given a default value, specify an "Initial Value"

There is also a "Subsetted Property" which I do not know what it could be used for.

If I had designed this, I would have a wizard that allows me to specialise a class or component, class A in the example, and handle all of this in a single operation.

15

General Board / Re: MDG - Override Attribute Initializers - set value for inherited attribute

« on: October 01, 2025, 11:07:31 pm »

I cannot read Geert's mind but I am not sure the way "redefinition" is done in Sparx EA is elegant or compliant with the UML specification. In particular, "Specifically, any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member."

As far as I know, there is no way to specify a redefinition or substitution relationship between elements - i.e., classes or components - or attributes of a class or a component.