Messages

1

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.

2

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.

3

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.

4

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.

5

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

« on: October 01, 2025, 07:47:23 pm »

Unfortunately there are many, way worse issues on the level of "broken" or "actively harmful"

That sounds a bit scary and off-putting.

I have a stereotype, say Server, that extends a Node.  That Server has attributes like IsPhysical that can have value s Yes/No.  Now, I have another stereotype, called Some Server that extends server.  It has its own properties, but inherits IsPhysical.  I would like to be able to specify use of specific value for this IsPhysical.
I have tried using Override Attribute Initializers, and it shows nicely in the profile diagram, but does not actually set value for the property when creating a new instance of the Some Server.

I agree with this but I have given up hope of getting any improvements on how Sparx EA handles inheritance, specifically attribute inheritance.

What I would like to see are things like being able to

• assign default values to inherited attributes (as per the original post)
• select what attributes are inherited or not
• be able to include inherited attributes in the documentation (not sure if this is possible)

The other thing that catches my attention about the OP is that it may be able to solve the problem through instantiation. But he more I used other modelling languages - e.g., ArchiMate - the less comfortable I am with instantiation.

6

Uml Process / Re: Multiple versions of a Component

« on: September 25, 2025, 08:03:35 pm »

This indeed looks a PLE or feature release problem, as noted by PDC.

Although I agree with this comment from Geert, it was actually the first thing I thought about.

The problem I have with all of your approaches, is that it results in multiple elements all representing a single component.
Now if I want to get a complete view of the impact of this component, I somehow have to merge all versions of this component together.

I think that you need to consider a couple of additional things:

1) Are any features going to be developed in parallel? If they are, I would not use multiple components or packages.
2) Are any features going to be developed sequentially, supersede existing features, and released as separate versions? If they are, I would use multiple components or packages.

For any features developed sequentially and released as separate versions, if you have a starting baseline component architecture I would suggest cloning baseline components as a new version to track their evolution overtime.

Three other comments/considerations are:
3) What modelling language are you using? UML and SysML are very different from ArchiMate. I think your approach needs to be adapted to your modelling language.
4) Packages in Sparx EA have a dual personality, they are elements and folders. This adds additional complexities to problem like the one you are trying to resolve.
5) As hinted by Geert, Sparx EA has no mechanism to merge features into a new baseline. (But cloning as a new version can be used to split a baseline).

7

General Board / Re: Dumping a production database into a staging environment - recommendations

« on: September 25, 2025, 07:37:27 pm »

Azure RDS could be adding additional complexity to the what you are trying to achieve.

We have a similar setup using MSSQL but hosted on Azure VMs, our equivalent of our STG environment gets refreshed from PROD every 2 weeks using a SQL Agent job, the job does not take long to execute, the job restores the latest PROD backup to the STG environment overwriting the current version.

Azure SQL Database does not support SQL Agent but Azure SQL Managed Instance does.

8

Automation Interface, Add-Ins and Tools / Re: Script to convert elements from UML to ArchiMate

« on: September 18, 2025, 11:04:35 pm »

This gets better by the minute, the script now works fine with or without using using Repository.GetElementByID. The scripts have not changed, only the day has changed, including disconnecting and reconnecting the laptop from the network and logging in without restarting the computer, it even applies the right colour fill.

I am officially happily confused. Only explanation I can think of is that Sparx EA was somehow caching the script.

9

General Board / Re: Resetting element appearance to default after switching from UML to ArchiMate

« on: September 18, 2025, 10:45:52 pm »

Sorry if I have not articulated the question unambiguously.

Out of the box any ArchiMate elements in the application layer are rendered by Sparx EA with a blue/blueish fill. Somehow I was expecting that after manually converting,  without using a script, an existing element to ArchiMate application element, the right fill will be applied after saving and reloading a diagram, or after saving, closing, and reopening the diagram.

The fill never changes.

10

Automation Interface, Add-Ins and Tools / Re: Script to convert elements from UML to ArchiMate

« on: September 18, 2025, 04:50:04 pm »

Setting stereotypeEx clears all stereotypes and sets it to just one.

I was expecting this but stereotypeEx doesn’t clear the stereotypes.

If you are thinking of creating an MDG extension to archimate let me know. I have one.

We are thinking about creating an MDG extension of ArchiMate. Please feel free to DM me.

11

General Board / Re: Resetting element appearance to default after switching from UML to ArchiMate

« on: September 17, 2025, 11:47:37 pm »

We were initially running this from the UI, including, at some point, closing and reloading the diagram. Have also tried the scripts, including a save and refresh of the current diagram, the result is the same, the colour fill of the changed elements does not automatically change.

12

Automation Interface, Add-Ins and Tools / Re: Script to convert elements from UML to ArchiMate

« on: September 17, 2025, 10:32:10 pm »

Thank you for both of your contributions. After making changes to the scripts based on a variation of both your contributions, it appears that the new target stereotype gets added to any existing element stereotype and as a result the type gets changed to a "Class".

In other words, using this adds an additional stereotype to the element being converted.

Instead use .StereotypeEx, and pass the fully qualified stereotype.

Somehow, I was expecting this code to do the trick but it does not.

VBScript

Code: [Select]

if item.FQStereotype <> targetSteretoype then
item.StereotypeEx = targetSteretoype 'stereotype
dirty = true
end if
JScript

Code: [Select]

var dirty = 0

if (element.FQStereotype  != newStereotype)
{
element.StereotypeEx = newStereotype;
dirty = 1
}
It is looking like somehow the existing StereotypeEx  needs to be cleared.

Do I need to set element.StereotypeEx to "", update the element, and set the new stereotype?

Please keep in mind that we have not developed the new MDG out, at the moment we are testing how to translate existing content to ArchiMate.

13

Automation Interface, Add-Ins and Tools / Script to convert elements from UML to ArchiMate

« on: September 17, 2025, 02:15:47 am »

Trying to get some scripts written to converts element from a UML based MDG to an ArchiMate based MDG.

Let's take What I thought will be a simple example, converting a UML Component with a stereotype of "System" to an ArchiMate "Application Component" - i.e., an element with a stereotype of "ArchiMate_ApplicationComponent".

At first the scripts worked fine but then things got unexpectedly weird.

There are 2 scripts in play:

Code: [Select]

!INC Local Scripts.EAConstants-JScript
!INC DAF2.daf2_Element_Utilities

/*
 * This code has been included from the default Diagram Script template.
 * If you wish to modify this template, it is located in the Config\Script Templates
 * directory of your EA install path.
 *
 * Script Name:
 * Author:
 * Purpose:
 * Date:
 */

/*
 * Diagram Script main function
 */
function OnDiagramScript()
{
// Get a reference to the current diagram
var currentDiagram as EA.Diagram;
currentDiagram = Repository.GetCurrentDiagram();

if (currentDiagram == null)
{
Session.Output("Please open a diagram and select an element.");
return;
}
else if ( currentDiagram != null )
{
// Get a reference to any selected connector/objects
var selectedObjects as EA.Collection;
selectedObjects = currentDiagram.SelectedObjects;

if (selectedObjects.Count == 0)
{
Session.Output("❌ No elements selected in the diagram.");
return;
}

Session.Output("🔁 Processing selected elements in diagram...");

for (var i = 0; i < selectedObjects.Count; i++)
{
var diagramObject = selectedObjects.GetAt(i);
var element = Repository.GetElementByID(diagramObject.ElementID);

if (element == null)
{
Session.Output("⚠️ Skipping: could not retrieve element at index " + i);
continue;
}

Session.Output("✅ Converting '" + element.Name + "' (Component) → ArchiMate_ApplicationComponent...");

// Use utility function
convertElementType(element, "ArchiMate_ApplicationComponent", "Component");
}
}

currentDiagram.Update();

Session.Output("✅ Conversion complete.");
}

OnDiagramScript();
And

Code: [Select]

function convertElementType(element, newStereotype, newType)
{
element.Stereotype = newStereotype;
element.Type = newType;

    // Clear custom style overrides (optional)
    element.StyleEx = "";

    element.Update();
}
I thought the original test was successful but I am having my doubts now because the scripts does not change the type or stereotype and must be missing something obvious I cannot see.

14

General Board / Resetting element appearance to default after switching from UML to ArchiMate

« on: September 17, 2025, 12:09:59 am »

We are in the process of trialling what will become a new ArchiMate base MDG. Part of trial as mentioned elsewhere in the forum involves cloning the UML baseline, creating new versions of elements and changing their types to an out-of-the-box ArchiMate type. The process works well within reason but there is one annoying glitch: the appearance of the elements does not change, we have not yet found a way to reset the appearance to the default ArchiMate settings.

Have we missed something?

P.S.: We are still on version 16.X (64 -bit)

15

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

« on: September 16, 2025, 07:49:29 pm »

We are experimenting with ArchiMate to model complex data integrations involving multiple systems/applications. Essentially we are presenting integrations as Application Collaborations, and categorising them as manual or automated. Any automated integrations involve a pair of collaborations interactions, one creating the data payload and another processing the data payload. Data payloads are represented by (Application) Data Objects.

We are also experimenting with using Application Interfaces to represent the actual application component producing the data payload.

I have tried to use UML for this in the past and it becomes very easy to get lost in the weeds. Although, I fully get why they are important.

Hopefully, you find this helpful.