BRPI0903392A2 - método implementado em computador para adaptar e usar um ambiente de computador, produto programa de computador e sistema baseado em computador - Google Patents
método implementado em computador para adaptar e usar um ambiente de computador, produto programa de computador e sistema baseado em computador Download PDFInfo
- Publication number
- BRPI0903392A2 BRPI0903392A2 BRPI0903392-0A BRPI0903392A BRPI0903392A2 BR PI0903392 A2 BRPI0903392 A2 BR PI0903392A2 BR PI0903392 A BRPI0903392 A BR PI0903392A BR PI0903392 A2 BRPI0903392 A2 BR PI0903392A2
- Authority
- BR
- Brazil
- Prior art keywords
- computer
- gui
- repository
- policy
- executable files
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- User Interface Of Digital Computer (AREA)
- Analysing Materials By The Use Of Radiation (AREA)
- Image Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
A presente invenção refere-se a um método implementado por computador para adaptar e utilizar um ambiente de computação, em que o ambiente de computação compreende um conjunto de arquivos executáveis, uma estrutura repositória, uma estrutura de tabela, em que a estrutura repositória e a estrutura de tabela são associadas uma à outra, e uma interface gráfica de usuário (GUI 101) que é adaptada para iniciar a execução dos arquivos executáveis, a leitura de dados e/ou escrita de dados na estrutura de tabela, e proporcionar o dado de saida como texto legível por humano, o método implementado por computador que tem as etapas de: proporcionar uma definição de uma alteração do ambiente de computação em um lado de cliente, adaptar os arquivos executáveis, de acordo com a definição da alteração do ambiente de computação em um lado de servidor, introduzir pelo menos um elemento repositório adicional na estrutura repositória no lado de servidor, em que pelo menos um elemento repositório adicional corresponde à adaptação dos arquivos executáveis, adaptar a estrutura de tabela no lado de servidor, que corresponde ao elemento repositório adicional da estrutura repositória, e acessar a estrutura de tabela adaptada no lado de servidor através da dita GUI (101) e/ou executar um ou mais arquivos executáveis no lado de servidor através da dita GUI (101), enquanto mantém substancialmente o esboço visual da dita GUI (101), assim como, um produto de programa de computador e um sistema de computador.
Description
Relatório Descritivo da Patente de Invenção para "MÉTODOIMPLEMENTADO EM COMPUTADOR PARA ADAPTAR E USAR UM AMBIENTE DE COMPUTADOR, PRODUTO PROGRAMA DE COMPUTADORE SISTEMA BASEADO EM COMPUTADOR".
Descrição
A presente invenção refere-se a um método implementado porcomputador para adaptar e utilizar um ambiente de computação, um produtode programa de computador e um sistema baseado em computador.
No presente, na maioria dos campos industriais, os ambientesde computação são usados. Embora exista um grande número de progra-mas de computador que se encontra disponível no mercado para uma varie-dade de aplicações específicas, tais como, muitas aplicações industriais emuitos campos de negócios, as companhias também contam com ambientesde computação personalizados. Tal personalização pode envolver a adapta-ção de um sistema convencionalmente disponível, por exemplo, através deuma equipe de administração interna. Entretanto, dadas as necessidadesespecíficas, também é possível proporcionar soluções individuais para qual-quer tipo de produto que uma empresa deseja estabelecer e vender ou pro-porcionar soluções individuais por razões logísticas, razões de manutenção,etc. Tipicamente, uma equipe de especialistas técnicos é aplicada, a fim deproporcionar tais soluções personalizadas. Além disso, quando a empresadeseja explorar campos de negócios adicionais, em um cenário convencio-nal, um ambiente de computação personalizado adicional será tipicamenteestabelecido, a fim de também proporcionar produtos em tal novo campo domercado.
Um objetivo da presente invenção é aperfeiçoar a flexibilidade,com a qual um ambiente de computação pode ser proporcionado refletindoos requerimentos individuais do usuário de tal ambiente de computação.
O dito objetivo é solucionado de acordo com as reivindicaçõesindependentes. As modalidades preferidas são submetidas às reivindicaçõesdependentes.
Método implementado por computador para adaptar e utilizar umambiente de computação
Um aspecto da presente invenção refere-se a um método im-plementado por computador para adaptar e utilizar um ambiente de compu-tação, em que o ambiente de computação compreende
um conjunto de arquivos executáveis,
uma estrutura repositória,
uma estrutura de tabela, em que
a estrutura repositória e a estrutura de tabela são associadasumas às outras, e
uma interface gráfica de usuário (GUI) que é adaptada para ini-ciar a execução dos arquivos executáveis,
a leitura de dados e/ou escrita de dados na estrutura de tabela, eproporcionar os dados de saída como texto legível por humano,em que o método implementado por computador tem as etapasde: proporcionar uma definição de uma alteração do ambiente decomputação em um lado de cliente,
adaptar os arquivos executáveis de acordo com a definição daalteração do ambiente de computação em um lado de servidor,
introduzir pelo menos um elemento repositório adicional na estru-tura repositória no lado de servidor, em que pelo menos um elemento reposi-tório adicional corresponde à adaptação dos arquivos executáveis,
adaptar a estrutura de tabela no lado de servidor, que corres-ponde ao elemento repositório adicional da estrutura repositória, e
acessar a estrutura de tabela adaptada no lado de servidor atra-vés da dita GUI e/ou executar um ou mais dos arquivos executáveis no ladode servidor através da dita GUI, enquanto mantém substancialmente o esbo-ço visual da dita GUI.
O termo "estrutura repositória", conforme usado no presente pe-dido pode compreender um ou mais modelos e/ou um ou mais banco de da-dos. Em particular, a estrutura repositória pode compreender, ainda maisparticularmente, consistir em um ou mais modelos e/ou um ou mais bancosde dados. Os modelos devem ser organizados em um ou mais bancos dedados. Um "banco de dados" pode ser um banco de dados de hardware.Também é possível, que o banco de dados seja um banco de dados de soft-ware ao definir, por exemplo, uma partição, etc. de um espaço de memóriaexistente.
O termo "associado", conforme usado no presente pedido podecompreender um ou mais elementos da estrutura repositória, que tambémpodem ser referidos como elementos repositórios, podem ser correlaciona-dos a um ou mais elementos da estrutura de tabela, que também podem serreferidos como elementos de tabela. Em particular, para cada elemento re-positório pode-se proporcionar um elemento de tabela correlacionado. Comoum exemplo, na estrutura repositória, através dos elementos repositórios, umou mais parâmetros/variáveis, conforme usados pelos arquivos executáveispodem ser definidos. Na estrutura de tabela, através dos respectivos ele-mentos de tabela, os valores específicos dos ditos elementos repositóriospodem ser definidos. A seguir, os elementos repositórios podem apontar pa-ra um ou mais elementos de tabela. Além disso, podem existir apontadoresespecíficos que conectam um ou mais elementos repositórios a um ou maiselementos de tabela, em particular, que podem conectar cada um dos ele-mentos repositórios a um respectivo elemento de tabela. Em outras palavras,o número de elementos repositórios e o número de elementos de tabela po-dem ser idênticos.
O termo "texto legível por humano", conforme contido no presen-te pedido pode compreender texto escrito, tais como, políticas de contrato,em particular, apólices de seguro, etc. O dito texto legível por humano podeser impresso em uma impressora e/ou proporcionado como um arquivo dedados, tal como, um arquivo PDF, um arquivo Microsoft Word0, etc, que po-dem ser visualizados em um dispositivo de exibição, tal como, uma tela decomputador, um PDA, etc.
O termo "em uma definição de uma alteração de um ambiente decomputação no lado de cliente", pode compreender a definição de um novoproduto para o usuário do método implementado por computador. Ademais,o dito termo "proporcionar uma definição de uma alteração ..." pode compre-ender a utilização de uma definição pendente de um ambiente de computa-ção e a alteração de elementos/parâmetros específicos do dito ambiente.Como um exemplo, parâmetros/variáveis adicionais e/ou novos podem serintroduzidos. Também é possível que os parâmetros/variáveis existentes se-jam alterados. Também é possível que os parâmetros/variáveis existentessejam multiplicados. O anterior também pode compreender que o código le-gível por máquina adicional é proporcionado. De maneira alternativa ou adi-cional, o código já existente pode ser alterado.
Levando em conta todas as ditas alterações, os arquivos execu-táveis podem ser adaptados no lado de servidor. A adaptação dos arquivosexecutáveis pode compreender um ou mais arquivos executáveis, em parti-cular, um conjunto de arquivos executáveis, ainda mais particularmente, to-dos os arquivos executáveis são novamente criados. A criação dos arquivosexecutáveis adaptados/novos pode ser realizada compilando-se o códigolegível por máquina adaptado no lado de servidor. Em outras palavras, pro-porcionando-se uma definição de uma alteração do ambiente de computaçãono lado de cliente, os arquivos executáveis adaptados/novos podem ser cri-ados no lado de servidor.
De acordo com a adaptação dos arquivos executáveis, pelo me-nos um elemento repositório adicional é introduzido na estrutura repositóriano lado de servidor. Em outras palavras, os arquivos executáveis podem seralterados de uma maneira que um ou mais parâmetros adicionais, em parti-cular, uma ou mais variáveis adicionais podem ser manipuladas usando osditos arquivos executáveis. Como uma conseqüência, um ou mais elementossão introduzidos na estrutura repositória, que reflete os ditos parâme-tros/variáveis adicionais. Os ditos novos elementos na estrutura repositóriapode compreender a definição específica dos ditos novos parâme-tros/variáveis.
Alterações similares podem ser realizadas na estrutura de tabe-la. Isto significa que, uma ou mais tabelas adicionais podem ser introduzidas.O termo "adaptar a estrutura de tabela" pode compreender a manutenção dadefinição de tabela geral, porém, adiciona elementos adicionais nas tabelas.Portanto, também pode ser possível que as tabelas existentes sejam amplia-das, em particular, ao introduzir ou permitir a introdução de valores que refle-tem os elementos recentemente adicionados à estrutura repositória. Em ou-tras palavras, a estrutura repositória pode compreender um ou mais parâme-tros adicionais. Portanto, como um exemplo, a estrutura de tabela é modifi-cada para permitir o armazenamento e/ou leitura de valores específicos dosditos novos parâmetros/variáveis.
"Manter o esboço visual da dita GUI" pode significar que a maio-ria dos elementos da GUI é inalterada, enquanto apenas um número menorde elementos da GUI é modificado considerando, deste modo, a alteraçãodos arquivos executáveis e/ou a alteração dos elementos repositórios, isto é,a alteração da estrutura repositória e/ou a alteração dos elementos de tabe-la, isto é, a alteração da estrutura de tabela.
Em outras palavras, embora um ou mais dos elementos da GUIpossam ser modificados em relação à adaptação dos arquivos executáveise/ou à adaptação da estrutura repositória e/ou à adaptação da estrutura detabela, no entanto, a aparência cognitiva da GUI, conforme entendida pelousuário, pode ser substancialmente a mesma.
Consequentemente, o método implementado por computadoracima permite um uso muito intuitivo e de fácil entendimento do ambiente decomputação pelo usuário, mesmo quando o ambiente de computação tiversido adaptado. Isto significa, o ambiente de computação pode ser alterado,de modo que um ou mais produtos adicionais possam ser incluídos e/oupossam ser criados ao usar a dita GUI. Isto pode compreender a obtençãode um texto legível por humano, que não foi capaz de ser obtidos antes daadaptação do ambiente de computação. No entanto, o uso do ambiente decomputação se mantém substancialmente idêntico quando comparado aouso antes da adaptação do ambiente de computação.
Adicionalmente, o método descrito acima permite um uso e/ouadaptação eficiente do ambiente de computação, enquanto conserva particu-larmente o uso de recursos. Este se encontra entre outros casos, uma vezque uma estrutura já existente, em particular, uma estrutura repositória e/ouestrutura de tabela já existente pode ser facilmente modificada, de acordocom as necessidades do ambiente de computação adaptado, sem propor-cionar substancialmente uma estrutura repositoria e/ou estrutura de tabelacompletamente nova. De preferência, a estrutura repositoria existente podeser usada e pode ser apenas adicionalmente aumentada, por exemplo, adi-cionando-se elementos adicionais. Consequentemente, a estrutura de tabelaexistente também pode ser usada e pode ser apenas aumentada. Portanto, aflexibilidade do ambiente de computação é aumentada, uma vez que a mes-ma é facilmente adaptável às diferentes necessidades do usuário.
Como uma vantagem adicional, de acordo com o método descri-to acima, um ambiente de computação existente pode ser ampliado de umamaneira simples e intuitiva, em um período de tempo muito curto.
No método, de acordo com o presente pedido, a adaptação dosarquivos executáveis pode ser realizada de maneira similar à definição e àcriação dos arquivos executáveis, conforme descrito em detalhes adicionais abaixo.
No método, de acordo com o presente pedido, a adaptação daestrutura de tabela no lado de servidor e o acesso da estrutura de tabela nolado de servidor através da dita GUI podem ser realizados de maneira simul-tânea. Em outras palavras, a estrutura repositoria pode ser modificada e/ouuma estrutura repositoria modificada pode ser proporcionada, mediante acriação dos arquivos executáveis modificados e/ou adicionais no lado deservidor. A estrutura de tabela modificada, que pode compreender a introdu-ção de elementos de tabela adicionais na estrutura de tabela existente e/ouremoção de elementos de tabela existentes da estrutura de tabela existentee/ou criação de novas tabelas na estrutura de tabela existente pode ser rea-lizada mediante a execução de um ou mais arquivos executáveis usando-se a GUI.
Com relação a isto, a GUI pode ser executada em um clienteadicional do servidor. Isto significa que se pode proporcionar uma estruturade servidor de cliente muito complexa que compreende um dispositivo deservidor e pelo menos dois dispositivos de cliente, em que em um dispositivode cliente, a definição da alteração dos arquivos executáveis é realizada, nodispositivo de servidor os arquivos executáveis são alterados e no dispositivode cliente adicional, a GUI pode ser executada. Também é possível que pelomenos uma parte ou todos os arquivos executáveis sejam executados emum cliente que também executa a GUI. Também pode ser possível compre-ender clientes adicionais e diversos arquivos executáveis podem ser execu-tados em diversos clientes enquanto a GUI é executada em um cliente. Demaneira similar, pelo menos um arquivo ou arquivos executáveis adicionaispode ser executado no servidor e/ou um primeiro cliente e/ou um segundocliente e/ou um terceiro cliente, etc. A GUI pode ser executada no servidorou em um dos clientes.
O termo "adaptado para iniciar" pode compreender que a GUIque pode ser conectada a uma funcional ou casos que podem realizar a tare-fa iniciada pela GUI. Como um exemplo, a GUI pode acionar a execução deum arquivo executável selecionando-se um botão ou similar na GUI. Portan-to, a GUI é adaptada para iniciar a execução de um arquivo executável.
O método acima também pode ser referido como administraçãode apólice.
Modalidades específicas do método implementado por computador
De maneira exemplificativa, os arquivos executáveis e a dita GUIacessam a mesma estrutura de tabela, em que o acesso compreende escre-ver dados e/ou ler dados a partir da mesma estrutura de tabela.
De maneira vantajosa, não é necessário que os dados sejamenviados e recebidos entre as entidades específicas, tal como um servidorde arquivo e um servidor de terminal. De preferência, os arquivos executá-veis podem acessar de maneira simultânea ou sucessiva um subconjunto outodas as tabelas da estrutura de tabelas. O acesso nesse sentido pode com-preender a leitura e/ou escrita de dados na e/ou a partir da estrutura de tabe-la. Como um exemplo, a GUI pode ter um campo para lançar dados. Os ditosdados podem ser escritos em uma tabela específica. Além disso, a GUI podeter um campo, tal como um botão para acionar o recibo de dados que podeser exibido na GUI ou que pode ser introduzido em um produto de saída, talcomo, uma apólice de seguro ou similar. Portanto, os dados podem ser lidosa partir da estrutura de tabela através do uso da dita GUI, em particular, aoexecutar um arquivo executável, usando a dita GUI. A execução do arquivoexecutável pode ser acionada através da seleção do dito botão. De maneiraadicional ou alternativa, a GUI pode ler os dados diretamente a partir de umaou mais tabelas, de modo que a informação possa ser exibida na GUI emuma tela de computador para informação do usuário da GUI.
De maneira exemplificativa, a adaptação do ambiente de compu-tação é substancialmente livre da cópia da estrutura repositória e/ou da es-trutura de tabela.
Vantajosamente, de uma maneira muito rápida e eficiente, osprodutos adicionais podem ser introduzidos no ambiente de computação e-xistente. Em outras palavras, o ambiente de computação existente pode, deuma maneira muito eficiente, ser aumentado ao adicionar e/ou deletar oselementos repositórios e/ou elementos de tabela na dada estrutura repositó-ria e/ou estrutura de tabela.
Em um método convencional, quando uma empresa deseja ex-plorar um novo campo de negócio, todo o ambiente de computação geral-mente é duplicado e a duplicata do ambiente de computação é modificada nonovo campo de negócio. Em essência, isto significa, de maneira convencio-nal, que "dois" ambientes de computação são proporcionados. De acordocom o método descrito acima, por outro lado, o ambiente existente pode serampliado de uma maneira simples e eficiente, em particular, para proporcio-nar e/ou ser adaptado aos produtos que não foram incluídos antes. Alémdisso, de maneira vantajosa, uma vez que o ambiente existente é ampliado,o recurso de computação, em particular, o espaço de armazenamento é con-servado, ao evitar a duplicata das estruturas de banco de dados que inclui,em particular, as estruturas repositórias e/ou estruturas de tabelas.
De maneira exemplificativa, quando adapta o ambiente de compu-tação, a estrutura repositória é substancialmente mantida.
Na descrição acima, o termo "estrutura" significa basicamente adefinição geral do repositório. Isto pode compreender inúmeros modelos e/oucomo um ou mais subconjuntos de inúmeros modelos interagem e/ou sãoconectados uns aos outros. Além disso, também pode compreender comoum ou mais subconjuntos dos modelos pode ser conectado a um ou maissubconjuntos da estrutura de tabela, por exemplo, uma ou mais tabelas.
Consequentemente, a estrutura repositória geral é substancialmente manti-da, isto significa que a definição dos repositórios e/ou do número de repositó-rios é substancialmente inalterada. Entretanto, um ou mais elementos reposi-tórios podem ser adicionados à estrutura repositória e/ou um ou mais ele-mentos repositórios podem ser deletados da estrutura repositória. Em outraspalavras, um modelo adicional pode ser introduzido. Consequentemente,pode ser possível que uma linha adicional em um banco de dados seja intro-duzida, compreendendo um ou mais valores do dito modelo. Também é pos-sível que um ou mais parâmetros e/ou variáveis de um modelo possam seralterados e/ou introduzidos. Consequentemente, em uma ou mais tabelas daestrutura de tabela, os valores específicos e/ou marcadores de posição po-dem ser proporcionados, de modo que os valores específicos dos ditos pa-râmetros/variáveis adicionais possam ser armazenados.
De maneira exemplificativa,
- usando a dita GUI, o dado de saída é gerado pelo ambiente decomputação,
e
- após a adaptação do ambiente de computação, usando a ditaGUI, o dado de saída adicional é gerado pelo dito ambiente de computaçãoadaptado.
De maneira vantajosa, após a adaptação do ambiente de compu-tação, o dado de saída pode ser gerado, esta geração não era possível an-tes da adaptação. Como um exemplo, antes da adaptação, o ambiente decomputação pode ser capaz de computar o dado de saída que refere-se aum ou mais produtos, tais como, uma apólice de seguro de carro e uma apó-lice de seguro imobiliário. Após a adaptação, o ambiente de computação po-de gerar e produzir, adicionalmente, como um exemplo, uma apólice de se-guro de saúde.De maneira convencional, a fim de adaptar um ambiente decomputação existente que pode proporcionar apólices de seguro de carro eapólices de seguro de saúde, o ambiente de computação existente precisaser duplicado e adaptado para a apólice de seguro de saúde. Além disso, umambiente de computação isolado precisa ser proporcionado para criar asapólices de seguro de carro e um ambiente de computação isolado foi pro-porcionado para a criação das apólices de seguro imobiliário. O ambiente decomputação isolado, neste sentido, significa que cada ambiente de computa-ção compreende seu próprio conjunto de arquivos executáveis, sua própriaestrutura repositória, sua própria estrutura de tabela e sua própria interfacegráfica de usuário.
De maneira vantajosa, tais ambientes de computação isoladospodem ser evitados de acordo com o método descrito acima. De preferência,o ambiente existente pode ser modificado para usar os arquivos executáveisexistentes, se necessário, modificados, a estrutura repositória existente, senecessário, modificada, a estrutura de tabela existente, se necessário, modi-ficada e a GUI existente, se necessário, modificada, porém, ainda tem subs-tancialmente o esboço visual idêntico.
De maneira exemplificativa, o método compreende adicionalmentea etapa de:
- adaptar a dita GUI, de acordo com pelo menos um elemento re-positório adicional na estrutura repositória introduzindo-se pelo menos umelemento de exibição em uma entidade de entrada/saída dinâmica da ditaGUI, enquanto mantém as entidades de entrada/saída da dita GUI substan-cialmente inalteradas.
De maneira vantajosa, de acordo com o método acima, propor-cionar a definição de uma alteração do ambiente de computação pode en-volver a adição de um ou mais elementos repositórios. A adição dos ditoselementos repositórios pode ser refletida através da adição dos elementosde exibição na GUI, em particular, em uma janela específica da GUI. As ja-nelas, botões restantes, etc. da GUI podem manter-se substancialmente nãomodificados. Em outras palavras, uma entidade de entrada/saída exemplifi-cativa pode ser uma janela da GUI.
De maneira exemplificativa, introduzindo-se pelo menos um ele-mento de exibição adicional na dita entidade de entrada/saída dinâmica dadita GUI, o tamanho da dita entidade de entrada/saída dinâmica é mantido.
De maneira exemplificativa, a dita entidade de entrada/saída di-nâmica da GUI é implementada como uma lista suspensa, se o tamanho dadita entidade de entrada/saída dinâmica for menor que o tamanho comum detodos os elementos de exibição da dita entidade de entrada/saída.
De maneira vantajosa, no caso de o número de elementos deexibição adicionados ser muito grande, a fim de exibir todos os ditos elemen-tos simultaneamente na dita janela, à medida que a barra de rolagem podeser proporcionada, a fim de rolar através dos ditos elementos de exibição.
Em outras palavras, a adaptação do ambiente de computação e,em particular, a introdução de um grande número de elementos repositórios,pode ser refletida pela introdução de um grande número de elementos deexibição na GUI. É possível que para cada elemento repositório que é recen-temente introduzido na estrutura repositoria, um único elemento de exibiçãopossa ser incluído na dita janela e na GUI. Embora o número de elementospossa ser muito grande, a fim de ser exibido simultaneamente na dita janelaatravés da barra de rolagem, todos os elementos podem ser exibidos para ousuário.
De maneira exemplificativa,
- para exibir um elemento de exibição na entidade de entra-da/saída dinâmica, o conteúdo do dito elemento de exibição é lido a partir deum elemento de tabela associado
e/ou
- para armazenar o conteúdo de um elemento de exibição daentidade de entrada/saída dinâmica, o conteúdo do dito elemento de exibi-ção é escrito em um elemento de tabela associado.
De maneira exemplificativa,
- os elementos de tabela armazenados na dita estrutura de tabe-la são armazenados em uma ordem de tabela predeterminada,* em que
- os elementos de exibição exibidos na entidade de entra-da/saída dinâmica são exibidos em uma ordem de exibição predeterminada,e em que
- a ordem de tabela predeterminada é diferente da ordem de exi-bição predeterminada.
Em outras palavras, na estrutura de tabela os elementos de ta-bela podem ser incluídos em uma ou mais tabelas da estrutura de tabela. Oselementos de tabela podem ser armazenados em uma determinada ordem,ou seja, a ordem de tabela. As informações associadas a cada um dos ele-mentos de tabela podem ser exibidas na janela descrita acima da GUI comoos elementos de exibição. A seguir, os mesmos dados podem ser referidospor nomes diferentes, ou seja, pelo nome de um elemento de tabela e pelonome de um elemento de exibição.
Além disso, a ordem na qual o dado é exibido como os elemen-tos de exibição na GUI (isto é, a ordem de exibição) pode diferir da ordem naqual o dito dado é armazenado como o elemento de tabela nas ditas tabelas(isto é, a ordem de tabela). De maneira exemplificativa, a estrutura de tabelapode compreender elementos de tabela N, em que N é um número natural. Ajanela pode exibir elementos de exibição M, em que M é um número natural.N e M podem ser idênticos. N e M também podem diferir uns dos outros.Como um exemplo adicional, N pode ser idêntico a M, isto é, pode existir umnúmero idêntico de elementos de tabela e elementos de exibição. Entretanto,a ordem de pelo menos dois elementos de tabela na estrutura de tabela po-de ser invertida quando comparada com a ordem dos respectivos elementosde exibição, à medida que exibidos na GUI. Isto já pode ser considerado co-mo uma ordem diferente.
De maneira exemplificativa, um dispositivo de ordem de elemen-to é usado
- para ler o conteúdo de um elemento de tabela no elemento deexibição associado na ordem de exibição,e- para escrever o conteúdo de um elemento de exibição no ele-mento de tabela associado na ordem de tabela.
De maneira vantajosa, apesar da ordem diferente dos elementosde tabela na estrutura de tabela e dos elementos de exibição, conforme exi-bidos na GUI usando o dispositivo de ordem, a informação é proporcionadapara o usuário do ambiente de computação na forma/ordem correta. Comoum exemplo, o dispositivo de ordem pode ser uma Ferramenta JAVA. Comoum exemplo, a Ferramenta Java pode ser o software que suporta a extremi-dade frontal com o usuário. A mesma pode permitir que o usuário interajacom os processos de negócios codificados e situados no computador central.Além disso, o mesmo pode suportar a interface com o usuário ao longo dastelas, e o dado lançado é processado pelas Classes Java. As classes podemser uma ou mais faixas de campos ordenados com um certo critério, que en-via ou recebe dados específicos para os ditos campos. A Ferramen-ta/Software Java pode usar as classes para comunicar e/ou processar osdados lançados pelo usuário.
A descrição acima refere-se, em particular, à ordem dos elemen-tos de tabela e os elementos de exibição se aplicam, de maneira similar, àordem dos elementos repositórios e dos elementos de tabela, assim como aordem dos elementos repositórios e dos elementos de exibição.Produto de programa de computador de acordo com um aspecto
Um aspecto da presente invenção refere-se a um produto deprograma de computador, armazenado em um meio legível por computadorou proporcionado como um sinal de dados, que compreende instruções legí-veis por computador, que quando carregadas na memória de um computadore executadas pelo computador obtém este computador que realiza o métodode acordo com a invenção.
Sistema baseado em computador para gerar dados de saída de acordo comum aspecto
Um aspecto da presente invenção refere-se a um sistema base-ado em computador para gerar o dado de saída em particular, sob a formade texto legível por humano, que compreende- um conjunto de arquivos executáveis,
- uma estrutura repositoria e
- uma estrutura de tabela, em que
- a estrutura repositoria e a estrutura de tabela são associadasumas às outras,
e
- uma interface gráfica de usuário (GUI) que é adaptada para
- executar os arquivos executáveis,
- ler dados a partir da e/ou escrever dados na estrutura de tabe-la, e
- proporcionar o dado de saída como texto legível por humano,
- o sistema baseado em computador que compreende adicio-nalmente:
- uma interface de cliente para definir uma alteração dos arqui-vos executáveis em um lado de cliente,
- dispositivo de servidor para
- adaptar os arquivos executáveis de acordo com a definição daalteração em um lado de servidor,
- introduzir pelo menos um elemento repositório adicional na es-trutura repositoria no lado de servidor, em que menos um elemento repositó-rio adicional corresponde à adaptação dos arquivos executáveis
e
- adaptar a estrutura de tabela no lado de servidor, que corres-ponde ao elemento repositório adicional da estrutura repositoria,
e em que
- a dita GUI é adaptada para acessar a estrutura de tabela adap-tada no lado de servidor e/ou para executar um ou mais arquivos executá-veis no lado de servidor, enquanto o esboço visual da dita GUI é substanci-almente mantido.
Além do que foi dito acima, o presente pedido também podedescrever um método implementado por computador para gerar arquivos decomputador executáveis interrelacionados em um lado de servidor que com-preendem as etapas de:
- proporcionar em um lado de cliente a interface gráfica de usuá-rio associada ao código legível por máquina em uma linguagem de máquina,em que a interface gráfica de usuário exibe os dados substancialmente notexto claro;
- selecionar e associar duas ou mais seções de código legívelpor máquina na linguagem de máquina no dito lado de cliente usando a ditainterface gráfica de usuário;
- a verificação implementada por computador de uma coerênciado dito código legível por máquina selecionado antes no lado de cliente, depreferência, sem compilar o dito código legível por máquina selecionado nolado de cliente e produzir o resultado da dita verificação de coerência subs-tancialmente no texto claro, em que
- a verificação da coerência do dito código legível por máquinaselecionado compreende:
- uma verificação implementada por computador da coerênciadas ditas seções selecionadas do código legível por máquina e/ou
- a verificação implementada por computador da coerência dasditas associações das ditas seções selecionadas do código legível por má-quina; e
mediante a aprovação da coerência, compila as duas ou maisseções selecionadas e associadas do código legível por máquina em umlado de servidor para criar e/ou adaptar e/ou modificar dois ou mais arquivosexecutáveis interrelacionados que são executáveis pelo servidor.
De maneira vantajosa, os arquivos de computador executáveisem um lado de servidor podem ser produzidos e/ou adaptados e/ou modifi-cados por uma pessoa, substancialmente sem quaisquer habilidades especí-ficas em programação de computador. De preferência, usando a interfacegráfica de usuário (GUI) através do texto claro, o usuário pode coletar duasou mais seções de código legível por máquina na linguagem de máquinasem ler tal código legível por máquina ou linguagem de máquina e, em parti-cular, sem precisar saber o código legível por máquina ou linguagem de má-quina. O usuário pode escolher seções, tais como, "elementos", "validações","textos/parágrafos que são associados às seções específicas do códigolegível por máquina na linguagem de máquina. Como um exemplo, uma vali-dação pode ser associada ao código legível por máquina que compreendeuma avaliação, se uma variável e/ou parâmetro for maior que outra variávele/ou parâmetro. As variáveis e/ou parâmetros também podem ser especifi-cados usando a GUI, em que o valor específico da variável e/ou parâmetro écomputado quando o programa é executado.
Em outras palavras, o usuário pode criar substancialmente umavalidação ao lançar duas ou mais variáveis e/ou parâmetros e lançar tambémo tipo de validação, por exemplo, uma operação, tal como, "maior que", "me-nor que", "igual a", etc. Além disso, o usuário pode lançar a conseqüência davalidação, isto é, o que será feito quando uma condição da validação forcumprida ou a dita não for cumprida. Como um exemplo, quando uma condi-ção é cumprida, o método implementado por computador se move para umapróxima etapa.
Em outras palavras, usando a GUI, o código legível por máquinacomplexo na linguagem de máquina pode ser montado, sem o usuário terconhecimento específico do código legível por máquina ou da codificação emparticular. De preferência, o usuário pode ser uma pessoa versada na técni-ca, tal como, um engenheiro mecânico, um economista, etc, que precisausar os arquivos de computador executáveis e, portanto, deseja proporcionararquivos de computador executáveis de acordo com suas necessidades.Consequentemente, de maneira vantajosa, ocorre pouca perda de informa-ção, uma vez que o usuário não precisa explicar para um inventor a necessi-dade dos arquivos executáveis.
De maneira preferencialmente adicional, a verificação implemen-tada por computador de uma coerência do dito código legível por máquinaseletivo no lado de cliente antes de compilar o dito código legível por máqui-na selecionado permite que o usuário, de um modo muito rápido e eficiente,verifique o uso dos arquivos executáveis produzidos em uma etapa posterior.Em particular, mesmo se não conectado em um lado de servidor ou se o ladode servidor não estiver disponível para o usuário, por qualquer motivo, o u-suário já pode verificar no lado de cliente, sem produzir os arquivos executá-veis, se os dois ou mais arquivos executáveis irão trabalhar de maneira ade-quada no lado de servidor. Esta verificação pode ser particularmente feita,mesmo se o usuário não foi versado na técnica de programação específicas,uma vez que a dita verificação da coerência é implementada por computa-dor. Em outras palavras, no lado de cliente, o computador examina as se-ções selecionadas do código legível por máquina. Deste modo, o computa-dor pode examine cada uma das seções separadamente. O computadortambém pode examinar as seções selecionadas em sua totalidade. De prefe-rência, o computador pode examine qualquer inter-relação entre as seçõesselecionadas do código. Como um exemplo, o computador pode examinar asaída de uma seção do código que é lançado em outra seção do código,como se o código fosse compilado.
Em outras palavras, o computador pode examinar, sem compilar,se uma possível saída de uma primeira seção é adequada como a entradade outra seção. Portanto, as associações também entre as seções do códigoselecionado podem ser examinadas de um modo computadorizado pelo me-nos parcialmente automático. Deste modo, o computador pode aplicar regrasespecíficas, tais como, regras matemáticas e/ou lógica específica, tal como,lógica matemática, no código legível por máquina. Também, o computadorpode usar regras e/ou lógica de código legível por máquina, tais como regrase/ou lógica da linguagem de codificação específica, a fim de examinar asseções selecionadas e/ou as associações entre as seções selecionadas do código.
Além disso, o computador no lado de cliente (isto é, um compu-tador ou processador de cliente) pode examinar as seções selecionadas docódigo e/ou as associações para integridade. Como um exemplo, se umaseção for associada à outra seção, de modo que a saída de uma seção sejalançada em outra seção, em que a outra seção precisa, por exemplo, de u-ma, duas ou mais variáveis de entrada, o computador pode examinar qual-quer incoerência, por exemplo, se a variável de saída de uma seção de códi-go atender os requerimentos da entrada de outras seções de código. Alémdisso, o computador pode avaliar o comportamento de tempo de execuçãodo código, mesmo sem compilação, por exemplo, ao usar a lógica matemáti-ca. Como um exemplo, se o código compreende uma fração e o denomina-dor da dita fração é uma variável que pode se tornar muito pequena duranteo tempo de execução devido às razões matemáticas das faixas de variá-vel/parâmetro proporcionadas, o computador no lado de cliente pode desco-brir que, como um resultado, um transbordamento de dados ou similar, iráocorrer no caso de o arquivo executável ser executado no lado de servidor.Em particular, o computador no lado de cliente pode reconhecer que umtransbordamento de dados irá ocorrer, mesmo sem a criação do arquivo e-xecutável (isto é, sem compilação) e mesmo sem executar o arquivo execu-tável. Consequentemente, o computador pode proporcionar a respectiva saí-da de coerência.
A saída de coerência pode ser uma mensagem de erro ou umamensagem de aprovação, particularmente, em texto claro. Como um exem-plo, os erros matemáticos ou similares, que podem ser proporcionadosquando se verifica a coerência do código selecionado e composto na lingua-gem de máquina, tal como, uma linguagem de programação, pode ser tradu-zida em texto claro, em particular, texto legível por humano, ainda mais parti-cularmente, de acordo com as semânticas entendíveis e legíveis por humanoe regras de linguagem. Consequentemente, o usuário que não é um especia-lista em codificação, pode verificar se as seções de código legível por má-quina, que foram selecionadas usando a GUI, podem ser sucessivamenteexecutadas no lado de servidor, sem
a) a necessidade de compilar as seções selecionadas de códigono lado de servidor e/ou sem
b) a necessidade do usuário de ter habilidades de programaçãoespecíficas, uma vez que a GUI proporciona uma saída legível e entendívelpor uma pessoa que não é versada na técnica de programação.
Como um exemplo, um tradutor pode ser proporcionado conec-tado e/ou usando uma ou mais tabelas que compreendem mensagens emlógica matemática e/ou lógica de linguagem legível por máquina, etc. quesão ligadas/associadas ao texto claro que cobre o respectivo significado nalinguagem/lógica legível por humano.
O termo "texto claro" refere-se a uma exibição de texto, de acor-do com as semânticas humanas, gramática humana, linguagem humana,particularmente independente/diferente da linguagem legível por máquina.Como um exemplo, o texto claro pode ser proporcionado em inglês, espa-nhol, alemão, etc. O texto claro é, particularmente, o texto que pode ser lidoe entendido por uma pessoa, que não é versada na técnica de programação,como um exemplo, sem ter habilidades específicas em qualquer linguagemde programação. O texto claro pode ser proporcionado usando também figu-ras, imagens, pictóricas, cores diferentes e/ou esquemas de cores, realce depalavras, em particular, exibição intermitente de palavras, etc.
O termo "código legível por máquina na linguagem de máquina"(contrário ao texto claro) pode se referir a qualquer linguagem de programa-ção convencional que pode ser, por exemplo, COBOL, FORTRAN, C, C++,PASCAL, JAVA, etc. O código legível por máquina na linguagem de máquinapode compreender elementos, que também podem ser compreendidos portexto claro na linguagem humana. Como um exemplo, um código legível pormáquina na linguagem de máquina pode compreender as palavras de umalinguagem humana, em particular, palavras na língua inglesa, tais como, "e","se", "então", etc. Entretanto, o código legível por máquina na linguagem demáquina é baseado na lógica matemática, em particular, como uma ferra-menta matemática quando comparada ao texto claro que é baseado na gra-mática de uma linguagem humana como sua lógica intrínseca. Portanto, otermo "linguagem de máquina" não é necessariamente limitado ao significa-do de um baixo nível de linguagem de programação.
O termo "verificação de coerência implementada por computa-dor" descreve o exame implementado por computador das seções de códigoselecionado e/ou das associações entre as seções de código selecionado,conforme descrito acima. Em particular, as seções de código selecionadopodem ser separadamente examinadas. Também é possível que os conjun-tos de seções possam ser examinados. Também é possível que a totalidadedas seções selecionadas possa ser examinada. É possível que as associa-ções entre duas ou mais seções de código sejam examinadas. As associa-ções podem, por exemplo, compreender que a saída de uma seção é a en-trada de outra seção. As associações podem, por exemplo, compreenderque duas mais seções compartilham uma ou mais seções, variá-veis/parâmetros adicionais, etc.
Contrário à "verificação implementada por computador de umacoerência", o termo "compilação" descreve a tradução de texto escrito emuma linguagem legível por computador que também pode ser referida comouma linguagem fonte, em outra linguagem legível por computador que tam-bém pode ser referida como a linguagem alvo. A seqüência original é geral-mente chamada de código fonte e a saída pode ser chamada de código deobjeto. Comumente, a saída tem uma forma adequada para processamentoatravés de outros programas (por exemplo, um vinculador).
Através da compilação, o código fonte pode ser traduzido em umprograma executável ou arquivo executável. Em particular, o código fonte deum alto nível de linguagem de programação pode ser traduzido em uma lin-guagem de nível inferior, tal como, por exemplo, linguagem de montagem.
O termo "aprovação da coerência" descreve que uma verificaçãode coerência pode ser aprovada pelo computador de cliente, em particular,automaticamente, por exemplo, se um resultado específico for obtido pelaverificação implementada por computador da coerência. Se um resultadoespecífico não for obtido, é possível que uma mensagem de erro seja produ-zida. No entanto, mesmo no caso de tal mensagem de erro, um usuário podeaprovar de maneira alternativa ou adicional a coerência manualmente, porexemplo, se a saída da aprovação computadorizada proporcionar um signifi-cado específico no texto claro, tal como, por exemplo, certas variáveis nãoforam consideradas ou não foram adequadamente consideradas pelos arqui-vos executáveis a serem gerados, etc.
O termo "arquivos executáveis interrelacionados" descreve quedois ou mais arquivos executáveis, quando executados, trabalham juntos,por exemplo, compartilham recursos, variáveis/parâmetros comuns, etc.Também, o termo "arquivos executáveis interrelacionados" pode descreverque um ou mais arquivos executáveis executam um mais outros arquivosexecutáveis. Isto também é possível pelo fato de que a saída de um ou maisarquivos executáveis é/são entradas de um ou mais arquivos executáveis.Deste modo, tais arquivos são interrelacionados.
O termo uma "interface gráfica de usuário é associada ao códigolegível por máquina" descreve que a GUI tem uma relação com o código le-gível por máquina, tal como, acesso a um banco de dados, em que o códigolegível por máquina é armazenado nas tabelas, etc.
A seguir, de acordo com este aspecto, a geração de arquivos decomputador executáveis interrelacionados no lado de servidor pode ser fa-cilmente realizada e/ou mantida. Em particular, de maneira vantajosa, o có-digo legível por máquina na linguagem de máquina pode ser proporcionado ecomposto de uma maneira muito fácil e suficiente por uma pessoa que não éversada na técnica de programação. De maneira adicionalmente vantajosa,tal composição de código legível por máquina na linguagem de máquina po-de ser obtido em um tempo muito curto, uma vez que compilações tipica-mente muito compridas não precisam ser necessariamente realizadas muitasvezes. De preferência, as seções selecionadas do código legível por máqui-na precisam ser compiladas apenas uma vez, após uma aprovação bem-sucedida da coerência. Em relação a isto, a verificação implementada porcomputador de uma coerência pode ser realizada de maneira iterativa, parti-cularmente, enquanto a coerência é aprovada.
Em outras palavras, no caso de uma mensagem de erro ser cri-ada, usando a GUI, a seleção de duas ou mais seções de código legível pormáquina pode ser alterada e/ou as associações entre as duas ou mais se-ções de código legível por máquina podem ser alteradas. A etapa de sele-cionar e associar duas ou mais seções de código legível por máquina tam-bém pode incluir o ajuste de variáveis/parâmetros usados pelas ditas duasou mais seções de código legível por máquina. Consequentemente, no casoem que nenhuma aprovação da coerência foi ainda estabelecida, em vez deselecionar e associar as seções adicionais do código legível por máquinae/ou não selecionar e/ou não associar uma ou mais seções de código legívelpor máquina, as variáveis/parâmetros das duas ou mais seções seleciona-das de código legível por máquina podem ser alterados, deletados, recémajustados, etc. É possível que a etapa de alterar, deletar, reinicializar, etc,dos parâmetros/variáveis é realizada de maneira iterativa em combinaçãocom a verificação implementada por computador de uma coerência, até aaprovação bem-sucedida da coerência.
A seleção e a associação de duas ou mais seções de código po-de compreender, de preferência, um ou mais:
- lançar uma ou mais regras, tais como, condições, operaçõesmatemáticas, etc. usando a GUI, em que as ditas uma ou mais regras, taiscomo, condições, operações matemáticas, etc são lançadas em texto claro;
- armazenar a entrada em uma ou mais tabelas de definição es-pecífica;
- armazenar uma ou mais regras, tais como, condições, opera-ções matemáticas, etc. em uma tabela de condições específicas, de prefe-rência, diferente das tabelas de definição;
- armazenar na(s) tabela(s) de definição e/ou na(s) tabela(s) decondição um ou mais indicador(es), tais como, por exemplo, ">", "<", "=>","=<", "=", etc, que indicam a natureza matemática de uma ou mais regras;
- ler, por exemplo, usando um criador, a partir da(s) tabela(s) dedefinição e/ou tabela(s) de condição uma ou mais regras e/ou um ou maisindicadores);
- proporcionar, por exemplo, usando o dito criador, em uma oumais tabela(s) de código na linguagem legível por máquina;
- gerar, por exemplo, usando o dito criador, um ou mais arquivosexecutáveis interrelacionados a partir do dito código legível por máquina. Épossível que a partir de cada tabela de código um arquivo executável sejagerado. Também é possível que a partir de uma tabela de código dois oumais arquivos executáveis sejam gerados.
De maneira exemplificativa, selecionar e associar duas ou maisseções de código legível por máquina na linguagem de máquina compreen-de lançar regras no texto claro usando a dita interface gráfica de usuário eproporcionando, por exemplo, usando o dito criador, o código legível por má-quina na linguagem de máquina equivalente ao dito texto claro que usa umgerador.
O termo "equivalente" no contexto do presente pedido compre-ende, por exemplo, que uma regra, condição matemática, etc, é lançada notexto claro (que pode ser facilmente entendido pelo usuário que não é versa-do na programação em uma linguagem de programação) e é, então, trans-formado na linguagem legível por máquina que pode ser interpretado, porexemplo, por um computador.
De maneira exemplificativa, a etapa de a verificação implemen-tada por computador da coerência compreende uma verificação implementa-da por computador da compatibilidade da primeira seção do código usadopara gerar um primeiro arquivo executável com uma segunda seção de códi-go usada para gerar um segundo arquivo executável.
Em outras palavras, de maneira vantajosa, é facilmente possívelexaminar, se dois arquivos executáveis estarão trabalhando juntos de manei-ra adequada, isto é, se a interrelação dos ditos dois arquivos executáveis forcorreta, sem a necessidade de o usuário ser versado na técnica de progra-mação específicas no código legível por máquina na linguagem de máquina.
De maneira exemplificativa, a etapa de verificação implementadapor computador da coerência compreende:
- baseado no código legível por máquina selecionado que avaliano lado do cliente os parâmetros de tempo de execução antes de compilaras seções selecionadas do código legível por máquina, em que os parâme-tros de tempo de execução são associados aos arquivos executáveis, quan-do executam os arquivos executáveis no lado de servidor.
Em outras palavras, analisando-se o código legível por máquinaselecionado, em particular, analisando-se a associação entre o código legívelpor máquina selecionado que usa, por exemplo, lógica de linguagem de pro-grama e/ou lógica matemática, os parâmetros de tempo de execução podemser avaliados antes sem compilar as seções selecionadas do código legívelpor máquina. Os parâmetros de tempo de execução podem ser variá-veis/parâmetros usados por ou no(s) arquivo(s) executável(eis) no lado deservidor. No caso de os ditos parâmetros de tempo de execução serem in-compatíveis com o sistema, em particular, incompatíveis com as configura-ções de hardware no lado de servidor, uma respectiva mensagem pode sergerada de maneira automática e computadorizada. Portanto, mesmo sem serversado na técnica de programação específicas, o usuário pode verificar deuma maneira simples se o código legível por máquina selecionado irá atuarde maneira realizar de adequada no lado de servidor.
Como exemplos, a etapa de verificação implementada por com-putador da coerência pode compreender:
- Quando em uma lógica condicional (também referido como va-lidação) um elemento definido como numérico é comparado com um elemen-to alfanumérico, proporciona-se uma mensagem de erro que informa sobreuma incompatibilidade.
- Quando um formato de um ou mais cálculos não for correspon-dente/compatível com o formato de seus operandos, proporciona-se umamensagem de erro. De maneira exemplificativa, pode-se proporcionar umamensagem de erro quando a operação X for definida como Dec(6,2), isto é,uma variável que tem 6 entradas e 2 decimais e sua operação é o resultadoda operação para resumir as variáveis Y e Z, onde Y é definido comoDec(15,2) e Z como Dec(15,2). Em outras palavras, o resultado desta soma"Y+Z" pode não se encaixar no elemento definido em X como "X = Y + Z".
De maneira exemplificativa, uma ou mais seções de código legí-vel por máquina são reutilizadas para compilar os dois ou mais arquivos exe-cutáveis interrelacionados.
Em outras palavras, as seções similares ou idênticas do códigolegível por máquina podem ser usadas para a compilação. A seleção dasseções de código legível por máquina pode, portanto, compreender a cópiadas ditas seções. Entretanto, mesmo que as seções similares ou idênticasdo código legível por máquina sejam usadas para compilar os diferentes ar-quivos executáveis, os ditos arquivos podem atua de maneira diferente, porexemplo, no caso de variáveis/parâmetros serem ajustadas de maneira dife-rente.
Em outras palavras, podem-se proporcionar grupamentos de có-digo legível por máquina, em que os ditos grupamentos podem ser unidos aousar a GUI a fim de proporcionar um conjunto de grupamentos que pode sercompilado em um arquivo executável no lado de servidor. O dito conjunto degrupamentos pode compreender seções similares, particularmente idênticasao código legível por máquina. Os grupamentos também podem compreen-der diferentes conjuntos de código legível por máquina. Em outras palavras,a GUI pode ser usada para construir o código legível por máquina para com-pilar dois ou mais arquivos executáveis, em que o código legível por máquinapara cada arquivo executável pode ser composto similar a um kit de constru-ção, em que o usuário usa o texto claro proporcionado e lançado pela GUI.
De maneira exemplificativa, pelo menos um arquivo executávelem primeiro nível compilado que é interrelacionado com pelo menos um ar-quivo executável em nível i, em que pelo menos um arquivo executável emnível i é interrelacionado com pelo menos um arquivo executável em nível(i+1), em que i é um número natural maior que 1.
De maneira exemplificativa, pelo menos um arquivo executávelem nível i e pelo menos um arquivo executável em nível (i+1) são compila-dos a partir de uma ou mais seções de um código legível por máquina, emque uma ou mais seções de código legível por máquina compreendem códi-go legível por máquina similar, de preferência, substancialmente idêntico.
Em outras palavras, um conjunto hierárquico de arquivos execu-táveis pode ser criado, em que os arquivos executáveis podem ser associa-dos aos arquivos executáveis que, novamente podem ser associados aosarquivos executáveis adicionais. Os conjuntos diferentes de arquivos execu-táveis pode ser criado, em que cada conjunto pode ter a dita estrutura deárvore/hierárquica. Cada nível pode ter um ou mais arquivos executáveis.Cada nível pode compreender arquivos executáveis, que podem ser simila-res, mesmo idênticos a um ou mais níveis de arquivo executável superioresna hierarquia de um ou mais níveis inferiores na hierarquia. Os arquivos exe-cutáveis em um nível podem ser interrelacionados. Um ou mais arquivos e-xecutáveis em um nível podem ser interrelacionados a um ou mais arquivosexecutáveis em um ou mais níveis hierárquicos mais altos e/ou um ou maisníveis hierárquicos mais baixos. Os conjuntos diferentes de arquivos execu-táveis podem ter estrutura hierárquica similar, mesmo idêntica. Os diferentesconjuntos de arquivos executáveis podem ter diferentes estruturas hierárqui-cas. O valor de i pode ser 2, 3, 4, 5, 6, 7, 8, 9, 10, etc.
De maneira exemplificativa, o método compreende a etapa adi-cional de verificar a integridade da execução de todos os arquivos executá-veis ao executar todos os arquivos executáveis no lado de servidor e compa-rar o desempenho no lado de servidor com uma especificação predetermina-da no lado de cliente.
O desempenho no lado de servidor pode ser computadorizado,comparado com uma especificação predeterminada no lado de cliente. Comoum exemplo, uma ou mais saídas dos arquivos executáveis no lado de servi-dor podem ser comparadas com um conjunto de variáveis/parâmetros nolado de cliente.
De maneira exemplificativa, as etapas no lado de cliente são rea-lizadas no computador de cliente remoto a partir do servidor e as etapas nolado de servidor são realizadas no computador servidor remoto a partir docliente.
Em outras palavras, as etapas no lado de cliente são realizadasem um computador de cliente que pode ser um computador em uma rede. Ocomputador de cliente pode ser conectado a um computador servidor atravésda rede. Após realizar as etapas no computador de cliente, em particular,mediante a aprovação da coerência, as duas ou mais seções selecionadas eassociadas a um código legível por máquina podem ser transferidas para olado de servidor, em particular, para um computador servidor, por exemplo,através da dita rede. As duas ou mais seções de código legível por máquinaselecionadas e associadas também podem ser transferidas para o servidoratravés de quaisquer outros meios, tal como, ao armazenar as duas ou maisseções de código legível por máquina selecionadas e associadas em umdispositivo de armazenamento, tal como, um CD, um flash drive, um discorígido, etc, e copiar as ditas duas ou mais seções de código legível por má-quina selecionadas e associadas a partir do dito dispositivo de armazena-mento no servidor. Então, no servidor, as duas ou mais seções de códigolegível por máquina selecionadas e associadas podem ser compiladas.
O dispositivo de armazenamento também pode ser parte de umcomputador intermediário, que é conectado ao computador de cliente e aocomputador servidor. Em outras palavras, as duas ou mais seções de códigolegível por máquina selecionadas podem ser transferidas a partir do compu-tador de cliente para o computador servidor através de outro computador ououtro dispositivo computadorizado, tal como, um dispositivo móvel, para o servidor.
De maneira alternativa, todas as etapas no lado de cliente e asetapas no lado de servidor podem ser realizadas em um computador, queincorpora o servidor e o cliente.
Além do que foi dito acima, o presente pedido pode descrevertambém um sistema computadorizado para gerar arquivos de computadorexecutáveis interrelacionados em um lado de servidor que compreende:
- uma interface gráfica de usuário em um lado de cliente, em que
- a interface gráfica de usuário é associada ao código legível por máquina,
- a interface gráfica de usuário exibe dados substancialmente em texto claro
- a interface gráfica de usuário é adaptada para selecionar duasou mais seções de código legível por máquina em um lado de cliente;
- um verificador de coerência que é adaptado para
- verificar uma coerência do dito código legível por máquina se-lecionado no lado de cliente e
- produzir o resultado da dita verificação de coerência substanci-almente em texto claro; e
- um compilado para compilar as duas ou mais seções de códigolegível por máquina selecionadas em um lado de servidor para criar e/ou a-daptar e/ou modificar dois ou mais arquivos executáveis interrelacionadosque são executáveis pelo servidor.
Para selecionar duas ou mais seções de código legível por má-quina em um lado de cliente, a GUI pode ser conectada um seletor. O seletorpode compreender uma ou mais ligações específicas que apontam para asseções de código na linguagem legível por máquina. Em outras palavras, oseletor pode ser adaptado para selecionar duas ou mais seções de código,mediante a entrada do usuário através da GUI, deste modo, o usuário podese comunicar com a GUI em texto claro na linguagem legível por humano e aGUI, através do seletor pode selecionar as duas ou mais seções de códigoque representam o texto claro no código legível por máquina. No contexto dopresente pedido, o texto claro também pode compreender que os campos deexibição de GUI, em particular, botões e/ou outros tipos de menus, que sãoconstruídos, de modo que o usuário possa entender de maneira intuitiva osignificado dos ditos campos e/ou botões e/ou outros tipos de menus. Comoum simples exemplo, a fim de criar uma validação, o menu pode compreen-der botões que têm representados nos mesmos operadores matemáticos,tais como,">", "<", "=", que o usuário pode entender para representar as ope-rações em uma validação de "maior", "menor" e "igual a".
Devido às seções de termo de código, os detalhes acima sãorealizados devido ao método ser igualmente aplicável.
De maneira exemplificativa, a interface gráfica de usuário com-preende um gerador que é adaptado para proporcionar o código legível pormáquina na linguagem de máquina equivalente ao dito texto claro como en-trada através da interface gráfica de usuário.
De maneira exemplificativa, o sistema computadorizado podecompreender um avaliador que é adaptado para avaliar no lado de clientebaseado no código legível por máquina selecionado os parâmetros de tempode execução antes de compilar as seções selecionadas do código legível pormáquina, em que os parâmetros de tempo de execução são associados aosarquivos executáveis quando executam os arquivos executáveis no lado deservidor.
Além do que foi dito acima, o presente pedido pode tambémdescrever um produto de programa de computador, armazenado em um dis-positivo de armazenamento de dados ou proporcionado como sinal, quequando carregado na memória de um computador e executado pelo compu-tador faz com que o computador realize um método conforme descrito acima.
A descrição precedente dos aspectos não se limita aos respecti-vos aspectos. De preferência, a descrição dos respectivos aspectos pode seraplicada nos aspectos restantes. Em particular, a descrição que refere-se aométodo pode ser aplicada no sistema de computador e no produto de pro-grama de computador e nas respectivas modalidades específicas, conse-quentemente, de modo que ao combinar os recursos individuais dos aspec-tos ou modalidades específicas, novos aspectos e/ou modalidades possamser criados. Além disso, os aspectos e/ou modalidades descritos acima nãosão restritos a uma aplicação, tal como, a geração de arquivos de computa-dor executáveis interrelacionados que podem ser produtos de seguro ou serrelacionados a produtos de seguro e/ou relacionados às aplicações de ge-renciamento de reivindicação de seguro e/ou relacionados à geração de do-cumentos de seguro e/ou relacionados à geração de produtos adicionais, taiscomo, produtos de bens imobiliários, produtos e/ou documentos de serviçofinanceiro em um ou mais dos campos mencionados acima.
Descrição das figuras
Os seguintes exemplos específicos são descritos por meio defiguras exemplificativas, em que os recursos individuais das figuras podemser combinados com os exemplos adicionais, não explicitamente estabeleci-dos na descrição das figuras. Com referência às figuras, mostrou-se na:
a figura 1a é visão geral esquemática de configurações exempli-ficativas das seções de código legível por máquina;
a figura 1 b é uma visão geral esquemática;
figura 1c é uma captura de tela de uma GUI;
figura 2 é uma visão geral detalhada esquemática de um ele-mento, de acordo com a figura 1a;realce;
realce;realce;realce;
a figura 3 é uma captura de tela de uma GUI que compreende
a figura 4 é uma captura de tela que compreende realce;a figura 5a é uma captura de tela que compreende realce;a figura 5b é uma captura de tela que compreende realce;a figura 6 é uma captura de tela que compreende realce;a figura 7a é uma captura de tela de uma GUI que compreende
a figura 7b é uma captura de tela de uma GUI que compreende
a figura 8a é uma captura de tela de uma GUI que compreende
a figura 8b é uma a captura de tela de uma GUI que compreenderealce;
a figura 9 é uma captura de tela que compreende realce;
a figura 10a é uma captura de tela que compreende realce;
a figura 10b é uma captura de tela que compreende realce;
a figura 11a é uma captura de tela que compreende realce;
a figura 11 b é uma captura de tela que compreende realce;
a figura 12a é uma captura de tela que compreende realce;
a figura 12b é uma captura de tela que compreende realce;
a figura 12c é uma captura de tela que compreende realce;
a figura 12d é uma captura de tela que compreende realce
a figura 13: a visão geral esquemática de um elemento, de acor-do com figura 1a;
a figura 14a é uma captura de tela de uma GUI que compreenderealce;
a figura 14b é uma captura de tela de uma GUI que compreenderealce;
a figura 14c é uma captura de tela de uma GUI;
a figura 14d é uma captura de tela de uma GUI;
a figura 15 é uma captura de tela que compreende realce;a figura 16a é uma captura de tela que compreende realce;
a figura 16b é uma captura de tela que compreende realce;
a figura 17a é uma captura de tela que compreende realce;
a figura 17b é uma captura de tela que compreende realce;
a figura 18a é uma captura de tela que compreende realce;
a figura 18b é uma captura de tela;
a figura 18c é uma captura de tela que compreende realce;
a figura 19 é uma visão geral esquemática de um elemento deacordo com figura 1a;
a figura 20a é uma captura de tela;
a figura 20b é uma captura de tela;
a figura 20c é uma captura de tela;
a figura 21a é uma captura de tela;
a figura 21 b é uma captura de tela;
a figura 22 é uma captura de tela;
a figura 23 é uma visão geral esquemática que mostra a execu-ção de dois ou mais arquivos executáveis interrelacionados;
a figura 24 é um fluxograma;
a figura 25 é uma captura de tela de uma GUI;
a figura 26 é uma captura de tela de uma GUI;
a figura 27a é uma captura de tela de uma GUI;
a figura 27b é uma captura de tela de uma GUI;
a figura 27c é uma captura de tela de uma GUI;
a figura 28 é uma captura de tela de uma GUI;
a figura 29 é uma captura de tela de uma GUI;
a figura 30 é um fluxograma;
a figura 31 é uma visão geral;
a figura 32 é uma visão geral;
a figura 33 é uma visão geral;
a figura 34 é uma visão geral;
a figura 35 é uma visão geral;
a figura 36 é uma visão geral ea figura 37 é um sistema baseado em computador.
Os exemplos específicos do método e do sistema descritos aseguir também podem ser referidos como "Fábrica de Produto Info2000" ou"módulo de Fábrica de Produto Info2000" ou "Administração de apólice". Demaneira vantajosa, o módulo de Fábrica de Produto Info2000 proporcionauma metodologia de desenvolvimento comum para todas as Linhas de Ne-gócio, em que substancialmente todos os produtos isto é, dois ou mais ar-quivos executáveis interrelacionados são criados, suportados e manipuladosdo mesmo modo, usando as mesmas telas e um dicionário de dados comumpara o armazenamento de dados. De maneira adicionalmente vantajosa, omesmo também permite uma reutilização de componente de produto exten-siva, tal como, a reutilização de seções de código na linguagem legível pormáquina. No contexto deste pedido, o termo "reutilizar" significa particular-mente que uma seção de código específica pode ser copiada uma ou maisvezes, para utilização em uma ou mais composições de código que são, en-tão, usadas para criar dois ou mais arquivos executáveis interrelacionados.Em outras palavras, o termo "selecionar", no contexto deste pedido, significaque a seção de código selecionada é copiada para criar dois ou mais arqui-vos executáveis interrelacionados. Em particular, o termo "selecionar e asso-ciar", no contexto do presente pedido pode significar que o código é copiadonas tabelas. De maneira vantajosa, a "Administração de Apólice" pode per-mitir a criação e/ou manutenção de dados de apólice e/ou apólices específi-cas de uma maneira simples e intuitiva. Em particular, um sistema comumpode ser facilmente adaptado, enquanto a interface de "Administração deApólice" se mantém substancialmente idêntica.
Uma vez que o Produto é definido, isto é, uma vez que todas asseções de código legível por máquina foram selecionadas e associadas,possivelmente, todos os parâmetros/variáveis necessários também foramajustados, a Fábrica de Produto irá gerar um Programa executável que com-preende dois ou mais arquivos executáveis interrelacionados, chamados deinterfaces Administração de Apólice padrões.
1. Estrutura de produtoA figura 1a proporciona um diagrama que mostra a estrutura deproduto básica definida na Fábrica de Produto. Em outras palavras, a figura1a mostra uma visão geral da funcionalidade dos dois ou mais arquivos exe-cutáveis interrelacionados, uma vez que eles são executados no lado de ser-vidor.
O criador do produto irá definir os diferentes componentes quesão necessários para construir o Produto, tais como,
- Objetos segurados (por exemplo, carro, casa)
- Coberturas (por exemplo, construção)
- Códigos de avaliação (para reivindicações; por exemplo, fogo)Estes componentes podem ser reutilizados entre os produtos.
Portanto, o criador do produto pode selecionar os componentes que usamuma GUI, em que na GUI os componentes que são disponíveis usam textoclaro, de preferência, pelo fato de que a GUI compreende os respectivos bo-tões, tais como, por exemplo, um botão para "objetos segurados", que po-dem proporcionar, por exemplo, uma lista suspensa de possíveis escolhasque, então, podem ser selecionadas, por exemplo, simplesmente através dorealce que usa um dispositivo apontador como um mouse ou algo equivalen-te. Estes botões são associados ao respectivo código legível por máquina nalinguagem de máquina.
Os elementos também podem ser definidos e designados no ní-vel adequado (por exemplo, ano de construção). Os elementos podem serusados para capturar dados ou ajustar regras. Os elementos podem ser sim-ples campos de entrada ou relacionados a um conjunto de valores de refe-rência que podem ser mantidos ou armazenados em uma tabela de corpora-ção.
Como um exemplo, na figura 1a, o produto a ser criado refere-seao seguro de "propriedade de conforto domiciliar". Em outras palavras, osarquivos executáveis interrelacionados irão proporcionar, quando executadosno lado de servidor, como um resultado de documentos de seguro, tal comoum contrato de um seguro de uma casa. O método, de acordo com o presen-te pedido, permite a geração computadorizada de dois ou mais arquivos e-xecutáveis interrelacionados que, quando executados, criam ou auxiliamquando cria os ditos documentos de seguro.
Em outras palavras, a figura 1a mostra um ou mais dos seguin-tes componentes:
- O produto refere-se a duas entidades:
- Produto Técnico: O mesmo contém as especificações técnicas.
É a estrutura de referência que é usada para criar os produtos comerciaisque são realmente distribuídos.
- Produtos Comerciais: Baseados nos produtos técnicos e limita-dos a sua área de aplicação. Eles podem apresentar restrições que limitamalgumas das características do produto técnico. Cada apólice usada no mé-todo/sistema descrito no presente pedido é claramente ligada a um únicoproduto técnico-comercial.
O tipo de objeto refere-se ao risco ou riscos específicos cobertospelo produto. O método, de acordo com este pedido, permite que os produ-tos sejam:
- Múltiplos objetos: que contêm diferentes tipos de necessidadesde seguro (pessoa, automóvel, casa, etc);
- Múltiplas situações: a fim de repetir o mesmo tipo de objetoquantas vezes requeridas em uma apólice. Isto permite, por exemplo, o ge-renciamento de apólices coletivas, de acordo com o presente pedido.
Classe Prêmio: identifica o risco segurável (garantia) para a ava-liação de um prêmio. As características importantes das classes prêmio, deacordo com o presente pedido são:
- Elas são o nível mínimo da estrutura de produto para o qual osresultados econômicos são calculados (prêmios, taxas, descontos, etc.)
- Um tipo de objeto (ou necessidade de seguro) pode ser associ-ado a muitas classes prêmio, conforme desejado. A mesma classe pode serdesignada a diferentes tipos de objetos.
- As classes prêmio podem ser agrupadas em Pacotes (ou Segu-ros) por razões de comercialização e vendas (por exemplo, "Full omnium").
- O código de avaliação é usado para classificar as reservas parauma reivindicação. Uma classe prêmio pode ter tantos códigos de avaliaçãoquanto requeridos, e um mesmo código de Avaliação pode ser designado adiferentes classes Prêmio.
- Os elementos podem ser unidades de informação que identifi-cam as características dos componentes do produto. Por exemplo, no caso
da Pessoa objeto segurado, os elementos podem incluir gênero, idade, pro-fissão, etc. No caso de classe Prêmio para seguro de vida ou seguro de in-cêndio, a soma segurada, etc. pode ser considerada.
Existem os seguintes tipos de elementos:
- Elementos internos: Eles são comuns a todos os produtos, po-
dem ser modificados pelos usuários da Fábrica de Produto e são transparen-tes para usuários finais (por exemplo, concessão para reintegrar as apólicesdaquele produto).
- Elementos essenciais: Eles são comuns a todos os produtos,podem ser modificados pelos usuários da Fábrica de Produto e são exibidos
nas telas de administração de Apólice screens, tal como, a GUI mostradanas figuras 28 e 29, uma vez que o usuário final precisa lançar/confirmar ovalor selecionado (por exemplo, freqüência de pagamento).
- Elementos adicionais: específicos a cada produto, podem sermodificados pelos usuários da Fábrica de Produto e são exibidos nas telas
de Administração de Apólice, tal como, a GUI mostrada na figuras 28 e 29uma vez que o usuário final precisa lançar/confirmar o valor selecionado (porexemplo, uma placa de veículo segurado)
O método implementado por computador permite particularmenteque uma pessoa não versada na técnica de programação para configurar ocódigo fonte de uma maneira simples e eficiente, de modo que os ditos doisou mais arquivos executáveis interrelacionados possam ser criados no ladode servidor e possam ser executados no lado de servidor.
Em particular, os arquivos executáveis, quando executados, pro-porcionam um meio para criar documentos individualmente ao permitir o a-juste através de uma GUI de todas as variáveis/parâmetros, limites, condi-ções, circunstâncias, elementos necessários, etc.De acordo com figura 1a, para o produto geral, assim como paracada componente do produto, o criador pode escolher um ou mais elemen-tos, validações, operações e textos/parágrafos. De maneira exemplificativa, oobjeto do produto "propriedade de conforto domiciliar" pode ser uma "casa".Adicionalmente, os objetos adicionais podem ser introduzidos, tal como, porexemplo, "apartamento".
Além disso, uma cobertura que é selecionada pode ser "constru-ção". Adicionalmente, "conteúdos" de coberturas, "furto" e "auxílios moradia"são selecionados no exemplo de acordo com a figura 1a. Para a coberturade "construção", os códigos de avaliação "fogo", "explosão", "inundação","relâmpago" e "terremoto" e o elemento "ano de construção" são seleciona-dos.
2. Módulos de Fábrica de Produto
A Fábrica de Produto Info2000 compreende quatro módulos bá-sicos, ou seja, definições de produto, validações, regras de classificação etexto/parágrafos. Além dos quatro módulos básicos, módulos adicionais po-dem ser integrados. Uma visão geral exemplificativa dos módulos e sua rela-ção é mostrada na figura 1 b.Definição de Produto
Este módulo permite que o criador do produto configure a defini-ção de produto, conforme descrito acima com relação à figura 1a. Toda ainformação que refere-se à definição de produto é armazenada no modelo dedados de Fábrica de Produto, junto com a informação lançada nos próximosmódulos.
Em outras palavras, o objetivo deste módulo é definir a estruturade produto e permitir a entrada de dados de produto e seus diferentes ele-mentos constituintes (objetos, classes Prêmio, códigos de Avaliação, e ele-mentos):
- Tipo de objeto das características de múltiplas situações e/ou
- Classes prêmio designadas a cada tipo de objeto e/ou
- Códigos de avaliação designados a cada tipo de classe prêmio
e/ou- Elementos requeridos para cada componente da estrutura deproduto:
Definição de componentes (nome, descrição, tipo e tamanho) aousar um dicionário comum para todos os produtos e/ou
Designação de elementos aos componentes de produto e/ou
Relação com os componentes de produto (valores, visibilidade,capacidade de modificação possíveis e padrões, etc).
Um ou mais dos seguintes elementos - relacionados à definiçãode produto - podem ser adicionados:
Agrupamentos - todos os componentes de Fábrica de Produtopodem ser agrupados (produto, objeto, classe prêmio, código de avaliação,elemento). Um tratamento definido mostra o objetivo de agrupamento (porexemplo, resseguro).
Modalidades - criadas para classes prêmio e que permitem aseleção de elementos da classe prêmio original a ser incluída na modalida-de. As características de elementos descritos (valor padrão, mínimo, máxi-mo) são especificadas ao estabelecer a relação entre as classe prêmio e amodalidade.
Opções - A definição de opções tem um duplo propósito: facilitara subscrição e estabelecer as modalidades/classes prêmio predefinidas. Asopções são criadas no nível de objeto.
Validações
Este módulo permite que o criador do produto configure as re-gras a serem executadas e validadas durante o ciclo de vida do produto naadministração de apólice, isto é, quando executa dois ou mais arquivos exe-cutáveis interrelacionados a fim de produzir, por exemplo, um documento deseguro. Uma possível validação pode ser definida, por exemplo, para validarse um motorista é maior de 18 anos, quando executa dois ou mais arquivosexecutáveis, em que uma variável é a idade de um motorista. A Fábrica deProduto permite a definição de variáveis/parâmetros, tal como a idade,quando define uma validação que será realizada durante o tempo de execu-ção dos dois ou mais arquivos executáveis interrelacionados (isto é, duranteo tempo de execução do produto). Estas validações, como quaisquer outroscomponentes de produto são reutilizáveis entre os produtos. Em outras pala-vras, a validação serve para verificar se a idade de um motorista, como umavariável exemplificativa, usada quando define, por exemplo, que um objetodo produto é maior que um dado valor limítrofe. A dita validação também po-de ser usada, quando define um objeto diferente do produto e/ou a coberturae/ou o próprio produto.
Em outras palavras, o objetivo deste módulo é permitir a introdu-ção de validações necessárias associadas a um produto (técnicas ou comer-ciais).
Uma validação é composta por uma ou algumas condições lógi-cas, unidas por meio de operadores Booleanos, onde cada condição lógica éfeita de operando(s) e um operador de lógica. O resultado da validação éVERDADEIRO ou FALSO.
Um ou mais dos seguintes componentes podem ser encontradosem uma validação:
Nome e descrição de uma ou mais validações.
Operandos, tais como, valores elemento, resultados de opera-ção, acesso às tabelas de corporação, etc.
Os operadores de comparação (maior que, menor que, igual),compatibilidade, compulsórios, etc.
Conectores lógicos para validações que podem compreender Ee/ou OU.
Sentido de validação que pode compreender Verdadeiro e/ouFalso.
Similares aos elementos, as validações devem ser associadasao produto, objeto, classe prêmio, etc, uma vez que elas são definidas. Umavez que uma validação é definida, a mesma pode ser reutilizada em outroscomponentes de um produto ou em diferentes produtos.
Um exemplo de uma validação é mostrado na captura de telaincluída na figura 1c, que mostra uma GUI exemplificativa. Neste exemplo(no pseudocódigo):SE
o Comercio for Escavação (10030)OU
Revestimento de Estrada (10028)E
As atividade incluem bombeamento/despejo de concretoENTÃO ... (resultado de validação)
Consequentemente, usando o método de acordo com este pedi-do, um criador do produto pode desenvolver isto sem uma única linha de có-digo ser escrita. Deste modo, de maneira vantajosa, o projeto técnico, codifi-cação e/ou teste de unidade pode ser eliminado do ciclo de vida de desen-volvimento de produto.
A figura 2 mostra uma visão geral sobre as possíveis configura-ções das validações. Em particular, a figura 2 mostra a possível configuraçãode cada validação, que usa condições lógicas N, onde N pode ser um núme-ro natural, em particular, 2, 3, 4, 5, 6, 8, 10, 15, 20, etc. Além disso, mostra-se de maneira exemplificativa na figura 2 os possíveis componentes de cadacondição. Cada uma das condições lógicas N pode compreender operandosM, onde M pode ser um número natural, em particular, 2, 3, 4, 5, 6, 8, 10, 15,20, etc. Além disso, para cada condição lógica, os M operandos lógicos po-dem ser conectados através de um dos operadores de lógica. Consequen-temente, proporciona-se para cada condição lógica operadores de lógica M-1. Os operandos lógicos podem compreender um ou mais: Elementos, Aces-sos, Operações, funções predefinidas, tipo de objeto, Classe prêmio, cons-tante Numérica, constante Alfanumérica, Rotina, etc. O operador de lógicapode compreender um ou mais: EQ=igual, NE=não igual, GT=maior que,GE=maior que ou igual a, LT=menor que, LE=menor ou igual a,TC=cobertura contraída, TNC=cobertura não contraída, Tl= cobertura in-compatível, TD=cobertura que depende de, etc.
As condições lógicas N podem ser conectadas a um operadorBooleano, tal como "E", "OU","(",")", etc.
Também na figura 2, mostra-se um exemplo adicional de umapossível validação, ou seja, para verificar, se a idade de uma pessoa a quemos documentos de seguro são criados tem uma idade superior a 100 anos.Se a dita validação descobrir que a idade, como um parâmetro preferido, formaior que 100 anos, uma ação específica é realizada, por exemplo, cobran-ças mensais de 7,50 EUROS serão cobradas.
O módulo "Validações" pode ser acessado quando usar o siste-ma de acordo com o presente pedido, seguindo ao caminho Sistema>Prod.Conf. Validações. A partir daqui, novas validações podem ser adicionadas,modificadas ou apagadas.
A figura 3 mostra a captura de tela de uma interface gráfica deusuário exemplificativa (GUI) do sistema baseado em computador de acordocom o presente pedido, quando adiciona ou modifica uma validação, que foicriada para propósitos de ilustração. Em outras palavras, a captura de tela,de acordo com figura 3, mostra uma validação que estabelece basicamenteque a validação deve ocorrer se a soma dos conteúdos exceder a figura em2.500.000. A parte superior desta captura de tela pode conter o nome, des-crição, data e operadores. O retângulo realçado é o lugar em que a validaçãoreal é exibida. Este módulo será usado para validar os dados de apólice co-mo um acionador de um cálculo dentro de uma operação ou como um acio-nador de parágrafos. Se esta validação não ocorrer, então, a mesma irá lan-çar uma mensagem de erro. Em outras palavras, a figura 3 mostra uma GUI1 que exibe texto claro, em particular, que tem, por exemplo, campos 2a, 2b,4a, 4b, etc, para lançar texto, em que o usuário pode selecionar operadoresespecíficos. Esta seleção através da GUI é associada ao código legível pormáquina na linguagem de máquina. Além disso, o usuário pode especificarvariáveis e/ou parâmetros que são submetidos, por exemplo, aos operado-res. Através da GUI, as variáveis e/ou parâmetros são ajustados na lingua-gem legível por máquina. Na figura 3, uma condição é exibida em texto claro.Em particular, os campos 2a, 2b, são usados para lançar um período detempo durante o qual a validação é aplicável. Como um exemplo, a data deinício lançada através do campo 2a é escolhida na figura 3 como 01 de janei-ro de 1900 e a data final lançada através do campo 2b é 31 de dezembro de9999. Durante este tempo, a validação será realizada, quando dois ou maisarquivos executáveis interrelacionados forem executados.
O nome e uma curta descrição da validação são lançados usan-do os campos 4a, 4b, em que os ditos campos são usados para descreverbrevemente a validação e, deste modo, permitir uma simples identificação davalidação, por exemplo, na tabela de definição, conforme mostrado na figura4 (vide abaixo). Adicionalmente, a GUI 1 de acordo com a figura 3 contém oscampos 6a, 6b para lançar os operandos que definem a validação, assimcomo, o operador no campo 8. A validação, assim, configurada e definida émostrada na GUI 1, na janela 10, em que a linha que define a validação foirealçada por uma caixa 12 (não mostrada, quando exibe a GUI) para umafácil visibilidade. A GUI 1 compreende a definição uma operação que é cha-mada de OP_DEFAULT_8 e usa os CONTEÚDOS de SOMA de validação 4
> LIM como um acionador de cálculo 01 e 05 que significa que o cálculo serárealizado dependendo do resultado desta validação. Então, no cálculo, de-pendendo do resultado, C1 ou C2 podem ser acionados. C3 é sempre acio-nado. Além disso, a descrição acima mantém, onde aplicável, a similaridadedas GUIs, conforme mostrado nas outras figuras.
Como um exemplo, todas as validações são armazenadas natabela KTPM34T. Em outras palavras, a tabela KTPM34T é uma tabela dedefinições exemplificativa. A figura 4 mostra uma captura de tela que com-preende a definição da validação, conforme selecionada com a GUI de acor-do com a figura 3. As linhas realçadas com uma caixa (não mostrada quandoexibe a GUI) são as que contêm o código exclusivo da validação, neste e-xemplo, "0000006619", datas válidas, neste exemplo, de "19000101" a"99991231" que foram lançadas através dos campos 12a, 12b da GUI 1 e dadefinição da validação. Também, nas figuras a seguir, as caixas usadas pararealçar normalmente não são exibidas pela GUI do sistema computadoriza-do.
A validação será executada apenas se a soma dos conteúdos for> 2.500.000. Estes valores sem os quais a validação não irá disparar sãoarmazenados na tabela KTPA78T. Em outras palavras, a tabela KTPA78T éuma tabela de condições exemplificativas. As figuras 5a e 5b, que são duascapturas de tela, realçam a condição definida com a GUI 1 de acordo com afigura 3 e também com os ditos valores anteriormente mencionados. As cap-turas de tela mostram duas linhas separadas como R1 e R2 que não podemse adequar apenas a uma captura de tela, de modo que elas sejam exibidasnas figuras 5a e 5b.
Portanto, os conteúdos são lidos a partir da tabela anterior KT-PA78T, um excerto desta é mostrado nas figuras 5a e 5b, de modo que se asoma for maior que 2.500.000, então, o programa é executado. Isto é querepresenta o conteúdo da validação.
Em outras palavras, através da GUI 1 mostrada na figura 3, asdefinições da validação são criadas em uma ou mais tabelas, no presenteexemplo, entradas são criadas nas tabelas mostradas nas figuras 4, 5a e 5b,em que em uma tabela de definição (figura 4), a definição da validação, emgeral, é proporcionada e em outra tabela, isto é, na tabela de condição (figu-ras 5a e 5b) a própria condição e os valores de variáveis/parâmetros usadospela validação são definidos.
Um gerador sob encomenda (fonte COBOL KTPLP007), a fim degerar automaticamente o código em copybooks irá acessar esta tabela KT-PA78T, conforme mostrado nas figuras 5a, 5b e realizar as seguintes instru-ções representadas em pseudocodigos. A seguinte lógica em pseudocodigosrepresenta o meio no qual o programa opera e se converte em fonte COBOLque é configurada nas tabelas mencionadas:
Etapa 1: Ler o primeiro registro a partir de KTPA78T (R1) eEtapa 2: RealizarEtapa 2.1: Escrever nova linha com a informação de KTPA78TEtapa 2.2: Ler o próximo registro a partir de KTPA78TAté o final de KTPA78T.Etapa 3: Escrever novas "Linhas Finais".
O processo de acordo com as subetapas 2.1 e 2.2 é iterati-vo/repetido, isto é, o dito processo termina quando o mesmo alcança o fimdas fileiras. No presente exemplo, de acordo com as figuras 3, 4, 5a e 5bduas iterações serão realizadas.
Referindo-se à natureza matemática das regras inseridas emKTPA78T, os ditos componentes tabela são definidos na validação e/ou ope-ração.
De maneira exemplificativa, conforme mostrado nas figuras 5a e5b, uma nova regra codificada por 000000619 que é criada consiste em umaLÓGICA CONDICIONAL (portanto, uma validação), através de valor "CL" nocampo TCTCP78T que é o primeiro operando (campo CDORD78T com valor"01") e o operando 0000006178 (campo CDCCH78T que é uma função pre-definida) deve ser maior (campo TCOBH78T com valor ">") que o segundooperando (segunda fileira na figura 5a) que é numérico (campo TCTCH78Tcom valor N) e seu valor é 2.500.000.
Então, aqui, a natureza matemática desta regra codificada é ocampo TCOBH78T com o valor ">", onde o código legível por máquina defineque o valor derivados de variáveis 0000006178 deve ser comparado com umvalor fixo, isto é, 2.500.000.
Possíveis indicadores podem ser ">", "<", "=>", "=<", "=", etc.O gerador feito sob encomenda é projetado e adaptado para re-conhecer condições específicas. Como um exemplo, a tabela KTPA78Tcompreende no campo TCTCP78T, o valor "CL" que significa Lógica deCondição e é igual à operação "IF". Em outras palavras, de maneira exempli-ficativa, na(s) tabela(s) um ou mais parâmetros que podem ser armazenadoscompreendem informação sobre condições lógicas. O gerador feito sob en-comenda é adaptado para ler o(s) parâmetro(s), identificar a lógica do(s) pa-râmetro(s) e usar o(s) parâmetro(s) para criar código fonte cobol (ou códigofonte em qualquer outra linguagem legível por máquina, tal como, FOR-TRAN, C, C++, PASCAL, JAVA, etc.
Como um resultado, a validação é gerada em linguagem legívelpor computador, por exemplo, em código fonte COBOL. A captura de telamostrada na figura 6 contém o código fonte do programa resultante, que po-de ser usado em uma etapa posterior, quando gerar o arquivo executável.Em outras palavras, a tabela mostrada na figura 6 é uma tabela de códigoexemplificativo, em que o código fonte é equivalente à condição, à medidaque lançado através da GUI mostrada na figura 3.
Portanto,, usando o sistema baseado em computador, de acordocom o presente pedido, o criador de um produto, isto é, dois ou mais arqui-vos executáveis interrelacionados, pode definir uma ou mais validações emtexto claro usando a GUI 1, conforme mostrado na figura 3. O conteúdo daGUI mostrado na figura 3 é transferido para uma tabela de definição, con-forme mostrado na figura 4. Os valores numéricos e/ou condições matemáti-cas da validação são armazenados em uma tabela de condição, conformemostrado nas figuras 5a e 5b. Usando as condições matemáticas e os valo-res numéricos, à medida que armazenados na tabela de condição, de acordocom as figuras 5a e 5b, o código fonte é automaticamente gerado. O códigofonte é armazenado em uma tabela de código, conforme mostrado na figura6. É possível que as condições sejam geralmente armazenadas em uma oumais tabelas de condição e que os valores numéricos, por exemplo, de vari-áveis/parâmetros usados nas condições armazenadas na(s) tabela(s) decondição, sejam armazenados em uma ou mais tabela(s) de valor e/ou umaou mais tabelas de variável/parâmetro.
- Acessos
Este componente de Fábrica de Produto, isto é, o siste-ma/método baseado em computador, de acordo com o presente pedido paracriar dois ou mais arquivos executáveis interrelacionados, que é parte de ummódulo, permite através do campos chave para a busca de dados em umatabela de corporação. Os acessos também são reutilizáveis entre os produ-tos, isto é, diferentes métodos/sistemas baseados em computador que com-preendem dois ou mais arquivos executáveis interrelacionados.
É possível adicionar, modificar ou apagar um Acesso ao seguir ocaminho Sistema>Prod. Conf.>Acessos. As capturas de tela, conforme mos-trado, nas figuras 7a, 7b, 8a, 8b e 9 contêm o exemplo de um Acesso a umatabela com todas os seus resultados chave e econômicos. Cada Acesso temum conjunto de chave(s) e o(s) resultado(s) associado(s). A seguir, encontra-se um exemplo de um Acesso "ACC_SIC_2ND". As chaves são realçadasnas duas capturas de tela, de acordo com as figuras 7a e 7b, à medida queexistem muitas para se ajustar em uma única captura de tela.
Os resultados econômicos mencionados acima são realçadosnas duas capturas de tela, de acordo com as figuras 8a e 8b.
Os Acessos são armazenados na tabela KTPM38T. A captura detela, de acordo com a figura 9, contém a definição do exemplo acima emuma tabela de definição. Os elementos relevantes estão realçados, incluindoseu código exclusivo "0000001280".
Os resultados econômicos deste Acesso, tais como, os dadoseconômicos relevantes que podem ser considerados quando produzem ocódigo fonte e, posteriormente, nos arquivos executáveis, são armazenadosna tabela KTPA30T. Estes são os mesmos que aparecem no exemplo dosistema/método implementado por computador, conforme mostrado nas figu-ras. Eles são realçados nas capturas de tela, conforme mostrado nas figuras10a e 10b, que representam uma tabela de variável/parâmetro.
A Tabela KTPA37T com as chaves para este Acesso particular éexibida nas duas capturas de tela, de acordo com as figuras 11a e 11b, quemostram uma tabela de condição.
O código do programa é exibido nas quatro capturas de tela, deacordo com as figuras 12a a 12d, que mostram uma tabela de código. Osresultados e as chaves são selecionados e, então, o Acesso é executado. Oresultado é a geração de um Acesso.
O gerador (fonte COBOL KTPLP007), a fim de gerar automati-camente o código e nos copybooks irão acessar ambas as tabelas(KTAP30T e KTPA37T) e realizar as seguintes instruções representadas nopseudocódigo. As seguintes instruções no pseudocódigo representam comoo programa opera e se converte em fonte COBOL que é configurada nastabelas mencionadas:
Etapa 1
Etapa 1.1 - Ler o primeiro registro a partir de KTPA30T (R1) eEtapa 1.2 - RealizarEtapa 1.2.1 - Escrever nova linha com a informação de KTPA30T(L1)
Etapa 1.2.2-. Ler o próximo registro a partir de KTPA30T (R2)
Até o final de KTPA30T.
Etapa 1.3 - Escrever novas "Linhas Fixas"
Etapa 2
Etapa 2.4 - Ler o primeiro registro a partir de KTPA37T (R1) eEtapa 2.5 - Realizar
Etapa 2.5.1 - Escrever nova linha com a informação de KTPA37T(L1)
Etapa 2.5.2 - Ler o próximo registro a partir de KTPA37T (R2)
Até o final de KTPA37T.
Etapa 2.6 - Escrever novas "Linhas Fixas"
Etapa 3
Etapa 3.7 - Ler o primeiro registro a partir de KTPA30T (R1) eEtapa 3.8 - Realizar
Etapa 3.8.1 - Escrever nova linha com a informação de KTPA30T(L1)
Etapa 3.8.2 - Ler o próximo registro a partir de KTPA30T (R2)Até o final de KTPA30T.
Etapa 3.8 - Escrever novo erro de manipulação de "Linhas Fi-xas", etc...
No pseudocódigo acima, as "linhasjixas" usam a informação docódigo de tabela e código de acesso KTPM38T.
As subetapas 1.2.1 e 1.2.2 podem ser iterativas/repetidas. Tam-bém, as subetapas 2.5.1 e 2.5.2 podem ser iterativas/repetidas. Também, assubetapas 3.8.1 e 3.8.2 podem ser iterativas/repetidas.
O pseudocódigo acima é refletido no código, conforme mostradonas figuras 12a a 12d, em que a figura 12a representa a etapa 1, a figura12b representa a etapa 2 e as figuras 12c e 12d representam a etapa 3, quejá começa na linha 061946 na figura 12b.
- Regras de Classificação
Através do módulo "regras de classificação", o criador do produtodefine as operações (feitas de um ou mais cálculos) usadas para calcular ataxa de produto (os prêmios foram calculados no nível de cobertura). Nãoapenas os elementos podem ser usados nos cálculos, porém, os valores (porexemplo, fatores) armazenados nas tabelas de corporação podem ser usa-dos também através dos "Acessos". Os programas de classificação externatambém podem ser "capturados" nestes cálculos. Uma visão geral esquemá-tica é mostrada na figura 13, que é similar à figura 2. Em particular, a figura13 mostra uma operação que pode compreender um grupo de cálculos, taiscomo, cálculos n, em que n é um número natural. Em particular, n é igual a1, 2, 3, 4, 5, 6, 8, 10, 15, 20, etc. Um cálculo pode ser uma validação préviaque compreende operandos e operadores, conforme descrito com referênciaà figura 3.
As capturas de tela de um exemplo gráfico são mostradas nasfiguras 14a a 14d, que podem ser criadas pelo exemplo do sistema/métodoimplementado por computador, conforme mostrado pelas figuras, quandoseguem o caminho Sistema>Prod. Conf.>Cálculos. A partir daqui, as opera-ções podem ser adicionadas, modificadas ou apagadas. Por exemplo, asfiguras 14a a 14c representam um composto de cálculos para uma operaçãochamada de "OP_DEFAULT_8". Cada linha é separadamente realçada emuma respectiva figura. A primeira linha (na figura 14a) contém o cálculo "C1".
A segunda linha (na figura 14b) contém o próximo cálculo, "C2" e a últimalinha (na figura 14c) contém o último cálculo "C3".
Portanto; o módulo de classificação permite a realização de to-das as operações financeiras necessárias para a criação de um produto téc-nico ou comercial, assim como o acesso às tabelas necessárias para realizarqualquer uma das ditas operações.
Um acesso permite a consulta dos valores armazenados emuma tabela e a configuração das condições para a consulta particular. Pode-se especificar o seguinte:
Chave(s), que pode(m) compreender o(s) campo(s) da tabelamediante a qual uma condição de acesso é estabelecida.
Operador(s), que pode(m) compreender igual, maior que, menorou igual a, etc.
Operando(s) que pode(m) compreender constante(s) através dasquais a chave é comparada.
Campo(s) de tabela que correspondem ao resultado do acesso.
Um ou mais dos seguintes componentes podem ser encontradosem uma operação:
Nome e descrição de uma operação.
Cálculos que contêm
- operandos que podem ser constantes numéricas, valores nu-méricos de elementos, resultados de outros cálculos ou operações, resulta-dos numéricos de acesso às tabelas, rotinas, etc. e/ou
- operadores: +, -, *, / e/ou
- circuitos e funções de soma e/ou
- funções predefinidas que podem compreender grupos de cálcu-lo padronizado que fornecem um resultado numérico de acordo com os pa-râmetros de uma entrada.
Também é possível que pelo menos uma validação possa seradicionada antes de uma operação. As operações podem ser designadas auma classe prêmio e/ou um objeto e/ou a conceitos econômicos específicos.
Uma vez que uma operação é registrada, a mesma pode ser reutilizada emoutros componentes de um produto ou em produtos diferentes.
Outro exemplo de classificação é mostrado na captura de telaincluída na figura 14d, que mostra uma GUI exemplificativa. Neste exemplo(em pseudocódigo):
Taxa de Prêmio de Seguro = Taxa Antes do Prêmio *
Alíquota de Imposto de Prêmio de Seguro /100
A GUI exemplificativa permite o tipo direto da operação no cam-po especificado, usando a sintaxe correta. A dita operação pode ser validadausando o botão Também é possível procurar o operando e extrair o ope-rando a ser usado ao usar o botão "Operando". Portanto, assegura-se queuma operação existente seja usada.No conteúdo dos cálculos acima 3 níveis foram definidos:
- C1 (referido como linha 01 na figura 14a) é cálculo baseado emuma validação que é executada se a validação for FALSA, isto é, o cálculoC1 é realizado se o resultado da validação "CONTEÚDOS DE SOMA 4 >LIM" for "falso". A validação "CONTEÚDOS DE SOMA 4 > LIM" foi definidade maneira exemplificativa pela figura 3 acima.
- C2 (referido como linha 05 na figura 14b) é um cálculo baseadona validação "CONTEÚDOS DE SOMA 4 > LIM". O cálculo C2 é executadose a dita validação for "verdadeira".
- C3 (referido como linha 10 na figura 14c) é um cálculo quesempre é executado.
A operação real é definida para o criador do produto e armaze-nada na tabela KTPM56T, isto é, na tabela de definição. Esta tabela é aquelaem que todas as operações são armazenadas. A Tabela KTPM56T é mos-trada na captura de tela de acordo com a figura 15.
As definições deste cálculo são contidas na tabela KTPA57T,como uma tabela de condição exemplificativa, que é mostrada de maneiraexemplificativa nas duas capturas de tela, de acordo com as figuras 16a e16b. Para cada linha (R1, R2, R3), que é armazenada na tabela KTPA57T(figuras 16a e 16b), o formato do cálculo e quaisquer variáveis associadassão definidos.
O conteúdo do cálculo é armazenado na tabela KTPA78T, comouma tabela de variável/parâmetro exemplificativa, que é mostrada de manei-ra exemplificativa nas duas capturas de tela, de acordo com as figuras 17a e17b. De maneira resumida, a tabela KTPA78T mantém as relações matemá-ticas entre os operandos e os operadores, então, no final a dita tabela arma-zena como os elementos ou componentes são relacionados em uma regramatemática.
O código do programa é mostrado de maneira exemplificativa natabela, de acordo com as capturas de tela na figuras 18a a 18c, que é umatabela de código exemplificativa. A partir das seguintes instruções no pseu-docódigo, pode-se ver o acontece em cada linha. Como nas validações eacessos, o gerador (fonte COBOL KTPLP007) gera um código automatica-mente nos copiadores que irão, por sua vez, acessar as tabelas (KTPA57T eKTPA78T) e irão, então, informar estas instruções de pseudocódigo. Destamaneira o programa converte o conteúdo de uma tabela em fonte cobol (empseudocódigo):
Etapa 1:
1.1- Ler o primeiro registro a partir de KTPA57T e escrever
1.2 - Realizar
1.2.1 - Se existe uma validação associada ao cálculo:
1.2.1.1 - Escrever a sentença REALIZAÇÃO para executar avalidação.
1.2.1.2 - Escrever o SE para avaliar o resultado de validação(Verdadeiro ou Falso)
1.2.2 - Escrever REALIZAÇÃO para executar o cálculo. (C)
1.2.3 - Se existe uma validação associada ao cálculo:
2.3.1 - Escrever Final de linhas e sair
1.2.2 - Ler o próximo registro a partir de KTPA57TAté o final de KTPA57T.
Como um resultado do circuito acima, o gerador gera o formatodo cálculo baseado no que é lido a partir de KTPA57T, e o código é geradono copiador TP3CCYAU, à medida que o mesmo é mostrado na captura detela, de acordo com a figura 18a.
O cálculo de nível 01 (vide definição dos níveis acima) é realiza-do quando a validação é "falsa", então, o segundo nível 05 é realizado quan-do a validação é "verdadeira" e o terceiro nível 10 será executado não sub-metido a qualquer validação. Os níveis são indicados na figura 18a pelasrespectivas caixas rotulada "F" (cálculo de nível 01), "T" (cálculo de nível 05)e "Cálculo" (cálculo de nível 10).
Finalmente, o conteúdo dos 3 níveis do cálculo (C1, C2 e C3) ouo nível 01, 05 e 10 é escrito no mesmo copiador TP3CCYAU. O pseudocódi-go ou as instruções que os programas seguem, a fim de escrever os conteú-do são os seguintes (pseudocódigo para acesso de tabela KTPA78T):Etapa 2:
2.1 - Ler o primeiro registro a partir de KTPA78T e
2.2 - Realizar
2.2.1 - Escrever nova linha com a informação de KTPA78T
2.2.2 - Ler o próximo registro a partir de KTPA78T Até o final de KTPA78T.
Subetapas 2.2.1 e 2.2.2 podem ser iterativas/repetidas.
Como um resultado deste circuito (etapas 2.2.1 e 2.2.2) nestecopiador mencionado acima o CONTEÚDO destes cálculos (C1, C2 e C3 ouos níveis 01, 05 e 10) também é escrito. Na captura de tela, de acordo comas figuras 18b e 18c, mostra-se como os cálculos são realizados em cadanível. Isto significa que a REALIZAÇÃO (instrução Cobol que executa o queé definido no interior) que é chamada na ETAPA 1 é definida neste ponto naETAPA 2, conforme mostrado nas figuras 18b e 18c.
Textos/Parágrafos
O módulo "textos/parágrafos" permite a definição dos textos(modelos de documento) a serem gerados para cada produto, isto é, paracada conjunto de dois ou mais arquivos executáveis interrelacionados, assimcomo as regras de disparo para os parágrafos (por exemplo, se a coberturaA for selecionada, a cláusula XXX será impressa). Uma visão geral esque-mática é mostrada na figura 19 (que é similar às figuras 2 e 13). Na figura 19,a criação de acordo com os textos/parágrafos módulo é mostrada. Como umexemplo, o "texto" pode compreender inúmeros parágrafos, tais como, 1, 2,3, 4, 5, 6, 10, 15, 20, etc. parágrafos, cada um destes pode ser individual-mente direcionado e individualmente associado, por exemplo, a pelo menosum produto e/ou pelo menos um objeto segurado e/ou pelo menos uma co-bertura, etc. Na figura 19, o "Objeto Segurado" é associado ao "Parágrafo 1".Também é possível que 2 ou mais parágrafos sejam associados ao dito "Ob-jeto Segurado". Além disso, a "Cobertura 1" é associada a um parágrafo, ouseja, "Parágrafo 2". "Cobertura 2" é associada a um parágrafo, ou seja, "Pa-rágrafo 3". É possível que cada cobertura seja associada a dois ou mais pa-rágrafos e/ou que cada cobertura seja associada a um parágrafo idêntico.Como um exemplo, a "Cobertura 1" pode ser associada ao "Parágrafo 1" e a"Cobertura 2 pode ser associada ao "Parágrafo 2" e o "Parágrafo 3". Tam-bém é possível, neste exemplo, que a "Cobertura 1" seja associada ao "Pa-rágrafo 1" e ao "Parágrafo 2".
Como nas validações, acessos e operações, as tabelas são usa-das para definir e armazenar variáveis. A Tabela KTPA65T é a base para osdocumentos gerados para um produto.
Os parágrafos têm um código fixo que significa que naquela ta-belas existem parágrafos que são associados a cada código de cobertura e,também, a cada produto, isto é, para cada conjunto de dois ou mais arquivosexecutáveis interrelacionados.
Para disparar os parágrafos também existem validações que sãoassociadas aos mesmos, isto significa que um parágrafo de texto pode serdisparado com base no fato de que a cobertura que é associada é contrata-da e, também, se a mesma tem uma validação associada a isto. Portanto,este módulo permite a designação/não designação de cláusulas específicase textos necessários na definição de produto. Isto permite a designação detexto(s) aos parágrafos correspondentes em qualquer nível de definição deproduto. Isto permite mostrar se um parágrafo é opcional ou compulsório e,também, associar condições lógicas aos parágrafos.
As capturas de tela, de acordo com as figuras 20a a 20c repre-sentam um exemplo desta definição KTPA65T de tabela.
As capturas de tela, de acordo com as figuras 21a e 21b contêma parte do programa COBOL que acessa os campos da tabela KTPA65T e lêos valores que documentação é projetada para ser gerada. Como um resul-tado de acesso à tabela KTPA65T, o programa pode gerar a documentaçãorequerida.
Aqui, o processo não é realmente o mesmo que os outros níveisexplicados como o executável que é chamado a fim de disparar os parágra-fos (e obviamente os documentos), ler os registros associados a um parágra-fo particular e mover toda a informação armazenada em uma variável internaatravés de um Instrução Cobol chamada CURSOR, conforme mostrado nascapturas de tela, de acordo com as figuras 21a e 21b.
Finalmente, após a leitura da informação armazenada para cadaparágrafo, no mesmo copiador (executável), TPSTCDBD é verificada se umcerto parágrafo precisa ser disparado ou não apesar do fato de ser contrata-do. Isto também é verificado através do código automatizado gerado combase nas validações associadas aos parágrafos que também foram descar-regados naquele copiador, conforme mostrado na captura de tela de acordocom figura 22.
Além do que foi dito acima, um ou mais dos módulos de suportepodem ser incluídos:
- Simulação (Simulador)
O objetivo deste módulo é permitir que o usuário verifique as o-perações e/ou cálculos associado à definição de produto e use os dados deportfólio para simular os resultados de alterações na definição de produto(por exemplo, simular o impacto no prêmio em dinheiro devido a uma altera-ção no preço de produto).
Coerência
O objetivo principal deste módulo é assegurar que a definição deproduto realizada a partir de módulos de definição, validação e ta-xa/classificação oferece integridade suficientepara permitir a geração de produto (objeto executável) e/ouque a Administração de apólice e pedidos de Reivindicaçõespossam realizar as operações com base no produto definido.
- Utilidades
Este módulo proporciona uma ou mais das seguintes facilidades:Cópia de produtos.
Introdução e uso de tabelas biométricas (por exemplo, tabelas de mortalidade).
Criação de variáveis de vida (símbolos de comutação).
Geração automática de descrição nas tabelas de corporação.
Além do que foi dito acima, um módulo de gerenciamento de competência pode ser incluído.- Gerenciamento de Competência
Os parâmetros de competência para elementos e/ou para valida-ções podem ser definidos a partir da aplicação de Fábrica de Produto. Aodefinir um elemento e/ou validação como um parâmetro de competência, seucomportamento pode ser modificado, de acordo com papel e/ou localizaçãogeográfica e/ou acesso de usuário do elemento na administração de apólice,em que os níveis de autorização podem ser levados em consideração. Estemódulo pode ser conectado à aplicação de componentes comum, que basi-camente gerencia as competências.
Adicionalmente, um módulo de subscrição pode ser proporcio-nado.
- Subscrição
Este módulo pode permitir adaptações rápidas de produtos co-merciais em nível local e permitir o fechamento de detalhes de negociação ealterar as características de um produto comercial de acordo com os parâ-metros predeterminados. Este módulo pode se aplicar ao cliente/grupo deafinidade/segmento aIvo/intermediário.
3. Produto Gerador
Após configurar o produto usando os módulos anteriores, isto é,após a composição de uma combinação de códigos legíveis por máquina nalinguagem de máquina ao selecionar e associar duas ou mais seções de có-digo usando a GUI, a Fábrica de Produto Gerador transforma os ditos dados,que podem ser configurados a partir das tabelas, nos arquivos executáveisCOBOL que contém a base de um produto, isto é, todas as informações eregras de produto (exceto para aqueles valores mantidos nas tabelas de cor-poração). No contexto do presente pedido, o termo "programa executável"pode ser sinônimo para o termo "arquivo executável" ou o termo "programaexecutável" pode compreender dois ou mais arquivos executáveis interrela-cionados. Através dos módulos de Administração de Apólice, apólices, vali-dações de dados, etc. podem ser gerados para o produto.
Este Produto Executável é chamado a partir dos serviços deAdministração de Apólice através de interfaces padrão, conforme mostradode maneira exemplificativa na figura 23. De acordo com a figura 23, existeum serviço de Administração de Apólice que é o KCILMZ06 que pode cha-mar as executáveis quando o usuário ou quando a ação é VALIDAR ou CLASSIFICAR.
Ambas as ações podem ser disparadas em três diferentes níveis:
Apólice
Objeto
Cobertura.
Agora, o serviço de Administração de Apólice é sempre o mesmo(KCILMZ06), porém, as executáveis a partir da Fábrica de Produto que reali-zam a ação de VALIDAÇÃO OU CLASSIFICAÇÃO são dinâmicas. Isto signi-fica que o serviço KCILMZ06 está acessando uma ou mais tabelas, onde onome das executáveis que precisam usar em cada nível e em cada ação éarmazenado. Esta tabela é, por exemplo, KTPM01T.
4. Resumo de Fluxos de Processo de Fábrica de ProdutoA figura 24 mostra um fluxograma que resume os fluxos de pro-cesso principais descritos ao longo de todo o documento. A figura 24 descre-ve a funcionalidade da "Fábrica de Produto", ou seja, para gerar particular-mente programas de alta complexidade a partir de uma entrada de dados inicial.
As etapas S1 a S3 são realizadas, de preferência, no lado decliente. As etapas S4 a S6 são realizadas, de preferência, no lado de servidor.
Na etapa S1, o dado relevante para definir os dois ou mais ar-quivos executáveis interrelacionados é lançado por um usuário do siste-ma/método baseado em computador, de acordo com o presente pedido. Osistema/método baseado em computador também pode ser referido como"Fábrica de Produto". Em particular, o dado é lançado usando uma GUI, con-forme mostrado de maneira exemplificativa nas figuras, tal como a figura 3.
Na etapa S2, o dado lançado é armazenado em uma ou maistabelas, conforme também mostrado nas respectivas figuras, tais como, figu-ras 4, 5a e 5b. As etapas 1 e 2 podem ser realizadas de uma maneira repeti-da, em que o dado pode ser subseqüentemente lançado (etapa 1) e o ditodado pode ser armazenado em uma ou mais tabelas (etapa 2).
Na etapa S3, a verificação implementada por computador da co-erência é realizada, em que uma ferramenta de coerência pode ser usada. Aferramenta de coerência pode compreender uma GUI para comunicaçãocom o usuário do sistema. Em particular, a ferramenta de coerência pode seradaptada para produzir um resultado do teste de coerência no texto claro. Demaneira vantajosa, a coerência do código na linguagem legível por máquinapode ser verificada em sua totalidade no lado de cliente, particularmente,sem compilação. Os dois ou mais arquivos executáveis podem, então, sercriados no lado de servidor (vide etapas S4 a S6) e executarem, com riscominimizado de erros de tempo de execução.
Na etapa S4, os processos que compreende, por exemplo, vali-dações, acessos, etc. podem ser gerados e, em particular, os dois ou maisarquivos executáveis interrelacionados são compilados usando um compila-dor e, deste modo,
na etapa S5, os dois ou mais arquivos executáveis interrelacio-nados (referidos, por exemplo, como programas de resultado) são gerados.
Na etapa S6, os dois ou mais arquivos executáveis interrelacio-nados são testados ao executar os mesmos o lado de servidor.
A seguir, as vantagens do método/sistema implementado porcomputador, de acordo com o presente pedido, são descritas:
5.1. Evitar problemas de conexão
Esta vantagem será explicada por meio de um exemplo, onde aoperação 1 foi projetada da seguinte maneira:
Operação 1 = Elemento 1 + Elemento 2
Em um banco de dados especifico, a Operação 1 pode ser co-nectada ao Produto Técnico (isto é, a cada conjunto de dois ou mais arqui-vos executáveis interrelacionados) que a mesma corresponde, a fim de indi-car para sistema onde o mesmo pode recuperar os valores para os compo-nentes da operação (elemento 1 e elemento 2 neste exemplo). A conexão daoperação significa que primeiro os operandos devem ser conectados, nestecaso, o Elemento 1 e o Elemento 2, onde estes elementos devem ser desig-nados ao nível desejado,que pode ser o produto, objeto ou cobertura (os ní-veis são indicados na figura 1a). Então, uma vez que os elementos são co-nectados, o sistema sabe onde os valores relacionados ao mesmo são ar-mazenados. O mesmo ocorre com a operação. Como um resultado destaoperação, o fato ser conectado significa que o sistema irá saber onde os va-lores relacionados ao mesmo são armazenados.
Quando gerar o produto, isto é, os dois ou mais arquivos execu-táveis interrelacionados, o gerador irá verificar se todas as conexões forameficientemente estabelecidas. Se não, o processo falha, e uma descrição deerro será escrita no registro de problema.
A fim de evitar falha, a operação pode ser adequadamente co-nectada antes da geração. Além disso, de acordo com o presente pedido, aferramenta de coerência é usada antes da geração, a fim de descobrir se asconexões foram eficientemente efetuadas. No caso de uma conexão incorre-ta ter sido efetuada, a ferramenta de coerência proporciona uma mensagemde erro, que aponta a inconsistência e/ou uma conexão incorreta. A ferra-menta de coerência é a capacidade que permite a verificação (antes da ge-ração) da coerência da Fábrica de Componentes de produto definição e suasrelações. Então, esta ferramenta valida não apenas a definição, mas tambémse a relação construída também é consistente. Em outras palavras, a ferra-menta de coerência pode verificar se as validações, elementos e operaçõessão corretamente relacionados e oferecem integridade. A ferramenta de coe-rência, em particular, é adaptada para ser executada usando a GUI. De ma-neira exemplificativa, um usuário pode definir e criar um ou mais conjuntosde código fonte usando a GUI, conforme mostrado na figura 25. Ao selecio-nar o botão 16, uma etapa de projeto ou associação para selecionar e asso-ciar as duas ou mais seções de código legível por máquina interrelacionadoé realizada. De maneira vantajosa, um ou mais projetos/produtos podem serescolhidos a partir da lista de produtos predefinidos disponíveis. De acordocom o exemplo mostrado na figura 25, o modelo "Core_Motor" é seleciona-do. O modelo "Core_Motor" pode representar uma definição de duas ou maisseções selecionadas de código legível por máquina. Ao selecionar o botão16, o código fonte do modelo "Core_Motor" é criado, em particular, as asso-ciações das duas ou mais seções de código legível por máquina são estabelecidas.
Como uma próxima etapa, que usa a dita GUI, que agora pro-porciona um botão 18, conforme mostrado na figura 26, a ferramenta de coe-rência é ativada, que agora verifica as duas ou mais seções de código legívelpor máquina selecionadas e associadas, isto é, a verificação implementadapor computador das associações de dois ou mais códigos legíveis por má-quina selecionados e associados é realizada. Em outras palavras, a coerên-cia de duas ou mais seções selecionadas e associadas de código legível pormáquina é verificada usando a ferramenta de coerência ao selecionar o bo-tão 18. A ferramenta de coerência pode ser executada no fundo e proporcio-nar uma mensagem, por exemplo, quando a verificação de coerência for ne-gativa, que particularmente proporciona detalhes para a natureza da coerên-cia negativa. A ferramenta de coerência pode proporcionar também umamensagem positive, no caso dè uma verificação positiva da coerência.
Também é possível que a ferramenta de coerência proporcioneuma janela individual na GUI ou seja exibida como uma janela na GUI, con-forme mostrado nas figuras 27a, 27b e 27c. Conforme mostrado nestas figu-ras, os parâmetros específicos podem ser selecionados, tais como, "coerên-cia de Elementos", "coerência de Validações" e/ou "coerência de classifica-ções". Também, a GUI/ferramenta de coerência pode ser adaptada paraproporcionar detalhes da validação de coerência, conforme também mostra-do nas figuras 27a, 27b e 27c.
5.2. Evitar problemas de formato
Dois exemplos são fornecidos a fim de descreverem esta vantagem:
Validações
é possível apresentar a seguinte validação definida:
'Se E1 > Op1, então
onde:E1 = valor de elemento
Op1 = resultado de um cálculo
Se o elemento E1 for definido com 'formato alfanumérico' e oresultado da Operação 1 for definido como 'formato numérico', o gerador nãoserá capaz de comparar seus valores e, consequentemente, nenhuma men-sagem de erro será criada pelo gerador que gera os arquivos executáveisinterrelacionados. No tempo de execução, o processo irá falhar e uma des-crição de erro será escrita no registro de problema.
De maneira vantajosa, a ferramenta de coerência pode verificaras inconsistências e produzir uma respectiva mensagem, mediante a qual ainconsistência pode ser corrigida. No exemplo, E1 será definido como 'Nu-mérico'. Em outras palavras, mesmo se o gerador não proporcionar qualqueraviso e/ou mensagem de erro, a ferramenta de coerência é capaz de deter-mine a inconsistência e produzir em texto claro um aviso e/ou mensagem deerro, mediante a qual a validação pode ser corrigida.
Em outras palavras, se a cláusula que compreende duas variá-veis for uma seção de código. Ao verificar se as variáveis "E1" e "Op1" po-dem ser comparadas usando o operador matemático ">", a coerência da se-ção de código é verificada, em particular, se a dita seção de código é capazde produzir uma saída consistente. Esta coerência pode ser particularmenteverificada usando a ferramenta de coerência.
b) Operações
é possível ter a seguinte operação definida:Operação 1 = Cálculo 1 + Cálculo 2Cálculo 1 = Elemento 1 + Elemento 2Cálculo 2 = Operação 2onde:
a operação 1 é definida como: Dec (15, 3)
o cálculo 1 é definido como: Dec (15, 3)
o cálculo 2 é definido como: Dec (11,6)
a operação 2 é definida como: Dec (15, 3)
Geralmente, estes resultados de operações que são importaçõeseconômicas, são definidos como Dec (15, 3), enquanto as porcentagens sãodefinidas como Dec (11, 6).
Neste exemplo, a Operação 2 é definida como Dec (15, 3), po-rém, o cálculo 2 é definido como Dec (11, 6). A operação 2 é definida comum formato numérico mais alto que o Cálculo 2. Neste caso, o gerador podegerar um 'erro de Aviso'. A geração e a compilação irão terminar, porém, ousuário será avisado sobre este fato.
Durante o tempo de execução (também referido como tempo deoperação), se todos os resultados da operação 2 se ajustarem ao formatodefinido para o Cálculo 2, nada irá acontecer. Porém, existe um risco, no ca-so de os resultados da operação 2 não se ajustarem ao formato de Cálculo 2(ex: 123456789, 122). Neste caso, durante o tempo de execução, o sistemairá gerar um erro.
De maneira vantajosa, a fim de evitar um possível erro durante otempo de execução, o formata do Cálculo 2 pode ser alterado para Dec (15,3), em que o formato (15, 3) significa que o valor pode ter no máximo 3 de-cimais e 12 números inteiros; o formato (11, 6) significa que o valor pode terno máximo 6 decimais e 5 números inteiros. Usando particularmente a fer-ramenta de coerência, o aviso criado pelo criador/compilador será traduzidoe produzido em texto claro para o fomentador que não precisa saber a lin-guagem legível por máquina, na qual o gerador também produz o aviso.Consequentemente, o usuário também entende o aviso e pode adaptar osistema ao corrigir a inconsistência. Em outras palavras, de acordo com opresente pedido, a coerência das associações das seções de código é verifi-cada de maneira vantajosa, em que a "Operação 1" representa uma primeiraseção de código e a "Operação 2" representa uma segunda seção de códigoe a associação entre as duas seções de código é realizada ao definirOperação 1 = Cálculo 1 + Cálculo2,onde "Cálculo 2 = Operação 2".
Também é possível que a "Operação 1" seja usada para gerarum arquivo executável. A "Operação 2" pode ser usada para gerar um arqui-vo executável adicional. Consequentemente, ambos os arquivos executáveissão interrelacionados, uma vez que a saída de um arquivo executável (porexemplo, a saída da "Operação 2") é usada como a entrada do outro arquivoexecutável (por exemplo, da "Operação 1").
5.3. Evitar problemas de sistema
De maneira vantajosa, os parâmetros do compilador são adapta-dos e otimizados e o programa de classificação pode ser separado, de modoque o processador, mesmo quando tem a capacidade limitada (outros possí-veis processos podem ser executados ao mesmo tempo), os arquivos execu-táveis interrelacionados podem ser gerados sem falha de geração. Em parti-cular, o gerador pode ser separado em diferentes programas que atendemas funcionalidades (Operações, Validações, textos e documentação) propor-cionando, deste modo, geração confiável dos arquivos executáveis interrela-cionados.
Consequentemente, de acordo com o método acima, um conjun-to de condições técnicas que será apresentado para as autoridades regula-doras de seguro e que não pode ser comercializado como tal, pode ser usa-do. As condições adicionais podem ser adicionadas ao dito conjunto de con-dições técnicas. Estas condições podem ser criadas para uma parte especí-fica de uma organização, tal como, uma empresa, linha de negócio, área ge-ográfica, canal de distribuição. Tudo isto pode ser aplicável, para ser umproduto que pode ser definido e as ditas condições adicionais podem sercriadas ao selecionar a partir do conjunto de condições técnicas, o que é e oque não é aplicável às condições adicionais.
As condições adicionais podem ser mapeadas em apenas umconjunto específico de condições técnicas e também podem restringir o con-junto de condições técnicas. As condições adicionais podem definir o produ-to, à medida que o mesmo é conhecido pelos clientes e vendido por interme-diários. As condições adicionais podem ser específicas à quem as vendee/ou à quem as mesmas são vendidas:
- Descontos comerciais e/ou
- Componentes de risco obrigatórios/opcionais e/ou
- Limitações de elementoA figura 28 mostra uma captura de tela exemplificativa de umainterface gráfica de usuário (GUI) 101. A GUI 101 compreende inúmeras en-tidades de entrada/saída, tais como, listas suspensas 110, botões 112, cam-pos de entrada 114 e janela de entrada/saída 116. De maneira exemplificati-va, mesmo se a GUI 101 for usada para proporcionar diferentes produtos,isto é, para criar apólices de seguro de carro e/ou apólices de seguro e/ouapólices de seguro de saúde, etc, as listas suspensas 110 e os botões 112podem ser substancialmente mantidos. Também é possível que os camposde entrada 114 possam ser substancialmente mantidos. Como um exemplo,um campo de entrada 114a, o produto específico pode ser definido para oqual o texto legível por humano, por exemplo, uma apólice, deve ser criado.Na GUI exemplificativa 101, conforme mostrado na figura 28 como o produtoespecifico, o seguro de construção é escolhido.
A janela de entrada/saída 116 pode ser particularmente usadapara definir os parâmetros do produto, isto é, os parâmetros e/ou valoresespecíficos da apólice de seguro de construção. De maneira exemplificativa,nove elementos de exibição 118a a 118i são mostrados. Os elementos deexibição 118a a 118i refletem os elementos repositórios, conforme definidosquando definem o produto e/ou quando definem a alteração do produto. Co-mo um exemplo, no campo de entrada 114a, o termo "carro" pode ser intro-duzido, deste modo, como o seguro de carro de produto exemplificativo ecomo as apólices de seguro de carro de texto legível por humano exemplifi-cativas.
Para produtos diferentes, isto é, diferentes tipos de apólices pos-síveis, os elementos da janela de entrada/saída 116 podem ser diferentes, oque significa que diferentes elementos de exibição podem ser mostrados emdiversas janelas de entrada/saída 116. Deste modo, mais ou menos elemen-tos de exibição podem ser exibidos e/ou pelo menos um dos elementos deexibição pode ser diferente. Como um exemplo, em vez do elemento de exi-bição 118c "tipo de construção de edifício", um elemento de exibição pode sereferir ao "fabricante do carro".
Como pode ser visto a partir da figura 28, para cada elemento deexibição 118a a 118i, proporciona-se um campo de entrada 120a a 120i. Oscampos de entrada 120a a 120i podem ser usados a fim de escrever dadosem uma tabela e/ou ler dados a partir de uma tabela. Como um exemplo, ocampo de entrada 120a é usado para especificar o valor do elemento de exi-bição 118a "ano de construção de edifício" a "inferior ou igual a 1940". Emoutras palavras, é possível que quando definir o produto, isto é, quando osarquivos executáveis são criados, um elemento repositório que pode ser in-troduzido é o "ano de construção de edifício". Em uma tabela relacionada,um elemento de tabela que pode ser definido mantém o valor do dito ele-mento repositório. Neste caso exemplificativo, o valor é "inferior ou igual a1940"
Na GUI exemplificativa 101 conforme mostrado na figura 28, oscampos de entrada 120a a 120e podem ser preenchidos apenas usando va-lores predefinidos. Entretanto, também é possível que os campos de entradanão tenham quaisquer valores predefinidos, mas, de preferência, possam serpreenchidos de maneira individual, conforme mostrado nos campos de en-trada 120f a 120L Em outras palavras, os campos de entrada 120a a 120i ouos valores dos campos de entrada 120a a 120i, que podem ser introduzidosmanualmente por um usuário ou ser recuperados semiautomaticamente, porexemplo, por meio de uma lista suspensa ou automaticamente, podem serreferidos como conteúdo dos respectivos elementos de exibição 118a a 118i.
Além disso, a GUI 101 compreende uma barra de rolagem 122.Portanto, a janela de entrada/saída 116 pode compreender inúmeros ele-mentos de exibição adicionais 118 e, consequentemente, campos de entradaadicionais 120, que não são mostrados na figura 28.
A GUI 101 refere-se ao proporcionamento de uma nova cotação,conforme pode ser visto a partir do cabeçalho 124. Portanto, o texto legívelpor humano que é criado de acordo com o método descrito acima é uma co-tação de uma taxa de uma apólice de seguro definida. Conforme mostradona figura 28, enquanto a GUI 101 refere-se ao estabelecimento de uma novacotação, por exemplo, para um seguro específico, uma GUI similar pode serusada para outros propósitos, em que o esboço visual da GUI se mantémsubstancialmente. Isto é mostrado de maneira exemplificativa na GUI 101 nafigura 29.
Conforme pode ser visto na figura 29, a lista suspensa 110 e osbotões 112 são idênticos à GUI 101, conforme mostrado na figura 28. A GUI101 compreende um cabeçalho 126 que indica que a GUI 101 refere-se àcriação de uma nova apólice. Consequentemente, a janela de entrada/saída116 compreende elementos de exibição 118a' e 118b'. Consequentemente,para cada elemento de exibição 118a' a 118b', existe um campo de entradacorrespondente 120a', 120b'. Conforme mostrado na figura 29, ambos oscampos de entrada 120a', 120b' ainda se encontram vazios, porém, podemser preenchidos, por exemplo, por um usuário da GUI e/ou automaticamente.
Consequentemente, proporcionou-se uma interface muito efici-ente e facilmente entendível para proporcionar um grande numero de dife-rentes textos legíveis por humano. Tal texto legível por humano pode seruma cotação de apólice de seguro e/ou uma própria apólice de seguro e/oupartes de uma apólice de seguro. Entretanto, a dita interface, isto é, a GUI101, é tão flexível, que a mesma permite a adaptação do ambiente de com-putação subjacente, por exemplo, a fim de introduzir produtos adicionais. Noentanto, o esboço visual se mantém substancialmente inalterado, de modoque o usuário da GUI sem ter substancialmente que requerer qualquer co-nhecimento adicional de uso e/ou manutenção, possa acessar e usar umaGUI mesmo quando o ambiente de computação tiver sido adaptado.
A figura 30 mostra um fluxograma adicional que proporciona umavisão geral de etapas de processo que podem ser realizadas, em particular,quando se adaptam ao ambiente de computação.
Na etapa S1', as definições de requerimentos que podem serproporcionadas atendem as necessidades do usuário do ambiente de com-putação. Em particular, as ditas definições de requerimentos podem compre-ender, como texto legível por humano e/ou instruções, as alterações que fo-ram feitas no ambiente de computação. Tais definições de requerimentospodem ser tão simples quanto a definição de que o ambiente de computaçãopossa ser capaz de gerar um novo produto. As definições de requerimentosque podem ser adicionalmente detalhadas compreendem, em particular, to-dos os elementos que o novo produto precisa cobrir. Como um exemplo, adefinição do requerimento pode compreender que o novo produto refere-seao seguro de saúde e a definição de requerimentos também compreendeque os parâmetros/variáveis específicos precisam ser ajustados pelo usuárioda GUI. Tais parâmetros podem ser de gênero, idade, pessoa, etc.
Na etapa S2', a definição de produto é feita. A definição de pro-duto compreende o conjunto completo de parâmetros/variáveis que são ne-cessários, a fim de cumprir os requerimentos, conforme definido na etapasr.
Na etapa S3', o produto é configurado. A configuração do produ-to pode compreender particularmente a definição do produto no texto legívelpor máquina. Em outras palavras, conforme descrito acima, o código do pro-duto pode ser configurado, em que tal configuração pode ser substancial-mente realizada em texto legível por humano, conforme definido acima.
Na etapa S4' os arquivos executáveis são gerados. Conformedescrito acima, tal geração é particularmente realizada ao compilar o códigolegível por máquina no lado de servidor.
Na etapa S5', o software é instalado no lado de servidor. Isto po-de compreender que o software é instalado em um motor servidor ou em umou mais computador de clientes, conectados ao motor servidor.
Na etapa S6', um teste do produto é realizado pelo usuário. Esteteste pode ser particularmente realizado pelo usuário que também fez a defi-nição de requerimentos na etapa S1'.
Na etapa S7', verifica-se se o usuário aceita o produto. No casoafirmativo, o método é finalizado na etapa S10'. De outro modo, na etapaS8', se decide se a configuração de produto precisa ser alterada. Isto podeser particularmente o caso, se os parâmetros/variáveis precisam ser altera-dos e/ou introduzidos e/ou deletados. A razão para isto pode ser que as re-gras de negócio adicionais podem ser cobertas e/ou que as regras de negó-cio alteraram. Neste caso, o método é repetido a partir da etapa S3'.
De outro modo, isto é, se nenhuma alteração da configuração deproduto for necessária, a partir da etapa S8" quaisquer novos requerimentospodem ser implementados na etapa S9'. Particularmente, tal implementaçãonão compreende nenhuma alteração dos arquivos executáveis. Como umexemplo, tal implementação pode compreender, por exemplo, corrigir a GUIao corrigir partes da aparência visual da GUI. Especificamente, o termo no-me de empresa no campo 118a' na figura 29 pode ser substituído pelo termo"parte de negócio".
Após a implementação de todos os requerimentos na etapa S9',o método é finalizado na etapa S10'.
Como um resumo, as etapas S1\ S4', S5\ S6', S7', S8' e S9' po-dem ser realizadas no lado de servidor ou em qualquer computador adicionalque é conectado no lado de servidor. As etapas S2' e S3" são realizadas emum lado do cliente.
Fornecida a descrição acima, o presente pedido pode permitir arealização do seguinte procedimento em partes ou no total. Deste modo,também é possível que partes do procedimento sejam realizadas de maneirarepetida e/ou que partes do procedimento ou todo o procedimento seja reali-zado em ordem diferente.
O método, conforme descrito neste pedido, proporciona de ma-neira vantajosa uma solução unificada para muitas, particularmente, todas astransações de apólice (novos negócios, endossos) e pra muitos, particular-mente, todos os tipos de produtos, tal como, Seguro Geral e/ou Automóvel ePropriedade & Acidente e/ou Vida & Pensões, etc.
Este método exemplificativo pode compreender funções comunspara muitos ou todos os produtos:
Cotações
Novos Negócios e modificações de apólice (endossos, de volta àdata & endossos temporários,...)
Cancelamentos de Apólice
Restabelecimentos de Apólice
Triagem de apólice
Renovação de PortfólioAdicionalmente, o método também pode compreender as fun-ções específicas para alguns tipos de produtos, tal como, Vida & Pensões,Automóvel, Propriedade & Acidente.
De maneira vantajosa, o método descrito permite a definição deproduto através dos usuários especialistas com a mínima intervenção de de-partamento IT.
Ademais, de maneira vantajosa, o projeto e a funcionalidade desistemas podem permitir a criação e a modificação de um produto de umamaneira rápida e pouco dispendiosa, especificamente, as telas de Adminis-tração de Apólice podem ser automaticamente geradas a partir da definiçãode produto na Fábrica de Produto.
De maneira vantajosa, os processos consistentes para apólicesindividuais e/ou de múltiplos objetos e/ou grupo podem ser providos.
Além disso, de maneira vantajosa, uma metodologia comum édefinida para criar produtos em uma empresa de seguro que permite, emparticular, a determinação dos limites de risco e condições financeiras queuma empresa deseja encarar/oferecer em sua atividade de seguro.
A seguir, descreve-se um exemplo de ciclo de vida de uma apó-lice, em que as sucessivas etapas são descritas e o ciclo de vida pode co-meçar em qualquer uma das ditas etapas:Etapa: Solicitação/Cotação
O cliente entra em contato com a empresa e solicita a informa-ção de cobertura de seguro. Uma cotação é fornecida sem cobertura de risco.
Etapa: Novo Negócio
Registro de um novo negócio na base de um produto, uma apóli-ce, uma cotação ou um modelo é realizado.
Etapa: Cancelamento
Se a apólice estiver ativa, o cancelamento da apólice pode ocor-rer em qualquer ponto na vida da apólice.
Etapa: Modificações/Endossos
Esta etapa pode se referir aos endossos econômicos e/ou en-dossos não econômicos.
Etapa: Reintegração
A reativação de uma apólice inativa é realizada.
Etapa: Portfólio
A renovação de apólices atuais é realizada.
A ordem acima das etapas de método pode continuar com a eta-pa de Solicitação/Cotação.
A seguir, detalhes adicionais das etapas acima são proporciona-dos.
Etapa: Solicitação/Cotação
A nova função de quota que pode ser incorporada na função desolicitação/cotação permite que o usuário lance os dados de data, deste mo-do
o sistema oferece diversas opções de classificação e/oucotações são automaticamente armazenadas e numeradasquando todos os dados necessários são lançados (identificação cliente, obje-to, etc.) e/ou
as cotações podem ser feitas a partir de cotações e apólices e-xistentes, ou ser baseadas em um produto ou um modelo e/ou
os dados requeridos para uma nova cotação são inferior aos da-dos requeridos para um novo negócio e/ou
a cotação de diversas opções de seguro e pagamento no mesmoproduto é permitida.
A função de cotação a apólice, que pode ser incorporada na eta-pa solicitação/cotação permite selecionar uma cotação existente e solicitarum novo negócio. O sistema irá abrir o novo negócio ao transferir todos osdados de cotação para a forma de aplicação. Se uma cotação tiver sido feitapara diversas opções, o sistema irá solicitar uma única escolha para o novonegócio.
O termo "modelo" refere-se a um esboço de apólice a partir doqual as apólices são criadas. O mesmo inclui detalhes do objeto segurado eda classe prêmio retirado. Seu uso principal serve para processar novos ne-gócios de maneira rápida sem ter que lançar detalhes da escolha de classeprêmio ou do objeto segurado.
Etapa: Novo negócio
De maneira vantajosa, no método descrito, o mesmo fluxo dejanelas pode ser usado para todas as configurações de novo negócio qual-quer que seja o produto. Portanto, método é facilmente utilizável pelo usuá-rio.
Registros de novo negócio podem ser feitos na base de Produto,Cotação, Modelo, Apólice. De maneira vantajosa, o registro de novo negóciopode ser possível na base apólice, cotação ou modelo. Portanto, pó proces-so de emissão de apólice é mais fácil porque os dados pré-armazenadospodem ser usados. As condições de produto especiais podem ser definidaspara alguns clientes, negócios ou intermediários.
De maneira vantajosa, o método acima proporciona um fluxo denavegação exclusivo e as mesmas telas podem ser usadas no processo deregistro de um novo negócio.
As seguintes informações/dados podem ser usados para for de-finir o novo negócio:
A duração de apólice pode ser cancelável/temporária/decenale/ou
Datas de início e término e/ounível de emissão de recibo e/ou
forma de pagamento e/ou
tipo de cosseguro ou resseguro e/ou
tipo de regularização e/ou
detentor de apólice e coletor de dados e/ou
dados de intermediários e comissões e/ou
Cosseguro e resseguro no novo negócio
Se uma Police contém dados de cosseguro ou resseguro, estesdados podem ser lançados junto com os detalhes de apólice gerais. Quandoos detalhes de cosseguro e resseguro são lançados, os mesmos podem serespecificados se forem cosseguros aceitos ou transferidos, e/ou resseguroscompulsórios e/ou opcionais.
No caso de cessões de cosseguro, as empresas às quais partedo risco é cedido podem lançar as seguintes informações:% de participação da empresa de seguro e/ounome/nome registrado da empresa/empresas que aceitam o ris-co e/ou
% de participação de empresa de aceitação e/ouporcentagem do consórcio que corresponde à empresa de acei-tação, que é automaticamente lançada em 4% e/ou
porcentagem de despesas administrativas da apólice estabeleci-da pela empresa que faz a cessão. Isto é automaticamente lançado em 1%.
Um único recibo ou um recibo para cada empresa pode ser emi-tido quando a apólice é uma cessão de cosseguro.
No caso de cosseguro aceito, os seguintes detalhes sobre a em-presa no comando podem ser lançados:
Participação da empresa de seguro e/ou% de consórcio a ser paga pela empresa de seguro e/ou% de despesas administrativas no gerenciamento de apólice es-tabelecido pela empresa de transferência e/ou
% de comissão paga pela empresa de seguro ao intermediário
e/ou
nome/nome registrado da empresa responsável pelo risco e/ouo numero de apólice, conforme designado pela empresa no co-mando.
Controle de apólice (como parte da etapa: Novo negócio)
A tela de controle de apólice é estrutura de maneira exemplifica-tiva da seguinte forma:
Cabeçalho que identifica a apólice e/ou
árvore de apólice e/ou
botões relacionados à árvore de apólice: Novo objeto, modifica-ção de objeto, seleção de classe prêmio, modificação de classe prêmio, etce/ououtras funções, tais como, configuração de beneficiários de apó-lice, cláusula,...
A função de novo objeto segurado pode ser acessada a partir datela mencionada acima. O número de objetos segurados determina o tipo deapólice. Em Solução de Seguro esta poderia ser:
Individual/Coletivo, por exemplo, como uma função do númerode objetos segurados e/ou
Múltiplos objetos, por exemplo, uma apólice pode ter mais doque apenas um objeto segurado. Por exemplo: um carro e uma casa e/ou
Múltiplas situações, por exemplo, uma apólice pode ter mais deum caso de um objeto com diferentes riscos, como um exemplo, 2 carrospodem ser compreendidos na mesma apólice.Objeto segurado (como parte da etapa: Novo negócio)
Uma tela de novo objeto segurado geral, similar à captura de telada GUI 101, conforme mostrado nas figuras 28 e 29, pode ser exibida se ne-nhuma tela de objeto específico já existir. Uma tela de novo objeto seguradoespecífico relacionada ao tipo de objeto que é segurado pode ser mostradase esta tela específica já existir. As telas específicas podem ser desenvolvi-das para aqueles produtos com objetos que requerem desenvolvimento es-pecífico, a fim de registrar a informação de objeto. Por exemplo, se o objetoque é segurado for um carro, a informação de proprietário/motorista será re-querida como elementos de exibição exemplificativos. Entretanto, se o objetoque é segurado for uma casa, a informação de risco de elementos de exibi-ção exemplificativos, tipo de casa, etc. será requerida. E para uma informa-ção de produto Unit Link sobre a pessoa que é segurada será requerida co-mo elementos de exibição exemplificativos. A entrada pode ser o elementode tabela específico que pode ser consequentemente preenchida.Classe prêmio (como parte da etapa: Novo negócio)
A seleção de classe prêmio pode ser feita usando uma GUI es-pecífica, em que a classe prêmio para o produto comercial selecionado podeser mostrada, tal como a GUI. É possível que uma classe prêmio ou um pa-cote de classe prêmio possa ser selecionado. Uma vez selecionadas, asclasses prêmio podem ter valores designados às mesmas.Valores (como parte da etapa: Novo negócio)
Os tipos de classe prêmio dependem de qual tela de produto émostrada. A tela específica (também referida como GUI) pode mostrar a en-trada do valor da classe prêmio relacionada a este produto.
De maneira vantajosa, as telas específicas foram desenvolvidaspara certos produtos. Entretanto, uma tela padrão encontra-se disponívelpara diversos produtos que têm valores diferentes dependendo do produto. Atela pode ter um ou mais dos seguintes campos:
Classe prêmio, por exemplo, que mostra a classe prêmio sele-cionada que foi combinada no contrato.
Elementos, por exemplo, que contêm uma descrição dos ele-mentos que descrevem cada classe prêmio.
Valores, por exemplo, que contêm is campos para cada elemen-to da classe prêmio.
Similares às capturas de tela, conforme mostrado nas figuras 28e 29, os elementos de exibição e/ou os campos de entrada podem ser defi-nidos ou compreender um ou mais dos campos mencionados acima.Árvore de Apólice (como parte da etapa: Novo negócio)
A árvore de apólice mostra a relação entre os elementos existen-tes em uma apólice, em particular, exibindo um ou mais:Apólice que é um novo negócio.
Tipos de objetos que podem ser segurados pelo produto.
Os objetos segurados na apólice agrupados na árvore pelos ti-pos de objeto.
Classe prêmio através da qual cada objeto é segurado. Na árvo-re de apólice, a classe prêmio coberta na apólice é mostrada para cada obje-to segurado.
Estes elementos podem ser consultados, modificados e, no casodo objeto segurado, os elementos podem ser duplicados e cancelados.
Resultados de Classificação (como parte da etapa: Novo negócio)
Uma tela de resultado de classificação mostra o prêmio que ocliente irá pagar. Ademais, o período de prestação é um programa que de-termina como dividir o prêmio em inúmeros recibos, tanto de acordo com aforma de pagamento selecionada no prêmio de movimento anual, como nainformação proporcionada pela Fábrica de Produto. Os detalhes dos prêmiosresultantes podem ser acessados.
Período de Prestação (como parte da etapa: Novo negócio)
As seguintes validações podem ser realizadas pelo período deprestação:
Itens Fracionais: Isto determina quais itens devem ser cobradosno primeiro recibo e quais itens devem ser divididos entre os recibos subse-quentes (uma taxa sendo um exemplo de um item que não pode ser divido edeve ser cobrado no primeiro recibo).
Itens reembolsáveis: No caso em que uma classe prêmio ésubscrita, ou uma apólice cancelada, esta função determina se um item podeser devolvido para o cliente ou não (o consórcio sendo um exemplo de umitem não reembolsável em produtos de vida).
Itens não Pró-tributáveis: Isto determina se a anuidade total deveser coletada mesma quando o prêmio não é retirado em uma base anual (umexemplo é a cobertura de viagem de automóvel).
Beneficiários (como parte da etapa: Novo negócio)
A solução de seguro permite que diferentes beneficiários sejamdesignados a diferentes níveis da apólice, ou seja, apólice e/ou objeto e/ouclasse prêmio.
Para designar beneficiários, um elemento da árvore de apólicepode ser selecionado na tela de Controle de Apólice e, então, o botão 'Bene-ficiários' é selecionado. Após isto a tela de Manutenção de Beneficiários éacessada.
Comissões (como parte da etapa: Novo negócio)
Se a comissão selecionada a partir da folha de intermediários natela de dados de apólice individual for 'Referida' ou 'Distribuída', então, o sis-tema não permite a emissão da apólice até as comissões serem configura-das na tela 'Comissões Manuais'. Esta tela pode ser obtida usando-se o bo-tão 'Comissões (a partir da tela de Controle de Apólice)Documentação (como parte da etapa: Novo negócio)
As condições particulares associadas a um produto que é subs-crito e os parágrafos que formam o documento podem aparecer como textona janela de composição do documento. Todo o texto pode compreenderparágrafos. Os parágrafos pode ser
Compulsórios, por exemplo, o(s) parágrafo(s) são necessáriospara o texto ou
Não compulsórios, por exemplo, o(s) parágrafo(s) não são ne-cessários para o texto.
Além disso, os seguintes parágrafos podem ser distinguidos:Parágrafos fixos: O usuário não pode modificar, adicionar ou eli-minar qualquer texto no parágrafo. Alguns parágrafos fixos têm "variáveis"que o usuário deve preencher.
Parágrafos livres: Alguns textos oferecem este tipo de parágrafo,que permite que o usuário inclua parágrafos com conteúdo que é totalmentelançado pelo usuário.
Quando todos os parágrafos do texto são concluídos, é possívelexibir a primeira retirada do documento antes de salvar os dados. Para isto,o botão 'Pré-visualização' pode ser ativado. Após verificar que todas as con-dições exibidas estão corretas, o dado é salvo através da ativação do botãode janela global 'Aceitar'.
Além disso, a impressão da documentação fixada na apólice ouendosso pode ser permitida de maneira centralizada e/ou distribuída. Demaneira alternativa ou adicional, a documentação pode ser enviada por faxe/ou e-mail, sem sair do pedido.
Administração de Competência (como parte da etapa: Novo negócio)
A administração de competência é uma função que estabelecelimites aos usuários quando contratam uma apólice, que cria uma cotação oumarcação de um endosso. O sistema pode gerar incidências de administra-ção de competência quando, durante o processo de criação de uma apólice,cotação ou endosso, o usuário realiza uma ação que excede as competên-cias as quais ele foi designado.
Como um exemplo, quando o usuário está desenvolvendo umaoperação de subscrição (apólice, endosso, etc.) e uma incidência relaciona-da a uma competência é gerada, a operação na pode ser emitida até que ascausas da incidência sejam corrigidas ou autorizadas. O processo pode serconcluído, uma vez que todos os erros foram autorizados. Uma modificaçãoque pode ser requerida refere-se ao motivo do erro (por exemplo, capital emexcesso). A emissão não será concluída até quaisquer erros não autorizadossejam modificados.
A administração de competência pode compreender as seguintes etapas:
I. Um usuário emite uma apólice com um capital maior do que ele é autorizado.
II. Uma incidência de administração de competência que é gera- da evita a emissão ser continuada.
III. Usando notas, a autorização é solicitada para o usuário res-ponsável ou para o usuário com nível de autorização adequado.
IV. O usuário pode ou não autorizar a emissão da apólice ou en-dosso através da operação de autorização de Apólice.
V. Usando notas, o usuário que estava desenvolvendo a opera-ção é informado se ele pode ou não continuar.Seleção de Saída (como parte da etapa: Novo negócio)
O método descrito pode permitir que a documentação ligada àapólice ou endosso seja impressão de uma maneira centralizada ou distribu-ida. Isto também permite que a documentação seja enviada por fax ou cor-reio eletrônico sem sair do pedido. Uma vez que o tipo de saída para umadocumentação específica foi selecionada, o processo de emissão irá termi-nar.
Etapa: Emissão
Um processo de emissão pode consistir em uma série de sub-processos comuns e outros subprocessos que serão executados de acordocom os parâmetros fornecidos. Os processos exemplificativos que são co-muns a todos os produtos e as etapas de emissão (novo negócio, endos-sos,...) podem ser:
Emissão de recibos e/ou
Consolidação de tabelas de novo negócio e/ou
Documentação
Os subprocessos exemplificativos que podem ser executados deacordo com os parâmetros fornecidos podem ser:De acordo com o produto e SBUAcidente: Lista de segurados e/ouEmpresas e SMEs: Folha PML /oudiversos: FIC.
De acordo com o movimento de cancelamento de etapa: FICO.
Etapa: Endossos
A criação de endossos pode permitir que modificações sejamincluídas na apólice ou em qualquer um de seus elementos ou entidades. Osendossos podem ser
Endossos não econômicos: o prêmio não é modificado e/ouendossos econômicos: envolvem uma modificação do prêmio. Osistema compara o prêmio a partir do movimento de base com o novo en-dosso. Se existem diferenças no prêmio, o endosso é um endosso econômi-co.
De preferência, o fluxo de um endosso é o mesmo que aquele deum novo negócio. Tipicamente, pode ser necessário identificar a razão portrás de uma modificação em um endosso. Uma tabela de corporação podelistar as razões e pode designar os valores de acordo com o produto de apó-lice. Dependendo da razão, certos campos de tela podem ser ativados oudesativados. Cada modificação na apólice cria uma nova versão, porém,nem todas as modificações envolvem um novo endosso. O tipo e a razão portrás da modificação irá determinar se a modificação gera um endosso ounão.
Um novo endosso será gerado se a modificação requer que odetentor da apólice receba a nova documentação. O sistema irá comparar osprêmios de movimento de base com aqueles do novo endosso. Qualquerprêmio diferencial irá resultar em um endosso econômico (oposto aos en-dossos não econômicos). Um endosso deve especificar uma razão identifi-cada para a modificação. Uma tabela de corporação lista as razões e desig-na os valores de acordo com o produto de apólice. As razões podem ativarou desativar certos campos de tela.
Data de efeito, o vencimento (em efeito, após a renovação deportfólio) ou data de endossos de cobertura de apólice endossos é permitida.
Se os endossos forem desejados para uma data antes daquela de outro en-dosso, eles devem ser fragmentados em tantas partes quanto existem ver-sões de apólice. Os endossos de extensão de apólice são permitidos paraapólice temporária. As seguintes etapas podem ser realizadas:
I. A emissão de uma nova apólice anual, por exemplo, Apólice1234567890 Versão 0 Endosso 0.
II. Se o detentor de apólice deseja incluir uma nova classe prê-mio, em efeito 1/06/2002, um endosso é operado em efeito 01/06/2002, porexemplo, Apólice 1234567890 Versão 1 Endosso 1.
III. Se um erro na comissão intermediária foi descoberto, 2 en-dossos são operados. O primeiro irá corresponder à versão 2 Endosso 1 e osegundo à Versão 3 Endosso 1.
IV. Se cliente deseja pagar por prestações em efeito a partir dopróximo ano, um endosso será operado no vencimento, que ocorre medianteuma renovação da apólice, por exemplo, Apólice 1234567890 Versão 4 En-dosso 2.
Um endosso é operado na última versão da apólice ou em qual-quer versão anterior. Quando operado na última versão, o movimento atuali-zado será aquele que existe atualmente no portfólio de apólice.
A classificação também é fixa na Fábrica de Produto. Os recibose rendimentos são emitidos com base nos resultados gerados pela fábrica. Oprêmio anual positivo é deduzido do prêmio pro rata negativo do movimentoanterior.
As modificações podem ser registradas em todos os casos, en-tretanto, aqueles além de seu nível de autorização não podem ser emitidos eficarão pendentes até a autorização ser fornecida a partir do nível adequado.A funcionalidade do sistema de autorizações é idêntica àquela que operapara o novo negócio.
Ao chamar a Fábrica de Produto, quando solicitar emissões deendosso, todas as validações de produto, competência e subscrição serãorealizadas. A Fábrica de Produto irá proporcionar os erros mediante os quaisa emissão pode ou não ser possível. Quando um endosso é emitido, os ajus-tes nas cessões de resseguro e cosseguro serão feitos se os resultados depedido de endosso em uma variação nas cessões. Um endosso não podeser emitido se as cessões permanecerem pendentes (resseguro facultativonão definido,)
Etapa: Manutenção de apólices pendentes
O estado de uma nova apólice ou de um endosso pode ser con-cluído ou pendente. Um movimento que ainda não foi emitido é um movi-mento pendente. A administração de apólice exemplificativa tem 2 bancos dedados: uma para as apólices completas e um para as apólices incompletas.A emissão de apólice pode registrada em um banco de dados de apólicesincompletas até a emissão ser concluída. Os dados consolidados, então,podem ser armazenados no banco de dados de apólices completos.
Quando um movimento em uma apólice existente é feito (porexemplo, um endosso) este pode ser armazenado no banco de dados deapólices incompletas, enquanto o número de apólice é mantido. O usuárioque deseja recuperar uma apólice por meio desta função deve ter atingido aetapa de controle de apólice. Se os usuários desistirem antes, a apólice nãopode ser recuperada. A apólice será bloqueada sempre que a mesma tiverum movimento pendente (por exemplo, um endosso não emitido) e irá per-manecer bloqueada até a emissão do movimento pendente ser concluída. Asapólices irão permanecer pendentes quando mostrarem erros de gerencia-mento de competência e até o erro ser autorizado. A apólice, então, serárecuperável a partir de manutenção de apólices pendentes.
Etapa: CancelamentoEsta função/etapa permite o cancelamento/anulação de uma a-pólice válida. As razões para a anulação são definidas para cada produ-to/objeto. Algumas razões são comuns a todos os produtos e outras são es-pecíficas, À medida que os motivos para o cancelamento podem variar.
Os cancelamentos de apólice são permitidos em qualquer datadentro da validade da apólice:
No caso de recibos pendentes, é possível cancelar as apólicescom ou sem retorno. No caso de cancelamento com retorno, a porção nãousada da apólice prêmio será reembolsada.
As apólices podem ser canceladas na data de vencimento. Nestecaso, nenhum prêmio é reembolsado e a apólice retém sua cobertura - parapropósitos de reivindicações - ao longo de sua validade e sem transferênciapara o portfólio.
Uma vez que todos os dados da apólice cancelável identificadaforam lançados, a mesma pode ser diretamente cancelada ou os dados declassificação de movimento podem ser acessados a fim de se obter qualquerquantia de retorno existente. Finalmente, todos os documentos de cancela-mento são gerados.
De maneira vantajosa, o método acima proporciona capacidadesde reescrita "fora da caixa". Esta funcionalidade pode incluir a capacidade deter uma nova apólice (substituição) subscrita no lugar de uma apólice antiga(aquela que é substituída). O processo pode envolver anulações através dosusuários (cancelamento da apólice que é substituída) e/ou novo negócio(subscrição de uma apólice de substituição).
Etapa: Reintegração
As reintegrações permitem que as apólices previamente cance-ladas tenham suas validades restabelecidas. As apólices podem ser concluí-das, validadas e registradas a fim de serem restabelecidas. A data de reinte-gração geralmente é a mesma que a do cancelamento efetivo da apólice,porém a mesma pode ser em um período posterior.
A reintegração pode envolver o pagamento de lucros, a restau-ração de resgates ou o pagamento de interesse através do retentor de apóli-ce, a fim de restabelecer a apólice na mesma condição em que a mesma foicancelada. Em todos estes casos as validações necessárias podem ser rea-lizadas, assim como as classificações (Fábrica de Produto) para a avaliaçãodo novo prêmio.
O processo de restabelecimento de apólice também pode seracompanhado por modificações de apólice. Estas modificações podem serfeitas na mesma operação de restabelecimento sem quaisquer endossosadicionais.
Finalmente, todos os documentos de restabelecimento (notas derestabelecimento, recibos, etc.) são emitidos e enviados.Etapa: Triagem de Apólice
A triagem de Apólice permite que o portfólio de apólice seja revi-sado com base na freqüência de acidentes e critérios de rentabilidade nega-tiva. Uma análise de processo em lote das apólices de portfólio pode ser rea-lizada com base nas tabelas/critérios predefinidos, que levam a detecção denecessidades de reorganização. O sistema, então, gera um (suporte) bancode dados de apólices que precisa de retificação com seus critérios de retifi-cação correspondentes, e designa uma solução proposta genérica. Os usuá-rios analisam a partir do banco de dados cada apólice individual e propõemedidas de retificação específicas para cada uma delas.
Uma vez que as apólices com necessidade de retificação sãodetectadas, os usuários podem informar o cliente/intermediário da decisãode saneamento definitiva a ser executada:
Manutenção: A apólice mantém seu estado atual por diversasrazões, por exemplo: bom desempenho global de cliente, reivindicações, etc.
Correção: Um endosso na apólice real é criado modificando-sealguns de seus detalhes, por exemplo: aumento de prêmios, alteração decondições de cobertura, etc.
Cancelamento: O sistema irá cancelar a apólice automaticamen-te, uma vez que a triagem de apólice é concluída e a decisão de cancela-mento é tomada. Todo mês um processo em lote cancela todas as apólicesque os usuários decidiram cancelar.Etapa: Portfólio
Renovação de Portfólio Manual (como parte da etapa: Portfólio)
Esta função permite a renovação de apólice manual, sem serincluída no processo de portfólio automático. Os usuários podem selecionaraquelas apólices que eles desejam renovar em uma base individual. Os usu-ários podem selecionar e/ou ajustar os prêmios a serem renovados. Todosos tipos de modificações são permitidos: alteração de taxa, cancelamento declasse prêmio, etc. Além do recibo, o sistema irá emitir o endosso corres-pondente através da ligação com o processo de endossos. Se a modificaçãofoi registrada antes do processo de portfólio, ou seja, porque existe o endos-so futuro (efetivo na data de vencimento de apólice), o usuário precisa ape-nas decidir sobre a renovação de condições registradas.
O portfólio manual não realiza a atualização como no processode renovação automática, tais como, bônus/alteração de penalidade de nível,ações de renovação de portfólio, avaliação de somas ou seguradas ou prê-mios, etc.
Renovação de Portfólio Automática (como parte da etapa: Portfólio)
O processo de portfólio é um processo de renovação mensal pa-ra todas as apólices que vencem no mês específico (parâmetros estabeleci-dos pelo produto), geralmente no mês seguinte do processo.
O processo envolve
a atualização de intermediários, penalidade bônus, avaliação erenovação de portfólio e/ou
a classificação dos prêmios da próxima anuidade e/oua emissão da apólice com novas datas de renovação e/ou
a impressão das notas de vencimento.Seleção de Apólice (como parte da etapa: Portfólio/Renovação de Portfólio)
A validação de Fábrica de Produto para produtos com apólicesde renovação automática. As apólices selecionadas podem serem vigor e/ou
com a data de expiração conforme mostrada no parâmetro e/oucom renovação automática.A apólice é marcada com um aviso para os usuários de que arenovação se encontra em andamento. A apólice é bloqueada e nenhummovimento pode ser feito.
Atualização de valor (como parte da etapa: Portfolio/Renovação de Portfólio)
Esta etapa pode compreender uma ou mais:
Atualizações Intermediárias e/ou
Penalidade Bônus e/ou
Ações de renovação de portfólio e/ou
Avaliação e/ou
Renovação de datas.
Classificação (como parte da etapa: Portfolio/Renovação de Portfólio)
As apólices prêmio são obtidas na próxima anuidade, após osvalores serem estimados pela Fábrica de Produto executável. Alguns produ-tos têm um prêmio mínimo definido na base das seguintes opções:
Prêmio mínimo por apólice e/ou
Prêmio mínimo por objeto e/ou
Prêmio mínimo por classe prêmio e/ou
Prêmio mínimo combinado (por objeto e classe prêmio).
Para as apólices que não excedem o prêmio mínimo, a diferençaentre todas as apólices prêmio serão divididas (proporcionais aos seus prê-mios), ou sua totalidade será aplicada à primeira classe prêmio, as conformeindicado pelo Fábrica de Produto.
Emissão de Apólice/Apólices (como parte da etapa: Portfolio/Renovação dePortfólio)
Este é um processo de validação e consolidação (tanto paraapólices completas como para apólices incompletas) da atualização de da-dos da renovação de apólice. Uma série de rotinas em uma estrutura modu-lar é requerida para o processo de emissão. Cada rotina fica encarregada davalidação ou consolidação.
A mesma também inclui dois módulos adicionais que
Estimam as comissões intermediárias e/ou
Lançam dados de apólice na interface de recibos.Emissão de Apólice/Green Cards (como parte da etapa: Portfólio/Renovaçãode Portfólio)
O coletor intermediário do primeiro recibo define a inclusão dogreen card na renovação de portfólio.
Emissão/Recibos de Apólice (como parte da etapa: Portfólio/Renovação dePortfólio)
Um modelo de dados de recibos é concluído com os dados for-necidos pela interface. Os pagamentos são fracionados em trimestres, se-mestres ou pagamentos anuais únicos, conforme indicados na apólice.
Os seguintes recibos são emitidos:
Pagamentos anuais e/ou
Primeiro pagamento trimestral ou semestral e/ou
Pagamentos sucessivos de apólices previamente expiradas quevencem no mês atual.
O restante dos recibos é mantido como 'Emissão Pendente'. Umarquivo Postscript (*.ps) é criado para armazenar todas as informações emrecibos emitidos e serem redirecionadas para a impressora central da em-presa. Para a facilidade de distribuição, a informação é classificada por escri-tório e intermediário.
Notas de Vencimento (como parte da etapa: Portfólio/Renovação de Portfó-lio)
O processo pelo qual toda a informação é coletada para comple-tar as notas de vencimento. A nota informa o cliente dos prêmios aplicadosna renovação de apólice.
Reconciliação (como parte da etapa: Portfólio/Renovação de Portfólio)
O processo extrai todos os dados atualizados no processo derenovação de apólice automática e transfere os mesmos para um arquivoExcel. O arquivo mostra uma falha através de SBU da seguinte informação:
Apólices renovadas totais e/ou
Total faturado e/ou
Total faturado para pagamentos de emissão pendentes devidosno mês atual e/ouPorcentagem de comissões de Intermediários sobre o fatura-mento total e/ou
Total de prêmios para cosseguro.
Uma lista de apólices não renovadas acompanhadas por umarazão para tal:
Canceladas e/ou
Não renováveis e/ou
Bloqueadas no início do processo devido a um movimento feitodurante a seleção e/ou
Erro durante o processo (um código de erro de identificação euma descrição são exibidos).
Pré-Renovação de Portfólio (como parte da etapa: Portfólio)
A pré-renovação de portfólio é lançada um mês ou dois mesesantes da renovação de portfólio para os produtos que requerem a mesma. Oprocesso de pré-renovação é lançado dois meses antes do vencimento deapólice que cobre o seguinte:
A mesma atualiza os valores de apólice e avalia os prêmios parao próximo período e/ou
Bônus/Penalidade, Soma segurada, Atualizações Automatizadase Outros Processos Automatizados (descontos e cobranças extras) e/ou
A mesma processa as notas de vencimento, mas, não emite omovimento e/ou
Este processo congela as apólices durante sua execução (ape-nas as cotações de renovação podem ser feitas nesta apólice, entretanto, asapólices pode ser manualmente descongeladas por um usuário autorizado).
Como um exemplo, a empresa envia informação sobre a renova-ção de apólice para o cliente, a fim de informá-lo das novas condições derenovação ou do cancelamento do contrato (devido a emissões de reivindi-cações). Posteriormente, as cotações baseadas na pre-renovação podemser feitas.
O método acima também pode compreender uma etapa relacio-nada a comissões.Etapa: Comissões
As comissões podem ser designadas para realizar uma ou maisdas seguintes etapas e/ou compreender um ou mais dos seguintes recur-sos/efeitos:
Recuperar os valores de tabela a partir do modulo de canais deDistribuição (produto - classe prêmio, grupo de afinidade, agente, etc).Manualmente dentro de limites pré-definidos.Distribuição de comissionamento entre diferentes agentes dentrode limites pré-definidos.
Diferentes níveis de comissão podem ser configurados depen-dendo
das primeiras anuidades e sucessivas e/ouda função do agente, produtor ou coletor.
Adicionalmente, o método acima pode permitir e/ou compreenderuma ou mais:
Uma tela de resultado de classificação como uma GUI específicapode ser proporcionada, que permite a exibição das quantias de prêmio,descontos, sobretaxas e/ou taxas na apólice, objeto e/ou nível de classeprêmio.
O período de prestação e os sucessivos são determinados, deacordo com ambas as formas de pagamento, e a informação proporcionadapela Fábrica de Produto
Os detalhes dos prêmios resultantes são disponíveis através doobjeto ou classe prêmio.
No caso de classificação manual ou semi-automática de um pro-duto, isto pode ser feito nas telas de administração de Apólice.
Programas principais
As seguintes etapas do processo de emissão apólice são resu-midas:
De apólice completa à incompleta
Os movimentos de Novo Negócio, endossos e restabelecimentossão feitos pelo programa KCILMS01. No caso de cancelamentos, os mes-mos são feitos pelo programa KCILMM03.
Entrada de dados
A entrada de dados é realizada pelos programas para obter in-formação da apólice em um nível de apólice (KCILMQ03), objeto(KCILMB03) e classe prêmio (KCILMD03). Os programas para modificar estainformação são KCILMQ02 (dados de apólice geral), KCILMQ04 (dados adi-cionais), KCILMB04 (objeto) e KCILMD04 (classe prêmio). Estes membrosusam o programa KCILMZ06 para chamar a Fábrica de Produto executávelpara validar todos os dados com as especificações de produto, para introdu-zir o gerenciamento de competência, etc.
Validação/Classificação
Uma vez que a validação é feita em cada nível (apólice, objeto,classe prêmio), o sistema chama novamente o executável para fazer umavalidação geral em todos os níveis (isto é feito pelo programa KCILMZ06 no-vãmente). Após as validações de dados o produto executável é usado no-vamente para classificar (obter o prêmio). Finalmente, existe uma chamadado Programa de Prestação (KCILMZ00), para dividir o prêmio em cada umdos recibos resultantes, de acordo com ambas as formas de pagamento se-lecionadas no prêmio anual de um movimento e na informação proporciona-da pela Fábrica de Produto.
Emissão de Apólice
O processo de emissão valida e consolida todos os dados intro-duzidos que alteram o estado da apólice de incompleta para completa. Oprocesso é iniciado pelo programa KCILMQ05 que chama dinamicamentediversos subprogramas que dependem do produto, do movimento e de ou-tros parâmetros.
Uma ou mais das seguintes tarefas pode ser compreendida noprocesso de emissão:
Validação dos parágrafos e/ou emissão de recibo e/ou ressegu-ro, etc. com a Fábrica de Produto.
Realizar operações adicionais (calcular comissões e/ou compo-sição cláusula, etc).Consolidar a apólice com todas as quitações. Este processo éfeito pelo KCILMZ05.
Proporcionar/gerar interfaces de resseguro e/ou cosseguro.
Processo Econômico Relacionado, tal como, emissão de recibo.
De maneira vantajosa, a Fábrica de Produto é completamenteintegrada com a administração de Apólice, de modo que alterações feitas nocriador dos produtos sejam prontamente disponíveis para os usuários. Moreespecificamente,
a estrutura de produto é definida na Fábrica de Produto. O pedi-do de administração de apólice é capaz de interpretar o mesmo e adaptar astelas, tais como, a GUI mostrada nas figuras 28 e 29 e os bancos de dados,a fim de armazenar a informação requerida, sem a necessidade de um co-nhecimento destas;
as validações de produto e a ação a ser tomada quando ocorremincidentes são definidas na Fábrica de Produto e a administração de apóliceapresenta a mensagem de erro apropriada que pode ser definida na Fábricade Produto para o usuário;
os cálculos podem ser definidos na Fábrica de Produto e o dadofinanceiro é salvo em um banco de dados de informação econômica, a partirdo qual a administração de apólice mostra os resultados detalhados para ousuário.
A figura 31 é uma visão geral esquemática de como a Fábrica deProduto e a administração de apólice são integradas uma à outra. Conformepode ser visto, a estrutura de um contrato/apólice é diretamente ligada à es-trutura de produto, conforme definido na Fábrica de Produto. Um contratopode ser um grupo de apólices que pode ser agrupado em diferentes níveis.Principalmente, estes agrupamentos podem ser usados para agrupar a e-missão de recibos e gerar relatórios e estatísticas agregadas. Os agrupa-mentos de divisão e subdivisão nas políticas de contrato são opcionais. Asapólices de um contrato podem ser diretamente agrupadas com o contrato.
Os objetos de risco disponíveis e as garantias (Classe prêmio naterminologia presente) são aqueles definidos na Fábrica de Produto sob oproduto que a apólice se baseia. Em outras palavras, o método descrito aci-ma, permite de maneira vantajosa o gerenciamento de todas as aquisiçõesde novo negócio e necessidades de manutenção de portfólio de apólice deuma empresa de seguro, de acordo com as regras predefinidas na Fábricade Produto
Em particular, as transações de negócio mais comuns podem serincluídas:
Cotações e/ou
Novo negócio e/ou
Endossos e/ou
Renovações e/ou
Cancelamento e/ou
Restabelecimentos e/ou
Declarações e/ou
Saneamento de Apólice e/ou
Gerenciamento de Competência e/ou
Outros...
A figura 32 mostra um modelo conceituai de uma visão geral dearquitetura técnica 200 para implementar o método descrito acima. Conformemostrado, a arquitetura de usuário 202 proporciona usabilidade e interação.A arquitetura de aplicações 204 representa uma visão integrada dos siste-mas para solucionar problemas de negócios. A arquitetura de desenvolvi-mento 206 proporciona/define um ou mais dentre o seguinte:
Metodologia
Padrões
Procedimentos
Ferramentas.
A arquitetura de operações 208 proporciona/define um ou maisdentre o seguinte:
Suporte de Operações
Segurança
Disponibilidade.A arquitetura de dados 210 proporciona/define um ou mais den-tre o seguinte:
Definição
Visões lógicas e físicas
Administração.
A arquitetura de execução 212 proporciona/define um conjuntode módulos e/ou programas e/ou objetos e/ou APIs que podem isolar os as-pectos técnicos.
A arquitetura de impressão 214 proporciona/define um conjuntode ferramentas e/ou procedimentos para gerenciar e imprimir facilidades.
A seguir, como uma visão geral, a estrutura repositória e estrutu-ra de tabela serão descritas, à medida que podem ser aplicadas de acordocom o método/sistema descrito neste pedido.
De acordo com o presente pedido, na Administração de Apólice,os valores são dinamicamente armazenados, o que significa que dependemde como os elementos foram definidos no produto, eles podem ser armaze-nados (dentro do mesmo banco de dados) em um campo ou em outro.
Isto retrata o banco de dados de Administração de Apólice com aflexibilidade para ELEMENTOS ADICIONAIS (aqueles definidos no Nível deApólice, Nível de Objeto e Nível de Cobertura), porque o mesmo permite oaumento ou redução do número de elementos adicionais a ser implementadoem cada cliente sem afetar o banco de dados. Portanto, uma vez que a es-trutura repositória é definida, os elementos adicionais podem ser incluídos norepositório sem alterar a estrutura do repositório.
O seguinte exemplo tem para o propósito de ilustrar como osvalores lançados para os elementos adicionais (no nível de apólice, nível deobjeto e/ou nível de cobertura) são armazenados no banco de dados de Ad-ministração de Apólice:
Uma vez que o produto, isto é, o conjunto de arquivos executá-veis interrelacionados é gerado, na tabela KTPA82T todas as designaçõesde elemento são armazenadas, isto é, a KTPA82T define/incorpora o localfísico exato em que o valor dos elementos será armazenado dentro das tabe-Ias de Administração de Apólice. Nesta tabela TODOS os vetores relaciona-dos a TODOS os níveis são armazenados. Portanto, antes de recuperarqualquer valor para um certo elemento, é obrigatório acessar esta tabela afim de conhecer o local físico em que os valores se situam. No(s) exemplo(s)a seguir para cada nível são descritos:
ELEMENTO DE APÓLICE ADICIONAL:
KTPA82T: O banco de dados com a designação de elemento. Oexemplo a seguir mostra como o dito banco de dados pode ser acessadopara recuperar o vetor para um elemento no nível de apólice. No caso, o va-lor para um elemento exemplificativo CDPOSTCO (código postal) deve serrecuperado. O banco de dados pode compreender a seguinte entrada:
CDPRODTE CDPRODCO CDOBJTP CDMCT CDELEME NOCAMPFI NURELREC
MOTOR MOTOR_1 000000000 00000000 CDPOSTCO TXCAOP1 1
Então, com NOCAMFI=TXCAOP1 e NURELREC=1, as seguin-tes tabelas são acessadas:
KCIM52T (Incompleta)KCIM16T (Completa).
Estas tabelas KCIM52T e KCIM16T são exatamente as mesmase dependem se uma apólice emitida (complete) ou uma apólice não emitida,que está pendente (incompleta) é trabalhada. Portanto, KCIM16T ouKCIM52T são acessadas, respectivamente, porém, as tabelas serão acessa-das do mesmo modo, à medida que ambas são tabelas idênticas.
A fim de acessar e recuperar o valor, a informação é recuperadaa partir dos seguintes campos (NURELREC=1 significa que para uma faixade registros encontrada, apenas a primeira será selecionada, isto é, apenasa primeira linha será usada):
CDNUMPOL CTVRSPOL.......... TXCAOP1 TXCAOP2
99788888801 1 VALOR 1 0000000
99788888801 1 VALOR 2 0000000
99788888801 2 VALOR 3 0000000
Então, "VALOR 1" é o valor especifico para o elemento CDPST-CO.Usando a terminologia do exemplo acima, a estrutura repositóriapode compreender o banco de dados KTPA82T. Os elementos repositóriospodem ser as linhas definidas acima:
CDPRODTE CDPRODCO CDOBJTP CDMCT CDELEME NOCAMPFI NURELRECMOTOR MOTOR_1 000000000 00000000 CDPOSTCO TXCAOP1 1
As tabelas KCIM52T e KCIM16T podem ser compreendidas pelaestrutura de tabela.
ELEMENTO DE OBJETO ADICIONAL:
KTPA82T: O banco de dados com a designação de elemento. Oexemplo a seguir mostra como o dito banco de dados pode ser acessadopara recuperar o vetor para um elemento no nível de apólice. No caso, o va-lor para um elemento exemplificativo CDLOCAT (localização) deve ser recu-perado. O banco de dados pode compreender a seguinte entrada:
CDPRODTE CDPRODCO CDOBJTP CDMCT CDELEME NOCAMPFI NURELRECMOTOR MOTOR_1 000005000 00000000 CDLOCAT IMCAOP1 3
Então, com NOCAMFI=IMCAOP1 e NURELREC=3, as seguintestabelas são acessadas:
KCIM54T (Incompleta)KCIM18T (Completa).
Estas tabelas KCIM54T e KCIM18T são exatamente as mesmase dependem se uma apólice emitida (complete) ou uma apólice não emitida,que está pendente (incompleta) é trabalhada. Portanto, KCIM18T ouKCIM54T são acessadas, respectivamente, porém, as tabelas serão acessa-das do mesmo modo, à medida que ambas são tabelas idênticas.
A fim de acessar e recuperar o valor, a informação é recuperadaa partir dos seguintes campos (NURELREC=3 significa que para uma faixade registros encontrada, apenas a primeira será selecionada, isto é, apenasa terceira linha será usada):
CDNUMPOL CTVRSPOL .......... IMCAOP1 IMCAOP2
99788888801 1 VALOR 1 0000000
99788888801 1 VALOR 2 0000000
99788888801 2 VALOR 3 0000000Então, o "VALOR 3" é o valor específico para o elemento C-DLOCAT.
ELEMENTO DE COBERTURA ADICIONAL:
KTPA82T: O banco de dados com a designação de elemento. Oexemplo a seguir mostra como o banco de dados pode ser acessado pararecuperar o vetor para um elemento no nível de apólice. No caso, o valorpara o elemento IMLIMIT (Quantia Limite) deve ser recuperado. O banco dedados pode compreender a seguinte entrada:
CDPRODTE CDPRODCO CDOBJTP CDMCT CDELEME NOCAMPFI NURELRECMOTOR MOTOR_1 000005000 00000000 IMLIMIT IMCAOP5 2
Então, com NOCAMFMMCAOP5 e NURELREC=2, as seguintestabelas são acessadas:
KCIM53T (Incompleta)
KCIM23T (Completa).
Estas tabelas KCIM53T e KCIM18T são exatamente as mesmase dependem se uma apólice emitida (complete) ou uma apólice não emitida,que está pendente (incompleta) é trabalhada. Portanto, KCIM23T ouKCIM53T são direcionadas, respectivamente, porém, as tabelas serão aces-sadas do mesmo modo, à medida que ambas são tabelas idênticas.modo, à medida que ambas são tabelas idênticas.
A fim de acessar e recuperar o valor, a informação é recuperadaa partir dos seguintes campos (NURELREC=2 significa que para uma faixade registros encontrada, apenas a primeira será selecionada, isto é, apenasa segunda linha será usada):
CDNUMPOL CTVRSPOL... IMCAOP1 IMCAOP2 IMCAOP3 IMCAOP4 IMCAOP5
99788888801 1 0000000 0000000 .......... ......... VALOR 1
99788888801 1 0000000 0000000 .......... ......... VALOR 2
99788888801 2 0000000 0000000 .......... ......... VALOR 3
Então, "VALOR 2" é o valor específico para o elemento IMLIMIT.
Uma visão geral esquemática dos processos e inter-relações,para gerar documentos e para distribuir impressão, é mostrada na figura 33.
Dado o que foi dito acima, os seguintes princípios de projeto po-dem ser aplicados e realizados:
• Arquitetura de múltiplos canais em 3 filas.
• Arquitetura "baseada em "Componente": aplicação de princípios de in-tegração de aplicação de empreendimento para inter-componentes.
• Portabilidade: a camada de serviços protege a aplicação a partir da im-plementação de software subjacente.
• Múltiplas linguagens (Interface de usuário e toda saída de documentoo), múltiplas moedas, múltiplas empresas.
• Geração de Documento Central & arquitetura de publicação flexível(centralmente & distribuída, on-line & em lote).
Uma visão geral exemplificativa de um possível sistema em 3filas é mostrada na figura 34, que mostra os elementos específicos da arqui-tetura em 3 filas e sua conexão.
A Tabela 1 proporciona de maneira exemplificativa uma visãogeral de uma implementação específica que lista os componentes usados.Outra configuração técnica que pode ser possível, pode ser baseada em di-ferentes plataformas. Os componentes opcionais podem ser substituídospelos componentes e/ou interfaces de aplicação existentes. Na tabela 1, sãousados os tempos que podem ser marcas registradas de terceiros.
<table>table see original document page 94</column></row><table>Na figura 35, mostra-se uma visão geral 300 de uma arquiteturatécnica que compreende particularmente a relação de componentes especí-ficos da arquitetura. Como um exemplo, um cliente HTML 302 e um clienteJava 304 são proporcionados. O cliente HTML 302 compreende uma esta-ção de trabalho de cliente 306. O cliente Java 304 compreende uma estaçãode trabalho de cliente 308. A estação de trabalho de cliente 306 do clienteHTML 304 pode ser conectada a um servidor web 310 e/ou um servidor deaplicação 312. O servidor web 310 pode ser adaptado para chamadas depreender lógica de edição básica e/ou lógica de navegação. O servidor web310 também pode ser adaptado para gerar apresentações. Se aplicável, omesmo também pode requerer o servidor de aplicação 312. Além disso, oservidor de aplicação 312 pode ser adaptado para receber e/ou armazenare/ou gerar dados de referência duplicados. Se aplicável, este também poderequerer o servidor web 310. Este pode ser particularmente o caso, se o ser-vidor web 310 e o servidor de aplicação 312 forem combinados em uma en-tidade.
O servidor de aplicação 312 é conectado a um servidor de inte-gração 314. O servidor de integração 314 pode compreender lógica de inte-gração. Se aplicável, o servidor web 312 também pode ser conectado aoservidor de integração 314. O servidor de integração pode ser conectado aum ou sistemas de legado 316. Cada sistema de legado 316 pode compre-ender lógica de negócio de legado.
A estação de trabalho de cliente 308 do cliente Java 304 é co-nectada a um anfitrião 318. O anfitrião pode compreender um ou mais dosseguintes componentes de lógica:
Lógica de ediçãoLógica de negócioLógica de acesso de dadosLógica de interfaceLógica de lote.
Além disso, o anfitrião 318 pode receber e/ou armazenar e/ougerar dados de transação e/ou dados de referência.
A seguir, os elementos, conforme mostrado na figura 35, sãodescritos em detalhes adicionais:
ANFITRIÃO: Este representa o computador central. No anfitrião,todo o banco de dados pode ser definido e todas as lógicas de negócio im-plementadas em programas cobol podem permanecer. Estes programas po-dem acessar os bancos de dados para atualizar e/ou manter os dados quetambém podem ser usados para fazer cálculo, etc.
SERVIDOR DE APLICAÇÃO Canelas, UNIX...): Neste ambienteuma lógica de Cliente Magro pode ser executada. Em outras palavras, o ser-vidor de aplicação define a localização para manter a ordem na qual as pági-nas da web devem ser lançadas. Esta aplicação pode ajustar a ordem naqual as telas aparecem ou ainda a necessidade de aparecerem.
SERVIDOR WEB: É o servidor que permite o fornecimento depáginas físicas para o servidor de aplicação. O servidor de aplicação (base-ado na ordem) pode solicitar as paginas para o servidor web que é o prove-dor destas páginas.
ESTAÇÃO DE TRABALHO DE CLIENTE: Isto é, o PC a partir doqual o usuário pode acessar o sistema, de acordo com o presente pedido. Omesmo pode ser o terminal a partir do qual alguém deseja se registrar nodito sistema, por exemplo, para executar um ou mais arquivos executáveis apartir do conjunto de arquivos executáveis através da GUI descrita acima.
SERVIDOR DE INTEGRAÇÃO & SERVIDOR DE LEGADO: Emalguns casos alguns clientes podem desejar manter seus dados de legadonão integrados com o sistema acima, de acordo com o presente pedido,mas, armazenados em um servidor diferente que é chamado de SISTEMASDE LEGADO. Então, através de um servidor de integração os dados arma-zenados no sistema de legado podem ser recuperados e enviados para oservidor de aplicação, quando necessário.
A figura 36 proporciona uma visão geral da arquitetura técnicapara a geração de interface automática. A arquitetura de execução mostradaproporciona um mecanismo de geração automática para muitos, particular-mente, todos os componentes que interferem no início de comunicação apartir de uma IDL (Linguagem de Definição de Interface). De maneira vanta-josa, esta geração automática permite que as aplicações tenham que lidarcom a definição das mensagens de entrada e/ou saída em um dicionário dedados, porém, não com a sua geração física (em forma de código).
A seguir, conforme mostrado na figura 36, os elementos sãodescritos em detalhes adicionais. Em particular, a figura 36 mostra como aEXTREMIDADE ANTERIOR comunica DADOS para a EXTREMIDADEPOSTERIOR. Em outras palavras, e usando um exemplo, a extremidadeanterior sob a forma de uma estação de trabalho pode ser um banco. Umusuário da estação de trabalho pode receber e lançar uma deman-da/solicitação de empréstimo. A extremidade posterior pode ser representa-da pelas operações que são feitas, por exemplo, no departamento adminis-trativo, a fim de determine se o banco aprova o empréstimo ou não. Então,de acordo com a visão geral esquemática mostrada na figura 36, os termosusados podem ser definidos da seguinte maneira:
ESTAÇÃO DE TRABALHO: O PC a partir do qual o usuário podeacessar as telas, isto é, a GUI/GUIs, conforme descrito neste pedido. O usu-ário pode usar a(s) tela(s) AIS para enviar e processar dados (situados noscampos) ao longo das classes.
CLASSE EXTERNA: Uma faixa de campos (dados) que são en-viados para o MIDDLEWARE para serem processados pelos programas.
CLASSE INTERNA: Uma faixa de campos (dados) que são re-cebidos pelo MIDDLEWARE (geralmente cálculos ou resultados de acessoaos bancos de dados) que são previamente enviados pelos arquivos execu-táveis, que podem ser programas cobol a serem exibidos nas telas.
STUB: Ordens a partir das quais os campos são empacotadospara serem enviados.
MIDDELEWARE: Software que comunica os dados enviadosatravés das telas, isto é, a GUI para a extremidade posterior, em outras pa-lavras, o software que comunica os dados lançados nas telas com o progra-mas situados no computador central. O mais usado é a CTG (PORTA DETRANSAÇÃO CICS).
OS390: O computador central ou o anfitrião onde todos os pro-gramas e bancos de dados são situados.
BANCO DE DADOS: A estrutura de dados onde todas as infor-mações relacionadas às telas e/ou resultados de cálculos são armazenadas.
ROTINA DE ACESSO DE DADOS: Os arquivos executáveis, taiscomo, programas COBOL onde permanece toda a lógica de negócio sobre aaplicação.
CÓPIA EXTERNA: Similar, ainda exatamente as mesmas que asClasses Java, porém, para COBOL. Em outras palavras, esta pode ser a fai-xa de campos que são enviados para o middleware a fim de serem enviadospara a tela e/ou podem ser o resultado de algum cálculo e/ou acesso de pro-grama.
CÓPIA INTERNA: O mesmo que "CÓPIA EXTERNA", porém, aoinverso. Isto representa a faixa de dados que é recebida para os programascobol a fim de realizar algum cálculo e/ou acesso de programa.
ESQUEMA: Similar, ainda o mesmo que STUB, que é a ordem apartir da qual os campos são empacotados para serem enviados.
A fim de verificar que o processo/método descrito acima podeser realizado de maneira apropriada, a definição das CLASSES e dosCOPYBOOKS deve combinar, em particular, deve combinar exatamenteuma com a outra. Portanto, proporciona-se um dicionário de dados, que éum banco de dados onde todos os campos são definidos (tais como, com-primento, formato, etc...). A partir deste ponto existe um processo chamadoIDL que gera automaticamente em formato e comprimento idênticos de Clas-ses Java e Cópias Cobol, a fim de garantir a coerência. De maneira vantajo-sa, ao usar isto, o programador não precisa gerar manualmente os ditos for-matos idênticos.
Geralmente, quando o método descrito acima é executado, àmedida que o nome de usuário e a senha de serviço de segurança são au-tenticados, permitindo o acesso ao sistema. O sistema pode recuperar o per-fil de segurança do usuário, que define quais funções o usuário pode aces-sar. As funções podem definir o acesso necessário para abordar a funciona-lidade de negócio, tais como
acesso aos cenários: áreas de procedimentos de negócio e/oucontrole de acesso: botões de acesso para as janelas ou servi-ços específicos e/ou
acesso aos recursos lógicos: para desativar /ativar o acesso àstabelas específicas
Acessos (consulta & modificação) e parâmetros de competênciasão ajustados seguindo as estruturas de negócio (papéis e localização).
Além do que foi dito acima, a geração automática de diferentespacotes de aplicação em diversas linguagens fora de uma única versão docódigo de aplicação pode ser proporcionada.
Referindo-se à figura 37, um sistema exemplificativo para imple-mentar a invenção inclui um dispositivo de computação de propósito geralsob a forma de um ambiente de computação convencional 20 (por exemplo,computador pessoal), que inclui uma unidade de processamento 22, umamemória de sistema 24 e um barramento de sistema 26 que acopla várioscomponentes de sistema incluindo a memória de sistema 24 na unidade deprocessamento 22. A unidade de processamento 22 pode realizar operaçõesaritméticas, lógicas e/ou de controle ao acessar a memória de sistema 24. Amemória de sistema 24 pode armazenar informações e/ou instruções parauso em combinação com a unidade de processamento 22. A memória desistema 24 pode incluir memória volátil e não volátil, tais como, memória deacesso aleatório (RAM) 28 e memória somente leitura (ROM) 30. Um siste-ma de entrada/saída básico (BIOS) que contém as rotinas básicas que aju-dam a transferir informações entre os elementos dentro do computador pes-soal 20, tal como, durante a inicialização, pode ser armazenado na ROM 30.O barramento de sistema 26 pode ser qualquer um entre diversos tipos deestruturas de barramento que incluem um barramento de memória ou contro-lador de memória, um barramento periférico e um barramento local que usaqualquer uma entre uma variedade de arquiteturas de barramento.
O computador pessoal 20 pode incluir adicionalmente um drivede disco rígido 32 para ler e escrever em um disco rígido (não mostrado), eum drive de disco externo 34 para ler ou escrever em um disco removível 36.
O disco removível pode ser um disco magnético para um driver de discomagnético ou um disco óptico, tal como um CD ROM para um drive de discoóptico. O drive de disco rígido 34 e o drive de disco externo 34 são conecta-dos ao barramento de sistema 26 através de uma interface de drive de discorígido 38 e uma interface de drive de disco externo 40, respectivamente. Osdrives e seus meios legíveis por computador associados proporcionam ar-mazenamento não volátil de instruções legíveis por computador, estruturasde dados, módulos de programa e outros dados para o computador pessoal20. As estruturas de dados podem incluir dados relevantes da implementa-ção do método, conforme descrito em mais detalhes acima. O dado relevan-te pode ser organizado em um banco de dados, por exemplo, um banco dedados relacionai ou de objeto.
Embora o ambiente exemplificativo descrito no presente docu-mento empregue um disco rígido (não mostrado) e um disco externo, deveser avaliado por aqueles versados na técnica que outros tipos de meios legí-veis por computador que podem armazenar dados que são acessíveis porum computador, tais como, fitas magnéticas, cartões de memória flash, dis-cos de vídeo digital, memórias de acesso aleatório, memória somente leitura,e similares, também podem ser usados no ambiente de operação exemplifi-cativa.
Inúmeros módulos de programa podem ser armazenados no dis-co rígido, disco externo, ROM 30 ou RAM 28, incluindo um sistema de ope-ração (não mostrado), um ou mais programas de aplicação 44, outros módu-los de programa (não mostrados) e dados de programa 46. Os programas deaplicação podem incluir pelo menos uma parte da funcionalidade, conformedetalhado nas figuras 1 a 36.
Um usuário pode lançar comandos e informações, conforme dis-cutido abaixo, no computador pessoal 20 através de dispositivos de entrada,tais como, um teclado 48 e mouse 50. Outros dispositivos de entrada (hãomostrados) podem incluir um microfone (ou outros sensores), vídeo game,controle de jogo, digitalizador, ou similares. Estes e outros dispositivos deentrada podem ser conectados à unidade de processamento 22 através deuma interface de porta em série 52 que é acoplada ao barramento de siste-ma 26, ou podem ser coletados por outras interfaces, tal como, uma interfacede porta paralela 54, porta de jogo ou um barramento serial universal (USB).Ademais, as informações podem ser impressas usando a impressora 56. Aimpressora 56 e outros dispositivos de entrada/saída paralelos podem serconectados à unidade de processamento 22 através da interface de portaparalela 54. Um monitor 58 ou outro tipo de dispositivo de tela também é co-nectado ao barramento de sistema 26 através de uma interface, tal comouma entrada/saída de vídeo 60. Além do monitor, o ambiente de computação20 pode incluir outros dispositivos de saída periféricos (não-mostrados), taiscomo, altofalantes ou outra saída audível.
O ambiente de computação 20 pode se comunicar com outrosdispositivos eletrônicos, tal como, um computador, telefone (com fio ou semfio), assistente digital pessoal, televisão, ou similares. Para se comunicar, ocomputador/ambiente de computação 20 pode operar em um ambiente derede que usa conexões em ou mais dispositivos eletrônicos. A figura 37 mos-tra o ambiente de computador em rede com o computador remoto 62. Ocomputador remoto 62 pode ser outro ambiente de computação, tal como,um servidor, a roteador; uma rede PC, um dispositivo par ou outro nó de re-de comum, e pode incluir muitos ou todos os elementos descritos acima rela-tivos ao ambiente de computação 20. As conexões lógicas mostradas nafigura 37 incluem uma rede de área local (LAN) 64 e uma rede de área am-pla (WAN) 66. Tais ambientes de rede são comuns em escritórios, redes decomputador empresariais-amplas, intranets e a Internet.
Quando usado em um ambiente de rede LAN, o ambiente decomputação 20 pode ser conectado à LAN 64 através de uma rede l/O 68.Quando usado em um ambiente de rede WAN, o ambiente de computação20 pode incluir um modem 70 ou outros meios para estabelecer as comuni-cações através da WAN 66. O modem 70, que pode ser interno ou externoao ambiente de computação 20, é conectado ao barramento de sistema 26através da interface de porta em série 52. Em um ambiente em rede, os mó-dulos de programa mostrados em relação ao ambiente de computação 20 ouporções destes podem ser armazenados em um dispositivo de armazena-mento de memória remoto residente ou acessível ao computador remoto 62.Além disso, outros dados relevantes para o método implementado por com-putador para gerar arquivos de computador executáveis interrelacionadosque podem ser produtos de seguro ou relacionados a produtos de seguroe/ou relacionados às aplicações de gerenciamento de reivindicação de segu-ro (descritas em mais detalhes acima) e/ou relacionados à geração de do-cumentos de seguro, e/ou relacionados à geração de produtos adicionais,tais como, produtos de imóveis, produtos de serviços financeiros e/ou docu-mentos, podem ser residente ou acessíveis através do computador remoto62. Os dados podem ser armazenados, por exemplo, em um objeto ou umbanco de dados. Será avaliado que as conexões de rede mostradas são e-xemplificativas e outros meios de estabelecer uma conexão de comunica-ções entre os dispositivos eletrônicos podem ser usados.
O sistema de computador descrito acima é apenas um exemplodo tipo de sistema de computação que pode ser usado para implementar ométodo implementado por computador descrito acima.
Lista de Referências Numéricas
1 GUI
2a campo
2b campo
4a campo
4b campo
6a campo
6b campo
8 campo
10 janela
12 caixa
16 botão
18 botão20 ambiente de computação convencional
22 unidade de processamento
24 memória de sistema
26 barramento de sistema
28 memória de acesso aleatório (RAM)
30 memória somente leitura (ROM)
32 drive de disco rígido
34 drive de disco externo
36 disco removível
38 interface de drive de disco rígido
40 interface de drive de disco externo
44 um ou mais programas de aplicação
46 dados de programa
48 teclado
50 mouse
52 interface de porta serial
54 interface de porta paralela
56 impressora
58 monitor
60 entrada/saída de vídeo
62 computador remoto
64 rede de área local (LAN)
66 rede de área ampla (WAN)
68 rede l/O
70 um modem
101 GUI
110 listas suspensas
112 botões
114 campos de entrada
114a campo de entrada
116 janela de entrada/saída
118a- 118i elementos de exibição118'a - 118'b elementos de exibição120a - 120i campos de entrada120'a - 120'b campos de entrada122 barra de rolagem124 cabeçalho126 cabeçalho200 visão geral de arquitetura técnica202 arquitetura de usuário204 arquitetura de aplicações206 arquitetura de desenvolvimento208 arquitetura de operações210 arquitetura de dados212 arquitetura de execução214 arquitetura de impressão300 visão geral302 cliente HTML304 cliente Java306 estação de trabalho de cliente308 estação de trabalho de cliente310 servidor web312 servidor de aplicação314 servidor de integração316 sistemas de legado318 anfitrião
Claims (13)
1. Método implementado por computador para adaptar e utilizarum ambiente de computação, em que o ambiente de computação compre-endeum conjunto de arquivos executáveis,uma estrutura repositória,uma estrutura de tabela, em quea estrutura repositória e a estrutura de tabela são associadasuma à outra,einterface gráfica de usuário (GU1101) que é adaptada para iniciara execução dos arquivos executáveis,a leitura de dados e/ou escrita de dados na estrutura de tabela, efornecimento de dado de saída como texto legível por humano,o método implementado por computador que tem as etapas de:proporcionar uma definição de uma alteração do ambiente decomputação em um lado de cliente,adaptar os arquivos executáveis, de acordo com a definição daalteração do ambiente de computação em um lado de servidor,introduzir pelo menos um elemento repositório adicional na estru-tura repositória no lado de servidor, em que pelo menos um elemento reposi-tório adicional corresponde à adaptação dos arquivos executáveis,adaptar a estrutura de tabela no lado de servidor, que corres-ponde ao elemento repositório adicional da estrutura repositória, eacessar a estrutura de tabela adaptada no lado de servidor atra-vés da dita GUI (101) e/ou executar um ou mais arquivos executáveis no la-do de servidor através da dita GUI (101), enquanto mantém substancialmen-te o esboço visual da dita GUI (101).
2. Método implementado por computador, de acordo com a rei-vindicação 1, em que o arquivos executáveis e a dita GUI (101) acessam amesma estrutura de tabela, em que o acesso compreende escrever dadose/ou ler dados a partir da mesma estrutura de tabela.
3. Método implementado por computador, de acordo com a rei-vindicação 1 ou 2, em que a adaptação do ambiente de computação é subs-tancialmente livre de cópia da estrutura repositória e/ou da estrutura de tabela.
4. Método implementado por computador, de acordo com pelomenos uma das reivindicações precedentes, em que quando adapta o ambi-ente de computação, a estrutura repositória é substancialmente mantida.
5. Método implementado por computador, de acordo com pelomenos uma das reivindicações precedentes, em queusar a dita GUI (101), o dado de saída é gerado pelo ambientede computação,e em queapós a adaptação do ambiente de computação, que usa a ditaGUI (101), o dado de saída adicional é gerado pelo dito ambiente de compu-tação adaptado.
6. Método implementado por computador, de acordo com pelomenos uma das reivindicações precedentes, que compreende adicionalmen-te a etapa deadaptar a dita GUI (101), de acordo com pelo menos um ele-mento repositório adicional na estrutura repositória ao introduzir pelo menosum elemento de exibição (118a a 118i) em uma entidade de entrada/saídadinâmica (116) da dita GUI (101), enquanto mantém as entidades de entra-da/saída restantes (110, 112, 114) da dita GUI (101) substancialmente inalte-radas.
7. Método implementado por computador, de acordo com a reivin-dicação 6, em que ao introduzir pelo menos um elemento adicional de exibi-ção (118a a 118i) na dita entidade de entrada/saída dinâmica (116) da ditaGUI (101), o tamanho da dita entidade de entrada/saída dinâmica (116) émantido
8. Método implementado por computador, de acordo com a reivin-dicação 7, em que a dita entidade de entrada/saída dinâmica (116) da GUI(101) é implementada como uma lista suspensa, se o tamanho da dita enti-dade de entrada/saída dinâmica (116) for menor que o tamanho comum detodos os elementos de exibição (118a a 118i) da dita entidade de entra-da/saída (116).
9. Método implementado por computador, de acordo com pelomenos uma das reivindicações 6 a 8, em quePara exibir um elemento de exibição (118a a 118i) na entidadede entrada/saída dinâmica (116) o conteúdo do dito elemento de exibição(118a a 118i) é lido a partir de um elemento de tabela associadoe/oupara armazenar o conteúdo (120a a 120i) de um elemento deexibição (118a a 118i) da entidade de entrada/saída dinâmica (116), o con-teúdo (120a a 120i) do dito elemento de exibição (118a a 118i) é escrito emum elemento de tabela associado.
10. Método implementado por computador, de acordo com pelomenos uma das reivindicações 6 a 9, em queos elementos de tabela armazenados na dita estrutura de tabelasão armazenados em uma ordem de tabela predeterminada,em queelementos de exibição (118a a 118i) exibidos na entidade de en-trada/saída dinâmica (116) são exibidos em uma ordem de exibição prede-terminada,e em quea ordem de tabela predeterminada é diferente da ordem de exi-bição predeterminada.
11. Método implementado por computador, de acordo com a rei-vindicação 10, em que um dispositivo de ordem de elemento é usadopara ler o conteúdo de um elemento de tabela no elemento deexibição associado (118a a 118i) na ordem de exibição,epara escrever o conteúdo (120a a 120i) de um elemento de exi-bição (118a a 118i) no elemento de tabela associado na ordem de tabela.
12. Produto de programa de computador, que compreende ins-truções legíveis por computador, que quando carregadas na memória de umcomputador e executadas pelo computador faz com que o computador reali-zé o método, como definido pelo menos em uma das reivindicações anterio-res.
13. Sistema baseado em computador para gerar dado de saída,em particular, sob a forma de texto legível por humano, que compreendeum conjunto de arquivos executáveis,uma estrutura repositória euma estrutura de tabela, em quea estrutura repositória e a estrutura de tabela são associadasuma à outra, euma interface gráfica de usuário (GUI, 101) que é adaptada paraexecutar os arquivos executáveis,ler dados e/ou escrever dados na estrutura de tabela, eproporcionar o dado de saída as texto legível por humano,o sistema baseado em computador que compreende adicional-mente:uma interface de cliente para definir uma alteração dos arquivosexecutáveis em um lado de cliente,um dispositivo de servidor paraadaptar os arquivos executáveis, de acordo com a definição daalteração em um lado de servidor,introduzir pelo menos uma elemento repositório adicional na es-trutura repositória no lado de servidor, em que pelo menos um elemento re-positório adicional corresponde à adaptação dos arquivos executáveiseadaptar a estrutura de tabela no lado de servidor, que corres-ponde ao elemento repositório adicional da estrutura repositória,e em quea dita GUI (101) é adaptada para acessar a estrutura de tabela adaptada nolado de servidor e/ou para executar um ou mais arquivos executáveis no ladode servidor, enquanto o esboço visual da dita GUI (101) é substancialmentemantido.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP08380135.7A EP2113837B1 (en) | 2008-04-30 | 2008-04-30 | Computer implemented method for generating interrelated computer executable files, computer-based system and computer program product |
EP08380266A EP2113838A1 (en) | 2008-04-30 | 2008-09-09 | Computer implemented method for adapting and using a computing environment, computer program product and computer based system |
Publications (1)
Publication Number | Publication Date |
---|---|
BRPI0903392A2 true BRPI0903392A2 (pt) | 2010-06-01 |
Family
ID=39643995
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
BRPI0901035-1A BRPI0901035B1 (pt) | 2008-04-30 | 2009-04-30 | Método implementado em computador e sistema baseado em computador para a geração de arquivos inter-relacionados executáveis em computador |
BRPI0903392-0A BRPI0903392A2 (pt) | 2008-04-30 | 2009-04-30 | método implementado em computador para adaptar e usar um ambiente de computador, produto programa de computador e sistema baseado em computador |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
BRPI0901035-1A BRPI0901035B1 (pt) | 2008-04-30 | 2009-04-30 | Método implementado em computador e sistema baseado em computador para a geração de arquivos inter-relacionados executáveis em computador |
Country Status (6)
Country | Link |
---|---|
EP (2) | EP2113837B1 (pt) |
AR (2) | AR071836A1 (pt) |
AU (2) | AU2009201680B2 (pt) |
BR (2) | BRPI0901035B1 (pt) |
CL (2) | CL2009000730A1 (pt) |
MX (2) | MX2009004598A (pt) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2446458C1 (ru) * | 2010-11-24 | 2012-03-27 | Закрытое акционерное общество "Лаборатория Касперского" | Компонента лицензирования компьютерных приложений |
US10949923B1 (en) | 2013-09-16 | 2021-03-16 | Allstate Insurance Company | Home device sensing |
US10380692B1 (en) | 2014-02-21 | 2019-08-13 | Allstate Insurance Company | Home device sensing |
US10430887B1 (en) | 2014-02-21 | 2019-10-01 | Allstate Insurance Company | Device sensing |
US10467701B1 (en) | 2014-03-10 | 2019-11-05 | Allstate Insurance Company | Home event detection and processing |
CN107103540A (zh) * | 2016-02-22 | 2017-08-29 | 易保网络技术(上海)有限公司 | 一种计算机执行的访问保险产品数据结构中的具体数据元素的方法和系统 |
CN107103539A (zh) * | 2016-02-22 | 2017-08-29 | 易保网络技术(上海)有限公司 | 一种计算机执行的计算保费的方法和系统 |
CN109871205B (zh) * | 2018-12-15 | 2023-07-18 | 中国平安人寿保险股份有限公司 | 界面代码调整方法、装置、计算机装置及存储介质 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4241307A (en) | 1978-08-18 | 1980-12-23 | International Business Machines Corporation | Module interconnection testing scheme |
AUPP949599A0 (en) * | 1999-03-30 | 1999-04-22 | Griffith University | Visual architecture software language |
US7020869B2 (en) * | 2000-12-01 | 2006-03-28 | Corticon Technologies, Inc. | Business rules user interface for development of adaptable enterprise applications |
US20030172367A1 (en) * | 2002-01-24 | 2003-09-11 | Robert Kannenberg | Method of modifying software via a network |
WO2008021777A2 (en) * | 2006-08-07 | 2008-02-21 | National Instruments Corporation | Formal verification of graphical programs |
-
2008
- 2008-04-30 EP EP08380135.7A patent/EP2113837B1/en active Active
- 2008-09-09 EP EP08380266A patent/EP2113838A1/en not_active Withdrawn
-
2009
- 2009-03-25 CL CL2009000730A patent/CL2009000730A1/es unknown
- 2009-04-07 CL CL2009000842A patent/CL2009000842A1/es unknown
- 2009-04-23 AU AU2009201680A patent/AU2009201680B2/en active Active
- 2009-04-23 AU AU2009201575A patent/AU2009201575B2/en active Active
- 2009-04-29 AR ARP090101557A patent/AR071836A1/es active IP Right Grant
- 2009-04-29 MX MX2009004598A patent/MX2009004598A/es not_active Application Discontinuation
- 2009-04-29 AR ARP090101556A patent/AR071835A1/es active IP Right Grant
- 2009-04-29 MX MX2009004599A patent/MX2009004599A/es not_active Application Discontinuation
- 2009-04-30 BR BRPI0901035-1A patent/BRPI0901035B1/pt active IP Right Grant
- 2009-04-30 BR BRPI0903392-0A patent/BRPI0903392A2/pt not_active Application Discontinuation
Also Published As
Publication number | Publication date |
---|---|
AR071836A1 (es) | 2010-07-21 |
BRPI0901035A2 (pt) | 2010-01-26 |
CL2009000842A1 (es) | 2010-03-12 |
CL2009000730A1 (es) | 2010-03-12 |
BRPI0901035B1 (pt) | 2020-03-31 |
AU2009201575A1 (en) | 2009-11-19 |
AU2009201575B2 (en) | 2012-11-08 |
EP2113838A1 (en) | 2009-11-04 |
MX2009004599A (es) | 2009-10-30 |
EP2113837B1 (en) | 2018-11-14 |
EP2113837A1 (en) | 2009-11-04 |
AU2009201680A1 (en) | 2009-11-19 |
MX2009004598A (es) | 2010-04-30 |
AR071835A1 (es) | 2010-07-21 |
AU2009201680B2 (en) | 2012-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4358782B2 (ja) | 財政計画およびアドバイスシステム用のコンピュータ実行プログラム | |
Garland | Large-scale software architecture: a practical guide using UML | |
BRPI0903392A2 (pt) | método implementado em computador para adaptar e usar um ambiente de computador, produto programa de computador e sistema baseado em computador | |
AU5541796A (en) | Automated enforcement of behavior in application program | |
WO1996032675A9 (en) | Automated enforcement of behavior in application program | |
US8744879B2 (en) | System and method for insurance product development | |
US20140122377A1 (en) | System and method for applying a business rule management system to a customer relationship management system | |
Hamdaqa et al. | icontractml: A domain-specific language for modeling and deploying smart contracts onto multiple blockchain platforms | |
Krahel | On the formalization of accounting standards | |
Dam et al. | Supporting change propagation in the evolution of enterprise architectures | |
Morris et al. | Developing a blockchain business network with hyperledger composer using the ibm blockchain platform starter plan | |
WO1996031828A1 (en) | Control system and method for direct execution of software application information models without code generation | |
Harrison | Code generation with roslyn | |
Velasco et al. | Evaluation of a High-Level Metamodel for Developing Smart Contracts on the Ethereum Virtual Machine | |
US11126967B2 (en) | Dynamic markup language-driven product administration system | |
FRIGERIO et al. | Model Driven Development of Blockchain Applications | |
JP2023137754A (ja) | 分割収益計上装置、分割収益計上方法、および、分割収益計上プログラム | |
Abeyratne | Web Based System for Maganeguma Rural Road Development Programme | |
Steizinger | Smart Economy | |
BRPI0909274A2 (pt) | processo para geração automatizada de software | |
Shelley | Bay Audio Repair Website & Data Management Application | |
ALAM | CORE E-PORTAL | |
Joos | A software development environment that assists in the use and design of reusable modules | |
Koirala et al. | How to Prepare Software Quotation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
B03A | Publication of an application: publication of a patent application or of a certificate of addition of invention | ||
B25A | Requested transfer of rights approved |
Owner name: ACCENTURE INTERNATIONAL SARL (LU) Free format text: TRANSFERIDO DE: ACCENTURE GLOBAL SERVICES GMBH. |
|
B25A | Requested transfer of rights approved |
Owner name: ACCENTURE GLOBAL SERVICES LIMITED (IE) Free format text: TRANSFERIDO DE: ACCENTURE INTERNATIONAL SARL |
|
B06F | Objections, documents and/or translations needed after an examination request according art. 34 industrial property law | ||
B06T | Formal requirements before examination | ||
B07A | Technical examination (opinion): publication of technical examination (opinion) | ||
B09B | Decision: refusal | ||
B09B | Decision: refusal |
Free format text: MANTIDO O INDEFERIMENTO UMA VEZ QUE NAO FOI APRESENTADO RECURSO DENTRO DO PRAZO LEGAL |