| Últimas 20 atualizações de FABIO GOMES ROCHA |
|
|
Muito se discute sobre projeto de software, mas ainda temos muitos problemas, principalmente quando tratamos sobre os requisitos. O Relatório do Standish Group denominado Chaos, indica que 42% dos projetos foram entregues fora do prazo previsto, ainda indica que 21% dos projetos foram um fracasso total, e somente 37% dos projetos foram bem sucedidos. Segundo o relatório, parte das falhas é devida a problemas de requisitos, desta forma, é de suma importância para a equipe saber levantar e gerenciar requisitos.
Temos de tomar cuidado para não entendermos algo que não é a realidade do que o cliente necessita.
Figura 1: Imagem clássica sobre diferentes visões de um requisito
A NBR/ISO possui normas que tratam sobre o ciclo de vida e o processo de engenharia de requisitos, entre as normas temos: NBR/ISO/IEC 25001 – Requisitos e avaliação da qualidade de produto de software, NBR/ISO/IEC 25020 – Requisitos e avaliação da qualidade do produto de software e NBR/ISO/IEC 12207 – Processos de ciclo de vida de software. Mas além das normas, outras organizações também trabalham no processo de engenharia de requisitos, mas uma que será destacada aqui neste artigo é a IREB ou International Requerements Engineering Board. Fundada por especialistas independentes com extensa experiência na Engenharia de Requisitos de Software, a IREB criou então uma certificação, a Certified Professional for Requirements Engineering (CPRE), esta certificação se baseia em um currículo, possuindo metas e parâmetros padronizados de qualidade para a engenharia de requisitos. A IREB então dividiu a certificação em níveis, o Foundation é o nível de entrada, depois é possível fazer o Advanced Level em Modelagem ou em Elicitação.
Mas como isso ajuda no requisito de software?
Bem, o IREB disponibiliza um manual para a certificação, e este manual é gratuito e pode ser utilizado não só para a certificação, mas também para o aperfeiçoamento do profissional de engenharia de requisitos. O manual possui uma divisão de conhecimento e de domínio e utilização, facilitando o estudo do profissional.
Desta forma, o objetivo é melhorar o nível da engenharia de requisitos, reduzindo o numero de problemas dos projetos, devido a problemas de requisitos, lembrando a premissa de Pressman de que quanto antes achar o erro, menor é o custo do erro, ou seja, se encontrarmos o erro na fase de levantamento de requisitos, o custo é menor do que encontrar o erro na fase de entrega do produto. A engenharia de requisitos é composta por cinco fases, sendo a elicitação, análise e negociação de requisitos, documentação, verificação e validação.
Figura 2: Fases da engenharia de requisitos
A engenharia de requisitos depende de processos, entre os processos temos:
Elicitação de requisito: é o processo de descoberta do requisito. Como muitas vezes o usuário não tem ao certo o que quer do produto, é a etapa mais complicada, que pode utilizar técnicas como entrevistas, brainstorming, entre outros para atingir o objetivo, ou seja, descobrir os requisitos que o sistema deve possuir. Esta descoberta pode passar por problemas, logo, é indicado que após a elicitação, seja fei
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Atualmente, muito se fala sobre qualidade de software, os desenvolvedores por vezes não sabem se estão no caminho certo. Para esclarecer um pouco sobre este assunto, neste artigo vamos tratar alguns pontos principais sobre este tema.
A história do teste de software começa há muito tempo, mas foi em 1957 que o conceito de teste se tornou o processo de detecção de erros e não de verificar se o software funciona, e foi em 1979 que Myers produziu os primeiros trabalhos complexos sobre o processo de teste. Nesta época já se dizia que o teste deveria ser a intenção de encontrar erros. Com o passar dos anos, os projetos foram tendo mais e mais problemas devido à complexidade dos sistemas, segundo Bartié “Mais de 30% dos projetos são cancelados antes de serem finalizados e mais de 70% dos projetos falham nas entregas de funcionalidade”. Estas falhas criaram um ambiente caótico e problemático para os gestores, desta forma, criou-se a necessidade de implementação de processos de qualidade, que busquem estabelecer procedimentos que sirvam de garantia e gerenciamento de qualidade. Assim surgiram modelos como o CMM (Capability Maturity Model), que foi definido pelo Instituto de Engenharia de Software (SEI), descrevendo uma estrutura de trabalho. Esta estrutura possui itens necessários para tornar o processo eficiente e controlado.
O modelo é dividido em cinco níveis do inicial ao otimizado, os níveis são sequenciais, desta forma, uma empresa para atingir o ultimo nível, deve ter passado por todos os níveis anteriores.
O nível dois do CMM já define o processo gerencial de qualidade de software, o que demanda processos de testagem.
Os testes devem provar que algo não funciona, e são essenciais para o sucesso do processo de qualidade de software.
“ Os testes unitários podem resolver entre 30% a 50% dos defeitos dos programas, os testes de sistemas podem remover entre 30% a 50% dos defeitos remanescentes, desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% dos defeitos. Por último, as revisões de códigos podem reduzir entre 30% e 30% desses defeitos.” Myers in Bastos, 2002.
A realização de testes desde o início do desenvolvimento é algo aconselhado não só pelas metodologias ágeis, mas como pode ser visto em Myers, indicado para a garantia de qualidade, visto que os testes são realizados do início ao final do processo de desenvolvimento.
O processo de teste atua dentro de uma visão de qualidade como o PDCA no momento de check, mas em desenvolvimento, é possível realizar testes em todos os processos, do fazer (testes unitários) até o planejamento.

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Muito se fala sobre metodologias ágeis, mas há necessidade de utilização de algumas técnicas para que estas metodologias tenham sucesso, uma das técnicas é a integração continua.
A integração contínua é um termo originado na metodologia ágil XP e utilizado em diversas metodologias, consistindo em algo simples: o desenvolvedor integra o código alterado e/ou desenvolvido ao projeto principal na mesma frequência com que as funcionalidades são desenvolvidas, sendo feito muitas vezes ao dia ao invés de apenas uma vez. O objetivo principal de utilizar a integração contínua é verificar se as alterações ou novas funcionalidades não criaram novos defeitos no projeto já existente. A prática da integração contínua pode ser feita através de processos manuais ou automatizados, utilizando ferramentas como o Jenkins, Hudson entre outros.
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler
Para a utilização continua, é importante que a equipe possa trabalhar em grupo, para isso é importante que se tenha um sistema de controle centralizado de versão.
Controle de versão e Integração continua
Como parte crucial no processo de desenvolvimento e, para o sucesso da integração contínua, o controle de versão deve ser utilizado. Sendo que um dos objetivos do controle de versão é o trabalho colaborativo, em que diversos desenvolvedores trabalham em conjunto e compartilhando dados. O controle de versão é essencial para metodologias como o XP, em que a equipe deve trabalhar em conjunto constantemente.
O sistema de controle de versão resolve um grande problema quando trabalhamos em equipe:
- como compartilhar as informações de forma a ter a última versão válida e ainda saber quem fez as alterações;
- como prevenir que os desenvolvedores refaçam o trabalho já desenvolvido, etc.
Para solucionar estes problemas, existe um conjunto de ferramentas para controle de versão centralizado, entre elas temos o CVS, Subversion, Git, entre outros. Estas ferramentas permitem aos desenvolvedores trabalharem em conjunto, possuindo um Servidor central responsável pelo versionamento do sistema e possibilitando que vários clientes possam acessar, visualizar, modificar e enviar novos códigos se for necessário.
CVS:
Subversion:
Git:
- http://git-scm.com/
- https://github.com/
- http://gitref.org/
Entre os benefícios da utilização de um sistema de controle de versão, temos:
- possibilidade de restaurar versões anteriores do sistema;
- comparar códigos;
- gestão de alteração, etc.
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Entre as metodologias ágeis que existiam antes do manifesto ágil, o FDD “Feature Driven Developement” é uma delas. Concebido originalmente por Jeff de Luca, o FDD surgiu em Singapura, entre os anos de 1997 e 1999 com base no método Coad (Criado por Peter Coad – 1980/1990) e nos processos interativos e lean já utilizados por Jeff de Luca.
O FDD busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do sistema. É pratico para o trabalho com projetos iniciais ou projetos com codificações existentes. Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia. O FDD atua muito bem em conjunto com o Scrum, pois o Scrum atua no foco do gerenciamento do projeto e o FDD atua no processo de desenvolvimento.
O FDD possui cinco processos básicos.
- Desenvolvimento de modelo abrangente (Análise orientada por objetos);
- Construção de lista de funcionalidades (Decomposição funcional);
- Planejar por funcionalidade (Planejamento incremental);
- Detalhe por funcionalidade (Desenho orientado a objetos);
- Construção por funcionalidade (Programação e teste orientado a objetos).
Assim como acontece na metodologia XP, o FDD faz uso de teste de software. Desta forma é possível utilizar TDD, aliás, é indicada a utilização deste para manter a qualidade do software.
O FDD, assim como a teoria de sistemas afirma, entende que a soma das partes é maior do que o todo. Desta forma, apesar de criar um modelo abrangente baseado no todo que será desenvolvido, esta fase inicia-se com o detalhamento do domínio do negócio com divisão de áreas que serão modeladas. O modelo só está pronto quando todos da equipe estiverem de acordo, o planejamento é feito com base na lista de funcionalidades. Se fossemos trabalhar com FDD em conjunto com o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de usuários a serem desenvolvidas.
Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este planejamento é incremental. Isto em conjunto com o Scrum, deve ser analisado como etapa de desenvolvimento do incremento, então este planejamento é feito com base no que será desenvolvido naquele incremento.
Vamos novamente ao Scrum, separando o que será feito na Sprint. Colocamos no backlog da Sprint. O que está no backlog da sprint são funcionalidades que serão desenvolvidas durante a sprint (que pode ser de duas a quatro semanas), estas tarefas são então planejadas com maior rigor, neste ponto, temos então o planejamento incremental, ou seja, planejamos apenas o que vamos desenvolver. Nesta etapa os envolvidos no processo resumem-se apenas à equipe, ou seja, os desenvolvedores, analistas, testadores, etc., que vão atuar no processo. Eles devem selecionar os itens com base no tempo que eles possuem e nas qualificações atuais da equipe.
Após o planejamento, é feito o detalhamento, nesta fase é de extrema importância que o de
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Metodologias ágeis existem há anos, desde a década de 80, mas algumas informações passam por distorções, fato que dificultou no início a utilização das metodologias. Por conseguinte, desenvolvedores passaram a entender a metodologia ágil como algo que tudo se pode, ou seja, podemos desenvolver sem documentação, sem padrão e sem cuidado. Isto não é verdade, as metodologias ágeis podem trazer sucesso ao projeto, e são utilizadas inclusive na indústria. Como exemplo temos o modelo de produção enxuta da Toyota, que é uma forma ágil de produção e que evita o desperdício. Apesar das metodologias existirem, foi em 2001 que um grupo formado por Kent Beck e mais dezesseis renomados desenvolvedores assinaram o MANIFESTO PARA O DESENVOLVIMENTO ÁGIL DE SOFTWARE e o grupo foi batizado de aliança dos ágeis.
O manifesto ágil pode ser acessado em: http://manifestoagil.com.br/ e possui a seguinte base:
- Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
- O software funcionando é mais importante do que uma documentação completa;
- A colaboração com e dos clientes acima de apenas negociações de contratos e;
- Respostas a mudanças acima de seguir um plano.
Isso não quer dizer que documentação não seja importante e que os processos e as ferramentas sejam inúteis, significa que o item a esquerda é mais valorizado, apenas isto.
“A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes”. (Pressman, 2011)
Pressman cita que uma das prioridades é a entrega, mas qual é o cerne de ser ágil?
Segundo Ivar Jacobson “Atualmente, agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo é ágil. Uma equipe ágil é aquela rápida e capaz de responder apropriadamente a mudanças. Mudanças têm muito a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudanças nos membros da equipe, mudanças devido a novas tecnologias, mudanças de todos os tipos que poderão ter um impacto no produto que está em construção ou no projeto que cria o produto. Suporte para mudanças deve ser incorporado em tudo o que fazemos em software, algo que abraçamos porque é o coração e a alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar, estão no cerne do sucesso do projeto.”
Um projeto envolve pessoas e mudanças, principalmente quando falamos de entregas constantes. Desta forma as metodologias ágeis trabalham com equipes altamente motivadas e suporte a mudanças durante o processo de desenvolvimento, mas como fazer isto?
O desenvolvimento ágil é incremental, ou seja, não se faz um plano completo com tudo que devemos fazer para depois iniciar o desenvolvimento, muito menos, desenvolvemos o produto sem contato com o cliente, ao invés disso, desenvolvemos incrementalmente, ou seja, o produto é feito aos poucos e entregue constantemente, desta forma, toda mudança é bem vinda, pois o projeto está em desenvolvimento e não foi concluído por completo.
Segundo Sommerville, os incrementos iniciais do sistema podem fornecer uma funcionalidade de alta prioridade, de forma que os clientes logo poderão obter valor do sistema durante seu desenvolvimento. Os clientes podem assim ver os requisitos na prática e especificar mudanças para serem incorporadas nos releases posteriores do sistema.
Aqui podemos v
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Afinal, é possível desenvolver aplicações web em PHP utilizando as melhores práticas de desenvolvimento guiado por teste? Como aplicar o teste unitário no desenvolvimento PHP? Este artigo apresenta uma introdução ao desenvolvimento Web PHP com teste de unidades.
Segundo o TIOB, o PHP ocupa a 6 posição entre as linguagens mais utilizadas do mundo.
Figura 1: Ranking de utilização das principais linguagens. Fonte: www.tiobe.com.
Ainda segundo o w3techs, o PHP é a linguagem server-side mais utilizada da Internet, dominando 78,8% de toda a internet.
Figura 2: Ranking das principais linguagens da web. Fonte: w3techs.
Este crescimento na utilização do PHP criou uma demanda pelo desenvolvimento web com qualidade. Mas o que é qualidade?
“Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos, com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos” Alexandre Bartié.
Esta definição vai ao encontro da ideia do TDD, que tem por objetivo realizar testes de ponta a ponta, além de pensar no teste antes da implementação.
No artigo Introdução ao Desenvolvimento Guiado por Teste (TDD) com JUnit (http://www.devmedia.com.br/introducao-ao-desenvolvimento-guiado-por-teste-tdd-com-junit/26559), são apresentados conceitos importantes sobre TDD, utilizando o framwork JUnit para Java. Vamos aplicar aqui os mesmos onceitos no desenvolvimento Web PHP. Também foi tratado no artigo Qualidade de Código com PHP da importância de uma boa codificação e de ferramentas que auxiliam no processo (http://www.devmedia.com.br/qualidade-de-codigo-com-php/18119). Este artigo é também um complemento para um desenvolvimento com qualidade.
A qualidade, para ser garantida em um processo de desenvolvimento de software, deve ser acompanhada do início ao fim. Na fase inicial, o teste unitário é essencial em diversas metodologias.
Em TDD, por exemplo, o teste unitário é de extrema importância, pois é a primeira fase do processo de desenvolvimento. Veja figura a seguir, é ainda a parte central da Extreme Programming (XP), sendo recomendado ainda pela metodologia Cristal Clear e utilizado no Scrum.
Figura 3: Ciclo de funcionamento do TDD
Segundo Leonardo Molinari, o teste de unidade é realizado em nível de componente ou classe, sendo o teste cujo o objetivo é um “pedaço do código”, ou uma unidade “lógica” ou “física” do sistema. Ainda segundo Bartié, “A validação da unidade de software é a primeira etapa do processo de validação, que tem por objetivo testar os componentes individuais de uma aplicação”.
Segundo a definição do RUP, o teste unitário é implementado com base no menor elemento testável (unidades) do software e implica em testar a estrutura interna (como fluxo lógico e de dados), a função da unidade e os comportamentos observáveis. O design e a implementação de testes com ênfase na estrutura interna de uma unidade se baseiam no conhecimento da implementação da unidade (abordagem c
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Afinal o que é TDD? TDD é a abreviação de Test Driven Development ou, em tradução livre, Desenvolvimento Guiado por Teste. Este artigo apresenta uma introdução ao TDD e ao framework JUnit. Introdução ao TDDA ideia por traz do desenvolvimento guiado por teste é que primeiro devemos escrever os testes para posteriormente escrever o código. Segundo Freeman, Steve; Pryce, Nat(2012) “... Você não tem nada a perder, a não ser seus bugs”. Ainda segundo a Wikipédia, “Desenvolvimento dirigido por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis”. O TDD é parte do processo de desenvolvimento ágil, utilizado em metodologias como o XP (Programação Extrema) e sendo uma das técnicas que auxiliam na melhoria de qualidade do processo de desenvolvimento. O TDD ou desenvolvimento guiado por teste torna mais eficiente o processo. A imagem a seguir ilustra os passos do desenvolvimento utilizando TDD:  Figura 1: Passos do TDD O desenvolvimento guiado por teste dá uma visão mais ampla do que deve ser feito ao desenvolvedor, pois antes de criar a funcionalidade, deve-se criar um teste da funcionalidade. Os passos apresentados na figura acima indicam que primeiro é necessário criar o teste, este teste é chamado de teste falho, pois a funcionalidade ainda não existe, desta forma, o teste deve retornar um erro. Posteriormente será desenvolvido o código para fazer com que o teste seja bem sucedido, já que o desenvolvedor sabe quais funcionalidades deve implementar, fica mais prático o seu desenvolvimento. Por último refatore, ou seja, melhore a codificação. O Desenvolvimento guiado por teste é um conjunto de técnicas que culminam em um teste de ponta a ponta. Neste artigo, vamos apenas tratar do teste unitário, que é um dos procedimentos para o TDD, mas deve-se pensar no conjunto, ou seja, o teste de integração e o teste de aceitação. Teste unitárioO Teste Unitário valida apenas um pedaço do sistema, ou seja, uma unidade, sendo utilizado para testar as funcionalidades, exibindo informações sobre seu funcionamento. Para nosso exemplo prático de codificação, vamos utilizar o JUnit como framework de teste unitário Java, o conceito aqui utilizado pode ser aplicado ao NUnit, PHPUnit, entre outros. O JUnit é um framework de teste que utiliza anotações para a identificação de métodos de ensaio. Lembrando que os testes são unitários, não devendo depender de outros testes para o seu funcionamento. Além de utilizar anotações, o framework disponibiliza métodos de asserções, que são utilizados para validar informações. Com base nas asserções teremos o resultado de nosso teste como falho ou OK. Nos exemplos utilizaremos o NetBeans que, ao ser instalado, já possui o JUnit integrado. O Eclipse também o tem integrado, mas é possível fazer o download caso queira fazer o processo manual. Para download ou mais informações visite: https://github.com/kentbeck/junit/wiki. Para nosso exemplo, será criado um novo projeto denominado "Calculo", este projeto será utilizado para criar nosso teste e posteriormente nosso código de aceitação para o teste. Ao criar o projeto, a seguinte estrutura foi montada:  Figura 2: Estrutura do projeto Primeiramente é necessário entender o que vamos testar, visto que criaremos um teste para algo que ainda não existe. Neste caso, o cenário é o seguinte: Temos de desenvolver uma classe como solução a um problema de cálculo simples, devem ser implementados métodos para soma, subtração, multiplicação e divisão. Nesse nosso exemplo, queremos apenas fazer o cálculo de dois números e obter o resultado. Agora que já sabemos o que vamos desenvolver, então vamos criar o nosso primeiro teste unitário.  Figura 3: Adicionando novo teste Será aberta uma nova janela, conforme a figura a seguir:  Figura 4: Propriedades iniciais do novo teste O campo "nome da classe" é o nome da classe de teste, vamos dar o nome de "TestCalculo", para sabermos que é um pacote de teste e deve testar a classe Calculo. Em "código gerado" estão marcadas as opções de inicializador de testes, finalizador etc. Para este exemplo, podemos desmarcar estes itens. No próximo passo será perguntada a versão do JUnit a ser utilizada, selecione JUnit 4.X. 
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Com a evolução da Internet, surgiram novas necessidades. Negócios passaram a existir de forma on-line, meios de comunicação, fazem uso constante desta poderosa ferramenta que é a Internet. Mas como esta tecnologia chegou a este ponto? No inicio a Internet era estática, a falta de interatividade imperava, foi quando surgiu o CGI, a tecnologia CGI criava interatividade ao ambiente, mas não tornava simples o seu desenvolvimento. Entre as tecnologias de CGI mais utilizadas, destaca-se o PERL, linguagem poderosa, utilizada até hoje para administração de servidores. O grande problema de se desenvolver um CGI, além do desempenho, era a sua complexidade, a solução para simplificar o desenvolvimento WEB e passar para uma nova fase, surgiram as linguagens server-side scripts como ASP, PHP e JSP. Estas linguagens tornaram o desenvolvimento web mais ágil, simples e prático. Além de possuir um maior desempenho de aplicação, em um meio que a velocidade é essencial, isto garantiu o sucesso das novas linguagens de scripts. Este artigo apresenta os conceitos básicos de JSP, bem como a utilização da linguagem para a programação web dinâmica, todo o desenvolvimento feito neste artigo foi testado utilizando o Servidor Tomcat. Introdução ao JSPJSP é o acrônimo para Java Server Pages, uma linguagem criada pela SUN gratuita, JSP é uma linguagem de script com especificação aberta que tem como objetivo primário a geração de conteúdo dinâmico para páginas da Internet. Podemos ao invés de utilizar HTML para desenvolver páginas Web estáticas e sem funcionalidade, utilizar o JSP para criar dinamismo. É possível escrever HTML com códigos JSP embutidos. Como o HTML é uma linguagem estática, o JSP será o responsável por criar dinamismo. Por ser gratuita e possuir especificação aberta possui diversos servidores que suportam a linguagem, entre eles temos: Tomcat, GlassFish, JBoos, entre outros. O JSP necessita de servidor para funcionar por ser uma linguagem Server-side script, o usuário não consegue ver a codificação JSP, pois esta é convertida diretamente pelo servidor, sendo apresentado ao usuário apenas codificação HTML. Uma pagina JSP possui extensão .jsp e consiste em uma página com codificação HTML e com codificação Java, inserida entre as tag´s , denominada scriptlets e funcionando da seguinte forma: o servidor recebe uma requisição para uma página JSP, interpreta esta página gerando a codificação HTML e retorna ao cliente o resultado de sua solicitação. A página JSP que foi interpretada pelo servidor não precisa ser compilada como aconteceria com um servlet java por exemplo, esta tarefa é realizada em tempo real pelo servidor. É necessário apenas desenvolver as páginas JSP e disponibilizá-las no Servlet Container (Tomcat, por exemplo). O trabalho restante será realizado pelo servidor que faz a compilação em tempo de uso transformando o jsp em bytecode. Assim, pode-se definir o JSP como uma tecnologia que provê uma maneira simples e prática de desenvolver aplicações dinâmicas baseadas em web, sendo independente de Plataforma de Sistema Operacional. Tecnologia Client-side e Server-sideA internet foi concebida de forma a funcionar como cliente X servidor, ou seja, temos um cliente que é o navegador web (browser) e o servidor http(web). Existem, na tecnologia disponível para Web, duas classificações de tecnologia, uma que funciona do lado do cliente ou Client-side e uma que funciona do lado do servidor ou Server-side. Client-side – lado do clienteO cliente-side de uma aplicação é o local onde ela é processada, ou seja, no caso da web, executa no navegador do cliente que é o responsável por interagir com o Servidor HTTP. Entre as tecnologias cliente-side temos o HTML que é executado no navegador, o CSS é outra tecnologia cliente que serve para formatar paginas HTML, há ainda o javascript que permite desenvolver ou ampliar o poder ao lado do cliente. Server-sideServer-side, por sua vez, é o termo que representa o conjunto de tecnologias em que os processos são interpretados/processados diretamente no servidor, retornando como resultado a codificação client-side. Quando um cliente web(navegador) acessa uma página web, uma solicitação é enviada ao servidor através do protocolo http para que o servidor envie a resposta. O Servidor além de rodar os aplicativos, o lado servidor também é um repositório de páginas estáticas, que serão enviados ao cliente quando solicitado. Supondo que haja uma página JSP, esta será processada pelo servidor e encaminhado uma resposta ao cliente (Navegador). Benefícios do JSPO objetivo da linguagem JSP não é só o desenvolvimento de páginas dinâmicas para Internet. Com ela é possível desenvolver sistemas inteiros para Internet. Além disso, existem diversos benefícios em se utilizar a linguagem JSP. CustoO JSP não tem custo de licença. Isto significa que pode ser utilizado em qualquer máquina, para qualquer numero de usuários sem violar nenhum direito autoral. Claro que isto depende do servidor escolhido, o Tomcat é um servidor livre, licenciado sob a licença da Apache Foundation, de alta qualidade e sem custo de licenciamento. JSP é embutido no HTMLO JSP é simples de se utilizar, podendo gerar o HTML ou ainda estar embutido dentro do HTML, como no exemplo a seguir: Listagem 1: Exemplo de código JSP embutido no HTML <html>
<head>
<title> Pagina JSP Ola Mundo</title>
</head>
<body>
<h1>
<%
out.println("Ola Mundo");
%>
</h1>
</body>
</html>Outras vantagens da linguagemAlem do custo e da integração perfeita com o HTML, é possível ainda, citar os seguintes benefícios da linguagem: - Aperfeiçoamento de recursos utilizando Java em Servlets;
- Manipulação de arquivos como texto, PDF, DOC etc;
- Criptografia de dados;
- Utilização de cookies e sessões;
- Manipulação de arquivos XML;
- Suporte a diversos bancos de dados como: MySQL, SQL Server, Oracle, Informix etc;
- Suporte a sistemas de relatórios como o JasperReport entre outros.
TomcatO JSP por ser uma linguagem Server-Side como visto anteriormente, necessita de um servidor para o seu funcionamento. O Apache Tomcat foi desenvolvido pela Apache Software Foundation, o Tomcat é um servlet container de código aberto, ou seja, uma aplicação que interpreta e processa servlets (java servlets) e JSP (Java Server Pages). O servidor esta disponível livremente na Internet sem a necessidade de pagamento de licenciamento e está disponível no endereço http://tomcat.apache.org para diversas plataformas, entre elas o Windows, Linux, Solaris etc. Recomenda-se o download da versão 7 do servidor. A instalação é simples, basta seguir o seu passo-a-passo. O desenvolvedor deve fazer a instalação completa do servidor para seu sistema operacional. Com o Tomcat instalado pode-se iniciar o desenvolvimento JSP. Para iniciar o desenvolvimento deve-se criar um diretório easyjava em “C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\webapps (no Windows) e /usr/java/apache-tomcat-7.0 (no Linux)”. No diretório easyjava deve-se criar os diretórios src, web, WEB-INF e WEB-INF/lib. - •src = diretório onde fica armazenado o código fonte dos servlets;
- •web = diretório raiz da aplicação web;
- •WEB-INF = diretório que armazena o descritor da aplicação web (web.xml), bem como outros arquivos de configuração. Este diretório é invisível ao usuário;
- •WEB-INF/lib = bibliotecas necessárias para a aplicação.
Utilizaremos, inicialmente, apenas o jsp, mas em artigos futuros criaremos servlets para ampliar a capacidade de nossa aplicação web, por isso criamos a estrutura completa de diretórios Tomcat. Desenvolvimento JSP na praticaPara iniciar o trabalho com JSP, criaremos o primeiro arquivo de exemplo, do Artigo JSP. Para manter o padrão, criaremos um arquivo hello word/ola mundo. No diretório (pasta) easyjava, com seu editor favorito notepad, vi, emacs etc., o desenvolver deve criar o arquivo ola.jsp com o seguinte conteúdo: Listagem 2: Programa Olá Mundo. <html>
<head>
<title> Pagina JSP Ola Mundo</title>
</head>
<body>
<h1>
<%
out.println("Ola Mundo");
%>
</h1>
</body>
</html>Salve o arquivo e abra o navegador de sua preferencia e digite: http://127.0.0.1:8080/easyjava/ola.jsp, conforme a Figura 1.  Figura 1: Resultado da exibição do código alo mundo O resultado é a exibição de uma página com o texto Ola Mundo. No código da pagina será exibido apenas HTML e não JSP. Para o teste, clique com o botão direito na tela e mande exibir o código fonte como na listagem 2. Listagem 3: Programa Olá Mundo. <html>
<head>
<title> Pagina JSP Ola Mundo</title>
</head>
<body>
<h1>
Ola Mundo
</h1>
</body>
</html>Vamos entender o que foi feito na listagem 1, todo script jsp esta entre as tag´s , a linha out.println("Ola Mundo") é responsável por escrever o texto que esta entre aspas, sendo convertido para a exibição em HTML de Ola Mundo, isto por que o comando out.println é responsável por escrever na tela, ou seja, escreve em HTML um conteúdo, e neste caso é Ola Mundo. Conteúdos de texto devem estar entre aspas, como visto no exemplo. Observe que a exibição no cliente não há nenhum código JSP, pois foi processado no servidor, outro ponto importante é que o JSP segue o padrão do Java, ou seja, ao final de cada linha temos um (;). Prosseguimos, agora, para os estudos do JSP. Inicialmente, abordaremos o seu funcionamento. O JSP, assim como o PHP, pode ser utilizado dentro do HTML, a página JSP, na verdade, é uma pagina HTML, mas quando for necessário utilizar codificação JSP que deve estar entre as tag´s , o servidor trata de converter para HTML para responder a solicitação do usuário. Na codificação JSP, têm-se algumas diretivas, as quais são utilizadas para informações especiais dentro de paginas, sendo dividido em três tipos: - @include: utilizado para inserir os códigos de arquivos à página corrente;
- @page: responsável por trazer informações sobre a página JSP;
- @taglib: responsável por habilitar uma biblioteca de tags personalizada (item que será abordado em outro artigo com mais detalhes).
Agora, vamos incrementar um pouco mais nossa aplicação ola mundo, exibindo a data atual. Listagem 4: Programa Ola Mundo melhorado <%@page contentType="text/html" import="java.util.Date, java.text.*" pageEncoding="ISO-8859-1"%>
<html>
<head>
<title> Pagina JSP Ola Mundo</title>
</head>
<body>
<h1>
<%
out.println("Ola Mundo");
%>
<br>
<%=new Date()%>
</h1>
</body>
</html> Ao abrir no navegador o resultado será a exibição do ola mundo e da data e hora atual, conforme a Figura 2.  Figura 2: Resultado da codificação a listagem 4 Em conjunto com a diretiva @page, temos os atributos listados na tabela 1.
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
O Jmeter é um programa que serve para fazer testes de performance, carga e stress. Ele é um software livre, sendo parte do projeto Jackarta da Apache Software Foundation. Neste howto veremos como utilizar o JMeter para fazer um teste de um site. Em próximas edições trataremos sobre mais recursos do JMeter. O JMeter está disponível para download em:
http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi
Faça download do JMeter, e descompacte-o. Ao abrir o programa, será exibido a seguinte tela:
 O Jmeter possui uma área de trabalho e um plano de teste. Vamos iniciar a criação do plano de teste, que é a base de qualquer teste no JMeter. No plano de teste é possível incluir os recursos de testes. Insira o nome do plano de teste e, se possíve,l algum comentário sobre o plano a ser realizado. Após a configuração do plano de teste, salve o plano de teste, clicando em arquivo ? salvar. O próximo passo para a criação de um teste é a criação de um grupo de usuários. Clique com o botão direito no plano de teste. Um menu pop-up será exibido. Clique em Adicionar ? Grupo de usuários. Um grupo de usuários serve para configurar quantas pessoas (virtuais) serão utilizadas no teste, o tempo de execução do teste e a quantidade de interações dos processos. No nosso teste vamos determinar que temos 10 usuários virtuais, o tempo de inicialização será 1 (tempo em segundos) e as interações (quantidade de vezes que será executado o teste) determinaremos 10.
![JMete]()
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Quando atuamos com codificação em equipe é importante seguirmos um padrão para codificação, em PHP existem diversos padrões que podem ser adotados, entre eles temos: Zend, PEAR, PHPCS, SQUIZ etc. Com base na padronização, veremos um programa que analisa os códigos e outro que padroniza os códigos.
PHPCodeSnifferO CodeSniffer do PHP é um analista de código, que verifica se a codificação esta seguindo um padrão, e emite um relatório de pontos em que a codificação fere a norma.
Instalaçãopear install PHP_CodeSniffer-1.3.0RC1 Sintax:phpcs opções /diretório/arquivo Opções--report = padrão de report (Uso summary e source para erros mais comuns) -n = omitir warnings -s = relatório completo com sumário --standard = padrão a ser adotado (Zend, PEAR, PHPCS, SQUIZ), se for omitido esta opção, o sistema usa como padrão o PEAR --config-set = Configura o PHPCodeSniffer Exemplos de usophpcs --report=summary /var/www Verifica o diretório /var/www, ou seja, todo o conteúdo phpcs --report=summary /var/www/index.php Verifica apenas o arquivo index.php O relatório apresentado, demonsta o caminho indicado para que possa ser corrigido. PHP_Beautifier
O Beautifier é um padronizador de códigos, ótimo para padronização de codigos.
Instalação
pear install PHP_Beautifier-0.1.15
Sintax:
php_beautifie opções /diretório/arquivo.php /diretório/arquivo_novo.php Opções-tn = T é a quantia de espaço por tab a ser utilizada e n indica o numero correspondende -s = indentamento automático -r = recursiva, para converter diretórios inteiros -l = filtros especiais Exemplophp_beautifier -t2 -l “Pear()” index.php index_pear.php converte o index.php utilizando tab = 2 e padrão pear de codificação do arquivo index.php salvando como index_pear.php ConclusãoCom os dois comandos, é possivel, não somente manter a códificação padronizada, como analisar os códigos de aplicações e as modificações criadas, mantendo a qualidade de codificação.
-->">
|
|
|
|
MySQL Definitivo – Parte 02
Manipulando
o banco de dados
Para nos familiarizarmos com o mysql utilizaremos nesta primeira etapa o MySQL
Console Line Client. Após conhecer o mysql, iniciaremos o uso de ferramentas
para a administração e manipulação do banco de dados.
O MySQL Console Line Client é a ferramenta de linha de comando do mysql para
manipulação de banco de dados, é uma ferramenta texto, disponibilizada em todas
as versões. Com ela é possível fazer tudo que é necessário, porém a ferramenta
não é visual, podendo oferecer um pouco de dificuldade para os iniciantes. Utilizaremos
esta ferramenta nesta primeira parte para que você passe a conhecer ela. Nas
próximas etapas serão apresentadas ferramentas visuais, mas continuaremos
trabalhando com comandos.
No Windows para acessar o MySQL Console Line Client, sigua até o menu iniciar à programas e procure por MYSQL, dentro de mysql acesse o item MySQL
Console Line Client.
Ao abrir, será exibida uma tela semelhante ao prompt do DOS, solicitando a senha.
Apenas tecle enter e pronto, temos acesso à tela o Console Line Client. (Figura
2).

Figura2. Comand Line do MySQL
A linguagem SQL é formada por grupos de comandos, sendo divididos em DDL(Data
Definition Language - Linguagem de Definição de Dados) e DML(Data Manipulation
Language - Linguagem de Manipulação de Dados). Utilizaremos os comandos destes
grupos para exemplificar melhor e, ao mesmo tempo, praticar o uso do banco de
dados.
Linguagem de Definição de dados
A DDL possui comandos que servem
para criar, apagar e alterar objetos, os quais podem ser banco de dados,
tabelas, views etc. Temos os seguintes comandos:
- Create objeto (cria objetos como banco
de dados, tabelas etc)
- Drop objeto (remove objeto)
- Alter objeto (altera o objeto criado)
Criando um banco de dados
O comando create database serve criar um novo banco de dados. O comando possui a seguinte sintax:
Create database ;
Onde:
= nome do banco de dados a ser criado, se o banco existir, o
comand line exibirá um erro, acusando que o banco já existe.
Listando os bancos de dados do Mysql
O comando show
database serve listar todos os bancos de dados disponíveis no servidor
MySQL. O comando possui a seguinte sintax:
Show databases;
Utilizando banco de dados do Mysql
O comando use serve para abrir o banco de dados para manipulação no
servidor MySQL. O comando possui a
seguinte sintax:
Use ;
Onde:
= nome do banco de dados a ser manipulado.
Removendo um banco de dados do Mysql
O comando drop serve para remover um banco de dados no servidor
MySQL. O comando possui a seguinte
sintax:
Drop database ;
Onde:
=
banco de dados a ser removido.
Com base nas informações acima vamos fazer um
exemplo:
Create database escola;
Cria um banco de
dados com o nome escola.
Show databases;
Exibe todos os
bancos de dados disponíveis no sistema, deve aparecer o banco de dados que
acabamos de criar, o escola.
Drop database
escola;
Remove o banco de
dados escola.
Show database;
Na listagem, o
banco de dados escola vai desaparecer. Crie o banco de dados novamente com o
comando create database.
Habilite para
utilizar o banco de dados:
Use escola.
Tipos de dados:
Varchar =cadeia de caracteres variáveis, até 255 caracteres;
Char(n) = armazena
caracteres, até 255 caracteres.
Int, Integer =
Inteiros entre -2147483648 até 2147483647 ou de 0 até 429.496.295;
Bigint = Inteiros
entre -9.223.372.036.854.775.808 até 9.223.372.036.854.775.807 ou de 0 até
18.446.744.073.709.551.615.
Float = ponto
flutuante entre -3.402823466E+38 até -1.175494351E-38,0 ou de 0 até
175494351E-38 ou até 3.402823466E+38.
Double = ponto
flutuante entre -1.7976931348623157E+308 até -2.2250738585072014E-308 ou de 0 e
desde 2.2250738585072014E-308 até 1.7976931348623157E+308;
Date = tipo data
Time = tipo hora
Mediumint =
Inteiros entre -8.388.608 até 8.388.607 ou
de 0 até 16777215;
SmallInt = Inteiro
entre -32768 até 32767 ou de 0 a
65535;
Bit ou boll =
valores entre 0 e 1;
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
MySQL Definitivo – Parte 01
Introdução
O
MySql é um SGBD (Sistema de Gerenciamento de Banco de Dados) muito utilizado
para aplicações Web. Sendo um banco de dados em constante evolução, em sua
versão atual, agregou novas características como Stored Procedure, Triggers,
etc. Este material pretende ser um mini-curso, abordando dos aspectos básicos
até os avançados para a instalação, utilização do console e ferramentas de
manipulação do banco.
A MySQL AB é a empresa dos fundadores e dos principais desenvolvedores do
Mysql, estabelecida originalmente na Suécia por Axmark, Larsson e Widenius. Atualmente
ela foi comprada pela SUN.
O MySQL é um sistema simples, e ao mesmo tempo com muitos recursos, os quais o tornam
um produto adequado para o aprendizado e para o uso em produção. Existem
diversos motivos para utilizar o MySQL, entre eles:
1° É uma ferramenta com suporte ao
SQL, e em conformidade com o ANSI/ISO SQL 92;
2° Multiplataforma, possibilitando a
portabilidade entre estas plataformas;
3° Ferramenta livre, amplamente
difundida no mercado;
4° Baixo consumo de recursos;
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
|
Imagine-se como novo funcionário de uma empresa que utiliza um sistema com banco de dados mysql, e que o antecessor não informou as senhas do banco de dados, ou por algum motivo a senha foi perdida? Enquanto o sistema não acusar problema, tudo bem, mas e se surgirem problemas como tabelas corrompidas?
A primeira coisa a fazer é tentar acessar o mysql para corrigir. Mas, se você não tem a senha, como proceder para efetuar as correções? Propomos uma solução simples e prática, permitindo, inclusive, alterar a senha e reparar as tabelas. Para iniciar o trabalho é necessário derrubar o banco de dados. Existem várias formas de se fazer isto:
Utilizando o ps -ax |grep mysql
Verifique o numero do processo, utiliza o comando kill para parar o processo como no exemplo abaixo.
kill -9 numerodoprocesso
Se utilizar o Slackware procede-se da seguinte forma:
#/etc/rc.d/rc.mysqld stop
No caso de ser utilizado o Debian:
#/etc/init.d/mysql stop
Depois de parar o banco é necessário iniciar o mysql, ignorando as tabelas de usuários. Uma dos caminhos para isso é editar o my.cnf que é o arquivo de configuração do mysql, dentro do
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|
|
|
| |
|