FERRAMENTA CASE (GERADOR DE CDIGO .

NET)
Anderson Michereff Oliveira < andersonmic@gmail.com >
Luiz Gustavo Mhlmann < mahlmann@gmail.com> - Orientador
Universidade Luterana do Brasil (ULBRA) Curso de Sistemas de Informao Cmpus Canoas
Av. Farropilha, 8.001 Bairro So 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 cdigos
fontes (classes) na linguagem C# .NET, tendo como objetivo principal automatizar a criao da camada de negcio
de uma aplicao arquitetada em trs camadas (ex. MVC), bem como gerenciar as regras de negcios implementadas
nas entidades (classes) mapeadas (objeto-relacional), baseando-se em templates pr-definidos para gerao das
classes, onde suas estruturas so constitudas por tags conhecidas pela ferramenta, assim possibilitando a importao
e gerao do cdigo fonte.
Palavras-chave: Ferramenta Case, Gerao de Cdigo; 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 INTRODUO
Este trabalho trata-se do projeto de uma ferramenta case para a gerao de cdigo fonte na
linguagem C# .NET. Sua finalidade principal a criao, manipulao e gerao da camada de negcio das
aplicaes com layouts e padres pr-definidos por templates, tendo como misso diminuir o esforo no
desenvolvimento de aplicaes, a ferramenta possui como uma de suas principais caracterstica 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 aplicao a ser
recriada.
Atualmente em projetos de software trs camadas (MVC), grande parte do tempo gasto para o
desenvolvimento da aplicao com a criao manual da camada de negcio, isso inclui a projeo da
arquitetura interna das classes, bem como a programao das regras de negcios encapsuladas nas mesmas.
Para alcanar o objetivo principal, ser necessrio projetar a automatizao do processo de criao
da camada de negcio, 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 sero criadas telas de cadastros e manipulao
de objetos (classes), cadastros e manipulao de regras de negcio (procedimentos), cadastros de templates
arquiteturais para as classes a serem geradas, gerao e importao de objetos. Uma das caractersticas
diferenciais que a ferramenta ir oferecer est a gerao de classes baseadas em templates definidos pelo
usurio utilizando tags pr-definidas pela ferramenta, o que ir permitir a flexibilidade de gerao de classes
em variadas arquiteturas.
1.1

Motivao

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 tm demonstrado um grande interesse em alternativas que sirvam como
diferencial competitivo, e a que entra a utilizao de uma Ferramenta CASE, oferecendo recursos que
podem minimizar o tempo de desenvolvimento de um software, mantendo o alto nvel de qualidade.

Algumas empresas no se sentem confortveis em utilizar uma Ferramenta Case, devido o possvel
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 considervel, exigindo novas metodologias. Porm, ainda existe outro lado, ou seja, as
vantagens em se utilizar uma Ferramenta Case, que o aumento da produtividade, melhor qualidade,
diminuio dos custos, melhor gerenciamento e a grande facilidade de manuteno.
Para as empresas que adotam uma Ferramenta Case, os principais objetivos so os resultados que
podem ser mensurveis at com certa facilidade, mas com muita disciplina. Para tanto, necessrio um
eficiente estudo de viabilidade para implementao de uma Ferramenta Case.
Diante deste cenrio, em que empresas ainda relutam em adotar uma Ferramenta Case como soluo
em desenvolvimento de Sistemas, mesmo com o mercado exigindo novas tcnicas em automao, as
Ferramentas CASE se mostram como alternativa para empresas, desenvolvedores e, at mesmo, estudantes,
impondo seus diferenciais em relao a outros tipos de ferramentas de desenvolvimento existentes no
mercado.
1.2

Objetivo

O objetivo deste trabalho desenvolver uma ferramenta geradora de cdigo fonte compacta,
otimizada e flexvel, que viabilize especificamente a gerao da camada de negcio das aplicaes, onde
sero 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 evoluo do editor Visual Studio e do framework .NET, h pontos em que o prprio editor
na atualidade j viabiliza, como por exemplo a facilidade da construo de variados tipos de interfaces
funcionais com reutilizao de cdigos e construo de objetos reutilizveis, fazendo uso do conceito de
herana entre os mesmos.
O cdigo fonte gerado na linguagem C# .NET ter sua estrutura determinada atravs de templates
pr configurados contendo tags conhecidas pela ferramenta geradora, assim proporcionando flexibilidade de
estruturao para qualquer padro. Em funo de estar sendo utilizado uma linguagem de sada orientada a
objetos e o conceito da arquitetura MVC, o foco desta camada ser a real implementao das regras de
negcio a qual a aplicao dever respeitar.

Referencial Terico

Este captulo apresenta um breve referencial terico sobre os temas envolvidos neste trabalho, desde
as vantagens e desvantagens da utilizao de uma Ferramenta Case at as metodologias envolvidas para o
desenvolvimento da ferramenta em questo.
Ferramentas CASE (do ingls Computer-Aided Software Engineering) uma classificao que
abrange todas ferramentas baseada em computadores que auxiliam atividades de engenharia de software,
desde anlise de requisitos e modelagem at programao e testes. Podem ser consideradas como
ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou vrias
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 deciso;
Menor quantidade de cdigos de programao;
Melhoria e reduo de custos na manuteno;
Agilidade no retrabalho do software.
Desvantagens do uso de ferramentas CASE:
Incompatibilidade entre ferramentas;
Treinamento para utilizao.

2.1

Geradores de Cdigo Fonte

Um gerador de cdigo um ferramenta desenvolvida para gerar automaticamente cdigo fonte de

alto nvel em linguagens de programao como .NET, C++, C#, Java e outros. Com a evoluo das
tecnologias e paradigmas de desenvolvimento, foi surgindo a necessidade de automatizao de fases de
desenvolvimento de sistemas, uma delas o mapeamento objeto-relacional ou ORM (AMBLER, 2003),
onde possvel criar, a partir de um banco de dados relacional, objetos de acesso base de dados, onde
tabela so representados como classes correspondentes, restando equipe de desenvolvimento implementar
regras de negcio e especializao das funcionalidades.
Vantagens de um gerador de cdigo fonte (DOLLARD,2004), so:
Padronizao de Cdigo: cdigos gerados atravs de uma ferramenta case obedecem uma
padronizao, o que implica diretamente na qualidade de legibilidade, diminuindo a margem de
possveis erros decorrentes de diferentes formas de implementao.
Eficincia: cdigos gerados dentro de um padro conhecido e testados aumentaro o ndice de
eficincia de suas funcionalidades uniformes.
Produtividade: sendo capaz de realizar a construo de funcionalidades das aplicaes de
maneira mais eficiente e segura, garantindo tambm a diminuio dos custos de projeto. Sendo
assim possibilitando que o foco dos desenvolvedores estejam voltados mais para as regras de
negcios a serem implementadas nas entidades (classes).
Abstrao: por possurem uma interface funcional, abstraem a interao com o modelo de dados,
ou seja, no momento que o modelo sofrer qualquer alterao, as entidades pertinentes sero
alteradas de acordo com suas entradas ou sadas.

2.2

Modelos Arquiteturais

Padres de projetos so solues para problemas que algum um dia teve e resolveu aplicando um
modelo que foi documentado e que voc pode adaptar integralmente ou de acordo com necessidade de sua
soluo. Ser abordado neste tpico o padro de modelo MVC, que tem por objetivo bsico separar a lgica
de negcio da apresentao (MACORATTI.NET, 2010).
O paradigma orientado a objetos est intimamente ligado arquitetura que foi utilizada para
construir a ferramenta. A tendncia indica que esta arquitetura estar baseada na organizao da aplicao
em camadas e na observao dos padres utilizados pelo mercado. A organizao em camadas a chave para
a independncia entre os componentes, em conseqncia deste fato que iro ser atingidos os objetivos de
eficincia, escalabilidade, reutilizao e facilidade de manuteno. O termo camada pode significar uma
separao fsica ou uma camada lgica, no contexto que ser aplicado, para produo de software foi
considerado camada como uma referncia a separao de responsabilidades (CELEPAR, 2010).
2.2.1

Aplicaes Monolticas

Primeiramente os softwares possuam uma caracterstica monoltica, ou seja, suas camadas eram
encapsuladas em um mesmo mdulo, o que acarretava em um extenso cdigo de manuteno. A entrada do
usurio, verificao, lgica de negcio e acesso a banco de dados estava presente em um mesmo lugar
(MACORATTI.NET, 2010). A Figura 1 ilustra como definido este tipo de aplicao.

Figura 1 - Arquitetura com uma camada ou monoltica.

2.2.2

Aplicaes em duas camadas

A necessidade de compartilhar a lgica de acesso a dados entre vrios usurios simultneos fez
surgir as aplicaes em duas camadas. Nesta estrutura a base de dados foi colocada em uma mquina
especfica, separada das mquinas que executavam as aplicaes. Nesta abordagem tem-se aplicativos
instalados em estaes clientes contendo toda a lgica da aplicao. Um grande problema neste modelo o

gerenciamento de verses, pois para cada alterao os aplicativos precisam ser atualizados em todas as
mquinas clientes (MACORATTI.NET, 2010). A Figura 2 ilustra como definido este tipo de aplicao.

Figura 2 - Arquitetura com duas camadas.

2.2.3

Aplicaes trs camadas

Neste modelo a lgica de apresentao esta separada em sua prpria camada lgica e fsica. A
separao em camadas lgicas torna os sistemas mais flexveis permitindo que as partes possam ser alteradas
de forma independente. As funcionalidades da camada de negcio podem ser divididas em classes e essas
classes podem ser agrupadas em pacotes ou componentes reduzindo as dependncias 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 padro para sistemas corporativos com base na Web.
O paradigma orientado a objetos ajuda a promover a modularidade pois os objetos encapsulam seus
dados (propriedades, mtodos e estados) e oferecem funcionalidades atravs de seus mtodos. Projetando-se
de forma adequada os objetos podem ter reduzidas as dependncias entre si ficando assim fracamente
acoplados e sero mais fceis de manter e evoluir. A Figura 3 ilustra como definido este tipo de aplicao.

Figura 3 - Arquitetura com trs camadas.

2.3

O Padro MVC

O modelo de trs camadas fiscas ( 3-tier ) divide um aplicativo de modo que a lgica de negcio
resida no meio das trs camadas fsicas. Isto chamado de camada fsica intermediria ou camada fsica de
negcios. A maior parte do cdigo escrito reside na camada de apresentao e de negcio. A arquitetura
MVC - (Model, View e Controller) fornece uma maneira de dividir a funcionalidade envolvida na
manuteno e apresentao dos dados de uma aplicao. A arquitetura MVC no nova e foi originalmente
desenvolvida para mapear as tarefas tradicionais de entrada, processamento e sada para o modelo de
interao com o usurio. Usando o padro MVC fica fcil mapear esses conceitos no domnio de aplicaes
Web multicamadas.
O MVC baseia-se em 2 princpios fortes. - O Controller despacha as solicitaes ao Model; A View
observa o Model. A Figura 4 ilustra como efetuada a comunicao entre as camadas.
Modelo (Model): Esta camada tem a funo de consistir e validar as regras de negcio
pertinentes aplicao, ou em especfico da entidade que a mesma representa. Muitas aplicaes
usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar
dados. MVC no cita especificamente a camada para acesso aos dados, porque subentende-se que
estes mtodos estariam encapsulados pelo Model.
Visualizao (View): "Renderiza" o model em uma forma especfica para a interao, geralmente
uma interface de usurio.
Controle (Controller): Processa e responde a eventos, geralmente aes do usurio, e pode
invocar alteraes no model. l que feita a validao dos dados e tambm onde os valores
postos pelos usurios so filtrados.

Figura 4 - Interao entre as trs camadas.

2.4

Frameworks

Um framework um conjunto de classes que colaboram para realizar uma responsabilidade para um
domnio de um subsistema da aplicao. 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 cdigo, 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 padro de projetos (acesso a dados), controles externos (segurana,
logs de aes) ou mesmo ser um ambiente de desenvolvimento como o caso do .NET (MATTSSON,
2000).
As vantagens de uso de framework so:
Modularizao de um projeto, pois cada framework ser uma pea do todo.
Reutilizao: interfaces estveis presentes nos frameworks aumentam o potencial de reutilizao,
pela definio de componentes abstratos que podem ser redefinidos para criar novas aplicaes.
Extensibilidade: um framework possui chamadas explcitas, permitindo a extenso de interfaces
estveis.

2.5

Reflexo (Reflection)

Reflexo uma caracterstica disponvel nas linguagens de programao Microsoft.NET assim

como na plataforma Java. Esta permite durante a execuo, um programa se auto-examinar, e manipular suas
propriedades internas. Por exemplo, possvel uma classe Java obter o nome de todos os seus mtodos e
mostr-los. A habilidade de examinar e manipular uma classe Java de dentro de si mesma no vista como
uma boa prtica, mas em outras linguagens de programao essa caracterstica simplesmente no existe. Por
exemplo, no possvel obter informaes sobre funes definidas dentro de programas escritos em
linguagem VB, C++ ou JScript (MSDN, 2010).
A reflexo til nas seguintes situaes:
Quando voc precisa acessar atributos nos metadados do seu programa
Para analisar e instanciar tipos em um assembly.
Para a construo de novos tipos em tempo de execuo. Usar classes em
System.Management.Instrumentation.
Para realizar ligao tardia, acessar mtodos em tipos criados em tempo de execuo. Consulte o
tpico carregamento dinmico e Usando tipos.

3 FERRAMENTAS CASE EXISTENTES

Abaixo so apresentadas breves descries de duas ferramentas CASE, populares, que so o Genexus
produzida pela ARTech (GENEXUS,2010) e o Apyon Studio produzida pela Apyon (APYON,2010). Ambas
possuem caractersticas muito similares tendo como objetivo automatizar aquilo que se pode automatizar no
processo de desenvolvimento de software corporativo.

As ferramentas CASE que sero apresentadas so robustas no que diz respeito produo em alta
escala de sistemas corporativos do tipo ERP por exemplo, possuem uma caracterstica em comum que a
gerao de cdigo 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 aplicao resultante, tornando um tanto restrita no que
diz respeito ao desenvolvimento de interfaces complexas, que exigem um alto esforo de customizaes para
facilitar a interao do usurio. Outra caracterstica em comum o alto custo de aquisio, por conseqncia
de sua alta gama de funcionalidades que tem por objetivo automatizar o mximo de esforo 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 aplicaes corporativas, tanto para o ambiente WEB
quanto GUI.
Podemos dizer que Genexus a primeira ferramenta inteligente para criar, desenvolver e manter, de
forma automtica, aplicaes multiplataforma de misso crtica, que facilmente se adaptam s mudanas do
negcio e s novas possibilidades geradas pela evoluo tecnolgica .
O Genexus trabalha com o conhecimento contido nas vises dos usurios. Ele captura tal
conhecimento e o sistematiza em uma base de conhecimento puro, que nos permite gerar aplicaes para
mltiplas arquiteturas e plataformas, ou seja, o Genexus possui uma gama de possibilidades no que diz
respeito a linguagem final da aplicao e ao seu banco de dados.
A idia bsica do Genexus automatizar tudo aquilo que for automatizvel. Baseado nos
requerimentos dos usurio, realiza o projeto, gerao e manuteno automticas da base de dados e dos
programas da aplicao. Com isso, permite ao analista ou desenvolvedor se concentrar no negcio e focar
toda sua ateno naquilo que um programa no poder fazer: entender os problemas do usurio. Alm disso,
possvel reduzir significativamente os custos de manuteno 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 benefcios das tradicionais ferramentas CASE. Alm de otimizar a especificao,
automatiza a gerao automtica de aplicativos e permite a migrao de sistemas entre diferentes
tecnologias. Isso possvel devido independncia tecnolgica obtida com a utilizao de um repositrio
central onde toda a inteligncia 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 especificaes de projeto feitas em uma ferramenta CASE so
importadas para o Apyon Metamodel, deixando de ser meramente documentacionais, pois formam a base
para a gerao automtica de cdigo-fonte. A seguir, o analista passa a especificar as interfaces de usurio e
os componentes de negcio, guiado por Wizards, evitando erros e inconsistncias referenciais, aumentando a
qualidade final do software.
Feitas as especificaes, o Apyon Studio permite a gerao automtica das telas de usurio e das
estruturas principais dos componentes de negcio. As telas geradas so completamente funcionais, com os
mtodos de incluso, alterao, consulta, excluso e toda a camada de segurana e acesso. Isso feito, basta
enviar os componentes de negcio para serem programados e depois importar o cdigo-fonte para o Apyon
Metamodel, consolidando todo o "cdigo gentico" do software aplicativo desenvolvido.
Devido alta integrao entre fases e ferramentas de desenvolvimento, no h retrabalho e a documentao
mantm-se atualizada, pois o analista ser conduzido a proceder as modificaes dos sistemas na ferramenta
CASE e no diretamente no cdigo-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 SOLUO PROPOSTA
Para o desenvolvimento da ferramenta em questo, ser efetuado um levantamento de requisitos,
onde sero definidos de uma forma macro todas as funcionalidades necessrias para atender as necessidades,
aps ser feito o uso de uma metodologia baseada em UML 2.0, o que permite a estruturao, detalhamento
e especificao dos requisitos levantados na fase de anlise do projeto.

4.1

Metodologia

A metodologia definida para o desenvolvimento deste trabalho envolver conhecimentos j

adquiridos e constituir a base terica do projeto. Portanto, ser utilizada a linguagem UML 2.0 com seus
diagramas especficos, ou seja, Diagramas de Casos de Uso, Diagramas de Seqncia e Diagramas de Classe.
Como as bases de dados utilizadas no desenvolvimento deste trabalho so relacionais o emprego de
Diagrama ER se faz necessrio 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, atravs do qual pode-se compreender rapidamente quais so os
atores externos de um sistema e as maneiras principais, segundo as quais ele utiliza.

Diagrama de Sequncia (BOOCH, 2006) - o diagrama de interao 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
interao, 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 relaes entre ocorrncias e classes. O diagrama de classes mostra atributos e operaes de uma
classe e as restries na maneira com que os objetos so conectados.
Diagrama ER (CHEN, 1990) - Obrigatoriamente, o sistema necessitar de um banco de dados para
organizar informaes e dados. Ser utilizado um banco de dados relacional e sua modelagem ER que
demonstra os relacionamentos das tabelas que compe o banco.
A ordem cronolgica das fases do projeto dar-se- atravs das seguintes fases: anlise, projeto e
desenvolvimento onde ser utilizado a UML como ferramenta de transio de conhecimento.

4.2

Descrio dos Requisitos Conceituais

Cadastro de Projetos: Este cadastro tem como objetivo manter os dados referentes ao cadastro de
projetos onde as entidades estaro vinculadas, sendo necessrio os seguintes atributos: descrio do projeto,
ativo ou inativo, tipo business e ou provider e dados para conexo da base de dados onde se encontra o
modelo existente que so: servidor, banco de dados, usurio e senha.
Importao de Entidades e Tabelas: Esta importao tem como objetivo importar as tabelas do banco
de dados, as quais representaro as entidades do modelo (Objeto-Relacional), sendo necessrio os seguintes
atributos: descrio da tabela, gerar provider (S/N), descrio da coluna, tipo da coluna, tamanho da coluna,
nulo (S/N), seqencial (S/N) e identao (S/N).
Cadastro de Templates: Este cadastro tem como objetivo manter os dados referentes aos templates
(arquivos .tmp), utilizados para gerar o cdigo fonte dos objetos, sendo necessrio os seguintes atributos:
descrio do template e tipo de template business e\ou provider.
Cadastro de Usurios da ferramenta: Este cadastro tem como objetivo manter os dados referentes aos
usurios que utilizaro a ferramenta, o mesmo dever manter permisses a nvel de projeto e tipo de projeto,
sendo necessrio os seguintes atributos: nome do usurio, ativo (S/N), administrador (S/N), login, senha e
projetos vinculados (permisses).
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 necessrios os seguintes atributos:
descrio do tipo, permite nulo (S/N), permite array (S/N), tipo DB (meta-dado equivalente ao tipo do
database) e declarao do metadado em C#.
Gerenciador de Entidades: Este gerenciador dever expor para o usurio a possibilidade de
manipular os objetos do projeto tanto quanto sua regras de negcio, possibilitando que o mesmo exclua,
insira e altere suas estruturas.
Importador de Cdigo: A importao dever respeitar as Tags pr-definidas nos fontes anteriormente
gerados, ou seja, o contedo inserido durante a fase de codificao das regras de negcio ter de ser
importado para base de dados antes de qualquer gerao executada pela ferramenta, o que garantir que em
uma posterior gerao seja alterado apenas as estruturas dos mtodos do objeto e preservado o cdigo
produzido pelo desenvolvedor.
Gerador de Cdigo: A gerao de fontes dever se orientar atravs das seguintes Tags que devero
formar os identificadores variveis nos arquivos .tmp.

4.2.1

Levantamento de Dados

Embora a maioria das ferramentas CASE que existem no mercado sejam robustas, com a evoluo
do framework .NET e do editor Visual Studio, a criao de interfaces em projetos .NET se tornou uma tarefa
de baixa complexidade em conseqncia das facilidades oferecidas pelo conceito de orientao objetos e da
tecnologia.
Devido a necessidade cada vez maior da criao de aplicaes de interfaces com requisitos de
performance variada de projeto para projeto, o que dificulta a padronizao na gerao das mesmas, surgiu
ento a necessidade de criar um prottipo capaz de gerenciar e gerar cdigos na linguagem C#, mais
especificamente da camada de negcio da aplicao. Para o levantamento de dados da ferramenta foram
observadas as seguintes questes:

4.2.2

Como ser feito o controle de projetos? Haver um cadastro de projetos, onde os mesmos
possuiro informaes para conexo 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 conexo 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 usurio ir poder selecionar
quais entidades sero mapeadas pela ferramenta.

De que forma o usurio ir gerenciar as regras de negcio da aplicao de destino? As

regras de negcio da aplicao destino, sero estruturadas atravs de uma interface onde a
ferramenta considera a validao conforme os eventos de antes de depois das aes de
manipulao dos dados na base de dados (Insert, Update e Delete), em um linguagem tcnica,
as mesmas sero consideradas como procedimentos, tendo como parmetros de entrada de dados
os atributos pertinentes a classe na qual esto inseridos e contando ainda com a possibilidade de
adio de parmetros customizados.

Como o cdigo gerado ser adaptado a uma arquitetura j existente? Por possuir a
caracterstica de gerao de cdigo configurvel, a ferramenta efetuar a gerao de cdigo
baseando-se em templates pr-definidos. Estes templates sero montados com cdigos estticos e
dinmicos, os cdigos dinmicos sero configurados atravs de Tags conhecidas pela ferramenta
e os cdigos estticos consistir na linguagem C# .NET o qual definir a estrutura do cdigo de
sada.

Como ser mantida a integridade de cdigo criado nas regras de negcio no caso de regerao das classes? A ferramenta possuir um sistema de importao e gerao de cdigo,
sendo que para distinguir quais cdigos devero ser mantidos em uma futura re-gerao, os
mesmos faro o uso de Tags de contexto delimitando incio em fim do bloco de cdigo.

Os projetos podero ser manipulados por todos os usurios? No, a ferramenta possuir um
cadastro e um controle de permisses de usurios, o qual cada um ter de ser relacionado como
participante do projeto para possui acesso a sua estrutura na ferramenta.

Anlise dos Dados

Tendo como base os requisitos levantados, o fluxo de dados da ferramenta iniciar com a criao do
projeto e importao das entidades escolhidas pelo usurio, em seguida sero criadas as regras de negcios
pertinentes entidade, tendo as ordens de suas execues conforme suas prioridades para a entidade, dentro
disso sero configurados seus parmetros de entradas, mtodos e funes de acordo com suas utilidades pela
regra de negcio.
No que diz respeito usabilidade, ser projetado um menu horizontal dividido por funcionalidade,
onde mesmo ter seus acessos limitados pelo perfil do usurio logado na ferramenta. As interfaces de
manipulao de objetos, como por exemplo, o gerenciamento das entidades, importao e exportao de

classes, sero estruturados atravs de uma treeview, o que facilitar a percepo e visualizao das estruturas
definidas na ferramenta pelos usurios.
Os templates da ferramenta devero ser dinmicos, ou seja, sero divididos por funes, por
exemplo: procedimentos, funes, includes, etc... Para isto ser ser disponibilizado um cadastro, onde o
usurio ir informar para ferramenta o caminho fsico, na qual futuramente ser utilizado pela rotina de
exportao.
Para orientar os usurios quanto montagem dos templates, dever constar na documentao as Tags
interpretadas pela ferramenta com exemplos prticos de suas aplicaes.

4.3

Projeto Conceitual

O projeto conceitual da ferramenta consiste em especificar em uma viso macro da arquitetura

definida para a implementao da ferramenta, de forma que a mesma possa atender o objetivo de viabilizar a
automatizao na gerao de cdigo 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 sero utilizados os diagramas
de Caso de Uso, Classe, Seqncia e Atividades.
4.3.1

Requisitos Funcionais

A ferramenta constituda de requisitos funcionais que esto divididos em cadastros gerais e

manipulao de fontes. Os cadastros da ferramenta so responsveis por abranger tanto os dados essnciais
para as geraes dos cdigos-fontes, quanto para a questo de segurana dos projetos.
No que diz respeito segurana dos dados trabalhados dentro da ferramenta, esto sendo previstos
duas classificaes perfis de usurios que so:
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 autorizao do perfil Administrador.
A figura 7 representa o diagrama de casos de uso dos usurios interagindo com a ferramenta.

uc Aes

Manipulao de Fontes

Cadastros

Manter Componente

Manter Usurios

(from Cadastros)

extend

Manter Tipos

Manter Componentes

extend

Manter Regras

Administrador
(from Cadastros)

(from Actors)

extend

Manter Campos de Regras

Manter Templates

(from Cadastros)
Gerao e Importao
extend
Manter Proj etos

Opces

Operador
(from Actors)
Gerao

(from Cadastros)

(from Business Rules)

Manter Tabelas

Importao

(from Business Rules)

(from Cadastros)

Figura 7 - Diagrama de Casos de Uso.

Abaixo descrito uma breve definio de cada caso de uso exibido na figura 7:

4.3.2

Manter Componentes: Este caso de uso tem como objetivo manter o gerenciamento dos
componentes e regras de negcios para cada tipo de projeto atravs de uma treeview.

Gerao e Importao: Este caso de uso tem como objetivo manter a gerao e importao dos
cdigos-fontes constitudos a partir da ferramenta para cada tipo de projeto atravs de uma
treeview.

Manter Campos de Regras: Este caso de uso tem como objetivo manter os dados referentes aos
campos das regras de negcios 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
negcios vinculadas aos componentes dos projetos.

Opces: Este caso de uso tem como objetivo manter os dados referentes s configuraes
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 estaro vinculadas.

Manter Tabelas: Este caso de uso tem o objetivo de importar as tabelas do banco de dados, as
quais representaro as entidades do modelo.

Manter Templates: Este caso de uso tem como objetivo manter os dados referentes aos
templates utilizados para gerar o cdigo fonte dos objetos.

Manter Tipos: Este caso de uso tem como objetivo manter os dados referentes aos tipos
utilizados nas propriedades dos objetos.

Manter Usurios: Este caso de uso tem como objetivo manter os dados referentes aos usurios
que utilizaro a ferramenta, o mesmo dever manter permisses em nvel de projetos e tipos de
projetos.

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 manipulao de dados de cadastros, configuraes e componentes, juntamente com
os contedos absorvidos no momento da importao de cdigos 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 padro o MVC (Model View
Controller), para isso a aplicao foi dividida em 3 projetos distintos. Cada projeto possui suas
caractersticas prprias conforme a definio do padro aplicado:

Tool: Este projeto representa a camada de interface da aplicao (View do padro MVC),
responsvel por tratar apenas das interfaces da ferramenta, esta camada tem como caracterstica
principal a implementao literal dos Casos de Uso definidos no projeto de usabilidade.

Tool.Entity: Este projeto representa a camada de modelo (Model do padro MVC),

responsvel por tratar acesso dados por intermdio das entidades referentes ao modelo de
dados (ORM), sua principal funo na arquitetura a persistncia e reflexo (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 negcio da aplicao (Controller do padro

MVC), esta camada tem a funo de encapsular todas as regras de negcio pertinentes entidade
em questo. Por ser a camada intermediria entre a interface e o modelo de dados, tem um papel
fundamental dentro da arquitetura, pois nela so tratados toda e qualquer regra antes ou aps as
operaes de CRUD (Create, Read, Update e Delete). Tambm nesta camada esto localizadas
as consultas (selects), o qual provm grupos de dados retornados da base de dados conforme
parmetros previamente definidos.

Tool.Gen: Este projeto responsvel pela gerao e importao de dados contidos nas classes
geradas pela ferramenta, neste projeto que est contido toda a lgica de criao e manipulao
de fontes, baseando-se nas configuraes e padres dos templates definidos pelo operador da
ferramenta.

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

Como exemplo de relao 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, aps podendo ser executado um de seus mtodos de CRUD (Create, Read, Update e Delete). A
figura 10 representa a interao entre as camadas.

sd Relacao entre camadas

Camada de
Interface
Tool::frmProjetos

Camada de
Negcio
Tool.Business::ProjetosBUS

Camada de
Modelo (ORM)
Tool.Entity::Projetos

Operador

Salvar()

Adicionar(Projetos)
AddProjetos()

Atualizar(Projetos)
SaveChanges()

Excluir()

Excluir(Projetos)

DeleteObject()

SelecionaProjetos()
CarregaDrop() :DataTable
SelectProjetos()

Figura 10 Interao entre camadas.

Pelo fato de todas as classes de negcio da camada de Controller, herdarem da classe BaseBLL e a
mesma possuir como definio 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 implementao conhecida dentro do Framework .NET como Generic
s,
pois isto nos possibilita que a classe ProjetosBUS seja especificamente a classe de negcio da entidade
Projetos. A figura 11 representa as camadas da ferramenta.
class Proj etos

Manter Proj etos

(from Cadastros)
Global.System.Data.Objects.DataClasses.EntityObject

Tool::frmProj etos

Tool.Entity::Proj etos

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)

_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)

T:System.Data.Obj ects.DataClasses.EntityObj ect

Tool.Business::Proj etosBUS
+
+
~
+
~
+
+
+
+
+
+
+

Tool.Business::BaseBLL

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

_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

Figura 11 Camadas.

A estrutura de tratamento das regras de negcio da ferramenta, est definida na classe base
BaseBLL. Para um melhor reaproveitamento de cdigo e padronizao, foi criado mtodos virtuais, estes
mtodos sero implementados nas classes que herdaro da classe BaseBLL, ou seja, onde ser codificado as
regras especficas a cada entidade em questo.
Para mtodos especficos de persistncia, antes e depois, so chamados mtodos virtuais referentes a
cada operao o qual garantiro que as regras sempre sero executadas ao disparar o CRUD (Create, Read,
Update e Delete). A figura 12 ilustra o trecho de cdigo do mtodo de Atualizar da classe BaseBLL.

Figura 12 Mtodo de Atualizar da classe BaseBLL.

4.3.4

Gerao e Importao

A gerao dos fontes tem como regra a configurao dos templates pelo usurio, para isso utilizado
tags especficas que indicam onde sero escritos os contedos automatizados nas classes, por exemplo: Para
indicar a nomenclatura da classe utilizada a tag <ClassName>, para incluir o contedo 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 importao das classes tem como caracterstica identificao das tags <Custom:<region>
[R:<ID>:C#]></Custom:<region>>, nesta tag no momento de gerao, 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 questo.
Pelo fato da ferramenta se basear em templates para gerao de fontes, possibilita que o cdigo
gerado seja totalmente definido pelo usurio. A figura 14 demonstra toda a interao entre as classes no
momento da gerao e importao dos cdigos fontes.

Figura 14 Rotina de Gerao e Importao de Cdigo Fonte

4.3.5

Usabilidade

A ferramenta foi projetada para oferecer ao usurio uma interface amigvel onde o mesmo
tenha o mnimo de interao possvel para alcanar seu objetivo, pelo fato do objetivo principal ser
a automatizao na criao de classes, para um melhor gerenciamento e padronizao de cdigo, as
funcionalidades principais da ferramenta se dividem em Cadastros e Aes, isto envolve a criao e
configurao do projeto, mapeamento das entidades, formatao dos componentes e configurao
de templates. A figura 14 representa o diagrama de atividades onde so exibidas todas interaes e
suas dependncias para o fornecimento dos dados necessrios para utilizao da ferramenta.

act Ativ idade

Login

Manter Tabelas

Manter Tipos

Manter Templates

Possui Projeto ?
Manter Proj etos

[No]

[Sim]

Cadastros

Selecionar Proj eto

Possui Usurio?
Configurar Proj eto

Manter Usurios
[No]

Possui Mapeamento ?
[Sim]
[Sim]

[No]
[No]

Vincular Usurios

Configurar Estrutura DB

Importar Estrutura DB

Fim

Fim

Gerao\Importao

Manter Componentes

Componente Nativo ?

Possui Entidade ?

Selecionar Componentes

[No]
[Sim]

[Sim]
Opes (Configurao)

Aes

Criar/Alterar Componete

Gerar

Manter Regras

Importar

Manter Campos de Regras

centralBuffer
Cdigo Fonte

Fim

Fim

Figura 14 - Diagrama de Atividades

5 EXEMPLO DE USO
Para realizao do caso prtico, foram selecionadas 10 classes com diferentes
caractersticas, estas classes constituem o mdulo de cadastro de um sistema de controle
patrimonial, o sistema em questo possui uma arquitetura bem definida, onde a camada que trata
das regras de negcio separada da camada de interface e da camada de modelo. No
desenvolvimento destas classes foram considerados como esforos relevantes para obteno de
mtricas comparativas, o nmero de propriedades e mtodo que cada classe possua como
especificao, e o tempo que se gastou para a codificao das assinaturas.
As classes foram desenvolvidas por um desenvolvedor de perfil pleno que possui como
rotina em sua funo, desenvolver estes padres de classes diariamente. Foi realizado um

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 so os seguintes:
Mesmo com os helps disponibilizados pelo editor Visual Studio 2008, houve muitas
compilaes para se eliminar os defeitos ocasionados pela sintaxe e pela tipagem exigida
na linguagem C#.
Ocorreram algumas despadronizaes nas nomenclaturas de variveis e mtodos criados
pelo programador, pois por mais que se tenha documentao referente a este assunto, o
risco deste fato acontecer em um cdigo desenvolvido manualmente alto,
principalmente se o desenvolvedor for um novato na equipe.
Se o projeto no possuir um ferramenta consistente de modelagem e especificao de
classes, o tempo de interao entre o desenvolvedor e o analista de sistemas aumenta por
conseqncia da falta de informao referente criao das classes, conseqentemente o
risco de defeitos por mal interpretao do que se deseja tambm.
Em um segundo momento foi executado a criao das mesmas 10 classes de forma
automatizada, ou seja, fazendo uso da ferramenta de gerao de cdigo. Nesta fase do experimento,
ocorreram fatos importantes para a boa utilizao e produtividade da ferramenta, que so eles:
Durante a usabilidade da ferramenta pelo usurio, notou-se uma pequena curva de
aprendizado, tanto para o que a ferramenta se prope a fazer, quanto para a sua
aplicao.
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 no possui.
Assim como a fase de configurao de templates no existe para a criao manual, a
ferramenta apresentou uma vantagem que beneficia o usurio em caso de recriao das
classes em outra arquitetura ou alteraes na mesma. Sendo que para isto seja possvel
basta apenas efetuar a manipulao dos templates e executar o processo de gerao das
mesmas.
5.1

Validao

Para efeitos comparativos foi criado um grfico de linha de tempo, conforme mostra a figura
15, onde demonstrado a diferena de tempos entre a criao manual e automatizada de cada
classe. Este experimento apontou uma produtividade bastante significativa na codificao, obtendo
uma mdia de ganho de 49% em relao ao mtodo manual. No grfico da figura 15 apresentado
apenas o benefcio cronolgico, sendo que tambm h outros benefcios significativos como a
padronizao e a gerao em outra arquitetura, a ltima coluna do grfico Total, demonstra a
diferena entre o somatrio total de horas da implementao manual e da forma automatizada.

14:24
12:00
09:36
07:12
04:48

Manual
Automa5zado

02:24
00:00

Figura 15 Grfico de Linha de Tempo

6 CONCLUSO
Neste trabalho foram identificados alguns pontos relevantes no desenvolvimento de software,
primeiro diz respeito ao custo do projeto, onde demandado um grande percentual de esforo na codificao
de aplicativos, como conseqncia 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 mo de obra. O segundo seria o custo da aquisio de uma Ferramenta CASE capaz de reduzir os
impactos e retrabalhos, porm restringindo a flexibilidade de customizao do cdigo gerado por suas
limitaes e padronizaes.
Conclui-se ento que, possvel desenvolver uma Ferramenta CASE objetiva e compacta, o que
torna seu custo mais baixo, atuando exatamente na camada de negcio das aplicaes, diminuindo o esforo
de mo de obra na fase de codificao, mantendo um padro configurvel e flexvel a diferentes arquiteturas.

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

APYON, Apyon Studio Professional 4.0. Disponvel 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 Usurio. 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 distribudos.
Disponvel 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 Lgico. So
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 avaliao e seleo de ferramentas case
baseado na norma ISO/IEC 14102. Artigo SEMINCO FURB-Universidade Regional de Blumenau, 1999.
MACORATTI.NET, Jos Carlos Macoratti. Padres de Projeto : O modelo MVC - Model View
Controller. Disponvel 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) . Disponvel por WWW em: < http://msdn.microsoft.com/enus/library/ms173183(VS.80).aspx>. Consultado em abril de 2010.
GENEXUS. Disponvel por WWW em: < http://www.genexus.com>. Consultado em junho de 2010.