This project has moved. For the latest updates, please go here.

Test Suite - Overview

1. Modular Application Architecture

The Test Suite consists of various modules which are developed independently of each other. The modules can be divided into two categories:
  • Infrastructure: These modules contain the core of the application. They are required by all other modules.
  • TestSuite Modules: These modules implement the use cases of the Test Suite.
An exception is the Help module because it does not belong to any of these categories. The reason why the Help module does not belong to the Infrastructure category is that this module is optional. If the Help module is not loaded by the Test Suite, the other modules are still able to work. Yet, they cannot show help topics anymore.

Figure 1

Figure 1 shows the CAB modules implemented in the Test Suite. The associations between the modules show their dependencies to each other. The interfaces shown in the component diagram are implemented as separate .NET assemblies.

2. Modules

2.1 Infrastructure

  • Shell: Contains the start-up code of the application. Additionally it contains a message service for showing all kinds of messages to the user. The reason for implementing the message service in this assembly is that an exception can already occur during the application start-up. The Shell processes all unhandled exceptions that are thrown in any module of the application. This part is improved from the implementation which already comes by using the Smart Client Software Factory.
  • Infrastructure.Layout: Uses the DockPanelWorkspace class to define a user interface layout that is very similar to the one of Visual Studio 2005.
  • Infrastructure.Module: Contains further reusable services:

2.2 TestSuite Modules

  • LogViewer: Allows the user to see the log entries in an application window.
  • LogViewer.Demo: A sample module for showing how to use the logging mechanism of the Logging Application Block.
  • Message.Demo: A demonstration of the message service and the exception handling of the Shell.
  • RTFEditor: An example how document oriented applications can be created with CAB.
  • TestDevice.Manager: Responsible for the management of various test devices.
  • FunctionGen.Driver: Represents a driver for a virtual function generator.
  • FunctionGen.ControlView: Controls device drivers of the category function generator.
  • SignalVisualizer: Draws a graph of one or more signals which are generated or measured by the test devices.

Last edited Oct 8, 2007 at 1:48 PM by jbe2277, version 7


No comments yet.