2. Requirements

This chapter describes the requirements for a Test Suite product. The Test Suite is a Windows-based application which is used for test procedures in the field of electrical power systems. The Test Suite is intended to become a successor product for the Test Universe 2.x [Omicron07a]. The requirements discussed in this thesis are far not complete as only the relevant ones are listed here. Relevant means that the requirements are in the field of plug-in architectures. The requirements addressed in this thesis include:

Most of these requirements are very general and can be adapted to other projects, even projects in other domains. The requirements are defined by the company OMICRON electronics GmbH. OMICRON is an international company providing solutions for primary and secondary testing in the field of electrical power utilities and industries [Omicron07]. All the listed requirements are of the category must-have if they are not otherwise defined.

The Runtime Platform

The most important requirement is to define the runtime platform because it sets the boundaries of the software architecture. The strategy of the company OMICRON is to use the Microsoft .NET Framework 2.0 or a higher version as runtime platform for new client applications which are running on a PC. The company’s preferred programming language is C# which open source solutions should be written with. The decision for using the Microsoft .NET Framework limits the deployment of the Test Suite to PCs on which the Microsoft Windows operating system is running.

The Test Modules

The Test Suite consists of test modules which enables the user to use different kinds of test procedures on various targets. The modules implement whole use cases with their own GUI elements, domain logic and module specific infrastructure. The GUI elements need to integrate seamless into the Test Suite. A user should not be aware of the different modules behind the GUI elements that he sees in the application. Many test modules share the same requirements regarding the infrastructure like logging, error handling, security, etc. To avoid implementing the same infrastructure code in every test module separately, they require access to a shared infrastructure implementation.

Handle Complexity

The complete Test Suite application is going to be a huge software product. The predecessor is known as OMICRON Test Universe 2.x and has about 2 million lines of code. Most parts are written in C++ whereas some newer parts are already developed with C#. A single project for rewriting the Test Universe from scratch with all its features is not manageable. Thus, the project needs to be divided into smaller feasible ones. The dependencies of these projects have to be as low as possible to remain controllable. Therefore the test modules need to be coded, tested and deployed independently. Nevertheless, the modules have to cooperate together. This cooperation includes extension and interaction with other modules.

Dependencies between the modules

Modules can use and extend functionality of other modules. Therefore, they have dependencies among each other. The functionality is mostly represented by services. Likewise the services have a dependency between the provider and the consumer. The dependencies on service level can be divided into hard and soft ones. Whereas the services defined by hard dependencies have to be available in order to work, the services defined by soft dependencies do not have to. A module is still able to work if some soft dependent services are not loaded but they run with reduced functionality.

Module Loading

The modules have to be loaded by the application at runtime. They are not allowed to have static references to other modules, because at compile-time it is not known which modules are going to work together. The module loader has to support configuration by a human-readable file and alternatively by command line parameters. This provides a flexible way of exchanging the modules as only the configuration file needs to be modified. It is especially useful in unit testing of a specific module. During testing, all the dependent modules are replaced by some mock modules. So the specific module is tested in an isolated environment.

Dependency Resolution and Lazy Loading

The module loader needs the information of the module dependencies. The dependent modules must be loaded before the defined module. Important to note is that dependent modules can also be dependent on other modules. These hierarchical dependencies can be represented in a tree data structure. Furthermore, the modules should be loaded on demand. This is also known as lazy loading. It means that modules are only loaded if they are used by the application or any other module. This approach improves the application start-up time and saves resources like memory.

Deployment and Versioning

Another point of the requirements is a strategy for the deployment of the Test Suite with its modules. This includes installing, uninstalling and updating the whole application or only a single module. Developers should be able to deploy new module versions without affecting the application or other modules. From this it follows that it can be necessary to deploy different versions of the same module on the identical machine. Additionally, the different versions need to be loaded side-by-side in the same client process. Not fulfilling this requirement results in a problem known as DLL-Hell [Löwy05, p. 11]. A nice-to-have feature would be to do the deployment tasks like installing, uninstalling or updating of the modules without restarting the application.

GUI Integration

A module needs to integrate seamlessly into the Test Suite. Consequently it requires an interface for the extension of the application GUI. The elements to extend are the menu bar, toolbar, status bar, option dialog, open / save dialog, etc. These extensions should be independent of the underlying user interface technology. At the moment it is planned to use the reliable Windows Forms framework but in future it will be the new Windows Presentation Foundation (WPF) which is introduced in Microsoft .NET Framework 3.0. Writing GUI components is a time consuming work. Therefore, it is not possible to change the GUI framework used by the whole application in a single step. The Test Suite application has to support both GUI technologies and even allow the mixing of modules which are based on the different GUI frameworks.

Command Service

Additionally to the GUI extensions, some kind of command service is required. The command service has to group different GUI elements (e.g. Menu item, toolbar button, etc.) together. It needs to be possible to hide or disable all GUI elements which are connected to the same command. This should be controlled by a command state. The state is mostly dependent on the active status of the module but in some cases a custom handling is required. Furthermore, the command object has to be associated with one or more command handlers.

Extensions and Communication between the Modules

The GUI extensions are already discussed in this chapter. Event though, other types of extension are also necessary. This can be an extension of the domain functionality of a module. A module has been able to provide various extensions and also consume extensions of other modules. Beside extension, a loosely coupled mechanism for communication between the modules should be available.