Estudo de Caso TPV Projetando uma solução com objetos e Padrões GRASP

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de Informação Estudo de Caso TPV Projetando uma solução com objetos e Padrões GRASP

2 Atividades da Fase Projetar Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Reais 3. Refinar a arquitetura do sistema 5. Definir Diagramas de Classes de Projeto 2. Definir Relatórios, IU e Storyboards 4. Definir diagramas de interação 6. Definir o Esquema Do Banco de Dados

3 Como Criar Diagramas de Comunicação Atribuir responsabilidades e criar os diagramas de comunicação são as atividades mais criativas da fase de projeto. Não há soluções mágicas ou não justificadas. Elas devem ser baseadas em raciocínios lógicos e racionais.

4 Diagramas de Comunicação e artefatos anteriores Caixa Sistema entraritem(cup, quantidade) Operação: entraritem Pós-condições: 1. Se for uma nova venda, uma nova venda foi criada... entraritem(cup, qtd) :TPV terminarvenda() Operação: registrarpagamento Pós-condições: registrarpagamento ( quantia) :TPV registrarpagamento (quantia) Diagrama de seqüência do sistema Contratos Diagrama de comunicação

5 Criação dos Diagramas de Comunicação Crie um diagrama separado para cada operação do sistema em desenvolvimento no passo iterativo corrente. Para cada evento do sistema, crie um diagrama com o evento como a mensagem inicial. Se o diagrama se tornar complexo, separe-o em diagramas menores. Usando as responsabilidades e as póscondições dos contratos, projete um sistema de objetos que interagem entre si para executar as tarefas. Use GRASP (e outros conhecimentos) para apoiar a sua decisão.

6 Diagramas de Comunicação para a aplicação TPV Na iteração corrente: dois casos de uso estão sendo tratados: Comprar Itens entraritem terminarvenda EfetuarPagamento Inicializar Inicializar

7 Diagramas de Comunicação para a aplicação TPV Lembretes: As pós-condições são somente uma pista inicial. Use o modelo conceitual como apoio. O contrato é a base para o diagrama de colaboração Comece escolhendo a classe controladora do evento (ou método)

8 Eventos de Sistema do TPV entraritem :TPV 1:???() terminarvenda :TPV 1:???() registrarpagamento :TPV 1:???() inicializar :TPV 1:???()

9 Modelo Conceitual e Diagrama de Comunicação Ponto de partida para os objetos que interagem entre si Novos conceitos poderão surgir, assim como conceitos previamente identificados poderão ser ignorados. É um guia, porém pode conter erros e omissões.

10 Modelo Conceitual do TPV * * LinhadeItemdeVenda quantidade Contido-em Paga-por Venda data tempo 1 Pagamento quantia * 1 1 Iniciada-por Registra-Dados-da v Cliente Registra-venda-de Catálogo de Produtos Usado-por Capturada-em 1 Descritos-por 1 * 1 Loja endereço nome Possui 1 TPV 1..* * Contém 1..* Estoca Iniciado por 1 1 < Registra-Vendas-do Especificação de Produto descrição preço CUP * Descreve Item Gerente Caixa * 1 1

11 Contrato da operação entraritem Nome: entraritem (cup:number, quantidade:integer) Responsabilidades: entrar(registrar) a venda de um item e acrescentá-lo à venda. Exibir a descrição e o preço do item. Pós-condições: Se for uma nova venda, uma Venda foi Criada (c.i.) Se for uma nova venda, a nova Venda foi associada ao TPV (f.a) Uma LinhadeItemdeVenda foi criada (c.i) A LinhadeItemdeVenda foi associada à Venda (f.a) LinhadeItemdeVenda.quantidade recebeu o valor de quantidade (m.a) A LinhadeItemdeVenda foi associada a um(a) (Especificaçãode) Produto, com base no CUP (f.a)

12 Diagrama de Comunicação de entraritem (Cont) Escolhendo a classe Controlador: Opções: TPV ou nova classe SistemadeVarejo, Loja, Caixa, Controlador-ComprarItens Escolha: TPV Satisfatório se houver poucas operações de sistema e o controlador fachada não estiver assumindo muita responsabilidade Tenha em mente que agora o TPV é um objeto no mundo do software. Ele é uma abstração de software que representa o registrador.

13 Diagrama de Comunicação de entraitem segundo o padrão Controlador entraritem(cup,qtd) :TPV

14 Diagrama de Comunicação de entraritem (Cont) Exibir a descrição e o preço do item Não é responsabilidade dos objetos do domínio (TPV ou VENDA) se comunicarem com a camada de interface do usuário (Padrão Separação entre Modelo e Visão): Tudo o que é necessário, com relação a essa responsabilidade, é que os dados sejam conhecidos (ou sejam calculados, conforme as necessidades). A apresentação da descrição e do preço será ignorada, por enquanto.

15 Criar uma nova venda -se for uma nova venda, uma Venda foi criada -se for uma nova venda, a nova Venda foi associada ao TPV entraritem(cup,qtd) segundo o padrão Criador :TPV 1:[nova_venda] criar() :Venda Coleção vazia, conterá futuramente, instâncias de Linha de Item de Venda (multiobjeto) 1.1:criar() :linhadeitemde Venda segundo o padrão Criador

16 Próximo passo Criar uma nova linhadeitemdevenda Uma LinhadeItemdeVenda foi criada (c.i) A LinhadeItemdeVenda foi associada à Venda (f.a) LinhadeItemdeVenda.quantidade recebeu o valor de quantidade (m.a)

17 Criar uma nova LinhaDeItemDeVenda entraritem(cup,qtd) :TPV 3:criarLinhadeItem(espec,qtd) 1:[nova_venda] criar() :Venda 1.1:criar() 3.1:criar(espec,qtd) segundo o padrão Criador :linhadeitemde Venda 3.2:adicionar(lv) lv:linhadeitemdevenda

18 Próximo passo Encontrar a especificação do produto A LinhadeItemdeVenda foi associada a um(a) (Especificaçãode) Produto, com base no CUP (f.a) Quem deveria ser responsável por recuperar uma EspecificaçãodeProduto a partir do CUP? Ou seja quem deveria ser responsável por conhecer uma EspecificaçãodeProduto? Quem deve ter a responsabilidade de encontrar os dados (especificação) do produto? Quais dados devem ser armazenados de forma permanente?

19 Próximo passo Encontrar a especificação do produto-> definir claramente a responsabilidade: Quem deveria ser responsável por conhecer uma Especificação de Produto baseado em uma correspondência de CUP? Que tipo de problema temos? Criação? Escolha de um Controlador? Especialista?

20 Próximo passo Encontrar a especificação do produto Padrão Especialista sugere: o objeto que tenha a informação requerida para cumprir a responsabilidade deve fazê-lo Quem sabe tudo sobre a Especificação de Produto? Observe isso no modelo conceitual:

21 Modelo Conceitual do TPV * * LinhadeItemdeVenda quantidade Contido-em Paga-por Venda data tempo Pagamento quantia * Iniciada-por Registra-Dados-da v Cliente Registra-venda-de Catálogo de Produtos Usado-por Capturada-em Descritos-por * Loja endereço nome Possui TPV 1..* 1..* Contém 1..* Estoca Iniciado por * Especificação de Produto descrição preço UPC < Registra-Vendas-do * Descreve Item Gerente Caixa

22 Próximo passo Visibilidade para um Catálogo de Produtos Quem deveria enviar a mensagem especificação para o Catálogo de Produtos solicitando uma Especificação de Produto? É razoável assumir que uma instância de TPV e de Catálogo de Produtos foram criados durante o caso de uso inicial Inicializar e que exista uma conexão permanente do objeto TPV para o objeto Catálogo de Produtos. Assumindo isso, TPV pode enviar a mensagem especificação para Catálogo de Produtos

23 Diagrama de Comunicação de entraritem (completo) entraritem(cup,qtd) :TPV 3:criarLinhadeItem(espec,qtd) 1:[nova_venda] criar() :Venda 2:espec:=especificação(cup) :Catálogode Produtos 2.1:espec:=encontrar(cup) 1.1:criar() :linhadeitemde Venda 3.2:adicionar(lv) 3.1:criar(espec,qtd) :Especificaçãode Produto lv:linhadeitemdevenda

24 Considerações Um objeto, ao enviar uma mensagem para outro objeto, deve ter visibilidade deste outro objeto. Na versão final de uma aplicação real de ponto de vendas, é improvável que todas as Especificação de Produto estarão realmente na memória. Um BD OO ou relacional será usado, e as recuperações serão realizadas sob demanda. Observe que as mensagens que estão sendo enviadas aos multiobjetos são interpretadas como mensagens ao próprio objeto Coleção.( 1.1 criar, 2.1 Encontrar, 3.2 adicionar)

25 Diagrama de Comunicação:terminarVenda Contrato da Operação: Nome: terminarvenda() Responsabilidades: Registrar que é o fim da entrada de itens de venda e exibir o total da venda Pós-condições: Venda.estáCompleta recebeu o valor true Um Diagrama de Comunicação será construído para satisfazer as pós-condições e responsabilidades de terminarvenda.

26 Diagrama de Comunicação: terminarvenda Pós-condições: Venda.estáCompleta recebeu o valor true TornarseCompleta() terminarvenda() { estácompleta := V} :TPV 1:tornarseCompleta() :Venda segundo o padrão Controlador Encerramento da entrada de itens segundo o padrão Especialista

27 Quem deve ser responsável pela exibição da informação total da venda? Isso deverá ser feito pela camada de apresentação ( a ser discutida mais adiante) Durante a criação do diagrama de comunicação, não se preocupe com a exibição de informações, exceto quando a informação requerida ainda não é conhecida. Garanta que toda informação a ser exibida seja conhecida e esteja disponível nos objetos do domínio. Exemplo: terminarvenda deve informar o total da venda.

28 Processo de raciocínio para encontrar um Especialista para o total da venda Defina a responsabilidade: Quem deveria ser responsável por conhecer o total da venda? Resuma a informação requerida: O total da venda é a soma dos subtotais de todas as linhas de itens de vendas. Subtotal da linha de item de vendas := quantidade da linha de item * preço na descrição do produto. Liste a informação necessária para satisfazer esta responsabilidade e as classes que conhecem esta informação.

29 Informação Requerida para calcular o total da Venda Classe Especialista EspecificaçãodeProduto.preço EspecificaçãodeProduto LinhadeItemdeVenda.quantidade LinhadeItemdeVenda Todas as LinhasdeItemdeVenda na Venda corrente Venda tot:=total() :Venda

30 Calcular o total da venda subtotal() { return quantidade*espec.preço() } tot:=total() :Venda 1*:[para cada]liv:=prox() :LinhadeItemdeVenda 2*: st:=subtotal() liv:linhadeite mdevenda total() { tot:=0 para cada linha de item de venda liv tot:= tot + liv.subtotal() } 2.1:pr:=preço espec: Especifi caçãodeproduto

31 Discussão A mensagem total não está associada a evento de sistema (não é uma operação de um diagrama de sequência) Nem todo o diagrama de comunicação começa com uma mensagem de um evento de sistema; eles podem começar com qualquer mensagem para a qual o projetista deseja mostrar as interações. Quem enviará a mensagem total para a Venda? Provavelmente será um objeto na camada de apresentação

32 Diagrama de Comunicação de registrarpagamento Contrato da Operação: Nome: RegistrarPagamento(quantia: Number) Responsabilidades: Registrar o pagamento, calcular o troco e imprimir o recibo. Pós-condições: Um Pagamento foi criado (ci) Pagamento.quantiaFornecida recebeu o valor de quantia (ma) O Pagamento foi associado à Venda (fa) A Venda foi associada à Loja, para acrescentá-la ao registro histórico de vendas completadas (fa)

33 Registrar Pagamento Controlador: TPV ou Venda? registrarpagamento(quantiafornecida) :TPV Fazer um DC Com Venda como controlador

34 Registrar Pagamento Criando o pagamento Candidatos: TPV e Venda registrarpagamento(quantia Fornecida) :TPV 1: registrarpagamento(quantia Fornecida) Criador + acoplamento baixo :Venda 1.1:criar(quantiaFornecida) :Pagamento

35 Registrando a Venda Padrão Especialista Quem é o responsável por conhecer todas as vendas registradas e fazer esse registro? - Loja - DiáriodeVendas

36 * Loja 1..* Catálogo de Produtos * Usado-por * 1..* 0..1 Especificação de Produto descrição preço UPC 1..* Contém * Descreve * LinhadeItemdeVenda quantidade 1..* Contido-em 0..1 Registra-venda-de * Descritos-por Registrando a Venda Caixa Gerente 1..* 1..* Pagamento quantia Cliente * TPV < Registra-Vendas-do 1..* Iniciado por * Loja endereço nome 1..* Possui * Venda data tempo Paga-por Iniciada-por * Registra-Dados-da v Capturada-em Item * Estoca * Contido-em

37 Registrando a venda: Alternativas Venda Venda Loja... acrescentarven da(v:venda) Registra-dados-da Loja é responsável por conhecer e acrescentar Vendas completadas Registra-dados-da DiáriodeVendas... acrescentarven da(v:venda))

38 Registrando uma venda completada registrarpagamento() 1: registrarpagamento(quantiafornecida) :TPV :Venda 2 : acrescentarvenda(v) :Loja 2.1 : acrescentrar(v) 1.1:criar(quantiaFornecida) :Pagamento VendasCompletadas: Venda

39 Calculando o Troco Quem é responsável por conhecer o troco? Troco = Dinheiro fornecido para pagamento Total da Venda Especialistas parciais: Venda e Pagamento Controlador? Pagamento -> visibilidade para venda (acréscimo de acoplamento) Venda -> visibilidade para pagamento (já possui tal visibilidade)

40 Calculando o Troco Controlador: Venda trc:=troco() Venda troco() {return pg.quantia() total() } :Venda 1: qtia:=quantia() pg:pagamento 2: t:=total() OBS: Um DC pode começar com qualquer mensagem para a qual o projetista deseja mostrar as interações.

41 Diagrama de Comunicação de Iniciar Deixe o diagrama Iniciar por último. Informações significativas relacionadas com as atividades de inicialização devem já ter sido descobertas Objetivo: criar o objeto inicial do domínio. Esse objeto cria então os demais objetos necessários. Então, a operação Iniciar deve: Enviar a mensagem criar() para o objeto inicial do domínio. No seu método de inicialização, o objeto inicial é, responsável pela criação de outros objetos do domínio do problema e por suas inicializações.

42 Exemplo de inicialização, a partir de um applet Java public class TPVApplet extends Applet { public void init ( ) { tpv = Loja.getTPV ( ) } // Loja é o objeto inicial do domínio // O construtor de Loja cria os outros // objetos do domínio private Loja loja = new Loja ( ); private TPV tpv; private Venda venda;

43 A Operação Inicializar da aplicação TPV Ocorre quando um gerente liga o sistema do ponto de venda e carrega o software. Suponha que exista uma interface gráfica de usuário e que um objeto da camada de apresentação será responsável pela criação do objeto inicial do domínio do problema (ex. uma instância de um applet java coordenador da aplicação e da camada de apresentação) O controle permanecerá no applet, após o objeto inicial do domínio ter sido criado. O diagrama de colaboração de Inicializar pode ser interpretado como uma mensagem criar() enviada para criar o objeto inicial.

44 Escolhendo o objeto inicial do domínio Escolha como um objeto inicial do domínio: Uma classe que representa todo o sistema de informação. Uma classe que representa todo o negócio ou organização. Nesta aplicação Loja será escolhida como objeto inicial

45 Objetos persistentes: Especificação de Produto Em uma aplicação real, as instâncias de Especificação de Produto residirão em um BD. O projeto de como carregar objetos, dinamicamente, sob demanda, de um BD OO é simples. (BD relacional é mais difícil) Por enquanto faremos uma hipótese simplificadora: todas as instâncias de Especificação de Produto podem ser magicamente criadas na memória pelo objeto Catálogo de Produtos

46 Contrato Nome: Iniciar Responsabilidades: Iniciar o sistema. Tipo: Sistema Refs cruzadas: Notas: Exceções: Saída: Pré-condições: Pós-condições: Uma Loja, TPV, CatálogodeProdutos e (Especificaçãode)Produto foram criadas (ci) CatálogodeProdutos foi associado a EspecificaçãodeProduto (af) Loja foi associada a CatálogodeProdutos (af) Loja foi associada a TPV (af) TPV foi associado a CatálogodeProdutos (af)

47 criar() Passa refer. do catálogo de produtos a TPV, que terá visibilidade permanente a ele. :Loja 2 : criar (cp) :TPV 1 :criar ( ) 1.1 criar () cp:catálogode 1.2.2* : adicionar (ep) Produtos :Especificãode Produto 1.2 : carregarespecprod( ) O asterisco, no número de seqüência, indica que a mensagem ocorre em uma seção que se repete 1.2.1* : criar(cup,preço,descrição) ep:especificaçãodeproduto

48 Comentários Multiplicidade : observe que a loja cria somente um objeto TPV. Persistência: num sistema real, Persistência: num sistema real, Especificação de Produto residirá num meio de armazenamento permanente (Disco + SGBD)

49 Como ligar a camada de apresentação à camada do domínio :TPVApplet 1: criar() Loja:Loja 2 p:= gettpv:tpv Uma vez que o applet tem uma conexão para a instância de TPV, ele pode repassar ao mesmo mensagens de eventos do sistema: entraritem(), terminarvenda() e outras.

50 Como ligar a camada de apresentação à camada do domínio Camada de apresentação (Applet Java) Camada do Domínio aoentraritem() :TPVApplet 1: entraritem(cup,qtd) Evento do sistema tpv:tpv

51 Como ligar a camada de apresentação Camada de apresentação à camada do domínio Para obter o subtotal corrente, o TPVAPPLET: aoentraritem() :TPVApplet 3: t:=total(): Float Obtém uma referência para a venda Armazena essa referência em um atributo Envia uma mensagem total para a Venda para obter a informação necessária para exibir o total corrente na janela Camada do Domínio tpdv:tpv 1:entrarItem(cup,qtd) venda:venda 2 :[nenhuma venda] venda:=getvenda ( ) : Venda

52 Responsabilidades das camadas de apresentação e do domínio A camada de apresentação não deve ter responsabilidades sobre a lógica da aplicação. Camada de apresentação deve ser responsável somente por tarefas de apresentação (interface), tais como atualizar widgets (componentes da interface) A camada de apresentação deve repassar todas as solicitações para a camada do domínio.

53 Resumo Projetar interações de mensagens e atribuir responsabilidades é a parte principal do projeto OO. Essas escolhas de projeto tem um impacto profundo sobre a capacidade de extensão, clareza, facilidade de manutenção de um sistema de software OO e sobre o grau de qualidade dos componentes reutilizáveis. Os padrões GRASP resumem alguns dos princípios mais gerais e mais comuns usados por projetistas de sistemas OO (princípios de bons projetos)

54 Próxima aula Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Reais 3. Refinar a arquitetura do sistema 5. Visibilidade e Diagramas de Classes de Projeto 2. Definir Relatórios, IU e Storyboards 4. Definir diagramas de interação 6. Definir o Esquema Do Banco de Dados

55