1
Universidade Federal de Campina Grande
Centro de Engenharia Elétrica e Informática
Departamento de Sistemas e Computação
Sistema de Bate-Papo para Redes
Sociais
Andressa Bezerra ferreira
Camila Pascoal
Renata Braga de Andrade
Campina Grande – PB
Setembro de 2011
2 Monografia de Projeto de Graduação sob o título “Sistema de Bate-Papo para Redes Sociais” defendida por Andressa Bezerra Ferreira, Camila Pascoal e Renata Braga
de Andrade. Aprovada em _____ de 2011, em Campina Grande, Estado da Paraíba,
pela banca examinadora constituída por
______________________________________________________ Prof. ______________________________________________________ Prof. ______________________________________________________ Prof.
3
Sumário
Introdução ... 03
Processo de Desenvolvimento ... 05
Análise e Requisitos ... 08
Arquitetura ... 10
Verificação e Validação ... 16
Métricas ... 17
Conclusões ... 18
Referências Bibliográficas ... 19
Apêndices ... 20
4
Introdução
Descrição do Problema
O projeto trata-se do desenvolvimento de um sistema de bate-bapo para o Turingo. O Turingo é uma rede social na área de turismo que será lançada brevemente. Os usuários do Turingo são turistas e empresas interessadas em oferecer seus serviços. Um dos maiores requisitos do Turingo é ser escalável, dessa forma, ele foi concebido para que a quantidade de servidores alocados seja determinada pela quantidade de requisições.O sistema de bate-papos deve suportar centenas de milhares
de conversas simultâneas.
Visão da solução
Deseja-se construir um chat semelhante ao facebook; que apareça na página do turingo, numa barra lateral no canto direito e na parte inferior. Entretanto os requisitos são diferentes: o chat deve funcionar somente para comunicação entre turistas e empresas, nunca empresa-empresa ou turista-turista; as demais regras de negócio serão aplicadas para definir quais empresas estão habilitadas para conversar com turistas, essas regras irão variar em função da disponibilidade de uma empresa, dos lugares onde a empresa oferece serviços, etc.
Contexto do Projeto
Os usuários do Chat-Turingo são exatamente os mesmos do Turingo; ou seja, são pessoas interessadas em viajar ( turistas ) e empresas interessadas em fornecer seus serviços a essas pessoas. O ambiente de execução do Turingo é brownser o usuário; ele estará rodando junto com o Turingo, em uma barra lateral, exatamente como o chat do facebook. O chat só está no ar quando o Turingo estiver, e só estará no chat quem estiver no Turingo, pois as aplicações estão completamente ligadas.
5
Processo de Desenvolvimento
Introdução
Neste capítulo será descrito o processo utilizado para guiar o desenvolvimento deste projeto.
O desenvolvimento de software consiste em um conjunto de atividades com a finalidade de se obter um software de boa qualidade, que atenda às expectativas do cliente, em um prazo razoável com um custo aceitável. Define quem faz o quê, quando e como.
O uso de um processo mostrou-se um dos principais mecanismos para se obter um software de qualidade e cumprir corretamente as metas de desenvolvimento.
O Processo XP1
Durante o desenvolvimento deste projeto, foi utilizado o processo de desenvolvimento XP1 [16]. Este foi escolhido por se tratar de um processo mais simples para ser aplicado pela primeira vez no ambiente acadêmico.
O XP1 é baseado nas práticas do processo de desenvolvimento eXtreme Programming(XP) [17]. A sua elaboração foi feita levando em consideração o ambiente acadêmico em que os alunos geralmente não trabalham no projeto 40 horas semanais. Outros motivos para a adoção de XP1 foram por ser um processo ágil e indicado quando os requisitos funcionais do software não estiverem bem definidos, permitindo mudanças com um custo menor.
Papéis do Processo
Durante o processo de desenvolvimento os principais papéis assumidos pelos participantes deste projeto foram:
Cliente: Principal interessado pela conclusão rápida, com custo baixo e com qualidade do software. Responsável por definir as funcionalidades (User Stories) desejadas e tirar dúvidas que surgirem durante o desenvolvimento; descrever os requisitos não funcionais do software; definir o plano de release, escrever os testes de aceitação e definir quais atividades serão desenvolvidas para cada release.
Desenvolvedor: Responsável por ajudar o cliente a levantar as User Stories e os requisitos não funcionais; elaborar um projeto arquitetural e estimar o tempo de desenvolvimento das User Stories, durante a fase de planejamento de release; dividir as User Stories em tarefas, estimar, com precisão, o tempo de desenvolvimento de tarefas e escolher tarefas para desenvolver, durante a fase de planejamento de atividades; elaborar o esquema lógico dos dados, se necessário.
Gerente de Projeto: Conduz as atividades de planejamento; aloca revisores de testes; avalia riscos e toma providências quanto aos riscos descobertos; mantém o progresso do projeto.
6 o Nesta etapa (Projeto 2 ), os gerentes de cada release são:
Release 1 – Andressa Bezerra Ferreira Release 2 – Renata Braga de Andrade Release 3 – Camila Pascoal
Release 4 – Andressa Bezerra Ferreira Release 5 – Renata Braga de Andrade Release 6 – Camila Pascoal
Release 7 – Andressa Bezerra Ferreira
Atividades do Processo
O processo foi dividido em planejamento, iteração e releases; foi planejado que haveria 7 releases, cada uma contendo 1 iteração, com duração de 2 semanas.
Release: é a liberação pública de uma nova versão de um programa ao qual foram adicionadas correções e melhorias
Iteração: Uma iteração abrange as atividades de desenvolvimento que conduzem à liberação de um produto - uma versão do produto estável e executável, junto com qualquer outro elemento periférico necessário para usá-lo. Portanto, uma iteração de desenvolvimento é de certa forma uma passagem completa por todas as etapas: pelo menos Requisitos, Análise & Design, Implementação e Teste.
Planejamento:
O planejamento é uma ferramenta administrativa, que possibilita perceber a realidade, avaliar os caminhos, construir um referencial futuro, estruturando o trâmite adequado e reavaliar todo o processo a que o planejamento se destina. Sendo, portanto, o lado racional da ação.
Artefatos
Em XP1, artefatos representam informações que devem ser guardadas sob controle de versão de forma permanente e em sincronia. XP1 não sugere muitos artefatos, numa tentativa de minimizar esforços de sincronização. Os artefatos de XP1 são:
Artefatos sob responsabilidade do cliente: User Stories;
Requisitos não funcionais;
O plano de releases (cronograma). Artefatos de desenvolvimento: O projeto arquitetural; Código; Testes. Artefatos de gerência: Os planos de iteração;
7 Tabela de risco;
8
Análise e Requisitos
Introdução
Neste capítulo será descrita a análise do projeto mediante a apresentação do seu modelo conceitual e de cada requisito funcional e não-funcional e sua arquitetura.
Requisitos Não-Funcionais
O servidor deve ser escrito em PHP rodando em cima de Jabber.
A interface do sistema deve ser compatível com os browsers Internet Explorer , Mozilla Firefox e Chrome.
o A interface deve ser feita em PHP
o O sistema deve suportar cerca de 2000 ( esse número ainda está em estudo ) conversas simultâneas por máquina.
O sistema deve ser escalável(Caso eu use duas máquinas o sistema deve suportar 4000 conversas simultâneas; para 3 máquinas, 6 mil conversas e assim por diante).
O sistema deve ser desenvolvido de forma que a configuração das máquinas (Core 2 Duo, 8Gb RAM, onde somente 1Gb deve estar sendo usado pelo sistema) o suporte.
o OBS: Essas configurações de hardware são para dar suporte ao lado servidor do Chat; o lado cliente roda na web ( nos brownsers IE, Firefox e Chrome) , não importando assim a configuração de hardware.
Requisitos Funcionais
Logar: Ao entrar na sua conta do Turingo, o chat já se loga automaticamente; assim como no facebook e gmail.
Logout: O usuário, ao entrar no turingo e ter seu bate-papo carregado, pode optar por sair do chat.
Iniciar conversa: Após logado, qualquer turista pode falar com qualquer agência ( online ) e qualquer agência pode falar com qualquer turista (online.)
9 as opções: Online, Ocupado e Ausente ( Offline sai do chat ).
10
Arquitetura
A principal decisão-chave da arquitetura do projeto foi a escolha da tecnologia Jabber, pois como se trata de um sistema de bate-papo a comunicação é o essencial.
Decisão-Chave Utilizar tecnologia Jabber
Drivers RNF: O sistema deve ser escalável.
Descrição
Flexibilidade - as aplicações Jabber, além das mensagens
instantâneas, incluem gerenciamento
de rede, gestão de
conteúdo, ferramentas de colaboração, compartilhamento de arquivos, jogos e monitoramento remoto de sistemas.
Vantagens O sistema pode ser distribuído de
forma que não limita o número de usuários.
Desvantagens Observações
Mais vantagens oferecidas pela tecnologia jabber:
Abertura - os protocolos Jabber são gratuitos, abertos, públicos e de fácil compreensão ,além disso existem múltiplas implementações de clientes, servidores, componentes e bibliotecas de código.
Padronização - A IETF( Internet Engineering Task Force ), formalizou o núcleo dos protocolos XML de transmissão de dados como uma tecnologia de mensagens instantâneas e presença sob o nome de XMPP e as especificações XMPP foram publicadas como RFC 3920 e RFC 3921.
Confiabilidade - as primeiras tecnologias Jabber foram desenvolvidas por Jeremie Miller em 1998 e estão bastante estáveis agora, centenas de desenvolvedores estão trabalhando em tecnologias Jabber, existem dezenas de milhares de servidores Jabber funcionando na Internet hoje e milhões de pessoas usando o Jabber como mensageiro instantâneo.
11 confiabilidade do sistema, partindo do fato que o protocolo XMPP será usado através do Jabber; garante-se que o sistema também possui a mesma confiabilidade.
Descentralização - a arquitetura da rede Jabber é similar ao e-mail, como resultado qualquer um pode ter o seu próprio servidor Jabber, permitindo às pessoas e organizações terem total controle sobre suas mensagens instantâneas.
Segurança - qualquer servidor Jabber pode ser isolado da rede Jabber pública ( por exemplo, a intranet da empresa ), além disso fazem parte das especificações XMPP medidas de segurança robustas, usando SASL e TLS.
o Segurança do Sistema: A segurança do sistema com relação ao lado cliente é feita por meio do login no Turingo ( ao se logar no turingo, loga-se no chat). A segurança no lado servidor também é feita via autenticação por login.
Extensibilidade - usando o poder das "XML namespaces", qualquer um pode construir funcionalidades sobre os protocolos centrais, para manter a interoperabilidade, as extensões comuns são mantidas pela Jabber Software Foundation.
Flexibilidade - as aplicações Jabber, além das mensagens instantâneas, incluem gerenciamento de rede, gestão de conteúdo, ferramentas de colaboração, compartilhamento de arquivos, jogos e monitoramento remoto de sistemas.
Diversidade - uma grande quantidade de empresas e projetos de código aberto usam os protocolos Jabber para criar e desenvolver aplicações e serviços.
Estrutura da Arquitetura
O projeto arquitetural é subdivido em dois, já que trata-se de um sistema cliente servidor.
12 Arquitetura Jabber
As tecnologias usadas serão:
FrontEnd ( entenda FrontEnd como sendo o cliente web): Jabber , HTML,
Bibliotecas
XMPP, PHP e JavaScript
BackEnd ( entenda BackEnd como sendo o servidor para o chat, que estará rodando nas máquinas da empresa do cliente ): O servidor Jabber openfire.
No lado cliente, a tecnologia usada será principalmente JavaScript e HTML ; no lado servidor será usado o servidor Jabber Openfire que é feito em PHP usando da tecnologia XMPP para fazer comunicação com os clientes vias httpRequest. O servidor estará rodando em um espaço chamado Octoputs alocado dentro do servidor da empresa; o octopus fará chamadas REST ao tomcat para saber quais novos usuários do Turingo vão se tornar também novos usuários do chat turingo, será utilizado também hadoop, hbase e um balanceador de carga. O cliente estará rodando na web; quer seja no navegador IE, Firefox ou Chrome.
13 Componentes da arquitetura Jabber:
Jabber Session Messenger(JSM) – O JSM gerencia o registro de
novas contas, autentica usuários, e gerencia informações sobre presença.
C2S(Cliente-to-Server) – C2S manipula as conexões entre o servidor e seus
clientes. A principal tarefa é a formatação e roteamento de mensagens entre clientes e outros componentes.
S2S(Server-to-Server) – S2S manipula conexões entre o servidor jabber
e outros servidores.
Xdb( XML Database) – xbd é o mecanismo de armazenamento
persistente compartilhado para o servidor jabber.
Logger – Responsável por registrar mensagens de controle de outros
componentes para o servidor . Registra mensagens, registra o login e logout de usuários, erros e assim por diante.
Dnsrv(DNS servisse) – converte nomes de servidores em endereços IP. Jabber User Directory(JUD) – fornece serviços que habilitam clientes exibir
informações de seu contato, bem como a disponibilização de informações de outros contatos do cliente.
Conferencing (conf) – Permite formar grupos de clientes (salas de bate-papo). Component BUS - é o backbone do servidor.
Cliente Web
A aplicação cliente do sistema web que irá ser executada nos browsers dos computadores dos usuários do bate-papo será implementada usando plugins javascript para que a interface seja semelhante ao chat do facebook/gtalk.
14 Toda a comunicação da página HTML+javascript com o back-end do sistema deve ser feita utilizando PHP, linguagem para desenvolvimento web mais utilizada hoje em dia por disponibilizar mais recursos necessários a essa comunicação.
Acessado de qualquer browser, não é necessária a instalação de nenhum
aplicativo por parte do cliente.
Dividindo em módulos, temos as seguintes estruturas:
Ao fazer o login no site do turingo, a página HTML é carregada no browser já com a interface do chat, que será feita utilizando um framework para javascript chamado Jquery,que possui uma extensão com diversos recursos de interface gráfica, o Jquery UI.Ao escolher iniciar uma conversa as requisições serão feitas para o servidor php que irá estabelecer a comunicação com o backend usando bibliotecas XMPP que disponibiliza métodos de acesso como “connect”, “message”, “desconnect”, “processUntil” de acordo com a biblioteca escolhida, como por exemplo a XMPPHP que dá suporte aos métodos citados.
É importante destacar que a compatibilidade com os diversos browsers é influenciada pela forma de implementação do frontEnd do sistema,no que diz respeito às páginas HTML+javascript e os plugins utilizados, ou seja, vários testes de alto nível devem ser feitos para garantir a funcionalidade em todos os browsers definidos.
O cliente deve ainda, possibilitar a mudança de status do usuário, e a abertura de várias conversas simultâneas, tendo um limite máximo de janelas definido pelo administrador do sistema.
Além disso, o cliente web deve ter opções de fechamento de janela, minimização, e status invisível para o caso do usuário não desejar falar com nenhum outro.Caso o número máximo de janelas seja ilimitado,deve existir um mecanismo de
15 agrupamento de conversas para que todas sejam facilmente acessadas quando o número for suficientemente grande.
De acordo com as regras de negócio que serão implementadas, o usuário só pode iniciar uma conversa com agências de turismo, logo, o cliente web deve exibir a lista de perfis disponíveis para bate-papo de acordo com o tipo de usuário que está utilizando. Como solução para o cliente web, estamos usando o Jappix Mini, que satisfaz aos requisitos que procuramos e segue a arquitetura mostrada acima.
16
Verificação e Validação
A verificação e validação de software asseguram que o software cumpra com suas especificações e atenda às necessidades dos usuários.
Verificação: ”Estamos construindo certo o produto?" O software cumpre com suas especificações. Validação: Estamos construindo o produto certo?"
O software deve estar de acordo com o que o usuário deseja.
Verificação
A verificação é feita através da testabilidade, e esta por sua vez será feita através de teste de carga e teste de escala.
Os testes de carga serão feitos através do endereço de loopback simulando diversos usuários logados no chat, espera-se que o chat funcione normalmente com o número de usuários que o cliente do projeto deseja. Outra possível ferramenta para testes de carga é o tsung, que ainda está em fase de estudo.
Os testes de escala são feitos no servidor, e o servidor usado para o desenvolvimento do projeto ( Openfire ) já garante escalabilidade.
Validação
A validação do software é feita através do acompanhamento por parte do cliente, em todas as etapas, através de testes no uso do sistema.
17
Métricas
Big Chart
Nesse tópico mostraremos o uso do big chart; o big chart é um gráfico que serve para o acompanhamento da coleta de métricas. E escolhemos usá-lo por concordarmos que seria a melhor opção para esse caso; além do que já tínhamos conhecimento da ferramenta pois a usamos em outra(s) disciplina(s). No nosso caso, os pontos usados para o big chart foram: Classes, Testes de Aceitação, Testes de Unidade, Paginas JavaScript, User Stories, Testes de Carga e Ferramentas Analisadas. Abaixo segue o gráfico inicial em projeto 2.
Observações:
O Big Chart é ser atualizado a cada reunião de acompanhamento (final de cada Release).
18
Conclusões
19
Referências Bibliográficas
MOFFITT, Jack. Professional XMPP Programming with JavaScript and jQuery. Wrox. 2010.
SAINT-ANDRE, Peter. “Extensible Messaging and Presence Protocol (XMPP): InstantMessagingandPresence”. 10/2004. Disponível em http://xmpp.org/rfcs/rfc3921.html, Acessado em Agosto de 2011.
CASCARDO, Thadeu Lima de Souza,
Jabber e XMPP: protocolo extensível paramensagens e presença
, Disponível em: <cascardo.info/lacfree.pdf>, Acessado em Agosto de 2011.
20
Apêndices
A seguir telas do servidor e do cliente ( legendas abaixo das imagens ):
21 Página de gerenciamento das configurações do servidor.
22 Página com a lista de usuários do servidor.
23 Página com as salas de conferência.
24 Chat carregando.
25 Servidor mostrando usuário logado.
26 Dois usuários conversando na sala de turismo João Pessoa.
