5.1-DesenvolvendoemCamadas-comFrontContrller

(1)

Padrões de Projeto

Prof. Cristiano Biancardi

(2)

Aplicações Desktop usando Java/NetBeans - Cristia

no Biancardi no Biancardi 2 2

Introdução



Aplicações em 2 camadas

• Lógica de apresentação (a interface homem

máquina) e a lógica de negócio (algoritmos do

sistema – casos de uso), estão reunidos em

uma única camada.

• Modelo de Classes do Domínio do Problema

fica separado –> quando implementadas.

• Atualização eram extremamente penosas e

complexas.

(3)



Com o passar do tempo, novas restrições de tempo e custo surgiram,

além de maior concorrência.



Necessidade de um modelo que permitisse maior produtividade e

desenvolvimento de aplicações mais confiáveis.



Surgiram os padrões de desenvolvimento em 3 ou mais camadas.



Vantagens:

• Reusabilidade

_{Reusabilidade}



O mesmo modelo pode ser usado com diferentes visões (ou aplicações diferentes).



Confiabilidade: modelo pronto e testado

• Clareza e Modularidade de projeto.

_{Clareza e Modularidade de projeto.}

• Manutenção facilitada

_{Manutenção facilitada}



Torna o sistema mais flexível, de modo que partes podem ser

alteradas independentemente.

• Necessário apenas a definição da interface contratual a ser usada.Necessário apenas a definição da interface contratual a ser usada.



Qualquer alteração em uma determinada camada não influi nas

demais, desde que o mecanismo de comunicação entre elas

permanece inalterado.

(4)

no Biancardi

4



Projetar software é uma tarefa difícil. A maioria dos projetistas é capaz

de compreender conceitos como classes, objetos, interfaces e herança.



O desafio reside em aplicá-los para construir software flexível e

reutilizável.



Projetistas novatos tendem a se perder com as muitas opções

disponíveis e a recorrer a técnicas não orientadas a objetos com as

quais têm certa familiaridade.



Projetistas experientes, por sua vez, tendem a fazer bons projetos. Eles

sabem que não se deve resolver todo e qualquer problema partindo de

princípios básicos (classes, objetos, herança, relacionamentos,

agregação,...).



Ao contrário, deve-se buscar reutilizar soluções que funcionaram no

passado. Esta é a motivação para o estudo de padrões de projeto, ou

design patterns

.

(5)



Assim, um padrão é um par nomeado problema/solução, que pode

ser utilizado em novos contextos, com orientações sobre com

utilizá-lo em novas situações.



Padrões são destilações de sabedoria acumulada, fornecendo

um jargão-padrão e nomeando os conceitos que praticantes

experimentados aplicam.



Cada padrão sistematicamente nomeia, explica e avalia um

importante projeto que ocorre repetidamente em sistemas OO.

• O objetivo de um

_{O objetivo de um}

design pattern

é registrar uma experiência no projeto

de software OO, na forma de um padrão passível de ser efetivamente

utilizado por projetistas.



Um projetista familiarizado com padrões de projeto pode aplicá-los

diretamente a problemas de projeto sem ter que redescobrir

abstrações e os objetos que as capturam.

(6)

no Biancardi

6



Em geral, um padrão tem quatro elementos essenciais:

• Nome

_Nome

: identificação de uma ou duas palavras, que se possa utilizar

para descrever o problema de projeto, suas soluções e

conseqüências.

• Problema

_Problema

: descreve quando aplicar o padrão. Explica o problema

de projeto e seu contexto.

• Solução

Solução

: descreve os elementos que compõem o projeto, seus

relacionamentos, responsabilidades e colaborações.

Não

descreve

um particular projeto concreto ou implementação.



Um padrão provê uma descrição abstrata de um problema de projeto e

como uma organização geral de classes e objetos resolve este problema.

• Conseqüências

_{Conseqüências}

: são os resultados e os comprometimentos feitos

ao se aplicar o padrão, tais como, bibliotecas de classes necessárias,

que problemas acarreta, etc.

(7)



A sigla “GoF”

• “

_“

Gang of Four”

• Apelido carinhoso pela qual o quarteto Erich Gamma,

_{Apelido carinhoso pela qual o quarteto Erich Gamma,}

Richard Helm, Ralph Johnson e John Vlissides ficou

conhecido quando escreveram o livro “Design

Patterns”, no início da década de 90

• Neste livro, os quatro dividiram um conjunto de 23

_{Neste livro, os quatro dividiram um conjunto de 23}

padrões em 3 grupos:



Estruturais:

lidam com maneiras de se compor

objetos.



Comportamentais:

caracterizam formas de

interação entre objetos.

(8)

no Biancardi

8

(9)

Observer



Observador



Intenção

• Definir uma dependência um-para-muitos entre objetos de

_{Definir uma dependência um-para-muitos entre objetos de}

forma que quando um objeto muda de estado, todos seus

dependentes são notificados e atualizados automaticamente.



Aplicação

• Mudar um objeto causando mudanças em outros objetos,

_{Mudar um objeto causando mudanças em outros objetos,}

sendo que não se sabe a priori quantos objetos precisam ser

mudados.

• Fazer um objeto notificar outros objetos de que seu estado

_{Fazer um objeto notificar outros objetos de que seu estado}

mudou, sem assumir nada sobre os outros objetos.

• Exemplo:

_Exemplo:



Fundos múltiplos investem em ações, de modo que quando o preço de

uma ação muda, todos os fundos que investem nessa açao são

afetados.

(10)

no Biancardi

10

(11)

(12)

MVC

• Com o aumento da complexidade das aplicações

_{Com o aumento da complexidade das aplicações}

desenvolvidas torna-se fundamental a separação entre os

dados (

Model

) e o layout (

View

).

• Desta forma, alterações feitas no layout não afetam a

Desta forma, alterações feitas no layout não afetam a

manipulação de dados, e estes poderão ser reorganizados sem

alterar o layout.

• Um dos primeiros padrões identificados na área de software foi

_{Um dos primeiros padrões identificados na área de software foi}

o modelo MVC:



Model (Modelo)



View (Visão)

(13)



Motivação:

(14)

no Biancardi

14



Diferença

• Separação em camadas

_{Separação em camadas}

• _{Relacionamento entre as camadas}

_{Relacionamento entre as camadas}

• Separado em camadas, é possível

_{Separado em camadas, é possível}

estabelecer interação.

(15)

• Model:

_Model:

responsável pelo armazenamento e

manutenção dos dados utilizados pela aplicação.



Modelo de classes proveniente da fase de análise

• View:

_View:

é a camada responsável pela interface com

o usuário.

• Controller: t

_{Controller: t}

rata os eventos de interação com o

usuário e, normalmente, invoca as mudanças no

modelo.

(16)

no Biancardi

16



Relação entre

Model, View e

Controller

• Linhas sólidas

_{Linhas sólidas}

indicam associação

direta / Chamada

de métodos

• Linhas tracejadas

_{Linhas tracejadas}

indicam associação

indireta / Eventos

(17)

(18)



Funcionamento:

• A visão

_{A visão}



Parte usada para transformar e preparar os dados do

modelo para que possam ser apresentados de

alguma forma (HTML, swing etc).



O controlador retira os dados do modelo e os entrega

para a visão (ou retira dados da interface e alimenta

o modelo).



Esta, por sua vez, alimenta templates com estes

dados para que possam ser apresentados ao usuário.



Além disso, efetua-se algum tratamento do tipo:

• Verificação de campos obrigatórios

_{Verificação de campos obrigatórios}

(19)

• O modelo

_{O modelo}



Parte que encapsula os dados da aplicação.



Fornecer rotinas para administrar e manipular dados.

• Deve conter métodos para adicionar, eliminar e atualizar

_{Deve conter métodos para adicionar, eliminar e atualizar}

informações dos objetos na base de dados.

• Também deve conter métodos para obter a lista de objetos

_{Também deve conter métodos para obter a lista de objetos}

existentes.



De modo geral, a técnica de acesso aos dados deve ser

encapsulada no modelo.

• Desta forma, se uma aplicação for transferida de um

Desta forma, se uma aplicação for transferida de um

sistema que usa banco de dados para um sistema que usa

arquivos texto para guardar as informações, o único

elemento que precisa ser alterado será o modelo

(20)

no Biancardi

20

• O controlador

_{O controlador}



Responsável pelas respostas às ações dos

usuários.



No caso de uma aplicação desktop, uma

ação de usuário (geralmente) é a solicitação

de uma consulta aos dados de um cliente.



O controlador é acionado pela Visão e vai

responder de acordo, fazendo com que o

Modelo manipule os dados necessários

(consulta o cliente no banco e monta o

objeto que o representa).

(21)



Estrutura

Modelo

Visão

Controle

Eventos

Invoca os métodos públicos

Invoca os métodos públicos para

pesquisa o estado do modelo

Estimula o sistema

Acessa a base de dados

Invoca Métodos

Notifica a Visão

(22)

no Biancardi

22

(23)



Onde colocar regras de negócio?

• A)No Controller, deixando o Model apenas como

_{A)No Controller, deixando o Model apenas como}

representação do negócio (objetos com get e

set)

• B)Fazer com que o Model seja representação do

_{B)Fazer com que o Model seja representação do}

negócio unido com as regras da aplicação

também (por exemplo, uma lógica de venda), e

o Controller fica encarregado apenas de

controlar o fluxo entre as camadas.



Dica: usar B.

(24)

no Biancardi

24



Desvantagens

• Complexidade adicional, só justificável

_{Complexidade adicional, só justificável}

em aplicações de médio e grande

porte.



Não é aconselhável para pequenas

aplicações.

• Requer uma quantidade maior de

_{Requer uma quantidade maior de}

tempo para analisar e modelar o

sistema.

(25)



Ver códigos:



MVC1

• http://www.dsc.ufcg.edu.br/~jacques/cursos/map

_{http://www.dsc.ufcg.edu.br/~jacques/cursos/map}

/html/arqu/mvc/mvc.htm

(26)

8.1 Transformação de

classes de análise em

classes de projeto

(27)

Especificação de classes de

fronteira



N

ão devemos atribuir a essas classes responsabilidades

relativas à lógica do negócio.

• Classes de fronteira devem apenas servir como um ponto de

_{Classes de fronteira devem apenas servir como um ponto de}

captação de informações, ou de apresentação de informações

que o sistema processou.

• A única inteligência que essas classes devem ter é a que

_{A única inteligência que essas classes devem ter é a que}

permite a elas realizarem a comunicação com o ambiente do

sistema.



Há diversas razões para isso

:

• Em primeiro lugar, se o sistema tiver que ser implantado em

_{Em primeiro lugar, se o sistema tiver que ser implantado em}

outro ambiente, as modificações resultantes sobre seu

funcionamento propriamente dito seriam mínimas.

• Além disso, o sistema pode dar suporte a diversas formas de

_{Além disso, o sistema pode dar suporte a diversas formas de}

interação com seu ambiente (e.g., uma interface gráfica e uma

interface de texto).

(28)

Especificação de classes de

fronteira



Durante a análise, considera-se que há uma única classe de

fronteira para cada ator.



No projeto, algumas dessas classes podem resultar em várias

outras.



Dois tipos:

• Interface com

Interface com

seres humanos:

seres humanos

:

projeto da interface gráfica

produz o

detalhamento das classes.

• Outros sistemas

_{Outros sistemas}

ou equipamentos

ou

equipamentos:

: devemos

devemos definir uma ou mais

definir uma ou mais

classes para encapsular o protocolo de comunicação.



É usual a definição de um

subsistema

para representar a comunicação

com outros sistemas de software ou com equipamentos.



É comum nesse caso o uso do padrão Façade (mais adiante)



O projeto de objetos de fronteira é altamente dependente da

natureza do ambiente...

(29)

Especificação de classes de

fronteira



Clientes WEB clássicos

• Classe

_C

lasses

s

de fronteira são

de fronteira

são representada

representadas

s

por páginas HTML que, m

por páginas HTML

que, m

uitas

vezes,

vezes, representam

representam sites

sites dinâmic

dinâmico

os

s.

.



Clientes móveis

• Classes de fronteira implement

C

lasses de fronteira implementa

am algum protocolo específico com o

m algum protocolo específico com o

ambiente.



Um exemplo é a WML (Wireless Markup Language).

_{Um exemplo é a WML (Wireless Markup Language).}



Clientes stand-alone

• Nesse caso, é recomendável que os desenvolvedores pesquisem os

Nesse caso, é recomendável que os desenvolvedores pesquisem os

recursos fornecidos pelo ambiente de programação sendo utilizado.



Um exemplo disso é o Swing/JFC da linguagem Java.

_{Um exemplo disso é o Swing/JFC da linguagem Java.}



Serviços WEB

(

WEB services

)

• Um serviço WEB é um uma forma de permitir que uma aplicação

Um serviço WEB é um uma forma de permitir que uma aplicação

forneça seus serviços (funcionalidades) através da Internet.

(30)

Especificação de classes de

entidade



A maioria das classes de entidade normalmente permanece na

passagem da análise ao projeto.

• Na verdade, classes de entidade são normalmente as primeiras classes

_{Na verdade, classes de entidade são normalmente as primeiras classes}

a serem identificadas, na

análise de domínio

.



Durante

o

projeto,

um

aspecto importante a considerar sobre

classes de entidade é identificar quais delas geram objetos que

devem ser

persistentes

.

• Para essas classes, o seu mapeamento para algum mecanismo de

_{Para essas classes, o seu mapeamento para algum mecanismo de}

armazenamento persistente deve ser definido

(mais adiante).

(mais adiante)

.



Um aspecto importante é a forma

de

representar associações,

agregações e composições entre objetos

de entidade

.

• Essa representação é função da

_{Essa representação é função da}

navegabilidade

e da multiplidade

e da

multiplidade

definidas para a associação (

(31)

Especificação de classes de

entidade



Outro aspecto relevante

para

classe

s

de entidade

é

modo como

podemos identificar cada um de seus objetos unicamente.

• Isso porque, principalmente em sistemas de informação, objetos de

_{Isso porque, principalmente em sistemas de informação, objetos de}

entidade devem ser armazenados de modo

persistente.

persistente

.

• Por exemplo, um objeto da classe Aluno é unicamente identificado pelo

Por exemplo, um objeto da classe Aluno é unicamente identificado pelo

valor de sua matrícula (um atributo do domínio).



A manipulação dos diversos atributos identificadores possíveis em

uma classes pode ser bastante trabalhosa.



Para evitar isso, um

identificador de implementação

é criado

,

que não tem correspondente com atributo algum do domínio.

• P

_P

ossibilidade de manipular identificadores de maneira uniforme e

eficiente.

(32)

Especificação de classes de

controle



Com relação às classes de controle, no projeto devemos identificar a real

utilidade das mesmas.

• Em casos de uso simples (e.g., manutenção de dados), classes de controle não

Em casos de uso simples (e.g., manutenção de dados), classes de controle não

são realmente necessárias.

• Neste caso, classes de fronteira podem repassar os dados fornecidos pelos

Neste caso, classes de fronteira podem repassar os dados fornecidos pelos

atores diretamente para as classes de entidade correspondentes. (não

Entretanto, é comum a situação em que uma classe de controle de análise

ser transformada em duas ou mais classes no nível de projeto.

• Objetivo

_Objetivo

: de evitar a criação de uma única classe com baixa coesão e

:

de evitar a criação de uma única classe com baixa coesão e

alto acoplamento.



No refinamento de qualquer classe proveniente da análise, aplicar padrões

de projeto (

(33)

Especificação de classes de

controle



Um tipo comum de controlador é o

controlador de caso

de uso

,

responsável pela coordenação da realização de um

caso de uso.



As

seguintes responsabilidades são esperadas de um

controlador de caso de uso:

• C

C

oordenar a realização de um caso de uso do sistema.

• S

_S

ervir como canal de comunicação entre objetos de fronteira e

objetos de entidade.

• S

_S

e comunicar com outros controladores, quando necessário.

• M

_M

apear ações do usuário (ou atores de uma forma geral) para

atualizações ou mensagens a serem enviadas a objetos de

entidade.

• E

_E

star apto a manipular exceções provenientes das classes de

entidades.

(34)

Especificação de classes de

controle



Alguns exemplos dos aspectos de uma aplicação

cuja coordenação é de responsabilidade das

classes de controle

:

• produção de valores para

_{produção de valores para}

preenchimento de controles

da interface gráfica,

• autenticação de usuários,

_{autenticação de usuários,}

(35)

Especificação de outras

classes

_classes



Além do refinamento de classes preexistentes, diversas

outros aspectos demanda a identificação de novas classe

durante o projeto.

• Persistência de objetos

_{Persistência de objetos}

• Distribuição e comunicação (e.g., RMI, CORBA, DCOM, WEB)

_{Distribuição e comunicação (e.g., RMI, CORBA, DCOM, WEB)}

• Autenticação/Autorização

_{Autenticação/Autorização}

• Logging

Logging

• Configurações

Configurações

• Threads

_Threads

• Classes para testes (

_{Classes para testes (}

Test Driven Development

)

• Uso de

_{Uso de}

bibliotecas

,

componentes

e

frameworks



Conclusão: a tarefa de identificação (reuso?) de classes

não

termina na análise.

(36)

Façade



Fachada



Provê uma interface unificada para um conjunto de classes em um

subsistema.



Define uma interface de nível mais alto para o subsistema,

tornando-o mais fácil de ser usado.



Facilita o trabalho em subsistemas pois são fornecidas as

interfaces de cada subsistema.

• Facilita a utilização do sistema: Cliente só precisa conhecer a fachada.

_{Facilita a utilização do sistema: Cliente só precisa conhecer a fachada.}



Promove acoplamento fraco:

• Pequenas mudanças no subsistema não mais afetam o cliente.

_{Pequenas mudanças no subsistema não mais afetam o cliente.}

• A manutenção também é facilitada!!!

_{A manutenção também é facilitada!!!}



Facade serve para abstrair complexas chamadas de métodos em

diversos componentes, facilitando o acesso a um conjunto

funcionalidades agrupadas. Ele permite que você consiga criar

uma interface de simples acesso ao sistema, de fora pra dentro.

(37)



Problema:

• Existem circunstâncias onde é necessário

_{Existem circunstâncias onde é necessário}

utilizar diversas classes diferentes para que

uma tarefa possa ser completada.

• Caracteriza uma situação onde uma classe

_{Caracteriza uma situação onde uma classe}

cliente necessita utilizar objetos de um

conjunto específico de classes utilitárias que,

em conjunto, compõem um subsistema

particular ou que representam o acesso a

diversos subsistemas distintos.

(38)

no Biancardi

38

(39)



Solução

• O

_O

Facade

é um padrão que pode apresentar infinidades

de formas de representá-lo.

• O que importa para este padrão é que o Cliente apenas

_{O que importa para este padrão é que o Cliente apenas}

acesse objetos da classe

Facade

, esperando algum

resultado vindo dela.

• A classe

_{A classe}

Facade

é que terá a responsabilidade de entrar

em contato com as diversas instâncias dentro deste

sistema, efetuar possíveis cálculos vindos de classes

abaixo dela e retornar as respostas que o cliente pediu.

(40)

no Biancardi

40

(41)

(42)

no Biancardi

42

(43)



Implementação:

• _{Implementar um}

_{Implementar um}

_Facade

_demanda

definir um conjunto de operações

reduzidas que permita ocultar a

complexidade inerente à utilização de

várias classes de um subsistema.

(44)

no Biancardi

44



Exemplo:

• O cliente necessita consultar várias entidades a fim de saber

_{O cliente necessita consultar várias entidades a fim de saber}

se têm condições de receber um empréstimo. Para isso,

normalmente, o cliente teria que conhecer toda a

complexidade envolvida com as regras de concessão de

empréstimos e aprende-las, no entanto, nada melhor do que

deixar isso a cargo de quem já está no sistema, no caso o

Facade

, que irá se preocupar em colher dados das diferentes

classes que podem decidir sobre a possibilidade do

empréstimo e retornará esta informação pronta para o

cliente.

• FacadeApp

FacadeApp

é o cliente que busca informações que podem vir

de vários de subsistemas,

Facade

é a classe responsável por

acessar os subsistemas e trazer respostas de forma

transparente a quem esteja acessando o

Facade

.

Banco

,

Emprestimo

,

Crédito

e

Consumidor

são classes pertencentes

aos subsistemas.

(45)

(46)

no Biancardi

46

(47)

/* Complex parts */ class CPU {

public void freeze() { ... }

public void jump(long position) { ... } public void execute() { ... }

}

class Memory {

public void load(long position, byte[] data) { ...

} }

class HardDrive {

public byte[] read(long lba, int size) { ...

} }

/* Facade */

class ComputerFacade {

public void startComputer() { cpu.freeze();

memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR, SECTOR_SIZE)); cpu.jump(BOOT_ADDRESS); cpu.execute(); } } /* Client */ class You {

public static void main(String[] args) {

ComputerFacade facade = new ComputerFacade (); facade.startComputer();

} }

(48)

no Biancardi

48



Persistência em Bancos de Dados

Relacionais

• Apresentação:

_{Apresentação:}



5.2 - Mapeamento de objetos para o

modelo relacional - Cap12

(49)

MVC Estendido

• A arquitetura MCV é um bom ponto de

_{A arquitetura MCV é um bom ponto de}

partida.

• Contudo, ela desconsidera um

_{Contudo, ela desconsidera um}

importante componente: a gerência de

dados.

• Evolução do MVC:

_{Evolução do MVC:}

(50)

no Biancardi

50

Duas formas complementares de agrupamento de classes em

pacotes:

•Pelo domínio do problema: aproveitando os

subsistemas definidos na fase de análise => Arquitetura

do Sistema

•Por estereótipos, tendo sido utilizados os estereótipos

propostos por Coad e Yourdon [Coad93].

Atendimento Cliente

Controle Acervo

Utilitario

pacote Utilitario, trata classes

reutilizáveis em outros contextos

(51)

• Componente do Domínio do Problema (Model)

_{Componente do Domínio do Problema (Model)}

:



corresponde aos subsistemas responsáveis por implementar

diretamente os requisitos dos usuários; (classe de análise)

• Componente de Interação Humana (View)

_{Componente de Interação Humana (View)}

:



corresponde aos subsistemas que implementam as interfaces

com o usuário; (interface gráfica, texto)

• Componente de Gerência de Tarefa (Controll)

_{Componente de Gerência de Tarefa (Controll)}

:



corresponde aos subsistemas responsáveis por controlar e

coordenar tarefas; (casos de uso)

• Componente de Gerência de Dados

_{Componente de Gerência de Dados}

:



corresponde aos subsistemas responsáveis pelo

armazenamento e recuperação de objetos (persistência dos

objetos). (gravação em meio secundário – BD, arquivo texto)

(52)

no Biancardi no Biancardi 52 52 DP_Controle Acervo GD_Controle Acervo IU_Controle Acervo UtilitarioPessoa (from Utilitario) GT_ControleAcervo UtilitarioInterfaceGrafica (from Utilitario)

(53)

Uso do p

adrão DAO

_{adrão DAO}



O padrão DAO é uma forma de desacoplar as classes do negócio dos

aspectos relativos ao acesso e ao armazenamento persistente.

• DAO:

DAO

:

Data Access Object

(Objeto de Acesso a Dados).



Nessa estratégia

, um

SSOO

obtém acesso a objetos de negócio

através de uma interface, a chamada

interface DAO

.

• Classes que implementam essa interface transforma

_{Classes que implementam essa interface transforma}

m

informações

provenientes do mecanismo de armazenamento em objetos de negócio

,

e vice-versa

.



O SSOO

interage com o

objeto DAO

através de uma interface.

• A implementação desse objeto simplesmente não faz diferença para a

_{A implementação desse objeto simplesmente não faz diferença para a}

aplicação.

• O objeto DAO isola completamente os seus clientes das particularidades

O objeto DAO isola completamente os seus clientes das particularidades

d

(54)

no Biancardi

54

Uso do p

adrão DAO

_{adrão DAO}

(55)

Uso do p

adrão DAO

_{adrão DAO}

public interface AlunoDAO

{

public void inserir(Aluno aluno)

throws AlunoDAOException;

public void atualizar(Aluno aluno)

throws AlunoDAOException;

public void remover(Aluno aluno)

throws AlunoDAOException;

public List<Aluno> encontrarTodos() throws AlunoDAOException;

public

Aluno

encontrarPorMatricula(String

matricula)

throws

AlunoDAOException;

public List<Aluno> encontrarPorTurma(int idTurma) throws AlunoDAOException;



Exemplo em linguagem Java de uma

InterfaceDAO

(56)

no Biancardi

56

(57)

(58)

no Biancardi

58

(59)

(60)

no Biancardi

60

(61)

(62)

no Biancardi

62



Outro exemplo de estrutura DAO:

BaseSombra

{abstract} -expressao campos parametros camposParametros expressaoAtualiza criterio ordem tabela : String : String : String : String : String : String : String : String + + + + + + + + + + + + + + + setCriterio () setOrdem () setTabela () montaInstConsulta () montaInstConsultaQtd () montaInstAlterar () montaInstIncluir () executeInstSQLUpdate () executeInstSQLConsulta () abstract adicionaCampos () adicionaCamposCod () adicionaCamposCons () abstract adicionaParametros () abstract adicionaCamposParametros () adicionaParametrosCod () : v oid : v oid : v oid : v oid : v oid : v oid : v oid : v oid : ResultSet : v oid : v oid : v oid : v oid : v oid : v oid

Conexao

-conexao driv er nome senha url usuario : Connection : String : String : String : String : String + + + conectar () desconectar () getStatement () : v oid : v oid : Statement

(63)

<<from Uti l i tari o.Persistenci a>> BaseSombra {abstract} -expressao campos parametros camposParametros expressaoAtualiza criterio ordem tabela : String : String : String : String : String : String : String : String + + + + + + + + + + + + + + + setCriterio () setOrdem () setTabela () montaInstConsulta () montaInstConsultaQtd () montaInstAlterar () montaInstIncluir () executeInstSQLUpdate () executeInstSQLConsulta () abstract adicionaCampos () adicionaCamposCod () adicionaCamposCons () abstract adicionaParametros () abstract adicionaCamposParametros () adicionaParametrosCod () : v oid : v oid : v oid : v oid : v oid : v oid : v oid : v oid : ResultSet : v oid : v oid : v oid : v oid : v oid : v oid MDCampoGlobalSombra + inserir (CampoGlobal mdCampoGlobal) : v oid

MDTabGlobalSombra + + + + + +

inserir (MDTabGlobal mdTabGlobal) consultar (int codTalGlobal)

consulta (String nome)

alterar (MDTabelaGlobal mdTabGlobal) remov er (int codTabGlobal)

consultarTodas () : v oid : MDTabGlobal : MDTabGlobal : v oid : v oid : Array List FonteDeDadosSombra + + + + + +

inserir (FonteDeDados f onteDeDados) consultar (int codFD)

consultar (String nomeFD)

alterar (FonteDeDados f onteDeDados) remov er (int codFD)

consultarTodas () : v oid : FonteDeDados : FonteDeDados : v oid : v oid : Array List MapeamentoTabSombra + + + + +

inserir (MapeamentoTabela mapeamentoTabela) consultar (int codTabGlobal, int codFD)

consultar (int codTabLocal)

alterar (MapeamentoTabela mapeamentoTabela) remov er (int codTabLocal)

: v oid : MapeamentoTabela : MapeamentoTabela : v oid : v oid MDTabLocalSombra + + + + + +

inserir (MDTabLocal mdTabLocal) consultar (int codTalLocal)

consultar (String nome, int codFD) alterar (MDTabelaLocal mdTabLocal) remov er (int codTabLocal)

consultarTodas (int codFD)

: v oid : MDTabLocal : MDTabLocal : v oid : v oid : Array List MDCampoLocalSombra + +

inserir (MDCampoLocal mdCampoLocal) consultar (int codCampoLocal)

: v oid : MDCampoLocal MapeamentoCampoSombra + + + + +

inserir (MapeamentoTabela mapeamentoCampo) consultar (int codCampoGlobal, int codFD) consultar (int codCampoLocal)