The Display Machine

O-O Rapid Application Development - the other way!

(read also about:  the benefits - the Virtual Machine - the gain in safety)

A customer recently wrote this to us:

"BTW, I used to use ****** workbench, which is probably the best RAD that I have ever looked at as far as quickly 'wiring' something together. For some reason, I never put it to use in developing any real application, and I think I figured out why recently. What DM (Display Machine) forces you to do is actually come up with a structure to your application *before* worrying about the GUI. In the ******  workbench, just the opposite was true, and after spending hours 'playing', if you had an application at all it was incoherent!

As I'm getting REAL results with DM (i.e. I've got an application which is composed of some 20 windows now and will probably grow to about 70 by the time I am done) and my application has a solid architecture, I am extremely happy!"

After 7 years of developing object oriented applications, and after many projects' experience with Rapid Application Development (RAD) tools we at Object Tools applied our experience to the latest developments in GUI technology. The result was the Display Machine.

The Display Machine (DM for short) is as fast to use as other RAD tools but retains all the advantages of object oriented programming. This means that:

The Display Machine works together with the programming language by means of an introspection API ("Meta Object Protocol"). We developed DM for Visual Eiffel and are now working on a Java version.

We do it the other way

Bones, Flesh and Skin

RAD development is usually widget-oriented - The programmer builds the windows from graphical components by selecting components and "painting" them in the desired place, then setting the appropriate attributes. Results are quickly achieved, and the customer can see immediately how the application will look. The first result is the skin - and the customer will see a nice mannequin. For some applications there may already be some flesh: some automatically generated code, for example for database access. Now the programmer's task is to fill the skin with functionality - to put in bones and flesh.

Our approach is different - but not so different as you may expect. We rely on the premise that widgets are not everything. Our concept is to start from inside - with the bones. As we know that the customer wants to have the mannequin as fast as possible, we don't need all the bones - and we need no flesh. But we need some bones in order to build the surface.

Now let's come back to our picture. What do bones, flesh and skin stand for?

We claim that our approach is better because it starts with (at least some) bones.


If you start with the skin ...

Imagine you are to develop a reservation system (it does not matter what for). The customer already has some ideas how it should look, and he certainly knows how it was done before. So you start your RAD tool and draw the Interface. After some hours everything looks fine and you can start real work.

The RAD tool produces resource files, wrappers, tables - the skin and some flesh. Your task is now to complete the design. You must provide the missing parts - the flesh and bones.

Your final program will probably look like the picture above.

You will end up with some commonly used program part - reused from old projects or written for this project (the big "program" box on the left) and many small "widget programs" written especially for this project - the flesh produced to serve single widgets. Much of the code in the "widget programs" is project specific and not reusable. Of course the proportion between the two types of code depends on the programmer.

The design process looks like:

Maybe you have had a similar experience to the customer we quoted above. We have also found from our experience of RAD tools that there is some danger of ending up with a system which (although it runs) is not very maintainable and certainly not very reusable.

And, there is always the danger that you must use the red pen and go "back to the drawing board" - for example when it proves impossible to force the design into the interface's "Procrustes Bed".


If you start with the bones ...

We have the same situation as before, but we start differently. Before we start to draw the screens we make a preliminary object oriented design. We discuss with the customer the objects he needs and we specify these classes by writing class wrappers - just bones, no flesh.

Then we use DM to "visualize the bones". DM knows how a component should look on the screen and generates the corresponding widget. We draw - but our components are plain class attributes. As soon as we drag them onto the screen they are translated automatically into widgets. If we need some "skin" for which we don't have the proper "bone", we must first specify the new bone. Then we can generate the skin we wanted before.

DM puts everything related to the interface into a resource file. As the objects and their attributes must be specified before they can be shown on the screen, they cannot even know what they will look like. So, it is not possible to write "widget programs" and the code becomes 100% independent of the screen view. The design process looks like this:

The price you have to pay is time. Designing needs time (so does thinking). But it is not always necessary to start from scratch with the design. You may already have a class you can reuse - and this class will also probably contain the flesh you need.

And even if the initial phase of your project takes longer, this time will be repaid later.


Nobody is perfect

In some situations it is simpler and saves time to let the bones and the flesh know about the skin - even if this is not the best solution. And it is sometimes good to know that there is SOME skin - even if you do not know what it looks like.

So, an object could know that it will be accessed from "outside". For this reason we extended the Display Machine (note the small arrow from the program to the resource):

But Display Machine will not allow you to draw first and think later.


The calculator

What is a pocket calculator? Here are some different descriptions:

So, lets specify a calculator object
- a CALCULATOR class:

This specification may be not perfect,
but it already contains some information
about a pocket calculator.

In our approach we call this the "bone"
of the
application. The flesh we can fill
in later (between do and end).

But keep in mind that our approach
needs such a specification before the
drawing can begin.

You can see our backbone at the right.

class CALCULATOR
     feature

     indicator : INTEGER
     memory : INTEGER
     operation : CHARACTER

    digit (d : INTEGER) is do ... end
     -- enter the rightmost digit into the display

    clear is do end
    -- clear the display

    operate (op : CHARACTER) is do ... end
    -- set the operation

    equals is do ... end
    -- calculate the result

end -- class

And now, let's start to draw the application using the "Display Machine Builder"

On the left of this screenshot you can see the attributes of class CALCULATOR - and on the right some widgets produced by dragging and dropping from the attributes and from the procedures clear, digit(d) and equals.

The procedures are automatically translated into buttons. A class containing no procedure cannot "produce" a button widget.

We "moved" the procedures digit(d), clear and equals to our new CALC widget, and also the INTEGER attribute indicator.

Next we move the digit(d) procedure onto our form once for every digit button - then we set the appearance and semantics for each digit button:
Naturally, it is also possible to copy buttons - including their formatting - and move them into place. Finally we get something like a calculator. This widget looks impressive, but it does not yet work.

The flesh is still missing.

Next we must write the "hard" code for our class CALCULATOR. Procedure digit(d) for example will get the following body:

     do
         display := display * 10 + d
     end

It's as easy as that!

Finally let's see how to bind this freshly created calculator into an application - in our case we want to use the calculator in order to enter a number. We can even create multiple widgets based on the same backbone - the parameter of display indicates which one should be used. c: CALCULATOR;
...
!!c;                  -- create a calculator object
c.display (1);    -- show it on the screen
x := c.indicator  -- use the result

You can see the complete example here - with bones, flesh and skin.

You may be wondering why we claim that this approach is better than other RAD tools. The "development" took about the same time and the result (the skin) looks identical.

The difference is in the bones - in the backbone. Try to change our calculator - and try to change the widget created with a competitor's tool. Our approach is completely object-oriented - it is almost impossible to make it not object oriented.

Try some small modifications:

You will see that the small calculator that we created above will still work with the more powerful program (the combination of bones and flesh you created whilst solving the four exercises). So the old skin still fits provided the bones are unchanged - even if there is much new flesh.

Later in this document we will show a more complete, real life application.


We do it the other way

The virtual machine

The bones and the flesh of our calculator example - in the form of the body of our CALCULATOR class - describe the functionality necessary to program many kinds of pocket calculator - just about any kind of calculator you might need.

We can put it another way: we have created a virtual machine designed especially to "make" pocket calculators. Not more - and not less. This machine comprises a complete description of a calculator's functionality. There is no input/output - only pure functionality.

The Display Machine allows you to write graphical programs based on your virtual machine.
These Display Programs can access attributes and call routines of the virtual machine.

Instead of writing an application to work with a single interface, you are writing an abstract virtual machine to be used with many applications. It's like writing an application for the abstract Java Virtual Machine instead of for a specific assembler language. However:

The user interface is the application

We promised another example - and here it is. We will demonstrate the bones necessary for an accounting system.


Accounting system

We start with our skeleton - the specification of customers and the items we want to deal with:

class CUSTOMER
     inherit
          DISPLAYABLE

     creation
          make

feature
     name, street, town: STRING
     turnover: REAL

     make is
          do end

     increment_turnover (n: REAL) is
          do end

     save is
          do end

     valid_customer : BOOLEAN is
          do end

end -- class CUSTOMER

class GOOD
     inherit
          DISPLAYABLE

     creation
          make

feature
     description: STRING
     price: REAL
     store: INTEGER

     make is
          do end

     change_store (n: INTEGER) is
          do end

     save is
          do end

end -- class GOOD

These specifications look very similar - they follow a special pattern. And they can be used as a starting point for all accounting systems. Of course it will be necessary to add more attributes later - but we have already enough "bones" to start real work.

Here is some "skin" we produced in less than 2 minutes based on the CUSTOMER class:

These dialogs are numbered 1, 2 and 3 within class CUSTOMER and can be called by this number - using the feature display of the enclosing class. For example, the update of a customer address is done by calling

c.display (2) -- 'c' refers to an object of type CUSTOMER

We can extend these forms without changing the underlying class, and we can change or even exchange our class without changing the forms. The worst thing which could happen is that some buttons no longer work (if the required functionality no longer exists) and that some edit fields cannot be edited (if the attributes are no longer part of the class). We can express it like this:

We can change the bones without changing the skin - at worst the skin will lose some functionality - but it will still look pretty. On the other hand we can change the skin without any need to touch the bones.

Now that we have designed the bones and skin we can start to "flesh out" our application - to develop the program code. You will probably find that most of the flesh/code developed for other projects can be reused.

We will extend our application later.


We do it the other way

Programming languages

DM is independent of the programming language used to code the application - as long it is supported by the Display Machine. We started by using Eiffel (an excellent modeling and implementation language - especially for complex object oriented designs). We kept the interfaces open - and had no problems accessing Java classes. Any language can be supported as long as certain information is available.

The diagram above shows the structure of the DM Interface Builder. It can access the structure of a system by means of a common interface (OOCAPI - the Object Oriented Compiler API). This API consists of a set of queries like "give me the list of all classes" or "tell me what parameters function xyz in class ALPHA has".

The Display Machine Interface Builder can use any language for which such an OOCAPI is available (or can be constructed). This interface delivers the description of the virtual machine.

At execution time the DM Interpreter must access the compiled application on which the design was based. For this purpose we use the simple CECIL interface, which makes it possible to access all functionality of a program by symbolic names using a special cache mechanism for speed. The Java .class files and the Eiffel executable implement the virtual machine for the application.

The combination of these two interfaces - the OOCAPI and the CECIL interface is similar to the Meta Object Protocol used in the specification of many object oriented languages.

At execution time a call to display causes the display machine to take control and "execute" the forms described in the resource file. As soon as some "flesh" (some calculation or some "real" data processing) becomes necessary, DM requests this service through CECIL. This can include the execution of other components - for example using OLE components.

The Display Machine itself need not be a standalone executable Windows application - it is possible to call it as an ActiveX or OLE component and to integrate DM applications into the execution of Web scripts.


We do it the other way

the Display Machine

The display machine is based 32-bit MS-Windows technology, and it is possible to design applications using all the bells and whistles offered by Windows:

For example, here's a screenshot of an MDI application using menus and tabs.

We don't have space here to describe all the things you can do with DM - but there are many of them and we are extending the features regularly. DM is very modular, and is easily extendible.

Speed

Computationally-intensive applications written for the Display Machine run as fast as other applications written in Java or Eiffel. The graphical part is written very efficiently and relies on the speed of Windows. No part runs slower than "custom specific" GUI applications.

GUI style guides

In the next release the commercial version of DM will support company-specific style guides. This will allow you to define the appearance and the behavior of special widgets in an object oriented way. It will also be possible to "inherit" from other forms, so you can adapt a whole application to a different style by changing the style guide.

These style guides can also be used to restrict access to classes and so to hide information from application programmers.


Build your knowledge base

Programming the Display Machine always consists of two separate programming tasks. One is the creation of the virtual machine specific to your problem domain, and the other is the creation of the application. There is not much in common between the two tasks. The languages they use are completely different - one is an object oriented programming language and the other a graphical drawing tool.

So it even makes sense to allow different people with different skills to do the work. The virtual machine may be developed by a software engineer experienced in object oriented design and the interface by an application programmer or even by a specialist in visual design and ergonomics. As we said above: The user interface is the application.

The Virtual Machine will be enhanced if extensions to it are requested from the application programmer's side.

The development cycle of the Virtual Machine and DM Interface typically looks like this. One or more applications (two in our diagram) are produced in parallel - in the standard cyclic way. Sometimes it is necessary to enhance - or to extend - the virtual machine. In this case a trigger (the T bubble) starts an independent development. As soon this task is done, programming the DM Applications can continue.

Many applications - one Virtual Machine

The program containing the object-oriented specification is growing all the time. With each application, with each extension request issued by an application programmer, the machine becomes more powerful. The functionality is only enhanced - bugs are removed, speed is increased - and the virtual machine becomes better. For example consider the development of the 8086 processor - the basic functionality is still in your computer, but it has been enhanced dramatically. There are more registers, many more functions, and everything runs much faster. The area of the chip used for the original 8086 functionality is only a tiny part of the whole chip size - and the design was completely redone.

And, there is a whole world of programs running on this machine.

The same will happen with your own virtual machine. As more applications are written on the machine as bigger it will become - and as more functionality will be stored into it. And everything should be object oriented, as the DM approach makes it very difficult to design in a non-OO way.

Changing the virtual machine will become less and less necessary as the description of your objects becomes better and better - and this is the essence of your virtual machine:

the Virtual Machine describes the objects

the Display Program describes the applications

The big circle shows the full functionality of the virtual machine. The small circles indicate the parts used by different applications. All object descriptions are included in the big circle - and each application can decide what attributes and what functionality of each object is to be used.

The style guides allow access to special data to be restricted.

The big circle will grow - and it is for you to decide if it makes sense to produce new virtual machines - consisting of classes from different other virtual machines. It's real design work.

You must organize the knowledge base - and the virtual machine will help you with this task.  It's the same with "real-life" machines - some can be used for many tasks, and some are extremely specialized. Consider the kitchen - the fridge is specialized. It probably makes no sense to extend it in order to bake bread. But the "Kitchen Wiz" can be used for many things: it chops, it mixes, it slices, it dices!

Examples of virtual machines are

Each machine is (depending of the language used to specify the application) an executable program, a loadable library or just a collection of object files.

And each machine encapsulates all your knowledge about a possible group of applications.


We do it the other way

the benefits

We hope that you understand what's behind the Display Machine:

You will see more benefits when you consider your current DP requirements,  the structure of your programs and the problems involved. We at Object Tools will help you to solve those problems.


Object Tools Inc.

13267 Summit Sq. Center
Route 413 & Doublewoods Rd.
Langhorne, PA 19047

Phone: 215-504 0854
info@object-tools.com
http://www.object-tools.com