Gerador De Código Fonte Para Php

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 7 8 9

Navegador web. Unified Modeling Language Object Oriented Software Enginnering. 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

especifico(negócio). As

alguma entidades

importância são

“coisas”

dentro da

de

um

realidade,

contexto 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 muitospara-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: •

DDL

17

(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 16 17 18 19 20 21

American National Standards Institute. Internacional Standards Organizations. Linguagem de Definição de Dados. Linguagem de Manipulação de Dados . Linguagem de Controle de Dados. Linguagem de Consulta a Dados. 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.

•

22 23 24 25

Manutenção: Re-analise das regras de negocio e um possível estudo de sua viabilidade

Molde ou modelo padrão. Programa de computador. Relativo a internet. 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. •<>:

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 •Linha

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

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.