modelo elaboracao trabalho academico 2013

Prévia do material em texto

�PAGE �
SUMÁRIO
32 INTRODUÇÃO	�
43 objetivo	�
54 DESENVOLVIMENTO	�
44.1 – Análise orientada a objentos II	�
44.2 – Banco de Dados II	�
44.3 – Prorgrmção orientada a objetos	�
44.4 – Programação web I	�
75 CONCLUSÃO	�
6 8REFERÊNCIAS	�
��
2 INTRODUÇÕES:
Para a elaboração deste trabalho vou realiza pesquisa para ajuda a desmonta como e bastante clareza pois só assim vou adquiri os conhecimentos de necessário que o trabalho para que no final eu possa absorver o máximo de informação para meu aprendizado, onde poderei colocar em prática de forma simplificada e consciente. Procurarei obter uma maior compreensão das pesquisas realizadas.
Procurarei as resoluções de forma clara e com boa consistência, para que os professores que fazem parte deste trabalho possam interpretar de forma objetiva, e tenham a consciência que as pesquisas realizadas foram feitas de forma que a proposta seja atendida.
3 OBJETIVOS:
. Estou aqui para desmontar a importância dos diagramas dá UML.e os conteúdos que fás parte deste Trabalho Para que posamos sabemos o quanto eles vão contribui para os desenvolvimentos de projetos que fase parte de um conjunto de atributos que visa não só o relacionamento entes entidade mais tabe como vai contribui para a formação do nosso trabalho assim como a nossa dedicação para com ele fazendo assim, esperamos contribuí para a formação dos conhecimentos adquiridos aqui. 
 
desnvolvimento:
análise orientada a objetos ii 
Diagrama de Atividade
O Diagrama de Atividade descreve a sequência de atividades num sistema com a ajuda as Atividades. Diagramas de Atividade são uma forma especial de Diagramas de Estado, que somente (ou principalmente) contém Atividades. 
O Umbrello UML Modeller mostrando um Diagrama de Atividade 
Diagramas de Atividade são similares aos Diagramas de Fluxo de procedimentos, com a diferença de que todas as Atividades são claramente anexas aos Objetos.
Diagramas de Atividade são sempre associados a um Classe, uma Operação ou um Caso de Uso.
Diagramas de Atividade suportam Atividades sequenciais bem como paralelas. A execução paralela é representada pelos ícones Forquilha/Esperar, e para as Atividades executadas em paralelo, não é importante a ordem na qual elas se executam (elas podem ser executadas ao mesmo tempo ou uma após a outra).
Atividade
Uma Atividade é um passo simples num processo. Uma Atividade é um estado no sistema com atividade interna e, pelo menos, uma transição de saída. Atividades podem também ter mais de uma transição de saída se elas possuem condições diferentes. 
Atividades podem formar hierarquias, isto significa que uma Atividade pode ser composta por diversas Atividades em “detalhe”, na qual as transições de entrada e saída devem corresponder às transições de entrada e saída do diagrama de detalhe. 
Elementos Auxiliares
Existem dois elementos em UML que não possuem nenhum valor real semântico para o modelo, mas auxiliam a elucidar partes do diagrama. Estes elementos são 
Linhas de texto
Notas de Texto e âncoras
Caixas
Linhas de texto são úteis para adicionar informações curtas de texto ao diagrama. São textos livres e não possuem nenhum significado para o Modelo propriamente dito. 
Notas são úteis para adicionar informações mais detalhadas sobre um objeto ou situação específica. Elas possuem a grande vantagem de poderem ser ancoradas a Elementos UML para mostrar que a nota “pertence” a um objeto específico ou situação. 
Caixas são retângulos de forma livre que podem ser usados para agrupar itens tornando os diagramas mais legíveis. Eles não possuem nenhum significado lógico no modelo
Diagramas de Sequência
Diagramas de Sequência mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de Sequência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas.
Em Diagramas de Sequência objetos são representados através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros. 
O Umbrello UML Modeller mostrando um Diagrama de Sequência 
Mensagens pode ser síncrona, o tipo normal de mensagem de chamada onde o controle é passado para o objeto chamado até o método ter terminado sua execução, ou assíncronas onde o controle é passado diretamente para o objeto chamado. Mensagens síncronas possui uma caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.
Diagrama de Classe
Diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe são chamados diagramas “estáticos” porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes “conhecem” quais classes ou quais classes “são parte” de outras classes, mas não mostram a troca de mensagens entre elas. 
O Umbrello UML Modeller mostrando um Diagrama de Classe 
Classe
Um Classe define os atributos e os métodos de um conjunto de objetos. Todos os objetos desta classe (instâncias desta classe) compartilham o mesmo comportamento, e possuem o mesmo conjunto de atributos (cada objeto possui seu próprio conjunto). O termo “Tipo” é algumas vezes usado ao invés de Classe, mas é importante mencionar que estes dois termos não são a mesma coisa, e Tipo é um termo mais genérico. 
Em UML Classes são representadas por retângulos, com o nome da classe, e podem também mostrar os atributos e operações da classe em dois outros “compartimentos” dentro do retângulo. 
Representação visual de uma Classe em UML 
Atributos
Na UML, atributos são mostrados com pelo menos seu nome, e podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem também ser exibidos com sua visibilidade: 
+ indica atributos públicos
# indica atributos protegidos
- Indica atributos privados
Operações
Operações (métodos) também são exibidos com pelo menos seu nome, e podem também mostrar seus parâmetros e valores de retorno. Operações podem, como os Atributos, mostras sua visibilidade: 
+ indica operações públicas
# indica operações protegidas
- Indica operações privadas
Modelos
Classes podem ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é especificado quando uma classe é iniciada (isto é um objeto é criado). Modelos existem no C++ moderno e foram introduzidos no Java 1.5 onde eles são chamados de Genéricos. 
Associações de Classe
Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras:
Generalização
A herança é um dos conceitos fundamentais da programação orientada por objetos, nos quais uma classe “ganha” todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias.
EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de herança de uma classe derivada de uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base. 
bancos de dados
Diagrama de Entidade e Relacionamento
Através deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstraídos no processo de análise de sistemas. Denominamos entidade (retângulo) estes elementos. Atribuímos a cada entidade definida atributos pertinentes ao sistema. Desta forma, podemos definir conceitualmente que representaremos como entidades aqueles elementos no qual gostaríamos de armazenardados – que por sua vez, são representados pelos atributos. Através do relacionamento (losango) representaremos o tipo de relação existente entre as entidades. Abaixo, na Figura 1, temos um exemplo (incorreto ou mal estruturado – em melhores palavras) de um Diagrama de Entidade e Relacionamento (DER).
�
Diagrama de Estrutura de Dados
A próxima etapa do processo de análise de banco de dados fixa-se na formulação do Diagrama de Estrutura de Dados (DED). Através deste diagrama, serão representadas, de forma a facilitar o processo implementação posterior (SQL), as entidades – neste caso, chamadas de tabelas. Os atributos serão representados com seus respectivos domínios (tipos). Veja a seguir, na Figura 2, os domínios adotados neste diagrama.
C (número) – Utilizado na representação de uma sequência de caracteres com tamanho número. Exemplo: Nome Cliente C (60) N (Esquerda, Direita) – Para representação de números na base de dados. Teremos Esquerda elementos ao lado esquerdo da vírgula e Direita elementos do lado direito da vírgula (casas decimais). Exemplo:
Salario empregado N (5,2) – com o formato 99999,99
D – Representa uma data. Exemplo: Data Nascimento D
Figura 2 – Domínios dos Atributos
A representação dos relacionamentos existentes no DER permanece no DED de forma a satisfazer os conceitos do modelo relacional, ou seja, com grande proximidade da implementação das tabelas no SGBD. A seguir, temos o diagrama anterior (DER) transportado para o Diagrama de Estrutura de Dados (DED). Observe que a modelagem ainda está inapropriada. Aqui, por conveniência do aprendizado da Normalização, alguns elementos foram propositalmente repetidos de forma errada.
�
Normalização
O processo de normalização visa corrigir a base de dados evitando possíveis problemas de integridade, redundância e má estruturação dos dados. A correção acontece através dos conceitos das formas normais que reestruturam o banco de dados. O processo deverá ocorrer em etapas: primeiramente a base deverá satisfazer as regras da primeira forma normal (1FN). A posteriori, estar enquadrada nas regras da segunda forma normal (2FN) – que por sua vez, só poderá ser realizada quando a 1FN já estiver atendida. Por seguinte, outras formas normais virão ajustando o banco. Adiante iremos corrigir os problemas encontrados no Diagrama de Estrutura de Dados apresentado anteriormente. As Formas Normais (1FN, 2FN e 3FN) serão explicadas durante cada etapa do processo.
Primeira Forma Normal (1FN): A primeira forma normal reajustará na base de dados atributos compostos (atributos que são compostos por sub-atributos, como por exemplo, endereço que é composto por rua, número, bairro, cep, cidade e uf) e atributos multivalorados (como por exemplo, os telefones do cliente – um cliente pode ter de 0 a N telefones). Para que a base esteja enquadrada na 1FN ela precisa satisfazer essas regras. Abaixo, na Figura 4, tempos o DED apresentado anteriormente já reestruturado de acordo com a 1FN.
�
Observação Importante: Existem outras possibilidades de reestruturar este DED pelas regras da 1FN. Propositalmente, a tabela telefones estará em desacordo com os conceitos relacionais, pois possui uma chave estrangeira (Cod_Fornecedor, que também é primária) que não é chave primária na tabela Produtos. Isto foi criado apenas para ser posteriormente tratado pela 3FN. Uma outra possibilidade: considerar o campo Cod_Fornecedor como chave primária (em conjunto com Cod Prod.) na tabela Produtos.
Segunda Forma Normal (2FN): Como primeira restrição, a 2FN requere que a base esteja enquadrada na 1FN. A Segunda Forma Normal trabalha para que todo atributo primo (aqueles atributos que não são chaves primárias) dependa funcionalmente das chaves primárias (pois na prática, este tipo de problema ocorrerá nas tabelas com mais de um atributo chave). Por exemplo, visualize com atenção a tabela Vendas. O único atributo primo, que talvez (isto varia com a abordagem do sistema) dependa exclusivamente das duas chaves primárias é a Comissão_Venda_Emp. Os outros atributos, ou só dependem de Cod_Venda ou só de Cod. Empregado. A correção desta anomalia resultaria em duas ou mais tabelas. Uma tabela será a de Vendas – que conterá todos os atributos pertinentes. Outra será a tabela de Empregados. Se EXISTIR algum atributo que dependa das duas chaves simultaneamente, haverá então uma terceira tabela com chave primária composta (Cod_Venda e Cod_Empregado). Por conveniência didática, suponha que a Comissão_Venda_Emp seja definida quando determinado empregado realiza determina venda de algum produto, ou seja, exigindo a adoção de uma terceira tabela (neste caso, que já existe: Prod_Venda – antiga entidade possui).
�
Terceira Forma Normal (3FN): Analogamente à 2FN, a 3FN exige que a primeira e segunda forma estejam satisfeitas. A Terceira Forma Normal trabalha com intuito de evitar a existência de dependência transitiva, ou seja, evitar que um atributo primo dependa funcionalmente (esteja relacionado) de outro atributo primo. Este tipo de problema pode ser visualizado na tabela Produtos. Observe que existe uma Sub-Tabela Funcionários dentro da tabela em questão. A correção desta anomalia é feita separando-se essas duas tabelas. Veja na Figura 6, o diagrama tratado pela 3FN. O problema ocasionado na correção pela 1FN (da tabela Telefones) foi, por consequência, resolvido.
�
Dica: Existe certa semelhança entre a 2FN e 3FN. Para evitar confusão, deve-se, na correção da 2FN, proceder visualizando os atributos chaves e sua relação com os atributos primos. Deve-se também lembrar que ela, em geral será usada na existência de mais de um atributo chave na tabela. Já a 3FN trata apenas das questões de dependência transitiva (ou grosseiramente, da existência de Sub-Tabelas dentro da Tabela).
Diagrama de Entidade e Relacionamento
Através deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstraídos no processo de análise de sistemas. Denominamos entidade (retângulo) estes elementos. Atribuímos a cada entidade definida atributos pertinentes ao sistema. Desta forma, podemos definir conceitualmente que representaremos como entidades aqueles elementos no qual gostaríamos de armazenar dados – que por sua vez, são representados pelos atributos. Através do relacionamento (losango) representaremos o tipo de relação existente entre as entidades. Abaixo, na Figura 1, temos um exemplo (incorreto ou mal estruturado – em melhores palavras) de um Diagrama de Entidade e Relacionamento (DER).
�
Diagrama de Estrutura de Dados
A próxima etapa do processo de análise de banco de dados fixa-se na formulação do Diagrama de Estrutura de Dados (DED). Através deste diagrama, serão representadas, de forma a facilitar o processo implementação posterior (SQL), as entidades – neste caso, chamadas de tabelas. Os atributos serão representados com seus respectivos domínios (tipos). Veja a seguir, na Figura 2, os domínios adotados neste diagrama.
C (número) – Utilizado na representação de uma sequência de caracteres com tamanho número. Exemplo: Nome Cliente C (60) N (Esquerda, Direita) – Para representação de números na base de dados. Teremos Esquerda elementos ao lado esquerdo da vírgula e Direita elementos do lado direito da vírgula (casas decimais). Exemplo:
Salario empregado N (5,2) – com o formato 99999,99
D – Representa uma data. Exemplo: Data Nascimento D
Figura 2 – Domínios dos Atributos
A representação dos relacionamentos existentes no DER permanece no DED de forma a satisfazer os conceitos do modelo relacional, ou seja, com grande proximidade da implementação das tabelas no SGBD. A seguir, temos o diagrama anterior (DER) transportado para o Diagrama de Estrutura de Dados (DED). Observe que a modelagem ainda está inapropriada. Aqui, por conveniência do aprendizado da Normalização, alguns elementos foram propositalmente repetidos de forma errada.
�
Normalização
O processo de normalização visa corrigir a base dedados evitando possíveis problemas de integridade, redundância e má estruturação dos dados. A correção acontece através dos conceitos das formas normais que reestruturam o banco de dados. O processo deverá ocorrer em etapas: primeiramente a base deverá satisfazer as regras da primeira forma normal (1FN). A posteriori, estar enquadrada nas regras da segunda forma normal (2FN) – que por sua vez, só poderá ser realizada quando a 1FN já estiver atendida. Por seguinte, outras formas normais virão ajustando o banco. Adiante iremos corrigir os problemas encontrados no Diagrama de Estrutura de Dados apresentado anteriormente. As Formas Normais (1FN, 2FN e 3FN) serão explicadas durante cada etapa do processo.
Primeira Forma Normal (1FN): A primeira forma normal reajustará na base de dados atributos compostos (atributos que são compostos por sub-atributos, como por exemplo, endereço que é composto por rua, número, bairro, cep, cidade e uf) e atributos multivalorados (como por exemplo, os telefones do cliente – um cliente pode ter de 0 a N telefones). Para que a base esteja enquadrada na 1FN ela precisa satisfazer essas regras. Abaixo, na Figura 4, tempos o DED apresentado anteriormente já reestruturado de acordo com a 1FN.
�
Observação Importante: Existem outras possibilidades de reestruturar este DED pelas regras da 1FN. Propositalmente, a tabela telefones estará em desacordo com os conceitos relacionais, pois possui uma chave estrangeira (Cod_Fornecedor, que também é primária) que não é chave primária na tabela Produtos. Isto foi criado apenas para ser posteriormente tratado pela 3FN. Uma outra possibilidade: considerar o campo Cod_Fornecedor como chave primária (em conjunto com Cod_Prod) na tabela Produtos.
Segunda Forma Normal (2FN): Como primeira restrição, a 2FN requere que a base esteja enquadrada na 1FN. A Segunda Forma Normal trabalha para que todo atributo primo (aqueles atributos que não são chaves primárias) dependa funcionalmente das chaves primárias (pois na prática, este tipo de problema ocorrerá nas tabelas com mais de um atributo chave). Por exemplo, visualize com atenção a tabela Vendas. O único atributo primo, que talvez (isto varia com a abordagem do sistema) dependa exclusivamente das duas chaves primárias é a Comissão_Venda_Emp. Os outros atributos, ou só dependem de Cod_Venda ou só de Cod_. Empregado. A correção desta anomalia resultaria em duas ou mais tabelas. Uma tabela será a de Vendas – que conterá todos os atributos pertinentes. Outra será a tabela de Empregados. Se EXISTIR algum atributo que dependa das duas chaves simultaneamente, haverá então uma terceira tabela com chave primária composta (Cod_Venda e Cod_Empregado). Por conveniência didática, suponha que a Comissão_Venda_Emp seja definida quando determinado empregado realiza determina venda de algum produto, ou seja, exigindo a adoção de uma terceira tabela (neste caso, que já existe: Prod_Venda – antiga entidade. Possui).
�
Terceira Forma Normal (3FN): Analogamente à 2FN, a 3FN exige que a primeira e segunda forma estejam satisfeitas. A Terceira Forma Normal trabalha com intuito de evitar a existência de dependência transitiva, ou seja, evitar que um atributo primo dependa funcionalmente (esteja relacionado) de outro atributo primo. Este tipo de problema pode ser visualizado na tabela Produtos. Observe que existe uma Sub-Tabela Funcionários dentro da tabela em questão. A correção desta anomalia é feita separando-se essas duas tabelas. Veja na Figura 6, o diagrama tratado pela 3FN. O problema ocasionado na correção pela 1FN (da tabela Telefones) foi, por conseqüência, resolvido.
�
Dica: Existe certa semelhança entre a 2FN e 3FN. Para evitar confusão, deve-se, na correção da 2FN, proceder visualizando os atributos chaves e sua relação com os atributos primos. Deve-se também lembrar que ela, em geral será usada na existência de mais de um atributo chave na tabela. Já a 3FN trata apenas das questões de dependência transitiva (ou grosseiramente, da existência de Sub-Tabelas dentro da Tabela).
4.3 PROGRAMAÇÃO orientada a objetos
Programação estruturada vs Programação Orientada a Objetos
Na Figura 1 vemos uma comparação muito clara entre a programação estruturada e a programação orientada a objetos no que diz respeito aos dados. Repare que, no paradigma estruturado, temos procedimentos (ou funções) que são aplicados globalmente em nossa aplicação. No caso da orientação a objetos, temos métodos que são aplicados aos dados de cada objeto. Essencialmente, os procedimentos e métodos são iguais, sendo diferenciados apenas pelo seu escopo.
Figura 1. Estruturada x Orientação a Objetos
A linguagem C é a principal representante da programação estruturada. Se trata de uma linguagem considerada de baixo nível, que atualmente não é utilizada para projetos muito grandes. A sua principal utilização, devido ao baixo nível, é em programação para sistemas embarcados ou outros em que o conhecimento do hardware se faz necessário para um bom programa.
Essa colocação nos traz a um detalhe importante: a programação estruturada, quando bem-feita, possui um desempenho superior ao que vemos na programação orientada a objetos. Isso ocorre pelo fato de ser um paradigma sequencial, em que cada linha de código é executada após a outra, sem muitos desvios, como vemos na POO. Além disso, o paradigma estruturado costuma permitir mais liberdades com o hardware, o que acaba auxiliando na questão desempenho.
Entretanto, a programação orientada a objetos traz outros pontos que acabam sendo mais interessantes no contexto de aplicações modernas. Como o desempenho das aplicações não é uma das grandes preocupações na maioria das aplicações (devido ao poder de processamento dos computadores atuais), a programação orientada a objetos se tornou muito difundida. Essa difusão se dá muito pela questão da reutilização de código e pela capacidade de representação do sistema muito mais perto do que veríamos no mundo real.
Veremos em detalhes esses e outros pontos que dizem respeito a programação orientada a objetos. Como desenvolvedores, é nossa missão entender quais são as vantagens e desvantagens de cada um dos paradigmas de programação e escolhermos o melhor para nossa aplicação. A escolha da linguagem também deve estar presente nessa escolha.
Os 4 pilares da Programação Orientada a Objetos
Para entendermos exatamente do que se trata a orientação a objetos, vamos entender quais são os requerimentos de uma linguagem para ser considerada nesse paradigma. Para isso, a linguagem precisa atender a quatro tópicos bastante importantes:
Abstração
A abstração consiste em um dos pontos mais importantes dentro de qualquer linguagem Orientada a Objetos. Como estamos lidando com uma representação de um objeto real (o que dá nome ao paradigma), temos que imaginar o que esse objeto irá realizar dentro de nosso sistema. São três pontos que devem ser levados em consideração nessa abstração.
O primeiro ponto é darmos uma identidade ao objeto que iremos criar. Essa identidade deve ser única dentro do sistema para que não haja conflito. Na maior parte das linguagens, há o conceito de pacotes (ou namespaces). Nessas linguagens, a identidade do objeto não pode ser repetida dentro do pacote, e não necessariamente no sistema inteiro. Nesses casos, a identidade real de cada objeto se dá por.
A segunda parte diz respeito a características do objeto. Como sabemos, no mundo real qualquer objeto possui elementos que o definem. Dentro da programação orientada a objetos, essas características são nomeadas propriedades. Por exemplo, as propriedades de um objeto “Cachorro” poderiam ser “Tamanho”, “Raça” e “Idade”.
Por fim, a terceira parte é definirmos as ações que o objeto irá executar. Essas ações, ou eventos, são chamados métodos. Esses métodos podem ser extremamente variáveis, desde “Acender () ” em um objeto lâmpada até “Latir () ” em um objeto cachorro.
Encapsulamento
O encapsulamento é uma das principais técnicas que definea programação orientada a objetos. Se trata de um dos elementos que adicionam segurança à aplicação em uma programação orientada a objetos pelo fato de esconder as propriedades, criando uma espécie de caixa preta.
A maior parte das linguagens orientadas a objetos implementam o encapsulamento baseado em propriedades privadas, ligadas a métodos especiais chamados getters e setters, que irão retornar e sentar o valor da propriedade, respectivamente. Essa atitude evita o acesso direto a propriedade do objeto, adicionando uma outra camada de segurança à aplicação.
Para fazermos um paralelo com o que vemos no mundo real, temos o encapsulamento em outros elementos. Por exemplo, quando clicamos no botão ligar da televisão, não sabemos o que está acontecendo internamente. Podemos então dizer que os métodos que ligam a televisão estão encapsulados.
Herança
O reuso de código é uma das grandes vantagens da programação orientada a objetos. Muito disso se dá por uma questão que é conhecida como herança. Essa característica otimiza a produção da aplicação em tempo e linhas de código.
Para entendermos essa característica, vamos imaginar uma família: a criança, por exemplo, está herdando características de seus pais. Os pais, por sua vez, herdam algo dos avós, o que faz com que a criança também o faça, e assim sucessivamente. Na orientação a objetos, a questão é exatamente assim, como mostra a Figura 2. O objeto abaixo na hierarquia irá herdar características de todos os objetos acima dele, seus “ancestrais”. A herança a partir das características do objeto mais acima é considerada herança direta, enquanto as demais são consideradas heranças indiretas. Por exemplo, na família, a criança herda diretamente do pai e indiretamente do avô e do bisavô.
Figura 2. Herança na orientação a objetos
A questão da herança varia bastante de linguagem para linguagem. Em algumas delas, como C++, há a questão da herança múltipla. Isso, essencialmente, significa que o objeto pode herdar características de vários “ancestrais” ao mesmo tempo diretamente. Em outras palavras, cada objeto pode possuir quantos pais for necessário. Devido a problemas, essa prática não foi difundida em linguagens mais modernas, que utilizam outras artimanhas para criar uma espécie de herança múltipla.
Outras linguagens orientadas a objetos, como C#, trazem um objeto base para todos os demais. A classe object fornece características para todos os objetos em C#, sejam criados pelo usuário ou não.
Polimorfismo
Outro ponto essencial na programação orientada a objetos é o chamado polimorfismo. Na natureza, vemos animais que são capazes de alterar sua forma conforme a necessidade, e é dessa ideia que vem o polimorfismo na orientação a objetos. Como sabemos, os objetos filhos herdam as características e ações de seus “ancestrais”. Entretanto, em alguns casos, é necessário que as ações para um mesmo método seja diferente. Em outras palavras, o polimorfismo consiste na alteração do funcionamento interno de um método herdado de um objeto pai.
Como um exemplo, temos um objeto genérico “Eletrodoméstico”. Esse objeto possui um método, ou ação, “Ligar () ”. Temos dois objetos, “Televisão” e “Geladeira”, que não irão ser ligados da mesma forma. Assim, precisamos, para cada uma das classes filhas, reescrever o método “Ligar () ”.
Com relação ao polimorfismo, valem algumas observações. Como se trata de um assunto que está intimamente conectado à herança, entender os dois juntamente é uma boa ideia. Outro ponto é o fato de que as linguagens de programação implementam o polimorfismo de maneiras diferentes. O C#, por exemplo, faz uso de método virtuais (com a palavra-chave virtual) que podem ser reimplementados (com a palavra-chave override) nas classes filhas. Já em Java, apenas o atributo “@Override” é necessário.
Esses quatro pilares são essenciais no entendimento de qualquer linguagem orientada a objetos e da orientação a objetos como um todo. Cada linguagem irá implementar esses pilares de uma forma, mas essencialmente é a mesma coisa. Apenas a questão da herança, como comentado, que pode trazer variações mais bruscas, como a presença de herança múltipla. Além disso, o encapsulamento também é feito de maneiras distintas nas diversas linguagens, embora os getters e setters sejam praticamente onipresentes.
Principais vantagens da POO
A programação orientada a objetos traz uma ideia muito interessante: a representação de cada elemento em termos de um objeto, ou classe. Esse tipo de representação procura aproximar o sistema que está sendo criado ao que é observado no mundo real, e um objeto contém características e ações, assim como vemos na realidade. Esse tipo de representação traz algumas vantagens muito interessantes para os desenvolvedores e também para o usuário da aplicação. Veremos algumas delas a seguir.
A reutilização de código é um dos principais requisitos no desenvolvimento de software atual. Com a complexidade dos sistemas cada vez maior, o tempo de desenvolvimento iria aumentar exponencialmente caso não fosse possível a reutilização. A orientação a objetos permite que haja uma reutilização do código criado, diminuindo o tempo de desenvolvimento, bem como o número de linhas de código. Isso é possível devido ao fato de que as linguagens de programação orientada a objetos trazem representações muito claras de cada um dos elementos, e esses elementos normalmente não são interdependentes. Essa independência entre as partes do software é o que permite que esse código seja reutilizado em outros sistemas no futuro.
Outra grande vantagem que o desenvolvimento orientado a objetos traz diz respeito a leitura e manutenção de código. Como a representação do sistema se aproxima muito do que vemos na vida real, o entendimento do sistema como um todo e de cada parte individualmente fica muito mais simples. Isso permite que a equipe de desenvolvimento não fique dependente de uma pessoa apenas, como acontecia com frequência em linguagens estruturadas como o C, por exemplo.
A criação de bibliotecas é outro ponto que é muito mais simples com a orientação a objetos. No caso das linguagens estruturadas, como o C, temos que as bibliotecas são coleções de procedimentos (ou funções) que podem ser reutilizadas. No caso da POO, entretanto, as bibliotecas trazem representações de classes, que são muito mais claras para permitirem a reutilização.
Entretanto, nem tudo é perfeição na programação orientada a objetos. A execução de uma aplicação orientada a objetos é mais lenta do que o que vemos na programação estruturada, por exemplo. Isso acontece devido à complexidade do modelo, que traz representações na forma de classes. Essas representações irão fazer com que a execução do programa tenha muitos desvios, diferente da execução sequencial da programação estruturada. Esse é o grande motivo por trás da preferência pela linguagem C em hardware limitado, como sistemas embarcados. Também é o motivo pelo qual a programação para sistemas móveis como o Google Android, embora em Java (linguagem orientada a objetos), seja feita o menos orientada a objetos possível.
No momento atual em que estamos, tecnologicamente essa execução mais lenta não é sentida. Isso significa que, em termos de desenvolvimento de sistemas modernos, a programação orientada a objetos é a mais recomendada devido as vantagens que foram apresentadas. Essas vantagens são derivadas do modelo de programação, que busca uma representação baseada no que vemos no mundo real.
Exemplos de Linguagens Orientadas a Objetos
Há uma grande quantidade de linguagens de programação orientada a objetos no mercado atualmente. Nesse artigo, iremos apresentar 3 das mais utilizadas no momento: Java, C# e C++. Cada uma delas possui uma abordagem diferente do problema que as torna muito boas para alguns tipos de aplicações e não tão boas para outros.
Java
O Java é, muito provavelmente, a linguagem de programação mais utilizada no mercado atual. Auxiliado pela presença do JRE (Java RuntimeEnvironment), ou variações dele, em quase todos os dispositivos eletrônicos do momento, a linguagem Java é um grande sucesso entre os desenvolvedores. O sucesso da linguagem aumentou ainda mais com o Google Android, que escolheu o Java como linguagem preferencial de desenvolvimento de aplicações.
O Java implementa os quatro pilares de forma bastante intuitiva, o que facilita o entendimento por parte do desenvolvedor. A abstração, o primeiro pilar, é implementado através de classes, que contém propriedades e métodos, de forma bastante simples. Já o encapsulamento é realizado através de propriedades privadas, auxiliadas por métodos especiais getters esetters, como mostra a Listagem 1. Vale ressaltar a palavra-chave “this” mostrada no método SetId (). Essa palavra-chave funciona como um representante da classe atual, uma auto referência ao próprio objeto.
Listagem 1. Encapsulamento em Java
 Private int. id;
 
 Public. int. GetId ()
 {
 return id;
 {
 
 public. Void SetId (int id)
 {
 this.id = id;
 }
As questões de herança e polimorfismo no Java são um pouco mais complexas. O Java possui herança simples, o que significa que cada classe pode herdar de apenas uma outra. Entretanto, o Java possui as chamadas Interfaces, que possuem propriedades e assinaturas de métodos. Essas interfaces precisam ser implementadas para funcionar, o que significa que uma classe pode implementar várias interfaces e herdar de apenas uma classe. Na questão de polimorfismo, o atributo @Override é responsável por informar ao Java que o método em questão está sendo reescrito.
C#
O C#, por sua vez, é outra das linguagens mais utilizadas no mercado. Como os computadores pessoais no mundo, em sua maioria, possuem o sistema operacional Windows, da Microsoft, o C# se popularizou. Isso porque o Windows implementa o Framework .NET, ao qual o C# está associado. O C# é uma linguagem de uso geral e especialmente criada para utilização com a orientação a objetos. Vale ressaltar que, em C#, tudo é um objeto (herda da classe object).
A abstração é muito simples, e segue o modelo do Java. A questão de encapsulamento é um pouco diferente devido a implementação dos métodos getter e setter. A nomenclatura também é um pouco diferente. A variável que realmente guarda o valor do dado é chamada atributo, enquanto a propriedade é o elemento que realmente acessa aquele dado do mundo externo. Isso está mostrado na Listagem 2. Além disso, o C# faz uso de duas palavras-chave especiais: get e set.
Listagem 2. Encapsulamento em C#
 // Atributo
 Private int id;
 
 // Propriedade
 Public int Id
 {
 get;
 Set;
 }
A questão da herança em C# também segue o modelo do Java: herança simples e a possibilidade de utilização de interfaces. A importância das interfaces é muito grande, uma vez que elas podem dar o tipo dos dados, que somente posteriormente serão associados a um tipo real, como mostra a Listagem 3. Isso também é válido para o Java. Por padrão, as identidades das interfaces começam com a letra “I”. O polimorfismo, por sua vez, é baseado em métodos virtuais (com a palavra-chave virtual) na classe pai e reescritos com a palavra-chave override na classe filha.
Listagem 3. Interfaces em C#
 IExemploInterface exemplo;
 Exemplo = new ImplementacaoIExemploInterface ();
C++
O C++, por sua vez, é uma linguagem um pouco mais primitiva, e permite muito mais liberdades com o hardware. Como ele foi derivado imediatamente do C, o C++ permite a utilização de ponteiros, por exemplo, que irão trabalhar diretamente com a memória. Além disso, o C++ pode utilizar todas as bibliotecas C que existem diretamente.
Em termos de abstração, o C++ implementa classes, assim como qualquer linguagem orientada a objetos. Ele também possui o sentido de privado e público, que é utilizado para encapsulamento. Esse encapsulamento é realizado através de métodos getter e setter, muito similar ao visto em Java, como mostra a Listagem 4. Repare que a listagem mostra somente a assinatura dos métodos especiais, sendo que sua implementação é a mesma que em Java. Esse tipo de adaptação é muito comum em C++, onde a classe é guardada em um arquivo. h e sua implementação em um arquivo .cpp.
Listagem 4. Encapsulamento em C++
 Private:
 Int id;
 public.:
 Int GetId () const.;
 Void SetId (int const id);
A questão da herança no C++ é um pouco diferente. A linguagem permite a herança múltipla, o que significa que cada classe pode herdar de quantas classes desejar. Isso pode causar problemas de métodos que possuem o mesmo nome, portanto o desenvolvedor precisa estar atento. O polimorfismo é baseado em métodos virtuais, da mesma forma como o C#. A complexidade, entretanto, é maior, uma vez que temos que cuidar de detalhes de mais baixo nível, como acesso a memória.
Além dessas exemplificadas, existem outras linguagens que merecem ser citadas. Entre elas, podemos elencar: Python, linguagem de script orientada a objetos que é muito utilizada em pesquisas científicas devido a sua velocidade; Object Pascal (também conhecida como Delphi, devido ao nome de sua IDE), que está caindo em desuso, apesar do grande número de sistemas mais antigos que a utilizam; Objective-C, que é a linguagem de preferência para desenvolvimento de aplicações para os sistemas da Apple, como iPhone e iPad; Ruby, voltada para o desenvolvimento web; e Visual Basic .NET, muito utilizada até pouco tempo, mas também caindo em desuso, principalmente devido ao avanço do C# em popularidade.
Ao longo desse artigo, procuramos elencar os elementos que fazem da programação orientada a objetos um sucesso no momento. Vimos os quatro pilares desse paradigma e entendemos como eles são implementados em algumas das linguagens mais utilizadas no mercado de desenvolvimento. Além disso, entendemos algumas das vantagens que tornaram a programação orientada a objetos um grande sucesso para o desenvolvimento de sistemas modernos.
4.4 programações web I
TABELA 2.1 - Comparativo entre tecnologias que suportam páginas dinâmicas. 
 
	Características 
	ASP 
	PHP 
	JSP 
	
	
	
	
	Arquitetura 
	Fechada 
	Aberta 
	Aberta 
	Uso de scripts 
	VBScript e JScript
	JavaScript 
	 
	Segurança 
	Baseada na arquitetura do NT 
	Versatilidade de configuração de segurança de acesso 
	Modelo de segurança do Java 
	Acesso à base de dados 
	ADO 
	DBASE, Interbase, 
MySQL, Oracle, 
PostgreSQL 
	JDBC 
	Personalização de tags 
	Não pode ser ampliado 
	Não pode ser ampliado 
	Ampliado através do uso de biblioteca 
FONTE: Medeiros (2002). 
O uso de uma ou de outra linguagem se dá de acordo com a experiência de cada profissional e com prioridades e necessidades de cada projeto. 
2.2.3 - Linguagens de Programação Client Side 
As linguagens de programação para a Web são os scripts que compõem os códigos ou sequências de códigos, que formam os arquivos existentes em um Web site. Algumas linguagens são interpretadas na máquina cliente (Client Side) onde o conteúdo gerado é exibido conforme os recursos disponíveis em cada navegador. Se o navegador não tiver os recursos que estão nos scripts, o usuário será privado de visualizar parte do conteúdo. As linguagens interpretadas em um servidor (Server Side) dependem do servidor para interpretálas, assim quando um usuário faz uma requisição, a servidora processa os scripts que compõem a página e devolve ao cliente somente o resultado na forma de HTML. (Mendes,1999), (Haddleton, 1997). 
A Tabela 2.2 mostra algumas características de máquinas cliente versus servidoras. 
TABELA 2.2 - Cliente x Servidor. 
	Cliente 
	Servidora 
	Quem quer a informação 
	Quem tem a informação 
	Usuário 
	Fornecedor 
	Quem quer usar 
	Quem tem o recurso 
	É um intermediário 
	Continuamente, escuta e atende os pedidos de clientes 
	Traduz as solicitações 
	Fornece hiperdocumentosdisponíveis em seu acervo 
	Exibe hiperdocumentos 
	Processa códigos de páginas ativas e devolve ao cliente em forma de hiperdocumentos 
 FONTE: Haddleton (1997). 
Algumas linguagens de programação client side, amplamente utilizadas para a Web são mostradas a seguir. 
 
2.2.3.1 - CSS 
A Cascading Style Sheets (CSS) foi introduzida quando do lançamento do navegador Internet Explorer 3. Logo em seguida, quando lançou a versão 4 do Netscape Communicator, a Netscape também aderiu a esse padrão. Porém quando a Microsoft lançou a versão 4, ela já agregou várias funcionalidades novas, que, entretanto, se mostraram incompatíveis com o Netscape. Após o lançamento do Internet Explorer 5, com uma carga enorme de funcionalidades para a CSS, as diferenças cresceram, e com elas mais problemas de incompatibilidade entre navegadores. 
Por isso, para utilizar CSS é necessário testar em diversos navegadores, os recursos que serão implementados em um Web site, para permitir que os usuários não deixem de ver o conteúdo e os que tiverem as versões mais recentes de navegadores ainda o vejam de uma forma mais completa. 
As folhas de estilo facilitam o trabalho de um Web design quando se trata de garantir uma formatação homogênea e mais criativa por todas as páginas de um Web site e ainda permite mais interatividade com o usuário. Mesmo que se deseje mudar todo o design, ou um certo grupo de formatação, as folhas de estilo permitem que uma alteração possa repercutir em todas as páginas do Web site. 
As folhas de estilo podem ser comparadas a um gabarito de formatação de páginas HTML. Ela permite que se alterem quase todas as tags da linguagem HTML. Sua limitação está na falta de reconhecimento por algumas versões de navegadores, sendo utilizada, portanto, como uma linguagem complementar ao HTML. 
As instruções de CSS são inseridas entre as tags <STYLE > e </STYLE>. Basta que se insira uma vez a tag no código para que toda a página responda às instruções (Bos, 2003). 
 
2.2.3.2 - HTML 
A linguagem HTML foi criada com o objetivo de dar à rede mundial de computadores um aspecto gráfico. Até a criação de HTML, as ferramentas existentes, tais como ftp, gopher e telnet, rodavam em terminais de caracteres e, apesar de muito úteis e bastante populares no meio acadêmico, eram muito pouco atrativas para o grande público. 
A HTML, em conjunto com o protocolo HyperText Transfer Protocol (HTTP) e com os navegadores, foi a responsável pela popularidade da Internet. Não se trata de uma linguagem de programação propriamente dita, mas de uma linguagem de formatação, que define um conjunto de tags que afetam a maneira como os documentos são exibidos pelo navegador. A HTML consiste em uma linguagem de descrição de textos que é usada como padrão internacional para formatação dos documentos na Web, na forma de aplicação de Standard Generalized Markup Language (SGML). Para trabalhar com HTML, utiliza-se um editor de texto e um navegador para visualização (Franklint, 2001). 
 
2.2.3.3 - JavaScript 
Os scripts escritos em JavaScript podem ser colocados dentro das páginas HTML, pois se trata de uma linguagem de script que é processada diretamente no navegador, dispensando a ajuda de um servidor. Ao contrário da HTML que é uma linguagem estática, com a JavaScript se fazem animações com textos e imagens e diversas interatividades com usuários, sendo assim considerada um acessório da HTML. A linguagem JavaScript possibilita o uso de diversos objetos na composição de uma página. Todos eles possuem propriedades que podem ser alteradas, além disso, os objetos fornecem eventos que possibilitam que uma página execute uma ação conforme instrução de um usuário. JavaScript é uma linguagem estruturada que usa objetos, mas não é uma linguagem de programação orientada a objetos. Os objetos são usados para representar algum aplicativo. Sua utilização requer um editor de texto e um navegador para visualização (NCC, 1999). 
 
2.3 - Servidores Web (Hosts) 
Um servidor é um programa que provê algum tipo de serviço para outros programas, denominados clientes. A conexão entre clientes e servidores é implementada normalmente através de passagem de mensagens, por meio de uma rede, utilizando algum protocolo para codificar as requisições dos clientes e as respostas do servidor (Haddleton, 1997). 
Um Web site é um conjunto de documentos ou páginas com padrão Web, que pode ser acessado através da rede mundial Internet. Estes documentos têm um endereço próprio (também chamado domínio) que está localizado na máquina servidora Web. No Brasil este endereço (domínio) é autorizado/fornecido pela Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP). 
Existem muitos tipos de servidores Web, com várias alternativas de recursos, inclusive gratuitos, no Brasil e no Exterior. Servidor é a denominação mais comum dada a um computador permanentemente conectado à Internet, de forma que usuários possam acessar os arquivos desses servidores, bastando fazer uso de um computador conectado à Internet. 
As páginas disponíveis na Internet permitem vários tipos de interatividades com o usuário. As páginas feitas basicamente em HTML oferecem pouca interatividade. Sua interatividade limita-se em clicar em links para abrir uma nova página, copiar conteúdos e fazer download de arquivos (Chase, 2000). 
Linguagens como CSS e JavaScript oferecem auxílio ao HTML para que as páginas tenham um pouco mais de interatividade e movimento. Porém a CSS não é reconhecida por todos os navegadores e o JavaScript, pode ser desabilitado dos navegadores, pelos usuários. 
Devido a essas limitações são que foram criados os servidores de páginas dinâmicas, que são softwares que trazem recursos para interpretar determinados códigos e extensões de arquivos. Com isso o usuário não fica privado dos recursos utilizados no desenvolvimento, pois é o software servidor de páginas dinâmicas que se encarregará de processar os arquivos com as extensões por ele reconhecidas e devolver ao usuário o HTML gerado. Isso possibilita o desenvolvimento dinâmico e mais interatividade nas páginas, independente do navegador, conforme mostrado na Seção 2.2.3. 
Destacam-se a seguir alguns servidores Web. 
 
2.3.1 - Apache 
O Apache é um software livre (GPL) que funciona como um servidor Web, tanto no Linux como no Windows. O Apache é um projeto de desenvolvimento colaborativo com objetivo de desenvolver o melhor servidor Web em performance, robustez, flexibilidade e com padrões de excelência e qualidade. O Apache tem em seu grupo de trabalho programadores das Universidades MIT, Berkeley, Stanford e empresas como IBM, Sun, HP, Compaq, RedHat e diversas outras. 
Entre suas principais características está multi-plataforma, robustez, performance, adaptabilidade, gratuidade e boa documentação. Ele tem vantagens em cima dos outros servidores, como código fonte completo e uma licença irrestrita. É compatível com a especificação HTTP/1.1, permite mudanças em suas características mesmo as mais internas através da utilização de módulos (isso implica em flexibilidade) e tem sua própria API padronizando toda programação interna. (The Apache Software Fondation, 2002). 
 
2.3.2 - IIS 
O Internet Information Server (IIS) faz parte da “família” Microsoft Windows Server que é uma integração de servidores local e Web. O IIS é um software para criação e hospedagem de aplicações Web dinâmicas, gerenciamento de FTP e SMTP. O IIS é responsável pelo processamento das páginas ASP, podendo também processar páginas PHP, desde que este recurso seja instalado (Microsoft Corporation, 2003). 
 
 
 
2.3.3 - ChiliASP 
Com o lançamento do software ChiliASP da empresa ChiliSoft, para rodar em servidores Unix, Netscape e Lotus, a Microsoft deixou de ser a única responsável pelo processamento e hospedagem de páginas ASP. A versão do ChiliASP foi sendo ampliada, primeiro para os servidores Netscape e Solaris e mais tarde para outras versões do Unix(incluindo Linux). A ChiliSoft não foi contratada pela Microsoft para oferecer estes serviços, mas a Microsoft também não foi totalmente contra as realizações da ChiliSoft em expandir a tecnologia Microsoft para outros servidores. 
O ChiliASP oferece suporte completo a ASP, incluindo objetos como Session e Request, mesmo sendo a Microsoft, a proprietária dessa tecnologia. Isso significa que é possível usar uma base Unix para desenvolver e processar scripts ASP. 
O que ocorre é que está havendo uma certa resistência dos profissionais da Web em aceitar trabalhar com a tecnologia Unix ASP. A questão é sobre até que ponto é viável utilizar uma tecnologia base do Windows em um ambiente Unix. Uma possível resposta referente a plataforma Windows é que há um número vasto de ferramentas de desenvolvimento e desenvolvedores experientes que usam essas ferramentas. Muitas empresas querem utilizar as ferramentas disponíveis no Windows e a experiência que têm ao trabalhar com serviços de Internet e Intranet, o que não significa que aplicativos desenvolvidos em Windows tenham que ser mantidos no IIS e no Windows NT/2000. Há empresas que preferem usar a praticidade e a versatilidade do Windows e o desempenho, segurança e estabilidade do Unix como servidor, de Internet e Intranet. Além disso, muitas tecnologias do Windows poderiam ser utilizadas no servidor Unix, como o desenvolvimento de aplicações com VBScript e ASP, sem a necessidade de um desenvolvedor ter que aprender a programar em uma nova linguagem ou usar uma nova tecnologia (Sun.com, 2003), (Yager, 1999). 
O que se pode afirmar que é constante na Web são as mudanças. Se por um lado isso faz com que novos recursos, linguagens e ferramentas sejam disponibilizadas, por outro lado traz dificuldades para que os profissionais conheçam o que há disponível. Na maioria das vezes é difícil adotar uma linguagem, ferramenta ou servidor de páginas dinâmicas e considerar como sendo a melhor solução para todas a situações. Há profissionais que preferem fazer uso de codificação manual, outros preferem usar ferramentas de design e codificação. Para um usuário dos sistemas UNIX/LINUX, uma solução pode ser a utilização de linguagens, editores e demais ferramentas que melhor se adaptem aos servidores utilizados por estes sistemas. Uma outra questão que pode auxiliar na escolha de recursos é fazer uma análise das necessidades específicas de cada domínio e encontrar as melhores soluções para tais necessidades. 
CONCLUSÃO
Este trabalho mi fé ver quanto reuso que ter no merca tecnológico hoje no mercando atual pôs atrás deste trabalho pude ver o quanto recuso já existir para que possamos contra e utilizar da melhor maneira possível temos ferramentais para o desenvolvimento varais sistemas e sim como outros que fás com que nossa vida seja mais fácil na hora de elabora um projeto que tenha não só como terma web mais sim como a formação de diagramas relacionando como a realidade do sistema que está trabalhado. 
REFERÊNCIAS
http://www.guilhermepontes.eti.br/sgbd/revisao.pdf
https://msdn.microsoft.com/pt-br/library/cc580626.aspx
http://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
http://www.aedb.br/seget/arquivos/artigos06/304_Artigo_SEGET.pdf
http://www.marcelohsantos.com.br/aulas/downloads/apostilas/Apostila_Java_B.pdf
http://www.ufpa.br/cdesouza/teaching/es/3-OO-concepts.pdf
http://pt.slideshare.net/dnunespro/tecnologias-web-20-38672827?related=1
https://docs.kde.org/trunk4/pt_BR/kdesdk/umbrello/uml-basics.html
analise edesenvolvimento de sistemas
fernando antonio dos santos
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual para 4º Semestre
“Desenvolvimento de Sistema II”
Maceió
2015
fernando antonio dos santos
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual para 4º Semestre
“Desenvolvimento de sistemas II”
Trabalho de apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de: análise orientada a objetos II e banco de dados II e programação orientada a objetos e programação web I e seminário IV 
 Professores: Luís Claudio Perini e Roberto Y. Nishimura e márcio roberto chiaveli e Veronice de Freitas e Adriane Ap. Loper 
Maceió
2015
Figura 1 – Diagrama de Entidade e Relacionamento
Figura 3 – Diagrama de Estrutura de Dados
Figura 4 – Diagrama de Estrutura de Dados na 1FN
Figura 5 – Diagrama de Estrutura de Dados na 2FN
Figura 6 – Diagrama de Estrutura de Dados na 3FN
Figura 1 – Diagrama de Entidade e Relacionamento
Figura 3 – Diagrama de Estrutura de Dados
Figura 4 – Diagrama de Estrutura de Dados na 1FN
Figura 5 – Diagrama de Estrutura de Dados na 2FN
Figura 6 – Diagrama de Estrutura de Dados na 3FN