gerador de artefatos para aplicações web

UNISALESIANO
Centro Universitário Católico Salesiano Auxilium
Curso de Tecnologia em Sistemas para Internet
Juliane Rosário
Murillo da Silva Casa Grande
GERADOR DE ARTEFATOS PARA APLICAÇÕES
WEB - ALPHAWEB
LINS – SP
2010
JULIANE ROSÁRIO
MURILLO DA SILVA CASA GRANDE
GERADOR DE ARTEFATOS PARA APLICAÇÕES WEB
Trabalho de Conclusão de Curso
apresentado à Banca Examinadora do
Centro Universitário Católico Salesiano
Auxilium, curso de Tecnologia em
Sistemas para Internet, sob a orientação
do Prof. M.Sc Anderson Pazin.
LINS – SP
2010
R713g
Rosário, Juliane; Grande, Murillo da Silva Casa.
Gerador de Artefatos para Aplicações Web - AlphaWEB / Juliane
Rosário ; Murillo da Silva Casa Grande. – – Lins, 2010.
90p. il. 31cm.
Monografia apresentada ao Centro Universitário Católico
Salesiano Auxilium – UNISALESIANO, Lins-SP, para graduação em
Tecnologia em Sistemas para Internet, 2010.
Orientador: Anderson Pazin
1. AlphaWEB. 2. Gerador de Artefatos. 3. Aplicações. 4. Software.
I. Título.
CDU 004
JULIANE ROSÁRIO
MURILLO DA SILVA CASA GRANDE
GERADOR DE ARTEFATOS PARA APLICAÇÕES WEB
Monografia apresentada ao Centro Universitário Católico Salesiano Auxilium,
para obtenção do título de Tecnólogo em Sistemas para Internet.
Aprovada em: 29 / 06 / 2010
Banca Examinadora:
Prof Orientador: Prof. M. Sc. Anderson Pazin
Titulação: Mestre em Ciência da Computação pela Universidade Federal de
São Carlos (UFSCar).
Assinatura: _________________________________
1º Prof(a): Prof. M.Sc. Luiz Eduardo Cortes Bergamo
Titulação: Mestre em Ciência da Computação pela Universidade Federal de
São Carlos (UFSCar).
Assinatura: _________________________________
2º Prof(a): Prof. M.Sc. André Ricardo Ponce do Santos
Titulação: Mestre em Administração pela Universidade Metodista de
Piracicaba (UNIMEP).
Assinatura: _________________________________
DEDICATÓRIA
Dedico este trabalho primeiramente à minha família, em especial aos meus pais
e minha irmã, pelo incentivo, apoio e esforços para me ajudar sempre. Ao meu
namorado Paulo, pelo apoio, paciência e compreensão durante a realização deste
trabalho. As minhas grandes amigas Mariana e Débora pela ajuda constante, incentivo,
carinho e amizade. Dedico ao meu grande amigo e companheiro de grupo Murillo por
conseguirmos realizar este trabalho.
Juliane
Dedico este trabalho á minha família, ao meu pai Sebastião, minha mãe Inês e
minha irmã Carolláine, que sempre me incentivaram e apoiaram. Aos amigos sempre
prestativos em diversos momentos de colaboração. Dedico a minha companheira de
grupo Juliane, grande amiga.
Murillo
AGRADECIMENTOS
Agradeço primeiramente a Deus pela fé e sabedoria.
A toda minha família, especialmente aos meus pais Valdecir e Rosangela e
minha irmã Viviane, pelo carinho, amor, incentivo, dedicação e principalmente pelo
grande esforço e me ajudar em mais esta etapa de minha vida.
Ao meu namorado e grande amigo Paulo, pela sua ajuda, incentivo,
compreensão, paciência e principalmente pelo seu grande apoio e incentivo em todos os
momentos na minha vida e durante a realização deste trabalho.
A minha amiga Mariana, pela sua grande amizade e apoio, por me incentivar
constantemente no dia-dia, obrigada pela sua grande ajuda sempre que preciso e por
estar ao meu lado nos momentos em que precisei.
A minha amiga de turma Débora, pelo grande incentivo a sempre buscar
resultados positivos, pelo seu grande carinho e amizade, e por sempre estar ao meu lado
constantemente no dia-dia, muito obrigada.
Ao orientador e professor Anderson Pazin, por sempre nos ajudar da melhor
forma possível e nos conduzir a conseguir os melhores resultados e objetivos durante
todo o curso, pelo seu apoio e incentivo a sempre fazermos o nosso melhor com
dedicação para a realização deste trabalho.
Ao companheiro e amigo de monografia Murillo pela amizade, ajuda, apoio,
incentivo, prestatividade e confiança durante todas as dificuldades do dia a dia que
tivemos para realizar este trabalho.
A todos os amigos e colegas de Faculdade que nos ajudaram de alguma forma
durante este trabalho e a todos que estiveram presentes e me ajudaram a alcançar mais
essa conquista.
A todos minha gratidão e muito obrigada!
Juliane
AGRADECIMENTOS
Agradeço a Deus.
A toda minha família, meus pais, pelo incentivo, colaboração e principalmente
pela presença positiva em minha vida.
Aos amigos que fiz no decorrer desta etapa da minha vida e que durante o
desenvolvimento do trabalho se mostraram prestativos, e sempre entre uma risada e
outra colaboraram com o que fosse necessário, especialmente Bruno, Débora, Maria
Eliza, Leandro e Pedro.
Ao orientador e professor Anderson Pazin, por sempre nos conduzir e incentivar
a buscar as melhores maneiras alcançar os objetivos no projeto. Por ser paciente e nos
transmitir tranquilidade e confiança.
A Juliane, pela amizade, prestatividade e imenso incentivo no decorrer deste
trabalho. Pela confiança depositada em mim e na capacidade de nossa dupla.
A todos, muito obrigado!
Murillo
RESUMO
Este trabalho refere-se a um gerador de artefatos para aplicações, que é
um software que produz automaticamente sub produtos de software para
aplicações a partir de suas especificações, oferecendo aos desenvolvedores
benefícios em termos de produtividade, pois reduz o tempo de
desenvolvimento da aplicação. A utilização de geradores de artefatos ajuda as
organizações a desenvolverem múltiplos produtos de uma família de software
com mais facilidades do que pelo modo de implementação tradicional. Além de
códigos, os geradores podem produzir a documentação do usuário e do
software, diagramas, casos de testes e figuras. Nota-se que eles têm como
principal objetivo acelerar e automatizar o processo de desenvolvimento de
software através do reuso de códigos pré-escritos, conhecidos como templates,
que definem parte de processos rotineiros de um determinado domínio,
reduzindo assim o tempo no desenvolvimento e os custos para sua
disponibilização e utilização. Este trabalho apresenta um Gerador de Artefatos
para Aplicações (AlphaWEB) que utiliza a plataforma Web e que não precisa
ser instalado na máquina do usuário. Foi desenvolvido para criar artefatos de
softwares a partir das tabelas existentes no banco de dados do desenvolvedor,
gerando automaticamente as classes javaBeans com as regras de negócio da
aplicação, javaDAO com as conexões com o banco de dados, os Servlets que
são os controladores da aplicação, scripts SQL do banco de dados e interfaces
HTML/JSP para a interação do usuário com o sistema. Esses artefatos são
criados em arquivos distintos do sistema operacional e são gerados de acordo
com as especificações fornecidas ao gerador. Esse gerador de artefatos tem
como objetivo diminuir as atividades repetitivas de copiar, colar e alterar.
Palavras-chave: AlphaWEB. Gerador de Artefatos. Aplicações. Software.
ABSTRACT
This work refers to a generator for artifacts about to applications, that that
is a software that automatically produces sub of software products for
applications from your specifications, giving developers the benefits in terms of
productivity, because reduces the development time of the application. The use
of generators of artifacts helps organizations develop several products from a
family of software with more ease than the traditional mode of implementation.
Beyond of code, the generators can produce user documentation and of the
software, diagrams, tests cases and figures. It is noted that they have as main
objective to accelerate and automate the process of software development
through the reuse of pre-written code, known as templates, which define part of
routine processes of a given domain, thus reducing development time and costs
for its availability and use. This paper presents a Artifacts Generator for
Applications (AlphaWEB) that uses the Web interface and which need not be
installed on the user's machine, was developed to create software artifacts from
existing tables in the database developer, automatically generating the
JavaBeans classes with the rules of application business, javaDAO with
connections to the database, the Servlets that are the controllers of the
application, SQL Scripts Database interfaces and HTML / JSP to the user's
interaction with the system. These artifacts are created in distinct files of the
operating system and are generated according to the specifications provided to
generator. This generator artifacts aims to reduce the repetitive activities of
copy, paste and change.
Keywords: AlphaWEB. Generator of Artifacts. Applications. Software.
LISTA DE FIGURAS
Figura 1. Diagramas definidos pela UML. ......................................................17
Figura 2. Diagrama de Classes. .....................................................................18
Figura 3. Diagrama de Objetos. .....................................................................19
Figura 4. Diagrama de Pacotes......................................................................19
Figura 5. Diagrama de Estrutura Composta...................................................20
Figura 6. Diagrama de Caso de Uso. .............................................................21
Figura 7. Diagrama de Componentes.............................................................21
Figura 8. Diagrama de Implantação. ..............................................................22
Figura 9. Diagrama de Sequência..................................................................23
Figura 10. Diagrama de Transição de Estado................................................23
Figura 11. Diagrama de Atividades. ...............................................................24
Figura 12. Diagrama de Colaboração ou Comunicação.................................25
Figura 13. Diagrama de Temporização. .........................................................25
Figura 14. Diagrama de Interatividade. ..........................................................26
Figura 15. Arquitetura de uma aplicação web utilizando Servlet. ...................29
Figura 16. Ciclo de vida do Servlet.................................................................30
Figura 17. Estrutura do padrão DAO..............................................................35
Figura 18. Modelo Tradicional de requisição Web versus o modelo AJAX. ...45
Figura 19. Interface de Definição de uma Aplicação – GawCRe....................51
Figura 20. Cadastro de Guias de Convênios de Pacientes – GawCRe..........51
Figura 21. Interface de Controle de Estoque de Produtos - GAS 2007..........52
Figura 22. Funcionamento de um Domínio do Sistema - DRACO-PUC.........53
Figura 23. Interface de Geração de Arquivo de Configuração - Captor. ........54
Figura 24. Interface de Armazenamento do Modelo da Aplicação - Captor. ..54
Figura 25. Diagrama de Classes e Objetos....................................................57
Figura 26. Diagrama de Use Case – Gerar Artefatos.....................................59
Figura 27. Diagrama de Classes a ser implementado....................................60
Figura 28. Diagrama de Classes para a Oficina Eletrônica. ...........................62
Figura 29. Diagrama de Sequência – Gerar Artefato. ....................................66
Figura 30. Utilização de templates durante a geração dos artefatos..............67
Figura 31. Conjunto de scripts de criação de tabelas utilizando SQL. ...........68
Figura 32. Template definido para scripts de criação das tabelas SQL. ........68
Figura 33. Template para construção de scripts de tabelas SQL...................69
Figura 34. Funcionamento do gerador e os artefatos por ele gerados...........70
Figura 35. Tela Inicial do Gerador. .................................................................71
Figura 36. Tela de Gerar Artefatos.................................................................72
Figura 37. Artefato de scripts SQL da Tabela Comissão................................73
Figura 38. Artefato Bean da Tabela Comissão...............................................73
Figura 39. Artefato HTML da Tabela Comissão. ............................................74
Figura 40. Conjunto de scripts de criação das classes Beans. ......................87
Figura 41. Template definido para criação das classes Beans. .....................87
Figura 42. Template para construção das Beans...........................................88
Figura 43. Template para construção das páginas HTML..............................89
Figura 44. Conjunto de scripts de criação das páginas HTML. ......................90
Figura 45. Template definido para criação das páginas HTML. .....................90
LISTA DE QUADROS
Quadro 1. Regras de trabalho com JavaBeans..............................................33
Quadro 2. Lista de Use Case. ........................................................................58
Quadro 3. Caso de Uso – Gerar Artefatos. ....................................................59
Quadro 4. Estrutura da Tabela Conserto de Aparelho. ..................................62
Quadro 5. Estrutura da Tabela Execução de Conserto..................................63
Quadro 6. Estrutura da Tabela Cliente...........................................................63
Quadro 7. Estrutura da Tabela Aparelho........................................................63
Quadro 8. Estrutura da Tabela Tipo de Aparelho...........................................64
Quadro 9. Estrutura da Tabela Técnico..........................................................64
Quadro 10. Regras de Validação da Tabela de Técnico................................64
Quadro 11. Estrutura da Tabela Comissão. ...................................................64
Quadro 12. Regras de Validação da Tabela Comissão..................................65
Quadro 13. Termos utilizados no trabalho......................................................83
LISTA DE SIGLAS E ABREVIATURAS
AJAX: Asynchrous JavaScript and XML
API: Interface de Programação de Aplicativos
ANSI: Instituto Nacional Americano de Padronização
ASP: Active Server Pages
CSS: Cascading Style Sheets
CAPTOR: Configurable Application Generator
DAO: Data Access Object
DBMS: Database Management System
DCL: Linguagem de Controle de Dados
DDL: Linguagem de Definição de Dados
DML: Linguagem de Manipulação de Dados
DOM: Document Object Model
DQL: Linguagem de Consulta de Dados
DTL: Linguagem de Transação de Dados
EE: Enterprise Edition
GB: Giga Bytes
GAwCRe: Gerador de Aplicações Web para Clínicas de Reabilitação
HTML: Linguagem de Marcação de Hipertexto
HTTP: Protocolo de Transferência de Hipertexto
ISO: Organização Internacional para Padronização
JEE: Java Enterprise Edition
JME: Java Micro Edition
JSE: Java Standard Edition
JDBC: Java DataBase Connectivity
JS: Java Script
JSP: Java Server Pages
LMA: Linguagem de Modelagem da Aplicação
MB: Mega Bytes
OMG: Object Management Group
OO: Orientada a Objetos
PDA: Assistente Pessoal Digital
PHP: Personal Home Page
RAC: Real Application Clusters
SE: Standard Edition
SGBD: Sistema Gerenciador de Banco de Dados
SGBDR: Sistema Gerenciador de Banco de Dados Relacional
SiGCli: Sistemas de Gestão de Clínicas
SO: Sistema Operacional
SQL: Linguagem de Consulta Estrutural
UML: Unified Modeling Language
URL: Localizador Padrão de Recursos
WML: Wireless Markup Language
XE: Express Edition
XHTML: eXtensible Hypertext Markup Language
XML: eXtensible Markup Language
SUMÁRIO
INTRODUÇÃO..................................................................................................14
1 FUNDAMENTOS CONCEITUAIS ...............................................................16
1.1
UML – UNIFIED MODELING LANGUAGE .......................................................16
1.2
PLATAFORMAS TECNOLÓGICAS ..................................................................27
1.2.1 A LINGUAGEM JAVA ..................................................................................27
1.2.2 SISTEMA GERENCIADOR DE BANCO DE DADOS ............................................37
1.2.3 AJAX.......................................................................................................42
2 GERADORES DE ARTEFATOS DE SOFTWARE .....................................46
2.1
ENGENHARIA DE SOFTWARE ......................................................................46
2.2
DEFINIÇÃO DE GERADORES DE ARTEFATOS ................................................47
2.3
DEFINIÇÃO DE TEMPLATES ........................................................................48
3 LEVANTAMENTO DE REQUISITOS..........................................................50
3.1
ANÁLISE DE MERCADO ..............................................................................50
3.2
DOCUMENTOS DE REQUISITOS...................................................................55
4 ANÁLISE ORIENTADA A OBJETOS.........................................................57
4.1
DIAGRAMA DE CLASSES – COMPLETO ........................................................57
4.2
JUSTIFICATIVA PARA IMPLEMENTAÇÃO ........................................................57
4.3
LISTA DE CASOS DE USO ...........................................................................58
4.4
DIAGRAMA DE CASOS DE USO ...................................................................58
4.5
DIAGRAMA DE CLASSES A SER IMPLEMENTADO............................................60
5 PROJETO DE BANCO DE DADOS ...........................................................61
5.1
DESCRIÇÃO DO SISTEMA DE OFICINA ELETRÔNICA ......................................61
5.2
TABELAS ..................................................................................................62
6 PROJETO ORIENTADO A OBJETOS .......................................................66
6.1
DIAGRAMA DE SEQUÊNCIA .........................................................................66
7 IMPLEMENTAÇÃO DO GERADOR DE ARTEFATOS ..............................67
7.1
LAYOUT DE TELAS ....................................................................................71
6.2.1 TELA INICIAL DO SISTEMA...........................................................................71
6.2.2 TELA DE GERAR ARTEFATOS ......................................................................71
7.2
ARTEFATOS GERADOS ..............................................................................72
CONCLUSÃO...................................................................................................75
REFERÊNCIAS ................................................................................................77
GLOSSÁRIO ....................................................................................................80
APÊNDICES .....................................................................................................84
14
INTRODUÇÃO
O desenvolvimento de softwares é um processo complexo e de difícil
realização, devido às mudanças de tecnologia e às alterações nos requisitos
que surgem no decorrer do processo de desenvolvimento (PAZIN, 2004).
Para facilitar esse processo, algumas técnicas podem ser utilizadas. O
reuso de software, visa diminuir a possibilidade de inserção de erros e com isso
o produto final pode ser gerado com maior qualidade (JUNIOR, 2006). A
técnica de reuso pode ser automatizada por softwares específicos chamados
de geradores ou wizards (PAZIN, 2004).
Geradores de Aplicações são ferramentas que têm a capacidade de
automatizar e acelerar o processo de desenvolvimento de softwares, por meio
de reuso de código pré-escrito, chamados de templates. Os geradores
permitem ao desenvolvedor inserir especificações do programa em alto nível e
a ferramenta gera um produto de software (PAZIN, 2004).
Com a utilização de geradores de aplicação, o desenvolvedor deve
inserir apenas as informações sobre “o que” deve ser feito, e a
ferramenta deve decidir “como” essas informações são transformadas
em código fonte (CLEAVELAND, 2001).
Os
geradores
de
aplicação
trazem benefícios
em termos
de
produtividade para o software, pelo fato de gerarem classes de alto nível com
base em suas especificações. Um dos problemas dos geradores de aplicação é
o elevado custo em seu desenvolvimento, utilização e manutenção (JUNIOR,
2006).
O objetivo deste trabalho é desenvolver um gerador de artefatos para
aplicações web. Artefatos são produtos de uma ou mais atividades dentro do
contexto de desenvolvimento de um software ou sistema. Esse gerador deve
criar as classes Java Beans da aplicação, as classes Java DAO para a
manipulação dos dados armazenados em um banco de dados, os
controladores da aplicação (Servlets), os scripts SQL de criação e manipulação
do banco de dados e as interfaces HTML e JSP para a aplicação. Esses
artefatos são gerados a partir das tabelas existentes em um banco de dados. O
objetivo principal do gerador é diminuir as tarefas repetitivas de copiar, colar e
alterar.
15
O processo de codificação que os geradores utilizam durante a
engenharia de aplicação pode ser mais rápido e menos suscetível a
erros humanos do que o processo tradicional de codificação, ou seja,
os geradores podem produzir códigos de forma sistemática e mais
segura em relação aos métodos tradicionais de programação
(CZARNECKI E EISENERCKER, 2000).
O desenvolvimento e a utilização deste gerador de aplicação pode ser
justificada pela diminuição de tarefas repetitivas e pelos benefícios oferecidos
como a alta qualidade do produto gerado, pois esses produtos gerados são
alterados de acordo com as informações que são fornecidas ao gerador, e que
assim facilita o desenvolvimento de uma nova versão do software.
16
1 FUNDAMENTOS CONCEITUAIS
1.1 UML – Unified Modeling Language
A Unified Modeling Language (UML) é uma linguagem de modelagem
gráfica e visual, designada para especificar, construir e documentar um
sistema, permitindo a visualização de softwares e aplicações em diagramas
padronizados (FOWLER, 2005).
Ela nasceu da unificação das linguagens de modelagem orientadas a
objetos existentes desde o final dos anos oitenta e início dos anos noventa. Em
1997, a UML foi aprovada como padrão pela OMG, tendo desde então grande
aceitação e utilização pela comunidade de desenvolvedores de sistemas.
Desde seu surgimento foram sendo criadas atualizações para tornar a
linguagem mais clara e útil (PENDER, 2004).
A UML é uma linguagem visual para modelar sistemas orientados a
objetos. Isso quer dizer que a UML é uma linguagem que define
elementos gráficos (visuais) que podem ser utilizadas na modelagem
de sistemas. Esses elementos permitem representar os conceitos do
paradigma da orientação a objetos. Através dos elementos gráficos
definidos nesta linguagem pode-se construir diagramas que
representam diversas perspectivas de um sistema (BEZERRA, 2007,
p. 15).
A linguagem de modelagem é uma notação utilizada para expressar e
indicar quais os passos a serem seguidos para o desenvolvimento de um
projeto. A especificação da UML consiste de duas partes (BEZERRA, 2007):
a) semântica: especifica a sintaxe abstrata e a semântica dos conceitos
de modelagem estática e dinâmica de objetos;
b) notação: especifica a notação gráfica para a representação visual da
semântica.
A UML suporta o desenvolvimento iterativo e incremental, que é um
processo de desenvolvimento de sistemas em pequenos passos. Uma iteração
é um laço de desenvolvimento que resulta na liberação de um subconjunto de
produtos que evolui até o produto final percorrendo as seguintes atividades:
análise de requisitos, análise, projeto, implementação e teste (PENDER, 2004).
17
A UML é projetada especificamente para representar sistemas
orientados a objetos (OO). As técnicas de desenvolvimento
orientadas a objetos descrevem o software como um conjunto de
blocos cooperativos de informações e comportamentos (PENDER,
2004, p. 5).
A UML permite ao desenvolvedor especificar, documentar e estruturar os
diagramas para uma maior visualização lógica do desenvolvimento completo
de um sistema de informação. (FOWLER, 2005). A UML foi projetada para
atender a algumas especificações, para que possa verdadeiramente ser um
padrão
que
resolva
as
necessidades
práticas
da
comunidade
de
desenvolvimento de software. A UML auxilia os desenvolvedores para
(PENDER, 2004):
a) oferecer aos desenvolvedores uma linguagem de modelagem pronta
para usar, expressiva e visual, para o desenvolvimento e a troca de
modelos significativos;
b) fornecer mecanismos de extensibilidade e especialização para
estender os principais conceitos;
c) admitir
especificações
independentes
das
linguagens
de
programação e dos processos de desenvolvimento específicos;
d) oferecer uma base formal para entender a linguagem de modelagem;
e) encorajar o crescimento do mercado de ferramentas de objetos;
f) admitir conceitos de desenvolvimento de nível mais alto, como
componentes, colaborações, frameworks e padrões.
Fonte: Bezerra, 2007 p. 18
Figura 1. Diagramas definidos pela UML.
18
A Figura 1 ilustra o modelo oficial da UML que se compõe de 13 tipos de
diagramas: classes, objetos, componentes, instalação, pacotes, estrutura, caso
de uso, transição de estado, atividade, sequência, interatividade, colaboração
ou comunicação e tempo (BEZERRA, 2007).
a) Diagrama de Classes: descreve os tipos de objetos presentes no
sistema e os tipos de relacionamentos existentes entre eles, é uma
representação da estrutura e relações entre as classes, que servem
de modelo para os objetos e seus comportamentos. Esse diagrama
pode ser observado na Figura 2.
Fonte: Fowler, 2005 p. 53
Figura 2. Diagrama de Classes.
b) Diagrama de Objetos: é uma varição do diagrama de classes
utilizando praticamente a mesma notação, e é tão importante quanto
ele. Normalmente permite desvendar as regras que precisam fazer
parte das definições dos recursos e seus relacionamentos. Tem
19
como objetivo admitir a investigação de requisitos e modelar os
casos de testes para validar o diagrama de classes. Exibe os objetos
instanciados em um sistema e a configuração de instâncias. A Figura
3 apresenta esse diagrama.
Fonte: Fowler, 2005 p. 95
Figura 3. Diagrama de Objetos.
c) Diagrama de Pacotes: mostra os pacotes e exibe suas respectivas
dependências. Um pacote é a representação de um grupo de classes
ou outros elementos que se relacionam com outros pacotes através
de uma relação de dependência. A Figura 4 representa um diagrama
de pacotes.
Fonte: Fowler, 2005 p. 98
Figura 4. Diagrama de Pacotes.
20
d) Diagrama de Estrutura Composta: é utilizado para descrever
relacionamentos entre os elementos do sistema e a colaboração
interna das classes, interfaces e componentes para e especificação
de uma funcionalidade. Os recursos estáticos influenciam classes e
associações, objetos, ligações e colaborações, oferecendo ao
framework no qual os elementos dinâmicos do modelo são
executados. Esse diagrama funciona de modo semelhante a uma
planta para a construção de um equipamento, mostra as partes e
como elas podem ser montadas, mas não pode mostrar como o
produto final se comportará. A Figura 5 apresenta um exemplo desse
diagrama.
Fonte: Fowler, 2005 p. 133
Figura 5. Diagrama de Estrutura Composta.
e) Diagrama de Caso de Uso: modela as expectativas dos usuários
para utilização do sistema, descrevendo a funcionalidade proposta
para um novo sistema que será projetado. É normalmente utilizado
como parte da abordagem de caso de uso, que inclui uma descrição
textual dos casos de uso individuais e a extração de cenários. Pode
ser escrito de maneiras diferentes, mas a mais comum é representar
a visão de fora do sistema. Diagramas de caso de uso identificam os
recursos específicos do sistema, comportamento compartilhado entre
21
os recursos e oferece modo simples e fácil de entendimento para os
clientes visualizarem os requisitos. A Figura 6 apresenta um exemplo
de diagrama de caso de uso.
Fonte: Fowler, 2005 p. 107
Figura 6. Diagrama de Caso de Uso.
f) Diagrama de Componentes: modela a visão da implementação
representando partes do software no ambiente de implementação,
ilustra como deverá ficar a organização das classes através de
componentes de trabalho. Sua finalidade é definir os modelos físicos
do software e seus relacionamentos entre si, os componentes podem
representar qualquer coisa desde uma classe até aplicações,
subsistemas e sistemas. Esse diagrama pode ser utilizado para
representação do relacionamento entre classes que especificam os
requisitos para os componentes. A Figura 7 apresenta esse
diagrama.
Fonte: Fowler, 2005 p. 135
Figura 7. Diagrama de Componentes.
22
g) Diagrama de Implantação: descreve os componentes de uma
arquitetura de execução, ou seja, a configuração do hardware e do
software, exibindo o layout físico do sistema revelando quais partes
do hardware e do software são executados. É consistido em nós
representando um tipo de recurso de processamento e associações
que define o tipo de relacionamento que dá suporte à comunicação
entre os nós. A Figura 8 é um exemplo de diagrama de implantação.
Fonte: Fowler, 2005 p. 103
Figura 8. Diagrama de Implantação.
h) Diagrama de Sequência: utilizado para representar informações de
forma simples e lógica de sequências de processos em um sistema,
tendo como foco a identificação da interação e comportamento entre
os grupos de objetos ao longo do tempo. Seu maior beneficio é a
ajuda na identificação de mensagens trocadas entre os objetos que
fazem perguntas e os que respondem. Normalmente isso ocorre em
cenários para caso de uso, capturando os comportamentos de um
único cenário e exibindo os objetos e as mensagens passadas entre
eles no caso de uso. São modelados em nível de objeto e não no
nível de classe, admitindo que vários objetos de uma mesma classe
23
possam trabalhar juntos. A Figura 9 representa um diagrama de
sequência.
Fonte: Fowler, 2005 p. 69
Figura 9. Diagrama de Sequência.
i) Diagrama de Transição de Estado: são técnicas para conhecer o
comportamento do sistema, é uma representação do estado ou
situação em que o objeto pode se encontrar no decorrer da execução
de processos de um sistema, passando assim o objeto de um estado
inicial para o estado final através de uma transição. Inclui notações
que explicam o comportamento do objeto enquanto ele muda de um
estado para outro e enquanto está em um estado específico. É
designado para mostrar o comportamento do ciclo de vida de um
único objeto. Esse diagrama pode ser observado na Figura 10.
Fonte: Fowler, 2005 p. 111
Figura 10. Diagrama de Transição de Estado.
24
j) Diagrama de Atividades: é uma técnica que descreve a lógica de
procedimento, representa processo de negócio e fluxo de trabalho
conduzido por processamento, desempenha papel semelhante aos
fluxogramas, e suportam comportamento paralelo. São importantes
somente para a modelagem de aspectos dinâmicos de um sistema e
para construção de sistemas executáveis por meio de engenharia
reversa. Diz o que acontece, mas não diz quem faz o que, este
diagrama não comunica qual classe é responsável por cada ação. A
Figura 11 é um exemplo de diagrama de atividades.
Fonte: Fowler, 2005 p. 119
Figura 11. Diagrama de Atividades.
k) Diagrama de Colaboração ou Comunicação: exibe interação entre
conjuntos de objetos e seus relacionamentos, incluindo mensagens
trocadas entre eles. Dá ênfase à ordenação estrutural em que as
mensagens são trocadas entre os objetos de um sistema. Oferecem
visão de alto nível da progressão lógica através das interações. Esse
diagrama é utilizado para dar ênfase no contexto do sistema, é
25
desenhado como um diagrama de objetos, onde os objetos são
exibidos juntamente com seus relacionamentos. A Figura 12 exibe
esse diagrama.
Fonte: Fowler, 2005 p. 130
Figura 12. Diagrama de Colaboração ou Comunicação.
l) Diagrama de Temporização: apresenta comportamento dos objetos
durante seu ciclo de vida e sua interação em uma escala de tempo,
focando as condições que mudam no decorrer desse período. É uma
outra forma de diagrama de interação, no qual o foco está nas
restrições de temporização para um ou vários objetos. Oferece visão
da mudança de estado do objeto enfatizando a importância do tempo
e da temporização. Seu layout é uma grade com eixos de tempo e
estado, utiliza duas formas de representação, uma linha de tempo de
estado (timeline) e uma linha de tempo de valor geral. Esse diagrama
é representado pela Figura 13.
Fonte: Fowler, 2005 p. 141
Figura 13. Diagrama de Temporização.
26
m) Diagrama de Interatividade: é uma mistura e variações de diagramas
de atividades e sequência, faz utilização do layout do diagrama de
atividades para modelar o fluxo da lógica em diversos eventos. Faz
modelagem de uma série de comportamentos discretos (atividades)
utilizando blocos de ocorrência de interação e realiza interação
individual que se expressa nos diagramas de sequência. Esse
diagrama é representado na Figura 14.
Fonte: Fowler, 2005 p. 140
Figura 14. Diagrama de Interatividade.
Um software ou aplicação que utiliza a UML como linguagem de suporte
à modelagem envolve a criação de diversos documentos, podendo ser textos
ou gráficos. Esses documentos são denominados artefatos de software que
compõem as visões do sistema. Os artefatos gráficos produzidos durante o
desenvolvimento de uma aplicação de software orientado a objetos são
definidos pela utilização dos diagramas da UML (BEZERRA, 2007).
27
1.2 Plataformas Tecnológicas
1.2.1 A Linguagem Java
Java é uma linguagem de programação, desenvolvida pela empresa Sun
Microsystems voltada para a programação Orientada a Objetos (OO). É
portável para diferentes plataformas e diferente das outras linguagens de
programação. A linguagem Java é compilada para um bytecode que é
executado e compilado por uma máquina virtual (JAVA, 2009).
A Sun lança a primeira plataforma universal de software, desenhada
a partir das tecnologias utilizadas na Internet e intranets corporativas.
A tecnologia Java possibilita aos desenvolvedores escrever
aplicativos uma vez, para rodar em qualquer computador (SUN,
2009).
Java foi criada com base nos elementos das linguagens C e C++ com
finalidade de adicionar conteúdo dinâmico a páginas da Web, como
interatividade e animações, atendendo as necessidades crescentes dos
usuários e desenvolvedores (DEITEL e DEITEL, 2005). Java é utilizada em
todos os principais setores corporativos de médio e grande porte no mundo
inteiro e está presente em uma ampla gama de dispositivos programáveis
como computadores, celulares, PDA, e redes (DEITEL e DEITEL, 2005).
A linguagem teve sua idéia principal amadurecida pelas mudanças
ocorridas no mundo da tecnologia, e foi implementada com o intuito de
abranger essas mudanças. A linguagem Java foi projetada com os seguintes
objetivos: orientação a objetos, portabilidade, recursos de rede e segurança, e
oferece diversas vantagens em relação ao uso de outras tecnologias de
servidor como: flexibilidade, e benefícios como escalabilidade de distribuir o
processamento
de
aplicações
desenvolvidas
em
diversos
servidores
(GONÇALVES, 2007).
Segundo o site da Sun Microsystems, em 1998, foi introduzida uma nova
tecnologia que permite maior velocidade, flexibilidade e um conjunto completo
de classes base, nas seguintes plataformas (SUN, 2009):
a) JSE (Java Standard Edition): é um ambiente básico destinado ao
desenvolvimento e execução das aplicações para desktops e
estações de trabalho;
28
b) JEE
(Java
Enterprise
Edition):
plataforma
voltada
para
desenvolvimento de aplicações de grande porte, onde a execução é
realizada em servidores, como aplicações para Web;
c) JME (Java Micro Edition): é destinada para desenvolvimento de
programas e aplicações para dispositivos móveis ou de pequeno
porte, como celulares.
A linguagem Java possui variações nas formas de desenvolvimento de
sistemas, devido às diferentes tecnologias existentes, oferecendo aos
desenvolvedores opções como: servidores web, banco de dados relacionais,
computadores de grande porte, telefones móveis, sistemas de cartão de
crédito, entre outros (BODOFF, 2005).
A linguagem Java nos dias de hoje é utilizada por grandes bancos,
pois fornece extrema segurança. Também é utilizada por grandes
empresas que necessitam de estabilidade, portabilidade e que
desejam trafegar uma grande quantidade de dados entre suas filiais
(GONÇALVES, 2007, p. 7).
Os programas Java consistem na criação de classes. As classes
possuem variáveis de instância (atributos) e métodos (ações do objeto) que
têm a função de realizar as tarefas e enviar informações ao concluí-las. Java
possui coleções de bibliotecas de classes que são conhecidas como API’s
(Application Programming Interfaces ou Interface de Programação de
Aplicativos) que ajudam aos programadores desenvolver suas classes ou
partes delas, e uma vez criadas as classes podem ser reutilizadas facilitando a
implementação e o desenvolvimento do software (DEITEL e DEITEL, 2005).
1.2.1.1 Servlets
Servlets são classes Java que dinamicamente processam requisição e
respostas, proporcionando novos recursos aos servidores (SERVLET, 2009).
São à base do desenvolvimento de qualquer aplicação escrita em Java para
Web (GONÇALVES, 2007).
Servlets são classes Java, desenvolvidas com uma estrutura bem
definida, e que quando instalada junto a um servidor que implemente
um Container Servlet (um servidor que permita a execução de
Servlets, muitas vezes chamado de Servidor de Aplicações Java),
29
podem tratar requisições recebidas de clientes (GONÇALVES, 2007,
p. 29).
Fonte: Deitel; Deitel, 2005 p. 931
Figura 15. Arquitetura de uma aplicação web utilizando Servlet.
Aplicações que utilizam arquitetura Servlets possibilitam a comunicação
entre clientes e servidores por meio do protocolo HTTP. A Figura 15 representa
os requerimentos e respostas a partir do momento em que o cliente envia uma
solicitação HTTP ao servidor. O container de Servlets recebe a solicitação e a
direciona para ser processada pelo Servlet apropriado. O Servlet realiza seu
processamento, podendo incluir e interagir com um banco de dados ou outros
componentes do servidor como outros Servlets e JSP. O Servlet retorna seus
resultados ao cliente geralmente na forma de um documento HTML, XHTML,
XML, ou em formatos de dados como imagens e dados binários (DEITEL e
DEITEL, 2005).
Alguns Servlets não produzem conteúdo, ao invés disso realizam tarefas
em favor do cliente e então invocam outros Servlets ou JSP para fornecer uma
resposta. Geralmente as tecnologias de Servlets e JSP são interligadas.
Todas as classes Servlets pertencem direta ou indiretamente à classe
GenericServlet, que trata dos métodos relacionados aos Servlets. A classe
HttpServlet estende-se da classe GenericServlet e é utilizada pelo protocolo
HTTP implementando métodos específicos como: get, post, head, trace, put,
delete, options e connect. Os mais comuns e utilizados são (GONÇALVES,
2007):
a) doGet: método que envia solicitação ao servidor, para que este
consiga um recurso e possa enviá-lo de volta;
b) doPost: envia solicitação e ao mesmo tempo dados ao servidor.
30
Os Servlets possuem ciclo de vida composto por três etapas:
inicialização, atendimento às requisições e finalização. O ciclo de vida do
Servlet é controlado pelo contêiner em que o Servlet foi implementado
(BODOFF, 2005).
Fonte: Gonçalves, 2007 p. 32
Figura 16. Ciclo de vida do Servlet.
A Figura 16 descreve os passos realizados quando uma requisição é
mapeada para um Servlet. O contêiner efetua as seguintes etapas de
funcionamento: carrega a classe de Servlet; cria uma instância da classe de
Servlet; inicializa a instância de Servlet chamando o método init; invoca
métodos de serviços (service), passa os objetos de requisição e resposta; e
finaliza o Servlet removendo-o com o comando destroy (BODOFF, 2005).
O método chave em cada Servlet é o método service(), que recebe tanto
um objetivo ServletRequest como um objetivo ServletResponse, fornecendo
acesso a fluxos de entrada e saída, permitindo o Servlet ler o dados do cliente
e enviar dados ao cliente. Comumente esse método não deve ser sobrescrito
(DEITEL e DEITEL, 2005).
1.2.1.2 JSP
Java
Server
Pages
(JSP)
é
uma
tecnologia voltada
para
o
desenvolvimento de aplicações para Web, que permite a criação de
componentes tanto estáticos como dinâmicos. É similar às tecnologias ASP
31
(Active Server Pages) e PHP (Personal Home Page), e por ser baseada na
linguagem de Java tem a portabilidade da plataforma, permitindo sua execução
em diversos sistemas operacionais (GONÇALVES, 2007).
Uma página JSP é um documento baseado em texto, que contém dois
tipos de textos: os dados estáticos que podem ser expressos por qualquer
formato baseado em texto tais como HTML, WML e XML, e os elementos JSP
que determinam como a página construirá seu conteúdo dinâmico (BODOFF,
2005).
A tecnologia JSP torna disponível todas as capacidades dinâmicas da
tecnologia Java Servlet, oferecendo uma abordagem mais natural para o
conteúdo estático (BODOFF, 2005). Uma página JSP, após ser hospedada em
um servidor de aplicações compatível a tecnologia JEE, é transformada em um
Servlet. O Tomcat e o GlassFish são exemplos de servidores compatíveis a
tecnologia JEE.
O JSP permite que o desenvolvedor de páginas para Internet possa criar
aplicações com acesso a banco de dados, manipular arquivos no formato de
texto, capturar informações de formulários e obter informações sobre o
servidor.
As bibliotecas de tag personalizadas são um recurso poderoso do
JSP que permite aos desenvolvedores em Java ocultar códigos
complexos para acesso de banco de dados e outros serviços úteis
para páginas da Web dinâmicas em tags personalizadas. Os sites
utilizam essas tags personalizadas como qualquer outro elemento de
página da Web para tirar proveito das funcionalidades mais
complexas ocultas pela tag. (DEITEL; DEITEL, 2005, p. 960).
Scripts JSP possibilitam a geração de conteúdo dinâmico como parte de
um documento HTML. Parte desse conteúdo depende da interação do usuário
por meio de solicitação de uma atualização da página feita ao servidor
(GONÇALVES, 2007).
Há quatro componentes-chaves para a criação de JSP: diretivas, ações,
scriptlets e bibliotecas de tags. Para o desenvolvimento de uma página JSP é
preciso conhecer as funcionalidades de cada elemento chave de JSP (DEITEL
e DEITEL, 2005, p. 960):
a) diretivas: são as mensagens que são enviadas ao contêiner
possibilitando o desenvolvedor configurar a página, incluir recursos e
32
especificar a utilização de bibliotecas. As principais diretivas são:
page, include e taglib;
b) ações: encapsula funcionalidades em tags predefinidas que são
incorporadas em uma página JSP. São frequentemente realizadas
com base em informações enviadas ao servidor como parte de uma
solicitação do cliente e permitem a instanciação de objetos Java para
uso em scriptlets JSP;
c) scriptlets ou elementos de script: permite a inserção de código Java
que tenha interatividade com componentes em um JSP e outros
componentes de aplicativos Web, para realização de algum tipo de
processamento mediante a solicitação do cliente e permite respostas
configuráveis às ações do usuário;
d) bibliotecas de tags: permite a criação de tags personalizadas ou a
utilização de tags preexistentes, facilitando o uso de código Java
para
projetistas
manipularem
conteúdo
JSP
com
pouco
conhecimento da linguagem.
A tecnologia Java Server Pages suporta diretamente o uso de
componentes JavaBeans com elementos de linguagem JSP padrão, podendo
facilmente criar e inicializar beans, e obter e definir os valores de suas
propriedades (BODOFF, 2005).
1.2.1.3 JavaBeans
JavaBeans são componentes feitos em Java, que são projetados para
ser independentes, reusáveis e modulares. As classes JavaBeans podem ser
objetos visíveis e empacotados, podendo assim ser distribuídos e utilizados
(BODOFF, 2005).
Uma classe para ser considerada JavaBean precisa seguir determinadas
convenções, que permitem a criação das ferramentas que poderão utilizar e
manipular os JavaBeans como: nomenclatura de métodos, construtores e
métodos (BODOFF, 2005).
As classes JavaBeans possuem o construtor sem argumentos e
métodos de acesso get e set. São classes amplamente utilizadas em conjunto
33
com páginas JSP, tendo a principal característica de separar a lógica do visual
(GONÇALVES, 2007). Essas classes podem realizar qualquer tipo de tarefa
dentro de uma aplicação Java e, se utilizadas corretamente, podem reduzir
beneficamente a quantia de código (GONÇALVES, 2007).
O JavaBeans não existe apenas para o desenvolvimento Web, como
é largamente usado. Sua concepção inicial era a reutilização de
programação visual, os famosos “Beans” do Swing. Tecnicamente
JavaBeans é o termo correto para a reutilização de partes de
programas visuais, com certas funcionalidades, mas que passou a
ser conhecida popularmente como componentes, na programação
visual para desktop (GONÇALVES, 2007, p. 171).
Os JavaBeans existem tanto para modelar sistemas gráficos criados
para desktop ou também para aplicações Web em conjunto com páginas JSP
(GONÇALVES, 2007).
Regra
Descrição da Regra
Se o JavaBean não contiver nenhum construtor declarado
Construtor
explicitamente, o interpretador Java considerará, que já faz parte da
definição da linguagem, a existência de um construtor implícito sem
argumentos e sem implementação de código no corpo do método.
O JavaBens pode implementar interfaces que possibilitem a
persistência e restauração do estado do objeto da classe, mas essa
Persistência
regra não precisa ser obedecida. A não existência dessa
implementação o impossibilita de ser salvo em arquivo ou ser
enviado de um computador para outro em uma aplicação
distribuída.
O JavaBean criado deve conter qualquer método para tratamento
de eventos, possuir um atributo que deseja obter seu valor, ele
deve ser acessível por um método público que de preferência, deve
ter mesmo nome, com o prefixo get. Para alterar o valor do atributo,
Atributos
o mesmo deve ser feito por outro método, também público, void,
com prefixo set, tendo um parâmetro de mesmo tipo para a
mudança.
Executando
essa
normativa
têm-se
os
atributos
encapsulados. Portanto esses mesmos atributos devem ser
qualificados como protected ou private.
Fonte: Gonçalves, 2007, p. 182.
Quadro 1. Regras de trabalho com JavaBeans.
34
As convenções de projeto de componente JavaBean governam as
propriedades da classe e os métodos públicos que fornecem acesso para as
propriedades. Uma propriedade de um componente JavaBeans pode ser
(BODOFF, 2005):
a) leitura/escrita, somente leitura ou somente escrita;
b) simples, o que significa que ela contém valor único, ou indexada que
significa que ela representa um array de valores.
1.2.1.4 JavaDAO
Data Access Object (DAO) é um modelo para persistência de dados em
aplicações de banco de dados relacional (BEZERRA, 2007). É um padrão que
permite separar regras de negócios das regras de acesso, garantindo a
independência dos mecanismos de persistências (BEZERRA, 2007).
A função da classe DAO é abstrair e encapsular o acesso às fontes de
dados e realizar a gerência de conexão com a fonte e saber como obter os
dados, tendo como finalidade definir uma arquitetura para o mapeamento
objeto relacional, diminuir dependência com a fonte de dados e reduzir
redundância. Sua utilização possui vantagens
e desvantagens
como
(BEZERRA, 2007):
a) vantagens: transparência quanto ao mecanismo de persistência,
facilita migração para outras implementações, reduz complexidade
do código nos objetos de negócio, não possui dependência entre a
classe de domínio e a classe de negócio, possui dependência da
fonte de dados em único ponto;
b) desvantagens: escrita de código de mapeamento básico.
Embora o padrão DAO traga maior flexibilidade para a aplicação, uma
desvantagem é que ele aumenta a complexidade de implementação,
pelo simples fato de a quantidade de classes aumentar. Portanto,
uma questão que deve ser avaliada é com relação aos aspectos de
complexidade e flexibilidade quando o uso do padrão estiver sendo
cogitado (BEZERRA, 2007, p. 355).
A utilização do padrão DAO permite uma aplicação obter acesso a
objetos de negócio que estão associados às informações persistentes, a
interação da aplicação com o objeto ocorre por meio de uma interface, a
35
chamada interface DAO (BEZERRA, 2007). Seu conceito é separar a relação
do cliente de um recurso dos dados de seu mecanismo de acesso aos dados.
Classes que fazem implementação da classe DAO se comprometem a
transformar as informações provenientes do mecanismo de armazenamento
em objetos de negócios e a armazenar informações de um objeto de negócio
no mecanismo de armazenamento em uso. A Figura 17 exibe a estrutura do
padrão DAO (BEZERRA, 2007).
Fonte: Bezerra, 2007 p. 354
Figura 17. Estrutura do padrão DAO.
O padrão DAO é uma forma de desacoplar as classes do negócio dos
aspectos relativos ao acesso aos mecanismos de armazenamento persistente.
Esse padrão controla a conexão com a fonte de dados para obter e armazenar
dados (BEZERRA, 2007).
Geralmente tem-se um DAO para cada objeto do domínio do sistema ou
então para cada módulo ou conjunto de entidades fortemente relacionadas.
Cada DAO deve possuir uma interface que contenha os métodos de
manipulação de dados (BEZERRA, 2007).
Pode ser que uma aplicação tenha a necessidade de armazenar
informações não somente em diferentes SGBDR, mas também em
outros tipos de mecanismos de armazenamento persistentes, tais
como arquivos no sistema operacional, sistemas legados, serviços
externos, etc. O padrão DAO é uma solução para esse dilema
(BEZERRA, 2007, p. 353).
Um aspecto importante do padrão DAO é que ele pode ser aplicado não
somente em caso de mapeamento de um objeto para uma tabela, mas também
para casos mais complexos envolvendo junções entre objetos e procedimentos
armazenados no SGBD (BEZERRA, 2007).
36
1.2.1.5 JDBC
Java DataBase Connectivity (JDBC) é uma API completa que consiste
em um conjunto de classes e interfaces incluídas dentro da linguagem Java
para programação com acesso a banco de dados, faz o envio das instruções
SQL para o banco de dados relacional (GONÇALVES, 2007).
Pelo fato de JDBC ser escrito em Java, ele possui a vantagem de ser
independente de plataforma. Uma aplicação escrita utilizando JDBC poderá
trabalhar com diversos bancos de dados como: Oracle, MySQL, SQL Server,
PostegreSQL, e etc (GONÇALVES, 2007).
Os programas Java comunicam-se com banco de dados e manipulam
TM
seus dados utilizando a API do JDBC . Um driver JDBC permite aos
aplicativos Java conectar-se a um banco de dados em um DBMS
particular e permite aos programadores manipular esse banco de
dados utilizando a API do JDBC. O JDBC é quase sempre utilizado
com um banco de dados relacional, entretanto ele pode ser utilizado
com qualquer origem de dados baseada em tabela (DEITEL; DEITEL,
2005, p. 895).
As APIs JDBC são divididas em duas partes que possibilitam ao
desenvolvedor de aplicativos utilizarem vários serviços e são consistidas em
pacotes como (GONÇALVES, 2007):
a) java.sql: contém classes e interfaces em nível de aplicativos, são
utilizadas pelos componentes do aplicativo e são necessárias para
acessar e lidar com o banco de dados;
b) javax.sql: contém classes e interfaces que são usadas pelo servidor
de fonte de dados, sua principal inclusão é o DataSource que
possibilita uma alternativa para DriverManager, inclui pool de
conexão, transações distribuídas e a implementação de RowSet.
Cada banco de dados possui um driver JDBC, esses drivers são
divididos em quatro categorias: Ponte JDBC-ODBC, Driver API-Nativo, Driver
de Protocolo de Rede e Driver Nativo (JDBC, 2009).
Tecnologias como JDBC (Java DataBase Connectivity) e ADO.NET
são uma tentativa de blindar as aplicações das particularidades de
cada SGBDR. Essas tecnologias fornecem APIs que podem ser
utilizadas para acesso padronizado a SGBDR. Com o uso de uma
dessas tecnologias, uma mesma API é utilizada pelo programador
para ter acesso a informações em um SGBDR, não importando qual é
37
o SGBDR especifico em uso no momento. Se os dados da aplicação
tiverem que ser movidos para outro SGBDR, essa aplicação não
precisa ser alterada, por conta de estar utilizando uma API
padronizada (BEZERRA, 2007, p. 353).
O JDBC para aperfeiçoar e melhorar suas funcionalidades utiliza as
propriedades de recuperação de metadados, garantindo que quando o modelo
relacional for alterado a aplicação não precise sofrer nenhuma manutenção
(MARCANDALI, 2002).
Os metadados ou dicionários de dados são dados sobre outros dados,
são dados de alto nível que descrevem um dado de nível inferior
(MARCANDALI, 2002). Um item de um metadado diz do que aquele dado se
trata, na maioria das vezes são informações ilegíveis por um sistema de
computador (METADADOS, 2009). Através dos metadados, as informações
podem ser consultadas, atualizadas e processadas, eles facilitam o
entendimento dos relacionamentos e a utilidade das informações de dados
(MARCANDALI, 2002).
A utilização de metadados permite que uma aplicação recupere dados
de um banco de dados sem conhecer previamente os dados que vai coletar,
sendo de qualquer tabela ou suas características (MARCANDALI, 2002).
1.2.2
Sistema Gerenciador de Banco de Dados
Um banco de dados ou base de dados é uma coleção organizada de
dados que oferece mecanismos para armazenar, organizar, recuperar e
modificar dados (DEITEL; DEITEL, 2005). Pode ser considerado como um
repositório
ou
recipiente
para
coleções
de
arquivos
de
dados
computadorizados (DATE, 2004). Um sistema de gerenciamento de banco de
dados
(DBMS
–
Database Management
System)
permite
acesso e
armazenamento de dados sem envolver a representação interna dos dados
(DATE, 2004).
A utilização de banco de dados implica em diversas vantagens para o
usuário como: poder obter e atualizar os dados com rapidez e velocidade,
redução de trabalho manual monótono, as informações são precisas e
atualizadas e estão disponíveis a qualquer momento para consulta, os dados
são mais protegidos contra perda e acesso ilegal (DATE, 2004).
38
A tecnologia dos bancos de dados tem provocado grande impacto na
utilização de computadores. É viável afirmar que os bancos de dados
representam um papel crítico em quase todas as áreas em que os
computadores são utilizados, incluindo negócios, comércio eletrônico,
engenharia, medicina, direito, educação, as ciências da informação,
etc. (ELMASRI; NAVATHE, 2005 p. 4).
A definição de um banco de dados implica em definição e especificação
de seus tipos de dados, em estruturas e as restrições para os dados serem
armazenados em um banco de dados (ELMASRI e NAVATHE, 2005).
Os bancos de dados podem ser de qualquer tamanho e de
complexidade variada, pode ser gerado e mantido por um grupo de aplicativos
escritos para desempenhar a tarefa de sistema gerenciador de banco de dados
(SGBD). Os bancos de dados oferecem diversas operações como (ELMASRI e
NAVATHE, 2005):
a) acrescentar novos arquivos ao banco de dados;
b) inserir, alterar e excluir dados em arquivos existentes;
c) buscar dados de arquivos existentes;
d) remover arquivos existentes do banco de dados.
Essas operações, disponíveis por meio de um SGBD, funcionam como
um mecanismo de inter-relação entre arquivos e programas para manter um
banco de dados (ELMASRI e NAVATHE, 2005). Para facilitar a interação dos
usuários com o sistema, o desenvolvedor deve omitir as complexidades da
estrutura de dados por meio dos diversos níveis de abstração (ELMASRI e
NAVATHE, 2005).
Os SGBD’s são projetados para administrar uma grande quantidade de
informações, proporcionando um ambiente conveniente e eficiente para facilitar
esta gestão (DATE, 2004).
Os principais bancos de dados existentes no mercado trabalham com o
modelo relacional. Esse nome representa o banco de dados como uma coleção
de relações, sendo que cada relação se parece com uma tabela de valores
(ELMASRI e NAVATHE, 2005). Esse modelo tem como finalidade organizar os
dados em forma de tabelas, cada tabela é chamada de relação, as colunas são
os atributos e as linhas são chamadas de tupla (ELMASRI e NAVATHE, 2005).
Um banco de dados relacional consiste de uma coleção de tabelas com
estrutura similar, do qual cada tabela possui um nome único (DATE, 2004).
39
Uma linha em uma tabela representa um relacionamento entre um determinado
conjunto de valores, uma vez que uma tabela é uma coleção desses
relacionamentos, há uma correspondência entre o conceito de tabela e o
conceito matemático de relação (DATE, 2004).
Todo banco de dados precisa ter uma forma de inserir e extrair dados,
de preferência utilizando uma linguagem que seja entendida por todos os
bancos de dados (DATE, 2004). Os SGBD implementam uma linguagem
padrão conhecida como Structured Query Language (SQL) que permite
recuperar, adicionar, modificar e excluir informações em um banco de dados
(DATE, 2004).
Os sistemas mais populares de hoje são os banco de dados
relacionais. Uma linguagem chamada SQL é a linguagem padrão
internacional utilizada quase universalmente com banco de dados
relacionais para realizar consultas (isto é, solicitar informações que
satisfazem os critérios dados) e manipular dados (DEITEL; DEITEL,
2005, p. 895).
Os SGBD’s mais conhecidos e utilizados no mercado atualmente são os
seguintes: Oracle, MySQL, PostgreSQL, SQL Server (DEITEL e DEITEL,
2005).
1.2.2.1 A Linguagem SQL
SQL (Linguagem de Consulta Estrutural) é a linguagem padrão para
banco de dados. Originalmente chamada de Sequel, foi desenvolvida pela IBM
Research no início dos anos 70, com sua evolução, seu nome foi mudado para
SQL (DATE, 2004). Apesar do nome, a linguagem tem muitas funções além de
consultar o banco de dados, como definir estruturas de dados, modificar dados
no banco ou especificar restrições de segurança (DATE, 2004).
Essa linguagem é aceita por quase todos os produtos existentes no
mercado, possibilita a criação e manipulação de tabelas, inclui operações de
definições e manipulação dos dados nelas armazenados e é a linguagem para
banco de dados mais utilizada no mercado nos dias de hoje (DATE, 2004).
Em sua forma original, a SQL pretendia ser especificamente uma
“sublinguagem de dados”. Porém, com a incorporação do recurso de
Módulos Armazenados Persistentes (SQL/PSM, ou PSM – Persistent
Stored Modules) ao padrão em 1996, o padrão se tornou completo
40
em termos computacionais, ele agora inclui instruções como CALL,
RETURN, SET, CASE, IF, LOOP, LEAVE, WHILE e REPEAT, bem
como características relacionadas à capacidade de declarar variáveis
e tratadores de exceções (DATE, 2004, p. 72).
A SQL é dividida em partes, devido à grande quantidade de comandos
em sua estrutura (DATE, 2004):
a) DML (Linguagem de Manipulação de Dados): é um subconjunto da
linguagem utilizada para inserir, atualizar e apagar dados;
b) DDL (Linguagem de Definição de Dados): permite durante a
atualização a definição de novas tabelas e elementos associados;
c) DCL (Linguagem de Controle de Dados): controla os respectivos
aspectos da autorização de dados e licenças de usuários para
controlar quem tem acesso para ver ou manipular os dados em um
banco de dados;
d) DTL (Linguagem de Transação de Dados): utilizado para marcar o
início de uma transação no banco de dados, podendo ser uma
transação completa ou não;
e) DQL (Linguagem de Consulta de Dados): possui apenas um
comando “select”, é a parte mais utilizada na SQL, pois esse
comando permite o usuário especificar uma consulta com a
descrição do resultado desejado, é composto de cláusulas e opções
que possibilitam a elaboração de consultas simples e complexas.
A linguagem SQL é a linguagem padrão de banco de dados devido a
sua simplicidade e facilidade de uso, sua maior diferença das outras linguagens
de consulta é que suas consultas especificam a forma do resultado e não o
caminho para chegar até ele (DATE, 2004). É uma linguagem padronizada pela
ANSI e pela ISO, possui diferentes variações e extensões devido à produção
de diferentes SGBD’s, pode ser migrada de plataforma sem necessitar de
mudanças estruturais (DATE, 2004).
1.2.2.2 Oracle
O Oracle surgiu no fim dos anos 70, foi desenvolvido por Larry Ellison,
Bob Miner e Ed Oates, que perceberam a partir de uma descrição de um
41
protótipo do modelo de banco de dados relacional, o grande potencial de
negócio deste modelo de banco de dados e descobriram que nenhuma
empresa havia comercializado essa tecnologia (ORACLE, 2009). Quase trinta
anos depois de seu desenvolvimento, a Oracle Corporation mudou a face da
computação empresarial e sua tecnologia está presente mundialmente em
quase todos os setores (ORACLE, 2009).
A Oracle Corporation possui diferentes versões do software de
gerenciamento de banco de dados. Essas versões estão subdivididas em
"edições" por razões de marketing e controle de licenças (ORACLE, 2009):
a) Enterprise Edition (EE): inclui diversas funcionalidades, mas seu foco
principal é nas áreas de desempenho e segurança, é licenciado para
usuários ou núcleos de processamento de servidor para quatro ou
mais computadores, não possui limite de memória e faz atualizações
utilizando o software Oracle RAC;
b) Standard Edition (SE): possui as funcionalidades básicas de banco
de dados, é licenciado para usuários ou de sockets, para servidores
com um a quatro computadores, não possui limite de memória e
pode fazer atualização com o Oracle RAC sem custo adicional;
c) Standard Edition One: introduzido com o Oracle 10g, possui
restrições de funcionalidades adicionais, é comercializado para
sistemas com um ou dois computadores e não possui restrições de
memória;
d) Express Edition (XE): oferece o Oracle 10g livre para a distribuição
nas plataformas Windows e Linux, possui limite de memória de 1GB
e no máximo 4GB de dados de usuário, é restrita para utilização em
apenas um computador, o suporte é feito em fóruns on-line sem o
suporte da Oracle;
e) Oracle Personal Edition: oferece funcionalidade da EE mais é
comercializada para desenvolvedores específicos que utilizam
estações de trabalho pessoais;
f) Oracle Database Lite: destinada para rodar em dispositivos móveis, o
banco de dados é localizado no próprio dispositivo móvel, pode ser
sincronizado com uma instalação baseada em servidor.
42
O SGBD da Oracle é líder de mercado, o Oracle 9i foi pioneiro no
suporte ao modelo web. O Oracle 10g, mais recente, se baseia na
tecnologia de grid. Recentemente fora lançado o Oracle 11g que veio
com melhorias em relação ao Oracle 10g (ORACLE, 2009).
A Oracle também criou a linguagem de programação PL/SQL, que é
utilizada no processamento de transações (ORACLE, 2009).
Escolheu-se utilizar a tecnologia Oracle no Gerador de Artefatos porque
julga-se ser ela a mais confiável do que as demais tecnologias de SGBD’s
disponíveis no mercado e sabe-se de sua grande aceitação na maior parte das
empresas.
1.2.3
AJAX
O termo AJAX (Asynchrous JavaScript and XML) foi criado por Jesse
James Garrett, quando apresentava a tecnologia até então sem nome a um
cliente (DEITEL e DEITEL, 2008). As tecnologias que compõem o AJAX já
existiam havia muitos anos antes de sua criação e são brevemente descritas a
seguir (GONÇALVES, 2006):
a) XHTML (eXtensible Hypertext Markup Language): é a reformulação
da linguagem de marcação HTML, é baseada em XML e combina
tags de marcação HTML com regras XML, pode ser exibido em
páginas da Web através de diversos dispositivos independente da
plataforma utilizada, como: celular, PDAs, palm, televisão, etc,
visando melhorar a acessibilidade, pois suas marcações possuem
sentido semântico para as máquinas;
b) CSS (Cascading Style Sheets): é uma linguagem de estilo em
cascata, padrões para definir a formatação em páginas da Web. O
CSS, ao invés de ser criado dentro do próprio documento, é criado
separado e possui um link de ligação com a página do documento,
tendo assim benefícios como: a separação entre o conteúdo de
formatação e o conteúdo da página escrito na linguagem de
marcação, possui reutilização de um estilo em diversas páginas e
oferece facilidade na padronização de um layout;
c) JavaScript (JS): é uma linguagem de programação de scripts, criada
para ser uma forma de controle do navegador, é utilizada para
43
acrescentar interesses e aumentar a interatividade entre as páginas
da Web, modifica dinamicamente os estilos dos elementos de
páginas em HTML. É uma linguagem interpretada ao invés de ser
compilada. Tem sintaxe semelhante à linguagem Java, mais é
diferente em conceito e utilização;
d) DOM (Document Object Model): é API e plataforma de interfaces que
permite de forma padrão programas e scripts acessar e atualizar o
conteúdo, estrutura e estilo de documentos, permitindo assim que o
conteúdo seja processado e os resultados desse processamento
sejam incorporados no próprio documento. Os elementos de um
documento DOM podem ser trabalhados separadamente e por esse
motivo facilitarem a criação de páginas altamente dinâmicas. DOM
pode ser agrupado em cinco categorias: DOM Core, DOM HTML,
DOM CSS, DOM Events e DOM XML. Possui um modelo de eventos
que permite a associação de eventos do usuário a scripts
programados em uma página da Web;
e) XML (eXtensible Markup Language): é uma linguagem de marcação
que descreve dados, tendo foco na descrição de dados, permite o
armazenamento de informações de uma forma estruturada, possui a
portabilidade e características de tags e atributos semelhantes ao
HTML, porém não contém tags pré-definidas. Os documentos XML
são formados inteiramente por elementos. Essa linguagem de
marcação tem como propósito a facilidade de compartilhamento de
informações através da internet e sua principal característica é criar
infraestrutura única para diversas linguagens;
f) XMLHttpRequest: é um objeto da linguagem JavaScript utilizado para
realizar a comunicação assíncrona entre as páginas da Web e o
servidor de aplicações, não é necessário carregar páginas completas
carrega apenas partes necessárias delas. Esse objeto possibilita a
portabilidade
para
outros
sistemas
operacionais
e
trata
as
requisições e respostas do servidor com o documento XML ou DOM.
Contém métodos que possibilitam ao browser realizar as requisições
e receber respostas do servidor sem necessitar atualizar a tela.
44
O AJAX desempenha um papel vital na Web 2.0, particularmente na
criação de aplicações e melhorias das experiências geral dos usuários (DEITEL
e DEITEL, 2008). É uma tecnologia funcional, pois a maior parte dos browsers
estão habilitados para suportar as tecnologias que o incorporam (DEITEL e
DEITEL, 2008).
Em vez do modelo de aplicação Web tradicional, onde o próprio
browser é responsável por iniciar os pedidos e processar os pedidos
do servidor Web, o modelo AJAX provê uma camada intermediária
para controlar esta comunicação (GONÇALVES, 2007 p. 590).
AJAX permite atualizações parciais de páginas, atualizando partes
individuais de uma página da Web sem necessitar recarregar a página inteira
(DEITEL e DEITEL, 2008). Isso gera uma interface sensitiva, possibilitando que
os usuários interajam com a página enquanto o servidor processa as
requisições (DEITEL e DEITEL, 2008).
O AJAX possui um conjunto de funções que são escritas em JavaScript
que são chamadas quando uma informação é solicitada ou enviada ao servidor
(OLSON, 2007). O AJAX oferece dois recursos para a captura de respostas em
uma aplicação Web dinâmica: responseText e responseXML (OLSON, 2007).
Quando a estrutura de mecanismo do AJAX recebe a resposta do
servidor, começa executar a ação da análise dos dados, onde eles sofrem
mudanças para trazer a informação de forma agradável e entendível ao usuário
(CRANE; PASCARELLO; JAMES, 2007). Os recursos utilizados durante esse
processo são menores que o do modelo tradicional, pois a única requisição
solicitada é somente do conteúdo e não da página em si, que já está carregada
no cliente e pronta para receber os dados (CRANE; PASCARELLO; JAMES,
2007).
O AJAX é o elo que os desenvolvedores precisavam para entender o
que o JavaScript é capaz de fazer, e principalmente a possibilidade
de trazer dados vindos do servidor sem causar maiores tráfegos,
dando assim à aplicação Web as características de uma aplicação
Desktop (GONÇALVES, 2006 p. 08).
A Figura 18 demonstra o modelo de uma aplicação web tradicional e faz
uma comparação de suas funcionalidades com o modelo de uma aplicação
web que faz utilização de AJAX.
45
Fonte: Gonçalves, 2006, p. 06
Figura 18. Modelo Tradicional de requisição Web versus o modelo AJAX.
De acordo com a Figura 18, quando uma página que contém AJAX é
inicializada, o tráfego de informações tem maior intensidade no início, devido à
parte lógica da aplicação ser movida para o navegador, pois as informações de
interatividade para o navegador e o servidor devem ser previamente
carregadas (GONÇALVES, 2006). Quando o usuário acessa a página, um
documento complexo é enviado ao navegador, onde as informações são scripts
em JavaScript, e enquanto o browser não for fechado, a parte lógica
permanecerá por toda sessão (GONÇALVES, 2006). Após o carregamento
inicial da página, as chamadas ao servidor são mais eficientes, pois o tráfego é
menor já que os dados carregados serão em menor quantidade do que em
uma aplicação Web comum (GONÇALVES, 2006).
46
2 GERADORES DE ARTEFATOS DE SOFTWARE
2.1 Engenharia de Software
O processo de software ou engenharia de software é uma sequência
estruturada de conjuntos de práticas e atividades que são utilizadas para o
desenvolvimento ou manutenção de um software (MACORATTI, 2010). Essas
práticas são caracterizadas pela interação de ferramentas, pessoas e métodos,
elas englobam as atividades de especificação, projeto, implementação e testes
(MACORATTI, 2010).
Um processo de software pode ser entendido como um conjunto
estruturado de atividades exigidas para desenvolver um sistema de
software. Assim tem-se a seguinte definição: O processo de software
é um conjunto de atividades e resultados associados que produzem
um produto de software (MACORATTI, 2010).
O processo de software é divido em fases que devem ser realizadas
durante o desenvolvimento de um software ou aplicação, essas fases podem
ser realizadas simultaneamente de acordo com as necessidades de cada
desenvolvedor, isto é, sem possuir uma ordem obrigatória de desenvolvimento
(MACORATTI, 2010). Dentre as fases que devem ser realizadas em um
processo de desenvolvimento de software destacam-se as quatro principais
fases a seguir (MACORATTI, 2010):
a) especificação dos requisitos: tradução das necessidades e requisitos
operacionais para uma descrição detalhada das funcionalidades a
serem executadas;
b) projeto do sistema: tradução destes requisitos em uma descrição de
todos os componentes que são necessários para codificar o sistema;
c) programação: produção dos códigos e scripts que controlam o
sistema e realizam a computação lógica envolvida;
d) verificação e integração: verificação da satisfação dos requisitos
iniciais e a integração com produto produzido.
Pode-se considerar, que de uma forma geral o processo de software
pode ser visto como um conjunto de padrões voltados para a construção de um
47
produto de software (MACORATTI, 2010). Para a definição e utilização de um
processo de software o desenvolvedor deve levar em consideração algumas
informações como: as atividades a serem realizadas, os recursos necessários,
os artefatos requeridos e produzidos, os procedimentos adotados e o modelo
de ciclo de vida utilizado (MACORATTI, 2010).
O processo de software pode ser definido como um conjunto de
atividades uniformizadas a serem aplicadas sistematicamente que se
encontram agrupadas em fases, cada uma das quais com os seus
intervenientes com responsabilidades, que possui diversas entradas e
produz diversas saídas. Isto é, define quem faz o quê, quando e
como para atingir um certo objetivo (MACORATTI, 2010).
A definição e utilização de um processo para construção de um software
são realizadas pelo desenvolvedor pelas principais razões descritas a seguir
(MACORATTI, 2010):
a) redução dos problemas relacionados a treinamentos, revisões e
suporte à ferramentas da aplicação;
b) as experiências adquiridas nos projetos são incorporadas ao
processo padrão e contribuem para melhorias em todos os
processos definidos;
c) economia de tempo e esforço na definição de novos processos
adequados à outros projetos.
2.2 Definição de Geradores de Artefatos
Geradores de artefatos têm como finalidade acelerar o processo de
implementação no desenvolvimento de softwares, pois ajudam automatizar
parte de um processo rotineiro para um determinado domínio, traduzindo
especificações de uma linguagem de programação de alto nível para uma
linguagem de baixo nível, validando essas especificações e transformando-as
automaticamente em artefatos de software da aplicação (PAZIN, 2004).
Geradores de artefatos podem ter diferentes significados, podendo ser
considerados como compiladores, wizards e gerador de códigos (JUNIOR,
2006).
A utilização de um gerador de artefatos pode trazer benefícios como o
aumento de produtividade, redução do tempo para desenvolvimento de um
48
novo produto, prototipação e qualidade no produto gerado (PAZIN, 2004). Um
gerador de artefatos tem como finalidade realizar as seguintes funções
(JUNIOR, 2006):
a) realiza a validação da especificação de entrada e relata erros ou
avisos de inconsistências;
b) completa a especificação utilizando as configurações padrão, caso
seja necessário;
c) realiza otimização;
d) gera implementação.
Um artefato é um produto qualquer criado como parte da definição,
manutenção ou utilização de um processo de software (PAZIN, 2004). Dentre
os artefatos incluem descrições de processos, especificações, componentes,
códigos, aplicação, documentação para o usuário, etc. (ARTEFATO, 2010). Por
essa definição, todos os produtos criados por um gerador, desde scripts do
banco de dados à aplicação final são considerados artefatos (PAZIN, 2004).
Assim sendo, os geradores de artefatos ajudam uma organização a
construir múltiplos produtos de uma família com mais facilidades do que pelo
modo de implementação tradicional (PAZIN, 2004). Além dos códigos, os
geradores podem produzir documentação do usuário e do software, casos de
teste, diagramas e figuras, porém, um dos problemas dos geradores de
aplicação é o seu alto custo de desenvolvimento e manutenção (JUNIOR,
2006).
2.3 Definição de Templates
Template (Gabarito) é um documento sem conteúdo, é um modelo de
página que contém conjuntos de instruções de formatação visual, e instruções
sobre onde e qual tipo de conteúdo deve ser inserido a cada elemento da
apresentação do modelo (TEMPLATE, 2010).
Os templates são estruturas pré-existentes de código que são utilizadas
para definir os produtos que se deseja gerar por meio de um gerador de
aplicação ou artefatos (PAZIN, 2004). Esses templates possuem partes fixas,
49
que estão presentes em todos os artefatos gerados, e partes variáveis que
permitem a criação de diferentes artefatos de software utilizando o mesmo
template (PAZIN, 2004).
Template é uma régua ou gabarito de símbolos muito usado no
preparo de fluxogramas e organogramas. Nos programas aplicativos,
um documento ou planilha que contém os textos ou as formulas
necessárias a algumas aplicações genéricas, e que fica
permanentemente disponível ao usuário para que seja adaptado às
necessidades de cada situação (SAWAYA, 2005, p. 465).
De modo geral templates são modelos que servem de matriz para a
produção em escala de um produto ou serviço, possuem conjuntos de
configuração padrão de acordo com que as novas páginas vão sendo criadas,
são utilizados para a produção massiva de conteúdo e documentos e para
separar o conteúdo da apresentação, conteúdo de texto e web design e layouts
da página (TEMPLATE, 2010). A utilização de templates permite a redução de
custos e de prazos de produção, pelo fato de servir como referência para a
criação de novos arquivos e diminuir casos de soluções isoladas (AVELLAR E
DUARTE, 2010).
50
3 LEVANTAMENTO DE REQUISITOS
O levantamento de requisitos é o estudo das características que o
sistema deverá ter para atender às necessidades e expectativas do cliente
(BEZERRA, 2007). Define as informações necessárias para a modelagem e
especificação do software, corresponde à etapa de compreensão do problema
aplicado ao desenvolvimento do software (BEZERRA, 2007).
É a etapa inicial do desenvolvimento de software, mostra as
funcionalidades do sistema que será desenvolvido, descreve a forma como
será feito e não a forma como será implementado, é o processo de aquisição,
refinamento e verificação das necessidades do sistema, e compreende as
necessidades dos usuários (BEZERRA, 2007).
A fase de concepção deve fornecer a visão do todo para poder ver o
que é mais importante e depois dividir o todo em partes para analisar
os detalhes. Na fase de concepção a análise de requisitos é rápida e
genérica. O analista deve entender a extensão do que o sistema deve
fazer, mas sem detalhar como vai fazer (WAZLAWICK, 2004, p. 33).
O objetivo do levantamento de requisitos é sistematizar o processo de
definição dos requisitos, obtendo uma especificação correta e completa do
mesmo para elaboração do Documento de Requisitos (WAZLAWICK, 2004). O
documento de requisitos declara os diversos tipos de requisitos do sistema,
normalmente é escrito em uma linguagem natural para o usuário entendê-lo
(BEZERRA, 2007).
3.1 Análise de Mercado
A análise de mercado foi realizada com o intuito de comparar os
sistemas geradores de aplicação e suas principais funcionalidades.
a) GAwCRe: é um gerador de aplicações baseado na web para domínio
de sistemas de clínicas de reabilitação, realiza a instanciação de
aplicações utilizando uma linguagem de modelagem da aplicação
(LMA) que deve representar os modelos das aplicações, é definida
com base na linguagem de padrões para Sistemas de Gestão de
Clínicas (SiGCli), as informações são representadas por um meta-
51
modelo utilizando a linguagem XML, assim apresenta as informações
na interface de instanciação da aplicação, que são criadas
dinamicamente (PAZIN, 2004). A Figura 19 representa a interface de
instanciação do sistema para clínica de fisioterapia (ClinicaFisio) que
será gerado pelo GAwCRe, essa tela define o código, o nome da
aplicação e o diretório da aplicação, e a Figura 20 ilustra a tela
gerada para cadastro de guias de convênios médicos dos pacientes.
Fonte: Pazin, 2004, p. 104
Figura 19. Interface de Definição de uma Aplicação – GawCRe.
Fonte: Pazin, 2004, p. 105
Figura 20. Cadastro de Guias de Convênios de Pacientes – GawCRe.
52
b) GAS 2007: é um software que gera sofisticadas aplicações para
manipulação com banco de dados e com interface simplificada,
contém um conjunto de funções e recursos que podem ser
compilados e utilizados sem necessitar de esforços de programação.
É uma aplicação voltada para desenvolvedores e para usuários
finais, sua utilização proporciona agilidade de produtividade,
padronização
e
redução
de
custos
em
desenvolvimento
e
manutenção de aplicações. Possui recursos para desenvolvimento
de aplicações com alto grau de complexidade e alto nível, consolida
a combinação entre desempenho e funcionalidade, tem eficiência,
rapidez e as necessidades de aplicações de banco de dados (GAS
TECNOLOGIA, 2009). A Figura 21 exibe uma tela de um sistema de
controle de estoque gerado pelo GAS 2007.
Fonte: GAS Tecnologia, 2009.
Figura 21. Interface de Controle de Estoque de Produtos - GAS 2007.
c) Draco-PUC: é uma implementação parcial do paradigma Draco no
desenvolvimento de software, é um projeto que investiga a
construção de softwares baseado na reutilização de abstrações de
alto nível escritas em linguagens de domínio. A máquina Draco
53
possui tecnologias que permitem a construção e utilização de
domínios, estes são classificados em domínios de aplicação,
modelagem e executáveis. Um aspecto importante do paradigma
Draco é a distinção entre transformações horizontais e verticais. Esse
software produz semi-automaticamente um programa executável, a
aplicação é definida como um programa Draco e então é traduzida
para um programa executável (PUC-RIO, 2009). A Figura 22
representa o funcionamento de um domínio do sistema Draco.
Fonte: PUC-RIO, 2009.
Figura 22. Funcionamento de um Domínio do Sistema - DRACO-PUC.
d) Gerador de Aplicações Configurável Captor: é um software gerado
para ser um gerador configurável por linguagens de padrões e
linguagens de modelagem, pode ser configurado para vários
domínios e fornece apoio no desenvolvimento de aplicações em um
mesmo domínio. A configuração da aplicação é realizada por
especificações em formulários ou pela criação de linguagens de
modelagem baseadas em formulários, representando assim os
elementos gráficos das interfaces. O Captor oferece apoio na criação
de gabaritos com zona de segurança pré e pós processamento dos
artefatos
gerados,
mecanismos
de
depuração
de
erros
na
especificação. Para a utilização do Captor, deve ser criado um
54
projeto representando o conjunto de arquivos com as informações do
domínio, assim o captor poderá realizar o gerenciamento dos
projetos, ou seja, criação, salvamento, fechamento, abertura e
remoção (JUNIOR, 2006). A Figura 23 ilustra a utilização do Captor
para a geração de um arquivo de configuração e a Figura 24 ilustra o
Captor sendo utilizado para armazenar o modelo de uma aplicação.
Fonte: Junior, 2006, p. 78
Figura 23. Interface de Geração de Arquivo de Configuração - Captor.
Fonte: Junior, 2006, p. 105
Figura 24. Interface de Armazenamento do Modelo da Aplicação - Captor.
55
3.2 Documentos de Requisitos
Visão Geral do Sistema
O Gerador de Artefatos de Software para Aplicações Web deve, a partir
das tabelas existentes em um banco de dados de um sistema completo, criar
as classes Java Beans da aplicação, as classes Java DAO para manipulação
dos dados armazenados em um banco de dados; os controladores da
aplicação (Servlet), os scripts SQL de criação e manipulação do banco de
dados e as interfaces HTML e JSP para a aplicação. O objetivo principal desse
gerador é diminuir as tarefas repetitivas de copiar, colar e alterar, existentes
durante o processo de desenvolvimento de software.
Requisitos Funcionais
a) O gerador deve ser capaz de permitir ao desenvolvedor acessar os
esquemas cadastrados em seu banco de dados por url, nome de usuário e
senha que são inseridos no código fonte do gerador;
b) O gerador deve ser capaz de permitir ao desenvolvedor escolher o
esquema de banco de dados que se pretende gerar o novo artefato;
c) Um esquema pode possuir uma ou mais tabelas;
d) O gerador deve ser capaz de identificar individualmente cada tabela com os
seus respectivos atributos, chaves primárias e chaves estrangeiras exibindo
essas informações ao usuário desenvolvedor;
e) O gerador deverá ter módulos distintos para a criação de artefatos de
software que são:
i. scripts no padrão SQL DDL (script de criação de tabelas);
ii. scripts no padrão SQL DML (scripts para a manipulação dos dados
das tabelas);
iii. as classes JavaBeans;
iv. as classes JavaDAO;
v. os controladores da aplicação (Servlets Java);
vi. as interfaces HTML/JSP.
56
f) Todos os artefatos gerados através dos templates devem ser criados em
arquivos distintos no Sistema Operacional.
Requisitos Não Funcionais
a) O gerador deve utilizar a plataforma web, sem a necessidade de ser
instalado na máquina do cliente;
b) O banco de dados utilizado pelo gerador de artefatos será o Oracle.
57
4 ANÁLISE ORIENTADA A OBJETOS
4.1 Diagrama de Classes – Completo
Fonte: Elaborado pelos Autores, 2009.
Figura 25. Diagrama de Classes e Objetos.
4.2 Justificativa para Implementação
No presente trabalho são implementados apenas as funções de criação
dos artefatos SQL, Bean e HTML. As demais funcionalidades de criação do
58
gerador como: gerarDML, gerarServlets, gerarWebXML, gerarDAO, gerarJSP,
gerarJS, gerarCSS e gerarAjax podem ser implementadas em trabalhos
futuros.
4.3 Lista de Casos de Uso
Objetivo
Gerar Artefatos:
a) Permitir acesso ao gerador por conexão no banco de dados
b) Selecionar o esquema do banco
c) Selecionar tabelas do esquema escolhido
d) Gerar artefatos
e) Exibir artefatos gerados
Descrição
Evento
Use Case
Resposta
Usuário solicita gerar
artefato e realizar conexão
com o banco de dados, em
seguida informa os dados
para a criação do artefato,
escolhe o esquema
desejado, seleciona tabela,
escolhe o tipo de artefato a
ser gerado e gera o artefato.
dadosArtefato
gerarArtefato
MSG
exibirArtefato
Fonte: Elaborado pelos autores, 2009.
Quadro 2. Lista de Use Case.
4.4 Diagrama de Casos de Uso
O diagrama de caso de uso deste gerador de artefatos representa as
seguintes ações:
a) conexão com Banco de Dados;
b) seleção de Esquema;
c) seleção de Tabelas;
d) gerar Artefatos.
59
Fonte: Elaborado pelos Autores, 2009.
Figura 26. Diagrama de Use Case – Gerar Artefatos.
Use Case: Gerar Artefato
Ator: Usuário
Descrição: Este use case é referente à geração dos artefatos SQL, Bean
e/ou HTML.
Curso Normal:
1. Usuário deseja utilizar gerador e gerador se conecta ao banco de dados
do usuário.
2. Após efetuar a conexão, o gerador exibe os esquemas cadastrados no
banco de dados e o usuário escolhe o esquema que deseja utilizar.
3. O sistema exibe para o usuário as tabelas existentes no esquema
escolhido.
4. Em seguida o usuário deverá selecionar qual a tabela do esquema ele
deseja gerar os respectivos artefatos.
5. Depois de escolher a tabela o usuário deverá informar qual tipo de
artefato ele deseja gerar: SQL, Bean e/ou HTML.
6. O gerador verifica todas as informações selecionadas pelo usuário e
gera os artefatos em arquivos distintos.
7. O sistema emite uma mensagem de confirmação de criação dos
artefatos, e exibe os artefatos gerados (MSG exibirArtefato).
Curso Alternativo:
6.1 – Caso não consiga gerar o artefato com os dados selecionados, o
gerador apresenta uma mensagem de erro.
6.2 – Caso ocorra algum erro durante a geração de um artefato o
gerador reinicia o processo de geração.
Fonte: Elaborado pelos Autores, 2009.
Quadro 3. Caso de Uso – Gerar Artefatos.
60
4.5 Diagrama de Classes a ser Implementado
Fonte: Elaborado pelos Autores, 2009.
Figura 27. Diagrama de Classes a ser implementado.
61
5 PROJETO DE BANCO DE DADOS
O gerador de artefatos não possui um sistema de banco de dados
próprio, ele utiliza o banco de dados do usuário para a realização de suas
funcionalidades, isso permite que o gerador se adéque as características do
banco de dados dos diversos usuários possíveis para sua utilização e geração
dos artefatos. O gerador cria seus artefatos de acordo com os esquemas
disponíveis no banco de dados do usuário, sendo que o banco de dados já
possui seus esquemas próprios e outros esquemas podem ser adicionados,
alterados ou excluídos. Para estudo de caso das funcionalidades do gerador de
artefatos foram cadastrados três esquemas no banco de dados: Oficina
Eletrônica, Help Desk e Venda Web. O sistema de Oficina Eletrônica descrito
abaixo foi um dos esquemas utilizados para estudo de caso do gerador de
artefatos, esse esquema demonstra as funcionalidades e utilização da
ferramenta.
5.1 Descrição do Sistema de Oficina Eletrônica
A Oficina Eletrônica Apolo efetua consertos em eletrônicos de diversos
tipos, como televisores, DVD, fornos de microondas, etc. Possui técnicos
eletrônicos que recebem comissão referente aos consertos efetuados. O
aparelho chega, é cadastrado, juntamente como o proprietário, e atribuído a um
técnico. O cliente recebe um comprovante de entrada do aparelho. Quando o
técnico termina o serviço, preenche os serviços executados e peças trocadas e
avisa-se o cliente para vir buscar o aparelho. O pagamento é somente à vista
(dinheiro ou cheque). Semanalmente deve ser impresso relatório contendo
todos os aparelhos que ainda não foram consertados. Os técnicos recebem
percentuais de comissão sobre o serviço de mão-de-obra executado, conforme
acordo com o proprietário da oficina. Pode haver diferenciação entre os
percentuais dos diversos funcionários, conforme a experiência e especialidade
de cada um. Além disso, possuem um salário fixo mensal. O sistema deve
emitir um relatório quinzenal dos serviços realizados por cada funcionário,
juntamente com o subtotal que eles devem receber de comissão.
62
Fonte: Elaborado pelos Autores, 2010.
Figura 28. Diagrama de Classes para a Oficina Eletrônica.
5.2 Tabelas
Tabela: Conserto de Aparelho
Chave-Primária (PK): código
Chave-Estrangeira (FK): codigoCliente (Cliente.codigo), numeroAparelho
(Aparelho.numero)
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
Numero
6
Não
data entrada
Data
8
Não
data saída
Data
8
Sim
defeitos apresentados
Texto
50
Não
peças trocas
Texto
50
Sim
serviços executados
Texto
50
Sim
codigoCliente
Numero
6
Não
numeroAparelho
Numero
6
Não
codigo
Fonte: Elaborado pelos Autores, 2010.
Quadro 4. Estrutura da Tabela Conserto de Aparelho.
63
Tabela: Execução de Conserto
Chave-Primária (PK): codigoConserto
Chave-Estrangeira (FK): codigoTecnico (Tecnico.codigo), numrroAparelho
(Aparelho.numero)
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
Numero
6
Não
Texto
50
Não
códigoTecnico
Numero
6
Não
numeroAparelho
Numero
6
Não
codigoConserto
descrição
Fonte: Elaborado pelos Autores, 2010.
Quadro 5. Estrutura da Tabela Execução de Conserto.
Tabela: Cliente
Chave-Primária (PK): código
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
código
Numero
6
Não
nome
Texto
30
Não
endereço
Texto
45
Não
telefone
Texto
12
Não
email
Texto
40
Não
cidade
Texto
25
Não
Fonte: Elaborado pelos Autores, 2010.
Quadro 6. Estrutura da Tabela Cliente.
Tabela: Aparelho
Chave-Primária (PK): numero
Chave-Estrangeira (FK): codigoTipoAparelho (TipoAparelho.codigo)
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
numero
Numero
6
Não
modelo
Texto
15
Não
situação
Texto
50
Não
fabricante
Texto
25
Não
Numero
6
Não
códigoTipoAparelho
Fonte: Elaborado pelos Autores, 2010.
Quadro 7. Estrutura da Tabela Aparelho.
64
Tabela: Tipo de Aparelho
Chave-Primária (PK): código
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
Numero
6
Não
Texto
50
Não
Tipo de Dado
Tamanho
Permite Nulo?
código
Numero
6
Não
nome
Texto
30
Não
percentualComissão
Numero
5,2
Sim
salário
Numero
10
Não
Texto
15
Não
código
descrição
Fonte: Elaborado pelos Autores, 2010.
Quadro 8. Estrutura da Tabela Tipo de Aparelho.
Tabela: Técnico
Chave-Primária (PK): código
Nome do Campo
especialidade
Fonte: Elaborado pelos Autores, 2010.
Quadro 9. Estrutura da Tabela Técnico.
Outras Regras de Validação de Campo:
Nome do Campo:
Restrição:
salário
Valor tem que ser maior que 0
percentualComissão
Valor tem que ser maior que 0
Fonte: Elaborado pelos Autores, 2010.
Quadro 10. Regras de Validação da Tabela de Técnico.
Tabela: Comissão
Chave-Primária (PK): código
Chave-Estrangeira (FK): codigoTecnico (Tecnico.codigo)
Nome do Campo
Tipo de Dado
Tamanho
Permite Nulo?
códigoComissao
Numero
6
Não
data pagamento
Data
8
Sim
valor
Numero
10
Sim
códigoTécnico
Numero
6
Não
Fonte: Elaborado pelos Autores, 2010.
Quadro 11. Estrutura da Tabela Comissão.
65
Outras Regras de Validação de Campo:
Nome do Campo:
Restrição:
valor
Valor tem que ser maior que 0
Fonte: Elaborado pelos Autores, 2010.
Quadro 12. Regras de Validação da Tabela Comissão.
66
6 PROJETO ORIENTADO A OBJETOS
6.1 Diagrama de Sequência
Fonte: Elaborado pelos Autores, 2010.
Figura 29. Diagrama de Sequência – Gerar Artefato.
67
7 IMPLEMENTAÇÃO DO GERADOR DE ARTEFATOS
Para melhor entender o gerador de artefatos proposto e suas
funcionalidades, é necessário entender seu fluxo de execução durante sua
utilização e criação dos artefatos através da utilização de templates.
O processo utilizado para a definição dos templates do gerador foi
seguindo os padrões dos scripts SQL, das classes Beans e das páginas HMTL.
Esses templates foram elaborados através da análise de modelos de artefatos
já existentes.
Fonte: Elaborado pelos Autores, 2010.
Figura 30. Utilização de templates durante a geração dos artefatos.
A Figura 30 ilustra a utilização do gerador no momento em que o usuário
for solicitar a geração do artefato, o gerador deve processar um conjunto de
especificações que são definidas em seu código fonte, utilizando seus
templates para transformá-los no artefato final. O gerador processa essas
especificações e as informações fornecidas a ele pelo usuário e cria os
artefatos SQL, Bean e/ou HTML da aplicação de acordo com as definições
estabelecidas em seus templates.
Analisando os artefatos foram identificadas em seu modelo partes fixas e
variáveis. Para que o gerador possa criar os artefatos às partes fixas são
previamente definidas em seu código fonte e as partes variáveis são
substituídas pelas informações que são fornecidas ao gerador pelo usuário
através da utilização de esquemas do banco de dados.
68
A Figura 31 apresenta um artefato que é um script de criação de tabela
utilizando SQL, sendo que os itens em negrito representam as partes fixas do
template. A Figura 32 apresenta o template definindo esses scripts, sendo que
as partes fixas estão definidas de acordo com a identificação na Figura 31 e as
partes variáveis são colocadas entre tags.
CREATE TABLE OFICINA.CLIENTES (
CODIGO NUMBER (6),
NOME VARCHAR2 (40),
ENDERECO VARCHAR2 (45),
TELEFONE VARCHAR2 (12),
EMAIL VARCHAR2 (40),
CIDADE VARCHAR2 (45)
);
Fonte: Elaborado pelos Autores, 2010.
Figura 31. Conjunto de scripts de criação de tabelas utilizando SQL.
CREATE TABLE <ESQUEMA>.<NOME_TABELA> (
<ATRIBUTO> <TIPO> (<TAMANHO>)
);
Fonte: Elaborado pelos Autores, 2010.
Figura 32. Template definido para scripts de criação das tabelas SQL.
Todos os artefatos produzidos pelo gerador (SQL, Bean e HTML)
passaram pela mesma forma de identificação das partes variáveis e fixas,
definindo-se os templates para cada artefato desejado. Após a definição dos
templates, eles foram embutidos no código da classe Java responsável pela
geração dos artefatos no gerador.
A Figura 33 exibe o código Java do template da construção dos artefatos
de scripts SQL, onde a classe executa um comando SQL de seleção utilizando
o nome do esquema e nome da tabela selecionada pelo usuário, para obter os
dados da tabela desejada. Os atributos das tabelas para serem utilizados pelo
template do gerador são armazenados em uma lista de objetos, com seus
nomes, tipos e tamanhos, pois esses atributos são recuperados através de um
laço e são chamados através de variáveis encaixadas no código do template
formando o artefato completo.
69
//template para gerar o script SQL da tabela escolhida
public void getScriptSQL(String tabela, String esquema) throws
IOException{
FileWriter saida = null;
try {
File dir = new
File("c:/"+padrao.fCase(esquema)+"."+padrao.fCase(tabela));
if (!dir.exists()){
dir.mkdir();
}
File arquivo = new File(dir,padrao.fCase(tabela)+ "(sql).sql");
// criando file se ele não existir file.createNewFile();
conexao = ConexaoDB.getInstance().getConnection();
statement = conexao.createStatement(ResultSet.TYPE_SCROLL_
INSENSITIVE, ResultSet.CONCUR_READ_ONLY );
resultados = statement.executeQuery("select * from
"+esquema+"."+tabela);
metaTabela = resultados.getMetaData();
String virgula="";
saida = new FileWriter(arquivo,true);
saida.write("\nCREATE TABLE "+esquema+"."+tabela +" (");
for(int i=1; i <=metaTabela.getColumnCount(); i++){
saida.write(virgula+"\n\t"+metaTabela.getColumnName(i) + " " +
metaTabela.getColumnTypeName(i) + "(" +
metaTabela.getColumnDisplaySize(i)+ ")");
virgula=",";
}
saida.write(");");
saida.close();
statement.close();
} catch (IOException e) {
System.out.print(e.getMessage());
} catch (SQLException excecao){
JOptionPane.showMessageDialog( null,
excecao.getMessage(),"Erro de SQL",
JOptionPane.ERROR_MESSAGE );
} catch (Exception e) {
System.out.print(e.getMessage());
} finally {
try {
if (resultados != null)
resultados.close();
if (statement != null)
statement.close();
} catch (SQLException e) {
JOptionPane.showMessageDialog( null,
e.getMessage(),"Erro de SQL",
JOptionPane.ERROR_MESSAGE );
}
}
}
Fonte: Elaborado pelos Autores, 2010.
Figura 33. Template para construção de scripts de tabelas SQL.
A Figura 34 ilustra o esquema completo de funcionamento do gerador de
artefatos e os artefatos SQL, Bean e HTML gerados por ele.
70
...
Templates modelo = new Templates();
AtributosDAO obj = new AtributosDAO();
modelo.getScriptSQL(tabela, esquema);
modelo.getScriptHTML(obj.getAtribut
os
ObjAtributo(esquema,
tabela),
esquema, tabela);
modelo.getScriptBean(obj.getAtribut
osObjAtributo(esquema,
tabela),
esquema, tabela);
response.getWriter().close();
...
CREATE TABLE
OFICINA.TIPOAPARELHO (
CODIGO NUMBER(22),
DESCRICAO VARCHAR2(50)
);
Script SQL de criação da tabela
public class TipoAparelho {
Gerador de
scripts SQL
Lê as definições
Java para geração
dos artefatos
private int codigo;
private String descricao;
public TipoAparelho(){}
public int getCodigo(){
return codigo;
}
Gerador AlphaWEB
public void setCodigo(int codigo){
this.codigo = codigo;
}
Gerador de
classes Beans
public String getDescricao(){
return descricao;
}
Templates
Recupera dados das
especificações do
Gerador
public void setDescricao(String
descricao){
this.descricao = descricao;
}
}
Gerador de
interfaces HTML
Classe Bean
Base de Dados
do Gerador
Interface HTML
Fonte: Elaborado pelos Autores, 2010.
Figura 34. Funcionamento do gerador e os artefatos por ele gerados.
O gerador cria seus artefatos em arquivos distintos do sistema
operacional do usuário e esses artefatos são gerados em um diretório padrão
71
que está definido no código fonte da aplicação. Após a geração do artefato o
usuário poderá alterar seu conteúdo de acordo com suas necessidades e de
sua aplicação que está sendo desenvolvida.
7.1 Layout de Telas
Nesta seção são apresentadas as telas que compõem o layout do
sistema e uma explicação sobre suas funcionalidades.
6.2.1 Tela Inicial do Sistema
A Figura 35 representa a tela inicial do sistema, sendo possível a
visualização dos ícones e do menu de navegação.
Fonte: Elaborado pelos Autores, 2010.
Figura 35. Tela Inicial do Gerador.
6.2.2 Tela de Gerar Artefatos
A Figura 36 apresenta a interface de geração dos artefatos. O usuário
para gerar o artefato, deverá informar os dados do respectivo artefato que
deseja criar, primeiro ele deve selecionar na lista de esquemas o esquema do
72
banco de dados, em seguida deverá informar qual a tabela com seus atributos
que deseja gerar o artefato, e por fim deve escolher qual tipo de artefato ele
deseja gerar, sendo eles três tipos: SQL, Java Bean e HTML. O usuário poderá
gerar quantos artefatos for necessário para sua aplicação, sendo que ele
poderá utilizar um esquema e tabela por vez. O sistema cria os artefatos com
todos atributos cadastrados nas tabelas dos esquemas, e após a criação do
artefato o usuário poderá deletar os atributos que não lhe são úteis e até
mesmo adicionar ou alterar algum atributo da tabela. Os artefatos serão criados
em uma pasta no diretório que estiver definido no código fonte da aplicação.
Fonte: Elaborado pelos Autores, 2010.
Figura 36. Tela de Gerar Artefatos.
7.2 Artefatos Gerados
Nesta seção são apresentados os artefatos gerados pelo AlphaWEB. Os
artefatos são gerados de acordo com os templates definidos no gerador, esses
artefatos são criados através da utilização do esquema de estudo de caso da
Oficina Eletrônica. Os artefatos SQL, Bean e HTML gerados são referentes à
tabela de Comissão e todos seus atributos.
73
Os demais artefatos gerados pelo AlphaWEB referentes aos esquemas
de estudo de caso de Help Desk e Venda Web não são apresentados pois têm
a mesma estrutura dos artefatos apresentados, mudando apenas seu conteúdo
variável de acordo com o template.
CREATE TABLE OFICINA.COMISSAO (
CODIGO NUMBER(22),
DATAPAGAMENTO DATE(7),
VALOR NUMBER(22)
);
Fonte: Elaborado pelos Autores, 2010.
Figura 37. Artefato de scripts SQL da Tabela Comissão.
public class Comissao {
private int codigo;
private DATE datapagamento;
private int valor;
public Comissao(){}
public int getCodigo(){
return codigo;
}
public void setCodigo(int codigo){
this.codigo = codigo;
}
public DATE getDatapagamento(){
return datapagamento;
}
public void setDatapagamento(DATE datapagamento){
this.datapagamento = datapagamento;
}
public int getValor(){
return valor;
}
public void setValor(int valor){
this.valor = valor;
}
}
Fonte: Elaborado pelos Autores, 2010.
Figura 38. Artefato Bean da Tabela Comissão.
74
<html>
<head>
<title> Página HTML da Tabela Comissao </title>
</head>
<body>
<form id="idComissao">
codigo: <input type="text" id="codigo" /><br/>
datapagamento: <input type="text" id=
"datapagamento" /><br/>
valor: <input type="text" id="valor" />
<br/><br/>
<input type="button" value="Salvar" />
<input type="button" value="Limpar" />
</form>
</body>
</html>
Scripts HMTL e Interface
Fonte: Elaborado pelos Autores, 2010.
Figura 39. Artefato HTML da Tabela Comissão.
75
CONCLUSÃO
A proposta deste trabalho é desenvolver um gerador de artefatos para
aplicações, tendo como principal objetivo automatizar e acelerar o processo de
desenvolvimento de software, oferecendo aos desenvolvedores benefícios
como o ganho de produtividade e diminuição das atividades repetitivas durante
o desenvolvimento ou atualização de uma nova versão de uma aplicação. Com
a pesquisa realizada, foi possível compreender as funcionalidades e utilização
de um gerador de artefatos.
O gerador de artefatos AlphaWEB, apresentado neste trabalho, gera
artefatos em arquivos distintos no sistema operacional, de acordo com os
templates (especificações) que são definidos no código fonte. Os artefatos
criados podem ser utilizados por aplicações de plataforma web ou desktop.
O gerador desenvolvido trabalha na plataforma web através de um
browser (navegador) de internet, sem precisar ser instalado na máquina do
usuário. O gerador realiza uma análise da estrutura de banco de dados e utiliza
o resultado dessa análise para formatar os arquivos SQL, Beans, DAO e
HTML/JSP. Inicialmente o gerador funciona apenas para o banco de dados
Oracle.
O AlphaWEB não teve todas as suas funcionalidades implementadas,
sendo assim, as demais funcionalidade poderão ser desenvolvidas em
trabalhos futuros. O objetivo que se pretendia alcançar com esse trabalho era o
de gerar alguns artefatos para uma aplicação.
Como proposta para trabalhos futuros, o gerador poderá receber
atualizações de sua recente versão, tendo como objetivo adaptar o sistema às
necessidades
dos
usuários.
As
seguintes
atualizações
poderão
ser
implementadas no gerador a fim de melhorar a forma de criação dos artefatos,
permitindo a criação de mais tipos de artefatos como:
a) criação da documentação da aplicação e dos artefatos gerados;
b) permissão ao usuário para adicionar, alterar ou remover atributos dos
artefatos sempre que necessário;
c) realização das alterações necessárias para o gerador funcionar com
outros bancos de dados;
76
d) implementar ao gerador as funcionalidades para gerar outros
artefatos para as aplicações como: gerar os scripts DML para
manipulação dos dados das tabelas, gerar as classes Java DAO para
manipulação da aplicação com banco de dados, gerar os Servlets e o
web.xml, os controladores da aplicação, gerar as páginas JSP de
interação com o usuário, gerar as funções de Ajax e JS (Java Script)
e os modelos de formatação CSS para as páginas HTML e JSP.
Com o desenvolvimento desse sistema, concluiu-se que a utilização de
um gerador de artefatos pode auxiliar durante o desenvolvimento de uma
aplicação de software, pois o sistema pode ser utilizado por qualquer tipo de
desenvolvedor que tenha como objetivo desenvolver uma aplicação em menor
tempo, mas com maior produtividade e qualidade, já que os artefatos gerados
já foram previamente testados em outras aplicações.
77
REFERÊNCIAS
APACHE. Javax.sql: Extensões JDBC, Brasil, [s.d.]. Disponível em:
<http://db.apache.org/derby/docs/dev/pt_BR/ref/rrefjta18596.html>. Acesso em:
12 fev. 2010.
APACHE TOMCAT. Apache Tomcat, Brasil, 03 fev. 2010. Disponível em:
<http://pt.wikipedia.org/wiki/Apache_Tomcat)>. Acesso em: 07 fev. 2010.
API.
API,
Brasil,
30
ago.
2009.
Disponível
<http://pt.wikipedia.org/wiki/API)>. Acesso em: 31 ago. 2009.
em:
ARTEFATO. Artefato: Desenvolvimento de Software, Brasil, 16 mai. 2010.
Disponível em: < http://pt.wikipedia.org/wiki/Artefato>. Acesso em: 01 jun. 2010.
AVELLAR E DUARTE. Glossario: Template, Brasil, [s.d.]. Disponível em:
<http://www.avellareduarte.com.br/glossario/glossario.htm>. Acesso em: 12
mai. 2010.
BEZERRA, E. Princípios de Análise e Projetos de Sistemas com UML. 2.ed.
Rio de Janeiro: Campus, 2007.
BODOFF, S.; et al. Tutorial do J2EE. Tradução Cláudio Rodrigues Pistilli Rio
Janeiro: Editora Ciência Moderna, 2005.
CLEAVELAND, J. C. Program generators with XML and Java. Prentice Hall,
2001.
CRANE, D; PASCARELLO, E; JAMES, D. Ajax em Ação, São Paulo: Pearson
Prentice Hall, 2007.
CZARNECKI, K.; EISENERCKER. U.W. Generative Programming: Methods,
Tools, and Applications. Ed. Addison-Wesley, 2000.
DATE, C. J. Introdução a Sistemas de Banco de Dados. 8. ed. Rio de
Janeiro: Campus/Elsevier, 2004.
DEITEL, H.M.; DEITEL, P.J. Java: como programar. 6. ed. São Paulo: Pearson
Prentice Hall, 2005.
DEITEL, H.M.; DEITEL, P.J. Ajax, Rich Internet Applications e
desenvolvimento Web para programadores. São Paulo: Pearson Prentice
Hall, 2008.
ELMASRI, R; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. São
Paulo: Pearson Addison Wesley, 2005.
FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de
modelagem de objetos. 3. ed. Porto Alegre: Bookman, 2005.
78
GAS Tecnologia. GAS2007 - Gerador Automático de Sistemas. Brasil, [s.d.].
Disponível em: <http://www.gastecnologia.com.br/site/pt/GAS.aspx>. Acesso
em: 10 nov. 2009.
GONÇALVES, E. Desenvolvendo Aplicações Web com JSP, Servlets,
JavaServer Faces, Hibernate, EJB 3 Persistence e Ajax. Rio de Janeiro:
Ciência Moderna, 2007.
GONÇALVES, E. Dominando Ajax: as melhores práticas ligadas a aplicações
Web escritas em Java como em PHP 5 utilizando Ajax. Rio de Janeiro: Ciência
Moderna, 2006.
JAVA
FREE.
RowSet,
Brasil,
[s.d.].
Disponível
<http://javafree.uol.com.br/index.jf>. Acesso em: 08 fev. 2010.
em:
JAVA. Java: Linguagem de Programação, Brasil, 19 ago. 2009. Disponível em:
<http://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3
o)>. Acesso em: 28 ago. 2009.
JAVA. Saiba mais sobre a tecnologia Java, Brasil, [s.d.]. Disponível em:
<http://www.java.com/pt_BR/about/>. Acesso em: 26 ago. 2009.
JDBC.
JDBC,
Brasil,
15
set.
2009.
Disponível
http://pt.wikipedia.org/wiki/JDBC)>. Acesso em: 02 out. 2009.
em:
<
JUNIOR, E. K. S. Um de Gerador de Aplicações Configurável. 2006.
Dissertação (Mestrado em Ciências de Computação e Matemática
Computacional) – Instituto de Ciências Matemáticas e de Computação, USP de
São Carlos, São Paulo.
MACORATTI, J. C. O Processo de Software, Brasil, [s.d.]. Disponível em: <
http://www.macoratti.net/proc_sw1.htm>. Acesso em: 06 jun. 2010.
MARCANDALI, A. Analisando metadados com JDBC. GUJ, [s.l.], 11 nov. 2002.
Disponível em:<http://www.guj.com.br/article.show.logic?id=24> Acesso em: 22
out. 2009.
METADADOS. Metadados, Brasil, 12 out. 2009. Disponível
<http://pt.wikipedia.org/wiki/Metadados)>. Acesso em: 22 out. 2009.
em:
MUKHI, V.; MUKHI, S.; KOTECHA, N. Java Servlets JSP. São Paulo: Makron
Books, 2002.
ORACLE. A história do Oracle: Inovação, Liderança e Resultados, Brasil,
[s.d.]. Disponível em: <http://www.oracle.com/global/br/corporate/story.html>.
Acesso em: 20 out. 2009.
ORACLE.
ORACLE,
Brasil,
08
out.
2009.
Disponível
<http://pt.wikipedia.org/wiki/Oracle>. Acesso em: 12 out. 2009.
em:
79
OLSON, S. D. Ajax com Java: Os fundamentos da programação de
XMLHttpRequest e de XML com Java, Rio de Janeiro: Alta Books, 2007.
PAZIN, A. GAwCRe: Um de Gerador de Aplicações baseadas na Web para
o Domínio de Gestão de Clínicas de Reabilitação. 2004. Dissertação (PósGraduação em Ciência da Computação) – Centro de Ciências Exatas e de
Tecnologia, Universidade Federal de São Carlos, São Paulo.
PENDER, T. UML: A Bíblia. Rio de Janeiro: Elsevier, 2004.
PUC-RIO.
Projeto
Draco-PUC,
Brasil,
[s.d.].
Disponível
<http://www.inf.puc-rio.br/~draco/>. Acesso em: 11 nov. 2009.
em:
RAMALHO, J. A. Oracle 10g. São Paulo: Thonsom, 2005.
SAWAYA, M. R. Dicionário de Informática e Internet: inglês/português. 3. ed.
São Paulo: Nobel, 2005.
SERVLET.
Servlet,
Brasil,
31
ago.
2009.
Disponível
<http://pt.wikipedia.org/wiki/Servlet)>. Acesso em: 03 set. 2009.
em:
SUN. 1995: Começa a Grande Revolução da Tecnologia Java, Brasil, [s.d.].
Disponível em: <http://br.sun.com/aboutsun/historia.jsp>. Acesso em: 27 ago.
2009.
SUN MICROSYSTEMS. O que é o GlassFish, Brasil, [s.d.]. Disponível em:
<http://br.sun.com/practice/software/glassfish/index.jsp>. Acesso em: 07 fev.
2010.
TEMPLATE.
Template,
Brasil, 02 mar.
2010.
Disponível
<http://pt.wikipedia.org/wiki/Templates>. Acesso em: 10 mai. 2010.
em:
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação
Orientadas a Objetos. Rio de Janeiro: Elsevier, 2004.
WIKI SINTECTUS. Introdução ao JDBC, Brasil, [s.d]. Disponível em:
<http://wiki.sintectus.com/bin/view/GrupoJava/LicaoIntroducaoAoJDBC)>.
Acesso em: 08 fev. 2010.
80
GLOSSÁRIO
Termo
Descrição
As API’s contêm um conjunto de rotinas e padrões
estabelecidos por um software para a utilização de suas
API
funcionalidades por programas e aplicativos. Essas funções
são acessíveis somente por programação, permitindo
utilizar características do software menos evidentes ao
usuário tradicional (API, 2009).
Coleção de componentes organizada para realizar funções
Aplicação
interdependentes, visando apoiar atividades de um ou mais
usuários.
Qualquer item criado como parte da definição, manutenção
ou utilização de um processo de software. Inclui entre
descrições de processo, especificações, procedimentos,
Artefato
planos, código, projeto de arquitetura, projeto detalhado,
componente, módulo, aplicação, documentação para o
usuário. Artefatos podem ou não ser entregues a um cliente
ou usuário final.
É uma estrutura que abstrai um conjunto de objetos com
características similares ou iguais, define o comportamento
Classe
de seus objetos através de métodos e os estados possíveis
desses objetos através de atributos. Em outros termos uma
classe descreve os serviços providos por seus objetos e
quais informações ele podem armazenar.
DataSource é um parâmetro onde será especificado o
caminho lógico do banco de dados, representa dados em
DataSource
um banco de dados relacional do SQL para controles
ligados a dados, é utilizado para exibir, editar e classificar
dados em uma página da Web com pouco ou nenhum
código (APACHE, 2010).
81
Desktop (área de trabalho), é uma expressão utilizada para
computadores de mesa. Uma área de trabalho consiste de
um ambiente gráfico adequado ao usuário, onde ele possa
Desktop
abrir janelas de programas e efetuar operações básicas, há
ambientes gráficos que permitem o usuário ter mais de uma
área de trabalho permitindo a distribuição e organização
das janelas abertas.
Uma área de aplicação. São exemplos: pilhas, árvores,
Domínio
fluxo de caixa, planejamento e acompanhamento de
projetos, controle de um determinado processo químico,
gestão acadêmica, edição de diagramas, etc.
DriverManager é uma classe que cria e gerencia o
estabelecimento das conexões e faz gerenciamento dos
DriverManager
drivers JDBC, tem como responsabilidade manter uma lista
de
implementações
do
driver
e
apresentar
as
implementações a aplicação (WIKI SINTECTUS, 2010).
Qualquer solução incompleta que pode ser completada
Framework
através da instanciação e, desta forma, possibilitando a
geração de mais de uma aplicação dentro do domínio-alvo
do framework.
Gerador de
Uma ferramenta que produz um artefato completo e pronto
Artefatos
para o uso a partir de sua especificação.
GlassFish é um servidor de aplicações Java EE de código
aberto e de nível corporativo que oferece clusterização
GlassFish
avançada,
administração
centralizada
desempenho,
confiabilidade, produtividade e facilidade de uso superior de
servidores de aplicações proprietários (SUN, 2010).
É uma linguagem de programação ou de especificação
dedicada a um domínio de problema particular. O conceito
Linguagem de
não é novo, linguagens de programação de propósito
Domínio
especial, os tipos de linguagem de modelagem sempre
existiram, mas o termo se tornou mais popular devido à
ascensão da modelagem de domínio específico.
82
É uma pratica de análise e programação que agregam
OO (Orientado a
Objeto)
técnica de armazenamento, um conjunto de dados e suas
rotinas a um objeto que faz parte de uma determinada
classe de objetos, sendo que, na programação, cada objeto
é tratado como se fosse uma unidade autônoma.
O processo de software pode ser definido como um
conjunto de atividades uniformizadas a serem aplicadas
sistematicamente que se encontram agrupadas em fases,
cada uma das quais com os seus intervenientes com
Processo de
responsabilidades, que possui diversas entradas e produz
Software
diversas saídas. Isto é, define quem faz o quê, quando e
como para atingir um certo objetivo. Pode-se considerar, que
de uma forma geral o processo de software pode ser visto como
um conjunto de padrões voltados para a construção de um
produto de software (MACORATTI, 2010).
RowSet é uma interface que configura a conexão com o
banco de dados e executa as consultas automaticamente,
RowSet
oferece métodos ao programador para especificar as
propriedades
conexão,
há
necessárias
dois
para
tipos
de
se
estabelecer
Rowset
uma
conectado
e
desconectado (JAVA FREE, 2010).
Programa que fornece algum tipo de serviço para outro
programa, na internet ou em outras redes, um computador
ou programa que responde a comandos provenientes de
Servidor
um cliente. Por exemplo, um servidor de arquivos pode
conter um arquivo de dados ou de programas, quando um
cliente solicita um arquivo, o servidor transfere uma cópia
do arquivo para o cliente.
Conjunto de programas que executam tarefas que fazem
Sistema
parte de uma tarefa global. Um sistema pode ser composto
dos seguintes programas: compra e venda, atualização,
controle, gerenciamento e etc.
83
Todo e qualquer conjunto de instruções executadas no
computador. Um software pode ser um programa, um
Software
sistema, uma
rotina,
um
sistema operacional,
uma
linguagem, um aplicativo, uma aplicação ou qualquer outro
conjunto de instruções, independente da função, tamanho,
forma, linguagem ou de qualquer outra característica.
Tomcat é um servidor web Java, que inclui ferramentas de
configurações
Tomcat
e
gerenciamento,
e
cobre
parte
da
especificação J2EE com tecnologias como Java Servlets,
Java Server Pages e tecnologias de apoio relacioandas a
segurança (APACHE TOMCAT, 2010).
É um sistema de páginas e documentos em hipermídia que
Web
são interligadas e executadas na internet, para visualização
e navegação do conteúdo dessas paginas na web utiliza-se
um navegador de internet.
Fonte: Elaborado pelos autores, 2010.
Quadro 13. Termos utilizados no trabalho.
84
APÊNDICES
85
APÊNDICE A – SCRIPTS SQL DE CRIAÇÃO DO ESQUEMA DA OFICINA
ELETRÔNICA NO BANCO DE DADOS
Para a utilização do gerador e criação dos artefatos foram criados
esquemas no banco de dados do usuário, além dos esquemas padrões do
banco para estudos de caso do gerador. Abaixo estão os scripts de criação do
esquema de estudo de caso da Oficina Eletrônica.
CREATE USER OFICINA PROFILE "DEFAULT"
IDENTIFIED BY "oficina" DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK;
GRANT "CONNECT" TO "OFICINA";
GRANT "DBA" TO "OFICINA";
CREATE TABLE OFICINA.CLIENTES (
CODIGO NUMBER (6),
NOME VARCHAR2 (40),
ENDERECO VARCHAR2 (45),
TELEFONE VARCHAR2 (12),
EMAIL VARCHAR2 (40),
CIDADE VARCHAR2 (45),
CONSTRAINT PK_CLIENTES PRIMARY KEY (CODIGO)
);
CREATE TABLE OFICINA.TIPOAPARELHO (
CODIGO NUMBER (6),
DESCRICAO VARCHAR2 (50),
CONSTRAINT PK_TIPOAPARELHO PRIMARY KEY (CODIGO)
);
CREATE TABLE OFICINA.APARELHO (
NUMERO NUMBER (6),
MODELO VARCHAR2 (15),
SITUACAO VARCHAR2 (50),
FABRICANTE VARCHAR2 (25),
CODIGO NUMBER(6),
CONSTRAINT PK_APARELHO PRIMARY KEY (NUMERO),
CONSTRAINT FK_OFICINA_TIPOAPARELHO FOREIGN KEY (CODIGO)
REFERENCES OFICINA.TIPOAPARELHO (CODIGO)
);
CREATE TABLE OFICINA.TECNICO (
CODIGO NUMBER (6),
NOME VARCHAR2 (40),
86
PERCCOMISSAO NUMBER (5),
SALARIO NUMBER (10),
ESPECIALIDADE VARCHAR2 (15),
CONSTRAINT PK_TECNICO PRIMARY KEY (CODIGO),
CONSTRAINT SALARIO_CK CHECK (SALARIO in ('>0')),
CONSTRAINT PERCCOMISSAO_CK CHECK (PERCCOMISSAO in ('>0'))
);
CREATE TABLE OFICINA.COMISSAO (
CODIGO NUMBER (6),
DATAPAGAMENTO DATE,
VALOR NUMBER (10),
CONSTRAINT PK_COMISSAO PRIMARY KEY (CODIGO),
CONSTRAINT FK_OFICINA_TECNICO FOREIGN KEY (CODIGO)
REFERENCES OFICINA.TECNICO (CODIGO),
CONSTRAINT VALOR_CK CHECK (VALOR in ('>0'))
);
CREATE TABLE OFICINA.CONSERTOAPARELHO (
CODIGO NUMBER (6),
DATAENTRADA DATE,
DATASAIDA DATE,
DEFEITOSAPRESENTADOS VARCHAR2 (50),
PECASTROCAS VARCHAR2 (50),
SERVICOSEXECUTADOS VARCHAR2(50),
CODIGOCLIENTE NUMBER (6),
NUMEROAPARELHO NUMBER (6),
CONSTRAINT PK_CONSERTODEAPARELHO PRIMARY KEY (CODIGO),
CONSTRAINT FK_OFICINA_CLIENTES FOREIGN KEY (CODIGOCLIENTE)
REFERENCES OFICINA.CLIENTES (CODIGO),
CONSTRAINT FK_OFICINA_APARELHO FOREIGN KEY
(NUMEROAPARELHO)
REFERENCES OFICINA.APARELHO (NUMERO)
);
CREATE TABLE OFICINA.EXECUCAOCONSERTO (
CODIGOTECNICO NUMBER (6),
CODIGOCONSERTO NUMBER (6),
CONSTRAINT FK_OFICINA_TECNICO_CONSERTO FOREIGN KEY
(CODIGOTECNICO)
REFERENCES OFICINA.TECNICO (CODIGO),
CONSTRAINT FK_OFICINA_CONSERTOAPARELHO FOREIGN KEY
(CODIGOCONSERTO)
REFERENCES OFICINA.CONSERTOAPARELHO (CODIGO)
);
87
APÊNDICE B – TEMPLATES DE CRIAÇÃO DOS ARTEFATOS
Para a criação dos artefatos foram utilizados três modelos de templates,
sendo que cada template gera um tipo de artefato, sendo SQL, Bean e HTML.
O template de criação dos artefatos com os scripts SQL já foi explicado e
exemplificado no desenvolvimento do trabalho. Abaixo estão os modelos dos
templates criados para as classes Java Beans e das páginas HTML do gerador
de artefatos.
Os templates para classes Beans e páginas HTML seguem o mesmo
padrão do template para scripts SQL. Os templates contêm as partes fixas que
estão destacadas em negrito e as partes variáveis que estão entre tags.
A seguir têm se o template criado para as classes Beans do gerador.
public class Esquema {
private String nome;
public Esquema ( ){ }
public String getNome ( ) {
return nome;
}
public void setNome (String nome) {
this.nome = nome;
}
}
Fonte: Elaborado pelos Autores, 2010.
Figura 40. Conjunto de scripts de criação das classes Beans.
public class <NomeTabela> {
private <tipo> <nome>;
public <NomeTabela> ( ){ }
public <tipo> get<Atributo> ( ) {
return <atributo>;
}
public void set<Atributo> (<tipo> <atributo>) {
this.<atributo> = <atributo>;
}
}
Fonte: Elaborado pelos Autores, 2010.
Figura 41. Template definido para criação das classes Beans.
88
//template para gerar o script Java Bean da tabela escolhida
public void getScriptBean(Atributos atributos, String esquema,
String tabela) throws IOException{
String espaco = " ";
String esq = esquema;
String tab = tabela;
FileWriter saida =null;
//criando arquivo
File dir = new
File("c:/"+padrao.fCase(esq)+"."+padrao.fCase(tab));
if (!dir.exists()){
dir.mkdir();
}
File arquivo = new File(dir, padrao.fCase(tab)+"(java).java");
saida = new FileWriter(arquivo,true);
AtributosDAO atr = new AtributosDAO();
List<Atributos>lista = atr.getListaAtributos(esq, tab);
saida.write("public class "+padrao.fCase(tab)+" {\n");
//atributos
for (Atributos atrs : lista) {
saida.write("\n"+espaco+"private "+atrs.getTipoDado()+"
"+atrs.getNome()+";");
}
//construtor
saida.write("\n\n"+espaco+"public "+padrao.fCase(tab)
+"(){}\n");
//getters and setter
for (Atributos atrs : lista) {
saida.write("\n\n"+espaco+"public "+atrs.getTipoDado()+"
get"+padrao.fCase(atrs.getNome())+"(){");
saida.write("\n"+espaco+"
"+"return "+atrs.getNome()
+";\n"+espaco+"}");
saida.write("\n\n"+espaco+"public void set"+padrao. fCase
(atrs.getNome())+"("+atrs.getTipoDado()+"
"+atrs.getNome()+"){");
saida.write("\n"+espaco+"
"+"this."+atrs.getNome()+" =
"+atrs.getNome()+";\n"+espaco+"}");
}
saida.write("\n\n}");
saida.close();
}
}
Fonte: Elaborado pelos Autores, 2010.
Figura 42. Template para construção das Beans.
89
A seguir têm se nas Figuras 43, 44 e 45 o modelo do template criado
para as páginas HTML do gerador de artefatos.
//template para gerar o script HTML da tabela escolhida
public void getScriptHTML(Atributos atributos, String esquema,
String tabela) throws IOException{
String espaco = "
";
String tab = tabela;
String esq = esquema;
String nome = atributos.getNome();
String tipo = atributos.getTipoDado();
FileWriter saida = null;
//criando arquivo
File dir = new
File("c:/"+padrao.fCase(esq)+"."+padrao.fCase(tab));
if (!dir.exists()){
dir.mkdir();
}
File arquivo = new File(dir, padrao.fCase(tab)+".html");
saida = new FileWriter(arquivo,true);
AtributosDAO atr = new AtributosDAO();
List<Atributos>lista = atr.getListaAtributos(esq, tab);
saida.write("<html>\n");
saida.write("<head>\n");
saida.write("<title> Página HTML da Tabela "+padrao.fCase
(tab)+"</title>\n");
saida.write("</head>\n");
saida.write("<body>\n");
saida.write("<form id=\"id"+padrao.fCase(tab)+"\">\n");
for (Atributos atrs : lista) {
saida.write(espaco+""+atrs.getNome()+": <input type=\"text\"
id=\""+atrs.getNome()+"\" /><br/>\n");
}
saida.write(espaco+"<input type=\"button\" value=\"Salvar\"
/>\n");
saida.write(espaco+"<input type=\"button\" value=\"Limpar\"
/>");
saida.write("</form>\n");
saida.write("</body>\n");
saida.write("</html>\n");
saida.write("<html>\n");
saida.close();
}
Fonte: Elaborado pelos Autores, 2010.
Figura 43. Template para construção das páginas HTML.
90
<html>
<head>
<title> Página HTML da Tabela TipoAparelho </title>
</head>
<body>
codigo: <input type="text" id=" codigo"/> <br/>
descricao: <input type="text" id=" descricao"/> <br/>
</body>
</html>
Fonte: Elaborado pelos Autores, 2010.
Figura 44. Conjunto de scripts de criação das páginas HTML.
<html>
<head>
<title> Página HTML da Tabela <nome da tabela> </title>
</head>
<body>
nome_atributo: <input type="text" id="<nome do atributo>"/> <br/>
</body>
</html>
Fonte: Elaborado pelos Autores, 2010.
Figura 45. Template definido para criação das páginas HTML.