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] 2 3 ... 422
General Board / Re: Status for connectors
« on: December 18, 2018, 10:36:48 am »
Hey, what ... ? Never made it to Australia ?!
Who's been filling my Xmas stocking then ... ??

No, wait ... you must be wrong! Haven't you heard of the six white boomers ??
Matthew is right, he does make it to Oz.  But, if you believe the Christmas advertisements, we ply him with grog and food so he's too p*ssed and stuffed to...


Neither Aggregation or Composition exist in UML 2.0+, they have been preserved in EA for legacy reasons. Of those, only Aggregation exists as an actual type in EA, where Composition is more or less an alias that is often used for a type of aggregation.

In UML, they are just (binary) associations with aggregation set.

From a strict UML perspective. Cmpstn extends association.

In EA, you can set in a profile the aggregation kind at either end to be used when creating a connector. Note that this doesn't prevent the user from changing it or update any existing connectors if the value is changed.
Neither Aggregation or Composition exist in UML 2.0+, they have been preserved in EA for legacy reasons. Of those, only Aggregation exists as an actual type in EA, where Composition is more or less an alias that is often used for a type of aggregation.

In UML, they are just (binary) associations with aggregation set.

From a strict UML perspective. Cmpstn extends association.

In EA, you can set in a profile the aggregation kind at either end to be used when creating a connector. Note that this doesn't prevent the user from changing it or update any existing connectors if the value is changed.
Thanks for that Simon,

I guess we've been using Aggregation and Composition types also for Legacy reasons.  Never really checked it out in detail.

So, to your point about Composition (and Aggregation) extending Association, to check for Aggregation vs Composition, we have to use the DestIsAggregate value (0,1,2) yes?

It seems, as a consequence of losing the Aggregation Type, the "Set Aggregation to Composite/Shared" Context Menu item disappears.  Should It?  (just a question)


My guess is that despite it being available in the metaclasses dialog, Composition isn't a real metaclass. When you try to apply your stereotype EA says something like, "Woah there! That stereotype applies to a composition, but you've got an aggregation here. I can't apply that stereotype." (Equally, it would skip over your stereotype when search without a fully qualified name)

This would explain all the behaviour you have described except for it using your stereotype when a matching stereotype exists in the db.

I can't comment on what change(s) might be appropriate without further investigation about they will impact all users.
So as I understand what you're saying, notwithstanding that "Composition" is on the list, and can be used in a profile using the standard generating process it should NOT be used?

So, what is the official metamodel for specifying a Composition (Composite Aggregation - "Strong" Aggregation) rather than Aggregation (Shared Aggregation - "Weak" Aggregation) in an MDG?

We now have a process that seems to fully manage the creation of Composition arcs but it has a special test for "Strong" arc subtypes and weaves some magic to make sure that the end result is what is required.  On the way through, it changes the arc type from "Composition" - which is NOT a valid Connector Type - to "Aggregation".

However, moving forward (to a metamodel based MDG) we need to sort out a more consistent (and less heavy-handed) method.

BTW, we've found new problems with Composition - now that we have a valid install and are using StereotypeEx with the fully qualified name (and so don't appear to generate a general stereotype any more).


General Board / Re: SysML. Show nested IBDs
« on: December 15, 2018, 01:52:54 pm »
On the diagram above, you can see the "suppressed" arcs in the Set Visible Relations dialog, yes?  Now, drag the C1 item outside the B1 item and you should now see the arcs made visible.  Is that so?  Then drag it back inside, they disappear. yes?

Now in all those scenarios, the "Visible" setting was set to true in the dialog, yes?  That's why I don't use the word hidden but suppressed.

So, there's no way to achieve what you want in the current version.

You can hide the "suppressed" arcs so that they aren't visible when you unenclose the item, but you can't make them visible, while suppressed.

You may care to lodge a bug report using the links below.  Personally, I think it's a defect, that you can't make explicitly visible a suppressed arc.


PS: there may be a cheeky way to (almost) achieve your aims.  Move the C1 item down so that the bottom edge of the C1 item is 1 pixel, below the bottom edge of the B1 item (and thus, normatively, NOT enclosed).  The arc between B1 and C1 may become visible.  I say may because the presence of ports makes things a bit more complicated.

General Board / Re: Tagged Value Type Format
« on: December 15, 2018, 01:30:19 pm »
Thanks, Paolo for your response.

If I create the tag value checklist, can the defined options be populated from a CSV Import?

For example, in EA I add a tag type checklist named "Group Options" with the values: All, Group 1, Group 2;

In the CSV specification file, column heading = TagValue_Group Options. Values in the rows = above-mentioned options.

Does the row value check the applicable box in the defined checklist or is a CSV strictly a text format (i.e, In EA a label is created, Group Options, value = row entry.

It's pretty much strictly a text format.  If you searched the forum you'll see it's a while since I gave up on the Checklist.  Not that it's wrong (well, yes, there are issues with it as I noted at the time); it just didn't suit my needs.  But you should have a look in the t_objectproperties table to see what EA does with it these days.


Not so fast, Batman!

It seems for our setup we haven't quite got the "ducks" in a row.  Our Composition relationship is still problematic.

But based on the last few days, I'm going to take it more slowly.

Following Simon's injunction to Check on a profile created by an EA model, we confirmed that our handcrafted MDG entry for our Composition (Composite Aggregation) arc appeared to be correct:
Code: [Select]
<Stereotype name="Cmpstn" metatype="Composition" notes="" cx="200" cy="100" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
{Image and Icon entries removed for clarity}
<Apply type="Composition">
<Property name="compositionKind" value="Composite at Target"/>
<Property name="direction" value="Source -&gt; Destination"/>
<Property name="_SourceMultiplicity" value="1..*"/>
<Property name="_TargetMultiplicity" value="1"/>
<Property name="_lineStyle" value="orthogonalS"/>
E.g. this stereotype Extends the Composition Metaclass (via the <Apply> entry)

Can this be confirmed, please?  That is, that this arc should behave like a normal Composition.


General Board / Re: Tagged Value Type Format
« on: December 14, 2018, 11:59:55 am »
"Warning, Warning, Will Robinson!"

When we say checklist we normally mean a "multi-option list" where one can optionally select a number of the options - from zero to all.

However, a Sparx Tag of type Checklist is truly a Checklist: a list of items, like names or tasks, for comparison, verification, or other checking purposes.  You check the items off as you go through the process.

So it can't be used for the purposes you are intending.  There also are usage issues with the type as defined, which you should be able to find with a search of the forum.


General Board / Re: SysML. Show nested IBDs
« on: December 14, 2018, 11:53:58 am »
Hi, le-Chiffre,

A couple of things.  What I see on the diagrams is Visual Enclosure, not Nesting, to show composition.  Search the forum for visual enclosure or visual embedding (a previous term - now deprecated) to see the difference.

As such, you are a "victim" of arc suppression with visual embedding.  I say "victim" because what you are seeing is the intended outcome (You don't see the relationship when you visually encircle one item with another).  It's just not what you were expecting.

If you Show Visible Relationships [Ctrl+Shift+I] you should see the "missing arcs".  Unfortunately for you, they will be shown as visible (when they aren't).  There appears to be no way to make them visible again.

Let us know if that is the case, as it could be argued there's a defect in this behaviour.


Automation Interface, Add-Ins and Tools / Re: EPPRofile:: ?
« on: December 14, 2018, 09:25:33 am »
OK, OK, I got lazy "once" and paid the price!  :-[  I normally use Super Finder XT.

Happy Friday, everyone!  8)


I can confirm Simon's statement regarding StereotypeEx.
In my code, I almost never use the Stereotype Field.
After setting the StereotypeEx field I would expect the Stereotype field only to be filled in after updating and reloading the element.

Simons tip about setting the qualified metatype is even better. Should remember to apply that in my own code.

It turns out my local EA 1427 was corrupt!  :-[  Repairing the setup made my machine work consistently with others.

Even after I repaired the computer I was getting anomalous results.  However in the last half an hour, things seemed to have settled down.

BTW: in 1427, Setting SetereotypeEx also sets Stereotype, even before the update.

As to Simon's point about "Strong", I never mentioned Strong.  This code is DEEP inside a library and used for all sorts of arcs.  So we set Subtype to the value passed in, in the call.

As it happens, the behaviour was anomalous when we passed in a Type of Aggregation and a Subtype of Strong, but we think we've now tracked it down to an error in our handcrafted MDG.  We ARE trying to move to a generated MDG.  :)

This code is a VBScript port of code that has worked in VBA (apparently) satisfactorily for nearly a decade.  Hence my perturbation.

It seems I picked the wrong example to start with...  (typical  "Cantoni effect" - point me at a system and I'll find the one anomalous issue)  If I'd started with another arc metatype on a machine with a valid EA install, I might have tracked down the problems myself.

So, believe it or not, thanks to everyone for their help!

I still believe the search algorithm is questionable, but it shouldn't apply if the automation is correct.


I've got it to work EVEN with an entry in the General Stereotypes for "Cmpstn".

However the following VBScript code
Code: [Select]
Set foundConnector = oEAPackage.Connectors.AddNew(gs_EMPTY_STRING, sConnectorType)
foundConnector.Subtype = sConnectorSubtype
foundConnector.ClientID = orginEAElementID
foundConnector.SupplierID = destinationEAElementID
foundConnector.StereotypeEx = "MDG::" & stereotype
foundConnector.Stereotype = stereotype
foundConnector.Name = name
Session.output "6St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="
on error resume next
Session.output "11St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="

Generates the following output:
6St=Cmpstn= StEx== FQS==   
11St=Cmpstn= StEx=Cmpstn= FQS=MDG::Cmpstn=

(for all the 5 arcs in the loop)

Note the change in ordering of the setting of StereotypeEx vs Stereotype

Anybody care to explain the differences in output?

As an experiment, I then commented out the "foundConnector.StereotypeEx = "MDG::" & stereotype" line.
By now, it won't be a surprise to you that it STILL worked!

Final (and further testing - taking time out of my day job) has revealed that if the General Stereotypes entry for "Cmpstn" is NOT present, EA will create one, and (as noted in previous posts) the first will be a GUID and the rest MDG correct.  Whereas, if the General entry is present, all 5 will be correct!  That's why nos 2-5 are correct!

I await someone to tell me I'm not doing it right or that EA is making apposite decisions.


BTW, In this repository, User Security is NOT enabled so I can't disable Configure Stereotypes.  In any case, we're talking about automation, not UI stuff.

The Help system says:
The system checks the loaded and enabled Profiles and Technologies, and the Stereotypes table, for a  stereotype with a matching name and base type. If it finds a match, it links to that stereotype and applies the effects. If it doesn't find a match, it creates a new stereotype name in the Stereotypes table and links to that - the stereotype acting as a simple label.


If you don't want the element's stereotype to match with an identically named stereotype located by the system, either:
     -  Disable the Technology that owns the stereotype
     -  Unload the Profile that owns the stereotype, or
     -  Delete the stereotype from the stereotypes table
If you do want the stereotype to match to a specific stereotype in a Profile or Technology, load the Profile or enable the Technology.

AFAIK, I did all these things (In spades - since the ONLY enabled Technologies was our own) and EA still got it wrong!

What is the rationale for finding a match OUTSIDE the scope of the action when there IS a match within the scope?  AND, as per my previous post, getting a different answer in the same loop!

Rita Mae Brown (apparently NOT Einstein) said:  “Insanity is doing the same thing over and over again and expecting different results.”
Sending someone else insane is “Doing the same thing over and over again and providing different results.”


NO, I specifically excluded ALL but my active MDG
You prevented them from showing in the toolbox etc. That's all that option does. The other technologies are explicitly still available to ensure existing models using them still appear correct.
That's a strange use of the term "Active".  I thought unmarking the MDG list stopped the toolboxes from appearing.  Since you can ONLY set ONE of any enabled MDGs to be active I would have thought, by definition,  "All enabled MDGs are created equal, but the active MDG is more equal than others".  But in these post-truth times, I guess anything goes.

I understand (and agree) that the other technologies should be available to ensure existing models still render correctly.  BUT we're NOT talking about existing models, we're talking about new arcs!  Surely, EA should try to match the stereotype in the MDG of the diagram the arc is being created on?  If not, then we're really NOT on planet Sparx.

If you need any more proof that "She Brok"! (as my mum would say...)

We have code that creates 5 composition arcs in a loop.  Before the test, the general stereotypes are cleared of the specific MDG related uniquely named stereotype ("Cmpstn").  The test is run and "lo and behold", the first arc (by ID) creates a new general stereotype whose value is the unique name "Cmpstn" and the arc is created with a t_xref entry referencing a GUID.  Now for the REALLY BROK bit... The subsequent 4 arcs have been created with the correct MDG FQName t_xref entry!  Go figure!

What a way to build a battleship!

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?
The concept is easy. The problem is that your definition doesn't match the actual definition of that option.

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).
From 1425, EA blocks creation of new stereotypes containing "::". You shouldn't see them created. The other thing I would suggest is to disable the Configure Stereotypes for all users. This will prevent extra stereotypes being defined from typos etc.

As Geert said, always use the fully qualified name. If you don't, EA will try to guess your meaning. And it will probably get it wrong.
Where is the use of the fully qualified name documented?

So I tried to do what is suggested in VBScript
Code: [Select]
foundConnector.Stereotype = stereotype
 foundConnector.StereotypeEx = "MDG::" & stereotype
Setting the breakpoint at the second statement, foundConnector.Stereotype is set to the value of the Stereotype ("Cmpstn").
After the StereotypeEx assignment, both foundConnector.Stereotype and foundConnector.StereotypeEx are set to empty string!  I'm assuming that's NOT supposed to happen.  So what, if anything am I doing wrong?


PS: the caching issue around scripts and debug vs non-debug mode aren't helping and adding to the exasperation!

General Board / Re: No XSD type found for: "XType" Defau is: xs:string
« on: December 13, 2018, 09:29:29 am »

10 years is nothing to a man with a portrait in his basement :-)
Especially on planet Sparx.

EA even provides a special theme for Dorian.  ;)


A bet a bottle of beer against a Beetle that it won't be fixed in 5 years.

Not gonna take you up on that!

I posted mainly to see if in 10 years "is still brok" (Italglish for Broken).  It's been brok for the last 10 years, I'm sure.


Pages: [1] 2 3 ... 422