Copy child links to parent

SystemAdmin - Thu Mar 17 20:04:21 EDT 2011
Just before we start getting medieval with DXL here - can I ask why you would like to do this?

For example, is this an attempt to co-join an object that contains the lead in phrase of a bullet list where each bullet item is a child object? Or some other reason/

Your answer may spawn some alternative solutions that may not require DXL at all or maybe a simple DXL solution.

SystemAdmin - Thu Mar 17 21:27:40 EDT 2011
Paul,
Thanks for your quick reply. The time difference is working to my advantage.

I'm very new using the forum and I didn't describe what I want to do very clearly.

I have a module which contains multiple scenarios each of which, of course, contains several scenario statements. These scenario statements are linked to requirements in another module. I’d like to be able to list all of the requirement which are linked at the scenario level vs. scenario statement where the links actually are.

I’m open to any approach to provide this list.

Rita

SystemAdmin - Thu Mar 17 22:18:59 EDT 2011
OK, think I understand now.

There are two possible avenues here.

1. You have indicated that you don't want to manually create links to help out here but I'm afraid that this is one of your options that you'll need to consider - create internal links from the scenario statement objects up to their respective parent Scenario Level object then use the Analysis Wizard to follow those links all the way to the Requirements Module and display the info you want to see e.g. Unique ID, the requirement text etc.

2. Use the Analysis Wizard to create a DXL Layout column showing the information you want to see from the linked requirements objects. Then modify the DXL layout script that the Wizard has created so that it can detect scenario level parent objects and aggregate the displayed link info of the child scenario statement objects - not easy - can see many traps\exceptions that have to be catered for, and the DXL Layout script will most likely need to be converted to a DXL Attribute type. If I'm not making sense to you then option 1 may still be the way to go. I recommend waiting overnight to see if Louie Landale and\or Mathias Mamsch or others have anything ready to use or alternatives to consider.

SystemAdmin - Thu Mar 17 22:18:59 EDT 2011
OK, think I understand now.

There are two possible avenues here.

1. You have indicated that you don't want to manually create links to help out here but I'm afraid that this is one of your options that you'll need to consider - create internal links from the scenario statement objects up to their respective parent Scenario Level object then use the Analysis Wizard to follow those links all the way to the Requirements Module and display the info you want to see e.g. Unique ID, the requirement text etc.

2. Use the Analysis Wizard to create a DXL Layout column showing the information you want to see from the linked requirements objects. Then modify the DXL layout script that the Wizard has created so that it can detect scenario level parent objects and aggregate the displayed link info of the child scenario statement objects - not easy - can see many traps\exceptions that have to be catered for, and the DXL Layout script will most likely need to be converted to a DXL Attribute type. If I'm not making sense to you then option 1 may still be the way to go. I recommend waiting overnight to see if Louie Landale and\or Mathias Mamsch or others have anything ready to use or alternatives to consider.

Mathias Mamsch - Sun Mar 20 09:47:05 EDT 2011

The complexity of the DXL layout is really dependend on the structure of the Module. As it sounds, the Szenario Statements are somewhere below the szenario statement. If so this is a pretty easy DXL, since we can use the Analysis Wizard to do the complicated work:

1. First make a DXL Layout that will display the information from the requirement module that you are interested in. It will display it on the Szenario statements, but we are about to change that.

2. Convert the Layout DXL in a DXL attribute by "Tools/Support Tools/Convert Layout DXL to attribute DXL". A DXL attribute which is named "DXL for Inlinks" or something like that will be created. Rename that attribute to "Requirement Information".

3. Now we can create a pretty simple DXL layout, that will collect the information from the child objects and display it. It will look something like this:

// modify this function so it will return true if o is a szenario object
bool isSzenario (Object o) { 
   // assume you have an object type 'Szenario Type' 
   if (o."Szenario Type" "" == "Szenario") return true
   return false
}
 
// modify this function so it will return true if o is a szenario statement object
bool isSzenarioStatement (Object o) { 
   // assume you have an object type 'Szenario Type' 
   if (o."Szenario Type" "" == "Szenario Statement") return true
   return false
}
 
// modify this function so it will return a skip list with all szenario statement objects
// for the given Szenario object
Skip findSzenarioStatements (Object oSzenario) {
   Skip skResult = null
   // ignore non Szenario objects
   if (!isSzenario oSzenario) return skResult
 
   // we will return a skip list, so lets create it
   skResult = create() 
 
   // easiest case: Szenario statements are parented direcly below the szenario objects
   Object oStatement =  null
 
   for oStatement in oSzenario do {
      if (isDeleted oStatement || !isSzenarioStatement oStatement) continue
      put (skResult, oStatement, oStatement) 
   }
 
   return skResult
}
 
// Now collect the data for the current object
Skip sk = findSzenarioStatements obj 
if (null sk) halt // do nothing for non szenario objects
 
// create two temporary Buffers, one will get the attribute value, one will get the final result
Buffer buf = create() 
Buffer objData = create()
 
// loop over all szenario statements for the szenario object
Object oSearch; for oSearch in sk do {
    // read the Requirement Information attribute from the statement
    // we created it using the wizard and converted it to a dxl attribute (see post)
    objData = oSearch."Requirement Information" 
    // append the attribute to the result buffer 'buf' if something is shown
    if (length objData > 0) {
       if (length buf > 0) buf += "\n"
       combine (buf, objData, 0)
    }
}
 
display tempStringOf buf // display the result
// delete all the stuff we created
delete sk
delete buf
delete objData

Hope this helps, regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

SystemAdmin - Mon Mar 21 13:50:37 EDT 2011
Mathias,
Thank you so much for providing the dxl.
I understand what this dxl is trying to do, and I am getting some assistance to make the changes correctly. I also have some questions.

In my module, the scenario objects are all at object level 2 and the scenario statements are at level 4, so this is easy to check for. However, you have the comment:
// easiest case: Szenario statements are parented direcly below the szenario objects
Since this is not true, how does this change the dxl?

Also you have in red "\n" which I interpret that it needs to be changed, but I don't know to what I should change it.

It is very generous of you to help me with this.

Rita

Mathias Mamsch - Mon Mar 21 16:14:00 EDT 2011

Hi Rita,

regarding finding the szenario statements. If the szenarios are on level 2 and the statements are on level 4, there is something in between I guess (probably some headings?). So lets call that: UnknownLevel3Object. The easiest way would be to loop over all level 3 objects (childs of the szenario) and then loop over their childs (level 4 szenario objects):
 

// second-easiest case: Szenarios are two levels above the szenario statements
   Object oStatement =  null
   Object oUnknownLevel3Object = null
 
   // oSzenario is a level 2 object, loop over its childs (level 3 objects) 
   for oUnknownLevel3Object in oSzenario do {
 
      // the childs of the level 3 objects should be szenario objects, loop over them 
      for oStatement in oUnknownLevel3Object do {
         if (isDeleted oStatement || !isSzenarioStatement oStatement) continue
         put (skResult, oStatement, oStatement) 
      }
 
   }

or the more general, more complex, more elegant, whatever way, that will handle ALL levels below the szenario objects

// will add all childs of o  (of all hierarchies below o) to sk for which the filterFunction returns true
Skip filterChilds (Object o, Skip sk, bool filterFunction(Object) ) {
   Object oSearch; 
   if (filterFunction o) put (sk, o, o)  // add the object first if the filter function returns true 
   for oSearch in o do filterChilds (o, sk, filterFunction) // recursion over all childs, adding them if applicable
   return sk // convenience, return the skip, so we can call ' return filterChilds(...) '
}
 
// uses filterChilds to find all objects below oSzenario that are Szenario-Statments, independent of the level 
Skip findSzenarioStatements (Object oSzenario) {
   // ignore non Szenario objects
   if (!isSzenario oSzenario) return null Skip 
   // return a filtered list of szenario statements that are below oSzenario 
   return filterChilds (oSzenario, create Skip, isSzenarioStatement) 
}

The red color of the attributes or the "\n" is only the syntax coloring of string literals here in the forum. The "\n" is only a line feed that will separate the lines of the final output. No need to change here.

I did not try the code myself, I just hope it works as is ...

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS