portfólio individual.doc

Prévia do material em texto

3
Sistema de Ensino Presencial Conectado
análise e desenvolvimento de sistemas
BRYAN SECONELLO GUEDES
portfólio individual
4º SEMESTRE
Campo Novo do Parecis – MT
2014
BRYAN SECONELLO GUEDES
produção textual interdisciplinar - individual
4º SEMESTRE – 2014/2
Trabalho apresentado ao Curso Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para as disciplinas Banco de Dados II, Análise Orientada a Objetos II, Programação Orientada a Objetos e Programação para Web I.
Professores: Roberto Y. Nishimura, Anderson Emílio M. Gonçalves, Marcio Roberto Chiaveli e Veronice de Freitas. 
Campo Novo do Parecis – MT
2014
SUMÁRIO
1 INTRODUÇÃO	4
2 DESENVOLVIMENTO	5
2.1 segurança no desenvolvimento de aplicações web	5
2.2 dIagrama de atividade (UML)	5
2.3 normalização do diagrama entiDADE RELACIONAMENTO (MRN)	7
3 CONCLUSÃO	12
REFERÊNCIAS..........................................................................................................14
APÊNDICES	 .............................................................................................................15
APÊNDICE A – Modelo de Banco de Dados Esquema Conceitual “Tele cine Mozer” ....................................................................................................................................16
ANEXO B – Modelo de Banco de Dados Esquema Lógico “Tele cine Mozer”..........17
INTRODUÇÃO
O analista de sistemas deve garantir o alinhamento entre tecnologia e estratégias organizacionais, os projetos de software devem conhecer o cenário organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou mesmo reengenharia nos processos de negócio. Este trabalho mostrará na prática a importância das técnicas e o desenvolvimento do sistema que iremos utilizar a linguagem C#, através do diagrama de atividades, bem como a modelagem de dados na utilização dos consagrados bancos de dados relacionais juntamente com a programação orientada a objetos, viabilizando o sucesso dos sistemas no que tange o alinhamento dos objetivos aos processos das organizações.
DESENVOLVIMENTO
segurança no desenvolvimento de aplicações web
São aplicados requisitos de segurança em aplicações web que não recebem a atenção devida pela equipe de desenvolvimento, principalmente pelo pressuposto frágil de que uma área de segurança da organização resolverá os requisitos de segurança por meios de firewalls, sistemas de detecção de instruções, algoritmos e protocolos de criptografia. Trata-se do mito de que as vulnerabilidades de segurança serão tratadas pela implementação, a posterior, de uma camada provida por soluções periféricas que atendam aos princípios tradicionais de segurança definidos em: identificação, autenticação, autorização, confidencialidade, integridade e administração de políticas.
Muitas vezes, o ataque é facilitado pelo fato dos programadores não se preocuparem com a qualidade dos dados. Estes dados são apresentados em retornos de eventos associados a erros, que são capturados pela aplicação, mas não tratados pelo programador. Nas tentativas de invasão, os hackers exploram as falhas das aplicações por meio de mensagens desprotegidas para saber:
Qual o sistema operacional do site onde a aplicação está sendo executada;
Qual o tipo de página (ASP, JAVA, CGI);
O tipo de banco de dados (Oracle, SQL Server, MySQL) utilizado para armazenar as informações.
Tendo em mente essas preocupações e baseando-se no estudo de caso “Telecine Mozer”,
dIagrama de atividade (UML)
É um dos diagramas que mais sofreu mudanças em seu meta-modelo, desde seu surgimento no UML 1.0. neste diagrama uma atividade é modelada como uma sequencia estruturada de ações, controladas potencialmente por nós de decisão e sincronismo. Em seu aspecto mais simples, um diagrama de atividade pode ser confundido com um fluxograma. Entretanto, ao contrario de fluxogramas, os diagramas de atividades UML suportam diversos outros recursos, tais como partições e os nós do tipo fork e merge, além da definição de regiões de interrupção, que permitem uma modelagem bem mais rica do que simplesmente um fluxograma.
Para melhor entendimento do diagrama de atividades, será utilizado o estudo de caso “TELECINE MOZER”, proposto para realização deste material.
Existe uma série de características no estudo de caso. No entanto deve-se atentar-se primeiramente as restrições de que o usuário (cliente) poderá ter quanto a locação dos filmes pelo site, quando este utilizar sua senha previamente gerada pelo último boleto pago. Então partimos do ponto inicial até a primeira ação do cliente quando se entra no site para fornecer suas credenciais de login, ou seja, seu nome de usuário, mais a sua nova senha mensal gerada, após as informações serem digitadas, o site deve fazer a verificação dessas credenciais, como mostra a figura abaixo:
Ao submeter as credenciais para aprovação o sistema deve verificar o nome do usuário, a nova senha gerada, e se a ultima mensalidade está em aberto. Logo o diagrama terá o seguinte formato:
Dessa forma o sistema só dará acesso ao usuário se as credenciais informadas realmente forem as corretas, e se a mensalidade cujo boleto gerou a nova senha mensal, estiver paga.
Tendo acesso ao sistema o usuário poderá entrar na biblioteca de filmes e decidir se irá reservar ou não um. Caso ele tome a decisão de reservar, as informações serão gravadas no cadastro do mesmo, caso contrário, isso não acontecerá. Após uma dessas ações serem tomadas o usuário irá decidir se continua ou não no sistema, como mostra a figura abaixo:
normalização do diagrama entidade relacionamento (mrn)
Normalização de dados é o processo formal passo a passo que examina os atributos de uma entidade, com o objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de registros.
Uma das principais regras no projeto de um Banco de Dados baseado no modelo relacional de Dados é a de “não misturar assuntos em uma mesma tabela”. Por exemplo: na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos com outros assuntos, tais como Pedidos, Produtos, etc. Essa “Mistura de Assuntos” em uma mesma tabela acaba gerando uma repetição desnecessária dos dados bem como inconsistência dos mesmos.
Normalmente após a aplicação das regras de normalização de dados, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um numero maior do que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente a necessidade de manutenção.
O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados, para verificar se estas estão corretamente projetadas. Embora existam cinco formas normais, na prática usamos um conjunto de três Formas Normais.
No estudo do caso “TELECINE MOZER”, podemos aplicar essas três formas normais. Nele podemos detectar algumas entidades básicas, entre elas a entidade Clientes.
Considerando-se que na entidade Clientes podemos ter as seguintes informações:
Código do cliente;
Nome;
Data de Nascimento
Endereço;
Filiação;
Documentos Pessoais;
Telefone.
A tabela com os dados estaria na seguinte forma:
	Cód_Cli
	Nome
	Data N.
	Endereço
	Filiação
	Doc. P.
	Telefone
	001
	José
	31/03/78
	Rua Seis, 85, Morumbi, 12536-965
	Augusto José e Maria do Socorro
	RG: 42662342 SSP/TO
CPF: 123899345-89
	9653-6352
9847-2501
Desta forma a tabela não está na primeira forma normal. A primeira forma normal não admite repetições ou campos que tenha mais que um valor. No caso da tabela acima, se prestarmos mais atenção teremos no capo endereço mais de umainformação: rua, número, bairro e CEP. O mesmo ocorre nos campos Documentos Pessoais e Filiação. Para normalizar teremos que colocar cada informação em uma coluna diferente como no exemplo a seguir:
	Cód
	Nome
	DN
	Endereço
	Numero
	Bairro
	CEP
	Pai
	Mãe
	RG
	CPF
	Tel.
	001
	José
	31/03/78
	Rua Seis
	85
	Morumbi
	12536-965
	Augusto José
	Maria Socorro
	42662342 SSP/TO
	123654789-54
	9653-6352
9847-2501
Mesmo com o ajuste acima, a tabela ainda não está na primeira forma normal, pois há clientes com mais de um telefone e os valores estão em uma mesma célula. Para normalizar será necessário criar uma nova tabela para armazenar os números dos telefones e o campo chave da tabela cliente (FK: chave estrangeira). O resultado ficaria assim:
Tabele Cliente:
	Cód_Cliente
	Nome
	DN
	Endereço
	Numero
	Bairro
	CEP
	Pai
	Mãe
	RG
	CPF
	001
	José
	31/03/78
	Rua Seis
	85
	Morumbi
	12536-965
	Augusto José
	Maria Socorro
	42662342 SSP/TO
	123654789-54
Tabela Telefone:
	Cód_telefone
	Cod. Cliente
	Telefone
	001
	001
	9653-6352
	002
	001
	9847-2501
Desta maneira a primeira forma normal aplicada no estudo do caso “TELECINE MOZER” para o cadastro de clientes seria satisfeita.
A segunda forma normal visa identificar os atributos que não são funcionalmente dependentes de toda a chave primária para removê-los da entidade e criar uma nova entidade com eles. Assim a chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.
No estudo do caso “TELECINE MOZER” podemos identificar mais uma entidade que será utilizada para armazenar as informações de locação dos clientes. Esta entidade conterá as seguintes informações:
Código da Locação;
Data da Locação;
Código do Cliente;
Nome do Cliente;
Código do Filme;
Título do Filme;
Valor da Locação;
Data da Exibição do Filme;
Horário da Exibição do Filme.
Vejamos então a tabela com os correspondentes dados:
	Cód_Locação
	Data_Loc.
	Cód_Cli
	Nome_Cliente
	Cód_Filme
	Título
	Valor
	Data_Exib.
	Horário_Exib.
	001
	23/10/2014
	001
	José
	001
	O Predador
	2,50
	31/10/2014
	20:00
Pode-se notar que a tabela acima não está na segunda forma normal, pois o nome do Cliente depende do Código do Cliente, mas não depende do Código da Locação. Isto gera problemas com a manutenção dos dados, pois se houver alteração no nome do Cliente, teremos que alterar em todos os registros da tabela Locação. Para normalizar esta tabela teremos que excluir o campo “Nome do Cliente” e manter apenas o campo “Código do Cliente” para reutilizarmos a tabela Cliente mostrada anteriormente. Da mesma forma, criaremos uma nova entidade Filmes, que terão os atributos Código_Filme, Título, Gênero, Sinopse, Valor.
Vejamos o resultado:
Tabele Cliente:
	Cód_Cliente
	Nome
	DN
	Endereço
	Numero
	Bairro
	CEP
	Pai
	Mãe
	RG
	CPF
	001
	José
	31/03/78
	Rua Seis
	85
	Morumbi
	12536-965
	Augusto José
	Maria Socorro
	42662342 SSP/TO
	123654789-54
Tabela Telefone:
	Cód_telefone
	Cod. Cliente
	Telefone
	001
	001
	9653-6352
	002
	001
	9847-2501
Tabela Filmes:
	Cód_Filme
	Titulo
	Gênero
	Sinopse
	Valor
	001
	O Predador
	Ação
	Em uma terra assombrada...
	2,50
Tabela Locações:
	Cód_Locação
	Data_Loc.
	Cód_Cli
	Cód_Filme
	Data_Exib.
	Horário_Exib.
	001
	23/10/2014
	001
	001
	31/10/2014
	20:00
Desta maneira a segunda forma normal estaria satisfeita.
Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela. Por exemplo:
Considerando a tabela abaixo:
	N_Pedido
	Código_Produto
	Quantidade
	Valor_Unitário
	Subtotal
	001
	001
	5
	1500
	7500
	002
	105
	3
	350
	1050
Podemos observar que o campo Subtotal armazena o resultado da multiplicação entre a Quantidade e o Valor Unitário. Para que esta tabela esteja na terceira forma normal, tem-se que eliminar este campo. Por exemplo:
	N_Pedido
	Código_Produto
	Quantidade
	Valor_Unitário
	001
	001
	5
	1500
	002
	105
	3
	350
No estudo de caso “TELECINE MOZER”, não há campos dessa espécie, logo não há necessidade de se aplicar a terceira forma normal.
Para concluir o projeto utilizando a normalização do modelo relacional de banco de dados, existe mais uma entidade não menos importante, que será utilizada para armazenar os dados de credenciais mensais dos clientes ao site “TELECINE MOZER”. Por exemplo:
	Código_Acesso
	Cod_Cliente
	Mês_Acesso
	Senha_Acesso
	Mensalidade_paga
	0342
	001
	11/2014
	E4gt67jg
	1
Esta entidade será responsável por verificar se o cliente 001 está ou não com a última mensalidade paga. Se a mensalidade não estiver paga será atribuído o valor 0, e se estiver paga, o valor 1. Sendo assim o acesso ao site dependerá não só do cadastro do cliente, como também da verificação da mensalidade paga e da nova senha gerada para o respectivo mês para aquele cliente.
CONCLUSÃO
	O desenvolvimento do projeto de uma locadora distribuída “TELECINE MOZER” via web foi uma sucesso. Com o uso de tecnologias que permitem termos bons recursos de sistema. É possível o desenvolvimento completo de uma aplicação que solucione problemas, aumentando o desempenho e aumentando a qualidade da aplicação.
Com este trabalho, conclui-se que o processo de modelagem do banco de dados com certeza merece um destaque especial em nossa avaliação, pois foi justamente por termos exercidos o trabalho de análise e programação como se profissionais fossemos, que podemos identificar e atuar na essência da profissão. Foi bastante interessante as discussões, reuniões, ponderações, dúvidas e a forma como foi desenvolvido o trabalho com pesquisa e ajuda de fóruns, pois na medida que o modelo tomava forma, ficou evidente que em projetos de sistemas, vários profissionais trabalhando em conjunto com certeza podem obter um resultado muito satisfatório para o objetivo final que é o projeto pronto, funcionando e entregue ao destino final. O trabalho proposto foi concluído com a certeza de que no decorrer deste Curso, o aprendizado e os conhecimentos adquiridos reforçam a importância de conhecermos bem os diversos benefícios trazidos pela correta aplicabilidade das ferramentas como o domínio dos conceitos de banco de dados relacionais casados ao paradigma de orientação a objetos. A pesquisa nos proporcionou a prática de programação, tão importante na concretização dos sistemas modelados e pensados.
 
 
REFERÊNCIAS
TANAKA, Simone Sawasaki. Análise de Sistemas III. São Paulo: Editora Pearson, 2014. 
Site: http://www.dca.fee.unicamp.br/~gudwin/ftp/ea976/AtEst.pdf 
APÊNDICES
ANEXOS
ANEXO A – Modelo de Banco de Dados Esquema Conceitual “Tele cine Mozer”
ANEXO B – Modelo de Banco de Dados Esquema Lógico “Tele cine Mozer”