Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - adepreter

Pages: 1 2 3 [4] 5 6 7
Bugs and Issues / Virtual Connectors do not execute Shape Scripts
« on: December 13, 2017, 03:28:10 am »
When we create a virtual connector, only the original item is displayed as requested by the shape script.

The ghost is ill-mannered as it simply ignores the shape script. I mean the ghost doesn't bother and it shows as a UML element.

Is there a trick for taming the ghost in the shape script or is it simply a bug?

If it is a bug (ghosts can also have bugs), will this be fixed for version 14?


Users very often have to maintain several diagrams that share common elements including their layout.

When we drag a source diagram 1 into target diagrams 2 and 3, one additional option (besides "diagram frame" etc...) would be to
- drop the laid out source diagram objects from diagram 1 into the target diagrams 2 and 3 (not a picture)
- keep the target diagram layout synchronized with the source diagram layout
That way, in each target diagram 2 and 3 we can re-use the layout of the source diagram 1 and add specific elements and connectors.

In other words, in each specific target diagram, we should be able to re-use a source diagram as a "dynamic layer of connectable diagram objects".

Example 1:
- Shared/Common part of the diagram:  Business Function Landscape
- Specific diagrams: Information owned by functions, Organizations performing functions, Applications supporting functions, Domain architect in charge of function, functional heat map, roles that belong to functions...

Example 2:
- Shared/Common part of the diagram:  Organization structure
- Specific diagrams: Organization Managers, Organization Locations, Organization-owned Applications

OK Simon :)  Indeed it could be fixed only by improving and simplifying the UI and the configuration features (though I still believe it would be simpler to have UML, BPMN or whatever language defined altogether from scratch).

At the end of the day, users of our MDGs would be happy if they had...

a) A single list of properties (not tag) which are editable either in shapes, in property windows or in catalog sheets.

b) Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

c) Quick links which are transparently derived from the metamodel (without these extra quick links that we cannot get rid of).


(a) would require some filter defining which properties and tags need to be visible, in what sequence and for which role
The catalog sheet (like a spreadsheet) would require some sort of element lists which are dynamic and editable. Dynamic legends could also be applied for creating catalog heat maps.

(b) and C) can be implemented either using a metamodel or a language metamodel. For example, we implemented the second option in this language metamodel:

The advantage of a language metamodel is that it can be more easily used for language documentation as it is easily understandable by modelers.


Sparx shines thanks to its UML implementation. But the focus on UML and low levels abstractions is also an impediment.

We should be able to create languages without any UML profile.
The user experience, the architecture and the implementation of Sparx might be simplified if languages could be defined independently of UML.

We should be able to create elements, connectors, properties, shapes, metamodels and other consistency rules from scratch.

The language author would create
- Element and connector types (no stereotype)
- Properties (not tag)
- User-defined shapes (not derived from any UML type)
- Properties validation rules (including but not limited to enumerations)
- A metamodel (defining possible combinations of elements and connectors)

The end user of the language would enjoy a simplified user experience user i.e.
- Element and connectors types (no stereotype)
- Properties (not tag) which are editable either in shapes, in property windows and or in catalog sheets (result sets)
- Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

UML (and legacy UML profiles) would be languages as any other.

When we lock a package, and the locking gets propagated into the elements in the package, other individuals or groups shouldn’t be able to change or delete connectors connecting elements in the locked package.

In other word, when an element is locked, its connectors should be implicitly locked as well.

Note that this could also be an option, in which case you need different types of locking.
So this is for you an opportunity to use the field LockType in the table t_seclocks.
Today this field is always empty.


Automation Interface, Add-Ins and Tools / Paste diagram objects by code
« on: September 18, 2017, 07:46:57 pm »
Selecting diagram objects seems to be OK: The Diagram class has a collection property called SelectedObjects that we can read and write to.

But I can't find a way to paste the selected data objects into another diagram (by code).

Any idea?

Thank you all for your useful answers

When we mix different types of element... in some cases (it seems random), we are no longer able to move SOME elements (not all of them) up and down by using CTRL-Up or CTRL-DOWN or by using the menu option "Move up" or "Move down" on the element.
In addition, the option 'Content / Reset Sort Order" does not sort these elements.

Any idea how to resolve this?

Thank you in advance,

Automation Interface, Add-Ins and Tools / Protecting some MDG
« on: March 09, 2017, 08:47:32 pm »
If we want to make a product out of an MDG, what is the best way to protect it from reverse engineering?
- MDG as part of the database?
- MDG as part of an add-on?
- ...?
Thank you in advance

Thank you. That sounds like a good idea. We will give it a try.

Is there any way to update elements programmatically even when they are locked?
This is needed when a language gets migrated (Stereotype, tag name changes...).

As an alternative, how could we
- Save the locks to a file
- Release all locks
- Reload the locks from the file

Is there any option to define the lookup package for each tagged value type of type RefGUID or RefGUIDList?
The syntax for defining tagged value type is: Type=RefGUID; Values=Activity;Sterotypes=MyStereotype

We are looking for something like an extra tagged value type specification like "Catalogue={some refGUID of a package}"
Type=RefGUID; Values=Activity;Sterotypes=MyStereotype; Catalogue={some refGUID of a package}

PROBLEM when using multiple Tagged Value Types of type RefGUID or RefGUIDList :
When the value of a RefGUID or RefGUIDList tagged value is not set, The lookup always starts from the last accessed package location for all tags.
This makes the option of using RefGUID and RefGUIDList unacceptable for our end users.

We have detailed connectors that realize summary connectors. This is expressed using a connector to connector realization relationship.

    / \

Based on a selected connector (SC), I would like to create a script providing zoom-in/zoom-out behaviour :
- Find "connector to connector" connectors (CCs) starting from the selected connector (SC)
- Find target connectors (TCs) at the other end of each "connector to connector" connector (CC)
- Open diagrams that contain the target connectors (TCs) and select the target connectors

Using the connector API (

- how can we figure out that the client or supplier is another connector?

- if the client or supplier is a connector, how can we get a reference to that connector? Would the Client/SupplierID then be the ID of a connector?

Suggestions and Requests / Re: Deprecation warnings
« on: November 17, 2016, 02:28:14 am »
We use the nesting connector heavily in our Enterprise Architecture MDG to indicate ownership and to make this visible in the traceability window.

This is very useful e.g. when we want to distinguish the cases where an Application, an Application Component or a Data Store...
- *Owns* Data Objects (golden source)
- *Is composed of* Data Objects (the app, app comp or data store contains the data object bit is not the golden source)

Please don't shoot the nesting connector (even if you remove it from the UML toolboxes). Our MDG and its army of robots changed Sparx into a very competitive EA tool. I will not be able to share things if you change them into dust.

Related feature request: The ability to specify, in an MDG, the verbs appearing in the traceability window (the implementation approach was provided with the request). If you implement this then we would at least be able to compensate any connector type that you would remove. So that would be to the benefits of everyone.


Pages: 1 2 3 [4] 5 6 7