Overriding outputs in a producer graph oriented programming and execution system
Abstract
A system for replacing outputs, the system comprising: a processor; a machine storage medium, coupled to the processor, which has an object-oriented code stored therein that includes customer code that has commands to be executed by the processor, including said customer code, a producer instantiation command that has a producer key for a producer of interest and that causes an object-oriented code execution environment to automatically, based on producer dependency statements, discover, build, and, optionally, solve a producer graph from the producer of interest, where each of the producers in the producer graph is an instantiated construction of an execution environment, where each producer is instantiated from the respective producer combination of a particular instance of a class and a particular method of that class and identifies that particular instance and said particular method, where the method identified by each producer has associated with it a declaration of dependencies of the producer that identifies the execution environment of a set of zero or more producers, where the execution environment automatically instantiates some of the producers of the producer graph that still has not been instantiated, where producer keys are used to distinguish producers, where method keys are used to distinguish methods, where the instance keys are used to distinguish the instances, and where the producer key for each of the producers is based on at least the instance key and the key of the instance method and the method identified by that producer; execute commands, each having the execution environment for object-oriented code execute the producer graph and cache a current output for each of the producers executed in the producer graph; and execute producer output substitution commands, which each has a producer key and a substitution value and each has the execution environment for the object-oriented code replace the producer's output designated by the producer key with The replacement value.

Term
1.2 yearsto projected expiry
Projected expiry 3 December 2027, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
11 claims: 8 independent, 3 dependent
- 1REIVINDICACIONES 1 Un sistema para la sustitución de salidas, comprendiendo el sistema:un procesador;un medio de almacenamiento de máquina, acoplado al procesador, que tiene almacenado en el mismo un CÓdigo orientado a objetos que incluye CÓdigo de cliente que tiene comandos a ejecutar mediante el procesador, incluyendo dicho código de cliente, un comando de instanciación de productor que tiene una clave de productor para un productor de interés y que causa un entorno de ejecución de código orientado a objetos para automáticamente, en base a las declaraciones de dependencia del productor, descubrir, construir, y, opcionalmente, resolver un grafo de productores a partir del productor de interés, donde cada uno de los productores en el grafo de productores es una construcción instanciada de entorno de ejecución, donde cada productor se instancia a partir de la respectiva combinación de una instancia particular de una clase y un método particular de esa clase e identifica dicha instancia particular y dicho método particular, donde el método identificado por cada productor tiene asociada con el mismo una declaraciÓn de dependencias del productor que identifica el entorno de ejecución de un conjunto de cero o más productores, donde el entorno de ejecución instancia automáticamente alguno de los productores del grafo de productores que aun no se ha instanciado, donde las claves de productores se utilizan para distinguir los productores, donde las claves de método se utilizan para distinguir los métodos, donde las claves de instancias se utilizan para distinguir las instancias, y donde la clave de productor para cada uno de los productores se basa en al menos la clave de instancia y la clave del método de la instancia y del método identificado por ese productor;ejecutar comandos, haciendo cada uno que el entorno de ejecución para el CÓdigo orientado a objetos ejecute el grafo de productores y guarde en caché una salida actual para cada uno de los productores ejecutados en el grafo de productores;y ejecutar comandos de sustitución de salidas del productor, que cada uno tiene una clave de productor y un valor de sustituciÓn y cada uno hace que el entorno de ejecución para el código orientado a objetos sustituya la salida del productor designada por la clave de productor con el valor de sustitución.
- 2El sistema de la reivindicación 1, donde el CÓdigo de cliente también incluye:comandos de sustitución de la salida del productor, que cada uno tiene uno la clave de productor de los productores que han sido sustituidos y que cada uno hace que el entorno de ejecuciÓn para el código orientado a objetos sustituya a la salida sustituida de ese productor.
- 3El sistema de cualquiera de las reivindicaciones 1 a 2, donde la causa del comando de instanciaciÓn del productor y los comandos de sustitución de las salidas del productor es indirecta a través del uso de un registro de comandos guardado por el entorno de ejecución para el código orientado a objetos.
- 4El sistema de cualquiera de las reivindicaciones 1 a 3, donde el primero de los comandos de ejecución provoca una ejecución inicial y cada uno posterior de los comandos de ejecución provoca una ejecución incremental.
- 5El sistema de cualquiera de las reivindicaciones 1 a 4, donde el código de cliente también incluye:un comando de instanciación de instancias que tiene la clave de instancia del productor de interés yeso hace que el entorno de ejecución de código orientado a objetos instancie la instancia identificada por el productor de interés.
- 6El sistema de cualquiera de las reivindicaciones 1 a 5, donde un conjunto de uno o más de los comandos de sustituciÓn de salidas del productor es seguido por uno de los comandos que se ejecutan dicho código de cliente.
- 7El sistema de cualquiera de las reivindicaciones 1 a 6, donde claves de clase se utilizan para distinguir una pluralidad de clases, cuyas instancias son instancias, y donde la clave de productor para cada uno de los productores también se basa en la clave de clase de la clase de la instancia identificada por ese productor.
- 8El sistema de la reivindicación 7, donde el comando de instanciación del productor hace que el entorno de ejecución para código orientado a objetos para instanciar el productor de interés accediendo a la clase de la instancia identificada por el productor de interés a través de una estructura de seguimiento de clase utilizando la clase de clave de la clave del productor del comando de instanciación del productor, accediendo a la instancia identificada por el productor de interés a través de una estructura de seguimiento de instancia utilizando la clave de instancia de la clave del productor del comando de instanciación del productor, y accediendo a la declaración de dependencia del productor del método identificado por el productor de interés a través de una estructura de seguimiento de métodos usando la clave de método de la clave del productor del comando de instanciación del productor.
- 9El sistema de cualquiera de las reivindicaciones 1 a 8, donde la clave de instanciación de al menos algunos de los productores mantiene una referencia a la instancia identificada mediante ese productor.
- 10El sistema de cualquiera de las reivindicaciones 1 a 9, donde dicho código de cliente también incluye:comandos de instanciación del productor adicionales que hacen que el entorno de ejecución de código orientado a 5 objetos automáticamente descubra, construya, y opcionalmente resuelva otros grafos de productores, donde cada uno de dichos comandos de ejecución hacen que dicho entorno de ejecución de código orientado a objetos ejecute todos los grafos de productor. 11 El sistema de cualquiera de las reivindicaciones 1 a 10, donde dicho código orientado a objetos incluye 10 definiciones de clases, donde dichas definiciones de clases incluyen métodos con las declaraciones de dependencias del productor.
- 12El sistema de la reivindicación 11, donde las declaraciones de dependencias del productor definen los vinculos entre los productores como parte de la definición de las clases, más que en el momento de instanciación de las 15 instancias de esas clases.
Independent claims11
970 paragraphs in 1 section, as filed
Substitution outputs in a programming and execution system oriented by producer graphs Background
Embodiments of the invention refer to the field of computers, and more specifically, to the field of programming and code execution with an execution environment.
Background
Object-oriented programming
fifteen Object-oriented programming is a paradigm of computer programming. The idea behind object-oriented programming is that a computer program can be seen as comprising a collection of individual units (called objects or instances) that act with each other, as opposed to a traditional point of view in which a program It can be seen as a collection of functions, or simply as a list of instructions to the computer. An object is a language mechanism for linking data with methods
twenty that operate on that data. Each object is capable of being called through methods, processing data, and providing results with other objects. Each object can be seen as an independent machine or an actor with a different role or responsibility.
A reflective object-oriented language is a programming language that has a particular set of
25 characteristics (for example, classes, objects / instances, inheritance, reflection, etc.), while an object-based reflective language is sometimes used to label a programming language that has some subset of those characteristics (for example, objects) . For the purposes of this document, the phrases "Object-oriented source code ~ and Object-oriented code ~ are used to refer to the code written in a language that has these characteristics (for example, code written in an object-oriented reflective language, code written in
30 a reflective language based on objects). While method languages, non-reflective object-oriented languages, and non-reflective object-based languages are programming languages that do not normally support these characteristics, transformation techniques can be used to provide these characteristics (for example, through emulation) to code correctly written in both languages, and therefore, These techniques transform these languages into an object-based reflective language or a reflective oriented language
35 to objects. (These techniques do not need to emulate all features of object-oriented or object-based languages, but can only emulate features that are of interest to the rest of this document). For the purposes of this document, the phrases "object-oriented source code" and "object-oriented code" are also used to refer to this cross-border, non-reflective object-oriented language code, and non-object-based reflective method. By way of example, and not limitation, this document describes
40 primarily an object-oriented source code written in a reflective object-oriented language. In addition, the terms object and example are used interchangeably in this document.
Mainly used in object-oriented programming, the term method refers to a piece of code that is exclusively associated with either a class (called class methods, static methods or methods of
Four. Five factory) or with an object (called instance methods). Like a method in method programming languages, a method usually consists of a sequence of instructions to perform an action, a set of input parameters to parameterize the actions, and possibly an output value of some kind that is bring back.
fifty When programmers write a program using an object-oriented language, the resulting code can be viewed conceptually as including four basic types of code. The first type includes commands that operate on input instance (s) to provide output instance (s) (referred to herein as "transfonnación" code); Typically written as methods (referred to here as "transformation" methods). The second type includes instantiation commands for instances that cause the runtime environment to create instances of
55 classes (indicated here as ~ instance instantiation code ~). The third type includes property manipulation commands (indicated here as "data preparation" code) to invoke property access methods, mutations, etc.) of the previous instances. The fourth type includes scripts that cause method invocation sequencing using the corresponding instances (when the appropriate instances include the instances to use as arguments, the instances are used by the
60 instance methods and instances of meta classes used by class methods) to specify which transformation methods of which instances they invoke, in what order, and with what parameters of which instances they respond to changes introduced by the preparation code of data (indicated here as "manual invocation sequencing code ~). The manual invocation sequencing code is sometimes written as separate methods from the transformation methods, and therefore, the manual invocation of the code of
65 Sequencing includes transformation method invocation scripts. A program typically iterates between the data preparation code and manual invocation sequencing code (which can also be immersed in the instance instantiation code), which in turn invokes the transformation code (which can also be immersed in the code of instance instantiation and data preparation code types). It should be noted that this is a conceptual representation of a program, and therefore, not
5 It should be taken as an absolute regarding how to watch a program.
Runtime environment
The term runtime environment is used here to refer to a program or a basic code library that is
10 execute another code written in the same and / or a different language. Therefore, an execution environment is a collection of utility functions that support a program while it is running, including working with the operating system to provide services such as mathematical, input and output functions. This makes it unnecessary for programmers to continually rewrite the basic capabilities specified in a programming language or provided by an operating system. Since the demarcation between a
fifteen runtime environment and an operating system may be blurred, the term runtime environment is used here to refer to code separate from the operating system and / or code that is part of the operating system.
Initial execution times, such as FORTRAN, offer features such as mathematical operations. Other languages add more sophisticated features, for example, collection of memory remnants, often in association with support for objects. More recent languages tend to have considerably larger execution times with more functionalities. Many object-oriented languages also include a system known as "dispatcher" and "class loader." The Java Virtual Machine (JVM) is an example of this runtime environment: it also interprets or compiles binary portable Java programs (byte-code) in the runtime environment. The common language runtime environment (CLR) framework is another example of a
25 runtime environment.
Programming and execution framework
A framework in which applications are provided to end users includes three basic divisions. The
30 First division includes the creation of the operating system and the runtime environment. This first division is carried out by programmers with very advanced programming knowledge. When working in this division, programmers are called, respectively, programmers in the operating system and programmers in the runtime environment. When creating an execution environment for an object-oriented language, runtime programmers include support for the execution of the different types of commands that
35 they are used in the transformation code, instance instantiation code, data preparation code, and manual invocation sequence code (for example, instance instantiation commands, data preparation commands and invocation commands of the method).
The second division includes the creation of object-oriented application source code that will be executed by the
40 runtime environment. The second division is carried out again by programmers with more advanced programming knowledge, as well as an understanding of the application's business objectives. When working in this division, programmers are known as application programmers. When creating an application in an object-oriented programming language, application programmers write the specific transformation code, instance instantiation code, data preparation code, and
Four. Five Manual invocation sequence code for the specific application that was created. As part of this, if the application requires a graphical user interface, application programmers also design and code the graphical user interface for the specific application, and therefore, they are also known as application designers.
fifty The third division includes the use of application programs that are executed by the execution environment. The third division is carried out by end users who do not need to have programming skills.
Manual invocation sequencing code
55 The higher costs typically associated with creating an application involve debugging and / or optimizing the manual invocation sequencing code. For each opportunity for the data to change, the application programmer must take into account its effect and write the manual invocation sequencing code to make the appropriate transformation methods of the appropriate instances invoked in the appropriate order, with the corresponding entries. Sample errors made by programmers of
60 Applications include: 1) invoke the appropriate transformation methods of the corresponding instances in the wrong order, 2) forget to include commands to make one or more necessary transformation methods of the instances to be invoked respond to some data that was changed, 3) include commands to make unnecessary transformation methods to be invoked in response to some data that is being modified (for example, including commands to invoke methods of transforming instances that
65 are not affected by the change in data), etc.
As an example, a manual invocation sequencing code generation technique is the use of the observer pattern (sometimes known as "subscribe publication") to observe the status of an instance in a program. In the observer pattern, one or more instances (called observers or listeners) register (or register themselves) to observe an event that can be raised by the observed object (the subject). the
5 Observed instance, which can cause an event, generally maintains a collection of registered observers. When the event is triggered, each observer receives a callback from the observed instance (the observed instance invokes a "notification" method on registered observers). The notification function may pass some parameters (usually information about the event that is occurring) that can be used by observers. Each observer implements the notification function, and as a consequence, defines its own behavior when the notification occurs.
The observed instance typically has a registration method to add a new observer and an unregistered method for removing an observer from the list of instances to be notified when the event is triggered. In addition, the observed instance may also have methods to temporarily disable and then return to
fifteen enable calls to prevent inefficient shedding of a number of related changes. Specifically, callbacks in response to a change in property value often also change the values of some other properties, causing additional callbacks, and so on.
When the observer pattern technique is used, application programmers who manually write the manual invocation sequencing code specify which methods of which instances they are called, in what order, and with which entries by registration, registration cancellation, deactivation and return to the rehabilitation of observers to the different instances observed, as well as the writing of the methods of notification and return of calls for each one. More specifically, the relationship between the observer and the cases observed
25 it is administered locally (for example, the observed instance only, without synchronization with other observed instances) within the observer pattern, and therefore, the manual invocation sequencing code necessary to synchronize events from multiple observed instances is typically part of the specific callback methods of each observer.
Volatile overwriting call stack
Typical runtimes use a volatile overwriting call stack to track calls currently invoked not completed. A volatile overwriting call stack overwrites because it dispatches and discards entries when each call has been completed, and is volatile because it is discarded and
35 rebuild on each run. Typical execution times use volatile overwriting call stacks because typical execution times combine the construction of the volatile overwriting call stack, with the actual invocation of appropriate transformation methods of the appropriate instances with the appropriate inputs that respond upon execution of the manual invocation sequence code. In sum, to respond to the execution of the manual invocation sequencing code, a typical execution environment determines the method of transforming instance-by-call sequencing (when each call is made) and maintains the volatile overwriting call stack to make Tracking only of calls invoked not completed.
Assigned Object-Relational
Four. Five Object-relational assignment is a programming technique that links relational databases with object-oriented language concepts, creating (in effect) a "virtual object database". Some object-relational mappers automatically keep instances loaded in memory in constant synchronization with the database. Specifically, after the construction of a query of assigned object to Sal, the first data returned is copied into the fields of the instances in question, like any package of assigned object-SOL object. Once there, the instance has to look to see if these values change, and then carefully reverse the process of writing the data back to the database.
Hibemate 3.0 is an object-relational assigned solution for Java and ClR (JBoss® Inc., of Atlanta, Georgia). By
55 Therefore, Hibemate offers a framework for the assignment of an object-oriented domain model in a traditional relational database. Its objective is to relieve the developer of some common data programming tasks related to persistence. Hibernate is responsible for assigning classes to database tables (and from object-oriented data types to Sal data types), as well as those that offer data queries and recovery facilities. Hibernate is focused on instances and creates graphs that represent relationships between instances.
Control investment and the dependency investment principle
Control inversion, also known as IOC, is an object-oriented programming principle that can be used to reduce coupling (the degree to which each program module is based on each other type of module) inherent in the programs of computer. the loe is also known as the investment principle of the
dependence. In the IOC, a class X depends on class Y if any of the following cases apply: 1) X has a y and the flame; 2) X is a Y, or 3) X depends on some class Z that depends on Y (transitivity). It should be noted that X depends on Y does not imply that Y depends on X; if both turn out to be true, it is called a cyclic dependence: X cannot be used without Y, and vice versa.
In practice, if an object x (of class X) calls the methods of one object y (of class Y), then class X depends on Y. The dependence is reversed by the introduction of a third class, it is that is, an interface class I that must contain all the methods that x could call in y. In addition, Y must be changed in such a way that it implements interface 1. X and Y are now both dependent on interface I and class X no longer depends on class Y (assuming that x is not an instance of Y). This elimination of the dependence of class X on Y by the introduction of an interface l is said to be a control inversion (or an inversion of the dependence). It should be noted that And could depend on other classes. Before the transformation has been applied, X depends on Y, and so X indirectly depends on all the classes on which Y depends. Through the application of control investment, all these indirect dependencies have also been broken. L interface just
fifteen introduced does not depend on anything.
The dock framework is an open source application framework for the Java platform that uses IOC and dependency inversion. Specifically, the central point in the dock framework is its investment of the control container that provides a means to configure and manage Java objects. This container is also known as pod factory, application context or core container. Examples of the operations of this container are: creation of objects, configuration of objects, methods of initialization of calls and passing objects to return objects of registered calls. The objects that are created by the container are also called managed objects or pods. Normally, the container is configured by loading XML files that contain pod definitions. These provide all the information that is required to create
25 objects. Once objects are created and configured without raising error conditions, they are available for use. The objects can be obtained by means of a dependency search or dependency injection. The dependency search is a pattern in which a caller asks the container object for an object with a specific name or of a specific type. Dependency injection is a pattern where the container passes objects by name to other objects, whether through constructors, properties or factory methods. Therefore, the spring frame is focused on memory and builds graphs that represent the relationships between the instances.
Graphing tools
35 Javadoc ™ is a tool that analyzes documentation declarations and comments in a set of Java source files and generates a set of HTML pages that describe (by default) public and protected classes, nested classes (but not anonymous internal classes ), interfaces, constructors, methods and fields (Su n Microsystems®, Inc., of Santa Clara, CA). Javadoc can be used to generate the API documentation (Application Programming Interface) or the implementation documentation for a set of source code files. Javadoc is focused on the class and the method and creates graphs that represent the relationships between the combination of classes and their methods.
Another system for designing software applications includes graphs of the objects analyzed by an interpreter to represent and reproduce a computer application. This system uses written programming classes previously stored in code libraries, which can be written to follow the design patterns described in "Design Pallems" by Gamma et al, Addison Wesley 1995, "Pallems in Java" by Grand, Wiley Computer Publishing, 1998, and / or high-level Assisted Software Engineering (CASE) tools. More specifically, some classes are based on the pattern of observer behavior. The previously written code libraries represent application nodes of the state, the processing logic, and the system data flow between the various application states (i.e., the previously written data elements of the application), so that a User does not have to write, edit, or compile the code, when creating a software application. Instead, a user manually edits a software application in a graphical user interface by editing visual objects associated with a node of the current state of the application, such as data in the application status node or the processes performed in the application status node. Then, based on the
55 changes made by the user for the node of the current state of the application, the interpreter shows the status of the updated application for the user for the state of the application that has just been edited. Then, the system can make the transition along a user-defined edge of transition to another state of the application where the user can optionally edit the state of the next application or the transition edge. Changes in a graph can be made to the instances of the graph that are implemented by the interpreter, while the software application is running.
This system for the design of software applications may include visual representations of a functioning software application that can be made "usable" with an application controller. When a user changes the visual objects, which represents the software application that is running, the controller uses input 65 to induce the interpreter to make the change to the graph. The controller then expects more changes. In addition, visual representations of software applications cannot be imported or exported as
XML documents that describe the visual representation of the application, and therefore, the software application.
In order to modify and create a software application, in the form of a visual representation of nodes, directed edges, and application states, an application program interface and an additional application editor may be included in the system. The keywords and associated definitions of the previously written code libraries allow application developers to manually define a software application, processing steps, as well as the visual representation of a software application, providing graphical representations, in an editor, of an application graph that correlates closely with the structure of the actual application. A user defines a new application through an "application definition wizard", after certain preliminary issues have been met, shows the new application as a graphical component in the editor's workspace. A user also interacts with an application by making selections of the lists that are shown of the previously created components of possible applications and dragging and dropping components into the workspace through a PC mouse and keyboarding. A user can select the components and "drag" them over the existing components. When a new component "falls" on a
fifteen existing component, the new component becomes a minor of the existing component in an application graph. The relationships of the components within the fonna application are defined manually by the user selections in the editor. Thus, a tree structure is generated that represents an application by the user. As the application is created, the user can select a browser viewer of the application to display a tree view of the construction request, so that it is possible to select and edit any component of the application. The editor's interface processes user entries and selections, including the creation or deletion of application elements, the update of component attributes, and the update of an application's screen properties.
The system described above, while using visual representations of software applications,
25 It can also be used as a visual programming tool to define and update relational databases. The system uses the XML descriptions of the visual representation of software applications. A tool analyzes and interprets XML descriptions to produce equivalent relational schemas in the list of databases, as well as their changes. When the data is changed within a visual representation of a software application, a description of the change is stored along with other changes in a journal file and then processed as a group. An intentional program (a Java application that operates on its own thread) performs transactions between the visual representation of the software application and the relational database. The Java application (for example, checks) reviews the journal of changes in the nodes of the visual representation (that is, the data in the database), and if there are changes, it makes the changes in the database. Thus, by altering the data within the visual representation, the system updates a database of
35 data. A similar application is between the visual representation of the software application and the database handles the requests for the database data.
Another system for software analysis is called a Code Tree Analyzer (CTA). A CTA analyzes the static source code written in an object-oriented programming language. The CTA generates a symbol table and a call tree from the static source code. Using the symbol table, the CTA generates a class diagram. Also, using the call tree, the CTA generates a sequence diagram. The class diagram illustrates the relationship between a class selected by the user and the classes related to the class selected by the user. The sequence diagram illustrates the sequence in which different methods are called. Using the class diagram and the sequence diagram, the CTA generates a representative of the design artifacts of the
Four. Five static source code When the user modifies the design artifact, the CTA identifies the affected parts of the source code using the sequence diagram. The design artifact is used for code maintenance and reverse engineering of static source code.
Chapter 8 "Linking Model" of the book "Inside the Java Virtual Machine" by 8ill Venners describes the dynamic link model of the Java virtual machine.
Document US2002l072890 describes a method of nullifying a value in a network in an array during the execution of a routine test.
55 Brief Summary
Various aspects and embodiments of the invention are indicated in the appended claims.
Brief description of the drawings
The invention can be better understood by referring to the following description and the accompanying drawings that are used to illustrate the embodiments of the invention. In the drawings:
Figure 1A is a block diagram illustrating the relationship of a producer dependency declaration of a method of a class in an object-oriented source code of a producer that includes the class, a given example of that class, and a method of that class, according to an embodiment of the invention;
Figure 1B illustrates the example relationships between producer 110A and parent producer 1l4A.1 according to an embodiment of the invention;
5 The figure illustrates the example relationships between producer 110A and descending producer 112A.1 according to an embodiment of the invention;
Figure 1D illustrates some additional example combinations of the relationships of parent producers 114 and descendant producers 112 to producer 110A according to an embodiment of the invention;
Figure 1E illustrates those different instances of the same class that producers may have based on the same and / or different methods according to an embodiment of the invention;
Fig. 2 is a block diagram illustrating the reuse capacity of an execution environment with a graph of producer of oriented programming support according to an embodiment of the invention;
Fig. 3A is a block diagram illustrating an execution environment with the graphical oriented programming support of the producer according to an embodiment of the invention;
Figure 3B is a block diagram illustrating an execution environment with the programming support oriented to the producer graph that also supports incremental execution and replaced outputs of the producers according to an embodiment of the invention;
Fig. 4A is a block diagram illustrating the discovery and construction of a graph of the example producer according to an embodiment of the invention;
Figure 4B is a block diagram illustrating the initial execution of the graph of the producer of Figure 4A according to an embodiment of the invention;
Figure 4e is a block diagram illustrating the incremental execution of the graph of the producer of Figure 4B according to an embodiment of the invention:
Figure 40 is a block diagram illustrating the incremental execution of the graph of the producer of Figure 48 after the dependent producer 2 has been canceled according to an embodiment of the invention;
35 Figure 4E is a block diagram illustrating the incremental execution of the graph of the producer of Figure 4B after the dependent producer 2 has been canceled and the independent source producer 3 has been modified according to an embodiment of the invention;
Figure 5A is a block diagram illustrating the discovery and construction of a graph of the example producer that includes an unresolved dependency according to an embodiment of the invention;
Figure 5B is a block diagram illustrating the initial execution of the graph of the producer of Figure 5A and the resolution of the unresolved dependency according to an embodiment of the invention;
Four. Five Figure 5e is a block diagram illustrating the initial execution of the graph of the producer of Figure 5A and / or the additional execution of the graph of the producer of Figure 5B according to an embodiment of the invention;
Figure 50 is a block diagram illustrating the initial execution of the graph of the producer of Figure 5A and / or the additional execution of the graph of the producer of Figures 58 and 5e in accordance with an embodiment of the invention;
Fig. 6 is a flow chart illustrating a logical execution flow of an execution client and its relation to an execution environment with the graphical support of the producer according to an embodiment of the invention;
55 Figure 7A illustrates a pseudo code of a producer dependency declaration of a method using direct access dependencies declared in accordance with an embodiment of the invention;
Fig. 7B is a block diagram of example producers according to an embodiment of the invention;
Figure 7e illustrates a pseudo code of a producer dependency determination of a method that uses an undeclared dependency shortcut, and illustrates a block diagram of example producers according to an embodiment of the invention;
65 Figure 70 illustrates a pseudo code of a producer dependency declaration of a method that uses an undeclared dependency shortcut according to an embodiment of the invention; Fig. 7E is a block diagram of example producers according to an embodiment of the invention;
Figure 7F is a block diagram of an example dependencies by using an ascending dependency 5 with a dependency determination producer according to an embodiment of the invention;
Figure 7G is a block diagram of possible example dependencies by using a weakly restricted dependency with a dependency determination producer according to an embodiment of the invention;
Figure 7H illustrates graphs of example producers of standard producers according to an embodiment of the invention;
Figure 71 illustrates an example of the dependencies of producers and producers of determination of dependence to discover, solve, and construct the graph of the producer of Figure 7H.
Fig. 8A is a block diagram illustrating a first example framework in which applications are provided to end users according to an embodiment of the invention;
twenty Figure 88 is a block diagram illustrating a second example of a framework in which applications are provided to end users according to an embodiment of the invention;
Figure 8e illustrates a screen and example and the use of free cell selection with the graphical user interface module of the configurable interactive producer output 840 according to an embodiment of the invention;
Figure 8D illustrates another example screen and the use of free cell selection with the graphical user interface module of the configurable interactive producer's output 840 according to an embodiment of the invention;
Figure 8E shows an example of a screen and the use of creating the table with the graphical user interface module of the output of the configurable interactive producer 840 according to an embodiment of the invention;
35 Figure 8F illustrates another example screen and the use of creating the table with the graphical user interface module of the output of the configurable interactive producer 840 according to an embodiment of the invention;
Figure 9A is a block diagram illustrating a first scheme of the distribution of an execution environment 40 with the programming support oriented to the producer's graph according to an embodiment of the invention;
Fig. 98 is a block diagram illustrating a second scheme for the distribution of an execution environment with the programming support oriented to the producer's graph according to an embodiment of the invention;
Figure 9C is a block diagram illustrating a third scheme of the distribution of an execution environment with the programming support oriented to the producer's graph according to an embodiment of the invention;
Fig. 10 is a block diagram of an exemplary embodiment according to an embodiment of the invention;
Figure 11A is a block diagram of an example of the class 1092 tracking structure of Figure 10 according to an embodiment of the invention;
55 Fig. 118 is a block diagram of an example of the example tracking structure 1065 of Fig. 10 according to an embodiment of the invention;
Figure 11C is a block diagram of an example of the producer graph (s) of structure 1060 of Figure 10 according to an embodiment of the invention;
Figure 110 is a block diagram of an example of the method of tracking structure 1058 of Figure 10 according to an embodiment of the invention;
Figure 12 is a block diagram illustrating additional details of Figure 10 to support dynamic contingent type and subscription dependencies 65 of producers according to an embodiment of the invention;
Figure 13A illustrates a pseudo code of producer dependency declarations of the methods that use an undeclared, non-dynamic dependency, without direct access (non-contingent, without subscription) in accordance with an embodiment of the invention;
5 Figure 138 is a diagram of producer blocks illustrating an example of producer dependence without undeclared, non-dynamic (non-contingent, no subscription) direct access according to an embodiment of the invention;
Figure 13C illustrates a pseudo code of producer dependency declarations of the methods that use a producer dependency without direct undeclared, contingent, non-subscription access according to an embodiment of the invention;
Figure 130 is a block diagram of producers illustrating an example of producer dependence without declared direct access, contingent, without subscription according to an embodiment of the invention;
Figure 13E shows a pseudo-code of the producer dependency declarations of the methods that use both a producer dependency without undeclared, contingent, non-subscription direct access and a producer dependence with declared, contingent, non-subscription direct access according to an embodiment of the invention;
Figure 13F is a block diagram of producers illustrating a producer dependency without undeclared direct access, contingent, no subscription and a declared direct access producer dependency, contingent, without subscription according to an embodiment of the invention;
25 Figure 13G illustrates a pseudo code of producer dependency declarations of the methods that use a dependency of the declared, contingent, non-subscription direct access producer and a non-contingent direct access producer dependency, without subscription according to an embodiment of the invention;
Figure 13H is a block diagram of producers illustrating an example of producer dependence with declared direct access, contingent, no subscription and a producer dependence with declared direct access, non-contingent, without subscription according to an embodiment of the invention ;
Figure 131 illustrates a pseudo code of producer dependency declarations of the methods that use a producer dependency with declared direct, non-dynamic (non-contingent, no subscription) access according to an embodiment of the invention;
Figure 13J is a block diagram of producers illustrating an example of producer dependence with declared direct access, not dynamic according to an embodiment of the invention; Figure 14A is a block diagram of an example of the subscription record 1250 of Figure 12 according with an embodiment of the invention;
Figure 148 is a block diagram of example producers illustrating a non-contingent subscription producer dependency, absorbent according to an embodiment of the invention;
Four. Five Figure 14C is a block diagram of example producers illustrating a dependency of the non-contingent, adherent subscription producer in accordance with an embodiment of the invention;
Figure 140 illustrates the choice of a parent producer based on a parent dependency determination producer created by an adherent subscription according to an embodiment of the invention;
Figure 14E illustrates the choice of a parent producer based on a parent dependency determination producer created by a descending dependency determination producer, whose descending dependency determination producer is linked by a sequencing dependency, in accordance with an embodiment of the invention;
Figure 15 is a flow chart for instantiation of new instances according to an embodiment of the invention;
Figure 16 is a flow chart of instantiation of new producers and producers without cancellation according to an embodiment of the invention;
Figure 17 is a flow chart for block 1650 of Figure 16 according to an embodiment of the invention;
65 Figure 18 is a flow chart for block 1745 of Figure 17 according to an embodiment of the invention;
Figure 19 is a flow chart for block 1630 of Figure 16 according to an embodiment of the invention;
5 Figure 20 is a flow chart for blocks 1635 and 1670 of Figure 16 according to an embodiment of the invention;
Figure 21 is a flow chart for replacing producers according to an embodiment of the invention;
Figure 22A is a part of a flow chart for the execution of the current producing graph (s) according to an embodiment of the invention;
Figure 228 is another part of a flow chart for the execution of current producing graph (s) according to an embodiment of the invention;
Figure 23 is a flow chart for block 2205 of Figure 22 according to an embodiment of the invention;
Figure 24 is a flow chart for block 2225 of Figure 22 according to an embodiment of the invention; and
Figure 25 is a flow chart for block 2260 of Figure 22 according to an embodiment of the invention.
Detailed description
In the following description, numerous specific details, such as logical implementations, operation codes, means for specifying operands, resource sharing / sharing / duplication implementations, types and interrelations of system components, and logical partition options that are logical established in order to provide a greater complete understanding of the invention. It will be appreciated, however, by one skilled in the art, that the invention can be practiced without these specific details. In other cases, control structures, complete data structures and software instruction sequences have not been shown in detail so as not to obscure the invention. The experts in the field, with the
35 Descriptions included, will be able to apply the appropriate functionality, without undue experimentation.
Unless otherwise specified, the dashed lines in the figures (with the exception of the dashed lines) are used to represent optional elements in the figures. However, it should not be assumed that all optional elements are shown by dashed lines, but that those shown on dashed lines were chosen for a variety of reasons (for example, they could be easily displayed, to provide greater clarity, etc.)
References in the memory to ~ an embodiment ~, ~ an embodiment example ", etc., indicate that the described embodiment may include a particular feature, or structure, but not necessarily all embodiments.
Four. Five They can include the particular feature, or structure. In addition, these phrases do not necessarily refer to the same embodiment. In addition, when a particular feature or structure described in connection with an embodiment, it is said that it is within the skill of a person skilled in the art to affect this characteristic or structure in relation to other embodiments whether or not it is explicitly described.
In the following description and in the claims, the "coupled ~ and ~ connected" lines, together with their derivatives, can be used. It should be understood that these terms are not intended as synonyms for each other. On the contrary, in particular embodiments, "connected" may be used to indicate that two or more elements are in direct contact with each other. "Coupled" may mean that two or more elements are in direct contact. However, "coupled" can also mean that two or more elements are not in direct contact with each other, but
55 still cooperate or interact with each other.
In some cases, flowchart operations are described with reference to the exemplary embodiments of the other block diagrams. However, it should be understood that the operations of the flowcharts can be performed by embodiments of the invention other than those described with reference to these other block diagrams, and that the embodiments of the invention described with reference to these other block diagrams may Perform operations other than those described with reference to the flowcharts.
The techniques shown in the figures can be implemented using codes and data stored and executed on one or more computers. These computers store and communicate (internally and with 65 other devices over a network) codes and data using machine-readable media, such as machine storage media (e.g. magnetic disks, optical disks; random access memory,
read-only memory, flash memory devices) and media of the machine (for example, electrical, optical, acoustic or other forms of reproduced signals, such as carrier waves, infrared signals, digital signals, etc.). In addition, these computers typically include a set of one or more processors coupled to one or more other components, such as a storage device, a series of
5 user input / output devices (for example, a key and a screen), and a network connection. The coupling of the set of processors and other components is normally through one or more buses and bridges (also referred to as bus controllers). The storage device and network traffic represent, respectively, one or more storage media of the machine and the communication media of the machine. Thus, the storage device of a given computer system typically stores codes and data for execution in the set of one or more processors of said equipment. Of course, one or more parts of an embodiment of the invention can be implemented using different combinations of software, firmware and / or hardware.
General information
According to one aspect of the invention, a producer is at least a specific example (or object) and a specific method, such that if the producer is executed during the execution environment, the specific method is executed in the specific instance . Therefore, a given producer is instantiated from a given instance and a given method associated with that instance. Like classes, instances and methods, producers are basic elements or constructions manipulated by the execution environment. Therefore, the instantiation of a producer is interpreted and followed by the execution environment, and therefore, the execution environment follows the combination of instances and methods represented by the producers. In other words, a producer is a construction that can be instantiated from the execution environment that is followed by the execution environment, which is executed by the execution environment, and that includes at least one instance and a method associated with that instance,
25 such that the execution of the producer's execution times results in the method of the producer that is executed at the producer's instance. In addition, a producer's method has associated with it a declaration of producer dependence that identifies, with a set of zero or more producer dependencies, a set of zero or more producers for a given producer. Specifically, producer dependencies are declared for methods that use producer dependency declarations, the producer dependency declaration of a particular method may include zero or more producer dependencies, and each producer dependency identifies a set of zero or more producers. Therefore, the declarations of dependence of the producers and the dependencies of the producers that are defined are interpreted and followed by the execution environment, and therefore, the execution environment tracks the relationships between the indicated producers. by the declarations of dependence of the producers.
35 When a given producer depends on a set of one or more other producers, the execution environment will ensure the execution of all other producers before the given producer. Therefore, the declarations of dependence of the producers represent the relations of execution between the producers, while the producers represent the operations to be carried out (methods) and instances. Although in some embodiments of the invention the dependencies of the parent producers on the descending producers are allowed to be declared in the declaration of dependence of the producer associated with the method of the parent producer (the declaration of the dependence of the producer of the parent producer is identified with any of the descending producers - indicated here as declared descending), Other embodiments of the invention also allow dependencies to be declared in the producer dependency declaration associated with the
Four. Five method (s) of the descending producer (s) (the producer's dependency declaration of the descending producer identifies one or more parent producers - indicated here as declared ascending).
In different embodiments of the invention, a producer identifies additional things. For example, while in some embodiments of the invention, a producer is at least one instance and a method associated with that instance, in other embodiments of the invention, a producer is a class, an instance of that class, and an associated method. with that instance (for example, a producer can directly include a class, instance, and a method; a producer can directly include an instance and a method, while indirectly identifying a class of that instance through a reference (for example, a reference in the instance ». Although the invention can be used in the context of the code written in different programming languages (for example, object-oriented code written in a reflective object-oriented language; object-oriented code written in an object-based reflective language, the code written in a non-reflective object-oriented non-reflective method language and transformed into object-oriented reflective language code), the embodiments of the invention will be described, by way of example and not limitation, with reference to object-oriented reflective programming languages and with reference to producers that directly include classes, instances and methods. Furthermore, although in one embodiment of the invention the method of a producer is an instance method (a method that can use instance fields in addition to any input received as arguments), alternative embodiments of the invention may also or alternatively, support the method of a producer that is a class method (methods that receive all inputs as arguments and / or use independent instance variables) (where a producer's method is an instance method, the producer's instance is
65 an instance of a class, while in the method of a producer is a class method, the instance of that producer is a meta-class instance that represents the class).
Figure 1A is a block diagram illustrating the relationship of a producer dependency declaration for a method of a class in an object-oriented source code of a producer that includes the class, a given instance of that class, and a method of that class, according to an embodiment of the invention. In the figure
5 1A, an object-oriented source code 100 is shown that includes a class 102, which in turn includes a method 104 and a producer dependency declaration 106 for method 104. Of course, class 102 typically includes one or more fields (not shown) and additional methods (not shown). In addition, the source code or object-oriented 100 typically includes additional classes.
During the runtime environment, an instance 108 of class 102 is instantiated. The instance 108 includes the data of the fields of class 102. In addition, a producer 110 is instantiated, when the producer 110 identifies the class 102, the instance 108 of the class 102 (which has associated with it method 104 of the class 102), and method 104 of class 102. The producer dependency statement 106 identifies the execution environment of a set of zero or more producers 112 (hereinafter, producers descending from producer 110) that must
fifteen be executed before the execution of the producer 110. In other words, the producer 110 depends on the set of zero or more producers 112. In addition or instead of the consumption outputs of the producer 112 as a whole, the producer 110 may consume data from the instance 108. In addition, producer 110 provides at least one output, the output of which can be internal to instance 108 (and therefore, modify the data of example 108) and / or can be external, in any way, the output of producer 110 can be be consumed by a set or zero or more of other producers 114 (referred to as producer producers father 110)). As indicated above, and as described in more detail later in this document, the producer dependency statement 106, in some embodiments of the invention, can also identify the zero or more execution performance of the producers 114.
25 It should be understood that the inputs and outputs of the producers are based on the inputs and outputs of the methods on which the producers are based. As such, these inputs and outputs can represent several parameters that have a variety of data structures.
The producer dependency declaration for a given method identifies in the execution environment of the set of zero or more producers to be instantiated and executed. As an example, when a producer dependency declaration (for example, producer dependency declaration 106) for a given method (for example, method 104) identifies a producer dependency on a given producer (whose given producer identifies a first class, a first instance of that class, and a first method of that first class) (for example, one of all producers 112), then the producer's dependency declaration
35 given method identifies the execution environment that the first instance must be instantiated (if it is not already) and that the first method uses to create an instance of the given producer for the first instance (in these examples, it first does not mean location or order).
In operation, when, during the execution environment, a set of one or more producers are designated as of interest and have the dependencies of the producers declared by them, the execution environment: 1) generates automatically (discover, develop , and, optionally, solves) a set of one or more graphs, which can be of multiple levels and can be of a variety of forms (eg, chain. tree). from the given set of producers designated as of interest down to the producers of origin based on the declarations of dependence of the producers, and 2) the execution of the sequences of the producers of the series
Four. Five of graphs to generate the output (s) of the given set of producers designated as of interest. Therefore, the runtime environment uses producer dependency statements to determine which methods with which arguments are executed in which instances, and when for synchronization purposes.
Therefore, producer units represent the sequence of execution of producers in the execution environment. However, in addition to indicating the sequence of execution, the dependencies of the producers may represent different input and output relationships in different embodiments of the invention. For example. different embodiments of the invention may support one or more of the arguments producer dependencies, field producer dependencies and sequencing only producer dependencies (sequencing only producer dependencies referred to herein.
55 document with the abbreviation dependencies of sequencing producers). Although each of the arguments producer dependencies, the field producer dependencies and sequencing producer dependencies represent the execution sequencing relationships between the producers, the argument and the field producer dependencies, in addition, they represent the data of which the execution environment is conscious. Specifically, a dependency of the argument producer causes the execution environment to assign the output of a descendant producer as an input parameter to a parent producer, while a dependency of the field producer indicates the use of a field of an instance. Regardless of the input in relation to the output represented by a dependency of the producer, ensuring the appropriate use of the producer's dependencies that the producers access the information that is sequenced after the producers impacting the information.
Sequencing dependencies can be used for a variety of purposes, including ensuring the
Execution order between the producers who modify the data in a way in which the execution environment is not aware and producers who consume the data (a descendant producer can write their outputs in a way that requires the method of the parent producer to include code to access the output (for example, a method that impacts the environment by affecting an output that is not the output of the regular producer and, as such, that
5 It is not detected by the runtime environment - such as a method that sets a global variable, which defines a field in an instance that is not the output of the producer, which affects an eld data source: erno, etc.)). Thus, a sequencing dependency reflects a dependency of a parent producer on a descendant producer, but requires outputs that need to be provided, if any, to each other that occur through the writing of the code (for example, code in the method from the descending producer to write an output to a given mechanism (such as setting a global variable, the impact of an external data source, establish a field of an example that is not the output of the producer, etc.) and a code in the method of the parent producer to read the output of the given mechanism). In this way, the sequencing dependencies allow the execution environment to synchronize the execution of the parent producers that are based on an output that the execution environment cannot detect.
In one embodiment of the invention, the producer dependency declaration of a particular method identifies only the direct dependencies on the producers (for example, direct descendants (children), in contrast to the indirect descendants (grandchildren, great-grandchildren, etc.)) . In this embodiment, each producer dependency declaration provides only a single layer layer of producers whose outputs can be used directly by a producer instantiated from the given method, leaving the discovery / construction / resolution of additional layers of the graph (s) of the producer for processing the execution environment of other producer dependency statements.
Sample keys
25 A producer can be seen as a set of multiple identifiers, an identifier for each additional level of specified granularity (class, instance, method, etc.). In addition, some embodiments of the invention apply each identifier as a separate key, while other embodiments have certain identifiers that share a key. By way of example, some embodiments of the invention implement a producer as a class triplet, instance, and method and implement the keys, such that each part of the triplet is identified by a separate key (a class key, a key instance, and a method key) and the producer is identified by the combination of the class key, the instance key, and the method key (the producer key).
35 Embodiments of the invention that use keys may vary in the uniqueness of the keys used. For example, in one embodiment of the invention, each class key is unique, each instance key is unique in all cases of all classes, and each method key is unique in all methods of all classes. As another example, in other embodiments of the invention, each class has a unique key, each instance of a given class has a unique key (through the instances of the class), and each method of a class has a unique key ( through class methods), but instances of different classes can have the same instance key, and different class methods can have the same method key; This approach will be used later in the rest of the document as an example and not as a limitation. For example, suppose that a first class includes methods and has a key for each of these methods that is unique within the first class, then instances of this class (that each has a unique key to each other) has the same keys of
Four. Five method associated with them. As another example, suppose a different second class includes methods (some, all, or none of the same as the methods of the first class) that have the same method keys as those used for the first class, as such, an example of This different class can be associated with the same method keys that are associated with an instance of the first class.
The use of the keys allows a wide variety of features, including: 1) the monitoring of each entity identified by the identifiers of a producer (for example, the monitoring of each class, instance, and method), 2) several parent producers (without realizing their mutual existence) to connect with the producer of the same descendant based on their declarations of dependence on producers (which specify the dependencies of producers with producer codes), etc. In one embodiment of the invention, the instance key is a
55 instance of a class (Instance Key) that supports two elements: an instance key nature that indicates whether the key identifier is a reference to the instance or other object (such as a string), and a key identifier that it can be a reference to the instance, or to another object (such as a string). Storing a reference to the instance in the instance key saves the programmer from inventing a name to identify these cases.
Sample Relationships
In the context of the previous discussion regarding a producer that is being viewed as a set of multiple identifiers (with an identifier for each additional level of specified granularity), in an embodiment of the invention, the various relationships between the support of a producer and his children And the parents are those in which at least one identifier is different between a producer and his set of zero or more
Parent producers and an identifier is different between a producer and each of its set of zero or more descendant producers. By way of providing some example relationships, suppose a first producer is instantiated, where the first producer is a first instance of a first class and a first method of that first class, and the producer's dependency declaration is assumed to that first method
5 identify the execution environment of a second producer as a descendant, then the second producer can be: 1) the first instance of the first class and a second method of that first class, 2) a second instance of the first class and a second method of that first class, 3) a second instance of the first class and the first method of the first class, or 4) an instance of a second class and a method of that second class. In such a case, the first producer depends on the second producer - therefore, it represents an entry in the output ratio of the first producer to the second producer. Various relationships and combinations of these relationships are described below for an embodiment of the invention that uses an object-oriented language and in which a producer identifies at least one class, instance, and method.
Figures 1A-1D illustrate example relationships between a given producer, his set of parent producers, and his
fifteen set of descendant producers according to an embodiment of the invention. Figures 18-1 D each show the following: 1) a definition of class 102A, including methods 104A-C and statements of dependency producers 106A-C for each of these methods, respectively, 2) a definition of class 1028 including methods 104D-E and declarations producer dependence 106D-E for each of those methods, respectively, and 3) a class definition 102C, including method 104F and producer dependency declaration 106F for that method; 4) an instance 108A of class 102A, 5) a producer 110A that identifies class 102A, instance 108A, and method 104A, and 6) a producer 112A.1 and a producer 114A.1 respectively representing one of the set of Producers 112 and 114. The dashed lines with boxed letters in them are used in Figures 18-10 to illustrate the example relationships. Thus, the collection of the dashed lines with an A box in them represents a relationship. The relationships in Figure 18 can be
25 Combined with the relationships in Figure 1C, as such, these combinations represent combinations of the relationships between the parent producers 114A and the descendant producers 112A to the producer 110A. In addition, Figure 1D illustrates some additional example combinations of the relationships between parent producers 114A and descendant producers 112A and producer 110A.
Figure 18 illustrates the example relationships between producer 110A and parent producer 114A.1 in accordance with an embodiment of the invention. Figure 18 additionally includes an instance 1088. The set of producers 114 is identified by other declarations of dependence of the producers of the different method (s) of the same class, different instances of the same class, and method (s) of a different class, and therefore , each of the series of producers 114 can be: 1) of the same instance as producer 110A (instance 108A of class 35 102A) And a different method associated with that example (illustrated by box A in the dashed lines of instance 108A for producer 114A.1 and from method 1048 to producer 114A1), 2) of a different instance of class 102A AND a different method associated with that example (illustrated by box 8 in the dashed lines of class 102A to instance 1088, from instance 1088 to producer 114A.1, and from method 1048 to producer 114A1), 3) of an instance of a different class and a method associated with that instance (illustrated by box C on the dashed lines from class 1028 to instance 1088, from the instance 1088 to producer 114A.1, and from method 1040 to producer 114A.1), or 4) of a different instance of class 102A (instance 108A) and the same method (method 104A) of that instance (for example, with a contingent dependency - described later in this document) (illustrated by box D in the dashed lines of class 102A to instance 1088, from instance 1088 to producer 114A.1, and from method 104A for producer 114A1); also,
Four. Five when there are multiple producers in the set of producers 114, producers 114 may be part of the same instance of class 102A, different instances of class 102A, an instance of a different class, and / or a mixture of the above.
Figure 1C illustrates the example relationships between producer 110A and descending producer 112A.1 according to an embodiment of the invention. Figure 1C additionally includes an instance 108C. Each of the 112A set of producers can be: 1) of the same instance as producer 11 DA (instance 1 OBA of class 102A) and a different method associated with that instance (illustrated by box E in the dashed lines of instance 108A to producer 112A.1 and from method 1 Q4C for producer 112A.1), 2) of a different instance of class 102A and a different method associated with that instance (illustrated by box F on the dashed lines of class 102A in instance 108C , from instance 108C to producer 112A.1, and from method 104C to producer 112A.1), 3) of an instance of a different class and a method associated with that instance (illustrated by box G in the dashed lines of class 102C to instance 108C, from instance 108C to producer 112A.1, and from method 104F to producer 112A.1), or 4) from a different instance of class 102A (instance 108) and the same method ( method 104A) of that instance (for example, with a contingent dependency described later in this document) (illustrated by box H in the dashed lines of class 102A to instance 108C, from instance 108C to producer 112A.1, and from method 104A to producer 112A.1). Thus, each set of producers 112A can be from the same instance as producer 110A, from a different instance of class 102A, or an example from a different class; in addition, where there are multiple producers in the set of 112A producers, 112A producers may be part of the same class 102A instance, instances
65 different from class 1Q2A, the same instance of a different class, different instances of a different class, and / or a mixture of the previous ones.
Figure 1D illustrates some additional example combinations of the relationships of parent producers 114 and descendant producers 112 to producer 110A according to an embodiment of the invention. Figure 10 also includes instance 1088 and instance 108C. The combinations of Figure 10 are shown in Table 1 below:
Figure 1E illustrates that different instances of the same class may have producers based on the same and / or different methods according to an embodiment of the invention. Figure 1E shows: 1) the class definition 102A, which includes methods 104A-C and the producer dependency declaration 106A-C for each of these methods, respectively, 2) instance 108A and instance 1088, belonging to class 102A, 3) a producer 110A is method 104A of instance 108A of class 102A, 4) a producer 110B is method 1048 of instance 108A of class 102A, 5) a producer 11 OC is the method 104A of instance 1088 of class 102A; And 6) a producer 11 OD is method 1 04C of instance 1088 of class 1 02A. In addition, Figure 1 D shows that: 1) the producer dependency declaration 106A for method 104A identifies an execution environment for the producers descended from producer 110A and producer 110C, 2) the producer dependency declaration 1068 for method 104B identifies the producer's execution environment descendant of producer 1108, and 3) the producer dependency statement 106C of method 104C identifies the execution environment of the producer descending from producer 1100.
Sample Execution Times
Figure 2 is a block diagram illustrating the ability to reuse an execution environment with the programming support oriented to the producer's graph according to an embodiment of the invention. In Figure 2, several object-oriented application programs (object-oriented application code with producer dependency statements 210A-I) are executed by the same execution environment with the help of producer-oriented programming support. 220.
Fig. 3A is a block diagram illustrating an execution environment with the graphical oriented programming support of the producer according to an embodiment of the invention. In FIG. 3A, an execution environment with programming support oriented to the producer graph 335 includes an automated generator graph generation module 340 and an producer graph execution module 345. In addition, the execution environment 335 is for executing the object-oriented source code, and therefore includes additional modules that are not shown.
In addition, Figure 3A shows producer dependency statements for object-oriented source code methods 320, a current set of one or more producers whose outputs are of interest 325 (also
5 here referred to as the currently selected producers of interest), and the outputs of producers of origin 330 (described later in this document). The graph generation module of the automated producer 340 receives the dependency statements of the producers 320 and the current set of producers of interest 325.
The graph generator module of the automated producer 340 attempts to discover, from the producer dependency declarations, the descending producers with outputs that contribute directly and indirectly to the input of the selected producers of interest (and in some embodiments of the invention that support upwardly declared dependencies, parent producers), and builds a set of one or more current graphs of producers that represent the dependence of these producers on each other on the producers
fifteen currently selected of interest, through any discovered producer who are producers without origin, to whom the discovered producers are producers of origin. The graph (s) of the current producers is stored in the structure of the graph (s) of the producer 380. While the embodiments of the invention may store and manipulate the producer's graph (s) as a collection of graphs, other embodiments of the invention store and manipulate the producer's graph (s) as a collection of producers that are linked together. form graph (s) (as opposed to a collection of graphs) to facilitate the fusion and excision of the producer's graphs. By way of example and not limitation, the embodiments of the invention that store and manipulate the producer graph (s) as a collection of producers are described herein.
The producer module execution module 345 receives the graph (s) of the current producer from the module
25 generation of the graph of the automated producer 340 and the outputs of the producers of origin 330, and executes the producers of the graph (s) of the current producer to determine the current output of the currently selected producers of interest. The producer graph execution module 345 caches the current outputs of the producers in the structure of the producer graph (s) 380 as illustrated by caching the output of the producer 384.
Caching the producers' outputs of the producer's graph during execution allows synchronization. For example, the appropriate time to execute a parent producer that depends on multiple descendant producers is after all multiple descendant producers have been executed, in other words, it would be a waste (and, in some cases, not possible) to run the producer. father every time one of its descendant producers has completed its execution. The caching of the producers' outputs allows the execution of the parent producer not only to be postponed until all his descendant producers have been executed, but also allows a determination of the appropriate time for the execution of the parent producer - when all Descendant producers have been executed and their results have been stored. Thus, the execution environment makes this synchronization decision for the programmer checking the execution status of its descendant producers, in other words, said synchronization is automated (the programmer does not need to include the independent source code that determines the appropriate time to identify an instance and execute a given method associated with that instance in that instance). By way of another example, where several parent producers depend on the same descendant producer, as well as other producers other than the descendants, the appropriate time to execute each of the several producers
Four. Five father is usually different, the execution environment automatically determines the appropriate time to execute each of the several parent producers depending on the availability of the outputs of their set of secondary producers.
As will be described in detail later in this document, since some parts of a producer graph may not be detectable at present due to dynamic producer dependencies, the automated producer graph generation module 340 "attempts" to discover and build the graph of the entire producer, but may not initially be able to complete the entire graph of the producer until some producers run. As such, the producer graph execution module 345 can invoke the automated producer graph generation module 340 with the outputs of the necessary producers during the graph execution
55 from the current producer to complete any unresolved remainder of the current producer's graph (this is illustrated in Figure 3A by a dashed arrow line from the graph execution module of producer 345 to the graph generation module of automated producer 340, and use a dashed line with an arrow because this support is optional).
Figure 4A is a block diagram illustrating the discovery and construction of a graph of the example producer according to an embodiment of the invention. Figure 4A shows that the current set of producers of interest consists of producer 1. On the basis of producer 1 and its declaration of dependence on producer, producer 2 and producer 3 are discovered. In other words, the producer's dependency declaration for producer 1 identifies that entry to producer 1 requires the execution of producer 2 and producer 3. As such, producer 1 is a dependent producer (a producer who has one or more more dependencies of producers). Figure 4A also shows that while producer 3 is an independent producer (a
producer that has no dependence on producers, and therefore is a producer of origin), producer 2 is not. As a result, based on the declaration of dependence on producer 2, producer 4 and producer 5 are discovered. In Figure 2A, producer 4 and producer 5 are independent producers (and therefore, origin producers ).
Figure 48 is a block diagram illustrating the initial execution of the graph of the producer of Figure 4A according to an embodiment of the invention. In Figure 48, the curved lines with an arrow illustrate the execution of one of the producers to generate an output that is provided as the input to another producer. As shown in Figure 3A, the output of the origin producers 330 is provided to the module execution module of the producer 345; in contrast, the outputs of dependent producers 1-2 are determined by the execution of said producers, as shown in Figure 48. Therefore, in Figure 48, the following occurs: 1) the output of the producer of origin 4 and the producer of origin 5 is provided to the dependent producer 2, 2) the dependent producer 2 is executed, and 3) the outputs of the dependent producer 2 and origin producer 3 are provided to producer 1; And 4) producer 1 is executed and its output is provided as the current output of interest. It must be indicated
fifteen that the graph of the producer of Figure 48 is the data that circulates in the sense that the data flows from one producer to another producer of the graph.
Thus, the producer dependency statements 320 together with the possible graphs of producers that can be generated, while the currently selected set of producers of interest 325 identify the initial node (s) of the graph of the current producer that is generated . Of these two, the graph generator module of the automated producer 340 discovers and builds the graph of the producer. The discovery and construction is automated because the graph generator module of the automated producer 340 does not provide the graph of the producer (for example, it does not need to be manually identified by a programmer) or even a list of the producers that will be in the graph of the producer. On the contrary, the producer's graph generation module
25 Automated 340 analyzes the producer's declaration (s) of the current set of selected producers of interest to discover their descendant producers (and in some embodiments of the invention that support declared ascending dependencies, parent producers), then analyzes the producer dependency statements of said discovered producers, and so on down to the producers of origin (in some embodiments of the invention described later in this document, this can be done with the help of the producer graph execution module 345). In the event that the producer's graph is a tree, a currently selected producer of interest will be the root node, and producer dependency statements will be analyzed until leaf nodes (originating producers) are discovered.
Producers of cancellation and incremental execution
35 Fig. 38 is a block diagram illustrating an execution environment with the graphically oriented programming support of the producer which also supports incremental execution and cancellation outputs of the producer according to an embodiment of the invention. It should be understood that incremental execution and cancellation outputs of the producer are each independent optional features, and therefore, different embodiments of the invention may apply one or both.
In Fig. 38, an execution environment with a programming support oriented to the producer 360 graph includes an automated generator graph generation module 365, a producer graph execution module 370, and an output producer producer module. cancellation 390. The execution environment 360 is the execution of the
Four. Five Object-oriented source code and, thus, thus includes additional modules than shown.
In addition, Figure 38 shows the producer dependency declarations for object-oriented source code methods 320, the current set of one or more producers whose outputs are of interest 325 (also referred to herein as the currently selected producers of interest), and the departure of producers of origin 350. The output of the originating producers 350 includes the results of the independent producers established in source code 352 (for example, the constants, the default values, etc.) and the outputs of the currently annulled producers 354 (the outputs of the independent producers and dependent producers whose departures are currently canceled).
55 In some embodiments of the invention, the outputs of the producers can be explicitly voided with a currently provided value (that is, instead of executing a producer to determine their output value based on their current inputs, the output value for the producer is explicitly provided). In addition to the independent producers of a producer graph, the producers of origin of a producer graph are currently voided producers.
The output module of the cancellation producer 390 receives the outputs of the cancellation producer 354 (which identifies the producers are being annulled and whose output values are being annulled). In one embodiment of the invention, producers can be classified as property producers or method producers. Property producers are those that rely on property methods (for example, obtain and establish). 65 The method producers are those based on non-property methods. The output module of the cancellation producer 390 includes an output module owned by the cancellation producer 392 for the producers of
voided property and an output module of the void method producer 394 for the voided method producers. The output module of the void ownership producer 392 causes the voided value to be stored in the cache of the output producer 384 and in the instance data, while the output module of the voided producer method 394 causes the value voided be stored in the output cache of the
5 producer 384. Depending on the embodiment of the invention, this causal relationship may be direct or indirect. Figure 3B illustrates an indirect causal relationship through the use of an override register 396 that collects the output of the output module of the override producer 390 and that is consumed by the execution module of the producer graph 370. For optimization purposes, the cancellation record 396 allows the delay of cancellations to collect multiple batch processing cancellations.
As in the module of automatic generation of the graph of producer 340, the module of automated generation of the graph of producer 365: 1) receives the declarations of dependence of producer 320 and the current set of producers of interest 325, and 2) tries to discover, on the basis of the declarations of dependence of the producers, descending producers with outputs that contribute directly and indirectly to
fifteen the entry of the currently selected producers of interest (and in some embodiments of the invention that support the declared upward dependencies, parent producers), and constructs a set of one or more current producer graphs that represent the input dependency of these producers on each other. of the selected producers of interest, through any producer discovered not of origin, to the discovered producers who are producers of origin (independent producers and currently annulled producers). The producing graph (s) is stored in the producing graph (s) of the structure 380.
Similar to the producer graph execution module 345, the producer graph execution module 370 receives the graph from the current producer from the automated graph module 365 and the outputs of the originating producers 350, and executes the producers from the producer graph current to determine the current output of the producers
25 Selected of interest. The producer graph execution module 370 caches the current results of the producers of the structure of the producer graph 380 as illustrated in the output cache of the producer 384. As described previously, the cache of producer outputs during the axis allows synchronization (for example, the separate source code does not need to be written to determine when producer 2 of Figure 48 should be executed, but rather the environment Execution makes this synchronization decision for the programmer by checking the availability of the necessary outputs in producer output cache 384, in other words, such synchronization is automated). In addition, this output cache of producer 384 is used for incremental execution. More specifically, after a producer graph has been initially generated and executed, the cancellation of a producer in the current producer graph
35 It requires a certain level of additional execution. While some embodiments of the invention simply rerun the entire graph, alternative embodiments of the invention support incremental execution (rerun only those parts of the producer's graph that are affected by the override). Some embodiments that support incremental execution use incremental execution by marking 382 in the structure of producer graph (s) 380 to help determine which producers require additional execution. Therefore, maintenance of the producer graph (s) refers to the modification of the links of the producer graph (s) as necessary through multiple executions to keep updated (to the dial), while incremental execution refers to both to maintain the graph (s) of the producer and use the graph (s) of the current producer (per day) to rerun only those parts of the graph (s) of the producer that are affected by an annulment.
Four. Five Similar to Fig. 3A, there is an arrow dashed line from the producer graph execution module 370 to the producer graph automated execution module 365 to represent an optional support for dynamic dependencies. It should be noted that dynamic dependencies may change during the additional execution of a producer graph.
Figure 4C is a block diagram illustrating the incremental execution of the graph of the producer of Figure 48 according to an embodiment of the invention. In Figure 4C, the output of producer 5 has been explicitly modified, but the outputs of producer 3 and producer 4 have not. Based on the monitoring of the dependencies from the exit to the entry in the graph of the producer and that only the output of the producer 5 has been explicitly modified, it is determined that only producer 2 and producer 1 are affected by this
55 modification. As a result, the determination of an updated output of producer 1 requires only the additional execution of producer 2 and producer 1 with the new output of producer 5 and the previous outputs of producer 4 and producer 3. This additional partial execution of the producer's graph is illustrated in Figure 4C by curved lines with an arrow from producer 5 to producer 2 and from producer 2 to producer 1, but not from producer 4 to producer 2 or from producer 3 to producer 1 . The lack of curved lines with arrows from producer 4 to producer 2 and from producer 3 to producer 1 are not to indicate that outputs from producer 3 to producer 4 are not necessary, but instead, producer 3 and producer 4 they do not need to be rerun if their output is available before. (For example, cached since the previous execution of the producer graph).
65 The relatively simple example of Figure 4C illustrates that there can be no savings in processing resources as a result of incremental execution. These savings will depend on a number of factors (for example, the number of producers that do not need to be re-executed, the amount of processing these producers would have required, etc.). Although an embodiment of the invention is illustrated as performing incremental execution, alternative embodiments may be implemented differently (for example, an alternative embodiment may be rerun so that all producers respond to a modification).
Figure 40 is a block diagram illustrating the incremental execution of the graph of the producer of Figure 4B after the dependent producer 2 has been overridden according to an embodiment of the invention. In Figure 40, the output of producer 2 has been explicitly modified, but the output of producer 3 has not. Based on the graph of the producer and that only the output of producer 2 has been explicitly modified, it is determined that only producer 1 is affected by this modification. As a result, the determination of an updated output of producer 1 requires only the additional execution of producer 1 which is canceled with the output of producer 2 and the modified output of producer 3. This additional partial execution of the producer graph is illustrated in Figure 40 by a curved line with fledla from producer 2 to producer 1, but not from producer 4 to producer 5
or from producer 3 to producer 1.
Figure 4E is a block diagram illustrating the incremental execution of the graph of the producer of Figure 4B after the dependent producer 2 has been canceled and the independent source producer 3 has been modified according to an embodiment of the invention. Based on the graph of the producer and that only the outputs of producer 2 and producer 3 have been modified, it is determined that only producer 1 is affected by this modification. As a result, the determination of an updated output of producer 1 requires only the additional execution of producer 1 which is replaced with the output of producer 2 and the modified output of producer 3. This partial additional execution of the producer's graph is illustrated in the figure. 4E using a curved arrow line from producers 2 and 3 to producer 1, but not from producers 4 and 5 to producer 2.
25 Although an embodiment of the invention that supports the outputs of the cancellation producer also supports the outputs of the cancellation producer, alternative embodiments of the invention do not. Although an embodiment of the invention that supports cancellation producers leaves an annulment producer annulled until it is specifically annulled, alternative embodiments of the invention can be implemented differently (eg, by canceling an annulled producer when one of its progeny is annulled). .
Construction and execution of the producer graph
Different embodiments of the invention can be implemented to discover and build a producer graph in different grades (for example, build the producer graph until all roads from the end of the
35 root node in independent producers (in which case, the end nodes of a producer graph are independent producers, with the possibility that any voided producers are intermediate nodes); build the producer graph until each path from the root node ends in a voided producer or an independent producer, whichever is reached first (in which case, each end node of a producer graph is an independent producer or producer canceled)).
~ Start execution producers ~ refers to the producers of a producer graph from which a given execution of the producer graph begins. For an initial execution of a producer graph, different embodiments may start from different producers (for example, in the embodiments of the invention that construct the producer graph until all paths from the root node end in producers 45 independent, the execution can start from the end nodes (which would be independent producers), from the origin producers (which would include the nodes of independent producers and the nodes of annulled producers), from a subset of origin producers that consist of the combination of any independent producers with at least one path between them and the root producer that does not include a voided producer and any voided producers, or from a subset of producers of origin consisting of the combination of any annulled producers without any type of offspring that are annulled and any independent producers with at least one path between them and the producer who does not include a voided producer; In embodiments of the invention where the graph of the producer under annulled producers is not constructed if and until a producer is withdrawn, the execution can start from the end nodes (which can be independent producers and / or
55 canceled producers), etc.).
For subsequent executions of a producer graph, different embodiments may start from different producers (for example, from independent producers of the producer graph (for example, in embodiments of the invention that do not support incremental execution), from the producers of origin of the graph of producers (for example, in the embodiments of the invention that do not support the incremental axis); from a subset of the origin producers consisting of the origin producers that have been annulled and / or added since the last execution (for example, in the embodiments of the invention that are made compatible with the incremental execution), to from the origin producers that have been annulled and / or added since the last execution, from the combination of the annulled producers without descendants that are annulled and any added producers, with at least one path between them and the root producer that does not include a voided producer (for example, in the embodiments of the invention that support execution
incremental); etc.). By way of example and not limitation, the embodiments of the invention that perform the following are described below: 1) do not construct the producer's graph under voided producers if and until this producer has not withdrawn the annulment; 2) for an initial execution of a producer graph, start the execution of the end nodes (which can be independent producers and the annulled producers), 3) implement the
5 Gradual execution, and 4) for subsequent executions of a producer graph, start the execution of a subset of the origin producers consisting of those origin producers that have been canceled and added since the last execution.
With respect to the previous concept of the producers of the beginning of the execution, the processing flow of the execution of the graph of the producer also differs between the different embodiments. For example, in one embodiment of the invention, the ancestry of the start-up execution producers is determined and placed in a collection, the start-up producers are executed, and the collection is analyzed iteratively in search of producers for which all the dependencies have been executed -eventually, the nodes of ra iz are reached. As another example, in one embodiment of the invention, the start-up producers are
fifteen they execute, the parents of the startup execution producers are identified, the parents are executed, and their parents are identified and executed, and so on. This last embodiment of the invention is then used by way of example, and not limitation.
Sample types of dependencies
Dynamic dependencies of sample producers
A dynamic producer dependency is a producer dependency that can change during execution. It should be understood that the criteria for resolving producer dependence are present in the source code, and therefore, producers to whom producer dependence can be resolved are limited. With reference to Figure 3A, the dashed line with arrow from the producer graph execution module 345 to the automated generator graph module 340 represents a support for the axis of one or more producers in the graph of the current producer who they are necessary to discover and build the entire graph of the current producer. In other words, an embodiment of the invention that supports the dynamic dependencies of producers can iterate between the automated generator module of producer graph 340 and the producer graph execution module 345 until the producer's entire graph is discovered, build, and execute, that is, iterate between: 1) the invocation of the automated generator generation module of the producer to discover and construct the parts of the current producer graph that can be resolved at that time, and 2) the invocation of the producer graph execution module to execute the producers of the producer graph
35 current). In this sense, discovering refers to the access of the producer dependency statements and the determination of the producers that are identified; the creation refers to instances of the producers and their addition to the graph of the producer, and the resolution refers to the determination of the dynamic dependencies of currently unresolved producers.
Figure 5A is a block diagram illustrating the discovery and construction of a graph of the example producer that includes an unresolved dependency according to an embodiment of the invention. Figure 5 shows the current set of producers of interest consisting of producer 1. On the basis of producer 1 and its declaration of dependence on producer, producer 2 and producer 3 are discovered. In other words, the dependency declaration for producer 1 identifies that producer 1 requires as inputs the output of
Four. Five producer 2 and producer 3. Figure 5A also shows that while producer 3 is an independent producer (and therefore a producer of origin), producer 2 is not. As a result, based on the declaration of dependence of producer 2, producer 4 and producer 5 are discovered. In addition, Figure 5A shows that while producer 4 is an independent producer (and therefore, a producer of origin), producer 5 is not. As a result, based on the producer's dependency statement 5, producer 6 and the currently unresolved dependency are discovered. Figure 5A also shows that the currently unresolved unit can be producer 7A and producer 7B.
Figure 5B is a block diagram illustrating the initial execution of the graph of the producer of Figure 5A and the resolution of the unresolved dependency according to an embodiment of the invention. Figure 5B shows the
55 graph of the producer of Figure 5A, with CUNas lines with arrows showing the execution of the producers and the provision of their outputs to the dependent parent producers. In addition, Figure 58 shows that the unresolved dependency of producer 5 is resolved as a dependency on producer 7A, and that producer 7A is an independent producer.
Figure 5C is a block diagram illustrating the initial example of the graph of the producer of Figure 5A and the further embodiment of the graph of the producer of Figure 5B according to an embodiment of the invention. Figure 5C shows the graph of the producer of Figure 5A, with CUN lines with arrows showing the execution of the producers and the supply of their outputs to the dependent parent producers. In addition, Figure 5C shows that the unresolved dependency of producer 5 is resolved as a dependency of producer 7B and that producer 65 7B is a dependent producer. As a result, based on the producer dependency statement 7B, producer 8 is discovered. Producer 8 is an independent producer (and therefore, is a producer of origin).
Assuming that Figure 5C represents the initial execution of the graph of the producer of Figure 5A, all curved lines with an arrow in Figure 5C would be used. However, assuming that the figure represents the additional execution of the graph of the producer of Figure 5B, the additional execution results in the dynamic dependence that is solved differently (a switch from the producer 5 which is dependent on the producer 7A to the producer 5 7B). In addition, if the additional execution is carried out without incremental execution, then all the curved lines with arrow in Figure 5C are used, however, if the incremental execution was used, only the non-discontinuous arrow curved lines (of the producer 8 to producer 7B, from producer 7B to producer 5, from producer 5 to producer 2, and from producer 2 to producer 1). It should also be understood that the dynamic change in dependence illustrated in Figure SC is exemplary, and therefore, any number of different situations could arise (for example, dynamic change may never occur; producer 5 could have been first dependent producer 7B and then switch to producer 7A, producer 5 could have been first dependent on producer 7B and dynamic change does not always occur, producer 5 can be found to be dependent on producer 7A and from producer 7B as illustrated in Figure 50, etc.). Although different embodiments may resolve the dynamic dependencies of producers in different ways, some examples
fifteen They are provided later in this document.
Thus, the additional automated execution of a producer graph is not limited to the producer that is modified and to his direct father who is re-executed, rather a change is automatically wavy across the producer graph during the execution environment, which affects to the appropriate producers and their dependencies, because the producer's graphs are maintained (and incremental execution is used if supported). As such, the changes cause any additional necessary discovery, creation, resolution and execution. Thus, the additional execution of a producer graph is automated in the sense that a user / programmer does not need to determine which producers of the producer graph are affected, and possibly manually correct the graph.
25 Static producer dependencies
A static dependency is one that cannot be changed during execution. Thus, in one embodiment of the invention that supports dynamic contingent and subscription dependencies (described later in this document), a non-contingent dependency without subscription is a static dependency. The graph of the example producer of Figure 4A illustrates a graph of the producer of static dependencies.
Shapes of the producer's graph
Since a producer is at least one instance and a method associated with that instance, a producer graph is
35 a graph that represents the instances and the methods associated with the instances - and therefore, the graphs of the producer are at least instance and centric method. In embodiments of the invention in which a producer is at least one class, instance, and method, the graphs of the producer are at least class, instance and centric method.
It should be understood that a producer graph can take a variety of different forms (for example, a single producer chain, a tree, etc.). The graph of the example producer of Figure 5B is a tree with a root node of producer 1, from which there are two branches - one for each of producer 2 and producer 3. When producer 3 is a leaf node , producer 2 has two branches that extend from it - one to each of producer 4 and producer 5. Producer 5 has two branches that extend from it - one for each
Four. Five one from producer 6 and producer 7A. The graph of the example producer of Figure 5B is said to be multilevel, with level 1 including producer of root node 1, with level 2 including producer 2 and producer 3, with level 3 including producer 4 and producer 5, with level 4 including producer 6 and producer 7A (in figure SC, level 4 includes producer 7B, and level 5 includes producer 8). When considering the branch from producer 1 with producer 2, the first producer of the branch is producer 2 and the last producers of the branch are producer 4, producer 6, and producer 7A in Figure 58.
Although Figure 58 shows a producer graph in which the current set of producers of interest includes a single producer, embodiments of the invention that support more than one producer of current interest would discover and construct producer graphs for each. It should be understood that, when simultaneously there are 55 multiple producers of interest, the resulting producer graphs can be independent or can be crossed. When the producer graphs intersect, the embodiments of the invention can be implemented in: 1) duplicating the producers to keep the producer graphs separate, or 2) avoiding duplication and maintaining said intersection of the producer graphs. It should also be understood that these intersecting producer graphs may include a producer graph that is a subset of another producer graph. For example, if producer 5 was included with producer 1 in the current set of producers of interest, then there would be a first graph of the producer with a root node of the producer 5 and a second graph of the producer with a root node of the producer 1, where the second producer graph includes the first producer graph. If, for example, producer 7B was included with producer 1 and producer 5 in the current set of producers of interest, there would be a third graph of the producer, separated from the first and second graphs of the producer, with a root node from producer 65 7B in Figure 5B. In addition, if the dynamite dependence of producer 5 changes from producer 7A to producer 7B (figure 5C), then the change would result in the producer's third graph becoming a subset
of the second graph of the remaining producer, and the second graph of the producer becomes a subset of the first graph of the producer. As indicated above, although embodiments of the invention may store and manipulate the producer's graph (s) as a collection of graphs, other embodiments of the invention store and manipulate the producer's graph (s) as a collection of producers that are linked to each other
5 to form the graph (s) (as opposed to a collection of graphs) to facilitate the fusion and excision of the producer's graphs. By way of example and not limitation, the embodiments of the invention that store and manipulate the graph (s) of the producer as a collection of the producers are described herein.
Sample Execution Flow
Fig. 6 is a flow chart of a logical execution flow of a runtime client and its relation to a runtime environment with the programming support oriented to the producer's graph according to an embodiment of the invention. In Fig. 6, the dashed dividing line 600 separates the logical execution flow of a runtime client 610 from the runtime environment with the programming support oriented to the graph of the
fifteen producer 640.
The logical execution flow of the execution entanglement tooth 610 includes blocks 615, 620, 625, and 630, while the execution environment with the graph-oriented support of producer 640 includes blocks 645, 650, 660, and, optionally, 655. A solid line with an arrow represents a direct causal relationship from block 630 to block 660. In contrast, the dashed lines with an arrow illustrate a causal relationship from blocks 615 and 625 in the logical execution flow of the client from execution site 610 to blocks 645 and 650 in the execution environment with the graph-oriented support of the Producer 640, respectively, depending on the embodiment of the invention, this causal relationship may be direct or indirect. For example, Figure 6 illustrates an indirect optional causal relationship through the use of a command register 665 at a discontinuous oval in the direction of
25 execution with a graph-oriented side towards the support of the producer 640 of the dashed line 600. The command register 665 collects the commands resulting from blocks 615 and 625 of the logical execution flow of the execution environment customer 610, and the command register 655 that is consumed, which responds to block 630, by processing block 660. Therefore, the 665 command register allows the commands to be delayed in order to collect the multiples together and process them in batches for optimization purposes. Thus, the command register 665 is similar to the override register 396 of Figure 38, and in reality the override register 396 is included in some embodiments of the invention.
In block 615, the set of one or more producers of interest is determined as the current set of producers of interest and control passes to block 620. In response to the causal relationship between block 615 and the
35 block 645, block 645 shows that the current set of producers of interest is instantiated and that an attempt is made to discover, build, and resolve (if dynamic dependencies are compatible and one or more are discovered in the producer's graph) the graph (s) of the producer for each one, including instances of all instances and the producers thereof, as necessary, based on the producer dependency statements in the runtime client 610. With reference to Figures 3A and 38, the automated graph generation module of producer 340 and 365 are invoked, respectively.
In block 620, it is determined whether there is any cancellation of producer output. If so, the control goes to block 625, otherwise, the control goes to block 630.
Four. Five In block 625, one or more producer exit cancellations are received by a set of one or more producers and control passes to block 630. In response to the causal relationship between block 625 and block 650, block 650 shows that the current set of voided producers are instantiated (if they are not already instantiated in block 645), their outputs are modified, and their monitoring is carried out. A voided producer may have already been instantiated, since it was already discovered to be part of the producer's graph (s) in block 645. However, a voided producer can no longer be discovered in block 645 due to an unsolved dynamic dependency . As such, this voided producer is instantiated and canceled with the expectation that it can be added to the producer's graph (s) when dynamic dependencies are resolved. Also, as indicated above, the override register 396 of Figure 38, if applicable, exists between block 625 and block 650, and is part of command register 665. In addition, the set of voided producers is traced in some
55 embodiments of the invention that support incremental execution. Although in the embodiments of the invention that support the override register 396 / command register 665, the tracking is part of the record, in alternative embodiments of the invention the tracking is performed separately in block 650 with a different mechanism.
In block 630, the axle module of the producer graph is invoked and the control optionally returns to block 615 and / or block 625. In response to the causal relationship between block 630 and block 660, block 660 shows that the graph (s) of the producer has followed and the producers that require the execution are executed based on the monitoring. Various techniques have been discussed previously for the execution of the producers graph producer and are applicable here. With reference to Figures 3A and 38, the execution module of graph 65 of producer 345 and 370 is invoked, respectively. In addition, in embodiments of the invention in which the command register 665 is carried out, the causal relationship includes consume the command register 665 and the embodiment
of processing blocks 645 and 650 before block 660. In addition, in embodiments of the invention that support the possibility of unresolved dependencies, control flows from block 660 to block 655 when necessary.
5 In block 655, an attempt is made to resolve the unresolved dependencies and discover and construct the rest of the producer graph (s), including instantiating all instances and their producers. From block 655, the control flows back to block 660.
Example forms of producer dependency statements
Figures 7A-F illustrates some example forms for producer dependency statements in accordance with the embodiments of the invention. Although Figures 7A-F illustrate embodiments that support argument, field, and sequencing dependencies, it should be understood that different embodiments can support only one or two of the three forms of dependency. In the embodiments of the invention shown in FIGS. 7A-F, a producer dependency declaration is composed of a producer dependency declaration and the optionally explicit producer dependency declaration code. A shortcut from the producer's undeclared dependency is one whose producer's explicit dependency declaration code is used, while a producer's dependency declaration shortcut is one whose producer's non-explicit dependency statement code is used (better said, the execution environment does not use the code
twenty declaration of dependence of the producer and / or implements it on the fly based on the information in the declaration of dependence of the producer).
Different embodiments of the invention may use different syntaxes to declare producer dependencies. For example, different embodiments of the invention may include different syntaxes for use in the producer dependency statements that strongly limit, weakly limit, and / or do not limit the type of producer dependency that can be created. A heavily limited producer dependency is one for which a syntax is used in the producer dependency declaration that substantially limits the type of producer dependency that can be created, a weakly limited producer dependency is one for which a producer is used. syntax in the producer dependency statement that is less limiting
30 The type of producer dependency that can be created, and an unrestricted producer dependency is one for which a syntax is used in the producer dependency statement that does not limit the type of producer dependency that can be created.
By way of example, and not limitation, the embodiments of the invention described below include the
35 following: 1) a syntax for a heavily limited producer dependency for the arguments (Argument Dependency = argument dependency declared in a strongly limited descending manner [static or dynamic, and if dynamic, contingent and / or absorption subscription]), 2 ) a syntax for a producer dependence that is strongly limited for fields (Field dependence = field dependence declared very limited [static or dynamic, and if dynamic, contingent and / or absorption subscription]), 3)
40 a syntax for a very limited producer dependency for sequence dependencies (Sequence dependency = sequence dependency declared very limited in a descending manner [static or dynamic, and if dynamic, contingent and / or adherent subscription]), 4 ) a syntax for a weakly declared producer dependency for argument, field, or sequence of dependencies (Ascending dependency = weakly limited dependency declared ascending field, argument, or
Four. Five sequence [static or dynamic, and if it is dynamic, contingent]), and 5) a syntax for a weakly limited producer dependency (weakly limited dependency = or a) sequence dependency declared in a descending [static or dynamic way, and if it is dynamic, contingent and / or adherent subscription], or b) dependency declared ascendingly [argument, field, or sequence] [static or dynamic, and if it is dynamic, contingent]). It should be understood that, although some embodiments of the invention support a syntax for the
fifty producer dependency statement that distinguishes the declaring dependencies declared in a descending manner, the field dependencies declared in a descending manner, the dependencies declared in ascending order (which can return the dependencies declared in ascending order of argument, field, or sequence), and weakly limited dependencies (which can be returned declared sequence dependencies in descending order, argument dependencies, field, or sequence ascendingly),
55 Alternative embodiments of the invention can adopt a different syntax (for example, they have a syntax that has all the dependencies without restrictions with the determination of the dependency producers who can return any supported dependency (dependencies in descending and ascending manner of argument, field , and sequence), which have a syntax that distinguishes all supported dependencies, that have a syntax that distinguishes declaring and ascending dependencies of argument
60 and field, and that distinguishes a weakly restricted dependency that can only return the sequence dependencies declared in ascending and descending fashion, a syntax that distinguishes the declared dependencies in a descending argument from the field and in the field, and that distinguishes the ascending dependencies declared that Only the declared sequence dependencies can be returned in ascending order, a syntax that distinguishes the dependencies declared in a descending manner of argument, field, and sequence
65 (adherent subscriptions and dependencies declared ascendingly are not supported), etc.).
It should be understood that the syntax of the statement the producer's dependency statement does not necessarily amount to the producer's dependency (for example, the link), created in the producer's graph (for example, ArgumentDependency creates a dependency on the argument, but an UpwardDependency you can create a dependency on the argument, field, or sequence). As such, where appropriate for understanding, a space between
5 a qualifier (for example, argument, field, or sequence) and the word "dependency" is used to refer to the dependency created by the execution environment, while the lack of a space is used to refer to the syntax.
Figure 7A illustrates the pseudo code of a producer dependency declaration for a method using declared direct access dependencies according to an embodiment of the invention, while Figure 7B is a block diagram of exemplary producers according to a embodiment of the invention. Figure 7A shows: 1) a producer dependency declaration 705 that includes ArgumentDependencies 1-N, FieldDependencies 1-H, SequencingDependencies 1-L, UpwardDependencies 1-P, and WeaklyeonstrainedDependencies 1-Q, and 2) an alpha 710 method that has 1-N arguments to the declaration of
fifteen producer dependence 705. In one embodiment of the invention, the arguments of a producer dependency declaration are counted to provide an argument ID for each for tracking purposes. Figure 7B shows a producer 720 having the following dependencies of the descendants: 1) producer 725 for argument ID 1, 2) producer 730 for argument ID N, 3) producers 740-745 for FieldDependencies 1-M, 4) producers 746-747 for SequencingDependencies 1-L, and 5) producer 748-749 for UpwardOependencies 1-P (note, WeaklyConstrainedOependencies The are not shown, but will be described in greater detail with reference to Figure 7G). Therefore, the arguments of the producer dependency declaration 705 correspond to the arguments of the alpha 710 method, and the IDs of the arguments in the producer dependency declaration 705 are tracked with respect to the descendants of the producers They identify.
25 Figure 7e illustrates the pseudo code of a producer dependency declaration of a method that uses a dependency declaration without direct access, and illustrates a block diagram of the exemplary producers according to an embodiment of the invention. Figure 7e shows the producer dependency statement 705 and method alpha 710 of Figure 7A, as well as producers 720 and 725 of Figure 7B. In addition, Figure 7e includes producer dependency declaration code 715 associated with ArgumentDependency 1. During the execution environment, the execution environment accesses and executes producer dependency declaration code 715 that responds to ArgumentDependency 1 of the declaration of producer dependence 705. Execution of the producer dependency declaration code 715 returns producer 725 as the producer's dependence on ArgumentOependency 1. Thus, Figure 7e illustrates embodiments of the invention in which the code
35 Dependency of producer dependency 715 may be part of a method (other than alpha 710), but not part of a producer.
Figure 70 illustrates pseudo code of a producer dependency declaration of a method that uses a non-dependency direct access declared according to an embodiment of the invention, while 7E figure is a block diagram of exemplary producers according to a embodiment of the invention. Figure 70 shows the producer dependency declaration 705 and the alpha 710 method of Figure 7A, while Figure 7E shows producers 720 and 725 of Figure 7B. In addition, Figure 70 includes: 1) a producer dependency declaration 750, and 2) a beta 755 method including the producer dependency declaration code 760. Figure 7D also shows that the dependence of argument 1 of the producer dependency statement 705 identifies a producer (shown in Figure 7E as producer 765) based on the beta 755 method that will return the dependency for dependency argument 1. During the execution environment, the execution environment, which responds to the dependency of argument 1 of a producer dependency declaration 705, executes producer 765 to return from identification that the producer's dependence on dependency argument 1 is producer 725 . As such, producer 765 is referred to as a dependency determination producer (its output is a dependency of the producer - and therefore, it is returned using a class / example that is controlled for a special treatment (manipulation of the graph (s) ) of the producer) by the execution environment with the graph of the producer oriented to the programming support), while the producer 725 is referred to as a standard producer (its output, where appropriate, It is not directly processed by the executing agency to manipulate a graph of the producer, but its output, where appropriate, can be consumed
55 by an ascending producer (either a producer of the dependency determination or another standard producer) and / or as provided by the output of the producer's graph (If the standard producer is a producer of interest, and therefore a node root).
Thus, Figures 7D-E illustrate embodiments of the invention in which those producer declaration code 715 is part of another producer, referred to as a dependency determination producer. While in Figures 70-E the object-oriented source code includes the explicit producer dependency declaration code in the methods from which the determination of the dependency producers is created in the execution environment through the environment of execution of declared non-direct access dependencies, alternative embodiments of the invention, additionally or instead of applying the runtime environment to include the generic dependency producer declaration code that invokes when one or more generic dependency determination producers on the fly for declared direct access dependencies.
Also, while Figures 7C-E illustrate with reference to ArgumentOependencies, the illustrated techniques are applicable to the other types of dependencies declared in descending order. In addition, Figures 7F-G illustrate the use of a dependency determination producer for an UpwardDependency and a WeaklyConstrainedOependency.
Fig. 7F is a block diagram of an example dependency by using an UpwardOependency with a dependency determination producer according to an embodiment of the invention. Figure 7F shows the producer 720 having dependence of sequencing producer to a producer determining dependency 772. The producer of the dependency determination may return an argument, field, or dependency of the sequencing declared in ascending form of nosuscription, of the ascending producer 748 in producer 720. In addition, said dependency determination producer can apply a dynamic dependency (for example, a contingent dependency that selects between the previous ones depending on the data values, including between different argument values, as described hereinafter). While some embodiments of the invention support all of these possibilities,
fifteen Alternative embodiments of the invention support only a subset (for example, only sequencing dependencies declared in an ascending non-subscription manner).
Figure 7G is a block diagram of possible example dependencies by using a WeaklyConstrainedDependency with a dependency determination producer according to an embodiment of the invention. Figure 7G shows producer 720 having a sequencer dependency producer to a dependency determination producer 775. In some embodiments of the invention, the dependency determination producer may return any of the following: 1) a sequencing dependency declared downwardly from non-subscription in a descending producer 780, 2) a sequencing dependency, field or argument declared upstream of non-subscription a parent producer 785 in the
25 Producer 720, and 3) an adherent subscription (described later in this document). In addition, said dependency determination producer can apply a dynamic dependency (for example, a contingent dependency that selects between the previous ones depending on the data values, including between different argument ones, as described hereinafter). While some embodiments of the invention support all of these possibilities, alternative embodiments of the invention support only a subset (eg, only sequencing dependencies declared upstream of non-subscription).
As indicated above, sequencing dependencies can be used for a variety of purposes, including ensuring the order of execution among producers that modify the data in a way that the execution environment is not aware of and the producers that consume that data. (a producer
35 Descendants can write their outputs in a way that requires the parent producer's method to include code to access that output (for example, a method that impacts the environment by affecting an output that is not the regular producer's output and, as such, that it is not detected by the execution environment - said method that establishes a global variable, which defines a field in an instance that is not the output of the producer, which affects an external data source, etc.)), etc.
Different embodiments may support one or more forms for the declaration of producer dependencies with respect to the producers of goods. Specifically, in some embodiments of the invention, producers who read a field must be dependent on the producer of property obtained, while the producer of property obtained should depend on any of the producers who establish the field in which the producer is responsible. property method get. A manipulation technique of this situation is provided that can be used in embodiments of the invention that support sequencing producer dependencies, for a method of obtaining property, a producer dependency declaration that creates sequence producer dependencies in each method. which establishes the field for which the property method to obtain is responsible (for example, with respect to Figure 7G, where producer 780 is a producer that establishes a field and producer 720 is the property producer to obtain responsibility for that field, dependency determination producer 775 would be written to return a sequencing dependency declared downwardly from producer 720 in the producer 780). A second technique for handling this situation that can be used in the embodiments of the invention that support both sequencing producer dependencies and ascending producer dependencies is included in the
55 declaration / Code of producer dependency for any method that establishes a field, a sequence producer dependency declared in ascending order (for example, using an UpwardOependency or WeaklyConstrainedOependency) in the method to get responsible for that field (for example, with with respect to Figure 7G, where producer 720 is a producer that establishes a field and producer 785 is the property producer to be responsible for that field, Dependency determination producer 775 would be written to return a sequencing dependency of upstream of parent producer 785 in producer 720). This second technique allows the programmer of the method that sets the field to be responsible for providing a producer dependency to the appropriate get method, instead of requiring the programmer to go to the get method and modify his producer dependency declaration / declaration code .
When sequencing dependencies are used, when a given producer is based on a given variable, that variable should not be modified by more than one of the producer-descendant producers in a given execution of the producer graph (s) (It should be noted that Through the contingent dependencies (described later in this document), the different descending producers can modify that variable during different executions of the graph (s) of the current producer). For example, a get property producer should
5 depend only on a producer of another type that establishes the one presented for which the property producer get is responsible in a given execution of the graph (s) of the current producer.
It should be understood that different embodiments of the invention may apply one or more of the embodiments of the invention shown in Figures 7A -F. For example, one embodiment of the invention supports declared dependencies of direct access and without direct access, both using dependency determination producers, in particular, in this embodiment of the invention: 1) The object-oriented source code includes explicit producer dependency declaration code in the methods from which those dependency determination producers are from an instance in the execution environment by the execution environment by declared dependencies of no shortcut, 2) the execution environment includes the code of
fifteen generic producer dependency statement that invokes it as one or more generic dependency determination producers on the fly for declared direct access, contingent dependencies (described later in this document), and 3) the execution environment includes support for Directly link declared direct access, dependencies of non-contingent producers (described later in this document).
As another example, one embodiment of the invention supports dependencies of producers declared of non-direct access and direct access using dependency determination producers; specifically, in this embodiment of the invention: 1) the object-oriented source code includes explicit producer dependency declaration code in the methods from which the dependency determination producer is instantiated into the execution environment by the runtime environment for declared dependencies
25 non-direct access, and 2) the runtime environment includes the generic dependency determination code that invokes it as one or more generic dependency determination producers on the fly for direct access declaration dependencies (regardless of type). This last embodiment allows the coherent treatment of the producers' dependencies, and therefore, simplifies the execution environment.
In addition, while in one embodiment of the invention, the producer dependency declaration of a method is located just above said method in the object-oriented source code, in alternative embodiments of the invention it is found elsewhere (for example , producer dependency statements for all methods for a class are grouped together within the class, Producer dependency statements of all methods in all classes are grouped into a separate data table,
35 etc.) In addition, while in an embodiment of the invention the producer dependency declaration code is separated from the producer dependency declarations, in alternative embodiments of the invention they are combined (for example, the dependency declaration code of the producer is within the parentheses of the producer dependency statement, the producer dependency declaration code is placed directly below the producer dependency declaration and is treated by the execution environment as a single unit, etc.)
Figures 7H-1 illustrate the distinction between different subgraphs that may exist in a producer graph due to dependency determination producers. Figure 7H illustrates graphs of example producers of the standard producers according to an embodiment of the invention. Specifically, Figure 7H shows a producer graph with root node S 1, a producer graph with root node SS, and a producer graph with root node S 11. The standard producer S 1 has as standard producers descendants S2, S3 and S4; standard producers S2 and S3 have as standard producers descendants S7 and S8; the standard producer SS has as standard producers descendants S4 and S6; and the standard producer S11 has as standard producers descendants S6 and S10. The example producer graphs of Figure 7H can be discovered, constructed, and rotated with any number of producer dependencies and dependency determination producers. Figure 71 illustrates an example of producer dependencies and dependency determination producers to discover, solve, and construct the graph of the producer in Figure 7H. Specifically, Figure 71 shows the graphs of Figure 7H as subgraphs of a larger set of producer graphs. In other words, the producer graphs of Figure 71 include the graphs of Figure 7H (hereinafter, the "objective subgraphs" and illustrated with 55 solid arrow lines and solid ovals) and graphs that aid in the discovery, resolution , and creation of the target subgraphs (referred to as "decision subgraphs and illustrated using dashed arrow lines and dashed ovals). The decision subgraphs in Figure 7H include dependency determination producers (OOPs) 1-11 and standard S9-10 producers. In Figure 7H, S1 is presented as dependent on PDOs 1-3, which, respectively, return dependencies of producers declared downwardly from S1 S2, S3 and S4, S4 is shown as dependent on OOP4, which returns a dependency on the producer deClayed upwardly SS on S4; SS is shown as dependent on ODP5, which returns a producer dependency declared downwardly SS in S6; S3 is shown as dependent on OOP6, which in turn depends on DOP8, which returns a producer dependency declared downwardly from DOP6 at S9 and S10, which causes ODP6 to return a dependency declared downwardly S3 on S7; S3 is shown as 65 dependent on DDP7, which returns a producer dependency declared downwardly S3 on S8, S8 is shown as dependent on DOP9, which returns an adherent subscription for which S6 is a producer
of activation and S11 is the parent created (therefore, the producer dependency of S11 on S6); S2 is shown as dependent on DDP10, which returns a producer dependency collection declared downwardly S2 on S7 and S8, and S11 is shown as dependent on DOP 11, which returns a producer dependency declared downwardly S11 on S10. It should be understood that a standard producer can be
5 both part of an objective subgraph and a decision symbol (for example, see S10). It is worth noting that the objective subgraphs are the data that circulate in the sense that the data flows from one producer to another standard producer of the graph.
Programming and sample execution framework
Figure 8A is a block diagram illustrating a first example framework in which applications are provided to end users in accordance with an embodiment of the invention. The frame shown in Figure 8A includes three basic divisions. The first division includes the creation of the execution environment with the support of the graph-oriented programming of producer 810. This first division is carried out by the
fifteen Programmers with very advanced programming knowledge. When working in this division, programmers are known as execution programmers. When creating a runtime environment with producer-oriented programming support, the runtime programmers include support for product graphs, as well as support for the execution of the different types of commands used in the product code. Transfiguration, instance code, and data preparation code.
The second division includes the creation of object-oriented application source code 820 to be executed by the runtime environment. The object-oriented application source code 820 includes two basic divisions: 1) class definitions that include business logic expressed in methods with producer dependency declarations 822 (this may optionally include other functionalities, such as an interface
25 graphical user -in which case, the graphical user interface is written using producers and producer dependency declarations), and 2) class definitions that include the customer code expressed in methods 824, including the instance code (class , instances, and producer (s) of interest, to cause the generation of the graph (S) of producers) 824A, data preparation code 8248 (for example, system commands, such as adjustment commands that trigger the main of the production outputs), global execution commands 824C to cause the execution of the producer graph (s) (for example, execute and obtain commands), and any necessary graphical user interface 824d (not included in 822). Producer dependency statements are used to define the bonds between producers during the definition of classes that include business logic, before subsequent instances of those classes are created. The 820 object-oriented source code is hard coded class, instance and the methods that are compiled and executed.
35 While in one embodiment of the invention a global execution command is applied, the execution of which makes the attempt to execute all producer graph (s) currently in the structure of producer graph (s) 380, alternative embodiments of the invention or, alternatively, they also apply a graph specific execution commands that require the identification of a given graph of the current producer graph (s) to be executed. In addition, the global execution command may be explicit (for example, adjustment, adjustment, adjustment, execute, obtain, obtain) or implicit depending on the implementation of the execution environment. For example, an implicit global execution command could be: 1) caused by the first command obtained from a producer of interest (for example, adjustment, adjustment, adjustment, obtain (implicit execution), obtain), 2) caused by each manipulation of data (adjustment (implicit execution), adjustment (implicit execution), adjustment (implicit execution), obtain,
Four. Five get), etc.
The second division is carried out again by programmers with advanced programming knowledge, as well as an understanding of the application's business objectives. When working in this division, programmers are known as application programmers. As part of this, if the application requires a graphical user interface, application programmers also design and code the graphical user interface for the specific application, and therefore, they are also known as application designers.
The third division includes the use of application programs that run during the execution environment. The third division is carried out by end users who do not need to have programming skills. He
55 Application program can be distributed in a variety of ways (for example, as the source code; a transformation of source code, such as byte code; as binary, etc.) In addition, the application program can be distributed for use independent 830 (in which case, the complete application program (and the execution environment if not already present) is provided to a computer system) and / or use of the client / server. In one embodiment of the invention, a client / server distribution includes the dissemination of class definitions that include business logic expressed in methods with producer dependency statements 822 (and the execution environment if not already present) to the use of the 832 server and the class definitions that include the client code expressed in the 824 methods (and the execution environment if it is not already present) for the use of the 834 client, where the use of the 834 client in a computer system causes communication with the use of the 832 server in a server system.
Figure 8A also shows an optional configurable interactive producer output design graphic user interface module B40 that is provided for independent use 830 and client use 834. The object-oriented source code 820 would be directed by the execution environment to generate the producer graph (s), and the configurable interactive producer output graphic design user interface module 840 allows to graphically display the outputs of and interact with the Graphs of the producer. Specifically, the user interface module
5 840 configurable interactive producer output design graphic includes: 1) a configuration and the graphical user interface module of assigned 844 to allow the design and assigned configuration of the selected producer outputs (for example, the areas of the screen to be used, how the data will be displayed , etc.), and 2) a graphical user interface and representation of the 846 interaction to make the setup configured and to allow the predominance of producer outputs (resulting in the updating of producer graphs through a global execution command). It should be understood that the graphical user interface module of configurable interactive producer output design 840 may or may not be created by the same entity that writes execution interface 810.
Figure 88 is a block diagram illustrating a second example of a framework in which applications are
fifteen they provide to end users according to an embodiment of the invention. Figure 88 is identical to Figure BA, with the following exceptions: 1) independent use 830 is not present, 2) object-oriented source code 820 is provided for the use of server 832, while client code 824 is not intended for customer use 834, 3) the interface module Graphical user of configurable interactive producer output design 840 is provided for the use of the B32 server and not the use of the 834 client, and 4) a configurable interactive producer output design client interface 885 is provided for the use of client 834. The configurable interactive producer output design client interface 885 is used to connect to the interface module of Graphical user of configurable interactive producer output design B40.
Regardless of the framework used, in one embodiment of the invention, the programming framework oriented to the
25 Producer graph offers the possibility of interface with unwritten programs with producer dependency statements. This ability to interact with programs that are not written with producer dependency statements includes: 1) a calling party (for example, an unwritten graphical user interface according to producer-oriented programming), and 2) a called party (such as an unwritten external data source according to the producer-oriented programming). The calling party can, through customer code, issue programming commands aimed at graph producers. The called party is implemented as part of the producers that wrap the called party (referred to as "wrapped producers"). Executing the called party (such as reading the data from a data source or subscribing to the data changes in an external data source) can in turn trigger instance modifications. These changes can occur by calling the established ownership methods in the producers code
35 wrapped. Property producers obtain (collectors) are required to have dependencies on these wrapped producers, in order to ensure that the instance modifications caused by changes occurring in an external data source are properly propagated through the graph of producer. As described above, the different embodiments may support one or more forms for the declaration of producer dependencies with respect to property producers. For example, in some embodiments of the invention that support sequencing producer dependencies, SequencingDependencies can be used to declare sequencing producer dependencies declared in a downward non-subscription manner in the wrapped producers. As another example, in some embodiments of the invention that support sequencing producer dependencies and upstream non-subscription producer dependencies, UpwardDependencies and / or WeaklyConstrainedDependencies can be
Four. Five placed in the producer dependency declaration of the producers involved to create dependencies of sequencing producers declared in an ascending manner of non-subscription for the property producers.
Figures 8C-F illustrate example images and the use of the graphical user interface module output design of the configurable interactive producer 840 according to an embodiment of the invention. While the embodiments of the invention will be described with reference to the graphical user interface module of the configurable interactive producer output 840 provided for configuration, assignment, and interaction with the selected outputs of the graph (s) of Current producers in the form of a spreadsheet, alternative embodiments of the invention can be implemented to provide additional support or alternatively for
55 Another way. In addition, although exemplary embodiments of the configuration, assignment, and interaction in the form of a spreadsheet are described in accordance with some embodiments, other embodiments of the invention may perform these operations in a different way, with a different interface. , yfo with a different screen layout. In addition, the spreadsheet can support any of the known functionalities associated with spreadsheets (for example, color selection, font selection, line bar graphs, pivot tables, save designs, load designs, etc.)
Figures 8C-D illustrate exemplary images and use of the selection of free cells according to an embodiment of the invention, while Figures 8E-F illustrate exemplary images and use of table creation according to an embodiment of the invention. Each of Figures 8C-F includes a menu bar 850 65 along the top of the screen, a list of the classes (with their property methods obtained) 852 of the producers in the graph of the current producer and its outputs on the left side of the screen, and a viewfinder of
configuration and assignment 854 filling the rest of the screen with a design as a spreadsheet. In addition, Figures 8C-F also show the following list of examples of dases with their property methods obtained in list 852: 1) the PERSON class, 2) the property methods obtained from the person of the class, including NAME ( for example, chain) and SURNAME (for example, chain), G¡;: NERO (for example, chain), ADDRESS
5 PERSONAL (instance of the ADDRESS class), PROFESSIONAL ADDRESS (instance of the ADDRESS class), BIRTH DATE (for example, date) and AGE (for example, whole), 3) the ADDRESS class, and 4) ownership methods get from the ADDRESS class including CITY (for example, chain), STATE (for example, chain), ZIP CODE (for example, chain). Therefore, the current producer chart includes the producers of the PERSON and DIRECTION classes, as well as the producers whose outputs are of the PERSON AND DIRECTOR classes. It is also noteworthy that the property method obtain AGE calculates an age based on the output of the property method obtain BIRTH DATE, as such, a producer of an instance of the property method obtain AGE will depend on a producer of an instance of the method of the property get DATE OF BIRTH.
fifteen Figures 8C-D show the following free text entered in the consecutive cells of the first column of the viewer: CLIENT, NAME, LAST NAME, DATE OF BIRTH, AND AGE, while Figures 8E-F show the following: 1) free text entered in the first row of the viewer - CUSTOMER LIST, AND 2) free text entered in the consecutive cells of the second row of the viewer NAME, LAST NAME, DATE OF BIRTH AND AGE.
Figure 8C illustrates a screen and example use of cell-free selection with the graphical user interface module of the configurable interactive producer output 840 according to an embodiment of the invention. Figure 8C shows a set of mappings 856 of the PERSON data and a selection of the property methods obtained from the PERSON class to the different viewer cells. Specifically, the PERSON class is assigned to the cell to the right of the CLIENT free text. As part of this action, some embodiments of the invention will instruct the user to select one of a series of supported filters (show as filter selection 858) (for example, open drop-down list, form scroll arrows, etc.) These Filters allow the selection of one or more instance keys of the producers of the selected class, or one or more instance keys of the producers whose output class is the selected class. While some embodiments of the invention support a series of filters, other embodiments of the invention predetermine one (and allow the user to choose whether to select a different one) or support only one and do not need to select filter 858. Assignments 856 also show that the property methods obtain NAME, LAST NAME, DATE OF BIRTH, and AGE of the PERSON class are, respectively, assigned to cells adjacent to cells with corresponding free text. Such assignment can be done with any number of techniques either.
35 known, including drag and drop, when writing in a GUI field, etc.
Figure 80 illustrates another screen and the example use of cell-free selection with the graphical user interface module of the output of the configurable interactive producer 840 according to an embodiment of the invention. Figure 8D shows that the cell to which the PERSON class has been assigned to allow for example 854 selection. Specifically, based on the filter that is used for this cell, the user has the opportunity to select an instance of the PERSON class from a list that induces the instance key (s) of the producers of the person PERSON, and the instance records of the producers that produce the PERSON class. The selection of an instance of the PERSON class (or the existence of a single instance) results in the automatic population of the cells, to which the property methods obtained from the PERSON class were
Four. Five assigned, with the outputs of the property methods get corresponding from that instance. This settlement of the table based on the instances of the PERSON class is labeled 858. In the example of Figure 80, the cells in which the property methods obtain NAME, LAST NAME, DATE OF BIRTH, AND AGE of the class PERSON were assigned, respectively, to be populated with JOHN, SMITH, 7/20/1990, and 16.
Figure 80 also shows that the viewer cells to which the property methods obtained have been assigned can be overridden. As an example, Figure 80 shows that if the cell to which the property method is assigned to obtain BIRTH DATE is replaced, then it will cause the producer's predominance to predominate, whose output is currently populating said cell, the invocation of a global execution command
55 (which results in a re-execution of the producer, whose output is currently populating the cell to which the property method is assigned to obtain AGE), and any necessary screen updates.
Figure 8E shows an example of a screen and the use of creating the table with the graphical user interface module of the configurable interactive producer output 840 according to an embodiment of the invention. Figure 8E shows a zone and the orientation operation of selection 864 is performed to identify a table of three vertical rows directly in the cells with the free text NAME, LAST NAME, DATE OF BIRTH AND AGE (illustrated with a thick dashed line around to these cells). Different embodiments of the invention can support the user to perform this operation in many ways, including: 1) selection of an area with an input device such as a mouse, and 2) selection between a vertical, horizontal or dynamic table 65 with an interiaz as a pop-up menu - assuming that multiple orientations are supported). Figure 8E also shows a set of property method allocations 866 get selected from the
PERSON class to different viewer cells. Specifically, the 866 assignments show that property methods obtain NAME, LAST NAME, DATE OF BIRTH, and AGE of the PERSON class are, respectively, assigned to the cells directly below the cells with corresponding free text.
5 Figure 8F illustrates another screen and example of creating the table with the graphical user interface module of the configurable interactive producer output 840 according to an embodiment of the invention. Assignments 866 results in the automatic population of the columns of the table, to which the property methods obtained from the PERSON class were assigned, with the outputs of the property methods obtained corresponding to the instances of that class This settlement of the table based on the instances of the
10 PERSON class is labeled 868. In the example in Figure 8D, the columns to which the property methods obtain NAME, LAST NAME, DATE OF BIRTH, AND AGE of the PERSON class were assigned are filled in with the following rows of data: 1 ) STEVE, COLLlNS, 7f20f1990, and 16, 2) JENNIFER, ADAMS, 7f20f1990, and 16, Y 3) JOHN, SMITH, 7f20 / 1985, and 21.
fifteen As in Figure 80, Figure 8F shows that the viewer cells to which property methods obtained have been assigned can be overridden. By way of example, Figure 8F shows that if the cell in the second row of the column to which the property method is assigned to obtain BIRTH DATE is replaced, then it will make the predominance of the producer's exit, whose output is currently filling in that cell, invoke a global execution command (which would result in an additional execution of the producer, whose output is
twenty currently populating the cell to which the ownership method get AGE is assigned), and any necessary screen updates.
Figures 8C-F illustrate example screens generated by the configuration and assignment of the graphical user interface module 842. The screens generated by the rendering and the graphical user interface module
25 interactive 846 are the same, with the exception that the list of dases (with their property methods get) 852 the configuration and the assigned viewer 854 are replaced by a representation and interactive viewer (not shown) that contains the same image as the configuration and assignment viewer 854 shown (the difference being that the assignment function is no longer available).
30 Examples of execution scheme distribution schemes
Figures 9A-C illustrate several schemes for the distribution of an execution program with the support of the producer-oriented programming program. It should be understood that these distribution schemes are exemplary, and therefore, other schemes are within the scope of the invention.
35 Figure 9A is a block diagram illustrating a first scheme for the distribution of an execution system with the programming support oriented to the producer's graph according to an embodiment of the invention. In Figure 9A, the object-oriented source code 905 (which would include producer dependency statements) is shown at the top of an execution environment with programming support
40 Graphically oriented producer 910, which is at the top of an execution environment with class loading, instantiation of dynamic classes, invocation of the single dynamic method, and introspection of class / method 915, which is at the top of an operating system 920. In Figure 9A. execution system 910 works with the execution environment 915. Although any number of mechanisms can be used to allow the execution environment 910 to work with the execution environment 915, an example is described by way of example.
Four. Five Metadata installation A metadata installation allows additional information to be added to the source code, whose information is used by development tools. For example, the installation of metadata for Java specification defines an API for the annotation fields, the methods and classes of which have particular attributes that indicate that they should be treated in a special way by the development tools. implementation tools, or in libraries in a runtime environment (Java Specification Request 175). In
fifty In this example, a programmer who programs the object-oriented source code 905 would add annotations to the methods in the form of producer dependency statements. Since these annotations are delivered by execution entail 915 to execution endeavor 910, execution environment 910 dictates the syntax of producer dependency statements. In Figure 9A, the execution times of 910 and 915 can be developed and / or distributed by different organizations.
Figure 9B is a block diagram illustrating a second scheme for the distribution of an execution environment with the programming support oriented to the producer's graph according to an embodiment of the invention. In Figure 9B, the object-oriented source code 925 (which would include producer dependency statements) is shown at the top of a runtime environment (with the burden of d, creating 60 instances of dynamic classes, dynamic unique method invocation, and class / method introspection, as well as the graphically oriented programming support of producer 930, which is at the top of an operating system
935 Compared to Figure 9A, the execution environment 910 and 915 have been combined into a single execution environment 930. As a result of this combination, the execution environment 930 dictates the syntax of the producer dependency statements. Therefore, a code programming programmer
65 Object-oriented source 925 add the producer dependency statements in the necessary syntax.
Figure 9C is a block diagram illustrating a third scheme of the distribution of an execution environment with the programming support oriented to the producer's graph according to an embodiment of the invention. In Figure 9C, the object-oriented source code 940 (which would include producer dependency statements) is shown at the top of an operating system execution environment (with the load of
5 classes, instantiation of dynamic classes, dynamic single method invocation, and class / method introspection, as well as producer-oriented graphical programming support) 945. Compared to Figure 98, the 920 execution environment and The 935 operating system has been combined into a single entity. As a result of this combination, the operating system in the 945 runtime environment dictates the syntax of producer dependency statements. Therefore, an object-oriented source code programming programmer 940 added producer dependency statements in the necessary syntax.
Although the embodiments in which the execution environment has the load of classes, creation of instances of dynamic classes, the invocation of dynamic single method, and introspection, the class / method, alternative embodiments may include more or less features are described ( for example, cloning instances,
fifteen dynamic proxies, conversions of primitive types, etc.)
Sample Advantages
In one embodiment of the invention, the dependencies of the producers are declared for the methods as a way of specifying the method invocation sequence with the corresponding instances (in the appropriate cases they include the cases to use as arguments, the instances to be used by the instance methods, and the meta instances of the class used by the d) methods without using the manual invocation sequence code. Indeed, the work of generating part or all of the manual invocation of the sequence code is replaced by: 1) the work done by the programmer of the application to write the
25 producer dependency statements, and 2) the work done by the execution environment to discover and build the producer graph (s) and execute the producers of the producer graph (s). In other words, the logic that was previously contained in the code of the manual invocation sequence is detectable by the axCuCion environment during the axisCuCion environment based on the producer dependency statements. Therefore, producer dependency statements inform the runtime environment what methods of what instances with which the arguments run, and when for synchronization purposes. Although the effort to write the execution environment is relatively large, it only needs to be written once it can be used to run any of the object-oriented applications written for the execution environment, instead, for a typical application, the effort of Writing producer dependency statements is relatively low compared to manual writing of the invocation sequencing code.
Programming error reduction
Producer graph-oriented programming generally reduces the costs associated with debugging and / or optimizing the performance of the manual invocation sequencing code. This is true for at least the reason that the infrastructure of an application program is conceptually a set of non-formalized graphs of object transformation methods (the output of a method associated with an object is the input to another. and so on) that operates on specific inputs. Producer dependency statements and the execution environment with producer-oriented programming support formalize these graphs in the form of producer graphs. Therefore, for each opportunity for the data to change, the application programmer does not have to consider its effect and write the manual invocation of sequence code to cause the appropriate transformation methods of the appropriate instances to be invoked. in the appropriate order, with the corresponding entries. In other words. For each opportunity when the data changes, it is not necessary for an application programmer to consider that the graphs are affected, as well as what methods of transforming instances within the graphs are affected. On the contrary, the automated producer graph generation module discovers and builds the producer graphs and the producer graph execution module reruns the producer graphs, as necessary to reflect the changes in the data. This automation helps application programmers avoid errors such as: 1) invoke the appropriate transformation methods of the appropriate instances in the wrong order, 2) forget about including commands to make one or more necessary methods of transforming the instances from
55 a graph is invoked in response to some data that is changed, and 3) include commands to make unnecessary transformation methods of instances to be invoked that respond to some data that is changed (for example, including commands to invoke transformation methods of instances that are not part of a graph affected by the change in the data; including commands to invoke methods of transforming instances that are part of a graph affected by the change in the data, but are not affected in themselves, etc.).
Synchronization
As previously described, changing producer outputs during execution allows synchronization. Thus, in terms of comparison with the observer pattern, producer dependency declarations notify an execution environment with producer-oriented programming support to producers.
dependencies, and the execution environment determines which producers and when to call back.
Ability to fully explain any result
5 In one embodiment of the invention, a periodization / display module (not shown) is included as part of the execution environment. The periodization / visualization module provides an interactive user graphic that, through the interaction of an end user, allows the producer graph to be per- formed (walking through a producer graph from the root node) to see the outputs of the different producers of the graph of producers. This allows an end user to see the different results that contributed to the exit of the producer of interest,
10 including data values and dependencies (returned by the producers of the dependency determination). In addition, in one embodiment of the invention, this periodization / display module provides the ability for the end user to view the code within the methods of the producers, the values of the cases of the producers, and the content of the producer classes.
fifteen Thus, the drilling / viewing module offers a variety of subsequent transformation activities, including debugging, explanation of outputs, etc.
Practical application / Technical effect! Exemplary industrial applicability
twenty There are a variety of practical example applications of the different aspects and embodiments of the invention. For example, the runtime environment, as part of the application programs that it runs, causes the retrieval of information from a machine storage medium (for example, access to object-oriented source code, including declarations of dependence on producers), the storage of information to a storage medium of the machine (for example, the storage of the structures of
25 data such as the structure of producer graph (s), etc.), the operation of hardware processing resources, the supply of outputs of the producer (s) of interest (for example, through a graphic user interface, storage in machine storage media, transmission, etc.), etc. In a sense, the pre-processing activity includes the writing of this type of application program and! Or the provision of data (diChOS data can represent any number of physical and practical elements, such as financial values, values
30 goographs, meteorological values, actuarial values, statistical values, physical measurements, machine state values, etc.), while post-processing activity includes the provision of the results (these results can represent any number of physical elements and / or practical, such as financial analysis, geographic analysis, meteorological analysis, actuarial analysis, statistical analysis, industrial measurements, machine control information, etc. As a specific example, the post-processing activity can be
35 provided by: 1) the producer graph viewer module 1062 of Figure 10 to graphically show a representation of the current producer graph (s) generated by the runtime environment, and 2) the graphical user interface module of producer output design configurable interactive 840 (see also, Graphical user interface module of configurable interactive producer output design 1085 of Figure 10) to graphically display the outputs of and interact with the graphs of the producers.
40 As another example, the application program with the producer dependency declarations itself, when executed through the execution environment, represents the physical / practical elements and causes the operations described above. As a specific example, these producer dependency declarations cause data structures to be formed in the storage media of the machine that respond to its execution
Four. Five for the execution environment. In addition, producer dependency statements are stored and retrieved from the machine's storage media along with the application program. In addition, these producer dependency statements represent the relationships between the producers, while the producers represent the operations to be carried out (methods) and institutions. Instances in object-oriented programming can be used to represent physical and practical elements, while
fifty Producers represent the operations carried out in these representations.
By way of another example, a set of one or more application and execution programs for the transverse application of risk management software assets that includes currency exchange, equity, interest rate, credit, inflation, raw materials and products composed of cross assets. These products range from money
55 in cash and flat vanilla physical products to exotic and complex derivative products. It also includes a set of mathematical models for these products, and their corresponding market data, payment and routines for generating accounting entries and their associated observables, calibration models and their associated raw inputs.
60 By way of another example, a set of one or more application programs and execution environment can implement a word processor, a spreadsheet, a communication software! email, photo viewing software, virus detection software, a media player, a database server, a game, an industrial application, a computer-aided design tool application and / or an operating system . Of course, application programs can be implemented to perform a variety of
65 other tasks.
Sample implementations
By way of illustration, exemplary embodiments of the invention that support dependencies, dynamic dependencies (including contingent dependencies and subscription dependencies), producers will be described.
5 Explicit dependency determination for declared direct access dependencies and for declared non-direct access dependencies, on-the-spot dependency stop producers for declared direct access dependencies, class keys, instance keys, method keys, override commands / reverse producers override (which are the types of set commands), and global execution commands. In addition, the example embodiments optionally support an interactive graphical visualizer module of the producer and incremental execution. Of course, alternative embodiments of the invention may apply more, less, and / or different features.
Figure 10 is a block diagram of an exemplary embodiment according to an embodiment of the invention. In Figure 10, the dashed dividing line 1000 separates an execution environment client 1002 from an execution environment with the graphical oriented producer support 1004.
The logical execution flow of the client at run 1002 includes blocks 1010, 1020, 1025, 1030 and 1035, and the execution environment with the producer-oriented programming support 1004 includes, respectively, corresponding blocks, 1095, 1098 , 1040, 1045 and 1070, while a solid arrow line represents a direct causal relationship from block 1035 of the logical execution flow of the execution environment client 1002 with block 1070 of the execution environment with the graphically oriented support of producer 1004, arrow lines of points show a causal relationship from blocks 1010, 1020, 1025 and 1030 of the client in execution environment 1002 of blocks 1095, 1098, 1040 And 1045 of the execution environment with the graphically oriented support of producer 1004. Depending on the embodiment of the invention, these latter relationships
25 Causes can be direct or indirect. For example, similar to Figure 6, an indirect optional causal relationship through the use of a command register (not shown) and / or override register 1047 can be used. Other blocks 1095 and 1098 are discontinuous because they can optionally be part of a different block depending on the embodiment of the invention (for example, block 1095 can be part of block 1098; block 1098 can be part of block 1040; blocks 1095 and 1098 can be part of block 1040). Similarly, block 1045 is discontinuous, since it may optionally be part of a different block depending on the embodiment of the invention (for example, block 1045 may be part of block 1070).
In Figure 10, the execution environment 1002 includes the class definitions that include the business logic 1010 with data 1012, the methods 1014, the declarations of the dependency producers 1016, and optionally the
35 Class 1090 keys. Class 1010 definitions are classes in an object-oriented programming language, and therefore data definitions 1012 and methods 1014 are included. In addition, these class 1010 definitions include statements of producer dependence 1016 for method 1014 as previously described. In addition, in one embodiment of the invention, each class has a class code 1090 for tracking purposes.
The new class 1095 module of the 1004 runtime environment loads and does the introspection about the class 1010 definitions (for example, that responds to the commands of the new class). This loading and introspection can be done using any number of known or known techniques developed, including those of loading classes selectively for optimization purposes. Class loading by the module
Four. Five new class 1095 is illustrated in classes 1054 of runtime environment 1004. As part of the loading and introspection of classes 1054, new class module 1095 also loads and inspects producer dependency statements 1016, as illustrated by the methods and declarations of dependence of producers 1056 in classes 1054. The new class module 1095 also maintains a tracking structure of the class 1092 that is used to track the classes with the class keys. Thus, the class tracking structure 1092 maintains a correspondence between the class keys and references in the classes 1054. In addition, the new class module 1095 also maintains a method tracking structure 1058 that is used for the tracking methods using The method keys. Therefore, the tracking system structure 1058 maintains a correspondence between the method keys and the references to the methods, as well as information on the producer dependency statements.
The runtime environment client 1002 also includes the instance commands with the instance keys 1020. The new instance module 1098 of the runtime environment 1004 creates an instance of the instances designated by the instance commands with the example keys 1020 ( for example, to respond to the new instance commands). This instantiation can be done using any number of developed techniques also known or known, including those instantiated instances of selective sources for optimization purposes. As part of this instantiation, the new instance module 1098 accesses the tracking structure of class 1092 through a class key to access the appropriate class of classes 1054. The instance of instances by the new instance module 1098 is illustrated with instances 1052 of the runtime environment 1004. The new instance module 1095 also maintains an instance tracking structure 65 1065 that is used for tracking instances with instance keys Thus, the instance tracking structure 1065 maintains a correspondence between the instance keys and references in the
instances 1052. As indicated above, the new class module 1095 can be part of the new instance module 1098 in which classes 1054 can be instantiated in response to instance instantiation commands 1020, as opposed to separating new class commands .
5 The runtime environment client 1002 also includes instance producer commands with the production keys 1025. The automated producer graph generation module 1040 of the runtime environment 1004 creates a producer instance designated by the producer instance commands with 1025 producer keys (for example, responding to new producer commands that designate the current set of producers of interest). In addition, the 1040 automated producer graph generation module also discovers, builds, and, optionally, resolves the producer graph (s) in response to the current series of producers of interest, as described above. In one embodiment of the invention, a producer key is composed of a class key, instance key, and method key. As part of this instance of the producers, the automated generator graph generation module 1040: 1) accesses the tracking structure of class 1092 with the class key to access the appropriate class of classes 1054, 2) access
fifteen to the instance tracking structure 1065 with the instance key to access the appropriate instance of instances 1052, and 3) access the method tracking structure that uses the method key to access the producer dependency declaration appropriate. The instance of the producers designated by the commands of instance producers with the production keys 1025 and the instance of any discovered producers and the construction of the producer graph are illustrated by the structure of the graph (s) of the producer 1060 of the environment of execution 1004. Thus, in one embodiment of the invention, producer keys identified by instance producer commands with producer keys 1025 and those discovered through producer graph generation are stored in the producer graph structure (s). 10BO, along with additional information to represent the graph (s) of current producer.
25 As described above, block 1095 and 1098 may be part of block 1040, and therefore, the decision on which classes, instances, and producers to load / create an instance is driven by which producers are on the graph (s). ) of current producer. In such an embodiment of the invention, the load / instance of class, instances, and producers is optimized and focused on the producer.
The runtime environment client 1002 also includes data preparation commands, including producer override / reverse override commands from producer 1030. The override / reverse override commands include the producer producer's key to be overridden / reversed, as well as the cancellation values when they are canceled. The output module of the voided producer 1045 of the execution environment 1004 causes the producers designated by the reverse override / override commands of the producers to be overridden / reversed
35 voided This causal relationship can be indirect or direct.
In the case of the indirect causation relationship, the output module of the cancellation producer 1045 fills out the cancellation record 1047 for consumption by the graphic execution module of the producer 1070. In the case of a direct causal relationship, the output module of the cancellation producer 1045 accesses the output cache of the producer 1097 of the graph structure (s) of the producer 1060 and instances 1052. Specifically, as described with reference to the output module of the cancellation producer 390, in one embodiment, the producers may be classified as property producers or method producers, whereby the output module of the cancellation producer 1045 may include a characteristic of the exit module of the cancellation property producer (not shown) for voided property producers and an exit module of the cancellation method producer (not
Four. Five shown) for voided method producers; the cancellation of a property method causes the voided value to be stored in the output cache of producer 1097 of the graph structure (s) of producer 1060 and be stored in the data of the appropriate instance of instances 1052, while that the cancellation of a producer method causes the voided value to be stored in the producer output cache 1097.
In an embodiment of the invention the producers cannot be annulled before a graph of the producer of which they will be part has been initially executed (therefore, the producer will have already been instantiated as a result of having been designated as a producer of interest or as a result of being discovered by the automatic producer graph generation module 1040). However, in the embodiment shown in the figure
55 10, producers can be annulled before initial execution upon instantiation and annulled with a producer cancellation command. This producer normally canceled over time will be part of a producer graph through the discovery process (for example, when a dynamic dependency is resolved). In some embodiments of the invention, this data preparation may also include other types of commands being! The cancellation producer output module 1045 is shown as a dashed line chart, since it may not be present in alternative embodiments of the invention.
The graph structure (s) of producer 1060 also optionally includes incremental execution marking 1080 for some embodiments of the invention that support incremental execution. As described above with reference to incremental execution marking 382 of Figure 38, incremental execution marking 65 1080 is used to assist with incremental execution of producer graph (s) in execution beyond initial execution. . Different embodiments of the invention that use incremental execution marking 382, use it in different ways. For example, in one such embodiment of the invention that has a command register, the register is used to track which producers have been added and / or modified, and incremental execution marking 382 is used to mark the producers. that are affected (ancestors of the modified or added producers, and therefore dependent on them). As another example, in an embodiment of the invention such that it does not have a command register, incremental execution marking 382 is used to mark the producers that are added or modified, as well as those that are ancestors of the modified or added producers. (and therefore depend on them). As another example, in an embodiment of the invention such that it does not have a command register, the modifications and additions of the producers are made immediately and the incremental execution marking 382 is used to mark the 10 producers who are ancestors of the modified producers. or added (and therefore depend on them). While embodiments of the invention that support incremental execution and use incremental execution marking have been described, other embodiments of the invention support incremental execution that do not use incremental execution marking (for example, a command log is used to track producers that have been added or modified, and a list of start-up producers is kept in a start record of
fifteen execution, where the producer graph execution module 1070 starts from the start-up producers and makes its way to the ancestors of the producer graph (s) at the top, by way of example and not limitation, this Embodiment of the invention is described later in this document with respect to Figures 15-25.
twenty Execution environment client 1002 also includes global execution commands 1035. The graphical execution module of the producer 1070 of the execution environment 1004 executes the producer graph (s). As such, the graph execution module of producer 1070 modifies the output cache of producer 1097 (in the case of property producers and method producers), uses incremental execution marking 1080 (if present), and modifies data from instances 1052 (in the case of ownership methods). Various techniques
25 they have been discussed previously for the execution of the producers of the producer graph and are applicable here. For example, in the embodiments in which a command register is implemented, the command register is consumed and then the producer graph (s) is executed. In addition, in embodiments of the invention that support the possibility of unresolved dependencies, the producer graph axis module 1070 includes the dynamic dependency module 1075, which can invoke the producer graph generation module.
30 1040 automated.
Figure 10 also shows a graphical viewer module of the optional producer 1062 that provides a mechanism (for example, a graphic user interface) by which a programmer / user can view the producer graph (s) and outputs of the producers of the structure of producer graph (s). In addition, Figure 10 shows a
35 Graphical user interface module of optional configurable interactive producer output design 1085 to provide a graphical user interface (including dynamic invocation of blocks 1030 and 1035) representing the graphical user interface module of producer output design 840 interactive configurable.
In embodiments of the invention that use a command register, different triggers can be used.
40 to activate different actions. For example, producer instance creation commands can be registered and processed in batches in response to an explicit command (start registration and end registration), a global explicit execute command (registration starts automatically at startup and after each command execute global explicit, and each record is processed in response to the next command execute global explicit execution), an explicit data preparation command, etc. Similarly, the preparation commands of
Four. Five data can be recorded and processed in batches in response to a global explicit execute command, a first get command, every get command, etc.
Sample Tracking Structures
fifty Figures 11A-D are block diagrams illustrating the example content of the data structures of Figure 10 according to an embodiment of the invention. While Figures 11A-D illustrate these data structures as tables, it should be understood that any suitable data structure can be used (for example, a hash map, a set, a list).
55 Figure 11A is a block diagram of an example of the class 1092 tracking structure of Figure 10 according to an embodiment of the invention. In Figure 11A, a class key column 1110 and a class reference column 1115 are shown to store, respectively, the class keys and corresponding references to the loaded classes.
60 Figure 118 is a block diagram of an example of the instance tracking structure 1065 of Figure 10 according to an embodiment of the invention. In Fig. 118, an instance key column 1120 and an instance reference column 1125 are shown to store, respectively, the instance keys and references corresponding to the cases. In embodiments of the invention in which the instance keys do not have to be unique in all dases, the example tracking structure also includes the
65 class or reference for the instance class.
Figure 11C is a block diagram of an example of the producer graph (s) structure 1060 of Figure 10 according to an embodiment of the invention. In Figure 11C, a reference column of class 1135, an instance reference column 1140, and a method reference column 1145 are shown to store respectively references that make up the current producers of the producer graph (s).
5 current. These references can take a variety of forms. For example, these columns, respectively, can store references in classes 1054 (or, alternatively, 1092), instances 1052 (or, alternatively, 1065), and methods 1056 (or, alternatively, 1058). While in one embodiment of the invention these columns store references, in one alternative embodiment of the invention one or more of these columns stores keys.
In addition, Figure 11C includes a link column (s) of parent producer (s) 1150 (including for each link a parent producer reference, and a dependency determination producer reference) and a link column (s) ) of offspring producer (s) 1160 (including for each link, the offspring producer reference (s), a reference of the dependency termination producer, a link mode, and an adherent link indicator). Each producer may have zero or more producer links of the descendant in column 1160. Each descendant producer link in column 1160 includes: 1) reference (s) of the descendant producer that are references to other lines of the producer graph structure (s) to represent of a producer dependency according to the producer dependency statement, 2) a reference of the dependency determination producer that is a reference to another row of the producer's graph structure (s) and represents the dependency determination producer that created the downlink, and 3) a link mode with a type of producer dependence that identifies whether the producer's dependence is a result of an argument, a field, or a sequencing dependency (see discussion regarding Figures 7A-F), and if an argument, the argument ID of the producer dependence, and 4) an adherent indicator to indicate that the link mode is the result of an upwardly declared dependency 25 (in the embodiments of the invention they support, upwardly declared dependencies) or the result of an adherent subscription (in the embodiments of the invention that support adherent subscriptions) and should not be modified through the argument of the producer's dependency statement (that is, the producer stored in the row of the column that contains the adherent indicator). Each producer can have zero or more parent producer links in column 1150. Each parent producer link in column 1150 includes: 1) a parent producer reference that stores a reference again according to a reference producer descending from another producer (i.e., a reference to another row of the producer graph structure (s) to represent a producer parent dependent on the producer ), and 2) a dependency determination producer reference that is a reference to another row of the producer's graph structure (s) and represents the dependency detention producer that created the parent link.
35 Therefore, when a link is created, the parent producer link column of the descendant producer row and the link producer column descending from the parent producer row have been modified to represent the link (and the termination of the producer's reference unit is the same in both). In one embodiment of the invention, since multiple routes in a producer graph or different producer graphs may include a particular producer, there may be multiple parent producer links for a given producer.
In addition, Figure 11C includes an output cache and modification column of the output of the cancellation producer 1170 for storing the outputs of the current producer, as well as an indication of whether the producer is canceled and the output value overridden. In addition, Figure 11 C includes an incremental execution mark column
Four. Five 1180 for storing incremental execution marks as described above.
Figure 110 is a block diagram of an example of the tracking structure of method 1058 of Figure 10 according to an embodiment of the invention. In Figure 11 D, a key column of method 1190 and a reference column of method 1192 shown to store, respectively, the method keys and references corresponding to the methods of the loaded classes. In addition, Figure 11 D also includes an ArgumentDependencies 1194 column, a FieldDependencies 1196 column, a SequencingDependencies 1195 column, an UpwardDependencies 1193 column, a WeaklyConstrainedDependencies 1199 column, an output class 1197 column, and an additional optional annotation column 1198 The ArgumentDependencies 1194 column, the SequencingDependencies 1195 column, the
55 UpwardDependencies 1193 column, the WeaklyConstrainedDependencies 1199 column, and the FieldDependencies 1196 column store producer dependency information analyzed from the producer's dependency declaration of the method (for example, see 705 of Figure 7A), while the column of output class 1197 stores information regarding the output class of the method output (determinable by the method signature - for example, see 710 of Figure 7A). Examples of content of the ArgumentDependenCies 1194 column, the FieldDependenCies 1196 column, the SequencingDependencies 1195 column, the UpwardDependency 1193 column, and the WeaklyConstrainedDependencies 1199 column, which are used in some embodiments of the invention are provided later in this document.
Dependencies of the dynamic producer
As described above, one embodiment of the invention supports dependencies of non-dynamic and dynamic producers. Although different embodiments may support different types of dependencies of dynamic producers, one embodiment of the invention supports quotas and subscription types of dependencies of dynamic producers. Therefore, a non-contingent dependency, without subscription, is a non-dynamic (static) dependency.
Figure 12 is a block diagram illustrating additional details of Figure 10 to support the contingent and subscription type dependencies of dynamic producers according to an embodiment of the invention. Figure 12 includes in figure 10 the dashed dividing line 1000, the class definitions that include the business logic 1010 (which includes the data 1012, the methods 1014, and the producer dependency statements 1016), the module new class 1095, classes 1054 (including methods and declarations of dependence of producers 1056), new instance module 1098, instances 1052, tracking example structure 1065, the module of automated generation of the graph of the producer 1040, the structure of the graph (s) of the producer 1060, and the module of execution of the graph of the producer 1070 (including the dynamic dependency module 1075).
Figure 12 shows that producer dependency statements 1016 optionally include contingent dependencies 1210, subscription dependencies 1220, and multiple producers 1215. Here, multiple producers 1215 refers to the ability of a producer dependency to return a collection of producers . In addition, Figure 12 includes a subscription module 1240 and a contingency module 1230 in the automated generation module of producer graph 1040 for processing contingent dependencies 1210 and subscription dependencies 1220. Figure 12 also shows that the module of 1240 subscription accesses a 1250 subscription record. In addition, dynamic dependency module 1075 includes a contingency module 1260 and a subscription module 1265 to process contingent dependencies 1210 and subscription dependencies 1220. Subscription module 1265 accesses subscription registration 1250.
The following description of the contingent and subscription dependencies is made in the context of an embodiment of the invention that uses a class DEP (an abbreviation for the dependency), from which an instance is returned by the dependency determination producers and It is analyzed by the execution environment with the support of the programming oriented to the producer's graph. The class DEP includes the following fields: 1) TYPE that can be adjusted to the subscription, without declared downward subscription (descending producers who do not subscribe), or without declared upward subscription (the parent producers who do not subscribe), 2) PROD that is used for dependencies without downward subscription dedaradas and a collection of the descending producers (as such, can store zero or more producers), 3) SUB TYPE that is used for subscription dependencies and is set to indicate the type of subscription dependency (used in 35 embodiments of the invention that support multiple types of subscription, while performing the invention described herein It is compatible with two types: adherent and absorbent, alternative realizations can support more, less, and / or different types of subscription, 4) CRIT SUB, which is used for subscription dependencies and is established to indicate the subscription criteria, 5) LINK MODE PAR that It is used for subscription dependencies and dependencies without subscribed adherent dedaradas and is established to indicate what is the mode of link that should be the parent producer: 6) PAR CLASS that is used for subscribed dependencies and subscribed non-subscribed dependencies and is set to indicate what the parent producer's class should be (for example, the class key); 7) PAR METHOD that is used for adherent subscription dependencies and declared non-subscription ascending dependencies and is set to indicate what the parent producer's method should be (for example, the method key), and 8)
Four. Five PAR INSTANCE that is used for the adherent subscription dependencies and the declared ascending non-subscription dependencies established to indicate what the parent producer's instance should be (for example, the instance key) (If the PAR instance is left blank, the key instance of the descending producer is used for the parent producer). An alternative embodiment could use a collection of parent producers (each element of the collection supports a PAR_CLASS, PAR_INSTANCE, PAR_METHOD, PAR_LINK MODE) in the case of adherent subscription dependencies and / or declared non-subscription dependencies. Of course, other alternative embodiments of the invention could use a different structure to return dependencies.
Contingent dependencies
55 In one embodiment of the invention, both dependencies of non-contingent and contingent producers are compatible. A non-contingent dependency producer is one that is independent of the output of the other producers, while a dependency of the contingent producer is one that is dependent on the output of other producers. While one embodiment of the invention supports dependencies of non-contingent and contingent producers, alternative embodiments only admit non-contingent or contingent (whose contingent dependencies of the producers may initially be driven by default values).
As previously discussed, a producer can be seen as a set of multiple identifiers, an identifier for each additional level of specified granularity. In one embodiment of the invention, a dependency of the contingent producer may be contingent in the sense that any or all of the set of identifiers can be conditionally determined based on the values of the current data.
For example, a first dependency of the contingent producer may have only the identifier of the instance that was determined conditionally (the class identifiers and the method are fixed), while a second dependency of the contingent producer may have the class, the instance and the identification method that was determined conditionally. Although in an embodiment of the invention all the plurality of the identifiers
5 from a dependency of the contingent producer they can be conditional, alternative embodiments of the invention can be implemented in a different way (for example, they only allow a subset of the plurality of identifiers to be conditional).
Figures 13A-J are block diagrams illustrating the pseudo code and example agreement producers
10 with an embodiment of the invention. In addition, the embodiments shown in Figures 13A-J use the same dependency determination mechanism for both contingent and non-contingent dependencies. As such, for explanatory purposes, some of the examples in Figures 13A-J are examples of dependencies of non-contingent producers, while others are examples of dependencies of contingent producers. In addition, a non-contingent producer agency is one in which the agency is a
fifteen producer of dependency determination that is an independent producer (for example, in one embodiment of the invention, the type of dependency is identifiable because its producer dependency statement is empty), while a dependency of the contingent producer is one in the that the dependency is a dependency determining producer that is a dependent producer (for example, in an embodiment of the invention, the type of dependency is identifiable because its producer dependency statement is not empty).
twenty In addition, numbers and letters in circles are used in Figures 13A-J to illustrate the order in which operations are performed in accordance with an embodiment of the invention. In addition, an X :: Y :: Z notation is used in Figures 13A-J to represent a producer key that is composed of a class key (X), an instance key (Y), and a method key (Z). In addition, circles of lines and lines with arrows represent the
25 operations that are not performed in some embodiments of the invention. In particular, when the execution of an independent dependency determination producer for a given dependency will always return the same dependency (for example, an independent dependency determination producer), this dependency determination producer is executed in some realizations. of the invention, but not instantiated and linked in the graph (s) of the producer.
Producers of explicit dependency determination
Figure 13A illustrates pseudo code of producer dependency declarations for methods that use a non-declared non-dynamic direct access dependency (non-contingent, no subscription) according to an embodiment of the invention, while Figure 138 is a block diagram of producers illustrating a dependency of the declared non-contextual example producer, not dynamic (non-contingent, no subscription) according to an embodiment of the invention. Figure 13A shows: 1) a producer dependency declaration 1300 of an alpha 1305 method, where the producer dependency declaration 1300 includes a producer dependency with the producer CW :: IY :: BETA, and 2) a declaration of dependence on
40 producer 1310 for a beta method 1315, where the producer dependency declaration 1310 is empty, and where beta method 1315 returns as an argument of an instance of the EPO class. The beta method 1315 includes the producer dependency declaration code 1320 that establishes DEP.TYPE in non-declared decryption down, establishes DEP.PROO in producer 13, and returns DEP.
Four. Five In Figure 13A, a circle 1 indicates that the producer dependency declaration 1300 is accessed (for example, as a result of the designation of a producer based on the alpha 1305 method as a producer of interest, as a result of the automated detection from a producer based on the alpha 1305 method, as a progeny ie from a producer of interest, etc.). A circle 2 in Figure 138 shows that a producer CO :: IO :: ALFA is instantiated based on the alpha 1305 method. A circle 3 in Figure 13A indicates that the dependence of the producer CW :: IY :: 8ETA
fifty it is processed to determine the producer's dependence, and as a result, a circle 4 indicates that the producer's dependency statement 1310 is accessed. A dashed circle 5 in Figure 138 shows that a CW :: IY :: 8ETA producer is instantiated as a dependency determination producer 1380. A dashed circle 6 in Figure 13 indicates that producer CO :: IO :: ALFA is linked to the producer's graph to indicate that producer CW :: IY :: BETA is a descending producer. A circle 7 in Figure 138 indicates that the producer
55 CW :: IY :: BETA runs and returns DEP to identify producer 13. A circle 8 indicates that producer 13 is instances 13, while a circle 9 indicates that producer 13 is linked as a descending producer in the producer's graph with producer CO:: IO :: ALPHA. In Figure 13B, producer CO :: IO :: ALFA and producer 13 are standard producers 1385 (which are not producers of dependency determination).
60 Figure 13C illustrates a pseudo code of Producer Dependency Claims of the methods that use a contingent undeclared direct access producer dependence without subscription in accordance with an embodiment of the invention, while Figure 130 is a diagram of producer blocks illustrating an example of producer dependence without declared direct access, contingent, without subscription according to an embodiment of the invention. In addition, Figure 130 refers to producers 5, 7A, 7B and Figure 5A and the
65 resolution of dynamic dependence from producer 5 to producer 7A.
Figure 13C shows: 1) a 1300 producer dependency statement for an alpha 1305 method, where the 1300 producer dependency statement includes a producer dependency with the CW :: IY :: BETA producer, 2) a 1325 producer dependency statement for a beta method 1315, where the declaration of dependency of the proouctor 1325 includes a dependency of the producer with the producer 5 CU :: IV :: OELTA, and where the beta method 1315 returns as an argument an instance of the EPO class; 3) a producer dependency declaration 1332 for a delta method 1334, where the producer dependency declaration 1332 is empty, and where the delta method 1334 returns as an argument of an instance of the EPO class, and 4) a dependency declaration from producer 1338 for a gamma method 1340, where the producer dependency declaration 1338 is empty, and where the gamma method 1340 returns to variable X (where X is an external source, a default value (explicit or constant in class. ”The beta method 1315 includes the producer dependency declaration code 1330 that establishes OEP.TYPE in declined down subscription, sets DEP.PROO to producer 7A or 7B based on the output of the producer CX :: IZ :: GAMMA, and returns OEP. Delta method 1332 includes the producer dependency declaration code 1336 that establishes OEP.TYPE to no downward subscription declared, establishes OEP.PROO in the producer
fifteen CX :: 1Z :: GAMMA, and returns OEP.PROO.
In Figure 13C, a circle 1 indicates that the producer dependency declaration 1300 is accessed (for example, as a result of the designation of a producer based on the alpha 1305 method as a producer of interest, as a result of the automated detection of a producer based on the Alfa 1305 method as a progeny of a producer of interest, etc.). A circle 2 in Figure 130 shows that producer 5 is instantiated based on the alpha 1305 method. A circle 3 in Figure 13C indicates that the producer's dependence CW :: IY :: BETA is processed to determine the producer's dependence, and as a result, a circle 4 indicates that the producer's dependency declaration 1325 is accessed. A circle 5 in Figure 130 shows that a CW :: IY :: BETA producer is instantiated as a dependency determination producer 1380. A circle 6 in Figure 13D indicates that the
25 Producer 5 is linked to the producer graph to indicate that producer CW :: IY :: BETA is a descending producer.
A circuit 7 in Figure 13C indicates that the producer's dependence on the producer CU :: IV :: OELTA is processed to determine the producer's dependence, and as a result, a circle 8 indicates that the producer's dependency statement 1332 is accessed. A circle of lines 9 in Figure 130 shows that a producer CU:: IV:: DELTA is instantiated as a producer of dependency determination 1380. A dashed circle 10 in Figure 130 indicates that producer CW :: IY :: BETA is linked to the producer's graph to indicate that producer CU:: IV:: DELTA is a descendant producer. A circle 11 in Figure 130 indicates that producer CU :: IV :: OELTA runs and returns DEP to identify CX :: 1Z :: GAMMA. A circle 12 indicates that the producer
35 CX :: IZ :: GAMMA is instantiated, while a circle 13 indicates that producer CX :: IZ :: GAMMA is linked as a descending producer in the producer's graph in producer CW :: IY :: BETA
In Figure 130, a circle A indicates that producer CX :: IZ :: GAMMA runs and returns X for producer CW :: IY :: BETA, while circle B indicates that producer CW :: 1Y :: BETA returns EPO to identify producer 7A; A circuit indicates that the unresolved remainder (beta method) 1390 has now been resolved and producer 7A is instantiated, while a circle O indicates the link between producer 5 and producer 7A. In Figure 13D, CX :: IZ :: GAMMA, 5 and 7A producers are standard 1385 producers.
Producers of flight dependency determination
Four. Five Figure 13E shows the pseudo code of the producers' dependency declarations of the methods that use a dependency of the declared direct access producer, contingent, without subscription and a declared producer dependence of direct access, contingent, without subscription according to an embodiment of the invention, while Figure 13F is a block diagram of producers illustrating a dependency on the undeclared direct access producer, contingent, without subscription and a dependency of the declared direct access producer, contingent, without subscription according to an embodiment of the invention. Similar to Figure 13D, Figure 13F refers to producers 5, 7A, and 7B of Figure 5A and the resolution of the dynamic dependence of producer 5 to producer 7A.
55 Figures 13E-F are the same as Figures 13C-D, with the exceptions: 1) a producer dependency declaration 1342 replaces the producer dependency declaration 1325; 2) a fly method 1344 replaces the delta method 1334, and 3) a producer CW :: IY :: FLY replaces the producer CU :: IV :: DELTA The producer dependency declaration 1342 includes a declared direct access dependency of the producer CX :: IZ :: GAMMA ASi, circle 4 in Figure 13E now indicates that the producer dependency declaration 1342 is accessed. Circle 7 in Figure 13E now indicates that the direct access unit of the CX Producer's CX :: IZ :: GAMMA is processed to determine the producer's dependence, and as a result, the executing agency invokes the dependency determination producer CW :: IY :: FLY on the fly based on the fly method 1344. Circle 8 now indicates that the producer dependency declaration 1332 is accessed. The dashed circle 9 in Figure 13F now shows that producer CW :: IY :: FLY is instantiated. The circle of strokes 10
65 in Figure 13F it indicates that the producer CW :: IY :: BETA is linked to the graph of the producer to indicate that the producer CW :: IY :: FLY is a descending producer. Circle 11 in Figure 13F indicates that the producer
CW :: IY :: FlY runs and returns DEP to identify CX :: IZ :: GAMMA. The rest of Figures 13E-F are the same as Figures 13C-D.
generation on the fly through the producer's environment for determining dependence
5 CW :: IY :: Fly relieves the application programmer of having to write the declaration code of the producer's explicit dependency and create instances of a producer-based determination. In addition, it allows the application programmer to directly specify producer dependency
CX :: IZ :: GAMMA in the producer dependency declaration for beta method 1315, instead of specifying the dependency determination producer CU :: JV :: DEl TA.
The direct access technique can be used in a variety of situations, and additionally they can have a variety of formats. For example, although in Figures 13E-F the declared dependence of direct access is a non-contingent dependency (which directly identifies the descending producer) and is in a declaration of producer dependence for a method on which a producer is based of determination of the
fifteen dependence, other situations and formats are shown as follows: 1) Figures 13G-H illustrate the use of two shortcuts, where one is contingent and is part of a producer dependency declaration of a method on which a standard producer is based and the other is non-contingent and is part of a producer dependency declaration of a method on which a dependency determination producer is based, and 2) Figures IJ illustrate the use of a shortcut that is not contingent and that is in a producer declaration state of dependence on a method on which a standard producer is based.
Figure 13G illustrates the pseudo code of producer dependency declarations for the methods that use a dependency of the direct access producer declared non-subscription contingent and a dependency of the direct access producer declared non-contingent without subscription in accordance with one embodiment. of the invention, while Figure 13H is a block diagram of producers illustrating an abbreviated method of a declared producer dependency declared, contingent, without subscription and a dependency of the direct access producer declared non-contingent without subscription in accordance with an embodiment of the invention. Figure 13G shows: 1) a producer dependency declaration 1345 for the alpha 1305 method, where the producer dependency declaration 1345 includes a direct access producer dependency declared contingent with a producer <P> GETC1 :: 11 :: M1; 2) a producer dependency declaration 1350 in a fly1 1355 method, where the producer dependency declaration 1350 includes a direct access producer dependency declared non-contingent in the producer CO :: IO: GETC1, and where the fly1 1355 method returns as an argument of a DEP instance, 3) the producer dependency declaration 1332 of a fly2 1362 method, where the fly2 1362 method returns as an argument of an instance of
35 DEP, Y 4) the producer dependency declaration 1365 for a getc1 1370 method, where the getc1 1370 method returns to C1 with a value of CX or ey.
The FlY1 1355 method and its producer dependency declaration 1350 are provided by the execution environment in response to the dependency declared in the shortcut <P> GETC1 :: 11 :: M1 (indicating that the shortcut is being used for the class key). The fly1 1355 method includes the code of the producer dependency declaration 1360 that sets DEP.TYPE to sets declared descending without DEP.PROD subscription to the producer CX :: 11 :: M1 or CY :: 11 :: M1 depending on the value of output C1 by the producer of CO:: 10:: GETC1, and returns DEP. Although in the example of Figure 13H, a <P> is used to designate that it is the class key of the producer that is contingent, alternative embodiments of the invention could use other
Four. Five syntax. In addition, although in the example of Figure 13H, a <P> is used to designate that it is the class key of the producer that is contingent, an embodiment of the invention supports having more and / or different identifiers that make up the Producer code to be indicated as a quota in this way.
In Figure 13G, a circle 1 indicates that the producer dependency declaration 1345 is accessed (for example, as a result of the designation of a producer based on the alpha 1305 method as a producer of interest, as a result of the automated detection of a producer based on the alpha 1305 method as a progeny of a producer of interest, etc.). A circle 2 in Figure 13H shows that the producer CO :: IO :: AlFA is instantiated based on the alpha 1305 method. A circle 3 in Figure 13G indicates that the dependency of the declared direct access producer is processed to determine the producer's dependence and the execution environment that
55 provides method fly1 1355, and as a result, a circle 4 indicates that the producer dependency declaration 1350 is accessed.
A circuit with a 5 in Figure 13H shows that a producer CO :: 10 :: FlY1 is instantiated as a dependency determination producer 1380. A circle 6 in Figure 13H indicates that producer CO :: IO :: AlFA is linked in the producer graph to indicate that the producer CO :: IO :: FlY1 is a descending producer. A circle 7 in Figure 13G indicates that the producer's dependence on the direct access declared in CO :: 10 :: GETC1 is processed to determine the producer's dependence and the execution environment provided by the fly2 1362 method, and as a result, a Circle 8 indicates that the producer dependency declaration 1332 is accessed. A dashed circle 9 in Figure 13H shows that a producer CO :: IO :: FlY2 is instantiated. A circle of strokes 10 in
65 Figure 13H indicates that producer CO :: IO :: FlY1 is linked in the producer graph to indicate that producer CO :: IO :: FlY2 is a descending producer.
A circle 11 in Figure 13H indicates that producer CO :: 10 :: FLY2 is executed and DEP is returned to identify producer CO :: 10 :: GETC1. A circle 12 indicates that producer CO :: 10 :: GETC1 is instantiated, while a circle 13 indicates that producer CO :: 10 :: GETC1 is linked in the producer graph in producer CO :: 1O :: FLY1 as
5 descending producer.
In Figure 13H, a circle A indicates that producer CO :: 10 :: GETC1 runs and returns C1 = CX to producer CO :: 10 :: FLY1, while circle B indicates that producer CO :: 10: : FLY1 runs and returns DEP to identify the producer CX :: 11 :: M1, a circle C indicates that the remainder not resolved (fly1 method) 1390 has now been resolved, and a circle O indicates the linkage of producer CO :: IO :: ALFA with producer CX :: 11 :: M1. In Figure 13H, the producers CO :: 10 :: GETC1, CO :: IO :: Alfa, and CX :: 11 :: M1 are the standard producers 1385.
The fly generation through the execution environment of the dependency determination producer CO :: 10 :: FLY1 and CO :: 10 :: FLY2 relieves the application programmer from having to write the dependency declaration code
fifteen explicitly of the producer and of creating instances of the producers of the dependence determination based on the same. In addition, it allows the application programmer to directly specify the contingent dependency on a producer ** :: 11 :: M1 through the getC1 method in the producer dependency declaration of the alpha 1305 method, as opposed to the producer's specification of dependency determination CW :: IY :: BETA.
Figure 131 illustrates the pseudo code of the producer dependency statements of the methods that use a dependency of the direct access producer declared non-dynamic (non-contingent, without subscription) according to an embodiment of the invention, while the figure 13J is a block diagram of producers illustrating a dependency of the context example producer declared non-dynamic according to an embodiment of the invention. Figure 131 shows: 1) a declaration of dependence of producer 1372 on a
25 method alpha 1305, where the declaration of dependency of the instructional producer 1372 includes a declared dependence of the producer of direct access to a producer 10, and 2) a declaration of dependence of the producer 1374 for a fly method 1376, where the declaration of dependence of the producer Producer 1374 is empty, and where the fly 1376 method returns as an argument of an instance of DEP. The fly method 1776 and its producer dependency declaration 1374 are provided by the execution environment in response to the declared direct access dependency. The fly 1376 method includes producer dependency declaration code 1378 that establishes DEP.TYPE without a declared subscription, establishes DEP.PROD to producer 10, and returns DEP.
In Figure 131, a circle 1 indicates that the producer dependency statement 1372 is accessed (for example, as a result of the designation of a producer based on the alpha 1305 method as a producer of interest,
35 as a result of the automated detection of a producer based on the Alpha 1305 method as a progeny of a producer of interest, etc.). A circle 2 in Figure 13J shows that a producer CO :: IO :: ALFA is instantiated based on the alpha 1305 method. A circle 3 in Figure 131 indicates that a dependency of the declared direct access producer is processed to determine the producer's dependence and the execution environment provided to the fly 1376 method, and as a result, a circle 4 indicates that the dependency declaration of the Producer 1374 is accessed. A dashed circle 5 in Figure 13J shows that a producer CO :: IO :: FL is instantiated as a producer of dependency determination 1380. A dashed circle 6 in Figure 13J indicates that producer CO :: IO :: ALFA is linked to the producer's graph to indicate that producer CO :: IO :: FLY is a descending producer.
Four. Five A circle 7 in Figure 13J indicates that producer CO :: IO :: FLY is executed and returns DEP to identify producer 10. A circle 8 indicates that producer 10 is instantiated, while a circle 9 indicates that producer CO :: IO :: ALFA is linked in the producer graph with producer 10, indicating that it is a descendant producer. In Figure 13J, producer CO :: IO :: ALFA and producer 10 are standard producers 1385.
It should be understood that the programmer of the runtime environment, in one embodiment of the invention, writes a single fly method to interpret all supported syntaxes and combinations (for example, the fly 1334 method, the fly1 1355 method, the fly2 1362 method , the fly method 1376) And induces it in the execution environment. This not only allows application programmers to avoid code writing for dependency determination producers where a fly method can be used, the runtime environment programmer only needs
55 write the generic fly method (the single fly for all supported situations) only once. In addition, it should be understood that the direct access dependencies thickened to allow an execution environment that uses the dependency determination producers, while at the same time allowing an application programmer to indicate the standard producers in the dependency declarations of the producers (for example, figures 13G-J).
Method Tracking Structure
With reference again to the tracking structure of the method of Figure 110, example contents of the ArgumentDependencies 1194 column, FieldDependencies 1196 column, SequencingDependencies 65 1195 column, UpwardOependencies 1193 column, and the WeaklyConstrainedOependencies 1199 column used in some embodiments of the invention will now be described. Specifically, the ArgumentOependencies 1194 column stores a collection of items, one for each ArgumentDependency. In an embodiment of the invention, each article includes the following: 1) the Identification argument, 2) an identifier of the nature of the class key, being one of explicit class, the same class and the contingent class, 3) an identifier of the population explicit class key, when the identifier of the class key indicates the explicit nature of the class, 4) the 5 key identifier of the method of determination of the populated contingent class, when the identifier of the class key indicates the nature of the contingent class, 5) an identifier of the nature of the instance key, being one of the explicit instance, the same instance and the contingent instance; 6) a key identifier of the populated explicit instance, when the identifier of the key instance indicates the nature of the explicit instance; 7) the identifier of the key of the method of determination of the populated contingent instance, when the identifier of the nature of the key of the instance indicates contingent instance, 8) an identifier of the nature of the key of the method, being one of the method Explicit, the same method, and the contingent method; 9) a key identifier of the explicit method filled when the key identifier of the nature of the method indicates which explicit method; 10) the identification key for determining the populated contingent method, when the identifier of the nature of the method key indicates which contingent method; and 11) an identifier of
fifteen direct access indicating whether the producer dependency statement for the argument in the producer dependency statement contained a direct access indication (that is, the producer dependency statement directly identifies a standard descending producer instead of a producer of dependence determination).
The indication - .. explicit "of the various identifiers of the nature of the key is used when the explicit key is provided for producer dependency in the producer dependency declaration. As an example, producer dependence" CW: : IY :: BETA "of the producer dependency declaration 1300 of Figure 13A provides an explicit class, example, and method key.
25 In some embodiments of the invention, a direct link technique is compatible with producer dependency statements such that: 1) if a class is not intended for a dependency of a particular producer, then the same class is used as the parent producer, and 2) if a class and instance are not provided for a dependency of a particular producer, then the same Class and instance as the parent producer is used. In other embodiments of the invention, a syntax is used to allow any combination of class, instance, and method, to be the same as the parent (with the exception that all are equal) (for example, a separator is used to designate each class, instance, and method, and an absence of this separator indicates the same as parent -a specific example title, the syntax can be "# C:", H # 1: ", and H # M: H, such that a producer dependency in a producer dependency declaration can be # C: "dase key :: # 1:" instance key ":: # M: Method H key) (where quotas indicate a placeholder for a value or a
35 variable). The indication "... same" of the nature of the different key identifiers used in this direct access technique is used in the declaration status of the producer's agency.
As indicated above, in some embodiments of the invention an indication of a dependency of the contingent producer is supported through a syntax (for example, <P »used in the producer's own declaration of dependence (see 1345 of Figure 13G ), and this syntax can be used in one or more of the class, the instance, and the method of a producer dependency. contingent "of the various identifiers of the nature of the key is used to identify when a dependency of the contingent producer occurs, while Hidentifier of the determination method key ... contingent" indicates the method key of the descending producer (the class and instance are the same as that of the parent producer). TO
Four. Five As an example, the producer dependency "<P> GETC1 :: 11 :: M1" for the producer dependency declaration 1345 of Figure 13G provides a contingent class (where the key to the method of determining the contingent class is GETC1 ), an explicit instance key, and an explicit method key.
The SequencingDependencies 1195 column, the UpwardDependencies 1193 column, and the WeaklyConstrainedDependencies 1195 column each store a collection of elements, one for each SequencingDependency, UpwardDependency and WeaklyConstrainedDependency. In one embodiment of the invention, each element has the same structure as an element of the ArgumentDependencies collection, except that it does not include an argument identifier. In addition, although Figures 13A-J illustrate declined non-subscribed dependencies from the dependency determination producers, it should be understood that in the case of a dependency declared ascending or weakly limited dependence, the dependency determination producer may return the other dependencies discussed with reference to figures 7F
G.
The FieldDependencies 1196 column stores a collection of elements, one for each FieldDependency. Although in an embodiment of the invention, each element includes the key to the property method, in alternative embodiments of the invention they may have the same structure as an element of the SequencingDependencies collection.
Subscription Dependencies
In an embodiment of the invention, both dependencies of subscription and non-subscription producers are compatible. When a dependency of the subscription producer is declared for a given method and a producer is instantiated from that given method, the execution environment can resolve during the execution environment (based on the existence of other producers), the set of zero OR more producers that meet the subscription criteria. While one embodiment of the invention is compatible with dependency producers
5 subscription and dependency without subscription, alternative realizations only support without subscription. In addition, although in one embodiment of the invention two types of subscription dependencies are compatible (absorbent and adherent), alternative embodiments of the invention support more, less, and different types of subscription producer dependencies.
Figures 14A-C are block diagrams illustrating absorbent and adherent subscriptions according to an embodiment of the invention. Figure 14A is a block diagram of an example of the subscription record 1250 of Figure 12 according to an embodiment of the invention. Although Figure 14A illustrates this record structure as a table, it should be understood that any suitable data structure can be used (for example, a hash map). Figure 148 is a block diagram of example producers illustrating a
fifteen absorbent dependence on the non-contingent subscription producer according to an embodiment of the invention. Figure 14C is a block diagram of example producers illustrating an adherent dependency of the non-contingent subscription producer according to an embodiment of the invention. Two rows are shown in the table in Figure 14A filled with content used in the examples in Figures 14B-C. Numbers surrounded with a circle are used in Figures 14B-C to illustrate the order in which operations are performed in accordance with an embodiment of the invention.
In Fig. 14A, a column of subscriber producer keys 1400, a column of subscription type 1405, and a subscription criterion for the column of activation producers 1410 are shown to store, respectively, the content corresponding to the name of the spine. In addition, Figure 14A shows
25 a parent link mode column 1425 for storing the link mode for the parent producer of the subscription unit; This information will be described in more detail with respect to Figures 14B-C.
Figure 14A also shows a column of matching producers 1415 and a completed column 1420 used for absorption subscriptions. The matching producers column 1415 is used to store the production keys of the activation producers that meet the subscription criteria of the absorption subscription, while the entire column 1420 is used to control whether the absorption subscription has been completed during the given execution of a current set of producer graphs. Producers match columns 1415 and full column 1420 provides an optional additional optimization that allows the exploration work of instantiated producers that are divided between generation
35 Automated graph of the proouctor and the execution of the graph of the producer as described below.
Figure 14A also shows a parent class column 1430, a parent method column 1435, and a parent instance column 1437 used for adherent subscriptions. The parent class column 1430, the parent method column 1435, and the parent instance column 1437, respectively, store the class key, the method key, and the instance key of the parent producer that will be created for the adherent subscription . In addition, Figure 14A shows a reference column of the dependency determination producer 1421 that stores a reference for the dependency determination producer that creates the subscription.
Absorption Subscription
Four. Five In a dependency of the absorption subscription producer, the dependence is the collection of all producers of the structure of the current graph (s) of the producer that meets the absorption subscription criteria. With reference to Figure 148, a circle 1 indicates a producer 1450 that is instantiated (for example, as a result of the designation of producer 1450 as a producer of interest, as a result of the automated discovery of producer 1450 as a progeny of a producer of interest, etc.). Producer 1450 is based on a method for which the producer dependency declaration includes a producer dependency (for example, with argument ID X). A circle 2 indicates the producer's dependence on producer 1450 that is processed to identify a producer 1455.
55 A circle 3 indicates that producer 1450 is linked (in the previous example, through argument ID X) in producer graph 1455 as a descending producer. A circle 4 indicates the execution of producer 1455. Producer 1455 is a dependency determination producer that includes the producer's dependency declaration code indicating a dependency of the absorption subscription producer and indicating the absorption subscription criteria . As such, the execution of producer 1455 results in filling in the subscription record. With respect to the example in the first row of Figure 14A, the subscriber producer key column 1400, the subscription type column 1405, the subscription criteria for the activation producers column 1410, the link mode column parent 1425, and the producer determination dependency reference column 1421 are, respectively, filled with producer producer key 1450, an indication that the subscription is of the absorption type, the absorption subscription criteria contained in the
65 producer 1455, the link mode of producer 1450 linked to producer 1455 (which, in the case of an absorbent subscription will be an argument dependency and include an argument ID, but whose indicator of
Adhesion will be indicated as non-adherent - in the previous example, Identification of the argument of X), and a reference to producer 1455 (the producer of the dependency that creates the subscription).
Circles 5A-N indicate the instantiation of producers 1460A-N. In this example, producers 1460A-N
5 they meet the absorbent subscription criteria, and therefore they are activation producers. As such, a circle 6A-N indicates the link between producer 1450 and producers 1460A-N (in the previous example, through the ID of argument X). A circle 7 indicates that the dependency of the absorbent subscription is completed for the current execution of the graph (s) of the producer, and the producer 1450 is then executed.
In one embodiment of the invention, the absorbent subscription criteria may be one or more of any of the keys that constitute a producer's key. Thus, in embodiments of the invention where a producer key comprises a class key, an example key, and a method key, the subscription criteria could be one or more such keys. As an example with reference to Figure 11C, a scan through instantiated producers for those who meet the subscription criteria is a scan to
fifteen through one or more of the first three columns of the graph (s) of the producer of the structure to determine whether the keys of the instantiated producers coincide with the keys of the absorption subscription criteria. Although in one embodiment of the invention, the absorbent subscription criteria may be one or more of any of the keys that constitute a producer's key, in alternative embodiments of the invention, the absorbent subscription criteria are limited to a subset of the keys. which constitute a producer key.
Adherent subscription
In a dependency on the subscription of the adherent producer, the dependency causes a parent producer to instantiate for each producer that meets the adherent subscription criteria. With reference to the figure
25 14C, a circle 1 indicates a producer 1470 that is instantiated (for example, as a result of the designation of producer 1470 as a producer of interest, as a result of the automated discovery of producer 1470 as a progeny of a producer of interest through a sequencing dependency (for example, as a result of a SequencingOependency or WeaklyConstrainedOependency, etc.). Producer 1470 is a dependency determination producer that includes the dependency of the producer declaration code indicating an adherent subscription, the adherent subscription criteria for the activation producers, and the adhesive subscription characteristics for the parent producer that is going to create.
The execution of producer 1470 results in populating the subscription record. With respect to the example in the second row of Figure 14A, the subscriber producer key column 1400, the subscription type column 1405, and the producers column of the criteria for activation subscription 1410, respectively, are fill in with the producer producer 1470 code, an indication that the subscription is of the adherent type, and the adherent subscription criteria for the activation producers contained within the producer 1470. In addition, the column of the parent class 1430, the column of the parent method 1435, the column of the parent instance 1437, and the link mode column 1425 of the parent producer that is linked to the activation producer are filled with the subscription features adherent for the parent producer that can be created - in this embodiment of the present invention, respectively, the class of the parent producer to instantiate, the method of the parent producer to instantiate, the example parent producer to instantiate (if left blank, would be equal to the activation producer instance key), the link mode (which, in the case of the adherent subscription, can be: 1) argument dependency , field, or sequencing, 2) the identity argument if an argument dependency - the ID of
Four. Five Parent producer argument is related to the activation producer (for example, the ID Y argument). In addition, the reference column of the dependency determination producer 1421 is filled with a reference for the dependency determination producer that created the subscription (in Figure 14C, the producer 1470).
With reference to Figure 14C, a circle 2 indicates a producer 1475 that is instantiated (for example, as a result of the designation of producer 1475 as a producer of interest, as a result of the automated discovery of producer 1475 as a progeny of a producer of of interest, etc.). In addition, it is determined whether producer 1475 meets the adherent subscription criteria for an activation producer. A circle 3 indicates that it responds to the activation producer 1475, a producer 1480 is instantiated based on the characteristics of adherent subscriptions for the parent producer to be created. With reference to the second example row of Figure 14C, the class key, the method key, the example key, and the link mode are accessed from the parent class column 1430, the parent method column 1435, the example column 1437, and the parent link mode column 1425, respectively. The parent producer has a producer ciave comprising the visited class key, the visited instance key (if left blank, the activation producer instance key (in Figure 14C, producer 1475)), and the key of the method accessed - in the example of Figure 14C, this is the first producer 1480. A circle 4 indicates that the instantiated parent producer 1480 is linked with the producer graph to the downstream activation producer 1475 through the access mode accessed (in the previous example, the type of the link mode = argument dependency, the argument of the link mode ID = Y). Also in circle 4, in the case of a dependency on the argument, the adherent indicator is set to indicate adherent - whose dependence on the producer in that position of the producer's declaration of dependence for the method on which the parent producer is based instantiated 1480 should be ignored by producer 1480 - this prevents the link
created by the dependency of the adherent subscription producer who are overwritten by subsequent operations of automated producer generation of graphs.
In one embodiment of the invention, the adherent subscription criteria for the activation producers may be one or more of the keys that constitute a producer key. Thus, in embodiments where a producer key comprises a class key, an instance key, and a method key, the adherent activation subscription criteria may be one or more of the class, instance, and method keys. . By way of example with reference to Figure 11C, a scan through instantiated procluctors for those who meet the adherent subscription criteria for activation producers is a scan through one or more of the first to third columns of the graph (s) of the producer of the structure to determine whether the keys of the instantiated producers coincide with the keys of the adherent subscription criteria for the activation producers. Although in one embodiment of the invention, the adherent subscription criteria for the activation producers may be one or more of the keys that constitute a producer key, in alternative embodiments of the invention, the absorbent subscription criteria may be one more number. limited of the keys that constitute a producer's key.
Figures 14D-E illustrate the choice of a parent producer based on a parent producer of dependency determination according to an embodiment of the invention. Although Figures 140-E are described with reference to the argument dependencies, embodiments of the invention can support the use of sequencing and field dependencies.
Figure 140 illustrates the choice of a parent producer based on a parent producer of dependency determination created by an adherent subscription according to an embodiment of the invention. Like Figure 14C, Figure 140 shows the adherent subscription producer 1470 and the activation producer 1475, however, more than the producer 1480, Figure 140 shows a dependency determination producer 1480 created by the adherent subscription of an adherent subscription producer 1470. In addition, Figure 140 shows that the mode of attachment of the adherent subscription is the argument dependency, the argument ID = X, Y adherent indicator = adherent. As illustrated by the broken line curved from producer 1475 to dependency determination procluctor 1480, the EPO returned by the dependency determination producer may be based on producer 1475's own output (the argument of the argument ID = X). In Figure 140, the dependency determination producer 1480 returns a dependency producer without upstream subscription declared in a producer 1482, with the link mode indicating the argument dependency and the argument ID = Y. Although the argument identifiers X e And they are used in Figure 140 to show that they can vary, it should be understood that they can be the same.
Figure 14E illustrates the choice of a parent producer based on a parent producer of dependency determination created by a descendant producer of dependency determination, which is linked to the producer of determination of descending dependence by a sequencing dependency, according with an embodiment of the invention. Figure 14E is similar in structure to Figure 140, specifically, producer 1475, 1480, and 1482 are replaced with producers 1486, 1496 and 1498. However, more than the adherent subscription producer 1470 that creates the link between producers 1480 and 1475, producer 1486 has a sequencing dependency of a dependency determination producer 1494 (for example, created through UpwardOependency or WeaklyConstrainedOependency a), which creates the dependency determination producer 1496 through a dependency without declared upward subscription.
It is noteworthy that adherent subscriptions and dependencies declared without ascending subscriptions (for example, created through UpwardOependencies and / or WeaklyConstrainedOependencies) cause a lower construction of a producer graph (as opposed to the top-down construction described above) in this document). In addition, this bottom-up construction is not limited to the construction of a single level, but can be multi-level (for example, if due to an adherent subscription or no up-subscribed subscription of declared dependency, a parent producer is instantiated, that the same parent producer may also be an activation producer for an adherent subscription or may include a dependency without a declared up-subscription and cause the instantiation of another parent procluctor, and so on). In this sense, the adherent subscriptions, as well as the up-subscribed non-subscription dependencies, inverse to the construction of the producer graph.
Although in some embodiments of the invention, the parent producers identified by the adherent subscription characteristics are standard producers (see Figure 14C), alternative embodiments can be implemented to support the identification of other types of producers. For example, in the embodiments of the invention that allow adherent subscription characteristics to identify a dependency determination producer (see Figure 140), this dependency determination producer can access the output of the activation producer and can , on the basis of that output, trigger the creation of a particular producer as a parent producer to adhere to the descendant (this parent producer could already exist or not, and if it already exists, it is simply linked, and the descending producer is added to its argument; if it does not exist yet, it is created). The case in which the dependency determination producer returns a constant producer mimics an absorbent subscription. The case in which the dependency determination producer returns a producer whose key example is unique to each activation producer (for example, returns a producer whose instance key is the producer producer's producer key) results in a parent producer separated from the descendant producer and is known as a pure adherent subscription. The case in which the dependency determination producer returns an instance key that is neither constant nor unique
5 For each activation producer, the behavior of pure adherent subscriptions and absorption subscriptions can be mixed and known as a non-pure adherent subscription.
Sample Advantages
10 As previously described, in one embodiment of the invention, producer dependencies are declared for methods as a way of specifying the method sequencing invocation using the appropriate instances (where the appropriate instances include the instances to be used as arguments, the instances to use by the instance methods, and the instances of the meta class used by the class methods) without using the manual invocation of the sequencing code, effectively, the work of
fifteen generating part or all of the invocation manual of the sequence code is replaced by: 1) the work done by the application programmer to write the producer dependency statements and 2) the work done by the execution environment for discover and build the graph (s) of the producer and execute the producers of that graph (s) of the producer. Although the effort to write the runtime environment is relatively large, it only needs to be written once because it can be used to run all oriented applications
twenty To objects written for the execution environment, on the other hand, for a typical application, the effort to write producer dependency statements is relatively low compared to the manual writing of the sequencing invocation code.
25 [0297] Non-dynamic producer dependencies provide a way to specify the invocation of unconditional code sequencing methods, and thus avoid the need to write the unconditional invocation of manual code sequencing. Producer quota dependencies provide for a way to specify conditional processing, and therefore eliminates the need to write manual conditional invocation sequencing code. Support to producer units that allow a collection of producers to
30 being returned provides a way to specify the filling of a collection before it is passed as a parameter, and thus avoid the need to write several calls in the manual invocation of sequence code to fill a collection before it is passed as a parameter . Subscription support provides an environment in which a programmer does not have to write specific listening code for each type of object to be heard (for example, in a graphical spreadsheet of producer-oriented programming, a subscription to absorption
35 It can be used to calculate an average of a range of cells (each cell is a producer) by having the absorption subscription criteria identify the cells within the range, and recalculate the average each time a new producer is added to the subscription of the absorption, in a graphical spreadsheet of programming oriented to producers, An adherent subscription can be used as a currency converter by having the adherent subscription criteria identifying the cells keeps the content of the currency and the
40 Adhesive subscription characteristics of the adherent producer (s) to create an instance to perform the currency conversion (the producers (holding the converted amounts) created by the adherent subscriptions would then be available for viewing in other cells).
Operation
New instance commands
Figure 15 is a flow chart for instantiating new instances according to an embodiment of the invention. As described above with reference to Figure 10, the new class module 1095 of the
fifty Figure 10 can be implemented as part of the new instance module 1098. The flow chart of Figure 15 assumes this embodiment and is carried out by the new instance module 1098; The part of the flowchart of Figure 15 representing the new class module 1095 is shown as the block of strokes 1580, which includes blocks 1540 and 1550.
55 In response to a new instance command (block 1510), control passes to block 1520. In block 1520, it is determined whether the instance already exists. If not, the control goes to block 1530, otherwise, it is not necessary to create an instance and the control goes to block 1570, in which the flow chart is terminated. In an embodiment that supports instance keys, block 1520 is made by accessing the instance tracking structure 1065 of Figure 10 for the instance key (and the class key if the instance keys do not have to be unique
60 through the ClaSeS) provided as part of the new instance command.
In block 1530, it is determined whether the class definition of the instance is already loaded. If not, the control goes to block 1540, otherwise, the control goes to block 1560. In an embodiment that admits class keys, block 1540 is performed by accessing the class 1092 tracking structure of the figure 10 for the key
65 class provided as part of the new instance command.
In block 1540, the class is loaded and control passes to block 1550. In block 1550, the class definition is stored according to the class key and introspection is performed, including any producer dependency declaration (stored for the key of the method within the class - see figure 11 D). From block 1550, control passes to block 1560. With reference to Figure 10, the following is done in blocks 1540
5 And 1550: 1) the class is loaded from the class definitions that include business logic 1010 in classes 1054 (this load results in loading methods and dependency declarations of the producers of the class are stored in the method and producer dependency statements 1056), 2) the class is added to the tracking structure of class 1092, and 3) the methods are added to the structure of the tracking method 1058. In addition, the output classes of the methods are loaded.
In block 1560, an instance of the class is instantiated and stored according to the instance key. With reference to Figure 10, the instance is instantiated in instances 1052, and the example is added to the instance tracking structure 1065. From block 1550, control passes to block 1570 in which the flowchart ends. In some embodiments of the invention in which an object allocation technique is used
fifteen relational, the data can be loaded from an external data source to fill the instance field as part of block 1560.
In some embodiments of the invention, classes and instances can be loaded / executed in a manner in which the execution environment with the programming support oriented to the producer's graph is not conscious (for example, 20 in Figure 9A, if execution environment 915 load / instance without execution environment 910 being aware). In such cases, the embodiments of the invention that also support the instance key are an example of the InstanceKey class (which has two elements: an instance key nature indicating whether the key identifier is a reference to the instance or other object (such as a string), and a key identifier that can be a reference to the instance, or to another object (such as a string )), blocks 1520 and 1530 will ask if the instance and class are instantiated / loaded in a way in which the execution environment with the programming support oriented to the producer's graph is conscious. In cases where the execution environment with the programming support oriented to the producer graph is not aware of an already loaded class, the class cannot be loaded, but the class is added to the monitoring structure of the class 1092 and the methods are attached to the tracking structure of method 1058. In cases where the execution environment is supported by
30 producer-oriented programming is not aware of an instance already created, the instance is not instantiated, but the instance is added to the tracking structure of instance 1065.
New Producer and Overridden Commands
35 Figure 16 is a flow chart for instantiating new producers and canceling producers according to an embodiment of the invention. With reference to Figure 10, the flows of Figure 15 are made by the graph generator module of the automated producer 1040 and the module of the cancellation producer 1045 (or, as described with reference to alternative embodiments with respect to the Figure 10, the module responsible for cancellation and reversal of the cancellation).
40 In response to a new producer command (block 1600), control passes to block 1605. In one embodiment of the invention, a new producer command can be executed in response to a variety of situations. Table 2 below identifies the various situations and the parameters passed according to an embodiment of the invention.
TABLE 2
<dl><dt>Situations </dt><dd>Calling producer Producer called (to be created if it does not exist) Call type Link mode Reference of the dependency determination producer </dd></dl>
<dl><dt>Producer of interest </dt><dd>NIA Producer of interest What is created Of interest NIA NIA </dd></dl>
<dl><dt>No subscription declared descending </dt><dd>Father Descends No subscription declared descending Binding mode of the pad re producer that calls Dependency determination producer that provides dependency </dd></dl>
<dl><dt>Adherent subscription </dt><dd>Descendant Parent (parent class, method and instance key from the adherent subscription characteristics for the parent producer to create, if instance key is blank, the instance key of the descending producer ~) and calls existing Adherent Link mode of the parent producer called from the adherent subscription features for the parent producer to create Dependency determination producer that provides dependency </dd></dl>
<dl><dt>Annulment </dt><dd>NIA Annual Producer Anu side NIA NIA </dd></dl>
<dl><dt>No upstream subscription declared </dt><dd>Descendant Father No upstream subscription declared Link mode of the parent producer called Dependency determination producer that provides dependency </dd></dl>
In block 1605, it is determined whether the producer already exists. If not, the control goes to block 1610, otherwise, the control goes to block 1670. Block 1605 is carried out by accessing a class, instance, and the method identified (for example, by the key yfo the reference) as part of the new producer command. In a
5 realization that supports the keys of the producers, block 1605 is made by accessing the graph (s) of the producer of structure 1060 of figure 10 for the producer key provided as part of the new producer command (the producer's key in the column of the called producer from Table 2).
In block 1610, the new instance module is called with a new instance command and control passes to
10 block 1615. In one embodiment of the invention, block 1610 is made by calling the flowchart of Fig. 15 using the instance key of the producer key in the column of the called producer of Table 2.
In block 1615, the class definition of the producer instance is accessed and control passes to block 1620.
fifteen With reference to Figure 10, block 1615 is made by using the class key of the producer key in the column of the called producer of Table 2 to access the appropriate class 1054 according to the structure of follow-up of class 1092.
In block 1620, the producer producer's method and declaration of dependence are accessed and the control
twenty go to block 1625. With reference to Figure 10, block 1620 is made using the producer's key of the method's key in the column of the called producer of Table 2 to access the appropriate methods and dependency declarations of 1056 producers of the class located in block 1615.
In block 1625, the producer is added to the producer graph and control passes to block 1630. With reference to the embodiment of the invention in Figure 11C, the first three columns are filled.
In block 1630, for each registered subscription, the criteria for filtering the subscription is processed to determine if the producer matches. With reference to the embodiment of the invention in Figure 14A, a subscription is considered registered when added to the subscription record. Examples of operations to register the
30 Subscription are described later in this document. Block 1630 is optional, which allows the optimization of the exploration work of the instance producers that is divided between the automated generation of the producer graph and the execution of the producer graph. As such, an alternative embodiment of the invention may not realize block 1630.
35 In block 1635, the producer is linked to the producer's graph (s) if called due to a dependency. From block 1635, the control goes to block 1640. The way in which block 1635 is carried out depends on the situation that resulted in the new command of the producer being executed (see Figure 20). For example, if the situation is that this is a producer of interest or an impersonation producer, then it is not called due to dependence and nothing is done. In contrast, if the situation is without subscription declared descending, then it
40 call due to an unsubscribed dependency declared descending; and with reference to the embodiment of the invention in Figure 11C, the following is done: 1) the parent producer (s) is linked in column 1150 of the called down producer (called producer column of table 2) is modified with a reference of the parent producer in the row of the calling parent producer (the column of the calling producer from table 2) and the reference for determining the dependence of the producer (reference column for determining the
Four. Five dependence on the producer of Table 2), and 2) the link column (s) of the descending producer (s) 1160 of the row of the calling parent producer (column of the calling producer of table 2) is modified with a reference to the descending producer in the row of the called descending producer (the column of the called producer of Table 2), a reference of the dependency determination producer (the reference column of the dependency determination producer in Table 2), and a link mode (established in accordance with the column of the
5 link mode of Table 2).
In contrast, if the situation is an adherent subscription, then it is called due to an activation producer that is identified, and with reference to the embodiment of the invention in Figure 11C, the following is done: 1) the link column (s) of the parent producer 1150 of the calling down producer (the column of the calling producer 10 in table 2) is modified with a reference of the parent producer in the row of the calling parent producer (the column from the called producer of table 2) and the producer reference of the dependency determination (the reference column for determining the dependence of the producer in Table 2), and 2) the link (s) of the descending producer (s) 1160 of the calling parent producer's row (calling producer's column of table 2) is modified with a reference to the descending producer in the calling downline producer's row
fifteen (column of the calling producer of Table 2), a reference of the producer of dependence determination (reference column for the determination of the dependence of the proouctor of Table 2), a link mode (established according to column of the link mode of Table 2) and an adherent indicator established to indicate adhesion. In this respect, the situation of a non-ascending declared subscription that is handled is a similar way to the adherent subscription.
twenty In block 1640, the producer is marked as not executed and control passes to block 1645. With reference to the embodiment of the invention in Figure 11C, the marking column of incremental execution 1180 of the corresponding row is filled in with An indication not executed.
25 In block 1645, it is determined whether the producer has any dependency and is not annulled. If so, the control goes to block 1650, otherwise, the control goes to block 1665. Block 1645 is carried out by checking the dependency declaration in the access control block 1620 and the type column of Call from Table 2.
30 In block 1650, for each dependency in the declaration of the dependency of the producer to be resolved now, the number of producers is determined and a new command of the producer is invoked for each. From block 1650, control passes to block 1655. Different embodiments of the invention determine the different types of dependency at different times, the embodiment of block 1650 is an exemplary embodiment of the invention that will be described later in this document.
35 In block 1655, the producer is added to the execution start record if all the dependent producers exist and have been executed. From block 1655, control passes to block 1660. When, by a given producer instantiated as part of the current iteration of this flow, block 1655 is then performed, the invocation of another iteration of this flow to a producer, the given dependent producer will return the execution status of that
40 producer (see block 1660) (for example, with respect to the embodiment of the invention of Figure 11C, the status of the marking column of the incremental embodiment 1180 of the corresponding row (s). all dependent producers exist and the execution status of all dependent producers is executed, then the producer of the current iteration is added to the start of execution record.
Four. Five In block 1660, the producer execution status is returned as a parameter.
In block 1670, similar to block 1635, the producer is linked to the producer's graph (s) if called by a dependency. From block 1670, control passes to block 1675. Block 1670 can be reached for a variety of reasons. For example, block 1670 can be reached because the producer creates an instance
fifty which previously responds to a producer cancellation command, but not linked in the producer graph. As another example, block 1670 can be reached because the producer is already part of a graph of the producer and is added to another (for example, in response before the instance that is a producer of interest, a progeny of a producer of interest, etc.)
55 In block 1675, it is determined whether the new producer flow is called due to a cancellation, an adherent subscription dependency, or a dependency declared ascending without subscription. If so, the control goes to block 1680, otherwise, the control goes to block 1660. Block 1675 carries out the control of the call type column of Table 2 to see if it is a call for a cancellation producer, an adherent subscription dependency, or a non-subscription dependency declared ascending.
In block 1680, similar to block 1640, the producer is marked as not executed and control passes to block 1665. Block 1680 can be reached for a variety of reasons.
In block 1665, the producer is added to the execution start record, if it is not already present, and control 65 goes to block 1660.
In response to a producer override command (block 1690), the control goes to block 1695. In block 1695, the producer is marked as not overridden and the control goes to block 1640. With reference to the embodiment of the invention of Figure 11C, the output producer's cache and the output indication column of the cancellation producer 1170 of the producer row are accessed and altered to indicate that the producer is no longer canceled. Continuing with this flow, block 1640 would give rise to block 1645, and if the producer had any dependency, block 1650, which would cause the producer's graph under the producer to be discovered and built, if it was not already. If the graph of the producer under the producer is already discovered and built, then the invocation of the new command of the producer will result in flows ranging from 1600 to 1605, to 1670, and so on, in addition, the return of the state of execution of graph producers in the framework of
10 producer in block 1660 will determine if the producer is added to the start-up record in block 1655. However, if the graph of the producer under the producer is not discovered and constructed, then the invocation of the new command of the Producer will result in discovering and building flows ranging from 1600, to 1605, to 1610, and so on.
fifteen Figure 17 is a flow chart for block 1650 of Figure 16 according to an embodiment of the invention. Therefore, the control flows from block 1645 to block 1700 in block 1650. In 1700, by categories, for each dependency on the producer's dependency declaration (one for each ArgumentOpendency, FieldOependency, SequencingOependency, UpwardOependency and WeaklyConstrainedOependency), The following blocks 1705-1745 are carried out. With reference to figures 10
twenty And 110, the monitoring structure of the method is accessed to determine the information related to the producer's dependence. It should also be understood that blocks 1715, 1725, 1730, 1740, 1745 and 1750 are an optimization when performed prior to the execution of the producer's graph.
In block 1705, it is determined whether the dependency is a linked dependency argument already due to a
25 adherent dependence. If so, the control goes to block 1710 where the flow is completed for this dependence, otherwise, the control goes to block 1715. Regarding the embodiment of the invention shown in Figure 11C, the adherent indicator is checked to determine whether the argument of this dependency is subject to an argument dependency of its adherent encryption or an argument dependency declared ascending.
In block 1715, it is determined whether the dependency is a contingent dependency. If yes, the control goes to block 1720, otherwise, the control goes to block 1725. Block 1715 is carried out by checking the producer's dependency determination of the descending producer identified by the agency to determine if it is empty (the descending producer is an independent producer). Regarding 35 figures 13A-J, this would be true for producers with numbers surrounded by dashed lines (for example, in figure 130, producer CU :: IV :: OEL TA), but not true for the others producers (for example, in figure 130, producer CW :: IY :: BETA). Thus, with reference to Figure 130, block 1715 is represented by a circle 1,4, and 8. Block 1715 and the flow therefrom through blocks 1725-1750 is an optimization that avoids the addition / linking with the producers of the numbers surrounded with dashed lines of the graph of the
40 producer, as well as dividing the work of the executing producers between the generation of the graph of the automated producer and the execution of the graph of the producer.
In block 1720, a new producer command for the dependency determination producer is invoked and the flow ends. For example, with reference to Figure 130, block 1720 causes what is represented
Four. Five 5,6, and 7.
In block 1725, the dependency determination producer is executed and control passes to block 1730. For example, with reference to Figure 130, block 1725 is represented by a circle 11 (hence, the flow of the Figure 17 illustrates the previously described embodiment, in which a circle 9 and 10 of Figure 130 is not
fifty perform).
In block 1730, it is stopped if the dependency is a dependency without subscription. If so, the control goes to block 1750, otherwise the control goes to block 1740. In other words, in block 1725, the producer dependency stop code in the dependency stop producer method, what
55 It is part of the declaration of dependence on the producer of the parent producer, it is executed. Once this code for the determination of the producer's dependence has been executed, whose code would identify whether it is determined that this dependence is a subscription dependence, the type of producer's dependence on the parent producer. With respect to the example in Figure 130, circle 11 would result in the flow of Figure 17 passing from block 1730 to block 1750.
60 In block 1750, the number of producers returned by the producer's dependency determination in block 1725 is stopped and a new producer command is invoked for each one, using the arguments described in Table 2, including the reference of the dependency determination producer executed in 1725. For example, with reference to Figure 130, block 1750 would cause circulations 12
65 and 13 And you circulate C and D.
With reference to the example of absorbent subscription of Figure 148, block 1725 represents a circle 4; which causes the flow to pass through block 1730 to block 1740.
In block 1740, the subscription is added to the subscription record, and if the subscription is absorbed, it will be marked
5 as incomplete From block 1740, control passes to block 1745. With reference to the embodiment of the invention shown in Figure 14A, the subscription record is filled in with the subscription as previously described.
In block 1745, all instances of the producers are analyzed to see if they match the criteria of the subscription (and therefore, it is an activation producer), and the matches are processed.
Figure 18 is a flow chart for block 1745 of Figure 17 according to an embodiment of the invention. Therefore, control flows from block 1740 to block 1800 to block 1745. In block 1800, for each instantiated producer, the following blocks 1810-1830 are carried out.
In block 1810, it is determined whether the producer meets the subscription criteria. If so, the control goes to block 1815, otherwise, the control goes to block 1830, where the flow ends for the producer being processed. With reference to the embodiments of the invention shown in Figures 11C and 14A, the graph (s) of the producer are agreed to determine if the producers that meet the subscription criteria are included.
The way to process a matching producer depends on the type of subscription being processed. With reference to block 1815, if the subscription is of the absorption type, control passes to block 1825, otherwise, control passes to block 1820. Block 1815 is made sensitive to the type of subscription added in block 1740 or 2235 .
25 In block 1825, the matching producer is added to the subscription register and the producer with the absorption subscription is related to the corresponding producer. From block 1825, control passes to block 1830. With reference to the embodiments of the invention shown in Figures 11C and 14A-8, the following is done: 1) the subscription criteria from the subscription criteria for the column of activation producers 1410 is used in block 1810 and a matching producer was located (for example, one of producers 1460A-N), 2) the matching producer is added to the matching producer column 1415 in the subscription row, and 3) the producer with the absorption subscription (for example, producer 1450) is linked to the matching producer (for example, one of the producers 1460A-N) in the structure of the producer graph (s) of Figure 11C (using the producer determination reference taken from the column of
35 Reference of dependency determination producer 1421 of subscription registration 14A for the given absorbent subscription).
In block 1820, a new producer command is invoked for the parent producer to be created. From block 1820, control passes to block 1830 where the flowchart ends for the current producer selected in block 1800. With reference to the embodiments of the invention shown in Figures 14A and 14C, the following is performed: 1) the subscription criteria of the subscription criteria for the column of activation producers 1410 was used in block 1810 and a matching producer was located (for example, producer 1475), and 2) a new producer command is invoked with the parameters in table 2 adjusted as follows: a) call type is the adherent subscription, b) the call producer is the key
Four. Five from the producer of the calling descendant producer (for example, producer 1475); c) called producer is the key of the producer of the parent producer called to create (for example, producer 1480), the producer's key being formed using the parent class, the instance, and the method key from the subscription characteristics adherent for the parent producer to be created (figure 14A, columns 1430, 1435 and 1437) (if the instance key is empty, the instance key of the calling child producer is used), d) the link mode for the called parent producer (Figure 14A, link mode column 1425); and e) the reference of the dependency determination producer is extracted from the reference producer column of the dependency determination 1421 of the subscription registration 14A for the determined adherent subscription.
Figure 19 is a flow chart for block 1630 of Figure 16 according to an embodiment of the
55 invention. Therefore, the control flows from block 1625 to block 1900 to block 1630. Figure 19 is very similar to figure 18. Specifically, blocks 1910, 1915, 1920 and 1930 of figure 19 are identical to blocks 1810 , 1815, 1820 and 1830, while blocks 1900 and 1925 differ from blocks 1800 and 1825. As such, only the difference will be described here.
Block 1900 indicates that the flow is made for each registered Subscription, while block 1800 indicates that the flow is made for each instance producer. Thus, when the flow of Figure 18 focuses on a single subscription and scans all producers, the flow of Figure 19 focuses on a single producer and scans all subscriptions. Block 1925 is the same as block 1825, with the exception that the absorbent subscription is marked
65 as incomplete With reference to the embodiment of the invention shown in Figure 14A, the completed column 1420 in the corresponding row is updated to indicate that it is incomplete.
Figure 20 is a flow chart for blocks 1635 and 1670 of Figure 16 according to an embodiment of the invention. Therefore, the control flows from block 1605 and block 1630 to block 2005 in blocks 1635 and 1670. In block 2005, it is determined whether this iteration of the flow chart of Figure 16 is invoked due to a
5 dependence (for example, from block 1630 (block 1920) or 1650 (blocks 1720, 1750 or 1745/1820) of an earlier iteration). If not, the control goes to block 1640 or 1675 depending on where the flow has been entered (from block 163061605).
In block 2010, it is determined whether the flow was called, due to an adherent subscription or situation declared ascending without subscription. If not, the control goes to block 2015, otherwise, the control goes to block 2020. The block 2010 is carried out by checking the parameter of the type of call in Table 2 (that is, if the type of call it is of adherent subscription or without ascending subscription declared or not). With reference to the embodiments of the invention shown in Figures 18 and 19, if the new producer command is invoked from blocks 1820 or 1920.
In block 2020, the current parent producer is linked to the descending producer lIamante. With reference to the embodiments of the invention shown in Figures 11C and 14C, the called parent producer (for example, producer 1480) identified by the parameter from the column of the named producer of Table 2 is related in graph (s) from the producer of the structure of Figure 11C to the calling down producer (for example, producer 1475) identified by the column parameter of the called producer of table 2, using the link mode and the determination of the reference dependence of the producer identified by the link mode parameter and the reference columns of the producers determining the dependence of table 2. If the parent existed previously, the behavior of the block 2020 mimics the breakdown of a dependency of the absorption subscription in the sense that a single argument can be assigned to zero or more producers
25 decendents.
In the 2015 block, the parent producer lIamante is related to the descendant producer called current. With reference to the embodiment of the invention shown in Figure 11C, the parent parent producer identified by the parameter of the column of the producer producer in Table 2 is listed in the graph (s) of the producer of the structure of Figure 11C for the called descending producer identified by the parameter of the called producer column of table 2, using the reference of the dependency determination producer identified by the column of the determination reference producer the dependence of table 2. From blocks 2015 and 2020, control passes to block 1640 or 1675 depending on where the flow has been introduced (from block 1605 or 1630).
35 Figure 21 is a flow chart for canceling the producers according to an embodiment of the invention. With reference to figure 10, the flow of figure 21 is carried out by the annulled producer module 1045 (or, as described with reference to alternative embodiments with respect to figure 10, the module handles the cancellation and reverse cancellation).
In response to a producer override command (block 2110), control passes to block 2120. In block 2120, a new producer command is invoked for the producer identified by the override producer command and passes control to the block 2130. Block 2120 is carried out in an embodiment of the invention in case the producer is annulled has not yet created an instance, as well as to mark the producer as
Four. Five not executed (block 1640 or 1680) and register it in the execution start register (block 1665). An alternative embodiment of the invention that does not allow the cancellation of a producer that is not yet instantiated would be to perform an additional check between blocks 1605 and 1610 to determine if this new command of the called producer responds to a command of the cancellation producer, and indicates an error if this new command from the called producer responds to an order from the override producer.
In block 2130, the output in the producer's output cache (as in the instance, if a field) is set and the producer is marked as voided.
Global Execution Commands
Figure 22A is a part of a flow chart for the execution of the graph (s) of the current producer according to an embodiment of the invention, while Figure 228 is another part of a flow chart for the execution of the graph ( s) of the current producer according to an embodiment of the invention. With reference to figure 10, the flow of figure 22 is carried out by means of the graph execution module of the producer 1070.
In response to a global execution command, block 2200 shows that a set of candidate producers is selected to be executed on the basis of the producers at the start of execution record and control passes to block 2205. In one embodiment of the invention, the annulled producers are marked as not executed and their execution returns their annulled result (as opposed to causing their method to be executed), the current set of the candidate producers are the producers in the start register of execution. Although an embodiment of the invention has been described above in which the annulled producers are marked as
not executed and its execution returns its annulled result (as opposed to causing its method to be executed), alternative embodiments may operate differently (for example, mark the replaced producers as executed and when selecting the current set of candidate proouctors , independent producers are selected from the start-of-execution record and the parents of the producers canceled in the
5 registration of start of execution).
In block 2205, a subset of producers ready for execution is selected from the set of candidate producers and control passes to block 2210. An exemplary embodiment of block 2205 is described later in this document.
In block 2210, the producers of the current set of ready producers are sorted by type - standard producers go to block 2215 and dependency determination probes go to block 2225. In one embodiment of the invention, block 2210 is performed checking the return class of the producer. With reference to Figures 10 and 110, the method tracking structure is accessed to determine if the output class of the
fifteen Producer is EPO, and therefore, this producer is a dependency determination producer.
In block 2215, the standard producers in the current set of ready producers are executed and control passes to block 2220. In one embodiment of the invention, block 2215 is performed by calling the method with any of the input parameters assigned from the outputs of the downstream producers that result in the argument dependencies (for the arguments, the link mode ID argument is use to assign the output of the appropriate producer of the descendant with the appropriate input argument of the method being executed). In some embodiments of the invention, this execution may result in the execution of code in the method of a descendant producer who writes an output in a given mechanism (such as establishing a global variable, establishing a field in an instance that is not the output from the producer, impact a
25 external data source, etc.) or code in the method of the parent producer that reads that output from the given mechanism). In block 2220, for those parents, if any, who have an absorbent subscription in any of these standard executed producers, the subscription is marked as incomplete. From block 2220, control passes to block 2245. With reference to Figure 14A, the corresponding row of completed column 1420 is set to indicate incomplete.
In block 2225, the dependency determination projectors in the current set of ready producers are prepared for execution and control passes to block 2230. An exemplary embodiment of block 2225 is described later in this document.
35 In block 2230, any of the dependency determination producers in the current set of list producers is executed and control passes to block 2235. In one embodiment of the invention, block 2230 is performed similarly to block. 2215
In block 2235, a new producer command is executed by the discovered producers, and the registration of registration and subscription processing is performed. The command part of the new producer of block 2235 is performed similarly to block 1750, while subscription registration and processing is performed similarly to blocks 1740 and 1745.
In block 2240, the set of candidate producers added back to the start register is added
Four. Five of execution. From block 2240, control passes to block 2245. Block 2240 is performed similarly to block 2200, except the only producers newly added in the start-up record as a result of blocks 2230 and 2235 being added to the set of the candidate producers.
In block 2245, the producers that have been executed are marked as executed, the production results cache (and instance caching) are updated when necessary, any of the parent producers of the producers that have been executed are they add to the current set of candidate producers, and the producers that were executed are removed from the current set of candidates and ready producers. From block 2245, control passes to block 2250.
55 In block 2250, it is determined whether the set of candidate producers is empty. If not, the control returns to block 2205, otherwise, the control goes to block 2255.
In block 2255, it is determined that all subscriptions have been completed. If so, the control goes to block 2265 where the flow chart ends, otherwise, the control goes to block 2260. With reference to the embodiment of the invention in Figure 14A, the column of the type of its Specification 1405 and the 1420 full column are scanned for any absorbent subscription that is not terminated.
In block 2260, incomplete absorbent subscriptions are processed and control passes back to block 2205. An exemplary embodiment of block 2260 is described later in this document.
Figure 23 is a flow chart for block 2205 of Figure 22 according to an embodiment of the
invention. Therefore, the control flows from block 2200 to block 2305 in block 2205. In block 2305, for each producer in the set of candidate producers, the following blocks 2310-2325 are carried out.
In block 2310, it is determined whether the producer has any absorbent subscription dependency that is
5 incomplete If so, the control goes to block 2325, otherwise, the control goes to block 2315. With reference to the embodiment of Figure 14A, the column of the subscriber's producer's record 1400 and the column of the subscription type 1405 are analyzed for a match for the currently selected producer and the type of absorption subscription, and if found a match, the completed column 1420 in the corresponding row is checked to determine the status of that absorbent subscription dependency.
In block 2315, it is determined whether the producers on which the selected producer depends are executed. If not, the control goes to block 2325, otherwise, the control goes to block 2320. With respect to the embodiment of the invention shown in Figure 1 1C, the column of incremental execution marks 1180 for the rows of the descendant dependencies are checked to determine the execution status of the descendants of the
fifteen currently selected producer.
In block 2320, the currently selected candidate producer is added to the current set of ready producers and control passes to block 2325.
In block 2325, the flow ends for the produced current selected in block 2305.
Figure 24 is a flow chart for block 2225 of Figure 22 according to an embodiment of the invention. A) Yes. the control flows from block 2210 to block 2405 in block 2225. In block 2405, for each producer of dependence determination, the following blocks 2410-2430 are performed.
25 In block 2410, the type of the previous dependencies generated by the currently selected dependency determination producer is determined. If the type of dependency is without a subscription, then the control goes to block 2420, if the type is suSCripCión absorption, then the control goes to block 2415, while, if the type is adherent subscription, then the control goes to block 2425 . Block 2410 is determined by checking the current producer output stored in the producer's output cache. With reference to the DEP class, the output would be indicated without subscription, absorption subscription, and adherent subscription.
In both blocks 2415 and 2425, the entry is removed from the subscription record. With reference to the embodiment of the invention shown in Figures 14A-C, the following is done: 1) for absorbent subscriptions (block
35 2415), the dependency determination producer (for example, producer 1455) is used to determine its parent producer (for example, producer 1450) in the graph (s) of the producer, and then the parent producer is searched for registration and its entry is withdrawn, and 2) for adherent subscriptions (block 2425), the dependency determination producer (for example, producer 1470) is searched in the subscription register and its entry is deleted. From block 2415, control passes to block 2420; from block 2425, control passes to block 2420.
In block 2420, the currently selected links already created by the dependency determination producer are deleted from the producer graph (s) and the control goes to block 2430. With reference to the embodiment of the invention shown in Figure 11C, The following is done. First it is determined whether the determination producer
Four. Five of the dependency has "adhered" to an existing producer. This is done by scanning the link column of the producer of the descending producer determining dependence in Figure 11C, and checks if one of the links has the adherent indicator indicating adhesion.
If the dependency determination producer has not adhered to an existing producer, then: 1) for a producer determining the dependency that has occurred from the declaring dependencies without subscription (argument, field, or sequence dependencies), the parent of the dependency determination producer is accessed in the producer graph at through the reference column (s) of the parent producer 1150 in the row of the producer of determination of the currently selected unit, and in this entry of the parent producer, the link column (s) of the descending producer 1160 is accessed to coincide with the producer dependency determination reference, and all producer references that have the descendants that the dependency determination producer reference are deleted , 2) for a dependency determination producer that has produced declared dependencies without ascending membership, the parent of the producer of dependency determination is accessed in the producer's graph through the link column (s) of the parent producer 1150 in the producer's row of determination of the dependency selected at that time, and in this entry of the parent producer, the link column (S) of the parent producer 1150 is accessed to match the determination of the producer's reference unit, and all the references of the producers that have the parents that the determination of the producer's reference unit is deleted, and 3) for a producer determining the unit that has produced an absorption subscription, the same dependency behavior is performed 65 descendants declared without subscription, and 4) for a producer determining dependence that an adherent subscription has occurred, The determination of the producer's reference unit is taken from column 1421 of the register.
of subscription 14A before the removal of the subscription is searched in the structure of the producer graph in the link column (s) of the parent producer 1150, and all references of the parent producers that have that dependency determination reference from the producer are deleted.
5 If the dependency determination producer has adhered to an existing producer, as a result of a dependency declared ascending without subscription or an adherent subscription, then the descending producer is accessed to which the dependency determination producer has adhered (the descending producer in column 1160 with an adhesion indicator indicating adherence), and in this entry of the descending producer, The link column (s) of the parent producer 1150 is accessed to match the reference of the dependency determination producer, and all references of the parent producers that have that reference of the dependency determination producer are deleted.
In block 2430, the flow ends for the dependency determination producer selected in block 2405.
Figure 25 is a flow chart for block 2260 of Figure 22 according to an embodiment of the invention. Thus, the control flows from block 2255 to block 2505 in block 2260. In block 2505, for each producer with an incomplete subscription absorption unit, the following blocks 2510-2525 are performed.
In block 2510, it is determined whether all matching producers have been executed. If so, the control goes to block 2515, otherwise, the control goes to block 2525. With reference to the embodiments of Figures 11C and 14A, the matching producer column 1415 is accessed in the corresponding row to determine the comparison producers, and the 1180 incremental execution column in the appropriate rows is checked for
25 Each of the matching producers.
In block 2515, the absorbent subscription is marked as complete and control passes to block 2520. With reference to the embodiments of Figure 14A, the entire column 1420 in the corresponding row is set to indicate complete.
In block 2520, the producer selected in block 2505 is added to the current set of candidate producers and control passes to block 2525.
In block 2525, the flow ends for the producer selected in block 2505.
Method languages
As indicated above, correctly written method language, non-reflective object-oriented language, and non-reflective object-based language code can be transformed into object-oriented reflective language code. As an example, a class can be emulated through a data structure and a set of static functions that have as a first parameter a pointer to an instance of the data structure. Among these functions are the constructor and the destroyer. The constructors are invoked by the execution environment after the assignment of a pointer to a data structure and provide default values for the elements of the data structure, and the destroyers are invoked by the execution environment before the launch of a data structure. Pointer to the data structure. Each class has its description through a file that includes: 1) the data structure, 2) another structure that describes the class, maintaining the size of the structure and a set of function pointers, 3) a list of static functions, with its code (for non-reflective object-oriented languages and languages based on non-reflective objects, the code of static functions is generated automatically by exploring methods of the real class, and create for each method a static function that effectively invokes the related method), and 4) annotations at the top of each function (producer dependency statements that support comments), along with its type (constructor, destroyer, property , etc.). In addition to this definition of a class in the language of the method, non-reflective object-oriented, or non-reflective object-based, dynamic invocation is also implemented. Specifically, a compiler generates the initialization code for each class, code that is called once (for the new class module) to: 1) instantiate the structure that describes the class, fill in the function pointers with the effective static functions, 2) register the instance of this structure with a class map (the class tracking structure) with a key corresponding to the name class, and 3) register all pointers with functions in a function map (the method tracking structure), with a key corresponding to the name of the function (together with ArgumentDependencies, SequencingDependencies, FieldDependencies, upwardDependencies, WeaklyConstrainedDependencies, class exit key and additional annotations). The assignment allows implements in the execution environment of generic invocation functions capable of: 1) instantiating an instance of a class by name (for example, the new instance module) (specifically, the execution environment: a) allocates memory based on the size of the data structure, and adds a header to the pointer to store a pointer to the structure that describes the class, and therefore, implements pointers
65 smart (for example, pointers that can check their types), and b) invoke the appropriate constructor functions after the retrieval of the corresponding pointer in the static map function), and 2) invoke a method by name providing that all parameters are they pass correctly after the retrieval of the pointer corresponding to the static map function. The correct step of the parameters of the functions indicated by the pointers to the functions is done through the assembly language, pushing and popping the elements from the stack of the input and output parameters. The method described above
5 it assumes the existence of the notion of data structures and the existence of the notion of function pointers in the language of the method, based on non-reflective objects or non-reflective object oriented.
Syntax Source code oriented to sample objects
A. Customer code
In one embodiment of the invention, the client code takes the following syntax (shown as a header):
fifteen ProducerKey
New (String ClassKey, InstanceKey InstanceKey, String MethodKey); Runtime NewO AddProducerOflnterest (ProducerKey ProducerOflnterestKey);
SetProducerOutput (ProducerKey ProducerToOverndeKey, Object
ProducerOutpullnstance); Execute O; ProducerKey and Runtime are classes, while New, AddProducerOflnterest, SetProducerOutput, and Execute are methods. AddProducerOflnterest causes the invocation of the new producer command with the appropriate values for the producer of the situation of interest in Table 2. ProducerOutpullnstance is an instance of the class of
25 exit of the canceled producer. Thus, it is instantiated through the constructor of the output class of the corresponding producer.
B. Declarations
1. Dependency Declaration Syntax
argumentDependency = ~ Argument1Dependency; Argument2Dependency;
fieldDependency = ~ FieldDependency1; FieldDependency2; .. ~; sequencingDependency:
35 "SequencingDependencyl; SequencingDependency2; ... ~; upwardDependency = ~ UpwardDependencyl; UpwardDependency2; ..."; weeklyConstrainedDependency =
'WeeklyConstrainedDependency 1; WeeklyConstrainedDependency2; ... "; unConstrainedDependency = "a ConstrainedDependency 1; a ConstrainedDependency2;
two. Dependency Syntax
Four. Five to. Syntax fieldDependencyX seguencingDependencyX upwardDependencyX weeklyConstrainedDependencyX unconstrainedDependencyX: # C: 'ClassKey' :: # 1: 'InstanceKey' :: # M: 'MethodKey'
b. AraumentXDependency syntax: ArgumentID :: # C: 'ClassKey' :: # 1: 'InstanceKey' :: # M: 'MethodKey'
In one embodiment of the invention, the ArgumentlO is omitted in the syntax, and the order in which the argumentDependencies have declared represents the ArgumentlD. ArgumenllD is thus added to improve readability.
55 3. Direct access and no direct access
The syntax is the same as for a non-shortcut, but the use of # S: before the producer key indicates a shortcut.
<dl><dt>to. </dt><dd>Syntax fieldDependencyX seguencingDependencyX upwardDependencyX weeklyConstrainedDependencyX the aConstrainedDependencyX: # S :: # C: 'ClassKey' :: # 1: 'InstanceKey' :: # M: 'MethodKey' </dd></dl>
<dl><dt>b. </dt><dd>ArgumentXDependency syntax: ArgumentID :: # S :: # C: 'ClassKey' :: # 1: 'InstanceKey' :: # M: 'MethodKey' </dd></dl>
In this case, the producer's key indicated by the agency is not a producer's dependency determination.
Other syntax implementations may assume that the shortcut is the default dependency for a given type of dependency (such as field), and omit the #S :: In that case, a # DDP can be used to
<dl><dt>Indicate the presence of a DDP. </dt><dd /></dl>
<dl><dt>Four. Quotas and non-quotas </dt><dd /></dl>
<dl><dt>As already described, a <P> can be placed before a contingent element. </dt><dd /></dl>
<dl><dt>to. Class example and contingent method:</dt><dd /></dl>
<dl><dt>eleven Syntax fieldDependencyX seguencingDependencyX weeklyConstrainedDependencyX unConstrainedDependencyX: # C: <P> 'ClassDeterminationMethodKey' :: # 1: 'InstanceKey' :: # M: <P> 'MethodDeterminationMethodKey' 2) Syntax argumentXDependency ArgumentID :: # C: :: # 1: 'InstanceKey' :: # M: <P> 'MethodDeterminationMethodKey' </dt><dd>upwardDependencyX </dd></dl>
<dl><dt>b. Example of contingent method</dt><dd /></dl>
<dl><dt>eleven Syntax fieldDependencyX seguencingDependencyX weeklyConstrainedDependencyX unConstrainedDependencvX: # C: 'ClassKey' :: # 1: 'InstanceKey' :: # M: <P> 'MethodDeterminationMethodKey' 2) Syntax argumentXDependency: ArgumentID :: # C: 'ClassKey':: ClassKey ': 'InstanceKey' :: # M: <P> 'MethodOeterminationMethodKey' </dt><dd>upwardDependencyX </dd></dl>
<dl><dt>c. Example of contingent instances</dt><dd /></dl>
<dl><dt>1) Syntax fieldOeoendencyX seguencingDependencyX weeklyConstrainedDependencyX unConstrainedDependencyX: # C: 'ClassKey' :: # 1: <P> 'InstanceOeterminationMethodKey' :: # M: 'MethodKey' 2) Syntax araumentXOependency ArgumentlO :: # C: Class #Key # 1: # C: Class 1 : <P> 'InstanceDeterminationMelhodKey': # M: 'MethodKey' </dt><dd>upwardDependencyX </dd></dl>
<dl><dt>5. Abbreviation Technique </dt><dd /></dl>
Elements such as the class, the instance, or the method that are considered to be identical to the elements of the parent producers are omitted. This is typically the case with direct access fields. The examples below combine the abbreviation technique and an abbreviation statement (the shortcut is illustrated with a # S: :)
to. Example in which class and instance are omitted
1) Syntax of fieldOependencyX, sequencingOependencyX, upwardOependencyX, weeklyConstrainedOependencyX, aConstrainedOependencyX: # S :: # M: 'MethodKey' 2) aroumentXOependency syntax: ArgumentID :: # S :: # M: 'MethodKey'
b. Example in which class is omitted
eleven Syntax of fieldDependencyX sequencingDependencyX upwardDependencyX weeklyConstrainedOependencyX unConstrainedOependencyX: # S :: # 1: 'InstanceKey' :: # M: 'MethodKey' 2) argumentXOependency syntax: ArgumentlD :: # S :: # 1: 'InstanceKey' :: # M: 'MethodKey'
Alternative realizations
Although the flowcharts in the figures show a particular order of the operations performed by certain embodiments of the invention, it should be understood that such an order is an example (for example, alternative embodiments can perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
Although the invention has been described in terms of various embodiments, those skilled in the art will recognize that the invention is not limited to the described embodiments, it can already be practiced with modifications and alterations.
5 within the scope of the appended claims. The description, therefore, should be considered as illustrative rather than limiting. Several examples are indicated in the following numbered paragraphs (NPs).
NP1. Apparatus for executing an object-oriented code, said apparatus comprising
an execution environment (355, 360, 1004) that interprets producer dependency statements (320, 1016) for methods in object-oriented code, identifying said producer dependency statements in an execution environment a set of zero or more producers, where a producer (110) is an instantiable construction of an execution environment, which includes at least one particular instance (108) and a
fifteen method (104) associated with that instance (108), including the execution environment an automated graph generation module of the producer (340, 365, 1040) to receive a designation of a producer of interest (325, 1025), to add the producer of interest as part of a producer graph, and to automatically generate a remainder of the producer graph through linking, and instantiation if necessary, from other producers on the basis of the producers' dependency statements on the methods of the producers that are already in the producer's graph; and a producer graph execution module (345, 370, 1070) to execute the producers in the producer graph in the order indicated by the producer graph, where the execution of each producer results in the method of the producer being executed at the instance of the producer.
NP2. Apparatus according to NP1, where said module of automated generation of the graph of the producer initially
25 it may not be able to complete the producer's graph generation until some producers of the producer's graph are executed, and where said producer's graph execution module may invoke the producer's automated generation module with the outputs of the producers necessary during the execution of the producer graph to complete the unresolved remainder of the producer graph.
NP3 Apparatus according to NP1, where the set of producers that were identified in the execution environment by at least one of said declarations of dependence of the producers (106) includes at least one producer that is executed before the execution of the producer (112 ) which includes the method of that producer dependency declaration.
35 NP4. Apparatus according to NP1, where said producer graph represents an adequate sequence of execution identified by the producer dependency statements of the producer methods in the producer graph.
NP5. Apparatus according to NP1, where the set of producers that were identified in the execution environment by at least one of said declarations of dependence of the producers (106) for a given method includes at least one producer (112) with an output that It is a direct entry for the given method.
NP6. Apparatus according to NP1, where the graph of the producer represents the direct entry to the outgoing dependencies of the producers from each other from the producer of interest to those of the producers that are end nodes
Four. Five from the producer’s graph.
NP7. Apparatus according to NP1, where the execution environment also includes:
an output module of the cancellation producer (390, 1045) to receive the current modifications to the output of one or more of the producers of a current version of the producer graph: a structure of the producer graph (380, 1060), coupled to the module of automatic generation of the graph of the producer, to store the current version of the graph of the producer and the current output of each of the producers in the graph of the current producer; and said producer graph execution module, coupled to the cancellation producer output module and the producer graph structure, to make the current modifications, to track the
55 producers in the current version of the producer graph need to be executed because they are indirectly affected by any of the current modifications, and to execute only the producers of the current version of the producer graph that must currently be executed to maintain consistency 65 of the current version from the producer’s graph.
NP8. Apparatus according to NP7, where the structure of the graph of the producer also includes:
an incremental execution marking structure (382, 1080) to assist the producer graph execution module with the monitoring of the producers of the current version of the producer graph to be re-executed, due to any current modification.
NP9. Apparatus according to NP7, which also comprises: an annulment register (396, 1047), coupled to the output module of the cancellation producer and to the execution module of the producer graph, to collect multiple steps for batch processing.
NP10. Apparatus according to NP7, where the output module of the cancellation producer is also to receive 5 indications that one or more canceled outputs must cease to be canceled (1030).
NP11. Apparatus according to NP1, where the execution environment also includes:
a command register (665), coupled to the automatic graph generator module of the producer, to collect 10 multiple commands together for batch processing.
NP12. Apparatus according to NP1, where each method of the producer (112) is a method (104) of a class (102) of that instance of the producer (108).
fifteen NP13. Apparatus according to NP12, where producer dependency statements (106) are part of the class definitions (102) for classes in the object-oriented code (100).
NP14. Apparatus according to NP1, where any method may have one of said producer dependency statements.
twenty NP15. Apparatus according to NP1, where the execution environment replaces the need for a manual invocation sequencing code, and where the method of each of the producers is a transformation method and the execution environment discovers the sequencing of these transformation methods from the declarations of dependence of the producers.
25 NP16. Apparatus according to NP1, where the end nodes of the producer graph are independent producers (PRODUCER 3).
NP17. Apparatus according to NP1, where the execution environment also includes:
an instance tracking structure (1065), coupled to the automatic generator module of the producer graph and the producer graph execution module, to store the references to the producer instances; and a method tracking structure (1058), coupled to the automatic generator graph generation module and the producer graph execution module, to store the references to the methods
35 of producers and information regarding their declarations of dependence on producers.
NP18. Apparatus according to NP17, where the execution environment also comprises: a new instance module (1098), coupled to said instance tracking structure, to receive the designation of and to instantiate, if necessary, the currently selected producer of interest ; an structure
40 class monitoring (1092) to follow references to classes; and a new class module (1095), coupled to the class tracking structure, for loading and for introspection of class definitions.
NP19. Apparatus according to NP1, where the execution environment also includes:
Four. Five a producer graph display module (1062) to graphically display a representation of the current producer graph.
NP2Q Apparatus according to NP1, where the execution environment also includes:
fifty a graphical user interface module of configurable interactive producer output arrangement (1085) to graphically display the outputs from and allow interaction with the producer graph.
NP21 Apparatus according to NP1, where the producer's graph execution module includes:
55 a module of dynamic dependencies (1075) to resolve any dynamic dependency of the producers, where each declaration of dependence of the producers can include a dynamic dependency of the producer, where the dynamic dependencies of the producers make the execution environment dynamically select the set of zero or more producers that the producer dependency declaration identifies during the execution environment, and where dynamic selection can cause the selection of different producers
60 for the whole during different axesCUCiOnes of the producer graph.
NP22 Apparatus according to NP21, where the dynamic dependencies of the producers include contingent dependencies of the producers, where contingent dependencies of the producers are dependencies of the producers of dependency determination (DDP6) that are themselves dependent on the output of one or
65 more than the other producers (S9).
NP23 Apparatus according to NP21, where the dynamic dependencies of producers include subscriptions, where subscriptions identify criteria (1410) by which the producers are compared to determine if they are activation producers, where subscriptions identify dependencies in activation producers.
5 NP24. Apparatus according to NP23, where some of these subscriptions are absorbent subscriptions, where absorbent subscriptions make the execution environment dynamically induce some of the activation producers (1460) in the set of zero or more producers than the producer dependency declaration Identify during the runtime environment.
NP25 Apparatus according to NP23, where some of these subscriptions are adherent subscriptions, where adherent subscriptions also identify the characteristics (1425, 1430, 1435) for the parent producers, and where the adherent subscriptions make the execution environment, for each producer of activation (1475) located, Instance a parent producer (1480) that meets the characteristics identified and includes it in the graph of the producer that has a dependency on the producer in that activation producer.
NP26. Apparatus according to NP1, where some of the zero or more producers are producers of dependency determination (765) whose execution returns the identifications of the dependencies of producers among themselves.
NP27 Apparatus according to NP26, where the execution of some of the dependency determination producers (772) returns the dependencies declared ascending.
NP28. Apparatus according to NP1, where at least some of the dependencies represented by the producer graph are designated as argument dependencies and field dependencies (705), where the argument dependencies make the execution environment assign the outputs of the child producers (725) as parameters of
25 entry to the parent producers (720), and where field units indicate uses of the instance fields.
NP29 Apparatus according to NP1, where at least some of the dependencies represented by the producer graph are designated as sequencing only dependencies (705), where sequencing only dependencies require outputs that need to be provided, where appropriate, from the child producers (746) to the parent producers (720) are produced through the code in the method of the descending producer to write the output in a given mechanism and the code in the method of the parent producer to read that output to from the given mechanism.
NP30 Apparatus according to NP1, where the method keys (1190) are used to distinguish the methods, the instance keys (1120) are used to distinguish the instances, and the producer keys are used to distinguish the producers, where the Producers' key for each producer is based on at least the instance key and the method of that producer's method and method.
NP31 Apparatus according to NP30, where instances are instances of a plurality of classes, where class keys (1090, 1110) are used to distinguish said plurality of classes, and where the producer's key for each producer is also based on the key class class of that instance of the producer.
NP32. Apparatus according to NP30, where the instance key of at least some producers contains a reference to the producer instance.
Four. Five NP33 Apparatus according to NP1, where at least some of these declarations of dependence on producers include dependencies declared ascending (705).
NP34. Apparatus according to NP1, where at least some of these producer dependency statements include descending harrowing units (705).
NP35 Apparatus according to NP1, where at least some of these declarations of dependence on producers include dependencies declared ascending and descending (705).
NP36. Apparatus according to NP1, where said module of automated generation of the graph of the producer is sensitive to the new commands of the producers (1025), and where said module of execution of the graph of the producer is sensitive to executing commands (1035).
NP37. An apparatus for the execution of object-oriented code, said apparatus comprising:
an axle drive environment (355, 360, 1004) that interprets producer dependency statements (320, 1016) for methods in object-oriented code, identifying those producer dependency statements in an execution environment a set of zero or more producers, when a producer (110) is an instantiable execution environment construct that includes at least one instance (108) and a method (104) associated with that instance, where the method of each producer is a method of a class (102) of that instance 65 of the producer, where the producer dependency declarations (106) are part of the class definitions for the classes in the object-oriented code, and where at least some of those statements of
producer dependencies include dependencies declared down (705), including the execution environment, an automated graph generator module (340, 365, 1040) to receive a designation of a producer of interest, to add the producer of interest ( 325, 1025) as part of a current producer graph, and
5 to automatically generate a remainder of the current producer graphs through linking, and creation of instances as necessary, from other producers based on the producer dependency statements of the producer methods that are already in the producer graph current, a producer graph structure (380, 1060), coupled to the automated producer graph generation module, for the current producer graph and a current output of each of the producers in the current producer graph, where the method keys (1190) are used to distinguish the methods, the instance keys (1120) are used to distinguish cases, and producer keys are used to distinguish producers, and where the producer key for a given producer is based on at least the instance key and the instance method key of that producer and method; and a producer graph execution module (345, 370, 1070), coupled to the producer graph structure, to execute the producers of the
fifteen current producer graph in the order indicated by the current producer graph, where the current producer graph represents an appropriate sequence of execution identified by producer dependency declarations of producer methods in the current producer graph, and in the execution of each of the results of producers in the production method that is being executed in the instance of the producer, including said producer graph execution module, a dynamic dependency module (1075) to resolve the dynamic producer dependencies, where each producer dependency declaration can include a dynamic producer dependency, where the dynamic producer dependencies make the As an execution, dynamically select the set of zero or more producers, and the producer dependency declaration is defined during the execution environment, where dynamic selection can cause the selection of different producers for the set during
25 the different executions of the current producer graphs, where the dynamic producer dependencies include contingent producer dependencies, and where the contingent producer dependencies are dependencies of the dependency determination producers (DDP6) that are themselves dependent on the output from one or more other producers (S9).
NP38. The NP37 apparatus, where the execution environment also includes:
a producer graph viewer module (1062) to graphically show a representation of the current producer graph.
35 NP39. The NP37 apparatus, where the execution environment further comprises:
an interactive configurable module of producer output distribution of the graphical user interface (1085) to graphically display the outputs from and penetrate the interaction with the current producer graph.
NP40 The NP37 apparatus, where the dynamic dependencies of the producer includes the subscriptions, where the subscriptions identify criteria (1410), by which the producers are compared to determine if they are shot producers, where the subscriptions identify the dependencies of shot producers.
NP41. The NP40 apparatus, where some of these subscriptions are absorbent subscriptions, where the
Four. Five Absorbent subscriptions make the execution environment dynamically include any trigger producers (1460) in the set of zero or more producers reporting producer dependencies identified during the execution environment.
NP42. The NP40 apparatus, where some of these subscriptions are adherent subscriptions, where adherent subscriptions also identify characteristics (1425, 1430, 1435) for the parent producers, and where the adhesive subscriptions cause the execution environment, for each trigger producer ( 1475) located, at the request of a parent producer (1480) according to the characteristics identified and includes it in the current producer graph.
55 NP43. The NP37 apparatus, where some of the producers are dependency custody producers
(772) whose execution returns identifications of the dependencies of the producers among themselves.
NP44. The NP43 apparatus, where the execution of some of the dependency determination producers
(772) returns dependencies declared up.
NP45 The NP37 apparatus, where at least some of the producer dependency statements include one or more of an argument dependency and a field dependency (705), where the argument dependencies cause the execution environment to assign outputs from child producers (725) as input parameters to the parent producers (720), and where the dependencies field indicates uses of the instance fields.
NP46. The NP37 apparatus, where class keys (1090, 1110) are used to distinguish classes, and where the
Producer code for each producer is also based on the class code of the instance of that producer.
NP47. The NP37 apparatus, where the instance key of at least some producers contains a reference to the producer instance.
NP48. The NP37 apparatus, where said automated producer graph generation module receives multiple denominations of producers of interest and automatically generates multiple graphs of current producers, and where said producer graph execution module responds to execute global commands (1035) that each makes all current producer graphs run.
NP49. Method for the execution of object-oriented code, said method comprising:
instantiate a producer with an output that is currently of interest (645), where the object-oriented code includes methods (104) and producer dependency statements (106), where the producer's dependency declaration of a particular method identifies a set of zero or more producers, where a producer (110) is an instantiable execution environment construction, which includes at least one instance (108) and a method associated with that instance; sensitive to that instance, add the producer of interest as part of a graph of the current producer (645); try to automatically generate a remainder of the current graph of the producer through the linking and instantiation as necessary, of other producers on the basis of the producer dependency statements of the methods of producers that are already in the current graph of the proouctor and execute the producers in the current graph of the proouctor to determine the current output for said producer of interest (660).
NP50 Method according to NP49, where said automatic generation attempt also includes:
try to discover and build automatically, from declarations of dependence of the producers in said object-oriented code, the current graph of the producer that represents the relationships of the input to the direct output of the producers necessary to generate a current value of the set of one or more inputs to the producer of interest, Where a current output of each of the producers in the graph of the current producer is a direct entry to another or more of the producers in the graph of the current producer and / or the producer of interest.
NP51. Method according to NP49, where said execution of the producers in the graph of the current producer also includes: automatically generating additional parts of the graph of the current producer through the execution of some of the producers of the graph of the current producer that return the identifications of the dependencies of other producers in each one to be added to the graph of the current producer.
NP52. Method according to NP49, where said execution includes:
resolve any dynamic producer dependencies (665), where each producer dependency declaration can include a dynamic producer dependency, where the dynamic producer dependencies make the execution environment dynamically select the set of zero or more proctors that the producer dependency statement identifies during the execution environment.
NP53 Method according to NP52, where the dynamic dependencies of the producers include contingent dependencies of the producers, where the contingent dependencies of the producers are dependencies of the producers of dependency determination (OOP6) that by themselves are dependent on the output of one or more than the other producers (89).
NP54 Method according to NP52, where the dependencies of the dynamic producers include subscriptions, where the subscriptions identify criteria (1410) by which the producers are compared to determine if they are activation producers, where the subscriptions identify the dependencies of the activation producers.
NP55 Method according to NP54, where some of said subscriptions are absorbent subscriptions, where absorbent subscriptions cause the dynamic inclusion of any activation producers (1460) in the set of zero or more producers that identifies the producer's dependency declaration.
NP56 Method according to NP54, where some of these subscriptions are adherent subscriptions, where the adherent subscriptions also identify the characteristics (1425, 1430, 1435) for the parent producers, and where the adherent subscriptions cause, for each of the activation producers (1475 ) located, the instantiation of a parent producer (1480) that meets the characteristics identified and its inclusion in the current graph of the producer that has a dependency on the producer on that activation producer.
NP57. Method according to NP49, where said automatic generation attempt also includes: instantiating any instance of producers that have not yet been instantiated (645, 1560), and instantiating producers that have not yet been instantiated (645, 1625).
NP58 Method according to NP49, where said automatic generation attempt also includes:
load any classes of the instances of the producers that have not yet been loaded (1540), and perform the introspection of the class definitions of the classes in which the introspection has not yet been performed (1550), including the dependency statements of the producers contained therein.
NP59 Method according to NP58, where said automatic generation attempt includes:
discover and build in the graph of the current producer one of the producers for whom the class of the instance identified by the producer has already been loaded and introspection has been made before said attempt (1530), the producer instance has already been instantiated before said attempt (1520), and the producer was already instantiated before said attempt (1605).
NP60 Method according to NP49, which also includes:
graphically show a representation of the graph of the current producer.
NP61 Method according to NP49, which also includes:
graphically show the outputs from and allow interaction with the graph of the current producer.
NP62. Method according to NP49, which also includes:
store a current output of the producers from the current graph of the producer; cancel the current output of one or more of the producers of the graph of the current producer (625), and re-execute, according to the current graph of the producer and the cancellation and the current stored output of those of the producers who are not directly or indirectly affected by said cancellation, only those of said producers that are affected, directly or indirectly, by said cancellation to determine their current output (660).
NP63. Method according to NP62, where those of said producers that are affected are not all producers in the current graph of the producer.
NP64 Method according to NP62 which also includes:
reverse the annulment (1690); and re-execute, according to the current graph of the producer, and reverse cancellation and the current stored output of those of the producers that are not directly or indirectly affected by said reverse cancellation (660), only those of the producers that are affected , directly or indirectly, by said reverse cancellation to determine its current output.
NP65 Method according to NP49, where at least some of the dependencies declared by the producer dependency declarations are designated as argument dependencies and field dependencies (705), where the argument dependencies cause the assignment of the outputs of the child producers ( 725) as input parameters to the parent producers (720), and where the field dependencies indicate the uses of the instance fields.
NP66. Method according to NP49, where at least some of the dependencies declared by the producer dependency declarations are designated as sequencing only dependencies (705), where sequencing only dependencies require outputs that need to be provided, where appropriate, from child producers (746) to the parent producers (720) that are produced by code in the descending producer's method to write the output to a given mechanism and the code in the parent producer's method to read that output from the mechanism dice.
NP67. Method according to NP49, where the keys of the method (1190) are used to distinguish the methods, the instance keys (1120) are used to distinguish the instances, and the keys of the producers are used to distinguish the producers, where the key of the Producer for a given producer is based on at least the instance key and the instance method key and the producer method.
NP68. Method according to NP67, where instances are instances of a plurality of classes, where class keys (1090, 1110) are used to distinguish said plurality of classes, and where the producer key for each producer is also based on the key of class of the instance class of that producer.
NP69. Method according to NP67, where the instance key of at least some of the producers maintains a reference to the producer instance.
NP70 Method according to NP49, where at least some of these producer dependency statements include ascending harrowing units (705).
NP71. Method according to NP49, where at least some of these producer dependency statements include descending harrowing dependencies (705).
NP72. Method according to NP49, where at least some of these declarations of dependence on producers include dependencies declared ascending and descending (705).
NP73 Method according to NP49, where said instance is made sensitive to a new producer command (1025) and said execution is made sensitive to a global execution command (1035).
NP74. A method for the execution of object-oriented code, said method comprising:
receiving an indication from a producer of interest (615, S1), where a producer (110) is an instantiable construction of an execution environment that includes at least one instance (108) and a method (104) associated with that instance; automatically generate and execute a producer graph based on said producer of interest and the producer of dependency declarations for the methods (645), where said producer graph includes a destination subgraph (S1, S2, S3, 84, S7, S8) which includes said producer of interest and a plurality of levels of other producers, including said generation and execution, iteratively perform the following until source producers are reached (S7, S8) automatically, discover, build and execute a producer decision subgraph (DDP1) based on the establishment of producer dependency declarations of the method of one of the producers in the destination subgraph (S1), and add to said destination subgraph a set of one or more of the other producers returned by said decision subgraph (S2), and execute the producers in the sequenced destination subgraph as indicated by the destination subgraph (660), where the execution of each of the results of the producers in the method of the producer is being executed in the instance of the producer.
NP75 The NP74 method, where at least one producer (S10) is part of the target sign and one of the decision subgraphs.
NP76. The NP74 method, where a first of the decision subgraphs includes a root that is a dependency determination producer (DDP6) and includes nodes, at least some of which are standardized producers (S9).
NP77 The NP74 method, where the target subgraph has a root that is a standard producer (S1).
NP78. The NP74 method, where at least one of the decision subgraphs returns a subscription.
NP79. The NP78 method, where the subscription is an absorbent subscription that indicates the absorption of the subscription criteria (1410) for the shooting producers (1460).
NP80 The NP78 method, where the subscription is an adherent subscription (DDP9) that indicates the adherent subscription criteria (1410) for the shooting producers (1475) and the adherent subscription characteristics (1425, 1430, 1435) for a parent producer (1480) to be created.
NP81. The NP74 method, where at least one of the decision subgraphs returns a producer dependency declared up (DDP4).
NP82. The NP74 method, where at least some of the producer dependency declaration instructions identify one or more of an argument dependency and a field dependency (705), where the argument dependencies make the assignment of the outputs of child producers (725) as input parameters for parent producers (720), and where field dependencies indicate uses of instance fields.
NP83. The NP74 method, where the method keys (1190) are used to distinguish the methods, instance keys (1120) are used to distinguish the cases, and the producer keys are used to distinguish the producers, where the producer key for each producer it is based on at least the instance key and the instance method key and the method of that producer.
NP84. The NP83 method, where instances are instances of a plurality of classes, where class keys (1090, 1110) are used to distinguish said plurality of classes, and where the producer key for each producer is also based on the key class of the instance class of that producer.
NP85 The NP83 method, where the instance key of at least some producers contains a reference to the producer instance.
NP86 The NP74 method, which also includes:
graphically show a representation of the producer graph.
NP87. The NP74 method, which also includes:
graphically show outputs from and penetrating the interaction with the producer graph.
NP88. The NP74 method, which also includes:
the reception of an execution command after said receiving the indication of the producer of interest and before said automatic generation and execution.
NP89. An apparatus for the execution of object-oriented code, said apparatus comprising:
an execution environment (355, 360, 1 (04) to automatically generate and execute a producer graph based on a producer of interest (325) and producer dependency statements for methods (320), where a producer (110 ) is an instantiable execution environment construction that includes at least one instance (108) and one method (104) associated with that instance, said execution environment including the following iteratively related modules, an automated producer graph generation module (340, 365, 1040) to receive a designation of said producer of interest (325), to add said producer of interest to a destination subgraph (81) of said producer graph, and Automatically generate a plurality of the levels of other producers (82, 87, S8) in the said target symbol by automatically discovering and constructing decision subgraphs (DOP1, ODP 10) based on the instructions of producer dependency declarations of the methods of the producers currently in the destination subgraph, and an axis moduleCooking producer graphs (345, 370, 1070) to execute the producers in the graph of producers, where the execution of each producer results in the method of the producer that is being executed at the instance of the producer, and where the execution of each of a plurality of the decision subgraphs adds at least one other producer to said destination subgraph.
NP90 The NP89 apparatus, where at least one producer (S 10) is part of both the destination subgraph and one of the taking subgraphs.
NP91. The NP89 apparatus, where a first of the decision symbols includes a root that is a dependency determination producer (OOP6) and includes the nodes of at least some of those that are unnalized producers (S9).
NP92. The NP89 apparatus, where the target symbol has a root that is a normalized producer (S1).
NP93. The NP89 apparatus, where at least one of the decision subgraphs returns a subscription.
NP94. The NP93 apparatus, where the subscription is an absorbent subscription that indicates the absorption of the subscription criteria (1410) for the shooting producers (1460).
NP95 The NP93 apparatus, where the subscription is an adherent subscription that indicates the adherent subscription criteria (1410) for the shooting producers (1475) and the adherent subscription characteristics (1425,1430, 1435) to be created a parent producer ( 1480).
NP96. The NP89 apparatus, where at least one of the plurality of decision subgraphs returns a producer dependency declared up (DDP4).
NP97. The NP89 apparatus, where at least some of the producer dependency declaration instructions identify one or more of an argument dependency and a field dependency (705), where the argument dependencies make the mapping of producer outputs son (725) as input parameters for the parent producers (720), and where the field dependencies indicate uses of the instance fields.
NP98. The NP89 apparatus, where the method keys (1190) are used to distinguish the methods, instance keys (1120) are used to distinguish the cases, and the producer keys are used to distinguish the producers, where the producer key for each producer it is based on at least the instance key and the instance method key and the method of that producer.
NP99 The NP98 apparatus, where instances are instances of a plurality of classes, where class keys (1090, 1110) are used to distinguish said plurality of classes, and where the producer key for each producer is also based on the key class of the instance class of that producer.
NP100 The NP98 apparatus, where the instance key of at least some producers contains a reference to the producer instance.
NP101. The NP89 apparatus, where the execution environment also includes:
a producer graph viewer module (1062) to graphically show a representation of the current producer graph.
NP102. The NP89 apparatus, where the execution environment also includes:
a graphical user interface module of interactive configurable producer output distribution (1085) to graphically display the outputs from and allow interaction with the producer graph.
NP103 The NP89 apparatus, where said automated producer graph generation module is sensitive to the new producer commands (1025), and where said producer graph execution module is sensitive to executing commands (1035).
NP104. A machine storage medium that provides object-oriented code including: a plurality of class definitions (102) each including a set of one or more fields, a set of one or more methods (104), and a producer dependency statement (106) for each of said set of methods , where the producer dependency declaration for a given one of such methods is used in the execution environment to identify a set of zero or more producers, where a producer (110) is an instantiable execution construction that includes at least one instance (108) of one of the plurality of classes in execution environment and such a method; and where a first producer (PRODUCER 5) has a dependency on the contingent producer as follows, a first method (1340) of said method sets is a property method, a second method (1315) of said method sets has a declaration of dependencies of the declaration producer (1325) that identifies a producer of goods (CX PRODUCER :: 12 :: GAMMA) based on said property method, and has the code (1330) to select between a second (PRODUCER 7A) and third producer (PRODUCER 7B) based on the output of said property producer, and a third method ( 1305) of these sets of methods has a producer dependency declaration statement (1300) that identifies a dependency determination producer (CW PRODUCER :: IY :: BETA) based on said second method, where said first producer is based on said third method and has a dependency on the producer (1390) where said second and third producer of the dependency determination producer is currently returning.
NP105 The storage medium of the NP104 machine, where:
A fourth producer (1405, 1480) has a subscription unit in a shooting producer (1460. 1475) as follows, a fourth method of said method sets, where said fourth producer is based on said fourth method, a fifth method of said method sets having a code indicating a set of subscription criteria (1410) for shot producers, where a subscription producer (1455, 1470) is based on said fifth method, and a sixth method of said method sets, wherein said trigger producer is based on said sixth method and said subscription dependency is created because said trigger producer meets said set of subscription criteria.
NP106. The NP105 machine storage medium, where said set of subscription criteria is absorbing subscription criteria, and where said fourth method has a producer dependency statement that identifies said subscription producer (1455).
NP107. The storage medium of the NP105 machine, wherein said set of subscription criteria is an adherent subscription criterion, wherein said fifth method also includes a code indicating a set of adherent subscription characteristics (1425. 1430, 1435) for The parent producers. wherein, said trigger producer (1475) meets said adherent subscription criteria, and wherein said fourth producer (1480) meets said adherent subscription characteristics and instances are created as a result of said subscription dependence.
NP108. The storage medium of the NP104 machine, where at least one of said producer dependency statements includes a heavily restricted argument dependency (705).
NP109. The NP104 machine storage medium, where at least one of said producer dependency statements includes a heavily restricted field dependency (705).
NP110. The storage medium of the NP104 machine, where:
a producer quartz (748) has a dependency of the producer on the fifth producer (720) as follows, a fourth method of said sets of methods, wherein said fourth producer is based on said fourth method, a fifth method of said sets of methods that have code that declares a producer dependency upward, and a sixth method of said sets of methods having a producer dependency declaration that identifies a dependency determination producer (772) based on said fifth method, wherein said fifth producer is based on said sixth method and has a producer dependency on said producer of dependency determination that returns the dependence of the producer of the fourth producer on the fifth producer.
NP111. The storage medium of the NP104 machine, where the method keys (1190) are used to distinguish said sets of methods, instance keys (1120) are used to distinguish the cases of said plurality of class definitions, and the keys Producers are used to distinguish producers, where the producer's key for each producer is based on at least the instance key and the instance method key and that producer's method.
NP112. The storage medium of the NP111 machine, where the class keys (1090, 1110) are used to distinguish said plurality of classes, and where the producer key for each producer is also based on the class key of the class of that instance producer.
NP113. The storage medium of the NP111 machine, where the instance key of at least some producers contains a reference to the producer instance.
NP114 A machine storage medium that provides object-oriented code including:
a program that has a plurality of dase definitions (102) including each, a set of one or more fields, a set of one or more methods (104), and a producer dependent statement (106) for each of said set of methods, where the producer dependency declaration for a detainee of such methods is used in an execution environment to identify a set of zero or more producers, where a producer (110) is an instantiable execution environment construction that includes at least one instance
(108) of one of the plurality of classes in execution environment and a method of that class; and where the method of each of the producers is a transformation method and the program does not include manual invocation sequencing code, but instead is based on an execution environment (355, 360, 1004) to automatically discover the sequencing for the transformation methods of producer dependency declarations.
NP115. The storage medium of the NP114 machine, where at least some of said producer dependency statements include a dynamic producer dependency (1300), where the dynamic producer dependencies cause the set of zero or more producers to be dynamically selected during The execution environment.
NP116. The NP115 machine storage medium, where dynamic producer dependencies include contingent producer dependencies, where contingent producer dependencies are dependencies of dependency determination producers (OOP6) that are dependent on the output of one or more more producers (59).
NP117. The NP115 machine's storage medium, where the dynamic dependencies of the producer include the subscriptions, where the subscriptions identify criteria (1 410) by which the producers are compared to determine if they are trigger producers, where the subscriptions are identified. dependencies of shooting producers.
NP118. The storage medium of the NP117 machine, where some of these subscriptions are absorbing the subscriptions, where the absorbent subscriptions cause dynamic inclusion of the trigger producers (1460) in the set of zero or more producers that identifies the dependency declaration of the producers.
NP119. The NP117 machine's storage medium, where some of these subscriptions are adherent subscriptions, where adherent subscriptions also identify characteristics (1425, 1430, 1435) for parent producers, and where adherent subscriptions cause, for each producer of shot (1475) located, the creation of instances of a parent producer (1480) that meets the characteristics and the inclusion thereof in a graph of producers identified as a dependency of the producer of that trigger producer.
NP120. The storage medium of the NP114 machine, where at least some of the dependencies declared by the producer dependency declarations are designated as argument dependencies and field dependencies (705), where the argument dependencies make the mapping of the outputs of child producers (725) as input parameters to the parent producers (720), and where the field dependencies indicate uses of the instance fields.
NP121. The storage medium of the NPl14 machine, where method keys (1190) are used to distinguish methods, instance keys (1120) are used to distinguish cases, and producer keys are used to distinguish producers , where the producer key for a given producer is based on at least the instance key and the instance method key and the method of that producer.
NP122. The storage medium of the NP121 machine, where class keys (1090,1110) are used to distinguish said plurality of classes, and where the producer key for each producer is also based on the class key of the instance class from the producer.
NP123. The storage medium of the NP121 machine, where the instance key of at least some producers contains a reference to the producer instance.
NP124. The storage medium of the NP machine, 114, where at least some of said producer dependency statements include dependencies declared upwards (705).
NP125. A storage medium for the machine that is stored in it:
a set of one or more instances (108, 1052) of a set of one or more classes (102), where each class includes methods (104) and producer dependency statements (106) for the methods, where each of the set of instances is associated with all methods of its class, and where declarations of dependencies of the producer identify in the execution environment a set of one or more dependencies among the producers (110); a producer graph structure (380, 1060) that has a plurality of producers stored therein that each is a construction of an instance in execution and that includes only one of said set of instances and only one of the methods associated with that instance, a plurality of links (1160) representing a multiple level graph of the plurality of producers, where the plurality of links represent the dependencies between the producers in the producer graph identified by the producer dependency declarations for the methods included in the plurality of the producers, a producer key for each of said plurality of producers, where each producer key is based on at least one instance key (1120) and one method key (1190) that identify the one of said set of instances and the one of the methods associated with that instance, and a current output ( 1170) of each of the plurality of producers in the graph of producers; and an instance tracking structure (1065) that has stored in it a correspondence between the instance tedas and the instance set.
NP126. The storage medium of the NP125 machine, where said producer graph structure represents an adequate sequence of execution, signaled by the producer dependency declarations of the producer methods in the producer graph.
NP127. The storage medium of the NP125 machine, where the structure of producer graphs represents the direct entry to the outgoing dependencies of the producers on each other from a producer of interest to those of the producers that are extreme nodes of the producer graph .
NP128. The NP125 machine storage medium, where at least some of the dependencies represented by the producer graph structure are designated as argument dependencies and field dependencies (705, 1160), where argument dependencies make the entamo Executions to the map outputs of child producers (725) as input parameters to the parent producers (720), and where the field dependencies indicate uses of the instance fields.
NP129. The storage medium of the NP125 machine, where at least some of the dependencies represented by the producer graph structure are designated as sequencing only dependencies (705, 1160), where the only sequencing of dependencies requires outputs that need to be provided, if there is, from the child producers (746) to the parent producers (720) are produced through the code in the method of the child producer to write the output to a particular mechanism and the code in the method of the parent producer to read that output from the mechanism determined.
NP130 The storage medium of the NP125 machine, where the producer graph structure also includes:
annul the production output modifications (1170) that store for each of said plurality of producers an indication of whether that producer is canceled and the output value is canceled.
NP131. The storage medium of the additional NP125 machine that is stored in it:
a set of class definitions (1010) written in the object-oriented code for the set of classes in which each of the producer dependency statements (1016) includes a producer dependency statements located next to those of the methods for what it is
NP132. The storage medium of the NP125 machine, where the instance key of at least some producers contains a reference to the producer instance.
NP133. The storage medium of the NP125 machine, in which each producer key is also at least based on a class key (110) that identifies the class of the producer instance.
NP134. The storage medium of the additional NP133 machine that is stored in it:
a representation of the plurality of load classes and introspection during the execution stage (1054), said representation including the results of the introspection of the methods and the producer dependency statements (1056); a class tracking structure (1092) having a correspondence between class keys and the representation of the class set stored therein; and a method tracking structure (1058) that has stored in it a correspondence between method keys and the results of the methods introspection, as well as information regarding the results of the introspection of the producer dependency statements .
NP135. A storage medium of the machine that you have stored in it:
an object-oriented source code (100, 1002, 820) including customer code (824), said customer code, including, a producer instance command having a producer key (1025) (824A) for a producer of interest, and that provokes an entanglement axis (360, 1004, 810) for the Object-oriented code to automatically discover, build, and, optionally, solve a graph of current producers from the producer of interest and that has multiple levels of the discovered producers, where each of the producers (110) is an instantiable construction of an execution environment that includes at least one instance
(108) and a method (104) associated with that instance, where the execution environment creates an ex officio instance none of the producers of the current producer graphs that are not yet instantiated, where the production keys are used to distinguish go producers, where method keys (1190) are used to distinguish methods, in instance keys (1120) are used to distinguish instances, and where the producer key for each producer is based on at least the instance key and the instance method key and the producer method; execute commands (1035, 824C) that each cause the execution environment for object-oriented code to execute the current producer graph and store in memory a current output for each of the producers executed in the current producer graph; and producer exit cancellation commands (1030,8248) that each has a producer key and a replacement value, and that each makes the object-oriented code execution environment to override the producer's output designated by The producer's key with the replacement value.
NP136. The NP135 machine storage medium, where the runtime client also includes:
commands to cancel the producer's output (1030) that each one has the producer's key of one of the producers that has been canceled and that each one causes the execution environment for the object-oriented code to cancel the output of that producer .
NP137. The NP135 machine storage medium, where the producer instance command is a new producer command (1600), and where the producer output overrides the commands are sets of commands (8248).
NP138. The NP135 machine storage medium, where the causal relationship of the producer instance command and producer exit cancellation commands is indirect through a register
(665) maintained by the object-oriented code execution environment.
NP139. The machine storage medium of NP135, where the first of the commands are executed, causes an initial axis and each subsequent one of the axisCUCTION commands causing an incremental execution.
NP140. The NP135 machine storage medium, where the runtime client also includes:
an instance instantiation command (1025) that has the instance key of the producer of interest, and that causes the object-oriented code execution entity to create an instance of the instance of the producer of interest.
NP141. The NP135 machine storage medium, where each set of one or more of the producer output cancellation commands is followed by one of the commands that are executed.
NP142. The NP135 machine storage medium, where class records (1090, 1110) are used to distinguish a plurality of classes from which instances are instances, and where the producer key for each producer is also based on the key class of the instance class of that producer.
NP143. The NP142 machine storage medium, where the instance instantiation command causes the code execution or object-driven environment to create an instance of the producer of interest by accessing the producers' class through a structure of class tracking (1092), using the class key of the producer key of the producer instance command, accessing the producer's instance through an instance tracking structure (1065) using the producer's instance key from the producer's instance command command, and accessing a producer dependency declaration of the producer's method through of a method tracking structure (1058) using the method key of the producer key of the producer instance command.
NP144. The NP135 machine storage medium, where the instance key of at least some producers contains a reference to the producer instance.
NP145. The NP135 machine storage medium, where said customer code also includes:
additional producer instantiation commands that cause the object-oriented code execution environment to automatically discover, construct, and, optionally, solve other graphs of current producers, where each of said execution commands makes said execution environment Object-oriented code execute all graphs of current producers.
NP146. The NP135 machine storage medium, where said object-oriented source code also includes the class definitions (102,1010,824), where said class definitions include the business logic expressed in methods with the producer dependency statements.
NP147. The NP146 machine storage medium, where producer dependency statements define the relationship between producers during the definition of classes that include business logic, rather than after creating instances of those classes.
NP148. A method for the distribution of producer outputs, said method comprising:
show a list that includes the ciases, with their methods of obtaining property (852), of the producers (110) in a graph of producers and of those outputs of the producers, where said graph of producers is automatically generated and executed on the base of a producer of interest (325, 1025) and declarations of dependencies of the producer (320, 1016) for class methods, where a producer is an instantiable construction of the execution environment that includes at least one class, one instance (108) of that class, and one method
(104) of that class that is associated with that instance, in the producer dependency declarations of the methods of the producers in the producers graph, each identifying a set of zero or more of the other producers in the producers graph , where said producer graph includes said producer of interest and a plurality of levels of other producers; display of a spreadsheet that has cells (854); receiving assignments (856, 866) of a plurality of methods of obtaining properties that are shown from a set of one or more of the classes shown in the cells of the spreadsheet; and populate at least the cells of said assignments with the outputs of the corresponding property obtaining methods of a set of one or more instances (858, 868).
NP149. The NP148 method, which also includes:
receive a value for one of the automatically populated cells (860, 870, 625); cancel the output of the producer whose output is currently populating that cell with that value (860, 870, 650); at least incrementally execute the graph of producers and update the cells of said allocation when necessary (860, 870,660).
NP150 The NP148 method, where said population also includes:
receive an indication of selection of the set of one or more instances (854).
NP151. The NP150 method, wherein said reception of an indication of the selection of the set of one or more instances includes the reception of at least one indication of an instance key of one of the series of instances.
NP152. The NP148 method, where said population also includes:
receiving an indication of selection of one of a plurality of filters to be applied to select instances that are at least one first of said set of classes shown (858), where each of said plurality of filters allows selection in a manner different.
NP153. The NP152 method, where said population also includes:
before said reception of the selection indication of one of the plurality of filters, receive an assignment of said first class (PERSON) in one of the cells of the spreadsheet.
NP154. The NP153 method, where said reception of the selection indication of one of the plurality of filters is carried out through the cell of the spreadsheet to which said first class was assigned (858).
NP155. The NP154 method, where said population also includes:
after said reception of the selection indication of one of the plurality of filters, receive a selection indication of one of the instances of the first class using the filter selected through the cell of the spreadsheet for which it was assigned said first class (854).
NP156. The NP155 method, where said reception of the selection indication of one of the instances of the first class further comprises:
receive an indication of the instance key of one of the instance set.
NP157. The NP148 method, where said population also includes:
receiving an indication of an area of the definition of a table (864), where said table includes a plurality of rows and columns of cells in the spreadsheet; where said reception of assignments (866) is carried out in a group of cells at one edge of the table; populate the group of cells on the edge with the outputs of the corresponding property obtaining methods of a first instance of a first of said set of classes shown (868); and iteratively populate each adjacent group of cells that have the same orientation until the opposite edge of the table is reached with the outputs of the corresponding property obtaining methods of another instance of said first class (868).
NP158. The NP148 method, where at least one of the producer dependency statements includes a dynamic producer dependency (1300), where dynamic producer dependencies cause a dynamic selection of the set of zero or more producers from the producer dependency declaration identified during the execution environment.
NP159. The NP158 method, where the dynamic producer dependency is a contingent producer dependency, where the contingent producer dependencies are dependencies of the dependency determination producers (DDP6) that are themselves dependent on the output of one or more of other producers (S9).
NP160. The NP158 method, where the dynamic producer returns a subscription.
NP161. The NP160 method, where the subscription is an absorbent subscription that indicates the absorption of the subscription criteria (1410) for the shooting producers (1460).
NP162. The NP160 method, where the subscription is an adherent subscription that indicates the adherent subscription criteria (1410) for the shooting producers (1475) and the adherent subscription characteristics (1425, 1430, 1435) for the parent producer (1480) to create.
NP163. The NP148 method, where at least some of the producer dependency statements identify one or more of an argument dependency and a field dependency (705), where the argument dependencies make the assignment of the outputs of the child producers (725) as input parameters to the parent producers (720), and where the field dependencies indicate uses of the instance fields.
NP164. The NP148 method, where class keys (1090, 1110) are used to distinguish classes, said method keys (1190) are used to distinguish methods, instance keys (1120) are used to distinguish instances, and producer keys are used to distinguish producers, where the producer key for each producer is based on at least the class key, the instance key, and the method key of that producer class, instance and method.
NP165. The NP164 method, where the instance code of at least some producers contains a reference to the producer instance.
41 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41
36 members in 10 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 633098 | United States of America | – | |
| 63309806 | United States of America | A |
Members36
| Document | Office | Kind | |
|---|---|---|---|
| US2008134138A1 | United States of America | A1 | |
| WO2008064901A2 | World Intellectual Property Organization (WIPO) | A2 | |
| EP1942411A2 | European Patent Office (EPO) | A2 | |
| EP1942411A3 | European Patent Office (EPO) | A3 | |
| WO2008064901A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2008064901A8 | World Intellectual Property Organization (WIPO) | A8 | |
| CN101617292A | China | A | |
| JP2010511234A | Japan | A | |
| HK1139216A | Hong Kong, China | A | |
| HK1139216A1 | Hong Kong, China | A1 | |
| RU2009125013A | Russian Federation | A | |
| EP2365435A2 | European Patent Office (EPO) | A2 | |
| EP2365436A2 | European Patent Office (EPO) | A2 | |
| EP2365435A3 | European Patent Office (EPO) | A3 | |
| EP2365436A3 | European Patent Office (EPO) | A3 | |
| EP1942411B1 | European Patent Office (EPO) | B1 | |
| AT546775T | Austria | T | |
| ATE546775T1 | Austria | T1 | |
| RU2445682C2 | Russian Federation | C2 | |
| ES2381373T3 | Spain | T3 | |
| US8191052B2 | United States of America | B2 | |
| US2012266146A1 | United States of America | A1 | |
| US2013232475A1 | United States of America | A1 | |
| JP5354602B2 | Japan | B2 | |
| US8607207B2 | United States of America | B2 | |
| US8645929B2 | United States of America | B2 | |
| BRPI0719730A2 | Brazil | A2 | |
| EP2365435B1 | European Patent Office (EPO) | B1 | |
| US2014137086A1 | United States of America | A1 | |
| ES2471394T3 | Spain | T3 | |
| EP2365436B1 | European Patent Office (EPO) | B1 | |
| ES2497573T3This record | Spain | T3 | |
| CN101617292B | China | B | |
| US10083013B2 | United States of America | B2 | |
| US2018321920A1 | United States of America | A1 | |
| US10481877B2 | United States of America | B2 |
Numbers
- Publication
- 2497573
- Application
- 11167918
Titles2
- Spanish
- Salidas de sustitución en un sistema de programación y ejecución orientado por grafos de productor
- English
- Substitution outputs in a programming and execution system oriented by producer graphs
Classification
- CPC, 6
- G06F9/4494
- G06F8/315
- G06F9/4488
- G06F8/30
- G06F8/41
- G06F9/45508
- IPC, 1
- G06F9 44