BRPI0901507A2 - comparador de aplicativo de interface gráfica de usuário - Google Patents

Abstract

COMPARADOR DE APLICATIVO DE INTERFACE GRáFICA DE USUáRIO. A presente invenção refere-se a um comparador de aplicativo de interface gráfica de usuário (GUI) ajuda aos projetistas de aplicativo a criarem aplicativos de interface gráfica de usuário (GAPs) sem erros. O comparador encontra diferenças nos elementos de GUI usados para a composição de uma interface entre uma versão de GAP atual e uma versão de GAP subsequente. Um benefício é que um escritor de script de teste pode entender melhor como o GAP evoluiu, de modo a escrever um script de teste melhor. Um outro benefício é que a saída de comparador pode ser analisada por sistemas de processamento subsequentes para uma análise automatizada de scripts de teste.

Description

Relatório Descritivo da Patente de Invenção para "COMPARA-DOR DE APLICATIVO DE INTERFACE GRÁFICA DE USUÁRIO".

ANTECEDENTES DA INVENÇÃO

1. Referência Cruzada a Pedidos Relacionados

Este pedido está relacionado aos pedidos a seguir, todos depo-sitados no mesmo dia e todos incorporados inteiramente aqui como referên-cia:

Número de protocolo legal 10022-1162: Número de Série de Pe-dido de Patente U.S. 12/038.665, depositado em 27 de fevereiro 2008;

Número de protocolo legal 10022-1185: Número de Série de Pe-dido de Patente U.S. 12/038.672, depositado em 27 de fevereiro 2008;

Número de protocolo legal 10022-1186: Número de Série de Pe-dido de Patente U.S. 12/038.676, depositado em 27 de fevereiro 2008;

Número de protocolo legal 10022-1187: Número de Série de Pe-dido de Patente U.S. 12/038.661, depositado em 27 de fevereiro 2008;

Número de protocolo legal 10022-1188: Número de Série de Pe-dido de Patente U.S. 12/038.658, depositado em 27 de fevereiro 2008; e

Número de protocolo legal 10022-1189: Número de Série de Pe-dido de Patente U.S. 12/038.675, depositado em 27 de fevereiro 2008.

2. Campo Técnico

Esta exposição refere-se à análise e à geração de scripts de tes-te para se testarem aplicativos de interface gráfica de usuário e, em particu-lar, refere-se à transformação de um script de teste anterior para uso comuma nova versão de aplicativo.

3. Técnica Relacionada

O passo assíduo da tecnologia avançando de origem a aplicati-vos de software de computador complexos para ajudarem na automação dequase todo aspecto da existência do dia a dia. Os aplicativos de hoje em diaexistem para ajudarem com a redação de romances, para preenchimento derestituição de imposto de renda, para análise de tendências históricas emnomes de bebês. Um recurso quase ubíquo destes aplicativos é que elesempregam interfaces gráficas de usuário (GUIs). Um outro aspecto quaseubíquo é que os aplicativos de GUI (GAPs) requerem testes completos antesda liberação.

Não obstante, no passo, era mais fácil implementar a GUI para oaplicativo do que testar completamente o GAP. Para GAPs de qualquercomplexidade significativa, as permutações e combinações de elementos deGUI dão margem a um campo enorme de comandos potenciais e seqüên-cias de comando que poderiam ter bugs de qualquer severidade, de umafalha insignificante a uma crítica. A exacerbação do problema é que os de-senvolvedores de aplicativo estão sob pressão para continuamente adiciona-rem novos recursos, atualizarem a GUI e liberarem novas versões de aplica-tivo. Como resultado, mesmo se um script passado de uma versão anteriorde um GAP fosse adequado, raramente é o caso de o script de teste originalpoder testar adequadamente o aplicativo revisado subsequente.

Testar manualmente GAPs de empresa em larga escala é tedio-so, propenso a erros e trabalhoso. Os GAPs não triviais contêm centenas detelas de GUI que, por sua vez, contêm milhares de objetos de GUI. De modoa se automatizarem os testes de GAPs, os engenheiros de teste escrevemprogramas usando linguagens de script (por exemplo, JavaScript e VBS-cript), e estes scripts de teste comandam os GAPs através de estados dife-rentes ao imitarem usuários que interagem com estes GAPs pela realizaçãode ações nos seus objetos de GUI. Freqüentemente, os scripts de teste si-mulam usuários de GAPs e suas declarações acessam e manipulam objetosde GUI destes GAPs. Por exemplo, a declaração:

VbWindow("Login").VbEdit("b(tAgentsName").Set"ShawnMlocaliza uma janela cujo título descritivo é Login e que é criada por um con-trole baseado em Visual Basic, então, localiza uma caixa de texto cujo nomeé txtAgentsName que é um objeto de GUI cuja origem é a janela de login. Aochamar o método Set com o parâmetro "Shawn", o valor da caixa de texto éregulado para "Shawn".

Ferramentas comerciais tais como QTP e Rational Robot ajudamna geração de scripts de teste pelo acompanhamento do apontamento deum cursor em objetos de GUI e realizando ações desejadas. Estas ferramen-tas geram um código de script que pode reexecutar ações de usuário captu-radas. O código gerado serve como um esqueleto para a criação de scriptspara a automação de testes de script. Os engenheiros de teste adicionamum código aos scripts gerados de modo que estes scripts possam ser reexe-cutados usando-se valores de entrada diferentes, desse modo se exercitan-do a funcionalidade do GAP.

A expansão de scripts de teste com um código escrito manual-mente para automação de testes torna o script de teste mais complexo, difí-cil de entender, manter e evoluir. Embora seja conhecido de antemão que osscripts de teste acessem e manipulem elementos de GUI, não é claro comodetectar as operações no momento da compilação que levem a erros detempo de execução. O uso de chamadas de API exportadas por plataformasde teste permanece um modo primário de acesso e manipulação de objetosde GUI de GAPs, e estas chamadas de API levam a vários erros de tempode execução nos scripts de teste. Por exemplo, o pessoal de teste pode usaras chamadas de API de plataforma forma incorreta no código fonte de scriptde teste, desse modo acessando elementos de GUI que eles não pretendi-am acessar.

É um desafio técnico difícil checar scripts de teste quanto a po-tenciais falhas causadas por chamadas de API de terceiros que levam a tes-tes incorretos e erros de tempo de execução nos scripts de teste. Além dis-so, há problemas fundamentais com o uso de chamadas de API para acessoe manipulação de objetos de GUI. Em primeiro lugar, as chamadas de APIassumem nomes e valores de propriedade de objetos de GUI como variáveisde parâmetro de entrada de string. Os valores destes parâmetros de entradafreqüentemente são conhecidos apenas no tempo de execução, tornandoimpossível aplicar algoritmos de checagem bons. Em segundo lugar, as pla-taformas de teste exportam dúzias de chamadas de API diferentes, e a altacomplexidade destas chamadas de API torna difícil para os programadoresentenderem as chamadas de API a usar e como combiná-las para acesso emanipulação de objetos de GUI. Estes problemas levam a uma ampla faixade bugs nos scripts de teste, muitos dos quais sendo difíceis de detectar du-rante a inspeção do código fonte de script de teste.

Um problema adicional surge porque as especificações de exi-gência de aplicativo incluem conceitos de nível alto que descrevem GAPs,especificamente, seus objetos de GUI. Infelizmente, o rastreio de objetos deGUI de GAPs para estes conceitos de nível alto é um problema difícil porqueos programadores não documentam estes rastreios. Assim sendo, quando opessoal de teste cria GAPs, eles gastam um tempo considerável para enten-derem como usar estes GAPs pela leitura de documentação e falando comespecialistas no assunto. Este conhecimento crucial freqüentemente é per-dido após o pessoal de teste ser reatribuído a outras tarefas ou deixarem acompanhia.

Um dos benefícios percebidos de abordagens existentes para acriação de scripts de teste é que uma checagem de tipo não é requerida,uma vez que o código de script é gerado diretamente a partir de GUIs. Porexemplo, dados certos objetos de GUI em um GAP, uma ferramenta de testepode produzir declarações correspondentes que navegam para aqueles ob-jetos usando chamadas de API com parâmetros de string descrevendo suaspropriedades. Contudo, este benefício percebido de fato dá margem a desa-fios técnicos difíceis, devido a inconsistências semânticas entre o script deteste e o GAP. Suponha, por exemplo, que durante a fase de manutenção aGUI do GAP mudasse. O intérprete de script não está ciente da mudança erodaria o script gerado sem a produção de quaisquer avisos de tempo decompilação. Contudo, o script resultante falharia no tempo de execução ouproduziria resultados de teste inconsistentes porque seu código tentaria a-cessar objetos de GUI que mudaram ou não existem mais.

Portanto, existe uma necessidade de uma arquitetura de gera-ção de script de teste com análise de suporte e lógica de avaliação que sedirija aos problemas citados acima e a outros encontrados previamente.

SUMÁRIO

Uma arquitetura de transformação de script de teste gera scriptsde teste acurados para aplicativos com interfaces gráficas de usuário quemudam ao longo do tempo. Conforme os aplicativos mudam, scripts de testeprévios são tornados não praticáveis. A arquitetura facilita a geração auto-mática de novos scripts de teste para se testarem de forma confiável ver-sões de aplicativo subsequentes e pode reduzir grandemente o tempo, ocusto e as despesas de recurso necessárias para se chegar a novos scriptsde teste.

A arquitetura de transformação de script de teste ("arquitetura")pode incluir um modelo de tipo de interface gráfica de usuário (GUI) e umalógica de construtor de modelo de GUI. A lógica de construtor de modelo deGUI aceita como entrada o modelo de tipo de GUI, uma versão de GAP atuale uma versão de GAP subsequente. A lógica de construtor de modelo deGUI gera como uma saída um modelo de GUI de GAP atual e um modelo deGUI de GAP subsequente.

Além disso, a arquitetura inclui uma lógica de comparador deGUI. A lógica de comparador de GUI aceita como entrada o modelo de GUIde GAP atual, o modelo de GUI de GAP subsequente e gera como saída ummodelo de diferença de GUI. O modelo de diferença de GUI inclui entradasde diferença de elemento de GUI que identificam um elemento de GUI espe-cífico que combina entre a versão de GAP atual e a versão de GAP subse-quente, mas que difere no caráter entre a versão de GAP atual e a versão deGAP subsequente. A arquitetura ainda inclui um analisador de script. Combase em uma representação de árvore de sintaxe abstrata de um script deteste atual, o analisador de script gera um guia de mudança, um script deteste transformado ou ambos. O guia de mudança pode incluir, por exemplo,uma informação de transformação de script para transformação do script deteste atual para uso em relação à versão de GAP subsequente. O script deteste transformado (para uso em relação à versão de GAP subsequente)pode incluir, por exemplo, entradas de script modificadas geradas a partirdas entradas de script de teste atuais no script de teste atual.

Outros sistemas, métodos, recursos e vantagens serão ou setornarão evidentes para alguém versado na técnica, mediante um examedas figuras a seguir e da descrição detalhada. Todos esses sistemas, méto-dos, recursos e vantagens adicionais estão incluídos nesta descrição, estãono escopo do assunto reivindicado e são protegidos pelas reivindicações aseguir.

BREVE DESCRIÇÃO DOS DESENHOS

O sistema pode ser mais bem entendido com referência aos de-senhos e à descrição a seguir. Os elementos nas figuras não estão necessa-riamente em escala, a ênfase sendo posta, ao invés disso, na ilustração dosprincípios do sistema. Nos desenhos, números referenciados iguais desig-nam partes correspondentes por todas as diferentes vistas.

A Figura 1 mostra uma arquitetura de transformação de script deteste.

A Figura 2 mostra um fluxograma de processamento realizadopela arquitetura de transformação de script de teste.

A Figura 3 mostra um sistema de tipificação de elemento deGUI.

A Figura 4 mostra um mapeamento de tipo de elemento de GUI.

A Figura 5 mostra uma interface de usuário de mapeamento detipo de elemento de GUI.

A Figura 6 mostra um fluxograma para uma lógica de tipificaçãode elemento de GUI.

A Figura 7 mostra um sistema de mapeamento de elemento deGUI.

A Figura 8 mostra um mapeamento de versão de elemento deGUI.

A Figura 9 mostra uma interface de usuário de mapeamento deversão de elemento de GUI.

A Figura 10 mostra um fluxograma para uma lógica de mapea-mento de versão de elemento de GUI.

A Figura 11 mostra um sistema de tipificação e de mapeamentode elemento de GUI.

A Figura 12 mostra uma arquitetura de ferramenta de evoluçãode metadados.

A Figura 13 mostra uma arquitetura de depósito de metadados.A Figura 14 mostra os exemplos de mensagens de notação.

A Figura 15 mostra um fluxograma de processamento de meta-dados.

A Figura 16 mostra um fluxograma de processamento de tipo.

A Figura 17 mostra uma primeira parte de um fluxograma deprocessamento de mapeamento.

A Figura 18 mostra uma segunda parte de um fluxograma deprocessamento de mapeamento.

A Figura 19 mostra um fluxograma de processamento de nota-ção.

A Figura 20 mostra um fluxograma de processamento de migra-ção de metadados.

A Figura 21 mostra um fluxograma de processamento de migra-ção de metadados.

A Figura 22 mostra um fluxograma de processamento de migra-ção de metadados.

A Figura 23 mostra um sistema de comparador de GAP.

A Figura 24 mostra uma porção de um modelo de GUI de GAPatual que prove uma representação de GAP como um modelo para análise.

A Figura 25 mostra uma porção de um modelo de GUI de GAPsubsequente que prove uma representação de GAP como um modelo paraanálise.

A Figura 26 mostra uma porção de um modelo de diferença deGUI.

A Figura 27 mostra um fluxograma para uma lógica de construtorde modelo de GUI.

A Figura 28 mostra um fluxograma para uma lógica de compara-ção de GAP.

A Figura 29 mostra um visor e uma interface de limite de compa-radordeGUI.

A Figura 30 mostra um destaque de elemento de GUI em res-posta a um cursor deslizante de limite de comparador.A Figura 31 mostra um fluxograma para uma lógica de visualizaçao.

A Figura 32 mostra um exemplo de propriedades de bissimulaçao.

A Figura 33 mostra uma GUI de uma versão de GAP atual.

A Figura 34 mostra uma GUI de uma versão de GAP subsequente.

A Figura 35 ilustra uma comparação de GAP atual e subsequente.

A Figura 36 ilustra uma entrada de diferença de elemento deGUI.

A Figura 37 mostra um script de teste atual.

A Figura 38 mostra uma representação de script de teste atual.

A Figura 39 mostra um sistema analisador de script de exemplo.

A Figura 40 mostra um fluxograma para a recuperação de propriedades de uma entrada de objeto de GUI a partir de um depósito de objeto (OR).

A Figura 41 mostra um fluxograma para a identificação de umaentrada de diferença de GUI correspondente a uma entrada de objeto de GUI.

A Figura 42 mostra um script de teste transformado.

A Figura 43 mostra um guia de mudança.

A Figura 44 mostra um fluxograma para extração de declaraçõesde script de teste transformado.

A Figura 45 ilustra uma outra entrada de diferença de elementode GUI.

A Figura 46 mostra uma outra entrada de diferença de elementode GUI de exemplo.

A Figura 47 ilustra caminhos de navegação a partir de uma fontepara um objeto de destino.

A Figura 48 mostra um fluxograma para a extração de um espe-cificador de mudança de GAP.A Figura 49 mostra um analisador de transformação de script deteste com arquitetura de motor de custo econômico.

A Figura 50 mostra um script de teste atual.

A Figura 51 mostra uma representação de script de teste atual.

A Figura 52 mostra um sistema de motor de custo econômico deexemplo.

A Figura 53 mostra um fluxograma para a identificação de umaentrada de diferença de GUI correspondente a uma entrada de objeto deGUI.

A Figura 54 mostra um script de teste transformado.

A Figura 55 mostra um fluxograma para a geração de um espe-cificador de mudança de GAP sintético.

A Figura 56 mostra um fluxograma para a extração de um relató-rio de custo de transformação de script de teste.

DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS

A Figura 1 mostra uma arquitetura de transformação de script deteste 100 ("arquitetura 100"). A arquitetura 100 inclui vários sistemas, inclu-indo um sistema de tipificação e de mapeamento de elemento de GUI 102,um sistema de migração e de depósito de metadados 104 e um sistema decomparador de aplicativo de GUI (GAP) 106. A arquitetura 100 também in-clui um sistema de análise de script de teste 108 e um sistema de análiseeconômica de script de teste 110.

O sistema de tipificação e de mapeamento de elemento de GUI102 ("sistema 102") facilita a aplicação de um modelo de tipo formal a ele-mentos de GUI em GAPs, bem como o estabelecimento de relações entreelementos de GUI de uma versão de um GAP para uma outra. O sistema102 inclui um processador 112, uma memória 114 e um depósito de dadosde elemento de GUI ("depósito") 116. O sistema 102 troca informação comos outros sistemas 104, 106, 108 e 110 na arquitetura 100 através da lógicade comunicação 118.

A memória 114 mantém a lógica de tipificação e de mapeamentode GUI 120 e um modelo de tipo de GUI de referência 122. O depósito 116armazena mapeamentos de elemento de GUI de aplicativo de interface grá-fica de usuário (GAP) ("mapeamentos") 124. O depósito 116 também arma-zena um modelo de tipo de GUI de versão de GAP atual 126 e um modelode tipo de GUI de versão de GAP subsequente 128. O sistema 102 comuni-ca mensagens de especificação de tipo de elemento de GUI e mensagensde especificação de mapeamento de elemento de GUI para o sistema demigração e de depósito de metadados 104 ("sistema 104").

O sistema 104 facilita a perpetuação de metadados úteis paraGAPs, particularmente conforme os GAPs evoluírem entre versões. O siste-ma 104 inclui um processador 129, uma memória 130 que mantém uma ló-gica de processamento de metadados 132 e um sistema de gerenciamentode banco de dados 134 e uma lógica de comunicação 136. O sistema 104também inclui um depósito de metadados 138. O depósito de metadados138 mantém metadados de elemento de GUI 140, tais como identificadoresde elemento de GUI 142, notações de elemento de GUI 144, tipos de ele-mento de GUI 146 e mapeamentos de elemento de GUI 148. O sistema 104pode comunicar os metadados de elemento de GUI 140 para os outros sis-temas 102, 106, 108 e 110 para ajudar aos outros sistemas 102, 106, 108 e110 na execução de sua lógica.

O sistema comparador de GAP 106 ("o sistema 106") analisauma versão de GAP atual 150 e uma versão de GAP subsequente 152 paradeterminar diferenças de elemento de GUI entre as versões 150 e 152. Paraessa finalidade, o sistema 106 pode incluir uma lógica de construtor de mo-delo de GUI 154 que aceita como entrada a versão de GAP atual 150 e aversão de GAP subsequente 152. A lógica de construtor de modelo de GUI154 gera um modelo de elemento de GUI 156 da versão de GAP atual 150 eum modelo de elemento de GUI 158 da versão de GAP subsequente 152.Os modelos 156 e 158 podem ser modelos de árvore ou outros tipos de re-presentações.

Um comparador de GUI 160 processa as representações 156 e158. Um modelo de diferença de GUI 162 resulta. O modelo de diferença deGUI 162 inclui entradas de diferença de elemento de GUI que identificam umelemento de GUI específico que combina entre a versão de GAP atual e aversão de GAP subsequente, mas que difere no caráter entre a versão deGAP atual e a versão de GAP subsequente. Por exemplo, uma entrada dediferença pode identificar que uma caixa de texto na versão de GAP atualcombina com uma lista suspensa na versão de GAP subsequente, e podenotar as características de elemento de GUI diferentes entre as duas ver-sões.

O sistema de análise de script de teste 108 ("sistema 108") pro-ve um analisador de transformação de script de teste com um motor de guiade mudança. Em particular, o sistema 108 começa com um script de testeatual 164 e inicia uma execução de um analisador gramatical de script 166para a obtenção de uma representação de árvore de sintaxe abstrata 168("AST 168") do script de teste atual 164. O script de teste atual 164 pode seradequado para se testar qualquer quantidade de funcionalidade na versãode GAP atual 150. O sistema 108 ajuda a transformar o script de teste atual164 em um script de teste transformado adequado para se testar qualquerquantidade de funcionalidade na versão de GAP subsequente 152.

O analisador de script 170 aceita a AST 168, o modelo de dife-rença de GUI 162 e os metadados de elemento de GUI 140 através da lógi-ca de comunicação 190. A lógica de consulta de depósito de objeto 172 re-cupera dados de objeto a partir do depósito de objeto 174 como um auxíliona análise do modelo de diferença de GUI 162. Como resultado desta análi-se, o analisador de script 170 gera um script de teste transformado 178, umguia de mudança 180 ou ambos. A análise pode levar em consideração umdepósito de mensagem de guia de mudança 192 e regras de mudança descript de elemento de GUI 194. Um aspecto adicional do sistema 108 é omotor de satisfação de restrição 188. Em conjunto com a informação de tipode elemento de GUI obtida a partir dos sistemas 104 e 104, o motor de satis-fação de restrição determina se as declarações de script são compatíveiscom o tipo de elemento de GUI atribuído a qualquer dado elemento de GUI.

O sistema de análise econômica de script de teste 110 ("sistema110") prove um analisador de transformação de script de teste com um mo-tor de custo econômico. O sistema 10 inclui um motor econômico 182 queconsulta modelos econômicos 176 para a geração de relatórios de custos186. Os modelos econômicos 176 podem ser modelos econômicos predefi-nidos de relações de custo de transformação de script de teste. Os relatóriosde custos 186 podem incluir uma informação de custo de transformação descript de teste, por exemplo, o custo estimado para transformação do scriptde teste atual 164 no script de teste transformado 178. Os relatórios de cus-tos 186 podem ser baseados em uma análise do guia de mudança 180, es-pecificamente de especificadores de mudança de GAP de entrada 184, ouuma outra informação.

A Figura 2 mostra um fluxograma 200 de processamento reali-zado pela arquitetura de transformação de script de teste 100. O sistema102 gera mensagens de especificação de mapeamento de elemento de GUIque podem incluir um mapeamento de versão de elemento de GUI, e men-sagens de especificação de tipo que podem incluir identificadores de tipo deelemento de GUI (202). O sistema 102 comunica as mensagens para o sis-tema 104 (204), o qual recebe as mensagens. O sistema 104 em respostamantém metadados de elemento de GUI no depósito de metadados 138(206).

O sistema 106 inicia uma execução de lógica de comparador deGUI (208). A lógica de comparador de GUI 160 aceita como entrada um mo-delo de elemento de GUI 156 para a versão de GAP atual 150 e um modelode elemento de GUI 158 para a versão de GAP subsequente 152 (210). Alógica de comparador de GUI 160 ainda pode aceitar como entrada mapea-mentos de elemento de GUI a partir do sistema 102 ou 104. A lógica decomparador de GUI 160 produz como saída um modelo de diferença de GUI162 que inclui entradas de diferença de elemento de GUI que identificamelementos de GUI específicos que combinam entre a versão de GAP atual150 e a versão de GAP subsequente 152, mas diferem no caráter entre aversão de GAP atual 150 e a versão de GAP subsequente 152 (212).

O sistema de análise de script de teste 108 inicia a execução deum analisador de script 170 (214). O analisador de script 170 aceita comoentrada o modelo de diferença de GUI 162 e a AST 168 do script de testeatual 164. O analisador de script 170 pode gerar um guia de mudança 180que inclui uma informação de transformação de script para transformação doscript de teste atual 164 para uso em relação à versão de GAP subsequente152 (216). De forma adicional ou alternativa, o analisador de script 170 podegerar um script de teste transformado 178 para uso em relação à versão deGAP subsequente 152 (218). O script de teste transformado 178 inclui en-tradas de script de teste transformado geradas a partir de entradas de scriptde teste atual no script de teste atual.

Além disso, o sistema 110 pode iniciar uma execução de um mo-tor econômico 182 operável para analisar o guia de mudança 180 (220). Osistema 100 leva em consideração as relações de custo de transformaçãode script de teste definidas nos modelos econômicos 176. O resultado é umrelatório de custo 186 compreendendo uma informação de custo de trans-formação de script de teste (222).

A Figura 1 mostra um sistema de tipificação e de mapeamentode elemento de interface gráfica de usuário (GUI) ("sistema") 102. O sistema102 inclui um processador 112, uma memória 114 e um depósito de dadosde elemento de GUI ("depósito") 116. O sistema 102 troca informação comos outros sistemas através da lógica de comunicação 118. A lógica de co-municação 118 pode ser uma interface com fio/ sem fio, um mecanismo decomunicação interprocesso, uma memória compartilhada, uma interface deserviços da web, ou quaisquer outros tipos de interface de comunicação.

A memória 114 mantém a lógica de tipificação e de mapeamentode GUI 120 e um modelo de tipo de GUI de referência 122. Conforme expli-cado em maiores detalhes abaixo, a lógica de tipificação e de mapeamentode GUI 120 ajuda o projetista de GAP a especificar tipos de elemento deGUI para elementos de GUI individuais de um GAP. A lógica de tipificação ede mapeamento de GUI 120 também ajuda o projetista de GAP a definirlinks para elementos de GUI em uma versão de GAP atual para elementosde GUI em uma versão de GAP subsequente. Os tipos e a informação demapeamento podem ser providos para outros sistemas de análise de GAP,tais como sistemas de análise de script de teste e depósitos de metadados,através da lógica de comunicação 118.

O sistema 102 pode operar em qualquer elemento de GUI emparticular. Os exemplos de elementos de GUI incluem caixas de texto, me-nus, itens de menu, botões de rádio, caixas de verificação, e botões de co-mando. Outros exemplos incluem caixas de lista, caixas de combinação, bo-tões de alternar, botões de girar, barras de rolagem, rótulos, barras de fer-ramenta, widgets, imagens, janelas, calendário e tab strips. O modelo de tipode GUI de referência 122 pode estabelecer um conjunto formalizado de no-mes de tipo (por exemplo, identificadores) e qualidades comuns a elementosde GUI individuais que distinguem os elementos de GUI do mesmo tipo co-mo membros de uma classe identificável. O modelo de tipo de GUI 122, emconjunto com a especificação de tipos para elementos de GUI individuaisajuda a prover uma técnica sintática tratável para o estabelecimento que aGUI não exibe certos comportamentos (por exemplo, armazenamento de umcaractere alfabético em uma caixa de texto significando manter um númerode seguridade social), em oposição a uma anotação ad hoc de forma livre deelementos de GUI.

O depósito 116 armazena mapeamentos de elemento de GUI deaplicativo de interface gráfica de usuário (GAP) ("mapeamentos") 124. O de-pósito 116 também armazena um modelo de tipo de GUI de versão de GAPatual 126 e um modelo de tipo de GUI de versão de GAP subsequente 128.O sistema 102 pode preparar os mapeamentos 124 em resposta a uma en-trada de operador que cria links de elementos de GUI a partir de qualquerversão de GAP atual para qualquer versão de GAP subsequente. Assim, porexemplo, se uma caixa de texto mudar para uma lista suspensa, o operadorpoderá documentar a mudança ao criar explicitamente um link dos dois ele-mentos de GUI em conjunto. O sistema 102 em resposta prepara um mape-amento de versão de elemento e armazena o mapeamento de versão deelemento no depósito 116.

De modo similar, o sistema 102 pode construir os modelos detipo 126 e 128 a partir de atribuições específicas de operador de tipos demeio de gancho para elementos de GUI específicos na versão de GAP atuale na versão de GAP subsequente. Para essa finalidade, o sistema 102 podealertar o operador para uma seleção a partir de uma lista de tipo de elemen-to de GUI estabelecida pelo modelo de tipo de GUI de referência 122. Cadamodelo de tipo 126 e 128 pode incluir especificadores de tipo de elementode GUI para um ou mais elementos no GAP atual e no GAP subsequente. Osistema 102 pode interagir com o operador usando o visor 121 e tambémpode aceitar uma linha de comando, um script, um arquivo de batch e outrostipos de entrada.

A Figura 3 mostra uma implementação do sistema 102. A Figura3 mostra que a lógica de comunicação 118 pode trocar uma informação como depósito de metadados 202 através de uma conexão de uma ou mais re-des 304. Como exemplos, o sistema 102 pode comunicar mensagens deespecificação de tipo de elemento de GUI e mensagens de especificação demapeamento de elemento de GUI para o depósito de metadados 202.

Um detalhe adicional do modelo de tipo de GUI de referência122 é mostrado na Figura 3. O modelo de tipo de GUI de referência 122 in-clui entradas de modelo de tipo de GUI (por exemplo, as entradas de modelode tipo de GUI 306 e 308). As entradas de modelo de tipo de GUI definemum sistema de tipo para uma GUI, e podem prover um conjunto finito de i-dentificadores pré-estabelecidos para etiquetagem de elementos de GUI.Cada entrada de modelo de tipo de GUI pode especificar um especificadorde tipo de elemento de GUI 310, restrições de modificação de elemento deGUI 312 e restrições de conteúdo de elemento de GUI 314. Em outras im-plementações, o modelo de tipo de GUI de referência 122 pode incluir umainformação adicional, diferente ou menor. O especificador de tipo de elemen-to de GUI estabelece um identificador (por exemplo, uma string única ou umnúmero) que pode ser atribuído a um elemento de GUI para especificaçãode um tipo de elemento de GUI para o elemento de GUI. As restrições demodificação de elemento de GUI 312 especificam como e se um elementode GUI do tipo especificado pode ser modificado. De modo similar, as restri-ções de conteúdo e de formatação de elemento de GUI 314 especificam queconteúdo um elemento de GUI do tipo especificado pode manter, e como oconteúdo ou o elemento de GUI em si pode ser formatado. As restrições 312e 314 podem ser expressas de muitas formas, tal como por regras que ditamo comportamento desejado ou restrições em um elemento de GUI de umdado tipo.

Os exemplos de tipos de elemento de GUI são dados abaixo na Tabela 1.

Tabela 1

<table>table see original document page 17</column></row><table>por exemplo, a um elemento de GUI (por exemplo, uma caixa de texto) emum GAP que é pretendido para entrada de números de seguridade social. Otipo SSNEntryBox não impõe restrições nas modificações que podem serrealizadas na caixa de texto. Contudo, o tipo SSNEntryBox restringe o conteúdo da caixa de texto para nove dígitos ou 3 dígitos seguidos por um traço,seguido por 2 dígitos, seguidos por um traço, seguido por 4 dígitos. O tipoSSNDisplayBox especifica restrições similares, mas também torna o elemen-to de GUI apenas de leitura.

O tipo StaticWindowLabel prove um rótulo de apenas leitura paraseu elemento de GUI anexado. O rótulo pode ter entre 0 e 50 caracteres al-fanuméricos. Devido ao fato de StaticWindowLabel ser do tipo apenas deleitura de elemento de GUI, o rótulo não pode ser mudado.

O tipo 3DButton limita as cores de primeiro plano que podem serreguladas para o elemento de GUI entre FStart e FEnd. De modo similar, otipo 3DButton limita as cores de fundo que podem ser reguladas para o ele-mento de GUI entre BStart e BEnd. A HelpTextEntryBox restringe a posiçãoX e Y do elemento de GUI anexado, e ainda restringe a fonte dimensionadausada para o texto no elemento de GUI entre 10 e 16 pontos. O tipo Menu-Widget pode ser aplicado a um elemento de botão gráfico, por exemplo, parao estabelecimento do elemento como um widget para uma barra de menu. Otipo MenuWidget fixa a localização X e Y do elemento de GUI, e ainda esta-belece um tamanho mínimo de SMin e um tamanho máximo de SMax. A US-StateTextBox limita o conteúdo de um elemento de GUI a apenas os nomesdos Estados dos Estados Unidos (por exemplo, "Alaska, Maine, Nevada,...").

O sistema 102 pode implementar qualquer modelo de tipo deGUI formal 122 útil para ajudar um projetista a criar um GAP. O modelo detipo de GUI pode variar, dependendo do tipo de GAP sendo projetado, e osistema pode escolher a partir de múltiplos modelos de tipo de GUI 122 parao GAP sob análise, ou pode aceitar uma entrada de operador para selecio-nar qual modelo de tipo de GUI é aplicável. Por exemplo, o operador podeespecificar um modelo de tipo de GUI de assistência médica, quando daconstrução de um GAP de farmácia, e especificar um modelo de tipo de GUIde videogame, quando construindo uma interface de usuário para um jogoon-line de RPG. O modelo de tipo de GUI de assistência médica pode incluirtipos de elemento úteis para a construção de um GAP relacionado à assis-tência médica, tal como o tipo SSNEntryBox, enquanto o modelo de tipo deGUI de videogame pode incluir tipos de elemento úteis para a construção dainterface de usuário, tal como o 3DButton.

A Figura 3 também mostra que o sistema 102 inclui a lógica detipificação de elemento de GUI ("lógica de mapeamento de tipo") 316 resi-dente na memória 114. A lógica de mapeamento de tipo 316 pode ser incluí-da na lógica de tipificação e de mapeamento de GUI 120, mas também podeser um módulo separado ou implementada de outras formas. Conforme des-crito em detalhes abaixo, a lógica de mapeamento de tipo 316 pode incluiruma lógica de seleção de elemento 318, uma lógica de recuperação de tipo320 e uma lógica de seleção de tipo 326. A lógica de tipificação 316 aindapode incluir uma lógica de associação de tipo 324 e uma lógica de criaçãode mensagem 326. A lógica de mapeamento de tipo 316 gera mapeamentosde tipo de elemento de GUI (por exemplo, o mapeamento de tipo 328).

Voltando-nos brevemente para a Figura 4, um exemplo de ummapeamento de tipo de elemento de GUI 400 é mostrado. O mapeamentode tipo 400 inclui um alias de GAP 402, um identificador de elemento de GUI404, e um identificador de tipo de GUI 406. Adicionalmente, menos camposou diferentes podem ser incluídos no mapeamento de tipo 400.

O alias de GAP 402 especifica um identificador para o GAP, oqual inclui o elemento de GUI ao qual um tipo está sendo aplicado. O aliasde GAP 402 pode ser um identificador único que distingue entre GAPs, inclu-indo uma versão de GAP atual e uma versão subsequente do mesmo GAP.O identificador de elemento de GUI 404 prove um identificador único para oelemento de GUI o qual está sendo tipificado. O identificador de tipo de GUI406 especifica o tipo de elemento de GUI sendo atribuído ao elemento deGUI (por exemplo, SSNEntryBox).

A Figura 4 também mostra dois exemplos de mapeamentos detipo de GUI 408 e 410. O mapeamento de tipo 408 é um mapeamento paraum elemento de GUI de Window. O alias de GAP 412 é "University Direc-toryO", significando a versão atual de um GAP de diretório de universidade.O elemento de GUI sendo tipificado tem o identificador de elemento único414 "0x30fb0" notado pelo identificador de HWND e estabelecido, por exem-plo, por uma interface de camada de acessibilidade, conforme descrito abai-xo.

O identificador de tipo de GUI 416 para o elemento de GUI Win-dow é "US-StateTextBox". O mapeamento de tipo 410 é um mapeamentopara um elemento de GUI de Menu Item. O alias de GAP 418 é "UniversityDirectoryl", significando a versão subsequente do GAP de diretório de uni-versidade. O elemento de GUI sendo tipificado tem o identificador de ele-mento único 420 "OpenFile" conforme especificado no campo Name. O iden-tificador de tipo de GUI 422 para o elemento de GUI Window é "FileOpen".

A Figura 4 também mostra um exemplo de uma mensagem deespecificação de tipo de elemento de GUI 424. A mensagem de especifica-ção de tipo de elemento de GUI 424 pode incluir um cabeçalho de mensa-gem de especificação de tipo de elemento de GUI 426 e um terminador demensagem de especificação de tipo de elemento de GUI 428. O cabeçalho426 e o terminador 428 significam que os dados na mensagem especificamum mapeamento de tipo para um elemento de GUI. Para essa finalidade, amensagem de especificação de tipo de elemento de GUI 424 ainda podeincluir um alias de GAP 430, um identificador de elemento de GUI 432 e umidentificador de tipo de GUI 434.

A Figura 5 mostra um GAP 500 e uma interface de usuário deexemplo 502 para a lógica de tipificação 316. O operador seleciona os ele-mentos de GUI usando, por exemplo, o cursor do mouse. Quando selecio-nada, a lógica de tipificação 316 destacada o elemento de GUI selecionado.No exemplo mostrado na Figura 4, o elemento de GUI selecionado é a caixade texto 504.

Em resposta a seleção de um elemento de GUI, a lógica de tipi-ficação 316 exibe um requisitante de tipo 506. O requisitante de tipo 506prove uma lista suspensa 508 a qual lista os tipos de elemento de GUI dis-poníveis definidos no modelo de tipo de GUI de referência 122. O operadorseleciona um tipo de elemento para atribuição ao elemento de GUI selecio-nado 504, neste caso, "US-StateTextBox". Clicar no botão 'OK' dirige a lógi-ca de tipificação 316 para a criação do mapeamento do tipo US-StateTextBox para a caixa de texto 504. Clicar em 'Cancel' dirige a lógica detipificação 316 para não tomar nenhuma medida.

A Figura 6 mostra um fluxograma 600 do processamento reali-zado pela lógica de tipificação 316. A lógica de tipificação 316 monitoraquanto à entrada de operador (602). Em particular, a lógica de tipificação316 usa a entrada de operador para determinar um modelo de tipo de GUIde referência selecionado e o GAP que o operador tipificará (604). Por e-xemplo, o operador pode enviar um modelo de tipo de GUI de referência a-plicável a partir de uma lista de modelos de tipo de GUI de referência, e po-de especificar o programa executável concretizando o GAP a partir de umalista de GAPs conhecidos.

A lógica de recuperação de tipo 320 recupera uma lista de sele-ção de tipo de elemento de GUI (606) a partir do modelo de tipo de GUI dereferência selecionado. Continuando o exemplo dado acima na Tabela 1, alógica de recuperação de tipo 320 recupera a lista {SSNEntryBox, SSNDis-playBox, StaticWindowLabel, 3DButton, HelpTextEntryBox, MenuWidget, eUS-StateTextBox} a partir do modelo de tipo de GUI de referência. A listacontém os tipos de elemento de GUI permissíveis que o operador pode atri-buir a qualquer dado elemento de GUI.

A lógica de tipificação 316 também pode exibir o GAP selecio-nado (608). Em uma implementação, a lógica de tipificação 316 inicia a exe-cução do GAP. A lógica de seleção de elemento 318, então, monitora quantoa uma entrada de operador (610). Em particular, a lógica de seleção de ele-mento 318 monitora quanto a cliques de mouse, entrada de teclado ou outraentrada para a determinação de um elemento de GUI selecionado (612). Alógica de seleção de elemento 318 destaca o elemento de GUI selecionado(614). Como exemplos, a lógica de seleção de elemento 318 pode desenharuma borda em torno do elemento, mudar a cor do elemento, fazer piscar oelemento ou de outra forma destacar o elemento de GUI selecionado.

A lógica de seleção de tipo 322 exibe a lista de seleção de tipode elemento de GUI (616). Por exemplo, a lógica de seleção de tipo 322 po-de exibir o requisitante de tipo 506. A lógica de seleção de tipo 322 monitoraquanto a uma entrada de operador (618), tal como uma seleção de lista sus-pensa de um tipo de elemento a partir da lista de seleção de tipo de elemen-to de GUI. Em particular, a lógica de seleção de tipo 322 obtém uma seleçãode tipo de elemento de GUI que especifica o tipo de elemento de GUI sele-cionado a partir da lista de seleção de tipo de elemento de GUI exibida(620).

Se o operador aceitar a seleção, a lógica de associação de tipo324 criará um mapeamento de tipo de elemento de GUI (622). Especifica-mente, a lógica de associação de tipo 324 cria um mapeamento que liga otipo de elemento de GUI selecionado ao elemento de GUI selecionado. Paraessa finalidade, a lógica de associação de tipo 324 pode criar uma entradade mapeamento de tipo no modelo de tipo de GUI correspondente ao GAPselecionado no depósito 124 que especifica um campo de alias de GAP, umidentificador de elemento de GUI 404 para o elemento de GUI selecionado eum identificador de tipo de GUI 406 de acordo com o tipo de em selecionadopor operador. A Figura 4 proporciona exemplos de mapeamentos de tipo deelemento de GUI.

Além disso, a lógica de tipificação 316 pode comunicar o mape-amento de tipo de elemento de GUI para sistemas externos. Para essa fina-lidade, a lógica de criação de mensagem 326 pode construir uma mensagemde especificação de tipo de elemento de GUI (624). A mensagem de especi-ficação de tipo pode incluir o mapeamento, um cabeçalho de mensagem deespecificação de tipo e um terminador de mensagem de especificação detipo. A lógica de criação de mensagem 326 também pode comunicar a men-sagem de especificação de tipo de elemento de GUI para o depósito de me-tadados 202 (626).

A Figura 7 mostra um exemplo do sistema 102 no qual uma lógi-ca de mapeamento de versão de elemento de GUI ("lógica de mapeamentode versão") 702 reside na memória 114. A lógica de mapeamento de versão702 pode ser incluída na lógica de tipificação e de mapeamento de GUI 120,mas também pode ser um módulo separado ou implementado de outrasformas. A lógica de mapeamento de versão 702 pode incluir uma lógica deseleção de elemento 704, uma lógica de criação de mapeamento 706 e umalógica de criação de mensagem 708. A lógica de mapeamento de versão702 gera mapeamentos de versão de elemento de GUI (por exemplo, o ma-peamento de versão 710).

A Figura 8 mostra um exemplo do mapeamento de versão deelemento de GUI ("mapeamento de versão") 802. O mapeamento de versão802 inclui um alias de GAP de origem 804, um identificador de elemento deGUI de origem 806, um alias de GAP de destino 808 e um identificador deelemento de GUI de destino 810. Campos adicionais, em menor quantidadeou diferentes podem ser incluídos no mapeamento de versão 802.

O alias de GAP de origem 804 especifica um identificador paraum GAP ("o GAP de origem") que inclui um primeiro elemento de GUI sele-cionado, enquanto o alias de GAP de destino 808 especifica um identificadorpara um GAP (o "GAP de destino") que inclui um segundo elemento de GUIselecionado que deve ser ligado ao primeiro elemento de GUI selecionado.Os aliases de GAP 804 e 808 podem ser identificadores únicos que distin-guem entre GAPs, tais como identificadores que diferenciam a versão deGAP atual e a versão de GAP subsequente. O identificador de elemento deGUI de origem 806 prove um identificador único para o elemento de GUI se-lecionado no GAP de origem, enquanto o identificador de elemento de GUIde destino 810 prove um identificador único para o elemento de GUI selecio-nado no GAP de destino.

A Figura 8 também mostra um exemplo específico de um mape-amento de versão 812. O mapeamento de elemento 812 especifica um aliasde GAP de origem 814 de "University Directoryl", significando a versão sub-sequente de um GAP de diretório de universidade. O elemento de GUI deorigem sendo mapeado (por exemplo, uma caixa de combinação), tem o i-dentificador de elemento único 816 "0x30fc8" etiquetado pelo rótulo"HWND". O mapeamento de elemento 812 também especifica um alias deGAP de destino 818 de "University DirectoryO", significando a versão atualde um GAP de diretório de universidade. O elemento de GUI de destinosendo mapeado (por exemplo, uma caixa de lista suspensa) tem o identifi-cador de elemento único 820 "0x30fc0" etiquetado pelo rótulo "HWND". As-sim, o mapeamento de versão 812 estabelece que uma caixa de lista sus-pensa em particular na versão subsequente do GAP corresponde a uma cai-xa de combinação em particular na versão de GAP atual.

A Figura 8 também mostra um exemplo de uma mensagem deespecificação de mapeamento de elemento de GUI 822. A mensagem deespecificação de mapeamento de elemento de GUI 822 pode incluir um ca-beçalho de mensagem de especificação de mapeamento de elemento deGUI 824 e um terminador de mensagem de especificação de mapeamentode elemento de GUI 826. O cabeçalho 824 e o terminador 826 significamque os dados na mensagem especificam um mapeamento de elemento en-tre elementos de GUI em GAPs diferentes. Para essa finalidade, a mensa-gem de especificação de mapeamento de elemento de GUI 822 pode incluir,ainda, um alias de GAP de origem 828, um identificador de elemento de GUIde origem 830, um alias de GAP de destino 832 e um identificador de ele-mento de GUI de destino 834.

Uma extensão opcional para o mapeamento de versão de ele-mento de GUI 802 é o campo de nível de confiança 811. O campo de nívelde confiança 811 pode especificar um grau de confiabilidade para o mapea-mento de versão de elemento de GUI. Quando o mapeamento de versãosurge a partir dos esforços de um operador humano, por exemplo, a lógicade mapeamento 702 pode regular o nível de confiança relativamente alto(por exemplo, de 90 a 100%). Quando o mapeamento de versão surge apartir de uma análise automatizada, a lógica de mapeamento de versão 702pode regular o nível de confiança em um nível especificado (por exemplo,um nível predefinido para combinação automatizada), ou pode regular umlimite que depende da força da análise automatizada.Por exemplo, a análise automatizada pode determinar um escore normalizado para qualquer dada tentativa de combinação de um elemento de GUI com um outro elemento de GUI. O campo de nível de confiança 811 então pode especificar o escore normalizado. O campo de nível de confiança 811 ainda pode especificar por que o nível de confiança é regulado para qualquer valor em particular. Além disso, um campo de explicação (por e-xemplo, um caractere tal como "M" ou "A") pode ser incluído no campo de nível de confiança 811 para denotar que o nível de confiança surge de uma análise Manual ou Automatizada. Um exemplo é o nível de confiança 821, regulado para "88A" para denotar uma análise automatizada e um escore normalizado de 88, enquanto o nível de confiança 836 mostra um valor de confiança de 100, sem especificar uma explicação.

A Figura 9 mostra a versão de GAP atual 902 e uma versão de GAP subsequente 904, bem como uma interface de usuário de mapeamento de exemplo 906 para a lógica de mapeamento 702. Ambos os GAPs 902 e 904 são mostrados executando e apresentando suas GUIs no visor 121. O operador seleciona elementos de GUI usando, por exemplo, o cursor do mouse, uma entrada de teclado ou outras entradas.

Mediante uma seleção, a lógica de mapeamento 702 destaca os elementos de GUI selecionados. No exemplo mostrado na Figura 9, o elemento de GUI selecionado na versão de GAP atual 902 é a caixa de lista 908. O elemento de GUI selecionado na versão de GAP subsequente 904 é a lista suspensa 910. Mediante uma seleção de um elemento em cada GAP, a lógica de mapeamento 702 exibe a interface de usuário de mapeamento 906. Clicar no botão 'OK' direciona a lógica de mapeamento 702 para criar o mapeamento de elemento entre a caixa de lista 908 e a lista suspensa 910. Clicar em 'Cancel' dirige a lógica de mapeamento 702 para não efetuar nenhuma ação.

A Figura 10 mostra um fluxograma 1000 do processamento realizado pela lógica de mapeamento 702. A lógica de mapeamento 702 monitora quanto a uma entrada de operador (1002) de modo a determinar um primeiro GAP (1004) (por exemplo, a versão de GAP atual) e um segundoGAP (1006) (por exemplo, a versão de GAP subsequente) entre os quais o operador mapeará elementos de GUI individuais. Por exemplo, o operador pode selecionar arquivos de programa executáveis para os GAPs a partir de uma janela de seleção de arquivo para escolher os dois GAPs. A lógica de mapeamento 702 exibe as GUIs para os GAPs selecionados (por exemplo, pela execução dos GAPs) (1008).

A lógica de seleção de elemento 704 então monitora quanto a uma entrada de operador (1010). Em particular, a lógica de seleção de elemento 704 detecta uma entrada de mouse, de teclado e outros tipos de entrada para determinar quando um operador selecionou elementos de GUI nos GAPs (1012). A lógica de seleção de elemento 704 destaca cada elemento de GUI selecionado (1014). Quando um elemento de GUI a partir de cada GAP tiver sido selecionado, a lógica de seleção de elemento 704 exibe uma interface de usuário de mapeamento de elemento de GUI (1016). Se o operador clicar em 'Cancel', a lógica de mapeamento 702 não precisará efetuar nenhuma ação, mas poderá continuar a assistir quanto a seleções de elemento de GUI adicionais.

Se o operador clicar em 'OK, a lógica de criação de mapeamento 706 criará um mapeamento de versão de elemento de GUI que especifica que existe uma relação entre os elementos de GUI selecionados (1018). Para essa finalidade, a lógica de criação de mapeamento 706 pode armazenar um alias de GAP de origem, um identificador de elemento de GUI de origem correspondente ao elemento de GUI selecionado no GAP de origem, um alias de GAP de destino, e um elemento identificador de GUI de destino correspondente ao elemento de GUI selecionado no GAP de destino.

Adicionalmente, a lógica de criação de mensagem 708 pode construir uma mensagem de especificação de mapeamento de elemento de GUI (1020). Para essa finalidade, a lógica de criação de mensagem 708 pode armazenar um cabeçalho de mensagem de especificação de mapeamento de elemento de GUI e um terminador de mensagem de especificação de mapeamento de elemento de GUI. O cabeçalho e o terminador significam que os dados na mensagem especificam um mapeamento de elemento deGUI entre os elementos de GUI em GAPs diferentes. A mensagem de especificação de tipo de elemento de GUI ainda pode incluir um alias de GAP de origem, um identificador de elemento de GUI de origem, um alias de GAP de destino e um identificador de elemento de GUI de destino. A lógica de criação de mensagem 708 pode então comunicar a mensagem de especificação de mapeamento de elemento de GUI para outros sistemas, tal como um depósito de metadados (1022).

A Figura 11 mostra uma implementação de exemplo do sistema de tipificação e de mapeamento de elemento de GUI ("sistema") 1100. O sistema 1100 inclui uma lógica de driver 1102 na memória 114, bem como um proxy 1104 que acessa uma tabela de GAP 1106. Na Figura 11, a versão de GAP atual 1108 é mostrada em execução com um gancho 1110, e a versão de GAP subsequente 1112 também é mostrada em execução com um gancho 1114.

O proxy 1104 inclui uma lógica que insere os ganchos 1110 e 1114 no espaço de processo dos GAPs 1108 e 1112. O proxy 1104 se comunica com os ganchos 1110 e 1114. Em particular, o proxy 1104 pode trocar mensagens com os ganchos 1110 e 1114 para a obtenção do estado de qualquer um ou de todos os elementos de GUI nos GAPs 1108 e 1112. Os ganchos 1110 e 1114 são programas que respondem a mensagens do proxy 1104, e que podem interagir através de uma camada de acessibilidade para descobrir e reportar uma informação sobre os elementos de GUI nos GAPs 1108 e 1112 para o proxy. O sistema operacional geralmente prove a camada de acessibilidade. A camada de acessibilidade expõe uma interface de acessibilidade através da qual o proxy 1104 e os ganchos 1110e 1114 podem invocar métodos e regular e recuperar valores e características de elemento de GUI e, desse modo, selecionar, destacar, controlar, modificar, atribuir identificadores para ou interagir de outra forma com os elementos de GUI nos GAPs.

A camada Microsoft (TM) Active Accessibility (MSAA) é um exemplo de uma camada de acessibilidade adequada. Nesse sentido, os GAPs 1108 e 1112 expõem as interfaces de acessibilidade que exportammétodos para acesso e manipulação das propriedades e do comportamento de elementos de GUI. Por exemplo, os GAPs 1108 e 1112 podem empregar a interface lAccessible para se permitirem acesso e controle em relação ao elemento de GUI usando chamadas de API de MSAA. A interface Accessible ainda facilita aplicativos para exposição de uma árvore de nós de dados que constituem cada janela na interface de usuário com a qual se interage atualmente. A lógica de driver 1112 e o proxy 1104 podem incluir, então, declarações de programa para acesso e controle do elemento de GUI, como se o elemento de GUI fosse um objeto de programação convencional. As chamadas de API de acessibilidade podem incluir: realizar uma ação em um objeto, obter um valor de um objeto, regular um valor no objeto, navegar para o objeto, e regular uma propriedade no objeto, e outras chamadas.

O proxy 1104 pode ser um programa daemon e pode começar antes da lógica de driver 1102. O proxy 1104 pode estar ciente de um ou mais GAPs. Quando o proxy 1104 começa, ele carrega a tabela de GAP 1106, a qual pode incluir um conjunto predefinido de entradas de GAP quanto às quais o proxy 1104 está ciente. Uma entrada de GAP pode assumir a forma:

<Alias, <File0, PathO, DirO, CommandLine0>,

<File1, Pathl, Dir1, CommandLinel»

onde Alias é um nome predefinido único para o GAP (por exemplo, um nome genérico para a versão de GAP atual 1108 e a versão de GAP subsequente 1112), FileO é o nome do programa executável para a versão de GAP atual 1108, PathO é o caminho absoluto para FileO, DirO é o caminho absoluto para o diretório a partir do qual FileO deve ser executado, e CommandLine especifica os argumentos de linha de comando para FileO. Filei, Pathl, Dir1 e CommandLinel provêem parâmetros similares para a versão de GAP subsequente 1112.

Quando a lógica de driver 1102 começa, ela se conecta ao Proxy de forma local ou remota (por exemplo, através de uma porta de Protocolo de Controle de Transmissão (TCP)). Uma vez conectada, a lógica de driver 1102 requisita a tabela de GAP 1106 ao enviar uma mensagem derequisição de tabela de GAP para o proxy 1104. O proxy 1104 responde pelo envio de uma mensagem de resposta de tabela de GAP incluindo a tabela de GAP 1106 para a lógica de driver 1102. Uma troca de mensagem de e-xemplo é mostrada na Tabela 2: Tabela 2

<table>table see original document page 29</column></row><table>

A lógica de driver 1102 então pode prover uma lista de GAPs para escolher a partir do operador quanto a tipificar o GAP (Figura 5, (602), (604)) ou realizar um mapeamento de elemento de GUI (Figura 10, (1002), (1004), (1006)). A lógica de driver 1102 então pode criar uma mensagem de carregar GAP, por exemplo, <LoadGap Alias="name"/> e enviar a mensagem de carregar GAP para o proxy 1104 para se começar qualquer GAP selecionado (o qual então exibirá sua interface de usuário) (Figuras 6 e 10, (608), (1008)). Quando o operador está realizando um mapeamento de elemento, uma mensagem de carregar GAP pode fazer co que o proxy 1104 comece múltiplas versões de um identificador de GAP em conjunto com a tabela de GAP 1106 na seção de <GAP>.

Após começar os GAPs, o proxy 1104 injeta ganchos no espaço de processo de GAPs. O gancho se conecta ao proxy 1104 e envia uma mensagem de confirmação (por exemplo, <GAP File="gap.exe" Instan-ce="192"/>). O proxy 1104 envia uma mensagem de sucesso (por exemplo, <Loaded Alias="name" VN="192" VN1="1937>) para a lógica de driver 1102, desse modo reconhecendo que os GAPs foram começados de forma bem-sucedida.

O operador pode requisitar o estado atual de cada GAP come-çado a partir da lógica de driver 1102. Em resposta, a lógica de driver 1102 envia uma mensagem de requisição de estado (por exemplo, <GetState Ali-as="name"/>) para o proxy 1104. Por sua vez, o proxy 1104 localiza a conexão com os ganchos correspondentes dos GAPs e envia uma mensagem de requisição de estado (por exemplo, <GetState/>) para os ganchos. Os ganchos criam um estado de GAP (incluindo identificadores únicos para os elementos de GUI), tal como uma árvore de estado, codifica-o (por exemplo, em um formato em XML), e o envia para o proxy 1104. O proxy 1104 encaminha o estado de GAP para a lógica de driver 1102. Uma mensagem de estado de GAP de exemplo enviada pelo proxy 1104 é mostrada na Tabela 3.

Tabela 3

<table>table see original document page 30</column></row><table>

O estado de GAP contém uma informação sobre os elementos de GUI compondo uma dada tela, bem como os valores destes elementos e seus identificadores atribuídos. O estado de GAP especifica os elementos de GUI de GAP e os valores dos elementos de GUI. Em uma implementação, o estado de GAP é refletido em uma estrutura de linguagem de marcação extensível (XML), onde o elemento 'State' tem um ou mais elementos filhos 'GAP', cujos elementos filhos por sua vez são 'GUIEIements'. Por exemplo, os elementos de GUI podem ser containeres ou básicos. Os elementos deGUI de container contêm outros elementos, enquanto os elementos básicos não contêm outros elementos. A estrutura de XML reflete a hierarquia de contenção ao permitir que os GUIEIements contenham outros GUIEIements.

Na estrutura de XML, o atributo SeqNumber pode designar um número de seqüência único do estado dentro do GAP. Uma vez que os estados são mapeados para telas de GUI, a cada estado pode ser dado um nome o qual é especificado pelo atributo 'Name'. Os atributos Alias e Pro-cessID podem denotar o alias do GAP e seu identificador de processo de instância, respectivamente. O identificador de processo de instância pode diferenciar entre a versão de GAP atual e a versão de GAP subsequente.

A lógica de tipificação e de mapeamento 120 pode aceitar uma entrada de operador (por exemplo, uma entrada de mouse) através da qual o operador identifica um objeto de GUI ao apontar o cursor para ele (Figuras 10 e 6, (1012) e (612)). A lógica de tipificação e de mapeamento 120 então pode desenhar uma moldura em torno do elemento (Figuras 10 e 6 (1014) e (614)). A lógica de tipificação e de mapeamento 120 então pode exibir uma lista de seleção de tipo de elemento de GUI (Figura 6, (616)) ou uma interface de usuário de mapeamento de elemento de GUI (Figura 10, (1016)). O operador seleciona o tipo apropriado para o objeto (Figura 6, (620)) ou verifica se um mapeamento deve ser criado entre dois objetos selecionados. Em qualquer caso, o proxy 1104 envia um mapeamento de tipo de elemento de GUI ou um mapeamento de versão de elemento de GUI para a lógica de driver 1102. Por sua vez, a lógica de driver 1102 pode armazenar os mapeamentos no depósito 116, e pode criar e comunicar uma mensagem de especificação de elemento de GUI ou uma mensagem de especificação de tipo de elemento de GUI para o depósito de metadados 202 (Figura 6, (626) e Figura 10, (1022)).

A Figura 11 também mostra um depósito de modelo de tipo de referência 1116. O sistema 1110 pode tirar o modelo de tipo de GUI de referência 122 atualmente sendo aplicado a partir de um de muitos modelos de tipo de referência disponíveis no depósito de modelo de tipo de referência 1116. Os exemplos mostrados na Figura 11 de modelos de tipo de referên-cia incluem um modelo de tipo de referência de jogo de interpretação de papéis (role playing game - RPG) online 1118, que pode ser selecionado pelo operador, quando do projeto ou da tipificação de um GAP que implementa uma funcionalidade de jogo online, e um modelo de tipo de referência de registros de paciente 1120 que o operador pode selecionar quando projetando ou tipificando um GAP de assistência médica. Os exemplos adicionais incluem o modelo de tipo de referência de processador de texto 1122 que o operador pode selecionar quando tipificando ou construindo um GAP de processador de texto, e um modelo de tipo de referência de envio de mensagem instantânea (IM) 1124, que o operador pode selecionar quando projetando ou tipificando um GAP de IM.

A Figura 12 mostra uma modalidade de uma arquitetura de ferramenta de evolução de metadados 1200. A arquitetura 1200 inclui uma interface 136, um processador 129, uma memória 130, e um depósito de metadados 138. A arquitetura 1200 pode se comunicar com outros sistemas através da interface 136. Por exemplo, a arquitetura 1200 pode receber requisições de informação de metadados e enviar respostas àquelas requisições através da interface 136. De forma alternativa ou adicional, a arquitetura 1200 pode enviar instruções para a interface 136 para exibição de um alerta em um terminal não local e pode receber respostas ao alerta através da interface 136. De forma alternativa ou adicional, o processador 129 pode enviar instruções para exibição de um alerta em um visor 1236 e pode receber respostas ao aleta. O processador 129 executa a lógica armazenada na memória 130. O depósito de metadados 138 recebe, recupera e armazena uma informação de metadados processada pelo processador 129.

A memória 130 pode incluir uma lógica de processamento de metadados 132, uma lógica de gerenciamento de banco de dados e de arquivo 134 e mensagens 1214. A lógica de processamento de metadados 132 pode instruir o processador 129 para realizar fluxos de processo para manutenção e migração de metadados. A lógica de gerenciamento de banco de dados e de arquivo 134 pode instruir o processador 129 para realizar processos relevantes para armazenamento de dados, recuperação e manipula-ção para e a partir do depósito de metadados 138. As mensagens 1214 podem ser armazenadas na memória, quando recebidas a partir da interface 136 e manipuladas pelo processador 129 de acordo com instruções a partir da lógica de processamento de metadados 132.

A lógica de processamento de metadados 132 inclui uma lógica de manipulação de mensagem de metadados 1216, uma lógica de processamento de tipo 1218, uma lógica de processamento de mapeamento 1220, uma lógica de processamento de notação 1222 e uma lógica de migração de metadados 1224. A lógica de manipulação de mensagem de metadados 1216 pode instruir o processador 129 para armazenar as mensagens 1214 recebidas a partir da interface 136 na memória 130 e processar as mensagens 1214 conforme descrito abaixo. A lógica de manipulação de mensagem de metadados 1216 pode incluir uma lógica de comunicação 1226 e uma lógica de análise gramatical 1228. A lógica de comunicação 1226 pode instruir o processador 129 para enviar e receber mensagens 1214 através da interface 136. A lógica de comunicação 1226 também pode instruir o processador 129 para armazenar as mensagens 1214 na memória 130. De forma alternativa ou adicional, a lógica de comunicação 1226 pode enviar instruções para a interface 136 para a exibição de um alerta para um terminal nãolocal e pode instruir o processador 129 para processar instruções recebidas pela interface 136, em resposta ao alerta. De forma alternativa ou adicional, a lógica de comunicação 1226 pode instruir o processador 129 para enviar instruções para o visor 1236 para exibição de um alerta, e o processador 129 pode processar instruções recebidas em resposta ao alerta. A lógica de análise gramatical 1228 pode instruir o processador 129 para analisar gramaticalmente as mensagens 1214. Por exemplo, a lógica de análise gramatical 1228 pode instruir o processador 129 para extrair uma informação de identificação de metadados a partir das mensagens.

A lógica de processamento de tipo 1218, a lógica de processamento de mapeamento 1220 e a lógica de processamento de notação 1222 podem instruir o processador 129 para o processamento de mensagens de metadados, tais como a mensagem de especificação de tipo 1230, a men-sagem de especificação de mapeamento 1232 e a mensagem de notação 1234. Por exemplo, a lógica de processamento de tipo 1218, a lógica de processamento de mapeamento 1220 ou a lógica de processamento de notação 1222 pode instruir o processador 129 para manter um registro de metadados armazenado no depósito de metadados 138. Nesse sentido, o processador 129 pode dirigir uma leitura, uma escrita, um armazenamento, uma cópia, uma atualização, um movimento, um apagamento, uma sobrescrita, uma anexação em apenso, ou manipular de outra forma dados armazenados em um registro de metadados no depósito de metadados 138. A lógica de processamento de tipo 1218, a lógica de processamento de mapeamento 1220 ou a lógica de processamento de notação 1222 pode ser realizada em conjunto com processos a partir da lógica de gerenciamento de banco de dados e de arquivo 134, As mensagens 1214 incluem como exemplos mensagens de especificação de tipo 1230, mensagens de especificação de mapeamento 1232 e mensagens de notação 1234, mas podem incluir outras mensagens relacionadas a metadados. As mensagens de especificação de tipo 1230, as mensagens de especificação de mapeamento 1232 e as mensagens de notação 1234 são discutidas em maiores detalhes com respeito às Figuras 4, 8 e 14, respectivamente.

A Figura 13 mostra uma implementação do depósito de metadados 138. O depósito de metadados 138 pode ser organizado de muitas formas diferentes, contudo. O depósito de metadados 138 pode incluir um registro de metadados de GAP 0 1302, um registro de metadados de GAP 1 1304 até um registro de metadados de GAP 'j' 1306, e um registro de mapeamento de versão de elemento de GUI 1308. Os registros de metadados de GAP 1302, 1304 e 1306 podem armazenar metadados associados a um GAP específico ou a uma versão de GAP. O registro de mapeamento de versão de elemento de GUI 1308 pode armazenar mapeamentos a partir de um elemento de GUI para um outro elemento de GUI.

Cada registro de metadados de GAP pode incluir um identificador de GAP. Os identificadores de GAP 1310, 1312, e 1314 podem servir para a identificação de um GAP, de uma versão de um GAP ou de ambos.Por exemplo, o registro de metadados de GAP 0 1302 contém um identificador de GAP 1 de "University DirectoryO" e o registro de metadados de GAP 1 1304 contém um identificador de GAP 1 1312 de "University Directoryl". Neste caso, "University DirectoryO" pode servir para a identificação do GAP inteiro como "University DirectoryO". De forma alternativa ou adicional, "University DirectoryO" pode servir para a identificação do GAP como a versão 0 (por exemplo, a versão atual) do GAP "University Directory". O depósito de metadados 138 pode armazenar registros de metadados para múltiplos GAPs, bem como múltiplos registros de metadados para cada uma das múltiplas versões de cada GAP.

O registro de metadados de GAP 0 1302 adicionalmente pode incluir o registro de metadados de elemento de GUI 1 1316 através do registro de metadados de elemento de GUI 'n' 1318. O número total 'n' de registros de metadados de elemento de GUI armazenados em cada registro de metadados de GAP pode variar, dependendo da complexidade do GAP. Cada registro de metadados de elemento de GUI pode corresponder a um elemento de GUI em um GAP ou uma versão de um GAP, e cada elemento de GUI em um gpa pode ter um registro de metadados de elemento de GUI correspondente a um registro de metadados de GAP. Por exemplo, o registro de metadados de GAP 0 1302 contém o registro de metadados de elemento de GUI 'n' 1318 indicando que o GAP 0 pode ser composto por 'n' ou mais elementos de GUI identificáveis. De forma alternativa ou adicional, o registro de metadados de elemento de GUI 'n' 1318 pode indicar que o registro de metadados de GAP 0 1302 atualmente contém 'n' registros de metadados de elemento de GUI, onde 'n' pode ser um valor inteiro de 0 até o número total de elementos de GUI no GAP 9. Todo elemento de GUI em um GAP pode não ter um registro de metadados de elemento de GUI. De modo similar, o registro de metadados de GAP 1 1304 pode conter o registro de metadados de elemento de GUI 'k', e um registro de metadados de GAP 'j' pode conter o registro de metadados de elemento de GUI 'm' 1322.

Cada um dos registros de metadados de elemento de GUI 1316, 1318, 1320 e 1322 pode incluir um identificador de elemento de GUI 1324,um identificador de tipo 1326, uma notação 1328, um mapeamento de elemento de GUI 1330 e outros metadados 1332. Um identificador de elemento de GUI 1324 pode servir para a identificação de um elemento de GUI no GAP ou na versão de GAP, usando-se um número único, uma string de caracteres ou outros índices. Por exemplo, um ID de elemento pode ser "0x30fb0". Um identificador de tipo 1326 pode ser uma classificação de um elemento de GUI que defina semântica de nível alto, anotações e propriedades, comportamentos permitidos ou restritos, e valores associados ao elemento de GUI. Por exemplo, um identificador de tipo pode ser "US-StateTextBox", o que pode especificar um tipo de elemento de GUI de caixa de texto que apenas aceita strings correspondentes aos nomes dos estados dos Estados Unidos. Esta informação pode vir a partir do conhecimento de um engenheiro de testes quando ele ou ela tentar entender a semântica de cada elemento de GUI no GAP sob teste.

Uma notação 1328 pode incluir texto, notas, comentários informais, restrições, ou uma informação derivada de uma especificação técnica que um programador pode desejar levar para um outro programador sobre um elemento de GUI em particular. Por exemplo, uma notação 1328 pode incluir o texto "State Names Only" como um método informal de levar paraum outro programador que apenas strings correspondentes aos nomes dos estados dos Estados Unidos devem ser incluídas. Um mapeamento de elemento de GUI 1330 pode identificar um elemento de GUI em um outro GAP ou versão de GAP correspondente ao elemento de GUI associado ao registro de metadados de elemento de GUI. Por exemplo, um mapeamento de elemento de GUI 1330 pode incluir os valores "University Directoryl" e "0x30fc8" para indicar que o elemento de GUI associado a este registro de metadados de elemento de GUI corresponde ao elemento de GUI 0x30fc8 no GAP University Directory, versão 1. Adicionalmente, outros metadados 1332 podem ser armazenados em associação com um registro de metadados de elemento de GUI.

O depósito de metadados 138 pode incluir qualquer número de registros de mapeamento de versão de elemento de GUI, tal como o registro1308. O número de registros de mapeamento de versão de elemento de GUI 1308 pode variar, dependendo do número de GAPs ou de versões de GAP. Por exemplo, cada registro de mapeamento de versão de elemento de GUI 1308 pode incluir mapeamentos a partir de uma versão de GAP específica para uma outra versão de GAP específica. De forma alternativa ou adicional, cada registro de mapeamento de versão de elemento de GUI 1308 pode incluir todos os mapeamentos entre todas as versões de um único GAP. O exemplo da Figura 13 mostra que o registro de mapeamento de versão de elemento de GUI 1308 inclui mapeamentos de versão de elemento de GUI 1334 e 1336. O número de mapeamentos de versão de elemento de GUI 1334 e 1336 em um registro de mapeamento de versão de elemento de GUI 1308 pode variar de acordo com o número de mapeamentos feitos entre e-lementos de GUI de GAPs ou de versões de GAP diferentes.

Cada mapeamento de versão de elemento de GUI 1334 ou 1336 pode incluir um identificador de alias de GAP de origem 1338, um identificador de elemento de GUI de origem 1340, um identificador de alias de GAP de destino 1342, um identificador de elemento de GUI de destino 1344 e um valor de nível de confiança 1346. O mapeamento de versão de elemento de GUI 1348 prove um exemplo de um mapeamento de versão de elemento de GUI usando linguagem de marcação extensível (XML). O mapeamento de versão de elemento de GUI 1348 inclui um identificador de alias de GAP de origem 1350, um identificador de elemento de GUI de origem 1352, um identificador de alias de GAP de destino 1354, um identificador de elemento de GUI de destino 1356 e um valor de nível de confiança 1358. Neste exemplo, o mapeamento indica uma correspondência entre o elemento de GUI 0x30fc8 de GAP University Directory, versão 1 (por exemplo, uma versão subsequente) com o elemento de GUI 0x80fc0 de GAP University Directory, versão 0 (por exemplo, uma versão atual), com um nível de confiança de 1200. Os valores de nível de confiança podem usar valores decimais entre 0 e 1, valores inteiros entre 0 e 100, ou qualquer outra escala, para indicarem a intensidade da certeza que se tem quanto ao mapeamento entre os elementos de GUI ser um mapeamento correto. Por exemplo, um mapeamentoprovido por um usuário humano pode ter uma confiança alta ou absoluta de 1 ou 1200 por cento, onde um mapeamento provido por um programa de avaliação de mapeamento usando uma comparação de propriedade de elemento de GUI pode ter uma confiança mais baixa ou nenhuma. De forma alternativa ou adicional, um mapeamento provido por um programa de avaliação de mapeamento usando uma comparação de propriedade de elemento de GUI pode ter uma confiança alta ou absoluta, onde um mapeamento provido por um usuário humano pode ter uma confiança mais baixa ou nenhuma.

O processador 129 usa a lógica de gerenciamento de banco de dados e de arquivo 134 para acessar e manipular qualquer um dos registros de metadados de GAP 1302, 1304 ou 1306, os registros de metadados de elemento de GUI 1316, 1318, 1320 ou 1322, e/ou registros de mapeamento de versão de elemento de GUI armazenados no depósito de metadados 138.

O acesso e a manipulação dos dados no depósito de metadados 138 podem incluir a leitura, a escrita, o armazenamento, a cópia, a atualização, o movimento, o apagamento, a sobrescrita, a anexação em apenso, ou qualquer outra função realizada nos dados.

A Figura 14 mostra um exemplo de um mapeamento de notação de elemento de GUI 1400 que pode ser um componente de uma mensagem de notação de elemento de GUI 1234. O formato de mapeamento de notação 1400 inclui um alias de GAP 1402, um identificador de elemento de GUI 1404 e uma notação de GUI 1406. Campos adicionais, a menos ou diferentes podem ser incluídos no mapeamento de notação 1400.

O alias de GAP 1402 especifica um identificador para o GAP, o qual inclui o elemento de GUI ao qual uma notação está sendo aplicada. O alias de GAP 1402 pode ser um identificador único que distingue entre GAPs ou versões de GAP, incluindo uma versão de GAP atual e uma versão subsequente do mesmo GAP. O identificador de elemento de GUI 1404 prove um identificador único para o elemento de GUI o qual está sendo anotado. A notação de GUI 1406 especifica a notação sendo atribuída ao elemento de GUI (por exemplo, o texto "State names only").A Figura 14 também mostra dois exemplos de mapeamentos de notação de GUI 1408 e 1410 usando uma representação em XML. O mapeamento de notação 1408 é um mapeamento para um elemento de GUI de Window. O alias de GAP 1412 é "University DirectoryO", significando a versão atual de um GAP de diretório de universidade. O elemento de GUI sendo anotado tem um identificador de elemento único 1414 "0x30fb0" anotado pelo identificador de HWND e estabelecido, por exemplo, por uma interface de camada de acessibilidade. A notação de GUI 1416 para o elemento de GUI de Window é o texto "State names only".

O mapeamento de notação 1410 é um mapeamento para um elemento de GUI de Menu Item. O alias de GAP 1418 é "University Direc-toryl", significando a versão subsequente do GAP de diretório de universidade. O elemento de GUI sendo anotado tem o identificador de elemento único 1420 "OpenFile" conforme especificado pelo campo Name. A notação de GUI 1422 para o elemento de GUI de Window é o texto "Opens to Default Directory", conforme especificado pelo campo Annotation.

A Figura 14 também mostra um exemplo de uma mensagem de notação de elemento de GUI 1424 em uma representação em XML. A mensagem de notação de elemento de GUI 1424 pode incluir um cabeçalho de mensagem de notação de elemento de GUI 1426 ("NotationGuiObject") e um terminador de mensagem de notação de elemento de GUI 1428 ("/NotationGuiObject"). O cabeçalho 1426 e o terminador 1428 significam que os dados dentro da mensagem especificam uma notação para um elemento de GUI. Para essa finalidade, a mensagem de notação de elemento de GUI 1424 ainda pode incluir um alias de GAP 1430, um identificador de elemento de GUI 1432 e uma notação de GUI 1434.

A Figura 15 mostra um fluxograma 1500 de processamento de mensagem de metadados que a lógica de processamento de metadados 132 pode realizar. A lógica de processamento de metadados 132 pode obter uma mensagem de metadados (1502). Por exemplo, a mensagem de metadados pode ser obtida através da interface 136 e armazenada na memória 130. A lógica de processamento de metadados 132 pode instruir o proces-sador 129 para, então, analisar gramaticalmente a mensagem de metadados (1504). Por exemplo, a lógica de processamento de metadados 132 pode analisar gramaticalmente uma mensagem de metadados para a obtenção de uma informação de identificação de elemento, uma informação de identificação de GAP, dados de notação e outros metadados. A lógica de processamento de metadados 132 então pode manter registros de metadados com base na informação extraída a partir da mensagem de metadados analisada gramaticalmente (1506). A manutenção de registros de metadados pode incluir a leitura, a escrita, o armazenamento, a cópia, a atualização, o movimento, o apagamento, a sobrescrita, a anexação em apenso ou a manipulação de outra forma dos dados dentro dos registros de metadados. A lógica de processamento de metadados 132 então pode checar se quaisquer mensagens a mais estão disponíveis para processamento (1508). Se mais mensagens estiverem disponíveis, a lógica de processamento de metadados 132 então pode circular de volta e obter a próxima mensagem de metadados (1502). Se não houver mais mensagens disponíveis, então, a lógica de processamento de metadados 132 poderá terminar.

A Figura 16 mostra um fluxograma 700 de processamento de tipo que pode ser realizado pela lógica de processamento de tipo 1218. A lógica de processamento de tipo 1218 primeiramente pode obter uma mensagem de especificação de tipo (1602). A mensagem de especificação de tipo pode estar no formato de exemplo mostrado para a mensagem de especificação de tipo de elemento de GUI 424. A lógica de processamento de tipo 1218 então pode extrair um alias de GAP a partir da mensagem de especificação de tipo (1604). O alias de GAP pode ser delimitado em uma declaração de XML, conforme ilustrado pelo alias de GAP 430. A lógica de processamento de tipo 1218 então pode extrair um identificador de elemento de GUI a partir da mensagem de especificação de tipo (1606). O identificador de elemento de GUI pode ser delimitado em uma declaração de XML, conforme ilustrado pelo identificador de elemento de GUI 432. A lógica de processamento de tipo 1218 então pode extrair um identificador de tipo de GUI a partir da mensagem de especificação de tipo (1608). O identificador de tipode GUI pode ser delimitado em uma declaração em XML, conforme ilustrado pelo identificador de tipo de GUI 434.

A lógica de processamento de tipo 1218 então pode determinar se um registro de metadados de tipo correspondente ao alias de GAP e ao identificador de elemento de GUI já existe (1610). Se um registro de metadados de tipo já existir para o alias de GAP e para o identificador de elemento de GUI, então, a lógica de processamento de tipo 1218 armazenará o i-dentificador de tipo de GUI no registro de metadados de tipo (1612). A lógica de processamento de tipo 1218 pode armazenar o identificador de tipo de GUI ao sobrescrever um identificador de tipo de GUI já existente ou armazenando o identificador de tipo de GUI em um campo de identificador de tipo de GUI em branco. Além disso, a lógica de processamento de tipo 1218 pode exibir um alerta de requisição de confirmação, antes de sobrescrever um identificador existente, ou pode empregar qualquer outra técnica de resolução de conflito antes de armazenar ou sobrescrever dados. Se um registro de metadados de tipo não existir ainda para o alias de GAP e o identificador de elemento de GUI, então, a lógica de processamento de tipo 1218 poderá criar um registro de metadados de tipo para o alias de GAP e o identificador de elemento de GUI (1614). A lógica de processamento de tipo 1218 então pode armazenar o identificador de tipo de GUI no registro de metadados de tipo (1612).

A Figura 17 mostra uma primeira parte de um fluxograma 800 de processamento de mapeamento que pode ser realizado pela lógica de processamento de mapeamento 1220. A lógica de processamento de mapeamento 1220 primeiramente pode obter uma mensagem de especificação de mapeamento (1702). A mensagem de especificação de mapeamento pode ser no formato de exemplo mostrado para a mensagem de mapeamento de versão de elemento de GUI 822. A lógica de processamento de mapeamento 1220 então pode extrair um alias de GAP de origem a partir da mensagem de especificação de mapeamento (1704). O alias de GAP de origem pode ser delimitado em uma declaração de XML, conforme ilustrado pelo alias de GAP de origem 828. A lógica de processamento de mapeamento 1220 entãopode extrair um alias de GAP de destino a partir da mensagem de especificação de mapeamento (1706). O alias de GAP de destino pode ser delimitado em uma declaração em XML, conforme ilustrado pelo alias de GAP de destino 832. A lógica de processamento de mapeamento 1220 então pode extrair um identificador de elemento de GUI de origem a partir da mensagem de especificação de mapeamento (1708). O identificador de elemento de GUI de origem pode ser delimitado em uma declaração em XML, conforme ilustrado pelo identificador de elemento de GUI de origem 830. A lógica de processamento de mapeamento 1220 então pode extrair um identificador de elemento de GUI de destino a partir da mensagem de especificação de mapeamento (1710). O identificador de elemento de GUI de destino pode ser delimitado em uma declaração de XML, conforme ilustrado pelo identificador de elemento de GUI de destino 834. A lógica de processamento de mapeamento 1220 então pode extrair um valor de confiança a partir da mensagem de especificação de mapeamento (1712). O valor de confiança pode ser delimitado em uma declaração em XML, conforme ilustrado pelo valor de confiança 836.

A Figura 18 mostra uma segunda parte de um fluxograma 18000 de processamento de mapeamento que pode ser realizado pela lógica de processamento de mapeamento 1220. A lógica de processamento de mapeamento 1220 pode decidir qual registro de metadados de mapeamento atualizar (1802). A decisão pode ser com base em regulagens pré-existentes ou padronizadas. De forma alternativa ou adicional, a decisão pode ser com base em uma instrução de mapeamento recebida a partir de um usuário, em resposta a um alerta de instrução. Se a instrução de mapeamento especificar uma atualização do registro de mapeamento de versão de elemento de GUI, então, a lógica de processamento de mapeamento 1220 poderá criar um mapeamento de versão de GUI (1804). O mapeamento de versão de GUI pode ser delimitado em uma declaração de XML, conforme ilustradopelo mapeamento de versão 812. A lógica de processamento de mapeamento 1220 então pode armazenar o mapeamento de versão de GUI (1806). Por exemplo, o mapeamento de versão de GUI pode ser armazenado no registrode mapeamento de versão de elemento de GUI 1308.

Se a instrução de mapeamento especificar uma atualização dos registros de metadados de elemento de GUI, então, a lógica de processamento de mapeamento 1220 poderá localizar um registro de metadados de GAP de destino em um depósito de metadados (1808). O depósito de metadados pode ser o depósito de metadados 138. O registro de metadados de GAP de origem pode estar no formato de exemplo mostrado para o registro de metadados de GAP 0 1302. O registro de metadados de GAP de origem pode ser localizado por uma comparação do alias de GAP de fonte extraído a partir da mensagem de especificação de mapeamento (1704) com um i-dentificador de GAP, tal como o identificador de GAP 0 1310. A lógica de processamento de mapeamento 1220 então pode armazenar o identificador de elemento de GUI de destino (1810). Por exemplo, o identificador de elemento de GUI de destino pode ser armazenado no campo de mapeamento de elemento de GUI 1330. De forma alternativa ou adicional, o nível de confiança pode ser armazenado. Por exemplo, o nível de confiança pode ser armazenado no campo de outros metadados 1332. A lógica de processamento de mapeamento 1220 então pode localizar um registro de GUI de destino (1812). O registro de metadados de GAP de destino pode ser similar ao registro de metadados de GAP 1 1304. O registro de metadados de GAP de destino pode ser localizado por uma comparação do alias de GAP de destino extraído a partir da mensagem de especificação de mapeamento (1706) com um identificador de GAP, tal como o identificador de GAP 1 1312. A lógica de processamento de mapeamento 1220 então pode armazenar o identificador de elemento de GUI de origem (1814). Por exemplo, o identificador de elemento de GUI de origem pode ser armazenado no campo de mapeamento de elemento de GUI 1330. De forma alternativa ou adicional, o nível de confiança pode ser armazenado. Por exemplo, o nível de confiança pode ser armazenado no campo de outros metadados 1332. A lógica de processamento de mapeamento 1330 então pode terminar. Estas etapas não precisam ser realizadas em qualquer ordem em particular. Algumas etapas podem ser adicionadas ou removidas sem se afetarem os objetivos doprocesso.

Se a instrução de mapeamento especificar uma atualização dos registros de metadados de elemento de GUI e dos registros de mapeamento de versão de GUI, então, a lógica de processamento de mapeamento 1220 primeiramente poderá localizar um registro de metadados de GAP de origem em um depósito de metadados (1816). A lógica de processamento de mapeamento 1220 então pode armazenar o identificador de elemento de GUI de destino e/ou o nível de confiança (1818). A lógica de processamento de mapeamento 1220 então pode localizar um registro de metadados de GUI de destino (1820). A lógica de processamento de mapeamento 1220 então pode armazenar o identificador de elemento de GUI de origem e/ou o nível de confiança (1822). A lógica de processamento de mapeamento 1220 então pode criar um mapeamento de versão de GUI (1824). A lógica de processamento de mapeamento 1220 então pode armazenar o mapeamento de versão de GUI nos registros de mapeamento de versão de GUI (1826). A lógica de processamento de mapeamento 1220 então pode terminar. Estas etapas não precisam ser realizadas em qualquer ordem em particular. Algumas etapas podem ser adicionadas ou removidas, sem se afetarem os objetivos do processo.

A Figura 19 mostra um fluxograma 1900 de processamento de notação que pode ser realizado pela lógica de processamento de notação 1222. A lógica de processamento de notação 1222 primeiramente pode obter uma mensagem de notação (1902). A mensagem de notação pode estar no formato mostrado para a mensagem de notação de elemento de GUI 1424. A lógica de processamento de notação 1222 então pode extrair um alias de GAP a partir da mensagem de notação (1904). O alias de GAP pode ser delimitado em uma declaração de XML, conforme ilustrado pelo alias de GAP 1430. A lógica de processamento de notação 1222 então pode extrair um identificador de elemento de GUI a partir da mensagem de notação (1906). O identificador de elemento de GUI pode ser delimitado em uma declaração de XML, conforme ilustrado pelo identificador de elemento de GUI 1432. A lógica de processamento de notação 1222 então pode extrair umanotação de GUI a partir da mensagem de notação (1908). A notação de GUI pode ser delimitada em uma declaração de XML, conforme ilustrado pela notação de GUI 1434.

A lógica de processamento de notação 1222 então pode determinar se já existe um registro de metadados de notação correspondente ao alias de GAP e ao identificador de elemento de GUI extraídos a partir da mensagem de notação (1910). Se o registro de metadados de notação já existir para o alias de GAP e o identificador de elemento de GUI, então, a lógica de processamento de notação 1222 poderá armazenar a notação de GUI no registro de metadados de notação (1912), antes da terminação. A lógica de processamento de notação 1222 pode armazenar a notação de GUI ao sobrescrever uma notação de GUI existente, armazenando a notação de GUI em um campo de notação de GUI em branco, exibindo um alerta antes de sobrescrever uma notação existente, colocando em apenso a notação com uma notação existente, ou usando qualquer outra forma adequada de resolução de conflitos antes do armazenamento de dados. Se um registro de metadados de notação ainda não existir para o alias de GAP e o identificador de elemento de GUI, então, a lógica de processamento de notação 1222 poderá criar um registro de metadados de notação para o alias de GAP e o identificador de elemento de GUI (1914). A lógica de processamento de notação 1222 então pode armazenar a notação de GUI no registro de metadados de notação (1912), antes da terminação.

A Figura 20 mostra um fluxograma 2000 de processamento de migração de metadados que a lógica de migração de metadados 1224 pode realizar. A lógica de migração de metadados 1224 pode localizar um registro de metadados de origem (2002). A lógica de migração de metadados 1224 então pode localizar um registro de metadados de destino (2004). A lógica de migração de metadados 1224 então pode identificar metadados órfãos (2006). Os metadados órfãos incluem metadados armazenados em um registro de metadados de elemento de GUI em que os metadados também não são armazenados em um outro registro de metadados de elemento de GUI para o qual o primeiro registro de metadados de elemento de GUI émapeado. De forma alternativa ou adicional, os metadados órfãos podem incluir metadados associados a um elemento de GUI em que o elemento de GUI não tem um mapeamento para um outro elemento de GUI. A lógica de migração de metadados 1224 então pode migrar para quaisquer metadados órfãos (2008). A migração pode ocorrer automaticamente. De forma alternativa ou adicional, a migração pode ocorrer após a exibição de uma mensagem de alerta. Se mais mensagens de origem estiverem disponíveis (2010), a lógica de migração de metadados 1224 poderá então circular de volta e obter o próprio registro de origem (2002). Se não houver mais registros de origem disponíveis (2010), então, a lógica de migração de metadados 1224 poderá cessar.

A Figura 21 mostra um fluxograma 2100 de processamento de migração de metadados que pode ser realizada pela lógica de migração de metadados 1224. A lógica de migração de metadados 1224 pode executar, por exemplo, o processamento durante um processo de mapeamento, tais com os processos de mapeamento 800 e 1800. Este processamento de migração de metadados pode ajudar no movimento de todos os metadados existentes ou quaisquer metadados despercebidos de um GAP para um outro ou de uma versão de GAP para uma outra.

A lógica de migração de metadados 1224 primeiramente pode determinar se o elemento de GUI de origem tem metadados associados a ele (2102). Por exemplo, a lógica de migração de metadados 1224 pode u-sar um alias de GAP de origem e um identificador de elemento de GUI de origem para a localização de um registro de metadados de elemento de GUI de origem. Então, a lógica de migração de metadados 1224 pode buscar dentro daquele registro de metadados de elemento de GUI de origem quanto a quaisquer campos de metadados relevantes, tal como um campo de tipo 1326, um campo de notação 1328 ou campo de outros metadados 1332. Se a lógica de migração de metadados 1224 determinar que o elemento de GUI de origem não tem metadados relevantes associados a ele, a lógica de migração de metadados 1224 então poderá determinar se o elemento de GUI de destino tem metadados associados a ele (2104). Esta determinação podeser realizada de uma maneira similar a se determinar se o elemento de GUI de origem tinha metadados associados a ele (2102). Se a lógica de migração de metadados 1224 determinar que o elemento de GUI de destino não tem metadados relevantes associados a ele, a lógica poderá terminar.

Se a lógica de migração de metadados 1224 determinar que o elemento de GUI de origem tem metadados associados a ele, a lógica de migração de metadados 1224 determinará se um elemento de GUI de destino tem metadados associados a ele (2106). Esta determinação pode ser realizada de uma maneira similar a determinar se o elemento de GUI de origem tinha metadados associados a ele (2102). Se a lógica de migração de metadados 1224 determinar que o elemento de GUI de destino não tem metadados associados a ele, a lógica de migração de metadados 1224 poderá prover um alerta para o processamento adicional de instruções (2108). O alerta pode pedir instruções quanto a se é para copiar metadados a partir do elemento de GUI com metadados para o registro de elemento de GUI sem os metadados (2110). Se a resposta ao alerta for 'não', então a lógica poderá terminar. Se a resposta ao alerta for 'sim', então a lógica poderá realizar o processo de cópia (2112), antes de terminar. Um processo similar ocorre quando um elemento de GUI de origem não tem metadados, mas um elemento de GUI de destino tem.

Se a lógica de migração de metadados 1224 determinar que um elemento de GUI de origem e um elemento de GUI de destino têm, cada um, metadados associados a eles, a lógica de migração de metadados 1224 poderá prover um alerta para o processamento adicional de instruções (2114).

Por exemplo, o alerta pode incluir opções para Sobrescrever um dos conjuntos de metadados com um outro, Apensar um conjunto de metadados com o outro (ou, opcionalmente, apensar cada conjunto de metadados ao outro), ou Mover um conjunto de metadados para um registro de metadados de elemento de GUI completamente diferente (2116). Se a resposta ao alertaincluir Sobrescrever um dos conjuntos de metadados com o outro, então, a lógica de migração de metadados 1224 poderá realizar o processo de so-brescrita (2118), antes de terminar. Se a resposta ao alerta incluir Apensarum conjunto de metadados ao outro, então, a lógica de migração de metadados 1224 poderá realizar o processo de apensar (2120), antes de terminar. Se a resposta ao alerta incluir Mover um conjunto de metadados ao outro, então, a lógica de migração de metadados 1224 poderá realizar o processo de mover (2120), antes de terminar. De forma alternativa ou adicional, a lógica de migração de metadados 1224 pode realizar o processo de mover (2122) e, então, prover um outro alerta para uma ação continuada, tal como copiar um conjunto de metadados no registro de metadados deixado vago pelo processo de mover, de modo similar ao alerta de copiar (2110).

A Figura 22 mostra um fluxograma 2200 de processamento de migração de metadados que pode ser realizado pela lógica de migração de metadados 1224. A lógica de migração de metadados 1224 pode primeiramente buscar elementos de GUI que tenham metadados associados a eles (2202). Por exemplo, esta busca pode ser realizada pelo acesso a um registro de metadados de GAP ou de versão de GAP e acessando-se cada registro de metadados de elemento de GUI armazenado naquele registro. De forma alternativa ou adicional, a lógica de migração de metadados 1224 pode consultar uma lista de GAPs ou de versões de GAP juntamente com os identificadores de elemento de GUI associados e acessar os registros de metadados de elemento de GUI para cada um dos identificadores de elemento de GUI individualmente. De forma alternativa ou adicional, a lógica de migração de metadados 1224 pode realizar uma técnica de busca primeiro em profundidade, busca primeiro em largura ou outra técnica de busca para se acessarem todos os registros de metadados de elemento de GUI em um depósito de metadados. Uma vez que a lógica de migração de metadados 1224 tenha adquirido um elemento de GUI, ela pode determinar se o elemento de GUI tem metadados apropriados de uma maneira similar a determinar se o elemento de GUI de origem tem metadados associados a ele (2102).

Uma vez que a lógica de migração de metadados 1224 tenha identificado um elemento de GUI com metadados associados a ele, a lógica de metadados 1224 pode determinar se o elemento de GUI tem um mapea-mento associado a ele (2204). Por exemplo, esta determinação pode incluir olhar para o campo de mapeamento de elemento de GU11330 no registro de metadados de elemento de GUI. De forma alternativa ou adicional, a determinação pode ter sido feita por um outro processo lógico com o resultado a partir da lógica de migração de metadados 1224 passado juntamente com a identificação do elemento de GUI.

Se a lógica de migração de metadados 1224 determinar que o elemento de GUI tem um mapeamento associado, a lógica de migração de metadados 1224 poderá assumir que um outro processo de lógica de migração de metadados, tal como o processo de lógica 2100, já migrou quaisquer metadados relevantes e, assim, em seguida determinará se o elemento de GUI foi o último elemento que precisou ser checado quanto a uma migração de metadados (2206). Esta determinação pode incluir olhar para o próximo GAP ou versão de GAP e o identificador de elemento de GUI associado em uma lista. De forma alternativa ou adicional, a determinação pode incluir o-Ihar para o próximo registro de metadados de elemento de GUI criado em um algoritmo de busca primeiro em profundidade, primeiro em largura ou outro apropriado. Se a lógica de migração de metadados 1224 determinar que o elemento de GUI foi o último elemento de GUI a processar, então, a lógica de migração de metadados 1224 poderá terminar.

Se a lógica de migração de metadados 1224 determinar que o elemento de GUI não foi o último elemento de GUI a ser processado, a lógica de migração de metadados 1224 poderá se mover para o próximo elemento de GUI (2208). Este movimento pode incluir acessar o próximo GAP ou versão de GAP e o identificador de elemento de GUI associado em uma lista. De forma alternativa ou adicional, o movimento pode incluir acessar o próximo registro de metadados de elemento de GUI criado em um algoritmo de busca primeiro em profundidade, primeiro em largura ou outro apropriado. Após o movimento, a lógica de migração de metadados 1224 pode circular de volta e determinar se o novo elemento de GUI tem um mapeamento associado a ele (2204).

Se a lógica de migração de metadados 1224 determinar que umelemento de GUI não tem um mapeamento associado a ele, então, a lógica de migração de metadados 1224 poderá prover um alerta por instruções adicionais (2210). O alerta pode requisitar instruções adicionais quanto a se é para mapear o elemento de GUI para um outro elemento de GUI (2212). Se a resposta ao alerta incluir um 'sim', então, a lógica de migração de metadados 1224 poderá ativar uma lógica de processamento de mapeamento 1220 e terminar (2214). De forma alternativa ou adicional, a lógica de migração de metadados 1224 pode ativar uma lógica de processamento de mapeamento 1220 e um processamento de migração de metadados 2100, antes de terminar.

Se a resposta ao alerta 1312 incluir um 'não', então, a lógica de migração de metadados 1224 poderá determinar se o elemento de GUI foi o último elemento que precisava ser checado quanto a uma migração de metadados (2216), de modo similar à checagem 2206. SE a lógica de migração de metadados 1224 determinar que o elemento de GUI foi o último elemento de GUI a processar, então, a lógica de migração de metadados 1224 poderá terminar. Se a lógica de migração de metadados 1224 determinar que o e-lemento de GUI não foi o último elemento de GUI a ser processado, a lógica de migração de metadados 1224 poderá se mover para o próximo elemento de GUI (2208).

A Figura 1 mostra um sistema comparador de aplicativo de interface gráfica de usuário (GUI) ("sistema") 106. O sistema 106 pode incluir um construtor de modelo de GUI 154 e um comparador de GUI 160. O construtor de modelo de GUI 154 pode aceitar uma versão 'n' de aplicativo de GUI (GAP) ("Vn de GAP") 150 e criar um modelo de GUI de Vn de GAP 156. O construtor de modelo de GUI 154 também pode aceitar uma versão de GAP •n+1' ("Vn+1 de GAP") 152 e criar um modelo de GUI de Vn+1 de GAP 158. O comparador de GUI 160 pode aceitar o modelo de GUI de Vn de GAP 156 e o modelo de GUI de Vn+1 de GAP 158, bem como uma informação recebida através da lógica de comunicação 163 para a criação de um modelo de diferença de GUI 162. O modelo de diferença de GUI 162 pode ser enviado para outros sistemas através da lógica de comunicação 163. Os modelos deGUI de GAP 156 e 158 podem ter uma estrutura plana, de árvore, hierárquica, aninhada ou outro tipo de estrutura. A Vn de GAP 150 pode ser uma versão atual de um GAP em particular, enquanto a Vn+1 de GAP 152 pode ser uma versão subsequente de GAP. O modelo de GUI de Vn de GAP 156 pode prover uma representação da estrutura de GUI da versão de GAP atual, enquanto o modelo de GUI de Vn+1 de GAP 158 pode prover uma representação da estrutura de GUI da versão de GAP subsequente.

A Figura 23 mostra uma implementação do sistema comparador de aplicativo de GUI 106. O sistema 106 pode incluir um processador 2302, uma memória 2304 e um visor 2306. O sistema 106 pode trocar uma informação com outros sistemas, tal como um depósito de dados de elemento de GUI ("depósito") 138, um analisador de script 170 e uma rede 2314 através de uma lógica de comunicação 163. A lógica de comunicação 163 pode ser uma interface com fio/ sem fio, um mecanismo de comunicação interprocesso, uma memória compartilhada, uma interface de serviços da web, ou quaisquer outros tipos de interface de comunicação. O depósito 138 pode incluir os mapeamentos de elemento de GUI de GAP 1308. A rede 2314 pode se conectar a terminais locais ou remotos 2318, para uma interação de operador local ou remoto com o sistema 106, a outros processos rondando em outras máquinas ou a outras entidades que interajam com o sistema 106.

A memória 2304 pode incluir uma lógica de construtor de modelo de GUI 2320. A lógica de construtor de modelo de GUI 2320 pode se comunicar com um proxy 2322. O proxy 2322 pode ser armazenado na memória 2304 e acessar uma tabela de GAP 2324. O proxy 2322 pode se comunicar com GAPs, tal como uma versão de GAP atual 2326 e uma versão de GAP subsequente 2328. A versão de GAP atual 2326 e a versão de GAP subsequente 2328 já podem residir na memória 2304. De forma alternativa ou adicional, o sistema 106 pode requisitar e receber a versão de GAP atual 2326 e a versão de GAP subsequente 2328 através da lógica de comunicação 163, mediante o que a versão de GAP atual 2326 e a versão de GAP subsequente 2328 podem ser armazenadas na memória 2304.

O proxy 2322 pode incluir uma lógica que insere os ganchos2330 e 2332 em um espaço de processo dos GAPs 2326 e 2328. O proxy 2322 pode se comunicar com os ganchos 2330 e 2332. Em particular, o proxy 2322 pode trocar mensagens com os ganchos 2330 e 2332 para a obtenção do estado de qualquer um ou de todos os elementos de GUI nos GAPs 2326 e 2328. Os ganchos 2330 e 2332 podem ser programas que respondem a mensagens a partir do proxy 2322 e podem interagir através de uma camada de acessibilidade 2334 de um sistema operacional 2336 para a descoberta e o relatório de uma informação sobre os elementos de GUI nos GAPs 2326 e 2328 para o proxy. A camada de acessibilidade 2334 pode expor uma interface de acessibilidade através da qual o proxy 2322 e os ganchos 2330 e 2332 podem invocar métodos e regular e recuperar valores e características de elementos de GUI e, desse modo, selecionar, destacar, controlar, modificar, atribuir identificadores para ou interagir de outra forma com os elementos de GUI nos GAPs.

A camada Microsoft (TM) Active Accessibility (MSAA) é um exemplo de uma camada de acessibilidade adequada. Nesse sentido, os GAPs 2326 e 2328 expõem as interfaces de acessibilidade que exportam métodos para acesso e manipulação das propriedades e do comportamento de elementos de GUI. Por exemplo, os GAPs 2326 e 2328 podem empregar a interface lAccessible para se permitirem acesso e controle em relação ao elemento de GUI usando chamadas de interface de programação de aplicativo (API) de MSAA. A interface lAccessible ainda facilita aplicativos para exposição de uma árvore de nós de dados que constituem cada janela na interface de usuário com a qual se interage atualmente. A lógica de construtor de modelo de GUI 2320 e o proxy 2322 podem incluir, então, declarações de programa para acesso e controle do elemento de GUI, como se o elemento de GUI fosse um objeto de programação convencional. As chamadas de API de acessibilidade podem incluir: realizar ações em objetos, obter valores de objetos, regular valores em objetos, navegar para objetos, e regular propriedades em objetos, e outras chamadas.

O proxy 2322 pode ser um programa daemon e pode começar antes da lógica de construtor de modelo de GUI 2320. O proxy 2322 podeestar ciente de um ou mais GAPs. Quando o proxy 2322 começa, ele carrega a tabela de GAP 1106, a qual pode incluir um conjunto predefinido de entradas de GAP quanto às quais o proxy 2322 está ciente. Uma entrada de GAP pode assumir a forma:

<Alias, <FileO, PathO, DirO, Commandl_ineO>,

<File1, Pathl, Dir1, Commandünel»

onde Alias é um nome predefinido único para o GAP (por exemplo, um nome genérico para a versão de GAP atual 2326 e a versão de GAP subsequente 2328), FileO é o nome do programa executável para a versão de GAP atual 2326, PathO é o caminho absoluto para FileO, DirO é o caminho absoluto para o diretório a partir do qual FileO deve ser executado, e CommandLine especifica os argumentos de linha de comando para FileO. Filei, Pathl, Dir1 e CommandLinel provêem parâmetros similares para a versão de GAP subsequente 2328.

Quando a lógica de construtor de modelo de GUI 2320 começa, ela pode se conectar ao proxy 2322. Uma vez conectada, a lógica de construtor de modelo de GUI 2320 requisita a tabela de GAP 2324 ao enviar uma mensagem de requisição de tabela de GAP para o proxy 2322. O proxy 2322 pode responder pelo envio de uma mensagem de resposta de tabela de GAP incluindo a tabela de GAP 2324 para a lógica de construtor de modelo de GUI 2320. Uma troca de mensagem de exemplo é mostrada na Tabela 4:

Tabela 4

<table>table see original document page 53</column></row><table>ver uma lista de GAPs a partir da qual um operador pode escolher. O operador pode acessar o sistema 106 localmente através do visor 2306 ou remotamente, por exemplo, através do terminal 2318. A lógica de construtor de modelo de GUI 2320 então pode criar uma mensagem de carregar GAP, por exemplo, <LoadGap Alias="name7> e enviar a mensagem de carregar GAP para o proxy 2322 para se começar qualquer GAP selecionado (o qual então pode exibir sua interface de usuário). Uma mensagem de carregar GAP pode fazer com que o proxy 2322 comece múltiplas versões de um GAP identificado em conjunto com a tabela de GAP 2324 na seção de <GAP>.

Após começar os GAPs, o proxy 2322 pode injetar ganchos no espaço de processo de GAPs. O gancho pode se conectar ao proxy 2322 e enviar uma mensagem de confirmação (por exemplo, <GAP File="gap.exe" lnstance="1927>). O proxy 2322 pode enviar uma mensagem de sucesso (por exemplo, <Loaded Alias="name" VN="192" VN1="193"/>) para a lógica de construtor de modelo de GUI 2320, desse modo reconhecendo que os GAPs foram começados de forma bem-sucedida.

A lógica de construtor de modelo de GUI 2320 pode requisitar o estado atual de cada GAP começado. Nesse sentido, a lógica de construtor de modelo de GUI 2320 pode enviar uma mensagem de requisição de estado (por exemplo, <GetState Alias="name"/>) para o proxy 2322. Por sua vez, o proxy 2322 pode localizar a conexão com os ganchos correspondentes dos GAPs e enviar uma mensagem de requisição de estado (por exemplo, <GetState/>) para os ganchos. Os ganchos podem criar um estado de GAP (incluindo identificadores únicos para os elementos de GUI), tal como uma árvore de estado, codificá-lo (por exemplo, em um formato em XML), e o enviar para o proxy 2322. O proxy 2322 pode encaminhar o estado de GAP para a lógica de construtor de modelo de GUI 2320. Uma mensagem de estado de GAP de exemplo enviada pelo proxy 2322 é mostrada na Tabela 5.<table>table see original document page 55</column></row><table>

O estado de GAP contém uma informação sobre os elementos de GUI compondo uma dada tela, bem como os valores destes elementos e seus identificadores atribuídos. O estado de GAP especifica os elementos de GUI de GAP e os valores dos elementos de GUI. Em uma implementação, o estado de GAP é refletido em uma estrutura de linguagem de marcação extensível (XML), onde o elemento 'State' tem um ou mais elementos filhos 'GAP', cujos elementos filhos por sua vez são 'GUIEIements'. Por exemplo, os elementos de GUI podem ser containeres ou básicos. Os elementos de GUI de container contêm outros elementos, enquanto os elementos básicos não contêm outros elementos. A estrutura de XML reflete a hierarquia de contenção ao permitir que os GUIEIements contenham outros GUIEIements.

Na estrutura de XML, o atributo SeqNumber pode designar um número de seqüência único do estado dentro do GAP. Uma vez que os estados são mapeados para telas de GUI, a cada estado pode ser dado um nome o qual é especificado pelo atributo 'Name'. Os atributos Alias e Pro-cessID podem denotar o alias do GAP e seu identificador de processo de instância, respectivamente. O identificador de processo de instância pode diferenciar entre a versão de GAP atual e a versão de GAP subsequente.A lógica de construtor de modelo de GUI 2320 pode construir modelos de GUI de GAP com base em mensagens de estado de GAP recebidas a partir do proxy 2322. Por exemplo, a lógica de construtor de modelo de GUI 2320 pode construir um modelo de GUI de Vn de GAP 2338 a partir de mensagens de estado de GAP referentes à versão de GAP atual 2326. De modo similar, a lógica de construtor de modelo de GUI 2320 pode construir um modelo de GUI de Vn+1 de GAP 2340 a partir de mensagens de estado de GAP referentes à versão de GAP subsequente 2328.

O processador 2302 pode invocar a lógica de comparação de GAP 2342 armazenada na memória 2304. A lógica de comparação de GAP 2342 pode comparar dois modelos de GUI de GAP, tais como os modelos de GUI de GAP 2338 e 2340 e produzir um modelo de diferença de GUI 2344. A lógica de comparação de GAP 2342 pode incluir uma lógica de recuperação de mapeamento 2346, uma lógica de travessia de representação 2348, uma lógica de análise ponderada 2350 e uma lógica de construção de combinação 2352.

A lógica de recuperação de mapeamento 2346 pode requisitar mapeamentos de elemento de GUI de GAP em particular a partir dos mapeamentos de elemento de GUI de GAP 1308 em um depósito de dados de elemento de GUI 138 e armazenar os mapeamentos de elemento de GUI de GAP em particular na memória 2304 como mapeamentos de versão de elemento de GUI 2354.

A lógica de travessia de representação 2348 pode atravessar um modelo de GUI de GAP, tal como o modelo de GUI de Vn de GAP 2338. Por exemplo, a lógica de travessia de representação 2348 pode determinar o próximo nó a visitar nos modelos de GUI de GAP 2338 e 2340. De forma alternativa ou adicional, a lógica de travessia de representação 2348 pode atravessar todo um ou partes de um modelo de diferença de GUI, tal como o modelo de diferença de GUI 2344. O próximo nó a visitar pode ser determinado, como exemplos, de forma de primeiro profundidade ou primeiro largura.

A lógica de análise ponderada 2350 pode usar os pesos caracte-rísticos de GUI 2356 obtidos a partir de uma tabela de peso 2358 para a determinação de um valor de similaridade entre um elemento de GUI em um primeiro modelo de GUI de GAP, tal como o modelo de GUI de Vn de GAP 2338, e cada elemento de GUI em um segundo modelo de GUI de GAP, tal como o modelo de GUI de Vn+1 de GAP 2340. Pesos característicos de GUI diferentes 2356 podem ser atribuídos às similaridades ou diferenças entre características de elemento de GUI diferentes 2360 ou propriedades, que podem estar presentes ou ausentes entre os elementos de GUI nos dois modelos de GUI de GAP. As características de elemento de GUI 2360 podem incluir características de elemento de GUI tais como tamanho, posição XY, cor, posição de janela, tipo de fonte, tamanho de fonte, estilo de borda, cor de fundo, cor de primeiro plano, apenas de leitura / apenas de escrita ou qualquer outra característica de elemento de GUI. De forma alternativa ou adicional, as características de elemento de GUI 2360 podem incluir um Papel de camada de acessibilidade, Classe, Estilo, Estilo Estendido, número de filhos, nível em uma árvore ou hierarquia, Nome do elemento de GUI, ou outras propriedades atribuídas a uma camada de acessibilidade. A tabela de peso também pode incluir notas 2362 associadas aos pesos 2356 atribuídos às características de GUI 2360 que podem explicar o raciocínio por trás de cada valor de peso.

A lógica de análise ponderada 2350 pode armazenar um escore 2364 em uma tabela de escore 2366 com base em cada valor de similaridade gerado pela lógica de análise ponderada 2350. Cada escore 2364 na tabela de escore 2366 pode corresponder a um identificador de origem 2368 e um identificador de destino 2370. O identificador de origem 2368 e o identificador de destino 2370 podem ser um valor único ou uma combinação de valores (por exemplo, incluindo aliases de GAP) identificando os GAPs e os elementos de GUI que a lógica de análise ponderada 2350 comparou para o cálculo de cada escore 2364.

A lógica de construção de combinação 2352 pode comparar os valores de similaridade gerados pela lógica de análise ponderada 2350 e/ou os escores 2364 armazenados na tabela de escore 2366 em relação a umlimite de similaridade 2372. Esta comparação pode determinar se dois elementos de GUI são suficientemente similares para serem considerados uma combinação de uma versão de GAP atual para a versão de GAP subsequente. A lógica de construção de combinação 2352 pode criar um link entre os elementos de GUI combinando no modelo de diferença de GUI 2344. O link pode ser armazenado na representação de elemento de GUI dentro do modelo de diferença de GUI 2344 como um link de elemento de GUI 2374 com um escore de combinação correspondente opcional 2376. O link de elemento de GUI pode compreender um identificador de um segundo elemento de GUI 2377. O identificador pode ser o identificador de origem 2368, o identificador de destino 2370, ou ambos.

Em operação, a lógica de comparação de GAP 2342 pode obter os modelos de GUI de GAP 2338 e 2340 pela recuperação deles a partir da memória 2304, ao chamar a lógica de construtor de modelo de GUI 2320 ou de uma outra maneira. A lógica de comparação de GAP 2342 pode criar um modelo de diferença de GUI de base como um nó de raiz a partir do qual os modelos de GUI de GAP 2338 e 2340 descem em ramificações diferentes a partir da raiz. A lógica de comparação de GAP 2342 então pode determinar o próximo nó a visitar em cada um dos modelos de GUI de GAP usando-se a lógica de travessia de representação 2348.

A lógica de comparação de GAP 2342 pode iniciar a execução da lógica de recuperação de mapeamento 2346 para a obtenção dos mapeamentos de versão de elemento de GUI disponíveis a partir de fontes externas, tal como o depósito de metadados 138. A lógica de comparação de GAP 2342 pode requisitar todos os mapeamentos de versão de elemento de GUI disponíveis, ou pode requisitar especificamente mapeamentos de versão de elemento de GUI para o próximo nó no modelo de GUI de GAP atual. Se um mapeamento de versão de elemento de GUI estiver disponível para o próximo nó no modelo de GUI de GAP atual, a lógica de comparação de GAP 2342 pode abrir mão da execução da lógica de análise ponderada 2350. Ao invés disso, a lógica de comparação de GAP 2342 pode empregar a lógica de construção de combinação para escrever um link de elemento deGUI para o modelo de diferença de GUI de base. Como uma outra alternativa, quando um mapeamento de versão de elemento de GUI está disponível, a lógica de comparação de GAP 2342 pode criar uma entrada correspondente na tabela de escore 2366, com base na informação disponível no mapeamento de versão de elemento de GUI.

Contudo, a lógica de comparação de GAP 2342 não precisa a-brir mão da análise ponderada, quando existir um mapeamento de versão de elemento de GUI. Ao invés disso, a lógica de comparação de GAP 2342 pode decidir quando prosseguir com o mapeamento ponderado com base no nível de confiança provido no mapeamento de versão de elemento de GUI. Por exemplo, quando o nível de confiança excede a um limite de confiança, a lógica de comparação de GAP 2342 pode abrir mão da execução da análise ponderada. Como um outro exemplo, quando o nível de confiança especifica um mapeamento manual, a lógica de comparação de GAP 2342 pode abrir mão da execução da análise ponderada.

A lógica de comparação de GAP 2342 usa a lógica de análise ponderada 2350 para determinar valores de similaridade entre cada elemento de GUI no modelo de GUI de GAP atual 2338 e cada elemento no modelo de GUI de GAP subsequente 2340. A lógica de análise ponderada 2350 é descrita em maiores detalhes abaixo. A lógica de análise ponderada registra os valores de similaridade na tabela de peso 2358 como escores. Os escores podem ser os valores de similaridade, valores de similaridade normalizados, ou baseadas de alguma outra forma nos valores de similaridade.

Tendo determinado os valores de similaridade, a lógica de comparação de GAP 2342 pode usar a lógica de construção de combinação 2352 para determinar se elementos de GUI combinam entre as versões de GAP. Para essa finalidade, a lógica de construção de combinação 2352 pode comparar os escores na tabela de escore em relação ao limite de similaridade 2372. Os elementos de GUI com escores que excedam ao limite de similaridade 2372 podem ser considerados combinações sob a hipótese de que quanto mais alto o escore de similaridade, mais provavelmente ele se referirá aos elementos de GUI correspondentes. A lógica de construção decombinação 2352 pode criar links de elemento de GUI no modelo de diferença de GUI de base quando combinações forem determinadas.

A Figura 24 mostra um exemplo de uma porção 2400 de um modelo de GUI de GAP atual. A porção 2400 usa uma representação em XML, mas qualquer outra representação pode ser usada, ao invés disso. A porção 2400 inclui um alias de GAP 2402 ("University DirectoryO"), um identificador de elemento de GUI 2404 ("0x90b52"), e características de GUI 2406. As características de GUI 2406 incluem uma localização com um valor x de "173", um valor y de "486", um valor de largura de "336" e um valor de comprimento de "274". Outras características de GUI 2406 incluem um valor de classe de "WindowsForms10.LISTBOX.app4", um valor de estilo de "0x560100c1" e um valor de estilo estendido de "OxcOOOOaOO".

A Figura 25 mostra um exemplo de uma porção correspondente 2500 de um modelo de GUI de GAP subsequente usando uma representação em XML. A porção correspondente 2500 inclui um alias de GAP 2302 ("University Directoryl"), um identificador de elemento de GUI 2504 ("0x90e66"), e características de GUI 2506. As características de GUI 2406 incluem uma localização com um valor x de "248", um valor y de "653", um valor de largura de "299" e um valor de comprimento de "24". Outras características de GUI 2506 incluem um valor de classe de "Windows-Forms10.COMBOBOX.app.0.378734a", um valor de estilo de "0x560100242" e um valor de estilo estendido de "0xc0000800".

O elemento de GUI com o identificador 2504 é uma versão modificada do elemento de GUI com o identificador 2404. Em outras palavras, quando o programador projetou a versão de GAP subsequente, o programador modificou o elemento de GUI com identificador 2404 para obter o elemento de GUI com identificador 2504. Em particular, as Figuras 24 e 25 mostram que as mudanças a seguir foram feitas: o estilo mudou de "0x560100c1" para "0x560100242" e o estilo estendido mudou de "OxcOOOOaOO" para "0xc0000800". Estas diferenças nas características de elemento de GUI não são prontamente discerníveis para programadores de script de teste. Contudo, outras mudanças podem ser discerníveis por umprogramador, tal como a mudança de classe de "Windows-Forms10.LISTBOX.app4" para "Windows-Forms10.COMBOBOX.app.0.378734a".

A Figura 26 mostra um exemplo de uma porção de diferença 2600 de um modelo de diferença de GUI. A porção de diferença 2600 pode incluir uma seção de versão atual 2602, incluindo uma informação de elemento de GUI retirada do modelo de GUI de GAP atual (por exemplo, partes de porção 2400) e uma seção de versão subsequente correspondente 2604, incluindo uma informação de elemento de GUI retirada do modelo de GUI de GAP subsequente (por exemplo, partes de porção correspondente 2500). As seções 2602 e 2064 podem ser separadas por um primeiro elemento de versão 2606 e um segundo elemento de versão 2608. Neste exemplo, o primeiro elemento de versão 2606 tem um valor de "0", enquanto o segundo elemento de versão 2608 tem um valor de "1". O valor de elemento de versão "0" pode indicar que a seção se originou de um modelo de GUI de GAP atual, onde o valor de elemento de versão "1" pode indicar que a seção se originou de um modelo de GUI de GAP subsequente.

O modelo de diferença de GUI 2344 pode ser em uma configuração plana, onde o modelo de diferença de GUI 2344 inclui uma seção única 2602 e uma seção correspondente única 2604. De forma alternativa ou adicional, o modelo de diferença de GUI 2344 pode estar em uma configuração de árvore, hierárquica ou aninhada, onde o modelo de diferença de GUI 2344 inclui múltiplas seções 2602 e múltiplas seções correspondentes 2604. Na configuração de árvore, hierárquica ou aninhada, elementos de GUI similares podem ser representados por um nó único. De forma alternativa ou adicional, elementos de GUI similares podem ser representados em nós separados. O modelo de diferença de GUI 2344 pode incluir todos os elementos de GUI de ambos os modelos de GUI de GAP. Alternativamente, o modelo de diferença de GUI 2344 pode incluir apenas os elementos do segundo modelo de GUI de GAP e as porções correspondentes do primeiro modelo de GUI de GAP. O modelo de diferença de GUI 2344 pode ser formado com base em um algoritmo de bissimulação, conforme descrito em maioresdetalhes abaixo.

A lógica de comparação de GAP 2342 pode criar a porção de diferença 2600 no formato apresentado na Figura 26, quando combinar o modelo de GUI de GAP de origem com o modelo de GUI de GAP de destino sob um nó de raiz. De forma alternativa ou adicional, a lógica de comparação de GAP 2342 pode criar a porção de diferença 2600 após a lógica de recuperação de mapeamento 2346 obter um mapeamento relevante entre o elemento de GUI representado na seção de versão atual 2602 e a seção de versão subsequente 2604. De forma alternativa ou adicional, a lógica de comparação de GAP 2342 pode criar a porção de diferença 2600 após a lógica de construção de combinação 2352 criar um link entre a seção de versão atual 2602 e a seção de versão subsequente 2604.

A Figura 27 mostra um fluxograma 2700 para a lógica de construtor de modelo de GUI 2320. A lógica de construtor de modelo de GUI 2320 pode exibir uma lista de GAPs para escolha pelo operador. Conforme citado acima, a lista de GAPs pode ser estabelecida na tabela de GAP 2324. A lógica de construtor de modelo de GUI 2320 monitora quanto a uma entrada de operador (2702) para a seleção de um GAP. A lógica de construtor de modelo de GUI 2320 desse modo determina uma versão de GAP selecionada (2704).

A lógica de construtor de modelo de GUI 2320 então pode criar uma mensagem de carregamento de GAP, por exemplo, <LoadGap Ali-as="name'7> e enviar a mensagem de carregamento de GAP para o proxy 2322 para começar a versão de GAP selecionada, a qual então pode exibir seu GUI (2706). Após o começo do GAP, o proxy 2322 pode injetar um gancho no espaço de processo de GAP (2708). O gancho pode se conectar ao proxy 2322 e enviar uma mensagem de confirmação (por exemplo, <GAP File="gap.exe" lnstance="1927>). O proxy 2322 pode enviar uma mensagem de sucesso (por exemplo, <Loaded Alias="name" VN="192" VN1="193'7>) para a lógica de construtor de modelo de GUI 2320, desse modo reconhecendo que o GAP foi começado de forma bem-sucedida.

A camada de acessibilidade, o proxy, o gancho e a lógica deconstrutor de modelo de GUI 2320 monitoram uma interação de operador com elementos de GUI na versão de GAP selecionada (2710). A lógica de construtor de modelo de GUI 2320 pode enviar uma mensagem de requisição de estado <GetState Alias="name"/>) para o proxy 2322 para obtenção da informação de elemento de GUI a partir do gancho (2712). Por sua vez, o proxy 2322 pode localizar a conexão com o gancho correspondente na versão de GAP selecionada e enviar uma mensagem de requisição de estado (por exemplo, <GetState/>) para o gancho. O ganho pode criar um estado de GAP (incluindo identificadores únicos para elementos de GUI), tal como uma árvore de estado, codificá-lo (Por exemplo, em um formato em XML), e enviá-lo para o proxy 2322. O proxy 2322 pode encaminhar o estado de GAP para a lógica de construtor de modelo de GUI 2320. A informação de elemento de GUI pode ser retornada para a lógica de construtor de modelo de GUI 2320 uma tela de uma vez, um elemento de GUI de uma vez, um aplicativo inteiro de uma vez, ou em alguma outra segmentação discreta do GAP.

A finalidade de monitoração da interação de operação com o GAP é permitir que a lógica de construtor de modelo de GUI 2320 registre as estruturas das telas e as ações de operador nos GAPs. A lógica de construtor de modelo de GUI 2320 intercepta eventos de operador usando a camada de acessibilidade. Através destes eventos, a lógica de construtor de modelo de GUI 2320 registra a seqüência de telas através do que o operador navega, bem como as ações que o operador realiza em elementos de GUI. Quando registrando a seqüência de telas, a lógica de construtor de modelo de GUI 2320 obtém uma informação sobre a estrutura do GAP e as propriedades dos elementos de GUI individuais usando as interfaces de acessibilidade habilitada. Assim sendo, a lógica de construtor de modelo de GUI 2320 extrai dados estruturais de elemento de GUI (2714) e características de elemento de GUI (2716) a partir da informação retornada pela camada de acessibilidade. A lógica de construtor de modelo de GUI 2320 usa os dados estruturais de elemento de GUI e as características de elemento de GUI para adicionar uma informação de elemento de GUI em um modelo de GUI de GAP (2718), por exemplo, em uma base de elemento por elemento, tela portela ou em outra base em incrementos. A lógica de construtor de modelo de GUI 2320 pode continuar a construir o modelo de GUI de GAP até o operador parar de interagir com o GAP selecionado (2720).

O modelo de GUI de GAP que resulta pode ser uma captura plena ou parcial da estrutura de GUI de GAP inteira. Assim, quando o operador está interessado em comparar pedaços específicos de uma GUI entre dois GAPs, o operador pode exercitar apenas aqueles pedaços de interesse. A lógica de construtor de modelo de GUI 2320 captura os pedaços específicos em um modelo de GUI de GAP específico para os pedaços que o operador exercitou, ao invés de todo aspecto de todo elemento de GUI no GAP selecionado inteiro. O operador pode rodar a versão de GAP atual 2326 e a versão de GAP subsequente 2328 com a lógica de construtor de modelo de GUI 2320 para criar o modelo de GUI de Vn de GAP 2338 e o modelo de GUI de Vn+1 de GAP 2340, respectivamente.

A Figura 28 mostra um fluxograma 2800 para uma lógica de comparação de GAP, tal como a lógica de comparação de GAP 2342. A lógica de comparação de GAP 2342 pode receber um primeiro modelo de GUI de GAP (2802). Por exemplo, a lógica de comparação de GAP 2342 pode acessar o modelo de GUI de Vn de GAP 2338 armazenado na memória 2304. A lógica de comparação de GAP 2342 pode receber um segundo modelo de GUI de GAP (2804). Por exemplo, a lógica de comparação de GAP 2342 pode acessar o modelo de GUI de Vn+1 de GAP 2340 armazenado na memória 2304. De forma alternativa ou adicional, a lógica de comparação de GAP 2342 pode requisitar e receber um primeiro e um segundo modelos de GUI de GAP a partir da lógica de comunicação 163.

A lógica de comparação de GAP 2342 então pode combinar o primeiro modelo de GUI de GAP e o segundo modelo de GUI de GAP para a criação do modelo de diferença de GUI (2806). Os primeiro e segundo modelos de GUI de GAP podem ser combinados em uma configuração plana.

De forma alternativa ou adicional, os primeiro e segundo modelos de GUI de GAP podem ser combinados em uma configuração de árvore, hierárquica ou aninhada.A lógica de comparação de GAP 2342 pode invocar, então, a lógica de recuperação de mapeamento 2346. A lógica de recuperação de mapeamento 2346 pode determinar se os mapeamentos de versão de elemento de GUI estão disponíveis para o primeiro modelo de GUI de GAP e o segundo modelo de GUI de GAP (2808). Esta determinação pode ser realizada ao se consultar uma fonte local, tal como a memória 2304, quanto a mapeamentos de versão de elemento de GUI. De forma alternativa ou adicional, a lógica de recuperação de mapeamento 2346 pode consultar um depósito de dados de elemento de GUI 138 através da lógica de comunicação 163.

Se a lógica de recuperação de mapeamento 2346 determinar que os mapeamentos de versão de elemento de GUI estão disponíveis, então, a lógica de recuperação de mapeamento 2346 pode requisitar aqueles mapeamentos de versão de elemento de GUI (2810). A requisição pode ser feita para uma fonte local, tal como a memória 2304. De forma alternativa ou adicional, a requisição pode ser feita para um depósito de dados de elemento de GUI 138 através da lógica de comunicação 163. A requisição pode ser por mapeamentos específicos, tal como para mapeamentos de versão de elemento de GUI relevantes para o próximo nó. Alternativamente, a requisição pode ser por todos os mapeamentos de versão de elemento de GUI disponíveis. A lógica de recuperação de mapeamento 2346 pode receber os mapeamentos de versão de elemento de GUI em resposta à requisição (2812).

De forma alternativa ou adicional, a determinação quanto a se os mapeamentos de versão de elemento de GUI estão disponíveis, a requisição e a resposta podem ser combinadas em menos ações. Por exemplo, a lógica de recuperação de mapeamento 2346 pode apenas requisitar os mapeamentos. Uma resposta dos mapeamentos de versão de elemento de GUI pode confirmar que os mapeamentos estão disponíveis, enquanto uma resposta negativa ou nula pode confirmar que os mapeamentos não estão disponíveis.

A lógica de recuperação de mapeamento 2346 pode retornar,então, e a lógica de comparação de GAP 2342 então pode invocar a lógica de travessia de representação 2348. A lógica de travessia de representação 2348 pode atravessar para o próximo elemento de GUI, isto é, um elemento de GUI de origem, a partir do primeiro modelo de GUI de GAP (2814). No caso em que o modelo de diferença de GUI de base é recém criado, a travessia pode ser para o primeiro elemento de GUI. A travessia pode ser realizada com base na representação do modelo de GUI de GAP dentro do modelo de diferença de GUI de base. O próximo nó a visitar pode ser determinado, como exemplos, em forma de primeiro na profundidade ou primeiro na largura.

A lógica de comparação de GAP 2342 então pode determinar se um mapeamento de versão de GUI existe para o elemento de GUI (2816). A lógica de comparação de GAP 2342 pode buscar nos mapeamentos de versão de elemento de GUI recuperados para determinar se o mapeamento existe. Se o mapeamento existir, então, a lógica de comparação de GAP 2342 poderá criar um campo de link no modelo de diferença de GUI de base (2818). O campo de link pode incluir um identificador de elemento de GUI, tal como um identificador de elemento de GUI de origem ou um identificador de elemento de GUI de destino. O campo de link também pode incluir um alias de GAP. A lógica de comparação de GAP 2342 pode criar um campo de link para apenas o elemento de GUI de origem. De forma alternativa ou adicional, a lógica de comparação de GAP pode criar um campo de link para o elemento de GUI de destino.

A lógica de travessia de representação 2348 pode determinar, então, se mais elementos de GUI de origem estão disponíveis (2820). Se mais elementos de GUI de origem não tiverem sido atravessados ainda, então, a lógica de travessia de representação 2348 circulará de volta e atravessará o próximo elemento de GUI de origem disponível (2814). Se não existirem elementos de GUI de origem disponíveis, a lógica de comparação de GAP 2342 poderá terminar.

Se nenhum mapeamento de versão de elemento de GUI existir ou os mapeamentos existirem, mas nenhum mapeamento existir para o ele-mento de GUI de origem, então, a lógica de comparação de GAP 2342 poderá invocar a lógica de análise ponderada 2350. A lógica de análise ponderada 2350 pode recuperar pesos a partir de uma tabela de peso (2822). Por exemplo, a lógica de análise ponderada 2350 pode recuperar os pesos a partir de uma tabela de peso na memória 2304. De forma alternativa ou adicional, a lógica de análise ponderada 2350 pode requisitar e receber uma tabela de peso a partir da lógica de comunicação 163.

A lógica de travessia de representação 2348 então pode atravessar para o próximo elemento de GUI, isto é, um elemento de GUI de destino, no segundo modelo de GUI de GAP (2824). No caso em que nenhuma travessia prévia no segundo modelo de GUI de GAP foi feita para um dado elemento de GUI de origem, então, a lógica de travessia de representação 2348 pode atravessar para o primeiro elemento de GUI no segundo modelo de GUI de GAP. A travessia pode ser realizada com base no segundo modelo de GUI de GAP. De forma alternativa ou adicional, a travessia pode ser realizada com base na reprodução segundo modelo de GUI de GAP dentro do modelo de diferença de GUI de base. A travessia pode ser realizada u-sando-se uma técnica de travessia primeiro na profundidade, primeiro na largura ou outra.

A lógica de análise ponderada 2350 então pode obter características de elemento de GUI para o elemento de GUI de origem e o elemento de GUI de destino (2826). As características de elemento de GUI podem incluir características de elemento de GUI tais como tamanho, posição XY, cor, posição de janela, tipo de fonte, tamanho de fonte, estilo de borda, corde fundo, cor de primeiro plano, apenas de leitura / apenas de escrita, ou qualquer outra característica de elemento de GUI. De forma alternativa ou adicional, as características de elemento de GUI podem incluir um Papel de camada de acessibilidade, HWND, Classe, Estilo, Estilo Estendido, número de filhos, nível em uma árvore ou hierarquia, Nome do elemento de GUI ou outras propriedades de camada de acessibilidade atribuída. Estas características de elemento de GUI podem ser obtidas a partir dos primeiro e segundo modelos de GUI de GAP. De forma alternativa ou adicional, as carac-terísticas de elemento de GUI podem ser obtidas a partir do modelo de diferença de GUI de base.

A lógica de análise ponderada 2350 então pode determinar um valor de similaridade de elemento de GUI para o elemento de GUI de origem e o elemento de GUI de destino (2828). O valor de similaridade pode ser determinado de acordo com a fórmula a seguir:

<formula>formula see original document page 68</formula>

onde Vs é o valor de similaridade, N é o número de características ou propriedades em relação às quais a similaridade está sendo medida, P, é o valor atribuído às diferenças entre cada propriedade ou característica, e Wi é o peso característica para cada propriedade P,. Como um exemplo:

Vs = WR Role

onde Role pode ser 0 ou 1 dependendo de as características de Role entre os dois elementos de GUI serem diferentes ou as mesmas, respectivamente, e Wr pode ser o peso correspondente para Role. Ao peso para Role pode ser atribuído um valor indicativo da importância da combinação de Role entre os elementos de GUI. Por exemplo, o peso do Role pode ser muito grande em relação ao peso para outras características. Como um outro exemplo:

Vs=WR . Role + Wc -Class

onde Class pode ser uma contagem de quantos termos na propriedade Class combinam, dividido pelo número total de termos na propriedade Class, e Wc pode ser o peso correspondente para a Class. Por exemplo, uma característica de Class para um elemento de GUI pode ser "Windows-Forms10.LISTBOX.app4". Se a característica de Class para um elemento de GUI correspondente for "WindowsForms10.COMBOBOX.app.0.378734a", então devido ao fato de as características apenas combinarem em um único lugar de três ou cinco lugares, o valor de Class será "1/3" ou "1/5".

A lógica de comparação de GAP 2342 pode armazenar, então, em uma tabela de escore um escore com base no valor de similaridade (2830). De forma alternativa ou adicional, a lógica de comparação de GAP 2342 pode armazenar os identificadores de elemento de GUI para o elemen-to de GUI de origem e o elemento de GUI de destino juntamente com o escore na tabela de escore. A tabela de escore pode residir na memória 2304.

A lógica de comparação de GAP 2342 então pode determinar se a lógica de travessia de representação 2348 completou a travessia do segundo modelo de GUI de GAP (2832). Se a lógica de travessia de representação 2348 ainda tiver mais elementos de GUI de destino a atravessar, então, a lógica de travessia de representação 2348 circulará de volta para atravessar para o próximo elemento de destino (2824). Se a lógica de travessia de representação 2348 tiver completado a travessia dos elementos de GUI de destino, a lógica de comparação de GAP 2342 poderá invocar a lógica de construção de combinação 2352.

A lógica de construção de combinação 2352 pode analisar os valores de similaridade determinados pela lógica de análise ponderada 2350 ou os escores na tabela de escore (2834). A lógica de construção de combinação 2352 pode comparar os valores ou os escores em relação a um limite de similaridade para determinar se os valores ou escores se adéquam e/ou excedem ao limite de similaridade. De forma alternativa ou adicional, os valores ou escores podem ser comparados em relação a um limite de diferença para se determinar se os valores ou escores estão em ou abaixo de um limite de diferença.

A lógica de construção de combinação 2352 pode determinar se os elementos de GUI combinam (2836). Esta determinação pode ocorrer quando os valores ou escores excederem ao limite de similaridade. De forma alternativa ou adicional, esta determinação pode ocorrer quando os valores ou escores não estiverem abaixo de um limite de diferença.

Se existir uma combinação, então, a lógica de comparação de GAP 2342 poderá criar um campo de link no modelo de diferença de GUI de base (2838). O campo de link pode incluir um identificador de elemento de GUI, tal como um identificador de elemento de GUI de origem ou um identificador de elemento de GUI de destino. O campo de link também pode incluir um alias de GAP. A lógica de comparação de GAP 2342 pode criar um campo de link para apenas o elemento de GUI de origem. De forma alternativaou adicional, a lógica de comparação de GAP pode criar um campo de link para o elemento de GUI de destino.

Após a lógica de comparação de GAP 2342 criar um campo de link, ou se nenhuma combinação existir, então, a lógica de construção de combinação 2352 pode determinar se mais escores ou valores de similaridade precisam ser analisados (2840). Esta determinação pode depender de a tabela de escore ainda incluir escores que não foram analisados. Se a lógica de comparação de GAP 2342 determinar que mais escores precisam ser analisados, a lógica de construção de combinação 2352 circulará de volta para analisar o próximo escore na tabela de escore (2834). Se nenhum escore não analisado existir na tabela de escore, a lógica de construção de combinação 2352 poderá retornar, e a lógica de comparação de GAP 2342 poderá circular de volta para determinar se quaisquer elementos de GUI de origem a mais permanecem (2820). De forma alternativa ou adicional, a lógica de comparação de GAP 2342 pode comunicar quaisquer campos de link criados pela lógica de construção de combinação 2352 para o depósito de dados de elemento de GUI para armazenamento como um mapeamento de versão de elemento de GUI de GAP. A comunicação pode usar um formato de mensagem de mapeamento de versão de elemento de GUI, conforme descrito na Figura 6.

Em uma outra implementação, a lógica de comparação de GAP 2342 pode executar uma comparação de esquema para determinar diferenças entre a GUI de GAP atual e a GUI de GAP subsequente. Dada uma representação de esquema (por exemplo, uma representação de esquema em XML) da GUI de GAP atual e da GUI de GAP subsequente, a lógica de comparação de GAP 2342 pode comparar os respectivos esquemas. Se estes esquemas forem "iguais", então, a versão de GAP atual e a versão de GAP subsequente serão as mesmas. Caso contrário, a versão de GAP atual e a versão de GAP subsequente serão diferentes e a lógica de comparação de GAP 2342 encontrará as diferenças.

Por exemplo, os esquemas em XML podem ser registrados no formato XML e cada esquema pode ter a raiz especificada com o elemento<schema>. Elementos de dados podem ser especificados com os tags <e-lement> e <attribute>. Cada elemento de dados pode ser definido por seu nome e por seu tipo. Os elementos podem ser de tipos simples ou complexos. Os tipos de elemento complexos suportam elementos aninhados, enquanto os tipos simples são atributos e elementos de tipos básicos.

Estendendo o exemplo, os elementos podem ter dois tipos de restrições. Em primeiro lugar, os valores dos elementos podem ser restritos. O segundo tipo de restrições especifica limites quanto ao número de vezes que um elemento específico pode ocorrer como um filho de um elemento.

Estes limites podem ser especificados com os atributos minOccurs e ma-xOccurs do tag <element> para representação do número mínimo e do máximo de ocorrências. Os elementos podem ser agrupados em uma seqüência se eles forem filhos do mesmo elemento pai. A cada elemento ou atributo em uma seqüência pode ser atribuído um número de seqüência inteiro positivo único. Este número pode ser usado para se acessarem elementos ou atributos, ao invés de se usarem seus nomes.

Os esquemas podem ser representados usando-se gráficos. Seja T os conjuntos finitos de nomes de tipo e F de nomes de elemento e atributo (rótulos) e símbolos distintos a e F e (3 e T. Os gráficos de esquema são gráficos dirigidos G (V, E, L), de modo que:

1) VçT, os nós são nomes de tipo ou p se o nome de tipo de dados não for conhecido;

2) L ç F, bordas são rotuladas por nomes de elemento ou de atributo ou a se o nome não for conhecido;

3)EçLXVXV, bordas são produtos vetoriais de rótulos e nós.

Se < I, vk, vm> e E, então vk -> (I) -> vm. Os nós vm são chamados de filhos do nó vk. Se um elemento não tiver filhos, então, seu nó correspondente em um gráfico de esquema terá uma coleção vazia de nós filhos;

4) Os limites para os elementos são especificados com subscritos e sobrescritos para rótulos designando estes elementos. Os subscritos são usados para especificação de limites definidos pelo atributo minOccurs, e sobrescritos designam os limites especificados pelo atributo maxOccurs;5) Cada gráfico tem um nó especial rotulado root € V, onde root representa uma coleção de elementos de raiz. Um esquema vazio tem um nó de raiz único e nenhuma borda;

6) O tag de XML <complexType> especifica que um elemento tem um tipo complexo, e não é representado no gráfico.

Um caminho em um gráfico de esquema pode ser uma se de rótulos PG = <I1, 12, ... In>, onde vk -> (In) -> vm para vm em V e 1 <= u <= n. O símbolo p pode ser usado ao invés de um rótulo em um caminho, se um elemento for navegado por seu número de seqüência. Function type:v->s retorna o tipo se Tdo nove V. Function max:label(u, I) -> u retorna o limite superior u, ou 00 se o limite superior não for especificado, e function min:label(u, I) -> I retorna o limite inferior I, ou zero, se o limite inferior não for especificado.

Uma vez que os GAPs sejam modelados usando-se esquemas em XML, estes esquemas podem ser comparados usando-se uma simulação para computação de mudanças entre os GAPs correspondentes. Isto é, se o esquema do novo GAP for o mesmo que o esquema da liberação prévia do GAP, ou os tipos de seus objetos de GUI forem subsumidos pelos tipos do objeto de GUI correspondente do GAP prévio, então, estes esquemas poderão ser considerados idênticos. Caso contrário, a lógica de comparação de GAP 2342 poderá emitir um aviso e os objetos de GUI com os tipos de modificação associados serão reportados.

Para essa finalidade, a lógica de comparação de GAP 2342 pode implementar uma técnica de bissimulação para comparação de esquemas. A Figura 32 mostra um exemplo das propriedades de bissimulação 3200 que uma lógica de comparação de GAP 2342 pode empregar, incluindo uma primeira propriedade de bissimulação 3202, uma segunda propriedade de 3204, uma terceira propriedade de bissimulação 3206 e uma quarta propriedade de bissimulação 3208.

A bissimulação pode ser uma relação binaria entre os nós de dois gráficos g1, g2 e G, escrita como x ~y, x,ye V, satisfazendo às propriedades de bissimulação 3202 - 3208.A lógica de comparação de GAP 2342 pode considerar dois gráficos finitos g1, g2 € G iguais, se existir uma bissimulação de g1 para g2. Um gráfico é bissimilar para seu desdobramento infinito. A lógica de comparação de GAP 2342 pode computar a bissimulação de dois gráficos começando com uma seleção dos nós de raiz e aplicando as propriedades de bissimulação 3202 - 3208. A lógica de comparação de GAP 2342 busca uma relação (x, y) entre os nós x e y em um gráfico que falha em satisfazer às propriedades de bissimulação 3202 - 3208. Quando uma relação (x, y) como essa é encontrada, então, a lógica de comparação de GAP 2342 determinará que os gráficos não são iguais e a bissimulação poderá parar.

Por exemplo, considere o esquema atual 3210 e o esquema subsequente 3212 na Figura 32. A lógica de comparação de GAP 2342 aplica uma bissimulação para determinar se dois esquemas 3210 e 3212 são equivalentes. O esquema 3210 descreve dados em XML que modelam uma tela de GUI atual, e o esquema 3212 modela uma versão modificada da tela de GUI atual. A lógica de comparador 2342 pode determinar que se o esquema 3212 for equivalente ao esquema 3210, então, as telas de GUI serão as mesmas.

A lógica de comparação de GAP 2342 seleciona os nós de raiz 3214 e 3216 em ambos os esquemas 3210 e 3212 que satisfazem à primeira propriedade de bissimulação 3202 e à segunda propriedade de bissimulação 3204. A lógica de comparação de GAP 2342 então pode selecionar a relação a -> (authorl) -> a 3222 para o esquema 3210 e a relação a -> (au-thorl) -> a 3224 para o esquema 3212. A lógica de comparação de GAP 2342 determina que a terceira propriedade de bissimulação 3206 e a quarta propriedade de bissimulação 3208 são violadas. Em particular, a lógica de comparação de GAP 2342 determina que a relação ofendendo 'author' é marcada como potencialmente apagada no esquema 3212, uma diferença do esquema 3210. Assim, os esquemas 3210 e 3212 não são iguais.

A Figura 29 mostra um visor 2900 e uma interface de limite de comparador de GUI 2902. A lógica de modelo de diferença de GUI 2380 pode exibir a interface 2902 em resposta a uma entrada de operador. Por e-xemplo, o operador pode selecionar um item de configuração de opção apartir de um menu gerado pela lógica de modelo de diferença de GUI 2380.Em resposta, a lógica de modelo de diferença de GUI 2380 exibe a interface2902. A exibição pode ser provida localmente, por exemplo, através do visor2306, ou remotamente, por exemplo, via o terminal 2318.

No exemplo mostrado na Figura 29, a interface 2902 inclui umcursor deslizante 2904 que seleciona um valor entre 0 e 1. Qualquer outrainterface ou faixa de valor pode ser provida para o operador. A lógica demodelo de diferença de GUI 2380 pode regular o limite de diferença combase no valor do cursor deslizante 2904. O valor 9 representa que essenci-almente nenhuma similaridade ou uma similaridade limitada é necessáriapara se encontrar uma combinação entre os elementos de GUI. O valor 1representa que uma similaridade muito próxima ou exata é necessária parase encontrar uma combinação entre elementos de GUI. Essa similaridadepode ser encontrada em mapeamentos manuais, por exemplo, conformeespecificado em um campo de nível de confiança alto 811 (por exemplo,"100M") conforme recebido a partir do depósito de metadados. Contudo, umnível de confiança muito alto também pode ser obtido através da análise decálculo de peso automatizada descrita acima, e a lógica de modelo de dife-rença de GUI 2380 em algumas implementações pode aceitar um mapea-mento de versão manual como correto, independentemente do nível de con-fiança associado.

A Figura 29 também mostra uma porção 2906 da versão de GAPatual 2326 e uma porção 2908 da versão de GAP subsequente 2328. Alémde permitir que o operador regule o limite de usando a interface 2902, a lógi-ca de modelo de diferença de GUI 2380 ainda pode incluir uma lógica devisualização 2378. A lógica de visualização 2378 pode exibir elementos naversão de GAP atual e na versão de GAP subsequente que combinem, con-forme determinado pela análise de comparação ponderada, pelo limite desimilaridade e pelos mapeamentos de versão. Os elementos de GUI combi-nando podem ser destacados com uma borda de um padrão em particularou cor, ou de outras maneiras, e bordas, cores e outros recursos diferentespodem ser usados para cada combinação.

Na Figura 29, a lógica de visualização 2378 destaca os elemen-tos de GUI combinando com base no limite de similaridade regulado atravésda interface 2902. O limite de similaridade é muito alto. No exemplo mostra-do na Figura 29, a lógica de visualização 2378 destaca os elementos de cai-xa de texto 2910, 2912, 2914, 2916 e 2918 na porção 2906 da versão deGAP atual 2326 que combinam, respectivamente, com os elementos de tex-to 2920, 2922, 2924, 2926 e 2928 na porção 2908 da versão de GAP subse-quente 2328. Os elementos de caixa de texto 2190 - 2928 têm poucas mu-danças ou nenhuma nas suas características entre as versões de GAP sub-sequentes. O elemento de caixa de texto 2930 e o elemento de caixa decombinação 2932 permanecem não destacados, contudo, por que suas ca-racterísticas diferem até uma grande extensão, e a análise de comparaçãoponderada não determina um valor de similaridade de elemento de GUI queexceda ao limite de similaridade.

Na Figura 30, o visor 3000 mostra que o cursor deslizante 2904foi ajustado para um limite de similaridade mais baixo. A lógica de visualiza-ção 2378 destaca os elementos de GUI de combinação com base no limitede similaridade mais baixo regulado através da interface 2902. No exemplomostrado na Figura 30, a lógica de visualização 2378 destaca, como antes,os elementos de caixa de texto 2910, 2912, 2914, 2916 e 2918 na porção2906 da versão de GAP atual 2326 que combinam, respectivamente, com oselementos de texto 2920, 2922, 2924, 2926 e 2928 na porção 2908 da ver-são de GAP subsequente 2328.

Contudo, a lógica de visualização 2378 também destaca o ele-mento de caixa de texto 2930 e o elemento de caixa de combinação 2932.Embora as características do elemento de caixa de texto 2930 e do elemen-to de caixa de combinação 2932 difiram até uma certa extensão, a análisede comparação ponderada realmente obtém um valor de similaridade deelemento de GUI que excede ao limite de similaridade. Assim sendo, a lógi-ca de visualização 2378 destaca os elementos 2930 e 2932.

A Figura 31 mostra um fluxograma 3100 par artigo absorventelógica de visualização 2378. A lógica de visualização 2378 também podeexibir uma interface de limite de comparador de GUI 2902 (3106). A lógicade visualização 2378 pode regular o limite de similaridade com base no valorescolhido através da interface de limite de comparador de GUI 2902 (3108).Dado o limite de similaridade, a lógica de visualização 2378 pode chamar aversão de GAP atual 2326 e a versão de GAP subsequente 2328 (3110).Alternativamente, a lógica de visualização 2378 pode executar uma análisede comparação (por exemplo, a análise de comparação ponderada descritaacima) para determinar um ou mais elementos de GUI na versão de GAPsubsequente 2328 que combinem com qualquer elemento em particular naversão de GAP atual. A lógica de visualização 2378 pode aceitar uma sele-ção de elemento a partir do operador, que especifique um ou mais elemen-tos de GUI em particular de interesse em qualquer versão de GAP, e encon-trar os elementos de GUI combinando na outra versão de GAP. Alternativa-mente, a lógica de visualização 2378 pode considerar cada elemento de GUIna versão de GAP atual 2326 e encontrar os elementos de GUI combinandona versão de GAP subsequente 2328.

A lógica de visualização 2378 destaca os elementos de GUIcombinando na versão de GAP atual 2326 e na versão de GAP subsequente2328 (3112). Para essa finalidade, a lógica de visualização 2378 pode emitircomandos para o proxy para destacar quaisquer elementos de GUI em parti-cular. Se houver mais elementos de GUI a considerar, a lógica de visualiza-ção 2378 tentará encontrar combinações adicionais.

Em qualquer momento, a lógica de visualização 2378 pode che-car para determinar se a interface de limite de comparador de GUI 2902 mu-dou (por exemplo, o operador mudou a posição do cursor deslizante paraselecionar um novo valor de limite). A lógica de visualização 2378 tambémpode checar, em qualquer momento, se o operador desejou rever GAPs dife-rentes. Caso assim seja, a lógica de visualização 2378 obtém novas sele-ções de GAP (3114). A lógica de visualização então exibe os GAPs e a inter-face de limite de comparador de GUI e prossegue conforme citado acima.

A Figura 1 mostra um analisador de script com uma arquiteturade guia de mudança (SAA) 108. Embora descrições detalhadas dos recursosda SAA 108 sejam providas adicionalmente abaixo, uma breve introdução daSAA 108 será apresentada, primeiramente. A SAA 108 recebe um modelode diferença de GUI 162 que especifica diferenças de elemento de GUI entreuma versão de GAP atual 150 e uma versão de GAP subsequente 152. Omodelo de diferença de GUI 162 pode ser representado como um esquemaem XML. Em uma outra implementação, os modelos de árvore de GAP atuale subsequente, bem como o modelo de diferença de GUI 162 são implemen-tados como modelos relacionais armazenados em um banco de dados. ASAA 108 emprega uma interface 190 para receber entradas e se comunicarcom vários componentes, incluindo um depósito de metadados de elementode GUI 138. O depósito de metadados de elemento de GUI 138 pode proveruma informação detalhada referente aos elementos de GUI representadosno modelo de diferença de GUI 162, o GAP atual 150 e o GAP subsequente152. Em uma implementação, a SAA 108 inclui um analisador gramatical descript 166 que analisa gramaticalmente um script de teste atual 164 para aobtenção de uma representação intermediária do script de teste atual 164. Arepresentação intermediária pode ser uma árvore de sintaxe abstrata (AST)168 ou uma outra representação do script de teste atual 164. A SAA 108emprega um analisador de script 170 que analisa a AST 168 e invoca umaconsulta de depósito de objeto 172 em relação a um depósito de objeto 174,para a localização das propriedades de elementos de GUI identificados pelaAST 168. O analisador de script 170 usa o depósito de metadados de ele-mento de GUI 138, o depósito de objeto 174, um motor de satisfação de res-trição 188 e regras de mudança de script de elemento de GUI 194 para alocalização de entradas de diferença de elemento de GUI válidas, discutidasadicionalmente abaixo. Em uma implementação, o analisador de script 170usa uma lógica de regras de classe de GUI para favorecer a análise, discuti-do em maiores detalhes abaixo. O analisador de script 170 extrai um scriptde teste transformado 178, um guia de mudança 180 e especificadores demudança de GAP 184 com base na análise realizada no modelo de diferen-ça de GUI 162 e na AST 168.A Figura 33 mostra uma GUI de uma versão de GAP atual 150.A Tabela 6 mostra uma representação de modelo de árvore de GAP atual daGUI da versão de GAP atual 150. O modelo de árvore de GAP atual mostra-do na Tabela 6 especifica os elementos de GUI e os atributos dos elementosde GUI da versão de GAP atual 150. A Tabela 6 ilustra que o modelo de ár-vore de GAP atual suporta elementos de GUI que incluem elementos de GUIaninhados. Por exemplo, a janela StateList 3302, mostrada na Figura 33,corresponde a GUI Element Alias StateList na linha 11 (L11) da Tabela 6 eelementos de GUI aninhados SaveFile, Exit, SaveChange, FileOpen, a caixade lista School, mostrados nas linhas 18-21 e 59 da Tabela 6, correspon-dem, respectivamente, a Save File 3304, Close Form 3306, Save Change3308, Open File 3310 e à caixa de lista School 3316 da Figura 33. Em umaimplementação, o modelo de diferença de GUI 162 resulta de uma compara-ção do modelo de árvore de GAP atual, conforme mostrado na Tabela 6 eum modelo de árvore de GAP subsequente ilustrado abaixo na Tabela 8.

Um GAP, os elementos de GUI do GAP e os valores dos ele-mentos de GUI definem estados para o GAP. Os modelos de árvore de GAPatual e subsequente capturam os estados das versões de GAP atual e sub-sequente (por exemplo, 150 e 152), respectivamente. Em uma implementa-ção, os estados de GAP são identificados por números de seqüência e alias,bem como outros atributos. Por exemplo, a linha 1 da Tabela 6 ilustra um'state' que tem um SeqNumber com um valor de 0. O SeqNumber representaum número de seqüência único da versão de GAP atual. Ao estado é dado onome State_0_3556. Os atributos Alias e Processid representam o alias daversão de GAP atual 150 e o identificador de processo de instância para aversão de GAP atual 150, respectivamente. Lembre que a Tabela 6 e a Ta-bela 8 ilustram que os modelos de árvore de GAP atual e subsequente su-portam elementos de GUI que incluem elementos de GUI aninhados. Embo-ra múltiplos elementos de GUI possam usar um Alias idêntico (por exemplo,StateList, conforme ilustrado na Tabela 6 nas linhas 2 e 11), os elementosde GUI são adicionalmente distinguidos pelo atributo UniquelD (por exemplo,0x0 e 0x12, conforme mostrado nas linhas 3 e 12 da Tabela 6).<table>table see original document page 79</column></row><table><table>table see original document page 80</column></row><table>

O elemento de GUI StateListBox mostrado na Tabela 6 na linha62 corresponde à caixa de lista State 3312 mostrada na Figura 33. A Figura33 mostra uma barra de navegação horizontal 3314 como um recurso dacaixa de lista State 3312. A Tabela 7 mostra alguns dos atributos da caixa delista State 3312 que podem ser refletidos no modelo de diferença de GUI162 como resultado de uma comparação entre o modelo de árvore de GAPatual e o modelo de árvore de GAP subsequente mostrado na Tabela 8.<table>table see original document page 81</column></row><table><table>table see original document page 82</column></row><table>

A Figura 34 mostra a GUI de uma versão de GAP subsequente152. A Tabela 8 ilustra uma representação de modelo de árvore de GAPsubsequente da versão de GAP subsequente 152. O modelo de árvore deGAP subsequente mostrado na Tabela 8 inclui os elementos de GUI e osatributos dos elementos de GUI. Por exemplo, o objeto de GUI de janela S-chool 3402 mostrado na Figura 34 corresponde ao Alias de Elemento de GUI"School" mostrado na linha 11 (L11) da Tabela 8 e os elementos de GUI ani-nhados StateListBox e SchoolCombobox mostrados nas linhas 23 e 24 daTabela 8 correspondem, respectivamente, à caixa de lista State 3404 e àcaixa de combinação School 3406 da Figura 34. Em uma implementação, omodelo de diferença de GUI 162 resulta de uma comparação entre o modelode árvore de GAP atual, conforme mostrado na Tabela 6 e o modelo de ár-vore de GAP subsequente, conforme mostrado na Tabela 8.

Tabela 8 - Modelo de árvore de GAP subsequente

<table>table see original document page 83</column></row><table><table>table see original document page 84</column></row><table>

O esquema de elemento de GUI menuStripl mostrado na Tabe-la 8 na linha 18 corresponde ao objeto de GUI WinObject GUI 'menu strip'3408 mostrado na Figura 34. O esquema de elemento de GUI menuStriplde GAP subsequente mostrado na Tabela 9 ilustra a entrada plena na linha18 na Tabela 8 e indica que a menu strip 3408 inclui um elemento de GUIaninhado File menu que inclui os elementos de GUI aninhados OpenFile,SaveFile, SaveAs, e Exit, mostrados nas linhas 15 da Tabela 9, e 22-25,respectivamente.

Tabela 9 - Esquema de elemento de GUI menuStripl de GAP subsequente

<table>table see original document page 85</column></row><table>

A Figura 35 ilustra uma vista lado a lado do GAP atual e do sub-sequente, que ajuda a ilustrar similaridades de elemento de GUI, bem comodiferenças, entre versões de GAP sucessivas. Na vista 3500, há vários obje-tos de GUI que têm a mesma funcionalidade desejada entre versões de GAPsucessivas, embora aspectos do objeto de GUI possam parecer diferentesentre versões de GAP sucessivas.

Por exemplo, com referência à Figura 35, diferenças entre a ver-são de GAP atual 150 e a versão de GAP subsequente 152 incluem que ajanela StateList 3302, a caixa de lista State 3312, o campo Academic Em-phasis 3502, e o campo Quality of Life Scale (1-5) 3504 na versão de GAPatual 150 são respectivamente representados pela janela School 3402, pelacaixa de lista State 3404, pelo campo Academic Emphasis 3506, e pelocampo Quality of Life (1-5) 3508 na versão de GAP subsequente 152. Emum outro exemplo, considere os objetos de GUI Save File 3304, Close Form3306, Save Change 3308 e Open File 3310 implementados na versão deGAP atual 150 que foram implementados na versão de GAP subsequente152 como objetos de GUI filhos do File 3510, o qual é um objeto de GUI filhodo objeto de GUI menu strip 3408.

Pode ser desafiador localizar diferenças entre elementos de GUIde GAPs. Por exemplo, não é prontamente evidente que a caixa de lista S-chool 3316 e a caixa de combinação School 3406 têm por significado ter amesma funcionalidade ou uma similar entre versões de GAP sucessivas.Como um outro exemplo, o WinObject "Select School" 3318 na versão deGAP atual 150 foi removido na localização 3512 da versão de GAP subse-quente 152. O modelo de diferença de GUI 162 inclui as entradas de dife-rença de elemento de GUI que listam características de elementos de GUI,para aqueles elementos de GUI que combinam entre a versão de GAP atuale a versão de GAP subsequente, mas que diferem no caráter entre a versãode GAP atual e a versão de GAP subsequente. As entradas de diferença deelemento de GUI guiarão a análise de script conforme descrito em maioresdetalhes abaixo.

A Figura 36 mostra uma entrada de diferença de elemento deGUI de exemplo 3604. A Figura 36 ilustra um modelo de diferença de GUI162 obtido pela comparação de um modelo de árvore de GAP atual, confor-me mostrado na Tabela 6 e um modelo de árvore de GAP subsequente, con-forme mostrado na Tabela 8. Em uma implementação, o modelo de diferen-ça de GUI 162 é implementado como um esquema em XML que especificacada diferença de elemento de GUI entre versões de GAP sucessivas comuma entrada de diferença de elemento de GUI correspondente. Em uma ou-tra implementação, o modelo de diferença de GUI 162 aninha entradas dediferença de elemento de GUI para indicar elementos de GUI pais e filhos, eo nível no qual uma entrada de diferença de elemento de GUI é aninhadaindica quão distante o elemento de GUI está de um elemento de GUI pai(raiz) em um caminho de navegação.

Em uma implementação, o modelo de diferença de GUI 162 omi-te uma entrada de diferença de elemento de GUI para objetos de GUI quetenham sido apagados entre versões de GAP sucessivas. Cada entrada dediferença de elemento de GUI representando um objeto de GUI que tenhasido modificado ou adicionado entre versões de GAP sucessivas inclui umtag 'Version' que tem um valor de 0 ou 1, como exemplo. Em outras pala-vras, uma entrada de diferença de elemento de GUI que não inclui um tagVersion indica que o objeto de GUI não foi modificado entre versões de GAPsucessivas. Os valores 0 e 1 de Version indicam se os elementos filhos daVersion representam as propriedades do objeto de GUI na versão de GAPatual 150 ou na versão de GAP subsequente 152, respectivamente. Por e-xemplo, a entrada de diferença de GUI 3604 mostrada na Figura 36 indicana linha 11 que o valor de caixa de lista de StateListbox para SeqNum-ber="8" implementado na versão de GAP atual 150 é "District of Columbia",enquanto o valor na versão de GAP subsequente 152 é "Florida", conformeindicado na linha 23. Em uma implementação, a entrada de diferença de GUI3604 inclui um elemento ParentChildldentifier na linha 3, que identifica a re-lação entre dois objetos de GUI em uma dada versão de GAP, de modo querestrições de classe e herança de GUI possam ser validadas (discutido emmaiores detalhes abaixo).

Com referência brevemente à Figura 45, a entrada de diferençade GUI 4504 indica na linha 1 que a janela StateList na versão de GAP atual150 corresponde à janela School na versão de GAP subsequente 152 indi-cada na linha 22 pelo valor de Version igual a 0 e 1, respectivamente. Osobjetos de GUI StateList e School são da classe WindowsForm10.Window.8,conforme mostrado nas linhas 8 e 28. O identificador de subclasse para oobjeto de GUI de StateList e School distingue os objetos de GUI (Por exem-pio, app4 e app.0.0378734a, respectivamente). A entrada de diferença deGUI 4504 indica que os elementos Location das janelas StateList e Schoolsão diferentes, conforme mostrado nas linhas 7 e 27, respectivamente. Con-tudo, a entrada de diferença de GUI 4504 também indica que os elementosStyle e ExStyle são idênticos, conforme mostrado nas linhas 9-10 e 29-30,respectivamente.

Com referência brevemente à Figura 46, a entrada de diferençade GUI 4604 indica na linha 3 que a caixa de lista SchoolListbox na versãode GAP atual 150 corresponde à caixa de combinação SchoolCombobox naversão de GAP subsequente 152 indicada na linha 13. A entrada de diferen-ça de GUI 4604 indica que o elemento Location da SchoolListbox e o da S-choolCombobox são diferentes, conforme mostrado nas linhas 7 e 18, res-pectivamente. A entrada de diferença de GUI 4604 também indica que oselementos Class, Style e ExStyle são diferentes, conforme mostrado naslinhas 8-10 e 19-21, respectivamente. Em particular, uma ou mais das pro-priedades de uma WindowsFormslO.LISTBOX e uma Windows-FormslO.COMBOBOX são diferentes, incompatíveis com as propriedadesda outra classe, e os elementos de GUI filhos de objetos de GUI destas duasclasses podem ter uma ou mais propriedades incompatíveis.

A Figura 37 mostra um script de teste atual 164 para o GAP atu-al. O script de teste atual 164 inclui declarações de navegação (por exemplo,L1 e L6) que navegam para objetos de GUI, realizam ações (funções) deleitura, escrita ou outras em objetos de GUI, e os argumentos destas fun-ções. Por exemplo, a linha 1 do script de teste atual 164 navega para umajanela StateList, localiza 'Open File' identificado como um objeto de GUI filhoda janela StateList, e realiza uma ação 'Click' no objeto de GUI 'Open File'em coordenadas XY 86, 12. Através de uma série de declarações de nave-gação e de ação, o script de teste atual 164 abre um arquivo 'univer-sity.data', conforme indicado pelas linhas 2-3. O script de teste atual 164 se-leciona uma escola 'Acme State University' como resultado das declaraçõesde navegação e de ação nas linhas 4-7, com base nas coordenadas 67, 12no WinObject "Select School". O script de teste atual 164 muda a escala a-cadêmica para '3' como resultado das declarações nas linhas 8-10, e salva amudança em um novo arquivo 'university_revise.data' como resultado dasdeclarações nas linhas 11-14.

A Figura 38 ilustra uma representação de script de teste atual3800 que o analisador gramatical de script 166 produz como uma represen-tação intermediária do script de teste atual 164. Em uma implementação, aSAA 108 implementa a representação de script de teste atual como uma ár-vore de sintaxe abstrata (AST) 168. A representação de script de teste atual3800 representa um vetor (por exemplo, o script de teste atual 164), cujoselementos são vetores que representam declarações de navegação do scriptde teste atual 164. Em outras palavras, a representação de script de testeatual 3800 representa as declarações de navegação como vetores de decla-ração de script de teste que navegam para objetos de GUI e realizam açõesnaqueles objetos de GUI. A Tabela 10 ilustra uma gramática que o analisa-dor gramatical de script 166 pode usar para produzir a representação de s-cript de teste atual 3800. Os radicais func, action e var representam os no-mes de funções específicas de plataforma que navegam para objetos deGUI (por exemplo, Window, VbEdit, e WinObject), realizam ações (funções)de leitura, escrita ou outras em objetos de GUI, e os argumentos destas fun-ções, respectivamente.

Tabela 10 - Gramática de Analisador Gramatical de Script

<table>table see original document page 89</column></row><table>

O analisador gramatical de script 166 representa os vetores dedeclaração de script de teste como uma seqüência ordenada de nós quecontêm nomes de função e os argumentos daquelas funções que navegampara objetos de GUI. Os nós de um vetor de declaração de script de testeincluem um nó de origem e um nó de destino. Por exemplo, o analisadorgramatical de script 166 pode representar o vetor de declaração de script deteste correspondente à linha 1 do script de teste atual 164 como uma State-List de nó de origem 3802 e um 'Open File' de nó de destino 3804. Os nósde um vetor de declaração de script de teste também incluem nós intermedi-ários posicionados entre um nó de origem e um nó de destino. Por exemplo,o analisador gramatical de script 166 pode representar o vetor de declaraçãode script de teste correspondente à linha 13 do script de teste atual 164 co-mo uma StateList de nó de origem 3802, um 'Save a Data Record' de nó in-termediário 3806 e 'File name' de nó de destino 3808. Em uma implementa-ção, o analisador de script 170 usa os vetores de declaração de script deteste para analisar caminhos de navegação plausíveis para objetos de GUIidentificados no modelo de diferença de GUI 162 por entradas de diferençade elemento de GUI, descritas em maiores detalhes abaixo. O analisador descript 170 pode usar os vetores de declaração de script de teste para tam-bém analisar objetos de GUI plausíveis identificados no depósito de objeto174, também discutido em maiores detalhes abaixo.

O analisador gramatical de script 166 avalia argumentos de fun-ções de navegação e de ação como expressões, variáveis e constantes. Osargumentos expressam as propriedades físicas de objetos de GUI para osquais os vetores de declaração de script de teste navegam e valores usadospara a realização de ações naqueles objetos de GUI. Por exemplo, as coor-denadas '86, 12' 3812 identificam a localização para um dispositivo de apon-tar para realizar uma ação 'Click' 3810 no objeto de GUI 'Open File' 3804, oqual é um objeto de GUI filho da janela StateList 3802. O analisador de script170 usa os nomes dos objetos de GUI (por exemplo, StateList 3802 e 'OpenFile' 3804) navegados para pelos vetores de declaração de script de testepara localização das propriedades físicas correspondente dos objetos deGUI armazenados em um depósito de objeto (OR) 174.

Em uma implementação, o analisador de script 170 usa a lógicade OR Lookup 172 para retornar a partir do depósito de objeto 174 as pro-priedades físicas dos objetos de GUI navegados para por um vetor de decla-ração de script de teste. Em uma implementação, a lógica de OR Lookup172 é dividida em duas subfunções: 1) uma lógica de consulta adaptada pa-ra localizar e recuperar as propriedades físicas dos objetos de GUI navega-dos para pelo vetor de declaração de script de teste (por exemplo, 3802-3804, 3802-3806-3808, e 3802-3814); e 2) uma lógica de localizador queencontra e retorna uma entrada de diferença de elemento de GUI (nó) nomodelo de diferença de GUI 162 que corresponde ao objeto de GUI com asdadas propriedades físicas! A lógica de OR Lookup 172 pode incluir umalógica de travessia de caminho, discutida em maiores detalhes abaixo, paraa identificação de possíveis caminhos de navegação do vetor de declaraçãode script de teste entre um objeto de GUI de nó de origem e um objeto deGUI de nó de destino para o qual um vetor de declaração de script de testenavega.

A Tabela 11 ilustra uma implementação de um depósito de obje-to 174, na forma de um esquema de XML. O depósito de objeto 174 incluiuma entrada de objeto de GUI para cada objeto de GUI da versão de GAPatual 150 identificada no script de teste atual 164. O depósito de objeto 174pode ser gerado por uma ferramenta de escrita de script, tais como QuickTest Pro (QTP), Rational Robot, e Compuware Test Partner. O analisador descript 170 pode consultar o depósito de objeto 174 para identificar as propri-edades físicas dos objetos de GUI navegados para pelos vetores de decla-ração de script de teste representados pela representação de script de testeatual 3800 que o analisador gramatical de script 166 produz como uma. Aspropriedades físicas de um objeto de GUI podem indicar se o objeto de GUIestá oculto, é apenas de leitura, um número e valores-padrão, conformemostrado na Tabela 12.

Por exemplo, o analisador de script 170 analisa os objetos deGUI 3802-3814 no vetor de declaração de script de teste. A coordenada'19,22' 3818 identifica a localização para um dispositivo de apontar para rea-lizar uma ação de 'Glick' 3812 na SchooListbox de objeto de GUI 3814, oque é um objeto de GUI filho da janela StateList 3802. O analisador de script170 invoca a lógica de OR Lookup 172 para localizar as propriedades físicasdos objetos de GUI 3802 e 3814. A lógica de OR Lookup 172 localiza aspropriedades físicas da janela StateList 3802 e o WinObject SchoolListbox3814, conforme mostrado na Tabela 11 nas linhas 3 e 12. O analisador descript 170 usa as propriedades físicas recuperadas a partir do depósito deobjeto 174 para a localização das entradas de diferença de GUI correspon-dentes (por exemplo, 4504 e 4604) no modelo de diferença de GUI 162. Asentradas de diferença de GUI 4504 e 4604 indicam que a janela StateList3802 e o WinObject SchoolListbox 3814 na versão de GAP atual 150 corres-pondem à janela School 3402 e ao WinObject SchoolCombobox 3406 naversão de GAP subsequente 152, respectivamente. Em uma IP, o analisadorde script 170 emprega a lógica de OR Lookup 172 para atravessar o modelode diferença de GUI 162 usando as propriedades físicas dos objetos de GUInavegados para pelo vetor de declaração de script de teste. A função de ló-gica de OR Lookup 172 retorna uma entrada de diferença de elemento deGUI (por exemplo, 3604, 4504 e 4604) a partir do modelo de diferença deGUI 162 que representa o objeto de GUI navegado para pelo vetor de decla-ração de script de teste (por exemplo, 3802-3804-3810-3812, 3802-3806-3808-3820-3822, e 3802-3814-3826-3818).

Tabela 11 - Depósito de Objeto

<table>table see original document page 92</column></row><table>

A Tabela 12 ilustra as propriedades físicas que podem estar lo-calizadas no depósito de objeto para a entrada de objeto de GUI correspon-<table>table see original document page 93</column></row><table><table>table see original document page 94</column></row><table>

A Figura 39 mostra um exemplo de um sistema analisador descript (SAS) 3900 que pode implementar o analisador de script 170. O SAS3900 inclui uma memória 3902 acoplada a um processador 3904, e uma in-terface 190. Em uma implementação, a interface 190 se comunica com odepósito de metadados de elemento de GUI 138 e um comparador de GUI160 para recebimento de metadados de elemento de GUI 140 e do modelode diferença de GUI 162, respectivamente. A interface 190 é conectada auma rede 3906 (por exemplo, a Internet) em comunicação com vários outrossistemas e recursos. Em uma outra implementação, a memória 3902 incluios metadados de elemento de GUI 140 e uma lógica de modelo de diferençade GUI 3908 que produz o modelo de diferença de GUI 162 e entradas dediferença de elemento de GUI 3910. A memória 3902 também inclui umalógica de analisador gramatical de script 3912 que recebe o script de testeatual 164 e produz a AST 168, processa a AST 168 como uma representa-ção de script de teste atual 3914, e produz os vetores de declaração de s-cript de teste 3916 (por exemplo, 3802-3804-3810-3812, 3802-3806-3808-3820-3822, e 3802-3814-3826-3818).

A memória 3902 ainda inclui uma lógica de análise de script3920 que recebe o modelo de diferença de GUI 162, e a representação descript de teste atual 3914 para o script de teste atual 164, incluindo um vetorde declaração de script de teste 3916. Em uma implementação, a lógica deanálise de script 3920 invoca a lógica de OR Lookup 172 para localizar, nodepósito de objeto 174, uma entrada de objeto de GUI 3922 combinandocom o vetor de declaração de script de teste 3916. Em uma implementação,o analisador de script 170 invoca a lógica de OR Lookup 172 para localizar,em várias fontes externas, uma entrada de objeto de GUI 3922 combinandocom o vetor de declaração de script de teste 3916. Quando o vetor de decla-ração de script de teste 3916 (por exemplo, 3802-3804-3810-3812, 3802-3806-3808-3820-3822, e 3802-3814-3826-3818) emprega constantes para aidentificação de nomes de objeto de GUI, ao invés de expressões cujos valo-res podem ser determinados apenas no tempo de execução, a função de ORLookup 172 pode usar o nome de objeto de GUI e as propriedades do objetode GUI para localizar de forma eficiente a entrada de objeto de GUI correta3922 e localizar, no modelo de diferença de GUI 162, uma entrada de dife-rença de elemento de GUI 3910 combinando com a entrada de objeto deGUI 3922.

Por exemplo, o vetor de declaração de script de teste represen-tado por 3802-3804-3810-3812 identifica a janela StateList de objeto de GUI3302 e o objeto de GUI de caixa de lista SchoolListbox 3316, mostrados nadeclaração de navegação de script de teste atual 164 mostrada na linha 6 daFigura 37:

Window("StateList").WinObject("SchoolListbox").CIick 19,22.

A função de OR Lookup 172 localiza a entrada de objeto de GUI3922 para cada objeto de GUI 3302 e 3316, usando os nomes conhecidosdos objetos de GUI, StateList e SchoolListbox, respectivamente. A função deOR Lookup 172 localiza as entradas de diferença de elemento de GUI cor-respondentes 4504 e 4604, no modelo de diferença de GUI 162. A lógica deanálise de script 3920 extrai uma declaração de script de teste transformado3926 que corresponde a 3402 e 3406:

WindowCSchoon.WinObjectCSchoolCombobox^.Click 294,14.

A lógica de regra de classe de GUI 3928 pode usar os nomes deobjeto de GUI para localização das propriedades usadas para se validar quea declaração de script de teste transformado 3928 não viola as regras demudança de script de elemento de GUI 194 e as restrições. Em uma imple-mentação, o analisador de script 170 usa a lógica de regra de classe de GUI3928 em conjunto com o motor de satisfação de restrição 188 para determi-nação de violações das regras de mudança de script de elemento de GUI194 e restrições.

Por exemplo, quando a declaração de script de teste transfor-mado 3926 acessa objetos de GUI que não existem na versão de GAP sub-sequente 152 e/ou a declaração de script de teste transformado 3926 tentaregular um valor de um objeto de GUI que não é compatível com a classe deGUI daquele objeto de GUI, então, a declaração de script de teste transfor-mado 3926 viola as restrições impostas ao objeto de GUI. O motor de satis-facão de restrição 188 valida a declaração de script de teste transformado3926 para ajudar a verificar que operações incorretas sejam identificadas nadeclaração de script de teste transformado 3926 para um programador re-solver. Em uma implementação, o motor de satisfação de restrição 188 re-cebe uma mensagem de inquisição de compatibilidade (por exemplo, a partirde um sistema externo, tal como o depósito de metadados de elemento deGUI 138) que especifica dois tipos de elemento de GUI. O CSE 188 analisaos dois tipos e retorna uma mensagem de verificação de compatibilidadeque indica se os dois tipos são compatíveis. No caso de a mudança de obje-to de GUI violar uma regra de satisfação de restrição 3932, então, a mensa-gem de verificação de compatibilidade provera uma informação detalhadareferente à violação.

O motor de satisfação de restrição 188 e a lógica de regra declasse de GUI 3928 podem inferir uma informação de classe de GUI referen-te a objetos de GUI que estejam presentes em um caminho de navegaçãode vetores de declaração de script de teste 3916 e declarações de script deteste transformado 3926, e cuja presença não é explicitamente definida. Emuma implementação, o motor de satisfação de restrição 188 e/ou a lógica deregra de classe de GUI 3928 usam uma combinação de validação de tipo detempo de compilação e uma validação de inferência de classe de GUI, demodo a validarem a correção de vetores de declaração de script de teste3916 e declarações de script de teste transformado 3926. Por exemplo,quando o vetor de declaração de script de teste 3916 emprega expressõesque identificam as possíveis entradas de objeto de GUI correspondentes3922 e as entradas de diferença de elemento de GUI 3910 no depósito deobjeto 174 e no modelo de diferença de GUI 162, respectivamente. A lógicade regra de classe de GUI 3928 e o motor de satisfação de restrição 188então identificam as entradas de objeto de GUI válidas 3922 que podemsubstituir as expressões e as entradas de diferença de elemento de GUI3910 que satisfazem aos vetores de declaração de script de teste 3916 e àsdeclarações de script de teste transformado 3926. De modo similar, quandoa declaração de script de teste transformado 3928 emprega expressões queidentificam objetos de GUI cujos valores podem ser determinados apenas notempo de execução, a função de OR Lookup 172 usa a lógica de travessiade caminho 3924 para identificar todas as entradas de diferença de elemen-to de GUI correspondentes 3910 que identifiquem objetos de GUI que pos-sam substituir as expressões, e a lógica de regra de classe de GUI 3928 e omotor de satisfação de restrição 188 validam cada substituição de objeto deGUI pelas expressões usadas para a formação da declaração de script deteste transformado 3928.

Por exemplo, considere a declaração de script de teste transfor-mado 3928: VBWindow("s").VBWindow(e1 ).VBWindow(e2).VBWindow(Md"),onde o objeto de GUI de nó de origem é denominado "s", o objeto de GUI denó de destino é denominado "d", mas as expressões e1 e e2 computam va-lores de nós intermediários no caminho de navegação no tempo de execu-ção. A lógica de travessia 3924 determina nós intermediários (objetos deGUI) que podem ser incluídos nos caminhos de navegação identificados pe-lo nó de origem "s" e pelo nó de destino "d". A lógica de travessia de cami-nho 3924 analisa o modelo de diferença de GUI 162 para identificar possí-veis substituições de constante por e1 e e2, por exemplo, "a" e T, de modoque a declaração de script de teste transformado 3928 formada pelos obje-tos de GUI substitutos na expressão de caminho de navegação "s.a.f.d" pos-sa ser validada pela lógica de regra de classe de GUI 3928 e/ou pelo motorde satisfação de restrição 188. Pela identificação dos possíveis caminhos denavegação levando ao nó de destino d começando com o nó de origem s, alógica de regra de classe de GUI 3928 e o motor de satisfação de restrição188 podem concluir se a declaração de script de teste transformado 3928 éválida. No caso de a lógica de travessia 3924 não identificar pelo menos umcaminho de navegação, então, a declaração de script de teste transformado3928 será inválida. Alternativamente, no caso de a lógica de travessia 3924identificar caminhos de navegação levando a partir de s para d pela traves-sia de dois objetos (por exemplo, e1 e e2), então, a declaração de script deteste transformado 3928 poderá ser válida, desde que as expressões e1 ee2 avaliem para os nomes dos nós nos caminhos de navegação descober-tos. A lógica de travessia 3924 infere os nomes possíveis computados pelasexpressões e1 e e2 no tempo de compilação.

Uma descrição formal da lógica de travessia 3924 é provida comreferência à Figura 47. As expressões e1 e e2 podem ser substituídas pelasvariáveis de nome de objeto a e (3 de forma correspondente, e a expressãooriginal é convertida na estratégia de travessia S = s —► a —► p —>• d. A função'first(s)' computa um conjunto de bordas que podem ser atravessadas a par-tir do nó s. Estas bordas levam a um conjunto de objetos designados pelavariável a. A função 'first(s)' pode ser computada usando-se um algoritmo decapacidade de alcance de gráfico, incluído na lógica de travessia de cami-nho 3924, e a lógica de travessia de caminho 3924 retorna bordas que paraque se pode navegar para o nó de destino. De acordo com a Figura 47, a ={a, b, c}. Então, para cada elemento de a, função 'first' pode ser computada.Como resultado, (5 = {e, f, g} são obtidos, onde 'first(a)' = {e, g}, 'first(b)' = {e},e 'first(c)' = {f}, e tfirst(e)' = {□}, 'first(f)' = {d}, e 'first(g)' = {d}. A partir dos valo-res de nó computados a lógica de travessia de caminho 3924 forma umalista de trabalho W que inclui um conjunto de todos os caminhos computa-dos, W= {(s, a, e), (s, a, g, d), (s, b, e), (s, c, f, d)}. A lógica de travessia decaminho 3924 analisa cada caminho de navegação de W para determinar seo caminho de navegação contém os nós s e d. Os caminhos de navegaçãoidentificados pela lógica de travessia de caminho 3924 como incluindo osnós s e d, como nós de origem e de destino, são considerados como cami-nhos de navegação válidos. No caso de nenhum caminho de navegação seridentificado pela lógica de travessia de caminho 3924, então, a declaraçãode script de teste transformado 3928 será inválida, porque o elemento deGUI alvo não pode ser alcançado começando-se a partir do elemento deGUI de começo especificado. A lógica de travessia 3924 de modo similarvalida os vetores de declaração de script de teste 3916.

Com referência de novo à Figura 47, um exemplo de uma ex-pressão inválida é VBWindow("s").VBWindow(e1). VBWin-dow(e2).VBWindow(e3).VBWindow("d"). Todos os caminhos de navegaçãoentre os nós s e d têm no máximo dois objetos. Portanto, não importandoque valores são computados no tempo de execução para as expressões e1,e2 e e3, as expressões não podem representar objetos em um caminho denavegação válido entre os objetos de origem e de destino. U outro exemplode uma expressão inválida é VBWin-

dow("s").VBWindow("b").VBWindow(e1 ).VBWindow("d"), porque nenhumvalor para a expressão e1 existe que torne o caminho de navegação válido(isto é, que forme um caminho completo de 's' para 'd').

O motor de satisfação de restrição 188 e a lógica de regra declasse de GUI 3928 podem inferir uma informação de classe de GUI referen-te a objetos de GUI que estejam presentes no caminho de navegação devetores de declaração de script de teste 3916 e declarações de script de tes-te transformado 3926. Um recurso da SAA 108 é manter a compatibilidadede operações nos objetos de GUI entre scripts de teste sucessivos. Quandouma declaração de script de teste transformado 3926 tenta acessar objetosde GUI que não existem em uma versão GAP subsequente 152 e/ou tentaregular um valor de um objeto de GUI que não é compatível com o tipo doobjeto de GUI, a declaração de script de teste transformado 3926 viola asentradas de regras de mudança de script de elemento de GUI 3930 e/ou asregras de satisfação de restrição 3932 impostas no objeto de GUI. O motorde satisfação de restrição 188 e a lógica de regra de classe de GUI 3928podem checar cada declaração de script de teste transformado potencial3926, antes da inclusão do vetor no script de teste transformado 178, demodo que operações inválidas possam ser identificadas e mensagens deguia de mudança correspondentes 3938 possam ser extraídas.

O motor de satisfação de restrição 188 e a lógica de regra declasse de GUI 3928 usam relações de herança e subtipificação entre asclasses de objetos de GUI. O conceito de classe inclui contenções hierárqui-cas (por exemplo, escopos de GUI e hierarquias de sistema). O depósito deobjeto 174 e o modelo de diferença de GUI 162 incluem uma informação declasse de GUI (por exemplo, anotação das classes de objetos de GUI) paracada entrada de objeto de GUI 3922 e entrada de diferença de elemento deGUI 3910. Por exemplo, com referência à linha 1 da Tabela 12, a School-ListBox é uma classe de WinObject com propriedades listadas nas linhas 3-39. Em um outro exemplo, com referência às Figuras 36, 45 e 46, na linha 1de cada entrada de diferença de GUI (por exemplo, 3604, 4504 e 4604) oGUIEIement Type é indicado. A classe de cada objeto de GUI é indicadaconforme mostrado nas Figuras 36, 45 e 46, nas linhas 7, 8 e 8, respectiva-mente. A classe de um objeto de GUI indica que o objeto de GUI inclui atri-butos, propriedades e/ou tratos em particular em comum com outros objetosde GUI da mesma classe que podem ser estendidos e/ou herdados pelosobjetos de GUI filhos. Por exemplo, a Figura 36 na linha 7 indica que o obje-to de GUI StateListbox é de uma classe WindowsForms10.ListBox.app4 queinclui valores, conforme indicado na linha 11 da Figura 36. Em outras pala-vras, uma propriedade de objetos de GUI de WindowsForms10.ListBox.app4é que estes objetos de GUI são esperados como tendo valores. A classe éum conceito que uma estrutura de GUI usa para a classificação de objetosde GUI. Por exemplo, a classe ListBox define formato, funcionalidade e asregras de interatividade para objetos de GUI nesta classe. A atribuição declasses a objetos de GUI facilita o motor de satisfação de restrição 188 e alógica de regra de classe de GUI 3928 a rastrearem mudanças entre versõesde GAP sucessivas (por exemplo, 150 e 152) e a realizarem uma checagemestendida na correção de operações em objetos de GUI.

Com referência de novo à Figura 39, em uma implementação, alógica de regra de classe de GUI 3928 e o motor de satisfação de restrição188 determinam se um objeto de GUI mudou e regulam o status de mudan-ça de elemento de GUI 3934. Por exemplo, o status de mudança de elemen-to de GUI 3934 pode usar um indicador numérico de 0, 1 e 2, respectiva-mente, para indicar que um objeto de GUI não foi mudado, mudou com oumudou sem violações de regras de mudança de script de elemento de GUI194 e/ou regras de satisfação de restrição 3932. A lógica de análise de script3920 pode usar o status de mudança de elemento de GUI 3934, as entradasde regras de mudança de script de elemento de GUI 3930 e as regras desatisfação de restrição 3932 para buscar no depósito de mensagem de guiade mudança 192 e identificar o especificador de mudança apropriado 184 eos identificadores de mensagem de guia de mudança 3936. As entradas deregras de mudança de script de elemento de GUI 3930 podem indicar se umelemento de um objeto de GUI pode ser mudado de uma forma em particu-lar. Por exemplo, as regras de mudança de script de elemento de GUI 3930podem indicar que um elemento de um objeto de GUI em particular não po-de ser mudado apenas de leitura para editável. Em um outro exemplo, umamudança para a classe de um objeto de GUI pode resultar em um objeto deGUI filho violando uma regra de mudança de script de elemento de GUI3920, porque um ou mais atributos do objeto de GUI filho estão em conflitocom uma mudança de classe do elemento de GUI pai. Além disso, um botãopode ser substituído por itens de menu, e ações que são corretas para aces-so e manipulação de botões não funcionarão para menus.

Em uma outra implementação, o status de mudança de elemen-to de GUI 3934 é uma mensagem que prove uma descrição detalhada damudança. O status de mudança de elemento de GUI 3934 também podeindicar com um indicador numérico (Por exemplo, -1) que o objeto de GUI foiapagado da versão de GAP subsequente 152. Quando um objeto de GUI foiapagado da versão de GAP subsequente 152 e uma declaração de script deteste transformado 3926 inclui uma referência ao objeto de GUI, a lógica deanálise de script 3920 extrai uma mensagem de guia de mudança 3938 queindica que o objeto de GUI foi apagado.

Em uma implementação, a lógica de análise de script 3920 extraium especificador de mudança 184 que inclui uma declaração de script deteste transformado 3926 que viola uma regra de mudança de script de ele-mento de GUI 194 e/ou uma regra de satisfação de restrição 3932, de modoque um programador pode avaliar se é para modificar a declaração de scriptde teste transformado 3926 e/ou a versão de GAP subsequente 152 para aobtenção de um resultado desejado e/ou se adequar a uma exigência dese-jada que, de outra forma, pode não ter sido evidente. Em uma outra imple-mentação, a lógica de análise de script 3920 proíbe a saída de declaraçõesde script de teste transformado 3926 que violem certas regras de mudançade script de elemento de GUI 194 e regras de satisfação de restrição 3932.

Cada uma das regras de mudança de script de elemento de GUI 194 e re-gras de satisfação de restrição 3932 pode incluir indicadores que indiquem onível ou a severidade de uma violação e se a lógica de análise de script3920 pode extrair uma declaração de script de teste transformado 3926, em-bora uma violação tenha ocorrido. Independentemente de a lógica de análisede script 3920 extrair uma declaração de script de teste transformado 3926,a lógica de análise de script 3920 pode extrair um guia de mudança 180 queinclua mensagens de guia de mudança 3938 correspondentes a cada umadas violações.

Para cada status de mudança de elemento de GUI 3934 queindique uma mudança na violação de regras de mudança de script de ele-mento de GUI 194 e/ou regras de satisfação de restrição 3932, a lógica deanálise de script 3920 extrai um conjunto de identificadores de mensagemde guia de mudança 3936 e mensagens de guia de mudança corresponden-tes 3938. As mensagens de guia de mudança 3938 podem incluir o tipo deapagamento de caminho errado (WP-1) 3940, o tipo de mesmo caminho er-rado (WP-2) 3942 e o tipo de elemento mudado (CE-1 e CE-2) 3944. O guiade mudança 180 e as mensagens de guia de mudança 3938, incluindo 3940,3942 e 3944, são descritas em mais detalhes abaixo.

A Figura 40 mostra um fluxograma 900 para a recuperação daspropriedades de uma entrada de objeto de GUI 3922 a partir de um depósitode objeto (OR) 174. A lógica de analisador gramatical de script 3912 analisagramaticalmente o vetor de declaração de script de teste 3916 em uma se-qüência ordenada de nós que representam funções e argumentos que nave-gam para objetos de GUI (4002). A lógica de analisador gramatical de script3912 avalia o primeiro nó da seqüência ordenada de nós (4004) e identificao primeiro nó como o nó de origem e atribui um identificador de seqüênciaindicando a posição do nó de origem na seqüência ordenada (4006). A lógi-ca de analisador gramatical de script 3912 avalia o próximo nó da seqüênciaordenada de nós para determinar se o próximo nó é o último nó (4008), eidentifica o próximo nó como um nó intermediário, quando o próximo nó nãofor o último nó (4010). Ao nó intermediário é atribuído um identificador deseqüência indicando a posição do nó intermediário na seqüência ordenada.A lógica de analisador gramatical de script 3912 pode identificar todos osnós intermediários entre o nó de origem e o nó de destino.A lógica de analisador gramatical de script 3912 identifica o últi-mo nó na seqüência ordenada como o nó de destino e atribui um identifica-dor de seqüência ao nó de destino que indica a posição do nó de destino naseqüência ordenada (4012). A OR Lookup 172 realiza uma consulta de de-pósito de objeto para cada objeto de GUI correspondente à seqüência orde-nada de nós para os quais o vetor de declaração de script de teste navega,de modo que cada entrada de objeto de GUI 3922 seja identificada (4014).Em uma implementação, a seqüência ordenada de nós é usada pela lógicade travessia de caminho 3924, pela lógica de regras de classe de GUI 3928e/ou pelo motor de satisfação de restrição 188 para validação das declara-ções do script de teste atual 164. Em uma implementação, o analisador descript 170 usa a seqüência ordenada de nós para inferir a classe de GUI euma informação de herança (subclasse) para objetos de GUI. Quando pelomenos um dentre os nós de origem, de destino e/ou intermediário é de ex-pressões que podem ser prontamente identificadas no tempo de execução, alógica de travessia de caminho pode identificar possíveis entradas de objetode GUI 3922, e a lógica de regra de classe de GUI 3928 e/ou o motor desatisfação de restrição 188 determinam as entradas de objeto de GUI 3922que satisfazem o vetor de declaração de script de teste 3916, sem violaçãoda lógica de regra de classe de GUI 3928 e das regras de satisfação de res-trição 3932. A OR Lookup 172 recupera as propriedades das entradas deobjeto de GUI 3922 para as quais o vetor de declaração de script de testenavega (4016).

A Figura 41 mostra um fluxograma 4100 para a identificação deuma entrada de diferença de elemento de GUI 3910 correspondente a umaentrada de objeto de GUI 3922. A OR Lookup 172 recebe as propriedadesdos objetos de GUI correspondentes aos nós de origem, de destino e todosos intermediários do vetor de declaração de script de teste 3916. Em umaimplementação, a OR Lookup 172 emprega a lógica de travessia de caminho3924 para a identificação de possíveis entradas de diferença de elemento deGUI 3910 correspondentes aos caminhos de navegação identificados por umnó de origem e um nó de destino para o qual um vetor de declaração de s-cript de teste navega (4102). Quando pelo menos uma das entradas de dife-rença de elemento de GUI 3910 é uma expressão que pode ser identificadaapenas no tempo de execução, a lógica de travessia de caminho 3924 iden-tifica uma ou mais entradas de diferença de elemento de GUI 3910 que for-mam um caminho de navegação entre o nó de origem e o nó de destino(4104). A lógica de travessia de caminho 3924 determina se as entradas dediferença de elemento de GUI 3910 formam um caminho de navegação váli-do entre as entradas de diferença de elemento de GUI 3910 de nós de ori-gem e de destino correspondentes (4106). A lógica de regra de classe deGUI 3928 e/ou o motor de satisfação de restrição 188 determinam se as en-tradas de diferença de elemento de GUI 3910 que formam o caminho de na-vegação violam a lógica de regra de classe de GUI 3928 (4108) e a regrasde satisfação de restrição 3932 (4110).

A lógica de regra de classe de GUI 3928 e/ou o motor de satis-facão de restrição 188 indicam as entradas de diferença de elemento de GUI3910 que correspondem a cada uma das entradas de objeto de GUI 3922formando um caminho de navegação válido (4112). A lógica de análise descript 3920 determina o especificador de mudança de saída com base notipo de mudança de elemento de GUI (por exemplo, o status de mudança deelemento de GUI 3934) indicado pelos resultados da lógica de regras declasse de GUI 3928 e do motor de satisfação de restrição 188, com base naentrada de diferença de elemento de GUI 3910 (4114).

Quando a lógica de travessia de caminho 3924 identifica umcaminho de navegação que atravessa um número inválido de entradas dediferença de elemento de GUI 3910 entre as entradas de diferença de GUI3910 de nó de origem e de destino correspondentes, a lógica de travessia decaminho 3924 indica que o caminho de navegação é inválido (4116). Emuma implementação, os caminhos de navegação inválidos não são analisa-dos pela lógica de regras de classe de GUI 3928 e pelo motor de satisfaçãode restrição 188, e uma declaração de script de teste transformado 3926 nãoé extraída como resultado. Em uma implementação, a lógica de travessia decaminho 3924 extrai uma mensagem de aviso identificando os caminhos denavegação inválidos. Em uma outra implementação, o guia de mudança in-clui uma mensagem de aviso indicando os caminhos de navegação inváli-dos. O guia de mudança 180 pode incluir várias mensagens de aviso querefletem qualquer número de condições identificadas durante um processa-mento pelo analisador de script 170. O guia de mudança 180 pode incluirmensagens de aviso e/ou de informação correspondentes às condições en-contradas pelo analisador de script 170 e/ou qualquer uma das lógicas doanalisador de script 170 (por exemplo, a lógica de analisador gramatical descript 3912, a lógica de análise de script 3920, a lógica de OR Lookup 172, alógica de travessia de caminho 3924 e a lógica de regras de classe de GUI3928) e/ou o motor de satisfação de restrição 188. A lógica de análise descript 3920 pode extrair um guia de mudança 180 com mensagens de guiade mudança 3938 (por exemplo, 3940, 3942 e 3944) correspondentes àsviolações de lógica de regras de classe de GUI 3928 e de regras de satisfa-ção de restrição 3932 (4118).

A Figura 42 mostra um script de teste transformado 178 para aversão de GAP subsequente 152. O script de teste transformado 178 podeincluir declarações automaticamente transformadas pela lógica de análise descript 3920. O script de teste transformado 178 também pode incluir declara-ções introduzidas manualmente após uma revisão do guia de mudança 180.No exemplo mostrado na Figura 42, a lógica de análise de script 3920 extraio script de teste transformado 178 com as declarações de script de testetransformado nas linhas 1, 6-11, 14-19, e 21-22, enquanto um escritor descript manualmente introduziu as linhas 2-4. A lógica de análise de script3920 determina as declarações de script de teste transformado 3926 a extra-ir para o script de teste transformado 178 com base na lógica de regras declasse de GUI 3928 e nas regras de mudança de script de elemento de GUI194. A complexidade da lógica de regras de classe de GUI 3928 e das re-gras de mudança de script de elemento de GUI 194 e a riqueza do modelode diferença de GUI 162 e dos metadados de elemento de GUI podem serespecificadas em qualquer nível de complexidade para condução quanto sepuder do script de teste transformado 178 a lógica de análise de script 3920extrair sem uma entrada de programador.

Por exemplo, a lógica de análise de script 3920 transforma aslinhas 1-3 do script de teste atual 164, mostrado na Figura 37, em declara-ções de script de teste transformado 3926, linhas 1, 5-7, mostradas na Figu-ra 42. um programador pode introduzir as linhas 2-4 do script de teste trans-formado 178, porque aquelas linhas incluem objetos de GUI novos (por e-xemplo, "ToolbarWindow32" e valores "My Computer") para os quais o mo-delo de diferença de GUI 162 pode não incluir uma informação que identifi-que um objeto de GUI correspondente na versão de GAP atual 150. Em umaimplementação, o modelo de diferença de GUI 162 e os metadados de ele-mento de GUI provêem a classe de GUI, a tipificação de GUI e uma informa-ção de mapeamento necessárias para a lógica de análise de script 3920 in-ferir as linhas 2-4 do script de teste transformado 178, dado que "univer-sity.data" na linha 6 representa um destino em uma travessia de caminho apartir da qual declarações de script de teste intermediárias podem ser de-terminadas. Em um outro exemplo, o modelo de diferença de GUI 162 e/ouos metadados de elemento de GUI incluem uma classe de GUI e uma infor-mação de mapeamento que o analisador de script 170 usa para a transfor-mação da linha 11 do script de teste atual 164 que se refere ao WinObject"Save File" nas declarações de script de teste transformado 3926 nas linhas16-17 que se referem a um objeto de GUI filho "Save File" do WinObject"menuStripl".

A Figura 43 mostra um guia de mudança 180 que o analisadorde script 180 pode extrair. Em uma implementação, a lógica de análise descript 3920 extrai um especificador de mudança 184 que indica se a declara-ção de script de teste transformado 3926 viola uma regra de mudança descript de elemento de GUI 194 com base em uma análise realizada pela ló-gica de regras de classe de GUI 3928 e/ou pelo motor de satisfação de res-trição 188. O analisador de script 170 extrai especificadores de mudança184 que também podem incluir as declarações de script de teste transforma-do 3926. O analisador de script 170 determina as modificações nos objetosde GUI e nas declarações de script de teste transformado 3928 que são afe-tadas pelas modificações nos objetos de GUI aos quais as declarações descript de teste transformado 3928 se referem. Em uma implementação, alógica de análise de script 184 determina os objetos de GUI referidos no s-cript de teste atual 164 que são apagados na versão de GAP subsequente152. O analisador de script 170 extrai os especificadores de mudança 184que podem incluir as mensagens de guia de mudança 3938, as declaraçõesde script de teste transformado 3926 e/ou ambas. Em uma implementação, oanalisador de script 170 extrai especificadores de mudança 184 que incluemidentificadores de mensagem de guia de mudança 3930, declarações descript de teste transformado 3926 e/ou ambas.

Alguns dos tipos de mudanças em objetos de GUI entre libera-ções para edição sucessivas de GAPs que o analisador de script 170 podeidentificar em uma mensagem de guia de mudança 3938 incluem: (A) umnovo objeto de GUI adicionado a uma versão de GAP subsequente 152; (B)um objeto de GUI é apagado de uma versão de GAP subsequente 152; (C)os valores de um ou mais atributos de um objeto de GUI são modificados;(D) os valores de um objeto de GUI são diferentes; e (E) o tipo de um objetode GUI é diferente. As mudanças de objeto de GUI dos tipos A e B ocorremquando objetos de GUI são adicionados e removidos de forma correspon-dente a partir de uma versão de GAP atual 150 e uma versão de GAP sub-sequente 152. Por exemplo, a adição de WinObject menustripl 3408 à ver-são de GAP subsequente 152 é uma mudança de tipo A, enquanto a remo-ção do WinObject "Select School" 3304 é uma mudança de objeto de GUI detipo B. Com referência à Figura 4, note que "Select School" foi removido em412.

Um exemplo de uma mudança de tipo C é a mudança do nomede janela de StateList 3302 para School 3402. A adição ou a remoção devalores de objetos de GUI tais como caixas de lista e de combinação é umexemplo de modificações da mudança de tipo D. Por exemplo, a caixa delista StateListbox 3312 na versão de GAP atual 150 é identificada na versãode GAP subsequente 152 como StateListbox 3404, e com referência à en-trada de diferença de GUI 3604, os valores para SeqNumber = "8" são "Dis-trict of Columbia" e "Florida" para versões de GAP sucessivas, respectiva-mente. A mudança do "tipo" de um objeto de GUI pode incluir a substituiçãode uma classe da janela que é usada para representação do objeto e/ou pe-la mudança do conceito de nível alto que descreve os valores que o objetode GUI assume. Por exemplo, mudar o tipo de rótulo estático para uma caixade combinação apenas de leitura é uma modificação do tipo E. Um outroexemplo de uma mudança do tipo E inclui a mudança da caixa de lista "S-chooListbox" 3316 para uma caixa de combinação "SchoolCombobox" 3406.

O analisador de script 170 classifica os tipos de mudanças que alógica de regras de classe de GUI 3928 e/ou o motor de satisfação de restri-ção 188 identificam, incluindo: erros de tipo 1 de caminho errado (WP-1) queocorrem quando um script acessa os objetos de GUI que podem estar apa-gados na versão de GAP subsequente 152 (por exemplo, veja "Select Scho-ol" 3318 e 412 conforme mostrado na Figura 4). Os erros de WP tipo 2 (WP-2) ocorrem em scripts que são lidos ou escritos em objetos de GUI errados.Os erros de WP-2 ocorrem quando as declarações de script de teste trans-formado 3926 navegam para objetos de GUI errados e lêem os valores doobjeto de GUI errado e/ou invocam métodos no objeto de GUI errado.

Por exemplo, considere a declaração nas linhas 2 e 6 do scriptde teste atual 164 e do script de teste transformado 178, respectivamente:Window("StateList").Dialog("Open").WinListView("SysListView32").Select"university.data".

A declaração seleciona "university.data" a partir de uma Win-ListView "SysListView32". Contudo, as linhas 2-4 do script de teste transfor-mado 178 podem navegar para e invocar o método Select no objeto de GUIerrado "university.data", porque os objetos de GUI referenciados nas linhas2-4 do script de teste transformado 178 são novos objetos de GUI que nãosão referenciados no script de teste atual 164. Assim, quando as proprieda-des de objetos de GUI existentes são modificadas e/ou outros objetos deGUI são adicionados em uma versão de GAP subsequente 152, o resultadode interferência destas operações é que a declaração de script de testetransformado 3926 pode acessar e ler valores de objetos que são diferentesdaqueles conforme pretendido originalmente.

Erros de Elemento Mudado (CE) ocorrem quando declaraçõestentam acessar objetos de GUI cujos tipos, propriedades ou valores-padrãosão mudados na versão de GAP subsequente 152 (CE-1). Por exemplo, aentrada de diferença de GUI 3604 indica que há valores diferentes paraSeqNumber = "8" que são "District of Columbia" e "Florida" para versões deGAP sucessivas, e a lógica de análise de script 3920 pode emitir, conse-quentemente, uma mensagem de guia de mudança 3944 indicando que umerro de tipo CE-1 ocorreu.

A lógica de análise de script 3920 pode emitir uma mensagemde guia de mudança 3944 correspondente a um erro de tipo CE-2, quandouma declaração de script de teste transformado 3926 tentar uma operaçãoem um objeto de GUI que não leve em consideração novas restrições impos-tas nos elementos, por exemplo, tentar escrever dados em uma caixa detexto apenas de leitura. Com referência à entrada de diferença de elementode GUI mostrada na Tabela 13, o WinObject "AcadScale" referido no scriptde teste atual 164 na linha 8 é um objeto editável que foi transformado noWinObject "Academics (1-5)" na versão de GAP subsequente 152, onde oobjeto é apenas de leitura. Em uma implementação, a lógica de análise descript 3920 extrai uma mensagem de guia de mudança 3944 para indicarque uma mudança de tipo de CE-2 ocorreu.

Tabela 13 - Entrada de Diferença de Elemento de GUI para AcadScale

<table>table see original document page 110</column></row><table><table>table see original document page 111</column></row><table>

Conhecer o tipo de modificação para um objeto de GUI facilita alógica de análise de script 3920 na determinação da mensagem de guia demudança apropriada 3938 e nas declarações de script de teste transformado3926 a extrair. Por exemplo, quando uma declaração de script de testetransformado 3926 tenta regular valores em um objeto de caixa de texto,embora o tipo de objeto tenha mudado para uma caixa de combinação ape-nas de leitura, a lógica de análise de script 3920 extrai mensagens de guiade mudança 3944 que sugerem como modificar a declaração de script deteste transformado 3926 para valores de seleção na caixa de combinaçãousando interfaces apropriadas.

A Figura 44 mostra um fluxograma para extração de declaraçõesde script de teste transformado 3926. A lógica de análise de script 3920 revêo status de mudança de elemento de GUI 3934 de cada objeto de GUI refe-rido no script de teste transformado 178, na versão de GAP atual 150 e/ouna declaração de script de teste transformado 3926 (4402). A lógica de aná-lise de script 3920 determina se os objetos de GUI da declaração de scriptde teste transformado foram adicionados à versão de GAP subsequente 152(4404). A lógica de regras de classe de GUI 3928 e/ou o motor de satisfaçãode restrição 188 podem analisar os objetos de GUI adicionados para deter-minarem se um erro de WP-2 ocorreu como resultado das declarações descript de teste transformado 3926 navegando para objetos de GUI errados(por exemplo, dois objetos de GUI incorretamente usando aliases idênticos)e lêem os valores do objeto de GUI errado e/ou invocam métodos no objetode GUI errado (4406). A declaração de script de teste transformado 3926 éincluída no script de teste transformado 178 e mensagens de guia de mu-dança 3938 correspondentes são extraídas (4408).

Quando a lógica de análise de script 3920 determina que objetosde GUI foram removidos de uma versão de GAP atual 150 (4410). A lógicade análise de script 3920 localiza as declarações que referenciam estes ob-jetos removidos no script de teste atual 178. O analisador de script 170 serefere a estas declarações como declarações de primeira referência (FRS)(4412). As variáveis usadas nestas declarações são obtidas, e as declara-ções que usam as variáveis cujos valores são definidos nas FRSs são refe-ridas como declarações de referência secundária (SRS) (4414). A lógica deregras de classe de GUI 3928 e/ou o motor de satisfação de restrição 188podem analisar os objetos de GUI para determinarem se erros de WP-1 o-correram, com base nas declarações de script tentando acessar objetos deGUI que foram apagados em uma versão de GAP subsequente 152 (4416).Quando uma declaração do script de teste atual 178 se refere a uma variávelcujo valor aponta para um objeto de GUI removido, a declaração do script deteste atual 3926 é considerada uma SRS. Em uma implementação, o anali-sador de script 170 extrai as SRSs identificadas como declarações de scriptde teste transformado 3926 e mensagens de guia de mudança 3938 corres-pondentes, de modo que o pessoal de teste possa recuperar e decidir comomodificar as SRSs (4408).

Quando os valores de um ou mais atributos de um objeto de GUIsão modificados, uma modificação de tipo C é realizada (4418). FRSs e S-RSs são identificadas nas declarações de script de teste transformado 3926para o objeto de GUI com os atributos modificados e mensagens de guia demudança 3938 são extraídas. Quando os valores de objetos de GUI são adi-cionados ou removidos, modificações do tipo D ocorrem (4418). Após a loca-lização de FRSs que referenciam objetos de GUI cujos valores foram muda-dos, as SRSs são encontradas e o analisador de script determina o impactodevido as SRSs. Quando o tipo de um objeto de GUI é modificado, então,uma modificação do tipo E ocorre, que envolve a localização de FRSs, che-car os novos tipos do objeto de GUI, invocar as regras de subsunção de tipocorrespondente (por exemplo, regras que a lógica de regras de classe deGUI 3928 pode aplicar) (4418). A lógica de regras de classe de GUI 3928e/ou o motor de satisfação de restrição 188 pode analisar os objetos de GUImodificados para determinarem se erros de CE-1 e CE-1 ocorreram, comoresultado da declaração de script de teste transformado 3926 tentar acessarobjetos de GUI cujos tipos, propriedades ou valores-padrão são mudadosem uma versão de GAP subsequente 152, e/ou tentar uma operação em umobjeto de GUI que não leva em consideração novas restrições impostas noselementos do objeto de GUI (4420). Em uma implementação, o analisadorde script 170 extrai as SRSs identificadas como declarações de script deteste transformado 3926 e mensagens de guia de mudança 3938 correspon-dentes, de modo que o pessoal de teste possa rever e decidir como modifi-car as SRSs (4408).

A Figura 48 mostra um fluxograma para extração de um especi-ficador de mudança de GAP 184. Um modelo de diferença de GUI 162 éproduzido (4802) e um analisador de script 170 recebe o modelo de diferen-ça de GUI 162 e os metadados de elemento de GUI 140 (4804). O analisa-dor de script 170 recebe uma representação de script de teste atual 3914que inclui um vetor de declaração de script de teste 3916 (4806). A lógica deanalisador gramatical de script 3912 analisa gramaticalmente o vetor de de-claração de script de teste 3916 em nós de vetor para determinar os objetosde GUI para os quais o vetor de declaração de script de teste 3916 navega(4808). A representação de script de teste atual 3914 invoca a OR Lookup172 para cada objeto de GUI identificado pelo vetor de declaração de scriptde teste 3916 para recuperação das propriedades dos objetos de GUI a par-tir do depósito de objeto 174 (4810). A lógica de travessia de caminho 3924analisa o caminho de navegação das entradas de diferença de elemento deGUI 3910 que corresponde aos objetos de GUI identificados pelo vetor dedeclaração de script de teste 3916 (4812). A lógica de regras de classe deGUI 3928 analisa as entradas de diferença de elemento de GUI 3910 combase na lógica de regras de classe de GUI 3928 e nas regras de mudançade script de elemento de GUI 3930 para a identificação de entradas de dife-rença de elemento de GUI válidas 3910 às quais o caminho de navegaçãocorresponde (4814). O motor de satisfação de restrição 188 analisa as en-tradas de diferença de elemento de GUI 3910 com base nas regras de satis-fação de restrição 3932 para determinar o tipo de especificador de mudançaa extrair, incluindo se é para extrair uma declaração de script de teste trans-formado 3926, uma mensagem de guia de mudança 3938 ou ambas (4816).A lógica de análise de script 3920 extrai um especificador de mudança cor-respondente ao tipo de mudança de elemento de GUI identificada pela lógicade classe de GUI 3928 e pelas regras de satisfação de restrição 3932(4818).

Em uma implementação, a SAA 108 usa uma programação a-daptativa incluindo gráficos de classe e de objeto e uma abstração que tratatodos os objetos uniformemente. A lógica de travessia 3924, o motor de sa-tisfação de restrição 188 e a lógica de regras de classe de GUI 3928 podemdistinguir tipos complexos e simples dos objetos de GUI. Os tipos complexoscontêm campos enquanto os tipos simples não. Seja T conjuntos finitos denomes de tipo e F de nomes de campo ou rótulos, e dois símbolos distintosisto □ F e □□ F. Os gráficos de tipo são gráficos diretos G= (V, E, L), demodo que:

V □ T, os nós são nomes de tipo;

L □ F, as bordas são rotuladas por nomes de campo, ou "□" on-de campos não têm nomes. As bordas que são rotuladas por "□" são deno-minadas bordas de agregação, e bordas que são rotuladas por nomes bor-das de referência de campo. A diferença entre bordas de agregação e dereferência se torna clara com o exemplo a seguir. Os campos de classes emlinguagens orientadas para objeto designam instâncias de algumas classes,e estes campos têm nomes que são usados para a referência aos campos.Cada campo de uma classe é definido pelo nome do campo e pelo nome daclasse (tipo) de que este campo é uma instância. O nome de um campo é orótulo da borda de referência correspondente no gráfico de tipo.

Quando uma classe designa um objeto de GUI Ok e a outra clas-se designa um objeto de GUI on que está contido no objeto o*,- o gráfico detipo tem dois nós, um para o objeto Ok e o outro para o objeto on que o objetoOk contém. Os nomes das classes correspondentes servem como seus tipos.

A relação entre dois objetos sem nome é representada usando-se a bordarotulada com o "□" no gráfico de tipo.

E □ LxVxV, as bordas são produtos vetoriais de rótulos e nós;para cada v □ V, os rótulos de todas as bordas de saída comexceção de "□" são distintos;para cada v □ V, onde v representa um tipo concreto, v , his >v□ E.

Um objeto gráfico é um gráfico dirigido rotulado O = (V1, E', U)que é uma instância de um gráfico de tipo G = (V, E, L) sob uma dada fun-ção Class que mapeia objetos para suas classes, se as condições a seguirforem satisfeitas:

para todos os objetos o □ V, o é uma instância do tipo concretodada pela função Class(o);para cada objeto o □ V, os rótulos de suas bordas de referênciade saída são exatamente aqueles do conjunto de rótulos de referências deClass(o) incluindo bordas e seus rótulos herdados de classes pais;

para cada borda o—e-^-o' ü E', Class(o) tem uma borda de refe-rência v—e—>u de modo que v seja um tipo pai de Class(o) e u seja um tipopai de Class(o').

Um gráfico de objeto é um modelo dos objetos, representadosem GAPs, e suas referências a cada outro. Uma coleção de campos em umgráfico de objeto é um conjunto de bordas rotuladas por nomes de campo.

Uma coleção de objetos agregados em um gráfico de objeto é um conjuntode bordas rotuladas por Um caminho em um gráfico de tipo G = (V, E, L)é uma seqüência de nós e rótulos pG = (yoei,vie2,...envn), onde Vi □ V evi —^í—» vi +1 para 0 £ i ^ n. Um caminho concreto é definido como umaseqüência alternada de nomes de tipo e rótulos designando bordas de refe-rência. Em geral, um caminho A concreto é definido como uma seqüênciaalternativa de nomes de tipo e rótulos designando bordas de referência. Emgeral, um caminho concreto pc é um subconjunto do caminho de tipo corre-spondente pc isto é, pc □ Pg-

Um gráfico de objeto tem o objeto especial or □ V, or é uma co-leção de objetos de raiz or □ V no gráfico de objeto O dado pela função root:O—► or. Este objeto tem type Class(or) tipo = raiz e sua relação com objetosem sua coleção é expressa através de or -> o' □ E'.

Dado um objeto o de algum tipo, a lógica de travessia 3924, omotor de satisfação de restrição 188 e a lógica de regras de classe de GUI3928 podem trabalhar em conjunto para a identificação de um ou mais obje-tos alcançáveis que satisfaçam a certos critérios. A tarefa realizada é equiva-lente a determinar se os vetores de declaração de script de teste 3916 e/ouas declarações de script de teste transformado 3926 que descrevem os ca-minhos de navegação são válidos. Os caminhos de navegação especifica-dos nas declarações de script de teste transformado 3926 podem ser pen-sados como uma especificação de restrições para o problema de capacida-de de alcance de objeto. Encontrar objetos alcançáveis é feito através detravessias. A travessia de uma borda rotulada e corresponde à recuperaçãodo valor do campo e. Toda borda no gráfico de objeto é uma imagem deuma borda que tem parte no gráfico de tipo: há uma borda e(oi, o2) em Oapenas quando existirem os tipos vi e V2 de modo que o objeto 01 seja detipo vi, vi tenha uma e-parte de tipo v2, e o2 seja de tipo v2.

O primeiro nó de um caminho p é denominado a origem de p e oúltimo nó é denominado o destino de p. Uma travessia de um gráfico de ob-jeto O começada com um objeto Vj e guiada por caminhos a partir de umconjunto de caminhos p é feita pela realização de uma busca primeiro naprofundidade em O com p usado para podar a busca. O histórico de traves-sia resultante é uma travessia primeiro na profundidade do gráfico de objetoao longo de caminhos de objeto de acordo com o dado conjunto de caminhoconcreto.

O problema de identificação de todos os objetos alcançáveis apartir de um dado objeto o que satisfaz a certos critérios é formalizado con-forme se segue. Para cada par de classes c e c', um conjunto de bordas epode ser identificado pela computação de FIRST(c, c') caso seja possívelque um objeto de tipo c alcance um objeto de tipo c' por um caminho come-çando com uma borda e. Mais precisamente, FIRST(c, c') = e □ E, de modoque exista um gráfico de objeto O de C e objetos o e o' de modo que: 1)Class(o) = c; 2) Class(o') = c'; e 3) o e*o'.

A última condição, o e* o' indica que existe (□) um caminho apartir de o para o' no gráfico de objeto, consistindo em uma borda rotulada e,seguido por qualquer seqüência de bordas no gráfico. A falta de informaçãosobre o gráfico real é representada pelo operador de existência □.

A tarefa de checagem estática de scripts de teste (por exemplo,scripts de teste transformados 178) é grandemente simplificada quando osnomes de nomes de componentes estranhos são definidos como constantesde string. Quando os nomes de objetos de GUI são especificados usando-seexpressões, os valores destas expressões não podem ser determinados atéo tempo de execução. Os gráficos de tipo facilitam o sistema analisador descript 3900 para inferir tipos de expressões e variáveis que mantêm os no-mes de objetos de GUI. O sistema analisador de script 3900 aplica conceitoscom base na Análise de Gráfico de Travessia (TGA) definida em uma pro-gramação adaptativa para inferência de tipos de expressões e variáveis.

Uma estratégia S=(R, tt, õ) representa caminhos em um gráficode objeto, onde R={s, d}, onde s e d são os objetos de GUI de origem e dedestino de um caminho em um gravador, e R □ O, onde O é o conjunto deobjetos em um gráfico de tipo, tt = {e, a}, onde e é um conjunto de campos ea é um conjunto de variáveis que designam um conjunto de algumas bordasa □ e, e õ = {□,□} é um conjunto de variáveis de transição representandoobjetos e atributos, respectivamente. Cada elemento em uma estratégia S éo nome de algum objeto ou uma variável designando um objeto e/ou atribu-tos.

A expressão tt(o, o') designa um conjunto de objetos {o'}, demodo que cada objeto o' do conjunto seja uma parte do objeto o expressopor alguma borda e □ tt de modo que e(o, o'). Por exemplo, declarações descript de teste podem ser consideradas estratégias que definem bordas degráfico de estratégia aDb e aDb para declarações de script de teste Win-dow(,,a,,).VBWindow(,,b") e Window("a").VBWindow("b").property("ReadOnly"), respectivamente. Assim,uma estratégia é uma abstração de declarações de script de teste (por e-xemplo, as declarações de script de teste transformado 3926), bem comouma abstração de um conjunto de caminhos em um gráfico de tipo.

Por exemplo, um gráfico de tipo de uma estrutura organizacionalde uma companhia pode incluir: um CEO como um tipo de raiz de algumobjeto de GUI que contém o objeto de GUI estoque de tipo inteiro e agrega otipo CTO. CTO é um tipo que tem objetos de GUI salário de tipo Cheque(Check) e chefe de tipo CEO. O tipo Cheque por sua vez tem os camposquantidade de tipo flutuante e emissor do tipo CEO. Uma estratégia de quan-tidade de CEOD ct1 □ a2 □ amount para a declaração de script de teste:

Window(,,CEO").Window(strexp1).Window(strexp2).property-("quantidade") para o gráfico de tipo descrito acima designa a estratégia S,onde s = CEO, d = quantidade , a1 é uma variável que designa objetos com-putados usando-se a expressão de string strexpl, e a2 é uma variável quedesigna um objeto de atributo computado através da expressão de stringstrexp2. Computando-se tt(CEO, o') o tipo {CTO} é obtido, e computando-seTr(CTO, o') os tipos {CEO.check} são obtidos.

A cada nó em uma estratégia é atribuído um número de seqüência distinto, e os nós são expressos como pares (i, tt). Dadas as funções Ai:N* N—► õ e Att : tt * tt —> õ e dois números naturais seqüenciais k e k+1, afunção A/ computa a borda de transição entre nós a que são atribuídos estesnúmeros em S, e □ se não houver uma borda de transição. Corresponden-do temente, dados dois nós ttq e ttr em algum gráfico de tipo, a função Att com-puta a borda de transição entre os nós, e □ se não houver uma borda detransição.

Quando os valores de expressões de string em declarações descripts de teste não podem ser computados até o tempo de execução, asexpressões de string podem ser inferidas. A lógica de travessia de caminho3924, o motor de satisfação de restrição 188 e a lógica de regra de classe deGUI 3928 trabalham em conjunto para a análise das declarações de scriptde teste transformado, usando gráficos de tipo pela transformação das de-clarações de script de teste transformado 3926 em uma estratégia adaptati-va com variáveis substituindo expressões de string. O motor de satisfaçãode restrição 188 e/ou a lógica de regra de classe de GUI 3928 computampossíveis valores para cada variável e geram caminhos de travessia paracada estratégia. Quando nenhum caminho é identificado entre os objetos deorigem e de destino, então, uma entrada de regra de mudança de script deelemento de GUI 3930, uma mensagem de guia de mudança 3938 e um es-pecificador de mudança 184 podem ser reportados. Quando pelo menos umcaminho é identificado, então, uma mensagem de guia de mudança 3938correspondente e um especificador de mudança 184 são gerados, uma vezque os valores de expressões que computam nomes de objetos podem nãoestar nos caminhos computados. Em uma implementação, a lógica de tra-vessia de caminho 3924, o motor de satisfação de restrição 188 e a lógicade regra de classe de GUI 3928 podem ser aplicados de forma similar paravalidação das declarações de script de teste no script de teste atual 164.

A lógica de travessia de caminho 3924 identifica um ou maiscaminhos possíveis, enquanto o motor de satisfação de restrição 188 e alógica de regra de classe de GUI 3928 validam caminhos para as expres-soes e declarações. O motor de satisfação de restrição 188 e a lógica deregra de classe de GUI 3928 computam o conjunto de bordas e para cadapar de classes c e c', pela computação de FIRST(c, c') onde um objeto detipo c existe, que pode alcançar um objeto de tipo c' por um caminho come-çando com uma borda e. Lembre que FIRST(c, c') = e □ E, de modo queexista um gráfico de objeto O de C e objetos o e o' de modo que: 1) Class(o)= c; 2) Class(o') = c'; e 3) o e* o'.

A última condição, o e* o' indica que existe (□) um caminho apartir de o para o' no gráfico de objeto, consistindo em uma borda rotulada e,seguido por qualquer seqüência de bordas no gráfico. Em uma implementação, o método FIRST é implementado usando-se dois conjuntos de lógica: alógica de travessia de caminho 3924 e a lógica de regra de classe de GUI3928. A Tabela 14 ilustra a lógica de travessia de caminho 3924 e a lógicade regra de classe de GUI 3928.

A lógica de travessia de caminho 3924 assume o conjunto R de

20 componentes de origem e de destino em S e o conjunto tt como parâmetrosde entrada. A lógica de travessia de caminho 3924 extrai uma árvore de ca-minhos válidos em um gráfico de tipo que satisfaz a uma dada estratégia.Alguns dos componentes de entrada podem não fazê-lo na árvore de cami-nho porque eles não começam quaisquer caminhos válidos.

25 Em uma implementação, a lógica de travessia de caminho 3924

invoca a lógica de regra de classe de GUI 3928, a qual por sua vez chama asi mesma de forma recursiva. A lógica de regra de classe de GUI 3928 usatrês parâmetros: um componente o que é um nó atual potencial no caminho,o número de seqüência i do nó na estratégia S, e a borda de transição õ en-

30 tre os nós em S a que são atribuídos dois números naturais seqüenciais i ei+1. A meta da lógica de regra de classe de GUI 3928 é colorir o nó atualpotencial o no caminho como vermelho ou azul, onde um objeto colorido devermelho o é considerado um nó morto no caminho no gráfico de tipo quenão leva aos nós de destino designados. Caso contrário, o nó é colorido deazul e esta cor é propagada até os nós de origem, os quais são subseqüen-temente incluídos na árvore de caminho.

A lógica de regra de classe de GUI 3928 se completa quando onúmero de seqüência i é igual a ou maior do que o número de nós na estra-tégia, |tt|, e/ou quando não houver uma borda de transição a partir do nóatual. Quando a lógica de regra de classe de GUI 3928 se completa, a lógicade regra de classe de GUI 3928 colore o nó atual de azul. No procedimentode chamada, a cor do nó é checada, e quando o nó é azul, então, o nó éanexado a seu nó pai na árvore de caminho.

Em uma implementação, o motor de satisfação de restrição 188e a lógica de regra de classe de GUI 3928 trabalham em conjunto para acomputação do conjunto de bordas e para cada par de classes c e c', ondeum objeto de tipo c é identificado, que pode alcançar um objeto de tipo c' porum caminho começando em uma borda e. A lógica é aplicada individualmen-te a cada declaração de script de teste transformado 3926 na qual objetosde GAP estranhos sejam especificados usando-se expressões de string cu-jos valores não sejam conhecidos antes de o script de teste transformado178 ser executado. O motor de satisfação de restrição 188 e a lógica de re-gra de classe de GUI 3928 trabalham em conjunto para inferirem possíveisnomes de objetos estranhos que expressões de string possam avaliar notempo de execução.

Tabela 14 - Travessia de caminho e lógica de regras de classe de GUI

<table>table see original document page 121</column></row><table><table>table see original document page 122</column></row><table>

Freqüentemente, as mesmas expressões de string são usadasem declarações diferentes no mesmo escopo de script. As mesmas expres-sões computam os mesmos valores, onde as expressões estão localizadasno mesmo escopo, desde que os valores das variáveis usadas nestas ex-pressões não sejam mudados. Usando técnicas de análise de programa, alógica de travessia de caminho 3924, o motor de satisfação de restrição 188e a lógica de regra de classe de GUI 3928 trabalham em conjunto para de-tectarem expressões no tempo de compilação, cujas variáveis não são mu-dadas no tempo de execução. A lógica de travessia de caminho 3924 identi-fica um ou mais nomes possíveis de objetos de GUI estranhos que podemser substituídos por expressões de string em declarações de script de teste.Embora o motor de satisfação de restrição 188 e a lógica de regra de classede GUI 3928 identifiquem dentre os nomes possíveis de objetos de GUI es-tranhos, aqueles objetos de GUI que não violam as regras de satisfação derestrição 3932 e/ou as regras de mudança de script de elemento de GUI194. Dada a mesma expressão usada em declarações de script de teste di-ferentes no mesmo escopo de script, e desde que os valores das variáveisusadas nestas expressões não sejam mudados por outras expressões exe-cutadas entre estas declarações, o motor de satisfação de restrição 188 e/oua lógica de regra de classe de GUI 3928 identificam um conjunto de nomesde objetos de GUI estranhos computados por estas expressões de string.Este conjunto de objetos de GUI é obtido tomando-se a interseção dos con-juntos de nomes computados pela lógica de travessia de caminho 3924.

Por exemplo, considere a quantidade CEOD a1 □ cr2 □ do gráfi-co de estratégia S1 para o gráfico de tipo discutido acima para a expressãode declaração de script de teste transformado 3926: Win-dow("CEO").Window(strexp1 ).Window(strexp2).property("amount"). O motorde satisfação de restrição 188 e/ou a lógica de regra de classe de GUI 3928computam valores para as variáveis de esquema de tipo a1= {CTO} e a2= {chefe salário}.

Suponha que exista um gráfico de estratégia diferente S2, ondeProgrammerD a2 Dbonus para y["Programmer"][strexp2].attribute("bonus")para algum outro gráfico de tipo. Note que a variável de expressão de stringstrexp2 é a mesma em ambas as declarações, e por causa disso a variávelde expressão de string strexp2 é designada pelas mesmas variáveis de es-quema de tipo em ambos os gráficos de estratégia. Suponha que pela apli-cação da lógica de travessia de caminho 3924 valores para a variável deesquema de tipo a2= {salário} sejam computados. Em uma implementação,de modo a se determinar o valor da variável a2 que satisfaz a S1 e a S2, alógica de regra de classe de GUI 3928 identifica a interseção dos conjuntosde valores de a2 computados para estas duas estratégias. O conjunto resul-tante a2= {salário} é o resultado de corte dos caminhos de navegação.

Este exemplo ilustra a idéia de cortar caminhos de navegaçãousando-se uma análise de fluxo de dados sensível a contexto, que pode serusada pelo motor de satisfação de restrição 188 e/ou pela lógica de regra declasse de GUI 3928. Pela determinação de definições e usos de uma variá-vel que designa nomes de objetos de GUI em um dado escopo, os conjuntosde valores são computados para cada declaração de script de teste trans-formado na qual uma variável é usada. Então, a interseção destes conjuntosé tomada para a determinação dos valores comuns que esta variável podeassumir no escopo considerado.

O sistema analisador de script 3900 prove uma integridade demodularização como um mecanismo para garantia da capacidade de manu-tenção de scripts de teste transformados 178. A integridade de modulariza-ção especifica que cada declaração em um script de teste transformado 178possa apenas se comunicar diretamente com objetos que pertençam a GUIspara as quais o script de teste transformado 178 é criado. Composições descripts de teste transformados 178 nas quais objetos de GUI são acessadospela chamada de funções exportadas por scripts de teste transformados 178não devem violar a integridade de modularização. O sistema analisador descript 3900 assegura a integridade de modularização de scripts de testetransformados 178 pela análise de composições de declarações de script deteste transformado 3924 para a construção das relações transitivas entre oscript de teste atual 164 e o script de teste transformado 178.

Por exemplo, uma declaração Func("y", "z"), encontrada em umasuíte de scripts de teste relacionados, navega para o campo z de um objetode GUI estranho y em alguns scripts de teste que exportam a função Func.Assim, alguns scripts de teste na suíte de scripts de teste relacionados po-dem violar a integridade de modularização ao interoperarem de forma implí-cita os scripts de teste através da função Func, embora esta comunicaçãopossa ser proibida pelas restrições de uma dada suíte de teste. Em uma im-plementação, o sistema analisador de script 3900 codifica restrições de mo-dularização quando da definição de scripts de teste usando as restrições depalavra-chave como parte de um comentário global em cada script de teste.Estas restrições definem GAPs e suas telas de GUI, bem como outros s-cripts de teste com os quais um dado script de teste pode se comunicar. Umexemplo é uma declaração que especifica uma restrição, que é 'constraintsscreenfQ") test_scripts("P, S"). Esta restrição efetivamente proíbe um dadoscript de teste de se comunicar com outros GAPs, telas de GUI e scripts deteste, exceto a tela Q e os scripts de teste P e S, de forma explícita ou implí-cita. Em uma implementação, o motor de satisfação de restrição 188 asse-gura que essas restrições não sejam violadas pela manutenção de regras desatisfação de restrição 3932 impostas em scripts de teste e GAPs, e o motorde satisfação de restrição 188 emite mensagens de guia de mudança 3938quando estas restrições forem violadas.

A complexidade de tempo da lógica de travessia de caminho3924, do motor de satisfação de restrição 188 e da lógica de regra de classede GUI 3928 é exponencial para o tamanho do gráfico de tipo para cada s-cript de teste transformado 178. Devido ao fato de a lógica de travessia decaminho 3924, o motor de satisfação de restrição 188 e a lógica de regra declasse de GUI 3928 envolverem a busca de um ou mais nós e bordas nográfico de tipo que contenham ciclos para cada nó na estratégia, a comple-xidade de tempo é 0((V+ E)max n ) onde V é o número de nós, E é o númerode bordas no gráfico de tipo, e max(|Tr|) é o número máximo de nós em es-tratégias. As operações de armazenamento de sucessores na tabela de va-riáveis leva 0(1). Em geral, o número de nós max(|TT|) em estratégias é mui-to menor do que o número de nós em gráficos de tipo. Nem todos os nós degráfico podem precisar ser explorados para cada nó em uma estratégia. Olimite teórico na complexidade computacional da lógica de travessia de ca-minho 3924, do motor de satisfação de restrição 188 e da lógica de regra declasse de GUI 3928 é exponencial. Contudo, uma avaliação experimentalmostrou que, na prática, o tempo de execução é pequeno para esquemasgrandes, porque tipicamente as expressões de caminho são curtas.

A Figura 49 mostra um analisador de transformação de script deteste com um motor de custo econômico ("arquitetura de motor de custo e-conômico") 110. Embora descrições detalhadas dos recursos da arquiteturade motor de custo econômico 110 sejam providos adicionalmente abaixo,uma breve introdução da arquitetura de motor de custo econômico 110 seráapresentada, primeiramente. Em uma implementação, a arquitetura de motorde custo econômico 110 recebe um modelo de diferença de elemento deGUI 162 que especifica diferenças de elemento de GUI entre uma versão deGAP atual 150 e uma versão de GAP subsequente 152. O modelo de dife-rença de GUI 162 pode ser representado como um esquema em XML. Omodelo de diferença de elemento de GUI 162 pode incluir modelos de árvorede GAP subsequentes correspondentes à versão de GAP atual 150 e à ver-são de GAP subsequente 152. Em uma implementação, o motor de custoeconômico 182 recebe o modelo de árvore de GAP atual a partir do modelode diferença de GUI 162. Em uma outra implementação, os modelos de ár-vore de GAP atual e subsequente, bem como o modelo de diferença de GUI162 são implementados como modelos relacionais armazenados em umbanco de dados. A arquitetura de motor de custo econômico 110 empregauma interface 190 para o recebimento de entradas e comunicação com vá-rios componentes, incluindo o depósito de metadados de elemento de GUI138. O depósito de metadados de elemento de GUI 138 pode prover umainformação detalhada referente aos elementos de GUI representados nomodelo de diferença de GUI 162, o GAP atual 150 e o GAP subsequente152.

A arquitetura de motor de custo econômico 110 inclui um anali-sador gramatical de script 166 que analisa gramaticalmente um script de tes-te atual 164 para a obtenção de uma representação intermediária do scriptde teste atual 164. A representação intermediária pode ser uma árvore desintaxe abstrata (AST) 168 ou outra representação do script de teste atual164. Em uma implementação, a arquitetura de motor de custo econômico110 emprega um motor de custo econômico 182 que analisa a AST 168 e omodelo de diferença de GUI 162. O motor de custo econômico 182 podeinvocar a lógica de consulta de depósito de objeto (OR) 172 para a buscaem um depósito de objeto 174 e no modelo de diferença de GUI 162 para alocalização, no modelo de diferença de GUI 162, dos elementos de GUI i-dentificados pela AST 168. O motor de custo econômico 182 inclui a lógicade modelo de custo econômico 4996 que usa os elementos de GUI identifi-cados pela AST 168 e o modelo de diferença de GUI 162 para a geração deespecificadores de mudança de GAP sintéticos 4984 que são usados parase buscar em um depósito de modelos econômicos 176 quanto a uma regrade custo de mudança de elemento de GUI. Em uma implementação, a lógicade modelo de custo econômico 4996 usa os especificadores de mudança deGAP 184 e os especificadores de mudança de GAP sintéticos 4984 para abusca em um depósito de modelos econômicos 176 por uma regra de custode mudança de elemento de GUI correspondente. O motor de custo econô-mico 182 aplica cada regra de custo de mudança de elemento de GUI para aobtenção dos custos de transformação de GUI correspondentes a partir doque um relatório de custo de transformação de script de teste 186 é gerado,discutido adicionalmente abaixo. O motor de custo econômico 182 tambémpode usar medidas de teste históricas a partir de um depósito de medidas deperformance 4998 e um depósito de relatórios de custo 5288 para facilitaçãoda obtenção dos custos de transformação de GUI, discutidos abaixo.

O motor de custo econômico 182 pode gerar os relatórios decustos de transformação de script de teste 186 com base em combinaçõesdiferentes de informação disponível, incluindo: 1) especificadores de mudan-ça de GAP 184 e/ou especificadores de mudança de GAP sintéticos 4984; 2)especificadores de mudança de GAP e um script de teste atual 164; 3) es-pecificadores de mudança de GAP 184, um script de teste atual 164 e umaversão de GAP atual 150 (por exemplo, um modelo de árvore de GAP atual);4) um script de teste atual 164 e um modelo de diferença de GUI 162 comentradas de diferença de elemento de GUI; e 5) especificadores de mudançade GAP 184, um script de teste atual 164 e um modelo de diferença de GUI162. Outras combinações da mesma informação ou de uma diferente tam-bém podem ser empregadas. As várias combinações de informação disponí-vel são usadas pelo motor de custo econômico 182 para análise dos especi-ficadores de mudança de GAP sintéticos 4984 recebidos e/ou gerados quesão usados pela lógica de modelo de custo econômico 4996 para localiza-ção e recuperação de custos de transformação de GUI e geração de relató-rios de custo de transformação de script de teste.

A acurácia dos custos de transformação de GUI pode depender,em parte, de quão estreita é a variância entre os custos reais e os custosindicados pelos custos de transformação de GUI. Uma grande variância cor-responde a uma acurácia mais baixa, enquanto uma variância estreita cor-responde a uma acurácia mais alta. Em outras palavras, a acurácia dos cus-tos de transformação de GUI pode corresponder à previsibilidade e/ou à con-fiança com que os custos reais refletirão os custos de transformação de GUI.Em uma implementação, a acurácia de custos de transformação de GUI va-ria devido à granularidade da informação recebida pelo motor de custo eco-nômico 182. Por exemplo, os custos de transformação de GUI gerados comoresultado do motor de custo econômico 182 recebem especificadores demudança de GAP 184, um script de teste atual 164 e um modelo de diferença de GUI 162 pode ter um nível mais alto de acurácia do que os custos detransformação de GUI gerados unicamente com base em especificadores demudança de GAP 184. O motor de custo econômico 182 pode empregar vá-rios modelos econômicos que compensem a falta de granularidade de infor-mação provida para o motor de custo econômico 182, discutido em mais de-talhes abaixo.

Em uma implementação, o motor de custo econômico 182 rece-be os especificadores de mudança de GAP 184, um script de teste atual 164e uma versão de GAP atual 150, e gera um modelo de diferença de GUI162. Em outras palavras, o motor de custo econômico 182 pode gerar o rela-tório de custo de transformação de script de teste 186 com base na AST168, na versão de GAP atual 150 e em especificadores de mudança de GAP184, discutidos adicionalmente abaixo, sem se basear em uma versão deGAP subsequente real 152. Por exemplo, o motor de custo econômico 182analisa os especificadores de mudança de GAP 184 e a versão de GAP atu-al 150 (por exemplo, um modelo de árvore de GAP atual recebido a partir domodelo de diferença de GUI 162) e gera os especificadores de mudança deGAP sintéticos 4984. Em uma outra implementação, o motor de custo eco-nômico 182 gera o relatório de custo de transformação de script de teste 186com base nos especificadores de mudança de GAP 184, sem analisar o mo-delo de diferença de GUI 162 e/ou a AST 168. O motor de custo econômico182 pode gerar os relatórios de custo de transformação de script de teste186 com mensagens de guia de mudança recuperadas a partir de um depó-sito de mensagem de guia de mudança 192. As mensagens de guia de mu-dança podem prover uma informação referente a várias mudanças corres-pondentes aos especificadores de mudança de GAP 184, a regras de custode mudança de elemento de GUI e/ou entradas de diferença de GUI.

A Figura 34 mostra uma GUI de uma versão de GAP subse-quente 152. Em uma implementação, o modelo de diferença de GUI 162 re-sulta de uma comparação entre o modelo de árvore de GAP atual, conformemostrado na Tabela 6, e um modelo de árvore de GAP subsequente, con-forme mostrado na Tabela 8. Em uma outra implementação, o motor de cus-to econômico 182 analisa o modelo de árvore de GAP atual usando especifi-cadores de mudança de GAP 184 para a determinação de mudança de GAPque podem produzir o modelo de árvore de GAP subsequente, a partir doque o motor de custo econômico 182 gera os especificadores de mudançade GAP sintéticos 4984. Por exemplo, antes de realmente construir a versãode GAP subsequente 152, um programador pode identificar várias mudan-ças propostas para uma versão de GAP atual 150 usando os especificado-res de mudança de GAP 184. O motor de custo econômico 182 analisa osespecificadores de mudança de GAP 184 e o modelo de árvore de GAP atu-al para a geração de especificadores de mudança de GAP sintéticos 4984que correspondem a um modelo de árvore de GAP subsequente proposto.Em uma implementação, o motor de custo econômico 182 inclui uma lógicade especificador de mudança de GAP que gera os especificadores de mu-dança de GAP sintéticos 4984 usando o modelo de árvore de GAP atual eos especificadores de mudança de GAP recebidos 184. Em uma implemen-tação, a arquitetura de motor de custo econômico 110 gera os especificado-res de mudança de GAP sintéticos 4984 como resultado do registro de vá-rias mudanças propostas identificadas pelo programador durante uma ses-são interativa com a versão de GAP atual 150.

A Figura 50 mostra um script de teste atual 5000 para a GUI deGAP atual. O script de teste atual 5000 inclui declarações de navegação (porexemplo, L1 e L6) que navegam para objetos de GUI, realizam ações (fun-ções) de leitura, escrita ou outras nos objetos de GUI, e os argumentos des-tas funções. Por exemplo, a linha 1 do script de teste atual 5000 navega pa-ra uma janela StateList, localiza 'Open File' identificado como um objeto deGUI filho da janela StateList, e realiza uma ação de 'Click' no objeto de GUI'Open File' nas coordenadas 86, 12. Através da série de declarações de na-vegação e de ação, o script de teste atual 5000 abre um arquivo 'univer-sity.data', conforme indicado pelas linhas 2-3. Um 'State' é selecionado apartir de StateListbox e uma SchoolListbox é ativada, com base nas linhas 4-6. O script de teste atual 5000 sucessivamente seleciona a partir da School-Listbox as escolas 'Acme University' e 'State University' localizadas no 'State'pelo uso de um 'For Next Loop', como resultado das declarações de navega-ção e de ação nas linhas 7-17, com base nas coordenadas 67, Scho-ol_Constant em WinObject "Select School" na linha 8. O script de teste atual5000 usa uma ramificação condicional nas linhas 11-15 para mudança daescala acadêmica para '3' para 'Acme University' e para '2' para 'State Uni-versity', e salva as mudanças individuais como um resultado da linha 16. Oscript de teste atual 5000 salva todas as mudanças em um novo arquivo 'u-niversity_revise.data' como resultado das declarações nas linhas 18-20.

A Figura 51 ilustra uma representação de script de teste atual5100 que o analisador gramatical de script 166 produz como uma represen-tação intermediária do script de teste atual 5000. Em uma implementação, aarquitetura de motor de custo econômico 110 implementa a representaçãode script de teste atual como uma árvore de sintaxe abstrata (AST) 168. Arepresentação de script de teste atual 5100 representa um vetor (por exem-plo, o script de teste atual 5000) cujos elementos são vetores que represen-tam declarações de navegação do script de teste atual 5000. Em outras pa-lavras, a representação de script de teste atual 5100 representa as declara-ções de navegação como vetores de declaração de script de teste que na-vegam para objetos de GUI e realizam ações naqueles objetos de GUI.

O analisador gramatical de script 166 representa os vetores dedeclaração de script de teste como uma seqüência ordenada de nós quecontêm nomes de função e os argumentos daquelas funções que navegampara objetos de GUI. Os nós de um vetor de declaração de script de testeincluem um nó de origem e um destino. Por exemplo, o analisador gramati-cal de script 166 pode representar o vetor de declaração de script de testecorrespondente à linha 1 do script de teste atual 5000 como um nó de ori-gem StateList 5102 e um nó de destino 'Open File' 5104. Os nós de um vetorde declaração de script de teste também podem incluir nós intermediáriosposicionados entre um nó de origem e um nó de destino. Por exemplo, oanalisador gramatical de script 166 pode representar o vetor de declaraçãode script de teste correspondente à linha 19 do script de teste atual 5000como um nó de origem StateList 5102, um nó intermediário de 'Save a DataRecord' 5106 e um nó de destino 'File name' 5108. O vetor de declaração descript de teste correspondente à linha 19 do script de teste atual 5000 podeser adicionalmente expresso como (5102-5106-5108-5120-5122), incluindo ométodo 'Set' 5120 e o valor 'university_revise.data' 5122.

Os vetores de declaração de script de teste podem incluir nós deentrada em laço e ramificação condicional (por exemplo, o laço 5124 e a ra-mificação 5126, respectivamente). Em uma implementação, o nó de laço5124 é seguido por uma variável de laço (por exemplo, school_constant5130) para a qual uma faixa de valores, a partir de um limite inferior para umsuperior (por exemplo, J 5132 e K 5134), são avaliados e usados em ex-pressões dentro do escopo do laço 5124 (por exemplo, coordenadas 67, s-chool_constant 5136). A ramificação 5126 pode ser seguida por uma oumais condições (por exemplo, condição-1 5138 e condição-2 5140) o motorde custo econômico 182 pode utilizar os nós de laço S124 e ramificaçãoS126, e variar os valores e condições (por exemplo, J5132, K5134 condu-ção-1 5138 e condução-2 5140) para se avaliar de forma recursiva a repre-sentação de script de teste atual 5100.

Em uma implementação, os especificadores de mudança deGAP 184 incluem um especificador de modelo (discutido em mais detalhesabaixo) que identifica a regra de custo de mudança de elemento de GUI parauso para obtenção de um custo de transformação de GUI correspondente aum laço 5124. A regra de custo de mudança de elemento de GUI para umlaço 5124 pode resultar na lógica de modelo de custo econômico 4996 ob-tendo um custo de transformação de GUI que representa um multiplicadorigual ao número de valores na faixa a partir de um limite inferior para um su-perior (por exemplo, J 5132 e K 5134) que é aplicado aos custos de trans-formação de GUI para as declarações de script de teste no escopo do laço5124 (por exemplo, as linhas 8-16 na Figura 50). Por exemplo, o custo detransformação de GUI correspondente ao laço 5124, com base no limite infe-rior para superior (por exemplo, J 5132 e K 5134), pode ser igual a 10 e oscustos de transformação de GUI correspondentes às declarações de scriptde teste no escopo do laço 5124 (por exemplo, linhas 8-16 na Figura 50)podem eqüivaler a 500, resultando em um custo de transformação de GUItotal de 5.000 para as declarações de script de teste incluindo o laço 5124(por exemplo, as linhas 7-17). Em um outro exemplo, o custo de transforma-ção de GUI obtido pela aplicação da regra de custo de elemento de GUI pa-ra um laço 5124 pode representar um valor ponderado único (por exemplo,50) que a lógica de modelo de custo econômico 4996 adiciona aos custos detransformação de GUI correspondentes às declarações de script de teste noescopo de laço 5124 de modo que o custo de transformação de GUI total de550 resulte para as declarações de script de teste incluindo o laço 5124 (porexemplo, as linhas 7-17).

A regra de custo de mudança de elemento de GUI para uma ra-mificação 5126 pode resultar na obtenção de um custo de transformação deGUI que é baseado no número de condições (por exemplo, a condição-15138 e a condição-2 5140) dentro do escopo da ramificação 5126, e os cus-tos de transformação de GUI para a ramificação 5126 e as declarações descript de teste no escopo da ramificação 5126 são adicionadas para a ob-tenção dos custos de transformação de GUI totais. Em uma outra implemen-tação, o custo de transformação de GUI correspondente à ramificação 5126é um multiplicador que é aplicado aos custos de transformação de GUI cor-respondendo às declarações de script de teste no escopo da ramificação5126. Por exemplo, duas condições (por exemplo, a condição-1 5138 e acondição-2 5140) existem no escopo da ramificação 5126, correspondendo aum custo de transformação de GUI de 2 para a ramificação 5126 e os custosde transformação de GUI das linhas dentro do escopo da ramificação 5126são 100 resultando em um custo de transformação de GUI total de 200 paraas declarações de script de teste incluindo a ramificação 5126 (por exemplo,as linhas 11-15).

O analisador gramatical de script 166 avalia argumentos de fun-ções de navegação e de ação como expressões, variáveis e constantes. Osargumentos expressam as propriedades físicas de objetos de GUI para asquais os vetores de declaração de script de teste navegam e valores usadospara a realização das ações naqueles objetos de GUI. Por exemplo, as co-ordenadas '86, 12' 5112 identificam a localização de um dispositivo de apon-tar para a realização de uma ação 'Click' 5110 no objeto de GUI 'Open File'5104, o qual é um objeto de GUI filho da janela StateList 5102. O motor decusto econômico 182 usa os nomes dos objetos de GUI (por exemplo, Sta-teList 5102 e 'Open File' 5104) navegados para pelos vetores de declaraçãode script de teste para localização das propriedades físicas correspondentesdos objetos de GUI armazenados em um depósito de objeto 174, para a i-dentificação das entradas de diferença de GUI correspondentes e para ageração de especificadores de mudança de GAP sintéticos 4984.

Em uma implementação, o motor de custo econômico 182 usa alógica de consulta de OR 172 para localização, no depósito de objeto 174,das propriedades físicas dos objetos de GUI navegados por um vetor de de-claração de script de teste, e para localização, no modelo de diferença deGUI 162, de entradas de diferença de GUI correspondentes. O motor de cus-to econômico 182 gera especificadores de mudança de GAP sintéticos 4984e invoca a lógica de modelo de custo econômico 4996 para a localizaçãodas regras de custo de mudança de elemento de GUI correspondentes nodepósito de modelos econômicos 176 usando-se especificadores de mudan-ça de GAP 184 e especificadores de mudança de GAP sintéticos 4984. Emuma IP, a lógica de consulta de OR 172 é dividida em duas subfunções: 1)uma lógica de consulta adaptada para a localização e a recuperação daspropriedades físicas dos objetos de GUI navegados pelo vetor de declaraçãode script de teste (por exemplo, 5102-5104, 5102-5106-5108, e 5102-5114);e 2) uma lógica de localizador que encontra e retorna uma entrada de dife-rença de elemento de GUI (nó) no modelo de diferença de GUI 162 que cor-responde ao objeto de GUI com as dadas propriedades físicas. A lógica demodelo de custo econômico 4996 gera especificadores de mudança de GAPsintéticos 4984 que são usados para a localização das regras de custo demudança de elemento de GUI aplicáveis, com base nos resultados de lógicade consulta e de lógica de localizador a partir da lógica de consulta de OR172. A lógica de consulta de OR 172 pode incluir uma lógica de travessia decaminho, discutida em mais detalhes abaixo, para a identificação de cami-nhos de navegação possíveis de um vetor de declaração de script de testeentre um objeto de GUI de nó de origem e um objeto de GUI de nó de desti-no para o qual um vetor de declaração de script de teste navega.

O motor de custo econômico 182 pode consultar o depósito deobjeto 174 para identificar as propriedades físicas dos objetos de GUI nave-gados pelos vetores de declaração de script de teste representados pelarepresentação de script de teste atual 5100. As propriedades físicas de umobjeto de GUI podem indicar se o objeto de GUI está oculto, é apenas deleitura, é um número e valores-padrão, conforme mostrado na Tabela 12.

Por exemplo, o motor de custo econômico 182 analisa os obje-tos de GUI 5102-5114 no vetor de declaração de script de teste. A coorde-nada '19,22' 5118 identifica a localização para um dispositivo de apontar pa-ra a realização de uma ação de 'Click' 5116 no objeto de GUI SchooListbox5114, o qual é um objeto de GUI filho da janela StateList 5102. O motor decusto econômico 182 invoca a lógica de consulta de OR 172 para localiza-ção das propriedades físicas dos objetos de GUI 5102 e 5114. A lógica deconsulta de OR 172 localiza as propriedades físicas da janela StateList 5102e do WinObject SchoolListbox 5114, conforme mostrado na Tabela 11 naslinhas 3 e 12. O motor de custo econômico 182 usa as propriedades físicasrecuperadas a partir do depósito de objeto 174 para a localização das entra-das de diferença de GUI correspondentes (por exemplo, 4504 e 4604) nomodelo de diferença de GUI 162. As entradas de diferença de GUI 4504 e4604 indicam que a janela StateList 5102 e o WinObject SchoolListbox 5114na versão de GAP atual 150 correspondem à janela School 3402 e ao Wi-nObject SchoolCombobox 3406 na versão de GAP subsequente 152, res-pectivamente. Em uma implementação, o motor de custo econômico 182emprega a lógica de consulta de OR 172 para atravessar o modelo de dife-rença de GUI 162 usando as propriedades físicas dos objetos de GUI nave-gados pelo vetor de declaração de script de teste. A função da lógica deconsulta de OR 172 retorna uma entrada de diferença de elemento de GUI(por exemplo, 3604, 4504 e 4604) a partir do modelo de diferença de GUI162 que representa o objeto de GUI navegado pelo vetor de declaração descript de teste (por exemplo, 5102-5104-5110-5112, 5102-5106-5108-5120-5122, e 5102-5114-5126-5118), e a lógica de modelo de custo econômico4996 gera especificadores de mudança de GAP sintéticos correspondentes4984. A Tabela 12 ilustra as propriedades físicas que podem ser localizadasno depósito de objeto para a entrada de objeto de GUI correspondente àSchoolListbox5114.

A Figura 52 mostra um sistema de motor de custo econômico deexemplo 5200 que pode implementar o motor de custo econômico 182. Omotor de custo econômico 182 inclui uma memória 5202 acoplada a um pro-cessador 5204 e uma interface 190. Em uma implementação, a interface 190se comunica com o depósito de metadados de elemento de GUI 138 e omodelo de diferença de GUI 162 para receber metadados de elemento deGUI 140 e entradas de diferença de elemento de GUI 3910, respectivamen-te. A interface 190 é conectada a uma rede 3906 (por exemplo, a Internet)em comunicação com vários outros sistemas e recursos. Em uma outra im-plementação, a memória 5202 inclui os metadados de elemento de GUI 140,e a lógica de especificador de mudança de GAP 5290 que produz o modelode diferença de GUI 162 e as entradas de diferença de elemento de GUI3910. A memória 5202 também inclui a lógica de analisador gramatical descript 3912 que recebe o script de teste atual 164 e produz a AST 168, pro-cessa a AST 168 como uma representação de script de teste atual 3914 eproduz os vetores de declaração de script de teste 3916 (por exemplo, 5102-5104-5110-5112, 5102-5106-5108-5120-5122, e 5102-5114-5126-5118).

A memória 5202 ainda inclui a lógica de modelo de custo eco-nômico 4996 que, em uma implementação, invoca a lógica de consulta deOR 172 para a localização, no depósito de objeto 174, de uma entrada deobjeto de GUI 3922 referida pelo vetor de declaração de script de teste 3916.Em uma outra implementação, o motor de custo econômico 182 invoca alógica de consulta de OR 172 para localizar, em várias fontes externas, umaentrada de objeto de GUI 3922 combinando com o vetor de declaração descript de teste 3916. Quando o vetor de declaração de script de teste 3916(por exemplo, 5102-5104-5110-5112, 5102-5106-5108-5120-5122, e 5102-5114-5126-5118) emprega constantes para a identificação de nomes de ob-jeto de GUI, ao invés de expressões cujos valores podem ser determinadosapenas no tempo de execução, a função de lógica de consulta de OR 172pode usar o nome de objeto de GUI e as propriedades do objeto de GUI pa-ra a localização eficiente da entrada de objeto de GUI correta 3922 e paralocalizar, no modelo de diferença de GUI 162, uma entrada de diferença deelemento de GUI 3910 combinando com a entrada de objeto de GUI 3922.

Por exemplo, o vetor de declaração de script de teste represen-tado por 5102-5104-5110-5112 identifica o objeto de GUI de janela StateList3302 e o objeto de GUI de caixa de lista SchoolListbox 3316, mostrados nadeclaração de navegação de modelo de diferença de GUI 162 mostrada nalinha 6 da Figura 50:

WindowCStateLisfJ.WinObjectCSchoolListbox^.Click 19,22.A lógica de consulta de OR 172 localiza cada entrada de objetode GUI 3922 para os objetos de GUI 3302 e 3316, usando os nomes conhe-cidos dos objetos de GUI, StateList e SchoolListbox, respectivamente. A ló-gica de consulta de OR 172 localiza as entradas de diferença de elementode GUI correspondentes 4504 e 4604 no modelo de diferença de GUI 162.Em uma implementação, a lógica de modelo de custo econômico 4996 ana-lisa as entradas de diferença de elemento de GUI correspondentes 4504 e4604 e gera um ou mais especificadores de mudança de GAP sintéticos cor-respondentes 4984. Usando os especificadores de mudança de GAP 184, alógica de modelo de custo econômico 4996 localiza, no depósito de modeloseconômicos 176 uma ou mais regras de custo de mudança de elemento deGUI 5246 e aplica as regras de custo para a obtenção dos custos de trans-formação de GUI 5248. Os custos de transformação de GUI 5248 podemincluir custos correspondentes à mudança do script de teste atual 164 e atestes da versão de GAP subsequente 152. Em outras palavras, a lógica demodelo de custo econômico 4996 determina os custos para a geração deuma declaração de script de teste transformado que corresponde aos obje-tos de GUI School 3402 e SchoolCombobox 3406 e os custos para se testara versão de GAP subsequente 152 usando a declaração de script de testetransformado:

Window("Schoor').WinObject("SchoolCombobox").CIick 294,14.Cada regra de custo de mudança de elemento de GUI 5246 po-de incluir vários atributos, incluindo: um identificador de especificador demudança 5250, identificadores de utilização de recurso de sistema 5252,uma estimativa de custo de mudança de GUI 5254 que indica o tempo esti-mado e/ou recursos necessários para se testar uma mudança de elementode GUI correspondente, identificadores dependentes de especificador demudança 5256, uma classificação de dependência 5258, uma classificaçãode qualidade 5260, uma classificação de complexidade 5262 e custos de-pendentes de mudança de elemento de GUI 5264. Cada modelo econômicoresidente no depósito de modelos econômicos 176 e/ou externo ao depósitode modelos econômicos 176 que esteja disponível para a lógica de modelode custo econômico 4996 através da interface 190 pode incluir mais, menosou diferentes atributos de regra de custo de mudança de elemento de GUI5246.

A lógica de modelo de custo econômico 4996 usa os especifica-dores de mudança de GAP 184 e especificadores de mudança de GAP sin-téticos 4984 para a localização de regras de custo de mudança de elementode GUI 5246 no depósito de modelos econômicos 176 correspondentes aosidentificadores de especificador de mudança 5250. Os identificadores deutilização de recurso de sistema 5252 indicam os recursos usados para setestar uma mudança de elemento de GUI em particular. Em uma implemen-tação, os identificadores de utilização de recurso de sistema 5252 têm valo-res de 1 a 10 que identificam a quantidade de uma capacidade de proces-samento e de infraestrutura de ambiente de teste necessária para se testaruma mudança de GAP correspondente. Por exemplo, um identificador deutilização de recurso de sistema 5252 com um valor de 3, correspondente àcapacidade de processamento de ambiente de teste, pode indicar que umterço da capacidade de processamento disponível é necessário para se tes-tar uma mudança de GAP correspondente. Um identificador de utilização derecurso de sistema 5252 com um valor de 10 correspondente à capacidadede processamento de ambiente de teste pode indicar que a maioria dos re-cursos de computação disponíveis (por exemplo, capacidade de processa-mento) será necessária para se testar uma mudança de GAP corresponden-te.

Em uma outra implementação, os identificadores de utilização derecurso de sistema 5252 proveem descrições dos recursos necessários parase testar uma mudança de GAP correspondente. Por exemplo, os identifica-dores de utilização de recurso de sistema 5252 podem itemizar as habilida-des de testadores, componentes de sistema (por exemplo, dispositivos deentrada e de saída, e largura de banda de rede) e regulagens de prioridadea serem atribuídas aos processos de sistema usados para se testar umamudança de elemento de GUI correspondente. Em uma implementação, osidentificadores de utilização de recurso de sistema 5252 provêem uma com-binação de valores discretos que indicam a capacidade de processamentode ambiente de teste e as descrições itemizadas dos vários recursos necessários para se testar a mudança de elemento de GUI correspondente.

A lógica de modelo de custo econômico 4996 pode localizar ou-tras regras de custo de mudança de elemento de GUI 5246 que dependemde uma regra de custo de mudança de elemento de GUI 5246 identificadapor um identificador de especificador de mudança 5250, usando os identifi-cadores dependentes de especificador de mudança 5256. Os identificadoresdependentes de especificador de mudança 5256 podem identificar uma oumais regras de custo de mudança de elemento de GUI 5246 que dependemda mudança de elemento de GUI correspondente ao identificador de especi-ficador de mudança 5250. Por exemplo, uma mudança na classe de um ob-jeto de GUI pai de uma caixa de lista para uma caixa de combinação (porexemplo, SchoolListbox 3316 e SchoolCombobox 3406) pode impor mudan-ças de elemento de GUI a objetos de GUI filhos do objeto de GUI pai, demodo que um identificador de especificador de mudança 5250 correspon-dente a um especificador de mudança de GAP 184 em particular e/ou umespecificador de mudança de GAP sintético 4984 identifique um ou mais i-dentificadores dependentes de especificador de mudança 5256.

Em uma implementação, a classificação de dependência 5258 éum valor de 0 a 10 que indica o nível de dependência que um GAP pode terem um elemento de GUI em particular. A classificação de dependência 5258pode corresponder à visibilidade e ao escopo de um elemento de GUI. Porexemplo, a mudança da janela Statelist 3302 no GAP atual 150 para School3402 no GAP subsequente 152, conforme mostrado na Figura 14, pode cor-responder a uma classificação de dependência 5258 de 10, enquanto a mu-dança de um valor na StateListbox 3312 para um valor na StateListbox 3404,conforme mostrado na Figura 5, pode corresponder a uma classificação dedependência 5258 de 4. A lógica de modelo de custo econômico 4996 usa aclassificação de dependência 5258 para facilitar a obtenção dos custos detransformação de GUI 5248. Em uma implementação, a lógica de modelo decusto econômico 4996 usa a classificação de dependência 5258 para deter-minar como e/ou se é para usar o fator de eficiência de mudança de GUI5286, discutido em mais detalhes abaixo.

Em uma implementação, a classificação de qualidade 5260 é umvalor de 1 a 10 que indica a contribuição para a qualidade da versão de GAPsubsequente 152 feita pela mudança de elemento de GUI. Por exemplo,uma mudança de elemento de GUI em particular que cumpre uma checa-gem de integridade em um elemento de GUI correspondente a um valor altode classificação de dependência 5258 pode corresponder a uma classifica-ção de qualidade 5260 de 10. Em um outro exemplo, uma mudança de ele-mento de GUI que é imperceptível e/ou corresponde a um valor baixo declassificação de dependência 5258 pode corresponder a uma classificaçãode qualidade 5260 de 0. Em uma implementação, a lógica de modelo decusto econômico 4996 usa um identificador de preferência de qualidade se-lecionável para a geração do relatório de custo de transformação de scriptde teste 186 com custos de transformação de GUI 5248 correspondentes aclassificações de qualidade 5260 se adequando ou excedendo ao identifica-dor de preferência de qualidade, de modo que planos de teste possam seravaliados com base em fatores de qualidade.

Em uma implementação, a classificação de complexidade 5262é um valor de 1 a 10 que indica o nível de dificuldade de se testar a mudan-ça de elemento de GUI correspondente, onde um nível de complexidade de10 é um nível alto de complexidade e um nível de 0 é um nível baixo decomplexidade. Em uma outra implementação, a classificação de complexi-dade 5262 indica a contribuição para o nível de complexidade da versão deGAP subsequente 152 feita pela mudança de elemento de GUI. Por exem-plo, uma mudança de elemento de GUI em particular que cumpra uma che-cagem de integridade em um elemento de GUI correspondente a um valoralto de classificação de dependência 5258 pode corresponder a uma classi-ficação de complexidade 5262 de 10. Em um outro exemplo, uma mudançade elemento de GUI que seja imperceptível e/ou corresponda a um valorbaixo de classificação de dependência 5258 pode corresponder a uma clas-sificação de complexidade 5262 de 0. Em uma implementação, a lógica demodelo de custo econômico 4996 usa um identificador de preferência decomplexidade selecionável por usuário para a geração do relatório de custode transformação de script de teste 186 com os custos de transformação deGUI 5248 para classificações de complexidade 5262 se adequando ou ex-cedendo ao identificador de preferência de complexidade, de modo que pla-nos de teste possam ser avaliados com base na complexidade.

Os custos dependentes de mudança de elemento de GUI 5264podem representar um custo de transformação de GUI agregado 5248 cor-respondente aos identificadores dependentes de especificador de mudança5256. Em uma implementação, a lógica de modelo de custo econômico 4996usa os custos dependentes de mudança de elemento de GUI 5264, ao invésde recuperar cada regra de custo de mudança de elemento de GUI 5246correspondente a um ou mais identificadores dependentes de especificadorde mudança 5256 para a geração do relatório de custo de transformação descript de teste 186.Em uma implementação, a lógica de modelo de custo econômico4996 usa os identificadores de preferência selecionáveis por usuário 5266para a localização das regras de custo de mudança de elemento de GUI5246 com base em valores discretos e/ou faixas de valores para um ou maisdos identificadores de utilização de recurso de sistema 5252, a estimativa decusto de mudança de GUI 5254, a classificação de dependência 5258, aclassificação de qualidade 5260, a classificação de complexidade 5262 e oscustos dependentes de mudança de elemento de GUI 5264. Os identificado-res de preferência 5266 identificam os custos de transformação de GUI 5248usados para a geração do relatório de custo de transformação de script deteste 186, com base em um ou mais dentre o identificador de especificadorde mudança 5250, um identificador de utilização de recurso de sistema5252, uma estimativa de custo de mudança de GUI 5254 que indica o tempoestimado e/ou recursos (por exemplo, dinheiro e trabalho) para se testaruma mudança de elemento de GUI correspondente, identificadores depen-dentes de especificador de mudança 5256, classificação de dependência5258, classificação de qualidade 5260, classificação de complexidade 5262e custos dependentes de mudança de elemento de GUI 5264.

O custo de transformação de GUI 5248 pode incluir um compo-nente de tempo e um componente de recurso. O componente de tempo docusto de transformação de GUI 5248 pode indicar o tempo decorrido neces-sário para a mudança de uma declaração de script de teste e/ou para se tes-tar uma mudança de elemento de GUI correspondente. O componente derecurso do custo de transformação de GUI 5248 pode indicar o dinheiro, á-reas de habilidade e/ou infraestrutura de sistema (por exemplo, unidadeshumanas e tecnológicas) necessárias para a mudança de uma declaraçãode script de teste e/ou para se testar uma mudança de elemento de GUI cor-respondente.

Lembre que o motor de custo econômico 182 pode gerar relató-rios de custo de transformação de script de teste 186 com base em múltiplascombinações de informação disponível, incluindo: 1) especificadores de mu-dança de GAP 184; 2) especificadores de mudança de GAP e um script deteste atual 164; 3) especificadores de mudança de GAP 184, um script deteste atual 164 e uma versão de GAP atual 150 (por exemplo, um modelo deárvore de GAP atual); 4) um script de teste atual 164 e um modelo de dife-rença de GUI 162 com entradas de diferença de elemento de GUI; e 5) es-pecificadores de mudança de GAP 184, um script de teste atual 164 e ummodelo de diferença de GUI 162. As várias combinações de informação dis-ponível são usadas pelo motor de custo econômico 182 para análise dosespecificadores de mudança de GAP recebidos 184 e/ou dos especificado-res de mudança de GAP sintéticos 4984 gerados que são usados pela lógicade modelo de custo econômico 4996 para localização e recuperação de cus-tos de transformação de GUI 5248 e geração de relatórios de custo de trans-formação de script de teste 186.

Em uma implementação, o motor de custo econômico 182 rece-be especificadores de mudança de GAP 184 que o motor de custo econômi-co 182 usa para localizar e recuperar os custos de transformação de GUI5248 a partir do depósito de modelos econômicos 176. Os especificadoresde mudança de GAP recebidos 184 podem ter resultado de uma análiseprévia de uma versão de GAP atual 150, um script de teste atual 164 e/ouum modelo de diferença de GUI 162. Em uma implementação, o motor decusto econômico 182 pode receber especificadores de mudança de GAP184 e um script de teste atual 164. A lógica de analisador gramatical de s-cript 3912 produz os vetores de declaração de script de teste 3916 com baseno script de teste atual 164. A lógica de modelo de custo econômico 4996analisa os vetores de declaração de script de teste 3916 para a geração deespecificadores de mudança de GAP sintéticos 4984. A lógica de modelo decusto econômico 4996 usa os especificadores de mudança de GAP recebi-dos 184 e os especificadores de mudança de GAP sintéticos gerados 4984para a localização e a recuperação de custos de transformação de GUI 5248a partir do depósito de modelos econômicos 176. Em uma implementação,os especificadores de mudança de GAP 184 recebidos e os especificadoresde mudança de GAP sintéticos gerados 4984 são indistinguíveis quanto asua origem, de modo que a lógica de modelo de custo econômico 4996 pro-cesse os especificadores de mudança de GAP 184 recebidos e os especifi-cadores de mudança de GAP sintéticos gerados 4984 uniformemente, inde-pendentemente de sua origem.

Em uma outra implementação, o motor de custo econômico 182recebe especificadores de mudança de GAP 184, um script de teste atual164 e uma versão de GAP atual 150. O motor de custo econômico 182 ana-lisa os especificadores de mudança de GAP 184 e a versão de GAP atual150 (por exemplo, um modelo de árvore de GAP atual) para a geração deespecificadores de mudança de GAP sintéticos 4984. O motor de custo eco-nômico 182 analisa os vetores de declaração de script de teste 3916 corres-pondentes ao script de teste atual 164 e ao modelo de diferença de GUI 162para a geração dos especificadores de mudança de GAP sintéticos 4984. Alógica de modelo de custo econômico 4996 usa os especificadores de mu-dança de GAP 184 recebidos e os especificadores de mudança de GAP sin-téticos gerados 4984 para a localização e a recuperação de custos de trans-formação de GUI 5248 a partir do depósito de modelos econômicos 176 egera o relatório de custo de transformação de script de teste 186.

Em uma implementação, o motor de custo econômico 182 rece-be um script de teste atual 164 e um modelo de diferença de GUI 162, semespecificadores de mudança de GAP 184. O motor de custo econômico 182analisa os vetores de declaração de script de teste 3916 correspondentes aoscript de teste atual 164 e ao modelo de diferença de GUI 162 para a gera-ção dos especificadores de mudança de GAP sintéticos 4984.

Em uma implementação, o motor de custo econômico 182 rece-be os especificadores de mudança de GAP 184, um script de teste atual164, um modelo de diferença de GUI 162 correspondente à versão de GAPatual 150 e uma versão de GAP subsequente 152. O motor de custo econô-mico 182 analisa os vetores de declaração de script de teste 3916 corres-pondentes ao script de teste atual 164 e ao modelo de diferença de GUI 162para a geração de especificadores de mudança de GAP sintéticos 4984. Omotor de custo econômico 182 usa os especificadores de mudança de GAP184 recebidos e os especificadores de mudança de GAP sintéticos gerados4984 para a localização e a recuperação das regras de custos de transfor-mação de GUI 5248 a partir do depósito de modelos econômicos 176 e paraa geração do relatório de custo de transformação de script de teste 186.

Em uma implementação, a acurácia dos custos de transforma-ção de GUI 5248 varia devido à granularidade da informação recebida pelomotor de custo econômico 182. Por exemplo, os custos de transformação deGUI 5248 gerados como resultado do motor de custo econômico 182 rece-bem os especificadores de mudança de GAP 184, um script de teste atual164 e um modelo de diferença de GUI 162 podem ter um nível de acuráciamais alto do que os custos de transformação de GUI 5248 gerados com ba-se unicamente nos especificadores de mudança de GAP 184 recebidos. Omotor de custo econômico 182 pode empregar vários modelos econômicospara conservação da acurácia dos custos de transformação de GUI 5248 ecompensação de granularidades variáveis de informação provida para o mo-tor de custo econômico 182.

Em uma implementação, os especificadores de mudança deGAP 184 e/ou os especificadores de mudança de GAP sintéticos 4984 inclu-em um especificador de modelo 5268, uma freqüência de mudança de GUI5270, coeficientes de habilidade 5272, um identificador de complexidade5274, um identificador de qualidade 5276, uma percentagem de mudança5278, um tipo de apagamento de percurso errado 5280, um tipo de mesmopercurso errado 5282 e especificadores de tipo de elemento mudado 5284.O especificador de modelo 5268 especifica um ou mais modelos econômicosa serem usados dentre os múltiplos modelos econômicos acessíveis pelalógica de modelo de custo econômico 4996. Em uma implementação, o es-pecificador de modelo 5268 especifica um ou mais modelos econômicos pa-ra a lógica de modelo de custo econômico 4996 usar correspondentes asgranularidades variáveis de informação providas para o motor de custo eco-nômico 182, de modo que a acurácia dos custos de transformação de GUI5248 seja conservada. Por exemplo, o especificador de modelo 5268 podeespecificar modelos correspondentes a uma ou mais das múltiplas combina-ções de informação disponível recebidas pelo motor de custo econômico182, incluindo: 1) modelo-1 para especificadores de mudança de GAP 184;2) modelo-2 para especificadores de mudança de GAP 184 e um script deteste atual 164; 3) modelo-3 para especificadores de mudança de GAP 184,um script de teste atual 164 e uma versão de GAP atual 150; 4) modelo-4para um script de teste atual 164 e um modelo de diferença de GUI 162 comentradas de diferença de elemento de GUI 3910; e 5) modelo-5 para especi-ficadores de mudança de GAP 184, um script de teste atual 164 e um mode-lo de diferença de GUI 162 com entradas de diferença de elemento de GUI3910.

A freqüência de mudança de GUI 5270 indica o número de ocor-rências de uma mudança de elemento de GUI em particular. Em uma im-plementação, a lógica de modelo de custo econômico 4996 inclui um fator deeficiência de mudança de GUI ajustável 5286 que indica se uma freqüênciade mudança de GUI 5270 acima de um limite em particular resulta em umcusto de transformação de GUI mais baixo 5248. Por exemplo, um fator deeficiência de mudança de GUI 5286 de 0,50 indica que o custo de transfor-mação de GUI 5248 para cada mudança acima de um limite de 100 ocorrên-cias para uma dada mudança de elemento de GUI é ajustado em 50 porcento. Em outras palavras, quando uma mudança de elemento de GUI emparticular é identificada como tendo 120 ocorrências, a lógica de modelo decusto econômico 186 aplica o fator de eficiência de mudança de GUI 5286de 0,50 ao custo de transformação de GUI 5248 para as 20 mudanças acimado limite de 100. Em um outro exemplo, um fator de eficiência de mudançade GUI 5286 de 0,00 pode indicar que nenhuma eficiência é realizada, inde-pendentemente do valor de freqüência de mudança de GUI 5270.

Em uma implementação, os coeficientes de habilidade 5272 in-cluem um ou mais coeficientes que são usados para a descrição do nível deexperiência dos testadores que se espera que testem a versão de GAP sub-sequente 152. Os coeficientes de habilidade 5272 podem incluir coeficientesindividuais para áreas específicas de experiência de teste. Por exemplo, oscoeficientes de habilidade 5272 podem corresponder à habilidade e ao nívelde experiência de testadores de acordo com fases em particular de testes,tais como unidade, integração, sistema e fase de teste final, de modo quecada fase seja representada por um ou mais coeficientes. Em um outro e-xemplo, os coeficientes de habilidade 5272 podem corresponder às habilida-des e à experiência correspondente a aspectos em particular de testes daversão de GAP subsequente 152, tais como segurança e autenticação deusuário, computações numéricas específicas para o GAP, e rede e infraes-trutura.

Em uma outra implementação, os coeficientes de habilidade5272 são calibrados com base em medidas de performance localizadas emum depósito de medidas de performance 4998 e/ou um depósito de relató-rios de custo 5288. Os especificadores de mudança de GAP 184 e/ou espe-cificadores de mudança de GAP sintéticos 4984 podem ser construídos e/ougerados a partir de medidas de performance históricas encontradas em umdepósito de medidas de performance 4998 e/ou um depósito de relatórios decusto 5288. Os coeficientes de habilidades 5272 dos especificadores de mu-dança de GAP 184 e/ou especificadores de mudança de GAP sintéticos4984 construídos podem ser ajustados por múltiplas interações para a ob-tenção de custos de transformação de GUI 5248 e relatórios de custo detransformação de script de teste 186 que estão em margens aceitáveis devariância para os custos reais refletidos no depósito de medidas de perfor-mance 4998. A acurácia dos custos de transformação de GUI 5248 obtidospela lógica de modelo de custo econômico 4996 pode ser com base emquão bem os coeficientes de habilidades 5272 são calibrados para refletiremos recursos de teste disponíveis para se testar a versão de GAP subsequen-te 152. Em uma implementação, os coeficientes de habilidades 5272 influen-ciam o identificador de complexidade 5274, discutido em mais detalhes abai-xo.

A lógica de modelo de custo econômico 4996 usa os coeficien-tes de habilidades 5272 para a obtenção de custos de transformação de GUI5248. Por exemplo, um valor de coeficiente de habilidades 5272 de 1,0 podeindicar que é esperado que testadores com pouca experiência sejam usadospara teste da versão de GAP subsequente 152 e custos de transformaçãode GUI 5248 mais altos possam resultar para refletirem a experiência baixa.Em um outro exemplo, um valor de coeficiente de habilidades 5272 de 8,0pode indicar testadores com uma experiência de teste mais alta do que amédia e custos de transformação de GUI 5248 mais baixos podem resultar,que refletem a experiência mais alta do que a média. A lógica de modelo decusto econômico 4996 pode analisar se os coeficientes de habilidades 5272e a classificação de complexidade 5262 se correlacionam, e obter de formacorrespondente custos de transformação de GUI 5248 mais altos ou maisbaixos. Por exemplo, os coeficientes de habilidades 5272 podem indicar queos testadores são capazes de testarem um GAP com um nível em particularde complexidade, conforme indicado pela classificação de complexidade5262, de modo que custos de transformação de GUI 5248 mais baixos se-jam obtidos. Em um outro exemplo, os coeficientes de habilidades 5272 po-dem indicar que os testadores carecem de uma habilidade e um nível deexperiência para testar um GAP com um nível de complexidade em particu-lar correspondente à classificação de complexidade 5262, de modo que cus-tos de transformação de GUI 5248 mais altos sejam obtidos para refletirem afalta de habilidades e experiência dos testadores e o tempo esperado e re-cursos para se testar a versão de GAP subsequente 152.

Em uma implementação, o identificador de complexidade 5274numericamente identifica o nível de complexidade de uma mudança de ele-mento de GUI (por exemplo, valores de 0 a 10) determinado pela lógica demodelo de custo econômico 4996, correspondente a um especificador demudança de GAP sintético gerado 4984. Em uma outra implementação, oidentificador de complexidade 5274 identifica o nível de complexidade de-terminado por um testador e recebido pela lógica de modelo de custo eco-nômico 4996 com o especificador de mudança de GAP 184. Distinguindo oidentificador de complexidade 5274 do especificador de mudança de GAP184 e/ou especificador de mudança de GAP sintético 4984 a partir da classi-ficação de dependência 5258 da regra de custo de mudança de elemento deGUI 5246, o identificador de complexidade 5274 representa uma análise queé externa ao depósito de modelos econômicos 176. A lógica de modelo decusto econômico 4996 pode analisar a classificação de complexidade 5262 eo identificador de complexidade 5274 para avaliação da acurácia dos custosde transformação de GUI 5248 obtidos pela aplicação da regra de custo demudança de elemento de GUI 5246.

Por exemplo, a lógica de modelo de custo econômico 4996 podedeterminar que a classificação de complexidade 5262 e o identificador decomplexidade 5274 correspondentes a uma mudança de elemento de GUIem particular estão em uma margem aceitável de variância, de modo que ocusto de transformação de GUI 5248 não seja ajustado, como resultado. Emum outro exemplo, a lógica de modelo de custo econômico 4996 pode de-terminar que a classificação de complexidade 5262 e o identificador de com-plexidade 5274 correspondentes a uma mudança de elemento de GUI emparticular estão fora de uma margem aceitável de variância e os custos detransformação de GUI 5248 são ajustados para cima por um multiplicador. Amargem de variância e o multiplicador, determinados pela análise da classi-ficação de complexidade 5262 e do identificador de complexidade 5274, po-dem ser selecionáveis por usuário e/ou ajustáveis. Em uma implementação,o identificador de complexidade 5274 é com base nos coeficientes de habili-dades 5272, de modo que a complexidade de uma mudança de elemento deGUI seja avaliada em relação às habilidades e à experiência dos testadoresdisponíveis. Os coeficientes de habilidades 5272 podem ser calibrados demodo que a classificação de complexidade 5262 e o identificador de com-plexidade 5274 gerados pela lógica de modelo de custo econômico 4996estejam em uma margem aceitável de variância.

Em uma implementação, o identificador de qualidade 5276 iden-tifica numericamente o nível de qualidade contribuído por uma mudança deelemento de GUI (por exemplo, valores de 0 a 10), determinado pela lógicade modelo de custo econômico 4996, correspondente a um especificador demudança de GAP sintético gerado 4984. Em uma outra implementação, oidentificador de qualidade 5276 identifica o nível de qualidade determinadopor um testador e recebido pela lógica de modelo de custo econômico 4996com o especificador de mudança de GAP 184. Distinguindo o identificadorde qualidade 5276 do especificador de mudança de GAP 184 e/ou de espe-cificadores de mudança de GAP sintéticos 4984 a partir da classificação dequalidade 5260 da regra de custo de mudança de elemento de GUI 5246, oidentificador de qualidade 5276 representa uma análise que é externa aodepósito de modelos econômicos 176. A lógica de modelo de custo econô-mico 4996 pode analisar a classificação de qualidade 5260 e o identificadorde qualidade 5276 para avaliação da acurácia dos custos de transformaçãode GUI 5248 obtidos pela aplicação da regra de custo de mudança de ele-mento de GUI 5246. Por exemplo, a lógica de modelo de custo econômico4996 pode determinar que a classificação de qualidade 5260 e o identifica-dor de qualidade 5276 correspondentes a uma mudança de elemento deGUI em particular estão em uma margem aceitável de variância, de modoque o custo de transformação de GUI 5248 não seja ajustado, como resulta-do. Em um outro exemplo, a lógica de modelo de custo econômico 4996 po-de determinar que a classificação de qualidade 5260 e o identificador dequalidade 5276 correspondentes a uma mudança de elemento de GUI emparticular estão fora de uma margem aceitável de variância, e os custos detransformação de GUI 5248 são ajustados para cima por um multiplicador. Amargem de variância e o multiplicador, determinados pela análise da classi-ficação de qualidade 5260 e do identificador de qualidade 5276 podem serselecionáveis por usuário e/ou ajustáveis.

Em uma implementação, o motor de custo econômico 182 rece-be um especificador de mudança de GAP 184 que inclui um valor de percen-tagem de mudança 5278, um script de teste atual 5000 e um modelo de ár-vore de GAP atual correspondente a uma versão de GAP atual 150 que omotor de custo econômico 182 usa para a geração de especificadores demudança de GAP sintéticos 4984, e localização e recuperação de custos detransformação de GUI 5248 a partir do depósito de modelos econômicos176. Por exemplo, a lógica de modelo de custo econômico 4996 analisa aversão de GAP atual 150 (por exemplo, representada por um modelo de ár-vore de GAP atual) e gera os especificadores de mudança de GAP sintéticos4984 que refletem uma percentagem de mudança da versão de GAP atual150 correspondente ao valor de percentagem de mudança 5278 (por exem-plo, variando de 1 a 100). A lógica de modelo de custo econômico 4996 ana-lisa a versão de GAP atual 150 e identifica um conjunto de mudanças deelemento de GUI propostas que correspondem ao valor de percentagem demudança 5278. A lógica de modelo de custo econômico 4996 pode identifi-car os elementos de GUI propostos pela análise dos elementos de GUI nomodelo de árvore de GAP atual da versão de GAP atual 150 em uma ordemrandômica, a ordem na qual os elementos de GUI são apresentados no mo-delo de árvore a partir do topo para o fundo ou do fundo para o topo.

Em uma implementação, as mudanças de elemento de GUI pro-postas podem ser determinadas com base no identificador de complexidade5274 e/ou no identificador de qualidade 5276 incluídos no especificador demudança de GAP recebido 184. Por exemplo, a lógica de modelo de custoeconômico 4996 recebe um especificador de mudança de GAP 184 que in-clui um valor de identificador de complexidade 5274 de 1 e um valor de iden-tificador de qualidade 5276 de 2, e para cada um dos elementos de GUI pro-postos a serem mudados determina mudanças propostas correspondentesao valor de identificador de complexidade 5274 de 1 e ao valor de identifica-dor de qualidade 5276 de 2. A lógica de modelo de custo econômico 4996pode localizar, no depósito de medidas de performance 4998 e/ou no depó-sito de relatórios de custo 5288, mudanças de elemento de GUI propostascorrespondentes aos valores de identificador de complexidade 5274 e aosvalores de identificador de qualidade 5276. Em uma implementação, a lógicade modelo de custo econômico 4996 gera especificadores de mudança deGAP sintéticos 4984, como resultado da análise das mudanças de elementode GUI propostas. Em uma outra implementação, a lógica de modelo de cus-to econômico 4996 identifica as mudanças de elemento de GUI propostascorrespondentes ao identificador de complexidade 5274, ao identificador dequalidade 5276 e aos coeficientes de habilidades 5272.

A lógica de modelo de custo econômico 4996 analisa o script deteste atual 5000 e o modelo de diferença de GUI 162 para a geração de es-pecificadores de mudança de GAP sintéticos 4984 com base em mudançasde elemento de GUI validadas (por exemplo, entradas de diferença de ele-mento de GUI). Por exemplo, a lógica de modelo de custo econômico 4996determina vetores de declaração de script de teste 3916 que precisam demodificação porque os objetos de GUI que são referenciados no script deteste atual 5000 e existem na versão de GAP atual 150 não existem na ver-são de GAP subsequente 152, e a lógica de modelo de custo econômico4996 gera especificadores de mudança de GAP sintéticos 4984 que refletemas mudanças necessárias para o script de teste atual 5000. A lógica de mo-delo de custo econômico 4996 identifica mudanças nos vetor de declaraçãode script de teste 3916 que regulam os valores de objetos de GUI que sãocompatíveis com a classe daqueles objetos de GUI, de modo que restriçõesimpostas nos objetos de GUI como resultado de uma mudança não sejamvioladas. Em uma implementação, a lógica de modelo de custo econômico5 4996 verifica que operações incorretas não são especificadas pelos especifi-cadores de mudança de GAP 184 e/ou pelos especificadores de mudançade GAP sintéticos 4984 usados para a obtenção de custos de transformação1 de GUI 5248.

A lógica de modelo de custo econômico 4996 pode inferir umainformação de classe de GUI referente a um objeto de GUI que esteja pre-sente em um caminho de navegação de vetores de declaração de script deteste 3916, e cuja presença não é explicitamente definida. Por exemplo,quando o vetor de declaração de script de teste 3916 emprega expressõesque identificam objetos de GUI cujos valores podem ser determinados ape-nas no tempo de execução, a lógica de consulta de OR 172 pode usar a ló-gica de travessia de caminho 3924 para identificar possíveis entradas deobjeto de GUI correspondentes 3922 e entradas de diferença de elementode GUI 3910 no depósito de objeto 174 e no modelo de diferença de GUI162, respectivamente. A lógica de modelo de custo econômico 4996 entãoidentifica as entradas de objeto de GUI válidas 3922 que podem substituir asexpressões e as entradas de diferença de elemento de GUI 3910 que satis-fazem a vetores de declaração de script de teste válidos 3916, e a lógica demodelo de custo econômico 4996 gera especificadores de mudança de GAPsintéticos 4984 correspondentes.

Por exemplo, considere o vetor de declaração de script de teste3916: VBWindow("s")VBWindow(e1).VBWindow(e2).VBWindow("d"), onde oobjeto de GUI de nó de origem é denominado "s", o objeto de GUI de nó dedestino é denominado "d", mas as expressões e1 e e2 computam valores denós intermediários no caminho de navegação no tempo de execução. A lógi-ca de travessia 3924 determina nós intermediários (objetos de GUI) que po-dem ser incluídos nos caminhos de navegação identificados pelo nó de ori-gem "s" e pelo nó de destino "d". A lógica de travessia de caminho 3924analisa o modelo de diferença de GUI 162 para identificar possíveis substitu-ições de constante por e1 e e2, por exemplo, "a" e T, de modo que o vetorde declaração de script de teste 3916 formado pelos objetos de GUI substi-tutos na expressão de caminho de navegação "s.a.f.d" possa ser validadopela lógica de modelo de custo econômico 4996. Pela identificação dos pos-síveis caminhos de navegação levando ao nó de destino d começando como nó de origem 's', a lógica de modelo de custo econômico 4996 pode con-cluir se é para gerar um especificador de mudança de GAP sintético 4984com base nos objetos de GUI substitutos. No caso de a lógica de travessia3924 não identificar pelo menos um caminho de navegação, então, a decla-ração de script de teste transformado 3928 será inválida. Alternativamente,no caso de a lógica de travessia 3924 identificar caminhos de navegaçãolevando a partir de 's' para 'd' pela travessia de dois objetos (por exemplo, e1e e2), então, a declaração de script de teste transformado 3928 poderá serválida, desde que as expressões e1 e e2 avaliem para os nomes dos nósnos caminhos de navegação descobertos. A lógica de travessia 3924 infereos nomes possíveis computados pelas expressões e1 e e2 no tempo decompilação. Em outras palavras, há uma correlação direta entre a complexi-dade de scripts de teste e o custo econômico para a transformação de s-cripts de teste e o uso daqueles scripts de teste para se testarem versões deGAP subsequente 152. A complexidade é uma função do número de objetosde GUI referenciados e das operações nos objetos de GUI, bem como daquantidade de lógica necessária para processamento dos dados que sãoextraídos e colocados naqueles objetos de GUI.

Com referência à Figura 47, a lógica de modelo de custo eco-nômico 4996 pode inferir uma informação de classe de GUI referente a obje-tos de GUI que estejam presentes no caminho de navegação de vetores dedeclaração de script de teste 3916. A lógica de modelo de custo econômico4996 identifica os especificadores de mudança de GAP 184 e/ou os especifi-cadores de mudança de GAP sintéticos 4984 que resolvem vetores de de-claração de script de teste 3916 que tentam acessar objetos de GUI que nãoexistem em uma versão de GAP subsequente 152 e/ou tentam regular umvalor de um objeto de GUI que não é compatível com o tipo do objeto deGUI. O tipo de lógica de modelo de custo econômico 4996 checa vetores dedeclaração de script de teste 3916 em relação ao modelo de diferença deGUI 162, antes da geração de especificadores de mudança de GAP 184 cor-respondentes.

A lógica de modelo de custo econômico 4996 usa relações deherança e subtipificação entre as classes de objetos de GUI para validaçãode especificadores de mudança de GAP recebidos 184 e geração de especi-ficadores de mudança de GAP sintéticos válidos 4984. O conceito de classeinclui contenções hierárquicas (por exemplo, escopos de GUI e hierarquiasde sistema). O depósito de objeto 174 e o modelo de diferença de GUI 162incluem uma informação de classe de GUI (por exemplo, anotação das clas-ses de objetos de GUI) para cada entrada de objeto de GUI 3922 e entradade diferença de elemento de GUI 3910. Por exemplo, com referência à linha1 da Tabela 12, a SchoolListBox é uma classe de WinObject com proprieda-des listadas nas linhas 3-39. Em um outro exemplo, com referência às Figu-ras 36, 45 e 46, na linha 1 de cada entrada de diferença de GUI (por exem-plo, 3604, 4504 e 4604) o GUIEIement Type é indicado. A classe de cadaobjeto de GUI é indicada conforme mostrado nas Figuras 36, 45 e 46, naslinhas 7, 8 e 8, respectivamente. A classe de um objeto de GUI indica que oobjeto de GUI inclui atributos, propriedades e/ou tratos em particular em co-mum com outros objetos de GUI da mesma classe que podem ser estendi-dos e/ou herdados pelos objetos de GUI filhos. Por exemplo, a Figura 36 nalinha 7 indica que o objeto de GUI Stateüstbox é de uma classe Windows-Forms10.ListBox.app4 que inclui valores, conforme indicado na linha 11 daFigura 36.

Com referência de novo à Figura 52, em uma implementação, alógica de modelo de custo econômico 4996 determina se o objeto de GUImudou e regula o status de mudança de elemento de GUI 3934. Por exem-plo, o status de mudança de elemento de GUI 3934 pode usar um indicadornumérico de O, 1 e 2, respectivamente, para indicar nenhuma mudança euma mudança com e sem uma violação de restrição em particular. A lógicade modelo de custo econômico 4996 pode usar o status de mudança de e-lemento de GUI 3934 para facilitar a identificação dos especificadores demudança de GAP 184 e/ou especificadores de mudança de GAP sintéticos4984 apropriados.

Em uma outra implementação, o status de mudança de elemen-to de GUI 3934 é uma mensagem que prove uma descrição detalhada deuma mudança. O status de mudança de elemento de GUI 3934 também po-de indicar com um indicador numérico (por exemplo, -1) que o objeto de GUÍfoi apagado da versão de GAP subsequente 152. Quando um objeto de GUIfoi apagado da versão de GAP subsequente 152, a lógica de modelo de cus-to econômico 4996 gera um ou mais especificadores de mudança de GAPsintéticos 4984 que especificam mudanças correspondentes no script deteste atual 5000 e na versão de GAP atual 150. Em uma implementação, alógica de modelo de custo econômico 4996 gera especificadores de mudan-ça de GAP sintéticos 4984 que correspondem a abordagens diferentes, masequivalentes em termos programáticos, para mudança do script de teste a-tual 5000 e da versão de GAP atual 150, de modo que um programador pos-sa avaliar os custos de transformação de GUI 5248 e um relatório de custode transformação de script de teste.

A Figura 40 mostra um fluxograma 4000 para a recuperação daspropriedades de uma entrada de objeto de GUI 3922 a partir de um depósitode objeto (OR) 174. A lógica de analisador gramatical de script 3912 analisagramaticalmente o vetor de declaração de script de teste 3916 em uma se-quência ordenada de nós que representam funções e argumentos que nave-gam para objetos de GUI (4002). A lógica de analisador gramatical de script3912 avalia o primeiro nó da seqüência ordenada de nós (4004) e identificao primeiro nó como o nó de origem e atribui um identificador de seqüênciaindicando a posição do nó de origem na seqüência ordenada (4006). A lógi-ca de analisador gramatical de script 3912 avalia o próximo nó da seqüênciaordenada de nós para determinar se o próximo nó é o último nó (4008), eidentifica o próximo nó como um nó intermediário, quando o próximo nó nãofor o último nó (4010). Ao nó intermediário é atribuído um identificador deseqüência indicando a posição do nó intermediário na seqüência ordenada.A lógica de analisador gramatical de script 3912 pode identificar todos osnós intermediários entre o nó de origem e o nó de destino.

A lógica de analisador gramatical de script 3912 identifica o últi-mo nó na seqüência ordenada como o nó de destino e atribui um identifica-dor de seqüência ao nó de destino que indica a posição do nó de destino naseqüência ordenada (4012). A OR Lookup 172 realiza uma consulta de de-pósito de objeto para cada objeto de GUI correspondente à seqüência orde-nada de nós para os quais o vetor de declaração de script de teste navega,de modo que cada entrada de objeto de GUI 3922 seja identificada (4014).

Em uma implementação, a seqüência ordenada de nós é usada pela lógicade travessia de caminho 3924 e pela lógica de modelo de custo econômico4996 para validação das declarações do script de teste atual 5000 e/ou paravalidação dos especificadores de mudança de GAP recebidos 184 e dos es-pecificadores de mudança de GAP sintéticos gerados 4984. Em uma imple-mentação, o motor de custo econômico 182 usa a seqüência ordenada denós para inferir a classe de GUI e uma informação de herança (subclasse)para objetos de GUI. Quando pelo menos um dentre os nós de origem, dedestino e/ou intermediário é de expressões que podem ser identificadas a-penas no tempo de execução, a lógica de travessia de caminho pode identi-ficar possíveis entradas de objeto de GUI 3922, e a lógica de modelo de cus-to econômico 4996 e determina as entradas de objeto de GUI 3922 que sa-tisfazem ao vetor de declaração de script de teste 3916. A OR Lookup 172recupera as propriedades das entradas de objeto de GUI 3922 para as quaiso vetor de declaração de script de teste navega (4016).

A Figura 53 mostra um fluxograma 5300 para a identificação deuma entrada de diferença de elemento de GUI 3910 correspondente a umaentrada de objeto de GUI 3922. A lógica de consulta de OR 172 recebe aspropriedades dos objetos de GUI correspondentes a nós de origem, de des-tino e todos os intermediários do vetor de declaração de script de teste 3916.Em uma implementação, a lógica de consulta de OR 172 emprega a lógicade travessia de caminho 3924 para a identificação de possíveis entradas dediferença de elemento de GUI 3910 correspondentes aos caminhos de na-vegação identificados por um nó de origem e um nó de destino para o qualum vetor de declaração de script de teste navega (5302). Quando pelo me-nos uma das entradas de diferença de elemento de GUI 3910 é uma expres-são que pode ser identificada apenas no tempo de execução, a lógica detravessia de caminho 3924 identifica uma ou mais possíveis entradas de di-ferença de elemento de GUI 3910 que formam um caminho de navegaçãoentre o nó de origem e o nó de destino (5304). A lógica de travessia de ca-minho 3924 determina se as entradas de diferença de elemento de GUI3910 formam um caminho de navegação válido entre as entradas de dife-rença de elemento de GUI 3910 de nós de origem e de destino correspon-dentes (5306). A lógica de modelo de custo econômico de GUI 4996 deter-mina se as entradas de diferença de elemento de GUI 3910 que formam ocaminho de navegação são válidas (5308).

A lógica de modelo de custo econômico 4996 identifica as entra-das de diferença de elemento de GUI 3910 que correspondem a cada umadas entradas de objeto de GUI 3922 formando um caminho de navegaçãoválido (5310). A lógica de modelo de custo econômico 4996 determina osespecificadores de mudança de GAP sintéticos 4984 para a geração e/ou avalidação dos especificadores de mudança de GAP 184 com base no tipo demudança de elemento de GUI (por exemplo, 5280, 5282, 5284 e/ou o statusde mudança de elemento de GUI 3934), com base na análise da entrada deobjeto de GUI 3922 e da entrada de diferença de elemento de GUI 3910(5312). A lógica de modelo de custo econômico 4996 gera especificadoresde mudança de GAP sintéticos válidos 4984 correspondentes ao tipo de mu-dança de elemento de GUI identificado. Quando a lógica de travessia decaminho 3924 identifica um caminho de navegação que atravessa um núme-ro inválido de entradas de diferença de elemento de GUI 3910 entre as en-tradas de diferença de elemento de GUI 3910 de nó de origem e de destinocorrespondentes, a lógica de travessia de caminho 3924 indica que o cami-nho de navegação é inválido (5314).

A Figura 54 mostra um script de teste transformado 5400 para aversão de GAP subsequente 152. A lógica de modelo de custo econômico4996 pode gerar especificadores de mudança de GAP sintéticos 4984 queespecificam as mudanças necessárias para a obtenção do script de testetransformado 5400. Por exemplo, a lógica de modelo de custo econômico4996 gera especificadores de mudança de GAP sintéticos 4984 para as li-nhas 1-3 do script de teste atual 5000, mostrado na Figura 50, correspon-dente às linhas de script de teste transformado 1, 5-7, mostradas na Figura54. Em uma implementação, o modelo de diferença de GUI 162 e os metadados de elemento de GUI provêem a classe de GUI, a tipificação de GUI ea informação de mapeamento necessárias para que a lógica de modelo decusto econômico 4996 infira as linhas 2-4 do script de teste transformado5400, dado que o "university.data" na linha 6 representa um destino em umatravessia de caminho a partir da qual os especificadores de mudança deGAP válidos 184 e/ou os especificadores de mudança de GAP sintéticos4984 podem ser determinados. Em um outro exemplo, o modelo de diferença de GUI 162 e/ou os metadados de elemento de GUI incluem uma informação de classe de GUI e de mapeamento que o motor de custo econômico182 usa para gerar um ou mais especificadores de mudança de GAP sintéticos 4984 que especificam como transformar a linha 16 do script de teste a-tual 5000, conforme mostrado na Figura 50, que se refere ao WinObject"Save File" nas linhas 24-25 que se referem a um objeto de GUI filho "SaveFile" do WinObject "menuStripl".

A Figura 55 mostra um fluxograma 5500 para a geração de umespecificador de mudança de GAP sintético 4984. Em uma implementação,a lógica de modelo de custo econômico 4996 valida os especificadores demudança de GAP 184 e/ou gera especificadores de mudança de GAP sinté-ticos 4984 que especificam o tipo de mudanças de objeto de GUI entre libe-rações de edições sucessivas de GAPs, incluindo: (A) um novo objeto deGUI adicionado a uma versão de GAP subsequente 152; (B) um objeto deGUI é apagado de uma versão de GAP subsequente 152; (C) os valores deum ou mais atributos de um objeto de GUI são modificados; (D) os valoresde um objeto de GUI são modificados entre versões de GAP sucessivas; e

(E) o tipo de um objeto de GUI é diferente. O motor de custo econômico 182analisa os objetos de GUI referidos no script de teste atual 5000, a versão deGAP atual 150 e os especificadores de mudança de GAP 184 (5502). O motor de custo econômico 182 recupera as propriedades de cada objeto de GUI(por exemplo, as entradas de objeto de GUI 3922) a partir do depósito deobjeto 174, e localiza uma entrada de diferença de elemento de GUI 3910correspondente no modelo de diferença de GUI 162 (5504). Em uma implementação, o motor de custo econômico 182 recebe uma representação demodelo de árvore de GAP atual de uma versão de GAP atual 150 a partir domodelo de diferença de GUI 162 e especificadores de mudança de GAP184, e gera especificadores de mudança de GAP sintéticos 4984, usando alógica de especificador de mudança de GAP 5290. A lógica de modelo decusto econômico 4996 analisa as mudanças de objeto de GUI (5506).

As mudanças de objeto de GUI de tipos A (5508) e B (5510) ocorrem quando objetos de GUI são adicionados e removidos de forma correspondente da versão de GAP atual 150 e da versão de GAP subsequente152. Por exemplo, a adição do WinObject menustripl 308 para a versão deGAP subsequente 152 é uma mudança de tipo A, enquanto a remoção doWinObject "Select School" 3304 é uma mudança de objeto de GUI de tipo B.Com referência à Figura 35, note que o "Select School" foi removido em3512.

Um exemplo de uma mudança de tipo C (5512) é a mudança donome de janela de StateList 3302 para School 3402. A adição ou remoçãode valores de objetos de GUI, tais como caixas de lista e de combinação, éum exemplo de modificações da mudança de tipo D (5512). Por exemplo, acaixa de lista StateListbox 3312 na versão de GAP atual 150 é identificadana versão de GAP subsequente 152 como StateListbox 3404, e com referência à entrada de diferença de GUI 3604 os valores para SeqNumber = "8"são "District of Columbia" e "Florida" para versões de GAP sucessivas, respectivamente. A mudança do "type" de um objeto de GUI pode incluir asubstituição de uma classe da janela que é usada para representação doobjeto e/ou a mudança do conceito de nível alto que descreve os valoresque o objeto de GUI assume. Por exemplo, a mudança do tipo do rótulo estático para uma caixa de combinação apenas de leitura é uma modificaçãodo tipo E (5512). Um outro exemplo de uma mudança de tipo E inclui a mudança da caixa de lista "SchooListbox" 3316 para uma caixa de combinação"SchoolCombobox" 3406.

A lógica de modelo de custo econômico 4996 recebe os especificadores de mudança de GAP 184 e gera especificadores de mudança deGAP sintéticos 4984 que incluem os especificadores de tipo de apagamentode percurso errado 5280, de tipo de mesmo percurso errado 5282 e de tipode elemento mudado 5284. O tipo de apagamento de percurso errado 5280 especifica que um objeto de GUI na versão de GAP atual 150 pode ter sidoapagado na versão de GAP subsequente 152 (por exemplo, vide "Select School" 3318 e 3512 conforme mostrado na Figura 35), embora o script deteste atual 5000 se refira ao objeto de GUI (5514). O tipo de mesmo percurso errado 5282 especifica que uma mudança de GAP pode resultar em umaleitura e/ou uma escrita para o objeto de GUI errado. Por exemplo, o métodopode ser invocado no objeto de GUI errado com base em uma mudança deGAP em particular. O tipo de mesmo percurso errado 5282 especifica queum objeto de GUI em uma versão de GAP atual 150 foi modificado e/ou umoutro objeto de GUI foi adicionado à versão de GAP subsequente 152, quepode resultar em o objeto de GUI ser navegado para por uma declaração descript de teste (5516).

Por exemplo, considere a declaração nas linhas 2 e 6 do scriptde teste atual 5000 e do script de teste transformado 5400, respectivamente:

Window(,,StateList,,).Dialog(,,Open,,).WinListView("SysListView32").Select

"university.data".

A declaração seleciona "university.data" a partir de uma WinListView "SysListView32". Contudo, as linhas 2-4 do script de teste transformado 5400 podem navegar para e invocar o método Select no objeto de GUIerrado "university.data", porque os objetos de GUI referenciados nas linhas204 do script de teste transformado 5400 são objetos de GUI novos que nãosão referenciados no script de teste atual 5000. Assim, quando as propriedades de objetos de GUI existentes são modificadas e/ou outros objetos deGUI são adicionados em uma versão de GAP subsequente 152, o resultadode interferência destas operações é que as declarações de script de testetransformado que resultam da aplicação de especificadores de mudança deGAP 184 e/ou especificadores de mudança de GAP sintéticos 4984 em vetores de declaração de script de teste atuais 3916 podem acessar e ler valoresde objetos que são diferentes daqueles originalmente pretendidos.

O elemento mudado 5284 especifica que o tipo, as propriedadese/ou os valores-padrão de um objeto de GUI referenciados por um vetor dedeclaração de script de teste 3916 mudaram na versão de GAP subsequente152 (5518). Por exemplo, a entrada de diferença de GUI 3604 indica que hávalores diferentes para SeqNumber = "8" são "District of Columbia" e "Florida" para versões de GAP sucessivas, e a lógica de modelo de custo econô-mico 4996 pode gerar um especificador de mudança de GAP sintético 4984que inclui um elemento de mudança 5284 de forma correspondente. O elemento de mudança 5284 também pode especificar que novas restrições fo-ram impostas em um objeto de GUI que entram em conflito com os vetoresde declaração de script de teste 3916, por exemplo, tentando escrever da-dos em uma caixa de texto que podia ser escrita previamente que mudoupara uma caixa de texto apenas de leitura.

Com referência à entrada de diferença de elemento de GUI mostrada na Tabela 13, o WinObject "AcadScale" referido no script de teste atual5000 na linha 8 é um objeto editável que foi transformado no WinObject "A-cademics (1-5)" na versão de GAP subsequente 152 em que o objeto é apenas de leitura. A lógica de modelo de custo econômico 4996 valida os especificadores de mudança de GAP 184 e/ou gera o especificador de mudançade GAP sintético 4984 com o tipo de mudança de GAP especificado (5520),e o status de mudança de elemento de GUI 3934 é atualizado (5522). Emuma implementação, a lógica de modelo de custo econômico 4996 não geraespecificadores de mudança de GAP sintéticos 4984 para objetos de GUIque não tenham mudado entre versões de GAP sucessivas (5524).

Conhecer o tipo de modificação para um objeto de GUI facilita alógica de modelo de custo econômico 4996 na determinação dos especificadores de mudança de GAP sintéticos apropriados 4984 para a geração e/ouvalidação de especificadores de mudança de GAP recebidos 184. Por exemplo, a lógica de modelo de custo econômico 4996 pode validar os especificadores de mudança de GAP 184 e/ou gerar um ou mais especificadoresde mudança de GAP sintéticos 4984 que especificam mudanças em vetoresde declaração de script de teste 3916 que tentam regular valores em um objeto de caixa de texto que mudou para uma caixa de combinação de apenasleitura. Os especificadores de mudança de GAP 184 e/ou os especificadoresde mudança de GAP sintéticos 4984 podem especificar que o vetor de declaração de script de teste 3916 foi modificado (transformado) para a seleção de valores na caixa de combinação usando-se interfaces apropriadas,ao invés de se tentar regular valores na caixa de texto.

A lógica de modelo de custo econômico 4996 determina se osobjetos de GUI foram removidos de uma versão de GAP atual 150 e localizaos vetores de declaração de script de teste 3916 que referenciam estes objetos removidos no script de teste atual 5000. O motor de custo econômico182 se refere a estas declarações como declarações de primeira referência(FRS). As variáveis usadas nestas declarações são obtidas e as declaraçõesque usam as variáveis cujos valores são definidos nas FRSs são referidascomo declarações de referência secundária (SRS). A lógica de modelo decusto econômico 4996 determina se os objetos de GUI podem ter sido apa-gados na versão de GAP subsequente 152, e valida os especificadores demudança de GAP recebidos 184 e gera um ou mais especificadores de mudança de GAP sintéticos 4984 correspondentes com um apagamento decaminho errado 5284. Quando uma declaração do script de teste atual 5000se refere a uma variável cujo valor aponta para um objeto de GUI removido,a declaração do script de teste transformado 3926 é considerada um SRS.Em uma implementação, o motor de custo econômico 182 gera um ou maisespecificadores de mudança de GAP sintéticos 4984 e/ou valida os especificadores de mudança de GAP recebidos 184 correspondentes as SRSs identificadas.

Quando os valores de um ou mais atributos de um objeto de GUIsão modificados, uma modificação de tipo C é realizada. As FRSs e SRSssão identificadas para o objeto de GUI com os atributos modificados e especificadores de mudança de GAP sintéticos 4984 correspondentes são gerados e/ou os especificadores de mudança de GAP recebidos 184 são validados. Quando os valores de objetos de GUI são adicionados ou removidos,as modificações do tipo D ocorrem. Após a localização de FRSs que referenciam objetos de GUI cujos valores foram mudados, SRSs são encontradas e o motor econômico 182 determina o impacto devido as SRSs. Quandoo tipo de um objeto de GUI é modificado, então, uma modificação do tipo Eocorre, que envolve a localização de FRSs, a checagem de novos tipos deobjeto de GUI, invocando regras de subsunção de tipo correspondente. Alógica de modelo de custo econômico 4996 pode analisar os objetos de GUImodificados para determinar se é para gerar especificadores de mudança deGAP sintéticos 4984 com o tipo de elemento mudado 5284, onde objetos deGUI cujos tipos, propriedades ou valores-padrão são mudados em uma versão de GAP subsequente 152, e/ou tentando uma operação em um objetode GUI que não leva em consideração novas restrições impostas nos elementos do objeto de GUI.

A lógica de modelo de custo econômico 4996 analisa cada objeto de GUI referido no script de teste atual 164 e/ou no script de teste atual5000, a versão de GAP atual 150, os especificadores de mudança de GAPrecebidos 184, os especificadores de mudança de GAP sintéticos gerados4984 e/ou o status de mudança de elemento de GUI 3934. A lógica de modelo de custo econômico 4996 localiza, no depósito de modelos econômicos176, o modelo econômico especificado pelo especificador de modelo 5268, erecupera uma regra de custo de mudança de elemento de GUI 5246 com umidentificador de especificador de mudança 5250 correspondente ao especificador de mudança de GAP 184 e/ou ao especificador de mudança de GAPsintético 4984. Em uma implementação, a lógica de modelo de custo econômico 4996 combina um ou mais atributos de um objeto de GUI (por exemplo, tipo e/ou classe) com o status de mudança de elemento de GUI 3934, oespecificador de modelo 5268, o tipo de apagamento de percurso errado5280, o tipo de mesmo percurso errado 5282 e/ou o tipo de elemento mudado 5284 para a formação de um identificador único usado para a localizaçãode um identificador de especificador de mudança 5250 correspondente nomodelo econômico especificado pelo especificador de modelo 5268.

A lógica de modelo de custo econômico 4996 analisa os componentes de regra de custo de mudança de elemento de GUI 5246, o especificador de mudança de GAP 184 e/ou os componentes de especificador demudança de GAP sintético 4984, os identificadores de preferência 5266 e ofator de eficiência de mudança de GUI 5286 para se determinar se é paraajustar a estimativa de custo de mudança de GUI 5254. Por exemplo, a lógica de modelo de custo econômico 4996 ajusta a estimativa de custo de mudança de GUI 5254 com base em se os coeficientes de habilidades 5272,identificador de complexidade 5274, identificador de qualidade 5276, identificadores de utilização de recurso de sistema 5252, classificação de qualidade5260 e/ou classificação de complexidade 5262 estão em uma variância aceitável, conforme especificado pelos identificadores de preferência 5266. Alógica de modelo de custo econômico 4996 obtém o custo de transformaçãode GUI 5248 com base na estimativa de custo de mudança de GUI 5254.Em outras palavras, a estimativa de custo de mudança de GUI 5254 é ajustada para a obtenção do custo de transformação de GUI para o especificador de mudança de GAP 184 e/ou o especificador de mudança de GAP sintético 4984. A lógica de modelo de custo econômico 4996 processa cadaespecificador de mudança de GAP recebido 184 e/ou especificador de mudança de GAP sintético gerado 4984 para a obtenção dos custos de transformação de GUI 5248 correspondentes e gera o relatório de custo de trans-formação de script de teste 186 com os custos de transformação de GUI 5248.

A Figura 56 mostra um fluxograma para extração de um relatóriode custo de transformação de script de teste 186 com base em um modelode diferença de GUI 162. O motor de custo econômico 182 recebe o modelode diferença de GUI 162 e os metadados de elemento de GUI 140 (5604). Omotor de custo econômico 182 recebe uma representação de script de testeatual 3914 que inclui um vetor de declaração de script de teste 3916 (5606).A lógica de analisador gramatical de script 3912 analisa gramaticalmente ovetor de declaração de script de teste 3916 em nós de vetor para determinaros objetos de GUI para os quais o vetor de declaração de script de teste3916 navega (5608). O motor de custo econômico 182 invoca a lógica deconsulta de OR 172 para cada objeto de GUI identificado pelo vetor de declaração de script de teste 3916 para a recuperação das propriedades dosobjetos de GUI a partir do depósito de objeto 174 (5610). A lógica de travessia de caminho 3924 analisa o caminho de navegação das entradas de diferença de elemento de GUI 3910 que correspondem aos objetos de GUI iden-tificados pelo vetor de declaração de script de teste 3916 (5612). A lógica demodelo de custo econômico 4996 valida um especificador de mudança deGAP 184 e/ou determina o tipo de especificador de mudança de GAP sintético 4984 a gerar (5614). A lógica de modelo de custo econômico 4996 geraum especificador de mudança de GAP sintético 4984 correspondente ao tipode mudança de elemento de GUI identificado pela análise do script de testeatual 164, da versão de GAP atual 150 (por exemplo, o modelo de árvore deGAP atual) e o modelo de diferença de GUI 162 (5616). A lógica de modelode custo econômico 4996 localiza no modelo econômico especificado peloespecificador de modelo 5268 a regra de custo de mudança de elemento deGUI 5246 correspondente ao especificador de mudança de GAP 184 e/ou aoespecificador de mudança de GAP sintético 4984 e aplica a regra de custode mudança de elemento de GUI 5246 para a obtenção do custo de transformação de GUI 5248 (5618). A lógica de modelo de custo econômico 4996gera o relatório de custo de transformação de script de teste 186 com baseno custo de transformação de GUI 5248 (5620).

Em uma implementação, a arquitetura de motor de custo econômico 110 usa uma programação adaptativa incluindo classe e gráficos deobjeto e uma abstração que trata todos os objetos uniformemente. A lógicade travessia de caminho 3924 e a lógica de modelo de custo econômico4996 podem distinguir tipos complexos e simples de objetos de GUI. Dadoum objeto de GUI de algum tipo, a lógica de travessia 3924 e a lógica demodelo de custo econômico 4996 trabalham em conjunto para a identificação de um ou mais objetos alcançáveis que satisfazem a certos critérios. Atarefa realizada é equivalente a determinar se os vetores de declaração descript de teste 3916 que descrevem os caminhos de navegação são válidos.

A tarefa de checagem de scripts de teste (por exemplo, scripts de testetransformados 5400) é grandemente simplificada quando os nomes de nomes de componentes estranhos são definidos como constantes de string.Quando os nomes de objetos de GUI são especificados usando expressões,os valores destas expressões não podem ser determinados usando-se expressões, os valores destas expressões podem não ser determinados atéum tempo de execução. Os gráficos de tipo facilitam o sistema de motor econômico 5200 para inferir tipos de expressões e variáveis que mantêm osnomes de objetos de GUI. O sistema de motor econômico 5200 aplica conceitos com base na Análise de Gráfico de Travessia (TGA) definida em uma programação adaptativa para se inferirem tipos de expressões e variáveis.

Quando os valores de expressões de string nas declarações descript de teste não podem ser computados até o tempo de execução, as expressões de string podem ser inferidas. A lógica de travessia de caminho3924 e a lógica de modelo de custo econômico 4996 trabalham em conjuntopara a análise de vetores de declaração de script de teste 3916, usando-segráficos de tipo pela transformação de vetores de declaração de script deteste 3916 em uma estratégia adaptativa com variáveis substituindo expres-soes de string. A lógica de modelo de custo econômico 4996 computa valores possíveis para cada variável e gera caminhos de travessia para cadaestratégia. Quando pelo menos um caminho é identificado, então, um especificador de mudança de GAP 184 correspondente é validado e/ou um especificador de mudança de GAP sintético 4984 é gerado, uma vez que valoresde expressões que computam nomes de objetos podem não estar nos caminhos computados. A lógica de travessia de caminho 3924 identifica um oumais caminhos possíveis, enquanto a lógica de modelo de custo econômico4996 valida caminhos para as expressões e as declarações.

O sistema de motor econômico 5200 prove uma integridade demodularização como um mecanismo para garantia da validade dos especificadores de mudança de GAP 184 e/ou especificadores de mudança de GAPsintéticos 4984. A integridade de modularização especifica que cada declaração de script de teste atual identificada por um especificador de mudança de GAP 184 e/ou um especificador de mudança de GAP sintético 4984 a sermudada possa se comunicar diretamente apenas com objetos que pertençam a GUIs para as quais a declaração de script de teste atual, conforme mudada pelo especificador de mudança de GAP 184 e/ou por um especifi-cador de mudança de GAP sintético 4984, é criada. As composições de declarações de script de teste atuais mudadas conforme especificado pelosespecificadores de mudança de GAP 184 e/ou especificadores de mudançade GAP sintéticos 4984, nas quais os objetos de GUI são acessados ao sechamarem funções exportadas pelas declarações de script de teste atuaismudadas conforme especificado, não devem violar a integridade de modularização. O sistema de motor econômico 5200 assegura a integridade de modularização de especificadores de mudança de GAP 184 e/ou especificado-res de mudança de GAP sintéticos 4984 pela análise de composições dedeclarações de script de teste atuais mudadas conforme especificado porespecificadores de mudança de GAP 184 e/ou especificadores de mudançade GAP sintéticos 4984 para a construção de relações transitivas entre oscript de teste atual 164 e o script de teste atual 164 mudado conforme especificado pelos especificadores de mudança de GAP 184 e/ou especifica-dores de mudança de GAP sintéticos 4984 (por exemplo, o script de testetransformado 178 e o 5400).

Por exemplo, uma declaração Func("y", "z"), encontrada em umasuíte de scripts de teste relacionados, navega para o campo z de objeto deGUI estranho y em alguns scripts de teste que exportam a função Func. Assim, alguns scripts de teste na suíte de scripts de teste relacionados podemviolar a integridade de modularização ao interoperarem de forma implícita osscripts de teste através da função Func, embora esta comunicação possaser proibida pelas restrições de uma dada suíte de teste. Em uma implementação, o sistema de motor econômico 5200 codifica as restrições de modularização quando definindo scripts de teste usando as restrições de palavrachave como parte de um comentário global em cada script de teste. Estasrestrições definem GAPs e suas telas de GUI, bem como outros scripts deteste com os quais um dado script de teste pode se comunicar. Um exemploé uma declaração que especifica uma restrição que é 'constraints screen("Q") test_scripts("P, S"). Esta restrição efetivamente proíbe um dado script de teste de se comunicar com outros GAPs, telas de GUI e scripts deteste, exceto a tela Q e os scripts de teste P e S, de forma explícita ou implícita.

A complexidade de tempo da lógica de travessia de caminho3924 e da lógica de modelo de custo econômico 4996 é exponencial para otamanho do gráfico de tipo para cada script de teste 164. Devido ao fato de alógica de travessia de caminho 3924 e a lógica de modelo de custo econômico 4996 envolverem a busca de um ou mais nós e bordas no gráfico detipo que contém ciclos para cada nó na estratégia, a complexidade de tempoé 0((V+ E)max(|TT|)), onde V é o número de nós, E é o número de bordas nográfico de tipo e max(|Tr|) é o número máximo de nós em estratégias. As operações de armazenamento de sucessores na tabela de variáveis assumem 0(1). Em geral, o número de nós max(|TT|) em estratégias é muito menor do que o número de nós em gráficos de tipo. Nem todos os nós de gráfico podem precisar ser explorados para cada nó em uma estratégia.

Os sistemas podem ser implementados de muitas formas dife-rentes. Por exemplo, embora alguns recursos sejam mostrados armazenados em memórias que podem ser lidas em computador (por exemplo, comouma lógica implementada como instruções executáveis em computador oucomo estruturas de dados em memória), todos ou parte dos sistemas, dalógica e das estruturas de dados podem ser armazenados em, distribuídosatravés de ou lidos a partir de outros meios que podem ser lidos em máquina. Os meios podem incluir discos rígidos, discos flexíveis, CD-ROMs, umsinal, tal como um sinal recebido a partir de uma rede ou dividido em seçõese recebido em múltiplos pacotes comunicados através de uma rede. Os sistemas podem ser implementados em software, hardware ou uma combinação de software e de hardware.

Além disso, os sistemas podem ser implementados com componentes adicionais, diferentes ou menos. Como um exemplo, um processador ou qualquer outra lógica pode ser implementado com um microprocessador,um microcontrolador, um DSP, um circuito integrado específico de aplicativo(ASIC), instruções de programa, lógica analógica ou digital discreta, ou umacombinação de outros tipos de circuitos ou lógica. Como um outro exemplo,memórias podem ser DRAM, SRAM, flash ou outro tipo de memória. Os sistemas podem ser distribuídos dentre múltiplos componentes, tal como dentromúltiplos processadores e memórias, opcionalmente incluindo múltiplos sistemas de processamento distribuídos. Uma lógica, tais como programas oucircuitos, pode ser combinada ou dividida dentre múltiplos programas, distribuída através de várias memórias e processadores, e pode ser implementada em ou como uma biblioteca de função, tal como uma biblioteca de enlacedinâmico (DLL) ou outra biblioteca compartilhada.

Embora várias modalidades tenham sido descritas, será evidente aproximadamente aqueles de conhecimento comum na técnica que muitas modalidades a mais e implementações são possíveis no escopo da invenção. Assim sendo, a invenção não é para ser restrita, exceto à luz dasreivindicações anexadas e seus equivalentes.

Claims (20)

1. Produto que compreende:uma memória;um limite de similaridade armazenado na memória;um modelo de GUI de aplicativo de interface gráfica de usuário(GUI) (GAP) atual armazenado na memória, o modelo de GUI de GAP atualincluindo um primeiro elemento de GUI de origem;um modelo de GUI de GAP subsequente armazenado na memória, o modelo de GUI de GAP subsequente incluindo um primeiro elemento de GUI de destino; euma lógica de comparação de GAP armazenada na memória, alógica de comparação de GAP compreendendo:uma lógica de análise ponderada operável para determinar umvalor de similaridade com base no primeiro elemento de GUI de origem e noprimeiro elemento de GUI de destino; euma lógica de construção de combinação operável para criar umprimeiro link de elemento de GUI entre o primeiro elemento de GUI de origem e o primeiro elemento de GUI de destino, quando o valor de similaridade exceder ao limite de similaridade.

2. Produto, de acordo com a reivindicação 1, que ainda compreende:uma lógica de mapeamento de recuperação operável para a obtenção de um mapeamento de versão de elemento de GUI entre um segundo elemento de GUI de origem no modelo de GUI de GAP atual e um segundo elemento de GUI de destino no modelo de GUI de GAP subsequente.

3. Produto, de acordo com a reivindicação 2, onde a lógica deconstrução de combinação ainda é operável para:criar um segundo link de elemento de GUI entre o segundo elemento de GUI de origem e o segundo elemento de GUI de destino.

4. Produto, de acordo com a reivindicação 3, onde a lógica de comparação de GAP é operável ainda para:renunciar à execução da lógica de análise ponderada quando omapeamento de versão de elemento de GUI for obtido.

5. Produto, de acordo com a reivindicação 1, onde a lógica decomparação de GAP ainda compreende:uma lógica de análise ponderada operável para a determinaçãodo valor de similaridade.

6. Produto, de acordo com a reivindicação 5, onde a lógica deanálise ponderada é operável para:determinar o valor de similaridade como uma soma ponderadade características de elemento de GUI.

7. Produto, que compreende:uma memória;um modelo de diferença de GUI de base armazenado na memória; euma lógica de comparação de GAP armazenada na memória e operável para:analisar um primeiro elemento de GUI em uma versão de aplicativo de interface gráfica de usuário (GAP) atual em relação a um segundo elemento de GUI em uma versão de GAP subsequente para a determinaçãode um primeiro valor de similaridade; einserir um link de elemento de GUI a partir do primeiro elemento de GUI para o segundo elemento de GUI no modelo de diferença de GUIde base, quando o primeiro valor de similaridade exceder a um limite de similaridade.

8. Produto, de acordo com a reivindicação 7, que ainda compreende:uma tabela de peso armazenada na memória e compreendendopesos de característica de GUI; eonde a lógica de comparação de GAP recupera os pesos de característica de GUI para a determinação do valor de similaridade.

9. Produto, de acordo com a reivindicação 8, onde o valor de similaridade compreende:uma soma de características de elemento de GUI ponderadapelos pesos de característica de GUI.

10. Produto, de acordo com a reivindicação 7, onde a lógica decomparação de GAP ainda é operável para:modificar o limite de similaridade com base em uma entrada de operador.

11. Produto, de acordo com a reivindicação 10, onde a lógica decomparação de GAP ainda é operável para:destacar elementos de GUI combinando entre a versão de GAPatual e a versão de GAP subsequente, em resposta ao limite de similaridade.

12. Produto, de acordo com a reivindicação 7, onde o link de elemento de GUI compreende um identificador do segundo elemento de GUI.

13. Produto, de acordo com a reivindicação 7, onde o link de elemento de GUI ainda compreende um escore de combinação com base no primeiro valor de similaridade.

14. Produto, de acordo com a reivindicação 7, onde a lógica de comparação de GAP ainda é operável para:analisar o primeiro elemento de GUI em relação a múltiplos elementos de GUI na versão de GAP subsequente, incluindo o segundo elemento de GUI, para a determinação de múltiplos valores de similaridade, incluindo o primeiro valor de similaridade.

15. Método, que compreende:a análise de um primeiro elemento de GUI em uma versão deaplicativo de interface gráfica de usuário (GAP) atual em relação a um segundo elemento de GUI em uma versão de GAP subsequente para a determinação de um primeiro valor de similaridade; ea inserção de um link de elemento de GUI a partir do primeiroelemento de GUI para o segundo elemento de GUI no modelo de diferençade GUI de base, quando o primeiro valor de similaridade exceder a um limitede similaridade.

16. Método, de acordo com a reivindicação 15, que ainda compreende:a recuperação de pesos de característica de GUI a partir de umatabela de peso para a determinação do valor de similaridade.

17. Método, de acordo com a reivindicação 16, que ainda compreende:a determinação de uma soma de características de elemento deGUI ponderada pelos pesos de característica de GUI como o primeiro valorde similaridade.

18. Método, de acordo com a reivindicação 15, que ainda compreende:a modificação do limite de similaridade com base em uma entrada de operador.

19. Método, de acordo com a reivindicação 18, que ainda compreende:o destacamento de elementos de GUI combinando entre a versão de GAP atual e a versão de GAP subsequente, em resposta ao limite desimilaridade.

20. Método, de acordo com a reivindicação 15, que ainda compreende:a análise do primeiro elemento de GUI em relação a múltiploselementos de GUI na versão de GAP subsequente, incluindo o segundo elemento de GUI, para a determinação de múltiplos valores de similaridade,incluindo o primeiro valor de similaridade.