A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1A)

Apresentações semelhantes


Apresentação em tema: "Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1A)"— Transcrição da apresentação:

1 Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1A)

2 Prof. Msc. Emerson Silas Dória2 Artefatos de análise capturam os resultados do processo de investigação do domínio do problema Da Análise ao Projeto Casos de Uso Quais são os processos do domínio? Modelo ConceitualQuais são os conceitos, termos? Diagramas de Seqüência do Sistema Quais são os eventos e operações do sistema? Contratos O que fazem as operações do sistema?

3 Prof. Msc. Emerson Silas Dória3 A partir dos artefatos da fase de análise é desenvolvida uma solução lógica baseada no paradigma orientado a objetos. Os Diagramas de Interação são a base de tal solução lógica, posteriormente, são criados os Diagramas de Classes de Projeto. O Começo da Fase Projetar

4 Prof. Msc. Emerson Silas Dória4 Descrevendo Casos de Uso Reais Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diagrama de interação b. ordem variada

5 Prof. Msc. Emerson Silas Dória5 Casos de Uso Reais Projeto “real” de um caso de uso em termos de tecnologias concretas de entrada/saída e sua implementação geral Referências a janelas, componentes da interface com o usuário, mecanismos de interação, etc. Necessários apenas se o desenvolvedor ou cliente requer uma descrição minuciosa (detalhada) da interface com o usuário antes da implementação

6 Prof. Msc. Emerson Silas Dória6 Casos de Uso Reais Exemplo de um caso de uso real Caso de uso: Atores: Finalidade: Visão Geral: Comprar Itens com Dinheiro Cliente, Operador Capturar uma venda e seu pagamento em dinheiro. Um Cliente chega no caixa, com itens que deseja comprar. O Operador registra os itens de compra e recebe um pagamento em dinheiro. Ao final, o Cliente deixa a loja com os itens. Tipo: Referências Cruzadas: Primário e Essencial Funções : R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

7 Prof. Msc. Emerson Silas Dória7 Seqüência Típica de Eventos Ação do Ator Resposta do Sistema 2. Para cada item, o Operador digita o código universal de produto (UPC) no campo A da Janela 1. Se houver mais de um exemplar do item, a quantidade pode ser digitada opcionalmente. Ele então pressiona o botão “Entra Item” com o mouse ou pressiona a tecla. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda corrente. Mostra a descrição e o preço do item corrente no campo B e F da Janela Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar. Object Store Entrar Item UPC Total Quantidade Fornecido Troco A C E G H Terminar Venda I Registrar Pagamento J Preço Descrição B D F Casos de Uso Reais

8 Prof. Msc. Emerson Silas Dória8 Definindo Diagramas de Interação Sinc. Artefatos AnáliseProjeto Teste Refin. Plano Impl. 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diagrama de interação b. ordem variada

9 Prof. Msc. Emerson Silas Dória9 Ponto de Partida Os contratos não mostram uma solução de como os objetos de software procederão para satisfazer as pós-condições. Pós-condições: n Se for uma nova venda, uma Venda foi criada (criação de instância); n Se for uma nova venda, a nova Venda foi associada ao POST (formada uma associação); n Um ItemVenda foi criado (criação de instância); n O ItemVenda foi associado à Venda (formada uma associação); n...

10 Prof. Msc. Emerson Silas Dória10 Diagramas de Interação Um Diagrama de Interação ilustra como os objetos interagem através de mensagens para cumprir tarefas. A criação de um DI depende da criação prévia dos seguinte artefatos: Modelo Conceitual: subsidia a definição de classes de software correspondentes a conceitos, cujos objetos participam dos DI;

11 Prof. Msc. Emerson Silas Dória11 Diagramas de Interação continuando... Contratos: subsidia a definição de responsabilidades e as pós-condições que os DI devem satisfazer Casos de Uso Reais ou Essencias: subsidia a coleta de informações sobre quais tarefas os DI ilustram, além do que está nos contratos

12 Prof. Msc. Emerson Silas Dória12 Diagramas de Colaboração Ênfase na organização estrutural dos objetos que enviam e recebem mensagens Diagramas de Interação Diagramas de Seqüência Ênfase na ordenação temporal das mensagens: :Instância_ClasseA:Instância_ClasseB 1: mensagem2( ) 2: mensagem3( ) mensagem1( ) :Instância_ClasseA:Instância_ClasseB 1: mensagem2( ) 2: mensagem3( ) mensagem1( )

13 Prof. Msc. Emerson Silas Dória13 Diagramas de Interação Exemplo de Diagrama de Colaboração para a operação RegistrarPagamento: :POST :Pagamento :Venda RegistrarPagamento(df) 1:RegistrarPagamento(df) 1.1:Criar(df) primeira mensagem direção da mensagem instância primeira mensagem interna

14 Prof. Msc. Emerson Silas Dória14 Como Fazer um Diagrama de Colaboração Regras úteis: 1. Criar um diagrama em separado para cada uma das operações de sistema em desenvolvimento. Para cada mensagem de operação de sistema, criar um diagrama com essa mensagem como mensagem inicial. 2. Se um diagrama se tornar muito complexo, o diagrama deve ser dividido. 3. Utilizar as responsabilidades e pós-condições dos contratos das operações de sistema, e a descrição dos casos de uso para projetar um sistema cujo objetos interajam para cumprir tarefas.

15 Prof. Msc. Emerson Silas Dória15 Diagramas de Colaboração e Outros Artefatos Operação:EntrarItem Pós-Condições: 1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância); Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) EntrarItem(UPC,quantidade) :Sistema Operador TerminarVenda() RegistrarPagamento(quantia) DSSOperações do Sistema Contratos Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor... Diag. Colaboração :POST EntrarItem(UPC, quantidade)

16 Prof. Msc. Emerson Silas Dória16 Classes e Instâncias Notação Básica para DI Ligações, Mensagens, Parâmetros POST p1:Pagamento:Venda classe instância instância nomeada :POST msg1( ) :Venda 1:msg1(a,b ) 2:msg2( ) 3:msg3( )

17 Prof. Msc. Emerson Silas Dória17 Notação Básica para DI Valor de Retorno Mensagem para “self” ou “this” :POST msg1( ) 1:clear( ) :POST msg1( ) :Venda 1:tot:=total( ):integer

18 Prof. Msc. Emerson Silas Dória18 Notação Básica para DI Iteração Cláusula de Iteração :POST msg1( ) :Venda 1*:l:=proximaLinhaItem( ) :POST msg1( ) :Venda 1*[i:=1..10]:l:=proximaLinhaItem( ) * Expressa mensagem enviada repetidamente

19 Prof. Msc. Emerson Silas Dória19 Seqüenciamento de Mensagens Notação Básica para DI :ClasseA msg1( ) :ClasseB 1:msg2( ) :ClasseC :ClasseD 2.1:msg5( ) 1.1:msg3( ) 2:msg4( ) 2.2:msg6( )

20 Prof. Msc. Emerson Silas Dória20 Mensagens Condicionais Notação Básica para DI :POST msg1( ) :Venda 1:[nova venda] criar( ) :ItemVenda Expressa que a mensagem só deve ser enviada se o valor de nova venda for TRUE em tempo de execução.

21 Prof. Msc. Emerson Silas Dória21 Caminhos Condicionais Mutuamente Exclusivos Notação Básica :ClasseA msg1( ) :ClasseB 1a:[test]msg2( ) :ClasseC :ClasseD 2.1:msg5( ) 1.1:msg3( ) 1b:[not test]msg4( ) 2.2:msg6( ) Expressa que a mensagem 1a ou 1b podem ser executadas, dependendo do teste lógico entre [].

22 Prof. Msc. Emerson Silas Dória22 Mensagens para uma coleção Notação Básica Coleções (multiobjects) :ClasseB vendas:Venda Expressa um conjunto lógico de instâncias (Ex: Vector em Java) :Venda msg1( ) :ItemVenda 1:s:=size():int :ItemVenda Expressa uma mensagem enviada a Java.util.Vector, por exemplo, para descobrir o número de elementos no Vetor (objeto coleção)

23 Prof. Msc. Emerson Silas Dória23 Mensagens para uma coleção e um elemento Notação Básica :Venda msg1( ) iv:ItemVenda 1:criar( ) :ItemVenda 2:additem(iv )

24 Prof. Msc. Emerson Silas Dória24 Mensagens para um objeto classe Notação Básica :Venda msg1( ) Data 1:d1:=today( ):Date Expressa uma mensagem sendo enviada para uma classe

25 Prof. Msc. Emerson Silas Dória25 Atribuição de Responsabilidades O POO às vezes é definido como: “Identificado os requisitos e o modelo conceitual, acrescente os métodos às classes de software e defina as mensagens/troca de mensagens (DI) para atender os requisitos”

26 Prof. Msc. Emerson Silas Dória26 Atribuição de Responsabilidades Contratos: suposição preliminar sobre as responsabilidades e as pós-condições das operações Diagramas de Interação: ilustram a solução, em termos de objetos interatuantes, que satisfazem responsabilidades e pós- condições POO -> Atribuição de Responsabilidade -> Bons Projetos OO

27 Prof. Msc. Emerson Silas Dória27 Responsabilidades e Métodos Responsabilidade é “um contrato ou obrigação de um tipo ou classe” (Booch e Rumbaugh, 1997) Relacionada as obrigações dos objetos em termos de comportamento. Tipos básicos De fazer (alguma coisa) Ex: fazer algo individualmente, iniciar ações em outros objetos, controlar ou coordenar atividades em outros objetos De conhecer (alguma coisa) Ex: dados privados encapsulados, objetos relacionados, informação derivada ou calculada

28 Prof. Msc. Emerson Silas Dória28 Responsabilidades e Métodos Responsabilidades são atribuídas aos objetos do sistema durante o Projeto OO “Uma Venda é responsável por imprimir a si própria” (de fazer) “Uma Venda é responsável por conhecer sua data” (de conhecer) Tradução de responsabilidades para classes e métodos é influenciada pela granularidade da responsabilidade Um único método para “imprimir venda” Dezenas de métodos para “prover um mecanismo de acesso a SGBDR”

29 Prof. Msc. Emerson Silas Dória29 Responsabilidades e Métodos Métodos são implementados para cumprir responsabilidades Podem agir sozinhos ou em colaboração com outros métodos e objetos Exemplo: A classe Venda pode definir um ou mais métodos específicos para cumprir a responsabilidade de imprimir Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos ItemVenda associados à Venda.

30 Prof. Msc. Emerson Silas Dória30 Diagramas de Interação ilustram decisões de atribuição de responsabilidades a objetos. Quais mensagens são enviadas para diferentes classes e objetos? Responsabilidades e DI Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP. :Venda imprimir( ) iv:ItemVenda 1:[para cada] iv:=next( ) :ItemVenda iv:ItemVenda 2:imprimir( ) Implica que objetos Venda têm uma responsabilidade de imprimirem a si mesmos.

31 Prof. Msc. Emerson Silas Dória31 Padrões (Patterns) “Um padrão é um par nomeado problema/solução que pode ser aplicado em novos contextos, com conselhos sobre sua aplicação em novas situações e uma discussão sobre as conseqüências de seu uso.” Capturam princípios fundamentais da engenharia de software. Em geral, não contêm novas idéias nem soluções originais Codificam soluções existentes comprovadas Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problemas.

32 Prof. Msc. Emerson Silas Dória32 Padrões GRASP (General Responsibility Assignment Software Patterns) Atribuição competente de responsabilidades a objetos: Cruciais no POO e ocorre na construção dos Diagramas de Interação Padrões: pares de problema/solução que codificam orientações e princípios freqüentemente relacionados com a atribuição de responsabilidades. Cinco padrões mais comuns (Especialista; Criador; Alta Coesão; Baixo Acoplamento; Controlador)

33 Prof. Msc. Emerson Silas Dória33 Padrão Especialista (Expert) Solução Atribuir responsabilidade para o especialista na informação - a classe que tem a informação necessária para cumprir a responsabilidade. Problema Qual é o princípio básico pelo qual responsabilidades são atribuídas em POO? Exemplo: Quem deve ser responsável por conhecer o total de uma venda? Informação necessária: conhecer todas as instâncias ItemVenda da Venda e o subtotal de cada uma delas. Somente uma instância de venda conhece isso. Segundo o padrão EXPERT, devemos procurar a classe de objetos que tem a informação necessária para determinar o total.

34 Prof. Msc. Emerson Silas Dória34 Pelo padrão, a classe Venda deve ser a responsável. Venda data hora, status ItemVenda quantidade EspecificaçãoProduto descrição preço UPC contém descrito 1..* * Modelo Conceitual Parcial Padrão Especialista (Expert) Venda data hora obter_total() :Venda t:obter_total( ) Aqui ocorrem as definições de responsabilidade.

35 Prof. Msc. Emerson Silas Dória35 Mas quem deve ser responsável por conhecer o subtotal de um ItemVenda? Informação necessária: ItemVenda.quantidade e EspecificaçãoProduto.preço Pelo padrão, a classe ItemVenda deve ser a responsável. Padrão Especialista (Expert) :ItemVenda :Venda t:obter_total( ) iv:ItemVenda:ItemVenda 2:st:=obter_subtotal() 1*:[para cada]iv:next( ) Venda data hora obter_total( ) Aqui ocorrem as definições de responsabilidade. ItemVenda quantidade obter_subtotal()

36 Prof. Msc. Emerson Silas Dória36 Porém, para cumprir essa responsabilidade de conhecer ou informar seu subtotal um ItemVenda precisa conhecer o preço do Item. Portanto, o ItemVenda deve mandar uma mensagem para a EspecificaçãoProduto para saber o preço do item. Padrão Especialista (Expert) :ItemVenda :Venda t:obter_total( ) iv:ItemVenda:ItemVenda 2:st:=obter_subtotal( ) 1*:[para cada]iv:next( ) 2.1:p:=obter_preço( ) :Especificação Produto Venda data hora, status obter_total( ) Aqui ocorrem as definições de responsabilidade. ItemVenda quantidade obter_subtotal() EspecificaçãoProduto descrição preço UPC obter_preço( )

37 Prof. Msc. Emerson Silas Dória37 Concluindo, para cumprir a responsabilidade de conhecer e informar o total da venda, três responsabilidades foram atribuídas a três classes de objetos: Classe VendaConhecer total da venda Responsabilidade ItemVendaConhecer subtotal do item EspecificaçãoProdutoConhecer preço do produto Padrão Especialista (Expert)

38 Prof. Msc. Emerson Silas Dória38 Contra-Indicações Indesejável, geralmente devido ao problema do acoplamento e coesão. Benefícios Mantém encapsulamento pois objetos usam sua própria informação, favorecendo o baixo acoplamentobaixo acoplamento Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade, obtendo alta coesãoalta coesão Padrão Especialista (Expert)

39 Prof. Msc. Emerson Silas Dória39 Padrão Criador (Creator) Solução Atribuir à classe B a responsabilidade de criar uma instância da classe A se umas das seguintes condições forem verdadeiras: n B agrega instâncias de A (*) n B contém instâncias de A (*) n B registra instâncias de A n B usa bem de perto instâncias de A n B tem os dados de inicialização para criar instâncias de A (B portanto é um especialista na criação de A) n Problema Quem deve ser responsável por criar uma nova instância de alguma classe? (*) priorizar Algumas vezes um criador é encontrado ao observar a classe que tem os dados iniciais que serão passados na criação.

40 Prof. Msc. Emerson Silas Dória40 Exemplo Quem deve ser responsável por criar uma instância de ItemVenda? Pelo padrão, Venda deve ser responsável. Padrão Criador (Creator) Benefícios ( garante baixo acoplamento) :Venda criar_iv(quantidade) :ItemVenda 1:criar_iv(quantidade) Venda data hora criar_iv( ) obter_total( )

41 Prof. Msc. Emerson Silas Dória41 Padrão Baixo Acoplamento (Low Coupling) Solução Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo. Problema Como conseguir menor dependência (entre as classes) e maior reuso? Acoplamento Baixo: Não depende de outros elementos (classes) Alto: Depende de muitos outros elementos (classes) Tais classes podem ter os seguintes problemas: mudanças em classes relacionadas forçam mudanças locais; difíceis de compreender isoladamente; difíceis de serem reutilizadas.

42 Prof. Msc. Emerson Silas Dória42 Padrão Baixo Acoplamento (Low Coupling) :POST RegistrarPagamento( ) p:Pagamento 1:criar( ) :Venda 2:adicionar_pagamento (p) Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, poderia ser POST (uma vez que POST “registra” pagamentos no mundo real)

43 Prof. Msc. Emerson Silas Dória43 Uma solução melhor, do ponto de vista do padrão, que preserva baixo acoplamento é a própria Venda criar o Pagamento : Padrão Baixo Acoplamento (Low Coupling) :POST RegistrarPagamento( ) :Venda 1:RegistrarPagamento( ) :Pagamento 1.1:criar( )

44 Prof. Msc. Emerson Silas Dória44 Benefícios Responsabilidade não é (ou é pouco) afetada por mudanças em outros componentes. Responsabilidade é mais simples de entender isoladamente. Maior chance para reuso. Padrão Baixo Acoplamento (Low Coupling)

45 Prof. Msc. Emerson Silas Dória45 Padrão Alta Coesão (High Cohesion) Solução Atribuir uma responsabilidade de modo que a coesão permaneça alta. Problema Como manter a complexidade (das classes) sob controle? Em POO a Coesão Funcional mede o quanto as responsabilidades de um elemento são fortemente relacionadas. Coesão Alta: Um elemento com responsabilidades altamente relacionadas e que não executa um grande volume de trabalho. Baixa: Uma classe faz muitas coisas não relacionadas ou executa muitas tarefas (indesejável pois fica difícil de: compreender, reutilizar e manter; e são constantemente afetadas pelas mudanças)

46 Prof. Msc. Emerson Silas Dória46 Padrão Alta Coesão (High Cohesion) Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, seria POST. Mas se POST for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e sem coesão. :POST RealizarPagamento( ) :Venda adicionar_pagamento (p) p:Pagamento criar( )

47 Prof. Msc. Emerson Silas Dória47 Padrão Alta Coesão (High Cohesion) Exemplo Outra forma para atribuição da responsabilidade RealizarPagamento que favorece uma coesão mais alta :POST RealizarPagamento( ) :Venda :Pagamento RealizarPagamento( ) criar( )

48 Prof. Msc. Emerson Silas Dória48 Padrão Alta Coesão (High Cohesion) Níveis de coesão Muito baixa Um única classe é responsável por muitas coisas em áreas funcionais muito diferentes. Baixa Um classe é a única responsável por uma tarefa complexa em uma área funcional. Alta Um classe tem responsabilidades moderadas em uma área funcional e colabora com outras classes para realizar tarefas. Moderada Uma classe tem peso leve e responsabilidades exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não uma com a outra.

49 Prof. Msc. Emerson Silas Dória49 Padrão Alta Coesão (High Cohesion) Benefícios Aumento da clareza e compreensão do projeto Simplificação da manutenção Favorece baixo acoplamento Reuso facilitado

50 Prof. Msc. Emerson Silas Dória50 Princípios Básicos (Pressman,1995) Acoplamento “O acoplamento é uma medida da interconexão entre os módulos de uma estrutura de software, depende da complexidade de interface entre módulos”; Coesão “Um módulo coeso executa uma única tarefa dentro do procedimento de software, exigindo pouca interação com procedimentos executados em outras partes de um programa.”


Carregar ppt "Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1A)"

Apresentações semelhantes


Anúncios Google