Veronica Loell
gpl@nakawe.se
17 May 2003
Göteborg, Sweden.
UIE stands for User Interface Engine, it is a theoretical software architecture that was designed to allow for communication between independent software modules.
The inspiration for the design came when I was trying to device a way to use a Tk-widget in a Paradox® application without resorting to creating and installing Active X controls. I finally decided that I wasn't going to just keep using a particular tool if it did not do the job I wanted it to do, on the basis that it was "the best tool for the job". There is in my opinion a good tool for every job. When you have a problem to solve that requires tools in different programming languages, on different platforms etc. is when you run into a problem. This is not in theory a difficult problem to solve. What I needed was the practical means for putting the theory into reality. The basis of the solution was Tclkit (http://www.equi4.com/tclkit). It provided easy access by scripting (Tcl/Tk) and platform independence. There are many additional strengths of Tclkit that I take advantage of but I will get back to them at some other time.
Having the tools that I needed to implement my theory, it was time to get down to the theoretical parts. Did I want just a way to do platform independent communication or was there something else that might prove useful for an architecture such as this? Isolating the actual source code in well defined small units should provide more stable code. Moving access to data from the source code should do the same. I work with database applications so my assumption on this part is that the data in the application is contained in one or more databases. Working directly with the user interface in its final graphical form to provide the appropriate responses to the users action will provide better overall grasp of the applications behavior, and methods to do introspection on actual running applications, as well as provide means for automatic documentation.
Incorporating these additional goals in my initial theory led me to the following definition of UIE (version 1.0):
The UIE is a combination of several different programming paradigms and software architectures. It is if you will my attempt to get the best out of all worlds. In the following sections I will briefly outline each of these. There may be others that I am unaware of, so this should not be seen as an exhaustive list.
In object oriented programming (OOp) the focus is on independent objects that work together to form an application. The UIE-objects are the result of this influence. The problem that I find with OOp is, that the functions and methods of the program are strictly bound to exactly one object. This severely limits the ways one may use to build an application.
The problem introduced by OOp is solved by the assumption in Functional programming (Fp) that functions are first order objects in the language. This influence results in the UIE-functions. I should note here that UIE-functions are not functions as in Fp or mathematics or even programming. A function always returns a value. A UIE-function never returns anything. Its result is either a change in the database or a request to the UIE to set up or modify a communication line. The name function is to be seen as something that provides some specific functionality for the application. With this I mean a high-level description such as "send an email", "add a new record to a table", etc.
The UIE way is to work top down rather than bottom up. This means that one starts with a functionality specification, defining a set of functions (such as "send an email"), and then provide the implementation of these functions. As mentioned in the introduction, I wish to provide code that is modular and contained in very strict, small units. This leads to the scripting language used to provide the high-level descriptions of an UIE-application. It is an extendable language that consists of clauses in natural language rather than words stringed together by capitalizing or using underscores. I.e. "send email", rather than sendEmail or Send_email.
A UIE script is shorthand for a Tcl/Tk procedure. A script is also a page in a wikit (the script editor, http://www.equi4.com/wikit). The name of the page is the name of the script. The body of a page contains the actual script. UIE has 3 types of scripts, that are used for different things.
Building the scripts in this way provides an abstraction at the same time as that abstraction automatically can be translated into the actual code that underlies it. This concept will probably become much clearer when one has a chance to look at the UIE-script editor. At the time of writing, it is not finalized, but it will be at the time of my presentation of this paper. It will be available from http://nakawe.sf.net
Objects in the UIE communicate with each other by means of passing messages. These work much the same way as message passing in concurrent programming (Cp). In order to not have to define a "language" of messages between every 2 objects, Cp-message passing is enhanced by the concept of a "meta language" that one finds in theories of Machine Translation. The idea is to create a generic language, and provide functions to translate to and from this generic language for each specific language supported, such as English (en), Swedish (sv) and German (de). The point of this structure is to not have to create a translation for all of en-sv, sv-en, en-de, de-en, de-sv and sv-de. This means that for each additional language one will not have to double the number of existing translations. Providing a generic language results in having only to provide two additional translations for each new rather than providing a translation for each of the already existing languages.
UIE-development is event driven, meaning that a specific event, caused by the user or the system, targeting one specific UIE-object will trigger exactly one UIE-function on that object.
We have finally reached the subject set forth in the title of this paper, Creating a generic interface between Tcl/Tk and other languages. This section is very brief as it relies heavily on the preceding sections. There will at the time of my presentation, be a functional, ready to use, implementation of this interface, but at the time of writing it is not finalized.
Using the UIE to create a generic interface to/from Tcl/Tk consists of simply implementing the UIE, a translation engine for the Tcl/Tk side, and the framework for a translation engine for the other side. You might at this time consider the title misleading, since in effect what we are doing is creating the possibility, or a framework, for an interface that can be used with any programming language. In my mind this means that for any two programs or software components, irregardless of language and platform, one has only to provide a two-way translation to our "meta-language" for each component.
This paper and presentation have come about in a rather short period of time, and as such it will need to be accompanied by the examples I will provide at the time of my presentation, and probably some notes clarifying what I have written here. It is my hope that this paper nevertheless have provided enough information about the UIE for the reader to decide whether it is something worth learning more about.