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. The following links focus on modeling examples:
  
==Modular Organization==
+
*[[T-VEC Tablular Modeler Examples|T-VEC Tablular Modeler (TTM) Examples]]
 +
*[[Simulink/T-VEC Examples|Simulink Tester for T-VEC Examples]]
  
Most organization start their model-based development efforts with a small thread of functionality and transitioned 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.  
+
Test driver generation examples are covered separately.
  
This examples 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.
+
*[[Test Driver Generation Examples|Test Driver Generation Examples]]
 
+
[[Image:Component_example.jpg|Conceptual Components Example]]
+
+
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 because of numerous historical reasons related to memory space limitations of the system. 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.
+

Latest revision as of 16:30, 25 February 2007