atividade-interdisciplinar-3º-semestre-individual-george
Post on 05-Aug-2015
23 Views
Preview:
TRANSCRIPT
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
top related