quinta-feira, 23 de outubro de 2014

Av2 - Tec. Analise e Desenv. Sist. - Programação Orientada a Objetos

1)
Sobre o Polimorfismo, podemos afirmar que:

Alternativas:
  • a) Técnica do Desenvolvimento Orientado a Objetos para proteger dados públicos
  • b) É o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura) mas comportamentos distintos
    Alternativa assinalada
  • c) O polimorfismo permite uma classe fazer herança de varias outras classes com o mesmo nome
  • d) É a característica de existirem duas classes com o mesmo nome no mesmo pacote.
2) Quando um atributo é definido como private:

Alternativas:
  • a) Somente os métodos da própria classe tem acesso
    Alternativa assinalada
  • b) Estes atributos são somente de leitura nas classes herdadas
  • c) Somente são visíveis nas classes herdadas
  • d) Todas os objetos herdados da classe tem acesso
3) Sobre um classe selada (sealed) podemos dizer que:

Alternativas:
  • a) É uma classe que não pode ser instanciada, pois é definida para ser modelo para outros objetos.
  • b) É uma classes cujo os métodos e atributos são todos private.
  • c) Utilizada para restringir características da herança do objeto, quando uma classe é definida como sealed, está classe não poderá ser herdada
    Alternativa assinalada
  • d) Em Desenvolvimento Orientado a Objetos, significa classe usada como interface para outras classe
4) O que é uma classe abstrata?

Alternativas:
  • a) É uma classe usada para encapsular os dados através dos métodos get e set.
  • b) Serve apenas como superclasse, não existem instâncias desta classe.
    Alternativa assinalada
  • c) Classe que possui somente métodos estáticos e atributos concretos
  • d) Classe que pode ser instanciadas porem não pode ser herdada
5)
No desenvolvimento Orientado a Objetos, o que podemos dizer sobre Interfaces

Alternativas:
  • a) Meio pelo qual os dados são apresentados em ao usuário
  • b) Formulários onde são montadas as telas de um sistema
  • c) Não possui atributos, mas apenas métodos, porém não possui implementação dos mesmos.
    Alternativa assinalada
  • d)
    Artefato da Orientação a Objetos usado para definir sincronização entre dois estados de um objeto


    Sequencia 100% Very Happy
    1 - B
    2 - A
    3 - C
    4 - B
    5 - C

quarta-feira, 22 de outubro de 2014

Av1 - Tec. Analise e Desenv. Sist. - Programação Orientada a Objetos

1) Com relação a Herança em desenvolvimento orientado a objetos, podemos afirmar que:

Alternativas:
  • a) É uma característica de classes que não podem ser instanciadas.
  • b) É a capacidade que permite uma classe, receber métodos e atributos de uma classe superior reaproveitando código.
    Alternativa assinalada
  • c) É a característica de possuir dois métodos com o mesmo nome na mesma classe.
  • d) Uma alternativa para sobrecarga de métodos de classes abstratas
2) A finalidade de declarar um método ou um atributo como público é:

Alternativas:
  • a) Para que o atributo ou método de um objeto dessa classe possa ser acessado por qualquer outro objeto (visibilidade externa total).
    Alternativa assinalada
  • b) Para que a classe possa ser instanciada por qualquer outra classe
  • c) Para ser herdado nas classes pais.
  • d) Para poder ser encapsulado pelas classes herdadas.
3) Característica de proteger dados usando métodos para acessa-los.

Alternativas:
  • a) Polimorfismo
  • b) Interfaces
    Alternativa assinalada
  • c) Encapsulamento
  • d) Abstração
4) Define o comportamento da classe

Alternativas:
  • a) Construtor
  • b) Métodos
    Alternativa assinalada
  • c) Propiedades Publicas
  • d) Herança
5) Define a visibildade de métodos e atributos

Alternativas:
  • a) Polimorfismo
  • b) Private
    Alternativa assinalada
  • c) Herança
  • d) Sobrecarga de metodo



    Sequencia 100% correta
    1 - b
    2 - a
    3 - c
    4 - b
    5 - b

segunda-feira, 20 de outubro de 2014

Portfolio Individual - Curso Superior de ADS - IV Semestre



 SISTEMA DE ENSINO PRESENCIAL CONECTADO
CURSO SUPERIOR DE TECNOLOGIA EM
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

WANDERLEY NUNES CRISTO



DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO II


Produção Textual Interdisciplinar – Portfolio


Trabalho apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas à Universidade Norte do Paraná - UNOPAR, para as disciplinas Banco de Dados II, Análise Orientada a Objetos II, Programação Orientada a Objetos, Programação para Web I e Seminários IV.
Prof.: Roberto Y. Nishimura, Anderson Emídio M.Gonçalves, Marcio Roberto Chiaveli e Prof.ª Veronice de Freitas.
Tutor eletrônico: Jose Henrique Lopes Oliveira Bento
Tutor de sala: Rosinaldo Leão dos Santos


Breves
2014


SUMÁRIO
1 INTRODUÇÃO ..................................................................................................... 3
2 OBJETIVO ........................................................................................................... 4
3 SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB..................... 5
3.1 VULNERABILIDADES COMUNS ..................................................................... 6
3.2 UTILIZAÇÕES DE FIREWALLS E PROTOCOLO HTTPS. .............................. 7
3.2.1 FIREWALLS .................................................................................................. 7
3.2.2 HTTPS: ......................................................................................................... 8
4 DIAGRAMA DE ATIVIDADE (UML) ..................................................................... 9
4.1 CONCEITOS USADOS NOS DIAGRAMAS DE ATIVIDADES ......................... 9
4.2 ESTADO DE ATIVIDADE E ESTADO DE AÇÃO ........................................... 10
4.3 EXEMPLO DE DIAGRAMA DE ATIVIDADE .................................................. 11
5 NORMALIZAÇÃO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN) ... 12
5.1 MODELO ENTIDADE RELACIONAMENTO (MER) ....................................... 12
5.2 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) .................................... 12
5.3 NORMALIZAÇÃO ........................................................................................... 13
5.4 DER NORMALIZADO ..................................................................................... 15
6 CONCLUSÃO .................................................................................................... 16
REFERÊNCIAS ...................................................................................................... 17

1  INTRODUÇÃO

Hoje os serviços disponibilizados para uma infinidade de situações estão mudando cada vez mais para a plataforma WEB, isso ocorre devido a facilidade que essa plataforma proporciona. Porém, nem sempre, as aplicações desenvolvida para essa plataforma atendem os requisitos básicos de segurança da informação, confiabilidade da informação e disponibilidade da informação. Nesse trabalho, além de abordarmos esse pontos, também falaremos de diagramas de atividade e normalização de um Diagrama de Entidade Relacionamento.
2  OBJETIVO

Este trabalho tem por objetivo levar o aluno a conhecer os problemas básicos que ocorrem no desenvolvimento de aplicações WEB, tendo como foco a segurança no desenvolvimento de aplicações WEB. Os conceitos básicos de um Diagrama de Atividade e suas características e a Normalização de dados no Diagrama Entidade Relacionamento.
3  Segurança no desenvolvimento de Aplicações Web

                            Atualmente as vulnerabilidades nas aplicações web são o maior vetor para os ataques contra a segurança de TI. Os artigos no noticiário acerca dos ataques que comprometem os dados confidencias frequentemente mencionam o método usado sendo “cross-site scripting”, “SQL injection” e “erros de configurações de websites”. Muitas vezes as vulnerabilidades deste tipo estão fora da experiência tradicional dos administradores de segurança de TI. Esta relativa obscuridade das vulnerabilidades dos aplicações web faz deles alvos atrativos para atacantes. Como muitas organizações têm descoberto, esses ataques evadirão as defesas tradicionais das redes empresariais, e novas defesas são necessárias. As vulnerabilidades das aplicações web em geral tem origem em configurações com falhas ou em erros de programação nas linguagens usadas para aplicações web (Java, .NET, PHP, Python, Perl, Ruby, etc.). Estas vulnerabilidades podem ser complexas e podem se manifestar em muitas situações diferentes.

                            A segurança das aplicações, principalmente aquelas conectadas a uma rede aberta é perigosa como é a Internet. Essa complexidade advém do fato que as aplicações web são agrupamentos bastante heterogêneos de plataformas, bancos dedados, servidores de aplicação, etc. Uma aplicação típica, geralmente, está distribuída em vários servidores, rodando diversos aplicativos e para funcionar na velocidade adequada, a aplicação precisa que as interfaces entre os diversos sistemas sejam construídas com a premissa que os dados passados através da mesma são confiáveis e não hostis. Não há tempo hábil para duplas verificações nas aplicações e a necessidade de haver “confiança” entre os diversos subsistemas e é disso que os hackers e outros ciber criminosos se aproveitam. Para o sistema aplicativo, frequentemente desenvolvido in house ou por terceiros, especificamente para a empresa, não existem patches de segurança. Segundo o Gartner, 75% dos ataques são concentrados nos aplicativos específicos de cada empresa, pois os atacantes sabem das suas fragilidades.

3.1   Vulnerabilidades comuns

Nestes sistemas complexos, a segurança dos produtos disponíveis no mercado é assegurada pelos fabricantes, que fornecem periodicamente patches que os atualizam.

Os ataques que hoje conhecemos são baseados em vulnerabilidades típicas de aplicações web complexas. Mesmo os sistemas operacionais que são mantidos por grandes empresas, empregando milhares de profissionais, têm vulnerabilidades que são periodicamente descobertas por hackers e só se transformam em patches depois que os hackers já atacaram algumas vezes, que o problema foi comunicado ao fabricante e devidamente corrigido.

A Internet agregou outros componentes de risco, sendo muito importante o “efeito comunidade” em que os hackers e outros criminosos se julgam fazendo parte de uma “comunidade” e obrigados a compartilhar rapidamente suas descobertas. Isto significa que qualquer vulnerabilidade descoberta nas suas aplicações será rapidamente divulgada, com as ferramentas necessárias para atacá-la, e outros hackers e cibe criminosos aproveitarão as vulnerabilidades da sua aplicação. Os ataques podem causar uma série de problemas, entre os quais se podem citar:
  • Perdas Financeiras;
  • Transações Fraudulentas;
  • Acesso não autorizados a dados, inclusive confidenciais;
  • Roubo ou modificação de Dados;
  • Roubo de Informações de Clientes;
  • Interrupção do Serviço;ü  Perda da confiança e lealdade dos clientes;
  • Dano à imagem da marca.
 Os tipos mais comuns de ataques são:
  • Cross-Site Scripting
  • SQL Injection
  • Command Injection
  • Cookie/Session Poisoning
  • Parameter/Form Tampering
  • Buffer Overflow
  • Directory Traversal/Forceful Browsing
  • Cryptographic Interception
  • Cookie Snooping;
  • Authentication Hijacking

3.2   Utilizações de firewalls e protocolo HTTPS.
3.2.1   FIREWALLS

A maioria dos firewalls de rede, por se concentrar nas camadas mais baixas, não protege as aplicações da maior parte desses ataques, protege sim o acesso aos recursos de rede.

Uma nova geração de appliances está surgindo para resolver este e outros problemas, o Aplicativo Firewalls.

Fazem parte de um novo conceito, que é a defesa na camada de aplicação. Defesa das aplicações dos clientes, não padronizadas, heterogêneas, distribuídas em vários sistemas operacionais, usando diversos servidores de aplicação e de bancos de dados.

Surgiram só agora, por duas razões, primeiro a necessidade de combater ataques cada vez mais inteligentes e segundo a disponibilidade da tecnologia necessária para a criação desses appliances que necessitam monstruosa capacidade de computação.

O Gartner Group identificou como uma tendência à transformação do firewall comuns em commodities, em que a principal diferença entre os diversos appliances é o preço, pois as funcionalidades e a tecnologia são bastante similares, e o surgimento de novos líderes no Gartner Quadrante Mágico dos Firewall.
3.2.2   HTTPS:

Hypertext Transfer Protocol Secure, é uma implementação do protocolo HTTP's sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS. Essa camada adicional permite que os dados sejam transmitidos através de uma conexão criptografias e que se verifique a autenticidade do servidor e do cliente através de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443.

O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como, por exemplo, no caso de compras on-line. A existência na barra de tarefas de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do navegador utilizado) demonstra a certificação de página segura (SSL). A existência desse certificado indica o uso do protocolo HTTPS e que a comunicação entre o browser e o servidor se dará de forma segura. Para verificar a identidade do servidor é necessário abrir esse certificado com um duplo clique no cadeado para exibição do certificado.

Nas URL's dos Sites o início ficaria 'https://'. Consulte a ajuda do seu navegador para mais informações de como ele avisa sobre sites seguros. Um exemplo de conexão via HTTPS são os próprios sites da Wikipédia, em que é possível acessar e editar o conteúdo dos sites através de uma conexão segura. Através da URL é possível editar a Wikipédia em língua Portuguesa.

Conexões HTTPS são frequentemente usadas para transações de pagamentos na World Wilde Web e para transações sensíveis em sistemas de informação corporativos. Porém, o HTTPS não deve ser confundido com o menos utilizado protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660.

4  Diagrama de Atividade (UML)

Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra e serão empregados para fazer a modelagem de aspectos dinâmicos do sistema. Na maior parte, isso envolve a modelagem das etapas sequenciais em um processo computacional; Enquanto os diagramas de interação dão ênfase ao fluxo de controle de um objeto para outro, os diagramas de atividades dão ênfase ao fluxo de controle de uma atividade para outra; Uma atividade é uma execução não atômica em andamento em uma máquina de estados e acabam resultando em alguma ação, formada pelas computações atômicas executáveis que resultam em uma mudança de estado do sistema ou o retorno de um valor.

O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada (UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas sequenciais em um processo computacional.

Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.
4.1   Conceitos Usados nos Diagramas de Atividades
  • Atividades: Comportamento a ser realizado.
  • Sub-atividade: Execução de uma sequência não atômica de atividades.
  • Transição: Fluxo de uma atividade para outra.
  • Ação: Transformação.
  • Decisão: Dependendo de uma condição, mostra as diferentes transições.
  • Raia: Diferenciação de unidades organizacionais.
  • Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo tempo.
  • Sincronização (Join): Concatenação de transições vindas do Fork.
  • Objeto: O objeto da atividade.
  • Envio de sinal: Transição pra um meio externo, por exemplo, um hardware.
  • Recepção de sinal: Recepção do envio.
  • Região: Agrupamento de uma ou mais atividades.
  • Exceção: Atividades que ocorrerem em decorrência de uma exceção.

                            Os diagramas de atividade costumam conter:
  • Estado de atividade e estado de ação.
  • Transições
  • Objetos

4.2   Estado de atividade e estado de ação

                            No fluxo de controle modelado por um diagrama de atividade é onde as atividades acontecem. É possível calcular uma expressão que defina um conjunto de valor de um atributo ou que retorne algum valor. Alternativamente, você poderá chamar uma operação num objeto, enviar um sinal a um objeto ou até criar ou destruir um objeto. Estas computações atômicas executáveis são chamados estado de ação.

Os estados de ação não podem ser decompostos. Além disso, os estados de ação são atômicos, significando que os eventos poderão ocorrer, mas o trabalho de estado de ação não é interrompido. O trabalho de estado de ação é geralmente considerado como ocupando um tempo de execução insignificante.

Em contraste, os estados de atividade podem ser decompostos, suas atividades sendo representadas por outros diagramas de atividades. Além disso, os estados de atividade são não-atômicos, significando que poderão ser interrompidos e, em geral, são considerados como tomando algum tempo para serem completados.
4.3   Exemplo de Diagrama de Atividade

5  Normalização do Diagrama Entidade Relacionamento (MRN)
5.1   Modelo entidade relacionamento (MER)

Em engenharia de software, um modelo entidade relacionamento (modelo ER) é um modelo de dados para descrever os dados ou aspectos de informação de um domínio de negócio ou seus requerimentos de processo, de uma maneira abstrata que em última análise se presta a ser implementada em um banco de dados, como um banco de dados relacional. Os principais componentes dos modelos ER são entidades (coisas) e os relacionamentos que podem existir entre eles, e bancos de dados.

Um modelo entidade relacionamento é uma maneira sistemática de descrever e definir um processo de negócio. O processo é modelado como componentes (entidades) que são ligadas umas às outras por relacionamentos que expressam as dependências e exigências entre elas, como: um edifício pode ser dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado em apenas um edifício. Entidades podem ter várias propriedades (atributos) que os caracterizam. Diagramas criados para representar graficamente essas entidades, atributos e relacionamentos são chamados de diagramas entidade relacionamento.

Um modelo ER é normalmente implementado como um banco de dados. Nos casos de um banco de dados relacional, que armazena dados em tabelas, as próprias tabelas representam as entidades. Alguns campos de dados nestas tabelas apontam para índices em outras tabelas. Tais ponteiros representam relacionamentos.

5.2   Diagrama Entidade-Relacionamento (DER)

O Diagrama Entidade-Relacionamento descreve toda estrutura lógica do banco de dados. É possível construí-lo a partir de um MER, identificando assim a partir de um conceito do mundo real como os dados serão armazenados de fato.

O DER tem como ênfase os dados e os relacionamentos. Sua representação utiliza os símbolos:

    Retângulos - representam as entidades;

    Elipses - representam os atributos;

    Losangos - representam os relacionamentos entre as entidades;

    Linhas - unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de relacionamentos;

    Elipses duplas - atributos multivalorados.

Na construção de um projeto de banco de dados é necessário saber quais são os objetos e os relacionamentos para elaborar o DER, ou seja, descobrir quais os atributos que compõem as tabelas (objetos).

5.3   Normalização

A utilização do MER nos proporciona a criação de um DER (Diagrama de Entidades e Relacionamento). Os DER fazem uma representação de parte de um mundo real onde são feitas representações estruturadas e conceituais do que o ser humano pode fazer nessa parcela do mundo real.

A princípio, Peter Chen propôs como notação desses diagramas os retângulos como sendo as entidades, os losangos como sendo os relacionamentos entre as entidades, os círculos como sendo os atributos das entidades e linhas de conexão para mostrar a cardinalidade entre uma entidade e outra.

Ao aplicar esse sistema de Relacionamento, existem uma série de passos para fazer com que os dados tornem-se menos redundantes e menos inconsistentes. Tais passos são chamados de Normalização de dados. A primeira forma normal foi definida por Edgar F. Codd em 1970. Essa norma tinha como definição permitir que os dados fossem questionados e manipulados usando uma "sub-linguagem de dados universal" atrelada à lógica de primeira ordem. Nem sempre essa normalização é eficiente, dependendo da separação entre o projeto lógico da base de dados e a implementação física do banco de dados.

Para normalização é feito um trabalho sobre as restrições que indicam relações individuais, isto é, as restrições relacionais. O propósito destas restrições é descrever o universo relacional, ou seja, o conjunto de todas as relações que são permitidas para serem associadas com certos nomes de relação. Dentre essas restrições relacionais, a mais importante é a Chave, a qual vai relacionar um registro com um ou mais valores de índice.

Existem hoje diversas normas formais, cada uma gerando aprimoramentos em relação à norma anterior. Abaixo as normas e definições:

Primeira Norma Formal: Uma tabela está na 1FN, se e somente se, não possuir atributos multivalor.

Segunda Norma Formal: Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente da chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas parte da chave.

Terceira Norma Formal: Uma relação R está na 3FN, se estiver na 2FN e cada atributo não-chave de R não possuir dependência transitiva, para cada chave candidata de R.

Quarta Norma Formal: Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas.

5.4   DER Normalizado

6  CONCLUSÃO

Nos dias atuais é impensável desenvolver uma aplicação sendo ela para qualquer plataforma sem pensar em um item essencial chamado segurança. Esse trabalho de pesquisa trouxe conhecimentos que serão extremamente uteis para quem pretende trabalhar com esse tipo de desenvolvimento. A segurança das aplicações voltadas para a Web é um dos requisitos básicos para termos uma aplicação funcionado de forma adequada, disponibilizado para os clientes toda a segurança que sempre queremos ao utilizar qualquer serviço.

Estuda um pouco mais sobre Diagrama de atividade melhorou bastante o entendimento sobre o mesmo, quando devemos implementar o diagrama, e os benefícios de sua utilização dentro do projeto de desenvolvimento.

A normalização dentro de um projeto é fundamental para um correto funcionamento da aplicação e principalmente do banco de dados. Pesquisar um pouco mais sobre a Normalização no Diagrama Entidade Relacionamento (DER) só veio a enriquecer ainda mais o conhecimento adquirido durante o semestre.

REFERÊNCIAS

ANHANGUERA NITERÓI, Banco de Dados I. Disponível em: (https://sites.google.com/site/uniplibancodedados1/aulas/aula-4---modelo-entidade-e-relacionamentos) Acesso em: 19 de outubro de 2014.

DEVMEDIA.COM.BR, Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). Disponível em: (http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332) Acesso em: 19 de outubro de 2014.

GUILHERMEPONTES.ETI.BR, Revisão. Disponível em: (http://www.guilhermepontes.eti.br/sgbd/revisao.pdf) Acesso em: 19 de outubro de 2014.

MACORATTI.NET, .NET - Implementando Soluções OOP II. Disponível em: (http://www.macoratti.net/11/09/net_ioop2.htm) Acesso em: 19 de outubro de 2014.

OWASP.ORG, As 10 vulnerabilidades de segurança mais críticas em aplicações WEB. Disponível em: (https://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf) Acesso em: 19 de outubro de 2014.

SITEBLINDADO.COM, Segurança Para aplicações Web. Disponível em: (http://www.siteblindado.com/pt/pags/view/files/WhitePaper+QualysGuard+Vulnerability+Web+Applications.pdf) Acesso em: 19 de outubro de 2014.

WIKIPEDIA, Diagrama de atividade. Disponível em: (http://pt.wikipedia.org/wiki/Diagrama_de_atividade) Acesso em: 19 de outubro de 2014.

WIKIPEDIA, Modelo entidade relacionamento. Disponível em: (http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento) Acesso em: 19 de outubro de 2014.


Clique ao lado para ver o trabalho (Portfolio Individual- Curso Superior de ADS - VI Semestre

Portfolio Individual - Curso Superior de ADS - VI Semestre

SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS WANDERLEY NUNES CRISTO PRO...