quinta-feira, 26 de abril de 2012
Problemas com os aspectos
Tudo possui vantagens e desvatagens. E é importante se conhecer as duas faces. Com a programação orietada a aspectos não é diferente. Iremos agora explorar os pontos negativos deste
-Depuração:Ao se usar a orientação a aspectos, não se é possivel depurar erros nos trechos de interceção entre os dois codigos, aspecto e codigo base.Dessa maneira, a eliminação de bug e falhas se torna mais complexa.
-Execução inadvertida de aspect por metodo: Se o programador não souber ou esquecer os pointcuts que os aspectos estão monitorando, os resultados podem ser imprevisiveis.
-Estagio inicial: Esse paradigma ainda não foi completamente estudado, analisado, consolidado, deixando muitas brechas ainda abertas em seus usos.
-Falta de incentivo, metodologias: Esse paradigma é pouco divulgado, não existem muitos incentivos abertos a seu uso, assim como a inexistencia de uma metodogia para seu uso.
-Advices multiplos se referindo a mesmo pointcut: Se varias referencias apontam para o mesmo ponto do programa sem observação atenta, o resultado da execução de ambos é dubia, podendo comprometer o sistema.
-Pointcut duplicado, anonimo, usado em outro aspecto: Todos esses, combinando com a falta de depuração, tambem geram problemas de confusão que podem levar muito tempo para serem encontrados.
Existem mais problemas relacionados a orientação a aspectos que não foi comentada aqui. Mas sabendo destes, cada um pode agora avaliar se vale a pena o uso desse paradigma ou não em seus projetos.
referencias:
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_aspecto
http://www.dextra.com.br/empresa/artigos/aspectprog.htm
http://www.guj.com.br/java/22100-orientacao-a-aspectos-x-padroes-de-projeto/2
http://www.ic.unicamp.br/~rocha/college/src/aop.pdf
http://www.lisha.ufsc.br/teaching/sce/ine6511-2003-2/work/aopj/relatorio.pdf
Postado por: Douglas Viana dos Santos, ADS - 6º periodo
terça-feira, 24 de abril de 2012
Padrão de Projeto Iterator
Classificado como
padrão comportamental da família de padrões GoF, o iterator Fornece uma maneira
de acessar seqüencialmente os elementos de um objeto agregado sem expor sua
implementação.
Estrutura
Participantes
IteradorConcreto :
- Implementa a interface Iterator.
- Mantém o controle da posição corrente no percurso do agregado.
ColecaoConcreta : implementa a interface de criação do Iterador para retornar uma instância do ConcreteIterador.
O exemplo (adaptado
[Software Design Patterns, 2005]), ilustrado na Figura 2, é muito simples,
basicamente o usuário adiciona dados do tipo String na quantidade que
desejar e a qualquer momento pode navegar entre estes dados utilizando os métodos
fornecidos pela interface IteradorIF.
A ColecaoConcreta aplicará
uma estrutura de dados desconhecida, ou seja, a forma com que ela armazena os
objetos não interessará à classe Cliente. ColecaoConcreta poderá
utilizar lista ordenadas, listas encadeadas, algum tipo de árvore ou qualquer
outra estrutura, entretanto a forma como o cliente fornecerá e posteriormente
fará a leitura desta lista de objetos sempre será a mesma.
Referencia:
Software Design Patterns, 2005
Postado por: Hélio Marcus, ADS - 6º Período
Padrão de Projeto Composite
Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado para representar listas recorrentes - ou recursivas - de elementos. Além disso, esta forma de representar elementos compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetos atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.
Consequências
Estrutura
 |
| Estrutura do Padrão de Projeto Composite |
Consequências
|
Implementação
Este exemplo (adaptado [Software Design Patterns, 2005]) do padrão Composite representa uma simulação de sua funcionalidade propriamente dita, ele foi retirado e adaptado do site. É apresentado através na classe Tela dois botões para mostrar todas as folhas e componentes e outro simplesmente para limpar. Também se utiliza o padrão para construir uma estrutura de árvore gráfica composta de nós primitivos (estes nós podem ser substituídos por linhas, círculos, etc) e nós compostos (grupos de elementos que formam elementos mais complexos).
Fonte:
Fonte:
Postado por: Argemiro Júnior, ADS - 6º Período
Padrão de Projeto State
State é um padrão de projeto de software usado para permitir que um objecto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe.
O padrão State deve ser utilizado nas seguintes situações:
O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado. Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da instrução condicional numa classe separada. Desta forma, o estado do objecto pode ser tratado como um objecto ele próprio, o qual pode variar.
Ao modelar um objeto cujo estado é importante, pode-se descobrir que há uma variável que monitora o modo como esse objeto deveria se comportar, dependendo do seu estado. Essa variável pode aparecer em comandos if complexos, em cascata, que focalizam como reagir aos eventos que o objeto pode experimentar.
O padrão State, ilustrado na Figura 1, oferece uma abordagem mais limpa e simples, utilizando uma operação distribuída.
Implementação
A implementação de exemplo para o padrão State é um quiz, ou seja, uma seqüência de perguntas com opções de respostas, na qual de acordo com o número de respostas corretas, será retornado uma nota. Neste quiz, é acrescida alguma regra a mais para o cálculo de pontos. Normalmente o número de respostas corretas é proporcional a nota final. No entanto, este quiz introduz um cálculo, considerando a seqüência de perguntas acertadas.
Por exemplo, inicialmente cada pergunta respondida corretamente traz um ganho de cinco pontos sendo este estado definido pela classePontuacao1, mas se o usuário acertar duas em seqüência faz com que o valor da pergunta fique em dez pontos, que é definido pela classePontuacao2. Caso consiga-se acertar cinco perguntas seqüencialmente a resposta correta valerá vinte. Mudanças também ocorrerão quanto a perca de pontos ao errar perguntas e caso peça ajuda.
No exemplo, ilustrado na Figura 2, PontuacaoIF assume o papel da interface de Estado, enquanto Pontuacao1, Pontuacao2 e Pontuacao3são as implementações desta interface.JanelaState é a classe de apresentação para o cliente, enquanto BuscaPergunta é classe que vai buscar em algum lugar as perguntas e respostas para o jogo. Pergunta é classe VO utilizada para o transporte entre BuscaPergunta e JanelaState e fornecida posteriormente paraContexto visando o cálculo total de pontos conquistados com a resposta da determinada pergunta.
Código
O padrão State deve ser utilizado nas seguintes situações:
O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado. Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da instrução condicional numa classe separada. Desta forma, o estado do objecto pode ser tratado como um objecto ele próprio, o qual pode variar.
Estrutura
O padrão State, ilustrado na Figura 1, oferece uma abordagem mais limpa e simples, utilizando uma operação distribuída.
 |
| Estrutura do padrão State |
Implementação
Por exemplo, inicialmente cada pergunta respondida corretamente traz um ganho de cinco pontos sendo este estado definido pela classePontuacao1, mas se o usuário acertar duas em seqüência faz com que o valor da pergunta fique em dez pontos, que é definido pela classePontuacao2. Caso consiga-se acertar cinco perguntas seqüencialmente a resposta correta valerá vinte. Mudanças também ocorrerão quanto a perca de pontos ao errar perguntas e caso peça ajuda.
No exemplo, ilustrado na Figura 2, PontuacaoIF assume o papel da interface de Estado, enquanto Pontuacao1, Pontuacao2 e Pontuacao3são as implementações desta interface.JanelaState é a classe de apresentação para o cliente, enquanto BuscaPergunta é classe que vai buscar em algum lugar as perguntas e respostas para o jogo. Pergunta é classe VO utilizada para o transporte entre BuscaPergunta e JanelaState e fornecida posteriormente paraContexto visando o cálculo total de pontos conquistados com a resposta da determinada pergunta.
 |
| Exemplo de aplicação |
Fonte:
Postado por: Argemiro Júnior, ADS - 6º Período
Padrão de Projeto Builder
Builder é um padrão de projeto de software que permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
O padrão Builder, da forma como foi descrito no livro Design Patterns: Elements of Reusable Object-Oriented Software, contém os seguintes elementos:
director — constrói um objeto utilizando a interface do builder;
builder — especifica uma interface para um construtor de partes do objeto-produto;
concrete builder — define uma implementação da interface builder, mantém a representação que cria e fornece interface para recuperação do produto;
product — o objeto complexo acabado de construir. Inclui classes que definem as partes constituintes.
O padrão Builder pode ser utilizado em uma aplicação que converte o formato RTF para uma série de outros formatos e que permite a inclusão de suporte para conversão para outros formatos, sem a alteração do código fonte do leitor de RTF.
A implementação da solução para esse problema pode ser realizada através de uma classe de leitura (director) associada a uma classe capaz de converter o formato RTF para outra representação (builder). O objeto da classe de leitura lê cada token do texto e executa o método apropriado no objeto de conversão, de acordo com tipo do token. A classe de conversão possui um método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes e etc. Para cada formato de texto suportado é criada uma classe de conversão especializada (concrete builder). Um conversor para formato ASCII, por exemplo, poderia ignorar qualquer requisição para converter tokens que não fossem caracteres comuns. Um conversor para o formato PDF, por outro lado, iria processar qualquer requisição para poder converter o estilo, além do texto.
Diagrama
Código
O padrão Builder, da forma como foi descrito no livro Design Patterns: Elements of Reusable Object-Oriented Software, contém os seguintes elementos:
director — constrói um objeto utilizando a interface do builder;
builder — especifica uma interface para um construtor de partes do objeto-produto;
concrete builder — define uma implementação da interface builder, mantém a representação que cria e fornece interface para recuperação do produto;
product — o objeto complexo acabado de construir. Inclui classes que definem as partes constituintes.
 |
| Diagrama UML da estrutura do padrão Builder |
A implementação da solução para esse problema pode ser realizada através de uma classe de leitura (director) associada a uma classe capaz de converter o formato RTF para outra representação (builder). O objeto da classe de leitura lê cada token do texto e executa o método apropriado no objeto de conversão, de acordo com tipo do token. A classe de conversão possui um método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes e etc. Para cada formato de texto suportado é criada uma classe de conversão especializada (concrete builder). Um conversor para formato ASCII, por exemplo, poderia ignorar qualquer requisição para converter tokens que não fossem caracteres comuns. Um conversor para o formato PDF, por outro lado, iria processar qualquer requisição para poder converter o estilo, além do texto.
Diagrama
.png) |
| Exemplo de Diagrama em UML para o Padrão Builder. |
Código
Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.
A classe Cliente determina, através do parâmetro passado ao programa Java ("pdf" para formato PDF, "tex" para Tex e qualquer outro para ASCII), qual das classes derivadas de ConversorTexto irá utilizar na construção da classe LeitorRTF.
Fonte:
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2
- http://pt.wikipedia.org/wiki/Builder
Postado por: Argemiro Júnior, ADS - 6º Período
abstract class ConversorTexto {
public void converterCaractere(char c) {
// vazio
}
public void converterParagrafo() {
// vazio
}
public void converterFonte(Fonte f) {
// vazio
}
}
class ConversorPDF extends ConversorTexto {
public void converterCaractere(char c) {
System.out.print("Caractere PDF");
}
public void converterParagrafo() {
System.out.print("Parágrafo PDF");
}
public void converterFonte(Fonte f) {
System.out.print("Fonte PDF");
}
}
class ConversorTeX extends ConversorTexto {
public void converterCaractere(char c) {
System.out.print("Caractere Tex");
}
public void converterParagrafo() {
System.out.print("Paragrafo Tex");
}
public void converterFonte(Fonte f) {
System.out.print("Fonte Tex");
}
}
class ConversorASCII extends ConversorTexto {
public void converterCaractere(char c) {
System.out.print("Caractere ASCII");
}
}
class LeitorRTF {
private ConversorTexto conversor;
LeitorRTF(ConversorTexto c) {
this.conversor = c;
}
public void lerRTF() {
List<Token> tokens = obterTokensDoTexto();
for (Token t : tokens) {
if (t.getTipo() == Token.Tipo.CARACTERE) {
conversor.converterCaractere(t.getCaractere());
}
if (t.getTipo() == Token.Tipo.PARAGRAFO) {
conversor.converterParagrafo();
}
if (t.getTipo() == Token.Tipo.FONTE) {
conversor.converterFonte(t.getFonte());
}
}
}
}
public class Cliente {
public static void main(String[] args) {
ConversorTexto conversor;
if (args[0].equals("pdf")) {
conversor = new ConversorPDF();
} else if (args[0].equals("tex")) {
conversor = new ConversorTeX();
} else {
conversor = new ConversorASCII();
}
LeitorRTF leitor = new LeitorRTF(conversor);
leitor.lerRTF();
}
}
A classe Cliente determina, através do parâmetro passado ao programa Java ("pdf" para formato PDF, "tex" para Tex e qualquer outro para ASCII), qual das classes derivadas de ConversorTexto irá utilizar na construção da classe LeitorRTF.
Fonte:
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2
- http://pt.wikipedia.org/wiki/Builder
Postado por: Argemiro Júnior, ADS - 6º Período
Programação Orientada a Aspectos - Um paradigma em evolução
A alguns anos atrás uma metodologia para desenvolvimento de software era a famosa “Dividir para conquistar”, apesar de funcionar, ela trazia consigo alguns problemas de implementação, um exemplo desse problemas, era a existência de várias linhas de código que sobravam e sem nenhum propósito e causando redundância e inconsistências de dados, além da dificuldade de manter de utilizar do artifício de reuso de código.
Devido a esse problemas surgiu-se a necessidade de uma nova abordagem na produção de sistemas de computadores, foi quando surgiu o novo paradigma de programação orientado a objetos, que era baseado em classes e objetos, isso fez com que os problemas desaparecessem , porém, outros surgiram. Hoje mesmo com todos os recursos da orientação a objetos, muitos desenvolvedor ainda sentem dificuldade em implementar certas entidades do mundo real em objetos do sistema. Embora exista fundamento para expressar uma solução como um conjunto de vários objetos, ainda temos funcionalidades que devem ser aplicadas em diversos deles.
Hoje o que sabemos é que o paradigma orientado a objetos consegue suprir quase todas as necessidades em programação, porém ainda não completamente, devido impactos ocorrentes de novas funcionalidades do sistema em determinada etapa do desenvolvimento pode causar problemas de inconsistência na estrutura do sistema, a ocorrência disso dar-se devido a o modelo orientado a objetos ser estático.
O surgimento da Programação Orientada a Aspectos não de maneira nenhuma substituir qualquer paradigma de programação, muito menos o Orientado a Objetos. Ele veio para completá-lo promovendo novas implementações e uma forma de interação diferente, permitindo que novos requerimentos possam ser facilmente agregados ao sistema, e que funcionalidades inerentes a vários objetos sejam facilmente desenvolvidas modularmente. Por isso esses paradigmas se completam devido a modularidade da orientação a aspectos junto com a orientação a objetos.
O AOP também não veio substituir o SOP (Subject Oriented Programming) já que cada um tem propósitos distintos. O SOP tende a tratar as funcionalidades do sistema como subjects. Mais tarde, em outra etapa, todos esses subjects são agrupados para formar o sistema. Embora um subject possa ser definido como um conjunto de objetos que tenham finalidades semelhantes dentro do sistema, o que é muito semelhante a um aspect, eles distinguem-se pelo fato de um aspect ter sua definição dinâmica no nível de instância de um objeto, enquanto o subject é completamente estático.
Fonte: http://javafree.uol.com.br/artigo/6626/AOP-Um-paradigma-de-desenvolvimento-em-evolucao.html
Postado por: Murilo Almeida, ADS - 6º Período
Devido a esse problemas surgiu-se a necessidade de uma nova abordagem na produção de sistemas de computadores, foi quando surgiu o novo paradigma de programação orientado a objetos, que era baseado em classes e objetos, isso fez com que os problemas desaparecessem , porém, outros surgiram. Hoje mesmo com todos os recursos da orientação a objetos, muitos desenvolvedor ainda sentem dificuldade em implementar certas entidades do mundo real em objetos do sistema. Embora exista fundamento para expressar uma solução como um conjunto de vários objetos, ainda temos funcionalidades que devem ser aplicadas em diversos deles.
Hoje o que sabemos é que o paradigma orientado a objetos consegue suprir quase todas as necessidades em programação, porém ainda não completamente, devido impactos ocorrentes de novas funcionalidades do sistema em determinada etapa do desenvolvimento pode causar problemas de inconsistência na estrutura do sistema, a ocorrência disso dar-se devido a o modelo orientado a objetos ser estático.
O surgimento da Programação Orientada a Aspectos não de maneira nenhuma substituir qualquer paradigma de programação, muito menos o Orientado a Objetos. Ele veio para completá-lo promovendo novas implementações e uma forma de interação diferente, permitindo que novos requerimentos possam ser facilmente agregados ao sistema, e que funcionalidades inerentes a vários objetos sejam facilmente desenvolvidas modularmente. Por isso esses paradigmas se completam devido a modularidade da orientação a aspectos junto com a orientação a objetos.
O AOP também não veio substituir o SOP (Subject Oriented Programming) já que cada um tem propósitos distintos. O SOP tende a tratar as funcionalidades do sistema como subjects. Mais tarde, em outra etapa, todos esses subjects são agrupados para formar o sistema. Embora um subject possa ser definido como um conjunto de objetos que tenham finalidades semelhantes dentro do sistema, o que é muito semelhante a um aspect, eles distinguem-se pelo fato de um aspect ter sua definição dinâmica no nível de instância de um objeto, enquanto o subject é completamente estático.
Fonte: http://javafree.uol.com.br/artigo/6626/AOP-Um-paradigma-de-desenvolvimento-em-evolucao.html
Postado por: Murilo Almeida, ADS - 6º Período
Decorator
Padrão de Projeto Decorator
Pertencente à família de padrões estruturais do conjunto de padrões de projeto GoF, o Decorator, ou Wrapper, tem como finalidade agregar comportamentos a objetos existentes em tempo de execução. Portanto, pode-se utilizar também a definição de que o Decorator agrega responsabilidades adicionais a um objeto dinamicamente, oferecendo uma alternativa flexível ao uso de herança para extender uma funcionalidade.
Referencias:
SILVA, V. T. Padrões de Design. Wikipedia.org. Acessado em 2012
Postado por: Hélio Marcus Torres de Arêa Leão
Pertencente à família de padrões estruturais do conjunto de padrões de projeto GoF, o Decorator, ou Wrapper, tem como finalidade agregar comportamentos a objetos existentes em tempo de execução. Portanto, pode-se utilizar também a definição de que o Decorator agrega responsabilidades adicionais a um objeto dinamicamente, oferecendo uma alternativa flexível ao uso de herança para extender uma funcionalidade.
Intenção
· Acrescentar responsabilidades a um objeto dinamicamente
· Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe
· Acrescentar responsabilidades a um objeto dinamicamente
· Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe
Motivação
· Objeto usado possui as funcionalidades básicas, mas é necessários adicionar funcionalidades adicionais a ele que podem ocorrer antes ou depois da funcionalidade básica.
· Funcionalidades devem ser adicionadas em instancias individuais e não na classe.
· Objeto usado possui as funcionalidades básicas, mas é necessários adicionar funcionalidades adicionais a ele que podem ocorrer antes ou depois da funcionalidade básica.
· Funcionalidades devem ser adicionadas em instancias individuais e não na classe.
Consequencias
· Mais flexibilidade do que herança
o Adição ou remoção de responsabilidades em tempo de execução
o Adição da mesma propriedade mais de uma vez
· Evita o excesso de funcionalidades nas classes.
· Decorator e seu componente não são idênticos.
o Comparações tornam-se mais complexas
· Resulta em um design que tem vários pequenos objetos, todos parecidos
· Mais flexibilidade do que herança
o Adição ou remoção de responsabilidades em tempo de execução
o Adição da mesma propriedade mais de uma vez
· Evita o excesso de funcionalidades nas classes.
· Decorator e seu componente não são idênticos.
o Comparações tornam-se mais complexas
· Resulta em um design que tem vários pequenos objetos, todos parecidos
Aplicabilidade
· Acrescentar ou remover responsabilidades a objetos individuais dinamicamente, de forma transparente
· Evitar a explosão de subclasses para prover todas as combinações de responsabilidades
· Acrescentar ou remover responsabilidades a objetos individuais dinamicamente, de forma transparente
· Evitar a explosão de subclasses para prover todas as combinações de responsabilidades
Implementação
Outro Exemplo
1. // a caixa de texto é o componente "decorado"
2.
JTextArea txt = new JTextArea();
3.
4. // "decora" a caixa de texto com barras de rolagem
5.
Component comp = new JScrollPane(txt);
6.
7. // adiciona o componente com barras de rolagem no form
8.
getContentPane().add(comp);
Referencias:
SILVA, V. T. Padrões de Design. Wikipedia.org. Acessado em 2012
Postado por: Hélio Marcus Torres de Arêa Leão
domingo, 15 de abril de 2012
Orientação a Aspectos – Anatomia
O paradgma de programação orientada a aspectos envolve duas etapas. Uma delas é a decomposição do sistema em diversas partes isoladas e não espalhadas. Essa é a parte mais simples de implementar. A outra etapa significa juntar novamente essas partes para obter um sistema desejado. O processo de juntar essas partes pode ser entendido com “composição” já que compõem várias partes antes separadas. Além disso existem três etapas para ser determinadas durante o processo de composição na orientação a aspectos:
Correspondência: A forma de correspondência da linguagem é o modo com o qual se descreve quais entidades serão compostas entre si. A correspondência pode ser implícita (determinada por regras da linguagem) ou explícita (descrita pelo programador). Por exemplo, no exemplo acima que mostra duas políticas, podemos dizer que há uma correspondência implícita entre eles - os métodos com os mesmos nomes estão relacionados.
Semântica composicional: é o que deve acontecer com os elementos que correspondem. Em geral, linguagens de POA modificam a semântica das chamadas a métodos:
Em linguagens procedurais, chamar a função F implica em executar a função F.
Em linguagens orientadas a objetos, chamar o método M implica em executar algum método M em uma das subclasses que definem M.
Em linguagens orientadas a aspectos, chamar o método M pode ter diversas consequências:
M é executado, ou
N (algum outro método) é executado, ou
M+N são executados, em alguma ordem definida
A linguagem pode definir diversas semânticas diferentes que em geral são escolhidas pelo programador. No exemplo da última aula, uma linguagem de POA permitiria que o usuário definisse o que acontece com os métodos que têm o mesmo nome (ou seja, que correspondem): se um for chamado, os dois devem ser executados? em que ordem? apenas um deve ser executado? qual?
Tempo de ligação: diz respeito ao momento em que a correspondência passa a surtir efeito; pode ser estático (em tempo de compilação) ou dinâmico (em tempo de execução).
A ferramenta ou compilador que faz a composição dos elementos em POA é chamado weaver (tecelão), pois "tece" os vários fragmentos de programa em um programa único.
A forma de composição das partes é o que realmente distingue linguagens orientadas a aspectos de outras linguagens. Em linguagens procedurais ou orientadas a objetos, a composição é feita através de chamadas de procedimentos ou métodos. Ou seja, uma parte (por exemplo, uma classe) usa a funcionalidade de outra chamando um método.
Em POA, não há chamadas explícitas de métodos entre partes. Ao invés disso, especifica-se, em uma parte separada, como uma parte deve reagir a eventos que acontecem em outra parte. Essa estratégia reduz o acomplamento entre as partes, pois as partes não se acessam diretamente.
Benefícios da programação orientada a aspectos:
· Menos responsabilidades em cada parte
· Melhor modularização
· Evolução facilitada
· Mais possibilidades de reutilização.
Fonte: http://www.aspectos.org/courses/aop.html
Postado por: Murilo Almeida, ADS - 6º Período
Correspondência: A forma de correspondência da linguagem é o modo com o qual se descreve quais entidades serão compostas entre si. A correspondência pode ser implícita (determinada por regras da linguagem) ou explícita (descrita pelo programador). Por exemplo, no exemplo acima que mostra duas políticas, podemos dizer que há uma correspondência implícita entre eles - os métodos com os mesmos nomes estão relacionados.
Semântica composicional: é o que deve acontecer com os elementos que correspondem. Em geral, linguagens de POA modificam a semântica das chamadas a métodos:
Em linguagens procedurais, chamar a função F implica em executar a função F.
Em linguagens orientadas a objetos, chamar o método M implica em executar algum método M em uma das subclasses que definem M.
Em linguagens orientadas a aspectos, chamar o método M pode ter diversas consequências:
M é executado, ou
N (algum outro método) é executado, ou
M+N são executados, em alguma ordem definida
A linguagem pode definir diversas semânticas diferentes que em geral são escolhidas pelo programador. No exemplo da última aula, uma linguagem de POA permitiria que o usuário definisse o que acontece com os métodos que têm o mesmo nome (ou seja, que correspondem): se um for chamado, os dois devem ser executados? em que ordem? apenas um deve ser executado? qual?
Tempo de ligação: diz respeito ao momento em que a correspondência passa a surtir efeito; pode ser estático (em tempo de compilação) ou dinâmico (em tempo de execução).
A ferramenta ou compilador que faz a composição dos elementos em POA é chamado weaver (tecelão), pois "tece" os vários fragmentos de programa em um programa único.
A forma de composição das partes é o que realmente distingue linguagens orientadas a aspectos de outras linguagens. Em linguagens procedurais ou orientadas a objetos, a composição é feita através de chamadas de procedimentos ou métodos. Ou seja, uma parte (por exemplo, uma classe) usa a funcionalidade de outra chamando um método.
Em POA, não há chamadas explícitas de métodos entre partes. Ao invés disso, especifica-se, em uma parte separada, como uma parte deve reagir a eventos que acontecem em outra parte. Essa estratégia reduz o acomplamento entre as partes, pois as partes não se acessam diretamente.
Benefícios da programação orientada a aspectos:
· Menos responsabilidades em cada parte
· Melhor modularização
· Evolução facilitada
· Mais possibilidades de reutilização.
Fonte: http://www.aspectos.org/courses/aop.html
Postado por: Murilo Almeida, ADS - 6º Período
Padrão de Projeto Expert
O padrão Expert faz parte dos padrões de projeto classificados como GRASP. O objetivo dele é atribuir determinada responsabilidade a uma classe. Deve ser observada a classe que tem as informações relevantes para desempenhar a responsabilidade.
Tomemos como exemplo um sistema PDV (ponto de venda), onde gostaríamos de atribuir a responsabilidade “cálculo do total de um pedido” à uma classe. Observamos então, em nosso sistema, qual a classe “expert” das informações necessárias para a obtenção desse total e a ela será delegada essa responsabilidade.
Dentro deste contexto, a classe “expert” do conteúdo relevante à obtenção da informação desejada é a “Pedido”, pois ela possui a lista de produtos que serão utilizados para o cálculo do valor total do pedido. Portanto, a ela será designada a responsabilidade “cálculo do total de um pedido”.
Benefícios:
– Leva a projetos onde o objeto de software faz o que o objeto real faria
– Mantém o encapsulamento e não aumenta o acoplamento, pois utiliza informações próprias
– Distribui o comportamento uniformemente entre as classes do sistema, aumentando a coesão das mesmas
Sinônimos:
– Colocar responsabilidades com os dados
– Aquele que conhece faz
– Quem sabe faz
– Animação
– Fazê-lo eu mesmo
– Colocar os serviços com os atributos que eles utilizam
– Especialista na informação
Referências:
• MURTA, L. G. P. – “Aula Padrões de Projeto GRASP” - Universidade Federal Fluminense - RJ, 2007
• Craig Larman, 1999, “Utilizando UML e Padrões”, 1ª ed., Prentice-Hall
• Craig Larman, 2007, “Utilizando UML e Padrões”, 3ª ed., Bookman.
Postado por: Hélio Marcus, ADS - 6º Período
Modelagem de Requisitos Orientada a Aspectos
O levantamento de requisites é fator crucial na etapa inicial de desenvolvimento de software. É durante essa etapa que todos ou grande maioria das funcionalidades do sistema são discutidas por isso se exige muito critério durante esse processo por parte dos especialistas para determinar qual a melhor maneira de detectar e determinar quais serão os requisitos iniciais do sistema.
Mesmo com todas as técnicas utilizadas no processo de levantamento de requisitos essas abordagens ainda são muito imaturas. E necessário um estudo ainda mais minucioso, a questão é, como tratar mais cedo responsabilidades que serão parte de um sistema até o fim, como prever problemas, como modelá-las? Como vincular componentes?
Para facilitar a fase de levantamento de requisitos propomos um método de integração com características transversais. Esse método é implementado na linguagem de programação orientada a aspectos, uma delas é a AspectJ. Seguindo o modelo da linguagem orientada a aspectos o nosso modelo de levantamento de requisitos tente em separar as responsabilidades em módulos distintos. A intenção é trazer o modelo de programação orientada a aspectos para o levantamento de requisitos, e desta forma isolar responsabilidades de outras partes do sistema, através de um mecanismo que tornará possível o gerenciamento de requisitos de forma transversal.
A separação das responsabilidades será realizada, através da separação de características e metas. A composição é realizada pelo um mecanismo que gera um modelo único do sistema sendo desenvolvido, facilitando a inclusão e exclusão de características e responsabilidade desse modelo. Além disso, é possível extrair diferentes visões dos modelos separados melhorando assim na hora de modelar, pois, podemos visualizar a aplicação em diferentes perspectivas diferentes durante a modelagem, facilitando a identificação das responsabilidades envolvidas no sistema.
Segue imagem com o método de integração de características.
Postado por: Murilo Almeida, ADS - 6º Período
Padrão de Projeto Mediator
O Mediator é um padrão de projeto pertencente ao conjunto GoF de padrões de projeto. Classificado como padrão comportamental devido a maneira que ele pode alterar seu a execução do software.
O objetivo do mediator é gerenciar as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo. Foi criado para resolver problemas de comunicação entre classes em um sistema, diminuindo assim a complexidade e o acoplamento. Melhora a leitura e manutenibilidade do programa, que seria muito maior caso não existisse o mediador no projeto, pois as colaborações teriam que ser distribuídas entre as próprias classes, gerando a necessidade de mecher em todas, caso fosse necessário atualizar algo. Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando.
Exemplo em um jogo:
Esse exemplo ilustra o projeto de um jogo de RPG em turnos. Existem 3 classes, “Ken” e “Ryu” representando os lutadores, e a classe “Fight” que é o nosso mediador, responsável por gerenciar as interações entre os lutadores. Em nenhum momento as classes que estao sendo mediadas conversaram entre si, sempre interagem com o mediador que faz a comunicação entre elas.
Referencias:
•http://abrindoojogo.com.br/padroes-de-projeto-para-games-mediador
•http://imasters.com.br/artigo/21642/dotnet/o-padrao-de-projeto-mediator-na-pratica
•http://s2i.das.ufsc.br/tikiwiki/apresentacoes/padroes_de_projeto.pdf
•http://www.allapplabs.com/java_design_patterns/mediator_pattern.htm
•http://pt.appbrain.com/app/air-control-lite/dk.logisoft.aircontrol
Postador por: Hélio Marcus, ADS - 6º Período
segunda-feira, 2 de abril de 2012
Composição de um sistema Orientado a Aspectos
Um sistema que utiliza programação orientada a aspectos é composto dos seguintes componentes:
A linguagem de componentes que deve permitir ao programador escrever programas que implementem as funcionalidades básicas de um sistema, sem precisar prever nada do que será implementado com a linguagem em aspectos. A linguagem de componentes concentra-se na fase de análise de requisitos do sistema, mas precisamente envolvidos com a regra de negócio.
Linguagem de Aspectos: A linguagem de aspectos dever suportar a implementação das propriedades desejadas de forma clara e concisa, fornecendo mecanismos necessários ao programador elabora estruturas que definam como os aspectos serão envolvidos.
Programas de componentes: é um arquivo fonte escrito em determinada linguagem de programação, por exemplo: Java, C, C++, onde o desenvolvedor codifica regra de negócio de acordo com a análise de requisitos.
Um ou mais programas de aspectos: é o arquivo fonte codificado em um linguagem de aspectos como, por exemplo: AspectJ, AspectC entre outras. A ainda a preocupação de determinar qual linguagem de aspectos será utilizada para determinada situação, pois elas tem características diferentes e são aplicadas para tarefas especificas.
Combinador de Aspectos: a sua função é combinar os programas escritos em uma determinada linguagem de componentes, que são as classes onde são determinadas a regra de negócio, com os programas escritos em linguagem de aspectos, as classes aspectos.
 |
Composição de sistemas utilizando programação orientada a aspectos. |
Postado por: Murilo Almeida, ADS - 6º Período
quinta-feira, 29 de março de 2012
Command
O command tem como objetivo encapsular uma solicitação com um objeto, permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro de solicitações e suportem operações que podem ser desfeitas.
Um exemplo de um Portão Eletrônico que possui um controle que faz o portão abrir e fechar. Na figura 2 está a implementação do Portão.
 |
| Figura 2 – Classe Portao |
A classe portão possui um atributo estado, onde quando for igual a 0, o portão está aberto, enquanto for igual a 1 o portão está fechado. A classe também possui o método abrir que abre o portão e o método fechar que fecha o portão.
 |
| Figura 3 – Interface Command |
Na figura 3 está representado a interface Command, que possui o método execute e também o método undo, o qual é opcional, porque nem todas as ações possibilitam uma operação de desfazer.
 |
| Figura 4 – Classe AbrirCommand |
Na figura 4 é apresentado a classe AbrirCommand, que é um ConcreteCommand, sua funcionalidade é fazer um portão abrir através do método execute. Para isto, a classe traz um atributo do tipo portão, que precisa ser “setado“ através do construtor. Além de abrir o portão essa classe também possibilita desfazer a operação de abrir, através do método undo que faz o oposto do execute, fechando o portão.
 |
| Figura 5 – Classe Controle |
Na figura 5 é mostrado a classe Controle que é o Invoker, ela armazena Commands e chama o método execute do command. Além disto, ela possui um outro atributo command (ultimoCommand) que armazena o ultimo command que foi usado, através disso, o controle possui um método desfazer que chama o método undo do ultimo command utilizado.
A principal consequência do Command é que ele desacopla o objeto que invoca a operação daquele que sabe como executá-la. Ao visualizar o diagrama de sequência na figura 2 ficará mais claro como isto ocorre.
 |
| Figura 6 – Diagrama de Sequência |
Primeiro o Client cria um novo Command especificando seu Receiver, em seguida este Command é armazenado em um Invoker. O Invoker quando quer chamar a ação do Receiver, usa o método execute do Command que por sua vez chama a ação do Receiver. Deste modo o Invoker não conhece como funciona a ação e também não conhece o Receiver.
Para conhecer mais sobre o padrão recomendo que baixem o slide disponível, olhem o exemplo implementado e que façam a atividade prática proposta. Também é interessante ler as referências que foram utilizadas para este trabalho.
Referências
GAMMA, Erich; HELM; Richard; JOHSON, Ralph; VLISSIDES, John – Padrões de Projeto – Soluções reutilizáveis de software orientados a objeto .
FREEMAN, Eric – Use a cabeça!: Padrões de Projetos (Design Patterns).
Postado por: Argemiro Júnior, ADS - 6º Período
terça-feira, 27 de março de 2012
Adapter
"Objetivo: converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces." [GoF]
Duas formas de Adapter
Forma 1
• Class Adapter: usa herança múltipla
• Cliente: aplicação que colabora com objetos aderentes à interface Alvo
• Alvo: define a interface requerida pelo Cliente
• ClasseExistente: interface que requer adaptação
• Adaptador (Adapter): adapta a interface do Recurso à interface Alvo
Forma 2
Object Adapter: usa composição
• Única solução se Alvo não for uma interface Java
• Adaptador possui referência para objeto que terá sua interface
adaptada (instância de ClasseExistente).
• Cada método de Alvo chama o(s) método(s) correspondente(s)
na interface adaptada
Quando usar?
• Sempre que for necessário adaptar uma
interface para um cliente
• Class Adapter
• Quando houver uma interface que permita a
implementação estática
• Object Adapter
• Quando menor acoplamento for desejado
• Quando o cliente não usa uma interface Java ou
classe abstrata que possa ser estendida
Fonte:
Padrões Design de Projeto com aplicações em Java (argonavis)
[1][Metsker] Steven John Metsker, Design Patterns Java Workbook.
Addison-Wesley, 2002,
[2][GoF] Erich Gamma et al. Design Patterns: Elements of
Reusable Object-oriented Software. Addison-Wesley, 1994
[3] James W. Cooper. The Design Patterns Java Companion.
http://www.patterndepot.com/put/8/JavaPatterns.htm
[4][Larman] Craig Larman, Applying UML and Patterns, 2nd.
Edition, Prentice-Hall, 2002
[5][EJ] Joshua Bloch, Effective Java Programming Guide, AddisonWesley, 2001
[6][JMM FAQ] Jeremy Manson and Brian Goetz, JSR 133 (Java
Memory Model) FAQ, Feb 200
Postado por: Hélio Marcus, ADS - 6º Período
segunda-feira, 26 de março de 2012
Desenvolvimento de Aplicações que utilizam conceitos de Tecnologia Adaptativa
A simplicidade e eficiência sempre foram fatores importantes e cruciais para boas praticam de desenvolvimento de software. Linguagens de programação estão sendo desenvolvidas para essa linha. Desde sempre os desenvolvedores procuram desenvolver linguagens que possibilitem maior flexibilidade na implementação de sistemas, seja ele de qualquer nível de dificuldade. As linguagens chegaram ao conceito de POO (Paradigma de programação orientada a objetos), que possui uma capacidade de trazer “objetos do mundo real” para a programação. Mas apesar de todos os seus recursos que facilitam o desenvolvimento de sistemas complexos, ainda sim existem problemas que a Orientação Objetos deixa a desejar, ela até resolve o problema, mas de uma maneira não muito aconselhável, podendo prejudicar a flexibilidade, entendimento e por fim o reuso do código.
Em 1997, Gregor Kiczales e alguns cientistas do PARC (Xerox Palo Alto Research Center) desenvolveram um novo paradigma de programação o POA (Programação Orientada a Aspectos) com a finalidade solucionar falhas de programação que a POO não conseguia fazer com eficiência. Segundo os criadores, a POA procura separar a parte do sistema que eles chama de interesses das classes e módulos bem definidos a regra de negócio, dessa forma os analistas podem se dedicar a um interesse de forma independente.
Mas mesmo com os novos recursos oferecidos pela POA, existia a necessidade de uma linguagem que tratasse o sistema como componentes de forma mais inteligente e flexível para mudanças, essa linguagem orientada a componentes pode ser entendida como um paradigma orientado a objetos ou ser uma linguagem estruturada. Um outra característica em aplicações complexas é a de se automatizarem seu comportamento. Dessa forma o uso da programação adaptativa ganha força, permitindo criar e desenvolver sistemas de alta complexidade mas que dividida em vários módulos distintos, tornando-os independentes na aplicação e que podem adaptar-se com facilidade a mudanças de rotina como casos de uso por exemplo.
Postado por: Murilo Almeida, ADS - 6º Período
quarta-feira, 21 de março de 2012
Strategy
É um padrão comportamental que tem por objetivo apresentar uma interface para classes que contém métodos com o mesmo nome e diferem entre si apenas na implementação dos métodos. Dentro deste contexto, interface é, não apenas classes abstratas marcadas com palavra reservada INTERFACE, mas também para qualquer modelo reutilizável e abstrato, seja explicitamente uma interface ou classe abstrata. Segue um exemplo:
Em uma loja, existem várias promoções ao longo do ano. É criada então uma interface para a promoção que deverá ser implementada nas classes que irão conter o comportamento para a promoção específica:
package com.strategy;
import java.math.BigDecimal;
public interface Promocao {
BigDecimal desconto();
}
BigDecimal desconto();
}
As classes das promoções:
class PromocaoDeNatal implements Promocao {
@Override
public BigDecimal desconto() {
return 10;
}
public BigDecimal desconto() {
return 10;
}
}
class PromocaoDiaDosNamorados implements Promocao {
@Override
public BigDecimal desconto() {
return 15;
}
public BigDecimal desconto() {
return 15;
}
}
class PromocaoQueimaDeEstoque implements Promocao {
@Override
public BigDecimal desconto() {
return 40;
}
}
public BigDecimal desconto() {
return 40;
}
}
public class Celular extends Produto {
public Celular() {
this.promocao = new PromocaoDeNatal();
}
}
public Celular() {
this.promocao = new PromocaoDeNatal();
}
}
Fontes:
Padrão de projetos: Strategy – por Robson Farias - http://serpeerless.wordpress.com/2008/06/22/entendendo-o-padrao-de-projetos-strategy/
Sérginho Vittorino – Padrões de Projeto - http://www.youtube.com/user/SerginhoVittorino?feature=watch
Postador por: Hélio Marcus, ADS - 6º Período
Assinar:
Postagens (Atom)