Ciclo de Informação de Percepção

Do ponto de vista técnico, a informação utilizada no modelo de percepção passa por um ciclo desde que é coletada a partir das ações de um usuário, armazenada, organizada, distribuída, apresentada, analisada e, finalmente, destruída.

5.4.1 Coleta

A etapa de coleta tem como objetivo determinar os elementos do modelo de percepção associados com cada ação existente na fila de eventos da aplicação. O principal problema, nesta etapa, é realizar a coleta sem alterar as aplicações existentes (RT1).

Não é adequado que o usuário seja envolvido no processo de coleta, pois isso implicaria tarefas adicionais para o usuário final que, além da sobrecarga cognitiva associada, iriam distrair o usuário da atividade principal que é o desenvolvimento de software. A coleta implícita de informações deve ser realizada com uma das técnicas de integração de aplicação, conforme as facilidades oferecidas pela aplicação. Do ponto de

vista da arquitetura, é importante separar a coleta das demais preocupações. O componente de coleta deve ser simples e coeso. Deve ser considerada a existência de dados incompletos devido a sensores insuficientes ou usuários não participantes. Exemplos de sensores são apresentados juntamente com os protótipos no Capítulo 6.

5.4.2 Armazenamento

A colaboração assíncrona exige a existência de um mecanismo de persistência que armazene a informação de percepção. Na arquitetura proposta, escolhemos o servidor de espaço de tuplas. Devido à granularidade escolhida pelo modelo de percepção, espera-se a necessidade de um grande espaço de armazenamento. O espaço de tuplas favorece o armazenamento, pois é uma estrutura escalável, distribuída e persistente.

5.4.3 Organização

A organização da informação de percepção inclui os processos de filtragem e transformação de eventos. A filtragem é baseada na recuperação de tuplas que satisfaçam determinados critérios de consulta e é posterior ao armazenamento. Desta forma, reduz a sobrecarga de apresentação, mas não favorece a redução do espaço de armazenamento, nem a privacidade do usuário.

O principal processo de transformação é a interpretação de eventos (Seção 5.5.5), que é encarregada de gerar novos eventos, de mais alta ordem semântica, a partir de um grupo de eventos existentes. A quantidade de eventos após a interpretação é sempre reduzida, embora os eventos originais sejam preservados no repositório.

5.4.4 Distribuição

A distribuição de informação é realizada por notificação e por consulta, com base em um critério de consulta. Na notificação, uma tupla é enviada para um processo, sempre que satisfizer um critério específico. Na consulta, são recuperadas tuplas existentes que satisfazem o critério estabelecido. Em geral, um componente vai usar a consulta para recuperar tuplas que foram geradas antes do início da execução do

processo e a notificação para acompanhar a criação de novas tuplas.

5.4.5 Consumo

O consumo da informação ocorre quando da sua apresentação ao usuário final ou pela sua retenção por um filtro de informação. Em mecanismos que trabalham em tempo real, o consumo da informação é instantâneo, ou seja, uma vez distribuída e apresentada, a informação não é mais necessária. Por outro lado, nos demais mecanismos, a informação pode ser consumida (consultada) em diferentes sessões de execução de um mecanismo.

Em alguns casos, a informação é coletada na estação de trabalho antes mesmo de ser consolidada no repositório central. Ocorre, então, o problema de notificar o cancelamento de uma informação armazenada e possivelmente distribuída e consumida. Por exemplo, imaginemos que um desenvolvedor crie algumas classes e depois decida abandonar a alteração sem realizar o commit, no repositório de software do projeto. A informação coletada na estação, durante a sessão de trabalho, vai indicar a criação de uma classe que não existe no repositório central, gerando uma inconsistência entre a informação de percepção e o modelo de software. A solução adotada é a notificação da destruição da classe que não se encontra no modelo de software, logo após a notificação da criação da classe. Entretanto, a percepção de um desenvolvedor que está ciente da criação é diferente da percepção do desenvolvedor que ainda não estava ciente da criação da classe. Para o primeiro, a criação tem maior relevância, enquanto que para o segundo, a criação e a destruição são eventos que se anulam e não tem maior relevância, a não ser que o segundo desenvolvedor esteja interessado no histórico dos artefatos envolvidos.

O consumo da informação de percepção é uma etapa que é realizada, em sua maior parte, pelas extensões colaborativas. Existem trabalhos que tratam especificamente desta etapa e das possibilidades de estabelecer filtros de informação e de seleção de extensões apropriadas para uma sessão colaborativa (DAVID e BORGES, 2001).

5.4.6 Destruição

Na prática, o armazenamento da informação de percepção é limitado pelo espaço de armazenamento disponível e pela perda de desempenho causada pelo alto volume de informação a ser processado para responder às consultas. Em um sistema concreto, uma política deve ser adotada para a destruição das anotações ou para a sua movimentação para um novo espaço de armazenamento.

Por exemplo, as anotações sobre um elemento do modelo de software poderiam ser destruídas quando o elemento deixasse de existir em todas as cópias do modelo. Por exemplo, quando uma classe deixasse de existir no repositório central e em todas as áreas de trabalho, seria possível remover todas as anotações sobre essa classe. Todas a ações sobre a classe seriam invalidadas por sua remoção do modelo. Entretanto, essa regra não é determinante da destruição de uma anotação, pois existem outras características a serem analisadas.

A remoção de um elemento do modelo de software gera uma modificação em todos os elementos associados ao elemento removido. Por exemplo, ao remover uma classe de um modelo, ocorre uma modificação no pacote associado a esta classe. Portanto, a anotação sobre um elemento de software inexistente é necessária para comunicar a situação de elementos que ainda persistem no modelo de software. Se a anotação sobre a remoção da classe fosse destruída, a anotação sobre a alteração do pacote seria perdida.

A destruição da informação de percepção não é uma operação trivial. A informação pode ser necessária no futuro para um estudo da evolução do projeto ou para facilitar sua auditoria. A opção mais simples é mover a informação de percepção para mídia terciária. A movimentação da informação seria controlada pelo ciclo de desenvolvimento dos projetos. A decisão pela destruição da informação é administrativa e é provável que seja determinada pela data da coleta ou outro parâmetro de interesse da gerência do projeto.