+

WO1994023362A1 - Objets comportementaux - Google Patents

Objets comportementaux Download PDF

Info

Publication number
WO1994023362A1
WO1994023362A1 PCT/US1994/003588 US9403588W WO9423362A1 WO 1994023362 A1 WO1994023362 A1 WO 1994023362A1 US 9403588 W US9403588 W US 9403588W WO 9423362 A1 WO9423362 A1 WO 9423362A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
behavior
target object
target
methods
Prior art date
Application number
PCT/US1994/003588
Other languages
English (en)
Inventor
Erik Richard Neumann
Original Assignee
Kalieda Labs, Inc.
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 Kalieda Labs, Inc. filed Critical Kalieda Labs, Inc.
Priority to AU64190/94A priority Critical patent/AU6419094A/en
Publication of WO1994023362A1 publication Critical patent/WO1994023362A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented

Definitions

  • the present invention relates to a computer system running in an object oriented programming environment and more particularly to methods and means for associating behavior with objects in the environment.
  • multimedia scripting languages can be found in such computer software program products as HyperCard, developed by Apple Computer, Inc., MacroMind Director, developed by MacroMedia Inc. , and Authorware Professional from MacroMedia, Inc. These multimedia scripting languages require the multimedia author to learn all the intricacies of the scripting language and to develop scripts comprising several hundred lines of code to create desired behaviors. This code is difficult to develop and typically cannot be readily reused.
  • the technique of multiple inheritance requires the author to (1) write a new class in order to use the behavior and (2) have the knowledge and skill to resolve the conflicts between the classes.
  • the use of this technique is typically found in programming environments involving compilers, linkers, and debuggers. As a result, this technique can only be learned and used after years of formal training.
  • the technique of multiple inheritance is typically not available to a non-programmer author in an interactive real time environment where incremental experimentation allows for rapid learning and exploration.
  • Existing environments also do not provide a convenient mechanism for changing the behavior of an object over time while the program is running.
  • the new class always inherits from the mix in class. As a result, the environment can result in a proliferation of confusing and complex classes.
  • the present invention relates to a system having an object oriented programming environment.
  • the environment includes a plurality of classes and objects.
  • Each object communicates with other objects in the environment by sending messages which invoke methods in these other objects.
  • the environment contains at least one object (target object) which contains one or more methods (universal methods) used for communicating with another object, such as an object (behavior object) that implements a behavior of the target object.
  • object such as an object (behavior object) that implements a behavior of the target object.
  • These universal methods are typically included in all of the target objects in the environment, along with associated universal instance variables used by the universal methods, thereby forming a universal protocol or interface to target objects.
  • the behavior object In order to implement the behavior (e.g., make the target object bounce) , the behavior object must obtain and modify certain properties of that target object, e.g., getting and setting its position. In the present invention, the behavior object obtains and modifies these properties by invoking the universal method(s) residing in the target object. Since the existence and the manner of invoking these universal methods are know at least to behavior objects (e.g., through a published interface or by internal decree of a company or individual) , a behavior object can directly invoke
  • a target object acquires a behavior from the behavior object without having to maintain an inheritance relationship with the class from which the behavior object is derived. Communication between the behavior object and the target object is accomplished through the universal protocol (method and instance variables) . Consequently, the above mentioned problems in the prior art approaches can be avoided.
  • a "box" object and a “ball” object might contain universal methods for setting their color, position, etc.
  • a behavior object (bounce object) might contain a method (bounce method) for implementing a particular behavior, such as "bounce.” This method calculates the position of the controlled target object at the current time.
  • that object By associating the target object with the bounce object (by means of an explicit command rather than through inheritance) , that object will attain the ability to bounce, i.e., by supplying the information requested and ultimately changing its position and related properties in accordance with the algorithms implemented by the bounce method, using the universal protocol.
  • the target object may also contain one or more optional methods and related instance variables (optional protocol) relating to other properties of the target object. This optional protocol or interface is also known to behavior object. But, before invoking the optional methods, the behavior object needs to ascertain the existence of these optional methods in its associated target object.
  • Fig. 1 is a drawing showing an object communication system according to the present invention.
  • Fig. 2 is a drawing showing the structure of a target object of the present invention.
  • Fig. 3 is a drawing showing the methods module of the target object of Fig. 2.
  • Fig. 4 is a flow chart showing the use of the methods module of the present invention.
  • Fig. 5 is a drawing of a computer system containing an object oriented programming environment according to the present invention.
  • Fig. 6 is a drawing showing the communication process between an interpolate object and a target object of the present invention.
  • Fig. 7 is a flow chart of the communication process between an interpolate object and a target object of the present invention.
  • Fig. 8 is a drawing showing the communication process between a bounce object and a target object of the present invention.
  • Fig. 9 is a drawing showing target objects in a container in accordance with the present invention.
  • Fig. 10 is a flow chart of the communication process between a bounce object and a target object of the present invention.
  • Fig. 11 is a drawing showing a graphic user interface system containing icons in accordance with the present invention.
  • FIG. 1 illustrates an object communications system in accordance with the present invention.
  • the system facilitates communications among objects in an object-oriented programming environment.
  • the system of Fig. 1 comprises three classes, class A, class B, and class C, shown as reference numerals 110, 120, and 130, respectively.
  • Each class may consist of an enumerated number of objects which are derived from the class.
  • Fig. 1 also shows an object A derived from class A, an object B derived from class B, an object C derived from class C, and an object D derived from class C; these objects are shown in Fig. 1 as reference numerals 112, 122, 132, and 134, respectively.
  • Each object has the ability to send and receive certain messages in accordance with predefined capabilities of such object.
  • Any particular object of a class may be in communication with one or more objects derived from the same or another class.
  • Direct communication between objects in classes A and B enable object A derived from class A to affect the behavior of object B derived from class B by sending it a specific message.
  • a typical message may be a request for data or information, a transmission of data or information, a query as to the other object's ability to perform certain methods, or an instruction to execute certain operations, to undertake certain actions, or to perform certain functions.
  • one of the objects for example, object A, which is derived from Class A, is a conductor object.
  • the conductor object contains a list of objects that are active and coordinates their use of shared resources, such as a monitor.
  • the conductor is responsible for the smooth updating of the screen of the monitor by compositing the objects on the screen in an efficient way.
  • One of the classes for example, class B, is a behavior class and objects of class B, such as object B, are called behavior objects.
  • the objects which could be affected by the behavior objects, such as objects C and D, are called target objects.
  • each behavior object is associated with a single target object, though a target object can be associated with multiple behavior objects.
  • FIG. 2 shows a target object 200 consisting of two components: (1) a data field 210, and (2) a methods module 220.
  • Data field 210 contains data that is accessible by methods module 220.
  • Data field 210 is private to target object 200, i.e., it is accessible only by the methods module 220 of target object 200.
  • the methods module of an object serves as the means by which the object communicates with other objects.
  • the details of methods module 220 of FIG. 2 is depicted in FIG. 3.
  • Methods module 220 consists of a set of methods 222, further divided into a set of universal methods 226 and a set of optional methods 228, and a set of additional methods 224.
  • the universal methods (and their associated instance variables) are, in this embodiment, common to all target objects, i.e., every target object contains the same set of universal methods and instance variables.
  • a behavior object can send messages to invoke members of the set of universal methods 226.
  • the universal methods 226 are essentially the fundamental functions and operations that all target objects are expected to be capable of performing in response to messages from the behavior objects. Examples of universal methods are methods to determine the position, size, and color of a target object. Universal methods provide consistency and predictability among different objects. A listing of exemplary universal methods and instance variables is given in Table 1.
  • the set of optional methods (and their associated instance variables) is incorporated in some of the target objects.
  • a behavior object needs to send messages to determine whether a target object can respond to an optional method before invoking that method.
  • a listing of exemplary optional methods and instance variables is given in Table 2.
  • the additional methods 224 of target object 200 are those methods which are not part of the universal or optional protocol, and thus, cannot be expected to be known to behavior objects.
  • the set of universal methods and instance variables is incorporated in a parent class.
  • the classes which inherit from this parent class contain the universal method and instance variables. Each of these classes may also contain a set of optional methods and instance variables.
  • the universal methods can be implemented by unrelated classes (i.e., classes not related by inheritance) .
  • a behavior object is designed to be able to invoke only those universal methods or optional methods which are required to implement its behavior. There is no need to include code to invoke universal methods it does not need. As a result, the behavior object can be efficiently designed.
  • the programming considerations in the design of a behavior object are illustrated by flow chart 250 of FIG. 4. If the behavior object wishes to send a message to a target object to invoke a universal method, the behavior object can simply send the message because all the target objects can respond to the message. However, if the behavior object wishes to invoke an optional method in a target object, the behavior object must first determine whether the target object is able to invoke the optional method.
  • Flow chart 250 starts at block 252. The first step is to determine whether a method the behavior object wishes to invoke is a universal method (block 254) . If the answer is positive, indicating that the method is a universal method, the behavior object can send a message to the target object to invoke the method (block 256) . Flow chart 250 is then terminated (block 258) . If the answer responding to block 254 is negative, indicating that the method is an optional method, the behavior object needs to send a message to the target object to determine whether the target object contains the method (block 260) . If the answer responding to block 260 is positive, indicating that the target object contains the optional method, the behavior object can send a message to the target object to invoke the method (block 256) . If the answer responding to block 260 is negative, indicating that the target object does not contain the optional method, the target object does not invoke the optional method. Flow chart 250 is terminated (block 262) .
  • a behavior object can affect the behavior of any object
  • the ability to invoke the universal and optional methods enables the behavior object to affect the behavior of a target object without the need to use multiple inheritance.
  • the technique of the present invention avoids burdensome overhead or conflicts associated with the process of generating multiple inheritance under traditional object-oriented systems.
  • Multiple inheritance under a traditional objected- oriented system involves the creation of a new class of objects each time it is necessary to generate an object that has some characteristics of one class and some other characteristics of another class.
  • the process of generating a new third class to achieve multiple inheritance often requires significant overhead caused by the complexity of the programming language and the potential conflicts between the specifications and requirements of the two parent classes.
  • the incorporation of a set of universal methods (and if appropriate, optional methods) in the target objects eliminates the need to generate a new third class of objects since objects can directly communicate with and affect the behavior of one another.
  • the design provides for efficient use and reuse of complex code. For instance, if a behavior object desires to invoke the universal method of another object, the behavior object can safely assume that the target object has the capability to perform the desired universal method. In such instance, the behavior object need not undergo the tedious process of sending a query and receiving a reply from the target object as to whether it has the ability to perform the desired function.
  • Fig. 5 is a drawing showing a computer system 300 comprising a processor unit 310, a monitor 312, and a pointing device 313 (such as a mouse) .
  • Processor unit 310 preferably contains a central processing unit, memory, and other components for performing digital operations.
  • Processor unit 310 further contains a sound unit 314 for generating audio output.
  • Monitor 320 may display a shape, such as a circle 320, which is a physical property of an object created by an object oriented program.
  • a text window 324 may also co-exist with circle 320.
  • Fig. 5 also shows a cursor 326, the motion of which is preferably controlled by pointing device 313.
  • An interpolate object is designed to move a target object from one position to another position over a specified amount of time. Given inputs of the identity of the target object, the destination, and the travel time, an interpolate object moves the target object in a smooth motion to the destination in the specified amount of time.
  • a bounce object causes a target object to move at a constant velocity and to bounce upon colliding with another object or with the edges of a container that holds the target object. The process of bouncing may involve a change in velocity and/or a change in horizontal and vertical directions. It is sometimes desirable to add features to the bounce and interpolate objects, such as changing the color of the target object when it enters an area on the screen of the monitor, or making a sound when two target objects collide.
  • An example of a target object is an oval object which is derived from a class of shapes. Objects from the class of shapes, such as ovals, squares, and lines, display themselves on a monitor. In contrast, behavior objects do not display themselves but rather affect the behavior of the target objects.
  • a conductor object such as object A of Fig. 1, is used to composite the screen of monitor 312.
  • the conductor object maintains a list of active objects. As the state of a target object changes resulting from actions by a corresponding behavior object, such as moving the target object from one point to another, the changes are reflected on the screen once the conductor object updates the screen (for example, by invoking the "draw" method of each active target object) .
  • the conductor object may also invoke a "run" method on the behavior objects, causing them to take appropriate actions to communicate with the target objects they control and implementing the desired behavior.
  • the behavior objects might, for example, be free running threads of execution.
  • FIG. 6 depicts the communications between an interpolate object 600 and an oval object 601.
  • interpolate object 600 may send to oval object 601 several messages, including a capability query 602, a position query 604, a move command 606, and a "produce sound" command 608.
  • the capability query 602 is simply an inquiry as to whether oval object 601 can perform an optional method.
  • Interpolate object 600 obtains the requested information immediately after issuing capability query 602. Similar to capability query 602, position query 604 is a request for oval object 601 to supply its position to interpolate object 600. Again, interpolate object 600 obtains the answer immediately upon invoking position query 604.
  • Move command 606 is a message from interpolate object 600 instructing oval object 601 to initiate a motion.
  • "produce sound” command is a message from interpolate object 600 instructing oval object 601 to produce a sound using sound unit 314, shown in Fig. 5.
  • Interpolate object 600 also contains a "run” method (not shown) for interacting with the conductor object. Interpolate object 600 performs its calculation and initiates move command 606 or "produce sound” command 608 after the conductor object invokes the "run” method. Oval object 601 also contains a "draw” method (not shown) which can be invoked by the conductor object to draw itself on the screen of monitor 312.
  • a color behavior object 610 can be created which changes the color of oval object 601 when it is located within a certain area on the screen of monitor 312.
  • Color behavior object 610 communicates with oval object 601 using a capability query 612, a position query 614, and a color change command 616 in a manner similar to the communication between interpolate object 600 and oval object 601.
  • Fig. 7 is a flow chart 650 of an interpolate process which implements an interpolate behavior where a sound is produced when the target object reaches the destination.
  • interpolate object 600 Upon being supplied information regarding the identity of the target object, the destination, and the travel time, interpolate object 600 commences the interpolation process.
  • Interpolate object 600 issues a position query to determine the coordinates of oval object 601 (block 654) .
  • interpolate object 600 Upon receipt of the coordinates, interpolate object 600 stores the coordinates (block 656) .
  • Interpolate object 600 then goes through a loop comprising blocks 660, 662, and 666. This loop is executed every time the conductor object sends the "run" message to the interpolation object.
  • interpolate object 600 calculates the next position for movement by oval object 601 (based on the current time) and stores the next position in memory. Interpolate object 600 then sends a move command (block 662) to oval object 601 to provide it with the coordinates of the next position and to initiate movement toward such position (the oval object will be shown in the next position after it receives the "draw" command from the conductor object) . Interpolate object 600 then determines whether oval object 601 has reached its destination by comparing the coordinates of the current position of oval object 601 with the coordinates of the destination (block 666) .
  • interpolate object 600 will repeat the steps shown in blocks 660, 662 and 666 when it receives the next "run” command. If oval object 601 has reached the destination, interpolate object 600 then initiates the sound production phase of the process. In the preferred embodiment, the conductor object successively invokes the "run” and “draw” methods on active objects such as behavior and target objects. As a result, oval object 601 appears to move steadily towards the destination.
  • interpolate object 600 determines whether oval object 601 can respond to the position query and move methods because these methods are known to the programmer to be universal methods.
  • a "produce sound" method is an optional method. Consequently, in block 670, interpolate object 600 sends a capability query to oval object 601 to determine if oval object 601 can execute the "produce sound” method. If oval object 601 cannot execute the method, the interpolate process ends (block 674) . If oval object 601 can execute the "produce sound” method, interpolate method 600 causes oval object 601 to make a sound (block 676) . The interpolate process then terminates.
  • FIG. 8 the communication between a bounce object 800 and an oval object 801 is illustrated in FIG. 8.
  • the messages sent between bounce object 800 and oval object 801 are identical to those between interpolate object 600 and oval object 601, as previously discussed.
  • the messages include a capability query 802, a position query 804, and a move command 806. These messages serve the same functions as those corresponding to the communications between interpolate object 600 and oval object 601 as previously described.
  • bounce object 800 and oval object 801 contain the "run” and “draw” methods, respectively.
  • bounce object 800 In addition to being in communication with oval object 801, bounce object 800 must communicate with the environment of oval object 801 to determine the existence of other objects with which oval object 801 may possibly collide.
  • the most common environment containing oval object 801 is the boundary of a monitor's display. However, the oval object may in certain circumstances be bouncing within a local container (i.e., a defined area on the monitor in which objects are confined) .
  • the procedures for bounce object 800 to communicate with the environment will be described in Figs. 9 and 10.
  • Fig. 9 is a drawing showing two oval objects 832 and 834 located inside a container 830 on the screen 840 of a monitor. Note that container 830 may also move (or bounce) from one position on screen 840 to another, as illustrated in Fig. 9 by line 842 (provided that container 830 implements the required universal methods) .
  • the interaction between the bounce object and the container object 830 involves the bounce object sending a list query to container 830 requesting a list of all objects that are contained within the environment of container object 830.
  • Container 830 makes a determination and sends the bounce object a list reply setting forth the identity of all the objects contained therein.
  • bounce object 800 Upon receiving a "run" command from the conductor object, bounce object 800 sends a list query to the container object 830 to determine the presence of any and all active bouncing objects or container boundaries in container object 830 (block 906) . Upon receipt from container object 830 of the list reply setting forth the identity of all bouncing objects or container boundaries within the container, bounce object 800 sends messages to all the objects on the list asking them to determine whether they collide with oval object 801 (block 910) . If there is a collision, bounce object 800 changes the velocity of oval object 801 according to a predetermined formula (block 912) . If there is no collision, the velocity used by bounce object 800 is not changed.
  • bounce object calculates the next position of oval object 801, taking into account whether a collision occurs.
  • Bounce object 800 then sends oval object 801 a move command that specifies the coordinates of the next position and initiates the move by oval object 832 (block 918) .
  • Oval object 801 then displays itself at the new position upon receiving the "draw" command from the conductor object.
  • the steps indicated in blocks 906-918 repeat indefinitely until the bouncing process is terminated.
  • GUI graphical user interface
  • a user can use a "drag-and-drop" operation to associate two objects.
  • GUI systems allow a user to drag an image of a document into an image of a waste basket, instructing the computer to delete the file associated with the document.
  • graphic images corresponding to behavior objects can be shown on a monitor.
  • a user can associate a target object with a behavior object by dragging an icon representing the corresponding behavior object onto the image of the target object.
  • Fig. 11 shows a monitor 940 for displaying a GUI system.
  • Monitor 940 displays an icon 944 for a bounce object, an icon 946 for an interpolate object, an icon 948 for a sound object and an image 942 for a target object, such as a menu bar, dialog box, or a box having various shapes.
  • a target object such as a menu bar, dialog box, or a box having various shapes.
  • a user can associate a bounce behavior with the target object 942 by dragging the icon 944 for the bounce object onto the target object 942. The target object 942 will then bounce with a default velocity.
  • a user can drag the icon 946 for the interpolate object onto the target object 942 and then drag the icon 946 to the destination.
  • the target object 942 will then move to the destination using a default velocity. If it is desirable to associate two behavior objects with a target object, such as associating a bounce object and a sound object with target object 942, the user can drag icon 944 onto target object 942 followed by dragging icon 948 onto target object 942.
  • Other behavior objects can also be implemented.
  • a gravity object can be designed to cause a target object being controlled to accelerate toward the bottom of a container. The user can specify the acceleration rate and the target object.
  • Another example is a path object which moves a target object along a given path (e.g., the perimeter of a square or circle) over time. The user can specify the path as a graphic object like "box,” "line,” or "polygon.” The user also specifies the target object, the starting and ending points, and the time it takes to travel along the path.
  • behavior objects allow multimedia authors to use complex behaviors developed by skilled programmers very easily, with a minimum of scripting.
  • the coding for performing bounces is quite complicated, even though writing programs to implement the equations for moving an object from one location to another (taking into account the change in direction in the event of a collision) is within the capability of programmers skilled in the art.
  • the multimedia author may only need to perform a drag and drop or write as little as one line of code — to simply create the bounce object and attach it to the controlled target object.
  • Multimedia authors can, of course, develop their own behavior objects (in whatever scripting or other language is available) , which they can then effectively and easily reuse.
  • Behavior objects overcome the deficiencies in existing multimedia scripting systems because there is no complex code for the multimedia author to develop, and reuse is very easy. In addition, because the behavior object can often be developed in a more efficient low-level computer language than the typical multimedia scripting language, performance is improved.
  • behavior objects overcome the deficiencies in traditional object oriented systems with multiple inheritance in several respects.
  • a multimedia author does not have to create a new class with its attendant complexities (the author simply creates an instance of the behavior class) .
  • the author does not have to decide how conflicts in methods are resolved, because both the behavior object and the target object have their full set of methods available, and the behavior object can be written to correctly handle any conflicts.
  • both the behavior object and the target object can get "idle" messages from the system; it does not have to be a case of one or the other getting such an idle message.
  • Another example is a behavior object that gets a mousedown event, and then can decide to either process the mousedown on its own, or hand the mousedown event to its target object, or both.
  • behavior objects can be "hooked up" to target objects at any time during run time. They can also be disconnected from target objects at run time. And multiple behaviors can be hooked up to a single target object, as the author sees fit. This gives the multimedia author the flexibility to experiment and to add or subtract behaviors over time.
  • display objects of the same class e.g., pixmaps
  • One bitmap might be hooked up to a bounce behavior, while another is hooked up to an interpolation behavior. This keeps classes from proliferating, so that the environment is simpler for the author to comprehend and use, as compared to a multiple inheritance environment where a new class is made for every combination of display type and behavior type.
  • SET CONTAINER set a reference to the object that contains this target object
  • SET HILITE highlights the target object in some way to the user
  • GET NEEDSRUN returns TRUE if the target wants periodic tickle message NAME FUNCTION OF METHODS SET NEEDSRUN sets the needsrun status of the target object
  • GETUPDATERGN get region to update HITCHECKPOINT return the corresponding part code (e.g., DRAGREGION, CONTENTREGION, and CLOSEREGION) of the target object after given a position
  • MOUSEDOWN ask target object to process a mouse down event
  • MOUSEUP ask target object to process a mouse up event
  • MOUSEWITHIN inform target object that the mouse is currently within its area
  • MOUSENTER inform target object that the mouse has entered its area
  • KEYUP ask target object to process a keyup event
  • OPEN open state (e.g., menus, icons)
  • CLOSE close state (e.g., menus, icons)
  • OBJECTDISPOSED notify the target object that some other object got disposed
  • OBJECTOPENED notify the target object that some other object got opened NAME FUNCTION OF METHODS OBJECTCLOSED notify the target object that some other object got closed
  • FLYOVER tell that an object is over this target object and may be dropped
  • INSTANCE VARIABLE container, bounds, oldbounds, position, height, width, hilite, selected, draggable, dirty, directToScreen, collider, and needsRun.
  • TARGET OBJECT METHOD FUNCTION OF METHOD GraphicActor GET FRAME determine whether the target object is a frame or solid shape
  • SET FRAME set the target object as a frame or solid shape
  • GET INK get the transfer mode: copy, XOR, matte, transparent, etc.
  • Arc GET ARCANGLE get the arcangle SET ARCANGLE set the arcangle GET STARTANGLE get the start angle

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

L'invention concerne un environnement de programmation orienté sur des objets. L'environnement comprend une pluralité de catégories et d'objets. Chaque objet communique avec d'autres objets de l'environnement par envoi de messages appelant des procédés dans ces autres objets. L'environnement contient au moins un objet cible contenant un ou plusieurs procédés universels utilisés pour communiquer avec un autre objet. Ces procédés universels sont typiquement inclus dans la totalité des objets cible de l'environnement, avec des variables d'exemple universelles et associées, utilisées par les procédés universels, ce qui constitue un protocole universel ou interface universelle avec les objets cible. Des objets comportementaux, objets mettant en application le comportement d'autres objets, obtiennent et modifient des propriétés de l'objet cible en appelant directement les procédés universels résidant dans l'objet cible. La communication entre l'objet comportemental et l'objet cible s'effectue par l'intermédiaire du protocole universel (procédé et variables d'exemple).
PCT/US1994/003588 1993-03-31 1994-03-31 Objets comportementaux WO1994023362A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU64190/94A AU6419094A (en) 1993-03-31 1994-03-31 Behavior objects

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US4052493A 1993-03-31 1993-03-31
US08/040,524 1993-03-31

Publications (1)

Publication Number Publication Date
WO1994023362A1 true WO1994023362A1 (fr) 1994-10-13

Family

ID=21911448

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1994/003588 WO1994023362A1 (fr) 1993-03-31 1994-03-31 Objets comportementaux

Country Status (2)

Country Link
AU (1) AU6419094A (fr)
WO (1) WO1994023362A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2632142C2 (ru) * 2015-06-30 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и электронное устройство управления разрешениями для объектов

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Dynamic data conversion for software release compatibility by object oriented programming", IBM TECHNICAL DISCLOSURE BULLETIN., vol. 37, no. 2A, February 1994 (1994-02-01), NEW YORK US, pages 209 - 212 *
D.L. MCCUE: "Developing a class hierarchy for object-oriented transaction processing", ECOOP '92 EUROPEAN CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, 3 July 1992 (1992-07-03), UTRECHT, NL, pages 413 - 426 *
L.V. MANCINI: "A technique for subclassing and its implementation exploiting polymorphic procedures", SOFTWARE PRACTICE & EXPERIENCE, vol. 18, no. 4, April 1988 (1988-04-01), CHICHESTER GB, pages 287 - 300 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2632142C2 (ru) * 2015-06-30 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и электронное устройство управления разрешениями для объектов

Also Published As

Publication number Publication date
AU6419094A (en) 1994-10-24

Similar Documents

Publication Publication Date Title
US10592238B2 (en) Application system that enables a plurality of runtime versions of an application
Potel MVP: Model-View-Presenter the Taligent programming model for C++ and Java
US5710896A (en) Object-oriented graphic system with extensible damage repair and drawing constraints
US5555368A (en) Object-oriented multi-tasking view framework
JP3602532B2 (ja) 増分コマンド・オブジェクトを有する並行処理装置
US5465362A (en) Object-oriented view-system for displaying information in a windowing environment
US5544301A (en) Object-oriented view layout system
US6453328B1 (en) Model tracking object-oriented system for collaborative data editing with non-compatible computer peripheral devices
US5459832A (en) Method and apparatus for editing groups of graphic images
US5465363A (en) Wrapper system for enabling a non-multitasking application to access shared resources in a multitasking environment
US5615326A (en) Object-oriented viewing framework having view grouping
JP5820339B2 (ja) 第４世代プログラミングツールを用いて生成されるアプリケーションの属性の拡張
JPH04303240A (ja) オブジェクト指向インタフェース標準を与えるシステムおよび方法
WO1995004961A1 (fr) Systeme et procede de manipulation du curseur
CN110262791B (zh) 一种可视化编程方法、装置及运行器、可读存储介质
JPH07200880A (ja) オブジェクトの簡単な操作と表示を可能にするための３ｄオブジェクトへのスライダの接続
WO1995018413A1 (fr) Systeme de hierarchies de vues, oriente objets
US6512519B1 (en) Infrastructure for shape event handlers
AU688314B2 (en) Costume objects
GB2327836A (en) User interface controls for a computer system
Ferguson et al. MetaMOOSE—an object-oriented framework for the construction of CASE tools
Beaudouin-Lafon Human-computer interaction
WO1994023362A1 (fr) Objets comportementaux
Herczeg et al. Progress in building user interface toolkits: The world according to XIT
KR19980703711A (ko) 데이터 처리시스템 및 방법, 및 컴퓨터프로그램 아키텍처

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AT AU BB BG BR BY CA CH CN CZ DE DK ES FI GB HU JP KP KR KZ LK LU MG MN MW NL NO NZ PL PT RO RU SD SE SK UA UZ VN

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 BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

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

Ref country code: CA

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载