2 Application Development

Chapter 1 used a rather simple application as example. This chapter shows how to use functors for the modular development of larger applications.

2.1 Functors for Modular Applications

Principles of good software engineering suggest that larger applications should be designed and assembled from a collection of smaller modules. In Oz, this decomposition can be realized in terms of several functor definitions.

The primary purpose of a functor is to compute a module: It takes modules as input and computes a new module as output. As we have seen already, the import section of a functor specifies its inputs as a list of module names. In addition, functors may also have an export section which is basically a list of feature/value pairs that describes the module computed by the functor.

As demonstrated in Section 1.5 an application is run by executing the root functor. In our particular example, the root functor was rather simple in that it only imported system modules. However, larger applications will typically import modules computed by other application functors.

2.2 Example: Last Minute Flights

In the following we will build a trivial flight booking system featuring three components:

  1. A data base server: It maintains a data base that contains available flights, where each flight has a unique id by which it can be identified. At first, the data base is not even persistent, but as we incrementally refine and improve our application, the data base evolves into a persistent and distributed data base server.

  2. A graphical flight booking form, where a travel-minded user can choose a flight, enter her name, her E-mail address and so on. Later we will show how to build a web-based interface serving the same purpose.

  3. The main component of our application that manages user requests to the data base and sets up the application.

All components are programmed as functors.

2.3 The Data Base

Let us start with the data base, which is the most straightforward part of our application. The data will be held in a dictionary that uses integers as keys, and arbitrary data structures as entries. The functor definition resides in file DB.oz and its toplevel structure is as follows:

<Export specification for DB.oz> 
<Body for DB.oz> 

The functor has no import specification, and its export specification is as follows:

<Export specification for DB.oz>=
   add:    Add
   get:    Get
   getAll: GetAll
   remove: Remove

The specification determines that the functor's module provides the features add, get, getAll, and remove, where the value of each feature is given by the variable after the following colon. The values of these variables are then computed by the functor's body.

For convenience, the export specification above may also be written more succinctly as follows:

<Export specification for DB.oz (with syntactic sugar)>=

The shortcut to just use a variable identifier starting with a capital letter, defines both the variable identifier as well as the feature. The feature is the variable identifier with its first character changed to lowercase.

The functor body is of less importance to us here, however, you can find it in Section A.1. One advantage of modular program development is that during the design of an application one may concentrate first on finding the right interfaces, and only then provide corresponding implementations.

Even though the functor does not import any module, it uses predefined procedures (for example, Dictionary.new to create a new dictionary). The compiler provides a set of variable identifiers, that refer to the basic operations on all primitive Oz data types. This set of identifiers is known as the base environment and is documented in detail in ``The Oz Base Environment''.

When a functor definition is compiled, all free variable identifiers must be bound by the base environment.

2.4 The Graphical Input Form

The functor that implements the graphical form to book flights has the following structure, and its definition resides in file Form.oz:

   proc {Book Fs ?Get}
      %% Takes a list of flights and returns the booked flight
      %% and information on the booking user
<Implementation of Book> 

2.5 The Root Functor

The root functor for our last minute flights application uses the previously defined functors that maintain the data base and that provide the user form. The root functor's definition resides in file LMF.oz:

   DB Form            % User defined
   System Application % System
   %% Enter some flights
<Sample flights> DB.add}
   %% Book until all flights sold out
   proc {Book}
      case {DB.getAll}
      of nil then 
         {System.showInfo 'All flights sold.'}
      [] Fs then 
         O={Form.book Fs}
         {System.showInfo ('Booked: '#O.key# 
                           ' for: '#O.first# 
                           ' '#O.last# 
                           ' ('#O.email#')')}
         {DB.remove O.key}
   {Application.exit 0}

2.6 Compilation

Functors also are compilation units. Each functor definition is compiled separately. For our example, the following sequence of commands

ozc -c DB.oz -o DB.ozf
ozc -c Form.oz -o Form.ozf
ozc -c LMF.oz -o LMF.oza

compiles our example functor definitions. If you now change the functor definition in, say, DB.oz but the interface of the created functor remains the same, none of the other functor definitions need recompilation.

Note that we have chosen as file extensions for pickled functors that are not supposed to be run as applications the string ozf. For the root functor of our application we chose oza. This is completely transparent as it comes to the semantics of our program, it is just a convention that makes it easier to tell apart which pickled functors are root functors of applications.

2.7 Execution

As before, we just execute the root functor of our application by applying the ozengine command to LMF.oza:

ozengine LMF.oza

The next chapter (Chapter 5) explains how applications that consist of several functors are executed.

Denys Duchier, Leif Kornstaedt and Christian Schulte
Version 1.4.0 (20080702)