[]
DejaVU Online
-- Project DejaVu (1992)
[]
-
[up]
[up]
introduction
background
hypermedia
components
studies
conclusions
Software components
Our project aims at providing a software platform
that supports the development of distributed
hypermedia applications.
In this section we will delineate the software
components that we plan to develop
in the context of our project.
We distinguish between three layers of software.
Our implementation platform Active C++/DLP
must be regarded as the bottom layer.
We consider what we call the linguistic symbiosis between
Active C++ and DLP as crucial to the success of our project.
It is one of the innovative features of our framework,
and together with the second layer, which consists of a
library and toolkit for constructing hypermedia systems,
we consider this the core of our project.
The third layer we envision is of a more general, explorative
nature. It will provide additional hypermedia
development support tools.
Linguistic symbiosis
The object oriented language C++ is a powerful language
for implementing (complex) efficient systems.
It is likely to become an industry standard of the near future.
We have recently developed Active C++, an extension of C++ with active classes
and communication by rendez-vous. See [Eliëns and Visser, 1992].
Active C++ is currently being employed for implementing
the distributed logic programming language DLP.
In order to provide a flexible and powerful software platform
for the construction of distributed hypermedia systems,
we aim at a linguistic symbiosis between Active C++ and DLP.
The notion of a linguistic symbiosis has originally been put
forward in [Ichisugi et al, 1992], and it expresses the wish to mix
computations specified in different formalisms.
More precisely it indicates a means to specify the relation
between a high level language and its underlying implementation
language in a way that allows the programmer to profit
from both worlds in a non ad-hoc manner.
Such an environment enables the programmer to effect a smooth
transition between a prototype in DLP
and an efficient implementation in Active C++,
which in our opinion may significantly reduce the production cost of
complex systems.
Another advantage of this approach is that it supports
the implementation of inferential links in a rather
direct way.
Active C++
Active C++ is a minimal extension of C++ supporting
active objects and communication by rendez-vous.
From the outside, for client code, there is no
distinction between calling a member of an active object or calling a member
of an ordinary object.
Whether an object is active or not is determined
by the definition of its class.
The actual object created is of a subclass
of the class defined for the object, dependent on what type of
process is associated with the object.
In addition to the encapsulation provided by the typechecking mechanism
of C++, Active C++ provides strong dynamic encapsulation by allowing
to determine the order in which method calls are accepted.
This is done by a somewhat Ada-like accept-statement.
Active C++ is implemented as a pre-compiler (which is a preprocessor
to be used before cfront)
that generates the proper derived classes for classes
that define active objects.
Currently, both light and heavy weight processes are supported.
At run-time, calls to active objects are dealt with by message-passing.
We chose this model because it is clean, it is universal (across multiple platforms),
it is easy to establish its correctness and (very important also) it is flexible.
The message-passing model moreover may be optimized
in shared-memory situations.
Other run-time models, although they may sometimes result
in a better performance in specific situations, are considered as semantically unclear,
inflexible, difficult to implement, and difficult to support uniformly on multiple platforms.
Due to the type-information we get from our pre-compiler, we can deal with
a number of issues such as distribution, persistence and type-security
quite easily. Marshalling and unmarshalling can be transparently dealt
with by inserting the appropriate stubs.
Currently, we study how we can best incorporate primitives for the allocation
of processes on a network of processors.
In our approach thus far, we assume that processes running on multiple processor machines
are created from a single root process.
This enables us to deal with arbitrary C++ code, without artificial restrictions
specific to active classes.
DLP
We will employ the distributed logic programming language DLP
that allows to specify an object oriented system in a highly
abstract way. DLP is fully described in [Eliëns, 1992].
The language DLP extends logic programming with features specifically
geared towards the specification of object oriented
systems and thus corrects what has been commonly felt to be one of the major
drawbacks of logic programming:
the lack of support for specifying large systems in a structured way .
See [Eliëns, 1989].
In addition to object oriented features, DLP supports
parallelism, by allowing objects to have activity of their
own.
For many problem areas, concurrency or parallelism is a very natural phenomenon.
Parallism and distribution fit in well with the object oriented paradigm
since the actual (possibly concurrent) behavior or location of an object
may remain hidden for the clients of an object.
An important application of DLP lies in the area of distributed knowledge based systems.
We feel that the object oriented modeling approach may support
a proper distribution of the various reasoning tasks that are involved,
by taking the natural activity of the actors in a domain as
the guideline in developing an intelligent system.
See [Eliëns, 1991] and [Eliëns, 1992c].
Hyper Utility Shell
We distinguish between three subcomponents that together will
comprise our hypermedia toolkit.
First of all, we need a (kind of) hypermedia abstract machine
that allows the storage of documents and links
and that supports elementary storage and retrieval tasks
(and in the future also versioning).
Secondly, we must provide a library of common user interface items
(widgets in X-terminology) to support the (rapid) construction
of hypermedia interfaces.
And lastly, we wish to provide a hypermedia
command language that supports a script-based definition of
links and retrieval and navigation semantics.
The name hush , which stands for
hyper utility shell ,
is used to refer to the class library providing
an interface to Tcl/Tk as well as to the interpreter
for (Tcl-like) hypermedia scripts.
(Actually, it is a variation on wish ,
the original window shell interpreter
that is part of Tcl/Tk.)
Hypermedia Abstract Machine
What we need is a uniform mechanism to store documents,
links and context information in an efficient and reliable manner.
Currently, we are exploring the use of O++,
which provides an object oriented database extension to C++ as part
of the Ode environment. See [Agrawal and Gehani, 1989] and [Agrawal and Gehani, 1990].
Our approach now is to store the raw contents of a document
as an ordinary file.
However, the additional information, such as links to
other documents and the structure of compound documents,
is stored in persistent objects.
In the near future, we intend to support persistent objects in Active C++,
which will give us greater control
over the storage and retrieval policies employed.
Another important feature of a hypermedia abstract machine
is the support it offers for various documents and link types
and the mechanisms it provides for retrieval and navigation.
Cf. [Campbell and Goodman, 1988].
As explained in our discussion of hypermedia research issues,
our framework will include the support for inferential links
that allow retrieval and navigation to be controlled by contextual
knowledge.
However, this states a research issue, rather than a ready solution!
As other interesting issues, we mention version control and support
for group work.
HyperViews
For hypermedia systems, user interface issues are closely connected
with functionality.
Apart from the primitives for define graphical
user interfaces, we also need to provide
the functionality to present the various
document types (including time-based documents)
and links in a user consumable fashion.
In [E. Rijvordt and M. Kalkman, 1992], a pilot implementation of HyperViews is described,
developed as part of a student project.
(The name HyperViews was the idea of the students.
It reflects their intention
to provide for hypermedia what InterViews provides
for the development of graphic user interfaces.)
The HyperViews library currently supports bitmaps and ordinary text
as document types and provides mechanisms to define extrinsic links
between documents of these types.
The HyperViews system is open in that similar support for
other documents may easily be defined.
A limitation of the current approach, however, is that it
offers no real support for hierarchically structured documents
and that it only supports extrinsic links.
Hence, it does not allow the sharing of information
and it is difficult to dynamically update the information of individual
without compromising the consistency of the link structure.
The next version of HyperViews (or a library akin to it)
will be based on the hush library (and Tcl/Tk primitives)
Also, we expect that our approach will be to
a greater extent script-based in order to allow
for the definition of soft (dynamic) links.
Hypermedia Command Language
From the perspective of the average user,
the most important part of our implementation
platform will consist of a shell-like
scripting language (based on Tcl).
Naturally, we need additional functionality to accommodate
the construction of hypermedia systems.
The advantage of using a Tcl-based scripting language
in this respect is that it may be extended
and integrated with existing programs.
We think that this feature is especially important
in the area of hypermedia applications,
since a language or system designer cannot possibly foresee
every need of future users.
Scripts, moreover, have the advantage that they may be
easily transported across a network.
Being human-readable, they moreover provide an
excellent way to communicate complex information.
Application Development Support
Projects such as ours are somehow intrinsically open ended.
Therefore, in addition to the two layers described
previously, we distinguish a third layer comprising
additional application development support.
To realize this layer, our intention is to reuse
other software whenever possible
by employing so-called software wrappers .
The generic phrase software wrappers
describes an approach to reusing traditional (read C-based)
software in an object oriented context (read C++)
by embedding the software in one or more classes.
An example of this approach is the work reported in
[Fekete90],
that we have discussed in section toolkit .
In a similar vein, we have developed a pre-processor
that wraps the output of the scanner
and parser generators lex and yacc in
appropriate classes.
The advantage of using a wrapping technique
is that it allows to hide many of the complex details
of the software involved behind a (rather) clean
interface.
As an aside, wrapper generators as described are
another instance of the glueing technology
around which our framework is built.
In the following we will discuss our plans
to develop an integrated programming environment
and tools for software documentation support.
Also, we will discuss our ideas with respect
to declarative specification formalisms.
Integrated Programming Environment
Developing distributed systems is error-prone.
As an essential part of our software platform we need to have
some basic tools for debugging and monitoring a system developed
in Active C++/DLP.
We intend to model our programming environment after
Field [Reiss, 1990b], which offers a collection of tools
for the static and dynamic analysis of a program.
The Field-environment supports a tool-interaction protocol
that enables tools to cooperate in the task of monitoring
a program.
This protocol allows to monitor the behavior of the distinct components
of an application separately and hence to focus the activity
of debugging on any particular component.
Our implementation platform offers the primitive needed for the implementation
of this protocol.
Currently, we are studying on formalisms that enable to specify
the interaction between tools cooperating in a debugging task in a formal way
in order to specify such protocols in a verifiable manner.
See section studies .
Software Documentation Support
Without wanting to engage in an ideological debate,
we wish to state our belief that a suitable software documentation tool
facilitates the maintenance of software.
See also [Webster, 1988].
It is our intention to document the software developed in our software
in a web-like manner
along the guidelines defended in [Knuth, 1992].
Additionally, for user documentation and reference manuals
we intend to employ the gnu latexinfo system,
that allows to generate both a latex copy and a hypertext-alike online
manual out of a common source.
As one of the possible applications of our environment,
we suggest the development of a fully fledged
hypermedia application based on these tools.
Both the latexinfo and web tools mentioned are instances of
report generators which are found in a number of systems.
We choose for report generator tools,
among other reasons, for the quality of output.
Declarative Specification Formalism
We have already argued the usefulness of a hypermedia command language.
More in general,
applications may profit from a command language
that is extendible with user-defined commands.
Another approach to support user defined command languages
in a C++ context is provided by our wrapping technique,
which allows to embed a scanner and a parser (generated by lex and yacc)
in a class.
Due to the encapsulation provided by C++ an arbitrary number of these
scanners and parsers can be employed
(whereas without wrapping only a single scanner/parser pair is allowed).
This enables the system developer to define an arbitrary number
of application specific languages.
Whether this is the most viable approach depends of
course on the nature of the application at hand.
For some applications visual languages may considered
to be more appropriate. See [Harel, 1988], [Grafton, 1985], [Ichikawa et al, 1990].
Certainly, we need more experience in this area.
Ultimately, we like to provide the means to derive a prototype
system from a declarative specification of an application.
However, specification technology has not matured enough yet
to make this at all possible.
Our approach of supporting an extendible command language
meets our ends to some extent.
In addition, however, we wish to explore how to translate
formal specifications, in Z or a related specification language,
to DLP automatically.
Suggestions in this direction can be found for instance in [Diller, 1990].
An advantage of using DLP to implement such specifications
is its support for distributed processing.
Finding the proper translation mechanisms to represent specifications
in DLP is a difficult but potentially very fruitful research issue.
If successful it would result in a support environment for the development
of applications other than hypermedia systems as well.
Apart from the means for specifying a system we would also like to provide
some support for verification.
Our thoughts in this respect are directed towards
applying a theorem prover such as Otter [Wos et al, 1992], or a special purpose
theorem prover built in DLP, for verifying invariance and
consistency assertions.
[]
-
[up]
[up]
introduction
background
hypermedia
components
studies
conclusions
