Contextualizando XP para Web
engineering
Américo Tadeu Falcone Sampaio
[email protected]
Visão geral do trabalho
• Apresentar conceitos e uma visão geral
sobre Extreme Programming (XP);
• Apresentar conceitos sobre Web
Engineering;
• Contextualizar XP dentro da Web
Engineering e verificar possibilidades de
adaptação da metodologia.
Extreme Programming (XP)
• É uma metodologia ágil de engenharia de software, ou
seja, promove:
–
–
–
–
Indivíduos e interações ao invés de processos e ferramentas;
Software que “roda” ao invés de documentação em demasia;
Colaboração do cliente ao invés de negociação de contratos;
Responder a mudanças ao invés de seguir um plano rígido.
• O objetivo de XP é servir como um processo ágil de engenharia
de software cujo principal foco é entregar funcionalidades de
forma rápida e eficiente. Além disso, XP foi criado
considerando que mudanças são inevitáveis e que devem ser
incorporadas constantemente.
Conceitos básicos
• Valores: Comunicação, simplicidade, feedback e coragem. Estes quatro
valores servem como critérios que norteiam as pessoas envolvidas no
desenvolvimento de software seguindo a metodologia XP.
• Princípios fundamentais: feedback rápido, assumir simplicidade,
mudança incremental, abraçando mudanças e trabalho de qualidade.
• Práticas: Jogo do planejamento (The planning game); Releases
pequenas (Small releases); Metáfora (Metaphor); Projeto simples
(Simple design); Testando (Testing); Refactoring; Programação em par
(Pair programming); Posse coletiva do código (Collective ownership);
Integração contínua (Continuous integration); 40 horas por semana
(40-hour week); Cliente no local (On-site customer); Padrões de
codificação (Coding standards).
Valores
• Comunicação: XP se foca em construir um entendimento pessoa-parapessoa do problema com o uso mínimo de documentação formal e com o
uso máximo de interação cara-a-cara entre as pessoas envolvidas no
projeto.
• Simplicidade: XP sugere que cada membro da equipe adote a solução mais
fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples
hoje e criar um ambiente em que o custo de mudanças no futuro é baixo.
• Feedback: O feedback é importante pois possibilita que as pessoas
aprendam cada vez mais sobre o sistema e assim corrijam os erros e
melhorem o sistema.
• Coragem: Ela é necessária para que realmente se aplique XP como deve
ser aplicado. Exemplos de atitude que exigem coragem são: alterar código
já escrito e que está funcionando; jogar código fora e reescrever tudo de
novo; e permitir código compartilhado por todos.
Princípios
• Feedback rápido – Um dos princípios é receber o feedback,
interpretá-lo e colocar o que foi aprendido de volta no sistema o
mais rápido possível. Os programadores aprendem a melhor forma
de projetar, implementar e testar o sistema e retornam o
aprendizado.
• Assumir simplicidade – Todo problema deve ser tratado para ser
resolvido da forma mais simples possível. XP afirma que se deve
fazer um bom trabalho (testes, refactoring, comunicação) em
resolver hoje os problemas de hoje e confiar na sua habilidade de
adicionar complexidade no futuro quando for necessária.
• Mudança incremental – Quando muitas mudanças são realizadas
todas de uma vez, não se obtêm um bom resultado. Em vez disso,
esse princípio de XP diz que as mudanças devem ser incrementais
e feitas aos poucos.
Princípios - Continuação
 Abraçando mudanças (Embracing Change) – XP procura
facilitar o ato de incluir alterações através do uso de vários
princípios e práticas.
 Trabalho de qualidade – Em XP, qualidade não é um
critério opcional mas sim obrigatório. Embora a definição
de qualidade possa variar de pessoa para pessoa, XP trata
qualidade no sentido de se ter um sistema que atenda os
requisitos do cliente, que rode 100% dos casos de teste e
que agregue o maior valor possível para o negócio.
Práticas
• O jogo do planejamento (The planning game) – No final de cada release é
feita uma determinação rápida do escopo da próxima, através da
combinação de estimativas e prioridades do negócio. Uma release
consiste de várias iterações e, em cada iteração, várias estórias (use case
simplificadas) são implementadas. Os programadores estimam cada
estória e dizem quantas eles podem implementar no final da release.
• Releases pequenas (Small releases) – Beck diz: “cada release deve ser tão
pequena quanto possível, contendo os requisitos mais importantes para o
negócio”. Isso possibilita ter releases freqüentes o que resulta em maior
feedback para clientes e programadores, facilitando o aprendizado e a
correção dos defeitos do sistema.
• Metáfora (Metaphor) – A intenção da metáfora é oferecer uma visão geral
do sistema, em um formato simples, que possa ser compartilhada por
clientes e programadores. É semelhante a uma arquitetura porém feita de
uma forma mais simples.
Práticas - continuação
• Projeto simples (Simple Design) – Pode-se explicar esta prática em
duas partes: A primeira diz que devem ser projetadas as
funcionalidades que já foram definidas e não as que poderão ser
definidas futuramente. A segunda diz que deve ser feito o melhor
projeto que possa entregar tais funcionalidades.
• Testando (Testing) – Os casos de testes em XP são feitos antes da
programação. Existem dois tipos de teste: teste de unidade e teste
funcional. Os testes de unidade são feitos para verificar tudo que possa
dar errado. Os testes são automatizados, e toda vez que o programador
escrever código, ele irá verificar se o sistema roda 100%.
• Refactoring – Essa prática pode ser definida como constantes
melhorias no projeto do software para aumentar sua capacidade de se
adaptar a mudanças. O refactoring consiste em aplicar uma série de
passos para melhorar o projeto do código existente, tornando-o mais
simples, sem alterar sua funcionalidade.
Práticas - continuação
• Posse coletiva do código (Collective ownership) – Qualquer
membro do projeto pode alterar qualquer parte do código a
qualquer tempo. A programação em par encoraja duas pessoas a
trabalharem juntas procurando atingir o melhor resultado possível.
Enquanto isso, a posse coletiva encoraja a equipe inteira a
trabalhar mais unida em busca de qualidade no código.
• Integração contínua (Continuous integration) – O código escrito
deve ser constantemente integrado na versão atual. As alterações
feitas não podem quebrar o que foi feito antes devem passar em
100% dos testes.
• 40 horas por semana (40-hour week) – Essa não é uma regra que
obriga as equipes em projetos XP a trabalharem somente 40 horas
por semana. No entanto, Beck diz que não se deve trabalhar 2
semanas seguidas além desse tempo, pois o cansaço e a
insatisfação de trabalhar horas extras pode resultar numa queda de
qualidade do código.
Práticas - continuação
• Cliente no local (On-site customer) – Deve ser incluído na
equipe uma pessoa da parte do cliente, que irá usar o sistema,
para trabalhar junto com os outros e responder as perguntas e
dúvidas.
• Padrões de codificação (Coding standards) – Como XP prega a
posse coletiva de código, onde todos podem alterar e fazer
refactoring de qualquer parte do código a qualquer momento,
então é mais do que necessário que se tenha padrões de
codificação. O objetivo é que todos programem da mesma
forma, facilitando o entendimento do código e as alterações.
Web Engineering
• Tópico recente da área de engenharia de
software;
• Preocupa-se com as características inerentes
aos sistemas Web.
• Procura abordar aspectos que diferem da ES
tradicional e como adaptar metodologias e
processos de software existentes para o
desenvolvimento de sistemas para a Web;
Caraterísticas dos sistemas Web
• Diversos tipos de clientes que podem acessar o
sistema via browsers distintos, via dispositivos
wireless (celulares, PDAs, Pocket PCs);
• Possui uma arquitetura hipermídia distribuída;
• Rodam em ambientes heterogêneos com diversos
tipos de hardware e software;
• Estão constantemente sendo alterados e integrados
com outros sistemas e dispositivos.
Cenário atual de projetos de software
• Ciclos de desenvolvimento curtos, tipicamente 3
meses ou menos;
• Times de desenvolvimento pequenos (4 a 6 pessoas) e
multidisciplinares;
• Melhor teste e avaliação dos produtos construídos;
• Em projetos de sistemas Web:
– Mais rigor na análise de requisitos, incluindo uma
análise clara das necessidades de negócio e
preocupação com requisitos não funcionais;
– Preocupação com questões de navegação e interfaces;
– Maior preocupação com as questões relativas a
evolução e integração dos sistemas Web.
• Processos ágeis surgem levando em consideração as
questões acima. A Web Engineering pode se beneficiar
de metodologias ágeis.
O que existe atualmente
• Existem técnicas e metodologias que podem
ser incorporadas em processos de software
como RUP e XP fazendo as devidas
adaptações.
– Técnicas de modelagem baseadas na UML com
extensões para aplicações WEB (WAE, W2000,
etc).
– Metodologias de Projeto de sistemas
Hipermídia (HDM, OOHDM e outras).
• Não são processos completos de ES.
Extensões de UML
• 3 características importantes para estender a UML
para a Web que são: modelagem de elementos
específicos de aplicações Web tais como página
cliente, pagina servidor, links, frames, formulários
entre outros; navegação; e apresentação
(interface).
• Existem 3 abordagens feitas respectivamente por
J. Conallen (WAE), N. Koch (Koch) e L. Baresi
(Framework W2000).
Extensões de UML - Comparação
• A WAE (Web Application Extension), proposta por J. Conallen,
define um conjunto de estereótipos para modelagem dos
elementos específicos descritos anteriormente, porém não
atende a um aspecto muito importante que é o da navegação.
• A extensão proposta por N. Koch , que é baseada na OOHDM
(Object Oriented Hipermedia Design Method) , trata dos
aspectos de navegação e apresentação, porém não define
estereótipos para modelar os elementos básicos.
• O framework W2000, proposto por L. Baresi, é uma
caracterização do HDM (Hipermedia Design Method) usando o
meta modelo da UML. Ele trata apenas dos aspectos de
navegação.
Extensões UML – Quadro Resumo
Técnicas de Projeto de sistemas
Hipermídia
• Sistemas Web podem ser considerados sistemas
Hipermídia.
• Essas técnicas podem ser incorporadas dentro
de um processo de engenharia de software.
• As principais são HDM (Hipermidia Design
Method) e OOHDM (Object Oriented
Hipermedia Design Method)
OOHDM
• Em OOHDM, uma aplicação hipermídia é construída
em um processo de cinco passos em um estilo
iterativo e incremental. Cada passo mantém seu foco
em um interesse particular de projeto e um modelo
orientado a objetos é construído. Classificação,
agregação e generalização/especialização são usadas
durante o processo para melhorar o poder de
abstração e as oportunidades de reuso.
• Possui cinco atividades: captura de requisitos,
modelagem de domínio ou conceitual, projeto
navegacional, projeto da interface abstrata e
implementação
Resumo dos passos de OOHDM
• O primeiro passo é capturar os requisitos do sistema.
• Os cenários são então coletados para formar uma Use Case que
é representada usando Diagramas de Interação do Usuário
(UID). Em seguida, um conjunto de guidelines é aplicado aos
UIDs para extrair o modelo conceitual.
• O próximo passo é construir o modelo conceitual do domínio da
aplicação usando técnicas conhecidas de modelagem orientada a
objetos, além de algumas primitivas para perspectivas de
atributos (atributos multivalorados) similares às perspectivas
HDM.
• Na atividade de projeto da interface abstrata o modelo é
construído pela definição de objetos perceptíveis (ex. figura,
mapa, etc.) em termos de classes de interface
• Na implementação ocorre o mapeamento dos objetos de
interface em objetos implementacionais
XP e Web Engineering
• Web Engineering possui características como: equipes
multidisciplinares (XP); ciclos curtos de desenvolvimento
(XP); grande quantidade de requisitos não funcionais;
preocupação com questões de navegação e interfaces;
preocupação com as questões relativas a evolução e
integração dos sistemas Web; e mudanças constantes nos
requisitos (XP).
• XP atende a algumas dessas características e falha em outras.
– Atende: ver acima (XP)
– Não atende  a metodologia precisa ser adaptada
• XP pode ser adaptado para a Web Engineering
Falha de XP: Navegação e Interface
• Uma das questões fundamentais no desenvolvimento de
sistemas para a Web é a do projeto da navegação e das páginas
do Website. Os sistemas Web são concebidos para serem usados
por diversos tipos de usuário, com perfis e funções diferentes,
que podem navegar de diversas maneiras para obter informações
de seu interesse. Então, qualquer metodologia que trate da
construção de sistemas Web deve levar isso em consideração.
• Ao analisar a metodologia XP nota-se a omissão em relação a
esse assunto. Para solucionar o problema pode-se pensar em
importar para XP, práticas de projeto de navegação e interface
adotadas por outras metodologias como extensões de UML
(seção 2.3) e OOHDM (seção 2.4). É importante mencionar que
a incorporação de tais práticas deve ser feita respeitando os
valores e princípios de XP, caso contrário ela pode perder a sua
característica de metodologia ágil.
Outras falhas
• A questão de modelagem em XP não é muito levada em
consideração visto que seu foco é maior em
implementação e testes.
– Possibilidades de solução: Utilização de modelagem
baseada em técnicas ágeis (Agile Modeling) e
utilização de Design Patterns
• As questões arquiteturais em XP são descritas de forma
superficial através da metáfora. O problema da metáfora é
que ela é relativamente estática e estável o que não se
alinha ao desenvolvimento Web que deve possuir um alto
grau de dinamismo para incorporar as mudanças de
infraestrutura e permitir a evolução dos sistemas Web.
– Considerar uso de padrões arquiteturais
Conclusão
• Extreme Programming pode ser adaptado
para a Web Engineering;
• A adaptação deve ser feita de forma a
preservar as caraterísticas ágeis de XP e
responder às peculiaridades dos sitemas
Web;
• Já existem iniciativas semelhantes de
criação de processos ágeis para Web
Engineering (AWE process).