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 ... 104
If we wanted to use the TimeAware Modelling cloning functions, is the Element.Clone() and Package.Clone() methods the correct one to call to achieve that?
[Edit: some forum searching has revealed that this is, indeed, the case.]

The documentation doesn't supply any description of the functionality, so should we assume that we have to do all the "leg work" ourselves following the return of the new clone item?

[Edit: any gotchas from those who have "used it in anger"?]


When one first reverse engineers a DB via the Database Builder one can make a selection that filters the DB Items to only those selected.  One such filter (the principal subject of this post/defect) is the ability to filter out system items.

If you then try and show differences (typically) after there have been changes to the operational DB, this option is NOT available.  In a particular case, the System Objects (functions, procedures etc.) suddenly appeared in the differences list.  I admit I hadn't noticed this before, but it is certainly happening with this DB.

Of note is that we transferred this DB RE package between repositories, but I would have expected that the properties of the RE would be somehow attached to the package.

When we saw the system items pop up in the "Show Differences" we thought we should correct it with the "Show DIfferences with Options" menu option, but there was no mechanism to suppress the System Objects.

Anyone else seen this, any solution?


The Resource Allocation Help says:
This checkbox and drop-down list allow linking the end date to the date of a Milestone element that is no more than seven days old. (Milestone elements form part of the structures developed using the MDG Technology for CMMN, the Case Management Model & Notation, which you can access through the Analysis Perspective.)

So I've created a few CMMN milestones, but nothing appears in the dropdown.  What's the secret sauce?


General Board / v15.2 - How to order items on Gantt view?
« on: September 10, 2021, 11:36:15 am »
I couldn't see how to order the items in the Gantt view (specifically by date).
The items are listed in alphabetic order - about as useful as the proverbial "T*ts on a bull".

Did I miss something?


I've often alluded to that famous Castrol commercial where "Boss" tells "Sol"  "Sol, Oils ain't oils!"  meaning what you think you're seeing may not be what you are seeing.

We've started playing with Gantt views.  We added an element and assigned a resource. "Paolo"  (not Paolo Cantoni).  It showed up on the view just fine.

So silly me, I thought it's probably in t_resources.  Had a look, it's empty!  ::)  I know, it'll show up in Configure | Reference Data | Model Types | People | Resources  NADA! :o  So I added another resource in that dialog.

I then added a new element and tried to assign a resource - BOTH Paolo and the new resource could be selected.
Instead, I added a new resource in the allocation dialog "somename" and the Gantt view showed the allocation. Still only the one resource in t_resources.

SOOOOOO...  Where are these resources held in the repository (I suspect in multiple places)?


We have an increasing number of diagrams that use the [X] Use Alias if Available property to render the Alias instead of the Name fields.  We use the incorrectly named "Box" layout tool a lot and use the [Name <ascending)] sorting algorithm to layout the diagrams.  We were hoping that if the property was marked, it would use the Alias to sort (instead of the Name).  This is not the case.  We'd be happy with either using the "effective" name (Alias if available) or add the Alias as another field to sort on.

Please rectify.

As we know, the Note column in (for example t_object)  is a "Long Text" format (formerly Memo) in a typical .eap/.eapx repository and varchar(MAX) in SQL Server.  Via the EAUI (pun intended) we can add "Rich Text"/"HTML" adornments to the text.  These are stored in an HTML-compatible form within the column.
If one displays the column (say with MS Access), we can see the HTML within the "plain text".  When we wich to display the "rendered" output we normally just set the "Text Format" property of the item to "Rich Text" and we get the adornments displayed directly (bolding, colour, underline, italic etc.)

This has worked fine for me for a decade.  But yesterday, when I set the property to "Rich Text", I did get the adornments, but "at no extra charge", I lost ALL the line endings in the query output!  That is, the output was one continuous stream of characters.  Any blank lines or line endings disappeared.

Investigation showed that the line endings could be restored by post-processing the field with a function that replaced all instances of vbCrLf (in this case, for Visual Basic) with <br>.  NOTE: The repository was a SQL Server repository, but I don't think that affects the problem.

Is anybody else seeing this?  Should it work like this?  I don't recall seeing this behaviour before. 
It's not clear where the issue is.  EA, SQL Server, MS Access.   (adding <br> to the Note by direct column update will render the "<br>" visible in the Note)


As mentioned elsewhere, we're successfully using Synchronize Stereotypes on vertices.  We have observed that under some circumstances, it seems the process rectifies the prefix part of the GUID on the relevant t_objectproperties entries.  For example, if we had previously a set of them created as non-MDG based properties, they would have GUIDs that did not have the common MDG-prefix.  After we had converted the tags into MDG properties and executed the "Synchronize Stereotypes" process, the GUIDs now "line up" correctly.

  • Has anybody else noticed this phenomenon
  • If so, is it part of the process?


We have got synchronize Stereotypes "down pat" for vertices.  This allows us to extend the item properties as required.

However, we're finding some issues with the equivalent for arcs.   If we select the arc on the toolbox, sometimes it works and other times it doesn't.  We understand that in order for synchronizing stereotypes to work (even for vertices), the item needs to have the correct stereotype value in both t_object and the extended "Stereotypes" property in t_xref.  We thought that was all that was required (and certainly for vertices that seem to do the job).

Is anybody else successfully using synchronize stereotypes on arcs?


General Board / Floating Licence Server vs Keystore service
« on: August 22, 2021, 09:44:15 pm »
We currently use a Keystore Service (on a server) to manage our Floating licences.  This week, our Keystore Service Server was inadvertently shut down by the Infrastructure Group due to some incorrect documentation.  We have to move the Keystore service from that server.

We have the option of using the FLS part of PCS instead of the Keystore Service for the new environment.  If we only use the FLS (for the present) is there an increased load on the server (as opposed the full PCS)?  As I read the documentation, we can transfer the keystore file from the KeyStore Service to the FLS directly.  Is that the case?


Bugs and Issues / v15.2 - What should [F2] do for vertices on diagrams?
« on: August 13, 2021, 04:00:09 pm »
We are/should be aware that the [F2] key will allow easy changing of the name which is visible on the rendered element on the diagram.

However, suppose we have [X] Use Alias if Available? and the rendered label is showing the Alias?  Would one normally expect the Name to be changed or the Alias?


We are used to being able to set the vertex rendering characteristics in the MDG definition metamodel and having them track in the diagram rendering. [1]
For example, we change the border width from 1 to 2, and the next time we load the repository, the items specified, change from width 1 to 2.

In the case of arcs, this doesn't seem possible.  Even though we set the value of "InBold" to zero (in t_connector) and  LWidth=0; (in the applicable t_diagramlinks) which according to qwerty's excellent InsideEA book should use the default value, the expected thing doesn't happen.

We recently decided to change the line width of a particular arc metatype from 1 to 2.  New arcs are width 2, existing arcs are unchanged.

We ended up having to set the LWidth value to 2 in t_diagramlinks got get the desired result.

Is it possible to have an arc behave in a consistent manner to a vertex in this regard?  Or is it a defect. [2]


[1] That is if the rendering on a specific diagram has NOT deviated from the default rendering.
[2] I have previously reported that it is not possible via the UI to alter the local rendering of an arc.  You can only change the (supposed) "default" appearance of the line (via the dialog), but even then, the colour can change, but NOT the line width!  EAUI!

In the Add elements to package dialog, there is a Type drop-down.

The documentation says:

Click on the drop-down arrow and select the required element type from the list.
The list of element types is derived from the diagram or technology shown in the 'Toolset' field.

What the documentation doesn't make explicit is that to appear on the list in the drop-down, the metatype MUST appear on at least one toolbox in that technology.

Having just spent some considerable time trying to figure out why one of our metatypes wasn't appearing on the list, it would be helpful to make that clearer.


Many of you will be aware that we are using a highly structured metamodel to do (seemingly) magical things with our MDG.  In the past, I have waxed somewhat lyrical concerning how well the mechanism hangs together.  Today, I'm afraid I'm going to hand out a BIG brickbat!

So, using the ArchiMate concept of anything can compose into itself, we have a root definition:  Stereotype "R"
Code: [Select]
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="source.metatype.both"/>
Things work fine over many of the specialized stereotypes:
i.e.   B1 Composes to B2 etc. Q3 composed to Q5 etc.
Then one day I notice that C1 won't compose to C2.  HOURS of debugging reveals that the problem was that stereotype "C" ALSO had a composition relationship to stereotype "D".
Stereotype C had the following in its specification:
Code: [Select]
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="PrIME::D"/>
When we created the composition to "D" in the model we were assuming we were saying:
"In addition to composing to itself, C can also compose to D".

Turns out, that's NOT what happens...
What is implemented is: "Instead of composing to itself, C can ONLY compose to D".

That is, the specific stereotyped relationship obliterates the more general.

This has to be a defect in the mechanism, yes?  If it's NOT, how do I create what we were after?


Many of you will be aware that we are using a highly structured metamodel to do (seemingly) magical things with our MDG.  A significant technology used in this process is inheritance (via Generalization/Specialization).  We are really starting to "kick-ass" with the inheritance of stereotyped relationships.

In the normal conceptualisation of inheritance, there are a number of use cases:
  • Direct "inherited" copy of the feature from the generalization into the specialization
  • Modified (typically renamed) "inherited" copy of the feature from the generalization into the specialization
  • Addition of feature in the specialization

What is not so well known is:
  • Removal of a generalization Feature from the specialization

Inclusion of the removal use case allows for the creation of "Einsteinian Structures"[1]

In the case of Stereotype inheritance (specialization), we have the first three in our metamodel.  It seems to work well (in general).

When considering whether one stereotype is a specialization of another stereotype one needs to consider (inter aia) the degree of overlap of the features.  I believe it is generally accepted that if the degree of common overlap is high enough, then a specialization exists.  But that begs the question how do we indicate that the specialized stereotype may not have one or more features of the generalized stereotype?

When modelling real-world items, we generally handle this kind of thing via the Specialization relationship itself and encode how the mapping between the two ends is to be handled.

To get EA to do this "out of the box" would be tough (if not impossible)!

One idea we've had to indicate that a feature should not be inherited is to create a feature with the appropriate name in the specialized stereotype and set its multiplicity to [ 0 ]!


[1] That follow the Einsteinian dictum:  "Keep things as simple as possible, but no simpler!"[2]
[2] People tend to ignore the second part of the dictum!

Pages: [1] 2 3 ... 104