ES2327797T3 - Soporte de programacion orientado a graficos de productores con soporte de escenario. - Google Patents
Soporte de programacion orientado a graficos de productores con soporte de escenario. Download PDFInfo
- Publication number
- ES2327797T3 ES2327797T3 ES07856313T ES07856313T ES2327797T3 ES 2327797 T3 ES2327797 T3 ES 2327797T3 ES 07856313 T ES07856313 T ES 07856313T ES 07856313 T ES07856313 T ES 07856313T ES 2327797 T3 ES2327797 T3 ES 2327797T3
- Authority
- ES
- Spain
- Prior art keywords
- producer
- producers
- dependencies
- scenario
- dependency
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4494—Execution paradigms, e.g. implementations of programming paradigms data driven
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
- Measuring Or Testing Involving Enzymes Or Micro-Organisms (AREA)
Abstract
Un método implementado por ordenador para ejecutar un programa de aplicación escrito en un código orientado a objetos, comprendiendo el método: representar un productor con una salida que es actualmente de interés, en el que el código orientado a objetos incluye métodos y declaraciones de dependencias del productor, en el que la declaración de dependencias del productor para un método determinado identifica un conjunto de cero o más productores, en el que un productor es una construcción representable por una rutina de ejecución que incluye al menos una instancia y un método asociado con esa instancia; en respuesta a dicha representación, añadir el productor de interés como parte del primer gráfico de productores; intentar generar automáticamente un resto del primer gráfico de productores mediante enlazado, y la representación si es necesaria, de otros productores en base a las declaraciones de dependencias del productor y los métodos de los productores ya en el primer gráfico de productores; y simular el programa de aplicación con un cambio en el programa de aplicación mientras que se impiden estados existentes y salidas existentes de los productores en el primer gráfico de productores.
Description
Soporte de programación orientada a gráficos de
productores con soporte de escenario.
Las realizaciones de la invención se refieren al
campo de los ordenadores; y más específicamente, al campo de la
programación y la ejecución de código con una rutina de
ejecución.
\vskip1.000000\baselineskip
La programación orientada a objetos es un
paradigma de la programación de ordenadores. La idea que está detrás
de la programación orientada a objetos es que un programa de
ordenador puede verse de forma que comprende una colección de
unidades individuales (llamadas objetos o instancias) que actúan
entre sí, en oposición a la visión tradicional en la cual un
programa puede verse como una colección de funciones, o simplemente
como una lista de instrucciones para el ordenador. Un objeto es un
mecanismo de lenguaje para vincular datos con métodos que operan
sobre esos datos. Cada uno de los objetos es capaz de llamarse a
través de métodos, procesar datos, y proporcionar resultados a
otros objetos. Cada uno de los objetos puede verse como una máquina
independiente o actor con un papel o responsabilidad distintos.
Un lenguaje orientado a objetos reflexivo es un
lenguaje de programación que tiene un conjunto particular de
características (por ejemplo, clases, objetos/instancias, herencia,
reflexión, etc.), mientras que un lenguaje basado en objetos
reflexivo se usa a veces para etiquetar un lenguaje de programación
que tiene algún subconjunto de esas características (por ejemplo,
objetos). Para el propósito de este documento las frases "código
fuente orientada a objetos" y "código orientado a objetos"
se usarán para referirnos a un código escrito en un lenguaje que
tiene tales características (por ejemplo, un código escrito en un
lenguaje reflexivo orientado a objetos, un código escrito en un
lenguaje reflexivo basado en objetos). Aunque los lenguajes de
procedimientos, los lenguajes no reflexivos orientados a objetos, y
los lenguajes no reflexivos basados en objetos son lenguajes de
programación que típicamente no soportan tales características,
pueden usarse técnicas de transformación para proporcionar tales
características (por ejemplo, mediante la emulación) para el código
adecuadamente escrito en tales lenguajes; y de este modo, tales
técnicas transforman tales lenguajes en un lenguaje reflexivo
basado en objetos o un lenguaje reflexivo orientado a objetos.
(Estas técnicas no necesitan emular todas las características de
los lenguajes orientados en objetos o basados en objetos, pero
pueden emular sólo las características que son de interés para el
resto de este documento). Para el propósito de este documento, las
frases "código fuente orientado a objetos" y "código
orientado a objetos" se usarán también para referirnos a tales
procedimientos transformados, el código de lenguaje no reflexivo
orientado a objetos, y el código de lenguaje no reflexivo basado en
objetos. A modo de ejemplo, y no de limitación este documento
principalmente describe un código fuente orientado a objetos
escrito en un lenguaje reflexivo orientado a objetos. También, los
términos objeto y instancia se usan de forma intercambiable en este
documento.
Usados principalmente en la programación
orientada a objetos, el términos método se refiere a un elemento de
código que está asociado exclusivamente bien con una clase (llamada
métodos de clase, métodos estáticos, o métodos de fábrica) o con un
objeto (llamados métodos de instancias). Como un procedimiento en
los lenguajes de programación de procedimientos, un método usual
consiste de una secuencia de declaraciones para realizar una
acción, un conjunto de parámetros de entrada para configurar esas
acciones, y posiblemente se devuelve un valor de salida de alguna
clase.
Cuando los programadores escriben un programa
usando un lenguaje orientado a objetos, el código resultante puede
verse conceptualmente de forma que incluye cuatro tipos básicos de
código. El primer tipo incluye comandos que operan sobre instancias
de entrada para proporcionar instancias de salida (denominados en
este documento como código de "transformación"); típicamente
escritos como métodos (denominados en este documento como métodos
de transformación). El segundo tipo incluye comandos de
representación de instancias que hacen que la rutina de ejecución
represente instancias de clases (denominados en este documento como
código de "representación de instancias"). El tercer tipo
incluye comandos de manipulación de propiedad (denominados en este
documento como código de "preparación de datos") para invocar
métodos de propiedad (que acceden, o que producen un cambio, etc.)
de las instancias anteriores. El cuarto tipo incluye secuencias de
comandos que causan la secuenciación de invocación de métodos que
usan las instancias adecuados (donde las instancias adecuadas
incluyen las instancias a usar como argumentos, las instancias a
usar por los métodos de instancias, y las instancias de meta clases
usadas por los métodos de clases) para especificar qué métodos de
transformación de qué instancias invocar, en qué orden, y con qué
parámetros de los cuales las instancias sensibles a los cambios
producidos por el código de preparación de datos (denominado en
este documento como código de "secuenciación de invocación
manual"). El código de secuenciación de invocación manual se
escribe a veces como métodos separados de los métodos de
transformación, y de este modo el código de secuenciación de
invocación manual incluye secuencias de comandos de invocación para
los métodos de transformación. Típicamente un programa itera entre
el código de preparación de datos y el código de secuenciación de
invocación manual (el cual puede también profundizar en el código
de representación de instancias), el cual a su vez invoca el código
de transformación (que puede también profundizar en código de
representación de instancias y los tipos de código de preparación de
datos). Se observará que esta es una representación conceptual de
un programa, y de este modo, no debería tomarse en absoluto con
respecto a cómo ver un programa.
\vskip1.000000\baselineskip
El término rutina de ejecución se usa en este
documento para referirnos a un programa o una librería de códigos
básicos que corre otro código escrito en el mismo y/o en diferente
lenguaje. De este modo, una rutina de ejecución es una colección de
funciones de utilidad que soportan un programa mientras que se está
ejecutando, incluyendo el funcionamiento con el sistema operativo
para proporcionar facilidades tales como funciones matemáticas,
entrada y salida. Estas hacen innecesario para los programadores
reescribir continuamente capacidades básicas especificadas en un
lenguaje de programación o proporcionadas por un sistema operativo.
Como la demarcación entre la rutina de ejecución y el sistema
operativo puede estar borrosa, el término rutina de ejecución se
usa en este documento para referirnos a un código separado del
sistema operativo y/o al código que es parte del sistema
operativo.
Rutinas de ejecución primitivas, tales como el
FORTRAN, proporcionan características tales como operaciones
matemáticas. Otros lenguajes añaden características más sofisticadas
- por ejemplo, la recogida de basura de memoria, a menudo en
asociación con el soporte para objetos. Los lenguajes más recientes
tienden a tener rutinas de ejecución considerablemente mayores con
considerablemente más funcionalidad. Muchos lenguajes orientados a
objetos también incluyen un sistema conocido como el
"despachador" o "cargador de clases". La Máquina Virtual
de Java (JVM) es un ejemplo de tal rutina de ejecución: también
interpreta o compila los programas Java binarios portátiles (código
de octetos de bits) en la rutina de ejecución. El esquema de la
rutina de ejecución de lenguaje común (CLR) es otro ejemplo de una
rutina de ejecución.
\vskip1.000000\baselineskip
Un esquema dentro del cual se proporcionan las
aplicaciones a los usuarios finales incluye tres divisiones
básicas. La primera división incluye la creación del sistema
operativo y la rutina de ejecución. La primera división se realiza
por los programadores con experiencia en programación altamente
avanzada. Cuando se trabaja en esta división, los programadores se
denominan respectivamente como programadores de sistemas operativos
y programadores de rutinas de ejecución. Cuando se crea una rutina
de ejecución para un lenguaje orientado a objetos, los
programadores de las rutinas de ejecución incluyen un soporte para
ejecutar los diversos tipos de comandos utilizados en el código de
transformación, el código de representación de instancias, el código
de preparación de datos, y el código de secuenciación de invocación
manual (por ejemplo, comandos de representación de instancias,
comandos de preparación de datos, y comandos de invocación de
métodos).
La segunda división incluye la creación de un
código fuente de aplicación orientada a objetos a correr por la
rutina de ejecución. La segunda división se realiza de nuevo por
programadores con experiencia de programación altamente avanzada,
así como un entendimiento de los objetivos del negocio de la
aplicación. Cuando se trabaja en esta división, los programadores
se denominan como programadores de aplicación. Cuando se crea una
aplicación en un lenguaje de programación orientado a objetos, los
programadores de las aplicaciones escriben el código de
transformación específico, el código de representación de
instancias, el código de preparación de datos, y el código de
secuenciación de invocación manual para la aplicación específica que
se está creando. Como parte de esto, si la aplicación requiere una
interfaz gráfica de usuario, los programadores de la aplicación
también diseñan y codifican la interfaz gráfica de usuario para la
aplicación específica; y de este modo también se denominan como
diseñadores de aplicación.
La tercera división incluye el uso de programas
de aplicación que se corren por la rutina de ejecución. La tercera
división se realiza por los usuarios finales que no necesitan tener
ninguna experiencia de programación.
\vskip1.000000\baselineskip
Los mayores costes típicamente asociados con la
creación de una aplicación involucran la depuración y/o la
optimización del código de secuenciación de invocación manual. Para
cada una de las oportunidades para los datos a cambiar, el
programador de la aplicación debe considerar su efecto y escribir el
código de secuenciación de invocación manual para causar los
métodos de transformación apropiados de las instancias apropiadas a
invocar en el orden apropiado con las entradas apropiadas. Errores
de ejemplo producidos por los programadores de la aplicación
incluyen: 1) invocar los métodos de la transformación apropiados de
las instancias apropiadas en el orden equivocado; 2) olvidar
incluir comandos para causar que el uno o más métodos de
transformación requeridos de instancias a invocar en respuesta a
algunos datos que están cambiando; 3) incluir comandos para causar
métodos de trasformación innecesarios de instancias a invocar en
respuesta a algunos datos que están cambiando (por ejemplo, incluir
comandos para invocar métodos de transformación de instancias que no
están afectadas por el cambio en los datos), etc.
A modo de ejemplo, una técnica de generar un
código de secuenciación de invocación manual es el uso de un modelo
del observador (a veces conocido como "publicar suscribir")
para observar el estado de una instancia en un programa. En el
modelo del observador, una o más instancias (llamadas observadores u
oyentes) están registradas (o se registran a si mismas) para
observar un evento, que puede ocasionarse por el objeto
observado (el sujeto). La instancia observada, que puede ocasionar
un evento, generalmente mantiene una colección de observadores
registrados. Cuando se ocasiona el evento, cada observador recibe
una llamada de vuelta desde la instancia observada (la instancia
observada invoca un método de "notificación" en los
observadores registrados). La función de notificación puede pasar
algunos parámetros (generalmente información acerca del evento que
está ocurriendo) que puede usarse por los observadores. Cada uno de
los observadores implementa la función de notificación, y como
consecuencia define su propio comportamiento cuando se produce la
notificación.
La instancia observada típicamente tiene un
método de registro para añadir un nuevo observador y un método de
desregistro para eliminar un observador de la lista de instancias a
notificar cuando se ocasiona el evento. Además la instancia
observada puede también tener métodos para deshabilitar
temporalmente y a continuación rehabilitar llamadas para impedir la
ineficiente puesta en cascada de varias de las actualizaciones
relacionadas. Específicamente, las llamadas de vuelta requeridas en
respuesta a un cambio de valor de propiedad a menudo también cambian
valores de otras propiedades, disparando llamadas de vuelta
adicionales, y así sucesivamente.
Cuando se usa la técnica del modelo del
observador, los programadores de aplicaciones que escriben el código
de secuenciación de invocación manual, especifican qué métodos de
qué instancias llamar, en qué orden, y con qué entradas
registrando, desregistrando, inhabilitando, y rehabilitando
observadores para diferentes instancias observadas, así como
escribiendo la notificación y los métodos de llamada de vuelta para
cada uno. Más específicamente, la asociación entre el observador y
las instancias observadas se gestiona localmente (por la instancia
observada sola, sin sincronización con otras instancias observadas)
dentro del modelo del observador, y de este modo el código de
secuenciación de invocación manual necesario para sincronizar
eventos desde múltiples instancias observadas es típicamente parte
de los métodos específicos de llamada de vuelta de cada uno de los
observadores.
\vskip1.000000\baselineskip
Las rutinas de ejecución típicas usan un
almacenamiento volátil de llamadas, de
sobre-escritura para seguir las llamadas
incompletas actualmente invocadas. Un almacenamiento volátil de
llamadas, de sobre-escritura se
sobre-escribe porque saca y desecha las entradas
cada vez que se completa una llamada y es volátil porque se
descarta y se reconstruye con cada ejecución. Las rutinas de
ejecución típicas usan almacenes volátiles de llamadas, de
sobre-escritura porque las rutinas de ejecución
típicas combinan la construcción de un almacenamiento volátil de
llamadas, de sobre-escritura con la invocación real
de los métodos de transformación adecuados de las instancias
apropiadas con las entradas apropiadas en respuesta a la ejecución
del código de secuenciación de invocación manual. En suma, en
respuesta a la ejecución de un código de secuenciación de invocación
manual, una rutina de ejecución típica, determina la secuenciación
de métodos/instancias de transformación llamada por llamada (a
medida que se realiza cada llamada) y mantiene el almacenamiento
volátil de llamadas de sobre-escritura para seguir
las llamadas incompletas, sólo actualmente invocadas.
\vskip1.000000\baselineskip
El mapeo Relativo a Objetos es una técnica de
programación que enlaza bases de datos relacionales con conceptos
del lenguaje orientado a objetos, creando (en efecto) una "base de
datos de objetos virtuales". Algunos realizadores del mapeo
relativo a objetos mantienen las instancias cargadas en memoria en
sincronización constante con las bases de datos. Específicamente,
después de la construcción de una pregunta de mapeo de objetos a
SQL, en primer lugar los datos devueltos se copian dentro de los
campos de las instancias en cuestión, al igual que cualquier
paquete de mapeo de objetos a SQL. Una vez allí, las instancias
tienen que mirar para ver si estos valores cambian, y a
continuación invertir cuidadosamente el proceso para escribir los
datos de vuelta a la base de datos.
Hibernate 3.0 es una solución de mapeo relativo
a objetos para Java y CLR (Jboss® Inc. de Atlanta, Georgia). De
este modo Hibernate proporciona un entramado para realizar el mapeo
de un modelo de dominio orientado a objetos a una base de datos
relacional tradicional. Su objetivo es relevar al desarrollador de
algunas tareas de programación relacionadas con la persistencia de
datos comunes. Hibernate tiene cuidado del mapeo de las clases a
las tablas de las bases de datos (y de los tipos de datos orientados
a objetos a tipos de datos SQL), así como de proporcionar
peticiones de datos y facilidades de recuperación. Hibernate es una
instancia central y construye gráficos que representan las
asociaciones entre instancias.
\vskip1.000000\baselineskip
La Inversión de Control, también conocida como
IOC, es un principio de programación orientado a objetos que puede
usarse para reducir el acoplamiento (el grado en el cual cada módulo
de programa depende de cada uno de los otros módulos) inherente en
los programas de ordenador. La IOC se conoce también como el
Principio de Inversión de Dependencia. En la IOC, una clase X
depende de una clase Y si se aplica cualquiera de lo siguiente: 1)
X tiene una Y y la llama; 2) X es una Y; o 3) X depende de alguna
clase Z que depende de Y (transitividad). Es importante observar
que X depende de Y no implica que Y depende de X, si sucede que
ambos son ciertos, se llama una dependencia cíclica: X no puede
entonces usarse sin Y, y viceversa.
En la práctica, si un objeto x (de la clase X)
llama a métodos de un objeto y (de la clase Y), entonces la clase X
depende de la clase Y. La dependencia se invierte introduciendo una
tercera clase, a saber una clase de interfaz I que debe contener
todos los métodos que x podría llamar sobre y. Además, Y debe
cambiarse de modo que implementa la interfaz I. X e Y son ahora
ambas dependientes de la interfaz I y la clase X ya no dependen de
la clase Y (suponiendo que x no crea una instancia sobre Y). Esta
eliminación de la dependencia de la clase X sobe la clase Y
introduciendo una interfaz I se dice que es una inversión de control
(o una inversión de dependencia). Debe observarse que Y debe
depender de otras clases. Antes de que se haya aplicado la
transformación X, dependía de Y y de este modo X dependía
indirectamente de todas las clases de las que depende Y. Aplicando
la inversión de control, todas esas dependencias indirectas también
se han roto. La interfaz I introducida de nuevo no depende de
nada.
La Estructura de Muelle es una estructura de
aplicación de fuente abierta para la plataforma Java que usa la IOC
y la inversión de dependencia. Específicamente, el centro de la
Estructura de Muelle es su contenedor de Inversión de Control que
proporciona un medio para configurar y gestionar los objetos Java.
Este contenedor se conoce también como BeanFactory,
ApplicationContext o contenedor del Núcleo. Ejemplos de operaciones
de este contenedor son: la creación de objetos, la configuración de
objetos, las llamadas de métodos de inicialización y el paso de
objetos a objetos registrados de la llamada de vuelta. Los objetos
que se crean por el contendor también se llaman Objetos Gestionados
o Habas (Beans). Típicamente el contenedor se configura cargando los
ficheros XML que contienen las definiciones de las Beans. Estos
proporcionan toda la información que se requiere para crear los
objetos. Una vez que se han creado y configurado los objetos sin
producir condiciones de error se hacen disponibles para su uso. Los
objetos pueden obtenerse por medio de la búsqueda de Dependencias o
la inyección de Dependencias. La búsqueda de Dependencias es un
modelo donde un llamante pide al contenedor de objetos un objeto
con un nombre específico o de un tipo específico. La inyección de
Dependencias es un modelo donde el contendor pasa objetos por
nombre a otros objetos, bien a través de constructores, propiedades
o métodos de fábrica. De esta forma, la Estructura de Muelle es una
memoria central y construye gráficos que representan asociaciones
entre instancias.
\vskip1.000000\baselineskip
Javadoc^{TM} es una herramienta que analiza
las declaraciones y los comentarios de la documentación en un
conjunto de ficheros fuente de Java y produce el conjunto
correspondiente de páginas HTML que describen (por defecto) las
clases públicas y protegidas, las clases anidadas (pero no las
clases interiores anónimas), las interfaces, los constructores, los
métodos y los campos (de Sun Microsystems® Inc. en Santa Clara,
California). Javadoc puede usarse para generar la documentación API
(Interfaz de Programación de Aplicaciones) o la documentación de
implementación para un conjunto de ficheros fuente. Javadoc es una
clase y un método central y construye gráficos que representan las
asociaciones entre la combinación de clases y sus métodos.
Otro sistema para diseñar aplicaciones software
incluye gráficos u objetos analizados por un intérprete para
representar y reproducir una aplicación de un ordenador. Este
sistema utiliza clases de programación preescritas almacenadas en
librerías de código, que pueden escribirse para seguir los modelos
de diseño descritos en el documento "Design Patterns" de Gamma
y otros, Addison Wesley de 1995, el documento "Patterns in
Java" de Grand, Publicaciones de Wiley Computer de 1998, y/o las
herramientas de alto nivel de Ingeniería de Software Asistida por
Ordenador (CASE). Más específicamente, algunas de tales clases están
basadas en el modelo de comportamiento del Observador. Las
librerías de código preescrito representan nodos del estado de la
aplicación, lógica del procesamiento, y flujo de datos del sistema
entre los diversos estados de la aplicación (es decir, los elementos
de datos preescritos de la aplicación), de modo que un usuario no
necesita escribir, editar o compilar código cuando crea una
aplicación software. En cambio, el usuario edita manualmente una
aplicación software en una Interfaz Gráfica de Usuario editando
objetos visuales asociados con el nodo del estado de la aplicación
actual, tales como los datos dentro del nodo del estado de la
aplicación o procesos realizados dentro del nodo del estado de la
aplicación. A continuación, en base a los cambios producidos por el
usuario para el nodo del estado de la aplicación actual, el
intérprete presenta en pantalla el estado actualizado de la
aplicación al usuario para el estado de la aplicación que acaba de
editar. El sistema puede transitar a continuación junto con un
perfil transaccional definido por el usuario a otro estado de la
aplicación donde el usuario puede editar opcionalmente el siguiente
estado de la aplicación o el perfil de transición. Pueden realizarse
cambios a un gráfico para las instancias del gráfico que se
implementan por el intérprete, mientras que está corriendo la
aplicación software.
Este sistema para diseñar aplicaciones software
puede incluir representaciones visuales de una aplicación software
en funcionamiento que puede hacerse "utilizable" con un
controlador de la aplicación. Cuando un usuario cambia objetos
visuales, que representan la aplicación software en funcionamiento,
el controlador usa la entrada para inducir al intérprete a realizar
el cambio del gráfico. El controlador espera a continuación más
cambios. Además, las representaciones visuales de tales
aplicaciones software pueden importarse o exportarse como documentos
XML que describen la representación visual de la aplicación, y por
lo tanto de la aplicación de software.
Para editar y/o crear una aplicación software,
en la forma de una representación visual de nodos, perfiles
dirigidos, y estados de aplicación, puede incluirse además en el
sistema una interfaz del programa de la aplicación y un editor de
la aplicación. Las palabras clave, y las definiciones asociadas, a
partir de las librerías de código preescritas, posibilitan a los
desarrolladores de la aplicación definir manualmente una aplicación
de software, las etapas de procesamiento, así como la representación
visual de la aplicación software proporcionando representaciones
gráficas, dentro de un editor, de una aplicación gráfica que
correlaciona estrechamente con la estructura real de la aplicación.
Un usuario define una nueva aplicación mediante un "adivino de la
definición de la aplicación" que después que se cumplimentan
ciertos asuntos preliminares, presenta en pantalla la nueva
aplicación como una componente gráfica dentro del espacio de trabajo
del editor. Un usuario además interactúa con una aplicación
haciendo selecciones desde las listas presentadas en pantalla de las
posibles componentes de la aplicación pre-creadas y
arrastrando y soltando las componentes dentro del espacio de trabajo
usando el ratón del ordenador y el teclado. Un usuario puede
seleccionar componentes y "arrastrarlos" sobre las componentes
existentes. Cuando se "suelta" una nueva componente sobre una
componente existente, la nueva componente se convierte en un hijo
de la componente existente dentro de un gráfico de la aplicación.
Las asociaciones de componentes dentro de la aplicación se definen
manualmente por las selecciones del usuario dentro del editor. De
este modo se construye por el usuario una estructura de árbol que
representa una aplicación. A medida que se crea la aplicación, el
usuario puede seleccionar un visor del navegador de la aplicación
para representar en pantalla una vista de árbol de la aplicación
construida haciendo posible seleccionar y editar cualquier
componente de la aplicación. La interfaz del editor procesa las
entradas y selecciones del usuario incluyendo crear o borrar
elementos de la aplicación, actualizando los atributos de las
componentes, y actualizando las propiedades de la pantalla de la
aplicación.
El sistema descrito anteriormente, aunque
utiliza representaciones visuales de las aplicaciones software,
también puede usarse como una herramienta de programación visual
para definir y actualizar bases de datos relacionales. El sistema
utiliza descripciones XML de representaciones visuales de
aplicaciones de software. Una herramienta analiza e interpreta las
descripciones XML para producir esquemas de tablas de bases de datos
relacionales equivalentes, así como cambios en los mismos. Cuando
se cambian los datos dentro de una representación visual de una
aplicación software, se almacena una descripción del cambio junto
con otros cambios en un fichero registro y a continuación se
procesan como un grupo, Un programa intermedio (una aplicación java
que opera sobre su propio hilo) realiza transacciones entre las
representaciones visuales de la aplicación software y la base de
datos relacional. La aplicación java sondea (es decir, comprueba) el
registro de cambios para los nodos de representación visual (es
decir, los datos en la base de datos) y si hay cambios, realiza los
cambios en la base de datos. De este modo, alterando los datos
dentro de la representación visual, el sistema actualiza la base de
datos. Una aplicación similar permanece entre la representación
visual de la aplicación software y la base de datos para manejar
las peticiones de datos desde la base de datos.
Otro sistema para análisis de software se llama
el Analizador de Árboles de Código (CTA). Un CTA analiza el código
fuente estático escrito en un lenguaje de programación orientado a
objetos. El CTA genera una tabla de símbolos y un árbol de llamadas
a partir del código fuente estático. Usando la tabla de símbolos, el
CTA genera un diagrama de clases. Igualmente, usando el árbol de
llamadas, el CTA genera un diagrama de secuencias. El diagrama de
clases ilustra la asociación entre una clase seleccionada por el
usuario y las clases relacionadas con la clase seleccionada por el
usuario. El diagrama de secuencias ilustra la secuencia en la cual
se llaman los diferentes métodos. Usando tanto el diagrama de
clases como el diagrama de secuencias, el CTA genera un artefacto
de diseño representativo del código fuente estático. Cuando el
usuario modifica el artefacto de diseño, el CTA identifica las
porciones impactadas del código fuente usando el diagrama de
secuencias. El artefacto de diseño se usa para el mantenimiento del
código y/o la ingeniería inversa del código fuente estático.
\vskip1.000000\baselineskip
Se presentan las realizaciones de una estructura
de programación orientada a gráficos de productores con soporte de
escenarios. En una realización, se recibe una petición de evaluar
los impactos potenciales por un cambio sobre un programa de
aplicación. El programa de aplicación incluye un conjunto de
productores, teniendo cada uno al menos una instancia y un método
asociado con la instancia. En respuesta a la petición, el programa
de aplicación puede simularse con el cambio mientras que se
conservan los estados existentes y las salidas existentes de los
productores.
\vskip1.000000\baselineskip
La invención puede entenderse de la mejor manera
refiriéndonos a la siguiente descripción y a los dibujos adjuntos
que se usan para ilustrar las realizaciones de la invención. En los
dibujos:
La Figura 1A es un diagrama de bloques que
ilustra la asociación de una declaración de dependencias del
productor para un método de una clase en un código fuente orientado
a objetos con un productor que incluye la clase, una instancia
determinada de esa clase y un método de esa clase, de acuerdo con
una realización de la invención;
la Figura 1B ilustra ejemplos de asociaciones
entre el productor 110A y el productor padre 114A.1 de acuerdo con
una realización de la invención;
la Figura 1C ilustra ejemplos de asociaciones
entre el productor 110A y el productor hijo 112A.1 de acuerdo con
una realización de la invención;
la Figura 1D ilustra algunos ejemplos de
combinaciones adicionales de asociaciones de productores padre 114 y
los productores hijo 112 para el productor 110A de acuerdo con una
realización de la invención;
la Figura 1E ilustra que las instancias
diferentes de la misma clase pueden tener productores basados en los
mismos y/o diferentes métodos de acuerdo con una realización de la
invención;
la Figura 2 es un diagrama de bloques que
ilustra la reutilización de una rutina de ejecución con un soporte
de programación orientado a gráficos de productores de acuerdo con
una realización de la invención;
la Figura 3A es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores de acuerdo con una realización
de la invención;
la Figura 3B es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores que también soporta la ejecución
incremental y las salidas del productor anuladas de acuerdo con una
realización de la invención;
la Figura 4A es un diagrama de bloques que
ilustra el descubrimiento y construcción de un gráfico de
productores de ejemplo de acuerdo con una realización de la
invención;
la Figura 4B es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
4A de acuerdo con una realización de la invención;
la Figura 4C es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores de la
Figura 4B de acuerdo con una realización de la invención;
la Figura 4D es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores de la
Figura 4B después de que el productor dependiente 2 se ha anulado de
acuerdo con una realización de la invención;
la Figura 4E es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores de la
Figura 4B después de que el productor dependiente 2 se ha anulado y
el productor fuente independiente 3 se ha modificado de acuerdo con
una realización de la invención;
la Figura 5A es un diagrama de bloques que
ilustra el descubrimiento y construcción de un gráfico de
productores de ejemplo incluyendo una dependencia sin resolver de
acuerdo con una realización de la invención;
la Figura 5B es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
5A y la resolución de la dependencia sin resolver de acuerdo con una
realización de la invención;
la Figura 5C es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
5A y/o la reejecución del gráfico de productores de la Figura 5B de
acuerdo con una realización de la invención;
la Figura 5D es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
5A y/o la reejecución del gráfico de productores de las Figuras 5B ó
5C de acuerdo con una realización de la invención;
la Figura 6 es un diagrama de flujo que ilustra
el flujo lógico de ejecución de una rutina de ejecución del cliente
y su asociación con una rutina de ejecución con el soporte de
programación orientado al gráfico de productores de acuerdo con una
realización de la invención;
la Figura 7A ilustra un seudo código de una
declaración de dependencias del productor para un método que usa
dependencias declaradas de atajo de acuerdo con una realización de
la invención;
la Figura 7B es un diagrama de bloques de
productores de ejemplo de acuerdo con una realización de la
invención;
la Figura 7C ilustra el seudo código de una
declaración de dependencias del productor para un método que usa una
dependencia declarada no de atajo, e ilustra un diagrama de bloques
de productores de ejemplo de acuerdo con una realización de la
invención;
la Figura 7D ilustra el seudo código de una
declaración de dependencias del productor para un método que usa una
dependencia declarada no de atajo, de acuerdo con una realización de
la invención;
la Figura 7E es un diagrama de bloques de
productores de ejemplo de acuerdo con una realización de la
invención;
la Figura 7F es un diagrama de bloques de unas
dependencias de ejemplo mediante el uso de una
DependenciaHaciaArriba con un productor de determinación de
dependencias de acuerdo con una realización de la invención;
la Figura 7G es un diagrama de bloques de
posibles dependencias de ejemplo mediante el uso de una
DependenciaDébilmenteRestringida con un productor de determinación
de dependencias de acuerdo con una realización de la invención;
la Figura 7H ilustra gráficos de productores de
ejemplo de productores normalizados de acuerdo con una realización
de la invención;
la Figura 7I ilustra un ejemplo de dependencias
del productor y productores de determinación de dependencias para
descubrir, resolver y construir el gráfico de productores de la
figura 7H.
la Figura 8A es un diagrama de bloques que
ilustra una primera estructura de ejemplo dentro de la cual se
proporcionan aplicaciones a los usuarios finales de acuerdo con una
realización de la invención;
la Figura 8B es un diagrama de bloques que
ilustra una segunda estructura de ejemplo dentro de la cual se
proporcionan aplicaciones a los usuarios finales de acuerdo con una
realización de la invención;
la Figura 8C una captura de pantalla de ejemplo
y el uso de una selección libre de célula con el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención;
la Figura 8D ilustra otra captura de pantalla de
ejemplo y el uso de una selección libre de célula con el módulo de
interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840 de acuerdo con una
realización de la invención;
la Figura 8E ilustra una captura de pantalla de
ejemplo y el uso de creación de tablas con el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención;
la Figura 8F ilustra otra captura de pantalla de
ejemplo y el uso de creación de tablas con el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención;
la Figura 9A es un diagrama de bloques que
ilustra un primer esquema para distribuir una rutina de ejecución
con soporte de programación orientado al gráfico de productores de
acuerdo con una realización de la invención;
la Figura 9B es un diagrama de bloques que
ilustra un segundo esquema para distribuir una rutina de ejecución
con soporte de programación orientado a gráficos de productores de
acuerdo con una realización de la invención;
la Figura 9C es un diagrama de bloques que
ilustra un tercer esquema para distribuir una rutina de ejecución
con soporte de programación orientado a gráficos de productores de
acuerdo con una realización de la invención;
la Figura 10 es un diagrama de bloques de una
implementación de ejemplo de acuerdo con una realización de la
invención;
la Figura 11A es un diagrama de bloques de un
ejemplo de la estructura de seguimiento de clases 1092 de la Figura
10 de acuerdo con una realización de la invención;
la Figura 11B es un diagrama de bloques de un
ejemplo de la estructura de seguimiento de instancias 1065 de la
Figura 10 de acuerdo con una realización de la invención;
la Figura 11C es un diagrama de bloques de un
ejemplo de la estructura de gráficos de productores 1060 de la
Figura 10 de acuerdo con una realización de la invención;
la Figura 11D es un diagrama de bloques de un
ejemplo de la estructura de seguimiento de métodos 1058 de la Figura
10 de acuerdo con una realización de la invención;
la Figura 12 es un diagrama de bloques que
ilustra detalles adicionales de la Figura 10 para soportar las
dependencias dinámicas del productor tipo contingente y de
suscripción de acuerdo con una realización de la invención;
la Figura 13A ilustra el seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia declarada no de atajo, no dinámica (no contingente,
no de suscripción) de acuerdo con una realización de la
invención;
la Figura 13B es un diagrama de bloques de los
productores que ilustran una dependencia del productor de ejemplo
declarada no de atajo, no dinámica (no contingente, no de
suscripción) de acuerdo con una realización de la
invención;
invención;
la Figura 13C ilustra un seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia del productor declarada no de atajo, contingente, no
de suscripción de acuerdo con una realización de la invención;
la Figura 13D es un diagrama de bloques de
productores que ilustran un ejemplo de una dependencia del productor
declarada no de atajo, contingente, no de suscripción de acuerdo con
una realización de la invención;
\newpage
la Figura 13E ilustra un seudo código de las
declaraciones de dependencias del productor para métodos que usan
tanto dependencias del productor declaradas no de atajo,
contingentes, no de suscripción como dependencias del productor
declaradas de atajo, contingentes, no de suscripción de acuerdo con
una realización de la invención;
la Figura 13F es un diagrama de bloques de los
productores que ilustra una dependencia del productor declarada no
de atajo, contingente, no de suscripción y una dependencia del
productor declarada de atajo, contingente, no de suscripción de
acuerdo con una realización de la invención;
la Figura 13G ilustra seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia del productor declarada de atajo, contingente, no de
suscripción y una dependencia del productor declarada de atajo, no
contingente, no de suscripción de acuerdo con una realización de la
invención;
la Figura 13H es un diagrama de bloques de los
productores que ilustran una dependencia del productor declarada de
atajo, contingente, no de suscripción y una dependencia del
productor declarada de atajo, no contingente, no de suscripción de
acuerdo con una realización de la invención;
la Figura 13I ilustra seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia del productor declarada de atajo, no dinámica (no
contingente, no de suscripción) de acuerdo con una realización de la
invención;
la Figura 13J es un diagrama de bloques de
productores que ilustran una dependencia del productor de ejemplo
declarada de atajo, no dinámica de acuerdo con una realización de la
invención;
la Figura 14A es un diagrama de bloques de un
ejemplo del registro de suscripción 1250 de la figura 12 de acuerdo
con una realización de la invención;
la Figura 14B es un diagrama de bloques de
productores de ejemplo que ilustran una dependencia del productor no
contingente, de suscripción absorbente de acuerdo con una
realización de la invención;
la Figura 14C es un diagrama de bloques de
productores de ejemplo que ilustran una dependencia del productor,
no contingente, de suscripción adherente de acuerdo con una
realización de la invención;
la Figura 14D ilustra la elección de un
productor padre en base al productor de determinación de
dependencias del padre creadas por una suscripción adherente de
acuerdo con una realización de la invención;
la Figura 14E ilustra la elección de un
productor padre en base al productor de determinación de
dependencias del padre creado por el productor de determinación de
dependencias del hijo, cuyo productor de determinación de
dependencia del hijo está enlazado por una dependencia de
secuenciación, de acuerdo con una realización de la invención;
la Figura 15 es un diagrama de flujo para
representar nuevas instancias de acuerdo con una realización de la
invención;
la Figura 16 es un diagrama de flujo para
representar nuevos productores y restaurar productores de acuerdo
con una realización de la invención;
la Figura 17 es un diagrama de flujo para el
bloque 1650 de la Figura 16 de acuerdo con una realización de la
invención;
la Figura 18 es un diagrama de flujo para el
bloque 1745 de la Figura 17 de acuerdo con una realización de la
invención;
la Figura 19 es un diagrama de flujo para el
bloque 1630 de la Figura 16 de acuerdo con una realización de la
invención;
la Figura 20 es un diagrama de flujo para los
bloques 1635 y 1670 de la Figura 16 de acuerdo con una realización
de la invención;
la Figura 21 es un diagrama de flujo para anular
productores de acuerdo con una realización de la invención;
la Figura 22A es una parte del diagrama de flujo
para la ejecución de gráficos de productores actuales de acuerdo con
una realización de la invención;
la Figura 22B es otra parte del diagrama de
flujo para la ejecución de gráficos de productores actuales de
acuerdo con una realización de la invención;
la Figura 23 es un diagrama de flujo para el
bloque 2205 de la Figura 22 de acuerdo con una realización de la
invención;
la Figura 24 es un diagrama de flujo para el
bloque 2225 de la Figura 22 de acuerdo con una realización de la
invención;
la Figura 25 es un diagrama de flujo para el
bloque 2260 de la Figura 22 de acuerdo con una realización de la
invención;
la Figura 26 ilustra una realización alternativa
de la invención que soporta el escenario;
la Figura 27A es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores así como un soporte de escenario
de acuerdo con una realización de la invención;
la Figura 27B es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores que también soporta la ejecución
incremental y anulación de las salidas de productores, así como
escenarios de acuerdo con una realización de la invención;
las Figuras 28A-D ilustran
algunos ejemplos de gráficos de productores de un programa de
aplicación para diferentes escenarios;
la Figura 29 es un diagrama de flujo del flujo
lógico de ejecución de una rutina de ejecución del cliente y su
asociación con una rutina de ejecución con el soporte de
programación orientado a gráficos de productores de acuerdo con una
realización de la invención;
la Figura 30 es un diagrama de bloques de una
implementación alternativa de acuerdo con una realización de la
invención que soporta el escenario.
la Figura 31A ilustra una realización de ejemplo
de una estructura de seguimiento de clases;
la Figura 31B ilustra una realización de ejemplo
de una estructura de seguimiento de instancias;
la Figura 31C ilustra una realización de ejemplo
de una estructura de gráficos de productores;
la Figura 31D ilustra una realización de ejemplo
de una estructura de seguimiento de escenarios;
la Figura 31E ilustra una realización de ejemplo
de una estructura de seguimiento de objetos de escenarios;
la Figura 31F ilustra una realización de ejemplo
de una lista de impactos;
la Figura 32 es un diagrama de flujo que ilustra
un nuevo flujo de representación de escenarios de acuerdo con una
realización de la invención;
la Figura 33 es un diagrama de flujo que ilustra
un nuevo flujo de representación de instancias que soporta
escenarios de acuerdo con una realización de la invención;
las Figuras 34A-34G ilustran
diagramas de flujo de representación de un nuevo productor estresado
en un escenario objetivo de acuerdo con una realización de la
invención; y
las Figuras 35A-35B son
diagramas de flujo que ilustran un flujo de ejecución de gráficos de
productores estresados de acuerdo con una realización de la
invención.
\vskip1.000000\baselineskip
En la siguiente descripción, se muestran
numerosos detalles específicos tales como implementaciones lógicas,
códigos de operación, medios para especificar los operandos,
implementaciones de partición/compartir/duplicación de recursos,
tipos y asociaciones entre los componentes de un sistema, y
elecciones de partición/integración lógicas para proporcionar un
entendimiento más perfecto de la invención. Se apreciará, sin
embargo, por los especialistas en la técnica que la invención puede
llevarse a la práctica sin tales detalles específicos. En cualquier
caso, las estructuras de control, las estructuras de datos, y las
secuencias de instrucciones software global no se han mostrado en
detalle para no obscurecer la invención. Los especialistas en la
técnica, con las descripciones incluidas, podrán implementar la
funcionalidad apropiada sin experimentación excesiva.
A menos que se especifique lo contrario, las
líneas discontinuas en las figuras (con la excepción de las líneas
de división discontinuas) se usan para representar los elementos
opcionales en las figuras. Sin embargo, no debería presuponerse que
todos los elementos opcionales se muestran usando líneas
discontinuas, sino que más bien que los mostradas en líneas
discontinuas se eligieron por una diversidad de razones (por ejemplo
pudieron mostrarse fácilmente, para proporcionar una mayor claridad,
etc.)
\newpage
Las referencias en esta especificación a "una
de las realización", "una realización", "una realización
de ejemplo", etc. indican que la realización descrita puede
incluir una característica, estructura o rasgo particular, pero
cada realización puede que no incluya necesariamente el rasgo,
estructura o característica particular. Además, tales frases no
necesariamente se refieren a la misma realización. Además, cuando se
describe un rasgo, estructura o característica particular en
conexión con una realización, se sostiene que está dentro del
conocimiento de cualquier especialista en la técnica
afectar a tal rasgo, estructura o característica en conexión con otras realizaciones se describa explícitamente o no.
afectar a tal rasgo, estructura o característica en conexión con otras realizaciones se describa explícitamente o no.
En la siguiente descripción y reivindicaciones,
pueden usarse los términos "acoplados" y "conectados",
junto con sus derivados. Debería entenderse no se pretende que
estos términos sean sinónimos entre sí. Más bien, en realizaciones
particulares, "conectados" puede usarse para indicar que dos o
más elementos están en contacto directo entre sí. "Acoplados"
puede significar que dos o más elementos están en contacto directo.
Sin embargo, "acoplados" puede también significar que dos o
más elementos no están en contacto directo entre sí, pero que aún
cooperan o interactúan entre sí.
En algunos casos, las operaciones de diagramas
de flujo se describen con referencia a las realizaciones de ejemplo
de otros diagramas de bloques. Sin embargo, debería entenderse que
las operaciones de los diagramas de flujo pueden realizarse por
realizaciones de la invención distintas de las tratadas con
referencia a estos otros diagramas de bloques, y que las
realizaciones de la invención tratadas con referencia a estos otros
diagramas de bloques pueden realizar operaciones diferentes de las
tratadas con referencia a los diagramas de flujo.
Las técnicas mostradas en las figuras pueden
implementarse usando código y datos almacenados y ejecutados sobre
uno o más ordenadores. Tales ordenadores almacenan y comunican
(internamente y con otros ordenadores sobre una red) código y datos
que usan medios legibles por una máquina, tales como los medios de
almacenamiento de una máquina (por ejemplo, discos magnéticos;
discos ópticos; memoria de acceso aleatorio; memoria de sólo
lectura; dispositivos de memoria flash) y medios de comunicación de
máquinas (por ejemplo, eléctricos, ópticos, acústicos u otra forma
de señales propagadas - tales como ondas portadoras, señales de
infrarrojos, señales digitales, etc.). Además, tales ordenadores
típicamente incluyen un conjunto de uno o más procesadores acoplados
a uno o más componentes, tales como un dispositivo de
almacenamiento, varios dispositivos de entrada/salida de usuario
(por ejemplo, un teclado o una pantalla), y una conexión de red. El
acoplamiento del conjunto de procesadores y otros componentes
típicamente se produce a través de uno o más buses y puentes
(también denominados como controladores de bus). El dispositivo de
almacenamiento y el tráfico de red representan respectivamente una
o más medios de almacenamiento de las máquinas y medios de
comunicación de las máquinas. De este modo, el dispositivo de
almacenamiento de un sistema de ordenador determinado típicamente
almacena código y datos para la ejecución del conjunto de uno o más
procesadores de ese ordenador. Por supuesto, pueden implementarse
una o más partes de una realización de la invención usando
diferentes combinaciones de software, firmware, y/o hardware.
\vskip1.000000\baselineskip
De acuerdo con un aspecto de la invención, un
productor es al menos una instancia (o un objeto) y un método
específico, de modo que si se ejecuta el productor durante la rutina
de ejecución, se ejecuta el método específico sobre la instancia
específica. De este modo, un productor determinado se representa a
partir de una instancia determinada y un método determinado
asociado con esa instancia. Al igual que las clases, instancias, y
métodos los productores son elementos básicos o constructores
manipulados por la rutina de ejecución. De este modo, la
representación de un productor se interpreta y se sigue por la
rutina de ejecución, y de este modo la rutina de ejecución sigue la
combinación de las instancias y métodos representados por los
productores. En otras palabras, un productor es un constructor que
se puede representar por una rutina de ejecución que se sigue por
la rutina de ejecución, que se ejecuta por la rutina de ejecución, y
que incluye al menos una instancia y un método asociado con esa
instancia, de modo que la ejecución de las rutinas de ejecución del
productor da como resultado que se ejecuta el método del productor
sobre la instancia del productor. También el método de un productor
tiene asociado con el mismo una declaración de dependencias del
productor que identifica, con un conjunto de cero o más
dependencias del productor, un conjunto de cero o más productores
para el productor determinado. Específicamente las dependencias del
productor se declaran para métodos que usan declaraciones de
dependencias del productor, la declaración de dependencias del
productor para un método determinado puede incluir cero o más
dependencias del productor, y cada una de las dependencias del
productor identifica un conjunto de cero o más productores. De esta
forma, las declaraciones de dependencia del productor y las
dependencias del productor que definen se interpretan y se siguen
por la rutina de ejecución, y de este modo la rutina de ejecución
sigue las asociaciones entre productores indicadas por las
declaraciones de dependencias del productor.
Donde un productor determinado es dependiente de
un conjunto de uno o más productores, la rutina de ejecución
asegurará la ejecución del conjunto de otros productores antes que
el productor determinado. De este modo las declaraciones de
dependencias del productor representan las asociaciones de ejecución
entre productores, mientras que los productores representan las
operaciones a realizar (método) e instancias. Aunque en algunas
realizaciones de la invención se permiten dependencias de los
productores padre sobre los productores hijo a declarar en la
declaración de dependencias del productor asociada con el método del
productor padre (la declaración de dependencias del productor, del
productor padre identifica cualesquiera productores hijo -
denominadas en este documento como declaradas hacia abajo), otras
realizaciones de la invención también permiten dependencias a
declarar en la declaración de dependencias del productor asociada
con el método de los productores hijos (la declaración de
dependencias del productor, del productor hijo identifica uno o más
productores padre - denominada en este documento como declaradas
hacia arriba).
En las diferentes realizaciones de la invención
un productor identifica cosas adicionales. Por ejemplo, aunque en
algunas realizaciones de la invención un productor es al menos una
instancia y un método asociado con esa instancia, en otras
realizaciones de la invención un productor es una clase, una
instancia de esa clase, y un método asociado con esa instancia (por
ejemplo, un productor puede incluir directamente una clase, una
instancia y un método; un productor puede incluir directamente una
instancia y un método, mientras que identifica indirectamente una
clase de esa instancia a través de una referencia (por ejemplo, una
referencia en la instancia)). Aunque la invención puede usarse en
el contexto del código escrito en diferentes lenguajes de
programación (por ejemplo, un código orientado a objetos escrito en
un lenguaje reflexivo orientado a objetos; un código orientado a
objetos escrito en un lenguaje reflexivo basado en objetos; un
código escrito en un procedimiento, no reflexivo orientado a
objetos, un lenguaje no reflexivo basado en objetos y transformado
en un código de lenguaje reflexivo orientado a objetos), se
describirán realizaciones de la invención, a modo de ejemplo y no
de limitación, con referencia a los lenguajes reflexivos de
programación orientados a objetos y con referencia a los
productores que incluyen directamente clases, instancias y métodos.
También, aunque en una realización de la invención el método de un
productor es un método de una instancia (un método puede usar campos
de instancias además de cualesquiera entradas recibidas como
argumentos), realizaciones alternativas de la invención también
pueden soportar o alternativamente soportan el método de un
productor que es un método de clase (métodos que reciben todas las
entradas como argumentos y/o usa variables independientes de la
instancia) (donde el método de un productor es un método de una
instancia, la instancia de ese productor es una instancia de una
clase; aunque donde el método de un productor es un método de
clase, la instancia de ese productor es una instancia de
meta-clase que representa la clase).
La Figura 1A es un diagrama de bloques que
ilustra la asociación de una declaración de dependencias del
productor para un método de una clase en un código fuente orientado
a objetos para un productor que incluye la clase, una instancia
determinada de esa clase, y un método de esa clase, de acuerdo con
una realización de la invención. En la Figura 1A, el código fuente
orientado a objetos 100 se muestra incluyendo una clase 102, que a
su vez incluye un método 104 y una declaración de dependencias del
productor 106 para el método 104. Por supuesto, la clase 102
típicamente incluiría uno o más campos (no mostrados) y métodos
adicionales (no mostrados). Además, el código fuente orientado a
objetos 100 típicamente incluiría clases adicionales.
Durante la rutina de ejecución, se representa
una instancia 108 de la clase 102. La instancia 108 incluye los
datos de los campos de la clase 102. Además, se representa el
productor 110, donde el productor 110 identifica la clase 102, la
instancia 108 de la clase 102 (que tiene asociado con la misma el
método 104 de la clase 102), y el método 104 de la clase 102. La
declaración de dependencias del productor 106 identifica para la
rutina de ejecución un conjunto de cero o más productores 112
(denominados como productores hijo del productor 110) que deben
ejecutarse antes de la ejecución del productor 110. En otras
palabras, el productor 110 depende del conjunto de cero o más
productores 112. Además de, o en lugar de, consumir salidas del
conjunto del productor 112, el productor 110 puede consumir datos
de la instancia 108. Además, el productor 110 proporciona al menos
una salida, salida que puede ser interna a la instancia 108 (y de
este modo, modificar los datos de la instancia 108) y/o puede ser
externa; de cualquier modo, la salida del productor 110 puede
consumirse por un conjunto de cero o más de otros productores 114
(denominados como productores padres del productor 110). Como se ha
indicado anteriormente y se describe con más detalle más adelante en
este documento, la declaración de dependencias del productor 106,
en algunas realizaciones de la invención, también pueden identificar
para la rutina de ejecución de cero o más productores 114.
Debería entenderse que las entradas y salidas de
los productores están basadas en las entradas y salidas de los
métodos sobre los cuales están basados esos productores. Como tal,
estas entradas y salidas pueden representar múltiples parámetros que
tienen una diversidad de estructuras de datos.
La declaración de dependencias del productor
para un método determinado identifica en la rutina de ejecución el
conjunto de cero o más productores a representar y a ejecutar. A
modo de ejemplo, donde una declaración de dependencias de un
productor (por ejemplo, la declaración de dependencias del productor
106) para un método determinado (por ejemplo, el método 104)
identifica una dependencia del productor sobre un productor
determinado (cuyo productor determinado identifica una primera
clase, una primera instancia de esa clase, y un primer método de
esa primera clase) (por ejemplo, uno del conjunto de productores
112), a continuación la declaración de dependencias del productor
del método determinado identifica para la rutina de ejecución que se
va a representar la primera instancia (si no lo está ya) y que se
va a usar el primer método para representar el productor determinado
para la primera instancia (en estos ejemplos, el término primera no
significa localización u orden).
En funcionamiento, cuando durante el tiempo de
ejecución, se designan un conjunto determinado de uno o más
productores como productores de interés y tienen dependencias del
productor declaradas para los mismos, la rutina de ejecución: 1)
genera automáticamente (descubre, construye y opcionalmente
resuelve) un conjunto de uno o más gráficos, que pueden ser
multi-nivel y pueden ser de una diversidad de formas
(por ejemplo de cadena, de árbol), desde el conjunto determinado de
productores designados como productores de interés bajando a los
productores fuente en base a las declaraciones de dependencias del
productor); y 2) la ejecución de secuencias de productores del
conjunto de gráficos para generar las salidas del conjunto
determinado de productores designado como productores de interés.
De este modo, la rutina de ejecución usa las declaraciones de
dependencias del productor para determinar qué métodos, con qué
argumentos para ejecutar sobre qué instancias, y cuando para
propósitos de sincronización.
De este modo, las dependencias del productor
representan la secuenciación de la ejecución de los productores
para la rutina de ejecución. Sin embargo, además de indicar la
secuenciación de la ejecución, las dependencias del productor
pueden representar diferentes entradas para sacar asociaciones en
diferentes realizaciones de la invención. Por ejemplo diferentes
realizaciones de la invención pueden soportar una o más dependencias
de argumentos del productor, dependencias de campos del productor,
y dependencias de secuenciación sólo del productor (las
dependencias de secuenciación sólo del productor se denominan en
este documento con las dependencias del productor de secuenciación
taquigráficas). Aunque cada una de las dependencias de argumentos
del productor, las dependencias de campos del productor, y las
dependencias de secuenciación del productor representan la
asociación de secuenciación de la ejecución entre productores,
argumentos y dependencias de campos del productor adicionalmente
representan los datos de los cuales se da cuenta la rutina de
ejecución. Específicamente, una dependencia de argumentos del
productor causa que la rutina de ejecución realice el mapeo de la
salida de un productor hijo como un parámetro de entrada para un
productor padre, mientras que una dependencia de un campo del
productor indica el uso de un campo de una instancia.
Independientemente de la asociación de la entrada con la salida
representada por las dependencias del productor, el uso adecuado de
las dependencias del productor asegura que los productores que
acceden a la información se secuencian después de los productores
que impactan esa información.
Las dependencias de secuenciación pueden usarse
para una diversidad de propósitos, incluyendo asegurar el orden de
ejecución entre los productores que modifican los datos de un modo,
del cual la rutina de ejecución no está enterada y los productores
que consumen esos datos (un productor hijo puede escribir sus
salidas en un modo que requiere que el método del productor padre
incluya código para acceder a esa salida (por ejemplo, un método
que impacta el entorno afectando a una salida que no es la salida
del productor normal y, como tal, que no se detecta por la rutina
de ejecución - tal como un método que fija una variable global, que
fija un campo en una instancia que no es la salida del productor,
que impacta una fuente de datos externa, etc.)). De este modo, una
dependencia de secuenciación refleja una dependencia de un productor
padre sobre un productor hijo pero requiere salidas que se necesita
proporcionar, si las hay, desde una a la otra se produce a través
de la escritura de código (por ejemplo, el código en el método del
productor hijo para escribir una salida para un mecanismo
determinado (tal como fijar una variable global, impactar una fuente
de datos externa, fijar un campo en una instancia que no es la
salida del productor, etc.) y un código en el método del productor
padre para leer esa salida desde el mecanismo determinado). De este
modo, las dependencias de secuenciación permiten a la rutina de
ejecución sincronizar la ejecución de cualesquiera productores padre
que descansan sobre una salida que la rutina de ejecución no puede
detectar. Influir en las fuentes (tales como las variables globales
o las fuentes de datos externas) de las que la rutina de ejecución
no es consciente y leer desde estas fuentes es una característica
que debería evitarse en los productores donde se requieren
capacidades de escenario.
En una realización de la invención la
declaración de dependencias del productor para un método determinado
identifica sólo dependencias directas sobre los productores (por
ejemplo, descendientes directos (hijos), en contraste con los
descendientes indirectos (nietos, bisnietos, etc.). En tal
realización, cada una de las declaraciones de dependencias del
productor proporciona un nivel único o capa de productores cuyas
salida pueden usarse directamente por un productor representado
desde el método determinado, dejando el
descubrimiento/construcción/resolución de las capas adicionales del
gráfico de productores al procesamiento de la rutina de ejecución de
otras declaraciones de dependencias del productor.
\vskip1.000000\baselineskip
Un productor puede verse como un conjunto de
identificadores múltiples un identificador para cada uno de los
niveles adicionales de granularidad especificada (clase, instancia,
método, etc.). Además, algunas realizaciones de la invención
implementan cada uno de los identificadores como una clave separada,
mientras que otras realizaciones tienen ciertos identificadores
compartiendo una clave. A modo de ejemplo, algunas realizaciones de
la invención implementan un productor como un triplete de una
clase, una instancia, y un método e implementan claves, de modo que
cada una de esas partes del triplete se identifica por una clave
separada (una clave de clase, una clave de instancia, y una clave
de método) y el productor se identifica por la combinación de clave
de clase, clave de instancia y clave de método (la clave del
productor).
Las realizaciones de la invención que usan
claves pueden variar en la unicidad de las claves utilizadas. Por
ejemplo, en una realización de la invención, cada una de las claves
de clase es única, cada una de las claves de instancia es única a
través de todas las instancias de todas las clases, y cada una de
las claves de los métodos es única a través de todos los métodos de
todas las clases. Como un ejemplo adicional, en otras realizaciones
de la invención, cada una de las clases tiene una clave única, cada
instancia de una clase determinada tiene una clave única (a través
de las instancias de clases), y cada uno de los métodos de una clase
tiene una clave única (a través de los métodos de clase); pero las
instancias de las diferentes clases pueden tener la misma clave de
instancia, y los métodos de diferentes clases pueden tener la misma
clave de método; esta última aproximación se usará en el resto del
documento a modo de ejemplo y no de limitación. Por ejemplo,
asumamos que una primera clase incluye métodos y tiene una clave
para cada uno de estos métodos que es única dentro de la primera
clase, a continuación las instancias de esta clase (que tendrán cada
una clave única como cada una de las otras) tienen las mismas
claves de métodos asociadas con los mismos. Como otro ejemplo,
asumamos que una segunda clase diferente incluye métodos (sean
algunos, todos o ninguno los mismos que los métodos de la primera
clase) que tienen las mismas claves de método que las usadas por la
primera clase; como tal, una instancia de esta clase diferente
puede tener asociada con la misma las mismas claves de método que
las asociadas con una instancia de la primera clase.
\newpage
El uso de las claves permite una diversidad de
características, incluyendo: 1) el seguimiento de cada una de las
entidades identificadas por los identificadores del productor (por
ejemplo, el seguimiento de cada una de las clases, instancias y
métodos); 2) diversos productores padre (no conscientes de su mutua
existencia) para conectar al mismo productor hijo en base a sus
declaraciones de dependencias del productor (que especifican
dependencias del productor que usan claves del productor), etc. En
una realización de la invención, la clave de instancia es una
instancia de una clase (ClaveInstancia) que mantiene dos elementos:
una clave de instancia natural que indica si el identificador de la
clave es una referencia a la instancia u otro objeto (tal como una
cadena de caracteres), y un identificador de clave que puede ser
bien una referencia a la instancia, o a otro objeto (tal como una
cadena de caracteres). El almacenamiento de una referencia de
instancia en la clave de instancia ahorra al programador inventar
un nombre para identificar estas instancias.
\vskip1.000000\baselineskip
En el contesto de la exposición anterior
respecto al productor que está viendo como un conjunto de
identificadores múltiples (con un identificador para cada nivel
adicional de granularidad especificada), en una realización de la
invención las diversas asociaciones soportadas entre un productor y
sus hijos y padres son aquellas en las que al menos uno de tales
identificadores es diferente entre un productor y su conjunto de
cero o más productores padre y uno de tales identificadores es
diferente entre un productor y cada uno de su conjunto de cero o
más productores hijo. Como modo de proporcionar algunas asociaciones
de ejemplo, asumamos que se representa un primer productor, donde
el primer productor es una primera instancia de una primera clase y
un primer método de esa primera clase, y asumamos que la declaración
de dependencias del productor para ese primer método identifica en
la rutina de ejecución un segundo productor como un hijo, entones el
segundo productor puede ser: 1) la primera instancia de la primera
clase y un segundo método de esa primera clase; 2) una segunda
instancia de la primera clase y un segundo método de esa primera
clase; 3) una segunda instancia de la primera clase y el primer
método de la primera clase; o 4) una instancia de la segunda clase y
un método de esa segunda clase. En tal caso, el primer productor es
dependiente del segundo productor - representando, de este modo,
una asociación de una entrada con una salida del primer productor
sobre el segundo productor. Las diversas asociaciones y
combinaciones de esas asociaciones se describen más adelante para
una realización de la invención que usa un lenguaje orientado a
objetos y en el cual un productor identifica al menos una clase, una
instancia y un método.
Las Figuras 1B-1D ilustran
asociaciones de ejemplo entre un productor determinado, su conjunto
de productores padre, y su conjunto de productores hijo de acuerdo
con una realización de la invención. Las Figuras
1B-1D muestran cada uno los siguiente 1) una
definición de clase 102A incluyendo métodos 104A-C y
declaraciones de dependencias del productor 106A-C
para cada uno de estos métodos, respectivamente; 2) una definición
de clase 102B incluyendo métodos 104D-E y las
declaraciones de dependencias del productor 106D-E
para cada uno de esos métodos, respectivamente; 3) una definición
de clase 102C incluyendo un método 104F y una declaración de
dependencias del productor 106F para ese método; 4) una instancia
108A de la clase 102A, 5) un productor 110A que identifica la clase
102A, la instancia 108A, y el método 104A; y 6) un productor 112A.1
y un productor 114.1 que representan respectivamente uno del
conjunto de productores 112 y 114. Las líneas discontinuas con
letras encuadradas sobre las mismas se usan en las Figuras
1B-1D para ilustrar las asociaciones de ejemplo. De
este modo, la colección de líneas discontinuas con la letra A
encuadrada sobre las mismas representa una asociación. Las
asociaciones en la figura 1B son combinables con las asociaciones en
la Figura 1C; como tal, estas combinaciones representan
combinaciones de asociaciones entre los productores padres 114A y
los productores hijos 112A para el productor 110A. Además la Figura
1D ilustra algunas combinaciones de ejemplo adicionales de las
asociaciones entre productores padres 114A y productores hijos 112A
para el productor 110A.
La Figura 1B ilustra asociaciones de ejemplo
entre el productor 110A y el productor padre 114A.1 de acuerdo con
una realización de la invención. La Figura 1B incluye adicionalmente
una instancia 108B. El conjunto de productores 114 se identifica
por otras declaraciones de dependencia de diferentes métodos de la
misma clase, diferentes instancias de la misma clase, y/o métodos
de una clase diferente; y de este modo, cada uno del conjunto de
productores 114 puede ser: 1) de la misma instancia que el productor
110A (instancia 108A de la clase 102A) y un método diferente
asociado con esa instancia (ilustrada por la letra A encuadrada
sobre las líneas discontinuas desde la instancia 108A para el
productor 114A.1 y desde el método 104B al productor 114A.1); 2) de
una instancia diferente de la clase 102A y un método diferente
asociado con esa instancia (ilustrado con la letra B encuadrada
sobe las líneas discontinuas desde la clase 102A a la instancia
108B, desde la instancia 108B al productor 114A.1, y desde el
método 104B al productor 114A.1); 3 de una instancia de una clase
diferente y un método asociado con esa instancia (ilustrado por la
letra C encuadrada sobre las líneas discontinuas desde la clase
102B a la instancia 108B, desde la instancia 108B al productor
114A.1 y desde el método 104D al productor 114A.1); o 4) de una
instancia diferente de la clase 102A (que la instancia 108A) y el
mismo método (método 104A) de esa instancia (por ejemplo con una
dependencia contingente - descrita más adelante en este documento)
(ilustrada por la letra D encuadrada sobre las líneas discontinuas
desde la clase 102A a la instancia 108B, desde la instancia 108B al
productor 114A.1, y desde el método 104A al productor 114A.1);
además, donde hay múltiples productores en el conjunto de
productores 114, los productores 114 ellos mismos pueden ser parte
de la misma instancia de la clase 102A, diferentes instancias de la
clase 102A, una instancia de una clase diferente, y/o una mezcla de
las anteriores.
La Figura 1C ilustra asociaciones de ejemplo
entre el productor 110A y el productor hijo 112A.1 de acuerdo con
una realización de la invención. La Figura 1C adicionalmente incluye
una instancia 108C. Cada productor del conjunto de productores 112A
puede ser: 1) de la misma instancia que el productor 110A (instancia
108A de la clase 102A) y un método diferente asociado con esa
instancia (ilustrada por la letra E encuadrada sobre las líneas
discontinuas desde la instancia 108A al productor 112A.1 y desde el
método 104C al productor 112A.1 y desde el método 104C al productor
112A.1); 2) de una instancia diferente de la clase 102A y un método
diferente asociado con esa instancia (ilustrado por la letra F
encuadrada sobre las líneas discontinuas desde la clase 102A a la
instancia 108C, desde la instancia 108C al productor 112A.1 y desde
el método 104C al productor 112A.1); 3) de una instancia de una
clase diferente y un método asociado con esa instancia (ilustrados
por la letra G encuadrada sobre las líneas discontinuas desde la
clase 102C a la instancia 108C, desde la instancia 108C al
productor 112A.1 y desde el método 104F al productor 112A.1); ó 4)
de una instancia diferente de la clase 102A (que la instancia 108)
y el mismo método (método 104A) de esa instancia (por ejemplo, con
una dependencia contingente descrita más adelante en este
documento) (ilustrado por la letra H encuadrada sobre las líneas
discontinuas desde la clase 102A a la instancia 108C, desde la
instancia 108C al productor 112A.1, y desde el método 104A al
productor 112A.1). De este modo, cada uno del conjunto de
productores 112A puede ser de la misma instancia que el productor
110A, de diferente instancia de la clase 102A, o de una instancia de
una clase diferente; además, donde hay múltiples productores en el
conjunto de productores 112A, los propios productores 112A pueden
ser parte de la misma instancia de la clase 102A, diferentes
instancias de la clase 102A, la misma instancia de una clase
diferente, diferentes instancias de una clase diferente, y/o una
mezcla de las anteriores.
La Figura 1D ilustra algunas combinaciones de
ejemplo adicionales de las asociaciones de productores padre 14 y de
productores hijo 112 para el productor 110A de acuerdo con una
realización de la invención. La Figura 1D adicionalmente incluye la
instancia 108B y la instancia 108C. Las combinaciones de la Figura
1D se muestran en la Tabla 1 siguiente:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
La Figura 1E ilustra que instancias diferentes
de la misma clase pueden tener productores en base a los mismos y/o
diferentes métodos de acuerdo con una realización de la invención.
La Figura 1E muestra: 1) la definición de clase 102A incluyendo los
métodos 104A-C y las declaraciones de dependencias
del productor 106A-C para cada uno de esos métodos,
respectivamente; 2) la instancia 108A y la instancia 108B que son de
la clase 102A, 3) un productor 110A es el método 104A de la
instancia 108A de la clase 102A; 4) un productor 110B es el método
104B de la instancia 108A de la clase 102A; 5) un productor 110C es
el método 104A de la instancia 108B de la clase 102A; y 6) un
productor 110D es el método 104C de la instancia 108B de la clase
102A. Además, la Figura 1D muestra que: 1) la declaración de
dependencias del productor 106A para el método 104A identifica en
la rutina de ejecución productores hijos tanto del productor 110A
como del productor 110C; 2) la declaración de dependencias del
productor 106B para el método 104B identifica en la rutina de
ejecución el productor hijo del productor 110B, y 3) la declaración
de dependencias del productor 106C para el método 104C identifica en
la rutina de ejecución el productor hijo del productor 110D.
\vskip1.000000\baselineskip
La Figura 2 es un diagrama de bloques que
ilustra la reutilización de una rutina de ejecución con el soporte
de programación orientado a gráficos de productores de acuerdo con
una realización de la invención. En la Figura 2, están corriendo
múltiples programas de aplicación orientados a objetos (códigos de
aplicaciones orientadas a objetos con declaraciones de dependencias
del productor 210A-I) por la misma rutina de
ejecución con el soporte de programación orientado a gráficos de
productores 220.
La Figura 3A es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores de acuerdo con una realización
de la invención. En la Figura 3A, una rutina de ejecución con el
soporte de programación orientado a gráficos de productores 335
incluye un módulo de generación automatizada de gráficos de
productores 340 y un módulo de ejecución de gráficos de productores
345. Además la rutina de ejecución 335 es para ejecutar el código
fuente orientado a objetos, y de este modo incluye módulos
adicionales no mostrados.
Además, la Figura 3A muestra las declaraciones
de dependencias del productor para métodos en un código fuente
orientado a objetos 320, un conjunto actual de uno o más productores
cuyas salidas son de interés 325 (también denominadas en este punto
como los productores seleccionados actualmente de interés), y las
salidas de los productores fuente 330 (descritos más adelante en
este documento). El módulo de generación automatizada de gráficos
de productores 340 recibe las declaraciones de dependencias del
productor 320 y el conjunto actual de productores de interés
325.
El módulo de generación automatizada de gráficos
de productores 340 intenta descubrir, en base a las declaraciones
de dependencias del productor, productores hijo con salidas que
contribuyen directamente e indirectamente a la entrada de los
productores seleccionados actualmente de interés (y algunas
realizaciones de la invención que soportan dependencias declaradas
hacia arriba, productores padre), y construye un conjunto de uno o
más gráficos actuales de productores que representan la dependencia
de esos productores sobre cada uno de los otros desde los
productores seleccionados actualmente de interés, a través de
cualquiera de los productores descubiertos que son productores no
fuente, a aquellos de los productores descubiertos que son
productores fuente. Los gráficos de productores actuales se
almacenan en la estructura de gráficos de productores 380. Aunque
realizaciones de la invención pueden almacenar y manipular los
gráficos de productores como una colección de gráficos, otras
realizaciones de la invención almacenan y manipulan los gráficos de
productores como una colección de productores que están enlazados
entre sí para formar gráficos (en oposición a la colección de
gráficos) para facilitar la fusión y división de gráficos de
productores. A modo de ejemplo y no de limitación, se describen en
este documento realizaciones de la invención que almacenan y
manipulan los gráficos de productores como una colección de
productores.
El módulo de ejecución de gráficos de
productores 345 recibe los gráficos de productores actuales desde el
módulo de generación automatizada de gráficos de productores 340 y
las salidas de los productores fuente 330, y ejecuta los
productores de los gráficos de productores actuales para determinar
la salida actual de los productores de interés seleccionados
actualmente. El módulo de ejecución de gráficos de productores 345
almacena temporalmente las salidas actuales de los productores en
la estructura de gráficos de productores 380 como se ilustra por el
almacenamiento temporal de la salida del productor 384.
El almacenamiento temporal de las salidas del
productor de los gráficos de productores durante la ejecución
permite la sincronización. Por ejemplo, el momento apropiado para
ejecutar un productor padre que es dependiente de múltiples
productores hijos es después de que se han ejecutado todos los
múltiples productores hijo; en otras palabras, sería poco económico
(y, en algunos casos no posible) ejecutar el productor padre cada
vez que uno de sus productores hijo completó la ejecución. El
almacenamiento temporal de las salidas del productor permite que la
ejecución del productor padre no sólo se posponga hasta que todos
los productores hijo se hayan ejecutado sino que también permite
una determinación del momento apropiado para la ejecución del
productor padre - cuando todos los productores hijo se han
ejecutado y sus salidas se han almacenado temporalmente. De este
modo, la rutina de ejecución realiza esta decisión de sincronización
para el programador comprobando el estado de ejecución de los
productores hijos; en otras palabras, tal sincronización se
automatiza (el programador no necesita incluir un código fuente
separado que determine el instante apropiado para identificar una
instancia y ejecutar un método determinado asociado con esa
instancia sobre esa instancia). A modo de otro ejemplo, donde
varios productores padre son dependientes del mismo productor hijo
así como sobre otros productores hijos diferentes, el instante
apropiado para ejecutar cada uno de los varios productores padre es
típicamente diferente; la rutina de ejecución determina
automáticamente el instante apropiado para ejecutar cada una de las
varios productores padre dependiendo de la disponibilidad de salidas
de su conjunto de productores hijos.
Como se describirá con mayor detalle más
adelante en este documento, como puede que no se puedan descubrir
actualmente algunas partes del gráfico de productores debido a las
dependencias dinámicas del productor, el módulo de generación
automatizada de gráficos de productores 340 "intenta" descubrir
y construir todo el gráfico de productores, pero no puede
inicialmente completar todo el gráfico de productores hasta que se
ejecuten algunos productores. Como tal, el módulo de ejecución de
gráficos de productores 345 puede invocar el módulo de generación
automatizada de gráficos de productores 340 con las salidas del
productor necesarias durante la ejecución del gráfico de
productores actual para completar cualquiera de los restos no
resueltos del gráfico de productores actual (esto se ilustra en la
Figura 3A por una línea discontinua con flecha desde el módulo de
ejecución del gráfico de productores 345 hasta el módulo de
generación automatizada de gráficos de productores 340; se usa una
línea discontinua con flecha porque tal soporte es opcional).
La Figura 4A es un diagrama de bloques que
ilustra el descubrimiento y construcción de un gráfico de
productores de ejemplo de acuerdo con una realización de la
invención. La Figura 4A muestra que el conjunto actual de
productores de interés consiste del productor 1. En base al
productor 1 y su declaración de dependencias del productor, se
descubren el productor 2 y el productor 3. En otras palabras la
declaración de dependencias para el productor 1 identifica que la
entrada al productor 1 requiere la ejecución del productor 2 y el
productor 3. Como tal, el productor 1 es un productor dependiente
(un productor que tiene una o más dependencias del productor). La
Figura 4A también muestra que aunque el productor 3 es un productor
independiente (un productor que no tiene ninguna dependencia del
productor, y de este modo es un productor fuente), el productor 2 no
lo es. Como resultado, en base a la declaración de dependencias del
productor 2, se descubren el productor 4 y el productor 5. En la
Figura 2A, el productor 4 y el productor 5 son productores
independientes (y de este modo, productores fuente).
La Figura 4B es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
4A de acuerdo con una realización de la invención. En la Figura 4B,
las líneas curvas con flecha ilustran la ejecución de uno de los
productores para generar una salida que se proporciona como entrada
a otro productor. Como se muestra en la figura 3A, la salida de los
productores fuente 330 se proporciona al módulo de ejecución de
gráficos de productores 345; en contraste, las salidas de los
productores dependientes 1-2 se determinan por la
ejecución de esos productores como se muestra en la Figura 4B. De
este modo, en la Figura 4B ocurre lo siguiente: 1) se proporcionan
la salida del productor fuente 4 y el productor fuente 5 al
productor dependiente 2; 2) se ejecuta el productor dependiente 2;
3) se proporcionan al productor 1 las salidas del productor
dependiente 2 y el productor fuente 3; y 4) se ejecuta el productor
1 y su salida se proporciona como salida actual de interés. Merece
la pena observar que el gráfico de productores de la Figura 4B son
datos controlados en el sentido de que los datos fluyen desde un
productor a otro productor hacia arriba en el gráfico.
De este modo, pueden generarse las declaraciones
de dependencias del productor 320 ligadas a los gráficos de
productores posibles; mientras el conjunto seleccionado actualmente
de productores de interés 325 identifica el nodo de comienzo del
gráfico de productores actual a generar. A partir de estos dos, el
módulo de generación automatizada de gráficos de productores 340
descubre y construye el gráfico de productores. El descubrimiento y
la construcción están automatizados ya que en el módulo de
generación automatizada de gráficos de productores 340 no se
proporciona el gráfico de productores (por ejemplo no necesita estar
identificado manualmente por un programador) o incluso una lista de
los productores que estarán en el gráfico de productores. En lugar
de esto, el módulo de generación automatizada de gráficos de
productores 340 analiza las declaraciones de dependencias del
productor del conjunto actual de productores seleccionados de
interés para descubrir su productores hijos (y en algunas
realizaciones de la invención que soportan dependencias declaradas
hacia arriba, productores padre), a continuación analiza las
declaraciones de dependencia del productor de los productores
descubiertos, y de este modo baja a los productores fuente (en
algunas realizaciones de la invención descritas más adelante en
este documento, esto puede hacerse con la asistencia del módulo de
ejecución de gráficos de productores 345). En el caso en el que el
gráfico de productores es un árbol, un productor de interés
seleccionado actualmente típicamente será el nodo raíz, y las
declaraciones de dependencias del productor se analizarán hasta que
se descubren los nodos hoja (productores fuente).
\vskip1.000000\baselineskip
La Figura 3B es un diagrama de bloques que
ilustra una rutina de ejecución con un soporte de programación
orientado a gráficos de productores que también soporta la ejecución
incremental y la anulación de salidas de los productores de acuerdo
con una realización de la invención. Debería entenderse que la
ejecución incremental y la anulación de salidas del productor son
cada una características opcionales independientes, y de este modo
realizaciones diferentes de la invención pueden implementar una o
ambas.
En la Figura 3B, una rutina de ejecución con un
soporte de programación orientado a gráficos de productores 360
incluye un módulo de generación automatizada de gráficos de
productores 365, un módulo de ejecución de gráficos de productores
370, y un módulo de anulación de la salida del productor 390. La
rutina de ejecución 360 es para ejecutar el código fuente orientado
a objetos, y de este modo incluye módulos adicionales no
mostrados.
Además, la Figura 3B muestra, las declaraciones
de dependencias del productor para métodos en el código fuente
orientado a objetos 320, el conjunto actual de uno o más productores
cuyas salidas son de interés 325 (también denominados en este
documento como productores seleccionados actualmente de interés), y
la salida de los productores fuente 350. La salida de los
productores fuente 350 incluye las salidas del conjunto de
productores independientes en el código fuente 352 (por ejemplo,
constantes, valores por defecto, etc.) y las salidas del productor
anuladas actualmente 354 (las salidas de los productores
independientes y/o los productores dependientes cuyas salidas están
actualmente anuladas).
En algunas realizaciones de la invención, las
salidas de los productores pueden anularse explícitamente con un
valor proporcionado actualmente (es decir, en lugar de ejecutar un
productor para determinar su valor de salida en base a sus entradas
actuales, el valor de salida para el productor se proporciona
explícitamente). Además de cualquiera de los productores
independientes de un gráfico de productores, los productores fuente
de un gráfico de productores incluyen cualesquiera productores
anulados actualmente.
El módulo de anulación de la salida del
productor 390 recibe las salidas del productor anuladas 354 (que
identifican qué productores se están anulando y con qué valores de
salida se están anulando). En una realización de la invención, los
productores pueden clasificarse como productores de propiedad y
productores de métodos. Los productores de propiedad son los
basados en los métodos de propiedad (por ejemplo, obtener y fijar).
Los productores de métodos son los basados en métodos no de
propiedad. El módulo de anulación de la salida del productor 390
incluye un módulo de anulación de la salida del productor de
propiedad 392 para los productores de propiedad anulados y un
módulo de anulación de la salida del productor de métodos 394 para
productores del método anulados. El módulo de anulación de la
salida del productor de propiedad 392 causa que el valor anulado se
almacene en el almacenamiento temporal de la salida del productor
384 y en los datos de la instancia, mientras que el módulo de
anulación de la salida del productor de métodos 394 provoca que el
valor anulado se almacene en el almacenamiento temporal de la
salida del productor 384. Dependiendo de la realización de la
invención, esta provocación puede ser directa o indirecta. La
Figura 3B ilustra una provocación indirecta mediante el uso de un
registro de anulación 396 que recoge las salidas del módulo de
anulación de las salidas del productor 390 y que se consume por el
módulo de ejecución de gráficos de productores 370. Para propósitos
de optimización, el registro de anulación 396 permite retardar las
anulaciones para recoger múltiples anulaciones para su procesamiento
por lotes.
Similar al módulo de generación automatizada de
gráficos de productores 340, el módulo de generación automatizada
de gráficos de productores 365: 1) recibe las declaraciones de
dependencias del productor 320 y el conjunto actual de productores
de interés 325; y 2) intenta descubrir, en base a las declaraciones
de dependencias del productor, productores hijo con salidas que
contribuyan directamente o indirectamente a la entrada de los
productores seleccionados actualmente de interés (y en algunas
realizaciones de la invención que soportan dependencias declaradas
hacia arriba, productores padre), y construye un conjunto de uno o
más gráficos de productores actuales que representan la dependencia
de la entrada de estos productores sobre cada uno de los otros
productores seleccionados actualmente de interés, mediante
cualesquiera productores descubiertos no fuente, a los productores
descubiertos que son productores fuente (productores independientes
y productores anulados actualmente). Los gráficos de productores se
almacenan en la estructura de gráficos de productores 380.
Similar al módulo de ejecución de gráficos de
productores 345, el módulo de ejecución de gráficos de productores
370 recibe el gráfico de productores actual desde el módulo de
gráficos automatizado 365 y las salidas de los productores fuente
350, y ejecuta los productores del gráfico de productores actual
para determinar la salida actual de los productores seleccionados
actualmente de interés. El módulo de ejecución de gráficos de
productores 370 almacena temporalmente las salidas actuales de los
productores en la estructura de gráficos de productores 380 como se
ilustra por el almacenamiento temporal de salida del productor
384.
Como se ha descrito anteriormente, el
almacenamiento temporal de las salidas del productor durante la
ejecución permite la sincronización (por ejemplo, no necesita
escribirse el código fuente separado para determinar cuándo el
productor 2 de la Figura 4B debería ejecutarse, pero en cambio la
rutina de ejecución hace esta decisión de sincronización para el
programador comprobando la disponibilidad de las salidas necesarias
en el almacenamiento temporal de salidas del productor 384; en
otras palabras, tal sincronización se automatiza). Además, este
almacenamiento temporal de la salida del productor 384 se usa para
la ejecución incremental. Más específicamente, después de que un
gráfico de productores se ha generado y ejecutado inicialmente, la
anulación de un productor en un gráfico de productores actual
requiere algún nivel de reejecución. Aunque algunas realizaciones de
la invención simplemente reejecutan todo el gráfico, las
realizaciones alternativas de la invención soportan la ejecución
incremental (reejecutando sólo las partes del gráfico de productores
que están afectadas por la anulación). Algunas realizaciones de
ejemplo que soportan la ejecución incremental usan la marcación de
la ejecución incremental 382 en la estructura de gráficos de
productores 380 para ayudar a determinar qué productores requieren
reejecución. De este modo, el mantenimiento de los gráficos de
productores se refiere a modificar los enlaces de los gráficos de
productores según se necesite a través de ejecuciones múltiples
para mantenerlos actuales (al momento), mientras que la ejecución
incremental se refiere tanto a mantener el gráfico de productores
como a usar el gráfico de productores actual (al momento), para
reejecutar sólo las partes de los gráficos de productores que están
afectadas por una anulación.
Similar a la Figura 3A, hay una línea
discontinua con flecha desde el módulo de ejecución del gráfico de
productores 370 al módulo de ejecución automatizada de gráficos de
productores 365 para representar un soporte opcional para
dependencias dinámicas. Debería observarse que las dependencias
dinámicas pueden cambiar durante la reejecución de un gráfico de
productores.
La Figura 4C es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores de la
Figura 4B de acuerdo con una realización de la invención. En la
Figura 4C, la salida del productor 5 se ha modificado
explícitamente, pero las salidas del productor 3 y del productor 4
no se han modificado. En base al seguimiento de las dependencias de
la salida con la entrada en el gráfico de productores y que sólo se
ha modificado explícitamente la salida del productor 5, se determina
que sólo el productor 2 y el productor 1 están afectados por esta
modificación. Como resultado, la determinación de una salida
actualizada del productor 1 requiere sólo la reejecución del
productor 2 y el productor 1 con la nueva salida del productor 5 y
las salidas anteriores del productor 4 y del productor 3. Esta
reejecución parcial del gráfico de productores se ilustra en la
Figura 4C por las líneas curvas con flecha desde el productor 5 al
productor 2 y desde el productor 2 al productor 1, pero no desde el
productor 4 al productor 2 o desde el productor 3 al productor 1.
La falta de las líneas curvadas con flechas desde el productor 4 al
productor 2 y desde el productor 3 al productor 1 no son para
indicar que las salidas del productor 3 y del productor 4 no son
necesarias, si no más bien que el productor 3 y el productor 4 no
necesitan reejecutarse si sus salidas anteriores están disponibles,
(por ejemplo, almacenadas temporalmente desde la anterior ejecución
del gráfico de productores).
El ejemplo relativamente simple de la Figura 4C
ilustra que puede haber un ahorro en los recursos del procesamiento
como resultado de la ejecución incremental. Tales ahorros dependen
de varios factores (por ejemplo, el número de productores que no
necesitan reejecutarse, la cantidad de procesamiento de esos
productores que se habría requerido, etc.). Aunque se ilustra una
realización de la invención que realiza ejecución incremental,
pueden implementarse realizaciones alternativas de forma diferente
(por ejemplo, una realización alternativa puede reejecutar todos los
productores en respuesta a una modificación).
La Figura 4D es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores de la
Figura 4B después de que el productor dependiente 2 se ha anulado de
acuerdo con una realización de la invención. En la Figura 4, la
salida del productor 2 se ha modificado explícitamente, pero la
salida del productor 3 no se ha modificado. En base al gráfico de
productores y a que sólo se ha modificado explícitamente la salida
del productor 2, se determina que sólo está afectado el productor 1
por esta modificación. Como resultado, la determinación de una
salida actualizada del productor 1 requiere sólo la reejecución del
productor 1 con la salida anulada del productor 2 y la salida
anterior del productor 3. Esta reejecución parcial del gráfico de
productores se ilustra en la Figura 4D por la línea curva con flecha
desde el productor 2 al productor 1, pero no desde el productor 4 y
el productor 5 al productor 2 ó desde el productor 3 al productor
1.
La Figura 4E es un diagrama de bloques que
ilustra la ejecución incremental del gráfico de productores 4B
después de que el productor dependiente 2 se ha anulado y el
productor fuente independiente 3 se ha modificado de acuerdo con
una realización de la invención. En base al gráfico de productores y
a que sólo se han modificado las salidas del productor 2 y del
productor 3, se determina que sólo el productor 1 está afectado por
esta modificación. Como resultado, la determinación de una salida
actualizada del productor 1 sólo requiere la reejecución del
productor 1 con la salida anulada del productor 2 y la salida
modificada del productor 3. Esta reejecución parcial del gráfico de
productores se ilustra en la Figura 4E por la línea curvada con
flecha desde los productores 2 y 3 al productor 1, pero no desde
los productores 4 y 5 al productor 2.
Aunque una realización de la invención que
soporta la anulación de las salidas del productor también soporta
la restauración de las salidas del productor, realizaciones
alternativas de la realización no lo soportan. Aunque una
realización de la invención que soporta la restauración de los
productores deja un productor anulado como anulado hasta que se
restaura específicamente, pueden implementarse realizaciones
alternativas de la invención de forma diferente (por ejemplo,
restaurando un productor anulado cuando uno de sus progenitores está
anulado).
Pueden implementarse diferentes realizaciones de
la invención para descubrir y construir un gráfico de productores
para diferentes extensiones (por ejemplo, construir el gráfico de
productores hasta que todos los caminos desde el nodo raíz terminan
en productores independientes (en cuyo caso, los nodos finales de un
gráfico de productores son productores independientes, con la
posibilidad de que cualesquiera de los productores anulados sean
nodos intermedios); construir el gráfico de productores hasta que
cada camino desde el nodo raíz termine en un productor anulado o un
productor independiente, cualquiera que se alcance primero (en cuyo
caso, cada uno de los nodos de un gráfico de productores es o un
productor independiente o un productor anulado).
"Los productores de comienzo de la
ejecución" se refiere a los productores de un gráfico de
productores desde los cuales comienza una ejecución determinada del
gráfico de productores. Para una ejecución inicial de un gráfico de
productores, las diferentes realizaciones pueden comenzar desde
productores diferentes (por ejemplo, en realizaciones de la
invención que construyen el gráfico de productores hasta que todos
los caminos desde el nodo raíz terminan en productores
independientes, la ejecución puede comenzar desde los nodos finales
(que serían los productores independientes), desde los productores
fuente (que incluirían los nodos de productores independientes y
cualesquiera nodos de productores anulados), desde un subconjunto de
productores fuente consistente de la combinación de cualesquiera
productores independientes con al menos un camino entre ellos y el
productor raíz que no incluye un productor anulado y cualesquiera
productores anulados, o desde un subconjunto de productores fuente
que consiste en la combinación de cualesquiera productores anulados
sin ningún descendiente que esté anulado y cualquiera productores
independientes con al menos un camino entre ellos y el productor
raíz que no incluye un productor anulado; en realizaciones de la
invención donde el gráfico de productores bajo los productores
anulados no está construido y hasta que tal productor está
restaurado, puede comenzar la ejecución desde los nodos finales
(que pueden ser productores independientes y/o productores
anulados), etc.
Para posteriores ejecuciones de un gráfico de
productores, las diferentes realizaciones pueden comenzar desde
diferentes productores (por ejemplo, desde los productores
independientes del gráfico de productores (por ejemplo, en
realizaciones de la invención que no soportan ejecución
incremental); desde los productores fuente del gráfico de
productores (por ejemplo, en realizaciones de la invención que no
soportan ejecución incremental); desde un subconjunto de
productores fuente que consiste de los productores fuente que se han
anulado y/o añadido desde la última ejecución (por ejemplo, en
realizaciones de la invención que soportan ejecución incremental);
de los productores fuente que se han anulado y/o añadido desde la
última ejecución, desde la combinación de cualesquiera de tales
productores anulados sin cualesquiera descendientes que estén
anulados y cualesquiera de tales productores añadidos con al menos
un camino entre ellos y el productor raíz que no incluye un
productor anulado (por ejemplo, en realizaciones de la invención
que soportan ejecución incremental), etc.). A modo de ejemplo y no
de limitación, las realizaciones de la invención que realizan lo
siguiente se describirán más adelante: 1) no construyen el gráfico
de productores bajo los productores anulados si y hasta que tales
productores estén restaurados; 2) para una ejecución inicial del
gráfico de productores, la ejecución comienza desde los nodos
finales (que pueden ser productores independientes y/o productores
anulados); 3) implementa ejecución incremental; y 4) para las
ejecuciones posteriores de un gráfico de productores, la ejecución
comienza desde un subconjunto de productores fuente que consiste de
los productores fuente que se han anulado y/o añadido desde la
última ejecución.
Con respecto al concepto anterior de los
productores de comienzo de ejecución, el flujo del procesamiento
del gráfico de productores también difiere entre realizaciones
diferentes. Por ejemplo, en una realización de la invención, los
ancestros de los productores de comienzo de la ejecución se
determinan y sitúan en una colección, se ejecutan los productores
de comienzo de la ejecución, y la colección se rastrea de forma
iterativa en busca de productores para los cuales se han ejecutado
todas las dependencias - eventualmente se alcanzan los nodos raíz.
Como uno ejemplo más, en una realización de la invención, se
ejecutan los productores de comienzo de la ejecución, se
identifican los padres de los productores de comienzo de la
ejecución, se ejecutan esos padres, y se identifican sus padres y
se ejecutan, y así sucesivamente. La última realización de la
invención se usa a continuación a modo de ejemplo y no de
limitación.
Una dependencia dinámica del productor es una
dependencia del productor que puede cambiar durante la rutina de
ejecución. Debería entenderse que los criterios para resolver las
dependencias del productor se presentan en el código fuente, y de
este modo los productores para los cuales pueden resolverse las
dependencias del productor están limitados. Con referencia a la
Figura 3A, la línea discontinua con flecha desde el módulo de
ejecución de gráficos de productores 345 al módulo de generación
automatizada de gráficos de productores 340 representa el soporte
para la ejecución de uno o más productores en el gráfico de
productores actual que son necesarios para descubrir y construir
todo el gráfico de productores actual. En otras palabras, una
realización de la invención que soporta dependencias dinámicas del
productor puede iterar entre el módulo de generación automatizada
del gráfico de productores 340 y el módulo de ejecución del gráfico
de productores 345 hasta que se descubre todo el gráfico de
productores, se construye, se resuelve y se ejecuta (esto es, se
itera entre: 1) invocar el módulo de generación automatizada del
gráfico de productores para descubrir y construir las partes del
gráfico de productores actual que puedan resolverse en ese momento;
y 2) invocar el módulo de ejecución del gráfico de productores para
ejecutar los productores del gráfico de productores actual). En
este sentido, descubrir se refiere al acceso de las declaraciones de
dependencia de los productores y la determinación de los
productores que identifican; construir se refiere a representar los
productores y añadirlos al gráfico de productores; y resolver se
refiere a determinar las dependencias dinámicas del productor
actualmente sin resolver.
La Figura 5A es un diagrama de bloques que
ilustra el descubrimiento y la construcción de un gráfico de
productores de ejemplo incluyendo una dependencia sin resolver de
acuerdo con una realización de la invención. La Figura 5A muestra
el conjunto actual de productores de interés consistente del
productor 1. En base al productor 1 y su declaración de
dependencias del productor, se descubren el productor 2 y el
productor 3. En otras palabras, la declaración de dependencias para
el productor 1 identifica que el productor 1 requiere como entradas
la salida del productor 2 y el productor 3. La Figura 5A también
muestra que mientras que el productor 3 es un productor
independiente (y de este modo, un productor fuente), el productor 2
no lo es. Como resultado, en base a la declaración de dependencias
del productor 2, se descubren el productor 4 y el productor 5.
Además, la Figura 5A también muestra que mientras que el productor
4 es un productor independiente ((y de este modo, un productor
fuente), el productor 5 no lo es. Como resultado, en base a la
declaración de dependencias del productor 5, se descubren el
productor 6 y la dependencia actualmente no resuelta. La Figura 5A
también muestra que la dependencia no resuelta actualmente puede
ser para el productor 7A y/o el productor 7B.
La Figura 5B es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
5A y la resolución de la dependencia sin resolver de acuerdo con
una realización de la invención. La Figura 5B ilustra el gráfico de
productores de la Figura 5A con las líneas curvas con flecha que
muestran la ejecución de los productores y la provisión de sus
salidas para los productores padres dependientes. Además, la Figura
5B muestra que la dependencia no resuelta del productor 5 se
resuelve como una dependencia sobre el productor 7A, y que el
productor 7A es un productor independiente.
La Figura 5C es un diagrama de bloques que
ilustra la ejecución inicial del gráfico de productores de la Figura
5A y/o la reejecución del gráfico de productores de la Figura 5B de
acuerdo con una realización de la invención. La Figura 5C ilustra
el gráfico de productores de la Figura 5A con líneas curvas con
flecha que muestran la ejecución de los productores y la provisión
de sus salidas a los productores padre dependientes. Además, la
Figura 5C muestra que la dependencia no resuelta del productor 5 se
resuelve como una dependencia sobre el productor 7B y que el
productor 7B es un productor dependiente. Como resultado, en base a
la declaración de dependencias del productor 7B, se descubre el
productor 8. El productor 8 es un productor independiente (y de
esta forma, es un productor fuente). Asumiendo que la Figura 5C
representa la ejecución inicial del gráfico de productores de la
Figura 5A, se emplearían todas las líneas curvas con flechas en la
Figura 5C. Sin embargo, asumiendo que la Figura 5C representa la
reejecución del gráfico de productores de la Figura 5B, la
reejecución da como resultado la dependencia dinámica que se
resuelve de diferente forma (un conmutador desde el productor 5 que
es dependiente sobre el productor 7A para el productor 7B). Además,
si se realiza la reejecución sin la ejecución incremental, a
continuación se emplearían todas las líneas curvas con flecha en la
Figura 5C; sin embargo, si se usó la ejecución incremental, sólo se
emplearían las líneas curvas no discontinuas (productor 8 al
productor 7B, productor 7B al productor 5, productor 5 al productor
2, y productor 2 al productor 1). También debería entenderse que el
cambio dinámico en la dependencia ilustrada en la Figura 5C es de
ejemplo, y de este modo podría presentar cualquier número de
situaciones diferentes (por ejemplo, el cambio dinámico puede que
nunca se produzca; el productor 5 podría haber sido primero
dependiente del productor 7B y a continuación cambiar al productor
7A; el productor 5 podría haber sido primero dependiente del
productor 7B y no producirse nunca ningún cambio dinámico; el
productor 5 podría encontrarse que es dependiente tanto del
productor 7A como del productor 7B como se ilustra en la Figura 5D;
etc.). Aunque diferentes realizaciones pueden resolver las
dependencias dinámicas
del productor de diferentes maneras, se proporcionan más adelante en este documento algunos ejemplos.
del productor de diferentes maneras, se proporcionan más adelante en este documento algunos ejemplos.
De este modo, la reejecución automatizada de un
gráfico de productores no está limitada al productor que se está
modificando y su padre directo que se está reejecutando, más bien un
cambio se riza automáticamente a través del gráfico de productores
por la rutina de ejecución, afectando cualesquiera productores y
dependencias apropiadas, ya que los gráficos de productores se
mantienen (y se usa la ejecución incremental donde se soporta).
Como tal, los cambios producen cualquier descubrimiento adicional
necesario, construyendo, resolviendo, y ejecutando. De este modo,
la reejecución del gráfico de productores se automatiza en el
sentido de que un usuario/programador no necesita determinar qué
productores del gráfico de productores están afectados y
posiblemente corrija manualmente el gráfico.
Una dependencia estática es la que no cambia
durante la rutina de ejecución. De este modo, en una realización de
la invención que soporta dependencias dinámicas contingentes y de
suscripción (descritas más adelante en este documento), una
dependencia no contingente y no de suscripción es una dependencia
estática. El gráfico de productores de ejemplo de la Figura 4A
ilustra un gráfico de productores de dependencias estáticas.
Como un productor es al menos una instancia y un
método asociado con esa instancia, un gráfico de productores es un
gráfico que representa instancias y métodos asociados con esas
instancias - y de este modo los gráficos de productores son al
menos una instancia y un método central. En realizaciones de la
invención en las cuales un productor es al menos una clase, una
instancia, y un método, los gráficos de productores son al menos una
clase, una instancia y un método central.
Debería entenderse que un gráfico de productores
puede tomar una diversidad de formas diferentes (por ejemplo, una
simple cadena de productores, un árbol, etc.). El gráfico de
productores de ejemplo de la Figura 5B es un árbol con un nodo raíz
del productor 1, desde el cual hay dos ramas - una para cada uno del
productor 2 y el productor 3. Donde el productor 3 es un nodo hoja,
el productor 2 tiene dos ramas que se extienden desde el mismo -
una para cada uno del productor 4 y el productor 5. El productor 5
tiene dos ramas que se extienden desde el mismo - una para cada uno
del productor 6 y el productor 7A. El gráfico de productores de
ejemplo de la Figura 5B se dice que es multi-nivel,
con el nivel 1, incluyendo el productor nodo raíz 1, con el nivel 2
incluyendo el productor 2 y el productor 3, con el nivel 3
incluyendo el productor 4 y el productor 5, con el nivel 4
incluyendo el productor 6 y el productor 7A (en la Figura 5C, el
nivel 4 incluye el productor 7B, y el nivel 5 incluye el productor
8). Cuando se considera la rama desde el productor 1 con el
productor 2, el primer productor de la rama es el productor 2 y los
últimos productores de la rama son el productor 4, el productor 6; y
el productor 7A en la Figura 5B.
Aunque la Figura 5B ilustra un gráfico de
productores en el cual el conjunto actual de productores de interés
incluye un productor único, las realizaciones de la invención que
soportan más de un productor actual de interés descubrirían y
construirían gráficos de productores para cada uno. Se debería
entender que donde hay simultáneamente múltiples productores de
interés, los gráficos de productores resultantes pueden ser
independientes o pueden tener intersecciones. Donde los gráficos de
productores tienen intersecciones, pueden implementarse las
realizaciones de la invención para: 1) duplicar productores para
mantener gráficos de productores separados; o 2) evitar tal
duplicación y mantener los gráficos de productores con
intersecciones. Debería entenderse que tales gráficos de
productores con intersecciones pueden incluir un gráfico de
productores que es un subconjunto de otro gráfico de productores.
Por ejemplo, si el productor 5 se incluyó con el productor 1 en el
conjunto actual de productores de interés, entonces habría un
primer gráfico de productores con un nodo raíz del productor 5 y un
segundo gráfico de productores con un nodo raíz del productor 1,
donde el segundo gráfico de productores incluye el primer gráfico
de productores. Si, por ejemplo, el productor 7B se incluyo con el
productor 1 y el productor 5 en el conjunto actual de productores
de interés, habría un tercer gráfico de productores, separado del
primer y el segundo gráficos de productores, con un nodo raíz del
productor 7B en la Figura 5B. Además, si la dependencia dinámica
del productor 5 cambió desde el productor 7A al productor 7B (Figura
5C), entonces el cambio daría como resultado que el tercer gráfico
de productores se convertiría en un subconjunto del segundo gráfico
de productores restante, y el segundo gráfico de productores se
convertiría en un subconjunto del primer gráfico de productores.
Como se ha establecido anteriormente, aunque realizaciones de la
invención pueden almacenar y manipular los gráficos de productores
como una colección de gráficos, otras realizaciones de la invención
almacenan y manipulan los gráficos de productores como una colección
de productores que están enlazados entre sí para formar gráficos
(en oposición a una colección de gráficos) para facilitar la unión y
división de los gráficos de productores. A modo de ejemplo y no de
limitación, se describen en este documento realizaciones de la
invención que almacenan y manipulan gráficos de productores como una
colección de productores.
La Figura 5 es un diagrama de flujo, de un flujo
lógico de ejecución de una rutina de ejecución del cliente y su
asociación con una rutina de ejecución con un soporte de
programación orientado a gráficos de productores de acuerdo con una
realización de la invención. En la Figura 6, la línea 600 de
división discontinua separa el flujo lógico de ejecución de una
rutina de ejecución del cliente 610 de la rutina de ejecución con el
soporte de programación orientado a gráficos de productores 640.
El flujo lógico de ejecución de la rutina de
ejecución del cliente 610 incluye los bloques 615, 620, 625 y 630,
mientras que la rutina de ejecución con el soporte orientado a
gráficos de productores incluye los bloques 645, 650, 660, y
opcionalmente 655. Una línea continua con flecha representa una
asociación directa causal del bloque 630 al bloque 660. En
contraste, las líneas de puntos con flechas ilustran una asociación
causal desde los bloques 615 y 625 en el flujo lógico de ejecución
de la rutina de ejecución del cliente 610 a los bloques 645 y 650
en la rutina de ejecución con el soporte orientado a gráficos de
productores 640, respectivamente; dependiendo de la realización de
la invención, esta asociación causal puede ser directa o indirecta.
Por ejemplo, la Figura 6 ilustra una provocación indirecta opcional
mediante el uso del registro de comandos 665 en un óvalo
discontinuo sobre la rutina de ejecución con el soporte orientado a
gráficos de productores 640 el lado de la línea discontinua 600. El
registro de comandos 665 recoge los comandos resultantes de los
bloques 615 y 625 del flujo lógico de ejecución de la rutina de
ejecución del cliente 610; y el registro de comandos 655 se
consume, en respuesta al bloque 630, procesando el bloque 660. De
este modo, el registro de comandos 665 permite el retardo de los
comando para recoger múltiples comandos juntos y procesarlos por
lotes para propósitos de optimización. De este modo, el registro de
comandos 665 es similar al registro de anulaciones 396 de la Figura
3B, y realmente incluiría el registro de anulaciones 396 en algunas
realizaciones de la invención.
En el bloque 615, el conjunto de uno o más
productores de interés se determina como el conjunto actual de
productores de interés y el control pasa al bloque 620. En respuesta
a las asociaciones causales entre el bloque 615 y el bloque 645, el
bloque 645 muestra que el conjunto actual de productores de interés
están representados y que se realiza un intento de descubrir,
construir y resolver los gráficos de productores para cada uno (si
se soportan las dependencias dinámicas y se descubren una o más en
el gráfico de productores), incluyendo representar cualesquiera
instancias y productores de los mismos cuando sea necesario, en base
a las declaraciones de dependencias del productor en la rutina de
ejecución del cliente 610. Con referencia a las Figuras 3A y 3B, se
invocan respectivamente el módulo de generación automatizada de
gráficos de productores 340 y 365.
En el bloque 620, se determina si hay
cualesquiera anulaciones de salidas de productor. Si es así, el
control pasa al bloque 625; de lo contrario el control pasa el
bloque 630.
En el bloque 625, se reciben una o más
anulaciones de salidas de productor para un conjunto de uno o más
productores y el control pasa al bloque 630. En respuesta a las
asociaciones causales entre el bloque 625 y el bloque 650, el
bloque 650 muestra que el conjunto actual de productores anulados
están representados (si no están ya representados en el bloque
645), sus salidas se modifican, y se siguen. Un productor anulado
puede haberse representado ya, porque se descubrió que ya era parte
del gráfico de productores en el bloque 645. Sin embargo, un
productor anulado puede no descubrirse ya en el bloque 645 debido a
una dependencia dinámica sin resolver. Como tal, este productor
anulado se representa y se anula con la expectación de que puede
añadirse al gráfico de productores cuando se resuelvan las
dependencias dinámicas. También, como se ha indicado anteriormente,
el registro de anulaciones 396 de la figura 3B, si se implementa,
existe entre el bloque 625 y el bloque 650 y es parte del registro
de comandos 665. Además, el conjunto de productores anulados se
sigue en algunas realizaciones de la invención que soportan la
ejecución instrumental. Aunque en las realizaciones de la invención
que soportan el registro de anulación 396/registro de comandos 665
el seguimiento es parte del registro, en realizaciones alternativas
de la invención el seguimiento está realizado separadamente en el
bloque 650 con un mecanismo diferente.
En el bloque 630, se invoca el módulo de
ejecución del gráfico de productores y el control vuelve
opcionalmente al bloque 615 y/o al bloque 625. En respuesta a las
asociaciones causales entre el bloque 630 y el bloque 660, el
bloque 660 muestra que los gráficos de productores actuales han
progresado y cualesquiera productores que requieran ejecución se
ejecutan en base al seguimiento. Se han tratado anteriormente
diversas técnicas para ejecutar los productores del gráfico de
productores y son aplicables en este punto. Con referencia a las
figuras 3A y 3B, se invoca el módulo de ejecución del gráfico de
productores 345 y 370, respectivamente. Además, en las
realizaciones de la invención en las que se implementa el registro
de comandos 665, las asociaciones causales incluyen consumir el
registro de comandos 665 y realizar los bloques de procesamiento 645
y 650 antes del bloque 660. Además, en realizaciones de la
invención que soportan la posibilidad de dependencias sin resolver,
el control fluye desde el bloque 660 al bloque 655 cuando es
necesario.
En el bloque 655, se realiza un intento de
resolver las dependencias no resueltas y descubrir y construir el
resto de los gráficos de productores, incluyendo representar
cualesquiera instancias y productores de los mismos. Desde el bloque
655, el control fluye de vuelta al bloque 660.
Las Figuras 7A-7F ilustran
algunas formas de ejemplo de declaraciones de dependencias del
productor de acuerdo con realizaciones de la invención. Aunque las
Figuras 7A-7F ilustran realizaciones que soportan
argumentos, campos, y dependencias de secuenciación, debería
entenderse que las diferentes realizaciones pueden soportar sólo
una o dos de las tres formas de dependencias. En las realizaciones
de la invención mostradas en las Figuras 7A-7F, se
realiza una declaración de dependencias del productor del
establecimiento de declaraciones de dependencias del productor, y
opcionalmente el código explícito de declaraciones de dependencias
del productor. Una dependencia del productor declarada no de atajo
es aquella en la cual se usa un código explícito de declaración de
dependencias del productor, mientras que una dependencia del
productor declarada de atajo es aquella en la que no se usa ningún
código explícito de declaración de dependencias del productor (en su
lugar, el rutina de ejecución no usa un código de declaración de
dependencias del productor y/o la implementa sobre la marcha en base
a la información en el establecimiento de declaraciones de
dependencias del productor.
Las diferentes realizaciones de la invención
pueden usar diferentes sintaxis para declarar dependencias del
productor. Por ejemplo, diferentes realizaciones de la invención
pueden incluir diferentes sintaxis para su uso en los
establecimientos de declaración de dependencias del productor que
restringen fuertemente, restringen débilmente y/o no restringen el
tipo de dependencias del productor que puede crearse. Una
dependencia del productor fuertemente restringida es aquella para
la cual se usa una sintaxis en el establecimiento de declaraciones
de dependencias del productor que sustancialmente limita el tipo de
dependencias del productor que pueden crearse. Una dependencia del
productor débilmente restringida es aquella para la cual se usa una
sintaxis en el establecimiento de declaraciones de dependencias del
productor que es menos limitativa del tipo de dependencias del
productor que pueden crearse; y una dependencia del productor sin
restricciones es aquella para la cual se usa una sintaxis en el
establecimiento de declaraciones de dependencias del productor que
no limita el tipo de dependencias del productor que pueden
creare.
A modo de ejemplo, y no de limitación, las
realizaciones de la invención descritas más adelante incluyen lo
siguiente: 1) una sintaxis para una dependencia del productor
fuertemente restringida para argumentos (DependenciaArgumento =
dependencia del argumento declarada hacia abajo fuertemente
restringida [estática o dinámica, y si dinámica, contingente y/o de
suscripción absorbente]); 2) una sintaxis para una dependencia del
productor fuertemente restringida para campos (DependenciaCampo =
dependencia del campo declarada hacia abajo fuertemente restringida
[estática o dinámica, y si dinámica, contingente y/o de suscripción
absorbente]), 3) una sintaxis para una dependencia del productor
fuertemente restringida para las dependencias de secuenciación
(DependenciaSecuenciación = dependencia de secuenciación declarada
hacia abajo fuertemente restringida [estática o dinámica, y si
dinámica, contingente y/o de suscripción adherente]), 4) una
sintaxis para una dependencia del productor declarada débilmente
restringida declarada hacia arriba para dependencias de argumentos,
campos, o secuenciación (DependenciaHaciaArriba = dependencia
débilmente restringida declarada hacia arriba de campo, argumento, o
secuenciación [estática o dinámica, y si dinámica, contingente]), y
5) una sintaxis para una dependencia del productor débilmente
restringida (DependenciaDébilmenteRestringida = una cualquiera de a)
una dependencia de sólo secuenciación declarada hacia abajo
[estática o dinámica, y si dinámica, contingente y/o de suscripción
adherente]; o b) una dependencia declarada hacia arriba [argumento,
campo o secuenciación] [estática o dinámica, y si dinámica,
contingente]. Debería entenderse que aunque algunas realizaciones de
la invención soportan una sintaxis para el establecimiento de
declaraciones de dependencias del productor que distinguen
dependencias de argumentos declaradas hacia abajo, dependencias de
campos declaradas hacia abajo, dependencias declaradas hacia arriba
(que pueden devolver dependencias de argumentos, campos o
secuenciación declaradas hacia arriba), y dependencias débilmente
restringidas (que pueden devolver dependencias de secuenciación
declaradas hacia abajo, dependencias de argumento, campo o
secuenciación declaradas hacia arriba), realizaciones alternativas
de la invención pueden adoptar una sintaxis diferente (por ejemplo,
tienen una sintaxis que tiene todas las dependencias que son
dependencias no restringidas con productores de determinación de
dependencias que pueden devolver cualesquiera dependencias
soportadas (dependencias de argumento, campo, y secuenciación
declaradas hacia abajo y hacia arriba); tienen una sintaxis que
distingue todas las dependencias soportadas; tienen una sintaxis que
distingue dependencias de argumento y campo declaradas hacia abajo
y hacia arriba y que distingue una dependencia débilmente
restringida que puede devolver sólo dependencias de secuenciación
declaradas hacia arriba y hacia abajo; una sintaxis que distingue
dependencias de argumento y de campo declaradas hacia abajo y que
distinguen dependencias declaradas hacia arriba que pueden devolver
sólo dependencias de secuenciación declaradas hacia arriba; una
sintaxis que distingue dependencias de argumento, campo, y
secuenciación declaradas hacia abajo (suscripciones adherentes y
dependencias declaradas hacia arriba no se soportan); etc.).
Debería entenderse que la sintaxis del
establecimiento de las declaraciones de dependencias del productor
no necesariamente se equipara a las dependencias del productor (por
ejemplo, el enlace) creadas en el gráfico de productores (por
ejemplo, una DependenciaArgumento crea una dependencia de argumento;
pero una DependenciaHaciaArriba puede crear una dependencia de
argumento, campo, o secuenciación). Como tal, donde sea apropiado
para el entendimiento, se usa un espacio entre un calificador (por
ejemplo, argumento, campo, o secuenciación) y la palabra
"dependencia" para referirnos a la dependencia creada por la
rutina de ejecución, mientras que se usa una ausencia de espacio
para referirnos a la sintaxis.
La Figura 7A ilustra un seudo código de una
declaración de dependencias del productor para un método que usa
dependencias declaradas de atajo de acuerdo con una realización de
la invención; mientras que la Figura 7B es un diagrama de bloques
de productores de ejemplo de acuerdo con una realización de la
invención. La Figura 7A muestra: 1) un establecimiento de
declaraciones de dependencias del productor 705 incluyendo
DependenciasArgumento 1-N, DependenciasCampo
1-M, DependenciasSecuenciación 1-L,
DependenciasHaciaArriba 1-P, y
DependenciasDébilmenteRestringidas 1-Q; y 2) Un
método alfa 710 que tiene argumentos 1-N desde el
establecimiento de declaraciones de dependencias del productor 705.
En una realización de la invención, los argumentos de un
establecimiento de declaraciones de dependencias del productor
están numeradas para proporcionar una ID de argumento para cada uno
de los propósitos de seguimiento. La Figura 7B muestra un productor
720 que tiene dependencias hijo para los siguiente: 1) productor
725 para la ID de argumento 1; 2) productor 730 para la ID de
argumento N; 3) productores 740-745 para
DependenciasCampo 1-M; 4) productores
746-747 para DependenciasSecuenciación
1-L; y 5) productores 748-749 para
DependenciasHaciaArriba 1-P (obsérvese que las
DependenciasDébilmenteRestringidas 1..Q no se muestran, pero se
describirán con mayor detalle con referencia a la Figura 7G). De
este modo los argumentos del establecimiento de declaraciones de
dependencias del productor 705 corresponden con los argumentos del
método alfa 710, y las ID de los argumentos en el establecimiento
de declaraciones de dependencias del productor 705 se siguen con
respecto a los productores hijos que identifican.
La Figura 7C ilustra seudo código de una
declaración de dependencias del productor para un método que usa
una dependencia declarada no de atajo, e ilustra un diagrama de
bloques de productores de ejemplo de acuerdo con una realización de
una realización de la invención. La Figura 7C muestra el
establecimiento de declaraciones de dependencias del productor 705
y el método alfa 710 de la Figura 7A, así como los productores 720 y
725 de la Figura 7B. Además, la Figura 7C incluye el código de
declaración de dependencias del productor 715 asociado con la
DependenciaArgumento 1. Durante el tiempo de ejecución, la rutina de
ejecución accede y ejecuta el código de declaración de dependencias
del productor 715 en respuesta con la DependenciaArgumento 1 del
establecimiento de declaraciones de dependencias del productor 705.
La ejecución del código de declaración de dependencias del
productor 715 devuelve al productor 725 como dependencias del
productor para la DependenciaArgumento 1. De este modo la Figura 7C
ilustra realizaciones de la invención en las cuales el código de
declaración de dependencias del productor 715 puede ser parte de un
método (distinto que el método alfa 710), pero no es parte de un
productor.
La Figura 7D ilustra un seudo código de un
declaración de dependencias del productor para un método que usa
una dependencia declarada no de atajo de acuerdo con una realización
de la invención; mientras que la Figura 7E es un diagrama de
bloques de productores de ejemplo de acuerdo con una realización de
la invención. La Figura 7D muestra el establecimiento de
declaraciones de dependencias del productor 705 y el método alfa 710
de la Figura 7A, mientras que la Figura 7E muestra los productores
720 y 725 de la Figura 7B. Además la Figura 7D incluye: 1) un
establecimiento de declaraciones de dependencias del productor 750;
y 2) un método beta 755 que incluye el código de declaración de
dependencias del productor 760. La Figura 7D también muestra que la
dependencia del argumento 1 del establecimiento de declaraciones de
dependencias del productor 705 identifica un productor (mostrado en
la Figura 7E como el productor 765) en base al método beta 755 que
devolverá la dependencia para la dependencia del argumento 1.
Durante el tiempo de ejecución, la rutina de ejecución, en
respuesta a la dependencia del argumento 1 del establecimiento de
declaraciones de dependencias del productor 705, ejecuta el
productor 765 para devolver la identificación que la dependencia del
productor para la dependencia del argumento 1 es el productor 725.
Como tal, el productor 765 se denomina como productor de
determinación de dependencias (su salida es la dependencia del
productor - y de este modo. se devuelve usando una clase/instancia
que se monitoriza en búsqueda de un tratamiento especial
(manipulación de los gráficos de productores por la rutina de
ejecución con el soporte de programación orientado a gráficos de
productores), mientras que el productor 725 se denomina como un
productor normalizado (su salida, si existe, no se procesa
directamente por la rutina de ejecución para manipular un gráfico
de productores; pero su salida, si existe, puede consumirse por un
productor padre (sea un productor de determinación de dependencia u
otro productor normalizado) y/o proporcionarse como la salida del
gráfico de productores (si el productor normalizado es un productor
de interés, y de este modo un nodo raíz).
De este modo, las Figuras 7D-E
ilustran realizaciones de la invención en las que el código de
declaración de dependencias del productor 715 es parte de otro
productor - denominado como un productor de determinación de
dependencias. Aunque en las Figuras 7D-7E el código
fuente orientado a objetos incluye el código explícito de la
declaración de dependencias del productor en métodos de los cuales
los productores de determinación de dependencias se representa en
el tiempo de ejecución por la rutina de ejecución para dependencias
declaradas no de atajo, realizaciones alternativas de la invención
adicionalmente o en su lugar implementan la rutina de ejecución
para incluir el código genérico de declaración de dependencias del
productor que los invoca como uno o más productores de
determinación de dependencias genéricos sobre la marcha para
dependencias declaradas de atajo. También, aunque las Figuras
7C-E se ilustran con referencia a las
DependenciasArgumento, las técnicas ilustradas son aplicables a
otros tipos de dependencias declaradas hacia abajo. Además, las
Figuras 7F- G ilustran el uso de un productor de determinación de
dependencias para una DependenciaHaciaArriba y una
DependenciaDébilmenteRestringida.
La Figura 7F es un diagrama de bloques de una
dependencia de ejemplo a través del uso de una
DependenciaHaciaArriba con un productor de determinación de
dependencias de acuerdo con una realización de la invención. La
Figura 7F muestra el productor 720 que tiene una dependencia del
productor de secuenciación para el productor de determinación de
dependencias 772. El productor de determinación de dependencias
puede devolver un argumento declarado hacia arriba de no
suscripción, un campo o una dependencia de secuenciación del
productor padre 748 sobre el productor 720. Además, tal productor
de determinación de dependencias puede implementar una dependencia
dinámica (por ejemplo, una dependencia contingente que selecciona
entre lo anterior que depende de valores de datos, incluyendo entre
ID de argumentos diferentes, como se describe más adelante en este
documento). Aunque algunas realizaciones de lo invención soportan
todas estas posibilidades, realizaciones alternativas de la
invención sólo soportan un subconjunto (por ejemplo, sólo
dependencias de secuenciación declaradas hacia arriba de no
suscripción).
La Figura 7G es un diagrama de bloques de
dependencias de ejemplo posibles a través del uso de una
DependenciaDébilmenteRestringida con un productor de determinación
de dependencias de acuerdo con una realización de la invención. La
Figura 7G muestra al productor 720 que tiene una dependencia del
productor de secuenciación para el productor de determinación de
dependencias 775. En algunas realizaciones de la invención, el
productor de determinación de dependencias puede devolver
cualquiera de los siguiente: 1) una dependencia de secuenciación
declarada hacia abajo no de suscripción sobre un productor hijo
780; 2) una dependencia de argumento, campo o secuenciación
declarada hacia arriba, no de suscripción del productor padre 785
sobre el productor 720; y 3) una suscripción adherente (descrita
más adelante en este documento). Además, tal productor de
determinación de dependencias puede implementar una dependencia
dinámica (por ejemplo, una dependencia contingente que selecciona
entre los anteriores dependiendo de los valores de los datos,
incluyendo las diferentes ID de argumentos, como se describe más
adelante en este documento). Aunque algunas realizaciones de la
invención soportan todas estas posibilidades, realizaciones
alternativas de la invención sólo soportan un subconjunto (por
ejemplo dependencias de secuenciación declaradas hacia arriba no de
suscripción).
Como se ha indicado anteriormente, las
dependencias de secuenciación pueden usarse para una diversidad de
propósitos, incluyendo asegurar el orden de ejecución entre
productores que modifican datos en un modo que la rutina de
ejecución no conoce y los productores que consumen estos datos (un
productor hijo puede escribir sus salidas en un modo que requiere
el método del productor padre para incluir código para acceder a esa
salida (por ejemplo un método que impacta el entorno afectando una
salida que no es la salida del productor regular y, como tal, que
no es detecta por la rutina de ejecución - tal como un método que
fija un variable global, que fija un campo en una instancia que no
es la salida del productor, que impacta una fuente de datos externa,
etc,)), etc.
Diferentes realizaciones pueden soportar una o
más formas de declarar las dependencias del productor con respecto
a los productores de propiedad. Específicamente, en algunas
realizaciones de la invención, los productores que leen un campo
deberían ser dependientes del productor de obtención de propiedad,
mientras que el productor de obtención de propiedad debería ser
dependiente sobre cualesquiera productores que fijan el campo para
el cual es sensible el método de obtención de propiedad. Una
técnica de manejar esta situación que puede usarse en realizaciones
de la invención que soportan las dependencias del productor de
secuenciación es proporcionar, para un método de obtención de
propiedad, un establecimiento de declaraciones de dependencias del
productor que crea dependencias del productor de secuenciación
sobre cada método que fija el campo para el cual es sensible ese
método de obtención de propiedad (por ejemplo, con respecto a la
Figura 7G, donde el productor 780 es un productor que fija un campo
y el productor 720 es el productor de obtención de propiedad
sensible para ese campo, el productor de determinación de
dependencias 775 se escribiría para devolver una dependencia de
secuenciación declarada hacia abajo del productor 720 sobre el
productor 780). Una segunda técnica de manejar esta situación que
puede usarse en las realizaciones de la invención que soporta tanto
dependencias del productor de secuenciación como las dependencias
del productor declaradas hacia arriba es incluir en el
establecimiento/código de declaraciones de dependencias del
productor para cualquier método que fija un campo, una dependencia
del productor de secuenciación declarada hacia arriba (por ejemplo
usando una DependenciaHaciaArriba o una
DependenciaDébilmenteRestringida) sobre el método de obtención
sensible para ese campo (por ejemplo, con respecto a la Figura 7G,
donde el productor 720 es un productor que fija un campo y el
productor 785 es el productor de obtención de propiedad sensible
para ese campo, el productor de determinación de dependencia 775
escribiría para devolver una dependencia de secuenciación declarada
hacia arriba del productor padre 785 sobre el productor 720). Esta
segunda técnica permite al programador del método que fija el campo
que será sensible para proporcionar una dependencia del productor
para el método de obtención apropiado, en oposición a requerir que
el programador vaya al método de obtención y modifique su
establecimiento/código de declaraciones de dependencias del
productor.
Cuando se usan dependencias de secuenciación,
cuando un productor determinado depende de una variable determinada,
esa variable no debería modificarse por más de uno de los
productores descendientes de ese productor en una ejecución
determinada del gráfico de productores (debería observarse que a
través de las dependencias contingentes (descritas más adelante en
este documento), diferentes productores descendientes pueden
modificar esa variable durante las diferentes ejecuciones de los
gráficos de productores actuales. Por ejemplo, un productor de
obtención de propiedad debería depender sólo de otro productor que
fija el campo para el cual el productor de obtención de propiedad
es sensible en una ejecución determinada de los gráficos de
productores actuales.
Debería entenderse que las diferentes
realizaciones de la invención pueden implementar una o más de las
realizaciones de la invención mostradas en las Figuras
7A-F. Por ejemplo, una realización de la invención
soporta dependencias declaradas de atajo y no de atajo, usando
ambas productores de determinación de dependencias; específicamente,
en esta realización de la invención: 1) el código fuente orientado
a objetos incluye el código explícito de declaración de
dependencias del productor en métodos desde los cuales los
productores de determinación de dependencias están representados en
el tiempo de ejecución por la rutina de ejecución para las
dependencias declaradas de no atajo; 2) la rutina de ejecución
incluye el código genérico de declaración de dependencias del
productor que invoca uno o más como productores genéricos de
determinación de dependencias sobre la marcha para dependencias
declaradas atajos, contingentes (descritas más adelante en este
documento); y 3) la rutina de ejecución incluye un soporte para
enlazar directamente las dependencias del productor no contingentes,
declaradas de atajo (descritas más adelante en este documento).
Como otro ejemplo, una realización de la
invención soporta dependencias del productor declaradas de atajo y
no de atajo usando productores de determinación de dependencia;
específicamente, en esta realización de la invención: 1) el código
fuente orientado a objetos incluye el código explícito de
declaración de dependencias del productor en métodos desde los
cuales los productores de determinación de dependencias están
representados en el tiempo de ejecución por la rutina de ejecución
para las dependencias declaradas no de atajo; y 2) la rutina de
ejecución incluye el código genérico de determinación de
dependencias que se invoca como uno o más productores genéricos de
determinación de dependencias sobre la marcha para las dependencias
declaradas de atajo (independientemente del tipo). Esta última
realización permite un tratamiento consistente de las dependencias
del productor, y de este modo, simplifica la rutina de
ejecución.
Además, aunque en una realización de la
invención el establecimiento de declaraciones de dependencias del
productor para un método está localizado justo encima de ese método
en el código fuente orientado a objetos, en realizaciones
alternativas de la invención está localizado en otro sitio (por
ejemplo, los establecimientos de declaraciones de dependencias del
productor para todos los métodos para una clase están agrupados
juntos dentro de la clase, los establecimientos de declaraciones de
dependencias del productor para todos los métodos en todas las
clases se agrupan juntos como una tabla de datos separada, etc.).
También, aunque en una realización de la invención el código de
declaración de dependencias del productor de la invención está
separado de los establecimientos de declaraciones de dependencias
del productor, en realizaciones alternativas de la invención están
combinados (por ejemplo, el código de declaración de dependencias
del productor está dentro del paréntesis del establecimiento de
declaraciones de dependencias del productor, el código de
declaraciones de dependencias del productor está situado
directamente debajo del establecimiento de declaraciones de
dependencias del productor y se trata por la rutina de ejecución
como una unidad única, etc.).
Las Figuras 7H-I ilustran la
distinción entre diferentes sub-gráficos que pueden
existir en un gráfico de productores debido a los productores de
determinación de dependencias. La figura 7H ilustra gráficos de
productores de ejemplo de productores normalizados de acuerdo con
una realización de la invención. Específicamente, la Figura 7H
muestra un gráfico de productores con un nodo raíz S1, un gráfico de
productores con un nodo raíz S5, y un gráfico de productores con un
nodo raíz S11. El productor normalizado S1 tiene como productores
hijos normalizados S2, S3, y S4; los productores normalizados S2 y
S3 tienen productores hijos normalizados S7 y S8; el productor
normalizado S5 tiene como productores hijos normalizados S4 y ; y el
productor normalizado S11 tiene productores hijos normalizados S6 y
S10. Los gráficos de productores de ejemplo de la figura 7H pueden
descubrirse, construirse, y resolverse usando cualquier número de
dependencias del productor y los productores de determinación de
dependencias. La Figura 7I ilustra un ejemplo de dependencias de
productores y productores de determinación de dependencias para
descubrir, resolver y construir el gráfico de productores de la
Figura 7H. Específicamente, la Figura 7I muestra los gráficos de la
Figura 7H como sub-gráficos de un gran conjunto de
gráficos de productores. En otras palabras, los gráficos de
productores de la Figura 7I incluyen los gráficos de la Figura 7H
(denominados como "sub-gráficos objetivos" e
ilustrados usando líneas continuas con flecha y óvalos continuos) y
los gráficos que asisten en el descubrimiento, resolución y
construcción de los sub-gráficos objetivo
(denominados como "sub-gráficos de decisión" e
ilustrados usando líneas discontinuas con flecha y óvalos
discontinuos). Los sub-gráficos de decisión en la
Figura 7H incluyen productores de determinación de dependencia
(DDP) 1-11 y productores normalizados
S9-10. En la Figura 7H, S1 se muestra como
dependiente sobre los DDP 1-3, que devuelven
respectivamente las dependencias de productor declaradas hacia abajo
de S1 sobre S2, S3, y S4; S4 se muestra como dependiente sobre
DDP4, que devuelve una dependencia del productor declarada hacia
arriba de S5 sobre S4; S5 se muestra como dependiente sobre DDP5,
que devuelve una dependencia del productor declarada hacia abajo de
S5 sobre S6; S3 se muestra como dependiente sobre DDP6, que ha su
vez es dependiente sobre DDP8, que devuelve una dependencia del
productor declarada hacia abajo de DPP6 sobre S9 y S10, que causa
que DDP6 devuelva una dependencia declarada hacia abajo de S3 sobre
S7; S3 se muestra como dependiente sobre DDP7, que devuelve una
dependencia del productor declarada hacia abajo de S3 sobre S8; S8
se muestra como dependiente sobre DDP9, que devuelve una suscripción
adherente para la cual S6 es un productor de disparo y S11 es el
padre creado (de este modo, la dependencia del productor de S11
sobre S6); S2 se muestra como dependiente sobre DDP10, que devuelve
una colección de dependencias del productor declaradas hacia abajo
de S2 sobre S7 y S8; y S11 se muestra como dependiente sobre
DDP11,que devuelve una dependencia del productor declarada hacia
abajo de S11 sobre S10. debería entenderse que un productor
normalizado puede ser tanto parte de un sub-gráfico
objetivo como un sub-gráfico de decisión (por
ejemplo, véase S10). Merece la pena observar que los
sub-gráficos objetivos son datos controlados en el
sentido de que los datos fluyen desde un productor normalizado a
otro productor normalizado hacia arriba en el gráfico.
La Figura 8A es un diagrama de bloques que
ilustra una primera estructura de ejemplo dentro de la cual se
proporcionan aplicaciones a los usuarios finales de acuerdo con una
realización de la invención. La estructura mostrada en la Figura 8A
incluye tres divisiones básicas. La primera división incluye la
creación de la rutina de ejecución con el soporte de programación
orientado gráficos de productores 810. Esta primera división se
realiza por los programadores con experiencia de programación
altamente avanzada. Cuando se trabaja en esta división los
programadores se denominan como programadores de la rutina de
ejecución. Cuando se crea una rutina de ejecución con un soporte de
programación orientado a gráficos de productores, los programadores
de la rutina de ejecución incluyen soportes para gráficos de
productores, así como el soporte para la ejecución de los diversos
tipos de comandos usados en el código de transformación, código de
representación, y código de preparación de datos.
La segunda división incluye la creación del
código fuente de la aplicación orientada a objetos 820 a ejecutar
por la rutina de ejecución. El código fuente de aplicación orientado
a objetos 820 incluye dos divisiones básicas; 1) definiciones de
clases que incluyen la lógica del negocio expresada en métodos con
las declaraciones de dependencias del productor 822 (esto puede
incluir opcionalmente otras funcionalidades, tales como una
interfaz gráfica de usuario - en cuyo caso, la interfaz gráfica de
usuario está escrita usando productores y declaraciones de
dependencias del productor); y 2) definiciones de clases que
incluyen código del cliente expresado en métodos 824, incluyendo el
código de representación (clases, instancias, y productores de
interés, para causar la generación de los gráficos de productores)
824, el código de preparación de datos 824B (por ejemplo, comandos
de fijación, tales como los comandos de fijación que disparan la
anulación de las salidas del productor), comandos de ejecución
global 824C para causar la ejecución de gráficos de productores (por
ejemplo, los comandos de ejecutar y obtener), y cualquier interfaz
gráfica del usuario requerida 824D (no incluida en 822). Las
declaraciones de dependencias del productor se usan para definir las
ataduras entre productores durante la definición de clases que
incluye la lógica del negocio, más bien que después de crearse las
instancias de esas clases. El código fuente orientado a objetos 820
son clases, instancias y métodos codificados directamente que se
compilan y se ejecutan.
Aunque en una realización de la invención se
implementa un comando de ejecución global, cuya ejecución causa el
intento de ejecución de todos los gráficos de productores
actualmente en la estructura de gráficos de productores 380,
realizaciones alternativas de la invención también o
alternativamente implementan un comando de ejecución específica de
gráficos que requiere la identificación del gráfico determinado de
los gráficos de productores actuales que se va a ejecutar. Además,
el comando de ejecución global puede ser explicito (por ejemplo,
fijar, fijar, fijar, ejecutar, obtener, obtener) o implícito
dependiendo de la implementación de la rutina de ejecución. Por
ejemplo, un comando de ejecución global implícito podría ser 1)
disparar por el primer comando de obtención de un productor de
interés (por ejemplo, fijar, fijar, fijar, obtener (ejecución
implícita), obtener); 2) disparado por cada manipulación de datos
(fijar (ejecución implícita), fijar (ejecución implícita), fijar
(ejecución implícita) obtener, obtener); etc.
La segunda división se realiza de nuevo por
programadores con experiencia de programación avanzada, así como
con un entendimiento de los objetivos del negocio de la aplicación.
Cuando se trabaja en esta división, los programadores se denominan
como programadores de aplicaciones. Como parte de esto, si la
aplicación requiere una interfaz gráfica de usuario, los
programadores de aplicaciones también diseñan y codifican la
interfaz gráfica de usuario para la aplicación específica; y de este
modo se denominan como diseñadores de aplicaciones.
La tercera división incluye el uso de los
programas de aplicaciones que se corren por la rutina de ejecución.
La tercera división se realiza por los usuarios finales que no
necesitan tener ninguna experiencia de programación. El programa de
aplicación puede distribuirse en una diversidad de modos (por
ejemplo, como código fuente; una transformación del código fuente,
tal como el código de octetos de bits; como binario, etc.). Además,
el programa de aplicación puede distribuirse para uso individual 830
(en cuyo caso, todo el programa de aplicación (y la rutina de
ejecución si no está ya presente) se proporciona a un sistema de
ordenador) y/o un uso del cliente/servidor. En una realización de
la invención, una distribución de cliente/servidor incluye
distribuir las definiciones de clases que incluyen la lógica de
negocio expresada en métodos con las declaraciones de dependencias
del productor 822 (y la rutina de ejecución sin no está ya presente)
para uso del servidor 832 y las definiciones de clases que incluyen
el código del cliente expresado en métodos 824 (y la rutina de
ejecución sin no está ya presente) para uso del cliente 834, donde
el uso del cliente 834 sobre el sistema de ordenador causa una
comunicación con el uso del servidor 832 sobre el sistema del
servidor.
La Figura 8A también muestra un módulo opcional
de interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840 que se proporciona para un
uso independiente 830 y un uso de cliente 834. El código fuente
orientado a objetos 820 se correría por la rutina de ejecución para
generar los gráficos de productores, y el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 permite la representación en pantalla
de forma gráfica desde las salidas e interactuar con los gráficos
de productores. Específicamente, el módulo de interfaz gráfica de
usuario de la distribución de salidas del productor configurable
interactiva 840 incluye: 1) un módulo de configuración y mapeo de la
interfaz gráfica del usuario 844 para permitir la configuración de
la distribución y mapeo de las salidas seleccionadas del productor
(por ejemplo, áreas de la pantalla a utilizar, cómo se presentan en
pantalla los datos, etc.); y 2) un módulo de interfaz gráfica de
usuario de interpretación e inter-actuación 846 para
interpretar la distribución configurada y permitir la anulación de
las salidas del productor (que da como resultado la actualización
de los gráficos de productores a través de un comando de ejecución
global). Deberá entenderse que el módulo de interfaz gráfica de
usuario de la distribución de salidas del productor configurable
interactiva 840 puede crearse o no por la misma entidad que escribe
la rutina de ejecución 810.
La Figura 8B es un diagrama de bloques que
ilustra una segunda estructura de ejemplo dentro de la cual se
proporcionan las aplicaciones a los usuarios finales de acuerdo con
una realización de la invención. La Figura 8B es idéntica que la
Figura 8A, con las siguientes excepciones: 1) no está presente el
uso independiente 830; 2) el código fuente orientado a objetos 820
se proporciona al uso del servidor 832, mientras que el código del
cliente 824 no se proporciona para uso del cliente 834; 3) el módulo
de interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840 se proporciona al uso del
servidor 832 y no al uso del cliente 834; y 4) la interfaz genérica
configurable interactiva del cliente de distribución de salidas del
productor 855 se proporciona para uso del cliente 834. La interfaz
genérica configurable interactiva del cliente de distribución de
salidas del productor 855 se usa para hacer interfaz con el módulo
de interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840.
Independientemente de la estructura utilizada,
en una realización de la invención la estructura de programación
orientada a gráficos de productores ofrece la capacidad de interfaz
con programas no escritos con declaraciones de dependencias del
productor. Esta capacidad para hacer interfaz con programas no
escritos con declaraciones de dependencias del productor incluye:
1) una parte llamante (tal como una interfaz de gráfica de usuario
no escrita de acuerdo con la programación orientada a gráficos de
productores); y 2) una parte llamada (tal como una fuente de datos
externa no escrita de acuerdo con la programación orientada a
gráficos de productores). La parte llamante puede, a través del
código de cliente, emitir comandos de programación orientados a
gráficos de productores. La parte llamada se implementa como la
parte de productores que envuelven la parte llamada (denominada
como "productores de envoltura"). Ejecutando la parte llamada
(tal como leyendo datos desde un fuente de datos o suscribiendo
cambios de los datos en una fuente de datos externa) puede a su vez
disparar modificaciones de instancias. Estos cambios pueden ocurrir
llamando los métodos de fijación de propiedad en el código de los
productores de envoltura. Los productores de obtención de propiedad
(recuperadores) se causa que tengan dependencias sobre estos
productores de envoltura, para asegurarse que las modificaciones de
instancias disparadas por los cambios que ocurren en una fuente de
datos externa se propagan adecuadamente a través del gráfico de
productores. Como se ha descrito anteriormente, diferentes
realizaciones pueden soportar uno o más modos de declarar
dependencias del productor con respecto a los productores de
propiedad. Por ejemplo, en algunas realizaciones de la invención
que soportan dependencias de secuenciación del productor, pueden
usarse las DependenciasSecuenciación para declarar las dependencias
del productor de secuenciación declaradas hacia debajo de no
suscripción sobre los productores de envoltura. Como otro ejemplo
más, en algunas realizaciones de la invención que soportan
dependencias del productor de secuenciación y dependencias del
productor declaradas hacia arriba de no suscripción, pueden
situarse las DependenciasHaciaArriba y/o las
DependenciasDébilmenteRestringidas en la declaración de
dependencias del productor de los productores de envoltura para
crear dependencias del productor de secuenciación declaradas hacia
arriba de no suscripción para los productores de propiedad.
Las Figuras 8C-F ilustran
capturas de pantalla de ejemplo y el uso del módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención. Aunque las realizaciones de la invención se describirán
con referencia al módulo de interfaz gráfica de usuario de la
distribución de salidas del productor configurable interactiva 840
que proporciona la configuración, mapeo, e interacción con las
salidas seleccionadas de los gráficos de productores actuales en la
forma de una hoja de cálculo, pueden implementarse realizaciones
alternativas de la invención para proporcionar adicionalmente o
como alternativa un soporte para otra forma. Además, aunque se
describen modos de ejemplo de realizar la configuración, mapeo, e
interacción en la forma de una hoja de cálculo de acuerdo con
algunas realizaciones de la invención, otras realizaciones de la
invención pueden realizar estas operaciones de otro modo, con
diferente interfaz; y/o con una distribución de pantalla diferente.
Además, la hoja de cálculo puede soportar cualquiera de las
funcionalidades conocidas asociadas con las hojas de cálculo (por
ejemplo, selección de color, selección de fuentes, gráficos de
barras, de tarta, de líneas, tablas dinámicas, distribución de
ahorros, distribución de cargas, etc.)
Las Figuras 8C-D ilustran
capturas de pantalla de ejemplo y el uso de la selección libre de
células de acuerdo con una realización de la invención, mientras
que las Figuras 8E-F ilustran capturas de pantalla
de ejemplo y el uso de la creación de tablas de acuerdo con una de
las realizaciones de la invención: Cada una de las Figuras
8C-F incluye una barra de menú 850 a lo largo de la
parte superior de la pantalla, una lista de clases (con sus métodos
de obtención de propiedad) 852 de los productores en el gráfico de
productores actual y sus salidas hacia abajo al lado izquierdo de
la pantalla, y un visor de configuración y mapeo 854 que rellena el
resto de la pantalla con una hoja de cálculo como distribución.
Además, las Figuras 8C-F también muestran de
ejemplo la siguiente lista de clases con sus métodos de obtención de
propiedades en la lista 852; 1) la clase PERSONA; 2) los métodos de
obtención de propiedad de la clase persona incluyendo su NOMBRE (por
ejemplo, una cadena de caracteres) APELLIDOS (por ejemplo, una
cadena de caracteres), GÉNERO (por ejemplo, una cadena de
caracteres), DIRECCIÓNCASA (una instancia de la clase DIRECCIÓN),
DIRECCIÓNPROFESIÓN (una instancia de la clase DIRECCIÓN),
FECHANACIMIENTO (por ejemplo, una fecha), y EDAD (por ejemplo, un
número entero); 3) la clase DIRECCIÓN; y 4) los métodos de
obtención de propiedad de la clase DIRECCIÓN incluyendo CIUDAD (por
ejemplo, una cadena de caracteres), ESTADO (por ejemplo, una cadena
de caracteres) CÓDIGOPOSTAL (por ejemplo, una cadena de
caracteres). Como tal, el gráfico de productores actual incluye los
productores de las clases PERSONA y DIRECCIÓN así como productores
cuyas salidas son de las clases PERSONA y DIRECCIÓN. También merece
la pena observar que el método de obtención de propiedad EDAD
calcula la edad en base a la salida del método de obtención de
propiedad FECHANACIMIENTO; como tal, un productor representado por
el método de obtención de propiedad EDAD será dependiente del
productor representado a partir del método de obtención de propiedad
FECHANACIMIENTO.
Las Figuras 8C-D muestran el
siguiente texto libre introducido, en células consecutivas de la
primera columna del visor: CLIENTE, NOMBRE, APELLIDOS, FECHA DE
NACIMIENTO y EDAD; mientras que las Figuras 8E-F
muestran los siguiente: 1) texto libre introducido en la primera
fila del visor - LISTA DE CLIENTES; y 2) texto libre introducido en
células consecutivas de la segunda fila del visor NOMBRE, APELLIDOS,
FECHA DE NACIMIENTO y EDAD.
La Figura 8C ilustra una captura de pantalla de
ejemplo y el uso de la selección libre de células con el módulo de
interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840 de acuerdo con una
realización de la invención. La Figura 8C muestra un conjunto de
mapeos 856 de la clase PEROSNA y los métodos seleccionados de
obtención de propiedad de la clase PERSONA para las diferentes
células del visor. Específicamente, la clase PERSONA está situada
en la célula de la derecha del texto libre CLIENTE. Como parte de
esta acción, algunas realizaciones de la invención invitan al
usuario a seleccionar desde uno de varios filtros soportados
(mostrados como la selección de filtros 858) (por ejemplo, lista
desplegable, flechas de formas de desplazamiento, etc.). Estos
filtros posibilitan la selección de una o más claves de instancias
de los productores de la clase seleccionada, o uno o más claves de
instancias de los productores cuya clase de salida es la clase
seleccionada. Aunque algunas realizaciones de la invención soportan
varios filtros, otras realizaciones de la invención presentan uno
(y permiten al usuario elegir si seleccionar uno diferente) o
sopórtanoslo uno y no necesitan realizar la selección de filtros
858. Los mapeos 856 también muestran que los métodos de obtención
de propiedad NOMBRE, APELLIDOS, FECHA DE NACIMIENTO y EDAD de la
clase PERSONA se sitúan respectivamente en las células adyacentes a
las células con el texto libre correspondiente. Tal mapeo puede
realizarse con cualquiera de varias técnicas bien conocidas,
incluyendo el arrastrar y soltar, tecleando en un campo de la
Interfaz Gráfica de Usuario, etc.
La Figura 8D ilustra otra captura de pantalla de
ejemplo y el uso de la selección de células libres con el módulo de
interfaz gráfica de usuario de la distribución de salidas del
productor configurable interactiva 840 de acuerdo con una
realización de la invención. La Figura 8D muestra la célula a la
cual se mapeo la clase PERSONA para permitir la selección de
instancias 854. Específicamente, en base al filtro utilizado para
esta célula, al usuario se le da la oportunidad de seleccionar una
instancia de la clase PERSONA desde una lista que incluye las
claves de instancias de los productores de la clase PERSONA y las
claves de instancias de los productores que producen la clase
PERSONA. La selección de la instancia de la clase PERSONA (o la
existencia de una instancia única) da como resultado la repoblación
automática de las células, para las cuales se mapearon los métodos
de obtención de propiedad de la clase PERSONA, con las salidas de
los métodos de obtención de propiedad correspondientes a esa
instancia. Esta repoblación de la tabla en base a las instancias de
la clase PERSONA se etiqueta como 858. En el ejemplo de la Figura
8D, las células a las cuales se mapearon los métodos de obtención
de propiedad NOMBRE, APELLIDOS, FECHA DE NACIMIENTO
y EDAD de la clase PERSONA se rellenaron respectivamente con JHON, SMITH, 7/20/1990, y 16.
y EDAD de la clase PERSONA se rellenaron respectivamente con JHON, SMITH, 7/20/1990, y 16.
La Figura 8D también muestra que las células del
visor a las cuales se han mapeado los métodos de obtención de
propiedad pueden anularse. A modo de ejemplo, la Figura 8D muestra
que si la célula a la cual se mapea el método de obtención de
propiedad FECHANACIMIENTO se anula, entonces causará la anulación de
la salida del productor cuya salida está rellenando actualmente esa
célula, la invocación de un comando de ejecución global (el cual
daría como resultado la reejecución del productor cuya salida está
rellenando actualmente la célula a la cual está mapeado el método
de obtención de propiedad EDAD), y cualquier actualización necesaria
de la pantalla.
La Figura 8E ilustra una captura de pantalla de
ejemplo y el uso de la creación de tablas con el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención. La Figura 8E muestra que se realiza una operación de
selección de zona y de orientación 864 para identificar una tabla
vertical de filas de árbol directamente debajo de las células con
texto libre NOMBRE, APELLIDOS, FECHA DE NACIMIENTO y EDAD
(ilustradas con una delgada línea discontinua alrededor de estas
células). Diferentes realizaciones de la invención pueden soportar
la realización por el usuario de esta operación de cualquiera de
los diversos modos (incluyendo: 1) selección de un área con un
dispositivo de entrada como un ratón, y 2) selección entre una tabla
vertical horizontal, o de giro con una interfaz tal como un menú de
ventanas emergentes - asumiendo que se soportan múltiples
orientaciones). La Figura 8E también muestra un conjunto de mapeos
866 de los métodos de obtención de propiedad seleccionados de la
clase PERSONA a las diferentes células del visor. Específicamente,
los mapeos 866 muestran que los métodos de obtención de propiedad
NOMBRE, APELLIDOS, FECHANACIMIENTO, y EDAD de la clase PERSONA se
mapean respectivamente a las células directamente debajo de las
células con el texto libre correspondiente.
La Figura 8F ilustra otra captura de pantalla de
ejemplo y el uso de la creación de tablas con el módulo de interfaz
gráfica de usuario de la distribución de salidas del productor
configurable interactiva 840 de acuerdo con una realización de la
invención. Los mapeos 866 dan como resultado la repoblación
automática de las columnas de la tabla, a las cuales se mapearon
los métodos de obtención de propiedad de la clase PERSONA, con las
salidas de los métodos obtención de propiedad correspondientes de
las instancias de esa clase. Esta repoblación de la tabla en base a
las instancias de la clase PERSONA se etiqueta con 868. En el
ejemplo de la Figura 8D, las columnas a las cuales se mapearon los
métodos de obtención de propiedad NOMBRE, APELLIDOS,
FECHANACIMIENTO, y EDAD de la clase PERSONA se rellenaron con las
siguiente filas de datos: 1) STEVE, COLLINS, 20/07/1990, y 16; 2)
JENNIFER, ADAMS, 20/07/1990, y 16; y 3) JOHN, SMITH, 20/07/1985, y
21.
Como en la Figura 8D, la Figura 8F muestra que
las células del visor a las cuales se han mapeado los métodos de
obtención de propiedad pueden anularse. A modo de ejemplo, la Figura
8F muestra que si la célula de la segunda fila de la columna a la
cual está mapeado el método de obtención de propiedad
FECHANACIMIENTO se anula, entonces causará la anulación de la
salida del productor cuya salida está rellenando actualmente esa
célula, la invocación de un comando global de ejecutar (que daría
como resultado una reejecución del productor cuya salida está
rellenando actualmente la célula a la cual está mapeado el método de
obtención de propiedad EDAD), y cualquier actualización necesaria de
la pantalla.
Las Figuras 8C-F ilustran
pantallas de ejemplo generadas por el módulo de interfaz gráfico de
usuario de configuración y mapeo 842. Las pantallas generadas por
el módulo de interpretación y de interfaz gráfico de usuario
interactiva 846 son lo mismo, con la excepción de que la lista de
clases (con sus métodos de obtención de propiedad) 852, la
configuración y el visor del mapeo 854 se reemplazan por un visor de
interpretación interactivo (no mostrado) que contiene la misma
imagen que el visor de configuración y mapeo 854 presentado en
pantalla (siendo la diferencia la característica de mapeo que ya no
está disponible).
Las Figuras 9A-C ilustran varios
esquemas para distribuir una rutina de ejecución con el soporte de
programación orientado a gráficos de productores. Debería
entenderse que estos esquemas de distribución son de ejemplo, y de
este modo otros esquemas están dentro del alcance de la
invención.
La Figura 9A es un diagrama de bloques que
ilustra un primer esquema para distribuir una rutina de ejecución
con un soporte de programación orientado a gráficos de productores
de acuerdo con una realización de la invención. En la Figura 9A, se
muestra el código fuente orientado a objetos 905 (que incluiría
declaraciones de dependencias del productor) sobre la parte
superior de una rutina de ejecución con un soporte de programación
orientado a gráficos de productores 910, que está en la parte
superior de una rutina de ejecución con la carga de clases, la
representación de clases dinámicas, invocación de métodos únicos
dinámicos, y la introspección de clases/métodos 915, que está en la
parte superior del sistema operativo 920. En la Figura 9A, la rutina
de ejecución 910 funciona con la rutina de ejecución 915. Aunque
puede usarse cualquiera de varios mecanismos para permitir que la
rutina de ejecución 910 funcione con la rutina de ejecución 915, se
describe una facilidad de los metadatos a modo de ejemplo. Una
facilidad de metadatos permite añadir información adicional al
código fuente, cuya información se usa por las herramientas de
desarrollo. Por ejemplo la Facilidad de Metadatos para la
especificación de Java define una API para campos de anotación,
métodos y clases que tienen atributos particulares que indican que
deberían procesarse en modos especiales por las herramientas de
desarrollo, las herramientas de despliegue, o las librerías de
rutinas de ejecución (Petición de Especificación Java 175). En este
ejemplo, un programador que programa un código fuente orientado a
objetos 905 añadiría anotaciones a los métodos en la forma de
declaraciones de dependencias del productor. Como estas anotaciones
se manejan por la rutina de ejecución 915 para la rutina de
ejecución 910, la rutina de ejecución 910 dicta la sintaxis de las
declaraciones de dependencias del productor. En la Figura 9A las
rutinas de ejecución 910 y 915 pueden desarrollarse y/o distribuirse
por diferentes organizaciones.
La Figura 9B es un diagrama de bloques que
ilustra un segundo esquema para distribuir una rutina de ejecución
con el soporte de programación orientado a gráficos de productores
de acuerdo con una realización de la invención. En la Figura 9B, se
muestra el código fuente orientado a objetos 925 (que incluiría las
declaraciones de dependencias del productor) sobre la parte
superior de una rutina de ejecución (con carga de clases,
representación dinámica de clases, invocación dinámica de métodos
únicos e introspección de clases/métodos, así como el soporte de
programación orientado a gráficos de productores) 930, que está en
la parte superior del sistema operativo 935. En comparación con la
Figura 9A, las rutinas de ejecución 910 y 915 se han combinado en
una rutina de ejecución única 930. Como resultado de esta
combinación, la rutina de ejecución 930 dicta la sintaxis de las
declaraciones de dependencias del productor. De este modo, el
programador que programa el código fuente orientado a objetos 925
añadiría las declaraciones de dependencias del productor en la
sintaxis requerida.
La Figura 9C es un diagrama de bloques que
ilustra un tercer esquema para distribuir una rutina de ejecución
con el soporte de programación orientado a gráficos de productores
de acuerdo con una realización de la invención. En la Figura 9C, se
muestra el código fuente orientado a objetos 940 (que incluiría las
declaraciones de dependencias del productor) sobre la parte
superior de la rutina de ejecución del sistema operativo (con carga
de clases, representación dinámica de clases, invocación dinámica
de métodos únicos, e introspección de clases/métodos, así como el
soporte de programación orientado a gráficos de productores) 945. En
comparación con la Figura 9B, la rutina de ejecución 920 y el
sistema operativo 935 se han combinado dentro de una entidad única.
Como resultado de esta combinación, la rutina de ejecución del
sistema operativo 945 dicta la sintaxis de las declaraciones de
dependencias del productor. De este modo, el programador que
programa el código fuente orientado a objetos 940 añadiría
declaraciones de dependencias del productor en la sintaxis
requerida.
Aunque se han descrito realizaciones en las
cuales la rutina de ejecución tiene carga de clases, representación
dinámica de clases, invocación dinámica de métodos únicos, e
introspección de clases/métodos, realizaciones alternativas pueden
incluir más o menos características (por ejemplo, clonación de
instancias, representantes dinámicos, conversiones de tipos de
primitivas, etc.)
En una realización de la invención, las
dependencias del productor se declaran para métodos como un modo
para especificar la secuenciación de invocación de métodos usando
las instancias apropiadas (donde las instancias apropiadas incluyen
instancias a usar como argumentos, las instancias a utilizar por los
métodos de instancias, y las instancias de meta clases usadas por
los métodos de clases) sin usar el código de secuenciación de
invocación manual. Efectivamente, el trabajo de generar algo o todo
el código de secuenciación de invocación manual se reemplaza con:
1) el trabajo hecho por el programador de aplicación para escribir
las declaraciones de dependencias del productor; y 2) el trabajo
hecho por la rutina de ejecución para descubrir y construir los
gráficos de productores y ejecutar los productores de esos gráficos
de productores. En otras palabras, la lógica que estaba contenida
anteriormente en el código de secuenciación de invocación manual se
puede descubrir por la rutina de ejecución durante el tiempo de
ejecución en base a las declaraciones de dependencia de productor.
De este modo, las declaraciones de dependencias de productor
informan a la rutina de ejecución de qué métodos y qué instancias
con qué argumentos ejecutar, y cuándo para propósitos de
sincronización. Aunque el esfuerzo de escribir la rutina de
ejecución es relativamente grande, sólo se necesita escribir una vez
ya que puede usarse para ejecutar cualesquiera aplicaciones
orientadas a objetos escritas para la rutina de ejecución; en
contraste, para una aplicación típica, el esfuerzo de escribir las
declaraciones de dependencias del productor es relativamente bajo
en comparación con escribir el código de secuenciación de invocación
manual.
La programación orientada a gráficos de
productores típicamente reduce los costos asociados con la
depuración y/o ajuste del funcionamiento del código de
secuenciación de invocación manual. Esto es cierto al menos por la
razón de que la infraestructura de un programa de aplicación
conceptualmente es un conjunto de gráficos no formalizados de
métodos de transformación de objetos (la salida de un método
asociado con un objeto es la entrada del otro, y así sucesivamente)
que funciona sobre las entradas especificas. Las declaraciones de
dependencias del productor y la rutina de ejecución con el soporte
de programación orientado a gráficos de productores formalizan
estos gráficos como gráficos de productores. De este modo, en cada
oportunidad para cambiar datos, el programador de la aplicación no
necesita considerar su efecto y escribir el código de secuenciación
de invocación manual para causar los métodos de transformación
apropiados de las instancias apropiadas a invocar en el orden
apropiado con las entradas apropiadas. En otras palabras, para cada
una de las oportunidades de cambiar datos, el programador de la
aplicación no necesita considerar qué gráficos están afectados, así
como qué métodos de transformación de instancias dentro de esos
gráficos están afectados. En cambio, el módulo de generación
automatizada de gráficos de productores descubre y construye los
gráficos de productores y el módulo de ejecución de gráficos de
productores reejecuta los gráficos de productores según se necesite
para reflejar los cambios en los datos. Este automatismo ayuda a
los programadores de la aplicación a evitar errores tales como: 1)
invocar los métodos de trasformación apropiados de las instancias
apropiadas en el orden equivocado; 2) olvidar incluir comandos para
hacer que uno o más métodos de transformación requeridos de
instancias en un gráfico a invocar en respuesta a que se cambiaron
algunos datos; 3) incluir comandos para causar métodos de
transformación innecesarios de instancias a invocar en respuesta a
que se cambiaron algunos datos (por ejemplo, incluyendo comandos
para invocar métodos de transformación de instancias que no son
parte de un gráfico afectado por el cambio en los datos; incluyendo
comandos para invocar métodos de transformación de instancias que
son parte de un gráfico afectado por el cambio en los datos, pero
que no están ellos mismos afectados; etc.).
Como se ha descrito anteriormente, el
almacenamiento temporal de las salidas del productor durante la
ejecución permite la sincronización. De este modo, en términos de
comparación para el patrón del observador, las declaraciones de
dependencias del productor notifican a la rutina de ejecución con
soporte de programación orientado a gráficos de productores de las
dependencias, y la rutina de ejecución determina qué productores y
cuándo llamarlos de vuelta.
En una realización de la invención, se incluye
un módulo de introducción/visión (no mostrado) como parte de la
rutina de ejecución. El módulo de introducción/visión proporciona
una interfaz gráfica de usuario que, a través del la interacción
por el usuario final, permite introducirse hacia abajo dentro del
gráfico de productores (avanzando hacia abajo en un gráfico de
productores desde el nodo raíz) para ver las salidas de los diversos
productores del gráfico de productores. Esto permite a un usuario
final ver las diversas salidas que contribuyen a la salida del
productor de interés, incluyendo los valores de datos y las
dependencias (devueltas por los productores de determinación de
dependencias). Además, en una realización de la invención, este
módulo de introducción/visión proporciona la capacidad para el
usuario final de ver el código dentro de los métodos de los
productores, los valores de las instancias de los productores, y/o
el contenido de las clases de los productores.
De este modo el módulo de introducción/visión
proporciona una diversidad de actividades de procesamiento
posterior, incluyendo la depuración, la explicación de las salidas,
etc.
Hay una diversidad de aplicaciones prácticas de
ejemplo de los diferentes aspectos y realizaciones de la invención.
Por ejemplo, la rutina de ejecución, como parte de la ejecución de
los programas de aplicación, causa la recuperación de información
desde un medio de almacenamiento de una máquina (por ejemplo,
accediendo al código fuente orientado a objetos, incluyendo las
declaraciones de dependencias del productor), el almacenamiento de
información para un medio de almacenamiento de una máquina (por
ejemplo, almacenando las estructuras de datos como la estructura de
gráficos de productores, etc.), el funcionamiento de los recursos de
procesamiento hardware, la provisión de las salidas de los
productores de interés (por ejemplo, a través de la interfaz gráfica
de usuario, el almacenamiento en los medios de almacenamiento de
una máquina, transmisión, etc.), etc. En un sentido, la actividad
de pre-procesamiento incluye la escritura de tal
programa e aplicación y/o la provisión de datos (los cuales pueden
representar cualquier número de elementos físicos y/o prácticos,
tales como valores financieros, valores geográficos, valores
meteorológicos, valores actuariales, valores estadísticos,
mediciones físicas, valores de estados de una máquina, etc.),
mientras que la actividad de post-procesamiento
incluye la provisión de resultados (los cuales pueden representar
cualquier número de elementos físicos o prácticos, tales como
análisis financieros, análisis geográficos, análisis meteorológicos,
análisis actuariales, análisis estadísticos, medidas industriales,
información de control de una máquina, etc. A modo de ejemplo
específico, la actividad de post procesamiento puede proporcionarse
por 1) el módulo de visión del gráfico de productores 1062 de la
Figura 10 para representar gráficamente en pantalla una
representación de los gráficos de productores actuales generados
por la rutina de ejecución; y/o 2) el módulo de interfaz gráfica de
usuario de la distribución de salidas del productor configurable
interactiva 840 (véase también, el módulo configurable interactivo
de la interfaz gráfica de usuario de distribución salidas del
productor 1085 de la Figura 10) para representar gráficamente en
pantalla las salidas de los gráficos de productores e interactuar
con ellos.
Como otro ejemplo, el programa de aplicación con
declaraciones de dependencias del productor por si mismo, cuando se
ejecuta por la rutina de ejecución, representa los elementos
físicos/prácticos y causa las operaciones descritas anteriormente.
A modo de ejemplo específico, estas declaraciones de dependencias
del productor causan que se formen estructuras de datos en un medio
de almacenamiento de una máquina en respuesta a su ejecución por la
rutina de ejecución. También, las declaraciones de dependencias del
productor se almacenan y se recuperan desde el medio de
almacenamiento de la máquina junto con el programa de aplicación.
Además, estas declaraciones de dependencias del productor
representan asociaciones entre productores, mientras que los
productores representan las operaciones a realizar (métodos) e
instancias. Las instancias en la programación orientada a objetos
pueden usarse para representar elementos
físicos y/o prácticos, mientras que los productores representan las operaciones a realizar sobre estas representaciones.
físicos y/o prácticos, mientras que los productores representan las operaciones a realizar sobre estas representaciones.
A modo de otro ejemplo, un conjunto de uno o más
programas de aplicación y la rutina de ejecución implementan un
software de gestión de riesgos de activos cruzados que cubre las
transacciones internacionales, paridad, tasas de interés, crédito,
inflación, materias primas y productos compuestos de activos
cruzados. Estos productos varían desde el efectivo y productos
físicos simples a productos derivados complejos y exóticos. También
está incluido un conjunto de modelos de evaluación matemáticos para
estos productos, y sus datos de mercado asociados, pagos y rutinas
de generación de entradas de contabilidad y sus modelos de
calibración asociados observables y sus entradas sin tratar
asociadas.
A modo de otro ejemplo, un conjunto de uno o más
programas de aplicación y la rutina de ejecución pueden implementar
un procesador de textos, una hoja de cálculo, un software de
comunicaciones/correo electrónico, un software de visión de fotos,
un software de búsqueda de virus, un reproductor de medios, un
servidor de una base de datos, un juego, una aplicación industrial,
una aplicación de herramienta de diseño asistido por ordenador, y/o
un sistema operativo. Por supuesto, los programas de aplicación
pueden implementarse para realizar una diversidad de tareas
diferentes.
A modo de ilustración, se describirán
realizaciones de ejemplo de la invención que soportan dependencias,
dependencias dinámicas (incluyendo dependencias contingentes y
dependencias de suscripción), productores de determinación de
dependencia explicita para dependencias declaradas de atajo y para
dependencias declaradas no de atajo, productores de determinación
de dependencia sobre la marcha para dependencias declaradas de
atajo, claves de clases, claves de instancias, claves de métodos,
comandos de anulación/restauración de productores (que son tipos de
comandos de fijación), y comandos de ejecución global. Además, las
realizaciones de ejemplo opcionalmente soportan un módulo visor
interactivo de gráficos de productores y ejecución incremental. Por
supuesto, las realizaciones alternativas de la invención pueden
implementar más, menos y/o diferentes características.
La Figura 10 es un diagrama de bloques de una
implementación de ejemplo de acuerdo con una realización de la
invención. En la Figura 10, la línea de división discontinua 1000
separa una rutina de ejecución del cliente 1002 de una rutina de
ejecución con soporte de programación orientado a gráficos de
productores 1004.
El flujo lógico de ejecución de la rutina de
ejecución del cliente 1002 incluye los bloques 1010, 1020, 1025,
1030, y 1035 y la rutina de ejecución con el soporte de programación
orientado a gráficos de productores 1004 incluye respectivamente
los bloques correspondientes 1095, 1098, 1040, 1045; y 1070;
mientras que una línea continua con flecha representa una
asociación directa causal desde el bloque 1035 del flujo lógico de
ejecución de la rutina de ejecución del cliente 1002 al bloque 1070
de la rutina de ejecución con soporte orientado a gráficos de
productores 1004, las líneas de puntos con flechas ilustran un
asociación causal desde los bloques 1010, 1020, 1025, y 1030 de la
rutina de ejecución del cliente 1002 a los bloques 1095, 1098, 1040
y 1045 de la rutina de ejecución con soporte de programación
orientado a gráficos de productores 1004. Dependiendo de la
realización de la invención, estas últimas asociaciones causales
pueden ser directas o indirectas. Por ejemplo, similar a la Figura
6, puede usarse una provocación indirecta opcional mediante el uso
de un registro de comandos (no mostrado) y/o el registro de
anulaciones 1047. Los bloques adicionales 1095 y 1098 son
discontinuos porque pueden ser opcionalmente parte de un bloque
diferente dependiendo de la realización de la invención (por
ejemplo, el bloque 1095 puede ser parte del bloque 1098; el bloque
1098 puede ser parte del bloque 1040; los bloques 1095 y 1098
pueden ser parte del bloque 1040). De forma similar, el bloque 1045
es discontinuo porque opcionalmente puede ser parte de un bloque
diferente dependiendo de la realización de la invención (por
ejemplo, el bloque 1045 puede ser parte del bloque 1070).
En la Figura 10, la rutina de ejecución 1002
incluye definiciones de clases que incluyen la lógica del negocio
1010 que tiene datos 1012, métodos 1014, declaraciones de
dependencias del productor 1016, y opcionalmente claves de clases
1090. Las definiciones de clases 1010 son clases en un lenguaje de
programación orientado a objetos, y de este modo, incluyen
definiciones para datos 1012 y métodos 1014. Además, estas
definiciones de clases 1010 incluyen declaraciones de dependencias
del productor 1016 para el método 1014 como se ha descrito
anteriormente. Además, en una realización de la invención, cada
clase tiene una clave de clase 1090 para propósitos de
seguimiento.
El nuevo módulo de clases 1095 y la rutina de
ejecución 1004 cargan y realizan la introspección de las
definiciones de clases 1010 (por ejemplo, en respuesta a los nuevos
comandos de clases). Esta carga e introspección pueden hacerse
usando cualquiera de las varias técnicas bien conocidas o que se
desarrollen en el futuro, incluyendo aquellas para la carga
selectiva de clases para propósitos de optimización. La carga de las
clases por el nuevo módulo de clases 1095 se ilustra por las clases
1054 de la rutina de ejecución 1004. Como parte de la carga y la
introspección de las clases 1054, el nuevo módulo de clases 1095
también carga y realiza la introspección de las declaraciones de
dependencias del productor 1016 como se ilustra por los métodos y
las declaraciones de dependencias del productor 1056 en las clases
1054. El nuevo módulo de clases 1095 también mantiene una
estructura de seguimiento de clases 1092 que se usa para el
seguimiento de clases usando las claves de clases. De este modo, la
estructura de seguimiento de clases 1092 mantiene una
correspondencia entre claves de clases y referencias dentro de las
clases 1054. Además, el nuevo módulo de clases 1095 también mantiene
una estructura de seguimiento de métodos 1058 que se usa para el
seguimiento de módulos usando las claves de métodos. De este modo,
la estructura de seguimiento de métodos 1058 mantiene una
correspondencia entre las claves de métodos y las referencias a los
métodos, así como la información relativa a las declaraciones de
dependencias del productor.
La rutina de ejecución del cliente 1002 también
incluye comandos de representación de instancias con las claves de
instancias 1020. El nuevo módulo de instancias 1098 de la rutina de
ejecución 1004 representa las instancias diseñadas por los comandos
de representación de instancias con las claves de instancias 1020
(por ejemplo en respuesta a los nuevos comandos de instancias).
Esta representación de instancias puede hacerse usando cualquiera
de varias técnicas conocidas o desarrolladas en el futuro,
incluyendo aquellas para representar selectivamente instancias para
propósitos de optimización. Como parte de esta representación de
instancias, el nuevo módulo de instancias 1098 accede a la
estructura de seguimiento de de clases 1092 usando una clave de
clases para acceder a la clase apropiada de las clases 1054. La
representación de instancias por el nuevo módulo de instancias 1098
se ilustra por las instancias 1052 de la rutina de ejecución 1004,
El nuevo módulo de instancias 1095 también mantiene una estructura
de seguimiento de instancias 1065 que se usa para el seguimiento de
instancias que usan las claves de instancias. De este modo la
estructura de seguimiento de instancias 1065 mantiene una
correspondencia entre las claves de instancias y las referencias
dentro de las instancias 1052. Como se ha indicado anteriormente,
el nuevo módulo de clases 1095 puede ser parte del nuevo módulo de
instancias 1098 en que las clases 1054 pueden representarse en
respuesta a los comandos de representación de instancias 1020, en
oposición a los nuevos comandos separados de clases.
La rutina de ejecución del cliente 1002 también
incluye comandos de representación de productores con claves de
productores 1025. El módulo de generación automatizada de gráficos
de productores 1040 de la rutina de ejecución 1004 representa a los
productores designados por los comandos de representación de
productores con las claves de productores 1025 (por ejemplo, en
respuesta a los nuevos comandos de productores que designan el
conjunto actual de productores de interés). Además, el módulo de
generación automatizada de gráficos de productores 1040 también
descubre, construye y opcionalmente resuelve los gráficos de
productores en respuesta al conjunto actual de productores de
interés como se ha descrito anteriormente. En una realización de la
invención, una clave de productor está comprendida de una clave de
clase, una clave de instancia, y una clave de método. Como parte de
esta representación de productores, el módulo de generación
automatizada de gráficos de productores 1040: 1) accede a la
estructura de seguimiento de clases 1092 usando la clave de clases
para acceder a la clase apropiada de las clases 1054; 2) accede a
la estructura de seguimiento de instancias 1065 usando la clave de
instancias para acceder a la instancia apropiada de las instancias
1052; y 3) accede a la estructura de seguimiento de métodos usando
la clave de métodos para acceder al establecimiento de declaraciones
de dependencias del productor apropiado. La representación de los
productores designados por los comandos de representación de
productores con las claves del productor 1025 y la representación de
cualesquiera productores descubiertos y la construcción del gráfico
de productores se ilustra por la estructura de gráficos de
productores 1060 de la rutina de ejecución 1004. De este modo, en
una realización de la invención, las claves de productores
identificadas por los comandos de representación del productor con
las claves del productor 1025 y las descubiertas a través de la
generación del gráfico de productores se almacenan en la estructura
de gráficos de productores 1060, junto con la información adicional
para representar los gráficos de productores actuales.
Como se ha descrito anteriormente, los bloques
1095 y 1098 pueden ser parte del bloque 1040, y de este modo la
decisión con respecto a qué clases, instancias, y productores
cargar/representar se controla por los productores que están en los
gráficos de productores actuales. En tal realización de la
invención, la carga/representación de clases, instancias, y
productores se optimiza y es un productor central.
La rutina de ejecución del cliente 1002 también
incluye comandos de preparación de datos, incluyendo los comandos
de anulación/restauración de salidas del productor 1030. Los
comandos de anulación/restauración incluyen la clave del productor
para anular/restaurar, así como los valores de anulación cuando se
anulan. El módulo de anulación de la salida del productor 1045 de
la rutina de ejecución 1004 causa que los productores designados por
los comandos de anulación/restauración se anulen/restauren. Esta
provocación puede ser indirecta o directa.
En el caso de una provocación indirecta, el
módulo de anulación de la salida del productor 1045 rellena el
registro de anulaciones 1047 para consumo por el módulo de ejecución
de gráficos de productores 1070. En el caso de una provocación
directa, el módulo de anulación de la salida del productor 1045
accede al almacenamiento temporal de la salida del productor 1097
de la estructura de gráficos de productores 1060 y las instancias
1052. Específicamente, como se ha descrito con referencia al módulo
de anulación de la salida del productor 390, en una realización,
los productores pueden clasificarse como productores de propiedad o
productores de métodos; de este modo, el módulo de anulación de la
salida del productor1045 puede incluir un módulo de anulación de la
salida del productor de propiedad (no mostrado) para anular los
productores de propiedad y un módulo de anulación de la salida de
productores de métodos (no mostrado) para anular los productores de
métodos; la anulación de un método de propiedad causa que el valor
anulado se almacene en el almacenamiento temporal de la salida 1097
de la estructura de gráficos de productores 1060, y se almacene en
los datos de la instancia apropiada de las instancias 1052,
mientras que la anulación de un productor de métodos causa que el
valor anulado se almacene en el almacén temporal de la salida del
productor 1097.
En una realización de la invención los
productores puede que no se anulen antes de que el gráfico de
productores del que formarán parte se haya ejecutado inicialmente
(de este modo, el productor ya se representará como el resultado de
lo que se designa como un productor de interés o como el resultado
de lo que se descubre por el módulo de generación automatizada de
gráficos de productores 1040). Sin embargo, en la realización
mostrada en la Figura 10, los productores pueden anularse antes de
la ejecución inicial representándose y anulándose con un comando de
anulación del productor. Tal productor anulado típicamente se
convertirá eventualmente en parte de un gráfico de productores a
través del proceso de descubrimiento (por ejemplo cuando se resuelve
una dependencia dinámica). En algunas realizaciones de la
invención, esta preparación de datos puede incluir también otros
tipos de comandos de fijación. El módulo de anulación de las salidas
del productor 1045 se muestra como una caja discontinua porque puede
que no esté presente en realizaciones alternativas de la
invención.
La estructura de gráficos de productores 1060
incluye también opcionalmente el marcado de ejecución incremental
1080 para algunas realizaciones de la invención que soportan
ejecución incremental. Como se ha descrito anteriormente con
referencia al marcado de ejecución incremental 382 de la Figura 3B,
las marcaciones de ejecución incremental 1080 se usan para asistir
con la ejecución incremental de los gráficos de productores sobre la
ejecución más allá de la ejecución inicial. Diferentes
realizaciones de la invención que usan el marcado de la ejecución
incremental 382, lo usan de formas diferentes. Por ejemplo, en una
de tales realizaciones de la invención que tiene un registro de
comandos, el registro se usa para seguir qué productores se han
añadido y/o modificado, y se usa el marcado de ejecución
incremental 382 para marcar los productores que están afectados
(ancestros de los productores modificados o añadidos, y de este
modo dependientes de los mismos). Como otro ejemplo, en una de
tales realizaciones de la invención que no tienen un registro de
comandos, se usa la marcación de ejecución incremental 382 para
marcar a los productores que se añaden o se modifican, así como a
los que son ancestros de los productores modificados o añadidos (y
de este modo, dependientes de los mismos). Como otro ejemplo, en
una de tales realizaciones de la invención que no tiene un registro
de comandos, se hacen inmediatamente modificaciones y adiciones de
productores y se usa el marcado de ejecución incremental 382 para
marcar los productores que son ancestros de los productores
modificados o añadidos (y de este modo, dependientes de los
mismos). Aunque se han descrito realizaciones de la invención que
soportan la ejecución incremental y usan el marcado de ejecución
incremental, otras realizaciones de la invención soportan la
ejecución incremental que no usan el marcado de ejecución
incremental (por ejemplo, se usa un registro de comandos para seguir
qué productores se añaden o se modifican, y se mantiene una lista
de productores de comienzo de ejecución en el registro de comienzo
de ejecución; donde el módulo de ejecución de gráficos de
productores 1070 comienza desde los productores de comienzo de la
ejecución y sigue su camino hacia los ancestros de los gráficos de
productores en la parte superior; a modo de ejemplo y no de
limitación, esta realización de la invención se describe más
adelante en este documento con respecto a las Figuras
15-25.
\newpage
La rutina de ejecución del cliente 1002 incluye
comandos de ejecución global 1035. El módulo de ejecución de
gráficos de productores 1070 de la rutina de ejecución 1004 ejecuta
los gráficos de productores. Como tal el módulo de ejecución de
gráficos de productores 1070 modifica el almacenamiento temporal de
la salida del productor 1097 (en el caso de productores de
propiedad y productores de métodos), usa el marcado de ejecución
incremental 1080 (si está presente), y modifica los datos de las
instancias 1052 (en el caso de métodos de propiedad). Anteriormente
se han descrito diversas técnicas para ejecutar los productores del
gráfico de productores y son aplicables en este punto. Por ejemplo,
en realizaciones en las que se implementa un registro de comandos,
el registro de comandos se consume y a continuación se ejecutan los
gráficos de productores. Además en realizaciones de la invención
que soportan la posibilidad de dependencias no resueltas, el módulo
de ejecución de gráficos de productores 1070 incluye el módulo de
dependencias dinámicas 1075, que puede invocar al módulo de
generación automatizada de gráficos de productores 1040.
La Figura 10 muestra un módulo opcional del
visor de gráficos de productores 1062 que proporciona un mecanismo
(por ejemplo una interfaz gráfica de usuario) por el cual el
usuario/programador puede ver los gráficos de productores y las
salidas del productor de la estructura de gráficos de productores.
Además, la Figura 10 muestra un módulo opcional de la interfaz
gráfica del usuario de distribución de salidas del productor
configurable interactivo 1085 para proporcionar una interfaz
gráfica de usuario (incluyendo la invocación dinámica de bloques
1030, y 1035) que representa el módulo de interfaz gráfica de
usuario de la distribución de salidas del productor configurable
interactiva 840.
En realizaciones de la invención que usan un
registro de comandos, pueden usarse diferentes disparos para
disparar diferentes acciones. Por ejemplo, los comandos de
representación del productor pueden registrarse y procesarse por
lotes en respuesta a un comando explícito (registro de comienzo y
registro de final), un comando de ejecución global explícito (
registrando automáticamente los comienzos en la inicialización y
después de cada uno de los comandos de ejecución global explícito,
y se procesa cada uno de los registros en respuesta al siguiente
comando de ejecución global explícito), un comando de preparación de
datos explícito, etc. De forma similar, los comandos de preparación
de datos pueden registrarse y procesarse por lotes en respuesta a
un comando explícito de ejecución global, un primer comando de
obtención, cada uno de los comandos de obtención, etc.
Las Figuras 11A-D son diagramas
de bloques que ilustran el contenido de ejemplo de las estructuras
de datos de la Figura 10, de acuerdo con una realización de la
invención. Aunque las Figuras 11A-D ilustran estas
estructuras de datos como tablas, debería entenderse que puede
usarse cualquier estructura de datos adecuada (por ejemplo, un mapa
hash, un conjunto, una lista).
La Figura 11A es un diagrama de bloques de un
ejemplo de la estructura de seguimiento de clases 1092 de la Figura
10 de acuerdo con una realización de la invención. En la Figura 11A
se muestran, la columna de claves de clases 1110 y la columna de
referencia de clases 1115 para almacenar respectivamente las claves
de clases y las referencias correspondientes a las clases
cargadas.
La Figura 11B e un diagrama de bloques de un
ejemplo de estructura de seguimiento de instancias 1065 de la
Figura 10 de acuerdo con una realización de la invención. En la
Figura 11B, la columna de claves de instancias 1120 y la columna de
referencia de instancias 1125 se muestran para almacenar
respectivamente las claves de instancias y las referencias
correspondientes a las instancias. En realizaciones de la invención
en las cuales las claves de instancias no necesitan ser única a
través de todas las clases, la estructura de seguimiento de
instancias también incluye la clave de clases o referencia, para la
clase de instancia.
La Figura 11C es un diagrama de bloques de un
ejemplo de la estructura de gráficos de productores 1060 de la
Figura 10 de acuerdo con una realización de la invención. En la
Figura 11C, la columna de referencia de clases 1135, la columna de
referencia de instancias 1140, y la columna de referencia de métodos
1145 se muestran para almacenar respectivamente referencias que
preparan los productores actuales de los gráficos de productores
actuales. Estas referencias pueden tomar una diversidad de formas.
Por ejemplo, estas columnas pueden almacenar respectivamente
referencias dentro de las clases 1054 (o alternativamente 1092), las
instancias 1052 (o como alternativa 1065), y los métodos 1056 (o
como alternativa 1058). Aunque en una realización de la invención
estas columnas almacenan referencias, en una realización alternativa
de la invención una o más columnas almacenan claves.
Además, la Figura 11C incluye una columna de
enlaces de productores padres 1150 (incluyendo para cada enlace una
referencia al productor padre, y una referencia al productor de
determinación de dependencias) y una columna de enlaces de
productores hijos 1160 (incluyendo para cada uno de los enlaces,
referencias al productor hijo, una referencia al productor de
determinación de dependencias, un modo de enlace, y un indicador de
enlace adherente). Cada productor puede tener cero o más enlaces
del productor hijo en la columna 1160. Cada uno de los enlaces del
productor hijo en la columna 1160 incluye: 1) referencias del
productor hijo que son referencias a otras filas de la estructura
de gráficos de productores para representar una dependencia del
productor de acuerdo con la declaración de dependencias del
productor; 2) una referencia al productor de determinación de
dependencias que es una referencia a otra fila de la estructura de
gráficos de productores y representa el productor de determinación
de dependencias que ha creado el enlace del hijo; y 3) un modo de
enlace con un tipo de dependencias del productor que identifica si
la dependencia del productor es un resultado de un argumento, un
campo, o una dependencia de secuenciación (véase la discusión
respecto a las Figuras 7A-F), y si es un argumento,
la ID del argumento de la dependencia del productor; y 4) un
indicador de adherencia para indicar que el modo de enlace es el
resultado de una dependencia declarada hacia arriba (en
realizaciones de la invención que soportan dependencias declaradas
hacia arriba) o el resultado de una suscripción adherente (en
realizaciones de la invención que soportan suscripciones adherentes)
y no debería modificarse a través de declaraciones de dependencias
de argumentos de productor de este productor (es decir, el productor
almacenado en la fila de la columna que contiene el indicador de
adherencia). Cada uno de los productores puede tener cero o más
enlaces de productores padres en la columna 1150. Cada uno de los
enlaces del productor padre en la columna 1150 incluye: 1) una
referencia al productor padre que almacena de vuelta una referencia
de acuerdo con una referencia del productor hijo de otro productor
(es decir, una referencia a otra fila de la estructura de gráficos
de productores para representar un productor padre dependiente de
este productor); y 2) una referencia del productor de determinación
de dependencia que es una referencia a otra fila de la estructura
del gráfico de productores y representa el productor de
determinación de dependencia que ha creado el enlace del padre, De
este modo, cuando se crea un enlace, la columna del enlace del
productor padre de la fila del productor hijo y la columna del
enlace del productor hijo de la fila del productor padre están
modificadas para representar el enlace (y la referencia del
productor de determinación de dependencia es la misma en ambos). En
una realización de la invención, como múltiples caminos en el
gráfico de productores o diferentes gráficos de productores pueden
incluir un productor determinado, hay múltiples enlaces de
productores padre para un productor determinado.
Además, la Figura 11C incluye un almacenamiento
temporal de la salida del productor y una columna de modificación
de la salida del productor anulada 1170 para almacenar las salidas
actuales del productor, así como una indicación de si el productor
está anulado y el valor de la salida anulada. También, la Figura 11C
incluye una columna de marcado de ejecución incremental 1180 para
almacenar el marcado de ejecución incremental como se ha descrito
anteriormente.
La Figura 11D es un diagrama de bloques de un
ejemplo de una estructura de seguimiento de métodos 1058 de la
Figura 10 de acuerdo con una realización de la invención. En la
Figura 11D se muestran, una columna de claves de método 1190 y una
columna de referencias de métodos 1192 para almacenar
respectivamente las claves de métodos y las referencias
correspondientes a los métodos de las clases cargadas. Además, la
Figura 11D también incluye una columna de DependenciasArgumento
1194, una columna de DependenciasCampo 1196, y una columna de
DependenciasSecuenciación 1195, una columna de
DependenciasHaciaArriba 1193, una columna de
DependenciasDébilmenteRestringidas 1199, una columna de clases de
salida 1197, y una columna de anotaciones adicionales opcional 1198.
La columna de DependenciasArgumento 1194, la columna de
DependenciasSecuenciación 1195, la columna DependenciasHaciaArriba
1193, la columna de DependenciasDébilmenteRestringidas 1199, la
columna DependenciasCampo 1196 almacenan información de
dependencias del productor analizada desde el establecimiento de
declaraciones de dependencias del productor del método (por
ejemplo, véase 705 de la Figura 7A), mientras que la columna de
clases de salida 1197 almacena información relativa a la clase de
salida de la salida del método (determinable por la firma del método
- por ejemplo véase 710 de la Figura 7A). Los contenidos de ejemplo
de la columna DependenciasArgumento 1194, la columna
DependenciasCampo 1196, la columna de DependenciasSecuenciación
1195, la columna DependenciasHaciaArriba 1193, y la columna de
DependenciasDébilmenteRestringidas 1199, usadas en algunas
realizaciones de la invención se proporcionan más adelante en este
documento.
Como se ha descrito anteriormente, una
realización de la invención soporta dependencias del productor no
dinámicas y dinámicas. Aunque diferentes realizaciones pueden
soportar tipos diferentes de dependencias dinámicas del productor,
una realización de la invención soporta tipos contingentes y de
suscripción de las dependencias dinámicas del productor. De esta
forma una dependencia no contingente, no de suscripción es una
dependencia no dinámica (estática).
La Figura 12 es un diagrama de bloques que
ilustra detalles adicionales de la Figura 10 para soportar
dependencias del productor del tipo dinámicas, contingentes y de
suscripción de acuerdo con una realización de la invención. La
Figura 12 incluye de la Figura 10 la línea de división discontinua
1000, las definiciones de clases que incluyen lógica del negocio
1010 (que incluyen los datos 1012, los métodos 1014, y declaraciones
de dependencias del productor 1016), el nuevo módulo de clases
1095, las clases 1054 (incluyendo métodos y declaraciones de
dependencias del productor 1056), el nuevo módulo de instancias
1098, las instancias 1052, la estructura de seguimiento de
instancias 1065, el módulo de generación automatizada de gráficos de
productores 1040, la estructura de gráficos de productores 1060, y
el módulo de ejecución de gráficos de productores 1070 (incluyendo
el módulo de dependencias dinámicas 1075).
La Figura 12 muestra que las declaraciones de
dependencia del productor 1016 opcionalmente incluyen dependencias
contingentes 1210, dependencias de suscripción 1220, y múltiples
productores 1215. En este punto, múltiples productores 1215 se
refiere a la capacidad de una dependencia del productor para
devolver una colección de productores. Además, la Figura 12 incluye
un módulo de suscripción 1240 y un módulo de contingencia 1230 en
el módulo de generación automatizada de gráficos de productores 1040
para procesar las dependencias contingentes 1210 y las dependencias
de suscripción 1220. La Figura 12 también muestra que el módulo de
suscripción 1240 accede a un registro de suscripción 1250. Además,
el módulo de dependencias dinámicas 1075 incluye un módulo de
contingencia 1260 y un módulo de suscripción 1265 para procesar las
dependencias contingentes 1210 y las dependencias de suscripción
1220. El módulo de suscripción 1265 accede al registro de
suscripción 1250.
La siguiente descripción de dependencias
contingentes y de suscripción se hace en el contexto de una
realización de la invención que usa una clase DEP (una abreviación
de dependencia), desde la cual se devuelve una instancia por los
productores de determinación de dependencia y se analiza por la
rutina de ejecución con el soporte de programación orientado a
gráficos de productores. La clase DEP incluye los siguientes campos:
1) TIPO que pude fijarse a suscripción, no suscripción declarada
hacia abajo (productores hijos que no son suscripciones), o
declaradas hacia arriba de no suscripción (productores padres que
son no de suscripción); 2) PROD que se usa para las dependencias
declaradas hacia abajo no de suscripción y es una colección de
productores hijo (como tal, puede almacenar cero o más
productores); 3) SUP TIPO que se usa para dependencias de
suscripción y se fija para indicar el tipo de dependencia de
suscripción (usada en realizaciones de la invención que soportan
múltiples tipos de suscripción; mientras que la realización de la
invención descrita en este punto soporta dos tipos - adherente y
absorbente, realizaciones alternativas pueden soportar más o menos
y/o diferentes tipos de suscripción; 4) SUB CRIT que se usa para
dependencias de suscripción y se fija para indicar los criterios de
suscripción; 5) MODO ENLACE PAR que se usa para dependencias de
suscripción adherentes y dependencias declaradas hacia arriba de no
suscripción y se fija para indicar qué modo de enlace debería ser el
productor padre; 6) CLASE PAR que se usa para dependencias de
suscripción adherentes y dependencias declaradas hacia arriba de
suscripción y se fija para indicar qué clase de productor padre
debería ser (por ejemplo, la clave de clase); 7) MÉTODO PAR que se
usa para dependencias de suscripción adherentes y dependencias
declaradas hacia arriba de no suscripción y se fija para indicar
qué método de productor padre debería ser (por ejemplo, la clave de
método); y 8) INSTANCIA PAR que se usa para dependencias de
suscripción adherente y dependencias de no suscripción declaradas
hacia arriba y se fija para indicar qué instancia del productor
padre debería ser (por ejemplo, la clave de instancia) (si
INSTANCIA PAR se deja en blanco, la clave de instancia del productor
hijo se usa entonces para el productor padre). Una realización
alternativa de la invención podría usar una colección de
productores padre (manteniendo cada uno de los elementos de la
colección una CLASE_PAR, INSTANCIA_PAR, MÉTODO_PAR, MODOENLACE_PAR)
en el caso de dependencias de suscripción adherentes y/o
dependencias declaradas hacia arriba de no suscripción. Por
supuesto, otras realizaciones alternativas de la invención podrían
usar una estructura diferente para devolver dependencias.
En una realización de la invención, se soportan
tanto las dependencias del productor contingentes como no
contingentes. Una dependencia del productor no contingente es
aquella que es independiente de la salida de otros productores,
mientras que una dependencia del productor contingente es la que es
dependiente de la salida de otros productores. Aunque una
realización de la invención soporta dependencias del productor tanto
no contingentes como contingentes, realizaciones alternativas
soportan sólo dependencias no contingentes o contingentes (las
dependencias del productor contingentes pueden controlarse
inicialmente por los valores por defecto).
Como se ha tratado anteriormente, un productor
puede verse como un conjunto de múltiples identificadores, un
identificador por cada uno de los niveles de granularidad
especificados. En una realización de la invención, una dependencia
del productor contingente puede ser contingente en el sentido de que
una cualquiera o todos del conjunto de identificadores pueden
determinarse condicionalmente en base a los valores de los datos
actuales. Por ejemplo, una primera dependencia del productor
contingente puede tener sólo el identificador de instancia a
determinar condicionalmente (los identificadores de clase y método
son fijos), mientras que una segunda dependencia del productor
contingente puede tener los identificadores de clase, instancia, y
método determinados condicionalmente. Aunque en una realización de
la invención todos los identificadores de la pluralidad de
identificadores de una dependencia de productor contingente pueden
ser condicionales, realizaciones alternativas de la invención
pueden implementarse de diferente forma (por ejemplo, permitir que
sólo un subconjunto de la pluralidad de identificadores sea
condicional).
Las Figuras 13A-J son diagramas
de bloques que ilustran seudo código y productores de ejemplo de
acuerdo con una realización de la invención. Además, las
realizaciones mostradas en la Figura 13A-J usan el
mismo mecanismo de determinación de dependencia para ambas
dependencias contingente y no contingente. Como tal, para propósitos
de explicación, algunos de los ejemplos en las Figuras
13A-J son ejemplos de dependencias del productor no
contingentes, mientras que las otras son ejemplos de dependencias
del productor contingentes. Además, una dependencia del productor
no contingente es aquella en la cual la dependencia es para un
productor de determinación de dependencia que es un productor
independiente (por ejemplo, en una realización de la invención, el
tipo de dependencia es identificable porque su declaración de
dependencias del productor está vacía); mientras que una
dependencia de productor contingente es aquella en la cual la
dependencia es para un productor de determinación de dependencias
que es un productor dependiente (por ejemplo, en una realización de
la invención, el tipo de dependencia es identificable porque su
declaración de dependencias del productor está no vacía).
Además, en las Figuras 13A-J se
usan números y letras en un círculo para ilustrar el orden en el
cual se realizan las operaciones de acuerdo con una realización de
la invención. También, se usa una notación X::Y::Z en las Figuras
13A-J para representar una clave de productor
construida de una clave de clase (X), una clave de instancia (Y), y
una clave de método (Z). Además los círculos y las líneas con
flechas discontinuas representan operaciones que no se realizan en
algunas realizaciones de la invención. En particular, donde la
ejecución de un productor de determinación de dependencias
independiente para una dependencia determinada siempre devolverá la
misma dependencia (por ejemplo, un productor de determinación de
dependencia independiente), tal productor de determinación de
dependencia en algunas realizaciones de la invención se ejecuta pero
no se representa y se enlaza en los gráficos de productores.
La Figura 13A ilustra un seudo código de
declaraciones de dependencias del productor para métodos que usan
una dependencia declarada de no atajo, no dinámica (no contingente,
no de suscripción) de acuerdo con una realización de la invención;
mientras que la Figura 13B es un diagrama de bloques de productores
que ilustra un ejemplo de una dependencia del productor declarada
no de atajo, no dinámica (no contingente, no de suscripción) de
acuerdo con un realización de la invención. La Figura 13A muestra:
1) un establecimiento de declaraciones de dependencias del
productor 1300 para un método alfa 1305, donde el establecimiento de
declaraciones de dependencias del productor 1300 incluye una
dependencia de un productor para el productor CW::IY::BETA; y 2) un
establecimiento de declaraciones de dependencias del productor 1310
para un método beta 1315, donde el establecimiento de declaraciones
de dependencias del productor 1310 está vacío y donde el método beta
1315 devuelve como argumento una instancia de la clase DEP. El
método beta 1315 incluye un código de declaración de dependencias
del productor 1320 que fija TIPO.DEP a declarada hacia abajo no de
suscripción, fija PROD.DEP al productor 13 y devuelve DEP.
En la Figura 13A, el número 1 en un círculo
indica que se accede la declaración de dependencias del productor
1300 (por ejemplo, como resultado de la designación de un productor
en base al método alfa 1305 como un productor de interés, como
resultado de un descubrimiento automatizado de un productor en base
al método alfa 1305, como un progenitor de un productor de interés,
etc.). El número 2 en un círculo en la Figura 13B muestra que el
productor C0::I0::ALFA está representado en base al método alfa
1305. El número 3 en un círculo en la Figura 13A indica que se
procesa la dependencia del productor para el productor CW::IY::BETA
para determinar la dependencia del productor, y como resultado, el
número 4 en un círculo indica que se accede a la declaración de
dependencias del productor 1310. Un número 5 en un círculo
discontinuo en la Figura 13B muestra que el productor CW::IY::BETA
está representado como un productor de determinación de dependencias
1380. Un número 6 en un círculo discontinuo en la Figura 13B indica
que el productor C0::I0::ALFA está enlazado en el gráfico de
productores para indicar que el productor CW::IY::BETA es un
productor hijo. El número 7 en un círculo en la figura 13B indica
que el productor CW::IY::BETA se ejecuta y devuelve una DEP para
identificar al productor 13. El número 8 en un círculo indica que
está representado el productor 13, mientras que un número 9 en un
círculo indica que el productor 13 está enlazado como productor
hijo en el gráfico de productores al productor C0::I0::ALFA. En la
Figura 13B, el productor C0::I0::ALFA y el productor 13 son
productores normalizados 1385 (no son productores de determinación
de dependencias).
La Figura 13C ilustra un seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia del productor declarada no de atajo, contingente, no
de suscripción de acuerdo con una realización de la invención;
mientras que la Figura 13D es un diagrama de bloques de productores
que ilustra un ejemplo de dependencia del productor declarada no de
atajo, contingente, no de suscripción de acuerdo con una
realización de la invención. Además, la Figura 13D se refiere a los
productores 5, 7A y 7B de la Figura 5A y la resolución de la
dependencia dinámica del productor 5 para el productor 7A.
La Figura 13C muestra: 1) un establecimiento de
declaraciones de dependencias del productor 1300 para un método
alfa 1305, donde el establecimiento de declaraciones de dependencias
del productor 1300 incluye una dependencia de productor para el
productor CW::IY::BETA; 2) un establecimiento de declaraciones de
dependencias del productor 1325 para un método beta 1315, donde el
establecimiento de declaraciones de dependencias del productor 1325
incluye una dependencia del productor para el productor
CU::IV::DELTA, y donde el método beta 1315 devuelve como argumento
una instancia a la clase DEP; 3) un establecimiento de declaraciones
de dependencias del productor 1332 para un método delta 1334, donde
el establecimiento de declaraciones de dependencias del productor
1332 está vacío, y donde el método delta 1334 devuelve como
argumento una instancia de la clase DEP; y 4) un establecimiento de
declaraciones de dependencias del productor 1338 para un método
gamma 1340 donde el establecimiento de declaraciones de
dependencias del productor 1338 está vacío, y donde el método gamma
1340 devuelve una variable X (donde X es desde una fuente externa,
un valor por defecto (explícito o constante en la clase). El método
beta 1315 incluye un código de declaración de dependencias del
productor 1330 que fija TIPO.DEP a declarada hacia abajo, no de
suscripción, fija PROD.DEP al productor 7A ó 7B dependiendo de la
salida del productor CX::IZ::GAMMA, y devuelve DEP. El método delta
1332 incluye el código de declaración de dependencias del productor
1336 que fija TIPO.DEP a declarada hacia abajo, no de suscripción,
fija PROD.DEP al productor CX::IZ::GAMMA, y devuelve PROD.DEP.
En la Figura 13C, el número 1 en un círculo
indica que la declaración de dependencias del productor 1300 se
accede (por ejemplo como resultado de la designación de un productor
en base al método alfa 1305 como productor de interés, como
resultado de un descubrimiento automatizado de un productor en base
al método alfa 1305 como un progenitor de un productor de interés,
etc.). El número 2 en un círculo en la Figura 13D muestra que el
productor 5 se representa en base al método alfa 1305. El número 3
en un círculo en la Figura 13C indica que la dependencia del
productor para el productor CW::IY::BETA se procesa para determinar
la dependencia del productor, y como resultado el número 4 en un
círculo indica que se ha accedido a la declaración de dependencias
del productor 1325. El número 5 en un círculo 5 en la Figura 13D
muestra que el productor CW::IY::BETA está representado como un
productor de determinación de dependencia 1380. El número 6 en un
círculo en la Figura 13D indica que el productor 5 está enlazado en
el gráfico de productores para indicar que el productor CW::IY::BETA
es un productor hijo.
Un número 7 en un círculo en la Figura 13C
indica que la dependencia del productor para el productor
CU::IV::DELTA se procesa para determinar la dependencia del productor, y como resultado, el número 8 en un círculo indica que la declaración de dependencias del productor 1332 está accedida. Un número 9 en un circulo discontinuo en la Figura 13D muestra que el productor CU::IV::DELTA se representa como un productor de determinación de dependencias 1380. El número 10 en un círculo discontinuo en la Figura 13D indica que el productor CW::IY::BETA está enlazado en el gráfico de productores para indicar que el productor CU::IV::DELTA es un productor hijo. Un número 11 en un círculo en la Figura 13D indica que se ejecuta el productor CU::IV::DELTA y devuelve una DEP para identificar CX::IZ::GAMMA. Un número 12 en un círculo indica que el productor CX::IZ::GAMMA está representado, mientras que un número 13 en un círculo indica que el productor CX::IZ::GAMMA que está enlazado como un productor hijo en el gráfico de productores al productor CW::IY::BETA.
CU::IV::DELTA se procesa para determinar la dependencia del productor, y como resultado, el número 8 en un círculo indica que la declaración de dependencias del productor 1332 está accedida. Un número 9 en un circulo discontinuo en la Figura 13D muestra que el productor CU::IV::DELTA se representa como un productor de determinación de dependencias 1380. El número 10 en un círculo discontinuo en la Figura 13D indica que el productor CW::IY::BETA está enlazado en el gráfico de productores para indicar que el productor CU::IV::DELTA es un productor hijo. Un número 11 en un círculo en la Figura 13D indica que se ejecuta el productor CU::IV::DELTA y devuelve una DEP para identificar CX::IZ::GAMMA. Un número 12 en un círculo indica que el productor CX::IZ::GAMMA está representado, mientras que un número 13 en un círculo indica que el productor CX::IZ::GAMMA que está enlazado como un productor hijo en el gráfico de productores al productor CW::IY::BETA.
En la Figura 13D, una letra A en un círculo
indica que el productor CX::IZ::GAMMA se ejecuta y devuelve X al
productor CW::IY::BETA, mientras que una letra B en un círculo
indica que el productor CW::IY::BETA, devuelve una DEP para
identificar al productor 7A; una letra C en un círculo indica que el
resto sin resolver (método beta) 1390 está resuelto ahora y el
productor 7A está representado, mientras que una letra D en un
círculo indica el enlace del productor 5 con el productor 7A. En la
Figura 13D, los productores CX::IZ::GAMMA, 5 y 7A son productores
normalizados 1385.
La Figura 13E ilustra un seudo código de las
declaraciones de dependencia del productor para métodos que usan
tanto dependencias del productor declaradas de no de atajo,
contingentes, de no suscripción como dependencias del productor
declaradas de atajo, contingente, de no suscripción de acuerdo con
una realización de la invención; mientras que la Figura 13F es un
diagrama de bloques de los productores que ilustran una dependencia
del productor declarada de no de atajo, contingente, de no
suscripción y una dependencia del productor declaradas de atajo,
contingente, de no suscripción de acuerdo con una realización de la
invención. De forma similar a las Figuras 13D, la Figura 13F se
refiere a los productores 5, 7A, y 7B de la Figura 5A y la
resolución de la dependencia dinámica del productor 5 al productor
7A.
Las Figura 13E-F son las mismas
que las Figuras 13C-D, con las excepciones: 1) el
establecimiento de declaraciones de dependencias del productor 1342
reemplaza al establecimiento de declaraciones de dependencias del
productor 1325; 2) un método fly 1344 reemplaza al método delta
1334; y 3) el productor CW::IY::FLY reemplaza al productor
CU::IC::DELTA. El establecimiento de declaraciones de dependencias
del productor 1342 incluye una dependencia del productor declarada
de atajo para el CX::IZ::GAMMA. De este modo, el número 4 en un
círculo en la Figura 13E ahora indica que la declaración de
dependencias del productor 1342 está accedida. El número 7 en un
círculo en la Figura 13E indica ahora que la dependencia del
productor declarada de atajo para productor CX::IZ::GAMMA se
procesa para determinar la dependencia del productor, y como
resultado, la rutina de ejecución invoca al productor de
determinación de dependencias CW::IY::FLY sobre la marcha en base al
método fly 1344. El número 8 en un círculo indica ahora que la
declaración de dependencias del productor 1332 está accedida. El
número 9 en un círculo en la Figura 13F muestra ahora que el
productor CW::IY::FLY está representado. El número 10 en un círculo
discontinuo en la Figura 13F indica que el productor CW::IY::BETA
está enlazado en el gráfico de productores para indicar que el
productor CW::IY::FLY es un productor hijo. El número 11 en un
círculo en la Figura 13F indica que el productor CW::IY::VUELO se
ejecuta y devuelve una DEP para identificar CX::IZ::GAMMA. El resto
de las Figuras 13E-F es el mismo que en las figuras
13C-D.
La generación sobre la marcha por la rutina de
ejecución del productor de determinación de dependencias
CW::IY::FLY alivia al programador de aplicación de tener que escribir el código explícito de la declaración de dependencias del productor y representar un productor de determinación de dependencias en base al mismo. Además, permite al programador de aplicación especificar directamente la dependencia sobre el productor CX::IZ::GAMMA en el establecimiento de declaraciones de dependencias del productor para el método beta 1315, en oposición a especificar el productor de determinación de dependencias CU::IV::DELTA.
CW::IY::FLY alivia al programador de aplicación de tener que escribir el código explícito de la declaración de dependencias del productor y representar un productor de determinación de dependencias en base al mismo. Además, permite al programador de aplicación especificar directamente la dependencia sobre el productor CX::IZ::GAMMA en el establecimiento de declaraciones de dependencias del productor para el método beta 1315, en oposición a especificar el productor de determinación de dependencias CU::IV::DELTA.
La técnica de atajo puede usarse en una
diversidad de situaciones, y puede tener adicionalmente una
diversidad de formados. Por ejemplo, aunque en las Figuras
13E-F la dependencia declarada de atajo es para una
dependencia no contingente (identifica directamente el productor
hijo) y es un establecimiento de declaraciones de dependencias del
productor para un método sobre el cual se basa del productor de
determinación de dependencias, se muestran otras situaciones y
formatos como sigue: 1) las Figuras 13G-H ilustran
el uso de dos atajos, donde uno es contingente y el otro no es
contingente y es parte de un establecimiento de declaraciones de
dependencias del productor para un método sobre el cual está basado
un productor normalizado y el otro es no contingente y es parte de
un establecimiento de declaraciones de dependencias del productor
para un método sobre el cual está basado un productor de
determinación de dependencias; y 2) las Figuras I-J
ilustran el uso de un atajo que no es contingente y que es un
establecimiento de declaraciones de dependencias del productor para
un método sobre el cual está basado un productor normalizado.
La Figura 13G ilustran el seudo código de las
declaraciones de dependencias del productor para métodos que usan
una dependencia del productor declarada de atajo, contingente, no de
suscripción y una dependencia del productor declarada de atajo, no
contingente, no de suscripción de acuerdo con una realización de la
invención; mientras que la Figura 13H es un diagrama de bloques de
productores que ilustran un ejemplo de dependencia del productor
declarada de atajo, contingente, no de suscripción y una dependencia
del productor declarada de atajo, no contingente, no de suscripción
de acuerdo con una realización de la invención. La Figura 13G
muestra: 1) un establecimiento de declaraciones de dependencias del
productor 1345 para el método alfa 1305, donde el establecimiento
de declaraciones de dependencias del productor 1345 incluye una
dependencia del productor declarada de atajo, contingente, para el
productor <P>GETC1::I1::M1; 2) un establecimiento de
declaraciones de dependencias del productor 1350 para un método
fly1 1355, donde el establecimiento de declaraciones de
dependencias del productor 1350 incluye una dependencia del
productor declarada de atajo, no contingente, para el productor
C0::I0::GETC1, y donde el método fly1 1355 devuelve como argumento
una instancia de DEP: 3) el establecimiento de declaraciones de
dependencias del productor 1332 para un método fly2 1362, donde el
método fly2 1362 devuelve como argumento como una instancia de DEP;
y 4) el establecimiento de declaraciones de dependencias del
productor 1365 para un método getc1, donde el método getc1 1370
devuelve C1 con el valor de CX o de CY.
El método FLY1 1355 y su establecimiento de
declaraciones de dependencias del productor 1350 se proporcionan
por la rutina de ejecución en respuesta a la dependencia declarada
de atajo <P>GETC1::I1::M1 (que indica que se ha usado el
atajo para la clave de clase). El método fly1 1355 incluye un código
de declaración de dependencias del productor 1360 que fija TIPO.DEP
a declarada hacia abajo de no suscripción, fija PROD.DEP al
productor CX::I1::M1 ó CY::I1::M1 dependiendo del valor de la salida
C1 por el productor C0::I0::GET1, y devuelve DEP. Aunque que en el
ejemplo de la Figura 13H, se usa <P> para designar que es la
clave de clase del productor que es contingente, realizaciones
alternativas de la invención podrían usar otras sintaxis. Además,
aunque en el ejemplo de la Figura 13H, se usa <P> para
designar que es la clave de clase del productor que es contingente,
una realización de la invención soporta tener más identificadores
y/o diferentes de los identificadores que construyen la clave del
productor a indicar como contingente de este modo.
En la Figura 13G, un número 1 en un círculo
indica que la declaración de dependencias del productor 1345 está
accedida (por ejemplo, como resultado de la designación de un
productor en base al método alfa 1305 como un productor de interés,
como resultado del descubrimiento automatizado de un productor en
base al método alfa 1305, como progenitor de un productor de
interés, etc.). Un número 2 en un círculo en la Figura 13H muestra
que el productor C0::I0::ALFA se representa en base al método alfa
1305. Un número 3 en un círculo en la Figura 13G indica que la
dependencia del productor declarada de atajo se procesa para
determinar las dependencias del productor y la rutina de ejecución
proporciona el método fly1 1355; y como resultado, un número 4 en un
círculo indica que la declaración de dependencias del productor 1350
está accedida.
Un número 5 en un círculo en la Figura 13H
muestra que un productor C0::I0::FY1 está representado como un
productor de determinación de dependencia 1380. Un número 6 en un
círculo en la figura 13H indica que el productor C0::I0::ALFA está
enlazado en el gráfico de productores para indicar que el productor
C0::I0::FLY1 es un productor hijo. Un número 7 en un círculo en la
Figura 13G indica que la dependencia del productor declarada de
atajo para el productor C0::I0::GETC1 se procesa para determinar
las dependencias del productor y la rutina de ejecución proporciona
el método fly2 1362, y como resultado, un número 8 en un círculo
indica que la declaración de dependencias del productor 1332 está
accedida. Un número 9 en un círculo discontinuo en la Figura 13H
muestra que el productor C0::I0::FLY2 está representado. Un número
10 en un círculo discontinuo en la Figura 13H indica que el
productor C0::I0::FLY1 está enlazado en el gráfico de productores
para indicar que el productor C0::I0::FLY2 es un productor hijo.
Un número 11 en un círculo en la Figura 13H
indica que el productor C0::I0::FLY2 se ejecuta y devuelve una DEP
para identificar al productor C0::I0::GETC1. Un número 12 en un
círculo indica que el productor C0::I0::GETC1 está representado,
mientras que un número 13 en un círculo indica que el productor
C0::I0::GETC1 está enlazado en el gráfico de productores al
productor C0::I0::FLY1 es un productor hijo.
En la Figura 13H, una letra A en un círculo
indica que el productor C0::I0::GETC1 se ejecuta y devuelve C1=CX
al productor C0::I0::FLY1, mientras que una letra B en un círculo
indica que el productor C0::I0::FLY1 se ejecuta y devuelve una DEP
para identificar al productor CX::I1::M1; una letra C en un círculo
indica que el resto sin resolver (método fly1) 1390 está ahora
resuelto, y una letra D en un círculo indica el enlazamiento del
productor C0::I0::ALFA con el productor CX::I1::M1. En la Figura
13H, los productores C0::I0::GETC1, C0::I0::ALFA, y CX::I1::M1 son
productores normalizados 1385.
La generación sobre la marcha por la rutina de
ejecución del productor de determinación de dependencias
C0::I0::FLY1 y C0::I0::FLY2 alivia al programador de la aplicación de tener que escribir el código explicito de la declaración de dependencias del productor y representar a los productores de determinación de dependencias en base a los mimos. Además, permite a los programadores de aplicación especificar directamente la dependencia contingente sobre el productor **::I1::M1 a través del método getC1 en el establecimiento de declaraciones de dependencias del productor para el método alfa 1305, en oposición a especificar el productor de determinación de dependencias CW::IY::BETA.
C0::I0::FLY1 y C0::I0::FLY2 alivia al programador de la aplicación de tener que escribir el código explicito de la declaración de dependencias del productor y representar a los productores de determinación de dependencias en base a los mimos. Además, permite a los programadores de aplicación especificar directamente la dependencia contingente sobre el productor **::I1::M1 a través del método getC1 en el establecimiento de declaraciones de dependencias del productor para el método alfa 1305, en oposición a especificar el productor de determinación de dependencias CW::IY::BETA.
La Figura 13I ilustra un seudo código de las
declaraciones de dependencia del productor para los métodos que
usan una dependencia del productor declarada de atajo, no dinámica
(no contingente, no de suscripción) de acuerdo con una realización
de la invención; mientras que la Figura 13J es un diagrama de
bloques de productores que ilustran un ejemplo de dependencia del
productor declarada de atajo, no dinámica de acuerdo con una
realización de la invención. La Figura 13I muestra: 1) un
establecimiento de declaraciones de dependencias del productor 1372
para un método alfa 1305, donde el establecimiento de declaraciones
de dependencias del productor 1372 incluye una dependencia del
productor declarada de atajo para el productor 10; y 2) un
establecimiento de declaraciones de dependencias del productor 1374
para un método fly 1376, donde el establecimiento de declaraciones
de dependencias del productor 1374 está vacío, y donde el método fly
1376 devuelve como argumento una instancia de DEP. El método fly
1776 y su establecimiento de declaraciones de dependencias del
productor 1374 se proporcionan por la rutina de ejecución en
respuesta a la dependencia declarada de atajo. El método fly 1376
incluye un código de declaración de dependencias del productor 1378
que fija TIPO.DEP a declarada hacia abajo no de suscripción, fija
PROD.DEP al productor 10 y devuelve DEP.
En la Figura 13I un número 1 en un círculo
indica que la declaración de dependencias del productor 1372 está
accedida (por ejemplo, como resultado de la designación de un
productor en base al método alfa 1305 como productor de interés,
como resultado de un descubrimiento automatizado de un productor en
base al método alfa 1305 como un progenitor de un productor de
interés, etc.) Un número 2 en un círculo en la Figura 13J muestra
que el productor C0::I0::ALFA está representado en base al método
alfa 1305. Un número 3 en un círculo en la Figura 13I indica que se
procesa la dependencia del productor declarada de atajo para
determinar las dependencias del productor y la rutina de ejecución
proporciona el método fly 1376; y como resultado, un número 4 en un
círculo indica que la declaración de dependencias del productor 1374
está accedida. Un número 5 en un círculo discontinuo en la Figura
13J indica que el productor C0::I0::FLY está representado como el
productor de determinación de dependencias 1380. Un número 6 en un
círculo discontinuo en la Figura 13J indica que el productor
C0::I0::ALFA está enlazado en el gráfico de productores para indicar
que el productor C0::I0::FLY es un productor hijo.
Un número 7 en un círculo en la Figura 13J
indica que se ejecuta el productor C0::I0::FLY y devuelve una DEP
para identificar el productor 10. Un número 8 en un círculo indica
que el productor 10 está representado, mientras que un número 9 en
un círculo indica el productor C0::I0::ALFA que está enlazado en el
gráfico de productores para indicar que el productor 10 es un
productor hijo. En la Figura 13J, el productor C0::I0::ALFA y el
productor 10 son productores normalizados 1385.
Debería entenderse que el programador de la
rutina de ejecución, en una realización de la invención, escribe un
simple método fly para interpretar todas las sintaxis y
combinaciones soportadas (por ejemplo, el método fly 1334, el
método fly1 1355, el método fly2 1362, el método fly 1376) y los
incluye en la rutina de ejecución. Esto no sólo permite a los
programadores de aplicaciones evitar escribir el código para los
productores de determinación de dependencia donde puede usarse un
método fly, el programador de la rutina de ejecución sólo necesita
escribir el método genérico fly una vez (el único fly para todas las
situaciones soportadas). Además debería entenderse que las
dependencias declaradas de atajo permiten que una rutina de
ejecución use los productores de determinación de dependencias
mientras que al mismo tiempo permiten a un programador de aplicación
indicar los productores normalizados en las declaración de
dependencias del productor (por ejemplo, las Figuras
13G-J).
Refiriéndonos de nuevo a la estructura de
seguimiento de métodos de la Figura 11D, se describirán ahora los
contenidos de ejemplo de la columna DependenciasArgumento 1194, la
columna DependenciasCampo 1196, la columna de
DependenciasSecuenciación 1195, la columna de
DependenciasHaciaArriba 1193, la columna de
DependenciasDébilmenteRestringidas 1199 usadas en algunas
realizaciones de la invención. Específicamente, la columna
DependenciasArgumento 1194 almacena una colección de elementos, uno
para cada DependenciaArgumento. En una realización de la invención,
cada uno de los elementos incluye lo siguiente: 1) la ID del
argumento; 2) un identificador de la naturaleza de la clave de
clase, que es una de la clase explícita, la misma clase, y la clase
contingente; 3) un identificador explícito de la clave de clase
relleno cuando el identificador de la naturaleza de la clave de
clase que indica la clase explícita; 4) un identificador de la
clave del método de determinación de clase contingente relleno
cuando el identificador de la naturaleza de la clave de clase indica
una clase contingente; 5) un identificador de la naturaleza de la
clave de instancia, siendo uno de la instancia explícita, la misma
instancia, y la instancia contingente; 6) un identificador de la
clave de instancia explícita relleno cuando el identificador de la
naturaleza de la clave de instancia indica instancia explícita; 7)
un identificador de la clave del método de determinación de
instancia contingente relleno cuando el identificador de la
naturaleza de la clave de instancia indica instancia contingente;
8) un identificador de la naturaleza de la clave de método, siendo
uno de método explícito, el mismo método y el método contingente; 9)
un identificador de la clave del método explícito relleno cuando el
identificador de la naturaleza de la clave de método indica el
método explícito; 10) un identificador de la clave de método de
determinación del método contingente relleno cuando el identificador
de la naturaleza de la clave del método indica un método
contingente; y 11) un identificador de atajo que indica si la
declaración de dependencias del productor para el argumento en el
establecimiento de declaraciones de dependencias del productor
contenía una indicación de atajo (es decir, el establecimiento de
declaraciones de dependencias del productor identifica directamente
un productor hijo normalizado en lugar de un productor de
determinación de dependencias).
La indicación "...explicito" de los
diversos indicadores de la naturaleza de la clave se usa donde se
proporciona la clave explícita para las dependencias del productor
en el establecimiento de declaraciones de dependencias del
productor. A modo de ejemplo, la dependencia del productor
"CW::IY::BETA" del establecimiento de declaraciones de
dependencias del productor 1300 de la Figura 13A proporciona una
clase explícita, una instancia, y una clave de método.
En algunas realizaciones de la invención, se
soporta una técnica de taquigrafía para los establecimientos de
declaraciones de dependencias del productor de modo que: 1) si no se
proporciona una clase para una dependencia del productor
determinado, entonces se usa la misma clase que el productor padre;
y 2) si no se proporcionan una clase y una instancia para una
dependencia de un productor determinado, entonces se usan la misma
clase e instancia que el productor padre. En otras realizaciones de
la invención , se usa una sintaxis para permitir que cualquier
combinación de clases, instancias y métodos para sean las mismas que
los padres (con la excepción de que todas sean las mismas) (por
ejemplo, se usa un separador para designar cada una de las clases,
instancias, y métodos, y una ausencia de tal separador indica los
mismo que los padres - a modo de ejemplo específico, la sintaxis
puede ser "#C:", "#I:", y "#M:", de modo que una
dependencia del productor en un establecimiento de declaraciones de
dependencias del productor puede ser #C:"clave de
clase"::#I:"clave de instancia":: #M:"clave de
método") (donde las comillas indican un espacio para un valor de
la variable). La indicación "...igual" de los diversos
identificadores de la naturaleza de clave se usan donde se use esta
técnica de taquigráfica en el establecimiento de declaraciones de
dependencias del productor:
Como se ha indicado anteriormente, en algunas
realizaciones de la invención se soporta una dependencia del
productor contingente a través de la sintaxis (por ejemplo,
<P>) usada en el establecimiento de declaraciones de
dependencias del productor propiamente (véase 1345 de la Figura
13G), y tal sintaxis puede usarse sobre una o más de las clases,
instancias, y métodos de una dependencia del productor. La
indicación "...contingente" de los diversos identificadores de
la naturaleza de clave se usan para identificar cuándo se produce
tal dependencia del productor contingente, mientras que el
"identificador de clave del método de
determinación...contingente" indica la clave del método del
productor hijo (la clase y la instancia son las mismas que las del
productor padre). A modo de ejemplo, las dependencias del productor
"<P>GETC1::I1::M1" para la declaración de dependencias
del productor 1345 de la Figura 13G proporciona una clase
contingente (donde la clave del método de determinación de clase
contingente es GETC1), una clave de instancia explícita, y una clave
de método explícita.
La columna DependenciasSecuenciación 1195, la
columna DependenciasHaciaArriba 1193, y la columna
DependenciasDébilmenteRestringidas 1195 almacenan cada una, una
colección de elementos, uno por cada DependenciaSecuenciación,
DependenciaHaciaArriba, y DependenciaDébilmenteRestringida. En una
realización de la invención, cada uno de tales elementos tiene la
misma estructura que un elemento de la colección para las
DependenciasArgumento, excepto que no incluye una ID de argumento.
Además, aunque las figuras 13A-J ilustran
dependencias declaradas hacia abajo no de suscripción que se
originan desde los productores de determinación de dependencias,
deberá entenderse que en el caso de una dependencia declarada hacia
arriba o una dependencia débilmente restringida el productor de
determinación de dependencias puede devolver las otras dependencias
tratadas con referencia a las Figuras 7F-G.
La columna DependenciasCampo 1196 almacena una
colección de elementos, uno para cada DependenciasCampo. Aunque en
una realización de la invención cada uno de los elementos incluye
una clave de método de propiedad, en realizaciones alternativas de
la invención pueden tener la misma estructura que un elemento de la
colección de DependenciasSecuenciación.
En una realización de la invención, se soportan
ambas dependencias del productor de no suscripción y de suscripción.
Cuando se declara una dependencia del productor de suscripción para
un método determinado y se representa el productor determinado
desde ese método determinado, la rutina de ejecución puede resolver
durante el tiempo de ejecución (en base a la existencia de otros
productores) el conjunto de cero o más productores que cumplen los
criterios de la suscripción. Aunque una realización de la invención
soporta ambas dependencias del productor de no suscripción y de
suscripción, realizaciones alternativas sólo soportan de no
suscripción. Además, aunque en una realización de la invención se
soportan dos tipos de dependencias de suscripción (absorbentes y
adherentes), realizaciones alternativas de la invención pueden
soportar más, menos, y/o diferentes tipos de dependencias del
productor de suscripción.
Las Figuras 14A-C son diagramas
de bloques que ilustran las suscripciones absorbentes y adherentes
de acuerdo con una realización de la invención. La Figura 14A es un
diagrama de bloques de un ejemplo de registro de suscripción 1250
de la figura 12 de acuerdo con una realización de la invención.
Aunque la Figura 14A ilustra esta estructura de registro como una
tabla, debería entenderse que puede usarse cualquier estructura de
datos adecuada (por ejemplo, un mapa hash). La Figura 14B es un
diagrama de bloques de productores de ejemplo que ilustra una
dependencia del productor de suscripción absorbente, no contingente
de acuerdo con una realización de la invención. La Figura 14C es un
diagrama de bloques de productores de ejemplo que ilustra una
dependencia del productor de suscripción adherente no contingente
de acuerdo con una realización de la invención. Se muestran dos
filas en la tabla de la Figura 14A rellenas con el contenido usado
en los ejemplos de las Figuras 14B-C. Los números
en un círculo usados en las Figuras 14B-C para
ilustrar el orden en el cual se realizan las operaciones de acuerdo
con una realización de la invención.
En la Figura 14A, la columna de claves del
productor del suscriptor 1400, la columna del tipo de suscripción
1405, y el criterio de suscripción para disparar la columna de
productores de disparo 1410 se muestran para almacenar
respectivamente el contenido correspondiente al nombre de la
columna. Además, la Figura 14A muestra una columna del modo de
enlace del padre 1425 para almacenar el modo de enlace para el
productor padre de la dependencia de suscripción, esta información
se describirá con más detalle con respecto a las Figuras
14B-C.
La Figura 14A también muestra una columna de
productores de coincidencia 1415 y una columna completa 1420 usada
para suscripciones absorbentes. La columna de productores de
coincidencia 1415 se usa para almacenar las claves productores, de
los productores de disparo que cumplen los criterios de suscripción
de la suscripción absorbente, mientras que la columna completada
1420 se usa para seguir si la suscripción absorbente se ha
completado durante una ejecución determinada del conjunto actual de
los gráficos de productores. La columna de productores coincidentes
1415 y la columna completados 1420 proporcionan una optimización
opcional adicional que permite que el trabajo de escanear los
productores representados se divida entre la generación automatizada
de gráficos de productores y la ejecución de los gráficos de
productores como se describe más adelante en este documento.
La Figura 14A también muestra una columna de
clase de padres 1430, una columna de métodos de padres 1435, y una
columna de instancias de padres 1437 usadas para suscripciones
adherentes. La columna de clases de padres 1430, la columna de
métodos de padres 1435, y la columna de instancias de padres 1437
respectivamente almacenan las claves de clases, la clave de
métodos, y la clave de instancias de los productores padres a crear
para la suscripción adherente. Además, la Figura 14A muestra una
columna de referencias del productor de determinación de
dependencias 1421 que almacena una referencia al productor de
determinación de dependencias que crea la suscripción.
En una dependencia del productor de suscripción
absorbente, la dependencia es para la colección de todos los
productores de la estructura de gráficos de productores actuales que
cumplen el criterio de suscripción de absorción. Con referencia a
la Figura 14B, un número 1 en un círculo indica que un productor
1450 está representado (por ejemplo, como resultado de la
designación del productor 1450 como un productor de interés, como
resultado de un descubrimiento automatizado del productor 1450 como
un progenitor de un productor de interés, etc.). El productor 1450
está basado en un método para el cual la declaración de dependencias
del productor incluye una dependencia del productor (por ejemplo,
con una ID de argumento X). Un número 2 en un círculo indica que la
dependencia del productor, del productor 1450 se procesa para
identificar un productor 1455.
Un número 3 en un círculo indica que el
productor 1450 está enlazado (en el ejemplo anterior, a través de
la ID de argumento X) en el gráfico de productores para el productor
1455 como un productor hijo. Un número 4 en un círculo indica la
ejecución del productor 1455. El productor 1455 es un productor de
determinación de dependencia que incluye el código de declaración
de dependencias del productor que indica una dependencia del
productor de suscripción absorbente y que indica el criterio de
suscripción absorbente. Como tal la ejecución del productor 1455 da
como resultado el relleno del registro de suscripción. Con respecto
al ejemplo en la primera fila de la Figura 14A, la columna de
claves del productor del subscriptor 1400, la columna del tipo de
suscripción 1405, los criterios de suscripción para la columna de
productores de disparo 1410, la columna del modo de enlace del
padre 1425, y la columna de referencias del productor de
determinación de dependencias 1421 se rellenan respectivamente con
la clave del productor 1450, una indicación de que la suscripción es
del tipo absorbente, los criterios de suscripción absorbente
contendidos dentro del productor 1455, el modo de enlace del
productor 1450 enlazado con el productor 1455 (el cual, en el caso
de una suscripción absorbente será una dependencia de argumento e
incluirá una ID de argumento, pero cuyo indicador de adherencia
indicará no adherencia - en el ejemplo anterior, la ID de argumento
X), y una referencia para el productor 1455 (el productor de
determinación de dependencias que crea la suscripción).
5A-N en un círculo indica la
representación de productores 1460A-N. En este
ejemplo, los productores 1460A-N cumplen los
criterios de suscripción absorbente y de este modo son productores
de disparo. Como tal, 6A-N en un círculo indica el
enlace del productor 1450 con los productores
1460A-N (en el ejemplo anterior, a través de la ID
de argumento X). Un número 7 en un círculo indica que está
completada la dependencia de suscripción absorbente para la
ejecución actual de los gráficos de productores, y a continuación se
ejecuta el productor 1450.
En una realización de la invención, los
criterios de suscripción absorbente pueden ser una o más de las
claves que construyen una clave del productor. De este modo, en las
realizaciones de la invención donde una clave de productor
comprende una clave de clase, una clave de instancia, y una clave de
método, el criterio de suscripción podría ser una o más de tales
claves. A modo de ejemplo con referencia a la Figura 11C, un rastreo
a través de los productores representados en búsqueda de los que
cumplen el criterio de suscripción es un rastreo a través de una o
más de las tres primeras columnas de la estructura de gráficos de
productores para determinar si las claves de los productores
representados coinciden con las claves de los criterios de
suscripción absorbente. Aunque en una realización de la invención,
el criterio de suscripción absorbente puede ser uno o más de
cualesquiera claves que construyen una clave de productor, en
realizaciones alternativas de la invención el criterio de
suscripción de absorción está limitado a un subconjunto de claves
que construyen una clave de productor.
En una dependencia de productor de suscripción
adherente, la dependencia causa que el productor padre a representar
para cada productor cumpla el criterio de suscripción adherente.
Con referencia a la Figura 14C, un número 1 en un círculo indica un
productor 1470 que está representado (por ejemplo, como resultado de
la designación del productor 1470 como productor de interés, como
resultado de un descubrimiento automatizado del productor 1470 como
progenitor de un productor de interés a través de la dependencia de
secuenciación (por ejemplo, como resultado de una
DependenciaSecuenciación o DependenciaDébilmenteRestringida, etc.).
El productor 1470 es un productor de determinación de dependencia
que incluye un código de declaración de dependencias del productor
que indica una suscripción adherente, el criterio de suscripción
adherente para los productores de disparo, y las características de
suscripción adherente para los productores padre a crear.
La ejecución del productor 1470 da como
resultado el relleno del registro de suscripción. Con respecto al
ejemplo en la segunda fila de la Figura 14A, la columna de claves de
productor del suscriptor 1400, la columna del tipo de suscripción
1405, y el criterio de suscripción para la columna de productores de
disparo 1410 se rellenan respectivamente con la clave del
productor, del productor 1470, una indicación de que la suscripción
es del tipo adherente, y el criterio de suscripción adherente para
los productores de disparo contenidos dentro del productor 1470.
Además, la columna de clases de padres 1430, la columna de métodos
de padres 1435, la columna de instancias de padres 1437, y la
columna de modo de enlace 1425 del productor padre a enlazar con el
productor de disparo se rellenan con las características de
suscripción adherente para el productor padre a crear - en esta
realización de la invención, respectivamente la clase del productor
padre a representar, el método del productor padre a representar,
la instancia del productor padre a representar (si se deja en
blanco, sería igual a la clave de instancia del productor de
disparo), el modo de enlace (que en el caso de suscripción
adherente, puede ser: 1) un argumento, un campo, o una dependencia
de secuenciación; 2) una ID de argumento si es una dependencia de
argumento - la ID de argumento del productor padre a enlazar con el
productor de disparo (por ejemplo la ID de argumento Y). Además, la
columna de referencias del productor de determinación de
dependencias 1421 se rellena con una referencia al productor de
determinación de dependencias que creó la suscripción (en la Figura
14C, el productor 1470).
Con referencia a la Figura 14C, un número 2 en
un círculo indica que el productor 1475 está representado (por
ejemplo como resultado de la designación del productor 1475 como un
productor de interés, como resultado de un descubrimiento
automatizado del productor 1475 como un progenitor de de un
productor de interés, etc.). Además, se determina si el productor
1475 cumple el criterio de suscripción adherente para un productor
de disparo. Un número 3 en un círculo indica que en respuesta al
productor de disparo 1475, se representa el productor 1480 en base
a las características de suscripción adherente para el productor
padre a crear. Con referencia a la segunda fila de ejemplo de la
Figura 14C, la clave de clase, la clave de método, la clave de
instancia, y el modo de enlace se acceden desde la columna de clases
de padres 1430, la columna de métodos de padres 1435, la columna de
instancias 1427, y la columna de modos de enlaces de padres 1425,
respectivamente. El productor padre tiene una clave de productor
que comprende la clave de clase accedida, la clave de instancia
accedida (si se deja en blanco, la clave de instancia del productor
de disparo (en la Figura 14C, el productor 1475)), y la clave del
método accedido - en el ejemplo de la Figura 14C, este es el
productor 1480. Un número 4 en un círculo indica que el productor
padre representado 1480 está enlazado en el gráfico de productores
al productor de disparo hijo 1475 a través del modo de enlace
accedido (en el ejemplo anterior el tipo del modo de enlace =
dependencia de argumento; la ID del argumento del modo de enlace =
Y). También un número 4 en un círculo, en el caso de una
dependencia de argumento, el indicador de adherencia se fija para
indicar adherencia - que la dependencia del productor en esa
posición del establecimiento de declaraciones de dependencias del
productor para el método sobre el cual está basado el productor
padre representado 1480 debería ignorarse por el productor 1480 -
esto impide que el enlace creado por la dependencias del productor
de suscripción adherente se sobrescriba por las operaciones de
generación automatizada del gráfico de productores.
En una realización de la invención, el criterio
de suscripción adherente para productores de disparo puede ser una
o más de las claves de construcción de una clave de productor. De
este modo, en realizaciones cuando una clave de productor comprende
una clave de clase, un clave de instancia, y una clave de método, el
criterio de suscripción adherente para el disparo podrían ser una o
más de las claves de clase, instancia y método. A modo de ejemplo
con referencia a la Figura 11C, un rastreo a través de los
productores representados en búsqueda de los que cumplen el
criterio de suscripción adherente para los productores de disparo es
un rastreo a través de una o más de las
primera-tercera columnas de la estructura de
gráficos de productores para determinar si las claves de los
productores representados coinciden con las claves del criterio de
suscripción adherente para los productores de disparo. Aunque en
una realización de la invención el criterio de suscripción adherente
para productores de disparo puede ser una o más de las claves de
construcción de una clave de productor, en realizaciones
alternativas de la invención el criterio de suscripción absorbente
puede ser un número más limitado de las claves que construyen una
clave de productor.
Las Figuras 14D-E ilustran la
elección de un productor padre en base al productor de determinación
de dependencias de padres de acuerdo con una realización de la
invención. Aunque las Figuras 14D-E se describen con
referencia a dependencias de argumentos, realizaciones de la
invención pueden soportar el uso de las dependencias de
secuenciación y de campo.
La Figura 14D ilustra la elección de un
productor padre en base al productor padre de determinación de
dependencia creado por una suscripción adherente de acuerdo con una
realización de la invención. Al igual que la Figura 14C, la Figura
14D muestra el productor de suscripción adherente 1470 y el
productor de disparo 1475; sin embargo, en lugar del productor
1480, la Figura 14D muestra un productor de determinación de
dependencia 1480 creado a través de la suscripción adherente del
productor de suscripción adherente 1470. Además, la Figura 14D
muestra que el modo de enlace de la suscripción adherente es la
dependencia de argumento, ID de argumento = X, y el indicador de
adherencia = adherencia. Como se ilustra por la línea curva
discontinua desde productor 1475 al productor de determinación de
dependencia 1480, la DEP devuelta por el productor de determinación
de dependencias puede basarse en la salida del productor 1475
propiamente (el argumento de ID de argumento=X). En la Figura 14D,
el productor de determinación de dependencias 1480 devuelve una
dependencia del productor declarada hacia arriba de no suscripción
sobre un productor 1482, con el modo de enlace indicando dependencia
de argumento y la ID de argumento=Y. Mientras que las ID de
argumentos de X e Y se usan en la Figura 14D para mostrar que pueden
diferir, debería entenderse que podrían ser iguales.
La Figura 14E ilustra la elección de un
productor padre en base al productor padre de determinación de
dependencias creado por el productor de determinación de
dependencias hijo, cuyo productor de determinación de dependencia
hijo está enlazado por una dependencia de secuenciación, de acuerdo
con una realización de la invención. La Figura 14E es similar en
estructura a la Figura 14D; específicamente, los productores 1475,
1480 y 1482 se reemplazan con los productores 1486, 1496, y 1498.
Sin embargo, en lugar del productor de suscripción adherente 1470
que crea el enlace entre los productores 1480 y 1475, el productor
1486 tiene una dependencia de secuenciación sobre el productor de
determinación de dependencias 1494 (por ejemplo, creada a través de
una DependenciaHaciaArriba o una DependenciaDébilmenteRestringida),
la cual crea el productor de determinación de dependencias 1496 a
través de una dependencia declarada hacia arriba de no
suscripción.
Merece la pena observar que las dependencias de
suscripción adherente y las dependencias no de suscripción
declaradas hacia arriba (por ejemplo creadas a través de
DependenciasHaciaArriba y/o DependenciasDébilmenteRestringidas)
causan un construcción de abajo a arriba de un gráfico de
productores (en oposición a la construcción de arriba abajo
descrita anteriormente en este documento). Además, esta construcción
de abajo a arriba no está limitada a la construcción de un nivel
único, sino que puede ser de múltiples niveles) (por ejemplo, si,
debido a una suscripción adherente o una dependencia declarada
hacia arriba de no suscripción, se representa un productor padre,
el mismo productor padre puede también ser un productor de disparo
para una suscripción adherente o puede incluir una dependencia
declarada hacia arriba de no suscripción y causar la representación
de oto productor padre, y así sucesivamente). En este sentido, las
dependencias de suscripción adherente, así como las dependencias no
de suscripción declaradas hacia arriba, invierten la construcción
del gráfico de productores.
Aunque en algunas realizaciones de la invención,
los productores padre identificados por las características de la
suscripción adherente son productores normalizados (véase la Figura
14C), pueden implementarse realizaciones alternativas para soportar
la identificación de otros tipos de productores. Por ejemplo, en
realizaciones de la invención que permiten a las características de
suscripción adherente identificar un productor de determinación de
dependencias (véase la Figura 14D), tal productor de determinación
de dependencias puede acceder a la salida del productor de disparo
y puede, en base a esa salida, disparar la creación de un productor
particular como productor padre que necesita soportarse sobre el
hijo (este productor padre puede existir ya o no; si ya existe,
está simplemente enlazado, y el productor hijo se añade a su
argumento; si no existe aún, se crea). El caso donde el productor
de determinación de dependencias devuelve un productor constante
imita una suscripción absorbente. El caso donde el productor de
determinación de dependencia devuelve un productor cuya clave de
instancia es única por productor de disparo (por ejemplo, devuelve
un productor cuya clave de instancia es la clave del productor del
productor de disparo) da como resultado un productor padre separado
por productor hijo y se denomina como una suscripción adherente
pura. El caso donde el productor de determinación de dependencia
devuelve una clave de instancia que no es ni constante ni única por
productor de disparo, puede mezclar los comportamientos de las
suscripciones adherentes puras y las subscripciones absorbentes y se
denominan como una suscripción adherente no pura.
Como se ha descrito anteriormente, en una
realización de la invención, las dependencias del productor se
declaran para los métodos como un modo de especificar una
secuenciación de invocación de métodos que usa las instancias
apropiadas (donde las instancias apropiadas incluyen las instancias
a usar como argumentos, las instancias a usar por los métodos de
instancias, y las instancias de meta clases usadas por los métodos
de clases) sin el uso del código de secuenciación de invocación
manual; efectivamente, el trabajo de generar algo o todo el código
de secuenciación de invocación manual se reemplaza con: 1) el
trabajo hecho por el programador de aplicación para escribir las
declaraciones de dependencias del productor; y 2) el trabajo hecho
por la rutina de ejecución para descubrir y construir los gráficos
de productores y ejecutar los productores de esos gráficos de
productores. Aunque el esfuerzo para escribir la rutina de ejecución
es relativamente grande, sólo necesita escribirse una vez ya que
puede usarse para ejecutar cualesquiera aplicaciones orientadas a
objetos escritas para la rutina de ejecución; en contraste, para
una aplicación típica, el esfuerzo de escribir las declaraciones de
dependencias del productor es relativamente bajo en comparación con
escribir el código de secuenciación de invocación manual.
Las dependencias del productor no dinámicas
proporcionan un modo para especificar un código de secuenciación de
invocación de un método incondicional, y de este modo elimina la
necesidad de escribir código de secuenciación de invocación manual
incondicional. Las dependencias del productor contingente
proporcionan un modo para especificar el procesamiento condicional,
y de este modo reemplazan la necesidad de escribir el código de
secuenciación de invocación manual condicional. El soporte de las
dependencias del productor que permiten devolver una colección de
productores, proporciona un modo para especificar el relleno de una
colección antes de que se pase como un parámetro, y de este modo
evitar la necesidad de escribir múltiples llamadas en el código de
secuenciación de invocación manual para rellenar una colección
antes de que se pase como un parámetro. El soporte de suscripciones
proporciona un entorno en el cual un programador no necesita
escribir código de escucha específico para cada tipo de objeto a
escuchar (por ejemplo, en una hoja de cálculo de programación
orientada a gráficos de productores, puede usarse una suscripción
absorbente para calcular un promedio de un intervalo de células
(siendo cada una de las células un productor) teniendo las células
de identificación el criterio de suscripción absorbente dentro del
intervalo, y recalculando el promedio cada vez que se añade un nuevo
productor a la suscripción de absorción; en una hoja de cálculo de
programación orientada o gráficos de productores, puede usarse una
suscripción adherente como un convertidor de divisas teniendo el
criterio de suscripción adherente células de identificación que
mantienen el contenido de la divisa y características de suscripción
adherente de productores adherentes a representar que realizan la
conversión de divisas (los productores (que mantienen las cantidades
convertidas) creados por las suscripciones adherentes estarían
disponibles a continuación para su presentación en pantalla en otras
células).
La Figura 15 es un diagrama de flujo para
representar nuevas instancias de acuerdo con una realización de la
invención. Como se ha descrito anteriormente con referencia a la
Figura 10, el nuevo módulo de clases 1095 de la Figura 10 puede
implementarse como parte del nuevo módulo de instancias 1098. El
diagrama de flujo de la Figura 15 asume tal realización y se
realiza por el nuevo módulo de instancias 1098; la parte el diagrama
de flujo de la Figura 15 que representa el nuevo módulo de clase
1095 se muestra como el bloque discontinuo 1580, que incluye los
bloques 1540 y 1550.
En respuesta al nuevo comando de instancias
(bloque 1510), el control pasa al bloque 1520. En el bloque 1520,
se determina si la instancia ya existe. Si no existe, el control
pasa al bloque 1530, de lo contrario, la instancia no necesita
representarse y el control pasa al bloque 1570 en el cual termina el
diagrama de flujo. En una realización que soporta claves de
instancias, se realiza el bloque 1520 accediendo a la estructura de
seguimiento de instancias 1065 de la Figura 10 para la clave de
instancias (y la clave de clases si las claves de instancias no
necesitan ser únicas a través de las clases) proporcionada como
parte del nuevo comando de instancias.
En el bloque 1530, se determina si la definición
de clase de la instancia está ya cargada. Si no lo esta, el control
pasa al bloque 1540; de lo contrario el control pasa al bloque 1560.
En una realización que soporta claves de clases, el bloque 1540 se
realiza accediendo a la estructura de seguimiento de clases 1092 de
la Figura 10 para la clave de clase proporcionada como parte del
nuevo comando de instancias.
En el bloque 1540, se carga la clase y el
control pasa al bloque 1550. En el bloque 1550, la definición de
clase se almacenaría de acuerdo con la clave de clase e
introspección, incluyendo cualquier establecimiento de
declaraciones de dependencias del productor (almacenado por la clave
de método dentro de la clase - véase la Figura 11D). Desde el
bloque 1550, el control pasa al bloque 1560. Con referencia a la
Figura 10, se realiza lo siguiente en los bloques 1540 y 1550: 1)
la clase se cargaría desde las definiciones de clases que incluye
la lógica del negocio 1010 dentro de las clases 1054 (esta carga da
como resultado los métodos y las declaraciones de dependencias del
productor de la clase que se está almacenando en el método y las
declaraciones de dependencia del productor 1056); 2) la clase se
añadiría a la estructura de seguimiento de clases 1092; y 3) los
métodos se añadirían a la estructura de seguimiento de métodos
1058. Además, se cargarían las clases de salida de los métodos.
En el bloque 1560, una instancia de la clase se
representaría y se almacenaría de acuerdo con la clave de
instancias. Con referencia a la Figura 10, la instancia se
representaría dentro de las instancias 1052; y la instancia se
añadiría a la estructura de seguimiento de instancias 1065. Desde el
bloque 1550, el control pasa al bloque 1570 donde termina el
diagrama de flujo. En algunas realizaciones de la invención en las
que se usa la técnica de mapeo relacionado con objetos, los datos
pueden almacenarse desde una fuente de datos externa para rellenar
el campo de instancia como parte del bloque 1560.
En algunas realizaciones de la invención, las
clases e instancias pueden cargarse/representarse de un modo que la
rutina de ejecución con el soporte de programación orientado a
gráficos de productores no es consciente (por ejemplo, en la Figura
9A, si la rutina de ejecución 915 carga/representa sin que la rutina
de ejecución 910 sea consciente). En tales casos, las realizaciones
de la invención que también soportan que la clave de instancia sea
una instancia de la clase ClaveInstancia (que mantiene dos
elementos: una clave de instancia natural que indica si el
identificador de la clave es una referencia a la instancia u otro
objeto (tal como una cadena de caracteres) y un identificador de
clave que puede ser bien una referencia a la instancia, u otro
objeto (tal como una cadena de caracteres)), los bloques 1520 y 1530
se informan de si la instancia y la clase se representaron/cargaron
de modo que la rutina de ejecución con el soporte de programación
orientado a gráficos de productores sea consciente. En los casos
donde la rutina de ejecución con el soporte de programación
orientado a gráficos de productores no sea consciente de la clase
esté ya cargada, la clase no se cargaría, pero la clase se añadiría
a la estructura de seguimiento de clases 1092 y los métodos se
añadirían a la estructura de seguimiento de métodos 1058. En los
casos donde la rutina de ejecución con el soporte de programación
orientado a gráficos de productores no sea consciente de una
instancia ya representada, la instancia no se representaría, pero la
instancia se añadiría a la estructura de seguimiento de instancias
1065.
La Figura 16 es un diagrama de flujo para
representación de nuevos productores y restauración de productores
de acuerdo con una realización de la invención. Con referencia a la
Figura 10, los flujos de la Figura 15 se realizan por el módulo de
generación automatizada de gráficos de productores 1040 y el módulo
de anulación de productores 1045 (o, como se describe con
referencia a las realizaciones alternativas respecto a la Figura 10,
el módulo que maneja la anulaciones y restauraciones).
En respuesta al nuevo comando del productor
(bloque 1600), el control pasa al bloque 1605. En una realización
de la invención, se puede ejecutar un nuevo comando del productor en
respuesta a una diversidad de situaciones. La Tabla 2 a
continuación identifica las diversas situaciones y parámetros
pasados de acuerdo con una realización de la invención.
En el bloque 1605, se determina si el productor
ya existe. Si no existe el control pasa al bloque 1610; de lo
contrario el control pasa al bloque 1670. El bloque 1605 se realiza
accediendo a la clase, instancia, y método identificados (por
ejemplo, por clave y/o referencia) como parte del nuevo comando del
productor. En una realización que soporta las claves de productor,
el bloque 1605 se realiza accediendo a la estructura de los
gráficos de productores 1060 de la Figura 10 para la clave del
productor como parte del nuevo comando del productor (la clave de
productor en la columna de productor llamado de la Tabla 2).
En el bloque 1610, el nuevo módulo de instancias
se llama con un nuevo comando de instancias y el control pasa al
bloque 1615. En una realización de la invención, el bloque 1610 se
realiza llamando al diagrama de flujo de la Figura 15 usando la
clave de instancias desde la clave del productor en la columna del
productor llamado de la Tabla 2).
En el bloque 1615, la definición de clases de la
instancia del productor se accede y el control pasa al bloque 1620.
Con referencia a la Figura 10, el bloque 1615 se realiza usando la
clave de clases desde la clave de productor en la columna del
productor llamado de la Tabla 2 para acceder a la clase apropiada de
las clases 1054 de acuerdo con la estructura de seguimiento de
clases 1092.
En el bloque 1620, se acceden el método y el
establecimiento de declaraciones de dependencias del productor y el
control pasa al bloque 1625. Con referencia a la Figura 10, el
bloque 1620 se realiza usando la clave de método desde la clave del
productor en la columna del productor llamado de la Tabla 2 para
acceder al método apropiado de los métodos y declaraciones de
dependencias del productor 1056 desde la clase localizada en el
bloque 1615.
En el bloque 1625, se añade el productor al
gráfico de productores y el control pasa al bloque 1630. Con
referencia a la realización de la invención en la Figura 11C, las
tres primeras columnas se rellenan.
En el bloque 1630, para cada un de las
suscripciones registradas, el criterio de filtrado de suscripción se
procesa para determinar si el productor coincide. Con referencia a
la realización de la invención en la Figura 14A, una suscripción se
considera registrada cuando se añade al registro de suscripciones.
Más adelante en este documento, se describen operaciones de ejemplo
para registrar una suscripción. El bloque 1630 es una optimización
opcional que permite para el trabajo de rastreo de los productores
representados dividirlos entre la generación automatizada del
gráfico de productores y la ejecución del gráfico de productores.
Como tal, una realización alternativa de la invención podría no
realizar el bloque 1630.
En el bloque 1635, el productor está enlazado
dentro de los gráficos de productores si se llamó debido a una
dependencia. Desde el bloque 1635, el control pasa el bloque 1640.
El modo de realizar el bloque 1635 depende de la situación que
resultó en el nuevo comando del productor que se ejecutó (véase la
Figura 20). Por ejemplo, si la situación es que este es un
productor de interés o un productor que está anulado, entonces no se
llamó debido a la dependencia y no se hace nada. Por el contrario,
si la situación es de declarada hacia abajo no de suscripción,
entonces se llamó debido a una dependencia declarada hacia abajo no
de suscripción; y con referencia a la realización de la invención
en la Figura 11C, se realiza lo siguiente: 1) el enlace del
productor padre en la columna 1150 del productor hijo llamado (la
columna del productor llamado de la Tabla 2) se modifica con la
referencia del productor padre para la fila del productor padre
llamante (la columna del productor llamante de la Tabla 2) y la
referencia del productor de determinación de dependencia (la columna
de referencia del productor de determinación de dependencia de la
Tabla 2); y 2) la columna del enlace del productor hijo 1160 de la
línea del productor padre llamante (la columna del productor
llamante de la Tabla 2) se modifica con una referencia del
productor hijo para la fila del productor hijo llamado (la columna
del productor llamado de la Tabla 2), una referencia del productor
de determinación de dependencia (la columna de referencia del
productor de determinación de dependencia de la Tabla 2), y un modo
de enlace (fijado de acuerdo con la columna del modo de enlace de la
Tabla 2).
Por el contrario, si la situación es una
suscripción adherente, entonces se llamó debido a un productor de
disparo que se identificó; y con referencia a la realización de la
invención en la Figura 11C, se realiza lo siguiente: 1) la columna
de enlaces del productor padre 1150 del productor hijo llamante (la
columna del productor llamante de la Tabla 2) se modifica con la
referencia del productor padre para la fila del productor padre
llamado (la columna del productor llamado de la Tabla 2) y la
referencia del productor de determinación de dependencia (la
columna de referencias del productor de determinación de
dependencias de la Tabla 2); y 2) los enlaces de productores hijo
1160 de la fila del productor llamado padre (la columna del
productor llamado de la Tabla 2) se modifica con la referencia del
productor hijo para la fila del productor hijo llamante (la columna
del productor llamante de la Tabla 2), una referencia del productor
de determinación de dependencia (la columna de referencias del
productor de determinación de dependencia de la Tabla 2), un modo de
enlace (fijado de acuerdo con la columna del modo de enlace de la
Tabla 2) y un indicador de adherencia fijado para indicar
adherencia. En este respecto, la situación de declarado hacia arriba
de no suscripción se maneja de forma similar a la suscripción
adherente.
En el bloque 1640, el productor se marca como no
ejecutado y el control pasa el bloque 1645. Con referencia a la
realización de la invención en la Figura 11C, la columna de marcado
de ejecución incremental 1180 de la fila apropiada se rellena con
una indicación de no ejecutado.
En el bloque 1645, se determina si el productor
tiene cualesquiera dependencias y no está anulado. Si es así, el
control pasa al bloque 1650; de lo contrario el control pasa al
bloque 1665. El bloque 1645 se realiza comprobando la declaración
de dependencias del productor accedida en el bloque 1620 y la
columna del tipo de llamada de la Tabla 2.
En el bloque 1650, para cada una de las
dependencias en la declaración de dependencias del productor que se
va a resolver ahora, se determina el número de productores y se
invoca un nuevo comando de productores para cada uno. Desde el
bloque 1650, el control pasa al bloque 1655. Las deferentes
realizaciones de la invención determinan diferentes tipos de
dependencias en diferentes instantes; el modo de realizar el bloque
1650 en una realización de ejemplo de la invención se describirá más
adelante en este documento.
En el bloque 1655 se añade el productor al
registro de comienzo de ejecución si todos sus productores
dependientes existen y se han ejecutado. Desde el bloque 1655, el
control pasa a al bloque 1660. Cuando para un productor determinado
representado como parte de la iteración actual de este flujo, se
realiza el bloque 1655, a continuación la invocación de otra
iteración de este flujo para un productor del que depende el
productor determinado devolverá el estado de ejecución de ese
productor (véase el bloque 1660) (por ejemplo, con respecto a la
realización de la invención de la Figura 11C, el estado desde la
columna de marcado de ejecución incremental 1180 de la fila
apropiada). Se existen todos los productores dependientes y el
estado de ejecución de todos los productores dependientes es de
ejecutados, entonces se añade el productor de la iteración actual al
registro de comienzo de la ejecución.
En el bloque 1660, se devuelve el estado de
ejecución del productor como un parámetro.
En el bloque 1670, similar al bloque 1635, el
productor se enlaza dentro del gráfico de productores si se llamó
debido a una dependencia. Desde el bloque 1670, el control pasa al
bloque 1675. El bloque 1670 puede alcanzarse por una diversidad de
razones. Por ejemplo, el bloque 1670 puede alcanzarse porque el
productor se representó anteriormente en respuesta a un comando de
anulación de productor pero no se enlazó dentro del gráfico de
productores. Como otro ejemplo, el bloque 1670 puede alcanzarse
porque el productor es ya parte de un gráfico de productores y se
añade a otro (por ejemplo representado anteriormente en respuesta a
que es un productor de interés, un progenitor de un productor de
interés, etc.)
En el bloque 1675, se determina si el flujo del
nuevo productor se llamó debido a una anulación, a una dependencia
de suscripción adherente, o a una dependencia declarada hacia arriba
no de suscripción. Si es así, el control pasa al bloque 1680; de lo
contrario, el control pasa al bloque 1660. El bloque 1675 se realiza
comprobando la columna del tipo de llamada de la Tabla 2 para ver
si ésta es una llamada a un productor anulado, una dependencia de
suscripción adherente, o a una dependencia declarada hacia arriba de
no suscripción.
En el bloque 1680, al igual que el bloque 1640,
el productor se marca como no ejecutado y el control pasa al bloque
1665. El bloque 1680 puede alcanzarse por una diversidad de
razones.
En el bloque 1665, se añade el productor al
registro de comienzo de ejecución, si no está ya presente, y el
control pasa al bloque 1660.
En respuesta al comando de restauración de un
productor (bloque 1690), el control pasa al bloque 1695. En el
bloque 1695, el productor se marca como no anulado y el control pasa
al bloque 1640. Con referencia a la realización de la invención de
las figuras 11C, el almacenamiento temporal de la salida del
productor y la columna de indicaciones de anulación de la salida
del productor 1170 de la fila del productor se accede y se altera
para indicar que el productor ya no está anulado. Continuando este
flujo, el bloque 1640 conduciría al bloque 1645, y si el productor
tenía cualesquiera dependencias, al bloque 1650, el cual causaría
descubrir el gráfico de productores bajo el productor y construirlo
si no lo estaba ya. Si el gráfico de productores bajo el productor
ya estaba descubierto y construido, entonces la invocación del nuevo
comando del productor dará como resultado que el flujo va desde
1600 a 1605, a 1670 y así sucesivamente, además, la devolución del
estado de ejecución de los productores del gráfico bajo el productor
en el bloque 1660 determinará si se añade el productor al registro
de comienzo de ejecución en el bloque 1655. Sin embargo, si el
gráfico de productores bajo el productor no está descubierto y
construido, entonces la invocación del nuevo comando del productor
dará como resultado que se descubre y se construye con los flujos
yendo desde 1600 a 1605, a 1610, y así sucesivamente.
La Figura 17 es un diagrama de flujo para el
bloque 1650 de la Figura 16 de acuerdo con una realización de la
invención. De este modo, el control fluye desde el bloque 1645 al
bloque 1700 en el bloque 1650. En el bloque 1700, para cada una de
las dependencias en la declaración de dependencias del productor
(una para cada una de DependenciaArgumento, DependenciaCampo,
DependenciaSecuenciación, DependenciaHaciaArriba, y
DependenciaDébilmenteRestringida), se realizan los bloques
siguientes 1705-1745. Con referencia a las Figuras
10 y 11D, se accede a la estructura de seguimiento del método para
determinar la información respecto a la dependencia del productor.
También debería entenderse que los bloques 1715, 1725, 1730, 1740,
y 1750 son una optimización cuando se realizan antes de la ejecución
del gráfico de productores.
En el bloque 1705, se determina si la
dependencia es una dependencia de argumento ya enlazada debido a una
dependencia adherente. Si es así, el control pasa al bloque 1710
donde se completa el flujo para esta dependencia; de lo contrario,
el control pasa al bloque 1715. Con respecto a la realización de la
invención mostrada en la Figura 11C, se comprueba el indicador de
adherencia para determinar si la ID del argumento de esta
dependencia está sujeta a una dependencia del argumento de
suscripción adherente o una dependencia del argumento declarada
hacia arriba.
En el bloque 1715, se determina si la
dependencia es una dependencia contingente. Si es así, el control
pasa al bloque 1720; en caso contrario, el control pasa al bloque
1725. El bloque 1715 se realiza comprobando la declaración de
dependencias del productor del productor hijo identificado por la
dependencia a determinar si está vacía (el productor hijo es un
productor independiente). Con respecto a las Figuras
13A-J, esto podría ser cierto para productores con
números en círculos discontinuos (por ejemplo, en la Figura 13D, el
productor CU::IV::DELTA), pero no cierto para los otros productores
(por ejemplo, en la Figura 13D, el productor CW::IY::BETA). De este
modo, con referencia a la Figura 13D, el bloque 1715 está
representado por los números 1, 4, y 8 en un círculo. El bloque
1715 y el flujo desde el mismo a través de los bloques
1725-1750 es una optimización que evita tanto
añadir/enlazar los productores con números en círculos discontinuos
al gráfico de productores, como también dividir el trabajo de
ejecutar productores entre la generación automatizada de gráficos de
productores y la ejecución del gráfico de productores.
En el bloque 1720, se invoca un nuevo comando
del productor para el productor de determinación de dependencia y el
flujo termina. Por ejemplo, con referencia a la Figura 13D, el
bloque 1720 causa lo que se representa por los números 5, 6, y 7 en
un círculo.
En el bloque 1725, se ejecuta el productor de
determinación de dependencia y el control pasa al bloque 1730. Por
ejemplo, con referencia a la Figura 13D, el bloque 1725 se
representa por un número 11 en un círculo (de esta forma el flujo
de la Figura 17 ilustró la realización descrita anteriormente en la
cual los números 9 y 10 en un círculo de la Figura 13D no se
realizan).
En el bloque 1730, se determina si la
dependencia es una dependencia no de suscripción. Si es así, el
control pasa al bloque 1750; de lo contrario el control pasa al
bloque 1740. En otras palabras, en el bloque 1725, se ejecuta el
código de determinación de dependencias del productor en el método
del productor de determinación de dependencias, que es parte de la
declaración de dependencias del productor del productor padre. Una
vez ejecutado este código de declaración de dependencias del
productor, cuyo código identificaría si esta dependencia es una
dependencia de suscripción se determina el tipo de dependencias del
productor padre. Con respecto al ejemplo en la Figura 13D, el
número 11 en un círculo daría como resultado que el flujo de la
Figura 17 pase desde el bloque 1730 al bloque 1750.
En el bloque 1750, se determina el número de
productores devueltos por la ejecución del productor de
determinación de dependencias en el bloque 1725 y se invoca un
nuevo comando del productor para cada uno, usando los argumentos
descritos en la Tabla 2, incluyendo la referencia al productor de
determinación de dependencias ejecutado en 1725. Por ejemplo, con
referencia a la Figura 13D, el bloque 1750 causaría los números 12 y
el 13 en un círculo y las letras C y la D en un círculo.
Con referencia al ejemplo de suscripción
absorbente de las figuras 14B, el bloque 1725 representa un número
4 en un círculo; el cual causa que el flujo pase a través del bloque
1730 al bloque 1740.
En el bloque 1740, la suscripción se añade al
registro de suscripción, y si la suscripción es absorbente se marca
como incompleta. Desde el bloque 1740, el control pasa al bloque
1745. Con referencia a la realización de la invención mostrada en
la Figura 14A, el registro de suscripción se rellena con la
suscripción como se ha descrito anteriormente.
En el bloque 1745, todos los productores
representados se rastrean para ver si coinciden en el criterio de
suscripción (y de este modo son productores de disparo), y se
procesan cualesquiera coincidentes.
La Figura 18 es un diagrama de flujo para el
bloque 1745 de la Figura 17 de acuerdo con una realización de la
invención. De este modo, el control fluye desde el bloque 1740 al
bloque 1800 en el bloque 1745. En el bloque 1800, para cada uno de
los productores representados, se realizan los bloques siguientes
1810-1830.
En el bloque 1810, se determina si el productor
cumple los criterios de suscripción. Si es así, el control pasa al
bloque 1815; de lo contrario el control pasa al bloque 1830 donde el
flujo termina para el productor que se está procesando actualmente.
Con referencia a las realizaciones de la invención mostradas en la
Figura 11C y 14C, los gráficos de productores se acceden para
determinar si incluyen productores que cumplan el criterio de
suscripción.
El modo de procesamiento de un productor
coincidente depende del tipo de suscripción que se esté procesando.
Con referencia al bloque 1815, si la suscripción es del tipo
absorbente, el control pasa al bloque 1825; de lo contrario el
control pasa al bloque 1820. El bloque 1815 se realizaría en
respuesta al tipo de suscripción añadida en el bloque 1740 ó
2235.
En el bloque 1825, el productor coincidente se
añade al registro de suscripción y el productor con suscripción
absorbente se enlaza con el productor coincidente. Desde el bloque
1825, el control pasa al bloque 1830. Con referencia a las
realizaciones de la invención mostradas en las Figuras 11C y
14A-B, se realiza lo siguiente: 1) se usó el
criterio de suscripción desde el criterio de suscripción para la
columna de productores de disparo 1410 en el bloque 1810 y se
localizó un productor coincidente (por ejemplo, uno de los
productores 1460A-N); 2) el productor coincidente
se añade a la columna de productores coincidentes 1415 en la fila de
la suscripción; y 3) el productor con la suscripción absorbente
(por ejemplo, el productor 1450 se enlaza al productor coincidente
(por ejemplo, uno de los productores 1460A-N) en la
estructura de gráficos de productores de la Figura 11C (usando la
referencia del productor de determinación de dependencia extraída de
la columna de referencia del productor de determinación de
dependencia 1421 del registro de suscripción 14A para la suscripción
absorbente determinada).
En el bloque 1820, se invoca un nuevo comando
del productor para el productor padre a crear. Desde el bloque
1820, el control pasa al bloque 1830 donde termina el diagrama de
flujo para al productor actual seleccionado en el bloque 1800. Con
referencia a las realizaciones de la invención mostradas en las
Figuras 14A y la 14C, se realiza lo siguiente: 1) se usó el
criterio de suscripción desde el criterio de suscripción para la
columna de productores de disparo 1410 en el bloque 1810 y se
localizó un productor coincidente (por ejemplo, el productor 1475);
y 2) se invoca un nuevo comando de productor con los parámetros de
la tabla 2 fijados como sigue: a) el tipo de llamada es una
suscripción adherente; b) un productor llamante es la clave del
productor del productor hijo llamante (por ejemplo, el productor
1475); c) el productor llamado es la clave de productor del
productor padre llamado a crear (por ejemplo, el productor 1480);
la clave de productor que se forma usando la la clave de método, la
clase, y la instancia del padre desde las características de la
suscripción adherente para el productor padre a crear (Figura 14A,
columnas 1430, 1435, y 1437) (si la clave de instancia está vacía,
se usa la clave de instancia del productor hijo llamante); d) el
modo del enlace para el productor padre llamado (Figura 14A,
columna del modo de enlace 1425); y e) la referencia del productor
de determinación de dependencia extraída de la columna de
referencias del productor de determinación de dependencia 1421 del
registro de suscripciones 14A para la suscripción adherente
determinada.
La Figura 19 es un diagrama de flujo para el
bloque 1630 de la Figura 16 de acuerdo con una realización de la
invención. De este modo, el control fluye desde el bloque 1625 al
bloque 1900 en el bloque 1630. La Figura 19 es muy similar a la
Figura 18. Específicamente, los bloques 1910, 1915, 1920, y 1930 de
la Figura 19 son idénticos que los bloques 1810, 1815, 1820, y
1830; mientras que el bloque 1900 y el 1925 difieren de los bloques
1800 y 1825. Como tal, sólo se describirán las diferencias en este
punto.
El bloque 1900 indica que el flujo se realiza
para cada una de las suscripciones registradas, mientras que el
bloque 1800 indica que el flujo se realiza para cada uno de los
productores representados. De este modo, cuando el flujo de la
Figura 18 está centrado sobre una suscripción única y rastreando
todos los productores, el flujo de la Figura 19 se centra sobre un
productor único y rastrea todas las suscripciones.
El bloque 1925 es el mismo que el bloque 1825,
con la excepción de que la suscripción absorbente está marcada como
incompleta. Con referencia a la realización de la invención mostrada
en la Figura 14A, la columna completada 1420 en la fila apropiada se
actualiza para indicar incompleta.
La Figura 20 es un diagrama de flujo para los
bloques 1635 y 1670 de la Figura 16 de acuerdo con una realización
de la invención. De este modo, el control fluye desde el bloque 1605
y el bloque 1630 al bloque 2005 en los bloques 1635 y 1670. En el
bloque 2005 se determina si esta iteración del diagrama de flujo de
la Figura 16 se invocó debido a una dependencia (por ejemplo, desde
el bloque 1630 (bloque 1920) ó 1650 (bloques 1720, 1750 ó
1745/1820) de la iteración anterior). Si no es así, el control pasa
al bloque 1640 ó 1675 dependiendo de donde se introdujo el flujo
(desde el bloque 1630 ó 1605).
En el bloque 2010, se determina si el flujo se
llamó debido a una suscripción adherente o una situación declarada
hacia arriba no de suscripción. Si no es así, el control pasa al
bloque 2015; de lo contrario el control pasa al bloque 2020. El
bloque 2010 se realiza comprobando el parámetro del tipo de llamada
de la Tabla 2 (es decir el tipo de llamada es una suscripción
adherente o no de suscripción declarada hacia arriba o no). Con
referencia a las realizaciones de la invención mostradas en las
Figuras 18 y 19, si se invocó el nuevo comando del productor desde
los bloques 1820 ó 1920.
En el bloque 2020, el productor padre actual se
enlaza con el productor hijo llamante. Con referencia a las
realizaciones de la invención mostradas en las Figuras 11C y 14C, el
productor padre llamado (por ejemplo, el productor 1480)
identificado por el parámetro desde la columna del productor llamado
de la tabla 2 está enlazado en la estructura de los gráficos de
productores de la Figura 11C al productor hijo llamante (por
ejemplo, el productor 1475) identificado por el parámetro desde la
columna del productor llamante de la tabla 2, usando el modo de
enlace y la referencia del productor de determinación de dependencia
identificado por el parámetro del modo de enlace y las columnas de
referencias del productor de determinación de la tabla 2. Si el
padre existía anteriormente, el comportamiento del bloque 2020 imita
el comportamiento de una dependencia de suscripción absorbente en
el sentido de que un argumento único se puede mapear a cero o más
productores hijo.
En el bloque 2015, el productor padre llamante
se enlaza con el productor hijo llamado actual. Con referencia a la
realización de la invención mostrada en la Figura 11C, el productor
padre llamante identificado por el parámetro desde la columna del
productor llamante de la tabla 2 se enlaza en la estructura de
gráficos de productores de la Figura 11C al productor hijo llamado
identificado por el parámetro desde la columna del productor
llamado de la Tabla 2, usando la referencia del productor de
determinación de dependencia identificado por la columna de
referencias del productor de determinación de dependencia de la
tabla 2. Desde los bloques 2015 y 2020 el control pasa al bloque
1640 ó 1675 dependiendo de desde donde se introdujo el flujo (desde
el bloque 1605 ó 1630).
La Figura 21 es un diagrama de flujo para anular
productores de acuerdo con una realización de la invención. Con
referencia a la Figura 10, el flujo de la Figura 21 se realiza por
el módulo de anulación de productores 1045 (o, como se describió
con referencia a las realizaciones alternativas respecto a la Figura
10, el módulo maneja las anulaciones y restauraciones).
En respuesta al comando de anulación del
productor (bloque 2110), el control pasa al bloque 2120. En el
bloque 2120, se invoca un nuevo comando de productor para el
productor identificado por el comando de anulación del productor y
el control pasa al bloque 2130. El bloque 2120 se realiza en una
realización de la invención en caso de que el productor a anular no
se haya representado aún, así como para marcar el productor como no
ejecutado (bloque 1640 ó 1680) y registrarlo en el registro de
comienzo de ejecución (bloque 1665). Una realización alternativa de
la invención que no permite la anulación de un productor que está
aún representado realizaría una comprobación adicional entre los
bloques 1605 y 1610 para determinar si se llamó este nuevo comando
del productor en respuesta a un comando de anulación de productor,
y para indicar un error si este nuevo comando del productor se llamó
en respuesta a un comando de anulación del productor.
En el bloque 2130, se fija la salida en el
almacenamiento temporal de la salida del productor (y en la
instancia si un campo) y el productor se marca como anulado.
La Figura 22A es una parte de un diagrama de
flujo para la ejecución de gráficos de productores actuales de
acuerdo con una realización de la invención; aunque la Figura 22B es
otra parte de un diagrama de flujo para la ejecución de los
gráficos de productores actuales de acuerdo con una realización de
la invención. Con referencia a la Figura 10, se realiza el flujo de
la Figura 22 se realiza por el módulo de ejecución de gráficos del
productores 1070.
En respuesta al comando de ejecución global, el
bloque 2200 muestra que se selecciona un conjunto de candidatos
para ejecutarse en base a los productores sobre el registro de
comienzo de ejecución y el control pasa el bloque 2205. En una
realización de la invención los productores anulados se marcan como
no ejecutados y la ejecución de los mismos devuelve su resultado
anulado (en oposición a causar que se ejecuten sus métodos), el
conjunto actual de productores candidatos son los productores sobre
el registro de comienzo de ejecución. Aunque anteriormente se ha
descrito una realización de la invención en la cual los productores
anulados se marcan como no ejecutados y la ejecución de los mismos
devuelve su resultado anulado (en oposición a causar que se
ejecuten sus métodos), realizaciones alternativas de la invención
pueden operar de forma diferente (por ejemplo, marcar los
productores anulados como ejecutados y cuando se selecciona el
conjunto actual de productores candidatos, los productores
independientes del registro de comienzo de ejecución y se
seleccionan los padres de los productores anulados sobe el registro
de comienzo de ejecución).
En el bloque 2205, se selecciona un subconjunto
de productores listos para su ejecución desde el conjunto del
conjunto de productores candidatos y el control pasa al bloque 2210.
Más adelante en este documento se describe un modo de ejemplo de
realizar el bloque 2205.
En el bloque 2210, los productores del conjunto
actual de los productores listos se clasifican por tipos - los
productores normalizados van al bloque 2215 y los productores de
determinación de dependencia van al bloque 2225. En una realización
de la invención, el bloque 2210 se realiza comprobando la clase de
retorno del productor. Con referencia a las Figuras 10 y 11D, la
estructura de seguimiento de métodos se accede para determinar si
la clase de salida del productor es una DEP, y de este modo este
productor es un productor de determinación de dependencia.
En el bloque 2215, cualesquiera productores
normalizados en el conjunto actual de productores listos se ejecutan
y el control pasa al bloque 2220. En una realización de la
invención, se realiza el bloque 2215 llamando el método con
cualesquiera parámetros de entrada mapeados desde las salidas de
cualesquiera productores hijos que resultan desde las dependencias
de los argumentos (para argumentos, se usa la ID de argumento del
modo de enlace para mapear la salida del hijo apropiado al
argumento de entrada apropiado del método que se está ejecutando).
En algunas realizaciones de la invención, tal ejecución puede dar
como resultado la ejecución del código en el método de un productor
hijo que escribe una salida a un mecanismo determinado (tal como
fijar una variable global, fijar un campo en una instancia que no
es la salida del productor, impactar una fuente de datos externa,
etc.) o un código en el método del productor padre que lee esa
salida desde el mecanismo determinado). En el bloque 2220, para los
padres, si los hay, que tienen una suscripción absorbente sobre
cualquiera de estos productores normalizados ejecutados, la
suscripción se marca como incompleta. Desde el bloque 2220, el
control pasa al bloque 2245. Con referencia a la Figura 14A, la fila
apropiada de la columna de completados 1420 se fija para indicar
incompleta.
En el bloque 2225, cualesquiera productores de
determinación de dependencia en el conjunto actual de productores
listos se preparan para su ejecución y el control pasa al bloque
2230. Más adelante en este documento se describe un modo de ejemplo
de realizar el bloque 2225.
En el bloque 2230, se ejecutan cualesquiera
productores de determinación de dependencia en el conjunto actual de
productores listos y el control pasa al bloque 2235. En una
realización de la invención, se realiza el bloque 2230 de forma
similar al bloque 2215.
En el bloque 2235, se ejecuta un nuevo comando
del productor para cualesquiera productores descubiertos, y se
realiza el registro de suscripción y el procesamiento para
cualesquiera suscripciones. El nuevo comando del productor parte
del bloque 2235 se realiza de forma similar al bloque 1750, mientras
que se realiza el registro de suscripción y el procesamiento de
forma similar que los bloques 1740 y 1745.
En el bloque 2240, añadimos al conjunto de
productores candidatos los nuevamente añadidos al registro de
comienzos de ejecución. Desde el bloque 2240, el control pasa al
bloque 2245. El bloque 2240 se realiza de forma similar al bloque
2200, excepto que sólo los productores nuevamente añadidos al
registro de comienzos de ejecución como resultado de los bloques
2230 y 2235 se añaden al conjunto de productores candidatos.
En el bloque 2245, los productores que se
ejecutaron se marcan como ejecutados, el almacenamiento temporal de
salida del productor (y el almacenamiento temporal de instancias) se
actualizan si es necesario, cualesquiera productores padre de los
productores que se ejecutaron se añaden al conjunto actual de
productores candidatos, y los productores que se ejecutaron se
eliminan del conjunto actual de productores candidatos y listos.
Desde el bloque 2245, el control pasa al bloque 2250.
En el bloque 2250, se determina si el conjunto
de productores candidatos está vacío. Si no lo está, el control pasa
de vuelta al bloque 2205; de lo contrario el control pasa al bloque
2255.
En el bloque 2255, se determina si se han
completado todas las suscripciones. Si es así, el control pasa al
bloque 2265 donde termina el diagrama de flujo; de lo contrario, el
control pasa al bloque 2260. Con referencia a la realización de la
invención en la Figura 14A, la columna del tipo de suscripción 1405
y la columna de completas 1420 se exploran en busca de cualesquiera
suscripciones absorbentes que no estén completas.
En el bloque 2260 se procesan las suscripciones
absorbentes incompletas y el control pasa de vuelta al bloque 2205.
Un modo de ejemplo de realizar el bloque 2260 se describe más
adelante en este documento.
La Figura 23 es un diagrama de flujo para el
bloque 2205 de la Figura 22 de acuerdo con una realización de la
invención. De este modo, el control fluye desde el bloque 2200 al
bloque 2305 en el bloque 2205. En el bloque 2305, para cada uno de
los productores en el conjunto de productores candidatos, se
realizan los siguientes bloques 2310-2325.
En el bloque 2310, se determina si el productor
tiene cualesquiera dependencias de suscripción absorbente que esté
incompleta. Si es así, el control pasa al bloque 2325; de lo
contrario, el control pasa al bloque 2315. Con referencia a la
realización de la Figura 14A, se rastrea la columna de claves del
productor del suscriptor 1400 y la columna del tipo de suscripción
1405 en búsqueda de una coincidencia del productor seleccionado
actual y el tipo de suscripción absorbente; y si se encuentra una
coincidencia, se comprueba la columna de completas 1420 en la fila
apropiada para determinar el estado de la dependencia de la
suscripción absorbente.
En el bloque 2315, se determina si están
ejecutados los productores de los cuales depende el productor
seleccionado actualmente. Si no lo están, el control pasa al bloque
2325; de lo contrario, el control pasa al bloque 2320. Con respecto
a la realización de la invención mostrada en la Figura 11C, la
columna de marcado de ejecución incremental 1180 para las filas de
las dependencias del hijo se comprueban para determinar el estado de
ejecución de los hijos del productor seleccionado actualmente.
En el bloque 2320, el productor candidato
seleccionado actualmente se añade al conjunto actual de productores
listos y el control pasa al bloque 2325.
En el bloque 2325, el flujo termina para el
productor actual seleccionado en el bloque 2305.
La Figura 24 es un diagrama de flujo para el
bloque 2225 de la Figura 22 de acuerdo con una realización de la
invención. De este modo el control fluye desde el bloque 2210 al
bloque 2405 en el bloque 2225. En el bloque 2405, para cada
productor de determinación de dependencia se realizan los siguientes
bloques 2410-2430.
En el bloque 2410, se determina el tipo de
cualesquiera dependencias anteriores generadas por el productor de
determinación de dependencias seleccionado actualmente. Si el tipo
de la dependencia es de no suscripción, a continuación el control
pasa al bloque 2420; si el tipo es una suscripción absorbente,
entonces el control pasa al bloque 2415; mientras que, si el tipo
es una suscripción adherente, a continuación el control pasa al
bloque 2425. El bloque 2410 se determina comprobando la salida
actual del productor almacenado en el almacenamiento temporal de la
salida del productor. Con referencia a la clase DEP, la salida
indicaría de no suscripción, suscripción absorbente, y suscripción
adherente.
En ambos bloques 2415 y 2425, se elimina la
entrada desde el registro de suscripción. Con referencia a la
realización de la invención mostrada en las Figuras
14A-C, se realiza lo siguiente: 1) para las
suscripciones absorbentes (bloque 2415), el productor de
determinación de dependencias (por ejemplo, el productor 1455) se
usa para determinar su productor padre (por ejemplo, el productor
1450) en los gráficos de productores, y a continuación se busca el
productor padre en el registro de suscripciones y se elimina su
entrada; y 2) para suscripciones adherentes (bloque 2425), el
productor de determinación de dependencia (por ejemplo, el
productor 1470) se busca en el registro de suscripción y se elimina
su entrada. Desde el bloque 2415, el control pasa al bloque 2420;
desde el bloque 2425, el control pasa al bloque 2420.
En el bloque 2420, los enlaces ya creados por el
productor de determinación de dependencia seleccionado actualmente
se borran de los gráficos de productores y el control pasa al bloque
2430. Con referencia a la realización de la invención mostrada en
la Figura 11C, se realiza lo siguiente. En primer lugar se determina
si el productor de determinación de dependencias se ha
"adherido" sobre un productor existente. Esto se hace
rastreando la columna de enlaces del productor hijo del productor
de determinación de dependencias en la Figura 11C, y comprobando si
uno de los enlaces tiene un indicador de adherencia que indica
adherencia.
Si el productor de determinación de dependencia
no está adherido sobre un productor existente, a continuación: 1)
para un productor de determinación de dependencia que ha producido
dependencias declaradas hacia abajo de no suscripción (dependencias
de argumento, campo, o secuenciación), el padre del productor de
determinación de dependencias se accede en el gráfico de
productores a través de la columna de referencias del productor
padre 1150 en la fila del productor de determinación de dependencias
seleccionado actualmente, y en esta entrada del productor padre, se
accede la columna de enlaces del productor hijo 1160 para hacer
coincidir la referencia del productor de determinación de
dependencias y se borran todas las referencia de los productores
hijo que tienen esa referencia del productor de determinación de
dependencia; el 2) para un productor de determinación de
dependencias que ha producido dependencias declaradas hacia arriba
de no suscripción, el padre del productor de determinación de
dependencias se accede en el gráfico de productores a través de la
columna de enlaces del productor padre 1150 en la fila del
productor de determinación de dependencias actualmente seleccionado,
y en esta entrada del productor padre, se accede la columna de
enlaces del productor padre 1150 para hacer coincidir la referencia
del productor de determinación de dependencias, y se borran todas
referencias de los productores padre que tienen esa referencia del
productor de determinación de dependencias; 3) para un productor de
determinación de dependencias que ha producido una suscripción
absorbente, se tiene el mismo comportamiento que las dependencias
declaradas hacia abajo de no suscripción; y 4) para un productor de
determinación de dependencias que ha producido una suscripción
adherente, la referencia del productor de determinación de
dependencias extraída de la columna 1421 del registro de
suscripciones 14A anterior a la eliminación de la suscripción se
busca en la estructura de gráficos de productores en la columna de
enlaces del productor padre 1150, y se borran todas las referencias
de los productores padre que tienen esa referencia del productor de
determinación de dependencias.
Si el productor de determinación de dependencia
se ha adherido sobre un productor existente, como resultado de una
dependencia declarada hacia arriba de no suscripción o una
suscripción adherente, entonces se accede al productor hijo sobre
el que se ha adherido el productor de determinación de dependencias
(el productor hijo en la columna 1160 con un indicador de
adherencia indicando adherencia), y en esta entrada del productor
hijo, se accede a la columna de enlaces del productor padre 1150
para hacer coincidir la referencia del productor de determinación
de dependencia, y se borran todas las referencias de los productores
padres que tienen esa referencia del productor de determinación de
dependencias.
En el bloque 2430, el flujo termina para el
productor de determinación de dependencias seleccionado en el bloque
2405.
La Figura 25 es un diagrama de flujo para el
bloque 2260 de la Figura 22 de acuerdo con una realización de la
invención. De este modo, el control fluye desde el bloque 2255 al
bloque 2505 en el bloque 2260. En el bloque 2505, para cada uno de
los productores con dependencia de suscripción absorbente que está
incompleta se realizan los siguientes bloques
2510-2525.
\newpage
En el bloque 2510, se determina si se han
ejecutado todos los productores coincidentes. Si es así, el control
pasa al bloque 2515; de lo contrario, el control pasa al bloque
2525. Con referencia a las realizaciones de las Figuras 11C y 14C,
se accede la columna de productores coincidentes 1415 en la fila
apropiada para determinar los productores coincidentes, y se
comprueba la columna de ejecución incremental 1180 en las filas
apropiadas para cada uno de los productores coincidentes.
En el bloque 2515, la suscripción absorbente se
marca como completa y el control pasa al bloque 2520. Con referencia
a las realizaciones de la Figura 14A, la columna de completas 1420
en la fila apropiada se fija para indicar completa.
En el bloque 2520, el productor seleccionado en
el bloque 2505 se añade al conjunto actual de productores candidatos
y el control pasa al bloque 2525.
En el bloque 2525, el flujo termina para el
productor seleccionado en el bloque 2505.
En algunas realizaciones, los escenarios
proporcionan un modo para especificar el rellenado de una colección
con resultados de invocar múltiples veces los mismos métodos de las
mismas instancias con diferentes parámetros; y de esta forma evitar
la necesidad de escribir en múltiples invocaciones de código de
secuenciación de invocación manual de los mismos métodos de las
mismas instancias con diferentes parámetros. En algunas
realizaciones de la invención que soportan dependencias dinámicas,
dos escenarios diferentes de una aplicación pueden tener gráficos
de productores estructuralmente diferentes o
sub-gráficos en un gráfico de productores de la
aplicación si se usan diferentes instancias, diferentes métodos,
y/o diferentes clases en los escenarios. Por ejemplo, se
proporciona un programa de aplicación de ejemplo para calcular una
salida en base a un modelo matemático que toma como entrada un
vector nombrados de valores numéricos. Para evaluar los impactos de
usar diferentes vectores nombrados, pueden crearse escenarios que
usan diferentes instancias de vectores, donde cada instancia
corresponde a un distinto vector. Como alternativa, el programa de
aplicación de ejemplo puede usar el mismo ejemplo de vector, pero
diferentes modelos matemáticos para calcular la salida de interés.
Para evaluar el impacto de adoptar un primer modelo matemático
frente a adoptar un segundo modelo matemático, pueden crearse un
primer escenario y un segundo escenario. En el primer escenario, se
invoca un primer método que representa el primer modelo. En el
segundo escenario, se invoca un segundo método que representa el
segundo modelo. Además, la clase en el primer escenario puede ser o
no la misma que la clase en el segundo escenario. Si el primero y
el segundo métodos se definen para que estén dentro de la misma
clase, entonces la clase permanece la misma en el primero y el
segundo escenarios. Sin embargo, si el primer método se define para
que esté dentro de la primera clase y el segundo método se define
para que esté dentro de la segunda clase diferente de la primera
clase, entonces el primero y el segundo escenarios tienen diferentes
clases. Obsérvese que el primer método en la primera clase y el
segundo método en la segunda clase pueden tener o no nombres
idénticos.
La Figura 26 ilustra una realización alternativa
de la invención que soporta un escenario. Similar a la realización
mostrada anteriormente en la Figura 1A, el código fuente orientado a
objetos 100 incluye una clase 102, que a su vez incluye un método
104 y una declaración de dependencias del productor 106 para el
método 104. Por supuesto, la clase 102 típicamente incluiría uno o
más campos (no mostrados) y métodos adicionales (no mostrados).
Además, el código fuente orientado a objetos 100 típicamente
incluiría clases adicionales.
Como se ha descrito anteriormente con respecto a
la Figura 1A, se representa una instancia 108 de la clase 102
durante el tiempo de ejecución. La instancia 108 incluye los datos
de los campos de la clase 102. Además, se representa un productor
110, donde el productor 110 identifica la clase 102, la instancia
108 de la clase 102 (que tiene asociada con la misma el método 104
de la clase 102), y el método 104 de la clase 102. La declaración
de dependencias del productor 106 identifica para la rutina de
ejecución un conjunto de cero o más productores 112 (denominados
como productores hijos del productor 110) que deben ejecutarse antes
de la ejecución del productor 110. En otras palabras, el productor
110 depende del conjunto de cero o más productores 112. Además o en
lugar de consumir salidas del conjunto de productores 112, el
productor 110 puede consumir datos de la instancia 108. Además, el
productor 110 proporciona al menos una salida, cuya salida puede ser
interna a la instancia 108 (y de este modo, modificar los datos de
la instancia 108) y/o puede ser externa; de cualquier modo, la
salida del productor 110 puede consumirse por un conjunto de cero o
más productores distintos 114 (denominados como productores padres
del productor 110)). En algunas realizaciones, un gráfico de
productores que comprende un productor 110, los productores padre
114, y los productores hijo 112 están asociados con un primer
escenario que tiene una clave única del primer escenario.
Para crear un gráfico de productores o un
sub-gráfico para un segundo escenario distinto del
primer escenario, pueden estresarse uno o más de los productores
110, 112, y 114. Para estresar un productor, el productor se
duplica. En una segunda realización un productor puede duplicarse
representando el productor a partir de la declaración de clases
102, el método determinado 104 y la declaración de dependencias del
productor 106. Como alternativa, un productor puede duplicarse
clonando o copiando el productor correspondiente existente para un
escenario de referencia (tal como el primer escenario descrito
anteriormente). A continuación se describen detalles de algunas
realizaciones de ambas técnicas. En general, todos los productores
impactados directamente están estresados. Además, los productores
dependientes de los productores impactados directamente, es decir
los productores impactados indirectamente, pueden estar también
estresados. En una realización, un productor impactado
indirectamente está estresado si el productor impactado
indirectamente cae sobre el camino entre un productor de interés y
los productores impactados directamente. Refiriéndonos de nuevo a la
Figura 26, supongamos que el productor 110 es un productor
impactado directamente para el segundo escenario, entonces el
productor 110 se estresa para generar un productor estresado 2610
para el segundo escenario. Todos los productores padre 114 del
productor 110 están impactados indirectamente porque todos los
productores padre 114 dependen del productor 110. Si un productor
padre dentro del conjunto de productores padre 114 cae dentro del
camino entre un productor de interés y el productor 110, entonces el
productor padre está estresado. Una colección de productores padres
estresados del productor 110 se representa por el conjunto 2614 para
el segundo escenario. Además, si hay una dependencia dinámica entre
algunos de los productores dentro del conjunto 2614, entonces los
productores en el conjunto 2614 pueden estresarse de forma recursiva
para el segundo escenario. Como para los productores hijos 112 del
productor 110, los productores hijo 112 pueden no estar estresados
para el segundo escenario ya que los productores hijos 112 no son
dependientes del productor 110. Sin embargo, si un productor hijo
dentro del conjunto 112 está directamente o indirectamente impactado
en el segundo escenario, entonces el productor hijo impactado
dentro del conjunto 112 puede estresarse para generar un productor
hijo estresado 2612 para el segundo escenario. Las dependencias
entre los productores 2610, 2612, y 2614 pueden permanecer sin
cambiar en el segundo escenario. Como alternativa, algunas o todas
las dependencias entre los productores 2610, 2612, y 2614 pueden
cambiar en el
segundo escenario. En la Figura 26, el gráfico de productores del segundo escenario se ilustra con líneas de puntos.
segundo escenario. En la Figura 26, el gráfico de productores del segundo escenario se ilustra con líneas de puntos.
En una realización de la invención todos los
productores en un primer gráfico de productores de un programa de
aplicación están estresados para un nuevo escenario. Como resultado,
se crea un gráfico de productores del productor estresado y se
añade a la colección de gráficos de productores que representan un
programa de aplicación. Sin embargo, puede permitirse la
optimización en algunas realizaciones de modo que sólo un
subconjunto de productores esté estresado para crear un
sub-gráfico dentro del primer gráfico de productores
para el nuevo escenario. Más detalles de algunas realizaciones de
la creación de gráficos de productores o
sub-gráficos de productores se tratan más
adelante.
La Figura 27A es un diagrama de bloques que
ilustra una rutina de ejecución con soporte de programación
orientado a gráficos de productores así como un soporte de
escenario de acuerdo con una realización de la invención. Detalles
de las referencias numéricas 320, 325, 330, 335, 340, 380, 384 y 345
también se han descrito anteriormente con referencia a la Figura
3A. Para soportar el escenario, la rutina de ejecución 335 también
recibe información de representación del escenario 328. La
información de representación del escenario 328 también puede
proporcionarse a la rutina de ejecución 335 a través de diversas
maneras, tales como, por ejemplo, a través del código del cliente
(tal como, una interfaz gráfica de usuario (GUI), una interfaz de
línea de comandos (CLI), etc.). Como alternativa, la información de
representación del escenario 328 puede especificarse en una
declaración de dependencias del productor (tal como un
establecimiento de declaraciones de dependencia del productor o un
código de declaración de dependencias del productor). Como
alternativa, algo o toda la información la información de
representación del escenario 328 pude especificarse en un código
fuente de un método de un productor de generación de productores
estresados. Más detalles del productor de generación de productores
estresados se tratan más adelante.
De acuerdo con una realización de la invención,
se proporciona información de representación de escenarios 328 para
un nuevo módulo de escenarios 337 de la rutina de ejecución 335. En
base a la información de representación de escenarios 328, el nuevo
módulo de escenarios 337 representa nuevos escenarios. En algunas
realizaciones, la rutina de ejecución 335 incluye un estructura de
seguimiento de escenarios 338 para almacenar claves de escenarios,
referencias a objetos de escenario, que pueden especificar un
conjunto de uno o más productores impactados directamente y las
salidas predeterminadas correspondientes o las transformaciones de
salida de los productores impactados directamente, y una estructura
de seguimiento de la trayectoria del impacto, la cual mantendrá
posteriormente la lista de productores impactados por el escenario.
En base al conjunto actual de uno o más productores estresados
cuyas salidas son de interés 325, el módulo de generación
automatizada del gráfico de productores 340 puede generar un
gráfico de productores o un sub-gráfico para uno o
más productores estresados de interés actuando sobre la estructura
de seguimiento del escenario 338. Para evaluar el impacto sobre el
productor estresado de interés por una o más salidas predeterminadas
de uno o más productores impactados directamente en los escenarios,
el módulo de ejecución de gráficos de productores 345 puede pasearse
a través el gráfico o sub-gráfico de productores
generado para ejecutar productores impactados, directamente o
indirectamente por las salidas predeterminadas o las
transformaciones de salida para el escenario.
En algunas realizaciones, la información del
escenario 328 incluye una clave del escenario de referencia, una
clave del escenario objetivo, una lista de uno o más productores
impactados directamente y las salidas correspondientes
predeterminadas de los productores impactados directamente. En
general, una clave de escenario es una clave única para identificar
un escenario. En algunas realizaciones, un escenario de referencia
es un escenario existente, que puede incluir los estados actuales y
las salidas del programa de aplicación. Un escenario objetivo es
una colección de impactos atribuidos a la lista de los productores
impactados directamente y sus salidas correspondientes. Para el
escenario objetivo, las salidas de los productores identificados por
la lista de productores impactados directamente se anularán con las
salidas especificadas en la lista. La rutina de ejecución 335 puede
usar el escenario de referencia para encontrar productores
impactados indirectamente por los productores impactados
directamente. El impacto sobe un productor estresado de interés por
los productores impactados directamente puede evaluarse usando el
escenario objetivo sin sobrescribir o modificar el escenario de
referencia. En otras palabras, las salidas existentes y/o las
instancias de los productores se conservan o mantienen para el
primer escenario. En algunas realizaciones, una porción del gráfico
de productores del escenario de referencia puede enlazarse con el
gráfico de productores del escenario objetivo si el productor de
interés depende de la porción y la porción no está impactada,
directamente o indirectamente, por los productores impactados
directamente en el escenario objetivo. En otras palabras, puede
crearse un sub-gráfico para el escenario objetivo
dentro del gráfico de productores del escenario de referencia.
La Figura 27B es un diagrama de bloques que
ilustra una rutina de ejecución con soporte de programación
orientado a gráficos de productores que también soporta ejecución
incremental y salidas de productores anuladas, así como escenarios,
de acuerdo con una realización de la invención. Se han tratado
anteriormente detalles de los componentes 320, 325, 350, 352, 354,
360, 365, 380, 382, 384, 370, 396, 390, 392, y 394 con referencia a
la Figura 3B. Para soportar escenarios, se introduce la información
de representación de escenarios 328 en el módulo de generación
automatizada de gráficos de productores 365. Detalles de algunas
realizaciones de la información de representación de escenarios 328
se han descrito anteriormente con referencia a la Figura 27A. En
base a la información de representación de escenarios 328, el módulo
de generación automatizada de gráficos de productores 365 puede
construir un gráfico o sub-gráfico de productores
para cada uno de los escenarios. Más detalles de algunas
realizaciones de la construcción de gráficos o
sub-gráficos de productores para un escenario se
describen a continuación. Para evaluar el impacto sobre un productor
estresado de interés (es decir, un productor de interés para un
escenario particular), el módulo de ejecución de gráficos de
productores 370 puede pasearse a través del gráfico o
sub-gráfico de productores creado para ese escenario
para ejecutar los productores consecuentemente. Más detalles de
algunas realizaciones de la ejecución de un gráfico o
sub-gráfico de productores para un escenario se
describen más adelante.
En algunas realizaciones, la información de
representación de escenarios 328 se proporciona al módulo de
anulación de la salida del productor 390, que anula la salida de
uno o más productores impactados directamente en el escenario
correspondiente. Anteriormente se han descrito detalles de la
operación del módulo de anulación de la salida del productor 390 con
respecto a la Figura 3B.
Las Figuras 28A-D ilustran
algunos ejemplos de gráficos de productores de un programa de
aplicación para diferentes escenarios. Refiriéndonos a la Figura
28A, se muestra un gráfico de productores para el escenario 1 en la
parte superior y se muestra un gráfico de productores para el
escenario 2 en la parte inferior. Los escenarios 1 y 2 tienen
claves de escenario "S1" y "S2" respectivamente. En
algunas realizaciones, el escenario 1 se denomina también como el
escenario por defecto o escenario de referencia. El programa de
aplicación de muestra tiene al menos siete productores, a saber,
Productor 1 - Productor 7, donde el Productor 1 depende directamente
del Productor 3 y el Productor 4, el Productor 2 depende
directamente del Productor 4, el Productor 3 depende directamente
del Productor 5 y el Productor 6, y el Productor 4 depende
directamente del Productor 7. En el escenario 1, la salida del
Productor 7 tiene el valor de X_{1} y la salida del Productor 1
tiene un valor de Z_{1}.
En algunas realizaciones, un productor estresado
se identifica por un par de una clave del productor y una clave de
escenario. Por ejemplo, el Productor estresado 1 en el escenario 2,
se identifica por el par (Productor 1, S2). Un productor estresado
puede especificarse por los usuarios a través de diversos modos, tal
como a través de un código de cliente (por ejemplo, una GUI, una
CLI, etc.). Como alternativa el programa de aplicación puede
incluir un productor de generación de productores estresados para
generar uno o más productores estresados. Una realización de
ejemplo de un productor de generación de productores estresados, a
saber, el Productor 8, se muestra en la Figura 28B. Refiriéndonos a
la Figura 28B, se muestra un seudo código de ejemplo del Productor
8 en el lateral derecho de la figura. Inicialmente, se define una
clase de productores estresados que tienen un campo que representa
la clave del productor de interés y un campo que representa el
escenario. En el ejemplo actual, el Productor 8 es independiente,
esto es, el establecimiento de declaraciones de dependencias del
productor del Productor 8 es nulo. Entonces un método del Productor
8 puede proporcionar información del escenario 2, asignando valores
a los campos de un productor estresado, y sacar una colección de
productores estresados.
Refiriéndonos de nuevo a la Figura 28A, el
escenario 2 se define por la siguiente información de usuario:
clave del escenario de referencia = nula, clave del escenario
objetivo = S2, y una lista de productores impactados directamente y
sus salida correspondientes. En el ejemplo actual, la lista de
productores impactados directamente tiene sólo un productor, a
saber el Productor 7, que tiene una salida asignada X_{2}. Sin
embargo, debería apreciarse que puede haber múltiples productores
impactados directamente en un escenario. En algunas realizaciones,
se reproduce todo el gráfico de productores para el escenario 2
creando cada uno de los Productor 1 - Productor 7, como se ilustró
en la Figura 28A. En el gráfico de productores para el escenario 2,
la salida del productor impactado directamente, es decir el
Productor 7, se anula con la salida especificada en la definición
del escenario 2, es decir X_{2}. El productor de interés en el
ejemplo actual es el Productor 1. Ejecutando el gráfico de
productores para el escenario 2, la salida del productor estresado
de interés, es decir, el Productor 1 en el escenario 2, se
determina que es Z_{2}. Aproximaciones alternativas para generar
sub-gráficos para los escenarios dentro de un
gráfico de productores existente están disponibles y algunas
realizaciones las mismas se describen en detalle a continuación.
Como se crea un segundo gráfico de productores
para el escenario 2, las modificaciones realizadas para el
escenario 2 (por ejemplo, anulación de la salida del Productor 7) no
afectan al gráfico de productores para el escenario 1. De este
modo, las salidas de los productores para el escenario 1 no se
sobrescriben ejecutando el programa de aplicación con las
modificaciones realizadas para el escenario 2, Como tal, la técnica
de crear escenarios es útil para evaluar impactos potenciales o
posibles y/o efectos de modificaciones sin perder las salidas
existentes de los productores en el programa de aplicación. Puede
ser útil retener o conservar las salidas existentes de los
productores por diversas razones, tales como, por ejemplo, para
determinar automáticamente derivadas de productores usando
diferencias finitas. Refiriéndonos de nuevo a la realización en la
Figura 28A y asumiendo que Z_{1}, Z_{2}, X_{1}, y X_{2} son
valores numéricos, la derivada del productor de interés, es decir
el Productor 1, desde el escenario 1 al escenario 2 puede calcularse
fácilmente usando salidas de ambos escenarios 1 y 2 como sigue:
Derivada del
Productor 1 = (Z_{1} - Z_{2}) / (X_{2} -
X_{1})
Además, el orden más alto de las derivadas, es
decir las derivadas de orden N (donde N es un número entero mayor de
uno), puede calcularse también fácilmente usando las salidas desde
diferentes escenarios. En algunas realizaciones, pueden calcularse
las derivadas cruzadas de una salida de un productor de interés
cuando cambia más de una entrada desde un escenario a otro. Por
ejemplo, supongamos que las entradas X_{1}, e Y_{1} se cambian a
X_{2}, e Y_{2} respectivamente, desde un escenario a otro. Como
resultado, se cambia una salida de un productor de interés desde
Z_{1} a Z_{2}. Entonces una derivada cruzada de la salida del
productor de interés puede calcularse como sigue:
Derivada
Cruzada del Productor de Interés = (Z_{2} - Z_{1})^{2}
/ (X_{2} - X_{1})* (Y_{2} -
Y_{1}))
Como la rutina de ejecución puede mantener el
seguimiento de las salidas de productores para diferentes escenarios
y puede determinar automáticamente las derivadas de los
productores, los programadores no tienen que escribir el código de
secuenciación de invocación manual para correr el programa de
aplicación múltiples veces, para mantener el seguimiento de las
salidas correspondientes, y para codificar métodos para calcular
derivadas usando las salidas correspondientes.
Como se ha mencionado anteriormente, están
disponibles las aproximaciones alternativas para generar un
sub-gráfico para el escenario 2. Ejemplos de algunas
aproximaciones alternativas se ilustran en las Figuras 28C y
28D.
Refiriéndonos a la Figura 28C, se usa una
técnica de enlazar una porción de un gráfico de productores para el
escenario 1 (es decir, el escenario de referencia) para generar el
gráfico de productores para el escenario 2 (es decir, el escenario
objetivo). Inicialmente, una rutina de ejecución puede recibir un
nuevo comando de productores estresados desde un usuario a través
del código del cliente para indicar que un productor de interés es
el Productor 1. Como alternativa, un productor de generación de
productores estresados, tal como el Productor 8, puede disparar la
invocación de un nuevo comando de productores estresados. En
respuesta al nuevo comando del productor estresado, la rutina de
ejecución construye un gráfico de productores para el Productor 1
para el Escenario 1, que también se denomina como escenario por
defecto o escenario de referencia. A continuación se recibe un
segundo nuevo comando de productor estresado del usuario a través
del código del cliente o disparado por un productor de generación
de productores estresados (por ejemplo, el Productor 8) para
indicar que un productor de interés es el Productor 2. En respuesta
al segundo nuevo comando de productor estresado, la rutina de
ejecución añade el Productor 2 dentro del gráfico de productores
para el escenario 1.
A continuación la rutina de ejecución recibe la
información de escenario que define el escenario 2. De nuevo, la
información de escenario puede ser del código del cliente. La
información de escenario especifica una clave del escenario de
referencia como "S1", una clave del escenario objetivo como
"S2", y una lista de productores impactados directamente y sus
salidas correspondientes para el escenario objetivo. La lista de
productores impactados directamente incluye sólo un productor en el
ejemplo actual, a saber el Productor 7, y la salida del Productor 7,
a saber X_{2}.
Para evaluar el impacto o efecto del escenario
2, es decir, cambiando la salida del Productor 7 a X_{2}, sobre
un productor, tal como el Productor 1, en el programa de aplicación,
el Productor 1 se identifica como productor de interés. Además, el
Productor 1 se identifica con el escenario que es de interés. De
este modo, se identifica un productor estresado, que es un par de
claves una del productor de interés y una clave de escenario, a
saber, {Productor 1, S2}. En algunas realizaciones, el productor de
interés se identifica por los usuarios a través del código de
cliente, tal como GUI, CLI, etc. Como alternativa, el productor de
interés puede identificarse en la salida del productor de
generación de productores estresados (por ejemplo, el Productor
8).
En base a las dependencias entre productores y
la información del escenario, la rutina de ejecución puede
identificar tanto productores impactados directamente como
indirectamente para el escenario 2. La identificación de los
productores impactados directamente e indirectamente también puede
denominarse como seguimiento. Los productores impactados
directamente e indirectamente pueden seguirse usando una estructura
de seguimiento de trayectorias de impactados (IPTS). En el ejemplo
actual, la estructura de seguimiento de trayectorias de impactados
contiene el Productor 7, el Productor 4, el Productor 1, y el
Productor 2. Obsérvese que los Productores 1, 2, y 4 son
productores impactados indirectamente mientras que el Productor 7 es
un productor impactado directamente para el escenario 2. En algunas
realizaciones, usando la lista de impactos del escenario 2, la
rutina de ejecución puede identificar los productores impactados
directamente. A continuación la rutina de ejecución puede usar el
gráfico de productores para el escenario 1 para seguir los
productores impactados indirectamente atravesando el gráfico de
productores para el escenario 1 desde los productores impactados
directamente como se indica por [B], [C], [D], y [E] en la Figura
28C. Si el gráfico de productores para el escenario 1 no se ha
construido aún, la rutina de ejecución pude construir el gráfico de
productores para el escenario 1 antes de seguir los productores
impactados indirectamente. Como alternativa, si no se proporciona
ningún escenario de referencia o el gráfico de productores para el
escenario de referencia no se ha construido aún, la rutina de
ejecución puede crear el productor de interés, los productores
impactados directamente, y cualesquiera productores intermedios que
caen sobre el camino entre los productores de interés y los
productores impactados directamente para el escenario 2 usando los
métodos correspondientes y las declaraciones de dependencias del
productor de los productores mencionados anteriormente.
En algunas realizaciones, la rutina de ejecución
va a través de la estructura de seguimiento de trayectorias de
impactados para invocar un nuevo comando de productores estresados
para cada uno de los productores impactados en la estructura de
seguimiento de trayectorias de impactados. Los productores
estresados generados se interconectan para formar un
sub-gráfico del gráfico de productores existente
para el escenario 1. La secuencia de invocación puede no importar
porque los nuevos productores estresados (es decir, los Productores
1, 2, 4, y 7 para el escenario 2) están interconectados entre sí
como se crearon, como se indica por [G] en la Figura 28C. En algunas
realizaciones, cuando no existe un productor de interés en el
escenario de referencia, tal productor de interés no se seguiría en
la estructura de seguimiento de trayectorias de impactados. Sin
embargo, la rutina de ejecución invoca un nuevo comando de
productores estresados para tal productor de interés para crear el
gráfico de productores para el escenario 2.
Para optimizar el gráfico de productores para el
escenario 2, los productores que no están impactados, directamente
o indirectamente, por el Productor 7 pero son dependientes del
productor de interés, es decir, el Productor 1, pueden no estar
duplicados o estresados en el escenario 2. En cambio, estos
productores están enlazados al gráfico de productores del escenario
2 desde el escenario 1. En el ejemplo actual, estos productores
incluyen los Productores 3, 5 y 6, donde el Productor 1 depende
directamente del Productor 3 y el Productor 3 depende directamente
de los Productores 5 y 6. Como se ilustra en la Figura 28C, se crea
un enlace para enlazar el Productor 3 del escenario 1 al Productor
1 del escenario 2 en [F]. Como tal, el subconjunto del gráfico de
productores del escenario 1 que tiene el Productor 3 y los
productores hijos del Productor 3 (es decir, el Productor 5 y el
Productor 6) están enlazados al gráfico de productores del escenario
2. En otras palabras, se ha creado un sub-gráfico
dentro del gráfico de productores para el escenario 1 para el
escenario 2. Obsérvese que los impactos sobre el productor 7 para
el escenario 2 no afectan al Productor 3 porque el Productor 3 no
depende, directamente ni indirectamente del Productor 7.
Para optimizar adicionalmente el proceso de
creación del gráfico de productores del escenario 2, la rutina de
ejecución puede no duplicar ningún productor estresado que sean
directamente o indirectamente dependientes del productor de
interés, independientemente de si tales productores están impactados
o no en el escenario 2. Un ejemplo de tal optimización se ilustra
en la Figura 28D. Similar a la Figura 28C, se crea un gráfico de
productores para el escenario 1 y se identifica el Productor 1 como
un productor de interés en el escenario 2, donde el escenario 2 se
define como se ha descrito anteriormente. En algunas realizaciones,
se invoca un nuevo comando de productor estresado sobre el
productor de interés, es decir, el Productor 1, como se indica por
[A] en la Figura 28D. El nuevo comando de productores estresados
puede invocarse por el usuario a través del código del cliente o
dispararse por un productor de generación de productores estresados,
tal como el Productor 8 en la Figura 28B.
Dependiendo del orden de la declaración de
dependencias inicial, la rutina de ejecución puede invocar el nuevo
comando de productores estresados sobre los productores de los que
depende el Productor 1 en ese orden. Por ejemplo, si el Productor 3
viene antes que el Productor 4 en la declaración de dependencias
inicial, se invoca el nuevo comando de productores estresados sobre
el Productor 3 en primer lugar, y a continuación sobre el Productor
4, y viceversa. Cuando se invoca un nuevo comando de productores
estresados sobre el Productor 3, se crea un enlace en [F] para
enlazar el Productor 1 en el escenario 2 con el Productor 3 en el
escenario 1 ya que el Productor 3 no está impactado en el escenario
2. Cuando se invoca un nuevo comando de productores estresados
sobre el Productor 4, el Productor estresado 4 se clona en el
escenario 2 como se indica por [G] en la Figura 28D. Para clonar el
Productor estresado 4 en el escenario 2, la rutina de ejecución
puede usar información del Productor 4 en el gráfico de productores
del escenario 1 para hacer una copia del Productor 4 en el
sub-gráfico para el escenario 2. Como alternativa,
la rutina de ejecución puede crear un nuevo Productor 4
representando el Productor 4 en base a la declaración de
dependencias del productor y el código fuente orientado a objetos
del Productor 4. Después de que el Productor estresado 4 se añade al
gráfico de productores, se invoca un nuevo comando de productores
estresados sobre el Productor 7 para estresar el Productor 7 sobre
el escenario 2 como se indica por [H] en la Figura 28D. Como el
Productor 4, el Productor 7 puede estresarse por representación o
clonación. Obsérvese que el sub-gráfico para el
escenario 2 se construye ahora completamente como se muestra en la
Figura 28D sin estresar el Productor 2 en el escenario 2 porque el
productor de interés en el escenario 2, a saber el Productor 1, no
depende, ni directamente ni indirectamente del Productor 2, incluso
aunque el Productor 2 esté impactado indirectamente por el Productor
7. Como resultado, el proceso de creación del
sub-gráfico para el escenario 2 no está optimizado
adicionalmente.
La Figura 29 es un diagrama de flujo de un flujo
lógico de ejecución de la rutina de ejecución del cliente y su
asociación con la rutina de ejecución con soporte de programación
orientado a gráficos de productores de acuerdo con una realización
de la invención. En la Figura 29, la línea discontinua de división
600 separa el flujo lógico de ejecución de una rutina de ejecución
del cliente 610 de la rutina de ejecución con el soporte de
programación orientado a gráficos de productores 640. Los detalles
de los bloques 615, 620, 625, 630, 645, 650, 655 y 660 se han
descrito anteriormente con referencia a la Figura 6. Para soportar
escenarios, la rutina de ejecución del cliente 610 en primer lugar
comprueba si hay cualquier nuevo escenario en el bloque 616. Si hay
un nuevo escenario, la rutina de ejecución del cliente 610 determina
la información del nuevo escenario en el bloque 617. Además, puede
invocarse un comando de representación de escenario o registrarse en
el registro de comandos 665 para representar el nuevo escenario. En
respuesta al nuevo comando de escenarios, la rutina de ejecución
640 representa un nuevo escenario en el bloque 648. A continuación
la rutina de ejecución del cliente 610 transita dentro del bloque
615 para continuar el flujo de ejecución. De lo contrario, la rutina
de ejecución del cliente 610 salta al bloque 617 y transita al
bloque 615 para continuar el flujo de ejecución. En el bloque 615,
la rutina de ejecución del cliente 610 determina un conjunto de uno
o más productores estresados cuya salida es de interés. A
continuación la rutina de ejecución del cliente 610 transita al
bloque 620 para continuar el flujo de ejecución como se ha descrito
anteriormente con referencia a la Figura 6.
Para evaluar los impactos sobre uno o más
productores de interés para el escenario, se invoca el módulo de
ejecución del gráfico de productores en el bloque 630. A
continuación el módulo de ejecución del gráfico de productores
puede pasearse a través del gráfico o sub-gráfico de
productores para ejecutar cualesquiera productores que se tengan
que ejecutar en base al seguimiento del bloque 660. En el bloque
630, se invoca el módulo de ejecución del gráfico de productores y
opcionalmente el control vuelve al bloque 615, el bloque 625, y/o el
bloque 616.
La Figura 30 es un diagrama de bloques de una
implementación alternativa de acuerdo con una realización de la
invención que soporta el escenario. En la Figura 30, la línea de
división discontinua 1000 separa un cliente de la rutina de
ejecución 1002 de la rutina de ejecución con soporte de programación
orientado a gráficos de productores 1004. Detalles de los diversos
componentes de la rutina de ejecución del cliente 1002 y la rutina
de ejecución 1004 se han descrito anteriormente con referencia a la
Figura 10. De este modo, la siguiente descripción se enfoca sobre
las componentes relacionadas con el escenario. En algunas
realizaciones, la rutina de ejecución 1004 incluye además un nuevo
módulo de escenario 1096 y una estructura de seguimiento de
escenarios 1050 para soportar el escenario.
Como se ha tratado anteriormente con referencia
a la Figura 10, un nuevo módulo de clases 1095 puede representar
una clase en base a las definiciones de clases 1010. La información
de la clase representada puede almacenarse en la estructura de
seguimiento de clases 1092. Una realización de ejemplo de la
estructura de seguimiento de clases 1092 se muestra en la Figura
31A. Respecto a la Figura 31A, una clave de clase 1110 y una
referencia de clase 1115 (tal como un puntero de clases) se
almacenan en la estructura de seguimiento de clases para cada una
de las clases representadas. Refiriéndonos de nuevo a la Figura 30,
las definiciones de clase 1010 del lado de la rutina de ejecución
del cliente 1002 incluyen el código del productor de generación de
productores estresados 1018 de acuerdo con una realización de la
invención. Como se ha tratado anteriormente con referencia a la
Figura 28B, un productor de generación de productores estresados es
un productor que saca una colección de productores estresados, cada
uno de los cuales incluye una clave del productor y una clave del
escenario. Algunos seudo códigos de ejemplo del código del
productor de generación de productores estresados 1018 también se
muestran en la Figura 28B. Para soportar el escenario, la rutina de
ejecución del cliente 1002 proporciona además comandos de
representación de escenarios 1019 con claves de escenarios. Las
claves de escenarios pueden usarse en la representación de las
nuevas instancias para asociar las instancias con los escenarios
correspondientes. La información sobre las instancias representadas
puede almacenarse en la estructura de seguimiento de instancias
1065. Una realización de ejemplo de la estructura de seguimiento de
instancias 1065 se muestra en la Figura 31B. Para cada una de las
instancias representadas, se almacenan una clave de escenario 1123,
una referencia de instancia 1120, y una referencia de la instancia
estresada 1125 en la estructura de seguimiento de instancias de
ejemplo en la Figura 31B.
Refiriéndonos de nuevo a la Figura 30, la rutina
de ejecución del cliente 1002 puede invocar un comando de
representación de escenarios 1019 con una clave de escenario única
para crear un nuevo escenario. En respuesta al comando de
representación del escenario 1019, el nuevo módulo de escenarios
1096 puede almacenar información del nuevo escenario (tal como la
información de escenario 328 en la Figura 27A) en la estructura de
seguimiento de escenarios 1050. Una realización de ejemplo de la
estructura de seguimiento de escenarios 1050 se ilustra en la
Figura 31D. En algunas realizaciones las estructura de seguimiento
de escenarios 1050 incluye una tabla que tiene una columna para la
clave de escenario, una columna para la referencia de escenario, y
una columna para la estructura de seguimiento de trayectorias de
impactos como se ilustra en la Figura 31D. La clave de escenario
3110 puede ser una clave única asignada al escenario para
identificar el escenario. La referencia de escenario 3112 puede
referirse a un objeto de escenario. Una estructura de seguimiento de
trayectorias de impactos 3113 mantiene el seguimiento de los
productores impactados en el escenario correspondiente.
La Figura 31E ilustra una realización de una
estructura de seguimiento de objetos de escenario. La estructura de
seguimiento de objetos de escenario puede incluir una tabla que
tiene una fila para cada uno de los escenarios. Para cada uno de
los escenarios, se almacenan una clave del escenario de referencia
3120, una clave del escenario objetivo 3122, y una referencia a una
lista de impactos 3124 en la estructura de seguimiento de objetos de
escenario. La clave del escenario objetivo 3122, identifica el
escenario a construir. De este modo, la clave del escenario
objetivo 3122 es la misma que la clave del escenario correspondiente
3110 en la estructura de seguimiento de escenarios en la Figura
31D. La clave del escenario de referencia 3120 identifica un
escenario basado en el cual puede construirse el escenario
objetivo. Si no hay ningún escenario de referencia, entones la
clave de escenario de referencia 3120 es nula. La referencia para
una lista de impactos del escenario 3124 se refiere a una lista de
impactos del escenario, tal como la lista de impactos de ejemplo,
mostrada en la Figura 31F.
En la Figura 31F, la lisa de impactos de ejemplo
de un escenario incluye una columna para cada uno de los
siguientes: una clave del productor impactado directamente 3130, un
indicador relativo o absoluto 3124, una instancia de salida 3132,
un parámetro de transformación 3136, y un nombre del método de
transformación y clase de método 3138. Cada uno de los productores
impactados directamente en el escenario correspondiente ocupa una
fila de la lista de impactos. La clave del productor impactado
directamente 3130 identifica un productor impactado directamente en
el escenario.
En algunas realizaciones, puede asignarse el
valor de salida como un valor absoluto o un valor relativo. El
indicador de valor relativo o absoluto 3134 indica si al valor de
salida se asigna un valor absoluto o un valor relativo. Si el
indicador 3134 indica que es un valor absoluto, el valor de salida
del productor impactado directamente se designa para que sea la
instancia de salida 3132 independientemente de las entradas al
productor impactado directamente. Por el contrario, se aplica el
parámetro de transformación 3136 a la salida actual del productor
impactado directamente (es decir, la salida del productor impactado
directamente para el escenario de referencia) para transformar la
salida actual del productor impactado directamente usando el método
de transformación con el nombre del método de transformación y la
clase del método 3138. A continuación la salida del productor
impactado directamente para el escenario objetivo se anula con la
salida actual transformada. Obsérvese que la salida del productor
impactado directamente puede ser un valor (tal como un valor
numérico) o una instancia. Por ejemplo, la salida actual de un
productor impactado directamente es un valor numérico, el parámetro
de transformación 3136 es un valor de factor, y el método de
transformación es una multiplicación, entones la salida del
productor impactado directamente para el escenario objetivo es un
valor igual al producto del valor del factor y el valor actual de
la salida del productor impactado directamente. En otro ejemplo, el
parámetro de transformación 3136 es un valor de difusión y el método
de transformación es una suma, entonces la salida del productor
impactado directamente para el escenario objetivo puede ser igual a
la suma del valor difundido y el valor actual de la salida del
productor impactado directamente. Debería apreciarse que el valor
de salida del productor impactado directamente puede generarse
usando otra fórmula en diferentes realizaciones como una función del
valor de salida actual.
Refiriéndonos de nuevo a la Figura 30, el módulo
de generación automatizada de gráficos de productores estresados
3040 accede a la estructura de seguimiento de escenarios 1050. En
respuesta a los comandos de representación de productores
estresados con las claves del productor y las claves de escenario
1025, el módulo de generación automatizada de gráficos de
productores estresados 3040 puede representar un productor estresado
en base a la información de escenario del escenario correspondiente
desde la estructura de seguimiento de escenarios 1050, la
estructura de seguimiento de clases 1092, la estructura de
seguimiento de métodos 1058, la estructura de seguimiento de
instancias 1065, y las instancias 1052. Como alternativa, el código
del productor de generación de productores estresados 1018 dentro
de las definiciones de clases 1010 se procesa por la rutina de
ejecución 1004 para generar una clase de productores de generación
de productores estresados 3054 y un método para generar productores
estresados 3056. La clase y el método generados se introducen en el
módulo de generación automatizada de gráficos de productores
estresados 3040, que representa un productor estresado
consecuentemente. El módulo de generación automatizada de gráficos
de productores estresados 3040 interconecta los productores
estresados representados para generar un gráfico o
sub-gráfico de productores para el escenario
correspondiente. Detalles de algunas realizaciones del flujo de
representación del nuevo productor estresado que soporta el
escenario se tratan más adelante con referencia a las Figuras
34A-34G.
De acuerdo con una realización de la invención,
el gráfico de productores se almacena en la estructura del gráfico
de productores 1060. En la Figura 31C se muestra una estructura de
un gráfico de productores de ejemplo. La estructura del gráfico de
productores es sustancialmente la misma que la mostrada en la Figura
11C. Como cada uno de los escenarios se sigue individualmente en el
correspondiente gráfico o sub-gráfico de
productores, el módulo de ejecución de gráficos de productores
estresados 3070 puede pasearse a través del correspondiente gráfico
o sub-gráfico de productores para el escenario, para
ejecutar al menos algunos de los productores estresados para el
escenario, para evaluar los impactos sobre uno o más productores
estresados de interés para el escenario sin sobrescribir o cambiar
las salidas de los productores para otros escenarios. Detalles de
algunas realizaciones del flujo de ejecución de los gráficos de
productores que soportan escenarios se tratarán más adelante con
referencia a las figura 35A y 35B.
Obsérvese que los módulos y estructuras para
soportar el escenario en la rutina de ejecución del cliente 1002 y
la rutina de ejecución 1004 descritas anteriormente se añaden dentro
de algunas realizaciones que soportan dependencias del productor
contingentes y de suscripción de tipo dinámico, tal como la
ilustrada en la Figura 12 anterior.
La Figura 32 es un diagrama de flujo que ilustra
un nuevo flujo de representación de escenarios de acuerdo con una
realización de la invención. En el bloque 3210, una rutina de
ejecución recibe un nuevo comando de representación de escenarios.
La rutina de ejecución comprueba a continuación si el escenario
identificado por el nuevo comando de representación de escenarios
ya existe en el bloque 3220. Si el escenario ya existe, entonces el
nuevo flujo de representación de escenarios se hace en el bloque
3290. De lo contrario, la rutina de ejecución añade información de
escenario, tal como, por ejemplo, una clave del escenario objetivo,
una clave del escenario de referencia, y una referencia a una lista
de impactos del escenario para una estructura de seguimiento de
escenarios en el bloque 3230. A continua-
ción la rutina de ejecución transita dentro del bloque 3290 y se efectúa el nuevo flujo de representación de escenarios.
ción la rutina de ejecución transita dentro del bloque 3290 y se efectúa el nuevo flujo de representación de escenarios.
La Figura 33 es un diagrama de flujos que
ilustra un nuevo flujo de representación de instancias que soporta
escenarios de acuerdo con una realización de la invención. Obsérvese
que la Figura 33 es sustancialmente similar a la Figura 15 y se han
descrito detalles del flujo con referencia a la Figura 15 anterior.
Para soportar escenarios, la rutina de ejecución representa una
instancia de una clase y almacena la instancia con su clave de
instancia, la referencia a la instancia estresada, y las claves de
escenario en el bloque 3360 en la Figura 33. Como se ha tratado
anteriormente, hay una clave de escenario única para cada uno de los
escenarios. De este modo, puede haber múltiples claves de escenario
si la instancia está asociada con múltiples escenarios. En una
realización, la clave de instancia y las claves de escenario se
almacenan en una estructura de seguimiento de instancias como se
ilustra en la Figura 31B. Refiriéndonos a la Figura 31B, la
estructura de seguimiento de instancias incluye una columna para
cada una de la claves de escenario 1123, la clave de instancia 1120,
y la referencia de la instancia estresada 1125.
Las Figuras 34A-34G ilustran
diagramas de flujo de la representación de un nuevo productor
estresado en un escenario objetivo, de acuerdo con una realización
de la invención. Las Figuras 34A-34C ilustran el
flujo global de la representación de un nuevo productor estresado
mientras que las Figuras 34D-34G ilustran un flujo
expandido de ciertas operaciones del flujo global.
Refiriéndonos a la Figura 34A, una rutina de
ejecución recibe un nuevo comando de productores estresados en el
bloque 1600. El nuevo comando de productores estresados especifica
una clave de productor y una clave de escenario objetivo. Un
productor con la clave de productor y la clave del escenario
objetivo es el productor estresado a generar por el nuevo comando
de productores estresados. En una realización de la invención, puede
ejecutarse un nuevo comando del productor estresado en respuesta a
una diversidad de situaciones. La Tabla 3 siguiente identifica las
diversas situaciones y parámetros pasados de acuerdo con una
realización de la invención.
En respuesta al nuevo comando del productor
estresado, la rutina de ejecución comprueba si el productor
estresado (es decir el productor con la clave del productor y la
clave del escenario objetivo) ya existe en el bloque 1605. Si el
productor estresado ya existe, entonces la rutina de ejecución
enlaza el productor dentro del gráfico de productores si el
productor se llama debido a la dependencia en el bloque 1670. De lo
contrario, si no existe el productor estresado, entonces la rutina
de ejecución identifica ambos productores impactados directamente e
indirectamente si el productor es el productor de interés en el
bloque 1601. Detalles del bloque 1601 se tratan más adelante con
referencia a la Figura 34D. A continuación, la rutina de ejecución
transita dentro del bloque 1602 para manejar escenarios, durante
los cuales, la rutina de ejecución fija el valor de la creación del
productor. En algunas realizaciones, la creación del productor tiene
tres valores posibles, a saber, sin creación, nueva creación, y
clonación. Detalles del bloque 1602 se tratan más adelante con
referencia a la Figura 34E. A continuación, la rutina de ejecución
comprueba el valor de la creación del productor en el bloque 1603.
Si la creación del productor es crear nuevo, la rutina de ejecución
transita al punto de entrada A en la Figura 34B. Si la creación del
productor es clonar, la rutina de ejecución transita al punto de
entrada B en la Figura 34B. Si la creación del productor es ninguna
creación, la rutina de ejecución transita al bloque 1670.
Después del bloque 1670, la rutina de ejecución
comprueba si el productor está anulado, si tiene una suscripción
adherente, o si está declarado hacia arriba en el bloque 1675. Si es
así, la rutina de ejecución marca el productor como no ejecutado en
el bloque 1680 y registra el productor en el registro de comienzo de
ejecución en el bloque 1665. A continuación, la rutina de ejecución
devuelve el estado de ejecución del productor en el bloque 1660. De
lo contrario, si el productor no esta anulado, la rutina de
ejecución transita dentro del bloque 1660 para devolver el estado de
ejecución del productor.
Refiriéndonos a la Figura 34B, la rutina de
ejecución va al punto de entrada A, si la creación del productor es
crear nuevo. Desde el punto de entrada A, la rutina de ejecución
transita dentro del bloque 1610 para llamar al nuevo módulo de
instancias. A continuación la rutina de ejecución accede a la
definición de clase de una instancia del productor en el bloque
1615. A continuación, la rutina de ejecución accede al método y el
establecimiento de la declaración de dependencias del productor,
del productor en la definición de clase en el bloque 1620. A
continuación la rutina de ejecución añade el productor al gráfico de
productores del escenario objetivo en el bloque 1625. Después la
rutina de ejecución transita dentro del bloque 1604.
Refiriéndonos de nuevo al bloque 1603 en la
Figura 34A, si la creación del productor es clonar, la rutina de
ejecución transita al punto de entrada B en la Figura 34B. Desde el
punto de entrada B, la rutina de ejecución transita dentro del
bloque 1626 para llamar a un nuevo modelo de instancias para
representar una instancia vacía. A continuación la rutina de
ejecución copia la información del productor con la clave del
productor y la clave del escenario de referencia para rellenar la
instancia vacía en el bloque 1627. A continuación, la rutina de
ejecución clona el productor con la instancia rellena en el bloque
1628. A continuación la rutina de ejecución añade el productor
clonado con la clave del escenario objetivo dentro del gráfico de
productores en el bloque 1629. Después la rutina de ejecución
transita dentro del bloque 1604.
En el bloque 1604, la rutina de ejecución
procesa el impacto si el productor está en la lista de impactos del
escenario. Más adelante se tratan detalles del bloque 1604 con
referencia a la Figura 34G. A continuación, la rutina de ejecución
procesa los criterios de filtrado de la suscripción en el bloque
1630 para cada una de las suscripciones registradas. Si se llama el
productor debido a la dependencia, la rutina de ejecución enlaza el
productor dentro del gráfico de productores en 1635. A continuación
la rutina de ejecución transita al punto de entrada C.
Refiriéndonos a la Figura 34C, la rutina de
ejecución transita al bloque 1640 desde el punto de entrada C para
marcar el productor como no ejecutado. En algunas realizaciones, la
rutina de ejecución puede recibir un comando de anular el productor
en el bloque 1690. En respuesta al comando de anular el productor,
la rutina de ejecución puede marcar el productor como no anulado en
el bloque 1695 y a continuación transita dentro del bloque 1640.
Desde el bloque 1640, la rutina de ejecución
transita dentro del bloque 1645 para comprobar si el productor
tiene cualesquiera dependencias y no está anulado. Si el productor
no tiene ninguna dependencia y no está anulado, entonces la rutina
de ejecución transita al punto de entrada D para volver al bloque
1665 en la Figura 34A. Por el contrario, la rutina de ejecución
transita dentro del bloque 1650. En el bloque 1650, para cada una
de las dependencias en la declaración de dependencias eso es lo que
se determina ahora, la rutina de ejecución determina el número de
productores e invoca un nuevo comando de productor estresado para
cada uno. Si todos los productores dependientes existen y se han
ejecutado, la rutina de ejecución añade el productor al registro de
comienzo de ejecución en el bloque 1655 y transita al punto de
entrada E para volver al bloque 1660 en la Figura 34A.
La Figura 34D ilustra un diagrama de flujo
expandido del bloque 1601 de acuerdo con una realización de la
invención. La rutina de ejecución en primer lugar localiza la
estructura de seguimiento de la trayectoria de impactos usando la
estructura de seguimiento de escenarios y la clave de escenario en
el bloque 3405. A continuación, la rutina de ejecución determina en
el bloque 3410 si la estructura de seguimiento de la trayectoria de
impactos en la estructura de seguimiento de escenarios está ya
representada. Si la estructura de seguimiento de trayectorias de
impactos está ya representada, entonces ambos productores impactados
directa e indirectamente ya se han identificado. De este modo, la
rutina de ejecución transita al bloque 3419 para terminar el flujo.
De lo contrario, la rutina de ejecución transita al bloque 3412. En
el bloque 3412 la estructura de seguimiento de trayectorias de
impactos se representa y se almacena en la estructura de seguimiento
de escenarios. A continuación la rutina de ejecución transita al
bloque 3413. Para cada uno de los productores impactados
directamente en la definición de escenario, la rutina de ejecución
busca un productor con la clave de productor correspondiente y la
clave del escenario de referencia en la definición de escenario. La
rutina de ejecución determina si tal productor existe en el bloque
3415. Si tal productor existe, la rutina de ejecución añade el
productor a la estructura de seguimiento de trayectorias de
impactos junto con todos sus ancestros en el bloque 3417 y a
continuación transita al bloque 3418. De lo contrario, la rutina de
ejecución salta el bloque 3417 y transita al bloque 3418. En el
bloque 3418, la rutina de ejecución comprueba si hay algún productor
más impactado directamente en la definición de escenario. Si lo
hay, entonces la rutina de ejecución vuelve al bloque 3413 para
repetir las operaciones descritas anteriormente. De lo contrario la
rutina de ejecución transita al bloque 3419 para terminar el
flujo.
La Figura 34E ilustra un diagrama de flujo
ampliado del bloque 1602 de acuerdo con una realización de la
invención. La rutina de ejecución comprueba si la estructura de
seguimiento de trayectorias de impactos está vacía en el bloque
3420. Si la estructura de seguimiento de trayectorias de impactos
está vacía, la rutina de ejecución transita al bloque 3429. De lo
contrario, la rutina de ejecución comprueba si el productor con la
clave del escenario de referencia está en la estructura de
seguimiento de trayectorias de impactos en el bloque 3422. Si lo
está, entones la rutina de ejecución fija la creación del productor
a "clonar" en el bloque 3424. De lo contrario, la rutina de
ejecución comprueba si el productor existe en el gráfico de
productores con el escenario de referencia en el bloque 3426. Si
existe, entonces la rutina de ejecución fija la creación del
productor a "no creación" en el bloque 3428. Esta es una
optimización que da como resultado la duplicación de sólo una
porción del gráfico de productores para el escenario objetivo. Los
productores que no se ha creado o clonado pueden enlazarse al
sub-gráfico para el escenario objetivo desde el
escenario de referencia. De lo contrario, la rutina de ejecución
transita al bloque 3429. En el bloque 3429, la rutina de ejecución
fija la creación del productor a "crear nuevo".
La figura 34F ilustra una vista ampliada del
bloque 1605 de la Figura 34A de acuerdo con una realización de la
invención. En el bloque 1605, la rutina de ejecución comprueba si el
productor estresado ya existe. En algunas realizaciones, la rutina
de ejecución comprueba si la combinación de la clave de clase, la
clave de instancia, la clave de método y la clave de escenario ya
existe en la tabla de productores. Si la combinación existe, el
productor estresado existe. De lo contrario, el productor estresado
no existe.
La Figura 34B ilustra un diagrama de flujo
ampliado del bloque 1604 de acuerdo con una realización de la
invención. En algunas realizaciones, existen interfaces dedicadas
correspondientes para obtener y fijar las salidas de los
productores. En el bloque 3430, la rutina de ejecución comprueba si
el impacto sobre el productor es relativo. Si no lo es, entonces el
impacto sobre el productor es absoluto. De este modo la rutina de
ejecución asigna la instancia de salida desde la lista de impactos
del escenario como la nueva salida del productor en el escenario
objetivo en el bloque 3436. A continuación la rutina de ejecución
transita al bloque 3440. De lo contrario, el impacto sobre el
productor es relativo y la rutina de ejecución obtiene la salida
actual del productor en el bloque 3432. A continuación la rutina de
ejecución genera la nueva salida del productor usando la salida
actual y el método de transformación correspondiente y el parámetro
de transformación correspondiente en la lista de impactos del
escenario en el bloque 3434. A continuación la rutina de ejecución
transita al bloque 3440.
En algunas realizaciones, la rutina de ejecución
puede generar la nueva salida añadiendo el valor difundido a la
salida actual. Como alternativa, la rutina de ejecución puede
generar la nueva salida multiplicando la salida actual por el valor
del factor.
En el bloque 3440, la rutina de ejecución fija
la salida del productor al nuevo valor de salida generado en el
almacenamiento temporal de la salida del productor y en la instancia
si la salida es un campo. La rutina de ejecución marca a
continuación el productor como anulado en el bloque 3442 y transita
al bloque 1630 en la Figura 34B.
Las Figuras 35A-35B son
diagramas de flujo que ilustran un flujo de ejecución del gráfico de
productores estresados de acuerdo con una realización de la
invención. En el bloque 2200, la rutina de ejecución selecciona un
conjunto de productores candidatos a ejecutar en base a los
productores sobe el registro de comienzo de ejecución como el
conjunto actual de productores candidatos. A continuación la rutina
de ejecución selecciona un subconjunto de productores del conjunto
actual de productores candidatos que están listos para ejecutarse
como un conjunto actual de productores listos en el bloque 2205.
Para cada uno de los productores en el conjunto actual de
productores listos, la rutina de ejecución comprueba el tipo de
productores en el bloque 2210. En una realización, hay tres tipos
de productores, a saber, productores normalizados, productores de
generación de productores estresados, y productores de declaración
de dependencias.
Si el productor es un productor normalizado, la
rutina de ejecución transita al bloque 2215 para ejecutar el
productor. A continuación la rutina de ejecución marca cualesquiera
padres que tienen una dependencia de suscripción absorbente sobre
el productor ejecutado como incompleto en el bloque 2220 y transita
al punto de entrada A.
Si el productor es un productor de generación de
productores estresados, la rutina de ejecución transita al bloque
3710 para ejecutar el productor. A continuación la rutina de
ejecución marca cualesquiera padres que tienen una dependencia de
suscripción absorbente sobre el productor ejecutado como incompletos
en el bloque 3720. A continuación, la rutina de ejecución invoca
nuevos comandos de productores estresados para los productores
descubiertos, registra y procesa las suscripciones en el bloque
3730. A continuación la rutina de ejecución los añade al conjunto
de productores candidatos en base a los productores nuevamente
añadidos al registro de comienzo de ejecución en el bloque 3740. La
rutina de ejecución transita a continuación al punto de entrada
A.
Si el productor es un productor de declaración
de dependencias, la rutina de ejecución prepara el productor de
determinación de dependencias en el bloque 2225. A continuación, la
rutina de ejecución ejecuta el productor de determinación de
dependencias para resolver cualesquiera dependencias sin resolver
listas para resolverse en el bloque 2230. A continuación la rutina
de ejecución invoca nuevos comandos de productores estresados para
los productores descubiertos, registra y procesa las suscripciones
en el bloque 2235. La rutina de ejecución añade productores
nuevamente añadidos al registro de comienzo de ejecución al conjunto
de productores candidatos en el bloque 2240. La rutina de ejecución
transita a continuación al punto de entrada A.
Refiriéndonos a la Figura 35B, la rutina de
ejecución transita desde el punto de entrada A al bloque 2245. En
el bloque 2245, las rutinas de ejecución marcan los productores como
ejecutados y actualizan el almacenamiento temporal de salida del
productor y el almacenamiento temporal de instancias si es
necesario. Además, la rutina de ejecución añade cualesquiera
productores padre al conjunto de productores candidatos a ejecutar y
los marca como no ejecutados. La rutina de ejecución elimina además
los productores ejecutados de los conjuntos actuales de productores
candidatos y listos. Desde el bloque 2245, la rutina de ejecución
transita dentro del bloque 2250 para comprobar si el conjunto de
productores candidatos está vacío. Si no está vacío, la rutina de
ejecución transita al bloque 2205 a través del punto de entrada B
para repetir el flujo descrito anteriormente. Si el conjunto de
productores candidatos está vacío, la rutina de ejecución transita
al bloque 2255 para comprobar si todas las suscripciones se han
completado. Si no se han completado, la rutina de ejecución procesa
los productores de suscripción absorbentes incompletos en el bloque
2260 y a continuación vuelve al bloque 2205 a través del punto de
entrada B. De lo contrario, esto es, s todas las suscripciones se
han completado, la rutina de ejecución transita al bloque 2248. En
el bloque 2248, se rastrea la estructura de seguimiento de
escenarios y se liberan todas las estructuras de seguimiento de
trayectorias de instancias. A continuación la rutina de ejecución
transita al bloque 2265 para terminar el flujo.
Como se ha indicado anteriormente, el lenguaje
del procedimiento escrito adecuadamente, el lenguaje orientado a
objetos no reflexivo, y el código de lenguaje basado en objetos no
reflexivo pueden transformarse en código de lenguaje orientado a
objetos reflexivo. A modo de ejemplo, una clase puede emularse a
través de una estructura de datos y un conjunto de funciones
estáticas que tienen como primer parámetro un puntero a una
instancia de la estructura de datos. De entre estas funciones están
el constructor y el destructor. Los constructores se invocan por la
rutina de ejecución después de la asignación de un puntero a la
estructura de datos y proporcionan las faltas para los elementos en
la estructura de datos, y los destructores se invocan por la rutina
de ejecución antes de la liberación de un puntero a la estructura
de datos. Cada clase tiene su descripción a través de un fichero
que incluye: 1) la estructura de datos; 2) otra estructura que
describe la clase, manteniendo el tamaño de la estructura y un
conjunto de punteros a funciones; 3) una lista de funciones
estáticas, con sus códigos (para lenguajes reflexivos orientados a
objetos y lenguajes no reflexivos basados en objetos, el código de
funciones estáticas se generaría automáticamente rastreando métodos
de la clase real, y creando para cada uno de los métodos una
función estática que realiza la invocación efectiva del método
relacionado); y 4) anotaciones en la parte superior de cada una de
las funciones (comentarios que mantienen las declaraciones de
dependencias del productor), junto con sus tipos (constructor,
destructor, propiedad, etc.). Además de esta definición de clase en
el procedimiento, no reflexivo orientado a objetos, o un lenguaje no
reflexivo basado en objetos, también se implementa una invocación
dinámica. Específicamente, un compilador genera el siguiente código
de inicialización para cada clase, código que se llama una vez (por
el nuevo módulo de clases) para: 1) representar la estructura que
describe la clase, rellenar los punteros a las funciones con las
funciones estáticas efectivas; 2) registrar la instancia de esta
estructura con un mapa de clases (la estructura de seguimiento de
clases) con una clave correspondiente al nombre de la clase; y 3)
registrar todos los punteros a funciones en un mapa de funciones
(la estructura de seguimiento de métodos) con una clave
correspondiente al nombre de la función (junto con las
DependenciasArgumento, DependenciasSecuenciación, DependenciasCampo,
DependenciasHaciaArriba, DependenciasDébilmenteRestringidas, clave
de la clase de salida y anotaciones adicionales). El mapeo permite
implementaciones en la rutina de ejecución de funciones de
invocación genéricas capaces de: 1) representar una instancia de
una clase por nombre (por el nuevo módulo de instancias)
(específicamente la rutina de ejecución: a) asignar memoria de
acuerdo con el tamaño de la estructura de datos, y añade una
cabecera al puntero para almacenar un puntero a la estructura que
describe la clase, e implementa por lo tanto punteros inteligentes
(por ejemplo, punteros capaces de preguntar sus tipos); y b) invocar
las funciones del constructor adecuadas después de la recuperación
del puntero relevante para la función estática desde el mapa); y 2)
invocar un método por el nombre suponiendo que todos los parámetros
se pasan adecuadamente después de la recuperación del puntero
relevante para la función estática desde el mapa. Pasar los
parámetros de forma adecuada a las funciones identificadas por los
punteros a funciones se haría a través del lenguaje de ensamblaje,
metiendo y sacando elementos en/desde el almacenamiento para la
entrada y salida de parámetros. El método descrito anteriormente
asume la existencia de la notación de estructuras de datos y la
existencia de la notación de punteros a funciones en el
procedimiento, no reflexivo orientado a objetos, o el lenguaje no
reflexivo basado en objetos.
\vskip1.000000\baselineskip
En una realización de la invención, el código
cliente toma la siguiente sintaxis (mostrada en forma de
cabecera):
ClaveProductor
- Nuevo (String ClaveClase, ClaveInstancia ClaveInstancia, String ClaveMétodo)
CódigoEjecución
- Nuevo
\hskip1.5cm
0
- AñadirProductoresDeInterés (ClaveProductor ClaveProductorDeInterés);
- FijarSalidaProductor (ClaveProductor ClaveAnulaciónProductor, Objeto InstanciaSalidaProductor);
- Ejecutar
\hskip1.3cm
0;
\vskip1.000000\baselineskip
ClaveProductor y CódigoEjecución son clases,
mientras que Nuevo, AñadirProductorDeInterés, FijarSalidaProductor,
y Ejecutar son métodos. AñadirProductorDeInterés causa la invocación
del nuevo comando del productor con los valores apropiados para el
productor de la situación de interés en la Tabla 2.
InstanciaSalidaProductor es una instancia de la clase de salida del
productor anulado. De esta forma se representa a través del
constructor de clase de salida del productor correspondiente.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
1. Sintaxis del Establecimiento de la
Declaración de Dependencias
DependenciaArgumento =
"DependenciaArgumento1; DependenciaArgumento2;
...";
DependenciaCampo =
"DependenciaCampo1; DependenciaCampo2;
...";
DependenciaSecuenciación =
"DependenciaSecuenciación1;
DependenciaSecuenciación2; ...";
DependenciaHaciaArriba =
"DependenciaHaciaArriba1;
DependenciaHaciaArriba2; ...";
\newpage
\global\parskip0.950000\baselineskip
DependenciaDébilmenteRestringida =
"DependenciaDébilmenteRestringida1;
DependenciaDébilmenteRestringida2; ...";
DependenciaNoRestringida =
"DependenciaNoRestringida1,
DependenciaNoRestringida2 ..."
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
2. Sintaxis de Dependencia
a. Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#C: "ClaveClase" :: #I:
"ClaveInstancia" :: #M: "ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
b. Sintaxis DependenciaArgumentoX:
IDArgumento :: #C; "ClaveClase" :: #I:
"ClaveInstancia" :: #M: "ClaveMétodo"
\vskip1.000000\baselineskip
En una realización de la invención, la
IDArgumento se omite en la sintaxis, y el orden en el cual se han
declarado las DependenciasArgumento representa la IDArgumento. La
IDArgumento se añade entonces para mejorar la legibilidad.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
3. Atajo y No Atajo
La sintaxis es la misma que para un
no-atajo pero el uso de #S:: delante de la clave del
productor identifica un atajo.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
a. Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#s :: #C: "ClaveClase" ::#I;
"ClaveInstancia" :: #M: "ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
b. Sintaxis DependenciaArgumentoX:
IDArgumento :: #S ::#C: "ClaveClase" :: #I:
"ClaveInstancia" : ; : #M: "ClaveMétodo"
\vskip1.000000\baselineskip
En este caso, la clave del productor indicada
por la dependencia no es un productor de determinación de
dependencia. Otras implementaciones de sintaxis pueden asumir que el
atajo es la dependencia por defecto para un cierto tipo de
dependencia (tal como un campo); y omitir #S:: En ese caso puede
usarse #DDP para indicar la presencia de un DDP.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
4. Contingente y no contingente
Como se ha descrito anteriormente, puede
colocarse una <P> antes de un elemento contingente.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
a. Ejemplo de clase y método
contingentes
1) Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#C:<P>"ClaveMétodoDeterminaciónClase"
:: #I : "ClaveInstancia" ::#M:
<P>
"ClaveMétodoDeterminaciónMétodo"
\global\parskip1.000000\baselineskip
2) Sintaxis DependenciaArgumentoX:
IDArgumento :: #C: <P>
"ClaveMétodoDeterminaciónClase" :: #I: "ClaveInstancia" ::
#M: <P> "ClaveMétodoDeterminaciónMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
b. Ejemplo de método contingente
1) Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#C: "ClaveClase" :: #I:
"ClaveInstancia" :: #M:
<P>
"ClaveMétodoDeterminaciónMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
2) Sintaxis DependenciaArgumentoX:
IDArgumento :: #C: "ClaveClase" :: #I:
"ClaveInstancia" :: #M:
<P>
"ClaveMétodoDeterminaciónMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
c. Ejemplo de instancia contingente
1) Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#C: "ClaveClase" :: #I: <P>
"ClaveMétodoDeterminaciónInstancia":: #M:
"ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
2) Sintaxis DependenciaArgumentoX:
IDArgumento :: #C: "ClaveClase" :: #I:
<P>
"ClaveMétodoDeterminaciónInstancia":: #M:
"ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
5. Técnica Taquigrafíca
Elementos tales como clase, instancia, o método
que se consideran que son idénticos a los elementos del productor
padre se omiten. Este es típicamente el caso para campos de atajo.
Los ejemplos datos más adelante en este documento combinan la
técnica taquigráfica con una declaración de atajo (el atajo se
indica por #S::)
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
a. Ejemplo donde se omiten la clase y la
instancia
1) Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#S :: #M: "ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
2) Sintaxis DependenciaArgumentoX:
IDArgumento :: #S :: #M "ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
b. Ejemplos donde se omite la clase
1) Sintaxis DependenciaCampoX,
DependenciaSecuenciaciónX, DependenciaHaciaArribaX,
DependenciaDébilmenteRestringidaX,
DependenciaNoRestringidaX;
#S :: #I: "ClaveInstancia" :: #M
"ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
2) Sintaxis DependenciaArgumentoX:
IDArgumento :: #S :: #I "ClaveInstancia" ::
#M "ClaveMétodo"
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Aunque los diagramas de flujo en las figuras
muestran un orden particular de operaciones realizadas por ciertas
realizaciones de la invención, debería entenderse que tal orden es
un ejemplo (por ejemplo, realizaciones alternativas pueden realizar
las operaciones en un orden diferente, combinar ciertas operaciones,
solapar ciertas operaciones, etc.)
Claims (26)
1. Un método implementado por ordenador para
ejecutar un programa de aplicación escrito en un código orientado a
objetos, comprendiendo el método:
representar un productor con una salida que es
actualmente de interés, en el que el código orientado a objetos
incluye métodos y declaraciones de dependencias del productor, en el
que la declaración de dependencias del productor para un método
determinado identifica un conjunto de cero o más productores, en el
que un productor es una construcción representable por una rutina de
ejecución que incluye al menos una instancia y un método asociado
con esa instancia;
en respuesta a dicha representación, añadir el
productor de interés como parte del primer gráfico de
productores;
intentar generar automáticamente un resto del
primer gráfico de productores mediante enlazado, y la representación
si es necesaria, de otros productores en base a las declaraciones de
dependencias del productor y los métodos de los productores ya en el
primer gráfico de productores; y
simular el programa de aplicación con un cambio
en el programa de aplicación mientras que se impiden estados
existentes y salidas existentes de los productores en el primer
gráfico de productores.
2. El método de la reivindicación 1, en el que
los productores están interconectados entre sí en base a las
dependencias entre los productores en el primer gráfico de
productores, en el que el primer gráfico de productores, los estados
existentes, y las salidas existentes del programa de aplicación
corresponden a un primer escenario, en el que el cambio incluye
cambios en las salidas de uno o más productores impactados
directamente del programa de aplicación.
3. El método de la reivindicación 2, que
comprende además:
recibir información de escenario que incluye una
clave del escenario de referencia que identifica el primer
escenario, una clave del escenario objetivo que identifica un
escenario objetivo, y una referencia a una lista de impactos que
contiene una colección de una o más claves de productores del uno o
más productores impactados directamente para el escenario objetivo e
información sobre los cambios de las salidas del uno o más
productores impactados directamente; y
crear un segundo escenario usando la información
del escenario.
4. El método de la reivindicación 3, en el que
crear el segundo escenario comprende:
determinar qué productores, de los productores
que están en el primer gráfico de productores se van a impactar por
las salidas del uno o más productores impactados directamente usando
el primer gráfico de productores; y
registrar los productores impactados en una
estructura de seguimiento de productores de impactos.
5. El método de la reivindicación 4, en el que
crear el segundo escenario comprende:
crear un segundo gráfico de productores que
tiene una copia de al menos un productor de interés, el uno o más
productores impactados directamente, y cualquiera de los productores
impactados en la estructura de seguimiento de productores de impacto
del cual depende el productor de interés; y
cambiar las salidas de la copia de uno o más
productores impactados directamente de acuerdo con la información en
la lista de impactos.
6. El método de la reivindicación 5, en el que
cambiar las salidas de la copia del uno o más productores impactados
directamente de acuerdo con la información en la lista de impactos
comprende:
anular las salidas de la copia del uno o más
productores impactados directamente en el segundo gráfico de
productores con un valor predeterminado especificado por la
información en la lista de impactos.
7. El método de la reivindicación 5, en el que
cambiar las salidas de la copia del uno o más productores impactados
directamente de acuerdo con la información en la lista de impactos
comprende:
determinar las salidas de los productores en el
primer escenario; y
generar la salida de la copia del productor
impactado directamente en el segundo escenario usando las salidas de
los productores en el primer escenario y la información en la lista
de impactos.
\newpage
8. El método de la reivindicación 5, en el que
crear el segundo gráfico de productores comprende:
enlazar uno o más productores en el primer
gráfico de productores con el segundo gráfico de productores, en el
que, el uno o más productores son independientes del productor
impactado directamente.
9. El método de la reivindicación 5, en el que
crear el segundo gráfico de productores comprende:
clonar el productor de interés y cualquiera de
los productores impactados del cual depende el productor de interés
usando el primer gráfico de productores.
10. El método de la reivindicación 5, en el que
crear el segundo gráfico de productores comprende:
crear el productor de interés y los productores
impactados de los cuales depende el productor de interés desde la
definición del método y la declaración de dependencias de un método
de cada uno de los productores de interés y los productores
impactados de los cuales depende el productor de interés.
11. El método de la reivindicación 5, que
comprende además:
ejecutar el programa de aplicación en el segundo
escenario usando las salidas cambiadas de la copia del uno o más
productores impactados directamente para determinar la salida de la
copia del productor de interés en el segundo gráfico de productores
mientras que se conservan las salidas existentes del productor de
interés, el uno o más productores impactados directamente, y los
productores impactados para el primer escenario;
almacenar la salida de la copia del productor de
interés para el segundo escenario en un almacenamiento temporal
mientras que se retiene la salida existente del productor de interés
para el primer escenario en el almacenamiento temporal;
almacenar la salida cambiada de la copia del uno
o más productores impactados directamente para el segundo escenario
en el almacenamiento temporal mientras que se mantiene la salida
existente del uno o más productores impactados directamente para el
primer escenario en el almacenamiento temporal; y
almacenar las salidas de las copias de los
productores intermedios sobre la trayectoria entre el productor de
interés y el uno o más productores impactados directamente para el
segundo escenario en el almacenamiento temporal mientras que se
retienen las salida existentes de los productores intermedios para
el primer escenario en el almacenamiento temporal.
12. El método de la reivindicación 11, que
comprende además:
determinar automáticamente una derivada de la
salida del productor de interés desde el primer escenario al segundo
escenario usando la salida de la copia del productor de interés para
el segundo escenario y la salida del productor de interés para el
primer escenario.
13. El método de la reivindicación 12, que
comprende además:
determinar automáticamente y de forma recursiva
al menos una de las derivadas de orden N y una derivada cruzada
usando la derivada de la salida de la copia del productor de interés
desde el primer escenario al segundo escenario, donde N es un número
entero mayor de uno.
14. El método de la reivindicación 5, en el que
el programa de aplicación comprende ejecutar un productor de
generación de productores estresados para crear dinámicamente al
menos uno de los productores en el segundo gráfico de
productores.
15. Un sistema que comprende:
una rutina de ejecución que corre un código
fuente orientado a objetos con declaraciones de dependencias del
productor para métodos, en el que un productor es un constructor
representable por rutina de ejecución que incluye al menos una
instancia y un método asociado con la instancia, en el que cada
declaración de dependencias del productor para un método determinado
identifica un conjunto de cero o más productores, dicha rutina de
ejecución incluye:
un nuevo módulo de escenarios para recibir
información de escenarios de un escenario objetivo y, en respuesta a
un comando de representación de escenarios; representar el escenario
objetivo;
un módulo de generación automatizada de gráficos
de productores estresados acoplado al nuevo módulo de escenarios
para recibir un productor seleccionado actualmente con una salida de
interés, y para construir un gráfico de productores para el
escenario objetivo usando la información del escenario, incluyendo
el gráfico de productores una copia de cada uno de los productores
seleccionados actualmente, uno o más productores que tienen salidas
cambiadas en el escenario objetivo de acuerdo con la información de
escenario, y los productores intermedios entre el uno o más
productores y el productor actualmente seleccionado; y
un módulo de ejecución automatizada de gráficos
de productores estresados acoplado al módulo de generación
automatizada de gráficos de productores estresados para recibir las
salidas cambiadas del uno o más productores en el gráfico de
productores para el escenario objetivo y aplicar las salida
cambiadas a los productores del gráfico de productores para el
escenario objetivo para determinar la salida del productor de
interés seleccionado actualmente en el escenario objetivo.
16. El sistema de la reivindicación 15, en el
que la información de escenario incluye una referencia
una clave de escenario, una clave de escenario
objetivo, una referencia a una lista de productores impactados
directamente, y un indicador asociado con cada uno de los
productores impactados directamente para indicar si la salida del
productor correspondiente impactado directamente va a cambiar a un
valor predeterminado o se va a generar a partir de una salida
existente del productor correspondiente impactado directamente.
17. El sistema de la reivindicación 16, en el
que la rutina de ejecución comprende además:
un módulo de anulación de la salida del
productor acoplado con el módulo de generación automatizada de
gráficos de productores estresados para anular la salida de cada uno
de los productores impactados directamente con el correspondiente
valor predeterminado.
18. El sistema de la reivindicación 15, en el
que la rutina de ejecución comprende además:
una estructura de gráficos de productores
acoplada con el módulo de generación automatizada de gráficos de
productores estresados para almacenar el gráfico de productores para
el escenario objetivo sin sobrescribir cualesquiera de los gráficos
de productores existentes almacenados en el mismo, en el que la
estructura del gráfico de productores comprende además una
estructura de almacenamiento temporal de la salida del productor
para almacenar la salida del productor de interés seleccionado
actualmente, las salidas de los productores intermedios, y las
salidas cambiadas del uno o más productores para el escenario
objetivo sin sobrescribir cualesquiera de las salidas existentes del
productor de interés seleccionado actualmente, los productores
intermedios, y el uno o más productores almacenados en
el mismo.
el mismo.
19. El sistema de la reivindicación 15, en el
que la rutina de ejecución comprende además:
una estructura de seguimiento de escenarios
acoplada con el nuevo módulo de escenarios, en el que el nuevo
módulo de escenarios se puede actuar para representar el escenario
objetivo añadiendo la información de escenario a la estructura de
seguimiento de escenarios.
20. El sistema de la reivindicación 15, que
comprende además;
un segundo rutina de ejecución que se puede
actuar para cargar y representar clases, para invocar métodos, y
para realizar la introspección de al menos una de las clases y los
métodos, en el que la segunda rutina de ejecución está separada
lógicamente de la rutina de ejecución.
21. El sistema de la reivindicación 15, en el
que la rutina de ejecución se puede actuar además para cargar y
representar clases, para invocar métodos, y para
realizar una introspección sobre al menos una de las clases y de los
métodos.
22. El sistema de la reivindicación 15, que
comprende además un sistema operativo en el que
la rutina de ejecución está integrada dentro del
sistema operativo.
23. Un medio legible por la máquina que
proporciona el código fuente orientado a objetos incluyendo:
una pluralidad de definiciones de clases de una
pluralidad de clases, incluyendo cada una de la pluralidad de
definiciones de clases,
un conjunto de uno o más campos,
un conjunto de uno o más métodos, y
una declaración de dependencias del productor
para cada uno de dicho conjunto de métodos, en el que la declaración
de dependencias del productor para uno determinado de dichos métodos
se usa en la rutina de ejecución para identificar un conjunto de
cero o más productores, en el que un productor es un constructor
representable por una rutina de ejecución que incluye al menos una
instancia de una de la pluralidad de clases y un método asociado con
la instancia; y
en el que una primera de dicha pluralidad de
definiciones de clases define una primera de la pluralidad de clases
que tiene uno o más métodos de generación de productores estresados
para generar un conjunto de uno o más productores estresados,
incluyendo cada uno de dichos uno o más métodos de generación de
productores estresados código para identificar un productor de
interés y para definir un escenario objetivo, de tal modo que la
rutina de ejecución se puede actuar para ejecutar el método para
evaluar el impacto sobre el productor de interés para el escenario
objetivo.
24. El medio legible por la máquina de la
reivindicación 23, en el que cada uno del uno o más métodos de
generación de productores estresados especifica una clave del
escenario de referencia, una clave del escenario objetivo, una
referencia a una lista de productores impactados directamente, y un
indicador asociado con cada uno de los productores impactados
directamente para indicar si la salida de un productor impactado
directamente se va a cambiar a un valor predeterminado o se va a
generar a partir de una salida existente del productor
correspondiente impactado directamente.
25. El medio legible por la máquina de la
reivindicación 23, en el que cada uno del uno o más
métodos de generación de productores estresados,
cuando se ejecutan por la rutina de ejecución, causa que la rutina
de ejecución cree uno o más productores estresados en el escenario
objetivo y añada los productores estresados al gráfico de
productores del escenario objetivo.
26. El medio legible por la máquina de la
reivindicación 25, en el que cada uno del uno o más
productores estresados incluye una clave de
productor para identificar un productor y una clave de escenario
para identificar un escenario.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US607199 | 1990-10-31 | ||
| US11/607,199 US8332827B2 (en) | 2006-12-01 | 2006-12-01 | Produce graph oriented programming framework with scenario support |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2327797T3 true ES2327797T3 (es) | 2009-11-03 |
Family
ID=39358358
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07856313T Active ES2327797T3 (es) | 2006-12-01 | 2007-11-30 | Soporte de programacion orientado a graficos de productores con soporte de escenario. |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US8332827B2 (es) |
| EP (1) | EP1958062B1 (es) |
| JP (1) | JP5354603B2 (es) |
| CN (1) | CN101601012B (es) |
| AT (1) | ATE435453T1 (es) |
| DE (1) | DE602007001443D1 (es) |
| ES (1) | ES2327797T3 (es) |
| RU (1) | RU2438161C2 (es) |
| WO (1) | WO2008064902A2 (es) |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8751950B2 (en) | 2004-08-17 | 2014-06-10 | Ice Edge Business Solutions Ltd. | Capturing a user's intent in design software |
| US20050071135A1 (en) * | 2003-09-30 | 2005-03-31 | Vredenburgh David W. | Knowledge management system for computer-aided design modeling |
| WO2009111885A1 (en) | 2008-03-11 | 2009-09-17 | Dirtt Environmental Solutions, Ltd. | Automatically creating and modifying furniture layouts in design software |
| US8332827B2 (en) | 2006-12-01 | 2012-12-11 | Murex S.A.S. | Produce graph oriented programming framework with scenario support |
| US8307337B2 (en) | 2006-12-01 | 2012-11-06 | Murex S.A.S. | Parallelization and instrumentation in a producer graph oriented programming framework |
| US8191052B2 (en) | 2006-12-01 | 2012-05-29 | Murex S.A.S. | Producer graph oriented programming and execution |
| US7865872B2 (en) * | 2006-12-01 | 2011-01-04 | Murex S.A.S. | Producer graph oriented programming framework with undo, redo, and abort execution support |
| US8307372B2 (en) | 2007-04-02 | 2012-11-06 | International Business Machines Corporation | Method for declarative semantic expression of user intent to enable goal-driven information processing |
| US8370812B2 (en) * | 2007-04-02 | 2013-02-05 | International Business Machines Corporation | Method and system for automatically assembling processing graphs in information processing systems |
| US8863102B2 (en) * | 2007-04-02 | 2014-10-14 | International Business Machines Corporation | Method and system for assembling information processing applications based on declarative semantic specifications |
| CN101689111A (zh) * | 2007-04-03 | 2010-03-31 | Ldra技术公司 | 软件需求验证的自动化管理 |
| US10248915B2 (en) | 2008-03-07 | 2019-04-02 | International Business Machines Corporation | Risk profiling for enterprise risk management |
| CA2781638C (en) | 2009-11-24 | 2019-06-04 | Ice Edge Business Solutions Inc. | Securely sharing design renderings over a network |
| US8595709B2 (en) * | 2009-12-10 | 2013-11-26 | Microsoft Corporation | Building an application call graph from multiple sources |
| US20120117546A1 (en) * | 2010-11-08 | 2012-05-10 | International Business Machines Corporation | Run-time Module Interdependency Verification |
| US8897900B2 (en) * | 2011-03-18 | 2014-11-25 | Rockwell Automation Technologies, Inc. | Graphical language for optimization and use |
| US9230358B2 (en) | 2011-03-31 | 2016-01-05 | International Business Machines Corporation | Visual connectivity of widgets using event propagation |
| WO2012173741A2 (en) | 2011-06-11 | 2012-12-20 | Dirtt Environmental Solutions Inc. | Automated re-use of structural components |
| US9292422B2 (en) | 2012-10-12 | 2016-03-22 | Vmware, Inc. | Scheduled software item testing |
| US8949794B2 (en) | 2012-10-12 | 2015-02-03 | Vmware, Inc. | Binding a software item to a plain english control name |
| US9069902B2 (en) | 2012-10-12 | 2015-06-30 | Vmware, Inc. | Software test automation |
| US9684587B2 (en) | 2012-10-12 | 2017-06-20 | Vmware, Inc. | Test creation with execution |
| US8839201B2 (en) | 2012-10-12 | 2014-09-16 | Vmware, Inc. | Capturing test data associated with error conditions in software item testing |
| US10067858B2 (en) | 2012-10-12 | 2018-09-04 | Vmware, Inc. | Cloud-based software testing |
| US8839202B2 (en) * | 2012-10-12 | 2014-09-16 | Vmware, Inc. | Test environment managed within tests |
| US9292416B2 (en) | 2012-10-12 | 2016-03-22 | Vmware, Inc. | Software development kit testing |
| US10387294B2 (en) | 2012-10-12 | 2019-08-20 | Vmware, Inc. | Altering a test |
| US9201649B2 (en) * | 2012-10-26 | 2015-12-01 | Inforsys Limited | Systems and methods for estimating an impact of changing a source file in a software |
| US9471719B2 (en) | 2012-12-10 | 2016-10-18 | Dirtt Environmental Solutions, Ltd | Efficient lighting effects in design software |
| CA2838197C (en) | 2013-01-25 | 2020-05-12 | Robert W. Blodgett | Real-time depth of field effects with design software |
| US9619920B2 (en) | 2013-01-31 | 2017-04-11 | Ice Edge Business Solutions, Ltd. | Method and system for efficient modeling of specular reflection |
| JP5707430B2 (ja) * | 2013-01-31 | 2015-04-30 | 京セラドキュメントソリューションズ株式会社 | アプリケーション開発プログラム |
| US9245381B2 (en) | 2013-01-31 | 2016-01-26 | Ice Edge Business Solutions, Ltd | Visual distortion effects through translucent structures in design software |
| US9292405B2 (en) | 2013-03-08 | 2016-03-22 | Sap Se | HANA based multiple scenario simulation enabling automated decision making for complex business processes |
| US9389986B2 (en) * | 2013-05-06 | 2016-07-12 | Microsoft Technology Licensing, Llc | Identifying impacted tests from statically collected data |
| CA2883079C (en) | 2013-05-31 | 2021-10-26 | Ice Edge Business Solutions Ltd. | Associating computer-executable objects with three-dimensional spaces within an architectural design environment |
| RU2656580C9 (ru) * | 2014-01-30 | 2020-01-22 | Общество с ограниченной ответственностью "Аби Девелопмент" | Определение порядка инициализации статических объектов |
| CA2921871A1 (en) | 2014-06-09 | 2015-12-17 | Ice Edge Business Solutions Ltd. | Associating computer-executable objects with timber frames within an architectural design environment |
| US9465723B2 (en) * | 2014-10-27 | 2016-10-11 | Software Ag Usa, Inc. | Systems and/or methods for monitoring live software |
| RU2693682C2 (ru) * | 2014-12-19 | 2019-07-03 | Сергей Анатольевич Горишний | Система и способ управления функционально связанными данными |
| US9411706B1 (en) * | 2015-09-30 | 2016-08-09 | Semmle Limited | Suggesting candidate removable software dependencies |
| CN105739983B (zh) * | 2016-01-29 | 2019-03-15 | 腾讯科技（深圳）有限公司 | 脚本程序编辑装置及其实现方法 |
| CN105867907A (zh) * | 2016-03-23 | 2016-08-17 | 沈阳师范大学 | 去除业务耦合性的JSS多层Web开发框架设计方法 |
| EP3443432A4 (en) * | 2016-04-12 | 2020-04-01 | Guardknox Cyber Technologies Ltd. | SPECIALLY PROGRAMMED COMPUTER SYSTEMS WITH ASSOCIATED DEVICES CONFIGURED TO IMPLEMENT SECURE LOCKINGS AND METHODS OF USING THEM |
| US10146530B1 (en) | 2017-07-12 | 2018-12-04 | International Business Machines Corporation | Simulating and evaluating code branch merge |
| US10963373B2 (en) * | 2019-03-25 | 2021-03-30 | Aurora Labs Ltd. | Identifying software dependencies using line-of-code behavior and relation models |
| US11113030B1 (en) * | 2019-05-23 | 2021-09-07 | Xilinx, Inc. | Constraints for applications in a heterogeneous programming environment |
| US11615271B2 (en) | 2019-06-03 | 2023-03-28 | Cerebri AI Inc. | Machine learning pipeline optimization |
| CN111857683A (zh) * | 2020-07-01 | 2020-10-30 | 北京黄金管家科技发展有限公司 | Java高效编程系统 |
Family Cites Families (105)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4558413A (en) * | 1983-11-21 | 1985-12-10 | Xerox Corporation | Software version management system |
| US5481740A (en) | 1986-04-14 | 1996-01-02 | National Instruments Corporation | Method and apparatus for providing autoprobe features in a graphical data flow diagram |
| US5504917A (en) | 1986-04-14 | 1996-04-02 | National Instruments Corporation | Method and apparatus for providing picture generation and control features in a graphical data flow environment |
| US5481741A (en) | 1986-04-14 | 1996-01-02 | National Instruments Corporation | Method and apparatus for providing attribute nodes in a graphical data flow environment |
| US5497500A (en) | 1986-04-14 | 1996-03-05 | National Instruments Corporation | Method and apparatus for more efficient function synchronization in a data flow program |
| US5155836A (en) | 1987-01-27 | 1992-10-13 | Jordan Dale A | Block diagram system and method for controlling electronic instruments with simulated graphic display |
| JPS6432337A (en) * | 1987-07-29 | 1989-02-02 | Hitachi Ltd | Method for instructing influence of program change |
| US5371851A (en) | 1989-04-26 | 1994-12-06 | Credence Systems Corporation | Graphical data base editor |
| US5313387A (en) * | 1989-06-30 | 1994-05-17 | Digital Equipment Corporation | Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers |
| DE69126066T2 (de) * | 1990-06-29 | 1997-09-25 | Oracle Corp | Verfahren und Gerät zur Optimierung des Logbuchaufhebungsgebrauchs |
| DE69225544T2 (de) | 1991-08-13 | 1998-12-03 | Xerox Corp | Elektronische Bilderzeugung |
| JPH05265975A (ja) * | 1992-03-16 | 1993-10-15 | Hitachi Ltd | 並列計算処理装置 |
| US5416895A (en) * | 1992-04-08 | 1995-05-16 | Borland International, Inc. | System and methods for improved spreadsheet interface with user-familiar objects |
| US5659747A (en) * | 1993-04-22 | 1997-08-19 | Microsoft Corporation | Multiple level undo/redo mechanism |
| JPH06332785A (ja) | 1993-05-25 | 1994-12-02 | Fujitsu Ltd | オブジェクト指向データ処理システム |
| JPH0713766A (ja) * | 1993-06-14 | 1995-01-17 | Internatl Business Mach Corp <Ibm> | オブジェクト指向コンピュータ・システムおよびオブジェクト・クラス管理方法 |
| US5758160A (en) * | 1993-06-28 | 1998-05-26 | Object Technology Licensing Corporation | Method and apparatus for building a software program using dependencies derived from software component interfaces |
| US5893123A (en) * | 1995-06-22 | 1999-04-06 | Tuinenga; Paul W. | System and method of integrating a spreadsheet and external program having output data calculated automatically in response to input data from the spreadsheet |
| US6003037A (en) * | 1995-11-14 | 1999-12-14 | Progress Software Corporation | Smart objects for development of object oriented software |
| US5838976A (en) | 1995-11-28 | 1998-11-17 | Hewlett-Packard Co. | System and method for profiling code on symmetric multiprocessor architectures |
| US6067415A (en) * | 1995-12-26 | 2000-05-23 | Kabushiki Kaisha Toshiba | System for assisting a programmer find errors in concurrent programs |
| US7987427B1 (en) | 1996-05-10 | 2011-07-26 | Apple Inc. | Graphical editor for program files |
| US5819293A (en) * | 1996-06-06 | 1998-10-06 | Microsoft Corporation | Automatic Spreadsheet forms |
| US5966072A (en) * | 1996-07-02 | 1999-10-12 | Ab Initio Software Corporation | Executing computations expressed as graphs |
| US5822593A (en) | 1996-12-06 | 1998-10-13 | Xerox Corporation | High-level loop fusion |
| JP3730740B2 (ja) * | 1997-02-24 | 2006-01-05 | 株式会社日立製作所 | 並列ジョブ多重スケジューリング方法 |
| US6145121A (en) * | 1997-04-17 | 2000-11-07 | University Of Washington | Trace based method for the analysis, benchmarking and tuning of object oriented databases and applications |
| US6026235A (en) * | 1997-05-20 | 2000-02-15 | Inprise Corporation | System and methods for monitoring functions in natively compiled software programs |
| US6209125B1 (en) | 1997-06-03 | 2001-03-27 | Sun Microsystems, Inc. | Method and apparatus for software component analysis |
| US5990906A (en) * | 1997-06-25 | 1999-11-23 | National Instruments Corporation | Undo feature for a graphical programming system |
| US6233733B1 (en) | 1997-09-30 | 2001-05-15 | Sun Microsystems, Inc. | Method for generating a Java bytecode data flow graph |
| US6427234B1 (en) * | 1998-06-11 | 2002-07-30 | University Of Washington | System and method for performing selective dynamic compilation using run-time information |
| US6223171B1 (en) * | 1998-08-25 | 2001-04-24 | Microsoft Corporation | What-if index analysis utility for database systems |
| US6111575A (en) * | 1998-09-24 | 2000-08-29 | International Business Machines Corporation | Graphical undo/redo manager and method |
| US6493868B1 (en) * | 1998-11-02 | 2002-12-10 | Texas Instruments Incorporated | Integrated development tool |
| US6826752B1 (en) * | 1998-12-17 | 2004-11-30 | California Institute Of Technology | Programming system and thread synchronization mechanisms for the development of selectively sequential and multithreaded computer programs |
| JP2000207223A (ja) * | 1999-01-12 | 2000-07-28 | Matsushita Electric Ind Co Ltd | 並列処理向けのプログラム処理方法および装置、並びに並列処理向けのプログラム処理を実行するプログラムを記録した記録媒体および並列処理向けの命令列を記録した記録媒体 |
| US6385770B1 (en) * | 1999-01-29 | 2002-05-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
| US6957191B1 (en) * | 1999-02-05 | 2005-10-18 | Babcock & Brown Lp | Automated financial scenario modeling and analysis tool having an intelligent graphical user interface |
| US6571388B1 (en) * | 1999-03-09 | 2003-05-27 | Hewlett-Packard Development Company, L.P. | Building a custom software environment including pre-loaded classes |
| US6407753B1 (en) * | 1999-05-04 | 2002-06-18 | International Business Machines Corporation | System and method for integrating entities via user-interactive rule-based matching and difference reconciliation |
| US6665866B1 (en) | 1999-05-28 | 2003-12-16 | Microsoft Corporation | Extensible compiler utilizing a plurality of question handlers |
| JP2001005678A (ja) * | 1999-06-18 | 2001-01-12 | Fujitsu Ltd | ネットワーク型情報処理装置及び方法 |
| WO2001001206A2 (en) | 1999-06-30 | 2001-01-04 | Strategic Simulation Systems, Inc. | System dynamics model builder and simulator |
| US6618851B1 (en) * | 1999-08-31 | 2003-09-09 | Autodesk, Inc. | Method and apparatus for state-reversion |
| WO2001082068A1 (en) | 2000-04-21 | 2001-11-01 | Togethersoft Corporation | Methods and systems for identifying dependencies between object-oriented elements |
| CA2346231A1 (en) | 2000-05-08 | 2001-11-08 | Internet Number Corporation | Method and system for accessing information on a network using message aliasing functions having shadow callback functions |
| US6959429B1 (en) * | 2000-05-16 | 2005-10-25 | Watterson-Prime Software, Inc. | System for developing data collection software applications |
| US6763515B1 (en) | 2000-06-05 | 2004-07-13 | National Instruments Corporation | System and method for automatically generating a graphical program to perform an image processing algorithm |
| US20030005407A1 (en) | 2000-06-23 | 2003-01-02 | Hines Kenneth J. | System and method for coordination-centric design of software systems |
| US6889227B1 (en) * | 2000-07-21 | 2005-05-03 | Sun Microsystems, Inc. | Database access bridge system and process |
| RU2206119C2 (ru) | 2000-09-22 | 2003-06-10 | Закрытое акционерное общество "МЦСТ" | Способ получения объектного кода |
| US6973640B2 (en) * | 2000-10-04 | 2005-12-06 | Bea Systems, Inc. | System and method for computer code generation |
| WO2002046916A2 (en) * | 2000-10-20 | 2002-06-13 | Polexis, Inc. | Extensible information system (xis) |
| US6826523B1 (en) * | 2000-11-01 | 2004-11-30 | Sony Computer Entertainment America Inc. | Application development interface for multi-user applications executable over communication networks |
| US6829572B2 (en) * | 2000-12-07 | 2004-12-07 | Internatinal Business Machines Corporation | Method and system for efficiently overriding array net values in a logic simulator machine |
| US6820256B2 (en) * | 2000-12-13 | 2004-11-16 | Microsoft Corporation | System and method for whole-system program analysis |
| US7200838B2 (en) | 2000-12-20 | 2007-04-03 | National Instruments Corporation | System and method for automatically generating a graphical program in response to a state diagram |
| US6836884B1 (en) * | 2001-06-04 | 2004-12-28 | Microsoft Corporation | Method and system for editing software programs |
| US20020188616A1 (en) * | 2001-06-07 | 2002-12-12 | Chinnici Roberto R. | Database access bridge system and process |
| US7051339B2 (en) * | 2001-06-29 | 2006-05-23 | Goldman, Sachs & Co. | System and method to measure latency of transaction information flowing through a computer system |
| US6995765B2 (en) | 2001-07-13 | 2006-02-07 | Vicarious Visions, Inc. | System, method, and computer program product for optimization of a scene graph |
| US6966013B2 (en) * | 2001-07-21 | 2005-11-15 | International Business Machines Corporation | Method and system for performing automated regression tests in a state-dependent data processing system |
| US7236915B2 (en) * | 2001-08-09 | 2007-06-26 | Hewlett-Packard Development Company, L.P. | Technique and interface for computer system resource assignment |
| US20040205524A1 (en) * | 2001-08-15 | 2004-10-14 | F1F9 | Spreadsheet data processing system |
| US7010779B2 (en) * | 2001-08-16 | 2006-03-07 | Knowledge Dynamics, Inc. | Parser, code generator, and data calculation and transformation engine for spreadsheet calculations |
| US7017084B2 (en) * | 2001-09-07 | 2006-03-21 | Network Appliance Inc. | Tracing method and apparatus for distributed environments |
| US8473922B2 (en) | 2001-09-19 | 2013-06-25 | Hewlett-Packard Development Company, L.P. | Runtime monitoring in component-based systems |
| US7069547B2 (en) * | 2001-10-30 | 2006-06-27 | International Business Machines Corporation | Method, system, and program for utilizing impact analysis metadata of program statements in a development environment |
| US7194475B2 (en) * | 2001-10-30 | 2007-03-20 | International Business Machines Corporation | Method, system, and program for performing an impact analysis of program statements in at least one source code file |
| CA2360650A1 (en) * | 2001-10-31 | 2003-04-30 | Ibm Canada Limited-Ibm Canada Limitee | Algorithm to create and compare debug scenarios of a computer process |
| JP2003157185A (ja) * | 2001-11-19 | 2003-05-30 | Nec Corp | 計算機の動作の解析・表示装置とその解析・表示方法及びコンピュータプログラム |
| US7203743B2 (en) | 2001-12-28 | 2007-04-10 | Nortel Networks Limited | Hierarchical tree-based protection scheme for mesh networks |
| US7039923B2 (en) | 2002-04-19 | 2006-05-02 | Sun Microsystems, Inc. | Class dependency graph-based class loading and reloading |
| US7159211B2 (en) * | 2002-08-29 | 2007-01-02 | Indian Institute Of Information Technology | Method for executing a sequential program in parallel with automatic fault tolerance |
| US7210128B2 (en) * | 2002-10-14 | 2007-04-24 | Fujitsu Limited | Event-driven observability enhanced coverage analysis |
| TWI262383B (en) * | 2003-01-10 | 2006-09-21 | Univ Nat Cheng Kung | A generic software testing system and method |
| US7571431B2 (en) | 2003-04-29 | 2009-08-04 | Microsoft Corporation | Processing macro information and displaying via GUI in different tools |
| US7299450B2 (en) * | 2003-06-17 | 2007-11-20 | Microsoft Corporation | Undoing changes in a software configuration management system |
| KR100513385B1 (ko) * | 2003-06-19 | 2005-09-07 | 삼성전자주식회사 | 선형 위상 검출기를 이용한 클럭 및 데이터 복원 장치 및 그 방법 |
| US7559050B2 (en) * | 2003-06-30 | 2009-07-07 | Microsoft Corporation | Generating software development tools via target architecture specification |
| US7739252B2 (en) * | 2003-07-14 | 2010-06-15 | Oracle America, Inc. | Read/write lock transaction manager freezing |
| US7818718B2 (en) * | 2003-09-30 | 2010-10-19 | Sap Ag | Undoing user actions in a client program |
| US7454701B2 (en) * | 2003-10-30 | 2008-11-18 | Sap Ag | Systems and methods for implementing formulas |
| US7536678B2 (en) * | 2003-12-04 | 2009-05-19 | International Business Machines Corporation | System and method for determining the possibility of adverse effect arising from a code change in a computer program |
| US7792824B2 (en) * | 2004-01-08 | 2010-09-07 | International Business Machines Corporation | Apparatus and method for enabling parallel processing of a computer program using existing database parallelism |
| US7917898B2 (en) * | 2004-02-02 | 2011-03-29 | Intel Corporation | Methods and apparatus to provide a modular native method invocation system |
| US7316001B2 (en) * | 2004-06-05 | 2008-01-01 | Graphlogic Inc. | Object process graph system |
| US7444287B2 (en) * | 2004-07-01 | 2008-10-28 | Emc Corporation | Efficient monitoring system and method |
| US7493335B2 (en) | 2004-07-02 | 2009-02-17 | Graphlogic Inc. | Object process graph relational database interface |
| US7360209B2 (en) * | 2004-07-16 | 2008-04-15 | Graphlogic Inc. | Object process graph application controller-viewer |
| US7506320B2 (en) * | 2004-09-09 | 2009-03-17 | International Business Machines Corporation | Generating sequence diagrams using call trees |
| EP1787197A2 (en) * | 2004-09-10 | 2007-05-23 | Graphlogic Inc. | Object process graph application development system |
| US7933862B2 (en) * | 2004-09-27 | 2011-04-26 | Microsoft Corporation | One click conditional formatting method and system for software programs |
| US7458072B2 (en) * | 2004-10-06 | 2008-11-25 | Microsoft Corporation | Execution context infrastructure |
| US20060080660A1 (en) * | 2004-10-07 | 2006-04-13 | Dell Products L.P. | System and method for disabling the use of hyper-threading in the processor of a computer system |
| US7831956B2 (en) * | 2005-09-13 | 2010-11-09 | Microsoft Corporation | Using attributes to identify and filter pluggable functionality |
| US7904892B2 (en) | 2006-01-06 | 2011-03-08 | Northrop Grumman Corporation | Systems and methods for identifying and displaying dependencies |
| US7882498B2 (en) * | 2006-03-31 | 2011-02-01 | Intel Corporation | Method, system, and program of a compiler to parallelize source code |
| US7844959B2 (en) | 2006-09-29 | 2010-11-30 | Microsoft Corporation | Runtime optimization of distributed execution graph |
| US8902231B2 (en) | 2006-10-20 | 2014-12-02 | Alcatel Lucent | Method and apparatus for displaying graphical representations of graph layouts |
| US8307337B2 (en) | 2006-12-01 | 2012-11-06 | Murex S.A.S. | Parallelization and instrumentation in a producer graph oriented programming framework |
| US7865872B2 (en) | 2006-12-01 | 2011-01-04 | Murex S.A.S. | Producer graph oriented programming framework with undo, redo, and abort execution support |
| US8191052B2 (en) | 2006-12-01 | 2012-05-29 | Murex S.A.S. | Producer graph oriented programming and execution |
| US8332827B2 (en) | 2006-12-01 | 2012-12-11 | Murex S.A.S. | Produce graph oriented programming framework with scenario support |
-
2006
- 2006-12-01 US US11/607,199 patent/US8332827B2/en active Active
-
2007
- 2007-11-30 AT AT07856313T patent/ATE435453T1/de not_active IP Right Cessation
- 2007-11-30 CN CN200780050596.4A patent/CN101601012B/zh active Active
- 2007-11-30 EP EP07856313A patent/EP1958062B1/en active Active
- 2007-11-30 DE DE602007001443T patent/DE602007001443D1/de active Active
- 2007-11-30 WO PCT/EP2007/010410 patent/WO2008064902A2/en active Application Filing
- 2007-11-30 ES ES07856313T patent/ES2327797T3/es active Active
- 2007-11-30 RU RU2009125011/08A patent/RU2438161C2/ru active
- 2007-11-30 JP JP2009538646A patent/JP5354603B2/ja active Active
-
2012
- 2012-12-10 US US13/710,372 patent/US9201766B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| RU2009125011A (ru) | 2011-01-10 |
| EP1958062A2 (en) | 2008-08-20 |
| RU2438161C2 (ru) | 2011-12-27 |
| JP2010511235A (ja) | 2010-04-08 |
| DE602007001443D1 (de) | 2009-08-13 |
| US20080134152A1 (en) | 2008-06-05 |
| US8332827B2 (en) | 2012-12-11 |
| WO2008064902A3 (en) | 2008-07-17 |
| ATE435453T1 (de) | 2009-07-15 |
| CN101601012B (zh) | 2014-03-19 |
| EP1958062B1 (en) | 2009-07-01 |
| CN101601012A (zh) | 2009-12-09 |
| JP5354603B2 (ja) | 2013-11-27 |
| WO2008064902A2 (en) | 2008-06-05 |
| US20130104109A1 (en) | 2013-04-25 |
| US9201766B2 (en) | 2015-12-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2327797T3 (es) | Soporte de programacion orientado a graficos de productores con soporte de escenario. | |
| ES2497573T3 (es) | Salidas de sustitución en un sistema de programación y ejecución orientado por grafos de productor | |
| ES2473765T3 (es) | Paralelizaci�n e instrumentaci�n en un marco de programación orientado a grafos de productor | |
| EP1952216B1 (en) | Producer graph oriented programming framework with undo, redo, and abort execution support | |
| US7526750B2 (en) | Object-based systematic state space exploration of software | |
| Horváth | Search-based techniques in model-driven engineering |