BRPI0909274A2 - processo para geração automatizada de software - Google Patents

Abstract

<B>PROCESSO PARA GERAçãO AUTOMATIZADA DE SOFTWARE.<D> é proposto um processo de geração automática de programas fonte com base no MDA. Para orientar o processo de geração de código, são usadas regras de marcação padronizadas, inseridas em modelos UML por meio de lagged values, extensões e anotações. Essas regras indicam o interesse arquitetural e o padrão dc projeto que deverá ser usado ao gerar os programas fonte. O PROGERAS é proposta de extensão ao MDA, aplicando os conceitos do AOD e do POA para gerar programas fonte de forma automatizada a partir de um diagrama de classes (PIM). Com essa proposta, acredita-se ser possível não só obter um elevado nível de automação no processo de produção do software, forçar o uso de padrões, aumentar a qualidade e a consist6ncia, como também ganhar produtividade.

Description

"PROCESSO PARA GERAÇÃO AUTOMATIZADA DE SOFTWARE"INTRODUÇÃO/ESTADO DA TÉCNICA

No presente pedido é proposto um processo para geração de programas a partirde modelos UML, como sugerido no MDA (Model-Driven Architecture). O MDA é umprocesso de desenvolvimento de software criado e publicado pela OMG (ObjectManagement Group), em 2001, e tem como base um conjunto de práticas e padrões paradesenvolvimento de software por meio da transformação de modelos. O MDA estáfundamentado em outros padrões também definidos pela OMG: UML (Unified ModelingLanguage) para modelagem, MOF (Meta-Object Facility) para definição de linguagens demodelagem, XMI (XML Metadata Interchange) para armazenamento de modelos e QVT('Query View Transformation) para transformação de modelos (Mellor et alli., 2005).

O MDA é uma especialização do MDD (Model-Driven Development), umaabordagem na qual considera-se que os modelos de análise e projeto estão no mesmo níveldos programas fontes, buscnado transferir o trabalho da programação para a construção demodelos (Stahl et alli., 2006). O objetivo do MDA e do MDD é desenvolver sistemascompletos de forma automatizada por meio da ligação e transformação de modelos e nofinal gerar programas fonte. Na abordagem MDA estão definidas quatro categorias demodelos, que são o CIM (Computer Indepent Model), o PIM (Platform Indepent Model), oPSM (Platform Specific Model) e os programas-fonte. O CIM é usado para modelar osprocessos de negócio e a estrutura das informações. O PIM é um modelo utilizado paradescrever a estrutura do sistema sem levar em consideração a plataforma na qual seráimplementado. Esse modelo pode consistir de diagramas de classes, estados, seqüência,dentre outros. O PSM consiste de um refinamento do PIM, no qual é considerada umaplataforma específica e ele lida com o sistema operacional, linguagem de programação,tecnologia da plataforma (.NET, J2EE, CORBA, etc.), distribuição, dentre outros detalhestécnicos. No MDA o programa fonte também é considerado como sendo um modelo, que éo refinamento do PSM. As seguintes contribuições do MDA são destacadas em Biffl etalli. (2007):Melhoria da produtividade aliada à redução de prazo e custo, decorrente daautomação da geração de modelos e programas fonte.

Maior foco no negócio, decorrente da mudança do enfoque do desenvolvedor quepassa a trabalhar principalmente no CIM e no PIM para construir modelosconceituais, ao invés de ter que se aprofundar em detalhes lógicos e técnicos.

Aumento da portabilidade, visto que o mesmo PIM pode ser transformado emmodelos PSM para diferentes plataformas e linguagens.

Simplificação do processo de mudança, já que essas precisam ser feitas apenas noCIM e no PIM, e depois propagadas para os modelos PSM e programas fonteautomaticamente.

Aumento do reuso, por meio da reutilização das rotinas e regras de transformação egeração de programas fonte.

Sabe-se que o uso do MDA pode resultar em diversas melhorias, tais como: (i)melhorias no requisito de portabilidade, devido à separação do conhecimento de negóciode sua implementação numa tecnologia específica; (ii) aumento de qualidade, devido aoreuso de padrões e práticas bem testadas no processo de transformação; (iii) melhoria nafacilidade de manutenção, devido à separação de interesses e obtenção de maiorconsistência e geração de trilhas entre modelos e programas fonte. Contudo, o MDAapresenta uma lacuna importante por não apresentar suporte adequado para elaboração do projeto técnico da arquitetura, uma vez que a concepção da arquitetura do software não éconsiderada na visão do MDA. A ausência dessa característica tem sido um campo fértilpara pesquisas, que estão no campo do ACMDA (Architecture-Centric MDA) e Aspect-Oriented MDA, e que propõem o uso do AOD (Aspeet-Oriented Design), do POA(.Pattern-Oriented Arehiteeture) e do AOP (.Aspeet-Oriented Programming) como meiospara estender o MDA.

Na filosofia do Pattern-Oriented Arehiteeture (POA), a arquitetura de umsoftware pode ser construída por meio do reuso de soluções estruturais prontas, que são ospadrões de projeto. O POA pode trazer várias contribuições para aumento da qualidade eprodutividade, ou seja:• Prover soluções bem conhecidas e testadas para o projeto da arquitetura, reduzindoo esforço e os riscos de especificação.

• Prover meios para documentar as decisões pertinentes à arquitetura.

• Facilitar a comunicação entre os participantes do projeto por meio de umvocabulário padronizado.

• Descrever os atributos de qualidade associados a cada solução.

Segundo o Aspect-Oriented Design (AOD), a arquitetura de um software podeser projetada e implementada a partir da especificação de interesses arquiteturais(iarchitectural concerns) como persistência, apresentação, auditoria, dentre outros. Essesinteresses podem ser especificados e implementados por meio da aplicação de padrões deprojeto. O AOD é derivado do Aspect-Oriented Programming (AOP) que é uma técnica deprogramação que permite endereçar umas das principais limitações da programaçãoorientada a objetos, que é a modularização dos interesses arquiteturais que atravessamvários elementos da estrutura do software (crosscutting concerns), como persistência,tratamento de erros, segurança, dentre outros. O AOD provê mecanismos para identificar eprojetar esses interesses e depois combiná-los com o resto dos programas. Dentre osprincipais benefícios do AOD, destacam-se:

Centralizar a localização do código associado à implementação de umafuncionalidade específica, por meio de um aspecto. Por exemplo, no AOP oprograma pertinente à persistência fica concentrado num aspecto, que depois écombinado com o resto dos programas no momento da compilação. Isso aumenta acoesão e reduz o acoplamento entre os elementos da arquitetura.

• Automatizar o processo de geração de programas, combinando múltiplos aspectospara gerar o software. Isso pode resultar em ganho de produtividade e qualidade,assim como redução de custo.

Na abordagem do MDA falta abordar a questão do projeto técnico daarquitetura, o que inclui o tratamento dos requisitos não-funcionais. Algumas pesquisaspropõem a combinação do MDA com o AOD como meio para lidar com os interessestransversais e outras propõem a combinação do MDA com o POA para lidar com asdecisões pertinentes à arquitetura. O PROGERAS poderá ser usado como uma extensão aoMDA, adicionando os benefícios associados ao AOD e ao POA.

Apesar de o MDA apresentar uma lacuna quanto ao projeto da arquitetura, asferramentas que o utilizam propiciam vários benefícios para os desenvolvedores desoftware. Há uma discussão sobre a adoção do MDA como meio de aumento deprodutividade e também é apresentada uma avaliação baseada no uso do OptimalJ. Há umalista extensa de ferramentas para geração de programas-fonte, compatíveis com o MDA eMDD. Algumas delas, como o CodeSmith, .netTiers, AndroMDA, MyGeneration, dentreoutras, foram testadas durante o a concepção do processo para geração automatizada deprogramas fontes, objeto do presente pedido, doravante denominado PROGERAS, comomeio para automatizar etapas do processo. Porém todas elas esbarram na limitação de nãodeixar explícitas as escolhas arquiteturais feitas pelos geradores ao criar os programasfonte e fornecem suporte limitado para que o arquiteto possa influenciar essas escolhas.

Este tipo de abordagem carece de um mecanismo formal, padronizado e flexível quepermita ao arquiteto indicar o que deve ser gerado, já que cada software tem necessidadesespecificas e não deveriam ser geradas nem mais nem menos linhas de programas e rotinasque o necessário.

BREVE DESCRIÇÃO DAS FIGURAS.

A figura 1 mostra esquematicamente o fluxograma do processo de geração deprogramas fonte, objeto do presente pedido, com o detalhamento e a marcação do modelo egeração do código;

A figura 2 mostra o processo de geração de programas-fonte de um softwareusando um gerador;

A figura 3 exibe diagrama de contexto da ferramenta de geração de código combase no PROGERAS;A figura 4 mostra projeções do modelo de domínio por interesse arquitetural;

A figura 5 mostra Templates (Modelos padrões) implementados no protótipo daferramenta de geração de programas-fontes (batizado de Genesys) criado para demonstraro PROGERAS;

A figura 6 mostra um exemplo do Modelo de Domínio do Sistema deReembolso de Despesas;

A figura 7 exibe um exemplo do Diagrama de Componentes do Sistema deReembolsos;

A figura 8 mostra um Diagrama de Pacotes descrevendo as camadas do Sistemade Reembolsos;

DESCRIÇÃO DETALHADA DA INVENÇÃO

Processo para Geração Automatizada de Softwares

A arquitetura de um software consiste em uma estrutura ou estruturas dosistema que, por sua vez, se formam pelos elementos do software, das propriedadesvisíveis externamente demonstradas por esses elementos e nas relações entre eles. Asnecessidades do negócio vão determinar os atributos de qualidade que a arquitetura dosistema precisará apresentar. Somadas a outros requisitos técnicos (sistema operacional,linguagem, dentre outros) vão orientar o arquiteto na identificação dos interessesarquiteturais relevantes e na seleção das abordagens técnicas que serão utilizadas (padrõesde projeto, algoritmos, estruturas de dados, dentre outras). Essas características técnicassão transversais aos requisitos funcionais, que descrevem as capacidades, serviços e ocomportamento do software. O mapeamento das funcionalidades do sistema na estrutura desoftware vai determinar o suporte da arquitetura aos requisitos de qualidade.

A arquitetura de um software decorre de múltiplos interesses, alguns associadosàs funções de infra-estrutura (persistência, geração de logs, tratamento de exceções, dentreoutros) e outros associados às funções de negócio, sendo que os primeiros são construídospara suportar o segundo. A forma como os interesses arquiteturais são especificados variaem função dos atributos de qualidade que o software precisa atender. Cada interesse podeser implementado por meio do uso de táticas arquiteturais bem conhecidas (padrões deprojeto), que permitem maximizar certos atributos de qualidade. Um padrão de projetopode estar associado a várias táticas, e vice-versa. Um padrão de projeto também podeestar associado a mais de um interesse, e vice-versa. Por exemplo, numa implementação odesenvolvedor pode criar um mecanismo para gerar trilha de Iog (para suportar asegurança) ou trilha de testes (para suportar a facilidade de ser testado).

No processo de análise o arquiteto terá que compreender os requisitosenvolvidos numa implementação e fazer as escolhas de quais combinações de táticasdeverão ser aplicadas para que o sistema possa atingir os seus objetivos de qualidade e defuncionalidade. No PROGERAS os padrões de projeto selecionados para implementaçãode cada interesse arquitetural são indicados no próprio modelo, por meio de um mecanismode marcação. O método de escolha das táticas está fora do escopo deste processo, no qual éconsiderada apenas a marcação e a transformação de modelos. Posteriormente umaferramenta (um gerador de programas fontes) vai ler os modelos PIM marcados etransformá-los para programa fonte usando os mecanismos de combinação aspectual.

Requisitos do Processo

Quanto ao mecanismo de marcação de modelos e geração de programas, oprocesso foi concebido para atender aos seguintes requisitos:

• Usar uma estrutura padronizada para marcação dos modelos com base no recursode tagged values, estereótipos e anotações do UML.

• Usar ferramentas para automatizar o processo de geração de programas fonte.

• Projetar a estrutura do software a ser gerado com base em interesses arquiteturais epadrões de projeto. Os padrões são escolhidos para atender a certos atributos dequalidade que o software precisa respeitar.

• Implementar cada interesse arquitetural por meio da aplicação de um ou maispadrões de projetos.• Os interesses arquiteturais podem atravessar uns aos outros, sendo assim, oprocesso deve ter mecanismos para combinar dois ou mais interesses e, porconseguinte, dois ou mais padrões de projeto, no processo de geração de programasfonte.

• Para cada padrão de projeto há um ou mais templates, sendo eles ativados emfunção das marcas inseridas no modelo de entrada. Cada marca indica um interessejunto e um padrão de projeto.

• Os templates podem receber parâmetros de entrada para direcionar a ferramenta degeração de programas fonte, por exemplo, uma string de conexão, um flagindicando se um determinado atributo de uma classe é persistente ou não, dentreoutros. A regra de marcação deve permitir que seja indicado o interessearquitetural, o padrão de projeto e também os parâmetros. Juntos, esses elementoscompõem um aspecto que será aplicado ao modelo para geração dos programaspertinentes.

• O processo não se limita a um estilo arquitetural específico, como LAYER ouFILTERS AND PIPES ou BLACKBOARD, por exemplo. O estilo arquitetural éimposto por meio dos padrões de projeto que o arquiteto aplica aos modelos, pormeio das marcações.

• O processo não deve limitar-se a uma linguagem, plataforma ou frameworkespecífico.

• O processo deve poder ser usado em conjunto com diferentes metodologias, comoRUP, XP, Scrum, dentre outras.

Um processo de desenvolvimento de software define um arcabouço para astarefas necessárias para construir um sistema. O processo fornece um roteiro, composto poruma série de passos previsíveis, que ajuda o desenvolvedor a criar, dentro do tempoespecificado, um produto de software com qualidade esperada. Os desenvolvedoresadaptam o processo às necessidades específicas de cada projeto. Tipicamente um processoé composto pelos seguintes tipos de atividades:• Comunicação: atividades associadas à comunicação com o cliente e levantamentode requisitos. Por exemplo, identificação e reuniões com os interessados no projeto,documentação das características e funcionalidades desejadas, priorização dosrequisitos, investigação das restrições e limitações que serão colocadas no sistema,dentre outras.

• Planejamento: atividades para estabelecer um plano de trabalho, que descreve astarefas, os riscos, os recursos, produtos de trabalho, dentre outros elementos.

• Modelagem: atividades pertinentes à criação de modelos. Basicamente existemduas atividades de modelagem, a análise e o projeto técnico. As tarefas de análiseenvolvem, dentre outras, levantamento, elaboração, negociação, especificação evalidação de requisitos para criação de modelos de análise. As tarefas técnicasenvolvem, dentre outras, criação do modelo de dados, projeto arquitetural e decomponentes.

• Construção: atividades de geração de código (manual ou automático) e os testesnecessários.

• Implantação: atividades associadas à entrega do software ao cliente, que fazavaliação e fornece feedback.

No PROGERAS as atividades têm foco no trabalho técnico de engenharia,pertinentes à modelagem e construção. Sendo assim, para obter-se um melhor resultadoeste processo pode ser combinado com outro que o complemente, como o SCRUM ouPMI/PMBook, que tem enfoque nas atividades de gerenciamento e comunicação - ambosse completariam.

Passos do Processo

O processo PROGERAS consiste de uma seqüência de passos para obterem-seprogramas fonte de forma automática, por meio do uso de uma ferramenta, a partir de umdiagrama de classes UML. Os passos básicos do processo estão ilustrados na figura 1.

Passo 1 - Levantar Requisitos. A primeira tarefa consiste em identificar os requisitos dosoftware que será desenvolvido: requisitos funcionais, não-funcionais e técnicos. NoPROGERAS não é definido como estes requisitos devem ser levantados. O trabalho podeser feito por meio de casos de uso, cenários, histórias ou por meio de qualquer outromecanismo. Este trabalho normalmente é executado por um Analista de Negócios.

Passo 2 - Criar o Modelo de Domínio. O próximo passo é elaborar o Modelo deDomínio, por meio de um diagrama de classes UML, no qual são indicadas as entidades denegócio e as relações entre elas. Este trabalho é executado manualmente por um Analistade Sistemas.

Passo 3 - Projetar Arquitetura. O projeto da arquitetura é elaborado por meio daidentificação e especificação dos interesses arquiteturais. Para cada interesse arquiteturaldeve ser associado um padrão de projeto que permita que o software possa atingir osobjetivos de qualidade especificados. No PROGERAS, para cada padrão deprojeto/interesse haverá um template para geração de programas fonte. O Projeto daArquitetura é executado por um Arquiteto de Software.

Passo 4 - Marcar o Modelo de Domínio. O próximo passo consiste em fazer a marcaçãodo Modelo de Domínio. Os elementos do diagrama de classes (domínios, classes, atributose operações) devem ser marcados com base no projeto da arquitetura e no padrão deRegras de Marcação do PROGERAS. As marcações indicam o interesse arquitetural e opadrão de projeto selecionado para sua implementação. Juntas, essas duas informações vãopermitir que a ferramenta selecione e execute o template correspondente. Este trabalhotambém é executado pelo Arquiteto de Software.

Passo 5 - Gerar programas fontes. Depois que os diagramas forem marcados, eles serãoprocessados por uma ferramenta, que receberá como entrada, um ou mais diagramas declasses (com marcações) correspondentes ao modelo PIM e, como saída, vai gerar tantoprogramas fonte numa linguagem específica quanto outros modelos mais detalhados quedemonstram a arquitetura do sistema após a aplicação dos padrões de projeto. A ferramentavai processar os modelos e criará outros modelos novos, específicos para cada interesse,que detalham a arquitetura do software. Será criado um modelo PIM para cada interessearquitetural (persistência, apresentação, etc.). Esses modelos mostram a estrutura daarquitetura, não considerando a tecnologia que será utilizada na implementação. Estetrabalho também é executado pelo Arquiteto de Software. Estas entradas e saídas estãoilustradas na figura 2, na qual é mostrado o diagrama de contexto de uma ferramenta degeração de código compatível com o PROGERAS.

Ao processar as marcas associadas ao PROGERAS, o interesse arquitetural e opadrão de projeto indicados vão orientar a ferramenta na seleção e na execução do templatepertinente. Um elemento, como uma classe, pode conter múltiplas marcações, cada umaassociada a um template diferente. Por exemplo, uma classe pode ter uma marcação paragerar o programa fonte associado à classe da camada de negócio (interesse de negócio),outra para persistência (interesse de persistência) e outra para gerar telas de pesquisa eedição (interesse de apresentação).

Dessa forma a ferramenta, por meio dos templates, vai gerar os programas fontede infra-estrutura da aplicação e depois as regras de negócio deverão ser inseridasmanualmente por um programador. Para isso, o programador deverá inserir novas linhas deprograma, em áreas protegidas, nos arquivos gerados pela ferramenta ou criar novasclasses para herdar as geradas pela ferramenta. Quando o programa fonte for regerado, aferramenta preservará o conteúdo inserido manualmente, demarcado por essas áreas.

Passo 6 - Adicionar linhas de programa manualmente. A ferramenta pode não gerartodo o programa fonte e um programador terá concluir o trabalho manualmente. Nestaetapa é necessário assegurar que o código adicionado manualmente não seja substituídopelo código regerado. Para isso as novas linhas de programa devem ser adicionadas emáreas protegidas, demarcadas nos arquivos gerados pela ferramenta.

Passo 7 - Gerar o software executável. Finalmente os programas gerados pelaferramenta, mais aqueles construídos manualmente por um programador devem sercombinados num projeto e compilados para dar origem ao aplicativo executável.

Por meio do processo PROGERAS é proposto um complemento à visão MDA,cujo foco é definir padrões para modelagem e transformação de modelos. Neste processo ésugerida uma estrutura padronizada de regras de marcação, para indicar os padrões queserão usados na implementação de cada interesse arquitetural e uma seqüência de passos aserem seguidos para marcar o modelo e transformá-lo em programas fonte.Ferramenta de Geração de Programas Fonte (robôs)

No PROGERAS as ferramentas de geração de programas fonte também sãochamadas de robôs. Estas ferramentas recebem como entrada diagramas UML marcados ecomo saída geram programas fonte.

Alguns interesses arquiteturais, como persistência e auditoria, podem se cruzar.Por exemplo, pode ser necessário gerar Iog de auditoria sempre que objetos de determinadaclasse forem persistidos. Neste caso estão sendo cruzados os interesses de persistência egeração de log. A ferramenta precisará ter mecanismos para combinar dois ou maispadrões de projeto, por meio da combinação dos templates pertinentes. O AOD fornece ummecanismo para essa finalidade, que é o uso de pontos de junção e adendos. NoPROGERAS os templates são tratados como adendos, e dentro de cada template, devemser definidos pontos de junção. A ferramenta fará a combinação aspectual por meio dacombinação dos templates.

Na figura 2.2 está ilustrada a estrutura de um gerador. A ferramenta vai ler odiagrama de classes com as marcações, gravado em formato XMI (conforme definido nopadrão MDA), e armazená-lo internamente, por meio de um grafo de objetos. Esse modeloserá processado e convertido, também por meio de um módulo de transformação, em umnovo modelo. Para realizar essa tarefa, a ferramenta percorrerá todos os tagged values decada elemento (domínios, classes, atributos, relações e operações) para identificar aquelespertinentes ao PROGERAS. A ferramenta vai aplicar o padrão de projeto indicado paracada interesse. Ao aplicar o padrão de projeto, novas classes e domínios serão criados,dando origem a um novo modelo. Posteriormente esse novo modelo será processado pelogerador de código que produzirá os programas fonte para uma plataforma e linguagemespecíficas. Depois os programas gerados automaticamente e os criados manualmente pelodesenvolvedor serão combinados e compilados para gerar o aplicativo completo.

Uma ferramenta de geração de programas fonte compatível com o PROGERAStrabalhará com múltiplos templates, um para cada padrão de projeto e interessearquitetural. Por exemplo, para o interesse de persistência, haverá um template queimplementa o padrão de projeto DAO com acesso ao banco de dados via ODBC e outropara o DAO que usa a API do driver nativo. A mesma abordagem pode ser aplicada aoutros interesses arquiteturais, como auditoria e apresentação. O template pode gerarprogramas fonte de auditoria para gravar Iog em arquivo TXT ou XML. O interesse deapresentação pode ser implementado com MVC, mas pode haver um template para web eoutro para aplicações desktop. Cada template está associado a um padrão de projetodiferente. Estes elementos estão representados na figura 2.3.

Regras de Marcação

No PROGERAS, as marcas indicam um interesse arquitetural, como propostono AOD, e o padrão de projeto que será usado na sua implementação, como proposto noPOA. As marcas são inseridas no modelo por meio de tagged values ou anotações e têm aforma Variável := Expressão. A variável indica o interesse (aspecto arquitetural) e aexpressão indica o mecanismo de implementação que pode ser um valor atômico ou podeconter um conjunto de um ou mais parâmetros, separados por ponto e vírgula. Cadaparâmetro tem a forma Parâmetro = Valor, representando o nome do parâmetro e o valorcorrespondente. Uma marca tem a seguinte estrutura:

aspAspecto:={ Pattern=NOME;[outros parâmetros do pattern]}

Seguem alguns exemplos de marcas do PROGERAS:

aspPresentation:={Pattern=MVCWEB; Operations=CRUD;

Screen=Form)

aspPersistency:={Pattern=DAODB}

aspAuditity:={Pattern=LOGTXT;Layer=DAL}

No primeiro exemplo, a marca está associada ao interesse de apresentação eindica que para esse interesse deve ser aplicado o padrão de projeto MVCWEB (MVC paratelas html). Essa marca, que deve ser aplicada às classes, tem dois parâmetros: oOperations, que indica as operações de CRUD (Create, Read, Update e Delete) que devemser ativadas na tela, e o Screen que indica o formato da tela (Screen=Form para formulárioe Screen=Grid para tabela).

O próximo exemplo é uma marcação do interesse de persistência, que seráimplementado por meio do padrão de projeto DAO, usando banco de dados relacionais.Neste padrão, para cada classe marcada como persistente no Modelo de Domínio, serácriada uma classe responsável por ler e gravar os objetos correspondentes no banco dedados na camada de persistência. O exemplo indica que será aplicado o padrão de projetoDAO para bancos de dados relacionais (Pattern=DAODB), mas poderiam ser usadosoutros padrões aplicando DAO para XML, para CSV, dentre outros. O template DAO podeter múltiplos parâmetros, como os exemplos indicados na tabela 2.1.

No Modelo de Domínio são inseridas marcas para indicar os interessesarquiteturais relevantes no projeto da aplicação e os padrões de projeto aplicados naimplementação de cada um deles. Quando uma ferramenta processa o Modelo de Domínioe cria novos modelos, um para cada interesse arquitetural, uma entidade do modelo apareceem um ou mais modelos. Uma entidade pode ser marcada com mais de um interesse, comomostrado na figura 4, por exemplo:

• Interesse negócio, para indicar que é uma entidade de negócio.

• Interesse de persistência, para indicar que será persistida no banco de dados.

• Interesse de apresentação, para indicar que será visualizada e atualizada por meio

de telas (interface com usuário).

• Interesse de monitoração, para indicar que as operações de construção e destruiçãode objetos serão monitoradas.

• Dentre outros.

Quando um template, é construído, nas suas definições deve ser indicado o

nome do padrão de projeto associado, o nome do interesse arquitetural, a lista deparâmetros permitidos e a relação dos arquivos com os templates de programas fontes.

Na figura 5 estão indicados alguns exemplos de interesses arquiteturais epadrões de projeto. Para cada interesse arquitetural pode haver uma ou maisimplementações de padrões de projeto. Cada implementação está associada a um template,que será usado pela ferramenta para geração de programas fonte. Por exemplo, existem trêsimplementações persistência: DAODB, DAOXML e DAOCSV. O template DAODB geracódigo para persistência de bancos de dados relacionais usando o padrão de projeto DAO(Data Access Objects), o DAOXML gera código para persistir objetos em arquivos XML eo CSV em arquivos CSV (Coma-Separated Values).

O nome do interesse arquitetural será atribuído arbitrariamente pelodesenvolvedor que constrói o template. Contudo, a estrutura dos nomes deve serpadronizada, para facilitar a sua memorização e o trabalho de marcação de modelos.Devem-se evitar dois nomes diferentes para o mesmo interesse arquitetural, pois issogeraria ambigüidade e dificultaria o uso do processo e da ferramenta de geração deprogramas fontes.

Na figura 5 há algumas sugestões de nomes, que são compostos pelo prefixo"asp" (de "aspecto") seguido do nome do interesse. Abaixo, foi usada a língua inglesa paraque o processo possa ser entendido mais facilmente por desenvolvedores de outros países.

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

Tabela 1

- Exemplo de parâmetros de um template para gerar código de persistência.Conclusão

O PROGERAS aborda a transformação de modelos PIM marcados paraprogramas fonte, aplicando uma transformação direta (não são geradas versõesintermediárias de modelos). O processo consiste em uma seqüência de passos para se obterprogramas de forma automática, por meio do uso de uma ferramenta a partir de umdiagrama de classes UML marcado.

No PROGERAS, o desenvolvimento começa com a elaboração do Modelo deDomínio e a próxima tarefa consiste da criação da estrutura do software. Essa estruturaserá projetada tomando como referência os interesses arquiteturais relevantes, que podemser identificados e projetados com base nos requisitos não funcionais que a aplicaçãoprecisa atender, o que pode ser feito por meio de cenários.

Os elementos do diagrama de classes (domínios, classes, atributos e operações)são marcados para indicar os padrões de projeto que se deseja utilizar no projeto daarquitetura. As marcações indicam o interesse arquitetural e o padrão de projeto que seráutilizado. Juntas, essas duas informações vão permitir que uma ferramenta selecione eexecute o template correspondente.

Uma ferramenta de geração de programas fonte compatível com o PROGERASpoderá trabalhar com múltiplos templates, um para cada padrão de projeto. Por exemplo,para o interesse arquitetural de persistência, haverá um template para implementar opadrão de projeto DAO com acesso ao banco de dados via ODBC e outro para o DAO queusa a API do driver nativo. No capítulo seguinte é mostrado um exemplo de uso doprocesso e das regras de marcação.

EXEMPLOS

Exemplo de Uso do Processo de Geração Automatizada de Programas Fonte

A descrição a seguir mostra um exemplo de aplicação do processoPROGERAS. Este exemplo consiste de um software real, que foi construído para aCompugraf® Comunicação Empresarial para automatizar o procésso de reembolso dedespesas de funcionários. Nesta empresa os funcionários podem fazer reembolsos dedespesas e de estudos. As despesas reembolsadas são aquelas que os funcionários incorremao atender um cliente ou fornecedor, como deslocamento, hospedagem, refeição, dentreoutras. A empresa também reembolsa cursos universitários, línguas e cursos técnicos.

O exemplo aqui apresentado foi simplificado (devido á restrição de tamanhodeste texto), o projeto original aborda também reembolso para terceiros (prestadores deserviços), reembolso de deslocamentos com veículo próprio, notas de débito entreempresas, múltiplas alçadas de aprovação, dentre outras funções. O sistema original temaproximadamente 40 entidades de negócio.

1.1. Contexto

A empresa tem aproximadamente 200 funcionários, que estão espalhados emquatro filiais, dispersas geograficamente. Três delas estão no estado de São Paulo e uma noRio de Janeiro. Os funcionários de todas as filiais podem fazer reembolsos.

1.1.1. Despesas

Depois de pagar com recursos próprios uma despesa para o atendimento de umcliente ou fornecedor, o funcionário deve prestar contas à empresa para receber de volta ovalor gasto. Para isso é necessário apresentar o "Relatório de Prestação de Contas deDespesas" com os seguintes dados:

• Identificação do funcionário

• Identificação do cliente ou fornecedor

• Identificação do projeto (opcional)

• Descrição da finalidade da despesa

• Relação dos comprovantes associados (cupons ficais, notas fiscais, recibos, etc.)

O funcionário deve apresentar este relatório, mais os comprovantes em anexo,ao seu gerente para aprovação, por meio de uma assinatura. Na ausência de um gerente umdiretor da empresa também pode aprovar. Depois de aprovado o relatório deve serencaminhado à área financeira, que vai contabilizar as despesas (por tipo: refeição,combustível, estacionamento, etc.) e provisionar o pagamento. Caso algum comprovantenão seja válido, o relatório poderá ser recusado pela área financeira e o funcionário teráque refazê-lo. Os pagamentos ocorrem duas vezes por semana, às terças-feiras e às quintas-feiras.

Caso o funcionário conheça antecipadamente o valor da despesa, ele poderápedir um adiantamento em dinheiro. Este pedido é feito por gerente ou diretor usando umformulário específico, no qual são indicadas as seguintes informações:

• Identificação do funcionário

• Descrição do motivo da despesa

• Valor

O formulário deve ser encaminhado ao departamento financeiro, que vaiprovisionar o pagamento. Depois o funcionário terá que prestar contas por meio do"Relatório de Prestação de Contas de Despesas". Caso o funcionário ainda seja credor, elereceberá o valor da diferença, caso ele seja devedor ele terá que devolver o saldo.

1.1.2. Estudos

A empresa tem a política de reembolsar despesas com estudos para todos osfuncionários que tenham no mínimo seis meses de registro. O padrão é reembolsar o doisterços do valor do curso, sendo que a somatória dos reembolsos de um mês não podeultrapassar 20% do valor do salário bruto do funcionário. A critério do gerente, o cursopode ser reembolsado integralmente e o valor não será abatido da bolsa de estudos (20%do salário).

Somente determinados tipos de cursos podem ser reembolsados, que sãoaqueles associados à função que o funcionário desempenha na empresa. Podem ser cursosuniversitários, cursos de línguas e cursos técnicos. Cabe ao gerente do funcionário avaliaro curso e autorizar o reembolso, na ausência do gerente um diretor pode fazer a aprovação.Para ter direito ao reembolso, quando o funcionário planejar fazer um curso ele deveráantes preencher um "Formulário de Solicitação de Reembolso de Estudo", no qual deveráinformar os seguintes dados:

• Identificação do funcionário• Descrição do curso

• Instituição

• Duração do curso

• Datas e valores das parcelas

• Percentual de reembolso

• Valor a ser abatido da bolsa de estudos

O funcionário deve apresentar este formulário aò seu gerente para aprovação,por meio de uma assinatura. Na ausência de um gerente um diretor da empresa tambémpoderá aprovar. Ao aprovar o gerente deverá indicar no formulário se o reembolso deveráser abatido da bolsa de estudos e se o reembolso é integral (e não de dois terços). Depois oformulário deverá ser encaminhado ao departamento pessoal. Somente cursos previamenteaprovados poderão ser reembolsados.

Posteriormente, o funcionário deverá efetuar o pagamento de cada parcela comrecursos próprios e depois solicitar o reembolso. Para receber o reembolso, o funcionárioterá que preencher o "Relatório de Solicitação de Reembolso de Estudos", indicando asseguintes informações:

• Identificação do funcionário

• Descrição do curso

• Instituição

• Data e valor da parcela

O formulário deverá ser encaminhado ao departamento pessoal, que calculará ovalor do reembolso, considerando a bolsa mensal e os valores previamente aprovados pelogerente do funcionário (ou um diretor). O departamento pessoal encaminhará para odepartamento financeiro uma solicitação para que o pagamento seja contabilizado e provisionado.1.2. Requisitos

O processo PROGERAS começa com o levantamento dos requisitos funcionais,não-funcionais e tecnológicos, que vão orientar o arquiteto na especificação da arquiteturae, por conseguinte, na marcação do modelo.

1.2.1. Requisitos Funcionais

Considerando a sistema de reembolsos, o software deverá apresentar asseguintes funcionalidades:

• Consultar o banco de dados de funcionários (identificação, departamento, gerente,salário, data de contratação, conta corrente).

• Prover mecanismo para um gerente ou diretor solicitar um adiantamento para ofuncionário.

• Prover mecanismo para o departamento financeiro contabilizar e provisionar opagamento do adiantamento ao funcionário.

• Prover mecanismo para o funcionário fazer a prestação de contas de despesas.

• Prover mecanismo para o gerente do funcionário, ou um diretor da empresa,aprovar um relatório de prestação de contas.

• Prover mecanismo para o departamento financeiro contabilizar e provisionar opagamento de despesas ao funcionário.

• Prover mecanismo para o funcionário solicitar a aprovação de um curso.

• Prover mecanismo para o gerente do funcionário, ou um diretor, aprovar o curso, ovalor do reembolso (dois terços ou integral) e indicar se o curso será abatido dabolsa ou não.

• Prover mecanismo para o departamento pessoal controlar o uso da bolsa de estudospelos funcionários.

• Prover mecanismo para o funcionário solicitar o reembolso de um curso.• Prover mecanismo para o departamento financeiro contabilizar e provisionar opagamento de um curso ao funcionário.

• Prover mecanismo para parametrização dos reembolsos: percentual da parcela,percentual do salário, datas de pagamento, dentre outras.

1.2.2. Requisitos Não-funcionais

O sistema deve respeitar aos seguintes requisitos:

• Funcionalidade:

o Precisão - os valores dos reembolsos devem ser calculados com precisão deduas casas decimais.

o Interoperabilidade - o sistema deverá ser integrado ao sistema decontabilidade e folha de pagamento, sem denegrir o desempenho ou asegurança destes sistemas, para consulta e atualização de dados.

o Segurança - deve haver um controle de segurança parametrizável de modoque somente as pessoas autorizadas possam aprovar reembolsos e

pagamentos. Somente os usuários autorizados poderão visualizar os saláriosdos funcionários da empresa e alterar os parâmetros do sistema.

• Confiabilidade:

o Recuperabilidade - em caso de falha o sistema não poderá ficar fora do arpor mais que 24 horas.

• Facilidade de Uso (Entendimento, Aprendizado, Operação):

o O sistema será utilizado por todos os funcionários da empresa, espalhadosgeograficamente. Os funcionários não poderão ser treinadosindividualmente no uso do sistema, sendo assim este .deve ser de fácil uso eaprendizado.

•Facilidade de Manutenção:o Facilidade de ser Analisado - o sistema será instalado nos terminais detodos usuários espalhados geograficamente. No caso de algum erronormalmente não será possível enviar um desenvolvedor ao local paraanalisar e resolver o problema. Desta forma o sistema precisará gerar Iogsque possam ser enviados para área de TI para que possam ser analisados,que indiquem as operações efetuadas pelo sistema mais os dadosassociados.

o Facilidade de mudança - na fábrica de software da Compugraf® trabalhamaproximadamente 30 desenvolvedores (na data de elaboração desde texto) equalquer um deles deve poder fazer eventuais manutenções neste sistema.

1.2.3. Requisitos Tecnológicos

A empresa já possui outros sistemas em produção, e o sistema de reembolsosdeverá ser compatível com a plataforma existente:

• Banco de Dados MS-SQL Server® 2005.

• Ser programado em C# com .NET 3.5.

• Usar a tecnologia WPF para construção das telas e respeitar o padrão de cores,fontes, dentre outros da empresa (no .NET é chamado de tema).

• Ser distribuído através intranet usando a tecnologia ClickOnce.

• Poder ser executado em estações com Windows XP®, 2MB de memória e usar nomáximo 2M do disco rígido.

• Fazer controle de acesso por meio dos dados cadastrados no Active Direetory.

1.3. Modelo de Domínio

O modelo de domínio, representado na figura 3.1, é compostos pelos domínios"Funcionário", "Reembolso" e "Financeiro". No do domínio "Funcionário" estão asentidades associados aos dados dos funcionários que fazem reembolso e aos chefes queaprovam:• Funcionário: um funcionário da empresa, pode ser chefe ou não. Nesta tabelaexistem os atributos. nome, departamento, cargo, salário, data de contratação,gerente do departamento.

• Empresa: dados da empresa onde o funcionário está registrado. A Compugraf® écomposta por cinco diferentes razões sociais.

• DadosFuncionario: dados do funcionário específicos ao processo de reembolso dedespesas e estudos, como valor mensal da bolsa de estudos, percentual dereembolso por curso, e se o funcionário está autorizado a fazer reembolso deestudos.

• CursoFuncionario: registro de um curso do funcionário, para que ele possa fazer oreembolso de estudos.

• ParcelaCurso: parcelas do curso, para o funcionário solicitar reembolso

No domínio "Reembolso" estão as entidades associadas às solicitações dereembolso e as aprovações:

• TipoDespesa: tipos de despesas para solicitação de reembolso, como combustível,hospedagem, taxi, refeição, dentre outras.

• Projeto: projetos executados pela empresa, aos quais podem estar associados umaou mais despesas de funcionário.

• ComprovanteDespesa: registro de um comprovante de despesa, como um cupomfiscal ou uma nota fiscal. Cada comprovante deve estar associado a um tipoespecífico de despesa.

• Reembolso: solicitação de reembolso de despesa, que deve estar associado a um oumais comprovantes quando se tratar de reembolso de despesas ou a uma parcela decurso, quando for reembolso de estudos. Quando for uma despesa pode estarassociado a um projeto.

• Adiantamento: registro de um adiantamento dado a um funcionário.Finalmente há o domínio "Parametros", onde estão as entidades associadas àparametrização do sistema:

• ParametrosCalculo: parâmetros para o cálculo dos valores de reembolso de estudose datas de pagamento, e para contabilização dos reembolsos.

1.4. Projeto da Arquitetura

O Sistema de Reembolsos deverá ser integrado com outros três sistemas,descritos na figura 3.2:

• Contabilidade: integração por meio de um WebService, no qual há um serviçopara enviar para a contabilidade os dados de um pedido de reembolso ouadiantamento.

• Folha de Pagamento: neste sistema estão contidas, dentre outras, as entidadesfuncionário e departamentos. A integração deverá ser feita por meio de uma DLL,na qual estão contidas os objetos de negócio deste sistema. O Sistema deReembolsos vai instanciar objetos e chamar os métodos pertinentes.

• Projetos: neste sistema estão as entidades de projetos, itens do projeto, condiçõesde pagamentos dentre outras. A integração será feita da mesma forma que com aFolha de Pagamento.

O Sistema de Reembolsos será estruturado em camadas, por meio do padrão deprojeto LAYERS. Este padrão arquitetural é usado para dividir a arquitetura em camadas,de modo a facilitar a implementação e manutenção do sistema. Criando blocos com baixoacoplamento e alta coesão. As camadas são implementadas para se comunicarem umascom as outras respeitando uma seqüência específica de mensagens. Num projeto bemconstruído uma camada A usa os serviços da camada B, mas a camada B não usa osserviços de A - comunicação flui numa única direção. O Sistema de Reembolsos serácomposto pelas seguintes camadas:

• User Interface Layer (UIL) ou Camada de Interface com Usuário - nesta camadaestão encapsuladas as telas do sistema, usadas pelos usuários.• Application Layer (APL) ou Camada de Aplicação - nesta camada estão os objetose serviços específicos da aplicação, como mecanismos para geração de relatórios,função de login dos usuários, dentre outros.

• Business Rule Layer (BRL) ou Camada de Regras de Negócio (também conhecidacomo Camada de Serviços de Negócio) - nesta camada são providas asfuncionalidades administrativas e operacionais que o sistema precisa suportar. Porexemplo, criação de reembolso, aprovação, concessão de adiantamentos, dentreoutros.

• Business Entitties Layer (BEL) ou Camada de Entidades de Negócio - nestacamada residem as entidades de negócio com as quais os serviços de negóciooperam. Por exemplo Reembolso, Comprovante, Funcionário, dentre outros.

• Data Access Layer (DAL) ou Camada de Persistência de Objetos - nesta camadaestão implementadas as funções de leitura e gravação de objetos de negócio, queestão implementados na camada BEL.

• Infra-structure Layer (IFL) ou Camada de Infra-estrutura - nesta camada estãoimplementados serviços como tratamento de erros, geração de logs, controle deacessos (segurança) dentre outros que são utilizados pelas demais camadas.

• Data Base Layer (DBL) ou Camada de Banco de Dados - camada associada aobanco de dados, que no Sistema de Reembolsos será implementada por meio doMS-SQL Server®.

De modo a reduzir o acoplamento entre as camadas, cada uma delas seráacessada pelas demais por meio de uma fachada, aplicando-se o padrão de projetoFACADE. Este padrão faz com que exista um único ponto de acesso, reduzindo oacoplamento entre as partes do sistema.

Com base nos requisitos apresentados (funcionais e não-funcionais) osseguintes interesses arquiteturais podem ser identificados: apresentação, persistência,controle de acesso, geração de logs e tratamento de erros. No PROGERAS não háimposição de um conjunto padrão de passos para identificação dos interesses arquiteturais,neste projeto foi usada uma abordagem para seleção de aspectos na programação comAspectJ. Cada interesse deve ser especificado e construído como um aspecto separado daarquitetura, que deverá ser implementado por meio de um padrão de projeto. Cada padrãode projeto é definido para maximizar ou minimizar algumas características da aplicação,como maximizar o desempenho, minimizar o uso de recursos, facilitar a manutenção,dentre outros, que são os requisitos não-funcionais. No PROGERAS também não éimposto um roteiro para seleção dos padrões, no projeto do Sistema de Reembolsos foiusada uma abordagem que propõe a criação de cenários de atributos de qualidade, paraescolha dos mecanismos que serão usados na construção do software (implementação dosinteresses arquiteturais).

O interesse de apresentação aplica-se a todas as entidades que poderão sercadastradas pelos usuários, como o reembolso e os comprovantes, por exemplo. Para cadaentidade que apresentar este interesse deverá ser criada uma ou mais telas, conforme anecessidade. As telas, que serão encapsuladas na Camada de Interface com Usuário, devemser construídas por meio de um padrão de projeto específico, o MODEL-VIEW-CONTROLER ou MVC. Neste padrão estão claramente separadas a máscara da tela(VIEW), as funções de controle (CONTROLER) e as entidades de negócio (MODEL). OMYC simplifica as mudanças de aparência nas telas (look-and-feel skins), a personalizaçãode preferências de usuários, e as mudanças estruturais. Por meio deste padrão estesobjetivos podem ser atingidos sem que seja necessário fazer mudanças nas funções centraisdo sistema e nas regras de negócio.

O interesse de persistência aplica-se às entidades que serão persistidas embanco de dados. Neste projeto o mecanismo de persistência que será implementado pormeio do padrão de projeto DATA ACCESS LAYER (DAL) e DATA ACCESS OBJECTS(DAO). As classes que serão geradas para esta finalidade serão implementadas na Camadade Persistência. A camada de persistência (padrão de projeto DAL), tem a função deabstrair a tecnologia de banco de dados que será usada para a função de persistência dosobjetos. O padrão de projeto DAO provê uma interface abstrata para algum tipo de bancode dados (neste exemplo o MS-SQL Server®) ou mecanismo de persistência, sem expor osdetalhes técnicos associados. Para cada objeto de negócio persistente é criado uma ou maisclasses nas quais estão implementadas as funções de persistência. A maior vantagem destepadrão é proporcionar uma separação clara e simples das camadas de negócio epersistência, que podem evoluir independentemente. Por meio do DAO mudanças numacamada normalmente resultam em pequeno impacto na outra.

Por meio do interesse arquitetural de controle de acesso, que está associado aorequisito de segurança, deverá ser possível indicar quais usuários podem acessar cadaentidade. Este interesse aplica-se somente às entidades críticas, como a entidadefuncionário, por exemplo, onde estão registrados informações sigilosas como o salário decada colaborador. Para este interesse deverá ser utilizado o padrão de projeto FIREWALLPROXY. Por meio deste padrão a permissão de acesso pode ser verificada cada vez queum serviço é requisitado, como os serviços providos pelas camadas de persistência eapresentação, por exemplo. As classes geradas ficarão contidas na Camada de Infra-estrutura.

O interesse de monitoração pode ser aplicado às classes mais acessadas, a fimde monitorar-se o volume de acessos de consultas, atualizações e inclusões. Desta formaserá possível avaliar-se, em tempo de execução, a quantidade de recurso e processamentoconsumido. A monitoração deverá ser feita por meio do padrão HEART BEAT. Por meiodeste padrão é possível monitorar uma tarefa específica, para saber se e como ela estáfuncionando. As classes geradas ficarão contidas na Camada de Infra-estrutura.

O interesse de tratamento de erros será utilizado em todo o sistema a fim depadronizar o mecanismo utilizado para lidar com as situações de erro. A função detratamento de erros será implementada por meio dos padrões de projeto RECOVERYBLOCKS, MINIMIZE HUMAN INTERVENTION, MAINTENACE INTERFACE,SOMEONE IN CHARGE, ESCALATION e FAULT OBSERVER. Estes padrõesprovêem meios para detectar os erros, gerar Iog e notificar alguém sobre sua ocorrência. Asclasses geradas ficarão contidas na Camada de Infra-estrutura.

Finalmente, o interesse de geração de logs será utilizado pelos mecanismosassociados aos demais interesses para gerar logs para futura análise, pelo administrador dosistema. Poderão gerar logs, por exemplo, das funções de tratamento de erros e demonitoração. A função de geração de logs deverá ser implementada por meio do padrão deprojeto LEADER/FOLLOWERS, que permite gerar Iogs com pouco impacto nodesempenho do sistema. Estas funções serão implementadas na Camada de Infra-estrutura.

1.5. Marcação do Modelo

Os artefatos do Modelo de Domínio (domínios, classes, atributos e relações)serão marcados para indicar os padrões que serão usados na implementação de cadainteresse arquitetural. Alguns exemplos de marcas associadas à classe "Reembolso", estãoindicadas na tabela 2.

Todas as classes de negócio serão marcadas com o aspecto"aspBusinessEntity", mais o padrão "BEL", para gerar os programas fonte da camada deentidades de negócio (BEL). Este padrão tem um parâmetro adicional que é o rótulo (Iabel)da classe, este rótulo será usado como título das telas e em mensagens de erro e log. Paraos atributos marcados também existem outros parâmetros para indicar se o atributo aceitavalor nulo (Null=true), rótulo, regras de consistência (validation) e tamanho do campo(size). Associado ao padrão "BEL" e interesse "aspBusinessEntity" deve haver umconjunto de templates que serão processados por uma ferramenta para gerar os programasfonte.

Por meio da parametrização do interesse de persistência o arquiteto vai indicaro mecanismo que deve ser usado para persistência dos objetos. Para usar o padrão DAOcom banco de dados relacionais, é indicado o padrão DAODB com o parâmetro"Write=true" para indicar que este classe permite atualização. Para indicar que devem sercriados mecanismos para carregar objetos com base no atributo "TipoReembolso", esteatributo é marcado com o parâmetro "ReadBy=true". Para indicar os mecanismos dacamada de armazenamento de dados, que será encapsulada no banco de dados, indica-se ointeresse arquitetural de armazenamento de dados. O padrão "DDL+DML" é usado paragerar os scripts para criação das tabelas e índices (DDL - Data Definition Language) maisos scripts para criar as stored procedures para fazer INSERT, DELETE e UPDATE nestastabelas.

O mecanismo de controle de acesso é gerado na camada de infra-estrutura(IFL), por meio da marca associada ao interesse arquitetural "aspUserAccessControl", queserá construído por meio do padrão de projeto FIREWALL PROXY. Na camada depersistência de todas as classes marcadas com este padrão, será inserido uma verificação depermissão de acesso dos usuários, em todas as funções de leitura, atualização, exclusão einclusão.

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

Tabela 2 - Exemplos de marcas associadas à classe "Reembolso"

O mecanismo de geração de Iog é especificado por meio do interesse"aspTracking". O padrão "LOGCG" foi definido na Compugraf® para indicar, em cadaregistro de cada tabela do banco de dados, os dados da última atualização feita no registro:nome do usuário, data e hora, identificação do sistema usado e motivo da atualização.

1.6. Geração dos Programas Fonte

Associado a cada padrão há um ou mais templates, que serão processados poruma ferramenta para gerar os programas fonte. Por exemplo, para o interesse depersistência, padrão DAODB, foram criados os seguintes templates·.• DAO.cs - este template é processado uma vez para cada entidade persistente, paracriar a classe responsável pelas funções de persistência. O nome da classe geradaterá o prefixo "dao", como "daoReembolso.es".

• DaoFacade.cs - este template é processado apenas uma vez para gerar umafachada, por meio do padrão de projeto FACADE, para a camada de persistência(DAL). Na fachada serão gerados os métodos para carregar, atualizar, apagar eincluir objetos, como "Reembolso_ReadObject(long id)" e"Reembolso_WriteObject( beReembolso oReembolso)".

• Repository.cs - este template é processado apenas uma vez para gerar uma classeonde estão os métodos de acesso ao banco de dados. Tem métodos para conectar,desconectar, iniciar uma transação, dentre outros.

A ferramenta de geração de programas fonte vai receber como entrada asdefinições do projeto (linguagem de programação, diretórios onde os arquivos serãoarmazenados, dentre outras informações) e o diagrama de classes UML. Depois vaiprocessar o diagrama e montar internamente um grafo com as classes e os interessesespecificados. Para cada interesse a ferramenta vai elencar os padrões parametrizados e vaiprocessar os templates associados. A estrutura de uma ferramenta está representada nasfiguras 2.2 e 2.3.

Quando for necessário usar um padrão para o qual ainda não existem ostemplates, estes precisarão ser criados antes que os programas fonte sejam gerados. Podeser necessário, inclusive, definir-se um novo interesse arquitetural, por exemplo, ointeresse de distribuição, serialização de objetos, dentre outros.

1.7. Programação Manual

As regras de negócio precisarão de programadas, pois o PROGERAS permiteespecificar e gerar somente as rotinas de infra-estrutura. Por exemplo, para criar um objetopara reembolso de estudos, é necessário calcular o valor do reembolso (normalmente doisterços da parcela) e a somatória dos reembolsos já pagos no mês. Neste projeto partes doprograma serão construídas manualmente: algumas telas, os relatórios e alguns scripts SQL(por exemplo os scripts de backup).1.8. Conclusão

Acima, foi apresentado um exemplo de aplicação do PROGERAS, e foidemonstrado como o processo deve ser usado. Entretanto, fica implícito para aquelesversados na técnica, que o exemplo acima não constitui uma limitação da invenção, sendoobservado que o processo para a geração de programas fonte, aqui denominadoPROGERAS, permite que seja possível especificar processos de negócio, de modo que asrotinas associadas também possam ser geradas automaticamente, sendo a sua limitaçãounicamente de acordo com as reivindicações anexas.

Por meio do processo PROGERAS é proposto um processo de geraçãoautomática de programas fonte com base no MDA. Para orientar o processo de geração decódigo, são usadas regras de marcação padronizadas, inseridas em modelos UML por meiode tagged values, extensões e anotações. Essas regras indicam o interesse arquitetural e opadrão de projeto que deverá ser usado ao gerar os programas fonte. O PROGERAS éproposta de extensão ao MDA, aplicando os conceitos do AOD e do POA para gerarprogramas fonte de forma automatizada a partir de um diagrama de classes (PIM). Comessa proposta, acredita-se ser possível não só obter um elevado nível de automação noprocesso de produção do software, forçar o uso de padrões, aumentar a qualidade e aconsistência, como também ganhar produtividade.Lista de Abreviaturas e Siglas

ACMDA Architecture-Centric Model-Driven Arehiteeture

ADL Arehiteeture Deseription Language

AOAD Aspeet-Oriented Arehiteeture Design

AOD Aspeet-Oriented Design

AOM Aspeet-Oriented Modeling

AORE Aspeet-Oriented Requirements

AOP Aspeet-Oriented Programing

AOSD Aspeet-Oriented Software Development

CIM Computer-Independent Model

CSV Comma Separated Value

CTI Computer Telephony Integration

IDE Integrated Development Environment ,

GUI Graphie User Interface

LOC Lines Of Code

MDA Model-Driven Arehitecture

MDD Model-Driven Development

MDE Model-Driven Engineering

MOF Meta-Objeet Faeility

PIM Platform-Independent Model

OMG Objeet Management Group

POA Patter-Oriented Arehiteeture

PSM Platform-Specific Model

PROGERAS Processo para geração automatizada de softwareUML Un ified Model ing Language

XMI XML Metadata Interchange

CAMPOS da Figura 6:

Campo A

- Sequencia : int = 1

- DataVencimento : Date

- Valor : float = O- ValorReembolso : float: = O

- FlagAbaterAuxilioEstudo : boolean = true

- DataAprovacaoChefe : Date

Campo B

- Curso : String

- Instituição : String

- DataInicio : Date

- DuracaoMeses : int

Campo C

- MaxAuxilioEstudo : float

- PercentualReembolsoCursos : float

- FazReembolsoEstudo : boolean

- UserId : String

Campo D

-DataPedido : Date

- DataAprovacaoChefe : Date

- DataAprovacaoDiretor : Date

- DataAprovacaoFinanc : Date

- DataPagamento : Date- Finalidade : String

- ValorReembolso : Float

- DataContabilizacao : Date

- TipoReembolso : String

Campo E

- Numero : String

- DataEmissao : Date

- Valor : float

- Fornecedor : String- Itinerário : String

- Quilometragem : float = 0

- Observacao : String

Campo F

- Data : Date

- Valor : float

- Finalidade : String

- DataVencimento : Date

- DataContabilizacao : Date

CampoG

- PercenbtualReembolsoEstudo : float = 0.66F

- PercenbtualMaxReembolsoSobreSalario : float = 0.2F

- DiaPagamentoReembolsoEstudo : int = 20

- DiaSemanaPagamentoReembolsoDespesa : int = 3

- PeriodoMesesParalnicioReembolsoEstudo : int = 6

- IntervaloContabilizacao : int

- EventoAdiantamentoCLT : int

- EventoAdiantamentoKFD : int

- EventoReembolsoDespesaCLT : int

- EventoReembolsoDespesaKFD : int

- EventoAbatimentoemFolhaCLT : int

- EventoAbatimentoemFolhaKFD : int

- EventoReembolsoEstudoCLT : int

- EventoReembolsoEstudoKFD : int

- EventoNotaDebito : int

- LimiteAprovacaoDiretor: float

- DiasParaSolicitacaoReembolsoEstudo : int

Claims (7)

1.) "PROCESSO PARA GERAÇÃO AUTOMATIZADA DE SOFTWARE",caracterizado por compreender as etapas de:a) levantamento de requisitos;b) criação de modelos de domínio;c) projeto de arquitetura;d) marcação do modelo de domínio;e) geração de programas fonte;f)adição manual de linhas de programa; eg) geração de software executável.

2.) "PROCESSO", de acordo com a reivindicação 1, caracterizado pelo projeto dearquitetura compreender o uso de templates para geração do programa fonte.

3.) "PROCESSO", de acordo com a reivindicação 2, caracterizado pelos templatesconsistirem como adendos nos quais são definidos pontos de junção de interessesarquiteturais.

4.) "PROCESSO", de acordo com a reivindicação 1, caracterizado pela marcação demodelo de domínio utilizar elementos do diagrama de classes marcados com base noprojeto de arquitetura e no padrão de regras de marcação do processo selecionado para asua implementação permitindo que a ferramenta selecione e execute o templatecorrespondente.

5.) "PROCESSO", de acordo com a reivindicação 4, caracterizado pelas marcas sereminseridas no modelo por meio de tagged values ou anotações, tendo a forma Variável =Expressão.

6.) "PROCESSO", de acordo com a reivindicação 1, caracterizado pela geração deprogramas compreender o uso de uma ferramenta que recebe os diagramas de classes commarcações, gerando programas fonte numa linguagem específica e novos modelos quedemonstram a arquitetura do sistema.

7.) "PROCESSO", de acordo com a reivindicação 1, caracterizado pela geração dosoftware executável ser realizado pela ferramenta de geração de fonte (robôs) que recebemos diagramas UML marcados como entrada e geram os programas fonte.