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  :


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  :

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 : 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 Bouraqadi­Saadani, Thomas Ledoux, Fred Rivard & Pierre Cointe.Providing Explicit Metaclasses In Smalltalk. OOPSLA'96 Workshop : Extending the Smalltalk Language.


Last updated October 7, 1999.