doors dxl unsolved mysteries - solved! - galactic solutions group

DOORS DXL Unsolved Mysteries - Solved!

Michael SutherlandGalactic Solutions Group LLC

3221 Eastern Ave.Rochester Hills, MI 48307-5529

[email protected]

Abstract:

The Telelogic product DOORS has provided its users with a comprehensive set of functionalityto manage Requirements across the Enterprise. To further extend the capability of DOORS andallow users to customize the product to meet their specific needs, the makers of DOORS haveprovided a powerful Application Programmer Interface (API) called the DOORS ExtensionLanguage (DXL). This API gives the user access to the internal DOORS functionality, andunlocks the power of the tool beyond those functions present from the user interface.

The following are typical user needs:

(1) A View exists in a Module, and it is desired to copy that View to another Module, includingFilter criteria.

(2) An existing data set with numbered hierarchy is imported from Excel, and it is desired tobuild that hierarchy in the imported Module.

(3) A user desires to avoid traversing a complex Folder Hierarchy to locate and open a Module.

Through the knowledge and application of DXL, these needs can be addressed.

Biography :

Michael Sutherland has 11 years experience working with automotive suppliers andmanufacturers. He has been working with General Motors for 7 years, and is currently aconsultant to General Motors Powertrain and North American Operations (NAO) ManufacturingEngineering Divisions, developing and deploying Systems Engineering Processes and Tools.Michael has a Masters Degree in Electrical and Computer Engineering from Oakland University.He also specializes in the Application of the DOORS Enterprise Requirements Suite, mentoringand teaching application, customization (DXL), and information modeling to a wide variety ofclients across the nation.

Telelogic Americas' 2001 User Group ConferenceDOORS DXL Unsolved Mysteries - Solved!

© 2001 Galactic Solutions Group LLC Author: Michael [email protected]

Copying Views

Scenario:

A user desires to Copy Views from one DOORS Module to another.

Background:

A View in DOORS consists of a display of the following information from a DOORS Module:

Columns- Content (Attribute, Layout DXL or Main - Object Number, Heading and Text )- Properties (Color, Graphics, Info, Justification, Title, Width)

Objects- Selection - Filtering on Attribute Values- Order - Sorting on Attribute Values

Other View Options in DOORS can be saved:



Strategy:

Most properties of a View are available through documented DXL commands.

View properties can be read from Source Module and set in Target Module using documentedDXL commands such as:

View Properties Column PropertiesuseAncestors( ViewDef v )useDescendants( ViewDef v )useCurrent( ViewDef v )useSelection( ViewDef v )useColumns( ViewDef v )useFilterTables( ViewDef v )useGraphicsColumn( ViewDef v )useShowExplorer( ViewDef v )useGraphics( ViewDef v )useOutlining( ViewDef v )useCompress( ViewDef v )useLevel( ViewDef v )useSorting( ViewDef v )useFiltering( ViewDef v )useShowDeleted( ViewDef v )useShowPictures( ViewDef v )useShowTables( ViewDef v )useShowLinkIndicators( ViewDef v )useShowLinks( ViewDef v )useTooltipColumn( ViewDef v )useWindows( ViewDef v )

for Column c in Module m {} main( Column c ) dxl( Column c ) attribute( Column c ) color( Column c ) graphics( Column c ) info( Column c ) justify( Column c ) title( Column c ) width( Column c )

These commands cover most properties of a View. One very important property of a savedView that cannot be determined by using commands in the DXL manual is the Filter Criteria.

There are documented DXL commands to get references to DOORS datatypes such as:

Project p = current ProjectFolder f = current FolderModule m = current ModuleObject o = current ObjectTrigger t = current TriggerPageLayout pl = current PageLayout



Issue:

How can the Filter criteria be obtained from a saved View in a Module?

Why not load the view and try:

Filter f = current Filter

This command is not in the existing documentation, but it does work. It returns a reference tothe current Filter in Source Module, which can be applied directly to the Target Module with thefollowing command:

set( Module m, Filter f )

Does this sound too good to be true? It almost is. There is one problem to be addressed. AFilter refers to Attributes and Enumerated Attribute Type Values in Source Module that may notexist in Target Module.

Applying the Filter in such a situation will cause a DXL error such as:

-R-E- DXL: <Line:###> unknown attribute (AttributeName)or-R-E- DXL: <Line:###> illegal value 'False' for type 'Integer'or-R-E- DXL: <Line:35> null attribute definition parameter was passed-I- DXL: <Line:123> execution halted

Strategy:

Use the documented

stringOf( Module m, Filter f )

function, which returns a string such as:(Created By == Michael Sutherland) AND ((Created Thru == Manual Input) OR (Created Thru == Copying))

Solution:

Parse Source Module Filter string so that individual Attribute Names and Values are known, andthen check against Attribute Names and possible Values in Target Module. Do not copy View ifit is not possible to apply Filter in the Target Module without errors.



Application Interface:

Note:

The Sort criteria can also be obtained as a string with the following DXL commands

Sort s = current Sortprint stringOf( Sort s )

This returns a string such as:

Ascending Last Modified By and Ascending Last Modified On

The Telelogic documentation incorrectly refers to stringOf( Module m, Sort s ).

Further investigation needs to be done to determine if the Sort criteria can be copied to theTarget Module.



Building a Hierarchy

Scenario:

A user imports a Requirement Specification, and desires to build a Hierarchy from the importedinformation.

Background:

DOORS has existing tools to import hierarchy structure the following imports:- Word Processors

- MS Word, Framemaker, Interleaf, Rich Text- uses Heading Levels style (TOC)

- Plain Text- uses typed Heading Number strings

There is no such functionality for a specification imported from Excel, when Hierarchy Numbersare typed in a Column.

Example:



Strategy:

A four-pass algorithm will be used to build the Hierarchy.

Pass One - Check the validity of the Level Indicator Strings, to make sure that the SectionNumber sequence can actually be built.- Format: "1.2.a" is invalid- Sequence: "1.2" followed by "1.4" is invalid

Pass Two - Set all Objects to Level 1- May not be necessary, but the Pass Four algorithm used requires this as a precondition.- Uses Skip List of Objects in Module to preserve order

Pass Three - Make each blank the last Child of the previous non-blank- For situations where Requirements and/or supporting information (Graphics, Tables, etc.) do

not have typed Section Numbers

Pass Four - Build DOORS Hierarchy using the following algorithm:



Example:

Before the Hierarchy Build is executed, the Module has no Hierarchy.- Section Number is the imported representation of the desired Hierarchy.- Object Number and Level show the current state of Hierarchy in DOORS.

After running the Hierarchy Build routines, the desired Hierarchy is achieved.



Bookmarking a Module

Scenario:

The user desires the ability to bookmark a Module, so they do not have to traverse the Folderhierarchy every time they start DOORS.

Background:

In a large DOORS Project, there may be numerous Modules in Folders located many levelsbelow the Database root.

In DOORS 5, each Module has an "item Unique ID", which is a 8 digit hex value- hexadecimal (base 16) digits can be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f

Executing the following command

print uniqueID( item( fullName( current Module ) ) )

prints the following output, which is the "item Unique ID" for the Module.

00000b0a

The "item Unique ID" is also used to name the directory in a DOORS database where data forthe Module is stored. DOORS users are insulated from this by using the DOORS Clientconnected to a DOORS Database Server (DDBS).



Solution:

The "item Unique ID" is used so the bookmark will be preserved if Module is renamed ormoved. The following features of DXL will also be used to assist in bookmarking the Module.

User Configuration Files:DOORS Database conf (Configuration) Files are text files stored in Database. These are notDOORS Modules, and are not visible to the user through the DOORS client interface. Files oftype confUser and confSysUser are specific to each User defined in the Database

Configuration files are used so that bookmarks to Modules are stored in Database and backed up,do not reside on any individual client PC, and are available to user no matter which PC they useDOORS from (assuming Bookmarking software is installed).

DOORS Menu Modification:Functions can be added to the DOORS Project Explorer Right-Click Menu by adding additionalcreateMenu() functions in the createDBExplorerListPopup() function found in the DOORSApplication Configuration file $DOORSHOME\lib\dxl\config\baseWindowMenu.inc . Extracare is required when developing and distributing of such modifications to DOORS Client PCs.




Adding a Module to the list of Bookmarks (from DOORS Explorer right-click Menu):

Opening a Module from the list of Bookmarked Modules:



Obtaining Software:

DOORS Users are encouraged to obtain, use, share, and improve upon the utilities mentioned inthis presentation.

For a free copy:

Contact: [email protected], or download from http://galactic-solutions.com.

doors dxl unsolved mysteries - solved! - galactic solutions group

Documents