Traceability from model to originating pattern?

[David OD]

Situation:

We have a UML Pattern that has been developed, and is let's say at "version 1".  I create model elements based upon that pattern, and the world is a wonderful place!

I then update the pattern, and it is now at version 2.  I can reapply the pattern to my model using the merge option, and lo! the changes are applied.

However, somebody then asks about traceability of the model elements.  They want to know which pattern was used for each element, and more importantly which version of that pattern.

As far as I can see, there is nothing in the instantiated classes that indicates what pattern was used or which element within the pattern was used.

Questions:

1. Is this a question others have pondered and solved?  I can't see anything by searching the forum.

2. Am I missing something that is present but is not visible in the UI (or is a bit obscure)?

3. Can anybody suggest a way of providing traceability for this scenario?  A key feature to be addressed is making sure that subsequent applications of the pattern (for later versions) cause the traceability to be updated.

Any thoughts or comments are welcome.

[beginner]

my anserws so far:
1. no
2. no (AFAIK)
3. you could include a version tag in each profile element. Or you make snapshots on introduction of the new profile and see later which element had been added before. However, I wonder how much sense it makes to know about the profile version. The elements should reflect the current modeling situation. So if I'm a bit wiser today I will update the profile and off we go.

b.

[David OD]

@b: Regarding your 3rd point, I would normally agree.  However I work in the health sector, where everything is about traceability to maximise clinical safety.  

Interestingly I have tested out using tagged values, but they don't seem to updated when a merge occurs.  I have asked Sparx to explain if this is expected behaviour.

[beginner]

You're right. The synch does not update values but just ensures that new tagged values are introduced. So this won't work (except Sparx would be willing to enhance the synch).

b.