Reusing code in object-oriented program development6182274Abstract A method and system for reusing code extensions prepared by a user or developer are disclosed. The extensions are handled as method implementations and stored in the method body, in a persistent storage model. Thus when the source code is regenerated after a change is made to the metadata in an object, its method body attribute is retrieved intact and the user/developer does not need to re-enter the extensions into the object to be edited. Claims The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows: Description FIELD OF THE INVENTION
DMMethod
Attribute Name Description
name The name of the method
OB::TypeString The method return type. (eg. int, or
Employee).
Oneway A flag in the IDL case to indicate whether
this is a oneway or not.
DMMethod::varExceptions This is a string blob that return the list of
exceptions raised by this method.
OB::Context This is a string blob that returns the list of
contexts for this method in IDL case.
MethodBody The method implementation that the user
enters in the edit session.
ImplInterface For Java, this flag indicates whether this
method implements one of the methods in its
inherited interfaces.
The class DMArg 33 is used to model a parameter, and includes the attributes name, OB::Typestring, and directional attribute, which define respectively the name of the parameter; the parameter type, for example int; and the direction of the parameter, namely in, out or inout. The class DMArg 33 operates in ways known to the persons skilled in the art. The class DMType 34 models a type and includes the attribute part, which relate to the class DM part which will be described below; and qualifiers. Qualifiers are used in a way known to the person skilled in the art, and can include all appropriate declaration qualifiers, for example, * and const. The class DMFile 36 is used to model a list of include files for an IDL file, or a list of import statements for a Java file. The class DMFile 36 has, as its only property, the attribute name, which is the name of an include file or an import statement. The superclass DMNameScope 35 provides the scope of the class name used in the in memory data model 4 and the persistent model 5 in FIG. 1. The class DMNSGroup 37 represents a grouping construct and defines a name scope. It is an abstract concept, and its concrete implementation OBFileGroup 39 is used to model a file level construct, for example an IDL file or a Java file. The class OBFileGroup 39 can contain a collection of classes used in the in-memory data model, for example OBFile 42, OBModule 43, OBinterface 44, OBSimpleType 45, OBExcepdion 46, OBTypedef 48, OBEnum 50, OBStruct 52 or OBUnion 54. The class OBFileGroup 39 has a one-to-one relationship to OBFile 42 and a one-to-many relationship with each of OBModule 43, OBinterface 44, OBSimpleType 45, OBException 46, ObTypedef 48, OBEnum 50, OBStruct 52 and OBUnion 54. The relationships are ownership relationships, and when the OBFileGroup object is destructed, all of its contained elements will also be destructed. The class DMModel 38 represents the model instance root. A user of the model attaches to a specific mode instance using methods in the class DMModel 38. OBApplication Family 40 is a model for the objects that are saved onto a storage medium for product distribution, for example, a CD-ROM disk. These objects are then installed selectively in a target machine in a software installation step as is known in the art. DMPart 41 is a part construct and models behaviour for other model objects by way of various relationships. The behaviour model includes, for example, inheritance, data member and method. In a preferred embodiment of the invention, several classes derive from DMPart 41. The class OBFile 42 is used to model an IDL or Java file; each instantiation of OBFileGroup 39 contains one and only one OBFile 42. The attributes of the OBFile class are shown in the table below.
Attribute Name Description
name The name of the file
FileType The type of the file. The value can be either Idl or
Java.
PackageName The name of the Package for Java
Framework A flag to indicate whether this is a framework
OBFile::hasPublic A flag to indicate whether this Java file contains a
public interface.
OB::ForwardDecl A blob containing the list of forward declarations for
this scope.
The class OBModule 43 is used for modelling a module, and includes the attributes name and OB::ForwardDecl, which is a binary large object containing a list of forward declarations. The class OBinterface 44 is used to model an interface. Its attributes include name, OBlnterface::is Public and OB::ForwardDecl which is described above. The attribute OBlnterface::is Public is a flag which indicates whether the interface is a public interface or not, in the lava implementation of the invention. The class OBlnterface 44 can contain attribute declarations, method declarations and constant declarations for both Java application and interface definition language applications; for interface definition language applications it can also contain type declarations, for example Typedef, Enum, Struct and Union, as well as Exception declarations. An OBlnterface 42 scopes interface level constants, attributes, methods, typedefs, enums, structs, unions, exceptions and an interface parents. FIG. 5 illustrates, in a preferred embodiment, the relationship name for navigation from the OBInterface to the interface level objects, namely DMMethod, DMDataMember, OBException, OBEnum, OBTypedef, OBStruct, and OBUnion. The class OBSimpleType 45 is used to model any primitive data type that is not otherwise defined by the persistent data model. Examples of such primitive datatypes in interface Definition Language, include "any", or "octet", or, in Java, the primitive datatype "byte". The class OBSimpleType 45 has a property which stores the name of the primitive data type. The class OBException 46 is used to model an IDL exception definition, in ways common to the object-oriented programming art. It stores the name of the exception. The class OBTypedef 48 is used to model an IDLTypeDef definition. The class contains the following properties: name, which is the name of the TypeDef; type qualifier which is a flag indicating this TypeDef is a TypeDef of a basic type, for example short, or a bounded sequence, or an unbounded sequence or an array; and size, which indicates the number of elements found if the defined type is a bounded sequence or array. The size attribute is not necessary if the defined TypeDef is a basic type or a bounded sequence. The classes OBEnum 50, OBStruct 52 and OBUnion 54 are used to model IDL Enums Structs and Unions. The classes OBTypedef 48 OBEnum 50, OBStruct 52 and OBUnion 54 all operate through the corresponding persistent data model classes DMTypedef 47, DMEnum 49, DMStruct 51 and DMUnion 53. The classes whose names begin with "OB" in the preferred embodiment are concrete implementations of the superclasses whose names begin with "DM". The DM superclasses are not instantiated themselves. The class DMSubpart 60 is a model type. DMDataMember 61 is a concrete implementation of DMSubPart 60. DMDataMember 61 is instantiated by the object builder tool in a preferred embodiment of the invention. DMDataMember 61 is used to model constants, attributes, struct, data members, and enums, that is enumerators. In the preferred embodiment, DMDataMember 61 includes the attributes shown in the table below. In that table, Getimpi is a string that stores the get implementation for attributes that represent essential state of the object. Setimpi is a string that stores the set implementation for attributes that represent the essential state of the object.
Attribute Name Description
name The name of the corresponding item.
OB::TypeString The type of the corresponding item. (e.g. int, or
Employee).
ReadOnly Applies only to IDL attribute. Set to 1 if it is read
only. Set to 0 otherwise.
Static A flag for Java case to indicate that static modifier
GetImpl For attributes in IDL, and public attributes in Java, this
property contains the Getter implementation.
SetImpl For attributes in IDL, and public attributes in Java, tis
property contains the Setter implementation.
In the preferred embodiment of the invention described herein, each object that is created by the object builder tool in the persistent data model has a unique name. The unique name is formed by concatenadng its name with its contained path. When an IDL file or a Java file is added, an OBFileGroup object representing the group, and an OBFile object representing the file are created. For example, to add "F1.idl", the system creates an OBFileGroup object of name "::F1". The "::" is appended by the persistent data model framework. Since the OBFileObject is scoped by the OBFileGroup object, its unique name becomes "::F1::F1". If an interface is added, for example "Person" to "F1.idl" and OBinterface object will be created, and its unique name will be "::F1::F1::Person". The unique naming scheme allows the system to employ name scoping across files, modules and interfaces. For example, if "F2.ldl" also contains the "person" interface, its unique name will be "::F2::F2::Person". Thus a desired model object can always be located by searching for its unique name in the part group in which it is located. The persistent model classes described above with respect to FIG. 3 handle the storage of the objects that make up the programming system being developed; the classes handle the streaming in and the streaming out of the data bits. The invention also uses an in-memory model that sits on top of the persistent classes. The in-memory model provides a simple add, update, delete, and query interface for the viewers, editors, parsers and importers shown in FIG. 1. The in-memory model isolates each component from the underlying persistent data model implementation artifacts. The in-memory model is the layer that handles the translation from a user-friendly form, for example "F1 " to the persistent model form, for example "::F1::F1". The in-memory model also acts as a cache. That is, the in-memory model stores the data collected by the various user interface dialog. Each in-memory model class has input and output APls for its required metadata. The metadata remains in the in-memory model object until the user or developer indicates that a change made on the screen is to be adopted, for example by pressing the OK button in a user dialog box; at that point, the appropriate persistent model objects and model object relationships are created. If the user does not wish to make the changes permanent, for example, by clicking on the cancel button in the user interface dialogue, the system does not instantiate the persistent model objects and the model relationships. In a preferred embodiment, the invention includes the following classes in its in-memory model. The class IXORepository provides an encapsulation for the model as a whole. It creates and stores the DMModel object and provides query functions by means known in the art to locate all the files that are contained in the model or to find a specific file by name in the model. The class IXOFileGroup creates and stores the OBFileGroup object. It provides an emit method that can be called to generate a code for the interface and implementation that are associated with a specific file group. The class IXOFile creates and stores the OBFile object that represents an IDL or Lava file. It also creates an DMFile object for each include or import statement. It provides methods to add and to query module, interface, constant, typedef, struct, enum, union, and exception that are scoped at the specific file level. The class IXOModule creates and it stores the OBModule object that represents an IDL module. It provides methods to add and query module, interface, constant, typedef, struct, enum, union, and exception that are scoped at the specific module level. The class IXOLInterface creates and stores the OBInterface object that represents an IDL interface or a lava interface. This class provides methods to add, query and find attribute, method, constant, typedef, struct, enum, union, and exception that are scoped at the specific interface level. The class IXOInterface also provides methods to add and to query the parent interfaces of the specific interface. When a parent interface is added, any method that needs to overwritten or implemented from the parent class will result in a DMMethod object being created and added to this class. The class IXOType encapsulates a type definition and an IXOType object is created for each of the following cases or events: the type of an attribute, the return type of a method, the type of a parameter, the type of a struct data member, the type of an exception data member, the type of a union data member and the type of a TypeDef. In order to add any of these objects to the persistent data model, the DMPart object representing its type must already have been added to the persistent model. The IXOType class provides operations to locate the DMPart that represents the type, or to add an empty OBinterface object that represents the type. The class IXOMember creates and stores the DMDataMember and associates it with a DMPart. The class IXOConstant is derived from IXOMember. It is used to represent an IDL constant. Each IDL constant has a name, a type, and a value. This class called a method IXOMember::to cdm to create the persistent data model DMDataMember object, and then adds the required constant declaration qualifier, and the constant value. The class IXOAttribute is derived from IXOConstant and is used to represent an IDL attribute or a Java member. Optionally, if the class represents a Java data member, initialization values can also be included in the attributes of this class. The class IXOOperation creates and stores the DMMethod object that represents an IDL method or Java method and it provides methods to add and query the list of parameters associated with the method. It also provides methods to get and set the method implementation for the corresponding method. The class IXOParameter creates and stores the object DMArg 33 in FIG. 3, that represents an IDL or Java parameter. The class IXOException creates and stores the object OBException 46 that represents an IDL exception. The class IXOException also provides methods to add and query the list of exception members that are scoped by the specific exception. It also delegates to the IXOMember class the task of creating its exception members. The class IXOEnum creates and stores the object OBEnum 50 that represents an IDL Enum. It provides methods to add and query the list of enumerators and members that are scoped by this enum type. It delegates to the IXOMember class the task of creating its enumerators. The class IXOStruct creates and stores the OBStruct 52 object that represents an IDL struct. It provides methods to add and query the list of struct members that are scoped by the specific structure. It delegates to the IXOMember the task of creating its struct members. The class IXOUnion creates and stores the OBUnion 54 object that represents an IDL union. It also provides methods to add and query the list of union members that are scoped by this union. It delegates to the IXOUnion member class the task of creating its union members. The class IXOUnion member is derived from IXOMember, and is used to represent an IDL union member. Each IDL union member has a case label, a name and a type. This class calls the method IXOMember::to CDM, which creates the DMDataMember object for the union member and then adds the case label value to the DMDataMember object thus created. Finally, the class IXOTypeDef creates and stores the object OBTypedef 48 that represents an IDL typedef. FIG. 4 is an example of an IDL file test.IDL and the model objects that are instantiated by a preferred embodiment of the invention for each of the elements in the file test.IDL. On the left side of the figure are shown code fragments that implement some of the elements described above and opposite them on the right side of FIG. 4 are shown the objects that are created in the preferred embodiment of the invention. The objects are shown as types, and, (the instances of those types that are created by the system). The statement # include "SomObj.idl" tells the system to add the header file SomObj.idl and creates an instance test.idl of the object OBFileGroup. It also creates an instance test.idl of the object OBFile, and an instance SomObj.idl of the object DMFile. Similarly, instances of other classes are created by the system for each of the statements within the file test.idl. Example Shown below is an example of a code fragment created by a typical application according to the prior art, and similar code fragment created according to the preferred embodiment of the invention. For example, a developer creates an IDL file, a.idl, containing the following code:
interface A
{
void print ()
}
Upon generation of an object in source code relating to the above code fragment, a prior art system would create an implementation file, a.cpp containing the following code:
void A::print ()
{
cout << "hello";
}
At a later date, the developer adds a parameter to the IDL file, and produces the following code in the file a.idl:
interface A
{
void print (in short p1);
}
The prior art system would take this change and regenerate the a.cpp file without the text that was intended to be displayed on the screen, and would contain the code shown below:
void A::print(in short p1)
{
(nulls)
}
Thus, when the user has changed the parameter list for the print statement, the prior art process has overwritten the text that the user had previously entered with nulls, and the user is required to re-enter the text in the a.cpp file. Using the preferred embodiment of the invention, the user prepares an IDL file containing the same code, as below:
interface A
{
void print ()
}
The system creates a class called OBInterface in the in-memory model, and, in the persistent model, instances of the class DMMethod and the class DMArg. As described above, the instance of DMMethod includes the attribute MethodBody which contains the method implementation that the user entered in the edit session, namely `cout<<"hello";`. The method implementation in the MethodBody includes:
void A::print ()
{
cout < < "hello";
}
When the user decides to make the change permanent, for example by clicking on the Ol( button in a user dialogue box, the DMMethod including the MethodBody is saved in the persistent data model. When the user makes the change to add a parameter at a later date, for example, to change the print statement from having no parameters to having the parameter in short p1, the MethodBody is not changed by the system. The generated a.IDL file would include the code below:
interface A
{
void print (in short p1);
}
Thus the text that the user previously entered is recovered in the form below for viewing and for further editing at the option of the user.
void A::print(in short p1)
{
cout < < "hello";
}
As described above, the MethodBody is saved as a string binary large object, and therefore is not changed by the system except upon being edited by the user. Because the MethodBody is a string, it can contain material that can be used in any platform upon which the user is working. For example, it can contain Java code or C++ code or a combination of text and code an individual language. An advantage of the invention is that the user does not have to re-enter large amounts of text and code from IDL files that previously would overwrite text that was entered by way of an editor. A further advantage is that the invention is inherently independent of the language used because the code and text entered by means of an editor is stored as string data in the MethodBody attribute of the instances of a DMMethod class, and is retrieved in the same way.
|
Same subclass Same class Consider this |
||||||||||