INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE · para o mundo real, criando uma ferramenta de...

96
CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE SISTEMAS DE INFORMAÇÃO ARTHUR BRUNORO MEIRA INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE VILA VELHA

Transcript of INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE · para o mundo real, criando uma ferramenta de...

CENTRO UNIVERSITÁRIO VILA VELHACURSO DE SISTEMAS DE INFORMAÇÃO

ARTHUR BRUNORO MEIRA

INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE

VILA VELHA

2011

2

ARTHUR BRUNORO MEIRA

INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE

Monografia do Trabalho de Conclusão de Curso de Graduação em Sistemas de Informação apresentada ao Centro Universitário Vila Velha, como requisito parcial para a obtenção do título de bacharel em Sistema de Informação, sob a orientação do Professor Marcello Novaes.

VILA VELHA2011

ARTHUR BRUNORO MEIRA

3

INVITTE ME – SISTEMA DE ENVIO DE CONVITES ONLINE

Trabalho de Conclusão do Curso apresentado como pré-requisito para obtenção do título de Bacharel em Sistemas de Informação do Centro Universitário de Vila Velha – UVV, submetida á aprovação da banca examinadora composta pelos seguintes membros:

_____________________________________ Orientador Prof. Marcello Novaes de Amorim Mestre em Informática

_____________________________________ Orientador Prof. Marcello Novaes de Amorim Mestre em Informática

_____________________________________ Orientador Prof. Marcello Novaes de Amorim Mestre em Informática

4

AGRADECIMENTOS

Motivos não faltam para agradecer as pessoas que me ajudaram durante esse período da minha vida. Agradeço aos meus pais por terem incentivado a vinda para uma nova cidade e para a conclusão do curso. Ao meu irmão que também me acompanhou de perto nessa caminhada. Aos colegas da instituição, e ao Raphael.Deixo aqui o agradecimento merecido para todos os professores da instituição.

Obrigado.

5

“Happiness is only real when shared”

(Christopher McCandless)

6

RESUMO

O Invitte me será uma aplicação web com foco na mobilidade atual via redes sociais

ou e-mail, seu principal foco é permitir que usuários da rede web possam enviar

convites para seus amigos, familiares e agregados. A aplicação também será

responsável por manter uma comunicação mais eficiente entre o convidado e o

criador do evento.

Para chegar nesse resultado foram utilizadas técnicas adquiridas ao longo do curso

de Sistemas de Informações. Utilizando padrões de Analise e de Projetos que serão

apresentadas ao longo do trabalho.

7

LISTA DE TERMOS E SIGLAS

APF Análise de Ponto de Função

API Application Programming Interface

DAO Data Access Object, em português Objetos de Acesso a Dados.

DP Domínio do Problema

GD Gerência de Dados

GT Gerência de Tarefas

HTML Hyper Text Markup Language

IDE Integrated Development Environment, em português Ambiente Integrado para Desenvolvimento.

IU Interface com o Usuário

JDBC Java Database Connectivity

JSP Java Server Pages

PF Ponto de Função

UML Unified Modeling Language, em português Linguagem Unificada de Modelagem

UVV Universidade de Vila Velha

ÍNDICE DE FIGURAS

8

FIGURA 1 – TELA DO SITE FACEBOOK....................................................25

FIGURA 2 - CASO DE USO DO SISTEMA..................................................31

FIGURA 3 - TELA DE DIAGRAMA DE CLASSES..........................................52

FIGURA 4 - TELA DIAGRAMA GERAL DO SISTEMA....................................57

FIGURA 5 - DIAGRAMA EFETUAR LOGIN.................................................58

FIGURA 6 – DIAGRAMA SEQUENCIA INCLUIR VIDEO................................59

FIGURA 7 - TELA DIAGRAMA EXCLUIR VIDEO..........................................60

FIGURA 8 - TELA DIAGRAMA INCLUIR FOTO............................................61

FIGURA 9 - TELA DIAGRAMA EXCLUIR FOTO...........................................62

FIGURA 10 - TELA DIAGRAMA INCLUIR USUÁRIO....................................63

FIGURA 11 - TELA DIAGRAMA EXCLUIR USUÁRIO....................................64

FIGURA 12 - TELA DIAGRAMA ALTERAR USUÁRIO...................................65

FIGURA 13 - TELA DIAGRAMA CRIAR EVENTO.........................................66

FIGURA 14 - TELA DIAGRAMA ALTERAR EVENTO.....................................67

FIGURA 15 - TELA DIAGRAMA EXCLUIR EVENTO.....................................68

FIGURA 16 - TELA DIAGRAMA CONFIRMAR EVENTO................................69

FIGURA 17 - TELA DIAGRAMA VIZUALIZAR EVENTO................................70

FIGURA 18 - TELA DIAGRAMA INCLUIR COMENTÁRIO..............................71

9

FIGURA 19 - TELA DIAGRAMA EXCLUIR COMENTÁRIO.............................72

FIGURA 20 - TELA DIAGRAMA CADASTRAR CONTA..................................73

FIGURA 21 - TELA DIAGRAMA CRIAR CONVITE........................................74

FIGURA 22 - TELA DIAGRAMA PUBLICAR REDES SOCIAIS........................75

FIGURA 23 - DIAGRAMA DE ESTADOS DA CLASSE CONVITE.....................76

FIGURA 24 - DIAGRAMA DE ESTADOS DA CLASSE EVENTO......................77

FIGURA 25 - DIAGRAMA DE PACOTES....................................................81

FIGURA 26 – DIAGRAMA DOMÍNIO DO PROBLEMA (DP)...........................83

FIGURA 27 - DIAGRAMA GERÊNCIA DE TAREFAS (GT)..............................84

FIGURA 28 - DIAGRAMA GERÊNCIA DE DADOS (GD)...............................85

FIGURA 29 - DIAGRAMA DE INTERFACE COM USUÁRIO (IU).....................86

FIGURA 30 - DIAGRAMA RELACIONAL....................................................88

FIGURA 31 - DIAGRAMA DE COMPONENTES...........................................90

FIGURA 32 - DIAGRAMA DE IMPLANTAÇÃO.............................................91

ÍNDICE DE TABELAS..................................................................................................

TABELA 1 - SERVIÇOS OFERECIDOS NO ALUGUEL DO SERVIDOR..............48

TABELA 2 - TABELA DE SERVIÇOS ADICIONAIS.......................................50

TABELA 3 - DICIONÁRIO DE DADOS DA CLASSE ENDEREÇO.....................53

10

TABELA 4 - DICIONÁRIO DE DADOS DA CLASSE EVENTO.........................53

TABELA 5 - DICIONÁRIO DE DADOS DA CLASSE PESSOA.........................53

TABELA 6 - DICIONÁRIO DE DADOS DA CLASSE TELEFONE......................54

TABELA 7 - DICIONÁRIO DE DADOS DA CLASSE LOG...............................54

TABELA 8 - DICIONÁRIO DE DADOS DA CLASSE SESSÃO.........................54

TABELA 9 - DICIONÁRIO DE DADOS DA CLASSE USUÁRIO........................54

TABELA 10 - DICIONÁRIO DE DADOS DA CLASSE CONTA REDE SOCIAL.....54

TABELA 11 - DICIONÁRIO DE DADOS DA CLASSE REDE SOCIAL................54

TABELA 12 - DICIONÁRIO DE DADOS DA CLASSE FOTO EVENTO...............56

TABELA 13 - DICIONÁRIO DE DADOS DA CLASSE MAPA...........................56

11

SUMÁRIO

1 INTRODUÇÃO .................................................................................... 13

2 CONCEITOS ....................................................................................... 17

3 ESPECIFICAÇÃO DE REQUISITOS ......................................................... 21

4 LEVANTAMENTO DE REQUISITOS ........................................................ 29

5 PROPOSTA TECNOLÓGICAS ................................................................ 45

ESPECIFICAÇÃO DE ANALISE ................................................................ 51

6 ESPECIFICAÇÃO DE PROJETO ............................................................. 78

7 PROJETO DE SEGURANÇA ................................................................... 92

8 CONCLUSAO ..................................................................................... 94

9 REFÊRENCIAS BIBLIOGRÁFICAS .......................................................... 95

12

1 INTRODUÇÃO

Atualmente, a facilidade ao acesso à internet é crescente nas empresas, nas residências, nos cyber`s café, com a conectividade wireless, diversos estabelecimentos já podem, como diferencial, proporcionar aos seus clientes o livre acesso da internet em seus respectivos notebooks e celulares.

Essa forma de comunicação e interatividade instantânea, além de mudar o cenário de relacionamento, altera a cultura social, ao passo que permite que as pessoas construam um cotidiano também virtual. Com essa realidade virtual que se baseia o projeto, onde a idéia de prover uma nova metodologia de se criar um evento on line. Essas redes sociais dialogam entre si - para facilitar ainda mais a divulgação de informações - e criam com naturalidade um marketing viral, muito mais impactante que diversas mídias disponíveis hoje em dia de modo tradicional.Esse novo modo de comunicar faz parte do que o campo da tecnologia e outras áreas afins do conhecimento denominam como cibercultura, ou seja, a ampliação e popularização do uso da internet e demais recursos digitais com o intuito de comunicar. Utilizando este recurso e possível prosseguir na criação de um sistema on line que possibilita a criação de um evento cujo os convidados já estão conectados virtualmente por diversas redes sociais ou email.

13

1.1 Motivação

A internet é uma ferramenta importante de comunicação, entretenimento e informação onde o conteúdo é produzido de forma colaborativa.

Os websites vêm se consolidando nos últimos anos e se tornando uma das principais ferramentas presentes na Internet para estimular os usuários a produzirem o seu próprio conteúdo. A presente comunicação se insere dentro desta pesquisa sobre comunicação colaborativa procurando aprofundar aspectos teóricos ligados a esse fenômeno que se insere dentro de uma lógica de produção em rede e de uma expansão da Internet no cenário contemporâneo. (BELTRÃO, 2009, online1).

Assim como a TV, o Rádio e outras mídias tradicionais, a Internet também começou a despertar o interesse das pessoas na forma de se comunicar. A internet é uma rede democrática, não elitizada, onde qualquer individuo pode produzir conteúdo, reclamar, elogiar e compartilhar.

Graças ao seu dinamismo as informações repercutem em grande velocidade. E neste ponto é que as redes sociais vêm ganhando forte destaque, pois graças a elas o caráter de interação social se torna evidente, ou seja, as pessoas cada vez mais se relacionam via Internet, através de sites de relacionamento, blogs e outras diversas plataformas.

Com isso se torna necessário um mecanismo que possa agregar essas pessoas a um evento real ou não criado na própria Internet, de forma automática e sem trabalho. Neste contexto, o questionamento proposto para o presente estudo é como o usuário pode inserir seu evento, analisar e se relacionar com seu público através da Internet e da comunicação mediada por computador, de forma colaborativa utilizando as Redes Sociais online.

14

1.2 Justificativa

Quem vai se manifestar nas redes sociais não deve agir por impulso. "Em qualquer mídia virtual, se 20 pessoas replicarem uma informação sua, ela será distribuída para 8.000 pessoas. É como pólvora", diz o professor Gil Giardelli. (Folha OnLine).

Por um meio fácil, rápido e certeiro, tende a visão desse projeto a garantir um estudo sobre uma ferramenta que não existe para os usuários.

Assim este projeto visa a abrir um espaço para o usuário se relacionar da internet para o mundo real, criando uma ferramenta de envio de convites onde possa agregar a contatos e amigos uma nova janela fugindo do normal.

1.3 Objetivos

1.3.1 Geral

Este projeto tem como objetivo o planejamento e o desenvolvimento de um sistema Web de envio de convites agregando contatos e usuários de outras redes sócias ou email, cuja finalidade e prover ao usuário um novo modo de se convidar alguém para uma festa ou evento.

1.3.2 Especifico

Este trabalho tem como objetivo criar um sistema, aplicando os conhecimentos adquiridos ao longo do curso de Sistemas de Informação, ajudando ao usuário a emitir convites via web.

Neste sistema será possível:

• Gerenciar diversos convites em um único ambiente• Prover tópicos de discussão dos eventos realizados.• Utilizar os comuns serviços de redes sociais, em interação com as diversas

contas.• Administração de lista de contatos.

15

1.4 Descrição dos capítulos

O trabalho está estruturado em 9 (nove) capítulos.

O capítulo 2 possui uma descrição dos principais conceitos utilizados no desenvolvimento deste trabalho.

O capítulo 3 apresenta toda parte de especificação de requisitos do sistema proposto, informando os problemas analisados, e suas respectivas soluções, bem como a diagramação e a descrição dos casos e uso e seus respectivos atores.

O capítulo 4 apresenta o levantamento de requisitos do sistema proposto. Neste capítulo são apresentados os modelos de classe e comportamental.

O capítulo 5 apresenta duas propostas tecnológicas, dentre as quais foi escolhida uma, justificando o motivo da escolha.

O capítulo 6 apresenta a especificação de análise do sistema. Este capítulo apresenta os diagramas e casos de usos ,onde cada caso de uso é descrito detalhadamente.

O capítulo 7 apresenta a especificação de projeto do sistema. Este capítulo apresenta os módulos e pacotes, onde cada pacote é descrito detalhadamente.

O capítulo 8 apresenta o projeto de segurança do sistema, com práticas necessárias a fim de que as informações estejam disponíveis no local e no momento estabelecido e de forma confiável.

O capítulo 9 apresenta a conclusão do trabalho, bem como a citação de projetos futuros.

No capítulo 10 estão as referências bibliográficas utilizadas durante a realização deste trabalho de conclusão de curso.*

16

2 CONCEITOS

Neste capitulo serão apresentados os conceitos sobre engenharia de software e suas metodologias de desenvolvimento de software. Serão apresentadas ainda informações sobre os processos quem foram utilizados para o desenvolvimento do projeto e linguagem de programação.

2.1 Desenvolvimento de Software

O processo de desenvolvimento de software pode ser compreendido como um conjunto de atividades relacionadas que tem como finalidade definir, desenvolver, testar e manter um produto de software(BEZERRA, 2003).

A seguir as etapas de desenvolvimento de um software:

1. Levantamento de requisitos: Corresponde a etapa de compreensão do problema aplicada ao desenvolvimento do software (BEZERRA, 2003).

2. Analise dos requisitos: É a etapa no qual os analistas realizam um estudo detalhado dos requisitos levantados na atividade anterior. A partir desse estudo, são construídos modelos para representar o sistema a ser construído (BEZERRA, 2003).

3. Projeto: Determina-se “como” o sistema funcionara para atender os requisitos, de acordo com os recursos tecnológicos existentes (BEZERRA, 2003).

4. Implementação: O sistema é codificado, ou seja, ocorre a tradução da descrição computacional da fase de projeto em código executável através do uso de uma ou mais linguagens de programação (BEZERRA, 2003).

5. Testes: Verificação do sistema construído, levando-se em conta a especificação realizada na fase de projeto (BEZERRA, 2003).

6. Implantação: O sistema é empacotado, distribuído e instalado no ambiente do usuário (BEZERRA,2003).

2.1.1 Modelo de Ciclo de Vida

O desenvolvimento de um sistema envolve diversas fases. Ao encadeamento específico dessas fases para a construção do sistema dá-se o nome de Modelo de Ciclo de Vida (BEZERRA, 2007).

17

2.1.1.1 Modelo de Ciclo de Vida em Cascata

Quando segue o processo em cascata, o fluxo vai de um estágio para o próximo. Entretanto, uma vez que um estágio é completado, não há volta exatamente como descer uma cascata. O processo de cascata tenta evitar alteração, proibindo mudar quando estágio está concluído. Tal estratégia protege os desenvolvedores de requisitos que mudam constantemente. Entretanto, tal processo rígido frequentemente resulta em software que não é o que o cliente deseja.Quando um problema é continuamente aprofundado. Os requisitos podem até mudar enquanto o sistema é desenvolvido (MATOS, 2003).Conforme ilustra a Figura 1, o processo de cascata é sequencial e unidirecional contendo vários estágios.

Figura 1 - Modelo de ciclo de Vida em Cascata (VICTORINO e BRASCHER, 2010)

O modelo de ciclo de vida cascata foi adotado devido às suas boas práticas para que o projeto seja bem sucedido. Este modelo é importante para o desenvolvimento do sistema, pois todo o trabalho será desenvolvido usando como base as fases nele contida.

18

2.2 UML

A UML é uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer que a UML é uma linguagem que define elementos gráficos (visuais) que podem ser utilizados na modelagem de sistemas. Esses elementos permitem representar os conceitos de paradigma da orientação a objetos. Através dos elementos gráficos definidos nesta linguagem podem-se construir diagramas que representam diversas perspectivas de um sistema (BEZERRA, 2007).

Durante uma década, Grady Booch, James Rmbaugh e Ivar Jacobson colaboraram para combinar as melhores características de seus métodos individuais de análise e projeto orientados a objetos num método unificado. O resultado chamado de linguagem de modelagem unificada (Unified Modeling Language, UML), tornou-se amplamente usado pela indústria (BOOCH, 1999).Apresenta-se a seguir os principais conceitos e artefatos da UML que foram utilizados neste projeto:

• Ator : Um ator representa um conjunto coerente de papéis que os usuários dos casos de uso desempenham quando interagem com esses casos de uso. Tipicamente, um ator representa um papel que um humano, um dispositivo de hardware, ou até mesmo um outro sistema que interage com o sistema desempenha. (G. BOOCH; J. Jacobson;L. Rumbaugh, 2005).

• Caso de Uso: Um caso de uso descreve o que um sistema (ou subsistema, classe ou interface) faz, mas ele não especifica como isso é feito. .(G. BOOCH; J. Jacobson. Rumbaugh, 2005).

• Diagrama de Casos de Uso: Corresponde a uma visão externa dos sistemas e representam graficamente os atores, casos de uso e relacionamento entre esses elementos. (BEZERRA, 2003).

• Diagrama de Classes : O Diagrama de classes é um modelo que dá suporte à visualização estática do sistema que esta sendo desenvolvido. Ele mostra as classes e os relacionamentos entre as mesmas que permanecem constantes no sistema com o passar do tempo (BEZERRA, 2003).

• Diagrama de Sequencia : Um diagrama de sequência ilustra os objetos que participam de um caso de uso e as mensagens que são passada entre eles ao logo do tempo para apenas um caso de uso. Ele é também um modelo dinâmico, que dá suporte a visualização dinâmica do sistema que está sendo desenvolvido. No diagrama é mostrada a sequência explicita de mensagens que são passadas entre objetos em uma iteração definida (BEZERRA, 2007).

19

• Diagrama de Pacotes: Mostra a decomposição do próprio modelo em unidades organizacionais e suas dependências (G. BOOCH; J. Jacobson; L. Rumbaugh, 2005).

2.3 Orientação a Objetos

A Orientação a Objetos é um paradigma de programação. Um sistema de software orientado a objetos consiste em vários objetos trabalhando junto com o objetivo de realizar as funcionalidades desse sistema. Cada objeto é responsável por tarefas especificas. É através da cooperação entre objetos que a computação do sistema se desenvolve (BEZERRA, 2003).

Com a orientação a objetos são definidos diversos conceitos como:

• Abstração: É a habilidade de selecionar aspectos essenciais de um contexto qualquer, ignorando características de menores importâncias.

• Classes: É a abstração de características relevantes do mundo real. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos.

• Atributos: São as características que um objeto pode assumir.

• Métodos: São as ações que um objeto pode realizar.

• Objetos: É a instância de uma classe, é o elemento criado a partir da classe seguindo os moldes já definida na classe.

• Mensagens: São estímulos enviados a um objeto para invocar os seus métodos, ativando um comportamento descrito na sua classe.

• Herança: É o mecanismo que uma classe pode derivar de outra classe aproveitando os sues métodos e atributos.

• Polimorfismo: É a capacidade abstrair várias aplicações diferentes em uma mesma interface.

• Encapsulamento: É ocultar o funcionamento interno e as estruturas de dados de um objeto, de forma que se utilizarem os serviços de um objeto não é necessário saber o seu funcionamento.

• Interface: É um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface.

20

3 ESPECIFICAÇÃO DE REQUISITOS

“a análise de requisitos está associada ao processo de descobrir quais são as operações que o sistema deve realizar e quais são as restrições que existem sobre elas”. (WAZLAWICK, 2004)

Esta é a fase em que o analista senta com o cliente para fazer o levantamento das funcionalidades do sistema e as restrições que existe sobre elas.

3.1 Descrição geral do Ambiente

A necessidade do sistema e parte de uma carência quando se tenta organizar diversos meios de contatar um amigo ou um membro da família.O usuário tem a necessidade de enviar inúmeros convites para seus amigos, familiares, e eles podem fazer este envio no sistema tanto para endereço de e-mail quanto para seus amigos na rede social Facebook. Para enviar os convites o usuário tem que estar cadastrado no sistema e com o perfil correto para enviar os convites.

Cada convite possui informações essências que devem ser preenchidos para que o convidado não tenha nenhuma dúvida quanto à localização, horário e do que se trata o convite. O convidado pode aceitar ou não aquele convite que foi enviado, para ele.Tem destinada a cada evento uma pagina onde quem convidou e quem foi convidado possa estar se interagindo durante ou depois da festa, enviado fotos e ou vídeos.

3.2 Análise de Problemas, Causas e Possíveis Soluções

Feita uma busca por sites que oferecem este tipo de serviço separadamente e em língua portuguesa o resultado foi que atualmente não existe nenhuma aplicação que atua diretamente no envio de convites on line.Para traçar um quadro com os problemas levantados, suas causas e seus possíveis problemas foram feita a seguinte tabela abaixo.

21

Problemas Causa Solução

Falta de tempo para distribuir os convites

Quem organiza uma festa ou um evento tem pressa e necessita de mecanismos que atuam na performance de envio dos mesmos.

O sistema permite o envio on line e rápido para seus convidados, de forma segura.

Falta da aplicação separada.

Pode se marcar um evento por um simples email.

Oferecer ao usuário uma plataforma rica de detalhes e de performance. Para que seu convite não seja somente um email.

Falta de aplicação na língua portuguesa.

Existem sites em língua inglesa, o que dificulta o entendimento do usuário.

Oferecer o Invitte me em língua português para os usuários do Brasil

Falta de mapa nos convites

Os convites enviados de forma normal, em papel, impossibilitam a impressão de mapas.

Oferecer aos usuários o envio de mapas do local do evento.

Local onde postar as fotos do evento.

Varias pessoas gostam de registrar o momento através de fotografias.

O sistema oferece ao usuário uma página do evento que possibilita o envio de fotos tiradas durante o mesmo.

Controle de convidados

O convidado muitas vezes não confirma a presença no evento ao ser convidado via email ou via papel.

O sistema irá gerenciar esse

controle.

3.3 Possíveis Propostas de Melhorias

Visando a melhoria do sistema para a integração e o envio via outras formas, segue abaixo propostas de melhorias para o sistema:

Possíveis Melhorias Aplicações no sistema

Envio dos convites via SMS

Integrar o sistema via um servidor WebService junto a uma prestadora de serviço no envio do convite via SMS.

Integração com outras redes sociais

Integrar o sistema com o micro blog Twitter

Internacionalizar o sistema

Implementar a língua inglesa e espanhola como idioma do sistema.

22

3.4 Regras de Negócio

As regras de negocio são políticas, condições ou restrições que devem ser consideradas na execução dos processos organizacionais. (BEZERRA,2002).Essas regras darão o entendimento do funcionamento da organização e ditarão o comportamento do sistema.

A tabela abaixo mostra as regras de negócio do sistema Invitte me.

Código Nome Descrição

RN01 Envio de convites

O usuário somente consguira enviar os convites se estiver cadastrado corretamente no sistema.

RN02Enviar o convite via rede social Facebook

O usuário somente conseguira enviar o convite via rede social Facebook, se o mesmo tiver e aceitar o mecanismo de integração entre os dois sistemas.

RN03 Enviar fotos para do evento.

O usuário somente conseguirá enviar fotos em formatos .jpg e de tamanho maximo de 5 MB cada.

RN04 Excluir o evento

O usuário somente conseguirá excluir o evento se for o mesmo que criou.

RN05 Confirmar a presença

O convidado somente conseguirá confirmar a presença no período de 05 dias, e se foi convidado via email ou rede social.

3.4.1 FUNDAMENTAÇÃO TEÓRICA

Este capítulo apresentará os conceitos utilizados neste projeto, sendo eles, conceitos específicos que envolvem o cenário para o desenvolvimento da pesquisa,

23

quanto, conceitos de engenharia de software, tornando mais claro o entendimento relacionado aos aspectos abordados no mesmo.

3.5 Específicos

Para entender melhor a respeito do contexto no qual a pesquisa será desenvolvida, este tópico apresentará conceitos de forma específicos para o entendimento do mesmo, tornando assim mais claro o entendimento relacionado aos aspectos abordados no projeto que será abortado.

3.5.1 Das relações sociais as redes sociais na internet

A rede social é uma das formas mais antigas de relacionamento. Os seres humanos usam da comunicação e da interatividade para desenvolverem qualquer tipo de relacionamento. Nos primórdios da humanidade, os homens desenhavam na parede das cavernas para se comunicarem com seus semelhantes. Os egípcios usavam hieróglifos. Os índios brasileiros faziam os sons dos pássaros para enviarem mensagens entre si. Surgiu o alfabeto e a escrita, língua a língua. Para facilitar a comunicação, o homem consagrou várias invenções, tais como o correio, o telégrafo, o rádio, a televisão e, uma das mais importantes, o telefone, inventado por Alexander Graham Bell em 1876.

3.5.2 A evolução da internet

O serviço de internet surgiu na Guerra Fria, para as forças armadas norteamericanas manterem a comunicação em caso de ataques inimigos que viessem a destruir seus meios convencionais de telecomunicação. No Brasil, a internet foi disponibilizada em 1995. Nessa época, se usavam modens discados, a conexão era de velocidade baixa e os sites não eram conhecidos. A internet foi evoluindo com o tempo e logo os sites brasileiros, os portais e suas salas de bate-papo começaram a chamar a atenção dos internautas. O e-mail também começou a substituir as cartas em papéis. Surge o primeiro mensageiro instantâneo, que se popularizou, denominado ICQ

1 Em uma matéria sobre redes sociais na internet e a visão de alguns gestores, disponível em:<http://www.artigonal.com/tecnologia-artigos/as-redes-sociais-na-internet-e-a-visao-de-algunsgestores-1264492.html>.

24

Após isso, as pessoas começaram a descobrir o grande meio de comunicação que estava nascendo. Segundo Morais (2009), no livro “Planejamento Estratégico Digital”, as empresas começaram a se interessar pelos sites corporativos e portais em meados de 1999, sendo que algumas delas sobrevivem até hoje, como os portais Terra <http://www.terra.com.br> e UOL <http://www.uol.com.br>.

1.3 Comunicação via redes sociais

O sistema irá contar com a principal rede social atualmente, o Facebook. Um mecanismo que carregará seus contatos e distribuirá para os mesmos, o convite do evento. Possibilitando assim uma melhor agilidade quando for criado o evento. O disparo desses convites visa uma integração e uma facilidade para que o usuário não necessite convidar um a um.

O Facebook é um site de relacionamento social lançado em 2004. Atualmente o website possui mais de 500 milhões de usuários ativos, a posição do Facebook no ranking de tráfego de visitantes do Alexa <http://www.alexa.com>, subiu do 60º lugar para 2º lugar.

Figura 1 – Tela do site Facebook

25

3.5.3 INTEROPERABILIDADE ENTRE SITES DE REDE SOCIAL

Segundo WIKIPEDIA (Interoperabilidade, 2010) a Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não) Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos. Seja um sistema de portal, seja um sistema educacional ou ainda um sistema de comércio eletrônico, ou e-commerce, hoje em dia se caminha cada vez mais para a criação de padrões para sistemas.

3.5.3.1 API(APPLICATION PROGRAMMING INTERFACE)

Segundo CIRIACO (O que é API?, 2009) podemos definir API que é um acrônimo de Application Programming Interface ou, em português, Interface de Programação de Aplicativos como um conjunto de padrões de programação que permite a construção de aplicativos e a sua utilização de maneira não tão evidente para os usuários (CIRIACO, 2009).Ainda segundo CIRIACO (O que é API?, 2009) a API é a “matrix” dos aplicativos, ou seja, uma interface que roda por trás de tudo: enquanto você usufrui de um aplicativo ou site, a sua API pode estar conectada a diversos outros sistemas e aplicativos. E tudo isso acontece sem que você percebaUma API funciona através da comunicação entre diversos códigos, definindo assim comportamentos específicos de determinados objetos em uma interface. Ou seja, a API irá interligar diversas funções em um site (por exemplo, busca de imagens, notícias, artigos, etc.) de modo a possibilitar que possam ser utilizadas em outras aplicações (CIRIACO, 2009).Sistemas operacionais também possuem APIs e elas continuam tendo a mesma função. O Windows, por exemplo, possui APIs como a Win16 API, Win32 API ou Telephony API, em todas as suas versões. Ao executar um programa que envolva algum processo do sistema operacional, é provável que ele faça uma conexão com alguma API do Windows (CIRIACO, 2009).

26

3.5.4 API DE FERRAMENTAS DE COMUNICAÇÃO COM REDES SOCIAS

Neste tópico serão mostradas as ferramentas que fazem a comunicação entre as redes sócias e aplicativos externos.

3.5.4.1 GRAPHAPI(API FACEBOOK)

O GraphAPI permite a integração de páginas da Web ao Facebook. Onde se Incluindo tags do Open Graph em uma página Web, para torná-la equivalente a uma página do Facebook. Isto significa que quando um usuário clica em um botão na pagina web, é feita uma conexão entre a página e o usuário. A página irá aparecer em " Likes and Interests" do perfil do usuário, e terá a capacidade de publicar atualizações para o usuário. A página irá aparecer em alguns locais que aparecem páginas do Facebook em todo o site (pesquisa, por exemplo), e pode segmentar os anúncios para as pessoas que gostam do conteúdo publicado. Os dados estruturados fornecidos através do Open Graph definiram como a página será representada no Facebook (Graph API Overview - Facebook Developers, 2009).

27

3.5.5 FONTES DE INFORMAÇÕES E TÉCNICAS UTILIZADAS

A tabela abaixo descreve as fontes de informações e técnicas de levantamento de dados que foram utilizadas para coletar tais informações.

Fonte de Informação Técnica UtilizadaAmbiente social Observação

28

4 LEVANTAMENTO DE REQUISITOS

Neste capítulo será abordado o levantamento de requisitos das funcionalidades do sistema.

A atividade de levantamento de requisitos corresponde a etapa de compreensão do problema aplicada ao desenvolvimento de software (BEZERRA, 2006). O principal objetivo do levantamento de requisitos é que Analistas e desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema a ser desenvolvidos. Essas necessidades são geralmente denominadas requisitos.

29

4.1 DIAGRAMA DE CASOS DE USO

Em engenharia de software, um Caso de Uso é entendido como um representador de uma unidade funcional provida pelo sistema, subsistema ou classes. Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho. É do interesse desta seção mostrar quais são os atores que irão interagir com o sistema, bem como descrever quais atividades são de responsabilidade de cada um, de acordo com o perfil que lhes foram atribuídos. Para ilustrar essas interações será usado o recurso UML: Diagrama de Casos de Uso de Contexto. Em um segundo momento será exibida uma listagem dos principais casos de uso do sistema com os seus respectivos diagramas e descrições. Por fim, fluxos alternativos serão mostrados para cada caso de uso na impossibilidade dos mesmos terem o fluxo principal seguido. Entenda-se fluxo principal como aquele que obriga o usuário a seguir passos para que o caso de uso seja executado, enquanto que o alternativo pode ser entendido como aquele que disponibiliza opções que poderão ser seguidas, tais como: cadastro, edição e exclusão.

O diagrama de caso de uso (DCU) corresponde a uma visão externa do sistema e representam graficamente os atores, caso de uso e relacionamento entre esses elementos (BEZERRA, 2006). O diagrama de caso de uso tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com as funcionalidades do sistema. Nesse sentido, a finalidade de um DCU é apresentar um tipo de “diagrama de contexto”, que apresentam os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.

30

Figura 2 - Caso de uso do sistema

31

4.1.1 DESCRIÇÃO DOS ATORES

4.1.1.1 Internauta

Descrição: Realiza atividades sem a necessidade de cadastro.Responsabilidade: Visualização de eventos públicos, participação do evento sem a necessidade de ser convidado.

4.1.1.2 Usuário

Descrição: Realiza atividades com necessidade de cadastro.Responsabilidade: Gerenciamento de eventos, customização, postagem de comentários, fornecimento de imagens e vídeos, administração de contatos.

4.1.1.3 Convidado

Descrição: Realiza a confirmação atendendo ou não o convite.Responsabilidade: Postagem de comentários, fornecimento de imagens e vídeos, confirmação de aceite.

4.1.1.4 Administrador

Descrição: Responsável pela administração técnica do sistema.Responsabilidade: Gerenciamento de contas de usuários, Visualização de log do sistema, gerencia de redes sociais.

32

4.1.2 DESCRIÇÃO DOS CASOS DE USO

4.1.2.1 Visualizar evento

Identificação: UC01 – Visualizar eventoSumário: O ator realiza a visualização dos dados sobre o evento.Ator Primário: InternautaPré-condições: O Evento ser publico.

Fluxo Principal:

1. O caso de uso inicia quando ator requisita a visualização do evento.2. O sistema apresenta uma lista de eventos públicos para serem consultados.3. O ator indica a opção de consultar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)5. Se o ator deseja continuar com a consulta; caso contrário, o caso de uso

termina.

Fluxo Alternativo:

(A1) Consultaa) O ator solicita a realização de uma consulta dos dados do evento.b) O sistema apresenta os detalhes do evento.

33

4.1.2.2 Manter comentário eventoIdentificação: UC02 – Manter comentário eventoSumário: O ator realiza a manutenção (inclusão e remoção) dos dados dos comentários postados sobre o eventoAtor Primário: ConvidadoPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a manutenção de formas de

notificação.2. O sistema apresenta as operações que podem ser realizadas: a inclusão de

um novo comentário, a exclusão de uma postagem e a consulta de todos os comentários.

3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)5. Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2. Caso contrário, o caso de uso termina.

Fluxo Alternativo:(A1) Inclusãoa) O ator requisita a inclusão de um comentário.b) O sistema apresenta um formulário em branco para que os dados do

comentário sejam inseridosc) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo comentário; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Remoçãoa) O ator seleciona um comentário para remoção, e requisita ao sistema que o

remova.b) Se a forma de notificação puder ser removida, o sistema realiza a remoção.

Caso contrário, o sistema reporta o fato.

Pós-condições: Uma forma de notificação foi inserida ou removida, ou seus detalhes foram alterados.

34

4.1.2.3 Confirmar Evento

Identificação: UC03 – Confirmar EventoSumário: O usuário recebe um e-mail ou uma mensagem no Facebook do sistema convidando-o para participar de um evento de um amigo. Na mensagem também vem informações sobre o evento. O usuário que confirma a participação está definitivamente participando do evento. Caso não queira participar deve ignorar o e-mail do convite.Ator Primário: ConvidadoPré-condições: Ter um e-mail ou Facebook válido.

Fluxo Principal:

1. Usuário clica no link de confirmação da participação do evento.2. Sistema confirma a participação do usuário nesse evento e dá opção de logar

no sistema.3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)5. Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2; caso contrário, o caso de uso termina.

Fluxo Alternativo:

(A1) Cadastro

a) O ator requisita a inclusão de uma conta de usuário.b) O sistema apresenta formulário em branco para que os dados do usuário

sejam inseridos.c) Ator fornece os dados do usuário.d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo usuário; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Login

a) O ator é encaminhado ao caso de uso Efetuar Login.

Pós-condições: O usuário já estar como convidado no evento.

35

4.1.2.4 Manter Fotos Eventos

Identificação: UC04 – Manter Fotos EventosSumário: O ator realiza a manutenção (inclusão, alteração, remoção e consulta) de vídeo ou link de vídeos. O Ator poderá inserir imagens que foram tiradas durante o evento e subir para a pagina do evento que foi criada.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:O Ator inicia o caso de uso solicitando na pagina do evento a opção inserir imagem.

1. O sistema ira abrir um formulário de uploud para as inserir as imagens.2. O Ator ira selecionar as imagens que deverão ir para a pagina do evento.3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)5. Se o ator deseja continuar com a inserção, o caso de uso retorna ao passo 2;

caso contrário, o caso de uso termina

Fluxo Alternativo:(A1) Enviar as imagensa) O ator clica em submeter as imagens.b) O sistema carrega as imagens.c) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui

uma nova imagem; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Cancelar b) O ator clica em cancelar o envio.c) O caso de uso termina.

Pós-condições: As imagens estarão em um álbum na pagina do evento que foi criada.

36

4.1.2.5 Manter Vídeo Evento

Identificação: UC04 – Manter Vídeo EventoSumário: O ator realiza a manutenção (inclusão, remoção e consulta) de vídeo ou link de vídeos.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a manutenção de vídeos.2. O sistema apresenta as operações que podem ser realizadas: a inclusão de

novo vídeo ou link de vídeo, a exclusão de vídeo ou link de vídeo e a consulta de dados do vídeo ou link de vídeo.

3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)(A3)5. Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2; caso contrário, o caso de uso termina.

Fluxo Alternativo:

(A1) Inclusão de vídeoa) O ator requisita a inclusão de vídeo.b) O sistema apresenta formulário em branco para que os dados do vídeo sejam

inseridos.c) Ator fornece os dados do vídeo.d) O sistema apresenta formulário em branco para que vídeo ou link de vídeo

seja inserido.e) Ator fornece insere um vídeo ou um link de vídeo.f) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo vídeo; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Consultar vídeoα) O ator solicita a realização de uma consulta sobre a lista de videos.β) O sistema apresenta uma lista com o nome e datas dos vídeos.χ) O ator seleciona um vídeo.δ) O sistema apresenta os detalhes do vídeo. (A3)(A4)(A5)

(A3) Remoção de vídeoa) O ator seleciona evento, e requisita ao sistema que o remova.b) Se o vídeo puder ser removido, o sistema realiza a remoção; caso contrário, o

sistema reporta o fato.

Pós-condições: Um vídeo foi inserido ou removido.

37

4.1.2.6 Manter Evento

Identificação: UC06 – Manter EventoSumário: O ator realiza a manutenção (inclusão, alteração, remoção e consulta) de evento.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a manutenção de agendamento de

evento.2. O sistema apresenta as operações que podem ser realizadas: a inclusão de

novo evento, a exclusão de evento, a alteração de dados do evento, consulta de dados do agendamento de evento.

3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)(A3(A4)5. Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2; caso contrário, o caso de uso termina.

Fluxo Alternativo:(A1) Inclusão de eventoa) O ator requisita a inclusão de evento no sistema.b) O sistema apresenta formulário em branco para que os dados do evento

sejam inseridos.c) Ator fornece os dados do evento.d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo evento; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Consulta de eventoa) O ator solicita a realização de uma consulta sobre a lista de eventos.b) O sistema apresenta uma lista com o nome e datas dos eventos.c) O ator seleciona um evento.d) O sistema apresenta os detalhes do evento. (A3)(A4)

(A3) Remoção de eventoa) O ator seleciona evento, e requisita ao sistema que o remova.b) Se o evento puder ser removido, o sistema realiza a remoção; caso contrário,

o sistema reporta o fato.

(A4) Alteração de eventoa) O ator altera um ou mais dos detalhes sobre o evento e requisita a sua

atualização.b) O sistema verifica a validade dos dados e, se eles forem válidos, altera os

dados da vaga.

Pós-condições: Um agendamento de evento foi inserido ou removido, ou seus detalhes foram alterados.

38

4.1.2.7 Criar Convite

Identificação: UC06 – Manter ConviteSumário: O ator realiza a criação de um convite.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a criação do convite.2. O sistema apresenta as telas para a criação do convite.3. O ator preenche os dados para a criação do convite a ser enviado.4. O sistema verifica a validade dos dados. Se os dados forem válidos, envia o

convite; caso contrario, o sistema reporta o fato, solicita novamente os dados e repete a verificação.

5. O ator confirma o envio do convite. (A1)6. O caso de uso se encerra.

Fluxo Alternativo:(A1) Publicar Redes Sociaisa) O caso de uso Publicar em Redes Sociais inicia.

(A2) Cancelar convitea) O ator optar por estar cancelando o envio do convite.b) O sistema cancela o convite.c) O caso de uso se encerra.

Pós-condições: O convite foi enviado para o convidado via e-mail ou redes sociais.

39

4.1.2.8 Incluir mapa endereço evento

Identificação: UC07 – Incluir mapa endereço eventoSumário: O ator ira utilizar o mapa do Google Maps para anexar ao convite do evento o link do mapa.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a inclusão do mapa no convite.2. O sistema apresenta as operações que podem ser realizadas: a inclusão de

um link utilizando o Google Maps.3. O ator indica a opção a realizar ou opta por finalizar o caso de uso.4. O ator seleciona a operação desejada: (A1)(A2)5. Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2; caso contrário, o caso de uso termina.

Fluxo Alternativo:(A1) Inclusão de mapa de endereço de eventoa) O ator requisita a inclusão do link do mapa do Google Maps.b) O sistema irá abrir a pagina do Google Maps.c) O sistema ira pedir o local do evento.d) O usuário ira entrar com o nome do local do evento.e) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui ao

convite o link do mapa do Google Maps; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Cancelamento de mapa de endereço de evento

a) O caso de uso se encerra.

40

4.1.2.9 Publicar em Redes Sociais

Identificação: UC08 – Publicar em Redes SociaisSumário: O ator realiza a publicação do convite por redes sociais. A rede social utilizada será o Facebook.Ator Primário: UsuárioPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso e possuir cadastros nas redes sociais citadas acima.

Fluxo Principal:1. O caso de uso inicia quando ator requisita a opção de envio do convite por

meio de redes sociais.2. O sistema apresenta as telas para a interface delegando a permissão de

divulgação nas redes sociais.3. O ator preenche os dados para delegar acesso as redes sociais.4. O sistema verifica a validade dos dados. Se os dados forem válidos, envia o

convite; caso contrário, o sistema reporta o fato, solicita novamente os dados e repete a verificação.

5. O sistema habilita as redes sociais para envio dos convites.6. O ator confirmar a publicação dos dados do convite nas redes sociais.7. O sistema envia a descrição do convite nas redes sociais.8. O caso de uso se encerra.

Pós-condições: O convite foi publicado nas redes sociais.

41

4.1.2.10 Manter Usuário

Identificação: UC07 – Manter UsuárioSumário: O ator realiza a manutenção (inclusão, remoção, alteração e consulta) dos dados de usuário.Ator Primário: AdministradorPré-condições: O ator está autenticado pelo sistema e possuir autorização de acesso ao caso de uso.

Fluxo Principal:6. O caso de uso inicia quando ator requisita a manutenção de uma conta de

usuário.7. O sistema apresenta as operações que podem ser realizadas: a inclusão de

novo usuário, a alteração dos dados de um usuário, a exclusão de uma conta de usuário e a consulta pelos dados de uma conta de usuário.

8. O ator indica a opção a realizar ou opta por finalizar o caso de uso.9. O ator seleciona a operação desejada: (A1)(A2)10.Se o ator deseja continuar com a manutenção, o caso de uso retorna ao

passo 2; caso contrário, o caso de uso termina.

Fluxo Alternativo:(A1) Inclusão de usuário:a) O ator requisita a inclusão de uma conta de usuário.b) O sistema apresenta formulário em branco para que os dados do usuário

sejam inseridos.c) Ator fornece os dados do usuário.d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo usuário; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

(A2) Consulta de usuário:a) O ator solicita a realização de uma consulta dos dados da conta de um

usuário.b) O sistema apresenta uma lista com o nome dos usuários cadastrados.c) O ator seleciona um usuário.d) O sistema apresenta os detalhes do usuário. (A3)(A4)

(A3) Remoção de usuário:c) O ator seleciona um usuário, e requisita ao sistema que o remova.d) Se a usuário puder ser removida, o sistema realiza a remoção; caso contrário,

o sistema reporta o fato.

(A4) Alteração de usuário:a) O ator altera um ou mais dos detalhes sobre o usuário e requisita a sua

atualização.b) O sistema verifica a validade dos dados e, se eles forem válidos, altera os

dados na lista de usuários do sistema.

42

Pós-condições: Um usuário foi inserido ou removido, ou seus detalhes foram alterados.

4.1.2.11 Fazer Login

Identificação: UC10 – Fazer LoginSumário: O ator realiza a entrada no sistema.Ator Primário: Usuário,Internauta,Convidado e AdministradorPré-condições: Possuir cadastro no site

Fluxo Principal:1. O caso de uso inicia quando ator requisita fazer login no sistema.2. O sistema apresenta os campos que devem ser preenchidos, login e senha.3. O ator informar os dados e inicia a entrada no sistema.(A1)4. O ator seleciona a operação desejada: (A1)5. Se o ator deseja continuar com a consulta; caso contrário, o caso de uso

termina.

Fluxo Alternativo:(A1) Lembrar senhaa) O ator solicita a realização de lembrete de senha.b) O sistema apresenta campos que devem ser preenchidos pelo usuário.c) O sistema valida os dados, e enviar para o email do usuário login e senha.

43

4.1.2.12 Cadastrar Conta

Identificação: UC13 – Cadastrar ContaSumário: O ator realiza um novo cadastro no sistema.Ator Primário: Internauta e ConvidadoPré-condições: Não possuir cadastro no sistema.

Fluxo Principal:

1. O caso de uso inicia quando ator requisita fazer um novo cadastro no sistema.2. O sistema apresenta os campos que devem ser preenchidos para o cadastro.3. O ator submete os campos preenchidos para o sistema.4. O sistema valida os campos. (E1)(E2)5. Se o ator deseja continuar com o cadastro ele é concluído; caso contrário, o

caso de uso se encerra.

Fluxo de Exceção:(E1) Usuário já cadastradoa) O sistema reporta que já possui algum usuário com o e-mail já cadastrado no

sistema.b) O usuário retornar ao Fluxo Principal para alterar o e-mail.c) Esta exceção se encerra.

(E2) Dados incorretosa) O sistema reporta que os dados estão incorretos.b) O usuário retornar ao Fluxo Principal para alterar os dados.c) Esta exceção se encerra.

Pós-condições: Fim do Fluxo Principal do caso de uso com o cadastro do usuário sendo realizado com sucesso e exibindo

44

5 PROPOSTA TECNOLÓGICAS

5.1 ANÁLISE PONTO DE FUNÇÃO

Segundo VAZQUEZ, SIMÕES e ALBERT, análise de pontos de função é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. Ponto de função é uma unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software.

A APF (Análise de Pontos de Função) tem como objetivos:

• Medir as funções que o usuário solicita e recebe;

• Medir o desenvolvimento e manutenção de software independente da tecnologia de implementação;

A técnica define algumas abstrações necessárias à determinação do tamanho funcional do sistema. Estes conceitos representam os componentes do sistema que fornecem funcionalidades de armazenamento e processamento de dados aos seus usuários e por eles reconhecidas e solicitadas. Ela também fornece definições de conceitos utilizados como referência na identificação desses componentes.

5.1.1 Elementos de Contagem de Pontos de Função

Os elementos da contagem de pontos de função são funções do tipo dado e funções do tipo transação. As funções do tipo dado representam as funcionalidades fornecidas pelo sistema ao usuário para atender a suas necessidades de armazenamento de dados. São classificadas em:

• Arquivo de Interface Externa (AIE): Grupo de dados ou informações de controle, mantido fora da aplicação sendo contada. Sua principal intenção é armazenar dados referenciais através de transações da aplicação sendo contada.

• Arquivo Lógico Interno (ALI): Um grupo logicamente relacionado de dados ou informações de controle, identificável pelo usuário, mantido dentro da fronteira da aplicação sendo contada. Sua principal intenção é armazenar dados mantidos através de uma ou mais transações da aplicação sendo contada.

45

As funções do tipo transação representam os requisitos de processamento fornecidos pelo sistema ao usuário.

São classificadas em:

• Entrada Externa (EE): É uma transação que processa dados ou informações de controle originados de fora da aplicação. Sua principal intenção é manter arquivos lógicos internos e/ou alterar o comportamento do sistema (incluir, alterar, excluir).

• Saída Externa (SE): É uma transação que envia dados ou informações de controle para fora da fronteira da aplicação. Sua principal intenção é apresentar informações ao usuário através de lógica de processamento que não seja apenas uma simples recuperação de dados ou informações de controle. Seu processamento deve conter cálculo, ou criar dados derivados, ou manter um arquivo lógico interno, ou alterar o comportamento do sistema (relatórios com cálculos).

• Consulta Externa (CE): É uma transação que envia dados ou informações de controle para fora da aplicação. Sua principal intenção é apresentar informações ao usuário pela simples recuperação de dados ou informações de controle de ALIs e/ou AIEs (consultas).

Para realizar o cálculo do tamanho funcional, cada função do tipo dado e transação possui um peso, que é determinado pela complexidade da função que pode ser baixa, média ou alta. A complexidade das funções do tipo é determinada por dois parâmetros: quantidade de tipos de dados (campos) (TD) e quantidade de tipos de registros (TR) (subgrupos de dados dentro do arquivo). As funções do tipo transação têm sua complexidade determinada por outros parâmetros: quantidade de tipos de dados (TD) e quantidade de arquivos referenciados (AR).

Para finalizar a contagem dos pontos de função do sistema, é utilizado o fator de ajuste, que tem como propósito medir requisitos gerais da aplicação (não funcionais).

46

5.1.2 Contagem de Pontos de Função

Contagem dos tipos dados estão baseados nos atributos das classes persistentes da aplicação, e na contagem das funções do tipo transação, os TDs são acrescentados 2 (dois) a mais levando em consideração o comando e a mensagem de retorno.

As funções contadas seguem conforme descrito abaixo:

Internauta: Fazer Login,Visualizar Evento e Cadastrar Conta.

Convidado: Incluir, Alterar, Excluir,Consultar e Publicar.

Manter Video Evento

5.2 Recursos de profissionais

Para o desenvolvimento do sistema, será necessário montar uma equipe de profissionais. A tabela abaixo mostra os profissionais alocados, a quantidade, sua produtividade e o valor total.

Profissional Qtde Produtividade Valor TotalGerente 1 R$ 70,00 /h Analista 1 5h/PF R$ 100,00 /PF Desenvolvedor 1 3h/PF R$ 80,00 /PF Tester 1 2h/PF R$ 15,00 /h

A produtividade e o valor total dos profissionais são valores estimados observadosno mercado, pois não há uma padronização desses valores no mercado de trabalhoatual.

* Fonte: Pesquisa salarial da Catho Online (2011)

47

Para o desenvolvimento do sistema será adotado uma carga horária de trabalho de 8 horas diários sendo 20 dias por mês. Com exceção do gerente que trabalhará em uma carga horária reduzida, porém acompanhará todo o desenvolvimento do sistema. A tabela abaixo mostra o investimento que em mão de obra que será necessário para realizar o desenvolvimento do sistema

Atividade Envolvidos Tempo (dia) Custo Planejamento Gerente 8 R$ 4.480,00 Análise Analista e Gerente 90 R$ 26.740,00 Implementação Desenvolvedor e Gerente 60 R$ 21.280,00 Tester Tester e Gerente 30 R$ 3.955,00 Total R$ 56.455,00

5.3 Propostas tecnológicas

As propostas sugerem o aluguel de um servidor dedicado e licenças necessárias

para ativação do sistema e recomenda uma maquina mais simples.

A tabela abaixo reúne os serviços oferecidos junto ao aluguel de um servidor. As

funcionalidade que não possuem controle pelo Cliente não serão adquiridas.

Gerenciamento do Servidor

Funcionalidade Gerenciamento pelo Cliente

Posse da Senha de Administração ClienteAdministração Remota (SSH,

Terminal Services) Sim

SLA99,8% de disponibilidade do servidor (hardware)

Instalação de Softwares Cliente

(além do Sistema Operacional) Parcial

Backup Opcional

Monitoração de Servidor

Hardware Não

Notificação sobre hardware Não

Serviços Ping

Notificação sobre serviços Cliente

Urchin (Relatório de Acessos ao Site) Não

Firewall Regras definidas pelo Cliente

Tabela 1 - Serviços oferecidos no aluguel do servidor

48

5.3.1 Propostas de servidores

A tabela abaixo especifica as características técnicas para o servidor do sistema. Os

planos são de pagamento mensal e os valores são baseados nas configurações

padrão. Caso necessário o uso de um servidor personalizado, será feito uma

consulta com a empresa de aluguel do servidor

.

Serviços Propostos

DescriçãoPrazo

contratualValor em Reais Periodicidade

Servidor Dedicado I

• CPU: 1 x Processador Intel L5630 (4

cores de 2,13 GHz)

• Disco Rígido: 2 x 1 TB SATA 7.200 RPM

• Memória RAM: 12 GB

• Transf. Mensal : 175 GB

12 meses 1.350,00 mensal

Servidor Dedicado II

• CPU: 2 x Processadores Intel L5630 (4

cores de 2,13 GHz)

• Disco Rígido: 2 x 600 GB SAS 15.000 RPM

• Memória RAM: 24 GB

• Transf. Mensal : 175 GB

12 meses 1.900,00 mensal

Servidor Dedicado III

• CPU: 2 x Processadores Intel L5630 (4

cores de 2,13 GHz)

• Disco Rígido: 2 x 146 GB SAS 15.000 RPM

• Memória RAM: 48 GB

• Transf. Mensal : 175 GB

12 meses 2.200,00 mensal

Servidor Dedicado IV

• CPU: 2 x Processadores Intel L5640 (6

cores de 2,26 GHz)

• Disco Rígido: 2 x 146 GB SAS 15.000 RPM

• Memória RAM: 72 GB

• Transf. Mensal : 175 GB

12 meses 2.950,00 mensal

Taxa de Instalação R$ 800,00

49

Serviços Adicionais

Qtde. Descrição Valor Total(R$) Período Pagto.

01 Backup FTP (10 GB) 25,00 mensal

01 Transferência excedente por GB 0,30 mensal

01 Endereço IP adicional 20,00 mensal

01 Porta Gigabit habilitada no switch (1 Gbps) 60,00 mensal

01 SSL Dedicado 299,00 anual

01 Link Ponto-a-Ponto 512 Kbps 1.010,00 mensal

01 Link Ponto-a-Ponto 1 Mbps 1.800,00 mensal

01 Link Ponto-a-Ponto 2 Mbps 2.565,00 mensal

01 Link Ponto-a-Ponto 3 Mbps 3.350,00 mensal

01 Link Ponto-a-Ponto 4 Mbps 4.135,00 mensal

01 Link Ponto-a-Ponto 6 Mbps 6.185,00 mensal

01 Balanceamento de Carga WEB (1Mbps) 50,00 mensal

01 Instalação – Balanceamento de Carga 200,00 único

Tabela 2 - Tabela de serviços adicionais

A escolha pela proposta no aluguel de um servidor dedicado foi pela opção de Servidor Dedicado I. O servidor é ideal para aplicações com grande volume de armazenamento e média performance de I/O junto a capacidade de transferência de dados a partir de 175 GB mensais e possibilidade de contratação de tráfego adicional.Os serviços serão contratados a medida da necessidade, pois não há plano contratual.

50

ESPECIFICAÇÃO DE ANALISE

A especificação de análise enfatiza a investigação do problema proposto. O principal objetivo da fase de análise é levar o analista ao entendimento de como o sistema em questão funciona (WAZLAWICK, 2004).

É uma atividade que engloba a maioria das tarefas que chamamos coletivamente de engenharia de software, tendo como objetivo identificar a necessidade do usuário, executar análise econômica e técnica, atribuir funções ao hardware, ao software, às pessoas, ao banco de dados e aos demais elementos do sistema (PRESSMAN 2007).

5.4 MODELO DE CLASSES

A modelagem de classes envolve a identificação de classes, atributos, associações e operações, bem como o agrupamento de classes em subsistemas ou pacotes. A seguir, são apresentados os resultados da análise, no que tange aos aspectos de informação basicamente (BEZERRA, 2006).

51

5.5 DIAGRAMA DE CLASSES

Figura 3 - Tela de Diagrama de Classes

52

5.6 Dicionário de Dados

Os dicionários de dados são locais onde são armazenados informações dos atributos das classes, tais como nome, descrição, tipo e entre outros (ALLAN DENNIS, BARBARA HALEY WIXON, 2005).

As tabelas a seguir, mostram o dicionário de dados das classes que compõem o diagrama de classes.

Tabela 3 - Dicionário de dados da classe Endereço

Campo Regra/Descrição Editaveis Obrigatorios

numero Número da residência Sim Sim

complementoComplemento da

residência Sim Nãorua Nome da Rua Sim Sim

bairro Nome do bairro Sim Simcidade Nome da cidade Sim Simpais Nome do Pais Sim SimCEP CEP da localidade Sim Sim

Tabela 4 - Dicionário de dados da Classe Evento

Campo Regra/Descrição Editáveis Obrigatórios

TipodeEvento Tipo do evento Sim Simnome Nome do evento Sim Sim

descrição Descrição do Evento Sim SimdataInicio Data inicio do Evento Sim SimdataFim Data final do Evento Sim Sim

fotoEvento Foto do Evento Sim SimhoraInicio Hora Inicio do Evento Sim SimhoraFim Hora fim do Evento Sim Sim

Tabela 5 - Dicionário de dados da Classe Pessoa

Campo Regra/Descrição Editaveis Obrigatorios

Nome Nome do usuário Sim SimSobrenome Sobrenome do usuário Sim Não

Email Email do usuário Sim Sim

DataNascimentoData de nascimento do

usuário Sim Sim

53

Tabela 6 - Dicionário de dados da Classe Telefone

Campo Regra/Descrição Editáveis Obrigatórios

numero Numero do telefone Sim Sim

descricaoDescrição do número do

telefone Sim Nãoddd Pré fixo DDD do número Sim Sim

ramal Ramal Sim NãoCodPais Código do número por País Sim Não

Tabela 7 - Dicionário de dados da Classe Log

Campo Regra/Descrição Editáveis Obrigatórios

data Data da geração do log Não Simnivel Nivel do log Não Sim

mensagem Mesagem do log Não SimtipoLog Tipo do log Não Sim

Tabela 8 - Dicionário de dados da Classe Sessão

Campo Regra/Descrição Editáveis ObrigatóriosinicioAcesso Inicio da sessão Não SimfimAcesso Fim da sessão Não Sim

ip Endereço IP do usuário Não Sim

cookieMantem o cookie do

usuário Não Sim

isAtivoIndicador sobre status do

usuário Não Sim

Tabela 9 - Dicionário de Dados da Classe Usuário

Campo Regra/Descrição Editáveis Obrigatórios

usuário Nome do usuário Sim Simsenha Senha do usuário Sim Sim

codAuth Código autenticador Não SimdtCadastro Data de cadastro Não Sim

Tabela 10 - Dicionário de Dados da Classe Conta Rede Social

Campo Regra/Descrição Editáveis Obrigatórios

isAtivaIdentificador de status da Conta da rede

social Sim SimemailUser Senha do usuário Sim Sim

auth Código autenticador Sim Sim

Tabela 11 - Dicionário de Dados da Classe Rede Social

Campo Regra/Descrição Editáveis ObrigatóriosNome Nome da Rede Social não não

Descrição Descrição da Rede Social não não

54

url Endereço da rede social não não

55

Tabela 12 - Dicionário de Dados da Classe Foto Evento

Campo Regra/Descrição Editáveis Obrigatórios

titulo Titulo para foto Sim SimDescrição Descrição para a foto Sim não

url Endereço da foto não nãofile Arquido da foto não não

Tabela 13 - Dicionário de Dados da Classe Mapa

Campo Regra/Descrição Editáveis Obrigatórios

Descricao Descrição do mapa Sim Simlink Link do mapa Sim Sim

5.7 DIAGRAMA DE SEQÜÊNCIA

Um diagrama de sequência ilustra os objetos que participam de um caso de uso e as mensagens que são passadas entre eles ao longo do tempo para apenas um caso de uso. Ele é também um modelo dinâmico, que dá suporte à visualização dinâmica do sistema que está sendo desenvolvido. No diagrama é mostrada a sequência explícita de mensagens que são passadas entre objetos em uma iteração definida.(BEZERRA, 2007).

5.7.1 Geral

A figura abaixo mostra o diagrama geral do sistema:

56

Figura 4 - Tela Diagrama Geral do Sistema

57

5.7.1.1 Efetuar Login

A figura abaixo mostra o diagrama de sequencia do caso de uso Efetuar Login:

Figura 5 - Diagrama Efetuar Login

58

5.7.1.2 Incluir Video

A figura abaixo mostra o diagrama de sequencia do caso de uso Incluir Video

Figura 6 – Diagrama Sequencia Incluir Video

59

5.7.1.3 Excluir Video

A figura abaixo mostra o diagrama de sequência do caso de uso Excluir Video:

Figura 7 - Tela Diagrama Excluir Video

60

5.7.1.4 Incluir Foto

A figura abaixo mostra o diagrama de seqüência do caso de uso Incluir Foto:

Figura 8 - Tela Diagrama Incluir Foto

61

5.7.1.5 Excluir Foto

A figura abaixo mostra o diagrama de seqüência do caso de uso Excluir Foto:

Figura 9 - Tela Diagrama Excluir Foto

62

5.7.1.6 Incluir Usuário

A figura abaixo mostra o diagrama de seqüência do caso de uso Incluir Usuário:

Figura 10 - Tela Diagrama Incluir Usuário

63

5.7.1.7 Excluir Usuário

A figura abaixo mostra o diagrama de seqüência do caso de uso Excluir Usuário:

Figura 11 - Tela Diagrama Excluir Usuário

64

5.7.1.8 Alterar Usuário

A figura abaixo mostra o diagrama de seqüência do caso de uso Alterar Usuário:

Figura 12 - Tela Diagrama Alterar Usuário

65

5.7.1.9 Criar Evento

A figura abaixo mostra o diagrama de seqüência do caso de uso Criar Evento:

Figura 13 - Tela Diagrama Criar Evento

66

5.7.1.10 Alterar Evento

A figura abaixo mostra o diagrama de seqüência do caso de uso Alterar Evento:

Figura 14 - Tela Diagrama Alterar Evento

67

5.7.1.11 Excluir Evento

A figura abaixo mostra o diagrama de seqüência do caso de uso Excluir Evento:

Figura 15 - Tela Diagrama Excluir Evento

68

5.7.1.12 Confirmar Evento

A figura abaixo mostra o diagrama de seqüência do caso de uso Confirmar Evento:

Figura 16 - Tela Diagrama Confirmar Evento

69

5.7.1.13 Visualizar Evento

A figura abaixo mostra o diagrama de seqüência do caso de uso Visualizar Evento:

Figura 17 - Tela Diagrama Vizualizar Evento

70

5.7.1.14 Incluir Comentário

A figura abaixo mostra o diagrama de sequência do caso de uso Incluir Comentário:

Figura 18 - Tela Diagrama Incluir Comentário

71

5.7.1.15 Excluir Comentário

A figura abaixo mostra o diagrama de sequência do caso de uso Excluir Comentário:

Figura 19 - Tela Diagrama Excluir Comentário

72

5.7.1.16 Cadastrar Conta

A figura abaixo mostra o diagrama de sequência do caso de uso Cadastrar Conta:

Figura 20 - Tela Diagrama Cadastrar Conta

73

5.7.1.17 Criar Convite

A figura abaixo mostra o diagrama de sequência do caso de uso Criar Convite:

Figura 21 - Tela Diagrama Criar Convite

74

5.7.1.18 Publicar Redes Sociais

A figura abaixo mostra o diagrama de seqüência do caso de uso Publicar Redes Sociais:

Figura 22 - Tela Diagrama Publicar Redes Sociais

75

5.8 Diagrama de Estados

Um objeto muda de estado quando acontece algum evento interno ou externo ao sistema. Quando um objeto muda de um estado para o outro, diz-se que ele realizou uma transição entre estados. Os estados e as transições de estados de um objeto constituem o seu ciclo de vida (BEZERRA, 2004).

A figura abaixo apresenta o diagrama de estados da classe Convite

Figura 23 - Diagrama de estados da Classe Convite

76

A figura abaixo apresenta o diagrama de estados da classe Evento

Figura 24 - Diagrama de estados da Classe Evento

77

6 ESPECIFICAÇÃO DE PROJETO

A especificação de projeto visa a produzir uma solução para o problema identificado na fase de análise. (WAZLAWICK, 2004).

Segundo PRESSMAN, o projeto é o primeiro passo da fase de desenvolvimento de qualquer produto ou sistema de engenharia. Ele pode ser definido como:

“...o processo de se aplicar várias técnicas e princípios ao propósito de sedefinir um dispositivo, um processo ou um sistema com detalhes suficientes

para permitir sua realização física”.

Ao longo do processo de projeto, a qualidade do projeto em evolução é avaliada, segundo as diretrizes:

• Um projeto deve exibir uma organização hierárquica que faça uso inteligente do controle entre os componentes de software.

• Um projeto deve ser modular, ou seja, o software deve ser logicamente dividido em componentes que executam funções e subfunções específicas.

• Um projeto deve conter uma representação distinta e separável de dados e procedimentos.

• Um projeto deve levar a módulos (por exemplo, as sub-rotinas ou os procedimentos) que apresentem características funcionais independentes.

• Um projeto deve levar a interface que reduzam a complexidade de conexões entre os módulos e com o ambiente externo.

• Um projeto deve ser derivado usando-se um método capaz de permitir repetições e que seja orientado pelas informações obtidas durante a análise de requisitos de software.

As características de um bom projeto apresentadas acima não são conseguidas casualmente. O processo de projeto de software estimula o bom projeto por meio da aplicação de princípios fundamentais, metodologias e cuidadosa revisão

78

6.1 Escolha da Tecnologia

Para o desenvolvimento do protótipo será utilizado a aplicação orientada a RIA( do inglês Rich Internet Applications) e a linguagem de programação JAVA, protocolo JSON e persistência por Hibernate. Tendo como o banco de dados será utilizado o MySQL, que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language) como interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo.

RIA é uma tecnologia web engajante, interativa, leve e flexível. Aplicações de Internet Rica (Rich Internet Application) são aplicações web que tem características e funcionalidades de softwares tradicionais do tipo Desktop.

Para o framework será utilizado o Spring, cuja é um framework open source para a plataforma Java. Trata - se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. No Spring o container se encarrega de "instanciar" classes de uma aplicação Java e definir as dependências entre elas através de um arquivo de configuração em formato XML, inferências do framework, o que é chamado de auto-wiring ou ainda anotações nas classes, métodos e propriedades. Dessa forma o Spring permite o baixo acoplamento entre classes de uma aplicação orientada a objetos.

Para o padrão de projeto, será adotado o Modelo, Visão e Controlador (MVC). Cujo o padrão de arquitetura de software que visa a separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos.O modelo é usado para definir e gerenciar o domínio da informação e notificar observadores sobre mudanças nos dados.A visão apresenta o modelo num formato adequado ao utilizador, na saída de dados, e diferentes visões podem existir para um mesmo modelo, para diferentes propósitos.O controlador recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo, e por fim uma visão baseada na entrada. Ele também é responsável pela validação e filtragem da entrada de dados.(WIKIPEDIA,2011)

Como IDE de desenvolvimento, será utilizado o Eclipse desenvolvido em java com código aberto para a construção de programas de computador. Possui como características marcantes o uso da SWT e não do Swing como biblioteca gráfica, a forte orientação ao desenvolvimento baseado em plug-ins e o amplo suporte ao desenvolvedor com centenas de plugins que procuram atender as diferentes necessidades de diferentes programadores (ECLIPSE, 2010).

6.2 Arquitetura do Sistema

A arquitetura do sofware de um sistema consiste dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares (caso exista). O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos

79

componentes e padrões entre projetos (WIKIPEDIA, 2010).

6.2.1 Diagrama de Pacotes

O diagrama de pacotes mostra a decomposição do próprio modelo em unidades organizacionais e suas dependências (BOOCH, 2005).

O diagrama de pacotes exibe a decomposição do sistema em partes menores e a dependência entre eles, o que possibilita a divisão em módulos de desenvolvimento facilitando o gerenciamento de cada pacote. Os pacotes menores oferecem maneiras de dividir diagramas e modelos grandes em subconjuntos gerenciáveis.

Pode-se considerar o sistema inteiro como um único pacote de alto nível com todos os modelos e elementos.

Para organizar o sistema, os requisitos foram divididos nos seguintes subsistemas (pacotes):

• Administração: O subsistema Administração trata as ações referentes asmanutenções no sistema, como cadastros de usuários, de visualizações de logs.

• Evento: O Subsistema Evento trata das ações de envio e configuração de eventos criado pelo usuário.

• Utilitarios: Este pacote contém classes reutilizáveis para as camadas de persistência e apresentação, contudo somente as classes com maior relevância serão abordadas.

80

A figura abaixo mostra esta divisão e suas dependências através do diagrama de pacotes, apresentando a arquitetura lógica do sistema.

Figura 25 - Diagrama de Pacotes

81

6.2.2 Divisão em Camadas

Os subsistemas serão divididos em quatro camadas, sendo elas:

• Camada de Domínio do Problema (DP): Camada responsável por implementar diretamente os requisitos do usuário e as regras de negócio.

• Camada de Gerencia de Tarefa (GT): Camada responsável por controlar e coordenar tarefas.

• Camada de Gerencia de Dados (GD): Camada responsável pelo armazenamento e recuperação de objetos.

• Camada de Interface com o Usuário (IU): Camada responsável pela interface entre o sistema e o usuário.

A figura abaixo apresenta o subsistema a ser prototipado no modelo MVCE.

82

6.2.3 Camada Domínio do Problema (DP)

A camada de domínio do problema é aquela onde se encontram a maioria dos objetos na análise de domínio. Esta camada manipula requisições da camada de aplicação. Os objetos nesta camada normalmente são independentes da aplicação. É responsável por validações das regras de negócio, assim como de validação de dados provenientes da camada de apresentação (por intermédio da camada de aplicação). Essa camada também é chamada de camada da lógica do negócio (BEZERRA, 2007).

Responsável por controlar todo que a aplicação ira fazer, ela tem a função de modelar os dados e o comportamento por tras do processo de negócios e controla a manipulação e geração de dados.

A figura abaixo exibe o diagrama de classe do domínio do problema:

Figura 26 – Diagrama Domínio do Problema (DP)

83

6.2.4 Camada Gerência de Tarefas (GT)

É onde serão processadas todas as requisições feitas através da interface, pois a camada do controle também acessa o Modelo a fim de obter determinadas informa- ções.Toda a parte lógica da aplicação (validações, atribuições, etc) é feita na parte de controle (REVISTAPHP, 2008). A camada de controle é composta por classes que implementam a forma como os dados do modelo serão acessados para a realização das computações necessárias, gerenciando as tarefas desempenhadas pelo sistema e também validando os dados provenientes da camada de apresentação.

A figura abaixo exibe o diagrama de gerencia de tarefas:

Figura 27 - Diagrama Gerência de Tarefas (GT)

84

6.2.5 Camada Gerência de Dados (GD)

Possui acesso a todos os repositórios de dados,fazendo com que o encapsulamento dos mecanismos de persistência, procurando assim isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura de software.

A figura abaixo exibe o diagrama de gerencia de dados:

Figura 28 - Diagrama Gerência de Dados (GD)

85

6.2.6 Camada Interface com Usuário (IU)

A visão é o componente da arquitetura MVC que é responsável pela apresentação, é a interface de representação do modelo, ou seja, trata-se da fronteira entre usuário e o sistema em si. Camada responsável por captar como um usuário comanda o sistema e como o sistema apresentará as informações a ele. Esta camada é composta por classes que disponibilizam a visualização dos dados pelos usuários do sistema.

A figura abaixo exibe o diagrama de classes da interface com o usuário.

Figura 29 - Diagrama de Interface com Usuário (IU)

6.2.6.1 Padrões de Interface

A interface do sistema é um fator fundamental para o usuário, pois é nela que o mesmo deverá se adaptar. Analisando e visando tal aspecto, foram analisados diversos aspectos com intuito de estabelecer padrões de interface como ícones, fontes, cores, tamanhos e outros, com o objetivo de buscar da melhor maneira a interação com o usuário, agilidade e facilidade.

86

Diagrama Relacional O uso de mapeamento objeto-relacional é uma técnica de desenvolvimento utilizada para reduzir o impedimento da programação orientada aos objetos utilizando bancos de dados relacionais (WIKIPEDIA, 2010). As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.A seguir será apresentado o modelo relacional do banco de dados para o sistema

87

.

Figura 30 - Diagrama Relacional

88

89

6.3 Diagrama de Componentes

O diagrama de componentes exibe uma classe encapsulada e suas interfaces, portas e estruturas internas que consiste de componentes aninhados e conectores. Abrangem a visão de implementação do projeto estático de um sistema (BOOCH, 2005).

Figura 31 - Diagrama de Componentes

90

6.4 Diagrama de Implantação

O diagrama de implantação mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes. Abrangem a visão estática de implementação de uma arquitetura (BOOCH, 2005).Com a UML, o diagrama de implantação pode ser utilizado para visualizar o aspecto estático dos nós físicos e seus relacionamentos e para especificar seus detalhes referentes à construção (BOOCH, 2005).

Figura 32 - Diagrama de Implantação

91

7 Projeto de Segurança

A segurança da informação está relacionada com proteção de um conjunto de dados, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. São características básicas da segurança da informação os atributos de confidencialidade, integridade, disponibilidade e autenticidade, não estando esta segurança restrita somente a sistemas computacionais, informações eletrônicas ou sistemas de armazenamento. O conceito se aplica a todos os aspectos de proteção de informações e dados. O conceito de Segurança Informática ou Segurança de Computadores está intimamente relacionado com o de Segurança da Informação, incluindo não apenas a segurança dos dados/informação, mas também a dos sistemas em si. (WIKIPEDIA,2010)

Em sistemas de informações, existem ameacas que podem comprometer toda a estrutura da segurança do sistema. Conforme a tabela abaixo, existe algumas dessas ameaças e seus respectivos controles para combater os mesmos.

Ameaças Medidas de Seguranças

Perda de dadosExecução de rotinas de backup diários.

Acesso indevidoAutenticação no ambiente do sistema.

VirusInstalação de programas de anti virus no servidor onde esta sendo executado o sistema.

Negação de ServiçoUso de técnicas de contole de largura de banda e de recursos. Validar o fluxo e filtr

7.1 Medidas de controles

7.1.1 Perda de dados

Haverá rotina de backup da aplicação diária. Os dados salvos deverão ser guardados em mídias externas. A mídia externa ficara em um local seguro e arejado, longe de pessoas que não possuam acesso e a ameaças naturais.

7.1.2 Acesso indevido ao sistema

Pessoas que não possuem acesso ao sistema não poderá utilizar a aplicação.O acesso ao sistema so poderá ser feito através de login e senha. Neste momento saberia se o usuário é um usuário normal ou o administrador do sistema.

92

7.1.3 Virus

O servidor onde a aplicação roda devear possui um software de anti vírus sempre atualizado. O software devera estar sempre ativado.

7.1.4 Backup

A realização de backup do sistema será realizada de forma completa no final do expediente do trabalho. O banco de dados será armazenado em uma mídia DVD-RW, pois o mesmo pode armazenar um grande volume de dados. Após a gravação, o DVD-RW será guardado em um cofre de segurança.

7.1.5 Arquivos de Log

É necessário registrar todas as ações dos usuários no sistema em um arquivo de log para possíveis auditorias.

7.2 Controle de acesso usuários

O controle de usuarios do sistema consiste na maioria de suas funcionalidades no módulo de Administração, onde são cadastrados os usuários e seu perfis.Onde são fornecidas permissões de acesso aos mesmos.O controle de acesso lógico define quem pode acessar o que. Cada usuário do sistema possuira um perfil e cada perfdil terão suas permissões dentro do sistema.

93

8 CONCLUSAO

Neste primeiro momento e diante da elaboração do sistema e possível identificar de forma clara e objetiva ao qual se faz necessário o uso de um mecanismo que possa realizar o envio de convites para um evento criado a partir da web. Muitos usuários, na sua maioria os jovens, tem fácil acesso a internet, o que inclui possuir perfil em diversas redes sociais e se relacionar facilmente com os seus contatos de forma rápida.

Facilmente encontramos problemas desse tipo em nosso dia a dia, sejam eles como a falta de tempo, a perda de contato, a mudança de local onde reside e entre outros fatores que impede que você possa se comunicar diretamente, buscando então um relacionamento virtual. E fácil identificar um colega, amigo ou parente em redes sociais, mecanismos de buscas eficazes garante que ao se criar contas em sites essas informações se cruzam com outras informações de usuários aos quais podem ser do seu conhecimento.

O Evento Me disponibiliza aos seus usuários uma plataforma eficiente e com objetivos diretos, o usuário tem a plena confiança no sistema e garantia que o seu convite foi encaminhado para seus contatos via e-mail ou redes sociais.

94

9 REFÊRENCIAS BIBLIOGRÁFICAS

BEZERRA, Eduardo. Principios de analise e projeto de sistemas com UMLRio de Janeiro: Elsevier,2003.

VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Analise de Ponto de Função – Medição, Estimativa e Gerenciamento de Projetos de Software. Editora Érica. São Paulo,2010.

WAZLAWICK, Raul, Sidnei. Análise e Projeto de sistemas de informação orientados a objetos; Editora Campos.

FURLAN,José Davi. Modelagem de Objetos através da UML. São Paulo: Makron Books

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário.Trad. Fabio Freitas. Rio de Janeiro: Campus,2005.

CARDOSO, Caique. Orientação a Objetos na Prática – Aprendendo Orientação a

objetos com Java. Editora Ciência Moderna. Rio de janeiro, 2005.

CATHO. Empregos. Disponível em: <http://v.catho.com.br/buscar/empregos/>.

Acesso em: 05/05/2010.

CAVALCANTI, Marcos. Arquitetura MVC. Disponível em:

<http://www.revistaphp.com.br/artigo.php?id=50>. Acesso em: 07/08/2009.

INFO. Salários. Disponível em: <http://info.abril.com.br/professional/salarios/>.

Acesso em: 05/05/2010.

LOCAWEB. Disponível em: < https://contratacao.locaweb.com.br/contratacao/>.

Acesso em: 05/10/2011.

WIKIPEDIA. Arquitetura de Software. Disponível em

<http://pt.wikipedia.org/wiki/Arquitetura_de_software>. Aceso em: 11/10/2011.

WIKIPEDIA. Mapeamento Objeto-Relacional. Disponível em:

<http://pt.wikipedia.org/wiki/Mapeamento_objeto-relacional>. Acesso em:

19/10/2011.

95

WIKIPEDIA.Tecnologia da Informação. Disponível em:

<http://pt.wikipedia.org/wiki/Tecnologia_da_informa>. Acesso em: 30/08/2011.

96