Get package ends with: root import package already

[Paolo F Cantoni]

Hi Damir,

Thanks for the clarification  

We've now had quite a bit of experience in refactoring stuff to get to our current model.  There may still be some way we can help.

As you say, there's probably no elegant way to fix your problem.  Our view would be "how can we make sure we don't loose data in the refactoring process".

Just so I can be clear on what the nature of your problem is...

1) you have a particular package structure which was used to start a number of different project specific .EAP files such that a given named package has the same GUID in more than one .EAP file.

2) You wish to combine the same package from more than one source and place the new (combined) package in a third location.

3) You are encountering errors in this process due to GUID conflicts

Now for some questions...

Will our structure of specific, some & all fit your requirements (if you could start over again).  If not, why not?  (This is to gain better insight into the nature of your problem - not to, necessarily force our solution on you)

Assuming, for the present, that it will, is there any impediment (other than GUID conflict) to place all the current set of packages into one .EAP file (for refactoring purposes)

Given you started from the same template, does the content of a specifically named package in one .EAP file contain, conceptually, the same content or different?  If different, how is it different and why?

Can you give some specific examples (in summary) of specific packages (in their structure and content), where the problem is and what you are trying to achieve?

HTH,
Paolo

[Damir]

here we go:
1. and 2. - correct
3. partly correct: I wish to use the same packages in other projects as such, not necessarely combine them into one package. It is OK to put all "sibling" imported packages into a new package in the new project

I'm not sure what you mean under "component instances". I think in our case the answer would be that we allways have "all". when something is changed in the package, it should reflect and be seen in all projects.

there is no impediment (other than GUID conflict) to place all the current set of packages into one .EAP file (for refactoring purposes)

yes, packages contain conceptually the same content. that was the purpose of using template.

I can give you exact structure of them:
- Model package
--business technology model - to be version controled
--use cases model - to be version controled
--SW solution model
----class model
-----application view - subpackages of this package to be version controled
-----information view - to be version controled
---Data model  - to be version controled
--component model - to be version controled
--deployment model - to be version controled
- here can go a package into which above version controled packages from other projects could be placed.

thanks
damir

[Paolo F Cantoni]

here we go:
1. and 2. - correct
3. partly correct: I wish to use the same packages in other projects as such, not necessarily combine them into one package. It is OK to put all "sibling" imported packages into a new package in the new project

I'm not sure what you mean under "component instances". I think in our case the answer would be that we always have "all". when something is changed in the package, it should reflect and be seen in all projects.

there is no impediment (other than GUID conflict) to place all the current set of packages into one .EAP file (for refactoring purposes)

yes, packages contain conceptually the same content. that was the purpose of using template.

I can give you exact structure of them:
- Model package
--business technology model - to be version controlled
--use cases model - to be version controlled
--SW solution model
----class model
-----application view - subpackages of this package to be version controlled
-----information view - to be version controlled
---Data model  - to be version controlled
--component model - to be version controlled
--deployment model - to be version controlled
- here can go a package into which above version controlled packages from other projects could be placed.

thanks
damir

Thanks Damir.  I see I should have been more explicit in defining what "same content" meant.  I really meant "functionally" identical content.  But for the present, not a great matter.

I'm going to work on a more formal response; but, meanwhile, can you confirm:

1) Conceptually you have:

Project A
- Model package
-- etc

Project B
- Model package
-- etc

Project C
- Model package
-- etc

2) Project A may contain a use case Fred, Project B may use the identical Use Case Fred (and I mean identical...) Project C also uses a use case called Fred, but its content is different and it has some extensions.

3) Each project uses an identical component Bill, but each project has its own unique component Mary, dependent on Bill.

If you can quickly confirm or deny these example scenarios, it would help.

Paolo

[Damir]

Hi
1) yes
2) yes, but project C is not adding scenarios to use case that are not to be seen in other projects. Projec C can make extension to that use case (meaning: create link from the use case to other use cases or actors). Or maybe more clear example in data model- if Project C uses (depends) on data model from project A and if something is to be added or changed in data model (table, column, FK...) for project A through project C - it is required immediatly to be seen in project A and any other project using that data model.
3) yes. I would just like to clarify, I'm not talking just about UML Components but classifiers in general (classes, activities...).
thanks for putting your effort in!

[Paolo F Cantoni]

OK Damir,

Each project has an identical structure.  However, that doesn't mean that every project has to have a copy of each element.  In fact, each unique element must appear only once in the entire (consolidated) repository.

Assuming that you agree with that assertion (and if you don't I really don't know how you can fix your problem) we have to refactor your current situation to achieve that.

Once we have a consolidated repository across all projects, we can create individual repositories for each project - each of which is a proper subset of the consolidated repository.

It would appear that your situation is more consistent than ours, but I'll still discuss the some project...

The first step is to create a new, blank repository.

Next you import each project into a separate root (as shown in the post above), stripping the GUIDs.  The original GUID are no longer relevant.

You also need to create two additional projects:
Project Some and Project All.  They have the same structure as the others, but initially NO content.  You can import them in the same way.

Project A
- subordinate packages + diagrams + content (Classifiers)

Project B
- subordinate packages + diagrams + content (Classifiers)

Project C
- subordinate packages + diagrams + content (Classifiers)

Project Some
- subordinate packages (no diagrams or content)

Project All
- subordinate packages (no diagrams or content)

Now comes the hard bit...  Pick one of your projects as the "primary" (if they aren't identical in content, pick the one with the most content).  For the sake of the example, let's take Project B as the "primary".

For each content item (classifier) if the item is identically in all projects, move it from Project B to Project All (in the same part of the structure).  Using the browser, you can move things in bulk, so it's not quite as cumbersome or onerous as it might first appear.

If the item is only in some of the other projects, move it to Project some (again, in the same structure).

if the item is only in project B, then leave it there.

At the end of this process, you have some things in Project All, some things in Project Some and the remainder in Project B.

All the diagrams, however, are still in project B.  Their content will still be as before...

If you are OK so far, we can move onto the next step...  If not, then we should stabilise this far first.

Paolo

[Damir]

when you said "The first step is to create a new, blank repository. ", you mean "new EA project"? OK

during moving of classifiers, other copies of classifiers are deleted. right? (for instance class A is used in project A and B so I moved it to SOME project from project A and deleted its "instance" in project B.

ok, I'm ready to go to next step.

[Paolo F Cantoni]

when you said "The first step is to create a new, blank repository. ", you mean "new EA project"? OK

yes...

during moving of classifiers, other copies of classifiers are deleted. right? (for instance class A is used in project A and B so I moved it to SOME project from project A and deleted its "instance" in project B.

OK, I'm ready to go to next step.

Well, you went a little bit too fast, but no matter.  If you have already deleted the additional copies, then you should have a canonical set of classifiers (no duplicates - unless they are not identical).

Now, the objective of the next step is to create in each real project (A, B, C), diagrams to fit their needs.  That is, for each project you are creating a "view" of the consolidated model that contains the classifiers it needs (and no others).

From your previous descriptions, this should be easily achieved because most of the diagrams should have essentially identical content in each project.

If you understand the concept so far, the question is how to achieve this as easily as possible?

One way would be to again treat Project B as the leader and get it "right" enough - diagram wise.  Remembering that the old GUIDs are no longer relevant, I would temporarily rename Project A and C to Project A-old and Project C-old.  I would then export the new "fixed" project B and reimport as Project A and Project C (stripping the GUIDs).  I would then repeat the refactoring of A and C using the classifiers in A-Old and C-Old respectively.  Once the refactoring is complete, you can delete A-old and C-old.

By this time, you should have a consolidated repository with each unique classifier appearing only once in one of three projects:  Specific (A,B,C), some or all.

Each project has it's own set of diagrams (even if they are duplicates).  If they are true duplicates, you can consider placing them in the some or all project depending on if they have any some content (or exclusively all content).

When this is all refactored.  We can do the last step...

Paolo

[Damir]

From your previous descriptions, this should be easily achieved because most of the diagrams should have essentially identical content in each project.

actually no, but nevermind. there aren't many projects and there aren't many classifiers. Each "sibling" package contains all different content (including special subpackages aswell).

One way would be to again treat Project B as the leader and get it "right" enough - diagram wise.  Remembering that the old GUIDs are no longer relevant, I would temporarily rename Project A and C to Project A-old and Project C-old.  I would then export the new "fixed" project B and reimport as Project A and Project C (stripping the GUIDs).  I would then repeat the refactoring of A and C using the classifiers in A-Old and C-Old respectively.  Once the refactoring is complete, you can delete A-old and C-old.

I'm quite confident that this step is not necessary since each project should have been imported with new GUIDs for each of it's elements because we have imported them with stripped GUIDs

By this time, you should have a consolidated repository with each unique classifier appearing only once in one of three projects:  Specific (A,B,C), some or all.

I have achieved that in the previous step allready.

Each project has it's own set of diagrams (even if they are duplicates).  If they are true duplicates, you can consider placing them in the some or all project depending on if they have any some content (or exclusively all content).
 
When this is all refactored.  We can do the last step...

Let's say I've done that.
ok. let's go to the next step.

[Damir]

Arghhh - when importing package into a project, database specific attributes of data model are LOST! I'll have to do almost all over again but first import resources from the template project. I hope this will work.

[Paolo F Cantoni]

OK Damir,

the last part is actually two parts:

1) You need to decide on what level of granularity of your packages is appropriate for your needs.

(in our case, our product is broken down into a number of subsystems and so we have currently opted to create controlled packages at the subsystem level).

You break the repository into these controlled packages and export them.

2) You then take a copy of the .EAP file and strip all the classifier content, leaving only the packages in their hierarchy across the entire repository.  This is (effectively) your new empty skeleton.  If you add a new project, you export an existing root and reimport stripping the GUIDs to create a new set for that project.

To create a project specific .EAP file, you can take the populated consolidated file and remove all the parts not pertinent to that project - each file will have at least three roots:  Project specific, Some and All.

You can now exchange controlled packages as appropriate between the different projects.  For example, Project A modifies a controlled package in the All hierarchy.  You save [Ctrl+Alt+S] the controlled package out of Project A and load [Ctrl+Alt+L]  the new version into Projects B and C's .EAP file (and, not forgetting, the Consolidated Repository .EAP).

Project C changes a package that is in both it and Project A   (that is, it should be in the Some branch).  you save it from Projected C and load into Project A and the consolidated one.

Project B changes a package that is specific to it.  You Save it from B and Load into the same place in the consolidated one.

Should work a treat!

Paolo

PS Hope you solve your other problem...

[Damir]

Huh... done
Paolo, if you ever come to Zagreb or Dubrovnik in Croatia, I owe you a beer (or wathever is your flavor)

I've adopted the "all" technique. "some" technique is actually a set of special BASE projects in our case but it solved itself quite well.

from now on, new projects will be opened with relatively empty EABase project (with loaded profiles, database types and ALL part of the structure) and then populated by initial hierarchy using import with stripping GUIDs.

Damir