DXL attribute to determine status

llandale - Tue Nov 22 14:57:13 EST 2011

[1] AttrDXL and Layout have the natural context of "this" object, represented by variable "obj" which already has the Handle of "this" Object. Its a mistake to loop through all objects in the module when inside an AttrDXL or layout.

[2] You cannot see an incoming link unless the other source module is open. The DXL manual (section "Finding Links") has the code to first find the incoming "LinkRef" for this object, which lets you get name of the source module which you can open.

[3] Your code seems to presume that the "Link" has an attribute saying whether the source object is "Passed" or not. I doubt that's true, more likely the source module has that attribute and the Source Object has that value.

[4] Your code seems to get the current status of the (target) object "o" in order to determine its own status (Astatus = o."Verification Status"). That recursive logic gives me the HeeBeeJeeBees and violates your original statement that the status is based (only) on the status of incoming linked objects.

Lets start over, letting me take some liberty in guessing what is really going on.

LinkRef lr
Link    lnk
bool    HasPassed = false   // true when any linked object has "Passed"
bool    HasFailed = false   // true when any linked object has "Failed"
string  BStatus, AStatus
Object  OSource
//   Open up modules that target this Object for links
for lr in obj <-"*" do
{  read(fullName(lr), false, true)   // Open it, even if its already open
}
//   now we can see all then "Link"s
for lnk in obj <-"*" do
{  oSource = source(lnk)
   if (null oSource)   continue  //???
   BStatus = oSource."Verification Status"
   HasPassed = HasPassed or BStatus == "Passed"
   HasFailed = HasFailed or BStatus == "Failed"
}
if     ( HasPassed and  HasFailed) AStatus == "Partially Passed"
elseif( HasPassed and !HasFailed) AStatus == "Passed"
elseif(!HasPassed and  HasFailed) AStatus == "Failed"
elseif(!HasPassed and !HasFailed) AStatus == "Untested"
else{}   // all cases covered
obj.attrDXLName = AStatus

Not sure that's exactly right but should get you going.

• Louie

SystemAdmin - Tue Nov 22 15:27:50 EST 2011
Thanks for your replies and help! :D

I've deleted the Object o statements and changed o to obj ... taken out 'all' (I couldn't recall if that was correct placement, but obvioulsy it wasn't) and deleted the first for loop.

The incoming links (my B requirements) have an attribute called "Verification Status" with type enumeration Passed, Partially Passed, Failed, and blank (nothing selected) as options/values. I am trying to determine the verification status of my A requirements based on the status of the B requirements. The A requirements not Passed unless all B requirements are set to Passed and other combinations. Hopefully I am not confusing anyone :| So I am assuming that the source object (the linked B reqs) has a value. By calling Bstatus = inlink."Verficiation Status", I thought I was pulling that value for an object, not the module's attribute and Astatus = o."Verification Status" to 'fill in' the value for the dxl attribute ???????

llandale - Wed Nov 23 10:32:38 EST 2011
You can create a link attribute and populate it, and it would represent information about the relationship, B->A in your case. For example, if object B1 "satisfies" both A1 and A2 you could create a text attribute in the "satisfies" link module "Satisfies Info" that could describe which portion of B1 is satisfying which portion of A1. Once you create the link, you would get the Properties of B1, go to the Link tab, edit a link, and modify the link-value.

Custom Link attributes are uncommon; but you can get routine info from them e.g. <datCreated = lnk."Created On">.

I don't think that's what you are doing. Requirement B1 is either Passed or Failed or Not Tested and that's information about the requirement, not about its relationship to other linked objects (A1). Thus it seems to me "Verification Status" is an Object attribute in the source formal module, not a Link attribute in the link module. So I think you don't want to say <Bstatus = lnk."Status"> but rather <Bstatus = oOther."Status">

If the status of A is solely determined by the accumulation of the inlinked B requirements then you need not query the value of A. In fact, you cannot do that in an attr DXL used to calculate the value since when its queried the 1st time the module is opened it has no value, and you would end up in some infinate loop except that DOORS just up-chucks when you try.

If the status of A can be set explicitely OR be based on the values of in-linked objects then you have a bigger issue. Perhaps you could have two attributes, a normal enumerated "Actual Status" and a DxlAttr "Current Status". The Current Status attr-DXL would be set to the Actual Status if there is one, otherwise calculated based on the linked statuses. You would have some procedure looking for Requirements with a "Current Status" of "Passed" but that have no Actual Status, encouraging folks to make a mindful decision to set the Actual Status to Passed.

The way I coded the 1st response would presume that A is a requirement and B is a test; A is "Passed" when all its tests have "Passed". The previous paragraph would make more sense if A and B are requirements at different levels.

• Louie

SystemAdmin - Wed Nov 23 17:04:42 EST 2011
I appreciate your feedback. I think my error was trying to extract an object attribute by calling a link module, if I am understanding your comments correctly. Also, I guess I wasn't to clear on what exactly I am trying to accomplish.

The B requirements are not test reqs, they are the subcontractor/subsystem requirements (our level 4 requirements). The A requirements are the system requirements (level 3 requirements). Levels 1 and 2 being our stakeholder and program requirements that I did not mention in the original post.

In an effort to not manually set the verification status of the system requirements, I wanted to take the verification status of the subsystem requirements (that is filled in by the subcontractors after their test efforts) to determine the status of the system requirement.

My goal was to read the incoming (child) requirements from the various level 4 (subsystem) modules to determine the status of the system requirement. Having that output displayed and eventually exported to excel for future comparison (btw, I am not trying to code the export in this script), since the output will not be saved in the module. Running the script when necessary, ensuring updated results, since the subcontractors will be updating their modules until completion.

The "Verification Status" attribute from the subsystem modules have the following values to select from;

• Passed
• Partially Passed
• Failed
• Blank/No input

• If all incoming links of the subsystem's Verification status are Blank, then the verification status of the system is left Blank
• If all incoming links of the subsystem have Verification status of Passed, then the verification status of the system is Passed
• If all incoming links of the subsystem have Verification status of Failed, then the verification status of the system is Failed
• If all incoming links of the subsystem have Verification status of Partially Passed, then the verification status of the system is Partially Passed
• If there is at least one Passed or Partially Passed incoming link of the subsystem status (can include a Failed if present), then the status of the system is Partially Passed

llandale - Mon Nov 28 18:21:41 EST 2011

So your instructions indeed ignore the current status. Good.
My bad, you need this at line 11:

read(fullName( source (lr)), false, true) // Open it, even if its already open

I think your "if" instruction sequence is slightly inadequate, even when changed to an elseif sequence. It does suggest that if both "passed" and "blank" the result is "partially passed". Missing seems to be both "failed" and "blank"; so I'll go ahead and assume that results in "blank". If so, you need a new variable for accumulating any "Blank" results and the perfect truth table would have 16 lines; so lets narrow it down to this instead:

if      (!Pass and !Part and !Fail)           L3Status = ""  // All sub-system blanks, or no sub-system links at all
elseif ( Pass and !Part and !Fail and !Blnk) L3Status = "Passed"  // All sub-system passed
elseif (!Pass and !Part and  Fail and !Blnk) L3Status = "Failed"  // All sub-system failed
elseif ( Pass or   Part)                     L3Status = "Partially Passed" // Some passed or partially-passed
elseif (                     Fail)           L3Status = ""    // Failed and blank results
else                                          L3Status = "Louie made a mistake"

In an effort to verify the above code, lets remove the 1st two "elseif" statements and combine the last two, and we end up with this; when the "if" fails then surely the "elseif" must be true; and if so it doesn't matter how many other "elseif"s there are after the "if":

if      (!Pass and !Part and !Fail)           L3Status = "X" 
elseif ( Pass or   Part  or  Fail)           L3Status = "Y"
else                                          L3Status = "Louie made a mistake"

• Louie

You have a problem if there are any sub-system linked objects that are not requirements and have no Status at all; you would need a mechanism for idenitifying these objects and ignoring them inside your loop.

I think the system should be "Failed" if any sub-system has "Failed"; in which case it's "Partial" when there has been some sub-system success but no failure so far.

Having System Status completely dependant on the SubSystem test results means there are no tests done on these level 3 system requirements; if so I suggest that's dubius. Seems to me you would WANT to do some "system" level testing on these requirements: The SubSytem table-top may be "flat" and the sub-system legs may be "stout" and the sub-system brackets may be "sturdy", but you want to put marbles on the "System" table to make sure it's "level". Later on your "Stakeholders" will want to set up a dinner for 4 on their flat stout sturdy level table with room for a baby chair to fit snuggly up to it.

If so, this code will generate an attribute that could be called "SubSystem Verification Status" which is auto-generated, but you would add the ability to do System tests and set the "Verification Status" of the system requirement manually. The System tests would be eligible only when all the sub-system tests have "passed". Stakeholder attr-DXL would query the "Verification Status" and "SubSystem Verification Status" of their linked system requirements.

SystemAdmin - Wed Nov 30 13:29:25 EST 2011
Yes, there will definately be testing at the system level. This is to check the verification status for the subsystems. Possibly using the results as a metric to track progress. The system test status would be manually entered, but would not begin until the subsystem has completed testing. And then using the system verification status, recycle the code to produce the L2 status (the stakeholder reqs).

I've since added a 'Blank' and 'Waived' option. Blank for incomplete items and Waived for requirements that were given waivers (due to costs, vendor testings, etc...)

I've attached my latest code w/ comments for the if statements. While I've cut down my errors while debugging, I am now getting a DXL run-time error,
-R-E- DXL: <Line:14> null Object parameter was passed into argument position 1
-I- DXL: execution halted

I would expect that even if incoming items were blank, the column would still be created and just be empty

SystemAdmin - Wed Nov 30 13:29:25 EST 2011
Yes, there will definately be testing at the system level. This is to check the verification status for the subsystems. Possibly using the results as a metric to track progress. The system test status would be manually entered, but would not begin until the subsystem has completed testing. And then using the system verification status, recycle the code to produce the L2 status (the stakeholder reqs).

I've since added a 'Blank' and 'Waived' option. Blank for incomplete items and Waived for requirements that were given waivers (due to costs, vendor testings, etc...)

I've attached my latest code w/ comments for the if statements. While I've cut down my errors while debugging, I am now getting a DXL run-time error,
-R-E- DXL: <Line:14> null Object parameter was passed into argument position 1
-I- DXL: execution halted

I would expect that even if incoming items were blank, the column would still be created and just be empty

llandale - Wed Nov 30 14:54:05 EST 2011
Line 14 is OK in a layout, variable "obj" is pre-declared and pre-populated with "this" object.

But I've seen this sort of wierd error when the current view has busy adjacent columns with layout and attr-DXL. Get rid of some other columns and try again.

Or you first you could do a little testing; add this at the top:

• if (null obj)
• { obj = obj__()
• display "obj__() used: " identifier(obj) ""
• }

• Louie

SystemAdmin - Wed Nov 30 17:14:42 EST 2011
I've restarted my session and opened the module in standard view, only showing the Object ID and text columns all to no avail. I am still receiving the same error except now it is referencing line

display "obj__() used: " identifier(obj) ""

If it is not recognizing obj, do I need to re-declare it to not pass null? Declare the current module and object?

Not sure if it matters, but I am using 9.3

SystemAdmin - Wed Nov 30 17:48:54 EST 2011
I finally got it to read in obj ... everything works. Thanks so much for all your help!