Beruflich Dokumente
Kultur Dokumente
Reserva
0..n 0..n
^ faz
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
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
0..n
0..n
< refere-se a
1..1
possui
0..n
0..*
possui
1..*
refere-se a
0..*
Conhecer
Conhecer dados privados encapsulados. Conhecer objetos relacionados. Conhecer dados/atributos que podem ser derivados ou calculados.
Sistema Videolocadora
Cod Cpia Fita
Emprestar
:Atendente
aoExecutada(eventoDaAo)
Camada de Interface
:CWindow
emprestarFita(fcodigo)
possui
possui
10
item: ItemDeEmprestimo
item: ItemDeEmprestimo
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)
Exemplo
No sistema biblioteca, quem seria o responsvel por calcular a data de devoluo de um livro?
0..1
corresponde a
corresponde a
0..1 0..1
faz Emprstimo/Devoluo
1
Atendente nome
1
registra
0..n
0..n
Livro
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
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?
0..1
corresponde a
corresponde a
0..1 0..1
faz Emprstimo/Devoluo
1
Atendente nome
1
registra
0..n
0..n
Livro
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
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
linh: LinhaDoEmprestimo
linh: LinhaDoEmprestimo
Especialista
Onde procurar pela classe especialista?
Comear pelas classes j estabelecidas durante o projeto. Se no encontrar, utilizar o Modelo Conceitual.
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?
Criador
No sistema da Biblioteca, quem responsvel pela criao de um itemDeEmprestimo
adicionarCopia(copiaLivro)---> : Emprestimo
1: d:=calcularDataDevoluo()
2: criar(d, copiaLivro)
:Leitor
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.
0..1
corresponde a
corresponde a
0..1 0..1
faz Emprstimo/Devoluo
1
Atendente nome
1
registra
0..n
0..n
Livro
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
0..n
< refere-se a
1
possui CopiaDoLivro nro sequencial situacao : char liberadoParaEmprestimo : char
0..n
2: devolver(dataDeHoje) 1: cop:=busca(codCopia)
cop: CopiaDoLivro
3: atualizarDataDev(dataDeHoje)
copias: CopiaDoLivro
linh: LinhaDoEmprestimo
1: cop:=busca(codCopia)
cop: CopiaDoLivro
copias: CopiaDoLivro
devolverCopia(codCopia)--->
: Emprestimo
:LinhaDoEmprestimo
2: cc:=obterCodigoCopia()
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
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.
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
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
1: cop:=busca(codCopia)
cop: CopiaDoLivro
copias: CopiaDoLivro
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.
devolverCopia(codCopia)--->
: Emprestimo
:LinhaDoEmprestimo
2: cc:=codigoCopia()
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.
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()
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
3: emprestarLivro(id_Livro) 4: dataDeDevoluo
Emprestar
:Atendente
aoExecutada(eventoDaAo)
Camada de Interface
:CWindow
emprestarLivro(codCopia)
Objeto de Interfac e
emprestarLivro()
:Biblioteca
encerrarEmprestimo() encerrarEmprestimo()
:ControladorDe EmprestarLivro
:Biblioteca
:ControladorDe EmprestarLivro 61
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 )
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
Emprestar
:Atendente
aoExecutada(eventoDaAo)
devolver Copia?
Camada de Interface
:CWindow
emprestarLivro(codCopia)
:Emprestimo
Qual a soluo?
Classe Fachada ou Controladora
Emprestar
:Atendente
aoExecutada(eventoDaAo)
devolver Copia?
Camada de Interface
:CWindow
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