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.

Topics - Paolo F Cantoni

Pages: [1] 2 3 ... 80
As many will know I've been discussing the notion of Instance vs Classifier in (relatively) recent times (see What is an "Instance"?).
As mentioned, UML Objects only relate to run-time instances of UML Classes and thus unsuitable for the modelling of more persistent instances.

I'm, personally, comfortable with the analysis that ArchiMate based models are primarily composed of (persistent) Instances.  As I mentioned, I believe the two sub-types of such instances are "specific" and "placeholder" (rather than "generic" as mentioned in the ArchiMate specification).  So, other than by use of the name (I suggested using the indefinite article - a or an - for placeholder instances), how can we easily differentiate between the two?

The answer is easy and elegant!  The t_object table has a column "Multiplicity" (But see Fix Multiplicity and Cardinality, once and for all!)

[Multiplicity refers to the potential range of set membership and thus is expressed as a range 0..*, 2..4, 1..1 (reduced to 1).  Cardinality refers to the actual number of items in a specific set.  For example, a motor vehicle may have a multiplicity of 1..20 wheels.  This (specific) vehicle has a cardinality of 6 wheels.]

Anyway, it seems to me that by setting the value of the Multiplicity to 1 (1..1) is an apposite mechanism for specifying that the item is a specific instance.  Any other value (including null) defines a non-specific or placeholder instance.  The shapescript can react to the value of Multiplicity and adjust the rendering accordingly.  Also, background queries and online scripts can also react thereto.



Can we please fix Multiplicity and Cardinality once and for all?

Multiplicity refers to the potential range of set membership and thus is expressed as a range 0..*, 2..4, 1..1 (reduced to 1).  Cardinality refers to the actual number of items in a specific set.  For example, a motor vehicle may have a multiplicity of 1..20 wheels.  This (specific) vehicle has a cardinality of 6 wheels.

The t_object table has two columns "Multiplicity" and "Cardinality".  In typical EAUI, you can ONLY get at the Cardinality via the Element | Properties | Details page and you can ONLY get at Multiplicity via the Element | Properties | Advanced window.  Further, the Cardinality property in the UI is restricted to the values in the Configure | Reference Data | UML Types | Cardinality Values dialog - which is incorrectly named (should be Multiplicity value), whereas the Multiplicity property is NOT. Finally (I've only looked so far...) in the Shapescript Element properties, we have Multiplicity, but NOT Cardinality!  Similarly in the Element Class of the EA Object model!

We are intending to make our Shapescripts react to the Multiplicity value (see ...), so it's fortunate that it's currently available!

Please, can this be fixed and made consistent?

It might be argued that Cardinality doesn't have a place in an Element, but I can see uses therefore - so long as I can specify it correctly (that is, WITHOUT restriction to - or reference to - the Cardinality (Multiplicity) Values).


PS: This may be a record (in over a decade of reporting bugs for EA)!  Seven bugs for on issue!

We are having problems with EA "Hijacking" our MDG stereotypes (on items created via the API) - even though we ONLY have our MDG selected in the lists.

Normally, our stereotype names are encoded (using an algorithm) so that they DON'T conflict with any other MDG technologies.  However, sometimes, the algorithm (as it currently stands) will generate a conflict - as we discovered with "Goal" today.

We have observed, that even with our encoded stereotypes, if a stereotype with the same name (such as Otcm) exists in the general stereotype list, then EA will use the general version (thus the t_xref entry has a GUID, rather than an FQName).  So we try to ensure that such entries are purged.  But since it's not clear as to how these are created it seems to be a post-facto event (the purging).

So, our own MDG is the only one selected and it is set as the active Technology.  Is it, therefore, a bug that under these circumstances, if I get the API to set the stereotype to "Goal", the t_xref entry should be @STEREO;Name=Goal;FQName=<OurMDG>::Goal;@ENDSTEREO;  and nothing else?

As far as I'm aware, I don't need to set the stereotype in the API to "<OurMDG>::Goal" and, indeed, when we do that, we may get a general stereotype of "<OurMDG>::Goal" at no extra charge and with anomalous consequences.

Can anyone advise on how to specify stereotypes to ensure that our MDG is used when setting via the API?


Automation Interface, Add-Ins and Tools / EPPRofile:: ?
« on: December 11, 2018, 05:52:26 pm »
We are having problems with EA "Hijacking" our MDG stereotypes - even though we ONLY have our MDG selected in the lists.

One such was the "Goal" stereotype which ended up in our t_xref tables as: @STEREO;Name=goal;FQName=EPProfile::goal;@ENDSTEREO;
Anyone know where the EPProfile comes from?  BTW- note the change of case in the stereotype.


Automation Interface, Add-Ins and Tools / "option explicit" - does it work?
« on: December 06, 2018, 03:18:08 pm »
Being careful coders, we put option explicit at the top of each VBScript.

We had a weird bug today which we traced down to an undefined variable name NOT being picked up by the option explicit setting.

Code: [Select]
option explicit
dim GoodOne
GoodOne = 10
BadOne = 20
should fail on the second assignment, but doesn't.

We've discovered that if in Debug mode, the option explicit functionality DOESN'T WORK!

So to check for option explicit you need to run the script in a normal manner.

"It's a bug, Joyce!"


Automation Interface, Add-Ins and Tools / Selected Objects Collection Order
« on: December 03, 2018, 12:40:36 pm »
We are reinvestigating Visual Enclosure with some scripts to help with the relationships between the enclosed and enclosing objects.

We have observed that the selected objects collection seems to have a special property.  The objects in the collection appear to be returned in reverse Z-Order.

Is this intentional?  Can we rely on this behaviour?  It seems eminently reasonable that they are returned in that order.  If we can rely on this behaviour we can simplify our code tremendously and determine enclosure in one pass.


We have had issues in the past with EA confusing Visual Enclosure with Nesting.  But we developed a technique that allowed us to visually embed the items on the diagram as required WITHOUT having EA nest them in the browser.

Recently, we have returned to the exploration of visual enclosure and its impact on the model.  (It's a LONG time since we played with any new visual enclosure so it may have always been thus, and we didn't notice it.)

Anyway, we have found that if we accidentally move a visually enclosed item the item will be suddenly (and for us unexpectedly) NESTED under the enclosing item.  We are able to move the items out from being nested to their correct locations (we have specific folder for specific item metatypes).  The visual enclosure is NOT affected.  So we're VERY annoyed with the behaviour (espeically since it can be shown to be theoretically incorrect - particularly in the case of ArchiMate)

Is there any way to stop this behaviour (out of the box)?


Bugs and Issues / Insert related elements- NOT!
« on: November 16, 2018, 12:46:15 pm »
The "Insert Related Elements" functionality needs to be renamed to "Insert Connected Elements" since it does not include some pretty fundamental relationships which are not implemented as connectors, to wit: Nesting and Classification.  The functionality only references elements related to the root element by an entry in t_connector.



We reverse engineered an XSD containing the following:
Code: [Select]
<xs:simpleType name="ISO_3166-1_Alpha-2-Code">
<xs:documentation xml:lang="en">AF AFG Afghanistan</xs:documentation>
<xs:documentation xml:lang="en">AX ALA Aland Islands</xs:documentation>
<xs:documentation xml:lang="en">AL ALB Albania</xs:documentation>
<xs:documentation xml:lang="en">DZ DZA Algeria</xs:documentation>
<xs:documentation xml:lang="en">AS ASM American Samoa</xs:documentation>
<xs:documentation xml:lang="en">AD AND Andorra</xs:documentation>
<xs:documentation xml:lang="en">AO AGO Angola</xs:documentation>
<xs:documentation xml:lang="en">AI AIA Anguilla</xs:documentation>
<xs:documentation xml:lang="en">AQ ATA Antarctica</xs:documentation>
We found only the first <xs:documentation> entry was imported (into the Notes field).  I'm not an XSD guru. Should the other entries have been imported (as additional lines in the field)?


[Edit:  I checked locally and I've been informed that the notation is invalid.  However, I'd like some corroboration that this is indeed invalid.]

Automation Interface, Add-Ins and Tools / Problem building Add-In
« on: October 30, 2018, 03:01:09 pm »
Our (C#) Diagrammer Add-in uses EA.tlb and Interop.EA.dll.  We don't always update these files with the latest releases, so as not to be on the "Bleeding Edge".

We have been running successfully with the build 1308 version since Nov 2016.  But we decided to update to the v14 build 1427 versions.  Imagine our surprise when the following message popped out of VS:
Error   CS0246   The type or namespace name 'EA' could not be found (are you missing a using directive or an assembly reference?)

Since all we've done is to replace the 1308 files with the 1427 files, we didn't expect this.  Is anybody else experiencing a similar problem?

Has anything changed in the files to cause this?    Did we miss something n the way through?


We've been experimenting with the Schema Composer to allow us to generate multiple payload forms from one model.

We've established that the source (base) model (from which the payloads are to be generated) HAS to be a SIMPLE Class Model.  We were hoping to be able to use some of our MDG specific items as the source.  However, it seems that as soon as you stereotype the class, the generated output is changed in a significant way!
(If that should NOT be the case can someone let me know?)
So we appear to have that limitation.  So we then said, OK, let's run a transform to allow us to automatically generate the simple class model from our MDG specific items (initially, just strip the stereotype and see what happens).

It's over a decade since I last used model transform templates and as I recall even then they were a bit problematic.

So, before I waste a LOT of time trying to do the impossible. I thought I'd check here.
  • Can I create a transform to change one class-based model into a similar class-based model?
  • If I just wanted to strip the stereotype from the class to generate the transformed class, what templates should I change?
  • We already have payloads defined as XSDs -which we can reverse engineer.  Can we also use this type of transform to transform from the XSD to a Simple Class (or even our MDG based items)?


We autogenerate our Neighborhood diagrams.  We settled on a default of A3 Landscape and determined that the cx and cy values were 1600x1100.  It's been thus for almost a decade.

However, in investigating the Persistent Zoom functionality, I found that creating an A3 landscape diagram manually created a 1622x1138 diagram.  That got us wondering, is the value entered into those fields driver related?

Is there any impact of printing a 1600x1100 onto a printer that expects 1622x1138?

Is there a standard value for A3 Landscape that may have changed over the years?


Anyone know (and is prepared to share) where the Persistent Zoom is stored?  We're experimenting with this and for some diagrams, it looks like we'd need something smaller than 50%.

Can this be altered?


If we generate an HTML report, we are able to get to specific diagrams from outside the browser by the documented means.

However, we can't do this with EA (whether Full or Lite).  Can anyone confirm that?

We'd like to provide users with the richer EA-Lite experience rather than simple HTML.  But we'd like to be able to provide an external reference (similar to the HTML mechanism).

I guess we could distribute shortcut files, but that seems a bit clumsy and will "pepper" the storage with transient files.



It would appear there is no mechanism for recording which pattern (if any) an item was created or merged from.  We need to record (almost like the «trace» in Time Aware Modelling) so we can correctly manage the evolution of patterns.

I guess we'd have to "roll our own".  However, even this presents a problem.  There is no GUID available to uniquely identify the pattern - even though the name might change.

Any suggestions as to what "best practice" might be?


Pages: [1] 2 3 ... 80