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 Common Information Types are derived from [DTE4] DIDO Reference Data Model, including its conceptual datatypes, enumerations, structured testing types, and supporting mappings.

Common Information Types provide reusable definitions for information such as:

• identifiers and keys;
• names and descriptions;
• dates and versions;
• namespaces and URIs;
• file and document references;
• sizes, counts, and other quantified values;
• parameter definitions and parameter values;
• controlled enumerated values;
• status values;
• test verdicts; and
• other values referenced by DIDO-TE Information Model elements.

Defining these types independently allows the Information Model to distinguish between:

• the semantics and value structure of a reusable type; and
• the semantic role of an attribute that uses that type.

For example, a Test, Test Plan, Test Set, Test Case, and Test Step may each have an identifier. Those attributes may use the same DIDO ID Type while retaining different semantic roles within their respective classes.

Section 6, DIDO-TE Information Model defines information-model 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 retains its semantics independently of the class or attribute that uses it.

[DTE4] treats its conceptual datatypes as implementation-independent semantic types.

DIDO-TE preserves the distinction among:

• Conceptual Model types, which define meaning, value distinctions, and conceptual constraints;
• Logical Model types, which map conceptual types to implementable logical representations; and
• Physical Model types, which map logical representations to concrete platform-specific datatypes, encodings, and constraints.

A physical representation does not redefine the semantics of its conceptual type.

For example, a conceptual identifier may be represented as a UUID in one logical model and encoded using a character representation in a particular database realization. Those representations remain mappings of the conceptual identifier rather than independent definitions of its meaning.

Likewise, a conceptual Enumeration may be physically represented using text, an integer, a database domain, or another encoding. The physical representation does not replace the controlled conceptual value space.

[DTE4] contains:

• 26 UML DataType elements;
• 8 UML Enumeration elements; and
• 4 UML PrimitiveType elements.

The database and conceptual-model mappings provide additional realization information for many of these types.

For purposes of DIDO-TE documentation, Common Information Types are organized as:

• Scalar Types — reusable values such as identifiers, names, dates, counts, sizes, and references;
• Enumeration Types — controlled semantic value spaces;
• Structured Types — types composed from subordinate values or definitions; and
• Primitive Types — underlying model primitives used to construct other types.

The documentation categories do not change the UML type classification represented by [DTE4].

The following Common Information Types have been identified from [DTE4] and its supporting model mappings.

The list is maintained alphabetically by normalized conceptual name.

• Command Line Type
• Copyright Grant Type
• Copyright Permission Type
• Copyright Private Use Type
• CPU Counter Type
• DIDO BLOB Type
• DIDO Date Type
• DIDO Description Type
• DIDO ID Type
• DIDO Key Type
• DIDO Name Type
• Document Type
• Domain Namespace Type
• Email Address Type
• Email Type
• Encryption Key Size Type
• Filename Type
• Gibibyte Type
• JSON String Type
• Mebibyte Type
• Namespace Type
• Node Count Type
• Parameter Definition Type
• Parameter Direction Type
• Parameter List Type
• Parameter Type
• Phone Number Type
• Release Number Type
• Release Status Type
• Size In Pixels Type
• Social Network Type
• Spoken Language Type
• URI Type
• Verdict Type
• Version Type
• Yes No Type

The conceptual-model mappings identify the following reusable scalar types:

The conceptual representation describes the source-model mapping and does not prescribe the physical representation used by an implementation.

The conceptual-model mappings identify the following Enumeration types:

• Copyright Grant Type
• Copyright Permission Type
• Copyright Private Use Type
• DIDO Key Type
• Email Address Type
• Email Type
• Parameter Definition Type
• Parameter Direction Type
• Release Status Type
• Social Network Type
• Spoken Language Type
• Verdict Type
• Yes No Type

Some [DTE4] Enumerations define explicit semantic value spaces.

Examples include:

Each Enumeration leaf page records the complete [DTE4] value space before DIDO-TE determines whether any normalization or extension is required.

The Testing Package contains reusable structures used to describe test parameters and related values.

These include:

• JSON String Type;
• Parameter Definition Type;
• Parameter Direction Type;
• Parameter List Type; and
• Parameter Type.

These types are documented independently of Test, Test Plan, Test Set, Test Case, Test Step, Test Executable, or any other class that uses them.

The available model and database mappings show that conceptual types may have platform-specific realizations.

For example:

The PostgreSQL mappings are implementation realizations. They do not replace the conceptual definitions or semantic value spaces defined by [DTE4].

A DIDO-TE implementation MAY use another logical or physical representation provided that the required conceptual distinctions and constraints are preserved.

Each Common Information Type leaf page identifies the Information Model attributes known to use that type.

For example:

As Section 6 is developed, these relationships provide reverse traceability from reusable types to the classes and attributes that use them.

The source material exposes several issues that require deliberate review during normalization of the DIDO-TE Information Model.

In particular:

• [DTE4] contains the source name Parameter_Diretion_Type; DIDO-TE normalizes the display name to Parameter Direction Type while preserving the original source name in traceability records.
• [DTE4] contains the source name ParameterLlist Type; DIDO-TE normalizes the display name to Parameter List Type while preserving the original source name in traceability records.
• [DTE4] contains the source name Parameter_Definition_Type; DIDO-TE normalizes the display name to Parameter Definition Type.
• ParameterLlist Type appears to reference Parameter_Definition_Type where the intended structure may have been Parameter_Type. This requires model review rather than an editorial correction.
• Test_Result.Verdict references version_type even though [DTE4] defines a separate Verdict Type. This requires model review.
• conceptual and PostgreSQL representations are not always identical. Differences in representation are treated as mappings rather than silent changes to conceptual semantics.
• an Enumeration represented physically as text or an integer retains its conceptual value space independently of that physical encoding.

A change to spelling, spacing, capitalization, or naming style may be treated as editorial normalization when the original meaning is preserved.

A change to permitted values, relationships, cardinalities, constraints, or semantics constitutes a model refinement and requires an explicit rationale and disposition.

• [DTE4] DIDO Reference Data Model, conceptual datatypes, Enumerations, Primitive Types, Testing Package types, and supporting model mappings.

• Maintain Common Information Types independently of the Information Model classes that use them.
• Use the normalized conceptual type name as the DIDO-TE page title.
• Preserve the exact [DTE4] source-model name on the applicable leaf page for traceability.
• Maintain the explicit 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.
• Distinguish conceptual semantics from logical and physical representations.
• Do not define a conceptual type solely by its PostgreSQL, programming-language, serialization, or wire-format realization.
• Record known conceptual-to-logical and logical-to-physical mappings on the applicable type page.
• Document all known Information Model classes and attributes that use each type.
• Preserve complete Enumeration value spaces from [DTE4] before proposing changes.
• Do not silently correct source-model structures, constraints, references, or value spaces.
• Identify any DIDO-TE normalization or refinement explicitly.
• Add newly discovered reusable types to the explicit Contents list in alphabetical order.
• Do not create a new Common Information Type solely because an individual class has an attribute with a unique semantic role.