Reporting on applications that have versioned type systems

Before explaining how to create a type-filtered data source, it’s helpful to look at an example of how such changes might occur and their consequences. Suppose in the IBM Engineering Requirements Management DOORS Next application you have a global configuration SGC Production Stream that has contributions from three different streams (on the left).

Imagine that over time some changes were made to the artifacts in these DOORS Next streams in the context of their global streams. Eventually, three sets of changes were made, resulting in four global baselines (on the right). Typically, these baselines capture the state of an artifact and its attributes when it was created.

So, here is the related data in DOORS Next. For the global baseline SGC Production Stream (baseline 1), there is a corresponding local configuration in DOORS Next.

You can use Manage Component Properties to check the artifact types and their possible attribute values

Suppose at this time you made changes to the Software Requirement artifact type, adding two new attributes: Color and Part number.

To see the possible values for these attributes, look on the Attributes Data Types tab. The Color attribute has possible values of red, green and blue. The Part number attribute is of the String data type, which can contain any text entered by a user.

Now you can see that DOORS Next recorded the version and state of these attributes and their types as a part of the local baseline as well as the global baseline. Each artifact can have values for these attribute types. This example reflects the versioned type system for the application. You can also view the state of any artifact at the time when that baseline was created.

Two new values were added for the Color attribute, yellow and purple. A new attribute Part reference was created with the String data type. In addition, for the Software Requirement artifact type the Part number attribute was removed and Part reference was added.

Later, in the context of SGC Production Stream (baseline 3) the administrator made some other changes. They changed the values of the Color attribute, renaming purple to mauve with the same RDF URI (so that Report Builder recognizes this as the same value) and removed yellow.

Finally, they made further changes to the attributes in the context of SGC Production Stream (baseline 4). They deleted the existing Part number attribute from the Software Requirement artifact type and created a new attribute with the same name but without an RDF URI (to help Report Builder to recognize this as a different value).

This example depicts poor planning of the properties and enumeration values of the Software Requirement artifact type. It leads to a confused presentation of attributes when creating reports in Report Builder. Such evolution of the custom attributes results in inconsistent type definitions and overlapping of attributes.

In Report Builder, you can create reports for a specific global or local configuration by using the Lifecycle Query Engine scoped by a configuration as a data source. This data source is system generated and uses type system models that merge the attributes across all versions of the type system (custom attributes, types, links, and enumerations). However, you might see multiple attributes with the same or similar names when you add conditions to the report, as shown in the following image.

Ideally, the type systems should be planned in such a way that they evolve into a compatible and consistent system that avoids any confusion when selecting attributes for conditions in reporting.

However, for those type systems that have not been or cannot be planned, Report Builder includes an important feature that can help users to build efficient reports.

When you create a type-filtered data source scoped to the global baseline SGC Production Stream (baseline 1), then in the reports section, you'll see only the types and attributes specific to SGC Production Stream (baseline 1). Similarly, you can create data sources scoped to SGC Production Stream (baseline 2), or SGC Production Stream (baseline 3), or SGC Production Stream (baseline 4). The result is a clear representation of types and attributes when adding conditions to a report, as shown in the following image.