Abstract:
Computer method and apparatus implements redefinition of features in a programming model. The invention method includes (i) providing a model element having a feature with a redefinition such that the feature is a redefined feature; (ii) storing indications of the redefinition; and (iii) interpreting the stored indications and generating therefrom a model that implements the redefined feature. Redefined features include redefined property names, redefined property type and redefined multiplicity of a property.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     With the proliferation of software products and services, attempts have been made to codify and/or standardize the designing of software and software architecture. Examples include:  
         [0002]     The Booch Method and Modeling Language (see “Object Oriented Analysis and Design” by Grady Booch);  
         [0003]     James Rumbaugh and associates&#39; Object Modeling Technique (OMT);  
         [0004]     the Object Oriented Software Engineering (OOSE) method by Ivar Jacobson; and  
         [0005]     the Unified Modeling Language (UML) which combines the foregoing and industry best practices.  
         [0006]     The UML is a visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. Thus the modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth. In general, at the modeling level a “problem” is posed in terms of a customer&#39;s needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O&#39;Reilly &amp; Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.  
         [0007]     In UML 2.0, properties and operations can be redefined (in the context of generalization) with, for example, a different type and/or multiplicity that is consistent with the original. The redefined property commonly has the same name as the property it is redefining, but this is not always the case. Redefinition is indicated using a redefines constraint, which is typically left out if the name remains the same.  
         [0008]     The Rose model for UML 2.0 contains many properties whose names, types, and/or multiplicities have been redefined. There are, however, no known mechanisms for generating Java code that enforces these constraints. The Eclipse Modeling Framework (EMF) can be used to generate Java code from a Rose model, but provides no automated support for processing redefinitions.  
         [0009]     One aspect of EMF (and of the Java language) that affects the treatment of redefined properties is the way multiple inheritance is handled. When processing a class that is defined to have more than one superclass, EMF will generate an interface that extends all of the interfaces corresponding to the specified superclasses, but the implementation class will extend only one of the implementation classes (since multiple inheritance is illegal in Java). The class that is extended by the implementation class is referred to as the class&#39;s primary superclass; all other superclasses are referred to as secondary, or mixin, superclasses.  
         [0010]     Properties whose names are redefined do not pose a problem as far as EMF is concerned since it considers the redefined and redefining properties as separate properties. However, this means that the generated code will not indicate in any way that the redefining property in fact overrides the redefined property. It would be desirable for the generated code to in some way reflect the redefinition, and for the data in these properties to be serialized only once.  
         [0011]     All other redefined aspects of properties pose problems to EMF. This is because properties with the same name are considered duplicates by EMF, and are factored out of the Ecore model (i.e., of the UML2 metamodel) during validation.  
       SUMMARY OF THE INVENTION  
       [0012]     The present invention addresses the foregoing problems of the prior art.  
         [0013]     In one embodiment, the present invention provides a computer method and apparatus for implementing (modeling) redefines/constraints. A model element is provided and has a “redefined feature”, i.e., a feature with a redefinition. The invention stores indications of the redefinition in a manner that makes a correspondence between the stored information and the model element. An interpreter interprets the stored indications/information and generates an implementation of the redefined feature. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]     The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred 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 the principles of the invention.  
         [0015]      FIG. 1  is a schematic view of the “general” property of the Class class being redefined by the “superClass” property (i.e., a list property redefined by another list property).  
         [0016]      FIG. 2  is a schematic view of a non-list property (“owner”) being redefined by another non-list property (“container”).  
         [0017]      FIG. 3  is a schematic illustration of a list property (“redefinedElement”) being redefined by a non-list property (“extendedStateMachine”).  
         [0018]      FIG. 4  is a schematic illustration of a non-list property (“value”) being redefined by a list property (“duration”).  
         [0019]      FIG. 5  is a block diagram of the redefining of an “ownEnd” property.  
         [0020]      FIG. 6  is a schematic view of a computer environment in which the principles of the present invention may be implemented.  
         [0021]      FIG. 7  is a block diagram of the internal structure of a computer from the  FIG. 6  computer environment.  
         [0022]      FIG. 8  is a schematic illustration of computer systems implementing methods of the present invention.  
         [0023]      FIG. 9  is a block diagram of a preferred embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0024]     There are two scenarios in which a property is considered a duplicate by EMF. The first scenario is where a class defines a property with the same name as a property already inherited from one of its superclass hierarchies. In this case, the Ecore “builder” (building the Ecore model or meta data of the user model) simply removes the attribute from the class. As a result, the generated interface and implementation class will contain neither a field nor accessors to represent the redefinition. It would be desirable for at least the getters and setters to be generated for these properties so that there is some indication in the generated code that these properties have been redefined.  
         [0025]     The second scenario is where a class inherits two or more properties with the same name. In this case, EMF will discard the generalization relationships to the mixin classes whose hierarchies contain the second and subsequent properties. As a result, the generated interface and implementation class will neither extend nor implement the offending mixin class(es), and consequently will contain neither a field nor accessors to represent the redefinition. It would be desirable for the generalization relationship(s) to be retained for at least the getters and setters to be generated for these properties so that there is some indication in the generated code that these properties have been redefined.  
         [0026]     Assume for a moment that EMF did not factor out duplicate properties as described above.  
         [0027]     Properties whose types have been redefined would pose a number of problems, both from a Java and an EMF perspective. In EMF is not possible for a class to change the type of a feature that it inherits, and defining a new feature with the same name would lead to a whole host of problems. From a Java perspective, it is illegal for a field or method to be defined twice in the same hierarchy with a different type, so the resulting getters and setters would not compile anyway.  
         [0028]     Properties whose multiplicities have been redefined would also pose a number of problems. Since EMF generates different code depending on a feature&#39;s multiplicity, two features with the same name but different multiplicities (e.g. 0 . . . * and 0 . . . 1) would result in incompatible code. As with type redefinition, the getters and setters for these features could have different types, and also would not compile.  
         [0029]     The present invention overcomes the above limitations and provides a mechanism for generating Java code (in the preferred embodiment) or similar code that enforces redefines constraints in program modeling. In general, the present invention apparatus and method assists with building (designing) a model representation of a desired software product. Thus the present invention tool assists with forming the meta data design of the subject software product. The meta data design includes meta data classes, and instances thereof. Classes are defined with attributes, one of which is termed a “property”. Properties are indicated in the model representation with a name and have a respective value (either defined in the model or derived at run time, for example). Properties also have a type and a multiplicity (number of program objects it relates or applies to). There are constraints on properties based on, for example, respective allowable range of values, unions of sets of values and the like. The redefines constraint of a given property provides a substitute name, type and/or multiplicity (among other characteristics) for the initial indicated property name, type and/or multiplicity. The redefines constraint effectively redirects or changes model processing to use the substitute name, type or multiplicity, etc.  
         [0030]      FIG. 9  is illustrative. Shown is an example property “sfeature”  67  of a model element  77 . The example property  67  has a redefines constraint (indicated between curly brackets). That is, the “sfeature” property (redefining) effectively substitutes or redefines the “ifeature” property  71  (initial one being redefined). For ease of discussion, the example redefines property constraint is generally referenced  67 . The present invention records an indication of the redefines constraint  67  in annotations  69  corresponding to the model element  77 . The annotations  69  may be stored in a list or other appropriate data structure. During model processing, the model interpreter  63  obtains the substituting definition (name, type and/or multiplicity) of “sfeature” in this example. Then in the body of the model program code  65 , the model interpreter  63  reads the property being redefined (“ifeature”  71 ) and delegates processing to the substituting property (“sfeature”  67 ). The model interpreter  63  effectively overrides the model program code instructions to get the initially stated property (“ifeature”  71 ) and as a consequence returns program code that gets the substituting property (“sfeature”  67 ).  
         [0031]     In a preferred embodiment, the subject user model  61  is a Rose model that represents the code generation (model) of interest, i.e., the software product model being designed. The present invention records (in the form of annotations  69  in respective parts of the Rose model  61 ) constraint information for each redefined property  67 ,  71 . Next the preferred embodiment employs EMF to generate Java templates (or like code) from the annotated Rose model  61 ,  69 . The generated Java template or the like carries out “get” instruction statements mentioned above and further discussed below. The resulting EMF  63  output is an API  65  (e.g., in an object oriented programming language) that correctly implements the Redefines constraint  67 . Further specific examples are discussed below in  FIGS. 1 through 5 .  
         [0032]     As described above, Java templates can be used to generate code for redefined features (properties  71 ) such that they delegate to their redefining features (properties)  67 . There are several scenarios to consider with respect to redefined properties.  
         [0033]     First, consider the case where a list property is redefined by another list property. For example, the “general” property  15  of the Class class  11  is redefined by its “superClass” property  13 , as shown in  FIG. 1 .  
         [0034]     Java or similar templates employed by the preferred embodiment generate target code for the getGeneral( ) operation on the ClassImpl class (created to override the implementation inherited from its parent) that resembles the following:  
         [0035]     return getSuperClass( );  
         [0036]     Next, consider the case where a non-list property is redefined by another non-list property. For example, the “owner” property  23  of the Vertex class  21  is redefined by its “container” property  25 , as shown in the class diagram of  FIG. 2 .  
         [0037]     The Java or similar templates employed by the preferred embodiment generate target code for the getowner( ) operation on the VertexImpl class (created to override the implementation inherited from its parent) that resembles the following:  
         [0038]     return (Element) getcontainer( );  
         [0039]     Continuing with  FIG. 2 , the Region object  19  is an instance of the Vertex class  21  and inherits the “container” property  25  and the “subvertex” property  27  of class  21 . Thus Region object  19  inherits the Redefines constraint of owner property  23  and container  25 .  
         [0040]     Next, consider the case where a list property is redefined by a non-list property. For example, the “redefinedElement” property  37  of the StateMachine class  31  is redefined by its “extendedStateMachine” property  35 , as shown in the class diagram of  FIG. 3 .  
         [0041]     The Java templates or similar model processing employed by the present invention generate code for the getRedefinedElement( ) operation on the StateMachineImpl class (created to override the implementation inherited from its parent) that resembles the following:  
         [0042]     return new BasicEList.UnmodifiableEList (0, Collections.EMPTY_LIST.toArray( ));  
         [0043]     Finally, consider the case where a non-list property is redefined by a list property. For example, the “value” property  41  of the DurationObservationAction class  45  is redefined by its “duration” property  43 , as shown in the class diagram of  FIG. 4 .  
         [0044]     The Java template in a preferred embodiment generates code for the getvalue( ) operation on the DurationObservationActionImpl class (created to override the implementation inherited from its parent) that resembles the following:  
         [0045]     return null;  
         [0046]     Target code is generated for the setValue( ) operation on the DurationObservationActionImpl class (created to override the implementation inherited from its parent) that resembles the following:  
         [0047]     throw new UnsupportedOperationException( );  
         [0048]     Next, target code for the redefining (substituting) features  67 , described above, is implemented as follows. For example, the “ownedEnd” property  51  of the Extension class  53  redefines its ownedEnd property  55 , inherited from the Association class  57 , as shown in the class diagram of  FIG. 5 .  
         [0049]     Target code in one embodiment is implemented for the getOwnedEnd( operation on the ExtensionImpl class (created to override the implementation inherited from its parent) that resembles the following:  
                                                                                                     if (ownedEnd == null) {                ownedEnd =                new EObjectContainmentWithInverseSubsetEList(                ExtensionEnd.class,           this,           Uml2Package.EXTENSION_OWNED_END,           new EObjectEList[] {(EObjectEList)           getMemberEnd( )},                Uml2Package.EXTENSION_END_OWNING_ASSOCIATION);                }           return ownedEnd;                      
 
         [0050]     Notice that the result achieved by the above redefinition is that the contents of the ownedEnd list feature  51  are further constrained to be of type ExtensionEnd  59 .  
         [0051]     Referring back to  FIG. 9 , when dealing with properties whose names have been redefined, the preferred embodiment records information about redefined properties  67 ,  71  as annotations  69  on the code generation model  61  that it builds as described above. At the model interpreter level  63 , operations are created on the class that redefines the feature to override the accessors for the redefined feature  71  such that they delegate to the accessors for the redefining feature  69 . This way, the values of these properties will not be stored in two places. Java templates are used to automatically generate code for these operations based on the annotations  69 . The generated comments for the methods associated with these operations may (in some embodiments) indicate by which properties the properties represented by the operations have been redefined.  
         [0052]     To deal with scenarios where a class defines a property with the same name as a property already inherited from one of its superclass hierarchies, the present invention model interpreter  63  converts the duplicate (in name) property into operations that represent the getters and setters that would have been generated if the properties were volatile. This results in an API  65  that is similar to that if the duplicate properties were not discarded.  
         [0053]     To deal with scenarios where a class inherits two or more properties with the same name, the present invention model interpreter  63  renames the duplicate properties inherited from mixin classes so that they are not considered duplicates. The new name is unique, for example a concatenation of the class and original feature names. Operations are created in the mixin classes whose properties have been renamed so as to represent the accessors that would have been generated if the properties were not renamed. This way, the generalization relationships are preserved, and corresponding features are not discarded. Java templates automatically generate code for these operations based on annotations  69 .  
         [0054]     To deal with properties whose types have been redefined, the present invention model interpreter  63  changes the types of the two properties (if necessary) so that they are compatible. That is, the type for the two properties is set to the nearest common supertype of the two original types. One unfortunate side effect of this is that downcasting will be required to cast the types of the generated accessors to their original (intended) type.  
         [0055]     To deal with properties whose multiplicities have been redefined, the present invention model interpreter  63  changes the multiplicities of the two properties (if necessary) so that they are compatible (unless the redefining feature is a container reference and the upper bound of the redefined feature is not 1). That is, the lower bound for the two properties is set to the lower of the two original lower bounds and the upper bound is set to the higher of the two original upper bounds. One unfortunate side effect of this is that the constraints will be relaxed, possibly resulting in a slightly different API  65  for the generated accessors. If the redefining property  67  is a container reference and the upper bound of the redefined feature  71  is not 1, it will instead be renamed with a unique name and treated as if it were a property with a name redefinition.  
         [0056]      FIG. 6  illustrates an example computer environment in which the present invention operates. 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 computer(s)  50  and server computer(s)  60 . Communications network  70  can be part of the Internet, a worldwide collection of computers, networks, and gateways that currently use the TCP/IP suite of protocols to communicate with one another. The Internet provides a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer networks, that route data and messages. In another embodiment of the present invention, the methods are implemented on a stand-alone computer. In either network or standalone, the invention output software design and models (API&#39;s  65 ) are sharable and reusable among users.  
         [0057]      FIG. 7  is a diagram of the internal structure of a computer (e.g., client computer(s)  50  or server computers  60 ) in the computer system of  FIG. 6 . Each computer contains system bus  79 , where a bus is a set of hardware lines used for data transfer among the components of a computer. 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., displays, printers, speakers, etc.) to the computer. Network interface  86  allows the computer to connect to various other devices attached to a network (e.g., network  70  of  FIG. 6 ). Memory  90  provides volatile storage for computer software instructions used to implement an embodiment of the present invention (e.g., EMF code  63  and Rose models  61  of subject Program Routines  92  and Data  94 ). Disk storage  95  provides non-volatile storage for computer software instructions and data 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.  
         [0058]     Referring now to  FIG. 8  illustrated is another computer system  10  embodying the present invention techniques mentioned above. Generally, computer system  10  includes digital processor  12  in which subject modeling language and EMF code  20  are utilized. Input means  14  provides user commands, selections (generally communication) to computer system  10 .  
         [0059]     Responsive to input means  14  is user interface  22 . User interface  22  receives user input data from input means  14  and provides input data for processing and manipulation at  20 . The methods of the invention are implemented at  20  for designing Application Program Interfaces that enforce Redefines constraints in Java, UML, EMF and the like which are output at  16 . Output  16  may be a display monitor, printer or other computer.  
         [0060]     In one embodiment, computer program product  80 , 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.) provides at least a portion of the software instructions at  20  and/or user interface  22 . Computer program product  80  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 wireless connection. Computer program propagated signal product  83  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)) provides at least a portion of the software instructions at  20  and/or user interface  22 .  
         [0061]     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  80  is a propagation medium that the computer system  10  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  83 .  
         [0062]     Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals/medium, storage medium and the like.  
         [0063]     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.  
         [0064]     For example, the above recited example code is for purposes of illustration and not limitation. The model interpreter  63  may be implemented in UML, EMF and other modeling languages. The generated target/produced API code  65  may be Java, UML, EMF, XML, object oriented, and the like.