Recent Posts

1

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Eve on September 15, 2026, 09:32:11 am »

depending on the "order" of the stereotypes (although in UML there is no order)

I can't find any information in the UML spec about whether they are ordered or not. But there is some kind of ordering in the spec because if multiple stereotypes aren't applied they are displayed in an order.

- You can't use the field t_object.Stereotype anymore as it now contains one of the multiple stereotype names (and it might be any of them)

And you shouldn't be using it. The API allows access to the full list even if there are properties (on each object) to access that field.

- Metatype determination becomes uncertain

Always the first.

- Shapescript might behave erratic, depending on the "order" of the stereotypes (although in UML there is no order)

Metatype if it's defined and if not then the first.

- metamodel constraints will probably behave in weird ways

Not as far as I'm aware.

- the icon in the project browser/toolbox will be what?

For the project browser it's the metatype. For the toolbox it's a non-issue because a toolbox item can only have one stereotype.

2

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Geert Bellekens on September 14, 2026, 06:02:10 pm »

Oh dear, YAEAB!?! - What am I up against with multiple stereotypes?

Not bugs per sé, but things that are simply nor forseen for multiple stereotypes.
What I can think about is:

- You can't use the field t_object.Stereotype anymore as it now contains one of the multiple stereotype names (and it might be any of them)
- Metatype determination becomes uncertain
- Shapescript might behave erratic, depending on the "order" of the stereotypes (although in UML there is no order)
- metamodel constraints will probably behave in weird ways
- the icon in the project browser/toolbox will be what?

As you can see there are many things that work just fine if you have only one stereotype, but might behave differently when there are multiple stereotypes.
You can offcourse try to take all of these into account, and use different "types" of stereotypes. (e.g. Full stereotype vs tagged value only stereotype) but it is a can of worms I'd rather avoid.

Geert

3

Automation Interface, Add-Ins and Tools / Re: Database Query Restrictions in Enterprise Architect 17.2

« Last post by Geert Bellekens on September 13, 2026, 08:09:20 am »

Hello,

I also stumbled on the issue with Update/Insert via sql and EA 17.2 (disabled).

Is there a way to set e.g. PDATA3 for a Part which points to the original part (if the part is a reference)? In the past I used sql because there is no API (readonly property).

Ok, I can access with native SQL. For sqlite this shouldn't be a big deal.

Other databases aren't always that simple.

Have someone an idea or experiences?

Thanks,

Helmut

I've sent an email to Sparx support, with my list of all the things I use the now retricted methods for, asking for alternatives.

I have yet to get an answer.

I'm afraid I'll have to switch to native database queries at some point.
Upside of that is that this is much much faster than Repository.SQLQuery, and you don't need to worry about the translation into xml.

Geert

4

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Knaldgas on September 13, 2026, 02:22:05 am »

Oh dear, YAEAB!?! - What am I up against with multiple stereotypes?

5

Automation Interface, Add-Ins and Tools / Re: Database Query Restrictions in Enterprise Architect 17.2

« Last post by Helmut Ortmann on September 12, 2026, 06:13:58 am »

Hello,

I also stumbled on the issue with Update/Insert via sql and EA 17.2 (disabled).

Is there a way to set e.g. PDATA3 for a Part which points to the original part (if the part is a reference)? In the past I used sql because there is no API (readonly property).

Ok, I can access with native SQL. For sqlite this shouldn't be a big deal.

Other databases aren't always that simple.

Have someone an idea or experiences?

Thanks,

Helmut

6

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Geert Bellekens on September 11, 2026, 10:53:00 pm »

Using multiple stereotypes on a single element has it's own issues.

I personally avoid that at all costs. A lot of things don't work correctly with multiple stereotypes.

Geert

7

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Knaldgas on September 11, 2026, 06:38:35 am »

I've changed my approach a bit. I have now created a multiple stereotypes, and then let user add relevant stereotypes to their elements (DataType, Component, Node and Association).
Adding multiple stereotypes results in something close to what I want to achieve: grouping of tagged values in a way that allows identical identifiers across groups 

Is there a simple way to have a toolbox have a UML::Component (or something extended from it), but have multiple Stereotype appended to it (StereotypeEx)?

As to the question if it gets too fine-grained: Perhaps. This is a proof of concept, so the result may come to look very different.

8

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Geert Bellekens on September 10, 2026, 07:28:01 pm »

Thanks Geert,

Yes, that's an option for some of the fields.
Any solution if Sensitivity is going to be used several times? E.g. a Node could have Sensitivity on Logs, on Data storage and on Processing.

~Per

I think I would implement that as just several different tags:
- Log Sensitivity
- Storage Sensitivity etc...

Another question is if you should.
Having that much fine grained properties on your model elements is a risk in it own right.
More often then not, there will be an initial initiative to fill in those properties, but I see that those tend to go stale very quickly.

And also, if there is so much data to be filled in, I often see that it's filled in the same for all categories.

What I sometimes propose in those cases is to set a single sensitivity property, and then have another property that indicates the most important category (logs, storage, processing) for wich the sensitivity is applicable.

Geert

9

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Knaldgas on September 10, 2026, 05:47:44 pm »

Thanks Geert,

Yes, that's an option for some of the fields.
Any solution if Sensitivity is going to be used several times? E.g. a Node could have Sensitivity on Logs, on Data storage and on Processing.

~Per

10

Automation Interface, Add-Ins and Tools / Re: Aggregated Enumerations in Profile

« Last post by Geert Bellekens on September 10, 2026, 04:43:40 pm »

That is probably not possible currently.

If you have that same combo in multiple stereotypes, you might want to consider making an abstract stereotype that contains these (grouped) tags, and let the other stereotypes inherit from that.

Geert