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 Type Definition
Structure types are represented hierarchically. Structure field names must be associated with a scalar or predefined structure type as shown below.
Structure Condition Usage
In a condition or event expression a structure variable can be related to another structure variable using the "=" or "!=" operators. Structure field elements are referenced using a dot notation and the relationship must correspond to the type of the field element.
structure_name.field1 = scalar structure1.field1 = structure2.field_n structure1 = structure2 structure_name.field1 = function(param,…); structure1.field_integer < structure2.field_integer
Structure Assignment Usage
For outputs, terms or functions that are structures, a field element can be assigned a value to one or more field elements where each assignment is terminated by a semicolon. For example, the vertical tracker3 example that is provided as part of the TTM installation illustrates the use of an assignment to a structure type with two fields (tState and tStatus):
tState = FAIL; tStatus = currentStatus;
Only the field elements need to be used on the left side of the assignment. For inputs each field elements must be fully qualified such as sensorData.trk1 shown in the example below.
Functions are parameterized condition tables. For example the tracking avoidance example provides several uses of function usage such as:
Note, the return value associated with the reference to advisoryStatus is associated with an intermediate values called an INTERM. An INTERM variable is a local temporary variables that can be assigned from the return of a function. References to that INTERM variable can be made in an Assignment or Condition Reference form such as:
INTERM_x := function(a, b, c)
Note the INTERM assignment operator is ":=" as opposed to equality relational operator "=:". INTERM variables can be constrained in condition, but must be assigned from the function before additional constraints are applied as shown in the example above. INTERM variables can be assigned to output variable associated with table.
The following provides a look at how single dimensional arrays is to be supported for structures and scalars. The following provides an example for defining an array. Provide a name and select a data types and check the box indicating that the type is an array. Finally, supply a positive integer indicating the size of the array.
Arrays are referenced similar to structures or scalars, but using square brackets if a particular array element is to be referenced. An array of size 4 has four elements, starting at location zero (0):
a, a, a and a
An entire array or array elements can be referenced in a condition or an assignment. If a variable is used to index an array, then the range of the variable must be constrained to the size of the array. The following example shows three different ways to assign array information to an array of structures.
- Row 1 shows that the output array is assigned the input array inArray
- Row 2 shows that the zeroth element of the array is assigned two different field values, one for status and another for value
- Row 3 shows that the output array associated with index is assigned to the index of inArray
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.