• Nenhum resultado encontrado

Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais

N/A
N/A
Protected

Academic year: 2021

Share "Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais"

Copied!
102
0
0

Texto

(1)

Especialização em web com interfaces

ricas

Padrões de Projeto - Estruturais

Prof. Fabrízzio Alphonsus A. M. N. Soares

fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática

Universidade Federal de Goiás

Aula 8 25 de maio de 2012

(2)

Padrões de Projeto - Estruturais I

Padrões de projeto estruturais são padrões que lidam com as estruturas do projeto, facilitando a comunicação entre suas enti-dades. Por enquanto, esse conceito permanecerá abstrato, mas de acordo com os padrões deste tipo, entenderemos melhor.

(3)

Padrões de Projeto - Estruturais II

Em resumo, estes padrões, em outras palavras cuidam da estru-tura de seu projeto. Por outro lado padrões estruestru-turais devem ser aplicados em classes responsáveis pela estrutura dos domí-nios, fazendo uma analogia com a engenharia civil, eles seriam responsáveis por definir o alicerce da construção bem como a estrutura para sustentá-la.

(4)

Padrões de Projeto - Estruturais III

Lista de padrões estruturais Adapter Bridge Composite Decorator Façade Flyweight

(5)

Padrão Adapter I

Adapter, também conhecido como Wrapper, é um padrão de projeto de software (do inglês design pattern).

Este padrão é utilizado para “adaptar” a interface de uma classe.

(6)

Padrão Adapter II

O Adapter permite que classes com interfaces incompatíveis possam interagir.

Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de uma interface única.

(7)

Padrão Adapter III

O principal objetivo do Adapter é facilitar a conversão da inter-face de uma classe para outra interinter-face mais interessante para o cliente, fazendo com que várias classes possam trabalhar em conjunto independentemente das interfaces originais.

(8)

Padrão Adapter IV

Às vezes é preciso modificar uma classe que não pode ser al-terada adequadamente devido à falta do código fonte (alguma biblioteca comercial de classes), ou por alguma outra razão.

(9)

Padrão Adapter V

O Adapter é uma das formas de modificar classes nestas cir-cunstâncias, sendo classificado com a de finalidade estrutural e abrange tanto escopo de classe quanto de objeto.

(10)

Motivação I

Uma classe já existente e sua interface não combinam com a esperada pelo cliente;

Se quer criar uma classe reutilizável que coopera com classes não relacionadas ou não previstas, isto é, classes que não necessariamente tenham interfaces compatíveis; Se necessita usar várias subclasses existentes, mas é impraticável adaptar suas interfaces fazendo um Subclassing de cada uma.

(11)

Aplicabilidade I

Desejar usar uma classe existente e sua interface não corresponde ao que você precisa;

Desejar criar uma classe reutilizável que coopera com classes imprevistas ou não relacionáveis, isto é, classes que não tem necessariamente interfaces compatíveis.

(12)
(13)

Estrutura II

Participantes

Cliente Colabora entre os objetos conforme a interface Alvo.

Alvo Define a interface de domínio específico que o

Cliente utiliza.

Adaptador Adapta a ClasseExistente para ser utilizada pela classe Alvo.

ClasseExistente Define uma interface pré-existente que necessita ser adaptada.

(14)

Vantagens

Adapta o Adaptador para o Alvo através de uma classe concreta. Como consequência, uma classe adaptada não funcionará para adaptar uma classe e suas subclasses. Deixa o Adaptador sobrepor algum comportamento do adaptado, desde que o Adaptador seja uma subclasse do adaptado.

Introduz um único objeto e nenhum ponteiro adicional é necessário para chegar ao adaptado

(15)

Exemplo

Usou-se como exemplo (adaptado [Software Design Patterns, 2005]), ilustrado na Figura 2, uma implementação que demons-tra o uso de um banco de dados químico legado.

Objetos da classe CompostoQuimico acessam o banco de dados através de uma interface que utiliza o Padrão Adapter.

(16)

Padrão Bridge I

Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é desejável que uma interface (abstra-ção) possa variar independentemente das suas implementações.

(17)

Padrão Bridge II

Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas.

Neste sistema são encontrados diversos tipos de janelas, como ícones, diálogos, etc.

Estas janelas formam uma hierarquia que contém uma abstração das janelas (classe base).

Normalmente, a portabilidade seria obtida criando-se especia-lizações dos tipos de janelas para cada uma das plataformas suportadas.

O problema com essa solução reside na complexidade da hie-rarquia gerada e na dependência de plataforma que existirá nos clientes do sistema.

(18)

Padrão Bridge III

Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquia que contém a implementação. Desta forma todas as operações de Janela são abstratas e suas implementações são escondidas dos clientes.

(19)

Propósito

Desacopla uma abstração de sua implementação de maneira que ambas possam variar independentemente.

(20)

Motivação

O que motiva a utilização do padrão Bridge é a necessidade de um driver, permitindo implementações específicas para tratar objetos em diferentes meios persistentes.

(21)

Aplicabilidade

Use o Padrão de Projeto Bridge quando:

Quando for necessário evitar uma ligação permanente entre a interface e a implementação.

Quando alterações na implementação não puderem afetar clientes.

Quando implementações são compartilhadas entre objetos desconhecidos do cliente.

(22)
(23)

Estrutura II

Participantes

Abstração Define a interface de abstração. Mantém uma referência a um objeto do tipo Implementador.

AbstracãoRefinada Estende a interface definida por Abstração.

Implementador Define a interface para classes de

implementação. Esta não tem a obrigação de corresponder exatamente à interface de

abstração. De fato, as duas interfaces podem ser bastante diferentes. Tipicamente, a interface de implementação fornece apenas operações primitivas, cabendo à abstração a

responsabilidade de definir operações de alto nível baseadas nestas primitivas.

(24)

Estrutura III

ImplementadorConcretoA e implementadorComcretoB

Implementação concreta da interface definida por Implementador.

(25)

Vantagens I

Detalhes de implementação totalmente inacessíveis aos clientes.

Eliminação de dependências em tempo de compilação das implementações.

Implementação de abstração pode ser configurada em tempo de execução.

(26)

Implementação I

A implementação (adaptado [Software Design Patterns, 2005]) do Padrão Bridge ilustra a Ponte entre a classe abstrata Obeto-Negocios a ClienteDadosObjeto através de interface DadosOb-jeto. A interface DadosObjeto não é igual a ObjetoNegocios, já que não existe necessária dependência entre elas.

(27)

Implementação II

Este exemplo demonstra desacoplamento de uma abstração de ObjetoNegocio da implementação em DadosObjeto. As imple-mentações de DadosObjeto podem evoluir dinamicamente sem propagar mudanças a nenhum dos objetos cliente, isso pode ser verificado na figura 2.

(28)

Implementação III

Na classe ClienteDadosObjeto encontra-se a implementação que a classe cliente espera através da DadosObjeto, neste caso, ela contém algumas pessoas cadastradas, ela pode adicionar novas pessoas em determinado grupo ou mostrá-las. Para interagir en-tre os cadastros utiliza-se o Padrão Iterator, que será detalhado nos próximos Padrões.

(29)

Implementação IV

(30)

Padrão composite I

Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela composição de objetos similares a ele.

Neste padrão, o objeto composto possui um conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence.

O padrão composite é normalmente utilizado para representar listas recorrentes - ou recursivas - de elementos.

(31)

Padrão composite II

Além disso, esta forma de representar elementos compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto.

Desta forma, todos os métodos comuns às classes que repre-sentam objetos atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.

(32)

Aplicação I

Utilizado sempre que é necessário representar elementos que são compostos por outros elementos similares.

(33)

Exemplo I

Por exemplo, em interfaces gráficas um elemento gráfico pode ser constituído pela composição de vários outros elementos grá-ficos. Uma janela pode conter um ou mais ícones, uma caixa de texto e vários outros elementos gráficos - até mesmo outra janela.

(34)

Exemplo II

Considerando que uma determinada hierarquia de classes in-dicasse ElementoGráfico como a super-classe comum a todas classes que representassem os elementos gráficos atômicos, a classe Janela seria representada como uma classe que contém zero (0) ou mais elementos gráficos.

(35)

Motivação I

Aplicações gráficas como editores de desenho e sistemas de captura de esquema deixam os usuários construírem diagramas complexos a partir de Componentes simples. O usuário pode agrupar Componentes para formar Componentes maiores, que, por sua vez, podem ser agrupados para formar Componentes maiores ainda. O Padrão Composite descreve como usar com-posição recursiva, de modo que os clientes não tenham que fazer distinção entre componentes simples e composições.

(36)

Motivação II

Use o Padrão de Projeto Bridge quando:

Quiser representar hierarquias parte-todo de objetos; Deseja que os clientes sejam capazes de ignorar as diferenças entre composição de objetos e objetos individuais. Clientes tratarão todos os objetos uniformemente na estrutura Composite.

(37)

Estrutura I

(38)

Estrutura II

Componente Declara a interface para objetos na composição; Implementa comportamento default para

interface comum a todas as classes, como

apropriado; Declara uma interface para acessar ou gerenciar seus Componentes filhos;

Folha Representa objetos folhas na composição. Uma folha não tem filhos; Define comportamento para objetos primitivos na composição.

Composição Define comportamento para Componentes que

têm filhos; Armazena Componentes filhos;

(39)

Consequencias I

Vantagens

Define a consistência das hierarquias de classes de objetos primitivos e objetos composição.

Clientes podem tratar estruturas compostas e objetos individuais uniformemente. Clientes normalmente não sabem (e não deveriam se preocupar) se eles estão tratando com uma folha ou uma composição;

Torna mais fácil adicionar novos tipos de Componentes. Novas composições ou subclasses. Folhas trabalham automaticamente com estruturas existentes e código do cliente. Clientes não têm que ser mudados para novas classes de Componentes.

(40)

Consequencias II

Desvantagem

Quando uma composição tem apenas alguns

Componentes, você terá de usar uma checagem em tempo de execução para isto.

(41)

Exemplo I

Este exemplo (adaptado [Software Design Patterns, 2005]) do padrão Composite representa uma simulação de sua funcionali-dade propriamente dita, ele foi retirado e adaptado do site.

(42)

Exemplo II

É apresentado através na classe Tela dois botões para mostrar todas as folhas e componentes e outro simplesmente para lim-par.

Também se utiliza o padrão para construir uma estrutura de árvore gráfica composta de nós primitivos (estes nós podem ser substituídos por linhas, círculos, etc) e nós compostos (grupos de elementos que formam elementos mais complexos).

(43)

Exemplo III

Assim sendo verifica-se que a classe Folha representa os nós primitivos, ou seja, elas não possuem nenhuma classe folha. A classe Componente apenas possui os atributos e métodos comuns a todos seus filhos (ou folhas).

(44)
(45)

Padrão Decorator I

Atribui responsabilidade adicionais a um objeto dinamicamente. O Decorator fornece uma alternativa flexível a subclasses para a extensão da funcionalidade.

(46)

Propósito I

Agregar responsabilidades adicionais a um objeto dinamicamente. Classes decoradoras oferecem uma alternativa flexível ao uso de herança para estender uma funcionalidade [Silva, 2005].

(47)

Motivação I

Adicionar responsabilidades a um objeto, mas não à sua classe. Acontece, por exemplo, com criação de interfaces gráficas, quando se deseja acrescentar uma borda a um componente qualquer ou uma barra de rolagem a uma área de texto. Uma abordagem mais flexível é inserir o componente em outro objeto que adici-ona a borda, um Decorator [Silva, 2005].

(48)

Aplicabilidade I

Utilizado para adicionar responsabilidades a objetos individuais de forma dinâmica e transparente, isto é, sem afetar outros obje-tos, da mesma forma, quando se quer retirar responsabilidades.

(49)

Aplicabilidade II

Quando a utilização de heranças para a implementação do mesmo afetará a flexibilidade do sistema.

(50)

Aplicabilidade III

Um caso de aplicação do Decorator é quando existem muitas variações de um objeto. Imagine por exemplo uma classe Janela com uma subclasse JanelaComBorda. Se houver a necessidade também de janelas com rolagem, tem-se ainda JanelaComRo-lagem e JanelaComBordaERoJanelaComRo-lagem [Faerman, 2005], além de outras possíveis combinações, já que poderia haver menus, bo-tões ou barra de status.

(51)

Aplicabilidade IV

Usando o Decorator, tem-se um número muito menor de sub-classes: Janela, DecoratorJanela, DecoratorJanelaBorda, Deco-ratorJanelaRolagem, DecoratorJanelaMenu, e assim por diante [Faerman, 2005].

(52)

Estrutura I

Esse padrão providencia que cada objeto Decorator contenha outro objeto Decorator.

Nesse aspecto, um decorator é como um pequeno composite cujos elementos possuem cada qual um filho único.

Diferentemente do padrão Composite, cujo propósito é compor objetos agregados, o propósito do Decorator é compor compor-tamentos.

(53)

Estrutura II

Estruturalmente, o padrão Decorator dispõe as classes em um hierarquia e distribui operações ao longo dela.

Cada classe dessa hierarquia tipicamente tem um construtor que precisa de outra instância de uma classe dela.

As classes Decorator tipicamente implementam suas operações por meio da dependência do objeto decorador que recebem em seus construtores [Metsker, 2004].

(54)
(55)

Estrutura IV

Participantes

Componente define a interface para objetos que podem ter responsabilidades acrescentadas a eles

dinamicamente.

ComponenteConcreto define um objeto para o qual

responsabilidades adicionais podem ser atribuídas

Decorator mantém uma referência para um objeto

Componente. Define uma interface que segue a interface de Componente.

DecoratorConcretoA e DecoratorConcretoB acrescenta responsabilidades ao componente

(56)

Vantagens I

Fornece uma flexibilidade maior do que a herança estática. Evita a necessidade de colocar classes sobrecarregadas de recursos em uma posição mais alta da hierarquia.

Simplifica a codificação permitindo que você desenvolva uma série de classes com funcionalidades específicas, em vez de codificar todo o comportamento no objeto. Aprimora a extensibilidade do objeto, pois as alterações são feitas codificando novas classes.

(57)

Exemplo de implementação I

(58)

Exemplo de implementação II

O exemplo ilustrado na Figura, visa gerar janelas com caracte-rísticas que podem variar de uma janela para outra.

(59)

Exemplo de implementação III

Por exemplo, o cliente pode decidir entre construir uma janela com barra de menus ou não. Desta forma consegue-se aumentar o número de possibilidades de janelas diferentes apresentadas com um pequeno número de classes.

(60)

Exemplo de implementação IV

Neste exemplo, a interface Janela recebe o papel de ser o Com-ponente da estrutura apresentada anteriormente.

(61)

Exemplo de implementação V

Por sua vez, JanelaComum interpreta o ComponenteConcreto, ou seja, é ele que receberá as modificações no decorrer da exe-cução da aplicação. Como o próprio nome diz, o Decorator assume a finalidade do Decorator da estrutura padrão.

(62)

Exemplo de implementação VI

JanelaMenuBar, JanelaBorda, JanelaBarraStatus e JanelaBar-raFerramenta herdam de Decorator, ou seja, são os n decora-dores concretos.

(63)

Padrão Façade I

Em padrões de projeto de software, um façade (fachada em francês) é um objeto que disponibiliza uma interface simplificada para uma das funcionalidades de uma API, por exemplo.

(64)

Padrão Façade II

Um façade pode:

tornar uma biblioteca de software mais fácil de entender e usar;

tornar o código que utiliza esta biblioteca mais fácil de entender;

reduzir as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema;

(65)

Padrão Façade III

Os façades são muito comuns em projeto orientados a objeto. Por exemplo, a biblioteca padrão da linguagem Java contém dúzias de classes para processamento do arquivo fonte de um caractere, geração do seu desenho geométrico e dos pixels que formam este caractere.

(66)

Padrão Façade IV

Entretanto, a maioria dos programadores Java não se preocu-pam com esses detalhes, pois a biblioteca contém as classes do tipo façade (Font e Graphics) que oferecem métodos simples para as operações relacionadas com fontes.

(67)

Propósito I

Oferecer uma interface única para um conjunto de interfaces de um subsistema.

Definir uma interface de nível mais elevado que torna o subsistema mais fácil de usar [Silva, 2005].

Reduzir a complexidade do relacionamento entre uma classe relativa ao cliente e as demais classes utilitárias [Junior, 2004].

(68)

Motivação I

Uma grande vantagem da programação orientada a objetos é que ela ajuda a evitar que as aplicações se tornem programas monolíticos, com pedaços incorrigivelmente entrelaçados.

(69)

Motivação II

No entanto, a aplicabilidade variada das classes em um subsis-tema orientado a objetos pode oferecer uma variedade expres-siva de opções [Metsker, 2004].

(70)

Motivação III

Existem circunstâncias onde é necessário utilizar diversas classes diferentes para que uma tarefa possa ser completada, caracte-rizando 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 represen-tam o acesso a diversos subsistemas distintos.

(71)

Motivação IV

(72)

Aplicabilidade I

Criação de interfaces mais simples para um ou mais subsistemas complexos.

Redução de dependência entre o cliente e as classes existentes nos subsistemas, ocasionando a redução da coesão do sistema

Criação de sistemas em camadas. Este padrão provê o ponto de entrada para cada camada (nível) do

(73)

Estrutura I

A estrutura deste padrão é bastante simples.

A classe que constituirá o Facade deverá oferecer um conjunto de operações que sejam suficientes para que seus clientes pos-sam utilizar adequadamente o subsistema, embora sem conhecer as interfaces de seus componentes.

(74)

Estrutura II

O Facade é um padrão que pode apresentar infinidades de for-mas de representá-lo.

O que importa para este padrão é que o Cliente apenas acesse objetos da classe Facade, esperando algum resultado vindo dela.

(75)

Estrutura III

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.

(76)
(77)

Estrutura V

Participantes

Cliente aguarda respostas da interação do Facade e as Classes do subsistema.

Facade conhece quais classes do subsistema seriam responsáveis pelo atendimento de uma solicitação e delega solicitações de clientes a objetos

apropriados dos subsistemas.

Classes de subsistema (ClasseA, ..., ClasseB)

Implementam as funcionalidades do subsistema.

Respondem a solicitações de serviços da Facade.

Não têm conhecimento da Facade.

(78)

Vantagens I

Protege os clientes da complexidade dos componentes do subsistema;

Promove acoplamento fraco entre o subsistema e seus clientes;

Reduz dependências de compilação, possivelmente complexas ou circulares;

Facilita a portabilidade do sistema [Junior, 2004]; Reduz a união entre subsistemas desde que cada subsistema utilize seu próprio padrão Facade e outras

(79)

Vantagens II

Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem [Junior, 2004];

(80)

Implementação I

Implementar um Facade demanda definir um conjunto de ope-rações reduzidas que permita ocultar a complexidade inerente à utilização de várias classes de um subsistema (adaptado [Soft-ware Design Patterns, 2005]).

(81)

Implementação II

(82)

Implementação III

Neste exemplo, 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és-timos 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.

(83)

Implementação IV

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.

(84)

O padrão Flyweight I

Flyweight é um padrão de projeto de software apropriado quando vários objetos devem ser manipulados, e esses não suportam dados adicionais. No padrão flyweight não existem ponteiros para os métodos do dado, pois isto consome muita memória. Em contrapartida são chamadas sub-rotinas diretamente para acessar o dado.

(85)

Propósito I

Utilizar compartilhamento para suportar eficientemente um grande número de objetos com estado reduzido

(86)

Motivação I

Em um editor de textos certas vantagens são obtidas as representar cada caractere como objeto

Entretanto, seria necessário a instanciação de um número consideravelmente alto de objetos, com consumo

(87)

Motivação II

Um flyweight é um objeto compartilhado que pode ser utilizado simultaneamente em múltiplos contextos

Atua como um objeto independente em cada contexto, de modo que os clientes não são cientes do

compartilhamento

O conceito chave é a distinção entre estado intrínseco e estado extrínseco:

O estado intrínseco é armazenado no flyweight e consiste de informações independentes do contexto e, portanto, compartilháveis

O estado extrínseco depende de e varia com o contexto e, portanto, não pode ser compartilhado. Os clientes são responsáveis por passar o estado extrínseco para o flyweight, quando necessário

(88)

Problema exemplo I

Desenvolver um editor de texto onde cada caractere é represen-tado por um objeto:

Granularidade muito pequena;

Não haverá recursos (memória) suficiente para textos grandes.

(89)

Solução I

Monta-se um pool de objetos compartilhados;

Cada caractere tem um objeto. Com 100 objetos (tabela ASCII) poderíamos montar textos de qualquer tamanho.

(90)
(91)

Usar este padrão quando? I

Todas as condições forem verdadeiras:

A aplicação usa um grande número de objetos; O custo de armazenamento é alto por causa desta quantidade;

O estado dos objetos pode ser externalizado;

Objetos podem ser compartilhados assim que seu estado é externalizado;

A aplicação não depende da identidade.

(92)

Consequencias

Custo x benefício:

Custo de recuperar o objeto compartilhado e transferir seu estado externalizado;

(93)

Padrão Proxy I

Um proxy, em sua forma mais geral, é uma classe que funciona como uma interface para outra classe. A classe proxy poderia conectar-se a qualquer coisa: uma conexão de rede, um objeto grande em memória, um arquivo, ou algum recurso que é difícil ou impossível de ser duplicado.

(94)

Padrão Proxy II

Um exemplo bem conhecido do padrão proxy é um objeto pon-teiro de referência de contagem.

(95)

Padrão Proxy III

Em situações onde múltiplas cópias de um objeto complexo deve existir o padrão proxy pode ser adaptado para incorporar o padrão flyweight a fim de reduzir o rastro de memória das aplicações. Normalmente uma instância de um objeto complexo é criada e vários objetos proxies são criados, todos contendo uma referência ao único objeto complexo original.

(96)

Padrão Proxy IV

Quaisquer operações realizadas nos proxies são enviadas ao ob-jeto original. Uma vez que todas as instâncias do proxy esti-verem fora do escopo, a memória do objeto complexo pode ser desalocada.

(97)

Descrição I

Intenção:

Prover um representante ou ponto de acesso que controle o acesso a um objeto.

Também conhecido como: Surrogate.

(98)

O problema I

Considere um editor de texto multimídia (texto e imagens): Carregar todas as imagens do texto assim que ele é aberto pode demorar;

Nem todas as imagens aparecem na primeira página, muitas estão “escondidas” mais abaixo.

(99)

Solução I

Documento instancia um objeto proxy, que possui referência à imagem;

Assim que necessário, proxy carrega a imagem - lazy loading.

(100)
(101)

Usar este padrão quando? I

precisar de um acesso mais versátil a um objeto do que um ponteiro:

Remote proxy (acesso remoto); Virtual proxy (exemplo da imagem); Protection proxy (controla acesso).

(102)

Consequencias I

Adiciona um nível de separação:

Transparência na execução de ações de carregamento de objetos.

Referências

Documentos relacionados

- Se o estagiário, ou alguém com contacto direto, tiver sintomas sugestivos de infeção respiratória (febre, tosse, expetoração e/ou falta de ar) NÃO DEVE frequentar

c.4) Não ocorrerá o cancelamento do contrato de seguro cujo prêmio tenha sido pago a vista, mediante financiamento obtido junto a instituições financeiras, no

[r]

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição

Reconhecimento de face utilizando banco de imagens monocromáticas e coloridas através dos métodos da análise do componente principal (PCA) e da Rede Neural Artificial (RNA)

Os resultados mostraram que a cinética de secagem do yacon é fortemente influenciada pela temperatura e também pela PVOD, com menor tempo de processo e maior

Se você tiver, no mínimo, três anos de vinculação ao Plano, terá direito ao Benefício Proporcional Diferido (BPD), que consiste em manter o saldo de Conta de

• Capacitação e Transferência da metodologia do Sistema ISOR ® para atividades de Coaching e/ou Mentoring utilizando o método das 8 sessões;.. • Capacitação e Transferência