Diagrama de Comunicação. SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa

Diagrama de Comunicação

1

SSC 526 – Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa

2

O que já foi visto até agora

Consultar Livro Emprestar Livro Devolver Livro Atendente Incluir Livro Bibliotecária Comprar Livro Leitor

Diagrama de Casos de Uso

Casos de Uso Completo Abstrato

C a s o d e U s o : E m p r e s t a r L iv r o A t o r P r i n c i p a l : A t e n d e n t e I n t e r e s s a d o s e I n t e r e s s e s : - A te n d e n te : d e s e j a r e g is tr a r q u e u m o u m a is liv r o s e s tã o e m p o s s e d e u m le i to r , p a r a c o n tr o la r s e a d e v o lu ç ã o s e r á f e ita n o te m p o d e te r m in a d o . - L e ito r : d e s e ja e m p r e s ta r u m o u m a is liv r o s , d e f o r m a r á p id a e s e g u r a . - B ib lio te c á r io : d e s e ja c o n t r o la r o u s o d o s liv r o s , p a r a q u e n ã o s e p e r c a m e p a r a q u e s e m p r e s e s a ib a c o m q u e le ito r e s tã o n o m o m e n to .

P r é - C o n d iç õ e s : O A te n d e n te é id e n tif ic a d o e a u t e n tic a d o .

G a r a n t ia d e S u c e s s o ( P ó s - C o n d iç õ e s ) : O s d a d o s d o n o v o e m p r é s tim o e s tã o a r m a z e n a d o s n o S is te m a . O s liv ro s e m p re s ta d o s p o s s u e m s ta tu s “ e m p re s ta d o ” C e n á r io d e S u c e s s o P r i n c ip a l : 1 . O L e ito r c h e g a a o b a lc ã o d e a te n d im e n to d a b ib lio te c a e d iz a o a te n d e n te q u e d e s e ja e m p r e s ta r u m o u m a is liv r o s d a b ib lio te c a . 2 . O A te n d e n te s e le c io n a a o p ç ã o p a r a r e a liz a r u m n o v o e m p r é s tim o . 3 . O A te n d e n te s o lic ita a o l e ito r s u a c a r te ir a d e id e n t if ic a ç ã o , s e ja d e e s tu d a n t e o u

p r o f e s s o r . 4 . O A te n d e n te in f o r m a a o s is te m a a id e n tif ic a ç ã o d o le ito r . 5 . O S is te m a e x ib e o n o m e d o l e ito r e s u a s itu a ç ã o . 6 . O A te n d e n te s o lic ita o s li v r o s a s e r e m e m p r e s ta d o s . 7 . P a r a c a d a u m d e le s , in f o r m a a o s is te m a o c ó d i g o d e id e n tif ic a ç ã o d o liv r o . 8 . O S is te m a in f o r m a a d a ta d e d e v o lu ç ã o d e c a d a liv r o . 9 . S e n e c e s s á r io , o A te n d e n te d e s b lo q u e ia o s liv r o s p a r a q u e p o s s a m s a ir d a b i b lio te c a . 1 0 . O L e ito r s a i c o m o s liv r o s . F lu x o s A lt e r n a t iv o s :

( 1 - 8 ) . A q u a lq u e r m o m e n to o L e ito r in f o r m a a o A te n d e n te q u e d e s is tiu d o e m p r é s tim o .

3 . O L e ito r in f o r m a a o A te n d e n te q u e e s q u e c e u a c a r t e i r a d e i d e n tif ic a ç ã o . 1 . O A te n d e n te f a z u m a b u s c a p e lo c a d a s tr o d o L e ito r e p e d e a e le a l g u m a in f o r m a ç ã o p e s s o a l p a r a g a r a n tir q u e e le é m e s m o q u e m d iz s e r . 4 . O L e ito r e s tá im p e d id o d e f a z e r e m p r é s tim o , p o r te r n ã o e s ta r a p to . 1 .C a n c e la r a o p e r a ç ã o . 7 a . O L iv r o n ã o p o d e s e r e m p r e s t a d o , p o is e s tá r e s e r v a d o p a r a o u tr o le it o r . 1 . O A te n d e n te in f o r m a a o L e ito r q u e n ã o p o d e r á e m p r e s ta r o liv r o e p e r g u n ta s e d e s e ja r e s e r v á - lo . 2 . C a n c e la r a o p e r a ç ã o ( s e f o r o ú n ic o liv r o ) 7 b . O L iv r o n ã o p o d e s e r e m p r e s ta d o , p o is é u m liv r o r e s e r v a d o s o m e n te p a r a c o n s u lta . 1 . C a n c e la r a o p e r a ç ã o ( s e f o r o ú n ic o liv r o )

3

O que já foi visto até agora

1. OLeitorchegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestarumoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionarumnovoempréstimo. 3. OAtendentesolicitaaoleitorsuacarteirinha,sejadeestudanteouprofessor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitoresuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles,informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. 9. OAtendentedesbloqueiaoslivrosparaquepossamsairdabiblioteca. 10.OLeitorsaicomoslivros.

Casos de Uso com substantivos e verbos sublinhados Atendente nome Leitor nome tipo : char 0..n 1..1 0..n 1..1 registra Empréstimo/Devolução data do empréstimo situação : Char 0..n 1..1 0..n 1..1 faz LinhaDoEmpréstimo data_prevista_dev olução data_entrega_real 1..n 1..1 1..n 1..1 _possui Bibliotecaria nome Reserva período situacao : char 0..n 1..1 0..n 1..1 ^ faz 0..1 0..1 0..1 0..1 corresponde a 0..1 0..1 0..1 0..1 corresponde a CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char 1..1 0..n 1..1 0..n < refere-se a Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char 0..n 1..1 _0..n 1..1 registra 1..1 0..n 1..1 0..n refere-se a > 0..n 1..1 0..n 1..1 possui Modelo Conceitual 1. OLeitorchegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestarumoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionarumnovoempréstimo. 3. OAtendentesolicitaaoleitorsuacarteirinha,sejadeestudanteouprofessor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitoresuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles,informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. Caso de Uso 1 Caso de Uso n

4

O que já foi visto até agora

Diagrama de Seqüência do Sistema (para cada caso de uso)

Modelo Conceitual +

Casos de Uso

:Atendente

:Atendente SistemaSistema

3: encerrarEmpréstimo() 1: iniciarEmpréstimo(id_Leitor)

2: emprestarLivro(id_Livro)

* mais livros a emprestar

5

O que já foi visto até agora

Diagrama de Seqüência do Sistema (para cada caso de uso)

:Atendente

:Atendente SistemaSistema

3: encerrarEmpréstimo() 1: iniciarEmpréstimo(id_Leitor) 2: emprestarLivro(id_Livro) * mais livros a emprestar Contrato da Operação (para cada operação) Operação: encerrarEmpréstimo()

Referências Cruzadas: Caso de uso: “Emprestar Livro”

Pré-Condições: Um leitor apto a emprestar livros já foi identificado; pelo menos um livro já foi identificado e está disponível para ser emprestado.

Pós-Condições: um novo empréstimo foi registrado; o novo empréstimo foi relacionado ao leitor já identificado na operação “iniciar o empréstimo”; a situação dos livros emprestados foi alterada para “emprestado”.

Conclusão da Fase de Análise

• A fase de análise enfatiza uma compreensão dos requisitos do sistema

• “Fazer a Coisa Certa” – compreender objetivos, conceitos e

características do domínio do problema

• Artefatos estudados:

6

Artefato da Análise

Casos de Uso

Modelo Conceitual

Diagramas de Sequência do Sistema

Questões respondidas

Quais são os processos do domínio? Quais são os conceitos (objetos)? Quais são os eventos e operações?

Início da fase Projetar

• Nessa fase, é desenvolvida uma solução lógica baseada no paradigma de orientação a objetos – objetos, mensagens, classes, métodos, ….

• “Fazer Certo a Coisa” – projetar de maneira competente

uma solução que satisfaça os requisitos

• Os dois artefatos principais a serem desenvolvidos são:

• Diagramas de Interação

• Diagramas de Classe de Projeto

Diagramas de Interação

• Diagramas de Interação – apresentam como os objetos interagem, por meio de mensagens, para responder a um determinado evento

• são importantes para o desenvolvimento de um bom

projeto

• exigem criatividade

• A UML fornece dois tipos de diagramas de interação que permitem representar interação (colaboração) entre classes (ou objetos):

• diagramas de comunicação – formato de grafo

9 mensagem1() :Instância da Classe A :Instância da Classe B 1:mensagem2() 2:mensagem3()

Diagrama de Comunicação

 Os diagramas de comunicação têm melhor

capacidade de expressar informações contextuais e podem ser mais econômicos em termos de espaço

10 mensagem1() 1:mensagem2() 2:mensagem3()

Diagrama de Sequência

:instância de Classe A :instância de Classe B :instância de Classe C 3:mensagem4()

Diagramas de Comunicação

• Diagrama de Comunicação - um dos artefatos mais importantes criados no projeto OO

• o tempo gasto na sua criação deveria absorver um

percentual de tempo significativo do tempo gasto no projeto

• Elaborar diagramas de comunicação exige conhecimento de:

• princípios de atribuição de responsabilidades

• padrões de projeto

Classes e Instâncias

12 Venda Classe :Venda Instância venda1:Venda Instância nomeada

Mensagens

• Sintaxe UML:

retorno := mensagem ( parâmetro : tipoParâmetro ) : tipoRetorno

• O retorno pode não existir

• Os tipos podem ser omitidos ser forem óbvios ou não forem importantes • Exemplo:

especificacao := obterEspecificacaoProduto(id)‏

especificacao := obterEspecificacaoProduto(id:IdItem)‏

especificacao := obterEspecificacaoProduto(id:IdItem) : EspecificacaoProduto

Mensagens

• No paradigma de orientação a objetos:

• Mensagem é o mecanismo de comunicação entre objetos

• invoca as operações desejadas

• “O processo de invocar um método é chamado de envio de uma

mensagem ao objeto”

• Ex: quando uma mensagem façaAlgo() é enviada a uma

objeto obj, o método façaAlgo() definido na classe de obj é

executado:

obj.façaAlgo()‏

Ligações

15

 Ligação: conexão em dois objeto que indica a

possibilidade de alguma forma de navegação ou de visibilidade entre eles

 permite que mensagens fluam de um objeto para outro total:=totalizarVenda():float :Venda :TPV --- --- :Venda.totalizarVenda()‏ ---

Mensagens Múltiplas

• Várias mensagens, em ambos os sentidos, podem fluir ao

longo de uma mesma ligação

• usar seta para indicar direção da mensagem

• usar números de sequência para indicar ordem de execução das mensagens 16 1:mensagem1() 2:mensagem2() 3:mensagem3() :Instância Classe A :Instância Classe B 4:mensagem4()‏

Exemplo

17 acionar()‏ :BotãoElevador :ControladorElevador 1:atualizar( )‏ 2:iluminar( )‏

Primeira Mensagem

• A primeira mensagem é aquela enviada ao objeto que inicia o tratamento a um determinado evento

• O emissor da primeira mensagem não é identificado

18 1:mensagem1() 2:mensagem2() 3:mensagem3() _:Instância Classe B 4:mensagem4()‏ primeiraMsg()‏ :Instância Classe A --- --- :InstÂnciaClasseA.primeiraMsg()‏ --- --- em algum lug ar no sis tema…

Exemplo

19 1:ok :=posicionarAngulo(angulo):Booleano :Flape Aterrissar()‏ :Aeronave

Número de Sequência da Mensagem

• Primeira mensagem  não é numerada

• Numeração formal e agregada indica a ordem e o

aninhamento das mensagens

20 :ClasseA :ClasseB :ClasseC msg1() 1:msg2() 1.1:msg3() aninhamento de mensagens

Aninhamento de Mensagens

21 :ClasseA :ClasseB :ClasseC msg1() 1:msg2() 1.1:msg3() msg1()‏ --- --- :ClasseB.msg2()‏ --- --- msg2()‏ --- --- :ClasseC.msg3()‏ --- ---

Aninhamento de Mensagens –

Exemplo

22 :ClasseA :ClasseB :ClasseC :ClasseD msg1() 1:msg2() 1.1:msg3() 2.1:msg5() 2:msg4() 2.2:msg6()

Aninhamento de Mensagens – Exemplo

(cont.)‏ 23 msg1()‏ --- --- :ClasseB.msg2()‏ --- --- :ClasseC.msg4()‏ --- --- msg2()‏ --- --- :ClasseC.msg3()‏ --- --- msg4()‏ --- --- :ClasseB.msg5()‏ --- --- :ClasseD.msg6()‏ --- --- em algum lugar no sistema… :ClasseA.msg1()‏

Auto-Mensagem (this)

24 :TPV 1: iniciar() :ClasseA 1: msg2()‏ msg1()‏ iniciarSistema()‏

Iteração

25 msg1() 1*:[i:=1..10]msg2()‏ 2*:[i:=1..10]msg3()‏ :ClasseA :ClasseB :ClasseC --- --- for i=1 to 10 { :ClasseB.msg2()‏ :ClasseC.msg3()‏ } --- --- msg1()‏

Iteração

26 :TPV :Venda 1 * : linha:=proxLinhaItem():LinhaItemVenda Cláusula de Iteração ([i:=1..10]) é opcional msg1()

Criação de Instância

27

:TPV :Venda

1:criar(caixa)

iniciarVenda()

 Uma mensagem pode ser usada para criar uma

instância

 nomear mensagem como criar()

mensagem criar(), com parâmetros opcionais,

normalmente é interpretada, na implementação, como chamada

a um construtor da classe de software

Mensagens Condicionais

28

:ClasseA :ClasseB

1: [condição] msg2()

msg1()

 Uma mensagem condicional só será enviada se a

cláusula entre [ ] tiver valor true

--- --- if (condicao = true) { :ClasseB.msg2()‏ } --- --- msg1()‏

Mensagens Condicionais

29

:TPV :Venda

1: [nova venda] criar()

30

Caminhos Condicionais

Mutuamente Exclusivos

:ClasseA :ClasseB :ClasseC msg1() 1a: [condição] msg2() 1b:[not condição] msg3()

 Apenas uma ou outra

mensagem é enviada

dependendo da condição ser verdadeira ou falsa --- --- if (condicao = true) :ClasseB.msg2()‏ else :ClasseC.msg3()‏ --- --- msg1()‏

31 1a.1:msg3()

Caminhos Condicionais

Mutuamente Exclusivos

:ClasseA :ClasseB :ClasseC msg1() 1a: [condição] msg2() 1b:[not condição] msg4() :ClasseD :ClasseE 1b.1:msg5() 2:msg6()

Multiobjetos

• Um multiobjeto é uma coleção de instâncias, representada por um único ícone

• Uma mensagem pode ser enviada ao multiobjeto ou a cada membro da coleção

Mensagens para Multiobjetos

33 1: qt:=obterQuantidade( ) : Int :Venda msg1() ItemLinhaVenda mensagem enviada à coleção * :Venda 1*: id:=obterID( ) msg1() ItemLinhaVenda mensagem enviada a cada membro da coleção

34

Exemplo TPV - DSS

:Sistema :Caixa Comprar Itens entrarItem(CUP, quantidade) terminarVenda() fazerPagamento(quantia)‏ troco, recibo descrição item, total iniciarNovaVenda( )

Exemplo TPV – Modelo

Conceitual

35 1..1 Pagamento quantia 1..1 1..1 TPV Venda data hora Paga-por 1..1 Capturada-em

Exemplo TPV – Diagrama de

Comunicação

36 1:fazerPagamento(quantia)‏ :Venda :TPV :Pagamento 1.1:criar(quantia)‏ fazerPagamento(quantia)‏

Portanto

• É importante ser consistente ao sublinhar os nomes de instância quando realmente se deseja uma instância; caso contrário,

mensagens para instâncias versus mensagens para classes podem ser interpretadas incorretamente.

38 tot:=total() 2: st:=subtotal() liv:LinhadeItem deVenda prodEspec: Especifi caçãodeProduto :Venda 2.1:pr:=preço

Exemplo de Diagrama de Comunicação: Calcular o total da compra

1*:[para cada]liv:=prox() :LinhadeItemdeVenda subtotal() { return quantidade*prodSpec.preço() } total() { tot:=0

para cada linha de item de venda liv

tot:= tot + liv.subtotal() }

GRASP: Padrões para

Atribuição de

Responsabilidades

Responsabilidade

• Responsabilidade

• um contrato ou obrigação de um tipo ou classe

• serviços fornecidos por um elemento (classe ou subsistema)‏

• incorpora os objetivos de um elemento

• Dois tipos de responsabilidades básicas:

• Fazer

• fazer algo (criar um objeto, executar uma operação,…)‏

• iniciar ações em outros objetos

• coordenar e controlar atividades em outros objetos

• Saber

• conhecer dados privados encapsulados

• conhecer objetos relacionados

• conhecer coisas que podem ser derivadas ou calculadas

Responsabilidade

• Exemplos:

• “uma Venda é responsável por criar ItemLinhaVenda ” –

FAZER

• “uma Venda é responsável por conhecer o seu total”-

SABER

• OBS: responsabilidades do tipo saber

frequentemente podem ser deduzidas do modelo conceitual (atributos e associações)‏

Responsabilidades e Diagramas

de Comunicação

• Diagramas de comunicação mostram escolhas de atribuição de responsabilidade a objetos

• Exemplo: atribuir aos objetos do tipo Venda a responsabilidade de imprimirem a si próprios.

42 :Venda imprimir() Responsabilidade de imprimir a si própria

Responsabilidade

• A “tradução” de responsabilidade em classes e métodos é influenciada pela granularidade da responsabilidade. Ex:

• “Fornecer acesso a bancos de dados relacionais” – pode

envolver muitas classes e métodos

• “Imprimir uma venda” – pode envolver apenas um ou

alguns poucos métodos

• Os métodos são implementados para satisfazer uma responsabilidade

• Um objeto pode colaborar com outros objetos para

Exemplo

44 fazerPagamento(quantia)‏ :Venda :Pagamento 1:criar(quantia)‏

Responsabilidade “Fazer Pagamento”  atribuída ao objeto Venda

 colaboração entre Venda e

Padrões

• Desenvolvedores de software experientes criaram um

repertório de princípios gerais e boas soluções para guiar a construção de softwares

• Essas soluções foram descritas em um formato padronizado (nome, problema, solução) e podem ser usadas em outros contextos

• Padrões usualmente não contêm novas ideias

• organizam conhecimentos e princípios existentes, testados e

consagrados

• Padrão é uma descrição nomeada de um problema e uma

Padrões GRASP

• GRASP = General Responsibility Assignment Software Patterns

• Descrevem princípios fundamentais de atribuição de responsabilidade a objetos

• Principais padrões GRASP:

• Especialista (Expert)‏

• Criador (Creator)‏

• Coesão alta (High Cohesion)‏

• Acoplamento fraco (Low Coupling)‏

Especialista

• Problema: qual é o princípio mais básico de atribuição de responsabilidades a objetos ?

• Solução: Atribuir responsabilidade ao especialista da informação.

• Exemplo: no sistema TPV, alguma classe precisa conhecer o total geral de uma venda

Exemplo

• Venda  conhece o total da venda

• ItemLinhaVenda  conhece o subtotal da linha

• EspecificaçãoProduto  conhece o preço do produto.

1.1: p:=obterPreço( )‏ t:=obterTotal( )‏ :Venda :Especificaçãode Produto :LinhadeItemdeVenda * 1*: st:=obterSubtotal( )‏

Especialista

• Discussão

– É o padrão mais utilizado – “Fazê-lo eu mesmo”

• objetos fazem coisas relacionadas à informação que têm

– Lembrar que existem especialistas parciais que colaboram numa tarefa

• informação espalhada  comunicação via

mensagens

– Tem uma analogia no mundo real

Especialista

• Benefícios:

– Mantém encapsulamento  favorece o acoplamento

fraco

– O comportamento fica distribuído entre as classes que

têm a informação necessária (classes “leves”) 

favorece alta coesão

• Contra-indicações

– contra indicado quando aumenta acoplamento e reduz coesão

– Ex: quem é responsável por salvar uma Venda no banco de dados?

Criador

• Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe ?

• Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira:

• B agrega/contém/registra objetos de A

• B usa objetos de A

• B tem os valores iniciais que serão passados para objetos de

A, quando de sua criação

Criador

• Exemplo: No sistema TPV, quem é responsável pela

criação de uma instância de ItemLinhaVenda ?

53

1:criar(quantidade)‏ :Venda

criarItemLinha (quantidade)‏

:ItemLinhaVenda  Venda contém vários

Criador

• Discussão

– objetivo do padrão: definir como criador o objeto que precise ser conectado ao objeto criado em algum

evento

• escolha adequada favorece acoplamento fraco

– objetos agregados, contêineres e registradores são bons candidatos à responsabilidade de criar outros objetos

– algumas vezes o candidato a criador é o objeto que conhece os dados iniciais do objeto a ser criado

• Ex: Venda e Pagamento

Exemplo

55 fazerPagamento(quantia)‏ :Venda :Pagamento 1:criar(quantia)‏

 Venda possui dados iniciais do pagamento

Criador

• Benefícios

– favorece o acoplamento fraco

• provavelmente o acoplamento não é aumentado porque o objeto criado provavelmente já é visível para o objeto criador, devido às associações

existentes que motivaram sua escolha como criador

Acoplamento

• Acoplamento: dependência entre elementos (classes, subsistemas,…), normalmente resultante de

comunicação para atender a uma responsabilidade

• O acoplamento mede o quanto um objeto está

conectado a, tem conhecimento de ou depende de outros objetos

• acoplamento fraco (ou baixo) – um objeto não depende de

muitos outros

• acoplamento forte (ou alto) – um objeto depende de

muitos outros

Acoplamento

• Problemas do acoplamento alto:

• mudanças em classes interdependentes forçam mudanças

locais

• dificulta a compreensão do objetivo de cada classe

• dificulta reutilização

Acoplamento Fraco

• Problema: como favorecer a baixa dependência e aumentar a reutilização ?

• Solução: Atribuir responsabilidade de maneira que o acoplamento permaneça baixo.

• Exemplo: No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa?

fazerPagamento( )‏ 1: criar( )‏ 2 : adicionarPagamento(p)‏ p:Pagamento :Venda :TPV

Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV

fazerPagamento( )‏

1: fazer Pagamento( )‏

:Pagamento :Venda :TPV

Projeto 2: alternativa – responsabilidade atribuída à Venda

Qual projeto é melhor?

• Qual dos projetos anteriores favorece o acoplamento fraco?

• em ambos os casos, Venda será acoplada a (terá conhecimento de)

Pagamento

• projeto 1 – acoplamento entre Pagamento e TPV

• projeto 2 – não aumenta acoplamento

61 PREFERÍVEL

Formas de Acoplamento

• Um objeto tem um atributo que referencia um objeto de outra classe

• Um objeto tem um método que referencia um objeto de outra classe

• parâmetro, variável local ou retorno

• Um objeto invoca os serviços de um objeto de outra classe

• Uma classe é subclasse de outra, direta ou indiretamente

Acoplamento Fraco

• Discussão:

– Acoplamento fraco  classes mais independentes

• reduz impacto de mudanças • favorece reúso de classes

– Considerado em conjunto com outros padrões – Extremo de acoplamento fraco não é desejável

• fere princípios da tecnologia de objetos – comunicação por mensagens

• projeto pobre: objetos inchados e complexos, responsáveis

Acoplamento Fraco

• Discussão:

– dica: concentre-se em reduzir o acoplamento em

pontos de evolução ou de alta instabilidade do sistema

• ex: cálculo de impostos terceirizados no sistema TPV

• Benefícios:

– classe são pouco afetadas por mudanças em outras partes

– classes são simples de entender isoladamente – conveniente para reutilização

Coesão

• Coesão mede o quanto as responsabilidades de um elemento

(classe, objeto, subsistema,…) são fortemente focalizadas e relacionadas

• Objeto com Coesão Alta  objeto cujas responsabilidades são

altamente relacionadas e que não executa um volume muito grande de trabalho

• Objeto com Coesão Baixa  objeto que faz muitas coisas não

relacionadas ou executa muitas tarefas

• difícil de compreender, reutilizar e manter

• constantemente afetadas por mudanças

Coesão

Alta

• Problema: Como manter a complexidade sob controle?

• Solução: Atribuir responsabilidade de tal forma que a coesão permaneça alta.

• Exemplo (o mesmo para o acoplamento fraco): No sistema TPV, suponha que queremos criar uma

instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa?

fazerPagamento( )‏ 1: criar( )‏ 2 : adicionarPagamento(p)‏ p:Pagamento :Venda :TPV

Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV

O TPV toma parte na responsabilidade de fazer pagamento. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvessem 50 mensagens recebidas por TPV?

Projeto 2: alternativa – responsabilidade atribuída à Venda

Esta solução favorece uma coesão mais alta em TPV e também um acoplamento mais fraco. Portanto, projeto 2 é preferível.

fazerPagamento( )‏ 1: fazer Pagamento( )‏ :Pagamento :Venda :TPV 1.1: criar( )‏

Coesão

Alta

• Discussão:

• Coesão alta, assim como Acoplamento Fraco, são princípios

que devem ser considerados no projeto de objetos • má coesão traz acoplamento ruim e vice-versa

• regra prática: classe com coesão alta tem um número

relativamente pequeno de métodos, com funcionalidades relacionadas, e não executa muito trabalho

• analogia com mundo real

• ex: pessoas que assume muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes

Coesão

Alta

• Benefícios

• mais clareza e facilidade de compreensão no projeto

• simplificação de manutenção e acréscimo de funcionalidade/melhorias

• favorecimento do acoplamento fraco

• aumento no potencial de reutilização

• classe altamente coesa pode ser usada para uma finalidade bastante específica

Controlador

• Problema: Quem deve ser responsável por tratar um evento do sistema ?

• Solução: A responsabilidade de receber ou tratar as mensagens de eventos (operações) do sistema pode ser atribuída a uma classe que:

• represente todo o sistema, um dispositivo ou um

subsistema – chamado de controlador fachada - OU

• represente um cenário de um caso de uso dentro do qual

ocorra o evento

• TratadorDe<NomeDoCasoDeUso>, ControladorDe<NomeDoCasoDeUso>

Controlador

• Exemplo: quem vai tratar os eventos do sistema TPV?

72 :Caixa :Sistema Comprar Itens terminarVenda() fazerPagamento(quantia) troco, recibo entrarItem(CUP, quantidade)

descrição item, total iniciarNovaVenda( )

ID Item Quantidade Entrar Item :Caixa :CWindow :???? Camada de Interface Camada do Domínio entrarItem(itemId, quantidade)‏ açãoExecutada(eventoDaAção)‏

Exemplo: Opções de

Controlador

• todo o sistema (controlador fachada): TPV 74 :TPV entrarItem(…) :ControladorDe ComprarItem entrarItem(…)

 um tratador artificial do caso de

Discussão: Controladores

Fachada

• Um controlador fachada deve ser um objeto (do domínio) que

sugira uma cobertura sobre outras camadas e que seja o ponto principal para as chamadas provenientes da interface com o usuário ou de outros sistemas

• pode ser uma abstração de uma entidade física – ex: TPV

• pode ser um conceito que represente o sistema – ex: sistemaTPV

• São adequados quando não há uma quantidade muito grande

de eventos de sistema

• Não é possível redirecionar mensagens do sistema para

controladores alternativos (ex: outros subsistemas )‏

Discussão :Controladores de

Casos de Uso

• Deve existir um controlador diferente para cada caso de uso

• Não é um objeto do domínio, e sim uma construção artificial para dar suporte ao sistema. Ex: ControladorDeComprarItem,

ControladorDeDevolução

• Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coesão (controlador inchado por excesso de responsabilidade)

• É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos.

Controladores inchados

• Classe controladora mal projetada - inchada

• coesão baixa – falta de foco e tratamentos de muitas responsabilidades

• Sinais de inchaço:

• uma única classe controladora tratando todos os eventos, que são muitos. Comum com controladores fachada

• o próprio controlador executa as tarefas necessárias para atender o evento, sem delegar para outras classes (coesão alta, não especialista)‏

• controlador tem muitos atributos e mantém informação significativa sobre o domínio, ou duplica informações existentes em outros lugares

Controlador

• Curas para controladores inchados

• acrescentar mais controladores – misturar controladores fachada e de casos de uso

• delegar responsabilidades

• Corolário: objetos de interface (como objetos “janela”) e da camada de apresentação não devem ter a responsabilidade de tratar

eventos do sistema

Controlador

• Benefícios:

• aumento das possibilidades de reutilização de classes e do uso de interfaces “plugáveis”.

• conhecimento do estado do caso de uso – controlador pode armazenar estado do caso de uso, garantindo a sequência correta de execução de operações

ID Item Quantidade Entrar Item :Caixa :CWindow :TPV Camada de Interface Camada do Domínio entrarItem(itemId, quantidade)‏ açãoExecutada(eventoDaAção)‏ :Venda

http://www.schrankmonster.de/2006/06/12/i

Exemplo: Acoplamento

• Apache syscall graph

http://www.schrankmonster.de/2006/06/12/i

Exemplo: Acoplamento

• IIS6 syscal graph