1. Introduction

1.1 Motivation

According to Mayer et al. the plug-in concept is widely used [MMS02]. It can be found in many applications to enable customers and third party manufacturers to extend the functionality. These applications are spread in various domains. Some examples are:

Providing a powerful plug-in architecture in a software product can help to differentiate from competitors. These days a rich variety of systems are running in the IT environments of the customers. Therefore, the manufacturer is seldom able to support all of them. A plug-in architecture let others create the connection between the application and the various IT systems while the manufacturer is able to concentrate on its core business. For example the customer or third parties can connect the application with an enterprise resource planning (ERP) system by writing a new plug-in1.

An approach of building complex applications and particular GUI applications is to use a plug-in architecture not only to offer an extension mechanism2 for others. It can also be used to separate the own code into plug-ins and increase the modularity this way.

The concept of plug-in-based application development (…) goes one step further. Thereby, it is possible to divide the development of big systems into manageable small components which can be evolved independently [MMS02].

The plug-in architecture supports a fundamental architectural design principle called Separation of Concerns. That is to separate cohesive concerns into different independent plug-ins. One advantage of this principle is that developers (or teams) do not have to care about the whole application. They are able to concentrate on their specific requirements and implement them in plug-ins.

Additionally, the use of plug-ins reduces the complexity of the design and makes it more understandable [MMS02].

It is common for this approach that the plug-ins can also extend each other in a well defined way. This improves the extensibility of the application as new functionality can be introduced by adding new plug-ins. The important point is that the existing code does not have to be changed as long as adding of functionality does not violate the application design. Changing of already reviewed and tested code should be avoided whenever it is possible.

The plug-in architecture allows the deployment of different plug-in sets to create different application editions. This enables product managers to react in a flexible way on market changes. Even upgrading to a more capable version of the product can be done by installing only the necessary plug-ins.

1.2 Objective

The goal of this thesis is to find a plug-in architecture which fits the requirements of a Test Suite. The Test Suite consists of different test modules which must be developed and deployed independently. The test modules still require some kind of communication mechanism for information exchange.

An important point is to analyze existing plug-in architectures on the fulfillment of the specified requirements. The chosen architecture has to be adapted to the requirements defined in this thesis because these architectures are mostly kept abstract to cover as many scenarios as possible. The requirements that are not covered by the architecture have to be addressed with own solutions. A prototype application presents a way for fulfilling the requirements.

1.3 Document Structure

This thesis is divided into eight chapters. The content of these chapters are as follows:

Chapter 2: Requirements

This chapter describes the requirements for a Test Suite product.

Chapter 3: Plug-In Architectures

Gives an introduction into modular application design and plug-in architectures.

Chapter 4: Fundamentals

Describes the Dependency Injection and Service Locator design pattern which are common in application frameworks. Additionally, the chapter discusses the concept of Attributes as they are used in some frameworks for configuration.

Chapter 5: Current Solutions

This part describes the investigated plug-in frameworks. These are the Composite UI Application Block, the Smart Client Software Factory, the Spring .NET framework and the SharpDevelop application.

Chapter 6: Evaluation

Shows the evaluation criteria for the chosen solutions. Further, the chapter includes a discussion of each criterion in association with the plug-in frameworks.

Chapter 7: Prototype

Presents the Test Suite prototype which deals with the requirements defined in chapter 2. This chapter discusses the implementation and shows workarounds for occurring problems.

Chapter 8: Final Remark

Contains the conclusion of this diploma thesis and lists some ideas for future work.

1.4 Intended Audience

This diploma thesis is primarily written for software architects and software developers. It is advantageous if the reader has the following skills for understanding this thesis:

1 The term plug-in is also known as add-in, add-on, snap-in or extension [GK07].

2 An extension mechanism allows adding of new functionality without rewriting or recompiling the main application. See also Extensibility in the Glossary.