It's all about the answers!

Ask a question

DNG - parent/child requirement artifact - How to force the children Requirement artifacts to inherited the values of the artifact attributes/links from the parent?

Mohamed Samatar (13512) | asked Dec 10 '18, 3:42 p.m.

At the creation of the children requirement artifacts: How to force the children Requirement artifacts to inherited the values of the artifact attributes/links from the parent? 

2 answers

permanent link
Sean F (38712129) | answered Dec 10 '18, 4:32 p.m.
Attribute inheritance is not supported in DNG like it was in DOORS Classic.

This is a symptom of the loose coupling between artifacts and their module (and hence hierarchy) which is a usability problem affecting many areas of DNG.

This loose coupling is also the reason why users having to understand the distinction between between module context and base artifact links and deal with the usability hurdles which that entails.

It would be useful if DNG had the option to have a tighter more transparent binding between artifacts and their module. (since 99.9% of artifacts do not appear in more than one module)

This would also then make working with links much simpler.

It would also enable attribute value inheritance to be implemented which is a feature sorely missed.

David Reilly commented Dec 10 '18, 4:52 p.m.

Sean - 

Don't want to hijack Mohamed's thread here, but any chance you could take a look at my response and send me recommendations if you have any? I'm in much the same boat. Considering a "scorched earth" policy where we link all data programmatically against base artifacts with my defined example, though, we would run the risk of increasingly complex graphs.


permanent link
David Reilly (695) | answered Dec 10 '18, 4:48 p.m.
edited Dec 10 '18, 4:54 p.m.

Seems like it takes ingesting data in the application to realize that you needed to be creative with your data structure. Don't worry - I have the same problem. 

This is the solution that I am currently grappling with. I still need to test this fully, but it should work IN THEORY. 
  1. Link BASE Parent Artifacts (Headings) to Module with "Embeds" link type.
  2. Link BASE Children artifacts to Headings with "Child Of" link type
  3. Update module with attributes.
Artifacts "Embedded" in Module with Artifact Type (Attribute 1) = "Document" AND
Artifacts with "Parent of" links

That's ultimately the cross-section you're looking for, right? Additionally, I imagine that you could do the same thing for headings containing specific attributes, where you can filter additionally; 

Same linking structure above, update headings and modules with specific attributes.
Artifacts "Embedded" in a Module with Artifact Type (Attribute 1) = "Document" AND
Artifacts with "Parent of" links with Name (Attribute 2) containing "This is a heading." 

If someone from Jazz / IBM wants to chime in, that would be great. I'm also on DNG v6.0.2 so I don't know if there's a shorter path to this. 


Sean F commented Dec 11 '18, 2:17 p.m. | edited Dec 11 '18, 2:17 p.m.
If that is working for you David that is great.

But these workaround solutions with Child Of links tend to need manual refreshing every time the source data changes I find.

Would be great if the tool had a more concrete sense of module hierarchy so that the old DOORS Classic features like inheritance could be road-mapped and the module vs base links user confusion could be dealt with.

David Reilly commented Dec 12 '18, 11:26 a.m.

Thanks Sean for taking a look. 

Could you clarify what you mean by manual refreshing every time the source data changes? Does this mean that we would not be able to run a report or filter against the source link using criterion from the target? (ex: Requirements where last modified date <= "7 days ago and module attribute assignee = current user) 

I absolutely do agree, though, that forked capabilities between OSLC and REST have made it rather difficult to implement this system effectively without flaw. 

Your answer

Register or to post your answer.