Palmas - TO2012

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

SISTEMA DE ENSINO PRESENCIAL CONECTADOTECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL

Palmas - TO2012

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL

Trabalho apresentado ao Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR

Professores: Polyanna Pacheco GomesRoberto Y. NishimuraMarcio ChiaveliMerris Mozer

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

SUMÁRIO

1 INTRODUÇÃO 3

2 LISTAS LINEARES 4

2.1 FIFO 4

2.1.1 Aplicações FIFO 4

2.1.2 Vantagens e Desvantagens do FIFO 5

2.2 FILO 5

2.3 ALOCAÇÃO SIMPLISMENTE ENCADEADA 6

2.3.1 Exemplos de algoritmos para as operações de inserção e retirada de um

elemento numa pilha com alocação contígua: 6

2.3.2 Exemplo de algoritmo para a operação de inserção de um elemento numa

fila com alocação contígua: 7

2.3.3 Exemplo de algoritmo para a operação de retirada de um elemento numa

fila com alocação contígua: 7

2.4 ALOCAÇÃO DUPLAMENTE ENCADEADA 8

2.4.1 Implementação de Algumas Operações de Lista Duplamente Encadeada

Com Alocação Dinâmica 8

2.4.1.1 Inserção à direita de pont 9

2.4.1.2 Inserção à esquerda de pont 9

2.4.1.3 Eliminação à direita de pont 10

2.4.1.4 Eliminação do próprio pont 10

2.4.1.5 Busca em uma lista circular 10

3 ACID 12

3.1 TRANSAÇÕES 12

3.2 ATOMICIDADE 12

3.3 CONSISTÊNCIA 12

3.4 ISOLAMENTO 12

3.5 DURABILIDADE 13

3.6 IMPORTÂNCIA DO ACID PARA UM SGBD 13

4 BANCO DE DADOS RELACIONAL COM A PROGRAMAÇÃO ORIENTADA A

OBJETOS 14

4.1 ORIENTAÇÃO A OBJETOS VS MODELO ENTIDADE RELACIONAMENTO

14

5 OBJECT RELATIONAL MAPPING (ORM) – MAPEAMENTO DE OBJETO

RELACIONAL 15

5.1 FERRAMENTAS PARA FAZER ORM (OBJECT RELATIONAL MAPPING)

18

5.1.1 JPA e Hibernate 18

6 HERANÇA E POLIMORFISMO 19

6.1 HERANÇA 19

6.1.1 Diagrama de Classe (Herança) 19

6.2 POLIMORFISMO 20

6.2.1 Diagrama de Classe (Polimorfismo) 21

7 CONCLUSÃO 22

REFERÊNCIAS 23

1 INTRODUÇÃO

Neste trabalho será abordada toda a matéria do 3º Semestre, dentro

deste contexto serão apresentados os conceitos de listas lineares, FIFO, FILO, seus

apontadores, ordens de inclusão, exclusão e pesquisa. Definirei também os

conceitos de alocação simplesmente encadeada, alocação duplamente encadeada,

com representações gráficas das duas.

Em relação a banco de dados, definirei os conceitos das

propriedades ACID de uma transação e sua importância para um SGBD; e serão

apresentadas duas ferramentas para se fazer ORM, bem como a explanação sobre

o que é ORM e seus paradigmas.

No que tange a UML será mostrado os conceitos de polimorfismo e

herança, bem como exemplos que os representem em diagramas de classe.

3

2 LISTAS LINEARES

Lista Linear é a estrutura que permite representar um conjunto de

dados afins, de forma a preservar a relação de ordem linear de seus elementos.

Exemplos diários de listas lineares:

- Letras de uma palavra

- Palavras de uma frase

- Pessoas esperando ônibus

2.1 FIFO

As listas são amplamente utilizadas em programação para

implementar filas de espera. Em uma fila de tipo FIFO os elementos vão sendo

colocados na fila e retirados (ou processados) por ordem de chegada. A ideia

fundamental da fila é que só podemos inserir um novo elemento no final da fila e só

podemos retirar o elemento do início.

Como exemplo de aplicação para filas, pode-se citar a fila de

processos de um sistema operacional. Nela, é estabelecido um tempo a ser usado

por cada um dos processos. Se durante a execução de um processo o tempo passa

de a, este é posto na fila e o processo seguinte é executado. Se o processo seguinte

não terminar de ser executado no tempo, ele é posto na fila e o processo

subsequente é executado, e assim por diante até todos os processos serem

executados.

2.1.1 Aplicações FIFO

Os algoritmos FIFO's são comumente usados em circuitos

eletrônicos de buffer e controle de fluxo, que vai desde o hardware até o software.

Na forma de um hardware o FIFO consiste basicamente de um conjunto de ler e

escrever ponteiros, armazenamento e lógica de controle. Armazenamento pode ser

SRAM, flip-flops, fechos ou qualquer outra forma adequada de armazenamento.

Para o FIFO, de tamanho não trivial, uma SRAM de porta dupla geralmente é

utilizada quando uma porta é usada para a escrita e a outra para leitura.

O FIFO síncrono aonde o mesmo clock é usado para leitura e

4

escrita. Um FIFO assíncrono utiliza diferentes relógios para leitura e escrita. Uma

aplicação comum de um FIFO assíncrono utiliza um código de Gray (código binário

refletido), ou qualquer unidade de código à distância, para ler e escrever os

ponteiros para garantir a geração de bandeira confiável. Uma nota mais preocupante

é que se deve necessariamente usar a aritmética de ponteiro para gerar bandeiras

para implementações assíncronas FIFO. Por outro lado, pode-se usar a abordagem

de um balde "de fuga" ou a aritmética de ponteiro para gerar bandeiras nas

implementações síncronas FIFO.

Exemplos de sinalizadores de status FIFO incluem: cheios, vazios,

quase cheio, quase vazio, etc.

2.1.2 Vantagens e Desvantagens do FIFO

Vantagens:

O mais simples entre os processos de escalonamento;

Todos os processos tendem a serem atendidos.

Desvantagens:

Muito sensível à ordem de chegada;

Se processos maiores chegarem primeiro aumentarão o

tempo médio de espera;

Não garante um tempo de resposta rápido;

Não é eficiente em sistemas de tempo compartilhado;

Não é eficiente em sistemas em tempo real.

2.2 FILO

Em ciência da computação, a FILO (First In, Last Out, que em

português significa primeiro a entrar, ultimo a sair) refere-se a estruturas de dados

do tipo pilha. É equivalente a LIFO, que significa Last In, First Out.

O conceito de pilha é amplamente utilizado na informática, como, por

exemplo, durante a execução de um programa, para o armazenamento de valores

de variável local a um bloco e também para conter o endereço de retorno do trecho

de programa que chamou a função ou procedimento atualmente em execução.

5

Usam-se os termos push e pop para denominar a inserção e

remoção de elementos da pilha, respectivamente. Usa-se o termo top para consultar

o elemento do topo da pilha, sem o remover.

Uma pilha é uma lista linear na qual o primeiro elemento a entrar é o

último elemento a sair. Ela possui apenas uma entrada, chamada de topo, a partir da

qual os dados entram e saem dela.

2.3 ALOCAÇÃO SIMPLISMENTE ENCADEADA

A maneira mais simples de acomodar uma lista linear em

computador é através da utilização de um vetor. A representação por vetor explora a

sequencialidade da memória de tal forma que os nós de uma lista sejam

armazenados em endereços contíguos, ou igualmente distanciados um do outro.

X1 X2 X3 X4 X5 X6 Xn-1 Xn

2.3.1 Exemplos de algoritmos para as operações de inserção e retirada de um

elemento numa pilha com alocação contígua:

VARIÁVEIS: TOPO (índice que indica a última posição ocupada)MÁXIMO (variável cujo valor representa o tamanho do vetor)VALOR (elemento incluído/retirado)

INICIO INSERIRSE TOPO = MAXIMO ENTÃO

“OVERFLOW”SENÃO

TOPO := TOPO + 1VETOR[TOPO] := VALOR

FIM SEFIM

INICIO RETIRARSE TOPO = 0 ENTÃO

“UNDERFLOW”SENÃO

VALOR := VETOR[TOPO]TOPO := TOPO - 1

FIM SEFIM

6

2.3.2 Exemplo de algoritmo para a operação de inserção de um elemento numa fila

com alocação contígua:

VARIÁVEIS: COMECO (índice que indica o primeiro elemento da fila - inicializada c/ 0)FINAL (índice que indica o último elemento da fila - inicializada c/ 0) MÁXIMO (variável cujo valor representa o tamanho do vetor)VALOR (elemento a ser incluído)PROV (uma variável provisória)

INICIO INSERIRPROV := (FINAL MOD MAXIMO) + 1SE PROV COMECO ENTÃO

FINAL := PROVVETOR[FINAL] := VALOR SE COMECO = 0 ENTÃO

COMECO := 1FIM SE

SENÃO“OVERFLOW”

FIM SEFIM

2.3.3 Exemplo de algoritmo para a operação de retirada de um elemento numa fila

com alocação contígua:

VARIÁVEIS: COMECO (índice que indica o primeiro elemento da fila - inicializada c/ 0)FINAL (índice que indica o último elemento da fila - inicializada c/ 0)MÁXIMO (variável cujo valor representa o tamanho do vetor)VALOR (elemento excluído)

INICIO RETIRARSE COMECO 0 ENTÃO

VALOR := VETOR[COMECO]SE COMECO = FINAL ENTÃO

COMECO := 0FINAL := 0

SENÃOCOMECO := (COMECO MOD MAXIMO) + 1

FIM SESENÃO

“UNDERFLOW”FIM SE

FIM

7

2.4 ALOCAÇÃO DUPLAMENTE ENCADEADA

Características:

Listas foram percorridas do início ao final.

Ponteiro "anterior" necessário para muitas operações.

Em alguns casos pode-se desejar percorrer uma lista nas

duas direções indiferentemente.

Nestes casos, o gasto de memória imposto por um novo

campo de ponteiro pode ser justificado pela economia em não

reprocessar a lista toda.

Type tpont = ^ trec;

trec = record

info:T;

esq, dir: tpont;

End;

Lista = tpont;

Var pont: Lista;

Como consequência, podemos realizar as operações de

inserção e eliminação à esquerda ou à direita de um campo

no interior de uma lista sem a necessidade de ponteiros

"anteriores".

2.4.1 Implementação de Algumas Operações de Lista Duplamente Encadeada Com

Alocação Dinâmica

As operações 1 a 4 abaixo são atômicas, isto é, elas realizam a

reserva de espaço (quando necessária) além do 'acerto dos ponteiros'. Pré-condição

para todas elas é que se conheça o ponteiro de um nó ou de um vizinho. Além disso,

elas não tratam casos especiais. Assim, elas são operações de suporte para as

8

inserções e eliminações do TAD Lista, quando este é implementado por lista

duplamente encadeada. Tais operações não ficariam disponíveis para o 'usuário' da

TAD. Apenas o projetista do tipo abstrato de dados as usa no desenvolvimento dos

algoritmos genéricos de inserção e eliminação (isto é, aqueles que tratam todos os

casos, além das condições de erro).

2.4.1.1 Inserção à direita de pont

Procedure ins_dir (pont: lista; x: T);

Var j: Lista;

Begin

new(j);

j^.info:=x;

j^.dir:=pont^.dir;

j^.dir^.esq:=j;

j^.esq:=pont;

pont^.dir:=j;

End;

2.4.1.2 Inserção à esquerda de pont

Procedure ins_esq (pont: Lista; x: T);

Var j: Lista;

Begin

new(j);

j^.info:=x;

j^.dir:=pont;

j^.esq:=pont^.esq;

j^.esq^.dir:=j;

pont^.esq:=j;

End;

9

2.4.1.3 Eliminação à direita de pont

Procedure elim_dir (pont: Lista);

Var j: Lista;

Begin

j:=pont^.dir;

pont^.dir:=j^.dir;

j^.dir^.esq:=pont;

dispose(j);

End;

2.4.1.4 Eliminação do próprio pont

Procedure elim (Var pont: Lista);

Begin

pont^.dir^.esq:=pont^.esq;

pont^.esq^.dir:=pont^.dir;

dispose(pont);

End;

2.4.1.5 Busca em uma lista circular

Funtion Busca_Dup_Ord(ptlista: Lista; x: T):Lista;

{ Lista Duplamente Encadeada Ordenada com sentinela apontado por ptlista }

Var pont, ultimo: Lista;

Begin

ultimo:=ptlista^.esq;

If x<=ultimo^.info then

Begin

10

pont:=ptlista;

While pont^.info < x do

pont:=pont^.dir;

Busca_Dup_Ord:=pont;

End

Else

Busca_Dup_Ord:=ptlista;

End;

11

3 ACID

Acrônimo de Atomicidade, Consistência, Isolamento e Durabilidade.

3.1 TRANSAÇÕES

A maioria dos programas desenvolvidos atualmente é para uso

multiusuário, um sistema de controle de estoque por exemplo. Imagine 10 terminais

buscando e inserindo informações a cada segundo em um servidor. Todos eles

executam um conjunto de comandos que são solicitados de uma só vez. Uma

Transação é basicamente isso, um conjunto de comandos SQL em sequência ou

não, sendo que, todos os comandos deste conjunto devem ser executados e por

completo. Para um bom funcionamento de um SGBD, é necessário que ele tenha

um conjunto de propriedades, conhecido como ACID (Atomicidade, Consistência,

Isolamento e Durabilidade), onde estas propriedades vão definir como serão

executadas as transações.

3.2 ATOMICIDADE

Todas as ações que compõem a unidade de trabalho da transação

devem ser concluídas com sucesso, para que seja efetivada. Se durante a transação

qualquer ação que constitui unidade de trabalho falhar, a transação inteira deve ser

desfeita (rollback). Quando todas as ações são efetuadas com sucesso, a transação

pode ser efetivada e persistida em banco (commit).

3.3 CONSISTÊNCIA

Todas as regras e restrições definidas no banco de dados devem ser

obedecidas. Relacionamentos por chaves estrangeiras, checagem de valores para

campos restritos ou únicos devem ser obedecidos para que uma transação possa

ser completada com sucesso.

3.4 ISOLAMENTO

Cada transação funciona completamente à parte de outras estações.

12

Todas as operações são parte de uma transação única. O principio é que nenhuma

outra transação, operando no mesmo sistema, possa interferir no funcionamento da

transação corrente (é um mecanismo de controle). Outras transações não podem

visualizar os resultados parciais das operações de uma transação em andamento

(ainda em respeito à propriedade da atomicidade).

3.5 DURABILIDADE

Significa que os resultados de uma transação são permanentes e

podem ser desfeitos somente por uma transação subsequente. Por exemplo: todos

os dados e status relativos a uma transação devem ser armazenados num

repositório permanente, não sendo passíveis de falha por uma falha de hardware.

3.6 IMPORTÂNCIA DO ACID PARA UM SGBD

O ACID é muito importante para um BD, pois é este conjunto de

características que garante a qualidade e segurança (contra falhas do sistema) das

transações, obtendo assim bons resultados no armazenamento correto das

informações. Cada propriedade tem sua importância. Com a Atomicidade, as

transações são executadas com sucesso até o final, comando por comando, no caso

de erro em qualquer um deles o SGBD deve desfazer o que foi alterado, então

temos a garantia de que os cálculos, atualizações, ou outras operações não foram

executadas incompletas, e sim até o fim com sucesso. Já a Consistência é

importante porque uma operação não pode violar a integridade dos dados, ou seja,

após executar uma transação, o banco de dados deve manter a consistência dos

dados, mesmo ocorrendo alterações (Update, Insert...). O Isolamento vai evitar que

a transação que está sendo executada, seja interferida ou interrompida por outra

solicitação, evitando que erros aconteçam. A Durabilidade vai garantir que os dados

que foram gravados pelas transações, não sejam perdidos ou danificados, mesmo

que ocorra alguma falha no sistema, como travamento e queda de energia (desde

que não haja perda de hardware).

13

4 BANCO DE DADOS RELACIONAL COM A PROGRAMAÇÃO ORIENTADA A

OBJETOS

4.1 ORIENTAÇÃO A OBJETOS VS MODELO ENTIDADE RELACIONAMENTO

Um dos problemas na comunicação entre uma aplicação Java, por

exemplo, e um banco de dados é o conflito de paradigmas. O banco de dados é

organizado seguindo o modelo entidade relacionamento, enquanto as aplicações

Java, geralmente, utilizam o paradigma orientado a objetos.

A transição de dados entre o modelo entidade relacionamento e o

modelo orientado a objetos não é simples. Para realizar essa transição, é necessário

definir um mapeamento entre os conceitos desses dois paradigmas. Por exemplo,

classes podem ser mapeadas para tabelas, objetos para registros, atributos para

campos e referência entre objetos para chaves estrangeiras.

Para facilitar a comunicação entre aplicações Java que seguem o

modelo orientado a objetos e os banco de dados que seguem o modelo entidade

relacionamento, podemos utilizar ferramentas que automatizam a transição de

dados entre as aplicações e os diferentes bancos de dados e que são conhecidas

como ferramentas de ORM (Object Relational Mapper).

Outra consequência, ao utilizar uma ferramenta de ORM, é que não

é necessário escrever consultas em SQL, pois a própria ferramenta gera as

consultas de acordo com a sintaxe da linguagem SQL correspondente ao banco que

está sendo utilizado.

14

5 OBJECT RELATIONAL MAPPING (ORM) – MAPEAMENTO DE OBJETO

RELACIONAL

Mapeamento de Objeto Relacional (ORM) é uma abordagem que

permite a construção de sistemas utilizando o paradigma orientado a objetos com a

persistência destes objetos em bancos de dados relacionais. Utilizando-se de

técnicas e estratégias específicas, é possível mapear classes com seus atributos e

associações para o modelo relacional (SILVA, 2006).

Segundo (AMBLER, 1999), “o mapeamento de classes pode ser

feito mediante a paridade entre classe e tabela, ou seja, uma classe é mapeada para

uma tabela”. Este mapeamento direto de classes para tabelas representa a forma

mais simples de mapeamento, tornando mais fácil o entendimento e a manutenção

de uma aplicação.

Mapeamento de Tabelas – Simples

Porém, nem sempre o mapeamento é tão simples assim. No caso de

uma estrutura hierárquica, várias classes podem ser mapeadas para uma tabela,

bem como uma classe pode ser mapeada para várias tabelas.

Mapeamento de Tabelas – Complexo

15

As tabelas Classe1 e Classe2 possuem, respectivamente,

relacionamento com as tabelas Tabela1 e Tabela3. Esse mapeamento seria de certa

forma trivial, e poderia ser tratado como relacionamento simples. Um terceiro

relacionamento feito pelas duas tabelas impossibilita esse tratamento, pois ambas

possuem atributos na Tabela2. Dessa forma é necessário que haja uma

especificação de quais atributos pertencem a cada classe.

Ao tratar do mapeamento de atributos de uma classe para colunas

em tabelas de um banco de dados relacional, deve-se levar em conta que os

atributos podem ser de tipos de dados primitivos como inteiros, pontos flutuantes,

caracteres, booleanos e binários, bem como ser de tipos de dados complexos como

tipos baseados criados pelo usuário. Os atributos podem ser ainda multivalorados, o

que viola as regras de normalização do modelo relacional.

Além disso, podem existir atributos de controle ou utilizados em

cálculos, que geralmente não necessitam serem mapeados (AMBLER, 1999). Desta

forma, os atributos simples podem ser mapeados diretamente para colunas em uma

tabela, já os atributos complexos e multivalorados podem necessitar de tabelas

adicionais para seu armazenamento. Estes atributos complexos, geralmente,

possuem características recursivas, ou seja, são classes que possuem outros

atributos e, assim, sucessivamente.

O mapeamento segue o seguinte conceito: as classes mapeiam

cada uma das tabelas do banco de dados de modo que as linhas dessas tabelas se

tornam objetos e as colunas referem-se aos atributos dessa classe.

Mapeamento de Tabelas, Objetos e Atributos

16

Essa técnica possibilita mais do que códigos limpos, permite que

persistências de objetos no banco de dados sejam feitas sem simples e

transparente.

O ORM se comporta como uma camada que possui uma gama de

métodos que cuidam dessa tarefa, tais como: create (cria um novo objeto da classe

a partir dos dados da tabela), find (busca um determinado registro no banco e o

torna um objeto da classe), delete (exclui registros do banco) e update (atualiza

registros de uma tabela de acordo com as solicitações). Esses métodos variam de

acordo com a linguagem utilizada.

Na primeira tabela, é possível observar um pouco das facilidades e

de como a legibilidade do código fica melhor ao se utilizar o ORM ao invés de se

injetar dentro de seu código o SQL puro, o que fere as boas práticas de

programação, que sugere que códigos SQL estejam separados dos códigos de

desenvolvimento (RODRIGES; COSTA; SILVEIR, 2001).

Essa camada, chamada de persistência, encontra-se entre a

camada de negócio (onde estão as classes de domínio da aplicação, ou seja,

classes que definem as regras de negócio) e o banco de dados. Esta camada

permite que o impacto das modificações em uma delas seja atenuado em relação à

outra. Isto diminui o grau de dependência do banco de dados e aumenta a facilidade

de manutenção do código.

Toda responsabilidade por persistir objetos fica a cargo da camada

de persistência, liberando a aplicação destas tarefas, e assim aumentando a

produtividade no desenvolvimento (YODER; JOHNSON; WILSON, 1998). Na

camada de persistência está a definição das estratégias de mapeamento do modelo

17

orientado a objetos para o modelo relacional, apresentadas anteriormente.

A camada de classes representa todo o conjunto de classes

(controllers, views dentre outras) que podem utilizar métodos da camada de

persistência. Assim, as transações com o banco de dados ficam transparentes.

5.1 FERRAMENTAS PARA FAZER ORM (OBJECT RELATIONAL MAPPING)

Uma excelente ferramenta ORM para Java é o Hibernate, e para C#

é o Entity Framework. Mas, existem outras que possuem o mesmo objetivo.

5.1.1 JPA e Hibernate

Após o sucesso do Hibernate, a especificação JPA (Java

Persistence API) foi criada como objetivo de padronizar as ferramentas ORM para

aplicações Java e consequentemente diminuir a complexidade do desenvolvimento.

Atualmente, essa especificação está na sua segunda versão.

Ela especifica um conjunto de classes e métodos que as

ferramentas de ORM devem implementar. Veja que a JPA é apenas uma

especificação, ela não implementa nenhum código. Para isso, utilizamos alguma das

diversas implementações da JPA como, por exemplo, o Hibernate. Outras

implementações de JPA mais conhecidas são: TopLink, EclipseLink e OpenJPA. O

Hibernate é o mais antigo e mais utilizado atualmente.

18

6 HERANÇA E POLIMORFISMO

6.1 HERANÇA

Esse é um dos principais conceitos da POO. A herança é o

compartilhamento de atributos e operações entre classes com base em relações

hierárquicas, ou seja, é a utilização de superclasses para criar as subclasses.

Veja o exemplo abaixo:

6.1.1 Diagrama de Classe (Herança)

Veja outro exemplo abaixo, Em geral, pode-se ter uma hierarquia de

classes relacionadas por herança / generalização. Em cada classe da hierarquia

colocam-se as propriedades que são comuns a todas as suas subclasses, evitando-

se redundância, promovendo a sua reutilização.

19

6.2 POLIMORFISMO

O polimorfismo, na OOP, é a habilidade que os objetos, distintos,

mas relacionados, possuem, de receber um estimulo (um método, ou comando) e

agir (responder) de maneira diferente a esse estímulo. Por exemplo, podemos ter

uma classe, “abstract”, de mamíferos com o método comunicar. Esse método pode

ser implementado de formas diferentes para subclasses herdadas de mamíferos,

como: Humanos, Cães e Gatos. Dessa forma ao invocar o método comunicar, a

partir do objeto correspondente (Objeto da classe humanos, cães ou gatos) o

programa deverá ser capaz de decidir qual o método adequado será executado.

Bezerra (2007) fornece um bom relato sobre as consequências do polimorfismo:

“E no contexto da orientação a objetos, qual é a importância e quais

são as consequências do polimorfismo? Nesse contexto o polimorfismo diz respeito

à capacidade de duas ou mais classes de objetos responderem a mesma

mensagem, cada qual, de seu próprio modo. O exemplo clássico de polimorfismo

em desenvolvimento de software é o das formas geométricas. Pense em uma

coleção de formas geométricas que contenha círculos, retângulos e outras formas

específicas. Pelo princípio do polimorfismo, quando uma região de código precisa

desenhar os elementos daquela coleção, essa região não deve precisar conhecer os

tipos específicos das figuras existentes; basta que cada elemento da coleção receba

uma mensagem solicitando que desenhe a si próprio.” (BEZERRA, 2007:11).

Na OOP essa característica é importante uma vez que possibilita

uma codificação mais simplificada das chamadas dos métodos, ou seja, o cliente

(aquela parte do código que chamou o método) não precisa saber como ele foi

codificado, apenas envia a mensagem e o código, por delegação, sabe como ele foi

implementado e o executará. Assim, Deitel (2005) reforça a definição sobre esse

conceito:

“O polimorfismo ocorre quando um programa invoca um método por

meio de uma variável de superclasse – em tempo de execução, a versão correta da

subclasse do método é chamada, com base no tipo da referência armazenada na

variável de superclasse.” (DEITEL, 2005:337).

20

6.2.1 Diagrama de Classe (Polimorfismo)

21

7 CONCLUSÃO

Através da confecção deste trabalho observou-se o quanto amplo é

a utilização das filas e pilhas na programação. E também a importância das

propriedades ACID para um SGBD, pois é este conjunto de características que

garante a qualidade e segurança (contra falhas do sistema) das transações.

Foi observado que um dos problemas na comunicação entre uma

aplicação desenvolvida em uma linguagem orientada a objeto e um banco de dados

é o conflito de paradigmas. Para facilitar tal tarefa existe o ORM, Mapeamento de

Objeto Relacional, que é uma abordagem que permite a construção de sistemas

utilizando o paradigma orientado a objetos com a persistência destes objetos em

bancos de dados relacionais.

Notou-se também que a Herança é um dos principais conceitos da

POO e permite o compartilhamento de atributos e operações entre classes com

base em relações hierárquicas, e juntamente com o Polimorfismo facilitam a

manipulação de classes e subclasses.

22

REFERÊNCIAS

SILVA, Flávio de Almeida e. Desenvolvimento orientado a objetos I. São Paulo. Editora Pearson, 2009.

TANAKA, Simone Sawasaki. Análise de sistemas II. São Paulo. Editora Pearson, 2009.

http://pt.wikipedia.org/wiki/FIFOAcessado em: 15/04/2012

http://pt.wikipedia.org/wiki/LIFOAcessado em: 15/04/2012

http://www.icmc.usp.br/~sce182/ldupenc.htmlAcessado em: 18/04/2012

http://www.google.com.br/url?sa=t&rct=j&q=listas%20lineares&source=web&cd=5&ved=0CEoQFjAE&url=http%3A%2F%2Fwww.cultura.ufpa.br%2Fferreira%2FDisciplinas%2FEstDados1%2FListasLineares.pdf&ei=NRWQT9_LCqLL0QG31v2QBQ&usg=AFQjCNHl5LHbrwgpAlBFepNIgnVvOze8dAAcessado em: 18/04/2012

http://pt.wikipedia.org/wiki/Banco_de_dadosAcessado em: 03/05/2012

http://pt.wikipedia.org/wiki/Classe_(programação)Acessado em: 04/05/2012

http://pt.wikipedia.org/wiki/PolimorfismoAcessado em: 04/05/2012

23