UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
INCREMENTANDO O DESENVOLVIMENTO DE SISTEMAS BASEADOS
EM FRAMEWORK ATRAVÉS DE FERRAMENTA RAD
Área de Engenharia de Software
por
Everton Flávio Rufino Seára
Fabiane Barreto Vavassori Benitti, Drª. Eng.
Orientadora
Itajaí (SC), dezembro de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
INCREMENTANDO O DESENVOLVIMENTO DE SISTEMAS BASEADOS
EM FRAMEWORK ATRAVÉS DE FERRAMENTA RAD
Área de Engenharia de Software
por
Everton Flávio Rufino Seára
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientadora: Fabiane Barreto Vavassori Benitti,
Drª. Eng.
Itajaí (SC), dezembro de 2005
i
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................iv
LISTA DE FIGURAS................................................................................. v
LISTA DE TABELAS ...............................................................................vi
RESUMO...................................................................................................vii
ABSTRACT..............................................................................................viii
1. INTRODUÇÃO ...................................................................................... 1
1.1. OBJETIVOS ........................................................................................................ 2
1.1.1. Objetivo geral .................................................................................................... 2
1.1.2. Objetivos específicos ......................................................................................... 2
1.2. METODOLOGIA................................................................................................ 3
1.3. ESTRUTURA DO TRABALHO ....................................................................... 5
2. FUNDAMENTAÇÃO TEÓRICA ........................................................ 6
2.1. REUSO DE CÓDIGO ......................................................................................... 6
2.1.1. Vantagens do reuso de código.......................................................................... 7
2.2. RAD - RAPID APPLICATION DEVELOPMENT......................................... 8
2.2.1. Benefícios do RAD .......................................................................................... 11
2.2.2. RAD X CASE .................................................................................................. 12
2.3. PADRÕES DE PROJETO................................................................................ 13
2.3.1. Programas de aplicação.................................................................................. 14
2.3.2. Toolkits............................................................................................................. 15
2.3.3. Frameworks..................................................................................................... 15
2.4. FRAMEWORK PHPLIB-UNIVALI............................................................... 19
2.4.1. Elementos flexíveis do framework PHPLib-UNIVALI............................... 23
2.5. SOLUÇÕES SIMILARES................................................................................ 24
2.5.1. Geração automática de cadastros e consultas para linguagem ASP
baseado em banco de dados...................................................................................... 25
2.5.2. NETSIS - ferramenta CASE para geração de páginas ASP....................... 26
2.5.3. Polar Studio ..................................................................................................... 27
2.5.4. Análise comparativa entre as soluções pesquisadas .................................... 28
2.6. TECNOLOGIAS UTILIZADAS ..................................................................... 29
2.6.1. GALS – gerador de analisadores léxicos e sintáticos .................................. 30
2.6.2. XML - Extensive Markup Language ............................................................ 31
3. PROJETO ............................................................................................. 37
3.1. DEFINIÇÃO DOS REQUISITOS E REGRAS DE NEGÓCIO................... 37
3.2. MODELO DE CASOS DE USO ...................................................................... 39
3.3. DIAGRAMA DE CLASSES............................................................................. 41
3.3.1. Diagrama de classes do sistema ..................................................................... 41
3.3.2. Diagrama de classes do analisador SQL....................................................... 44
3.4. XML SCHEMA ................................................................................................. 46
3.5. IMPLEMENTAÇÃO ........................................................................................ 49
3.5.1. Reconhecedor de linguagem SQL ................................................................. 50
3.5.2. Estrutura de dados do sistema....................................................................... 51
3.5.3. Opções de configuração do sistema............................................................... 52
3.5.4. Gerador de código PHP.................................................................................. 52
3.6. FERRAMENTA RADPHP............................................................................... 54
3.6.1. Contextualizando o RADPHP no processo de desenvolvimento de
software ...................................................................................................................... 54
3.6.2. Estudo de caso ................................................................................................. 57
3.6.3. Demonstração .................................................................................................. 59
3.6.4. Produtividade RAD ........................................................................................ 67
4. CONCLUSÕES .................................................................................... 69
4.1. TRABALHOS FUTUROS................................................................................ 70
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 71
APÊNDICE A – DICIONÁRIO DE DADOS PHPLIB-UNIVALI ..... 74
APÊNDICE B – CENÁRIOS DOS CASOS DE USO........................... 81
APÊNDICE C – XML SCHEMA DA FERRAMENTA RADPHP..... 94
APÊNDICE D – PONTOS DE FUNÇÃO DO SISTEMA DE
PATRIMÔNIO ......................................................................................... 97
ANEXO I – ARTIGO ............................................................................... 99
iii
LISTA DE ABREVIATURAS
ASP
CASE
DER
DOM
DTD
ER
GALS
HTML
IDE
IIS
JAD
PHP
RAD
RADPHP
RF
RN
RNF
SGML
SQL
TCC
TI
UML
UNIVALI
URL
W3C
XML
XSD
Active Server Pages
Computer Aided System Engineering
Diagrama de Entidade Relacionamento
Document Object Model
Document Type Definition
Entidade Relacionamento
Gerador de Analisadores Léxicos e Sintáticos
Hypertext Markup Language
Integrated Development Environment
Internet Information Server
Joint Application Development
Hypertext Preprocessor
Rapid Application Development
Rapid Application Development Hypertext Preprocessor
Requisitos Funcionais
Regras de Negócio
Requisitos Não Funcionais
Standard Generalized Markup Language
Structured Query Language
Trabalho de Conclusão de Curso
Tecnologia da Informação
Unified Modeling Language
Universidade do Vale do Itajaí
Uniform Resource Locator
World Wide Web Consortium
Extensible Markup Language
XML Schema Definition
LISTA DE FIGURAS
Figura 1. Elementos flexíveis em frameworks: (a) Caixa branca; (b) Caixa Preta ............................17
Figura 2. Relacionamento entre aplicações e framework PHPLib-UNIVALI...................................20
Figura 3. Arquivos de funções do framework PHPLib-UNIVALI ....................................................21
Figura 4. Diagrama lógico do framework PHPLib-UNIVALI ..........................................................22
Figura 5. Exemplo de código do framework PHPLib-UNIVALI (frozen-spot) ................................23
Figura 6. Exemplo de código hot-spot do framework PHPLib-UNIVALI ........................................24
Figura 7. Tela exemplo da ferramenta proposta por Silveira (2003) .................................................25
Figura 8. Interface exemplo da ferramenta NETSIS..........................................................................26
Figura 9. Arquitetura da Ferramenta Polar Studio .............................................................................27
Figura 10. IDE da Ferramenta Polar Studio.......................................................................................28
Figura 11. Exemplo de um documento XML ....................................................................................32
Figura 12. Exemplo de um documento DTD .....................................................................................33
Figura 13. Exemplo de um documento XML Schema.......................................................................35
Figura 14. Modelo de Casos de Uso da ferramenta RADPHP...........................................................40
Figura 15. Diagrama de classes do sistema........................................................................................42
Figura 16. Diagrama de classes do analisador SQL...........................................................................45
Figura 17. Visão geral do XML Schema para ferramenta RADPHP.................................................47
Figura 18. Detalhes do elemento project ...........................................................................................47
Figura 19. Estrutura interna do elemento attribute ............................................................................48
Figura 20. Estrutura interna dos elementos list ..................................................................................48
Figura 21. Estrutura interna dos elementos detail..............................................................................49
Figura 22. Estrutura interna dos elementos register ..........................................................................49
Figura 23. Definição da gramática na ferramenta GALS...................................................................51
Figura 24. Interface do wizard do XML Data Binding......................................................................52
Figura 25. Exemplo de modelo para geração de código ....................................................................53
Figura 26. Arquivos de modelo da ferramenta RADPHP e suas relações .........................................54
Figura 27. Modelo de processo de software em cascata ....................................................................55
Figura 28. Diagrama de entidade-relacionamento (DER) para o estudo de caso proposto ...............58
Figura 29. Interface para criação de projetos na ferramenta RADPHP .............................................59
Figura 30. Interface para configuração das informações do banco de dados.....................................60
Figura 31. Configuração do formulário de listagem ..........................................................................61
Figura 32. Configuração do formulário de detalhe ............................................................................62
Figura 33. Configuração do formulário de cadastro ..........................................................................63
Figura 34. Interface para geração de código na ferramenta RADPHP ..............................................64
Figura 35. Código fonte de um formulário de listagem gerado pela ferramenta RADPHP ..............64
Figura 36. Formulário de listagem de patrimônios ............................................................................65
Figura 37. Formulário de detalhe de setores ......................................................................................65
Figura 38. Formulário de cadastro de patrimônios ............................................................................65
Figura 39. Interface para configuração de consultas personalizadas .................................................66
Figura 40. Interfaces para alteração da base de dados (a) Tabelas; (b) Atributos..............................67
Figura 41. XML Schema da ferramenta RADPHP ............................................................................96
LISTA DE TABELAS
Tabela 1. Benefícios do RAD ............................................................................................................11
Tabela 2. Comparando RAD e CASE................................................................................................13
Tabela 3. Ciclo de vida de um framework .........................................................................................19
Tabela 4. Comparação das ferramentas pesquisadas com a ferramenta proposta..............................29
Tabela 5. Atributos da Classe dbBase................................................................................................74
Tabela 6. Operações da Classe dbBase ..............................................................................................74
Tabela 7. Atributos da Classe formBase ............................................................................................75
Tabela 8. Operações da Classe formBase ..........................................................................................75
Tabela 9. Atributos da Classe formCadastro......................................................................................75
Tabela 10. Operações da Classe formCadastro ..................................................................................76
Tabela 11. Atributos da Classe formDetalhe .....................................................................................77
Tabela 12. Operações da Classe formDetalhe....................................................................................77
Tabela 13. Atributos da Classe formLista..........................................................................................78
Tabela 14. Operações da Classe formLista ........................................................................................78
Tabela 15. Atributos da Classe formListacomfiltro ...........................................................................78
Tabela 16. Operações da Classe formListacomfiltro .........................................................................78
Tabela 17. Atributos da Classe htmlBase...........................................................................................80
Tabela 18. Operações da Classe htmlBase.........................................................................................80
Tabela 19. Atributos da Classe htmlErro ...........................................................................................80
Tabela 20. Operações da Classe htmlErro .........................................................................................80
RESUMO
SEÁRA, Everton Flávio Rufino. Incrementando o desenvolvimento de sistemas baseados em
framework através de ferramenta RAD. Itajaí, 2005. 108 f. Trabalho de Conclusão de Curso
(Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar,
Universidade do Vale do Itajaí, Itajaí, 2005.
O cenário de desenvolvimento de software, cada vez mais competitivo, vem enfrentando profundas
mudanças na última década, exigindo das instituições rápidas e contínuas adaptações para a sua
sobrevivência e crescimento. Sabe-se que o processo de desenvolvimento de software é complexo
no que tange o gerenciamento de tempo, custos e pessoal, o que se evidencia na medida em que os
softwares tornam-se mais sofisticados. Dessa forma, existe uma grande tendência em desenvolver
sistemas de informação utilizando ferramentas e métodos de desenvolvimento rápido. Nesse
contexto, surgem as ferramentas RAD (Rapid Application Development), que prometem ser uma
poderosa fórmula para agilizar os processos tradicionais de desenvolvimento de software. De forma
geral, RAD descreve um ciclo de vida de software projetado para fornecer um processo de
desenvolvimento mais rápido e de maior qualidade que os tradicionais processos de ciclo de vida de
software. Também pode-se considerar que a utilização de frameworks acelera, consideravelmente, a
produtividade no desenvolvimento de software, uma vez que os mesmos ditam a arquitetura da
aplicação, definem a estrutura geral e suas divisões em classes e objetos, bem como a
responsabilidade das classes e como estas colaboram entre si. Um framework também predefine os
parâmetros do projeto, de maneira que o projetista possa se concentrar nos aspectos específicos da
aplicação. Dessa forma, acredita-se que a união de ambas as soluções, RAD e framework, possa
proporcionar mais do que um desenvolvimento rápido de software, mas, também, um produto de
qualidade e de fácil manutenção por parte dos desenvolvedores. Portanto, este projeto visa conceber
uma ferramenta RAD utilizando como base um framework de desenvolvimento de software, neste
caso, o PHPLib-UNIVALI, a fim automatizar a geração de scripts em formato PHP (Hypertext
Preprocessor). A ferramenta concebida tem como pressupostos a flexibilidade de configuração e
visa oferecer uma interface amigável, de modo que o desenvolvedor tenha à sua disposição um
software capaz de auxiliá-lo na criação de páginas que utilizam a tecnologia PHP de maneira rápida
e eficiente. Dentre as diversas tecnologias utilizadas para execução deste projeto, vale ressaltar a
aplicabilidade de linguagens formais e de documentos XML (Extensible Markup Language).
Espera-se, dessa forma, que este projeto contribua tanto para o meio acadêmico quanto para o meio
comercial, uma vez que foi concebida uma ferramenta que utiliza diversos conceitos
computacionais e que pode ser amplamente utilizada para desenvolvimento de sistemas Web que
utilizam PHP.
Palavras-chave: Engenharia de Software. Desenvolvimento Rápido de Aplicações. Framework.
ABSTRACT
The software development scene, more and more competitive, has faced deep changes in the last
decade, demanding fast and continuous adaptations from the institutions for its survival and
growth. It is known that the software development process is complex and as regard to time
management, costs and people, what it is evident in the measure that software becomes more
sophisticated. In such case, there is a great tendency in developing information systems using fast
development methods and tools. In this context, the Rapid Application Development (RAD) emerge,
which promises to be a powerful formula to speed up the traditional software development process.
Concisely, RAD describes a software life cycle designed to provide a faster and larger quality
development process than the traditional one. On the other hand, it can be said, the use of
frameworks also speed up the productivity in software development considerably, once they impose
the application architecture, define the general structure and its division in objects and classes as
well as the responsability of the classes and how these collaborate between them. A framework also
define the project parameters, in the way that the software engineers can concentrate in specific
aspects of the application. So, it is believed that, the union of both solutions RAD and framework
can provide more than a fast software development, but a high quality product and easy
maintenance by the developers. Therefore, this project aims to conceive a RAD tool that uses as
base a software development framework, in this case, the PHPLib-UNIVALI, in order to automate
the script generation in Hypertext Preprocessor (PHP) format. The conceived tool has as
presupposed the configuration flexibility and it aims to offer a friendly interface so that the
developer has at one’s disposal a software capable of helping him/her in PHP pages creation in a
fast and efficient way. Among the several technologies used to execute this project, it is important to
stand out the applicability of formal languages and XML (Extensible Markup Language)
documents. It is hopes that this project contributes in both academic and business environment,
once that it conceived a tool that uses several computational concepts and can be used widely to
develop web systems using PHP.
Keywords: Software Engineering. Rapid Application Development. Framework.
1. INTRODUÇÃO
Segundo Rauter e Benato (2004), o cenário competitivo vem experimentando profundas
mudanças na última década, exigindo das instituições rápidas e contínuas adaptações para a sua
sobrevivência e crescimento. Benvenutti (2002), afirma que o trabalho de desenvolvimento de
software é um processo difícil e consumidor de recursos como tempo, dinheiro e pessoal, o que
evidencia-se na medida em que os softwares tornam-se mais complexos.
Segundo Malcolm (2001), existe uma grande tendência em desenvolver sistemas de
informação utilizando ferramentas e métodos de desenvolvimento rápido. Benvenutti (2002)
assegura que uma maneira eficiente de agilizar o processo de desenvolvimento de software é aplicar
técnicas de reuso, que consistem em reutilizar partes de código que já foram anteriormente testados,
tornando assim o processo mais otimizado.
Neste contexto, surge o conceito RAD (Rapid Application Development – Desenvolvimento
Rápido de Aplicações) que, conforme Howard (2002), promete ser uma poderosa fórmula para
cortar os tradicionais projetos de software demorados e proporcionar maior produtividade ao
desenvolvedor.
Também pode-se dizer que a utilização dos arcabouços de classes (frameworks), acelera
consideravelmente a produtividade no desenvolvimento de software. Segundo Gamma et al. (2000),
os frameworks são um conjunto de classes cooperantes que constroem um projeto reutilizável para
uma específica classe de software. Um framework dita a arquitetura da sua aplicação, define a
estrutura geral e sua divisão em classes e objetos, bem como define a responsabilidade das classes e
como estas colaboram. Em acréscimo, um framework predefine os parâmetros do projeto, de
maneira que o projetista possa se concentrar nos aspectos específicos da aplicação.
Acredita-se, desta forma, que a junção de ambas as soluções, RAD e framework, possa
proporcionar mais do que um desenvolvimento rápido de software, mas também um produto de
qualidade e de fácil manutenção por parte dos desenvolvedores.
A proposta deste trabalho, portanto, é conceber uma ferramenta RAD que utiliza como base
um framework de desenvolvimento de software, neste caso, o PHPLib-UNIVALI, a fim de
automatizar a geração de scripts em formato PHP (Hypertext Preprocessor – Pré-Processador de
Hipertexto). Visa-se criar um software configurável e de interface amigável, oferecendo ao
desenvolvedor uma ferramenta capaz de auxiliá-lo na criação de páginas, que utilizam a tecnologia
PHP, de maneira rápida e eficiente.
Assim, a Seção 1.1 apresenta os objetivos do trabalho e a Seção 1.2 demonstra a
metodologia utilizada para execução do mesmo. Pode-se observar a estrutura do trabalho na Seção
1.3 e a fundamentação teórica no Capítulo 2. O Capítulo 3 descreve as funcionalidades, apresenta a
modelagem conceitual e o protótipo da ferramenta proposta. As conclusões são expostas no
Capítulo 4.
1.1. OBJETIVOS
1.1.1. Objetivo geral
Conceber uma ferramenta RAD capaz de automatizar a geração de código compatível com o
framework PHPLib-UNIVALI.
1.1.2. Objetivos específicos
Os objetivos específicos deste projeto são:
•
Pesquisar e estudar soluções similares;
•
Determinar os requisitos exigidos pelo sistema;
•
Pesquisar conceitos e tecnologias necessárias para a implementação do sistema;
•
Realizar a modelagem conceitual do sistema;
•
Implementar o sistema;
o Criar reconhecedor de script SQL (Structured Query Language) para Oracle;
o Automatizar a geração de código PHP a partir um script SQL para Oracle;
o Permitir customização de nome da página, tamanho e tipo dos campos, escolha de
botões e SQLs para consultas;
•
Testar a implementação do sistema; e
•
Documentar o desenvolvimento e os resultados do sistema.
2
1.2. METODOLOGIA
Pode-se considerar que a metodologia utilizada para a realização deste projeto consiste em
seis grandes etapas (i) Estudo; (ii) Especificação do Sistema; (iii) implementação; (iv) testes; (v)
validação; e (vi) elaboração do volume final; .
A etapa de estudo consiste basicamente em pesquisar e estudar as tecnologias e teorias
computacionais necessárias para a elaboração do projeto. Esta etapa é responsável pela realização
dos seguintes estudos:
•
Conceitos RAD: tendo em vista que a proposta principal deste projeto é a concepção
de uma ferramenta RAD, buscou-se denotar este conceito e seus benefícios;
•
Conceitos de framework: uma vez que a intenção da ferramenta RAD proposta é
gerar código fonte baseada em um frawework, realizou-se um estudo que abrange o
conceito de um frawework, seu principal objetivo, ciclo de vida e outros aspectos
pertinentes;
•
Framework PHPLib-UNIVALI: nesta fase realizou-se estudo sobre o framework
PHPLib-UNIVALI, visto que o mesmo foi o framework escolhido para ser base da
geração de código da ferramenta, e foram documentadas suas principais funções;
•
Soluções similares: com o intuito de obter maior conhecimento sobre o sistema
proposto, realizou-se uma pesquisa em busca de soluções similares, as mesmas
foram analisadas e comparadas com o projeto em questão; e
•
Tecnologias necessárias: com o objetivo de simplificar a implementação do sistema,
foram estudadas e definidas as tecnologias necessárias para implementar o sistema.
A etapa de especificação do sistema objetivou elicitar e analisar as necessidades da
ferramenta, bem como transformá-las em requisitos computacionais. Também foi intuito desta etapa
realizar análise do sistema utilizando a Unified Modeling Language (UML) e XML Schema. Nesta
etapa foram realizadas as seguintes tarefas:
•
Regras de negócio e requisitos do sistema: durante esta fase foram elicitados os
requisitos funcionais, não funcionais e regras de negócio do sistema, com o objetivo
de visualizar suas reais necessidades;
3
•
Diagrama de caso de uso e prototipação: Nesta fase as necessidades encontradas
foram transpostas em casos de uso, com o intento de identificar os cenários possíveis
e condições necessárias para a implementação do sistema, além de identificar a
interação entre os mesmos. Também foi criado um protótipo do sistema, a fim de
ilustrar como devem ser dispostas as informações contidas em cada caso de uso;
•
Diagrama de Classes: Com base nos casos de uso e no protótipo da ferramenta, foi
elaborado o diagrama de classes, identificando assim os atributos e operações de
cada classe; e
•
XML Schema: Tendo sido escolhido o XML como base para o armazenamento das
informações referentes aos projetos criados na ferramenta, foi criado o XML Schema
com o a intenção de validar e identificar como seriam dispostas as informações.
A etapa de implementação centrou-se diretamente na implementação da ferramenta proposta
utilizando a linguagem de programação C++. Durante essa etapa foram implementados 4 módulos:
•
Reconhecedor de linguagem SQL;
•
Estrutura de dados do sistema;
•
Opções de configuração do sistema; e
•
Gerador de código PHP.
A quarta etapa – testes – ocorreu em paralelo à etapa de implementação, onde cada módulo
criado foi testado. Ao fim deste processo, foi realizado um teste de integração, com o intuito de
verificar possíveis erros ocorridos durante o processo de integração dos módulos da ferramenta.
A etapa de validação visou o desenvolvimento de uma aplicação simples utilizando a
ferramenta concebida neste projeto.
Além das etapas apresentadas, é importante ressaltar que durante todo o processo ocorreu
concorrentemente a elaboração do texto final do TCC, que objetiva a concepção detalhada de todos
os passos ocorridos durante o projeto.
4
1.3. ESTRUTURA DO TRABALHO
Este trabalho está estruturado em 4 capítulos: (i) Introdução; (ii) Fundamentação Teórica;
(iii) Projeto; e (iv) Conclusões.
O Capítulo 1 (Introdução) apresenta o contexto do projeto, isto é, expõe sucintamente o
tema e aborda as necessidades e os objetivos a serem alcançados com o trabalho.
O Capítulo 2 (Fundamentação Teórica) aborda questões pertinentes ao projeto como
conceitos de RAD e framework, além de apresentar o framework utilizado neste projeto, soluções
similares e as tecnologias necessárias para implementar a ferramenta proposta.
O Capítulo 3 (Projeto) descreve de forma detalhada o projeto e suas funcionalidades,
apresentando aspectos relativos a sua implementação, requisitos funcionais e não funcionais, regras
de negócio, diagrama de casos de uso, diagrama de classes e XML Schema. Além da perspectiva
tecnológica, o Capítulo 3 contextualiza a ferramenta RADPHP no processo de desenvolvimento de
software, apresenta um estudo de caso (elaborado com o intuito de validar a ferramenta), demonstra
a ferramenta do ponto de vista funcional e aborda aspectos referentes a produtividade RAD.
O Capítulo 4 apresenta as considerações finais sobre o trabalho, relacionando o projeto com
seus objetivos, além de expor os resultados obtidos com a conclusão do mesmo e apresentar
recomendações para continuidade do trabalho.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
5
2. FUNDAMENTAÇÃO TEÓRICA
Segundo Karthink, Chung e Ramani (2003), as rápidas mudanças e especializações na
tecnologia, aumentam cada vez mais a dificuldade dos projetistas em manter os processos
industriais atualizados. A complexidade envolvida para construir um software circunda a
competência de dezenas de processos, o que pode acarretar vários problemas.
Peters e Pedrycz (2001) afirmam que estão ocorrendo muitas inovações na engenharia de
software a fim de superar as dificuldades na construção do software. Dentre estas inovações pode-se
elencar: (i) utilização de frameworks básicos; (ii) modelagem de sistemas de software; (iii)
programação orientada a objetos; (iv) programação automática; e (v) programação visual.
Como afirma Agarwal et al. (2000), em um mundo dominado por deadlines e usuários
coléricos, onde a competitividade pode depender de quão rápido um software é desenvolvido, podese dizer que a utilização das inovações proporcionadas pela engenharia de software a fim de
desenvolver métodos de desenvolvimento rápido de aplicações são certamente atraentes.
Conforme mencionado no Capítulo 1, este projeto tem o intuito de conceber uma ferramenta
que acelera o desenvolvimento de aplicações. Sendo assim, nas seções subseqüentes dá-se ênfase
aos métodos de desenvolvimento de aplicações que serão utilizados como base neste projeto. A
Seção 2.1 aborda o reuso de código, tendo em vista que o mesmo influencia fortemente no
desenvolvimento rápido de aplicações. A Seção 2.2 discute o desenvolvimento rápido de aplicações
(RAD), uma vez que este é o um dos principais enfoques do trabalho. É salientada a importância do
uso de padrões de projeto na Seção 2.3, além de enfatizar os conceitos dos frameworks, visto que é
uma das tecnologias utilizadas para desenvolvimento do projeto; a descrição do framework utilizado
(PHPLib-UNIVALI) é realizada na Seção 2.4; e as ferramentas similares pesquisadas são expostas
na Seção 2.5.
2.1. REUSO DE CÓDIGO
Holanda, Souza e Melo (2001 apud BENVENUTTI, 2002), afirmam que muito se tem
discutido sobre reuso de código e informações, devido a crescente importância que tem sido
atribuída a esta solução que se propõe a resolver um grande problema observado em algumas
organizações, o compartilhamento de experiências e informações.
Segundo Peters (2001), no terreno da engenharia de software existem os componentes e os
frameworks. Um componente é uma unidade de software construída e testada para fins especiais, é
útil, adaptável, portável e reutilizável. Para Kiely (1998 apud PETERS, 2001), o principal objetivo
do desenvolvimento de software baseado em componentes é permitir que os desenvolvedores
utilizem mais de uma vez um código escrito em qualquer linguagem e que o mesmo possa ser
executado em qualquer plataforma.
De acordo com Szyperski (1998 apud BRAGA e WERNER, 1999), o desenvolvimento
baseado em componentes está cada vez mais ganhando adeptos e é uma das propostas promissoras
para a melhoria da produção de software nos próximos anos. A construção de software através de
componentes leva a uma maior reutilização e conseqüentemente aumenta a qualidade e a
produtividade, o que enfatiza a crença que esta nova modalidade de desenvolvimento de software
venha a crescer.
A construção de software baseado no uso de componentes reutilizáveis tem por objetivos
reduzir a complexidade, o custo e o tempo de todo o processo de desenvolvimento, bem como
aumentar a confiabilidade dos sistemas produzidos, graças ao uso de componentes previamente
testados (SOUZA, 2000).
De maneira geral, um framework, segundo Peters (2001), é uma combinação de
componentes reutilizáveis que simplifica a construção de aplicações e que pode ser conectado a
uma aplicação.
Souza (2000) afirma que o processo de reutilização consiste em localizar, compreender,
recuperar e modificar componentes pré-existentes. Desta forma, toda uma infra-estrutura capaz de
apoiar as quatro atividades deste processo, dentre outros aspectos, torna-se necessária para o
sucesso do reuso.
2.1.1. Vantagens do reuso de código
Conforme Peters (2001), o objetivo da reutilização de código é aumentar cada vez mais a
produtividade e qualidade de software. Benvenutti (2002) afirma que o reuso de código proporciona
qualidade e produtividade no desenvolvimento e manutenção de software, pois ao utilizar partes de
softwares prontos, não serão necessárias sua digitação, codificação e verificação de erros.
7
Benvenutti (2002), baseada em diversos estudos, relaciona diversas vantagens do reuso de
código. Dentre estas vantagens pode-se citar:
•
Economia de tempo, pesquisa e dinheiro, uma vez que ocorre uma diminuição no
tempo total de desenvolvimento e no número de pessoas necessárias para elaborar
um sistema;
•
Flexibilidade de forma que os desenvolvedores podem combinar, recombinar e
compartilhar componentes para suprir suas necessidades; e
•
Alta qualidade de material, tendo em vista que o código foi já testado e aprovado.
Assim, a probabilidade dos componentes terem um nível de qualidade superior aos
objetos criados fora da idéia de reutilização é muito maior.
2.2. RAD - RAPID APPLICATION DEVELOPMENT
Segundo Jacques (1994), durante as décadas de 70 e 80 as técnicas de desenvolvimento de
software compartilhavam um elemento comum: a abordagem cascata. A idéia era iniciar a análise,
solidificar os requisitos, criar uma especificação de software e então implementar e testar. Jacques
(1994) afirma que este método produzia sistemas mais rapidamente e com menos erros do que
qualquer método previamente aplicado, entretanto, essa vantagem abrangia apenas a perspectiva do
desenvolvedor. Para os gerentes e projetistas de software, a história era completamente diferente.
Jacques (1994) assegura que em meados dos anos 80 estudos mostraram que vários
desenvolvedores adotavam formas de prototipação para demonstrar aos usuários finais como seria o
sistema após o término do processo de desenvolvimento. Sendo assim, Martin (1991 apud
MALCOLM, 2001) propôs o que hoje é conhecido como Rapid Application Development (RAD).
Pode-se dizer que a expressão RAD não é recente. Segundo Martin (1991 apud
MALCOLM, 2001) a mesma surgiu em um disfarce original como “Rapid Iterative Production
Prototyping”, desenvolvida pela Du Pont Organization como um aspecto da Engenharia da
Informação. Com o crescimento da prototipação e das ferramentas de desenvolvimento,
especialmente a expansão da programação visual, o RAD tem ganhado popularidade entre os
desenvolvedores.
8
De acordo com Agarwal et al. (2000), James Martin lançou o termo RAD no início dos anos
90, com o intuito de distinguir a metodologia do tradicional modelo de desenvolvimento de
software Cascata. Agarwal et al. (2000) afirma que RAD refere-se a um ciclo de vida projetado para
fornecer um desenvolvimento muito mais rápido que os tradicionais processos de software, além de
prover resultados de maior qualidade.
Howard (2002) diz que, a promessa básica do paradigma RAD é que uma vez que um
sistema é especificado e projetado, o mesmo pode ser construído e implementado sem maior
remodelagem. O objetivo do RAD é reduzir o tempo entre a determinação dos requisitos e suas
respectivas implementações, diminuindo assim, a probabilidade de mudança (HOWARD, 2002).
O RAD é um ciclo de vida projetado para fornecer desenvolvimento muito mais rápido e
resultados de mais alta qualidade que os alcançados com os tradicionais processos de
desenvolvimento de software (MARTIN, 1991 apud CASEMAKER INC, 2000).
Creegan (1994) afirma que para um projeto de desenvolvimento de software obter sucesso, o
mesmo deve produzir um software de qualidade diante do tempo e orçamento definidos pelo
usuário. Creegan (1994) ainda diz que o RAD suporta este objetivo e que transforma o ciclo de vida
do desenvolvimento de software de um processo “estático” e “orientado a documentação” para um
processo “dinâmico”, “evolucionário”, “interativo” e, segundo Agarwal et al. (2000), “iterativo”.
Existe consenso entre Agarwal et al. (2000) e Jacques (1992) de que existem quatro aspectos
fundamentais para o desenvolvimento rápido de aplicações: (i) ferramentas, (ii) metodologia, (iii)
pessoas e (iv) gerenciamento / planejamento. Desta forma, conforme Agarwal et al. (2000), em um
típico ciclo de vida RAD, as fases de especificação de requisitos e projeto consomem
aproximadamente 30% do tempo total de esforços despendidos.
Para Merlyn (1991) também existem quatro elementos chave para o RAD. Contudo, Merlyn
(1991) classifica-os de uma forma um pouco diferenciada:
1. Reuniões do grupo de trabalho, ou Joint Application Development (JAD): Reuniões
no estilo JAD são componentes importantes em qualquer ciclo de vida de ambientes
CASE (Computer Aided System Engineering). Segundo Brochu (1993), JAD é a
formação de equipes compostas pelos fornecedores dos problemas (clientes) e os
provedores de soluções (desenvolvedores) a fim tomar decisões conjunta sobre o
desenvolvimento do projeto;
9
2. Desenvolvimento Incremental: RAD quebra um projeto em pequenos pedaços que
podem ser analisados, projetados e construídos em poucos meses;
3. Tecnologia CASE: CASE tem adicionado novos estímulos para o movimento JAD.
Com sua ênfase em planejamento, análise e projeto e uma linguagem entendida pelo
usuário e desenvolvedor. CASE fornece um idioma para uma comunicação mais
clara entre desenvolvedor e usuário; e
4. Equipes pequenas: Merlyn (1991) diz que para um projeto RAD devem-se compor
pequenas equipes com pessoas altamente capacitadas e motivadas, já que equipes
pequenas, podem ser muito mais produtivas que equipes grandes.
Embora se tenha passado mais de uma década desde o surgimento do termo RAD, segundo
Agarwal et al. (2000), ainda não existe uma definição universal para o mesmo. Sendo assim, podese caracterizá-lo de duas formas:
•
Uma metodologia que prescreve as fases do desenvolvimento de software (similar
aos fundamentos do modelo espiral e modelo iterativo de construção de software); e
•
Classes de ferramentas que permitem desenvolvimento rápido de objetos e
aplicações, fornecendo interface gráfica com o usuário e proporcionando
reusabilidade e geração de código.
As ferramentas e a metodologia estão fortemente acopladas, uma vez que, as ferramentas
habilitam a metodologia e circunscrevem o que é realizado durante o desenvolvimento de um
projeto. Vale frisar que dentre as classificações do RAD este trabalho se enquadra nas classes de
ferramentas, visto que não se planeja alterar ou incluir novas funcionalidades na metodologia, mas
sim, conceber uma ferramenta atrelada à mesma.
Agarwal et al. (2000) diz que a primeira geração de ferramentas RAD sofria com as
limitações da época, o que não a possibilitava aumentar o nível de produção de aplicações.
Atualmente as ferramentas RAD têm superado essas falhas e proporcionado uma série de
funcionalidades, incluindo características CASE, programação visual, acesso remoto a banco de
dados e suporte a arquiteturas cliente / servidor.
10
2.2.1. Benefícios do RAD
Conforme Martin (1991 apud AGARWAL et al., 2000), a tecnologia RAD incorpora
abordagens diferentes, no que diz respeito a desenvolvimento de sistemas, que as abordagens
dominantes das últimas três décadas. RAD além de incluir iteração sucessiva e refinamento, acelera
o desenvolvimento de protótipos.
Os objetivos da utilização do RAD incluem desenvolvimento mais rápido de software e
sistemas com alto nível de manutenção. Em acréscimo, dado que cada vez mais as ferramentas
RAD incorporam o paradigma de orientação a objetos, os benefícios proporcinados pela
reusabilidade ficam cada vez mais claros.
Segundo Agarwal et al. (2000), os benefícios proporcionados pelas ferramentas RAD são
categorizados em duas classes: (i) benefícios globais, classe que inclui toda produtividade do
desenvolvimento da aplicação, consumo de recursos e gerenciamento do projeto de
desenvolvimento de software; e (ii) resultados específicos, representam valores de nível menor, tais
como, flexibilidade no desenvolvimento da aplicação, redução e reuso de código. Pode-se observar
na Tabela 1 o relacionamento entre o uso das ferramentas RAD e os resultados esperados.
Tabela 1. Benefícios do RAD
Categoria
Benefícios Globais
Resultados específicos
Itens
A ferramenta RAD incrementa a produtividade no
desenvolvimento da aplicação
Um software desenvolvido usando uma ferramenta RAD usa
menos recursos que um desenvolvido utilizando outras
ferramentas de desenvolvimento.
O uso de ferramentas RAD aumenta o planejamento /
gerenciamento de um projeto de desenvolvimento de software.
Com uma ferramenta RAD pode-se desenvolver aplicações de
forma mais rápida do que usando outros tipos de ferramentas.
Uma ferramenta RAD provê um alto nível de flexibilidade no
desenvolvimento de uma aplicação.
O uso de uma ferramenta RAD reduz a quantia de codificação
necessária.
Uma ferramenta RAD ajuda a categorizar e classificar objetos.
Com uma ferramenta RAD o desenvolvimento de aplicação
requer menos trabalho (mão-de-obra).
Uma ferramenta RAD aumenta o reuso de código
Uma ferramenta RAD ajuda a desenvolver aplicações mais
sustentáveis.
Fonte: Adaptado de Agarwal (2000)
11
Desta forma, espera-se com a concretização deste projeto alcançar grande parte dos
benefícios mencionados na classe “resultados específicos” bem como, gerar um código fonte
facilmente entendido pelos desenvolvedores, uma vez que o mesmo baseia-se no framework
PHPLIb-UNIVALI, descrito na Seção 2.4.
2.2.2. RAD X CASE
Além das ferramentas RAD, pode-se dizer que uma ferramenta CASE também acelera o
processo de engenharia de software. Segundo Castilhos (2004), uma ferramenta CASE é uma forma
de padronizar e agilizar a documentação em um processo de software, e quando utilizada
corretamente, acarreta em qualidade e produtividade no desenvolvimento.
Como já citado anteriormente, o RAD apresenta uma abordagem de criação rápida de
aplicativos através de reutilização de código, em contrapartida, o CASE propõe uma abordagem
metodológica em que o software é o produto de uma seqüência racional de passos (DEBONI,
1998).
De acordo com Deboni (1998), as duas abordagens são, aparentemente, divergentes em suas
tentativas de ajuda, entretanto, estas duas classes de ferramentas podem colaborar para que os
projetistas de software tenham um caminho mais seguro e produtivo ao criarem sistemas com
complexidade elevada.
Ainda segundo Deboni (1998), as ferramentas de programação RAD disponibilizam aos
projetistas uma grande quantidade de componentes e um meio eficiente para integrá-los. Desta
forma, pode-se utilizar diretamente o RAD em projetos não muito complexos e com número
relativamente pequeno de usuários. Atualmente deve-se também considerar que a complexidade da
maioria dos sistemas exige que o desenvolvimento seja apoiado por uma ferramenta CASE. Assim,
pode-se desenhar os diagramas representativos de visões do problema, em uma escala progressiva
de detalhe e complexidade, objetivando a criação de uma “planta” da solução que só então será
traduzida em software.
De forma geral, o que garante que um sistema projetado utilizando uma ferramenta CASE
possa ser construído em uma ferramenta RAD é a adoção, por ambas, dos mesmos princípios
básicos de orientação a objetos. Sendo assim, Deboni (1998) afirma que a utilização dos mesmos
conceitos tende a integrar a visão do desenvolvimento de software dada por ambas abordagens.
12
A Tabela 2 demonstra a divisão do RAD e do CASE no ciclo de vida de um software.
Tabela 2. Comparando RAD e CASE
Ferramenta Análise
RAD
Elaboração de
protótipos para
definição dos
requisitos do sistema
Projeto
Teste em protótipos
das opções de
projeto. Projeto das
Interfaces
CASE
Criação e teste de
modelos do
sistema, com o
projeto de uma
solução
Levantamento de
requisitos, criação de
modelos para facilitar
o entendimento do
problema
Construção
Construção da
aplicação
integrando o
código gerado
pelo CASE
Geração da
estrutura do
código do
aplicativo,
especialmente das
regras de negócio
Manutenção
Correção dos
códigos e testes
dos aplicativos
Engenharia
reversa de
aplicativos
criados pela
RAD, ajudando
na documentação
Fonte: Adaptado de Deboni (1998)
Pode-se caracterizar o projeto proposto como uma ferramenta RAD, uma vez que o mesmo
concentra-se em aspectos pertinentes da criação rápida de aplicativos, neste contexto, baseados em
um framework de desenvolvimento de software. É importante frisar que não é concernente a este
projeto gerar nenhuma espécie de documentação ou apoiar-se sobre aspectos metodológicos de
desenvolvimento de software, tendo em vista estas características pertencem às ferramentas CASE.
De certo modo, existe integração da ferramenta RAD proposta neste projeto com algumas
das ferramentas CASE existentes no mercado, uma vez que para iniciar um projeto na ferramenta é
necessário entrar com um arquivo SQL (Structured Query Language) que pode ser, eventualmente,
gerado por uma ferramenta CASE.
2.3. PADRÕES DE PROJETO
Pode-se dizer que projetar um software orientado a objetos é uma tarefa difícil, porém,
segundo Gamma et al. (2000), projetar um software reutilizável orientado a objetos é ainda mais
trabalhoso. Para isto, é necessário encontrar os objetos pertinentes, dividi-los em classes no nível
correto de granularidade, definir as interfaces das classes e suas hierarquias de herança, bem como
estabelecer as relações chave entre as mesmas.
Tendo em vista esta grande complexidade, Gamma (1995 apud CAGNIN et al., 1999)
propõe os padrões de projeto como um novo mecanismo para expressar experiências na elaboração
de projetos orientados a objetos. De acordo com Gamma et al. (2000), estes padrões resolvem
13
problemas específicos e tornam os projetos orientados a objeto mais flexíveis e, em última
instância, reutilizáveis. Tais padrões ajudam os projetistas a reutilizar projetos bem sucedidos ao
basear os novos projetos na experiência anterior.
De forma geral, um padrão de projeto nomeia, abstrai e identifica os aspectos chave de uma
estrutura de projeto comum, a fim de torná-la útil para a criação um projeto orientado a objetos
reutilizável. Um padrão de projeto identifica as classes e instâncias participantes, seus papéis,
colaborações e a distribuição de responsabilidades (GAMMA et al., 2000).
Pode-se classificar um padrão de projetos em quatro princípios fundamentais:
•
Nome do Padrão: Referência utilizada para descrever um problema de projeto, suas
soluções e conseqüências de forma sucinta. O nome torna mais fácil pensar sobre
projetos e comunicá-los, além de criar uma linguagem única entre a equipe;
•
Problema: Descreve quando aplicar o padrão, explicando o problema e seu contexto;
•
Solução: Descreve os elementos que compõem o projeto, seus relacionamentos, suas
responsabilidades e colaborações. A solução não está voltada a uma solução em
particular, pois um padrão pode ser aplicado em muitas situações distintas; e
•
Conseqüências: São os resultados e análises das vantagens e desvantagens da
aplicação do padrão. As conseqüências de um padrão incluem o seu impacto sobre a
flexibilidade, a extensibilidade ou a portabilidade de um sistema.
Conforme Gamma et al. (2000), os padrões de projeto desempenham um papel muito
importante em três grandes classes de software: (i) programas de aplicação; (ii) toolkits; e (iii)
frameworks. Sendo assim, as seções seguintes descrevem, de forma geral, estas três classes de
software, entretanto, enfatiza-se os frameworks, pois trata-se de um conceito abordado neste
trabalho.
2.3.1. Programas de aplicação
Segundo Gamma et al. (2000), para um programa de aplicação (softwares aplicativos) as
prioridades mais altas são reusabilidade interna, facilidade de manutenção e extensão. A
reusabilidade interna garante que não seja implementado mais do que se necessita.
14
A reusabilidade interna pode ser aumentada por padrões de projeto que reduzem
dependências, tendo em vista que um acoplamento mais fraco aumenta a probabilidade de que uma
classe possa cooperar com várias outras. Os padrões de projeto também tornam uma aplicação mais
fácil de ser mantida e melhoram a facilidade de extensão.
2.3.2. Toolkits
Para Gamma et al. (2000), um toolkit (biblioteca de classes) é um conjunto de classes
relacionadas e reutilizáveis, projetadas para fornecer uma funcionalidade útil e de finalidade geral.
Os toolkits não impõem um projeto específico à sua aplicação; simplesmente fornecem
funcionalidades que podem auxiliar a aplicação a executar o seu trabalho, desta forma evitam a
recodificação. De forma geral os toolkits são equivalentes em orientação a objetos a bibliotecas de
sub-rotinas.
2.3.3. Frameworks
Um framework é um conjunto de classes que representam um projeto abstrato para soluções
de uma família de problemas relacionados (JOHNSON e FOOTE, 1988 apud BOSCH et al., 1999).
Conforme mencionado na Seção 2.1, segundo Peters (2001) um framework, ou arcabouço de
classe, é uma combinação de componentes reutilizáveis que simplifica a construção de aplicações e
que pode ser conectado a uma aplicação.
Gabriel (1996 apud PARSONS, RASHID e SPECK, 1999) define framework como um
sistema que pode ser customizado, especializado, ou estendido para prover capacidades mais
específicas, mais apropriadas ou ligeiramente diferentes.
Gamma et al. (2000) provê uma definição mais abrangente, para ele um framework é
definido como um conjunto de classes cooperantes que constroem um projeto reutilizável para uma
específica classe de software. Um framework é customizado para uma aplicação peculiar através de
subclasses específicas da aplicação, sendo essas subclasses herdadas das classes abstratas do
framework. Desta forma, um framework prescreve a arquitetura da aplicação, define a estrutura
geral e sua divisão em classes e objetos e, conseqüentemente, as responsabilidades chave das
classes de objetos, como estas colaboram e o fluxo de controle.
15
Segundo Parsons, Rashid e Speck (1999), um framework consiste em dois pontos: (i) ponto
gelado - frozen spots - ou insensível (fragmentos do software já codificados para serem
reutilizados); e (ii) ponto quente - hot spots (elementos flexíveis, permitindo aos usuários ajustar o
código de acordo com a necessidade da aplicação). Diferente da maioria das bibliotecas de classes,
os frameworks encapsulam o controle de fluxo, bem como a interface dos objetos, modelando
assim, o comportamento dinâmico do sistema e sua estrutura.
Um framework captura as decisões do projeto que são comuns ao seu domínio de aplicação.
Assim, os frameworks enfatizam a reutilização de projetos em relação à reutilização de código,
embora um framework, geralmente, possua subclasses concretas que podem ser utilizadas
prontamente (GAMMA et al., 2000).
Gamma et al. (2000) ainda afirma que enfatizar a reutilização de projetos leva a uma
inversão de controle entre a aplicação e o software sobre a qual esta está baseada. Quando usa-se
um framework reutiliza-se o corpo principal, e escreve-se o código que este chama. Desta forma, é
necessário escrever operações com nomes e convenções de chamada já especificadas; porém isso
reduz as decisões de projeto. Um exemplo amplamente utilizado é o .NET Framework que, segundo
Msdn (2005), possui recursos para criação de aplicações web, desktop, móvel e Web Services.
Como resultado, pode-se não somente construir aplicações mais rapidamente, mas também
com estruturas similares, tornando-as mais fáceis de serem mantidas e mais consistentes para os
usuários. Em contrapartida, perde-se liberdade uma vez que muitas decisões do projeto foram
tomadas no momento de concepção do framework.
2.3.3.1. Evolução dos frameworks
Segundo Bosch et al. (1999) os frameworks tiveram suas origens com o ambiente Smalltalk
e Apple Inc. Entretanto, somente a partir de 1992 com o surgimento da empresa Taligent, que os
frameworks começaram a despertar os interesses das grandes corporações. A intenção da Taligent
era desenvolver um sistema operacional baseado totalmente no conceito de frameworks orientado a
objetos. Desta forma, a agência desenvolveu um conjunto de ferramentas RAD com o nome de
CommonPoint, que consistia em mais de uma centena de frameworks.
Em um contexto geral, pode-se dizer que os frameworks orientados a objetos passaram por
várias mudanças desde suas primeiras versões. Robersts & Johnson (1996 apud BOSCH et al.,
16
1999), descrevem a evolução de um framework em dois processos distintos: (i) caixa-branca; e (ii)
caixa-preta, detalhados na Seção 2.3.3.2. Bosch et al. (1999) afirma que a evolução está presente
como uma linguagem padrão, que descreve o processo desde o projeto inicial de um framework
como um framework de caixa-branca, até um framework de caixa-preta.
2.3.3.2. Elementos flexíveis dos frameworks
Parsons, Rashid e Speck (1999), baseados em características de customização, dividem os
frameworks em duas categorias principais:
•
Frameworks de Caixa Branca: As aplicações geradas são adaptadas a partir de um
conjunto de classes padrão, obrigando os desenvolvedores de aplicações e
componentes a conhecerem a arquitetura do framework. Desta forma, a utilização do
mesmo é geralmente limitada à operação de herança, conforme apresenta a Figura 1
(a). Segundo Gamma et al. (2000), termo “caixa branca” refere-se à visibilidade,
uma vez que com a operação de herança, os interiores das classes ancestrais são
freqüentemente visíveis para as subclasses; e
•
Frameworks de Caixa Preta: Em oposição, os frameworks de caixa preta escondem
sua estrutura interna. Diferente dos frameworks de caixa branca, para utilizá-lo os
usuários devem apenas conhecer uma descrição geral framework. O mecanismo de
hot spots é geralmente a operação de composição, como expõe a Figura 1 (b).
(a)
(b)
Figura 1. Elementos flexíveis em frameworks: (a) Caixa branca; (b) Caixa Preta
Fonte: Adaptado de Parsons (1999)
17
Gamma et al. (2000) afirma que, tanto a utilização de herança (caixa branca), quanto
composição (caixa preta) abrangem vantagens e desvantagens. A herança de classes é definida
estaticamente e é simples de usar, em contrapartida, não se pode mudar as implementações herdadas
das classes ascendentes em tempo de execução e as classes ancestrais freqüentemente definem pelo
menos parte da representação física das suas subclasses.
A composição de objetos é definida dinamicamente em tempo de execução pela obtenção de
referências para outros objetos por um determinado objeto. A composição exige que os objetos
respeitem as interfaces uns dos outros, o que requer interfaces cuidadosamente projetadas.
Entretanto, a vantagem é que os objetos são acessados exclusivamente através de suas interfaces,
não transgredindo o encapsulamento.
Segundo Parsons, Rashid e Speck (1999), na prática existem poucos frameworks de caixa
branca ou caixa preta puros, mas sim, existe uma combinação de ambos na maioria dos hot spots.
Parsons, Rashid e Speck (1999) ainda afirmam que os frameworks tendem a amadurecer neste
processo, iniciando como caixa branca e envolvendo frameworks de caixa preta.
2.3.3.3. Ciclo de vida de um framework
De acordo com Bosch et al. (1999), a presença de frameworks reutilizáveis influencia
fortemente no processo de desenvolvimento de uma aplicação. Bosch et al. (1999) ainda elenca três
fases no desenvolvimento de software centrado em frameworks.
•
Desenvolvimento do Framework: Esta é a fase que, freqüentemente, despende mais
esforços. O seu objetivo é conceber um projeto reutilizável de software em um
domínio específico;
•
Uso do Framework: Também conhecida como fase de desenvolvimento de
aplicação, seu principal objetivo é desenvolver uma aplicação utilizando um ou mais
frameworks; e
•
Evolução e Manutenção do Framework: Como todo software, os frameworks estão
sujeitos a mudanças, causadas por erros, inclusão de novas funcionalidades, etc. A
fase de manutenção dedica-se a identificar as mudanças e manter o framework.
18
A Tabela 3 demonstra as fases, as pessoas e os artefatos envolvidos no ciclo de vida de um
framework.
Tabela 3. Ciclo de vida de um framework
Fase
Desenvolvimento do
Framework
Uso do Framework
Manutenção e Evolução do
Framework
Pessoas envolvidas
Engenheiros de Software e
programadores
desenvolvedores do
Framework
Programadores usuários do
Framework 1
Responsáveis pela
identificação e manutenção
de erros e melhorias
Artefatos de Software envolvidos
Projeto do Núcleo do Framework
Incrementos internos
Núcleo do Framework
Incrementos Internos
Incrementos da Aplicação específica
Núcleo do Framework
Incrementos do Framework
Fonte: Adaptado de Bosch et al. (1999)
2.4. FRAMEWORK PHPLIB-UNIVALI
Pode-se encontrar em SourceForge (2005) a versão 2.0 do framework PHPLib-UNIVALI,
entretanto, o material disponível no site não é a mesmo utilizada neste projeto. A versão do
framework a ser usada é disponibilizada pelo setor de Tecnologia da Informação (TI) da
Universidade do Vale do Itajaí (UNIVALI) e é base de grande parte dos sistemas web
desenvolvidos pelo setor, bem como por seus núcleos de desenvolvimento internos e externos.
O framework PHPLib-UNIVALI teve seu projeto inicial concebido pelo professor Rodrigo
Becke Cabral no ano de 2003, desde então, vem sendo mantido por alunos, professores e
funcionários da UNIVALI. No entanto, o mesmo não possui nenhum tipo de documentação, ficando
por encargo deste projeto gerar uma documentação básica a fim de entender seus conceitos e
funcionalidades. Cabe ressaltar que o intuito deste trabalho não é documentar o framework, mas sim
utilizá-lo. Toda documentação aqui apresentada foi desenvolvida com a finalidade de melhor
entender suas funcionalidades.
Conforme aludido na Seção 2.3.3.2, os frameworks possuem duas formas de caracterização:
(i) caixa branca; e (ii) caixa preta. Desta forma, pode-se caracterizar o framework PHPLibUNIVALI como caixa branca, uma vez que o relacionamento entre suas classes e as aplicações que
as utilizam limitam-se à operação de herança. Todavia, o mesmo abrange um conjunto de arquivos
1
Também conhecidos como “framework reuser” ou desenvolvedores de aplicação.
19
de funções que podem ser agregadas às aplicações, o que descaracteriza-o totalmente como
framework de caixa branca, vindo de encontro à afirmação de Parsons, Rashid e Speck, que existem
poucos frameworks puros.
A Figura 2 demonstra o relacionamento entre as aplicações e o framework PHPLibUNIVALI através de estereótipos do diagrama de pacotes da UML (Unified Modeling Language).
Figura 2. Relacionamento entre aplicações e framework PHPLib-UNIVALI
Os itens abaixo descrevem, de forma sucinta, a importância de cada pacote apresentado na
Figura 2.
•
PHPLib-UNIVALI-Func: é um grupo de arquivos de funções que se agregam ao
framework PHPLib-UNIVALI e podem, eventualmente, compor as aplicações que o
utilizam como alicerce. Embora estes arquivos façam parte do framework e não
ditem a arquitetura da aplicação, os mesmos não podem ser considerados um toolkit,
uma vez que não apresentam nenhuma característica de orientação a objetos. Estes
são apenas funções estruturadas e reutilizáveis dentro do framework, podendo ser
conceitualmente definidos como bibliotecas de sub-rotinas. A Figura 3 apresenta
detalhadamente o grupo de arquivos de funções bem como, esclarece o objetivo de
cada um dentro do framework;
20
•
framework PHPLib-UNIVALI: é o alicerce do PHPLib-UNIVALI. Este pacote
contêm um conjunto de 8 classes co-relacionadas, conforme apresenta a Figura 4,
que ditam a arquitetura, definem a estrutura geral e as responsabilidades de cada um
dos objetos dentro da aplicação; e
•
Aplicação: é o sistema utilizado pelos usuários finais. Este pacote herda todas
características do framework PHPLib-UNIVALI. Sendo assim, vale enfatizar que o
principal objetivo deste projeto é gerar o pacote “Aplicação” customizado pelo
usuário através das configurações realizadas ao decorrer do uso do sistema proposto.
Figura 3. Arquivos de funções do framework PHPLib-UNIVALI
A Figura 4 apresenta o diagrama lógico do framework PHPLib-UNIVALI, no entanto, vale
destacar que, devido ao fraco encapsulamento dos atributos e métodos fornecido pela orientação a
objetos da linguagem PHP 4 (versão que o framework foi desenvolvido), os relacionamentos de
agregação que aparecem no modelo não existiam. Estes foram incluídos neste projeto a fim de
construir uma modelagem conceitual correta do framework.
Sendo assim, o código gerado pela ferramenta RAD proposta leva em consideração estes
relacionamentos, no entanto, isto não acarreta em nenhum tipo de incompatibilidade por parte dos
sistemas já desenvolvidos baseados no framework em questão.
21
Figura 4. Diagrama lógico do framework PHPLib-UNIVALI
Devido ao grande número de atributos e métodos, o dicionário de dados de cada uma das
classes do framework PHPLib-UNIVALI é apresentado no Apêndice A.
22
2.4.1. Elementos flexíveis do framework PHPLib-UNIVALI
De acordo com Parsons, Rashid e Speck (1999) e conforme mencionado na Seção 2.3.3 um
framework consiste em dois pontos: (i) frozen spots, que são fragmentos do software já codificados
para serem reutilizados; e (ii) hot spots, que são elementos flexíveis que permitem aos usuários
ajustar o código de acordo com a necessidade da aplicação.
Os artefatos já codificados e fornecidos pelo framework PHPLib-UNIVALI são os frozen
spots, onde se impõe a arquitetura da aplicação e define-se as propriedades, métodos e
relacionamento entre as classes. A Figura 5, apresenta um exemplo de código-fonte do framework
para melhor entendimento.
class
{
var
var
var
var
var
formCadastro extends formbase
$largura;
$tipoacao;
$campos;
$erros;
$mensagem;
...
function Inicializar() {}
function Formular() {}
function Novo()
{
return false;
}
...
}
Figura 5. Exemplo de código do framework PHPLib-UNIVALI (frozen-spot)
Analisando detalhadamente a Figura 5, pode-se perceber que os métodos estão apenas
definidos ou apresentam um pequeno trecho de código padrão, no entanto, não realizam nenhuma
ação em específico. Desta forma observa-se o frozen-spot do framework, isto é, a definição da
arquitetura da aplicação.
Este projeto propõe gerar, baseado na solução existente, o hot-spot do framework. O códigofonte é gerado a partir das configurações fornecidas pelo usuário através da ferramenta RAD. A
Figura 6 demonstra um exemplo do hot-spot do framework PHPLib-UNIVALI.
23
class formNomeCadastro extends formCadastro
{
var cam_id;
var cam_nome;
var cam_data;
...
function Inicializar()
{
return “Novo”;
}
function Formular()
{
# Tratamento para aspas
foreach( $this as $chave => $valor)
if(substr($chave,0,3) == "cam")
{
$this->$chave = @$_POST[$chave] ? stripslashes(@$_POST[$chave])
: stripslashes("$valor");
}
$this->campoOculto("cam_id", $this->fer );
$this->campoTexto("cam_nome", "Nome", $this-> cam_nome, "30", "30", true );
$this->campoRotulo("cam_data", "Data", $this->cam_data );
}
function Novo()
{
if ($this->erros)
{
return false;
}
# insere na tabela.
...
return true;
}
...
}
Figura 6. Exemplo de código hot-spot do framework PHPLib-UNIVALI
O código-fonte interno aos métodos é o hot-spot do framework, e atualmente é gerado
manualmente pelos programadores que utilizam o framework. Espera-se através desse projeto,
automatizar esta geração, conseqüentemente, acelerando o processo de desenvolvimento dos
sistemas.
2.5. SOLUÇÕES SIMILARES
As seções seguintes apresentam algumas ferramentas pesquisadas durante a realização deste
projeto. A pesquisa destas ferramentas tem como objetivo fornecer subsídios para o
24
desenvolvimento da solução proposta neste TCC, intitulado de RADPHP (Rapid Application
Development Hypertext Preprocessor).
2.5.1. Geração automática de cadastros e consultas para linguagem ASP baseado
em banco de dados
Esta solução é caracterizada como trabalho de conclusão de curso de Ciência da
Computação e, de acordo com Silveira (2003), é uma ferramenta com o intuito de auxiliar o
desenvolvedor na criação automática de um sistema de cadastros e consultas na plataforma Web.
Para isto, a ferramenta utiliza linguagem ASP (Active Server Pages) e baseia-se na estrutura de
campos e relacionamentos do banco de dados.
De forma geral, a ferramenta apresentada por Silveira (2003) objetiva automatizar a geração
de inclusões, alterações, exclusões e consultas no banco de dados. Pode-se observar parte da
interface da ferramenta na Figura 7.
Figura 7. Tela exemplo da ferramenta proposta por Silveira (2003)
Fonte: Silveira (2003)
25
Após a configuração das informações pelos desenvolvedores, a ferramenta gera as páginas
em formato ASP.
2.5.2. NETSIS - ferramenta CASE para geração de páginas ASP
Da mesma forma que o trabalho apresentado na Seção 2.5.1, este projeto também
caracteriza-se como TCC do curso de Ciência da Computação e é de autoria de Castilhos (2004).
Segundo Castilhos (2004), o trabalho é voltado ao desenvolvimento de uma ferramenta
CASE direcionada para o auxílio de programadores e analistas de sistemas para definição e
especificações do projeto e geração de código para aplicativos web, tendo assim por finalidade
principal agilizar a criação de aplicativos de cadastros reduzindo custos e ganhando tempo.
As aplicações produzidas pela ferramenta são baseadas na linguagem de programação ASP e
suportadas pelos bancos de dados Access e SQL Server. Além da aplicação, a ferramenta propõe-se
a gerar a estrutura do banco de dados, bem como seu dicionário de dados.
A Figura 8 apresenta a interface da ferramenta NETSIS, mostrando o menu principal do
software.
Figura 8. Interface exemplo da ferramenta NETSIS
Fonte: Castilhos (2004)
26
2.5.3. Polar Studio
Blue Polar (2004, tradução do autor) define Polar Studio como: “Ambiente de
desenvolvimento rápido de aplicações (RAD) destinado a criar aplicações comerciais baseadas na
web de alta qualidade em tempo recorde”.
O Polar Studio é um IDE (Integrated Development Environment - Ambiente de
Desenvolvimento Integrado), concebido pela empresa Blue Polar, e pode ser adquirido em Blue
Polar (2004) por 495,00 dólares. Com o objetivo de criar aplicações baseadas 100% em tecnologias
web de forma rápida, o Polar Studio tem seu próprio conceito, onde as aplicações são modeladas
diretamente no seu “repositório de aplicações” e são acessíveis via XML (Extensive Markup
Language). A partir da modelagem da aplicação, o gerador de páginas da ferramenta, que funciona
no servidor, gera o HTML (Hypertext Markup Language) que é visualizado pelo usuário.
Desta forma, a aplicação criada é processada no servidor sobre o IIS (Internet Information
Server) e o acesso aos dados ocorre através do servidor polar. A Figura 9 apresenta a arquitetura do
Polar Studio.
Figura 9. Arquitetura da Ferramenta Polar Studio
Fonte: Adaptado de Blue Polar (2004)
27
É importante considerar que a IDE do Polar Studio tem seu próprio servidor web
(WebServer) para testes imediatos. Assim, não existe a necessidade os ter, de fato, um WebServer
instalado para testar a construção da aplicação.
A Figura 10 apresenta a interface do IDE do Polar Studio.
Figura 10. IDE da Ferramenta Polar Studio
Fonte: Blue Polar (2004)
2.5.4. Análise comparativa entre as soluções pesquisadas
De forma geral, tanto as ferramentas geradas em meio acadêmico (trabalhos de conclusão de
curso de Silveira (2003) e Castilhos (2004)) quanto as comerciais (Blue Polar (2004)) apresentam
praticamente as mesmas funcionalidades no que diz respeito à manipulação de dados. Um único
item não existente na ferramenta de Castilhos (2004) que consiste no detalhe de dados.
A Tabela 4 apresenta os detalhes da comparação da ferramenta RADPHP (proposta neste
trabalho) com as soluções pesquisadas.
28
Tabela 4. Comparação das ferramentas pesquisadas com a ferramenta proposta
Descrição
Utiliza Framework
Não intervenção do desenvolvedor
Inserção de Dados
Edição de Dados
Exclusão de Dados
Listagem dos Dados
Detalhes dos Dados
Paginação em Listagens
Gera estrutura a partir de leitura do
Banco de dados
Gera estrutura a partir de leitura de
arquivo SQL
Criação Banco de Dados
Estrutura da ferramenta em XML2
Linguagem de geração
RADPHP
X
X
X
X
X
X
X
X
SILVEIRA
NETSIS
X
X
X
X
X
X
X
X
X
X
X
POLAR STUDIO
X
X
X
X
X
X
X
X
X
X
X
PHP
X
X
ASP
ASP
ASP
Observando a Tabela 4, pode-se dizer que um grande e importante diferencial existente na
ferramenta RADPHP, não encontrado em nenhuma das ferramentas pesquisadas, é a utilização de
um framework. Desta forma, os desenvolvedores podem realizar qualquer eventual modificação
facilmente, tendo em vista que o código gerado segue um padrão de desenvolvimento simples e
compreensível. Outra característica relevante, é o fato de todas as configurações realizadas pelo
usuário, estrutura da ferramenta e informações sobre a estrutura do banco de dados utilizado na
aplicação, serem armazenadas em arquivo (formato XML), garantindo desta forma, a portabilidade
dos projetos criados. Sendo assim, o único pré-requisito é ter a ferramenta instalada.
Percebe-se também, através da Tabela 4, que a única solução que concentra seus esforços
na geração de código PHP é o RADPHP. Pode-se desta forma, considerar esta particularidade como
um grande diferencial, uma vez que o PHP é uma linguagem gratuita e disponível a toda e qualquer
pessoa.
2.6. TECNOLOGIAS UTILIZADAS
Para a elaboração deste projeto e sua caracterização como trabalho de conclusão de curso,
faz-se necessário a utilização de diferentes tipos de tecnologias, cada qual com sua particularidade.
Dentre as tecnologias utilizadas vale ressaltar o uso de uma das etapas do processo de
compilação; a análise. O processo de análise consiste, segundo Gesser (2003) em examinar o código
2
Refere-se a forma de armazenamento dos dados do projeto.
29
fonte de um programa e extrair as informações relevantes para o preenchimento das estruturas de
dados utilizadas na etapa de síntese3.
A etapa de análise é subdividida em três fases: (i) análise léxica; (ii) análise sintática; e (iii)
análise semântica. É importante frisar que para o desenvolvimento desta etapa - neste projeto – é
utilizada a ferramenta GALS (Gerador de Analisadores Léxicos e Sintáticos), proposta por Gesser
(2003), que produz como resultado final os analisadores léxico e sintático, sendo de intuito deste
projeto o desenvolvimento de um analisador semântico. A Seção 2.6.1 expõe as características e as
funcionalidades da ferramenta GALS.
A Seção 2.6.2 aborda tecnologias referentes a especificação e validação de documentos
XML, tais como, DTD (Document Type Definition) e XML Schema. Considera-se importante
abordar este assunto, pois, a proposta de desenvolvimento da ferramenta (Capítulo 3) não utiliza
banco de dados e sim documentos XML para o armazenamento de dados.
2.6.1. GALS – gerador de analisadores léxicos e sintáticos
Segundo Gesser (2003), o GALS é uma ferramenta que tem o intuito de gerar
automaticamente analisadores léxicos e sintáticos, através de especificações léxicas, baseadas em
expressões regulares, e especificações sintáticas, baseadas em gramáticas livres de contexto.
Gesser (2003) afirma que o GALS tenta fornecer um ambiente amigável – que pode ser
empregado para o uso didático ou profissional – e de interface simples, onde podem ser
especificados aspectos de analisadores léxicos e sintáticos. O GALS fornece uma gama de
funcionalidades, dentre estas se pode citar:
•
Configuração: Interface para definir as opções de projeto, como linguagem objeto,
técnica empregada para o analisador sintático, nomes de classes;
•
Simulador: Permite testar os analisadores antes de gerar o código fonte; e
•
Documentação: Exibe documentação em formato HTML com as tabelas geradas
para os analisadores léxico e sintático.
3
A compilação de um programa é dividida em duas etapas: (i) análise; e (ii) síntese. No entanto, para realização deste
projeto é utilizada somente a etapa (i).
30
Para geração do analisador léxico devem ser declarados tokens, que são reconhecidos
através de expressões regulares. Estes tokens podem ser declarados de diferentes formas: através de
um identificador e uma expressão regular (seqüência de caracteres entre aspas) ou pela identificação
de um token como caso particular de um outro já declarado.
A especificação sintática dá-se através de uma gramática de livre contexto, existindo ainda a
possibilidade de inserção de ações semânticas (opção esta utilizada neste projeto), de modo que seja
possível realizar uma posterior análise semântica por meio de uma tradução dirigida pela sintaxe.
Ao término da especificação da linguagem, é gerado um conjunto de classes e tabelas. As
classes geradas compreendem os analisadores léxico, sintático e semântico, bem como classes
auxiliares e de exceções. É de extrema importância destacar que a classe para o analisador
semântico não possui nenhum tipo de implementação, mas sim, a interface que o analisador
sintático espera. Como já mencionado na Seção 2.6, a implementação do analisador semântico é
compreendida neste projeto.
2.6.2. XML - Extensive Markup Language
Segundo Tesch Jr. (2002), a intensificação do uso dos computadores e o crescimento da
complexidade do nível de manipulação e compartilhamento de informações, foram os fatores
precursores para o surgimento das linguagens de marcação.
Para Tesch Jr. (2002), as linguagens de marcação foram concebidas com intuito de
minimizar os problemas de transferência de um formato de representação para um outro. Tais
linguagens têm o objetivo de organizar e estruturar o conteúdo de um documento de um modo
diferente de sua forma de exibição. Pode-se enumerar diversas linguagens de marcação, tais como o
SGML (Standard Generalized Markup Language) e o HTML, no entanto, esta seção enfatiza
aspectos pertinentes ao XML, uma vez que é uma das tecnologias utilizadas para o
desenvolvimento deste trabalho.
Segundo McGrath (1999 apud VARGAS, 2004), XML é uma abordagem padronizada para
que informações sejam descritas, armazenadas, processadas e publicadas eletronicamente. Em
contrapartida, Tittel (2003 apud KOKUBO, 2004), não considera o XML como uma linguagem de
descrição de dados, mas sim, uma metalinguagem projetada para descrever outras linguagens de
marcação.
31
Embora não exista consenso entre as definições, pode-se dizer que todas convergem para a
mesma vertente e acabam complementando-se. Assim, pode-se dizer que XML é uma linguagem de
marcação extensiva e autodescritiva e que permite a criação de padrões com elementos atributos
pré-definidos. A Figura 11 apresenta um exemplo simplório de um documento XML.
<fonte>
<tipo>Arial</tipo>
<tamanho>10</ tamanho>
<cor>Vermelho</cor>
<estilo>Negrito</estilo>
<estilo>Itálico</estilo>
<estilo>Sublinhado</estilo>
<alinhamento>Centralizado</alinhamento>
<efeito>Nenhum</efeito>
</fonte>
Figura 11. Exemplo de um documento XML
2.6.2.1. Especificação de documentos XML
Segundo W3C (2005) o W3C (World Wide Web Consortium - Comitê Organizador da Web)
é uma organização fundada em outubro de 1994 com o intento de desenvolver diretrizes e
protocolos que asseguram o crescimento da Web em longo prazo, bem como fornecer padrões para
as linguagens que se propõem a fornecer informações aos usuários da Web. Desta forma, o W3C
estabelece os padrões de formulação do XML.
Conforme Kirk (2000), o fato de existir apenas um órgão gestor decidindo como a
linguagem deve evoluir, cria um padrão no qual os desenvolvedores de software podem utilizar
tranqüilamente.
Além de ser uma linguagem com padrão pré-estabelecidos e formulados pela W3C, o XML,
segundo Kirk (2000) fornece ao desenvolvedor a possibilidade de criar seus próprios conjuntos de
elementos e atributos; e até mesmo suas próprias entidades. Tesch Jr. (2002) diz que toda essa
flexibilidade, faz com que seus tipos de vocabulários (ou componentes XML) possam ser criados
como padrões para tipos de funções Web e até mesmo outros tipos de aplicações.
Outro aspecto que deve ser amplamente considerado é a portabilidade dos documentos
XML. Um documento XML pode armazenar informações relacionadas em apenas um arquivo, o
que facilita a comunicação com outros sistemas, e até mesmo a alteração do conteúdo desejado.
Tendo isso em vista, esse projeto propõe-se a utilizar documentos XML para armazenar a estrutura
32
de dados do sistema e suas informações. Desta forma, não existe a necessidade de armazenar estas
informações em qualquer tipo de banco de dados.
Muito se aborda a respeito das vantagens do XML, entretanto, Castro (2001 apud TESCH
JR, 2002) afirma que o XML, em si, é relativamente simples. No entanto, o que o torna poderoso
são as tecnologias empregadas juntamente com a linguagem, e, dentre estas tecnologias pode-se
destacar a validação dos documentos XML.
Existem duas classificações para os documentos XML: (i) documentos bem formados; e (ii)
documentos válidos. Os documentos bem formados têm como única característica as regras de
sintaxe determinadas pela W3C relativas aos documentos XML. Já os documentos válidos possuem
sua estrutura definida formalmente através de uma DTD ou um XML Schema. A utilização de tais
estruturas com o intuito de validar os documentos XML é de grande valia, pois garantem a
integridade da informação na aplicação.
2.6.2.1.1. DTD - Document Type Definition
Uma DTD é a base a partir da qual os documentos XML são criados. Para Kirk (2000), uma
DTD define as partes de um documento e descreve como estes podem ser utilizados. Também é de
responsabilidade de uma DTD determinar o que pode ser aplicado na parte interna do documento e
se seus elementos são obrigatórios.
De forma geral, uma DTD é um conjunto de regras que define as instruções que serão
enviadas ao analisador sintático para o documento que está para ser analisado (KIRK, 2000).
Assim, pode-se saber se um documento XML está sintaticamente correto.
Tesch Jr (2002) afirma que uma DTD pode incluir um grupo de declarações de elementos e
de atributos, bem como as entidades, notações e comentários que poderão ser utilizados em um
documento. Na Figura 12 pode-se observar um exemplo de uma DTD.
<?xml version="1.0" encoding="iso-8859-1"?>
<!ELEMENT fonte (tipo+, tamanho, cor?, estilo*, alinhamento*, efeito*)>
<!ELEMENT tipo (#PCDATA)>
<!ELEMENT tamanho (#PCDATA)>
<!ELEMENT cor (#PCDATA)>
<!ELEMENT estilo (#PCDATA)>
<!ELEMENT alinhamento (#PCDATA)>
<!ELEMENT efeito (#PCDATA)>
<!ELEMENT tamanho “10”)>
Figura 12. Exemplo de um documento DTD
33
KIRK (2000 apud Kokubo, 2004) afirma que as DTDs podem ser classificadas de duas
formas: (i) interna, onde documentos só podem ser auto-suficientes se a DTD estiver no próprio
documento; e (ii) externa, onde a DTD localiza-se em um arquivo externo, que pode ser acessado
localmente ou através de uma URL (Uniform Resource Locator).
2.6.2.1.2. XML Schema
Castro (2001 apud TESCH JR, 2002) diz que é importante enfatizar que, esquema é o nome
dado aos documentos gerados com o objetivo de definir o conteúdo dos documentos XML. Desta
forma, tanto o DTD quanto o XML Schema são considerados esquemas.
Conforme Maia (2005) o XML Schema – também chamado de XML Schema Definition
(XSD) - foi originalmente proposto pela Microsoft, e, segundo Tesch Jr (2002), foi aprovado como
padrão pelo W3C em março de 2001.
Para Tesch Jr (2002), o XML Schema possui essencialmente a mesma função de uma DTD.
Assim, o XML Schema define como determinado conjunto de um ou mais documentos XML
devem ser construídos, quais elementos eles podem ou devem conter e ainda em que ordem os
mesmos devem ser dispostos. Também é intuito do XML Schema definir os atributos dos elementos
e qual será seu tipo de conteúdo.
Segundo Maia (2005), de forma geral, o XML Schema tem a intenção de fixar os “blocos de
construção” permitidos em um documento XML. Desta forma, um XML Schema define:
•
Elementos e atributos que podem aparecer em um documento;
•
Que elementos são elementos filhos;
•
A ordem dos elementos filhos;
•
O número de elementos filhos;
•
Se um elemento pode ser nulo;
•
Tipos de dados para elementos e atributos; e
•
Valores padrão e fixos para elementos e atributos.
34
A Figura 13 apresenta um exemplo de um documento XML Schema.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="fonte">
<xs:complexType>
<xs:sequence>
<xs:element name="tipo" type="xs:string" maxOccurs="unbounded"/>
<xs:element name="tamanho" type="xs:double" default="10"/>
<xs:element name="cor" type="xs:string" minOccurs="0"/>
<xs:element name="estilo" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="alinhamento" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="efeito" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Figura 13. Exemplo de um documento XML Schema.
2.6.2.1.3. Análise comparativa DTD e XML Schema
Conforme mencionado nas seções anteriores, tanto a DTD quanto o XML Schema têm o
intuito de definir a estrutura de um documento XML.
Pode-se dizer que as DTDs são utilizadas de forma intensa, no entanto Anderson et al. (2001
apud VARGAS, 2004) enumera uma série de limitações da tecnologia:
1. Linguagem proprietária, o que causa certa complexidade para o desenvolvedor;
2. Para integração entre DTDs, é necessário a utilização de um mecanismo chamado
namespace. Os namespaces têm a função de evitar ambigüidades, no entanto,
dificultam a construção das DTDs; e
3. Os tipos de dados, em sua grande maioria, restringem-se aos tipos “PCDATA” e
“CDATA”.
Segundo Anderson (2001, apud TESCH JR, 2002), o XML Schema é uma linguagem
alternativa para desenvolvimento de esquemas, com o objetivo de suprir os problemas e outras
dependências referentes às DTDs.
35
Castro (2001 apud TESCH JR, 2002) afirma que o XML Schema tem diversas vantagens em
relação ao DTD. Os documentos XML Schema são escritos a partir de uma sintaxe XML, sendo
assim, eles podem ser analisados através parsers (analisadores gramaticais) XML. Em
contrapartida, em uma DTD todas as declarações são globais, o que impossibilita a definição de
dois documentos com o mesmo nome, mesmo que eles estejam em contextos diferentes. Para
Fornari (2003 apud VARGAS, 2004), as principais vantagens do XML Schema sobre a DTD são:
•
Possui 41 tipos de dados diferentes;
•
Permite criar novos tipos de dados;
•
Permite criar uma hierarquia de objetos com herança de características;
•
Permite que características herdadas sejam estendidas ou restringidas;
•
Possui o conceito de conjuntos, onde a ordem dos elementos não é importante; e
•
Permite valores nulos.
Schmitt Filho (2002 apud VARGAS, 2004) afirma que mesmo sendo mais poderoso que as
DTDs o XML Schema possui, alguns problemas:
•
Necessita de outras informações, além do elemento raiz, para torná-lo válido,
contrariando as especificações de boa-formação do XML;
•
Não é 100% autodescritivo pelo fato de contrariar a boa-formação exigida pelo
padrão XML; e
•
A notação de tipos causa maior complexidade para o desenvolvimento dos
documentos.
Embora o XML Schema ainda apresente alguns problemas, seus benefícios são maiores em
relação aos fornecidos pelas DTDs. Segundo Maia (2005), o XML Schema tornou-se uma
recomendação oficial do W3C em Maio de 2001. Sendo assim, a proposta deste projeto utiliza
XML Schema para definir toda a estrutura XML do sistema.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
36
3. PROJETO
Nesta seção são enfatizadas características concernentes à modelagem do sistema proposto.
Para isso, referencia-se alguns diagramas da linguagem UML. Também é utilizado XML Schema
para definição dos documentos XML utilizados no armazenamento de informações da ferramenta.
Sendo assim, as seções subseqüentes apresentam as regras de negócio e a definição dos
requisitos funcionais e não funcionais, a especificação do diagrama de casos de uso, o diagrama de
classes do sistema e o XML Schema.
3.1. DEFINIÇÃO DOS REQUISITOS E REGRAS DE NEGÓCIO
É de extrema importância definir as regras de negócio e antever as funções que são
incorporadas em um sistema antes de iniciar efetivamente sua implementação. Dessa forma, esta
seção descreve as regras de negócio e os requisitos funcionais e não funcionais do sistema
RADPHP.
Foram identificados os seguintes requisitos funcionais para o sistema proposto:
•
RF01: o sistema deve realizar a importação de um arquivo SQL a cada novo projeto
para montar a estrutura de tabelas do banco de dados interna4 referente à aplicação
em questão;
•
RF02: o sistema deve permitir a definição de listagens baseado na estrutura de banco
de dados da aplicação;
•
RF03: o sistema deve permitir a definição de detalhes5 baseado na estrutura de banco
de dados da aplicação;
•
RF04: o sistema deve implementar as funções de inclusão, exclusão e alteração de
dados baseando-se na estrutura de banco de dados interna da aplicação (cadastro);
4
A estrutura de tabelas do banco de dados é chamada interna para enfatizar que não existe nenhuma relação entre a
estrutura da ferramenta e o verdadeiro banco de dados da aplicação, tendo em vista que não realizá-se engenharia
reversa a partir da ferramenta.
5
Detalhe é o nome de um formulário pré-estabelecido pelo framework que se refere a todo e qualquer detalhe de dados
nas aplicações que o utilizam como alicerce.
•
RF05 o sistema deve permitir ao usuário informar o caminho da classe htmlBase
(classe do framework PHPLib-UNIVALI) utilizado para a definição do layout da
aplicação;
•
RF06: o sistema deve permitir a configuração de informações de acesso do banco de
dados da aplicação;
•
RF07: o sistema deve permitir adicionar e alterar tabelas na estrutura do banco de
dados interna da aplicação;
•
RF08: o sistema deve permitir adicionar e alterar atributos nas tabelas da estrutura do
banco de dados interna da aplicação;
•
RF09: o sistema deve permitir a definição de consultas simples em formato SQL;
•
RF10: o sistema deve implementar a função abrir projeto;
•
RF11: o sistema deve implementar a função salvar projeto; e
•
RF12: o sistema deve gerar código da aplicação de acordo com as configurações do
usuário.
Para o sistema proposto foram identificadas as seguintes regras de negócio:
•
RN01: o sistema deve validar os campos de entrada de dados obrigatórios;
•
RN02: o sistema deve possuir mecanismo para consistir campos do tipo e-mail, data
e CEP durante o processo de entrada de dados;
•
RN03: o sistema deve permitir a definição de rótulos e o tamanho visível do campo
no formulário de cadastro.
•
RN04: o sistema deve permitir a configuração dos nomes das páginas geradas,
observando o padrão de sufixos: _lst para listagens; _det para detalhes; e _cad para
cadastros;
•
RN05: o sistema não modifica a estrutura do banco de dados físico a partir das
alterações efetuadas na estrutura de banco de dados interna através da ferramenta; e
38
•
RN06: o sistema não incorpora as alterações realizadas manualmente pelo usuário no
código fonte gerado.
Foram identificados os seguintes requisitos não funcionais para o sistema proposto:
•
RNF01: o código gerado pelo sistema deve ser em linguagem PHP 4 e respeitar a
arquitetura fornecida pelo framework PHPLib-UNIVALI (conformidade);
•
RNF02: o arquivo SQL que será importado no sistema deve respeitar os padrões do
banco de dados Oracle (conformidade);
•
RNF03: o sistema não deverá utilizar banco de dados, todas as informações
necessárias deverão ser armazenadas em XML em conformidade com XML Schema
(implementação); e
•
RNF04: a definição de consultas SQL devem ser simples, ou seja, deve conter a
definição de cada campo selecionado na cláusula SELECT, não permitindo tipos
complexos e/ou operações aritméticas (implementação).
3.2. MODELO DE CASOS DE USO
Furlan (1998) afirma que o diagrama de caso de uso destina-se a descrever os requisitos
funcionais de um novo sistema. Um caso de uso representa uma entidade discreta e ilustra a
interação entre as funcionalidades e os usuários. A Figura 14 apresenta o modelo de casos de uso da
ferramenta RADPHP.
39
Figura 14. Modelo de Casos de Uso da ferramenta RADPHP
Na Figura 14, pode-se observar a interação entre o usuário (ator) e os casos de uso que
constituem o sistema. Para a utilização de qualquer funcionalidade da ferramenta é necessário criar
um projeto, desta forma o caso de uso Cria Projeto (UC 01) descreve os passos para criação de um
projeto.
Estando o projeto criado, o usuário pode manipulá-lo. Desta forma, ele interage diretamente
com os casos de uso UC 03, UC 04, UC 05, UC 06, UC 08, UC 09 e UC 10. É conveniente ao
usuário poder salvar as informações manipuladas e continuar o projeto posteriormente. Assim, os
casos de uso Abre Projeto e Salva Projeto (UC 02 e UC 07 respectivamente) retratam as ações que o
usuário efetua em relação as operações básicas do projeto.
A descrição das ações realizadas pelo usuário para obter seu produto final, ou seja, código
fonte da aplicação, são delineadas a partir do caso de uso Gera Código (UC 11), que é responsável
por descrever o processo de geração de código da aplicação.
40
Com o intuito de melhor descrever os casos de uso recomenda-se a elaboração de cenários
que, segundo Gustafson (2003), é a descrição de uma seqüência de ações que pode ocorrer no
domínio de um problema. Sendo assim, o Apêndice B apresenta os cenários de cada caso de uso,
bem como suas relações com os requisitos funcionais e regras de negócio do sistema.
3.3. DIAGRAMA DE CLASSES
Com o intuito de prover um melhor entendimento do funcionamento do sistema, a Seção
3.3.1 apresenta o diagrama de classes do mesmo e uma breve descrição de cada classe.
Também é conveniente demonstrar a estrutura lógica do analisador SQL, uma vez que o
mesmo é responsável pela análise léxica, sintática e semântica do script SQL fornecido ao sistema
no momento em que um projeto é criado. Desta forma, a Seção 3.3.2 apresenta o diagrama de
classes do analisador e uma descrição sucinta de cada uma de suas classes.
3.3.1. Diagrama de classes do sistema
Esta seção apresenta o diagrama de classes do sistema (Figura 15) e um comentário
explicativo sobre cada uma das classes do mesmo.
41
Figura 15. Diagrama de classes do sistema
42
Vale destacar que o diagrama de classes foi criado com base nos casos do sistema. Desta
forma, tanto os atributos quanto as funcionalidades de cada uma das classes podem ser validadas
através da Seção 3.2.1. Outro aspecto a ressaltar refere-se à classe com estereótipo enumeration, o
qual, segundo Carlson (2002), define de uma lista de valores possíveis para um atributo que recebe
o tipo da classe enumeration.
Os itens a seguir apresentam a descrição das classes do diagrama:
•
rhpProject: Classe responsável pelo comportamento do projeto. Possui atribuições
como: criar, abrir, fechar ou salvar um projeto, bem como é responsavel pela
configuração das informações do banco de dados da aplicação;
•
rhpTable: Classe responsável pelo comportamento das tabelas do banco de dados da
aplicação. Possui atribuições de criação e alteração das tabelas;
•
rhpAttribute: Classe responsável pelo comportamente dos atributos de uma tabela da
base de dados da aplicação, identificando o nome do atributo, seu tipo, tamanho, se o
mesmo é nulo e/ou uma chave;
•
rhpList: Classe responsável pelo comportamento do formulário de listagem do
framework. Essa classe identifica e relaciona todos os atributos utilizados na
listagem, como os mesmos são ordenados e se possuem link para outras páginas.
Também é responsabilidade desta classe definir o título das páginas de listagem e se
as mesmas possuem paginação;
•
rhpDetail: Classe responsável pelo comportamento do formulário de detalhe do
framework. Desta forma, é de responsabilidade desta classe identificar e relacionar
os atributos utilizados em um detalhe, bem como definir o título das páginas de
detalhe da aplicação;
•
rhpRegister: Classe responsável pelo comportamento do formulário de cadastro do
framework. Possuindo comportamento similar as classes rhpList e rhpDetail, essa
classe identifica e relaciona os atributos utilizados em um formulário de cadastro da
aplicação. Neste contexto, a mesma também define o título das páginas de cadastro
da aplicação;
•
rhpQuery: Classe que define as consultas de um projeto. Tais definições são
compostas por um nome (identificador da consulta) e um script SQL da mesma
43
definido pelo usuário. As consultas podem ser utilizadas para definição de listagens a
partir de diversas tabelas;
•
rhpAttributeList: Classe associativa que armazena as informações adicionais de cada
um dos atributos utilizados em uma listagem;
•
rhpAttributeDetail: Classe associativa que armazena as informações adicionais dos
atributos utilizados em um formulário de detalhe;
•
rhpAttributeRegister: Classe associativa que armazena as informações adicionais dos
atributos utilizados em um formulário de cadastro;
•
rhpReferenceTable: Classe responsável por identificar os atributos que são chave
estrangeira. Desta forma, essa classe identifica o atributo e qual é a sua tabela pai;
•
rhpParser: Classe responsável por percorrer o arquivo SQL da base de dados da
aplicação e identificar as tabelas, atributos, tipos de dados, chaves primárias e
estrageiras em cada uma das tabelas; e
•
rhpButton: Classe responsável por identificar quais os botões um formulário pode
ter.
•
rhpAttributeQuery: Classe que armazena as informações adicionais dos atributos
utilizados em uma consulta.
3.3.2. Diagrama de classes do analisador SQL
Esta seção apresenta o diagrama de classes do analisador SQL (Figura 16), bem como
explica a funcionalidade de cada uma das classes do mesmo.
O pacote que contêm o diagrama do analisador SQL do projeto foi nomeado sqlAnalyser.
Desta forma, os itens a seguir apresentam uma breve descrição de cada uma das classes
pertencentes ao pacote sqlAnalyser.
•
LexicalAnalyser: Classe responsável por realizar a análise léxica do arquivo SQL;
•
SyntacticAnalyser: Classe responsável por realizar a análise sintática do arquivo SQL;
•
SemanticAnalyser: Classe responsável por realizar a análise semântica do arquivo SQL;
•
AnalysisError: Classe base para tratamento de erros durante o parser do arquivo SQL;
44
•
LexicalError: Classe responsável por identificar e efetuar o tratamento dos erros
referentes ao analisador léxico;
•
SyntaticError: Classe responsável por identificar e efetuar o tratamento dos erros
referentes ao analisador sintático;
•
SemanticError: Classe responsável por identificar e efetu7ar o tratamento dos erros
referentes ao analisador semântico;
•
Token: Classe responsável pela identificação de cada um dos tokens reconhecidos
durante a análise do arquivo SQL; e
•
TokenId: Classe que identifica o tipo de token encontrado durante a análise do arquivo
SQL.
Figura 16. Diagrama de classes do analisador SQL
45
É importante ressaltar que as classes do pacote sqlAnalyser são geradas através de definições
de gramática a partir da ferramenta GALS, descrita com detalhes na Seção 2.6.1. No entanto,
enquadra-se como exceção a classe SemanticAnalyser, a qual é gerada somente a estrutura pela
ferramenta GALS e sua implementação torna-se responsabilidade do projeto.
3.4. XML SCHEMA
Conforme mencionado na Seção 2.6.2.1.2, XML Schema tem o intuito de definir como
documentos XML devem ser construídos, quais elementos os mesmos podem ou devem possuir,
bem como em que ordem esses elementos devem ser dispostos.
Desta forma, tendo em vista que as informações de configuração da ferramenta e a estrutura
de banco de dados da aplicação devem ser armazenadas em documentos XML, é conveniente a
elaboração de um XML Schema, com a finalidade de validar a estrutura e o conteúdo do documento
XML que compõe a ferramenta.
Para facilitar o entendimento, o XML Schema elaborado é apresentado em forma de
diagrama, a partir da notação utilizada pela ferramenta XML Spy. Uma explicação detalhada sobre
cada um dos estereótipos que compõem a notação pode ser encontrada em Kokubo (2004, p.17).
Além dos diagramas, o Apêndice C apresenta o código fonte do XML Schema do projeto.
A Figura 17 expõe a visão geral do XML Schema elaborado para validação do documento
XML utilizado pela ferramenta RADPHP.
46
Figura 17. Visão geral do XML Schema para ferramenta RADPHP
Além da visão geral do XML Schema (Figura 17), é fundamental apresentar a estrutura
interna dos elementos formados por estruturas de dados complexos (complex types). Desta forma a
Figura 18 apresenta os detalhes do elemento project e a Figura 19 a estrutura interna do elemento
attribute.
Figura 18. Detalhes do elemento project
47
Figura 19. Estrutura interna do elemento attribute
As informações pertinentes à estrutura interna dos elementos list são exibidas através da
Figura 20.
Figura 20. Estrutura interna dos elementos list
48
Por fim, são apresentadas as informações referentes aos elementos detail (Figura 21) e
register (Figura 22).
Figura 21. Estrutura interna dos elementos detail
Figura 22. Estrutura interna dos elementos register
3.5. IMPLEMENTAÇÃO
De forma geral, a fase de implementação da ferramenta RADPHP dividiu-se em quatro
grandes etapas: (i) implementar reconhecedor de linguagem SQL; (ii) implementar estrutura de
dados do sistema; (iii) implementar as opções de configuração do sistema; e (iv) implementar
49
gerador de código PHP. Sendo assim, as seções seguintes retratam as técnicas e tecnologias
utilizadas em cada uma das etapas desta fase.
3.5.1. Reconhecedor de linguagem SQL
Um dos pré-requisitos para o desenvolvimento de aplicações utilizando a ferramenta
RADPHP é a criação de um projeto, que armazena todas as informações de configuração e a
estrutura do banco de dados da aplicação. Dessa forma, fez-se necessário o desenvolvimento de um
analisador, com o intuito de converter a estrutura do banco de dados da aplicação – inicialmente em
linguagem SQL – para uma forma entendida pela ferramenta RADPHP.
O analisador SQL da ferramenta foi implementado em conformidade com o banco de dados
Oracle 8i e possui funções de reconhecimento de tabelas, atributos, tipos e tamanho de campos,
comentários e constraints.
É de suma importância destacar que durante a implementação deste obteve-se auxílio da
ferramenta GALS. De forma geral, o GALS (descrito em detalhes na Seção 2.6.1) propõe-se a gerar
analisadores léxicos e sintáticos baseados em gramáticas. Neste caso, utilizou-se o método SLR
que, segundo Crespo (1998), consiste na construção - a partir de uma gramática livre de contexto de um autômato finito determinista. A Figura 23 apresenta parte de uma gramática independente de
contexto – para reconhecimento de criação de tabelas em linguagem SQL – definida através da
ferramenta GALS.
A gramática descrita na Figura 23 – em sua totalidade – acarretou na geração da estrutura de
classes apresentada na Seção 3.3.2. Foi de inteira responsabilidade do projeto a implementação da
classe SemanticAnalyser, criada em linguagem C++ em consonância com a estrutura de classes
gerada pela ferramenta GALS.
50
Figura 23. Definição da gramática na ferramenta GALS
Vale ressaltar que o desenvolvimento do analisador foi desvinculado da ferramenta
RADPHP através de um pacote de classes, nomeado sqlAnalyser¸ portanto, pode ser utilizado
separadamente por qualquer aplicação desenvolvida em linguagem C++.
3.5.2. Estrutura de dados do sistema
Tendo em vista que um dos requisitos da ferramenta RADPHP é a não utilização de bancos
de dados para armazenamento das informações pertinentes ao projeto, foram utilizados documentos
XML - para armazenamento das informações - e XML Schema (descrito com detalhes na Seção 3.4)
para definição da estrutura do documento XML utilizado pela ferramenta.
O acesso e armazenamento dos dados em documentos XML na ferramenta deu-se através de
um recurso intitulado XML Data Binding, que de acordo com Borland (2002), é um wizard que
trabalha com geração automática de código para acesso a documentos XML através do método
DOM (Document Object Model). O XML Data Binding (Figura 24) objetiva criar uma estrutura de
dados comum para facilitar o acesso e manipulação de documentos XML através de XML Schema.
51
Figura 24. Interface do wizard do XML Data Binding
3.5.3. Opções de configuração do sistema
As opções de configuração do sistema consistem basicamente na interface para
desenvolvimento dos formulários, consultas, alterações na estrutura do banco de dados e definição
das informações de acesso a base de dados. Para o desenvolvimento da interface, apresentada na
Seção 3.6.3, utilizou-se a IDE Borland C++ Builder 6.
É importante salientar que a ferramenta RADPHP foi desenvolvida em duas camadas: (i)
interface, que se constitui do módulo de interação com o usuário; e (ii) aplicação, que contem a
implementação de todas as regras de negócio da aplicação. Dessa forma, pode-se facilmente criar
uma nova interface para ferramenta (sendo ela visual ou textual) sem a necessidade de realizar
alterações consideráveis na estrutura da aplicação.
3.5.4. Gerador de código PHP
O desenvolvimento do módulo gerador de código do projeto RADPHP foi a última etapa da
fase de implementação, sendo responsável pela geração do código da aplicação respeitando a
padronização definida pelo framework PHPLib-UNIVALI.
52
A geração de código dá-se através de arquivos de modelo – vide Figura 25 – orientados por
tags pré-definidas pela ferramenta e que são substituídas pelo código correspondente.
Figura 25. Exemplo de modelo para geração de código
A Figura 25 apresenta um exemplo de modelo para uma consulta SQL. A geração efetiva do
código PHP é realizada através de um parser, implementado na camada de aplicação, que substitui
as tags iniciadas por “<%rhp” pelo código gerado através das configurações do usuário.
Em sua totalidade, a ferramenta RADPHP é composta por 20 arquivos de modelo, divididos
em três grupos: (i) elementos, formado pelos componentes do framework, como campo de edição de
textos, lista de valores, e-mail, etc.; (ii) ações, que contem os modelos responsáveis pela interação
com o banco de dados; e (iii) formulários, constituído dos modelos para definição dos formulários
de listagem, detalhe, cadastro e consulta. A Figura 26 apresenta os três grupos de modelos e os
arquivos que os compõem, bem como as relações existentes entre os mesmos.
53
Figura 26. Arquivos de modelo da ferramenta RADPHP e suas relações
Vale ressaltar que, embora não seja recomendado, existe a possibilidade da alteração dos
arquivos de modelo – manualmente – por parte dos usuários da ferramenta, o que acarretará na
geração do código alterado pelo usuário a cada novo projeto. No entanto, a remoção, edição ou
alteração de alguma das tags do modelo ocasionará em erro durante a geração do código da
aplicação.
3.6. FERRAMENTA RADPHP
A ferramenta RADPHP foi concebida com a intenção de fornecer as funcionalidades
necessárias para a criação de projetos que empreguem o framework PHPLib-UNIVALI. Antes de
apresentar a ferramenta, é conveniente contextualizá-la dentro do processo de desenvolvimento de
software, uma vez que a utilização da mesma engloba etapas específicas e não o processo em sua
totalidade. Dessa forma, a Seção 3.6.1 contextualiza a ferramenta no processo de desenvolvimento
de software, a Seção 3.6.2 apresenta um estudo de caso, com o objetivo de validar o software e a
Seção 3.6.3 demonstra o funcionamento do RADPHP. As considerações sobre produtividade RAD
em relação ao estudo de caso são apresentadas na Seção 3.6.4.
3.6.1. Contextualizando o RADPHP no processo de desenvolvimento de software
De acordo com Peters e Pedrycz (2001), processo de software é uma seqüência de etapas
com feedback que produz uma variedade de documentos e resulta na produção e na evolução de um
software.
54
O processo de software pode ser visto de forma hierárquica e, segundo Peters e Pedrycz
(2001), durante a fase de desenvolvimento pode-se elencar três principais etapas:
•
Requisitos: Decide-se o que o sistema deve fazer, suas atividades, riscos e planos de
testes;
•
Projeto: Determina-se a estrutura do sistema e suas funções específicas; e
•
Implementação: Produz o código-fonte, documentação e testes.
Alguns modelos de ciclo de vida de software apresentam maior nível de maturidade, pois
fundamentam-se em conhecimento e experiência obtidos após uma infinidade de projetos
desenvolvidos em grande escala por engenheiros de software. Um exemplo clássico é o modelo em
cascata, que pode ser considerado um dos mais antigos modelos de ciclo de vida. Segundo Peters e
Pedrycz (2001), em seu formato original ele descrevia uma seqüência de atividades do ciclo de vida
de software, começando pela exploração de conceitos e concluindo com a manutenção e uma
inevitável substituição. A Figura 27 apresenta detalhadamente as etapas do modelo cascata.
Figura 27. Modelo de processo de software em cascata
Fonte: Adaptado de Peters e Pedrycz (2001)
55
Observando atentamente a Figura 27 observa-se claramente oito etapas distintas. É
importante enfatizar que a inserção da ferramenta RADPHP no processo de desenvolvimento
revela-se somente após a etapa de projeto. A ferramenta propõe-se a atuar como facilitador,
operando diretamente na etapa de implementação e provendo funcionalidades de geração
automática de código-fonte para formulários de listagem, detalhe e cadastro em aplicações web.
Vale destacar que não é descartado qualquer tipo de intervenção humana na etapa citada, uma vez
que a ferramenta não objetiva substituir o desenvolvedor, mas, auxiliá-lo no processo de
desenvolvimento, a fim de que o mesmo possa direcionar seus esforços para as regras de negócio da
aplicação.
Também pode-se considerar a aplicação indireta da ferramenta em mais duas etapas do
processo de desenvolvimento de software: (i) teste, tendo em vista que o código-fonte é gerado
automaticamente, o que reduz a margem erros de implementação; e (ii) manutenção, já que a
ferramenta facilita futuras modificações na aplicação e segue um padrão para geração de código
(fornecido pelo framework PHPLib-UNIVALI), que pode ser facilmente compreendido por
desenvolvedores que utilizam o framework. Dessa forma, a atuação direta ou indireta da ferramenta
RADPHP nestas três etapas do processo de desenvolvimento de software objetiva a redução de
tempo e esforço repetitivo por parte dos desenvolvedores durante o desenvolvimento de software.
Além do modelo cascata pode-se contextualizar a ferramenta em outros modelos de ciclo de
vida de software, como por exemplo o modelo de prototipação, que segundo Peters e Pedrycz
(2001), vem solucionar o problema da espera no modelo em casaca (não é necessário esperar até o
final do ciclo de desenvolvimento para se obter uma versão operacional do software), pois sua
abordagem tem como ponto principal produzir protótipos de software com funcionalidades e
desempenho limitados. Semelhantemente ao modelo em cascata a ferramenta RADPHP atua
diretamente na fase de construção do protótipo e indiretamente nas fases de teste e manutenção do
mesmo.
Sendo assim, pode-se dizer que independente do modelo de ciclo de vida de software a
ferramenta RADPHP traz benefícios diretos para a fase de implementação e indiretos as fases de
teste e manutenção, uma vez que estas fases possuem comportamento similar em ambos processos.
Conforme dito anteriormente, o processo de desenvolvimento software produz uma
variedade de documentos, grande parte deles na etapa de projeto, no entanto, a utilização da
ferramenta RADPHP se restringe apenas pelo modelo de entidade-relacionamento (modelo ER),
56
usualmente representado graficamente através de um diagrama de entidade-relacionamento (DER) e
que de acordo com Heuser (2000), é considerado padrão para modelagem conceitual de banco de
dados.
3.6.2. Estudo de caso
Estando bem definido o escopo da ferramenta perante o processo de desenvolvimento de
software e seu funcionamento, torna-se adequado elaborar um estudo de caso com o intuito de
validar os objetivos idealizados para o projeto. Dessa forma, desenvolveu-se uma aplicação utilizando a ferramenta RADPHP – com a finalidade de estabelecer um controle de patrimônios. O
objetivo da aplicação é simples: realizar controle de patrimônios levando em consideração a que
setor ele pertence, quem é seu responsável e em que estado (status) cada patrimônio se encontra.
Para facilitar o entendimento são apresentados a seguir os requisitos funcionais, não funcionais e
regras de negócio da aplicação.
Foram identificados os seguintes requisitos funcionais para a aplicação proposta:
•
RF01: O sistema deverá apresentar uma lista de setores;
•
RF02: O sistema deverá apresentar uma lista dos patrimônios;
•
RF03: O sistema deverá apresentar uma lista dos responsáveis;
•
RF04: O sistema deverá apresentar uma lista dos estados disponíveis para cada
patrimônio;
•
RF05: O sistema deverá permitir a inserção de novos setores;
•
RF06: O sistema deverá permitir a inserção de novos patrimônios;
•
RF07: O sistema deverá permitir a inserção de novos responsáveis;
•
RF08: O sistema deverá permitir a inserção de novos estados dos patrimônios;
•
RF09: O sistema deverá permitir a alteração dos dados dos setores, patrimônios,
responsáveis e estados; e
57
•
RF10: O sistema deverá permitir a exclusão de setores, patrimônios, responsáveis e
estados.
Para a aplicação proposta no estudo de caso foram identificadas as seguintes regras de
negócio:
•
RN01: O sistema deve validar os campos de obrigatórios durante os cadastros de
dados;
•
RN02: Cada patrimônio deve estar alocado a somente um setor;
•
RN03: Cada patrimônio deve ter um responsável; e
•
RN04: Cada patrimônio deve estar em um estado corrente (ex: quebrado,
emprestado, etc.).
Também foram identificados os seguintes requisitos não funcionais para a aplicação:
•
RNF01: O sistema deverá rodar sobre plataforma PHP 4.1.0 ou superior; e
•
RNF02: O sistema deverá ser compatível com banco de dados Oracle 8i ou superior.
Como mencionado na Seção 3.6.1, é necessário a elaboração de um DER para a utilização
da ferramenta RADPHP, já que um dos quesitos para criação de um projeto na ferramenta é possuir
a definição do banco de dados da aplicação em linguagem SQL. Sendo assim, a Figura 28 apresenta
o diagrama de entidade-relacionamento da aplicação proposta neste estudo de caso.
Figura 28. Diagrama de entidade-relacionamento (DER) para o estudo de caso proposto
58
3.6.3. Demonstração
Conforme mencionado na Seção 3.6.2, realizou-se o desenvolvimento de um estudo de caso
com a finalidade de validar as funcionalidades da ferramenta. Dessa forma, é apresentado nesta
seção o desenvolvimento do estudo de caso, com o intuito de demonstrar o funcionamento da
ferramenta RADPHP.
Pode-se dizer que a utilização a ferramenta RADPHP está diretamente vinculada à criação
de um projeto, o qual armazena todas as configurações do banco de dados da aplicação, dos
formulários e consultas geradas a partir da ferramenta. A Figura 29 apresenta a interface para
criação de um novo projeto.
Figura 29. Interface para criação de projetos na ferramenta RADPHP
A criação de um novo projeto dá-se através do preenchimento do nome do projeto, do
arquivo SQL que contêm as estrutura do banco de dados da aplicação e, eventualmente, do modelo
do layout da mesma (arquivo htmlBase.inc do framework PHPLib-UNIVALI). Após fornecer as
informações necessárias deve-se clicar no botão “Novo Projeto”, desta forma o sistema analisa
59
léxica, sintática e semanticamente o arquivo SQL fornecido e cria a estrutura do banco de dados da
aplicação necessária para a configuração dos formulários disponíveis na ferramenta.
Tendo em vista que um projeto já foi criado, inicia-se o desenvolvimento da aplicação, que
consiste basicamente na configuração das informações de conexão com o banco de dados e
configurações dos formulários. Pode-se observar na Figura 30 a interface de configuração dos
elementos do banco de dados, que resumem-se nos dados do servidor, usuário e senha de acesso. É
importante salientar que todas as informações a serem manipuladas são acessíveis através da barra
de ferramentas, na parte esquerda do software.
Figura 30. Interface para configuração das informações do banco de dados
A configuração dos três tipos de formulários (listagem, detalhe e cadastro) ocorre de forma
similar. Para tal, o usuário deve selecionar a tabela desejada, através da barra de ferramentas, e
manipular as informações do formulário e dos atributos do mesmo. Com o intuito de exemplificar o
funcionamento da ferramenta, a Figura 31 ilustra a configuração do formulário de listagem de
responsáveis, desenvolvido durante o estudo de caso.
60
Analisando a Figura 31 observa-se todas as informações necessárias para a configuração de
um formulário de listagem como as colunas que irão compor a listagem, bem como a forma de
ordenação. O campo “paginação” identifica se a listagem será ou não paginada, atribuindo um valor
padrão de 20 registros por página. Também observa-se as “Informações adicionais do campo”, onde
além de estipular o rótulo pode-se atribuir um link a cada registro da listagem, bem como selecionar
os parâmetro a serem passados para o formulário de detalhe.
Figura 31. Configuração do formulário de listagem
Pode-se também observar através da Figura 32 o exemplo da configuração do formulário de
detalhe dos setores a aplicação proposta no estudo de caso, possuindo – de forma reduzida – as
mesmas características de configuração do formulário de listagem.
61
Figura 32. Configuração do formulário de detalhe
A configuração do formulário de cadastro pode ser observada através da Figura 33. Vale
destacar que durante a configuração de um formulário os atributos podem ser identificados através
dos símbolos PK (chave primária), FK (chave estrangeira) e 2K (chave primária e estrangeira). Os
atributos identificados com os símbolos FK e 2K podem referenciar atributos de outras tabelas. No
exemplo apresentado na Figura 33, o atributo “responsavel_id” da tabela “patrimônio” referencia o
atributo “responsavel_nome” da tabela “responsavel”. Também é importante salientar as
características peculiares contidas durante a configuração do formulário de cadastro, como a
escolha do componente a ser utilizado para cada campo, através da opção “Formato do campo no
formulário” e opção para preenchimento obrigatório do campo.
62
Figura 33. Configuração do formulário de cadastro
A última etapa obrigatória para o funcionamento das aplicações geradas através da
ferramenta RADPHP é a geração de código fonte, realizada através da interface apresentada na
Figura 34. Para tal, deve-se selecionar os arquivos da aplicação que irão compor o sistema e clicar
no botão “Gerar Código”. Dessa forma, o código fonte é gerado em uma estrutura de diretórios que
incorpora o nome do projeto, e algumas sub-pastas contendo os arquivos do framework (caso a
opção de geração do framework for selecionada), as imagens e o arquivo de estilos.
63
Figura 34. Interface para geração de código na ferramenta RADPHP
A Figura 35 apresenta o código fonte do formulário de listagem de setores (gerado a partir
do modelo “list_model.mo”, apresentado na Figura 26) criado pela ferramenta RADPHP (em
conformidade com o framework PHPLib-UNIVALI) durante o estudo de caso.
Figura 35. Código fonte de um formulário de listagem gerado pela ferramenta RADPHP
64
Como resultado do estudo de caso obteve-se a geração dos formulários de listagem, detalhe
e cadastro para cada um das 4 tabelas da aplicação (patrimonio, responsavel, setor, status). Com o
intuito de ilustrar os resultados, a Figura 38 expõe a aplicação de estudo de caso em execução,
apresentando o formulário de listagem de patrimônios.
Figura 36. Formulário de listagem de patrimônios
A Figura 37 apresenta o formulário de detalhe de setores, gerado através da configuração
apresentada na Figura 32.
Figura 37. Formulário de detalhe de setores
Concluindo, a Figura 38 apresenta o formulário de cadastro de patrimônios, gerado através
da ferramenta durante o desenvolvimento do estudo de caso.
Figura 38. Formulário de cadastro de patrimônios
65
Além das funcionalidades apresentadas, a ferramenta RADPHP possibilita a criação de
consultas personalizadas e alteração na estrutura da base de dados da aplicação. A criação de uma
consulta dá-se através do fornecimento de um script SQL e o ajuste de algumas opções de
configuração, conforme apresenta a Figura 39. No exemplo exposto (Figura 39) destaca-se a criação
de uma consulta – no âmbito do estudo de caso – com o intuito de apresentar todos os responsáveis
por patrimônios com “status” disponível. É importante observar que o modelo de configuração
assemelha-se, em grande parte, ao formulário de listagem possuindo atributos como paginação,
botões e informações adicionais do campo.
Figura 39. Interface para configuração de consultas personalizadas
Conforme dito anteriormente, a ferramenta RADPHP também apresenta recursos de
alteração da estrutura do banco de dados da aplicação, que consistem fundamentalmente na criação
e alteração de tabelas (Figura 40 (a), onde pode-se manipular informações como nome e comentário
da tabela) e atributos (Figura 40 (b), possibilitando a modificação dos dados do atributo, como
nome, tipo e tamanho do campo, aceitação de valores nulos e caracterização do campo como chave
primária ou estrangeira).
66
(a)
(b)
Figura 40. Interfaces para alteração da base de dados (a) Tabelas; (b) Atributos
É de suma importância ressaltar que as informações modificadas na ferramenta RADPHP
durante a execução de um projeto não são concretizadas no banco de dados físico da aplicação, uma
vez que a ferramenta não possui vínculo direto com o banco de dados real.
3.6.4. Produtividade RAD
Durante o desenvolvimento da aplicação apresentada no estudo de caso mensurou-se o
tempo de desenvolvimento6 da mesma, com o intuito de avaliar a eficácia da produtividade RAD
nas etapas do processo de desenvolvimento englobados pela ferramenta.
Sendo assim, observou-se que a construção da aplicação de estudo de caso utilizando a
ferramenta RADPHP foi de 13 minutos e 03 segundos (tendo seu início as 12:51:00 e término as
13:04:03) e seu tamanho físico de aproximadamente 2000 linhas de código, distribuídas em 13
diferentes arquivos, isentando os arquivos do framework PHPLib-UNIVALI.
Além de medir o tempo de desenvolvimento, realizou-se cálculo utilizando a métrica de
software de pontos por função que, segundo Peters e Pedrycz (2001), está relacionada com os
documentos de especificação de requisitos, onde é determinada a funcionalidade de um sistema de
software. Em essência, o modelo de pontos por função se baseia em características visíveis do
sistema que são ponderadas de modo a produzir uma pontuação geral, com o objetivo de obter uma
medida do tamanho do produto a ser desenvolvido.
6
Neste contexto, desenvolvimento refere-se a etapa de implementação, uma vez que a ferramenta RADPHP não possui
vínculo direto com as etapas de análise e projeto de software.
67
Através do cálculo de pontos por função sobre o estudo de caso – apresentado
detalhadamente no Apêndice D – chegou-se ao valor de 81 pontos por função ajustados e 103
pontos por função brutos. Tendo em vista que foram gastos aproximadamente 13 minutos para o
desenvolvimento da aplicação, estima-se que a produtividade obtida com o uso da ferramenta
RADPHP em relação aos pontos por função ajustados seja de 373 pontos por hora. Não remova esta
quebra de seção]
68
4. CONCLUSÕES
Tendo em vista a necessidade de desenvolver softwares de maneira rápida e eficiente, tornase cada vez mais viável a utilização de ferramentas RAD para acelerar este processo. Neste
contexto, considera-se este trabalho uma possível solução para a necessidade apresentada, uma vez
que a mesma abrange conceitos referentes a RAD e framework, o que amplia, consideravelmente, a
velocidade e padronização no desenvolvimento de software.
Dentre as oito diferentes etapas do processo de desenvolvimento de software, a ferramenta
RADPHP atua em três delas. Existe atuação direta na etapa de implementação e indireta nas etapas
de teste e manutenção, o que engloba uma parte considerável do processo de desenvolvimento,
contribuindo para geração automática de código e redução de tempo de desenvolvimento de
sistemas. Vale ressaltar que a ferramenta propõe-se a atuar apenas como facilitador, não
descartando nenhum tipo de intervenção humana ao decorrer das etapas mencionadas.
Um ponto a ser destacado é a utilização das diversas tecnologias e ferramentas no
desenvolvimento do projeto. Para conclusão da etapa de implementação foi necessário estudar e
empregar a linguagem de programação C++, documentos XML, XML Schema, linguagem SQL,
linguagem de programação PHP, banco de dados Oracle e a ferramenta GALS. Dessa forma,
evidencia-se a importância da etapa de Fundamentação Teórica (Capítulo 2), tendo em vista que
durante este estágio foram absorvidos conceitos importantes e que nortearam o desenvolvimento da
ferramenta RADPHP.
Com a validação da ferramenta, através do estudo de caso, pôde-se observar sua real
utilidade e avaliar de forma prática a redução do tempo de desenvolvimento da aplicação, uma vez
que como resultado obteve-se um sistema que possui aproximadamente 2000 linhas de código
desenvolvido em 13 minutos, tendo como média mais de 153 linhas de código por minuto.
Considera-se assim, que os objetivos estabelecidos para a o projeto foram alcançados, visto
que foi concebida uma ferramenta que possui características RAD e que engloba grande parte dos
benefícios descritos na Seção 2.2.1. Como diferencial salienta-se a utilização do framework
PHPLib-UNIVALI como alicerce dos sistemas gerados pela ferramenta, o que garante a
padronização do código gerado, e conseqüentemente, um alto nível de manutenção, uma vez que o
código fonte pode ser facilmente alterado através da ferramenta e por desenvolvedores que
conheçam o framework PHPLib-UNIVALI.
Por fim, espera-se, que este projeto possa ser efetivamente utilizado e que seu resultado
contribua como referência para outros trabalhos científicos.
4.1. TRABALHOS FUTUROS
Embora os resultados obtidos com o projeto possam ser considerados satisfatórios, é
possível identificar possibilidades de melhorias para realização em trabalhos futuros. A seguir são
apresentadas sugestões para continuação deste projeto:
•
Suporte a outros bancos de dados através de acesso direto a base (sem necessidade de
análise de arquivo SQL como entrada);
•
Identificação de Visões (Views) durante o processo de análise do arquivo SQL para
banco de dados Oracle;
•
Geração d e Script SQL contendo a estrutura do banco de dados atualizada a partir da
ferramenta;
•
Possibilidade de realização de cadastros utilizando várias tabelas no mesmo formulário;
•
Possibilidade de inclusão dinâmica de componentes para cadastro;
•
Interface para auxiliar a criação de SQLs para consulta;
•
Possibilidade de identificar o código-fonte alterado manualmente pelo usuário e
incorporá-lo na geração de código através da ferramenta;
•
Alteração de Interface e Menu da aplicação dentro da própria ferramenta; e
•
Conexão FTP para envio dos arquivos gerados ao servidor. SEÇÃO. Não remova esta
quebra de seção]
70
REFERÊNCIAS BIBLIOGRÁFICAS
AGARWAL, Ritu; PRASAD, Jayesh; TANNIRU, Mohan; LYNCH, John. Risks of Rapid
Application Development. Communications of ACM, New York, v. 43, n.11, p.177-188, Nov.
2000.
BENVENUTTI, Vanessa. Arquitetura de agentes para o processo de reuso de software. 2002.
115 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de
Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2002.
BLUE POLAR. Business and internet applications. 2004. Disponível em:
<http://www.bluepolar.com>. Acesso em: 02. abr. 2005.
BOSCH, Jan; MOLIN, Peter; MATTSSON, Michael; BENGTSSON, Per O; FAYAD, M. Objectoriented frameworks - problems & experiences. In: FAYAD, Mohamed; SCHMIDT, Douglas;
JOHNSON, Ralph. Building Application Frameworks. New York: John Wiley & Sons, 1999.
p.55-82.
BORLAND. Tópicos de ajuda: C++ builder help - XML Data Binding wizard, 2002.
BRAGA, Regina M. M.; WERNER, Cláudia M.L. Odyssey-DE: um processo para
desenvolvimento de componentes reutilizáveis. In: CONFERÊNCIA INTERNACIONAL DE
TECNOLOGIA DE SOFTWARE, 10., Curitiba, 1999. Anais... [S.l.: s.n.], 1999. p.177-194.
BROCHU, Earl. JAD isn't just for system projects any more. Computing Canada, Abr. 1993.
Disponível em: <http://www.findarticles.com/p/articles/mi_m0CGC/
is_n9_v19/ai_13786383>. Acesso em: 13 fev. 2005.
CAGNIN, Maria Istela. PENTEADO, Rosângela D. GERMANO, Fernão S. R. MASIERO, Paulo
C. Reengenharia com uso de padrões de projeto. In: SIMPÓSIO BRASILEIRO DE
ENGENHARIA DE SOFTWARE, 14., Florianópolis. 1999. Anais... [S.l.: s.n.], 1999.
CARLSON, David. Modelagem de aplicações XML com UML: aplicações práticas de e-business.
São Paulo: Pearson Education, 2002.
CASEMAKER INC. What is Rapid Application Development?. Santa Clara, 2000. Disponível
em: <www.casemaker.com/download/products/totem/rad_wp.pdf>. Acesso em: 12 mar. 2005.
CASTILHOS, Cristiano de. Ferramenta CASE para geração de páginas ASP. 2004. 74 f.
Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências
Exatas e Naturais, Universidade Regional de Blumenau, Blumenau, 2004.
CREEGAN, Robert W. RAD may be the answer. Computing Canada, Jun, 1994. Disponível em:
<http://www.findarticles.com/p/articles/mi_m0CGC/is_n13_v20/ai_15554759>. Acesso em: 08 fev.
2005.
CRESPO, Rui Gustavo. Processadores de linguagens: da concepção à implementação. Lisboa:
IST Press, 1998.
DEBONI, José Eduardo Zindel. CASE e RAD: concorrência ou colaboração? Developers’
Magazine. Rio de Janeiro: AXCEL, ano 2, n. 19, p. 20-21, mar. 1998.
FURLAN, José Davi. Modelagem de objetos através da UML: the Unified Modeling Language.
São Paulo: Makron Books, 1998.
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de projeto:
soluções reutilizáveis de software orientado a abjetos. Porto Alegre: Bookman, 2000.
GESSER, Eduardo Carlos. GALS - Gerador de analisadores léxicos e sintáticos. 2002. 150 f.
Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação), Centro Tecnológico,
Universidade Federal de Santa Catarina, Florianópolis, 2003.
GUSTAFSON, David A. Teoria e problemas de engenharia de software. Porto Alegre:
Bookman, 2003.
HOWARD, Alan. Rapid Application Development: rough and dirty or value-for-money
engineering? Communications of ACM, New York, v. 45, n. 10, p. 27-29, Oct. 2002.
JACQUES, Trevor. From code-and-fix to 4GLs: why we need RAD. Computing Canada, Jan,
1992. Disponível em: <http://www.findarticles.com/p/articles/mi_m0CGC/is_n2_v18/ai_11760128
>. Acesso em: 08 fev. 2005.
KARTHINK, S. CHUNG, C. W. RAMANI, K. Rapid Application Development – supplier models.
In: COMPUTERS AND INFORMATION IN ENGINEERING (CIE) CONFERENCE, 23., 2003,
Chicago. Proceedings… New York: ASME, 2003.
KIRK, C. DTDs no XML. In: PITTS-MOULTIS, N.; KIRK, C. XML black book: solução e poder.
São Paulo: Makron Books, 2000. p. 99-129.
KOKUBO, Eduardo. Sistema para importação de informações do currículo Lattes. 2004. 104 f.
Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências
Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004.
MAIA, Maurício M. Tutorial XML-Schema: UNICAMP Dicas-L. Disponível em: <
http://www.dicas-l.unicamp.br/dicas-l/20050326.php>. Acesso em: 16 abr. 2005.
MALCOLM, Eva. Requirements acquisition for Rapid Applications Development. Information &
Management, Northampton, v. 39, n. 2, p. 101-107, Dez. 2001.
MERLYN, Vaughan. Is RAD “RAD”?. Software Magazine, Fev, 1991. Disponível em: <
http://www.findarticles.com/p/articles/mi_m0SMG/is_n2_v11/ai_10349436>. Acesso em: 08 fev.
2005.
MSDN. .NET Framework Developer Center. 2005. Disponível em:
<http://msdn.microsoft.com/netframework/> Acesso em 02 ago. 2005.
PARSONS, David; RASHID, Awais; SPECK, Andreas. T. A framework for object oriented
frameworks design. In: TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND
SYSTEMS, 31st, Nanjing, 1999. Proceedings… Washington: IEEE Computer Society, 1999.
p.141-151.
72
PETERS, J. F.; PEDRYCZ, W. Engenharia de software. Rio de Janeiro: Campus, 2001.
RAUTER, André. BENATO, Karina. Visualização da informação para análise da estratégia
competitiva das instituições na web. In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, 4.,
2004, Itajaí. Anais... Itajaí: UNIVALI, 2004. 1 CD-ROM.
SILVEIRA, Claudionor. Geração automática de cadastros e consultas para linguagem ASP
baseado em banco de dados. 2003. 77 f. Trabalho de Conclusão de Curso (Bacharelado em
Ciência da Computação)–Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau, 2003.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison Wesley, 2003.
SORCEFORGE. SourceForge.Net: SourceForge.net: project info - PHPLibs UNIVALI.
Disponível em: < http://sourceforge.net/projects/phplib-univali/>. Acesso em 21 fev. 2005.
SOUZA, Robson Pinheiro de. Serviços para publicação e recuperação de componentes de software
através da Internet em ambientes de reuso. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE
SOFTWARE. 14., João Pessoa. 2000. Anais... [S.l.: s.n.], 2000.
TESCH JR, José Roberto. XML Schema. Florianópolis: Visual Books, 2002.
VARGAS, Ariel. Ferramenta educacional estúdio de cinema. 2004. 139 f. Trabalho de
Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da
Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004.
W3C. World Wide Web Consortium. Sophia-Antipolis, 2005. Disponível em:
<http://www.w3.org/>. Acesso em 12 abr. 2005.[FIM DE SEÇÃO. Não remova esta quebra de
seção]
73
APÊNDICE A – DICIONÁRIO DE DADOS PHPLIB-UNIVALI
Para melhor entendimento do estudo, as tabelas abaixo apresentam o dicionário de dados do
framework PHPLib-UNIVALI.
Tabela 5. Atributos da Classe dbBase
Atributo
conexao
result
stmt
user
pass
sql
Comentário
String de conexão com o banco de dados.
Resultados retornado com a execução de um sql.
Identificador de uma conexão
Nome do usuário do banco de dados.
Senha do banco de dados.
SQL que será executado pelo Banco de Dados.
Tabela 6. Operações da Classe dbBase
Operação
dbBase ()
Conectar ()
Desconectar ()
Executar (var, var)
Encerrar ()
Tupla ()
TuplaSimples (var, var)
SQL (var, var, var)
AtualizaLOB (var, var, var,
var, var)
ExecutarProc (var, var, var,
var)
Comentário
Construtor da Classe.
Método responsável pela conexão com o banco de dados.
Método responsável por desconectar o usuário do banco de
dados.
param: q [ var - in ]
param: modo [ var - in ]
Executa a consulta no banco de dados.
Encerra a consulta no banco de dados.
Retorna uma linha de registro de cada vez de uma consulta no
banco de dados.
param: q [ var - in ]
param: modo [ var - in ]
Executa e retorna uma única linha de registro.
param: q [ var - in ]
param: autovar [ var - in ]
param: modo [ var - in ]
Tem a mesma função do método Executar, no entanto retorna
true se a consulta foi realizada com sucesso, e false caso
contrário.
param: tabela [ var - in ]
param: chave [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: type [ var - in ]
Atualiza um campo LOB (BLOB ou CLOB)
param: nome_proc [ var - in ]
param: array_in [ var - in ]
param: array_out [ var - in ]
ExecutarDML (var, var, var,
var, var)
Commit ()
Rollback ()
param: modo [ var - in ]
Executa um procedimento.
param: tipo [ var - in ]
param: tabela [ var - in ]
param: arrayValores [ var - in ]
param: arrayWhere [ var - in ]
param: modo [ var - in ]
Monta um script SQL automaticamente (INSERT, UPDATE,
DELETE)
Efetua o Commit
Efetua o Rollback
Tabela 7. Atributos da Classe formBase
Atributo
nome
titulo
acao
nome_acao
Comentário
Nome do formulário
Título do formulário
Ação Javascript que o formulário irá executar ao clicar em um
botão
Rótulo do botão onde a ação javascript será executada.
Tabela 8. Operações da Classe formBase
Operação
formbase (var)
Processar ()
Comentário
param: nome [ var - in ]
Construtor da classe
Processa todo conteúdo da página (monta o formulário)
Tabela 9. Atributos da Classe formCadastro
Atributo
largura
tipoacao
campos
erros
mensagem
fexcluir
url_cancelar
nome_url_cancelar
url_sucesso
nome_url_sucesso
action
form_enctype
Comentário
Largura da tabela do formulário de Cadastro.
Tipo da ação que o formulário irá executar Novo, Editar,
Excluir)
Campos do Formulário de Cadastro.
Array que contem os erros encontrados durante a execução do
formulário.
Mensagem que pode ser apresentada antes do formulário de
cadastro.
Indica se o botão excluir deve ser apresentado.
Ação do botão cancelar no cadastro.
Rotulo do botão cancelar no cadastro.
Ação do botão Enviar no cadastro.
Rotulo do botão Enviar no cadastro.
Guarda o caminho para onde o furmulário deve seguir caso ele
seja direcionado para outra página.
Informa o tipo de dado que será enviado no formulário.
75
Tabela 10. Operações da Classe formCadastro
Operação
formCadastro (var)
Comentário
param: nome [ var - in ]
Construtor da Classe.
PreCadastrar ()
Realiza pré processamento com o intúito de encontrar erros.
Inicializar ()
Inicializa os atrinutos da classe.
Processar ()
Processa e monta o formulário
Formular ()
Gera os campos (layout do formulário)
Novo ()
Método que executa a ação novo (inserção)
Editar ()
Método que executa a ação editar (alterar)
Excluir ()
Método que executa a ação excluir (deletar)
campoOculto (var, var)
param: nome [ var - in ]
param: valor [ var - in ]
Armazena um valor oculto.
campoRotulo (var, var, var)
param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
Campo informativo (descrição)
campoTexto (var, var, var, var, param: nome [ var - in ]
var, var)
param: campo [ var - in ]
param: valor [ var - in ]
param: tamanhovisivel [ var - in ]
param: tamanhomaximo [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de um pequeno texto (Edit)
campoData (var, var, var, var) param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de datas.
campoMemo (var, var, var,
param: nome [ var - in ]
var, var, var)
param: campo [ var - in ]
param: valor [ var - in ]
param: colunas [ var - in ]
param: linhas [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de textos maiores.
campoLista (var, var, var, var) param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
Campo "Select", para seleção de um dado.
campoArquivo (var, var, var,
param: nome [ var - in ]
var)
param: campo [ var - in ]
param: valor [ var - in ]
param: tamanho [ var - in ]
Campo para carregar arquivos.
campoRadio (var, var, var, var) param: nome [ var - in ]
76
campoCep (var, var, var, var,
var)
campoSenha (var, var, var, var,
var, var)
campoCheckBox (var, var, var,
var, var)
RenderHTML ()
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
Campo de única escolha.
param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: obrigatorio [ var - in ]
param: hifen [ var - in ]
Campo para tratamento de CEP
param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: tamanhovisivel [ var - in ]
param: tamanhomaximo [ var - in ]
param: obrigatorio [ var - in ]
Campo para senha.
param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
param: cols [ var - in ]
Campo Check Box. Múltipla escolha.
Gera o HTML de saida da classe.
Tabela 11. Atributos da Classe formDetalhe
Atributo
largura
detalhe
url_novo
url_editar
url_cancelar
nome_url_novo
nome_url_editar
nome_url_cancelar
Comentário
Largura da tabela que será apresentado o detalhe.
Linhas que serão apresentadas no formulário de detalhe
Destino da página quando se clicar no botão de ação novo.
Destino da página quando se clicar no botão de ação editar.
Destino da página quando se clicar no botão de ação cancelar.
Rotulo do botão novo.
Rotulo do botão editar.
Rotulo do botão cancelar.
Tabela 12. Operações da Classe formDetalhe
Operação
formdetalhe (var)
RenderHTML ()
Comentário
param: nome [ var - in ]
Construtor da Classe.
Gera o HTML apresentado no form de detalhe.
77
Tabela 13. Atributos da Classe formLista
Atributo
largura
linhas
colunas
cabecalho
paginacao
tabulacao
url_novo
nome_url_novo
url_cancelar
nome_url_cancelar
Comentário
Largura da tabela de listagem na página
Array contendo as informações da listagem
Array que contem o alinhamento de cada célula da listagem
Cabeçalho dos campos na listagem
Atributo que informa se existirá ou não paginação na listagem
Array que contem os ítens da tabulação na listagem
Ação do botão novo na listagem
Rotulo do botão novo na listagem
Ação do botão cancelar na listagem
Rotulo do botão cancelar na listagem
Tabela 14. Operações da Classe formLista
Operação
formlista (var)
geraTabulacao (var, var, var)
RenderHTML ()
Comentário
param: nome [ var - in ]
param: campo [ var - in ]
param: tabela [ var - in ]
param: todos [ var - in ]
Gera o HTML apresentado no form de listagem.
Tabela 15. Atributos da Classe formListacomfiltro
Atributo
largura
linhas
colunas
cabecalho
paginacao
tabulacao
url_novo
nome_url_novo
url_cancelar
nome_url_cancelar
campos
informacoes
Comentário
Largura da tabela do formulário Lista com Filtro.
Linhas da listagem (resultados)
Alinhamento das células da listagem.
Cabeçalho da listagem.
Atributo que informa se existirá ou não paginação na listagem
Array que contem os ítens da paginação.
Ação do botão novo no cadastro.
Nome do botão Novo no cadastro.
Ação do botão Cancelar no cadastro.
Nome do botão Cancelar no cadastro.
Campos do Cadastro.
Texto informativo.
Tabela 16. Operações da Classe formListacomfiltro
Operação
formlistacomfiltro (var)
campoOculto (var, var)
Comentário
param: nome [ var - in ]
Construtor da Classe.
param: nome [ var - in ]
param: valor [ var - in ]
Armazena um valor oculto.
78
campoRotulo (var, var, var)
param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
Campo informativo (descrição).
campoTexto (var, var, var, var, param: nome [ var - in ]
var, var)
param: campo [ var - in ]
param: valor [ var - in ]
param: tamanhovisivel [ var - in ]
param: tamanhomaximo [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de um pequeno texto (Edit)
campoData (var, var, var, var) param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de datas.
campoMemo (var, var, var,
param: nome [ var - in ]
var, var, var)
param: campo [ var - in ]
param: valor [ var - in ]
param: colunas [ var - in ]
param: linhas [ var - in ]
param: obrigatorio [ var - in ]
Campo para digitação de textos maiores.
campoLista (var, var, var, var) param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
Campo "Select", para seleção de um dado.
campoArquivo (var, var, var,
param: nome [ var - in ]
var)
param: campo [ var - in ]
param: valor [ var - in ]
param: tamanho [ var - in ]
Campo para carregar arquivos.
campoRadio (var, var, var, var) param: nome [ var - in ]
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
Campo de única escolha.
campoCep (var, var, var, var,
param: nome [ var - in ]
var)
param: campo [ var - in ]
param: valor [ var - in ]
param: obrigatorio [ var - in ]
param: hifen [ var - in ]
Campo para tratamento de CEP
campoCheckBox (var, var, var, param: nome [ var - in ]
var, var)
param: campo [ var - in ]
param: valor [ var - in ]
param: default [ var - in ]
param: cols [ var - in ]
79
RenderHTML ()
Campo Check Box. Múltipla escolha.
Gera o HTML de saída da classe,
Tabela 17. Atributos da Classe htmlBase
Atributo
titulo
secao
expirar
atualizar
Comentário
Título da página
Identificador das páginas geradas pelo framework
Indica se a página deve expirar.
Indica de quanto em quanto tempo a página deve ser atualizada.
Tabela 18. Operações da Classe htmlBase
Operação
htmlBase ()
Login ()
Processar ()
Cabecalho ()
Rodape ()
Corpo ()
CorpoLogin ()
Executar ()
Comentário
Construtor da classe.
Método responsável pelo controle de login.
Processa o conteúdo dos formulários.
Cabeçalho da página (referente ao layout)
Rodapé da página (referente ao layout)
Corpo da página (referente ao layout)
Cabeçalho da tela de login página (referente ao layout)
Executa a página, montando todas as informações e
apresentando ao usuário.
Tabela 19. Atributos da Classe htmlErro
Atributo
mensagem
Comentário
Mensagem de erro que será apresentada quando um erro for
encontrado.
Tabela 20. Operações da Classe htmlErro
Operação
htmlErro (var, var)
Corpo ()
Comentário
param: mensagem [ var - in ]
param: titulo [ var - in ]
Construtor da Classe
Corpo da classe com o layout da mensagem de erro.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
80
APÊNDICE B – CENÁRIOS DOS CASOS DE USO
UC 01 - Cria Projeto
Caso de uso responsável por criar um novo projeto e obter suas características.
Relações
RF01: o sistema deve realizar a importação de um arquivo SQL a cada novo projeto
•
para montar a estrutura de tabelas do banco de dados interna referente à aplicação em
questão.
RF05: o sistema deve permitir ao usuário informar o caminho da classe htmlBase
•
(classe do framework PHPLib-UNIVALI) utilizado para a definição do layout da
aplicação.
Condições
•
Pós Condição: Um projeto foi criado.
Cenários
Criar Projeto {Principal}.
1. Usuário informa dados para criação do projeto (Figura 29);
2. Sistema verifica autenticidade dos dados;
3. Sistema Importa SQL;
4. Sistema cria projeto.
Importa htmlBase {Alternativo}.
No passo 1, caso o usuário tenha informado o caminho do arquivo htmlBase
1.1. Sistema importa arquivo htmlBase.
Arquivo não encontrado {Exceção}.
Se no passo 2 algum arquivo não for encontrado:
2.1.
Sistema
apresenta
mensagem:
<nome_do_arquivo>. Tente novamente!".
2.2. Aborta criação do projeto;
2.3 Retorna ao passo 1.
"Não
foi
possível
encontrar
o
arquivo
Erro SQL {Exceção}.
No passo 3, caso ocorra algum erro na importação do Script SQL:
3.1. Sistema apresenta a mensagem: "Arquivo SQL inválido, não foi possível criar o
projeto!"
3.2. Aborta criação do projeto;
3.3 Retorna ao passo 1.
UC 02 - Abre Projeto
Caso de uso responsável por abrir arquivo com as configurações do projeto.
Relações
•
RF10: o sistema deve implementar a função abrir projeto.
Condições
•
Pré Condição: Algum projeto já deve ter sido criado e salvo em um arquivo de
formato "RHP".
•
Pós Condição: Um projeto foi aberto.
Cenários
Abre Projeto {Principal}.
1. Usuário Informa arquivo que será aberto;
2. Sistema verifica autenticidade do arquivo;
3. Sistema cria estrutura de banco de dados interna da ferramenta através do arquivo de
configuração;
4. Sistema obtem informações de configuração;
5. Sistema abre projeto.
Erro ao abrir arquivo {Exceção}.
Se no passo 2 ocorrer algum erro:
2.1. Sistema apresenta mensagem: "Arquivo corrompido, não foi possível abrir o projeto!".
2.2. Sistema aborta execução.
82
UC 03 - Configura informações de acesso ao Banco de Dados
Caso de uso responsável por alterar as informações utilizadas pela aplicação para acesso ao
banco de dados.
Relações
•
RF06: o sistema deve permitir a configuração de informações de acesso do banco de
dados da aplicação.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: As configurações de acesso ao banco de dados foram realizadas.
Cenários
Configura Informações {Principal}.
1. Usuário informa dados de acesso ao banco de dados (Figura 30);
2. Sistema confere dados;
3. Sistema configura informações;
4. Sistema apresenta mensagem "Configuração do banco de dados realizada com sucesso!".
Limpar Campos {Alternativo}.
Se durante o passo 1 usuário desejar limpar os campos (Figura 30):
1.1. Usuário informa ao sistema que deve limpar os campos;
1.2. Sistema limpa campos.
Erro na senha {Exceção}.
Se no passo 2 as senhas forem diferentes:
2.1. Sistema apresenta mensagem: "Os campos <senha> e <confirma senha> devem ser
idênticos!";
2.2. Sistema aborta execução.
UC 04- Configura criação de listagens
Caso de uso responsável por configurar a criação de listagens a partir da estrutura de banco
de dados interna da aplicação.
83
Relações
•
RF02: o sistema deve permitir a definição de listagens baseado na estrutura de banco
de dados da aplicação.
•
RN04: o sistema deve permitir a configuração dos nomes das páginas geradas,
observando o padrão de sufixos: _lst para listagens; _det para detalhes; e _cad para
cadastros.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: A configuração de uma listagem foi realizada.
Cenários
Configurar Listagem {Principal}.
1. Usuário seleciona tabela (Figura 31);
2. Usuário entra com as informações de configuração da listagem (Figura 31);
3. Usuário entra com as informações dos atributos da listagem (Figura 31);
4. Usuário confirma dados (Figura 31);
5. Sistema configura criação da listagem.
Arquivo já existe {Exceção}.
Se no passo 4 o arquivo já existir:
4.1. Sistema apresenta mensagem: "Arquivo <nome_do_arquivo>_lst.php já existe. Não foi
possível completar esta operação!";
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
Selecionar campo {Exceção}.
Se no passo 4 o sistema verificar que nenhum campo foi selecionado:
4.1. Sistema apresenta mensagem: "Você deve selecionar pelo menos um campo para criar
uma listagem!";
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
84
UC 05 - Configura criação de detalhes
Caso de uso responsável por configurar a criação de detalhes a partir da estrutura de banco
de dados interna da aplicação.
Relações
•
RF03: o sistema deve permitir a definição de detalhes baseado na estrutura de banco
de dados da aplicação.
•
RN04: o sistema deve permitir a configuração dos nomes das páginas geradas,
observando o padrão de sufixos: _lst para listagens; _det para detalhes; e _cad para
cadastros.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: A configuração de um detalhe foi realizada.
Cenários
Configurar Detalhe {Principal}.
1. Usuário seleciona tabela (Figura 32);
2. Usuário entra com as informações de configuração do detalhe (Figura 32);
3. Usuário entra com as informações dos atributos do detalhe (Figura 32);
4. Usuário confirma dados (Figura 32);
5. Sistema configura criação da detalhe.
Arquivo já existe {Exceção}.
Se no passo 4 o arquivo já existir:
4.1. Sistema apresenta mensagem: "Arquivo <nome_do_arquivo>_det.php já existe. Não foi
possível completar esta operação!";
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
Selecionar campo {Exceção}.
Se no passo 4 o sistema verificar que nenhum campo foi selecionado:
4.1. Sistema apresenta mensagem: "Você deve selecionar pelo menos um campo para criar
um detalhe!";
85
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
UC 06 - Configura criação de cadastro
Caso de uso responsável por configurar a criação de cadastros a partir da estrutura de banco
de dados interna da aplicação.
Relações
•
RF04: o sistema deve implementar as funções de inclusão, exclusão e alteração de
dados baseando-se na estrutura de banco de dados interna da aplicação (cadastro).
•
RN01: o sistema deve validar os campos de entrada de dados obrigatórios.
•
RN02: o sistema deve possuir mecanismo para consistir campos do tipo e-mail, data
e CEP durante o processo de entrada de dados.
•
RN03: o sistema deve permitir a definição de rótulos e o tamanho visível do campo
no formulário de cadastro.
•
RN04: o sistema deve permitir a configuração dos nomes das páginas geradas,
observando o padrão de sufixos: _lst para listagens; _det para detalhes; e _cad para
cadastros.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: A configuração de um cadastro foi realizada.
Cenários
Configurar Cadastro {Principal}.
1. Usuário seleciona tabela (Figura 33);
2. Usuário entra com as informações de configuração do cadastro (Figura 33);
3. Usuário entra com as informações dos atributos do cadastro (Figura 33);
4. Usuário confirma dados (Figura 33);
5. Sistema configura criação do detalhe.
Arquivo já existe {Exceção}.
86
Se no passo 4 o arquivo já existir:
4.1. Sistema apresenta mensagem: "Arquivo <nome_do_arquivo>_cad.php já existe. Não foi
possível completar esta operação!";
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
Selecionar campo {Exceção}.
Se no passo 4 o sistema verificar que nenhum campo foi selecionado:
4.1. Sistema apresenta mensagem: "Você deve selecionar pelo menos um campo para criar
um cadastro!";
4.2. Sistema aborta execução;
4.3. Retorna ao passo 2.
UC 07 - Salva Projeto
Caso de uso responsável por salvar arquivo com as configurações do projeto.
Relações
•
RF11: o sistema deve implementar a função salvar projeto.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: Um projeto será salvo.
Cenários
Salvar Projeto {Principal}.
1. Usuário informa ao sistema que deseja salvar o projeto;
2. Sistema verifica se não é a primeira vez que se está salvando o projeto;
3. Sistema Salva projeto.
Salvar pela primeira vez {Alternativo}.
Se no passo 2 for a primeira vez que o projeto é salvo:
2.1. Sistema solicita nome do projeto;
2.2. Usuário informa nome do projeto;
87
2.3. Sistema verifica se arquivo com mesmo nome já existe.
Se arquivo existe:
2.4. sistema apresenta mensagem: "<nome_do_arquivo> já existe. Deseja substituí-lo?";
2.5. Usuário seleciona opção;
Se escolha igual a <Não>:
2.6. Sistema aborta operação;
Retorna ao passo 1;
Se escolha igual a <Sim>:
Retorna ao passo 3
Erro ao salvar {Exceção}.
Se ocorrer algum erro desconhecido durante o processo:
1. Sistema apresenta a mensagem: "Não foi possível realizar esta operação!".
UC 08 - Altera estrutura de tabelas
Este caso de uso descreve os passos para alterar o nome e o comentário de uma tabela, bem
como inserir uma nova tabela na estrutura de banco de dados interna da aplicação.
Relações
•
RF07: o sistema deve permitir adicionar e alterar tabelas na estrutura do banco de
dados interna da aplicação.
•
RN05: o sistema não efetua engenharia reversa a partir das alterações efetuadas na
estrutura de banco de dados interna através da ferramenta.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: A estrutura de uma tabela será alterada.
Cenários
Altera estrutura de tabelas {Principal}.
1. Usuário Seleciona opção de criar ou alterar uma tabela;
2. Sistema verifica opção selecionada pelo usuário:
88
Se opção igual a "Nova Tabela":
Executa fluxo "Nova Tabela";
senão:
Executa fluxo "Editar Tabela";
3. Sistema verifica autenticidade dos dados;
4. Sistema efetua alterações na estrutura de tabelas.
Nova Tabela {Alternativo}.
1. Usuário Insere os dados referentes a tabela (Figura 40- a);
Retorna ao passo 3 do fluxo principal.
Editar Tabela {Alternativo}.
1. Sistema Insere os dados referentes a tabela;
2. Usuário altera os dados referentes a tabela (Figura 40 - a);
Retorna ao passo 3 do fluxo principal.
Tabela já existe {Exceção}.
Se no passo 3 tabela com mesmo nome já existe.
3.1. Sistema apresenta mensagem: "Tabela <nome_da_tabela> já existe. Tente novamente!";
3.2. Sistema aborta operação.
Erro ao alterar tabela {Exceção}.
Se no passo 3 ocorrer algum erro com o nome da tabela:
3.1. Sistema apresenta mensagem: "Nomes de tabelas não podem possuir acentos ou
caracteres especiais. Tente novamente!";
3.2. sistema aborta execução.
UC 09 - Altera estrutura de atributos
Este caso de uso descreve os passos para editar um atributo existente , bem como inserir um
atributo em uma tabela da estrutura de banco de dados interna da aplicação.
Relações
•
RF08: o sistema deve permitir adicionar e alterar atributos nas tabelas da estrutura do
banco de dados interna da aplicação.
89
•
RN05: o sistema não efetua engenharia reversa a partir das alterações efetuadas na
estrutura de banco de dados interna através da ferramenta.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: A estrutura de atributos de uma tabela será alterada.
Cenários
Alterar estrutura de atributos {Principal}.
1. Sistema lista os atributos existentes;
2. Usuário altera o atributo desejado (Figura 40 - b);
3. Sistema insere dados referentes ao atributo;
4. Sistema confere dados;
5. Sistema altera estrutura de atributos do banco de dados interno da aplicação.
Adicionar Atributo {Alternativo}.
No passo 2
2.1. Usuário seleciona a opção adicionar;
2.2. Usuário insere dados referentes ao atributo (Figura 40 - b);
Retorna ao passo 4.
Campo já existe {Exceção}.
Se no passo 4 campo com mesmo nome já existe na mesma tabela.
4.1. Sistema apresenta mensagem: "Campo <nome_do_campo> já existe nesta tabela. Tente
novamente!";
4.2. Sistema aborta operação.
Erro ao alterar atributo {Exceção}.
Se no passo 4 do fluxo principal for encontrado algum com o nome do campo:
4.1. Sistema apresenta mensagem: "Nomes de campos não podem possuir acentos ou
caracteres especiais. Tente novamente!";
4.2. sistema aborta execução.
90
UC 10 - Define Consultas SQL
Este caso de uso descreve os passos para alterar ou inserir uma nova consulta SQL.
Relações
•
RF09: o sistema deve permitir a definição de consultas simples em formato SQL.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: Uma consulta é definida.
Cenários
Define Consultas {Principal}.
1. Usuário seleciona opção de criar ou alterar uma consulta;
2. Sistema verifica opção selecionada pelo usuário:
Se opção igual a "Nova Consulta":
Executa fluxo "Nova Consulta";
senão:
Executa fluxo "Editar Consulta";
3. Sistema define consulta SQL para uso em listagens.
Nova Consulta {Alternativo}.
1. Usuário insere os dados referentes a consulta (Figura 39);
Retorna ao passo 3 do fluxo principal.
Editar Consulta {Alternativo}.
1. Sistema insere os dados referentes a consulta;
2. Usuário altera os dados referentes a consulta (Figura 39);
Retorna ao passo 3 do fluxo principal.
Configura criação de Listagem para consulta {Alternativo}.
1. Usuário seleciona consulta;
2. Usuário entra com as informações de configuração da listagem para a consulta
selecionada (Figura 39);
3. Usuário entra com as informações dos atributos da listagem;
91
4. Usuário confirma dados (Figura 39);
5. Sistema configura criação da listagem para consulta selecionada.
Arquivo já existe {Exceção}.
Se no passo 4 do cenário "Configura criação de Listagem para consulta" o arquivo já existir:
4.1. Sistema apresenta mensagem: "Arquivo <nome_do_arquivo> já existe. Não foi possivel
completar esta operação!";
4.2. Sistema aborta execução;
Retorna ao passo 2.
Selecionar Campo {Exceção}.
Se no passo 4 do cenário "Configura criação de Listagem para consulta" o sistema verificar
que nenhum campo foi selecionado:
4.1. Sistema apresenta mensagem: "Você deve selecionar pelo menos um campo para criar
uma listagem a partir de uma consulta!";
4.2. Sistema aborta execução;
Retorna ao passo 2.
UC 11 - Gera Código
Este caso de uso descreve os passos para geração do código fonte da aplicação configurada
pelo usuário.
Relações
•
RF12: o sistema deve gerar código da aplicação de acordo com as configurações do
usuário.
Condições
•
Pré Condição: Ter um projeto aberto ou criado.
•
Pós Condição: O código fonte PHP baseado no framework PHPLib-UNIVALI foi
gerado.
Cenários
Gera código {Principal}.
92
1. Sistema apresenta lista de arquivos que podem ser gerados;
2. Usuário seleciona o caminho para gerar os arquivos (Figura 34);
3. Usuário seleciona os arquivos a serem gerados (Figura 34);
4. Sistema gera o código da aplicação (substituindo os arquivos já gerados, caso eles
existam).
Nenhum arquivo selecionado {Exceção}.
Se no passo 3 nenhum arquivo foi selecionado:
3.1. Sistema apresenta mensagem: "Você deve selecionar pelo menos um arquivo para gerar
o código da aplicação!";
Retorna ao passo 3.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
93
APÊNDICE C – XML SCHEMA DA FERRAMENTA RADPHP
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by rth77 (rth77) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="infoProject">
<xs:sequence>
<xs:element name="projectName" type="xs:string"/>
<xs:element name="layout" type="xs:string" minOccurs="0"/>
<xs:element name="userName" type="xs:string" minOccurs="0"/>
<xs:element name="password" type="xs:string" minOccurs="0"/>
<xs:element name="ipServer" type="xs:string" minOccurs="0"/>
<xs:element name="serviceName" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="infoList">
<xs:sequence>
<xs:element name="title" type="xs:string" minOccurs="0"/>
<xs:element name="buttons" type="valueButtons" minOccurs="0" maxOccurs="3"/>
<xs:element name="paging" type="xs:boolean"/>
<xs:element name="attributesList" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="attributeID" type="xs:int" minOccurs="0"/>
<xs:element name="caption" type="xs:string" minOccurs="0"/>
<xs:element name="link" type="xs:string" minOccurs="0"/>
<xs:element name="parameterAttribute" type="xs:int" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="referenceTableList" type="referenceTable" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="orderAttribute" type="xs:int" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="infoDetail">
<xs:sequence>
<xs:element name="title" type="xs:string" minOccurs="0"/>
<xs:element name="buttons" type="valueButtons" minOccurs="0" maxOccurs="3"/>
<xs:element name="attributesDetail" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="attributeID" type="xs:int" minOccurs="0"/>
<xs:element name="caption" type="xs:string" minOccurs="0"/>
<xs:element name="referenceTableDetail" type="referenceTable" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="infoRegister">
<xs:sequence>
<xs:element name="title" type="xs:string" minOccurs="0"/>
<xs:element name="buttons" type="valueButtons" minOccurs="0" maxOccurs="3"/>
<xs:element name="attributesRegister" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="attributeID" type="xs:int" minOccurs="0"/>
<xs:element name="caption" type="xs:string" minOccurs="0"/>
<xs:element name="visibleSize" type="xs:int" minOccurs="0"/>
<xs:element name="obligatory" type="xs:boolean" default="false"/>
<xs:element name="type" type="xs:string">
<xs:annotation>
<xs:documentation>Tipo do Campo do Cadastro</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="referenceTableRegister" type="referenceTable" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="valueButtons">
<xs:restriction base="xs:int">
<xs:enumeration value="0"/>
<xs:enumeration value="1"/>
<xs:enumeration value="2"/>
<xs:enumeration value="3"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="referenceTable">
<xs:sequence>
<xs:element name="attributeID" type="xs:int"/>
<xs:element name="tableID" type="xs:int"/>
</xs:sequence>
</xs:complexType>
<xs:element name="radPHP">
<xs:annotation>
<xs:documentation>RADPHP root element</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="project" type="infoProject"/>
<xs:sequence maxOccurs="unbounded">
<xs:element name="tables">
<xs:complexType>
<xs:sequence>
<xs:element name="table" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="tableName" type="xs:string"/>
<xs:element name="tableComment" type="xs:string" minOccurs="0"/>
<xs:element name="fileName" type="xs:string" minOccurs="0"/>
<xs:element name="attribute" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="attributeID" type="xs:int"/>
<xs:element name="attributeName" type="xs:string"/>
<xs:element name="attributeType" type="xs:string"/>
<xs:element name="attributeSize" type="xs:float" minOccurs="0"/>
<xs:element name="attributeisNull" type="xs:boolean"/>
<xs:element name="primaryKey" type="xs:boolean"/>
<xs:element name="foreignKey" type="referenceTable"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="list" type="infoList" minOccurs="0"/>
<xs:element name="detail" type="infoDetail" minOccurs="0"/>
<xs:element name="register" type="infoRegister" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="queries" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="query" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="queryName" type="xs:string"/>
<xs:element name="querySQL" type="xs:string"/>
<xs:element name="pageTitle" type="xs:string" minOccurs="0"/>
<xs:element name="fileName" type="xs:string"/>
<xs:element name="paging" type="xs:boolean"/>
95
<xs:element name="buttons" type="valueButtons" minOccurs="0"
maxOccurs="3"/>
<xs:element name="atrtibutesList" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="caption" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Figura 41. XML Schema da ferramenta RADPHP
[FIM DE SEÇÃO. Não remova esta quebra de seção]
96
APÊNDICE D – PONTOS DE FUNÇÃO DO SISTEMA DE
PATRIMÔNIO
Função do Tipo Dado
Arquivo Interface Externa (AIE)
Não consta na aplicação
Arquivo Lógico Interno (ALI)
Arquivo
Número de
referenciado
registros lógicos
setor
1
status
1
responsavel
1
patrimonio
1
Qtd. Dados
referenciados
3
2
4
6
Grau da Função
Simples
Simples
Simples
Simples
Total PF
7
7
7
7
28
Função do Tipo Transação
Entrada Externa
Arquivo referenciado
Incluir setor
Alterar setor
Excluir setor
Incluir status
Alterar status
Excluir status
Incluir responsável
Alterar responsável
Excluir responsável
Incluir patrimônio
Alterar patrimônio
Excluir patrimônio
Número de
registros lógicos
1
1
1
1
1
1
1
1
1
4
4
4
Qtd. Dados
referenciados
2
2
2
1
1
1
3
3
3
5
5
5
Grau da Função
Simples
Simples
Simples
Simples
Simples
Simples
Simples
Simples
Simples
Complexa
Complexa
Complexa
Total PF
3
3
3
3
3
3
3
3
3
6
6
6
45
Saída Externa
Não consta função com dados derivados.
Consulta Externa
Arquivo referenciado
Listagem setor
Listagem de status
Listagem de responsável
Listagem de patrimônio
Detalhe setor
Detalhe status
Detalhe responsável
Detalhe patrimônio
Consulta Resp. por Patrimônio
Número de
registros lógicos
1
1
1
2
1
1
1
4
2
Qtd. Dados
referenciados
1
1
2
2
3
2
4
6
2
Grau da
Função
Simples
Simples
Simples
Simples
Simples
Simples
Simples
Complexa
Simples
Total PF
3
3
3
3
3
3
3
6
3
30
Pontos por Função Bruto: 103
Fatores de Ajuste
Fatores
Pontos
4
0
0
0
0
5
3
1
0
1
0
0
0
0
1. Comunicação de Dados
2. Processamento de Dados Distribuídos
3. Execução
4. Configuração Altamente Usada
5. Índice de Transação
6. Entrada de Dados On-line
7. Eficiência do Usuário Final
8. Atualização On-line
9. Processamento Complexo
10. Reutilização
11. Fácil Instalação
12. Fácil Operação
13. Sites Múltiplos
14. Alterações Facilitadas
Total Nível de Influência
Fator de ajuste = (14 * 0,01) +0,65
Fator de ajuste = 0,79
PF ajustados = 103 * 0,79
PF ajustados = 81 pf
Sendo PA = PF ajustados e h = hora.
PA = pf/h
PA = 81/(13/60)
PA = 373 pf/h
Sendo PB = PF brutos e h = hora.
PB = pf/h
PB = 103/(13/60)
PB = 475 pf/h
[FIM DE SEÇÃO. Não remova esta quebra de seção]
98
14
ANEXO I – ARTIGO