Difference between revisions of "Examples"

From T-VEC Wiki
Jump to: navigation, search
(Modular Organization)
Line 1: Line 1:
This section provides a number of examples to illustrate modeling approaches, test driver approaches, and modular organization of models.
+
This section provides links to a number of examples to illustrate modeling approaches, test driver approaches, and modular organization of models. This section first introduces the SCR modeling approach that has been extended by TTM. Click the following link for [[Simulink/T-VEC Examples|Simulink/T-VEC Examples]].
 +
 
 +
==SCR Methods Supported by TTM==
 +
This section discusses a few details about the SCR modeling concepts and rules through the TTM tool.
 +
 
 +
===SCR Basics===
 +
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==
 +
 
 +
===Requirements Management===
 +
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
 +
 
 +
===Requirement-to-Test Traceability===
 +
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.
 +
 
 +
===Model Includes===
 +
 
 +
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.
  
 
==Modular Organization==
 
==Modular Organization==

Revision as of 15:25, 13 February 2007