domingo, 9 de março de 2008

Padrão Especialista ( na prática )

Aula 8 (em Laboratório)


Nesta aula vimos a aplicação prática do padrão especialista, a implementação em código. Vamos pegar como exemplo uma parte de um modelo que tem como objetivo calcular o total de uma venda, especificando cada produto, a quantidade de cada produto, e o sub-total de cada item de venda, este diagrama contêm 3 classes somente, são essas classes:

Partiremos do princípio de todo esquema para uma venda, saber o total dela, portanto, qual a classe responsável por conhecer o total de uma venda? A classe responsável terá que conhecer todas as instâncias ItemVenda da Venda e o subtotal de cada uma delas, portanto a classe Venda é uma forte candidata pois uma Venda contém ItemVenda. Definida a classe que calcula o total de uma venda, vamos definir a classe responsável por conhecer o subtotal de uma venda, para isso é necessário saber a quantidade de cada produto, quem detém estas informações é a classe ItemVenda, portanto esta é a classe responsável por implementar o método de calcular subtotal. Mas para implementar este método a classe ItemVenda precisa conhecer o preço unitário de cada produto, e é aí que entra a responsabilidade da classe produto, que é obter especificação do produto para mandar como resposta para a classe ItemVenda quando esta enviar uma mensagem para obter o preço de cada produto.

No final, com todos os métodos em suas respectivas classes, o diagrama ficou assim:

Implementando em código:

public class Produto
{
private integer idProduto;
private string descricao;
private double valorUnitário;

public string getdescricao(){
return descricao;
}

public void setDescricao(string valor){
valor=descricao;
}
}


public class ItemVenda{
private double qtde;
private Produto p;

public void setP (Produto p) {
this.p = p;
}


public class Venda {
private Set itemVendaList=new HashSet();
private Date dataVenda;
private integer idvenda;


public criarItemvenda (Produto P, double qtde)
{
Itemvenda i =new ItemVenda();
i .setP(p);
i.setQtde(qtde);
itemVendaList.add(i);

}
}


observação: nos diagramas as classes "LinhaDeVenda" e "EspecificaçãoProduto" são as mesmas classes "ItemVenda" e "Produto" do trecho de código

domingo, 2 de março de 2008

Padrões GRASP (Padrão Criador)

Aulas 6 e 7


Nos artigos anteriores vimos que um programa construído no paradigma de orientação a objetos é nada mais que uma coleção de objetos interagindo entre si, mas o que vem a ser um objeto? Na linguagem técnica, um objeto é uma instância de uma classe, e o que é uma instância? O ato de criar objetos a partir de uma ou várias classes se chama instanciação. Mas como é feito esse trabalho de criar objetos? Objetos são criados a partir de chamadas de procedimento, ou seja, de mensagens(métodos) enviadas por classes para que sejam criados novos objetos, mas agora, vem o ponto crucial deste assunto que estamos estudando, qual a classe correta, ou seja, qual a mais indicada para criar novas instâncias de outra classe(objetos)? Afinal, existem muitos deles dentro de um programa, e não é qualquer classe que pode sair criando objetos à vontade, portanto vamos à explicação:

Segundo o Padrão Criador (Creator), para que uma classe tenha a responsabilidade de criar instâncias de outra classe é necessário que se aplique o procedimento a seguir: Vamos supor que existam duas classes A e B, a classe responsável por criar instância da outra será aquela em que mais de uma das seguintes condições se aplicar:

a. B agrega objetos da classe A.

b. B contém objetos da classe A.

c. B registra instâncias da classe A.

d. B usa muitos objetos da classe A.

e. B possui os dados usados para inicializar A.

quarta-feira, 27 de fevereiro de 2008

Padrões GRASP (Padrão Especialista na informação)

AULA 5

Como foi abordado na postagem anterior, padrões de software são princípios gerais de soluções que guiam o desenvolvimento de software, em outras palavras, são normas que permitem o desenvolvimento de alta qualidade de produtos de software. Existem nove destes padrões, mas vamos nos concentrar apenas nos cinco primeiros que são:

  1. Especialista na informação: Padrão mais utilizado para atribuir responsabilidades, é aquele que atribui responsabilidades a quem realmente detêm a informação necessária para preencher os requisitos daquela responsabilidade.
  2. Padrão Criador: qual a classe responsável por criar instâncias de outra?
  3. Baixo Acoplamento: responsável por minimizar dependências entre as classes e maximizar o reuso.
  4. Alta Coesão: responsável por manter a alta coesão entre as classes, ou seja, delegar responsabilidades e não deixar que certas classes assumam responsabilidades de outras.
  5. Controlador: responsável por tratar eventos do sistema, eventos são operações geradas por um ator externo do sistema.

Agora que já definimos cada um dos cinco primeiros padrões, vamos entender cada um com mais clareza.

Padrão Especialista

O principal objetivo dos padrões de projeto de software é a atribuição de responsabilidades, e o padrão especialista como o próprio nome já diz, é aquele responsável por atribuir responsabilidade à classe que tem informação necessária para suprir aquela responsabilidade.

É o padrão mais usado de todos, a informação necessária para uma determinada classe geralmente está espalhada entre várias classes, e através deste padrão é possível descobrir esta informação, bem como no mesmo caminho feito para esta descoberta, conhecer outros “expert information” de outras classes que estão relacionadas entre si.

As conseqüências do uso deste padrão é que o encapsulamento é mantido, já que objetos usam sua própria informação para cumprir responsabilidades, leva ao fraco acoplamento entre objetos e à alta coesão já que objetos fazem tudo que é relacionado à sua própria informação.

Este Padrão também é conhecido como:

  1. "Colocar as responsabilidades com os dados";
  2. "Quem sabe, faz";
  3. "Animação";
  4. "Eu mesmo faço";
  5. "Colocar os serviços junto as atributos que eles manipulam";

5 primeiros Padrões

sábado, 16 de fevereiro de 2008

Atribuições de Responsabilidades e Padrões de Projeto

Aula 4


Quando entramos em um novo emprego e já temos experiência nas atividades que vamos exercer naquela empresa pode ocorrer duas coisas: primeiro, o chefe nos atribui responsabilidades sobre a nossa parte do serviço, ou seja, temos obrigação de fazer determinadas tarefas, é o que foi designado para fazermos, segundo, como já temos experiência sobre o serviço que nos foi passado, ou seja, já conhecemos o trabalho que iremos desenvolver, temos a obrigação de conhecer sobre as nossas responsabilidades.

A mesma coisa acontece com um sistema orientado a objeto, ele é composto de objetos que enviam mensagens uns para os outros, lembrando que uma mensagem é um método executado no contexto de um objeto, ou melhor, dentro do objeto, pois bem, continuando, se um objeto de uma classe não sabe quando disparar determinado método ou conhecer os objetos ao qual está relacionado, definitivamente a comunicação entre objetos nesse sistema estará seriamente comprometida.

Padrões de software são um conjunto de princípios gerais e de soluções que guiam o desenvolvimento de software. São eles que definem a distribuição de responsabilidades entre objetos ou classes. Segundo a UML, as responsabilidades de objetos estão divididas em dois tipos e possuem diferentes granularidades:

Obrigação de fazer: o objeto pode fazer algo a si mesmo, pode iniciar, controlar ou coordenar ações em outros objetos.

Obrigação de conhecer: um objeto tem obrigação de conhecer os objetos aos quais está relacionado, conhecer dados encapsulados.

Granularidade baixa: uma responsabilidade pode envolver um único método, ou poucos.

Granularidade alta: uma responsabilidade pode envolver dezenas classes e métodos.

Só lembrando que uma responsabilidade não é um método, mas os métodos são usados para implementar responsabilidades.



Referências:

Padrões para atribuir Responsabilidades


quarta-feira, 13 de fevereiro de 2008

Diagramas de Interação

Aula 3


A UML é uma linguagem para especificação, documentação e melhor visualização de sistemas orientados a objetos. Ela permite que os desenvolvedores visualizem melhor os produtos do seu trabalho através de diagramas, mas não diz como fazê-los.

A UML possui diversos diagramas, sendo a maioria deles para a fase de análise, os mais importantes da fase de projeto são os diagramas de interação, estes diagramas são responsáveis por mostrar como as mensagens interagem entre os objetos, lembrando que essas mensagens se referem a métodos, e um objeto só se comunica com outro se conhecer os métodos deste, um objeto ainda pode mandar mensagens a outro mesmo quando ele não estiver ativo, ou até mesmo quando ainda não foi criado, isso é possível através do conceito de enfileiramento, basicamente como o cash de um sistema operacional. Os diagramas de interação podem se subdividir em dois: Diagrama de Seqüência e Diagrama de colaboração.

Diagrama de Seqüência:

Ilustram a interação entre os objetos através de raias que são colocadas sempre à direita de cada novo objeto, as mensagens para cada objeto seguem uma ordem vertical de cima para baixo, com isso a clareza dessas mensagens é evidente. As trocas de mensagens podem ser tanto síncronas, quando o controle é passado para o objeto que foi invocado até que esse método termine sua execução, quanto assíncrona, quando o controle é passado diretamente para o objeto que invoca o método.

Particularmente é um bom diagrama para se trabalhar, pela simplicidade e pela fácil localização de mensagens.

Ex:

Diagrama de colaboração:

O diagrama de colaboração, diferentemente do diagrama de seqüência, procura dá ênfase na localização estrutural dos objetos e não na ordem temporal das mensagens destes objetos, a identificação dos objetos é feita através de enumeração, uma vez que estes ficam misturados, é difícil identificá-los, assim como no de seqüência, um objeto é representado por um retângulo e a convenção na troca de mensagens também é a mesma.

O diagrama de colaboração possui uma notação mais complexa, mas são os mais adequados para explicar ou demonstrar rapidamente um processo na lógica de um programa.

Ex:

Referências:

Unicap

Elementos da UML

domingo, 10 de fevereiro de 2008

Análise e Projeto Orientados a objeto

Aula 1 e 2

Análise e projeto orientados a objetos, quais são as diferenças entre eles e quais as definições de cada um.

A análise é a fase onde é feita o levantamento de informações que definirão as características do sistema, esse é um passo importante, pois não se trata somente de levantar dados aleatoriamente, mas de compreender o objetivo daquele sistema. No caso da análise orientada a objetos é onde é feita a representação dos objetos e suas estruturas, definições de classes, relacionamento entre objetos e classes, além de observar o comportamento dos objetos.

Já o projeto parte do ponto onde termina a análise, ou seja, inicia-se a partir dos dados levantados através da investigação feita pela análise, em outros termos, é uma investigação mais profunda, onde começa a surgir a solução para o problema.

Em uma linguagem mais simples, a análise é onde é definido o problema, entender o problema, já o projeto é a solução, criar soluções para o problema. Na análise as informações são para o cliente discutir e aprovar, já no projeto as informações são importantes apenas para o programador.