A Description of the Business Model Research

Extending the Visual Builder:

Caterpillar has developed a "DuPont Model" [Johnson & Kaplan, 1987] to help with the financial decision making of the company. Note: the numbers reflected in the DuPont model example in no way represent any financial information about Caterpillar in one way or another. They were merely selected to show some general aspects of the DuPont model. As can be seen by the following DuPont model example, their is a common interface widget that is used many times. By adding a "DuPont widget" to the visual builder with methods for the automatic generation of related code, the developer can quickly tailor different DuPont models to meet the needs of different users.

When building a DuPont Model as in the Caterpillar example, there are formulas and database queries that are associated with each graphical box on the screen. Normally this would require a lot of back end coding. The developer would first use the Visual Works Interface Builder to draw in all of the text fields and buttons and then add in the associated behaviors such as defining all of the queries/formulas along with all of the associated constraints. If this only needed to be done once, then it probably would be advantagous to develop the software this way. However, every business unit was looking at developing a DuPont model with minor tweaks which included different boxes, constraints, formulas, and database queries. This along with the fact that the data structure and layout will be somewhat different for each business unit, prompted us to extend the Visual Builder framework.

We were able to extend the Visual Builder framework to allow for the re-use of code and easy extension of the DuPont model by creating another interface widget like the DuPont box which has all of the fields and the associated button, the developer can then draw the DuPont boxes quickly on the screen and use the property editor along with the builder's automatic define method to automatically generate the formulas, the default query methods, and the needed constraints.

There are four steps to build a new interface widgets: 1) Implement the new interface widget; 2) Define the property specs of the interface widget; 3) Add in behaviors for defining the object, usually add to the normal "define" behavior to iterate over the new object as well and take any appropriate action; 4) Use the icon editor to define the widget's icon on the UI Pallet Icon. The real beauty in this is the way in which the Visual Builder was used to extend itself.

Many Programming Languages have been developed to provide developers with many built-in functions/capabilities/tools that allow for the quick and accurate development of software projects. Most often these languages are developed with specific needs in mind. If the software being developed maps easily into the domain of the language being used, then the developer can easily develop the desired software. However, most large development projects do not easily map directly into the limited domain provided by the programming language. Often there are linguistic facilities that need modifications but are difficult if not impossible to apply in languages. Languages that do provide full, runtime access to such mechanism, thus allowing for the underlying semantics of the language to be changed, are said to be reflective.

Since VisualWorks allows one to get their hands on the insides of the visual builder, it opens up the system for easily adding a new interface widget. We usually think of the frameworks in VisualWorks as being the View and ApplicationModel subclasses. But the visual interface builder itself is comprised of a set of frameworks that can be extended as well. These frameworks provide the reflective interfaces that make it possible for the developer to easily extend the Visual Builder. Extending the visual interface builder is often the quickest way to make flexible and powerful software.

The Smalltalk-80 system is constructed from a set of objects which are themselves subject to modification. The language, framework, and tools with which the system is built all reside in the default system image, and hence may be changed. These changes are usually done using abstract classes available within the Smalltalk image thus allowing for a lot of reuse.

Developing a Dynamic "SQL-Objects" Framework:

In order to stay competitive, Caterpillar has noticed that they must be able to quickly evolve to new ways of doing business. They need ways to be able to make new decisions quickly and change the way they do business according to those decisions. In order to do this they need to be able to dynamically choose their variables and business logic and then query from their data sources accordingly.

VisualWorks by ParcPlace has provided a framework for creating static SQL database queries. The framework allows for the developer to graphically create SQL queries that map to Oracle and Sysbase Databases. These queries then get converted into a Smalltalk method that can be called upon when desired. Smalltalk objects can also be passed into the generated methods and conversions and comparisons are supported by the framework. This framework can also query the database for the current data model the developer is interested in and then create objects to map to the desired tables within the database. It is also easy to extend the framework to add undeveloped database functions or extend the mapping to other Database vendors.

Basically what happens is that the generated methods are parsed and SQL code is generated that includes the joins, projections, select-where, group-by, and order-by clauses. The generated SQL code is then packed up and shipped across the network via SQLNET. The returned database values are converted into objects that describe the attributes for each table within the database. These returned values can then be displayed, evaluated, or processed dynamically just like any Smalltalk object.

The problem arises when one wants to dynamically change or create SQL queries during run time. Since the SQL framework supplied by ParcPlace only provides ways to pre-defined static queries we built a framework of SQL Query objects that allows for the creation of dynamic SQL queries through the use of Smalltalk expressions. For example, the experienced Smalltalk Programmer might desire to be able to write code very similar that portrayed in example1

example1	
"Perform a natural join on Models and ProductFamily
  projecting model number and family description.
  Then return the values."
	
	| models productFamily tmpQuery|
	models := TableQuery tableFor: #Models.	
	productFamily := TableQuery tableFor: #ProductFamilies.
	tmpQuery := models naturalJoin: productFamily.
	tmpQuery := tmpQuery orderBy: (models fieldFor: 'modelType')).
	tmpQuery := tmpQuery project:(models fieldFor: 'modelType'),
          (productFamily fieldFor: 'familyDescription').
	^tmpQuery values

Also, it might be nice to take a query that is formed as above and then "wrap" some new constraints on the query such as select only those in the above query for the current month. Adding new constraints to the queries such as this might only be realized during run-time, thus making the static creation of queries insufficient.

Our solution to allowing for the dynamic creation of SQL objects was to define GroupQuery, OrderQuery, ProjectQuery, SelectionQuery, and TableQuery classes which are all subclasses of the QueryObject abstract class. We also created the associated objects to allow for the developer to build Smalltalk like query expressions as in the example above.

The Query objects know how to respond to the appropriate message to build the queries and wrap constraints to themselves during run-time. The design pattern that fits here is the interpreter pattern from Design Patterns [Gamma et. al, 1995].

We were able to reuse all of the code from VisualWorks original framework of parsing a method into SQL and submitting the SQL across the net and then creating objects representing the desired values returned from the database.

Our dynamic SQL framework has allowed for late binding of constraints to the SQL objects by allowing the developer to build a parser for developing queries and "wrap" additional constraints to SQL objects as the application runs.

This example demonstrates the principles of reuse, extensions, and modifications. Reuse by the simple approach of blindly reusing the framework for generating the SQL code and using SQLNET to get the desired results and populate objects with them. Extensions are based upon the addition of the "Query Expression" objects for allowing the developer to write queries in Smalltalk like expressions and to also allow for the ease of extending these objects dynamically by wrapping additional constraints before the SQL code is generated. Modifications can be done to the existing framework by adding in behaviors for additional desired SQL functionality or the framework can also be extended by adding database drivers not supported in the default image provided by ParcPlace.

Building a Visual Language for Developing "SQL-Objects":

The SQL-Object Framework above provides powerful tools for the development of dynamic queries that can not only be developed by the Smalltalk like expressions, but also wrapped with pre-existing queries during run-time. However, it still proved advantageous to provide a visual manner for the programmer to develope these queries. The figure below shows a form for building these queries that provides the developer with not only a way to build up all of the standard queries with any desired SQL commands based upon existing tables in the database, but also with a way to take pre-existing built queries and wrap more SQL constraints upon them.

This provides the Smalltalk programmer a way to quickly build queries which can then either be used as is or processed later for additional constraints or optimization techniques. A similar interface has been developed which is designed for a non-technical user that can build these queries and wrap additional constraints on them during run-time. This new interface looks very similar to the current one except that it only provides a few for selecting variables and logic based upon any queries an tables in the database. The joins, projects, and selects are taken care for the user so all they have to do is describe what conditions they want to search for. This is similar to the programming-by-example techniques.

Report-Writer Framework:

An important aspect of most, if not all, programs is that ability to take data that has been processed and then view it in a human-readable format. Quite often what a programmer will do is take the encryptic output of other programs, process this data through pipes and filters and possibly displaying it in a graphical interface to provide a desirable format for the end-user.

Quite often the data being viewed is in the form of a 2-D list or array. Research has shown that the use of spreadsheets is a very desirable means to display the output of data in this type of format. There has been much work done on the development of spreadsheets that allow the user to build up formulas for users to present their data.

As can be seen in the Vehicle Net Sales Report below, the output is formatted so that sales can be summarized across collumns and down rows. This can be done with any standard spreadsheet with a certain amount of formatting and programming of the desired formulas. However, since most of the summary reports for the application being developed needed a report like this, we developed a way to simply take a 2-D list with formatting information and then displayed it in a table-view. This allows for the summary report of any number of rows and collumns without re-formatting the spreadsheet and without any new formulas.

The spreadsheet below can be manipulated by hiding or showing collumns, moving collumns around, summarizing in greater or lesser detail, etc. The main thing to note about this framework is that it is in no-way encoded for only this type of data. This framework can take any 2-D list with formatting information for summarizing the list and output the desired table display. The only assumption being made is that we are trying to summarize over numerical values.

A natural extension to this is to provide the developer/user of the system a visual way for describing the formatting and 2-D lists. One might write a query with the tools described above and designate it as the desired 2-D list. Then the user would only need to delegate the formatting of the output to get the desired output.

Conclusions:

Today's business applications need flexible tools that allow for the development of dynamic applications that support the three-tier architecture. Object-oriented tools support this by allowing for quick development of prototypes that can be extended with a minimum amount of effort to production environments.

Visual languages can support rapid application development while assisting in the minimization of errors. Frameworks can be developed that assist the expert and amateur programmers to more quickly develop applications. The benefit of the programmer is that s/he is able to focuse more on domain analysis and how to support the needs of the specific domain rather than getting caught up in the trap of focusing primarily on language quirks.

The primary work done here focused on the development of frameworks supporting a visual language for the development of financial client-server applications that access relational databases. These visual languages have provided means for "almost" complete development of DuPont financial applications with summary reports, graphing, context-sensitive help, access to SQL-Objects, and more by simply drawing items on the screen and by describing constraints and desired queries.