With cloud assistance, mobile apps can offload their resource-demanding computation tasks to the cloud. This leads to a scenario where computation tasks in the same program run concurrently on both the mobile device and the cloud. An important challenge is to ensure that the tasks are able to access and share the files on both the mobile and the cloud in a manner that is efficient, consistent, and transparent to locations. Existing distributed file systems and network file systems do not satisfy these requirements. Current systems for offloading tasks either do not support file access for offloaded tasks or do not offload tasks with file access. The paper addresses this issue by designing and implementing an application-level file system called Overlay File System (OFS). To improve efficiency, OFS maintains and buffers local copies of data sets on both the cloud and the mobile device. OFS ensures consistency and guarantees that all the reads get the latest data. It combines write-invalidate and write-update policies to effectively reduce the network traffic incurred by invalidating/updating stale data copies and to reduce the execution delay when the latest data cannot be accessed locally. To guarantee location transparency, OFS creates a unified view of the data that is location independent and is accessible as local storage. We overcome the challenges caused by the special features of mobile systems on an application-level file system, like the lack of root privilege and state loss when application is killed due to the shortage of resource and implement an easy to deploy prototype of OFS. The paper tests the OFS prototype on Android OS with a real mobile app and real mobile user traces. Extensive experiments show that OFS can effectively support consistent file accesses from computation tasks, no matter whether they are on a mobile device or offloaded to the cloud. In addition, OFS reduce both file access latency and network traffic incurred by file accesses.

This paper aims to provide an efficient solution for people in a city who drive their cars to visit several destinations, where they need to park for a while, but do not care about the visiting order. This instance of the multi-destination route planning problem is novel in terms of its constraints: the real-time traffic conditions and the real-time free parking conditions in the city. The paper proposes a novel Multi-Destination Vehicle Route Planning (MDVRP) system to optimize the travel time for all drivers. MDVRP's design has two components: a mobile app running on the drivers' smart phones that submits real-time route requests and guides the drivers toward destinations, and a server in the cloud that optimizes the routes by finding the most efficient order to visit the destinations. MDVRP uses TDTSP-FPA, an algorithm that finds the fastest route to the next destination and also assigns free curbside parking spaces that minimize the total travel time for drivers. We evaluate MDVRP using a driver trip dataset that contains real vehicular mobility traces of over two million drivers from the city of Cologne, Germany. By learning the spatio-temporal distribution of real driver destinations from this dataset, we build a novel experimental platform that simulates real, multi-destination driver trips. Extensive simulations executed over this platform demonstrate that TDTSP-FPA delivers the best performance when compared to three baseline algorithms.

This paper presents Sentio, a distributed middle-ware designed to provide mobile apps with seamless connectivity to remote sensors when the sensing code and the sensors are not physically on the same device, e.g., when the sensing code is offloaded to the cloud. Sentio presents the apps with virtual sensors that are mapped to remote physical sensors. Virtual sensors can be composed into higher-level sensors, which fuse sensing data from multiple physical sensors. Furthermore, they are mapped to the best available physical sensors when the app starts and re-mapped transparently to other physical sensors at runtime in response to context changes. Sentio was designed to work without modifications to the operating system and to provide low-latency access to remote sensors, which is beneficial to apps with real time-requirements such as mobile games. We have built a prototype of Sentio on Android. We have also developed four apps based on Sentio to understand the programming effort and evaluate the performance. The development of the apps shows that complex sensing tasks can be implemented quickly, benefiting from Sentio's high-level API. The experimental results show that Sentio achieves good real-time performance.

Spin-locks are widely used in software for efficient synchronization. However, they cause serious performance degradation on virtualized platforms, such as the Lock Holder Preemption (LHP) problem and the Lock Waiter Preemption (LWP) problem, due to excessive spinning by virtual CPUs (VCPUs). The excessive spinning occurs when a VCPU waits to acquire a spin-lock. To address the performance degradation, hardware facilities, such as Intel PLE and AMD PF, are provided on processors to preempt VCPUs when they spin excessively. Although these facilities have been predominantly used on mainstream virtualization systems, using them in a manner that achieves the highest performance is still a challenging issue. There are two core problems in using these hardware facilities to reduce excessive spinning. One is to determine the best time to preempt a spinning VCPU (i.e., the selection of spinning thresholds). The other is which VCPU should be scheduled to run after the spinning VCPU is descheduled. Due to the semantic gap between different software layers, the virtual machine monitor (VMM) does not have information about the computation characteristics on VCPUs, which is needed to address the above problems. This makes the problems inherently challenging. We propose a framework named AdPtive Pause-Loop Exiting and Scheduling (APPLES) to address these problems. APPLES monitors the overhead caused by excessive spinning and preempting spinning VCPUs, and periodically adjusts spinning thresholds to reduce the overhead. APPLES also evaluates and schedules “ready” VCPUs in a VM by their potential to reduce the spinning incurred by the spin-lock synchronization. The evaluation is based on the causality and the time of VCPU preemptions. The implementation of APPLES incurs only minimal changes to existing systems (about 100 lines of code in KVM). Experiments show that APPLES can improve performance by 3$\sim$49 percent (14 percent on average) for the workloads with frequent spin-lock operations.

With cloud assistance, a mobile application can offload its resource-demanding computation tasks to the cloud (public cloud, cloudlet, or personal cloud, etc). This leads to a scenario where computation tasks in the same application run concurrently on both the mobile device and the cloud. These tasks need to save, read, and write files on both the mobile device and the cloud. An important challenge is to ensure that the tasks are able to access and share the files in a manner that is efficient, consistent, and transparent to locations. The paper addresses this issue by designing an application-level file system called Overlay File System (OFS). To improve efficiency, OFS maintains and buffers local copies of data sets on both the cloud and the mobile device. OFS ensures consistency and guarantees that all the reads get the latest data. It combines write-invalidate and write-update policies to effectively reduce the network traffic incurred by invalidating/updating stale data copies and to reduce the application delay when the latest data cannot be accessed locally. To guarantee location transparency, OFS creates an unified view of the data that is location independent and is accessible as local storage. Our experiments show that OFS can effectively support task offloading and efficient execution of offloaded tasks by significantly decreasing both file access latency and network traffic incurred by file accesses.

On virtualized platforms, Lock Holder Preemption (LHP) is known as a serious problem, which makes virtual CPUs (VCPUs) spin excessively while waiting for locks and seriously degrades performance. To address this problem, hardware facilities, such as Intel PLE and AMD PF, are provided on processors to preempt spinning VCPUs. Though these facilities have been predominantly used on mainstreamvirtualization systems, using them in a manner that achieves the highest performance is still a challenging issue. The core issue in dealing with the LHP problem is to determine the best time to preempt spinning VCPUs (i.e., spinning thresholds). Due to the semantic gap between different software layers, the virtual machine monitor (VMM) does not have the information about whether a VCPU is spinning normally (i.e., waiting for a lock to be released quickly) or is spinning excessively (i.e., waiting for a lock which is currently held by a preempted VCPU and cannot be released quickly). Thus, it cannot determine adequate thresholds for preempting spinning VCPUs to achieve high performance. Preempting spinning VCPUs late wastes system resources. Preempting them prematurely incurs costly context switches between VCPUs and delays lock acquisition. The paper addresses the issue of preempting spinning VCPUs with an end-to-end approach named Adaptive PLE (APLE). APLE monitors the execution efficiency of each VM by collecting the overhead incurred by wasteful spinning and wasteful VCPU switches. Then, it periodically adjusts the spinning threshold to reduce the overhead and increase the execution efficiency of the VM. The implementation of APLE incurs only minimal changes to existing systems (about 80 lines of code in KVM). The experiments with multicore workloads show that APLE can improve throughput by up to 68%.

Nowadays, huge volumes of data are organized or exported in a tree-structured form. Querying capabilities are provided through queries that are based on branching path expression. Even for a single knowledge domain structural differences raise difficulties for querying data sources in a uniform way. In this paper, we present a method for semantically querying tree-structured data sources using partially specified tree patterns. Based on dimensions which are sets of semantically related nodes in tree structures, we define dimension graphs. Dimension graphs can be automatically extracted from trees and abstract their structural information. They are semantically rich constructs that support the formulation of queries and their efficient evaluation. We design a tree-pattern query language to query multiple tree-structured data sources. A central feature of this language is that the structure can be specified fully, partially, or not at all in the queries. Therefore, it can be used to query multiple trees with structural differences. %and We study the derivation of structural expressions in queries by introducing a set of inference rules for structural expressions. We define two types of query unsatisfiability and we provide necessary and sufficient conditions for checking each of them. Our approach is validated through experimental evaluation.

LDAP (Lightweight Directory Access Protocol) directories are being rapidly deployed on the web. They are currently used to store data like white pages information, user profiles, and network device descriptions. LDAP directories offer scalability advantages over current database technologies, as well as being more flexible. However, as users begin to use them for Directory Enabled Networking tasks such as provisioning network services, allocating resources, reporting, managing end-to-end security, and offering mobile users customized features that follow them, LDAP's limited functionality becomes a significant barrier to progress. For example, LDAP directories do not have active database functionality (i.e., triggers). However, triggers are necessary for monitoring changes to directories and taking appropriate actions, just as they are for databases. Such functionality is crucial to take full advantage of proposals such as the Directory Enabled Network (DEN) initiative. Currently, trigger functionality is non-standardized for LDAP and each vendor's solution is non-portable. We built the Lightweight Trigger Access Process (LTAP) gateway to provide a portable way to add triggers to a LDAP directory. We describe the trigger language, the gateway's implementation, as well as our experiences gained both during implementation and from our users. LTAP is currently being used in several projects. LTAP can be downloaded at http://ltap.bell-labs.com. Copyright © 2000 John Wiley & Sons, Ltd.

The Ode object-oriented database system supports the creation and manipulation of objects with versions. Versioning is orthogonal to type – any object in the database can be versioned at any time, and the same code works on both versioned and non-versioned instances. Object versioning is supported by many object-oriented databases (e.g. Gemstone, ObjectStore, Versant). However, the facilities are often complex and may not quite match application requirements. Furthermore, the implementation techniques are not well-documented. Ode took the approach of designing a minimal set of versioning primitives with which users can specify the exact policy they require. To illustrate the flexibility and power of these versioning facilities, we use them to implement a set of previously suggested versioning capabilities. We describe how these versioning facilities are implemented, and discuss our experience in using them. Copyright © 1999 John Wiley & Sons, Ltd.

The Ode object-oriented database provides sophisticated trigger facilities. We illustrate their use and capabilities by writing a non-trivial trigger application–a stock market monitoring application. We will then describe our experiences in using the Ode trigger facilities to build the stock monitoring application. Our experiences with the performance and expressiveness of Ode triggers reveal advantages and limitations of the current system. Finally, we propose future work to remove the limitations. ©1997 by John Wiley & Sons, Ltd.

Ode is an active database system and environment based on the object paradigm. Triggers are the basic ingredient of active databases. Ode triggers are event-action pairs. An event can be a composite event (i.e. an event composed from other events). Composite events are detected by translating the event specifications into finite state machines. In this paper, we describe the integration and implementation of composite event-based triggers into the Ode object database. We focus on implementation details such as the basic trigger events supported, the efficient posting of these events, the handling of transaction-related events and the integration of triggers into a real database. We also describe the run-time facilities used to support trigger processing and describe some experiences we gained while implementing triggers. We illustrate Ode trigger facilities with a credit card example.

Extended transaction models in databases were motivated by the needs of complex applications such as CAD and software engineering. Transactions in such applications have diverse needs, for example, they may be long lived and they may need to cooperate. We describe ASSET, a system for supporting extended transactions. ASSET consists of a set of transaction primitives that allow users to define custom transaction semantics to match the needs of specific applications. We show how the transaction primitives can be used to specify a variety of transaction models, including nested transactions, split transactions, and sagas. Application-specific transaction models with relaxed correctness criteria, and computations involving workflows, can also be specified using the primitives. We describe the implementation of the ASSET primitives in the context of the Ode database.

Ode, a database system and environment based on the object paradigm, is discussed. Ode is defined, queried and manipulated using the database programming language O++, which is based on C++. The O++ compiler translates O++ programs into C++ programs that contain calls to the Ode object manager. The implementation of O++, the Ode object manager, and the translation of the database facilities in O++ are described. The problems encountered in the implementation and their resolutions are reviewed.>

Abstract C++ objects of types that have virtual functions or virtual base classes contain volatile (‘memory’) pointers. We call such pointers ‘hidden pointers’ because they were not specified by the user. If such C++ objects are made persistent, then these pointers become invalid across program invocations. We encountered this problem in our implementation of O++, which is a database language based on C++. O++ extends C++ with the ability to create and access persistent objects. In this paper, we describe the hidden pointers problem in detail and present several solutions to it. Our solutions are elegant in that they do not require modifying the C++ compiler or the semantics of C++. We also discuss another problem that arises because C++ allows base class pointers to point to derived class objects. C++ has emerged as the de facto standard language for software development, and database systems based on C++ have attracted much attention. We hope that the details and techniques presented will be useful to database researchers and to implementors of object‐oriented database systems based on C++.

Concurrent C/C++ is a superset of C and C++ that provides parallel programming facilities based on message passing. Upon porting Concurrent C/C++to a shared memory multiprocessor, the authors believed it would be appropriate to supplement Concurrent C/C++ with explicit facilities for synchronizing accesses to shared data structures. The capsule, which is a shared memory access mechanism designed especially for Concurrent C/C++ to match the C++data abstraction facility called the class, is discussed. Capsules are like monitors but they have significant advantages. Capsules satisfy T. Bloom's (1979) criteria for expressiveness of synchronization conditions, support inheritance, allow operations to execute in parallel, and permit them to time out. The design of capsules is reviewed. The author evaluates existing shared memory mechanisms, describes capsules, gives examples of capsules, compares capsules with monitors, and discusses how capsules are implemented by the Concurrent C compiler.>

The concept of a trigger is central to any active database. Upon the occurrence of a trigger event, the trigger is “fired”, i.e, the trigger action is executed. We describe a model and a language for specifying basic and composite trigger events in the context of an object-oriented database. The specified events can be detected efficiently using finite automata.

Abstract C does not have exception handling facilities. Errors are handled by examining the value returned by each function and signals (conditions reported to the program) are handled by using library functions. These approaches lead to ad hoc error‐handling techniques and can make programs hard to understand. Exceptional C, a superset of C, provides exception handling facilities. Exceptional C integrates the two techniques used by C programmers (i.e., status values and signals) to handle errors into one unified exception handling mechanism. In this paper, I review exception handling models, specify the criteria used for designing the exception handling facilities in Exceptional C, and then describe these facilities. I also illustrate the use of the exception handling facilities with examples.

Abstract Concurrent C (C++) is a parallel superset of C (C++). Versions of Concurrent C have now been implemented for a variety of uniprocessors and multiprocessors. We first implemented a uniprocessor version of Concurrent C correctly anticipating that it would be relatively easy to extend the uniprocessor implementation to run on multiprocessors. Concurrent C is translated to C. The generated C code contains calls to the C library implementing the Concurrent C run‐time system. This paper describes the ‘hard core’ details of the Concurrent C implementation: the specifics of process states, the data structures used, the library functions, and the C code generated for various Concurrent C constructs. We also give an overview of the Concurrent C facilities and of the uniprocessor, distributed and shared‐memory multiprocessor implementations.

In designing the versioning facility in Ode, a few but semantically sound and powerful concepts are introduced that allow implementation of a wide variety of paradigms. Some of the salient features of these versioning facilities are the following: (1) object versioning is orthogonal to type; (2) reference to an object can be bound statically to a specific version of the object or dynamically to whatever is its latest version; and (3) both temporal as well as derived-from relationships between versions of an object are maintained automatically. These facilities have been incorporated seamlessly into Ode's database programming language, O++. The new language constructs are powerful enough to make O++ a suitable platform for implementing a variety of versioning paradigms and application-specific systems.>

OdeView is the graphical front end for Ode, an object-oriented database system and environment. Ode's data model supports data encapsulation, type inheritance, and complex objects. OdeView provides facilities for examining the database schema (i.e., the object type or class hierarchy), examining class definitions, browsing objects, following chains of references starting from an object, synchronized browsing, displaying selected portions of objects (projection), and retrieving objects with specific characteristics (selection).

OdeView is the graphical front end for Ode, an object-oriented database system and environment. It is intended for users who do not want to write programs in Ode's database programming language O++ to interact with Ode but instead want to use a friendlier interface to Ode. OdeView is based on the graphical direct manipulation paradigm that involves selection of items from pop-up menus and icons that can be clicked on and dragged. OdeView provides facilities for examining the database schema examining class definitions, browsing objects, following chains of references, displaying selected portions of objects or selecting a subset of the ways in which an object can be displayed (projection), and retrieving specific objects (selection).

Abstract Message‐passing facilities used for interprocess communication fall into two categories: asynchronous and synchronous. Most concurrent programming languages support either synchronous or asynchronous message passing, but not both. Although these two kinds of message passing are equivalent because each can be implemented in terms of the other, programmers seem to have a strong preference for one or the other. Concurrent C is a parallel superset of C that initially provided only synchronous message‐passing facilities. Some users and potential users of Concurrent C indicated a strong preference for asynchronous message‐passing facilities. In response to this feedback, we eventually extended Concurrent C with asynchronous message passing. The issue of synchronous message passing versus asynchronous message passing has been much discussed in the context of operating systems but not in the context of programming languages. In this paper, I will explain the decision to add asynchronous message passing to Concurrent C. I will first summarize and review the pros and cons of synchronous and asynchronous message passing. I will then compare four versions of an example written using synchronous and asynchronous message passing, discuss some details about implementing synchronous and asynchronous message passing facilities, examine the costs involved in using these facilities, and present some experimental results.

ODE is a database system and environment based on the object paradigm. It offers one integrated data model for both database and general purpose manipulation. The database is defined, queried and manipulated in the database programming language O++ which is based on C++. O++ borrows and extends the object definition facility of C++, called the class. Classes support data encapsulation and multiple inheritance. We provide facilities for creating persistent and versioned objects, defining sets, and iterating over sets and clusters of persistent objects. We also provide facilities to associate constraints and triggers with objects. This paper presents the linguistic facilities provided in O++ and the data model it supports.

Concurrent C, a superset of C providing parallel programming facilities, is considered. A uniprocessor version of Concurrent C was first implemented. After experience with this version, the Concurrent C implementation was extended to run on two types of multiple processor systems: a set of computers connected by a local area network (the distributed version) and a shared-memory multiprocessor (the multiprocessor version). Experience with implementing and using these versions of Concurrent C is described. Specifically, the language changes triggered by the multiple processor implementations, some sample programs, a comparison of the execution times on various systems, and the suitability of these multiple processor architectures are discussed.>

Abstract C++ and Concurrent C are both upward‐compatible supersets of C that provide data abstraction and parallel programming facilities, respectively. Although data abstraction facilities are important for writing concurrent programs, we did not provide data abstraction facilities in Concurrent C because we did not want to duplicate the C++ research effort. Instead, we decided that we would eventually integrate C++ and Concurrent C facilities to produce a language with both data abstraction and parallel programming facilities, namely, Concurrent C++. Data abstraction and parallel programming facilities are orthogonal. Despite this, the merger of Concurrent C and C++ raised several integration issues. In this paper, we will give introductions to C++ and Concurrent C, give two examples illustrating the advantages of using data abstraction facilities in concurrent programs, and discuss issues in integrating C++ and Concurrent C to produce Concurrent C++.

The concurrent programming facilities in both Concurrent C and the Ada language are based on the rendezvous concept. Although these facilities are similar, there are substantial differences. Facilities in Concurrent C were designed keeping in perspective the concurrent programming facilities in the Ada language and their limitations. Concurrent C facilities have also been modified as a result of experience with its initial implementations. The authors compare the concurrent programming facilities in Concurrent C and Ada and show that it is easier to write a variety of concurrent programs in Concurrent C than in Ada.>

Many current robot systems exhibit a significant degree of concurrency, doing many activities in parallel. Future sensor-based robots are expected to exhibit even more concurrency. Programs to control such robots are characterized by the need to wait for external events and/or handle interrupts, deal with concurrent activities, synchronize actions with external events and communicate with other robots/processes. In this paper, we focus on the advantages of concurrent programming for robotics and suggest that a general purpose language with the right facilities is a good vehicle for robot programming. In this context we will discuss Concurrent C, an upward-compatible extension of the C language that provides high-level concurrent programming facilities. We give a brief description of Concurrent C followed by a description of how Concurrent C programs communicate with robots and devices. We then show, by means of examples, all of which were implemented, how Concurrent C simplifies the writing of robot programs. Of specific interest are the process interaction and related interrupt handling facilities.

Abstract Types in programming languages cannot model many properties of real world objects and quantities. Consequently, many errors resulting from the inconsistent usage of program objects representing real world objects and quantities cannot be detected automatically. For example, the real variables PRICE and WEIGHT, representing the price of diesel fuel and the weight of a person, may be inadvertently added, giving a non‐sensical value; such an error cannot be detected by a compiler. The programming language Ada introduces the concept ofderivedtypes to tackle this problem. An alternative solution to this problem is the incorporation ofunits of measureas a new data attribute. Derived types only partially solve the problem of detecting the inconsistent usage of objects; some valid usages of objects are also not allowed. Moreover, the solution is inelegant and inconvenient to use. On the other hand, specification of units of measure solves the problem elegantly and conveniently. The two solutions are compared and analysed. Several ways to implement units of measure in Ada are examined.

Researchers at Bell Labs have recently developed a silicon compiler, named Plex, that automatically generates VLSI layouts of high performance and area efficient microprocessors. Plex takes as input a specification of the function to be executed and generates a complete mask-level layout of a customized microprocessor to execute that function. The Plex microprocessor interacts with the external world, via input and output wires, and interrupts. The dedicated function performed by a Plex microprocessor typically involves real-time handling of inputs and interrupts-and the real-time generation of output signals.

Abstract The rendezvous is an important concept in concurrent programming—two processes need to synchronize, i.e. rendezvous, to exchange information. The Ada programming language is the first programming language to use the rendezvous as the basis of its concurrent programming facilities. Our experience with rendezvous facilities in the Ada language shows that these facilities lead to and encourage the design of programs that poll. Polling is generally, but not always, undesirable because it is wasteful of system resources. We illustrate and examine the reasons for polling bias in the Ada language. We give suggestions on how to avoid polling programs, and suggest changes to the rendezvous facilities to eliminate the polling bias. The ramifications of these changes to the implementation of the Ada language are also discussed. Although we have focused on the rendezvous facilities in the Ada language our analysis is also applicable to other languages. A polling bias can occur in any concurrent programming language based on the rendezvous mechanism if it does not provide appropriate facilities.

Communication in a broadcast protocol multiprocessor (BPM) is inherently different from that in distributed systems formed by explicit links between processors. A message broadcast by a processor in a BPM is received directly by all other processors in the network instead of being restricted to only one processor. Broadcasting is an inexpensive way of communicating with a large number of processors on a BPM. In this paper I will describe a new approach to user-level distributed programming called broadcast programming, i.e., distributed programs written as cooperating broadcasting sequential processes (BSP). Existing concurrent programming languages do not provide facilities to exploit the broadcast capability of a BPM. The idea of distributed programs written as BSP is tailored to exploiting a BPM architecture but is not restricted to such an architecture-however, implementation of the broadcast capability may not be as efficient on other architectures. I will illustrate the utility and convenience of broadcast programming with many examples. These examples will also be used to explore the suitability and advantages of BSP and to determine appropriate facilities for BSP.

Several office information systems based on the concept of forms have been built. However, none of these systems provides a high level language for defining forms. In this paper, I will discuss the advantages of a high level form definition mechanism, state the requirements that should be satisfied by such a mechanism, and then propose a high level form definition language based on the concept of abstract data types in programming languages. The proposed mechanism can be used in a form manipulation system. Alternatively, it can be incorporated into an existing languageor be the core of a specialy designed form manipulation language. The form definition language is illustrated by two exemplary form definitions.

Abstract A prototype electronic form system was implemented to test the feasibility of a high level form definition mechanism. This mechanism is based on the concept of abstract data types in programming languages. This paper briefly discusses prototypes in general and describes the prototype electronic form system—specific objectives, design decisions, the implementation and evaluation. The prototype has proven invaluable in providing a better understanding of the facilities that should be included in a form definition language and of the implementation issues. Success of the prototype can be attributed to keeping prototype objectives in perspective throughout its implementation and ensuring that the objectives were not violated by any design decisions or implementation restrictions.

Abstract Formal specifications (algebraic) are given for an informally specified small subsystem of the Change Management Automatic Build System. A comparison of the two specifications shows that although informal specifications are easier to read, the formal specifications are clearer, specify operation domains precisely, define the interaction between the operations, show the incompleteness of the informal specifications and are devoid of implementation details. The formal specifications pointed to the need of a function not in the subsystem whose inclusion would improve the system design. This inclusion is now being considered. However, the use of algebraic specifications requires practice and experience. Although the formal specification of large systems is somewhat impractical at the moment, experience in using formal specifications can lead to better informal specifications.

Forms have been used in the design of at least three office automation systems (OfficeTalk, Odyssey, and OFS). Forms help ease the transition from a manual office system based on paper forms to a computer office system based on electronic forms. Forms also exhibit other advantages, not exploited presently, that make them very desirable for inclusion in office automation systems of the future. Potential capabilities of electronic forms are explored by focusing on three important aspects-fields, abstraction, and access rights. Electronic forms can have a large variety of fields; constraints and rules can be associated with these fields and automatically enforced. Moreover, forms are similar to abstract data types. Treating forms as abstract data types allows their being used as an abstraction tool and facilitates many kinds of automatic error checking. Finally, access rights can be associated with forms to ensure that forms are accessed and/or modified by appropriate users only. To illustrate the ideas presented, an exemplary form definition is presented and some implementation details discussed.

A serious impediment to the integrated use of databases across international boundaries, scientific disciplines and application areas is the use of different units of measure, e.g., miles or kilometers for distance, dollars or rupees for currency, and Btu or kWh for energy. Units of measure are not specified in the data definition language but associated by convention with values in the database. Inconsistent usage of values with different units cannot be checked atuomatically. Retrieval, storage, and manipulation of data values in units other than those associated with the values requires that the user perform the appropriate conversions. This process is inconvenient and error prone. These problems are illustrated by an international database example.