by Mike Baker
Cluster Tool Control Practice Manager
The purpose of a framework is to improve the efficiency of creating new software. Frameworks can improve developer productivity and improve the quality, reliability and robustness of new software. Developer productivity is improved by allowing developers to focus on the unique requirements of their application instead of spending time on application infrastructure (“plumbing”).
Many people equate the term software framework with an object-oriented software library, or set of libraries, intended to provide reuse. However, there is an important difference between a framework and a library, that difference is often called “inversion of control.” If you’re using a library, the objects and methods implemented by the library are instantiated and invoked by your custom application. You need to know which objects to instantiate and which methods to call in order to achieve your goals. On the other hand, if you’re using a framework, you implement the objects and methods that are custom to your application and they are instantiated and invoked by the framework. A framework defines the flow of control for the application.
A common way to customize framework behavior is to override framework-implemented features. The abstract or virtual methods defined by framework classes can be overridden in user-defined code. New objects can be created that implement framework-defined interfaces. These approaches leverage polymorphism to allow one software system, the framework, to interact with software developed by another group.
To emphasize the point, let’s look at a grossly oversimplified example. The Windows Presentation Foundation (WPF) is a framework for building Windows applications. To create a new Windows application with WPF there are two essential elements. The first is a XAML file. The XAML file describes the configurable attributes of the application including: which classes to instantiate, values for object properties, and which methods to invoke in response to user activity. The following is a very simple example of a XAML file:
<Window x:Class="WpfApplication1.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:xhttp://schemas.microsoft.com/winfx/2006/xaml
Title="Window1" Height="300" Width="300">
<Grid>
<Button Name="button1" Click="button1_Click">Button</Button>
</Grid>
</Window>
This sample describes a Window that can be instantiated by the application. Application-specific logic for this window is found in a class named WpfApplication1.Window1. The sample describes how to label the window and the initial size of the window. The window contains a Grid control which in turn contains a Button control. The attributes of the Button control tell WPF to invoke the WpfApplication.Window1 method named button1_Click when the button is clicked by a user.
The second essential element of a WPF application is code. The following is a simple example:
namespace WpfApplication1
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
}
private void button1_Click(object sender, RoutedEventArgs e)
{
MessageBox.Show("Hello world.");
}
}
}
This snippet is sufficient to implement a Windows application. The framework’s "inversion of control" is represented by the button1_Click method. This method is invoked by the framework when the user clicks on the button. The framework defines practically everything that happens when this application is executed; the Window1 class defines only the application-specific behavior. No coding is needed to display the window, process user input, or handle any common window operations (e.g. move, resize, minimize, maximize, close). Compare this sample with the amount of code that would be needed to develop even a simple application like this one without a framework. Many organizations develop Windows applications; few do it from scratch.
Now extend the framework concept from the general-purpose to a specific application domain (e.g. equipment automation). A domain-specific framework permits new domain applications to be developed more quickly, with high quality, and allows developers to focus their attention on the unique requirements of their application or system. Imagine configuring a new equipment control solution using framework-implemented building blocks and implementing only the overrides that are unique to your system. Those overrides could include elements of process control, human machine interface, data collection and analysis, recipe management, material handling, etc. Today there are many organizations that develop individual equipment automation solutions from scratch. A team using an equipment automation framework, such as CIMControlFramework™, could (for example) focus their time on how to execute a process recipe instead of worrying about how recipes are stored, retrieved, organized, protected, uploaded, downloaded, or communicated to the process equipment.
Advantages
- Reuse code that has been pre-built and pre-tested. Increase the reliability of the new application and reduce the programming and testing effort, and time to market.
- A framework can help establish better programming practices and appropriate use of design patterns and new programming tools. A framework upgrade can provide new functionality, improved performance, or improved quality without additional programming by the framework user.
- By definition, a framework provides you with the means to extend its behavior.
Disadvantages
- Creating a framework is difficult and time-consuming (i.e. expensive).
- The learning curve for a new framework can be steep.
- Over time, a framework can become increasingly complex.
Running a company during an industry downturn presents quite a challenge. I have always thought I would someday be the president of a company. However, during this severe semiconductor down cycle, the thought that you should “be careful what you wish for” certainly came to mind a few times. Even though Cimetrix is a small company, successfully navigating a business through a severe downturn that hit the semiconductor industry requires a combination of critical thinking, tough decisions and a durable stomach.
I’d like to draw your attention to two recent articles by 
In June of this year, the SEMI PV 2 Standard - Guide for PV Equipment Communication Interfaces (PVECI) was approved for publication by the global Audits and Reviews Subcommittee.
