BRPI0719730A2

BRPI0719730A2 - Programação e execução orientada por gráfico de produtor.

Info

Publication number: BRPI0719730A2
Application number: BRPI0719730-6A2A
Authority: BR
Inventors: Fady Chamieh; Elias Edde
Original assignee: Murex Sas
Priority date: 2006-12-01
Filing date: 2007-11-30
Publication date: 2014-03-04
Also published as: US20140137086A1; EP2365436A3; US20080134138A1; EP2365435A2; ES2471394T3; US10083013B2; EP2365435A3; EP1942411A3; EP1942411B1; WO2008064901A8; US8607207B2; US20130232475A1; HK1139216A1; WO2008064901A3; US8645929B2; ES2381373T3; EP2365436B1; ES2497573T3; US8191052B2; CN101617292A

Description

Relatório Descritivo da Patente de Invenção para "PROGRA- MAÇÃO E EXECUÇÃO ORIENTADA POR GRÁFICO DE PRODUTOR".

ANTECEDENTES

Campo

A presente invenção refere-se ao campo de computadores e, mais especificamente, ao campo de código de programação e execução com um runtime.

Antecedentes

Programação Orientada por Obieto

A programação orientada por objeto é um paradigma de pro- gramação computacional. A ideia por trás da programação orientada por ob- jeto é que um programa de computador possa ser visto como compreenden- do uma coleção de unidades individuais (chamadas objetos ou instancias) que agem umas sobre as outras, em oposição a uma visão tradicional em que um programa pode ser visto como uma coleção de funções ou simples- mente como uma lista de instruções para o computador. Um objeto é um mecanismo de linguagem para ligar dados com métodos que operam sobre os dados. Cada objeto pode ser chamado através de métodos, que proces- sam os dados e fornecem os resultados a outros objetos. Cada objeto pode ser visualizado como uma máquina ou ator independente com um papel ou responsabilidade distinta.

Uma linguagem orientada por objeto reflexiva é uma linguagem de programação que tem um conjunto particular de características (por e- xemplo, classes, objetos/instâncias, herança, reflexão, etc.), enquanto que uma linguagem baseada em objeto reflexivo é usada, às vezes, para rotular uma linguagem de programação que tenha algum subconjunto daquelas ca- racterísticas (por exemplo, objetos). Para a finalidade deste documento, as frases "código fonte orientado por objeto" e "código orientado por objeto" serão usadas para fazer referência a código gravado em uma linguagem que tenha tais características (por exemplo, código gravado em uma linguagem orientada por objeto reflexiva, código gravado em uma linguagem baseada em objeto reflexivo). Embora as linguagens de procedimento, as linguagens

ws/DOCS/SDA P160149/RELATORIO/5655991 v1 orientadas por objeto não-reflexivas, e as linguagens baseadas em objetos não-reflexivas sejam linguagens de programação que não suportam tipica- mente tais características, as técnicas de transformação podem ser usadas para proporcionar tais características (por exemplo, através de emulação) a 5 código gravado em tais linguagens; e assim, tais técnicas transformam tais linguagens em uma linguagem baseada em objeto reflexiva ou linguagem orientada por objeto reflexiva. (Estas técnicas não precisam emular todas as características de linguagens orientadas ou baseadas em objeto, mas po- dem emular apenas aquelas características que sejam de interesse do resto 10 deste documento) Para os propósitos deste documento, as frases "código fonte orientada por objeto" e "código orientado por objeto" também serão usadas para fazer referência a tal código de procedimento transformado, orientado por objeto não reflexivo e baseado em objeto não reflexivo. À gui- sa de exemplo e não de limitação, este documento descreve principalmente 15 código fonte orientado por objeto gravado em uma linguagem orientada por objeto reflexiva. Além disso, os termos objeto e instância são usados aqui de modo intercambiável.

Usado principalmente em programação orientada por objeto, o termo método refere-se a um pedaço de código que é exclusivamente asso- 20 ciado a uma classe (chamados métodos de classe, métodos estáticos ou métodos de fábrica) ou a um objeto (chamados métodos de instância). Como um procedimento em linguagens de programação procedurais, um método consiste usualmente emuma seqüência de declarações para realizar uma ação, um conjunto de parâmetros de entrada para parametrizar aquelas a- 25 ções e, possivelmente, um valor de saída de algum tipo que é retornado.

Quando os programadores escrevem um programa usando uma linguagem orientada por objeto, o código resultante pode ser visualizado conceitualmente como incluindo quatro tipos básicos de código. O primeiro tipo inclui comandos que operam sobre instância(s) de entrada para fornecer 30 instância(s) de saída (referidos aqui como código de "transformação"); tipi- camente gravados como métodos (referidos aqui como métodos de "trans- formação"). O segundo tipo inclui comandos de instanciação de instância que fazem com que o runtime instancie instâncias de classes (referido aqui como código de "instanciação de instância). O terceiro tipo inclui comandos de manipulação de propriedade (referido como código de "preparação de dados") para invocar métodos de propriedade (acessores, mutadores, etc.)

5 das instâncias acima. O quarto tipo inclui seqüências de comandos que fa- zem com que o sequenciamento de invocação de método use as instâncias apropriadas (em que as instâncias apropriadas incluem as instâncias para usar como argumentos, as instâncias a serem usadas pelos métodos de ins- tância e as instâncias de metaclasse usadas pelos métodos de classe) para 10 especificar que métodos de transformação de que instâncias invocar, em que ordem e com quais parâmetros de que instâncias responsivas às mu- danças feitas pelo código de preparação de dados (referido aqui como códi- go de "sequenciamento de invocação manual). O codigo de sequenciamento de invocação manual é gravado, às vezes, como métodos separados dos 15 métodos de transformação e, assim, o código de sequenciamento de invo- cação manual inclui seqüências de comandos de invocação para os méto- dos de transformação. Tipicamente, um programa faz iterações entre o códi- go de preparação de dados e o código de sequenciamento de invocação manual (que também pode imergir no código de instanciação de instância), 20 que, por sua vez, invoca o código de transformação (que também pode i- mergir no código de instanciação de instância e tipos de código de prepara- ção de dados). Deve-se notar que esta é uma representação conceituai de um programa e, assim, não deve ser considerada como um absoluto no que diz respeito a como visualizar um programa.

Runtime

O termo runtime é usado para fazer referência a um programa ou biblioteca de código básico que roda outro código gravado na mesma linguagem e/ou uma linguagem diferente. Assim, um runtime é uma coleção de funções de utilidade que suporta um programa enquanto ele está rodan- 30 do, inclusive trabalhando com o sistema operacional para proporcionar facili- dades como funções matemáticas, entrada e saída. Isso torna desnecessá- rio que os programadores regravem continuamente capacidades básicas especificadas em uma linguagem de programação ou fornecidas por um sis- tema operacional, Como a demarcação entre um runtime e um sistema ope- racional pode ser obscura, o termo runtime é usado aqui para fazer referên- cia a código separado do sistema operacional e/ou código que seja parte do sistema operacional.

Os tempos de execução iniciais, como o do FORTRAN, propor- cionam características tais como operações matemáticas. Outras linguagens acrescentam características mais sofisticadas - por exemplo, coleta de resí- duo de memória, com frequência, em associação com suporte para objetos. Linguagens mais recentes tendem a ter tempos de execução consideravel- mente maiores com mais funcionalidade. Muitas linguagens orientadas por objeto também incluem um sistema conhecido como "expedidor" e "carrega- dor de classe". Java Virtual Machine (JVM) é um exemplo de tal runtime: também interpreta ou compila os programas Java binários portáteis (byte- codigo) no runtime. O runtime de linguagem comum (CLR - Common Lan- guage Runtime) é um outro exemplo de um runtime.

Estrutura de Execução e Programação

Uma estrutura dentro da qual são fornecidos os aplicativos a usuários finais inclui três divisões básicas. A primeira divisão inclui a criação do sistema operacional e runtime. A primeira divisão é realizada por progra- madores com conhecimentos de programação altamente avançados. Ao tra- balhar nesta divisão, os programadores são referidos, respectivamente, co- mo programadores de sistema operacional e programadores de runtime. Ao criar um runtime para uma linguagem orientada por objeto, os programado- res de runtime incluem suporte para executar os diversos tipos de comandos usados em código de transformação, código de instanciação de instância, código de preparação de dados e código de sequenciamento de invocação manual (por exemplo, comandos de instanciação de instância, comandos de preparação de dados e comandos de invocação de método).

A segunda divisão inclui a criacao de código fonte de aplicativo orientada por objeto a ser executado pelo runtime. A segunda divisão é no- vamente executada pelos programadores com conhecimentos de programa- ção altamente avançados, assim como uma compreensão os objetivos co- merciais do aplicativo. Ao trabalhar nesta divisão, os programadores são referidos como programadores de aplicativo. Ao criar um aplicativo em uma linguagem de programação orientada por objeto, os programadores de apli- cativo gravam o código de transformação específico, o código de instancia- ção de instância, o código de preparação de dados e o código de sequenci- amento de invocação manual para o aplicativo específico que está sendo criado. Como parte disso, se o aplicativo requerer uma interface gráfica com o usuário, os programadores de aplicativo também projetam e codificam a interface gráfica com o usuário para o aplicativo específico; e assim também são referidos como projetistas de aplicativo.

A terceira divisão inclui o uso de programas aplicativos que são executados pelo runtime. A terceira divisão é executada por usuários finais que não precisam ter qualquer conhecimento de programação.

Código de Sequenciamento de Invocação Manual

Os custos mais altos tipicamente associados à criação de um aplicativo envolvem depurar e/ou otimizar o código de sequenciamento de invocação manual. Para cada oportunidade para os dados mudarem, o pro- gramador do aplicativo tem que considerar seu efeito e gravar o código de sequenciamento de invocação manual para fazer com que os métodos ade- quados de transformação das instâncias apropriadas sejam invocados na ordem adequada com as entradas adequadas. Erros exemplificativos come- tidos pelos programadores de aplicativo incluem: 1) invocar os métodos de transformação apropriados das instâncias apropriadas em ordem errada; 2) esquecer de incluir comandos que fazem com que um ou mais métodos de transformação requeridos sejam invocados em resposta a algum dado que está sendo mudado; 3) incluir comandos que fazem com que métodos de instância de transformação desnecessários sejam invocados em resposta a algum dado que esteja sendo mudado (por exemplo, incluir comandos para invocar métodos de transformação de instâncias que não são afetadas pela mudança nos dados), etc.

À guisa de exemplo, uma técnica de gerar código de sequenci- í' amento de invocação manual é o uso de padrão observador (às vezes co- nhecido como "publicar assinatura") para observar o estado de uma instân- cia em um programa. No padrão observador, uma ou mais instâncias (cha- madas observadores ou ouvintes) são registradas (ou se registram) para 5 observar um evento que pode ser promovido pelo objeto observado (o sujei- to). A instância observada, que pode provocar um evento, geralmente man- tém uma coleção dos observadores registrados. Quando o evento é criado, cada observador recebe uma chamada da instância observada (a instância observada invoca um método de "notificar" nos observadores registrados). A 10 função de notificar pode passar alguns parâmetros (geralmente informação sobre o evento que está ocorrendo) que podem ser usados pelos observado- res. Cada observador implementa a função notificar e, como conseqüência, define seu próprio comportamento quando ocorre a notificação.

Tipicamente, a instância observada tem um método de registro 15 para adicionar um novo observador e um método de remoção de registro para remover um observador da lista de instâncias a serem notificadas quando o evento é criado. Adicionalmente, a instância observada também pode ter métodos para desabilitar temporariamente e então, habilitar nova- mente chamadas para impedir o cascateamento ineficiente de uma série de 20 atualizações relacionadas. Especificamente, as chamadas de retorno feitas em resposta a uma mudança de valor de propriedade com frequência tam- bém mudam valores de algumas outras propriedades, acionando chamadas de retorno adicionais, e assim por diante.

Ao usar a técnica de padrão de observador, os programadores 25 de aplicativos que gravam código de sequênciamento de invocação manual especificam que métodos de que instâncias chamar, em que ordem e com que entradas por meio do registro, remoção de registro, desabilitação e nova habilitação de observadores para diferentes instâncias observadas, assim como a gravação da notificação e métodos de chamada de retorno para ca- 30 da um. Mais especificamente, a relação entre o observador e instâncias do observador é gerenciada localmente (pela instância observada sozinha, sem sincronização com outras instâncias observadas) dentro do padrão do ob- servador, e assim o código de sequênciamento de invocação manual neces- sário para sincronizar eventos de múltiplas instâncias observadas é tipica- mente parte dos métodos de chamadas de retorno específicos de cada ob- servador.

Sobreqravação, Pilha de Chamada Volátil

Os tempos de execução típicos utilizam uma pilha de chamada volátil, de sobregravação para rastrear as chamadas incompletas que são invocadas no momento. Uma pilha de chamada volátil de sobregravação está sobregravando pelo fato de que ela desaparece e descarrega entradas conforme cada chamada é completada e é volátil pelo fato de que ela é des- carregada e reconstruída a cada execução. Tempos de execução típicos utilizam pilhas de chamada voláteis de sobregravação porque os tempos de execução típicos combinam a construção da pilha de chamada volátil de so- bregravação com a invocação real dos métodos de transformação adequa- dos das instâncias apropriadas com as entradas apropriadas em resposta à execução do código de sequenciamento de invocação manual. Em resposta à execução do código de sequenciamento de invocação manual, um runtime típico determina o método de transformação/sequenciamento de instância, chamada a chamada (conforme cada medida é feita) e mantém a pilha de chamada volátil, de sobregravação, para rastrear apenas as chamadas não completadas invocadas correntemente.

Mapeamento Obieto-Relacional

O mapeamento objeto-relacional é uma técnica de programação que liga bancos de dados relacionais a conceitos de linguagem orientada por objeto, criando (com efeito) um "banco de dados de objetos virtuais. Alguns mapeadores objeto-relacionais mantêm automaticamente as instâncias car- regadas na memória em sincronização constante com o banco de dados. Especificamente, após a construção de uma consulta de mapeamento obje- to-para-SQL, o primeiro dado retornado é copiado nos campos das instân- cias em questão, como qualquer pacote de mapeamento objeto-SQL. Uma vez lá, a instância tem que observar para ver se estes valores mudam e en- tão, cuidadosamente, reverter o processo para gravar os dados de volta no banco de dados. Hibernate 3.0 é uma solução de mapeamento objeto-relacional para Java e CLR (Jboss® Inc., Atlanta, Geórgia). Assim, Hibernate propor- ciona uma estrutura para mapear um modelo de domínio objeto-relacional para um banco de dados relacionai tradicional. Sua meta é auxiliar o desen- volvedor em algumas tarefas de programação relacionadas à persistência de dados comuns. Hibernate cuida do mapeamento desde de classes até tabe- las de banco de dados (e desde de tipos de dados orientados por objeto até tipos de dados SQL), assim como proporcionar consulta de dados e recursos de recuperação. Hibernate é instância cêntrica e constroi gráficos que repre- sentam as relações entre as instâncias.

Inversão de Controle e Princípio de inversão de Dependência

A Inversão de controle, também conhecida como IOC, é um princípio de programação orientada por objeto que pode ser usado para re- duzir o acoplamento (o grau até em que cada módulo de programa confia em cada outro módulo) inerente em programas de computador. IOC também é conhecida como o Princípio de Inversão de Dependência. Em IOC, uma classe X depende da classe Y se qualquer dos fatos a seguir se aplicar: 1) X tem um Y e o chama; 2) X é um Y; ou 3) X depende de alguma classe Z que depende de Y (transitividade). Vale a pena notar que X depender de Y não implica em Y depender de X; caso aconteça de ambos serem verdadeiros, ela é chamada uma dependência cíclica: X não pode ser usado sem Y e vi- ce-versa.

Na prática, se um objeto x (da ciasse X) chamar métodos de um objeto y (da classe Y), então a classe X depende de Y. A dependência é in- vertida introduzindo-se uma terceira classe, a saber, uma classe de interface

I que precisa conter todos os métodos que x puder chamar em y. Além do mais, Y tem que ser mudado tal que ele implemente a interface I. X e Y são ambos dependentes da interface I e a classe X não depende mais da classe Y (presumindo-se que x não instancia Y). Diz-se que esta eliminação da de- pendência da classe X de Y pela introdução de uma interface é uma inver- são de controle (ou uma inversão de dependência). Deve-se notar que Y pode depender de outras classes. Antes da transformação que tinha sido aplicada, X dependia de Y e, assim, X dependia indiretamente de todas as classes de que Y depende. Ao aplicar a inversão de controle, todas aquelas dependências indiretas foram quebradas também. A interface 1 que acabou de ser introduzida não depende de nada.

Spring Framework é uma estrutura de aplicativo de fonte aberta para a plataforma Java que usa IOC e inversão de dependência. Especifi- camente, central em Spring Framework é seu receptáculo de Inversão de Controle que proporciona um meio de configuração e gerenciamento de ob- 10 jetos Java. Este receptáculo também é conhecido como BeanFactory, Appli- cationContext ou Comutação resistiva. Exemplos das operações deste re- ceptáculo são: criar objetos, configurar objetos, chamar métodos de iniciali- zação e passar objetos para objetos de retorno de chamada registrados. Os objetos que são criados pelo receptáculo também são chamados Objetos 15 Orientados ou "Beans". Tipicamente, o receptáculo é configurado carregan- do-se arquivos XML que contêm definições "Bean", que fornecem toda a in- formação que é necessária para criar objetos. Uma vez que os objetos são criados e configurados sem criar condições de erro, eles se tornam disponí- veis para uso. Os objetos podem ser obtidos por meio de consulta de De- 20 pendência ou injeção de Dependência. A consulta de Dependência é um padrão em que um chamador pede ao objeto do receptáculo um objeto com um nome específico ou de um tipo específico. A injeção de dependência é um padrão em que o receptáculo passa objetos por nome para outros obje- tos, via construtores, propriedades ou métodos de fábrica. Assim, Spring 25 Framework é memória cêntrica e constroi gráficos que representam relações entre as instâncias.

Ferramentas Gráficas

Javadoc™ é uma ferramenta que analisa as declarações e co- mentários de documentação em um conjunto de arquivos de fonte Java e produz um conjunto correspem quente de paginas HTML que descrevem (por padrão) as classes protegidas e públicas, classes embutidas (mas não classes internas anônimas), interfaces, construtores, métodos e campos (Sun Microsystems®, Inc., Santa clara, CA). Javadoc pode ser usado para gerar a documentação API (Application Programming Interface) ou a docu- mentação de implementação para um conjunto de arquivos fontes. Javadoc é uma classe e método cêntrica e constrói gráficos que representam as rela- 5 ções entre a combinação de classes e seus métodos.

Um outro sistema para designar aplicativos de software inclui gráficos de objetos analisados por um interpretador para representar e re- produzir um aplicativo de computador. Este sistema utiliza classes de pro- gramação pré-gravadas armazenadas em bibliotecas de códigos, que po- 10 dem ser gravadas para seguir os padrões de projeto descritos em "Design Patterns'', por Gamma et al., Addison Wesley 1995, "Patterns in Java", Grand, Wiley Computer Publishing 1998 e/ou ferramentas de alto de Compu- ter Aided Software Engineering (CASE). Mais especificamente, algumas classes são baseadas no padrão comportamental Observer. As bibliotecas 15 de código pré-gravadas representam nós de estado do aplicativo, lógica de processamento e fluxo de dados do sistema entre diversos estados do apli- cativo (isto é, os elementos de dados pré-gravados do aplicativo), tal que um usuário não precisa gravar, editar ou compila código ao criar um aplicativo de software. Ao invés disso, um usuário edita manualmente um aplicativo de 20 software em uma interface Gráfica com o Usuário ao editar objetos visuais associados a um nó de estado de aplicativo atual, como dados dentro do nó de estado de aplicativo ou processos executados dentro do nó de estado de aplicativo. Então, com base nas mudanças feitas pelo usuário no nó de es- tado de aplicativo atual, o interpretador exibe o estado de aplicativo atualiza- 25 do para o usuário para o estado de aplicativo que acabou de ser editado. O sistema pode então sofrer transição ao longo de uma borda transicional defi- nida pelo usuário para um outro estado de aplicativo em que o usuário pode, opcionalmente, editar o próximo estado de aplicativo ou a borda transicional. Podem ser feitas mudanças em um gráfico para instâncias do gráfico que 30 são implementadas pelo interpretador, enquanto o aplicativo de software está rodando. Este sistema para projetar aplicativos de software pode incluir representações virtuais de um aplicativo de software em execução que pode se tornar "utilizável" com um controlador de aplicativo. Quando um usuário muda objetos visuais, que representam o aplicativo de software em execu- 5 ção, o controlador usa a entrada para induzir o interpretador a fazer a mu- dança no gráfico. Então, o controlador espera por mais mudanças. Adicio- nalmente, as representações visuais de tais aplicativos de software podem ser importadas ou exportadas como documentos XML que descrevem a re- presentação visuai do aplicativo e, deste modo, o aplicativo de software.

De modo a editar e/ou criar um aplicativo de software na forma

de um representação visuai de nós, bordas direcionadas e estados de apli- cativo, uma interface de programa aplicativo e um editor de aplicativo podem ser adicionalmente incluídos no sistema. Palavras chave e definições asso- ciadas, oriundas das bibliotecas de código pré-gravado, permitem que os 15 desenvolvedores do aplicativo definam manualmente um aplicativo de soft- ware, etapas de processamento, assim como a representação visual de um aplicativo de software ao proporcionar representações gráficas, dentro de um editor, de um aplicativo gráfico que se correlaciona intimamente à real estrutura do aplicativo. Um usuário define um novo aplicativo através de um 20 "assitente (wizard) de definição de aplicativo" que, após certos assuntos pre- liminares serem cumpridos, exibe o novo aplicativo como um componente gráfico dentro do espaço de trabalho do editor. Um usuário interage adicio- nalmente com um aplicativo ao fazer seleções de listas exibidas de possíveis componentes de aplicativo pré-criados e arrastar e liberar componentes no 25 espaço de trabalho usando mouse e teclado de um PC. Um usuário pode selecionar componentes e "arrastá-los" sobre componentes existentes. Quando um novo componente é "liberado" sobre um componente existente, o novo componente se torna um filho do componente existente dentro de um gráfico de aplicativo. As relações de componentes dentro do aplicativo são 30 definidas manualmente pelas seleções do usuário dentro do editor. Assim, uma estrutura em árvore, representando um aplicativo, é construída pelo usuário. Conforme o aplicativo é criado, um usuário pode selecionar um vi- sualizador de navegador de aplicativo para exibir uma visualização em árvo- re do aplicativo construído, tornando possível selecionar e editar qualquer componente do aplicativo. A interface do editor processa entradas do usuá- rio e seleções que incluem criar ou apagar elementos do aplicativo, atualizar 5 atributos de componente e atualizar propriedades de exibição de um aplica- tivo.

O sistema descrito acima, embora utilizando representações vi- suais de aplicativos de software, também pode ser usado como uma ferra- menta de programação visual para definir e atualizar bancos de dados rela- cionais. O sistema utiliza descrições XML de representação visual de aplica- tivos de software. Uma ferramenta analisa e interpreta as descrições XML para produzir esquemas de tabela de banco de dados relacionai equivalen- tes, assim como mudanças nos mesmos. Quando um dado é mudado dentro de uma representação visual de um aplicativo de software, uma descrição da mudança é armazenada junto com outras mudanças em um arquivo e então, é processado como um grupo. Um programa intermediário (um aplicativo Java que opera como sua própria ameaça) realiza transações entre a repre- sentação visual do aplicativo de software e o banco de dados relacionai. O aplicativo Java sonda (isto é, verifica) o registro de mudanças em nós da representação visual (isto é, dados no banco de dados) e, se houver qual- quer mudança, faz as mudanças no banco de dados. Assim, ao alterar os dados dentro da representação visual, o sistema atualiza um banco de da- dos. Um aplicativo similar fica entre a representação visual do aplicativo de software e o banco de dados para lidar com solicitações de dados do banco de dados.

Um outro sistema para analisar software é chamado um Code Tree Analyser (CTA). Um CTA analisa código de fonte estática gravado em uma linguagem de programação orientada por objeto. O CTA gera uma tabe- la de símbolos e uma árvore de chamada a partir do código de fonte estáti- 30 ca. Usando a tabela de símbolos, o CTA gera um diagrama de classe. Da mesma maneira, usando a árvore de chamada, o CTA gera um diagrama de seqüência. O diagrama de classe ilustra a relação entre uma classe selecio- nada pelo usuário e classes relacionadas à classe selecionada pelo usuário. O diagrama de seqüência ilustra a seqüência em que diferentes métodos são chamados. Usando tanto o diagrama de classe quando o diagrama de seqüência, o CTA gera um artefato de projeto representativo do código de 5 fonte estática. Quando o usuário modifica o artefato de projeto, o CTA identi- fica, usando o diagrama de seqüência, as partes do código fonte que sofre- ram impacto. O artefato de projeto é usado para manutenção de código e/ou engenharia reversa do código fonte estático.

Breve Sumário

Descreve-se um método e aparelho para programação e execu-

ção orientada por gráfico. De acordo com um aspecto da invenção, é pro- porcionado um runtime que interpreta declarações de dependência de pro- dutor para métodos. As declarações de dependência do produtor identificam, no momento da execução, um conjunto de zero ou mais produtores, em que 15 um produtor é uma construção instanciável por runtime que inclui ao menos uma instância e um método associado àquela instância. O runtime gera e executa automaticamente em resposta à recepção de uma designação de um produtor de interesse a ser instanciado, cujo método tem uma declara- ção de dependência do produtor, um gráfico de produtor. O gráfico de produ- 20 tor inclui, inicialmente, o produtor de interesse e é gerado a partir do produtor de interesse para produtores fonte através de instanciação de produtores com base nas declarações de dependência do produtor dos métodos dos produtores já no gráfico produtor. O runtime dá seqüência à execução dos produtores no gráfico produtor, conforme é indicado pelo gráfico produtor.

Breve Descrição dos Desenhos

A invenção pode ser melhor entendida fazendo-se referência à descrição a seguir e desenhos anexos que são usados para ilustrar modali- dades da invenção. Nos desenhos:

Figura 1A é um diagrama de bloco que ilustra a relação de uma declaração de dependência de produtor para um método de uma classe no código fonte orientado por objeto para um produtor que inclui a classe, uma dada instância daquela classe e um método daquela classe, de acordo com uma modalidade da invenção.

Figura 1B ilustra relações exemplificativas entre o produtor 110A e o produtor pai 114A.1, de acordo com uma modalidade da invenção.

Figura 1C ilustra relações exemplificativas entre o produtor 11OA e o produtor filho 112A.1, de acordo com uma modalidade da invenção.

Figura 1D ilustra algumas combinações exemplificativas adicio- nais de relações de produtores pais 114 e produtores filhos 112 com o pro- dutor 110A, de acordo com uma modalidade da invenção.

Figura 1E ilustra que instâncias diferentes da mesma classe po- dem ter produtores baseados no mesmo métodos e/ou em métodos diferen- tes, de acordo com uma modalidade da invenção.

Figura 2 é um diagrama de bloco que ilustra a capacidade de reutilização de um runtime com suporte de programação orientada por gráfi- co de produtor, de acordo com uma modalidade da invenção.

Figura 3A é um diagrama de bloco que ilustra um runtime com

suporte de programação orientada por gráfico de produtor, de acordo com uma modalidade da invenção.

Figura 3B é um diagrama de bloco que ilustra um runtime com suporte de programação orientada por gráfico produtor que também suporta execução incrementai e saídas sobregravadas de produtor, de acordo com uma modalidade da invenção.

Figura 4A é um diagrama de bloco que ilustra a descoberta e a construção de um gráfico produtor exemplificativo de acordo com uma mo- dalidade da invenção.

Figura 4B é um diagrama de bloco que ilustra a execução inicial

do gráfico produtor da Figura 4A, de acordo com uma modalidade da inven- ção.

Figura 4C é um diagrama de bloco que ilustra a execução in- crementai do gráfico produtor da Figura 4B de acordo com uma modalidade da invenção.

Figura 4D é um diagrama de bloco que ilustra a execução in- crementai do gráfico produtor da Figura 4B após o produtor dependente 2 ter sido sobregravado de acordo com uma modalidade da invenção.

Figura 4E é um diagrama de bloco que ilustra a execução in- crementai do gráfico produtor da Figura 4B após o produtor dependente 2 ter sido sobregravado e o produtor de fonte independente 3 ter sido modificado, de acordo com uma modalidade da invenção.

Figura 5A é um diagrama de bloco que ilustra a descoberta e a construção de um gráfico produtor exemplificativo que inclui uma dependên- cia não resolvida, de acordo com uma modalidade da invenção.

Figura 5B é um diagrama de bloco que ilustra a execução inicial do gráfico produtor da Figura 5A e a resolução da dependência não solucio- nada, de acordo com uma modalidade da invenção.

Figura 5C é um diagrama de bloco que ilustra a execução inicial do gráfico produtor da Figura 5A e/ou a re-execução do gráfico produtor da Figura 5B, de acordo com uma modalidade da invenção.

Figura 5D é um diagrama de bloco que ilustra a execução inicial

do gráfico produtor da Figura 5A e/ou a re-execução do gráfico produtor das Figuras 5B ou 5C, de acordo com uma modalidade da invenção.

Figura 6 é um diagrama de fluxo que ilustra um fluxo de execu- ção lógica de um cliente de runtime e sua relação com um runtime com su- porte de programação orientada por gráfico produtor, de acordo com uma modalidade da invenção.

Figura 7A ilustra pseudo-código de uma declaração de depen- dência de produtor para um método que utiliza dependências declaradas de atalho, de acordo com uma modalidade da invenção.

Figura 7B é um diagrama de bloco de produtores exemplificati-

vo s de acordo com uma modalidade da invenção.

Figura 7C ilustra pseudo-código de uma declaração de depen- dência de produtor para um método que utiliza uma dependência declarada sem atalho e ilustra um diagrama de bloco de produtores exemplificativos de acordo com uma modalidade da invenção.

Figura 7D ilustra pseudo-código de uma declaração de depen- dência de produtor para um método que utiliza uma dependência declarada sem atalho de acordo com uma modalidade da invenção.

Figura 7E é um diagrama de bloco de produtores exemplificati- vos de acordo com uma modalidade da invenção.

Figura 7F e'um diagrama de bloco de dependências exemplifi- cativas através do uso de UpwardDependency com um produtor de determi- nação de dependência, de acordo com uma modalidade da invenção.

Figura 7G é um diagrama de bloco de possíveis dependências exemplificativas através do uso de WeaklyConstrainedDependency com um produtor de determinação de dependência, de acordo com uma modalidade da invenção.

Figura 7H ilustra gráficos produtores exemplificativos de produ- tores padrão, de acordo com uma modalidade da invenção.

Figura 71 ilustra um exemplo de dependências de produtor e produtores de determinação de dependência para descobrir, solucionar e construir o gráfico produtor da Figura 7H.

Figura 8A é um diagrama de bloco que ilustra uma primeira es- trutura exemplificativa dentro da qual os aplicativos são fornecidos a usuá- rios finais, de acordo com uma modalidade da invenção.

Figura 8B é um diagrama de bloco que ilustra uma segunda es- trutura exemplificativa dentro da qual são proporcionados aplicativos a usuá- rios finais, de acordo com uma modalidade da invenção.

Figura 8C ilustra uma tela exemplificativa e utilização de seleção de célula livre com o módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840, de acordo com uma moda- Iidade da invenção.

Figura 8D ilustra uma outra tela exemplificativa e utilização de seleção de célula livre com o módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840, de acordo com uma modalidade da invenção.

Figura 8E ilustra uma tela exemplificativa e utilização da criação

de tabela com o módulo de interface gráfica com o usuário de saída de pro- dutor interativa configurável 840, de acordo com uma modalidade da inven- ção.

Figura 8F ilustra uma outra tela exemplificativa e utilização da criação de tabela com o módulo de interface gráfica com o usuário com Ia- yout de saída de produtor interativa configurável 840, de acordo com uma modalidade da invenção.

Figura 9A é um diagrama de bloco que ilustra um primeiro es- quema para distribuir um runtime com suporte de programação orientada por gráfico produtor, de acordo com uma modalidade da invenção.

Figura 9B é um diagrama de bloco que ilustra um segunda es- quema para distribuir um runtime com suporte de programação orientada por gráfico de produtor, de acordo com uma modalidade da invenção.

Figura 9C é um diagrama de bloco que ilustra um terceiro es- quema para distribuir um runtime com suporte de programação orientada por gráfico produtor, de acordo com uma modalidade da invenção.

Figura 10 é um diagrama de bloco de uma implementação e-

xemplificativa, de acordo com uma modalidade da invenção.

Figura 11A é um diagrama de bloco de um exemplo da estrutura de rastreamento de classe 1092 da Figura 10, de acordo com uma modali- dade da invenção.

Figura 11B é um diagrama de bloco de um exemplo da estrutura

de rastreamento de instância 1065 da Figura 10, de acordo com uma moda- lidade da invenção.

Figura 11C é um diagrama de bloco de um exemplo da estrutura de gráfico(s) produtor(es) 1060 da Figura 10, de acordo com uma modalida- de da invenção.

Figura 11D é um diagrama de bloco de um exemplo da estrutura de rastreamento de método 1058 da Figura 10, de acordo com uma modali- dade da invenção.

Figura 12 é um diagrama de bloco que ilustra detalhes adicio- nais da Figura 10 para suportar contingente e dependências de produtor di- nâmicas do tipo assinatura, de acordo com uma modalidade da invenção.

Figura 13A ilustra pseudo-código de declarações de dependên- cia de produtor para métodos usando uma dependência declarada de não- atalho, não-dinâmica (não-contingente, não-assinatura), de acordo com uma modalidade da invenção.

Figura 13B é um diagrama de bloco de produtores que ilustram uma dependência de produtor declarada sem atalho, não-dinâmica (não- contingente, não-assinatura), de acordo com uma modalidade da invenção.

Figura 13C ilustra pseudo-código de declarações de dependên- cia de produtor para métodos que utilizam uma dependência declarada sem atalho, contingente, de não-assinatura, de acordo com uma modalidade da invenção.

Figura 13D é um diagrama de bloco de produtores ilustrando uma dependência de produtor de não-assinatura, contingente, declarada, sem atalho, de acordo com uma modalidade da invenção.

Figura 13E ilustra pseudo-código de declarações de dependên- cia de produtor para métodos usando tanto uma dependência de produtor de não-assinatura, contingente, declarada, sem atalho, quanto uma dependên- cia de produtor de não-assinatura, contingente, declarada com atalho, de acordo com uma modalidade da invenção.

Figura 13F é um diagrama de bloco de produtores ilustrando uma dependência de produtor de não-assinatura, contingente, declarada sem atalho e uma dependência de produtor de não-assinatura, contingente, declarada com atalho, de acordo com uma modalidade da invenção.

Figura 13G ilustra pseudo-código de declarações de dependên- cia de produtor para métodos usando uma dependência de produtor de não- assinatura, contingente, declarada com atalho e uma dependência de produ- tor de não-assinatura, não-contingente, declarada com atalho, de acordo com uma modalidade da invenção.

Figura 13H é um diagrama de bloco de produtores ilustrando uma dependência de produtor de não-assinatura, contingente, declarada com atalho, exemplificativa e uma dependência de produtor de não- assinatura, não-contingente, declarada com atalho, de acordo com uma mo- dalidade da invenção. Figura 131 ilustra pseudo-código de declarações de dependência de produtor para métodos que usam uma dependência de produtor (não- assinatura, não-contingente), não-dinâmica, declarada com atalho, de acor- do com uma modalidade da invenção.

Figura 13J é um diagrama de bloco de produtores ilustrando

uma dependência de produtor não-dinâmica, declarada com atalho, de acor- do com uma modalidade da invenção.

Figura 14A é um diagrama de bloco de um exemplo do registro de assinatura 1250 da Figura 12, de acordo com uma modalidade da inven- ção.

Figura 14B é um diagrama de bloco de produtores exemplificati- vos ilustrando uma dependência de produtor de assinatura absorvedora, não-contingente, de acordo com uma modalidade da invenção.

Figura 14C é um diagrama de bloco de produtores exemplificati- vos ilustrando uma dependência de produtor de assinatura adesiva, não- contingente, de acordo com uma modalidade da invenção.

Figura 14D ilustra a escolha de um produtor parente com base em um produtor de determinação de dependência de pai criado por uma as- sinatura adesiva, de acordo com uma modalidade da invenção.

Figura 14E ilustra a escolha de um produtor pai com base em

um produtor de determinação de dependência pai criado por um produtor de determinação de dependência filho, produtor de determinação de dependên- cia filho este que está ligado por uma dependência de sequenciamento, de acordo com uma modalidade da invenção.

Figura 15 é um diagrama de fluxo para instanciar novas instân-

cias, de acordo com uma modalidade da invenção.

Figura 16 é um diagrama de fluxo para instanciar novos produto- res e não sobrepor produtores, de acordo com uma modalidade da invenção.

Figura 17 é um diagrama de fluxo para o bloco 1650 da Figura 16, de acordo com uma modalidade da invenção.

Figura 18 é um diagrama de fluxo para o bloco 1745 da Figura 17, de acordo com uma modalidade da invenção. Figura 19 é um diagrama de fluxo para o bloco 1630 da Figura 16, de acordo com uma modalidade da invenção.

Figura 20 é um diagrama de fluxo para os blocos 1635 e 1670 da Figura 16, de acordo com uma modalidade da invenção.

Figura 21 é um diagrama de fluxo para sobregravar produtores, de acordo com uma modalidade da invenção.

Figura 22A é uma parte de um diagrama de fluxo para execução do(s) gráfico(s) de produtor atual(is) , de acordo com uma modalidade da invenção.

Figura 22B é uma outra parte de um diagrama de fluxo para e- xecução do(s) gráfico(s) de produtor atual, de acordo com uma modalidade da invenção.

Figura 23 é um diagrama de fluxo para o bloco 2205 da Figura 22, de acordo com uma modalidade da invenção.

Figura 24 é um diagrama de fluxo para o bloco 2225 da Figura 22, de acordo com uma modalidade da invenção.

Figura 25 é um diagrama de fluxo para o bloco 2260 da Figura 22, de acordo com uma modalidade da invenção.

Descrição Detalhada

Na descrição a seguir, inúmeros detalhes específicos, como im- plementações lógicas, opcodes, meios para especificar operandos, imple- mentações de particionamento de recurso/compartilhamento/dupli-cação, tipos e inter-relações de componentes do sistema e escolhas de particiona- mento lógico/integração, são fornecidos de modo a proporcionarem uma compreensão mais completa da invenção. No entanto, será apreciado, por alguém que seja versado na técnica, que a invenção pode ser praticada sem tais detalhes específicos. Em outros casos, estruturas de controle, estruturas de dados e seqüências de instrução de software completas não são mostra- das em detalhes para não obscurecer a invenção. Aqueles que têm conhe- cimento comum da técnica, com as descrições inclusas, serão capazes de implementar funcionalidade apropriada sem experimentação indevida.

A menos que seja especificado o contrário, as linhas pontilhadas nas figuras (com a exceção das linhas de divisão pontilhadas) são usadas para representar itens opcionais nas figuras. No entanto, não se deve pre- sumir que todos os itens opcionais são mostrados usando linhas pontilha- das, mas ao invés disso, aquelas mostradas em linhas pontilhadas foram 5 escolhidas por uma série de razões (por exemplo, elas podem ser facilmente mostradas, para proporcionar maior clareza, etc.)

As referências no relatório descritivo a "uma modalidade", "uma modalidade exemplificativa", etc., indicam que a modalidade descrita pode incluir uma característica, estrutura, ou item particular, mas nem toda moda- 10 Iidade pode incluir necessariamente a característica, estrutura ou item parti- cular. Além do mais, tais frases não estão se referindo necessariamente à mesma modalidade. Adicionalmente, quando um item, estrutura ou caracte- rística é descrita em conjunto com uma modalidade, ele é submetido ao que está dentro do conhecimento de alguém que seja versado na técnica para 15 afetar tal item, estrutura ou característica em conjunto com outras modalida- des, que estejam explicitamente descritas ou não.

Na descrição e reivindicações a seguir, os termos "acoplado" e "conectado", junto com seus derivados, podem ser usados. Deve-se enten- der que estes termos não devem ser entendidos como sinônimos um do ou- 20 tro. Ao invés disso, em modalidades particulares, "conectado" pode ser usa- do para indicar que dois ou mais elementos estão em contato direto um com o outro. "Acoplado" pode significar que dois ou mais elementos estão em contato direto. No entanto, "acoplado" também pode significar que dois ou mais elementos não estão em contato direto um com o outro, mas ainda as- 25 sim, cooperarem ou interagirem um com o outro.

Em alguns casos, as operações de diagramas de fluxo são des- critas com referência às modalidades exemplificativas dos outros diagramas de bloco. No entanto, deve-se entender que as operações dos diagramas de fluxo podem ser realizadas por modalidades da invenção que não aquelas 30 discutidas com referência a estes outros diagramas de bloco e que as moda- lidades da invenção discutidas com referência a estes outros diagramas de bloco podem realizar operações diferentes daquelas discutidas com referên- * cia aos diagramas de fluxo.

As técnicas mostradas nas figuras podem ser implementadas com o uso de código e dados armazenados e executados em um ou mais computadores. Tais computadores armazenam e comunicam (internamente 5 e com outros computadores em uma rede) código e dados usando mídia iegível por máquina, como mídia de armazenamento em máquina (por e- xemplo, discos magnéticos; discos ópticos; memória de acesso aleatório; memória de leitura apenas; dispositivos de memória instantânea) e mídia de comunicação de máquina (por exemplo, sinais elétricos, ópticos, acústicos 10 ou outra forma de sinais propagados - como ondas portadoras, sinais infra- vermelhos, sinais digitais, etc), além disso, tais computadores tipicamente incluem um conjunto de um ou mais processadores acoplados a um ou mais outros componentes, como um dispositivo de armazenamento, uma série de dispositivos de entrada/saída de usuário (por exemplo, teclado e um visor) e 15 uma conexão de rede. O acoplamento do conjunto de processadores e ou- tros componentes é tipicamente através de um ou mais barramentos e pon- tes (também denominados controladores de barramento). O dispositivo de armazenamento e tráfego de rede representam, respectivamente, uma ou mais mídias de armazenamento em máquina e mídia de comunicação de -20 máquina. Assim, o dispositivo de armazenamento de um dado sistema com- putacional armazena, tipicamente, código e dados para execução no conjun- to de um ou mais processadores daquele computador. Obviamente, uma ou mais partes de uma modalidade da invenção podem ser implementadas u- sando diferentes combinações de software, firmware e/ou hardware.

Visão Geral

De acordo com uma aspecto da invenção, um produtor é ao menos uma instância específica (ou objeto) e um método específico, tal que se o produtor for executado durante o runtime, o método específico é execu- tado na instância específica. Assim, um dado produtor é instanciado a partir 30 de uma dada instância e um dado método associado àquela instância. Como as classes, instâncias e métodos, os produtores são elementos ou constru- ções básicas manipuladas pelo runtime. Assim, a instanciação de um produ- tor é interpretada e rastreada pelo runtime e, assim, o runtime rastreia a combinação de instâncias e métodos representados pelos produtores. Em outras palavras, um produtor é uma construção instanciável por runtime que é rastreada pelo runtime, que é executada pelo runtime e que inclui ao me- 5 nos uma instância e um método associado àquela instância, tal que a exe- cução de tempos de execução do produtor resulta no método do produtor ser executado na instância do produtor. Além disso, o método de um produ- tor tem associado a ele uma declaração de dependência de produtor que identifica, com um conjunto de zero ou mais dependências de produtor, um 10 conjunto de zero ou mais produtores para o dado produtor. Especificamente, as dependências de produtor são declaradas para métodos usando declara- ções de dependência de produtor, sendo que a declaração de dependência de produtor para um dado método pode incluir zero ou mais dependências de produtor e cada dependência de produtor identifica um conjunto de zero 15 ou mais produtores. Assim, as declarações de dependência de produtor e as dependências de produtor que elas definem são interpretadas e rastreadas pelo runtime e, assim, o runtime rastreia as relações entre os produtores in- dicadas pelas declarações de dependência de produtor.

Quando um dado produtor for dependente de um conjunto de um ou mais outros produtores, o runtime assegurará a execução do conjunto de outros produtores antes do dado produtor. Assim, as declarações de de- pendência de produtor representam as relações de execução entre os pro- dutores, enquanto os produtores representam operações a serem executa- das (métodos) e instâncias. Embora em algumas modalidades da invenção se permita que as dependências de produtores pais com relação a produto- res filho sejam declaradas na declaração de dependência de produtor asso- ciada com o método do produtor pai (a declaração de dependência de pro- dutor do produtor pai identifica qualquer produtor filho - referido aqui como declarado descendentemente), outras modalidades da invenção também permitem que as dependências sejam declaradas na declaração de depen- dência de produtor associada ao(s) método(s) de produtor(es) filho(s) (a de- claração de dependência de produtor do produtor filho identifica um ou mais * produtor pai - referido aqui como declarado ascendentemente).

Em modalidades diferentes da invenção, um produtor identifica coisas adicionais. Por exemplo, enquanto em algumas modalidades da in- venção um produtor é ao menos uma instância e método associado àquela 5 instância, em outras modalidades da invenção um produtor é uma classe, uma interferência daquela classe e um método associado àquela instância (por exemplo, um produtor pode incluir diretamente uma classe, instância e método; um produtor pode incluir diretamente uma instância e um método, enquanto identifica indiretamente uma classe daquela instância através de 10 uma referência (por exemplo, uma referência na instância)). Embora a in- venção possa ser usada no contexto de código gravado em diferentes lin- guagens de programação (por exemplo, código orientado por objeto gravado em uma linguagem orientada por objeto reflexiva; código orientado por obje- to gravado em uma linguagem baseada em objeto reflexiva; código gravado 15 em uma linguagem baseada em objeto não-reflexiva, orientada por objeto não-reflexiva, procedural e transformada em código de linguagem orientada por objeto reflexiva), modalidades da invenção serão descritas, à guisa de exemplo e não de limitação, com referência a linguagens de programação orientada por objeto reflexivas e com referência a produtores que incluem

> 20 diretamente classes, instâncias e métodos. Além disso, embora em uma modalidade da invenção o método de produtor seja um método de instância (um método que pode usar campos de instância em adição a qualquer en- trada recebida como argumento), modalidades alternativas da invenção também podem ou alternativamente, suportam, o método de um produtor 25 sendo um método de classe (métodos que recebem todas as entradas como argumentos e/ou utiliza variáveis independentes de instância) (em que o mé- todo de um produtor é um método de instância, a instância daquele produtor é uma instância de uma classe; enquanto, quando o método de um produtor for um método de classe, a instância daquele produtor é uma instância de 30 meta-classe que representa a classe).

A Figura 1A é um diagrama de bloco que ilustra a relação de uma declaração de dependência de produtor para um método de uma classe em codigo fonte orientado por objeto e um produtor que inclui a classe, uma dada instância daquela classe e um método daquela classe, de acordo com uma modalidade da invenção. Na Figura 1A, o código fonte orientado por objeto 100 é mostrado incluindo uma classe 102 que, por sua vez, inclui um 5 método 104 e uma declaração de dependência de produtor 106 para o mé- todo 104. Obviamente, a classe 102 inclui tipicamente um ou mais campos (não mostrados) e métodos adicionais (não mostrados). Além disso, o códi- go fonte orientado por objeto 100 inclui, tipicamente, classes adicionais.

Durante o runtime, uma instância 108 da classe 102 é instancia- da. A instância 108 inclui os dados dos campos da classe 102. Além disso, um produtor 110 é instanciado, em que o produtor 110 identifica a classe 102, a instância 108 da classe 102 (que tem associado a ela o método 104 da classe 102) e o método 104 da classe 102. a declaração de dependência de produtor 106 identifica para o runtime um conjunto de zero ou mais pro- dutores 112 (referidos como produtores filho do produtor 110) que precisam ser executados antes da execução do produtor 110. Em outras palavras, o produtor 110 depende do conjunto de zero ou mais produtores 112. Em adi- ção a ou ao invés de consumir saídas do conjunto de produtor 112, o produ- tor 110 pode consumir dados da instância 108. Além disso, o produtor 110 fornece ao menos uma saída, saída esta que pode ser interna à instância 108 (e assim, modificar o dado da instância 108) e/ou pode ser externa; de uma maneira ou de outra, a saída do produtor 110 pode ser consumida por um conjunto de zero ou mais outros produtores 114 (referidos como produto- res pais do produtor 110)). Conforme é indicado anteriormente, e descrito adiante com mais detalhes, a declaração de dependência de produtor 106, em algumas modalidades da invenção, também pode identificar para o run- time, zero ou mais dos produtores 114.

Deve-se entender que as entradas e saídas de produtores são baseadas nas entradas e saídas dos métodos nos quais aqueles produtores são baseados. Como tal, estas entradas e saídas podem representar múlti- plos parâmetros tendo uma variedade de estruturas de dados.

A declaração de dependência de produtor para um dado método identifica no runtime o conjunto de zero ou mais produtores a serem instan- ciados e executados. À guisa de exemplo, quando uma declaração de de- pendência de produtor (por exemplo, declaração de dependência de produ- tor 106) para um dado método (por exemplo, método 104) identifica uma 5 dependência de produtor em um dado produtor (sendo que este dado produ- tor identifica uma primeira classe, uma primeira instância daquela classe e um primeiro método daquela primeira classe) (por exemplo, um do conjunto de produtores 112), então a declaração de dependência de produtor do dado método identifica para o runtime que a primeira instância deve ser instancia- 10 da (se não já) e que o primeiro método deve ser usado para instanciar o da- do produtor para a primeira instância (nestes exemplos, primeiro não signifi- ca localização ou ordem).

Em operação, quando, durante o runtime, um dado conjunto de um ou mais produtores é designado como sendo de interesse e tem depen- dências de produtor declaradas para ele, o runtime: 1) gera automaticamen- te (descobre, constrói e, opcionalmente, soluciona) um conjunto de um ou mais gráficos, que podem ter múltiplos níveis e ter uma série de formatos (por exemplo, corrente, árvore), a partir do dado conjunto de produtores de- signado com sendo de interesse até os produtores fonte, com base nas de- clarações de dependência de produtor; e 2) sequencia a execução de produ- tores do conjunto de gráficos para gerar a(s) saída(s) do dado conjunto de produtores designados como sendo de interesse. Assim, o runtime usa as declaração de dependência de produtor para determinar que métodos com que argumentos executar em que instâncias e quando, para fins de sincroni- zação.

Assim, as dependências de produtor representam o sequencia- mento de execução de produtores para o runtime. No entanto, em adição a indicar o sequenciamento de execução, as dependências de produtor podem representar diferentes relações entre entrada e saída em diferentes modali- 30 dades da invenção. Por exemplo, diferentes modalidades da invenção po- dem suportar uma ou mais das dependências de produtor de argumento, dependências de produtor de campo e sequenciamento apenas de depen- dências de produtor (sequenciamento apenas de dependências de produtor é referido aqui com as dependências de produtor). Embora cada uma das dependências de produtor de argumento, dependências de produtor de campo e dependências de produtor de sequenciamento represente relações 5 de sequenciamento de execução entre produtores, argumento e dependên- cias de produtor de campo representam adicionalmente dados dos quais o runtime está consciente. Especificamente, uma dependência de produtor de argumento faz com que o runtime mapeie a saída de um produtor filho como um parâmetro de entrada em um produtor pai, enquanto que uma depen- 10 dência de produtor de campo indica o uso de um campo de uma instância. A despeito da relação entre entrada e saída representada por uma dependên- cia de produtor, o usuário adequado de dependências de produtor assegura que os produtores que acessam informações sejam sequenciados após os produtores que causam impacto sobre aquela informação.

As dependências de sequenciamento podem ser usadas para

uma série de finalidades, inclusive assegurar a ordem de execução entre os produtores que modificam dados de uma maneira que o runtime não está consciente e os produtores que consomem aqueles dados (um produtor filho pode gravar suas saídas de uma maneira que requeira que o método do 20 produtor pai inclua código para acessar aquela saída (por exemplo, um mé- todo que cause impacto sobre o ambiente ao afetar uma saída que não é a saída de produtor regular e, como tal, não é detectada pelo runtime - como um método que define uma variável global, que define um campo em uma instância que não é a saída do produtor, que causa impacto sobre uma fonte 25 de dados externa, etc.)). Assim, uma dependência de sequenciamento refle- te uma dependência de um produtor pai de um produtor filho, mas requer saídas que têm que ser proporcionadas, se existirem, de um para que o ou- tro ocorra através da gravação de código (por exemplo, código no método do produtor filho para gravar uma saida para um dado mecanismo (tal como 30 definir uma variável global, impactar uma fonte de dados externa, definir um campo de uma instância que não seja a saída de produtor, etc.) e código no método do produtor pai para Ier aquela saída do dado mecanismo). Deste modo, as dependências de sequenciamento permitem que o runtime sincro- nize a execução de qualquer produtor pai que se fie em uma saída que o runtime não pode detectar.

Em uma modalidade da invenção, a declaração de dependência 5 de produtor para um dado método identifica apenas dependências diretas em produtores (por exemplo, descendentes diretos (filhos), em contraste com descendentes indiretos (netos, bisnetos, etc.)). Em tal modalidade, cada declaração de dependência de produtor proporciona apenas uma única filei- ra ou camada de produtores cujas saídas possam ser usadas diretamente 10 por um produtor instanciado a partir do dado método; deixar a descober- ta/construção/resolução de camadas adicionais do(s) gráfico(s) do produtor para o processamento do runtime de outras declarações de dependência de produtor.

Chaves Exemplificativas Um produtor pode ser visualizado como um conjunto de múlti-

plos identificadores, um identificador para cada nível adicional de granulari- dade especificada (ciasse, instância, método, etc.). Além disso, algumas modalidades da invenção implementam cada identificador como uma chave separada, enquanto outras modalidades têm certos identificadores que com- 20 partilham uma chave. À guisa de exemplo, algumas modalidades da inven- ção implementam um produtor como um trio de classe, instância e método e implementam chaves, tal que cada parte do trio seja identificada por uma chave separada (uma chave de classe, uma chave de instância e chave de método) e o produtor seja identificado pela combinação da chave de classe, 25 chave de instância e chave de método (a chave do produtor).

As modalidades da invenção que utilizam chaves podem variar na unícidade das chaves usadas. Por exemplo, em uma modalidade da in- venção, cada chave de classe é única, cada chave de instância é única em todas as instâncias de todas as classes e cada chave de método é única em 30 todos os métodos de todas as classes. Como um outro exemplo, em outras modalidades da invenção, cada classe tem uma chave única, cada instância de uma dada classe tem uma chave única (em todas as instâncias de cias- se) e cada método de uma classe tem uma chave única (em todos os méto- dos de classe); mas instâncias de diferentes classes podem ter a mesma chave de instância e métodos de diferentes classes podem ter a mesma chave de método; esta última abordagem será usada no restante do docu- 5 mento à guisa de exemplo e não de limitação. Por exemplo, assuma que uma primeira classe inclua métodos e tenha uma chave para cada um des- tes métodos que é único dentro da primeira classe, então as instâncias desta classe (que terão, cada uma, uma chave única uma para a outra) têm as mesmas chaves de método associadas a eles. Um outro exemplo, assuma 10 que uma segunda classe diferente inclui métodos (sejam alguns, todos ou nenhum igual aos métodos da primeira classe) que têm as mesmas chaves de método que aquelas usadas para a primeira classe; como tal, uma ins- tância desta classe diferente pode ter associadas a ela as mesmas chaves de método associadas a uma instância da primeira classe.

O uso de chaves permite uma série de itens, incluindo: 1) o ras-

treamento de cada entidade identificada por identificadores de um produtor (por exemplo, o rastreamento de cada classe, instância e método); 2) diver- sos produtores pais (que não sabem de sua existência mútua) para conectar ao mesmo produtor filho com base em suas declarações de dependência de 20 produtor (que especificam dependências de produtor usando as chaves de produtor); etc. Em uma modalidade da invenção, a chave de instância é uma instância de uma classe (InstanceKey) que retém dois elementos: uma natu- reza de chave de instância que indica se o identificador chave é uma refe- rência à instância ou a outro objeto (como uma cadeia) e um identificador de 25 chave que pode er uma referência para a instância ou um outro objeto (como uma corrente). O armazenamento de uma referência de instância na chave de instância isenta o programador de inventar um nome para identificar es- tas instâncias.

Relações Exemplificativas No contexto da discussão acima no que se refere a um produtor

sendo visualizado como um conjunto de múltiplos identificadores (com um identificador para cada nível adicional de granularidade especificada), em uma modalidade da invenção as diversas relações suportadas entre um pro- dutor e seus filhos e pais são aquelas em que ao menos um identificador é diferente entre um produtor e seu conjunto de zero ou mais produtores pais e um tal identificador é diferente entre um produtor e cada um de seu conjun- to de zero ou mais produtores filhos. Para proporcionar algumas relações exemplificativas, assuma que um primeiro produtor é instanciado, em que o primeiro produtor é uma primeira instância de uma primeira classe e um pri- meiro método daquela primeira classe e assuma que a declaração de de- pendência de produtor para aquele primeiro método identifica, no runtime, um segundo produtor como um filho, então o segundo produtor pode ser: 1) a primeira instância da primeira classe e um segundo método daquela pri- meira classe; 2) uma segunda instância da primeira classe e um segundo método daquela primeira classe; 3) uma segunda instância da primeira clas- se e o primeiro método da primeira classe; ou 4) uma instância de uma se- gunda classe e um método daquela segunda classe. Em tal caso, o primeiro produtor é dependente do segundo produtor - representando assim uma relação entre entrada e saída do primeiro produtor e segundo produtor. Di- versas relações e combinações destas relações são descritas abaixo para uma modalidade da invenção que utiliza uma linguagem orientada por objeto ^ 20 e em que um produtor identifica ao menos uma classe, instância e método.

As Figuras 1B-1D ilustram relações exemplificativas entre um dado produtor, seu conjunto de produtores pais e seu conjunto de produtores filhos, de acordo com uma modalidade da invenção. As Figuras 1B-1D mos- tram, cada uma, o seguinte: 1) uma definição de classe 102A que inclui mé- 25 todos 104A-C e declarações de dependência de produtor 106A-C para cada um daqueles métodos, respectivamente; 2) uma definição de classe 102B incluindo métodos 104D-E e declarações de dependência de produtor 106D- E para cada um daqueles métodos, respectivamente; 3) uma definição de classe 102C que inclui o método 104F e declaração de dependência de pro- 30 dutor 106F para aquele método; 4)uma instância 108A da classe 102A; 5) um produtor 11OA que identifica a classe 102A, a instância 108A e o método 104A; e 6) um produtor 112A.1 e um produtor 114A.1, representando res- pectivamente um do conjunto de produtores 112 e 114. As linhas pontilhadas com letras sobre elas são usadas nas Figuras 1B-1D para ilustrar as rela- ções exemplificativas. Assim, a coleção de linhas pontilhadas com um A dentro da caixa representa uma relação. As relações na Figura 1B podem ser combinadas com as relações na Figura 1C; como tal, estas combinações representam combinações de relações entre os produtores pais 114A e pro- dutores filhos 112A para o produtor 11OA. Adicionalmente, a Figura 1D ilus- tra algumas combinações exemplificativas adicionais de relações entre pro- dutores pais 114A e produtores filhos 112A e produtor 110A.

A Figura 1B ilustra relações exemplificativas entre o produtor 11OA e o produtor pai 114A.1 de acordo com uma modalidade da invenção. A Figura 1B inclui, adicionalmente, uma instância de 108B. O conjunto de produtores 114 é identificado por outras declarações de dependência de produtor de diferente(s) método(s) da mesma classe, instâncias diferentes da mesma classe e/ou método(s) de uma classe diferente; e assim, cada um do conjunto de produtores 114 pode ser: 1) da mesma instância que o pro- dutor 11OA (instância 108A de classe 102A) e um método diferente associa- do àquela instância (ilustrado pela letra A nas linhas pontilhadas desde a instância 108A até o produtor 114A.1 e desde o método 104B até o produtor 114A.1); 2) de uma instância diferente da classe 102A e um método diferen- te associado àquela instância (ilustrado pela letra B nas linhas pontilhadas desde a classe 102A até a instância 108B, desde a instância 108B até o produtor 114A.1 e desde o método 104B até o produtor 114A.1); 3) de uma instância de uma classe diferente e um método associado àquela instância (ilustrado pela letra C nas linhas pontilhadas desde a classe 102B até a ins- tância 108B, desde a instância 108B até o produtor 114A.1, e desde o méto- do 104D até o produtor 114A.1); ou 4) de uma instância diferente de classe 102A (do que a instância 108A) e o mesmo método (método 104A) daquela instância (por exemplo, com uma dependência contingente - descrita aqui posteriormente) (ilustrado pela letra D nas linhas pontilhadas desde a classe 102A até a instância 108B, desde a instância 108B até o produtor 114A.1 e desde o método 104A até o produtor 114A.1); adicionalmente, quando existi- I 32

rem múltiplos produtores no conjunto de produtores 114, os próprios produ- tores 114 podem ser parte da mesma instância da classe 102A, de instân- cias diferentes da classe 102A, uma instância de uma classe diferente e/ou uma mistura dos mesmos.

5 A Figura 1C ilustra relações exemplificativas entre o produtor

11OA e o produtor filho 112A.1, de acordo com uma modalidade da inven- ção. A Figura 1C inclui, adicionalmente, uma instância 108C. Cada um do conjunto de produtores 112A pode ser: 1) da mesma instância que o produ- tor 11OA (instância 108A de classe 102A) e um método diferente associado 10 àquela instância (ilustrado pela letra E nas linhas pontilhadas desde a ins- tância 108A até o produtor 112A.1 e desde o método 104C até o produtor 112A.1); 2) de uma instância diferente da classe 102A e um método diferen- te associado àquela instância (ilustrado pela letra F nas linhas pontilhadas desde a classe 102A até a instância 108C, desde a instância 108C até o 15 produtor 112A.1 e desde o método 104C até o produtor 112A.1); 3) de uma instância de uma classe diferente e um método associado àquela instância (ilustrado pela letra G nas linhas pontilhadas desde a classe 102C até a ins- tância 108C, desde a instância 108C até o produtor 112A.1 e desde o méto- do 104F até o produtor 112A.1); ou 4) de uma instância diferente de classe 20 102A (do que a instância 108) e o mesmo método (método 104A) daquela instância (por exemplo com uma dependência contingente descrita posteri- ormente aqui) (ilustrado pela letra H nas linhas pontilhadas desde a classe 102A até a instância 108C, desde a instância 108C até o produtor 112A.1 e desde o método 104A até o produtor 112A.1). Assim, cada um dentro do 25 conjunto de produtores 112A pode ser da mesma instância que o produtor 110A, de uma instância diferente da classe 102A, ou uma instância de uma classe diferente; adicionalmente, quando existirem múltiplos produtores no conjunto de produtores 112A, os próprios produtores 112A podem ser parte da mesma instância da classe 102A, de instâncias diferentes da classe 30 102A, da mesma instância de uma classe diferente, instâncias diferentes de uma classe diferente e/ou mistura destes.

A Figura 1D ilustra algumas combinações exemplificativas adi- cionais de relações de produtores pais 114 e produtores filhos 112 com o produtor 11OA, de acordo com uma modalidade da invenção. A Figura 1D inclui adicionalmente a instância 108B e a instância 108C. As combinações de Figura 1D são mostradas na Tabela 1 abaixo:

Letra Linhas Pontilhadas para Produ¬ Linhas pontilhadas para Produ¬ dentro tor pai 114A.1 desde tor filho 112A.1 desde da caixa I Desde a instância 108A até o Desde a instância 108A até o produtor 114A.1 e desde o mé¬ produtor 112A.1 e desde o mé¬ todo 104B até o produtor todo 104B até o produtor 114A.1 112A.1 J Desde a instância 108A até o Desde a classe 102A até a ins¬ produtor 114A.1 e desde o mé¬ tância 108C, desde a instância todo 104B até o produtor 108C até o produtor 112A.1 e 114A.1 desde o método 104B até o produtor 112A.1 K Desde a classe 102A até a ins¬ Desde a instância 108A até o tância 108B, desde a instância produtor 112A.1 e desde o mé¬ 108B até o produtor 114A.1 e todo 104B até o produtor desde o método 104B até o 112A.1 produtor 114A.1 L Desde a classe 102B até a ins¬ Desde a classe 102B até a ins¬ tância 108B, desde a instância tância 108B, desde a instância 108B até o produtor 114A.1 e 108B até o produtor 112A.1 e desde o método 104E até o desde o método 104E até o produtor 114A.1 produtor 112A.1 M Desde a classe 102B até a ins¬ Desde a classe 102B até a ins¬ tância 108B, desde a instância tância 108C, desde a instância 108B até o produtor 114A.1 e 108C até o produtor 112A.1 e desde o método 104E até o desde o método 104E até o produtor 114A.1 produtor 112A.1 N Desde a classe 102A até a ins¬ Desde a classe 102A até a ins¬ tância 108B, desde a instância tância 108C, desde a instância 108B até o produtor 114A.1 e 108C até o produtor 112A.1 e desde o método 104A até o desde o método 104A até o produtor 114A.1 produtor 112A.1 O Desde a classe 102A até a ins¬ Desde a classe 102A até a ins¬ tância 108B, desde a instância tância 108B, desde a instância 108B até o produtor 114A.1 e 108B até o produtor 112A.1 e desde o método 104A até o desde o método 104A até o produtor 114A.1 produtor 112A.1 P Desde a instância 108A até o Desde a classe 102A até a ins¬ produtor 114A.1 e desde o mé¬ tância 108C, desde a instância todo 104B até o produtor 108C até o produtor 112A.1 e desde o método 104A até o | 114A.1 produtor 112A.1 Q Desde a classe 102A até a ins¬ Desde a classe 102A até a ins¬ tância 108B, desde a instância tância 108B, desde a instância 108B até o produtor 114A.1 e 108B até o produtor 112A.1 e desde o método 104A até o desde o método 104B até o produtor 114A.1 produtor 112A.1 R Desde a classe 102B até a ins¬ Desde a classe 102B até a ins¬ tância 108B, desde a instância tância 108B, desde a instância 108B até o produtor 114A.1 e 108B até o produtor 112A.1 e desde o método 104D até o desde o método 104E até o produtor 114A.1 produtor 112A.1 A Figura 1E ilustra que instâncias diferentes da mesma classe podem ter produtores com base no mesmo método e/ou em métodos dife- rentes de acordo com uma modalidade da invenção. A Figura 1E mostra: 1) a definição de classe 102A incluindo os métodos 104A-C e as declarações 5 de dependência de produtor 106A-C para cada um daqueles métodos, res- pectivamente; 2) a instância 108A e a instância 108B sendo da classe 102A; 3) um produtor 11OA é o método 104A da instância 108A da classe 102A; 4) um produtor 11OB é o método 104B da instância 108A da classe 102A; 5) um produtor 11OC é o método 104A da instância 108B da classe 102A; e 6) 10 um produtor 11OD é o método 104C da instância 108B da classe 102A. Além disso, a Figura 1D mostra que: 1) a declaração de dependência de produtor 106A para o método 104A identifica no runtime os produtores filhos tanto do produtor 11OA quanto do produtor 110C; 2) a declaração de dependência de produtor 106B para o método 104B identifica no runtime o produtor filho do 15 produtor 110B; e 3) a declaração de dependência de produtor 106C para o método 104C identifica no runtime o produtor filho do produtor 110D.

Tempos de execução Exemplificativos

A Figura 2 é um diagrama de bloco que ilustra a capacidade de reutilização de um runtime com suporte de programação orientada por gráfi- 20 co de produtor de acordo com uma modalidade da invenção. Na Figura 2, múltiplos programas aplicativos orientados por objeto (código aplicativo ori- entado por objeto com declarações de dependência de produtor 210A-I) são executados pelo mesmo runtime com suporte de programação orientada por gráfico de produtor 220. A Figura 3A é um diagrama de bloco que ilustra um runtime com suporte de programação orientado por gráfico de produtor de acordo com uma modalidade da invenção. Na Figura 3A, um runtime com suporte de programação orientado por gráfico de produtor 335 inclui um módulo de ge- ração de gráfico de produtor automatizado 340 e um módulo de execução de gráfico de produtor 345. Além disso, o runtime 335 deve executar código fonte orientado por objeto e, assim, incluir módulos adicionais não mostra- dos.

Em adição, a Figura 3A mostra declarações de dependência de produtor para métodos em código fonte orientado por objeto 320, um conjun- to atual de um ou mais produtores cujas saídas são de interesse 325 (tam- bém referidas aqui como os produtores de interesse selecionados no mo- mento) e as saídas de produtores fonte 330 (descritos aqui posteriormente). O módulo de geração de gráfico de produtor automatizado 340 recebe as declarações de dependência de produtor 320 e o conjunto atual de produto- res de interesse 325.

O módulo de geração de gráfico de produtor automatizado 340 tenta descobrir, com base nas declarações de dependência de produtor, produtores filhos com saídas que contribuem direta e indiretamente para a entrada dos produtores de interesse selecionados no momento (e em algu- mas modalidade da invenção que suportam dependências declaradas as- cendentemente, produtores pais) e constrói um conjunto de um ou mais grá- ficos atuais de produtores representando a dependência destes produtores entre símbolo a partir dos produtores de interesse selecionados no momen- to, através de qualquer produtor descoberto que seja produtor de não-fonte, com aqueles dos produtores descobertos que são produtores fonte. O(s) gráfico(s) de produtor atual(is) é(são) armazenado(s) na estrutura de gráfi- co(s) de produtor 380. Embora modalidades da invenção possam armazenar e manipular o(s) gráfico(s) de produtor como uma coleção de gráficos, outras modalidades da invenção armazenam e manipulam o(s) gráfico(s) de produ- tor como uma coleção de produtores que estão ligados entre símbolo para formar gráfico(s) (em oposição a uma coleção de gráficos) para facilitar a * mescla e a separação de gráficos de produtor. À guisa de exemplo e não de limitação, modalidades da invenção que armazenam e manipulam o(s) gráfi- co(s) de produtor como uma coleção de produtores, serão descritos aqui.

O módulo de execução de gráfico de produtor 345 recebe o(s) 5 gráfico(s) de produtor atual do módulo de geração de gráfico de produtor automatizado 340 e as saídas de produtores fonte 330 e executa os produto- res do gráfico(s) de produtor(es) atual(is) para determinar a saída atual dos produtores de interesse selecionados no momento. O módulo de execução de gráfico de produtor 345 faz cache das saídas atuais dos produtores na 10 estrutura de gráfico de produtor 380, conforme está ilustrado pelo cache de saída de produtor 384.

O cache de saídas de produtor do gráfico de produtor durante a execução permite a sincronização. Por exemplo, o tempo adequado para executar um produtor pai que é dependente de múltiplos produtores filhos é 15 depois de todos os múltiplos produtores filhos terem sido executados; em outras palavras, seria inútil (e, em alguns casos, impossível) executar o pro- dutor pai a cada vez que um de seus produtores filhos completasse a execu- ção. O cache das saídas de produtor permite que a execução do produtor pai não apenas seja adiada até que todos os seus produtores filhos tenham ^ 20 sido executados, como também permite uma determinação do tempo ade- quado para a execução do produtor pai - quando todos os produtores filhos tiverem sido executados e suas saídas tiverem sofrido cache. Assim, o run- time toma essa decisão de sincronização para o programador ao verificar o estado de execução de seus produtores filhos; em outras palavras, tal sin- 25 cronização é automatizada (o programador não precisa incluir código fonte separado que determine o tempo adequado para identificar uma instância e executar um dado método associado àquela instância naquela instância). Por meio de um outro exemplo, em que diversos produtores pais são depen- dentes do mesmo produtor filho, assim como de outros produtores filhos di- 30 ferentes, o tempo adequado para executar cada um dos diversos produtores pais é tipicamente diferente; o runtime determina automaticamente o tempo adequado para executar cada um dos diversos produtores pais, dependendo da disponibilidade das saídas de seu conjunto de produtores filhos.

Conforme será descrito com mais detalhes posteriormente, co- mo algumas partes de um gráfico de produtor podem não estar descobertas no momento, devido a dependências dinâmicas do produtor, o módulo de 5 geração de gráfico de produtor automatizado 340 "tenta" descobrir e constru- ir todo o gráfico produtor, mas inicialmente pode não ser capaz de completar todo o gráfico produtor até alguns produtores serem executados. Como tal, o módulo de execução de gráfico produtor 345 pode invocar o módulo de ge- ração de gráfico produtor automatizado 340 com as saídas necessárias de 10 produtor durante a execução do gráfico produtor atual para completar qual- quer excesso não solucionado do gráfico produtor atual (isso é ilustrado na Figura 3A por uma linha desde o módulo de execução de gráfico produtor 345 até o módulo de geração de gráfico produtor automatizado 340; é usado este tipo de linha porque tal suporte é opcional).

A Figura 4A é um diagrama de bloco que ilustra a descoberta e

construção de um gráfico produtor exemplificativo de acordo com uma mo- dalidade da invenção. A Figura 4A mostra que o conjunto atual de produto- res de interesse consiste em produtor 1. Com base no produtor 1 e sua de- claração de dependência de produtor, o produtor 2 e o produtor 3 são des- 20 cobertos. Em outras palavras, a declaração de dependência de produtor pa- ra o produtor 1 identifica que a entrada para o produtor 1 requer a execução do produtor 2 e produtor 3. Como tal, o produtor 1 é um produtor dependente (um produtor que tem uma ou mais dependências de produtor). A Figura 4A também mostra que embora o produtor 3 seja um produtor independente 25 (um produtor que não tem dependências de produtor, e assim é um produtor fonte), o produtor 2 não é. Como resultado, com base na declaração de de- pendência de produtor do produtor 2, o produtor 4 e o produtor 5 são desco- bertos. Na Figura 2A, o produtor 4 e o produtor 5 são produtores indepen- dentes (e assim, produtores fonte).

A Figura 4B é um diagrama de bloco que ilustra a execução ini-

cial de gráfico produtor da Figura 4A de acordo com uma modalidade da in- venção. Na Figura 4B, linhas curvas com seta ilustram a execução de um produtor para gerar uma saída que é proporcionada como a entrada para um outro produtor. Conforme é mostrado na Figura 3A, a saída dos produtores fonte 330 são fornecidas ao módulo de execução de de preferência 345; por outro lado, as saídas dos produtores dependentes 1-2 são determinadas pela execução daqueles produtores, conforme é mostrado na Figura 4B. As- sim, na Figura 4B, ocorre o seguinte: 1) a saída do produtor fonte 4 e produ- tor fonte 5 são fornecidas ao produtor dependente 2; 2) o produtor depen- dente 2 é executado; 3) as saídas do produtor dependente 2 e produtor fonte

3 são fornecidas ao produtor 1; e 4) o produtor 1 é executado e sua saída é fornecida como a saída atual de interesse. Vale a pena notar que o gráfico produtor da Figura 4B é acionado por dados no sentido de que os dados flu- em de um produtor para um outro produtor até o gráfico.

Assim, as declarações de dependência de produtor 320 limitam os possíveis gráficos de produtor que podem ser gerados; embora o conjun- to de produtores de interesse 325 selecionado no momento identifique o(s) nó(s) inicial do gráfico produtor atual a ser gerado. A partir destes dois, o módulo de geração de gráfico produtor automatizado 340 descobre e cons- trói o gráfico produtor. A descoberta e a construção são automatizadas pelo fato de que o módulo de geração de gráfico produtor automatizado 340 não possui o gráfico produtor (por exemplo, não precisa ser identificado manual- mente por um programador) ou mesmo uma lista dos produtores que estarão no gráfico produtor. Ao invés disso, o módulo de geração de gráfico produtor automatizado 340 analisa as declarações de dependência de produtor do conjunto de produtores de interesse selecionado no momento para descobrir seus produtores filhos (e, em algumas modalidades da invenção que supor- tam dependências declaradas ascendentemente, produtores pais), então analisa as declarações de dependência de produtor daqueles produtores descobertos e assim por diante até os produtores fonte (em algumas moda- lidades da invenção a serem descritas posteriormente, isso pode ser feito com a ajuda do módulo de execução de gráfico produtor 345). No caso em que o gráfico produtor é uma árvore, um produtor de interesse selecionado no momento será, tipicamente, o nó-raiz e as declarações de dependência de produtor serão analisadas até os nós folha (produtores fonte) serem des- cobertos.

Produtores Sobregravados e Execução Incrementai

A Figura 3B é um diagrama de bloco que ilustra um runtime com 5 suporte de programação orientado por gráfico produtor que também suporta execução incrementai e saídas de produtor sobregravadas, de acordo com uma modalidade da invenção. Deve-se entender que a execução incremen- tai e as saídas de produtor sobregravadas são, cada uma, características opcionais independentes e, assim, modalidades diferentes da invenção po- 10 dem implementar uma ou ambas.

Na Figura 3B, um runtime com suporte de programação orienta- do por gráfico produtor 360 inclui um módulo de geração de gráfico produtor automatizado 365, um módulo de execução de gráfico produtor 370 e um módulo de saída de produtor de sobregravação 390. O runtime 360 deve 15 executar código fonte orientado por objeto e, assim, inclui módulos adicio- nais não mostrados.

Em adição, a Figura 3B mostra as declarações de dependência de produtor para métodos em código fonte orientado por objeto 320, o con- junto atual de um ou mais produtores cujas saídas são de interesse 325 20 (também referidos aqui como os produtores de interesse selecionados no momento) e a saída de produtores fonte 350. A saída de produtores fonte 350 inclui as saídas de produtores independentes no código fonte 352 (por exemplo, constantes, valores padrão, etc.) e as saídas de produtor atual- mente sobregravadas 354 (as saídas dos produtores independentes e/ou 25 produtores dependentes cujas saídas estão sobregravadas no momento).

Em algumas modalidades da invenção, as saídas de produtores pode ser explicitamente sobregravada com um valor fornecido no momento (isto é, ao invés de executar um produtor para determinar seu valor de saída com base em suas entradas atuais, o valor de saída para o produtor é pro- 30 porcionado explicitamente). Além de qualquer produtor independente de um gráfico produtor, os produtores fonte de um gráfico produtor incluem qual- quer produtor atualmente sobregravado. ■·■ O módulo de saída de produtor de sobregravação 390 recebe as

saídas do produtor sobregravado 354 (que identificam que produtores estão sendo sobregravados e com que valores de saída eles estão sendo sobre- gravados). Em uma modalidade da invenção, os produtores podem ser clas- 5 sificados como produtores de propriedade ou produtores de método. Os pro- dutores de propriedade são aqueles baseados em métodos de propriedade (por exemplo, obter e definir). Os produtores de método são aqueles basea- dos em métodos de não-propriedade. O módulo de saída de produtor de so- bregravação 390 inclui um módulo de saída de produtor de propriedade de 10 sobregravação 392 para produtores de método sobregravados. O módulo de saída de produtor de propriedade sobregravado 392 faz com que o valor so- bregravado seja armazenado no cache de saída do produtor 384 e nos da- dos da invenção, enquanto o módulo de saída de produtor de método de sobregravação 394 faz com que o valor sobregravado seja armazenado no 15 cache de saída de produtor 384. Dependendo da modalidade da invenção, isso pode ser direto ou indireto. A Figura 3B ilustra uma causa indireta atra- vés do uso de um registro de sobregravação 396 que coleta a saída do mó- dulo de saída de produtor de sobregravação 390 e que é consumida pelo módulo de execução de gráfico produtor 370. Para fins de otimização, o re- '20 gistro de sobregravação 396 permite o atraso de sobregravações de modo a coletar múltiplas sobregravações para processamento em lote.

Similar ao módulo de geração de gráfico produtor automatizado 340, o módulo de geração de gráfico produtor automatizado 365: 1) recebe as declarações de dependência de produtor 320 e o conjunto atual de produ- 25 tores de interesse 325; e 2) tenta descobrir, com base nas declarações de dependência de produtor, produtores filhos com saídas que contribuam dire- ta e indiretamente com a entrada dos produtores de interesse atualmente selecionados (e em algumas modalidades da invenção que suportam produ- tores pais, dependências declaradas ascendentemente) e constrói um con- 30 junto de um ou mais gráficos atuais de produtores representando a depen- dência de entrada destes produtores entre símbolo a partir dos produtores de interesse atualmente selecionados, através de qualquer produtor não- fonte descoberto, e aqueles dos produtores descobertos que são produtores fonte (produtores independentes e produtores atualmente sobregravados). O(s) gráfico(s) de produtor é(são) armazenado(s) na estrutura de gráfico produtor 380.

5 Similar ao modo de execução de gráfico produtor 345, o módulo

de execução de gráfico produtor 370 recebe o gráfico produtor atual do mó- dulo de gráfico automatizado 365 e as saídas de produtores fonte 350 e e- xecuta os produtores do gráfico produtor atual para determinar a saída atual dos produtores de interesse atualmente selecionados. O módulo de execu- 10 ção de gráfico produtor 370 faz cache das saídas atuais dos produtores na estrutura de gráfico produtor 380, conforme está ilustrado pelo cache de saí- da de produtor 384.

Conforme descrito anteriormente, o cache das saídas do produ- tor durante a execução permite a sincronização (por exemplo, o código fonte separado não precisa estar gravado para determinar quando o produtor 2 da Figura 4B deve ser executado, mas ao invés disso, o runtime toma esta de- cisão de sincronização para o programador ao verificar a disponibilidade das saídas necessárias no cache de saída do produtor 384, em outras palavras, tal sincronização é automatizada). Além disso, este cache de saída de pro- dutor 384 é usado para execução incrementai. Mais especificamente, após um gráfico produtor ter sido inicialmente gerado e executado, a sobregrava- ção de um produtor no gráfico produtor atual requer algum nível de reexecu- ção. Embora algumas modalidades da invenção simplesmente reexecutem todo o gráfico, modalidades alternativas da invenção suportam execução incrementai (reexecução apenas daquelas partes do gráfico produtor que são afetadas pela sobregravação). Algumas modalidades exemplificativas que suportam execução incrementai usam marcação de execução incremen- tai 382 na estrutura de gráfico produtor 380 para ajudar a determinar que produtores requerem reexecução. Assim, manter o gráfico produtor refere-se a modificar as ligações do gráfico produtor, conforme for necessário em múl- tiplas execuções, par mantê-las atuais (atualizadas), enquanto que a execu- ção incrementa! refere-se tanto a manter o gráfico produtor quanto a usar o gráfico produtor atual (atualizado) para reexecutar apenas aquelas partes do gráfico produtor que são afetadas por uma sobregravação.

Similar à Figura 3A, existe uma linha com seta pontilhada a par- tir do módulo de execução de gráfico produtor 370 até o módulo de execu- ção de gráfico produtor automatizado 365 para representar suporte opcional para dependências dinâmicas. Deve-se notar que dependências dinâmicas podem mudar durante a reexecução de um gráfico produtor.

A Figura 4C é um diagrama de bloco que ilustra a execução in- crementai do gráfico produtor da Figura 4B de acordo com uma modalidade da invenção. Na Figura 4C, a saída do produtor 5 foi explicitamente modifi- cada, mas as saídas do produtor 3 e produtor 4 não. Com base no rastrea- mento das dependências entre saída e entrada no gráfico produtor e que apenas a saída do produtor 5 foi explicitamente modificada, determina-se que apenas o produtor 2 e o produtor 1 são afetados por esta modificação. Como resultado, a determinação de uma saída atualizada do produtor 1 re- quer apenas a reexecução do produtor 2 e produtor 1 com a nova saída do produtor 5 e as saídas anteriores do produtor 4 e produtor 3. Esta reexecu- ção parcial do gráfico produtor está ilustrada na Figura 4C pelas linhas cur- vas a partir do produtor 5 até o produtor 2 e do produtor 2 até o produtor 1, mas não do produtor 4 até o produtor 2 ou do produtor 3 até o produtor 1. A falta de linhas curvas com seta do produtor 4 até o produtor 2 e do produtor

3 até o produtor 1 não são para indicar que as saídas do produtor 3 e produ- tor 4 não são necessárias, mas ao invés disso, que o produtor 3 e o produtor

4 não precisam ser reexecutados se suas saídas anteriores estiverem dis- poníveis (por exemplo, com cache da execução anterior do gráfico produtor).

O exemplo relativamente simples da Figura 4C ilustra que pode haver uma economia nos recursos de processamento como resultado de execução incrementai. Tal economia depende de uma série de fatores (por exemplo, o número de produtores que não precisam ser reexecutados, a quantidade de processamento que aqueles produtores teriam necessitado, etc.). Embora seja ilustrada uma modalidade da invenção que realiza execu- ção incrementai, modalidades alternativas podem ser implementadas de maneira diferente (por exemplo, uma modalidade alternativa pode reexecutar todos os produtores em resposta a uma modificação).

A Figura 4D é um diagrama de bloco que ilustra a execução in- crementai do gráfico produtor da Figura 4B após o produtor dependente 2 ter 5 sido sobregravado, de acordo com uma modalidade da invenção. Na Figura 4D, a saída do produtor 2 foi explicitamente modificada, mas a saída do pro- dutor 3 não. Com base no gráfico produtor e que apenas a saída do produtor 2 foi explicitamente modificada, determina-se que apenas o produtor 1 é afe- tado por esta modificação. Como resultado, a determinação de uma saída 10 atualizada do produtor 1 requer apenas a reexecução do produtor 1 com a saída sobregravada do produtor 2 e a saída anterior do produtor 3. Esta ree- xecução parcial do gráfico produtor está ilustrada na Figura 4D por uma linha curva a partir do produtor 2 até o produtor 1, mas não do produtor 4 e 5 até o produtor 2 ou do produtor 3 até o produtor 1.

A Figura 4E é um diagrama de bloco que ilustra a execução in-

crementai do gráfico produtor da Figura 4B após o produtor dependente 2 ter sido sobregravado e o produtor fonte independente 3 ter sido modificado de acordo com uma modalidade da invenção. Com base no gráfico produtor e que apenas as saídas do produtor 2 e produtor 3 foram modificadas, deter- 20 mina-se que apenas o produtor 1 é afetado por esta modificação. Como re- sultado, a determinação de uma saída atualizada do produtor 1 requer ape- nas a reexecução do produtor 1 com a saída sobregravada do produtor 2 e a saída modificada do produtor 3. Esta reexecução parcial do gráfico produtor está ilustrada na Figura 4E por uma linha curva com seta a partir dos produ- 25 tores 2 e 3 até o produtor 1, mas não dos produtores 4 e 5 até o produtor 2.

Embora uma modalidade da invenção que suporta sobregrava- ção de saídas de produtor também suporte a não sobregravação de saídas do produtor, modalidades alternativas da invenção não. Embora uma moda- lidade da invenção que suporta a não sobregravação de produtores deixe 30 sobregravado um produtor sobregravado até ser desfeita nele especifica- mente a sobregravação, modalidades alternativas da invenção podem ser implementadas de maneira diferente (por exemplo, desfazendo a sobregra- vação de um produtor sobregravado quando um de sua prole for sobregra- vado).

Construção e Execução de Gráfico Produtor

Modalidades diferentes da invenção podem ser implementadas para descobrir e construir um gráfico produtor até diferentes âmbitos (por exemplo, construir o gráfico produtor até todos os caminhos a partir do nó- raiz terminarem em produtores independentes (caso em que os nós finais de um gráfico produtor são produtores independentes, com a possibilidade de qualquer produtor sobregravado ser nó intermediário); construir o gráfico produtor até cada caminho a partir do nó-raiz terminar em um produtor so- bregravado ou em um produtor independente, o que for alcançado primeiro (caso em que cada nó final de um gráfico produtor é um produtor indepen- dente ou um produtor sobregravado)).

"Produtores de início de execução" refere-se aos produtores de um gráfico produtor a partir do qual começa uma dada execução do gráfico produtor. Para uma execução inicial de um gráfico produtor, diferentes mo- dalidades podem começar a partir de diferentes produtores (por exemplo, em modalidades da invenção que constroem o gráfico produtor até todos os caminhos desde o nó-raiz terminarem em produtores independentes, a exe- cução pode começar a partir dos nós finais (que seriam os produtores inde- pendentes), a partir dos produtores fonte (que incluiriam os nós produtores independentes e qualquer nó produtor sobregravado), a partir de um sub- conjunto dos produtores fonte consistindo na combinação de qualquer pro- dutor independente com pelo menos um caminho entre eles e o produtor raiz que não inclua um produtor sobregravado e qualquer produtor sobregravado, ou a partir de um subconjunto dos produtores fonte consistindo na combina- ção de qualquer produtor sobregravado sem qualquer descendente que seja sobregravado e qualquer produtor independente com pelo menos um cami- nho entre eles e o produtor raiz que não inclua um produtor sobregravado, em modalidades da invenção em que o gráfico produtor sob produtores so- bregravados não é construído se e até tal produtor não tiver sido desgrava- do, a execução pode começar a partir dos nós finais (que podem ser produ- tores independentes e/ou produtores sobregravados), etc).

Para execuções subsequentes de um gráfico produtor, diferen- tes modalidades podem começar a partir de diferentes produtores (por e- xemplo, a psrtir de produtores independentes do gráfico produtor (por exem- pio, em modalidades da invenção que não suportem execução incrementai); a partir de produtores fonte do gráfico produtor (por exemplo, em modalida- des da invenção que não suportam execução incrementai); a partir de um subconjunto dos produtores fonte que consista naqueles produtores fonte que foram sobregravados e/ou adicionados desde a última execução (por exemplo, em modalidades da invenção que suportam execução incremen- tai); dos produtores fonte que foram sobregravados e/ou adicionados desde a última execução, a partir da combinação de qualquer produtor sobregrava- do sem qualquer descendente que esteja sobregravado e qualquer produtor adicionado com pelo menos um caminho entre eles e o produtor raiz que não inclua um produtor sobregravado (por exemplo, em modalidades da in- venção que suportam execução incrementai); etc). À guisa de exemplo e não de limitação, serão descritas abaixo modalidades da invenção que reali- zam o seguinte: 1) não constroem o gráfico produtor sob produtores sobre- gravados se e até tal produtor estar não sobregravado; 2) para uma execu- ção inicial de um gráfico produtor, começar a execução a partir dos nós fi- nais (que podem ser produtores independentes e/ou produtores sobregrava- dos); 3) implementa execução incrementai; e 4) para execuções subsequen- tes de um gráfico produtor, começa a execução a partir de um subconjunto dos produtores fonte que consiste daqueles produtores fonte que foram so- bregravados e/ou adicionados desde a última execução.

No que diz respeito ao conceito acima de produtores de início de execução, o fluxo de processamento de execução do gráfico produtor também difere entre diferentes modalidades. Por exemplo, em uma modali- dade da invenção, a linhagem dos produtores de início de execução é de- 30 terminada e colocada em uma coleção, os produtores de início de execução são executados e a coleção é iterativamente examinada para produtores para os quais todas as dependências foram executadas - eventualmente os " nós raízes são alcançados. Como outro exemplo, em uma modalidade da invenção, os produtores de início de execução são executados, os pais dos produtores de início de execução são identificados, aqueles pais são execu- tados e seus pais são identificados e executados, e assim por diante. A últi- 5 ma modalidade da invenção é usada abaixo à guisa de exemplo, e não de limitação.

Tipos Exemplificativos de Dependências Dependências de Produtor Dinâmicas Exemplificativas Uma dependência de produtor dinâmica é uma dependência de produtor que pode mudar durante o runtime. Deve-se entender que os crité- rios para solucionar a dependência de produtor estão presentes no código fonte e, assim, os produtores para os quais a dependência de produtor pode ser resolvida, são limitados. Com referência à Figura 3A, a linha pontilhada com seta a partir do módulo de execução de gráfico produtor 345 até o mó- dulo de geração de gráfico produtor automatizado 340 representa suporte para a execução de um ou mais produtores no gráfico produtor atual, o que é necessário para descobrir e construir todo o gráfico produtor atual. Em ou- tras palavras, uma modalidade da invenção que suporte dependências de produtor dinâmicas pode iterar entre o módulo de geração de gráfico produ- tor automatizado 340 e o módulo de execução de gráfico produtor 345 até todo o gráfico produtor estar descoberto, construído, resolvido e executado (ou seja, itera entre: 1 - invocar o módulo de geração de gráfico produtor au- tomatizado para descobrir e construir aquelas partes do gráfico produtor atu- al que podem ser resolvidas naquele momento; e 2 - invocar o módulo de execução de gráfico produtor para executar produtores do gráfico produtor atual). Neste sentido, descobrir refere-se a acessar as declarações de de- pendência de produtor e determinar os produtores que elas identificam; construir refere-se a instanciar os produtores e adicioná-los ao gráfico produ- tor; e resolver refere-se a determinar dependências de produtor dinâmicas não resolvidas atualmente.

A Figura 5A é um diagrama de bloco que ilustra a descoberta e construção de um gráfico produtor exemplificativo incluindo uma dependên- cia não resolvida, de acordo com uma modalidade da invenção. A Figura 5a mostra o conjunto atual de produtores de interesse consistindo em produtor 1. Com base no produtor 1 e em sua declaração de dependência de produ- tor, o produtor 2 e o produtor 3 são descobertos. Em outras palavras, a de- claração de dependência para o produtor 1 identifica que produtor 1 requer como entradas, a saída do produtor 2 e do produtor 3. A Figura 5A também mostra que, enquanto o produtor 3 é um produtor independente (e assim, um produtor fonte), o produtor 2 não é. Como resultado, com base na declara- ção de dependência do produtor 2, o produtor 4 e o produtor 5 são desco- bertos. Adicionalmente, a Figura 5A mostra que enquanto o produtor 4 é um produtor independente (e assim, um produtor fonte), o produtor 5 não é. Como resultado, com base na declaração de dependência do produtor 5, o produtor 6 e uma dependência atualmente não resolvida, são descobertos. A Figura 5A também mostra que a dependência atualmente não resolvida po- de ser para o produtor 7A e/ou produtor 7B.

A Figura 5B é um diagrama de bloco que ilustra a execução ini- cial do gráfico produtor da Figura 5A e a resolução da dependência não re- solvida, de acordo com uma modalidade da invenção. A Figura 5B ilustra o gráfico produtor da Figura 5A com linhas curvas com seta mostrando a exe- 20 cução dos produtores e provisão de suas saídas a produtores pais depen- dentes. Em adição, a Figura 5B mostra que a dependência não resolvida do produtor 5 é resolvida como uma dependência do produtor 7A e que o pro- dutor 7A é um produtor independente.

A Figura 5C é um diagrama de bloco que ilustra a execução ini- 25 ciai do gráfico produtor da Figura 5A e/ou a reexecução do gráfico produtor da Figura 5B, de acordo com uma modalidade da invenção. A Figura 5C ilus- tra o gráfico produtor da Figura 5A com linhas curvas com seta mostrando a execução dos produtores e provisão de suas saídas a produtores pais de- pendentes. Além disso, a Figura 5C mostra que a dependência não resolvida 30 do produtor 5 é resolvida como uma dependência do produtor 7B e que o produtor 7B é um produtor dependente. Como resultado, com base na decla- ração de dependência do produtor 7B, o produtor 8 é descoberto. O produtor ^ 8 é um produtor independente (e assim, é um produtor fonte). Assumindo que a Figura 5C representa a execução inicial do gráfico produtor da Figura 5A, todas as linhas curvas com seta na Figura 5C seriam empregadas. No entanto, assumindo que a Figura 5C represente a reexecução do gráfico 5 produtor da Figura 5B, a reexecução resulta na dependência dinâmica ser resolvida de modo diferente (um comutador do produtor 5 sendo dependente do produtor 7A para o produtor 7B). Adicionalmente, se a reexecução for realizada sem execução incrementai, então todas as linhas curvas com seta na Figura 5C seriam empregadas; no entanto, caso a execução incrementai 10 tenha sido usada, apenas as linhas curvas não pontilhadas com seta seriam empregadas (produtor 8 para produtor 7B, produtor 7B para produtor 5, pro- dutor 5 para produtor 2 e produtor 2 para produtor 1). Deve-se entender também que a mudança dinâmica na dependência ilustrada na Figura 5C é exemplificativa e, assim, qualquer número de diferentes situações pode apa- 15 recer (por exemplo, a mudança dinâmica pode nunca ocorrer; o produtor 5 pode ter sido primeiro dependente do produtor 7B e então ter mudado para o produtor 7A; o produtor 5 pode ter sido primeiro dependente do produtor 7B e nenhuma mudança dinâmica jamais ocorrer; pode-se ter descoberto que o produtor 5 é dependente tanto do produtor 7A quanto do produtor 7B, con- ‘ 20 forme está ilustrado na Figura 5D; etc.) Embora diferentes modalidades pos- sam resolver dependências de produtor dinâmicas de diferentes maneiras, alguns exemplos serão fornecidos posteriormente.

Assim, a reexecução automatizada de um gráfico produtor não está limitada ao produtor ser modificado e seu pai direto ser executado no- 25 vãmente; ao invés disso, uma mudança é automaticamente feita através do gráfico produtor pelo runtime, afetando qualquer produtor e dependência apropriados, porque os gráficos de produtor são mantidos (e a exemplificati- va incrementai é usada em que for suportada). Como tal, as mudanças cau- sam qualquer descoberta, construção, resolução e execução adicional ne- 30 cessária. Assim, a reexecução de um gráfico produtor é automatizada no sentido de que um usuário/programador não precisa determinar que produtor do gráfico produtor é afetado e possivelmente, corrigir manualmente o gráfi- Dependências de Produtor Estáticas Uma dependência estática é uma que não pode mudar durante

o runtime. Assim, em uma modalidade da invenção que suporta dependên- cias contingentes e de assinatura dinâmica (a ser descrita posteriormente), uma dependência não-contingente, de não assinatura é uma dependência estática. O gráfico produtor exemplificativo da Figura 4A ilustra um gráfico produtor de dependências estáticas.

Formatos do Gráfico Produtor

Como um produtor é pelo menos uma instância e um método associado àquela instância, um gráfico produtor é um gráfico que representa instâncias e métodos associados àquelas instâncias - e assim, os gráficos de produtor são pelo menos cêntricos em instância e método. Em modalida- des da invenção em que um produtor é pelo menos uma classe, instância e método, os gráficos produtores são pelo menos cêntricos em classe, instân- cia e método.

Deve-se entender que um gráfico produtor pode ter uma série de formatos diferentes (por exemplo, uma cadeia simples de produtores, uma árvore, etc.). O gráfico produtor exemplificativo das Figuras 5B é uma árvore com um nó-raiz do produtor 1, a partir do qual existem duas ramifica- ções - uma para o produtor 2 e outra para o produtor 3. Quando o produtor 3 for um nó-folha, o produtor 2 tem duas ramificações se estendendo a partir dele - uma para cada um dos produtores 4 e 5. O produtor 5 tem duas rami- ficações se estendendo a partir dele - uma para cada um dos produtores 6 e 7A. Diz-se que o gráfico produtor exemplificativo da Figura 5B tem múltiplos níveis, com o nível 1 incluindo o produtor de nó-raiz 1, com o nível 2 incluin- do o produtor 2 e o produtor 3, com o nível 3 incluindo o produtor 4 e o pro- dutor 5, com o nível 4 incluindo o produtor 6 e o produtor 7A (na Figura 5C, o nível 4 inclui o produtor 7B e o nível 5 inclui o produtor 8). Ao considerar a ramificação a partir do produtor 1 com o produtor 2, o primeiro produtor da ramificação é o produtor 2 e os últimos produtores da ramificação são o pro- dutor 4, o produtor 6 e o produtor 7A na Figura 5B. Embora a Figura 5B ilustre um gráfico produtor em que o con- junto atual de produtores de interesse inclui um produtor simples, modalida- des da invenção que suportem mais de um produtor atual de interesse des- cobrem e constroem gráficos produtores para cada um. Deve-se entender 5 que quando existirem simultaneamente múltiplos produtores de interesse, os gráficos produtores resultantes podem ser independentes ou podem se in- terceptar. Quando os gráficos produtores se interceptarem, as modalidades da invenção podem ser implementadas para: 1) duplicar produtores para manter gráficos produtores separados; ou 2) evitar tal duplicação e manter 10 os gráficos produtores se interceptando. Deve-se entender também que tais gráficos produtores que se interceptam podem incluir um gráfico produtor que é um subconjunto de um outro gráfico produtor. Por exemplo, se o pro- dutor 5 tiver sido incluído com o produtor 1 no conjunto atual de produtores de interesse, então há um primeiro gráfico produtor com um nó-raiz do pro- 15 dutor 5 e um segundo gráfico produtor com um nó-raiz do produtor 1, em que o segundo gráfico produtor inclui o primeiro gráfico produtor. Se, por exemplo, o produtor 7B tiver sido incluído com o produtor 1 e o produtor 5 no conjunto atual de produtores de interesse, haverá um terceiro gráfico produ- tor, separado do primeiro e do segundo gráfico produtor, com um nó-raiz do

1 20 produtor 7B na Figura 5B. Adicionalmente, se a dependência dinâmica do produtor 5 mudasse do produtor 7A para o produtor 7B (Figura 5C), então a mudança resultaria no terceiro gráfico produtor se tornar um subconjunto do segundo gráfico produtor remanescente e o segundo gráfico produtor se tor- nar um subconjunto do primeiro gráfico produtor. Conforme dito anteriormen- 25 te, embora as modalidades da invenção possam armazenar e manipular o(s) gráfico(s) produtor(es) como uma coleção de gráficos, outras modalidades da invenção armazenam e manipulam o(s) gráfico(s) produtor(es) como uma coleção de produtores que são ligados entre símbolo para formar gráfico(s) (em oposição a uma coleção de gráficos) para facilitar a mescla e a separa- 30 cao de gráficos produtores. Á guisa de exemplo e não de limitação, modali- dades da invenção que armazenam e manipulam o(s) gráfico(s) produtor(es) como uma coleção de produtor(es), são descritas aqui. Fluxo de Execução Exemplificativo A Figura 6 é um fluxograma de um fluxo de execução lógica de um cliente de runtime e sua relação com um runtime com suporte de pro- gramação orientada por gráfico produtor, de acordo com uma modalidade da invenção. Na Figura 6, a linha de divisão pontilhada 600 separa o fluxo de execução lógica de um cliente de runtime 610 do runtime com o suporte de programação orientada por gráfico produtor 640.

O fluxo de execução lógica do cliente de runtime 610 inclui blo- cos 615, 620, 625 e 630, enquanto o runtime com suporte orientado por grá- fico produtor 640 inclui blocos 645, 650, 660 e, opcionalmente, 655. Uma linha cheia representa uma relação causai direta do bloco 630 com o bloco 660. Por outro lado, linhas pontilhadas com seta ilustram uma relação causai dos blocos 615 e 625 no fluxo de execução lógica do cliente de runtime 610 e os blocos 645 e 650 no runtime com o suporte orientado por gráfico produ- tor 640, respectivamente; dependendo da modalidade da invenção, esta re- lação causai pode ser direta ou indireta. Por exemplo, a Figura 6 ilustra uma causalidade indireta opcional através do uso de um registro de comando 665 em um tracejado oval no runtime com suporte orientado por gráfico produtor 640 da linha tracejada 600. O registro de comando 665 coleta comandos resultantes dos blocos 615 e 625 do fluxo de execução lógica do cliente de runtime 610; e o registro de comando 655 é consumido, em resposta ao blo- co 630, por meio do processamento do bloco 660. Assim, o registro de co- mando 665 permite o atraso de comandos de modo a coletar múltiplos co- mandos juntos e processá-los em lote para fins de otimização. Assim, o re- gistro de comando 665 é similar ao registro de sobregravação 396 da Figura 3B e inclui, na verdade, o registro de sobregravação 396 em algumas moda- lidades da invenção.

No bloco 615, o conjunto de um ou mais produtores de interesse é determinado como o conjunto atual de produtores de interesse e o controle passa para o bloco 620. Em resposta à relação causai entre o bloco 615 e o bloco 645, o bloco 645 mostra que o conjunto atual de produtores de inte- resse é instanciado e que é feita uma tentativa para descobrir, construir e solucionar (se forem suportadas dependências dinâmicas e uma ou mais forem descobertas no gráfico produtor) o(s) gráfico(s) produtor(es) para cada um, incluindo a instanciação de qualquer instância e de seus produtores, conforme necessário, com base nas declarações de dependência de produ- tor no cliente de runtime 610. Com referência às Figuras 3A e 3B, invoca-se

o módulo de geração do gráfico produtor automatizado 340 e 365, respecti- vamente.

No bloco 620, determina-se se existe qualquer sobregravação de saída de produtor. Se houver, o controle passa para o bloco 625; caso contrário, o controle passa para o bloco 630.

No bloco 625, são recebidas uma ou mais sobregravações de saída de produtor para um conjunto de um ou mais produtores e o controle passa para o bloco 630. Em resposta à relação causai entre o bloco 625 e o bloco 650, o bloco 650 mostra que o conjunto atua! de produtores sobregra- vados é instanciado (se já não tiver sido instanciado no bloco 645), suas sa- ídas são modificadas e eles são rastreados. Um produtor sobregravado pode já ter sido instanciado porque já foi descoberto como sendo parte do(s) gráfi- co(s) produtor(es) no bloco 645. No entanto, um produtor sobregravado pode não ter sido descoberto ainda no bloco 645 por causa de uma dependência dinâmica não solucionada. Assim, este produtor sobregravado é instanciado e sobregravado com a expectativa de poder ser adicionado ao(s) gráfico(s) produtor(es) quando as dependências dinâmicas forem solucionadas. Além disso, conforme indicado anteriormente, o registro de sobregravação 396 da Figura 3B, caso implementado, existe entre o bloco 625 e o bloco 650 e é parte do registro de comando 665. Adicionalmente, o conjunto de produtores sobregravados é rastreado em algumas modalidades da invenção que su- portam execução incrementai. Embora nas modalidades da invenção que suportam o registro de sobregravação 396/o registro de comando 665, o ras- treamento seja parte do registro, em modalidades alternativas da invenção o rastreamento é realizado separadamente no bloco 650 com um mecanismo diferente.

No bloco 630, o módulo de execução de gráfico produtor é invo- cado e o controle retorna opcionalmente para o bloco 615 e/ou bloco 625. Em resposta à relação causai entre o bloco 630 e o bloco 660, o bloco 660 mostra que o(s) gráfico(s) produtor(es) atual(is) é(são) conduzido(s) e qual- quer produtor que requeira execução é executado com base no rastreamen- 5 to. Diversas técnicas foram discutidas anteriormente para executar os produ- tores do gráfico produtor e são aplicáveis aqui. Com referência às Figuras 3A e 3B, invoca-se o módulo de execução de gráfico produtor 345 e 370, respectivamente. Em adição, nas modalidades da invenção em que o regis- tro de comando 665 é implementado, a relação causai inclui consumir o re- 10 gistro de comando 665 e realizar o processamento dos blocos 645 e 650 antes do bloco 660. Adicionalmente, nas modalidades da invenção que su- portam a possibilidade de dependências não solucionadas, o controle flui do bloco 660 para o bloco 655, quando necessário.

No bloco 655, é feita uma tentativa para solucionar as depen- dências não solucionadas e descobrir e construir o restante do(s) gráfico(s) produtor(es), incluindo a instanciação de qualquer instância e seus produto- res. Do bloco 655, o controle flui de volta para o bloco 660.

Formas Exemplificativas de Declarações de Dependência de Produtor

As Figuras 7A-F ilustram algumas formas exemplificativas para declarações de dependência de produtor, de acordo com modalidades da invenção. Embora as Figuras 7A-F ilustrem modalidades que suportam de- pendências de argumento, campo e sequenciamento, deve-se entender que diferentes modalidades podem suportar apenas uma ou duas das três for- mas de dependência. Nas modalidades da invenção mostrada nas Figuras 7A-F, é feita uma declaração de dependência de produtor de uma afirmação de declaração de dependência de produtor e, opcionalmente, código de de- claração de dependência de produtor explicita. Uma dependência de produ- tor declarada sem atalho é uma em que é usado o código de declaração de dependência de produtor explícita, enquanto que uma dependência de pro- dutor declarada com atalho é uma em que não é usado o código de declara- ção de dependência de produtor explícita (ao invés disso, o runtime não usa código de declaração de dependência de produtor e/ou o implementa duran- te a execução com base na informação da afirmação de declaração de de- pendência de produtor).

Diferentes modalidades da invenção podem usar diferentes sin- taxes para declarar dependências de produtor. Por exemplo, diferentes mo- dalidades podem incluir diferentes sintaxes para uso em afirmações de de- claração de dependência de produtor que fortemente restrinjam, fracamente restrinjam e/ou não restrinjam o tipo de dependência de produtor que possa ser criada. Uma dependência de produtor fortemente restringida é uma para a qual é usada uma sintaxe na afirmação de declaração de dependência de produtor que limita substancialmente o tipo de dependência de produtor que pode ser criada. Uma dependência de produtor fracamente restringida é uma para a qual é usada uma sintaxe na afirmação de declaração de dependên- cia de produtor que é menos Iimitante quanto ao tipo de dependência de produtor que pode ser criada; e uma dependência de produtor não-restrita é uma para a qual é usada uma sintaxe na afirmação de declaração de de- pendência de produtor que não limita o tipo de dependência de produtor que pode ser criada.

À guisa de exemplo, e não de limitação, modalidades da inven- ção descritas abaixo que incluem o seguinte: 1) uma sintaxe para depen- dência de produtor fortemente restrita quanto aos argumentos (ArgmentDe- pendency = dependência [estática ou dinâmica e,se dinâmica, contingente e/ou assinatura absorvente] de argumento declarada descendentemente fortemente restrita); 2) uma sintaxe para uma dependência de produtor for- temente restrita quanto a campos (FieIdDependency = dependência [estática ou dinâmica e,se dinâmica, contingente e/ou assinatura absorvente] de campo declarada descendentemente fortemente restrita); 3) uma sintaxe para dependência de produtor fortemente restrita para dependências de se- quenciamento (SequencingDependency = dependência [estática ou dinâmi- ca e,se dinâmica, contingente e/ou assinatura absorvente] declarada des- cendentemente fortemente restrita); 4) uma sintaxe para uma dependência de produtor declarada ascendentemente fracamente restrita quanto a argu- mento, campo ou dependências de sequenciamento (UpwardDependency = dependência [estática ou dinâmica e,se dinâmica, contingente] de campo, argumento ou sequenciamento declarada ascendentemente fracamente res- trita); e 5) uma sintaxe para uma dependência de produtor fracamente restri- ta (WeakIyConstrainedDependency = a) dependência [estática ou dinâmica 5 e,se dinâmica, contingente e/ou assinatura adesiva] apenas de sequencia- mento declarada descendentemente; ou b) dependência [estática ou dinâmi- ca e,se dinâmica, contingente] de [argumento, campo ou sequenciamento] declarada ascendentemente). Deve-se entender que embora algumas moda- lidades da invenção suportem uma sintaxe para a afirmação de declaração 10 de dependência de produtor que distinga dependências de argumento decla- radas descendentemente, dependências de campo declaradas descenden- temente, dependências declaradas ascendentemente (que podem retornar dependências de argumento, campo ou sequenciamento declaradas ascen- dentemente) e dependências fracamente restritas (que podem retornar de- 15 pendências de sequenciamento declaradas descendentemente, argumento declarado ascendentemente, dependências de campo ou sequenciamento), modalidades alternativas da invenção podem adotar uma sintaxe diferente (por exemplo, ter uma sintaxe que tenha todas as dependências sendo de- pendências não-restritas com produtores de determinação de dependência 20 que podem retornar qualquer dependência suportada (dependências de ar- gumento, campo e sequenciamento declaradas descendentemente e ascen- dentemente); ter uma sintaxe que distinga todas as dependências suporta- das; ter uma sintaxe que distinga dependências de argumento e campo des- cendentemente e ascendentemente declaradas e que distinga uma depen- 25 dência fracamente restrita que só possa retornar dependências de sequen- ciamento ascendentemente e descendentemente declaradas; uma sintaxe que distinga dependências de argumento e campo descendentemente e as- cendentemente declaradas e que distinga dependências ascendentemente declaradas que possa retornar apenas dependências de sequenciamento 30 ascendentemente declaradas; uma sintaxe que distinga dependências de argumento, campo e sequenciamento descendentemente declaradas (subs- crições adesivas e dependências ascendentemente declaradas não são su- L portadas); etc.)

Deve-se entender que a sintaxe da afirmação de declaração de dependência de produtor não se iguala necessariamente à dependência de produtor (por exemplo, a ligação) criada no gráfico produtor (por exemplo, 5 ArgumentDependency cria uma dependência de argumento; mas Upward- Dependency pode criar uma dependência de argumento, campo ou sequen- ciamento). Como tal, em que for apropriado por questão de compreensão, um espaço entre um qualificador (por exemplo, argumento, campo ou se- quenciamento) e a palavra "dependência", é usado para fazer referência à 10 dependência criada pelo runtime, enquanto a falta de um espaço é usada para fazer referência à sintaxe.

A Figura 7A ilustra pseudo-código de uma declaração de de- pendência de produtor para um método usando dependências declaradas com atalho, de acordo com uma modalidade da invenção; enquanto a Figura 15 7B é um diagrama de bloco de produtores exemplificativos, de acordo com uma modalidade da invenção. A Figura 7a mostra: 1) uma afirmação de de- claração de dependência de produtor 705 que inclui ArguroeutDépeBdençies I-NiFieldDfpendeocies 1-M, SequencingDependencies

I-Lj UpwardDependencíes I-P5 and WeaklyConsirainedDepeBdencies 1-Q; e 2) um método alfa 710 que tem argumentos 1-N da afirmação de declaração 20 de dependência de produtor 705. Em uma modalidade da invenção, os ar- gumentos de uma afirmação de declaração de dependência de produtor são numerados para proporcionarem um ID de argumento a cada um para fins de rastreamento. A Figura 7B mostra um produtor 720 tendo dependências de filho com o seguinte: 1) produtor 725 para Id de argumento 1; 2) produtor 25 730 para ID de argumento N; 3) produtores 740-745 para FieIdDependencies 1-M; 4) produtores 746-747 para SequencingDependencies 1-L; e 5) produ- tor 748-749 para UpwardDependencíes 1-P (note, WeakIyConstrainedDe- pendencies 1..Q não são mostradas, mas serão descritas com mais detalhes com referência à Figura 7G). Assim, os argumentos da afirmação de decla- 30 ração de dependência de produtor 705 correspem quem aos argumentos do método alfa 710 e os IDs de argumento dos argumentos na afirmação de declaração de dependência de produtor 705 são rastreados no que diz res- peito aos produtores filhos que os identificam. A Figura 7C ilustra pseudo-código de uma declaração de depen- dência de produtor para um método usando uma dependência declarada sem atalho, e ilustra um diagrama de bloco de produtores exemplificativos de acordo com uma modalidade da invenção. A Figura 7C mostra a afirma- ção de declaração de dependência de produtor 705 e o método alfa 710 da Figura 7A, assim como os produtores 720 e 725 da Figura 7B. Além disso, a Figura 7C inclui código de declaração de dependência de produtor 715 as- sociado a ArgumentDependency 1. Durante o tempo de execução, runtime acessa e executa o código de declaração de dependência de produtor 715 em resposta a ArgumentDependency 1 da afirmação de declaração de de- pendência de produtor 705. A execução do código de declaração de depen- dência de produtor 715 retorna o produtor 725 como a dependência de pro- dutor para ArgumentDependency 1. Assim, a Figura 7C ilustra modalidades da invenção em que o código de declaração de dependência de produtor 715 pode ser parte de um método (outro que não o método alfa 710), mas não é parte de um produtor.

A Figura 7D ilustra pseudo-código de uma declaração de depen- dência de produtor para um método usando uma dependência declarada sem atalho de acordo com uma modalidade da invenção, enquanto a Figura 7E é um diagrama de bloco de produtores exemplificativos de acordo com uma modalidade da invenção. A Figura 7D mostra a afirmação de declara- ção de dependência de produtor 705 e o método alfa 710 da Figura 7A, en- quanto a Figura 7E mostra os produtores 720 e 725 da Figura 7B. Além dis- so, a Figura 7D inclui: 1) uma afirmação de declaração de dependência de produtor 750; e 2) um método beta 755 que inclui código de declaração de dependência de produtor 760. A Figura 7D também mostra que a dependên- cia de argumento 1 da afirmação de declaração de dependência de produtor 705 identifica um produtor (mostrado na Figura 7E como produtor 765) com base no método beta 755, que retornará a dependência para dependência de argumento 1. Durante o runtime, o runtime, em resposta à dependência de argumento 1 da afirmação de declaração de dependência de produtor 705, executa o produtor 765 para retornar identificação de que a dependên- cia de produtor para uma dependência de argumento 1 é o produtor 765. Como tal, o produtor 765 é referido como um produtor de determinação de dependência (sua saída é uma dependência de produtor - e assim, é retor- 5 nado usando uma classe/instância que é monitorada para tratamento espe- cial manipulação do(s) gráfico(s) produtor(es)) pelo runtime com suporte de programação orientada por gráfico produtor), enquanto o produtor 725 é re- ferido como um produtor padrão (sua saída, se houver, não é processada diretamente por runtime para manipular um gráfico produtor; mas sua saída, 10 se houver, pode ser consumida por um produtor pai (seja um produtor de determinação de dependência ou outro produtor padrão) e/ou ser fornecida como a saída do gráfico produtor (se o produtor padrão for um produtor de interesse e, assim, um nó-raiz).

Assim, as Figuras 7D-E ilustram modalidades da invenção em 15 que o codigo de declaração de dependência de produtor 715 é parte de um outro produtor - referido como produtor de determinação de dependência. Enquanto nas Figuras 7D-E o código fonte orientado por objeto inclui código de declaração de dependência de produtor explícita nos métodos a partir dos quais os produtores de determinação de dependência são instanciados

1 20 no momento de execução pelo runtime para dependências declaradas sem atalho, modalidades alternativas da invenção implementam, adicionalmente ou alternativamente o runtime para incluir código de declaração de depen- dência de produtor genérico, invocado como um ou mais produtores de de- terminação de dependência genéricos para dependências declaradas com 25 atalho. Além disso, embora as Figuras 7C-E sejam ilustradas com referência a ArgumentDependencies, as técnicas ilustradas são aplicáveis aos outros tipos de dependências declaradas descendentemente. Adicionalmente, as Figuras 7F-G ilustram o uso de um produtor de determinação de dependên- cia para uma UpwardDependency e uma WeakIyConstrainedDependency.

30 A Figura 7F é um diagrama de bloco de uma dependência e-

xemplificativa através do uso de uma UpwardDependency com um produtor de determinação de dependência de acordo com uma modalidade da inven- ção. A Figura 7F mostra o produtor 720 tendo dependência de produtor de sequenciamento com relação a um produtor de determinação de dependên- cia 772. O produtor de determinação de dependência pode retornar uma de- pendência de argumento, campo ou sequenciamento declarada ascenden- 5 temente sem subscrição do produtor pai 748 no produtor 720. Adicionalmen- te, tal produtor de determinação de dependência pode implementar uma de- pendência dinâmica (por exemplo, uma dependência contingente que faz a seleção entre os dependentes acima em valores de dados, incluindo entre IDs de argumento, conforme será descrito posteriormente). Embora algumas 10 modalidades da invenção suportem todas essas possibilidades, modalidades alternativas da invenção suportam apenas um subconjunto (por exemplo, apenas dependências de sequenciamento declaradas ascendentemente sem subscrição).

A Figura 7G é um diagrama de bloco de possíveis dependências exemplificativas através do uso de um WeakIyConstrainedDependency com um produtor de determinação de dependência de acordo com uma modali- dade da invenção. A Figura 7G mostra o produtor 720 tendo dependência de produtor de sequenciamento com um produtor de determinação de depen- dência 775. Em algumas modalidades da invenção, o produtor de determi- nação de dependência pode retornar qualquer dos seguintse: 1) uma de- pendência de sequenciamento declarada descendentemente sem subscri- ção de um produtor filho 780; 2) uma dependência de argumento, campo ou sequenciamento declarada ascendentemente sem subscrição de um produ- tor pai 785 com relação ao produtor 720; e 3) uma subscrição adesiva (a ser descrita posteriormente). Adicionalmente, tal produtor de determinação de dependência pode implementar uma dependência dinâmica (por exemplo, uma dependência contingente que faz a seleção entre os dependentes aci- ma de valores de dados, incluindo entre diferentes IDs de argumento, con- forme será descrito posteriormente). Embora algumas modalidades da in- venção suportem todas estas possibilidades, modalidades alternativas da invenção suportam apenas um subconjunto (por exemplo, apenas depen- dências de sequenciamento declaradas ascendentemente sem subscrição). 1 Conforme indicado anteriormente, as dependências de sequen-

ciamento podem ser usadas para uma série de finalidades, inclusive assegu- rar a ordem de execução entre produtores que modificam dados, de um mo- do que o runtime não está consciente e os produtores que consomem aque- 5 Ies dados (um produtor filho pode gravar suas saídas em um modo que re- queira que o método do produtor pai inclua código para acessar aquela saí- da (por exemplo, um método que exerça impacto sobre o ambiente ao afetar uma saída que não é saída de produtor regular e, como tal, que não é detec- tada pelo runtime - como um método que define uma variável global, que 10 define um campo em uma instância que não é a saida do produtor, que e- xerce impacto sobre uma fonte de dados externa, etc.))

Diferentes modalidades podem suportar uma ou mais maneiras de declarar dependências de produtor com respeito a produtores de proprie- dade. Especificamente, em algumas modalidades da invenção, os produto- 15 res que lêem um campo devem ser dependentes do produtor de obtenção de propriedade, enquanto o produtor de obtenção de propriedade deve ser dependente de qualquer produtor que defina o campo pelo qual aquele mé- todo de obtenção de propriedade é responsável. Uma técnica de lidar com esta situação que pode ser usada em modalidades da invenção que supor-

> 20 tam dependências de produtor de sequenciamento é proporcionar, para um método de obtenção de propriedade, uma afirmação de declaração de de- pendência de produtor que crie dependências de produtor de sequenciamen- to em todo método que defina o campo pelo qual aquele método de obten- ção de propriedade é responsável (por exemplo, com respeito à Figura 7G, 25 em que o produtor 780 é um produtor que define um campo e o produtor 720 e o produtor de propriedade responsável por aquele campo, o produtor de determinação de dependência 775 seria gravado para retornar uma depen- dência de sequenciamento descendentemente declarada do produtor 720 do produtor 780). Uma segunda técnica para lidar com esta situação que pode 30 ser usada em modalidades da invenção que suportem tanto dependência de produtor de sequenciamento quanto dependência de produtor declarada as- cendentemente é incluir, na afirmação/código de declaração de dependência de produtor para qualquer método que defina um campo, uma dependência de produtor de sequenciamento declarada ascendentemente (por exemplo, usando UpwardDependency ou WeakIyConstrainedDependency) no método de obtenção responsável por aquele campo (por exemplo, com respeito à 5 Figura 7G, em que o produtor 720 é um produtor que define um campo e o produtor 785 é o produtor de obtenção de propriedade responsável por a- quele campo, o produtor de determinação de dependência 775 seria gravado para retornar uma dependência de sequenciamento ascendentemente decla- rada do produtor pai 785 do produtor 720). Esta segunda técnica permite 10 que o programador do método que define o campo, seja responsável por proporcionar uma dependência de produtor ao método de obtenção adequa- do, em oposição a requerer que aquele programador vá até o método de obtenção e modifique sua afirmação/código de declaração de dependência de produtor.

Ao usar dependências de sequenciamento, quando um dado

produtor se baseia em uma dada variável, aquela variável não deve ser mo- dificada por mais de dos produtores descendentes daquele produtor em uma dada execução de gráficos de produtor (Deve-se notar que através de de- pendências contingentes (a serem descritas), diferentes produtores descen- 20 dentes podem modificar aquela variável durante diferentes execuções dos gráficos produtores atuais). Por exemplo, um produtor de obtenção de pro- priedade não deve depender apenas de um outro produtor que defina o campo pelo qual o produtor de obtenção de propriedade é responsável em uma dada execução do gráfico produtor atual.

Deve-se entender que diferentes modalidades da invenção po-

dem implementar uma ou mais das modalidades da invenção mostrada nas Figuras 7A-F. Por exemplo, uma modalidade da invenção suporta depen- dências declaradas com atalho e sem atalho, ambas usando produtores de determinação de dependência; especificamente, nesta modalidade da inven- 30 ção: 1) o código fonte orientado por objeto inclui código de declaração de dependência de produtor explícita em métodos a partir dos quais os produto- res de determinação de dependência são instanciados no runtime pelo run- * time para dependências declaradas sem atalho; 2) o runtime inclui código de declaração de dependência de produtor genérico que ele invoca como um ou mais produtores de determinação de dependência genéricos para depen- dências contingentes declaradas sem atalho (a ser descrito); e 3) o runtime 5 inclui suporte para ligar diretamente dependências de produtor não- contingentes, declaradas sem atalho (a ser descrito).

Como outro exemplo, uma modalidade da invenção suporta de- pendências de produtor declaradas sem atalho e com atalho usando produ- tores de determinação de dependência; especificamente, nesta modalidade 10 da invenção: 1) o código fonte orientado por objeto inclui código de declara- ção de dependência de produtor explícita em métodos a partir dos quais o produtor de determinação de dependência é instanciado no momento de execução pelo runtime para dependências declaradas sem atalho; e 2) o runtime inclui código de determinação de dependência genérico que ele in- 15 voca como um ou mais produtores de determinação de dependência genéri- cos para dependências declaradas com atalho (a despeito do tipo). Esta úl- tima modalidade permite o tratamento consistente de dependências de pro- dutor e, assim, simplifica o runtime.

Além disso, embora em uma modalidade da invenção a afirma- k·' 20 ção de declaração de dependência de produtor para um método esteja loca- lizada logo acima daquele método no código fonte orientado por objeto, em modalidades alternativas da invenção ela está localizada em outra parte (por exemplo, as afirmações de declaração de dependência de produtor para to- dos os métodos para uma classe são agrupadas juntas dentro da classe, as afirmações de declaração de dependência de produtor para todos os méto- dos em todas as classes, estão agrupadas como uma tabela de dados sepa- rada, etc.). Além disso, embora em uma modalidade da invenção o código de declaração de dependência de produtor seja separado das afirmações de declaração de dependência de produtor, em modalidades alternativas da invenção eles são combinados (por exemplo, o código de declaração de de- pendência de produtor está dentro dos parênteses da afirmação de declara- ção de dependência de produtor, o código de declaração de dependência de produtor está colocado diretamente abaixo da Figura de declaração de de- pendência de produtor e é tratado pelo runtime como uma unidade simples, etc.)

As Figuras 7H-I ilustram a distinção entre diferentes subgráficos que possam existir em um gráfico produtor devido aos produtores de deter- minação de dependência. A Figura 7H ilustra gráficos produtores exemplifi- cativos de produtores padrão, de acordo com uma modalidade da invenção. Especificamente, a Figura 7H mostra um gráfico produtor com nó-raiz S1, um gráfico produtor com nó-raiz S5 e um gráfico produtor com nó-raiz S11.

O produtor padrão S1 tem produtores filho padrão S2, S3 e S4; produtores padrão S2 e S3 têm como produtores filho padrão S7 e S8; o produtor pa- drão S5 tem como produtores filho padrão S4 e S6; e o produtor padrão S11 tem como produtores filhos padrão S6 e S10. Os gráficos produtores exem- plificativos da Figura 7H podem ser descobertos, construídos e resolvidos usando qualquer número de dependências de produtor e produtores de de- terminação de dependência. A Figura 71 ilustra um exemplo de dependên- cias de produtor e produtores de determinação de dependência para desco- brir, resolver e construir o gráfico produtor da Figura 7H. Especificamente, a Figura 71 mostra os gráficos da Figura 7H como sub-graficos de um conjun- to maior de gráficos produtores. Em outras palavras, os gráficos produtores da Figura 71 incluem os gráficos da Figura 7H (referidos como "subgráficos alvo" e ilustrados usando linhas sólidas com seta e formas ovais sólidas) e gráficos que ajudam a descobrir, solucionar e construir os subgráficos alvo (referidos como "subgráficos de decisão e ilustrados usando linhas traceja- das com seta e formas ovais tracejadas). Os subgráficos de decisão na Figu- ra 7H incluem produtores de determinação de dependência (DDPs) 1-11 e produtores padrão S9-10. Na Figura 7, S1 é mostrado como sendo depen- dente de DDPs 1-3, que retornam, respectivamente, dependências de produ- tor declaradas de S1 em S2, S3 e S4; S4 é mostrado como sendo depen- dente de DDP4, que retorna uma dependência de produtor declarada de S5 em S4; S5 é mostrado como sendo dependente de DDP5, que retorna uma dependência de produtor descendentemente declarada de S5 em S6; S3 é * mostrado como sendo dependente de DDP6, que, por sua vez, é dependen- te de DDP8, que retorna uma dependência de produtor declarada descen- dentemente de DDP6 em S9 e S10, que faz com que DDP6 retorne uma dependência declarada descendentemente de S3 em S7; mostra-se S3 co- 5 mo sendo dependente de DDP7, que retorna uma dependência de produtor declarada descendentemente de S3 em S8; mostra-se S8 como sendo de- pendente de DDP9, que retorna uma subscrição adesiva para a qual S6 é um produtor de ativação e S11 é o pai criado (assim, a dependência de pro- dutor de S11 em S6); mostra-se S2 como sendo dependente de DDP10, que 10 retorna uma coleção de dependência de produtor declarada descendente- mente de S2 em S7 e S8; e mostra-se S11 como sendo dependente de DDP11, que retorna uma dependência de produtor declarada descendente- mente de S11 em S10. Deve-se entender que um produtor padrão pode ser tanto parte de um subgráfico alvo e um subgráfico de decisão (por exemplo, 15 vide S10). Vale a pena notar que os subgráficos alvo são acionados por da- dos no sentido que os dados fluem de um produtor padrão para um outro produtor padrão no grafico.

Estrutura de Programação e Execução Exemplificativa A Figura 8A é um diagrama de bloco que ilustra uma primeira

1 · 20 estrutura exemplificativa dentro da qual os aplicativos são fornecidos a usuá- rios finais, de acordo com uma modalidade da invenção. A estrutura mostra- da na Figura 8A inclui três divisões básicas. A primeira divisão inclui a cria- ção do runtime com suporte de programação orientado por gráfico produtor 810. Esta primeira divisão é realizada por programadores com ferramentas 25 de programação altamente avançadas. Ao trabalhar nesta divisão, os pro- gramadores são referidos como programadores de runtime. Ao criar um run- time com suporte de programação orientado por gráfico produtor, os pro- gramadores de runtime incluem suporte para gráficos produtores, assim co- mo suporte para executar os diversos tipos de comandos usados em código 30 de transformação, código de instanciação e código de preparação de dados.

A segunda divisão inclui a criação de código fonte de aplicativo orientado por objeto 820 a ser executado pelo runtime. O código fonte de aplicativo orientado por objeto 820 inclui duas divisões básicas: 1) definições de classe que incluem a lógica comercial expressa em métodos com decla- rações de dependência de produtor 822 (isso pode opcionalmente incluir outra funcionalidade, como uma interface gráfica de usuário - caso em que a interface gráfica com o usuário é gravada usando produtores e declarações de dependência de produtor); e 2) definições de classe que incluem código de cliente expresso nos métodos 824, incluindo código de instanciação (classe, instâncias e produtores de interesse, para causar a geração dos gráficos produtores) 824A, código de preparação de dados 824B (por exem- plo, comandos de definição, como comandos de definição que ativam a so- bregravação de saídas de produtor), comandos de execução global 824C para causar a execução dos gráficos produtores (por exemplo, comandos de execução e obtenção) e qualquer interface gráfica com o usuário necessária 824D (não incluída em 822). As declarações de dependência de produtor são usadas para definir os vínculos entre os produtores durante a definição das classes que incluem a lógica comercial, ao invés de após as instâncias daquelas classes serem criadas. O código fonte orientado por objeto 820 é classe, instância e métodos codificados sólidos que são compilados e execu- tados.

Embora em uma modalidade da invenção seja implementado um comando de execução global, cuja execução causa a execução de todos os gráficos produtores atualmente na estrutura de gráficos produtores 380, mo- dalidades alternativas da invenção implementam alternativamente ou adicio- nalmente um comando de execução específico de gráfico que requer identi- ficação de um dado gráfico de produtor que deve ser executado. Adicional- mente, o comando de execução global pode ser explícito (por exemplo, defi- nir, definir, definir, executar, obter, obter) ou implícito, dependendo da im- plementação do runtime. Por exemplo, um comando de execução global im- plícito pode ser: 1) ativado pelo primeiro comando de obtenção em um pro- dutor de interesse (por exemplo, definir, definir, definir, obter (execução im- plícita), obter); 2) ativado por cada manipulação de dados (definir (execução implícita), definir (execução implícita), definir, (execução implícita)); etc. ^ A segunda divisão é novamente realizada por programadores

com ferramentas de programação avançadas, assim como uma compreen- são dos objetivos comerciais do aplicativo, Ao trabalhar nesta divisão, os programadores são referidos como programadores de aplicativo. Como parte 5 disso, se o aplicativo necessitar de uma interface gráfica com o usuário, os programadores do aplicativo também projetam e codificam a interface gráfica com o usuário para o aplicativo específico; e assim também são referidos como projetistas de aplicativo.

A terceira divisão inclui o uso de programas aplicativos que es- 10 tão sendo executados pelo runtime. A terceira divisão é realizada por usuá- rios finais que não precisam ter qualquer conhecimento de programação. O programa aplicativo pode ser distribuído de diversas maneiras (por exemplo, como código fonte; uma transformação de código fonte, como código de by- tes; como binário, etc). Além disso, o programa aplicativo pode ser distribuí- 15 do para uso autônomo 830 (caso em que todo o programa aplicativo (e run- time, se já não estiver presente) é fornecido a um sistema computacional) e/ou uso cliente/servidor. Em uma modalidade da invenção, uma distribuição cliente/servidor inclui a distribuição das definições de classe que incluem a lógica comercial expressa em métodos com declarações de dependência de >■' 20 produtor 822 ( e runtime se já não estiver presente) para uso servidor 832 e as definições de classe que incluem código cliente expresso em métodos 824 (e runtime, se já não estiver presente) para uso cliente 834, em que o uso cliente 834 em um sistema computacional causa a comunicação com o uso servidor 832 em um sistema servidor.

25 A Figura 8A também mostra um módulo de interface gráfica com

o usuário com Iayout de saída de produtor interativa configurável opcional 840 sendo proporcionada para uso autônomo 830 e uso cliente 834. O códi- go fonte orientado por objeto 820 seria executado pelo runtime para gerar o gráficos produtores e o módulo de interface gráfica com o usuário de Iayout 30 de saída de produtor interativa configurável 840 permite exibir graficamente saídas e interage com os gráficos produtores. Especificamente, o módulo de interface gráfica com o usuário de Iayout de saída de produtor interativa con- figurável 840 inclui: 1) configuração e mapeamento do módulo de interface gráfica com o usuário 844 para permitir a configuração das saídas do Iayout e mapeamento de saídas selecionadas de produtor (por exemplo, áreas da tela a serem usadas, como os dados devem ser exibidos, etc); e 2) um mó-

5 dulo de interface gráfica com o usuário de submissão e interação 846 para submeter o Iayout configurado e permitir a sobregravação de saídas do pro- dução (o que resulta na atualização dos gráficos produtores através de um comando de execução global). Deve-se entender que o módulo de interface gráfica com o usuário de Iayout de saída de produtor interativa configurável 10 840 pode ser criado ou não pela mesma entidade que grava o runtime 810.

A Figura 8B é um diagrama de bloco que ilustra uma segunda estrutura exemplificativa dentro da qual os aplicativos são fornecidos a usuá- rios finais, de acordo com uma modalidade da invenção. A Figura 8B é idên- tica à Figura 8A, com as seguintes exceções: 1) o uso autônomo 830 não 15 está presente; 2) o código fonte orientado por objeto 820 é fornecido ao uso servidor 832, enquanto o código cliente 824 não é fornecido para uso cliente 834; 3) o módulo de interface gráfica com o usuário de Iayout de saída de produtor interativa configurável 840 é fornecido ao uso servidor 832 e não uso cliente 834; e 4) uma interface de cliente com Iayout de saída de produ- 20 tor interativa configurável 885 é fornecida para uso cliente 834. A uma inter- face de cliente com Iayout de saída de produtor interativa configurável 885 é usada para fazer interface com o módulo de interface gráfica com o usuário de Iayout de saída de produtor interativa configurável 840.

A despeito da estrutura usada, em uma modalidade da invenção 25 a estrutura de programação orientada por gráfico produtor oferece a capaci- dade de fazer interface com programas não gravados com declarações de dependência de produtor. Esta capacidade de fazer interface com progra- mas não gravados com declarações de dependência de produtor inclui: 1) uma parte que realiza a chamada (como interface gráfica com o usuário não 30 gravada, de acordo com a programação orientada por gráfico produtor); e 2) uma parte que recebe a chamada (como fonte de dados externos não gra- vada, de acordo com programação orientada por gráfico produtor). A parte que realiza a chamada pode, através de código cliente, emitir comandos de programação orientada por objeto. A parte que recebe a chamada é imple- mentada como parte de produtores que envolve a parte chamada (referidos como "produtores de envoltório"). Executar a parte chamada (como Ier da- 5 dos de uma fonte de dados ou submeter a mudança de dados em uma fonte de dados externa) pode, por sua vez, ativar modificações de instância. Estas mudanças podem ocorrer chamando-se os métodos de definição de proprie- dade no código dos produtores de envoltório. Faz-se com que os produtores de obtenção de propriedade (obtentores) tenham dependências destes pro- 10 dutores de envoltório de modo a ter certeza que as modificações de instân- cia ativadas pelas mudanças que ocorrem em uma fonte de dados externa, sejam propagadas de maneira adequada através do gráfico produtor. Con- forme descrito anteriormente, diferentes modalidades podem suportar uma ou mais maneiras para declarar dependências de produtor com relação a 15 produtores de propriedade. Por exemplo, em algumas modalidades da in- venção que suportam dependências de produtor de sequenciamento, pode- se usar SequencingDependencies para declarar dependências de produtor de sequenciamento declaradas descendentemente de não-subscrição nos produtores de envoltório. Ainda como outro exemplo, em algumas modalida- ^ -20 des da invenção que suportam dependências de produtor de sequenciamen- to e dependências de produtor ascendentemente declaradas de não- subscrição, pode-se colocar UpwardDependencies e/ou WeakIyConstrai- nedDependencies na declaração de dependência de produtor dos produto- res de envoltório para criar dependências de produtor de sequenciamento 25 ascendentemente declaradas de não-subscrição para os produtores de pro- priedade.

As Figuras 8C-F ilustram tomadas de tela exemplificativas e uso do módulo de interface gráfica com o usuário com Iayout de saída de produ- tor interativa configurável 840, de acordo com uma modalidade da invenção. 30 Embora modalidades da invenção sejam descritas com referência ao módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840 proporcionando a configuração, mapeamento e interação com saídas selecionadas dos gráficos produtores atuais na forma de uma planilha, modalidades alternativas da invenção podem ser implementadas para proporcionar, adicionalmente ou alternativamente, suporte para uma outra forma. Adicionalmente, embora modos exemplificativos de realizar a 5 configuração, mapeamento e interação na forma de uma planilha sejam des- critos, de acordo com algumas modalidades, outras modalidades da inven- ção podem realizar estas operações de outras maneiras, com interface dife- rente e/ou com um Iayout de tela diferente. Adicionalmente, a planilha pode suportar qualquer das funcionalidades conhecidas associadas a planilhas 10 (por exemplo, seleção de cor, seleção de fonte, quadros em barra/torta/linha, tabelas pivô, Iayouts de economia, Iayouts de carregamento, etc.)

As Figuras 8C-D ilustram tomadas de tela exemplificativas e uso da livre seleção de célula, de acordo com uma modalidade da invenção, en- quanto as Figuras 8E-F ilustram tomadas de tela exemplificativas e uso de 15 criação de tabela, de acordo com uma modalidade da invenção. Cada uma das Figuras 8C-F inclui uma barra de menus 850 ao longo do topo da tela, uma lista de classes (com seus métodos de obtenção de propriedade) 852 dos produtores no gráfico produtor atual e suas saídas no lado esquerdo da tela, e um visor de configuração e mapeamento 854 que preenche o restante 20 da tela com um Iayout tipo planilha. Em adição, as Figuras 8C-F também mostram a seguinte lista exemplificativa de classes com seus métodos de obtenção de propriedade na lista 852: 1) a classe PESSOA; 2) os métodos de obtenção de propriedade da classe pessoa incluindo NOME (por exem- plo, cadeia), SOBRENOME (por exemplo, cadeia), SEXO (por exemplo, ca- 25 deia), ENDEREÇO (instância da classe ENDEREÇO), ENDEREÇO PRO- FISSIONAL (instância da classe ENDEREÇO), DATA DE NASCIMENTO (por exemplo, data) e IDADE (por exemplo, inteiro); 3) a classe ENDEREÇO; e 4) os métodos de obtenção de propriedade da classe ENDEREÇO incluin- do CIDADE (por exemplo, cadeia), ESTADO (por exemplo, cadeia), CEP 30 (por exemplo, cadeia). Como tal, o gráfico produtor atual inclui produtores das classes PESSOA e ENDEREÇO, assim como produtores cujas saídas são das classes PESSOA e ENDEREÇO. Também vale a pena notar que o método de obtenção de propriedade IDADE calcula uma idade com base na saída do método de obtenção de propriedade DATA DE NASCIMENTO; co- mo tal, um produtor instanciado a partir do método de obtenção de proprie- dade IDADE será dependente de um produtor instanciado a partir do método 5 de obtenção de propriedade DATA DE NASCIMENTO.

As Figuras 8C-D mostram o seguinte texto livre inserido nas cé- lulas consecutivas da primeira coluna do visor: CLIENTE, PRIMEIRO NOME, ÚLTIMO NOME, DATA DE NASCIMENTO e IDADE; embora as figuras 8E-F mostrem o seguinte: 1) texto livre inserido na primeira fileira do visor - LISTA 10 DE CLIENTES; e 2)texto livre inserido em células consecutivas da segunda fileira do visor PRIMEIRO NOME, ÚLTIMO NOME, DATA DE NASCIMENTO e IDADE.

A Figura 8C ilustra uma tomada de tela exemplificativa e uso de seleção de célula livre com o módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840, de acordo com uma modalidade da invenção. A Figura 8C mostra um conjunto de mapeamentos 856 da classe PESSOA e métodos selecionados de obtenção de proprieda- de da classe PESSOA para diferentes células do visor. Especificamente, a classe PESSOA é mapeada para a célula à direita do texto livre CLIENTE. Como parte desta ação, algumas modalidades da invenção solicitam que o usuário selecione a partir de um de uma série de filtros suportados (mostra- do como seleção de filtro 858) (por exemplo, lista suspensa, setas de rola- mento, etc.) Estes filtros permitem a seleção de uma ou mais chaves de ins- tância de produtores da classe selecionada ou uma ou mais chaves de ins- tância dos produtores cuja classe de saída é a classe selecionada. Embora algumas modalidades da invenção suportem uma série de filtros, outras mo- dalidades da invenção têm como padrão 1 (e permitem que o usuário esco- lha se quer selecionar um diferente) ou suportam apenas um e não necessi- tam realizar seleção de filtro 858. Os mapeamentos 856 também mostram que os métodos de obtenção de propriedade PRIMEIRO NOME, ÚLTIMO NOME, DATA DE NASCIMENTO e IDADE da classe PESSOA, são respec- tivamente mapeados para as células adjacentes às células com texto livre correspem quente. Tal mapeamento pode ser realizado com qualquer núme- ro de técnicas bem conhecidas, incluindo arrastar e liberar, digitar em um campo GUI, etc.

A Figura 8D ilustra uma outra tomada de tela exemplificativa e uso de seleção de célula livre com o módulo de interface gráfica com o usuá- rio com Iayout de saída de produtor interativa configurável 840 de acordo com uma modalidade da invenção. A Figura 8D mostra que a célula para a qual a classe PESSOA foi mapeada, permite a seleção de instância 854. Especificamente, com base no filtro usado para esta célula, o usuário tem a oportunidade de selecionar uma instância da classe PESSOA a partir de uma lista que inclui as chaves de instância dos produtores da classe PES- SOA e as chaves de instância dos produtores que produzem a classe PES- SOA. A seleção de uma instância da classe PESSOA (ou a existência de uma única instância) resulta na população automática das células, para as quais os métodos de obtenção de propriedade da classe PESSOA foram mapeados, com as saídas dos métodos de obtenção de propriedade corres- pem quentes daquela instância. Este preenchimento da tabela com base nas instâncias da classe PESSOA é rotulado 858. No exemplo da Figura 8D, as células para as quais os métodos de obtenção de propriedade NOME, SO- BRENOME, DATA DE NASCIMENTO e IDADE da classe PESSOA foram mapeados,sendo preenchidos respectivamente com JOHN, SMITH, 7/20/1990 e 16.

A Figura 8D também mostra que as células do visor para as quais os métodos de obtenção de propriedade foram mapeados, podem ser 25 sobregravadas. À guisa de exemplo, a Figura 8D mostra que se a célula pa- ra a qual o método de obtenção de propriedade DATA DE NASCIMENTO é mapeado, for sobregravada, então causara a sobregravação da saída do produtor cuja saída está preenchendo, no momento, aquela célula, invoca- ção de um comando de execução global (o que resuitaria em uma reexecu- 30 ção do produtor cuja saída está preenchendo atualmente a célula para a qual o método de obtenção de propriedade IDADE, é mapeado) e qualquer atualização necessária do visor. * A Figura 8E ilustra uma tomada de tela exemplificativa e uso de

criação de tabela com o módulo de interface gráfica com o usuário com Ia- yout de saída de produtor interativa configurável 840, de acordo com uma modalidade da invenção. A Figura 8E mostra que uma operação de seleção de zona e orientação 864 é realizada para identificar uma tabela vertical de três linhas diretamente sob as células com texto livre NOME, SOBRENOME, DATA DE NASCIMENTO e IDADE (ilustrada com uma linha tracejada es- pessa em torno dessas células). Modalidades diferentes da invenção podem suportar o usuário realizar esta operação em uma série de maneiras (inclu- indo: 1- seleção de uma área com um dispositivo de entrada como um mou- se; e 2- seleção entre uma tabela vertical, horizontal ou pivô com uma inter- face como um menu suspenso - assumindo que múltiplas orientações são suportadas). A Figura 8E também mostra um conjunto de mapeamentos 866 ou métodos de obtenção de propriedade selecionados da classe PESSOA para diferentes células do visor. Especificamente, os mapeamentos 866 mostram que os métodos de obtenção de propriedade NOME, SOBRENO- ME, DATA DE NASCIMENTO e IDADE da classe PESSOA, são respectiva- mente mapeados para as células diretamente abaixo das células com texto livre correspem quente. ι ,20 A Figura 8F ilustra uma outra tomada de tela exemplificativa e

uso de criação de tabela com o módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840, de acordo com uma modalidade da invenção. Os mapeamentos 866 resultam no preenchi- mento automático das colunas da tabela para as quais os métodos de ob- 25 tenção de propriedade da classe PESSOA foram mapeados, com as saídas dos métodos de obtenção de propriedade correspem quentes das instâncias daquela classe. Este preenchimento da tabela com base nas instâncias da classe PESSOA é rotulado 868. No exemplo da Figura 8D, as colunas para as quais os métodos de obtenção de propriedade NOME, SOBRENOME, 30 DATA DE NASCIMENTO e IDADE da classe PESSOA foram mapeados com as seguintes fileiras de dados: 1) STEVE, COLLINS, 7/20/1990 e 16; 2) JENNIFER, ADAMS, 7/20/1990 e 16; e 3) JOHN, SMITH, 7/20/1985, e 21. Como na Figura 8D, a Figura 8F mostra que as células do visor para as quais os métodos de obtenção de propriedade foram mapeados, podem ser sobregravadas. À guisa de exemplo, a Figura 8F mostra que se a célula da segunda fileira da coluna para a qual o método de obtenção de 5 propriedade DATA DE NASCIMENTO é mapeado, for sobregravada, então causará a sobregravação da saída do produtor cuja saída está preenchendo atualmente aquela célula, invocação de um comando de execução global (o que resulta em uma reexecução do produtor cuja saída está preenchendo atualmente a célula para a qual o método de obtenção de propriedade IDA- 10 DE é mapeado) e qualquer atualização necessária do visor.

As Figuras 8C-F ilustram telas exemplificativas geradas pelo módulo de interface gráfica com o usuário de configuração e mapeamento 842. As telas geradas pelo módulo de interface de usuário gráfica de sub- missão e interação são iguais, com a exceção que a lista de classes (com 15 seus métodos de obtenção de propriedade) 852 e o visor de configuração e mapeamento 854 são substituídos por um visor de submissão e interativo não mostrado) que contém a mesma imagem que o visor de configuração e mapeamento 854 exibia (sendo que a diferença é o item de mapeamento, que não está mais disponível).

Esquemas Exemplificativos de Distribuição de Runtime

As Figuras 9A-C ilustram diversos esquemas para distribuir um runtime com suporte de programação orientada por gráfico produtor. Deve- se entender que estes esquemas de distribuição são exemplificativos e, as- sim, outros esquemas estão dentro do escopo da invenção.

A Figura 9A é um diagrama de bloco que ilustra um primeiro es-

quema para distribuir um runtime com suporte de programação orientada por gráfico produtor, de acordo com uma modalidade da invenção. Na Figura 9A,

o código fonte orientado por objeto 905 (que inclui declarações de depen- dência de produtor) é mostrado no topo de um runtime com suporte de pro- gramação orientada por gráfico produtor 910, que está no topo de um runti- me com carregamento de classe, instância de classe dinâmica, invocação de método simples dinâmica, e introspecção de classe/método 915, que está no I 74

* topo de um sistema operacional 920. Na Figura 9A, o runtime 910 trabalha com o runtime 915. Embora possa ser usado qualquer mecanismo para permitir que o runtime 910 funcione com o runtime 915, é descrito um recur- so de metadados, à guisa de exemplo. Um recurso de metadados permite 5 que informação adicional seja adicionada ao código fonte, informação essa que é usada por ferramentas de desenvolvimento. Por exemplo, Metadata Facility para especificação Java define um API para campos de anotação, métodos e classes como tendo atributos particulares que indicam que eles devem ser processados de maneiras especiais por ferramentas de desen- 10 volvimento, ferramentas de distribuição ou bibliotecas de runtime (Java Spe- cification Request 175). Neste exemplo, um programador que programe o código fonte orientado por objeto 905 adicionaria anotações a métodos na forma de declarações de dependência de produtor. Como essas anotações são controlada sem intervenção pelo runtime 915 até o runtime 910, o runti- 15 me 910 dita a sintaxe das declarações de dependência de produtor. Na Figu- ra 9A, os runtimes 910 e 915 podem ser desenvolvidos e/ou distribuídos por diferentes organizações.

A Figura 9B é um diagrama de bloco que ilustra um segundo esquema para distribuir um runtime com suporte de programação orientada

1 20 por gráfico produtor de acordo com uma modalidade da invenção. Na Figura 9B, o código fonte orientado por objeto 925 (que inclui declarações de de- pendência de produtor) é mostrado no topo de um runtime (com carrega- mento de classe, instância de classe dinâmica, invocação de método sim- ples dinâmica e íntrospecção de classe/método, assim como suporte de pro- 25 gramação orientada por gráfico produtor) 930, que está no topo de um sis- tema operacional 935. Em comparação com a Figura 9A, o runtime 910 e 915 foram combinados em um único runtime 930. Como resultado desta combinação, o runtime 930 dita a sintaxe das declarações de dependência de produtor. Assim, um programador que programe o código fonte orientado 30 por objeto 925 acrescenta as declarações de dependência de produtor na sintaxe requerida.

A Figura 9C é um diagrama de bloco que ilustra um terceiro es- quema para distribuir um runtime com suporte de programação orientada por gráfico produtor, de acordo com uma modalidade da invenção. Na Figura 9C, o código fonte orientado por objeto 940 (que inclui declarações de de- pendência de produtor) é mostrado no topo de um runtime de sistema ope- 5 racional (com carregamento de classe, instanciação de classe dinâmica, in- vocação de método simples dinâmica e introspecção de classe/método, as- sim como suporte de programação orientada por gráfico produtor) 945. Em comparação com a Figura 9B, o runtime 920 e o sistema operacional 935 foram combinados em uma unida entidade. Como resultado desta combina- 10 ção, o runtime de sistema operacional 945 dita a sintaxe das declarações de dependência de produtor. Assim, um programador que programe o código fonte orientado por objeto 940, acrescenta as declarações de dependência de produtor na sintaxe requerida.

Embora sejam descritas modalidades em que o runtime tem car- regamento de classe, instância de classe dinâmica, invocação de método simples dinâmica e introspecção de classe/método, modalidades alternativas podem incluir mais ou menos características (por exemplo, clonagem de ins- tância, proxies dinâmicos, conversões do tipo primitivas, etc.)

Vantagens Exemplificativas Em uma modalidade da invenção, as dependências de produtor

são declaradas para métodos como uma maneira de especificar sequencia- mento de invocação de método usando as instâncias apropriadas (em que as instâncias apropriadas incluem as instância para usar como argumentos, as instâncias para serem usadas por métodos de instância e as instância de 25 meta classe, usadas por métodos de classe) sem usar código de sequenci- amento de invocação manual. Efetivamente, o trabalho de gerar uma parte ou todo o código de sequenciamento de invocação manual é substituído por:

1) trabalho feito pelo programador de aplicativo para gravar as declarações de dependência; e 2) trabalho feito pelo runtime para descobrir e construir o gráfico produtor e executar os produtores daqueles gráficos produtores. Em outras palavras, a lógica que estava contida anteriormente no código de se- quenciamento de invocação manual pode ser descoberta pelo runtime du- ■ rante o runtime com base em declarações de dependência de produtor. As- sim, as declarações de dependência de produtor informam ao runtime que métodos de que instâncias com que argumentos executar e quando, para fins de sincronização. Embora o esforço para gravar o runtime seja relativa- 5 mente grande, ele só precisa ser gravado uma vez pelo fato de que ele pode ser usado para executar qualquer aplicativo orientado por objeto gravado para o runtime; por outro lado, para um aplicativo típico, o esforço para gra- var as declarações de dependência de produtor é relativamente baixo em comparação com gravar o código de sequenciamento de invocação manual. 10 Redução de Erros de Programação

A programação orientada por gráfico produtor tipicamente reduz os custos associados à depuração e/ou sintonização de desempenho do código de sequenciamento de invocação manual. Isso é verdadeiro pelo menos pela razão que a infraestrutura de um programa aplicativo é, concei- 15 tualmente, um conjunto de gráficos não formalizados de métodos de trans- formação de objetos (a saída de um método associada a um objeto é a en- trada em outro e assim por diante) que operam sobre entradas específicas. As declarações de dependência de produtor e o runtime com suporte de programação orientada por gráfico produtor formaliza estes gráficos com 20 gráficos produtores. Assim, para cada oportunidade de os dados mudarem,

o programador de aplicativo não precisa considerar seu efeito e gravar o có- digo de sequenciamento de invocação manual para fazer com que os méto- dos de transformação apropriados das instâncias apropriadas sejam invoca- dos na ordem apropriada com as entradas apropriadas. Em outras palavras, 25 para cada oportunidade para os dados mudarem, um programador de aplica- tivo não precisa considerar que gráficos são afetados, assim como que mé- todos de transformação de instâncias dentro daqueles gráficos são afetados. Ao invés disso, o módulo de geração de gráfico produtor automatizado des- cobre e constrói os gráficos produtores e o módulo de execução de gráfico 30 produtor reexecuía os gráficos produtores, conforme necessário, para refleti- rem as mudanças nos dados. Esta automação ajuda os programadores de aplicativo a evitar erros como: 1) invocar os métodos de transformação a- propriados das instâncias apropriadas na ordem errada; 2) esquecer de in- cluir comandos para fazer com que um ou mais métodos de transformação requeridos de instância em um gráfico sejam invocados em resposta a al- guns dados serem mudados; 3) incluir comandos para fazer com que méto- dos de instâncias de transformação desnecessários sejam invocados em resposta à mudança de algum dado (por exemplo, incluir comandos para invocar métodos de transformação de instâncias que não são parte de um gráfico afetado pela mudança nos dados; incluir comandos para invocar mé- todos de transformação de instâncias que são parte de um gráfico afetado pela mudança nos dados, mas eles próprios não são afetados; etc.)

Sincronização

Conforme descrito anteriormente, fazer o cache de saídas de produtor durante a execução, permite a sincronização. Assim, em termos de comparação com o padrão do observador, as declarações de dependência de produtor notificam um runtime com suporte de programação orientada por gráfico produtor das dependências e o runtime determina que produtores e quando chamar de volta.

Capacidade de Explicar Totalmente Qualquer Resultado

Em uma modalidade da invenção, um módulo de explora- ção/visualização (não mostrado) é incluído como parte do runtime. O módulo de exploração/visualização proporciona uma interface gráfica com o usuário que, através da interação por um usuário final, permite explorar até o gráfico produtor (fazendo o circuito de um gráfico produtor a partir do nó-raiz) para ver as saídas dos diversos produtores do gráfico produtor. Isso permite que um usuário final vide as diversas saídas que contribuíram para a saída do produtor de interesse, incluindo os valores de dados e dependências (retor- nadas pelos declarações de dependência de produtor). Além disso, em uma modalidade da invenção, este módulo de exploração/visualização proporcio- na a capacidade de o usuário final ver o codigo dentro dos métodos dos pro- dutores, os valores das instâncias dos produtores e/ou o conteúdo das clas- ses dos produtores.

Assim, o módulo de exploração/visualização proporciona uma * variedade de atividades pós-processamento, inclusive depuração, explica- ção de saídas, etc.

Aplicação Prática/Efeito Técnico/Aplicabilidade Industrial Exemplares

Existe uma série de aplicações práticas exemplificativas dos di- 5 ferentes aspectos e modalidades da invenção. Por exemplo, o runtime, como parte da execução de programas aplicativos, causa a recuperação de infor- mações de uma mídia de armazenamento em máquina (por exemplo, aces- sando o código fonte orientado por objeto, incluindo as declarações de de- pendência de produtor), o armazenamento de informações em uma mídia de 10 armazenamento em máquina (por exemplo, armazenamento de estruturas de dados como a estrutura de gráfico produtor, etc.), a operação de recursos de processamento de hardware, a provisão das saídas do(s) produtor(es) de interesse (por exemplo, através de uma interface gráfica com o usuário, ar- mazenamento em mídia de armazenamento em máquina, transmissão, etc.) 15 Em um sentido, a atividade de pré-processamento inclui a gravação de tal programa aplicativo e/ou a provisão de dados (dados estes que podem re- presentar qualquer número de itens físicos e/ou práticos, como valores fi- nanceiros, valores geográficos, valores meteorológicos, valores atuariais, valores estatísticos, medidas físicas, valores de estado de máquina, etc.),

^ 20 embora a atividade de pós-processamento inclua a provisão de resultados (resultados estes que podem representar qualquer número de itens físicos e/ou práticos, como análise financeira, análise geográfica, análise meteoro- lógica, análise atuarial, análise estatística, medidas industriais, informações de controle da máquina, etc. À guisa de exemplo específico, a atividade de 25 pós-processamento pode ser fornecida por: 1- o módulo de visualização do gráfico produtor 1062 da Figura 10 para exibir graficamente uma representa- ção do gráfico produtor atual gerado pelo runtime; e/ou 2 - módulo de inter- face gráfica com o usuário com Iayout de saída de produtor interativa confi- gurável 840 (vide também, módulo de interface gráfica com o usuário de Ia- 30 yout de saída de produtor interativa configurável 1085 da Figura 10) para exibir graficamente saídas de e interagir com os gráficos produtores.

Como outro exemplo, o programa aplicativo com declarações de dependência de produtor, quando executado pelo runtime, representa os itens físicos/práticos e causa as operações descritas acima. À guisa de e- xemplo específico, estas declarações de dependência de produtor fazem com que as estruturas de dados sejam formadas em mídia de armazena- 5 mento em máquina responsiva à sua execução pelo runtime. Além disso, as declarações de dependência de produtor são armazenadas e recuperadas da mídia de armazenamento em máquina junto com o programa aplicativo. Adicionalmente, estas declarações de dependência de produtor representam relações entre os produtores, enquanto os produtores representam opera- 10 ções a serem realizadas (métodos) e instâncias. As instâncias na programa- ção orientada por objeto pode ser usada para representar itens físicos e/ou práticos, enquanto os produtores representam operações a serem realizadas sobre estas representações.

À guisa de um outro exemplo, um conjunto de um ou mais pro- 15 gramas aplicativos e o runtime, implementam software de gerenciamento de risco cobrindo câmbio estrangeiro, equidade, taxa de juros, crédito, inflação, mercadoria e produtos compostos. Estes produtos variam de dinheiro e pro- dutos comuns físicos até produtos derivados exóticos e complexos. Também está incluído um conjunto de modelos de avaliação matemática para estes 20 produtos e seus dados de mercado associados, rotinas de geração de en- tradas de pagamento e contabilidade e seus modelos de calibração associa- dos observáveis e suas entradas brutas associadas

À guisa de um outro exemplo, um conjunto de um ou mais pro- gramas aplicativos e o runtime podem implementar um processador de texto, 25 uma planilha, um software de comunicação/e-mail, um software de visualiza- ção de fotos, um software de varredura de vírus, um executador de mídia, um servidor de banco de dados, um jogo, um aplicativo industrial, um aplica- tivo de ferramenta de projeto auxiliado por computador e/ou um sistema ope- racional. Obviamente, os programas aplicativos podem ser implementados 30 para realizar uma série de outras tarefas.

Implementações Exemplificativas

À guisa de ilustração, serão descritas modalidades exemplificati- * vas da invenção que suportam dependências, dependências dinâmicas (in- clusive dependências contingentes e dependências de subscrição), produto- res de determinação de dependência explícita para dependências declara- das com atalho e para dependências declaradas sem atalho, nos produtores 5 de determinação de dependência para dependências declaradas com atalho, chaves de classe, chaves de instância, chaves de método, comandos de sobregravação/cancelamento de sobregravação (que são tipos de comandos de definição) e comandos de execução global. Em adição, as modalidades exemplificativas suportam, opcionalmente, um módulo de visualização inte- 10 rativo de gráfico produtor e execução incrementai. Obviamente, modalidades alternativas da invenção podem implementar mais, menos e/ou diferentes características.

A Figura 10 é um diagrama de bloco de uma implementação e- xemplificativa, de acordo com uma modalidade da invenção. Na Figura 10, a 15 linha de divisão tracejada 1000 separa um cliente de runtime 1002 de um runtime com suporte de programação orientada por gráfico produtor 1004.

O fluxo de execução lógica do cliente de runtime 1002 inclui os blocos 1010, 1020, 1025, 1030 e 1035 e o runtime com suporte de progra- mação orientada por gráfico produtor 1004 inclui, respectivamente, os blocos 20 correspem quentes 1095, 1098, 1040 e 1070; embora uma linha sólida com seta represente uma relação causai direta do bloco 1035 do fluxo de execu- ção lógica do cliente de ert 1002 com o bloco 1070 do runtime com suporte de programação orientada por gráfico produtor 1004, linhas pontilhadas com seta ilustram uma relação causai dos blocos 1010, 1020, 1025 e 1030 do 25 cliente de runtime 1002 com os blocos 1095, 1098, 1040 e 1045, do runtime com o suporte de programação orientada por gráfico produtor 1004. Depen- dendo da modalidade da invenção, estas últimas relações causais podem ser diretas ou indiretas. Por exemplo, similar à Figura 6, uma causalidade indireta opcional através do uso de um registro de comando (não mostrado) 30 e/ou registro de sobregravação 1047, pode ser usada. Blocos adicionais 1095 e 1098 são tracejados porque eles podem ser parte, opcionalmente, de um bloco diferente, dependendo da modalidade da invenção (por exemplo, bloco 1095 pode ser parte do bloco 1098; o bloco 1098 pode ser parte do bloco 1040; os blocos 1095 e 1098 podem ser parte do bloco 1040). De mo- do similar, o bloco 1045 é tracejado porque ele pode ser opcionalmente par- te de um bloco diferente, dependendo da modalidade da invenção (por e- 5 xemplo, bloco 1045 pode ser parte do bloco 1070).

Na Figura 10, o runtime 1002 inclui definições de classe que in- cluem lógica comercial 1010 tendo dados 1012, métodos 1014, declarações de dependência de produtor 1016 e, opcionalmente, chaves de classe 1090. As definições de classe 1010 são classes em uma linguagem de programa- 10 ção orientada por objeto e assim, incluem definições para dados 1012 e mé- todos 1014. Em adição, estas definições de classe 1010 incluem declara- ções de dependência de produtor 1016 para o método 1014, conforme des- crito anteriormente. Adicionalmente, em uma modalidade da invenção, cada classe pode ter uma chave de classe 1090 para fins de rastreamento.

O novo módulo de classe 1095 do runtime 1004 carrega e exa-

mina as definições de classe 1010 (por exemplo, em resposta a novos co- mandos de classe). Este carregamento e instrospecção podem ser feitos usando qualquer número de técnicas bem conhecidas ou futuramente de- senvolvidas, incluindo aquelas para carregar seletivamente classes para fins 20 de otimização. O carregamento das classes pelo novo módulo de classe 1095 é ilustrado pelas classes 1054 do runtime 1004. Como parte de carre- gar e examinar as classes 1054, o novo módulo de classe 1095 também car- rega e examina as declarações de dependência de produtor 1016, conforme ilustrado por métodos e declarações de dependência de produtor 1056 nas 25 classes 1054. O novo módulo de classe 1095 também mantém uma estrutu- ra de rastreamento de classe 1092 que é usada para rastreamento das clas- ses usando as chaves de classe. Assim, a estrutura de rastreamento de classe 1092 mantém uma correspondência entre as chaves de classe e refe- rências nas classes 1054. Adicionalmente, o novo módulo de classe 1095 30 também mantém uma estrutura de rastreamento de método 1058 que é usa- do para rastreamento de métodos usando as chaves de método. Assim, a estrutura de rastreamento de método 1058 mantém uma correspondência * entre as chaves de método e referências aos métodos, assim como informa- ções referentes às declarações de dependência de produtor.

O cliente de runtime 1002 também inclui comandos de instancia- ção de instância com chaves de instância 1020. O novo módulo de instância 5 1098 do runtime 1004 instancia as instâncias designadas pelos comandos de instanciação de instância com chaves de instância 1020 (por exemplo, em resposta a novos comandos de instância). Esta instanciação de instân- cias pode ser feita usando qualquer número de técnicas bem conhecidas ou futuramente desenvolvidas, incluindo aquelas para instanciar seletivamente 10 instâncias para fins de otimização. Como parte desta instanciação de instân- cias, o novo módulo de instância 1098 acessa a estrutura de rastreamento de classe 1092 usando uma chave de classe para acessar a classe apropri- ada a partir das classes 1054. A instanciação das instâncias pelo novo mó- dulo de instância 1098 é ilustrada pelas instâncias 1052 do runtime 1004. O 15 novo módulo de instância 1095 também mantém uma estrutura de rastrea- mento de instância 1065 que é usada para rastrear as instâncias usando as chaves de instância. Assim, a estrutura de rastreamento de instância 1065 mantém uma correspondência entre as chaves de instância e as referências nas instâncias 1052. Conforme indicado anteriormente, o novo módulo de ^ 20 classe 1095 pode ser parte do novo módulo de instância 1098 pelo fato de que as classes 1054 podem ser instanciadas em resposta a comandos de instanciação de instância 1020, em oposição a novos comandos de classe separados.

O cliente de runtime 1002 também inclui comandos de instancia- 25 ção de produtor com chaves de produtor 1025. O módulo de geração de grá- fico produtor automatizado 1040 de runtime 1004 instancia produtores de- signados pelos comandos de instanciação de produtor com chaves de pro- dutor 1025 (por exemplo, em resposta a novos comandos de produtor que designam o conjunto atual de produtores de interesse). Além disso, o módu- 30 Io de geração de gráfico produtor automatizado 1040 também descobre, constrói e, opcionalmente, resolve os gráficos produtores em resposta ao conjunto atual de produtores de interesse, conforme descrito anteriormente. Em uma modalidade da invenção, uma chave de produtor compreende uma chave de classe, uma chave de instância e chave de método. Como parte desta instanciação de produtores, o módulo de geração de gráfico produtor automatizado 1040: 1) acessa a estrutura de rastreamento de classe 1092 5 usando a chave de classe para acessar a classe apropriada das classes 1054; 2) acessa a estrutura de rastreamento de instância 1065 usando a chave de instância para acessar a instância apropriada a partir das instân- cias 1052; e 3) acessa a estrutura de rastreamento de método usando a chave de método para acessar a afirmação de declaração de dependência 10 de produtor apropriada. A instanciação dos produtores designados pelos comandos de instanciação de produtor com chaves de produtor 1025 e ins- tanciação dos produtores descobertos e construção do gráfico produtor, é ilustrada pela estrutura de gráfico produtor 1060 do runtime 1004. Assim, em uma modalidade da invenção, as chaves de produtor identificadas pelos co- 15 mandos de instância de produtor com chaves de produtor 1025 e aquelas descobertas através da geração de gráfico produtor, são armazenadas na estrutura de gráfico produtor 1060, junto com informações adicionais para representar o gráfico produtor atual.

Conforme descrito anteriormente, os blocos 1095 e 1098 podem 20 ser parte do bloco 1040 e, assim, a decisão referente a que classes, instân- cias e produtores para carregar/instanciar é ativada por aqueles produtores que estão no gráfico produtor atual. Em tal modalidade da invenção, o carre- gamento/instanciação de classe, instâncias e produtores é otimizada e é cê nt ri ca para produtor.

O cliente de runtime 1002 também inclui comandos de prepara-

ção de dados, incluindo comandos de sobregravação/cancelamento de so- bregravação de saída de produtor 1030. Os comandos de sobregrava- ção/cancelamento de sobregravação incluem a chave de produtor do produ- tor a ser sobregravado/não sobregravado, assim como os valores de sobre- 30 gravação ao serem sobregravados. O módulo de saída do produtor de so- bregravação 1045 do runtime 1004 faz com que os produtores designados pelos comandos de sobregravação/cancelamento de sobregravação de pro- ^ dutor sofram sobregravação/cancelamento de sobregravação. Esta causali- dade pode ser indireta ou direta.

No caso de causalidade indireta, o módulo de saída de produtor de sobregravação 1045 preenche o registro de sobregravação 1047 quanto 5 a consumo de módulo de execução de gráfico produtor 1070. No caso de causa direta, o módulo de saída de produtor de sobregravação 1045 acessa

o cache de saída de produtor 1097 da estrutura de gráfico produtor 1060 e as instâncias 1052. Especificamente, conforme descrito com referência ao módulo de saída do produtor de sobregravação 390, em uma modalidade, os produtores podem ser classificados como produtores de propriedade ou pro- dutores de método; assim, o módulo de saída de produtor de sobregravação 1045 pode incluir um módulo de saída de produtor de propriedade (não mos- trado) para produtores de propriedade sobregravados e um módulo de saída de produtor de método de sobregravação (não mostrado) para produtores de método sobregravados; a sobregravação de um método de produtor faz com que o valor sobregravado seja armazenado no cache de saída de produtor 1097 da estrutura de gráfico produtor 1060 e seja armazenado nos dados da instância apropriada das instâncias 1052, enquanto que a sobregravação de um produtor de método faz com que o valor sobregravado seja armazenado >■ 20 no cache de saída de produtor 1097.

Em uma modalidade da invenção, os produtores podem não ser sobregravados antes de um gráfico produtor do qual serão parte, ter sido inicialmente executado (assim, o produtor já terá sido instanciado como re- sultado de ser designado como um produtor de interesse ou como resultado 25 de ser descoberto pelo módulo de geração de gráfico produtor automatizado 1040). No entanto, nas modalidades mostradas na Figura 10, os produtores podem ser sobregravados antes da execução inicial ao serem instanciados e sobregravados com um comando de sobregravação de produtor. Tipicamen- te, tal produtor sobregravado eventualmente, se tornará parte de um gráfico 30 produtor através do processo de descoberta (por exemplo, quando uma de- pendência dinâmica é resolvida). Em algumas modalidades da invenção, esta preparação de dados também pode incluir outros tipos de comandos de definição. O módulo de saída de produtor de sobregravação 1045 é mostra- do como uma caixa tracejada porque ele pode não estar presente em moda- lidades alternativas da invenção.

A(s) estrutura(s) de gráfico(s) produtor(es) 1060 também in- clui(em), opcionalmente, marcação de execução incrementai 1080 para al- gumas modalidades da invenção que suportam execução incrementai. Con- forme descrito anteriormente com referência à marcação de execução in- crementai 382 da Figura 3B, as marcações de execução incrementais 1080 são usadas para auxiliar a execução incrementai do gráfico produtor na exe- cução além da execução inicial. Diferentes modalidades da invenção que utilizam a marcação de execução incrementai 382, as usam de diferentes maneiras. Por exemplo, em tal modalidade da invenção que tem um registro de comando, o registro é usado para rastrear que produtores foram adicio- nados e/ou modificados e a marcação de execução incrementai 382 é usada para marcar aqueles produtores que são afetados (ascendentes dos produ- tores modificados ou adicionados, e, assim, dependentes deles). Como outro exemplo, em uma tal modalidade da invenção que não tem um registro de comando, a marcação de execução incrementai 382 é usada para marcar aqueles produtores que são adicionados ou modificados, assim como aque- Ies que são ascendentes dos produtores modificados ou adicionados (e, as- sim, dependente deles). Como outro exemplo, em tal modalidade da inven- ção que não tem um registro de comando, modificações e adições de produ- tores são feitas imediatamente e a marcação de execução incrementai 382 é usada para marcar aqueles produtores que são ascendentes dos produtores modificados ou adicionados (e, assim, dependentes deles). Embora tenham sido descritas modalidades da invenção que suportam execução incrementai e uso de marcação de execução incrementai, outras modalidades da inven- ção suportam execução incrementai que não usa marcação de execução incrementai (por exemplo, um registro de comando é usado para rastrear que produtores foram adicionados ou modificados e uma lista de produtores de início de execução é mantida em um registro de início de execução; em que o módulo de execução de gráfico produtor 1070 começa a partir dos * produtores de início de execução e acha seu caminho até os ascendentes do gráfico produtor até o topo; à guisa de exemplo e não de limitação, esta modalidade da invenção será descrita posteriormente com relação às Figu- ras 15-25.

O cliente de runtime 1002 também inclui comandos de execução

globais 1035. O módulo de execução de gráfico produtor 1070 do runtime 1004 executa o gráfico produtor. Como tal, o módulo de execução de gráfico produtor 1070 modifica o cache de saída de produtor 1097 (no caso de pro- dutores de propriedade e produtores de método), usa a marcação de execu- 10 ção incrementai 1080 (se estiver presente) e modifica os dados das instân- cias 1052 (no caso de métodos de propriedade). Diversas técnicas foram discutidas anteriormente para executar os produtores do gráfico produtor e são aplicáveis aqui. Por exemplo, em modalidades em que um registro de comando é implementado, o registro de comando é consumido e então o 15 gráfico produtor é executado. Adicionalmente, em modalidades da invenção que suportam a possibilidade de dependências não solucionadas, o módulo de execução de gráfico produtor 1070 inclui módulo de dependência dinâmi- ca 1075, que pode invocar o módulo de geração de gráfico produtor automa- tizado 1040.

1 20 A Figura 10 também mostra um módulo de visualização de gráfi-

co produtor opcional 1062 que fornece um mecanismo (por exemplo, uma interface gráfica com o usuário) por meio do qual um programador/usuário pode visualizar o gráfico produtor e as saídas de produtor da estrutura de gráfico produtor. Adicionalmente, a Figura 10 mostra um módulo de interface 25 gráfica com o usuário com Iayout de saída de produtor interativa configurável opcional 1085 para proporcionar uma interface gráfica com o usuário (inclu- indo a invocação dinâmica de blocos 1030 e 1035), que representa o módulo de interface gráfica com o usuário com Iayout de saída de produtor interativa configurável 840.

30 Em modalidades da invenção que usam um registro de coman-

do, diferentes gatilhos podem ser usados para ativar diferentes ações. Por exemplo, os comandos de instanciação de produtor podem ser registrados e processados em lote em resposta a um comando explícito (registro inicial e registro final), um comando de execução global explícito (o registro começa automaticamente na inicialização e após cada comando de exu global explí- cito, e cada registro é processado em resposta ao comando de execução global explícito seguinte), um comando de preparação de dados explícitos, etc. Similarmente, os comandos de preparação de dados podem ser regis- trados e processados em lote em resposta a um comando de execução glo- bal explícito, um primeiro comando de obtenção, todo comando de obtenção, etc.

Estruturas Exemplificativas de Rastreamento

As Figuras 11A-D são diagramas de bloco que ilustram conteúdo exemplificativo das estruturas de dados da Figura 10 de acordo com uma modalidade da invenção. Embora as Figuras 11A-D ilustrem estas estruturas de dados como tabelas, deve-se entender que qualquer estrutura adequada de dados pode ser usada (por exemplo, um mapa hash, um conjunto, uma lista).

A Figura 11A é um diagrama de bloco de um exemplo da estru- tura de rastreamento de classe 1092 da Figura 10, de acordo com uma mo- dalidade da invenção. Na Figura 11 A, uma coluna de chave de classe 1110 e uma coluna de referência de classe 1115 são mostradas para armazenar, respectivamente, as chaves de classe e referências correspem quentes às classes carregadas.

A Figura 11B é um diagrama de bloco de um exemplo da estru- tura de rastreamento de instância 1065 da Figura 10, de acordo com uma modalidade da invenção. Na Figura 11B, uma coluna de chave de instância 1120 e uma coluna de referência de instância 1125 são mostradas para ar- mazenar, respectivamente, as chaves de instância e referências correspem quentes às instâncias. Em modalidades da invenção em que as chaves de instância não precisam ser únicas em todas as classes, a estrutura de ras- treamento de instância também inclui a chave de classe ou referência para a classe da instância.

A Figura 11C é um diagrama de bloco de um exemplo da estru- tura de gráfico produtor 1060 da Figura 10 de acordo com uma modalidade da invenção. Na Figura 11C, uma coluna de referência de classe 1135, uma coluna de referência de instância 1140 e uma coluna de referência de méto- do 1145 são mostradas armazenando, respectivamente, referências que 5 constituem os produtores atuais do gráfico produtor atual. Estas referências podem ter diversas formas. Por exemplo, essas colunas podem armazenar, respectivamente, referências nas classes 1054 (ou alternativamente, 1092), instâncias 1052 (ou alternativamente, 1065) e métodos 1056 (ou alternati- vamente, 1058). Embora em uma modalidade ad invenção essas colunas 10 armazenem referências, na modalidade alternativa da invenção, uma ou mais destas colunas armazenam chaves.

Em adição, a Figura 11C inclui uma coluna de ligação de produ- tor pai 1150 (incluindo, para cada ligação, uma referência a produtor pai e uma referência de produtor de determinação de dependência) e uma coluna 15 de ligação de produtor filho 1160 (incluindo, para cada ligação, referência(s) de produtor filho, uma referência de produtor de determinação de dependên- cia, um modo de ligação e um indicador de ligação adesiva). Cada produtor pode ter zero ou mais ligações de produtor filho na coluna 1160. Cada liga- ção de produtor filho na coluna 1160 inclui: 1) referência(s) de produtor filho

1 20 que são referências a outras fileiras da estrutura de gráfico produtor para representar uma dependência de produtor, de acordo com a declaração de dependência de produtor; 2) uma referência de produtor de determinação de dependência que é uma referência a uma outra fileira da estrutura de gráfico produtor e representa o produtor de determinação de dependência que criou 25 a ligação de filho; e 3) um modo de ligação com um tipo de dependência de produtor que identifica se a dependência de produtor é um resultado de um argumento, um campo ou uma dependência de sequenciamento (vide dis- cussão referente às Figuras 7a-F), e se um argumento, o ID de argumento da dependência de produtor; e 4) um indicador adesivo para indicar que o 30 modo de ligação é o resultado de uma dependência ascendentemente decla- rada (em modalidades da invenção que suportam dependências ascenden- temente declaradas) ou o resultado de uma subscrição adesiva (em modali- dades da invenção que suportam subscrições adesivas) e não devem ser modificadas através da declaração de dependência de argumento do produ- tor deste produtor (isto é, o produtor armazenado na fileira da coluna con- tendo o indicador adesivo). Cada produtor pode ter zero ou mais ligações de 5 produtor na coluna 1150. Cada ligação de produtor pai na coluna 1150 inclui:

1) uma referência de produtor pai que armazena uma referência de acordo com uma referência de produtor filho de um outro produtor (isto é, uma refe- rência a uma outra fileira da estrutura de gráfico produtor para representar um produtor pai dependente deste produtor); e 2) uma referência de produtor 10 de determinação de dependência que é uma referência a uma outra fileira da estrutura de gráfico produtor e representa o produtor de determinação de dependência que criou a ligação de pai. Assim, quando é criada uma liga- ção, a coluna de ligação de produtor pai da fileira de produtor filho e a coluna de ligação de produtor filho da fileira de produtor pai são modificadas para 15 representar a ligação (e a referência do produtor de determinação de depen- dência é igual em ambos). Em uma modalidade da invenção, como múltiplos caminhos em um gráfico produtor ou diferentes gráficos produtores podem incluir um dado produtor, pode haver múltiplas ligações de produtor pai para um dado produtor.

Adicionalmente, a Figura 11C inclui um cache de saída de pro-

dutor e coluna de modificação de saída de produtor 1170 para armazenar as saídas atuais de produtor, assim como uma indicação de se o produtor está sobregravado e o valor de saída de sobregravação. Além disso, a Figura 11C inclui uma coluna de marcação de execução incrementai 1180 para ar- 25 mazenar marcações de execução incrementais, conforme descrito anterior- mente.

A Figura 11D é um diagrama de bloco de um exemplo da estru- tura de rastreamento de método 1058 da Figura 10, de acordo com uma modalidade da invenção. Na Figura 11 D, uma coluna de chave de método 30 1190 e uma coluna de referência de método 1192 são mostradas para ar- mazenar, respectivamente, as chaves de método e referências correspem quentes aos métodos das classes carregadas. Além disso, a Figura 11D I 90

* também inclui uma coluna ArgumentDependencies 1194, uma coluna Field- Dependencies 1196, uma coluna SequencingDependencies 1195, uma colu- na UpwardDependencies 1193, uma coluna WeakIyConstrainedDependen- cies 119, uma coluna de classe de saída 1197, e uma coluna de anotações 5 adicionais opcional 1198. A coluna ArgumentDependencies 1194, a coluna SequencingDependencies 1195, a coluna UpwardDependencies 1193, a coluna WeaklyConstrainedDependencies 1199 e a coluna FieIdDependenci- es 1196 armazenam informações de dependência analisadas a partir da a- firmação de declaração de dependência de produtor do método (vide, por 10 exemplo, 705 da Figura 7A), enquanto a coluna de classe de saída 1197 armazena informações referentes à classe de saída do método (que pode ser determinada pela assinatura do método - por exemplo, vide 710 da Figu- ra 7A). Conteúdo exemplificativo da coluna ArgumentDependencies 1194, coluna FieIdDependencies 1196, coluna SequencingDependencies 1195, 15 coluna UpwardDependency 1193 e coluna WeaklyConstrainedDependencies 1199, usado em algumas modalidades da invenção, será fornecido posteri- ormente aqui.

Dependências de Produtor Dinâmicas

Conforme descrito anteriormente, uma modalidade da invenção >■ - 20 suporta dependências de produtor não-dinâmicas e dinâmicas. Embora dife- rentes modalidades possam suportar diferentes tipos de dependências de produtor dinâmicas, uma modalidade da invenção suporta contingente e ti- pos de subscrição de dependências de produtor dinâmicas. Assim, uma de- pendência não-contingente, de não-subscrição, é uma dependência não- 25 dinâmica (estática).

A Figura 12 é um diagrama de bloco que ilustra detalhes adicio- nais da Figura 10 para suportar dependências de produtor dinâmicas contin- gentes e do tipo subscrição, de acordo com uma modalidade da invenção. A Figura 12 inclui, da Figura 10, a linha de divisão tracejada 1000, as defini- 30 ções de classe que incluem lógica comercial 1010 (que incluem dados 1012, métodos 1014 e declarações de dependência de produtor 1016), o novo mó- dulo de classe 1095, as classes 1054 (incluindo métodos e declarações de dependência de produtor 1056), o novo módulo de instância 1098, as instân- cias 1052, a estrutura de rastreamento de instância 1065, o módulo de gera- ção de gráfico produtor automatizado 1040, a estrutura de gráfico produtor 1060 e o módulo de execução de gráfico produtor 1070 (incluindo o módulo 5 de dependência dinâmica 1075).

A Figura 12 mostra que as declarações de dependência de pro- dutor 1016 incluem, opcionalmente, dependências contingentes 1210, de- pendências de subscrição 1220, e múltiplos produtores 1215. Aqui, múltiplos produtores 1215 refere-se à capacidade de uma dependência de produtor 10 retornar uma coleção de produtores. Em adição, a Figura 12 inclui um módu- lo de subscrição 1240 e um módulo de contingência 1230 no módulo de ge- ração de gráfico produtor automatizado 1040 para processar as dependên- cias contingentes 1210 e dependências de subscrição 1220. A Figura 12 também mostra que o módulo de subscrição 1240 acessa um registro de 15 subscrição 1250. Adicionalmente, o módulo de dependência dinâmica 1075 inclui um módulo de contingência 1260 e um módulo de subscrição 1265 para processar as dependências contingentes 1210 e dependências de subscrição 1220. O módulo de subscrição 1265 acessa o registro de subs- crição 1250.

A descrição a seguir de dependências contingentes e de subs-

crição, é feita no contexto de uma modalidade da invenção que usa uma classe DEP (uma abreviação para dependência), a partir da qual uma ins- tância é retornada pelos produtores de determinação de dependência e é analisada pelo runtime com suporte de programação orientada por gráfico 25 produtor. A classe DEP inclui os seguintes campos: 1) ΤΥΡΟ, que pode ser definido para subscrição, não-subscrição descendentemente declarada (pro- dutores filhos que não são subscrições), ou não-subscrição ascendentemen- te declarada (produtores pais que não são subscrições); 2) PROD que é u- sado para dependências declaradas descendentemente de não-subscrição e 30 é uma coleção de produtores filhos (como tal, pode armazenar zero ou mais produtores); 3) SUB TYPE que é usado para dependências de subscrição e é definida para indicar o tipo de dependência de subscrição (usada em mo- * dalidades da invenção que suportam múltiplos tipos de subscrição; enquanto a modalidade da invenção descrita aqui suporta dois tipos - adesiva e ab- sorvente, modalidades alternativas podem suportar mais, menos e/ou dife- rentes tipos de subscrição; 4) SUB CRIT que é usado para dependências de subscrição e é definido para indicar os critérios de subscrição; 5) PAR LINK MODE que é usado para dependências de subscrição adesivas e depen- dências ascendentemente declarada de não-subscrição e é definido para indicar qual deve ser o modo de ligação do produtor pai; 6) PAR CLASS que é usado para dependências de subscrição adesiva e dependências ascen- dentemente declarada de não-subscrição e é definido para indicar qual deve ser a classe do produtor pai (por exemplo, a chave de classe); 7) PAR ME- THOD que é usado para dependências de subscrição adesiva e dependên- cias ascendentemente declarada de não-subscrição e é definido para indicar qual deve ser o método do produtor pai (por exemplo, a chave de método); e 8) PAR INSTANCE que é usado para dependências de subscrição adesiva e dependências ascendentemente declaradas de não-subscrição e é definido para indicar qual deve ser a instância do produtor pai (por exemplo, a chave de instância) (Se PAR INSTANCE for deixado em branco, a chave de ins- tância do produtor filho é usada então para o produtor pai). Uma modalidade ‘ 20 alternativa poderia usar uma coleção de produtores pais (cada item da cole- ção tendo um PAR_CLASS, PARJNSTANCE, PAR METHOD, PARJJNK MODE) no caso de dependências de subscrição adesiva e/ou dependências ascendentemente declaradas de não-subscrição. Obviamente, outras moda- lidades alternativas da invenção podem usar uma estrutura diferente para retornar dependências.

Dependências Contingentes

Em uma modalidade da invenção, são suportadas tanto depen- dências de produtor não-contingentes quanto contingentes. Uma dependên- cia de produtor não-contingente é uma que é independente da saída de ou- 30 tros produtores, enquanto uma dependência de produtor contingente é uma que é dependente da saída de outros produtores. Embora uma modalidade da invenção suporte ambas as dependências, não-contingente e contingen- te, modalidades alternativas suportam apenas não-contingente ou contingen- te (dependências de produtor contingentes estas que podem ser acionadas inicialmente por valores padrões).

Conforme foi discutido anteriormente, um produtor pode ser vi- 5 sualizado como um conjunto de múltiplos identificadores, um identificador para cada nível adicional de granularidade especificada. Em uma modalida- de da invenção, uma dependência de produtor contingente pode ser contin- gente no sentido de que qualquer identificador ou todos os elementos do conjunto de identificadores podem ser determinados condicionalmente com 10 base nos valores atuais de dados. Por exemplo, uma primeira dependência de produtor contingente pode ter apenas o identificador de instância sendo determinado condicionalmente (os identificadores de classe e método são fixados), enquanto uma segunda dependência de produtor contingente pode ter os identificadores de classe, instância e método determinados condicio- 15 nalmente. Embora em uma modalidade da invenção toda a pluralidade de identificadores de uma dependência de produtor contingente possa ser con- dicional, modalidades alternativas da invenção podem ser implementadas de maneira diferente (por exemplo, permitir que apenas um subconjunto da plu- ralidade de identificadores seja condicional).

As Figuras 13A-J são diagramas de bloco que ilustram pseudo-

código e produtores exemplificativos de acordo com uma modalidade da in- venção. Em adição, as modalidades mostradas na Figura 13A-J usam o mesmo mecanismo de determinação de dependência para ambas as de- pendências, contingente e não-contingente. Como tal, para fins de explica- 25 ção, alguns dos exemplos nas Figuras 13A-J são exemplos de dependên- cias de produtor não-contingentes, enquanto os outros são exemplos de de- pendências de produtor contingentes. Adicionalmente, uma dependência de produtor não-contingente é uma em que a dependência está para um produ- tor de determinação de dependência que é um produtor independente (por 30 exemplo, em uma modalidade da invenção, o tipo de dependência pode ser identificado porque sua declaração de dependência de produtor está vazia); enquanto uma dependência de produtor contingente é uma em que a de- * pendência está para um produtor de determinação de dependência, que é um produtor dependente (por exemplo, em uma modalidade da invenção, o tipo de dependência pode ser identificado porque sua declaração de depen- dência de produtor não está vazia).

Adicionalmente, números e letras circulados são usados nas Fi-

guras 13A-J para ilustrar a ordem em que as operações são realizadas de acordo com uma modalidade da invenção. Além disso, a notação X::Y::Z é usada nas Figuras 13A-J para representar uma chave de produtor constituí- da de uma chave de classe (X), de uma chave de instância (Y) e de uma 10 chave de método (Z). Círculos tracejados e linhas com seta adicionais repre- sentam operações que não são realizadas em algumas modalidades da in- venção. Em particular, quando a execução de um produtor de determinação de dependência independente para uma dada dependência sempre retornar a mesma dependência (por exemplo, um produtor de determinação de de- 15 pendência independente), tal produtor de determinação de dependência em algumas modalidades da invenção é executado, mas não instanciado e liga- do no gráfico produtor.

Produtores de Determinação de Dependência Explícitos A Figura 13A ilustra pseudo-código de declarações de depen-

* 20 dência de produtor para métodos que usam uma dependência (não- contingente, de não-subscrição) não-dinâmica, declarada sem atalho, de acordo com uma modalidade.da invenção; embora a Figura 13B seja um diagrama de bloco de produtores ilustrando uma dependência de produtor (não-contingente, de não-subscrição) não-dinâmica, declarada sem atalho, 25 de acordo com uma modalidade da invenção. A Figura 13A mostra: 1) uma afirmação de declaração de dependência de produtor 1300 para um método alfa 1305, em que a afirmação de declaração de dependência de produtor 1300 inclui uma dependência de produtor de um produtor CW::IY::BETA; e

2) uma afirmação de declaração de dependência de produtor 1310 para um 30 método beta 1315, em que a afirmação de declaração de dependência de produtor 1310 está vazia e em que o método beta 1315 retorna, como um argumento, uma instância da classe DEP. O método beta 1315 inclui o códi- go de declaração de dependência de produtor 1320, que define DEP.TYPE para dependência declarada descendentemente, de não-subscrição, define DEP.PROD para produtor 13 e retorna DEP.

Na Figura 13A, um 1 circulado indica que a declaração de de- 5 pendência de produtor 1300 é acessada (por exemplo, como resultado de designação de um produtor baseado no método alfa 1305 como um produtor de interesse, como resultado da descoberta automatizada de um produtor baseado no método alfa 1305, como uma progenia de um produtor de inte- resse, etc.) Um 2 circulado na Figura 13B mostra que um produtor C0::I0:: 10 ALPHA é instanciado com base no método alfa 1305. Um 3 circulado na Fi- gura 13A indica que a dependência de produtor com relação ao produtor CW::IY::BETA é processada para determinar a dependência de produtor e, como resultado, um 4 circulado indica que a declaração de dependência de produtor 1310 é acessada. Um 5 circulado tracejado na Figura 13B mostra 15 que um produtor CW::IY::BETA é instanciado como um produtor de determi- nação de dependência 1380. Um 6 circulado tracejado na Figura 13B indica que o produtor CO::IO::ALPHA está ligado no gráfico produtor para indicar que o produtor CW::IY::BETA é um produtor filho. Um 7 circulado na Figura 13B indica que o produtor CW::IY::BETA é executado e retorna DEP para 20 identificar produtor 13. Um 8 circulado indica que o produtor 13 é instancia- do, enquanto um 9 circulado indica o produtor 13 sendo ligado como um produtor filho no gráfico produtor ao produtor CO::IO::ALPHA. Na Figura 13B, o produtor CO::IO::ALPHA e o produtor 13 são produtores padrão 1385 (eles não são produtores de determinação de dependência).

A Figura 13C ilustra pseudo-código de declarações de depen-

dência de produtor para métodos que usam uma dependência de produtor de não-subscrição, contingente, declarada, sem atalho, de acordo com uma modalidade da invenção; enquanto a Figura 13D é um diagrama de bloco de produtores ilustrando uma dependência de produtor de não-subscrição, con- 30 tingente, declarada, sem atalho, de acordo com uma modalidade da inven- ção. Em adição, a Figura 13D refere-se aos produtores 5, 7A e 7B, da Figura 5A e a resolução da dependência dinâmica do produtor 5 com relação ao * produtor 7A.

A Figura 13C mostra: 1) uma afirmação de declaração de de- pendência de produtor 1300 para um método alfa 1305, em que a afirmação de declaração de dependência de produtor 1300 inclui uma dependência de 5 produtor com relação a um produtor CW::IY::BERA; 2) uma afirmação de declaração de dependência de produtor 1325 com relação a um método beta 1315, em que a afirmação de declaração de dependência de produtor 1325 inclui uma dependência de produtor com relação a um produtor CU::IV::DETAL e em que o método beta 1315 retorna, como um argumento, 10 uma instância da classe DEP; 3) uma afirmação de declaração de depen- dência de produtor 1332 para um método delta 1334, em que a afirmação de declaração de dependência de produtor 1332 está vazia e em que o método delta 1334 retorna, como argumento, uma instância da classe DEP; e 4) uma afirmação de declaração de dependência de produtor 1338 para um método 15 gama 1340, em que a Figura de declaração de dependência de produtor 1338 está vazia e em que o método gama 1340 retorna uma variável X (em que X é de uma fonte externa, um valor padrão (explícito ou constante na classe)). O método beta 1315 inclui código de declaração de dependência de produtor 1330 que define DEP.TYPE para não-subscrição declarada des- 20 cendentemente, define DEP.PROD para o produtor 7A ou 7B, dependendo da saída do produtor CX::IZ::GAMA e retorna DEP. O método delta 1332 inclui código de declaração de dependência de produtor 1336 que define DEP.TYPE para não-subscrição declarada descendentemente, define DEP.PROD para o produtor CX::IZ::GAMA e retorna DEP.PROD.

Na Figura 13C, um 1 circulado indica que a declaração de de-

pendência de produtor 1300 é acessada (por exemplo, como resultado da designação de um produtor baseado no método alfa 1305 como um produtor de interesse, como resultado da descoberta automatizada de um produtor com base no método alfa 1305 como uma progenia de um produtor de inte- 30 resse, etc). Um 2 circulado na Figura 13D mostra que o produtor 5 é instan- ciado com base no método alfa 1305. Um 3 circulado na Figura 13C indica que a dependência de produtor para o produtor CW::IY::BETA é processada para determinar a dependência de produtor e, como resultado, um 4 circula- do indica que a declaração de dependência de produtor 1325 é acessada. Um 5 circulado na Figura 13D mostra que um produtor CW::IY::BETA é ins- tanciado como um produtor de determinação de dependência 1380. Um 6 5 circulado na Figura 13D indica que o produtor 5 está ligado no gráfico produ- tor para indicar que o produtor CW::IY::BETA é um produtor filho.

Um 7 circulado na Figura 13C indica que a dependência de pro- dutor para o produtor CU::IV::DELTA é processada para determinar a de- pendência de produtor e, como resultado, um 8 circulado indica que a decla- 10 ração de dependência de produtor 1332 é acessada. Um 9 circulado traceja- do na Figura 13D mostra que um produtor CU::IV::DELTA é instanciado co- mo um produtor de determinação de dependência 1380. Um 10 circulado tracejado na Figura 13D indica que o produtor CW::IY::BETA é ligado no grá- fico produtor para indicar que o produtor CU::IV::DELTA é um produtor filho. 15 Um 11 circulado na Figura 13D indica que o produtor CU::IV::DELTA é exe- cutado e retorna DEP para identificar CX::IZ::GAMA. Um 12 circulado indica que o produtor CX::IZ::GAMA é instanciado, enquanto um 13 circulado indica que o produtor CX::IZ::GAMA está sendo ligado como um produtor filho no gráfico produtor ao produtor CW::Iy::BETA.

Na Figura 13D, um A circulado indica que o produtor

CX::IZ::GAMA é executado e retorna X para o produtor CW::IY::BETA, en- quanto um B circulado indica que o produtor CW::IY::BETA retorna DEP pa- ra identificar produtor 7A; um C circulado indica que o restante não solucio- nado (método beta) 1390 está solucionado agora e o produtor 7A é instanci- 25 ado, enquanto um D circulado indica a ligação do produtor 5 ao produtor 7A. Na Figura 13D, os produtores CX:.1Z::GAMA, 5 e 7A são produtores padrão 1385.

Produtores de Determinação de Dependência A Figura 13E ilustra pseudo-código de declarações de depen- dência de produtor para métodos usando tanto uma dependência de produ- tor de não-subscrição, contingente, declarada, sem atalho, quanto uma de- pendência de produtor de não-subscrição, contingente, declarada, com ata- * lho, de acordo com uma modalidade da invenção; enquanto a Figura 13F é um diagrama de bloco de produtores ilustrando uma dependência de produ- tor de não-subscrição, contingente, declarada, sem atalho e uma dependên- cia de produtor de não-subscrição, contingente, declarada, com atalho, de 5 acordo com uma modalidade da invenção. Similarmente às Figuras 13D, a Figura 13F refere-se aos produtores 5, 7 A e 7B da Figura 5A e a resolução da dependência dinâmica do produtor 5 com relação ao produtor 7A.

As Figuras 13E-F são iguais às Figuras 13C-D, com as exce- ções: 1) uma afirmação de declaração de dependência de produtor 1342 substitui a afirmação de declaração de dependência de produtor 1325; 2) um método 1344 substitui o método delta 1334; e 3) um produtor CW::IY::FLY substitui o produtor CU:IV:DELTA. A afirmação de declaração de dependên- cia de produtor 1342 inclui uma dependência de produtor declarada com ata- lho com relação a CX::IZ::GAMA. Assim, o 4 circulado na Figura 13E indica agora que a declaração de dependência de produtor 1342 é acessada. O 7 circulado na Figura 13E indica agora que a dependência de produtor decla- rada com atalho com relação ao produtor CX::IZ::GAMA é processada para determinar a dependência de produtor e, como resultado, o runtime invoca o produtor de determinação de dependência CW::!Y::FLY, com base no méto- do 1344. O 8 circulado indica agora que a declaração de dependência de produtor 1332 é acessada. O 9 circulado tracejado na Figura 13F mostra agora que o produtor CW::IY::FLY, é instanciado. O 10 circulado tracejado na Figura 13F indica que o produtor CW::IY::BETA está ligado no gráfico produtor para indicar que o produtor CW::IY::Fly é um produtor filho. O 11 circulado na Figura 13F indica que o produtor CW:.1Y::FLY é executado e retorna DEP para identificar CX::IZ::GAMA. O restante das Figuras 13E-F é igual às Figuras 13C-D.

A geração ainda em movimento pelo runtime do produtor de de- terminação de dependência CW::IY::FLY alivia o programador de aplicativo de ter que gravar código de declaração de dependência de produtor explícito e instanciar um produtor de determinação de dependência com base nele. Adicionalmente, permite que o programador de aplicativo especifique dire- tamente a dependência do produtor CX::IZ::GAMA na afirmação de declara- ção de dependência de produtor para método beta 1315, em oposição a es- pecificar o produtor de determinação de dependência CU::IV::DELTA.

A técnica de atalho pode ser usada em uma série de situações e pode ter, adicionalmente, uma série de formatos. Por exemplo, enquanto nas Figuras 13E-F a dependência declarada com atalho é para uma dependên- cia não-contingente (identifica diretamente o produtor filho) e está em uma afirmação de declaração de dependência de produtor para um método no qual um produtor de determinação de dependência está baseado, outras situações e formatos são mostrados conforme a seguir: 1) figuras 13G-H ilustram o uso de dois atalhos, em que um é contingente e é parte de uma afirmação de declaração de dependência de produtor para um método no qual um produtor padrão é baseado e o outro é não-contingente e é parte de uma afirmação de declaração de dependência de produtor para um método no qual um produtor de determinação de dependência é baseado; e 2) as Figuras I-J ilustram o uso de um atalho que é não-contingente e que está em uma afirmação de declaração de dependência de produtor para um método no qual é baseado um produtor padrão.

A Figura 13G ilustra pseudo-código de declarações de depen- dência de produtor para métodos usando uma dependência de produtor de não-subscrição, contingente, declarada, com atalho e uma dependência de produtor de não-subscrição, não-contingente, declarada, com atalho, de a- cordo com uma modalidade da invenção; enquanto a Figura 13H é um dia- grama de bloco de produtores ilustrando uma dependência de produtor de não-subscrição, contingente, declarada, com atalho e uma dependência de produtor de não-subscrição, não-contingente, declarada, com atalho, de a- cordo com uma modalidade da invenção. A Figura 13G mostra: 1) uma afir- mação de declaração de dependência de produtor 1345 para o método alfa 1305, em que a afirmação de declaração de dependência de produtor 1345 inclui uma dependência de produtor de não-subscrição, contingente, decla- rada, com atalho com relação a um produtor

GETC1::II::M1; 2) uma a- firmação de declaração de dependência de produtor 1350 para um método flyl 1355, em que a afirmação de declaração de dependência de produtor 1350 inclui uma dependência de produtor de não-subscrição, não- contingente, declarada, com atalho com relação a um produtor C0::I0::GETC1, e em que o método em andamentol 1355 retorna, como um 5 argumento, uma instância de DEP; 3) a afirmação de declaração de depen- dência de produtor 1332 para um método fly2 1362, em que o método fly2 1362 retorna, como um argumento, uma instância de DEP; e 4) a afirmação de declaração de dependência de produtor 1365 para um método getcl 1370, em que o método getcl 1370 retorna C1 com um valor de CXou CY. 10 O método FLY1 1355 e sua afirmação de declaração de depen-

dência de produtor 1350 são fornecidos pelo runtime em resposta à depen- dência declarada com atalho

GETC::I1::M1 (que indica que o atalho está sendo usado para a chave de classe). O método flyl 1355 inclui código de declaração de dependência de produtor 1360 que define DEP.TYPE para 15 não-subscrição descendentemente declarada, define DEP.PROD para o produtor CX::I1::M1 ou CY::I1::M1, dependendo do valor de C1 produzido pelo produtor C0::I0::GETC1 e retorna DEP. Embora no exemplo da Figura 13H seja usado um

para designar que é a chave de classe do produtor que é contingente, modalidades alternativas da invenção podem usar outras -20 sintaxes. Adicionalmente, enquanto no exemplo da Figura 13H usa-se

para designar que e chave de classe do produtor que é contingente, uma modalidade da invenção suporta ter mais identificadores e/ou identificadores diferentes que fazem com que a chave de produtor seja indicada como con- tingente desta maneira.

Na Figura 13G, um 1 circulado indica que a declaração de de-

pendência de produtor 1345 é acessada (por exemplo, como resultado da designação de um produtor baseado no método alfa 1305 como um produtor de interesse, como resultado da descoberta automatizada de um produtor com base no método alfa 1305 como uma progenia de um produtor de inte- 30 resse, etc.) Um 2 circulado na Figura 13H mostra que o produtor C0::I0::ALPHA é instanciado com base no método alfa 1305. Um 3 circulado na Figura 13G indica que a dependência de produtor declarada com atalho é processada para determinar a dependência de produtor e o runtime propor- ciona o método flyl 1355; e, como resultado, um 4 circulado indica que a declaração de dependência de produtor 1350 é acessada.

Um 5 circulado na Figura 13H mostra que um produtor C0::I0::FLY1 é instanciado como um produtor de determinação de depen- dência 1380. Um 6 circulado na Figura 13H indica que o produtor C0::I0::ALPHA está ligado, no gráfico produtor, para indicar que o produtor C0::I0::FLY1 é um produtor filho. Um 7 circulado na Figura 13G indica que a dependência de produtor declarada com atalho com relação ao produtor C0::I0::GETC1 é processada para determinar a dependência de produtor e o runtime proporciona o método fly2 1362 e, como resultado, um 8 circulado indica que a declaração de dependência de produtor 1332 é acessada. Um 9 circulado tracejado na Figura 13H mostra que um produtor C0::I0::FLY2 é instanciado. Um 10 circulado tracejado na Figura 13H indica que o produtor C0::I0::FLY1 é ligado no gráfico produtor para indicar que o produtor C0::I0::FLY2 é um produtor filho.

Um 11 circulado na Figura 13H indica que o produtor C0::I0::FLY2 é exeutado e retorna DEP para identificar o produtor C0::I0::GETC1. Um 12 circulado indica que o produtor C0::I0::GETC1 é ins- 20 tanciado, enquanto um 13 circulado indica que o produtor C0::I0::GETC1 está ligado no gráfico produtor ao produtor C0::I0::FLY1 como um produtor filho.

Na Figura 13H, um A circulado indica que o produtor C0::I0::GETC1 é executado e retorna CI=CX para o produtor C0::I0::FLY1, enquanto um B 25 circulado indica que o produtor C0::I0::FLY1 é executado e retorna DEP para identificar o produtor CX::11::M1; um C circulado indica que o restante não resolvido (método flyl) 1390 está resolvido agora e um D circulado indica a ligação do produtor C0::I0::ALPHA ao produtor CX::I1::M1. Na Figura 13H, os produtores C0::I0::GETC1, C0::I0::ALPHA, e CX::I1::M1 são produtores 30 padrão 1385.

A geração "durante o andamento" pelo runtime do produtor de deter- minação de dependência CO::IO::FLY1 e C0::I0::FLY2 tira a carga do pro- gramador do aplicativo de ter que gravar código de declaração de depen- dência de produtor explícito e instanciar os produtores de determinação de dependência com base nele. Adicionalmente, ela permite que o programador do aplicativo especifique diretamente a dependência contingente com rela- 5 ção a um produtor **::I1::M1 através do método getC1 na afirmação de de- claração de dependência de produtor para o método alfa 1305, em oposição a especificar o produtor de determinação de dependência CW::IY::BETA.

A Figura 131 ilustra pseudo-código de declarações de dependên- cia de produtor para métodos que usam uma dependência de produtor (não- contingente, não-subscrição) não-dinâmica, declarada, com atalho de acordo com uma modalidade da invenção; enquanto a Figura 13J é um diagrama de bloco de produtores ilustrando uma dependência de produtor não-dinâmica, com atalho, declarada, exemplificativa, de acordo com uma modalidade da invenção. A Figura 131 mostra: 1) uma afirmação de declaração de depen- dência de produtor 1372 para um método alfa 1305, em que a afirmação de declaração de dependência de produtor 1372 inclui uma dependência de produtor declarada com atalho com relação a um produtor 10; e 2) uma afir- mação de declaração de dependência de produtor 1374 para um método fly 1376, em que a afirmação de declaração de dependência de produtor 1374 está vazia e em que o método fly 1376 retorna, como um argumento, uma instância de DEP. O método fly 1776 e sua afirmação de declaração de de- pendência de produtor 1374 são fornecidos pelo runtime em resposta à de- pendência declarada com atalho. O método fly 1376 inclui código de decla- ração de dependência de produtor 1378 que define DEP.TYPE para não- subscrição descendentemente declarada, define DEP.PROD para o produtor e retorna DEP.

Na Figura 131, um 1 circulado indica que a declaração de de- pendência de produtor 1372 é acessada (por exemplo, como resultado da designação de um produtor com base no método alfa 1305 como um produ- 30 tor de interesse, como resultado de descoberta automatizada de um produtor com base no método alfa 1305 como uma progenia de um produtor de inte- resse, etc.). Um 2 circulado na Figura 13J mostra que um produtor CO::IO::ALPHA é instanciado com base no método alfa 1305. Um 3 circulado na Figura 131 indica que a dependência de produtor declarada com atalho é processada para determinar a dependência de produtor e o runtime propor- ciona o método fly 1376; e como resultado, um 4 circulado indica que a de- 5 claração de dependência de produtor 1374 é acessada. Um 5 circulado tra- cejado na Figura 13J mostra que um produtor C0::I0::FLY é instanciado co- mo um produtor de determinação de dependência 1380. Um 6 circulado tra- cejado na Figura 13J indica que o produtor C0::I0::ALPHA é ligado no gráfico produtor para indicar que o produtor C0::I0::FLY é um produtor filho.

Um 7 circulado na Figura 13J indica que o produtor C0::I0::FLY é

executado e retorna DEP para identificar o produtor 10. Um 8 circulado indi- ca que o produtor 10 é instanciado, enquanto um 9 circulado indica que o produtor C0::I0::ALPHA é ligado no gráfico produtor para indicar que o pro- dutor 10 é um produtor filho. Na Figura 13J, o produtor C0::I0::ALPHA e o produtor 10 são produtores padrão 1385.

Deve-se entender que o programador de runtime, em uma mo- dalidade da invenção, grava um único método fly para interpretar todas as sintaxes e combinações suportadas (por exemplo, o método fly 1334, o mé- todo flyl 1355, o método fly2 1362, o método fly 1376) e o inclui no runtime. 20 Isso não só permite que os programadores de aplicativo evitem gravar códi- go para produtores de determinação de dependência, em que um método fly pode ser usado o programador de runtime só precisa gravar o método fly genérico (o fly simples para todas as situações suportadas) uma vez. Adicio- nalmente, deve-se entender que as dependências declaradas com atalho 25 permitem um runtime que usa produtores de determinação de dependência, enquanto, ao mesmo tempo, permite que um programador de aplicativo indi- que produtores padrão nas declarações de dependência de produtor (por exemplo, Figuras 13G-J).

Estrutura de Rastreamento de Método Com referência à estrutura de rastreamento de método da Figu-

ra 11 D, conteúdo exemplificativo da coluna ArgumentDependencies 1194, coluna FieIdDependencies 1196, coluna SequencingDependencies 1195, * coluna UpwardDependencies 1193 e coluna WeakIyConstrainedDependen- cies 1199, usadas em algumas modalidades da invenção, será descrito ago- ra. Especificamente,a coluna ArgumentDependencies 1194 armazena uma coleção de itens, um para cada ArgumentDependency. Em uma modalidade 5 da invenção, cada item inclui o seguinte: 1) o ID de argumento; 2) um identi- ficador de natureza de chave de classe, sendo um de classe explícita, classe igual e classe contingente; 3) um identificador de chave de classe explícita preenchido quando o identificador da natureza de chave de classe indica classe explícita; 4) identificador de chave de método de determinação de 10 classe contingente preenchido quando o identificador de natureza de chave de classe indica classe contingente; 5) um identificador de natureza de cha- ve de instância, sendo um de instância explícita, mesma instância e instân- cia contingente; 6) um identificador de chave de instância explícita preenchi- do quando o identificador de natureza de chave de instância indica uma ins- 15 tância explícita; 7) identificador de chave de método de determinação de ins- tância contingente preenchido quando o identificador de natureza de chave de instância indica instância contingente; 8) identificador de natureza de chave de método, sendo um de método explícito, mesmo método e método contingente; 9) um identificador de chave de método explícito preenchido

1 20 quando o identificador de natureza de chave de método indica método explí- cito; 10) identificador de chave de método de determinação de método con- tingente, preenchido quando o identificador de natureza de chave de método indica método contingente; e 11) um identificador de atalho que indica se a declaração de dependência de produtor para o argumento na afirmação de 25 declaração de dependência de produtor continha uma indicação de atalho (isto é, a afirmação de declaração de dependência de produtor identifica di- retamente um produtor filho padrão ao invés de um produtor de determina- ção de dependência). A indicação "..explícita" dos diversos identificado- res de natureza de chave, é usada quando a chave explícita é fornecida para 30 dependência de produtor na afirmação de declaração de dependência de produtor. Á guisa de exemplo, a dependência de produtor "CW::IY::BETA" da afirmação de declaração de dependência de produtor 1300 da Figura 13A proporciona uma chave explicita de classe, instância e método.

Em algumas modalidades da invenção, é suportada uma técnica de estenografia para as afirmações de declaração de dependência de produ- tor tal que: 1) se uma classe não for proporcionada para uma dada depen- 5 dência de produtor, então a mesma classe do produtor pai é usada; e 2) se não forem proporcionadas uma classe e instância para uma dada depen- dência de produtor, então a mesma classe e instância do produtor pai são usadas. Em outras modalidade da invenção, é usada uma sintaxe para per- mitir que qualquer combinação de classe, instância e método seja igual ao 10 pai (com a exceção de todos serem iguais) (por exemplo, é usado um sepa- rador para designar cada um de classe, instância e método e uma ausência de tal separador indica igual ao pai - à guisa de exemplo específico, a sinta- xe pode ser "#C:", "#l:" e tal que uma dependência de produtor em uma afirmação de declaração de dependência de produtor pode ser 15 #C:"chave de classe"::#l:"chave de instância"::#M:"chave de método".) (em que as aspas indicam um marcador para um valor ou variável) A indicação "..igual" dos diversos identificadores de natureza de chave, é usada quando esta técnica de estenografia é usada na afirmação de declaração de depen- dência de produtor.

Conforme indicado anteriormente, em algumas modalidades da

invenção, uma indicação de uma dependência de produtor contingente é suportada através de uma sintaxe (por exemplo,

) usada na própria afir- mação de declaração de dependência de produtor (vide 1345 da Figura 13G) e tal sintaxe pode ser usada em um ou mais de classe, instância e mé- 25 todo de uma dependência de produtor. A indicação "..contingente" dos diver- sos identificadores de natureza de chave é usada para identificar quando ocorre tal dependência de produtor contingente, enquanto "identificador de chave de método de determinação .. contingente" indica a chave de método do produtor filho (a classe e a instância são iguais aos do produtor pai). À 30 guisa de exemplo, a dependência de produtor "

GETC1::I1::M1" para a declaração de dependência de produtor 1345 da Figura 13G, proporciona uma classe contingente (em que a chave de método de determinação de I 106

i classe contingente é GETC1), uma chave de instância explícita e uma chave de método explícita.

A coluna SequencingDependencies 1195, a coluna UpwardDe- pendencies 1193 e a coluna WeaklyConstrainedDependencies 1195 arma- 5 zenam, cada uma, uma coleção de itens, um para cada SequencingDepen- dency, UpwardDependency e WeakIyConstrainedDependency. Em uma mo- dalidade da invenção, cada item tem a mesma estrutura de um item da cole- ção para ArgumentDependencies1 exceto pelo fato de que ele não inclui o ID do argumento. Adicionalmente, embora as Figuras 13A-J ilustrem depen- 10 dências descendentemente declaradas de não-subscrição com origem nos produtores de determinação de dependência, deve-se entender que, no caso de uma dependência ascendentemente declarada ou dependência fraca- mente restrita, o produtor de determinação de dependência pode retornar as outras dependências discutidas com referência à Figura 7F-G.

15 A coluna FieIdDependencies 1196 armazena uma coleção de

itens, um para cada FieIdDependency. Embora em uma modalidade da in- venção cada item inclua a chave de método de produtor, em modalidades alternativas da invenção podem ter a mesma estrutura que um item da cole- ção de SequencingDependencies.

1 20 Dependências de Subscrição

Em uma modalidade da invenção, tanto dependência de produ- tor sem subscrição quanto com subscrição são suportadas. Quando uma dependência de produtor com subscrição é declarada para um dado método e um dado produtor é instanciado a partir daquele dado método, o runtime 25 pode resolver durante o runtime (com base na existência de outros produto- res) o conjunto de zero ou mais produtores que atendem aos critérios da subscrição. Embora uma modalidade da invenção suporte ambas as depen- dências de produtor, sem subscrição e com subscrição, modalidades alter- nativas suportam apenas não-subscrição. Em adição, embora em uma mo- 30 dalidade da invenção sejam suportados dois tipos de dependências com subscrição (absorvente e adesiva), modalidades alternativas da invenção suportam mais, menos e/ou diferentes tipos de dependências de produtor com subscrição.

As Figuras 14A-C são diagramas de bloco que ilustram subscri- ções absorvente e adesiva, de acordo com uma modalidade da invenção a Figura 14A é um diagrama de bloco de um exemplo do registro de subscri- 5 ção 1250 da Figura 12, de acordo com uma modalidade da invenção. Embo- ra a Figura 14A ilustra esta estrutura de registro como uma tabela, deve-se entender que qualquer estrutura de dados adequada pode ser usada (por exemplo, um mapa hash). A Figura 14B é um diagrama de bloco de produto- res exemplificativos ilustrando uma dependência de produtor com subscrição 10 absorvente, não-contingente, de acordo com uma modalidade da invenção. A Figura 14C é um diagrama de bloco de produtores exemplificativos ilus- trando uma dependência de produtor com subscrição adesiva, não- contingente, de acordo com uma modalidade da invenção. São mostradas duas fileiras na tabela da Figura 14A preenchidas com conteúdo usado nos 15 exemplos das Figuras 14B-C. Números circulados são usados nas Figuras 14B-C para ilustrar a ordem na qual as operações são realizadas de acordo com uma modalidade da invenção.

Na Figura 14A, mostra-se uma coluna de chave de produtor do subscritor 1400, uma coluna do tipo de subscrição 1405 e uma coluna de 20 critérios de subscrição para ativar produtores 1410, que armazenam, respec- tivamente, o conteúdo correspem quente ao nome da coluna. Em adição, a Figura 14A mostra uma coluna de modo de ligação de pai 1425 para arma- zenar o modo de ligação para o produtor pai da dependência com subscri- ção; esta informação será descrita com mais detalhes no que diz respeito à 25 Figura 14B-C.

A Figura 14A também mostra uma coluna de correspondência de produtores 1415 e uma coluna completada 1420 usada para subscrições absorventes. A coluna de correspondência de produtores 1415 é usada para armazenar as chaves de produtor dos produtores de ativação que atendem 30 aos critérios de subscrição da subscrição absorvente, enquanto a coluna completada 1420 é usada para rastrear se a subscrição absorvente foi com- pletada durante uma dada execução da definição atual de gráficos produto- * res. A coluna de correspondência de produtores 1415 e a coluna completada

1420 proporcionam uma otimização opcional adicional que permite que o trabalho de examinar os produtores instanciados seja dividido entre a gera- ção de gráfico produtor automatizado e a execução de gráfico produtor, con- 5 forme será descrito posteriormente.

A Figura 14A também mostra uma coluna de classe paterna 1430, uma coluna de método paterno 1435 e uma coluna de instância pater- na 1437 usadas para subscrições adesivas. A coluna de classe paterna 1430, a coluna de método paterno 1435 e a coluna de instância paterna 10 1437 armazenam, respectivamente, a chave de classe, a chave de método e a chave de instância do produtor paterno a ser criado para a subscrição a- desiva. Além disso, a Figura 14A mostra uma coluna de referência de produ- tor de determinação de dependência 1421 para armazenar uma referência ao produtor de determinação de dependência que cria a subscrição.

Subscrição Absorvente

Em uma dependência de produtor com subscrição absorvente, a dependência é com relação à coleção de todos os produtores da estrutura de gráfico produtor atual atendendo aos critérios de subscrição absorvente. Com referência à Figura 14B, um 1 circulado indica que um produtor 1450 é 20 instanciado (por exemplo, como resultado da designação do produtor 1450 como um produtor de interesse, como resultado da descoberta automatizada do produtor 1450 como uma progenia de um produtor de interesse, etc.) O produtor 1450 é baseado em um método para o qual a declaração de de- pendência de produtor inclui uma dependência de produtor (por exemplo, 25 com ID de argumento X). Um 2 circulado indica que a dependência de pro- dutor do produtor 1450 é processada para identificar u produtor 1455.

Um 3 circulado indica que o produtor 1450 é ligado (no exemplo acima, através de ID de argumento X) no gráfico produtor ao produtor 1455 como um produtor filho. Um 4 circulado indica a execução do produtor 1455. 30 O produtor 1455 é um produtor de determinação de dependência que inclui código de declaração de dependência de produtor indicando uma depen- dência de produtor com subscrição absorvente e indicando os critérios de subscrição absorvente. Como tal, a execução do produtor 1455 resulta no preenchimento do registro de subscrição. No que diz respeito ao exemplo na primeira fileira da Figura 14A, a coluna da chave de produtor do subscritor 1400, a coluna de tipo de subscrição 1405, a coluna de critérios de subscri- 5 ção para ativar produtores 1410, a coluna de modo de ligação paterna 1425 e a coluna de referência de produtor de determinação de dependência 1421 são preenchidas, respectivamente, com a chave de produtor do produtor 1450, uma indicação de que a subscrição é do tipo absorvente, os critérios de subscrição absorvente contidos no produtor 1455, o modo de ligação do 10 produtor 1450 ligado ao produtor 1455 (que, no caso de uma subscrição ab- sorvente, será uma dependência de argumento e inclui um ID de argumento, mas cujo indicador adesivo indicará não-adesivo - no exemplo acima, ID de argumento X) e uma referência ao produtor 1455 (o produtor de determina- ção de dependência que cria a subscrição).

5A-N circulado indica a instanciação de produtores 1460A-N.

Neste exemplo, os produtores 1460A-N atendem aos critérios de subscrição absorvente e, assim, são produtores de ativação. Como tal, 6A-N circulado indica a ligação do produtor 1450 aos produtores 1460A-N (no exemplo aci- ma, através de ID de argumento X). Um 7 circulado indica que a dependên- 20 cia de subscrição absorvente é completada para a execução atual do gráfico produtor e então, o produtor 1450 é executado.

Em uma modalidade da invenção, os critérios de subscrição ab- sorvente podem ser uma ou mais de qualquer chave que constitui uma cha- ve de produtor. Assim, nas modalidades da invenção em que uma chave de 25 produtor compreende uma chave de classe, chave de instância e uma chave de método, os critérios de subscrição podem ser uma ou mais chaves. À guisa de exemplo com referência à Figura 11C, um exame através dos pro- dutores instanciados para aqueles que atendem aos critérios de subscrição é um exame através de uma ou mais das primeiras três colunas da estrutura 30 de gráfico produtor para determinar se as chaves dos produtores instancia- dos correspem quem às chaves dos critérios de subscrição absorvente. Em- bora em uma modalidade da invenção os critérios de subscrição absorvente * possam ser um ou mais de qualquer das chaves que constituem uma chave de produtor, em modalidades alternativas da invenção os critérios de subs- crição absorvente estão limitados a um subconjunto das chaves que consti- tuem uma chave de produtor.

5 Subscrição Adesiva

Em uma dependência de produtor de subscrição adesiva, a de- pendência faz com que um produtor paterno seja instanciado para cada pro- dutor que atenda aos critérios de subscrição adesiva. Com referência à Figu- ra 14C, um 1 circulado indica que um produtor 1470 é instanciado (por e- 10 xemplo, como resultado da designação do produtor 1470) como um produtor de interesse, como resultado de descoberta automatizada do produtor 1470 como uma progenia de um produtor de interesse através de uma dependên- cia de sequenciamento (por exemplo, como resultado de SequencingDepen- dency ou WeaklyConstrainedDependency, etc). O produtor 1470 é um pro- 15 dutor de determinação de dependência que inclui código de declaração de dependência de produtor indicando uma subscrição adesiva, os critérios pa- ra a subscrição adesiva para produtores de ativação e características de subscrição adesiva para o produtor paterno a ser criado.

A execução do produtor 1470 resulta no preenchimento do regis-

* 20 tro de subscrição. No que diz respeito ao exemplo na segunda fileira da Fi- gura 14A, a coluna da chave de produtor do subscritor 1400, a coluna do tipo de subscrição 1405 e os critérios de subscrição para a coluna de produtores de ativação 1410 são respectivamente preenchidas com a chave de produtor do produtor 1470, uma indicação de que a subscrição é do tipo adesiva e os 25 critérios de subscrição adesiva para os produtores de ativação contidos no produtor 1470. Em adição, a coluna de classe paterna 1430, a coluna de método paterno 1435, a coluna de instância paterna 1437 e a coluna de mo- do de ligação 1425 do produtor paterno a serem ligadas ao produtor de ati- vação, são preenchidas com as características de subscrição adesiva para o 30 produtor paterno ser criado - nesta modalidade da invenção, respectivamen- te a classe do produtor paterno a ser instanciado, o método do produtor pa- terno a ser instanciado, a instância do produtor paterno a ser instanciado (se for deixado em branco, seria igual à chave de instância do produtor de ativa- ção), o modo de ligação (que, no caso de subscrição adesiva pode ser: 1- dependência de argumento, campo ou sequenciamento; 2- ID de argumento se uma dependência de argumento - o ID de argumento do produtor paterno 5 a ser ligado ao produtor de ativação (por exemplo,ID de argumento Y). Em adição, a coluna de referência do produtor de determinação de dependência

1421 é preenchida com uma referência ao produtor de determinação de de- pendência que criou a subscrição na Figura 14C, o produtor 1470).

Com referência à Figura 14C, um 2 circulado indica que um pro- dutor 1475 é instanciado (por exemplo, como resultado da designação do produtor 1475 como um produtor de interesse, como resultado de descober- ta automatizada do produtor 1475 como uma progenia de um produtor de interesse, etc.) Em adição, determina-se se o produtor 1475 atende aos cri- térios de subscrição adesiva para um produtor de ativação. Um 3 circulado indica que, em resposta ao produtor de ativação 1475, um produtor 1480 é instanciado com base nas características de subscrição adesiva para o pro- dutor paterno ser criado. Com referência à segunda fileira exemplificativa da Figura 14C, a chave de ciasse, a chave de método, a chave de instância e o modo de ligação são acessados a partir da coluna de classe paterna 1430, coluna de método paterno 1435, coluna de instância 1437 e coluna de modo de ligação paterna 1425, respectivamente. O produtor paterno tem uma cha- ve de produtor que compreende a chave de classe acessada, a chave de instância acessada (se deixada em branco, a chave de instância do produtor de ativação (na Figura 14C, o produtor 1475)), e a chave do método acessa- do - no exemplo da Figura 14C, este é o produtor 1480. Um 4 circulado indi- ca que o produtor paterno instanciado 1480 é ligado no gráfico produtor ao produtor de ativação filial 1475 através do modo de ligação acessado (no exemplo acima, tipo de modo de ligação = dependência de argumento; ID de argumento de modo de ligação = Y). Também no 4 circulado, no caso de uma dependência de argumento, o indicador adesivo é definido para indicar adesivo - que a dependência de produtor naquela posição da afirmação de declaração de dependência de produtor para o método no qual o produtor * paterno instanciado 1480 é baseado, deve ser ignorado para o produtor 1480 - isso impede que a ligação criada pela dependência de produtor de subscrição adesiva seja sobregravada pelas operações de geração de gráfi- co produtor automatizadas mais recentes.

Em uma modalidade da invenção, os critérios de subscrição a-

desiva para produtores de ativação podem ser um ou mais das chaves que constituem uma chave de produtor. Assim, nas modalidades em que uma chave de produtor compreende uma chave de classe, uma chave de instân- cia e uma chave de método, os critérios de subscrição adesiva para a ativa- 10 ção podem ser um ou mais das chaves de classe, instância e método. À gui- sa de exemplo com referência à Figura 11C, um exame através dos produto- res instanciados para aqueles que atendem aos critérios de subscrição ade- siva para produtores de ativação é um exame através de uma ou mais das prímeira-terceira colunas da estrutura de gráfico(s) produtor(es) para deter- 15 minar se as chaves dos produtores instanciados correspem quem às chaves dos critérios de subscrição adesiva para produtores de ativacao. Embora em uma modalidade da invenção os critérios de subscrição adesiva para produ- tores de ativação possam ser uma ou mais das chaves que constituem uma chave de produtor, em modalidades alternativas da invenção os critérios de - 20 subscrição adesiva podem ser um número mais limitado das chaves que constituem uma chave de produtor.

As Figuras 14D-E ilustram a escolha de um produtor paterno com base em um produtor de determinação de dependência paterno de a- cordo com uma modalidade da invenção. Embora as Figuras 14D-E sejam 25 descritas com referência às dependências de argumento, modalidades da invenção podem suportar o uso de dependências de sequenciamento e de campo.

A Figura 14D ilustra a escolha de um produtor paterno com base em um produtor de determinação de dependência paterno criado por uma 30 subscrição adesiva, de acordo com uma modalidade da invenção. Como a Figura 14C, a Figura 14D mostra o produtor de subscrição adesiva 1470 e o produtor de ativação 1475; no entanto, ao invés do produtor 1480, a Figura 14D mostra um produtor de determinação de dependência 1480 criado atra- vés da subscrição adesiva de produtor de subscrição adesiva 1470. Adicio- nalmente, a Figura 14D mostra que o modo de ligação de subscrição adesi- va é dependência de argumento, ID de argumento=X e indicador adesivo = 5 adesivo. Conforme está ilustrado pela linha curva tracejada a partir do produ- tor 1475 até o produtor de determinação de dependência 1480, DEP retor- nado pelo produtor de determinação de dependência pode ser baseado na saída do próprio produtor 1475 (o argumento de ID de argumento=X). Na Figura 14D, o produtor de determinação de dependência 1480 retorna uma 10 dependência de produtor ascendentemente declarada de não-subscrição com relação a um produtor 1482, com o modo de ligação indicando depen- dência de argumento e ID de argumento=Y. Embora os IDs de argumento de XeY sejam usados na Figura 14D para mostrar que eles podem diferir, de- ve-se entender que eles podem ser iguais.

A Figura 14E ilustra a escolha de um produtor paterno com base

em um produtor de determinação de dependência paterno criado por um produtor de determinação de dependência filial, produtor de determinação de dependência filial este que é ligado por uma dependência de sequenciamen- to, de acordo com uma modalidade da invenção. A Figura 14E é similar, em 20 estrutura, à Figura 14D; especificamente, o produtor 1475, 1480 e 1482 são substituídos por produtores 1486, 1496 e 1498. No entanto, ao invés do pro- dutor de subscrição adesiva 1470 criar a ligação entre os produtores 1480 e 1475, o produtor 1486 tem uma dependência de sequenciamento com rela- ção a um produtor de determinação de dependência 1494 (por exemplo, cri- 25 ado através de uma UpwardDependency ou uma WeakIyConstrainedDepen- dency), que cria o produtor de determinação de dependência 1496 através de uma dependência ascendentemente declarada de não-subscrição.

Vale a pena notar que as subscrições adesivas e as dependên- cias ascendentemente declaradas de não-subscrição (por exemplo, criadas através de UpwardDependencies e/ou WeaklyConstrainedDependencies) causam a formação de um gráfico produtor com a parte inferior voltada para cima (em oposição à construção de topo virado para baixo, descrita anteri- * ormente). Adicionalmente, esta construção abaulada para cima não está li- mitada à construção de um único nível, mas podem ser múltiplos níveis (por exemplo, se devido a uma dependência ascendentemente declarada de subscrição adesiva ou de não-subscrição, um produtor paterno é instancia- 5 do, aquele mesmo produtor paterno também pode ser um produtor de ativa- ção para uma subscrição adesiva ou pode incluir uma dependência ascen- dentemente declarada de não-subscrição e causar a instanciação de um outro produtor paterno, e assim por diante). Neste sentido, as subscrições adesivas, assim como as dependências ascendentemente declaradas de 10 não-subscrição, revertem a construção de gráfico produtor.

Embora em algumas modalidades da invenção os produtores paternos identificados pelas características de subscrição adesiva sejam produtores padrão (vide a Figura 14C), podem ser implementadas modalida- des alternativas que suportem a identificação de outros tipos de produtores. 15 Por exemplo, nas modalidades da invenção que permitem que as caracterís- ticas de subscrição adesiva identifiquem um produtor de determinação de dependência (vide a Figura 14D), tal produtor de determinação de depen- dência pode acessar a saída do produtor de ativação e pode, com base na- quela saída, ativar a criação de um produtor particular como um produtor 20 paterno que precise aderir ao filho (este produtor paterno pode já existir ou não; se ele já existir, ele é simplesmente ligado e o produtor filho é adiciona- do ao seu argumento; se ele não existir ainda, ele será criado). O caso em que o produtor de determinação de dependência retorna um produtor cons- tante, imita uma subscrição adesiva. O caso em que o produtor de determi- 25 nação de dependência retorna um produtor cuja chave de instância é única por produtor de ativação (por exemplo, retorna um produtor cuja chave de instância é a chave de produtor do produtor de ativação) resulta em um pro- dutor paterno separado por produtor filho e é referida como uma subscrição adesiva pura. O caso em que o produtor de determinação de dependência 30 retorna uma chave de instância que nem é constante nem única por produtor de ativação, pode misturar os comportamentos de subscrições adesivas pu- ras e subscrições absorventes e é referida como uma subscrição adesiva não pura.

Vantagens Exemplificativas

Conforme descrito anteriormente, em uma modalidade da inven- ção, as dependências de produtor são declaradas para métodos como uma maneira de especificar sequenciamento de invocação de método usando as instâncias adequadas (em que as instâncias adequadas incluem as instân- cias a serem usadas como argumentos, as instâncias a serem usadas pelos métodos de instância e as instâncias de meta classe usadas por métodos de classe) sem usar código de sequenciamento de invocação manual; efetiva- mente, o trabalho de gerar uma parte ou todo o código de sequenciamento de invocação manual é substituído por: 1) trabalho feito pelo programador de aplicativo para gravar as declarações de dependência do produtor; e 2) tra- balho feito pelo runtime para descobrir e construir o(s) gráfico(s) produtor(es) e executar os produtores daqueles gráficos produtores. Embora o esforço de gravar o runtime seja relativamente grande, ele só precisa ser gravado uma vez em que ele possa ser usado para executar qualquer aplicativo orientado por objeto gravado para o runtime; por outro lado, para um aplicativo típico, o esforço para gravar as declarações de dependência de produtor é relativa- mente baixo em comparação com a gravação do código de sequenciamento de invocação manual.

As dependências de produtor não-dinâmicas proporcionam uma maneira de especificar código de sequenciamento de invocação de método não-condicional e, assim, evitar a necessidade de gravar código de sequen- ciamento de invocação manual. As dependências de produtor contingentes 25 proporcionam uma maneira de especificar processamento condicional e, as- sim, substituir a necessidade de gravar código de sequenciamento de invo- cação manual condicional. Suportar dependências de produtor que permitam que uma coleção de produtores seja retornada, proporciona uma maneira de especificar o preenchimento de uma coleção antes de ela ser passada como 30 parâmetro e, assim, evitar a necessidade de gravar múltiplas células no có- digo de sequenciamento de invocação manual para preencher uma coleção antes de ela ser passada como parâmetro. Suportar subscrições proporciona * um ambiente em que um programador não precisa gravar código de escuta específico para cada tipo de objeto a ser ouvido (por exemplo, em uma plani- lha de programação orientada por gráfico produtor, pode ser usada uma subscrição absorvente para computar uma média de um intervalo de células 5 (cada célula sendo um produtor) ao ter os critérios de subscrição absorvente identificando células dentro do intervalo e computando novamente a média toda vez que um novo produtor for adicionado à subscrição absorvente; em uma planilha de programação orientada por gráfico produtor, pode ser usada uma subscrição adesiva como um conversor de moeda ao se ter critérios de 10 subscrição adesiva identificando células que contêm conteúdo monetário e características de subscrição adesiva de produtor(es) adesivo(s) a serem instanciados que realizam conversão de moeda (os produtor(es) (que con- têm as quantias convertidas) criados pelas subscrições adesivas estariam então disponíveis para exibição em outras células).

Operação

Novos Comandos de Instância

A Figura 15 é um fluxograma para instanciar novas instâncias, de acordo com uma modalidade da invenção. Conforme descrito anterior- mente com referência à Figura 10, o novo módulo de classe 1095 da Figura 20 10 pode ser implementado como parte do novo módulo de instância 1098. O fluxograma da Figura 15 assume tal modalidade e é executado pelo novo módulo de instância 1098; a parte do fluxograma da Figura 15 que represen- ta o novo módulo de classe 1095 é mostrada como o bloco tracejado 1580, que inclui os blocos 1540 e 1550.

Em resposta a um novo comando de instância (bloco 1510), o

controle passa para o bloco 1520. No bloco 1520, determina-se se a instân- cia já existe. Se não, o controle passa para o bloco 1530, caso contrário, a instância não precisa ser instanciada e o controle passa para o bloco 1570, em que o fluxograma termina. Em uma modalidade que suporta chaves de 30 instância, o bloco 1520 é executado acessando-se a estrutura de rastrea- mento de instância 1065 da Figura 10 para a chave de instância (e chave de classe se as chaves de instância não tiverem que ser únicas através das classes) fornecida como parte do novo comando de instância.

No bloco 1530, determina-se se a definição de classe da instân- cia já está carregada. Se não, o controle passa para o bloco 1540; caso con- trário, o controle passa para o bloco 1560. Em uma modalidade que suporta 5 chaves de ciasse, o bloco 1540 é executado acessando-se a estrutura de rastreamento de classe 1092 da Figura 10 para a chave de classe fornecida como parte do novo comando de instância.

No bloco 1540, a classe é carregada e o controle passa para o bloco 1550. No bloco 1550, a definição de classe é armazenada de acordo 10 com a chave de classe e sofre introspecção, incluindo qualquer afirmação de declaração de dependência de produtor (armazenada pela chave de método dentro da classe - vide a Figura 11 D). A partir do bloco 1550, o controle passa para o bloco 1560. Com referência à Figura 10, o seguinte é executa- do nos blocos 1540 e 1550: 1) a classe é carregada a partir das definições 15 de classe que incluem lógica comercial 1010 nas classes 1054 (este carre- gamento resulta nos métodos e declarações de DEP de produtor da classe armazenada nas declarações de dependência de método e produtor 1056);

2) a classe é adicionada à estrutura de rastreamento de classe 1092; e 3) os métodos são adicionados à estrutura de rastreamento de método 1058. Adi- cionalmente, as classes de saída dos métodos são carregadas.

No bloco 1560, uma instância da classe é instanciada e armaze- nada, de acordo com a chave de instância. Com referência à Figura 10, a instância é instanciada nas instâncias 1053; e a instância é adicionada à es- trutura de rastreamento de instância 1065. A partir do bloco 1550, o controle 25 passa para o bloco 1570, em que o fluxograma termina. Em algumas moda- lidades da invenção em que é usada uma técnica de mapeamento objeto- relacional, os dados podem ser carregados a partir de uma fonte externa de dados para preencher o campo da instância como parte do bloco 1560.

Em algumas modalidades da invenção, classes e instâncias po- dem ser carregadas/instanciadas de uma maneira em que o runtime com suporte de programação orientada por gráfico produtor não está ciente (por exemplo, na Figura 9A, se o runtime 915 carregar/instanciar sem runtime * 910 estar ciente). Em tais casos, modalidades da invenção que também su- portam a chave de instância sendo uma instância de Chave de instância de classe (que retém dois elementos: uma natureza de chave de instância indi- cando se o identificador de chave é uma referência à instância ou outro obje- 5 to (como uma cadeia), e um identificador de chave que pode ser uma refe- rência à instância ou um outro objeto (como uma cadeia)), os blocos 1520 e 1530 inquirem se a instância e a classe foram instanciadas/carregadas de uma maneira em que o runtime com suporte de programação orientada por gráfico produtor está ciente. Em casos em que o runtime com suporte de 10 programação orientada por gráfico produtor não está ciente de uma classe já carregada, a classe não é carregada, mas a classe é adicionada à estrutura de rastreamento de classe 1092 e os métodos são adicionados à estrutura de rastreamento de método 1058. Nos casos em que o runtime com suporte de programação orientada por gráfico produtor não está ciente de uma ins- 15 tância já instanciada, a instância não é instanciada, mas a instância é adi- cionada à estrutura de rastreamento de instância 1065.

Novos Comandos de Produtor e de Cancelamento de Sobregravação

A Figura 16 é um fluxograma para instanciar novos produtores e produtor es de cancelamento de sobregravação, de acordo com uma moda- >-20 Iidade da invenção. Com referência à Figura 10, os fluxos da Figura 15 são realizados pelo módulo de geração de gráfico produtor automatizado 1040 e o módulo de produtor de sobregravação 1045 (ou, conforme descrito com referência a modalidades alternativas referentes à Figura 10, o módulo que lida com sobregravações e cancelamentos de sobregravações).

25 Em resposta a um novo comando produtor (bloco 1600), o con-

trole passa para o bloco 1605. Em uma modalidade da invenção, um novo comando produtor pode ser executado em resposta a uma série de situa- ções. A Tabela 2 abaixo identifica as diversas situações e parâmetros pas- sados de acordo com uma modalidade da invenção. TABELA 2

Situações Produtor Produtor Tipo de Modo de Referência Realiza¬ Chamado Chamada Ligação de produtor dor de (a ser cri¬ de determi¬ Chamada ado se já nação de não existir) dependên¬ cia. Produtor de N/A Produtor De inte¬ N/A N/A Interesse de interes¬ resse se a ser criado Não- Pai Filho Não- Modo de Produtor de subscrição subscri- ligação de determina¬ descenden¬ ção des¬ produtor ção de de¬ temente cenden¬ paterno pendência declarada temente realizador proporcio¬ declarada de cha¬ nando a de¬ mada pendência. Subscrição Filho Pai (chave Adesiva Modo de Produtor de adesiva de classe, ligação de determina¬ método e produtor ção de de¬ instância paterno pendência de pai a chamado proporciona partir de a partir de a dependên¬ caracterís¬ caracte¬ cia ticas de rísticas de subscrição subscri¬ adesiva ção ade¬ para pro¬ siva para dutor pa¬ produtor terno a ser paterno a criado; se ser criado chave de instância estiver em Dranco, chave de instância de produ¬ tor filho chamador existente Sobregra¬ N/A Produtor a Sobregra- N/A N/A vação ser sobre- vada gravado I

Não- Filho Pai Não- Modo de Produtor de subscrição subscri- ligação de determina¬ ascenden¬ ção as¬ produtor ção de de¬ temente cenden¬ paterno pendência declarada temente chamado proporcio¬ declarada nando a de¬ pendência No bloco 1605, determina-se se o produtor já existe. Se não, o controle passa para o bloco 1610; caso contrário, o controle passa para o bloco 1670. O bloco 1605 é executado acessando-se uma classe, uma ins- 5 tância e um método identificados (por exemplo, por chave e/ou referência) como parte do novo comando de produtor. Em uma modalidade que suporta chaves de produtor, o bloco 1605 é executado acessando-se a estrutura do gráfico produtor 1060 da Figura 10 para a chave de produtor proporcionada como parte do novo comando de produtor (a chave de produtor na coluna de 10 produtor chamado da Tabela 2).

No bloco 1610, o novo módulo de instância é chamado com um novo comando de instância e o controle passa para o bloco 1615. Em uma modalidade da invenção, o bloco 1610 é executado chamando-se o fluxo- grama da Figura 15 que usa a chave de instância da chave de produtor na ' 15 coluna de produtor chamado da Tabela 2.

No bloco 1615, a definição de classe da instância do produtor é acessada e o controle passa para o bloco 1620. Com referência à Figura 10, o bloco 1615 é executado usando-se a chave de classe da chave de produ- tor na coluna de produtor chamado da Tabela 2 para acessar a classe apro- 20 priada dentre as classes 1054, de acordo com a estrutura de rastreamento de classe 1092.

No bloco 1620, a afirmação de declaração de dependência de produtor e método é acessada e o controle passa para o bloco 1625. Com referência à Figura 10, o bloco 1620 é executado usando-se a chave de mé- 25 todo da chave de produtor na coluna de produtor chamado da Tabela 2 para acessar o método apropriado dentre os métodos e declarações de depen- dência de produtor 1056 da classe localizada no bloco 1615. No bloco 1625, o produtor é adicionado ao gráfico produtor e o controle passa para o bloco 1630. Com referência à modalidade da invenção na Figura 11C, as primeiras três colunas são preenchidas.

No bloco 1630, para cada subscrição registrada, o critério de 5 filtragem de subscrição é processado para determinar se o produtor corres- pem que. Com referência à modalidade da invenção na Figura 14A, uma subscrição é considerada registrada quando ela é adicionada ao registro de subscrição. Operações exemplificativas para registrar subscrição serão des- critas posteriormente. O bloco 1630 é uma otimização opcional que permite 10 que o trabalho de varredura dos produtores instanciados seja dividido entre a geração de gráfico produtor automatizado e execução de gráfico produtor. Como tal, uma modalidade alternativa da invenção pode não executar o blo- co 1630.

No bloco 1635, o produtor é ligado ao gráfico produtor, se cha- mado devido a uma dependência. A partir do bloco 1635, o controle passa para o bloco 1640. A maneira de executar o bloco 1635 depende da situação que resultou em o novo comando de produtor ser executado (vide a Figura 20). Por exemplo, se a situação for aquela em que este é um produtor de interesse ou um produtor sendo sobregravado, então ele não foi chamado devido a uma dependência e nada é feito. Por outro lado, se a situação for não-subscrição descendentemente declarada, então ele foi chamado devido a uma dependência descendentemente declarada de não-subscrição; e com referência à modalidade da invenção na Figura 11C, o seguinte é realizado: 1) a ligação de produtor paterno na coluna 1150 do produtor filho chamado (coluna de produtor chamado da Tabela 2) é modificada com uma referência de produtor paterno à fileira do produtor paterno que realiza a chamada (a coluna de produtor chamador da tabela 2) e a referência de produtor de de- terminação de dependência (a coluna de referência de produtor de determi- nação de dependência da tabela 2); e 2) a coluna de ligação de produtor filho 1160 da fileira do produtor paterno chamador (coluna de produtor cha- mador da tabela 2) é modificada com uma referência de produtor filho à filei- ra do produtor filho chamado (coluna de produtor chamado da Tabela 2), uma referência de produtor de determinação de dependência (a coiuna de referência de produtor de determinação de dependência da Tabela 2) e um modo de ligação (definido de acordo com a coluna de modo de ligação da Tabela 2).

Por outro lado, se a situação for uma subscrição adesiva, então ele foi chamado devido a um produtor de ativação sendo identificado; e com referência à modalidade da invenção na Figura 11C, o seguinte é realizado: 1) a coluna de ligação de produtor paterno 1150 do produtor filho que realiza a chamada (coluna de produtor chamador da Tabela 2) é modificada com uma referência de produtor paterno à fileira do produtor paterno chamado (a coluna de produtor chamado da Tabela 2) e a referência de produtor de de- terminação de dependência (a coluna de referência de produtor de determi- nação de dependência da Tabela 2); e 2) a ligação de produtor filho 1160 da fileira do produtor paterno chamado (a coluna de produtor chamado da Ta- bela 2) é modificada com uma referência de produtor filho à fileira do produ- tor filho que realiza a chamada (coluna de produtor chamador da Tabela 2), uma referência de produtor de determinação de dependência (a coluna de referência de produtor de determinação de dependência da Tabela 2), um modo de ligação (definido de acordo com a coluna de modo de ligação da Tabela 2) e um indicador adesivo definido para indicar adesão. Neste aspec- to, lida-se com a situação de uma não-subscrição ascendentemente decla- rada de uma maneira similar à subscrição adesiva.

No bloco 1640, o produtor é marcado como não executado e o controle passa para o bloco 1645. Com referência à modalidade da invenção na Figura 11C, a coluna de marcação de execução incrementai 1180 da filei- ra adequada é preenchida com uma indicação de não execução.

No bloco 1645, determina-se se o produtor tem qualquer depen- dência e não está sobregravado. Se assim for, o controle passa para o bloco 1650; caso contrário, o controle passa para o bloco 1665. O bloco 1645 é executado verificando-se a declaração de dependência de produtor acessa- da no bloco 1620 e a coluna de tipo de chamada da Tabela 2.

No bloco 1650, para cada dependência na declaração de de- pendência de produtor que deve ser solucionada agora, o número de produ- tores é determinado e um novo comando de produtor é invocado para cada. Do bloco 1650, o controle passa para o bloco 1655. Diferentes modalidades da invenção determinam diferentes tipos de dependência em diferentes mo- mentos; a maneira de executar o bloco 1650 em uma modalidade exemplifi- cativa da invenção, será descrita posteriormente.

No bloco 1655, o produtor é adicionado ao registro de início de execução se todos os seus produtores dependentes existirem e tiverem sido executados. Do bloco 1655, o controle passa para o bloco 1660. Quando, para um dado produtor instanciado como parte da iteração atual deste fluxo, o bloco 1655 é executado, então a invocação de uma outra iteração deste fluxo para um produtor, depende do retorno do estado de execução daquele produtor (vide o bloco 1660) (por exemplo, no que diz respeito à modalidade da invenção da Figura 11C, o estado da coluna de marcação de execução incrementai 1180 da fileira apropriada). Se todos os produtores dependentes existirem e o estado de execução de todos os produtores dependentes for executado, então o produtor da iteração atual é adicionado ao registro inicial de execução.

No bloco 1660, o estado de execução do produtor é retornado como um parâmetro.

No bloco 1670, similar ao bloco 1635, o produtor é ligado no grá- fico produtor se chamado devido a uma dependência. Do bloco 1670, o con- trole passa para o bloco 1675. O bloco 1670 pode ser atingido por uma série de razoes. Por exemplo, o bloco 1670 pode ser atingido porque o produtor foi anteriormente instanciado em resposta a um comando de sobregravação de produtor, mas não ligado no gráfico produtor. Como outro exemplo, o blo- co 1670 pode ser alcançado porque o produtor já é parte de um gráfico pro- dutor e está adicionado a um outro (por exemplo, anteriormente instanciado em resposta a ser um produtor de interesse, uma progenia de um produtor de interesse, etc.

No bloco 1675, determina-se se o novo fluxo de produtor é cha- mado devido a uma sobregravação, a uma dependência de subscrição ade- siva ou a uma dependência ascendentemente declarada sem subscrição. Se assim for, o controle passa para o bloco 1680; caso contrário, o controle passa para o bloco 1660. O bloco 1675 é executado verificando-se a coluna de tipo de chamada da Tabela 2 para ver se esta é uma chamada para um produtor sobregravado, uma dependência de subscrição adesiva, ou uma dependência ascendentemente declarada sem subscrição.

No bloco 1680, similar ao bloco 1640, o produtor é marcado co- mo não executado e o controle passa para o bloco 1665. O bloco 1680 pode ser alcançado por uma série de razoes.

No bloco 1665, o produtor é adicionado ao registro de início de execução, se já não estiver presente, e o controle passa para o bloco 1660.

Em resposta a um comando de sobregravação de produtor (blo- co 1690), o controle passa para o bloco 1695. No bloco 1695, o produtor é marcado como não sobregravado e o controle passa para o bloco 1640. Com referência à modalidade da invenção da Figura 11C1 o cache de saída do produtor e a coluna de indicações de saída de produtor sobregravado 1170 da fileira do produtor, são acessados e alterados para indicar que o produtor não está mais sobregravado. Continuando este fluxo, o bloco 1640 leva ao bloco 1645 e se o produtor tiver qualquer dependência, até o bloco 1650, o que faria com que o gráfico produtor sob o produtor fosse descober- to e construído, se já não estivesse. Se o gráfico produtor sob o produtor já estiver descoberto e construído, então a invocação do novo comando de produtor resultará em fluxos indo de 1600 para 1605, para 1670 e assim por diante; adicionalmente, o retorno do estado de execução dos produtores do gráfico sob o produtor no bloco 1660, determina se o produtor será adiciona- do ao registro de início de execução no bloco 1655. No entanto, se o gráfico produtor sob o produtor não estiver descoberto e construído, então a invoca- ção do novo comando de produtor resultará em ele ser descoberto e cons- truído com fluxos indo de 1600 para 1605, para 1610 e assim por diante.

A Figura 17 é um fluxograma para o bloco 1650 da Figura 16, de acordo com uma modalidade da invenção. Assim, o controle flui do bloco 1645 para o bloco 1700 no bloco 1650. No bloco 1700, para cada depen- dência na declaração de dependência de produtor do produtor (uma para cada ArgumentDependency, FieIdDependency, SequencingDependency, UpwardDependency e WeakIyConstrainedDependency), os seguintes blocos 1705-1745 são executados. Com referência às Figuras 10 e 11 D, a estrutura 5 de rastreamento de método é acessada para determinar informações refe- rentes à dependência de produtor. Deve-se entender também que os blocos 1715, 1725, 1730, 1740, 1745 e 1750 são uma otimização quando executa- dos antes da execução do gráfico produtor.

No bloco 1705, determina-se se a dependência é uma depen- 10 dência de argumento já ligada devido a uma dependência adesiva. Se assim for, o controle passa para o bloco 1710, em que o fluxo é completo para esta dependência; caso contrário, o controle passa para o bloco 1715. No que diz respeito à modalidade da invenção mostrada na Figura 11C, o indicador a- desivo é verificado para determinar se o ID de argumento desta dependência 15 está sujeito a uma dependência de argumento de subscrição adesiva ou uma dependência de argumento ascendentemente declarada.

No bloco 1715, determina-se se a dependência é uma depen- dência contingente. Se assim for, o controle passa para o bloco 1720; caso contrário, o controle passa para o bloco 1725. O bloco 1715 é executado verificando-se a declaração de dependência de produtor do produtor filho identificado pela dependência para determinar se ele está vazio (o produtor filho é um produtor independente). Com relação às Figuras 13A-J, isso seria verdadeiro para produtores com números circulados com tracejado (por e- xemplo, na Figura 13D, o produtor CU::IV::DELTA), mas não verdadeiro para os outros produtores (por exemplo, na Figura 13D, o produtor CW::IY::BETA), Assim, com referência à Figura 13D, o bloco 1715 é repre- sentado pelo circulo 1,4 e 8. O bloco 1715 e o fluxo a partir dele através dos blocos 1725-1750 é uma otimização que evita adicionar/ligar os produtores com números circulados com tracejado ao gráfico produtor, bem como dividir o trabalho de executar os produtores entre a geração de gráfico produtor automatizado e execução de gráfico produtor.

No bloco 1720, um novo comando de produtor para o produtor * de determinação de dependência é invocado e o fluxo termina, Por exemplo, com referência à Figura 13D, o bloco 1720 causa o que é representado por 5, 6 e 7 circulados.

No bloco 1725, o produtor de determinação de dependência é executado e o controle passa para o bloco 1730. Por exemplo, com referên- cia à Figura 13D, o bloco 1725 é representado pelo 11 circulado (assim, o fluxo da Figura 17 ilustrou a modalidade descrita anteriormente em que 9 e circulados da Figura 13D não são executados).

No bloco 1730, determina-se se a dependência é uma depen- 10 dência de não-subscrição. Se assim for, o controle passa para o bloco 1750; caso contrário, o controle passa para o bloco 1740. Em outras palavras, no bloco 1725, o código de determinação de dependência de produtor no méto- do do produtor de determinação de dependência, que é parte da declaração de dependência de produtor do produtor paterno, é executado. Tendo execu- 15 tado este código de declaração de dependência de produtor, código este que identifica se esta dependência é uma dependência de subscrição, o tipo de dependência de produtor do produtor paterno é determinado. Com rela- ção ao exemplo na Figura 13D, o 11 circulado resulta em o fluxo da Figura 17 passar do bloco 1730 para o bloco 1750.

No bloco 1750, o número de produtores retornados pela execu-

ção do produtor de determinação de dependência no bloco 1725 é determi- nado e um novo comando de produtor é invocado para cada, usando os ar- gumentos descritos na Tabela 2, incluindo a referência de produtor de de- terminação de dependência executada em 1725. Por exemplo, com referên- cia à Figura 13D, o bloco 1750 causa 12 e 13 circulados e C e D circulados.

Com referência ao exemplo de subscrição absorvente das Figu- ras 14B, o bloco 1725 representa 4 circulado; o que faz com que o fluxo passe através do bloco 1730 até o bloco 1740.

No bloco 1740, a subscrição é adicionada ao registro de subscri- ção e se a subscrição for absorvente, ela é marcada como incompleta. Do bloco 1740, o controle passa para o bloco 1745. Com referência à modalida- de da invenção mostrada na Figura 14A, o registro de subscrição é preen- chido com a subscrição, conforme descrito anteriormente.

No bloco 1745, todos os produtores instanciados são examina- dos para ser se eles correspem quem aos critérios da subscrição (e, assim, são um produtor de ativação) e qualquer correspondência é processada.

5 A Figura 18 é um fluxograma para o bloco 1745 da Figura 17 de

acordo com uma modalidade da invenção. Assim, o controle flui do bloco 1740 para o bloco 1800 no bloco 1745. No bloco 1800, para cada produtor instanciado, os seguintes blocos 1810-1830 são executados.

No bloco 1810, determina-se se o produtor atende aos critérios 10 da subscrição. Se assim for, o controle passa para o bloco 1815; caso con- trário, o controle passa para o bloco 1830, em que o fluxo termina para o produtor que está sendo processado no momento. Com referência às moda- lidades da invenção mostradas na Figura 11C e 14A, o gráfico produtor é acessado para determinar se ele inclui produtores que atendam aos critérios 15 da subscrição.

A maneira de processar um produtor de correspondência de- pende do tipo de subscrição que está sendo processada. Com referência ao bloco 1815, se a subscrição for do tipo absorvente, o controle passa para o bloco 1825; caso contrário, o controle passa para o bloco 1820. O bloco 20 1815 é executado em resposta ao tipo de subscrição adicionada no bloco 1740 ou 2235.

No bloco 1825, o produtor de correspondência é adicionado ao registro de subscrição e o produtor com a subscrição absorvente é ligado ao produtor de correspondência. A partir do bloco 1825, o controle passa para o 25 bloco 1830. Com referência às modalidades da invenção mostradas nas Fi- guras 11C e 14A-B, o seguinte é realizado: 1) os critérios de subscrição ori- undos dos critérios de subscrição para a coluna de produtores de ativação 1410 foi usado no bloco 1810 e um produtor de correspondência foi localiza- do (por exemplo, um do produtor 1460A-N); 2) o produtor de correspondên- 30 cia é adicionado à coluna do produtor de correspondência 1415 na fileira da subscrição; e 3) o produtor com a subscrição absorvente (por exemplo, pro- dutor 1450) é ligado ao produtor de correspondência (por exemplo, um dos <' produtores 1460A-N) na estrutura de gráfico produtor da Figura 11C (usando a referência de produtor de determinação de dependência extraída da colu- na de referência de produtor de determinação de dependência 1421 do re- gistro de subscrição 14A para a dada subscrição absorvente).

5 No bloco 1820, um novo comando de produtor é invocado para o

produtor paterno ser criado. A partir do bloco 1820, o controle passa para o bloco 1830 em que o fluxograma termina para o produtor atual selecionado no bloco 1800. Com referência às modalidades da invenção mostradas nas Figuras 14A e 14C, o seguinte é realizado: 1) os critérios de subscrição ori- 10 undos dos critérios de subscrição para a coluna de produtores de ativação 1410 foi usado no bloco 1810 e foi localizado um produtor de correspondên- cia (por exemplo, produtor 1475); e 2) um novo comando de produtor é invo- cado com os parâmetros da Tabela 2 definidos a seguir: a) tipo de chamada é subscrição adesiva; b) produtor que realiza a chamada é a chave de pro- 15 dutor do produtor filho que realiza a chamada (por exemplo, produtor 1475); c) o produtor chamado é a chave de produtor do produtor paterno chamado a ser criado (por exemplo, produtor 1480), aquela chave de produtor sendo formada usando a chave de classe, instância e método paterna das caracte- rísticas de subscrição adesiva para o produtor paterno ser criado (Figura 20 14A, colunas 1430, 1435 e 1437); d) o modo de ligação para o produtor pa- terno chamado (Figura 14A, coluna de modo de ligação 1425); e e) a refe- rência de produtor de determinação de dependência extraída da referência de produtor de determinação de dependência 1421 do registro de subscrição 14A para a dada subscrição adesiva.

A Figura 19 é um fluxograma para o bloco 1630 da Figura 16, de

acordo com uma modalidade da invenção. Assim, o controle flui do bloco 1625 para o bloco 1900 no bloco 1630. A Figura 19 é muito similar à Figura

18. Especificamente, os blocos 1910, 1915, 1920 e 1930 da Figura 19 são idênticos aos blocos 1810, 1815, 1820 e 1830; enquanto os blocos 1900 e 1925 diferem dos blocos 1800 e 1825. como tal, apenas a diferença será descrita aqui.

O bloco 1900 indica o fluxo que é realizado para cada subscri- ção registrada, enquanto o bloco 1800 indica o fluxo que é executado para cada produtor instanciado. Assim, quando o fluxo da Figura 18 estiver cen- tralizado em uma única subscrição e varrendo todos os produtores, o fluxo da Figura 19 é centralizado em um único produtor e varre todas as subscri- 5 ções.

O bloco 1925 é igual ao bloco 1825, com a exceção que a subs- crição absorvente é marcada como incompleta. Com referência à modalida- de da invenção mostrada na Figura 14A, a coluna completada 1420 na fileira apropriada é atualizada para indicar incompleta.

A Figura 20 é um fluxograma para os blocos 1635 e 1670 da Fi-

gura 16, de acordo com uma modalidade da invenção. Assim, o controle flui do bloco 1605 e bloco 1630 para o bloco 2005 nos blocos 1635 e 1670. No bloco 2005, determina-se se esta iteração do fluxograma da Figura 16 foi invocada devido a uma dependência (por exemplo, do bloco 1630 (bloco 15 1920) ou 1650 (blocos 1720, 1750 ou 1745/1820) de uma iteração anterior). Se não, o controle passa para o bloco 1640 ou 1675, dependendo de em que o fluxo entrou (do bloco 1630 ou 1605).

No bloco 2010, determina-se se o fluxo foi chamado devido a uma situação de subscrição adesiva ou não-subscrição ascendentemente 20 declarada. Se não, o controle passa para o bloco 2015; caso contrário, o controle passa para o bloco 2020. o bloco 2010 é executado verificando-se o parâmetro do tipo de chamada a partir da Tabela 2 (isto é, se o tipo de cha- mada é subscrição adesiva ou não-subscrição ascendentemente declarada ou não). Com referência às modalidades da invenção mostradas na Figura 25 18 e 19, se o novo comando de produtor foi invocado dos blocos 1820 ou 1920.

No bloco 2020, o produtor paterno atual é ligado ao produtor fi- lho que realiza a chamada. Com referência às modalidades da invenção mostradas nas Figuras 11C e 14C, o produtor paterno chamado (por exem- 30 pio, produtor 1480) identificado pelo parâmetro da coluna de produtor cha- mado da tabela 2, é ligado na estrutura de gráfico produtor da Figura 11C ao produtor filho que realiza a chamada (por exemplo, produtor 1475) identifica- i do pelo parâmetro da coluna de produtor que realiza a chamada da Tabela 2, usando o modo de ligação e a referência de produtor de determinação de dependência identificados pelas colunas do parâmetro do modo de ligação e referência de produtor de determinação de dependência da Tabela 2. Se o 5 pai existia anteriormente, o comportamento do bloco 2020 imita o compor- tamento de uma dependência com subscrição absorvente no sentido em que um único argumento pode ser mapeado para zero ou mais produtores filhos.

No bloco 2015, o produtor paterno que realiza a chamada é liga- do ao produtor filho chamado atual. Com referência à moda invenção mos- 10 trada na Figura 11C, o produtor paterno que realiza a chamada identificado pelo parâmetro da coluna do produtor que realiza a chamada da Tabela 2 é ligado na estrutura de gráfico produtor da Figura 11C ao produtor filho cha- mado identificado pelo parâmetro da coluna de produtor chamado da Tabela

2, usando a referência de produtor de determinação de dependência identifi- cada pela coluna de referência de produtor de determinação de dependência da Tabela 2. Dos blocos 2015 e 2020, o controle passa para o bloco 1640 ou 1675, dependendo de em que o fluxo entrou (do bloco 1605 ou 1630).

A Figura 21 é um fluxograma para sobregravar produtores de acordo com uma modalidade da invenção. Com referência à Figura 10, o 20 fluxo da Figura 21 é executado pelo módulo produtor sobregravado 1045 (ou, conforme descrito com referência a modalidades alternativas referentes à Figura 10, o módulo que lida com sobregravação e cancelamento de so- bregravação).

Em resposta a um comando de produtor de sobregravação (blo- 25 co 2110), o controle passa para o bloco 2120. No bloco 2120, um novo co- mando de produtor é invocado para o produtor identificado pelo comando de produtor de sobregravação e o controle passa para o bloco 2130. O bloco 2120 é executado em uma modalidade da invenção no caso de o produtor a ser sobregravado ainda não tiver sido instanciado, assim como para marcar 30 o produtor como não executado (bloco 1640 ou 1680) e registrá-lo no regis- tro inicial de execução (bloco 1665). Uma modalidade alternativa da inven- ção que não permite a sobregravação de um produtor que ainda não está instanciado, executaria uma verificação adicionai entre os blocos 1605 e 1610 para determinar se este novo comando de produtor foi chamado em resposta a um comando de produtor de sobregravação e para indicar um erro se este novo comando de produtor foi chamado em resposta a um co- 5 mando de produtor de sobregravação.

No bloco 2130, a saída no cache de saída do produtor (e na ins- tância, se for um campo) é definida e o produtor é marcado como sobregra- vado.

Comandos de Execução Globais A Figura 22A é uma parte de um fluxograma para execução do

gráfico produtor atual, de acordo com uma modalidade da invenção; enquan- to a Figura 22b é uma outra parte de um fluxograma para execução do gráfi- co produtor atual, de acordo com uma modalidade da invenção. Com refe- rência à Figura 10, o fluxo da Figura 22 é executado pelo módulo de execu- ção de gráfico produtor 1070.

Em resposta a um comando de execução global, o bloco 2220 mostra que um conjunto de produtores candidatos é selecionado para ser executado com base nos produtores no registro inicial de execução e o con- trole passa para o bloco 2205. Em uma modalidade da invenção, os produto- 20 res sobregravados são marcados como não executados e sua execução re- torna seu resultado sobregravado (em oposição a fazer com que seu método seja executado), o conjunto atual de produtores candidatos é de produtores no registro inicial de execução. Embora uma modalidade da invenção seja descrita acima em que produtores sobregravados são marcados como não 25 executados e sua execução retorna seu resultado sobregravado (em oposi- ção a fazer com que seu método seja executado), modalidades alternativas podem operar de modo diferente (por exemplo, marcar produtores sobregra- vados como executados e, ao selecionar o conjunto atual de produtores candidatos, os produtores independentes do registro inicial de execução e os 30 pais de produtores sobregravados no registro inicial de execução, são sele- cionados).

No bloco 2205, um subconjunto de produtores prontos para exe- * cução é selecionado a partir do conjunto de produtores candidatos e o con- trole passa para o bloco 2210. Uma maneira exemplificativa de executar o bloco 2205 será descrita posteriormente.

No bloco 2210, os produtores do conjunto atual de produtores 5 prontos são classificados por tipo - produtores padrão vão para o bloco 2215 e produtores de determinação de dependência vão para o bloco 2225. Em uma modalidade da invenção, o bloco 2210 é executado verificando-se a classe de retorno do produtor. Com referência às Figuras 10 e 11 D, a estru- tura de rastreamento de método é acessada para determinar se a classe de 10 saída do produtor é DEP e, assim, este produtor e um produtor de determi- nação de dependência.

No bloco 2215, qualquer produtor padrão no conjunto atual de produtores prontos é executado e o controle passa para o bloco 2220. Em uma moda da invenção, o bloco 2215 é executado chamando-se o método 15 com qualquer parâmetro de entrada mapeado das saídas de qualquer produ- tor filho resultante de dependências de argumento (para argumentos, o ID do argumento do modo de ligação é usado para mapear a saída do produtor filho adequado para o argumento de entrada adequado do método que está sendo executado). Em algumas modalidades da invenção, tal execução po- >20 de resultar na execução de código no método de um produtor filho que grava uma saída para um dado mecanismo (como definir uma variável global, defi- nir um campo em uma instância que não é a saída do produtor, causa im- pacto sobre uma fonte de dados externa, etc.) ou código no método do pro- dutor paterno que leucócito aquela saída do dado mecanismo). No bloco 25 2220, para aqueles pais, se houver, que têm uma subscrição absorvente em qualquer destes produtores padrão executados, a subscrição é marcada como incompleta. Do bloco 2220, o controle passa para o bloco 2245. Com referência à Figura 14A, a fileira apropriada da coluna completada 1420 é definida para indicar incompleta.

30 No bloco 2225, qualquer produtor de determinação de depen-

dência no conjunto atual de produtores prontos é preparado para execução e o controle passa para o bloco 2230. Uma maneira exemplificativa de execu- tar o bloco 2225 será descrita posteriormente. No bloco 2230, qualquer produtor de determinação de depen- dência no conjunto atual de produtores prontos é executado e o controle passa para o bloco 2235. Em uma modalidade da invenção, o bloco 2230 é executado de maneira similar ao bloco 2215.

No bloco 2235, um novo comando de produtor é executado para qualquer produtor descoberto e executa-se registro e processamento de subscrição para qualquer subscrição. A parte do novo comando de produtor do bloco 2235 é executada de maneira similar ao bloco 1750, enquanto o registro e processamento de subscrição é executado de modo similar aos blocos 1740 e 1745.

No bloco 2240, adiciona-se ao conjunto de produtores candida- tos recentemente adicionados ao registro inicial de execução. Do bloco 2240, o controle passa para o bloco 2245. O bloco 2240 é executado de ma- neira similar ao bloco 2200, exceto que apenas produtores recentemente adiciondos ao registro inicial de execução como resultado de blocos 2230 e 2235, são adicionados ao conjunto de produtores candidatos.

No bloco 2245, os produtores que foram executados são marca- dos como executados, o cache de saída de produtor (e cache de instância) é atualizado conforme necessário, qualquer produtor paterno dos produtores que foram executados é adicionado ao conjunto atual de produtores candi- datos e os produtores que foram executados são removidos do conjunto a- tuai de produtores candidatos e prontos. Do bloco 2245, o controle passa para o bloco 2250.

No bloco 2250, determina-se se o conjunto de produtores candi- datos está vazio. Se não estiver, o controle passa de volta para o bloco 2205; caso contrário, o controle passa para o bloco 2255.

No bloco 2255, determina-se se todas as subscrições foram completadas. Se sim, o controle passa para o bloco 2265 em que termina o fluxograma; caso contrário, o controle passa para o bloco 2260. Com refe- rência à modalidade da invenção na Figura 14A, a coluna de tipo de subscri- ção 1405 e a coluna completa 1420 são examinadas para qualquer subscri- * ção absorvente que não esteja completa.

No bloco 2260, a subscrição absorvente incompleta é processa- da e o controle passa para o bloco 2205. Uma maneira exemplificativa de executar o bloco 2260 será descrita posteriormente.

5 A Figura 23 é um fluxograma para o bloco 2205 da Figura 22, de

acordo com uma modalidade da invenção. Assim, o controle flui do bloco 2200 para o bloco 2305 no bloco 2205. No bloco 2305, para cada produtor no conjunto de produtores candidatos, os blocos seguintes 2310-2325 são executados.

No bloco 2310, determina-se se o produtor tem qualquer decla-

ração de dependência de produtor que esteja incompleta. Se tiver, o controle passa para o bloco 2325; caso contrário, o controle passa para o bloco 2315. Com referência à modalidade da Figura 14A, a coluna da chave de produtor do subscritor 1400 e a coluna de tipo de subscrição 1405 são examinadas 15 quanto a uma correspondência com o produtor selecionado no momento e tiop de subscrição absorvente; e se for encontrada uma correspondência, a coluna completada 1420 na fileira apropriada é verificada para determinar o estado daquela dependência de subscrição absorvente.

No bloco 2315, determina-se se os produtores dos quais o pro- 20 dutor selecionado no momento depende, são executados. Se não, o controle passa para o bloco 2325; caso contrário, o controle passa para o bloco 2320. Com referência à modalidade da invenção mostrada na Figura 11C, a coluna de marcações de execução incrementai 1180 para as fileiras das dependên- cias filiais, são verificadas para determinar o estado de execução do filho de 25 produtor selecionado no momento.

No bloco 2320, o produtor candidato selecionado no momento é adicionado ao conjunto atual de produtores prontos e o controle passa para

o bloco 2325.

No bloco 2325, o fluxo termina para o produtor atual selecionado no bloco 2305.

A Figura 24 é um fluxograma para o bloco 2225 da Figura 22, de acordo com uma modalidade da invenção. Deste modo, o controle flui do bloco 2210 para o bloco 2405 no bloco 2225. No bloco 2405, para cada pro- dutor de determinação de dependência, os seguintes blocos 2410-2430 são executados.

No bloco 2410, determina-se o tipo de qualquer dependência 5 anterior gerada pelo produtor de determinação de dependência selecionado no momento. Se o tipo da dependência for não-subscrição, então o controle passa para o bloco 2420; se o tipo for subscrição absorvente, então o con- trole passa para o bloco 2415; enquanto que, se o tipo fórmula subscrição adesiva, então o controle passa para o bloco 2425. O bloco 2410 é determi- 10 nado pela verificação da saída atual do produtor armazenado no cache de saída do produtor. Com referência à classe DEP, a saída indicaria não- subscrição, subscrição absorvente e subscrição adesiva.

Em ambos os blocos 2415 e 2425, a entrada é removida do re- gistro de subscrição. Com referência à modalidade da invenção mostrada 15 nas Figuras 14A-C, é realizado o seguinte: 1) para subscrições absorventes (bloco 2415), o produtor de determinação de dependência (por exemplo, produtor 1455) é usado para determinar seu produtor paterno (por exemplo, produtor 1450) no gráfico produtor e então, procura-se o produtor paterno no registro de subscrição e sua entrada é removida; e 2) para subscrições ade- 20 sivas (bloco 2425), procura-se o produtor de determinação de dependência (por exemplo, produtor 1470) no registro de subscrição e sua entrada é re- movida. Do bloco 2415, o controle passa para o bloco 2420; do bloco 2425,

o controle passa para o bloco 2420.

No bloco 2420, as ligações já criadas pelo produtor de determi- 25 nação de dependência selecionado no momento são retiradas do gráfico produtor e o controle passa para o bloco 2430. Com referência à modalidade da invenção mostrada na Figura 11C, é realizado o seguinte. Primeiro, de- termina-se se o produtor de determinação de dependência "aderiu" a um produtor existente. Isso é feito examinando-se a coluna de ligações de pro- 30 dutor filho do produtor de determinação de dependência 11C e verificando- se se uma das ligações tem o indicador adesivo indicando adesão.

Se o produtor de determinação de dependência não tiver aderido * ao um produtor existente; então: 1) para um produtor de determinação de dependência que tenha produzido dependências descendentemente decla- radas de não-subscrição (argumento, campo ou sequenciamento), o pai do produtor de determinação de dependência é acessado no gráfico produtor 5 através da coluna de referência de produtor paterno 1150 na fileira do produ- tor de determinação de dependência selecionado no momento e nesta en- trada do produtor paterno, a coluna de ligação de produtor filho 1160 é aces- sada para correspem quer a referência de produtor de determinação de de- pendência e todas as referências de produtores filhos tendo aquela referên- 10 cia de produtor de determinação de dependência são removidas; 2) para um produtor de determinação de dependência que tiver produzido dependências ascendentemente declaradas de não-subscrição, o pai do produtor de de- terminação de dependência é acessado no gráfico produtor através da colu- na de ligação de produtor paterno 1150 na fileira do produtor de determina- 15 ção de dependência selecionado no momento, e, nesta entrada de produtor paterno, a coluna de ligação de produtor paterno 1150 é acessada para cor- respem quer a referência de produtor de determinação de dependência e todas as referências de produtores paternos tendo aquela referência de pro- dutor de determinação de dependência são removidas; 3) para um produtor

1 20 de determinação de dependência que tiver produzido uma subscrição absor- vente, o mesmo comportamento das dependências descendentemente de- claradas de não-subscrição é executado; e 4) para um produtor de determi- nação de dependência que tiver produzido uma subscrição adesiva, procura- se a referência de produtor de determinação de dependência extraída da 25 coluna 1421 do registro de subscrição 14A antes da remoção da subscrição na estrutura de gráfico produtor na coluna de ligação de produtor paterno 1150 e todas as referências de produtores paternos tendo aquela referência de produtor de determinação de dependência são removidas.

Se o produtor de determinação de dependência tiver aderido a 30 um produtor existente, como resultado de dependência ascendentemente declarada de não-subscrição ou uma subscrição adesiva, então o produtor filho a que o produtor de determinação de dependência aderiu é acessado (o produtor filho na coluna 1160, com um indicador adesivo indicando a ade- são) e, nesta entrada de produtor filho, a coluna de ligação de produtor pa- terno 1150 é acessada para correspem quer a referência de produtor de de- terminação de dependência e todas as referências de produtores paternos 5 tendo aquela referência de produtor de determinação de dependência são removidas.

No bloco 2430 o fluxo termina para o produtor de determinação de dependência selecionado no bloco 2405.

A Figura 25 é um fluxograma para o bloco 2260 da Figura 22 de acordo com uma modalidade da invenção. Assim, o controle flui do bloco 2255 para o bloco 2505 no bloco 2260. No bloco 2505, para cada produtor com uma dependência de subscrição absorvente que esteja incompleta, os seguintes blocos 2510-2525 são executados.

No bloco 2510, determina-se se todos os produtores correspem 15 quentes foram executados. Se sim, o controle passa para o bloco 2515; caso contrário, o controle passa para o bloco 2525. Com referência às modalida- des das Figura 11C e 14A, a coluna de produtores correspem quentes 1415 na fileira apropriada é acessada para determinar os produtores correspem quentes e a coluna de execução incrementai 1180 nas fileiras apropriadas, é 20 verificada para cada um dos produtores correspem quentes.

No bloco 2515, a subscrição absorvente é marcada como com- pleta e o controle passa para o bloco 2520. Com referência às modalidades da Figura 14A, a coluna completa 1420 na fileira apropriada é definida para indicar completa.

No bloco 2520, o produtor selecionado no bloco 2505 é adicio-

nado ao conjunto atual de produtores candidatos e o controle passa para o bloco 2525.

No bloco 2525, o fluxo termina para o produtor selecionado no

bloco 2505.

Linguagens de Procedimento.

Conforme indicado anteriormente, linguagem de procedimento gravada apropriadamente, linguagem orientada por objeto não-reflexiva e * código de linguagem baseada em objeto não reflexivo, podem ser transfor- madas em código de linguagem orientada por objeto reflexiva. À guisa de exemplo, uma classe pode ser emulada através de uma estrutura de dados e um conjunto de funções estáticas tendo como um primeiro parâmetro um 5 apontador para uma instância da estrutura de dados. Entre essas funções estão as de construtor e destruidor. Os construtores são invocados pelo run- time após a alocação de um apontador para uma estrutura de dados e pro- porciona padrões para elementos na estrutura de dados e os destruidores são invocados pelo runtime antes da liberação de um apontador para a es-

10 trutura de dados. Cada classe tem sua descrição através de um arquivo que inclui: 1) a estrutura de dados; 2) uma outra estrutura descrevendo a classifi- cação, contendo o tamanho da estrutura e um conjunto de apontadores para funções; 3) uma lista de funções estáticas, com seu código (para linguagens orientadas por objeto reflexivas e linguagens baseadas em objeto não- 15 reflexivas, o código de funções estáticas seria gerado automaticamente por meio de métodos de varredura da classe real e criando para cada método, uma função estática que executa a invocação efetiva do método relaciona- do); e 4) anotações no topo de cada função (declarações de dependência de produtor com comentários), junto com seu tipo (construtora, destrutiva, pro- -20 priedade, etc.). Em adição a esta definição de uma classe na linguagem de procedimento, orientada por objeto não-reflexiva, ou baseada em objeto não- reflexiva, também é implementada invocação dinâmica. Especificamente, um compilador gera o seguinte código de inicialização para cada classe, código que é chamado uma vez (pelo novo módulo de classe) para: 1) instanciar a 25 estrutura que descreve a classe, preencher os apontadores para funções com as funções efetivas estáticas; 2) registrar a instância desta estrutura com um mapa de classes (a estrutura de rastreamento de classe com uma chave correspem quente ao nome da classe; e 3) registrar todos os aponta- dores em um mapa de funções (a estrutura de rastreamento de método) com 30 uma chave correspem quente ao nome da função (junto com ArgumentDe- pendencies, SequencingDependencies, FieIdDependencies, UpwardDepen- dencies, WeaklyConstrainedDependencies, chave de classe de saída, e anotações adicionais). O mapeamento permite implementos no runtime de funções genéricas de invocação capazes de: 1) instanciar uma instância de uma classe por nome (pelo novo módulo de instância) (especificamente, o runtime: a- alocar memória, de acordo com o tamanho da estrutura de da- dos, e adicionar um cabeçalho ao apontador para armazenar um apontador na estrutura que descreve a classe e implementar, consequentemente, a- pontadores inteligentes (por exemplo, apontadores capazes de consultar seus tipos); e b - invoca as funções construtoras apropriadas após a recupe- ração do apontador relevante para a função estática do mapa); e 2) invocar um método pelo nome, contanto que todos os parâmetros sejam passados adequadamente após a recuperação do apontador relevante para a função estática a partir do mapa. A passagem apropriada de parâmetros para fun- ções identificadas pelos apontadores para funções, seria feita através de linguagem assembly, elementos pushing e popping em/da pilha para parâ- metros de entrada e saída. O método descrito acima assume a existência da noção de estruturas de dados e a existência da noção de apontadores para funções na linguagem de procedimento, orientada por objeto não-reflexiva ou baseada em objeto não-reflexiva.

Sintaxe de Código Fonte Orientado por objeto Exemplificativa

A. Código Cliente

Em uma modalidade da invenção, o código cliente tem a seguin- te sintaxe (mostrada em forma de cabeçalho:

ProducerKey

New (String CJassKey5 InstanceKey InstanceKey, String MethodKey);

Runtime

New O

AddProducerOflnterest {ProducerKey PraducerOflntercstKey);

SetProducerOutput (ProdaeeriCey ProducerToOvemdeKey* Ofcyect Producerüutputlnsíance);

Execute ();

ProducerKey e Runtime são classes, enquanto New, AddProdu- cerOflnterest, SetProducerOutput e Execute, são métodos. AddProducerO- * finterest causa a invocação do novo comando de produtor com os valores apropriados para a situação de produtor de interesse na Tabela 2. Produce- rOutputlnstance é uma instância da classe de saída de produtor sobregrava- do. Assim, ele é instanciado através do construtor de classe de saída de produtor correspem quente.

B. Afirmações

1. Sintaxe de Afirmação de Declaração de Dependência

argumeníDependencv “ ”ArgumGnt3Dependency;Argument2Dependency;

« ·►* S

fi.eidDepend.eney = "FieldDependency I ;FieldDependency2;... sequencingDependency =

"iSequenclngDependencyl;SequencingDependency2;

UpwardDependency * 11UpwardDependencyi ;UpwardDependency2; ... WeeklyConstrainedDepeBdency ~

“ WeeklyConstrainedDependency 1; W eekl y ConstrainedDependency2;.. unConstraínedDependeney "

tsUnConstrainedDependencyl ;unConstTainedDependency2;, „n;

2. Sintaxe de Dependência

a. fieldDependencvX. sequencíngDependencvX, upwardDependencvX. weeklyConstratn&dDeDendenevX.sintaxe nnConstrainedDependencvX

1 o fC^ClassKey^^^IflnstanceKey^^M/fMelhodKcy’ b. Sintaxe argumentXDependency:

ArgumeniíD: :# C f CIassKeyInstanceICey#MMetItodKey ’

Em uma modalidade da invenção, o ArgumentID é omitido na sintaxe e a ordem de declaração de argumentDependencies, representa Ar- gumentID. Assim, ArgumentID é adicionado para melhorar a legibilidade.

3. Atalho e Não-atalho

A sintaxe é a mesma para um não-atalho, mas o uso de #S:: an- tes da chave de produtor, indica um atalho. a fieldDependencvX, sequencingDepcndenevX. upwardDependencvX, week I vCo ns tra i n edDeaendencvX.sintaxe unConstrainedDependencvX

#S::#C: * CIassKey1: ;#I: rInstanceKey1 vM M: 1MethodKey* b. Sintaxe argumentXDependency Argum.entID::#S: JCfClassKey5 ::#I;’InstanoeKey’: JMr5MethodKey'’

Neste caso, a chave de produtor indicada pela dependência não é um produtor de determinação de dependência. Outras implementações de sintaxe podem assumir que o atalho é a dependência padrão para um certo tipo de dependência (como campo), e omitir #S::. Nesse caso, pode-se usar #DDP para indicar a presença de DDP.

4. Contingente e não-continqente Conforme descrito anteriormente, pode-se colocar

antes de

um elemento contingente.

a. Exemplo de classe e método contingente:

11 fieldDependencvX, s&quencineDependencvX. UpwardDependencvX. weeklyConstrainedDependencvX, ursConstrainedDependencvX svntax:

#C:

TiassDetermmationMethocíKey" InstanceKey* ::#M:

"MetfaodDetermmationMethodKey*

2. Sintaxe argumentXDependency ArgumentlD^C^^ClassDetermmatÍQnMethodKey’ ;:#I: MnstanoeKey'

-| g M:

’MethodDetermínationMethodKey’

b. Exemplo de método contingente

I) fi e I d D e p e n d e n c vX, sequencineDependcncvX.

UpwardDependencvX- weekl vCtmstraínedDependenevX. sintaxe unConstrainedDependencvX

tfCtOlassKey^JI^InstanceKeF^JM:

’ MethodDet erm i natí onMethodKey * * 2) Sintaxe argumentXDependency:

ArgumentID:: #C: *C IassKey ’:#I: 'InstanceKeyi: :#M;

<?> 'MefhodDetermInatIoriMetiiodKey*

c. Exemplo de instância contingente

D fieldDependencvX, sequencineDenendencyX. upwardDependencvX, weekJyConstraincdDependencvX .sintaxe unConstrainedDependencvX

#C:' ClassKey':M:

’Ir!StanccDeterminaíionMethodKey,::#M:

‘ MethodKey ’

5 2. Sintaxe argumentXDependency

Argwm entID: : iClassKey ’: :#I:

’ InstanceDeteraiinationMethodKey*: JM: lMethodKey'

5. Técnica de atalho

Elementos tais como classe, instância ou método, que são con- siderados como sendo idênticos aos elementos de produtor pai, são omiti- dos. Este é tipicamente o caso de campos de atalho. Os exemplos dados abaixo combinam a técnica de atalho e uma declaração de atalho (o atalho é ilustrado por um #S::

a. Exemplo em que a classe e a instância são omitidas

1) fieldDependencvX, sequencinaDependencvX. upwardDependencvX. weeklvConstralnedDependenevX, sintaxe unConstrainedDependencvX

#S ^MfMethodKeyt

2. Sintaxe argumentXDependency ÁrgumentID::#S:: PM:'MethodKey1

b. Exemplo em que a classe é omitida

sintaxe I) fieldDependencvX, sequencingDependencvX. upwardDcpendencvX. weekivConstrainedDependencvX. un ConstrainedDependencvX svntax:

4$::. Hf InstanceKey ’::#M:'MethodKeyi

2. sintaxe argumentXDependency:

ArgumentID::#S:: #1:’InstanceKey1:: #M: 1MethodKey'

Modalidades Alternativas Embora os diagramas de fluxo nas figuras mostrem uma ordem

particular de operações realizadas por certas modalidades da invenção, de- ve-se entender que tal ordem é exemplificativa (por exemplo, modalidades alternativas podem realizar as operações em uma ordem diferente, combinar certas operações, sobrepor certas operações, etc.)

Embora a invenção tenha sido descrita em termos de diversas

modalidades, aqueles que são versados na técnica irão reconhecer que a invenção não está limitada às modalidades descritas, pode ser praticada com modificação e alteração dentro do espírito e escopo das reivindicações anexas. Assim, a descrição deve ser considerada como ilustrativa, ao invés de limitante.

Claims

1. Aparelho para executar código orientado por objeto, o apare- lho compreendendo: um runtime que interpreta declarações de dependência do pro- dutor para métodos no código orientado por objeto, as ditas declarações de dependência do produtor identificando no runtime um conjunto de zero ou mais produtores, em que um produtor é uma construção instanciável pelo runtime que inclui ao menos uma ocorrência e um método associado àquela ocorrência, sendo que o runtime inclui, um módulo de geração de gráfico produtor automatizado para receber uma designação de um produtor de interesse, para adicionar o pro- dutor de interesse como parte de um gráfico produtor e automaticamente gerar um restante do gráfico produtor através de ligação e instanciação, con- forme necessário, de outros produtores com base nas declarações de de- pendência do produtor dos métodos dos produtores já no gráfico produtor, e um módulo de execução de gráfico de produtor para executar os produtores no gráfico produtor na ordem indicada pelo gráfico produtor, em que a execução de cada produtor resulta no método do produtor que está sendo executado na ocorrência do produtor.

2. Aparelho, de acordo com a reivindicação 1, em que o dito mó- dulo de geração de gráfico produtor automatizado pode não ser capaz, inici- almente, de completar a geração do gráfico produtor até alguns produtores do gráfico produtor serem executados, e em que o dito módulo de execução do gráfico produtor pode invocar o módulo de geração de gráfico produtor automatizado com saídas necessárias do produtor durante a execução do gráfico produtor para completar saldos não solucionados do gráfico produtor.

3. Aparelho, de acordo com a reivindicação 1, em que o conjunto de produtores que será identificado no momento de execução por pelo me- nos uma das ditas declarações de dependência do produtor inclui ao menos um produtor a ser executado antes da execução do produtor que inclui o mé- todo daquela declaração de dependência do produtor.

4. Aparelho, de acordo com a reivindicação 1, em que o dito grá- fico produtor representa sequenciamento de execução conforme identificado pelas declarações de dependência do produtor dos métodos dos produtores no gráfico produtor.

5. Aparelho, de acordo com a reivindicação 1, em que o conjunto de produtores que será identificado no momento de execução por pelo me- nos uma das ditas declarações de dependência do produtor para um dado método inclui ao menos um produtor com uma saída que é uma entrada di- reta no dado método.

6. Aparelho, de acordo com a reivindicação 1, em que o gráfico produtor representa as dependências diretas entre entrada e saída dos pro- dutores entre símbolo dos produtores de interesse e aqueles que são nós finais do gráfico produtor.

7. Aparelho, de acordo com a reivindicação 1, em que o runtime compreende ainda: um módulo de saída do produtor de sobreposição para receber modificações atuais na saída de um ou mais dos produtores em uma versão atual do gráfico produtor; uma estrutura de gráfico produtor, acoplada ao módulo de gera- ção de gráfico produtor automatizado, para armazenar a versão atual do grá- fico produtor e a saída atual de cada um dos produtores no gráfico produtor atual; e o dito módulo de execução do gráfico produtor, acoplado ao mó- dulo de saída do produtor de sobreposição e estrutura do gráfico produtor, para fazer as modificações atuais, para rastrear que produtores na versão atual do gráfico produtor precisam ser executados porque eles são afetados indiretamente por qualquer das modificações atuais e executar apenas os produtores da versão atual do gráfico produtor que precisam, no momento, ser executados para manter a consistência da versão atual do gráfico produ- tor.

8. Aparelho, de acordo com a reivindicação 7, em que a estrutu- ra de gráfico produtor compreende ainda: uma estrutura de marcação de execução incrementai para auxi- liar o módulo de execução de gráfico produtor a rastrear que produtores na versão atual do gráfico produtor precisam ser executados novamente devido a qualquer modificação atual.

9. Aparelho, de acordo com a reivindicação 7, compreendendo adicionalmente: um registro de sobreposição, acoplado ao módulo de saída do produtor de sobreposição e ao módulo de execução do gráfico produtor, pa- ra coletar múltiplas sobreposições para processamento em lote.

10. Aparelho, de acordo com a reivindicação 7, em que o módulo de saída produtor de sobreposição também deve receber indicações de que deve-se desfazer a sobreposição em uma ou mais saídas sobrepostas.

11. Aparelho, de acordo com a reivindicação 1, em que o runti- me compreende adicionalmente: um registro de comando, acoplado ao módulo de geração de gráfico produtor automatizado, para coletar múltiplos comandos juntos para processamento em lote.

12. Aparelho, de acordo com a reivindicação 1, em que cada método do produtor é um método de uma classe daquela ocorrência do pro-20 dutor.

13. Aparelho, de acordo com a reivindicação 12, em que as de- clarações de dependência do produtor são parte de definições de classe pa- ra classes no código orientado por objeto.

14. Aparelho, de acordo com a reivindicação 1, em que qualquer método pode ter uma das ditas declarações de dependência do produtor.

15. Aparelho, de acordo com a reivindicação 1, em que o runti- me substitui a necessidade de código de sequenciamento de invocação ma- nual e em que o método de cada um dos produtores é um método de trans- formação e o runtime descobre sequenciamento para estes métodos de transformação das declarações de dependência do produtor.

16. Aparelho, de acordo com a reivindicação 1, em que os nós finais do gráfico produtor são produtores independentes.

17. Aparelho, de acordo com a reivindicação 1, em que o runti- me compreende adicionalmente: uma estrutura de rastreio de ocorrências, acoplada ac módulo de geração de gráfico produtor automatizado e ao módulo de execução do gráfico produtor para armazenar referências às ocorrências de produtores; e uma estrutura de rastreio de método, acoplada ao módulo de ge- ração de gráfico produtor automatizado e ao módulo de execução de gráfico produtor para armazenar referências aos métodos de produtores e informa- ções referentes a suas declarações de dependência do produtor.

18. Aparelho, de acordo com a reivindicação 17, em que o run- time compreende adicionalmente: um novo módulo de ocorrência, acoplado à dita estrutura de ras- treamento de ocorrência, para receber a designação de instanciar, se ne- cessário, o produtor de interesse selecionado no momento; uma estrutura de rastreamento de classe para rastrear referên- cias a classes; e um novo módulo de classe, acoplado à estrutura de rastreamen- to de classe, para carregar e examinar definições de classe.

19. Aparelho, de acordo com a reivindicação 1, em que o runti- me compreende adicionalmente: um módulo visualizador de gráfico produtor para exibir grafica- mente uma representação do gráfico produtor atual.

20. Aparelho, de acordo com a reivindicação 1, em que o runti- me compreende adicionalmente: um módulo de interface gráfica com o usuário com Iayout de sa- ída do produtor interativo configurável para exibir graficamente saídas e per- mitir interação com o gráfico produtor.

21. Aparelho, de acordo com a reivindicação 1, em que o módulo de execução do gráfico produtor inclui: um módulo de dependências dinâmico para solucionar qualquer dependência do produtor dinâmico, em que cada declaração de dependên- cia de produtor pode incluir uma dependência do produtor dinâmico, em que as dependências do produtor dinâmico fazem com que o runtime selecione, dinamicamente, o conjunto de zero ou mais produtores que a declaração de dependência do produtor identifica durante o runtime, e em que a seleção dinâmica pode causar a seleção de diferentes produtores para o conjunto durante diferentes execuções do gráfico produtor.

22. Aparelho, de acordo com a reivindicação 21, em que as de- pendências do produtor dinâmico incluem dependências do produtor contin- gentes, em que as dependências de produtor contingente são dependências dos produtores de determinação de dependência que, por elas mesmas, são dependentes da saída de um ou mais outros produtores.

23. Aparelho, de acordo com a reivindicação 21, em que as de- pendências de produtor dinâmico incluem assinaturas, em que as assinatu- ras identificam critérios por meio dos quais os produtores são comparados para determinar se eles são produtores de gatilho, em que as assinaturas identificam dependências dos produtores de gatilho.

24. Aparelho, de acordo com a reivindicação 23, em que algu- mas das ditas assinaturas são assinaturas absorventes, em que as assinatu- ras absorventes fazem com que o runtime inclua dinamicamente qualquer produtor de gatilho no conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica durante o runtime.

25. Aparelho, de acordo com a reivindicação 23, em que algu- mas das ditas assinaturas são assinaturas adesivas, em que as assinaturas adesivas também identificam características para produtores pais e em que as assinaturas adesivas fazem com que o runtime, para cada produtor de gatilho localizado, instancie um produtor pai que atenda às características identificadas e o inclua no gráfico produtor como tendo uma dependência de produtor naquele produtor de gatilho.

26. Aparelho, de acordo com a reivindicação 1, em que alguns dos zero ou mais produtores são produtores de determinação de dependên- cia cuja execução retorna identificações de runtime de dependências de produtores entre símbolo.

27. Aparelho, de acordo com a reivindicação 26, em que a exe- cução de alguns dos produtores de determinação de dependência retorna dependências declaradas ascendentemente.

28. Aparelho, de acordo com a reivindicação 1, em que pelo me- nos algumas das dependências representadas pelo gráfico produtor são de- signadas como dependências de argumento e dependências de campo, em que as dependências de argumento fazem com que o runtime mapeie saí- das de produtores filhos como parâmetros de entrada em produtores pais e em que as dependências de campo indicam usos de campos de ocorrências.

29. Aparelho, de acordo com a reivindicação 1, em que pelo me- nos algumas das dependências representadas pelo gráfico produtor são de- signadas como sequenciamento apenas de dependências, em que o se- quenciamento apenas de dependências requer saídas que precisam ser for- necidas, se existirem, dos produtores filhos para os produtores pais que o- correm através de código no método do produtor filho para gravar a saída para um dado mecanismo e código no método do produtor pai para Ier aque- la saída a partir do dado mecanismo.

30. Aparelho, de acordo com a reivindicação 1, em que as cha- ves do método são usadas para distinguir os métodos, chaves de ocorrência são usadas para distinguir as ocorrências e as chaves de produtor são usa- das para distinguir os produtores, em que a chave de produtor para cada produtor é baseada pelo menos na chave de ocorrência e na chave do mé- todo daquela ocorrência e método de produtor.

31. Aparelho, de acordo com a reivindicação 30, em que as o- corrências são exemplos de uma pluralidade de classes, em que as chaves de classe são usadas para distinguir a dita pluralidade de classes e em que a chave de produtor para cada produtor também é baseada na chave de classe da classe daquele exemplo de produtor.

32. Aparelho, de acordo com a reivindicação 30, e que a chave de ocorrência de pelo menos alguns produtores retém uma referência à o- corrência do produtor.

33. Aparelho, de acordo com a reivindicação 1, em que pelo me- nos algumas das ditas declarações de dependência do produtor incluem de- pendências declaradas ascendentemente.

34. Aparelho, de acordo com a reivindicação 1, em que pelo me- nos algumas das ditas declarações de dependência de produtor incluem de- pendências declaradas descendentemente.

35. Aparelho, de acordo com a reivindicação 1, em que pelo me- nos algumas das ditas declarações de dependência do produtor incluem de- pendências declaradas tanto descendentemente quanto ascendentemente.

36. Aparelho, de acordo com a reivindicação 1, em que o dito módulo de geração de gráfico produtor automatizado é responsivo a novos comandos de produtor e em que o dito módulo de execução de gráfico pro- dutor é responsivo para executar comandos.

37. Aparelho para executar código orientado por objeto, o dito aparelho compreendendo: um runtime que interpreta declarações de dependência do pro- dutor para métodos no código orientado por objeto, as ditas declarações de dependência do produtor identificando em runtime um conjunto de zero ou mais produtores, em que um produtor é uma construção instanciável no run- time que inclui ao menos uma ocorrência e um método associado àquela ocorrência, em que o método de cada produtor é um método de uma classe de ocorrência daquele produtor, em que as declarações de dependência do produtor são parte de definições de classe para classes no código orientado por objeto e em que ao menos algumas das ditas declarações de dependên- cia do produtor incluem dependências declaradas descendentemente, sendo que o runtime inclui um módulo de geração de gráfico produtor automatizado para receber uma designação de um produtor de interesse para adicionar o produtor de interesse como parte de um gráfico produtor atual, e para gerar automaticamente um saldo do gráfico produtor atual através de ligação e instanciação, se necessário, de outros produtores com base nas declarações de dependência de produtor dos métodos dos produtores já no gráfico pro- dutor atual, uma estrutura de gráfico produtor, acoplada ao módulo de gera- ção de gráfico produtor automatizado, ao gráfico produtor atual e à saída atual de cada um dos produtores no gráfico produtor atual, em que as cha- ves do método são usadas para distinguir os métodos, e as chaves de pro- dutor são usadas para distinguir os produtores e em que a chave de produtor para um dado produtor é baseada pelo menos na chave de ocorrência e chave de método da ocorrência e método daquele produtor; e um módulo de execução de gráfico produtor acoplado à estrutu- ra de gráfico produtor para executar os produtores no gráfico produtor atual na ordem indicada pelo gráfico produtor atual, em que o gráfico produtor a- tual representa o sequenciamento apropriado de execução, conforme defini- do pelas declarações de dependência do produtor dos métodos dos produto- res no gráfico produtor atual e em que a execução de cada produtor resulta no método do produtor que está sendo executado na ocorrência do produtor, o dito módulo de execução de gráfico produtor incluindo, um módulo de dependências dinâmicas para solucionar qualquer dependência de produtor dinâmica, em que cada declaração de dependên- cia de produtor pode incluir uma dependência de produtor dinâmica, em que as dependências de produtor dinâmicas fazem com que o runtime selecione dinamicamente o conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica durante o runtime, em que a seleção di- nâmica pode causar a seleção de diferentes produtores para o conjunto du- rante diferentes execuções do gráfico produtor atual, em que as dependên- cias de produtor dinâmicas incluem dependências de produtor contingentes e em que as dependências de produtor contingentes são dependências de produtores de determinação de dependência que, elas próprias, são depen- dentes da saída de um ou mais outros produtores.

38. Aparelho, de acordo com a reivindicação 37, em que o run- time compreende adicionalmente: um módulo visualizador de gráfico produtor para exibir grafica- mente uma representação do gráfico produtor atual.

39. Aparelho, de acordo com a reivindicação 37, em que o run- time compreende adicionalmente: um módulo de interface gráfica com o usuário com Ieiaute de sa- ida de produtor interativa configurável para exibir graficamente saídas de e permitir a interação com o gráfico produtor atual.

40. Aparelho, de acordo com a reivindicação 37, em que as de- pendências de produtor dinâmicas incluem assinaturas, em que as assinatu- ras identificam critérios por meio dos quais os produtores são comparados para determinar se eles são produtores de gatilho, em que as assinaturas identificam dependências dos produtores de gatilho.

41. Aparelho, de acordo com a reivindicação 40, em que algu- mas das ditas assinaturas são assinaturas absorventes, em que as assinatu- ras absorventes fazem com que o runtime inclua dinamicamente qualquer produtor de gatilho no conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica durante o runtime.

42. Aparelho, de acordo com a reivindicação 40, em que algu- mas das ditas assinaturas são assinatura adesivas, e que as assinaturas adesivas também identificam características para produtores pais, e em que as assinaturas adesivas fazem com que o runtime, para cada produtor de gatilho localizado, instancie um produtor pai que atenda às características identificadas e as inclua no gráfico produtor atual.

43. Aparelho, de acordo com a reivindicação 37, em que alguns dos produtores são produtores de determinação de dependência cuja exe- cução retorna identificações de dependências de produtores entre símbolo.

44. Aparelho, de acordo com a reivindicação 43, em que a exe- cução de alguns dos produtores de determinação de dependência retornam dependências declaradas ascendentemente.

45. Aparelho, de acordo com a reivindicação 37, em que pelo menos algumas das declarações de dependência de produtor incluem uma ou mais de uma dependência de argumento e uma dependência de campo, em que as dependências de argumento fazem com que o runtime mapeie saídas de produtores filhos como parâmetros de entrada para produtores pais e em que as dependências de campo identificam usos de campos de ocorrências.

46. Aparelho, de acordo com a reivindicação 37, em que as cha- ves de classe são usadas para distinguir as classes e em que a chave de produtor para cada produtor também é baseada na chave de classe da ocor- rência daquele produtor.

47. Aparelho, de acordo com a reivindicação 37, em que a chave de ocorrência de pelo menos alguns produtores retém uma referência à o- corrência do produtor.

48. Aparelho, de acordo com a reivindicação 37, em que o dito módulo de geração de gráfico produtor automatizado é para receber múlti- plas designações de produtores de interesse e é para gerar automaticamen- te múltiplos gráficos de produtor atuais e em que o dito módulo de execução de gráfico produtor é responsivo a comandos de execução globais que fa- zem com que todos os gráficos de produtor atuais sejam executados.

49. Método para executar código orientado por objeto, o dito mé- todo compreendendo: instanciar um produtor com uma saída que, atualmente, é de in- teresse, em que o código orientado por objeto inclui métodos e declarações de dependência de produtor, em que a declaração de dependência de pro- dutor para um dado método identifica um conjunto de zero ou mais produto- res, em que um produtor é uma construção instanciável de runtime que inclui ao menos uma ocorrência e um método associado àquela ocorrência; em resposta à dita instanciação, adicionar o produtor de interes- se como parte de um gráfico produtor atual; tentar gerar automaticamente um saldo do gráfico produtor atual através de ligação e instanciação, conforme for necessário, de outros produ- tores com base nas declarações de dependência do produtor dos métodos dos produtores já no gráfico produtor atual; e executar os produtores no gráfico produtor atual para determinar a saída atual para o dito produtor de interesse.

50. Método, de acordo com a reivindicação 49, em que a dita tentativa de gerar automaticamente compreende adicionalmente: tentar descobrir e construir, automaticamente, a partir de decla- rações de dependência do produtor no dito código orientado por objeto, o gráfico produtor atua! que representa relações diretas entre entrada e saída de produtores necessários para gerar um valor atual do conjunto de uma ou mais entradas para o produtor de interesse, em que uma saída atual de cada um dos produtores no gráfico produtor atual é uma entrada direta em um outro dos produtores no gráfico produtor atual e/ou produtor de interesse.

51. Método, de acordo com a reivindicação 49, em que a dita execução dos produtores no gráfico produtor atual compreende adicional- mente: gerar automaticamente partes adicionais do gráfico produtor a- tual através da execução de alguns dos produtores do gráfico produtor atual que retornam identificações de dependências de outros produtores entre símbolo a serem adicionados ao gráfico produtor atual.

52. Método, de acordo com a reivindicação 49, em que a dita execução inclui: solucionar qualquer dependência de produtor dinâmica em que cada declaração de dependência de produtor pode incluir uma dependência de produtor dinâmica, em que as dependências de produtor dinâmicas fa- zem com que o runtime selecione dinamicamente o conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica du- rante o runtime.

53. Método, de acordo com a reivindicação 52, em que as de- pendências de produtor dinâmicas incluem dependências de produtor con- tingentes em que as dependências de produtor contingentes são dependên- cias de produtores de determinação de dependência que são, eles próprios, dependentes da saída de um ou mais outros produtores.

54. Método, de acordo com a reivindicação 52, em que as de- pendências de produtor dinâmicas incluem assinaturas, em que as assinatu- ras identificam critérios por meio dos quais os produtores são comparados para determinar se eles são produtores de gatilho, em que as assinaturas identificam dependências para produtores de gatilho.

55. Método, de acordo com a reivindicação 54, em que algumas das assinaturas são assinaturas absorventes, em que as assinaturas absor- ventes causam a inclusão dinâmica de qualquer produtor de gatilho no con- junto de zero ou mais produtores que a declaração de dependência de pro- dutor identifica.

56. Método, de acordo com a reivindicação 54, em que algumas das ditas assinaturas são assinaturas adesivas, em que as assinaturas ade- sivas também identificam características para produtores pais, e em que as assinaturas adesivas causam, para cada produtor de gatilho localizado, ins- tanciação de um produtor pai que atende às características identificadas e inclusão no gráfico produtor atual como tendo uma dependência de produtor naquele produtor de gatilho.

57. Método, de acordo com a reivindicação 49, em que a dita tentativa de gerar automaticamente compreende adicionalmente: instanciar qualquer ocorrência dos produtores que ainda não te- nha sido instanciada; e instanciar os produtores que ainda não foram instanciados.

58. Método, de acordo com a reivindicação 49, em que a dita tentativa de gerar automaticamente compreende adicionalmente: carregar qualquer classe das ocorrências dos produtores que a- inda não foram carregados; e examinar as definições de classe das classes que ainda não fo- ram examinadas incluindo as declarações de dependência do produtor con- tidas ali.

59. Método, de acordo com a reivindicação 58, em que a dita tentativa de gerar automaticamente inclui: descobrir e construir no gráfico produtor atual um dos produtores para os quais a classe da ocorrência do produtor já foi carregada e exami- nada antes da dita tentativa, a ocorrência do produtor já foi instanciada antes da dita tentativa e o produtor já foi instanciado antes da dita tentativa.

60. Método, de acordo com a reivindicação 49, compreendendo adicionalmente: exibir graficamente uma representação do gráfico produtor atual.

61. Método, de acordo com a reivindicação 49, compreendendo adicionalmente: exibir graficamente saídas de e permitir a interação com o gráfi- co produtor atual.

62. Método, de acordo com a reivindicação 49, compreendendo adicionalmente: armazenar uma saída atual dos produtores do gráfico produtor atual; sobrepor a saída atual de um ou mais dos produtores do gráfico produtor atual; e executar novamente, de acordo com o gráfico produtor atual e a sobreposição e a saída atual armazenada daqueles dos produtores que não são afetados, direta ou indiretamente pela dita sobreposição, apenas daque- les dos ditos produtores que são afetados, direta ou indiretamente, pela dita sobreposição para determinar sua saída atual.

63. Método, de acordo com a reivindicação 62, em que aqueles dos ditos produtores que são afetados não são todos os produtores no gráfi- co produtor atual.

64. Método, de acordo com a reivindicação 62, compreendendo adicionalmente: desfazer a sobreposição; e executar novamente, de acordo com o gráfico produtor atual e o desfazimento da sobreposição e a saída atual armazenada daqueles dos produtores que não são afetados direta ou indiretamente pela dita sobrepo- sição, apenas aqueles dos ditos produtores que são afetados, direta ou indi- retamente, pelo dito desfazimento de sobreposição para determinar sua saí- da atual.

65. Método, de acordo com a reivindicação 49, em que pelo me- nos algumas das dependências declaradas pelas declarações de dependên- cia de produtor são designadas como dependências de argumento e depen- dências de campo, em que as dependências de argumento causam o mape- amento de saídas de produtores filhos como parâmetros de entrada em pro- dutores pais e em que as dependências de campo indicam usos de campos

66. Método, de acordo com a reivindicação 49, em que peio me- nos algumas das dependências declaradas pelas declarações de dependên- cia de produtor são designadas como dependências apenas de sequencia- mento, em que a dependência apenas de sequenciamento requer saídas que não precisam ser fornecidas, se houver a partir de produtores filhos para produtores pais através de código no método do produtor filho para gravar a saída para um dado mecanismo e código no método do produtor pai para Ier aquela saída do dado mecanismo.

67. Método, de acordo com a reivindicação 49, em que as cha- ves de método são usadas para distinguir os métodos, as chaves de ocor- rência são usadas para distinguir as ocorrências e as chaves de produtor são usadas para distinguir os produtores, em que a chave de produtor para um dado produtor é baseada pelo menos na chave de ocorrência e na chave de método da ocorrência e método daquele produtor.

68. Método, de acordo com a reivindicação 67, em que as ocor- rências são ocorrências de uma pluralidade de classes, em que as chaves de classe são usadas para distinguir a dita pluralidade de classes e em que a chave de produtor para cada produtor também é baseada na chave de classe da classe da ocorrência daquele produtor.

69. Método, de acordo com a reivindicação 67, em que a chave de ocorrência de pelo menos alguns produtores retém uma referência à o- corrência do produtor.

70. Método, de acordo com a reivindicação 49, em que pelo me- nos algumas das ditas declarações de dependência do produtor incluem de- pendências declaradas ascendentemente.

71. Método, de acordo com a reivindicação 49, em que pelo me- nos algumas das ditas declarações de dependência de produtor incluem de- pendências declaradas descendentemente.

72. Método, de acordo com a reivindicação 49, em que pelo me- nos algumas das ditas declarações de dependência de produtor incluem de- pendências declaradas tanto descendentemente quanto ascendentemente.

73. Método, de acordo com a reivindicação 49, em que a dita instanciação é realizada em resposta a um novo comando de produtor e a dita execução é realizada em resposta a um comando de execução global.

74. Método para executar código orientado por objeto, sendo que o dito método compreende: receber uma indicação de um produtor de interesse, em que um produtor é uma construção instanciável por runtime que inclui ao menos uma ocorrência e um método associado àquela ocorrência; gerar automaticamente e executar um gráfico produtor com base no dito produtor de interesse e declaração de dependência de produtor para métodos, em que o dito gráfico produtor inclui um subgráfico alvo que inclui o dito produtor de interesse e uma pluralidade de níveis de outros produto- res, sendo que gerar e executar automaticamente inclui. realizar iterativamente o seguinte até os produtores fonte serem alcançados descobrir, construir e executar um subgráfico de decisão de pro- dutores com base na declaração de dependência de produtor do método de um dos produtores já no subgráfico alvo e adicionar ao dito subgráfico alvo um conjunto de um ou mais dos outros produtores retornados pelo dito subgráfico de decisão, e executar os produtores no subgráfico alvo em seqüência con- forme é indicado pelo subgráfico alvo, em que a execução de cada produtor resulta no método do produtor sendo executado na ocorrência do produtor.

75. Método, de acordo com a reivindicação 74, em que ao me- nos um produtor é parte tanto do subgráfico alvo quanto de um dos subgráfi- cos de decisão.

76. Método, de acordo com a reivindicação 74, em que um pri- meiro dos subgráficos de decisão inclui uma raiz que é um produtor de de- terminação de dependência e inclui nós em pelo menos alguns dos quais são produtores padrão.

77. Método, de acordo com a reivindicação 74, em que o subgrá- fico alvo tem uma raiz que é um produtor padrão.

78. Método, de acordo com a reivindicação 74, em que pelo me- nos um dos subgráficos de decisão retorna uma assinatura.

79. Método, de acordo com a reivindicação 78, em que a assina- tura é uma assinatura absorvente que indica critérios de assinatura absor- vente para produtores de gatilho.

80. Método, de acordo com a reivindicação 78, em que a assina- tura é uma assinatura adesiva que indica critérios de assinatura adesiva pa- ra produtores de gatilho e características de assinatura adesiva para um produtor pai a ser criado.

81. Método, de acordo com a reivindicação 74, em que pelo me- nos um dos subgráficos de decisão retorna uma dependência de produtor declarada ascendentemente.

82. Método, de acordo com a reivindicação 74, em que pelo me- nos algumas das declarações de dependência de produtor identificam um ou mais de uma dependência de argumento e dependência de campo, em que as dependências de argumento causam o mapeamento de saídas de produ- tores filhos como parâmetros de entrada em produtores pais e em que as dependências de campo indicam usos de campos de ocorrências.

83. Método, de acordo com a reivindicação 74, em que as cha- ves de método são usadas para distinguir os métodos, as chaves de ocor- rência são usadas para distinguir as ocorrências e as chaves de produtor são usadas para distinguir os produtores, em que a chave de produtor para cada produtor é baseada pelo menos na chave de ocorrência e na chave de método da ocorrência e método daquele produtor.

84. Método, de acordo com a reivindicação 83, em que as ocor- rências são ocorrências de uma pluralidade de classes, em que as chaves de classe são usadas para distinguir a dita pluralidade de classes e em que a chave de produtor para cada produtor também é baseada na chave de classe da classe da ocorrência daquele produtor.

85. Método, de acordo com a reivindicação 83, em que a chave de ocorrência de pelo menos alguns produtores retém uma referência à o- corrência do produtor.

86. Método, de acordo com a reivindicação 74, compreendendo adicionalmente: exibir graficamente uma representação do gráfico produtor.

87. Método, de acordo com a reivindicação 74, compreendendo adicionalmente: exibir graficamente saídas de e permitir a interação com o gráfi- co produtor.

88. Método, de acordo com a reivindicação 74, compreendendo adicionalmente: receber um comando de execução após o dito recebimento da indicação do produtor de interesse e antes de gerar e executar automatica- mente.

89. Aparelho para executar código orientado por objeto, o dito aparelho compreendendo: um runtime para gerar e executar automaticamente um gráfico produtor com base em um produtor de interesse e declaração de dependên- cia de produtor para métodos, em que um produtor é uma construção ins- tanciável por runtime que inclui ao menos uma ocorrência e um método as- sociado àquela ocorrência, o dito runtime incluindo os seguintes módulos relacionados iterativamente, um módulo de geração de gráfico produtor automatizado para receber uma designação do dito produtor de interesse, para adicionar o dito produtor de interesse a um subgráfico alvo do dito gráfico de produtor, e ge- rar automaticamente uma pluralidade de níveis de outros produtores no dito subgráfico alvo através da descoberta e construção automáticas de subgrá- ficos de decisão na declaração de dependência de produtor dos métodos dos produtores atualmente no subgráfico alvo, e um módulo de execução de gráfico de produtor para executar os produtores no gráfico produtor, em que a execução de cada produtor resulta no método do produtor ser executado na ocorrência do produtor e em que a execução de cada um dentre a pluralidade de subgráficos de decisão, adi- ciona ao menos um outro produtor ao dito subgráfico alvo.

90. Aparelho, de acordo com a reivindicação 89, em que ao me- nos um produtor é parte tanto do subgráfico alvo quanto de um dos subgráfi- cos de decisão.

91. Aparelho, de acordo com a reivindicação 89, em que um primeiro dos subgráficos de decisão inclui uma raiz que é um produtor de determinação de dependência e inclui nós em que pelo menos alguns dos quais são produtores padrão.

92. Aparelho, de acordo com a reivindicação 89, em que o sub- gráfico alvo tem uma raiz que é um produtor padrão.

93. Aparelho, de acordo com a reivindicação 89, em que pelo menos um dos subgráficos de decisão retorna uma assinatura.

94. Aparelho, de acordo com a reivindicação 93, em que a assi- natura é uma assinatura absorvente que indica critérios de assinatura absor- vente para produtores de gatilho.

95. Aparelho, de acordo com a reivindicação 93, em que a assi- natura é uma assinatura adesiva que indica critérios de assinatura adesiva para produtores de gatilho e características de assinatura adesiva para um produtor pai ser criado.

96. Aparelho, de acordo com a reivindicação 89, em que ao me- nos um dentre a pluralidade de subgráficos de decisão retorna uma depen- dência de produtor declarada ascendentemente.

97. Aparelho, de acordo com a reivindicação 89, em que ao me- nos uma das declarações de dependência de produtor identifica um ou mais dentre uma dependência de argumento e dependência de campo, em que as dependências de argumento causam o mapeamento de saídas de produto- res filhos como parâmetros de entrada em produtores pais, e em que as de- pendências de campo indicam usos de ocorrências.

98. Aparelho, de acordo com a reivindicação 89, em que as cha- ves de método são usadas para distinguir os métodos, as chaves de ocor- rência são usadas para distinguir as ocorrências e as chaves de produtor são usadas para distinguir os produtores, em que a chave de produtor para cada produtor é baseada em pelo menos uma chave de ocorrência e chave de método da ocorrência e método daquele produtor.

99. Aparelho, de acordo com a reivindicação 98, em que as o- corrências são ocorrências de uma pluralidade de classes, em que as cha- ves de classe são usadas para distinguir a dita pluralidade de classes e em que a chave de produtor para cada processador também é baseada na cha- ve de classe da ocorrência daquele produtor.

100. Aparelho, de acordo com a reivindicação 98, em que a cha- ve de ocorrência de pelo menos alguns produtores retém uma referência à ocorrência do produtor.

101. Aparelho, de acordo com a reivindicação 89, em que o run- time compreende adicionalmente um módulo de visualização de gráfico produtor para exibir grafi- camente uma representação do gráfico produtor atual.

102. Aparelho, de acordo com a reivindicação 89, em que o run- time compreende adicionalmente: um módulo de interface gráfica com o usuário com Ieiaute de sa- ída do produtor interativo configurável para exibir graficamente saídas e permitir interação com o gráfico produtor.

103. Aparelho, de acordo com a reivindicação 89, em que o dito módulo de geração de gráfico produtor automatizado respem que a novos comandos de produtor e em que o dito módulo de execução de gráfico pro- dutor respem que a comandos de execução.

104. Meio de armazenamento em máquina que fornece código orientado por objeto incluindo: uma pluralidade de definições de classe, cada uma incluindo, um conjunto de um ou mais campos, um conjunto de um ou mais métodos, e uma declaração de dependência de produtor para cada um dos ditos métodos, em que a declaração de dependência de produtor para um dado dentre os ditos métodos é usada no runtime para identificar um conjun- to de zero ou mais produtores, em que um produtor é uma construção ins- tanciável pelo runtime que inclui ao menos uma ocorrência de uma dentre a pluralidade de classes de runtime e um método daquela classe;e em que um primeiro produtor tem uma dependência de produtor contingente, conforme a seguir, um primeiro método de ditos conjuntos de métodos é um método de propriedade, um segundo método de ditos conjuntos de métodos tem uma declaração de dependência de produtor que identifica um produtor de pro- priedade com base no dito método de propriedade e tem código para sele- cionar entre um segundo e terceiro produtor com base na saída do dito pro- dutor de propriedade, e um terceiro método dos ditos conjuntos de métodos tem uma declaração de dependência de produtor que identifica um produtor de de- terminação de dependência com base no dito segundo método, em que o dito primeiro produtor é baseado no dito terceiro método e deve ter uma de- pendência de produtor de qualquer um do segundo e terceiro produtor que o produtor de determinação de dependência estiver retornando no momento.

105. Meio de armazenamento em máquina, de acordo com a reivindicação 104, em que: um quarto produtor tem uma dependência de assinatura de um produtor de gatilho conforme segue, um quarto método de ditos conjuntos de métodos, em que o dito quarto produtor é baseado no dito quarto método, um quinto método de ditos conjuntos de métodos que tem códi- go que indica um conjunto de critérios de assinatura para produtores de gati- lho, em que um produtor de assinatura é baseado no dito quinto método e um sexto método de ditos conjuntos de métodos, em que o dito produtor de gatilho é baseado no dito sexto método e a dita dependência de assinatura é criada porque o dito produtor de gatilho atende ao dito conjunto de critérios de assinatura.

106. Meio de armazenamento em máquina, de acordo com a rei- vindicação 105, em que o dito conjunto de critérios de assinatura é critérios de assinatura absorvente e em que o dito quarto método tem uma declaração de dependência de produtor que identifica o dito produtor de assinatura.

107. Meio de armazenamento em máquina, de acordo com a reivindicação 105, em que o dito conjunto de critérios de assinatura é crité- rios de assinatura adesiva, em que o dito quinto método também inclui códi- go que indica um conjunto de características de assinatura para produtores pais, em que o dito produtor de gatilho atende aos ditos critérios de assinatu- ra adesiva, e em que o dito quarto produtor atende às ditas características de assinatura adesiva e foi instanciado como resultado da dita dependência de assinatura.

108. Meio de armazenamento em máquina, de acordo com a reivindicação 104, em que ao menos uma das ditas declarações de depen- dência de produtor inclui uma dependência de argumento fortemente restrin- gida.

109. Meio de armazenamento em máquina, de acordo com a reivindicação 104, em que ao menos uma das ditas declarações de depen- dência de produtor inclui uma dependência de campo fortemente restringida.

110. Meio de armazenamento em máquina, de acordo com a reivindicação 104, em que: um quarto produtor tem uma dependência de produtor de um quinto produtor, conforme segue um quarto método dos ditos conjuntos de métodos, em que o di- to quarto produtor é baseado no dito quarto método, um quinto método dos ditos conjuntos de métodos que tem códi- go que declara ascendentemente uma dependência de produtor, e um sexto método dos ditos conjuntos de métodos tem uma de- claração de dependência de produtor que identifica um produtor de determi- nação de dependência com base no dito quinto método, em que o dito quinto produtor é baseado no dito sexto método e tem uma dependência de produ- tor com relação ao dito produtor de determinação de dependência que retor- na a dependência do produtor do quarto produtor no quinto produtor.

111. Meio de armazenamento em máquina, de acordo com a reivindicação 104, em que as chaves de método são usadas para distinguir os ditos conjuntos de métodos, as chaves de ocorrência são usadas para distinguir ocorrências da dita pluralidade de definições de classe e as chaves de produtor são usadas para distinguir produtores, em que a chave de pro- dutor para cada produtor é baseada pelo menos na chave de ocorrência e na chave de método da ocorrência e método daquele produtor.

112. Meio de armazenamento em máquina, de acordo com a reivindicação 111, em que as chaves de classe são usadas para distinguir a dita pluralidade de classes e, em que a chave de produtor para cada produ- tor também é baseada na chave de classe da classe da ocorrência daquele produtor.

113. Meio de armazenamento em máquina, de acordo com a reivindicação 111, em que a chave de ocorrência de pelo menos alguns pro- dutores retém uma referência à ocorrência do produtor.

114. Meio de armazenamento em máquina que fornece código orientado por objeto, incluindo: um programa que tem uma pluralidade de definições de classe, cada uma incluindo: um conjunto de um ou mais campos, um conjunto de um ou mais métodos, e uma declaração de dependência de produtor para cada um dos ditos conjuntos de métodos, em que a declaração de dependência de produ- tor para um dado método é usada no runtime para identificar um conjunto de zero ou mais produtores, em que um produtor é uma construção instanciável no runtime que inclui ao menos uma ocorrência de uma dentre a pluralidade de classes no runtime e um método daquela classe; e em que o método de cada um dos produtores é um método de transformação e o programa não inclui código de sequenciamento de invo- cação manual, mas ao invés disso, conta com um runtime para descobrir automaticamente a seqüência para os métodos de transformação das decla- rações de dependência do produtor.

115. Meio de armazenamento em máquina, de acordo com a reivindicação 114, em que peio menos algumas das ditas declarações de dependência de produtor incluem uma dependência de produtor dinâmica, em que as dependências de produtor dinâmicas fazem com que o conjunto de zero ou mais produtores seja dinamicamente selecionado durante o run- time.

116. Meio de armazenamento em máquina, de acordo com a reivindicação 115, em que as dependências de produtor dinâmicas incluem dependências de produtor contingentes, em que as dependências de produ- tor contingentes são dependências de produtores de determinação de de- pendência que são dependentes da saída de um ou mais outros produtores.

117. Meio de armazenamento em máquina, de acordo com a reivindicação 115, em que as dependências de produtor dinâmicas incluem assinaturas, em que as assinaturas identificam critérios por meio dos quais os produtores são comparados para determinar se eles são produtores de gatilho, em que as assinaturas identificam dependências para produtores de gatilho.

118. Meio de armazenamento em máquina, de acordo com a reivindicação 117, em que algumas das ditas assinaturas são assinaturas absorventes, em que as assinaturas absorventes causam a inclusão dinâmi- ca de qualquer produtor de gatilho no conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica.

119. Meio de armazenamento em máquina, de acordo com a reivindicação 117, em que algumas das ditas assinaturas são assinaturas adesivas, em que as assinaturas adesivas também identificam característi- cas para produtores pais e em que as assinaturas adesivas causam, para cada produtor de gatilho localizado, a instanciação de um produtor pai que atende às características identificadas e inclusão dele em um gráfico produ- tor como tendo uma dependência de produtor daquele produtor de gatilho.

120. Meio de armazenamento em máquina, de acordo com a reivindicação 114, em que pelo menos algumas das dependências declara- das pelas declarações de dependência de produtor são designadas como dependências de argumento e dependências de campo, em que as depen- dências de argumento causam o mapeamento de saídas de produtores fi- lhos como parâmetros de entrada em produtores pais e em que as depen- dências de campo indicam usos de campos de ocorrências.

121. Meio de armazenamento em máquina, de acordo com a rei- vindicação 114, em que as chaves de método são usadas para distinguir os métodos, as chaves de ocorrência são usadas para distinguir as ocorrências e as chaves de produtor são usadas para distinguir os produtores, e que a cha- ve de produtor para um dado produtor é baseada pelo menos na chave de ocorrência e na chave de método da ocorrência e método daquele produtor.

122. Meio de armazenamento em máquina, de acordo com a reivindicação 121, em que as chaves de classe são usadas para distinguir a dita pluralidade de classes e em que a chave de produtor para cada produtor também é baseada na chave de classe da classe da ocorrência daquele produtor.

123. Meio de armazenamento em máquina, de acordo com a reivindicação 121, em que a chave de ocorrência de pelo menos alguns pro- dutores retém uma referência à ocorrência do produtor.

124. Meio de armazenamento em máquina, de acordo com a rei- vindicação 114, em que pelo menos algumas das ditas declarações de de- pendência de produtor incluem dependências declaradas ascendentemente.

125. Meio de armazenamento em máquina que tem armazenado nele: um conjunto de uma ou mais ocorrências de um conjunto de uma ou mais classes, em que cada classe inclui métodos e declarações de dependência de produtor para os métodos, em que cada ocorrência do con- junto de ocorrências está associada a todos os métodos de sua classe e em que as declarações de dependência de produtor identificam um runtime um conjunto de uma ou mais dependências entre os produtores; uma estrutura de gráfico de produtor tendo armazenada nela, uma pluralidade de produtores que, cada um, é uma construção instanciada no runtime e que inclui apenas um dos ditos conjuntos de ocor- rências e apenas um dos métodos associados àquela ocorrência, uma pluralidade de ligações que representam um gráfico de múl- tiplos níveis da pluralidade de produtores, em que a pluralidade de ligações representa as dependências entre os produtores no gráfico de produtor iden- tificado pelas declarações de dependência de produtor para os métodos in- cluídos na pluralidade de produtores, uma chave de produtor para cada da dita pluralidade de produto- res, em que cada chave de produtor é baseada em pelo menos uma chave de ocorrência e uma chave de método que identifica um dos ditos conjuntos de ocorrências e um dos métodos associados àquela ocorrência, e uma saída atual de cada produtor da pluralidade de produtores no gráfico de produtor; e uma estrutura de rastreamento de ocorrência tendo armazenada nela uma correspondência entre as chaves de ocorrência e o conjunto de ocorrências.

126. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que a dita estrutura de gráfico de produtor representa sequenciamento apropriado de execução, conforme é indicado pelas decla- rações de dependência de produtor dos métodos dos produtores no gráfico de produtor.

127. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que a estrutura de gráfico de produtor representa as dependências diretas entre entrada e saída dos produtores a partir de um produtor de interesse daqueles dos produtores que são nós de extremidade do gráfico de produtor.

128. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que ao menos algumas das dependências represen- tadas pela estrutura gráfica de produtor são designadas como dependências de argumento e dependências de campo, em que as dependências de ar- gumento fazem com que o runtime mapeie saídas para produtores filhos como parâmetros de entrada em produtores pais, e em que as dependências de campo indicam usos de campos de ocorrências.

129. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que ao menos algumas das dependências represen- tadas pela estrutura de gráfico de produtor são designadas como dependên- cias apenas de sequenciamento, em que as dependências apenas de se- quenciamento requerem saídas que têm que ser fornecidas a partir de pro- dutores filhos para produtores pais ocorrendo através de código no método do produtor filho para gravara saída para um dado mecanismo e código no método do produtor pai para Ier aquela saída a partir do dado mecanismo.

130. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que a estrutura de gráfico de produtor inclui adicio- nalmente: sobrepor modificações de saída do produtor que armazenam, para cada um da dita pluralidade de produtores, uma indicação de se aquele produtor é sobreposto e o valor de saída sobreposto.

131. Meio de armazenamento em máquina, de acordo com a reivindicação 125, tendo armazenado nele: um conjunto de definições de classe gravado no código orienta- do por objeto para o conjunto de classes em que cada uma das declarações de dependência de produtor inclui uma declaração de dependência de pro- dutor localizada adjacente a um dos métodos.

132. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que a chave de ocorrência de pelo menos alguns pro- dutores retém uma referência à ocorrência do produtor.

133. Meio de armazenamento em máquina, de acordo com a reivindicação 125, em que cada chave de produtor também é baseada em uma chave de classe que identifica a classe da ocorrência do produtor.

134. Meio de armazenamento em máquina, de acordo com a reivindicação 133, tendo armazenada nele: uma representação da pluralidade de classes carregadas e exa- minadas durante o runtime, a dita representação incluindo os resultados de exame dos métodos e declarações de dependência de produtor; uma estrutura de rastreamento de classe tendo armazenada ne- Ia uma correspondência entre chaves de classe e a representação do con- junto de classes; e uma estrutura de rastreamento de método que tem armazenada nela uma correspondência entre chaves de método e os resultados de exa- me dos métodos, assim como informações referentes aos resultados do e- xame das declarações de dependência de produtor.

135. Meio de armazenamento em máquina, tendo armazenado nele: um código fonte orientado por objeto, incluindo código de cliente,o dito código de cliente incluindo: um comando de instanciação de produtor que tem uma chave de produtor para um produtor de interesse e que faz com que um runtime para código orientado por objeto descubra, construa e, opcionalmente, solucione automaticamente, um gráfico de produtor atual que começa no produtor de interesse e tem múltiplos níveis de produtores descobertos, em que cada um dos produtores é uma construção instanciável por runtime que inclui ao me- nos uma ocorrência e um método associado àquela ocorrência, em que o runtime instancia automaticamente qualquer dos pro- dutores do gráfico de produtor atual que ainda não tenha sido instanciado, em que as chaves de produtor são usadas para distinguir os produtores, em que as chaves de método são usadas para distinguir os métodos, em que as chaves de ocorrência são usadas para distinguir as ocorrências e em que a chave de produtor para cada produtor é baseada pelo menos na chave de ocorrência e na chave de método da ocorrência e método daquele produtor; executar comandos que fazem com que o runtime para código orientado por objeto execute o gráfico de produtor atual e faça cache de uma saída atual para cada um dos produtores executados no gráfico de produtor atual; e comandos de sobreposição de saída do produtor que têm uma chave de produtor e um valor de sobreposição e que fazem com que o run- time para o código orientado por objeto sobreponha a saída do produtor de- signado pela chave de produtor com o valor de sobreposição.

136. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o cliente de runtime inclui adicionalmente: comandos de desfazimento de saída de produtor que têm a cha- ve de produtor de um dos produtores que foi sobresposto e que fazem com que o código orientado por objeto desfaça a sobreposição da saída daquele produtor.

137. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o comando de instanciação de produtor é um no- vo comando de produtor e em que os comandos de sobreposição de saída do produtor são comandos definidos.

138. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que a causa do comando de instanciação de produtor e comandos de sobreposição de saída do produtor é indireta através de um registro mantido pelo runtime para o código orientado por objeto.

139. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o primeiro dos comandos de execução causa uma execução inicial e cada subsequente dos comandos de execução causa uma execução incrementai.

140. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o cliente de runtime inclui adicionalmente: um comando de instanciação de ocorrência que tem a chave de ocorrência do produtor de interesse e que faz com que o runtime para código orientado por objeto instancie a ocorrência do produtor de interesse.

141. Meio de armazenamento em máquina, de acordo com a rei- vindicação 135, em que cada conjunto de um ou mais dos comandos de so- breposição de saída de produtor é seguido por um dos comandos de execu- ção.

142. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que chaves de classe são usadas para distinguir uma pluralidade de classes das quais as ocorrências são ocorrências, e em que a chave de produtor para cada produtor também é baseada na chave de clas- se da ocorrência do produtor.

143. Meio de armazenamento em máquina, de acordo com a reivindicação 142, em que o comando de instanciação de produtor faz com que o código orientado por objeto instancie o produtor de interesse ao aces- sar a classe do produtor através de uma estrutura de rastreamento de classe usando a chave de classe da chave de produtor do comando de instancia- ção, acessando a ocorrência do produtor através de uma estrutura de ras- treamento de ocorrência usando a chave de ocorrência da chave de produtor do comando de instanciação de produtor e acessando uma declaração de dependência de produtor do método do produtor através de uma estrutura de rastreamento de método usando a chave de método da chave de produ- tor do comando de instanciação de produtor.

144. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que a chave de ocorrência de pelo menos alguns pro- dutores retém uma referência à ocorrência do produtor.

145. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o digo código de cliente inclui adicionalmente: comandos adicionais de instanciação de produtor que fazem com que o runtime para código orientado por objeto descubra, construa e solucione, opcionalmente, de maneira automática, outros gráficos de produtor atuais, em que cada um dos ditos comandos de execução fazem com que o dito runtime para código orientado por objeto execute todos os gráficos de produ- tor atuais.

146. Meio de armazenamento em máquina, de acordo com a reivindicação 135, em que o dito código de fonte orientado por objeto inclui também definições de classe, em que as ditas definições de classe incluem lógica comercial expressa em métodos com declarações de dependência de produtor.

147. Meio de armazenamento em máquina, de acordo com a reivindicação 146, em que as declarações de dependência do produtor defi- nem as amarrações entre os produtores durante a definição das classes que incluem a lógica comercial, ao invés de após ocorrências daquelas classes serem criadas.

148. Método para Ieiaute de saída de produtor, o dito método compreendendo: exibir uma lista que inclui classes, com seus métodos de propri- edades, de produtores em um gráfico de produtor e de saídas daquele pro- dutor, em que o dito gráfico de produtor foi gerado executado automatica- mente com base em um produtor de interesse e declarações de dependên- cia de produtor para métodos de classes, em que um produtor é uma cons- trução instanciável por runtime que inclui pelo menos uma classe, uma ocor- rência daquela classe e um método daquela classe que está associado à- quela ocorrência, em que as declarações de dependência do produtor dos métodos dos produtores no gráfico de produtor identificaram um conjunto de zero ou mais dos outros produtores no gráfico de produtor, em que o dito gráfico de produtor inclui o dito produtor de interesse em uma pluralidade de níveis de outros produtores/; exibir uma planilha tendo células; receber mapeamentos de uma pluralidade dos métodos de pro- priedade exibidos de um conjunto de uma ou mais das classes exibidas para células da planilha; e preencher pelo menos as células dos ditos mapeamentos com as saídas dos métodos de propriedades correspem quentes de um conjunto de uma ou mais ocorrências.

149. Método, de acordo com a reivindicação 148, compreenden- do adicionalmente: receber um valor para uma das células preenchidas automati- camente; sobrepor a saída do produtor cuja saída está preenchendo no momento aquela célula com o dito valor; executar, pelo menos de modo incrementai, o gráfico de produ- tor e atualizar as células do dito mapeamento, conforme necessário.

150. Método, de acordo com a reivindicação 148, em que o dito preenchimento compreende: receber uma indicação de seleção do conjunto de uma ou mais ocorrências.

151. Método, de acordo com a reivindicação 150, em que o dito recebimento de uma indicação de seleção do conjunto de uma ou mais ocor- rências inclui receber pelo menos uma indicação de uma chave de ocorrên- cia de um dos conjuntos de ocorrência.

152. Método, de acordo com a reivindicação 148, em que o dito preenchimento compreende adicionalmente: receber uma indicação de seleção de um filtro de uma pluralida- de de filtros a serem aplicados para selecionar ocorrências que são de pelo menos um primeiro do dito conjunto de classes exibidas, em que cada filtro da dita pluralidade de filtros permite a seleção de uma maneira diferente.

153. Método, de acordo com a reivindicação 152, em que o dito preenchimento compreende adicionalmente: antes do dito recebimento da indicação de seleção de um dentre a pluralidade de filtros, receber um mapeamento da dita primeira classe para uma das células da planilha.

154. Método, de acordo com a reivindicação 153, em que o dito recebimento da indicação da seleção de um filtro dentre a pluralidade de filtros é realizado através da célula da planilha para a qual a dita primeira classe foi mapeada

155. Método, de acordo com a reivindicação 154, em que o dito preenchimento compreende adicionalmente: após o dito recebimento da indicação de seleção de um filtro dentre a pluralidade de filtros, receber uma indicação de seleção de uma das ocorrências da primeira classe usando o filtro selecionado através da célula da planilha para a qual a dita primeira classe foi mapeada.

156. Método, de acordo com a reivindicação 155, em que o dito recebimento da indicação da seleção de uma das ocorrências da primeira classe compreende adicionalmente; receber uma indicação da chave de ocorrência de uma ocorrên- cia do conjunto de ocorrências.

157. Método, de acordo com a reivindicação 148, em que o dito preenchimento compreende adicionalmente: receber uma indicação de uma zona definindo uma tabela, em que a dita tabela inclui uma pluralidade de linhas e colunas de células da planilha; em que o dito recebimento de mapeamentos é realizado em um grupo de células em uma borda da tabela; preencher o grupo de células na borda com as saídas dos méto- dos de propriedade correspem quentes de uma primeira ocorrência de um primeiro conjunto de classes exibidas; e preencher, iterativamente, cada grupo adjacente de células ten- do uma mesma orientação até a borda oposta da tabela ser alcançada com as saídas dos métodos de propriedade correspem quentes de uma outra ocorrência da dita primeira classe.

158. Método, de acordo com a reivindicação 148, em que pelo menos uma das declarações de dependência de produtor inclui uma depen- dência de produtor dinâmica, em que as dependências de produtor dinâmi- cas causam uma seleção dinâmica do conjunto de zero ou mais produtores que a declaração de dependência de produtor identifica durante o runtime.

159. Método, de acordo com a reivindicação 158, em que a de- pendência de produtor dinâmica é uma dependência de produtor contingen- te, em que as dependências de produtor contingentes são dependências de produtores de determinação de dependência que são, elas próprias, depen- dentes da saída de um ou mais outros produtores.

160. Método, de acordo com a reivindicação 158, em que o pro- dutor dinâmico retorna uma assinatura.

161. Método, de acordo com a reivindicação 160, em que a as- sinatura é uma assinatura absorvente que indica critérios de assinatura ab- sorvente para produtores de gatilho.

162. Método, de acordo com a reivindicação 160, em que a as- sinatura é uma assinatura adesiva que indica critérios de assinatura adesiva para produtores de gatilho e características de assinatura adesiva para o produtor pai a ser criado.

163. Método, de acordo com a reivindicação 148, em que pelo menos algumas das declarações de dependência de produtor identificam uma ou mais de uma dependência de argumento e dependência de campo, em que as dependências de argumento causam o mapeamento de saídas de produtores filhos como parâmetros de entrada em produtores pais e em que as dependências de campo indicam usos de campos de ocorrências.

164. Método, de acordo com a reivindicação 148, em que cha- ves de ciasse são usadas para distinguir as ditas classes, em que chaves de método são usadas para distinguir os métodos, as chaves de ocorrência são usadas para distinguir as ocorrências e as chaves de produtor são usadas para distinguir os produtores, em que a chave de produtor para cada produ- tor é baseada em pelo menos uma da chave de classe, chave de ocorrência, chave de método da classe, ocorrência e método daquele produtor.

165. Método, de acordo com a reivindicação 164, em que a cha- ve de ocorrência de pelo menos alguns produtores, retém uma referência à ocorrência do produtor.