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

DNG - Base artifact links vs module context links

Questions
Tags
Users
Badges
Sean F
(1.3k●2●52●162) Aug 11 '18, 11:35 a.m.
There is a distinction between linking to/from a base artifact vs linking to it in a module context but what are people doing in practice?

If all artifacts are in modules and there is no CM then is it better to use module context links or base artifact context links?

If we have a simple project (no CM) with 2 modules Stakeholder and System and each contains some St and Sys reqs then users can create links by dragging and dropping between the module representations of the respective artifacts and these will be module context links.

They can alternatively open the artifact and create the link in the artifact sidebar in which case the links will be base artifact links.

It seems like it could be quite easy to accidentally end up with a mixture of the 2 types. Is there any way to enforce all link creation as being either module context or base artifact?

4

2 votes

6 answers
6,841 views
2 votes

6 answers

Permanent link
Sean F
(1.3k●2●52●162) Aug 14 '18, 8:45 a.m.
Or even if there is a way to tidy up afterwards when users have accidentally created a mixture of base and module link contexts.

Like if we could move any module links to become base artifact links (or vice versa - assuming all artifacts are in modules and appear only once)

0 votes

Permanent link
David Reilly
(69●7●42) Aug 15 '18, 11:25 a.m.
Sean,

You're asking the question that has other users of the software (like me) scratching their heads. I get the locality of modules. I suppose if users are making comments or want to show dependencies within a specific group of requirements, they'd prefer the locality of making them within the module. 


The design decision that Jazz has made is the assumption that link locality is the only reason users would link in the module. Users like myself and those I work with daily do not want to create "local" links by default. They are linking in the module because it is structural and cogent. Lack of context in artifact folders and collections makes linking impossible. 

While I'm griping, it's actually funny that there is an explicitly "local" link type called "Parent of" and "Child of." However, you aren't capable of linking by attribute with the parentBinding values you carefully populated. Extracting those values requires you to extract your requirements from every module you've ever created. GL, HF. 

Possible Fix:  There should be a way to fix this. Here's a general flow:

1. Query your project with OSLC / REST. (View -> Module)
2. GET the XML for the module. Loop over MB artifacts.
3. Extract uri and etag values. 
4. Replace "/MB_" with with rrm-core value to get the "base URI"
5. Update base uri artifact with Core etag value. 
6. POST artifact back to project.  

If there was some easy way to fix this issue, I'm sure they would have done it by now. As it stands, it's been an issue for reporting and user interaction which has no "out of the box" solution to my knowledge. 

DNG v6.0.2iFix015


0 votes

Permanent link
Sean F
(1.3k●2●52●162) Aug 16 '18, 10:01 a.m.

Thanks for the suggestions David.

Yes, it would be good of there were explicit options to choose to always default to either module or base context for all link operations within a given project.

I am also interested in opinions on which context is best even if there is no way to force that context as a default.

Most requirements projects will have requirements created in modules and most will not require the artifacts to appear in more than one module.

So in that scenario it would seem that there should not be any difference between using either module or base artifact context in theory but in practice is that true?

Would be interesting to get a straw poll of practitioners to say which of the 2 contexts they are recommending or mandating for their users and why.

It seems to me that base artifact linking would be the better default in case artifacts are reorganised into different modules at a later date.

0 votes

Permanent link
Cliff Sadler
(62●1●7●17) Sep 29 '19, 4:05 p.m.

 A year later, plus a couple of months, and it appears this is still not resolved, nor is there any guidance of substance.  Here's a reason that I would like to syncronize base artifact links and module links:

The closest thing to a traceability wizard in DNG exists only for artifacts.  It's called Tree view.
So, let's either make that available in Modules, or find a way to synchronize the links, or be able to view base artifact links in modules.
I see no way to direct a ReqIF or migration file to use base artifact links.  They are always module links, even if I don't check the box to create modules for non hierarchical modules.  BTW, this is all data coming from DOORS 9.6.1.10.

Are there any improvements in 9.7 in this area?
Any tricks that haven't been documented here?

0 votes

Comments
Sean F
Oct 03 '19, 12:37 p.m.
Hi Cliff,

i have only recently installed 9.7 and i have not yet tried the migration tool with 9.7

But I am not aware of any new features in 9.7 that would affect the migration tool's behaviour.

Permanent link
Henrik Mattfolk
(11●1) Mar 24 '21, 8:05 p.m.

My perspective after 2 years in the CM environment: The Modules are necessary to provide structure to your requirement Set, I would argue that linking to base artifacts makes little sense but it all depends on how you define your ontology. Trace reports will work independent on which method you are using but you need to be consistent. An improvement would be to be able to configure what the link dialog defaults to, Module or Folder. This is by far the greatest confusion among new and even experienced users. 

The great benefit a Module will bring is that you can keep a pool of artifacts that you can add or drop to/from the set making scope adjustments easy. However, a trap here is that when you add an artifact back to the module, from a trace link perspective it is considered a new instance, you have to create new incoming and outgoing link. That behavior makes it possible to link independently to and from multiple instances of the same artifact in the module, which for us makes no sense. Due to this behavior we now never drop requirements from modules just in case we have to add them back. Originally we used the module to define the requirement Set (the scope is not defined by your pool of base artifacts) but we surrendered this approach to instead use an attribute to indicate in our out of scope. Makes it more complicated to report and use links explorer but all in all a better solution for us. I think the tool should allow you to add back individual requirements to the set (module) from a different stream (so the instance identifier is identical) in case you dropped a requirement and want to add it back to the module without loosing at least the incoming links.   

0 votes

Permanent link
Michael Egan
(21●1) Feb 06 '23, 4:38 p.m.

 I hate that we have to do this, but I've had this same issue pop up a couple of times and I IBM keeps giving me the same answer.  The steps below will allow you to transfer your base artifact links over to module links.

Open your list of artifacts.
Configure the page so that all your links are displayed
Select all your artifacts
Export your artifacts to CSV
In the CSV file reduce all links down to just the DOORS ID number (Make sure not to change the DOORS ID).
Change the column name for the links.
Save the CSV file
Import the CSV file into DOORS (Assign the new column as "Text")
Open your module
Use "Link by Attribute" to link the module artifact to the original link using the new Text attribute.

It is a royal pain, but it fixes the issues with links.

0 votes

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,019

Question asked: Aug 11 '18, 11:35 a.m.

Question was seen: 6,841 times

Last updated: Feb 06 '23, 4:38 p.m.

Confirmation Cancel Confirm