DOORS 9.6 DB module linkage summaries

Seems to me I have seen something like this somewhere. I would like to find a tool that would allow me to export a summary of all linkages within a set of DOORS 9.6 formal modules. Individual link visibility is not necessary but direction is.

E.g., if module A and module B have multiple links between them running in both directions, a summary of the following linkages is desired:

  A ---> B

  B ---> A

Graphic representation is not required but would be nice if executed well.

The overall intent is to support analysis efforts to:

  - Provide an illustration of overall module dependencies in the database, and

  - Assist in efforts to determine where requirement looping may exist.

Although this DB contains a couple of hundred modules, most routing is currently through a common link module, so the initial solution might be as simple as extracting a summary of all active linksets (i.e., contain at least one link) from a given link module and present them with nodal redundancy removed.

Any suggestions?

Re: DOORS 9.6 DB module linkage summaries
llandale - Wed Jan 14 18:03:49 EST 2015

Querying existing linksets:

• doesn't tell you if any links actually exist
• doesn't handle inter-project linking well.

This may get you going:

Skip skpLinkSets = createString()  // KEY: 'string' NameSourceFull; DATA: 'string' NameTargetFull

GetLinkSets(string NameModule)
{  m = read(NameSource, false, true) // open standard view
   for o in m do
   {  for l in o ->"*" do
      {  NameTarget = fullName(target(l))
         put(skpLinkSets, NameModule, NameTarget)   // ignore duplicate entries
      }
      for lRef in o <-"*" do
      {  NameSource = fullName(source(lref))
         put(skpLinkSets, NameSource, NameModule)
      }
   }
close(m)
}   // end GetLinkSets()

for every module in the Project  //<- don't recall exact syntax here
{  GetLinkSets(moduleName)
}

for NameTarget in skpLinkSets do
{  NameSource = (string key skpLinkSets)
   print NameSource "\t->\t" NameTarget "\n"
}

-Louie

Re: DOORS 9.6 DB module linkage summaries
JWiseman - Thu Jan 15 12:53:13 EST 2015

Thanks Louie. I'll have a look at this. I've dabbled with DXL but our local tools support has disabled DXL editing for all engineers, so refining a tool (or even a view) is a bit tricky--i.e., load it into your local addins and see if it works, etc.

-Jeff

Re: DOORS 9.6 DB module linkage summaries
DOORSWizard - Thu Jan 15 14:56:27 EST 2015

I think it's a very poor idea to limit who can use DXL, a much better thing to do would be to have a good access control scheme in place to ensure that the correct people have the ability to make changes. DXL is very easy to start with and can a tremendous productivity boost for programs and organizations. If an engineer is willing to learn to make himself or herself more efficient I don't think the 'tools' folks should be standing in the way of that.

Re: DOORS 9.6 DB module linkage summaries
JWiseman - Wed Jan 21 11:33:14 EST 2015

I agree completely. Unfortunately the powers that be at this location believe that only the tools support group should be able to perform DXL editing operations. In general, nobody on the requirements management team has this capability so if I need a view to be tweaked (e.g., reorder the attributes) I must put in a ticket to get a tools person to edit the layout DXL for me.

As far as the access control scheme goes, it is rather over-simplified, so it will be a while until we can evolve this to enable more engineers to do work for themselves that presently requires a tools person.