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 - Paolo F Cantoni

Pages: 1 ... 4 5 [6] 7 8 ... 415
We're looking at possibly intercepting EA when a user attempts to visually embed one item "into" another.  However, looking at the list of Broadcast Events, I can't see anything I can leverage to detect an attempt at visual embedding.

Can anyone suggest a mechanism that we could use (even outside EA) to detect the "dropping" of one item into another or the removal of a visually embedded item out of the encompassing item?


General Board / Re: Deployment Diagram questions
« on: June 22, 2018, 11:39:50 am »
Hi Matthew,

An interesting question.  Certainly, from a theoretical point of view, the change should flow through from the Classifier to the Instance.  However, in an enterprise situation where a modeller may not be aware that others have created such instances, it should NOT flow through automatically.  The tool should observe that there are instances (optionally list them) and ask if the change should be flowed.  It may be, as qwerty suggested, that the original model may have been slightly defective and just changing the Classifier type may be injecting more issues.


Personally, I try to use the virtual connectors whenever I can, but I agree that their implementation is "weird and buggy". Before they existed, my work-around was to create 2 separate diagrams, then place one on the other as a diagram frame, using the "Hidden" option. A little clumsy to edit, but the effect is to allow multiple instances of the same element on one diagram, and it shouldn't compromise your model integrity.

They're NOT "Virtual connectors" they are Virtual Connector Ends.  The distinction is very important!

While they are called Virtual Connector Ends, they create REAL objects on the diagram.  In my view, one of the major problems with the current implementation is that while they create REAL objects on the diagram - you can move them around etc. - there is NO real diagram object created in the repository!  From this design flaw flow a lot of the "bugs" (user experience defects) I have reported.


Hi Ronald,
qwerty is correct, objects don't have attributes.  They have "slots" and as such the semantics are equivalent.  He is also correct that you should be using associations and role names.

Looking at your "object" model, I see numerous issues with it before it is in a fit state to create the "Link to Element Feature" functionality you are after.

Also, be aware that the question of what is a Classifier and what is an Instance (note I didn't say Class and Object) is not straightforward.  I have a number of posts - some in the fairly recent past that touch on this.  This is exemplified by some of the issues I see in your model.


Bugs and Issues / Re: Default connector line style
« on: June 21, 2018, 06:25:25 pm »
You can set default line styles on a per metatype basis in the MDG.  We've done that with ours.  "Flowy" relationships tend to be Orthogonal Rounded, "associative" relationships tend to be Orthogonal Square, Specialization relationships tend to be Tree Vertical.  But we can adjust as we like for each metatype.


General Board / Re: Lock Root Node
« on: June 20, 2018, 10:42:52 am »
Hi Simon,

I know you've probably touched on this before, but can you elaborate on the meaning of Security Level.   The definition of "Level" in our Ontological model is: A position on a scale of intensity or amount or quality.  A relative position or degree of value in a graded group
This implies that if you can see records at one level you can see the records in the level(s) below.  However, as  I read the explanation in the link, it may be that the 'levels' (Sparx's quotation marks, not mine) are actually independent.  Thus if you can see records in Level X, you can't see records in any other level.

Which is it?


We have a number of relationships defined in our QuickLinker between relationship metatypes and various element metatypes.  Under v13.5 the Quicklinker displays them as appropriate.  Under v14 with the SAME MDG file, they are missing.



There are XPDL to BPMN translation tools, you can then import the BPMN. See (tip, select 'translate')

Or you can pay someone for a full translation service, see:


So I got a .bpmn file (via the BPI) but it looks as if I'm NO closer to importing a .xpdl export from ProMapp.  Has anyone done it?


[Edit: IGNORE this post (except as how to NOT fall into the "trap for young players")!  I'd accidentally disabled the BPMN 2.0 MDGs and so, naturally, didn't have the BPMN 2.0 import menu item in the Publish | Technologies | Import menu".  THe .bpmn file imported without issue.  I'll put it down to a "slip of the mind!]

Suggestions and Requests / Re: Package Indicator for Here Be Locks
« on: June 18, 2018, 10:18:49 am »

Even with resetting the locking of items within the entire repository every night to ensure correct locking by package, EA occasionally ends up in an anomalous lock.  SO being able to see any lower level anomalies reflected up the tree would be useful.


Bugs and Issues / Re: EA14: Archimate shapescript / rendering issues
« on: June 14, 2018, 03:29:18 pm »
In build 1422

"ArchiMate 3

    - Quicklink behavior updated to set aggregation kind for Aggregation and Composition connectors
    - Connector validation rules updated:
        Specialization, Aggregation and Composition connectors now validate correctly
        Flow and Triggering connectors no longer report as not UML compliant"
I've been about to report a bug related to Aggregation Kind and the QuickLinker, but when I saw this I thought the bug might have been fixed.
We have our own MDG that has Aggregation and Composition relationships.  If the user drags the relationship between the two shapes and selects the appropriate relationship type, the aggregation kind is set correctly (because our MDG specifies it correctly).   However, if the user then uses the [F3] functionality, the Aggregation Kind is NOT correctly set and consequently, it can't match to the MDG and creates a spurious <MDG>::<Stereotype> entry in the local Stereotypes list.  Causing all manner of havoc.

Can anyone confirm before I submit a bug report?


I believe it's basically a standardization of our profile.
Hi Simon,

Can you clarify that?  In b1421 of the ArchiMate3.xml MDG file, ArchiMate_BusinessPRocess is  <Apply type="Activity"> which implies it extends "Activity", not "Class" as shown in Table 7-4. Business Layer Behavior Concepts of the ARCH document.


When a tag is added to a stereotype in an MDG using "Edit with profile helper", the features/attributes window does no synchronize properly
=> the new tag does not show in the list of attributes.

Hi Alain,

I think this is an example of a more general problem. I've also seen attributes not update correctly until you move focus.  This has changed since v13.  I think it was Uffe who asked that the WHOLE dialog be fixed.  The selection of portions of the edit boxes is abysmal and infuriating.  (Try double-clicking to select a word in the Attribute name field)


Hi Uffe,

We solved this problem by having multiple paths/environments (similar to the concept of Dev, Test, Prod)  MDG developers have paths that point to their local machine. Power users have one common path, general users have a different general path.

The MDG is "promoted" from one location to the other as testing/validation proceeds.

It's, perhaps, less than optimal. But we haven't found too many problems with this approach.  We've found enough problems with trying to switch MDG versions via the dialog that this is the easiest process.  The MDG is just slip-streamed into the appropriate folder and activated the next initialisation.


General Board / Re: Import Database Schema and Foreign Keys
« on: June 11, 2018, 12:37:36 pm »
I completely agree with what you have said. Unfortunately the system is quite old (10+ years) and those who created the physical tables, for some reason, decided not to define foreign keys.

We do not have the luxury of forward engineering the changes at this point. I was wondering if Sparx had something which prevents overwriting the relationships already defined in the model or add only those tables from the database that are new/modified.
Hi Raju,

We have a similar problem (and in this case, the third party software is pretty current).  From what we can see, there are over 2000 tables without a single Foreign Key Constraint!

Now to your question.  As Geert says, you are (by reverse engineering) creating a physical model.  Consequently, every time you reverse engineer, what you should end up with is a "copy" of the physical DB.  If you want to create things that DON'T exist in the physical model, then you either have to be able to forward engineer the changes to the physical DB (and thus make the reality the same as the updated model) or you have to change something other than the physical model - because otherwise you can't update the physical model.

About a decade ago, we came to the conclusion that there are TWO models at the physical level.  The Design Model (what we want to see in the DB) and the Implementation Model (what is actually in the DB).  The Design Model is only ever forward engineered and the Implementation Model is only ever reverse engineered.  The two models can (because they are at the same level of abstraction) can be compared and contrasted.

The process we generally use to create the Design Model (where there is only an implementation model), is to export the Implementation Model and re-import changing the GUIDs and tracing back to the implementation model. We can, therefore, make changes (such as you intend) to the design model and that's what we use in normal circumstances.

In any event, since (as I understand it) you can't change the physical DB, you aren't creating Foreign Key Constraints in the implementation model, but merely documenting dependencies between the columns in various tables.  You may "get away with" creating your relationships as Dependencies which might NOT be affected by reverse engineering.


Bugs and Issues / Re: Tag values mixing groups (ver 13.0)
« on: June 07, 2018, 09:44:59 am »
It worked! the solution is:
1) Apply the undesired stereotype by drag&dropping from the Toolbox pressing Ctrl over the conflicting element.
2) Uncheck the desired stereotype from the checkboxes in the Stereotype attribute of the element. At this point, the tag values are all grouped in the wrong stereotype group, but are all in the same group.
3) Apply the desired stereotype by drag&dropping from the Toolbox pressing Ctrl.
4) Uncheck the undesired stereotype from the checkboxes in the Stereotype of the element.
Hi Arquesoft,

I thought yu had already done that procedure...  What you have defined is the standard process for manually redefining a metatype.  If you don't do the steps of making sure you have cleared the StereotypeEx properties (where you unmark the checkbox of the non-current stereotype) then EA doesn't recognise the metatype correctly (Ask me how I know?  ;))

Anyway good to see you've solved it.

My issue, I now recognise is not the same as yours, is that the order of the Groups seems to vary between metatypes even though the same groups might be involved.  But I'll do more checking.


Pages: 1 ... 4 5 [6] 7 8 ... 415