Object replacement Method and System

Field of the invention

The present invention relates to the replacement of objects in an object oriented environment.

Background of the invention

A programming approach based on the concepts of data abstraction and inheritance is known. Unlike procedural programming techniques, object-oriented programming concentrates on what data objects comprise the problem and how they are manipulated, not on how something is accomplished. The approach is in particular applied for example in the fields of application coding using languages such as Java (RTM) or C++ or database structures. Such data objects are collections of data and member functions that operate on that data, which together represent a logical entity in the system. In object-oriented programming, objects are grouped into classes that share common data definitions and member functions. Each object in the class is said to be an instance of the class. Object oriented approaches have been adapted to use in the modelling of complex systems. In visual composition, an instance of an object class consists of attributes, a data structure, and operational member functions. It can represent a person, place, thing, event, or concept. Each instance has the same properties, attributes, and member functions as other instances of the object class, though it has unique values assigned to its attributes. Systems modelled using such approaches include software projects themselves, and even the functions of businesses. Specialised languages for describing and handling such

models such as eclipse (RTM) have been devised, in addition to extensions of conventional object oriented programming languages .

Inside any Object Oriented system objects are interconnected by references to one another. For any given object there may be other objects that referencing it and others that are referenced by it. If a user creates a new object and wants to replace the original one with the newly created one, the problem is that it is then necessary to rebuild all the connections once again for the new object. The same problem appears in transformation engines or any such case that needs replacing objects.

Thus a user wishing to update an object is presented with the tasks of inserting the new object, moving the old object connections to the new object in order to re-establish valid links between objects so as to correctly realign them, based on personal memory, then deleting the old object. This is of course a major undertaking with an obvious cost in terms of operator time. There is also the danger of user error introducing faults and inconsistencies.

Summary of the invention

According to the present invention there is provided a method of amending an object oriented model according to independent claim 1, a model maintenance method according to claim the appended independent 6, a data structure according to the appended independent claim 7, a computer program according to the appended independent claim 8, a computer readable medium according to the appended independent claim 9, and a system according to the appended independent claim

10. Preferred embodiments are defined in the dependent claims .

Further advantages of the present invention will become clear to the skilled person upon examination of the drawings and detailed description. It is intended that any additional advantages be incorporated herein.

Brief description of the drawings

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings in which like references denote similar elements, and in which:

Figure 1 shows a formal representation of an exemplary object oriented environment in which the invention might be implemented. Figure 2 shows a formal representation of a development of the arrangement of figure 1 according to a second embodiment . Figure 3 shows a third embodiment.

Detailed description

Figure 1 shows a formal representation of an exemplary object oriented environment in which the invention might be implemented. The representation is based on UML diagram conventions.

All objects in the system inherit "MObject" 22. MObject 22 supports registering listeners 25 on it and notifying these listeners 25 upon changes. MObject 22 has a meta-class

"MClass" 23 which carries meta-information about MObject's references MReference 24.

According to a first embodiment, when an object is to be replaced, a model interrogation is performed in order to determine all links between the object to be replaced, and other objects. The system is configured to traverse the model to extract connection information and apply the extracted information to a new object. Each system may traverse its model differently, which may lead to inconsistent extracting and applying connections across different systems. One method may traverse the whole model, which represents a substantial drain on system resources. Another method may traverse only a part of the model to improve performance thereby compromising completeness. During searching for connections between model objects and the old object, one method can apply the found connection to the new object immediately after it is found and then resume the search. Another method may finish the search first then apply all found connections to the new object. Assuming that all system objects are in the List "allObjs", interrogating them to find the objects that refer to the old object can be performed as exemplified in the following pseudo code:

List foundRefsEntries ; for(int i =0; i < allObj s . length; i++) { //for each object in the list

MObject obj = allObj s . get (i) ; List refs = obj . getAllMReferences ( ) ; for(int j = 0 ; j < refs . length; j++){

//for each reference in that object

MReference ref = refs.get(j); if (obj .get (ref) == old) {

//that object's reference refers to the old object ReferenceEntry refEntry = new ReferenceEntry ();

//creating ReferenceEntry, filling it then adding it to the found list refEntry . setOtherEnd (obj ) ; refEntry. setRef (ref); refEntry. setNavigability (Navigability. From) ; foundRefsEntries . add (refEntry) ; } } }

ReplacementSet rs = new ReplacementSet ();

//creating ReplacementSet and filling it rs . setEntries (foundRefsEntries) ; rs.setθld(old) ;

The information thus gathered can then be used in defining new, replacement, objects so as to assume the correct connections .

Thus a method according to this embodiment might comprise the steps of identifying a first object or set of objects to be added to the model, identifying a second object or group of objects to be replaced by the first object or group of objects; interrogating the model to retrieve information defining the relationships between the first object or group of objects and other components of the model; and using the relationship definitions to configure the first object or

group of objects within the model so as to assume corresponding relationships with the other components.

The information retrieved is preferably meta-information . Certain kinds of meta-information are mentioned in the embodiment above. Meta-information is meta-data which means all meta-class information that includes information about an object's references, attributes, super classes, etc. This information generally describes the object's structure rather than the values of its references and attributes.

Using this meta-data, the values of its references and attributes can be retrieved in a generic way.

Figure 2 shows a formal representation of a development of the arrangement of figure 1 according to a second embodiment .

All objects in the system inherit "MObject" 22. MObject 22 supports registering listeners 25 on it and notifying these listeners 25 upon changes. MObject 22 has a meta-class "MClass" 23 which carries meta-information about MObject 's references MReference 24.

The "ReferenceRegistry" 26 registers itself as listener on all model objects 22. When the "MObject" 22 changes, it notifies the registry 26. When the notification is about reference change, the registry 26 updates its records accordingly. The record contains the referencing object (the dependent), the referenced object (the dependee) and the meta-reference .

When the user selects an object to replace another one, the system calls the "extract" method in the "ReplacementSet" 21 giving it the old object. For the references from the old

object "To" other objects, the method queries the "ReferenceRegistry" 26 with the old object to get the dependee objects and the "MReference" (s) 24 that the old object refers to them with. For each reference 24, it creates a "ReferenceEntry" 27 object with "navigability = To" to hold the "MReference" 24 and its value (the "otherEnd") .

For the references to the old object "From" other objects, the method queries the "ReferenceRegistry" 26 with the old object to get the dependent objects and the "MReference" (s) 24 that they refer to the old object with. For each reference, it creates a "ReferenceEntry" 27 object with "navigability = From" to hold the "MReference" 24 and its objects (the "otherEnd") .

The "ReplacementSet" 21 can have child sets for the old object child objects. When new objects are set for parent and child replacement sets using the "setNew" method and the system calls the parent "replace" method, it calls the child sets' "replace" recursively.

This method gets the "ReferenceEntry" (s) 27 where "navigability = To" and starts to update the new object references with the "otherEnd" values. For the "navigability = From", the method updates the "otherEnd" objects' references with the new object.

Thus according to this embodiment there are provided the further steps of detecting changes to the relationships between objects belonging to the model, and recording the changes in a registry, and at the step of interrogating it is the registry which provides the relationship definitions.

Program code is preferably provided according to an object oriented programming language and may include for example

objects defining the entities which constitute a business, and by their interrelations define the processes established within that business. An example of such an object might be an object defining a five-point quality control check. Each object is defined by meta-information including information about the object's references, attributes, super classes etc. As an object's references change over time this is reflected in the meta-information . In the case of the quality control check, the meta-information might identify the processing feeding into this process, and the path to be followed in a case where the quality control was either passed or failed. In a case where a new, six-point quality control check is introduced in place of the five point process, according to the present invention the new six- point quality control check can simply be inserted in place of the old five-point quality control check, and its position in the overall process established with reference to the five-point quality control check's meta information.

Figure 3 shows a third embodiment. This third embodiment describes a practical application of the invention, which may be realised by means of the structure described with reference to figure 1 and 2. Objects are defined so as to support the registering of listeners and notifying these listeners upon change. An object has a meta-class which carries meta-information about the object's references. A Reference Registry 5 registers itself as listener on all objects. When an object changes, it notifies the registry. These functions may be implemented for example by means of the adapter or observer tools provided by the Eclipse

Modelling Framework, or using the reflection API of the Java

(RTM) Virtual Machine. When the notification concerns reference change, the registry updates its records accordingly. The record contains the referencing object (the

dependent), the referenced object (the dependee) and the meta-reference, that is, the reference of the reference.

As shown in figure 3, there are provided the following objects representing elements in an industrial process: the "components" object 1 representing the components which are required for the manufacture of a particular article, the "5 point Quality Control criteria" object which represents a particular quality control check which assembled articles must satisfy in order to be dispatched for sale, a "boxing unit" 3 and a "shrink wrap unit" 4 which both represent packaging means. The various objects are interconnected by references. A reference "assemble" 14 connects the object "components" and the object "5 point quality control criteria" 2, a reference "transport" connects the object "5 point quality control criteria" 2 with the object "boxing unit" in a case where the quality control criteria are met, and a reference "disassemble" connects the object "5 point quality control criteria" 2 with the object "components" in a case where the quality control criteria are not met. No references exist to the "shrink wrap unit" object 3. The Reference Registry 5 is registered with all of the objects, so that any changes to the model's configuration are registered. Accordingly, in the situation shown in figure 3a the contents of the Reference Registry will be as follows:

In Figure 3b the model is amended so that articles satisfying the 5 point quality control criteria are transported to the shrink wrap unit instead of the Boxing unit. This in figure 3b the "Transport" reference 12 references the "shrink wrap unit" object 3. When this change is implemented, the "5 point quality control criteria", "Boxing unit" and "shrink wrap unit" objects will notify the Reference registry of the changes. The reference registry will accordingly be amended as follows:

Imagine now that it was required to replace the "5 point quality control criteria" object 5 with a new, improved "6 point quality control criteria" object 6 as shown in figure 3c. By referring to the Reference registry the new object can be configured to slot into the position of the old "5 point quality control criteria" object 5, in particular by assigning references in the system so that the new object will have relations with the processing feeding into this process, and the path to be followed in a case where the quality control was either passed or failed.

The steps of detecting changes to the relationships between objects belonging to the model, and recording changes in a

registry may be realised for example by means of object cross references, reflection or meta information.

Preferably, objects referenced by an object to be replaced, the information retrieved with respect objects referenced by an object to be replaced is information, e.g. meta- information of the first object to be replaced, and with respect to objects which reference the object to be replaced the information is information stored in said registry.

According to a further embodiment there is defined a method of programmatically replacing an object in an object oriented model, by interrogating the model to retrieve information defining the relationships between the object to be replaced and other components of the model. These relationship definitions are then used to configure the replacement object within the model so as to assume corresponding relationships with the other components. There may be established as a part of the model functions to detect changes to the relationships between objects belonging to the model, and recording the changes in a registry. This Registry is then interrogated to retrieve relationship definitions necessary to replace an object.

Embodiments may be offered as a service for example in the form of a model maintenance method comprising the steps of detecting changes to the relationships between objects belonging to a model; recording said changes in a registry; and providing relationship definitions concerning one or more of said objects upon interrogation.

Although the terminology adopted above may be associated with particular software environments, modelling tools, or commercial or programming paradigms, the skilled person will

appreciate that the concepts presented herein will extend freely to object oriented environments generally.

Any element may be realised in terms of hardware, firmware, software or a combination of any or all of these. Where software components are provided, they may be placed temporarily or permanently on a carrier, such as an optical disc such as a CD or DVD, a magnetic disc such as a hard drive or floppy disc, a memory device such as a flash memory card, EPROM, volatile memory unit etc., or an optical, electrical, radio or other transmission channel, for example for the purposes of distribution.