August 30, 2011

Wrestling with RAM relationships

Written by

One of the most powerful features of Rational Asset Manager is its ability to relate Assets to each other.  I touched on this ability in my last blog post when describing how we modeled a release structure.  However, as  is the case with most things there is a price to be paid for this power.  In this post I describe why relationships are great, how they can be difficult and what we did to make them easier to use.

What makes relationships so great is that they allow the dependencies between Assets to be mapped.  Further to this, they provide a very easy way to navigate these relationships.  Each Asset has its relationships displayed as hyper links within the Assets general page, and this makes it very easy to navigate between Assets, see below:

The previous screen-shot is of the relationships within a SubSystem Release Asset called BAR.  A SubSystem Release has relationships to its parent System Release(s) and also the Components of the SubSystem.  From this example we can see that this SubSystem Release is related to 2 versions of the System Release and has 3 separate Components.  The diagram below shows where this Asset lives within the release hierarchy.

Now here’s where things get tricky.  When creating a new version of an Asset all of the relationships are copied into the new version. This is good as you would not want to recreate them each time. However it does lead to some unfortunate side effects, as depicted in the following example.

In this example we want to create new versions of the ACME System Release and BAR SubSystem Release.  The FOO SubSystem Release will stay the same.

Start State

So this is what our start state looks like:

Create new version of System Release

When we create version 2.0 of the ACME System Release the relationships from version 1.0 are copied over.  This is OK for the moment as we have not yet created version 2.0 of the BAR SubSystem Release.

Create new version of SubSystem Release

When we create version 2.0 of the BAR SubSystem Release the relationships from version 1.0 are copied over.

However, we now have a number of incorrect relationships.  Version 2.0 of BAR has a relationship to version 1.0 of ACME.  Obviously not what was wanted.  Also we no longer want version 1.0 of BAR to point to version 2.0 of ACME.  The incorrect relationships are highlighted in the diagram below.

This problem only gets worse as more new versions of assets are created for a release.  And we are not even describing  creating new Components in the above example.  To fix this you would manually remove the incorrect relationships but this is both error prone and time consuming.

Ensure new SubSystem Release version only relates to the new System Release version

A new version of a SubSystem Release should only ever have one parent, the System Release for which it was created.  Later on the SubSystem Release may end up belonging to multiple System Releases, but at this point in time it should only relate to a single System Release.  So we remove the relationships to all other System Releases.

Ensure previous SubSystem Release version does not point to new System Release version

As we saw earlier, when we created a new version of the ACME System Release all the relationships were copied over.  This meant that we ended up with a relationship to version 1.0 of BAR.  However, since we have created a new version of BAR we no longer want to relate to version 1.0 of BAR from version 2.0 of ACME.

And now things look as they should.

However, fixing things up manually is less than ideal.  If you look again at the tasks above then you can see that the manual solution is really a high level design for an automated solution, as below:

Create new version of System Release

For each new version of a SubSystem Release

Create new version of SubSystem Release

Ensure new  SubSystem Release version only relates to the new System Release version

Ensure previous SubSystem Release version does not point to new System Release version

So in this case the solution to the problem is to use automation to create new versions of Release Assets.  And if you are spending the time to automate then you might as well go the extra mile and create a framework that can be used for other purposes as well.  Which is exactly what we did.
Tags: ,

Categorised in: Uncategorized

This post was written by Des Drury