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.
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.
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
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
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 Framework provided by ParcPlace.
Developing a Dynamic "SQL-Object" framework.
Creating a Visual Language Framework for visually creating the "SQL-Objects"
Development of a Report-Writer for the dynamic creation of summary reports
of any type.
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
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
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
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
"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').
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
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.
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
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.
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.