Sistemas Dinâmicos Baseados em Metamodelos

Transcrição

1 Sistemas Dinâmicos Baseados em Metamodelos Diego Moreira 1, Marcelo Mrack 1 1 Setor de Informática Universidade de Santa Cruz do Sul (UNISC) Av. Independência, 2293 Bairro Universitário Santa Cruz do Sul - RS Brazil {diego,mrack}@unisc.br Abstract. The information systems have a great dependence of the data model and the processes that in them act. As consequence, any change in these elements implies in modification in the source code of the application. Although some tools help to reduce this work, the systems dependence problem persists. This paper describes a solution where the system is only the consequence of the connection between interface objects, data model and business rules. Resumo. Os sistemas de informação possuem uma grande dependência do modelo de dados e dos processos que neles atuam. Como conseqüência, qualquer modificação nesses elementos implica na alteração do código da aplicação. Embora algumas ferramentas ajudem a reduzir este trabalho, o problema da dependência do sistema continua. Este artigo apresenta uma solução onde o sistema é simplesmente a conseqüência da interligação entre objetos de interface, modelo de dados e regras de negócio. 1. Introdução Entende-se por sistema dinâmico qualquer processo que evolua com o tempo [Alves 2001]. Essa definição confronta com os sistemas construídos na área de informática, pois uma vez que o sistema foi desenvolvido, o comportamento dele durante todo seu ciclo de vida é exatamente o mesmo 1. Esse comportamento está ligado diretamente ao processo de construção do software, onde o código-fonte do sistema é projetado para responder às entradas do usuário com saídas pré-definidas. Essas entradas e saídas, mostradas em uma interface também programada, são baseadas geralmente em um conjunto de processos e dados que interagem mutuamente. Dessa forma, a relação entre o sistema que implementa o modelo de dados e os processos é muito grande. A conseqüência disso é que a cada vez que o modelo de dados ou o processo é alterado, o código-fonte do sistema deve ser modificado para suportar as necessidades das novas entradas e saídas. 1 Os chamados sistemas baseados em inteligência artificial podem apresentar uma certa evolução durante o tempo. Entretanto essa evolução nada mais é do que a inserção de mais informações dentro do sistema, o que, dentro de um intervalo de tempo, faz com que as respostas do sistema sejam modificadas.

2 A abordagem utilizada para minimizar esse problema é a utilização de ferramentas para geração do código ou até mesmo do sistema inteiro. Essas ferramentas, freqüentemente chamadas de RAD (Rapid Application Development), conseguem gerar grande parte do código da aplicação que, com alguns ajustes, rapidamente entra em operação. Entretanto, a utilização destas ferramentas não resolve o problema como um todo, uma vez que a cada modificação no processo ou no modelo de dados, a geração do código deve ser executada novamente, implicando em custos de compilação, testes e distribuição. Este trabalho apresenta uma alternativa para a construção de sistemas, onde a geração de cógido é substituída por um mecanismo de interpretação, que interliga os elementos de interface, as regras de negócio e o modelo de dados durante a execução do programa. A seção 2 faz uma comparação entre os geradores de código e os geradores de aplicação. A seção 3 apresenta a arquitetura e vantagens da solução proposta. A seção 4 situa a arquitetura no contexto do processo de desenvolvimento de sistemas. A seção 5 apresenta um exemplo de uso. 2. Geradores de Código e Geradores Aplicações Neste artigo, é feita uma separação entre dois tipos de ferramentas que podem ser usadas no desenvolvimento de sistemas. Apesar de ambas serem consideradas ferramentas CASE (Computer Aided Software Engineering), cada uma possui ênfase diferente. As duas próximas subseções abordam cada uma delas. 2.1 Geradores de Código Um gerador de código é uma ferramenta de auxílio ao processo de desenvolvimento de sistemas que atua na fase de implementação do projeto, gerando o código-fonte que seria criado pelo programador. De forma geral, esses geradores criam o código-fonte com base nas informações existentes no modelo de dados. Isso significa que os ganhos obtidos ficam restritos à interface de cadastro, listagens de registros ou telas de baixa complexidade. Apesar do código produzido ser correto, algumas características indesejáveis são geralmente encontradas nesse tipo de ferramenta: Funcionamento em uma via: O código é gerado em um único sentido. Assim, uma vez que o modelo de dados é modificado, a geração deve ser reexecutada. Caso o código existente tenha sido modificado pelo programador, essas alterações são perdidas e devem ser refeitas. O padrão de código é dependente da ferramenta: O código produzido geralmente não está de acordo com o padrão de codificação da equipe de desenvolvimento. Código de baixa qualidade: O código gerado não leva em consideração questões de desempenho, otimização, estrutura, integração com outros sistemas ou documentação. Ainda sobre os geradores de código e suas utilizações no processo de desenvolvimento de sistemas, cabe salientar que todo o software está propenso à

3 manutenções. Isso implica em um retrabalho de (i) geração do código, (ii) ajuste do código gerado, (iii) compilação, (iv) testes e (v) distribuição da nova versão do sistema. 2.2 Geradores de Aplicação Um gerador de aplicação é uma ferramenta de automação do processo de desenvolvimento de sistemas, podendo atuar em todo ciclo de vida da aplicação. Por esse motivo, os artefatos produzidos por esta ferramenta são outros. Além do códigofonte, é possível gerar interfaces de aplicação, documentação para o desenvolvedor ou usuário, descrição de processos, métricas, estimativas, especificações de projeto e arquitetura, planos e outros. Ao comparar os dois tipos de geradores, pode-se afirmar que os geradores de aplicação englobam os geradores de código, como mostra a Figura 1: Gerador de aplicação Gerador de código Figura 1. Comparação entre geradores de aplicações e geradores de código Dessa forma, percebe-se que um gerador de código faz parte de um gerador de aplicação e, como conseqüência, os problemas relacionados ao processo de manutenção do software persistem. Em outras palavras, isso quer dizer que, caso os requisitos do sistema mudem, os passos comentados no último parágrafo da subseção anterior devem ser refeitos. 3. Arquitetura Uma alternativa para contornar esse problema é suprimir o processo de geração de código-fonte. Assim, durante o processo de desenvolvimento do sistema, nenhum código de aplicação é gerado. Em outras palavras, a aplicação é construída em tempo de execução - os objetos de interface são criados na inicialização do sistema e as regras de negócio são mapeadas dinamicamente para esses objetos. A conseqüência direta dessa abordagem é que o processo de manutenção pode ocorrer sem alterações de código, exigindo apenas um remapeamento das regras de negócio e os objetos que as utilizam. Outras conseqüências são: Redução dos custos com manutenções: Como não existe código-fonte, não há esforços para ajustá-lo. Agilidade na disponibilização de novas versões: Como o tempo de manutenção do sistema é geralmente proporcional ao tempo de remapeamento das regras de negócio, tão logo esse remapeamento seja feito, a nova versão do sistema entra em funcionamento. Prototipação integrada: Como a aplicação é construída em tempo de execução, basta executar o gerador para que um protótipo totalmente funcional esteja disponível.

4 Não há recompilação: Como não existe modificação no código da aplicação, não existe recompilação do sistema. Não há redistribuição da aplicação: Como o arquivo executável da aplicação não é modificado, e sim apenas as especificações de entrada do gerador, não é necessário redistribuir uma nova versão do sistema. Qualidade do sistema: Como o processo de geração da aplicação é automatizado, pode-se pressupor que a aplicação está correta por natureza. Documentação: Uma vez que o gerador tenha as especificações do sistema, é possível gerar documentos de especificação de telas, manuais de uso, objetos utilizados, mecanismos de auxílio entre outros. Padronização de aplicações: Como as aplicações são geradas pela mesma ferramenta, as interfaces do usuário e a arquitetura dos sistemas seguem o mesmo padrão de interface, teclas de atalho, estilo de janelas, comandos, etc. A arquitetura que implementa essa abordagem é mostrada na Figura 2: Regras de negócio Aplicação Modelo de dados Metagen especificador Elementos de inferface Metagen gerador Metamodelo SGBD Tempo de projeto Tempo de execução Figura 2. Arquitetura do gerador de aplicações dinâmicas Percebe-se na Figura 2 duas separações: Tempo de projeto e Tempo de execução. No tempo de projeto são especificados o modelo de dados, as regras de negócio e os elementos de interface que constituem a aplicação. No tempo de execução está a aplicação final que possui no seu interior um mecanismo de geração. Entre essas duas partes ficam o banco de dados e o metamodelo. O modelo de dados é a representação formal e estruturada dos requisitos de dados do usuário. Ele é definido pelo analista de sistemas e é criado com o uso de uma ferramenta de modelagem de dados, como o AllFusion ERwin. As regras de negócio são os processos que atuam sobre os dados do usuário. Elas definem as relações existentes entre os dados, seus estados válidos, seus ciclos de vida e as transformações que eles podem sofrer. De uma forma geral, as regras de negócio dividem-se em dois grupos:

5 Regras de consistência: Definem a integridade entre estados válidos da base de dados. Regras de atividade: Descrevem seqüências de operações que devem ser realizadas para atender uma determinada função do sistema. O Sistema de Gerenciamento de Banco de Dados (SGBD) é o mecanismo responsável pela persistência e controle dos dados, devendo ser capaz de disponibilizar os dados durante todo o tempo de execução do sistema. Na arquitetura proposta, o banco de dados é implementado por um SGBD relacional, como o Microsoft SQL Server e o PostGreSQL. No centro da Figura 2 está a ferramenta de projeto denominada Metagen. O Metagen é responsável pela importação das informações contidas no modelo de dados, pelo armazenamento das regras de negócio e pela definição das interfaces que constituem a aplicação cliente. Como meio de persistência das informações contidas no Metagen está o Metamodelo. A aplicação cliente é o resultado final do processo e é produzida através de um mapeamento de regras de negócio e de geração automática de interfaces. Essas informações estão armazenadas no metamodelo. Com as tecnologias dos SGBD atuais, as regras de consistência podem ser armazenadas dentro do próprio banco de dados na forma de rules, constraints e triggers. Por outro lado, devido à complexidade [Klinger 2000], as regras de atividade devem ser armazenadas em um mecanismo à parte. O mecanismo utilizado na arquitetura proposta é baseado nos trabalhos de [Mrack 2001], [Klinger 2000], [MDC 1999] e [OMG 2001]. 4. Processo de Desenvolvimento Como observado na Figura 3, a relação das etapas do processo forma um ciclo, conhecido como o Ciclo de Vida do sistema - geralmente chamado de modelo espiral [Pressman 1995]. Requisitos Implantação Documentação Análise Modelagem Sistema Projeto Implementação Testes Prototipação Figura 3. Ciclo de vida A ordem da seta indica o fluxo de trabalho, iniciando com a etapa de requisitos e finalizando com a etapa de implantação. A necessidade de alteração de uma determinada etapa implica na revisão ou ajuste das etapas seguintes até a implantação. Como as manutenções geralmente envolvem alteração de requisitos, todo o fluxo deve ser seguido novamente.

6 4.1 Processo de Desenvolvimento no Contexto do Metagen No contexto do Metagen, o grupo de análise é responsável pelo levantamento dos requisitos de dados do usuário e pela tradução das regras de negócio envolvidas. Ambas as informações são armazenadas na base de conhecimento do Metagen o metamodelo. Durante o projeto é feita a relação entre os elementos do sistema, onde são relacionados o modelo de dados, as regras de negócio e os objetos que constituiem a interface da aplicação. A partir desta relação é possível especificar as entradas e saídas dos componentes que implementam as regras de negócio. Estas relações e especificações também são armazenadas na base de conhecimento. Na etapa de implementação são considerados os dois tipos de regras de negócio: de consistência e de atividade. As regras de consistência, por serem formadas basicamente de validações de dados, podem ser automaticamente mapeadas para objetos de interface. Por exemplo, um atributo de unidade federativa (UF) que é ligado a uma caixa de seleção (ComboBox). Por outro lado, devido a sua complexidade, as regras de atividade são implementadas em componentes de software [Szypersky 1998] por um programador. Esta abordagem traz três benefícios: As etapas posteriores podem ocorrer em paralelo: Como as entradas e saídas dos componentes que implementam as regras de negócio já estão definidas, é possível gerar protótipos ou até mesmo liberar módulos da aplicação que não dependem dessas regras. Reusabilidade de componentes: Como existe uma alta acoplabilidade e uma baixa coesão entre o modelo de dados e os componentes que implementam as regras de negócio, é possível reutilizar esses componentes em qualquer outro sistema. Delegação da implementação: Como as regras de negócio estão formalmente especificadas, é possível delegar a tarefa de implementação dos componentes para equipes de desenvolvimento terceirizadas (fábrica de software). A partir da especificação do modelo de dados e das regras negócio, é possível elaborar o plano de testes, que é executado em duas etapas. A primeira compreende a validação do modelo de dados com as regras de consistência. Sendo o gerador do Metagen responsável pela criação dos objetos de interface (que estão ligados diretamente às regras de consistência), pode-se pressupor que estes estão corretos por natureza. Qualquer problema apresentado nessa etapa do teste está relacionado a erros na modelagem dos dados ou no gerador. A segunda envolve a verificação das regras de atividade, através da comparação da especificação da regra de negócio com o componente que a implementa. Essa etapa também pode ser otimizada, delegando parte dos testes para o próprio usuário, que verifica se as operações executadas pelos componentes estão de acordo com suas necessidades. Outra alternativa é delegar tarefas de testes para equipes terceirizadas, uma vez que o componente está implementado e uma especificação detalhada das regras de negócio está disponível.

7 A etapa de documentação envolve, entre outras, a especificação da arquitetura, a documentação do sistema, o manual do usuário e o suporte a dúvidas freqüentes. Dentre essas informações, a única que não pode ser extraída da base de conhecimento é o suporte a dúvidas freqüentes. Entretanto, ela pode ser elaborada com base nas regras de negócio armazenadas ou durante o tempo de vida da aplicação. Além disso, uma vez que esta informação seja catalogada na base de conhecimento, ela pode ser usada em futuros desenvolvimentos. A etapa de implantação consiste na disponibilização do acesso ao arquivo executável da aplicação que contém a o mecanismo de geração do Metagen. Este mecanismo é responsável pela (i) interpretação das informações armazenadas no metamodelo, (ii) geração da interface da aplicação e o (iii) mapeamento dos objetos de interface para os componentes que implementam as regras de negócio. 5. Exemplo Esta seção mostra como a arquitetura proposta traduz as informações do metamodelo na aplicação do usuário. O exemplo mostra um sistema simples para cadastro de clientes, onde as informações prestadas são verificadas antes de serem armazenadas no banco de dados. Esta verificação é composta pela execução de uma regra de negócio e pela validação de um domínio de valores de dados. Figura 4. Exemplo do processo de geração Na figura 4, o modelo de dados está representado pela tabela cliente e seus respectivos atributos. Ligada ao atributo cpf da tabela cliente está a especificação de uma regra de negócio. Esta regra de negócio é implementada em um componente à

8 parte, que, com as tecnologias de distribuição de software atuais, pode estar escrito em qualquer linguagem de programação. Na parte superior da figura está a aplicação que o usuário interage. Essa aplicação possui uma implementação do mecanismo gerador do Metagen, o qual é responsável pela leitura e interpretação dos dados contidos no metamodelo. Com base nas propriedades das colunas da tabela cliente é possível cada uma delas para um objeto de tela que neste caso são uma caixa de texto e uma caixa de seleção. Para a caixa de texto cpf existe uma máscara de edição e para a caixa de seleção uf existe um domínio de valores. Essas informações foram obtidas através de um processo de importação de dados da ferramenta de modelagem (ex. AllFusion ERwin). Esses dois objetos de tela representam simplesmente regras de consistência. Por outro lado, o botão Validar CPF possui uma regra de negócio atrelada. Essa regra de negócio representa uma regra de atividade e está implementada em um componente externo. A partir da leitura do metamodelo, o gerador identifica a regra de negócio a ser executada, os parâmetros para sua execução e o objeto de tela a ser criado. Com essas informações o botão Validar CPF é criado e ligado ao componente que implementa a regra de negócio. A partir desse momento a aplicação fica disponível para o usuário utilizá-la. Conclusões Este artigo apresenta uma alternativa para a otimização do processo de desenvolvimento de software, tendo como premissa a geração da aplicação em tempo de execução. A partir desta abordagem, as etapas de desenvolvimento podem ser automatizadas, gerando inúmeras vantagens para o processo como um todo, entre elas: Redução dos tempos e custos de desenvolvimento e manutenção de sistemas. Aplicação de metodologia: O uso desta ferramenta permite a aplicação efetiva de uma metodologia de trabalho em todas as etapas de desenvolvimento. Qualidade: Através da automação de processos manuais, minimizam-se as ocorrências de erros, agregando qualidade e valor ao produto final. Independência de tarefas: As especificações armazenadas no metamodelo permitem que cada colaborador consiga realizar sua tarefa sem a necessidade de compreensão de todo o conjunto. Distribuição de tarefas: É possível delegar os procedimentos de implementação a terceiros e possibilitar que o usuário efetue testes e validações sobre a aplicação. Reusabilidade dos artefatos gerados: Tanto os componentes de software como a documentação armazenados podem ser reutilizados em outros sistemas. Especialização do trabalho: Cada colaborador pode especializar-se na sua área de atuação, pois grande parte das tarefas manuais é executada pela ferramenta. Não obstante as vantagens acima relacionadas, o grande benefício alcançado por esta abordagem está no direcionamento dos esforços para atividades de pesquisa na área processos, tecnologia e engenharia de software.

9 Considerações Finais O projeto Metagen está sendo desenvolvido pelo Setor de Informática da Universidade de Santa Cruz do Sul (UNISC), tendo atualmente três aplicações em uso. Atualmente, o projeto encontra-se em fase de reestruturação, onde estão sendo agregadas novas funcionalidades e recursos que permitam a operação multiplataforma. livre. A médio prazo prevê-se a disponibilização de uma implementação em software Agradecimentos Ao nosso coordenador, Sr. Hilton Dias; aos colegas Cilene, Douglas, Emerson, Julio, Laone e demais integrantes do Setor de Informática da UNISC. Referências Alves, José F.. (2001) Caos: uma perspectiva probabilística, Centro de Matemática da Universidade do Porto, January. Klinger, Daniel A.. (2000) Um Software Assistente para Especificação de Regras de Negócio, Universidade de Santa Cruz do Sul, (Dissertação Bacharelado em Ciência da Computação). MDC Meta Data Coalition. (1999) Business Engineering Model Business Rules, December. Mrack, Marcelo. (2001) Gerador de Componentes de Software Baseado em Regras de Negócio, Universidade de Santa Cruz do Sul (Dissertação Bacharelado em Ciência da Computação). OMG Object Management Architecture. (2001), htm, October. Pressman, Roger S.. (1995) Engenharia de Software, Editora Makron, São Paulo. Szypersky, Clemens. (1998) Component Software, Addison Wesley, Edinburg Gate.