Title of Invention

A METHOD FOR PROCESING AT LEAST ONE SOURCE CODE MODULE WITHIN A SOURCE CODE PROGRAM

Abstract

ABSTRACT OF THE DISCLOSURE An object oriented franaework for source code processing provides an infrastructure that embodies the steps necessary to process source code and a mechanism to extend the framework to fit a particular scenario for processing source code. Certain core functions are provided by the framework which interact with extensible functions provided by the framework user. The architecture of the framework allows a developer to select the native processing tool of their choice, and provides an infrastructure for using that processing tool with other platforms {e.g., targets, etc.) The extensible functions allow the processing tools of a new platform to be easily incorporated into the framework. The framework thus allows a programming environment with development on multiple platforms that targets multiple platforms, which may be easily customized to include new platforms and new processing tools.

Full Text

An Object Oriented Framework Mechanism for Multi-Target Source Code Processing Field of the Invention The present invention relates in general to the data processing field. More specifically, the present invention relates to the field of Object Oriented framework mechanisms. Background of the Invention The development of the ED VAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices. Due to competitive forces and differing performance requirements, a variety of different types of computers (i.e. platforms) have evolved. One of the primary differences between platforms is the operating system the platform uses. Each operating system provides different features, and the characteristics of platforms vary according to the specific operating system employed. Examples of popular operating systems include AIX, OS/2, MS-DOS and Windows. In the early years of computers, each different platform had a unique dedicated software development environment. The programming tools were written specifically for the platform on which they were to be used, and the software developed on a platform was typically run on the same platform. If a programmer needed to change from one platform to another, he or she would be faced with an entirely different set of programming tools on the new platform that would require a substantial time investment to acquire proficiency using these new tools. In addition, if a programmer needed to develop software targeted to more than one platform, this would generally require that the programmer have each of the target platforms on his or her desk, and that the programmer become proficient at using the development tools on each platform. In the alternative, developers of programming tools could port their processing tools from one platform to another. However, this approach is not economical due to the inherent inefficiencies of making the tools compatible with other platforms, and tool vendors have traditionally not offered this type of inter-platform support for their tools. Source code in any compiled language needs to be processed. In most cases, programs are not completely recompiled every time they are changed. Only the modules that are affected by the changes are recompiled to save on time and resources. Programming tools typically include processing tools that are generically referred to as "make tools." A make tool analyzes the various modules that comprise a computer program and only compile those modules that need to be compiled. Various different make tools exist for different platforms. For example, AIX has a processing tool known simply as "make." OS/2 has a similar processing tool called "nmake." Make tools are included in the group of source code processing tools that may be implemented within the framework. Make tools are also commonly referred \o as processing tools or reprocessing tools. As used herein, the terms processing tool and reprocessing tool are used interchangeably to denote any type of programming tool (such as a make tool) that is typically specific to a particular programming environment (i.e., development platform). The term "module" as used herein is a generic term for any portion of source code that may need to be processed. It may refer to a procedural routine or to an object. While the preferred embodiment herein is implemented using object oriented technology, the term module is used to distinguish a portion of source code that may need processing from objects in the framework. An example will illustrate the problems associated with developing software on one development platform targeted to for different target platforms. If a programmer were developing software on an OS/2 development platform for an OS/2 target platform, for an MVS target platform, and for an AIX target platform, the programmer would typically develop the software once on the first platform (e.g., OS/2), process (i.e., compile) the software using the processing tool native to the first platform, make modifications to accommodate a second platform (e.g., MVS), process (or reprocess) the software using the processing tool native to the second platform, make modifications to accommodate the third platform (e.g., AIX), and process (or reprocess) the software using the processing tool native to the third platform. Note that this process requires a programmer to be proficient using the processing tools on all three target platforms. Each platform requires a substantial investment in time for a programmer to achieve proficiency using the programming tools (e.g., make tools) for that platform. In addition, becoming proficient in using three different sets of processing tools may be difficult due to the confiision that may be created by the different commands and protocols that each requires. If a new target platform emerges, a programmer must now become familiar with all the programming tools for the new platform, including the reprocessing tools. There is currently no easy way for a programmer to extend existing processing tools for one platform to a second platform. As more software is developed for numerous different target platforms, the need for better mechanisms for processing source code for multiple target platforms becomes more apparent and more acute. Without a mechanism that can be readily customized and extended to allow reprocessing on multiple target platforms using reprocessing tools native to one target platform, the rate of development of computer software will be impaired. Summary of the Invention According to the present invention, an object oriented framework for source code processing provides an infrastructure that embodies the steps necessary to process source code and a mechanism to extend the framework to fit a particular scenario for processing source code. Certain core functions are provided by the framework, which interact with extensible functions provided by the framework user. The architecture of the framework allows a developer to select the native processing tool of their choice, and provides an infrastructure for using that processing tool with other platforms (e.g., targets, etc.) The extensible functions allow the processing tools of a new platform to be easily incorporated into the framework. The framework thus allows a programming environment with development on multiple platforms that targets multiple platforms, which may be easily customized to include new platforms and new processing tools. The framework mechanism of the present invention was designed and constructed using object-oriented technology. Those who are unfamiliar with object-oriented technology, or with object-oriented framework mechanisms, should read the object-oriented overview section of the Description of the Preferred Embodiments section. Accordingly, the present invention provides a method for processing at least one source code module within a source code program, the method comprising the steps of providing an extensible object oriented framework mechanism that performs the processing of the at least one source code module according to extended portions of the framework mechanism that are customized to provide a desired processing configuration; and executing the object oriented framework mechanism on a computer system. With reference to the accompanying drawings, in which : FIG. 1 is a category diagram of an example framework mechanism; FIGS. 2 through 6 are class diagrams for the example framework mechanism of fig. 1; FIG. 7 is an object diagram for the example framework mechanism of figs. 1 through 6; FIG. 8 is a block diagram of the computer system used in the preferred embodiment; FIG. 9 is a flow diagram showing steps in accordance with the present invention to perform core functions of the framework mechanism; FIG. 10 is a category diagram of a framework mechanism constructed in accordance with the teachings of the present invention; FIGS. 11-15 are class diagrams of a framework mechanism constructed in accordance with the teachings of the present invention; FIGS. 16-19 are object diagrams of a fi^amework mechanism constructed in accordance with the teachings of the present invention to implement two different processing configurations; and FIG. 20 is a class diagram showing the extension of the framework to implement the processing configurations of FIGS. 16-19. Description of the Preferred Embodiments Overview - Object-Oriented Technology As discussed in the Summary section, the present invention was developed using Object-oriented (00) firamework technology. Individuals skilled in the art of 00 framework technology may wish to proceed to the Detailed Description section of this specification. However, those individuals who are new to framework technology, or new to 00 technology in general, should read this overview section in order to best understand the benefits and advantages of the present invention. Object-oriented Technology v. Procedural Technology Though the present invention relates to a particular 00 technology {i.e., 00 framework technology), the reader must first understand that, in general, 00 technology is significantly different than conventional, process-based technology (often called procedural technology). While both technologies can be used to solve the same problem, the ultimate solutions to the problem are always quite different. This difference stems from the fact that the design focus of procedural technology is wholly different than that of 00 technology. The focus of process-based design is on the overall process that solves the problem; whereas, the focus of OO design is on how the problem can be broken down into a set of autonomous entities that can work together to provide a solution. The autonomous entities of 00 technology are called objects. Said another way, 00 technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures. The Term Framework There has been an evolution of terms and phrases which have particular meaning to those skilled in the art of 00 design. However, the reader should note that one of loosest definitions in the 00 art is the definition of the word framework. The word framework means different things to different people. Therefore, when comparing the characteristics of two supposed framework mechanisms, the reader should take care to ensure that the comparison is indeed "apples to apples." As will become more clear in the forthcoming paragraphs, the term framework is used in this specification to describe an 00 mechanism that has been designed to have core function and extensible function. The core function is that part of the framework mechanism that is not subject to modification by the framework purchaser. The extensible function, on the other hand, is that part of the framework mechanism that has been explicitly designed to be customized and extended by the framework purchaser. 00 Framework Mechanisms While in general terms an 00 framework mechanism can be properly characterized as an 00 solution, there is nevertheless a fiindamental difference between a framework mechanism and a basic 00 solution. The difference is that framework mechanisms are designed in a way that permits and promotes customization and extension of certain aspects of the solution. In other words, framework mechanisms amount to more than just a solution to the problem. The mechanisms provide a living solution that can be customized and extended to address individualized requirements that change over time. Of course, the customization/extension quality of framework mechanisms is extremely valuable to purchasers (referred to herein as framework consumers) because the cost of customizing or extending a framework is much less than the cost of a replacing or reworking an existing solution. Therefore, when framework designers set out to solve a particular problem, they do more than merely design individual objects and how those objects interrelate. They also design the core function of the framework (i.e., that part of the framework that is aol to be subject to potential customization and extension by the framework consumer) and the extensible function of the framework (i.e., that part of the framework that is to be subject to potential customization and extension). In the end, the ultimate worth of a framework mechanism rests not only on the quality of the object design, but also on the design choices involving which aspects of the framework represent core function and which aspects represent extensible function. ZAF - An Illustrative Framework Mechanism While those skilled in the art appreciate that fi-amework design is necessarily an intertwined and iterative process, example design choices for a simplistic fi-amework mechanism are set forth in the paragraphs that follow. It should be understood, though, that this is only an example fi-amework that is being used in this specification to illustrate and best explain fi-amework mechanisms such that the reader can understand and appreciate the benefits and advantages of the present invention. Framework designers determine what objects are needed for a firamework mechanism by selecting objects fi-om what is called the problem domain. The problem domain is an abstract view of the specific problem at hand. The example problem domain chosen for this illustrative fi-amework mechanism is that of zoo administration. The specific problem is that of designing a mechanism that assists zoo keepers in the care and feeding of zoo animals. In our example of a Zoo Administration Framework (ZAF), an 00 firamework designer would look to the zoological problem domain and decide that any ZAF would of necessity involve a mechanism that represented the relationship between zoo keepers and animals (i.e., to represent how zoo keepers care for animals). The firamework designer would also likely recognize that zoo animals usually live in cages, pens, tanks, and other sorts of containment units. Therefore, our fi-amework designer would start with the idea that the fi-amework would have to involve mechanisms that represented all of these fimdamental entities and relationships. How ZAF is Designed To begin the design process, our fi-amework designer would likely begin with what is called a category diagram. Category diagrams are used to describe high level framework mechanisms, and how those mechanisms relate to one another. FIG. 1 is a category diagram for the example firamework ZAF. The notation used in FIG. 1, and that used in the other figures of this specification, is explained in detail in the Notation section at the end of this specification (pages 41-47). Each mechanism in a category diagram represents groupings of objects that perform a particular Sanction. For the purposes of illustration, assume that our fi-amework designer decides that ZAF should be made up of four high level mechanisms: a zoo administration mechanism, a zoo keeper mechanism, an animal mechanism, and a containment unit mechanism. As shown in FIG. 1, the zoo administration mechanism has been designed to use the zoo keeper mechanism to administer the zoo. The zoo administration mechanism is therefore said to have a using relationship with the zoo keeper mechanism. (Again, please refer to the notation section of this specification for an explanation of this relationship and the other notation used in this specification.) As discussed, the zoo administration mechanism has been designed to have responsibility for overall control of ZAF. Accordingly, the zoo administration mechanism is responsible for scheduling the operation of the zoo keeper mechanism. Note also that our fi-amework designer designed the zoo administration mechanism to be a core fiinction of ZAF, which means that it has been designed such that it will not be subject to potential customization and extension. The C in the category box denotes this fact. Please note fiirther that the uses relationship between the zoo administration mechanism and the zoo keeper mechanism has also been designed such that it is not available for ultimate customization by the fi-amework consumer. The zoo keeper mechanism has been designed to be generally responsible for the care and feeding of the zoo animals. Accordingly, it uses the animal and containment unit mechanisms to perform its tasks. However, unlike the design of the zoo administration mechanism, our framework designer has designed the zoo keeper mechanism to be extensible fimction, which again means that the zoo keeper mechanism has been designed to be available for modification and/or extension by the fi-amework consumer to address future care and feeding requirements. This fact is denoted by the E in the zoo keeper mechanism category box. Our firamework designer has designed the animal mechanism to represent the animal side of the interaction between zoo animals and zoo keepers. Since the animal population in the zoo is something that changes on a regular basis, the animal mechanism has similarly been designed as an extensible function. The containment unit mechanism interacts with the zoo keeper mechanism by representing individual containment units such as pens, tanks, and cages. Like the animal mechanism, the containment unit mechanism has been designed as an extensible function such that it can handle future customization and extension requirements. Please note here, however, that even though the zoo keeper, zoo animal, and containment unit mechanisms have all been designed as extensible fimction, the relationships between the mechanisms have been designed to be a core fimction of ZAF. In other words, even though it is desirable to give ZAF's consumers flexibility relative to the zoo keeper, zoo animal, and containment unit mechanisms, it is not desirable to allow ZAF's consumers to change how these mechanisms relate to one another. Our fi-amework designer would next design the classes and relationships that make up the mechanisms shown on FIG. 1. A class is a definition of a set of like objects. As such, a class can be thought of as an abstraction of the objects or as a definition of a type of object. From the view of a computer system, a single object represents an encapsulated set of data and the operation or a group of operations that are performed by a computer system upon that data. In fact, in a secure computer system, the only access to the information controlled by an object is via the object itself This is why the information contained in an object is said to be encapsulated by the object. Each class definition comprises data definitions that define the information controlled by the object and operation definitions that define the operation or operations performed by objects on the data that each object controls. In other words, a class definition defines how an object acts and reacts to other objects by defining an operation or set of operations that is/are performed on the defined data. (Please note that operations are sometimes called methods, method programs, and/or member functions) When taken together, the defined operation(s) and data are said to be the behavior of the object. In essence, then, a class definition defines the behavior of its member object or objects. FIG. 2 is an 00 class diagram that shows the fiandamental classes that our firamework designer has designed for ZAF. Each class representation includes its relationship to the mechanisms shown on FIG. 1. For example, we can see that the zoo keepers class is denoted as being^ow Zoo Keeper Mechanism. The fiandamental classes of ZAF include: the zoo administrator class, which is part of the zoo administration mechanism; the zoo keeper registry class, which is also part of the zoo administration mechanism; the animal registry class, which is part of the zoo keeper mechanism; the zoo keepers class, which is also part of the zoo keeper mechanism; the containment unit registry class, which is also part of the zoo keeper mechanism; the animals class, which is part of the animal mechanism; and the containment unit class, which is part of the containment unit mechanism. Please note again that the relationships between the classes have been designed as core function of ZAF such that they are not available for uhimate modification by ZAF's consumers. The zoo administrator class is the definition of the object that is responsible for the overall control of ZAF. Again, 00 classes only define the objects that interact to provide a solution to the problem. However, it is by exploring the characteristics of the class definitions that we are able to understand how the objects of the framework mechanism have been designed to provide a living solution that can be customized and/or extended to address future requirements. The zoo administrator class has been designed to have a uses relationship with the zoo keeper registry. Our framework designer has designed the zoo administrator and zoo registry classes to be a core function of ZAF because our designer has decided that ZAF's consumers should not be allowed to modify the behavior of objects that are members of these class definitions. The zoo keeper registry, which has what is called a contains by reference relationship with the zoo keeper class, is simply a class that defines an object that is a container for all zoo keeper objects. Accordingly, the zoo keeper registry includes a definition for a list_zoo_keepers() operation. As will be described later, this operation is responsible for providing a Hst of zoo keeper objects to other objects that request such a hst. FIG. 3 shows a lower level view of the zoo administrator class. Since objects of type zoo administrator have responsibility for overall control of ZAF, the zoo administrator class has been designed to include operations that perform tasks oriented towards zoo administration. The class definition includes the following five operations: 5_minute_timerO, add_animalO, add_containment_unit(), add_zoo_keeper(), and start_zoo_adminO. The start_zoo_admin() operation is responsible for starting ZAF. That is, a user or system administrator will interact with the start_zoo_admin() operation to begin administration of a zoo via ZAF. Once started, our framework designer has designed the start_zoo_adminO operation to initiate the 5_minute_timer() operation. Every five minutes, the 5_minute_timer() operation instructs the zoo keeper objects to go out and check on the animals. The add/delete_zoo_keeper operation is responsible for interacting with users of ZAP to define additional zoo keepers (i.e., additional zoo keeper classes), to add additional zoo keepers {i.e., zoo keeper objects), and to remove zoo keeper classes and/or objects. As will become clear in the forthcoming paragraphs, each zoo keeper object is responsible for performing a particular zoo task. Therefore, it is natural that a user of ZAF might well want to add a zoo keeper definition and object to handle an additional zoo task or to remove a definition or object that is no longer needed. As will be seen, this flexibility is provided by designing the zoo keeper mechanism as an extensible function. Like the add/delete_zoo_keeper operation, the add/delete_animalO operation is responsible for interacting with users to define additional zoo animal classes and objects and to remove classes and objects that are no longer needed. Again, it is quite natural for a zoo to need to add and remove animals. The add/delete_containment_unitO operation is responsible for the definition of new containment unit classes and objects and for removal of classes and/or objects that are no longer necessary. Again, our framework designer has designed ZAF in a way that provides this flexibility by designing the animal and containment unit mechanisms as extensible functions. Referring back to FIG. 2, the zoo keepers class definition has a uses relationship with the animal registry, animals, containment unit registry, and containment units classes. Since the value of ZAF is enhanced by allowing ZAF's consumers to customize and extend the zoo keepers, animals, and containment unit classes, these classes have been designed as extensible function. However, changing the behavior of the animal and containment unit registry classes would disrupt the basic operation of ZAF. Therefore, these classes have been designed to be core functions of ZAF. While the classes and categories within ZAF have been described as either core functions or extensible functions, it is important to note that the term "core function" as used herein broadly relates to requirements that cause the framework to operate in the desired manner. In simple terms, core fiinctions of a framework are the functions that any program that uses the fi-amework will perform. The requirements of core functions may be imposed by the structure of the framework (e.g., by designating certain classes as core functions) or may be imposed by fimctional requirements that dictate how a framework consumer may utilize the framework. Thus, core fiinctions include not only the classes and class relationships that are designated as core, but may also include extensible classes that must be implemented in particular ways for the framework to function properly. Said another way, while extensible function is that part of the framework that is designed to be customized by the framework consumer, the nature and extent of the customization is governed by the requirements of the framework's core flinction (i.e., the overall framework function imposed by the structure and fimctional requirements of the framework). For example, the animals class has been designed as extensible function of ZAF so that ZAF can be customized to accommodate different types of animals. However, the ability to customize the extensible animals class does not imply that the nature of the customization can violate the basic structure imposed by the core function of ZAF {e.g., by customizing the animal class to the extent that it can no longer be reasonably said to represent a type of animal). FIG. 4 is a class diagram of the zoo keeper class. However, before describing the details of FIG. 4, it is worthwhile to point out that the class definitions shown on FIG. 4 are ranked in a very simple ordering called a class hierarchy. A class, like the zoo keeper class, that represents the most generalized/abstract class in a class hierarchy is referred to as the base class of the hierarchy. The ordering of classes in a class hierarchy goes from most general to least general {i.e., from general to specific). Less general classes {e.g., the feeder class) are said to inherit characteristics from the more general class or classes {i.e., the zoo keeper class in this case). As such, class definitions feeder, veterinarian, and temperature controller are said to be subclasses of the zoo keeper class. Inheritance mechanisms will be explored in more detail in the discussion associated with FIG. 5. As shown on FIG. 4, the zoo keeper class definition contains a single operation definition, the check_animals() operation definition. The reader should also note that the zoo keepers class definition is marked as being an abstract class. Abstract classes are not designed to have objects created as their members, but are instead used to define a common interface/protocol for their subclasses. A class is said to be an abstract class when at least one of its operation definitions is a. pure virtual operation definition. Pure virtual operation definitions are designed for the sole purpose of defining a common interface for subclass definition of that operation. In other words, the design of the actual behavior {i.e., the data and operations) is left to the subclasses themselves. In the case of the zoo keeper class definition, the feeder, veterinarian, and temperature controller subclasses define specific implementations of the pure virtual check_animals() operation definition that is contained in the zoo keeper class. An operation is marked as a pure virtual when it is set equal to 0. It is important to note, though, that the common interface of a pure virtual operation definition must be honored by all subclasses such that requesting objects (called client objects) can use subclass member objects (called server objects) without needing to know the particular subclass of the server object. For example, whenever the object defined by the zoo administrator class needs a particular action performed, it interacts with a zoo keeper object. Because the interface to these objects was defined in abstract, base class zoo keeper and preserved in the subclass definitions for the check_animalsO operation, the zoo administrator object need not have special knowledge about the subclasses of any of the server objects. This has the effect of decoupling the need for the action {i.e., on the part of the zoo administrator object) fi-om the way in which the action is carried out (i.e., by one of the objects of the zoo keepers subclasses). Designs (like the ZAF design) that take advantage of the characteristics of abstract classes are said to be polymorphic. Polymorphism is extremely important to 00 fi-amework design because it allows the way in which something is done (called the implementation) to be changed or extended without eiFecting the mechanisms that depend on the fact the action is actually performed. In other words, client objects need only understand that certain objects perform certain fiinctions, not how those fiinctions are actually carried out. This is one way in which a properly designed fi-amework can be readily customized and extended to satisfy fiiture requirements. As previously discussed, our fi-amework designer has designed ZAF such that zoo keeper objects interact with animal and containment unit objects to perform their tasks. FIG. 5 is a class diagram for the class hierarchy of the abstract class animal. Since the animals class definition is responsible for representing the characteristics and behavior of zoo animals, the fi-amework designer has designed abstract class animal in a way that reflects this responsibility. As shown, the example animal class definition includes data definitions feed_fi'eq, location, and temp_range and operation definitions get_temp_rangeO, feedQ, needs_foodO, needs_vet_visitO, and vet_visit(). For the purposes of this fi-amework overview, it is not necessary to explore each definition in detail. However, the temp_range data definition and the get_temp_rangeO and feedQ operation definitions are good examples of well thought out fi-amework design choices. The feedQ operation definition is designed to perform the actual feeding of the animals (i.e., through specific feeding apparatus which is not showTi). The feedQ operation is a pure virtual operation. Again, this means that the design of the class is such that the actual mechanism that performs the needed fiinction has been left to be defined by the subclasses. Requiring subclass definition is a good design choice in cases like this where objects that are created as members of the subclasses have particularized needs. In ZAF, for example, each type of animal is likely to have need for a particularized feeding apparatus, which not only makes definition of a generic feedQ operation difficult, but valueless. By way of comparison, the fi-amework designer has explicitly designed the get_temp_rangeQ operation such that it is sol a pure virtual operation definition. This means that get_temp_rangeQ has been generically defined as a default operation. As such, it is considered a virtual operation. Default operations are used to provide generic fiinction to subclasses. The subclasses can simply use the default operations or they can customize ,or extend the default operations by redefinition. Redefinition of a default operation is called overriding the defauh operation. Mammals is a subclass of class animals, and as such, mammals inherits all of the characteristics of class animals. Please note that class mammals is also designed as an abstract class, which again means that it has not been designed to have objects created as its members, but has instead been designed to provide a common interface for its subclasses. Subclass mammal is fiarther subclassed into classes carnivore and herbivore. Since definition of the feedQ operation has been left up to the subclasses, subclasses carnivore and herbivore each have their own definition of the feedQ operation. Again, this is a good design choice because meat eating carnivores are going to have different needs than their plant eating counterparts. Temp_range is a data definition for the range of temperatures that coincides with that of the specific animal's natural habitat and the get_temp_rangeO operation definition is designed to retrieve the temp_range for a specific animal and return it to a requesting client object. Subclass reptiles contains its own data definition for temp_range and its own definition for the get_temp_range() operation, ZAF has been designed this way to point out that data definitions can be overridden just like operation definitions. Since many reptiles live in desert conditions, where nights can be very cold and days very hot, the default temp_range definition has been overridden in the reptiles class to include time and temperature information (not explicitly shown on FIG. 5). This is another good design choice because it allows ZAF to treat reptile containment units differently than other containment units by allowing temperature adjustments to be made based on the time of day as well as on the current temperature of the containment unit itself FIG. 6 is a class diagram showing a lower level view of the containment unit class. The containment unit class contains virtual operation definition adjust_temp(). The adjust_temp definition defines both the interface and mechanism used to actually adjust the temperature in the containment units of the zoo (i.e., via heating and cooling mechanisms which are not shown). How the ZAF Objects Interact Beyond designing the objects that make up the solution to the specific problem, our framework designer must also design how the individual objects interrelate. In other words, the objects must interrelate in way that takes advantage of the manner in which they were designed. As discussed, the way in which the defined operations of an object operate on the data defined for the object is called the object's behavior. While objects may be characterized as autonomous entities, it is still very important that each object exhibit a consistent behavior when interrelating with other objects. Consistent behavior is important because objects depend upon the consistent behavior of other objects so that they themselves can exhibit consistent behavior. In fact, consistent behavior is so important that an object's behavior is often referred to as the contract the object has with the other objects. When an object does not exhibit a consistent behavior, it is said to have violated its contract with the other objects. When an operation of one object needs access to the data controlled by a second object, it is considered to be a client of the second object. To access the data controlled by the second object, one of the operations of the client will call or invoke one of the operations of the second object to gain access to the data controlled by that object. One of the operations of the called object (i.e., a server operation in this case) is then executed to access and/or manipulate the data controlled by the called object. FIG. 7 is an object diagram showing how the example objects of ZAF interact to assist zoo personnel in operating the zoo. A detailed analysis of the interaction of all of the ZAF objects is unnecessary for the purposes of this overview. However, the reader should review the following simple control flow to obtain a rudimentary understanding of how objects interact to solve problems. As mentioned, an object is created to be a member of a particular class. Therefore, Zelda the Zoo Administrator [object 706] is an object that is a member (actually the only member) of the zoo administrator class. As such, object Zelda is responsible for overall control of ZAF. All of the zoo keeper objects have registered with the Zoo Keeper Register object [object 700]. Therefore, object Zelda obtains a Hst of the current zoo keepers by calling the list_zoo_keepers() operation [step 1] of the Zoo Keeper Register object. The Zoo Keeper Register object has been created as a member of the zoo keeper register class. For the purposes of illustration, assume that this occurs every five minutes as part of Zelda's 5_minute_timer() operation. The Zoo Keeper Register object then responds with the zoo keepers list [step 2]. The hst of zoo keepers includes Tina the Temperature Checker [object 714], Vince the Vet. [object 740], and Fred the Animal Feeder [object 752]. Each zoo keeper has been created as a member of the zoo keepers class. In particular, objects Tina the Temp. Checker, Vince the Vet., and Fred the Feeder are respectively members of the temperature controller, veterinarian, and feeder subclasses. Once the list of current zoo keepers has been returned to object Zelda, object Zelda instructs each zoo keeper in the Hst to check the animals by calling the check_animals() operation of each zoo keeper object [only the call to Tina the Temp. Checker is shown - step 3]. Please note that object Zelda did not need to understand the types of zoo keepers that were in the zoo keeper list, the number of zoo keeper objects in the list, or the specialized characteristics of any one zoo keeper object. Object Zelda uses the same interface (i.e., the check_animals() operation) to communicate with each zoo keeper object. It is then up to the individual zoo keeper objects to perform the task for which they have been created. Each zoo keeper object performs its assigned task through use of its own check_animals() operation. For example, object Tina's check_animalsO operation retrieves a list of current animals from the animal registry object by calling the list_animals() operation [step 4] and then a list of containment units from the containment unit register object by calling the Iist_cont_units() operation [step 6]. Upon examining the animal Ust, object Tina's check_animals() operation determines that there are only two animals currently registered in the zoo, Sam the Snake [object 728] and Simba the Lion [object 718]. Object Tina's check_animals() operation then calls the get_temp_range() operations to get temperature ranges from objects Sam and Simba [steps 8 and 10]. Once the temperature ranges have been returned, the check_animalsO operation of object Tina determines which containment units house the respective animals (i.e., Simba and Sam) and then calls the adjust_temp() operation of the appropriate containment unit (i.e.. Lion Cage 7 in the case of object Simba and Snake Pit 3 in the case of object Sam) to adjust the temperature of the containment units [steps 12 and 13]. The adjust_temp() operation of each containment unit then completes the control flow by proceeding to adjust the temperature in a way that is appropriate for the animals contained in each containment unit. (That is, the temperature is adjusted based on time and temperature for Snake Pit 3 and based on time alone for Lion Cage 7.) The reader should note that the relationship between the check_animalsO operation and the adjust tempo operations is polymorphic. In other words, the check_animals() operation of object Tina does not require specialized knowledge about how each adjust_temp() operation performs its task. The checkanimalsQ operation merely had to abide by the interface and call the adjust_temp() operations. After that, it is up to the individual adjust_tempO operations to carry our their tasks in the proper manner. At this point, it is again worthwhile to point out that the ZAF mechanism is an extremely simplistic ft-amework mechanism that has been presented here to help novice readers understand some basic fi^amework concepts so as to best appreciate the benefits and advantages of the present invention. These benefits and advantages will become more clear upon reference to the following Detailed Description. Detailed Description FIG. 8 shows a block diagram of the computer system of the present invention. The computer system of the preferred embodiment is a computer system such as an AIX platform. However, those skilled in the art will appreciate that the mechanisms and apparatus of the present invention apply equally to any computer system, regardless of whether the computer system is a complicated multi-user computing apparatus or a single user workstation. As shown in the exploded view of FIG. 8, computer system 800 comprises main or central processing unit (CPU) 810 connected to main memory 820, mass storage interface 830, terminal interface 840, and network interface 850. These system components are interconnected through the use of a system bus 860. Mass storage interface 830 is used to connect mass storage devices (such as DASD device 855) to computer system 800. One specific type of DASD device is a floppy disk drive, which may store data to and read data fi-om a floppy diskette 895. Main memory 820 contains application programs 822, objects 824, data 826, and an operating system 828. Computer system 800 utilizes well known virtual addressing mechanisms that allow the programs of computer system 800 to behave as if they only ffi^fBeck&tRO9Q6-017 ■ have access to a large, single storage entity instead of access to muhiple, smaller storage entities such as main memory 820 and DASD device 855. Therefore, while application programs 822, objects 824, and operating system 828 are shown to reside in main memory 820, those skilled in the art will recognize that these programs are not necessarily all completely contained in main memory 820 at the same time. (It should also be noted that the term "computer system memory" is used herein to generically refer to the entire virtual memory of computer system 800.) Operating system 828 is a suitable muhitasking operating system such as AIX; however, those skilled in the art will appreciate that the spirit and scope of the present invention is not limited to any one operating system. Operating system 828 preferably supports an object oriented programming environment such as that provided, for example, by the C++ programming language. One or more application programs 822 provide a programming environment for computer system 800, and include a source code processing framework mechanism 870, which is preferably an object oriented framework mechanism. However, the scope of the invention is not limited to object oriented framework mechanisms within application programs, and framework mechanism 870 (whether object oriented or not) may exist anywhere in the virtual memory space of computer 800. Although computer system 800 is shown to contain only a single main CPU and a single system bus, those skilled in the art will appreciate that the present invention may be practiced using a computer system that has multiple CPUs and/or multiple buses, whether contained in a single unit or distributed across a distributed processing computer system. In addition, the interfaces that are used in the preferred embodiment each include separate, ftiUy programmed microprocessors that are used to ofF-load compute-intensive processing from CPU 810. However, those skilled in the art will appreciate that the present invention applies equally to computer systems that simply use I/O adapters to perform similar functions. Terminal interface 840 is used to directly connect one or more terminals 865 to computer system 800. These terminals 865, which may be non-intelligent or fully prograrnmable workstations, are used to allow system administrators and users to communicate with computer system 800. Network interface 850 is used to connect other computer systems and/or workstations {e.g., 875 and 885 in FIG. 8) to computer system 800 in networked fashion. The present invention applies equally no matter how computer system 800 may be connected to other computer systems and/or workstations, regardless of whether the connection to the network is made using present-day analog and/or digital techniques or via some networking mechanism of the future. It is also important to point out that the presence of network interface 850 within computer system 800 means that computer system 800 may engage in cooperative processing with one or more other computer systems or workstations. Of course, this in turn means that the programs shown in main memory 820 need not necessarily all reside on computer system 800. For example, one or more programs of application programs 822 may reside on another system and engage in cooperative processing with one or more programs that reside on computer system 800. This cooperative processing could be accomplished through use of one of the well known client-server mechanisms such as remote procedure call (RPC). At this point, it is important to note that while the present invention has been (and will continue to be) described in the context of a fully fijnctional computer system, those skilled in the art will appreciate that the present invention is capable of being distributed as a a program product via floppy disk {e.g., 895 of FIG. 8), CD ROM, or other form of recordable media, or via any type of electronic transmission mechanism. Source Code Processing Framework Mechanism of the Present Invention The source code processing fi^amework mechanism disclosed herein provides an architecture for defining a very powerfiil yet flexible programming environment for computer programmers. This programming environment may be easily extended to accommodate any number of platforms by implementing the native processing functions provided by the platform into the fi-amework, and by defining a processing configuration that includes the new platform. There are four different functions that are performed by some platform during the processing of source code, namely: development, target, library, and processing. A development platform is the platform on which the source code is written or originally developed. A target platform is the platform on which an executable derivative of the source code is intended to run. A library platform is a platform on which the source code is stored. A processing platform is a platform on which the source code processing {e.g., compilation) is performed. Each of these functions may be accomplished by one platform, or may be accomplished by any combination of multiple platforms. For example, it is possible for a software developer to develop source code on one platform PI targeted for a different platform P2, store the code in a third (library) platform P3, and process the source code on a fourth platform P4. It is important to remember that the term platform refers to a type of computer, and not a specific computer. While a software developer may write source code on a first computer, store the source code on a second computer, and compile the source code on a third computer, if these three computers are of the same type, this is still development on a single platform, and the programmer would be able to use the same processing tools on all these machines. The benefit of the framework disclosed herein is the capability to use processing tools from one particular platform when multiple platforms are involved. Once different platforms are defined within the framework, source code processing may be performed across platforms by extending extensible functions within the framework to implement a specific processing configuration. Any number of processing configurations may be defined and implemented with the framework. Source code processing as used herein is a generic term for any type of processing on source code. Well-known processing steps for source code include compilation and linking. The term source code processing is intended in its broadest sense, including any particular step or combination of steps that process source code. Referring to FIG. 9, a framework in accordance with the present invention performs step that comprise a method 900. The first step is to collect the initial candidates for processing (step 910). The initial candidates are the parts (e.g., source code modules) that the user specifies for processing. Next, the dependencies of the initial candidates to other modules is determined (step 920). Dependencies are modules that jm initial candidate uses directly or indirectly. The currency of the initial candidates and dependencies is then checked (step 930) to determine which modules must be processed. The appropriate commands for the processing tool are then generated (step 940) to process all required modules. These commands are then distributed (step 950) to a number of different computers on a network (if available). In the preferred embodiment, a network of computer systems is available over which the commands (e.g., in step 940) may be distributed (e.g., in step 950). If the framework is used on a stand-alone computer system, the distribute step 950 will not be able to distribute the commands to other computers, and the stand-alone computer will process all commands. The framework user would still implement a distributor subclass, but this subclass would provide a null function. In the ahemative, a framework within the scope of the present invention could forego the distribute step 950 and process all of the commands on the computer executing the framework. The distribute step 950 of FIG. 9 is illustrated as one step in the preferred embodiment of the invention. The commands are then executed by the one or more computers (step 960), processing the modules. The processed modules are then stored (step 970), and the processed code is output to a target platform (step 980). While the specific implementation of each step of method 900 will vary according to the desired processing configuration and the specific extensible functions provided by the framework user, method 900 is an illustration of several processing steps that may be performed for a large number of different configurations implemented within a single fi-amework. The fact that the preferred embodiment of the framework is object oriented, while not essential to the broad concept of the invention, allows the user of the framework to easily define the needed functions by subclassing from the classes defined within the framework using known object oriented programming environments, such as C++. The preferred embodiment of the present invention is an object oriented source code processing framework. While many different designs and implementations are possible, one suitable example of an object oriented source code processing framework is disclosed below to illustrate the broad concepts of the present invention. Class Definitions FIG. 10 is a category diagram of the source code processing framework mechanism 870 in accordance with the present invention. Those skilled in the art will appreciate that the categories illustrated in FIG. 10 represent collections of object oriented programming (OOP) classes that encapsulate data attributes and behaviors (or methods). Objects instantiated as members of these classes are stored in the main memory 820 of computer system 800. These classes may be implemented, for example, in a computer system operating environment that supports the C++ programming language. The classes have been broken down into four categories: the Processing Configurations (PC) category, the Processing Mechanisms (PM) category, the Multi-Platform Enablement (MPE) category, and the Utilities category. The Utilities category is a core category (as indicated by the "C" label), meaning that the classes in the utilities category may not be modified by a user of framework 870. The remaining categories are extensible categories (as indicated by the "E" label), meaning that users may extend the classes in these categories by defining and implementing classes that are subclasses of framework-defined classes. The Processing Configurations category has a using relationship with the Processing Mechanisms category and the Muhi-Platform Enablement category, indicating that classes within the Processing Configurations category invoke the methods provided by the classes in these categories. In addition, the Processing Mechanisms category has a using relationship with the Utilities category. Note that these relationships between categories are core relationships (as indicated by the "C" label), meaning that the framework user cannot modify these relationships. FIG. 11 is a top level class diagram of the classes used to implement source code processing framework 870. The categories to which the classes belong are identified by the abbreviations below the class names, with a PC indicating that the class belongs to the Processing Configurations category, a PM indicating that the class belongs to the Processing Mechanisms category, and a MPE indicating that the class belongs to the Multi-Platform Enablement category. The ProcessingConfiguration class belongs to the Processing Configurations category. Members of the Processing Mechanisms category include: CandidateColIector, DependencyChecker, CurrencyChecker, Distributor, and Command Assembler. Members of the Multi-Platform Enablement category include: Platform and File Agent. The key methods provided in each class are not shown in FIG. 11, but are shown in subsequent figures. The framework of FIG. 11 may be used by subclassing from the extensible classes (marked with an E). Thus, a user of the framework may extend the framework by defining a subclass, for example SampleProcessingConfiguration, then by supplying subclasses such as SampleCandidateCollector, SampleDependencyChecker, SampleCurrencyChecker, SampleDistributor, SampleFileTransfer, and SampleCommandAssembler that support the SampleProcessingConfiguration. The unmarked classes of FIG. 11 illustrate that many different subclasses could be defined to support a large number of processing configurations. A class diagram of the classes in the Processing Mechanisms category is shown in FIG. 12. (Note that Command is actually in the Utilities category, but is shown here to allow a description of the behavior of the classes in the Processing Mechanisms category that use Command.) The Distributor class, the CurrencyChecker class, the DependencyChecker class, the CandidateCollector class, and the CommandAssembler class are all extensible abstract classes, and they all have a using relationship with the PartList parameterized core class. The relationships between these classes are core relationships, those that may not be changed by the user of the framework. The Command class is a core class that is part of the Utilities category, and the Distributor and CommandAssembler both have a using relationship with Command. As described with reference to FIG. 11, a user of the framework may extend the framework by subclassing from the extensible classes. Thus, for the classes in the Processing Mechanisms category of FIG. 12, the following user-defined subclasses are provided as examples: SampleDistributor, SampleCurrencyChecker, SampleDependencyChecker, SampleCandidateCoUector, and SampleCommandAssembler. The classes of CandidateCollector, DependencyChecker, CurrencyChecker, and CommandAssembler represent fiinctions that all source code processors must perform. In general, any source code processor will first determine what modules have been targeted for processing, and will collect the candidates in an initial list. This flinction corresponds to the CandidateCollector class. Next, the initial list is checked to determine dependencies by other modules on the modules in the initial list, and a dependency list is created that contains both the candidates and their dependencies. This function corresponds to the DependencyChecker class. All the modules in the dependency list are then checked to see if they have changed since the last processing (e.g., compilation). Of those modules in the dependency list, those that require processing are put in an out of date list. This flinction corresponds to the CurrencyChecker class. Next, commands with all the appropriate options are generated to cause each of the modules in the out of date list to be processed. This function corresponds to the CommandAssembler class. Each different type of platform that provides a stand-alone programming environment will typically have native commands for native tools that process source code. These native tools may be implemented in the framework by subclassing firom the extensible classes listed above. In this manner, any number of platforms and their respective native processing tools may be supported by the framework, allowing a programmer to use tools native to one platform when working on a different platform. In addition to the power and flexibility that the fi-amework provides to support any processing tool from any platform, the firamework also allows a user to use the native tools when detached from their programming environment. The framework essentially emulates the operation of a particular native processing tool by implementing its various sub-functions using the native functions of other platforms. This allows a programmer to bypass the framework and use the same native commands when detached from the programming environment that the firamework provides. Each extensible class in FIG. 12 defines a set of methods which provide the functions needed for the fi-amework to operate. The Distributor class defines extensible method distributeQ. CurrencyChecker defines extensible method findOutOflDatePartsQ; DependencyChecker defines extensible method findAllCandidatesQ; CandidateCollector defines extensible method findlnitialCandidatesQ; and CommandAssembler defines extensible method createCommandsO- Each of these methods correspond to functions that may be performed during source code processing. These methods provide extensible interfaces that allow a user of the framework to take advantage of the flexibility and power of the fi-amework by easily adapting the framework to new or different platforms or processing tools. The specific implementation shown in the figures for the classes are shown for the purpose of illustration, and a framework user may select alternative implementations by overriding extensible methods within the scope of the present invention. FIG. 13 illustrates the relationships of the ProcessingConfiguration class to other classes in the framework. ProcessingConfiguration is an extensible class that contains the methods shown. ProcessingConfiguration is the class that a user of the framework will use to define a specific programming environment that needs to be supported by the fi-amework. ProcessingConfiguration has a "has by reference" relationship to CandidateCollector, DependencyChecker, CurrencyChecker, Distributor, and Platform, indicating that a ProcessingConfiguration will include one or more objects from each of these classes. ProcessingConfiguration has a using relationship with the PartList parameterized core class and the CommandAssembler extensible class. All of the relationships between classes in FIG. 13 are core relationships, that a user of the fi-amework may not alter. SampleProcessingConfiguration is an example of a user-defined processing configuration that is defined by subclassing fi-om the ProcessingConfiguration extensible class. An object instantiated under the ProcessingConfiguration class will have the methods shown in FIG. 13. Many of the methods simply call methods in the other extensible classes. For example, when the getlnitialCandidatesQ method of ProcessingConfiguration is invoked, it in turn invokes the findlnitialCandidatesQ method of CandidateCollector. When the checkCurrencyQ method of ProcessingConfiguration is invoked, it in turn invokes the findOutOfDatePartsQ method of the corresponding CurrencyChecker. In similar fashion, when the checkDependenciesQ method of ProcessingConfiguration is invoked, it in turn invokes the findAllCandidatesQ method of the corresponding DependencyChecker. When the distributeQ method of ProcessingConfiguration is invoked, it in turn invokes the distributeQ method of the Distributor. And when the createCommandsQ method of ProcessingConfiguration is invoked, it in turn invokes the createCommandsQ method of the Command Assembler. Classes included in the Multi-Platform Enablement category are illustrated in FIG. 14. A Platform class is defined that is an extensible class of the fi-amework. The platform class has a "has by reference" relationship to a FileAgent class, which is an abstract extensible class of the fi-amework. The relationship between the Platform class and the FileAgent class is a core relationship. The classes DistributedFileSystem and FileTransferMechanism are shown as examples of user-extended classes that are defined by subclassing fi-om the FileAgent abstract class. The Utilities category includes a Command class and a PartList class, as shown in FIG. 15. Command and PartList are both core classes. Command contains a processing command (such as a compile command) and a createQ method to create the processing command. PartList also includes a createQ method, which is invoked when a part list needs to be created. Core Functions FIG. 11 best distinguishes between core and extensible fianctions in the diagnostic framework of the present invention. Specifically, as noted above, the PartList class is the only core class. The rest of the classes in FIG. 11 are extensible. Note that all class relationships shown in FIG. 11 are core relationships, and may not be modified by the user of the framework. In fact, it is the fixed character of these relationships between classes that characterizes a framework and makes it useful and powerful. The core fianction of the source code processing framework is defined by the one core class and class relationships, along with functional requirements that cause the framework to behave in the desired manner. As described above with respect to FIG. 9, the overall core function of the diagnostic framework includes the steps of method 900. Object Interaction The operation of the framework of FIG. 11 may be best understood by providing two specific processing configurations as examples. FIGS. 16 and 17 illustrate a first example of a processing configuration, and FIGS. 18 and 19 illustrate a second example of a different processing configuration. A processing configuration generally contains a specification of the following parameters: development platform, library platform, processing platform, target platform, whether or not a distributed file system or some type of file transfer is available, whether of not a facility exists for distributing commands across a network, and the processing tool to be used. The first example, as illustrated in FIGS. 16 and 17, is referred to herein as the projectXProcessingConfiguration, which is specified as follows: 1) The end user is running on OpSysl (Development platform = OpSysl) 2) The library is running on OpSysl (Library platform = OpSysl) 3) The source will be processed on OpSysl machines (Processing platform = OpSysl) 4) The source code is processed to execute on OpSys2 machines (Target platform = OpSys2) 5) A distributed file system is available for a network of OpSysl machines 6) A distribution mechanism (protocolXYZDistributor) is available on multiple operating systems including OpSysl 7) The processing tool chosen on OpSysl is PI Referring to FIGS. 16 and 17, the object diagrams for the projectXProcessingConfiguration are shown. Each of the objects shown correspond to classes defined and discussed above, as illustrated by the concrete subclasses shown in FIG. 20. The implementation of FIG. 20 illustrates how a user of the fi-amework can extend the classes of the fi-amework to accommodate any suitable processing configuration by providing concrete subclasses of the extensible fi-amework classes. For example, plDependencyChecker corresponds to an object that is a member of a PlDependencyChecker class; plCandidateCollector corresponds to an object that is a member of a PlCandidateCollector class; opSyslLibraryPlatform corresponds to an object that is a member of the Platform class (not shown); protocolXYZDistributor corresponds to an object that is a member of a ProtocolXYZDistributor class; pi Currency Checker corresponds to an object that is a member of a PlCurrencyChecker class; opSyslProcessingPlatform corresponds to an object that is a member of the Platform class (not shown); and opSys2TargetPlatform corresponds to an object that is a member of a concrete subclass of the Platform class (not shovm). The object projectXProcessingConfiguration includes each of these objects described above, as illustrated in FIG. 17. Referring now to FIG. 16, an object aUser represents a user of a development environment that leverages the framework, and the processQ method initiates action by the framework (step 1). The aUser object is a simplified representation of any user interface that initiates processing of source code, and may be implemented by any suitable fashion. Next the method materializeProcessingView() is invoked (step 2) to assure the files needed to process the source code are available. The object opSyslLibraryPlatform includes an object distributedFileSystemAgent, which is a member of a concrete subclass of the FileAgent class. This configuration assumes that opSysl supports distributed file storage, and the distributedFileSystemAgent is responsible for materializing the processing view, i.e., to make the required files available to the fi-amework. The getlnitialCandidatesO method is then invoked (step 3), which results in the projectXProcessingConfiguration object delegating that function by calling the findlnitialCandidatesQ method (step 4) of plCandidateCollector. plCandidateCollector is an object that performs the candidate collection function for the native pi processing tool. Likewise, plDependencyChecker, plCurrencyChecker, and pi Command Assembler all correspond to the dependency checker function, the currency checker function, and the command assembler function of the native pi processing tool. In response to the findlnitialCandidatesO method being called, plCandidateCollector creates an initialList of candidates (step 5), which is an object that is a member of the PartList class. Next, the dependencies of the candidates in the initialList are determined by calling the checkDependenciesO method (step 6). This function is delegated to the plDependencyChecker object by invoking the findAllCandidates() method based on the initialList, which is passed as a parameter (step 7). plDependencyChecker then determines the dependencies of all the candidates in the initialList, and creates a dependencyList by calling the createQ method (step 8). The dependencyList is an object that is a member of the PartList class. Once the dependencyList has been constructed identifying all portions of the program that may need to be processed, the currency of the modules in the dependencyList must be determined by invoking the checkCurrency() method (step 9). This function is delegated to the plCurrencyChecker object by calling its findOutOfDatePartsO object, passing the dependency list as a parameter (step 10). The currency of each entry in the dependencyList is checked, and from this list an outOfDate list is created by calling its create() method from plCurrencyChecker (step 11). The outOfDate list is a member of the PartList class, and contains a list of items in the dependencyList that are out of date (i.e., that need to be processed). The next step in the process calls the makeProcessingList() method, passing the outOfDateList as a parameter (step 12). The projectXProcessingConfiguration object accomplishes this task by invoking the create() method of a processingList object (step 13), which is a member of the PartList class. The processingList object contains the list of modules to be processed, which is derived from combining the initial candidates the user requested to be processed plus those modules that are dependent upon the initial candidates and are not current (from the outOfDateList). Next, the createCommandsQ method of pi Command Assembler is called, passing the processingList as a parameter (step 14). pi Command Assembler then calls the create () method of commandList (step 15), which creates a list of commands to process the modules in the processingList. Once the commandList is created, these commands are distributed by calling the distributeCommandO method of the protocolXYZDistributor, passing the commandList as a parameter (step 16). The protocolXYZDistributor object represents a distributor that may exist on multiple operating systems, including opSysl. The distributor then calls the remoteCommandQ method on the opSyslProcessingPlatform object (step 17), which causes distribution of the modules to be processed across various machines on the network by the distributedFileSystemAgent within the opSysl ProcessingPlatform object. " Once the processing is complete, the store() method of projectXProcessingConfiguration is called to store the results of the processing (step 18). Calling the store() method resuhs in calling the storePart() method of the OpSyslLibraryPlatform object for as many parts as were processed, passing one part during each call (step 19). Once all parts have been stored back in the library, projectXProcessingConfiguration calls the moveProcessingOutput() method on the opSys2TargetPlatform object (step 20). This step moves the processed code to the target platform for execution. Note that this function is performed by the opSyslToOpSys2FileTransfer object wdthin the opSys2TargetPlatform object. One example of a suitable file transfer mechanism is using File Transfer Protocol (FTP), which is a known file transfer utility that many commercial operating systems support. A second example processing configuration is described in FIGS. 18 and 19, and is called projectYProcessingConfiguration. The characteristics of the project YProcessingConfiguration are: 1) The end user is running on OpSys3 (Development platform = OpSys3) 2) The library is running on OpSysl (Library platform = OpSysl) 3) The source will be processed on OpSys3 machines (Processing platform = OpSys3) 4) The source code is processed to execute on OpSys2 and OpSys3 machines (Target platform = OpSys2 and OpSys3) 5) A protocol for file transfer exists between multiple operating systems including OpSysl and opSys3 (protocolABCFileTransfer) 6) A distribution mechanism (opSys3Distributor) is available for OpSys3 7) The processing tool chosen on OpSys3 is P2 Referring to FIGS. 18 and 19, the object diagrams for the project YProcessingConfiguration are shown. Each of the objects shown correspond to classes defined and discussed above, as illustrated by the concrete subclasses shown in FIG. 20. The object projectYProcessingConfiguration includes each of the objects described above, as illustrated in FIG. 18. Steps 1-15 in FIG. 19 are the same as in the previous discussion relating to the projectXProcessingConfiguration illustrated in FIGS. 16 and 17, v^dth the exception that the projectXProcessingConfiguration is replaced with the project YProcessingConfiguration, and plCandidateCoUector, plDependencyChecker, plCurrencyChecker, plConunand Assembler, and the objects fi"om concrete subclasses of the FileAgent class (the objects within the platform objects) are all replaced with their corresponding counterparts fi"om p2, as illustrated in FIG. 19. Step 15 results in the creation of a commandList that contains the commands needed to process the modules in the processingList. Once the commandList is created (step 15), these commands are distributed by calling the distributeCommand() method of the opSys3Distributor, passing the commandList as a parameter (step 16). The opSys3Distributor object represents a distributor for opSys3. The distributor then calls the remoteCommandQ method on the opSysSProcessingPlatform object (step 17), which causes distribution of the modules to be processed across various machines on the network by the protocolABCFileTransfer object. Once the processing is complete, the store() method of projectYProcessingConfiguration is called to store the resuhs of the processing (step 18). Calling the store() method results in calling the storePartQ method of the opSyslLibraryPlatform object for as many parts as were processed, passing one part during each call (step 19). Once all parts have been stored back in the library, project YProcessingConfiguration calls the moveProcessingOutputQ method on the opSys2TargetPlatform object (step 20). This step moves the processed code to the opSys2TargetPIatform for execution. This function is performed by the opSys3ToOpSys2FileTransfer object within the opSys2TargetPlatform object, which may implement a common file transfer mechanism such as FTP. In the project YProcessingConfiguration example, there are multiple target platforms (opSys2 and opSys3). As a resuh, the moveProcessingOutputQ method on the opSys3TargetPlatform is also called (step 21). This step moves the processed code to the opSys3TargetPlatform. This fiinction is performed by the protocolABCFileTransfer object within the opSys3TargetPlatform object, which may implement FTP or another suitable file transfer mechanism. As the similarity of the two examples above illustrate, the fi-amework provides an extremely flexible and poweriiil tool for implementing any number of processing configurations by simply defining objects that implement the features specific to a particular processing configuration. For example, any number of processing tools may be enabled by the framework delegating to their native functions for candidate collection, dependency checking, currency checking, and command assembling, which functions have been encapsulated in a concrete subclass of a framework class. The framework even gives the capability to mix and match between processing tools. Thus, the candidate collection may be from one tool, the dependency checking from a different tool, and so on. The preferred embodiment disclosed herein implements the native fimctions of one tool so that a programmer may use that tool regardless of the platform the code is stored on, the platform on which he or she is processing code, or on which the code will eventually run. This also gives the programmer the possibility of processing source code in a "stand alone" configuration, when detached from the normal programming enviroimient, by simply running the native processing tools of the processing platform. If the processing configuration the programmer has been using in the programming environment delegates to the native processing tools, the programmer will have little trouble converting from the normal programming environment to stand-alone operation. In addhion to enabling a large number of processing tools, the framework allows any combination of platforms to be specified for development, library, processing, and target. Thus, the framework could readily support a programming environment on an Apple Mcintosh platform, with source code stored on a UNIX library platform, with processing on an AIX platform, with Windows 95 as the target platform. The embodiments and examples set forth herein were presented in order to best explain the present invention and its practical application and to thereby enable those skilled in the art to make and use the invention. However, those skilled in the art will recognize that the foregoing description and examples have been presented for the purposes of illustration and example only. The description as set forth is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching without departing from the spirit and scope of the forthcoming claims. For example, while the disclosure herein specifically relates to the processing of source code in a computer programming environment, it is equally within the scope of the invention to process other items, such as documents in a document processing system. Notation There is, as yet, no uniformly accepted notation for communicating object-oriented programming ideas. The notation used in this specification is very similar to that known in the programming industry as Booch notation, after Grady Booch. Mr. Booch is the author of Object-Oriented Analysis and Design With Applications. 2nd ed. (1994), available from The Benjamin/Cummings Publishing Company, Inc. Use of Booch notation concepts within this specification should not be taken to imply any connection between the inventors and/or the assignee of this patent application and Mr. Booch or Mr. Booch's employer. The notational system used by Mr. Booch is more fiiUy explained at Chapter 5, pp. 171-228 of the aforementioned book. The notational system used herein will be explained generally below. Other notational conventions used herein will be explained as needed. A system that is modeled by an object-oriented framework can be represented at a high level of abstraction by a diagram called a top-level class diagram. FIG. 1 of the drawings is an example of a top-level class diagram containing boxes that represent abstractions of the modeled system. The boxes are arranged in a hierarchy such that boxes representing abstractions close to the physical components of the system are at the lower levels of the diagram and boxes representing more abstract, fimctional components are closer to the top of the diagram. In FIG. 1, the boxes are labeled as "mechanisms" to denote that the abstractions comprise means for implementing modeled system IBM Docket "RlSm&Wf- components. The boxes (mechanisms) can be thought of as categories comprising groups of similar classes defined according to object-oriented programming concepts. FIG. 1 represents a zoo administration model and therefore the lower hierarchy boxes include a box called Animal Mechanism, which represents animals within the zoo model, and a box called Containment Unit Mechanism, which represents animal pens and cages. At the highest level of FIG. 1, the box called Zoo Administration represents a functional abstraction that encompasses a variety of administrative tasks that are performed by personnel. The boxes in a top-level class diagram represent the system abstractions that provide the system behavior. The system abstractions include classes and objects. Details of the system classes are provided in a class diagram that is used to show the class categories and to indicate the relationships and responsibilities of the classes. A class is represented by an irregularly shaped, dashed-line icon commonly referred to a cloud. FIG. 2, for example, shows several classes represented as clouds. Each class is identified by a name that is unique to the associated class category and also indicates the relationship of each class to one of the mechanisms illustrated in FIG. 1. Within a class icon, the class name is hsted above attribute names, operation names followed by parentheses, and constraints that are enclosed within brackets. FIG. 3 illustrates the class Zoo Administrator in greater detail. FIG. 3 indicates that the Zoo Administrator class includes multiple operations, including ones called "5_minute_timerO", "add_animalO", and "add_containment_unit()". Words in the operation names (and class attribute names) are separated by an underscore for easier reading. An example of a class attribute listing is shown by the attributes called "feed_fi-eq" and "temp_range" in the class Animals illustrated in FIG. 5. Connecting lines between mechanisms (FIG. 1) and classes (FIG. 2) indicate the nature of the relationships between such respective abstractions. Thus, connections between the boxes in FIG. 1 represent relationships between the various mechanisms. A straight connecting line, for example, represents a simple association relationship indicating shared information. A "using" relationship is a refinement of a simple association whereby one abstraction that is referred to as a server or supplier provides services to another abstraction that is referred to as a client. Such a relationship is indicated by an open circle at one end of a simple association line, the open circle end designating the client that "uses" the associated server. Another refinement of a simple association between two classes is a type referred to as an inheritance relationship. Inheritance is a relationship among classes in which one class shares the structure and/or behavior associated with one or more other classes. An inheritance association is also referred to as a "is a" relationship. Thus, given two classes A and B, the class A has an inheritance relationship with the class B if A is an example of a B; A is said to be a subclass of B and B is said to be a superclass or parent of A. That is, A "is a" B. An inheritance relationship is denoted with a connecting line that includes an arrowhead at one end to indicate a subclass that derives its characteristics firom a parent class at the other end of the line. Another refinement of class relationships is called an aggregation relationship, which denotes an association between a whole and its parts or attribute classes. In notation, an aggregation relationship is indicated between a whole class and an attribute class connected with an association line by a solid circle at the whole class end, with an attribute class at the other end. Another relationship specified by a class diagram is an instantiation relationship. An instantiation relationship represents an instance of a class such as a particular implementation of a class as supported by a programming language. For example, a class called "animal" can have multiple instantiations comprising lions, tigers, and bears. An instantiation of a class is represented by a dashed association line with an arrowhead pointing from an instance of a class to the general class. Finally, a class relationship referred to as a metaclass denotes a relationship in which a class itself is treated as an object that can be manipulated. That is, a metaclass is a class whose instances are themselves classes. Some computer languages, such as Small Talk, support the concept of a metaclass. Such relationships are denoted by a shaded line with an arrowhead pointing from an instance of a metaclass to the general metaclass. Classes can be parameterized, which denotes a family of classes whose structure and behavior are defined independently of its formal class parameters. A parameterized class is represented by a cloud-shaped class icon with a rectangular box placed over a portion of the cloud. The parameter list is named within the rectangular box. An instantiated class includes a parameter box, called an adornment, in contrast to a dashed line box for a general class. The instantiation relationship between a parameterized class and its instantiated class is represented as a dashed line pointing to the parameterized class. Typically, an instantiated class requires a "using" relationship to another concrete class for use as an actual parameter. Properties of classes can be represented by class adonunents that are enclosed within the class cloud icon. In particular, an abstract class is denoted by an upper case block "A" within a triangle that is placed within a cloud. An abstract class is a class for which no instances may be created. That is, it is a class of classes. Other class adornments are functions of the 00 implementation language. For example, the C++ language permits special class qualifications that will be given special adornments. A static class is represented by an upper case block "S" within an adornment triangle, a friend class is denoted by an upper case block "F" within an adornment triangle, and a virtual class is represented by an upper case block "V" within an adornment triangle. In addition to defining classes, a designer of an object oriented programming system must define objects (see page 136 of Booch). Objects are represented as solid line clouds within which is placed the object name located above a list of object attributes. An object is a tangible entity that exhibits a well defined behavior. An object is intended to represent some part of a real system that is being represented by the object oriented program. An object is characterized by a state, a behavior, and an identity. An object can be thought of as an instance of a class. The behavior of an object is an indication of how the object acts and reacts in terms of its state changes and its message-passing actions. Objects and their interrelationships are represented in object diagrams that comprise object icons having links that indicate synchronization between objects. Links are sequentially numbered to indicate the flow of operations. The existence of a link between two objects indicates an association between their corresponding classes and denotes a path of communication between them. Thus, a link between two objects indicates that one object may send messages to another. The direction of message transfer is indicated by adorning a simple connecting line with an arrowhead that points fi-om an object that invokes an operation, referred to as the client, to the object that provides the operation, referred to as the supplier. Such a representation of a simple synchronization relationship denotes the simplest form of message-passing. Such an association can indicate, for example, the invocation of an operation. Operation parameters can be indicated adjacent the linking line. Some objects may be active, meaning that they embody their own thread of control. That is, such objects are not simply sequential. Active objects may have a variety of concurrency characteristics. If an object has multiple threads of control, then synchronization must be specified. Message synchronization can be synchronous, meaning that the client will wait until the supplier accepts the message. Synchronous synchronization is indicated with an "X" with an arrowhead. Synchronization can encompass balking message-passing, meaning that the client will abandon the message if the supplier cannot immediately service the message. Balking is indicated with an arrowhead turned back on itself Synchronization can encompass a time-out synchronization, meaning that the client will abandon the message if the supplier cannot service the message within a specified amount of time. Time-out synchronization is indicated with a clock face representation adjacent a linking arrowhead. Finally, synchronization can encompass an asynchronous message, meaning that the client sends an event to a supplier for processing, the supplier queues the message, and the client then proceeds without waiting for the supplier. Those skilled in the art will appreciate that asynchronous message synchronization is analogous to interrupt handling. Asynchronous message synchronization is indicated with a half arrowhead. It bears mention that the Booch notation includes interaction diagrams that trace the execution of objects and classes. Interaction diagrams are essentially restructured object diagrams. That is, interaction diagrams do not convey any additional information from that conveyed by object diagrams, but simply present the same information in a different format. The present specification makes use of object diagrams rather than interaction diagrams, but those skilled in the art will recognize that they are equivalent and also will understand how to convert firom one to the other without further explanation. In FIG. 7, for example, the object called Zelda 706 obtains a list of current zoo keepers by calling an operation called List Zoo Keepers from the object called Zoo Keeper Register. The second processing step is represented in FIG. 7 by the Zoo Keeper Register object responding to the operation call by passing a message to the Zelda object that comprises the zoo keeper list. The zoo keeper objects include members of the Zoo Keepers class called Tina, Vince, and Fred. The third step indicated in the object diagram is for the object Zelda to pass a message to each of the zoo keepers instructing them to check the animals by calling the respective Check Animals operation of each zoo keeper object. WE CLAIM : 1. A method for processing at least one source code module within a source code program the method comprising the steps of providing an extensible object oriented framework mechanism that performs the processing of the at least one source code module according to extended portions of the framework mechanism that are customized to provide a desired processing configuration; and executing the object oriented framework mechanism on a computer system. 2. The method according to claim 1, comprising the step of extending the framework mechanism to define the desired processing configuration. 3. The method according to claim 1 comprising the steps of: selecting at least one target platform; selecting at least one processing platform; implementing at least one processing tool native to the at least one processing platform by defining the extended portions; and implementing the desired processing configuration by defining the extended portions in accordance with the selected at least one target platform and the selected at least one processing platform. 4. The method according to claim 3 comprising the steps of: selecting at least one library platform; selecting at least one development platform; the step of implementing the desired processing configuration including the step of defining the extended portions in accordance with the selected at least one library platform and the at least one development platform. 5. The method according to claim 4 comprising the steps of: determining an initial set of candidate modules within the source code program; determining a second set of modules within the source code program that are dependent upon the initial set of candidate modules; determining a third set of modules within the source code program, the third set comprising the modules within the second set that are out of date; determining a fourth set of modules that comprise the modules to be processed, and determining a set of commands needed to process the modules within the fourth set. 6. The method according to claim 5 comprising the steps of: distributing the set of commands across a plurality of computer systems; each of the plurality of computer systems processing its respective commands to process the modules within the fourth set. 7. The method according to claim 5, wherein the step of determining the initial set of candidate modules includes the step of creating an initial list of the candidate modules. 8. The method according to claim 5, wherein the step of determining the second set of modules includes the step of creating a dependency list containing all modules within the source code program that may require processing in order to process the candidate modules within the initial list. 9. The method according to claim 5, wherein the step of determining the third set of modules includes the step of creating an out of date list of modules within the dependency list that require processing in order to process the candidate modules within the initial list. 10. The method according to claim 5, further including the steps of storing at least one of the processed modules in a library platform; and moving at least one ofthe processed modules to a target platform of platforms. 11. A method for processing at least one source code module within a source code program, substantially as herein described with reference to the accompanying drawings.

Documents:

575-mas-1997 abstract duplicate.pdf

575-mas-1997 abstract.pdf

575-mas-1997 assigment.pdf

575-mas-1997 claims duplicate.pdf

575-mas-1997 claims.pdf

575-mas-1997 correspondence others.pdf

575-mas-1997 correspondence po.pdf

575-mas-1997 description (complete) duplicate.pdf

575-mas-1997 description (complete).pdf

575-mas-1997 drawings duplicate.pdf

575-mas-1997 drawings.pdf

575-mas-1997 form-2.pdf

575-mas-1997 form-26.pdf

575-mas-1997 form-4.pdf

575-mas-1997 form-6.pdf

575-mas-1997 others.pdf

575-mas-1997 petition.pdf