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 4 ... 79
16
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.

Reported,
Paolo

17
Automation Interface, Add-Ins and Tools / Oracle Reverse Engineer
« on: May 28, 2018, 02:55:51 pm »
One of our users is trying to reverse engineer an Oracle DB.

We're usually a SQL Server shop, so I haven't done one of these for ages.  Using b1351, he seems to be doing all the right things on the Import from ODBC dialog.  Are there any "gotchas", "secret sauces" that we should be using?

The result is that after asking it to reverse engineer everything, for the tables, we get the table objects, no features or relationships - just empty boxes...

TIA,
Paolo

18
From the help...

To set the layout type you use the layoutType attribute, which must be set in the initialization attributes section of the script; in other words, before any of the methods are called. Valid values for this attribute are:

  • LeftRight - Shapes with this layout position the sub-shapes side by side, with the first added on the left, and subsequent sub-shapes to the right
  • TopDown - Places the sub-shapes in a vertical arrangement, with the first sub-shape added to the top and subsequent sub-shapes added beneath
  • Border - This requires an additional argument to the addsubshape method to specify which region of the containing shape the sub-shape is to occupy: N, E, S, W or CENTER; each region can only be occupied by one sub-shape
    A sub-shape that is assigned to the E or W region must have its preferredwidth attribute specified in its declaration and, similarly, sub-shapes added to N or S must have their preferredheight attribute set; in this case, the values for these attributes are treated as static lengths and do not scale glyphs

Unfortunately, neither the Help file nor the editor tool-tip show the exact syntax to be used for the addsubshape method with layouttype=border

Can a Sparxian, please enlighten me?

Paolo

19
Bugs and Issues / V14 different browser order
« on: May 08, 2018, 11:46:13 am »
Our corporate repository (SQL Server) has 11 project roots.  If I open the repository in v13.5 I get the familiar order of roots (since v11).
In v14 I get a completely different order and if I move the one that's supposed to be the first up one (using browser arrows) (towards the top - it's about 6th down), it jumps to number 2 and the whole list of roots changes order!

What's going on? Anyone else seen this?

If I exit EA and re-enter, the original, weird order comes up, it doesn't retain the previous order (as did all previous versions).

Reported,
Paolo

20
Bugs and Issues / 1417RC Can't show Notes!
« on: May 01, 2018, 02:28:00 pm »
In the 1417 RC, the ability to use the Notes section of the [Ctrl+Shift+Y] Compartment Visibility dialog is compromised.  The [ ] Show Notes checkbox is missing!

Reported,
Paolo

21
As suggested, I've started a new thread to discuss what might be needed for Enterprise scale modelling of multiple states in time.  This post address the concepts involved so we can agree on what we are talking about and then look at options for implementation.

Time flows (for us humans at least).  What we consider to be the "present" state changes over time.  In database architectures, we can handle how records change over time with State Episodes (the record was in this state for this episode of time).  Using State Episodes, we can hold both historical changes of state and proposed future state(s) in addition to the present state.  One thing we can't do is hold alternate future states (at least not with standard State Episodes).

Because of the effluxion of time, there is only one present state and one "thread" of historical states.  With Standard State Episodes, one can hold a single "thread" of future states.

Historical states are (supposed to be) immutable.  The past is the past!  Whereas, the future is subject to change.  To quote Neils Bohr (disputed), "Prediction is difficult - especially about the future!".

The present is just the present - "As Is" - although what it contains changes with the effluxion of time.

Using state episodes, one can query the object and determine its state at any point in time, seamlessly.

One of the changes that the future is subject to, that that of alternate planning.  In real life (and therefore in modelling), we need to handle alternate, competing, possibilities for a solution while we are investigating the problem and its possible solution(s).  Eventually, we hope, one solution will win out and will be adopted as the "To-Be" solution, which when implemented and the effluxion of time has caught up with the future will become the new "As-Is".  One might say, in addition to a "To-Be",  we also need several "Might-Be".

While Sparx EA does not actually hold state episodic data, it utilises the single thread concept as part of its time aware modelling.

EA uses the concept of doppelgangers or clones to (at least some extent) simulate state episodes.  While not able to achieve the seamless determination of the object state at an arbitrary point in time, a clone (version) of the object is created at nominated points so that changes in a specific version are not also made in other versions.

Unlike a state episodic item, there is no single "identity", rather the single "thread" of clones establishes how the item has changed in each version.

In real life (and therefore in modelling), we need to retain knowledge of "As-was". There is a conceptual difference between "As-Was" and the other two viewpoints.  "As-Was" as mentioned above is immutable. We'd like to be able to recreate the state of an item at any point in the past for which we were tracking it, but that's not possible.  We can only take a "snapshot" of the item at a point in time.  Thus, we aren't really creating an "active" clone of the present (at the point at which we took the snapshot), but a "frozen" doppelganger.  It seems to me, therefore, that the semantic relationship between the past doppelgangers and the present is distinct from that of the future clones and the present.  In addition, while there is no direct relationship between the past doppelgangers (since they each came from a snapshot of the evolving present) there is an inferred relationship between them.

In EA, we already know how to create snapshots, we just export the branch and re-import using "Strip GUIDs".  All we need to do is to link the doppelganger with its master.  Not hard to do if we add a Tagged Value holding the original, master, GUID before export.  We can use the same GUID to link the other past doppelgangers to the new one.

Thoughts?

Paolo

22
Bugs and Issues / V14RC: [Alt+Z] functionality Gone!
« on: April 19, 2018, 02:51:02 pm »
V14RC: The [Alt+Z] key combination no longer resizes to the default element sizing.

Is there a ribbon/menu command to do that?  We use it all the time!

Reported,
Paolo

23
We've started to look at converting our "hand-rolled" MDG file to a formal MDG metamodel using the MDG Generator.

One nice thing about our hand-rolled version is that WE decide what the order of the stereotypes is.  Is it possible to influence the output order via the generator?

TIA,
Paolo

24
Bugs and Issues / TAM- confusing UI
« on: April 12, 2018, 04:47:51 pm »
Following some feedback on TAM - Incorrect item cloned! Sparx advised that: "Time-aware versions can be built sequentially, but not in parallel."

What this means is that if you have an item that has been cloned, you should not be able to clone it again!  Indeed, this appears to be the case.  However, the UI doesn't indicate this.  The "Clone Element as New Version..." context menu item is still enabled for the original item.

Furthermore, executing the menu item will replace the original item on the diagram with the latest clone.  I say the latest clone because if there is a chain of (say 5 items each one cloned from its predecessor), and you are selecting the first (original) item, the original item will be replaced by the fifth item.  Note further, that I said replaced, not cloned, since NO cloning has, in fact, taken place!  Now, to be clear, I have no problem with the end result (if that's what I understood would happen- - given "sequential only" cloning).  Once the latest clone has been inserted into the diagram, executing the "Clone Element as New Version..." a second time will NOW create a new (in this case 6th item)!

The concept of Time-Aware Modelling is difficult enough without confusing matters further by using the wrong terminology so that the unexpected happens (AND you can't reverse the effects once you've executed the menu item!).

Now, the "Clone Element as New Version..." menu item can be disabled by EA for a variety of circumstances (still to be fully investigated by us), so it's not as if EA can't work out when to enable/disable the item.  In some cases, the "Clone Element as New Version..." is enabled, but when you execute it, nothing seems to happen.  That would suggest that it should have been disabled.

In the case of the chained clones above, selecting any item other than the latest clone should enable the "Replace Element with Latest Version" (replacement) menu item.

In an enterprise setting, anyone may have created the diagram you are working on at any time in the past, you (AFAIK) have NO visual indication that the item you  are wanting to clone has already been cloned, so it is vital that you are assisted by the system in understanding what will happen if you execute the menu item.

Reported,
Paolo

25
Bugs and Issues / v14Beta: Issues with MDG profiles
« on: April 12, 2018, 01:55:25 pm »
Something has gone horribly wrong with MDG management in build 1415.

Attempting to load/unload an MDG (even standard ones) in 1415 will cause a crash.

The MDG patterns for the projects we have in 13.5 are no longer visible in the Package creation dialog (Model Wizard). They used to be visible right at the end of the list, but now aren't there at all!

The Toolbox management process also ignores the MDG supplied toolbox configuration profiles - they are no longer visible on the list (More Tools... in 1352).

Because this is missing, we can't work around a caching bug we have found with the toolbox profile itself. We thought this was an exclusively v14 bug, but we have found the issue with 1352 also.
When we changed the profile (for example changing the isCollapsed status of a toolbox section), this would not be reflected in the toolbox. However, we have discovered that it's a caching problem since (under 1352) if we reselect the profile via the "More Tools...", the "Correct" toolbox (as opposed to the "Cached" toolbox) could be made to appear.

Interestingly, exiting EA and reentering DOES NOT show the "correct" toolbox, but the original "cached" toolbox.

Consequently, since we can't reset the profile (since it's not visible on the list) we can't use v14! EAUI rearing its head?

Reported,
Paolo

[Edit: Oh, I forgot...  You also can't add a diagram type that's specified in the profile. The New Diagram dialog doesn't include the list of Profile diagrams.]

26
On out Neighborhood diagrams, we list all the diagrams that the main item (the Root Vertex) appears on (that aren't Neighborhood diagrams of the related items) as hyperlinks.

However, we'd like to open the diagram with the nominated item as the focus - Find in All Diagrams [Ctrl+U] Functionality.

Is there a syntax or property we can encode in the hyperlink to get it to move the focus to the nominated element?

TIA,
Paolo

27
Bugs and Issues / v14Beta: Local MDG projects at end of very long list
« on: March 23, 2018, 01:41:11 pm »
When you try to add a project with a local MDG specified pattern, it is placed at the end of a very long list on the Model Patterns tab!  Can we either have them at the top or in a separate tab on the dialog?

Reported,
Paolo

28
Bugs and Issues / setpenwidth() does not propagate to sub-shape
« on: March 22, 2018, 05:48:47 pm »
The penwidth() setting doesn't seem to propagate to a sub-shape, whereas the other pen related methods do.

Code: [Select]
setpencolor(getuserbordercolor());
setpenwidth(getUserPenSize()); //<-doesn't work
setfillcolor(getuserfillcolor());
addsubshape("X",100,100);
shape X
{
noshadow=true;
setpenwidth(getUserPenSize());//<- need to set it here!
startpath();
...
}
Please rectify.  NOTE: this is also true of setpen()

Reported,
Paolo

29
We're finding asymmetrical problems with link:<relationship type> QuickLinker entries.

Code: [Select]
// Everything can derive (by traversal) from anything else
link:Abstraction,,link:Abstraction,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Aggregation,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Association,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Composition,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:ControlFlow,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Dependency,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Generalization,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:InformationFlow,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Nesting,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:NoteLink,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Realisation,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
link:Abstraction,,link:Substitution,,,,,Abstraction,Drvtn,to,derives from,derives from,True,,,True,Derivation,0,,,,,&#xA;
(we've n x n of these)

So in both directions, we should be able to derive one type from another.  However, it's not working under v14 (1405).  Sometimes it works in one direction but not in the reverse.  Sometimes in neither.  Information Flows seem to be the worst.

Works fine under 1352 (and prior versions).

Reported,
Paolo

30
We have decided that we want to attach details of the REST API endpoints to our Required or Provided Interfaces (as operations on the interface).

The problem comes when we want to render them.  Even if we create a shapescript which has both Rectangular and non-Rectangular notation forms, Required and Provided Interfaces are "special" - there is no Rectangular form as we usually know it (drawnativeshape() - ONLY draws a ball or socket).  In addition, the sizes are (pretty much) fixed. The scripts don't respond to defsize() requests (although, in typical EAUI fashion, Ports do!).

So my question is, is there a way to make an MDG item be defined as "attached" (aka embedded) directly in another item?  In that way, we could use some other form of item (which does support Rectangular notation) as the basis for our specific Required or Provided Interfaces?

Paolo

Pages: 1 [2] 3 4 ... 79