Baseline compare utility - elements without diagrams

[minastaros2]

Hi there,
I am exploring possibilities how to branch and merge projects with baselining and importing / exporting with XMI files.

I changed elements in a diagram, drew a baseline and exported the stuff as an XMI file.

In another project, when I import the whole XMI file, everything is fine.

When I use the compare utility, selecting the baseline in the other file (as well as "Compare Package with XMI file..."), however, I can see all the different elements, but when I select some of them, they are imported without their "parent" diagram. The diagram as such cannot even be selected in the differences list. Only when I select the whole package, the diagram is also imported and the elments are shown correctly.

Do I miss something?

[qwerty]

FWIW: Branch and merge is nice for code. But it's not working for models. It's like saying "Oh, that truck can drive. So I can use it to get my breakfast". But what's a good idea with a bicycle is a bad idea with a truck. Unfortunately this place does not leave enough room to go into details. And one still can prove me wrong. But I'm ready to argue.

q.

[Glassboy]

FWIW: Branch and merge is nice for code. But it's not working for models. It's like saying "Oh, that truck can drive. So I can use it to get my breakfast". But what's a good idea with a bicycle is a bad idea with a truck. Unfortunately this place does not leave enough room to go into details. And one still can prove me wrong. But I'm ready to argue.

I feel this may be a culturally specific analogy, and the linkage between bicycles and breakfasts doesn't travel.

[qwerty]

We call those comparison limping in Germany. They all limp. A bicycle is not a truck - that much should be clear. And a model is not code. And the one or other pair serve different purposes. So what's good for the one tool (don't know the PSI for the tires to make another analogy) is not necessarily good for the other one.

A model serves as a current (!) complex, interwoven structure which serves as vehicle to communicate a common sense about that thing what is call project (the common sense of stakeholders to achieve a goal). Code in contrast has a fixed set of requirements. It's sort of a black box with (probably) known inputs and rules to produce output. You can have slight variations of code which can be tuned towards slightly different goals. The main variables do not change, though. In contrast, a model can not easily tuned towards other goals. It will simply break if not modified at hundreds of places. Eventually you need completely different architectures when changing parameters. Code is way more forgiving.

q.

[Glassboy]

Oh, I understand your point, just not the idiom.  But I learnt a long time ago that German idiomatic phrases and Dutch swear words make no sense when translated into English.

[RoyC]

Would you be thinking of that jolly old English exclamation "Poppycock!", by any chance?

[Paolo F Cantoni]

Oh, I understand your point, just not the idiom.  But I learnt a long time ago that German idiomatic phrases and Dutch swear words make no sense when translated into English.

Most idiomatic phrases make no sense when translated from one language to another - that's why they are idiomatic 

It's like when a medico describes your symptoms as idiopathic - it means "F@@ked if I know".  Idiomatic just means "B@@gered if I know why they say that..."

But it's fun trying to find the origins - as Roy indicates with Paapekak.

Paolo

[minastaros2]

OK, I understand that it doesn't make sense to add or remove single objects to diagrams and then wish to 'merge' them together.

However, in my concrete setup, I had a package with one diagram inside.
I the copy of that project, I added another fresh diagram with some new objects - and exported that whole package.

When trying to import to the former project, in the compare view, I could see the old objects, and the new ones with red triangles.
So I selected all of them with "Add from Baseline", but they are imported without their diagram.
I had expected that at least the second diagram would be imported as a whole with all included objects.


On a bigger picture, I am trying to find out how teams can model "features" in a similar topology as projects evolve.

One example:

The project status quo at a certain release level is "Version 1". Then two independent features are developed, one of them may extend existing components, the other might be a new component. So modelling and then implementing is done in separate 'branches' per feature.

Imagine that the features may be 'experimental', so the decision may not yet be done when they will actually be integrated for release and in which order (maybe one requires long term research and is planned to be integrated some releases later. Nevertheless, the modelling shall be done in an early phase - and the results shall eventually find their way back to the 'main model'). During this time, the 'main trunk model' should stay untouched.

Actually, should it? Somehow I am uncomfortable with the idea that all the 'feature branches' would be working on the same 'one' model. (in contrast, with code, everyone would just get its own copy in an SVN branch and that's it.) Maybe I am thinking wrongly and it is actually not such a big deal in reality.

But I understand that these actions require a more thorough planning concerning organising the changes and the structure of the model than with code.

[Geert Bellekens]

With regards to branches and merging models; many have tried, almost everyone has failed.

I'm not saying it cannot be done, but in most cases it is simply not worth the considerable overhead.

And in most cases I've seen you can live with a mixed model approach. Part of the model is "AS-IS", part of the model is "TO-BE".
Some parts will never be developed, others will.
As long as you have a mechanism to easily spot which features have been implemented, when they were implemented, and who was responsible, you should be fine.

So therefore at most of my clients we use some kind of change management, but not necessarily version control.
We all use the same model, but link our changes to a change object. This change object then usually has a number which allows the user to check whatever tool they are using (Jira, TFS, ...) to figure out the current status of the change.

This has the added benefit that you can spot possible conflicts earlier in the process.

Suppose team A starts work to change component X
Later on team B starts a project that requires component X.

In case both teams work on feature branches they are not aware of each others work.
So team A delivers the project and the change to component X is being merged to the main trunk.

A few months later team B thinks it's ready to deliver, only to find out that component X has been changed in the meantime, resulting in a lot of rework.

Would they have been working on the same model, team B would have known about the work of team A, and they could have avoided the problem.

Geert

[qwerty]

I can confirm what Geert says. The mixed model approach is the best (I know) you can get. We had a master reference set to read only (with either security or version control) and a working model. The tricky part was synching changes to the master created from the working model. This is manual work. But this can be tuned in tricky ways. It is a project inside the project to get a fluid workflow here.

q.

[minastaros2]

Thanks Geert & q.

this is some good insight into reality from you professionals. It confirms my concerns that branch&merge cannot as easily be done as I have expected - on the one hand,
but also guides a good way how to handle changing / growing projects without trying to make it more complicated than necessary - on the other.

min

[Glassboy]

I think there is a tendency to think that tools will solve what is basically an editorial problem.  Same thing happens with CMDBs.

[Glassboy]

Most idiomatic phrases make no sense when translated from one language to another - that's why they are idiomatic 

I was more disturbed by the thought you may not be able to have breakfast if you didn't have a bicycle.  I generally check the forum in a morning when I could happily manage a "full breakfast", and I don't own a bicycle.

[qwerty]

Probably "getting breakfast" is quite different between different cultures. In Germany (and probably many other European countries) it's not uncommon to buy a few things fresh from the bakery for breakfast. As I said: German metaphors are called "limping" - which is a metaphor itself

[Glassboy]

The irony is you've chosen an English word that means different things depending whether it's a verb or an adjective.   

I used to work with a German woman who would often become infuriated with multiple meanings in English.  One day she arrived at my desk furious from some discussion that was happening in the Communications department and asked me "Why can't English have rules?".  I handed her my copy of Usage and Abusage (http://www.amazon.co.uk/Usage-Abusage-English-Penguin-Reference/dp/0140514422).  After I moment or two of perusing it, she declared loudly she was correct and marched off with my book to claim victory.