|
Description  |
|
|
FIELD OF THE INVENTION
This invention relates to data processing systems and methods and more
particularly to object oriented computing environments.
BACKGROUND OF THE INVENTION
Object oriented programming systems and processes, also referred to as
"object oriented computing environments", have been the subject of much
investigation and interest in state of the art data processing
environments. As is well known to those having skill in the art, object
oriented programming systems are composed of a large number of "objects".
An object is a data structure, also referred to as a "frame", and a set of
operations or functions, also referred to as "methods", that can access
that data structure. The frame has many "slots", each of which contains an
"attribute" of the data in the slot. The attribute may be a primitive
(such as an integer or string) or an object reference which is a pointer
to another object. Objects having identical data structures and common
behavior can be grouped together into, and collectively identified as, a
"class".
Each defined class of objects will usually be manifested in a number of
"instances". Each instance contains the particular data structure for a
particular example of the object. In an object oriented computing
environment, the data is processed by requesting an object to perform one
of its methods by sending the object a "message". The receiving object
responds to the message by choosing the method that implements the message
name, executing this method on the named instance, and returning control
to the calling high level routine along with the results of the method.
The relationships between classes, objects and instances are established
during "build time" or generation of the object oriented computing
environment, i.e. prior to "run time" or execution of the object oriented
computing environment.
In addition to the relationships between classes, objects and instances
identified above, inheritance relationships also exist between two or more
classes such that a first class may be considered a "parent" of a second
class and the second class may be considered a "child" of the first class.
In other words, the first class is an ancestor of the second class and the
second class is a descendant of the first class, such that the second
class (i.e., the descendant) is said to inherit from the first class (i.e.
the ancestor). The data structure of the child class includes all of the
attributes of the parent class.
Object oriented systems have heretofore recognized "versions" of objects. A
version of an object is the same data as the object at a different point
in time. For example, an object which relates to a "work in progress", is
a separate version of the same object data which relates to a completed
and approved work. Many applications also require historical records of
data as it existed at various points in time. Thus, different versions of
an object are required.
Heretofore, versions of an object were treated as totally independent
objects. Complicated processing was required to implement a version
control mechanism. Other applications have recognized versions of objects
and have used customized logic to implement version control. In this case,
the version control system of one application was not usable with other
applications, so that application portability was reduced.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide systems and
methods for controlling versions of objects in an object oriented
computing environment.
It is another object of the invention to provide systems and methods for
generically controlling versions of objects in an object oriented
computing environment to thereby reduce the amount of customized logic
which must be generated for version control.
These and other objects are provided, according to the present invention,
by a system and method for controlling versions of selected objects in an
object oriented computing system on a computing platform, wherein each
object includes an object frame containing data attributes and at least
one object method for performing actions on the associated objects. The
version control system creates a plurality of versions of a selected
object. The object frame of each version includes unique data attributes
and a common logical key attribute which is used to identify all versions
of an object. The object frame of each version also includes a unique
combination of an insert sequence attribute and an extract sequence
attribute. The unique combination of insert sequence attribute and extract
sequence attribute allows selection of a unique version of an object based
on time.
According to the invention, the plurality of versions of the object are
identified based on the common logical key attribute associated therewith.
In order to select one or more versions of the identified object, a
version identifier, such as a version time, is converted into a selection
sequence value. Each application which uses the version controlled objects
may include its own logic for converting a version identifier such as time
into a selection sequence value, based on the unique requirements of that
application.
The selection sequence value is then compared to the insert sequence
attributes and extract sequence attributes of the versions of the selected
object in order to select at least one of the versions of the selected
object. The comparison may find an applicable version having an insert
sequence attribute which is less than or equal to the selection sequence
value and an extract sequence attribute which is greater than the
selection sequence value. This selection method finds one applicable
version valid at a particular time. Alternatively, all versions which were
inserted by a certain time can be found by finding those versions having
an insert sequence attribute which is equal to the selection sequence
value. As another alternative, all versions which were extracted by a
particular time can be found by identifying those versions having an
extract sequence attribute which is equal to the selection sequence value.
According to another aspect of the invention, the object frame of each
version also includes a perspective attribute for providing another
selection criteria for selecting one or more versions of an object. When
identifying versions, a perspective value can be compared to the
perspective attributes of all of the versions, and only those versions
which have a perspective attribute equal to the perspective value can be
selected. This comparison can be made in addition to the comparison by
insert sequence attribute and extract sequence! attribute.
The invention also supports updates to version controlled objects. Thus,
new versions can be added, existing versions can be changed, existing
versions can be deleted, and previous actions can be undone. Accordingly,
versions of objects are generically generated, identified and processed in
an object oriented computing environment.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 schematically illustrates a hardware and software environment in
which the present invention operates.
FIG. 2 schematically illustrates the main components of an object oriented
computing system.
FIG. 3 illustrates an example of an inheritance hierarchy in an object
oriented computing system.
FIG. 4 conceptually illustrates three objects, each of which includes a
plurality of versions according to the present invention.
FIG. 5 conceptually illustrates versions which are ordered by time
according to the present invention.
FIG. 6 conceptually illustrates versions of an object having different
perspectives according to the present invention.
FIG. 7 illustrates a class hierarchy including a version control class
according to the present invention.
FIG. 8 illustrates a version controlled object according to the present
invention.
FIG. 9 illustrates operations for creating and selecting versions according
to the present invention.
FIGS. 10A-10C illustrate three versions of an object according to the
present invention.
FIG. 11 illustrates operation of an add method according to the present
invention.
FIGS. 12A-12B illustrate operation of a change method according to the
present invention.
FIGS. 13A-13B illustrate operation of a delete method according to the
present invention.
FIGS. 14A-14C and 15A-15B illustrate operation of an undo method according
to the present invention.
FIG. 16 illustrates a class hierarchy including a version control class and
a version control stream according to the present invention.
FIG. 17 illustrates a class hierarchy including an application specific
version control metaclass according to the present invention.
FIG. 18 illustrates an example of the presentation of version controlled
objects according to the present invention.
DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention now will be described more fully hereinafter with
reference to the accompanying drawings, in which preferred embodiments of
the invention are shown. This invention may, however, be embodied in many
different forms and should not be construed as limited to the embodiments
set forth herein; rather, these embodiments are provided so that this
disclosure will be thorough and complete, and will fully convey the scope
of the invention to those skilled in the art. Like numbers refer to like
elements throughout.
Prior to describing a system for controlling versions of objects in an
object orienting computing environment, a general overview of object
oriented computing environments will be provided. An overview of a system
and method for controlling versions will then be provided followed by a
detailed design description.
Object Oriented Computing Environment
In an object oriented computing environment, work is accomplished by
sending action request messages to an object which contains data. The
object will perform a requested action on the data according to its
predefined methods. Objects may be grouped into object classes which
define the types and meanings of the data, and the action requests
(messages) that the object will honor. The individual objects containing
data are called instances of the class.
Object classes can be defined to be subclasses of other classes. Subclasses
inherit all of the data characteristics and methods of the parent class.
They can add additional data and methods and they can override or redefine
any data elements or methods of the parent class. An object may be
represented schematically, and is represented herein, by a rectangle
including an upper rectangle and a lower rectangle within the object
rectangle. The upper rectangle contains the data structure represented by
a frame having slots, each of which contains an attribute of the data in
the slot. The lower rectangle indicates the object's methods which
encapsulate the frame and which are used to perform actions on the data
encapsulated in the frame of the upper rectangle.
Referring now to FIG. 1, a hardware and software environment in which the
present invention operates will now be described. As shown in FIG. 1, the
present invention is a method and system for supporting Complex Objects
within an object oriented computing environment 11 operating on one or
more computer platforms 12. It will be understood by those having skill in
the art that computer platform 12 typically includes computer hardware
units 13 such as a central processing unit (CPU) 14, a main memory 15 and
an input/output (I/O) interface 16, and may include peripheral components
such as a display terminal 21, an input device 22 such as a keyboard or a
mouse, nonvolatile data storage devices 23 such as magnetic or optical
disks, printers 24 and other peripheral devices. Computer platform 12 also
typically includes microinstruction codes 26 and an operating system.
As shown in FIG. 1, object oriented computing environment 11 operates on
computer platform 12. For example, each computer platform 12 may be a
computer having an IBM System 370 architecture. However, it will be
understood by those having skill in the art that object oriented computing
environment may operate across multiple computer platforms. Operating
system 28 may be an IBM multiple virtual storage (MVS). Object oriented
computing environment 11 is preferably written in Intermediate C, which is
an object oriented dialect of the C computer programming language and is
similar to the C++ computer programming language. The design'and operation
of computer platforms and object oriented computing environments including
that of an object manager, are well known to those having skill in the art
and are described, for example in U.S. Pat. No. 5,265,206, issued Nov. 23,
1993 to Abraham et al. entitled A Messenger and Object Manager to
Implement an Object Oriented Environment; and U.S. Pat. No. 5,161,225 to
Abraham et al. entitled Persistent Stream for Processing Time Consuming
and Reusable Queries in an Object Oriented Database Management System;
U.S. Pat. No. 5,151,987 to Abraham et al. entitled Recovery Objects in an
Object Oriented Computing Environment; and U.S. Pat. No. 5,161,223 to
Abraham entitled Resumeable Batch Query for Processing Time Consuming
Queries in an Object Oriented Database Management System, all assigned to
the assignee of the present invention, the disclosures of which are hereby
incorporated herein by reference, and in numerous textbooks such as Object
Oriented Software Construction by Bertrand Meyer, published by Prentice
Hall in 1988, the disclosure of which is incorporated herein by reference.
Referring now to FIG. 2, which is a reproduction of FIG. 5 of the U.S. Pat.
No. 5,313,629, the main components of an object oriented program (11, FIG.
1) will be described. A detailed description of the design and operation
of an object oriented program is provided in "Object Oriented Software
Construction", by Bertrand Meyer, published by Prentice Hall in 1988, the
disclosure of which is incorporated herein by reference.
Referring to FIG. 2, object oriented computing environment 11 includes
three primary components: a Messenger 51, an Object Management Table 52
and a Loaded Classes Table 53. The Messenger 51 controls communication
between calling and called messages, Object Management Table 52 and Loaded
Classes Table 53. Object Management Table 52 contains a list of pointers
to all active object instances. The Loaded Classes Table 53 contains a
list of pointers to all methods of active object classes.
Operation of the Object Oriented Program 11 will now be described for the
example illustrated in FIG. 2, in which Method A (block 54) of an object
sends a message to Method B (block 55) of an object. Method A sends a
message to Method B by calling Messenger 51. The message contains (1) an
object reference of the instance to receive the message, (2) the method
the object instance is requested to perform on the data it encapsulates,
and (3) any parameters needed by the receiving method. Messenger 51
obtains a pointer to the data frame 56 of the instance object specified by
Method A, by searching Object Management Table 52 for the instance object.
If the specified instance object cannot be found, Object Management Table
52 adds the instance object to the table and calls the instance to
materialize its data from the database. Once in the instance table, Object
Management Table 52 returns the pointer to the materialized instance
object.
Messenger 5I then obtains the address of Method B from the Loaded Classes
Table 53. If the instance's class is not loaded, the Loaded Classes Table
53 will load it at this time to materialize its data. The Loaded Classes
Table 53 searches for the specified method (Method B) and returns the
address of the method to Messenger 51.
The Messenger 51 then calls Method B, passing it a system data area and the
parameters from the call made by Method A including the pointer. Method B
accesses the data frame 56 using the pointer. Method B then returns
control to the Messenger 51 which returns control to Method A.
FIG. 3 illustrates an example of an inheritance hierarchy in an object
oriented computing platform. As shown, three object classes are
illustrated for "salesperson" "employee" and "person", where a salesperson
is a "kind of" employee, which is a "kind of" person. In other words,
salesperson is a subclass of employee and employee is the superclass of
salesperson. Similarly, employee is the subclass of person and person is
the superclass of employee. Each class shown includes three instances. B.
Soutter, W. Tipp and B. G. Blue are salespersons. B. Abraham, K. Yates,
and R. Moore are employees. J. McEnroe, R. Nader, and R. Reagan are
persons. In other words, an instance is related to its class by an "is a"
relation.
Each subclass "inherits" the frames and methods of its superclass. Thus,
for example, a salesperson frame inherits age and hire date objects from
the employee's superclass as well as promote methods from the employee
superclass. Salesperson also includes a unique quota attribute and a pay
commission method. Each instance can access all methods and frames of its
superclass, so that, for example, B. G. Blue can be promoted.
Version Control Method and System: Overall Design and Operation
The general concept of version control implies that there are a plurality
of versions of a selected object. For purposes of illustration, three
objects will be illustrated: a person object "Jill", a person object
"John" and a cat object "Fluffy". As shown in FIG. 4, each of these
objects includes a plurality of versions. For example, versions of Fluffy
can be Fluffy at birth, Fluffy at age 10, and Fluffy the kitten. A logical
key identifies a selected object which may have many versions. Thus, for
example, assume there is a stack of photographs of Fluffy, each
representing a "version". There are also photographs of Jill and John. In
order to sort the photographs, the logical key of Fluffy, Jill and John
are used. Assume further that the photographs have been developed on
slides, and a selection sequence is being developed to decide which slide
to view on a slide projector. Since only one slide can be viewed at any
time, it is important that the selection criteria result in only one
slide. The first selection was by logical key (e.g. "Fluffy") but there
are many versions of Fluffy to choose from.
One way of selecting versions is by time. This would involve selecting by
date (for example, show me Fluffy as of last week) or status (for example,
show me Fluffy as a kitten). Note that the time selection criteria may not
have an exact match for the version. The version that will be selected
will be the one that was valid "at that time", as illustrated in FIG. 5.
Moreover, two versions of the same object can both be valid at the same
time. Thus, there may be the same picture of Fluffy as a slide, an
8.times.10, a 3.times.5 and a wallet size, as shown in FIG. 6. Thus, a
full qualification to select a picture would include the logical key
(example: Fluffy), date (example: yesterday), and perspective (example:
wallet size).
It will be recognized that in the above described example, time selection
was relatively simple. A date/time stamp can be applied to each picture
and the date/time stamp provides a unique identification for selecting a
version. For other types of version control, this may not be true. Thus,
the present invention provides means for assigning each version a time
order so that it can be selected unambiguously.
Version controlled objects may operate in connection with complex objects
and externalizable objects as illustrated in the class hierarchy of FIG.
7. The complex object class is described in application Ser. No.
08/101,913 entitled System and Method for Supporting Complex Objects in an
Object Oriented Computing Environment, filed concurrently herewith and
assigned to the assignee of the present invention, the disclosure of which
is hereby incorporated herein by reference The externalizable object class
is described in U.S. Pat. No. 5,432,925 issued Jul. 11, 1995 entitled
System and Method for Providing a Uniform External Interface for an Object
Oriented Computing System, the disclosure of which is hereby incorporated
herein by reference.
Referring now to FIG. 8, a version controlled object 80 according to the
present invention, is illustrated. Each version controlled object 80
includes the following attributes 81: logical key, perspective, insert
sequence, extract sequence and data. The logical key attribute provides
identification of the version controlled object. Each version of the
version controlled object is identified by a logical key, an insert
sequence and an extract sequence. Version controlled objects are
specializations of simple objects which participate in a complex object,
and the logical key for version controlled objects is the same as the
logical key for complex object subobjects. However, in the case of a
version controlled object, logical key only identifies an instance of the
object up to version selection. The exact version selection is achieved by
providing a selection sequence value, which is then compared to the insert
and extract sequence attributes. FIGS. 10A-10C illustrate three versions
of an object. These versions will be used to illustrate operation of the
methods 82 for version controlled objects.
FIG. 9 summarizes operations for creating and selecting versions according
to the present invention. As shown, a plurality of version controlled
objects 80a . . . 80n are present in the object oriented computing
environment 11. As shown at Block 91, versions are created for a selected
one of the objects 80a . . . 80n by placing a common logical key attribute
in the frame of each version and by generating a unique combination of an
insert sequence attribute and an extract sequence attribute for each
version. The insert and extract sequence attributes are created using the
add, delete, change, undo and promote methods 82 of FIG. 8, described
below.
Still referring to FIG. 9, when a version selection request is received at
Block 92, an object is identified based upon the logical key, at Block 93.
The selection request includes a version identifier such as version time.
At Block 94 the version time is converted into a selection sequence value.
This conversion may be unique for each application which uses version
control. However, the end result is a sequence value.
Still referring to FIG. 9, as shown at Block 95, a version is selected by
comparing the selection sequence value to the insert sequence attributes
and the extract sequence attributes of all of the versions using one of
the find methods 82 described below.
Formal methods in the version controlled object are defined using only the
abstract properties of the logical key and insert and extract sequence. In
other words, selection of version controlled objects requires a full or
partial logical key value, a perspective value and a selection sequence
value. In the discission that follows, unless it is explicitly mentioned,
perspective is considered to be part of the logical key. The logical key
for an instance of an object may be compared against a logical key used
for selection. The comparison may be against a full or partial logical
key. In the case of comparison against a partial logical key, the partial
logical key will be that of the immediate complex object ruler of the
object being selected, and a stream of objects matching the partial
logical key will be generated. As known to those having skill in the art,
a stream is a linked list of all instances that match a search criteria.
The insert sequence and extract sequence are long integers. They will be
compared to the selection sequence value.
Referring again to FIG. 8, the following methods 82 are defined for a
version controlled object:
1. Find Applicable: This method selects the version controlled object that
satisfies all of the following:
a. Logical key matches the passed logical key.
b. Insert sequence attribute is less than or equal to the selection
sequence value.
c. Extract sequence attribute is greater than the selection sequence value.
This assumes that "unextracted" is larger than any sequence number.
2. Find Inserted By: This method selects the version controlled object that
satisfies all of the following:
a. Logical key matches the passed logical key.
b. Insert sequence attribute is equal to the selection sequence value.
3. Find Extracted By: This method selects the version controlled object
that satisfies all of the following:
a. Logical key matches the passed logical key.
b. Extract sequence attribute is equal to the selection sequence value.
4. Find Logical: There is a match on logical key (regardless of the insert
and extract sequence attributes). This method returns a boolean true if
there is a matching object, rather than the object itself, since there may
be multiples.
In addition streams are provided to support complex object processing. The
streams will take as selection the logical key of the immediate ruler,
which in some cases is a partial logical key of the type of object
selected in the stream. The following methods are provided for selection
of a stream.
1. Find Applicable Stream: Selection is the same as Find Applicable, except
that a partial logical key is used.
2. Affected At Stream: This method selects the stream of version controlled
objects that satisfies all of the following:
a. Logical key matches the passed logical key.
b. Insert sequence attribute is less than or equal to the selection
sequence value.
c. Extract sequence attribute is equal to or greater than the selection
sequence value.
The affected at stream is used during complex object actions such as
promote, promote verify, and undo which must find all objects touched by a
particular version (either as an insert or extract). This stream includes
objects which are applicable at the version but not directly affected
(i.e. the insert sequence is less than and the extract sequence is greater
than the selection sequence value) because these objects may have
subobjects which are directly affected by the version (i.e. the insert or
extract sequence matches the selection sequence number).
3. Delete At Stream: This method selects the stream of version controlled
objects that satisfies all of the following:
a. Logical key matches the passed logical key.
b. Extract sequence attribute is greater than the selection sequence value.
This stream will include objects which are applicable at the version (i.e.
insert sequence is less than or equal to the version selection sequence),
and also objects which are future to the version to be dele | | |