1

10

1. INTRODUÇÃO

A cada ano que passa mais pessoas tem contato com a internet, e novas ferramentas e
serviços são criados para suprir as necessidades criadas por estes internautas. Com o avanço e
aprimoramento das tecnologias web(linguagens de programação e recursos áudio visuais) e o
aumento da largura de banda, muitas aplicações do desktop1 tem migrado para plataforma
web, outras têm sido desenvolvidas exclusivamente para esta, como é o caso do google, que
disponibiliza a seus usuários uma suíte de escritório via web, contendo os principais recursos
de uma suíte para desktop como o Open Office, outro exemplo são os conversores de vídeos
online como o keepvid.com, sendo que com os sistemas de gerenciamento ou sistema de
apoio a tomada de decisões não é diferente. Os benefícios das aplicações web são vários, entre
eles o espaço em disco, pois geralmente não é necessário instalar nada, os arquivos da
aplicação são alocados em uma máquina remota e executados a partir da mesma,
disponibilidade e acesso dos dados em qualquer parte do mundo, total independência de
sistema operacional e atualizações centralizadas apenas no servidor. A grande dificuldade e
frustração de alguns programadores desktop ao migrarem para a plataforma web é a falta de
ferramentas simples que realmente ajudem no processo de desenvolvimento, pois na
plataforma web o leiaute é criado a partir de código, além de desenvolver as funcionalidades
da aplicação, isso tudo torna o desenvolvimento uma tarefa bastante trabalhosa, cansativa e
monótona. Outras ferramentas através de uma interface gráfica, e com alguns click's
conseguem gerar todo o leiaute porém o código fonte é todo sujo e cheio de coisas
desnecessárias, o que prejudica o desempenho e sua manutenção é quase impossível.

1.1 Justificativa

Estas dificuldades de aprendizado e inovação das Soft-Houses e dos programadores

levam a uma necessidade de oferecer uma ferramenta que elabore partes de um sistema de
apoio a tomada de decisão para a plataforma Web (coleta e manutenção de dados) através de
um modelo padrão de leiaute, simples e de fácil manutenção, e que esta ferramenta seja de
código fonte aberto, facilitando a troca do leiaute padrão ou até mesmo a linguagem de código
fonte gerado (alvo) que é PHP, por alguma outra, como Ruby, Phyton, JSP, etc, oferecer ao

1 Área de trabalho – nesse caso se refere a plataforma de computadores pessoais.

 11

programador a opção de adicionar mais funcionalidades tornando-o personalizado para

atender, suas próprias necessidades, além de servir como material de estudo e aprimoramento.
O código fonte e outros componentes estão disponível em
http://code.google.com/p/indigophp/ e http://br.geocities.com/shini_quake/indigophp.html

1.2 Objetivos

1.2.1 Objetivo geral

Construir uma ferramenta de código fonte aberto, que automatize alguns processos
repetitivos na construção de websites que utilizem tecnologia PHP com banco de dados
relacional.

1.2.2 Objetivos específicos

•Utilizar tecnologia orientada a objetos tanto na análise quanto na programação.

•Utilizar threads para melhorar o desempenho do software;
•Agilizar o desenvolvimento de aplicações web através um modelo padrão bem estruturado,
simples e fácil de manutenção;
•Desenvolver um aplicativo que tenha total independência de qualquer banco de dados;
 12

2. REVISÃO LITERÁRIA

2.1 Linguagem de Programação.

No geral uma linguagem é um conjunto de símbolos e regras que um determinado

grupo usa para comunicar-se internamente ou externamente com outros grupos distintos, por
meio de uma linguagem que ambos tenham conhecimento. Com a linguagem de programação
não é diferente, ela é responsável pelo intercâmbio entre o programador e o dispositivo
(computador, celular, PDA2 etc) a ser programado. Pode-se resumir as principais
características de uma linguagem de programação em poucas palavras, porém estas
informações, expressão muito do seu funcionamento e de uma forma generalizada como um
compilador trata seus aspectos intrínsecos.

•Tipagem estática: A linguagem é dita tipada de forma estática quando a verificação dos tipos
de dados(variáveis, objetos), é feita em tempo de compilação.
•Tipagem Dinâmica: A linguagem é dita tipada de forma dinâmica quando verificação dos
tipos de dados é feito em tempo de execução(runtime).
•Tipagem fraca: É quando os tipos de dados não são bem definidos ou se misturam, não é
necessário associar o tipo de dado há variável, pois o compilador/interpretador se encarrega
de faze esse tipo de verificação.
•Tipagem forte: É quando os tipo de dados são bem definidos, também é necessário de forma
explicita associar o tipo de dado há variável.
Outra característica importante é forma do artefato gerado, em linguagens
interpretadas, são gerados bytecodes3, que são interpretados por uma maquina virtual e que
posteriormente serão traduzidos em linguagem de maquina. A grande vantagem de linguagens
interpretadas é escrever um código fonte para diversas plataformas com pouca ou nenhuma
mudança no mesmo. Já linguagens compiladas geram arquivos executáveis especificamente
para uma plataforma, isso garante uma alta performance de velocidade sobre as linguagens
interpretadas porém isso impede sua portabilidade, deve-se ao fato de que o código compilado
ser executado sem passar por um intermediário(maquina virtual). O numero de paradigmas
que a linguagem oferece é relevante, algumas linguagens de programação tem diversas
2 Personal digital assistant – assistente pessoal digital.
3 Arquivo intermediário entre linguagem natural estruturada e linguagem de maquina
 13

finalidades e são utilizadas para desenvolver qualquer tipo de programa, outras são bem
restritas como é caso de lisp e prolog que são utilizadas na área de inteligencia artificial.

2.2 Paradigma Orientado a Objetos.

O conceito de programação orientada por objetos não é novo. No final da década de

60, a linguagem Simula67, desenvolvida na Noruega, introduzia conceitos hoje encontrados
nas linguagens orientadas a objetos como encapsulamento. Em meados de 1970, o Centro de
Pesquisa da Xerox (PARC) desenvolveu a linguagem Smalltalk, a primeira totalmente
orientada a objetos. No início da década de 80, a AT&T lançaria a Linguagem C++, uma
evolução da linguagem C em direção à orientação a objetos.
A programação orientada a objetos simula atributos e comportamentos(métodos) de
coisas do mundo real, tirando apenas a característica principais, dessa forma se constrói um
objeto que ira se relacionar/comunicar com outros dentro de um sistema . Diferente da
programação estruturada onde tudo se baseia em funções, parâmetros de retorno e a
descentralização, (caso ocorra um mudança em alguma função sera necessário mudar em
todas as outras que tiverem alguma dependência dessa “função subprincipal”, por exemplo
onde um parâmetro era do tipo int e agora passou a ser string as mudanças serão em varias
partes do código acarretando na prática mais erros ou incompatibilidades. Já na programação
orientada a objetos basta apenas mudar o tipo dos atributos, pois todas as classes descendentes
irão herdar a mudança de tipo ou ainda sobrecarregar o método afim de manter
compatibilidade com versões antigas do mesmo.
A programação orientada a objetos tem como principais objetivos reduzir a
complexidade no desenvolvimento de software e aumentar sua produtividade. A análise,
projeto e programação orientadas a objetos são as respostas para o aumento da complexidade
dos ambientes computacionais que se caracterizam por sistemas heterogêneos, distribuídos em
redes, em camadas e baseados em interfaces gráficas.

2.2.1 Conceitos.

• Visibilidade: existem três tipos de visibilidade para atributos/métodos são eles private,
protected e public.
 14

• Private: O mais restrito de todos, apenas a classe proprietária pode acessar seu
métodos/atributos.
• Protected: O meio termo entre private e public, somente a classe proprietária e suas
descendentes pode visualizar esse tipo atributos/métodos.
• Public: De livre acesso ou seja, qualquer classe pode acessar seus atributos/métodos.
• Abstração: Criação de um modelo de dados abstraindo(coletando/observando) as
principais características e comportamentos de um objeto do mundo real.
• Classe: Coleção de atributos e métodos de uma abstração da realidade, que definem o
objeto e seu comportamento. São divididas em dois grupos classes concretas que
geram instancias e classes abstratas que não geram instancias.
• Objeto: Em POO4 é uma instancia de classe, já na AOO5 pode ser qualquer coisa do
mundo real.
• Encapsulamento: Permite que tanto atributos e métodos sejam privados de
determinada classe, sendo que somente ela terá acesso a tais, Dessa forma garante o
isolando de um possível erro não propagando-o. “ O mecanismo de encapsulamento é
a forma de restringir o acesso ao comportamento interno do objeto”. (BEZERA, 2003,
pg.9).
• Herança: Reutilização de atributos e métodos comum entre classes. “Existem diversas
similaridades entre diferentes classes. Com muita freqüência duas ou mais classes
compartilharam os mesmo atributos e/ou os mesmo métodos. Pelo fato de não
querermos ter que fica escrevendo o mesmo código varias vezes, necessitamos tirar
vantagens destas similaridades”. (AMBLER, 1998, pg.8).
• Polimorfismo: A capacidade do objeto/atributo/método, de ter varias formas distintas
porém pertencendo a mesma classe(sobrecarga) ou hierarquia(sobrescrita). “O
polimorfismo indica a capacidade de abstrair varias implementações diferentes em
uma única interface” (BEZERA, 2003, pg.10). Polimorfismo geralmente é expressado
por uma relação de generalização ou especialização sobre um(a) classe/objeto/método.
• Mensagem: A forma como os objetos comunicam-se uns com os outros.
• Persistência: Garante a integridade (estado atual) do objeto, após ser destruído da
memoria, quando o objeto foi instanciado novamente ele carregará todos os valores de
atributos que tinha antes de ser destruído. Um bom exemplo é restauração de abas do

4 Programação orienta a objetos.

5 Análises orientada a objetos.
 15

firefox6. “A persistência descreve as questões de como salvar os objetos para

armazenamento permanente” (AMBLER, 1998, pg.9).
• Coesão: Ocorre quando uma classe interage com outra porém não conhece os detalhes
de implementação dessa ultima.
• Acoplamento: É a medida de quanto uma classe depende de outra. Em um projeto
orientado a objetos é recomendável tem baixo acoplamento e alta coesão, pois a
manutenção de código será mais fácil e flexível a algumas mudanças.

2.3 UML.

A UML7 se originou de várias metodologias distintas, tendo forte influência de três. O

método Booch de Grady Booch, a Técnica de Modelagem de Objetos(OMT) de co-autoria de
James Raumbaugh e OOSE 8de Ivar Jacobson, também conhecidos com os três amigos. Eles
elaborarão a primeira versão da UML em 1994, já em 1997 ela, foi aceita pelo OMG9.
Atualmente a UML se encontra na versão 2.0.
UML é uma linguagem, ou seja (ela possui semântica e sintaxe), para especificação,
documentação, visualização e construção de sistemas orientados a objetos, provendo vários
diagramas que tratam da parte estática e dinâmica do sistema. Estática diagrama de classes,
componentes, estrutura composta, objetos, implantação e artefatos. Dinâmica diagrama de
caso de uso, seqüências, comunicação, gráfico de estados e atividades. “A UML é apenas uma
linguagem e, portanto é somente uma parte de um método para desenvolvimento de
software.”( BOOCH; RUMBAUGH; JACOBSON, 2005, pg.13).

2.3.1 Principais diagramas.

“la finalidade de los diagramas es presentar diversas perspectivas de un sistema, a la

cuales se le conece como modelo.”(SCHMULLER, 2000, pg.8).
• Diagrama de classes : Esse diagrama mostra de forma estática todas as classes, seus
métodos e atributos e seus respectivos relacionamentos. Alguns exemplos de
relacionamentos são agregação, composição e associação.
6 Navegador web.
7 Unified Modeling Language
8 Object Oriented Software Enginnering.
9 Object Manager Group.
 16

• Diagrama de caso de uso: Tem a função de mostrar os requisitos funcionais do sistema

independente da implementação. “documento narrativo que descreve a seqüência de
eventos de um ator que usa um sistema para completar um processo “(BOOCH;
RUMBAUGH; JACOBSON, 2005, pg.13).
• Diagrama de estado: Documenta o comportamento de classes/objetos/atributos,
sistemas e subsistemas e a comunicação dos mesmos com agentes externo, sua idéia
principal lembra o funcionamento de automato.
• Diagrama de interação: Responsável por ilustrar a comunicação entre os objetos.
“Diagramas de interação tem seu foco em mensagens especificas entre objetos e em
como essas mensagens vem juntas para realizar um funcionalidade”(PILONE, 2006,
pg.125).

2.4 Ferramenta Case.

Alguns dos principais objetivos de uma ferramenta case10 são documentar a análise e
automatizar tarefas triviais ou repetitivas no desenvolvimento de um software. Algumas
ferramentas são capazes de gerar código fonte baseado na análise, enquanto outras apenas
documentam análise. Existem três tipo de ferramentas case.
•Lower case - ferramentas de codificação.
•Upper case - ferramentas de análise, projeto e implementação .
•Integrated case - união de upper e lower case.

2.5 PHP.

PHP acrônimo recursivo para PHP hypertext preprocessor, é uma linguagem de

programação interpretada, de tipagem fraca e dinâmica e oferece suporte à orientação a
objetos, que ao final gera scripts11 tendo eles as mais diversas finalidades desde um simples
captcha12 a complexas instruções SQL's, diferentemente de linguagens compiladas como o C
que geram um executável.
Entretanto o PHP tem pouca ou nenhuma relação com leiaute da página, seu trabalho é

10 Computer-Aided Software Engineering - Engenharia de Software Auxiliada por Computador

11 Código fonte interpretado.
12 Mecanismo usando em antispams, e autenticações. Que teoricamente somente um humano pode resolver.
 17

invisível para o usuário final.

O PHP executa seus scripts no lado servidor da aplicação ou seja, o cliente somente
recebe uma página com o código HTML resultante da execução do PHP. Como a página
resultante contém unicamente código HTML, é compatível com todos os navegadores.
“Dentro de uma página HTML, você pode embutir código PHP que será executado toda a vez
que página for visitada. O código PHP é interpretado no servidor Web e gera HTML ou outra
saída que o visitante verá”(WELLING, LUKE, 2002, pg.XXVII).

2.6 Banco de Dados Relacional.

“O banco de dados relacional é um banco de dados visto pelos usuários como um

conjunto de tabelas (e nada além de tabelas).”(DATE, 1990, pg.100). Existem três conceitos
básicos empregados pelo modelo de entidade-relacionamento, são eles, conjunto de entidades
(database), conjunto de relacionamentos e atributos.
• Entidade: Consiste no processo de identificar objetos concretos ou abstratos do
mundo real que tem alguma importância dentro de um contexto
especifico(negócio). As entidades são “coisas” da realidade, que são
transpostas(abstração) para um modelo computacional/conceitual, sendo apenas
coletado suas características principais. “Defini-se entidade como aquele objeto
que existe no mundo real com uma identificação distinta e com um significado
próprio. São “coisas” que exitem no negócio, ou ainda descrevem o negócio em
si.”(RODRIGUES, ABREU, 1996, pg.32).
• Atributos: Também conhecidos como campos. Nada mais é que as características
de um objeto ou de uma entidade, tendo como exemplo o documento CPF seus
atributos são: nome do portador, número de inscrição e data de nascimento ou de
modo mais clássico entidade cliente: nome, endereço, data de nascimento, rg, cpf
entre outros atributos.
• Relacionamentos: Ou cardinalidade. É a forma como duas ou mais entidades se
relacionam. Existem três tipos: um-para-um: “Neste grau de relacionamento, cada
elemento de uma entidade relaciona-se com um e somente um elemento de outra
entidade”(RODRIGUES, ABREU, 1996, pg.54). Exemplo um filho(a) tem apenas
uma única mãe biológica. Uma-para-muitos: Encontrado com maior freqüência no
 18

processo de modelagem. Um elemento da entidade “A” relaciona-se com vários

outros elementos da entidade “B”. Tomando o exemplo filho/mãe, na primeira
visão temos a seguinte afirmativa, uma mãe pode ter vários filho(a)s, já na segunda
visão, um filho(a) pode ter somente uma única mãe biológica. E o ultimo muitos-
para-muitos. Onde vários elementos da entidade “A” se relacionam com vários
outros elementos de “B”. Exemplo: muitos acadêmicos cursam muitas disciplinas,
mas alguns acadêmicos podem estar cursando uma única ou mais disciplinas. Uma
disciplina é cursado por muitos acadêmicos, ou nenhum. O relacionamento de
muitos-para-muitos, logo será “quebrado” pelas normativas e se tornara um
relacionamento de um-para-muitos.
Alguns atributos podem ter certas restrições como aceitar ou não valores nulos, ter
uma valor padrão caso valor seja nulo, existe também um atributo que recebe o nome de
chave primaria que é capaz identificar exclusivamente cada ocorrência de uma entidade,
sendo que uma chave primaria nunca pode ter um valor nulo.
* Dependência de existência.
* Dependência de identificador.
“Dizemos que uma entidade é fraca se um desses dois tipos de dependência se
verificar entre uma entidade A e uma entidade B.”(COUGO, 1997, pg.53).

2.7 Normalização de Banco de Dados.

“O conceito de normalização foi introduzido para o modelo relacional por Edgar. F.

Codd em 1970 (primeira forma normal). Esta técnica é um processo matemático que tem seus
fundamentos na teoria dos conjuntos”.(MACHADO, 2001, pg.88). Ao todo existem 6 formas
normais, que tem o objetivo de “filtrar” anomalias de inclusão, alteração e exclusão, como
redundância dados, e também possíveis dependências etc. Neste trabalho é apenas
apresentado as três primeiras.
Existem quatro tipos de dependências:
• Dependência funcional: É um relacionamento entre dois ou mais
atributos(campos) de uma mesma entidade, que o valor de um atributo identifique
o valor para cada um dos outros atributos.
• Dependência funcional total: Ocorre apenas quando a chave primária for composta
 19

por vários atributos, ou seja um atributo ou conjunto depende de forma total desta
chave primária concatenada. Quando a dependência é de parte dessa chave
primária concatenada denomina-se dependência funcional parcial.
• Dependência funcional transitiva: Ocorre quando um atributo “X” depende de
outro ”Y” que não faça parte da chave primária, porém “Y” é dependente
funcional da mesma.

2.7.1 Primeira forma normal (1FN).

A 1FN caracteriza-se por remover grupos repetitivos de uma determinada entidade.

Para cada tabela, eliminar os grupos repetitivos gerando uma nova tabela na qual
cada um dos itens repetitivos dará origem a uma nova linha e na qual a chave
primária será a concatenação da chave da tabela original com uma nova coluna que
identifique de modo unívoco a linha. (COUGO, 1997, pg.191).

2.7.2 Segunda forma normal (2FN).

Os critérios para um entidade estar na segunda forma normal são, primeiramente estar
na primeira formal e não possuir atributos que tenham dependência parcial dessa chave.

2.7.3 Terceira forma normal (3FN).

“Podemos afirmar que uma estrutura está na terceira Forma Normal, se ela estiver na
segunda Forma Normal e não possuir campos dependentes de outros campos não
chaves.”(MACHADO, 2001, pg92).

2.8 SQL.

SQL é uma linguagem de quarta geração, é um padrão para manipulação de banco de

dados, diferente de outras linguagens como C, Java, PHP etc, em SQL o programador “diz o
que deve ser feito” e “não como”. Em 1974 nasceu na IBM13 o SEQUEL14 um protótipo de
linguagem para banco de dados, posteriormente SEQUEL/2 e finalmente SQL, “Com o peso
do nome IBM por trás desses produtos, ela consegue fazer com que 'sua' linguagem de
consulta estruturada SQL torne-se o padrão de mercado.”(MANZANO, 2002, pg.18).
13 Internacional Business Machine
14 Structured English Query Language.
 20

Com o amplo uso de banco da dados a partir da década de 80, muito fabricantes
começaram a introduzir dialetos de SQL nos seus produtos, distorcendo o padrão inicial. Uma
nova padronização foi proposta pela ANSI15, denominado SQL/86. No ano de 1987 a ISO16
passa a trabalhar com ANSI na padronização do SQL, após dois anos outro padrão é criado o
SQL/89, ao longo dos anos foram criados outras normativas SQL/92, SQL/99 e a última em
2003.
A linguagem SQL é composta por 3, 4 e até mesmo 5 grupos de instruções conforme o
autor, no presente trabalho será adotada a abordagem de 4 grupos são eles:
17
• DDL (Data Definition Language). Permite ao administrador de banco dados cria,
alterar e excluir entidades ou grupos de entidades, seus principais comandos são,
create, alter e drop.
• DML18(Data Manipulation Language). Possibilita manipular registros de uma
determinada entidade, seus principais comandos: insert, update e delete.
• DCL19 (Data Control Language). Restringe ou permite privilégios de acesso dos
usuários. Como por exemplo ter controle total sobre determinada entidade ou apenas
visualiza-la(somente leitura). Principais comandos grant e revoke.
• DQL20 (Data Query Language). Permite fazer consultas em grupos de entidades, a
DQL possui apenas um comando o select porém o existe varias clausulas que
oferecem maiores opções para manipulação de dados facilitando a vida do DBA.21
Algumas clausulas são: where, distinct, like, count, sum, between, entre outros. O
select é comando mais usado em SQL.

2.9 Geração de Código.

Mas o que exatamente seria uma gerador de código fonte? É uma técnica de
construção de programas para escrever outros programas, muitas vezes a linguagem usada
para desenvolver o gerador é diferente do produto final, um exemplo concreto disso é criar
geradores para construção e manipulação de base de dados ou procedimentos remotos. A idéia

15 American National Standards Institute.

16 Internacional Standards Organizations.
17 Linguagem de Definição de Dados.
18 Linguagem de Manipulação de Dados .
19 Linguagem de Controle de Dados.
20 Linguagem de Consulta a Dados.
21 Administrador de Banco de Dados.
 21

central é criar um código consistente, de alto nível e genérico, pois sua reutilização será
maior, com isso algumas etapas triviais ou repetitivas do projeto podem ser executas com
maior rapidez.
“Code generation takes over the task of writing repetitive infrastructure code, leaving
more time for engineers to concentrate on the interesting programming challenges that they do
enjoy”(HERRINGTON, 2003, pg.XVII).
As vantagens de usar geradores de código, está em usar um templete22 básico e dar ao
usuário algumas opções, a criação do código final é feita de modo instantâneo, a estrutura do
código gerado é de fácil manipulação e depuração ou seja qualidade de código, com isso a
produtividade de criação de um software23 ou pagina web24 é bem maior.

2.10 Ciclo de Vida do Software.

O ciclo de vida, refere-se a todas as atividades realizadas para idealização e construção

do software, o termino ocorre quando não é mais possível manter o software no mercado,
diversos fatores podem acarretar ou acelerar sua morte, dentre os principais podemos citar a
dificuldade na manutenção de um código fonte arcaico, aspectos legais, inovações da
concorrência, altos requisitos de hardware, etc. As etapas do ciclo de vida de um software são
as seguintes:
• Concepção: Surgimento de um conceito ou solução para um determinado problema.
• Construção: Análise e codificação.
• Implantação: Nessa etapa ocorrem testes, e o cliente tem os primeiros contatos com
software. Os desenvolvedores ou o analista de negócios ensinam o método de como
trabalhar com a ferramenta.
• Implementações: Ajustes em alguns requisitos, correção de bug25's.
• Ápice: Utilização plena com o minimo de erros possíveis, funcionalidades e conceitos
bem desenvolvidos.
• Declínio: Requisitos funcionais já ultrapassados, dificuldade ou falta comunicação
com novos sistemas ou aplicativos.
• Manutenção: Re-analise das regras de negocio e um possível estudo de sua viabilidade
22 Molde ou modelo padrão.
23 Programa de computador.
24 Relativo a internet.
25 Erros.
 22

de implementação(codificação) e seus efeitos colaterais.

• Morte: Pode ocorrer por não mais atender as necessidades do cliente ou
descontinuidades de atualizações por parte dos desenvolvedores.

Desde primórdios, o software, é construído/elaborado de forma artesanal devido a

complexidade das duas primeiras gerações de linguagens de programação, primeira geração:
(linguagem de maquina), o programador era obrigado a trabalhar com o mais baixo nível, ou
seja registradores, bit's e muitas seqüências de zeros e uns conseqüente a depuração desse
código era extremamente cansativa e sujeita a novos erros. Segunda geração: (linguagens de
montagem ou simbólica)
“Para minimizar as dificuldades da programação em notação binaria. Códigos de
operação e endereços binários foram substituídos por mnemônicos. Nas linguagens
de montagem, a maioria das instruções são representações simbólicas de instruções
de maquina”(PRICE; TOSCANO, 2005, pg.2).
Mesmo com o advento das linguagens de 3ª geração (linguagens procedurais,
declarativas ou imperativas), que propiciavam um maior nível de abstração deixando os
programadores/analistas preocuparem-se mais com a modelagem das regras de negocio do
que a complexidade de implementar uma determinada função em notação binaria, entre outros
aspectos de baixo nível. Com grande freqüência o processo de desenvolvimento do software
estourava o prazo imposto e por conseqüência disso seu custo dobrava ou até mesmo
quadruplicava, para tenta resolver esse problema e tentar industrializar o processo de
desenvolvimento de software(da mesma forma que a revolução industrial mudou a forma do
processo de produção que era realizado de forma artesanal e passou a ser industrializado com
a ajuda de maquinas, essa mesmo conceito de cria linhas produção seria aplicado de forma
eficiente no processo de desenvolvimento de software, quanto na Inglaterra do século XVIII?)
Foram propostos alguns modelos de ciclo de vida, entre eles:
• Modelo linear ou cascata: Proposto por Royce na década de 70 foi a primeira tentativa
de padronizar o processo de concepção do software, esse modelo sugere cinco etapas
sendo elas viabilidade, requisitos, projeto, implementações, testes. Caso ocorra alguma
mudança o processo deve recomeçar, sendo que todas as suas etapas são executas de
forma não paralela.
• Prototipagem: O objetivo desse modelo é analisar e implementar um fragmento dos
requisitos funcionais em um curto espaço de tempo e exibir esse protótipo ao cliente,
com isso é possível observar se os requisitos funcionais implementados pelos
 23

programadores, são os mesmos desejados ou próximos do esperado pelo cliente, a

principal vantagem sobre o modelo em cascata é o tempo em relação as interações e a
continua validação dos requisitos funcionais e não funcionais impostos pelo cliente.
• Modelo Espiral: O modelo em espiral pode levar ao desenvolvimento em paralelo de
múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é
necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem
como para determinar os indicadores de custo e progresso mais adequados.

3. METODOLOGIAS DE DESENVOLVIMENTO
 24

3.1 Levantamento de Dados

3.1.1 Tipo de pesquisa.

O presente trabalho é de natureza aplicada, tem como objetivo o desenvolvimento de

um software, um codegen26.

3.1.2 Arquitetura do Programa.

• Monousuário.
• A atual versão é executada em plataforma Win3227.
• Não da suporte a rede, sendo executado na máquina local.
• Uso de threads28 em algumas tarefas.

3.1.3 Requisitos Funcionais de Software.

• O programa deve possuir um mecanismo para criação de um novo projeto.

• O programa deve possuir um recurso para edição de um projeto.
• O programa deve possuir um mecanismo para salvar todas as informações do projeto
em um arquivo.
• O programa deve prover um mecanismo para abrir um projeto salva anteriormente.
• O programa deve prover um mecanismo, que contenha todas as restrições para se criar
uma entidade, como por exemplo: ter uma chave primaria, não possuir campos com o
mesmo nome, etc.
• O programa deve prover uma estrutura para a criação de entidades.
• O programa deve prover uma estrutura para a remoção de entidades.
• O programa deve prover um mecanismo para adição de um novo campo na entidade.
• O programa deve prover um mecanismo para edição de campo já existente na
entidade.
26 Gerador de código.
27 Referente ao sistemas operacional Windows
28 Processos leves, no Unix seria um processo filho.
 25

• O programa deve prover um mecanismo para remoção de um campo em uma

determinada entidade.
• O programa deve oferecer uma forma para salvar os scrips SQL's em forma de
arquivo.
• O programa deve prover um mecanismo para criação de um formulário.
• O programa deve prover um mecanismo para criação de um arquivo de listagem,
conforme os critérios de seleção do usuário.
• O programa deve prover um mecanismo para criação de um arquivo que contenha as
instruções de adicionar, remover e remover registros de uma determinada entidade.
• O programa deve prover um mecanismo para configuração de configuração das
strings de conexão do banco de dados.
• O programa deve oferecer um mecanismo para apenas a adição de arquivos CSS29.
• O programa deve oferecer um recurso para edição do título da pagina, o uso desse
recurso é extensível tanto para o formulário quanto para a listagem.
• O programa deve oferecer uma estrutura para criação de um novo formulário, sendo
que este terá uma listagem e um arquivo do UID30.
• O programa deve prover um mecanismo para remoção de um formulário.
• O programa deve prover um recurso para adição de uma novo tag, em um determinado
formulário.
• O programa dever oferecer uma maneira de o usuário editar tag's, sendo apenas edita
uma por vez.
• O programa deve prover uma forma para remover tag's.
• O programa deve prover um mecanismo que por finalidade gerar os arquivos os três
PHP's no diretório escolhido pelo usuário.
• Deve haver um mecanismo que evita o usuário fechar o programa enquanto as
modificações de um determinado item não sejam concluídas.

3.1.4 Requisitos Não Funcionais.

• O programa dever ter como cor de fundo o branco seguindo o padrão “industrial” do
windows xp/vista, para facilitar interação do usuário com software.

29 Cascading Style Sheets,

30 Update, insert e Delete.
 26

• O programa deve oferecer teclas de atalho para algumas tarefas, pois geralmente
usuários avançados tem maior preferencia por teclas de atalho.
• O programa dever mostrar metáforas das principais funcionalidades, para torna a
interface gráfica, mais agradável e facilitar memorização/associação das
funcionalidades, dessa forma o aprendizado do usuário é mais rápido. em outras
palavras tornar a interface mais intuitiva possível.
“A idéia básica é que já que os computadores estão substituído muitas
ferramentas formalmente utilizadas pelas pessoas de negócios – pastas de
arquivos para arquivar papeias com informações, cadernos com números de
de telefones, agendas para organizar compromissos e cesta lixo para
descartar objetos desnecessários – então seus sistema deveria se parecer
com as ferramentas que está substituindo. Isso fará com que seja mais fácil
de ser compreendido e aprendido por qualquer pessoa que já esteja
familiarizada com as ferramentas do mundo real que ele esta
substituindo.”(AMBLER, 1998, pg.276).
• O programa deve exibir dicas de ajuda, quando o mouse passar sob um controle
gráfico(botões, caixas de texto, combos etc).
• Utilizar threads.
• O programa deve oferecer suporte à dois ou mais idiomas, sendo a língua natural o
padrão(português-BR), o segundo o inglês.
• O programa dever possuir um splash31.
• O programa deve possuir um arquivo de ajuda.

3.1.5 Ferramentas Utilizadas.

• Object Pascal, linguagem para o desenvolvimento do software.

• StarUML, Ferramenta case para criação dos diagramas UML.
• Jude, Ferramenta case para criação dos diagramas UML.
• Visual Paradign,Ferramenta case para criação dos diagramas UML.
• Help & manual, para criação do arquivo de ajuda.

3.2 Análise do Software.

Devido a escolha de desenvolver um aplicativo com tecnologia orientada a objetos, a

linguagem utilizada para diagramação será a UML, pois é a notação padrão para modelos

31 Splash/Splash screen Tela de abertura.

 27

orientados a objetos além de oferece vários níveis(visões) de detalhamento sobre o projeto do

software .
 28

3.2.1. Diagrama de Classe.

 29

Ilustração 1 - Diagrama de classe

 30

3.2.2. Diagrama de Caso de Uso, demostrando todos os requisitos funcionais de software.

 31

Ilustração 2 - Diagrama de casos de uso

3.2.3. Diagrama de caso de uso, demonstrando os casos de uso do software.

 32

Ilustração 3 - Diagrama de casos de uso

3.2.4. Diagrama de seqüência, do caso de uso CarregarProjeto.

3.2.5. Diagrama de Seqüência, caso de uso NovaEntidade.

Ilustração 4 - Diagrama de seqüência CarregarProjeto

 33

Ilustração 5 - Diagrama de seqüência NovaEntidade

3.2.6. Diagrama de Seqüência, do caso de uso NovoModulo.

 34

Ilustração 6 - Diagrama de seqüência NovoModulo

3.2.7. Diagrama de Estado.

Ilustração 7: Ilustração- Diagrama de estado

Devido a ausência de classes/objetos e grupo de atributos/métodos relevantes para se

modelar estados, a última alternativa foi modelar o comportamento de um sistema/subsistema.
 35

De uma forma simplificada é ilustrado o funcionamento do sistema.

•<<Retorno>>: Esse esterótipo refere-se a finalização da tarefa independente de sucesso ou
falha, o sistema ficará 'inativo' esperando uma nova ação/tarefa do usuário.
•<<EditarModulo( )>> e <<EditarEntidade( )>> : Neste diagrama de estado entende-se como
as ações de incluir, alterar e remover entidades ou módulos.
•NumeroModulo e NumeroEntidade: É a quantidade total de módulos/entidades que compõe o
atual projeto.

4. IMPLEMENTAÇÃO DO SOFTWARE

4.1 Tutorial

• 1.0. Na tela inicial existem 3 opções.

• 1.1. Carregar projeto, o usuário, escolhe o arquivo já salvo, para modificar alguma
entidade/formulário ou ainda gerar os arquivos novamente.
• 1.2. Nova entidade. Essa tela oferece ao usuário, uma forma fácil e rápida para cria
entidades.
• 1.3 Novo Formulário. Permite o usuário, configurar as tags do fomulário e gerar os
arquivos “.php”.
• 2.0 Nova Entidade.
• 2.1. Primeiramente deve-se criar uma entidade, clicando no primeiro botão da
esquerda para a direita que tem um pequeno sinal de “+” verde, após isso será
visualizada uma caixa de texto que pede o nome da entidade.
• 2.2. Após criada a entidade o próximo passo é adicionar um campo, sendo
obrigatório preencher, seu nome, o tipo de campo, o tamanho/precisão, as
constrainsts32, não obrigatórias com exceção que no minimo um
atributo(campo/coluna) ou mais devem formar uma chave primaria de uma

32 Restrições.
 36

entidade.
• 2.3. A edição de um campo é feita da seguinte forma o usuário, executa um duplo
click sobre o campo que deseja modificar, para aplicar as modificações o usuário
dever clicar no quarto botão da esquerda para a direita que possui um engrenagem
e uma chave de fenda, concluindo assim o processo de edição do campo
selecionado.
• 2.4. A exclusão, pode ser tanto de uma entidade quanto de apenas um campo, o
usuário deve selecionar a entidade ou campo clicando sobre ela(e), e clicar no
terceiro botão que possui uma listra vermelha, no caso de uma entidade sera
exibido um aviso de confirmação, no caso de um campo o aviso não é exibido.
• 2.5. Após criada as entidades e seus respectivos campo, é possível gera os arquivos
contendo suas estruturas, exitem duas extensões .txt e .sql, clicando no quinto
botão da esquerda para direita, será mostrada um caixa de dialogo onde o usuário
deve escolher o diretório e o nome dos arquivos e clicar em salvar.
• 3.0. Novo Formulário.
• 3.1. O primeiro passo é criar um formulário, clicando no primeiro botão da esquerda
para a direita, que tem um pequeno sita de “+” verde, após isso será exibida uma caixa
de texto pedindo o nome do formulário.
• 3.2. O próximo passo é definir as strings de conexão, que estão cituadas na aba
“Conexão DB”, após o preenchimento deve-se clicar no botão que possui o ícone de
um plug de tomada, ele é o quinto botão da esquerda para direita, para concluir essa
etapa.
• 3.3. É possível configura um título tanto para o formulário quanto para listagem,
clicando na aba “Misc”, informando os respectivos títulos e clicando no botão “OK”.
• 3.4. Para adicionar uma tag, o usuário deve preencher todos os campos, e clicar no
segundo botão da esquerda para direita, para adicionar a nova tag.
• 3.5. Exclusão pode ser tanto de um formulário inteiro quanto de apenas uma tag,
usuário dever selecionar o formulário/tag, e clicar no terceiro botão da esquerda para
direita que possui o ícone de uma listra vermelha, no caso de um formulário sera
exibido um aviso de alerta, caso seja escolhida uma tag o aviso não é exibido.
• 3.6. A edição de uma tag, funciona da seguinte forma, o usuário executa um duplo
click sobre o item desejado, após as modificações o usuário deve clicar no quarto
 37

botão da esquerda para a direita que possui um ícone de uma engrenagem e uma chave
de fenda para efetuar as mudanças.
• 3.7. Existe a opção de importar arquivos css para decorar o formulário e a listagem, o
usuário deve clicar no sétimo botão da esquerda para a direita que possui o ícone de
uma folha verde, após isso sera exibida um caixa de dialogo onde o usuário deve
indicar quais os arquivo que deseja importar e clicar em abrir para terminar essa etapa.
• 3.8. Para gerar os arquivos .php o usuário deve clicar no sexto botão da esquerda para
a direita, após isso sera exibida uma caixa de dialogo onde o usuário deve informar
qual o diretório será salvo os arquivo, e seus respectivos nomes, clicando em salvar,
para efetuar o termino dessa etapa.

4.2 Padronizações.

Objetos são reconhecidos no código tendo, uma abreviatura de seu tipo mais um
sublinhado '_', após o sublinhado '_' é descrito a finalidade do objeto. Ex: Btn_Fix: botão
responsável por aplicar as modificações.
Variáveis são reconhecidas pela seguinte padronização, tem suas duas primeiras letras
identificando o tipo de dado, diferente de um objeto a variável não possui um sublinhado '_',
ou seja o tipo de dado e o nome da variável ficam concatenado. Ex:InE: contador de entidades
no projeto sendo do tipo integer.

4.3. Relação dos Programas.

Unit_Code.pas Possui todas as classes a serem utilizadas.

Unit_File.pas Responsável por criar os arquivos .php e os scripts SQL
Unit_Main.pas Responsável por instanciar o objeto principal, carregar um projeto já salvo
Unit_DB.pas Oferecer uma interface para o usuário criar/modificar entidades.
Unit_Pack.pas Oferece uma interface para o usuário criar/modificar tag's dos formulários
Unit_Splash.pas Contém o splash.

4.4 Fluxo de Telas.

 38

Ilustração 8 - Fluxo de telas do software, demostrado por

um diagrama de estado.
4.5 Telas do Programa

4.5.1. SplashScreen.

Ilustração 9 - SplashScreen

4.5.2. Tela Principal do Programa.

39
40
41
42
43
44
45
46
 47

Ilustração 10 - Tela Principal

4.5.3. Tela para criação de entidades.

 48

Ilustração 11 - Tela para criação e edição de entidades.

4.5.4. Tela para criação de módulos.

 49

Ilustração 12 - Tela para criação e edição de módulos.

4.5.5. Tela para salvar o projeto e os módulos.

 50

Ilustração 13 - Tela para salvar o projeto e seus módulos.

4.5.6. O modelo básico de um formulário gerado pelo programa.

 51

Ilustração 14 - Exemplo de um formulário de coleta de dados no internet explorer

Ilustração 15 - Exemplo de um formulário de coleta de dados no SeaMonkey

4.6 Código Fonte.

 52

4.6.1. GeraHTML

Ilustração 16 - Código fonte do método GeraHTML

•Linhas 8-12, verificam se as strings de conexão foram preenchidas, se estiverem vazias é

mostrado para o usuário o mensagem sugerindo as strings padrão.
•Linha 13, chama o método para adicionar as strings de conexão.
•Linha 14, chamada recursiva do próprio agora com as strings de conexão já preenchidas.
•Linha 18, chama o método responsável por salvar o projeto e todos os seus módulos.
•Linha 19-26, é feito um laço de repetição para salvar todos os módulos, as linhas seguintes
são criadas as threads, que tem a responsabilidade de criar os arquivos .php.

4.6.2. CarregarProjeto.
 53

Ilustração 17 - Código fonte do método Reload.

•Linhas 7-10, configuração das propriedades da janela.

•Linha 11, é mostrada a janela, OpDlg_Arq.execute retorna um booleano caso o usuário clicar
em cancelar os códigos a seguir não são executados.
•Linha 16, é criado um stream de memoria.
•Linha 17, após o arquivo de projeto ser selecionado, o seu conteúdo é transformado em um
FileStream.
•Linha 18 e 20, a forma como os streams serão lidos.
•Linha 19, converte o FileStream em um MemoryStream.
•Linha 21, o objeto projx recebe o cast33 da leitura do MemoryStream.
•Linha 22-23, destruição dos streams.

4.6.3 GeraUID.

33 Transformação/conversão do tipo de dado.

 54

Ilustração 18 - Código fonte do método GeraUID.

•Linhas 17-19, inicialização das variáveis.

•Linhas 19-21, configuração das propriedades da janela.
•Linha 23, o nome padrão do arquivo será o nome do modulo mais o sufixo “_UID”.
•Linhas 25-29, é feita a verificação se o arquivo existe caso sim o arquivo será subscrito sem
perguntar ao usuário.
 55

Ilustração 19 Código fonte do método GeraUID(continuação)

•As linhas descritas abaixo mostram como é criada a estrutura de um insert.

•Linhas 31-34, como o arquivo ainda não existe será exibido ao usuário uma janela solicitando
o diretório e o nome do arquivo.
•Linha 37, o arquivo é re-criado.
•Linhas 38-45, é escrito o cabeçalho do arquivo .php.
•Linhas 49-53, ByPos recebe o valor do ultimo elemento que contenha um campo do banco de
 56

dados.
•Linha 55, é escrito no arquivo, os campo do banco de dados.

Ilustração 20 Código fonte do método GeraUID(continuação)

•Linha 86, é exibido a forma de criação da estrutura de um update, os passos são semelhantes
ao do insert.
•Linha 112, o arquivo é fechado com seu conteúdo já salvo.
 57

5. CONCLUSÃO

O software orientado a objetos é diferente do software convencional. Dentre os muito

benefícios existentes no desenvolvimento orientado a objetos, estão a simplificação de
requisitos, projetos e implementações. Esses benefícios são alcançados pela modelagem do
domínio do problema com objetos que representam as abstrações importantes, pelo
encapsulamento das funções com os dados, pela reutilização de objetos dentro de um projeto e
entre projetos e tendo uma solução que é muito mais próxima intelectualmente do problema.
No desenvolvimento de software algumas tarefas se tornam repetitivas e ocupam
consideravelmente o tempo da equipe de desenvolvimento, muitas vezes por maus hábitos ou
distrações, programadores deixa passar erros simples ou pior ainda escreve um código
“primitivo” executam alguns testes(geralmente casos de sucesso) e replicam o esse código por
todo o software. Algumas vezes esse erro demora para ser corrigido, como esse código foi
replicado, a solução também será replicada. A solução por sua vez também pode gerar alguma
efeito colateral, causando um efeito dominó, conseqüentemente tempo do projeto se esgota e
seu custo se eleva mais que o planejado. O modelo padronizado prove uma arquitetura de
camadas, minimizando a área de procura de erros e inibindo maus hábitos como copiar e colar
código fonte e adaptar, é mais rápido e menos perigoso gerar o modelo padronizado do que
substituir certas partes do códigos.
Nas construção de um software, é comum utilizar bibliotecas de arquivos externas,
banco de dados ou componentes/pacotes de terceiros, porém estes podem causar um
dependência parcial ou total das funcionalidades, ou ainda no pior dos casos o não
funcionamento do aplicativo. Outro problema que pode ocorrer é a incompatibilidade de
novas versões das dependências com o software já desenvolvido, pois os fabricantes podem
remover ou modificar arquivos, funções, pacotes etc. Minimizar essas dependências oferecem
menores chances de ocorrer erros nesse aplicativo em uma determinada plataforma,
dependendo da tecnologia utilizada a ausência destes pré-requisitos aumentar o grau de
portabilidade.
A utilização de geradores de código fonte é bastante produtiva, quando a ferramenta se
adequa as necessidades do usuário e não o contrario, em uma arquitetura fechada ou
proprietária o custo do desenvolvimento é bastante elevado pois, muitas funcionalidades
 58

devem ser elaboradas e mantidas para atende a grande parte das necessidades dos usuários e
uma pequena porção de especializações voltada para pouco ou nenhum publico. Em contra
partida uma arquitetura aberta oferece a possibilidade de personalização do software,
pequenas mudanças ou poucas funcionalidades podem realmente atender as necessidades
daquele usuário em especifico, outras vantagens são o tempo de correção de erros que é muito
menor ao ser comparado com um produto proprietário, diversidade de funcionalidades
criadas pelos membros da comunidade do software em questão pois varias pessoas ao redor
do mundo o utilizam e trabalham em sua manutenção.

5.1 Implementações Futuras.

•Refatorar classes e métodos.

• Integrar o gerador de folhas de estilo.
•Oferecer suporte a PostgreSQL.
 59

6. REFERÊNCIA BIBLIOGRAFIA

AMBLER, W. S. Análise e projeto orientado a objetos: Seu guia para desenvolver sistemas
com tecnologia de objetos volume 2. 1.ed. Rio de Janeiro: IBPI Press, 1998.

BEZERA, E. Princípios de análise e projeto de sistemas com UML. 2.ed. : .2003

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do usuário. 2.ed.:2005.

COUGO, P. Modelagem conceitual e projeto de banco de dados. 1.ed. : Campus. 1997.

DATE, J. C. Introdução a sistemas de banco de dados. 4.ed. :Campus. 1990.

GUSTAFSON, D.A. Teoria e problemas de engenharia de software. 1.ed. São Paulo:

Bookman. 2003.

HERRINGTON, J. Code Generation in action. 1.ed. Manning: Greenwich.2003

MACHADO, F. N. R.; ABREU. Análise relaciona de sistemas. 1.ed. São Paulo: Érica. 2001.

MACHADO, F. N. R.; ABREU, M. Projeto de banco de dados uma visão prática. 5.ed. São
Paulo: Érica. 1996.

MANZANO, J. A. N. G. Estudo dirigido de SQL. 1.ed. : Érica. 2002.

MACORATTI, J. C. UML - Conceitos Básicos II. Disponível em

http://www.macoratti.net/vb_uml2.htm. Acesso em 08 set. 2008.

NOGUEIRA, A. Estados. Disponível em http://imasters.uol.com.br/artigo/3711/uml/estados/.

Acesso em 08 set. 2008.

NOGUEIRA, A. Casos de uso (cenários). Disponível em

 60

http://imasters.uol.com.br/artigo/3811/uml/casos_de_uso_cenarios/. Acesso em 08 set. 2008.

NOGUEIRA, A. Histórico da UML. Disponível em

http://imasters.uol.com.br/artigo/2994/uml/historico_da_uml/. Acesso em 08 set. 2008.

NOGUEIRA, A. Classes. Disponível em http://imasters.uol.com.br/artigo/3607/uml/classes/.

Acesso em 08 set. 2008.

PILONE, D.; PITMAN, N. UML 2 Rápido e prático. 1.ed. Rio de Janeiro: Alta Books. 2006.

PRESSMAN, R. S. Engenharia de Software. 1.ed. Rio de Janeiro: Makron Books. 1995.

PRICE, A . M; Toscani, S. S. Implementação de linguagens de programação: Compiladores. 3.

ed. Rio Grande do Sul: Sangra Luzzatto, 2005.

RUP. Diretrizes: Diagrama de Estados. Disponível em

http://www.wthreex.com/rup/process/modguide/md_stadm.htm. Acesso em 08 set. 2008

RUP. Diretrizes: Diagrama de Seqüência. Disponível em

http://www.wthreex.com/rup/process/modguide/md_seqdm.htm. Acesso em 08 set. 2008

REZENDE, D.A. Engenharia de software e sistemas de informações. 1.ed. Rio de Janeiro:

Brasport. 1999.

SCHMULLER, J. Aprendiendo UML em 24 horas. 1.ed. Edo. De México: PrenticeHall. 2000

VELOSO DE MATOS, A . UML: Prático e descomplicado. 2.ed. São Paulo: Érica. 2002.

WELLING, L.; THOMSON, L. PHP Mysql Desenvolvimento web. 2.ed. : Campus. 2003.