sábado, 21 de junho de 2008

XP - Extreme Programming

Aula 31


Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.


Esta metodologia prega que:

  • Indivíduos e interações entre eles são mais que processos e ferramentas;
  • Software em funcionamento é mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos; ·
  • Responder a mudanças mais que seguir um plano.
Os valores da programação extrema se baseiam em:

Comunicação: Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes.

Coragem: Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com freqüência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, gera uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando. È preciso coragem para enfrentar esses tipos de situações.

Feedback: Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as conseqüências daquilo que pediu. Os clientes, por sua vez, procuram se manter próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento.

Respeito: Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

Simplicidade: O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

Padrões GRASP - parte II (Variações Protegidas)

Aula 30


Como projetar objetos, subsistemas e sistemas de modo que as variações ou a instabilidade nesses elementos não tenha um impacto indesejável sobre outros elementos?
A VP é um princípio básico na motivação da maioria dos mecanismos e padrões na programação e no projeto para fornecer flexibilidade e proteção contra variações.
O encapsulamento de dados, das interfaces, e o polimorfismo são mecanismos básicos para se obter a VP. As técnicas de linguagens baseada em regras, interpretadores de regra, projetos reflexivos e de metadados, máquinas virtuais, etc, são mecanismos mais avançados para se obter a VP.


A seguir veremos alguns desses mecanismos e suas descrições de acordo o livro Utilizando UML e Padrões de Craig Larman:


Projeto dirigido por dados (data-driven designs): Os projetos dirigidos por dados englobam uma ampla família de técnicas que incluem códigos de leitura, valores, caminhos de arquivo de classe, nomes de classe, etc, de uma fonte externa para mudar o comportamento ou parametrizar um sistema de alguma maneiram, em tempo de execução.

Pesquisa de serviço: inclui técnicas como uso de serviços de atribuição de nomes ou negociantes para obter o serviço (o Jini do Java ou o UDDI para serviços web). Os clientes são protegidos contra variações na localização de serviços, usando a interface estável do serviço de pesquisa.

Projetos dirigidos pelo interpretador: os projetos dirigidos pelo interpretador incluem interpretadores de regra que executam regras lidas de uma fonte externa, interpretadores de script ou linguagem que lêem e executam programas, máquinas virtuais, mecanismos de rede neural que executam redes, mecanismos de lógica, etc. Esta estratégia permite mudar ou parametrizar o comportamento de um sistema por meio de expressões lógicas externas.

Projetos reflexivos ou de nível meta: O sistema é protegido contra o impacto de variações de lógica ou externas do código, por meio de algoritmos reflexivos que utilizam introspecção e serviços de metalinguagem.

Acesso uniforme: Algumas linguagens dão suporte a uma construção sintática de modo que os acessos a um método e a um campo de sejam expressos da mesma maneira.


Referências:


Larmam, Craig

Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados a objetos e ao processo unificado - 2.ed - Porto Alegre:Bookmam, 2004.

Padrões GRASP - parte II (Invenção Pura e Indireção)

Aulas 28 e 29


Sabemos que os princípios de ouro para um bom projeto OO é o baixo acoplamento e a alta coesão, mas e se em algum caso a aplicação de um padrão violar um desses princípios?

Utilizaremos um exemplo dado no livro Utilizando UML e padrões de Craig Larman. No exemplo ele diz “Às vezes, os projetos orientados a objetos são caracterizados por implementarem como classes de software as representações dos conceitos do domínio do problema no mundo real para diminuir o hiato de representação (aqui ele usa o termo “hiato” para se referir às lacunas, espaço, o vago deixado quando se quer representar algo do mundo real no mundo virtual), por exemplo, uma classe Venda e uma classe Cliente.

Entretanto, existem muitas situações em que atribuir responsabilidades apenas às classes de software da camada do domínio leva a problemas em termos de coesão ou acoplamento inadequados ou a um baixo potencial de reutilização.

Suponha, por exemplo, que seja necessário suporte para salvar as instâncias de Venda em um banco de dados relacional. Segundo o padrão Especialista, atribuir responsabilidade à própria classe Venda seria justificável, pois venda tem os dados que precisam ser salvos. Entretanto, considere as implicações a seguir:

A tarefa exige um número relativamente grande de operações de suporte relacionadas ao banco de dados, nenhuma delas voltada ao conceito de venda, de modo que a classe Venda se torna não-coesa.
A classe Venda precisa estar acoplada à interface do banco de dados relacional, de modo que seu acoplamento aumenta.

Salvar objetos em um banco de dados relacional é uma tarefa muito geral, para a qual muitas classes precisam de suporte. Colocar essas responsabilidades na classe Venda sugere que vai haver uma reutilização inadequada ou muita duplicação em outras classes que fazem a mesma coisa.
Entenderam agora como a aplicação do padrão especialista levou a um alto acoplamento e uma baixa coesão? Mas nesse caso, o que fazer se não podemos deixar de aplicar o padrão especialista?

A resposta é o título desta postagem, o padrão Invenção Pura. Uma solução razoável para o problema acima é criar uma classe que seja responsável unicamente por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional. Esta classe é uma Invenção Pura, uma criação da imaginação, e serve para tirar o acoplamento da classe Venda com o banco de dados.

Indireção

O objetivo deste padrão é muito parecido com o que estudamos acima, o padrão Invenção pura. Craig Larman cita em seu livro “Utilizando UML e padrões” que o objetivo do padrão indireção é “atribuir responsabilidade a um objeto intermediário para ser o mediador entre outros componentes ou serviços, para que eles não sejam diretamente acoplados. O intermediário cria uma indireção entre os outros componentes.

Geralmente, o padrão indireção e o Invenção Pura andam juntos, e o problema para o qual são a solução, geralmente é o mesmo, o alto acoplamento. Ao se aplicar um dos dois, não há a necessidade de aplicar o outro, a não ser que haja um certo choque de padrões, como foi explicado no exemplo anterior.

Padrões GRASP - parte II (Polimorfismo)

Aulas 26 e 27



Na área científica definimos polimorfismo como sendo uma propriedade que possui certas substâncias com a capacidade de se apresentarem sob muitas formas, sem mudarem de natureza, ou seja, de tipo. Em que esse pequeno parágrafo tem a ver com o design pattern polimorfismo? Segundo os autores do livro Core Java, Cornell & Horstmann, polimorfismo é a capacidade de um objeto decidir qual método aplicará a si mesmo, dependendo de onde se encontra na hierarquia de herança.

Complementando a idéia dos autores, podemos dizer em outras palavras que polimorfismo é a capacidade de um objeto de se transformar em outros objetos, dependendo do contexto onde está sendo aplicado, sem mudar o seu tipo, isso ocorre através dos métodos que são herdados de uma superclasse.

O questionamento que leva ao uso do polimorfismo é: como criar componentes de softwares conectáveis com base no tipo? Supomos que temos uma classe que faz três diferentes tipos de ações, imagine que uma outra classe sempre disparasse chamadas a essa classe, solicitando a execução de uma dessas ações, ou seja, quando chega a mensagem, teríamos sempre que testar qual seria o tipo de ação a ser executada, e só então executá-la.
If tipoação 1
...
Else
If tipoação 2
...
O design pattern polimorfimo prega que nunca teste o tipo de um objeto nem use condições lógicas no código para executar alternativas com base no tipo. Por que? Respondo com outra pergunta. E se o tipo mudar?
Com base no exemplo dado pelo Wikipedia vamos considerar a seguinte classe escrita em Java:

Esta é uma classe abstrata que representa qualquer operação matemática. Existem várias operações matemáticas, com isso não podemos ficar testando uma por uma. Note que, mesmo que a natureza do cálculo mude, a semântica do método calcular não muda, ou seja, ele sempre calculará o resultado da operação matemática que está sendo trabalhada.

Veremos duas subclasses que implementam duas dessas operações matemáticas

O seguinte trecho de código demonstra o uso do polimorfismo:

Embora o método calcular tenha sido chamado duas vezes em mostrarCalculo, o comportamento apresentado variou de acordo com a classe ao qual ele representava no momento.


http://www.mail-archive.com/java-list@soujava.org.br/msg09906.html
http://www.tecnoclasta.com/2007/12/18/aula-11-classes-interfaces-e-polimorfismo/
http://pt.wikipedia.org/wiki/Polimorfismohttp://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/index.html

Padrões GOF (Padrão MVC

Aulas 24 e 25

MVC significa Model-View-Controller, traduzindo seria, Modelo-Vista-Controlador, para entendermos um pouco sobre um dos mais importantes padrões de projeto, vamos a um exemplo básico:
Imagine que você tenha um sistema de RH e três clientes:
· Um por comodidade só quer acessá-lo pela web;
· Outro por questão de segurança só quer acessar por desktop através de uma rede local;
· E um outro, mais moderno, só quer se conectar ao sistema através de um celular;


Haverá a necessidade de desenvolver 3 interfaces diferentes para cada usuário, um para cada tipo. Já as outras duas camadas, não necessariamente teriam que ser modificadas, tornando assim uma aplicação potencialmente reutilizável. A idéia principal do padrão MVC é isolar a aplicação em camadas distintas, basicamente, a camada de acesso a dados, a camada de apresentação, e a camada de negócios, que respectivamente são o Modelo, o Vista e o Controlador.

O modelo


O modelo é a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas para administrar e manipular dados. De modo geral, a técnica de acesso aos dados deve ser encapsulada no modelo. Desta forma, se uma aplicação for transferida de um sistema que usa um tipo de banco de dados para um sistema que usa outro, o único elemento que precisa ser alterado será o modelo - a vista e o controlador não precisam ser modificados.

A vista


A vista é a parte do componente usada para transformar e preparar os dados do modelo para que possam ser apresentados de alguma forma. O controlador retira os dados do modelo e os entrega para a vista. Esta, por sua vez, alimenta templates com estes dados para que possam ser apresentados ao usuário. A vista não modifica os dados de nenhuma forma, apenas os apresenta.

O controlador


O controlador é responsável pelas respostas às ações dos usuários. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controlador vai determinar qual solicitação foi feita e vai responder de acordo fazendo com que o modelo manipule os dados necessários para depois passá-los para a vista para que possam ser mostrados.
Segundo o Wikipédia, um framework é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de software.
Existem diversos frameworks que abrangem o padrão mvc, mas a maioria deles é voltada para aplicações web, a seguir serão apresentados alguns com os respectivos links direcionando para um material mais aprofundado sobre os mesmos, para quem deseja aprofundar.

ZEND FRAMEWORK
Zend Framework é um framework de código aberto que provê recursos para o desenvolvimento de aplicações e serviços WEB usando a linguagem de programação PHP. Propõe-se a oferecer uma biblioteca de recursos de grande poder, fornecendo soluções modernas, robustas e seguras para o desenvolvedor. Inclui, também, diversos componentes de integração com APIs de serviços, como Flickr, Amazon e Delicious, entre outros.
TUTORIAL SOBRE O ZEND FRAMEWORK
http://akrabat.com/wp-content/uploads/iniciando-com-zend-framework_130.pdf

WEBWORK
O WebWork é um framework java que trabalha com MVC de nível 2. Ele desenvolve o papel de controlar, isto é, ele é o responsável por fazer o direcionamento de acordo com cada requisição. Nele está configurado qual ação (Action) deve ser chamada em cada caso.
FÓRUM SOBRE O WEBWORK CONTENDO UM PEQUENO TUTORIAL
http://www.javafree.org/javabb/viewtopic.jbb?t=8798

ASP.NET MVC FRAMEWORK
Framework da microsoft baseado no padrão MVC para linguagem asp.net. É necessário utilizar o visual studio, ferramenta também da microsoft para desenvolvimento de software.
TUTORIAL SOBRE O ASP.NET MVC FRAMEWORK
http://msdn.microsoft.com/pt-br/magazine/cc337884.aspx


JAVA SERVER FACES
O Java Server Faces é um framework MVC para o desenvolvimento de aplicações Web, que permite o desenvolvimento de aplicações para a internet tal como fazíamos com Delphi ou Visual Basic, ou seja, arrastanto e soltando os componentes na tela (JSP), definindo propriedades dos mesmos.
TUTORIAL SOBRE O JAVA SERVER FACES
http://www.guj.com.br/content/articles/jsf/jsf.pdf


REFERÊNCIAS
http://pt.wikipedia.org/wiki/Apache_Struts
http://www.linhadecodigo.com.br/Artigo.aspx?id=1602
http://www.javafree.org/javabb/viewtopic.jbb?t=8798
http://www.javafree.org/wiki/WebWork
http://akrabat.com/wp-content/uploads/iniciando-com-zend-framework_130.pdf
http://pt.wikipedia.org/wiki/Zend_Framework
http://www.javafree.org/javabb/viewtopic.jbb?t=853237
http://msdn.microsoft.com/pt-br/magazine/cc337884.aspx
https://saloon.inf.ufrgs.br/twiki-data/Disciplinas/CMP167/TF07RuthianoMunaretti/SlidesWebWork.pdf
http://www.marcelomx.com/2007/04/26/desenvolvendo-no-padrao-mvc-com-zend-framework/
http://www.numaboa.com/informatica/tutos/joomla/885-mvc
http://www.guj.com.br/content/articles/jsf/jsf.pdf
http://www.javafree.org/javabb/viewtopic.jbb?t=11749

Padrões GOF (Padrão Command)

Aulas 22 e 23

O objetivo do padrão command é encapsular uma requisição como um objeto permitindo que os clientes parametrizem diferentes requisições, filas ou fazer o registro de log de requisições e dar suporte operações que podem ser desfeitas.
Pra quem não está familiarizado com a maioria dos termos utilizados em java, ou nas linguagens orientada a objeto, vamos procurar entender da maneira mais simples. Encapsulamento para muitos se resume aos métodos get e set, que dá a idéia de proteger um objeto para que ele não seja acessado por qualquer um.
Mas a idéia transmitida pelo padrão command nada tem a ver com encapsulamento como proteção aos dados, mas sim com uma maneira de parametrizar as solicitações dos objetos de forma que estes não fiquem acoplados.
Um exemplo real do uso do padrão command pode ser visto na implementação de uma aplicação cliente/servidor onde geralmente temos o componente Menu que é composto de vários itens. Cada item do menu eqüivale uma operação, como salvar um arquivo, ler arquivo, apagar arquivo, selecionar a paleta de cores e etc.. Quando selecionamos um item do menu uma operação deve ser realizada. Esta operação pode ser encapsulada em um objeto, assim reduziremos o acoplamento entre o objeto menu e o objeto que executa a operação.
Quatro são os participantes na implementação do padrão command:
· Command: Classe abstrata ou interface para execuçãode uma operação.Deve implementar o método abstrato chamado execute.
· CommandAction: Classe concreta que implementa o método execute, ela deve ser uma subclasse se Command for uma classe abstrata, se Command for uma interface então ela deve realizar essa interface.
· Invoker: Objeto que faz uma requisição ao Command para que execute uma operação.
· Receiver: Objeto responsável por executar uma operação.
Abaixo seguem os diagramas de classe e de seqüência que explicam mais detalhadamente essa seqüência de mensagens.

Em tempo de execução o objeto Invoker chama o método execute() do objeto Command que delega ao método action() do objeto receiver que executará a operação.



Link: http://tramos.railsplayground.net/assets/2008/5/17/Padrao_20Projeto_20Command.pdf
http://pt.wikipedia.org/wiki/Command
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm