FERRAMENTA CASE (GERADOR DE CÓDIGO .NET) Anderson Michereff Oliveira < andersonmic@gmail.com >

Luiz Gustavo Mählmann < mahlmann@gmail.com> - Orientador

Universidade Luterana do Brasil (ULBRA) – Curso de Sistemas de Informação – Câmpus Canoas Av. Farropilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas – RS

29 de Novembro de 2010

RESUMO Este trabalho tem como objetivo apresentar o projeto de uma ferramenta de software capaz de gerar códigos

fontes (classes) na linguagem C# .NET, tendo como objetivo principal automatizar a criação da camada de negócio de uma aplicação arquitetada em três camadas (ex. MVC), bem como gerenciar as regras de negócios implementadas nas entidades (classes) mapeadas (objeto-relacional), baseando-se em templates pré-definidos para geração das classes, onde suas estruturas são constituídas por tags conhecidas pela ferramenta, assim possibilitando a importação e geração do código fonte.

Palavras-chave: Ferramenta Case, Geração de Código; MVC; ORM.

ABSTRACT Title: “Tool Case (Code Generator. NET)”

This paper aims to present the design of a software tool capable of generating source code (classes) in C #. NET, with the main objective to automate the creation of the business layer of an application architected in three tiers (exp. MVC) as well as manage the business rules implemented in the entities (classes) map (object-relational), based on predefined templates to generate the classes, where its structures are composed of tags known to the tool, thus allowing the importation and generation source. Key-words: MVC; ORM; Tool Case, Code.

1 INTRODUÇÃO Este trabalho trata-se do projeto de uma ferramenta case para a geração de código fonte na

linguagem C# .NET. Sua finalidade principal é a criação, manipulação e geração da camada de negócio das aplicações com layouts e padrões pré-definidos por templates, tendo como missão diminuir o esforço no desenvolvimento de aplicações, a ferramenta possui como uma de suas principais característica o mapeamento objeto relacional (ORM - mapear tabelas do banco de dados em classes) (AMBLER, 2003), para isso é utilizado uma estrutura de banco de dados do tipo SQL Server já existente pela aplicação a ser recriada.

Atualmente em projetos de software três camadas (MVC), grande parte do tempo gasto para o desenvolvimento da aplicação é com a criação manual da camada de negócio, isso inclui a projeção da arquitetura interna das classes, bem como a programação das regras de negócios encapsuladas nas mesmas.

Para alcançar o objetivo principal, será necessário projetar a automatização do processo de criação da camada de negócio, assim criando uma estrutura de dados capaz de armazenar e manipular o mapeamento do Modelo ER da base de dados que será importada. Para isso serão criadas telas de cadastros e manipulação de objetos (classes), cadastros e manipulação de regras de negócio (procedimentos), cadastros de templates arquiteturais para as classes a serem geradas, geração e importação de objetos. Uma das características diferenciais que a ferramenta irá oferecer está a geração de classes baseadas em templates definidos pelo usuário utilizando tags pré-definidas pela ferramenta, o que irá permitir a flexibilidade de geração de classes em variadas arquiteturas.

1.1 Motivação

Este trabalho surgiu diante das necessidades de flexibilidade e custo das atuais ferramentas CASE hoje encontradas no mercado deste segmento. Com o crescimento do mercado de desenvolvimento de software, as empresas do setor têm demonstrado um grande interesse em alternativas que sirvam como diferencial competitivo, e é aí que entra a utilização de uma Ferramenta CASE, oferecendo recursos que podem minimizar o tempo de desenvolvimento de um software, mantendo o alto nível de qualidade.

Algumas empresas não se sentem confortáveis em utilizar uma Ferramenta Case, devido o possível grande impacto que ela pode gerar em suas rotinas de desenvolvimento de software, pois, por serem um conjunto integrado de ferramentas que podem atuar em todas as fases de desenvolvimento de software, tem um impacto considerável, exigindo novas metodologias. Porém, ainda existe outro lado, ou seja, as vantagens em se utilizar uma Ferramenta Case, que é o aumento da produtividade, melhor qualidade, diminuição dos custos, melhor gerenciamento e a grande facilidade de manutenção.

Para as empresas que adotam uma Ferramenta Case, os principais objetivos são os resultados que podem ser mensuráveis até com certa facilidade, mas com muita disciplina. Para tanto, é necessário um eficiente estudo de viabilidade para implementação de uma Ferramenta Case.

Diante deste cenário, em que empresas ainda relutam em adotar uma Ferramenta Case como solução em desenvolvimento de Sistemas, mesmo com o mercado exigindo novas técnicas em automação, as Ferramentas CASE se mostram como alternativa para empresas, desenvolvedores e, até mesmo, estudantes, impondo seus diferenciais em relação a outros tipos de ferramentas de desenvolvimento existentes no mercado.

1.2 Objetivo

O objetivo deste trabalho é desenvolver uma ferramenta geradora de código fonte compacta, otimizada e flexível, que viabilize especificamente a geração da camada de negócio das aplicações, onde serão encapsuladas as regras pertinentes a mesma, tendo como base para espelhamento da estrutura de classes um modelo de dados SQL Server já existente.

Diante da evolução do editor Visual Studio e do framework .NET, há pontos em que o próprio editor na atualidade já viabiliza, como por exemplo a facilidade da construção de variados tipos de interfaces funcionais com reutilização de códigos e construção de objetos reutilizáveis, fazendo uso do conceito de herança entre os mesmos.

O código fonte gerado na linguagem C# .NET terá sua estrutura determinada através de templates pré configurados contendo tags conhecidas pela ferramenta geradora, assim proporcionando flexibilidade de estruturação para qualquer padrão. Em função de estar sendo utilizado uma linguagem de saída orientada a objetos e o conceito da arquitetura MVC, o foco desta camada será a real implementação das regras de negócio a qual a aplicação deverá respeitar.

2 Referencial Teórico Este capítulo apresenta um breve referencial teórico sobre os temas envolvidos neste trabalho, desde

as vantagens e desvantagens da utilização de uma Ferramenta Case até as metodologias envolvidas para o desenvolvimento da ferramenta em questão.

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas ferramentas baseada em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software (WEINRICH, 1999).

Vantagens do uso de ferramentas CASE: • Qualidade no produto final; • Produtividade; • Agilizar o tempo para tomada de decisão; • Menor quantidade de códigos de programação; • Melhoria e redução de custos na manutenção; • Agilidade no retrabalho do software.

Desvantagens do uso de ferramentas CASE: • Incompatibilidade entre ferramentas; • Treinamento para utilização.

2.1 Geradores de Código Fonte Um gerador de código é um ferramenta desenvolvida para gerar automaticamente código fonte de

alto nível em linguagens de programação como .NET, C++, C#, Java e outros. Com a evolução das tecnologias e paradigmas de desenvolvimento, foi surgindo a necessidade de automatização de fases de desenvolvimento de sistemas, uma delas é o mapeamento objeto-relacional ou ORM (AMBLER, 2003), onde é possível criar, a partir de um banco de dados relacional, objetos de acesso à base de dados, onde tabela são representados como classes correspondentes, restando à equipe de desenvolvimento implementar regras de negócio e especialização das funcionalidades.

Vantagens de um gerador de código fonte (DOLLARD,2004), são: • Padronização de Código: códigos gerados através de uma ferramenta case obedecem uma

padronização, o que implica diretamente na qualidade de legibilidade, diminuindo a margem de possíveis erros decorrentes de diferentes formas de implementação.

• Eficiência: códigos gerados dentro de um padrão conhecido e testados aumentarão o índice de eficiência de suas funcionalidades uniformes.

• Produtividade: sendo capaz de realizar a construção de funcionalidades das aplicações de maneira mais eficiente e segura, garantindo também a diminuição dos custos de projeto. Sendo assim possibilitando que o foco dos desenvolvedores estejam voltados mais para as regras de negócios a serem implementadas nas entidades (classes).

• Abstração: por possuírem uma interface funcional, abstraem a interação com o modelo de dados, ou seja, no momento que o modelo sofrer qualquer alteração, as entidades pertinentes serão alteradas de acordo com suas entradas ou saídas.

2.2 Modelos Arquiteturais

Padrões de projetos são soluções para problemas que alguém um dia teve e resolveu aplicando um modelo que foi documentado e que você pode adaptar integralmente ou de acordo com necessidade de sua solução. Será abordado neste tópico o padrão de modelo MVC, que tem por objetivo básico separar a lógica de negócio da apresentação (MACORATTI.NET, 2010).

O paradigma orientado a objetos está intimamente ligado á arquitetura que foi utilizada para construir a ferramenta. A tendência indica que esta arquitetura estará baseada na organização da aplicação em camadas e na observação dos padrões utilizados pelo mercado. A organização em camadas é a chave para a independência entre os componentes, em conseqüência deste fato é que irão ser atingidos os objetivos de eficiência, escalabilidade, reutilização e facilidade de manutenção. O termo camada pode significar uma separação física ou uma camada lógica, no contexto que será aplicado, para produção de software foi considerado camada como uma referência a separação de responsabilidades (CELEPAR, 2010).

2.2.1 Aplicações Monolíticas

Primeiramente os softwares possuíam uma característica monolítica, ou seja, suas “camadas” eram encapsuladas em um mesmo módulo, o que acarretava em um extenso código de manutenção. A entrada do usuário, verificação, lógica de negócio e acesso a banco de dados estava presente em um mesmo lugar (MACORATTI.NET, 2010). A Figura 1 ilustra como é definido este tipo de aplicação.

Figura 1 - Arquitetura com uma camada ou monolítica.

2.2.2 Aplicações em duas camadas

A necessidade de compartilhar a lógica de acesso a dados entre vários usuários simultâneos fez surgir as aplicações em duas camadas. Nesta estrutura a base de dados foi colocada em uma máquina específica, separada das máquinas que executavam as aplicações. Nesta abordagem tem-se aplicativos instalados em estações clientes contendo toda a lógica da aplicação. Um grande problema neste modelo é o

gerenciamento de versões, pois para cada alteração os aplicativos precisam ser atualizados em todas as máquinas clientes (MACORATTI.NET, 2010). A Figura 2 ilustra como é definido este tipo de aplicação.

Figura 2 - Arquitetura com duas camadas.

2.2.3 Aplicações três camadas

Neste modelo a lógica de apresentação esta separada em sua própria camada lógica e física. A separação em camadas lógicas torna os sistemas mais flexíveis permitindo que as partes possam ser alteradas de forma independente. As funcionalidades da camada de negócio podem ser divididas em classes e essas classes podem ser agrupadas em pacotes ou componentes reduzindo as dependências entre as classes e pacotes, podem ser reutilizadas por diferentes partes do aplicativo e até por aplicativos diferentes. O modelo de 3 camadas tornou-se a arquitetura padrão para sistemas corporativos com base na Web.

O paradigma orientado a objetos ajuda a promover a modularidade pois os objetos encapsulam seus dados (propriedades, métodos e estados) e oferecem funcionalidades através de seus métodos. Projetando-se de forma adequada os objetos podem ter reduzidas as dependências entre si ficando assim fracamente acoplados e serão mais fáceis de manter e evoluir. A Figura 3 ilustra como é definido este tipo de aplicação.

Figura 3 - Arquitetura com três camadas.

2.3 O Padrão MVC O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio

resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio. A arquitetura MVC - (Model, View e Controller) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada, processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.

O MVC baseia-se em 2 princípios fortes. - O Controller despacha as solicitações ao Model; A View observa o Model. A Figura 4 ilustra como é efetuada a comunicação entre as camadas.

• Modelo (Model): Esta camada tem a função de consistir e validar as regras de negócio

pertinentes à aplicação, ou em específico da entidade que a mesma representa. Muitas aplicações usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar dados. MVC não cita especificamente a camada para acesso aos dados, porque subentende-se que estes métodos estariam encapsulados pelo Model.

• Visualização (View): "Renderiza" o model em uma forma específica para a interação, geralmente uma interface de usuário.

• Controle (Controller): Processa e responde a eventos, geralmente ações do usuário, e pode invocar alterações no model. É lá que é feita a validação dos dados e também é onde os valores postos pelos usuários são filtrados.

Figura 4 - Interação entre as três camadas.

2.4 Frameworks Um framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um

domínio de um subsistema da aplicação. É uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Tipicamente, um framework pode incluir programas de apoio, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes do seu projeto.

Em outras palavras, um framework é uma parte de um programa para resolver determinado problema, seja ela uma camada de um padrão de projetos (acesso a dados), controles externos (segurança, logs de ações) ou mesmo ser um ambiente de desenvolvimento – como é o caso do .NET (MATTSSON, 2000).

As vantagens de uso de framework são: • Modularização de um projeto, pois cada framework será uma peça do todo. • Reutilização: interfaces estáveis presentes nos frameworks aumentam o potencial de reutilização,

pela definição de componentes abstratos que podem ser redefinidos para criar novas aplicações. • Extensibilidade: um framework possui chamadas explícitas, permitindo a extensão de interfaces

estáveis.

2.5 Reflexão (Reflection) Reflexão é uma característica disponível nas linguagens de programação Microsoft.NET assim

como na plataforma Java. Esta permite durante a execução, um programa se auto-examinar, e manipular suas propriedades internas. Por exemplo, é possível uma classe Java obter o nome de todos os seus métodos e mostrá-los. A habilidade de examinar e manipular uma classe Java de dentro de si mesma não é vista como uma boa prática, mas em outras linguagens de programação essa característica simplesmente não existe. Por exemplo, não é possível obter informações sobre funções definidas dentro de programas escritos em linguagem VB, C++ ou JScript (MSDN, 2010).

A reflexão é útil nas seguintes situações: • Quando você precisa acessar atributos nos metadados do seu programa • Para analisar e instanciar tipos em um assembly. • Para a construção de novos tipos em tempo de execução. Usar classes em

System.Management.Instrumentation. • Para realizar ligação tardia, acessar métodos em tipos criados em tempo de execução. Consulte o

tópico carregamento dinâmico e Usando tipos.

3 FERRAMENTAS CASE EXISTENTES Abaixo são apresentadas breves descrições de duas ferramentas CASE, populares, que são o Genexus produzida pela ARTech (GENEXUS,2010) e o Apyon Studio produzida pela Apyon (APYON,2010). Ambas possuem características muito similares tendo como objetivo automatizar aquilo que se pode automatizar no processo de desenvolvimento de software corporativo.

As ferramentas CASE que serão apresentadas são robustas no que diz respeito á produção em alta escala de sistemas corporativos do tipo ERP por exemplo, possuem uma característica em comum que é a geração de código em uma arquitetura pré-definida pela ferramenta, desde a camada de interface até a camada de dados, o que de uma certa forma limita a aplicação resultante, tornando um tanto restrita no que diz respeito ao desenvolvimento de interfaces complexas, que exigem um alto esforço de customizações para facilitar a interação do usuário. Outra característica em comum é o alto custo de aquisição, por conseqüência de sua alta gama de funcionalidades que tem por objetivo automatizar o máximo de esforço exigido pelas equipes de desenvolvimento.

3.1 Genexus

É uma ferramenta de desenvolvimento de software criada pela empresa uruguaia ARTech, baseada em conhecimento e orientada ao desenvolvimento de aplicações corporativas, tanto para o ambiente WEB quanto GUI.

Podemos dizer que Genexus é a primeira ferramenta inteligente para criar, desenvolver e manter, de forma automática, aplicações multiplataforma de missão crítica, que facilmente se adaptam às mudanças do negócio e às novas possibilidades geradas pela evolução tecnológica .

O Genexus trabalha com o conhecimento contido nas visões dos usuários. Ele captura tal conhecimento e o sistematiza em uma base de conhecimento puro, que nos permite gerar aplicações para múltiplas arquiteturas e plataformas, ou seja, o Genexus possui uma gama de possibilidades no que diz respeito a linguagem final da aplicação e ao seu banco de dados.

A idéia básica do Genexus é automatizar tudo aquilo que for automatizável. Baseado nos requerimentos dos usuário, realiza o projeto, geração e manutenção automáticas da base de dados e dos programas da aplicação. Com isso, permite ao analista ou desenvolvedor se concentrar no negócio e focar toda sua atenção naquilo que um programa não poderá fazer: entender os problemas do usuário. Além disso, é possível reduzir significativamente os custos de manutenção e os tempos de desenvolvimento dos sistemas (GENEXUS, 2010). A Figura 5 ilustra a interface de gerenciamento da ferramenta Genexus.

Figura 5 - Ferramenta Genexus

3.2 Apyon Studio

O Apyon Studio é um ambiente inovador de desenvolvimento de software que estende e consolida as funcionalidades e benefícios das tradicionais ferramentas CASE. Além de otimizar a especificação, automatiza a geração automática de aplicativos e permite a migração de sistemas entre diferentes tecnologias. Isso é possível devido à independência tecnológica obtida com a utilização de um repositório central onde toda a inteligência do sistema é armazenada - o Apyon Metamodel. O Apyon Studio foi desenvolvido para suportar ambientes de desenvolvimento de sistemas complexos, que necessitam ser implementados de forma componentizada. As features exclusivas do Apyon Studio e o seu ambiente Wizard

tornam transparente a complexidade da arquitetura, aumentando a produtividade e a qualidade dos sistemas desenvolvidos (APYON, 2010).

Ao utilizar o Apyon Studio, as especificações de projeto feitas em uma ferramenta CASE são importadas para o Apyon Metamodel, deixando de ser meramente documentacionais, pois formam a base para a geração automática de código-fonte. A seguir, o analista passa a especificar as interfaces de usuário e os componentes de negócio, guiado por Wizards, evitando erros e inconsistências referenciais, aumentando a qualidade final do software.

Feitas as especificações, o Apyon Studio permite a geração automática das telas de usuário e das estruturas principais dos componentes de negócio. As telas geradas são completamente funcionais, com os métodos de inclusão, alteração, consulta, exclusão e toda a camada de segurança e acesso. Isso feito, basta enviar os componentes de negócio para serem programados e depois importar o código-fonte para o Apyon Metamodel, consolidando todo o "código genético" do software aplicativo desenvolvido. Devido à alta integração entre fases e ferramentas de desenvolvimento, não há retrabalho e a documentação mantém-se atualizada, pois o analista será conduzido a proceder as modificações dos sistemas na ferramenta CASE e não diretamente no código-fonte como acontece nos processos tradicionais. A Figura 6 ilustra a interface de gerenciamento da ferramenta Apyon Atudio 4.0.

Figura 6 - Ferramenta Apyon Studio 4.0

4 SOLUÇÃO PROPOSTA Para o desenvolvimento da ferramenta em questão, será efetuado um levantamento de requisitos, onde serão definidos de uma forma macro todas as funcionalidades necessárias para atender as necessidades, após será feito o uso de uma metodologia baseada em UML 2.0, o que permite a estruturação, detalhamento e especificação dos requisitos levantados na fase de análise do projeto.

4.1 Metodologia A metodologia definida para o desenvolvimento deste trabalho envolverá conhecimentos já

adquiridos e constituirá a base teórica do projeto. Portanto, será utilizada a linguagem UML 2.0 com seus diagramas específicos, ou seja, Diagramas de Casos de Uso, Diagramas de Seqüência e Diagramas de Classe. Como as bases de dados utilizadas no desenvolvimento deste trabalho são relacionais o emprego de Diagrama ER se faz necessário para a sua devida modelagem.

Diagramas de Casos de Uso (BOOCH, 2006) - A finalidade do diagrama de casos de uso é apresentar um tipo de diagrama de contexto, através do qual pode-se compreender rapidamente quais são os atores externos de um sistema e as maneiras principais, segundo as quais ele utiliza.

Diagrama de Sequência (BOOCH, 2006) - é o diagrama de interação que enfatiza a ordem temporal das trocas de mensagens. Um objeto é mostrado como uma caixa na parte superior de uma linha tracejada vertical chamada de linha de vida que representa a vida do objeto durante a interação, cada mensagem é representada por uma flecha entre as linhas de vida de dois objetos. A ordem na qual estas mensagens ocorrem é mostrada da parte superior a parte inferior.

Diagrama de Classe (BOOCH, RUMBAUGH, JACOBSON, 2006) - Neste diagrama apresenta se as classes e as relações entre ocorrências e classes. O diagrama de classes mostra atributos e operações de uma classe e as restrições na maneira com que os objetos são conectados.

Diagrama ER (CHEN, 1990) - Obrigatoriamente, o sistema necessitará de um banco de dados para organizar informações e dados. Será utilizado um banco de dados relacional e sua modelagem ER que demonstra os relacionamentos das tabelas que compõe o banco.

A ordem cronológica das fases do projeto dar-se-á através das seguintes fases: análise, projeto e desenvolvimento onde será utilizado a UML como ferramenta de transição de conhecimento.

4.2 Descrição dos Requisitos Conceituais Cadastro de Projetos: Este cadastro tem como objetivo manter os dados referentes ao cadastro de

projetos onde as entidades estarão vinculadas, sendo necessário os seguintes atributos: descrição do projeto, ativo ou inativo, tipo business e ou provider e dados para conexão da base de dados onde se encontra o modelo existente que são: servidor, banco de dados, usuário e senha.

Importação de Entidades e Tabelas: Esta importação tem como objetivo importar as tabelas do banco de dados, as quais representarão as entidades do modelo (Objeto-Relacional), sendo necessário os seguintes atributos: descrição da tabela, gerar provider (S/N), descrição da coluna, tipo da coluna, tamanho da coluna, nulo (S/N), seqüencial (S/N) e identação (S/N).

Cadastro de Templates: Este cadastro tem como objetivo manter os dados referentes aos templates (arquivos .tmp), utilizados para gerar o código fonte dos objetos, sendo necessário os seguintes atributos: descrição do template e tipo de template business e\ou provider.

Cadastro de Usuários da ferramenta: Este cadastro tem como objetivo manter os dados referentes aos usuários que utilizarão a ferramenta, o mesmo deverá manter permissões a nível de projeto e tipo de projeto, sendo necessário os seguintes atributos: nome do usuário, ativo (S/N), administrador (S/N), login, senha e projetos vinculados (permissões).

Cadastro de Tipos de Dados: Este cadastro tem como objetivo manter os dados referentes aos tipos utilizados pela linguagem destino nas propriedades dos objetos, sendo necessários os seguintes atributos: descrição do tipo, permite nulo (S/N), permite array (S/N), tipo DB (meta-dado equivalente ao tipo do database) e declaração do metadado em C#.

Gerenciador de Entidades: Este gerenciador deverá expor para o usuário a possibilidade de manipular os objetos do projeto tanto quanto sua regras de negócio, possibilitando que o mesmo exclua, insira e altere suas estruturas.

Importador de Código: A importação deverá respeitar as Tags pré-definidas nos fontes anteriormente gerados, ou seja, o conteúdo inserido durante a fase de codificação das regras de negócio terá de ser importado para base de dados antes de qualquer geração executada pela ferramenta, o que garantirá que em uma posterior geração seja alterado apenas as estruturas dos métodos do objeto e preservado o código produzido pelo desenvolvedor.

Gerador de Código: A geração de fontes deverá se orientar através das seguintes Tags que deverão formar os identificadores variáveis nos arquivos “.tmp”.    

4.2.1 Levantamento de Dados

Embora a maioria das ferramentas CASE que existem no mercado sejam robustas, com a evolução do framework .NET e do editor Visual Studio, a criação de interfaces em projetos .NET se tornou uma tarefa de baixa complexidade em conseqüência das facilidades oferecidas pelo conceito de orientação à objetos e da tecnologia.

Devido a necessidade cada vez maior da criação de aplicações de interfaces com requisitos de performance variada de projeto para projeto, o que dificulta a padronização na geração das mesmas, surgiu então a necessidade de criar um protótipo capaz de gerenciar e gerar códigos na linguagem C#, mais especificamente da camada de negócio da aplicação. Para o levantamento de dados da ferramenta foram observadas as seguintes questões:

• Como será feito o controle de projetos? Haverá um cadastro de projetos, onde os mesmos

possuirão informações para conexão das bases de dados o qual foi originado o seu mapeamento relacional.

• Como se dará o mapeamento objeto relacional (ORM) das classes? Tendo posse dos dados

de conexão da base SQL Server de origem, a ferramenta oferecerá uma interface no qual estará exposta a lista de tabelas, juntamente com seus atributos, onde o usuário irá poder selecionar quais entidades serão mapeadas pela ferramenta.

• De que forma o usuário irá gerenciar as regras de negócio da aplicação de destino? As

regras de negócio da aplicação destino, serão estruturadas através de uma interface onde a ferramenta considera a validação conforme os eventos de antes de depois das ações de manipulação dos dados na base de dados (Insert, Update e Delete), em um linguagem técnica, as mesmas serão consideradas como procedimentos, tendo como parâmetros de entrada de dados os atributos pertinentes a classe na qual estão inseridos e contando ainda com a possibilidade de adição de parâmetros customizados.

• Como o código gerado será adaptado a uma arquitetura já existente? Por possuir a

característica de geração de código configurável, a ferramenta efetuará a geração de código baseando-se em templates pré-definidos. Estes templates serão montados com códigos estáticos e dinâmicos, os códigos dinâmicos serão configurados através de Tags conhecidas pela ferramenta e os códigos estáticos consistirá na linguagem C# .NET o qual definirá a estrutura do código de saída.

• Como será mantida a integridade de código criado nas regras de negócio no caso de re-

geração das classes? A ferramenta possuirá um sistema de importação e geração de código, sendo que para distinguir quais códigos deverão ser mantidos em uma futura re-geração, os mesmos farão o uso de Tags de contexto delimitando início em fim do bloco de código.

• Os projetos poderão ser manipulados por todos os usuários? Não, a ferramenta possuirá um

cadastro e um controle de permissões de usuários, o qual cada um terá de ser relacionado como participante do projeto para possui acesso a sua estrutura na ferramenta.

4.2.2 Análise dos Dados

Tendo como base os requisitos levantados, o fluxo de dados da ferramenta iniciará com a criação do projeto e importação das entidades escolhidas pelo usuário, em seguida serão criadas as regras de negócios pertinentes à entidade, tendo as ordens de suas execuções conforme suas prioridades para a entidade, dentro disso serão configurados seus parâmetros de entradas, métodos e funções de acordo com suas utilidades pela regra de negócio.

No que diz respeito à usabilidade, será projetado um menu horizontal dividido por funcionalidade, onde mesmo terá seus acessos limitados pelo perfil do usuário logado na ferramenta. As interfaces de manipulação de objetos, como por exemplo, o gerenciamento das entidades, importação e exportação de

classes, serão estruturados através de uma treeview, o que facilitará a percepção e visualização das estruturas definidas na ferramenta pelos usuários.

Os templates da ferramenta deverão ser dinâmicos, ou seja, serão divididos por funções, por exemplo: procedimentos, funções, includes, etc... Para isto será ser disponibilizado um cadastro, onde o usuário irá informar para ferramenta o caminho físico, na qual futuramente será utilizado pela rotina de exportação.

Para orientar os usuários quanto à montagem dos templates, deverá constar na documentação as Tags interpretadas pela ferramenta com exemplos práticos de suas aplicações.

4.3 Projeto Conceitual O projeto conceitual da ferramenta consiste em especificar em uma visão macro da arquitetura

definida para a implementação da ferramenta, de forma que a mesma possa atender o objetivo de viabilizar a automatização na geração de código fonte a partir de uma determinada estrutura de banco de dados.

Para expor o projeto será feito uso do Diagrama E-R e da UML, onde serão utilizados os diagramas de Caso de Uso, Classe, Seqüência e Atividades.

4.3.1 Requisitos Funcionais

A ferramenta é constituída de requisitos funcionais que estão divididos em cadastros gerais e manipulação de fontes. Os cadastros da ferramenta são responsáveis por abranger tanto os dados essênciais para as gerações dos códigos-fontes, quanto para a questão de segurança dos projetos.

No que diz respeito à segurança dos dados trabalhados dentro da ferramenta, estão sendo previstos duas classificações perfis de usuários que são:

• Administrador: possui acesso total a todos os recursos e projetos. • Operador: possui acesso restrito a algumas funcionalidades de cadastros por default, tendo

acesso apenas a projetos mediante autorização do perfil Administrador.

A figura 7 representa o diagrama de casos de uso dos usuários interagindo com a ferramenta.

Figura 7 - Diagrama de Casos de Uso.

uc Ações

Manipulação de FontesCadastros

Manter Componentes

Geração e Importação

Administrador

(from Actors)

Operador

(from Actors)

Manter Regras

Manter Campos de Regras

Opcões

Geração

(from Business Rules)

Importação

(from Business Rules)

Manter Componente

(from Cadastros)

Manter Projetos

(from Cadastros)

Manter Tabelas

(from Cadastros)

Manter Templates

(from Cadastros)

Manter Tipos

(from Cadastros)

Manter Usuários

«extend»

«extend»

«extend»

«extend»

Abaixo é descrito uma breve definição de cada caso de uso exibido na figura 7:

• Manter Componentes: Este caso de uso tem como objetivo manter o gerenciamento dos componentes e regras de negócios para cada tipo de projeto através de uma treeview.

• Geração e Importação: Este caso de uso tem como objetivo manter a geração e importação dos

códigos-fontes constituídos a partir da ferramenta para cada tipo de projeto através de uma treeview.

• Manter Campos de Regras: Este caso de uso tem como objetivo manter os dados referentes aos

campos das regras de negócios vinculadas aos componentes dos projetos. • Manter Componentes: Este caso de uso tem como objetivo manter os dados referentes aos

componentes de projetos. • Manter Regras: Este caso de uso tem como objetivo manter os dados referentes às regras de

negócios vinculadas aos componentes dos projetos. • Opcões: Este caso de uso tem como objetivo manter os dados referentes às configurações

utilizadas para gerar ou importar dados para a ferramenta. • Manter Projetos: Este caso de uso tem como objetivo manter os dados referentes ao cadastro de

projetos aos quais as entidades estarão vinculadas. • Manter Tabelas: Este caso de uso tem o objetivo de importar as tabelas do banco de dados, as

quais representarão as entidades do modelo. • Manter Templates: Este caso de uso tem como objetivo manter os dados referentes aos

templates utilizados para gerar o código fonte dos objetos. • Manter Tipos: Este caso de uso tem como objetivo manter os dados referentes aos tipos

utilizados nas propriedades dos objetos. • Manter Usuários: Este caso de uso tem como objetivo manter os dados referentes aos usuários

que utilizarão a ferramenta, o mesmo deverá manter permissões em nível de projetos e tipos de projetos.

4.3.2 Modelagem ER

O diagrama E-R da ferramenta exibe a modelagem de banco de dados aplicada para manter a massa de dados utilizada para a manipulação de dados de cadastros, configurações e componentes, juntamente com os conteúdos absorvidos no momento da importação de códigos inseridos nas classes geradas previamente pela ferramenta.

A figura 8 representa o diagrama de ER da ferramenta, expondo suas entidades, atributos e seus relacionamentos.

Figura 8 - Diagrama ER.

4.3.3 Arquitetura A ferramenta possui uma arquitetura 3 camadas, tendo como padrão o MVC (Model View

Controller), para isso a aplicação foi dividida em 3 projetos distintos. Cada projeto possui suas características próprias conforme a definição do padrão aplicado:

• Tool: Este projeto representa a camada de interface da aplicação (View do padrão MVC), é

responsável por tratar apenas das interfaces da ferramenta, esta camada tem como característica principal a implementação literal dos Casos de Uso definidos no projeto de usabilidade.

• Tool.Entity: Este projeto representa a camada de modelo (Model do padrão MVC), é

responsável por tratar acesso à dados por intermédio das entidades referentes ao modelo de dados (ORM), sua principal função na arquitetura é a persistência e reflexão (reflection) dos dados contidos na base de dados, onde cada classe se refere a uma tabela do banco de dados. A figura 9 representa o diagrama de classes da ferramenta (camada modelo), expondo suas classes, atributos e seus relacionamentos.

• Tool.Business: Este projeto representa a camada de negócio da aplicação (Controller do padrão

MVC), esta camada tem a função de encapsular todas as regras de negócio pertinentes à entidade em questão. Por ser a camada intermediária entre a interface e o modelo de dados, tem um papel fundamental dentro da arquitetura, pois nela são tratados toda e qualquer regra antes ou após as operações de CRUD (Create, Read, Update e Delete). Também nesta camada estão localizadas as consultas (select’s), o qual provém grupos de dados retornados da base de dados conforme parâmetros previamente definidos.

• Tool.Gen: Este projeto é responsável pela geração e importação de dados contidos nas classes geradas pela ferramenta, é neste projeto que está contido toda a lógica de criação e manipulação de fontes, baseando-se nas configurações e padrões dos templates definidos pelo operador da ferramenta.

Figura 9 - Diagrama de Classes (Camada de Modelo).

Como exemplo de relação entre camadas, foi utilizado a funcionalidade de Cadastro de Projetos, onde a camada de Interface (classe frmProjeto) implementa o caso de uso Manter Projetos e instancia a camada de Business (classe ProjetosBUS), passando o conjunto de dados a serem persistidos para entidade Projetos, após podendo ser executado um de seus métodos de CRUD (Create, Read, Update e Delete). A figura 10 representa a interação entre as camadas.

Figura 10 – Interação entre camadas.

Pelo fato de todas as classes de negócio da camada de Controller, herdarem da classe BaseBLL e a

mesma possuir como definição em seu construtor a classe base que constituem as classes Model, ao chamar o construtor da classe ProjetosBUS, poderá ser informado a classe da entidade correspondente, neste caso a classe Projetos. Este tipo de implementação é conhecida dentro do Framework .NET como Generic ‘s, pois isto nos possibilita que a classe ProjetosBUS seja especificamente a classe de negócio da entidade Projetos. A figura 11 representa as camadas da ferramenta.

Figura 11 – Camadas.

sd Relacao entre camadas

Tool::frmProjetos

Operador

Tool.Business::ProjetosBUS Tool.Entity::Projetos

Camada de Modelo (ORM)

Camada de Negócio

Camada de Interface

Salvar()Adicionar(Projetos)

AddProjetos()

Atualizar(Projetos)SaveChanges()

Excluir()Excluir(Projetos)

DeleteObject()

SelecionaProjetos()CarregaDrop() :DataTable

SelectProjetos()

class Projetos

Tool::frmProjetos

- pIdProjetos: Integer+ objProv: Provider.Provider (())

- btSair_Click(System.Object, System.EventArgs)- btSalvar_Click(System.Object, System.EventArgs)- btNovo_Click(System.Object, System.EventArgs)- CarregaProjetos()- frmProjetos_Load(Object, System.EventArgs)- cboProjeto_SelectedIndexChanged(Object, System.EventArgs)- cboProjeto_SelectedValueChanged(Object, System.EventArgs)- btExcluir_Click(System.Object, System.EventArgs)

(from Cadastros)

Manter Projetos

Tool.Business::ProjetosBUS

+ New()+ New(Tool.Entity.Projetos)~ New(DBEntityContext)+ New(DBEntityContext, Tool.Entity.Projetos)~ AddObjetct()+ ListarUM(Integer) : Tool.Entity.Projetos+ ListarUM(Integer, DBEntityContext) : Tool.Entity.Projetos+ GetProjetoByTipo(Integer, String, DBEntityContext) : Tool.Entity.Projetos+ GetProjetoByTipo(Integer, String) : Tool.Entity.Projetos+ CarregaDrop() : DataTable+ GetProjetosBusiness()+ GetTablesByConnProjeto(Tool.Entity.Projetos) : DataTable

T:System.Data.Objects.DataClasses.EntityObject

Tool.Business::BaseBLL

- _dbEntity: DBEntityContext- _entity: T

+ New()+ New(T)~ New(DBEntityContext)~ New(DBEntityContext, T)~ Contextualize(BaseBLL)+ Adicionar()+ Atualizar()+ Excluir()+ Salvar()~ RolesBeforeInsert()~ RolesAfterInsert()~ RolesBeforeUpdate()~ RolesAfterUpdate()~ RolesBeforeDelete()~ RolesAfterDelete()~ AddObjetct()

«property»~ DBEntity() : DBEntityContext+ Entity() : T

Global.System.Data.Objects.DataClasses.EntityObjectTool.Entity::Projetos

- _IdProjetos: Integer- _DescrSist: String- _FlgAtivo: String- _FlgTipo: String- _Versao: String- _Servidor: String- _DB: String- _PWD: String- _USR: String

«property»+ IdProjetos() : Integer+ DescrSist() : String+ FlgAtivo() : String+ FlgTipo() : String+ Versao() : String+ Servidor() : String+ DB() : String+ PWD() : String+ USR() : String+ Parametros() : Global.System.Data.Objects.DataClasses.EntityCollection(Of Parametros)+ Tabelas() : Global.System.Data.Objects.DataClasses.EntityCollection(Of Tabelas)+ Vinculos() : Global.System.Data.Objects.DataClasses.EntityCollection(Of Vinculos)

1

1

A estrutura de tratamento das regras de negócio da ferramenta, está definida na classe base BaseBLL. Para um melhor reaproveitamento de código e padronização, foi criado métodos virtuais, estes métodos serão implementados nas classes que herdarão da classe BaseBLL, ou seja, onde será codificado as regras específicas a cada entidade em questão.

Para métodos específicos de persistência, antes e depois, são chamados métodos virtuais referentes a cada operação o qual garantirão que as regras sempre serão executadas ao disparar o CRUD (Create, Read, Update e Delete). A figura 12 ilustra o trecho de código do método de Atualizar da classe BaseBLL.

Figura 12 – Método de Atualizar da classe BaseBLL.

4.3.4 Geração e Importação

A geração dos fontes tem como regra a configuração dos templates pelo usuário, para isso é utilizado

tags específicas que indicam onde serão escritos os conteúdos automatizados nas classes, por exemplo: Para indicar a nomenclatura da classe é utilizada a tag “ <ClassName>”, para incluir o conteúdo do template de propriedades da classe usa-se “<!—Property>”. A figura 13 ilustra como exemplo o template ClassBusiness.tmp.

Figura 13 – ClassBusiness.tmp como exemplo de Template.

A importação das classes tem como característica identificação das tags <Custom:<region> [R:<ID>:C#]></Custom:<region>>”, nesta tag no momento de geração, a ferramenta substitui a tag <ID>, pelo identificador do registro da regra correspondente no banco de dados, o que permite que a ferramenta associe o fonte à regra em questão.

Pelo fato da ferramenta se basear em templates para geração de fontes, possibilita que o código gerado seja totalmente definido pelo usuário. A figura 14 demonstra toda a interação entre as classes no momento da geração e importação dos códigos fontes.

Figura 14 – Rotina de Geração e Importação de Código Fonte

4.3.5 Usabilidade

A ferramenta foi projetada para oferecer ao usuário uma interface amigável onde o mesmo tenha o mínimo de interação possível para alcançar seu objetivo, pelo fato do objetivo principal ser a automatização na criação de classes, para um melhor gerenciamento e padronização de código, as funcionalidades principais da ferramenta se dividem em Cadastros e Ações, isto envolve a criação e configuração do projeto, mapeamento das entidades, formatação dos componentes e configuração de templates. A figura 14 representa o diagrama de atividades onde são exibidas todas interações e suas dependências para o fornecimento dos dados necessários para utilização da ferramenta.

Figura 14 - Diagrama de Atividades

5 EXEMPLO DE USO Para realização do caso prático, foram selecionadas 10 classes com diferentes características, estas classes constituem o módulo de cadastro de um sistema de controle patrimonial, o sistema em questão possui uma arquitetura bem definida, onde a camada que trata das regras de negócio é separada da camada de interface e da camada de modelo. No desenvolvimento destas classes foram considerados como esforços relevantes para obtenção de métricas comparativas, o número de propriedades e método que cada classe possuía como especificação, e o tempo que se gastou para a codificação das assinaturas. As classes foram desenvolvidas por um desenvolvedor de perfil pleno que possui como rotina em sua função, desenvolver estes padrões de classes diariamente. Foi realizado um

act Ativ idade

Açõ

esC

adas

tros

Login

Manter Tipos

Manter Projetos

Manter Usuários

Manter TemplatesManter Tabelas

Possui Mapeamento ?

Selecionar Projeto

Importar Estrutura DB Configurar Estrutura DB

Configurar Projeto

Vincular Usuários

Possui Usuário?

Possui Projeto ?

Manter Componentes

Possui Entidade ?

Manter Regras Manter Campos de Regras

Geração\Importação

Opções (Configuração)

Selecionar Componentes

Componente Nativo ?

Fim

Fim

Fim

Gerar Importar

«centralBuffer»Código Fonte

Fim

Criar/Alterar Componete

[Sim]

[Sim]

[Não]

[Não]

[Não]

[Sim][Não]

[Sim]

[Sim]

[Não]

experimento utilizando tanto a forma manual quanto a forma automatizada (ferramenta), sendo que primeiramente realizado o desenvolvimento manual das classes. Ao desenvolver de forma manual, foram levantados alguns pontos relevantes que impactam no tempo de desenvolvimento desta forma, que são os seguintes:

• Mesmo com os helps disponibilizados pelo editor Visual Studio 2008, houve muitas compilações para se eliminar os defeitos ocasionados pela sintaxe e pela tipagem exigida na linguagem C#.

• Ocorreram algumas despadronizações nas nomenclaturas de variáveis e métodos criados pelo programador, pois por mais que se tenha documentação referente a este assunto, o risco deste fato acontecer em um código desenvolvido manualmente é alto, principalmente se o desenvolvedor for um novato na equipe.

• Se o projeto não possuir um ferramenta consistente de modelagem e especificação de classes, o tempo de interação entre o desenvolvedor e o analista de sistemas aumenta por conseqüência da falta de informação referente à criação das classes, conseqüentemente o risco de defeitos por mal interpretação do que se deseja também.

Em um segundo momento foi executado a criação das mesmas 10 classes de forma automatizada, ou seja, fazendo uso da ferramenta de geração de código. Nesta fase do experimento, ocorreram fatos importantes para a boa utilização e produtividade da ferramenta, que são eles:

• Durante a usabilidade da ferramenta pelo usuário, notou-se uma pequena curva de aprendizado, tanto para o que a ferramenta se propõe a fazer, quanto para a sua aplicação.

• Por ser uma ferramenta que possui como base templates, inicialmente foi gasto um tempo para que o desenvolvedor pudesse configurar os templates para a arquitetura destino das classes, o que na forma manual não possui.

• Assim como a fase de configuração de templates não existe para a criação manual, a ferramenta apresentou uma vantagem que beneficia o usuário em caso de recriação das classes em outra arquitetura ou alterações na mesma. Sendo que para isto seja possível basta apenas efetuar a manipulação dos templates e executar o processo de geração das mesmas.

5.1 Validação

Para efeitos comparativos foi criado um gráfico de linha de tempo, conforme mostra a figura 15, onde é demonstrado a diferença de tempos entre a criação manual e automatizada de cada classe. Este experimento apontou uma produtividade bastante significativa na codificação, obtendo uma média de ganho de 49% em relação ao método manual. No gráfico da figura 15 é apresentado apenas o benefício cronológico, sendo que também há outros benefícios significativos como a padronização e a geração em outra arquitetura, a última coluna do gráfico “Total”, demonstra a diferença entre o somatório total de horas da implementação manual e da forma automatizada.

Figura 15 – Gráfico de Linha de Tempo

6 CONCLUSÃO Neste trabalho foram identificados alguns pontos relevantes no desenvolvimento de software,

primeiro diz respeito ao custo do projeto, onde é demandado um grande percentual de esforço na codificação de aplicativos, como conseqüência de se tratar de um procedimento manual, onde o índice de problemas recorrentes e retrabalho é um indicador de impacto e de desvios em seus cronogramas, assim elevando custos com mão de obra. O segundo seria o custo da aquisição de uma Ferramenta CASE capaz de reduzir os impactos e retrabalhos, porém restringindo a flexibilidade de customização do código gerado por suas limitações e padronizações.

Conclui-se então que, é possível desenvolver uma Ferramenta CASE objetiva e compacta, o que torna seu custo mais baixo, atuando exatamente na camada de negócio das aplicações, diminuindo o esforço de mão de obra na fase de codificação, mantendo um padrão configurável e flexível a diferentes arquiteturas.

00:00  

02:24  

04:48  

07:12  

09:36  

12:00  

14:24  

Manual  

Automa5zado  

REFERÊNCIAS AMBLER, Scott W. Agile Database Techniques : Effective Strategies for the Agile Software Developer. Wiley, Outubro. 2003.

APYON, Apyon Studio Professional 4.0. Disponível por WWW em: < http://www2.dc.ufscar.br/~valdirene/Files/GettingStartedNovo.pdf/>. Consultado em junho de 2010.

BOOCH, G.; RUMBAUGH, J.;JACOBSON I. UML Guia do Usuário. Campus - 2005. 474p.

CAZULLINO, Daniel. Code Generation in the .NET Framework Using XML Schema. MSDN Library, EUA, 2001.

CELEPAR , Vidal Martins GPT . Rumo às tecnologias de objetos e de componentes distribuídos. Disponível por WWW em: < http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=983>. Consultado em abril de 2010.

CHEN, Peter. Modelagem de Dados. A Abordagem Entidade-Relacionamento para Projeto Lógico. São Paulo: McGraw-Hill: 1990. 80p.

DOLLARD, K. Code Generation in Microsoft .Net. EUA: Apress, 2004.

SILVA, A. M. R.; VIDEIRA, C. A. E. UML Metodologias e Ferramentas Case. Lisboa, Maio. 2005.

WEINRICH, Jair. GRAHL Everaldo-Software de apoio a avaliação e seleção de ferramentas case baseado na norma ISO/IEC 14102. Artigo SEMINCO FURB-Universidade Regional de Blumenau, 1999.

MACORATTI.NET, José Carlos Macoratti. Padrões de Projeto : O modelo MVC - Model View Controller. Disponível por WWW em: < http://www.macoratti.net/vbn_mvc.htm>. Consultado em abril de 2010.

MATTSSON, Michael. Evolution and Composition Object-Oriented Frameworks. PhD Thesis. University of Karlskrona, 2000.

MSDN, Reflection (C# Programming Guide) . Disponível por WWW em: < http://msdn.microsoft.com/en-us/library/ms173183(VS.80).aspx>. Consultado em abril de 2010.

GENEXUS. Disponível por WWW em: < http://www.genexus.com>. Consultado em junho de 2010.