5. Common Information Types

Go to DIDO-TE Cover Page

Common Information Types define reusable value structures used by multiple elements of the DIDO-TE Information Model.

These types are defined independently of the classes, attributes, associations, or other information-model elements that use them. A Common Information Type may therefore be referenced by multiple model elements without redefining its structure or semantics at each point of use.

The initial set of Common Information Types is derived from the Testing Package and referenced supporting packages of [DTE4] DIDO Reference Data Model.

As additional portions of [DTE4] are reviewed, this section may be extended with additional reusable types.

Common Information Types provide a common structural basis for:

• identifiers;
• names;
• descriptive text;
• file and URI references;
• parameter definitions and values;
• enumerated values;
• result verdicts;
• version information; and
• other reusable values referenced by DIDO-TE Information Model elements.

Defining these types independently allows the Information Model to distinguish:

• the semantics and structure of a reusable type; from
• the meaning of an attribute that uses that type.

For example, a Test, Test Plan, Test Case, and Test Step may each have an identifier. The corresponding attributes may use the same identifier type while retaining different meanings within their respective classes.

Section 6, DIDO-TE Information Model defines classes, attributes, associations, and multiplicities.

Attributes within those classes reference the Common Information Types defined in this section.

Conceptually:

Common Information Type
          ^
          |
          | used by
          |
Information Model Attribute
          |
          | belongs to
          v
Information Model Class

A Common Information Type does not acquire different semantics merely because it is used by different classes.

[DTE4] contains several categories of reusable types:

• types defined directly within the Testing Package;
• primitive types represented within the Testing Package;
• shared DIDO types referenced from other model packages; and
• external UML or implementation-neutral primitive types referenced by model elements.

This section preserves the names and structures represented by [DTE4].

Where a source-model name contains an apparent typographical or structural anomaly, the original [DTE4] name is preserved when describing the source model. Any normalized DIDO-TE name or structure is identified explicitly as a model refinement.

The following Common Information Types have been identified during the initial review of the [DTE4] Testing Package.

The list is maintained alphabetically by type name.

• dido_id_type
• dido_key_type
• dido_name_type
• Do
• document_type
• filename_type
• JSON String Type
• Parameter_Definition_Type
• Parameter_Diretion_Type
• Parameter_Type
• ParameterLlist Type
• String
• URI
• uri_type
• Verdict_Type
• version_type

For purposes of DIDO-TE model review, the identified types can be considered in the following broad categories.

The categories above organize the documentation and do not change the type hierarchy represented by [DTE4].

The initial type inventory exposes several issues that require review during normalization of the DIDO-TE Information Model.

In particular:

• [DTE4] spells Parameter_Diretion_Type without the second “c” in “Direction”;
• [DTE4] spells ParameterLlist Type with an apparent additional “l”;
• ParameterLlist Type contains a values attribute typed as Parameter_Definition_Type rather than Parameter_Type;
• Test_Result.Verdict references version_type even though [DTE4] defines a Verdict_Type enumeration; and
• some external primitive types referenced by [DTE4] cannot be identified reliably from the extracted model resource alone.

These issues are recorded as source-model findings. DIDO-TE does not silently correct them.

Each type page should distinguish:

• the structure represented by [DTE4];
• the architectural meaning of the type;
• known uses of the type;
• identified source-model issues; and
• any deliberate DIDO-TE normalization or refinement.

• [DTE4] DIDO Reference Data Model, Testing Package and referenced supporting model packages.

• Maintain Common Information Types independently of the Information Model classes that use them.
• Maintain the explicit type links under Common Information Types while the leaf pages are being created. These links may be removed after the indexmenu reliably discovers all child pages.
• Preserve [DTE4] type names and spellings when documenting source-model content.
• Do not silently correct source-model type names, structures, or references.
• Identify any normalized DIDO-TE type name or structure explicitly as a model refinement.
• Document known uses of each type on its leaf page.
• Where a type is used by multiple Information Model classes, link each use back to the corresponding Section 6 model-element page.
• Add newly discovered reusable types to this page in alphabetical order.
• Do not create a new Common Information Type solely because an individual class has an attribute with a unique semantic role.