WO1993015469A1 - Method and apparatus for an object oriented material management system - Google Patents

Method and apparatus for an object oriented material management system Download PDF

Info

Publication number
WO1993015469A1
WO1993015469A1 PCT/US1993/000429 US9300429W WO9315469A1 WO 1993015469 A1 WO1993015469 A1 WO 1993015469A1 US 9300429 W US9300429 W US 9300429W WO 9315469 A1 WO9315469 A1 WO 9315469A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
class
containment tree
facility
data
Prior art date
Application number
PCT/US1993/000429
Other languages
French (fr)
Inventor
James H. Richardson
Anne Richardson
David B. Scott
Francisco J. Pataro
Dena A. Swackhammer
Original Assignee
Genoa3 Partners
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Genoa3 Partners filed Critical Genoa3 Partners
Publication of WO1993015469A1 publication Critical patent/WO1993015469A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders

Definitions

  • the present invention relates to material management systems and, more specifically, to the organization of a material management system in accordance with an object oriented model and the interaction of multiple external systems with a material management system to facilitate the management, storage and handling of physical materials.
  • Conventional material management systems are typically designed and developed using data processing systems and conventional relational and hierarchical database management technology.
  • relational database technology conventional material management systems manage information or records in at least twelve files for relatively small facilities. This is considered to be the minimum number of files required to manage all data corresponding to materials managed in a facility.
  • Each file is stored in the data processing system and corresponds to a different aspect of the particular facility. Examples of files include an 'order' file which contains records corresponding to incoming and outgoing orders, and a 'location' file which contains records identifying locations within the facility that contain material received in and shipped out of the facility.
  • the conventional material management system when a record identifying a new order for material to be shipped is added to the 'order' file, the conventional material management system must locate, access, and update at least one record in the 'location' file to fill the order record added to the 'order' file.
  • two files must be updated to complete a transaction as a result of a single update in one of the files, in order to preserve data integrity between the files.
  • as many as all twelve files must be updated to complete a transaction as a result of a single update.
  • this invention provides for the management of information corresponding to material and relevant operations on material being handled in a facility in an object oriented manner (using a data processing system) by which a system manages "classes” (within the "class categories” of facility, material, company, order, and activity) and instances of each class or objects which form a single treelike structure (the file), called an object containment tree, rather than multiple files of records.
  • the data management system including a data processing system having a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects, methods of adding a new object to, deleting an object from, and modifying an object in the object containment tree are provided, wherein each of the methods is performed by the data processing system.
  • the method of adding a new object to the object containment tree comprises the steps of designating a class of the new object; selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; sending a message to the class of the new object to create the new object; and adding the new object to the object containment tree.
  • the method of deleting an object from the object containment tree comprises the steps of selecting one of the objects in the object containment tree to be deleted; and sending a message to the selected object to delete the selected object from the object containment tree.
  • the method of modifying an object in the object containment tree comprises the steps of selecting one of the objects in the object containment tree to be modified; and sending a message to the selected object to modify at least one of the data values contained in the selected object.
  • a data processing system including an object oriented data management system for maintaining a facility comprising a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for designating a class of the new object; means for selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; means for sending a message to the class of the new object to create the new object; and means for adding the new object to the
  • Figure 1 is a block diagram illustrating the components of an exemplary workstation or platform in which the present invention may be implemented;
  • Figure 2 is an illustration of the major components of a preferred implementation of the present invention
  • Figure 3 is a class category diagram for describing the preferred implementation of the present invention
  • Figure 4 is a facility class diagram for describing the preferred implementation of the present invention.
  • Figure 5 is a material class diagram for describing the preferred implementation of the present invention.
  • Figure 6 is an order class diagram for describing the preferred implementation of the present invention.
  • Figure 7 is a company class diagram for describing the preferred implementation of the present invention.
  • Figure 8 is an activity class diagram for describing the preferred implementation of the present invention.
  • Figure 9 is a database class diagram for describing the preferred implementation of the present invention.
  • Figure 10 is a block diagram illustrating the relationship between the attributes of an object of a class in accordance with the preferred implementation of the present invention.
  • Figure 11 is an example of an object containment tree for describing the preferred implementation of the present invention.
  • Figure 12(a) illustrates a user interface (display screen) for adding a relative cell (or node) representative of an object to the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention
  • Figure 12(b) illustrates a flow diagram for describing an operation of the user interface of Figure 12(a) in accordance with the preferred implementation of the present invention
  • Figure 13 is an example of the object containment tree of Figure 11 after a leaf node is added to the tree in accordance with the preferred implementation of the present invention
  • Figure 14 is an example of the object containment tree of Figure 11 after an intermediate node is added to the tree in accordance with the preferred implementation of the present invention
  • Figure 15(a) illustrates a user interface (display screen) for deleting a relative cell (or node) representative of an object (e.g., material) from the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention
  • Figure 15(b) illustrates a flow diagram describing an operation of the user interface of Figure 15(a) in accordance with the preferred implementation of the present invention
  • Figure 16 is an example of the object containment tree of Figure 11 after a leaf node is deleted from the tree in accordance with the preferred implementation of the present invention
  • Figure 17 is an example of the object containment tree of Figure 11 after an intermediate node is deleted from the tree in accordance with the preferred implementation of the present invention
  • Figures 18(a)-18(c) illustrate a user interfaces (display screens) for modifying a relative cell (or node) representative of an object (e.g., material) from the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention
  • Figure 18(d) illustrates a flow diagram for describing an operation of the user interfaces of Figures 18(a)-18(c) in accordance with the preferred implementation of the present invention
  • Figure 19 is an example of the object containment tree of Figure 11 after a leaf node is modified in accordance with the preferred implementation of the present invention.
  • Figure 20 is an example of the object containment tree of Figure 11 after an intermediate node is modified in accordance with the preferred implementation of the present invention. Detailed Description of the Preferred Implementation
  • This invention is preferably implemented using industry standard workstations (or platforms). A block diagram of an example of such a workstation is illustrated in Figure 1. Those skilled in the art would recognize that the present invention may also be implemented using a variety of micro and mini computers as well as large scale data processing equipment. Those skilled in the art would also recognize that the present invention may also be implemented using a distributed network environment where the preferred implementation of the present invention is distributed on multiple platforms throughout the network. The preferred implementation, which is disclosed hereinafter in functional schematic form, is preferably written primarily in the C++ programming language.
  • a workstation 100 comprising a central processing unit (“CPU") 102, a disk drive 105, a mouse 110, a keyboard 115, and a display 120 having a display screen 122.
  • the workstation 100 may also optionally include other external devices 125, such as a radio data terminals, enhanced video display terminals, and tag printer peripherals.
  • the CPU 102 is comprised of an input/output (I/O) unit 130, a random access memory (“RAM”) unit 135, a display memory unit 140, a video interface circuit (“VIC”) 145, and a microprocessor 150.
  • Display memory 140 is a specialized section of RAM which is used to store bit patterns (pixel data) which are read out by the video interface circuit 145 in an appropriate synchronization with the display beam of the display 120 in order to provide the desired display graphics and text.
  • the disk drive 105 is also conventional and is provided to permit the ready interchange of control and application software and to provide a source of mass storage for the computer system.
  • the mouse 110 of the workstation 100 includes a roller ball 111 and control buttons 112 and 113.
  • the buttons 112 and 113 actuate momentary contact switches (not shown) to generate selection signals and other commands. These switches and signals are well known to those of ordinary skill in the art and, as is also well known, the user moves the mouse 110 along a planar surface, such as a table top, to generate cursor position input commands which are supplied to the CPU 102.
  • the roller ball 111 cooperates with a mechanism (not shown) which converts the movement of the mouse 110 into X-Y signals which are used by the CPU 102 to control positioning of a cursor symbol (not shown) on the display screen 122 of the display 120.
  • the conversion of the motion of the roller ball into x-y commands is also conventional.
  • the keyboard 115 may, for example, replace the activities of the mouse 110 by presetting a number of keys on the keyboard to emulate the positioning function of the mouse 110. Additionally, other keys on the keyboard 115 may replace the functions of the buttons 112 and 113 of the mouse 110.
  • the mouse 110 is used for positioning the cursor on the display screen 122 and for performing other functions described below.
  • the keyboard 115 of the workstation 100 of the preferred implementation of the present invention acts as a means for inputting textual or alphanumeric information into the CPU 102.
  • the display 120 is comprised of a display screen 122 for displaying the graphic and alphanumeric information output from the CPU 102.
  • the display 120 may be a touchscreen display in which commands may be entered into the CPU 102 via the display 120. Such touchscreen displays are also conventional.
  • the preferred implementation of the present invention is comprised of several software components 200 each of which, preferably, resides in the disk 105 of Figure 1. It should be understood that, when the user employs the preferred implementation of the present invention, all or part of the software components 200 of the preferred implementation may be input to the CPU 102.
  • 3 GENOA 210 is the software component of the preferred implementation that enables users to manage, store, and handle material. As discussed in detail
  • GENOA 210 supports inbound order processing, material movement and storage, and resource and facility allocation.
  • the import interface 220 is a software component of the preferred implementation that provides the functions used to import information into the preferred implementation.
  • the processes of the import interface component 220 include receiving information in a first format recognized by particular computer application systems (not shown), and translating the information from the first format into a second format recognizable by the preferred
  • the export interface component 230 provides the functions to export information from the preferred implementation for use with other external computer software applications (not shown), e.g., spreadsheets.
  • the general processes of the export interface 230 include receiving information in a format recognizable
  • the script interface 240 is an interface to externally provided scripts or programs (not shown) .
  • a script is an externally provided program and the script interface 240 allows a user to execute an externally provided script through
  • the database system interface 260 provides the necessary functions for the preferred implementation to communicate with external database systems (not shown) which are used to maintain aspects relating to a material management facility other than the management of material, e.g., management of accounts receivables and payroll.
  • the report system interface 270 provides the necessary functionality to enable the preferred implementation to communicate with standard report writing systems (not shown) which generate customized
  • the GENOA component 210 does not have to be adapted to conform with the style of reports generated for a facility.
  • the preferred implementation may communicate with external devices such as radio data terminals, video display terminals, and X-window terminals (not shown).
  • the preferred implementation communicates with these types of terminals by way of the terminals interface 280.
  • the preferred implementation also includes an optional automated equipment interface component 290.
  • the component 290 provides the preferred implementation with the capability to communicate with automated equipment (not shown) in a facility.
  • automated equipment include automated conveyor systems for moving material in and around a facility and robotic equipment such as automated forklift systems which are also used for moving material etc. in a facility.
  • the preferred implementation is organized using classes, methods, and messages.
  • a class is a template for the creation of objects (which represent the items or instances manipulated by the system) having the characteristics of that class.
  • the term template denotes the fact that the objects (i.e., data items or methods) in each class, share certain characteristics or attributes determined by that class.
  • Objects are created dynamically during system operation.
  • the preferred implementation uses many classes, some of which will be described below.
  • Methods are said to be associated with the classes.
  • messages are "sent" to an object of a class and (depending upon the type of message and the particular methods associated with the class containing the object that received the message) a method is selected from the methods associated with the class of the object, which method corresponds to the message, and the selected method is then executed in connection with the object receiving the message.
  • the message "UPDATE MATERIAL (LOC%)" may be sent to an object of the class material, which object is identified by the parameter LOC in the parentheses to update or modify the material object LOC. Because the object LOC is of the material class, the method associated with the material class for updating a material object is executed.
  • the preferred implementation uses a single class of objects (i.e., the class containment tree) to represent all of the classes of objects used by the preferred implementation
  • the message sent to an object of that class is the method of the class (containment tree) that will be executed.
  • the number of messages used in the preferred implementation is limited to primarily three, namely, ADD, DELETE, and UPDATE. Although other messages are used, the operations associated with the other messages are thought to be analogous to the operations of the preferred implementation corresponding to the at least one of the ADD, DELETE, and UPDATE messages.
  • class diagrams are used to show the structure of a system, including the existence of classes and their relationships in the logical design of a system.
  • the class diagrams (see Figures 4-9) contain many classes. Therefore, a class category model 300 of Figure 3 is used to gain a preliminary understanding of the organization of classes in the preferred implementation of the present invention.
  • a class category is a meaningful way of representing many related or "chunks" of classes sharing certain common characteristics.
  • the class category facility 320 of Figure 3 is composed of the classes locations, containers. capacity cells, movable cells, relative cells, cells, and a containment tree (see Figure 4). Each of these classes will be described below in detail and the common characteristics that make them part of the facility class category 320 will be apparent from that discussion.
  • the preferred implementation of the present invention is modeled in Figure 3 using class categories material 305, company 310, activity 315, facility 320, and order 325.
  • classes in the company class category 310 and classes in the facility class category 320 are said to be "visible" to classes in the material class category 305.
  • This is illustrated in the model 300 of Figure 3 by the directional arrows between the class categories 310 and 320 and the material class category 305. Visibility between classes in class categories is determined by whether a class category imports (or "uses") classes declared as part of another class category.
  • classes in the class category facility 320 use classes from the class categories activity 315, material 305, and order 325.
  • classes in the class category material 305 use classes in the class category order 325 and classes in the class category company 310 use classes in the class category order 325 and material 305.
  • Figure 3 also illustrates several class categories referred to as global class categories because these class categories represent classes visible to all classes in all other class categories that are part of the model 300.
  • the global class categories in the model 300 are labelled "global.” They include GENOA 3 330, CSX 335, AT&T 340, and database 345.
  • the global class categories, except the class category 345 represent classes of tools available to all other classes in the class categories of the model 300. Examples of classes of tools included in some of these global class categories are mathematical function tools that can be used by the preferred implementation to execute mathematical operations during system operation.
  • the class category database 345 will be explained in further detail below.
  • the class category facility 320 is composed of the following classes illustrated in Figure 4: location 410, container 415, capacity cell 420, movable cell 425, relative cell 430, cell 435 and containment tree 440. It should be understood that the rectangle surrounding a class name indicates that it is an exported class for use in at least one other class category. Further, the term "class containment tree” should be distinguished from the term "object containment tree” which is used, for example, to describe the object containment tree 1100 of Figure 11, which will be explained in detail below.
  • class category container 417 is illustrated in the class container 415
  • class category capacity cell 422 is illustrated in the class capacity cell 420
  • class category movable cell 427 is illustrated in the class movable cell 425.
  • Figure 4 also includes two additional classes, namely, the class location database item 450 and the class container database item 460.
  • classes 450 and 460 are illustrated in Figure 4, they are not part of the facility class category 320. Rather, they are imported from another class category. In other words, classes 450 and 460 are used to connect the classes of the facility class category 320 with other class categories.
  • This is illustrated in Figure 4 by underlining the legend for the class location database item 450 and the legend for the class container database item 460. For example, looking at Figure 9 it can be seen that the classes 450 and 460 of Figure 4 are imported from the global class category database 345 of Figures 3 and 9.
  • the class location 410 is a kind of" (or a specialization of) the class capacity cell 420.
  • the class container 415 "is a kind of” the class capacity cell 420 and the class container 415 is also a "kind of” the class movable cell 425.
  • the classes capacity cell 420 and movable cell 425 are each "a kind (or specialization) of" the class relative cell 430 and the class relative cell 430 is, in turn, a kind of the class cell 435. This is an example of an inheritance chain that will be discussed below.
  • class container 415 which is a specialization of the class container database item 460 of the global class category database 345 of Figure 3 and the class location 410 which is a specialization of the class location database item 450 of the global class category database 345 of Figure 3.
  • Inheritance may be defined as a relationship among classes, wherein one class shares the structure or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. Inheritance is said to define a relationship between classes in which a "subclass” inherits from one or more "superclasses”; a subclass augments or further defines the existing structure and behavior of its superclass. A subclass, therefore, has all the characteristics or attributes (e.g., physical record structure including any data fields and pointers as well as references to relevant methods capable of operating on objects in the class) of its superclass plus one or more additional characteristics.
  • characteristics or attributes e.g., physical record structure including any data fields and pointers as well as references to relevant methods capable of operating on objects in the class
  • the class location 410 is a subclass of the class capacity cell 420 (a superclass of the subclass location 410) that represents (or has the characteristics of a physical (or logical) volume of space at a specific position within the facility. Objects in the class location 410, therefore, have all the characteristics of objects in the class capacity cell 420 plus the added characteristics or attributes particular to objects of the class location 410 (explained below). As discussed below, in the class containment tree 440, a location object may contain other location objects, container objects, or material item objects.
  • class location 410 is a superclass of the subclass location 410 and, therefore, objects in the class location 410 have the structure corresponding to the attributes of objects in the class capacity cell 420 plus the added structure corresponding to the attributes of objects particular to the class location 410.
  • class location database item 450 is a superclass of the class location 410 (the subclass)
  • container database item 460 is a superclass to the class container 415 (the subclass)
  • capacity cell 420 is a superclass of the subclass container 415
  • movable cell 425 is also a superclass to the subclass container 415.
  • the class relative cell 430 is a superclass of both the capacity cell 420 and the movable cell 425.
  • the class cell 435 is a superclass to the class relative cell 430.
  • the class relative cell 430 is, therefore, said to inherit all the attributes of all of its superclasses.
  • the "has a” or “uses” relationship between classes is illustrated in Figure 4 with a double line with a circle at one end connecting classes (or connecting to the same class, e.g., the connection of the class relative cell to itself).
  • the "uses” relationship signifies that the class at the end of the double line having the circle "uses" the class at the opposite side of the double line.
  • the class containment tree 440 is said to "use” the class relative cell 430 (and the class relative cell 430 uses the class relative cell 430). This means that objects in the class containment tree 440 interface with or "use” the objects in the class relative cell 430.
  • the class containment tree 440 in the facility class category 320 is a tree structure in which each- node represents a relative cell object. This one-to- one relationship between an object of the class relative cell 430 and an object of the class containment tree is illustrated in Figure 4 with the principle cardinality depicted by the "1" next to each end of the "uses" connection (double line) between the class relative cell 430 and the class containment tree 440.
  • a containment tree represents the complete containment of child cells by parent cells.
  • the class relative cell 430 represents the class cell 435.
  • the class relative cell 430 also "uses" the class relative cell 430.
  • a relative cell object is completely contained within a parent relative cell object and has a specified position relative to the parent cell object. The position of the relative cell object with respect to its parent may be changed.
  • the class relative cell 430 inherits from the class cell 435, as explained above.
  • Objects said to be a part of the location class 410 have certain common characteristics.
  • a location object (not shown) in the class location 410 represents a fixed volume of space at a known position in a facility. Locations (objects in the class location 410) may contain other locations, containers, or material.
  • the location class 410 inherits from the following chain of classes: capacity cell 420, relative cell 430, and cell 435. The location class 410 also inherits from the location database item class 450 of the global database class 345 of Figure 3.
  • a model of a facility or a containment tree can be built by identifying a hierarchy of locations (or which locations in the facility contain other locations) .
  • the top location represents the totality of all locations managed by the preferred implementation. Thus, the top location might be a corporation with many warehouses, a single marshaling yard, or the finished goods section of a warehouse.
  • a warehouse might be identified as the "top" or highest location.
  • the warehouse might be divided into four zones, so four more locations might be specified, one for each zone contained in the warehouse.
  • Zone 1 of the four zones might contain six aisles, so six more locations would be identified as contained in Zone 1. This process continues until all individual locations where containers or material can reside have been identified.
  • classes are templates for the creation of objects.
  • Objects of a class have particular characteristics defined by the class.
  • Each container object (not shown) in the container class 415 like a location object, represents a fixed volume of space at a known position. Unlike a location object, however, a container object can be moved from one location to another in the facility.
  • Container objects may contain location objects, other container objects, or material item objects as will be explained below.
  • Location objects and container objects share certain common attributes in the preferred implementation.
  • each can define any number of ports.
  • a port is an area on the surface of a location object or a container object through which material item objects can arrive and/or leave the location or container object.
  • location objects and container objects can be set to adjust automatically their quantity of a given material type (to be discussed below) based upon specified events.
  • An example of a port might be a simple shelf location in the facility which may be used as a single port where material items both arrive and leave the facility.
  • ports are flow-through racks where material items arrive in one end of the port and leave through another end of the port, a sorter where material items arrive in one end of the sorter and leave through other ends of the sorter after being sorted (e.g., for color, weight, etc.) and packing stations where material items arrive for packing and leave packed (e.g., in containers).
  • An example of the port capable of being adjusted for different quantities of material items is a replenishment location in the facility. In replenishment locations, when the quantity of a given material type at the location falls below a predetermined quantity (called the event), the location finds some suitable material items in the facility and creates tasks to transfer the material items to itself.
  • the class container 415 in Figure 4 represents the template for container objects.
  • Each container object (not shown) of the class container 415 is a particular type of capacity cell (object of the capacity cell class 420) that represents a physical (or logical) volume of space at a specific position within the material management facility.
  • a container object within the class container 415 can contain location objects, other container objects, or material item objects (not shown) .
  • a container object may be contained in a location object or another container object, and is movable from one location object or container object to another.
  • the class capacity cell 420 represents the class cell 435.
  • a capacity cell object may contain relative cell objects, subject to capacity limits, and other defined restrictions.
  • the class capacity cell 420 inherits from the class relative cell 430, and the class cell 435.
  • the class movable cell 425 represents the class cell 435.
  • a movable cell object may be moved from one parent capacity cell object to another.
  • the class movable cell 425 inherits from the class relative cell 430 and the class cell 435.
  • class cell 435 is a rectangular parallelepiped of fixed dimensions.
  • the classes that compose the class category material 305 are illustrated in Figure 5.
  • the class category material 305 is comprised of the classes material 505, material definition 510, material locator 515, and lot 520.
  • the other classes shown in Figure 5 include the movable cell 425 (see Figure 4), the material definition database item 530, the lot database item 535, and the material database item 540.
  • the class material definition 510 is a template for objects (not shown) containing all the information needed to define a type of material (e.g., part number, description, weight, standard package sizes, qualified suppliers, etc. ) As explained above with reference to Figure 5, the class material definition inherits from the class material definition database item 530.
  • This class 530 is a class within the global class database 345 (see Figure 3), explained below with reference to Figure 9.
  • the class material 505 is a template for objects (not shown) containing information identifying a given quantity of a specific material definition object (not shown) and occupies a fixed volume of space at a known position.
  • the class material 505 inherits from the chain of classes movable cell 425 ( Figure 4), relative cell 430, cell 435. Finally, as explained above, the class material 505 also inherits from the material database item 540.
  • a material object of the class material 505 is recognized as soon as it appears on an inbound order. It is then tracked from its point of origin into the facility, put away for storage, picked to fill an outbound order, shipped by way of a transportation carrier and finally removed from the system. Any combination of these steps can be used.
  • the class material locator 515 represents a template for objects (not shown), wherein each object of this class is an index for locating all material item of a given material type.
  • the class lot 520 is an optional class and is provided for facilities where lot control or lot tracking disciplines are required.
  • a lot object (not shown) of the class lot 520 contains all the information needed about any one manufacturing lot of a given material (e.g., vendor, lot ID, date code, material definition, list of material from the lot, etc. ) .
  • the class movable cell 425 is imported (underlined legend) from another class category, namely, the facility class category 320 explained with Figure 4.
  • the classes material definition database item 530, lot database item 535, material database item 540, and company 545 are also imported from other class categories. Therefore, these classes will not be explained in detail with reference to Figure 5, rather these classes will be explained in detail with reference to each of the class categories from which each of these classes is imported for use in connection with the classes of the class category material 305. At this point only the relationship between these imported classes and the classes of the class category material 305 will be discussed.
  • the inheritance of classes in Figure 5, like those in Figure 4, is illustrated by way of the directional lines (arrows).
  • the class material definition 510 inherits from the class material definition database item 530 (an imported class), the class lot 520 inherits from the class lot database item 535 (an imported class), and the class material 505 inherits from the class material database item 540 (another imported class) and the class movable cell 425 (another imported class) .
  • the class material locator 515 "uses” the class material 505. As shown by the cardinality of this "using” relationship, or the "1" above the side of the double line near the circle (connecting the double line with the class 515) and the "*" above the other end of the double line connecting the double line with the class 505, each object (not shown) in the class material locator 515 uses zero or more objects (not shown) from the class material 505.
  • the class material locator 515 uses the class material definition 510 with a cardinality for this relationship of one-to-one (represented by the "1" above either end of the double line connecting these classes). That is, each material locator object (not shown) of the class material locator 515 uses or interfaces with an object from the material definition class 510.
  • the class material 505 uses the class material definition 510 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more material objects (not shown) of the class material 505 interface with one of the objects (not shown) from the material definition class 510.
  • the class material 505 uses the class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more material objects (not shown) of the class material 505 interface with zero or more objects (not shown) from the class company 545.
  • the class material 505 also uses the class lot 520 with a cardinality for this relationship of zero or more to zero or one (represented by the "*" above one end of the double line connecting these classes and the "?” above the other end) .
  • zero or more material objects (not shown) of the class material 505 interface with zero or one object (not shown) from the class lot 520.
  • the class material definition 510 uses the class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more material definition objects (not shown) of the class material definition 510 interface with zero or more objects (not shown) from the class company 545.
  • the class lot 520 uses the imported class company 545 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes).
  • zero or more lot objects (not shown) of the class lot 520 interface with one of the objects (not shown) from the class company 545.
  • Figure 6 illustrates the classes of the class category order 325 ( Figure 3).
  • the classes of the class category order 325 are used to model inbound and outbound orders for a material management facility.
  • the class category order 325 is comprised of the classes order 605, order directory 610, and order item 615.
  • the class order is comprised of the class category order 607 and the class order item 615 is comprised of the class category order item 617.
  • the class order 605 is used as a template to create order objects (not shown) .
  • An order object is a uniquely identified list of order items (discussed below), including common information about the source and destination of those items.
  • the class order 605 inherits either from the imported classes capacity cell 420 (which inherits from the class relative cell
  • class order item 615 inherits from the class material 505
  • the order item class 615 inherits (via the class material
  • Each object of the class order item 615 represents a quantity of a given material definition.
  • the class order 605 uses the imported class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more order objects (not shown) of the class order 605 interface with zero or more objects (not shown) from the class company 545.
  • the class order directory 610 uses the class order 605 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each material order directory class object (not shown) of the class material order directory 610 uses or interfaces with an object from the order class 605.
  • the order class 605 also uses the class order item 615 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes).
  • zero or more order item objects (not shown) of the class order item 615 interface with one of the objects (not shown) from the order class 605.
  • the class category company 310 ( Figures 3 and 7) is composed of the classes company 710 ( Figure 7), company directory 715 and company database item 720. As illustrated in Figure 7, the class company 710 inherits from the imported class company database item 720.
  • the class company directory 715 uses the class company 710 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes) . That is, each company directory class object (not shown) of the class company directory 715 uses or interfaces with an object from the company class 710.
  • the company class is used to record information about any entity with whom the material management facility does business.
  • the company class 710 may represent other companies, other divisions of the same company, plants, individuals, and the like.
  • the company class 710 may also represent sources, destinations, manufacturers, consignees, etc.
  • the class category activity 315 is composed of the classes human 810, fork truck 815, AGV 820, agent 825, task 830, and transaction 835.
  • the classes transaction 835, task 830, and agent 825 represent objects that are considered to be proactive, concurrent units of work that drive the preferred implementation of a material management system.
  • users or other systems generate transaction objects (e.g., automated equipment) of the class transaction 835 and transaction objects create task objects of the class task 830 that are subsequently carried out by agent objects of the class agent 825.
  • a transaction object (not shown) of the class transaction 835 represents an atomic unit of work from an application point of view. For example, placing an order, receiving an order, picking a set of orders and shipping an order are all transactions. Transactions initiate all activity in the preferred implementation of the present invention and can be generated by users, other systems and automated equipment.
  • a task object (not shown) of the class task 830 represents a request to relocate a container or material item, or to verify the quantity of a material item.
  • Task objects can be generated directly by the user, from transaction objects, or generated automatically by the preferred implementation of the present invention. The user can also dynamically manage all task objects at all times.
  • the agent object (not shown) of the class agent 825 represents a person or piece of equipment that can carry out a task.
  • Human objects (not shown) of the class human 810, fork truck objects (not shown) of the class fork truck 815 (e.g., cranes with operators), automatic guided vehicle objects (or AGV objects) of the class AGV 820 are all examples of agent objects.
  • an agent looks for an available task and picks one based on, for example, capability, priority, location, weight, and size, as specified by the user.
  • the agent then carries out the selected task and notifies the preferred implementation of the present invention when it is completed.
  • the imported classes illustrated in Figure 8 include the class capacity cell 420 (see Figure 4), the movable cell 425, and the agent database item 845 (see Figure 9). These imported classes are illustrated with the classes of the class category activity 315 to show how that class category relates to other classes in other class categories.
  • the class human 810 is a subclass of the superclass agent 825.
  • the class fork truck 815 is a subclass of the superclass agent 825 and the class AGV 820 is a subclass of the superclass agent 825.
  • the class agent 825 inherits from the class agent database item 845.
  • the class agent 825 is also a subclass to the superclasses capacity cell 420 and movable cell 425.
  • the class task 830 is a subclass to the superclass task database item 840.
  • the classes 840 and 845 will be explained in further detail below.
  • the agent class 825 uses the class task 830 with a cardinality for this relationship of zero or one to zero or one (represented by the "?" above both ends of the double line connecting these classes). In other words, zero or one agent object (not shown) of the class agents 825 interfaces with zero or one object (not shown) from the class task 830.
  • the task class 830 uses the class movable cell 425 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more task objects (not shown) of the class task 830 interface with one of the objects (not shown) from the imported class movable cell 425.
  • the task class 830 also uses the class capacity cell 420 with a cardinality for this relationship of zero or more to zero or one (represented by the "*" above one end of the double line connecting these classes and the "?” above the other end). In other words, zero or more task objects (not shown) of the class task 830 interface with zero or one object (not shown) from the class capacity cell 420.
  • the transaction class 835 uses the class movable cell with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more transaction objects (not shown) of the class transaction 835 interface with one of the objects (not shown) from the class movable cell 425.
  • the class transaction 835 also uses the class capacity cell 420 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes) .
  • zero or more task objects (not shown) of the class transaction 835 interface with one of the objects (not shown) from the imported class capacity cell 420.
  • the database global class category 345 ( Figure 3) is composed of the classes note 905, current status 910, classification 915, master database item 920, master note category 925, master classification 930, item note category 935, ⁇ X> database item 940, item classification category 945, and status state machine 950.
  • the " ⁇ X>" may be replaced by any of the following: agent, company, container, location, lot, material, material definition, order, order item, and task, as illustrated by way of the legend included in the class category 345.
  • each database item (or object of a class within the class category 345) represents a list of allowable status values that may be defined by the user. For example, locations might have status values of available, reserved, in-use and out-of- service, while material items might have status values of on-order, available, reserved, on-hold and return- to-vendor.
  • User defined status transition rules may be established to allow and disallow certain status transitions for the item based on its status.
  • classification categories as desired may be set up by the user and a selection of these categories applied to any database item.
  • the classification category "storage temperature” might include values of frozen, cold, ambient, and heated. The storage temperature classification might apply to both material items and locations.
  • a "hazardous material” category might include classifications of explosive, flammable, volatile, and safe. This category could apply to locations, containers, material items and agents. More complex classification schemes can also be used. For example, a hierarchical organization chart might be used to classify the ownership of material items, containers or locations.
  • the class note 905 uses the class item note category 935 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each note object (not shown) of the class item note category 935 uses or interfaces with an object from the class note 905.
  • the class classification 915 uses the class item classification category 945 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each classification object (not shown) of the class classification 915 uses or interfaces with an object from the class item classification category 945.
  • the class master database item 920 uses the class master note category 925 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes).
  • zero or more master note category objects (not shown) of the class master note category 925 interface with one of the objects (not shown) from the class master database item 920.
  • the class master database item 920 uses the class note 905 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). That is, zero or more note objects (not shown) of the class note 905 use or interface with an object from the master database item 920.
  • the class master database item 920 uses the class current status 910 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each current status object (not shown) of the class current status 910 uses or interfaces with an object from the class master database item 920.
  • the class master database item 920 uses the class classification 915 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more classification objects (not shown) of the class classification 915 use or interface with an object from the master database item 920.
  • the class master database item 920 uses the class master classification category 930 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes).
  • zero or more classification objects (not shown) of the class classification 915 use or interface with an object from the master database item 920.
  • Figure 9 also illustrates that the class item note category 935 uses the class master note category 925 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each master note category object (not shown) of the class 925 uses or interfaces with an object from the class item note category 935.
  • the class ⁇ X> database item 940 uses the class item note category 935 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes); the class ⁇ X> database item 940 uses the class item classification category 945 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes); and the class ⁇ X> database item 940 uses the class status state machine 950 with a cardinality for this relationship of one-to-one (represented by the "1" above either end of the double line connecting these classes) .
  • the GENOA global class category 330, the CSX global class category 335, and the AT&T global class category 340 each contains general purpose math and data structure classes, as is known to those of ordinary skill in the art.
  • objects of classes are represented, in a data processing system, by using objects of the class relative cell 430 ( Figure 4). That is, attributes corresponding to the class relative cell 430 are used to represent all objects of the classes managed by the preferred implementation.
  • a class is a template for the creation of objects. Associated with each class is a set of one or more attributes that are considered part of the template used to create objects of the class. Methods are also associated with classes. Objects of a class have specific (or unique) data values corresponding to the attributes of the class template. Objects of a class also have appropriate references (or pointers) to identify the methods associated with the class that may be performed on the objects of the class. The specific data values are sometimes referred to as the attributes of the object of a class. An example of this is illustrated in Figure 10.
  • the attributes 1020 are associated with the class relative cell 430 and each object (not shown) of the class relative cell 430 would have specific data values or attributes for each of the attributes of the class relative cell 430.
  • the methods 1025 are also associated with the class relative cell 430. This means that a relative cell object (not shown) would contain an appropriate reference or pointer to the methods 1025 to permit the methods 1025 to be performed on the relative cell object.
  • the attributes 1030 are associated with the class " ⁇ name>" 1040.
  • " ⁇ name>” is used to illustrate that any class name discussed above with reference to Figures 4-9 may be used in place of " ⁇ name>".
  • " ⁇ name>” is a variable and can be replaced by, for example, "location” or "container”. In the case where " ⁇ name>” is replaced by "location”, the attributes 1030 would the be the attributes for the class location 410.
  • the methods 1035 are also associated with the class " ⁇ name>" class 1040.
  • the object 1050 is a label for the object 1060. Again, “ ⁇ name>” is variable. Thus, if “ ⁇ name>” is "location,” then the object 1060 would be an object of the class location 410 ( Figure 4).
  • the object 1060 is comprised of data values (or attributes) corresponding to the attributes 1020 of the class relative cell 430 and the data values (or attributes) corresponding to the attributes 1030 of the class " ⁇ name>". This is illustrated in Figure 10 by blowing up the attributes 1070 and 1080 of the object to be represented by the attributes 1020 and 1030, respectively.
  • the object 1060 also includes pointers (or references) 1082 and 1084 to reference the methods 1025 and 1035 of the classes relative cell class 430 and " ⁇ name>” class, respectively.
  • the preferred implementation performs functions by sending messages to objects and, based on the particular message and the methods referenced by the receiving object, an appropriate method is selected from among the referenced methods to be performed on the object.
  • the object 1060 also includes attributes and method references 1090 that are values and pointers to methods corresponding to global classes that are templates for all objects.
  • the attributes of these global classes include parent object reference, which is a pointer to the parent object of the object 1060 and a children object list, which is a set of pointers to the objects that are called children of the object 1060.
  • attributes of the class relative cell 430 include size, weight, capacity size, capacity weight, list of classification categories with one classification each, list of note categories with one note each, and current state and state machine (including state transition rules).
  • the methods for the class relative cell 430 include create relative cell, destroy relative cell, select classification, deselect classification, add note, update note, delete note, add classification category, remove classification category, add note category, remove note category, read order classification categories, read order note categories, read order state machine, read current notes, read current classifications, set parent, remove parent, read parent, set offset in parent, read offset in parent, set children, add child, remove children, remove child and read children.
  • a location object 1060 would therefore include attributes corresponding to the attributes 1020 of the relative cell class 430, the attributes of the location class 1030, references to the methods 1025 of the relative cell class, and references to the methods 1035 of the location class.
  • the location object 1060 would also include attributes corresponding to global class characteristics and references to global class methods.
  • the preferred implementation constructs a model (or object containment tree) of a material management facility.
  • An object is said to be "contained” by its parent, or a parent object is said to contain one or more child objects.
  • the model is comprised of parent objects and children objects and is used to manage (or handle) information representative of the facility and the activities or work being performed in the facility.
  • the object containment tree begins with an object of the class containment tree 440 ( Figure 4). This object is unique. It is the only object in an object containment tree that is comprised only of a pointer to the first or root object in the tree.
  • Figure 11 illustrates an example of an object containment tree, i.e., object containment tree 1100, that is called Representative Warehouse Model. The object containment tree 1100 will be used to describe the functions of the preferred implementation.
  • the object containment tree 1100 represents a single file containing all of the information (stored in a data processing system of the type illustrated in Figure 1) required to maintain a material management facility.
  • an object containment tree is comprised of one or more objects. It may therefore be said that the preferred implementation manages objects of the type described above.
  • the objects in the object containment tree 1100 are different and contain data values corresponding to the class attributes as discussed above.
  • the objects also obey the rules of inheritance among classes as discussed above.
  • a facility is modeled using objects of the following classes: containment tree 440 ( Figure 4), relative cell 430, location 410, container 415, material 505 (Figure 5), order 605 ( Figure 6), order item 615, and agent 825 ( Figure 8).
  • objects have unique sets of data values.
  • the containment tree object 1102 is at the top of the tree 1100. As discussed above, this object 1102 is unique from other objects in that its only attribute is a pointer to a root object. Because the location of the containment tree object 1102 is predetermined, the object 1102 permits the preferred implementation to locate the root object of the object containment tree.
  • the object 1105 is, therefore, referred to as the "root object. "
  • the object 1105 is a location object having attributes corresponding to the attributes of the relative cell class 430 and the location class 410 as well as global attributes common to all objects.
  • the attributes of the object 1105 corresponding to these global attributes are the parent reference and child references. That is, the parent reference identifies the tree object 1102 as the parent of the location object 1105, and the child references identify objects 1110, 1115, and 1120 as objects that are children to (or are contained in) the object 1105.
  • This parent- child relationship between the objects in the example tree 1100 is illustrated using lines having arrows on either end of the line.
  • the unique data values of the object 1125 are "Carton 111".
  • the object 1150, which is a material object contains the data values "1 ea Socks”. This means that the object 1150 represents a material (in a container (see object 1130) in a receiving dock (see object 1110) of a warehouse (see object 1105)): one each of socks.
  • the object 1135 which is an order object.
  • the order object 1135 contains a reference to its parent object 1115 and references to its children, objects 1165, 1170, and 1175, as well as the unique data values "Acme P.O. #014".
  • the unique data in order 1135 represents an order placed by "Acme” and has an order number "014".
  • Objects 1125, 1150, and 1135 are merely examples used to illustrate the example object containment tree 1100 and to explain, in general, the tree structure and the relationship between the objects in the tree 1100. The other objects in the tree 1100 may be easily understood in light of these examples.
  • the preferred implementation provides for the processes used to add nodes (or objects) to an object containment tree, delete nodes from an object containment tree, and modify nodes of an object containment tree. These processes will now be explained with reference to the object containment tree 1100 of Figure 11.
  • operations or processes used to manage a facility are initiated by users by way of input interfaces or windows generated on the display screen 122 of the display 120 ( Figure 2). How windows are generated on the display screen 122 is conventional and, therefore, will not be described below.
  • the preferred implementation uses a commercially available software package such as "Interviews", along with certain modifications to follow the "Motif" standard, to implement the windows described below.
  • FIG. 12(a) illustrates an example window generated by the preferred implementation that is used to add an object of the class material 505 ( Figure 5) to the object containment tree, for example, the object containment tree 1100.
  • the field 1201 shows the title of the window.
  • the field 1202 includes a prompt "Quantity," and an enterable field (illustrated using the empty rectangle directly to the right of the prompt).
  • An enterable field is an area on the screen in which the user may enter variable information (or data values) or, in the case of an existing material object in the object containment tree, where data values already attributes of a material object may be displayed.
  • the field 1203 is comprised of the prompt "Material ID," and enterable field, and a browser.
  • the browser is illustrated in Figure 12(a) by the "gadget” next to the enterable field of the field 1203.
  • Gadgets are areas of a display screen that represent an operation or function that may be performed in connection with information on the display screen.
  • the gadget of field 1203 represents a browse function that may be used by the user to browse through a list of, for example, material identifications, to select the material identification to be entered in the enterable field of field 1203.
  • the field 1204 is comprised of a prompt "Material” and a nonenterable field " ⁇ Material>” which represents a generated material name looked up by the system.
  • the field 1205 includes a prompt "Status," an enterable field and list gadget. A default for this enterable field comes from a state machine and the list gadget is used to scroll through a list of possible states to be selected for the enterable field of field 1205.
  • the field 1206 is comprised of a prompt "Manufacture Date,” and an enterable field.
  • the field 1207 includes a prompt “Lot ID,” an enterable field, and a browser.
  • the field 1208 includes the prompt “Serial #” and an enterable field.
  • the field 1209 includes a prompt "Inventory” and framed buttons. Buttons in windows are used to make selections between choices shown on the display screen. Unlike gadgets, these buttons do not perform functions. Rather, they are used to signify a condition (yes or no).
  • the field 1210 is the label for a frame containing fields 1211 and 1212.
  • Field 1211 includes the prompt "Located in,” and enterable field, and a tree browser.
  • the tree browser permits the user to browse through (or traverse) the object containment tree to identify a parent object (in the enterable field) in which, for example, the material object to be added is said to be contained.
  • the field 1212 includes a set of label prompts "Located At,” “quantity,” “U of M, " "x-offset,” “y-offset,” and “z- offset” as well as enterable fields for the offsets followed by list gadgets.
  • the field 1213 includes a fixed label for a frame of fields containing several prompts, enterable fields, and list gadgets.
  • the field 1214 is a labeled frame "Classification" which contains the field 1215.
  • the field 1215 includes a labeled list of prompts, enterable fields with list gadgets, and a scroll bar.
  • the field 1216 is another labeled frame "Note” which contains the field 1217.
  • the field 1217 is comprised of a labeled single list of note categories which represents the types of notes which could be added to each object.
  • the window illustrated in Figure 12(a) also includes several gadgets 1218, 1219, 1220, 1221, and 1222.
  • the gadget 1218 is labelled “Edit Note.” This gadget is pushed (using the button on a mouse) to instruct the preferred implementation to edit the note.
  • the gadget 1219 is labelled “Schedule” and is pushed (using the button on a mouse) to instruct the preferred implementation to schedule an "Add” for a later time.
  • the gadget 1220 is labelled “Add & Next” and is pushed (using the button on a mouse) to instruct the preferred implementation to add the object and return to the same screen, ready to add the next object.
  • the gadget 1221 is labelled “Add” and is pushed (using the buttons on a mouse) to instruct the preferred implementation to add a material object, including the data values of the enterable fields, described above, to the object containment tree.
  • the gadget 1222 is labelled “Cancel Current” and is pushed (using the button on a mouse) to instruct the preferred implementation to cancel the current "Add” message.
  • the preferred implementation adds objects to the object containment tree in accordance with the steps illustrated by the flow diagram of Figure 12(b).
  • the user selects the add object option of the system (step 1250) by pushing (using the buttons or a mouse) the gadget labelled "Add" of the screen shown in Figure 12(a).
  • the user uses the enterable field for the Located In prompt (and the associated tree gadget) included in an appropriate window, for example, the window of Figure 12(a) to start at the root of the object containment tree and traverses the tree until the existing object in which the new object is to be contained is found (step 1255).
  • the existing object is said to be the parent of the new object.
  • the attribute for "located in” of the existing object is saved by the preferred implementation (step 1260). This attribute is a reference pointer to the parent object of the new object.
  • the user enters data values for the new object into the enterable fields of the window (step 1265).
  • the data values become parameters (including the location of the parent object corresponding to the Located In enterable field) for a message.
  • the user pushes the Add gadget of the window to instruct the preferred implementation to send the add message to the class of the object to be added to the object containment tree (including the data values for the new object as parameters) (step 1270).
  • the class then receives the add message and creates an object of the class type (e.g., material object) (step 1275). Finally, the attributes of the newly created object are set using the parameters of the add message (step 1280).
  • object of the class type e.g., material object
  • the steps 1270 through 1280 may also be understood as comprising the step Call Add Operation.
  • the Add Object function of the preferred implementation is initiated by calling the add function (method associated with a selected class).
  • the Add Object function then creates an object of the class identified in a parameter of the call and sets the data values of the newly created object using other parameters from the function call.
  • the parent-child relationship between the new object and existing objects in the object containment tree is established using the located-in parameter of the function call.
  • an object 1310 of the type material class is added to the tree 1100 shown in Figure 11. That is, using the process outlined in steps 1250-1280 of Figure 12(b), the user can add the material object 1310 by entering the data into a window, traversing the tree to locate where the new object is to be added (or identify the parent cell 1125) and add the new object to the tree 1100. In this example, the new object is added as a leaf node of the parent 1125.
  • the new object 1410 in this case is contained in the parent cell 1115.
  • the preferred implementation also provides the function of deleting objects from an object containment tree.
  • This function includes generating an appropriate user interface (window) for the user to identify the object(s) to be deleted from the object containment tree and then physically deleting identified object(s) from the tree.
  • the deletion of objects will also be explained with reference to the example object containment tree 1100. Illustrations of deleting a leaf node and an intermediate node from the object containment tree 1100 will also be illustrated.
  • the user interface for the delete process of the preferred implementation is illustrated in Figure 15(a). Like the window for the add process explained in detail above, the window for the delete process also includes prompts, enterable fields, and gadgets.
  • the window 1500 illustrated in Figure 15(a) is an example of the window used to delete an object of the class material from the object containment tree.
  • the field 1501 is the title of the window and identifies this window as the Select Material window.
  • the field 1502 is comprised of fixed labels Material ID, Material, Located In and Status.
  • the field 1503 is called a multiple selection list of Material. This means that multiple material items may be selected for simultaneous deletion.
  • the field 1503 also includes a scroll bar.
  • the field 1504 is a gadget labelled "Select All” that is used to identify or mark all relative cell structures (each corresponding to a relative cell object and a material object) listed in field 1503 to be deleted. To identify specific relative cell objects (material objects), the user depresses a mouse button which highlights the particular object.
  • the field 1505 is a gadget labelled "Clear All.” In contrast to the gadget 1504, gadget 1505 clears all marked material objects so that no objects are marked for deletion.
  • the field 1506 is a gadget labelled "Export” and is used to export data to other computer systems.
  • the field 1507 is a gadget labelled "View” and is used to display data for the selected objects on the display screen 122.
  • the field 1508 is a gadget labelled "Delete” and is pressed using the button on a mouse to initiate the delete process explained below.
  • the field 1509 is a gadget labelled “Update” and is used to modify data of the selected objects.
  • the field 1510 is a gadget labelled "Cancel” and is used to cancel the current message.
  • the user To delete an object from the object containment tree, the user first selects the Delete option from the main menu bar (not shown) (step 1550). In a manner similar to that used in the add object process described above, the user then traverses the object containment tree to identify the object to be deleted (step 1555). The location of the object to be deleted is then saved (step 1560).
  • the user presses the delete gadget 1508 to initiate the delete process which begins by sending the delete message to the object to be deleted (step 1565).
  • the message includes the location of the object saved in step 1560.
  • the object then receives the message sent in step 1565 (step 1570) and performs the method of the class referenced by the object to delete itself from the object containment tree (step 1575).
  • the delete method of all classes is performed by deleting the reference (or attribute) in the identified object (to be deleted) to its parent cell and releasing the memory allocated to it back to the operating system. This has the effect of deleting the relative cell from the object containment tree.
  • Figures 16 and 17 illustrate examples of the object containment tree 1100 of Figure 11 after deleting a leaf node 1145 ( Figure 16) and an intermediate node 1130 ( Figure 17).
  • the object (or leaf node) 1145 is illustrated with hatching to represent that the object 1145 has been deleted from the object containment tree 1100 (using the process outlined above with reference to Figure 15(b)) by eliminating the pointer or reference between object 1145 and its parent, object 1125.
  • the object (or intermediate node) 1130 has been deleted, by deleting its reference to the parent object 1115.
  • Deleting object 1130 has the effect of deleting all objects that are contained in object 1130 (i.e., object 1150, object 1155, and object 1160) .
  • the preferred implementation also provides the functions of modifying or updating objects in an object containment tree. These functions include generating appropriate user interfaces (windows) for the user to identify the object(s) in the object containment tree to be modified and then modifying the identified object.
  • Modifying an object can include modifying the contents or data values in the object or changing the parent object of the identified object to be modified.
  • the modification of objects will also be explained with reference to an example of modifying a leaf node (or object) and an intermediate node (or object) in the object containment tree.
  • FIG. 18(c) illustrates the update window for the relative cell structure in the object containment tree that has the special attributes of a material object.
  • the field 1801 in Figure 18(c) is the title of the window "Update ⁇ Material>.”
  • the word Material is in " ⁇ >" to show that this title is a variable. In other words, if one object is to be updated, then the title of the window is "Update Material.” However, if more than one object is to be updated then the title of this window would be "Update Multiple Materials. "
  • Figure 18(c) Most of the fields in Figure 18(c) have corresponding fields of the same type in the window illustrated in Figure 12(a). In this case, the common fields between the Figures 12(a) and 18(c) are labelled in Figure 18(c) using the same labels used in Figure 12(a).
  • the window of Figure 18(c) does not include the fields 1220, 1221, and 1222 of the window of Figure 12(a). Instead, the window of Figure 18(c) includes the field 1820 which is a gadget labelled "Update,” and field 1821 which is another gadget labelled "Cancel.” Update 1820 is depressed by the user using the buttons on a mouse to initiate the update object process described below. The Cancel gadget 1821 is depressed to cancel the current message.
  • one of the functions of the preferred implementation is to update or modify objects in an object containment tree. This process will now be described with reference to the flow diagram of Figure 18(d).
  • the user selects the Modify option from the main menu bar (not shown) (step 1850). This brings the user to the Select Action window 1900 of Figure 18(a). Then, the user presses the search gadget from the Select Action window 1900 which takes the user to the Search for Material window 2000 of Figure 18(b) (step 1855).
  • the user traverses the object containment tree to identify the object to be modified (step 1860). Then, the user presses the search gadget from the Search for Material window 2000 (step 1865). This takes the user to the Select Material window 1500 of Figure 15(a).
  • the user then enters or modifies the data of the existing object (step 1880) followed by depressing the Update gadget in the appropriate window.
  • Pressing the Update gadget has the effect of initiating an update by sending an update message to the object (including any updated object data values and, optionally, the previously saved reference to the object in which the object to be modified is contained) (step 1885).
  • the object receives the update message and locates the appropriate method of the class of which the object belongs, using the method references associated with all objects of each class type, and provokes the execution of the selected method to change the data values of the object in accordance with the parameters of the received message (step 1890).
  • These parameters are the modifications to the object indicated by the user in the modify window.
  • Changing the identified object's Located In attribute has the effect of moving or relocating the object in the object containment tree. This is illustrated in Figures 19 and 20 which are discussed below.
  • Figure 19 illustrates the tree 1100 of Figure 11 following a modification, performed in accordance with the steps shown in Figure 18(b).
  • the object (leaf node) 1175 is updated. This update included changing the contents or data values of the object 1175 as well as changing the parent-child relationship of the object.
  • the object 1175 is now contained in the parent object 1140, instead of object 1135 (see Figure 11).
  • the intermediate object 1135 is modified by changing its data values (changing Acme to ABC) as well as changing the object containment tree 1100 to reflect the fact that the object 1135 is now contained in object structure 1120.
  • changing the parent object 1135 requires only changing the located-in attribute of the object by changing the located-in field in the appropriate window used to modify the object.
  • the present invention thus provides an efficient and simple tool for managing one or more facilities.
  • classes of objects containing specific data values are managed, the data values themselves are not important.
  • the organization of the classes of objects is important because it is that organization which dictates how objects are managed.
  • Another advantage afforded by this invention is the ability to reorganize the containing relationships between the objects. This further enhances the power and flexibility of systems implemented in accordance with this invention.

Abstract

A method and apparatus providing for the management of material in suitable facilities designed and developed using object oriented technology comprised of objects representative of material and the like located in and activities being performed in the facility. The objects have data values and references, and are organized based on a unique set of classes adaptable for use with any facility handling material. The data values and references of objects correspond to the attributes of a class and the methods associated with the class, respectively. The objects are organized in a single object containment tree that represents one or more facilities. The objects in the object containment tree (1100) are manipulated to represent transactions, i.e., the movement of material, occurring within the facility.

Description

Description
METHOD AND APPARATUS FOR AN OBJECT ORIENTED MATERIAL MANAGEMENT SYSTEM
Field of the Invention
The present invention relates to material management systems and, more specifically, to the organization of a material management system in accordance with an object oriented model and the interaction of multiple external systems with a material management system to facilitate the management, storage and handling of physical materials.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copy rights whatsoever. Background of the Invention
Various material management systems for use in facilities such as warehouses, refiners, storerooms, etc. are currently available for maintaining, e.g., managing, storing, organizing, and handling, materials such as consumer goods, crude oil, supplies, etc. Such systems can prove to be essential for providing current information about a facility such as information concerning the status of material inventory, orders, etc. Because such information is critical to the efficient management of the facility and because the uninterrupted processing of orders is essential, it is desirable that the installation of such systems be both fast and efficient. Any delay in the installation of a material management system into a facility can have a significant negative impact upon the maintenance of that facility. For example, such delays can result in the waste of available space in a facility capable of holding materials to be shipped, or downtime of facility equipment because no orders for materials located in the facility are being processed.
Conventional material management systems typically require significant reprogramming or customization prior to their installation into a new facility especially if the facility itself is large and processes a wide variety of materials. This often results in installation delays which, as explained above, waste the facility's resources. Obviously, such waste due to installation delays is not desired. Further, reprogramming and customization of conventional systems require the skills of specially educated people such as computer programmers, etc. The installation of a conventional material management system is, therefore, viewed as an expensive and time- consuming operation.
An alternative to reprogramming or customizing conventional material management systems is to change the operations of the facility in which it is to be installed to conform with the operations of the material management system. This, however, is thought to be a significant undesirable aspect of conventional material management systems.
In addition to those requirements concerning the installation of conventional material management systems, such conventional systems also require specially skilled people to change or alter the systems in accordance with further changes made in the operations of the facility being managed. This is yet another shortcoming of conventional material management systems. The efficient and effective maintenance of physical materials in suitable facilities has also become increasingly important for reasons similar to those regarding fast installation time of material management systems and, specifically, because persons responsible for the management of materials require up-to-date information concerning the status of, for example, orders and inventory, to enable efficient management of the facility.
Conventional material management systems are typically designed and developed using data processing systems and conventional relational and hierarchical database management technology. Using relational database technology, conventional material management systems manage information or records in at least twelve files for relatively small facilities. This is considered to be the minimum number of files required to manage all data corresponding to materials managed in a facility. Each file is stored in the data processing system and corresponds to a different aspect of the particular facility. Examples of files include an 'order' file which contains records corresponding to incoming and outgoing orders, and a 'location' file which contains records identifying locations within the facility that contain material received in and shipped out of the facility.
Using relational database technology, when a record identifying a new order for material to be shipped is added to the 'order' file, the conventional material management system must locate, access, and update at least one record in the 'location' file to fill the order record added to the 'order' file. In this example, two files must be updated to complete a transaction as a result of a single update in one of the files, in order to preserve data integrity between the files. In other instances as many as all twelve files must be updated to complete a transaction as a result of a single update.
Further, maintaining data integrity and, at the same time, permitting continuous real-time interactive data access is impossible using conventional relational and hierarchical technology without locking users out of the system until a transaction is completely processed. Otherwise, users may view information in one file that does not reflect a change in another file as a result of a transaction that has not been completed.
Summary of the Invention
It is therefore an object of the present invention to provide a material management system designed using object oriented design technology.
It is another object of the present invention to provide a material management system that can be installed in new facilities in a relatively short period of time so as not to interrupt the operations of the facilities.
It is still another object of the present invention to provide a material management system that requires little or no changes to be adapted for use in each of a plurality of facilities.
It is also an object of the present invention to provide a material management system that can be installed in new facilities without the need of specially skilled people.
It is still a further object of the present invention to provide a material management system that enables users to change or alter the system in accordance with changes in the operations of the facility without the need of specially skilled people.
It is yet another object of the present invention to provide a material management system capable of consistently providing users with up-to-date information concerning data being managed by the system including the current status of orders and inventory.
It is still another object of the present invention to provide a material management system wherein all transactions, such as adding orders to be processed by the facility, require system access to only a single file and modification of only a single record in the file.
It is still a further object of the present invention to provide a material management system capable of maintaining data integrity and at the same time permitting continuous real-time interactive data access.
Additional •-.-bjects and advantages of the invention will set forth in the description which follows, and iϊ -.rt will be obvious from the description, or -ιy be learned by practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the purposes of the invention as embodied and broadly described here, this invention provides for the management of information corresponding to material and relevant operations on material being handled in a facility in an object oriented manner (using a data processing system) by which a system manages "classes" (within the "class categories" of facility, material, company, order, and activity) and instances of each class or objects which form a single treelike structure (the file), called an object containment tree, rather than multiple files of records.
In particular, in an object oriented data management system for maintaining a facility, the data management system including a data processing system having a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects, methods of adding a new object to, deleting an object from, and modifying an object in the object containment tree are provided, wherein each of the methods is performed by the data processing system.
The method of adding a new object to the object containment tree comprises the steps of designating a class of the new object; selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; sending a message to the class of the new object to create the new object; and adding the new object to the object containment tree.
The method of deleting an object from the object containment tree comprises the steps of selecting one of the objects in the object containment tree to be deleted; and sending a message to the selected object to delete the selected object from the object containment tree.
The method of modifying an object in the object containment tree comprises the steps of selecting one of the objects in the object containment tree to be modified; and sending a message to the selected object to modify at least one of the data values contained in the selected object. Further, a data processing system including an object oriented data management system for maintaining a facility is provided, comprising a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for designating a class of the new object; means for selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; means for sending a message to the class of the new object to create the new object; and means for adding the new object to the object containment tree.
Still further, a data processing system including an object oriented data management system for maintaining a facility is provided, comprising a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for selecting one of the objects in the object containment tree to be deleted; and means for sending a message to the selected object to delete the selected object from the object containment tree.
Even further, a data processing system including an object oriented data management system for maintaining a facility is provided, comprising a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for selecting one of the objects in the object containment tree to be modified; and means for sending a message to the selected object to modify at least one of the data values contained in the selected object.
Brief Description of the Drawings
The accompanying drawings which are incorporated in and which constitute part of this specification, illustrate a presently preferred implementation of the invention and, together with the general description given above and the detailed description of the preferred implementation given below, serve to explain the principles of the invention. In the drawings:
Figure 1 is a block diagram illustrating the components of an exemplary workstation or platform in which the present invention may be implemented;
Figure 2 is an illustration of the major components of a preferred implementation of the present invention; Figure 3 is a class category diagram for describing the preferred implementation of the present invention;
Figure 4 is a facility class diagram for describing the preferred implementation of the present invention;
Figure 5 is a material class diagram for describing the preferred implementation of the present invention;
Figure 6 is an order class diagram for describing the preferred implementation of the present invention;
Figure 7 is a company class diagram for describing the preferred implementation of the present invention;
Figure 8 is an activity class diagram for describing the preferred implementation of the present invention;
Figure 9 is a database class diagram for describing the preferred implementation of the present invention;
Figure 10 is a block diagram illustrating the relationship between the attributes of an object of a class in accordance with the preferred implementation of the present invention;
Figure 11 is an example of an object containment tree for describing the preferred implementation of the present invention;
Figure 12(a) illustrates a user interface (display screen) for adding a relative cell (or node) representative of an object to the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention;
Figure 12(b) illustrates a flow diagram for describing an operation of the user interface of Figure 12(a) in accordance with the preferred implementation of the present invention; Figure 13 is an example of the object containment tree of Figure 11 after a leaf node is added to the tree in accordance with the preferred implementation of the present invention;
Figure 14 is an example of the object containment tree of Figure 11 after an intermediate node is added to the tree in accordance with the preferred implementation of the present invention;
Figure 15(a) illustrates a user interface (display screen) for deleting a relative cell (or node) representative of an object (e.g., material) from the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention;
Figure 15(b) illustrates a flow diagram describing an operation of the user interface of Figure 15(a) in accordance with the preferred implementation of the present invention;
Figure 16 is an example of the object containment tree of Figure 11 after a leaf node is deleted from the tree in accordance with the preferred implementation of the present invention;
Figure 17 is an example of the object containment tree of Figure 11 after an intermediate node is deleted from the tree in accordance with the preferred implementation of the present invention;
Figures 18(a)-18(c) illustrate a user interfaces (display screens) for modifying a relative cell (or node) representative of an object (e.g., material) from the object containment tree of Figure 11 in accordance with the preferred implementation of the present invention;
Figure 18(d) illustrates a flow diagram for describing an operation of the user interfaces of Figures 18(a)-18(c) in accordance with the preferred implementation of the present invention; Figure 19 is an example of the object containment tree of Figure 11 after a leaf node is modified in accordance with the preferred implementation of the present invention; and
Figure 20 is an example of the object containment tree of Figure 11 after an intermediate node is modified in accordance with the preferred implementation of the present invention. Detailed Description of the Preferred Implementation
Reference will now be made in detail to the preferred implementation of the present invention as illustrated in the accompanying drawings. Major Components of an Exemplary Computer System
This invention is preferably implemented using industry standard workstations (or platforms). A block diagram of an example of such a workstation is illustrated in Figure 1. Those skilled in the art would recognize that the present invention may also be implemented using a variety of micro and mini computers as well as large scale data processing equipment. Those skilled in the art would also recognize that the present invention may also be implemented using a distributed network environment where the preferred implementation of the present invention is distributed on multiple platforms throughout the network. The preferred implementation, which is disclosed hereinafter in functional schematic form, is preferably written primarily in the C++ programming language.
Referring to Figure 1, a workstation 100 is provided comprising a central processing unit ("CPU") 102, a disk drive 105, a mouse 110, a keyboard 115, and a display 120 having a display screen 122. The workstation 100 may also optionally include other external devices 125, such as a radio data terminals, enhanced video display terminals, and tag printer peripherals. The CPU 102 is comprised of an input/output (I/O) unit 130, a random access memory ("RAM") unit 135, a display memory unit 140, a video interface circuit ("VIC") 145, and a microprocessor 150. These units are all well known and operate under control of system software which is preferably stored in the disc drive 105 to process various inputs and provide the outputs necessary to generate desired textual and graphic display information on the display screen 122 of the display 120 or on another output unit such as the optional external devices 125.
Display memory 140 is a specialized section of RAM which is used to store bit patterns (pixel data) which are read out by the video interface circuit 145 in an appropriate synchronization with the display beam of the display 120 in order to provide the desired display graphics and text.
The disk drive 105 is also conventional and is provided to permit the ready interchange of control and application software and to provide a source of mass storage for the computer system.
The mouse 110 of the workstation 100 includes a roller ball 111 and control buttons 112 and 113. The buttons 112 and 113 actuate momentary contact switches (not shown) to generate selection signals and other commands. These switches and signals are well known to those of ordinary skill in the art and, as is also well known, the user moves the mouse 110 along a planar surface, such as a table top, to generate cursor position input commands which are supplied to the CPU 102. The roller ball 111 cooperates with a mechanism (not shown) which converts the movement of the mouse 110 into X-Y signals which are used by the CPU 102 to control positioning of a cursor symbol (not shown) on the display screen 122 of the display 120. The conversion of the motion of the roller ball into x-y commands is also conventional. The keyboard 115 may, for example, replace the activities of the mouse 110 by presetting a number of keys on the keyboard to emulate the positioning function of the mouse 110. Additionally, other keys on the keyboard 115 may replace the functions of the buttons 112 and 113 of the mouse 110. However, in the preferred implementation of the present invention, the mouse 110 is used for positioning the cursor on the display screen 122 and for performing other functions described below. As is generally the case with conventional data processing systems, the keyboard 115 of the workstation 100 of the preferred implementation of the present invention acts as a means for inputting textual or alphanumeric information into the CPU 102. As stated above, the display 120 is comprised of a display screen 122 for displaying the graphic and alphanumeric information output from the CPU 102. In the workstation 100 of the preferred implementation the display 120 may be a touchscreen display in which commands may be entered into the CPU 102 via the display 120. Such touchscreen displays are also conventional. Major Components of the Preferred Implementation
As shown in Figure 2, the preferred implementation of the present invention is comprised of several software components 200 each of which, preferably, resides in the disk 105 of Figure 1. It should be understood that, when the user employs the preferred implementation of the present invention, all or part of the software components 200 of the preferred implementation may be input to the CPU 102.
Referring to Figure 2, the software components
200 of the preferred implementation of the present
3 invention include a component referred to as GENOA
210, an import interface 220, an export interface 230, a script system interface 240, a database systems interface 260, a report system interface 270, and two optional interfaces illustrated using broken line boxes, namely, a terminals interface 280 and an automated equipment interface 290. 3 GENOA 210 is the software component of the preferred implementation that enables users to manage, store, and handle material. As discussed in detail
3 below, GENOA 210 supports inbound order processing, material movement and storage, and resource and facility allocation. The architecture and operations
3 of the preferred implementation, including the GENOA component 210 will be discussed in detail below.
The import interface 220 is a software component of the preferred implementation that provides the functions used to import information into the preferred implementation. In general, the processes of the import interface component 220 include receiving information in a first format recognized by particular computer application systems (not shown), and translating the information from the first format into a second format recognizable by the preferred
3 implementation, including specifically, GENOA 210.
The export interface component 230 provides the functions to export information from the preferred implementation for use with other external computer software applications (not shown), e.g., spreadsheets.
In contrast to the operations of the import interface
220, the general processes of the export interface 230 include receiving information in a format recognizable
3 by GENOA 210 of the preferred implementation and translating the information into another format for
3 processing by other systems external to GENOA 210 and the preferred implementation.
The script interface 240 is an interface to externally provided scripts or programs (not shown) .
It should be understood that a script is an externally provided program and the script interface 240 allows a user to execute an externally provided script through
3 the GENOA menu system.
The database system interface 260 provides the necessary functions for the preferred implementation to communicate with external database systems (not shown) which are used to maintain aspects relating to a material management facility other than the management of material, e.g., management of accounts receivables and payroll.
The report system interface 270 provides the necessary functionality to enable the preferred implementation to communicate with standard report writing systems (not shown) which generate customized
3 reports using information from GENOA 210 of the preferred implementation. For example, the external report writing systems may be used to generate reports
3 regarding orders managed by GENOA 210. However, in many instances, facilities have report styles that they prefer to use. The general operations of an external report writing system therefore include the ability to provide users with customized reports. In this manner, the report writing system may be adapted
3 for use by each facility. However, the GENOA component 210, does not have to be adapted to conform with the style of reports generated for a facility.
The preferred implementation may communicate with external devices such as radio data terminals, video display terminals, and X-window terminals (not shown). The preferred implementation communicates with these types of terminals by way of the terminals interface 280.
Finally, the preferred implementation also includes an optional automated equipment interface component 290. The component 290 provides the preferred implementation with the capability to communicate with automated equipment (not shown) in a facility. Examples of automated equipment include automated conveyor systems for moving material in and around a facility and robotic equipment such as automated forklift systems which are also used for moving material etc. in a facility.
System Architecture of the Preferred Implementation
External System (Object Oriented. Architecture
The preferred implementation of the present
3 invention, and particularly the GENOA 210 component of Figure 2, is organized using object oriented technology. For purposes of the following description of the present invention, the terminology and notations described by Grady Booch in "Object Oriented
Design with Applications," The Benjamin/Cummings
Publishing Co., Inc., 1991 will be used.
The preferred implementation is organized using classes, methods, and messages.
A class is a template for the creation of objects (which represent the items or instances manipulated by the system) having the characteristics of that class. The term template denotes the fact that the objects (i.e., data items or methods) in each class, share certain characteristics or attributes determined by that class. Objects are created dynamically during system operation. The preferred implementation uses many classes, some of which will be described below.
Methods are said to be associated with the classes. As explained below, in the preferred implementation, messages are "sent" to an object of a class and (depending upon the type of message and the particular methods associated with the class containing the object that received the message) a method is selected from the methods associated with the class of the object, which method corresponds to the message, and the selected method is then executed in connection with the object receiving the message. For example, the message "UPDATE MATERIAL (LOC...)" may be sent to an object of the class material, which object is identified by the parameter LOC in the parentheses to update or modify the material object LOC. Because the object LOC is of the material class, the method associated with the material class for updating a material object is executed. As explained in detail below, this is how all operations are executed in the preferred implementation. However, as also explained below, because the preferred implementation uses a single class of objects (i.e., the class containment tree) to represent all of the classes of objects used by the preferred implementation, the message sent to an object of that class (containment tree) is the method of the class (containment tree) that will be executed. Also, the number of messages used in the preferred implementation is limited to primarily three, namely, ADD, DELETE, and UPDATE. Although other messages are used, the operations associated with the other messages are thought to be analogous to the operations of the preferred implementation corresponding to the at least one of the ADD, DELETE, and UPDATE messages.
In the object oriented design of applications, class diagrams are used to show the structure of a system, including the existence of classes and their relationships in the logical design of a system. In the design of the preferred implementation of the present invention, however, the class diagrams (see Figures 4-9) contain many classes. Therefore, a class category model 300 of Figure 3 is used to gain a preliminary understanding of the organization of classes in the preferred implementation of the present invention.
A class category is a meaningful way of representing many related or "chunks" of classes sharing certain common characteristics. For example, the class category facility 320 of Figure 3 is composed of the classes locations, containers. capacity cells, movable cells, relative cells, cells, and a containment tree (see Figure 4). Each of these classes will be described below in detail and the common characteristics that make them part of the facility class category 320 will be apparent from that discussion.
The preferred implementation of the present invention is modeled in Figure 3 using class categories material 305, company 310, activity 315, facility 320, and order 325. As illustrated in Figure 3, classes in the company class category 310 and classes in the facility class category 320 are said to be "visible" to classes in the material class category 305. This is illustrated in the model 300 of Figure 3 by the directional arrows between the class categories 310 and 320 and the material class category 305. Visibility between classes in class categories is determined by whether a class category imports (or "uses") classes declared as part of another class category. By way of example, classes in the class category facility 320 use classes from the class categories activity 315, material 305, and order 325. Similarly, classes in the class category material 305 use classes in the class category order 325 and classes in the class category company 310 use classes in the class category order 325 and material 305.
Figure 3 also illustrates several class categories referred to as global class categories because these class categories represent classes visible to all classes in all other class categories that are part of the model 300. The global class categories in the model 300 are labelled "global." They include GENOA3 330, CSX 335, AT&T 340, and database 345. The global class categories, except the class category 345, represent classes of tools available to all other classes in the class categories of the model 300. Examples of classes of tools included in some of these global class categories are mathematical function tools that can be used by the preferred implementation to execute mathematical operations during system operation. The class category database 345 will be explained in further detail below.
Understanding that the class categories of the model 300 of Figure 3 represent multiple classes which are organized to implement the present invention, a discussion of the classes in each of the class categories is now appropriate.
The class category facility 320 is composed of the following classes illustrated in Figure 4: location 410, container 415, capacity cell 420, movable cell 425, relative cell 430, cell 435 and containment tree 440. It should be understood that the rectangle surrounding a class name indicates that it is an exported class for use in at least one other class category. Further, the term "class containment tree" should be distinguished from the term "object containment tree" which is used, for example, to describe the object containment tree 1100 of Figure 11, which will be explained in detail below.
Similarly, the class category container 417 is illustrated in the class container 415, the class category capacity cell 422 is illustrated in the class capacity cell 420, and the class category movable cell 427 is illustrated in the class movable cell 425.
Figure 4 also includes two additional classes, namely, the class location database item 450 and the class container database item 460. Although classes 450 and 460 are illustrated in Figure 4, they are not part of the facility class category 320. Rather, they are imported from another class category. In other words, classes 450 and 460 are used to connect the classes of the facility class category 320 with other class categories. This is illustrated in Figure 4 by underlining the legend for the class location database item 450 and the legend for the class container database item 460. For example, looking at Figure 9 it can be seen that the classes 450 and 460 of Figure 4 are imported from the global class category database 345 of Figures 3 and 9.
There are two basic types of relationships between classes in a class category. These relationships are called the "is a" (or "kind of") relationship and the "has a" (or "uses") relationship. In Figure 4, an "is a" relationship between classes is illustrated using directional lines (or lines with an arrow at one end) to signify that the class at the end of the directional line (the side without the arrow) is a specialization or "a kind of" class at the opposite side of the directional line.
For example, in Figure 4, it may be said that the class location 410 "is a kind of" (or a specialization of) the class capacity cell 420. Similarly, the class container 415 "is a kind of" the class capacity cell 420 and the class container 415 is also a "kind of" the class movable cell 425. The classes capacity cell 420 and movable cell 425 are each "a kind (or specialization) of" the class relative cell 430 and the class relative cell 430 is, in turn, a kind of the class cell 435. This is an example of an inheritance chain that will be discussed below. Also illustrated in Figure 4 is the class container 415 which is a specialization of the class container database item 460 of the global class category database 345 of Figure 3 and the class location 410 which is a specialization of the class location database item 450 of the global class category database 345 of Figure 3.
The "is a" or "kind of" relationship is used to illustrate a concept called "inheritance. " Inheritance may be defined as a relationship among classes, wherein one class shares the structure or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. Inheritance is said to define a relationship between classes in which a "subclass" inherits from one or more "superclasses"; a subclass augments or further defines the existing structure and behavior of its superclass. A subclass, therefore, has all the characteristics or attributes (e.g., physical record structure including any data fields and pointers as well as references to relevant methods capable of operating on objects in the class) of its superclass plus one or more additional characteristics.
For example, in Figure 4, the class location 410 is a subclass of the class capacity cell 420 (a superclass of the subclass location 410) that represents (or has the characteristics of a physical (or logical) volume of space at a specific position within the facility. Objects in the class location 410, therefore, have all the characteristics of objects in the class capacity cell 420 plus the added characteristics or attributes particular to objects of the class location 410 (explained below). As discussed below, in the class containment tree 440, a location object may contain other location objects, container objects, or material item objects.
Another way of understanding the "kind of" relationships discussed above is to view the class location 410 as inheriting from the chain of classes, e.g., capacity cell 420 inherits from relative cell 430 which inherits from cell 435. The class location 410 also inherits from the class location database item 450. That is, the class capacity cell 420 is a superclass of the subclass location 410 and, therefore, objects in the class location 410 have the structure corresponding to the attributes of objects in the class capacity cell 420 plus the added structure corresponding to the attributes of objects particular to the class location 410. Similarly, the class location database item 450 is a superclass of the class location 410 (the subclass), container database item 460 is a superclass to the class container 415 (the subclass), capacity cell 420 is a superclass of the subclass container 415, and movable cell 425 is also a superclass to the subclass container 415.
As also illustrated in Figure 4, the class relative cell 430 is a superclass of both the capacity cell 420 and the movable cell 425. Finally, the class cell 435 is a superclass to the class relative cell 430. The class relative cell 430 is, therefore, said to inherit all the attributes of all of its superclasses.
The "has a" or "uses" relationship between classes is illustrated in Figure 4 with a double line with a circle at one end connecting classes (or connecting to the same class, e.g., the connection of the class relative cell to itself). The "uses" relationship signifies that the class at the end of the double line having the circle "uses" the class at the opposite side of the double line.
For example, in Figure 4, the class containment tree 440 is said to "use" the class relative cell 430 (and the class relative cell 430 uses the class relative cell 430). This means that objects in the class containment tree 440 interface with or "use" the objects in the class relative cell 430.
The class containment tree 440 in the facility class category 320 is a tree structure in which each- node represents a relative cell object. This one-to- one relationship between an object of the class relative cell 430 and an object of the class containment tree is illustrated in Figure 4 with the principle cardinality depicted by the "1" next to each end of the "uses" connection (double line) between the class relative cell 430 and the class containment tree 440. A containment tree represents the complete containment of child cells by parent cells.
The class relative cell 430 represents the class cell 435. The class relative cell 430 also "uses" the class relative cell 430. In other words, as illustrated in Figure 4 with the double line connecting the class relative cell with itself, there are zero or more objects (represented by the "*" above one end of the double line) in the class relative cell 430 that use another object (represented by the "1" above the other end of the double line) of the class relative cell 430. As explained below, in the class containment tree 440, a relative cell object is completely contained within a parent relative cell object and has a specified position relative to the parent cell object. The position of the relative cell object with respect to its parent may be changed. The class relative cell 430 inherits from the class cell 435, as explained above.
Objects said to be a part of the location class 410 have certain common characteristics. A location object (not shown) in the class location 410 represents a fixed volume of space at a known position in a facility. Locations (objects in the class location 410) may contain other locations, containers, or material. As already discussed above, the location class 410 inherits from the following chain of classes: capacity cell 420, relative cell 430, and cell 435. The location class 410 also inherits from the location database item class 450 of the global database class 345 of Figure 3.
A model of a facility or a containment tree can be built by identifying a hierarchy of locations (or which locations in the facility contain other locations) . The top location represents the totality of all locations managed by the preferred implementation. Thus, the top location might be a corporation with many warehouses, a single marshaling yard, or the finished goods section of a warehouse.
As an example, a warehouse might be identified as the "top" or highest location. The warehouse might be divided into four zones, so four more locations might be specified, one for each zone contained in the warehouse. Further, Zone 1 of the four zones might contain six aisles, so six more locations would be identified as contained in Zone 1. This process continues until all individual locations where containers or material can reside have been identified.
As discussed above, classes are templates for the creation of objects. Objects of a class have particular characteristics defined by the class. Each container object (not shown) in the container class 415, like a location object, represents a fixed volume of space at a known position. Unlike a location object, however, a container object can be moved from one location to another in the facility. Container objects may contain location objects, other container objects, or material item objects as will be explained below.
Location objects and container objects share certain common attributes in the preferred implementation. First, each can define any number of ports. A port is an area on the surface of a location object or a container object through which material item objects can arrive and/or leave the location or container object. Second, location objects and container objects can be set to adjust automatically their quantity of a given material type (to be discussed below) based upon specified events. An example of a port might be a simple shelf location in the facility which may be used as a single port where material items both arrive and leave the facility. Other examples of ports are flow-through racks where material items arrive in one end of the port and leave through another end of the port, a sorter where material items arrive in one end of the sorter and leave through other ends of the sorter after being sorted (e.g., for color, weight, etc.) and packing stations where material items arrive for packing and leave packed (e.g., in containers). An example of the port capable of being adjusted for different quantities of material items is a replenishment location in the facility. In replenishment locations, when the quantity of a given material type at the location falls below a predetermined quantity (called the event), the location finds some suitable material items in the facility and creates tasks to transfer the material items to itself.
The class container 415 in Figure 4 represents the template for container objects. Each container object (not shown) of the class container 415 is a particular type of capacity cell (object of the capacity cell class 420) that represents a physical (or logical) volume of space at a specific position within the material management facility. A container object within the class container 415 can contain location objects, other container objects, or material item objects (not shown) . As discussed below, in the class containment tree 440, a container object may be contained in a location object or another container object, and is movable from one location object or container object to another.
The class capacity cell 420 represents the class cell 435. As explained below, in the class containment tree 440, a capacity cell object may contain relative cell objects, subject to capacity limits, and other defined restrictions. The class capacity cell 420 inherits from the class relative cell 430, and the class cell 435. The class movable cell 425 represents the class cell 435. As explained below, in the class containment tree 440, a movable cell object may be moved from one parent capacity cell object to another. The class movable cell 425 inherits from the class relative cell 430 and the class cell 435.
Finally, the class cell 435 is a rectangular parallelepiped of fixed dimensions.
The classes that compose the class category material 305 (see Figure 3), used to model material in a material management facility, are illustrated in Figure 5. As shown in Figure 5, the class category material 305 is comprised of the classes material 505, material definition 510, material locator 515, and lot 520. The other classes shown in Figure 5 include the movable cell 425 (see Figure 4), the material definition database item 530, the lot database item 535, and the material database item 540.
The class material definition 510 is a template for objects (not shown) containing all the information needed to define a type of material (e.g., part number, description, weight, standard package sizes, qualified suppliers, etc. ) As explained above with reference to Figure 5, the class material definition inherits from the class material definition database item 530. This class 530 is a class within the global class database 345 (see Figure 3), explained below with reference to Figure 9.
The class material 505 is a template for objects (not shown) containing information identifying a given quantity of a specific material definition object (not shown) and occupies a fixed volume of space at a known position.
As illustrated in Figures 4 and 5, the class material 505 inherits from the chain of classes movable cell 425 (Figure 4), relative cell 430, cell 435. Finally, as explained above, the class material 505 also inherits from the material database item 540.
As will be explained below, a material object of the class material 505 is recognized as soon as it appears on an inbound order. It is then tracked from its point of origin into the facility, put away for storage, picked to fill an outbound order, shipped by way of a transportation carrier and finally removed from the system. Any combination of these steps can be used.
The class material locator 515 represents a template for objects (not shown), wherein each object of this class is an index for locating all material item of a given material type.
The class lot 520 is an optional class and is provided for facilities where lot control or lot tracking disciplines are required. A lot object (not shown) of the class lot 520 contains all the information needed about any one manufacturing lot of a given material (e.g., vendor, lot ID, date code, material definition, list of material from the lot, etc. ) .
The class movable cell 425 is imported (underlined legend) from another class category, namely, the facility class category 320 explained with Figure 4. Likewise, the classes material definition database item 530, lot database item 535, material database item 540, and company 545 are also imported from other class categories. Therefore, these classes will not be explained in detail with reference to Figure 5, rather these classes will be explained in detail with reference to each of the class categories from which each of these classes is imported for use in connection with the classes of the class category material 305. At this point only the relationship between these imported classes and the classes of the class category material 305 will be discussed. The inheritance of classes in Figure 5, like those in Figure 4, is illustrated by way of the directional lines (arrows). In Figure 5, therefore, the class material definition 510 inherits from the class material definition database item 530 (an imported class), the class lot 520 inherits from the class lot database item 535 (an imported class), and the class material 505 inherits from the class material database item 540 (another imported class) and the class movable cell 425 (another imported class) .
As also illustrated in Figure 5, the class material locator 515 "uses" the class material 505. As shown by the cardinality of this "using" relationship, or the "1" above the side of the double line near the circle (connecting the double line with the class 515) and the "*" above the other end of the double line connecting the double line with the class 505, each object (not shown) in the class material locator 515 uses zero or more objects (not shown) from the class material 505.
Other "using" relationships illustrated in Figure 5 include the following:
The class material locator 515 uses the class material definition 510 with a cardinality for this relationship of one-to-one (represented by the "1" above either end of the double line connecting these classes). That is, each material locator object (not shown) of the class material locator 515 uses or interfaces with an object from the material definition class 510.
The class material 505 uses the class material definition 510 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more material objects (not shown) of the class material 505 interface with one of the objects (not shown) from the material definition class 510.
The class material 505 uses the class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more material objects (not shown) of the class material 505 interface with zero or more objects (not shown) from the class company 545.
The class material 505 also uses the class lot 520 with a cardinality for this relationship of zero or more to zero or one (represented by the "*" above one end of the double line connecting these classes and the "?" above the other end) . In other words, zero or more material objects (not shown) of the class material 505 interface with zero or one object (not shown) from the class lot 520.
The class material definition 510 uses the class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more material definition objects (not shown) of the class material definition 510 interface with zero or more objects (not shown) from the class company 545.
Finally, as illustrated in Figure 5, the class lot 520 uses the imported class company 545 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more lot objects (not shown) of the class lot 520 interface with one of the objects (not shown) from the class company 545.
Figure 6 illustrates the classes of the class category order 325 (Figure 3). The classes of the class category order 325 are used to model inbound and outbound orders for a material management facility.
In Figure 6, the class category order 325 is comprised of the classes order 605, order directory 610, and order item 615. The class order is comprised of the class category order 607 and the class order item 615 is comprised of the class category order item 617.
Therefore, with respect to these classes 605 and 615, there is another level of abstraction (not shown) that would illustrate the relationship between the classes of the class categories 607 and 617, respectively.
In Figure 6, the class order 605 is used as a template to create order objects (not shown) . An order object is a uniquely identified list of order items (discussed below), including common information about the source and destination of those items.
Order objects that are said to be inbound represent
3 material coming into a facility managed by the GENOA component 210 (Figure 2) of the preferred implementation of the present invention, while order objects that are said to be outbound represent demand for material to be delivered from such a facility.
As shown in Figures 4-6, the class order 605 inherits either from the imported classes capacity cell 420 (which inherits from the class relative cell
430 which in turn inherits from the class cell 435), order database item 620, movable cell 425 (which inherits from the class relative cell 430 which in turn inherits from the class cell 435) . The class order item 615 inherits from the class material 505
(which is imported) or from the class order item database item 625. As also shown in Figures 4-6, the order item class 615 inherits (via the class material
505) from the class movable cell 425 which in turn inherits from the class relative cell 430 which inherits from the class cell 435. Each object of the class order item 615 represents a quantity of a given material definition. One or more order item objects exist for each different material definition included in an order. Order item objects on inbound orders represent promised material before being received and actual material after being received. Likewise, order items on outbound orders represent demand for material before being filled and actual material after being filled.
The "uses" relationships illustrated in Figure 6 include the following:
The class order 605 uses the imported class company 545 with a cardinality for this relationship of zero or more to zero or more (represented by the "*" above either end of the double line connecting these classes). In other words, zero or more order objects (not shown) of the class order 605 interface with zero or more objects (not shown) from the class company 545.
The class order directory 610 uses the class order 605 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each material order directory class object (not shown) of the class material order directory 610 uses or interfaces with an object from the order class 605.
Finally, the order class 605 also uses the class order item 615 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more order item objects (not shown) of the class order item 615 interface with one of the objects (not shown) from the order class 605.
The class category company 310 (Figures 3 and 7) is composed of the classes company 710 (Figure 7), company directory 715 and company database item 720. As illustrated in Figure 7, the class company 710 inherits from the imported class company database item 720. The class company directory 715 uses the class company 710 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes) . That is, each company directory class object (not shown) of the class company directory 715 uses or interfaces with an object from the company class 710.
In general, the company class is used to record information about any entity with whom the material management facility does business. The company class 710 may represent other companies, other divisions of the same company, plants, individuals, and the like. The company class 710 may also represent sources, destinations, manufacturers, consignees, etc.
In Figure 8, the class category activity 315 is composed of the classes human 810, fork truck 815, AGV 820, agent 825, task 830, and transaction 835.
The classes transaction 835, task 830, and agent 825 represent objects that are considered to be proactive, concurrent units of work that drive the preferred implementation of a material management system. In the preferred implementation, users or other systems generate transaction objects (e.g., automated equipment) of the class transaction 835 and transaction objects create task objects of the class task 830 that are subsequently carried out by agent objects of the class agent 825.
A transaction object (not shown) of the class transaction 835 represents an atomic unit of work from an application point of view. For example, placing an order, receiving an order, picking a set of orders and shipping an order are all transactions. Transactions initiate all activity in the preferred implementation of the present invention and can be generated by users, other systems and automated equipment.
A task object (not shown) of the class task 830 represents a request to relocate a container or material item, or to verify the quantity of a material item. Task objects can be generated directly by the user, from transaction objects, or generated automatically by the preferred implementation of the present invention. The user can also dynamically manage all task objects at all times.
Finally, the agent object (not shown) of the class agent 825 represents a person or piece of equipment that can carry out a task. Human objects (not shown) of the class human 810, fork truck objects (not shown) of the class fork truck 815 (e.g., cranes with operators), automatic guided vehicle objects (or AGV objects) of the class AGV 820 are all examples of agent objects. Whenever an agent is available for work, it looks for an available task and picks one based on, for example, capability, priority, location, weight, and size, as specified by the user. Using the agent object, the agent then carries out the selected task and notifies the preferred implementation of the present invention when it is completed.
The imported classes illustrated in Figure 8 include the class capacity cell 420 (see Figure 4), the movable cell 425, and the agent database item 845 (see Figure 9). These imported classes are illustrated with the classes of the class category activity 315 to show how that class category relates to other classes in other class categories.
As shown in Figure 8, the class human 810 is a subclass of the superclass agent 825. Similarly, the class fork truck 815 is a subclass of the superclass agent 825 and the class AGV 820 is a subclass of the superclass agent 825. This is another way of explaining the inheritance between the class 825 and the classes 810, 815, and 820. The class agent 825 inherits from the class agent database item 845. The class agent 825 is also a subclass to the superclasses capacity cell 420 and movable cell 425. Finally, the class task 830 is a subclass to the superclass task database item 840. The classes 840 and 845 will be explained in further detail below.
The "uses" relationships in Figure 8 are as follows:
The agent class 825 uses the class task 830 with a cardinality for this relationship of zero or one to zero or one (represented by the "?" above both ends of the double line connecting these classes). In other words, zero or one agent object (not shown) of the class agents 825 interfaces with zero or one object (not shown) from the class task 830.
The task class 830 uses the class movable cell 425 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more task objects (not shown) of the class task 830 interface with one of the objects (not shown) from the imported class movable cell 425.
The task class 830 also uses the class capacity cell 420 with a cardinality for this relationship of zero or more to zero or one (represented by the "*" above one end of the double line connecting these classes and the "?" above the other end). In other words, zero or more task objects (not shown) of the class task 830 interface with zero or one object (not shown) from the class capacity cell 420.
The transaction class 835 uses the class movable cell with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more transaction objects (not shown) of the class transaction 835 interface with one of the objects (not shown) from the class movable cell 425.
Finally, the class transaction 835 also uses the class capacity cell 420 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes) . In other words, zero or more task objects (not shown) of the class transaction 835 interface with one of the objects (not shown) from the imported class capacity cell 420.
Referring to Figure 9, the database global class category 345 (Figure 3) is composed of the classes note 905, current status 910, classification 915, master database item 920, master note category 925, master classification 930, item note category 935, <X> database item 940, item classification category 945, and status state machine 950. The "<X>" may be replaced by any of the following: agent, company, container, location, lot, material, material definition, order, order item, and task, as illustrated by way of the legend included in the class category 345.
The classes of Figure 9 in the class database category 345 are used to provide and extend the database capabilities normally available from a conventional database management system. These classes provide three characteristics common to all database items. First, each database item (or object of a class within the class category 345) represents a list of allowable status values that may be defined by the user. For example, locations might have status values of available, reserved, in-use and out-of- service, while material items might have status values of on-order, available, reserved, on-hold and return- to-vendor. User defined status transition rules may be established to allow and disallow certain status transitions for the item based on its status.
Second, as many classification categories as desired may be set up by the user and a selection of these categories applied to any database item. For example, the classification category "storage temperature" might include values of frozen, cold, ambient, and heated. The storage temperature classification might apply to both material items and locations. Likewise, a "hazardous material" category might include classifications of explosive, flammable, volatile, and safe. This category could apply to locations, containers, material items and agents. More complex classification schemes can also be used. For example, a hierarchical organization chart might be used to classify the ownership of material items, containers or locations.
Third, an arbitrary number of general text fields (notes) may be attached to each database item as needed. These fields are only for information and are not processed by the preferred implementation of the present invention. They may be entered by the user or come from another system. They are stored by the preferred implementation and may be passed on to other external systems via the interfaces described in Figure 2.
In the database class category 345 of Figure 9, the class <X> database item 920 inherits from the class master database item 920. This is the only inheritance relationship illustrated in Figure 9. The remaining relationships between the classes of the category 345 in Figure 9 are all "uses" relationships. They are:
The class note 905 uses the class item note category 935 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each note object (not shown) of the class item note category 935 uses or interfaces with an object from the class note 905.
The class classification 915 uses the class item classification category 945 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each classification object (not shown) of the class classification 915 uses or interfaces with an object from the class item classification category 945.
The class master database item 920 uses the class master note category 925 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more master note category objects (not shown) of the class master note category 925 interface with one of the objects (not shown) from the class master database item 920.
The class master database item 920 uses the class note 905 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). That is, zero or more note objects (not shown) of the class note 905 use or interface with an object from the master database item 920.
The class master database item 920 uses the class current status 910 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each current status object (not shown) of the class current status 910 uses or interfaces with an object from the class master database item 920. The class master database item 920 uses the class classification 915 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more classification objects (not shown) of the class classification 915 use or interface with an object from the master database item 920.
Finally, the class master database item 920 uses the class master classification category 930 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes). In other words, zero or more classification objects (not shown) of the class classification 915 use or interface with an object from the master database item 920.
Figure 9 also illustrates that the class item note category 935 uses the class master note category 925 with a cardinality for this relationship of one to one (represented by the "1" above either end of the double line connecting these classes). That is, each master note category object (not shown) of the class 925 uses or interfaces with an object from the class item note category 935.
The class <X> database item 940 uses the class item note category 935 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes); the class <X> database item 940 uses the class item classification category 945 with a cardinality for this relationship of zero or more to one (represented by the "*" and the "1" above the respective ends of the double line connecting these classes); and the class <X> database item 940 uses the class status state machine 950 with a cardinality for this relationship of one-to-one (represented by the "1" above either end of the double line connecting these classes) . 3 The GENOA global class category 330, the CSX global class category 335, and the AT&T global class category 340 each contains general purpose math and data structure classes, as is known to those of ordinary skill in the art.
Internal Object Architecture
Having a greater understanding of the external architecture of the preferred implementation of the present invention, one can appreciate the internal object architecture, or the physical structure of objects, and the functions or operations performed on objects by the preferred implementation to manage a facility.
The Object
In the preferred implementation, objects of classes (discussed above with reference to Figures 4- 9) are represented, in a data processing system, by using objects of the class relative cell 430 (Figure 4). That is, attributes corresponding to the class relative cell 430 are used to represent all objects of the classes managed by the preferred implementation.
As discussed above, a class is a template for the creation of objects. Associated with each class is a set of one or more attributes that are considered part of the template used to create objects of the class. Methods are also associated with classes. Objects of a class have specific (or unique) data values corresponding to the attributes of the class template. Objects of a class also have appropriate references (or pointers) to identify the methods associated with the class that may be performed on the objects of the class. The specific data values are sometimes referred to as the attributes of the object of a class. An example of this is illustrated in Figure 10. In Figure 10, the attributes 1020 are associated with the class relative cell 430 and each object (not shown) of the class relative cell 430 would have specific data values or attributes for each of the attributes of the class relative cell 430. The methods 1025 are also associated with the class relative cell 430. This means that a relative cell object (not shown) would contain an appropriate reference or pointer to the methods 1025 to permit the methods 1025 to be performed on the relative cell object.
The attributes 1030 are associated with the class "<name>" 1040. "<name>" is used to illustrate that any class name discussed above with reference to Figures 4-9 may be used in place of "<name>". In other words, "<name>" is a variable and can be replaced by, for example, "location" or "container". In the case where "<name>" is replaced by "location", the attributes 1030 would the be the attributes for the class location 410. The methods 1035 are also associated with the class "<name>" class 1040.
"<name>" object 1050 is a label for the object 1060. Again, "<name>" is variable. Thus, if "<name>" is "location," then the object 1060 would be an object of the class location 410 (Figure 4). The object 1060 is comprised of data values (or attributes) corresponding to the attributes 1020 of the class relative cell 430 and the data values (or attributes) corresponding to the attributes 1030 of the class "<name>". This is illustrated in Figure 10 by blowing up the attributes 1070 and 1080 of the object to be represented by the attributes 1020 and 1030, respectively. The object 1060 also includes pointers (or references) 1082 and 1084 to reference the methods 1025 and 1035 of the classes relative cell class 430 and "<name>" class, respectively. As discussed in detail below, the preferred implementation performs functions by sending messages to objects and, based on the particular message and the methods referenced by the receiving object, an appropriate method is selected from among the referenced methods to be performed on the object.
The object 1060 also includes attributes and method references 1090 that are values and pointers to methods corresponding to global classes that are templates for all objects. The attributes of these global classes include parent object reference, which is a pointer to the parent object of the object 1060 and a children object list, which is a set of pointers to the objects that are called children of the object 1060.
For example, attributes of the class relative cell 430 (Figure 4) include size, weight, capacity size, capacity weight, list of classification categories with one classification each, list of note categories with one note each, and current state and state machine (including state transition rules). The methods for the class relative cell 430 include create relative cell, destroy relative cell, select classification, deselect classification, add note, update note, delete note, add classification category, remove classification category, add note category, remove note category, read order classification categories, read order note categories, read order state machine, read current notes, read current classifications, set parent, remove parent, read parent, set offset in parent, read offset in parent, set children, add child, remove children, remove child and read children. If, for example, the "<name>" of "<name>" class 1040 is "location", then the attributes 1030 is comprised of location ID and the methods of the class location are create location, destroy location, and set ID. A location object 1060 would therefore include attributes corresponding to the attributes 1020 of the relative cell class 430, the attributes of the location class 1030, references to the methods 1025 of the relative cell class, and references to the methods 1035 of the location class. The location object 1060 would also include attributes corresponding to global class characteristics and references to global class methods. Object Containment Tree
Using objects of the type illustrated in Figure 10, the preferred implementation constructs a model (or object containment tree) of a material management facility. An object is said to be "contained" by its parent, or a parent object is said to contain one or more child objects. The model is comprised of parent objects and children objects and is used to manage (or handle) information representative of the facility and the activities or work being performed in the facility.
The object containment tree begins with an object of the class containment tree 440 (Figure 4). This object is unique. It is the only object in an object containment tree that is comprised only of a pointer to the first or root object in the tree. Figure 11 illustrates an example of an object containment tree, i.e., object containment tree 1100, that is called Representative Warehouse Model. The object containment tree 1100 will be used to describe the functions of the preferred implementation.
As shown in Fig. 11, the object containment tree 1100 represents a single file containing all of the information (stored in a data processing system of the type illustrated in Figure 1) required to maintain a material management facility. In general, an object containment tree is comprised of one or more objects. It may therefore be said that the preferred implementation manages objects of the type described above. The objects in the object containment tree 1100 are different and contain data values corresponding to the class attributes as discussed above. The objects also obey the rules of inheritance among classes as discussed above.
In the object containment tree 1100 of Figure 11, a facility is modeled using objects of the following classes: containment tree 440 (Figure 4), relative cell 430, location 410, container 415, material 505 (Figure 5), order 605 (Figure 6), order item 615, and agent 825 (Figure 8). As stated above, objects have unique sets of data values.
In the example object containment tree 1100, the containment tree object 1102 is at the top of the tree 1100. As discussed above, this object 1102 is unique from other objects in that its only attribute is a pointer to a root object. Because the location of the containment tree object 1102 is predetermined, the object 1102 permits the preferred implementation to locate the root object of the object containment tree. The object 1105 is, therefore, referred to as the "root object. "
The object 1105 is a location object having attributes corresponding to the attributes of the relative cell class 430 and the location class 410 as well as global attributes common to all objects. The attributes of the object 1105 corresponding to these global attributes are the parent reference and child references. That is, the parent reference identifies the tree object 1102 as the parent of the location object 1105, and the child references identify objects 1110, 1115, and 1120 as objects that are children to (or are contained in) the object 1105. This parent- child relationship between the objects in the example tree 1100 is illustrated using lines having arrows on either end of the line.
By way of the example, the unique data values of the object 1125, which is a container object, are "Carton 111". This means that the object 1125 represents carton number 111 in the facility. The object 1150, which is a material object, contains the data values "1 ea Socks". This means that the object 1150 represents a material (in a container (see object 1130) in a receiving dock (see object 1110) of a warehouse (see object 1105)): one each of socks.
Another example is the object 1135 which is an order object. The order object 1135 contains a reference to its parent object 1115 and references to its children, objects 1165, 1170, and 1175, as well as the unique data values "Acme P.O. #014". The unique data in order 1135 represents an order placed by "Acme" and has an order number "014".
Objects 1125, 1150, and 1135 are merely examples used to illustrate the example object containment tree 1100 and to explain, in general, the tree structure and the relationship between the objects in the tree 1100. The other objects in the tree 1100 may be easily understood in light of these examples.
System Operations
Having an appreciation for the structure of objects and the internal architecture of the preferred implementation, including the object containment tree, the operations of the preferred implementation that fall into three types of operations, namely, add, delete, and modify, will now be described. In other words, the preferred implementation provides for the processes used to add nodes (or objects) to an object containment tree, delete nodes from an object containment tree, and modify nodes of an object containment tree. These processes will now be explained with reference to the object containment tree 1100 of Figure 11.
In the preferred implementation, operations or processes (performed in a data processing system) used to manage a facility are initiated by users by way of input interfaces or windows generated on the display screen 122 of the display 120 (Figure 2). How windows are generated on the display screen 122 is conventional and, therefore, will not be described below. The preferred implementation uses a commercially available software package such as "Interviews", along with certain modifications to follow the "Motif" standard, to implement the windows described below.
Add Object to Object Containment Tree User Interface for Add Process
When a user selects the Add Object option from a main menu bar (not shown), which is a bar across the top of the display screen 122, and then selects the class of the object that he/she wants to add to the object containment tree, the preferred implementation generates a window for the user to enter data for the object to be added to the tree. Figure 12(a) illustrates an example window generated by the preferred implementation that is used to add an object of the class material 505 (Figure 5) to the object containment tree, for example, the object containment tree 1100.
In Figure 12(a), the field 1201 shows the title of the window. The field 1202 includes a prompt "Quantity," and an enterable field (illustrated using the empty rectangle directly to the right of the prompt). An enterable field is an area on the screen in which the user may enter variable information (or data values) or, in the case of an existing material object in the object containment tree, where data values already attributes of a material object may be displayed.
The field 1203 is comprised of the prompt "Material ID," and enterable field, and a browser. The browser is illustrated in Figure 12(a) by the "gadget" next to the enterable field of the field 1203. Gadgets are areas of a display screen that represent an operation or function that may be performed in connection with information on the display screen. For example, the gadget of field 1203 represents a browse function that may be used by the user to browse through a list of, for example, material identifications, to select the material identification to be entered in the enterable field of field 1203.
The field 1204 is comprised of a prompt "Material" and a nonenterable field "<Material>" which represents a generated material name looked up by the system. The field 1205 includes a prompt "Status," an enterable field and list gadget. A default for this enterable field comes from a state machine and the list gadget is used to scroll through a list of possible states to be selected for the enterable field of field 1205.
The field 1206 is comprised of a prompt "Manufacture Date," and an enterable field. The field 1207 includes a prompt "Lot ID," an enterable field, and a browser. The field 1208 includes the prompt "Serial #" and an enterable field. The field 1209 includes a prompt "Inventory" and framed buttons. Buttons in windows are used to make selections between choices shown on the display screen. Unlike gadgets, these buttons do not perform functions. Rather, they are used to signify a condition (yes or no).
The field 1210 is the label for a frame containing fields 1211 and 1212. Field 1211 includes the prompt "Located in," and enterable field, and a tree browser. The tree browser permits the user to browse through (or traverse) the object containment tree to identify a parent object (in the enterable field) in which, for example, the material object to be added is said to be contained. The field 1212 includes a set of label prompts "Located At," "quantity," "U of M, " "x-offset," "y-offset," and "z- offset" as well as enterable fields for the offsets followed by list gadgets.
The field 1213 includes a fixed label for a frame of fields containing several prompts, enterable fields, and list gadgets. The field 1214 is a labeled frame "Classification" which contains the field 1215. The field 1215 includes a labeled list of prompts, enterable fields with list gadgets, and a scroll bar. The field 1216 is another labeled frame "Note" which contains the field 1217. The field 1217 is comprised of a labeled single list of note categories which represents the types of notes which could be added to each object.
The window illustrated in Figure 12(a) also includes several gadgets 1218, 1219, 1220, 1221, and 1222. The gadget 1218 is labelled "Edit Note." This gadget is pushed (using the button on a mouse) to instruct the preferred implementation to edit the note. The gadget 1219 is labelled "Schedule" and is pushed (using the button on a mouse) to instruct the preferred implementation to schedule an "Add" for a later time. The gadget 1220 is labelled "Add & Next" and is pushed (using the button on a mouse) to instruct the preferred implementation to add the object and return to the same screen, ready to add the next object. The gadget 1221 is labelled "Add" and is pushed (using the buttons on a mouse) to instruct the preferred implementation to add a material object, including the data values of the enterable fields, described above, to the object containment tree. Finally, the gadget 1222 is labelled "Cancel Current" and is pushed (using the button on a mouse) to instruct the preferred implementation to cancel the current "Add" message. Add Object Process
The preferred implementation adds objects to the object containment tree in accordance with the steps illustrated by the flow diagram of Figure 12(b).
First, the user selects the add object option of the system (step 1250) by pushing (using the buttons or a mouse) the gadget labelled "Add" of the screen shown in Figure 12(a). Next, using the enterable field for the Located In prompt (and the associated tree gadget) included in an appropriate window, for example, the window of Figure 12(a), the user starts at the root of the object containment tree and traverses the tree until the existing object in which the new object is to be contained is found (step 1255). The existing object is said to be the parent of the new object. Once the existing object is located, the attribute for "located in" of the existing object is saved by the preferred implementation (step 1260). This attribute is a reference pointer to the parent object of the new object. Then, using the appropriate window corresponding to the class of the object to be added to the object containment tree, the user enters data values for the new object into the enterable fields of the window (step 1265). The data values become parameters (including the location of the parent object corresponding to the Located In enterable field) for a message. When the user has completed entering information into the window, the user pushes the Add gadget of the window to instruct the preferred implementation to send the add message to the class of the object to be added to the object containment tree (including the data values for the new object as parameters) (step 1270).
In the preferred implementation, the class then receives the add message and creates an object of the class type (e.g., material object) (step 1275). Finally, the attributes of the newly created object are set using the parameters of the add message (step 1280).
The steps 1270 through 1280 may also be understood as comprising the step Call Add Operation. In this step, when the user pushes the Add gadget, the Add Object function of the preferred implementation is initiated by calling the add function (method associated with a selected class).
In the preferred implementation, certain operations that are repeated during the operation of the system (and that are associated with classes), are maintained in class libraries. Thus, when the Add Object function (or method) is called, the preferred implementation references the object's class to locate the Add Object function to be executed. A function call typically consists of an identification of the function to be called followed by a list of function parameters.
The Add Object function then creates an object of the class identified in a parameter of the call and sets the data values of the newly created object using other parameters from the function call. In this step, the parent-child relationship between the new object and existing objects in the object containment tree is established using the located-in parameter of the function call.
Examples
The operation of adding an object to the object containment tree will now be illustrated by way of the examples illustrated in Figures 13 and 14.
In Figure 13, an object 1310 of the type material class is added to the tree 1100 shown in Figure 11. That is, using the process outlined in steps 1250-1280 of Figure 12(b), the user can add the material object 1310 by entering the data into a window, traversing the tree to locate where the new object is to be added (or identify the parent cell 1125) and add the new object to the tree 1100. In this example, the new object is added as a leaf node of the parent 1125.
In the example illustrated in Figure 14, the new object 1410 in this case is contained in the parent cell 1115.
Delete Cell in Object Containment Tree
The preferred implementation also provides the function of deleting objects from an object containment tree. This function includes generating an appropriate user interface (window) for the user to identify the object(s) to be deleted from the object containment tree and then physically deleting identified object(s) from the tree. The deletion of objects will also be explained with reference to the example object containment tree 1100. Illustrations of deleting a leaf node and an intermediate node from the object containment tree 1100 will also be illustrated.
User Interface for Delete Process
The user interface for the delete process of the preferred implementation is illustrated in Figure 15(a). Like the window for the add process explained in detail above, the window for the delete process also includes prompts, enterable fields, and gadgets. Specifically, the window 1500 illustrated in Figure 15(a) is an example of the window used to delete an object of the class material from the object containment tree. In Figure 15(a), the field 1501 is the title of the window and identifies this window as the Select Material window. Briefly, the field 1502 is comprised of fixed labels Material ID, Material, Located In and Status. The field 1503 is called a multiple selection list of Material. This means that multiple material items may be selected for simultaneous deletion. The field 1503 also includes a scroll bar. The field 1504 is a gadget labelled "Select All" that is used to identify or mark all relative cell structures (each corresponding to a relative cell object and a material object) listed in field 1503 to be deleted. To identify specific relative cell objects (material objects), the user depresses a mouse button which highlights the particular object. The field 1505 is a gadget labelled "Clear All." In contrast to the gadget 1504, gadget 1505 clears all marked material objects so that no objects are marked for deletion. The field 1506 is a gadget labelled "Export" and is used to export data to other computer systems. The field 1507 is a gadget labelled "View" and is used to display data for the selected objects on the display screen 122. The field 1508 is a gadget labelled "Delete" and is pressed using the button on a mouse to initiate the delete process explained below. The field 1509 is a gadget labelled "Update" and is used to modify data of the selected objects. And the field 1510 is a gadget labelled "Cancel" and is used to cancel the current message.
Delete Process
The process of deleting objects from the object containment tree will now be described with reference to Figure 15(b) .
To delete an object from the object containment tree, the user first selects the Delete option from the main menu bar (not shown) (step 1550). In a manner similar to that used in the add object process described above, the user then traverses the object containment tree to identify the object to be deleted (step 1555). The location of the object to be deleted is then saved (step 1560).
Next, using the Select Material window of Figure 15(a), the user presses the delete gadget 1508 to initiate the delete process which begins by sending the delete message to the object to be deleted (step 1565). The message includes the location of the object saved in step 1560. The object then receives the message sent in step 1565 (step 1570) and performs the method of the class referenced by the object to delete itself from the object containment tree (step 1575).
The delete method of all classes is performed by deleting the reference (or attribute) in the identified object (to be deleted) to its parent cell and releasing the memory allocated to it back to the operating system. This has the effect of deleting the relative cell from the object containment tree.
Examples
Figures 16 and 17 illustrate examples of the object containment tree 1100 of Figure 11 after deleting a leaf node 1145 (Figure 16) and an intermediate node 1130 (Figure 17).
In Figure 16, the object (or leaf node) 1145 is illustrated with hatching to represent that the object 1145 has been deleted from the object containment tree 1100 (using the process outlined above with reference to Figure 15(b)) by eliminating the pointer or reference between object 1145 and its parent, object 1125.
In Figure 17 the object (or intermediate node) 1130 has been deleted, by deleting its reference to the parent object 1115. Deleting object 1130 has the effect of deleting all objects that are contained in object 1130 (i.e., object 1150, object 1155, and object 1160) .
Modify Cell in Object Containment Tree
The preferred implementation also provides the functions of modifying or updating objects in an object containment tree. These functions include generating appropriate user interfaces (windows) for the user to identify the object(s) in the object containment tree to be modified and then modifying the identified object.
Modifying an object can include modifying the contents or data values in the object or changing the parent object of the identified object to be modified. The modification of objects will also be explained with reference to an example of modifying a leaf node (or object) and an intermediate node (or object) in the object containment tree.
User Interface for Modify Process
The window (user interface) for the update object function is illustrated by way of the example window in Figure 18(c). Figure 18(c) illustrates the update window for the relative cell structure in the object containment tree that has the special attributes of a material object. The field 1801 in Figure 18(c) is the title of the window "Update <Material>." The word Material is in "<>" to show that this title is a variable. In other words, if one object is to be updated, then the title of the window is "Update Material." However, if more than one object is to be updated then the title of this window would be "Update Multiple Materials. "
Most of the fields in Figure 18(c) have corresponding fields of the same type in the window illustrated in Figure 12(a). In this case, the common fields between the Figures 12(a) and 18(c) are labelled in Figure 18(c) using the same labels used in Figure 12(a). The window of Figure 18(c), however, does not include the fields 1220, 1221, and 1222 of the window of Figure 12(a). Instead, the window of Figure 18(c) includes the field 1820 which is a gadget labelled "Update," and field 1821 which is another gadget labelled "Cancel." Update 1820 is depressed by the user using the buttons on a mouse to initiate the update object process described below. The Cancel gadget 1821 is depressed to cancel the current message.
Modify Process
As discussed briefly above, one of the functions of the preferred implementation is to update or modify objects in an object containment tree. This process will now be described with reference to the flow diagram of Figure 18(d).
First, to modify an object in the object containment tree, the user selects the Modify option from the main menu bar (not shown) (step 1850). This brings the user to the Select Action window 1900 of Figure 18(a). Then, the user presses the search gadget from the Select Action window 1900 which takes the user to the Search for Material window 2000 of Figure 18(b) (step 1855). Next, in a manner similar to that used in the add object and delete object processes described above, the user then traverses the object containment tree to identify the object to be modified (step 1860). Then, the user presses the search gadget from the Search for Material window 2000 (step 1865). This takes the user to the Select Material window 1500 of Figure 15(a). Next, using the Select Material window 1500, the user presses the update gadget 1509 (step 1870). This takes the user to the Update <Material> window 1800 of Figure 18(c).
Using the window of Figure 18(c), the user then enters or modifies the data of the existing object (step 1880) followed by depressing the Update gadget in the appropriate window. Pressing the Update gadget has the effect of initiating an update by sending an update message to the object (including any updated object data values and, optionally, the previously saved reference to the object in which the object to be modified is contained) (step 1885). After the update process is initiated, the object receives the update message and locates the appropriate method of the class of which the object belongs, using the method references associated with all objects of each class type, and provokes the execution of the selected method to change the data values of the object in accordance with the parameters of the received message (step 1890). These parameters are the modifications to the object indicated by the user in the modify window. Changing the identified object's Located In attribute has the effect of moving or relocating the object in the object containment tree. This is illustrated in Figures 19 and 20 which are discussed below.
Examples
Figure 19 illustrates the tree 1100 of Figure 11 following a modification, performed in accordance with the steps shown in Figure 18(b). In Figure 19, the object (leaf node) 1175 is updated. This update included changing the contents or data values of the object 1175 as well as changing the parent-child relationship of the object. In Figure 19, the object 1175 is now contained in the parent object 1140, instead of object 1135 (see Figure 11). In Figure 20, the intermediate object 1135 is modified by changing its data values (changing Acme to ABC) as well as changing the object containment tree 1100 to reflect the fact that the object 1135 is now contained in object structure 1120. As discussed above, changing the parent object 1135 requires only changing the located-in attribute of the object by changing the located-in field in the appropriate window used to modify the object.
Summary
The present invention thus provides an efficient and simple tool for managing one or more facilities.
Because, in accordance with the object oriented techniques of this invention, classes of objects containing specific data values are managed, the data values themselves are not important. The organization of the classes of objects is important because it is that organization which dictates how objects are managed. By managing only objects in a single object containment tree, the requirements on system resources are reduced, and the flexibility of the system is increased.
Another advantage afforded by this invention is the ability to reorganize the containing relationships between the objects. This further enhances the power and flexibility of systems implemented in accordance with this invention.
Persons of ordinary skill will recognize that modifications and variations may be made to this invention without departing from the spirit and scope of the general inventive concept. This invention in its broader aspects is, therefore, not limited to the specific details or representative methods shown and described.

Claims

Claims
1. In an object oriented data management system for maintaining a facility, the data management system including a data processing system having a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects, a method of adding a new object to the object containment tree performed by the data processing system, comprising the steps of: designating a class of the new object; selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; sending a message to the class of the new object to create the new object; and adding the new object to the object containment tree.
2. The method of claim 1, wherein the step of selecting one of the objects in the containment tree includes the step of traversing the object containment tree until the selected object is found.
3. The method of claim 1, wherein the step of adding the new object to the containment tree includes the step of: saving a data value of the new object, the data value being a reference pointer to the selected object and the reference pointer being a parameter for the message.
4. The method of claim 1, wherein the step of sending the message to the class of the new object to create the new object includes the steps of: calling an add method of the class of the new object, the called add method being identified by the sent message; and executing the called add method.
5. In an object oriented data management system for maintaining a facility, the data management system including a data processing system having a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects, a method of deleting an object from the object containment tree performed by the data processing system, comprising the steps of: selecting one of the objects in the object containment tree to be deleted; and sending a message to the selected object to delete the selected object from the object containment tree.
6. The method of claim 5, wherein the step of selecting one of the objects in the object containment tree includes the steps of: traversing the object containment tree until the selected object is found; and storing a location of the selected object.
7. The method of claim 5, wherein the step of sending the message to the selected object to delete the selected object includes the steps of: calling a delete method of the selected object, the called delete method being identified by the sent message; and executing the called delete method.
8. In an object oriented data management system for maintaining a facility, the data management system including a data processing system having a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such each of the children objects is associated with a respective one of the parent objects, a method of modifying an object in the object containment tree performed by the data processing system, comprising the steps of: selecting one of the objects in the object containment tree to be modified; and sending a message to the selected object to modify at least one of the data values contained in the selected object.
9. The method of claim 8, wherein the step of selecting one of the objects in the object containment tree includes the steps of: traversing the object containment tree until the selected object is found; and storing a location of the selected object.
10. The method of claim 8, wherein the step of sending the message to the selected object to modify at least one of the data values contained in the selected object includes the steps of: calling a modify method of the selected object, the called modify method being identified by the sent message; and executing the called modify method.
11. A data processing system including an object oriented data management system for maintaining a facility, comprising: a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for designating a class of the new object; means for selecting one of the objects in the object containment tree, the selected object being a parent object of the new object and the new object being a child object of the selected object; means for sending a message to the class of the new object to create the new object; and means for adding the new object to the object containment tree.
12. The data processing system of claim 11, wherein the means for selecting one of the objects in the containment tree includes means for traversing the object containment tree until the selected object is found.
13. The data processing system of claim 11, wherein the means for adding the new object to the containment tree includes: means for saving a data value of the new object, the data value being a reference pointer to the selected object and the reference pointer being a parameter for the message.
14. The data processing system of claim 11, wherein the means for sending the message to the class of the new object to create the new object includes: means for calling an add method of the class of the new object, the called add method being identified by the sent message; and means for executing the called add method.
15. A data processing system including an object oriented data management system for maintaining a facility, comprising: a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent objects; means for selecting one of the objects in the object containment tree to be deleted; and means for sending a message to the selected object to delete the selected object from the object containment tree.
16. The data processing system of claim 15, wherein the means for selecting one of the objects in the object containment tree includes: means for traversing the object containment tree until the selected object is found; and means for storing a location of the selected object.
17. The data processing system of claim 15, wherein the means for sending the message to the selected object to delete the selected object includes: means for calling a delete method of the selected object, the called delete method being identified by the sent message; and means for executing the called delete method.
18. A data processing system including an object oriented data management system for maintaining a facility, comprising: a memory for storing substantially all data necessary to maintain the facility, the data representing attributes and methods associated with classes containing objects of the facility, each of the objects containing data values corresponding to attributes associated with a respective class and references to methods associated with the respective class, the objects being organized into an object containment tree as children objects and parent objects such that each of the children objects is associated with a respective one of the parent - objects; means for selecting one of the objects in the object containment tree to be modified; and means for sending a message to the selected object to modify at least one of the data values contained in the selected object.
19. The data processing system of claim 18, wherein the means for selecting one of the objects in the object containment tree includes: means for traversing the object containment tree until the selected object is found; and means for storing a location of the selected object.
20. The data processing system of claim 18, wherein the means for sending the message to the selected object to modify at least one of the data values contained in the selected object includes: means for calling a modify method of the selected object, the called modify method being identified by the sent message; and means for executing the called modify method.
PCT/US1993/000429 1992-01-31 1993-01-27 Method and apparatus for an object oriented material management system WO1993015469A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US83120792A 1992-01-31 1992-01-31
US07/831,207 1992-01-31

Publications (1)

Publication Number Publication Date
WO1993015469A1 true WO1993015469A1 (en) 1993-08-05

Family

ID=25258538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1993/000429 WO1993015469A1 (en) 1992-01-31 1993-01-27 Method and apparatus for an object oriented material management system

Country Status (2)

Country Link
AU (1) AU3655793A (en)
WO (1) WO1993015469A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999057664A1 (en) * 1998-05-04 1999-11-11 Wonderware Solutions, Inc. Systems and methods for automated order processing

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0408812A1 (en) * 1989-07-21 1991-01-23 Hewlett-Packard Company Distributed object based systems
US5063507A (en) * 1990-09-14 1991-11-05 Plains Cotton Cooperative Association Goods database employing electronic title or documentary-type title

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0408812A1 (en) * 1989-07-21 1991-01-23 Hewlett-Packard Company Distributed object based systems
US5063507A (en) * 1990-09-14 1991-11-05 Plains Cotton Cooperative Association Goods database employing electronic title or documentary-type title

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CERI S., ET AL.: "ALGRES: AN ADVANCED DATABASE SYSTEM FOR COMPLEX APPLICATIONS.", IEEE SOFTWARE., INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, US, vol. 07., no. 04., 1 July 1990 (1990-07-01), US, pages 68 - 78., XP000137898, ISSN: 0740-7459, DOI: 10.1109/52.56451 *
Database INSPEC Institute of Electrical Engineers, LONDON E. Kindler et al: 'An analytical view at the production process', INPEC Nr. 3099041 *
PROCEEDINGS OF THE 25TH ACM/IEEE DESIGN AUTOMATION CONFERENCE June 1988, pages 275 - 281 CHOU H. ET AL. 'Versions and change notification in an object-oriented database system' *
PROCEEDINGS OF THE SECOND IEEE SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING December 1990, DALLAS, US pages 160 - 163 F. MARIATEGUI ET AL. 'A Transaction Definition Based on Message Parsing' *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999057664A1 (en) * 1998-05-04 1999-11-11 Wonderware Solutions, Inc. Systems and methods for automated order processing

Also Published As

Publication number Publication date
AU3655793A (en) 1993-09-01

Similar Documents

Publication Publication Date Title
US5715413A (en) Dragging and dropping with an instantiation object
Kang 4A1\
USRE44652E1 (en) Computer-readable data product for managing sales information
US5361199A (en) Automated procurement system with multi-system data access
Davis et al. Towards an integrated information environment with open hypermedia systems
US5530861A (en) Process enaction and tool integration via a task oriented paradigm
US6388683B1 (en) Object oriented data arranger graphical user interface
CN108369481B (en) Method and system for creating configurable forms, configuring forms, and for correlating forms with forms
EP0520924B1 (en) Container object management system
US5819270A (en) Computer system for displaying representations of processes
CA2156917C (en) A computerized handbook of processes
US20050235206A1 (en) User interface for a quick activity window
US20050235251A1 (en) User interface for an object instance floorplan
KR20030015217A (en) Method and system for top-down business process definition and execution
CN104106066A (en) System to view and manipulate artifacts at temporal reference point
US20110246535A1 (en) Apparatus and Method for Constructing Data Applications in an Unstructured Data Environment
US20050235223A1 (en) User interface adaptable by an end user
US9244989B2 (en) Setting and displaying primary objects for one or more purposes in a table for enterprise business applications
US20050235208A1 (en) User interface for a guided activity window
Montgomery Object-oriented information engineering: analysis, design, and implementation
US20050234939A1 (en) System and method for progressively disclosing information to a computer user
Rodden et al. Interacting with an active, integrated environment
WO1993015469A1 (en) Method and apparatus for an object oriented material management system
CA2723355A1 (en) Method and system for providing visual instructions to warehouse operators
Iivari Object-oriented information systems analysis: A framework for object identification

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA