1. SISTEMA DE ENSINO PRESENCIAL CONECTADO
NOME DO CURSO
NOME DO(S) AUTOR (ES) EM ORDEM ALFABÉTICA
JEAN PIERRY DE FREITAS FERREIRA
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
PRODUÇÃO TEXTUAL INDIVIDUAL
4º Semestre

2. Maravilha SC
2015
Maravilha SC
2015
JEAN PIERRY DE FREITAS FERREIRA
PRODUÇÃO TEXTUAL INDIVIDUAL
4º Semestre
Trabalho de Analise e Desenvolvimento de Sistemas
apresentado à Universidade Norte do Paraná - UNOPAR,
como requisito parcial para a obtenção de conceito nas
disciplinas de Análise Orientada a Objetos II; Banco de
Dados II; Programação Orientada a Objetos;
Programação Web I.
Professores: Luis Claudio Perini; Roberto Y. Nishmura;
Márcio Roberto Chiaveli; Veronice de Freitas; Adriane Ap.
Loper.
JEAN PIERRY DE FREITAS FERREIRA

3. SUMÁRIO
1 INTRODUÇÃO...................................................................................................................3
2 OBJETIVO .........................................................................................................................4
3 DESENVOLVIMENTO .................................................................................................5
3.1 Analise Orientada a Objeto II................................................................................5
3.1.1 UMl...........................................................................................................................5
3.1.2 Diagrama de Caso de Uso.............................................................................7
3.1.3 Diagrama de Classes .........................................................................................8
3.1.4 Diagrama de objetos.........................................................................................9
3.1.5 Diagrama de Colaboração.............................................................................10
3.1.6 Diagrama de Sequência
...............................................................................................................................................
11
3.2 Banco de DadosII .....................................................................................................12
3.2.1- Modelo Relacional Normalizado- MRN
..................................................................................................................................................
12
3.3 Programação Orientada a Objetos.....................................................................15
3.4 Programação Web I..................................................................................................17
4 CONCLUSÃO.................................................................................................................21
REFERÊNCIAS BIBLIOGRÁFICAS
..................................................................................................................................................
22

4. 1 INTRODUÇÃO
A todo o momento nos deparamos com novas invenções e novas
maneiras para fazer uso da tecnologia, tendo sempre o objetivo de facilitar a vida do
ser humano.
Com o decorrer do tempo as organizações foram sistematizando
suas operações e sua maneira de enviar, receber e armazenar informações. Isso fez
com que o homem mudasse seu comportamento, sua maneira de trabalho, para
conseguir incorporar ao seu cotidiano os novos métodos propostos pelas inovações
tecnológicas.
Neste trabalho serão apresentados os conceitos abordados nas
disciplinas de estudo, os passos necessários para que seja elaborado um sistema
satisfatório, partindo da análise, passando pela modelagem, criação e
implementação, tendo como base a relação existente entre o ser humano e as
tecnologias, as maneiras de usá-las, custo-benefício, segurança na troca e no
armazenamento de informações.
3

5. 2 OBJETIVO
Trabalhar o conteúdo do eixo temático, incentivar a interatividade e a
regionalidade e auxiliar na aplicação dos conceitos estudados.
4

6. 3 DESENVOLVIMENTO
3.1 Análise Orientada a Objetos II
3.1.1 Diagramas da UML.
A Linguagem Unificada de Modelagem possui diagramas
(representações gráficas do modelo parcial de um sistema) que são usados em
combinação, com a finalidade de obter todas as visões e aspectos do sistema.
Os Diagramas da UML estão divididos em Estruturais e
Comportamentais.
No grupo de diagramas estruturais temos os de classes, de objeto,
de componentes, de implantação, de pacotes e de estruturas.
No grupo de diagramas comportamentais temos os de caso de uso,
de maquina de estados, de atividades, de interação, este último se divide em
sequência, interação, comunicação e tempo.
3.1.1.1 Diagrama de classes
O diagrama de classes representa a estrutura do sistema,
recorrendo ao conceito de classe e suas relações. O modelo de classes resulta de
um processo de abstração onde são identificados os objetos relevantes do sistema
em estudo. Um objeto é uma ocorrência que tem interesse para o sistema em
estudo e que se pretende descrever no seu ambiente, contendo identidade e
comportamento. O comportamento de um objeto define o modo como ele age e
reage a estímulos externos e a identidade de um objeto é um atributo que o
distingue de todos os demais, sendo preservada quando o seu estado muda. Um
objeto não é mais do que uma instância da classe.
Este diagrama é fundamental e o mais utilizado na UML e serve de
apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes
com seus atributos e métodos e os relacionamentos entre classes.
Um diagrama de classes pode oferecer mais de uma perspectiva,
cada uma para um tipo de observador diferente:
5

7. Conceitual, destinada ao cliente:
Especificação, destinada as pessoas que não necessitam saber da parte de
desenvolvimento
6

8. Implementação, destinada as pessoas que participam do desenvolvimento
3.1.1.2 Diagrama de Objeto
Mostram uma fotografia de um sistema OO em execução: mostrados
os objetos, com os valores de seus atributos e as ligações entre eles.
Permite um maior entendimento do problema e úteis para a
modelagem de estruturas de dados complexas, focando apenas uma parte dos
objetos.
Diagramas de objetos são usados quando não se consegue
entender o resultado que será obtido pelo diagrama de classe e para mostrar o
instanciamento de uma classe na memória. Pode ser construído em qualquer
momento da especificação ou construção do software.
Estes diagramas são raramente usados. A única utilizada prática e
direta é a de ilustrar a formação de relacionamentos complexos, como associações
reflexivas, com o objetivo de facilitar a atividade de validação.
7

9. Os Diagramas de Objetos são vistos como especiais, pois têm
conteúdo particular (instâncias de classes), mas compartilha as mesmas
propriedades comuns de todos os outros diagramas da UML.
3.1.1.3 Diagrama de caso de uso.
Representa o conjunto de comportamentos de alto nível que o
sistema deve executar para um determinado ator. É o diagrama mais simples, e não
hánecessidade de grandes detalhamentos.
A figura acima ilustra um caso de uso geral, mas é recomendado
que eles sejam desenvolvidos para cada cenário. As setas de includes e extends
indicam, respectivamente, obrigatoriedade e opção de se realizar determinadas
ações.
3.1.1.4 Diagrama de sequência
Consiste em um diagrama que tem o objetivo de mostrar como as
mensagens entre os objetos são trocadas no decorrer do tempo para a realização de
uma operação.
Em um diagrama de seqüência, temos como elementos as linhas
verticais representando o tempo de vida de um objeto (lifeline), linhas horizontais ou
diagonais que representam as mensagens trocadas entre os objetos, são
acompanhadas de um rótulo o nome da mensagem e, opcionalmente, os parâmetros
8

10. da mesma, as mensagens de retorno são representadas por linhas horizontais
tracejadas.
Exemplo de Diagrama de Sequência
3.2 BANCO DE DADOS II
3.2.1- Modelo Relacional Normalizado - MRN
O modelo relacional Normalizado é um modelo de dados,
adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de
Dados (SGBD), que se baseia no princípio em que todos os dados estão guardados
em tabelas (ou, matematicamente falando, relações). Toda sua definição é teórica e
baseada na lógica de predicados e na teoria dos conjuntos. O conceito foi criado por
Edgar Frank em 1970, sendo descrito no artigo "Relational Model of Data for Large
Shared Data Banks". Na verdade, o modelo relacional foi o primeiro modelo de
dados descrito teoricamente, os bancos de dados jáexistiam antes, passaram então
a ser conhecidos como (modelo hierárquico, modelo em rede ou Codasyl e modelo
de listas invertidas).
O MRN apareceu devido às seguintes necessidades: aumentar a
independência dos dados nos sistemas operacionais d e banco de dados; prover um
conjunto de funções apoiadas em álgebra relacional para armazenamento e
recuperação dedados; permitir processamento AD HOC(Em engenharia de software,
a expressão ad hoc é utilizada para designar ciclos completos de construção de
9

11. softwares que não foram devidamente projetado em razão da necessidade de atender
a uma demanda específica do usuário, ligada a prazo, qualidade ou custo). O modelo
relacional revelou-se o mais flexível e adequado ao solucionar os vários problemas
que se colocam no nível de concepção e implementação da Base de Dados.
A estrutura fundamental do modelo relacional é a relação (tabela).
Uma relação e construída por um ou mais atributos (campos) que traduzem o tipo de
dados a armazenar. Cada instancia do esquema (linha) é chamada de registro. O
modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados
como nos modelos que o procedem. O modelo relacional implementa estruturas de
dados organizados em relações. Porém, para trabalhar com essas tabelas, algumas
restrições precisam ser impostas para evitar aspectos indesejáveis, como: repetição
de informação, incapacidade de representar parte da informação e perda de
informação. Essas restrições são: Integridade referencial, chaves e integridades de
junções de relações.
Tabela de Modelo Relacional normalizado – Cliente Conta corrente
O Modelo Entidade Relacionamento é a base para a criação de um banco de dados.
Para realizarmos um projeto de banco de dados, podemos dividi-lo em três partes:
inicialmente o modelo conceitual, depois o modelo lógico, e finalmente o modelo
físico. Realizar os três modelos é de extrema importância para que o analista
compreenda a base de dados que ele vai criar. O administrador de banco de dados
(DBA) e o administrador de dados (AD) conseguem separar muito bem esses três
modelos
O primeiro passo e fazer o modelo conceitual; depois que ele já
estiver completo podemos transformá-lo em um modelo lógico, em que a estrutura
fica mais evidente para os analistas de sistemas e programadores. Uma vez definido
qual o SGBD a se utilizado, podemos passar esse modelo lógico para o físico. Com
o modelo físico concluído, já e possível escrever os comandos necessários para a
criação do esquema no banco de dados. Hoje em dia existem ferramentas CASE
que auxiliam o dia a dia dos analistas, DBAs e ADs.
MODELO RELACIONAL NORMALIZADO – MRN
Num projeto de banco de dados é necessário identificar os dados e
fazer com que estes representem eficientemente o mundo real. Os SGDB –
Sistemas Gerenciadores de
Bancos de Dados ou SGBDR – Sistemas Gerenciadores de Bancos de Dados
Relacionais são baseados no Modelo Relacional de Da dos, que tem o princípio de
que todos os dados são guardados em tabelas. Conceito criado por Edgar Frank
em 1970. Foi o primeiro modelo de dados descrito teoricamente. O Modelo Entidade
Relacionamento apresenta algumas situações de difícil implementação prática. Para
resolver isso, propôs um processo de Normalização de Dados (ou normalização de
tabelas) que aplica uma série de regras às tabelas de um banco de dados, para
10

12. verificar se estas estão corretamente projetadas. O objetivo da normalização é evitar
problemas provocados por falhas no projeto do banco de dados, eliminando
redundâncias e evitando problemas com inserção, eliminação e atualização de dados.
Com a normalização bem sucedida, o espaço de armazenamento de dados diminui,
as tabelas podem ser atualizadas com maior eficiência. Normalmente após a
aplicação das Regras de Normalização, algumas tabelas acabam sendo divididas em
duas ou mais tabelas. Esse processo causa a simplificação dos atributos de uma
tabela, contribuindo significativamente para a estabilidade do modelo de dados,
reduzindo-se consideravelmente as necessidades de manutenção. Uma definição
mais forte da Terceira Forma Normal de Frank foi depois proposta por Boyce Forma
Normal Boyce-Codd. Depois uma Quarta e uma Quinta Formas Normais foram
propostas, baseadas nos conceitos de dependências multivaloradas e de junção,
respectivamente:
• Primeira Forma Normal, ou 1FN
• Segunda Forma Normal, ou 2FN
• Terceira Forma Normal, ou 3FN
• Forma Normal Boyce-Codd, ou FNBC ou BCNF
• Quarta Forma Normal, ou 4FN
• Quinta Forma Normal, ou 5FN
Cada uma das formas normais representa
uma condição mais forte que a anterior na lista, mas para a maioria dos efeitos
práticos, considera-se que as bases de dado s estão normalizadas se aderirem à
Terceira Forma Normal. “Outro ponto a notar é que os projetistas de um banco de
dados não precisam normalizar até a forma normalmente mais alta possível. As
relações podem permanecer em um estado de normalização mais baixo, como 2FN,
por razões de desempenho.” (ELMASR I; NAVATHE, 2005, NISHIMURA, 2009, p.
81).
O processo é sequencial, iniciando pela 1FN. Não é possível “pular”
uma forma normal, assim como não é possível fazer uma forma normal errada e
passar para a próxima. Se uma tabela obedece às regras de uma forma normal,
esta obedece igualmente às regras das formas normais anteriores. Uma tabela está
na Primeira Forma Normal quando seu s atributos não contêm grupos de Repetição,
ou também, a 1FN requer que todos os valores de colunas em uma tabela sejam
atômicos (indivisíveis). É necessário identificar atributos que representam o
armazenamento de um mesmo dado em locais diferentes; atributos repetidos;
atributos com mais de uma ocorrência. Um a “regra de ouro” para a 1FN é não
misturar assuntos em uma mesma tabela (BATTISTI , 2004).
Exemplo de MRN
11

13. Código_cliente
Nome Telefone Rua Bairro Cep
C0000001 Joao 6684255512 Rua Getúlio Centro do 78652000
Silva Vargas endem
69
C0000002 Pedro 6599999516
Rua
Deodoro
Fonseca
Jardim
Espera
nça 75642001
Santos 96
Exemplo de DER aplicando o MRN.
3.3 PROGRAMAÇÃO ORIENTADA A OBJETOS
O c# (CSharp) é uma linguagem de programação voltada ao
desenvolvimento de sistemas orientados a objetos, porém aceita a programação
estruturada e imperativa como as utilizada em C, Pascal, entre outras. A
linguagem faz parte da plataforma .NET da Microsoft e seu mentor foi Anders
Hejlsberg, o qual hoje é Distinguished Engineer na empresa. Ele também é o
arquiteto de algumas linguagens da Borland, por exemplo, Turbo Pascal e Delphi.
Durante o desenvolvimento da .NET, algumas bibliotecas de classes – class
libraries’ foram elaboradas utilizando um compilador/linguagem chamada Simple
Managed C (SMC), contudo, em 1999, Anders e sua equipe de desenvolvimento
resolveram dar o nome de COOL. Este nome não predominou, pois em 2000 na
Profissional Developer Conference (PDC) foi apresentada a .NET e a linguagem
teve seu nome mudado e apresentado como C#
12

14. Exemplo de um programa para imprimir uma mensagem na tela:
1 // exemplo de simples programa em c#
2
3 using system; // diretiva using com espaço de no mes system.
4
5 class progMensagem // início do programa
6 { // inicio do corpo da classe (progMensagem)
7 static void Main (string [ ] args) //Métodos de execução com
parametro args.
8 { //início do corpo do método Main
9 // chamada para a Classe Console e Método de escrita
10 console.Writeline ( “primeiro programa: imprimindo mensagem na
tela”)
11 } // fim da método main
12 } // fim da classe (programa)
Neste exemplo, foi colocado em cada linha de comando um
mensagem de identificação para cada linha de código.
Um programa consiste de pelo menos uma classe definida pelo
programador. Isto significa que a pessoa que está desenvolvendo o programa deve
dar um nome para tal classe e este nome deve ser precedido pela palavra-chave
class. As palavras-chaves também chamadas de palavras reservadas, são de uso da
linguagem, não se pode criação de atributos, nomes de classes etc. com o mesmo
nome. Por exemplo, não se pode criar um atributo com o nome de console, pois ela é
uma palavra reservada e uma classe também.
13

15. CONCLUSÃO
Com o término do trabalho foi possível perceber que os conceitos
abordados nas disciplinas do Curso de Análise e Desenvolvimento de Sistemas
possuem uma vasta aplicação no sistema da “Poparome” dentre eles podemos citar
a disciplina de Linguagens de Programação e Estrutura de Dados, onde foi possível
identificar o tipo de lista ideal para o sistema da pizzaria; Banco de Dados I, onde
aprendemos como funciona um banco de dados e como trabalhar com os SGBD’s;
Organização de Computadores, onde tivemos uma noção básica de como montar
uma rede de computadores e Análise Orientada a Objetos, que tem grande
importância na parte inicial da criação do banco de dados do sistema.
Este trabalho mostrou as aplicações das teorias esplanadas nas
aulas, possibilitando ao aluno a fixação dos conteúdos abordados.
3.4 PROGRAMAÇÃO WEB I
14

16. REFERÊNCIAS
BATISTA, Gustavo Enrique de Almeida Prado Alves. Pré-processamento de dados
em aprendizado de máquina supervisionado. 2003. 232 f. Tese (Doutorado em
Ciências de Computação e Matemática Computacional) – Instituto de Ciências
Matemáticas e Computação, Universidade de São Paulo, São Carlos, 2003.
Disponível em: <http://www.teses.usp.br/teses/disponiveis/55/55134/tde-06102003-
160219/en.php>. Acesso em: jan. 2015.
ARAÚJO, Josivaldo de S. et al. Estudo comparativo de códigos paralelos
em fortran, c e java na análise de uma antena monopolo utilizando técnica
numérica de FDTD. Disponível em:
<http://www.lemag.ufpa.br/publicacoes/josivaldo_principia_pb_2006.pdf>.
Acesso em: jan. 2015.
GOMES, Anabela; HENRIQUES, Joana; MENDES, António José. Uma
proposta para ajudar alunos com dificuldades na aprendizagem inicial de
programação de computadores. Educação, Formação & Tecnologias, v. 1, 1,
maio, 2008. Disponível em:
<http://www.eft.educom.pt/index.php/eft/article/view/23/16>. Acesso em: jan.
2015.
CAMPO, Marcelo Ricardo. Compreensão visual de frameworks através da
introspecção de exemplos. 1997. 259 f. Tese (Doutorado em Ciência da
Computação) – Instituto de Informática, Universidade Federal do Rio Grande
do Sul, Porto Alegre, 1997. Disponível em:
<http://www.lume.ufrgs.br/handle/10183/17972>. Acesso em: jan. 2015.
ALEGRETTI, Francisco José Prates. Computação quântica. 2004. Disponível
em: <http://www.dct.ufms.br/~marco/cquantica/cquantica.pdf>. Acesso em: jan.
2015.
15