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 ... 108
Is anyone using Decision Modelling Notation (DMN) in a serious way?  We've started playing with it, and it sort of works, but we'd really appreciate being able to talk to someone who's "been through the pain".

We got a small Business Knowledge Model (BKM) going and then tried to get it to talk to a Decision (invocation) by using the QuickLinker to add a "Knowledge requirement to" relationship.  When we validate the Decision Model, we get a message saying we are missing a "Knowledge Requirement" link!

Can anyone help?  We need to get some clarity on the fundamentals.


As we move to the cloud, we need to reverse-engineer Azure Synapse SQL databases.  Is there some secret sauce to do this?  Is it even possible?
If so, could some kind soul "spill the beans"?


As noted by Ian Mitchell in MDG Extending 'Package' with a new icon is useful to indicate the package contents via a different package icon in the browser.  While support for this in EA is less than optimal, it served us well up to v16.  We defined package stereotypes and assigned specific icons to them.
In v15, unstereotyped packages were correctly shown with the standard package icon in the browser.  In v16, they often get one of our defined stereotyped icons (seemingly randomly, although it's certainly not the case).

This needs to be rectified (notwithstanding that Sparx doesn't support "package icons") since it reveals incorrect code in v16.


We have extended EAUML::table to allow our version <Profile>::DBTbl to include standard adornments for our diagrams in the shapescript (i.e. responding to additional properties defined for DBTbl etc.)
The extension works quite well, and the Foreign Key mechanism works etc.  But one thing that DOESN'T work (hopefully, yet) is to get the DBTbl to provide the PK & FK indicators on the rendered diagram object.  We followed the instructions for "Create Stereotypes Extending non-UML Objects" and used drawparentshape() but to no avail.
  • Is this actually possible?
  • How can we do it?

When you add a column using the UI Features dialog, the datatype of the column defaults to varchar regardless of the DB technology and whether or not the datatype varchar is available in the list of Database datatype.  Initially, I thought this was because the default database was set to SQL Server (where a varchar is an option), but changing that makes no difference.  It appears to be hard coded.

Where is the default database column datatype set, and why doesn't it respond to the default database technology?


We use DB Builder to reverse engineer our databases.  In this process, we can select NOT to import all schemas, but only those we are interested in.
We normally then use the DB Builder "Show Differences" to ensure that we have got ALL the differences.

Today we discovered a typical problem - self inconsistency!

Although you can select a subset of the schemas on the initial reversal, as far as we can see, there is NO mechanism to do the same for "Show Differences".  This makes the option effectively useless!


If you change the Diagram Type and the new diagram type has a different tiling to the old diagram type, the tiling is NOT changed!
We have started using Background tiles to visually distinguish our different diagram types, so it's awkward when the tiling is wrong after changing the Diagram Type.


We have a convention that if we use a special text "widget" ("<--+-->") in the Item Notes property;  text before the widget represents the normative definitions of something, and what follows the widget is a discursive text designed to help the user understand more about the normative definition and the nature of the item itself.
We have even created a special script to seek out the widget and automatically adjust the Notes size accordingly.  The automation equivalent of [Ctrl+Shift+Y] | Show Element Compartments | [X] Notes ! Element Notes Maximum Notes [<correct value>].  This means the user sees ONLY the normative definition on that particular diagram.

This has worked very successfully over the years.  Interestingly, we haven't used it for Notes items in the past.  Imagine our surprise when we tried this on a Notes item; it didn't respond to the automation (NOR, we discovered to the manual intervention).  A Notes item will resolutely ignore user requests to set the visible Note rendering size.

It is a defect, isn't it?

Bugs and Issues / v16 - Setting Line appearance to [ ] Default - Fails!
« on: August 11, 2022, 01:10:57 pm »
EA's "defaulting mechanism" for lines in the past differed from that for shapes.  For shapes, setting the extrinsic value "-1" in the BorderColor column of the t_object table would cause EA to draw the shape with the line colour as specified in the MDG.  Lines on the other hand would set the value from the MDG into the LineColor column in t_connector.  In both cases, if you changed the "Default Appearance" using the context menus, the value you selected would become the default colour for the border/line.

For shapes, setting the appearance to the Default value in the colour picker sets the value in t_object.BorderColor, back to "-1" and restores the MDG default.
For Lines, however, setting the appearance to the Default value in the colour picker sets the value in t_object.BorderColor, back to "-1", but this does not restore the MDG default; it just renders the line colour in a blue-grey!

This needs to be rectified!  My suggestion (which, I guess, will be ignored) is to make shapes and lines BOTH use the value "-1" to render the border/line in the MDG specified colour.


t_connector holds two columns, SourceTS and DestTS (Target Scope), to represent whether the scope at the relevant end is a classifier or instance.  We'd like to be able to manipulate this via scripting, but there doesn't seem to be a property to achieve this with.  We can access them in shapescripts via <end>.targetscope, and we will render the end differently depending on the value.

Can anyone confirm?  If there is such a scripting property, could a kind soul please advise what it is?


PS: Thomas Killian's (otherwise) excellent "Scripting EA" book, unfortunately, conflates Visibility (Access) with Visibility (Scope) in the Source/Target Properties Window description.

We've noticed that the middle top label transparency can vary on some diagrams.  This can only be really seen if the diagram uses background tiles.  It can vary between different stereotypes of the same type (i.e. functionally identical - as far as we can see - with only some minor rendering differences).  For the SAME stereotype, it appears to be consistent between diagrams.

We'd like to know if this is controlled by some mechanism (other than EAUI) - since we'd like our connector labels to be more consistent.


In the help for Display Element/Connector Properties, we find:
  • source.metatype                      for details of these four source.metatype properties; see the
  • source.metatype.general               Define Metamodel Constraints Help topic
  • source.metatype.specific
  • source.metatype.both
(with the equivalent target versions).
Unfortunately, while the Help defines these, it doesn't describe the values returned and how they may be used in a shapescript.  Can anybody enlighten us on these points?


Automation Interface, Add-Ins and Tools / XGML anyone?
« on: August 08, 2022, 03:08:47 pm »
Has anyone played with XGML reverse engineering into EA?  We have some users who used Graphity to create some diagrams that we'd like to import into EA.


For some of our metatypes, we want to enable the visibility of the Notes compartment when the item is created on the diagram (in Rectangular mode).
We tried using the Templates package to do this, but it doesn't seem to work.

Does anybody know how it can be done?  Via MDG?



On our machine, we have both 32-bit and 64-bit EA installed.  When we try to access any .eapx repository with the 32-bit version, we get the following message when we try to open a diagram.
DAO.Database [0x00000d0e]
Invalid Memo, OLE, or Hyperlink Object in subquery 't_object.PDATA2'.

The diagram opens "Empty" - no diagram objects are visible.  Everything else seems to work OK.  As far as we can tell, there is NOTHING wrong with thet_object.PDATA2 column.  Since v16 64-bit didn't support MS Access, we didn't try.  However, in the last few days, Sparxian Eve mentioned using the  64-bit version of the Microsoft Access Database Engine 2010 Redistributable in another thread.  So we installed it and tried to access the same file.  Success!  No problem!

Does anyone else see anything like this?  It's pretty weird!


BTW: We can't install the 32-bit version of the Redistributable because we have 64-bit office products.

[Edit: Forgot to say that "Alles ist in Ordnung" with v15.2]

Pages: [1] 2 3 ... 108