T-VEC Tablular Modeler
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.
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 .
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.
|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|
|Functions||Parameterizeable functions that can be referenced in other tables|
|Mode Machines||Mode Machines||Table-based state machines|
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.
The latest features extend beyond the core capabilities originally envisions for SCR. The lates features include:
- 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.
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.
- 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.