Embed Size (px)
Citation preview
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
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
R713g
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
Construtor
Se o JavaBean não contiver nenhum construtor declarado
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.
Persistência
O JavaBens pode implementar interfaces que possibilitem a
persistência e restauração do estado do objeto da classe, mas essa
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.
Atributos
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,
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 seus dados utilizando a API do JDBCTM. 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?
codigo 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 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?
codigoConserto Numero 6 Não
descrição Texto 50 Não
códigoTecnico Numero 6 Não
numeroAparelho Numero 6 Nã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
códigoTipoAparelho Numero 6 Não 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?
código Numero 6 Não
descrição Texto 50 Nã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 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
especialidade Texto 15 Não 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.
Fonte: Elaborado pelos Autores, 2010. Figura 31. Conjunto de scripts de criação de tabelas utilizando SQL.
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.
CREATE TABLE <ESQUEMA>.<NOME_TABELA> ( <ATRIBUTO> <TIPO> (<TAMANHO>) ) ;
CREATE TABLE OFICINA.CLIENTES ( CODIGO NUMBER (6),
NOME VARCHAR2 (40), ENDERECO VARCHAR2 (45), TELEFONE VARCHAR2 (12), EMAIL VARCHAR2 (40), CIDADE VARCHAR2 (45)
) ;
69
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.
//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 );
} } }
70
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
Gerador de classes Beans
Gerador de interfaces HTML
Gerador AlphaWEB
Templates
Recupera dados das especificações do
Gerador
Base de Dados
do Gerador
... Templates modelo = new Templates(); AtributosDAO obj = new AtributosDAO(); modelo.getScriptSQL(tabela, esquema);
modelo.getScriptHTML(obj.getAtributos ObjAtributo(esquema, tabela), esquema, tabela); modelo.getScriptBean(obj.getAtributosObjAtributo(esquema, tabela), esquema, tabela); response.getWriter().close();
...
Lê as definições Java para geração
dos artefatos
Gerador de scripts SQL
Script SQL de criação da tabela
CREATE TABLE OFICINA.TIPOAPARELHO ( CODIGO NUMBER(22), DESCRICAO VARCHAR2(50) );
Interface HTML
Classe Bean
public class TipoAparelho { private int codigo; private String descricao; public TipoAparelho(){} public int getCodigo(){ return codigo; } public void setCodigo(int codigo){ this.codigo = codigo; } public String getDescricao(){ return descricao; } public void setDescricao(String
descricao){ this.descricao = descricao; } }
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.
Fonte: Elaborado pelos Autores, 2010. Figura 37. Artefato de scripts SQL da Tabela Comissão.
Fonte: Elaborado pelos Autores, 2010. Figura 38. Artefato Bean da Tabela Comissão.
CREATE TABLE OFICINA.COMISSAO ( CODIGO NUMBER(22), DATAPAGAMENTO DATE(7),
VALOR NUMBER(22) );
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; } }
74
Fonte: Elaborado pelos Autores, 2010. Figura 39. Artefato HTML da Tabela Comissão.
<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
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 em: <http://pt.wikipedia.org/wiki/API)>. Acesso em: 31 ago. 2009. 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 em: <http://javafree.uol.com.br/index.jf>. Acesso em: 08 fev. 2010. 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%A3o)>. 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 em: < http://pt.wikipedia.org/wiki/JDBC)>. Acesso em: 02 out. 2009. 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 em: <http://pt.wikipedia.org/wiki/Metadados)>. Acesso em: 22 out. 2009. 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 em: <http://pt.wikipedia.org/wiki/Oracle>. Acesso em: 12 out. 2009.
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ós-Graduaçã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 em: <http://www.inf.puc-rio.br/~draco/>. Acesso em: 11 nov. 2009. 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 em: <http://pt.wikipedia.org/wiki/Servlet)>. Acesso em: 03 set. 2009. 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 em: <http://pt.wikipedia.org/wiki/Templates>. Acesso em: 10 mai. 2010. 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
API
As API’s contêm um conjunto de rotinas e padrões
estabelecidos por um software para a utilização de suas
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).
Aplicação Coleção de componentes organizada para realizar funções
interdependentes, visando apoiar atividades de um ou mais
usuários.
Artefato
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,
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.
Classe
É uma estrutura que abstrai um conjunto de objetos com
características similares ou iguais, define o comportamento
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
DataSource é um parâmetro onde será especificado o
caminho lógico do banco de dados, representa dados em
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
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
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.
Domínio
Uma área de aplicação. São exemplos: pilhas, árvores,
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
DriverManager é uma classe que cria e gerencia o
estabelecimento das conexões e faz gerenciamento dos
drivers JDBC, tem como responsabilidade manter uma lista
de implementações do driver e apresentar as
implementações a aplicação (WIKI SINTECTUS, 2010).
Framework
Qualquer solução incompleta que pode ser completada
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 Artefatos
Uma ferramenta que produz um artefato completo e pronto
para o uso a partir de sua especificação.
GlassFish
GlassFish é um servidor de aplicações Java EE de código
aberto e de nível corporativo que oferece clusterização
avançada, administração centralizada desempenho,
confiabilidade, produtividade e facilidade de uso superior de
servidores de aplicações proprietários (SUN, 2010).
Linguagem de Domínio
É uma linguagem de programação ou de especificação
dedicada a um domínio de problema particular. O conceito
não é novo, linguagens de programação de propósito
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
OO (Orientado a Objeto)
É uma pratica de análise e programação que agregam
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.
Processo de Software
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. 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
RowSet é uma interface que configura a conexão com o
banco de dados e executa as consultas automaticamente,
oferece métodos ao programador para especificar as
propriedades necessárias para se estabelecer uma
conexão, há dois tipos de Rowset conectado e
desconectado (JAVA FREE, 2010).
Servidor
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
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.
Sistema
Conjunto de programas que executam tarefas que fazem
parte de uma tarefa global. Um sistema pode ser composto
dos seguintes programas: compra e venda, atualização,
controle, gerenciamento e etc.
83
Software
Todo e qualquer conjunto de instruções executadas no
computador. Um software pode ser um programa, um
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
Tomcat é um servidor web Java, que inclui ferramentas de
configurações 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).
Web
É um sistema de páginas e documentos em hipermídia que
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.
Fonte: Elaborado pelos Autores, 2010. Figura 40. Conjunto de scripts de criação das classes Beans.
Fonte: Elaborado pelos Autores, 2010. Figura 41. Template definido para criação das classes Beans.
public class Esquema { private String nome; public Esquema ( ){ } public String getNome ( ) { return nome; } public void setNome (String nome) { this.nome = nome; } }
public class <NomeTabela> { private <tipo> <nome>;
public <NomeTabela> ( ){ }
public <tipo> get<Atributo> ( ) { return <atributo>;
}
public void set<Atributo> (<tipo> <atributo>) { this.<atributo> = <atributo>;
} }
88
Fonte: Elaborado pelos Autores, 2010. Figura 42. Template para construção das Beans.
//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(); } }
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.
Fonte: Elaborado pelos Autores, 2010. Figura 43. Template para construção das páginas HTML.
//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(); }
90
Fonte: Elaborado pelos Autores, 2010. Figura 44. Conjunto de scripts de criação das páginas HTML.
Fonte: Elaborado pelos Autores, 2010. Figura 45. Template definido para criação das páginas HTML.
<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>
<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>
