Design of the Image-Processing Components Using Late Binding

graphics/design_icon.gif

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

graphics/08fig02.gif

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

graphics/08fig03.gif

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.

Introducing .NET

Introducing Software Engineering

A .NET Prototype

Project Planning

The Photo Editor Application

GDI+ Graphics Extensions

Advanced GDI+ Operations

Dynamic Loading of Components

Accessing System Resources

Performance Optimization, Multithreading, and Profiling

Building the Web Application with ASP.NET

Security and Database Access

Product Release



. NET-A Complete Development Cycle
.NET-A Complete Development Cycle
ISBN: 0321168828
EAN: 2147483647
Year: 2005
Pages: 123

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net