UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCINCIAS, LETRAS E CINCIAS EXATAS DEPARTAMENTO DE CINCIAS DE COMPUTAO E ESTATSTICA

Projeto e Desenvolvimento de Sistemas de Informao

Diagramas de Colaborao e Padres GRASP

O que vimos at agora

Diagramas de Caso de Uso Casos de uso no formato completo (resumido e essencial) Modelo Conceitual Diagramas de Sequncia do Sistema Contratos de Operaes Notao dos Diagramas de Comunicao

Reserva

0..n 0..n
^ faz

perodo situacao : char

0..1
corresponde a

corresponde a

0..1 0..1
faz Emprstimo/Devoluo data do emprstimo 0..n situao : Char

1..1
Atendente nome

1..1
registra

0..n

Leitor nome tipo : char

1..1

1..1

possui

refere-se a >

1..1

Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char

1..n

0..1

Bibliotecaria nome

1..1
registra

LinhaDoEmprstimo data_prevista_dev oluo data_entrega_real

0..n

0..n
< refere-se a

1..1
possui

Objetivo ao final da fase de projeto

CopiaDoLivro nro sequencial 1..1 situacao : char liberadoParaEmprestimo : char

0..n

Leitor nome tipo calcularDataDevolucao( ) 1

faz

0..*

Emprestimo data_do_emprestimo situacao : char adicionarCopia( ) devolverCopia( ) 1

Mais a especificao das interfaces

LinhaDoEmprestimo data_prevista_devoluo data_entrega_real codCopia( ) atualizarDataDev( )

possui

1..*
refere-se a

CopiaDoLivro nro_sequencial situacao : char liberadoParaEmprestimo : char mudarSituacao( ) codCopia( ) sinalizarDevolucao( )

0..*

Como projetar as responsabilidades de cada objeto

Sabemos que os objetos precisam se comunicar para completar as operaes. Os Diagramas de comunicao/colaborao mostram escolhas de atribuies de responsabilidades a objetos. Mas quem o melhor candidato para realizar cada uma das operaes ou mtodos do sistema?

Como projetar as responsabilidades de cada objeto

Responsabilidade:
Um contrato ou obrigao de um tipo ou uma classe(Booch e Rumbaugh) Responsabilidades esto relacionadas s obrigaes de um objeto em termos de seu comportamento.

Dois tipos de responsabilidades bsicas:

Fazer
Fazer algo (criar um objeto, executar uma operao, ...) Iniciar aes em outros objetos(delegao). Controlar e coordenar atividades em outros objetos.

Conhecer
Conhecer dados privados encapsulados. Conhecer objetos relacionados. Conhecer dados/atributos que podem ser derivados ou calculados.

Responsabilidades e Diagramas de Interao

Diagramas de interao mostram escolhas de atribuio de responsabilidade a objetos. Exemplo: atribuir aos objetos do tipo Venda a responsabilidade de imprimirem a si prprios.
imprimir() :Venda

Responsabilidade de imprimir a si prpria

Exemplo: Motivao para aplicao de Padres

Diagrama de Comunicao para a operao EmprestarFita(fcodigo)

Implementao inchada ou concentradora X Implementao leve, distribuda

Sistema Videolocadora
Cod Cpia Fita

Emprestar

:Atendente
aoExecutada(eventoDaAo)

Camada de Interface

:CWindow
emprestarFita(fcodigo)

Camada do Domnio :????

Modelo Conceitual Sistema Videolocadora

Videolocadora

possui

possui

10

Colaborao entre os objetos

2: emprestimoCorrente := getEmprestimoCorrente emprestarFita(fCodigo)----> :Videolocadora clienteCorrente: Cliente

3: criar() 1: fita:=get(fCodigo) 5: associarItem(item) 4: associarFita(fita)

fitas: Fita emprestimoCorrente: Emprestimo

item: ItemDeEmprestimo

Qual o problema desta soluo?

Pseudo-cdigo Concentrador VideoLocadora

Classe VideoLocadora
fitas: Conjunto; clienteCorrente: Cliente

Mtodo emprestarFita(fCodigo: String)

fita:Fita; emprestimoCorrente: Emprestimo; item: ItemDeEmprestimo; fita := fitas.get(fCodigo); emprestimoCorrente := clienteCorrente.getEmprestimoCorrente(); item := itemDeEmprestimo.new(); Item.associarFita(fita); EmprestimoCorrente.associarItem(item); Fim Mtodo; FIM Classe;

Colaborao entre objetos (concentrador)

2: emprestimoCorrente := getEmprestimoCorrente emprestarFita(fCodigo)----> :Videolocadora clienteCorrente: Cliente

3: criar() 1: fita:=get(fCodigo) 5: associarItem(item) 4: associarFita(fita)

fitas: Fita emprestimoCorrente: Emprestimo

item: ItemDeEmprestimo

Diagrama de Colaborao no Concentrador

emprestarFita(fCodigo)----> :Videolocadora 5: associarItem() emprestimoCorrente: Emprestimo 1: fita:=get(fCodigo) 2: emprestar(fita) 4: criar() fitas: Fita 3: adicionar(fita) 6: associarFita(fita) clienteCorrente: Cliente item: ItemDeEmprestimo

Cdigo com Responsabilidade Distribuda

Classe VideoLocadora fitas: Conjunto; clienteCorrente: Cliente;
Metodo emprestarFita(fCodigo:string)

Classe Emprestimo Itens:Conjunto; Metodo adicionar(fita:Fita); item: ItemDeEmprestimo; item := ItemDeEmprestimo.new(); self.associaItem(item); item.associaFita(fita); Fim Metodo; Fim Classe;

fita:Fita; fita:=fitas.get(tCodigo); clienteCorrente.empresta(fita) Fim Metodo; Fim Classe; Classe Cliente emprestimoCorrente: Empretimo; Mtodo emprestar(fita:Fita); emprestimoCorrente.adiciona(fita); Fim Mtodo; Fim Classe;

Discusso
Qual dos cdigos mais fcil de entender e manter? Em qual dos cdigos as responsabilidades das classes parecem mais intuitivas? Para desenvolver um bom projeto, precisamos de princpios para nos guiar na atribuio de responsabilidades -> padres de projeto OO.

Responsabilidade
Responsabilidade no a mesma coisa que um mtodo.
Mtodos so implementados para satisfazer as responsabilidades

Responsabilidades so implementadas usando mtodos que agem sozinhos ou colaboram com outros mtodos e objetos. Padres de projeto so princpios para guiar a atribuio de responsabilidades aos objetos.

Padres
Desenvolvedores experientes em OO criaram um repertrio de princpios gerais e boas solues para guiar a construo de software. Essas solues foram descritas em um formato padronizado (nome, problema, soluo) e podem ser usadas em outros contextos(outros projetos). Surgiram com base no trabalho do arquiteto Christopher Alexander, 1977. (Padres Arquitetnicos). Ganharam impulso aps a publicao do livro sobre Padres de Projeto (Design Patterns Gamma e outros GoF- 1994)

Padres
Padres usualmente no contm novas idias
Organizam conhecimentos e princpios existentes, testados e consagrados.

Padro uma descrio nomeada de um problema e uma soluo, que pode ser aplicado em novos contextos. Nomear padres melhora a comunicao (criase um vocabulrio, ou idioma)

Padres GRASP
GRASP = General Responsability Assignment Software Patterns. Descrevem princpios fundamentais de atribuio de responsabilidades a objetos. A compreenso dos padres de projeto durante a criao de diagramas de comunicao importante, pois:
So princpios de bons projetos Orientado a Objetos. Levam a projetos OO de qualidade.

Padres GRASP
Alguns padres GRASP principais:
Especialista (Expert) Criador (Creator) Coeso alta (High Cohesion) Acoplamento fraco (Low Coupling) Controlador (Controller)

Esses padres abordam questes bsicas comuns e tpicos fundamentais de desenvolvimento.

O padro Especialista (Expert)

Problema: qual o princpio mais bsico para atribuir responsabilidades em projeto orientado a objetos? Soluo: Atribuir responsabilidade ao especialista da informao a classe que tem a informao necessria para satisfazer a responsabilidade.

Exemplo
No sistema biblioteca, quem seria o responsvel por calcular a data de devoluo de um livro?

Modelo Conceitual Biblioteca

0..n 0..n
^ faz

Reserva perodo situacao : char

0..1
corresponde a

corresponde a

0..1 0..1
faz Emprstimo/Devoluo

1
Atendente nome

1
registra

0..n

Leitor nome tipo : char

0..n
Livro

data do emprstimo situao : Char

possui

refere-se a >

Bibliotecaria nome

1
registra

0..n

titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char

1..n

0..1

LinhaDoEmprstimo data_prevista_devoluo data_entrega_real

0..n
< refere-se a

1
possui CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char

0..n

Especialista
A data de devoluo ficar armazenada no atributo data_prevista_devoluo do objeto LinhaDoEmprestimo Mas quem possui conhecimento necessrio para calcul-la?

Modelo Conceitual Biblioteca

0..n 0..n
^ faz

Reserva perodo situacao : char

0..1
corresponde a

corresponde a

0..1 0..1
faz Emprstimo/Devoluo

1
Atendente nome

1
registra

0..n

Leitor nome tipo : char

0..n
Livro

data do emprstimo situao : Char

possui

refere-se a >

Bibliotecaria nome

1
registra

0..n

titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char

1..n

0..1

LinhaDoEmprstimo data_prevista_devoluo data_entrega_real

0..n
< refere-se a

1
possui CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char

0..n

Especialista
Pelo padro especialista, Leitor deve receber essa atribuio, pois conhece o tipo de Leitor (por exemplo, aluno de graduao, aluno de ps-graduao, professor, etc), que utilizado para calcular a data em que o livro deve ser devolvido.

Especialista
adicionarCopia(copiaLivro)---> : Emprestimo

1: d:=calcularDataDevoluo()

2: criar(d, copiaLivro)

:Leitor

Uso do padro Especialista

linh: LinhaDoEmprestimo

Especialista: alternativa mais detalhada

adicionarCopia(CopiaLivro)

4: associarLinha(linh) adicionarCopia(copiaLivro)---> : Emprestimo 2: criar(d) 1: d:=calcularDataDevoluo() :Leitor 3: associarCopia(copiaLivro) copiaLivro: CopiaDoLivro

linh: LinhaDoEmprestimo

Uso do padro Especialista

Especialista
Onde procurar pela classe especialista?
Comear pelas classes j estabelecidas durante o projeto. Se no encontrar, utilizar o Modelo Conceitual.

Lembrar que existem especialistas parciais que colaboram numa tarefa

Informao espalhada -> comunicao via mensagens

Existe uma analogia no mundo real.

Especialista
Discusso
o padro mais utilizado Tem uma analogia no mundo real Coad: Faz-lo eu mesmo Lembrar que existem especialistas parciais

Benefcios:
Mantm encapsulamento -> favorece o acoplamento fraco. O Comportamento fica distribudo entre as classes que tem a informao necessria (classes leves) -> favorece alta coeso. Favorece o reuso.

Contra-indicaes
contra indicado quando aumenta acoplamento e reduz coeso Ex: quem responsvel por salvar um Emprstimo no banco de dados?

Padro Criador (Creator)

Problema: Quem deveria ser responsvel pela criao de uma nova instncia de alguma classe? Soluo: atribua classe B a responsabilidade de criar uma nova instncia da classe A se uma das seguintes condies for verdadeira: B agrega objetos de A B contm objetos de A B registra instncias de objetos de A B usa objetos de A B tem os valores iniciais que sero passados para objetos de A, quando de sua criao

Criador
No sistema da Biblioteca, quem responsvel pela criao de um itemDeEmprestimo
adicionarCopia(copiaLivro)---> : Emprestimo

1: d:=calcularDataDevoluo()

2: criar(d, copiaLivro)

:Leitor

Uso do padro Criador: Emprestimo contm vrias linhas de emprestimo

linh: LinhaDoEmprestimo
Emprstimo/Devoluo data do emprstimo situao : Char

CriarLinhaEmprest()

Criador
Discusso
O padro guia a atribuio de responsabilidades relacionadas com a criao de objetos.
Escolha adequada favorece acoplamento fraco

Objetos agregados, contineres e registradores so 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.

Acoplamento
Acoplamento: dependncia entre elementos (classes, subsistemas, ...). Normalmente resultante de colaborao 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 no depende de muitos outros. Acoplamento forte (ou alto) um objeto depende de muitos outros.

Acoplamento
Problemas do acoplamento alto:
Mudanas em classes interdependentes foram mudanas locais. Dificulta a compreenso do objetivo de cada classe. Dificulta a reutilizao.

Acoplamento fraco o desejvel

Padro Acoplamento Fraco

Problema: como apoiar a baixa dependncia entre classes e aumentar a reutilizao ? Soluo: Atribuir responsabilidade de maneira que o acoplamento permanea baixo.

Padro Acoplamento Fraco

Exemplo: No sistema de biblioteca, suponha que queremos realizar a devoluo da cpia do livro. Qual classe deve ser responsvel por essa tarefa? Alternativas:
A classe Leitor A classe Livro A classe Emprstimo

Modelo Conceitual Biblioteca

0..n 0..n
^ faz

Reserva perodo situacao : char

0..1
corresponde a

corresponde a

0..1 0..1
faz Emprstimo/Devoluo

1
Atendente nome

1
registra

0..n

Leitor nome tipo : char

0..n
Livro

data do emprstimo situao : Char

possui

refere-se a >

Bibliotecaria nome

1
registra

0..n

titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char

1..n

0..1

LinhaDoEmprstimo data_prevista_devoluo data_entrega_real

0..n
< refere-se a

1
possui CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char

0..n

Projeto 1: responsabilidade atribuda ao Leitor

cop:=busca(codCopia) devolver(dataDeHoje)

Leitor conhece copias do livro?

4: atualizarSituacao('devolvida') devolveCopia(codCopia)--> leit: Leitor

2: devolver(dataDeHoje) 1: cop:=busca(codCopia)

cop: CopiaDoLivro

3: atualizarDataDev(dataDeHoje)

copias: CopiaDoLivro

linh: LinhaDoEmprestimo

Copia conhece linha do emprstimo?

Projeto 2: responsabilidade atribuda ao Livro

2: devolver(dataDeHoje) devolveCopia(codCopia)--> liv: Livro 3: atualizarSituacao('devolvida')

1: cop:=busca(codCopia)

cop: CopiaDoLivro

copias: CopiaDoLivro

4: atualizarDataDev(dataDeHoje) linh: LinhaDoEmprestimo

Eficiente? Cpia conhece a linha de emprstimo?

Projeto 3: responsabilidade atribuda ao Emprstimo

1: *[enquanto encontrou=false] linh:==proximo()

devolverCopia(codCopia)--->

: Emprestimo

:LinhaDoEmprestimo

2: cc:=obterCodigoCopia()

6: mudarSituacao('devolvida') 4: [encontrou] atualizaDataDev(dataDeHoje) 3: cc :=CodigoCopia() linh: LinhaDoEmprestimo 5: sinalizaDevolucao() cop: CopiaDeLivro

encontrou := false enquanto encontrou == false linh := proxima linha do emprestimo cc:=linh.obterCdigoCpia() encontrou:=(cc==codCopia) fim-enquanto se encontrou linh.atualizaDataDevolucao(dataDeHoje) fim-se

Qual projeto melhor?

Qual dos projetos anteriores favorece o acoplamento fraco?
Projeto 1 e 2 acoplamento aumenta (entre cpia do livro e linha do emprstimo, entre leitor e cpia do livro) Projeto 3 no aumenta acoplamento

PREFERVEL

Formas de Acoplamentos
Um objeto tem um atributo que referencia um objeto de outra classe. Um objeto tem um mtodo que referencia um objeto de outra classe.
Parmetro, varivel local ou retorno

Um objeto invoca os servios de um objeto de outra classe. Uma classe subclasse de outra, direta ou indiretamente.

Acoplamento Fraco
Discusso:
Acoplamento fraco -> classes mais independentes.
Reduz impacto de mudanas. Favorece reuso de classes.

Considerado em conjunto com outros padres Extremo de acoplamento fraco no desejvel

Fere princpios da tecnologia de objetos comunicao por mensagens Projeto pobre: objetos inchados e complexos, responsveis por muito trabalho -> baixa coeso

Acoplamento Fraco
Discusso:
Dica: concentre-se em reduzir o acoplamento em pontos de evoluo ou de alta instabilidade do sistema.

Benefcios:
Classes so pouco afetadas por mudanas em outras partes. Classes so simples de entender isoladamente. Conveniente para reutilizao.

Coeso
Mede o quanto as responsabilidade de um elemento (classe, objeto, subsistema,...) so fortemente focalizadas e relacionadas. (coeso funcional) Objeto com Coeso Alta -> objetos cujas responsabilidades so altamente relacionadas e que no executa um volume muito grande de trabalho. Objeto com Coeso Baixa -> objeto que faz muitas coisas no relacionadas ou executa muitas tarefas.
Difcil de compreender, reutilizar e manter. constantemente afetado por mudanas.

Coeso Alta
Problema: Como manter a complexidade sob controle? Soluo: Atribuir responsabilidade de tal forma que a coeso permanea alta.

Coeso Alta
Exemplo 1: ( o mesmo para o acoplamento fraco): No sistema de biblioteca, suponha que queremos realizar a devoluo da cpia do livro. Qual classe deve ser responsvel por essa tarefa?
Leitor Livro Emprstimo

Projeto 1: responsabilidade atribuda ao Leitor

cop:=busca(codCopia) devolver(dataDeHoje)

O Leitor fica parcialmente encarregado da devoluo da cpia do livro. Neste exemplo, isso seria aceitvel, mas o que aconteceria se houvesse 50 mensagens de outro tipo recebidas por Leitor?
4: atualizarSituacao('devolvida')

devolveCopia(codCopia)-->

leit: Leitor

2: devolver(dataDeHoje) 1: cop:=busca(codCopia)

cop: CopiaDoLivro

3: atualizarDataDev(dataDeHoje)

copias: CopiaDoLivro

linh: LinhaDoEmprestimo

Projeto 2: responsabilidade atribuda ao Livro

2: devolver(dataDeHoje) devolveCopia(codCopia)--> liv: Livro 3: atualizarSituacao('devolvida')

1: cop:=busca(codCopia)

cop: CopiaDoLivro

copias: CopiaDoLivro

4: atualizarDataDev(dataDeHoje) linh: LinhaDoEmprestimo

cop:=busca(codCopia) devolver(dataDeHoje)

Parece uma soluo melhor. Mas se houver inmeras operaes a serem feitas com o livro, ocorre o mesmo problema de Leitor.

Projeto 3: responsabilidade atribuda ao Emprstimo

1: *[enquanto encontrou=false] linh:==proximo()

devolverCopia(codCopia)--->

: Emprestimo

:LinhaDoEmprestimo

2: cc:=codigoCopia()

6: mudarSituacao('devolvida') 4: [encontrou] atualizaDataDev(dataDeHoje) 3: cc := codigoCopia() linh: LinhaDoEmprestimo cop: CopiaDeLivro

encontrou := false enquanto encontrou == false linh := proxima linha do emprestimo cc:= linh.obter o cdigo da cpia() encontrou:=(cc==codCopia) fim-enquanto se encontrou linh.atualizaDataDev(dataDeHoje) fim-se

5: sinalizaDevolucao()

Esta a melhor soluo. O objeto emprstimo representa eventos bem definidos no sistema de biblioteca (emprstimo e devoluo), por isso mais intuitivo que ele assuma esta responsabilidade.

Coeso Alta
Discusso:
Coeso alta, assim como Acoplamento Fraco, so princpios que devem ser considerados para a avaliao de projetos de objetos
M coeso traz acoplamento e vice-versa

Regra prtica: classe com coeso alta tem um nmero relativamente pequeno de mtodos, com funcionalidades relacionadas, e no executa muito trabalho. Analogia com mundo real
Pessoas que assume muitas responsabilidades no associadas podem tornar-se (e normalmente tornam-se) ineficientes.

Coeso Alta
Benefcios:
Mais clareza e facilidade de compreenso do projeto. Simplificao de manuteno e de acrscimo de funcionalidade/melhorias. Favorecimento do acoplamento fraco. Aumento no potencial de reutilizao
Classe altamente coesa pode ser usada para uma finalidade bastante especfica.

Ser que a soluo dada para o evento de devoluo da cpia ideal?

Ainda temos um problema: quando ocorre o evento de devoluo da cpia, o objeto emprstimo ao qual a cpia emprestada se refere ainda no conhecido . Portanto, preciso eleger alguma classe, que conhea os emprstimos, para receber a mensagem devolverCopia. Essa classe ter que identificar o objeto emprstimo cujo cdigo de cpia seja igual ao parmetro fornecido.

A pergunta anterior no est respondida nos slides a seguir. Voltaremos a ela no fim deste assunto.

Controlador
um objeto de interface (no interface de usurio) responsvel por tratar um evento externo (evento de sistema). Define o mtodo para a operao de sistema.
Sistema iniciarDevo(idLei) devolver(codCop) FinalizarDevol()

Operaes de sistema associadas aos eventos de sistema:

Sistema entrarItem() terminarVenda() efetuarPagamento()

Padro Controlador
Problema: Quem deve ser responsvel por tratar um evento do sistema (gerado por um ator externo) ? Soluo: A responsabilidade de receber ou tratar as mensagens de eventos do sistema (operaes) pode ser atribuda uma classe que:
Representa o sistema todo, representa o negcio ou organizao, um dispositivo ou um subsistema (chamado de controlador fachada) Representa algo no mundo real que ativo (chamado de controlador do papel) Representa um tratador artificial de todos os eventos de sistema de um caso de uso (Controlador do caso de uso)
TratadorDe<NomeDoCasoDeUso> ControladorDe<NomeDoCasoDeUso>

Padro Controlador
Exemplo: Quem vai tratar os eventos do sistema de biblioteca?
:Atendente Sistema

1: iniciarEmprstimo(id_Leitor) 2: nome e situao do leitor

3: emprestarLivro(id_Livro) 4: dataDeDevoluo

* mais livros a emprestar

5: encerrarEmprstimo()

Cod Cpia Livro

Emprestar

:Atendente
aoExecutada(eventoDaAo)

Camada de Interface

:CWindow
emprestarLivro(codCopia)
Objeto de Interfac e

Camada do Domnio :????

Exemplo1: Opes de Controlador

todo o sistema (controlador fachada): Biblioteca
iniciarEmprestimo()

um tratador artificial do caso de uso: ControladorDeEmprestarLivro

iniciarEmprestimo() :ControladorDe :Biblioteca EmprestarLivro emprestarLivro()

emprestarLivro()

:Biblioteca
encerrarEmprestimo() encerrarEmprestimo()

:ControladorDe EmprestarLivro

:Biblioteca

:ControladorDe EmprestarLivro 61

Discusso : Controladores Fachada

Um controlador fachada deve ser um objeto (do domnio) que seja o ponto principal para as chamadas provenientes da interface com o usurio ou de outros sistemas
pode ser uma abstrao de uma entidade fsica ex: TerminalDeAtendimento pode ser um conceito que represente o sistema ex: Biblioteca

So adequados quando no h uma quantidade muito grande de eventos de sistema Ou quando no possvel redirecionar mensagens do sistema para controladores alternativos (ex: outros subsistemas )

Discusso : Controladores de Caso de Uso

Deve existir um controlador diferente para cada caso de uso
Por exemplo, o ControladorDeEmprestarLivro ser responsvel pelas operaes iniciarEmprstimo, emprestarLivro e encerrarEmprstimo

No um objeto do domnio, e sim uma construo artificial para dar suporte ao sistema. Ex: ControladorDeEmprestarLivro, ControladorDeDevolverLivro Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coeso (controlador inchado por excesso de responsabilidades) uma boa alternativa quando existem muitos eventos envolvendo diferentes processos.

Controladores inchados
Classe controladora mal projetada - inchada
coeso baixa falta de foco e tratamento de muitas responsabilidades

Sinais de inchao:
uma nica classe controladora tratando todos os eventos, que so muitos. Comum com controladores fachada o prprio controlador executa as tarefas necessrias para atender o evento, sem delegar para outras classes (coeso alta, no especialista) controlador tem muitos atributos e mantm informao significativa sobre o domnio, ou duplica informaes existentes em outros lugares

Possveis solues para controladores inchados

Acrescentar mais controladores. Projetar o controlador de forma que ele possa delegar o atendimento da responsabilidade de cada operao de sistema a outros objetos. Cuidado: Controladores de papis podem conduzir a maus projetos(armadilha de projetar objetos semelhantes a pessoas para fazer todo o trabalho preciso delegar)

Corolrio do Padro Controlador

Objetos de interfaces HM ( como objetos janela) e da camada de apresentao no devem ter a responsabilidade de tratar eventos do sistema (arquitetura em camadas)

Benefcios do Padro Controlador e seu corolrio Benefcios:

aumento das possibilidades de reutilizao de classes e do uso de interfaces plugveis. conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso, garantindo a seqncia correta de execuo de operaes

Cod Cpia Livro

Emprestar

:Atendente
aoExecutada(eventoDaAo)

devolver Copia?

Camada de Interface

:CWindow

emprestarLivro(codCopia)

Camada do Domnio ????

emprestarLivro(codCopia)

:Emprestimo

Voltando ao problema do slide 57.... Qual era o problema:

devolverCpia x Emprstimo

Qual a soluo?
Classe Fachada ou Controladora

Cod Cpia Livro

Emprestar

:Atendente
aoExecutada(eventoDaAo)

devolver Copia?

Camada de Interface

:CWindow

devolverCopia(codCopia)

Camada do Domnio :Biblioteca

devolverCopia(codCopia)

:Emprestimo

Prximo assunto
Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar

Padres GRASP

Estudo de Caso TPV : Projetar uma soluo com objetos e Padres GRASP