T-VEC Tablular Modeler

From T-VEC Wiki
Jump to: navigation, search

The T-VEC Tabular Modeler (TTM) is an environment for developing and managing tabular requirements models for defect analysis and automated test case generation.

Features of the TTM include:

  • Requirement modeling
  • Requirement management
  • Model decomposition
  • Requirement-to-test traceability
  • Automatic expression formatting
  • Integration With T-VEC Vector Generation System (VGS)

TTM is easy-to-use. It was designed to support building and translating SCR-style specifications into a T-VEC project. Model checking capabilities help ensure translation succeeds without errors.

Models in TTM have been used to support requirement defect identification as well as support for unit, integration, and system testing.


Recent Changes

The T-VEC Tabular Modeler (TTM) 4.5.0 is now generally available.

Primary Modeling Features/Enhancements:

  • Added support for 1-Dimensional Array variables
  • Improved character type and string type support
  • Improved model include mechanism to allow for selecting multiple include models
  • Added the concept of Local table variables for specifying and utilizing persistent state information.
  • Improved expression formatting (allows formatting of expressions even when there are model check errors)
  • Improved navigation from error/warning messages to actual error location and model elements
  • Improved interface for conditional table cells (vertical scrollbar, multiple row delete)
  • Now supports the specification of an alternate (i.e. non-default) report directory
  • Auto-fix identifiers function now works for local elements (function parameters, modes, structure fields)
  • Enhanced the Assignment column auto-fill feature to fill a new column with appropriate structure and local elements and values when possible
  • Enhanced find function
    • More search locations (all available navigable location)
    • Search results from Mode Machine transition tables and requirement descriptions are now available.
    • Improved search filter allows searching for local elements independently from the parent
  • Initial set of TTM library functions can now be found in <INSTALL_DIR>\translators\ttm\lib
  • Default/demo TTM test driver schema file and perl routine file can now be found in <INSTALL_DIR>\translators\ttm\test_drivers. This schema is targeted to code produced by Simulink's rtw code generator. Although they require some user configuration, they should help point the way to producing test drivers from TTM requirement models targeted to code generated from Simulink design models.
  • Added default map file variables to .map files that are referenced in the demo TTM test driver schema file.

TTM Model Checker:

  • Improved floating point value checking
    • Points out floating point constants with too many significant digits
    • Points out the use of degenerate forms of floating point constants. Values such as ".1" or "1." are now required to be in the more canonical form "1.0" or "0.1".
  • Improved checking for duplicated and/or bad identifiers
  • Improved assignment expression syntax checking and formatting
  • Added support for binary operator XOR ('^') and NOT ('~')

TTM/DOORS Integration:

  • Enhanced the model manager to work better with DOORS integration
  • Enhanced navigation from DOORS to TTM, the navigation will always bring up a TTM GUI with the correct model if one exists.
  • Improved user-friendliness of the DOORS integration dialog
    • Now is resizable to allow viewing of long module names
    • Now allows multiple selection of doors module to add, synchronize, and delete (4.3.0 -10/08)
    • Now allows synchronization through the context menu of a DOORS item (4.3.0 -10/08)

Please see the Release Notes for more details on the changes in this release.

Requirement Modeling

Requirement modeling describes behavior in terms of the interfaces to the system or component (box). The model requirements represents "what the box should do" as opposed to "how the box should do it." Sometimes used to model represent properties rather than actual behavior.


The tabular modeling approach is derived from the Software Cost Reduction (SCR) method developed by the Naval Research Lab (NRL). The SCR Toolkit was the first tool for modeling using the SCR method [1].

SCR Core Capabilities

In SCR the functional view of a system is defined using behavioral elements to specify the set of relations between entities that represent the interfaces of the system. The behavioral aspects of the models define the required functionality of the component using tables to relate monitored variables (inputs) to controlled variables (outputs). There are three basic types of tables (with two variants):

  • Condition Table (with mode or modeless)
  • Event Table (with mode or modeless)
  • Mode Transition Table

The SCR modeling approach permits Condition, Event, and Mode Tables to be combined. This allows complex relationships between monitored and controlled variables to be described in terms of simpler relationships that are modeled in Condition, Event, or Mode Tables. The concept of dependency relationships is supported using a mode class or a term variable.

TTM Terminology and Capabilities

The TTM support the core capabilities of SCR method, but provides a few terminology changes, and some addition capabilities.


The SCR method uses the terms 'monitored' variable and TTM uses 'input' variable. The SCR method uses the term 'controlled' variable and TTM uses 'output' variable.

Model Elements

SCR TTM Comments
Info Provides information that is stored internal to TTM files that is stored in XML format
Requirements Requirement mangement definition or import form tool such as DOORS
Types Types Specifies user-defined types
Constants Constants
Monitored Variables Inputs
Functions Parameterizeable functions that can be referenced in other tables
Mode Machines Mode Machines Table-based state machines
Terms Terms
Controlled Variable Outputs

Model Includes

TTM provides mechanisms for referencing (including) existing TTM models and overriding behavior of the included model elements. Requirement IDs specified in the model are included in test vectors generated from the model using T-VEC to support requirement-to-test traceability. The model editor includes automatic formatting of complex expressions and advanced find capabilities.

Latest Features

The latest features extend beyond the core capabilities originally envisions for SCR. The lates features include:

  • Arrays
  • Structures
  • Functions
    • Parameterized functions can be defined one and referenced by other tables
  • Intermediate variable
    • Intermediate variables make it easy to accept the results of a function and they reference in condition, event or assignment the intermediate value attributes
  • Disjointness Checking (sometimes also referred to as Disjointedness Checking)
    • Verifies that no conditions in a table overlap.
  • Race Condition Checking
    • Verifies that no transitions from a common source state can occur simultaneously.
  • String support
A "string" is now a base level data type. It is an ascii character string. Inputs, constants, terms tables, and output tables can all be declared to be a "string" type. Structure elements can also be of a "string" type. String types can be compared for equality ("abc" = "abc") and inequality ("abc" != "abc") and they may be concatenated ("abcdef" = "abc" + "def").
Strings are useful, for example, when the requirements being captured in TTM involve actual text messages rather than number, boolean, or enumerated types oriented data.
This is just the initial version of support for strings. There are ongoing efforts to extend these capabilities. For example, additional functionality will likely include string < or > comparisons (collating sequence relationships) and regular expression comparisons ("abc" =~ "a.+b") and other forms of string oriented relationships and operations.

The Examples section covers some general approaches that take advantage of the latests TTM features, which are important to using modeling from a project and team oriented perspective.


The following provides a few guidelines for modeling.

Define the Interface for the Model

  • Identify the interface boundaries of the component; the architecture at any level of the system is the context for the component under test.
  • Create new types and constants whenever they are needed in the course of the model development.
  • Identify the input (monitored) and output (controlled) variables:
    • Identify modes and terms.
  • Define the variables:
    • Define types for numeric variables so that the legal range of values can be specified.
    • Define types for enumerated variables.
    • Define Boolean variables (e.g., a flag) directly.

Strong Typing

Good modeling practices grew out of good programming practices. TTM combined with VGS try to help user attain greater assurance of correctness. Like any variable, strong typing of variables provides greater assurance that the semantics of the relationships where arrays are referenced are correct. An array element ultimately relates to something in the domain, or a particular hardware element that will have a fixed value. If it’s an integer, the integer will be associated with some type of object in the domain (e.g., altitude – the altitude takes on a value that has a range related to what the sensor can represent). Users are encouraged to define all of the types first, then any variable created should use one of those types.

Goal-Oriented Behavioral Modeling

Use a goal-oriented approach, and work backward by identifying each output (controlled variable or term) of the component.

  • Create a table that assigns the value for each different computed value of the output.
  • Use a condition table to describe relationships between outputs if the relationships are continuous over time (i.e., invariant over time).
    • Work backward, finding all of the conditions that must be TRUE for the function related to the output to be relevant.
  • Use an event table (with mode or modeless) to describe relationships between an output (or term) if the relationships are defined at a specific point in time.
    • Define the events and optional guard conditions that trigger the event.
  • Use a mode transition table (similar to a state machine) to describe relationships between an object if the relationship for a mode is defined for a specific interval of time (set of related system states):
    • Identify the set of modes; define the event associated with each source-to-destination transition.

If there are common conditions that are related to constraints (i.e., conditions or events) of functions of two or more outputs (or terms), then define a term table that can be referenced in all relevant tables.


  1. Constance Heitmeyer. Using the SCR Toolset to Specify Software Requirements. Proceedings, Second IEEE Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, Oct. 19, 1998.