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 ... 403
Bugs and Issues / Re: Time-aware models: revert clone
« on: Today at 09:54:58 am »
Very good perspectives and analysis in this thread. This is the kind of discussion that could have given a perfect spec for the new feature.
What ask the users what they want in a feature BEFORE you build it?  To paraphrase the ".Net Rocks" guys, "That's crazy talk!"

One of our senior architects was bemoaning a new "feature" that had been developed by one of our manufacturers on one of our production applications. "They build what they want to build and then wonder why it doesn't suit our needs.  They never asked anybody".

It seems to be an occupational hazard.

For our part, we have decided (and here I don't mean the "royal" we, I mean our Modeling Review Board) that this year we need to implement a proper cloning mechanism to help us keep track of what's going on in our enterprise-wide repository.  So given Sparx has developed a "cloning" mechanism of sorts, we need to be as compatible as we can with that.  Based on previous experience,  the feature design is not going to change significantly in the next little while.

Notwithstanding that the cloning mechanism is for our use (notionally), I could practice what I preach and open up a "crowd-sourced" requirements and use case thread - to help us specify what the mechanism should do and how it should behave.


Bugs and Issues / Re: Time-aware models: revert clone
« on: April 23, 2018, 04:49:34 pm »
Serious discussion! but just wondering how about a baseline of the source and the target packages before cloning, and use that to revert back? ideally automated, but in absence of which can it be a manual effort?
Hi Nizam,

Unfortunately, at enterprise scale, this is unviable.  Anyway, as Uffe has said, it's a diagram, not package problem.  One way would be to make a copy of the diagram before cloning and then revert to the saved copy - if it didn't go correctly.  The underlying issue of what "Clone to NEW version" means needs to be clarified first.

In addition to the problem Uffe has mentioned, it could (and we have) be argued that if you change the clone on one diagram in a version branch, you should change the clone in ALL (or at least be given the option to select which diagrams should also be changed) the diagrams in the version branch.


Bugs and Issues / Re: Time-aware models: revert clone
« on: April 23, 2018, 12:44:44 pm »
Ah, but it does -- I'm reverting to the previous version. I'm not talking about parallel branches here, just a basic "undo check-out" if you will, of a single element.

The element I'm reverting has the special-dodgy-kludgy trace connector to its predecessor. Which diagrams that predecessor is in is easily checked, so restoring those occurrences to the cloned diagrams (where the predecessor has been replaced by the clone) should be no harder when reverting than when cloning the diagram in the first place.

I'm fully prepared to accept that you can't revert an element which has already been cloned in turn (ie has an inbound special-dodgy-kludgy trace relationship), but you should be able to back up from the head.


Hi Uffe,
I wasn't clear enough.  My point applies to BOTH sequential and parallel streams.  Each clone knows the predecessor clone, but NOT which version it was cloned from!

Say I have versions 1 to 5 in the model and the diagram I am using to clone has #2.  When I say clone to a new version it will place #5 on the diagram.

Now it doesn't know it came from #2 - so it can't revert to #2.  I'm not sure that reverting to #4 is what you're after.

Is that clearer?


Bugs and Issues / Re: V14RC: [Alt+Z] functionality Gone!
« on: April 20, 2018, 10:36:36 am »
It still (mostly) works for me, although sometimes the ribbon appears to eat the combination.
Yes, that's the problem.  For me, it doesn't seem to work at all so far.  I'll reboot at some time and confirm the problem is still there. I'm on Windows 7.


Oh, and I found that if you've got the situation I had above, then select the non-cloned package in the cloned diagram and hit Clone Element as New Version, the old package is replaced by the new one in the diagram, and subsequently, the Clone Element menu item is greyed out.


As per my previous comments in the other TAM posts, I suspect it's working correctly.  Since the requirement for the initial clone of the diagram is to NOT clone any vertex, it is incumbent upon the user to determine which vertices to clone (including folders).

There is some "method in their madness".



I had a look at the time aware modelling feature and decided that it is not useful for me or my clients.
It really quickly becomes a mix of elements from different versions, all linked to each other.
Definitely not how I would design a feature like that.

Geert, Any cloning system will end up as a "mix of elements from different versions".  The trick is how to manage it properly.  We're looking at implementing our own cloning system (hopefully compatible with Sparx's) to do it a bit better.


Bugs and Issues / Re: Time-aware models: revert clone
« on: April 20, 2018, 10:14:32 am »
Hi boys & girls,

I can't find a function to revert a cloned element in a diagram, in other words, destroy the cloned element and replace it in the diagram with the original.

Isn't there one?

As far as I'm aware there's not.  I can also tell you why (I think).  In my topic on TAM where I discuss sequential versus parallel cloning; when you clone an early version which has subsequent versions, you get the latest version ONLY.  The cloned element has NO memory of where it was cloned from and so you can't revert.  It doesn't know which version to revert to.


Bugs and Issues / Re: Time-aware MDG Technology models
« on: April 20, 2018, 10:10:52 am »
... No it won't, and no it won't.

Thanks for the "heads up".

As per my reply to the Import/Export topic, I suspect it's working correctly (at present).  I'll have a look (when I get a minute or two) to better understand your point.


Bugs and Issues / Re: Import/export of time-aware models
« on: April 20, 2018, 10:02:17 am »
Hi Uffe,

Like you, having delved into TAM, I'm a bit concerned about some of the current functionality (and more particularly, the UI).

However, from my (still limited) knowledge of TAM, the export is working correctly.  The uncloned vertices are (and probably should) NOT part of the versioned folder.  Consequently, the export should be the same as for a non-TAM package.  I thought these days, the export exported "stubs" for the out-of-branch vertices.  If you're saying the stubs are missing, then that's a bug.

The problem (as I see it) with what you are asking is that (as I said above) the uncloned vertices are in a different structure.  If you force EA to export them as part of this structure, you are exporting a corrupted model.  However, that having been said, there may be use cases where such an export is useful.  Can you elaborate on yours?


Bugs and Issues / Re: Data Model - bug on saving the diagram
« on: April 20, 2018, 09:55:56 am »
Still a problem 8 years later in 13.5.

Working on a saved diagram, deleting and recreating the association in between the tables, with no other changes, causes the diagram to be flagged as needing saved. Trying to close the diagram without saving still results in the FK constraint being deleted. The diagram still shows the correct association link in between the tables with all of the correct labels, but without the constraint in place.
Hi lweath,

I'm not sure it's a bug (in Sparx's view).  As part of standard diagram processing, if you don't a diagram on closing with a NEW vertex or arc, EA assumes that you didn't want them and will purge them from the model.

In your case deleting (I assume yo9u mean purging from the model - not just hiding on the diagram) and creating the NEW arc will "dirty" the diagram.  Thus, it needs to be saved.  In the case of a Foreign Key Constraint, the issue is more complicated because you (effectively) have a two-step process.  Have you confirmed that saving the "dirty" diagram correctly saves the FK Constraint?

I have some sympathy for Sparx's view but the EAUI could have been better framed to alert users to what may happen.



As an alternative, you could compare the xml files "functionally".

I had this same requirement to compare XSD files in a "functional" way -> ignoring the order of elements (where not important), whitespace, order of attributes, etc...
(we are migrating a Magicdraw model + XSD generation to EA + XSD generation and we need to know if the XSD's (about 500 of them) are functionally still 100% the same while allowing non-important differences)
What I end up doing was building my own comparer based on a code sample I found on a Microsoft website.

I uploaded it to github. I think you only need to change the (hardcoded) .xsd extension to .xml to make it compare xml file.

Thanks, Geert!

That should be really useful!  I'll give it a try when I get to work.

However, that doesn't change my need to know the expected output order.  You know my views on consistency.  Why is that outlier present?  I'm always nervous with "unknowns".


Metatypes too, please!  We're trying to wean our users off stereotypes - which in our MDG are quite cryptic and move them to metatypes.
Did you even look at what was being requested? It's used metatypes for years.
My Bad, I was only looking at the column headings (which, of course, on reflection, includes both Types and Metatypes)


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!


Where would that order be important? I guess in the toolbox? If so (IIRC) EA does not offer an ordering from the MDG export (since IIRC I tried that once and could not figure it out).

Well, we have an existing MDG which is in a particular order  Arcs (alphabetical) followed by Vertices (alphabetical).  We are trying to regenerate the same content from the repository, so we use file comparators to compare what we generate with what we wanted to generate.  The file comparators work on text and so the order of the output is important, to help up do the comparison.

The generated MDG appears to have output the  Vertices (corrupted alphabetical) followed by Arcs (alphabetical).  I say corrupted alphabetical because the Vertices had an outlier (from close to the end alphabetically) stuck at the front, but the rest appear alphabetical.   (EAUI?)

Also, at the moment, the metatypes are intermingled in the same package and we want to separate them for ease of management, we'd like to know if that will affect the output.

So, could anyone, but especially a Sparxian, indicate how the output order is determined?
(For example, if it IS/should be Vertices (alphabetical) followed by Arcs (alphabetical), then we can easily cut and paste our original MDG file and swap.  Then "we're off and racing"!  :) )


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?


Pages: [1] 2 3 ... 403