Most of the requirements are general ones that are not limited on specifying a Test Suite. They might also be true for other applications, even applications of other domains. Many requirements can be fulfilled with a modular application design. Component-oriented programming promotes the building of modular applications [Löwy05, p. 1]. The .NET Framework is based on the principles of a component-enabling technology and thus helps to achieve this goal. One important feature missing in the current .NET Framework 3.0 is a mechanism to wire loosely coupled modules together at runtime. Here the plug-in architecture comes into play. This kind of architecture is already widely used in desktop applications. Manufacturers and institutions started the development of plug-in frameworks because the implementation of a plug-in architecture is not a trivial task. These frameworks assist the software developer to build plug-in based applications.
The Composite UI Application Block is one of these frameworks. It is used in combination with the Smart Client Software Factory for the prototype application to show how the requirements can be fulfilled. The application framework saves a lot of time in implementing the prototype since it already fulfills a couple of the requirements. Additionally, it promotes good object-oriented design by wizard driven code generation. Nevertheless, one of the major drawbacks is the high learning effort for this framework. Microsoft tried to address this issue with the Smart Client Software Factory but still the effort is not negligible.
In my opinion the uses of plug-in architectures will grow in the future. This strategy is supported by general application requirements like testing of isolated components. Furthermore, it can reduce the complexity of applications and decrease the maintenance efforts. Some IDEs already support the plug-in based development like the Eclipse Plug-In Development Environment17. The high learning effort is one of the main drawbacks of plug-in architectures. This drawback is weakened by the fact that an IDE like Eclipse supports the development of plug-ins and thus simplifies the usage of plug-in frameworks.
In the previous chapter it is mentioned that the .NET Framework 3.0 does
not provide an implementation of a plug-in architecture. The successor of
this framework version is going to deal with this issue. Microsoft
introduces the System.Addin namespace in the .NET Framework 3.5. This
namespace contains a plug-in framework with the main focus on application
extensibility for third parties. Thus, the design goal behind this namespace
is to enable dynamic composition of version resilient, isolatable components
[GK07]. It contains a communication pipeline between the host and the add-in
to enable compatibility because both parts can evolve independently [GK07a].
The System.Addin namespace shares some ideas with the Composite UI
Application Block but it has its strength in another domain. The
requirements, which are defined in chapter 2, do not have the need for
version resilient, isolatable components. Therefore, the use of the System.Addin namespace is not practical to fulfill these requirements.
This diploma thesis concentrates on the evaluation of three plug-in frameworks. In a future work further suitable solutions could be investigated and compared with the plug-in frameworks of this thesis. Examples for such solutions could be as follows:
Beside of the current available solutions some promising projects have
been started at the time of writing this thesis. One of them is the
Mono.AddIn framework20. It is a further development of
the SharpDevelop add-in system. The most important improvement, which is
planned for this framework, is the use of Attributes to define the add-in
description. This simplifies the configuration and the refactoring because
the descriptions are at the same place as the associated code. Even though,
it should still be possible to describe the add-ins via the xml files. The Mono.AddIn framework is intended to create extensible applications.
Therefore, it minimizes one of the main drawbacks of the SharpDevelop add-in
system. The evolution of the Mono.AddIn framework is likely to be more
stable than the add-in system of SharpDevelop.
Another promising project is the Microsoft framework code name Acropolis21. It is a set of components and tools that simplifies the building and managing of modular client applications. Microsoft intends Acropolis to be the successor of SCSF / CAB and promises to create a migration path for existing SCSF / CAB applications [Block07]. The success factor of Acropolis could be the designer environment in which a software developer shall be able to define the entire application. If the designer is well thought out, it would really simplify the development of modular applications.
Another idea for future work is to customize the Smart Client Software Factory to the needs of a Test Suite. This could also be a way for simplifying the development of an application in a specific domain. It would be interesting to see how much can be gained in relation to the efforts necessary in customizing the Software Factory.
17 The official Website of Eclipse PDE: http://www.eclipse.org/pde
18 Official Website of the Windsor Container: http://www.castleproject.org/container
19 Official Website of the StructuredMap: http://structuremap.sf.net
20 Official Website of the Mono.Addins: http://www.mono-project.com/Mono.Addins
21 Official Webste of Acropolis: http://www.windowsclient.com/acropolis