<![CDATA[
<body bgcolor="#000000" text="#b2b2b2" link="#00ff00" alink="#00ff00"
vlink="#00ff00">
<!INCLUDE "../title.html">
<a href="http://cat.ncsa.uiuc.edu/~yoder/tis/index.html">
<center><img src="http://cat.ncsa.uiuc.edu/~yoder/tis/Pics/TIS-gold.jpg" border=0></center>
</a>
<!/INCLUDE>
<!INCLUDE "project.html">
<center>
<h1>Smalltalk Class Project, Fall 1995</h1>
<hr width=25% NOSHADE>
</center>
The project was originally conceived as design and implementation of
an information system for managing a number of tractor specifications
stored in a relational database. This project was also based on earlier
work done by Joe Yoder and NCSA. The system should operate in a
distributed environment and be based on client-server architecture.
An implementation of the similar software in C using an interface
builder called UIM/X has shown a series of drawbacks associated with
using not an object-oriented language and design principles for the purpose.
The main feature of the system to be built is its dynamics. More
precisely, the specifications of various machine models in the database
can be updated as well as created during the execution of the program.
Therefore, the tool should provide adequate functionality for user
database manipulation. Furthermore, based on the new models added a user
may desire to create a new interface representation for a model, have
this representation available to other users while maintaining the
database and program consistency. The nature of the dynamics of the
system has become a primacy source of inspiration for using Smalltalk
for development of the software. However, after considering the task
wholly we have discovered certain levels of abstraction and functionality
in its realization. We have found it to be a useful approach as it
should allow us to develop a framework that can be used subsequently
for similar applications development. We describe the levels of
abstraction and functionality below.<p>
<h2>Dynamic database visualization tool</h2>
The idea is following: imagine that your manager gives you a pure relational
database and notes that he would like to see an application operating
on the database in several hours(sounds familiar?).
The application shall not be very general; nonetheless, it shall not resemble
sole reading of "Hello, World!" from the database. It has to provide a
reasonable tool for visualizing data from the database, i.e. creating views
based on one or more tables. Also, the views need to be separated into a number
of categories according to the manager's preference. To add insult to the
injury you are required to give the application functionality to save, delete,
and update the records in the database. Unintimidated, your eagerly rush to
the office, open your favorite database accessing tool, and by deadline
you design a program that does 30%-50% of what was needed, has a lot of
bugs, and is very far from being user-friendly. Your boss reviews your work
and melancholically observes that the views he wanted you to present
are not quite right and that the new ones should be created instead of them.
Finally, leaving the room he also remarks that it would be very neat to
build the views on the fly as he might make a mistake in their description.
By that time your enthusiasm has subsided significantly and after a sleepless
we see the following picture.<p>
<center>
<img src="newdraw1.jpg" width="508" height="243"><br>
<i>"Sorry! I am just not smart enough to do this..."</i>
</center><p>
Well, it does not sound too exciting, doesn't it? Is there a solution?
Yes, there is! After listening calmly to the manager
you go ahead and do everything
in a matter of an hour -- equipped with the Dynamic Database
Visualization Tool. The tool provides the environment for creating
applications delineated as above. Consider several steps necessary
for developing such an application.<p>
<h2>Initial data</h2>
<center>
<a href="before.jpg" target="chart_display"><img src="before_small.jpg" width="252" height="342"></a><br>
<i>A relational database</i>
</center>
<h3>Step 1</h3>
The source relational database should be augmented with several tables
(2 tables), which are used to store the descriptions of the interfaces
on the initial database to be created. In a sense these tables can be considered
as a part of the data dictionary because they represent the meta data for
an executing application. However, the information stored is
related not to the database but to the interface. Thus, the termin 'program
interface dictionary' is more suitable but not less confusing. We will not
go into cumbersome details of its internal structure. Just note that the new
tables to be added, Field_Data, Screen_Data in our terminology,
are responsible for the description of each particular field to be displayed,
and format of every view-screen, respectively.<p>
<center>
<a href="after.jpg" target="chart_display"><img src="after_small.jpg" width="267" height="352"></a><br>
<i>An augmented relational database</i>
</center>
<h3>Step 2</h3>
This step represents a process of creation of a new view-screen(another fuzzy
word coined but it appears to be the best suitable) on a database.
Creation is conducted using the Dynamic Database Visualization Tool and involves
specifying such parameters as the menu item corresponding to the view-screen;
the type of layout of the database records in it; the tables, on which the
database view is based; the fields from the tables to be displayed;
a label with possible description of each field. The resulted structure
reflecting the actual specifications of the new view-screen is mapped to
the 'program interface dictionary', which is updated as a result of the
creation. Subsequently, the description can be read from the database,
modified, and stored again.<p>
<! Some Kind of Divider>
The process described above implies several important tasks. First, a set
of base classes need to be created to communicate to the newly created tables
and provide necessary protocols for all of the activities depicted as
before. Second, another number of classes shall use transform the underlying
description of base classes into visual objects and display them on a user
screen. Third, an implementation of the tool that will create the base
objects is also very important. <p>
The high-level picture that we provided calls for further elaboration.
We can definitely certify that it is not a workable model, let alone a
complete one. We necessarily have to put additional constraints on
parameters of the view-screens determined by the rigidity of the
representation. Clearly, the relational data model, though possibly
applicable for the initial database domain, is not a right choice for
the 'program interface dictionary'. Both clearly distinguishable
part/subpart relationship and necessity for storing complex objects,
(window specifications, query conditions, etc.) do not admit elegant
relational database representation. We lament absence of persistent
object storage; nonetheless, we carry on with the relational structure.
Thus, the constraints imposed are following:
<ol>
<li> A small set of possible screen layouts, which is not customizable.
<li> The query conditions are restricted to fetching a whole table or
performing a natural join of specified tables. We understand that
this restriction is a most controversible and it shall strip the
software of the functionality one might expect from it. However,
we realize difficulties with extending the conditions and at this
point resort to this state of affairs for simplicity.
<li> The main window of a created database is not extendible and quite
'dull'.
</ol>
As inapplicable as the model may seem, we want to emphasize that
it represents just an abstraction of an application, a skeleton,
which can and must be extended to produce required application features.
We truly believe in its usability for a variety of database application
development tasks.<p>
<h2>Database Manipulation Tool</h2>
The next part of the system represents incorporation of the
underlying database data definition capability. This will involve
creation of different group of users such as 'administrator',
'privileged user', 'user'. 'Administrator' can perform both
dynamic interface creation and database manipulation. She also
can maintain the users accessing the system and their priviligies.
'Privileged user' cannot manipulate the database and user roles;
however, she must be able to create, update, and remove interface
specifications. This is the main category of users for whom the software
is designed. Finally, 'user' can modify neither the data dictionary
of the database she is working with nor the program interface
dictionary, i.e. the catalog of screens specifications. She views the
application as a usual information system devoid of any extraneous
features not related to the application domain.<p>
Clearly, the set of operations performed by a database manipulation tool
will be a subset of those accessible through the data definition
part of SQL. We do not aspire too far and will introduce the operations
that are absolutely necessary. Such are:
<ol>
<li> Table manipulation(create, remove).
<li> Index manipulation.
<li> Foreign key manipulation.
</ol>
The main challenge in designing the database manipulation tool lies
in providing flexibility as well as adequate performance. Any modification
of data dictionary will involve mapping the change to the Smalltalk
data model of the database and rebuilding it dynamically. <p>
<h2>Concrete Application -- Tractor Information System</h2>
<center>
<img src="draw4.gif" width="350" height="240">
</center><p>
This is the final part of our project, in which we will apply
the tools that we will have developed to the implementation
of the tractor information system. According to our methodology,
the initial data available is the tractor database containing
specifications of tractor models. Several parameters of the database:
<ul>
<li> number of tables: 79
<li> average number of columns for a table: 11.5
<li> number of primary key indexes: 79
<li> number of constraints(uniqueness and reference): 494
</ul>
We also have a number of files containing specifications of
user interface screens for the database available. The files are
being used by the information system written in C, which was
mentioned above. We plan to convert the file descriptions into
database representation and use these specifications to create
initial interfaces on the database. <p>
The database manipulation tool can be used on the database without
any additional tuning. We see major difficulties in extending
our dynamic database visualization tool to cover the actual
application needs. It is obvious that a full-fledged application
needs to possess domain specific information. Genericity of our model
bares it from this option; therefore, the initial application will
need to be 'hacked' to incorporate necessary domain specific
information. Since the process will involve only code additions
around the existing skeleton of implementation it shall not be
too resource-consuming. In any case, the undergoing development will
prove or disprove our claims.<p>
<table border=0>
<tr>
<td width=80%></td>
<td><i><a href="../Members/">Project Group <br> November, 1995</a></i></td>
</tr>
</table>
<!/INCLUDE>
<!INCLUDE "../menubar.html">
<center>
<a href="http://cat.ncsa.uiuc.edu/~yoder/tis/Scripts/imagemap.cgi/~tis/Scripts/bottommap">
<img src="http://cat.ncsa.uiuc.edu/~yoder/tis/Scripts/bar_anim.cgi" border=0 USEMAP="#bottommap" ISMAP></a>
</center>
<!/INCLUDE>
]]>