Aula09_Diagramas de Colaboração e Padrões GRASP

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 agoraDiagramas 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..1corresponde a

corresponde a

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

1..1Atendente nome

1..1registra

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..1registra

LinhaDoEmprstimo data_prevista_dev oluo data_entrega_real

0..n

0..n< refere-se a

1..1possui

Objetivo ao final da fase de projeto

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

0..n

Leitor nome tipo calcularDataDevolucao( ) 1faz

0..*

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

Mais a especificao das interfacesLinhaDoEmprestimo data_prevista_devoluo data_entrega_real codCopia( ) atualizarDataDev( )

possui

1..*refere-se a

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

0..*

1

Como projetar as responsabilidades de cada objetoSabemos 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 objetoResponsabilidade: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:FazerFazer algo (criar um objeto, executar uma operao, ...) Iniciar aes em outros objetos(delegao). Controlar e coordenar atividades em outros objetos.

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

Responsabilidades e Diagramas de InteraoDiagramas 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 PadresDiagrama de Comunicao para a operao EmprestarFita(fcodigo)

Implementao inchada ou concentradora X Implementao leve, distribuda

Sistema VideolocadoraCod Cpia Fita

Emprestar

:AtendenteaoExecutada(eventoDaAo)

Camada de Interface

:CWindowemprestarFita(fcodigo)

Camada do Domnio :????

Modelo Conceitual Sistema VideolocadoraVideolocadora

possui

possui

10

Colaborao entre os objetos2: 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 VideoLocadoraClasse VideoLocadorafitas: 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 ConcentradoremprestarFita(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 DistribudaClasse 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;

DiscussoQual 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.

ResponsabilidadeResponsabilidade 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.

PadresDesenvolvedores 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)

PadresPadres usualmente no contm novas idiasOrganizam 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 GRASPGRASP = 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 GRASPAlguns 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.

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

Modelo Conceitual Biblioteca0..n 0..n^ faz

Reserva perodo situacao : char

0..1corresponde a

corresponde a

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

1Atendente nome

1registra

0..n


1

0..nLivro

data do emprstimo situao : Char

1

possui

refere-se a >

1

Bibliotecaria nome

1registra

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

1possui CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char

1

0..n

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



0..1corresponde a

corresponde a


1Atendente nome

1registra

0..n


1

0..nLivro


1

possui

refere-se a >

1

Bibliotecaria nome

1registra

0..n


1..n

0..1


0..n< refere-se a


1

0..n

EspecialistaPelo 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.

EspecialistaadicionarCopia(copiaLivro)---> : Emprestimo

1: d:=calcularDataDevoluo()

2: criar(d, copiaLivro)

:Leitor

Uso do padro Especialista

linh: LinhaDoEmprestimo

Especialista: alternativa mais detalhadaadicionarCopia(CopiaLivro)

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


Uso do padro Especialista

EspecialistaOnde 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 tarefaInformao espalhada -> comunicao via mensagens

Existe uma analogia no mundo real.

EspecialistaDiscusso 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-indicaescontra 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

CriadorNo sistema da Biblioteca, quem responsvel pela criao de um itemDeEmprestimoadicionarCopia(copiaLivro)---> : Emprestimo

1: d:=calcularDataDevoluo()

2: criar(d, copiaLivro)

:Leitor

Uso do padro Criador: Emprestimo contm vrias linhas de emprestimo

linh: LinhaDoEmprestimoEmprstimo/Devoluo data do emprstimo situao : Char

CriarLinhaEmprest()

CriadorDiscussoO 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.

AcoplamentoAcoplamento: 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 objetosAcoplamento fraco (ou baixo) um objeto no depende de muitos outros. Acoplamento forte (ou alto) um objeto depende de muitos outros.

AcoplamentoProblemas 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 FracoProblema: como apoiar a baixa dependncia entre classes e aumentar a reutilizao ? Soluo: Atribuir responsabilidade de maneira que o acoplamento permanea baixo.

Padro Acoplamento FracoExemplo: 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



0..1corresponde a

corresponde a


1Atendente nome

1registra

0..n


1

0..nLivro


1

possui

refere-se a >

1

Bibliotecaria nome

1registra

0..n


1..n

0..1


0..n< refere-se a


1

0..n

Projeto 1: responsabilidade atribuda ao Leitorcop:=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


Copia conhece linha do emprstimo?

Projeto 2: responsabilidade atribuda ao Livro2: devolver(dataDeHoje) devolveCopia(codCopia)--> liv: Livro 3: atualizarSituacao('devolvida')

1: cop:=busca(codCopia)

cop: CopiaDoLivro


4: atualizarDataDev(dataDeHoje) linh: LinhaDoEmprestimo

Eficiente? Cpia conhece a linha de emprstimo?

Projeto 3: responsabilidade atribuda ao Emprstimo1: *[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 AcoplamentosUm 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 FracoDiscusso:Acoplamento fraco -> classes mais independentes.Reduz impacto de mudanas. Favorece reuso de classes.

Considerado em conjunto com outros padres Extremo de acoplamento fraco no desejvelFere princpios da tecnologia de objetos comunicao por mensagens Projeto pobre: objetos inchados e complexos, responsveis por muito trabalho -> baixa coeso

Acoplamento FracoDiscusso: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.

CoesoMede 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 AltaProblema: Como manter a complexidade sob controle? Soluo: Atribuir responsabilidade de tal forma que a coeso permanea alta.

Coeso AltaExemplo 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 Leitorcop:=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)



Projeto 2: responsabilidade atribuda ao Livro2: devolver(dataDeHoje) devolveCopia(codCopia)--> liv: Livro 3: atualizarSituacao('devolvida')

1: cop:=busca(codCopia)

cop: 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 Emprstimo1: *[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 AltaDiscusso:Coeso alta, assim como Acoplamento Fraco, so princpios que devem ser considerados para a avaliao de projetos de objetosM 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 realPessoas que assume muitas responsabilidades no associadas podem tornar-se (e normalmente tornam-se) ineficientes.

Coeso AltaBenefcios: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 reutilizaoClasse 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 ControladorProblema: 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 ControladorDe

Padro ControladorExemplo: 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 emprestar5: encerrarEmprstimo()

Cod Cpia Livro

Emprestar


Camada de Interface

:CWindowemprestarLivro(codCopia)Objeto de Interfac e

Camada do Domnio :????

Exemplo1: Opes de Controladortodo o sistema (controlador fachada): BibliotecainiciarEmprestimo()

um tratador artificial do caso de uso: ControladorDeEmprestarLivro

iniciarEmprestimo() :ControladorDe :Biblioteca EmprestarLivro emprestarLivro()

emprestarLivro()

:BibliotecaencerrarEmprestimo() encerrarEmprestimo()

:ControladorDe EmprestarLivro

:Biblioteca

:ControladorDe EmprestarLivro 61

Discusso : Controladores FachadaUm 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 sistemaspode 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 UsoDeve existir um controlador diferente para cada caso de usoPor 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 inchadosClasse controladora mal projetada - inchadacoeso 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 inchadosAcrescentar 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 ControladorObjetos 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


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


devolver Copia?

Camada de Interface

:CWindow

devolverCopia(codCopia)

Camada do Domnio :BibliotecadevolverCopia(codCopia)

:Emprestimo

Prximo assuntoRefinar Plano Sincronizar artefatos Analisar Projetar Construir Testar

Padres GRASP

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

Documents

Aula09_Diagramas de Colaboração e Padrões GRASP