Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

What are the rules for Link Validity when the associated artifact is modified?

Questions
Tags
Users
Badges
Daniel Barbour
(265●3●23) Feb 18 '16, 11:45 a.m.
This question arose in the course of trying to write requirements and tests for Link Validity in CLM 6.0.1.

On a simple level - a change to an artifact's attributes (such as Title/Description/Text content) the Validity should (and does) revert to Suspect. 

For example: If the Link Validity has been set to Valid for artifact 1001 - and the Text Content for artifact 1001 changes from "old text" to "new text" - the Link Validity will now be shown as Suspect.

What we've found, however, is that History plays a role - If the Link Validity for the new value is set to Valid and then the artifact is again changed back to a prior value where Link Validity was Valid (i.e. back to "old text") then Link Validity is NOT reported as Suspect - but is instead reported as Valid.  Or - more accurately - setting the artifact data to a prior value for which a Link Validity state was assigned causes that earlier assigned Link Validity state to be reported for the artifact.

Is this behavior indicated above - what is Expected/Intended for Link Validity?  The answer will affect how we plan to test Link Validity - it was not what we expected (our expectation did not encompass any 'history' contribution, rather - any change (even to an older value) would result in Link Validity being set to Suspect .. this seemed to be a safer choice (and less complicated) to ensure that the associated Links were always reconsidered by the team after a change..

Product Version/Patch: CLM 6.0.1 iFix002a

0 votes

1 answer
4,372 views
0 votes

Accepted answer

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Feb 18 '16, 2:20 p.m.
Yes, remembering (and using) historical validity information is an essential feature of the Validity Service (and is one of the primary advantages it has over previous Suspicion Service).   This is especially important when you are developing many variants of a given system, since this means that validity assertions made in one variant are automatically re-used in other variants that share those same artifact states (versions).    For example, suppose the platform team has produced a new baseline of a system component, and they wanted to get that new baseline into the hands of all the customer project developers, without waiting until they have performed all the validity checks.   With the Validity Service, they can do so, and whenever the platform team (or any of the variant developers) assert the Validity of some relation, that Validity information immediately appears in all of the other customer projects that are sharing artifacts from that new baseline.
Daniel Barbour selected this answer as the correct answer

0 votes

Comments
Daniel Barbour
Feb 18 '16, 3:57 p.m.
 Hi Geoff, While I think I understand the intent - I am not sure if it is directly applicable to the scenario I described so I'll beg for a little more time :) .  You refer to reflecting the Validity information in all other projects sharing the same baseline.  I agree with that goal - but the scenario I outlined is much narrower - no baselines have yet been created, there are no variants - so I am working within the current stream.  Effectively, the current behavior is that the Link Validity State of the current artifact will be set to that of the most recent history copy of the artifact that matches the current artifact's signature (title/description/text..etc).    From my perspective - I don't think we would ALWAYS want to say that you can simply reuse the most recent historical value (that earlier setting 'might' have been made by mistake).  It might sometimes be true but the only way to ensure it IS looked at again would be to restore the Suspect state on 'any' change.  If nothing else I would look for a settable mode to allow me to configure the system so it always defaults to Suspect.

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 19 '16, 1:54 a.m.
Note that baselining does not affect the behavior of the Validity Service (it doesn't care whether or not a particular version is captured in a baseline) ... that was just a way to set up the re-use example.   So the sharing of the validity information is based solely on the content of the versions on each end of the link.   Also note that Validity Status is on the link between two artifacts ... not on an artifact.  A particular link is flagged as "suspect" if no human has ever declared that the two linked artifact versions are valid for that link type.   An artifact does have a "link validity summary status", which is the minimum Validity Status of all of the links from that artifact to an upstream artifact. It appears that you are not looking for link validity information, but rather "what artifacts have change since some specific point in the past".    In a versioned world, that information is not obtained from Link Validity, but rather by comparing your current configuration with the configuration at that specific point in the past (captured by a baseline).   This is done with the "compare" command.

Daniel Barbour
Feb 19 '16, 10:14 a.m.
I am aware of the configuration comparison capability and acknowledge its value.  And I recognize that Link Validity state is separate from the artifacts.  Though I may have a different preference, I will ultimately accept the answer that it is working the way you, and the preponderance of users, intend for it to work (which, in summary, is that once a human has EVER set the Link validity state for the link between two artifacts that it will always be returned to that state regardless of the trajectory of changes made to the artifacts in the interim.  If the trajectory again touches an earlier state matching one where validity had once been set - the link validity will, again, be reported for that state). 

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 19 '16, 10:49 a.m.
One way to think about it is that Link Validity is for a binary relationship with well defined semantics.   So for example, if the artifacts are numeric formula, and the binary relationship is "equals", then if some human has asserted that the "equals" is valid for the two expressions "1+2" and "3", then any time you see the "equals" link type between the two artifacts whose content are "1+2" and "3", the system should tell you that this link is Valid".   If you modify the content of the second artifact to be "4", the link will become "Suspect", but if you switch the second artifact back to "3", the link will again become Valid.   You wouldn't want the system to respond by saying "you changed the second artifact, so the status must be Suspect". In our domain, the artifacts are things like test cases and requirements, but with the same rationale ... if someone has stated that the content of this test case is a valid test for the content of this requirement, then if you make some modifications to either the test case or requirement, but then restore the test case and requirement to the valid content, the system should tell you that the test case is a valid test for that requirement.

Daniel Barbour
Feb 19 '16, 10:51 a.m.
 Thanks Geoff - that explanation is helpful.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,145

Question asked: Feb 18 '16, 11:45 a.m.

Question was seen: 4,372 times

Last updated: Feb 19 '16, 10:51 a.m.

Related questions
Confirmation Cancel Confirm