Need advice on how to manage frequent sub-model changes (package import)

[Richard Freggi]

Hello
I've been reading the user manual but I'm still not clear on what is the best approach to meet my requirement.  Any advice is warmly welcome!

I have two models in my project (each with its root package):  an "Import" model containing complex package hierarchy and classes of a system, and a "Reporting" model consisting of package hierarchy and diagrams.  The diagram elements come from the Import model.

The system is updated on a weekly basis, so every week I need to extract an XMI file from the system and import the XMI into my "Import" package.  I need to make sure that elements that are changed or deleted are represented correctly in my diagrams (if an element is added, I can manually drag it into my diagram).

The most common changes are moving elements from one package to another, adding new packages and elements, and renaming elements.

It's not clear to me what is the right way to do this in EA.  Should I set my Import package as baseline, then import the XMI in a temporary package, then use package compare utility and manually merge the temporary package in the Import package?  Then delete the temporary package.

I think this should be a common scenario, so there must be some straightforward way to do it, but right now I'm confused by the user manual and can't find the right way of doing it - if anybody has experience please share! Thanks!

EA version 1310

[Geert Bellekens]

Is there a reason why you can't simply import the xmi over the existing Import package?

If you need a delta, you can take a baseline before the import, and then compare the current package to the baseline after the import.

Geert

[Richard Freggi]

Hi Geert
If I just import the XMI directly in the "Import" package it will synchronize?  Wow I did not think of that.  Will try it right away!

[Edit 10 minutes later]
Per Geert's suggestions I'm reading up on setting my Import as controlled package, then use Scan XMI and Reconcile model during the XMI import into the controlled package, and I should be able to manually accept/reject changes and get a report of all changes made.  Does this sound like a good approach?

[qwerty]

Yes and no. This element-wise "what has changed" does not get the whole picture. Merging model changes is simply a complex matter which can't be reduced to a simple monkey task.

q.

[Geert Bellekens]

From what I understood you are not changing the "Import" model are you?
In that case it's not a question of accepting/rejecting, but simply a question of knowing what has changed.

If you really need merging that is indeed a whole other ballgame. There are specialized tools to facilitate that (Lemontree), but this is certainly a rather big challenge and workload.

Geert

[Richard Freggi]

Yes as Geert says, rejecting a change is not really necessary, because my "Import" model needs to show the current system.  My concern is to ensure minimum breaking of my diagrams in the "Report" model (I'm OK to manually fix them a little if needed).  For example if a classifier is moved from one package to another in the import or  merge, will it disappear from my diagram?  I guess so as it may be imported with a different GUID.

I need a way to keep manual fixes in the Report model to a minimum, via the right import and/or merge strategy...

[Geert Bellekens]

Richard,

When doing XMI export/import (as long as it from EA and to EA) each element keeps it's own GUID
That never changes, not even when you move it to another package.

EA uses the guid to link the existing elemnets to the elements in the import file.

So your diagrams will not be changed except for
- elements that have been deleted
- relations that have been deleted or added.

You'll want to do a baseline compare to know which elements have been added, so you can add them to the relevant diagrams.

Geert

[Uffe]

Hello,

For example if a classifier is moved from one package to another in the import or  merge, will it disappear from my diagram?  I guess so as it may be imported with a different GUID.

If you reset GUIDs during the import, nothing will work because you're not importing the model, you're creating a duplicate. So don't do that.

I need a way to keep manual fixes in the Report model to a minimum, via the right import and/or merge strategy...

The right strategy is reusable assets. Not cheapest, not simplest, but right. est. You can combine it with baselines, and in fact in more recent versions you can store baselines in RAS itself.

The area where you need to put in the thinking is in structuring your models. RAS does dependency management -- one of its main selling points -- but complex dependency trees can confuse it so avoid those. It also works best if you maintain a strict separation between the master project, where you publish new versions of the models, and the target projects, where you import them. Allowing the target projects to publish updates can be viable, but only if everyone (and I do mean everyone) involved has a thorough, my-level understanding of how RAS works. Otherwise, things will break.

EA version 1310

Ah. Well RAS was around back then, but whether you can get hold of the corresponding version of the cloud server is another matter. There are potential compatibility issues, which Sparx don't necessarily handle all that well. But RAS is just about the simplest function the cloud server provides, and it should be easy enough to set up and test EA 13 with Pro Cloud Server 4.1.

HTH,


/Uffe

[Richard Freggi]

Richard,

When doing XMI export/import (as long as it from EA and to EA) each element keeps it's own GUID
That never changes, not even when you move it to another package.

EA uses the guid to link the existing elemnets to the elements in the import file.

So your diagrams will not be changed except for
- elements that have been deleted
- relations that have been deleted or added.

You'll want to do a baseline compare to know which elements have been added, so you can add them to the relevant diagrams.

Geert

Yes but the source of the model not from EA, is is a query on the repository of the system, which is then imported into a temporary package using Sparx Office integration MDG + your excellent Bellekens Excel importer, then I export this package to XMI and I import it into the "Import" model (I need to do this because both Office MDG and Excel importers work on *eap and my model is *feap (Firebird).
 So the elements have an ad-hoc GUID.  Also, I need XMI import because if an element is deleted in the system, MDG or Excel importer will not remove it from the Import model (they will just add or override, but not remove).

[qwerty]

Sounds like you need your own custom imported that can detect existing element rather replacing everything. That's doable but of course needs some brain work.

q.

[Uffe]

Hello again,

Yes but the source of the model not from EA, is is a query on the repository of the system, which is then imported into a temporary package using Sparx Office integration MDG + your excellent Bellekens Excel importer, then I export this package to XMI and I import it into the "Import" model (I need to do this because both Office MDG and Excel importers work on *eap and my model is *feap (Firebird).
 So the elements have an ad-hoc GUID.  Also, I need XMI import because if an element is deleted in the system, MDG or Excel importer will not remove it from the Import model (they will just add or override, but not remove).

Both the baseline and RAS functions are based on XMI, and will delete elements which are in the model but not the baseline/asset being imported. They also allow seamless transfer between repository types.

Sounds like you need your own custom imported that can detect existing element rather replacing everything. That's doable but of course needs some brain work.

Not that much. Richard's setup sounds similar to what I've built for my current client, which has several non-UML data sources which they want to modelize.

We've got one project where these "reference models" are maintained; this has got custom import scripts, each of which reads data from a source and updates one of the models. The sources are text files, Excel workbooks, web servers and proprietary servers. It is the responsibility of the import script to delete obsolete elements, add new ones, and update existing ones as necessary (this is where the brain work comes in, since the source data does not have EA GUIDs, but it's not overwhelmingly difficult). We don't use Office Integration or the Excel Importer.

From the model maintenance project, models are published to RAS, and then imported from there to the various target projects. In these target projects, the reference models are hands-off. Users in these projects do not have permission to update the RAS storage, and the reference models are kept locked by admin.

It works pretty well. I myself am not involved in either maintaining the reference models nor admin'ing any of the target projects, so it's not an oops-didn't-work-tinker-tinker-edit-script-fiddle-with-model-try-again process, but a fairly smooth production line. Would be better if implemented as an Add-In, but the client doesn't want that so it's VBScript all the way down. 


/Uffe

[Richard Freggi]

Thank very much everybody, much food for thought and very useful for my project!