Instituto de Engenharia de Sistemas e Computadores de Coimbra
Institute of Systems Engineering and Computers
INESC – Coimbra
Francisco Antunes, Manuel Paulo Melo e João Paulo Costa
O Collaboration Studio
como ferramenta de apoio à colaboração em grupo
No. 19 2004
ISSN: 1645-2631
Instituto de Engenharia de Sistemas e Computadores de Coimbra
INESC - Coimbra
Rua Antero de Quental, 199; 3000-033 Coimbra; Portugal
www.inescc.pt
O Collaboration Studio como ferramenta de apoio à colaboração em
grupo
Francisco José Peixeiro Antunes Universidade da Beira Interior, Departamento de Gestão e Economia, Covilhã, Portugal
INESC Coimbra [email protected]
Manuel Paulo Albuquerque Melo
Faculdade de Economia da Universidade de Coimbra, Coimbra, Portugal INESC Coimbra [email protected]
João Paulo Faria de Oliveira e Costa
Faculdade de Economia da Universidade de Coimbra, Coimbra, Portugal INESC Coimbra [email protected]
Resumo
A presente comunicação apresenta um sistema de apoio à decisão em grupo (SADG), implementado com base no modelo DOC2, bem como um exemplo do seu funcionamento prático. Este sistema, o Collaboration Studio, permite, de forma fiável, o acesso, utilização e definição de uma estrutura de informação, através de mecanismos transparentes para os seus utilizadores, cuja localização geográfica e temporal pode ser distinta. O sistema implementa um mecanismo para utilização síncrona e assíncrona e proporciona um ambiente apelativo e de fácil utilização, permitindo ratificar o modelo DOC2 como um modelo válido para a estruturação de aplicações distribuídas, com utilização de diferentes tipos de sincronismo.
Palavras chave: Sistemas de apoio à decisão em grupo; sistemas distribuídos; modelo DOC2.
1 Introdução Esta comunicação apresenta a utilização prática de uma ferramenta computacional, enquadrada dentro dos genericamente designados sistemas de apoio à decisão em grupo (SADG), implementada com base no modelo DOC2 (para mais detalhes sobre o modelo veja-se [Aleixo, 2000]). Para facilitar o apoio a tarefas de grupos, nomeadamente as de nível um e nível dois [DeSanctis e Gallupe, 1987], têm sido desenvolvidas algumas ferramentas computacionais. Porém, os casos em que os utilizadores podem estar em locais geograficamente distintos, bem como aqueles em que a utilização do sistema não tenha de ser efectuada de forma síncrona, exigem ferramentas distintas das normalmente utilizados nos SADG para apoiar grupos que reúnem face-a-face.
Para implementar num SADG mecanismos de apoio ao grupo (desde a interacção básica até à possivelmente complexa análise de modelos) é necessário desenvolver algumas estruturas internas. Como os dados manipulados pelo sistema estão frequentemente armazenados em bases de dados, a sua utilização directa pelo agente de decisão pode ser difícil e eventualmente perigosa para a integridade global da informação. No entanto, para limitar esta necessidade de referenciar directamente os dados armazenados, é possível criar uma camada semântica por
cima dos dados, isolando o utilizador dos pormenores associados ao seu armazenamento e gestão [Melo e Costa, 2001].
Atendendo ao referido, tentou implementar-se num primeiro trabalho [Lopes, 1999], um modelo de informação suportado por bases de dados relacionais e um sistema computacional que o utilizasse. Nesta primeira fase surgiu o modelo DOC, que suportou a elaboração do sistema AGAP - Aid to Groups of Analysis and evaluation of Projects. Apesar da estrutura DOC atingir parcialmente os seus objectivos, apresentava alguns problemas principalmente em interacções mais complexas [Melo e Costa, 1999; 2001]. Os problemas encontrados conduziram a investigação para a análise de sistemas de objectos distribuídos, na procura de um sistema mais fiável e genérico, procurando-se então um novo modelo teórico, assente em programação orientada a objectos, que utilizaria uma infra-estrutura de objectos distribuídos como o CORBA - Common Object Request Broker Agent, ou o DCOM - Distributed Component Object Model.
Esta nova abordagem deu origem a um novo modelo que usa objectos distribuídos como base para a armazenagem persistente de informação, mantendo as capacidades de alteração e controlo das acções comuns, tendo sido alterada a infra-estrutura DOC por uma estrutura dinâmica, composta por objectos com funções similares aos DOC originais. Neste modelo, cada um destes novos objectos é designado por DOC2. Esses objectos gerem um pacote de informação e também o controlo de acesso e versionamento, permitindo estruturas mais complexas e informação procedimental [Melo e Costa 1999; 2001].
O Collaboration Studio [Antunes, 2002] é um sistema informático destinado a apoiar grupos, estando assente numa arquitectura distribuída (utilizando a tecnologia CORBA) e programação orientada a objectos. Está consubstanciado numa aplicação que actua como servidor, executando tarefas de memória de grupo, e em postos de trabalho locais, tendo sido desenvolvido em Delphi 5 for Windows da Borland. Utilizou-se o ORB (Object Request Broker) Visibroker, para a implementação de serviços CORBA, pois este software vem incorporado nos elementos para instalação do Delphi 5.
Nesta comunicação apresenta-se o Collaboration Studio através de um exemplo prático de utilização: a discussão sobre a necessidade de estruturar um processo de decisão acerca do número de computadores pessoais a instalar nos gabinetes dos docentes de uma dada universidade, para uma subsequente proposta de aquisição de equipamento. Ressalva-se, porém, que não se pretende neste artigo chegar a quaisquer conclusões finais sobre o problema em causa. O objectivo é demonstrar a utilização do sistema.
Embora os sistemas de colaboração não sejam algo de novo, o sistema apresentado nesta comunicação implementa mecanismos inovadores capazes de proceder à estruturação de dados, de modo a que a rede de informação gerada ao longo das discussões de colaboração seja facilmente percebida pelos seus utilizadores. O sistema implementado permitiu revelar as capacidades dos objectos DOC2 para a gestão e armazenamento da informação, bem como das suas ligações ou relacionamentos, revelando facilidade e flexibilidade de programação, tanto em situações de utilização síncrona, como nos casos de utilização assíncrona. Este sistema permite, de forma fiável, o acesso, utilização e definição de uma estrutura de informação, através de mecanismos transparentes para os seus utilizadores, cuja localização geográfica pode ser distinta. A aplicação permite também a utilização síncrona e assíncrona e proporciona um ambiente apelativo e de fácil utilização.
Todavia a aplicação informática não deverá ser observada como um sistema óptimo alcançado, mas sim como um primeiro passo para a implementação de sistemas de colaboração mais evoluídos, baseados no modelo DOC2, eventualmente com mais e melhores capacidades de apoio a grupos distribuídos como, por exemplo, a incorporação de sistemas de votação, ou de métodos quantitativos de apoio à decisão [Antunes et al., 2002].
Na secção dois apresenta-se uma descrição geral das funcionalidades do Collaboration Studio, enquanto que na secção três mostra-se o funcionamento da aplicação através de um exemplo concreto de colaboração. Na secção quatro apresentam-se considerações finais acerca do Collaboration Studio.
2 Descrição geral do Collaboration Studio O Collaboration Studio [Antunes, 2002] é um sistema informático destinado a apoiar grupos, estando assente numa arquitectura distribuída (utilizando a tecnologia CORBA) e programação orientada a objectos. Está consubstanciado numa aplicação que actua como servidor, executando tarefas de memória de grupo, e em postos de trabalho locais, tendo sido desenvolvido em Delphi 5 for Windows da Borland. Utilizou-se o ORB (Object Request Broker) Visibroker, para a implementação de serviços CORBA, pois este software vem incorporado nos elementos para instalação do Delphi 5.
Como suporte à persistência da informação seleccionaram-se duas soluções, ambas sob a forma de bases de dados relacionais. A primeira, o SQL Server 7.0, destina-se à gestão e armazenamento central da informação global gerada pelos diferentes utilizadores, sendo utilizada pela aplicação central. A segunda é o Microsoft Access (versão Microsoft Office 2000) que assegura a persistência de informação ao nível local.
A ligação e acesso do sistema, tanto na unidade central, como nos postos locais de trabalho são efectuados através de ADO (ActiveX Data Objects), que é um interface de programação desenvolvido pela Microsoft, para permitir ao programador o acesso a bases de dados, quer estas sejam propriedade da Microsoft, quer de outras empresas. O ADO é um interface elaborado para a programação orientada a objectos, facilitando o trabalho do programador no que concerne ao acesso a bases de dados [Teixeira e Pacheco, 2000].
Embora os sistemas de colaboração não sejam algo de novo, o sistema apresentado nesta comunicação implementa mecanismos inovadores capazes de proceder à estruturação de dados, de modo a que a rede de informação gerada ao longo das discussões de colaboração seja facilmente percebida pelos seus utilizadores. O sistema implementado permitiu revelar as capacidades dos objectos DOC2 para a gestão e armazenamento da informação, bem como das suas ligações ou relacionamentos, revelando facilidade e flexibilidade de programação, tanto em situações de utilização síncrona, como nos casos de utilização assíncrona. Este sistema permite, de forma fiável, o acesso, utilização e definição de uma estrutura de informação, através de mecanismos transparentes para os seus utilizadores, cuja localização geográfica pode ser distinta. A aplicação permite também a utilização síncrona e assíncrona e proporciona um ambiente apelativo e de fácil utilização.
O sistema desenvolvido permite discussões entre um conjunto de participantes que contém um coordenador. Tal coordenador é inicialmente o utilizador que cria a discussão, existindo a possibilidade de executar posteriormente a transferência da coordenação para um outro participante. Se um qualquer utilizador quiser aceder ou participar numa discussão tem que enviar um pedido de participação ao coordenador da discussão. Cabe ao coordenador a responsabilidade de autorizar, ou não, esse pedido.
As discussões são constituídas pela descrição do tema em discussão e por tópicos, ou atributos de discussão, utilizados para definir aspectos que necessitem de uma caracterização mais individualizada dentro do tema proposto, ou eventualmente realidades parciais dentro do âmbito geral do tema de discussão. O relacionamento dos atributos é fácil de perceber pelos participantes. Tais participantes podem fornecer informação, no sentido de caracterizar cada atributo de discussão. A caracterização dos atributos de discussão pode ser feita de uma forma simples (por exemplo através de uma frase), ou através de estruturas de informação mais complexas, nomeadamente através de dados inseridos no sistema sob a forma matricial.
Os atributos de discussão, as caracterizações e as mensagens podem ser re-arranjados na discussão sem perdas no esquema de relacionamento da informação. No entanto, esta operação está reservada apenas ao coordenador, que é também responsável por seleccionar a caracterização final de um determinado atributo. Essa selecção fica patente aos restantes participantes, através de informação visual e pode envolver múltiplas caracterizações. O coordenador está igualmente incumbido de efectuar o fecho (e eventual reabertura) dos atributos de discussão, isto é, está encarregue de dizer ao sistema e aos participantes, que determinado atributo de discussão já não está disponível (ou voltou a estar) para novas caracterizações. Igual processo é implementado no sentido de fechar (ou reabrir) um tema de discussão, impedindo (ou permitindo novamente) novos elementos de discussão.
O sistema apresenta o conjunto de relações e encadeamento entre os diferentes elementos constituintes da discussão através de representação em árvore. No sentido de mostrar a rede de informação, que se vai desenvolvendo ao longo da discussão, podem existir elementos da discussão que são repetidos, sem que, no entanto, exista duplicação de informação (eventualmente existe apenas repetição de visualização).
O programa gere todo o processo de ligação e comunicação, aliviando o utilizador da preocupação de saber permanentemente se o sistema está em utilização síncrona ou assíncrona, informando-o apenas das operações a efectuar em ambos os casos. Ou seja, o sistema implementa um sistema de gestão de erros de acesso que impede o bloqueio quer na situação de utilização concorrencial, quer no caso de incapacidade para obter uma ligação síncrona, o que contribui para um sistema mais estável. É ainda implementada a reprodução de discussões existentes no sistema central para o posto local de trabalho, de modo a permitir o trabalho assíncrono nessas discussões, garantindo a persistência local dos dados reproduzidos, bem como a integridade dos dados globais e locais do sistema no momento em que a informação gerada, ou alterada, localmente é novamente remetida para o sistema central.
3 Utilização prática Nesta secção apresenta-se, através de um exemplo, o modo de utilização do sistema elaborado, acompanhado pela descrição do modo de procedimento do utilizador, em diferentes situações. Ressalva-se, contudo, que não se pretende chegar a quaisquer conclusões finais sobre o exemplo, ou mesmo determinar se a solução encontrada é ou não a melhor. Trata-se apenas de um exemplo ilustrativo.
O exemplo escolhido prende-se com a necessidade de tomar uma decisão acerca do número de computadores pessoais a instalar nos gabinetes dos docentes de uma dada universidade, para uma subsequente proposta de aquisição do equipamento.
Para maior facilidade da explicação, o funcionamento do sistema será explicado para dois utilizadores: “A” e “B”.
3.1 Início da aplicação e registo de utilizadores A primeira vez que um utilizador inicia o sistema local tem acesso à janela inicial da aplicação. Nesse momento a base de dados local está vazia pelo que é necessário efectuar a afectação do posto de trabalho ao utilizador. Para esta apresentação inicia-se o processo com o utilizador “A”.
Figura 1 – Janela de gestão de utilizadores.
Dentro da janela de gestão de utilizadores, “A” tem de inserir um novo utilizador, com as suas referências, após seleccionar o botão para o efeito, como indicado na figura 1.
Após a introdução do endereço electrónico, do nome e da palavra-passe de entrada, a confirmação a efectuar pelo utilizador “A” gera no sistema central um identificador único do utilizador. Note-se que para o registo de utilizadores, bem como para alterações, obriga-se o sistema a estar em modo síncrono, de modo a facilitar a tarefa de validação de utilizadores, evitando a duplicação de identificação. Se o sistema local não estiver ligado ao central será devolvida uma mensagem de erro indicando que a operação de registo apenas se pode efectuar on-line.
O utilizador é então criado e exibido na janela de gestão de utilizadores. Todos aqueles que pretendam utilizar o sistema terão de efectuar operações semelhantes. Quando “B” tiver também efectuado o seu registo, o resultado será o da figura 2.
Figura 2 – Utilizadores registados.
Após o registo do utilizador é necessário afectá-lo ao posto de trabalho (mais concretamente à base de dados local), para o que é necessário seleccionar o utilizador pretendido e premir o botão de afectação ao posto de trabalho (figura 1). Ao confirmar a acção, apenas um utilizador poderá usar o sistema local, no posto de trabalho onde foi instalado, pois a partir deste momento ao iniciar o sistema local é exibida uma janela de inserção da password, que apenas esse utilizador deverá conhecer. Quaisquer outras passwords inseridas levarão ao término do programa. A afectação ao posto de trabalho evita também que o utilizador tenha de se identificar permanentemente, ao longo acções efectuadas dentro do sistema.
3.2 Criação de uma discussão Após o procedimento prévio de registo é possível aos utilizadores acederem à área de discussão. Surgirá a janela das discussões existentes (figura 3). Dentro deste espaço existem três separadores, que distinguem os tipos de discussão que podem existir no sistema: a criar no sistema central (ainda local), on line (modo de funcionamento síncrono) e reproduzidas (modo de funcionamento assíncrono).
Figura 3 – Janela de discussões.
O primeiro separador (Local) exibe temas de discussão criados pelos utilizadores, mas que ainda não foram enviados para o sistema central. O segundo separador mostra os temas de discussão existentes ao nível central, o que requer uma ligação on-line ao sistema central. Por último, o terceiro separador indica reproduções efectuadas de discussões existentes ao nível central. Cada um destes separadores tem mecanismos distintos, que serão seguidamente apresentados.
Na descrição efectuada até ao momento, nem o utilizador “A”, nem o “B” conseguem visualizar quaisquer temas de discussão, visto que nenhum foi ainda criado. Para o exemplo, é o utilizador “A” que vai criar o tema de discussão da afectação de computadores. Para tal utilizará o botão da barra de ferramentas que permite criar novos temas de discussão (ver figura 4) que dá acesso ao preenchimento dos dados da discussão.
Figura 4 – Criação de uma nova discussão.
A criação de novas discussões é independente de existir, ligação ao sistema central. Após a selecção do botão, o utilizador é solicitado a introduzir os elementos iniciais da discussão, nomeadamente o tema e palavras de pesquisa associadas.
Os elementos da discussão são compostos por um tema de discussão, um coordenador da discussão (estabelece-se sempre que o coordenador inicial de qualquer discussão é o seu criador), um participante (neste caso o próprio coordenador) e um conjunto de elementos de relacionamento da informação gerada e que é transparente para o utilizador, sendo também transparente o processo de identificação dos vários elementos de informação gerados.
Com a confirmação, os elementos da discussão são armazenados na base de dados local e é exibido, no separador Local, o tema da discussão criada (figura 5).
A figura 5 mostra também que com a selecção da linha que descreve a discussão criada são activados dois botões na barra de ferramentas: enviar para o sistema central e apagar. O mecanismo de apagar anula a informação gerada, enquanto que o envio para o sistema central regista a discussão.
Figura 5 – Informação do separador Local após a criação de uma discussão.
O processo de registo requer então uma ligação ao sistema central, sob pena da exibição de uma mensagem de erro. Se o sistema estiver on-line, a discussão é armazenada centralmente (e apagada localmente) aparecendo no separador On-Line (ver figura 6) e desaparecendo do Local.
Figura 6 – Separador On Line após o envio para o sistema central.
Admitindo que existe uma ligação ao sistema central (figura 6) o utilizador “A” pode aceder ao espaço de discussão, pressionando o botão para o efeito. Com isso apresenta-se a janela de discussão (figura 7). Atendendo a que “A” é o coordenador da discussão surgem duas barras de ferramentas associadas à janela de discussão: a de ferramentas de discussão e a de funções do coordenador. Os botões associados a cada uma destas barras de ferramentas são automaticamente activados, ou desactivados, consoante os itens de discussão seleccionados e as situações de utilização (sem reservas, ou com reservas de informação efectuadas, como se verá adiante). A barra de ferramentas de discussão pode também ser acedida através do mecanismo mouse right click. Pode observar-se que a janela (figura 7) organiza a discussão num esquema de árvore com diversos nós (nodes) que podem agrupar outros nós, podendo ser expandidos ou comprimidos. As colunas podem também ser ordenadas alfabeticamente através da selecção dos respectivos cabeçalhos. O esquema de visualização é dividido em três partes: participantes da discussão (neste momento só existe “A”), o histórico de coordenadores (onde “A” é o coordenador actual) e o tema de discussão.
Figura 7 – Janela de discussão.
3.3 Introdução de alguns elementos de discussão “A” pode agora começar a introduzir elementos à discussão. Seleccionando o tema de discussão, na barra de ferramentas apresentam-se-lhe duas escolhas para a introdução de nova informação: as mensagens e os atributos de discussão, pois a barra de ferramentas retirou a opção de caracterização (reservada exclusivamente aos atributos), como mostra a figura 8.
Neste caso “A” vai criar um atributo de discussão para perguntar quais os critérios a usar para a instalação dos computadores nos gabinetes. A figura 9 ilustra o resultado após o envio da informação inserida por “A”, traduzindo-se numa expansão do nó descritivo do tema de discussão, com um novo nó que simboliza um atributo de discussão. Poderão ser criados atributos que dependam de outros atributos, bastando para tal seleccionar o nó com o atributo a partir do qual se pretende criar outro e repetir o processo de inserção de atributos.
Figura 8 – Selecção para introdução de um novo atributo ou de nova mensagem.
Figura 9 – Atributo aberto a discussão.
3.4 Discussão síncrona Neste ponto de discussão o utilizador “B”, também ligado ao sistema central, consegue saber que está a decorrer a discussão criada por “A” através da informação visual associada. No entanto ao seleccionar a linha da discussão recebe um aviso de que não é participante da discussão, pelo que não poderá aceder a ela sem antes formular um pedido de participação ao coordenador actual da discussão.
Após a formulação do pedido, este tem que ser aprovado pelo coordenador da discussão. Os pedidos de participação podem ser vistos pelo coordenador através da selecção da respectiva ferramenta, incluída na barra de ferramentas do coordenador. Esta acção exibe a janela de pedidos pendentes de participação, onde aparece o pedido efectuado por “B”. Após aprovado o pedido de “B” a discussão inclui mais um participante e a apresentação da discussão, visualizada por “A”, altera-se incorporando o novo participante. “B”, por sua vez, sabe que o seu pedido foi aceite, se ao seleccionar o tema de discussão pretendido não for exibida a mensagem de erro, activando-se automaticamente o botão que permite aceder à discussão. Na janela de visualização da discussão o participante “B” apenas possui a barra de ferramentas de discussão, pois ele não é o coordenador.
O participante “B” pode agora introduzir elementos à discussão. Neste caso, vai inserir uma mensagem, à qual “A” vai responder, criando uma associação de respostas. O processo é idêntico ao dos atributos, só que seleccionando o botão para novas mensagens, pelo que será aqui omitido, apresentando-se na figura 10 o resultado final.
“A” vai proceder a uma proposta de caracterização do atributo “Critérios de afectação”, utilizando a ferramenta para o efeito, como exibido na figura 11. Após a selecção efectuada o participante tem que preencher os elementos da sua proposta. A proposta de “A” é apresentada na figura 12.
Figura 10 – As relações entre a informação são visíveis pela ligação em árvore.
Figura 11 – Mecanismo para propostas de caracterização de atributos.
Figura 12 – Proposta de caracterização.
A seguir “B” pretende efectuar uma nova proposta de caracterização, tendo duas possibilidades para o fazer: ou utiliza um esquema similar ao que usou “A” (preenchendo de raiz toda a informação) ou pode aproveitar o trabalho de “A”, introduzindo-lhe alterações (o que não significa que esteja a alterar o trabalho de “A”). Este último processo é conseguido através do mecanismo de “copiar” e “colar” em que o participante, neste caso “B”, pretende efectuar alterações à informação já existente. Para tal deve seleccionar o nó que representa a informação da qual pretende partir para efectuar a sua alteração e premir o botão “copiar”.
Após a cópia do nó desejado o participante tem de indicar ao sistema se deseja efectuar ou não modificações à informação copiada. A resposta afirmativa permite a construção de novos elementos de informação com base nos já existentes.
Após a confirmação das alterações, seleccionando o botão “colar”, o participante é alertado para que deve escolher o nó ao qual pretende associar a nova informação. O sistema apenas permite que o “colar” se faça de acordo com a estrutura definida para os elementos da discussão (ou seja, neste caso só será possível se o nó onde se pretende “colar” a informação for um atributo de discussão).
3.5 Trabalho assíncrono Após a nova proposta elaborada por “B”, este decide ponderar mais sobre o assunto, mas num local, onde não possui meios de ligação ao sistema central. Para tal, antes de encerrar o sistema local instalado no seu posto de trabalho, efectua uma reprodução da discussão, bastando-lhe aceder à janela das discussões (rever figura 6), seleccionar a linha que representa a discussão em que estava a trabalhar e premir o botão que efectua a reprodução. Tendo realizado este passo é exibida uma nova janela para a selecção do tipo de reprodução a efectuar (figura 13).
Figura 13 – Opções de reprodução das discussões.
“B” possui então duas opções: a de visualização simples e a de visualização com possibilidade de acrescentar informação. A visualização simples apenas permite ao participante ver os elementos de informação existentes na discussão reproduzida, até ao momento da sua reprodução, estando-lhe vedada a possibilidade de quaisquer outras acções. A segunda opção implica que o participante poderá introduzir nova informação, mesmo estando desligado do sistema central. Ao ser activado este modo de reprodução, é registada no sistema central uma reserva de acrescento e guardada localmente uma cópia da informação associada à discussão seleccionada para reprodução. Após completar estas tarefas o sistema inclui no separador Reproductions uma linha que representa a discussão reproduzida localmente.
Se “B” pretender continuar a trabalhar, sem ligação ao sistema central, poderá fazê-lo de forma idêntica ao que foi descrito anteriormente (seleccionando o botão para visualizar a discussão e activando os diversos mecanismos para inserção de nova informação). Contudo, “B” estará a trabalhar em modo assíncrono, pois a informação por ele gerada ficará armazenada apenas no seu posto de trabalho. Assincronamente “B” cria uma nova proposta de caracterização de atributo, gerando a situação da figura 14, onde se mostra que o sistema local identifica claramente qual o modo de funcionamento que está a ser utilizado pelo participante, incluindo também informação adicional acerca de qual a informação que foi gerada desde o momento da reprodução.
Figura 14 – Nova informação gerada localmente.
Se “B” pressionar o botão apagar dentro do separador Reproductions, tendo seleccionado a linha que representa a discussão reproduzida, provocará o desaparecimento da base de dados local de toda a informação referente à discussão em causa, quer a reproduzida, quer a nova que introduziu. Se pelo contrário pressionar o botão para enviar para o sistema central e o sistema local conseguir com sucesso uma nova ligação é transferida apenas a informação nova que “B” introduziu, apagando a reprodução da base de dados local e consequentemente do separador Reproductions. Após este processo o sistema liberta a reserva de acrescento criada no momento da reprodução. A nova informação gerada por “B” fica então acessível a todos os outros participantes.
3.6 Transferência de coordenador A coordenação de uma discussão pode ser transferida para outros participantes. Embora esta operação não necessite de uma ligação ao sistema central por parte do participante a quem vai ser transferida a coordenação, requer uma ligação síncrona por parte do coordenador que vai processar a operação. Para a execução de tal procedimento, “A” (actual coordenador) vai transferir a coordenação para “B”, seleccionando a linha da discussão que representa “B” como participante da mesma e activando o botão de transferência de coordenador disponível na barra de ferramentas do coordenador (figura 15).
Figura 15 – Ferramenta para a transferência de coordenador.
O sistema solicita então a confirmação do processo de transferência. Se a resposta é afirmativa a transferência é realizada. Neste caso “A” deixa de ser o coordenador da discussão, sendo-lhe retirada a barra de ferramentas do coordenador, que aparece agora na visualização da discussão no posto de trabalho de “B” (novo coordenador). A janela de visualização da discussão mostra agora duas linhas no histórico de coordenadores da discussão, estando o coordenador actual assinalado com uma imagem própria (figura 16).
Figura 16 – Com a transferência é introduzida uma nova linha ao histórico de coordenadores. O
coordenador actual aparece com uma imagem diferente associada.
3.7 Informação estruturada em rede “B” vai introduzir uma nova mensagem, mas pretende que esteja associada a duas propostas de caracterização. Em vez de criar duas mensagens, pode simplesmente seleccionar as propostas de caracterização às quais quer relacionar a mensagem e efectuar uma nova mensagem através dos mecanismos já referidos anteriormente (figura 17).
Figura 17 – Selecção múltipla.
Com esta acção cria-se uma mensagem e duas ligações entre as propostas de caracterização e a mensagem gerada. Esta estrutura deixa de ser hierárquica e passa a ter de ser representada por uma rede. Para lidar com esta situação, a estrutura em árvore que representa a discussão repetirá a visualização da mensagem, associando-a às propostas de caracterização em questão. Refira-se que esta duplicação é apenas de visualização (ver figura 18).
Esta situação ocorre também nos casos em que os participantes façam “cópia e colagem” sem introduzir alterações, pois na realidade aquilo que é criado nesses casos é apenas uma nova ligação entre informação já existente.
Figura 18 – O sistema recorre à repetição de visualização, para representar associações não hierárquicas.
O coordenador também tem à sua disposição ferramentas para alterar a estrutura da discussão, através de mecanismos drag and drop. Por exemplo, caso “B” se tenha enganado na selecção do nó ao qual queria associar a mensagem anterior, basta-lhe seleccionar a mensagem e arrastá-la até ao nó devido. O sistema implementa automatismos que impedem, por exemplo, que ao arrastar atributos para mensagens se processe a alteração, pois tal contraria a estrutura definida para a discussão.
Por detrás deste mecanismo existe um processo de reserva de alteração no sistema central. Assim que o arrastamento é terminado o sistema verifica se existem reservas de acrescento já registadas. Se tais reservas forem detectadas, o processo de alteração de estrutura é impedido e é devolvido um erro ao utilizador. Caso contrário o sistema regista uma reserva de alteração (que impede reproduções de discussões com possibilidade de acrescentar informação) que dura apenas o tempo necessário para proceder às alterações da informação através do sistema central, sendo logo a seguir anulada. Com estes mecanismos garante-se a consistência dos dados e a integridade da informação.
Neste ponto da discussão, “B” vai efectuar uma nova reprodução da discussão, repetindo o processo para proceder à reprodução local, já referido anteriormente. No entanto, no momento de escolher o tipo de reprodução a efectuar “B” possui uma opção adicional (a reserva de modificação), visto que é o coordenador actual da discussão (figura 19).
Figura 19 – Opções de reprodução disponíveis para o coordenador da discussão.
Ao ser reproduzida a discussão gerou-se uma reserva de modificação no sistema central, que impede os outros participantes de inserirem novos dados, ou de efectuarem reproduções para acrescento. Se existirem reservas de acrescento anteriores ao momento da reprodução de modificação, o sistema gera um erro (impedindo o processo) e alertando o participante para o facto de estarem pendentes reservas de acrescento, que impedem a de modificação.
3.8 Encerramento de atributos e da discussão Para além das modificações via arrastamento da informação o coordenador de uma discussão está encarregue de vincular propostas de caracterização aos diferentes atributos. Está também incumbido de encerrar (impedindo novas propostas de caracterização) ou reabrir atributos (permitindo novas propostas de caracterização) e de encerrar a discussão (impedindo nova informação), ou de a reabrir (voltando a permitir a inserção de nova informação). Para tal utiliza a mesma ferramenta (lock/unlock) disponível na barra de ferramentas do coordenador, após seleccionar o nó a modificar (as mensagens não têm este processo).
Para o exemplo, “B” vai seleccionar uma proposta de caracterização, e encerrar o atributo existente (embora um atributo não necessite de ter uma proposta de caracterização seleccionada, para ser encerrado, de igual modo que o encerramento da discussão não necessita do encerramento dos atributos).
O processo para encerrar a discussão é igual ao de encerrar um qualquer atributo de discussão (quer em modo de trabalho síncrono, ou assíncrono), só que o seu efeito impede a discussão de receber quaisquer outros elementos de informação adicionais (os botões de inserção de nova informação, ou de cópia, ficam desactivados). A partir do encerramento da discussão apenas os utilizadores que participaram nela poderão visualizar os seus elementos, eliminando a possibilidade de novos pedidos de participação remetidos por outros utilizadores. Para que se possam introduzir novas informações à discussão é necessário que o último coordenador reabra a discussão (através do mesmo mecanismo que serve para o encerramento).
A acção de encerramento da discussão repercute-se directamente na janela das discussões, alterando a informação visual associada à linha que representa a discussão.
Os utilizadores poderão ainda efectuar a reprodução de discussões encerradas, onde participaram, mas a única opção que lhes é permitida é a de visualização simples. Apenas o último coordenador de uma discussão encerrada tem a opção adicional para reabrir uma discussão.
Figura 20 – A discussão foi encerrada.
4 Conclusões Em termos do modelo de informação utilizado, o trabalho realizado permitiu melhorar e ratificar o modelo DOC2 como um modelo válido para a estruturação de aplicações distribuídas, com utilização de diferentes tipos de sincronismo. Em termos da aplicação informática, pode-se verificar que esta conseguiu implementar os requisitos exigidos ao sistema, demonstrando
capacidade e flexibilidade de execução. Todavia a aplicação informática não deverá ser observada como um sistema óptimo alcançado, mas sim como um primeiro passo para a implementação de sistemas de colaboração mais evoluídos, baseados no modelo DOC2, eventualmente com mais e melhores capacidades de apoio a grupos distribuídos, como por exemplo a incorporação de sistemas de votação, ou de métodos quantitativos de apoio à decisão.
Para simplificação do trabalho, assume-se que as tarefas de gestão de utilizadores só podem ser executadas em modo síncrono. No entanto, este tipo de funcionamento pode ser alterado através da introdução de mecanismos de validação local e posterior validação por parte do servidor central.
O esquema de visualização da informação gerada, bem como da estrutura dos seus relacionamentos utiliza um esquema em árvore com recurso à duplicação de visualização da informação, no sentido de representar a rede de informação gerada nas discussões. O sistema poderá beneficiar de outras ferramentas de representação em rede que permitam simplificar a visualização da informação, sem comprometer a simplicidade de exibição da estrutura das suas relações.
O DOC2 foi ainda pensado de modo a que o gestor de reserva de objectos use calendários e reservas para gerir o acesso a cada recurso distribuído. Os mecanismos de reserva de informação implementados permitem duas opções: a reserva de acrescento e a reserva de modificação. No entanto nenhum deles tem associado mecanismos de controlo do tempo de reserva.
Finalmente, a constituição de um grupo de discussão passa pelo envio de pedidos de participação ao coordenador actual da discussão. Esta situação pode ser complementada com convites de participação, enviados pelo coordenador actual.
5 Agradecimentos O trabalho apresentado foi parcialmente financiado pela FCT e pelo FEDER, no âmbito do projecto POCTI/32405/GES/2000.
6 Referências Aleixo, J. (2000) “Um modelo de objectos para aplicações assíncronas distribuídas”, tese de
mestrado em Gestão da Informação nas Organizações, Faculdade de Economia da Universidade de Coimbra.
Antunes, F. (2002) “Collaboration Studio: Um sistema distribuído de colaboração síncrona e assíncrona com apoio à estruturação de dados”, tese de mestrado em Gestão da Informação nas Organizações, Faculdade de Economia da Universidade de Coimbra.
Antunes, F., Melo, P. e Costa, J. (2002) “Collaboration Studio: Um sistema distribuído de colaboração síncrona e assíncrona com apoio à estruturação de dados”, Actas da XII Jornadas Luso-Espanholas de Gestão Científica, Volume V, Universidade da Beira Interior, Covilhã.
DeSanctis, G. e Gallupe, B. (1987) “A foudation for the Study of Group Decision Support Systems”, Manegement Science, 33(5), p. 589-610.
Lopes, Secundino (1999) “Desenvolvimento de um sistema de apoio à interacção de um grupo distribuído”, tese de mestrado em Gestão de Informação nas Organizações, Faculdade de Economia, Universidade de Coimbra.
Melo, P. e Costa, J. (1999) “Some Design options for Persistent Distributed Information within Group Decision Support Systems”, Proceedings, Volume 1 – Information Systems, N.
Callaos, N. Nada, A. Cherif e M. Aveledo (Editores), International Institute of Informatics, p. 178-184.
Melo, P. e Costa, J. (2001) “Um par de modelos para gestão de dados distribuídos em Sistemas de Apoio à Decisão em Grupo”, Proceedings da 2.ª conferência da Associação Portuguesa de Sistemas de Informação, Évora, CD, António Serrano e Carlos Zorrinho (Editores), 21 a 23 de Novembro.
Teixeira, S. e Pacheco, X. (2000) “Delphi 5 – Guia do desenvolvedor”, Editora Campus, Rio de Janeiro.
