Engenharia de Software Persistencia e padroes

(1)

(2)

Persistência



_{Necessidade de utilizar objetos criados durante a}

execução de um programa em execuções futuras,

ou ainda em outras aplicações.

var

e1:Empregado;

begin

e1.Create (“Joao”);

...

(3)

Persistência



Um objeto persistente é aquele que

existe logicamente além do escopo do

programa que o cria.



As linguagens de programação OO

lidam apenas com objetos

(4)

Persistência



Armazenamento: salvar um objeto em

algum tipo de armazenamento

persistente.

(5)

Armazenamento - Alternativas



_{Soluções baseadas em arquivos.}



_{Soluções baseadas em BD hierárquicos.}



Soluções baseadas em BD Relacionais.



Soluções baseadas em BD orientados a

(6)

Soluções Baseadas em BD Relacional



_{Forte necessidade de integração entre}

linguagens OO e Bancos Relacionais:



Dados já existentes;



Grau de amadurecimento de soluções com BD

Relacionais;



_{Popularidade de SQL e ferramentas baseadas}

em SQL;



Profissionais com experiência em BD

(7)

BD Relacional



_{Os Banco de Dados Relacionais constituem}

a forma de armazenamento mais utilizada e

robusta atualmente.



_{Entretanto, exite uma diferença semântica}

natural entre o modelo OO e o modelo

baseado em tabelas de um BD relacional.



Um mecanismo de mapeamento entre os

(8)

Mapeamento de Atributo em

coluna



_{Um atributo de objetos: zero ou mais}

colunas no BD relacional:



1 atributo – 0 coluna:



_{Alguns atributos podem ser transientes.}



1 atributo – 1 coluna:



_{Atributos sem estrutura}



_{Ex.: data, string}



1 atributo – n colunas:

(9)

Mapeamento de Classe em Tabela



Normalmente, uma classe é mapeada

para uma tabela.

(10)

Mapeamento de Classe em Tabela

As s ociado

Nom e

Ende reco

Adm is s ao

(11)

Mapeamento de Classe em Tabela



Mapeamentos mais complicados são

possíveis.



Uma classe



Várias tabelas.



Cliente



_Id

_string



_{Nome string}



_Enderço

_string

(12)

Mapeamento de Relacionamentos



_{Um relacionamento um-para-um é}

mapeado com uma chave estrangeira no

banco de dados relacional. A chave

deverá ser feita por meio dos

Ids

das

tabelas.

Id_Associado

Nome

Endereco

Admissao

Tab. Do Associado

(13)

Mapeamento de Relacionamentos



_{Um relacionamento um-para-muitos é}

mapeado com uma chave estrangeira no

banco de dados relacional. A chave

deverá ser feita por meio dos

Ids

das

tabelas.

Associado

Nome

Endereco

Admissao

Dependente

Nome

DataNasc

0..n

1 0..n

1

(14)

Mapeamento de Relacionamentos



_{O relacionamento muitos para muitos é}

resolvido criando tabelas adicionais no

banco de dados relacionais.

As s ociado

Hos pital

1..n

Atendim ento

(15)

Mapeamento de Herança



_{Partição Vertical:}



_{1 tabela por classe}



_{Partição Horizontal:}



1 tabela por classe folha (migração dos atributos

para as subclasses).



Tabela Única:



1 tabela para toda a linha de herança (migração

(16)

Mapeamento de Herança

Equipamento

nome

preço

Bomba

pressaoSuccao

pressaoDescarga

(17)

(18)

Partição Horizontal



_Bomba:



_ID



Nome



Preco



pressaoSuccao



pressaoDescarga



_{DissipadorCalor:}



_ID



Nome



Preco

(19)

Tabela Única



Equipamento:



ID



Nome



Preco



pressaoSuccao



pressaoDescarga



areaSuperficie

(20)

Mapeamento de Herança



_{Partição Vertical:}



Evita redundância;



Performance (join);



Partição Horizontal:



_{Redundância.}



_{Tabela única:}

(21)

Mapeamento de Herança



Compromissos entre performance,

espaço em disco e facilidade de

modificação são usados para decidir

que mapeamento deve ser usado para

situações de herança.

(22)

Outras Estratégias



_{Métodos internos responsabilizam-se}

pela persistência do objeto (CRUD).

Classe

Create()

Restore()

Upadate()

Delete()

Insert into...

Select

from...

Update ...

(23)

Outras estratégias



Utilizar um produto para auxiliar no

mapeamento



Cache de objetos;



Controle de concorrência;



Front-end

de um OODBMS para um

(24)

Caracterização de padrões de

projeto

Design

Patterns

(25)

Introdução



Em g e ral, e m e ng e nharia de so ftw are

,

do is são o s princ ipais te m as tratado s:



Metodologia para o

desenvolvimento de sistemas.



Linguagem de modelagem para o

(26)

Introdução



As dific uldade s e nc o ntradas são de c o rre nte s da

falta de e xpe riê nc ia de q ue m e stá apre nde ndo

am b o s o s

te m as pe la prim e ira v e z o u da

dific uldade de

c o m b inaç ão de to do s o s

e le m e nto s q ue faze m parte do pro je to de um

siste m a c o m ple xo .



“ Estudo s de c aso s” são um a fo nte b astante ric a

(27)

Padrões



Descrevem maneiras comuns de fazer

as coisas e são coletados por pessoas

que identificam temas repetitivos em

projetos.



Um padrão é muito mais que um

(28)

Padrões



Um padrão é a solução para um

problema.



Deve identificar o problema

claramente, explicar porque ele

(29)

Padrões



_{O que é um padrão?}



_{Maneira testada ou documentada de alcançar um}

objetivo qualquer



Cada padrão descreve um problema que ocorre

repetidas vezes em nosso ambiente, e então descreve

o núcleo da solução para aquele problema, de tal

maneira que pode-se usar essa solução milhões de

vezes sem nunca fazê-la da mesma forma duas vezes



Os padrões de projeto são descrições de objetos que se

(30)

Por que aprender padrões?



_{Aprender com a experiência dos outros}



_{Aprender a programar bem com orientação}

a objetos



_{Desenvolver software de melhor qualidade}



_{Vocabulário comum}



_{Ajuda na documentação e na aprendizagem}



Uma prática adjunta aos métodos

(31)

Problemas de Projeto

Solucionados por padrões



_{Procurando objetos apropriados.}



_{Determinando a granularidade dos objetos.}



_{Especificando interfaces dos objetos.}



_{Especificando}

_i

_{implementações dos objetos.}



_{Herança de classe versus herança de interface.}



_{Programando para uma interface, não para uma}

i

implementação.



_{Colocando os mecanismos de reutilização para funcionar.}



_{Herança versus composição.}

(32)

Problemas de Projeto

Solucionados por padrões



Re la c io na nd o e s tr utur a s d e te m p o d e e xe c uç ã o e d e

te m p o d e c o m p ila ç ã o .



P r o je ta nd o p a r a m ud a nç a s .



D e p e nd ê nc ia s d e o p e r a ç õ e s e s p e c ífic a s , p la ta fo r m a s d e

s o ftw a r e e ha r d w a r e , d e r e p r e s e nta ç õ e s o u im p le m e nta ç õ e s d e

o b je to s e a lg o r ítm ic a s .



A c o p la m e nto fo r te .



Inc a p a c id a d e na a lte r a ç ã o d e c la s s e s .



_{P r o g r a m a s d e a p lic a ç ã o .}

(33)

Elementos de um padrão



_Nome



_{É uma referência que podemos usar para descrever}

um problema. Ajuda na implementação e

comunicação.



_Problema



_{Descreve como aplicar o padrão e quando.}



_Solução



Descreve os elementos que compõem o projeto,

seus relacionamentos, suas responsabilidades e

colaborações.



_{Conseqüências}

(34)

Como selecionar um padrão

de projeto?



Considere como os padrões de projeto

solucionam problemas de projeto.



Examine as seções de descrição do

problema de cada padrão.



Estude como os padrões se

interrelacionam.



_{Estude padrões de finalidades semelhantes.}



_{Examine uma causa de reformulação de}

projeto.

(35)

Como usar um padrão de

projeto?



Leia o padrão por inteiro, uma vez, para obter uma

visão geral.



Estude as seções de descrição do problema e do

padrão.



Olhe exemplos de código do padrão.



_{Escolha nomes para os participantes do padrão}

que tenham sentido no contexto da aplicação.



Defina as classes.



_{Defina nomes específicos da aplicação para as}

operações no padrão.

(36)

Padrões de Projeto



_{Em geral os padrões de projeto podem ser classificados em três}

diferentes tipos:

–

Padrões de criação: abstraem o processo de criação de

objetos a partir da instanciação de classes.

–

Padrões estruturais: tratam da forma como classes e

objetos estão organizados para a formação de

estruturas maiores.

–

Padrões comportamentais: preocupam--se com

algoritmos e a atribuição de responsabilidade entre

objetos.



_{Cada um desses tipos pode ser subclassificado em:}

(37)

Padrões de Criação



_{Abstract Factory: Fornece uma interface para}

criação de famílias de objetos relacionados ou

dependentes sem especificar suas classes

concretas.



A fábrica permite a troca de toda uma coleção

de classes sem grandes modificações no

programa fonte. Quem conhece as classes

concretas é somente a fábrica.



O padrão Abstract Factory foi utilizado para que

o sistema tivesse portabilidade em relação ao

SGDB utilizado



_{Uso conhecido: transportabilidade entre}

(38)

(39)

Padrões de Criação



Builder: Separa a construção de um objeto complexo da

sua representação, de modo que o mesmo processo de

construção possa criar diferentes representações.



_{O algoritmo para criação de um objeto complexo}

deve ser independente das partes que compõem o

objeto e de como elas são montadas.



Para atender esse requisito utilizamos o padrão de

projeto Builder, ou seja, separamos o processo de

produção do relatório da lógica de construção de

texto nos diferentes formatos



_{Uso conhecido: conversão de formatos de texto em}

(40)

(41)

Padrões de Criação



_{Factory Method: define uma interface}

para criar um objeto, mas deixa as

subclasses decidirem qual classe será

instanciada. Permite a uma classe

postergar a instanciação de subclasses.



Uso conhecido: bastante usado em

(42)

Padrões de Criação



Prototype: especifica os tipos de

objetos a serem criados usando uma

instância prototípica e cria novos

objetos copiando este protótipo.

(43)

Padrões de Criação



_{Singleton: Garante que uma classe tenha}

somente uma instância e fornecer um

ponto global de acesso para ela. Deve

haver apenas uma instância de uma

classe.

(44)

Padrões Estruturais



_{Adapter: Converte a interface de uma classe em}

outra interface esperada pelos clientes. Permite

que certas classes trabalhem em conjunto, pois de

outra forma seria impossível por causa de suas

interfaces incompatíveis.



Usar uma classe existente, mas sua interface

não corresponde à interface de que necessita.



O padrão Adapter foi utilizado para prover uma

interface mais adequada em certas situações

para as classes correspondentes aos objetos

persistentes.

(45)

(46)

Padrões Estruturais



Bridge: Separa uma abstração da sua

implementação, de modo que as duas

possam variar independentemente.



Separar a interface da sua

implementação.



Uso conhecido: Pessoa, inclusão de

novas pessoas. Para evitar o vínculo

entre abstração e implementação

quando de mudanças na

(47)

Padrões Estruturais



Composite: Compõem Objetos em estrutura de

árvore para representar hierarquias do tipo

partes-todo.

–

Uso conhecido: Hierarquia do módulo de

segurança. Hierarquias partes-todo



_{Decorator: Atribui responsabilidades adicionais a}

um objeto dinamicamente. Fornece uma alternativa

flexível à utilização de subclasses para a extensão

de funcionalidades

–

Uso conhecido: para a atribuição de

(48)

(49)

Padrões Estruturais



_{Façade: Fornece uma interface unificada}

para um conjunto de interfaces em um

subsistema. O façade define uma interface

de nível mais alto que torna o subsistema

mais fácil de usar.



Uso conhecido: Oferecer uma interface

única de nível mais elevado para um

conjunto de interfaces de um subsistema.

(50)

(51)

Padrões Estruturais



_{Flyweight: Usa compartilhamento para}

suportar grandes quantidades de objetos,

de granularidade fina, de maneira eficiente.



Uso conhecido: Sistemas com grande

número de objetos



_{Proxy: fornece um objeto representante ou}

um marcador de outro objeto para controlar

o acesso ao mesmo

(52)

(53)

Padrões Comportamentais



Chain of responsability: Desacoplar

remetentes e receptores fornecendo a

múltiplos objetos a oportunidade de tratar

uma solicitação. A solicitação é passada

ao longo de uma cadeia de objetos até

que um deles a trate.



Uso conhecido: tratamento de eventos

de usuário.



Help: O objeto a ser tratado é

(54)

(55)

Padrões Comportamentais



_{Command: Encapsular uma solicitação}

como um objeto. Pode parametrizar clientes

com vários tipos de solicitação.



Uso conhecido: O padrão Command foi

utilizado na implementação das telas

para desacoplá-las dos objetos que

realmente executam as operações

(56)

(57)

Padrões Comportamentais



Interpreter: dada uma linguagem,

define uma representação para sua

gramática juntamente com um

interpretador que usa a representação

interpretar sentenças nesta linguagem.



Uso conhecido: interpretar uma

(58)

Padrões Comportamentais



Iterator: Fornece uma maneira de

acessar sequencialmente os elementos

de um objeto agregado sem expor sua

representação subjacente.

–

Uso conhecido: Lista acessar seus

elementos sem expor a sua

(59)

Padrões Comportamentais



_{Mediator: Define um objeto que encapsula}

como um conjunto de objetos interage. O

mediator promove o acoplamento fraco ao

evitar que os objetos se refiram explicitamente

uns aos outros, permitindo que você varie suas

interações independentemente.



Um objeto pode ter que ter o conhecimento

de vários outros. Esta comunicação pode

ser complexa e de difícil reutilização.



Uso conhecido: arquitetura de aplicações de

(60)

Padrões Comportamentais



_{Memento: Sem violar o encapsulamento,}

captura e externaliza um estado interno de

um objeto, de modo que o mesmo possa

ser posteriormente recuperado. Um padrão

para trabalhar com estado do objeto.

Necessidade de recuperar um determinado

Estado.

–

Uso conhecido: armazenar um

(61)

Padrões Comportamentais



_{Observer: Define uma dependência}

um-para-muitos entre objetos, de modo que,

quando um objeto muda de estado, todos

os seus dependentes são automaticamente

notificados e atualizados. Usar quando uma

mudança em um objeto exige mudanças em

outros.

–

Uso conhecido: propagação de

mudanças e atualizações com

(62)

(63)

Padrões Comportamentais



_{State: Permite que um objeto altere seu comportamento}

quando seu estado interno muda. O comportamento do

objeto depende do seu estado.

–

Uso conhecido: em algumas implementações

da pilha TCP/IP



_{Strategy: Definir uma família de algoritmos, encapsular}

cada uma delas e torná-las intercambiáveis. Permite

que o algoritmo varie independentemente dos clientes

que utilizam.

(64)

(65)

(66)

Padrões Comportamentais



Template Method: define o esqueleto

de um algoritmo em uma operação,

postergando a definição de alguns

passos para subclasses. Permite que

as subclasses redefinam certos

passos de um algoritmo sem mudar

sua estrutura.



Uso conhecido: arquiteturas

(67)

(68)

Padrões Comportamentais



Visitor: representa uma operação a ser

executada sobre os elementos de uma

estrutura de objetos. Permite a

definição de uma nova operação sem

mudar as classes dos elementos

sobre os quais opera.



Uso conhecido: para executar uma