Book a Demo

Recent Posts

Pages: [1] 2 3 ... 10
1
Coming at your problem from a different angle. The functionality (b in particular) you're describing seems to be redundant.

If I define a tagged value type in the UML Types dialog. Any tagged value (new or old) with that name automatically gets the type specified in the dialog. Nothing needs to be added to the notes of the tag itself to make that happen. Even the new tagged value dialog recognises that match and disables the value field.

There are factors that complicate that simple answer. Adding a AppliesTo or BaseStereotype to the definition limits where the definition can be applied and tagged values where the notes specify their own type won't get overridden.

The tagged values coming from an MDG technology stereotype work in the same way. Any attributes defined on the stereotype become properties as soon as the stereotype is applied (or element is created.) They show in the main Properties window instead of the Tags part of the same dialog and the type of control they display is specified within the MDG Technology file. (See With Predefined Tag Types for the recommended way to set that in your technology and With Predefined Tag Types (Legacy Profiles) for the legacy method.)

All that is to say, your automation appears to be trying to duplicate functionality built-in to EA. If you're not seeing that functionality then that's the problem I would be trying to solve.

2
MDG technologies are stored in the xml file. The individual steroeotypes and tagged values are not stored in the database.

You will have to update your automation to parse the MDG xml instead of relying on the database to get the stereotypes and tagged values.

Geert
3
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
4
We're new to using MDG technologies and UML profiles in our models, and have recently discovered some issues with our existing automation tools and a new data type that was created as an MDG technology.

Previously, we'd been using class objects, with stereotypes and tagged value types defined in the UML Types dialog, and have a number of automations built that, before inserting an element or tagged value, check in the database to a) validate that what's being added is valid and b) to determine the type of tagged value being inserted, to know how to insert it (i.e. if Type=Memo, add to the Notes, not the value, if Type=RefGUID, lookup the ea_guid first, and insert that, rather than the name, etc, etc). We'd been looking at the t_propertytypes and t_stereotypes tables to get this information for the automation.

What we've found, however, is that our new object type that is derived from an MDG technology does not insert stereotype names or tagged value definitions into those tables, which means that validation fails when our automation tries to manipulate these new types of objects. When creating the UML profile for these new types, I'd initially tried creating the tagged values in the UML Types dialog, and adding them to the stereotype object in my profile diagram: but, that didn't create new tagged values in the objects to which that technology stereotype was applied: so I added them as features on the stereotype element, and created dataType / enumeration objects that I associated with the features (and added the "Type=RefGuid; Values=Actor;" string that you'd normally put in the notes in the UML Types dialog into the notes of the data type, and they worked as I'd expect them to - apart from not being in the database table. I'd wondered if perhaps I'd done this wrong (the documentation was a little unclear to me - though I assume that's an understanding issue, not a documentation issue...), or whether this was expected behavior, and I was looking in the wrong place for where these stereotype / tagged value definitions appear in the database?
5
General Board / Season's Greetings to all forum members!
« Last post by Paolo F Cantoni 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
6
Latest News / Enterprise Architect 17.1 - Build 1715
« Last post by sparks on December 23, 2025, 07:44:43 am »
Sparx Systems announces the official release of Enterprise Architect 17.1 build 1715, on 22nd of December

For more information on Enterprise Architect 17.1, please see:
   https://sparxsystems.com/products/ea/17.1/

The release notes can be found in the following locations:
   https://sparxsystems.com/products/ea/17.1/history.html


Registered Users can find download links to the EA installers on the following page:
  https://sparxsystems.com/registered/reg_ea_down.html


To report any issues please use the registered bug report form:
   https://sparxsystems.com/registered/forms/reg_bug_report.html
7
Latest News / Pro Cloud Server 6.1 - Build 168
« Last post by sparks on December 23, 2025, 07:44:09 am »
Sparx Systems announces official release of the Pro Cloud Server Version 6.1, build 168 (PCS 6.1)

For more information on the release please see:
    https://sparxsystems.com/products/procloudserver/6.1/

For a full list of features and fixes included please see:
    https://sparxsystems.com/products/procloudserver/6.1/history.html

Both registered Enterprise Architect and Registered Pro Cloud Server Users can find download links to the PCS installers on the following page:
    https://sparxsystems.com/products/procloudserver/downloads.html


The licensing procedures introduced in PCS 5 are still relevant to PCS 6.1 and are documented on the Pro Cloud Server download page (https://sparxsystems.com/products/procloudserver/downloads.html) under the heading "Installing and Registering Pro Cloud Server v5"



If you need any assistance in retrieving your Enterprise Architect/Pro Cloud Server credentials please contact Sparx Systems Sales Team: [email protected]


To report any issues please use:
    http://www.sparxsystems.com/registered/forms/reg_bug_report.html
8
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.
9
General Board / Re: Document Generation - how to get elements on a diagram to nest
« Last post by Sunshine on December 20, 2025, 10:37:50 am »
Unfortunately if you are generating text within the diagram it will come out flat.
If I want to create a diagram followed by headers and text that is hierarchical I'll create two templates. One for the diagram and another for the text that describes each element. I'll usually have three items in my virtual document. An artifact that contains introduction, model document for diagram template and model document for descriptions.
I did discover that you can create and artifact and within that you can drag and drop diagrams and packages using templates. You can then just go in and do an update later to re-generate. It does reduce the number of model documents but not the templates.
10
You either work with the child-packages/child-elements in your template, or you define the structure yourself using Model Documents.

In some cases I have created multiple copies of the same template, but with a different heading level.
A bit annoying, but only a one-time effort.

Geert
Pages: [1] 2 3 ... 10