Na seção de trabalhos relacionados deste capítulo, mostramos os principais modelos propostos para a modelagem de sistemas colaborativos. Na primeira subseção, apre- sentamos os modelos baseados na teoria da Engenharia Semiótica. Discutimos a seguir as principais limitações dos modelos apresentados que motivaram a construção de um novo - o SIGMa, proposto neste trabalho de doutorado.
O primeiro modelo apresentado foi o Modelo Abstrato do Componente Multi- usuário do Artefato de Metacomunicação (MetaCom-G) [Prates, 1998]. Como mostra- mos, este modelo já previa a necessidade de um gerador de cenários (naquela época chamado de Cenógrafo), mas o definiu apenas no nível conceitual (nunca foi implemen- tado). O trabalho de Prates [1998] foi a maior fonte de inspiração para a construção do SIGMa. Como será visto no próximo capítulo, as dimensões da nossa linguagem de modelagem (SIGMa-dl) foram inspiradas pelas dimensões previstas pelo MetaCom-G, mas contemplam as características necessárias para a modelagem de sistemas colabora- tivos diversos. O MetaCom-G foi definido para a modelagem de sistemas colaborativos com foco no trabalho cooperativo, ou seja, sistemas nos quais diversos usuários intera- gem para realizar um determinado trabalho. Nosso objetivo neste trabalho é permitir a modelagem de sistemas colaborativos diversos, e não apenas aqueles que têm foco no trabalho, como uma rede social, por exemplo. Além disso, ao observarmos o MArq-G (instância do MetaCom-G), vemos que o seu foco e a sua arquitetura são voltadas para a representação de sistemas colaborativos voltados para o trabalho. Devido a essa característica, optamos por nos basearmos nas dimensões propostas por Prates [1998], mas com um olhar mais abrangente que permitisse a modelagem de sistemas colabo- rativos em geral. As dimensões que foram diretamente reaproveitadas do MetaCom-G são os papéis e os objetos (que a SIGMa-dl nomeia como artefatos). Além disso, a dimensão de Tempo x Espaço não foi usada como no trabalho de Prates [1998], mas foi fundamental para fomentar a definição da dimensão Espaço de Tempo, prevista pela SIGMa-dl.
Já a Manas [Barbosa, 2006], apesar de ter surgido com base nas deficiências do MetaCom-G na representação de fatores sociais como confiança, privacidade e polidez, tem como foco a comunicação entre usuários de um sistema colaborativo. Neste sen- tido, foca na emissão e recepção da mensagem que está sendo enviada entre os usuários através da interface. A definição de toda essa interação é modelada como uma comu- nicação. Embora ajude o projetista na visão do sistema como metacomunicação, é de difícil entendimento pois os conceitos (como papéis, ações e objetos) usados em siste- mas colaborativos não são apresentados diretamente. Além disso, a Manas não permite
46 Capítulo 3. Fundamentação Teórica e Trabalhos Relacionados
que o projetista vislumbre os cenários que podem ser gerados a partir da interação de cada papel/grupo presente no sistema.
Ainda nos trabalhos relacionados, mostramos os principais modelos propostos para a modelagem de sistemas colaborativos que não são baseados na Engenharia Semiótica. Começamos apresentando o Groupware Task Analysis (GTA) [Veer et al., 1996]. Esse framework evoluiu para uma ontologia, que ajuda os projetistas a refletir sobre uma situação problema (chamada de “modelo de tarefas 1”) e para formular uma proposta de melhoria para essa situação (chamada de “modelo de tarefas 2”). Apesar de existir uma ferramenta (EUTERPE [Welie et al., 1998]) baseada na ontologia que permite a criação de modelos de tarefa graficamente, o projetista deve definir cada instância prevista para as cinco dimensões da ontologia. Além disso, não leva em consideração o tempo de uso, uma vez que não descreve que decisões o usuário pode tomar em relação ao sistema, que altere aspectos sobre o sistema e a interação.
O outro trabalho descrito foi o Concurrent Task Trees (CTT) [Paternò, 1999; Paternò et al., 2001; Paternò, 2003]. Este trabalho tem como características principais a representação gráfica dos modelos e o suporte a relacionamentos temporais entre tarefas. Como mostramos, o CTT contempla uma série de operadores temporais que podem ser aplicados a duas tarefa e ainda operadores unários que podem ser aplicados a tarefas individuais. As tarefas são categorizadas em quatro tipos e permitem ao projetista identificar “quem” é responsável por cada tarefa (o usuário, o sistema ou ambos.) A criação dos modelos é apoiada por uma ferramenta denominada CTTE [Mori et al., 2002]. Além de permitir a criação dos modelos de forma visual, a CTTE fornece ao projetista ainda a capacidade de simular as ações previstas segundo os operadores temporais previstos. Sob um olhar superficial o CTT se parece bastante com o SIGMa. Por isso, cabe aqui descrever as suas principais limitações que o diferenciam da nossa proposta.
Ao usar o CTT, o projetista necessariamente tem que descrever todas as tarefas possíveis e os relacionamentos temporais entre elas. A partir do simulador, o projetista pode ver como as relações temporais entre as tarefas definidas se desenvolvem. Assim, o projetista pode ver quando uma tarefa é executada, que outras tarefas ficam disponíveis para o usuário. No entanto, ele apenas gera esta simulação das relações entre as tarefas descritas nos operadores temporais. Não há como o projetista descrever mudanças que afetarão não apenas o momento em que as tarefas estarão disponíveis, mas em todos os lugares
Como veremos no próximo capítulo, o SIGMa tem uma proposta diferente. Ele nasce com o objetivo de gerar os cenários que não foram explicitamente especificados pelo projetista, mas que podem ser gerados pelos usuários em tempo de uso a partir
3.2. Modelos para Projetos de Sistemas Colaborativos 47
de uma combinação de ações que foram descritas pelo projetista. É claro que algu- mas definições devem ser feitas ao usar o SIGMa, mas o projetista define apenas as consequências que cada ação traz ao sistema como um todo. Ele não define todas as interações possíveis entre elas. Neste sentido, o SIGMa tem o potencial de chamar a atenção do projetista para cenários que não foram antevistos em tempo de projeto, possibilitando que ele reflita sobre as decisões tomadas. No CTT, uma mesma ação que tem os mesmos impactos no sistema deve ser modelada duas vezes (ou copiada). Uma alteração que eventualmente possa ser necessária deve ser feita em todas as cópias daquela ação, ou seja, a alteração em uma instância da ação não é propagada para as suas cópias. Finalmente, o CTT não prevê a “divisão” de um sistema colaborativo em diferentes contextos de aplicação. Por exemplo, um sistema de gerência de conferências passa por diversos contextos diferentes (fase de submissão, fase de atribuição de reviso- res, fase de revisão, fase de decisão de artigos aceitos e rejeitados, etc). Cada contexto do sistema envolve pessoas, ações e objetos diferentes. Como o CTT não contempla essa segmentação conceitual do sistema, os modelos que envolvem diferentes contextos podem ser difíceis de serem criados e ainda mais de serem simulados. Como veremos no próximo capítulo, os contextos pelos quais uma aplicação pode passar, os quais de- nominamos “espaços de tempo”, são o cerne da nossa linguagem de modelagem. Dessa forma, o projetista pode modelar a sua aplicação pensando nesses diferentes espaços de tempo, e pode acompanhar os impactos das ações previstas entre eles.
Por fim, o Human-centered Assessment and Modeling to Support Task Engineering for Resilient Systems (HAMSTERS) foi concebido para ser aderente ao CTT e, mesmo apresentando uma proposta para simplificar os modelos e propagar as alterações feitas em uma tarefa, ainda exige que o projetista especifique todos os cenários possíveis, e assim, embora trate de algumas limitações do CTT, não resolve as relacionadas a geração de cenários futuros que pretendemos tratar no SIGMa.