Abstract:
Computer method, apparatus and system chains model-to-model transformations. In a series of model transformations, there are respective bridges before and after each model transformation. For each pair of consecutive model transformations in the series, the respective bridge (i) receives a model output from a first model transformation of the pair, the received model being in the respective output model format of the first model transformation of the pair, (ii) prepares the received model as input to a second model transformation of the pair, including preparing the received model to be in the respective input model format of the second model transformation of the pair, and (iii) inputs the prepared model to the second model transformation of the pair. The series of model transformations and respective bridges provide chaining of the model-to-model transformations. Each model transformation in the series is able to be separately configured.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    Model-driven architecture (MDA) is an approach to software development advocated by the Object Management Group (OMG). It provides a set of guidelines for structuring specifications in the form of models. The approach suggests describing a system&#39;s specifications using a platform independent model (PIM). A PIM is usually specified in a language defined using the Meta Object Facility (MOF) by OMG. Once a system has been specified using a PIM, a platform is then chosen to realize it, producing what is referred to as a platform specific model (PSM). The process of going from a PIM to a PSM is called model-to-model transformation and can usually be automated. In fact, several model-to-model transformations may be needed to take the initial PIM through intermediate models to the ultimate PSM. This effectively creates a transformation chain. 
         [0002]    The traditional way to implement transformation chains is by making every transformation implementation aware of the next transformation in the chain so it can properly pass its output as an input to the next transformation. However, tying the two transformations together reduce the possibility of reusing each transformation individually and the possibility of configuring each of them in different chains. 
         [0003]    Another problem here is that transformations may be designed in some ways that complicate chaining. For example, some transformations might not clearly separate their inputs from their outputs (like those changing the input models directly). Others may have built-in post-processing (like serializes their results), which is typically done only if the transformation is a terminal one. 
         [0004]    What is needed is a flexible pattern for chaining transformations, guidelines for structuring transformations to make them chainable and a framework for configuring such transformation chains. 
       SUMMARY OF THE INVENTION 
       [0005]    The present invention addresses the forgoing short comings of the prior art. In particular, the present invention proposes a solution to chain model-to-model transformations that eliminates the need for inter-transformation dependencies and facilitates reuse. The invention solution in a nutshell is to implement bridges between transformations. A bridge is a chaining link that performs a small common task and has a precise interface in terms of its inputs and outputs. The main transformations are then structured to conform to that interface, i.e. accept the outputs of one bridge as their input, and produces the inputs expected by another bridge as their output. 
         [0006]    The present invention also proposes a framework for configuring transformation chains as a sequence of transformations and bridges, each with its own configuration. In one embodiment, the invention applies the proposed design to Ecore-based model-to-model transformations. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
           [0008]      FIG. 1  is a block diagram of a typical monolithic model-to-model transformation; 
           [0009]      FIG. 2  is a schematic illustration of typical chaining of model-to-model transformations using post-processing phases; 
           [0010]      FIG. 3  is a block diagram of a model-to-model transformation chain of the present invention; 
           [0011]      FIG. 4  is a schematic illustration of passing configurations through a typical monolithic transformation. 
           [0012]      FIG. 5  is a schematic illustration of configurations in a transformation chain of the present invention; 
           [0013]      FIG. 6  is a block diagram of an example embodiment of the present invention; 
           [0014]      FIG. 7  is a schematic view of a computer network environment in which embodiments of the present invention are implemented; 
           [0015]      FIG. 8  is a block diagram of a computer node in the computer network of  FIG. 7 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0016]    A description of example embodiments of the invention follows. 
         [0017]    A typical monolithic transformation  112  takes the input models  111 , pre-processes  113  them, applies the transformation logic  115 , and then post-processes  117 . The result produces the output models  119 .  FIG. 1  shows such a typical monolithic transformation approach  112 . Note that the shaded parts (namely pre-preprocessing  113  and post-processing  117 ) should not strictly be part of the transformation  112  but rather part of the reusable or global chain processing steps. For example, the pre-processing phase  113  of input models  111  usually involves loading them from their storage into memory, which usually needs to be done only by the first transformation in a chain. The same argument applies for the post-processing phase  117 , which typically runs after the last transformation in the chain and involves saving the in-memory output models  119  into storage, merging them into other models or invoking other (model-to-model or model-to-text) transformations  114 ,  116 ,  118  with them.  FIG. 2  shows a typical chaining of model-to-model transformations  114 ,  116 ,  118  in post-processing phase  117 . 
         [0018]    In  FIG. 2 , the output models of the last transformation in a chain serve as input models  120  to the post-processing phase  117 . In the post-processing phase,  117 , a first model-to-model transformation  114  in a chain of transformations is applied to the input models  120 . The resulting models output from first transformation  114  are received as input for next in succession transformation  116 , and so on. The last in the chain/series of transformations (e.g., transformation  118 ) produces final output models  119 . 
         [0019]    The present invention system  10  suggests separating those pre- and post-processing phases  113 ,  117  from a monolithic transformation  112  and repackaging them as bridges  12   a, b, . . . n  ( FIG. 3 ). in a transformation chain. A bridge  12  is a unit in a transformation chain that accepts the output of a previous transformation  14   a  and prepares it as an input to a following transformation  14   b . . . n . In a model-to-model transformation chain, the inputs and outputs of transformations  14  are typically models. Starting with an input set of models  11 , the models get transformed as they make their way through the transformation chain (the series or sequence of bridges  12  and transformations  14 ). Specifically, the models are transformed from one format to another until they reach the output format, as shown in  FIG. 3 . The output models  18  result. 
         [0020]    Various bridges  12  can be designed including: 1) a bridge that loads persisted input models  11  into memory, 2) a bridge that persists transformation  14  output models  18  to storage, 3) a bridge that merges transformation  14  output models  18  into persisted models, 4) a bridge that validates models, 5) a bridge that provides transformation  14  output models as input models to a consequent model-to-model transformation  14  and  6 ) a bridge that provides transformation  14  output models as input models to a model-to-text transformation  14 . The model-to-model transformations  14  themselves can then be reduced to taking input models in a certain format and producing respective output models in another format (the output models can either be a different set or the same set with a different state). 
         [0021]    Some other advantages can also be realized from designing a transformation chain in this fashion. The state of earlier links in the chain can be discarded as soon as the data flow reaches a new link in the chain, potentially leading to a more efficient execution. This can be contrasted to relying on monolithic transformations  112  doing the cleanup between the various phases on their own, which is error-prone. 
         [0022]    Another advantage can be seen in configurability. A monolithic transformation  112  is provided with configuration parameters  121  for all nested transformations  114 ,  116 ,  118 , which forces it to propagate those parameters down the hierarchy, as shown in  FIG. 4 . Meanwhile, the proposed chain solution of the present invention  10  allows every link in the chain (the bridges  12  and the transformations  14 ) to be configured separately or individually (at  20   a, . . . n  in  FIG. 5 ) and to get that configuration  20  when the data flow reaches it at runtime. This facilitates designing smaller and more focused configurations  20  and allows for composing them for different chains, as shown in  FIG. 5 . 
         [0023]    The Eclipse Modeling Framework (EMF) allows for defining modeling languages using Ecore, a meta-modeling language (an implementation of the EMOF specifications by OMG). These Ecore-based modeling languages are defined in terms of their meta-models. Users then make instances of these meta-models producing user models. Various modeling languages have been designed with Ecore in addition to a set of technologies that accept Ecore-based model instances as their input or output. One notable example here is JET (Java Emitter templates; see www.eclipse.org/articles/Article-JET/jet-tutorial1.html), which is a model-to-text transformation framework. Another example is BIRT (Business Intelligence and Reporting Tools, see www.eclipse.org/birt/), which is a report design framework. A third example is the Compare &amp; Merge framework, which is available in the IBM Rational Software Architect family of products and helps in comparing and merging Ecore-based models. 
         [0024]    Often enough there is a need to transform an Ecore-based user model from one modeling language to another in a chain. Several Ecore-based transformation frameworks exist today including MTAF (Model Transformation Authoring Framework, by IBM Rational Software Architect Version 7.0) and MTF (IBM Model Transformation Framework 1.0.0: Programmer&#39;s Guide, 2004 at www.alphaworks.ibm.com/tech/mtf) both of Assignee. These frameworks can be used to implement the specific model-to-model transformation  14  pairs. However, a transformation chain may terminate by consuming the model as an input to another framework like JET (to generate code) or BIRT (to generate reports). It may alternatively terminate by saving the output model or merging it into another persisted model using the Compare &amp; Merge framework. The transformation chain solution  10  presented by the present invention is well-suited to support that kind of chaining. 
         [0025]    Turning to  FIG. 6 , Ecore-based models  30  are persisted using XMI (see “MOF 2.0 XMI Mapping Specifications v2.1,” OMG Document Format, 05-09-01) and are loaded into memory as EMF Resources. One or more such Resources belong to a Resource Set. Based on that, the input and output of model-to-model transformations  41 ,  45  can be setup as Resource Sets. The bridges  33 ,  35 ,  37  on the other hand may have their inputs, outputs or both as Resource Sets. Table 1 describes the inputs, outputs and configuration parameters for some Ecore-based model-to-model transformations  41 ,  45  and bridges  33 ,  35 ,  37 .  FIG. 6  shows an example transformation chain involving some of those chain links in a system  10  implementing the present invention. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Possible chain links for Ecore-based model-to-model transformations 
               
             
          
           
               
                 Chain Link 
                 Configuration 
                 Inputs 
                 Outputs 
               
               
                   
               
               
                 Model Load 
                   
                 Model Files 
                 Resource Set 
               
               
                 Bridge 33 
               
               
                 Model-to-Model 
                   
                 Resource Set 
                 Resource Set 
               
               
                 Bridge 35 
               
               
                 Model-to-Model 
                 Transformation-defined 
                 Resource Set 
                 Resource Set 
               
               
                 Transformations 
                 Parameters 31 
               
               
                 41, 45 
               
               
                 Model Validation 
                 Validation Rules 
                 Resource Set 
                 Resource Set 
               
               
                 Bridge 
               
               
                 Model Persistence 
                 Output File Paths 
                 Resource Set 
                 Model Files 
               
               
                 Bridge 
               
               
                 Model Mergee 
                 Model Files Paths 
                 Resource Set 
                 Model Files 
               
               
                 Bridge 
               
               
                 JET Bridge 37 
                 JET Transformation Id 
                 Resource Set 
                 Text Files 
               
               
                   
                 Output Folder Path 40 
               
               
                 BIRT Bridge 
                 BIRT Report Design 
                 Resource Set 
                 Report File 
               
               
                   
                 Path 
               
               
                   
                 Output Format/Path 
               
               
                   
               
             
          
         
       
     
         [0026]    Optional configuration parameters  31   a, b ,  40  may be added respectively to transformations  41 ,  45  and bridges  33 ,  35 ,  37  as discussed above in  FIG. 5 . In the Ecore-based transformation chain of  FIG. 6 , an example JET configuration parameter  40  is shown providing input to JET bridge  37 . The result of the example transformation chain (including bridges  33 ,  35 ,  37  transformations  41 ,  45  and corresponding parameters  31   a, b ,  40 ) is an output JAVA code  38 . 
         [0027]      FIG. 7  illustrates a computer network or similar digital processing environment in which the present invention may be implemented. 
         [0028]    Client computer(s)  50  and server computer(s)  60  provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)  50  can also be linked through communications network  70  to other computing devices, including other client devices/processes  50  and server computer(s)  60 . Communications network  70  can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable. 
         [0029]      FIG. 8  is a diagram of the internal structure of a computer (e.g., client processor  50  or server computers  60 ) in the computer system of  FIG. 7 . Each computer  50 ,  60  contains system bus  79 , where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. Bus  79  is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to system bus  79  is I/O device interface  82  for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer  50 ,  60 . Network interface  86  allows the computer to connect to various other devices attached to a network (e.g., network  70  of  FIG. 7 ). Memory  90  provides volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention (e.g., bridges  12 , transformations  14 , and configurations parameters  20  detailed above in  FIGS. 5 and 6 ). Disk storage  95  provides non-volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention. Central processor unit  84  is also attached to system bus  79  and provides for the execution of computer instructions. 
         [0030]    In one embodiment, the processor routines  92  and data  94  are a computer program product (generally referenced  92 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product  92  can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. In other embodiments, the invention programs are a computer program propagated signal product  107  embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program  92 . 
         [0031]    In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of computer program product  92  is a propagation medium that the computer system  50  may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product. 
         [0032]    Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like. 
         [0033]    While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims. 
         [0034]    For example, the present invention may be implemented in a variety of computer architectures. The computer network of  FIGS. 7 and 8  are for purposes of illustration and not limitation of the present invention. 
         [0035]    The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
         [0036]    Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
         [0037]    The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.