T-VEC Tablular Modeler Examples
This section first introduces the SCR modeling approach that has been extended by TTM.
SCR Methods Supported by TTM
This section discusses a few details about the SCR modeling concepts and rules through the TTM tool.
Simplistically stated, the SCR method is based on the use of decision tables and state machines to describe required behavior of some component. The structure for organizing and relating SCR model elements is based on tables. Tables are used to define data types and variables of the problem. Variables can be defined in terms of primitive types (e.g., Integers, Float, Boolean, Enumeration), or user-defined types. The behavior is modeled using combinations of tables that define functional aspects of the problem using a form of state machines (called Mode Tables), Condition, or Event Tables.
The development of a model relates what system components have to do and how they have to do it. Then, through the generated tests, the model provides a measure of how well a target implementation satisfies the modeled requirements. The elements of “how” a system has to do its function is defined in terms of a set of interfaces specified with model variables and their associated data types. From a high-level perspective, models specify behavior relating input variables to output variables. Models also can represent behavior in terms of historical variables that are referred to as modes or terms.
TTM Extension Overview
TTM manages requirements through a hierarchical decomposition (i.e., outline format) where each requirement is composed of the following:
- Tag. A unique identifier for the requirement comprised of letters, numbers, underscores and periods.
- Description. A single line of text further describing the requirement.
- Comment. Any additional text.
The hierarchy of requirements is managed through the model view, and requirements are decomposed by creating child requirements that display below their parents within the model view
This section provides an example to explain the process for linking DOORS requirements to the TTM requirements model. The tool support for requirement-to-test traceability involves linking various sources of requirements through the model. The model transformation, test vector generation, and test driver generation provide the tool support to link the requirements to the test vectors, test drivers, and test reports. The process has three basic steps:
- A DOORS module is imported into the TTM. There are options to add or delete a DOORS module to TTM or synchronize DOORS modules when they are updated. There is a one-to-one correspondence between a DOORS ID and a TTM requirement ID.
- Imported requirements maintain the outline structure that they have within the DOORS environment. One or more DOORS requirements can be linked to an element of a TTM model (e.g., condition/assignment), or linked to a higher level in the TTM model, such as a condition, event, or mode table.
- The model translation maintains the link between the requirement ID, and during test generation, the requirement link is an attribute of the test vector. During test driver generation, requirement IDs can be output to the test driver to provide detailed traceability to the executable test cases.
TTM provides requirement management functionality that is similar to a DOORS module. Imported DOORS modules are linked into TTM as read-only modules. Changes to the requirements must be made within DOORS and then synchronized within TTM. Additional requirements can be created directly in TTM if they are not contained within DOORS or if the source requirements are not in a requirement management system such as DOORS. The process to link a requirement to the model is the same.
TTM models support the inclusion of existing models of other requirements, interfaces, or functional behavior. As a result, this feature helps consolidate behavior common to multiple models into a single model and includes it in other models where needed. This feature also supports partitioning a model to allow multiple engineers to work on it in parallel. It is described below.
Structure types are represented hierarchically. Structure field names and types must be provided as shown below
Output assignments for structures assign a value to one or more field elements terminated by a semicolon. In a condition table reference structure fields are referenced using a dot notation.
structure_name.field1 = scalar structure1.field1 = structure2.field_n structure1 = structure2 structure_name.field1 = function(param,…);
For outputs or terms, such as the vertical tracker3 example that is provided as part of the installation, an output that is a structure type such as trackingStateStrType with two fields is referenced as follow:
tState = FAIL; tStatus = currentStatus;
Note that only the field elements need to be used on the left side of the assignment. Individual field elements of an inputs such as sensorData.trk1 shown in the example with functions below, can be fully qualified.
Functions are parameterized condition tables. For example the tracking avoidance example provides several uses of functions such as:
Note, the return value associated with the reference to advisoryStatus is associated with an intermediate values called an INTERM. An INTERM variable are local temporary variables that can be assigned from the return of a function. Reference to that INTERM variable can be made in an Assignment or Condition Reference form such as:
INTERM_x := function(a, b, c)
Note INTERM assignment operator is := as opposed to equality relational operator =
- INTERM variables can be constrained in condition, but must be assigned from function before additional constraints are applied as shown in the example.
- INTERM variables can be assigned to output variable associated with table
Single dimensional arrays are supported for structures and scalars.
Most organization start their model-based development efforts with a small thread of functionality and transition into one that is performed by a team of developers. Some have evolved to support product lines. This requires coordination with the design team, system engineering team that write the product technical specification, test team, and the quality assurance organization.
This example shows an example function such as Check that might have many different types and combination of filtering, matching. This example discusses the organizational and process impacts of developing a feature for the Check component that impacts Filter, Match, and Select.
This example discusses a chronological perspective because the integration of the entire model-based method impacted many different organizations within a company. Before the of model-based development, the components of the Check function were not partitioned with well-defined interfaces; rather, the functionality was coupled, which made testing the functionality in each subcomponent (i.e., Filter, Match, and Select) more difficult. However, there is a verification requirement to demonstrate that every thread through a component or subcomponent is completely tested. Tight coupling makes this requirement difficult to achieve and demonstrate.
The team used interface-driven requirement modeling that starts early during the requirement and design phase. This early modeling helps to create a more testable design and improve the requirement and interface specifications.
As reflected in previous figure, the functionality in the existing system was tightly coupled for numerous historical reasons such as memory space limitations. The interfaces between Filter, Match, and Select were not well-defined. This complicated the testing process, requiring many tests to be initiated from higher levels in the system, such as Check, because some of the inputs could be set upstream from the Check component. In addition, the outputs from the function such as Match were not visible. This made systematic and comprehensive testing of these lower-level components difficult. Normally, ensuring coverage of the threads through the implementation of these lower-level components means increased testing from the high-level components. Sometimes, the number of tests can increase by an order of magnitude.
This effort started early enough that the designers were able to expose the interfaces of both the inputs and outputs, including internal state information to increase the testability significantly. Approximately 80% of the functionality was tested with improved interface support provided by the design team. This approach significantly reduced the complexity of the model and the tests, and provided greater test coverage with fewer tests to reduce time and cost. The remaining 20% represented elements of the components that could not be changed due to performance issues, and impacts on cost, resources, and schedule associated with retesting.