Design of the Image-Processing Components Using Late Binding

The time spent in design in this iteration is less than in the previous chapters. This is in accordance with the definition of the Unified Process. Recall that in the beginning of the construction phase the design workflow is one of the main tasks, but as we progress through the construction phase, the focus shifts to spending more time in the implementation and test workflows.

Because the architectural baseline is only extended by the late binding functionality, we will spend less time in the design workflow compared with earlier iterations. The major design requirement for this iteration is to provide the ability to load components at run time. Furthermore, the plugin components can be written in any of the languages that Microsoft Visual Studio.NET supports (VC++, C#, VB, and J#).

8.3.1 Design of the Language Extension Components

Up to this point, we have used compile time, or early, binding to access information in other assemblies (such as customScrollableControl). In this chapter the application's design is extended to allow for run time, or late, binding of certain components.

This means that a type of the component that is loaded at run time must be defined so that it can be invoked by the application at run time. Therefore, we first define a common method signature for the loadable component's interface. The following is the method signature used for the dynamically loadable components described in this chapter:

void ProcessImage(Bitmap source, int param1, int param2, int param3);

The parameter source of type Bitmap is used to provide a reference to the image on which the image-processing operation is to be performed. The three integer type parameters will hold additional information that might be needed for the requested image-processing calculation. The additional information can be the corresponding TrackBar position or any other information needed by the component to perform the requested operation.

The updated class diagram reflects these changes and can be seen in Figure 8.2.

Figure 8.2. The Photo Editor Class Diagram

The class diagram shows that the components are invoked at run time by the application. The component assemblies are provided as dynamic link libraries. The application will search for the plugins in the default location. To invoke the functionality at run time, all components must be located in the application's installation directory. For development this means that the release version of the components can be found in the bin directory, whereas the debug versions are stored in the bind directory. Figure 8.3 shows a package diagram to visualize the assembly structure.

Figure 8.3. The Photo Editor Package Diagram

This concludes the design changes that we analyze in order to implement the required functionality. Now it's time to move on to the implementation workflow.