Padrões GRASP – Parte 2
Variações Protegidas
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.
· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.
· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.
· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.
Padrão não Fale com Estranhos
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. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.
§ 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.
Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil
· O objeto this
· Um parâmetro do método
· Um atributo de this
· Um elemento de uma coleção que seja de this
· Um objeto criado dentro do método
Por exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.
XP – Extreme Programming
XP, ou Extreme programming, é uma metodologia para desenvolvimento de softwares ágil porém com qualidade indicada para projetos cujos requisitos mudem bastante, utilizam desenvolvimento orientado a objetos e tenham uma equipe de até 12 desenvolvedores. XP enfatiza o envolvimento do cliente e promove o trabalho em equipe
Programação Ágil
Na programação Ágil (processos ágeis) a tendência é poder minimizar os riscos no desenvolvimento de softwares.
- Indivíduos e interação entre eles 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.
4 focos principais
comunicação - ao extremo entre cliente e equipe, decisão mútua do que deve ser feito primeiro e o que pode ser deixado pra depois;
simplicidade - manter a simplicidade através do reuso de código e minimizando a construção de código;
feedback - pequenos releases e testes contínuos como mecanismo de retroalimentação;
coragem - ser honesto em dizer o que pode ser feito e o que não pode ser feito.
12 Práticas XP
• Jogo do Planejamento
• Fases Pequenas
• Metáfora
• Design Simples
• Testes
• Refatoração
• Programação em par
• Propriedade Coletiva
• Integração Contínua
• Semana de 40 horas
• Cliente junto aos desenvolvedores
• Padronização do código
No Extreme Programming há vários procedimentos a ser seguidos de forma que o projeto possa ser desenvolvido com maior agilidade, alguns dos procedimentos as serem seguidos são:
· Valores do XP
· Princípios do XP
· Práticas XP
· Papéis
· Decisões de Negócio
· Decisões Técnicas
· Pequenos releases (atualizações)
· Metáfora
· Design simples
· Testes
· Refatoração
· Programação em Par
· Código coletivo
Bibliografia
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 11 Jun 2008, 12:11;
Don Wells, Extreme Programming, Disponível em:
<http://www.extremeprogramming.org/map/project.html> Acessado em: 11 Jun 2008, 12:33;
MARTINS, Juliano, XP - Extreme Programming, Disponível em:
<http://jmmwrite.wordpress.com/2008/02/26/xp-extreme-programming/> Acessado em 12 Jun 2008, 13:03;
Instituto Militar de Engenharia – IME Departamento de Engenharia de Computação - DE/9 Cap Mello, Engenharia de Software, Disponível em:
<http://www.des.ime.eb.br/~cgmello/engsw/modulos/A1-ENGSW-Introducao.pdf> Acessado em: 12 Jun 2008; 22:56;
Variações Protegidas
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.
· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.
· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.
· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.
Padrão não Fale com Estranhos
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. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.
§ 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.
Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil
· O objeto this
· Um parâmetro do método
· Um atributo de this
· Um elemento de uma coleção que seja de this
· Um objeto criado dentro do método
Por exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.
XP – Extreme Programming
XP, ou Extreme programming, é uma metodologia para desenvolvimento de softwares ágil porém com qualidade indicada para projetos cujos requisitos mudem bastante, utilizam desenvolvimento orientado a objetos e tenham uma equipe de até 12 desenvolvedores. XP enfatiza o envolvimento do cliente e promove o trabalho em equipe
Programação Ágil
Na programação Ágil (processos ágeis) a tendência é poder minimizar os riscos no desenvolvimento de softwares.
- Indivíduos e interação entre eles 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.
4 focos principais
comunicação - ao extremo entre cliente e equipe, decisão mútua do que deve ser feito primeiro e o que pode ser deixado pra depois;
simplicidade - manter a simplicidade através do reuso de código e minimizando a construção de código;
feedback - pequenos releases e testes contínuos como mecanismo de retroalimentação;
coragem - ser honesto em dizer o que pode ser feito e o que não pode ser feito.
12 Práticas XP
• Jogo do Planejamento
• Fases Pequenas
• Metáfora
• Design Simples
• Testes
• Refatoração
• Programação em par
• Propriedade Coletiva
• Integração Contínua
• Semana de 40 horas
• Cliente junto aos desenvolvedores
• Padronização do código
No Extreme Programming há vários procedimentos a ser seguidos de forma que o projeto possa ser desenvolvido com maior agilidade, alguns dos procedimentos as serem seguidos são:
· Valores do XP
· Princípios do XP
· Práticas XP
· Papéis
· Decisões de Negócio
· Decisões Técnicas
· Pequenos releases (atualizações)
· Metáfora
· Design simples
· Testes
· Refatoração
· Programação em Par
· Código coletivo
Bibliografia
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 11 Jun 2008, 12:11;
Don Wells, Extreme Programming, Disponível em:
<http://www.extremeprogramming.org/map/project.html> Acessado em: 11 Jun 2008, 12:33;
MARTINS, Juliano, XP - Extreme Programming, Disponível em:
<http://jmmwrite.wordpress.com/2008/02/26/xp-extreme-programming/> Acessado em 12 Jun 2008, 13:03;
Instituto Militar de Engenharia – IME Departamento de Engenharia de Computação - DE/9 Cap Mello, Engenharia de Software, Disponível em:
<http://www.des.ime.eb.br/~cgmello/engsw/modulos/A1-ENGSW-Introducao.pdf> Acessado em: 12 Jun 2008; 22:56;
Nenhum comentário:
Postar um comentário