PM32187: RHP/GW: nested objects under the wrong header in DOORS

APAR status

• Closed as program error.

Error description

• With Rhapsody 7.5.2,  I am seeing the following issue when
  exporting model
  elements to DOORS.  I have a simple test case model containing
  two
  packages with each package containing a single class.    In
  Gateway I then
  select to export the model document to DOORS.  For the export
  'Source' I
  select the package containing the first class and for the types
  to be
  exported I select Operations and Primitive Operation under the
  Types field.
  With both the 'Keep children of filtered elements' and 'Do not
  maintain
  elements location' options selected, I exported the operations
  associated
  with the class in this package to a new module in DOORS.
  
  This results in an Operations (Header) object being created in
  the module
  containing nested objects representing each of the Operations in
  the class.
  I then repeated the export but this time adding the second
  package to the
  'Source' list.    The module then contained a second Operations
  (Header)
  object with the second class's operation objects nested under
  it.
  
  In the DOORS module I then moved the operations under Header
  objects that I
  created to represent different functionalities of my 'test case'
  system;
  assigning the operations associated with a class such that some
  of the
  operations were assigned to/nested under one functionality while
  other
  operations were assigned to/nested under another functionality.
  
  The issue I am seeing is that if in Rhapsody, I subsequently add
  new
  operations to one of the classes and then export the packages to
  DOORS,
  instead of placing the new operations under a generic
  'Operations' header
  object so that I can then easily locate these operations and
  then move them
  under the desired functionality header object, Gateway is
  placing the newly
  exported operations under the existing functionality header
  objects.    It
  appear that each newly exported operation for a class is being
  placed after
  the existing class operation in the module that alphabetically
  precedes it
  (as defined in the Rhapsody model).    In many cases this
  results in the
  newly exported operation being placed under the incorrect
  functionality
  header object.
  
  Gateway actually inserts the object near to another exported one
  known in the Gateway (either the parent, or the previous sibling
  object).
  Consequently, several objects exported at once will be arranged
  according to the order visible in the Gateway.
  
  The check box 'Do not maintain elements location' only disables
  the reordering of objects that already exists in DOORS.
  
  I guess that the customer expects that the export to DOORS must
  not try to insert objects near to another object that already
  exist in the DOORS.
  Instead he wants the export to DOORS to always create new
  objects starting from the same position, right?
  Maybe we should provide an option for that?
  'Always insert objects starting from the top of the module',
  please suggest something else if the title is not clear.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  RHP/GW: nested objects under the wrong header in DOORS
  

Problem conclusion

• Fixed in 7.5.3.1
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  TLOGIC RHAPSODY

• Fixed component ID

  5724V74RP

Applicable component levels

• R752 PSN

     UP