Importing an EAP file into a repository

[Modesto Vega]

We have an EAP file we want to import into an RDBMS repository, with several root nodes (model). Can we use the Project Transfer tool, using an File to RDBMS setting?

Most importantly, will the Project Transfer tool clear all repository data or just the selected root node?

P.S.: In this case we are using v13.

[Geert Bellekens]

Project transfer will completely erase the existing model.

You'll have to use xmi export/import.

In v15 you have the option to use native xml export/import, which supposedly is faster and less error prone then xmi.

Geert

[qwerty]

By "native" you supposedly mean "proprietary" I guess?

q.

[Geert Bellekens]

By "native" you supposedly mean "proprietary" I guess?

q.

"Native" is the term used by sparx.

Geert

[qwerty]

That says all (or nothing). Probably I'd guess right ;-)

q.

[Modesto Vega]

We ended up using an old trick: open the source project, copy the root node Full Structure for Duplication, close the source project, connect to the repository and paste it. It more or less worked, ended up with one level too many as the root package became a package within another root package.

[SNIP]
Project transfer will completely erase the existing model.

I am assuming that in this case, you mean the whole repository and not the selected root node or package. A repository can have multiple root nodes with Sparx oddly calling the first added one, model.

Isn’t it wonderful how consistent Sparx is with language? In this context, models are not models but the whole repository (which can have many models/roots nodes). If you add to this other semantic inconsistencies - i.e., projects being repositories (or project files) and not really projects, models not really being models but groups of loosely packages, and packages being often models - you get a very good understanding of why certain regular contributor to this forum wisely emphasises being “consistently inconsistent”.

[qwerty]

I still wonder (do I ?) why this stupid limitation for root and views still exists. It could simply be replaced by using stereotyped packages and would (more or less) be backward compatible. (Why is my neck aching? Ah, no no no no...)

q.

[Geert Bellekens]

I am assuming that in this case, you mean the whole repository and not the selected root node or package. A repository can have multiple root nodes with Sparx oddly calling the first added one, model.

Yes in this case model == repository == database == project 
When you do a transfer to a database, everything in that database will be erased.
You get a very clear warning about that when you start a project transfer.

Model transfer works by copying each table, row per row from one database to the next.
This can only be done with complete databases (for obvious reasons)

Geert

[Modesto Vega]

I still wonder (do I ?) why this stupid limitation for root and views still exists. It could simply be replaced by using stereotyped packages and would (more or less) be backward compatible. (Why is my neck aching? Ah, no no no no...)

q.

Agreed, but try to keep your neck intact it is more important than Sparx Systems been consistent 

[SNIP]
Model transfer works by copying each table, row per row from one database to the next.
This can only be done with complete databases (for obvious reasons)

Geert

Model transfer is not very useful. Its use is limited to transferring full repositories. It is useless to transfer individual models in a multi-model repository, or to consolidate multiple models into a single repository. Any of the above required the use of XMI imports which are not exactly straightforward.

The fact that Sparx does not fully embraced the concept of a multi-model repository is a bit baffling. Sparx seems to be implying that repositories have just one Root Node which equates to one single model, this may have worked in the late 1990s or early 2000s but not now.

[Geert Bellekens]

For what it's worth.

The limitation on views has been removed in the more recent versions. Views can now be moved under existing packages or views.

Root nodes are still special though.

Geert

[Uffe]

The fact that Sparx does not fully embraced the concept of a multi-model repository is a bit baffling. Sparx seems to be implying that repositories have just one Root Node which equates to one single model, this may have worked in the late 1990s or early 2000s but not now.

Well, not quite. You can have any number of root nodes in a project (except 0). And in the API, while root nodes are implemented as packages (without mirror elements, which is what makes them different), they are referred to in the Repository object as Models.

However, there are no restrictions on using elements between root hierarchies, which is what you'd need for the term "multi-model" to apply. Instead, root nodes are just a way of structuring the project. So apart from that one place in the API and various places in the documentation, there is no equivalence between "model" and "root node".

You can really only speak of "models" in any meaningful sense when you start doing version control, baselines or reusable assets. Only then is there some concept of a unit of modelling stuff which has an existence separate from the project(s) where it appears and which has dependencies to other units of modelling stuff -- aka "models".

The problem (or one problem) arises from the fact that there is a bunch of stuff which is part of the project but not of any model. Most of this stuff is referred to as "reference data", which can also be moved between projects using the reference data export/import functions.

In a recent version the reusable asset service was extended to support storage of reference data in addition to model content. RAS supports model-to-model dependency management, but I don't know whether it now also manages model-to-reference-data dependencies. If so, then this would go a fair way towards solving your initial problem of moving models and other necessary stuff from one repository to another without completely clobbering the target repository. Could be worth looking into.

The limitation on views has been removed in the more recent versions. Views can now be moved under existing packages or views.

Yeah, I got smacked upside the head with that in another thread a few weeks ago.

Serves me right for just reading the release notes and not personally regression-testing every little EA annoyance with each new version, I guess.   :|


/Uffe

[Modesto Vega]

The fact that Sparx does not fully embraced the concept of a multi-model repository is a bit baffling. Sparx seems to be implying that repositories have just one Root Node which equates to one single model, this may have worked in the late 1990s or early 2000s but not now.

Well, not quite. You can have any number of root nodes in a project (except 0). And in the API, while root nodes are implemented as packages (without mirror elements, which is what makes them different), they are referred to in the Repository object as Models.

I am not saying that multi-model repositories cannot be built with Sparx, of course, they can be built. Of course, it is possible to have multiple root nodes. Of course, the API calls the root nodes models when most the time they are not models.

Sparx is very flexible and if bent enough, semantic inconsistencies can be exploited to create multi-model repositories.

In my opinion, for Sparx to fully embrace multi-model repositories they need to:
1. Remove the restrictions around the Root node, it should be a package, its only apparent special characteristic is that it has no parent package.
2. It should be possible to stereotype the root node and to represent it as a package in any diagram.
3. It should also be possible to nest any element and diagram directly under the root package. In V13 and V14, this is impossible but don’t know about V15.1.
4. I would be happier if I had a model base type that could be further specialised through an MDG. In V13 and, I think v14, there is a model stereotype which does not belong to any profile. I have not check this on v15.1.
4. Project Transfer should allow the import of single packages, including root nodes, or full repositories. I know it can be done through XMI/XML files but these files are not particularly user friendly.

Finally, I would love if they stop using he word project instead of repository.

[Eve]

I'm not sure any of those points are the real issues that people have when building a multi-model repository. Those are the easiest to address. (As a workaround, just ignore that it exists completely and use "views" as your "roots".)

The issues that I come across are wanting/needing different authors, glossary, security rules, status types etc between the different models.

[Uffe]

The issues that I come across are wanting/needing different authors, glossary, security rules, status types etc between the different models.

Yes. This is what I meant by "stuff which is part of the project but not of any model", or reference data.

EA already has the ability to support multiple metamodels (in the form of MDG Technologies) in the same project. That's good, although enforcement is weak.
But since reference data is global, and since part of an EA metamodel is implemented as reference data, each project can in fact only support one metamodel fully and (any number of) others only partially. This is bad.

The ideal solution to my mind would be to allow root nodes to retain their special status, so no to Modesto's points 1, 2 and 3, but to introduce the notion of linking one metamodel to each root node, which is something like Modesto's point 4. These metamodels should be complete, and there should be functionality in place to manage conflicting metamodels in a project. So if you tried to create a model (= root node) from metamodel X when you are already using metamodel Y and they disagree about what types of requirement exist, EA should warn you.

A model = root node would then mean "a unit of modelling which adheres to one metamodel". You could still create multiple root nodes linked to the same metamodel if you wish, of course, but not one root node with multiple metamodels. (And I don't think linking individual packages to metamodels makes sense, since any meaningful model easily runs into thousands of packages, which is why I think root nodes should remain special.)

Finally, I would love if they stop using he word project instead of repository.

They're both needed, but they should be used consistently.
A project is a modelling workspace. Each EA session can be connected to (at most) one project.
A repository is a modelling workspace storage. It can be a DBMS database, or a single file, and both those cases have sub-cases. There are issues which relate exclusively to the storage technology so having a separate word for that makes sense.

In fact, the project transfer functionality highlights this: you can copy a modelling workspace from one storage to another, and afterwards you have the same project in two storages. All the GUIDs are the same, all the reference data is identical. (They may quickly diverge, of course.)
So consistent use of "project" and "repository" would be desirable, but they are both needed.

And ideally there should also be one single definition of "model", which is different from a package, a diagram, and a project.
Ideally ideally, something like what I described above.

4. Project Transfer should allow the import of single packages, including root nodes, or full repositories. I know it can be done through XMI/XML files but these files are not particularly user friendly.

There is a middle ground. You can create baselines (which can be taken at the root level) in the source project, import them into the target project and restore them there. It's XMI underneath, but you never see it and there are no files to manage.


/Uffe

[Modesto Vega]

I'm not sure any of those points are the real issues that people have when building a multi-model repository. Those are the easiest to address. (As a workaround, just ignore that it exists completely and use "views" as your "roots".)

The issues that I come across are wanting/needing different authors, glossary, security rules, status types etc between the different models.

These are some of the issues but not all them, those falling under what Uffe terms as "reference data" are also important issues. The key thing is how all of this relates to an architecture (Sparx).

Have you ever tried to explain to a Sparx and/or architecture novice that models - i.e., root nodes - are not always model, projects are repositories (and not workspaces or projects in the project management sense of the word), and packages are often models? You used the word workarounds in your reply; the real issue is that many workarounds are needed to create a multi-model repository.

[SNIP]
The ideal solution [...] would be to allow root nodes to retain their special status [...], but to introduce the notion of linking one metamodel to each root node, which is something like Modesto's point 4. These metamodels should be complete, and there should be functionality in place to manage conflicting metamodels in a project. [...].

A model = root node would then mean "a unit of modelling which adheres to one metamodel". You could still create multiple root nodes linked to the same metamodel if you wish, of course, but not one root node with multiple metamodels. (And I don't think linking individual packages to metamodels makes sense, since any meaningful model easily runs into thousands of packages, which is why I think root nodes should remain special.)

Perfectly happy with this, it would be a vast improvement, no need to fully demote root nodes from their special position if all of this is put in place .

Finally, I would love if they stop using he word project instead of repository.

They're both needed, but they should be used consistently.
A project is a modelling workspace. Each EA session can be connected to (at most) one project.
A repository is a modelling workspace storage. It can be a DBMS database, or a single file, and both those cases have sub-cases. There are issues which relate exclusively to the storage technology so having a separate word for that makes sense.

Agreed, there are
1) repositories, this is physical storage,
2) projects (and programmes) in the project management sense of the word, and
3) project workspaces.

It would be ideal if Sparx could
a) clearly separate the 3 of them using terminology that does not suggest a workaround,
b) be capable of attaching reference data to both projects (and programmes) in the PMO sense of the word, and to root nodes.