Nas ultimas aulas do semestre, conhecemos o ultimo Padrão Grasp que é Variações Protegidas, e Padrão Não fale com estranhos, pra encerrar foi comentado a respeito sobre Extreme Programming ou XP que é um Processo de desenvolvimento de Software voltado para projetos cujos requisitos são vagos e mudam com freqüência.
Extreme Programming
Extreme Programming
A muito tempo a indústria de software vem passando por grandes transformações e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes.
Com estes novos desafios a indústria de software passou a dar valor a algumas áreas da informática, como a engenharia de software e qualidade de software, com intuito de atender as exigências do mercado.
A indústria começou a utilizar metodologias de desenvolvimento de software, adotou métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Porém ainda são poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e orçamento estabelecidos e as necessidades do cliente sejam realmente atendidas.
Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoção de metodologia de desenvolvimento pelas indústrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, orçamento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aquém do esperado pelo mercado.
As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipação. Neste trabalho será utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele.
Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:
Tempo elevado entre cada fase do projeto, não acompanhando as mudanças de requisitos do projeto;
Falta de conhecimento por parte do cliente da sua real necessidade, dando margem às especulações dos desenvolvedores;
Forte linearidade no desenvolvimento do projeto;
Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento ágil de software. Cita-se algumas características destas metodologias:
Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;
Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada;
Ausência de linearidade no desenvolvimento do projeto;
O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;
Uma destas metodologias de desenvolvimento ágil é o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia será detalhada a seguir.
Extreme Programming (XP)
XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.
Uma metodologia voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.
A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço de tempo o cliente terá um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.
Por ser uma metodologia recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuízos do que benefícios é necessário relavaliar a utilização desta metodologia.
A XP é organizada em torno de um conjunto de práticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir serão apresentados os valores e em seguida as práticas.
Variações Protegidas
Como atribuir responsabilidades a objetos, subsistemas e sistemas, de modo que as variações ou a instabilidade nesses elementos não tenham um impacto indesejável sobre outros elementos?Identifique pontos de variação ou instabilidade prevista; atribua responsabilidades para criar uma interface estável em torno deles
Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.
Mecanismos de Variações Protegidas· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.
Padrão não Fale com Estranhos
-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.
-Objetos referenciados diretamente – “familiares”-Objetos referenciados indiretamente – “estranhos”
-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:-O objeto this (ou self)-Um parâmetro do método-Um atributo de self-Um elemento de uma coleção que é um atributo de self-Um objeto criado dentro do método.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:-O objeto this (ou self)-Um parâmetro do método-Um atributo de self-Um elemento de uma coleção que é um atributo de self-Um objeto criado dentro do método.
http://www.javafree.org/content/view.jf?idContent=5 Acessado em 12 Jun 2008, 14:21;
Microsoft Corporation Groups, GRASP - Padrões de Software para Atribuição de Responsabilidade Gerais, Disponível em:<http://groups.msn.com/cafedotnet/grasppadresdesoftware.msnw> Acessado em 12 Jun 2008, 13:21;
.bmp)
A fundamental finalidade de se usar O Padrão Indireção, é que pode-se atribuir a encargo a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.
