6. DIDO-TE Information Model

Go to DIDO-TE Cover Page

The DIDO-TE Information Model defines the principal information elements, relationships, and structures used to describe, configure, execute, observe, and evaluate tests within the DIDO-TE.

The Information Model provides the architectural vocabulary and structural relationships used by the DIDO-TE requirements and Concept of Operations (ConOps). It establishes what information exists and how that information is related without prescribing a particular storage technology, serialization format, programming language, database schema, or implementation platform.

The model builds upon [DTE4] DIDO Reference Data Model and extends that model where required by the DIDO-TE architecture.

Purpose

The DIDO-TE Information Model provides a common structural basis for:

defining the subject and scope of a test;organizing test plans, Test Sets, Test Cases, and Test Steps;identifying Test Executables and their Test Arguments;specifying Expected Results;identifying the Test Environment in which testing occurs;representing the participants and Resources required by a test;specifying state, time, network, communication, Configuration, and other governed test conditions;representing Test Results and Test Runs;supporting Traceability among Test Definitions, Test Executions, Test Results, and supporting Evidence; andproviding a structural foundation for the DIDO-TE Concept of Operations and normative requirements.

Relationship to Common Information Types

The DIDO-TE Information Model uses reusable information types defined in Section 5, Common Information Types.

Common Information Types define reusable datatypes, structured types, enumerations, identifiers, names, parameter structures, and other value representations independently of the Information Model classes that use them.

Information Model class definitions reference those common types rather than redefining their structure or semantics within individual class descriptions.

This separation allows a common type to be reused consistently by multiple model elements.

Modeling Approach

The Information Model distinguishes architectural concepts from their implementation.

Unified Modeling Language (UML) class diagrams in this section describe information elements and their relationships. The diagrams are not intended to prescribe object-oriented software classes or a particular implementation technology.

Each model element is described using:

its architectural purpose;its defining characteristics;its attributes, where applicable;the Common Information Types used by those attributes;its associations with other model elements;association multiplicities where established by [DTE4];relevant constraints and architectural interpretation; andTraceability to [DTE4] and DIDO-TE requirements.Where [DTE4] provides an element or relationship, this section preserves that source-model structure unless DIDO-TE introduces a deliberate refinement.

Where DIDO-TE introduces a concept not represented in [DTE4], the extension is identified explicitly rather than being represented as though it existed in the source model.

Relationship to the DIDO Reference Data Model

The initial DIDO-TE Information Model is derived in part from the Testing Package of [DTE4].

[DTE4] includes the following principal testing elements:

TestTest PlanTest SetTest CaseTest StepTest ExecutableExpected ResultsTest ResultTest RunTest Tag[DTE4] also establishes relationships between the testing structure and its execution environment.

DIDO-TE extends this foundation with architectural concepts required for governed distributed testing, including Test Environment Configuration, Nodes, Twin Nodes, Virtual Networks, communication conditions, state control, time control, Validation, Evidence, and other concepts defined by the DIDO-TE requirements.

Relationship to Test Definition

The Test Definition provides the governed specification of what is required for a test.

[DTE4] does not define a model element named Test Definition. The DIDO-TE Information Model therefore derives the structure of the Test Definition from:

the existing testing elements and relationships represented by [DTE4];the Common Information Types used by those model elements;the information required by the DIDO-TE functional requirements; andthe relationships required to connect test specification, Test Execution, Test Results, Validation, and Evidence.The Test Definition model is developed after the constituent testing elements are described so that its structure is derived from those elements rather than imposed independently of them.

Relationship to the Concept of Operations

The Information Model defines the information elements and relationships used by DIDO-TE.

The Concept of Operations (ConOps) describes how actors, capabilities, systems, and processes create, configure, use, exchange, and evaluate those information elements during testing.

Accordingly:

the Information Model defines what information exists and how it is related; andthe Concept of Operations describes how that information participates in DIDO-TE operations.

Relationship to Requirements

The DIDO-TE requirements place normative obligations on the concepts and relationships defined by the Information Model.

In particular, C.3.6 Test Definition Requirements identifies the information that a governing Test Definition is required to specify, identify, or reference.

The Information Model provides the structural basis for those requirements. Annex C remains the normative source of DIDO-TE conformance obligations.

Contents

Source

The initial structure of this section is derived from the Testing Package of [DTE4] DIDO Reference Data Model and is refined by the DIDO-TE architecture and requirements.

Notes for Editors

Treat [DTE4] as the source for existing modeled elements, relationships, attributes, multiplicities, and types.Use Section 5, Common Information Types, for reusable datatype, structured-type, enumeration, identifier, name, parameter, and other common-type definitions.Do not redefine Common Information Types on Information Model class pages.Do not silently correct anomalies in [DTE4]. Identify corrections or architectural refinements explicitly.Use focused UML class diagrams for individual model elements before producing the integrated Information Model.Preserve [DTE4] multiplicities where they are known unless a deliberate DIDO-TE refinement is approved.Distinguish [DTE4] source-model content from DIDO-TE extensions.Do not treat UML classes as implementation classes.Develop the Test Definition structure from the constituent model elements and the obligations identified by the DIDO-TE requirements.Use the integrated diagram in Section 6.14 to show the resulting DIDO-TE Information Model after the individual elements have been reviewed.

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.