reuniões electrónicas com pda - Informática

Transcrição

REUNIÕES ELECTRÓNICAS COM PDA
Licínio Gabriel dos Santos Furtado Pereira
Dissertação submetida para obtenção do grau de
MESTRE EM INFORMÁTICA
Orientador:
Professor Doutor Pedro Alexandre de Mourão Antunes
Júri:
Professor Doutor Luís Manuel Pinto da Rocha Afonso Carriço
Professora Doutora Ana Paula Pereira Afonso
Professor Doutor Manuel João Caneiro Monteiro da Fonseca
Professora Doutora Ana Paula Boler Cláudio
Janeiro de 2005
REUNIÕES ELECTRÓNICAS COM PDA
Licínio Gabriel dos Santos Furtado Pereira
Dissertação submetida para obtenção do grau de
MESTRE EM INFORMÁTICA
pela
Faculdade de Ciências da Universidade de Lisboa
Departamento de Informática
Orientador:
Professor Doutor Pedro Alexandre de Mourão Antunes
Júri:
Professor Doutor Luís Manuel Pinto da Rocha Afonso Carriço
Professora Doutora Ana Paula Pereira Afonso
Professor Doutor Manuel João Caneiro Monteiro da Fonseca
Professora Doutora Ana Paula Boler Cláudio
Janeiro de 2005
ii
Resumo
Nesta dissertação é estudado o suporte computacional em reuniões electrónicas com
Assistentes Pessoais (PDA). Uma questão central em análise foi a integração de PDA’s
numa arquitectura cooperativa de um único ecrã tendo como contexto de fundo as
reuniões electrónicas. E objectivo principal a ligação de PDA como dispositivos de
entrada.
A realização deste tipo de sistemas é complexa e apresenta diversos problemas. Foi
efectuada uma síntese geral sobre a área de investigação em que se insere o trabalho, com
particular ênfase na descrição do paradigma de aplicações cooperativas de um único ecrã
(SDG), sendo ainda apresentados problemas e soluções que influenciaram a sua evolução.
Em seguida, procedeu-se a um levantamento dos estudos empíricos sobre a utilização de
múltiplos dispositivos de entrada em sistemas de groupware. Também foi realizada uma
análise comparativa da ferramenta proposta com outras ferramentas similares.
No seguimento do trabalho, foram identificados os requisitos do protótipo, focando em
particular nos serviços a fornecer aos utilizadores.
Finalmente descreve-se a realização e avaliação preliminar do protótipo realizado.
PALAVRAS-CHAVE: Assistentes Pessoais (PDA), Sistemas de Apoio a Reuniões
Electrónicas (EMS), Sistemas de Apoio a Grupos (GSS), Sistemas de Apoio ao Trabalho
Cooperativo (CSCW), Aplicações Cooperativas com um Único Ecrã (SDG).
iii
Abstract
In this dissertation we study the computacional support to electronic meetings. A central
issue in analysis is the PDA integration in single display groupware arquitectures, in the
context of electronic meetings.
The development of this type of system is complex and not without some problems. We
overview the research area in which this work is inserted, with a particular emphasis on
the single display groupware (SDG) paradigm, while presenting problems and solutions
which influenced its evolution.
The discussion is followed by a survey of empirical studies on the use of multiple input
devices in groupware systems. Also compare the proposed tool with similar tools.
Then we specify the user requirements for the proposed tool.
Finally, we describe the implementation and preliminary evaluation of the proposed
prototype.
KEY-WORDS:
Personal Digital Assistant (PDA), Electronic Meeting Systems
(EMS), Group Support Systems (GSS), Computer Support Cooperative Work (CSCW),
Single Display Groupware (SDG).
iv
As reuniões podem ser uma das ferramentas mais produtivas … para estimular ideias, fomentar o sentido do
espírito de grupo, gerar planos de acção, proporcionar orientações valiosas, e, consequentemente, melhorar
a produtividade. Muitas vezes, contudo, constituem uma completa perda de tempo e energia.
MULLER & PINCUS (1997: vi).
v
Agradecimentos
A apenas algumas horas de concluir a presente dissertação, apraz-me relembrar algumas
pessoas que, de uma forma ou de outra, contribuíram para a conclusão deste mestrado.
Em primeiro lugar agradeço ao meu orientador, Professor Doutor Pedro Antunes pelo
apoio, motivação e pelas suas sugestões e criticas que contribuiram para melhorar este
trabalho.
A minha mãe e irmã que, uma vez mais, me deram, sem hesitar, toda a força para seguir
em frente.
A Dora Luisa, amiga e esposa, cujo apoio e confiança constantes foram inexcedíveis.
Os meus agradecimentos também a todos os colegas e amigos que aceitaram o desafio de
participar nas minhas experiências.
vi
Indice
Resumo ....................................................................................................................... ii
Abstract ..................................................................................................................... iii
Agradecimentos.......................................................................................................... vi
Indice......................................................................................................................... vii
Lista de Figuras ......................................................................................................... x
Listas de Tabelas...................................................................................................... xiv
Lista de Acrónimos ................................................................................................... xv
1. INTRODUÇÃO..................................................................................................... 1
1.1. Contexto ...........................................................................................................1
1.1.1. Reuniões Electrónicas ...........................................................................1
1.1.2. Sistemas Cooperativos de Suporte a Reuniões Electrónicas ................ 5
vii
1.1.3. Aplicações Cooperativas com um único ecrã......................................10
1.1.4. Toolkit Pebbles ....................................................................................14
1.2. Objectivos.......................................................................................................17
1.3. Estrutura da dissertação..................................................................................18
2.
PANORÂMICA ........................................................................................................................... 19
2.1. Introdução.......................................................................................................19
2.2. Arquitectura de SDG ......................................................................................19
2.3. Problemas com a Arquitectura SDG ..............................................................21
2.4. Integração de SDG e PDA..............................................................................22
2.5. Análise Comparativa ......................................................................................34
2.6. Ferramenta Proposta.......................................................................................37
2.7. Conclusões..................................................................................................... 41
3. REQUISITOS ..................................................................................................... 42
3.1. Introdução...................................................................................................... 42
3.2. Funcionalidades e Restrições ........................................................................ 42
3.2.1. Requisitos Genéricos .......................................................................... 42
3.2.2. Requisitos Técnicos ............................................................................ 43
3.3. Arquitectura Tecnológica do Sistema ........................................................... 46
3.4. Estrutura de Dados ........................................................................................ 47
viii
3.5. Casos de utilização ........................................................................................ 50
3.5.1. Caso de utilização “registar utilizador” .............................................. 53
3.5.2. Caso de utilização “Gerir Itens” ......................................................... 54
3.5.2.1.Caso de utilização “Visualizar / Organizar itens” ........................ 56
3.5.2.1.1. Caso de utilização “manter item” ..................................... 57
3.5.2.1.1.1.Caso de utilização “Criar item” .................................. 58
3.5.2.1.1.2.Caso de utilização “Alterar item” ............................... 59
3.5.2.1.1.3.Caso de utilização “Remover item”............................ 59
3.5.2.1.2. Caso de utilização “Subir nível”....................................... 60
3.5.2.1.3. Caso de utilização “Descer nível” .................................... 61
3.5.2.1.4. Caso de utilização “Mover item”...................................... 62
3.5.2.1.5. Caso de utilização “Copiar group item” ........................... 63
3.5.2.2.Caso de utilização “Prioritizar item” ............................................ 64
3.5.2.3.Caso de utilização “Votar item” ................................................... 65
3.5.3. Caso de utilização “Gerir reunião” ......................................................66
3.5.3.1.Caso de utilização “criar reunião” ............................................... 67
3.5.3.2.Caso de utilização “Abrir reunião”............................................... 68
3.5.3.3.Caso de utilização “remover reunião” .......................................... 69
3.5.3.4.Caso de utilização “gravar reunião” ............................................. 70
3.5.4. Caso de utilização “Gerir agenda”...................................................... 71
ix
3.5.5. Caso de utilização “Visualizar item local” ......................................... 72
3.5.5.1.Caso de utilização “Manter item local” ........................................ 73
3.5.5.1.1. Caso de utilização “Adicionar item” ................................ 74
3.5.5.1.2. Caso de utilização “remover item” ................................... 75
3.5.5.1.3. Caso de utilização “expandir item” .................................. 76
3.5.5.2.Caso de utilização “publicar item” ............................................... 77
3.6. Arquitectura lógica do sistema ...................................................................... 78
3.7. Conclusões..................................................................................................... 80
4. REALIZAÇÃO ................................................................................................... 81
4.1. Introdução...................................................................................................... 81
4.2. Ambiente de desenvolvimento ...................................................................... 81
4.2.1. Ferramentas de desenvolvimento e teste ............................................ 81
4.2.1.1.Superwaba .................................................................................... 82
4.2.1.2.Palm OS Emulator 3.5 .................................................................. 82
4.2.1.3.Simulator Palm OS5 ..................................................................... 83
4.2.1.4.JDK 1.4.1 ...................................................................................... 83
4.2.1.5.Tauschke MobileCreator Personal 1.7.......................................... 84
4.2.1.6.Microsoft Access 2002 ................................................................. 84
4.2.2. Problemas Relacionados com o Anbiente de Desenvolvimento .........85
4.3. Metodologia de Desenvolvimento..................................................................86
x
4.4. Arquitecura Fisica do Sistema LightMeet......................................................86
4.5. Arquitectura Lógica....................................................................................... 88
4.5.1. Componentes do sistema .................................................................... 89
4.5.1.1. Comunicação ............................................................................... 90
4.5.1.2. Cliente do PDA............................................................................ 96
4.5.1.3. Servidor ...................................................................................... 99
4.5.1.4. Diagrama de instalação..............................................................104
4.6. Funcionamento do sistema ........................................................................ 106
4.6.1. Funcionamento do Cliente................................................................ 107
4.6.1.1.Interface Agenda......................................................................... 107
4.6.1.2.Interface Dynamic Cursor........................................................... 109
4.6.1.3.Interface Meetings ...................................................................... 111
4.6.1.4.Interface Private Space ............................................................... 113
4.6.2. Funcionamento do Servidor.............................................................. 114
4.7. Conclusões .................................................................................................. 118
5. AVALIAÇÃO PRELIMINAR ........................................................................ 119
5.1. Introdução.................................................................................................... 119
5.2. Resultados.................................................................................................... 125
5.3. Discussão de Resultados.............................................................................. 132
5.4. Conclusão .................................................................................................... 134
xi
6. CONSIDERAÇÕES FINAIS........................................................................... 135
6.1. Conclusão .................................................................................................... 135
6.2. Trabalho Futuro ........................................................................................... 138
7. APÊNDICE ....................................................................................................... 139
7.1. Questionários............................................................................................... 139
7.2. Respostas ao 1º questionário ....................................................................... 140
8. REFERÊNCIAS................................................................................................ 144
xii
Lista de Figuras
1.1
Duas pessoas a trabalharem num ambiente SDG, ambas com um dispositivo
de entrada (Rato).................................................................................... 11
1.2
Esquema geral da Arquitectura do Toolkit Pebbles, com algumas aplicações
clientes e o respectivo Plug-in (servidor). .............................................. 14
2.1
Esquema genérico de uma arquitectura SDG .......................................... 20
2.2
O M-Pad .................................................................................................. 22
2.3
Numa situação de uso do M-Draw: Quadro digital que interage com vários
dispositivos .............................................................................................. 23
2.4
Operação “Pick & Drop”. .........................................................................24
2.5
Remote Commander, (a) Emulação do rato e (b) Emulação do teclado . 25
2.6
A interface do utilizador com (a) área de foco activa; (b) área de atributos das
notas activa .............................................................................................. 26
2.7
A visualização de notas no “Note Browser”............................................ 27
2.8
Informação pública e pessoal................................................................... 28
2.9
Espaço público (Ecrã Partilhado) ............................................................ 28
2.10
Duas salas ligadas através do sistema Hello.Wall ................................... 29
2.11
Os dois artefactos do ambiente Hello.Wall ............................................. 30
xiii
3.1
Arquitectura Tecnológica do LightMeet ................................................. 46
3.2
Diagrama de classes da Estrutura de Dados .............................................47
3.3
Representação gráfica da relação de agregação composta entre as classes
Reunião e Nó ........................................................................................... 48
xiv
3.4
Exemplo de sessão de reunião ................................................................. 49
3.5
Diagrama de pacotes referente ao LightMeet.......................................... 51
3.6
Diagrama de 1º nível de casos de utilização do Cliente LightMeet ........ 52
3.7
Diagrama de casos de utilização referente ao módulo de Registo........... 53
3.8
Diagrama de casos de utilização referente ao módulo Gestão de Itens... 54
3.9
Diagrama de casos de utilização referente ao módulo Reuniões............. 66
3.10
Diagrama de casos de utilização referente ao módulo Agenda ............... 71
3.11
Diagrama de casos de utilização referente ao módulo Espaço Privado... 72
3.12
Diagrama de componentes....................................................................... 75
4.1
Desenho geral da arquitectura do sistema. ............................................. 86
4.2
Componentes do sistema. ....................................................................... 89
4.3
Formato da mensagem enviada dos clientes para o servidor. ................. 92
4.4
Formato da mensagem enviada dos servidor para os clientes. ............... 92
4.5
Registo do Servidor. ............................................................................... 93
4.6
Registo do Cliente. ................................................................................. 94
4.7
Troca de mensagens, ficando a ligação virtual efectiva. ........................ 95
4.8
Diagrama de classes do cliente ................................................................ 96
4.9
Diagrama de classes do servidor.............................................................. 99
4.10
Diagrama de componentes do servidor.................................................. 102
4.11
Diagrama de Instalação.......................................................................... 104
4.12
A interface do cliente, referente ao ecrã principal com menu “Tools” activo
............................................................................................................... 106
4.13
A interface do cliente – visualização dos itens da Agenda (opção Agenda)
................................................................................................................107
4.14
A interface do servidor, referente a visualização da arvore geral da reunião
............................................................................................................... 109
4.15
A interface do cliente – visualização dos itens da Arvore Geral da reunião
(opção Tools - Dynamic Cursor - Viewport)..........................................109
4.16
A interface do cliente – visualização dos itens da base de dados local (opção
Tools - Dynamic Cursor - Private). ........................................................110
4.17
A interface do cliente – visualização das reuniões gravadas(opção Tools Meetings) ............................................................................................... 112
4.18
A interface do cliente – ecrã referente a base de dados local (opção Tools –
Private Space) ........................................................................................ 113
4.19
A interface do Servidor, módulo referente a administração do software 114
4.20
A interface do Servidor, módulo referente arvore da reunião ............... 115
4.21
A interface do Servidor, módulo referente a Agenda .............................116
4.22
A interface do Servidor, vista parcial da árvore da pasta “To minimize the
risks” ...................................................................................................... 117
xv
4.23
A interface do Servidor, vista da tabela de votos preparada para receber a
votação na lista de itens da pasta “Business Risks” ...............................117
xvi
5.1
Gráfico referente ao número de respostas dadas pelo grupo A ............. 125
5.2
Gráfico referente ao número de respostas dadas pelo grupo B ............ 127
5.3
Gráfico referente ao número de respostas globais (A + B) ....................128
Lista de Tabelas
1.1
Principais causas para as falhas dos GSS. ...................................................... 3
1.2
Matriz de DeSanctis e Gallupe. ...................................................................... 6
2.1
Análise comparativa de aplicações colaborativas. ......................................... 34
2.2
Análise comparativa com a ferramenta proposta. .......................................... 39
4.1
Tipos de mensagens de sistema. .................................................................... 90
4.2
Tipos de mensagens de aplicação. ................................................................. 91
5.1
Percentagens das respostas do grupo A ........................................................125
5.2
Percentagens das respostas do grupo B ....................................................... 126
5.3
Percentagens das respostas globais (A + B) ................................................ 128
xvii
Glossário
API
Application Programming Interface
BRAINSTORMING Geração de Ideias
xviii
CSCW
Computer Support Cooperative Work
DAL
Device Abstration Layer
DLL
Dynamic Link Library
GCSS
Group Communication Support System
GDSS
Group Decision Support Systems
GNSS
Group Negociation Support System
GSS
Group Support Systems
IDC
International Data Corporation
IDE
Integrated Development Enviroment
J2ME
Java 2 Micro Edition
JDBC
Java Database Connection
JDK
Java Development Kit
MIDP
Mobile Information Device Profile
MVC
Model – View – Controller
ODBC
Object Database Connection
PACE
Palm Application Compatibility Environment
PC
Personal Computer
PDA
Personal Digital Assistant
POSE
Palm OS Emulator
PRC
Palm Resource Collection
RAM
Random Access Memory
ROM
Read Only Memory
SDG
Single Display Groupware
SDK
Software Development Kit
SO
Sistema Operativo
SQL
Structure Query Language
VM
Virtual Machine
xix
Capítulo 1 - Introdução
1
Capítulo 1
Introdução
A abordagem estudada nesta dissertação inclui o desenvolvimento de um sistema de
apoio a reuniões electrónicas, a que foi dado o nome de LightMeet. Iremos em seguida
descrever o contexto, objectivos e estrutura da dissertação.
1.1 Contexto
1.1.1 Reuniões Electrónicas
No universo organizacional, uma parte significativa das decisões é tomada em reuniões,
que muitas vezes estão longe de ser produtivas [Nunamaker et al., 1997]. Uma hipótese
que tem sido estudada para aumentar a produtividade das reuniões passa pela utilização
de tecnologias de informação, razão pelo qual diversos sistemas académicos, em
diversas áreas (CSCW, Computer Supported Cooperative Work, GDSS, Group
Decision Support Systems, GSS, Group Support Systems), têm sido propostos com o
intuito de avaliar esta hipótese.
As reuniões adequam-se a uma vida organizacional moderna, onde os problemas são tão
complexos que ninguém tem a informação e a experiência suficiente para resolvê-los
sozinho [Vreede et al., 2003].
As tecnologias de suporte a reuniões electrónicas têm vindo a ser desenvolvidas desde
há 30 a 35 anos. A primeira demonstração de um sistema de reuniões electrónicas
Dissertação de Mestrado de Licínio Pereira
2
(NLS) foi em 1968, por Douglas Engelbart [MouseSite, 1968]. A colaboração era
remota, com comunicação por video e controlo remoto. Em 1985, na Universidade do
Arizona, uma equipa chefiada pelo Professor Jay Nunamaker desenvolveu o sistema
PLEXSYS [Konsynski & Nunamaker, 1984/85], tendo como funcionalidades
principais, o suporte à geração de ideias, o suporte à análise e organização de ideias e o
suporte à votação de ideias. Mais tarde foram adicionadas outras funcionalidades,
passando o sistema a designar-se por GROUPSYSTEMS [Nunamaker et al., 1991].
Bostrom et. al. [1993], vêm a reunião como um objectivo ou um resultado da interacção
directa entre duas ou mais pessoas (equipas ou grupos), daí que a descrevem como um
sistema Sócio-técnico de mudança de processos, com enfoque nos resultados. Estas
podem realizar-se em um dos quatro seguintes ambientes: mesmo tempo e espaço,
mesmo tempo / espaço diferente, diferente tempo e espaço e diferente tempo / mesmo
espaço [Ellis et al., 1991]. Durante o processo de reunião é utilizado um conjunto de
recursos (pessoas, tecnologia), que visam transformar o presente estado do problema de
grupo num estado futuro (cumprindo os resultados específicos da reunião – tarefas e
relações), tendo em conta uma série de tópicos (Agenda). Por sua vez, cada tópico
conduz a várias actividades de grupo. Por exemplo, para realizar um tópico de agenda, o
grupo poderá ter que gerar informação, organizar informação em alternativas, avaliar e
seleccionar as alternativas e discutir (comunicar) as suas acções. As ferramentas GSS e
outras tecnologias de suporte a reuniões podem ser classificadas em termos das diversas
actividades que suportam, como é o caso, por exemplo, do Brainstorming para gerar
alternativas, da categorização para organizar informação e da votação para escolher a
alternativa preferida pelo grupo.
Com a evolução da tecnologia computacional as reuniões convencionais, conduzidas
com base nos recursos tradicionais de reunião (pessoas, agenda), deram origem a uma
nova forma de reunião, a reunião electrónica.
A diferença entre uma reunião convencional e a electrónica (utilizando tecnologias de
informação), passa assim pela utilização de software e hardware que irá permitir a
recolha, partilha, estruturação e redução de informação, de acordo com as actividades
necessárias à realização dos objectivos da agenda. Está provado que as reuniões
3
electrónicas podem demorar metade do tempo que as convencionais [Weatherall &
Nunamaker, 2000].
A utilização de GSS nas reuniões permitiu resolver muitos problemas (por exemplo,
inadequada definição dos objectivos, insuficiência de planeamento, selecção errada dos
participantes, inadequada preparação dos participantes, atraso dos participantes na
reunião, informação insuficiente, demasiada informação, condução inadequada da
reunião, tempo gasto em revisão de reuniões anteriores e atenção excessiva a questões
irrelevantes) [Nunamaker et al., 1997] associados às reuniões. No entanto, como
qualquer ferramenta, tem de ser manejada com inteligência e técnica para produzir
resultados proveitosos. Face a histórias de sucesso e insucesso no uso de GSS nas
reuniões, foram realizados diversos estudos [Vreede et al., 2003] que resultaram na
identificação de algumas das causas de insucesso. A Tabela 1.1 mostra esses problemas.
Os resultados obtidos da utilização de GSS [Vreede et al., 2003, Costa et al., 1999,
Fjermestad, 2000, Fjermestad & Hiltz, 1998], focando a identificação dos aspectos
positivos e negativos destes sistemas, têm sido muito controversos. Sendo identificado
um conjunto significativo de vantagens, também não podem ser ignoradas muitas
desvantagens, pelo que o balanço global não é sempre positivo.
Problemas com planeamento
1.
2.
3.
Agenda pouco clara
Agenda desequilibrada: incorrecta distribuição do tempo pelas actividades
Pouco tempo para discussão
Problemas com objectivos
1.
2.
3.
4.
5.
Objectivos deficientemente definidos pelo patrocinador
O patrocinador não entende a percepção dos participantes sobre o problema
Os participantes estão mal informados sobre o propósito da reunião
Expectativas de conflito sobre o conteúdo da reunião
Necessidade de percepção de conflito na reunião
Problemas com a tecnologia
1.
2.
3.
A tecnologia não funciona ou falha
A falta de confiança no anonimato resulta rejeição da tecnologia
A não aprovação do anonimato resulta numa pobre ou reduzida comunicação
4
Problemas com os participantes
1.
2.
3.
Peritos de áreas que não se encaixam no contexto do problema
Os elementos chaves não estão presentes ou não são convidados
Não são detectados conflitos e políticas no grupo
Problemas com os facilitadores
1.
2.
3.
Pessoas não qualificadas
Facilitadores inexperientes ou incompetentes
Facilitadores que não tornam o grupo produtivo
TABELA 1.1 – Príncipais causas para o insucesso dos GSS.
A conclusão tirada destes estudos é que existem sérios problemas de sustentabilidade a
longo prazo na utilização destes sistemas [Briggs et al., 2003]. Uma das possibilidades
para resolver estes problemas passa pela simplificação da tecnologia dos GSS e pela
utilização de uma arquitectura simples, solução que vai ser explorada nesta dissertação:
A arquitectura proposta apoia o trabalho colaborativo numa situação face-a-face, através
da partilha de um computador e de um monitor, permitindo ainda que múltiplos PDA’s
interajam simultaneamente com o sistema.
A arquitectura vai permitir a utilização de software e hardware mais simples no apoio as
reuniões electrónicas. Isto é vai permitir que não seja necessário a utilização de salas e
equipamento dedicado e caro. Também o uso de software com interfaces menos
intrusivos que garantam ficar em segundo plano durante as reuniões.
5
1.1.2 Sistemas Cooperativos de Suporte a Reuniões Electrónicas
A cooperação é uma operação conjunta num espaço de informação partilhada entre os
membros do grupo. Num espaço partilhado de informação, os indivíduos cooperam
através da produção, manuseamento e organização de informação que é normalmente
obtida através da conversação e argumentação entre os membros do grupo. O
armazenamento da informação trocada, permite ao grupo construir memória colectiva,
que pode ser consultada sempre que seja necessário recuperar a história da discussão ou
o contexto no qual uma decisão foi alcançada. O objectivo da preservação de
informação é aumentar o entendimento entre as pessoas, reduzindo as incertezas
(relacionadas com a falta de informação ou de contexto) e os níveis de erro (relacionado
com a ambiguidade e a existência de conflitos de informação), que são ultrapassados
com a utilização de sistemas de apoio a reuniões.
Os termos GSS (Group Support Systems - Sistemas de apoio a grupos) e EMS
(Electronic Meeting Systems – Sistemas de apoio a reuniões) são muitas vezes
utilizados alternadamente. Todavia,
enquanto o termo GSS pode ser colocado no
contexto de um vasto raio de domínios de aplicação, o termo EMS só pode ser usado
no contexto de processos estruturados de apoio à reunião.
Os GSS’s são uma generalização dos GCSS (Group Communication Support Systems sistemas de apoio à comunicação em grupo) [Fjermestad & Hiltz, 1998], GNSS (Group
Negotiation Support Systems - sistemas de apoio à negociação em grupo) [Bellucci &
Zeleznikow, 1998] e GDSS (Group Decision Support Systems - sistemas de apoio à
decisão em grupo) [DeSanctis & Gallupe, 1987].
O facilitador é um dos componentes humanos das reuniões electrónicas, englobando os
papéis de técnico especialista na manipulação e configuração dos GSS e condução do
processo de reunião. Na primeira função, tem de ser garantido que as dificuldades
técnicas com a tecnologia não interferem com o normal funcionamento da reunião. A
6
facilitação ao nível do processo da reunião é feita através da aplicação de técnicas de
facilitação de trabalho em grupo. Estes dois papéis podem ser desempenhados por uma
ou duas pessoas, sendo preferível a segunda opção, segundo argumentos apresentados
por alguns autores [Bostrom & Anson, 1992; Bostrom et al., 1993].
Um modelo que pode ser útil para classificar e organizar conceitos e ferramentas de
GSS é a matriz de DeSanctis e Gallupe (1987). Nesta matriz cruzam-se duas dimensões:
a duração da sessão de tomada de decisão (TEMPO) e a dispersão dos membros do
grupo (ESPAÇO).
Duração da Sessão
Dispersão
Limitada
Contínua
Próxima
Sala de decisão
Rede de decisão local
Dispersa
Teleconferência
Tomada de decisão remota
TABELA 1.2 – Matriz de DeSanctis e Gallupe (1987)
A ferramenta proposta nesta dissertação enquadra-se na categoria das salas de decisão,
nas quais os participantes encontram-se numa mesma sala, face-a-face e a comunicar de
forma oral ou através do computador (zona sombreada da matriz – Tabela 1.2). A
configuração da sala de reunião vai desde uma simples disposição de um pequeno
conjunto de secretárias colocadas em forma de “U”, e com um ecrã grande, visível por
todos, em que apenas o facilitador tem acesso ao computador, até uma configuração
mais complexa, que inclua grande número de participantes. Mais adiante serão
discutidos vários tipos de salas de reunião e as implicações destas configurações nos
EMS. O ecrã público é utilizado para focar a atenção dos participantes e na
apresentação, analise e organização de ideias. Existem outros ambientes de reunião
classificados nesta tabela, que serão seguidamente descritos.
7
Rede de decisão local – Em vez de estabelecer uma sala de reunião permanente
(recurso escasso em algumas organizações) para o grupo, opta-se por criar uma “rede de
decisão local” para dar suporte aos elementos do grupo, por forma a puderem trabalhar
a partir do seu local de trabalho. Este sistema deverá ter uma rede local, diversos
clientes e um servidor onde estará o software GSS e as respectivas bases de dados. Cada
membro do grupo estará ligado à rede local através do cliente, utilizando software
dedicado a suportar comunicação com os outros elementos do grupo e acesso aos
serviços disponíveis (por exemplo, marcar reuniões, aceder a bases de dados, etc). Cada
cliente mostrará uma perspectiva do “espaço público” da reunião.
Teleconferência - Este tipo de GSS é utilizado por grupos em que os membros estão
distantes geograficamente, todavia, existindo a necessidade de se reunirem para tomar
decisões. Nesta situação duas ou mais salas de reunião são ligadas através de um
circuito de áudio e vídeo, utilizando tecnologia de teleconferência. Em cada sala existe
um ecrã público que apoia o esforço de convergência dos participantes.
Tomada de decisão remota – Nesta situação existem computadores remotos ligados
entre si, pertencentes a uma organização geograficamente dispersa, que tem um grupo
restrito de pessoas que com necessidades de reuniões regulares.
Nas salas de decisão, as interacções face-a-face combinadas com as formalizações
impostas pela tecnologia tornam estas reuniões mais eficazes e eficientes. As redes de
decisão local não suportam uma comunicação face-a-face, contudo, apresentam uma
maior flexibilidade em relação ao local onde se realizam e em relação a paragens
durante a reunião. A teleconferência, embora tenha uma abordagem semelhante às salas
de decisão, foca principalmente na comunicação áudio/vídeo.
As redes de decisão local e a tomada de decisão remota não necessitam de um espaço
físico para que as reuniões se realizem. No entanto, o espaço virtual da primeira
restringe-se normalmente à rede local de um edifício, sendo que a segunda abrange a
rede de um país ou de um continente.
8
A secção seguinte vai apresentar diversos tipos de configurações de salas de reunião
contemplando o escritório, que é a configuração utilizada no sistema proposto.
Configurações de Salas de Reunião
A escolha da sala de reunião tem um impacto significativo na qualidade global da
reunião. Entre outras coisas, a sala pode inibir ou desinibir a reunião, motivar ou não a
comunicação, promover ou não a criatividade e fazer com que os participantes se sintam
relaxados ou tensos. É assim importante ter em atenção a escolha e configuração do
espaço da reunião.
A escolha da sala [3M Meeting, 1994] é condicionada por factores como a luz,
ventilação, acústica e número de participantes, sendo este último um dos factores mais
importantes nesta escolha. Assim, quanto maior for o número de participantes numa
reunião, menor deve ser a duração da mesma, uma vez que a interacção se torna mais
restrita e mais difícil de manter o interesse de todos os participantes. Daí que, enquanto
um grupo pequeno pode estar durante horas absorvido pela procura de uma solução
para um problema, um grupo grande pode-se distrair em questão de minutos.
No espaço de reunião, as mesas podem estar dispostas em forma de ferradura, em
forma circular, em forma de círculos concêntricos, em forma de semicírculos, em forma
de linha e em forma ovular (mesa de conferência). Estes tipos de configuração estão
intimamente relacionados
com os diferentes tipos de salas de reunião, ou seja, a
disposição das mesas varia com o tipo de sala. Entre estes últimos podemos destacar
[3M Meeting, 1994]:
-
Escritório – Em salas pequenas, sem mesa de conferência, um projector pode
ser colocado num dos lados da secretária e o orador senta-se atrás da secretária
de forma a que a apresentação seja projectada num ecrã em frente daquela
secretária. É ideal para reuniões informais que não tenham mais de 6 pessoas.
-
9
Sala de conferências – Neste tipo de sala utilizam-se mesas circulares e mesas
em forma de ferradura. As mesas circulares são normalmente utilizadas nas
reuniões de grupos pequenos (6 a 12 pessoas), enquanto que as mesas em forma
de ferradura são utilizadas nas reuniões de grupos grandes (10 a 30 pessoas). A
disposição das mesas em forma circular é ideal para as reuniões cujo objectivo é
a resolução de problemas e a tomadas de decisão, uma vez que permite aos seus
participantes verem-se uns aos outros e encoraja a sua interacção. No que diz
respeito à disposição das mesas em forma de ferradura, esta é mais aconselhável
para reuniões de grupos grandes, pelo facto do seu propósito principal ser a
partilha de informação. Esta configuração, que necessita de um líder identificado
da reunião, dá a este último uma visão clara de todos os participantes e ajuda a
criar o sentimento de igualdade entre os restantes.
-
Sala de aula – Esta configuração é ideal para grupos grandes e reuniões longas.
Também é eficaz para sessões de instrução e outras reuniões que precisem de
espaço para trabalhar individualmente ou em sub-grupos.
-
Auditório ou teatro – Este tipo é muito utilizado nas reuniões com um grande
número de pessoas, onde se espera pouca discussão e onde a principal
preocupação é que o ecrã seja visto por todos os participantes.
-
Anfiteatro – Esta configuração é para reuniões com um número pequeno ou
médio de participantes. Não é recomendado para reuniões longas e não é
apropriado para reuniões que precisam de espaço para trabalhar individualmente
ou em sub-grupos.
10
1.1.3 Aplicações cooperativas com um único visor
Em 1999, Stewart et al., descreveram um tipo de aplicação colaborativa, designada por
“Single Display Groupware” (SDG), que apoia actividades de grupo numa situação
face-a-face. Resumiram o conceito como sendo:
“Software específico que permite a utilizadores co-presentes, colaborem através de um
sistema computacional partilhado, com um único visor partilhado e o uso de vários
dispositivos de entrada.”
As arquitecturas SDG, estão ligadas de forma intrínseca às salas de decisão, devido às
interacções serem feitas no mesmo espaço e tempo.
Enquanto as aplicações tradicionais de groupware, fornecem um único canal de entrada
e um único canal de saída para cada utilizador (por exemplo, GroupSystems [Bostrom
& Anson, 1992], Groove [Ellis et al., 1991], Netmeeting [Munkvold & Anson, 2001]),
as aplicações SDG, fornecem um canal de entrada para cada utilizador através do uso de
dispositivos de entrada independentes, em que os utilizadores partilham um único canal
de saída.
As vantagens de um sistema SDG, são as seguintes: (1) aumenta as comunicações
verbais e não verbais; (2) possibilita tipos de interacção que necessitam de múltiplos
utilizadores a colaborarem em simultâneo; (3) vários dispositivos de entrada vão
permitir um trabalho mais motivante e eficiente; (4) incentiva o ensino e a
aprendizagem ao par (professor/aluno); (5) fortalece as técnicas de comunicação,
porque alguns participantes já não podem monopolizar as tarefas, apenas pelo controlo
do dispositivo de entrada, terão que comunicar mais entre si para resolver conflitos.
11
FIGURA 1.1 - Duas pessoas a trabalharem num ambiente SDG, ambas com um
dispositivo de entrada (Rato).
As desvantagens são : (1) não permitem reuniões remotas; (2) há dados experimentais
que indicam poder demorar mais tempo a completar uma tarefa [Fjermestad & Hiltz,
1998]; (3) as aplicações podem ser mais lentas, em comparação com aplicações monoutilizador e aplicações tradicionais de groupware, devido aos requisitos de
processamento; (4) implica o aparecimento de barreiras à interacção, confrontando com
a alternativa face-a-face.
O conceito de SDG tem sido aplicada em diversos domínios de aplicação, tais como:
•
Educacional (Tivoli [Pederson et al., 1993], Inkpen [Inkpen et al., 1997]);
•
Entretenimento (Kidpad [Druin et al., 1997];
•
Organizacional (Pebbles Project [Myers, 2001, Myers et al., 1998.];
O
Projecto Ambiente [Ambiente].; O Projecto Colab [Stefik et al., 1987-1992].
O recente aumento da investigação no campo das aplicações SDG [Shoemaker, 2001] é
um sinal de que os cientistas acreditam que o paradigma de um utilizador para um
monitor, está demasiado restritivo, em detrimento do utilizador. Acredita-se que possa
12
ser vantajoso, em certas circunstâncias, que mais do que um utilizador interaja de forma
síncrona com um monitor.
Os sistemas SDG proporcionam apoio a pequenos grupos, para que estes colaborem à
volta de um ecrã, através da oferta a diversos utilizadores de entrada simultânea de
informação. Foram efectuadas investigações exaustivas sobre o impacto do uso de
múltiplos dispositivos de entrada em colaborações face-a-face. Em particular, foi
investigado [Inkpen et al., 2000] o impacto desta tecnologia na realização, motivação,
compromisso e desenvolvimento de entendimento partilhado, tendo-se concluído que o
apoio a interacções simultâneas e a múltiplos utilizadores, pode proporcionar benefícios
positivos para cada área acima mencionada.
Os utilizadores de uma configuração SDG também ganham com a riqueza das
interacções face-a-face, uma vez que estão no mesmo espaço físico (a proximidade
física dos utilizadores), onde facilmente se podem ver uns aos outros, observar os gestos
de cada um, ter conversas sem ser por meios electrónicos, mas de forma directa
(comunicação natural e efectiva) e observar o comportamento dos outros.
Uma das limitações dos sistemas SDG é o facto de toda a informação ser pública por
omissão. Como não é possível ter informação privada de forma natural, pode-se
ponderar a utilizaçao de um PDA por cada utilizador para ultrapassar este entrave, o que
permite a visualização e manipulação de informação privada e, muitas vezes, a
interacção com o ecrã partilhado.
Foi efectuado um estudo [Streitz et al., 1997] do impacto da utilização de diferentes
configurações de roomware para diferentes cenários de salas de reunião electrónica,
tendo-se constatado que os grupos a que foi dado a possibilidade de trabalharem com
dispositivos pessoais e públicos produziram resultados de qualidade superior aos grupos
que tinham somente dispositivos pessoais de informação ou somente dispositivos
públicos de informação. O grupo vencedor também produziu mais ideias de forma
significativa.
13
A abordagem SDG foi estendida recentemente para englobar locais de trabalho do
futuro, que contemplam a integração de espaços arquitectónicos com espaços virtuais
de informação. A esta abordagem dá-se o nome de “Edifícios Cooperativos” [Streitz et
al., 1998]. É um ambiente flexível e dinâmico que proporciona um espaço cooperativo
através do apoio e melhoramento da comunicação e colaboração entre humanos. Estes
edifícios servem o propósito da cooperação e, ao mesmo tempo, são cooperativos em
relação aos seus habitantes e visitantes. Isto é, não só proporciona as instalações mas
pode também reagir “por sua conta” depois de identificar certas condições. Enquanto
que o termo “Edifício” implica uma forte relação com a estrutura física, o conceito de
“Edifícios Cooperativos” vai para além disso. Entende-se que os “Edifícios
Cooperativos”
têm
origem
no
espaço
físico
arquitectónico,
embora
sejam
complementados por componentes criados como objectos informáticos e estruturas no
espaço virtual da informação. Dentro da plataforma “Edifício Cooperativo” as pessoas
podem
comunicar,
partilhar
informação
independentemente da localização física.
e
trabalhar
cooperativamente,
14
1.1.4 Toolkit Pebbles
O projecto Pebbles, criado na universidade Carnegie Mellon [Myers et al., 2001, Myers
et al., 1998.], estuda o uso de assistentes pessoais (PDA) e telefones inteligentes na sua
comunicação com um PC, com outros equipamentos similares e com aplicações
embutidas em telefones, rádios, microondas, carros e máquinas de fabricas. Para além
da comunicação entre equipamentos, estuda a sincronização de múltiplos PDA’s, o uso
simultâneo de um ou mais PDA’s com um PC numa sala de aulas e a integração de
tecnologias de apoio nestes equipamentos, direccionados para pessoas deficiências. O
objectivo central é desenvolver tecnologia e aplicações para PDA’s.
O sistema proposto nesta dissertação vai utilizar um dos componentes do Toolkit
Pebbles [Pebbles], o componente PebblesPC é disponibilizado para desenvolvimento de
aplicações com a arquitectura descrita na Figura 1.2.
Cabo Série(COM1); Cradle;
Bluetooth
PDA's
interface OLE
PC
Cliente
SlideShow
Servidor
SlideShow
Ms Powerpoint
Servidor Scroller
Cliente Scroller
PebblesPC
Outros Clientes
Outros Servidores
DLL's ou Sockets
Qualquer
aplicação de
PC
m e ns a g en s wi n do ws ;
eventos do rato; e do
teclado
FIGURA 1.2 - Esquema geral da Arquitectura do Toolkit Pebbles, com algumas
aplicações clientes e o respectivo Plug-in (servidor).
15
Descrição geral do Toolkit Pebbles
O Pebbles apresenta uma arquitectura de três camadas: a primeira é o cliente que
concretiza a interface com o utilizador; a segunda camada consiste no componente
mediador que é descrito no parágrafo seguinte; a terceira camada consiste no servidor, o
componente prestador de serviços. As comunicações entre cliente e PebblesPC são
suportadas através de tecnologia sem fios ou cabo série. A comunicação entre o
PebblesPC e o servidor é feita através da rede Ethernet.
O componente mediador, na arquitectura do Pebbles, designa-se por PebblesPC e
medeia as comunicações entre as aplicações cliente e servidor ligadas ao sistema. Os
utilizadores podem interagir com o sistema através de um programa cliente instalado
num PDA ou PC. As aplicações servidor, neste sistema, podem ser de dois tipos:
•
Plugin - é uma biblioteca de ligação dinâmica (DLL), que é carregada para o
espaço de memória do sistema.
•
Programa independente – é um processo separado que pode correr no mesmo
PC ou num PC remoto, em que a comunicação com o sistema é feita através de
sockets.
As principais funcionalidades do componente mediador são a prestação do serviço de
nomes e o encaminhamento de mensagens entre os programas cliente e servidor. As
aplicações servidor tornam-se disponíveis a partir do momento em que se ligam ao
sistema Pebbles e registam o seu nome. As aplicações cliente ligam-se ao servidor,
fazendo primeiro a ligação ao sistema e requerendo um servidor pelo seu nome. Se o
servidor referenciado estiver registado, o sistema irá criar uma ligação virtual entre os
dois, possibilitando assim a troca de mensagens, através de um protocolo especifico do
sistema.
O sistema permite aos clientes e servidores ligarem-se através de interfaces
heterogéneos de entrada / saída, tais como portas série, tecnologia sem fios, sockets e
16
troca de mensagens através do Microsoft Windows. O PebblesPC trata dos detalhes de
baixo nível de cada interface.
Os sistemas operativos convencionais têm um grave problema técnico que é só
disponibilizarem um dispositivo de entrada do mesmo tipo (um rato, um teclado), o que
não é apropriado para a arquitectura desejada para o trabalho proposto nesta dissertação.
A solução passa por criar ou utilizar uma arquitectura já desenvolvida que suporte
múltiplos dispositivos de entrada e outras funcionalidades úteis nas aplicações de
trabalho de grupo. O uso do Toolkit Pebbles reduz muitas das dificuldades de
desenvolvimento deste tipo de groupware. O resultado é que os programadores podem
focar o seu esforço nos problemas específicos da sua aplicação, reduzindo
significativamente o tempo de desenvolvimento. O Toolkit Pebbles disponibiliza uma
API (Application Program Interface) para acesso aos serviços do PebblesPC.exe, que
garantem a entrega fiável das mensagens, a ordem das mensagens ou tolerância a faltas.
A opção por esta arquitectura SDG deveu-se a procurar evitar repetir desenvolvimentos
já realizados e disponíveis.
17
1.2 Objectivos
O propósito deste trabalho é o seguinte:
•
Suportar a reuniões electrónicas do tipo “Sala de decisão” e com uma
arquitectura do tipo SDG;
•
Integração de PDA na arquitectura SDG, com o objectivo de ser possível ter um
espaço privado, onde o utilizador possa criar e gerir informação pessoal, algo
que não pode normalmente fazer numa aplicação SDG, onde a informação
existente é toda pública;
•
Definir um modelo de dados em árvore que permita aos utilizadores gerir a
informação disponível no espaço público de forma organizada mas
descentralizada, garantindo sempre uma relação entre os objectos da interface
sejam eles pessoais ou públicas;
•
Execução de algumas operações / funções no PDA por parte dos utilizadores do
sistema, como melhor solução para a interacção com o sistema, em vez da
partilha de um teclado e um rato;
•
Oferecer uma arquitectura que possa reduzir o custo tanto ao nível da
configuração dos GSS, como ao nível da facilitação e ao nível do processo de
reunião (facilitador), evitando utilização de diversos PC clientes; evitando o
papel central do facilitador na configuração da tecnologia.
Neste trabalho, irá ser feita a integração de tecnologias que permitam uma maior
flexibilidade, mobilidade e integração entre diversos dispositivos e tecnologias dentro
de um ambiente de reunião (rede com/sem fios, PDA, Java) [Tang et al., 2001].
18
1.3 Estrutura da Dissertação
Esta dissertação está organizada da seguinte forma. O presente capítulo faz a uma breve
introdução ao tema, ao contexto, aos problemas e objectivos da dissertação.
O capítulo 2
apresenta uma panorâmica geral das arquitecturas SDG.
Esta
panorâmica começa por descrever conceitos e características das arquitecturas SDG.
São também apresentados os diversos problemas, soluções e tecnologias utilizadas para
superar os diversos entraves conhecidos, caracterizando o estado actual do
conhecimento nesta área. No final do capítulo 2 é feita uma análise comparativa dos
sistemas existentes com a ferramenta proposta.
O capítulo 3 apresenta a análise de requisitos do sistema proposto, tendo por base
as necessidades dos utilizadores e os problemas encontrados no capítulo 2. Para tal, é
utilizada a linguagem de modelação UML (Unified Modeling Language).
O capítulo 4 descreve os aspectos relevantes da realização do sistema. Começa por
ser apresentado o ambiente de desenvolvimento, seguindo-se uma descrição detalhada
do software, auxiliada por esquemas, diagramas de classe e de instalação.
O capítulo 5 reporta uma experiência realizada com dois grupos de utilizadores,
em que se procura avaliar a ferramenta ao nível da usabilidade e funcionalidade.
O capítulo 6 apresenta conclusões e trabalho futuro.
Capítulo 2 – Panorâmica
19
Capítulo 2
Panorâmica
2.1 Introdução
Nesta dissertação é estudado o suporte computacional em reuniões electrónicas com
PDA’s. Uma questão central em análise é o papel do PDA na arquitectura SDG tendo
com contexto de fundo as reuniões electrónicas.
Em primeiro lugar, é realizada uma síntese geral sobre a área de investigação em que se
insere o trabalho, com particular ênfase na descrição do paradigma de aplicações
cooperativas de um único ecrã (SDG), aonde são apresentados problemas e soluções
que influenciaram a sua evolução. Em seguida, procede-se a um levantamento dos
projectos de investigação relacionados com o contexto “integração de SDG e PDA”, e
de estudos empíricos sobre a utilização de múltiplos dispositivos de entrada. Por fim, é
realizada uma análise comparativa da ferramenta proposta com outras ferramentas
similares.
2.2 Arquitectura SDG
O paradigma MVC (Model – View – Controller) [Goldberg, 1984] vai servir de base
para desenvolver o conceito SDG.
O paradigma MVC divide uma aplicação em três partes: Modelo, Vista e Centro de
Controlo. O MVC foi originalmente concebido para mapear o tradicional ciclo de
20
entradas, processamento e saídas do domínio da interface Pessoa – Máquina. O Modelo
corresponde à informação básica do programa (os dados). A Vista corresponde à parte
que controla os canais de saída do sistema. O Centro de Controlo corresponde à parte
que manipula o canal de entrada.
Utilizando o paradigma MVC, passo a descrever os sistemas SDG como tendo uma
única vista partilhada, através da qual o sistema oferece retorno (feedback) para todos os
utilizadores, e um único modelo partilhado que permite que todos os utilizadores
interajam com um único sistema. As aplicações SDG podem ter vários Centros de
Controlo, se a aplicação quiser replicar todos os elementos da interface por todos os
utilizadores e fornecer aos mesmos uma única cópia.
Centros de Controlo
Modelo de Dados
Partilhados
Teclado
Rato
PC
Ponto de Acesso
Utilizador 1
Teclado
Rato
Utilizador 2
Vista Partilhada
Ecrã
Teclado
Canais Partilhados de
Saida
(video, audio)
Rato
Utilizador n
Canal de Entrada Privado
FIGURA 2.1 – Esquema genérico de uma arquitectura SDG
A arquitectura SDG levanta alguns problemas ao nível da interface com o utilizador. Na
secção seguinte serão descritos algumas das dificuldades observadas por investigadores
21
[Shoemaker, 2001] nesta área, assim como algumas soluções adoptadas para colmatar
esses problemas.
2.3 Problemas com a Arquitectura SDG
Existem diversos problemas causados pela interacção dos utilizadores com os sistemas
SDG. A abordagem escolhida nesta dissertação e por alguns autores [Myers et al., 2001,
1999, 1998; Rekimoto, 1998, 1997; Greenberg et al., 1999] desta área de investigação
passa pela utilização do PDA como um substituto na execução de funções
problemáticas do sistema em causa. Passo a enumerar alguns casos:
(1) O PDA foi usado como dispositivo de entrada para um PC, emulando o rato e
teclado, uma vez que o sistema não permitia vários ratos e teclados simultâneos [Myers
et al., 2001].
(2) O PDA foi usado como uma paleta de ferramentas para gerir a entrada de dados no
sistema. Aqui existiam problemas ao nível da entrada de dados, manipulação dos dados,
separação dos espaços pessoais dos públicos e controlo da aplicação [Rekimoto, 1998].
(3) O PDA foi usado como um dispositivo que gere a informação pessoal e que permite
manipular a informação no PDA e no ecrã partilhado. Também transfere informação do
espaço pessoal para o espaço público [Greenberg et al., 1999].
Problemas introduzidos pelos PDA são o tamanho do ecrã, mais difícil usar que o rato e
o teclado, mais frágil que o PC (fácil de partir/perder), autonomia energética e mais
difícil a entrada directa de dados.
22
2.4 Integração de SDG e PDA
A seguir serão descritos um conjunto de projectos de investigação na área dos SDG’s,
no qual os autores propuseram como dispositivo de entrada o PDA, para ultrapassar os
problemas mencionados na secção anterior.
Os projectos são:
M-Pad
Lápis sem fios
FIGURA 2.3 - O M-Pad [Rekimoto Site].
Com a abordagem de multíplos dispositivos, Rekimoto criou um sistema com um
quadro digital, um projector e um PC para controlar ambos. Também a cada utilizador
é dado um PDA designado por M-Pad (Figura 2.3), que é baseado no lápis Mitsubishi
Amity-Sp [Rekimoto, 1998]. O quadro digital permite interagir com um ou mais lápis
electromagnéticos. Como o M-Pad suporta a mesma tecnologia do lápis que o quadro
23
digital, o utilizador pode usar o lápis com o PDA e com o quadro digital. Os utilizadores
podem trocar objectos digitais com qualquer destes dispositivos (PC, PDA, Quadro
Digital), utilizando uma operação designada por “Pick and Drop“, que será descrita
mais a frente.
Com base na arquitectura acima descrita, foi desenvolvida uma aplicação que vai
permitir a interacção de múltiplos dispositivos com o quadro digital. Esta aplicação
escrita em Java, designa-se por M-Draw [Rekimoto, 1998], e tem como interface uma
janela onde vai permitir aos utilizadores desenharem com o lápis. A parte do M-Draw
que gere o quadro digital é constituída por uma janela onde permite que os utilizadores
desenhem com o lápis. Também é adicionado uma funcionalidade que permite que o
sistema M-Pad controle a aplicação M-Draw.
FIGURA 2.4 – Numa situação de uso do M-Draw: Quadro digital que interage com
vários dispositivos [Rekimoto Site].
O M-Pad funciona como uma paleta pessoal, ou seja, é similar à paleta do “Paint”, por
exemplo. Cada utilizador pode usá-lo para aceder à sua informação pessoal ou criar
dados novos. A secção principal da janela do M-Pad, é o painel de ferramentas com
diversas páginas, no qual o utilizador pode seleccionar a cor e a largura do lápis e
preparar diagramas e textos. Utilizando lápis sem fios, o utilizador pode “agarrar” um
24
objecto e “largá-lo” no M-Draw. O M-Pad oferece assim uma maneira fácil e rápida de
personalizar o tamanho e a cor dos caracteres no M-Draw. O utilizador pode também
alterar o tamanho e cor dos caracteres no M-Pad, através do premir.
Pick
Drop
FIGURA 2.2 – Operação “Pick & Drop” [Rekimoto Site].
Pick and Drop: Rekimoto [Rekimoto, 1997] desenvolveu um método de manipulação
directa chamado “Pick & Drop”, que utiliza uma caneta sem fios para transferir dados
entre um PDA e um quadro digital. Pick & Drop é uma extensão ao “drag & drop“
utilizado nos tradicionais computadores de secretária. No uso desta técnica, podemos
apanhar um objecto (exemplo: um fragmento de texto) com a caneta no ecrã de um
computador e colocá-lo no ecrã de outro computador. Do ponto de vista da interface
com o utilizador, esta técnica permite ao utilizador “agarrar” e “largar” os dados
digitais, como se tratasse de um objecto físico.
Remote Commander:
25
Myers et al.
[Myers, 2001, 1999; Myers et al., 1998]
desenvolveram uma aplicação de groupware designada Remote Commander, com a
qual todos os participantes de uma reunião podem usar o PDA para enviar eventos de
rato e teclado para um PC. Os botões físicos no rodapé do Palm (Figura 2.5 – a) podem
executar várias acções do rato no PC. O botão central (cima / baixo) no rodapé do Palm
(Figura 2.5 - c) representam os botões esquerdo e direito do rato. Por exemplo,
pressionando na parte de cima do botão o RC envia um evento de premir do botão
esquerdo do rato, e soltando o botão o RC envia um evento de deixar de premir do
botão esquerdo. Isto permite fazer o arrastar quando botão está pressionado. Além deste
botão existem as labels no rodapé do ecrã (“Shift”, “Ctrl”, “Left”, ”Right”, ”Alt”,
”Func”) que indicam as funcionalidades dos botões, e se forem pressionados pelos o
lápis de apoio ao Palm, funcionarão também como botões no ecrã. O bater com o lápis
na área vazia do ecrã do Palm faz com que o RC envie um evento de premir. O mover o
lápis no ecrã do palm faz com que o cursor do PC se mova.
FIGURA 2.5 – Remote Commander, (a) Emulação do rato, (b) Emulação do teclado e
(c) Botão central [Pebbles].
Ao escrever caracteres na área de graffiti do Palm, esses caracteres serão enviados para
o PC como se fossem escritos no teclado do PC. Também poderá ser utilizado um
teclado parecido com o teclado virtual do Palm, que será activo ao pressionar nas áreas
26
do rodapé do ecrã (Figura 2.5 - b) onde tem escrito “ABC” para o teclado alfanumérico
e “123” para o teclado numérico.
O Remote Commander pode ser utilizado com todas as aplicações existentes e
executadas no PC, sem precisar fazer alterações nas mesmas. Com base em experiências
informais com outros sistemas de groupware, os autores do Remote Commander
confiaram nos protocolos sociais para controlar o acesso ao ecrã, em vez de utilizarem
um mecanismo formal de controlo de palco “floor-control” [Ellis et al., 1991].
FIGURA 2.6 – A interface do utilizador com (a) área de foco activa; (b) área de
atributos das notas activa [Davis et al., 1999, 1998].
Notepals: Brotherton et al. [Davis et al., 1999, 1998] desenvolveram a ferramenta
Notepals para que os participantes de uma conferência possam escrever notas da reunião
nos seus PDA, na forma manuscrita. Quando é utilizada a interface para escrita na
forma manual, o Notepals utiliza uma vista ampliada no PDA (Figura 2.6), para
ultrapassar os problemas que aparecem devido à pequena dimensão do ecrã. Depois da
reunião, os participantes podem sincronizar os seus PDA’s com as suas estações de
trabalho e com um repositório partilhado localizado no servidor. Mais tarde, pode ser
usado um web browser no PC (Figura 2.7) para ver as notas que, por sua vez, podem
27
ser visualizadas de forma ordenada ou filtrada, por hora, autor e tipo de nota. O
Notepals no PC fornece uma resolução de pixels aumentada para o utilizador (400 x
273), comparado com o normal formato dos PDA’s (160 x 160).
FIGURA 2.7 – A visualização de notas no “Note Browser” [Davis et al., 1999, 1998].
SharedNotes: Greenberg et al. [Greenberg et al., 1999] desenvolveram um sistema de
groupware – designado SharedNotes, baseado no toolkit GroupKit [Roseman &
Greenberg, 1992]. O SharedNotes permite manipular notas privadas (Figura 2.9) e
públicas (Figura 2.8) em três tipos de dispositivos: PDA, PC e ecrã público. Utilizando
o SharedNotes, uma pessoa pode anotar informação útil no seu PDA para uso pessoal e,
mais tarde, se desejar, publicar essa informação. No PDA a informação privada e
pública, está separada por painéis. A informação marcada para ser publicada, será
automaticamente propagada para o ecrã público partilhado, logo que o grupo se
encontre para dar inicio à reunião.
Durante as reuniões, um utilizador pode sincronizar a informação entre o PC e o PDA, e
os artefactos públicos podem ser depois propagados para o ecrã partilhado através do
PC atrás mencionado. Os autores desta ferramenta colocaram a restrição de que as notas
privadas passadas a notas públicas não podem passar novamente a privadas. Por outro
lado, as notas no espaço público só podem ser modificadas pelos utilizadores que as
passaram para públicas.
FIGURA 2.8 – Informação pública e pessoal [Greenberg et al., 1999].
FIGURA 2.9 – Espaço público (Ecrã Partilhado) [Greenberg et al., 1999].
28
29
Hello.Wall : [Prante et al., 2003], no âmbito do projecto “Ambient Agoras”, decidiram
utilizar padrões luminosos para transmitir informação acerca dos diferentes estados das
pessoas e ambientes físico e virtual de um espaço de trabalho num edifício. O sistema
foi criado para dar apoio, de forma espontânea,
a encontros informais em locais
remotos (exemplo: salas de estar). A configuração do exemplo mostrado na Figura 2.10,
mostra duas salas remotas ligadas em rede que trocam informação sobre o seu ambiente.
Deste modo estes dois espaços estão ligados e podem influenciar-se mutuamente.
FIGURA 2.10 – Duas salas ligadas através do sistema Hello.Wall [Ambiente].
O Hello.Wall é um ecrã do tamanho de uma parede, é considerado arte informativa (ou
artefacto de decoração) devido ao seu aspecto (estética), que emite informação através
de padrões de luz. De forma a comunicar informação detalhada e pessoal, o sistema
disponibiliza um artefacto móvel, designado “Viewport”.
O sistema cria três zonas de interacção para definir uma “semântica dependente da
distância”. Quer isto dizer que a distância de um indivíduo à parede define o tipo de
interacção oferecida e o tipo de informação mostrada no Hello.Wall e Viewport.
Quando as pessoas estão fora do alcance dos sensores colocados nas paredes, isto é na
zona ambiente, o ecrã mostra informação geral, definida para ser mostrada
independentemente da presença de alguém. Quando um indivíduo e o seu Viewport são
detectados na zona de notificação, dependendo do tipo de aplicação, dados podem ser
transmitidos para o Viewport e/ou distintos padrões de luz podem ser mostrados para
30
notificação. Os padrões de luz podem ser pessoais, apenas conhecidos por uma só
pessoa, padrões de grupo, ou padrões conhecidos por todos. Dentro da célula da zona de
interacção, as pessoas que estão perto da Hello.Wall podem interagir com cada célula
ou com várias células utilizando o Viewport para ler a identificação (ID) das mesmas. É
possível interacções simultâneas utilizando vários Viewport’s no Hello.Wall.
Viewport
Hello.Wall
FIGURA 2.11 – Os dois artefactos do ambiente Hello.Wall [Ambiente].
InterSpace: [Interspace] é um projecto de cooperação patrocinado pelo departamento
de investigação da Microsoft destinado a estudar um grupo de novas técnicas de
interacção para colaboração com dispositivos múltiplos e heterogéneos. Estas técnicas
exploram a interacção, apoio na colaboração entre utilizadores, dispositivos pessoais e
públicos, e ambientes integrados (utilizadores, dispositivos e contexto).
Protótipo de Carlos Costa: [Costa & Antunes, 2002] o trabalho em que se insere este
sistema, estuda a integração do EMS e o PDA, com o propósito de melhorar a produção
31
de relatórios das reuniões, tirando partido das capacidades de gestão de dados pessoais e
de grupo dos respectivos sistemas EMS E PDA.
Esta plataforma baseia-se num mecanismo conceptual que utiliza as noções de géneros
para ligar os dados de grupo com dados pessoais. Géneros de comunicação caracteriza a
colecção repetida de dados trocado por um grupo de pessoas para executarem um
trabalho. Com este mecanismo podemos caracterizar “o quê” e “como” as pessoas do
grupo poderão trocar informação entre o grupo, os indivíduos e os processos
organizacionais. O protótipo é baseado no conceito de género e apoia as actividades
necessárias para gerar artefactos de comunicação.
O protótipo é constituído por três componentes, ou seja, a base de dados do
responsável/facilitador, a base de dados dos participantes e uma aplicação partilhada de
gestão do quadro digital. Na implementação do software do PDA foi usado um sistema
de base de dados “jfile” para Palm Pilot.
A aplicação do quadro digital foi implementada utilizando tecnologia de Internet
(ficheiros html, cgi e scripts perl) e uma base de dados relacional da Microsoft. Os
utilizadores podem interagir com esta aplicação através de Web browser, uma vez que
esta corre num servidor (Xitami).
Este sistema foi elaborado com o pressuposto que o responsável/facilitador tivesse um
PDA. Os outros participantes poderão usar um PDA ou papel e lápis para escrever as
decisões tomadas na reunião. Terá de haver um PC na sala de reuniões ligada ao quadro
digital partilhado.
O responsável/facilitador pode sincronizar o PDA com o PC, deste modo partilha a
agenda com outros participantes através do quadro digital. Através da lista de tópicos o
responsável tem acesso as questões a debater dos participantes. Os participantes poderão
ter escrito estas questões no seus PDA’s, e nesse caso, poderão sincronizar com o PC, e
apresentar as questões a debater a audiência.
32
O PC organiza as questões a debater e associa a lista de tópicos da agenda. Os
participantes podem inserir as questões a debater directamente no PC.
A qualquer altura o responsável/facilitador podem sincronizar o PDA com o PC e
arranjar uma lista de tópicos e de questões a debater mais actualizada. Para esta lista o
responsável/facilitador pode adicionar decisões tomadas na reunião. Os participantes
podem tirar notas no seu PDA, documentando as decisões e agendamentos relacionados
com as suas tarefas pessoais. Estas notas pessoais são armazenadas na lista de tarefas.
Estas listas poderão ser associadas com a lista de tópicos e as questões a debater
sincronizadas no PC.
33
Outros Estudos na área dos SDG’s:
Alguns estudos têm sido efectuados para avaliar o efeito de múltiplos dispositivos de
entrada em interacções colaborativas e a sua influência no comportamento dos
participantes.
O efeito de dar a cada utilizador um dispositivo de entrada, mesmo que só um de cada
vez possa estar activo, foi estudado, tendo-se e encontrado um melhoria significativa na
aprendizagem [Inkpen et al., 1997]. Resultados preliminares de um estudo em que um
par de estudantes trabalhavam em conjunto utilizando uma arquitectura SDG para
completar uma tarefa de resolução de um problema indicou que esses estudantes,
utilizando dois ratos, apresentaram altos níveis de actividade e menos tempo na
realização da tarefa [Inkpen et al., 1999].
Stewart, Benderson & Druin (1999), investigaram um par de crianças a colaborar na
criação de uma história utilizando uma ferramenta designada Kidpad. As crianças
preferiram a situação de dois ratos tendo estado mais ocupadas na realização das tarefas
e divertindo-se mais.
Stewart et al. (1998) relataram diversos benefícios que observaram na arquitectura
SDG, desde o aumento da colaboração e comunicação, redução dos conflitos e maior
oferta e solicitação de ajuda. Também foi observado que a disponibilidade de um
dispositivo de entrada para cada utilizador, sugere também que nenhum poderá ser
capaz de monopolizar a tarefa [Stewart (1999)].
Diversos estudos utilizaram crianças para comparar o uso de um rato com o uso de dois
ratos [Inkpen et al., 1995; Stewart et al., 1999; Stanton et al., 2002]. Nestes estudos, os
investigadores descobriram que a utilização de múltiplos ratos num único ecrã pode
motivar os utilizadores, apoiar na resolução de problemas com mais sucesso nos
resultados e ajudar os utilizadores a estarem mais concentrados nas tarefas [Stanton et
al., 2002; Stanton et al., 2003].
34
2.5 Análise Comparativa
Integração espaço privado /
público
Sim
Não
Sim
Sim
Sim
Costa
[Costa & Antunes, 2002]
Protótipo de Carlos
[Prante et al., 2003]
Hello.Wall
SharedNotes
[Greenberg et al., 1999]
Notepals
[Davis et al., 1999, 1998]
Remote Control
[Myers, 2001, 1999; Myers et al., 1998]
avaliação
Sistema M-Pad
Critérios de
[Rekimoto, 1998]
Aplicações
Sim
Controlo do espaço partilhado
Não
Sim
Não
Não
Sim
Não
Estrutura de dados
Simples
Não têm
Simples
Simples
Código
Simples
Síncrono
Sim
Sim
Não
Sim
Sim
Não
Tipo de utilização do PDA
Paleta
Periférico
Bloco Notas
Bloco Notas
Periférico
Bloco Notas
Não se
Não se
aplica
aplica
Não
Sim
Escrita directa das
intervenções no conteúdo
partilhado
Não se
aplica
Não
TABELA 2.1 - Análise comparativa de aplicações colaborativas
Pretende-se com esta tabela proceder a uma análise comparativa das diversas aplicações
colaborativas, considerando um conjunto de variáveis seleccionadas, tendo em conta as
abordagens teóricas da literatura colaborativa. Assim, foram escolhidos determinados
critérios (primeira coluna da tabela 2.1) para auxiliar essa comparação.
Através do tabela 2.1 podemos ver que a integração espaço privado/público, é feita por
todas as aplicações à excepção da aplicação Remote Control.
Já relativamente ao controlo do espaço partilhado só o HelloWall e o Remote Control o
fazem.
35
A estrutura dos dados é simples no caso dos sistemas M-Pad, Notepals, SharedNotes e o
Protótipo de Carlos Costa e em código no HelloWall. Por sua vez, o Remote Control
não utiliza estruturas de dados.
Como se pode observar também na tabela, só existe uma aplicação (SharedNotes), que
faz a escrita directa das intervenções no conteúdo partilhado.
O sistema M-Pad é utilizado como paleta pessoal, enquanto os sistemas Remote Control
e o HelloWall são utilizados como periféricos. Os sistemas Notepals, SharedNotes eo
Protótipo de Carlos Costa são utilizados como bloco de notas.
Relativamente ao tipo de comunicação e à excepção do Notepals e do Protótipo de
Carlos Costa, todas as outras aplicações têm uma comunicação síncrona.
Todos os sistemas apresentados na tabela 2.1, possuem algumas características similares
e, como ferramentas de SDG, tentam focar a atenção dos participantes no espaço
público. Cada ferramenta abrange um domínio específico no contexto da interacção
utilizador – espaço partilhado.
Todos estes sistemas partilham bases de dados, onde está armazenada a informação
pública, e disponibilizam um PDA para acções privadas, assim como a criação de
informação que será enviada para repositório central. O uso de PDA’s durante as
reuniões foi considerado disruptivo, mas com o tempo verificou-se que, aparentemente,
os benefícios dados ao sistema (sincronização da informação da reunião) ultrapassam
os custos associados à disrupção [Costa & Antunes, 2002].
Os sistemas, “M-Pad” e “Remote Commander”, têm como dispositivo de entrada o
PDA e ambos permitem que diversos utilizadores interajam colaborativamente. No
entanto, estas aplicações diferem na forma como executam os pedidos, isto é, enquanto
que no sistema do M-Pad, todos os pedidos feitos pelos PDA’s são enviados para o PC e
processados pelo componente M-Draw, no sistema “Remote Commander” existe um
componente no PC, que recebe pedidos e os envia para o sistema operativo processar.
O Remote Commander é mais flexível que o M-Pad, devido ao facto de interagir com
36
qualquer aplicação (exemplo: Office) que esteja activa no PC e não com uma só
aplicação. O primeiro sistema partilha a paleta de ferramentas e a entrada de dados num
quadro digital para personalizar o comportamento de cada um dos vários utilizadores,
enquanto que o segundo partilha o controlo do rato e teclado de um PC, entre múltiplos
utilizadores.
Estes sistemas foram construídos com o objectivo de ultrapassar problemas
relacionados com o uso de quadros digitais, tais como a escrita directa de dados no
quadro, a manipulação de dados, a separação de espaço privado e público e o controlo
da aplicação.
O Notepals e o SharedNotes são sistemas de partilha de notas. O primeiro foi construído
para tirar notas individuais durante as reuniões e mais tarde sincronizar e partilhar
através da Web. Como atrás descrito, a preocupação principal deste sistema é a
integração (de dados dispersos entre organização, reunião, pessoas), ou seja, o
descarregar da informação e a partilha da mesma na fase posterior à reunião. O segundo
sistema, por sua vez, permite tirar notas em qualquer altura e de forma mais legível, já
que no primeiro, as notas são manuscritas. Também permite aos utilizadores
seleccionarem a informação que desejam publicar no espaço público, ou seja, entre
reuniões os participantes podem produzir informação que irão disponibilizar no início
da reunião seguinte.
No SharedNotes os participantes podem ainda ter uma cópia do espaço público no PDA,
mantendo-se uma versão persistente no PC central. Assim, poderão trabalhar em “Off
line” com a versão existente e na reunião seguinte sincronizar os dados. O Protótipo de
Carlos Costa é também um sistema de partilha de notas. No entanto, essa informação
gerada no PDA vai ser integrada numa estrutura de dados do sistema de apoio a
reuniões electrónicas.
O Hello.Wall é um ecrã de grande dimensão que transmite informação utilizando
padrões de luzes, sendo possível a troca de informação legível através do viewport
(PDA).
37
2.6 Ferramenta Proposta
No sistema proposto, designado LightMeet, todos os participantes têm um PDA que
está ligado a um PC (Ponto de Acesso) e para onde enviam informação para ser
apresentada no ecrã público. O facilitador, por sua vez, controla o ecrã e coordena o
grupo. Tanto os participantes como o facilitador interagem via PDA pois este permite
realizar diversas operações como criar, editar, escolher, mover, copiar, colar e apagar
informação. É através deste equipamento que haverá lugar à interacção entre os
membros do grupo, à partilha e gestão da informação, à construção cooperativa de
artefactos digitais e à articulação e organização do grupo. Desta forma, o esforço
individual convergirá em direcção a um objectivo comum e o conflito não irá
incomodar a colaboração.
Durante as reuniões existem diversos processos a correr, tais como tomada de decisão,
acções do facilitador, acções de conflito e acções de aprendizagem. Contudo, o processo
de reunião trata de um conjunto de assuntos discutidos nas reuniões e de actividades
organizadas com um objectivo comum.
O processo de reunião é constituído por três fases (pré-reunião, durante a reunião e pósreunião). Em cada uma delas são desencadeadas actividades, mas só algumas são
apoiadas pelo sistema LightMeet. Na fase de pré-reunião, os utilizadores poderão
definir tópicos e objectivos na estrutura do processo da reunião, onde consta uma pasta
com o nome Agenda. É de referir que esta estrutura tem uma organização hierárquica,
garantindo relação entre tópicos e objectivos.
Durante a sessão de reunião, os participantes irão seguir os tópicos da agenda, e
consoante essa lista poderão executar as seguintes tarefas: construção, organização e
redução sistemática de listas (ideias, comentários, notas, questões, decisões, ...etc.)
através de atribuição de prioridades (prioritização).
Após a sessão da reunião são executadas outras actividades que não são apoiadas pelo
sistema LightMeet.
38
Os PDA’s são utilizados para mediar a colaboração entre aqueles que estão envolvidos
na reunião, o que faz com que a informação trocada nessa reunião e o processo de
tomada de decisão conduzam ao produto final que pode ser gravado, manipulado e
recuperado. Através de uma estrutura de árvore, as relações entre as questões, ideias,
comentários, decisões, pontos de vista e argumentos podem ser explicados e separados.
Desta maneira, o autor não precisa de argumentar e os leitores podem claramente
identificar as ideias, pontos de vista, argumentos, etc. Esta separação e categorização
dos diferentes tipos de contribuições, conduz os participantes a organizarem-se e a
reflectirem sobre a melhor forma de serem claros acerca dos conteúdos que vão criar,
pois será necessário para a categorização e ligação à informação preexistente. Essa
forma de actuar dos participantes melhora a qualidade das contribuições e torna mais
difícil o uso de técnicas não produtivas (a repetição, o uso de retórica para distorcer o
conteúdo, a sofisticação do discurso, etc.), para melhorar a aceitação de um argumento.
Alguns sistemas para salas de reuniões procuram melhorar um tipo especifico de
reunião, através da estruturação das actividades de reunião.
Tal pode melhorar a
qualidade e o número de ideias geradas pelo grupo, embora não sejam criados para
trabalhar com todos os estilos de reunião. O LightMeet, por exemplo, foi criado
especificamente para permitir aos participantes usarem a estrutura que julgarem melhor
para a reunião. Outros sistemas para salas de reunião não tentam estruturar as reuniões,
mas em contrapartida, dão aos participantes novos meios para comunicar e gravar
actividades daquelas.
O LightMeet foi influenciado por projectos como o Remote Commander, o Notepals e o
SharedNotes. Algumas das ideias presentes nesses sistemas como a sincronização, o
hardware de baixo custo, a portabilidade, a partilha dos dados e a separação do espaço
privado do público foram implementadas no LightMeet.
39
Integração espaço
Ferramenta Proposta
[Costa & Antunes, 2002]
Costa
Protótipo de Carlos
Hello.Wall
[Prante et al., 2003]
[Greenberg et al., 1999]
SharedNotes
[Davis et al., 1999, 1998]
Notepals
[Myers, 2001, 1999; Myers et al., 1998]
Remote Control
avaliação
Sistema M-Pad
Critérios de
[Rekimoto, 1998]
Aplicações
Sim
Não
Sim
Sim
Sim
Sim
Sim
Não
Sim
Não
Não
Sim
Não
Não
Estrutura de dados
Simples
Não têm
Simples
Simples
Código
Simples
Síncrono
Sim
Sim
Não
Sim
Sim
Não
privado / público
Controlo do espaço
partilhado
Tipo de utilização do
PDA
Escrita directa das
intervenções no
conteúdo partilhado
Paleta
Periférico
Não se
Não se
aplica
aplica
Bloco de
Bloco de
Notas
Notas
Não
Sim
Periférico
Não se
aplica
Bloco
Notas
Não
Estrutura em
arvore
Sim
Periférico e
Bloco de
Notas
Sim
TABELA 2.2 - Análise comparativa com a ferramenta proposta
As diferenças do sistema LightMeet relativamente às outras aplicações da tabela 2.2
estão na organização, com uma estrutura de dados hierárquica; integração directa das
intervenções no conteúdo na estrutura de dados do sistema de apoio a reuniões
electrónicas, na partilha, apresentação e manipulação da informação numa interface, em
forma de árvore, em que os seus nós contém um objecto onde são guardados os dados.
Existem ainda outras características, que não estão descriminadas na tabela 2.2, e que
diferenciam o sistema LightMeet das outras aplicações:
•
pouca manutenção (apenas o PC que serve de ponto de acesso requer atenção,
pois as estações de trabalho serão os PDA’s pertencentes aos participantes);
•
fácil instalação / manutenção (sincronização com software do fabricante do
equipamento, Palm, Windows CE);
•
40
não necessita de espaço físico dedicado (não é preciso salas com características
especiais para conter o equipamento para as reuniões).
41
2.7 Conclusões
Neste capitulo pretende-se enquadrar as diversas áreas de investigação em que este
trabalho se insere. Começou-se por fazer um enquadramento geral sobre arquitecturas
SDG dentro do contexto de reunião electrónicas, dando mais atenção àquelas que
integravam múltiplos PDA na sua composição. Assim, foi feito um levantamento
detalhado de problemas e soluções identificados por investigadores nesta área. De
seguida, foram descritos vários projectos relacionados com o trabalho proposto nesta
dissertação.
Este capítulo foi concluído com uma analise comparativa dos vários projectos acima
referidos com o trabalho proposto.
Capítulo 3 – Analise de Requisitos
42
Capítulo 3
Análise de Requisitos
3.1 Introdução
Este capítulo encontra-se estruturado do seguinte modo. Em primeiro lugar,
identificam-se os requisitos para o protótipo a realizar e os seus serviços do ponto de
vista do utilizador, fazendo uso de casos de utilização segundo a notação UML. Em
seguida descreve-se graficamente a arquitectura lógica do trabalho proposto.
3.2 Funcionalidades e Restrições
3.2.1 Requisitos Genéricos
Pretende-se que diversas operações de dados estejam disponíveis em simultâneo para os
utilizadores. Os utilizadores deverão poder criar e manipular dados numa estrutura em
árvore que permite organizar as diversas operações dos utilizadores de forma flexível
(ex. criar nós) e estruturada..
O sistema deverá controlar os objectos partilhados por meio de uma interface que
representa a informação organizada em árvore. O utilizador não deve despender muito
tempo para aprender a utilizar o sistema, já que a interface é similar ao explorador do
Microsoft Windows, tornando fácil o primeiro impacto. O objectivo é criar no
participante uma leitura rápida do que é apresentado no ecrã e, ao mesmo tempo,
43
proporcionar uma boa adaptação ao método de manuseamento da informação. Os
PDA’s dos participantes, comunicam de forma contínua e nas duas direcções com o
sistema central, que, por sua vez, projecta no ecrã o produto da interacção, que serve
como ponto de enfoque da reunião. O sistema deverá ainda separar o espaço privado do
espaço público através do tratamento da informação privada no PDA..
3.2.2 Requisitos Técnicos
Este sistema é destinado ao suporte a um grupo restrito de pessoas, constituído por dois
a sete elementos, com intenção de realizar uma reunião, tirando partido das tecnologias
(PC, Projector, PDA) existentes numa sala de decisão e transportáveis pelos
utilizadores, e de fácil e rápida configuração dos meios de apoio.
Pretende-se que o sistema possa ser fornecido como um pacote de fácil instalação e
administração pelo grupo de pessoas que o utilizar. Para o funcionamento do sistema,
será necessário dispor das seguintes características:
O servidor deverá ser executado em qualquer plataforma que suporte as mesmas
especificações da máquina virtual da Sun.
O cliente para PDA deverá executado em qualquer dispositivo que suporte a máquina
virtual da superwaba (Palm OS3, OS4, OS5; Windows CE).
O facto de o sistema trabalhar com dispositivos PDA, que são pequenos e têm recursos
limitados, cria algumas limitações ao nível dos requisitos do utilizador:
•
44
O sistema apenas pode trabalhar com interfaces simples, tais como labels,
campos de texto, botões e menus, devido ao pequeno ecrã (320x320);
•
O sistema série tem algumas limitações, ao nível das comunicações,
considerando
o
número
de
utilizadores
a
usarem
esta
tecnologia
simultaneamente;
•
largura de banda limitada (115,200 bps);
O cliente vai ser desenvolvido em Superwaba e o servidor em Java, de modo a
cumprirem certos requisitos, tais como: a garantia de se poder usar este programa para
diversas plataformas sem a necessidade de ter de compilar novamente (portabilidade); a
não existência de risco de má gestão e alocação de memória no momento de compilação
(segurança).
Na classificação espaço - temporal este sistema classifica-se como mesmo local /
mesmo tempo.
Ao nível da construção do software para apoiar reuniões electrónicas, existem algumas
dimensões fundamentais, tal como em qualquer outro sistema, que se queira considerar
colaborativo. Estas são a comunicação, arquitectura, concorrência, coordenação, espaço
público, monitorização e acesso.
•
O sistema proposto tem os seguintes requisitos com base nas dimensões acima
descritas:

Entre PDA e PC a comunicação é ponto-a-ponto (redes com/sem fios). A
troca de mensagens é feita de forma síncrona.

A
arquitectura
do
sistema
é
centralizada
multi-utilizador,
como
consequência directa da necessidade de partilha de informação por múltiplos
utilizadores, sendo mais fácil se ela estiver centralizada.

45
A informação é manipulada por diversos utilizadores, levantando-se o
problema de preservar a sua coerência. A solução adoptada passa pela gestão
da concorrência através de políticas optimistas, uma vez que as políticas
pessimistas restringem as interacções dos utilizadores, ao não permitir a
manipulação de informação em paralelo e ao obrigarem a utilização de
protocolos de resolução de conflitos, que podem representar atrasos
inaceitáveis pelos utilizadores na manipulação da informação. Nas políticas
optimistas, as alterações dos dados são permitidas livremente a todos os
utilizadores, não existindo nem verificação, nem resolução de conflitos. A
visão por detrás deste mecanismo consiste em tornar as alterações dos dados
visíveis a todos os utilizadores, de modo a que sejam estes a verificar
possíveis conflitos e resolvê-los de forma colaborativa.

O mecanismo de controlo de palco coordena as actividades de uma forma
semelhante à utilizada numa conferência em que os participantes se
encontram face-a-face. A política utilizada para controlo do palco é aberta
(open-floor). Ou seja, os participantes têm livre acesso ao palco, sendo o
controlo exercido socialmente, segundo regras de etiqueta. No entanto,
existem canais de comunicação adicionais (visuais e auditivos), que
permitem interromper, ultrapassar e complementar a gestão exercida pelo
sistema.

O grau de coerência aplicado ao Espaço Público do sistema proposto é o
WYSIWIS (What You See Is What I See). O espaço público apresenta
estritamente a mesma informação a todos os utilizadores. A palavra estrito,
aqui atribui ao espaço público um forte sentido de convergência.

Neste sistema a Monitorização é convergente (tightly coupling), todos os
utilizadores prestam atenção simultânea e focada no mesmo propósito.

O controlo de Acesso dos objectos partilhados do sistema realiza-se
normalmente a partir de especificações dos atributos desses objectos, (por
exemplo visualizar, modificar, mover) e dos respectivos privilégios de cada
utilizador.
46
3.3 Arquitectura Tecnológica do Sistema
Cabo Série(COM1); Cradle;
Bluetooth
interface ODBC
PDA's
PC / Portátil
BD
Cliente
LightMeet
Servidor
LightMeet
PebblesPC
DLL's ou Sockets
FIGURA 3.1 - Esquema da Arquitectura Tecnológica do LightMeet.
Pretende-se que esta arquitectura tenha as seguintes características:
-
permita adoptar o Pebbles, garantindo a entrega fiável das mensagens, a ordem
das mensagens;
-
permita a portabilidade, garantindo que o sistema suporte diferentes sistemas
operativos;
-
permita uma fácil instalação e configuração, garantindo que o cliente e o
servidor tenham tempos reduzidos de instalação e configuração;
-
permite trabalhar com redes com/sem fios, garantindo uma comunicação em
tempo real entre cliente e servidor.
47
3.4 Estrutura de Dados
1
1
Operação
*
1
Filhos
1 .. *
Paternidade
Pai
FIGURA 3.2 – Diagrama de classes da Estrutura de Dados.
A figura 3.2 ilustra um conjunto de associações entre os elementos base da estrutura de
dados do sistema.
A associação existente na classe NÓ é reflexiva porque estabelece relações estruturais
consigo própria, isto, porque a classe NÓ desempenha diferentes papéis (PAI e FILHO).
Um objecto da classe NÓ relaciona-se com um ou mais objectos da mesma classe.
Tipicamente, esta relação surge em situações de hierarquia, sendo neste caso, a classe
NÓ que tem relações de Pai para Filhos com objectos da sua classe.
A associação Operação indica que um objecto da classe Cursor pode operar um objecto
da classe NÓ. Ou seja, a partir de uma instância da classe CURSOR pode-se aceder a
uma instância da classe NÒ.
A classe NÓ não existe fora do contexto da classe REUNIÃO. O objecto da classe
REUNIÃO é responsável pela disposição dos objectos da classe NÓ, ou seja, um
48
objecto da classe REUNIÃO é responsável pela criação e destruição dos seus objectos
da classe NÓ.
A estrutura irá conter a informação gerada durante o processo de reunião. Assim, a
partir do momento em que a estrutura começar a agregar informação resultante das
tarefas (em que se constróem listas) executadas na reunião, o seu desenho terá a forma
de uma árvore – estrutura de dados não linear que caracteriza uma relação de hierarquia
entre dados (nós) que a compõem, ou seja, onde um conjunto de dados se pode
apresentar hierarquicamente subordinado a outro conjunto de dados.
FIGURA 3.3 – Representação gráfica da relação de agregação composta entre as
classes Reunião e Nó.
FIGURA 3.4 – Exemplo de sessão de reunião em que num dos primeiros passos é
identificação dos riscos de expansão da nossa linha de produtos através da geração de
ideias em que a questão é “What are the risks of expanding our product line ?”.
49
50
3.5 Casos de utilização
Actores
Os actores principais numa reunião são o facilitador e os participantes.
O facilitador [Antunes & Costa, 2002] tem um papel neutro, é aceite pelos participantes
da reunião e desempenha um vasto conjunto de funções, tais como: (1) promover o
sentido de compromisso e responsabilidade; (2) demonstrar autoconfiança; (3)
seleccionar e preparar a tecnologia; (4) ouvir, esclarecer e integrar informação; (5)
desenvolver e colocar as questões correctas; (6) manter o grupo focado nos resultados;
(7) criar conforto com a tecnologia; (8) criar uma atmosfera / ambiente aberto e
positivo; (9) construir harmonia e relações no grupo; (10) apresentar informação ao
grupo; (11) demonstrar flexibilidade; (12) planear e desenvolver reuniões; (13) gerir
conflitos e emoções negativas; (14) compreender a capacidade / potencial das
tecnologias; (15) encorajar e apoiar múltiplas perspectivas; (16) dirigir e gerir as
reuniões.
Os participantes intervêm na reunião, produzindo e partilhando vários tipos de
informação tais com ideias e comentários.
O diagrama de pacotes apresentado na Figura 3.3, apresenta uma visão geral do sistema
de software, com dois pacotes de casos de utilização correspondentes aos dois subsistemas propostos. Este diagrama é aqui apresentado para estruturar as descrições das
funcionalidades do sistema na óptica dos seus utilizadores.
51
FIGURA 3.5– Diagrama de pacotes referente ao LightMeet.
Foram definidos dois pacotes principais: o pacote do sub-sistema “cliente”, que contém
todos os casos de utilização que o facilitador e o utilizador participante deverão realizar;
e o pacote do sub-sistema “servidor”, contém todos os casos de utilização que
correspondem apenas ao facilitador, já que é o único que trabalha nesse computador.
52
Cliente e Servidor LightMeet
FIGURA 3.6 – Diagrama de 1º nível de casos de utilização do Cliente e Servidor
LightMeet.
53
3.5.1 Caso de utilização “registar utilizador”.
FIGURA 3.7 – Diagrama de casos de utilização referente ao módulo de registo.
Breve descrição: Registo do utilizador no sistema para que possa utilizar os serviços /
funções disponíveis.
Actor: Facilitador/ Participante.
Pré-condição: Existe ligação estabelecida.
Cenário Principal:
1. O caso de utilização inicia-se quando é apresentado um ecrã a pedir o nome do
utilizador e a senha.
2. O utilizador digita o nome e senha, e assinala se é Facilitador ou Participante.
No fim activa a opção para prosseguir com o registo.
3. O sistema valida a informação inserida pelo utilizador.
4. Se o nome de utilizador for válido, o sistema regista o utilizador na base de
dados de utilizadores.
5. O utilizador tem acesso as funcionalidades do cliente e termina o caso de
utilização.
54
Cenário Alternativo:
No passo 2, em vez de activar a opção prosseguir com o registo, o utilizador cancela o
registo e termina o caso de utilização.
No passo 3, o sistema não valida a informação inserida e retorna ao passo 2 para
correcção.
Pós-condição: O utilizador foi registado.
3.5.2 Caso de utilização “Gerir Itens”.
FIGURA 3.8 – Diagrama de casos de utilização referente ao módulo Gestão de Itens.
A palavra item entende-se por informação útil, enviada pelos utilizadores (ex: ideia,
comentário, nota, questão, solução etc.). Os itens estarão organizados hierarquicamente,
segundo uma árvore lógica. Os cenários de utilização serão explicados seguindo a
terminologia das estruturas de Arvore, em que o item é igual ao nó, em que este nó pode
ou não ter filhos (nós subordinados).
55
Breve descrição: O actor pretende fazer a manutenção, organização ou avaliação de
itens.
Actor: Facilitador / Participante.
Pré-condição: O Facilitador / Participante esta registado e tem acesso ao sistema.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador / Participante decide
seleccionar uma das opções disponíveis no ecrã.
2. Se o utilizador optar por seleccionar a organização de um item, é incluído o caso
de utilização “visualizar / organizar item” (secção 3.5.2.1).
3. Se o Facilitador optar por seleccionar a avaliação de um grupo de itens, é
incluído o caso de utilização “prioritizar item” (secção 3.5.2.2).
4. Se o Participante optar por seleccionar a votação em um item, é incluído o caso
de utilização “votar item” (secção 3.5.2.3).
5. O caso de utilização termina quando a operação escolhida pelo utilizador estiver
dada como concluída.
Cenário alternativo:
1. O sistema falha e termina o caso de utilização.
2. O Facilitador / Participante sai da aplicação e termina o caso de utilização.
3. O Facilitador / Participante solicita ajuda e
retorna ao passo anterior a
interrupção.
Pós-condição: O Facilitador / Participante executa a função pedida ao sistema.
56
3.5.2.1 Caso de utilização “Visualizar / Organizar itens”
Breve descrição: O actor pretende executar uma operação de visualização ou
organização de um (ou mais) itens.
Actor: Facilitador / Participante
Pré-condição: O utilizador está registado e tem acesso ao sistema.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador / Participante decide
seleccionar uma das opções disponíveis no ecrã.
2. Se o Facilitador / Participante optar por seleccionar a manutenção de um item, é
incluído o caso de utilização “manter item” (secção 3.5.2.1.1).
3. Se o Facilitador / Participante optar por seleccionar a opção para visualizar o
item ascendente, é estendido para o caso de utilização “subir de nível” (secção
3.5.2.1.2).
4. Se o Facilitador / Participante optar por seleccionar a opção para visualizar o
item descendente, é estendido para o caso de utilização “descer de nível” (secção
3.5.2.1.3).
5. Se o Facilitador / Participante optar por seleccionar a opção para organizar item,
é estendido para o caso de utilização “mover item” (secção 3.5.2.1.4).
6. Se o Facilitador / Participante optar por seleccionar a opção para copiar item
(que poderá ser uma sub-árvore com vários itens descendentes) para a base de
dados local, é estendido para o caso de utilização “copiar group item” (secção
3.5.2.1.5).
7. O caso de utilização termina quando a operação escolhida pelo o Facilitador /
Participante estiver dado como concluída.
57
1. O sistema fica indisponível e o caso de utilização termina.
2. O Facilitador / Participante sai da aplicação.
Pós-condição: O Facilitador / Participante executa a operação pedida.
3.5.2.1.1 Caso de utilização “manter item”
Breve descrição: O actor pretende executar uma operação de manutenção num item.
Actor: Participante.
Pré-condição: Lista de itens disponível da reunião corrente.
Cenário principal:
1. O caso de utilização inicia-se quando o utilizador decide escolher uma das
operações, entre as opções de criação, alteração ou remoção de item.
2. Se o Participante seleccionar a opção de criação, o caso de utilização incluído é
o “criar item” (secção 3.5.2.1.1.1).
3. Se o Participante seleccionar a opção de alteração, o caso de utilização incluído
é o “alterar item” (secção 3.5.2.1.1.2).
4. Se o Participante seleccionar a opção de remoção, o caso de utilização incluído é
o “remover item” (secção 3.5.2.1.1.3).
5. O caso de utilização termina quando a operação pedida tiver sido realizada.
2. O Participante sai da aplicação e o caso de utilização termina.
Pós-condição: O Participante executa a operação pedida.
3.5.2.1.1.1 Caso de utilização “Criar item”
Breve descrição: O actor pretende inserir um item na reunião.
Pré-condição: Lista de itens disponível da reunião corrente.
Cenário principal:
1. O caso de utilização começa quando o Participante selecciona a opção de criar
item.
2. O sistema apresenta o ecrã a pedir para inserir o item.
3. O Participante digita a informação pretendida e solicita a gravação.
4. O sistema valida o item.
5. O sistema grava o item e apresenta a alteração no ecrã público, adicionando o
item à árvore.
6. O Participante recebe a lista de itens com o novo item e termina o caso de
utilização.
1. No passo 3, em vez de solicitar a gravação, o Participante cancela, terminando
assim o caso de utilização.
2. No passo 4, o sistema não valida o item e retorna ao passo 2.
Pós-condição: O participante criou o item da reunião.
58
59
3.5.2.1.1.2 Caso de utilização “Alterar item”
Breve descrição: O actor pretende alterar o item da reunião.
Actor: Participante
Pré-condição: Item seleccionado na lista de itens disponíveis da reunião corrente.
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção de alterar
item.
2. O sistema apresenta o ecrã com o item a alterar, permitindo a edição do mesmo.
3. O Participante altera o item e solicita a gravação.
5. O sistema grava o item e apresenta a alteração no ecrã público (item alterado na
árvore).
6. O Participante recebe lista de itens com a alteração e termina o caso de
utilização.
1. No passo 3, o Participante pode cancelar e termina o caso de utilização.
2. No passo 4, o sistema pode não validar o item e retorna ao ponto 2.
Pós-condição: O participante alterou o item da reunião.
3.5.2.1.1.3 Caso de utilização “Remover item”
Breve descrição: O actor pretende apagar o item da lista de itens da reunião.
60
Pré-condição: Item seleccionado da lista de itens da reunião corrente.
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção de
apagar item.
2. O sistema apresenta o ecrã a pedir a confirmação de remoção do item
seleccionado.
3. O participante confirma.
5. O sistema remove o item e apresenta a alteração no ecrã público.
6. O Participante recebe a lista de itens sem o item removido e o caso de utilização
termina.
1. No passo 3, o participante cancela e termina o caso de utilização.
2. No passo 4, o sistema não valida o item e termina o caso de utilização.
Pós-condição: O participante apaga o item da reunião.
3.5.2.1.2 Caso de utilização “Subir nível”
Breve descrição: O actor pretende visualizar a lista de itens do nível superior. Ou seja,
deseja visualizar os nós que estão ao nível do nó pai do item seleccionado.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador / Participante selecciona a
opção de subir de nível.
2. O sistema valida a operação.
3. O sistema apresenta a alista de itens do nível superior e termina o caso de
utilização.
Pós-condição: O participante visualiza os itens do nível superior.
3.5.2.1.3 Caso de utilização “Descer nível”
Breve descrição: O actor pretende visualizar os itens do nível inferior. Ou seja, deseja
visualizar os nós filhos do item seleccionado.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador / Participante selecciona a
opção de descer de nível.
2. O sistema valida o item seleccionado.
61
3. O sistema apresenta a lista de itens do nível inferior e termina o caso de
utilização.
1. No passo 2, o sistema não valida o item e o caso de utilização termina.
Pós-condição: O Facilitador / Participante visualiza os itens descendentes do item
seleccionado.
3.5.2.1.4 Caso de utilização “Mover item”
Breve descrição: O actor pretende mover o item para outra posição na estrutura da
árvore.
Pré-condição: Um item seleccionado na lista de itens da reunião corrente.
Cenário principal:
1. O caso de utilização começa quando o Facilitador / Participante selecciona a
opção de mover item.
2. O sistema apresenta o ecrã a pedir a confirmação de mover item seleccionado.
3. O Facilitador / Participante confirma a operação.
5. O sistema solicita o item de destino, permitindo ao Facilitador / Participante
escolher o item de destino.
6. O Facilitador / Participante selecciona o item de destino e submete - o ao
sistema.
7. O sistema move o item seleccionado para o destino pedido.
62
63
8. O Facilitador / Participante recebe a lista de itens actualizada sem o item movido
e termina o caso de utilização
1. No passo 3, o Facilitador / Participante cancela e termina o caso de utilização.
3. No passo 5, o Facilitador / Participante cancela e termina o caso de utilização.
Pós-condição: O item seleccionado é movido para o destino pedido.
3.5.2.1.5 Caso de utilização “Copiar group item”
Breve descrição: O actor pretende copiar um grupo de itens do ecrã público.
Actor: Participante
Pré-condição: Um item seleccionado na lista de itens da reunião corrente.
Cenário principal:
1. O caso de utilização começa quando o Participante selecciona a opção de copiar
group item.
2. O sistema apresenta o ecrã a pedir a confirmação.
3. O Participante confirmam a operação.
5. O sistema guarda o grupo de itens na base de dados local.
6. O Participante recebe a mensagem de cópia de item e o caso de utilização
termina.
64
1. No passo 3, o Participante cancela e termina o caso de utilização.
3. No passo 5, o sistema não copia o grupo de itens e retorna ao passo 2.
Pós-condição: O grupo de itens é copiado para a base de dados local.
3.5.2.2 Caso de utilização “Prioritizar item”
Breve descrição: O actor pretende prioritizar um conjunto de itens.
Actor: Facilitador.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador selecciona a opção prioritizar
item.
2. O sistema apresenta o ecrã para confirmar a operação.
3. O Facilitador confirma.
5. O sistema informa o Facilitador que já está disponível para prioritizar e formata
o ecrã público para esta função.
6. O Facilitador informa os Participantes e termina o caso de utilização.
1. No passo 3, o Facilitador cancela a operação e termina o caso de utilização.
65
Pós-condição: O sistema está disponível para prioritização.
3.5.2.3 Caso de utilização “Votar item”
Breve descrição: O actor pretende votar no conjunto de itens.
Actor: Participante
Pré-condição: O Facilitador informa que o sistema está pronto para a prioritização.
Cenário principal:
1. O caso de utilização inicia-se após o Facilitador informar que já é possível votar
nos itens.
2. O Participante selecciona o item que tem os itens para prioritizar, ficando assim
disponível a lista de itens para votar.
3. O Participante vota cada item da lista.
4. O sistema valida cada votação.
5. O sistema apresenta no ecrã público o somatório das votações por item feito
pelos Participantes.
6. O Participante recebe a lista ordenada de acordo com a votação dos restantes
Participantes e termina o caso de utilização.
1. No passo 2, o Participante não selecciona o item e o caso de utilização termina.
2. No passo 3, se o Participante não votar em todos os itens, os votos não vão
contar para o somatório.
3. No passo 4, o sistema pode não validar uma votação e retorna ao passo 2 para
corrigir.
66
Pós-condição: O Participante visualiza a lista prioritizada.
3.5.3 Caso de utilização “Gerir reunião”
FIGURA 3.9 – Diagrama de casos de utilização referente ao módulo Reuniões.
Breve descrição: O actor pretende fazer a gestão de reuniões.
Actor: Facilitador
Pré-condição: Lista de reuniões disponível.
Cenário principal:
1. O caso de utilização inicia-se quando o Facilitador selecciona uma das opções
disponíveis.
2. Se o Facilitador seleccionar a opção de criação do registo de reunião, é estendido
para o caso de utilização “criar reunião” (secção 3.5.3.1).
3. Se o Facilitador seleccionar a opção de abertura do registo de reunião, é
estendido para o caso de utilização “abrir reunião” (secção 3.5.3.2).
4. Se o Facilitador seleccionar a opção de remoção do registo de reunião, é
estendido para o caso de utilização “remover reunião” (secção 3.5.3.3).
5. Se o Facilitador seleccionar a opção de gravação do registo de reunião, é
estendido para o caso de utilização “guardar reunião” (secção 3.5.3.4).
6. O caso de utilização termina quando a operação escolhida pelo Facilitador
estiver dada como concluída.
Pós-condição: Operação executada na lista de reuniões.
3.5.3.1 Caso de utilização “criar reunião”
Breve descrição: O actor pretende criar registo para a nova reunião.
Actor: Facilitador
Pré-condição: O Facilitador está registado e tem acesso ao sistema.
Cenário principal:
1. O caso de utilização começa quando o Facilitador selecciona a opção de criar
reunião.
2. O sistema apresenta o ecrã a pedir o nome da reunião.
3. O Facilitador insere a informação pedida e submete-a ao sistema.
4. O sistema valida os dados.
5. O Facilitador é informado da validação dos dados e vê a alteração do ecrã
público.
67
68
6. O sistema formata o ecrã público, de modo a apresentar a informação da reunião
sob a forma de àrvore.
7. O sistema cria na árvore um nó agenda e o caso de utilização termina.
1. No passo 2, o Facilitador pode inserir caracteres inválidos e termina o caso de
utilização.
2. No passo 3, o Facilitador pode cancelar a operação e termina o caso de
utilização.
3. No passo 4, o sistema pode não validar os dados e retorna ao passo 2.
Pós-condição: O registo da nova reunião é criado.
3.5.3.2 Caso de utilização “Abrir reunião”
Breve descrição: O actor pretende abrir a reunião.
Actor: Facilitador
Cenário principal:
1. O caso de utilização começa quando o Facilitador selecciona a opção para abrir
reunião.
2. O sistema apresenta o ecrã com a lista de reuniões existentes.
3. O Facilitador escolhe a reunião.
4. O sistema valida a escolha.
5. O Facilitador recebe a mensagem do sistema a indicar que vai abrir a reunião.
6. O sistema mostra no ecrã público com a informação da reunião aberta.
69
7. O sistema formata o ecrã com a estrutura em árvore.
8. O Facilitador recebe a lista com os itens da nova reunião e termina o caso de
utilização .
1. No passo 3, o Facilitador cancela a operação em vez de seleccionar a reunião, e
o caso de utilização termina.
2. No passo 4, o sistema não valida a escolha e reinicializa o caso de utilização.
Pós-condição: Reunião foi aberta e carregada para o ecrã público.
3.5.3.3 Caso de utilização “remover reunião”
Breve descrição: O actor pretende apagar a reunião.
Actor: Facilitador
Cenário principal:
1. O caso de utilização começa quando o Facilitador selecciona a opção para
apagar reunião.
2. O sistema apresenta o ecrã com a lista de reuniões existentes.
3. O Facilitador selecciona a reunião e submete-a para validação.
4. O sistema valida a selecção.
5. O sistema remove a reunião e informa o Facilitador.
6. O Facilitador recebe a lista sem a reunião apagada e o caso de utilização
termina.
70
1. No passo 3, o Facilitador cancela a operação e o caso de utilização termina.
2. No passo 4, o sistema não valida e o caso de utilização é reinicializado.
Pós-condição: A reunião é apagada do sistema.
3.5.3.4 Caso de utilização “gravar reunião”
Breve descrição: O actor pretende gravar a reunião.
Actor: Facilitador
Pré-condição: Reunião aberta.
Cenário principal:
1. O caso de utilização começa quando o Facilitador selecciona a opção de gravar
reunião.
2. O sistema apresenta a mensagem a informar o Facilitador de que foi gravada a
reunião.
3. Termina o caso de utilização com a mensagem do sistema a informar o sucesso
da operação.
1. No passo 2, o sistema informa que não foi gravada a reunião.
Pós-condição: Reunião gravada.
71
3.5.4 Caso de utilização “Gerir agenda”
FIGURA 3.10 – Diagrama de casos de utilização referente ao módulo Agenda.
Breve descrição: O actor pretende fazer a gestão da Agenda da reunião.
Actor: Utilizador
Pré-condição: Reunião aberta.
Cenário principal:
1. O caso de utilização começa quando o utilizador selecciona a opção para gestão
da Agenda.
2. O Facilitador ao escolher esta opção é incluído o caso de utilização “visualizar /
organizar item“(secção 3.5.2.1).
3. O caso de utilização termina quando a operação escolhida pelo Facilitador
estiver dada como concluída.
1. Sistema indisponível e o caso de utilização termina.
72
3.5.5 Caso de utilização “Visualizar item local”
FIGURA 3.11 – Diagrama de casos de utilização referente ao módulo Espaço Privado.
Breve descrição: O actor pretende fazer a gestão da informação privada ”online” ou
”offline”, localizada na base de dados local.
Actor: Participante
Pré-condição: Lista local de itens disponível.
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona uma das opções
disponíveis no ecrã.
2. Se o Participante optar por seleccionar a manutenção de item, é incluído o caso
de utilização “manter item local” (secção 3.5.5.1).
3. Se o Participante optar por seleccionar um item privado para torná-lo público, é
estendido para o caso de utilização “publicar item” (secção 3.5.5.3).
4. O caso de utilização termina quando a operação escolhida pelo Participante,
estiver dado como concluída.
73
1. Sistema falha e o caso de utilização termina.
Pós-condição: executou opção escolhida.
3.5.5.1 Caso de utilização “Manter item local”
Breve descrição: O actor pretende executar uma operação de manutenção dos dados
armazenados na base de dados local.
Actor: Participante
Pré-condição: Lista local de itens disponíveis.
Cenário principal:
1. O caso de utilização inicia-se quando o Participante decide escolher uma das
operações, entre as opções, de adicionar, remover e expandir item.
2. Se o Participante seleccionar a opção de adicionar, é incluído o caso de
utilização “adicionar item” (secção 3.5.5.1.1).
3. Se o Participante seleccionar a opção de remover, é incluído o caso de utilização
“remover item” (secção 3.5.5.1.2).
4. Se o Participante seleccionar a opção de expansão, é incluído o caso de
utilização “expandir item” (secção 3.5.5.1.3).
1. O Sistema falha e o caso de utilização termina.
74
Pós-condição: Operação executada com sucesso.
3.5.5.1.1 Caso de utilização “Adicionar item”
Breve descrição: O actor pretende criar um item na base de dados local.
Actor: Participante
Pré-condição: lista de itens disponíveis
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção adicionar
item.
2. O sistema pede informação sobre o item a inserir.
3. O Participante preenche e activa a opção de confirmação.
4. O sistema valida a informação.
5. O sistema grava item.
6. O sistema mostra a lista com o novo item e termina o caso de utilização.
1. No passo 3, em vez do Participante activar a opção confirmar, activa a opção
cancelar e termina o caso de utilização.
2. No passo 3, o Participante insere caracteres inválidos e termina o caso de
utilização.
3. No passo 4, o sistema não valida a informação e o caso de utilização é
reinicializado.
Pós-condição: O item foi gravado na base de dados local.
3.5.5.1.2 Caso de utilização “remover item”
Breve descrição: O actor pretende apagar um item da base de dados local.
Actor: Participante
Pré-condição: Lista de items disponível.
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção para
apagar item.
2. O sistema pede para escolher o item à apagar.
3. O Participante selecciona o item e activa a opção de confirmação.
4. O sistema verifica o item.
5. O sistema retira o item da lista.
6. O sistema mostra a lista sem o item e termina caso de utilização.
1. No passo 3, o Participante cancela a operação e termina o caso de utilização.
2. No passo 4, o sistema não valida o item e retorna ao passo 2.
Pós-condição: Item removido da base de dados local.
75
76
3.5.5.1.3 Caso de utilização “expandir item”
Breve descrição: O actor pretende visualizar um grupo de itens que está representado
por um item na lista inicial.
Actor: Participante
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção para
expandir item.
2. O sistema pede ao participante para escolher o item.
3. O Participante escolhe o item e submete-o para validação.
5. O sistema mostra o grupo de itens a que pertence o item seleccionado e o caso
de utilização termina.
1. No passo3, o Participante pode activar a opção cancelar, em vez de submeter o
item para validação, e o caso de utilização termina.
2. No passo 4, o sistema não valida o item, por este não ser um item que tem como
descendentes um grupo de itens.
Pós-condição: Ver itens descendentes do item seleccionado
77
3.5.5.2 Caso de utilização “publicar item”
Breve descrição: O actor pretende tornar público um item da base de dados local.
Actor: Participante
Cenário principal:
1. O caso de utilização inicia-se quando o Participante selecciona a opção de
publicação de item privado.
2. O sistema pede ao Participante para escolher o item a publicar.
3. O Participante selecciona o item e submete-o para validação.
5. O Participante visualiza a mensagem de aceitação de item.
6. O sistema mostra o item no ecrã público e envia a lista para o Participante.
7. O sistema remove o item publicado da base de dados local e termina o caso de
utilização.
1. No passo 3, o Participante cancela a operação e o caso de utilização termina.
2. No passo 4, o sistema não valida o item e o caso de utilização retorna ao passo 2.
Pós-condição: Item gravado no sistema central.
78
3.6 Arquitectura lógica do sistema
Nesta secção é apresentada a arquitectura do sistema em quatro camadas: interface com
o utilizador, serviços de comunicação, serviços de reunião e base de dados. Trata-se de
uma arquitectura meramente lógica, porque as diferentes camadas não são
necessariamente implementadas no mesmo componente de software.
FIGURA 3.19 - Diagrama de Componentes.
Neste diagrama de componentes a camada “interface com o utilizador” fornece a
interface com o utilizador para apresentação e recolha de dados. A segunda camada
“serviços de comunicação” faz a gestão das comunicações entre os dois sub-sistemas. A
79
terceira camada “serviços de reunião” engloba as classes que possuem as regras
fundamentais das reuniões. No sub-sistema cliente, a anterior camada só tem algumas
das regras, por isso é chamada “local”. Por fim, a camada “Base de Dados” que permite
manter, actualizar e aceder aos dados persistentes.
80
3.7 Conclusões
Neste capítulo fez-se uma abordagem aos requisitos do sistema, dando ênfase ao
modelo adoptado e apresentou-se uma visão global do, ponto de vista dos utilizadores
do funcionamento do protótipo, recorrendo à notação UML. Através dos diagramas de
casos de utilização e interacção foi possível explicar de forma detalhada as opções
desenvolvidas no protótipo.
No final, foi apresentada a composição lógica da arquitectura do protótipo, com os
diferentes subsistema.
Capítulo 4 - Realização
81
Capítulo 4
Realização
4.1 Introdução
Neste capítulo apresentamos os pormenores do protótipo realizado. O sistema foi
implementado com a linguagem Java para o componente do PC e com a linguagem
Superwaba para o componente móvel (PDA).
O capítulo encontra-se estruturado da seguinte forma: descrição breve dos diversos
utilitários utilizados na implementação do protótipo; descrição da arquitectura do
sistema; outros aspectos relevantes para uma melhor compreensão da sua realização.
4.2 Ambiente de Desenvolvimento
4.2.1 Ferramentas de Desenvolvimento e Teste
•
Superwaba SDK 4.21 [Superwaba Site]
•
Simulador do Palm OS5 [Palm Simulator]
•
Palm OS Emulator 3.5 [POSE]
•
JDK 1.4.1 [JDK]
•
Tauschke MobileCreator Personal 1.7 [IDE]
•
Microsoft Access 2002 [Ms Office Site]
82
4.2.1.1 Superwaba
O programa cliente instalado no PDA foi implementado na linguagem waba [Waba
site]. Esta linguagem não é java, sendo no entanto 99% compatível com a linguagem
Java (o único bytecode não implementado é o synchronized). A máquina virtual waba
não pode ser chamada “Java VM”, por causa das restrições de direitos de autor. Ao
waba original foi adicionado um “packages ext” e melhorada algumas classes, que
acrescentaram várias funcionalidades, passando-se a chamar Superwaba. O Superwaba
é uma plataforma de desenvolvimento de código aberto para PDA’s e telemóveis, criado
em 2000. Para ser utilizada, o programador deverá substituir a API do JDK, pela API do
Superwaba. O kit de desenvolvimento de software consiste numa máquina virtual, numa
biblioteca de classes e diversos utilitários para o programador.
Para suportar um desenvolvimento flexível, a arquitectura Superwaba é modular e
escalável, através da disponibilização da sua máquina virtual optimizada para vários
dispositivos, com diferentes tipos de processadores e com limitações de memória.
A particularidade desta linguagem, quando comparado com outras concorrentes,
prende-se com a possibilidade de utilizar uma plataforma de desenvolvimento sem
custos inerentes.
Durante o desenvolvimento do cliente para o PDA verificou-se que o compilador teve
um bom funcionamento, não tendo sido verificadas limitações durante os trabalhos.
4.2.1.2 Palm OS Emulator 3.5
O emulador do sistema operativo Palm é um software que corre em PC e funciona como
o hardware Palm em todos os pormenores. Consiste em dois componentes: o programa
que simula o hardware e uma imagem do sistema operativo.
Este emulador está
83
limitado até à versão quatro do sistema operativo Palm. Isto é, só é possível verificar a
compatibilidade com o sistema operativo até à versão atrás descrita.
4.2.1.3 Simulator Palm OS5
O simulador para o sistema operativo 5.0 da Palm é o sistema operativo nativo da Palm
compilado para Intel. Não é emulação do hardware como no emulador do sistema
operativo da Palm (POSE - Palm OS Emulator), mas sim, um real sistema operativo da
Palm, funcionando em cima da camada de abstracção do dispositivo (DAL - Device
Abstration Layer).
O núcleo do sistema operativo da Palm, consiste em vários DLL’s de sistema. Como o
sistema operativo está nas DLL’s, o ficheiro da ROM é diferente do utilizado no POSE.
O simulador do sistema operativo da Palm contém um ambiente compatível para
aplicações Palm (PACE - Palm Application Compatibility Environment, que emula
PRC’s de 68K) e por omissão para os vários PRC’s, tais como Datebook e Memopad.
O ambiente de 68K proporcionado pelo PACE é efectivamente idêntico à
funcionalidade suportado pelo sistema operativo 4.1 da Palm.
4.2.1.4 JDK 1.4.1
O JDK é um kit de desenvolvimento para Java que vem acompanhado de diversos
utilitários (exemplo: compilador, interpretador, depurador, etc.) e da biblioteca de
classes (exemplo: interfaces gráficas, imagem e som, redes, etc.).
O Java é uma linguagem de programação orientada por objectos em que as
características principais são a portabilidade, a segurança, a simplicidade, a eficiência e
a concorrência.
84
4.2.1.5 Tauschke MobileCreator Personal 1.7
O MobileCreator é um ambiente integrado de desenvolvimento (IDE - Integrated
Development Enviroment) que foi criado para ser usado com o Superwaba versão 4. A
máquina virtual da Superwaba suporta os sistemas operativos windows 98/NT/2000/XP,
windows CE e o desenvolvimento nativo para Palm.
4.2.1.6 Microsoft Access 2002
O Sistema de Gestão de Base de Dados (SGBD) utilizado para suporte ao modelo de
dados do LightMeet foi o Microsoft Access. O SGBD fornece os mecanismos
necessários para o suporte dos processos colaborativos assumindo não só o papel de
repositório de informações para a memória do grupo, mas também o de intermediário no
armazenamento de informações partilhadas pelos diferentes processos. Para a interface
do Servidor com o SGBD foi utilizado o JDBC (Java Database Connection). O JDBC é
uma interface baseada em Java para acesso a Base Dados relacionais através do SQL.
Esta interface herda do java a portabilidade entre plataformas.
Muitas BD’s não têm controladores nativos JDBC, mas têm para ODBC (Object
Database Connection). Por causa disso, um controlador JDBC para BD ODBC é
fornecido pela Sun e incluído na distribuição Java. Com essa ponte JDBC-ODBC é
possível usar controladores ODBC através do JDBC. Ou seja, este controlador faz a
tradução de chamadas JDBC para chamadas ODBC .
85
4.2.2 Problemas relacionados com o Ambiente de desenvolvimento
Devido a algumas limitações da plataforma de desenvolvimento da Sun J2ME (MIDP
1.0 para Palm OS) [J2ME site], foi necessário mudar a plataforma de desenvolvimento
durante a realização do trabalho. A máquina virtual da Sun para dispositivos Palm, não
suportava:
•
Comunicações com porta de série;
•
Sistema operativo do palm versão 5.0.
86
4.3 Metodologia de Desenvolvimento
Devido aos requisitos não serem totalmente conhecidos no inicio do projecto, ao nível
dos componentes cliente e servidor, existiu uma série de opções em aberto, que foram
sendo preenchidas ao longo do processo, de acordo com as necessidades funcionais
requeridas pelos utilizadores. Por isso, decidiu-se optar por um modelo de processo de
desenvolvimento de software evolucionário - modelo incremental com prototipagem. A
interface com o utilizador foi melhorada sempre que se achou necessário.
4.4 Arquitectura Física do Sistema LightMeet
De seguida pretende-se descrever a arquitectura física do sistema LightMeet, e no
secção 4.5 será detalhadamente descrito o sistema implementado, bem como os seus
componentes. A Figura 4.1 apresenta a arquitectura do sistema LightMeet.
Cliente LightMeet
BD
Espaço Público
Servidor LightMeet PebblesPC
Projector
Ethernet
FIGURA 4.1 - Arquitectura do sistema.
Bluetooth, cabo de
série
87
Esta configuração difere um pouco das tradicionais arquitecturas colaborativas, que
normalmente têm um modelo com múltiplas vistas e centros de controlo (um para cada
utilizador), uma vez que este modelo tem uma vista (espaço público), um centro de
controlo e um modelo partilhado pelos vários utilizadores.
88
4.5 Arquitectura Lógica
O sistema desenvolvido é do tipo cliente / servidor com 4 camadas (4 Tier), ou seja, é
constituído por quatro componentes de software, podendo cada um ser executado em
hardware distinto. Os componentes são:
•
Camada cliente – responsável pela interface entre o utilizador e o sistema; subsistema móvel, para o facilitador e os participantes da reunião portadores de um
PDA;
•
Camada Mediadora – responsável pela gestão das comunicações. Actua como
ponte (Middleware) entre os programas cliente e o prestador de serviços
(servidor);
•
Camada Servidor – responsável pela parte lógica do sistema; sub-sistema SDG,
para o facilitador, acessível através do PC (Servidor LightMeet);
•
Camada Base Dados – responsável pelo armazenamento da informação gerada
durante a reunião.
No secção 4.5.1 será feita uma descrição mais detalhada da camada cliente e servidora
do sistema.
89
4.5.1 Componentes do Sistema
O sistema é constituído por quatro componentes, seguindo a arquitectura “4 Tier”
mencionada anteriormente. A camada do meio, é apresentada na secção 1.1.4, pois não
faz parte da implementação deste protótipo. Nos secção 4.5.1.2 e 4.5.1.3, é descrito a
implementação das camadas periféricas desta arquitectura (Figura 4.2).
FIGURA 4.2 - Componentes do sistema.
90
4.5.1.1 Comunicação
A comunicação entre os componentes é feita utilizando dois tipos de mensagens (Tabela
4.1), as de sistema e as de aplicação. Estas são enviadas através do protocolo de
comunicações TCP/IP. Uma mensagem pode ser enviada para um cliente especifico
(ponto a ponto) ou para todos (difusão). Só o servidor é que envia mensagens para
todos.
Mensagens de Sistema
Descrição
CMD_PEBBLES_NO_MESSAGE
mensagem reservada
CMD_PEBBLES_STARTUP
PebblesPC abriu um porta de serie
CMD_PEBBLES_CHANGE_PLUGIN
para alteração de Plugin
CMD_PEBBLES_ACK_CHANGE_PLUGIN
confirmar alteração
CMD_PEBBLES_NO_ACK_CHANGE_PLUGIN
não confirmar alteração
CMD_PEBBLES_KEEPALIVE
confirmar ligação “online”
CMD_PEBBLES_FLOW_CONTROL
controlo do fluxo de hardware sim/não
CMD_PEBBLES_CHANGE_USERNAME
para alteração do nome
CMD_PEBBLES_RESERVED1
valor reservado
CMD_SOCKET_NEW_USER
novo utilizador
CMD_SOCKET_DONE_USER
saída de um utilizador
CMD_PEBBLES_PLUGIN_NAME
para registo de servidor
TABELA 4.1 - Tipos de mensagens de sistema.
91
Mensagens de Aplicação
Descrição
CMD_CREATE
criar reunião
CMD_OPEN
abrir reunião
CMD_SAVE
guardar reunião
CMD_VIEW
ver lista de itens
CMD_ADD
adicionar item
CMD_CHANGE
alterar item
CMD_DELETE
remover item
CMD_UP
cursor para cima
CMD_DOWN
cursor para baixo
CMD_MOVE
mover item
CMD_DETAILS
detalhe do item
CMD_PUBLISH
publicar item
CMD_PRIORITIZE
permitir prioritizar grupo de itens
CMD_VOTE
votar em item
CMD_COPY_GROUP
copier um grupo de itens
TABELA 4.2 - Tipos de mensagens de aplicação.
92
Todas as mensagens enviadas são alfanuméricas, precedidas de um cabeçalho, como
mostra a Figura 4.3. O conteúdo da mensagem é composto por strings (UTF-8),
precedidas de um campo informando o tamanho da série de caracteres.
FIGURA 4.3 - Formato da mensagem enviada dos clientes para o servidor.
As mensagens de sistema servem para o cliente e o servidor fazerem pedidos aos
serviços disponibilizados pelo mediador. Por sua vez, as mensagens de aplicação
servem para a comunicação entre os clientes e o servidor.
FIGURA 4.4 – Formato da mensagem enviada dos servidor para os clientes.
93
Ligação do Servidor
Inicialmente, para que seja possível qualquer operação neste sistema por parte dos
clientes,
é
necessário
que
o
Servidor
envie
uma
mensagem
(CMD_SOCKET_PLUGIN_NAME) de registo (Figura 4.5).
FIGURA 4.5 - Registo do Servidor.
Com isso, o Servidor fica activo, podendo qualquer cliente ligar-se, utilizando os
serviços disponíveis.
Ligação do Cliente
O Cliente, para dar início à sequência de registo, envia uma mensagem
(CMD_CHANGE_PLUGIN) com o nome do Servidor que se quer ligar. Quando o
registo é feito com sucesso (Figura 4.6), o Mediador envia uma mensagem
94
(CMD_ACK_CHANGE_PLUGIN), ou, caso contrário, envia uma mensagem
(CMD_NO_ACK_CHANGE_PLUGIN) de insucesso.
FIGURA 4.6 - Registo do Cliente.
95
FIGURA 4.7 - Troca de mensagens, necessárias ao estabelecimento da ligação virtual.
96
4.5.1.2 Cliente do PDA
Na Figura 4.8 são apresentadas as classes principais do sistema desenvolvido para PDA.
FIGURA 4.8 - Diagrama de classes do cliente.
Classe MainWindow – é uma classe base da estrutura da linguagem Superwaba. Esta
classe tem que ter uma relação de generalização com uma classe da aplicação (Classe
LightMeet) desenvolvida com esta linguagem.
Classe LightMeet – é a classe responsável pela gestão da interface com o utilizador, e
por todas as operações relacionadas com a recepção e envio de mensagens.
97
Classe Agenda – é a classe responsável pela apresentação da agenda da reunião e
encarregue de todas operações locais para criação, alteração e remoção de dados na
Agenda.
Classe DynaCur – Esta classe está encarregue de todas as operações que vão permitir ao
utilizador navegar por toda a árvore que é mostrada no espaço público, visualizando
apenas um nível da árvore. Também é responsável por aceder à base de dados local e
permitir ao utilizador consultar e publicitar informação gravada.
Classe Login – é classe responsável pelas operações de identificação do utilizador para
acesso ao sistema.
Classe PrivSpace – é responsável por conter todas as operações de acesso e manutenção
da informação nas bases de dados locais. Esta classe vai permitir ao utilizador trabalhar
quando estiver em “off-line” com o sistema. O utilizador poderá criar informação útil
para as reuniões futuras sem que para isso seja obrigado a estar perto do sistema central.
Classe Meeting – Esta classe é responsável por todas as operações relacionadas com a
gestão do arquivo de reuniões.
Classe PebblesHeader – é classe responsável pela formato do cabeçalho da mensagem,
utilizado nas comunicações.
98
Classe PebblesConstants – Esta classe define todos os tipos de mensagens de sistema,
úteis para o protocolo de comunicações.
Classe LightMeetMessages – Esta classe define todos os tipos de mensagens da
aplicação LightMeet, úteis para o protocolo de comunicações.
Classe PebblesInterface – Esta classe é responsável por conter todas as operações
relacionadas com as comunicações com o sistema central.
99
4.5.1.3 Servidor
As classes mais importantes para a implementação do servidor são EasyMeet, MyTool,
Workqueue, LightMeet, MyTree, VOTPanel e elemento. Antes de apresentar a
hierarquia das classes é descreve-se cada uma das classes que constituem o servidor. A
explicação da funcionalidade é complementada com um diagrama de classes,
representada em Unified Modelling Language (UML).
FIGURA 4.9 - Diagrama de classes do servidor.
Classe EasyMeet - é uma classe que irá servir para instanciar a janela principal do
programa. Foi construída com o intuito de permitir juntar a esta classe outros módulos
de ferramentas úteis ao trabalho colaborativo. Contém a função “main” (classe de
suporte).
100
Classe MyTool - é uma classe responsável pela gestão da interface com o Facilitador.
Também é utilizada para alojar uma FILA de tarefas onde são guardados os pedidos dos
utilizadores feito através dos PDA’s. A árvore de informação é instanciada nesta classe.
Classe LightMeet - classe encarregue de todas as operações relativas à gestão das
mensagens enviadas e recebidas no servidor. É responsável pelas operações de acesso e
manutenção da base de dados central.
Classe MyTree - é uma classe responsável pela gestão da informação (nós), informação
essa apresentada em forma de árvore (ex: “Global Meeting Tree”). Esta classe é
utilizada para controlar todo o tipo de operações directas na interface (ex: adicionar,
apagar, mover, drag & drop). São efectuadas várias operações na árvore, devido a
mensagens enviadas pelos módulos do sistema. Existem outras operações (criar grupo,
prioritizar) que quando executadas directamente na interface gráfico do servidor, são da
responsabilidade desta classe desencadear o processo.
Classe VOTPanel - é uma classe responsável por todas as operações relacionadas com a
prioritização de itens. Esta classe é utilizada para a apresentação da interface do
prioritizar de itens, processando votos enviados pelos participantes e mostrando os
resultados da avaliação feita passo a passo. No final, a ordem dos itens estabelecida
nesta ferramenta, irá ser transportada para a árvore geral de dados, criando uma nova
ordem.
101
Classe Elemento - é a classe responsável por conter a informação criada pelos
utilizadores (intervenientes da reunião) e por todas as operações relativas à gestão dessa
mesma informação. Esta classe representa o nó da árvore.
Classe WorkQueue - Esta classe é encarregue de todas as operações relativas à gestão de
uma FILA DE ESPERA existente na classe, utilizada para armazenar mensagens de
tarefas em FIFO, colocadas aqui pela classe LightMeet. Estas mensagens serão
processadas por uma thread existente na classe MyTree.
Classe BasicPlugin - Esta classe é responsável por conter todas as operações
relacionadas com o envio e recepção das mensagens do servidor LightMeet.
Classe Pebbles - Esta classe é responsável por conter a definição de todos os tipos de
mensagens trocadas entre clientes e os servidores (PebblesPC e LightMeet).
102
Diagrama de componentes
FIGURA 4.10 - Diagrama de componentes do servidor.
Este diagrama ilustra os diversos componentes que formam o servidor e as suas relações
de dependência. A divisão é efectuada de acordo com a sua natureza, existindo assim,
oito componentes:

EASYMEET.CLASS – ficheiro que contém o executável do servidor. Depende
do módulo LightMeet.class para poder ser executado.

LIGHTMEET.CLASS – responsável por todas as operações de acesso e
manutenção da informação na base de dados. Também responsável por todas as
operações relativas à gestão de reuniões (criar, abrir, remover). Depende do
componente MyTree.class para gerir a interface com o utilizador (árvore), do
componente VOTPanel.class para gerir a prioritização da informação, do
componente EMSBD.mdb para conter a informação do sistema, do componente
Pebbles.jar para comunicar com o componente Pebbles.exe e do componente
Pebbles.exe para o reencaminhamento de mensagens.

103
MYTREE.CLASS – responsável por todas as operações relacionadas com a
árvore, na interface com o utilizador. Depende do componente Elemento.class,
por este ser a estrutura elementar da árvore (nó).

ELEMENTO.CLASS – responsável pela gestão da estrutura da informação do
nó da árvore.

VOTPANEL.CLASS – responsável por todas as operações relacionadas com a
prioritização de informação.

EMSBD.MDB – responsável por conter toda a informação do sistema.

PEBBLES.JAR – responsável por conter todas as classes (API) necessárias para
comunicar com o componente Pebbles.exe.

PEBBLES.EXE – responsável pelos serviços de reencaminhamento de
mensagens.

JDK VM – responsável por conter as classes necessárias para compilar o código
fonte do programa principal.
104
4.5.1.4 Diagrama de instalação
FIGURA 4.11- Diagrama de Instalação (ou Implantação).
Este diagrama ilustra os diversos componentes de software que deveria existir para a
configuração do sistema LightMeet e as relações de dependência.
No diagrama da Figura 4.21 é mostrado a arquitectura a quatro camadas: subsistema
PDA (onde está o cliente LightMeet); subsistema Servidor (onde está o servidor
105
LightMeet); subsistema Mediador (onde está o PebblesPC.exe) e o subsistema Base de
Dados (onde está a base de dados do sistema EMSBD.mdb).
106
4.6 Funcionamento do Sistema
Para a utilização do sistema LightMeet num contexto de reunião, torna-se necessário
possuir um PDA por utilizador e um PC/Portátil. Este sistema apresenta diversas
funcionalidades indicadas nas especificação de requisitos (Capítulo 3).
A comunicação entre os módulos do sistema é feita de forma síncrona, utilizando uma
filosofia cliente/servidor, em que são usadas as portas (TCP/IP) 4242 e 4343. É
importante referir que o servidor do sistema LightMeet pode assumir em simultâneo
dois papéis distintos: como servidor, ao disponibilizar um conjunto de serviços ao
cliente LightMeet e como cliente, ao invocar métodos noutros servidores (Pebbles e
BD).
Todos os pedidos do tipo consulta feitos pelo cliente são processados instantaneamente
pelo servidor, enquanto que os outros pedidos (do tipo criação, alteração e remoção)
serão colocados numa fila e processados segundo uma ordem FIFO (First In First Out).
FIGURA 4.12 - A interface do cliente, referente ao ecrã principal com menu “Tools”
activo.
107
4.6.1 Funcionamento do Cliente
O cliente LightMeet possui uma forma de funcionamento extremamente intuitiva. A
interface criada para o cliente é constituída por elementos gráficos básicos, tais como
botões, listas e menus. Existem diferentes funcionalidades nesta interface, as quais
dependem do papel do utilizador (Facilitador e Participante). Todas as opções dos
menus estão disponíveis para todos os utilizadores, excepto a opção “Meetings” do
menu Tools, a que só o Facilitador terá acesso.
Após iniciar o cliente, aparecerá uma janela de login através da qual o utilizador se
identificará perante o sistema. A partir deste momento o utilizador visualizará o ecrã
principal, e poderá dar início a utilização do sistema, através das opções disponíveis no
menu da figura anterior (Figura 4.12).
O cliente apresenta no seu menu principal diversas funções que serão apresentadas nas
seguintes secções.
4.6.1.1 Interface Agenda
FIGURA 4.13 - A interface do cliente – visualização dos itens da Agenda (opção Tools
- Agenda).
108
O planeamento e manutenção da Agenda são realizadas através da opção “Agenda”,
acessível através do menu “Tools”, localizado na parte superior do ecrã do PDA.
A Figura 4.13 apresenta uma lista de tópicos da Agenda, num controlo designado por
ListBox, que é precedido de um pedido feito ao servidor em virtude da selecção da
opção Agenda.
Após apresentação da lista, o utilizador poderá iniciar a gestão de itens da Agenda,
utilizando os botões disponíveis na Figura 4.13. Estes botões serão utilizados nos vários
ecrãs deste cliente, com a mesma designação e função, mas em contextos diferentes,
sendo fácil a sua utilização ao longo do programa. Os botões disponíveis são:
subir de nível;
descer de nível;
adicionar item;
remover item;
alterar item;
mover item;
ver detalhes sobre o item.
Deste modo, torna-se possível definir os tópicos e objectivos da reunião, com a ajuda
dos botões da figura 4.13.
109
4.6.1.2 Interface Dynamic Cursor
FIGURA 4.14 – A interface do servidor, referente à visualização da árvore geral da
reunião.
A informação da botão
“details” aparece aqui
FIGURA 4.15 – A interface do cliente – visualização dos itens da Árvore Geral da
reunião (opção Tools - Dynamic Cursor - Viewport).
110
O objectivo do ecrã da figura 4.15 é a navegação, na árvore global da reunião, pelo
espaço de itens existente. Isto é, através desta selecção (opção “Dynamic Cursor”), o
utilizador vai ter a possibilidade de navegar por toda a árvore (excepto no item Agenda)
e visualizar apenas um nível da hierarquia da mesma, em cada operação. Este ecrã vai
ter todos os botões atrás referidos no ecrã da gestão da Agenda, mais os que
seguidamente serão explicados:
permite ao Facilitador prioritizar um grupo de itens,
só o Facilitador tem acesso a este botão;
permite aos Participantes votar num item, só os
Participantes é que votam;
permite aos utilizadores copiar um grupo
de itens para a base de dados local.
FIGURA 4.16 – A interface do cliente – visualização dos itens da base de dados local
(opção Tools - Dynamic Cursor - Private).
111
O ecrã “Dynamic Cursor” tem disponível dois sub-ecrãs, o “viewport”, que já foi atrás
explicado, e o “private” que permite trabalhar com itens da base de dados local (espaço
privado) e transportá-los ou, melhor dizendo, publicá-los, na árvore geral da reunião
(espaço público). No ecrã “Private Space” será explicado a gestão dos itens da base de
dados local.
A figura 4.16 apresenta dois botões novos, o primeiro com o nome “PUBLISH”, em que
o utilizador poderá pressionar para publicar o ITEM seleccionado, pertencente à base de
dados local. Esta função será utilizada sempre que o utilizador precisar de enviar
informação
privada para o espaço público. E o segundo botão tem o nome de
“EXPAND”, e permite visualizar um “group item”, ou seja, um item que tem nós
subordinados (foi copiado do espaço público).
4.6.1.3 Interface Meetings
Após a selecção da opção do menu “Tools – Meetings”, um novo ecrã aparecerá no
visor do PDA, com uma lista de reuniões gravadas, que somente o Facilitador poderá
aceder.
O ecrã seguinte faz a gestão de reuniões, podendo o Facilitador (utilizador autorizado)
criar novas reuniões, abrir e apagar reuniões já existentes.
112
FIGURA 4.17 – A interface do cliente – visualização das reuniões gravadas (opção
Tools - Meetings).
A figura 4.17 apresenta dois novos botões que vão permitir realizar as seguintes
operações:
permite ao Facilitador criar reuniões;
permite ao Facilitador abrir reuniões.
confirma após inserção de dados.
113
4.6.1.4 Interface Private Space
FIGURA 4.18 – A interface do cliente – ecrã referente à base de dados local (opção
Tools – Private Space).
A figura 4.17 apresenta o ecrã da opção “Tools – Private Space”, que vai permitir ao
utilizador trabalhar com os itens copiados do servidor para a base de dados local e gerar
nova informação, que poderá ou não, ser enviada para o servidor, consoante a opção do
utilizador.
114
4.6.2 Funcionamento do Servidor
Para executar o servidor do sistema LightMeet, é preciso activar a opção “connect”, o
que implicará realizar as ligações necessárias para o programa funcionar. A interface do
servidor será projectada ou visualizada num grande ecrã (espaço público), o qual
permitirá focar a atenção dos participantes no assunto em discussão. Esta interface é
bastante simples e intuitiva.
FIGURA 4.19 - A interface do Servidor, módulo referente a administração do software.
A figura 4.19 apresenta o ecrã inicial do servidor do sistema LightMeet, designado por
“Admin of ...”. Esta interface terá na parte superior um controle (ComboBox), que
permitirá ver uma lista de reuniões gravadas e dará a possibilidade de criar um nova
115
reunião se for essa a vontade do Facilitador. Na parte inferior do ecrã terá uma área
(Client Message Pool) onde serão mostradas todas as mensagens enviadas pelos
Participantes ao servidor. Essa informação irá para um ficheiro de log. O Facilitador, ao
abrir / criar a reunião através do controle “ComboBox”, despoletará o aparecimento de
dois novos ecrãs com o nome de “Global Meeting Tree” e “Agenda”.
O ecrã “Global Meeting Tree” apresenta a árvore com informação partilhada por todos
aqueles que participam na reunião. A disposição dos itens na árvore facilita a interacção
dos utilizadores com o sistema, evitando mecanismos de interacção complexos, que
requeiram longa aprendizagem.
FIGURA 4.20 - A interface do Servidor, módulo referente à árvore da reunião.
Este interface procura distribuir os itens (informação) na forma de uma árvore lógica,
garantindo uma fácil interpretação e facilitando a interacção com a informação. A
árvore dá aos participantes uma clara visão de como os nós (informação) estão
relacionados entre si. A estrutura inicial da árvore, tem sempre duas pastas, uma é a
116
“Meeting” que é a raiz da árvore, e a outra é a “Agenda” que está num nível inferior, no
qual os seus filhos serão tópicos da agenda.
A árvore geral da reunião terá embutida na estrutura as várias contribuições dos
Participantes ao conteúdo partilhado, de forma a alcançar um objectivo comum. No
conteúdo da árvore estará: a definição do problema, os critérios para avaliar as soluções,
as causas do problema, as soluções alternativas, os métodos de avaliar as soluções
alternativas, a escolha da melhor solução, o plano de acção e a avaliação dos resultados.
O Facilitador com a ajuda do menu pop-up, poderá executar várias operações na árvore,
tais como arrastar itens, mover para cima e para baixo, apagar e adicionar item,
prioritizar itens (figura 4.21) e criar vistas parciais da árvore (figura 4.22).
FIGURA 4.21 - A interface do Servidor, módulo referente a Agenda.
A Figura 4.20 apresenta o ecrã “Agenda”, que vai conter apenas os nós filhos do ramo
Agenda da árvore geral da reunião, pois o seu objectivo é mostrar os tópicos da Agenda,
117
não misturando com a restante informação da reunião e garantindo assim, clareza nos
passos a seguir, segundo a lista de tópicos.
FIGURA 4.22 - A interface do Servidor, vista parcial da árvore da pasta “To minimize
the risks”.
FIGURA 4.23 - A interface do Servidor, vista da tabela de votos preparada para receber
a votação na lista de itens da pasta “Business Risks” .
118
4.7 Conclusões
Este capítulo teve a preocupação de descrever os pormenores da implementação do
trabalho proposto, que se baseia num modelo de dados centralizado.
De início, enumeraram as escolhas dos utilitários do ambiente de desenvolvimento e os
problemas surgidos no decorrer deste processo. Para concretizar o protótipo, escolheram
duas linguagens de programação. A primeira foi a linguagem Java, devido a ser uma
linguagem com excelentes bibliotecas para o desenvolvimento de aplicações em rede. A
segunda foi a linguagem Superwaba por ser uma linguagem de código aberto e por
cumprir os requisitos técnicos definidos anteriormente.
Em seguida, descreveu-se a arquitectura do sistema por componentes, para isso foram
utilizados diagramas de classe, diagramas de componentes e diagramas de instalação
para esmiuçar a implementação.
Finalmente apresentou-se genericamente a funcionalidade da aplicação através de
diversas imagens das suas interfaces.
Capítulo 5 – Avaliação
119
Capítulo 5
Avaliação
Neste capítulo, pretende-se apresentar uma avaliação preliminar do sistema LightMeet.
Para aferir da usabilidade e funcionalidade do sistema LightMeet, foram utilizados, em
três fases, dois grupos distintos de utilizadores com diferentes perfis (informáticos e não
informáticos).
Foi seguida uma metodologia experimental para avaliar o sistema, utilizando
questionários, com uma escala nominal de medição.
5.1 Introdução
No âmbito da avaliação do sistema, foram utilizados dois grupos de utilizadores que
realizaram um “caso prático”, seguido de um questionário de vinte e cinco perguntas e
um questionário de duas perguntas.
Foram utilizados os seguintes recursos nas duas reuniões electrónicas.
Recursos Materiais
¾ 1 Portátil Pentium IV – 2800 Mhz com 512 de Ram com sistema operativo
Microsoft Windows 2000;
¾ 6 PDA Tungsten T com sistema operativo 5.0 da Palm;
¾ 1 Retroprojector ;
¾ A versão do Superwaba SDK é 4.5b (PDA);
120
¾ A versão do Java SDK 1.4.1;
¾ Hardware e Software Bluetooth (Conceptronic).
Recursos Humanos
¾ cinco participantes - Grupo A - utilizadores que não são profissionais de
informática (não informáticos);
o um licenciado em economia (seis anos de experiência em gestão
financeira);
o uma licenciada em gestão (três anos de experiência bancária);
o uma licenciada em gestão de recursos humanos (um ano de experiência
recursos humanos);
o uma licenciada em educação infantil (cinco anos de experiência em
leccionar);
o uma administrativa (quatro anos de experiência em gestão de stocks).
¾ seis participantes - Grupo B - utilizadores que são profissionais de informática
(informáticos);
o três licenciados em informática (dois com seis anos e um com sete anos
de experiência em desenvolvimento);
o dois licenciados em informática de gestão (seis anos de experiência em
desenvolvimento);
o uma licenciada em matemática (seis anos de experiência em análise de
sistemas).
¾ um facilitador (autor), comum ás duas experiências.
121
o licenciado em informática (quatro anos de experiência em
desenvolvimento, seis anos em administração de sistemas e nenhuma
como facilitador)
Os elementos destas experiências foram escolhidos por conveniência.
O objectivo destas experiências foi descobrir o grau de satisfação dos utilizadores finais
do sistema, num ambiente de reunião parecido com o real.
Antes de dar início às experiências, foi feita uma sessão de apresentação aos
utilizadores, que se baseou num enquadramento no contexto “reuniões electrónicas” e
na explicação do funcionamento do sistema LightMeet. Esta sessão durou
aproximadamente trinta minutos.
O tema da reunião foi a identificação riscos envolvidos na criação de uma empresa de
reparação de equipamento informático doméstico. A ordem de trabalhos foi definida
previamente.
Na primeira experiência havia cinco participantes (Grupo A), cujo perfil era de não
informáticos e um facilitador. Esta sessão durou aproximadamente noventa minutos.
Na segunda experiência havia seis participantes (Grupo B), em que o perfil era de
informáticos e um facilitador. . Esta sessão durou aproximadamente noventa minutos.
Após os participantes tomarem conhecimento do conteúdo da agenda, deu- se início à
discussão dos tópicos da agenda. Em ambas as experiências, houve sugestões para que
os tópicos da agenda fossem revistos. No entanto,
para não prolongar o tempo da reunião, optou-se por manter a ordem de trabalhos, uma
vez que a prioridade era a utilização do maior número de funcionalidades do sistema.
122
O objectivo principal da experiência era obter um "feedback" dos participantes acerca
da utilização do sistema.
Na ordem de trabalhos constavam vários tópicos sobre o tema a debater, do qual se
queriam sugestões para posterior decisão. Um dos tópicos que mais informação gerou,
foi "a identificação dos riscos de negócio". Foi então criada uma lista de riscos, que teve
de ser categorizada e, posteriormente, escolhido um critério de prioridades para os
riscos.
Ao facilitador coube a função de desempenhar dois papéis na reunião. O primeiro como
especialista de software e o segundo como condutor da reunião. No primeiro papel (fase
inicial da reunião), verificou se o sistema LightMeet e o sistema sem fios estavam
ambos activos, para que o registo dos participantes fosse aceite. No segundo, interveio
durante a reunião forçando tarefas, mantendo o grupo focado no tema em discussão,
encorajando e apoiando várias perspectivas.
Após cada experiência, foi realizado um questionário de vinte e cinco perguntas onde os
participantes deram a sua opinião, com uma resposta de concordo (se concorda de forma
geral com a afirmação), discordo (se discordar com a afirmação de forma geral) ou
indeciso (se não consegue pronunciar-se, ou se a afirmação não tiver nenhuma
relevância para o software em causa ou para a sua situação). Cada participante foi
submetido ao questionário criado com base num outro questionário de cinquenta
perguntas padrão do SUMI (Software Usability Measurement Inventory) .
O SUMI é um questionário disponível comercialmente, para obter a opinião de
utilizadores finais de um software. O SUMI é um questionário padrão desenvolvido e
validado especificamente, para dar uma indicação exacta de qual a área da usabilidade
que deverá ser melhorada. Foi testado na indústria (é um padrão De Facto)
e
mencionado no ISO-9241 como um método de medição da satisfação do utilizador. O
questionário consiste em cinquenta perguntas, no qual cada utilizador final responde se
concorda ou não, ou se está indeciso. Apenas doze utilizadores são necessários para ter
uma precisão adequada da análise, mas é possível obter resultados satisfatórios,
recorrendo a poucos utilizadores.
123
O questionário para este estudo foi criado com suporte no SUMI, o qual é constituído
por cinco grupos de perguntas, que são características de medição da usabilidade,
nomeadamente:
-
Eficiência (Efficiency) – capacidade do sistema de resolver problemas de forma
rápida e económica; grau de apoio do sistema que os utilizadores sentem no seu
trabalho;
-
Afecto (Affect) – capacidade do sistema interagir amigavelmente com os seus
utilizadores; reacção emocional do utilizador ao sistema;
-
Utilidade (Helpfulness) – capacidade do sistema de resolver ou ajudar a resolver
problemas para o qual o sistema foi proposto; grau em que o sistema é autosuficiente; Documentação adequada;
-
Controlo (Control) – capacidade do sistema para responder de uma forma
natural e consistente aos comandos e entradas de dados fornecidos; O grau pelo
qual os utilizadores sentem o controlo do sistema;
-
Facilidade de Aprendizagem (Learnability) – capacidade de um utilizador atingir
rapidamente um grau de proficiência elevado; a facilidade que os utilizadores
sentem ao conseguir comandar o sistema.
Com base nestas cinco características foram escolhidas cinco perguntas para cada
grupo, entre as cinquentas existentes do SUMI, criando assim o questionário que foi
entregue a cada participante no fim da reunião, em que teria de responder de acordo
com uma escala nominal, em que os nomes foram “concordo”, “indeciso” e “discordo”.
Após responderem a esse questionário, foi distribuído um outro questionário com
perguntas abertas, em que se pediam os aspectos negativos e positivos do sistema, o
qual foi entregue a alguns dos utilizadores mais críticos do sistema.
124
O método mais eficaz e fiável seria fazer a análise dos dados do questionário SUMI
pelo software SUMISCO, mas uma vez que seria dispendiosa a aquisição do software,
foi escolhido um método simples e económico de testar a satisfação dos utilizadores do
sistema LightMeet, através do processamento e análise dos dados criados pelos
utilizadores das experiências, de uma forma linear, sem ponderações, e apenas
quantificar o número de respostas nas três opções disponíveis e analisá-las juntamente
com as respostas às questões “Aspectos Negativos e Positivos”.
125
5.2 Resultados
Os resultados finais do preenchimento do inquérito foram compilados no sentido de se
obter um valor percentual aproximado por cada característica de medição de
usabilidade. Devido à escassez de tempo dos participantes, foi possível apenas analisar
uma sessão por grupo.
Grupo A
Concordo
Indeciso
Discordo
Facilidade de
Aprendizagem
76 %
20 %
4%
Controlo
80 %
16 %
4%
Utilidade
80 %
16 %
4%
Eficiência
80 %
16 %
3,64 %
Afecto
96 %
4%
0%
TABELA 5.1 - Percentagens das respostas do Grupo A.
25
20
15
Concordo
Indeciso
10
Discordo
5
0
L
C
H
E
A
Legenda: L – Facilidade de Aprendizagem; C – Controlo; H – Utilidade; E – Eficiência; A – Afecto.
FIGURA 5.1 - Gráfico referente ao número de respostas dadas pelo Grupo A.
126
Após leitura e tratamento das respostas dadas pelos inquiridos do grupo de não
informáticos, constatou-se o seguinte:
•
Em relação a Facilidade de Aprendizagem, concordaram em76% das perguntas,
20% responderam que estavam indecisos e 4% discordaram com as perguntas.
•
Em relação ao Controlo, concordaram em 80% das perguntas,
16%
responderam que estavam indecisos e 4% discordaram com as perguntas.
•
Em relação a Utilidade, concordaram em 80% das perguntas, 16% responderam
que estavam indecisos e 4% discordaram com as perguntas.
•
Em relação a Eficiência, concordaram em 80% das perguntas,
16%
responderam que estavam indecisos e 3,64% discordaram com as perguntas.
•
Em relação a Facilidade de Aprendizagem, concordaram em 96% das perguntas,
4% responderam que estavam indecisos e 0% discordaram com as perguntas.
Grupo B
Favorável
Indeciso
Não Favorável
Facilidade de
Aprendizagem
63,33 %
30 %
6.67 %
Controlo
53,33 %
43,33 %
3,33 %
Utilidade
30 %
60 %
10 %
Eficiência
46,67 %
50 %
3,33 %
Afecto
73,33 %
20 %
6,67 %
TABELA 5.2 - Percentagens das respostas do Grupo B.
127
25
20
15
Concordo
Indeciso
10
Discordo
5
0
L
C
H
E
A
FIGURA 5.2 - Gráfico referente ao número de respostas dadas pelo Grupo B.
Observando as percentagens das respostas do grupo B, nota-se que a resposta Favorável
já não está em maioria, para todas as características. Provavelmente, por este grupo estar
em vantagem sobre o outro, uma vez que está por dentro desta área, possa fazer uma
avaliação mais crítica ao sistema. Daí estarem mais indecisos no que diz respeito à
Utilidade e Eficiência do mesmo, 60% e 50% respectivamente. No entanto, há uma
clara concordância do grupo de que o sistema é de fácil aprendizagem e controlo, tendo
também uma boa reacção emocional.
128
Resultados Agregados: Grupos A + B
Concordo
Indeciso
Discordo
Facilidade de
Aprendizagem
69,9 %
25,45 %
5,45 %
Controlo
65,45 %
30,91 %
3,64 %
Utilidade
48,33 %
36,67 %
15 %
Eficiência
61,82 %
34,55 %
3,64 %
Afecto
83,64 %
12,73 %
3,64 %
TABELA 5.3 - Percentagens das respostas globais (A + B).
50
40
30
Concordo
Indeciso
20
Discordo
10
0
L
C
H
E
A
FIGURA 5.3 - Gráfico referente ao número de respostas globais (A + B).
A tabela 5.3 e o gráfico da figura 5.3 apresentam os resultados obtidas no inquérito
efectuado pelos participantes das duas experiências.
De uma forma geral, a maioria dos inquiridos concordou com as afirmações feitas, para
cada uma das características apresentadas na tabela. Qualquer uma delas, mostra que
mais de metade não tem qualquer dúvida relativamente às afirmações, excepto no que
129
diz respeito à característica utilidade. É que da análise das respostas da utilidade,
constatou-se que 48,33% foram concordantes, 36,67% foram discordantes e as restantes
foram indecisas.
Comentários aos Resultados
•
Os dados obtidos pelo grupo A em cada característica de medição, indicam uma
aceitação elevada, podendo dizer que a generalidade dos participantes mostrou
satisfação na utilização do sistema.
•
Da análise aos dados do grupo B, verificou-se que determinadas áreas da
usabilidade devem ser melhoradas, uma vez que a indecisão nas características
utilidade, eficiência e controlo é bastante elevada.
•
Na agregação dos resultados dos grupos A e B as opiniões negativas (discordo,
indecisos) são diluídas pelas opiniões positivas (concordo). Ou seja, as
características controlo e eficiência deixam de ter o significado que tinham nos
gráficos do grupo B, ficando apenas a utilidade a ter uma percentagem
significativa.
130
As frases descritas nas secções “aspectos negativos” e “aspectos positivos” são dos
participantes.
Aspectos Negativos
-
Quando um participante insere um item num grupo, não se indica que é um novo
item, ou seja, não existe indicação do que será um item a discutir ou que pode já
ter sido discutido, simplesmente aparece e pode não ser notado; Aparenta ser
vulnerável a maus utilizadores;
-
Questões mais complexas dão origem a uma estrutura hierárquica de pontos a
analisar, bastante complicada. A aplicação não está apta a simplificar este tipo
de questões;
-
Os utilizadores ficam algo perdidos no desenrolar das fases da reunião;
Aspectos Positivos
-
Permitir focalizar o assunto em discussão na reunião, dado que os tópicos estão
organizados por itens de discussão;
-
Os participantes são convidados a reflectir sobre cada item e a inferir sobre um
conjunto especifico de itens, proporcionando pontos de referência (dinâmicos)
de discussão;
-
Aspecto geral simples e claro;
-
Permite ter um visão global dos tópicos da reunião de maneira simples;
-
Boa apresentação;
-
Fácil utilização e compreensão;
-
Útil para ultrapassar questões simples;
-
Facilidade de utilização nos PDA’s;
-
Comunicação rápida entre PDA-SERVIDOR;
131
132
5.3 Discussão dos Resultados
Na generalidade o sistema, funcionou correctamente e corresponde às expectativas dos
participantes. Verificou-se apenas uns pequenos problemas com a utilização do PDA,
pelo facto de alguns dos participantes não estarem familiarizados com o equipamento,
justificando assim, o atraso no começo da reunião .
Nos resultados do grupo A, o nível de satisfação das características de usabilidade foi
bastante elevada, ficando as outras duas opções de resposta (“discordo” e “indeciso”)
com pouco significado.
No grupo B foram identificados valores altos na resposta correspondente à indecisão,
em três características de usabilidade, fazendo-nos ver a existência de problemas na
utilidade, controlo e eficiência. No entanto, não é conclusivo que tais existam. É que,
embora se possa com base nos aspectos negativos se possa deduzir que hajam
problemas, o resultado elevado na resposta “indeciso” é pouco claro quanto à
interpretação a dar, uma vez que a resposta não é quantitativa e engloba um grande
intervalo entre o “concordo” e o “discordo”. Tal vai implicar que o participante opte
pela resposta “indeciso”, por esta ser a mais próxima do “concordo” ou do “discordo”.
Uma mudança para uma escala de medição ordinal garantiria uma resposta mais fácil de
interpretar, podendo esta ter várias categorias (ex. resposta de 1 a 10).
Também um maior número de experiências poderia estabelecer as causas dos valores
elevados na resposta “indeciso”. Desta forma, seria possível ver e identificar as
relações de causa/efeito, uma vez que a estatística com base nas amostras torna-se mais
precisa quando a amostra é grande.
Os dois grupos de utilizadores escolhidos para as experiências, foram criados por
conveniência, tendo em conta que um dos perfis era de profissionais de informática e o
outro não, sem no entanto se considerar as consequências destas escolhas. Por vezes, em
experiências deste tipo, não é possível tirar conclusões válidas, pois os efeitos causados
pelo sistema não se conseguem distinguir dos efeitos de outros factores (objectividade,
imparcialidade, cepticismo, etc.) alheios ao estudo. São factores que embora não tenham
133
interesse para o estudo, influenciam os resultados . A mistura de efeitos causados por
factores externos à experiência, levam a interpretações erradas dos resultados.
Após esta avaliação preliminar, há necessidade de efectuar-se um estudo mais detalhado
sobre as perguntas, onde através das respostas obtidas nessa avaliação inicial, se possa
reformular as questões e adaptá-las ao tipo de software. Desta forma, obter-se-ia um
maior grau de fiabilidade e confiança, através da descida das percentagens das respostas
“indeciso”.
Estas observações são relevantes e sustentam a necessidade de um maior número de
experiências, de uma escolha aleatória de participantes e de uma reformulação das
perguntas.
É necessário a reformulação das condições de realização das experiências, uma vez que
estas podem condicionar os resultados.
134
5.4 Conclusão
Relativamente aos resultados dos inquéritos dos participantes dos dois grupos, as
respostas obtidas para as diversas questões colocadas foram de um modo geral boas. No
entanto, face às elevadas percentagens obtidas, poder-se-á inferir a existência de
eventuais factores externos (objectividade, imparcialidade, cepticismo, etc.) que
poderão ter influenciado os resultados apresentados nas tabelas 5.1 , 5.2 e 5.3.
Capítulo 6 – Considerações Finais
135
Capítulo 6
Considerações Finais
Neste capítulo serão feitas algumas considerações sobre o trabalho desenvolvido e serão
resumidos os resultados obtidos e os contributos principais. Será ainda referido algum
trabalho futuro por forma a melhorar as lacunas existentes no actual protótipo.
6.1 Conclusão
A abordagem principal nesta dissertação é o apoio computacional a pequenos grupos,
em reuniões electrónicas com PDA, em situações face-a-face, numa configuração SDG
em que os participantes, portadores de PDA, interagem com um artefacto de
apresentação/visualização que é o ponto de enfoque do grupo.
Esta dissertação procura soluções para dois problemas relacionados com: integração do
PDA na arquitectura SDG e a redução dos factores de risco da sustentação dos sistemas
de apoio a reuniões electrónicas.
A solução para estes problemas, que é proposta nesta dissertação, baseia-se no
desenvolvimento de um protótipo (LightMeet). Este tem as seguintes características:
fácil instalação; pouca manutenção; não necessita de espaço físico dedicado; não
necessita de equipamento dedicado; portabilidade; simplicidade na interface de forma a
dispensar o recurso a facilitadores (tecnológo).
Para efectuar este trabalho, fez-se uma retrospectiva de trabalhos relevantes nesta área,
com particular relevo para aqueles que tinham na sua configuração múltiplos PDA’s.
Nestes são dados diversos exemplos de aplicações práticas de configurações SDG, em
diversos domínios. Com esta dissertação demonstrou-se a aplicabilidade prática da
configuração em reuniões electrónicas, isto é, estudou-se aplicação prática de um
136
sistema composto basicamente por múltiplos dispositivos de entrada e um artefacto de
visualização.
Foram enumerados problemas e soluções por investigadores que implementaram
sistemas similares ao proposto nesta dissertação. No seguimento foi feita uma análise
comparativa com os projectos atrás mencionados e o sistema proposto.
Os requisitos do sistema foram apresentados através de diagramas de casos de utilização
e de forma textual, tanto os requisitos funcionais (na óptica dos utilizadores) como os
requisitos técnicos.
O protótipo é baseado na filosofia cliente / servidor. O cliente é executado no PDA, no
qual possui uma interface simples e de fácil interpretação. Este envia pedidos de
operações para serem executados no servidor. O servidor é executado num PC / Portátil,
e está dependente do PebblesPC e da base de dados que poderão ser executadas no
mesmo hardware. A interface em forma de árvore do servidor, foi criada
especificamente para permitir aos Participantes criarem a estrutura que julgarem melhor
para a reunião. Assim deste modo, os Participantes irão entender claramente a relação
ente os nós (dados) criados durante as intervenções efectuadas nas reuniões. A
organização da árvore vai naturalmente separar e categorizar as diferentes contribuições
dos intervenientes.
Durante a implementação foram escolhidos diferentes utilitários para auxiliarem na
realização do trabalho proposto. O protótipo foi desenvolvido em Java e Superwaba, e
toda a sua modelação foi feita em UML, de modo a detalhar o sistema por meio de
diagramas, tornando mais fácil a sua leitura e interpretação.
A avaliação do sistema LightMeet demonstrou a usabilidade deste sistema em todas as
sub-caracteristicas de usabilidade. Considera-se que apesar do principal objectivo desta
dissertação ter sido atingido, há muito trabalho que pode ser desenvolvido no futuro,
137
nomeadamente ao nível da expansão das funcionalidades que serão descritas na secção
6.2.
138
6.2 Trabalho Futuro
Após as vária fases desta dissertação, verificou-se que o sistema necessita as seguintes
alterações :
•
adicionar uma ferramenta para fazer relatórios na fase da pós reunião;
•
converter o cliente do PDA para applet, e permitir que o servidor aceite pedidos
http, de forma a reduzir o tempo de instalação / manutenção;
•
adicionar ferramenta para tratar ficheiro de log das mensagens enviadas pelos
participantes, para análise pós-reunião;
•
colocar mais controlo na aplicação;
•
escolher uma plataforma mais flexível, para que seja possível alterar código;
•
melhorar as interfaces com o utilizador.
Capítulo 7 - Apêndice
139
Capítulo 7
Apêndice
7.1 Questionários
1) Questionário de 25 perguntas adaptado do SUMI.
Respostas possíveis: “concordo”, “indeciso”, “discordo”.
Os inquiridos responderam ao questionário de 50 afirmações do SUMI, e dentro dessem
lote foram escolhidas as 25 afirmações mais adequadas ao contexto.
A05 - Ao princípio é complicado aprender a utilizar o software.
A10 - Leva algum tempo até se aprender os comandos do software.
A25 - Tem de se ler muito antes da utilização do software.
A35 - È difícil aprender novas funções.
A50 - Na maioria das vezes, necessito de ajuda para a utilização do software.
A01 - A resposta do software as entradas de texto é muito lenta.
A09 - Se o software bloqueia não é fácil a sua reinicialização.
A14 - Sinto-me mais seguro se utilizar apenas comandos ou funções conhecidas.
A19 - Sinto- me à vontade quando uso este software.
A44 - É relativamente fácil movermo-nos de uma tarefa para outra.
A03 - As instruções e prompts são úteis.
A06 - Por vezes não sei o que fazer a seguir com o software.
A14 - Não existe informação suficiente no ecrã quando é necessário.
A19 - O software ajudou-me a ultrapassar alguns problemas que tive durante a sua
utilização.
A44 - È fácil fazer com que o software realize exactamente aquilo que queremos.
A11 - Por vezes, questiono- me se estou a utilizar os comandos certos.
A21 - Julgo que o software não é consistente.
A26 - As tarefas podem ser executadas de forma sequencial através do software.
A29 - A velocidade do software é razoavelmente rápida.
A36 - Para que as coisas funcionem são necessários muitos passos.
A07 - Agradou- me a sessão com este software.
A13 - A forma como a informação é apresentada é clara e compreensível.
A23 - Eu entendo e reajo à informação dada por este software.
A42 - O software tem uma apresentação atractiva.
140
A47 - Este software é muito desadequado.
2) Questionário de 2 perguntas abertas
1 - Aspectos negativos do sistema ?
2 - Aspectos positivos do sistema ?
7.2 Respostas ao 1º questionário
Dados em bruto
Informáticos e Não Informáticos
Questões concordo
indeciso
discordo
A05:
A10:
A25:
A35:
A50:
1
1
1
0
0
1
1
1
4
7
9
9
9
7
4
A01:
A09:
A14:
A19:
A44:
0
0
1
8
9
1
6
6
2
2
10
5
4
1
0
A003:
A06:
A18:
A28:
A39:
7
0
1
4
8
4
5
6
5
2
0
6
4
2
1
A11:
A21:
A26:
A29:
A36:
1
1
6
10
0
6
4
5
1
3
4
6
0
0
8
A07:
A13:
8
10
3
0
0
1
141
A23:
A42:
A47:
9
11
1
2
0
2
0
0
8
142
Não Informático
Questões concordo
indeciso
discordo
A05:
A10:
A25:
A35:
A50:
0
0
1
0
0
1
0
0
1
3
4
5
4
4
2
A01:
A09:
A14:
A19:
A44:
0
0
1
5
5
0
1
3
0
0
5
4
1
0
0
A03:
A06:
A18:
A28:
A39:
5
0
0
4
5
0
2
2
0
0
0
3
3
1
0
A11:
A21:
A26:
A29:
A36:
1
0
4
5
0
1
1
1
0
1
3
4
0
0
4
A07:
A13:
A23:
A42:
A47:
5
5
5
5
0
0
0
0
0
1
0
0
0
0
4
143
Informático
Questões concordo
indeciso
discordo
A05:
A10:
A25:
A35:
A50:
1
1
0
0
0
0
1
1
3
4
5
4
5
3
2
A01:
A09:
A14:
A19:
A44:
0
0
0
3
4
1
5
3
2
2
5
1
3
1
0
A03:
A06:
A18:
A28:
A39:
2
0
1
0
3
4
3
4
5
2
0
3
1
1
1
A11:
A21:
A26:
A29:
A36:
0
1
2
5
0
5
3
4
1
2
1
2
0
0
4
A07:
A13:
A23:
A42:
A47:
3
5
4
6
1
3
0
2
0
1
0
1
0
0
4
Capítulo 8 - Referências
144
Capítulo 8
Referências
[3M Meeting, 1994] The 3M Meeting Management Team with Jeannine Drew (1994).
Mastering meetings. New York, NY: McGraw Hill and Minnesota Mining &
Manufacturing Co.
[Ambiente] Projecto Ambiente. http://www.ambient-agoras.org/. Acesso em 2004.
[Antunes, 2002] Antunes, P., 2002. “Groupware: Conceitos Fundamentais e
Caracterização dos Principais Blocos Construtivos”. Relatório Técnico. November.
[Antunes & Costa, 2002] Antunes, P. & Costa, C., 2002. “A descriptive framework for
electronic meeting systems based on the UML language”, Faculdade de Ciências da
universidade de Lisboa, June.
[Apple site] Apple. http://www.apple.com. Acesso em 2002.
[Bellucci & Zeleznikow, 1988] Bellucci, E. & Zeleznikow, J., 1998. “A Comparative
Study of Negotiation Decision Support Systems“. Proceedings of the Thirty-First
145
Annual Hawaii International Conference on System Sciences, Vol. 1, p.254, January
06-09.
[Bluetooth site] Bluetooth. http://www bluetooth.com. Acesso em 2002.
[Bostrom et al., 1993] Bostrom, R., Anson, R., & Clawson, V., 1993. “Group
facilitation and group support systems”. Jessup and Valacich (editors), Group Support
Systems: New Perspectives. Macmillan.
[Bostrom & Anson, 1992] Bostrom, R. & Anson, R., 1992. "The Face-to-Face
Electronic Meeting: A Tutorial,". Computer Augmented Teamwork: A Guided Tour,
Bostrom, R.P., Watson, R.T., and Kinney S. (eds.), Van Nostrand Reinhold, pp. 16-33.
[Bostrom et al., 1991] Bostrom, R., Anson, R. & Clawson, V.,
1991. "Group
facilitation and group support systems" Department of Management; University of
Georgia; Working Paper.
[Briggs et al., 2003] Briggs, R.O., Vreede, G. J. & Nunamaker, J., 2003. “Collaboration
Engineering with ThinkLets to Pursue Sustained Success with Group Support
Systems”.Journal of Management Information Systems, Vol. 19, No. 4, Spring, pp. 31 –
64.
[Burbeck, 1992] Burbeck, S., 1992. “Applications Programming in Smalltalk-80TM :
How to use Model-View-Controller (MVC)”. ParcPlace Systems, Inc.
146
[Costa & Antunes, 2002] Costa, C. & Antunes, P., 2002. "Handheld CSCW in the
Meeting Environment". Lecture Notes in Computer Science, vol. 2440, pp. 47-60,
Groupware: Design, Implementation and Use, J. Haake and J. Pino, Eds. Berlin:
Springer-Verlag.
[Costa, 2001] Costa, C.M.J., 2001. “Integração Organizacional de Resultados de
Reuniões”. 219f. Tese (Doutor em Ciências e Tecnologias da Informação), ISCTE,
Lisboa.
[Costa et al., 1999] Costa, C., Antunes, P., & Dias, J., 1999. “GDSS: Limitações e
Oportunidades”. Instituto Superior Técnico, Outubro.
[Davis et al., 1999] Davis, R.C., Landay, J.A., Chen, V., Huang, J., Lee, R. B., LI, F. C.,
Lin, J., Morrey III, C. B., Schleimer, B., Price, M. N. & Schilit, B. N., 1999. “NotePals:
Lightweight Note Sharing by the Group, for the Group,” Proceedings of CHI ’99:ACM
Conference on Human Factors in Computing Systems, Pittsburgh, PA, May, pp. 338–
345.
[Davis et al., 1998] Davis, R.C., LIN, J., Brotherton, J.A., Landay, J.A., Schilit, B.N. &
Price, M.N., 1998. "A Framework for Sharing Handwritten Notes," Proceedings of
UIST '98, pp.119-120, 1998.
[Desanctis & Gallupe, 1987] Desanctis, G. & Gallupe, R., 1987. "A Foundation for the
study of group decision support systems". Management Science; Vol. 33; No.22; pp.
589-609.
147
[Dubs & Hayne] Dubs, S. & Hayne, S., 1992. "Distributed Facilitation: A Concept
Whose Time Has Come?"; CSCW 92 Proceedings; November; pp. 314-321.
[Druin et al., 1997] Druin, A., Stewart, J., Proft, D., Bederson, B. B. & Hollan, J. D.,
1997. “KidPad : A Design Collaboration Between Children, Technologists, and
Educators. In : Proceedings of Human Factors in Computing Systems (CHI 97) ACM
Press, pp. 463-470.“
[Ellis et al., 1991] Ellis, C.A., Gibbs, S.J. & Rein, G.L., 1991. “Groupware Sime issues
and Experiences”. Communication of the ACM, Vol. 34, Nº 1, pp. 38-58, January.
[Fjermestad, 2000] Fjermestad, J., 2000. “An Analysis of Communication Mode in
Group Support Systems Research“.
Information System Department. School of
Management. New Jersey Institute of Tecnology, Newark,
[Fjermestad & Hiltz, 1998] Fjermestad, J. & Hiltz, S.R., 1998. “An Analysis of the
Effects of Mode of Communication on Group Decision Making“. Proceedings of the
Thirtieth Annual Hawaii International Conference on System Sciences, 1, 17-26.
[Goldberg, 1984] Goldberg, A., 1984. “Smalltalk-80. The Interactive Programming
Environment”. Addison-Wesley.
[Greenberg et al., 1999] Greenberg, S., Boyle, M. & Laberge, J., 1999. “PDAs and
Shared Public Displays: Making Personal Information Public and Public Information
Personal“, Personal Technologies, v.3, n.1, pp.54-64.
148
[Groupsystems] Groupsysytems. http://www.groupsystems.com. Acesso em 2002.
[Haarsteen et al., 1998] Haarsten, J., Allen, W., Inouye, J., Joeressen, O.J. &
Naghshineh, M., 1998. “Bluetooth: Vision, Goals, and Arquitecture“. ACM Mobile
Computing Communication. (Rev. 2,4), pp. 38-45, October.
[IDE] Ambiente integrado de desenvolvimento. Tauschke MobileCreator.
http://www.tauschke.com/products/tauschkemobilecreator/index.html. Acesso em 2003.
[Inkpen et al., 2000] Inkpen, K.M., Mandryk, R.L. & Scott, S.D., 2000. “The EDGE of
face-to-face
collaborative
technology“.
CSCW
2000
Workshop
on
Shared
Environments to Support Face-to-Face Collaboration. Philadelphia, USA, December.
[Inkpen et al., 1997] Inkpen, K., Booth, K. S., Klawe, M. & Mcgrenere, J., 1997. “The
Effect of Turn-Taking Protocols on Children’s Learning in Mouse-Driven Collaborative
Environments. In : Proceedings of Graphics Interface (GI 97) Canadian Information
Processing Society, pp. 138-145.
[Interspace] Projecto Interspace.
http://www.ipsi.fraunhofer.de/ambiente/english/projekte/projekte/interspace.html.
Acesso em 2004.
[J2ME site] Java 2 Micro Edition. http://java.sun.com/j2me/. Acesso em 2002.
149
[J2SE] O Kit de desenvolvimento para Java. http://java.sun.com/j2se/. Acesso em 2004.
[Konsynski & Nunamaker, 1984/85] Konsynski, B.R. & Nunamaker, J.F., 1984/85.
PLEXSYS-84: An integrated development environment for information systems.
Journal of Management Information Systems, Vol. 1, No. 3, pp. 63-104.
[MouseSite, 1968] The MouseSite.
http://sloan.stanford.edu/MouseSite/1968Demo.html
[Ms Office Site] Microsoft Access 2002. http://office.microsoft.com/pt-pt/default.aspx.
Acesso em 2002.
[Myers, 2001] Myers B.A., 2001. “Using Handhelds and PCs Together”.
Communication of the ACM, Vol. 44, Nº 11, pp. 34-41, November.
[Myers, 1999] Myers B.A., 1999. "An Implementation Architecture to Support SingleDisplay Groupware," Carnegie Mellon University School of Computer Science
Technical Report, CMU-CS-99-139 and Human Computer Interaction Institute
Technical Report CMU-HCII-99-101.
[Myers et al., 1998] Myers B.A., Stiel, H. & Gargiulo, R., 1998. “Collaboration Using
Multiple PDAs Connected to a PC”. In : Proceedings of the Conference on Computer
Human Interaction (CHI), 1998, Seattle.
150
[Munkvold & Anson, 2001] Munkvold, B.E. & Anson, R., 2001. ”Organizational
adoption and diffusion of electronic meeting systems: a case study”. Proceedings of
Group’01, Boulder, CO, October, 279-287.
[Nunamaker et al., 1997] Nunamaker, J., Briggs, R., Mittleman, D., Vogel, D. &
Balthazard, P., 1997. "Lessons from a dozen years of group support systems research: A
discussion of lab and field findings" Journal of Management Information Systems; Vol.
13; No. 3.
[Nunamaker et al., 1991] Nunamaker, J., Dennis, A.R., Valacich, J.S., Vogel, D.R. &
George, J.F., 1991. “Electronic Meeting Systems to Support Group Work”.
Communication of the ACM, Vol. 34, Nº 7, pp. 40-61, July.
[Palm] Palm, Inc. http://www.palm.com. Acesso em 2002.
[Palm Simulator] Simulador do Palm. http://www.palmos.com/dev/tools/simulator/.
Acesso em 2004.
[Pebbles] Projecto Pebbles. http://www.cs.cmu.edu/~pebbles/. Acesso em 2002.
[Pederson et al., 1993] Pederson, E. R., Mccall, K., Moran, J. P. & Halasz, F. G., 1993.
“Tivoli : An Electronic Whiteboard for Informal Workshop Meetings. In : Proceedings
of human factores in computing systems (Inter CHI93) ACM Press, pp. 391-398.
151
[POSE] Emulador do Palm. http://www.palmos.com/dev/tools/emulator/. Acesso em
2004.
[Psion] Psion. http://www.psion.com. Acesso em 2002.
[Rekimoto Site] Página Pessoal do Jun Rekimoto.
http://www.csl.sony.co.jp/person/rekimoto.html. Acesso 2004.
[Rekimoto,1998] Rekimoto, J., 1998. “A Multiple Device Approach for Supporting
Whiteboard-based Interations”. In :
Proceedings of the Conference on Computer
Human Interaction (CHI’98), Los Angeles, pp.344-351.
[Rekimoto, 1997] Rekimoto, J., 1997. “Pick-and-Drop : A Direct Manipulation
Technique for Multiple Computer Environments”. In : Proceedings of UIST97, October,
Banff, Alberta, Canada.
[Shoemaker, 2001] Shoemaker, G. B. D., 2001. “Single Display Groupware research in
the year 2000”. Technical Report TR 2001-1. Simon Fraser University. April.
[Superwaba Site]
Linguagem de desenvolvimento. http://www.superwaba.com/.
Acesso em 2004.
[Stefik et al., 1987-1992] Stefik, M., Tatar, D., Bobrow, D., Foster, G. & Lanning, S.,
1987-1992.
Projecto
Colab.
Acesso em 2002.
http://www2.parc.com/istl/members/stefik/colab.htm.
152
[Stewart et al., 1999] Stewart, J., Bederson, B. B. & Druin, A., 1999. "Single Display
Groupware: A Model for Co-present Collaboration," Proceedings of ACM CHI'99,
pp.286-293.
[Streitz et al., 1997] Streitz, N. A., Rexroth, P. & Holmer, T., 1997. “Does "roomware"
matter?”. Investigating the role of personal and public information devices and their
combination in meeting room collaboration. In: Proceedings of the European
Conference on Computer-Supported Cooperative Work (E-CSCW'97). Lancaster, UK,
September 7-11, Amsterdam, NL, Kluwer Academic Publishers, 1997. pp. 297 - 312
[Streitz et al., 1998] Streitz, N., Konomi, S., & Burkhardt, H. (Ed.). “Cooperative
Buildings - Integrating Information, Organization, and Architecture”. Proceedings of
CoBuild '98, Darmstadt, Germany, LNCS Vol. 1370, Heidelberg, Germany, Springer,
1998. pp. 4-21.
[Tang et al., 2001] Tang, J.C. , Yankelovich, N., Begole, J., Kleek, M. V., LI, F. &
Bhalodia, J., 2001. ”ConNexus to Awarenex: Extending awareness to mobile users”. In:
Proceedings of the Conference on Computer Human Interaction (CHI), Seattle.
[Vreede, 2003] Vreede, G., Davidson, R.M. & Briggs, R.O., 2003. “How a Silver Bullet
may lose its Shine”. Communication of the ACM, Vol. 46, Nº 8 , pp. 96-101, August.
[Waba site]
153
[Weatherall & Nunamaker, 2000] Weatherall, A. & Nunamaker, J.; (2000). “Getting
Results with Electronic Meetings”. 3. ed. Southampton: Electronic Meeting Solutions
Limited, 166p.
[Widerg, 2001] Wiberg, M., 2001. “RoamWare: An Integrated Arquitecture for
Seamless Interation In between Mobile Meetings”. In :
Proceedings of the 2001
International ACM SIGGROUP Conference, Boulder, Colorado.