Integrating Interpretative and Generative MDA.pdf by censhunay

VIEWS: 0 PAGES: 5

									         Integrating Interpretative and Generative MDA

               Theo Dirk Meijler                                Andreas Prinz

           University of Groningen                       Agder University College
   Faculty Of Management and Organization            Faculty of Engineering and Science
          Groningen, The Netherlands                         Grimstad, Norway
         t.d.meijler@rug.nl                            andreas.prinz@HIA.no



        Abstract. Model driven development has become an essential development
        approach. Currently, two forms of model driven development exist: Generative
        and Interpretative. This paper describes how in one system, both forms can be
        combined.




    1      Introduction

The advances of software engineering have been an increase in the level of
abstraction. This is also true for the recent time, where the current state of the art is
defined by using high-level notations to describe the system to be developed instead
of programming it directly. This is usually called modelling and is connected to the
success of the UML modelling language [1] as well as the Model-Driven Architecture
(MDA) approach [2]. SDL [3] is using a similar model based design approach.
   To turn models into executing software, two approaches are well-known: Models
can be interpreted (see [6]), or from models code can be generated that is further
compiled and then ran [2]. Both approaches have their advantages and disadvantages.
A generative approach allows to map the model to an ideal low(er)- abstraction level
executable representation, such as Java code, SQL or some XML language, as
dependent on the needs. Moreover, in a generative approach one same model can be
mapped to different low-level executable representations, thus allowing for good
portability. On the other hand, interpretative approaches allow for quick ad-hoc
adaptations, allowing to iteratively, even online, finding an optimal executable
solution.
   In this paper we shall introduce an approach that allows combining both
approaches in order to get the best of both worlds:
− Enabling ad-hoc (interpretation based) variations on top of generated (binary)
   components.
− Enabling building large systems where both forms can be combined “as needed”,
   e.g. a combination of generated classes, and interpreted process models.
   The idea presented here is that models are treated as first-class citizens –thus
represented as objects–, similar as this is done in pure interpreted approaches, but that
at instantiation time, the model can still decide whether it will be interpreted or
whether a generated class will be used.
2        Andreas Prinz


This paper is subdivided as follows: In section 2 an example of the problem is given,
in section 3 the solution is described in the context of the example. In section 4 related
work is discussed. In section 5 we conclude.


         2             Example and Problem description

                                                                             I. Models of Implementation classes
                                               +supertype        1
                                                                               (Type object pattern & Customer)

                                +subtype              EntityType                 1                         *              Entity
                                           2      +Name : String
                                                  +ImplClass : String
                                           *               1                     +type             +instance
                           +referred type
                                                                                                                      1
                                                        1    1
         *        +properties          *          +associations          *           +operations                      *            +properties
                                                                                                                                                           Customer
       PropertyType               AssociationType                    OperationType                                    Property                        +Name : String
      +Name : String             +Name : String                      +Name : String                             +Value : String                       +Address : String
      -type : Type         1


                                                                                                                                        A              B



                                                II. Type Objects representing User Models

                                                                                         entity_type : EntityType
                                                                                        Name : String = Entity
                                                                                        ImplClass : String = Entity


                                                                                                         supertype



                                                                             A                  B


                                bicycle_type : EntityType                                                             customer_type : EntityType
                    type        Name : String = Bicycle                                                             Name : String = Customer
                                ImplClass : String = Entity                                                                                                  type
                                                                                                                    ImplClass : String = Customer




      brand_propdef : PropertyType               color_propdef : PropertyType
      Name : String = Brand                     Name : String = Color
      type : Type = String                      type : Type = String                         name_propdef : PropertyType                 address_propdef : PropertyType
                                                                                             Name : String = Name                        Name : String = Address
                                                                                             type : Type = String                        type : Type = String




    instance
                    gazelle123 : Entity                                                                                                                    instance
                                                                                                                      customerxyz : Customer
                                                                                                                Name : String = Xyz
                                                                                                                Address : String = Groningen
                                 End1
                                                                  End2


                   brand : Property                  color : Property
               Value : String = Gazelle            Value : String = Red



Fig. 1 Example, See text
                                   Integrating Interpretative and Generative MDA     3


Various authors [4],[5],[6] have demonstrated the need for adaptive applications, in
which new concepts can be introduced without programming. These authors have
shown that such a feature can be realized using the so-called “type object pattern” [4]
–such approaches are also known under the term adaptive object models [5]– in which
concepts are explicitly represented as objects, so-called “type objects”. Riehle et.al.
[6] have demonstrated the direct relation of such approaches with interpreted MDA:
Interpreted MDA can be realized by representing models as type objects, and these
type objects are interpreted at run-time to determine the behavior of instances.
   Figure 1 illustrates this principle: Part I(A) of the figure represent a UML
definition for the type object pattern, it both defines type objects (“Entity type” +
“Property type”) as well as of the instances of these type objects (“Entity” and
“Property”). An entity object has an association to a type object. It contains a set of
named property objects containing values, as corresponding to the set of property type
objects of the corresponding type object. We shall call an “Entity” object a “soft
typed” object, as the type is determined at run-time.
   Figure 1 represents the example of a typical application domain, inventory
management. In this domain the set of concepts –representing the kind of things for
which inventory is maintained– is not defined beforehand, and can be adapted as
needed. In part II(A) a new product type “Bicycle Type” is represented as a type
object with two property types (for the properties Brand and Color) together with a
possible instance, a specific bicycle “Gazelle123” that has corresponding property
objects, containing the values.
   Now suppose that in such an application not only inventory objects play a role, but
also customers, e.g., to indicate that a certain customer has ordered a certain product
from the inventory. Given that model driven development is applied, there are now
(seemingly) two options: Either customer types are represented as type objects such
that customers are also soft typed objects, or the modeling and implementation of
customer objects is done in a separate modeling tool.
   In contrast, as an example of the integration between generated and interpreted
MDA, we require that:
1. All relevant models, of both customers and products are modeled in one modeling
   environment. Both kinds of models are (therefore) modeled and represented in
   terms of type objects(!).
2. Customers are implemented using “normal” class generation, that is, not as soft
   typed instances.
   Remember that this combination is supposed to offer the best of both worlds: The
generated implementation of “Customer” enables storage and look-up efficiency,
while the interpreted implementation of products enables ad-hoc adaptation.
Combining the modeling of both in one modeling world enables, for example, that ad-
hoc special kinds of customers can be modeled that can only order certain kinds of
products. Due to space restrictions this will not be further examined as part of the
example. In general, new soft typed objects can be created by extending hard-typed
definitions.
4   Andreas Prinz


    3     Solution approach

Figure 1 parts I(B) and II(B) illustrates the solution approach.
   As already indicated in section 2, the key to integrating generative and
interpretative MDA is to use one common representation, representing all models as
type objects, whether this is really needed (as in the case of interpreted types) or not
(as in the case of generative MDA). In figure 1 part II(B), the Customer model is
represented and stored as the “Customer type” object. Code generation is applied to it,
delivering the “Customer” class presented in figure 1 part I(B).
   In this approach a type object not only carries modeling information, but also a link
to the class that is the “hard type” of its instances. Thus, in case of “Entity type” the
link is to the “Entity” class implementation of entity objects. In the case of the
“Customer type” the link is to the “Customer” class implementation of customer
objects.
   It is especially this “implementation class” link that does the trick: It enables to use
one common instantiation mechanism for type objects, whether used interpretatively,
or used through the generated class. When a type object is requested to instantiate
itself, it creates an instance of the corresponding implementation class (e.g. either the
“Entity” or the “Customer” class). The implementation class determines whether the
information in the type object is used interpretatively, or not.
   As shown in the figure, the generated Customer class will still be a subclass of
Entity class. This means that subtypes of “Customer type” can still apply ad-hoc
modeling techniques, e.g., to introduce ad-hoc modeled customers that can only use
certain products.


    4     Related Work

Similar problems have been encountered and solved in other areas of computer
science:
   In CORBA [7] IDL definitions can either be used to do a “hard link” between a
remote call and an implementation, but it is also possible to dynamically link calls to
implementations. Thus hard and soft linking are integrated.
   In Service Oriented Architectures [8] there is similarly the possibility to either
discover a service applying reflective mechanisms or to use an existing link with a
webservice.
   .NET [9] uses one common virtual machine for the execution of different
programming languages. The question could therefore be posed, whether model
interpretation or .java execution can be mapped to one such a virtual machine. This
kind of question is subject to further work.
                                    Integrating Interpretative and Generative MDA        5


    5     Conclusion

    This paper briefly demonstrates both the need to integrate generative and
interpretative MDA, as well as what this might mean: Using one common “type
object” based [4] model representation, that can either be interpreted or used to
generate code. It also describes a solution approach: Using the common type object
representation and a common instantiation mechanism either a class is instantiated
that does the interpretation, or a class is instantiated that has been generated.
    A more advanced approach could be to use one common virtual machine for both
interpreted models as well as for a generated class, similar to the .NET approach. This
is subject to further research.


    6     References

    [1]      Object Managment Group (OMG) Editor. OMG Unified Modelling Language
             Specification, Version 2.0. OMG Document. OMG, http://www.omg.org, 2003.
    [2]      MDA Guide, available as omg/03-06-01: MDA Guide V1.0.1 Eds: Jishnu
             Mukerji, Joaquin Miller, www.omg.org 2001
    [3]      ITU-T: ITU-T Recommendation Z.100: Specification and Description Language
             (SDL). International Telecommunication Union (2002).
    [4]      R. Johnson, B. Wolf. “Type Object”. Pattern Languages of Program Design 3.
             Addisson Wesley, 1998. (See also: http://www.ksc.com/article3.htm )
    [5]      J. W. Yoder, R. Johnson, The Adaptive Object-Model Architectural Style in:
             Proceedings WICSA 2002
    [6]      D. Riehle, S. Fraleigh, D. Bucka-Lassen, and N. Omorgbe, The architecture of a
             UML virtual machine. In Proceedings of OOPSLA’01. ACM Press, New York,
             327–341. 2001.
    [7]      OMG: CORBA Component Model, Version 3.0. Object Management Group
             (2002). formal/2002-06-65.
    [8]      T. Erl. A Field Guide to Integrating XML and Web Services, Pearson Education,
             Publishing as Prentice Hall Technical Reference, ISBN 0-13-142898-5 2004
    [9]      H. Mössenböck, W. Beer, D. Birngruber, A. Wöss, .NET Application
             Development with C#, ADO.NET, ASP.NET and Web Services

								
To top