A More Detailed Description of this Research

I am investigating "visual languages for business modeling". I am designing them, using them, and implementing them. My current focus has been on using frameworks to develop and implement visual languages for use with business modeling. This project is aimed at providing support for decision making during the business process.

 I believe that Frameworks are both a way of coming up with visual languages and a way of implementing them, because if you focus on building something in an OO language, then building a framework for it, then making the framework composable, and then making a direct manipulation tool for composing applications using a framework, you will automatically discover a visual language.

 I am also interested in finding and describing the design patterns in visual languages and business modeling. To support this I am also researching "Domain Analysis and Engineering". This project is being funded by Caterpillar at the National Center for Supercomputing Applications.  The numbers and structures described on the below GUIs have been altered and in no way reflect anything meaningful about the way Caterpillar does business.  They are contrived examples to show how to create adaptable systems.

 Following is a brief description of the project which includes overview, design decisions, interface descriptions, implementation details, and conclusions. A listing of relevant findings, "what have we learned from all of this" is available as well.

Introduction:

Successful corporations and businesses are continuing to try to enter new markets, better satisfy its customers, and outperform its competition. Businesses today have become increasing dependent on information technology to support these goals, thus any technology that a corporation uses must be able to support new and evolving business requirements.

 Many corporations today are at looking flexible dynamic tools "reflective" that support three-tiered client/server architectures to offer a solution to these problems. Applications that support these needs to provide for dynamic means to change themselves during run-time and a means by which they cleanly separate the presentation, semantics, and data components of an application. With a three-tiered client/server architecture, business logic can reside on any computer on the network, taking best advantage of computing resources and current available tools for high scalability. Further, as application requirements and computing resources change, business logic can easily be relocated to more powerful computers or the processing logic can changed. The separation of components allows each component to be modified with no impact on the others, demonstrating the flexibility of reflective multi-tiered architectures.

Overview:

The Business Model project is an excellent example of a system that was designed from the onset to cope with change. This project focuses on the use of object-oriented technology, and specifically on the development of object-oriented frameworks, as a key strategy for reusing code and design.

 Why is it inevitable that the requirements placed on this tool will evolve, and desirable that the tool be able to cope with this change?

 As the number of users doubles and triples, as data begins to fill the largest drives, and as business logic becomes more complex, applications must continue to perform well. Systems built on the technology must be flexible enough to adapt to new requirements. As business policies change, as the price of hardware rises and falls, as relational database technology evolves, applications must be able to quickly take advantage of these developments.

 To meet these requirements, our tool was developed around a object-oriented framework written in Smalltalk [Goldberg & Robson 1983]. VisualWorks by ParcPlace was the Smalltalk development environment chosen primarily because it allowed us to quickly develop working prototypes, and get immediate feedback from our users. VisualWorks was also chosen because of its rich set of classes and its support for client-server applications tied into relational databases. Since VisualWorks is robust enough for production use, these prototypes have shown that they can gracefully evolve into production applications.

 Smalltalk is a pure object-oriented language that was chosen because of its extensibility, open-architecture, tailorability, and ease of reuse. The use of Smalltalk has lead to the development of a financial framework where key components have been re-used and integrated into all the financial applications developed for the different business units. The specific needs of the individual business units have been realized by either making "small" changes to this framework, or by adding new modules to the framework.

 VisualWorks is a powerful object-oriented development environment for graphical, client-server applications. It includes an application framework and visual interface builders to help design graphical user interfaces (GUI's). VisualWorks was one of the first tools to provide for a type of three-tiered application. This primarily seen through the use of the Model-View-Controller which dates back to the early 80's with the original Smalltalk releases by Xerox-Parc. Recent extensions provide for three-tiered applications based upon the CORBA standard with a DCE implementations as can be seen in the HP-DIST extension to VisualWorks by Hewlett Packard and in VisualAge by IBM.

 Visual interface builders such as those provided by Smalltalk vendors today, let you quickly outline an interface as long as it is composed of basic widgets such as buttons, text-fields, menus, and scrolling fields. They generate empty methods that you can fill in later to invoke the desired behaviors. One can also develop more complicated interfaces by grouping these widgets together and adding in the appropriate behaviors, constraints, and tie-ins to databases.

 Visual languages like this are an important feature that allows software developers to be more productive in not only the early development/prototype stage, but also in the production stage of code writing. The primary development of the financial aspect of the "Business Model" has been directed toward building or extending visual languages for the quick development of financial applications. Most of the code is automatically generated by the drawing of the interface and the data-flow of the program.

 The financial component of the "Business Model" includes four important components of software development:

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 advantageous 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.

 The data being viewed is usually 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 columns and down rows. Here we are viewing the results of sales in different marketing areas as broken down by models within a family.  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 columns without re-formatting the spreadsheet and without any new formulas.

 The spreadsheet below can be manipulated by hiding or showing columns, moving columns 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 multi-tiered architectures. 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 help minimizing errors. Frameworks can be developed that help the expert and amateur programmers to more quickly develop applications. The benefit of the programmer is that s/he is able to focus 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.