Building an End-user-oriented Application Framework
by Meta-programming
A Case Study
Position Paper for
OPSLA'99 Metadata and Dynamic Object-Model
Pattern Mining Workshop
Reza
RAZAVI
Laboratoire d'Informatique de Paris
VI (LIP6)
Université Pierre et Marie
Curie – CNRS - Case 169
4, place Jussieu - 75252 Paris
Cedex 05 – France.
"Each system we build is in fact a problem-specific
language" A. Goldberg [1].
Keywords: end-user-oriented application framework,
domain-specific language, meta-programming, meta-modeling, reflection.
Abstract
This position paper reviews some outcomes of an industrial
experience on design and development of evolving systems and families
of similar software. During this project, our focus was on 1) minimizing
resources required for the development and maintenance of two software
systems in relative domains; and 2) offering every end-user a customized
and customizable software. These goals were achieved by 1) realizing that
those two systems could be conceived as an specialization of a same application
framework; and 2) by considering each system as a family of similar
software, and so integrating in that application framework appropriate
tools in order to let different categories of end-users customize, adapt
and evolve their software, by means of declarative specifications,
without being totally dependent on programmers. We call the
resulting system an end-user-oriented application framework.
It was designed and implemented, partially, by means of meta-modeling
and
meta-programming techniques. Moreover, reflective techniques
permitted us to enhance the code and raise our productivity.
Producing customized and customizable software
During this industrial project the following situation happened.
A client requested us to develop a software system, while we had already
developed such a software in a related domain. We neither had sufficient
development resources to launch a quite new project for that, nor were
willing to do so, for technical and economical reasons. So, we decided
to reuse as maximum as possible the resources (development team and code)
of the first system.
After having analyzed the submitted project, we realized
that these two systems could be conceived as an specialization of a same
application framework. This had actually an enormous advantage for us.
In fact, an alternative solution was to reuse some components of the first
system, and to launch a new platform for developing the second one. Although
such an strategy could help us to start the project, it would rapidly conduct
us to a situation were we had to develop and maintain in parallel two similar
systems. With the decision to build a unique platform to produce the two
above mentioned systems, we were avoiding this major inconvenient.
Following this analysis and the subsequent decision,
we started to make evolve the preliminary system toward a more generic
one, capable of being specialized to represent each of the two systems.
This goal was achieved by an approximately two-year iterative development
process. It consisted mostly of creating frameworks to capture the commonalties
and differences of these two systems. The result was very satisfying for
the development team because of our important gain on productivity. But
from the users' point of view, there was still an important problem to
resolve.
In fact, the systems that we delivered were not tailored for every end-user.
We were receiving a lot of requests about some lacking functionality from
a category of clients, while others were complaining from exceeding or
non adapted ones. There where practically no ways for end-users to customize
those systems to fulfil specific requirements. For obvious reasons, it
was not possible to develop as many software as there were specific requirements.
Moreover, we believe that it is not up to the developers to decide about
the end-user’s customizations. This is best done by the end-users themselves,
if they are provided adequate tools.
So, we decided to consider each of these two systems as
a family of similar software (actually they were it). Then, we integrated
in our application framework appropriate tools in order to let different
categories of end-users customize, adapt and evolve their software by means
of domain-oriented languages, without being totally dependent
on programmers. This was achieved after a one more year design
and development effort. We call the resulting system an end-user-oriented
application framework, i.e. any of its specializations is itself an
application framework, but with an end-user orientation. By end-user
orientation we mean that non-programmer end-users are provided graphical
user-friendly tools, based on domain-oriented languages, to produce
Specializations.
By Specialization, we mean a set of descriptions
concerning how somebody wants to customize an end-user-oriented application
framework. So each Specialization deals with one or more customizable
aspect of this system. A customizable aspect
is, theoretically,
any aspect of the system that users need to be able to customize dynamically.
For example, adding attributes or changing a functionality, etc. An Specialization
can be designed for at least two reasons : 1) to adapt an evolving system
to new requirements; 2) to specify the characteristics of a particular
system belonging to a family of similar software. We call Specialization
process the process which leads to create an
Specialization,
and to integrate it dynamically in the application framework.
During this project, we developed several domain-oriented
languages. Every domain-oriented language is concerned with
the creation and the interpretation of specifications for one customizable
aspect of the system. To create Specializations, our end-users
were provided graphical interfaces (Specialization editing interfaces
or editor for short). Here is the list of editors that we developed
:
-
Primitive functions editor, for specifying the primitive
functions (business logic) of the system, by an expert-user.
-
Macro function editor, for specifying a valid mono-task
and reusable sequence of primitive functions.
-
Program editor, for specifying valid sequences of
multi-task primitive functions.
-
"Workflow" editor, for specifying valid sequences
of programs with loops and some extra instructions.
-
Document editor, for specifying contents and style
of required documents (coupled with MS Word and Excel).
-
Type and Attributes editors,
for specifying user-defined and reusable typed attributes for some domain
objects.
-
Configuration panel editor, for specifying dialog
boxes for configuration panel (creating dialogues and choosing options
present in that dialog).
-
Editors’ editor, for specifying keyboard shortcuts,
opening size and position for editors.
-
On-line help editor, for specifying on-line help for
every menu item.
-
User Messages editor, for internationalization management
mechanisms.
Our end-user-oriented application framework was
built by integrating ten
domain-oriented languages (the above list)
into an specialization of VisualWorks.
It proposed also, five levels of customization :
-
code level customization, accessible to developers
: this corresponds to writing code that specializes the application framework.
It provides domain-oriented application frameworks which incorporate
also the user-oriented customization facilities.
-
domain-oriented language customization, accessible to
developers : this is an outcome of one of the two reflective aspects
of our system (another one is the reintegration of domain-oriented languages
facilities into the application framework). It corresponds to the use of
user-oriented facilities by the developers to produce a preliminary release
of each family of similar software. We call that the developer's reference
release. It is destinated to the domain expert. This work is operated
on a domain-oriented application framework.
-
domain-oriented language customization, accessible to
domain experts : this corresponds again to the use of user-oriented
facilities to customize the developer's reference release in order
to adapt it to different branches in that domain. In this way, an expert
can produce several releases. We call each of them the expert's reference
release (for a branch of activity)
-
domain-oriented language customization, accessible to
deployment manager : this is destinated to those people in client companies
who are responsible to install and configure software. For that they will
work on an expert's reference release for their branch of activity.
-
domain-oriented language customization, accessible to
the effective end-users : if the precedent customizations are well
done, normally at this level there should be no need to such an operation.
Although, a decision can be taken by the precedent customization levels
to delegate some customization tasks to the effective end-users. One should
observe that an important outcome
of this process is that, theoretically,
there will be no more need for the long lists of preferences proposed habitually
to users. At this level,
everybody receives the software tailored for
him, proposing the exact list of data and functionality that it requires
to accomplish his activities.
Figure 1 : delivering and adapting software be means
of an end-user-oriented application framework.
This end-user-oriented application framework was
actually instantiated twice, but because of industrial property questions,
its end-user oriented customization tools served only one of the two systems.
These two families of similar software are currently in production.
An example of a similar approach could be the LearningWorks system [8].
Hereafter comes some more precision about this end-user-oriented
application framework and its construction process, altogether
with a possible interpretation of some of its important characteristics.
This interpretation is elaborated by recent work. Several reasons could
be enumerated to explain this lately clarification of the underlying concepts
and mechanisms of this project. The most important should be its experimental
character and industrial context. In spite of the innovative character
of our approach and way of doing things, our aim was not to do research
in this matter, but to produce industrial software working in critical
situations. So, like most industrial projects, we had to concentrate our
effort to make things work. We had never time nor resources to formalize
our practices. Another reason should be a lack of feedback and yet less
formalization from similar projects. This is a tentative to participate
in this effort. Work is in progress ...
Dynamic integration of Specializations
by Partial Meta-modeling and Meta-programming
Domain-oriented languages serve to create Specializations.
Specializations are integrated dynamically in an end-user-oriented
application framework in order to customize it. We suggest a
double
modeling process for implementing the dynamic integration of
the Specializations. That is, elaborating a standard domain model
for the entire system, and in parallel, a modeling of the models (meta-modeling)
of some customizable domain aspects. We call that partial meta-modeling
of a system.
For every domain model, it is possible to define several
double
modeling relations, where we put in relation a meta-model
with
its corresponding (partial) model. Suppose now such a couple (MM,M)
where MM represents the meta-model and M the model. This will let us to
propose two definitions. We call program, a code that instantiates
directly classes belonging to the model M. So, this is the developer that
has the knowledge of what is to be instantiated. She is hard-coding
her
knowledge of the domain model. And, we call meta-program
[10,
13, 17], a code that
computes the instantiation of classes belonging
to M. This computation is driven by the meta-model MM, and is parameterized
to take into account the knowledge furnished at run-time, here by means
of a Specialization. Here the developer is not hard-coding his domain
knowledge. He is hard-coding his knowledge of the domain meta-models.
An end-user-oriented application framework is composed of programs
and meta-programs. In the way, users obtain a chance to express themselves,
and the software the potential to be customized "without" coding. In fact,
we are always coding. What changes is our way of coding.
One should consider that double modeling relations
can exists in several layers. That means, for example, a model M1 can participate
in two distinct double modeling relation with models M2 en M3, where
it plays once the role of a meta-model (here versus M2) and a second time
the role a model (here versus M3). In our notation, this will be (M1, M2)
and (M3, M1). This means that M3 serves to generate M1 and M1 serves to
generate M2. But, intuitively, it makes no sense to have in a system simultaneously
(M1, M2) and (M2, M1) couples.
Constructing domain-oriented languages
Domain-oriented languages are created during every
day projects. A large variety of techniques are proposed for elaborating
them. For example, N.Revault & al. [9] propose a double meta-modeling
approach to elaborate completely distinct languages for programmers and
users. An expert system, NeOpus [11], is used to translate specifications
from users’ language to programmers’ one and also from this latter format
to an executable code. A. Arsanjani [10] proposes to "represent each meta-model
(model of possible solutions) by a context-free grammar defining the valid
object interaction sequences for that domain".
In our case, two elements participate in the implementation
of domain-oriented languages : (1) a syntactic editor for
producing specifications "written" in that language (Specializations)
and, (2) an interpretation mechanism.
Syntactic editors
By syntactic editor we mean an editor that integrates
a "syntactic analyzer". The role of syntactic editors is to offer
direct manipulation, graphical construction interface to produce specification
conform to the syntax of the language. In general, a "parse tree"
(an abstract representation of the user’s intentions in terms of an object
cluster) is associated to every specification. This "parse tree"
can be either created by "parsing" a textual representation of the specifications,
or be produced directly by the syntactic editors as on object cluster
representing the "parse tree", which is then interpreted by the
corresponding framework.
The "law" governing the design of syntactic editors
is to model them such that they satisfy some end-users’ specification expression
requirements. This must be a respond to the following question : what
end-users need to specify ? In addition, a syntactic editor's
design must be synchronized with the interpretation capabilities of the
corresponding interpretation mechanism .
Interpretation mechanism
The interpretation mechanism, like any interpret,
is interested in the semantic of end-users’ specifications. Its role is
to run them on the computer. The things can be arranged so that a framework
can serve interpretation mechanism. In general, a "parse tree"
(an abstract representation of the user’s intentions in terms of object
instances) is associated to every specification, which is then interpreted
by the corresponding framework.
Example
The VisualWorks' Application development framework offers
a programmer-oriented tool for creating applications. This was one of the
major changes of VisualWorks relatively to ObjectWorks. Two classes collaborate
to implement the syntactic and semantic aspects of the associated language:
UIPainter and UIBuilder. UIPainter generates a Smalltalk literal array
script for every visually constructed application (interface). This script
is syntactically well-formed simply because UIPainter is developed so that
to assure it. Here is a small example of such a script :
helloWorldSpec
^#(#FullSpec
#window:
#(#WindowSpec
#label: ' '
#min: #(#Point 20 20 )
#max: #(#Point 1280 1024 )
#bounds: #(#Rectangle 221 465 389 504 )
#isEventDriven: true )
#component:
#(#SpecCollection
#collection: #(
#(#LabelSpec
#layout: #(#Point 35 8 )
#label: 'Hello World !' ) ) ) )
This specification is "parsed" to create a "parse tree"
composed of UISpecification subclasses instances (here FullSpec, WindowSpec,
SpecCollection, LabelSpec). The interpretation of this "parse tree"
provides the following result :
To obtain this application, a semantic function must be
associated to that "parse tree". This role is accomplished by UIBuilder
machinery. More precisely, an application specification script is
a Smalltalk literal array. This literal array is translated as a "Spec
tree" by Array >> decodeAsLiteralArray method. The translation process
is very similar to the way Parser analysis Smalltalk code and constructs
an abstract syntactic tree composed of ProgramNodes. The "Spec tree" is
then interpreted by an instance of UIBuilder. This process begins
with the following message send : aUIBuilder add: aSpec.
Role of frameworks in the implementation
of domain-oriented languages
"Inside every domain-specific framework, there is a language
crying to get out (Thomas Jay Peckish II)" [5]. During this project, we
constructed several frameworks. Actually, most of these frameworks could
evolve toward black-box frameworks [6] during iterations and refactoring
process.
Later, we find out that they served well as support for
implementing the interpretation mechanisms. So, making frameworks
evolve is a way (and perhaps one of the most realistic ones) to construct
domain-oriented languages.
Some other aspects
Specialization repository
In this project, a repository of Specializations
was also managed. This repository could be edited by the Specialization
Management Editor.
The idea of an Specialization repository came to
us first from the VisualWorks' inconvenient solution to conserve environment
modifications, that is Image save. This causes several problems : (1) users
are not really familiar with this concept (2) in case of Image corruption
modifications can often not be restored (3) user modifications can not
be easily transferred from one Image to another (4) Images are hard disk
space consumers. We decided so to remove this facility (Image save) and
replaced it by a repository.
The principle was to develop a framework letting every end-user
tool to save it's created or modified objects into a namespace within a
repository. We used VisualWorks' BinaryObjectStorage machinery (BOSS) as
default mechanism to save and retrieve objects and simple directories as
namespaces. We didn't need more in our case, but more elaborated mechanisms
can be used to implement this pattern. For example, Parcels [13] are much
more elaborated than BOSS for object storage.
Later, as we implemented our end-user-oriented application
framework, we reused this to save and retrieve Specializations.
By default, every Specialization is saved in a namespace having
the current user's login name. When launching the system, by default this
Specialization
is loaded into the system to customize it dynamically upon those specifications.
It's also possible to save and load specific
Specialization at any
moment. Other save/retrieve policies are also implemented.
Role of VisualWorks
VisualWorks offers nice linguistic mechanisms for Object-Oriented
programming. Declarative specifications are regularly used to compute the
program that effectively run to serve an end-user (here programmer). For
example, the system Browser is a VisualWorks application developed by means
of VisualWork's Application Framework. The "code" of this application is
computed by a meta-program (UIBuilder) which interprets Browser specification
scripts to build a running application.
So, VisualWorks is already applying the same principles but
there, end-users are programmers. To be 100% conform to our approach, VisualWork's
Application Framework must let non-programmer end-users to tailor applications
to their requirements. This is to emphasis the role of non-programmer end-user
in our approach.
Moreover, VisualWorks offers meta-class programming facilities.
Although still rarely exploited, it remains a powerful an indispensable
tool in some situations [13]. We used VisualWorks implicit meta-classes
only in some classical ways, for example to associate to each editor in
the system its Keyboard Configuration (collection of objects capable
of holding and managing user-defined shortcut keys). But we did not do
any explicit meta-class programming like [13] or [17].
Additionally, VisualWorks is an Open Source system. This
is a must for some tasks like reintegration of facilities, by means
of reflection, in order to avoid redundancy in the environment to let it
reuse mechanisms elaborated during specific projects for further developments.
Several projects have also explored the specialization of VisualWorks'
language constructions and environment, e.g. [8], [14], [15].
Use of Reflection
At some point during developement process Reflection becomes
inevitable,
to conserve system's coherence and maintainability. Otherwise there will
be parallel mechanisms complicating the maintenance of the system.
This phenomena can again be well illustrated through VisualWorks
system where MenuEditor menus are specified with MenuEditor, or UIPainter
interfaces are designed by UIPainter ! In our application framework we
obtained such reflection in the case of Preferences management framework.
The preferences of this framework were managed by itself !
This represents a real reflection case, that we call applicative
reflection, because the system 1) is obviously "in causal connection
with itself"[16] and 2) is bootstrapped.
Conclusion
An application framework was implemented for a French company
during 1992 -1998 using ObjectWorks (then ported to VisualWorks). It offers
three specialization levels : 1) programmer level; 2) expert-user level;
3) system configuration manager (and eventually end-user) level. So, every
delivered software can theoretically be in perfect (ergonomic) appropriateness
with an end user's requirements. This improved our whole software development
cycle letting us to develop rapidly more adequate and adaptable software
with less developement resources.
Some difficulties relative to the implementation of such
systems are enumerated in [5]. We can also mention some performance problems,
notably in some exaggerated cases like calculating and opening a dialog
box specified to contain all options of the system (something like 200
options). It should also be important to mention that our approach
brought us up the important question of industrial property : who was
owning what ?
Although we haven't opportunity for that, but in theory
the elaborated mechanisms can be rather easily reused for other projects.
This was not a perfect job, sure, but constitutes for us a first experience
in this field that worked.
Future work
The following subjects would constitute interesting fields
for future work :
-
Is an end-user-oriented application framework considered
to have an Active Object-Model [5] ?
-
Feedback from a framework's evolution, refactoring and specialization,
helps creating domain-specific languages. How this feedback can be obtained,
structured and analyzed ? Any tools ?
-
Studying reflective meta-framework construction process,
and its potential to let generating, by graphical tools, specific technologies.
-
More systematic research on emergence of domain-specific
languages out of evolving frameworks, to capture more precisely this phenomena.
How scripting languages and frameworks are related ?
-
More systematic research on reintegration of elaborated facilities
for a project in the base development environment (e.g. VisualWorks) [4]
and comparing it with the alternative of creating a meta-tool like Metagen
system [9].
-
Implementing tools to verify consistence and integrity of
user configurations and also to avoid creating "legacy" configurations
: configurations which can not be maintained (just like the programs) as
the application framework evolves.
-
End-User-Oriented Application Framework construction Pattern
mining.
-
Meta-programs Pattern mining.
-
Using Artificial Intelligence techniques and tools (e.g.
Agents) to generate Configurations automatically.
-
Studying the impact of our development choices in a whole
development cycle : when and how existing techniques and tools can be used
or not and why.
-
Mixing meta-modeling in analysis phase with emergence of
domain specific languages from evolving frameworks for constructing application
frameworks.
-
Studying more precisely the role of VisaulWorks facilities
in developing the application frameworks of sorts. Could we adopt a systematic
use of such an environment to create domain-specific development systems
? What language and system constructions should be enhanced ? Why not Java
based development systems ?
-
Applying feedback from our experiences in implementation
of Metagen system [9].
Moreover, we have the intuition that a framework can evolve,
in a reflective manner, toward integration of its design patterns.The rational
is : if we were capable of constructing one "manually", weren’t we capable
of constructing a production line for it ? This would serve as guideline
for creating graphical tools for generating specific technologies, in the
same manner as we did it for domain-specific languages. For example, such
an integration in case of HotDraw
would produce a HotDraw like framework generator.
Acknowledgments
This project was accomplished during a five year collaboration
(1993-98) with a French company, and was inspired a lot from the Smalltalk
culture in general (through ObjectWorks and VisualWorks
products), researches on meta-modeling by Métafor
group at Laboratoire d'Informatique de Paris
6 (LIP6) and my
work with Philippe KRIEF [2]
as project advisor during my Master Degree thesis in 1992-93 while he,
as a senior system architect, was also designing and implementing a preliminary
version of this software. The architecture that he devised could later
be easily understood and enhanced.
This position paper owes a great deal to Philippe
KRIEF that accompanied my first steps in Object-Oriented programming
with Smalltalk. I would like also to thank a lot all members of Métafor
group, and specially Gil Blain,
and Mikal Ziane for their insightful
comments and valuable discussions on meta-modeling and research methodology.
I'm particularly grateful to Jean-Pierre
Briot for his comments that helped me to enhance greatly this paper.
Bibliographie
[1] Adele Goldberg. What Should We Teach? OOPSLA '96
keynote speech. http://learningworks.neometron.com/overview/oopsla/default.htm
[2] Philippe KRIEF. Prototyping with Objects.
Prentice Hall, 1996.
[3] Don Roberts, Ralph Johnson. Evolving Frameworks,
A Pattern Language for Developing Object-Oriented Frameworks. http://st-www.cs.uiuc.edu/users/droberts/evolve.html.
[4] Bill Opdyke. Refactoring Object-Oriented Frameworks.
Ph.D. thesis. Department of Computer
Science at the University of Illinois
at Urbana-Champaign.1992.
[5] Brian Foote, Joseph Yoder. Metadata and Active
Object-Models. PLOP'98 conference, Monticello, Illinois. 1998.
[6] Brian Foot. Dmaine Specific Frameworks Emerge
as a System Evolves. Workshop on the Methologies and Object-Oriented
Programming. OOPSLA ’88, San Diego, CA.
[7] Nicolas Revault. Describing and (Re-)Using Technological
Application Frameworks in a Metamodeling-based Development Tool – an Application
of the METAGEN System. OOPSLA ’95 Workshop on Framework Centered Development.
Austin. A995.
[8] Adele Goldberg Steven T. Abell, David Leibs. The
LearningWorks Development and Delivery Frameworks. Communications of
the ACM, Fall, 1997. http://learningworks.neometron.com/overview/cacmThem/default.htm.
[9] N. Revault, , H.A. Sahraoui, G. Blain, J.-F. Perrot.
A
Metamodeling Technique : The METAGEN system. Proc. TOOLS 16 (127-139).
Versailles, March1995.
[10] Ali Arsanjani. GOOD: Meta-modeling and Grammar-Oriented
Object Design. OOPSLA ’98.
[11] F. Pachet. On the Embeddability of productions
systems in object-oriented languages. Journal of Object-Oriented Programming.
4,8 (1995), 19-24.
[12] Metamodeling in OO. OOPSLA '95 Workshop.
October 15 1995. AGENDA.
[13] Eliot Miranda. Meta-programming in a Flexible
Component Architecture. OOPSLA ’98.
[14]Pierre Cointe. The ClassTalk System: a Laboratory
to study reflection in Smalltalk. EcoopOopsla Workshop on Reflection
and MetaLevel architecture. 1990.
[15] Ralph Johnson and Jeff Oakes. The User-Defined Product
Framework. OOPSLA ’98.
[16] Pattie Maes. Concepts and experiments in computational
reflection. OOPSLA'87 Proceedings, October 4-8, 1987.
[17] Noury BouraqadiSaadani, Thomas Ledoux, Fred
Rivard & Pierre Cointe.Providing Explicit Metaclasses In Smalltalk.
OOPSLA'96
Workshop : Extending the Smalltalk Language.
Last updated October 7, 1999.