Embed Size (px)
Citation preview
Barramento Generico de Dados para Software de Videoconferencia
em Ambiente Multiplataforma
Vinıcius Heineck dos Santos
Projeto de Graduacao apresentado ao Curso
de Engenharia Eletronica e de Computacao
da Escola Politecnica, Universidade Federal
do Rio de Janeiro, como parte dos requisitos
necessarios a obtencao do tıtulo de Enge-
nheiro.
Orientador: Prof. Sergio Barbosa Villas-
Boas, Ph. D.
Rio de Janeiro
Abril de 2014
Universidade Federal do Rio de Janeiro
Escola Politecnica
Departamento de Eletronica e de Computacao
Barramento Generico de Dados para Software de
Videoconferencia em Ambiente Multiplataforma
Autor:
Vinıcius Heineck dos Santos
Orientador:
Prof. Sergio Barbosa Villas-Boas, Ph. D.
Examinador:
Prof. Aloysio de Castro Pinto Pedroza, D. Sc.
Examinador:
Prof. Flavio Luis de Mello, D. Sc.
DEL
Abril de 2014
ii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politecnica - Departamento de Eletronica e de Computacao
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitaria
Rio de Janeiro - RJ CEP 21949-900
Este exemplar e de propriedade da Universidade Federal do Rio de Janeiro, que
podera incluı-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
E permitida a mencao, reproducao parcial ou integral e a transmissao entre bibli-
otecas deste trabalho, sem modificacao de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa academica, comentarios e citacoes, desde3 que
sem finalidade comercial e que seja feita a referencia bibliografica completa.
Os conceitos expressos neste trabalho sao de responsabilidade do(s) autor(es) e
do(s) orientador(es).
iii
DEDICATORIA
Dedico aos meus pais, Luiz Carlos dos Santos e Martha Heineck Soares dos Santos,
meus avos, Maria da Penha Soares e Francisco Heineck Soares (In Memorian), meu
irmao, Vagner Luiz Heineck dos Santos, minha esposa, Tatiana Nempomuceno e ao
amigo Felipe Jose Ennes de Carvalho pela forca adquirida em mais uma conquista da
minha vida. Minha filha Julia Nepomuceno Heineck tambem foi muito importante
para dar-me mais forca na obtencao dessa conquista.
iv
AGRADECIMENTO
Dedico este trabalho ao povo brasileiro que contribuiu de forma significativa a
minha formacao e estada nesta Universidade. Este projeto e uma pequena forma de
retribuir o investimento e confianca em mim depositados.
Agradeco tambem meu orientador Sergio Barbosa Villas-Boas, Ph. D., por todo
conhecimento adquirido ao longo dos anos que trabalhamos juntos.
v
RESUMO
E notorio nos tempos atuais, que por motivos diversos, como a piora do transito
nas metropoles, e ainda a ocupacao maior do nosso tempo em diferentes tarefas,
ou ainda a vontade de dar acesso ao conhecimento nas regioes mais distantes do
paıs, o conceito de ensino a distancia vem se tornando cada vez mais popular,
sendo oferecido hoje ate como cursos em universidades. Todavia, os sistemas mais
conhecidos sao disponibilizados em forma de vıdeos e apresentacoes previamente
gravadas, e o aluno tira suas duvidas atraves de e-mails ou chat.
Diante desse cenario desenvolvemos o Telecontents, um sistema de videocon-
ferencia voltado para o ensino. A proposta e que as aulas sejam ministradas em
tempo real atraves de canais que seriam as salas de aula, tendo um usuario princi-
pal(mediador do canal) que controla o acesso dos demais usuarios. Alem da trans-
missao de vıdeo, existe uma funcionalidade denominada whiteboard, uma especie de
lousa virtual colaborativa.
Este projeto consiste na criacao de um framework para o Telecontents, o mesmo
ira viabilizar um sistema de extensoes que poderao ser posteriormente criados por
outros desenvolvedores. Este documento tambem fornecera um modelo de criacao
de novos plugins.
Palavras-Chave: plugin, EAD, framework, c++, engenharia de software.
vi
ABSTRACT
It is notorious in recent times, who for various reasons, such as worsening traffic in
the metropolis, and still the largest occupation of our time on different tasks, or even
the desire to give access to knowledge in the most distant regions of the country, the
concept of distance learning is becoming increasingly popular, even being offered
today as courses in universities. However, the best known systems are available in
the form of videos and pre-recorded presentations, and student takes your questions
via email or chat.
In this scenario we developed Telecontents, a videoconferencing system for tea-
ching. The proposal is that the classes are taught in real time through channels that
would be classrooms, with a primary user (broker channel) that controls access by
other users. Besides the video transmission, there is a feature called whiteboard, a
kind of collaborative whiteboard.
This project consists in creating a framework for telecontents, which is a distance
learning software, it will enable a extensions system that may subsequently be cre-
ated by other developers. This document also provides a model for creating new
plugins.
Key-words: plugin, EAD, framework, c++, software engineering.
vii
SIGLAS
UFRJ - Universidade Federal do Rio de Janeiro
API - Application Program Interface
GBP - Generic Binary Package
MVC - Model View Controller
DAO - Data Access Object
DTO - Data Transfer Object
UML - Unified Modeling Language
DLL - Dynamic Link Library
LCMS - Learning Content Management System
IP - Internet Protocol
GUI - Graphical User Interface
viii
Sumario
1 Introducao 1
1.1 Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Delimitacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Descricao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fundamentacao teorica 4
2.1 Metodologias de desenvolvimento ageis . . . . . . . . . . . . . . . . . 4
2.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Late Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Explicit linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Concorrentes do Telecontents . . . . . . . . . . . . . . . . . . . . . . 19
3 Telecontents Generic Binary Package Kernel 21
3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Adicao do GBP Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Datagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Conversoes entre bytes e inteiros . . . . . . . . . . . . . . . . . . . . . 25
3.5 Gerenciamento do envio e recebimento de informacoes . . . . . . . . . 26
4 Criacao do plugin 29
4.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Como e o transmissor? . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ix
4.3 Como e o receptor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Integracao do plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Metodos do receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Metodos do transmissor . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Worker Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Testes 39
5.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Teste de plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Teste de funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Teste de informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Consideracoes finais 49
6.1 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Bibliografia 51
x
Lista de Figuras
2.1 Processo Scrum. Fonte: Eclipse [1]. . . . . . . . . . . . . . . . . . . . . 9
2.2 Exemplo de Design patterns em UML, modelo MVC. Fonte: Linha de
Codigo [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Diagrama de Late Bind. Fonte: Jose Carlos Macoratti [3]. . . . . . . . . . 13
2.4 Exemplo de ponteiro de funcao. Fonte: Alex [4]. . . . . . . . . . . . . . . 15
3.1 Arquitetura do Telecontents. . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Arquitetura do Telecontents atualizada. . . . . . . . . . . . . . . . . . . 23
3.3 Pacote do GBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Transmissor do modulo dbgGBP. . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Receptor do modulo dbgGBP. . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Comando include do GBPKernel. . . . . . . . . . . . . . . . . . . . . . 35
4.4 Classe derivada de GBPKernel. . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Definindo os metodos derivados de GBPKernel na classe dbgGBP. . . . . 36
4.6 Implementacao do metodo Open. . . . . . . . . . . . . . . . . . . . . . 36
4.7 Implementacao do metodo GetPluginId. . . . . . . . . . . . . . . . . . . 37
4.8 Implementacao do metodo GetPluginName. . . . . . . . . . . . . . . . . 37
4.9 Implementacao do metodo ReceiveData. . . . . . . . . . . . . . . . . . . 38
4.10 Funcionamento do Worker Thread . . . . . . . . . . . . . . . . . . . . . 38
5.1 Modulo dbgGBP desinstalado. . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Mensagem de inexistencia de modulos. . . . . . . . . . . . . . . . . . . . 40
5.3 Modulo dbgGBP instalado. . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Tela de selecao de modulos. . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5 Envio de um sinal pelo transmissor do modulo dbgGBP. . . . . . . . . . . 42
5.6 Transmissor - 10 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . 43
xi
5.7 Receptor - 10 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.8 Resultado - 10 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9 Transmissor - 100 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . 45
5.10 Receptor - 100 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.11 Resultado - 100 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.12 Transmissor - 1000 caracteres. . . . . . . . . . . . . . . . . . . . . . . . 46
5.13 Receptor - 1000 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.14 Resultado - 1000 caracteres. . . . . . . . . . . . . . . . . . . . . . . . . 47
xii
Lista de Tabelas
xiii
Capıtulo 1
Introducao
1.1 Tema
O presente projeto consiste na criacao de um framework para o sistema de ensino a
distancia, Telecontents, que tornara a criacao de novas funcionalidades mais flexıvel.
Este sistema foi concebido com base em conceitos de engenharia de software,
visando a garantia de sua qualidade desde a especificacao, implementacao e manu-
tenibilidade, buscando chegar o mais proximo do otimo.
O framework pode atingir uma funcionalidade especıfica, por configuracao, du-
rante a programacao de uma aplicacao. E um conjunto de conceitos usado para
resolver um problema de um domınio especıfico. Conjunto de rotinas e padroes
estabelecidos por um software para a utilizacao das suas funcionalidades por apli-
cativos que nao pretendem envolver-se em detalhes da implementacao do software,
mas apenas usar seus servicos. O fornecimento de um link especıfico para que outros
autores criem plugins, estendendo as funcionalidades do programa.
1.2 Delimitacao
A educacao a distancia e muito importante nos dias de hoje, devido a varios
fatores que serao discutidos em breve, logo o Telecontents se torna mais dinamico
e completo quando existir esse framework que tornara viavel a criacao de novos
1
modulos de acordo com a demanda de clientes em especıfico, a medida que novos
conceitos, tecnologias ou formas de lecionar surgirem.
1.3 Justificativa
Nos tempos de hoje presenciamos um aumento da populacao nas grandes cidades,
e consequentemente a locomocao esta ficando cada vez mais difıcil, e notorio os
constantes congestionamentos nas estradas, bem como trens e metros lotados. Em
contrapartida existem cidades de interior, onde o acesso a educacao convencional
torna-se difıcil. Tais caracterısticas de nossa sociedade contemporanea, juntamente
com a disseminacao da internet e o crescimento rapido da banda larga contribuıram
para a criacao do conceito de educacao a distancia, onde o ensino chega ate o aluno.
1.4 Objetivos
O Telecontents e um sistema de videoconferencia aplicado ao ensino a distancia.
Ele opera com um protocolo modificado do IRC, que foi denominado IRM. Este
modelo consiste na criacao de canais, que no contexto podem ser atribuıdos como
as disciplinas, cada canal possui um moderador, que seria o professor, e os demais
usuarios, que sao os alunos. A funcionalidade principal e a videoconferencia, onde
todos os usuarios se visualizam, mas somente o moderador tem direito ao audio,
porem os demais usuarios pedem a vez e recebem o direito de voz, de acordo com
o moderador do canal. Outra funcionalidade implementada e o chat, onde cada
usuario pode enviar mensagens aos demais (chat publico), ou direcionadas a outro
especıfico (chat privado). Ja encontra-se implementado a transferencia de arquivos,
onde o moderador pode enviar uma imagem, por exemplo, de forma publica aos
demais usuarios do canal. Outra funcionalidade interessante implementada, onde o
moderador e capaz de desenhar numa lousa virtual, e os demais usuarios sao capazes
dessa visualizacao em tempo real, analogamente ao quadro negro, foi denominado
Whiteboard. O tema do presente projeto e a criacao de uma API que facilitara a
criacao de novas funcionalidades a esse sistema.
2
1.5 Metodologia
O assunto foi proposto sobre a experiencia de que poderia existir uma infinidade de
novas caracterısticas ao software, e o conhecimento da complexidade de criacao das
mesmas. O objetivo a ser alcancado e a diminuicao dessa complexidade, tornando
mais simples o trabalho de outros desenvolvedores que criarao os plugins. O projeto
sera concebido seguindo o metodo de desenvolvimento agil conhecido como Scrum.
1.6 Descricao
No capıtulo 2 sera definido as diferencas entre as metodologias classicas e as
metodologias ageis. O conceito sera aprofundado, explicitando os principais metodos
utilizados ate o Scrum, ao qual utilizamos nesse projeto. Logo sera demonstrado
todo o funcionamento desse metodo agil.
O capıtulo 3 apresenta uma explicacao teorica das tecnologias mais importantes
na implementacao de um plugin, desde o conceito de design patterns, passando pelo
late binding ate o significado de explicit linkage.
As alteracoes no Kernel do sistema para a criacao da nova estrutura que viabiliza o
barramento generico de dados sao apresentadas no capıtulo 4. Nele sera explicitado
em que camada do sistema o GBPKernel foi implementado. Na presente secao e
demonstrada toda a implementacao desse novo kernel. Ainda neste capıtulo, o leitor
compreende o funcionamento da plataforma.
No capıtulo 5 sera definido um tutorial de criacao de plugins seguindo o modulo
de exemplo denominado dbgGBP.
O capıtulo 6 apresentara os testes de funcionamento do barramento generico de
dados atraves do modulo criado no capıtulo 5.
3
Capıtulo 2
Fundamentacao teorica
2.1 Metodologias de desenvolvimento ageis
A expressao ”Metodologias Ageis”tornou-se conhecida em 2001, quando especia-
listas em processos de desenvolvimento de software representando entre outros, os
metodos Scrum e Extreme Programming (XP), foram estabelecidos princıpios e ca-
racterısticas comuns destes metodos. Assim foi criada a ”Alianca Agil”e efetuou-se
o estabelecimento do ”Manifesto Agil”.
O desenvolvimento agil, tal como qualquer metodologia de software, providencia
uma estrutura conceitual para reger projetos de engenharia de software. A maio-
ria dos metodos ageis tenta minimizar o risco pelo desenvolvimento do software em
curtos perıodos, chamados de iteracao, os quais gastam tipicamente menos de uma
semana a ate quatro. Cada iteracao e como um projeto de software em miniatura de
seu proprio, e inclui todas as tarefas necessarias para implantar o mini-incremento
da nova funcionalidade: planejamento, analise de requisitos, projeto, codificacao,
teste e documentacao. Enquanto em um processo convencional, cada iteracao nao
esta necessariamente focada em adicionar um novo conjunto significativo de funcio-
nalidades, um projeto de software agil busca a capacidade de implantar uma nova
versao do software ao fim de cada iteracao, etapa a qual a equipe responsavel reavalia
as prioridades do projeto.
Metodos ageis enfatizam comunicacoes em tempo real, preferencialmente face a
face, a documentos escritos. A maioria dos componentes de um grupo agil deve
4
estar agrupada em uma sala. Isso inclui todas as pessoas necessarias para terminar
o software: no mınimo, os programadores e seus clientes. Nesta sala devem tambem
se encontrar os testadores, projetistas de iteracao, redatores tecnicos e gerentes.
Metodos ageis tambem enfatizam trabalho no software como uma medida primaria
de progresso. Combinado com a comunicacao face-a-face, metodos ageis produzem
pouca documentacao em relacao a outros metodos, sendo este um dos pontos que
podem ser considerados negativos. E recomendada a producao de documentacao
que realmente sera util.
Os princıpios do desenvolvimento agil valorizam:
• Garantir a satisfacao do consumidor entregando rapidamente e continuamente
softwares funcionais;
• Softwares funcionais sao entregues frequentemente (semanas, ao inves de me-
ses);
• Softwares funcionais sao a principal medida de progresso do projeto;
• Ate mesmo mudancas tardias de escopo no projeto sao bem-vindas;
• Cooperacao constante entre pessoas que entendem do ”negocio”e desenvolve-
dores;
• Projetos surgem atraves de indivıduos motivados, entre os quais existe relacao
de confianca;
• Design do software deve prezar pela excelencia tecnica;
• Simplicidade;
• Rapida adaptacao as mudancas;
• Indivıduos e interacoes mais do que processos e ferramentas;
• Software funcional mais do que documentacao extensa;
• Colaboracao com clientes mais do que negociacao de contratos;
• Responder a mudancas mais do que seguir um plano.
5
Embora os metodos ageis apresentem diferencas entre suas praticas, eles compar-
tilham inumeras caracterısticas em comum, incluindo o desenvolvimento iterativo, e
um foco na comunicacao interativa e na reducao do esforco empregado em artefatos
intermediarios. A aplicabilidade dos metodos ageis em geral pode ser examinada
de multiplas perspectivas. Da perspectiva do produto, metodos ageis sao mais ade-
quados quando os requisitos estao emergindo e mudando rapidamente, embora nao
exista um consenso completo neste ponto. De uma perspectiva organizacional, a
aplicabilidade pode ser expressa examinando tres dimensoes chaves da organizacao:
cultura, pessoal e comunicacao. Em relacao a estas areas inumeros fatores chave do
sucesso podem ser identificados: A cultura da organizacao deve apoiar a negociacao;
As pessoas devem ser confiantes; Poucas pessoas, mas competentes; A organizacao
deve promover as decisoes que os desenvolvedores tomam; A Organizacao necessita
ter um ambiente que facilite a rapida comunicacao entre os membros.
O fator mais importante e provavelmente o tamanho do projeto. Com o aumento
do tamanho, a comunicacao face-a-face se torna mais difıcil. Portanto, metodos
ageis sao mais adequados para projetos com pequenos times, com no maximo de 20
a 40 pessoas.
Uma grande desvantagem encontrada nas metodologias de desenvolvimento ageis
relatadas sao crıticas que incluem falta de estrutura e documentacao necessarias.
Em nosso projeto a metodologia de desenvolvimento agil adotada foi SCRUM,
que sera melhor explicada na secao seguinte.
2.2 Scrum
O Scrum e um processo de desenvolvimento iterativo e incremental para geren-
ciamento de projetos e desenvolvimento agil de software. Apesar de a palavra nao
ser um acronimo, algumas empresas que implementam o processo a soletram com
letras maiusculas como SCRUM. Isto pode ser devido aos primeiros artigos de Ken
Schwaber, que capitalizava SCRUM no tıtulo. Scrum nao e um processo prescri-
bente, ou seja, ele nao descreve o que fazer em cada situacao. Ele e usado para
6
trabalhos complexos nos quais e impossıvel predizer tudo o que ira ocorrer. Apesar
de Scrum ter sido destinado para gerenciamento de projetos de software, ele pode
ser utilizado em equipes de manutencao de software ou como uma abordagem geral
de gerenciamento de projetos/programas.
Inicialmente, o SCRUM foi concebido como um estilo de gerenciamento de proje-
tos em empresas de fabricacao de automoveis e produtos de consumo, por Takeuchi
e Nonaka. Eles notaram que projetos usando equipes pequenas e multidisciplinares
produziram os melhores resultados, e associaram estas equipes altamente eficazes a
formacao Scrum do Rugby (utilizada para reinıcio do jogo em certos casos). Jeff
Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e im-
plementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em
1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka.
Em 1995, Ken Schwaber formalizou a definicao de Scrum e ajudou a implanta-lo no
desenvolvimento de softwares em todo o mundo. Scrum junta conceitos de Lean,
desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka. A
funcao primaria do Scrum e ser utilizado para o gerenciamento de projetos de de-
senvolvimento de software. Ele tem sido usado com sucesso para isso, assim como
Extreme Programming e outras metodologias de desenvolvimento. Porem, teorica-
mente pode ser aplicado em qualquer contexto no qual um grupo de pessoas neces-
sitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola
pequena, projetos de pesquisa cientıfica, entre outros. Mesmo que idealizado para
ser utilizado em gestao de projetos de desenvolvimento de software ele tambem pode
ser usado para a gerencia de equipes de manutencao, ou como uma abordagem para
gestao de programas: Scrum de Scrums.
Caracterısticas
• Equipes que se auto-organizam, O produto evolui em uma serie de ”Sprints”mensais;
• Os requerimentos sao listados em um ”Product Backlog”;
• Nao ha pratica de engenharia prescrita (o Scrum adequa-se a todas);
7
• Usa regras generativas na criacao de um ambiente agil para a entrega de pro-
jetos;
• E uma das ”metodologias ageis”.
Papeis
Product Owner: O product owner e responsavel pelas seguintes funcoes a seguir:
definir as funcionalidades do produto, ele decide datas de lancamento e conteudo, e
responsavel pela rentabilidade (ROI), priorizar funcionalidades de acordo com o va-
lor de mercado, ajustar funcionalidades e prioridades, aceitar ou rejeitar o resultado
dos trabalhos.
ScrumMaster: O ScrumMaster representa a gerencia para o projeto, e o res-
ponsavel pela aplicacao dos valores e praticas do Scrum, e o responsavel por remo-
ver obstaculos e garantir a plena funcionalidade e produtividade da equipe, tambem
garante a colaboracao entre os diversos papeis e funcoes, deve servir de escudo para
interferencias externas.
Equipe (Development Team): A equipe e responsavel pela entrega do produto. E
tipicamente composta de 5 a 9 pessoas com habilidades multifuncionais que fazem o
trabalho real (analisar, projetar, desenvolver, testar tecnicas de comunicacao, docu-
mentos, etc.). Recomenda-se que a equipe seja auto-organizada e auto-conduzida,
mas que muitas vezes trabalhem com alguma forma de projeto ou gestao de equipe.
Sprint
Um sprint e a unidade basica de desenvolvimento em Scrum. Sprints tendem a
durar entre uma semana e um mes, e sao um esforco dentro de um intervalo de
tempo de comprimento constante. Cada sprint e precedido por uma reuniao de
planejamento, onde as tarefas para o sprint sao identificadas e um compromisso es-
timado para o objetivo do sprint e definido e seguido por uma reuniao de revisao
ou de retrospectiva, onde o progresso e revisto e licoes para os proximos sprints sao
identificadas.
8
Figura 2.1: Processo Scrum. Fonte: Eclipse [1].
Durante cada sprint, a equipe cria um incremento de produto potencialmente en-
tregavel, por exemplo, software funcional e testado. O conjunto de funcionalidades
que entram em um sprint vem do ”backlog”do produto, que e um conjunto de priori-
dades de requisitos de alto nıvel do trabalho a ser feito. Durante um sprint, ninguem
esta autorizado a alterar o backlog do sprint, o que significa que os requisitos sao
congelados para esse sprint. Se os requisitos nao sao completados por qualquer mo-
tivo, eles sao deixados de fora e voltam para o backlog do produto. Depois que um
sprint e completado, a equipe demonstra como usar o software.
Um princıpio chave do Scrum e o reconhecimento de que, durante um projeto, os
clientes podem mudar de ideia sobre o que eles querem e precisam (muitas vezes
chamados requisitos churn), e que os desafios imprevisıveis nao podem ser facil-
mente tratados de uma maneira preditiva ou planejada tradicional. Como tal, o
Scrum adota uma abordagem empırica, aceitando que o problema nao pode ser to-
talmente entendido ou definido, focando na maximizacao da habilidade da equipe
para entregar rapidamente e responder as necessidades emergentes.
Artefatos
Product Backlog: Um backlog e uma lista de itens priorizados a serem desenvol-
vidos para um software. O Product Backlog e mantido pelo Product Owner e e
9
uma lista de requisitos que tipicamente vem do cliente. O Product Backlog pode
ser alterado a qualquer momento pelo Product Owner ou por decisao deste.
Sprint backlog: O Sprint backlog e uma lista de itens selecionados do Product
backlog e contem tarefas concretas que serao realizadas durante o proximo sprint
para implementar tais itens selecionados. O Sprint Backlog e uma representacao em
tempo real do trabalho que o Development Team planeja concluir na sprint corrente,
e ele pertence unicamente ao Development Team.
Sprint Planning Meeting: Reuniao de planejamento.
Sprint Goal: Disparo dos objetivos/metas.
Sprint Review Meeting: Revisao da reuniao.
Planejamento de sprint: Antes de todo sprint, o Product Owner, o Scrum Master
e o Development Team decidem no que a irao trabalhar durante o proximo sprint.
O Product Owner mantem uma lista priorizada de itens de backlog, o backlog do
produto, o que pode ser novamente priorizado durante o planejamento do sprint. A
Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o
quanto de trabalho eles podem executar para terminar. A Equipe entao planeja a
arquitetura e o design de como o backlog do produto pode ser implementado. Os
itens do backlog do produto sao entao destrinchados em tarefas que se tornam o
backlog do sprint.
Fases
As fases de desenvolvimento SCRUM podem ser divididas basicamente em tres,
sao elas:
• Planejamento: Definicao de uma nova funcionalidade requerida pelo sistema
baseado no conhecimento do sistema como um todo;
• Desenvolvimento: Desenvolvimento dessa nova funcionalidade respeitando o
tempo previsto, requisitos exigidos e qualidade. Esses itens definem o fim do
ciclo de desenvolvimento;
10
• Encerramento: Preparacao para a entrega do produto persistindo as ativi-
dades: Teste Caixa Branca, Teste Caixa Preta, Documentacao do Usuario,
Treinamento e Marketing.
2.3 Design Patterns
Como varias abordagens referentes a engenharia de software, os design patterns
tiveram suas raızes no trabalho do engenheiro civil Chistopher Alexander, que re-
digiu sobre as suas experiencias em resolver problemas de projetos encontrados em
construcoes em geral.
Os princıpios de Alexander foram trazidos para o desenvolvimento de software,
que culminou na publicacao da obra ”Design Patterns: Elements of Reusable Object-
Oriented Software”, de 1995 por Eric Gamma, Richard Helm, Ralph Johnson e John
Vlissides. Este livro e considerado a principal referencia de design patterns para a
comunidade de software e tem influenciado na evolucao dos padroes de projeto desde
entao. A obra descreveu 23 padroes baseados na experiencia dos autores. Muitos
outros padroes foram documentados e catalogados desde a publicacao de Design
Patterns. Entretanto, esses 23 iniciais sao provavelmente os mais populares.
Em termos de documentacao, os design patterns sao altamente estruturados. Eles
sao documentados a partir de um modelo que identifica a informacao necessaria para
entender o problema do software e a solucao em termos de relacionamentos entre
as classes e objetos necessarios para implementar essa solucao. Nao ha um ponto
comum na comunidade de design patterns sobre como descrever um template de pat-
terns. Alguns autores preferem ser mais expressivos e menos estruturados, enquanto
outros preferem que seus templates sejam mais precisos e altamente estruturados.
A UML tem papel importante nessa documentacao. E comumente usada para
descrever patterns e cataloga-los, incluindo diagrama de classes, de sequencia ou de
interacoes.
Raramente um pattern e utilizado isoladamente. Tipicamente, os patterns tem
relacionamentos e trabalham em conjunto. Quanto mais familiarizado com os dife-
11
rentes tipos de design patterns, melhor instruıdo se estara para determinar interacoes
entre esses componentes.
Como exemplo de aplicacoes em camadas com uso de componentes, existem quatro
patterns especıficos, com caracterısticas de melhora de performance de um sistema
e facilidade de manutencao. Sao eles MVC, DAO, DTO e Session Facade.
Figura 2.2: Exemplo de Design patterns em UML, modelo MVC. Fonte:
Linha de Codigo [2].
Um dos mais usados nos dias de hoje e o design pattern MVC, que permite que
se separe o modelo de dados das varias formas que o dado possa ser acessado e
manipulado. Um sistema MVC e dividido em um modelo de dados, um conjunto
de visoes e um conjunto de controladores. Na verdade existem quatro componentes
em uma aplicacao MVC, nao tres, ja que o cliente e uma parte integrante de toda a
operacao. Desacoplar as visoes do processo de requisicao torna mais facil criar novas
visoes para novos formatos. Uma aplicacao poderia apresentar uma interface HTML
e depois adicionar visoes WML (para dispositivos wireless) e visoes XML (para Web
services) futuramente. E importante ressaltar que nesse projeto o modelo MVC nao
foi adotado, o mesmo so foi explicitado como exemplo de design pattern.
12
2.4 Late Binding
Uma ligacao ( Binding) e um processo de chamada de funcao escrita para o codigo
atual que implementa a funcao e e feito quando a aplicacao e compilada e todas as
funcoes chamadas no codigo estarao ligadas/definidas antes do codigo ser executado.
Assim , seu codigo e constituıdo de partes que precisam estar agrupadas antes do
codigo poder ser lido. A ligacao e a acao de substituir os nomes das funcoes pelo
enderecos de memoria para onde o codigo sera referenciado.
E importante ressaltar que a linguagem C usa apenas early binding, mas a lin-
guagem C++ opera early binding e late binding, de acordo com os parametros de
compilacao.
Quando um programa e compilado, o compilador converte cada comando do seu
programa em C++ em uma ou mais linhas de linguagem de maquina. Cada linha da
linguagem de maquina possui um unico endereco de memoria sequencial. Isto para as
funcoes nao e diferente - quando uma funcao e encontrada, a mesma e convertida em
linguagem de maquina e e dada a ela o proximo endereco disponıvel. Desta forma,
cada funcao termina com um enderecamento em linguagem de maquina unico.
Binding refere-se a este processo que e usado para converter identificadores (como
as variaveis e nomes de funcoes) em enderecos de linguagem de maquina.
Figura 2.3: Diagrama de Late Bind. Fonte: Jose Carlos Macoratti [3].
Historico
13
O termo ”late binding”existe pelo menos desde 1960, onde pode ser encontrado
em artigos da revista cientıfica ”Communications of the ACM”[5]. O termo era
largamente usado para descrever linguagens como o LISP, embora geralmente como
conotacoes negativas sobre performance.
Nos anos de 1980 a linguagem SmallTalk tornou-se popular com programacao
orientada a objetos e tambem late binding. Dr. Alan Kay disse uma vez, ”OOP
to me means only messaging, local retention, and protection and hiding of state-
process, and extreme late-binding of all things. It can be done in Smalltalk and in
LISP. There are possibly other systems in which this is possible, but I’m not aware
of them.”
Do comeco ate os meados dos anos de 1990, a Microsoft promoveu fortemente seu
modelo COM como uma interface binaria entre diferentes linguagens de programacao
orientada a objetos. A programacao COM foi igualmente promovida com early e
late binding, com suporte para muitas linguagens em ambos os nıveis de sintaxe.
Em 2000, Alex Martelli cunhou o termo ”duck typing”para se referir ao mesmo
conceito, contudo com enfase em uma diferenca. Enquanto late binding e focado
em detalhes de implementacao, duck typing foca na habilidade de ignorar tipos e se
concentrar no objeto que os metodos possuem atualmente.
Late Binding
Em alguns programas, nao e possıvel conhecer que funcao sera chamada durante
o tempo de execucao(runtime). Isto e conhecido como late binding(ligacao tardia).
Em C++, uma maneira de implementar o late binding e usando ponteiro de funcoes.
Para melhor entendimento do exemplo, segue um breve resumo sobre ponteiro de
funcoes.
Um ponteiro de funcao, como o proprio nome sugere, e um ponteiro que aponta
para uma funcao ao inves de uma variavel. A funcao que um ponteiro de funcao
aponta pode ser chamada pelo uso do operador de chamada de funcao (()) sobre o
ponteiro. Segue exemplo na figura 2.4.
14
Figura 2.4: Exemplo de ponteiro de funcao. Fonte: Alex [4].
Chamando uma funcao via ponteiro e tambem conhecido como uma chamada
indireta. No exemplo da abaixo acontece o late binding.
#include <iostream>
using namespace std ;
int Add( int nX, int nY)
{
return nX + nY;
}
int Subtract ( int nX, int nY)
{
return nX − nY;
}
int Mult ip ly ( int nX, int nY)
{
return nX ∗ nY;
}
int main ( )
{
int nX;
cout << ”Enter a number : ” ;
15
c in >> nX;
int nY;
cout << ”Enter another number : ” ;
c in >> nY;
int nOperation ;
do
{
cout << ”Enter an opera t i on (0=add , 1=subtract , 2=mult ip ly ) : ” ;
c in >> nOperation ;
} while ( nOperation < 0 | | nOperation > 2) ;
// Create a func t i on po in t e r named pFcn ( yes , the syntax i s ug l y )
int (∗pFcn ) ( int , int ) ;
// Set pFcn to po in t to the func t i on the user chose
switch ( nOperation )
{
case 0 : pFcn = Add ; break ;
case 1 : pFcn = Subtract ; break ;
case 2 : pFcn = Mult ip ly ; break ;
}
// Ca l l the func t i on t ha t pFcn i s po in t i n g to wi th nX and nY as
parameters
cout << ”The answer i s : ” << pFcn (nX, nY) << endl ;
return 0 ;
}
Neste exemplo, ao inves de chamar as funcoes Add(), Subtract() ou Multiply()
diretamente, setamos pFcn para a funcao que queremos chamar. Entao chamaremos
a funcao desejada atraves do ponteiro. O compilador e incapaz de definir quem e
a funcao chamada em pFcn(nX, nY) pois a mesma so sera definida no tempo de
execucao.
16
Late binding e sensivelmente menos eficiente pois adiciona um nıvel extra de
indirecao. O seu funcionamento consiste na leitura do ponteiro e, so depois pular
para o endereco da funcao desejada. Isso envolve um ciclo extra, justificando essa
ineficiencia. Contudo, a vantagem do late binding e sua flexibilidade, pois as decisoes
a cerca da funcao chamada passam a ser introduzidas durante a execucao.
2.5 Explicit linkage
Refere-se ao processo de chamar uma funcao dentro de uma Dll/so e carrega-la
explicitamente durante o tempo de execucao. Isto siginifica dizer que quando a
aplicacao e buildada, nao existe biblioteca importada e a dll nao esta ligada durante
este processo. Nesse projeto a dll e carregada na memoria durante a execucao do
software utilizando a biblioteca sbVBLib, do professor Sergio Barbosa Villas-Boas.
Chamar uma dll dinamicamente requer um pouco mais de esforco e deve ser
liberada cuidadosamente para que nao resulte em erros. Em contrapartida, oferece
muito mais flexibilidade por nao haver a dependencia do software pela dll durante a
compilacao, e se o codigo da dll modifica futuramente, a mesma e alterada facilmente,
sem a necessidade de recompilacao do aplicativo.
As DLLs proveem os benefıcios comuns de bibliotecas compartilhadas, como a
modularidade. Esta modularidade permite que alteracoes sejam feitas no codigo
ou dados em uma DLL auto-contida, compartilhada por varios aplicativos, sem
que qualquer modificacao seja feita nos aplicativos em si. Essa forma basica de
modularidade permite a criacao de patches e service packs relativamente pequenos
para grandes aplicativos.
Outro benefıcio da modularidade e o uso de interfaces genericas para plug-ins.
Uma unica interface pode ser desenvolvida para permitir que modulos novos e antigos
possam ser integrados em aplicativos pre-existentes, sem qualquer modificacao no
proprio aplicativo.
Abaixo segue um exemplo de criacao de uma dll no Windows, seguido do codigo
para chamada com explicit link do mesmo.
17
#include <windows . h>
// Exporta e s t a func ao
extern ”C” d e c l s p e c ( d l l e xpo r t ) double SomaNumeros (double a , double b
) ;
// func ao de i n i c i a l i z a c a o da DLL
BOOL APIENTRY
DllMain (HANDLE hModule , DWORD dwReason , LPVOID lpReserved )
{
return TRUE;
}
// Funcao que soma do i s numeros
double SomaNumeros (double a , double b)
{
return a + b ;
}
#include <windows . h>
#inc lude <s t d i o . h>
// Assinatura da func ao da DLL
typedef double (∗ importFunction ) (double , double ) ;
int main ( int argc , char ∗∗ argv )
{
importFunction SomaNumeros ;
double r e su l t ado ;
// Carrega arqu ivo DLL
HINSTANCE hins tL ib = LoadLibrary ( ”Exemplo . d l l ” ) ;
i f ( h in s tL ib == NULL) {
p r i n t f ( ”ERRO: nao f o i p o s s ı v e l c a r r ega r a DLL\n” ) ;
return 1 ;
}
// Obtem o pon te i ro da func ao
18
SomaNumeros = ( importFunction ) GetProcAddress ( h instLib , ”
SomaNumeros” ) ;
i f (SomaNumeros == NULL) {
p r i n t f ( ”ERRO: nao f o i p o s s ı v e l achar a func ao na DLL\n”
) ;
FreeLibrary ( h in s tL ib ) ;
return 1 ;
}
// Chama func ao .
r e su l t ado = SomaNumeros (1 , 2) ;
// Descarrega arqu ivo DLL
FreeLibrary ( h in s tL ib ) ;
// Mostra o r e su l t a do
p r i n t f ( ”O re su l t ado e : %f \n” , r e su l t ado ) ;
return 0 ;
}
2.6 Concorrentes do Telecontents
Moodle: software livre, de apoio a aprendizagem, executado num ambiente vir-
tual. O programa e disponibilizado livremente e pode ser instalado em diversos
ambientes (Unix, Linux, Windows, Mac OS) desde que os mesmos consigam exe-
cutar a linguagem PHP. Muitas instituicoes de ensino (basico e superior) e centros
de formacao estao adaptando a plataforma aos proprios conteudos, com sucesso,
nao apenas para cursos totalmente virtuais, mas tambem como apoio aos cursos
presenciais.
ATutor: e um LCMS, ou Sistema de Gerenciamento de Conteudo de Aprendiza-
gem Baseado em Web, Open Source planejado com acessibilidade e adaptabilidade
em mente. Os administradores podem instalar ou atualizar o ATutor em minutos.
Os Educadores podem rapidamente montar, empacotar, redistribuir os conteudos
instalados e conduzir os seus cursos online. Os estudantes estudam num ambiente
19
de aprendizagem adaptativo.
Claroline: ferramenta de EAD e de trabalho colaborativo open source que permite
as instituicoes criar e administrar informacoes online.
Udemy: ferramenta de EAD que nos permite criar cursos na web com a possibili-
dade de adicionar apresentacoes, vıdeos e blogs. Os utilizadores podem inscrever-se
recebendo o material correspondente, permitindo participar de forma ativa e, inclu-
sive, divulgar o conteudo nas redes sociais. Possibilidade de emitir vıdeo ao vivo,
mostrando aos alunos e professor em tempo real dentro de um painel de comunicacao
muito intuitivo.
RCampus: sistema de gestao da educacao online e gratuito que aposta num am-
biente de aprendizagem colaborativa. Nele e possıvel fazer todos os trabalhos re-
lacionados com a escola, nomeadamente a construcao de sites pessoais e de grupo
e a implementacao de cursos, portfolios, comunidades academicas, etc. Ele fornece
como ferramentas a publicacao de trabalhos, foruns de discussao, vıdeos, imagens,
links, e avaliacao.
20
Capıtulo 3
Telecontents Generic Binary
Package Kernel
3.1 Introducao
O Telecontents e um sistema cliente/servidor de videoconferencia orientado para
o ensino a distancia. O sistema atual conta com as funcionalidades de streaming
de audio e vıdeo em tempo real, chat privado e publico, transferencia de arquivos
em formatos diversos, alem da lousa digital. A diferenca de um software de video-
conferencia original e que neste existe um usuario principal que comanda o canal, e
apenas ele tem vez do audio, podendo liberar a colaboracao para os demais.
O projeto Telecontents foi desenvolvido sob arquitetura de camadas, como ilustra
a figura abaixo:
Figura 3.1: Arquitetura do Telecontents.
21
As Bibliotecas base compoem um conjunto proprio de outras bibliotecas menores
responsaveis pelo gerenciamento da comunicacao entre o cliente e o servidor. Nesta
camada encontra-se a implementacao do IRM, versao modificada do protocolo IRC.
As bibliotecas que fazem toda a manipulacao de audio, vıdeo, alem do chat estao
nessa camada. Faz parte da mesma tambem estruturas de mais baixo nıvel, como
os sockets e threads.
O Kernel e a camada principal do sistema. Ele utiliza as bibliotecas da camada
inferior, implementando todas as funcionalidades do sistema. Ele foi implementado
no padrao de projetos Singleton.
A camada seguinte, denominada Telecontents client, e o lado cliente do sistema,
nele encontram-se as rotinas que interagem com o usuario, em resumo, e a aplicacao
propriamente dita.
A camada mais externa, chamada Skin, e responsavel pelo gerenciamento grafico
do sistema, sua funcao e tornar a interface mais amigavel ao usuario , como tam-
bem possuir diferentes rostos, personalizaveis, sem a necessidade de reinstalacoes do
sistema a cada nova interface criada.
3.2 Adicao do GBP Kernel
Para tornar possıvel a adicao de plugins comunicando-se com o servidor, indepen-
dente da interface final ao usuario, foi conveniente introduzir a camada GBP Kernel
entre o telecontents client e a Skin, como ilustra afigura abaixo:
Na introducao dessa nova camada, foram necessarios implementar modificacoes
no Kernel e no telecontents client. Foi aberto um canal para a passagem dos dados
entre cliente e servidor. E importante frisar que o GBP Kernel foi concebido com
a finalidade de fornecer uma plataforma de plugins totalmente flexıvel, portanto, o
mesmo nao faz tratamento dos pacotes, para ele apenas sao dados trafegados, onde
serao realmente tratados na implementacao do plugin, de acordo com a finalidade
de cada um.
22
Figura 3.2: Arquitetura do Telecontents atualizada.
No Kernel, foi criada uma classe denominada GenericBinaryPackage, nela encontram-
se os metodos de envio e recebimento dos pacotes.
O Telecontents client possui uma estrutura chamada GBPMessage, contendo os
campos do pacote de dados. Este pacote trafega dentro do pacote do protocolo IP.
Um pacote e enviado atraves do metodo abaixo:
GenericBinaryPackageSend - Envia um pacote atraves do parametro data, retor-
nando um booleano que indica se o sucesso do envio.
No receptor, o pacote chega atraves do evento OnGenericBinaryPackageChannel,
este nao possui retorno, tem como parametros o canal, usuario e o dado trafegado.
3.3 Datagrama
Figura 3.3: Pacote do GBP.
O pacote de dados do GBP segue inserido no datagrama IP, que possui tamanho
variavel, mas configurado nas placas no tamanho de 1500 bytes, por isso o pacote foi
23
calculado nesse mesmo tamanho maximo, caso a informacao ultrapasse o tamanho
de um pacote, tantos outros quanto necessarios serao criados. Abaixo cada campo
do pacote sera explicado:
• nPlugin id: Este campo indica em quantos bytes o plugin id esta representado.
• plugin id: A ideia e que exista um webservices que controle a quantidade de
plugins existentes, e cada um possuira um id proprio, esse numero inicialmente
sera do tipo unsigned int, ou seja, poderao existir plugins no range de 0 a
4294967295. Como pode-se notar, para representar diretamente esses valores
dentro do campo, seriam necessarios ate 10 bytes, e caso queira aumentar esse
tamanho no futuro para comportar mais plugins, todo o pacote sera alterado,
causando incompatibilidade entre as versoes, alem de diminuir o tamanho do
payload. Afim de sanar este problema, o id e representado sempre pelo seu
valor em bytes, ou seja, ocupando sempre 4 bytes apenas.
A classe ByteConversions foi concebida para fazer a conversao entre o valor
em inteiro e sua representacao em bytes. O ByteConversions possui os dois
metodos abaixo:
int ConvertIntegerToByte(int number, BYTE **byte), recebe o numero inteiro
e retorna os bytes correspondentes no parametro byte, o retorno desse metodo
e a quantidade de bytes representados.
for ( int j =0; j <4; j++)
{
b [ j ] = b [ j ] | i ;
i = i >> 8 ;
}
int ConvertByteToInteger(BYTE *byte, int byteLength), recebe os bytes cor-
respondentes e o comprimento do mesmo, retorna a representacao em int.
for ( int j= byteLength − 1 ; j>=0;j−−)
{
k = k | b [ j ] ;
i f ( j > 0)
k = k << 8 ;
24
}
• packet type, campo de 1 byte que define se o pacote recebido possui payload
(pacote contendo informacao) ou se e apenas um pacote de controle. Se for ’1’
ele abre o plugin do lado receptor, caso contrario trafega dados.
• payload, campo que trafega os dados em si.
Como percebido, o pacote nao possui campos para checagem de erros, isto deve-
se a intencao de prover ao plugin total flexibilidade, uma vez que ja ha o controle
padrao do protocolo TCP/IP, nesse caso, controles adicionais ficam a criterio da
necessidade de cada aplicacao.
3.4 Conversoes entre bytes e inteiros
Bit e a menor unidade de informacao que pode ser armazenada ou transmitida,
vem da uniao das palavras Binary digit. Quando unimos 8 bits, forma-se o byte.
Todos os demais tipos de representacao de informacoes derivam-se desses bytes,
como por exemplo strings, double, int, boolean, entre outros.
O tipo int e a representacao de numeros inteiros, variando seu range de acordo com
a linguagem utilizada, ou seja, a qantidade de bytes usados para sua representacao.
Na linguagem C++, utilizada nesse sistema, o int e definido em 32 bits, ou 4 bytes,
podendo ser do tipo signed ou unsigned.
Para representar o id do plugin, nao faz sentido a existencia de numeros negativos,
logo usamos o unsigned int. Como esse valor deve ser passado no pacote de dados e
queremos o mınimo de bytes gastos para liberar mais espaco para a informacao que
realmente importa, faz total sentido representa-lo em forma de bytes.
Na conversao de inteiro para bytes:
• Inicializacao de 4 bytes com valores zerados.
• b[0] = b[0] or i; Os 8 primeiros bits do inteiro i seguem para o byte b[0].
25
• O inteiro i e shiftado retirando os 8 bits utilizados.
• b[1] = b[1] or i; Os 8 primeiros bits do inteiro i seguem para o byte b[1].
• O inteiro i e shiftado retirando os 8 bits utilizados.
• b[2] = b[2] or i; Os 8 primeiros bits do inteiro i seguem para o byte b[2].
• O inteiro i e shiftado retirando os 8 bits utilizados.
• b[3] = b[3] or i; Os 8 primeiros bits do inteiro i seguem para o byte b[3].
• O inteiro i e shiftado retirando os 8 bits utilizados.
Na conversao de bytes para inteiro:
• Inicializacao do inteiro i com o valor zerado.
• b[3] = b[3] or i; O byte b[3] segue para o inteiro i.
• O inteiro i e shiftado a esquerda deslocando os 8 bits.
• b[2] = b[2] or i; O byte b[2] segue para os primeiro byte do inteiro i.
• O inteiro i e shiftado a esquerda deslocando os 8 bits.
• b[1] = b[1] or i; O byte b[1] segue para os primeiro byte do inteiro i.
• O inteiro i e shiftado a esquerda deslocando os 8 bits.
• b[0] = b[0] or i; O byte b[0] segue para os primeiro byte do inteiro i.
3.5 Gerenciamento do envio e recebimento de in-
formacoes
Data Parser
O DataParser e mais uma classe que tem a responsabilidade de tratar os pacotes.
Ela possui os seguintes metodos:
26
int CreateData(int pluginId, char packetType, const char *payload, char **data);
Este metodo recebe o plugin id, o packet type, e o payload. Sua funcao e gerar
atraves da classe ByteConversions o nPluginId e a representacao em bytes do plugin
id. O pacote montado e repassado atraves do parametro data. O retorno do metodo
e o tamanho do pacote gerado, em caso de erro na geracao do pacote o metodo
retorna 0. Esta mesma funcao e capaz de gerar o pacote de inicializacao.
void ParseData(const char *data); Este metodo e o oposto do anterior. Sua
funcao e receber o pacote passado no parametro data e destrincha-lo, mais uma vez
com o auxılio do ByteConversions, separando o pacote em plugin id, packetType e
payload. Este metodo nao possui retorno por se tratar de um metodo void. A seguir
os getters.
int GetPluginId(); Retorna o valor do plugin id ja no formato inteiro.
char GetPacketType(); Retorna o valor do packet type. Se for ’1’ trata-se de um
pacote de inicializacao.
const char *GetPayload(); Retorna o payload do pacote. Esse metodo so possui
sentido se packetType for diferente de ’1’.
GBPKernel
Esta e a classe principal do telecontents gbp kernel, todo plugin e uma classe
derivada desta. Ela e derivada de wxFrame, logo, encontra-se preparada para ser
GUI atraves da wxWidgets.
Abaixo seguem os atributos acessıveis para o plugin:
• m appInterface. Atributo do tipo AppInterface. Esta classe AppInterface
contem todas as informacoes referentes ao sistema, como o canal conectado,
nome de usuario logado, lista de usuarios presentes no canal, lista de canais,
entre outros. Esta interface estara presente para consulta no apendice.
27
• m isTx. Atributo do tipo booleano que indica se o modulo esta setado para
ser um transmissor ou receptor. Todo plugin pode ser transmissor e recep-
tor ao mesmo tempo, nesse caso m isTx e irrelevante, porem podem existir
aplicacoes onde o transmissor possui uma interface diferente do receptor, daı
veio a importancia da criacao do mesmo. O modulo e um transmissor quando
este atributo e verdadeiro e receptor quando falso.
A seguir seguem os metodos presentes no GBPKernel:
• virtual void SetAppInterface(AppInterface *iface); Setter do atributo m appInterface.
O objeto appInterface e passado atraves do parametro iface.
• virtual void SetTx(); Seta o modulo como transmissor.
• virtual void SetRx(); Seta o modulo como receptor.
• virtual void SendInitData(int pluginId); Este metodo gera o pacote de inici-
alizacao com o pluginId utilizando o DataParser e o envia para o respectivo
receptor do plugin.
• virtual void SendData(int pluginId, char *data); Este metodo gera o pacote
de dados com o DataParser e o envia para seu respectivo destinatario. O
parametro pluginId e o id do plugin responsavel pelo pacote, o dado a ser
enviado e passado atraves do parametro data.
A seguir seguem os metodos puramente virtuais presentes no GBPKernel:
• virtual void Open(); Metodo responsavel por dar os comandos iniciais apos o
recebimento do pacote de inicializacao.
• virtual int GetPluginId(); Metodo responsavel por retornar o id do plugin.
• virtual wxString GetPluginName(); Cada plugin pode receber um nome, este
metodo e reponsavel por retorna-lo no formato wxString.
28
Capıtulo 4
Criacao do plugin
4.1 Introducao
Neste presente capıtulo sera mostrado como fazer a criacao de um novo plugin
atraves do GBPKernel. Para fim de exemplo sera criado o plugin dbgGBP, e assim
teremos o passo a passo para criacao de diferentes aplicacoes.
O dbgGBP foi concebido com o intuito de ser demasiadamente simples, na ten-
tativa de ser o mais didatico possıvel. Ele apenas possui um transmissor que envia
uma cadeia de caracteres e um receptor que apenas a exibe.
O funcionamento basico deste modulo consiste no envio de uma quantidade ”X”de
caracteres em serie, e o receptor entao apenas exibira os caracteres que chegam.
4.2 Como e o transmissor?
O transmissor e uma interface GUI desenvolvida com base na biblioteca wsWid-
gets, ela contem um wxSpinCtrl, um botao e uma caixa de texto multiline.
O wxSpinCtrl e um controle que combina uma caixa de texto com um botao,
onde o usuario pode definir um valor numerico diretamente pela caixa de texto ou
atraves do botao. Sua funcao no plugin e definir a quantidade de caracteres a serem
enviados.
29
O botao possui a funcao de iniciar ou finalizar uma transmissao. Ele possui
dois estados distintos. Quando nao ha transmissao, o botao encontra-se no estado
generate, com a funcao de iniciar um novo envio de dados. Quando existe um
transmissao em andamento, o botao encontra-se no estado stop, possuindo a funcao
de finalizar o envio de pacotes.
A caixa de texto multiline, uma vez que a tranmissao comecou, vai informando
ao usuario qual dado esta sendo transmitido.
Figura 4.1: Transmissor do modulo dbgGBP.
Abaixo esta o codigo que implementa a criacao da interface do transmissor:
void DbgGBP : : CreateTransmitter ( )
{
Se tT i t l e (SYMBOL GENERICBINARYBUSSENDFRAME TITLE) ;
m mainVertSizer = new wxBoxSizer (wxVERTICAL) ;
this−>Se tS i z e r ( m mainVertSizer ) ;
m mainPanel = new wxPanel ( this , ID GENBINBUS SND FRM MAINPANEL,
wxDefaultPos it ion , wxDefaultSize , wxSUNKENBORDER|
wxTAB TRAVERSAL ) ;
30
m mainVertSizer−>Add(m mainPanel , 1 , wxGROW, 5) ;
m mainPanelVertSizer = new wxBoxSizer (wxVERTICAL) ;
m mainPanel−>Se tS i z e r ( m mainPanelVertSizer ) ;
m userF ie ldHorS izer = new wxBoxSizer (wxHORIZONTAL) ;
m mainPanelVertSizer−>Add( m userFie ldHorSizer , 0 ,
wxALIGN CENTER HORIZONTAL |wxALL, 5) ;
m lblQuest ion = new wxStaticText ( m mainPanel , wxID STATIC , ( ”
Choose a number : ” ) , wxDefaultPos it ion , wxDefaultSize , 0 ) ;
m userFie ldHorSizer−>Add( m lblQuest ion , 0 , wxALIGN CENTER VERTICAL |
wxALL, 5) ;
m spinCtrlNumber = new wxSpinCtrl ( m mainPanel ,
ID GENBINBUS SND FRM SPINCTRL NUM, T( ”0” ) , wxDefaultPos it ion ,
wxDefaultSize , wxSP ARROWKEYS, 0 , 1000000000 , 0 ) ;
m userFie ldHorSizer−>Add(m spinCtrlNumber , 0 ,
wxALIGN CENTER VERTICAL |wxALL, 5) ;
m btnGenerate = new wxButton ( m mainPanel ,
ID GENBINBUS SND FRM BTN GENERATE, ( ”Generate ” ) ,
wxDefaultPos it ion , wxDefaultSize , 0 ) ;
m btnGenerate−>Connect (wxEVTCOMMANDBUTTONCLICKED,
wxCommandEventHandler (DbgGBP : : OnBtnGenerateClick ) ,0 , this ) ;
m mainPanelVertSizer−>Add(m btnGenerate , 0 ,
wxALIGN CENTER HORIZONTAL |wxALL, 5) ;
m txtDebug = new wxTextCtrl ( m mainPanel ,
ID GENBINBUS SND FRM TXT DEBUG, wxEmptyString ,
wxDefaultPos it ion , wxDefaultSize , wxTE MULTILINE |
wxTEREADONLY ) ;
m mainPanelVertSizer−>Add(m txtDebug , 1 , wxGROW|wxALL, 5) ;
}
O metodo CreateTransmitter na primeira linha define o nome da janela atraves do
comando SetTitle(SYMBOL GENERICBINARYBUSSENDFRAME TITLE), onde
SYMBOL GENERICBINARYBUSSENDFRAME TITLE e uma constante presente
31
no arquivo ”DbgGBPConstants.h”.
Nas linhas seguintes do metodo sao definidos os controles anteriormente cita-
dos. O wxSpinCtrl atende pelo nome de m spinCtrlNumber, o botao e denominado
m btnGenerate, e a caixa de texto multiline m txtDebug.
O comando m btnGenerate->Connect(wxEVT COMMAND BUTTON CLICKED,
wxCommandEventHandler(DbgGBP::OnBtnGenerateClick),0,this) gera o evento que
sera acionado no clique do botao, sendo OnBtnGenerateClick o metodo que imple-
mentara a acao do botao.
void DbgGBP : : OnBtnGenerateClick ( wxCommandEvent& event )
{
i f ( ! this−>m generat ingPackets ) // beg in send o f packe t s
{
wxString qs = m lblQuest ion−>GetLabel ( ) ;
int f i n a lPacke t = m spinCtrlNumber−>GetValue ( ) ;
m thread = new Worker ( this , m appInter face , f i n a lPacke t
) ;
m thread−>Run( ) ;
}
else // s top send o f packe t s
{
m thread−>Stop ( ) ;
ToggleBtnGenerateState ( fa l se ) ;
}
////@end wxEVT COMMAND BUTTON CLICKED event hand ler f o r
ID GENBINBUS SND FRM BTN GENERATE in GenericBinaryBusSendFrame .
}
O metodo acima funciona em dois estados. Caso o sistema esteja ocioso, inicia
uma thread para fazer o envio dos pacotes, agora se existem pacotes sendo enviados,
para o processo.
32
4.3 Como e o receptor?
O receptor e uma interface GUI desenvolvida com base na biblioteca wxWidgets,
ela contem apenas uma caixa de texto multiline.
A caixa de texto multiline, uma vez que a tranmissao comecou, vai informando
ao usuario qual dado esta sendo recebido.
Figura 4.2: Receptor do modulo dbgGBP.
Abaixo esta o codigo que implementa a criacao da interface do receptor:
void DbgGBP : : CreateReceptor ( )
{
Se tT i t l e (SYMBOL GENERICBINARYBUSRECEIVEFRAME TITLE) ;
m mainVertSizer = new wxBoxSizer (wxVERTICAL) ;
this−>Se tS i z e r ( m mainVertSizer ) ;
m mainPanel = new wxPanel ( this , ID GENBINBUSRRCVFRMMAINPANEL,
wxDefaultPos it ion , wxDefaultSize , wxSUNKENBORDER|
wxTAB TRAVERSAL ) ;
m mainVertSizer−>Add(m mainPanel , 1 , wxGROW, 5) ;
33
m mainPanelVertSizer = new wxBoxSizer (wxVERTICAL) ;
m mainPanel−>Se tS i z e r ( m mainPanelVertSizer ) ;
m txtDbgMessage = new wxTextCtrl ( this ,
ID GENBINBUSRRCVFRMTXT DEBUG, wxEmptyString , wxDefaultPos it ion
, wxDefaultSize , wxTE MULTILINE |wxTEREADONLY ) ;
m mainPanelVertSizer−>Add(m txtDbgMessage , 1 , wxGROW|wxALL, 5) ;
}
Ometodo CreateReceptor na primeira linha define o nome da janela atraves do co-
mando SetTitle(SYMBOL GENERICBINARYBUSRECEIVEFRAME TITLE), onde
SYMBOL GENERICBINARYBUSRECEIVEFRAME TITLE e uma constante pre-
sente no arquivo ”DbgGBPConstants.h”.
Nas linhas seguintes do metodo sao definidas as localizacoes do controle na tela.
Na ultima linha e criada a caixa de texto multiline, que foi denominada m txtDbgMessage.
4.4 Integracao do plugin
Na presente secao, sera mostrado um passo a passo para executar a integracao do
modulo receptor/transmissor com o GBPKernel. Este tutorial se dara exemplificado
pelo dbgGBP.
O primeiro passo e criar uma classe no plugin que herda de GBPKernel.
No arquivo include da classe(.h), deve-se incluir o GBPKernel atraves da linha
mostrada na figura figura 4.3.
O proximo passo e fazer com que a classe do plugin seja derivada de GBPKernel,
isso e feito atraves da insercao como aparece na figura 4.4.
Ainda no include os metodos virtuais da classe base presentes na figura 4.5 deverao
ser definidos.
34
Figura 4.3: Comando include do GBPKernel.
Figura 4.4: Classe derivada de GBPKernel.
No arquivo source da classe(.cpp), os metodos da classe base mostrados acima
deverao ser implementados. No dbgGBP, eles foram implementados, como mostra
abaixo:
O metodo Open e chamado toda vez que o cliente recebe uma notificacao infor-
mando que pacotes de inicializacao estao sendo enviados. No dbgGBP abre a janela
GUI de recepcao e limpa a caixa de texto de debug.
O metodo GetPluginId e chamado atraves da classe base para informar o id do
modulo. No dbgGBP esse valor e retornado atraves do atributo m index, que foi
definido hardcoded pela constante DBGGBP PLUGIN ID.
O metodo GetPluginName e chamado atraves da classe base para informar o nome
do modulo. No dbgGBP esse valor e retornado atraves da constante DBGGBP PLUGIN NAME.
Este metodo e usado, por exemplo, para identificar o plugin que sera escolhido na
tela aberta ao clicar no botao de selecao de funcionalidades.
O metodo ReceiveData e responsavel por entregar os pacotes de dados ao plugin.
No dbgGBP os dados recebidos sao tratados pelo metodo WriteTextMsg.
35
Figura 4.5: Definindo os metodos derivados de GBPKernel na classe dbgGBP.
Figura 4.6: Implementacao do metodo Open.
4.5 Metodos do receptor
A seguir serao definidos os metodos internos que viabilizam o funcionamento do
receptor.
• void WriteTextMsg(const wxString &data); Este e chamado pelo ReceiveData
toda vez que um novo pacote e recebido, tendo a funcao de apresentar o dado
presente no atributo data na caixa de texto multiline.
• void ClearDbg(); E chamado pelo open, tendo a funcao de limpar a caixa de
texto multiline para que uma nova recepcao seja apresentada.
4.6 Metodos do transmissor
A seguir serao definidos os metodos internos que viabilizam o funcionamento do
transmissor.
• void EnableBtnGenerate(const bool &enable); Sua funcao e habilitar/desabi-
litar o botao Generate de acordo com o valor presente no atributo enable.
36
Figura 4.7: Implementacao do metodo GetPluginId.
Figura 4.8: Implementacao do metodo GetPluginName.
• void ToggleBtnGenerateState(bool generatingPackets); Atraves do atributo
generatingPackets, o metodo altera o estado do botao.
• void DebugAppendText(const wxString &msg); Este metodo apresenta na
caixa de texto multiline o valor passado pelo atributo msg. Possui bastante
utlilidade na visualizacao do dado que esta sendo enviado.
4.7 Worker Thread
O envio de dados e efetuado numa thread separada, pois em caso contrario o apli-
cativo ficaria suspenso ate o fim da transmissao, impossibilitando o funcionamento
do estado stop do botao, por exemplo. Na figura 4.10 segue o metodo responsavel
pelo funcionamento da thread.
A thread consiste em enviar um pacote de inicializacao, informando que uma nova
transmissao vai comecar. O proximo passo e realizar um loop enviando atraves do
metodo SendData o caracter correspondente ao valor do incremento no loop.
37
Figura 4.9: Implementacao do metodo ReceiveData.
Figura 4.10: Funcionamento do Worker Thread.
O valor final do loop, m finalPacket corresponde ao valor do wxSpinControl.
Caso o usuario pare uma transmissao em progresso, o valor de m stopped e alte-
rado, finalizando prematuramente o loop.
Ao final da transmissao, o estado do botao e alterado pelo metodo ToggleBtnGe-
nerateState.
38
Capıtulo 5
Testes
5.1 Introducao
Apos a implementacao do barramento generico de dados e o passo a passo para
a criacao de plugins, tomando como base o dbgGBP, nos dois capıtulos anteriores,
faremos testes do barramento generico de dados.
Os testes se dividirao em tres fases:
O primeiro objetivo e garantir que o sistema se comporta de fato como plugin;
O segundo objetivo e para com provar que a transmissao de dados esta em funci-
onamento;
Por fim os dados trafegados serao analisados, com a finalidade de comprovar o
grau de confiabilidade do sistema.
5.2 Teste de plugin
Nesta secao o objetivo e comprovar que o barramento generico de dados esta de
fato se comportado como um sistema de plugins. A realizacao dele consiste em fazer
a instalacao/desinstalacao manual do modulo. Essa tarefa sera demonstrada atraves
de figuras. A condicao de plugin sugere que o modulo seja instalado e desinstalado
durante a execucao do telecontents.
39
No lado transmisssor, as etapas do teste serao demonstradas atraves de figuras.
No primeiro passo o plugin esta desinstalado, como ilustra a figura 5.1.
Figura 5.1: Modulo dbgGBP desinstalado.
Visto que o plugin esta desinstalado, ao tentar acessa-lo, ocorre a mensagem da
figura 5.2.
Figura 5.2: Mensagem de inexistencia de modulos.
40
Nessa proxima fase o plugin sera instalado, como ilustra a figura 5.3.
Figura 5.3: Modulo dbgGBP instalado.
Uma vez que o plugin foi instalado temos a tela da figura 5.4, indicando a escolha
de modulos, por enquanto a unica opcao e o nosso modulo debuger dbgGBP.
Figura 5.4: Tela de selecao de modulos.
No lado receptor o procedimento e analogo, porem nao cabe demonstra-lo atraves
de imagens, uma vez que, se o modulo nao esta instalado o telecontents ignora os
41
dados recebidos pelo barramento generico de dados, quando o modulo existe no
sistema fica a criterio de cada plugin mostrar esses dados, por exemplo, no dbgGBP
apenas abre uma janela e o dado e mostrado como foi enviado, mas pode existir
uma aplicacao que so exibira a tela se o sinal recebido for um codigo.
5.3 Teste de funcionamento
Uma vez provado que o baramento generico de dados comporta-se como uma
plataforma de modulos, prosseguimos com o teste que comprovara o trafego de
dados.
Esta etapa e bastante simples, consiste apenas em abrir o tranmissor e enviar um
pulso, assim o receptor deve reagir mostrando esse dado na tela.
A figura 5.5 ilustra o transmissor enviando um dado.
Figura 5.5: Envio de um sinal pelo transmissor do modulo dbgGBP.
42
5.4 Teste de informacao
Para garantir a confiabilidade das informacoes trafegadas pelo Generic Binary
Package, o sistema deve garantir que a entrega dos dados ocorra com dois requisitos:
Os dados devem ser entregues sem erros;
Os dados devem ser entregues na mesma ordem que foram enviados.
O teste de informacao se dara no trafego de 3 informacoes, sendo elas com 10, 100
e 1000 caracteres, que serao posteriormente analisados afim de garantir a confiabi-
lidade do sistema.
A analise dos dados dar-se-a pela comparacao entre os caracteres enviados e os
caracteres recebidos atraves de um editor de texto.
Teste com 10 caracteres:
Figura 5.6: Transmissor - 10 caracteres.
43
Figura 5.7: Receptor - 10 caracteres.
Figura 5.8: Resultado - 10 caracteres.
44
Teste com 100 caracteres:
Figura 5.9: Transmissor - 100 caracteres.
Figura 5.10: Receptor - 100 caracteres.
45
Figura 5.11: Resultado - 100 caracteres.
Teste com 1000 caracteres:
Figura 5.12: Transmissor - 1000 caracteres.
46
Figura 5.13: Receptor - 1000 caracteres.
Figura 5.14: Resultado - 1000 caracteres.
47
5.5 Resultados obtidos
Atraves dos testes realizados com o envio de 10, 100 e 1000 bytes, o sistema nao
apresentou erro na recepcao. Entretanto, um delay na ordem de grandeza de 50ms
pode ser notado na transferencia dos dados, tal delay ocorreu no reenvio de bits
com erros. O mesmo pode ou nao ser relevante para o processo de acordo com a
funcionalidade realizada.
Todos os testes foram realizados num sistema fechado, com utilizacao de ambiente
virtualizado.
48
Capıtulo 6
Consideracoes finais
6.1 Conclusao
O objetivo desse projeto constituiu a construcao de uma interface para dinamizar
a criacao de novas funionalidades (plugin) ao sistema de videoconferencia.
Toda a gestao do projeto baseou-se na metodologia agil, usando como ferramenta
o modelo Scrum. Na parte de modelagem foram incorporadas tecnicas de design
patterns, viabilizando a manutenibilidade e escalabilidade no sistema.
Os testes demonstraram que o barramento mostrou-se confiavel do ponto de vista
da entrega da informacao, em contrapartida, um atraso na recepcao da informacao
pode ser notado.
O sistema e dito multiplataforma no sentido de utilizar apenas bibliotecas mul-
tiplataforma. O sistema foi testado apenas em ambiente Windows, pois o projeto
original nao foi testado no sistema operacional Mac OS. O sistema nao pode ser
testado no Linux porque bugs nao inerentes ao escopo desse projeto impediram o
funcionamento do sistema como um todo.
6.2 Trabalhos futuros
A expansao do sistema de videocoferencia consistira na resolucao de bugs em
ambiente Linux e inıcio de testes de funcionamento em ambiente Mac OS.
49
Hoje o mundo digital encontra-se nas plataformas moveis, logo o sistema de vide-
oconferencia deve ser expandido para os smartphones, pelo menos nas tecnologias
Android e iOS.
Para viabilizar a criacao de novas funcionalidades atraves da API aqui desenvol-
vida, e estritamente necessario o desenvolvimento de um webservices na cloud para
o gerenciamento de novos plugins. O webservices devera possuir como funcao prin-
cipal a publicacao das rotinas desenvolvidas por qualquer desenvolvedor apto ao uso
da API.
50
Referencias Bibliograficas
[1] ECLIPSE, “Processo Scrum”, http://epf.eclipse.org/wikis/scrumpt/Scrum/guidances
/supportingmaterials/scrum overview 610E45C2.html, 2005, (Acesso em 21
Janeiro 2012).
[2] CoDIGO, L. D., “Design Patterns”, http://www.linhadecodigo.com.br/artigo/345/introducao-
a-design-patterns.aspx, 2010, (Acesso em 21 Janeiro 2012).
[3] MACORATTI, J. C., “Diagrama de Late Bind”,
http://www.macoratti.net/vbbind.htm, 2008, (Acesso em 23 Janeiro 2012).
[4] ALEX, “Late Bind”, http://www.learncpp.com/cpp-tutorial/124-early-binding-
and-late-binding/, 2008, (Acesso em 23 Janeiro 2012).
[5] ACM, C. O., “Communications of ACM”, http://cacm.acm.org/, 2008, (Acesso
em 23 Janeiro 2012).
51
