Create a sub-project

[JW]

In the last couple of years we developed a project (some sort of framework) that consists of a large number of diagrams (activity, class, screenflow…). At the moment we would like to build a new sub-project that is identical, but with some variation points.

Is there a way to copy a whole project (root node) while preserving the links to all components (and possibly diagrams), so changes in de framework are mostly inherited into the sub-project?

[JW]

In the meantime I've come a long way. It is possible to copy/paste a diagram (shallow). The diagram is an identical copy of the original and it uses the original elements.

But there is one problem. All composite elements link to the original diagrams. I would like to link these to a new diagram (also a copy). Is it possible to use the original elements in the copied diagrams, but change the reference (composite element) to another diagram (ofcourse while maintaining the link in the original diagram).

[JW]

Does anyone know what is the best way to create two models, where one model is based upon the other model?

In other words; how can I setup my project so most of the changes in the parent-diagram are ‘pushed’ to the child-diagram(s)?

[Frank Horn]

I think controlled packages are the only way. Packages to be reused by other packages are exported to xmi and imported into the models which need them. The xmi files can be under version control.

There are two whitepapers

http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf

and

http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

as well as a lot of discussion in this forum about the pros and cons of the various scenarios described there.

[JW]

Thanks for your answer Frank!

I already found those white-papers and the "One Repository – Multiple Projects" seems to be the best solution for my problem. Therefore I don't need controlled packages (as far as I can tell…)

Everything works fine (using a shallow-copy of the various diagrams), but all the composite elements keep their links to a diagram in the original parent-project.
In other words: I use the same elements (activities) for the diagrams in the parent and child projects. When I double click on a composite-element in a child-project, I navigate back to a diagram in the parent-project.  I would like to navigate to the same diagram, but in the child-project.

Does EA support any functionality like this? Or should I use another approach and forget all about using a shallow-copy of the diagrams?

[Frank Horn]

Does EA support any functionality like this?

I don't think it does.

Anyway, I'm not sure if shallow diagram copies are a good idea, but maybe I don't understand the way you build up your model. When you drag activities from the parent project onto a diagram in the child project, and then add flow connectors, these connectors will be saved in the source activity's parent package, which may well be within the parent project. Is this really what you want?

[JW]

That is one of the side-effects. We were planning to overcome this problem by hiding the relations in all other packages, or by working with color-codes.

Using a shallow diagram copy is the best option I know to inherit as much as possible from the parent-project (too bad it works both ways).

[Frank Horn]

According to what I've learnt you're barking up the wrong tree cause you're thinking in terms of diagrams instead of model elements. The model should be leading, with the diagrams being just visualisations of it.

Let's say you have an old ("parent") model called "Common" and in there activities A and B, with A calling B. Now you introduce a new model called "New Branch", where A is calling a newly introduced activity C instead of B.

So you define a flow from A to C in the new model, thus changing the old model which will now contain calls from A to B and C. So your old model is actually messed up, and you want to ignore this by suppressing such things in the diagrams within the old model. Moreover, the "Common" model will have dependencies pointing to the branch, which badly goes against the grain.

This may be allright if you don't care for model consistency at all but just want to produce diagrams. But even then it can hit back. Imagine you get a host of new branches modelled by various people who will all change the model "Common". You'll need notification everytime someone changes things so you can suppress all the new things in the central model's diagrams.

I'm not really much of a UML expert, but here's what I would do in a situation like this:

1. Split the old model into

a) "Common" with activity A and nothing else (or, in a less trivial case, all things which are to be shared by all branches).

b) A model "Old Branch" with activity B and an instance of A calling an instance of B.

2. In model "New Branch", introduce activity C and let an instance of A call an instance of C.

This way you need not change the old model, and making the instances composite will solve your navigation problem.

Don't ask me if this is good UML though. Mine is a technical (and EA usability) point of view. For opinions on UML superstructure compliance you can open a thread in the UML usage section and wait for the big shots to join in.

[JW]

Thanks for your answer! It is an interesting approach that I did not think of before. It is a lot ‘cleaner’ and better workable than the solution that I thought off.

But I am afraid for the following situation;
I have an activity-diagram that consists of the following activities:
A --> B --> C

Activity B is modeled in more detail through another activity diagram (composite element):
X --> Y --> Z

In one of the branches it does not use the activity Z, but Z’. So I do not model this activity in the “Common” diagram, but I use instances in the branches.
Can I still use activity B in de “common” diagram? Or do I also have to use an instance of B for this diagram?

Most of the differences are modeled in the lowest diagrams (low granularity). So do I have to use instances all the way up when ‘specializing’ an element in the lowest model?

[Frank Horn]

So do I have to use instances all the way up

I think I would use instances all the way to keep it consistent. But then, as I said before, I'm not sure if this is good strategy at all.

A completely different approach would be to use controlled packages with version control and branches (in the version control sense). Unfortunately EA's version control integration does not support branching, so you would have to fiddle with the xmi files manually:

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1215613197/10#10

[JW]

I think I would use instances all the way to keep it consistent. But then, as I said before, I'm not sure if this is good strategy at all.

Thanks for your reply, I just tested this. And I think that none of the changes in the "common" diagram/instances are inherited to the child diagram/instances. Am I doing something wrong?

A completely different approach would be to use controlled packages with version control and branches (in the version control sense). Unfortunately EA's version control integration does not support branching, so you would have to fiddle with the xmi files manually:

Will this help? Since the several projects are saved in the same repository (database). I would be able to import the elements from the "common" diagram, but won't I have the same problems then?

[Frank Horn]

And I think that none of the changes in the "common" diagram/instances are inherited to the child diagram/instances. Am I doing something wrong?

No, it's just like that. The instances in one package have nothing to do with the instances in another one.  Looks like this is not what you need after all.

As to the version control approach:

Since the several projects are saved in the same repository (database). I would be able to import the elements from the "common" diagram, but won't I have the same problems then?

No separation into "Common" and "New" needed there. You just take the old model, put the package under version control, and then from outside EA with a version control client (like TortoiseSVN) you copy the xmi file(s) to a branch. Then you create a new empty model (eap file), configure it to point to the branch as local working copy for version controlled packages, and import the xmi file(s) via the "Get Package" menu. Then change the model as needed.

The problem there is merging back, but it should be possible with baselines. Anyway though, you wouldn't have what you call "inheritance" there, so I guess it's not what you want either.

So let's try another approach (again with the minimal example of A calling B in the old model and A calling C in the new one):

In package "Common", define A and B with a flow from A to B. Then in package "New", create a second Activity named A, and a new one called C, and a flow from the new A to C. Drag A from "Common" to the diagram in "New" where the new A and C are. Draw a dependency from new A to old A, perhaps giving it a stereotype like "overrides".

This way you don't change package "Common", and can now make the new A composite to model its details.

[Dermot]

Have you looked at copying the original model and then using the  Manage Baseline - Compare utility - there is facility to merge differnces between models - see:
http://www.sparxsystems.com.au/EAUserGuide/differences.htm
&
http://www.sparxsystems.com.au/EAUserGuide/compare_utility_tab_toolbar.htm

[JW]

Frank / Dermot, thanks for the answers!

Frank, nice approach. This will also clarify the differences between the new and common package.
Dermot, there are quite some differences between the diagrams (even though they are mostly the same). That will result in a very long list of differences every time a compare is made. But this feature can be very useful for comparing versions of the same package.

So, I think the solution is a combination of the above answers. I can use Frank’s approach to model the differences between the models. And compare the versions of the “common”-package every new release to indicate the new changes. After that we can change the new diagram by hand.

Too bad EA does not fully support my wishes in reusing activity-diagrams. But we are very close to it, and this is certainly a workable situation.
Thanks everybody for the help!

[John Brand]

Thanks for the tip - I downloaded and read both articles. I do have a question in the deployment document reference is made on page7 to "using separate repositories under a common master repository" - this is portrayed as a link but doesn't open? Any idea where this document can be found? Thanks in advance, John
ps do you by any chance occcasionally write/read about Irish rugby?