UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva

Transcrição

1 UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva

2 Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades (entity), fronteiras (boundary) e controles (control). << boundary >> Tela de Venda << control >> Controlador de Venda << entity >> Venda

3 Categorização BCE Nessa categorização, os objetos são agrupados de acordo com o tipo de responsabilidade a eles atribuída. objetos de entidade: usualmente objetos do domínio do problema; objetos de fronteira: realizam a interface entre o sistema e os atores; objetos de controle: servem como intermediários entre objetos de fronteira e de entidade, definindo o comportamento de um caso de uso específico.

4 Objetos de Entidade Repositório para informações e as regras de negócio manipuladas pelo sistema. Representam conceitos do domínio do negócio. Características Normalmente armazenam informações persistentes. Várias instâncias da mesma entidade existindo no sistema. Participam de vários casos de uso e têm ciclo de vida longo. Frequentemente correspondem a entidades de banco de dados.

5 Objetos de Fronteira Realizam a comunicação do sistema com os atores. Traduzem os eventos gerados por um ator em eventos relevantes ao sistema eventos de sistema. Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator. Durante a análise de domínio, considera-se que as classes de fronteira surgem de cada par ator-caso de uso. Existem para que o sistema se comunique com o mundo exterior. Por consequência, são altamente dependentes do ambiente. Há dois tipos principais de objetos de fronteira: Os que se comunicam com o usuário (atores humanos): páginas HTML, interfaces gráfica desktop, etc. Os que se comunicam com atores não-humanos (outros sistemas ou dispositivos): protocolos de comunicação.

6 Objetos de Controle São a ponte de comunicação entre objetos de fronteira e objetos de entidade. Responsáveis por controlar a lógica de execução correspondente a um caso de uso. Decidem o que o sistema deve fazer quando um evento de sistema ocorre. Eles realizam o controle do processamento. Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um caso de uso. Traduzem eventos de sistema em operações que devem ser realizadas pelos demais objetos.

7 Importância da Categorização BCE A importância dessa categorização está relacionada à capacidade de adaptação a eventuais mudanças. Se cada objeto tem atribuições específicas dentro do sistema, mudanças podem ser menos complexas e mais localizadas. Uma modificação em uma parte do sistema tem menos possibilidades de resultar em mudanças em outras partes.

8 Projeto da Camada de Domínio O projeto da camada de domínio compõem-se, basicamente, de duas atividades: Definir os diagramas de interação, de acordo com os padrões conhecidos. Elaborar um diagrama de classes de projeto - DCP, o qual se baseia em primeiro lugar, no modelo conceitual. 8

9 Identificação de Responsabilidades Formas para atribuir responsabilidades às classes: partir dos blocos de interação que compõem o Diagrama de Visão Geral da Interação (DVGI); ou da descrição dos Casos de Uso, com seus possíveis cenários; ou ainda dos cartões CRC (Classes, Responsabilidades e Colaboradores). 9

10 Padrões GRASP Padrões de SW para atribuição de responsabilidade

11 Padrões GRASP GRASP: General Responsibility Assignment Software Patterns. Padrões de análise catalogados por Craig Larman. Indicam como atribuir responsabilidades a classes, da melhor forma possível. Úteis na construção de: diagramas de interações; (Sequencia, Colaboracao, VGI, Tempo) diagramas de classes.

12 Padrões GRASP Padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto. A ocasião para considerar a atribuição de responsabilidades as classes é durante a elaboração dos diagramas de sequência.

13 Padrões GRASP GRASP - General Responsibility Assignment Software Patterns (or Principles) - consiste em guias para atribuição de responsabilidades a classes e objetos em Projetos OO. Os diferentes padrões usados em GRASP são: - Information Expert - Polymorphism - Creator - Pure Fabrication - Controller - Indirection - Low Coupling - Protected Variations. - High Cohesion Todos esses padrões são respostas a alguns problemas de software, que na maioria dos casos são comuns a quase todo desenvolvedor. Essas técnicas não foram inventadas para criar novas maneiras de trabalho, mas para melhorar a documentação e padronizar princípios de programação OO já antigos e testados.

14 Alguns Padrões GRASP Creator Expert Low Coupling (Baixo Acoplamento) High Coesion (Alta Coesão) Controller

15 Creator Problema: quem deve ser o responsável por criar instâncias de uma determinada classe? Solução: um objeto deve ser criado por outro que o possua como parte (agregação/composição) ou esteja fortemente associado a ele. Para identificar o criador de um objeto A, verifique: se o objeto A é parte em um relacionamento todo/parte - normalmente o todo é o responsável pela criação de A; se algum outro objeto tem uma associação de um para muitos, onde A é o lado muitos; se o objeto A está associado ao objeto de controle; se alguma classe tem os dados necessários à inicialização de A.

16 Creator (exemplo) Quem deve criar objetos ItemVenda? Quem deve criar objetos Pagamento? Quem deve criar objetos Venda? descrito por : Registrador : Venda processaritemvenda(qtd) Criar(qtd) : ItemVenda

17 Creator É mais adequado escolher um criador que estará conectado ao objeto criado, de qualquer forma, depois da criação. Isso leva ao acoplamento baixo, já que o objeto criado deve normalmente ser visível ao criador. Exemplo de criador que possui os valores de inicialização Venda - Pagamento. Uma instância de Pagamento deve ser criada. A instância deve receber o total da venda. Quem tem essa informação? Venda. Venda é um bom candidato para criar objetos da classe Pagamento.

18 Expert É o padrão mais usado para atribuir responsabilidades. Problema: dado um comportamento (responsabilidade), a qual classe essa responsabilidade deve ser alocada? Solução: atribuir essa responsabilidade ao especialista da informação a classe que tem a informação necessária para satisfazer a responsabilidade.

19 Expert (exemplo) No Caso de uso registrar venda, foi identificada a responsabilidade de o sistema gerar o total de uma venda. Que classe deve assumir essa responsabilidade?

20 Expert (exemplo) Quem deve ser responsável por conhecer o total da venda? Venda -data: Date t = gettotal() :Venda + gettotal() Novo método

21 Expert (exemplo) Quem deve ser responsável por conhecer os subtotais da venda? Essa notação implica que nós iremos iteragir sobre todos os elementos da coleção t = gettotal() :Venda 1*: st = getsubtotal() ItensVenda[i] :ItemVenda Venda -data: Date + gettotal() ItemVenda - qtd + getsubtotal() Novo método

22 Expert (exemplo) Quem deve ser responsável por conhecer o preço de cada item de venda? t = gettotal() :Venda 1*: st = getsubtotal() ItensVenda[i] :ItemVenda 1.1 : p = getprice() :Produto Venda -data: Date + gettotal() ItemVenda - qtd + getsubtotal() Produto - descricao - preçounitario - ID + getpreço() Novo método

23 Expert Classe de Projeto Venda ItemVenda Produto Responsabilidade Conhece total de venda Conhece subtotal de item de venda Conhece preço do produto Benefícios: O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas. Isto normalmente leva a um baixo acoplamento entre as classes. O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter.

24 Expert Um aspecto importante a notar é que a atribuição de responsabilidades muitas vezes não tem correspondente no mundo real. Por exemplo, no mundo real, uma venda não calcula seu próprio total. Isso seria feito por uma pessoa (se não houvesse software). Mas no mundo OO: Entidades conceitos (como uma venda) podem ter responsabilidades. Personificação dos objetos: objetos estão vivos!

25 Low Coupling (Fraco Acoplamento) O acoplamento é uma medida de quão fortemente uma classe está conectada a outras classes, tem conhecimento das mesmas ou depende delas. Uma classe com baixo (fraco) acoplamento não depende de muitas outras. Uma classe com acoplamento forte é: mais difícil de compreender isoladamente; mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende); sensível a mudanças nas classes associadas.

26 Low Coupling (Acoplamento Fraco) Que configuração de classes é melhor? Por que?

27 Low Coupling (Acoplamento Fraco) Problema: Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização? Solução: Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.

28 Low Coupling (Acoplamento Fraco) Ponto Chave: O Especialista favorece o Baixo Acoplamento Retornando à motivação do especialista: ele nos conduz a soluções que favorecem o baixo acoplamento. O especialista nos pede que encontremos o objeto que tem a maior parte da informação necessária para assumir a responsabilidade (por exemplo,a classe Venda). Se pusermos a responsabilidade em algum outro lugar qualquer (por exemplo, em uma classe Camelo) o acoplamento global será maior porque mais informações terão de ser compartilhadas entre os objetos.

29 Low Coupling (Acoplamento Fraco) Suponha que temos de criar um objeto pagamento e associá-lo à venda. Que classe deve ser responsável por isso? fazerpgto( ) :Registrador 1 : criar( ) p : Pagamento 2 : adicionarpgto( p ) : Venda 1ª alternativa fazerpgto( ) :Registrador 1 : fazerpgto( ) : Venda 1.1 : criar( ) : Pagamento 2ª alternativa

30 Acoplamento entre classes a) A ClasseA tem um atributo do tipo ClasseB

31 Acoplamento entre classes b) A ClasseA tem um método que, de alguma forma, referencia uma instância de ClasseB. Tipicamente, esta referência se dá através de um parâmetro ou variável local do tipo ClasseB ou por um objeto do tipo ClasseB retornado pela chamada de algum método

32 Acoplamento entre classes c) A ClasseA é uma subclasse de ClasseB

33 Acoplamento entre classes d) A ClasseB é uma interface e a ClasseA implementa esta interface

34 Acoplamento entre classes Discussão: Classes que, por natureza, são genéricas e que têm alta probabilidade de reutilização deveriam ter acoplamento baixo O caso extremo do baixo acoplamento é o não acoplamento: contraria o princípio da orientação a objetos: objetos conectados, trocando mensagens entre si. O acoplamento alto não é o problema em si. O problema é o acoplamento a classes que, de alguma forma são instáveis: sua interface, sua implementação ou sua mera presença.

35 High Coesion (Alta Coesão) A coesão é uma medida do quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe. Uma classe com baixa coesão: faz muitas coisas não-relacionadas; executa trabalho demais. Classes não coesas são: difíceis de compreender; difíceis de reutilizar; difíceis de manter; sensíveis a mudanças. É extremamente importante assegurar que as responsabilidades atribuídas a cada classe sejam altamente relacionadas.

36 Controller Problema: quem deveria ser responsável por tratar um evento do sistema? Solução: atribuir a responsabilidade do tratamento de um evento do sistema a uma classe que representa uma das seguintes escolhas: Representa o sistema todo. Representa um tratador oficial de todos os eventos de sistema de um caso de uso (controlador de caso de uso).