Versões em documentos estruturados

Marilene Araújo Noronha

                          

Este trabalho apresenta a proposta de um modelo de versões a ser incorporado no projeto GDOC (Gestão de Documentos). O objetivo do GDOC é o desenvolvimento de um sistema para o controle de documentação de produtos para a obtenção do certificado ISO 9000 em uma Intranet. Uma das exigências deste padrão é o controle das alterações e das versões antigas dos documentos. Como documentos podem ser criados de acordo com tipos pré-definidos, este modelo permite também o controle de versões dos tipos dos documentos.

Esta proposta baseia-se no modelo de versões de [GOL 95].

Os capítulos incluídos neste trabalho referem-se ao modelo de documentos definido para o GDOC e ao modelo de versões propriamente dito.

Conceitos associados a versões

O objetivo deste capítulo é apresentar os principais conceitos associados a versões definidos no modelo de versões de [GOL 95b] e como estes conceitos são abordados em algumas aplicações de gerência de documentos com controle de versões. Este modelo é o utilizado como base a extensão para suporte a versões proposta para o modelo de documentos do GDOC.

O modelo de versões é apresentado na primeira seção, sendo enfocados os aspectos que serão empregados neste trabalho. A descrição completa deste modelo, bem como exemplos de sua utilização em outros domínios de aplicação são encontradas em [GOL 95a, GOL 97].

Quando se tem versões em objetos (ou documentos) compostos, são necessários mecanismos para a manutenção da consistência entre estes objetos. Esta questão, embora não seja abordada pelo modelo de [GOL 95b], é um dos mecanismos associados a versões utilizados nesta proposta, sendo o assunto da seção 2.2.

Na seção 2.3 é analisado o tratamento de algumas aplicações de documentos com controle de versões para os conceitos apresentados, abordando em linhas gerais, o enfoque dado pelo controle de versões do GDOC.

O modelo de versões

O conceito de versão

Uma versão é uma descrição de um objeto num determinado momento do tempo, ou sob um certo ponto de vista, cujo registro é importante para a aplicação. Num modelo orientado a objetos, uma versão é um objeto de primeira classe, possui um identificador próprio, podendo ser diretamente manipulada ou consultada, como qualquer outro objeto do sistema.

As versões de uma entidade do mundo real ficam agrupadas e constituem um objeto versionado. Um objeto versionado também é um objeto de primeira classe, contém informações sobre as versões associadas, além de possuir propriedades próprias. Um objeto versionado pode apresentar atributos comuns a todas as versões. Cada versão pertence a exatamente um objeto versionado.

Objetos (versionados ou não) que apresentam as mesmas propriedades e comportamento podem ser agrupados em classes. Como a propriedade de ser versionado pertence ao objeto, uma classe pode ter objetos versionados e não versionados como instâncias.

Cada objeto versionado possui uma versão que é considerada sua versão corrente, sendo automaticamente mantida pelo sistema como a mais recentemente criada. O usuário pode especificar uma versão diferente como a corrente e, neste caso, a versão ficará fixa , não mudando com o surgimento de novas versões. A versão corrente é utilizada sempre que o usuário solicitar uma operação sobre um objeto versionado sem especificar uma de suas versões.

2.1.2 Propriedades das versões

As versões de um mesmo objeto estão relacionadas através de um relacionamento de derivação, formando um grafo acíclico dirigido, onde cada versão pode ter várias antecessoras e várias sucessoras.

Outras estruturas de relacionamento podem ser do tipo lista, onde cada versão só tem uma versão antecessora e uma sucessora, ou do tipo árvore , onde várias versões podem ser derivadas de uma mesma versão, mas cada versão só tem uma antecessora. O histórico das versões é obtido a partir do relacionamento antecessora/sucessora estabelecido entre as versões [KAT 90].

Cada versão tem um status que reflete seu estágio de consistência, podendo ser em trabalho, estável ou consolidada, semelhante à classificação em [KIM 89 a, BEE 88]. Dependendo do valor do status, certas operações não são permitidas. Uma versão em trabalho é uma versão temporária que ainda deve sofrer diversas alterações, antes de atingir um estágio mais estável. Uma versão estável é uma versão que já atingiu um estágio mais consistente, pode ser compartilhada ou removida, mas não alterada. Uma versão consolidada é uma versão em seu estágio final, não podendo mais ser alterada ou removida.

Novas versões são criadas com status em trabalho. Quando uma versão é derivada de uma ou mais versões, suas antecessoras são automaticamente promovidas para estáveis, impedindo que sejam feitas modificações em versões que são importantes do ponto de vista histórico. O usuário pode explicitamente promover uma versão em trabalho para estável, ou uma versão estável para consolidada.

2.1.3 Objetos compostos: referências estáticas e dinâmicas

Objetos podem ser definidos como compostos de outros objetos, formando uma hierarquia de agregação. Quando objetos que apresentam versões são usados como componentes de outro, podem ser estabelecidos dois tipos de referências: referência estática, quando é feita a uma versão específica, ou referência dinâmica [KIM 89, AGR 91, quando é feita para o objeto versionado.

Uma referência estática é uma referência simples ao objeto, ao passo que uma referência dinâmica significa que uma versão específica será escolhida em tempo de execução. Num ambiente de projeto, uma referência dinâmica indica que o usuário ainda não sabe qual versão do componente será usada, ou que ele quer deixar em aberto a escolha para testar diferentes opções. Na figura 2.1 o objeto composto fiat-uno da classe Automobile tem duas versões. A versão cs tem uma referência estática para a primeira versão do objeto fiat-motor, enquanto que a versão new tem uma referência dinâmica para o objeto versionado fiat-motor. Neste caso, diz-se que o componente motor para a versão cs está completamente definido. Já a referência dinâmica indica que o motor ainda não foi definido.

Quando um objeto para o qual há uma referência dinâmica for recuperado, esta referência deverá ser substituída por uma referência a uma de suas versões, num processo chamado resolução da referência dinâmica. Este processo também ocorre quando é construída uma configuração para o objeto. No primeiro caso é escolhida a versão corrente do objeto. Já na definição de uma configuração, o usuário dispõe de mais recursos para a seleção da versão, como por exemplo, utilizando critérios pré-definidos como a primeira, a última, ou através de expressões envolvendo os valores dos atributos da versão.

Referências dinâmicas são bastante convenientes, pois versões podem ser removidas ou novas versões podem surgir, não sendo necessário alterar o objeto composto que utiliza estas versões. Num sistema de documentos, referências dinâmicas possibilitam que os documentos sejam mantidos sempre atualizados, uma vez que o usuário sempre tem acesso à versão corrente do documento.

2.1.3 A definição de uma configuração

Considerando um objeto composto em que os componentes podem ser objetos versionados, uma configuração associa exatamente uma versão de cada um destes componentes com o objeto composto. Se o objeto for composto hierarquicamente, a configuração deve incluir definições para todos os objetos na hierarquia de agregação.

Como no modelo proposto uma entidade do mundo real pode ser modelada em vários níveis de abstração na hierarquia de herança, a configuração também deve definir uma única versão em cada nível em que a versão é representada. Diferentes versões podem ser escolhidas para os componentes (ou ascendentes), gerando diferentes configurações para o mesmo objeto. O modelo trata a configuração como uma versão especial do objeto chamada de versão configurada ou configuração.

A operação de configuração é aplicada a uma versão base. Na definição das versões dos componentes, cada escolha define "parte" da configuração e, quando uma versão fica completamente especificada, é gerada uma versão configurada, como sucessora de sua versão base. A nova versão passa a ser a versão corrente do objeto (se o usuário não alterou a corrente).

A figura 2.2 a) representa o cenário para a construção de uma configuração para a versão a2. A referência dinâmica de a2 para o objeto versionado y-q é resolvida para a versão corrente deste objeto, que é a versão q2. Em 2.2 b) está representado o resultado deste processo, que é a criação das versões configuradas c2 e c3.

Uma versão configurada só pode fazer referência a versões configuradas, que podem ser compartilhadas por outras versões, configuradas ou não. Esta restrição garante que uma versão configurada é sempre completamente definida. A possibilidade de compartilhar versões configuradas é bastante vantajosa, pois permite utilizar escolhas já feitas.

O modelo fornece uma série de recursos associados ao conceito de configuração. Configurações podem ser definidas com base num critério pré-estabelecido para a resolução das referências ou avaliando uma expressão de configuração fornecida pelo usuário. Na primeira opção, a versão selecionada é a versão corrente do objeto versionado. A segunda opção permite que versões sejam construídas com maior flexibilidade mas, por outro lado, são necessários recursos adicionais de uma linguagem de consulta para que versões possam ser consultadas utilizando-se os valores de seus atributos, e para que possam ser definidas expressões envolvendo os relacionamentos nas hierarquias de derivação e herança. Exemplos destes recursos são apresentados em [GOL 95b].

Configurações e versões são tratadas de maneira uniforme pelo modelo, permitindo que configurações e versões sejam combinadas na construção de novas versões, bem como que uma versão seja derivada a partir de uma configuração. A nova versão é uma versão regular, podendo sofrer qualquer tipo de alteração, mas fica ligada como sucessora da versão base. No entanto, configurações apresentam a particularidade de ser uma especificação completa do objeto, onde há apenas referências estáticas para os componentes, correspondendo ao conceito de instância num banco de dados sem versões. Além disto, configurações são sempre folhas no grafo de derivação. Esta característica garante que uma configuração possa ser removida, evitando a proliferação de configurações não aprovadas.

A possibilidade de armazenar uma configuração é um recurso bastante importante, pois no caso de existirem objetos com várias referências, a configuração representa todo um processo de escolha já feito e que pode ser aproveitado em outros projetos. Além disto, as configurações possibilitam o acompanhamento da evolução do sistema no tempo, pois nas referências dinâmicas diferentes versões podem ser definidas como a versão corrente ao longo do tempo, perdendo-se o acompanhamento da evolução do sistema.

2.1.5 Operações sobre as versões

Operações que podem ser feitas sobre as versões são: criação, modificação e remoção. Na criação de uma nova versão, aquela que serviu de base para a operação é automaticamente promovida para o status estável, não podendo mais ser alterada. A nova versão é criada com status em trabalho. Esta operação é feita sob controle explícito do usuário e pode ocorrer de quatro maneiras:

1) é criado primeiramente um objeto versionado e depois é feita a criação de versões para este objeto. Esta opção é bastante vantajosa pois permite que o objeto versionado seja referido, ainda que nenhuma versão tenha sido criada, possibilitando que um projeto seja realizado de maneira top-down. Quando novas versões forem criadas, elas serão derivadas da versão corrente do objeto;

2) derivação a partir de uma versão ou de um conjunto de versões. Havendo várias antecessoras, a nova versão é gerada como cópia de uma, mas o relacionamento de derivação é estabelecido com todas. Fica sob responsabilidade do usuário a operação de combinação (merge) das diversas antecessoras;

3) uma versão pode ser derivada a partir de um objeto não versionado, ou seja, o objeto já existia e surgiu a necessidade de alterá-lo, sem perder seu estado anterior. Neste caso, é criado um objeto versionado, o objeto existente passa a ser a primeira versão e a versão recém criada constitui a segunda;

4) podem ser criadas versões configuradas (vide seção 2.1.4) fornecendo-se uma expressão ou utilizando-se as versões corrente, no caso de referências dinâmicas. Uma nova versão também pode ser derivada a partir de uma versão configurada.

A modificação de uma versão só é possível caso ela esteja em trabalho. Uma versão pode ser removida se ela estiver em trabalho, ou se possuir status estável e for uma folha no grafo de derivação. Não poderão ser removidas versões que sejam referidas por outros objetos.

O modelo define também operações para navegação na hierarquia de herança, para recuperação dos atributos de uma versão ou objeto e para navegação no grafo de derivação.

2.2 Notificação e/ou propagação de mudanças

Quando existem objetos compostos, utilizando como componentes objetos que apresentam versões, modificações nos componentes, como a remoção ou o surgimento de uma nova versão, podem causar alterações nos objetos qe os utilizam. As ações a serem tomadas devido a modificações nos componentes são: notificação [CHO 86, KIM 89b] e/ou propagação [BEE 88, KAT 90, ATW 85, ZDO 86].

A notificação pode ocorrer através de duas técnicas: baseada em mensagens (message-based") ou baseada em sinais ("flag-based"). Na notificação baseada em mensagens, o sistema envia mensagens para notificar os usuários das versões (dos objetos compostos) possivelmente afetadas. Esta forma de notificação pode ser ainda distingüida em imediata ou deferida, conforme o momento no qual é dada a notificação, se imediatamente após as mudanças ou se em algum momento posterior, definido pelo usuário.

Na notificação baseada em sinais, o sistema coloca marcas nas estruturas de dados mantidas, de modo que o usuário só tomará conhecimento de uma mudança quando explicitamente fizer acesso a uma versão de um objeto composto que ficou com as referências desatualizadas devido a modificações nas versões dos componentes utilizados.

O fato de uma versão poder fazer referências a outras versões, de maneira recursiva, introduz o problema do escopo da notificação [CHO 86], ou seja, se somente as versões que fazem referência direta à versão modificada devem ser notificadas, ou se todas as versões que fazem referência direta ou indireta. O argumento a favor da primeira opção baseia-se na idéia de que a versão que faz referência direta poderá ou não ser alterada, para acompanhar a alteração de seu componente. Somente se o usuário da versão optar pela alteração, o processo de notificação continuará para o segundo nível de referência, e assim sucessivamente.

Outra ação que pode ser tomada frente à modificação dos componentes é propagar as mudanças. Esta abordagem é definida em [KAT 90] como o processo que automaticamente incorpora novas versões em configurações e pode-se dar através de atualização das versões afetadas ou da criação de novas versões. A primeira opção exige algoritmos não muito simples para proceder com as atualizações. Na segunda, também chamada de "percolation" [ATW 85], se uma nova versão é criada a partir de uma já existente, o sistema gera novas versões de objetos que direta ou indiretamente faziam referencia à versão existente.

Katz aponta ainda dois problemas que devem ser resolvidos por um mecanismo de propagação de mudanças:

1. como limitar o escopo da propagação, pois raramente o projetista deseja criar novas versões de todos os objetos até a raiz da hierarquia de composição. Este problema é análogo ao problema de definir o escopo da notificação;
2. como tornar não ambíguo o caminho usado para a propagação. A ambigüidade aparece, por exemplo, quando uma mesma versão é referida por mais de um componente de um mesmo objeto composto

2.3 O controle de versões em sistemas de documentos

2.3.1 Sistemas de hipertextos

Um hipertexto é definido como um conjunto de nós interligados por elos [SMI 88], estabelecendo uma estrutura hierárquica, semelhante a de um documento estruturado, de modo que também são semelhantes os mecanismos necessários para o controle de versõees nestes dois tipos de documentos.

Nesta seção são analisados como alguns sistemas de hipertextos com controle de versões abordam os conceitos apresentados anteriormente. Esta análise é baseada num estudo feito em [NOR 96] e enfoca os sistemas Neptune [DEL 87], CoVer [HAA 92], HyperPro[OST 92], MCA[SOA 95] e um modelo baseado em agentes [DAT 96]. A maioria dos conceitos está presente nestes sistemas, mas são tratados de maneira específica, uma vez que são baseados em outros modelos de versões, além do próprio conceito de hipertexto (um conjunto de nós interligados po elos [SMI 88]) envolver particularidades quanto ao controle de versões. Cabe salientar que no modelo de agentes estas diferenças se acentuam, devido à própria metáfora empregada, mas resultando num tratamento bastante interessante para alguns conceitos, como o da configuração, por exemplo.

Num sistema de hipertexto, os objetos versionados são os nós e elos. O CoVer, o MCA e o HyperPro permitem que os nós sejam agrupados numa estrutura hierárquica, possibilitando o versionamento tanto do nó quanto de toda a estrutura do hipertexto. No CoVer esta estrutura é o nó de composição e no MCA e HyperPro, um contexto. No GDOC um documento possui instâncias e está associado a um tipo que define a estrutura que estas instâncias apresentam. As instâncias podem ser versionadas e foi acrescentado ao modelo um conjunto de primitivas para o controle de versões dos tipos. Para simplificar a nomenclatura, o termo documento, neste trabalho, será empregado como sinônimo de instância de documento.

Uma série de questões estão envolvidas no versionamento dos elos [OST 92, LO 94] de modo que ele não é suportado por todos os modelos. No CoVer e na versão estendida do Neptune[CAM 88], HAM, são apresentados mecanismos para este tipo de versionamento. Como no modelo de documentos do GDOC um elo é considerado como um documento ( figura 4.2), não há diferença do ponto de vista do controle de versões para este tipo de versionamento.

No modelo de agentes, o nó do hipertexto é representado por um agente e o hipertexto é definido por uma coleção destes agentes. O termo versão é empregado com o significado de configuração [KAT 90] e refere-se ao estado da estrutura do hipertexto como um todo. A alteração de um nó (agente) provoca a geração de um clone deste nó.

O Hyperpro e o MCA permitem que os atributos de um nó sejam definidos pelo usuário como versionados e não versionados. Os valores de atributos não versionados podem ser alterados sem a criação de uma nova versão do objeto.

Estruturas semelhantes ao objeto versionado estão presentes na maioria dos modelos, com o objetivo de agrupar as versões de um mesmo objeto (ou nó). O CoVer faz a distinção entre objetos versionados e não versionados e permite transformar objetos não versionados em versionados através de uma operação explícita. No MCA o conceito de contexto foi estendido para agrupar as versões de um mesmo objeto. No modelo de agentes o conceito de objeto versionado é considerado implícito na estrutura do agente, pois cada clone conhece seu nó original.

No MCA e no CoVer o relacionamento entre as versões de um mesmo objeto é estabelecido por um grafo acíclico dirigido, mas com a particularidade de que versões alternativas não são estabelecidas pela sua suas posições no grafo. Como estes modelos permitem a definição de expressões de consultas para a seleção de uma versão, são consideradas versões alternativas as resultantes destas consultas. No HyperPro, as versões estão representadas numa estrutura de árvore e no Neptune o relacionamento é mais restrito, suportando apenas versionamento baseado no tempo, estabelecendo uma lista. Uma abordagem semelhante é adotada pelo GDOC.

As versões dos nós também possuem um atributo de status. No MCA, é fornecido o conceito de versão obsoleta, indicando as versões que são compartilhadas mas que não poderão ser usadas em futuras referências. Este conceito foi absorvido pelo GDOC para que no gerenciamento dos documentos sejam identificados aqueles não válidos e/ou obsoletos, um dos requisitos da norma ISO9000 [ISO ].

Referências estáticas e dinâmicas podem ser estabelecidas para as versões de um nó. No Neptune, um elo pode apontar para uma versão específica ou para a corrente, que é sempre a mais recentemente criada. Este também é o critério padrão adotado pelo HyperPro. No MCA e no CoVer o critério de seleção da versão corrente é mais genérico, pois a versão corrente é determinada por uma expressão de consulta vinculada a estrutura que agrupa as versões. O uso de referências dinâmicas é apontado em [HAL 88] como uma importante funcionalidade para sistemas de hipertextos, pois permite a atualização automática das referências.

O MCA dispõe de mecanismos para armazenar a estrutura do hipertexto com as referências estáticas para uma versão específica de cada nó. No entanto, o conceito de configuração estática do MCA não é o mesmo de [GOL 95b], pois não é gerada uma versão configurada. Num ambiente onde há varias alternativas para as versões que compõem um documento, a geração de versões configuradas oferece a funcionalidade de armazenar diferentes escolhas, bem como aproveitar escolhas já feitas em outros documentos. No GDOC esta geração é importante pois permite registrar, de forma automática, o estado de todo o documento composto num determinado momento, para fins de manutenção do histórico do documento.

Quanto à criação de versões, tanto o CoVer com conceito de tarefas quanto o MCA com as bases privadas permitem que a criação de versões também seja controlada pelo sistema, consistindo de uma forma implícita de criação de versões. No Neptune, versões são criadas com comando Save do editor, o que ocasiona o problema da propagação de versões. A criação de versões no GDOC é controlada pelo usuário, mas o mecanismo de notificação auxilia nesta tarefa.

No modelo de agentes, a modificação de um nó provoca a geração de um clone deste nó e dos nós relacionados diretamente com ele. Automaticamente é gerada uma nova configuração do hipertexto, incluindo os novos nós e os nós que faziam parte da configuração anterior. Esta passa a ser a configuração corrente e é composta dos nós denominados ativos. Os nós originais são congelados, constituem a população de nós considerados inibidos e definem as configurações passadas. As configurações ficam armazenadas e podendo ser consultadas. Este modelo também permite que o usuário decida quando será gerada uma nova configuração do hipertexto.

A questão da atualização de um objeto composto para incorporar a nova versão de um componente é tratada pelo MCA pelos mecanismos da Notificação e Propagação. Os outros modelos não tratam desta questão e no GDOC a solução adotada baseia-se na Notificação.

Quando se tabalha com versões de documentos pode ser interessante poder comparar estas versões. Em [CHA 96, WAN 97] são propostos mecanismos para a comparação de versões de documentos estruturados hierarquicamente, uma funcionalidade que poderia ser incorporada numa extensão futura do modelo de versões do GDOC. Esta operação não é suportada por nenhum dos modelos analisados.

Os modelos analisados foram implementados em aplicações de âmbito acadêmico (conforme as informações obtidas nas referências).

2.3.2 Outros gerenciadores de documentos

Comercialmente, o controle de versões tem se tornado uma importante funcionalidade oferecida por vários sistemas gerenciadores de documentos. Exemplos de alguns destes produtos são o MKS [MKS], o ORACLE InterOffice [ORACLE], o Office.IQ [OFFICE] e o KeyFile [KeyFile].

Estes podutos apresentam um conjunto de operações básicas para o controle de versões que permite a manutenção e consulta do histórico de um documento. No InterOffice é possível a edição de versões passadas. As versões possuem um status indicando se estão sendo editadas (edit) ou se é uma versão publicável (published) e que pode ser recuperada por outros usuários. No Office.IQ há o conceito de versão obsoleta, atendendo ao requisito da norma ISO9000 [ISO] para identificação de documentos que não devem mais ser recuperados. Estes produtos contam também com funcionalidades de controle de acesso às versões, questão que não é abordada pelo controle de versões do GDOC.

A grande diferença entre o controle de versões deste sistemas e o mecanismo proposto para o GDOC é dada pelas próprias características do modelo de documentos sobre o qual o controle de versões foi definido (vide capítulo 3). O fato dos documentos no GDOC poderem ser estruturados, ao contrário destes sistemas que tratam de documentos simples, implica uma série de controles extras que oferecem vantagens, como por exemplo, a manutenção sempre atualizada de um documento, independente das alterações nos componentes. Por outro lado, são necessárias restrições e outros mecanismos para a manutenção da consistência entre os documentos relacionados, que não são são encontrados nos mecanismos para controle de versões de documentos não estruturados.

2.4 Conclusões

Este capítulo apresentou o modelo de versões de [GOL 95b], que é o utilizado como base desta proposta, enfocando os aspectos que serão empregados no controle das versões de documentos. Foram apresentados também os mecanismos para a notificação e propagação de mudanças que, embora não sejam abordados em [GOL 95b], são tratados pela bibliogafia relacionada e são utilizados neste trabalho para a manutenção da consistência dos documentos.

Como documentos estruturados e hipertextos possuem uma estrutura semelhante, os conceitos discutidos foram analisados no contexto de sistemas de hipertextos com controle de versões. A maioria dos conceitos está presente nos sistemas, mas com particularidades dadas pelas aplicações para as quais foram projetados. Foi indicado, em linhas gerais, como estes aspectos serão abordados pelo controle de versões do GDOC que, devido ao modelo utilizado, apresenta características não encontradas nos outros sistemas. Estes aspectos serão aprofundados nos capítulos subseqüentes.

Também foram apresentadas as características de versionamento de alguns gerenciadores de documentos disponíveis comercialmente. Neste caso, o controle de versões proposto para o GDOC diferencia-se pela própria forma de tratamento dos documentos.

3. GDOC: um sistema gerenciador de documentos

Este capítulo apresenta as principais características e o modelo conceitual da base de documentos do sistema GDOC. Este modelo é definido em função de três partes interrelacionadas: uma que refere-se ao armazenamento do conteúdo e da estrutura dos documentos, outra que define o armazenamento dos tipos de documentos e uma terceira relacionada às formas de apresentação dos documentos.

Esta apresentação concentra-se nas duas primeiras partes do modelo, que compreendem os aspectos que serão abordados pelo controle de versões. Uma descrição mais abrangente do modelo de documentos do GDOC bem como de sua arquitetuta é apresentada em [GRA 97].

3.1 Caraterísticas principais

O GDOC é um sistema para autoria e armazenamento de documentos em um ambiente de Intranet, cuja a principal aplicação é o controle da documentação de produtos com vistas à obtenção do certificado de qualidade ISO 9000.

Os documentos no GDOC são armazenados em um banco de dados relacional, sendo considerados documentos virtuais [VER 97], ou seja, um documento é gerado "on-line", como resposta a uma consulta. Além disto, os documentos podem ser estruturados, o que permite caracterizá-los não somente pelo seu conteúdo, mas também pela sua estrutura lógica, imprimindo um maior significado ao conteúdo deste documento para o usuário. Um documento estruturado logicamente pode ser dividido em componentes como título, parágrafo e atributos.

O conceito de documentos estruturados é recursivo, isto é, um documento pode ser componente de um outro documento e o mesmo componente pode ser compartilhado por diferentes documentos. Esta funcionalidade permite que num ambiente industrial, por exemplo, o desenho de uma peça apareça tanto num documento relacionado à inicialização de uma máquina de produção como num documento com normas para controle de qualidade.

Uma característica particular do GDOC é dada pela sua arquitetura, que combina o armazenamento dos documentos em tabelas relacionais associados a códigos de apresentação HTML [LEE 93] e manipulados pela linguagem Java [SUN 96]. Esta combinação permite que o usuário tenha acesso ao sistema através de um "Web browser" e que a estrutura do documento seja gerenciada por uma aplicação de banco de dados relacional.

As vantagens do uso destas tecnologias é que estão baseadas em padrões abertos (protocolo Internet, Java e SQL) garantindo uma aplicação independente de plataforma. Além disto, o uso de "WEB browsers" está se tornando cada vez mais comum, reduzindo para o usuário final o esforço de aprendizado de novas interfaces.

3.2 O modelo de documentos

O modelo de documentos do GDOC é composto de três partes interrelacionadas:

• modelo de instâncias, que compreende as classes que armazenam as instâncias dos documentos;
• modelo de apresentação, que define as classes que contém informações utilizadas na apresentação do documento no "Web browser", e
• modelo do esquema com as classes que armazenam a estrutura do tipo do documento.

No GDOC cada documento é representado como uma instância da classe Documento, podendo ser especializado nos tipos primitivos texto, figura, atributo, composto e elo, conforme ilustra o modelo de instâncias descrito na figura 3.1. A notação usada para representar este e os outros modelos conceituais ao longo desta dissertação é a UML (Unified Modeling Language) [UML 97] e o termo documento será empregado neste trabalho como sinônimo de instância de documento.

Um documento do tipo primitivo Texto contém um texto não estruturado armazenado no atributo conteúdo, na forma de um "string" HTML. Um texto pode ser de qualquer tamanho, de uma simples palavra a um documento inteiro. Formatos de a apresentação de um documento que não estão relacionados com a estrutura são inseridos diretamente no texto na forma de código HTML, como por exemplo, um parágrafo com palavras em itálico ou negrito.

Um documento do tipo Figura contém um objeto que é manipulado via OLE por uma outra aplicação, como um programa de edição gráfica, por exemplo. Do ponto de vista do GDOC, os documentos do tipo Figura são não-estruturados. Largura e altura são atributos de dimensão definidos pelo usuário para apresentação da figura no documento. Borda define o tamanho do borda da figura. A legenda contém um texto alternativo que é exibido quando não é possível exibir a figura propriamente dita. Por exemplo, quando o programa chamado via OLE não está disponível.

O tipo Composto define um documento composto de outros documentos, denominados seus componentes. O documento composto possui uma estrutura de árvore, de forma análoga aos documentos compostos dos modelos ODA[BRO 89] e NR/SD [MOR 97], e está associado com os seus componentes pelo relacionamento Componente. O componente de um documento pode aparecer numa ordem específica, dada pelo atributo seqüência da classe Componente, além de ele próprio poder ser um documento composto.

Os atributos de um documento também são considerados documentos, mas do tipo primitivo Atributo. Um atributo é utilizado para armazenar propriedades associadas a um documento composto, como a data de criação e o nome do autor. Atributos podem ser empregados para a construção de expressões de consulta na pesquisa de documentos, além de serem utilizados pelo sistema de workflow do GDOC e no controle de versões (ex.: um atributo de comentário para a versão).

Documentos podem estar associados através de elos, ou "hyperlinks" [LEE 93]. Um elo é definido por uma âncora, que é a região (ex.: texto ou figura) que o usuário seleciona para navegar até um documento destino. Neste modelo, um elo é definido como um documento do tipo primitivo Elo associado a dois outros documentos: um que faz o papel da âncora (relacionamento âncora) e outro que é o seu destino (relacionamento destino). Um documento elo é sempre um componente de outro documento.

A figura 3.2 ilustra a estrutura lógica de um documento composto manual_industrial que possui quatro documentos componentes na seguinte ordem:

1. documento título_logotipo, do tipo primitivo figura;
2. documento introdução, do tipo primitivo texto, representando um parágrafo;
3. documento normas_de_montagem, do tipo primitivo composto, formado pelos documentos desenho_da_peça, do tipo primitivo figura, e montagem, representando um parágrafo do tipo primitivo texto, e
4. documento rodapé, do tipo primitivo texto, representando outro parágrafo.

3.2.2 O modelo de apresentação

No GDOC a forma de apresentação de cada documento é armazenada separadamente de seu conteúdo, nas classes definidas pelo modelo de apresentação. Esta abordagem permite que um documento componente tenha diferentes apresentações, dependendo do documento composto no qual ele aparece, ao contrário de linguagens de autoria para a "Web", como HTML, em que o código da apresentação está intercalado com o conteúdo do documento. A relação entre um documento e a sua forma de apresentação é ilustrada na figura 3.3

O código de apresentação de cada documento é armazenado como uma instância da classe Apresentação. Cada instância desta classe contém dois atributos com código HTML, o preScript e o postScript. O primeiro armazena o código HTML que deve ser processado antes do conteúdo do documento ser exibido. O segundo, o código HTML que deve ser processado após a exibição deste conteúdo. Por exemplo, para que o texto título_padrão da figura 3.2 fique em negrito, o preScript da sua apresentação deve ser o código HTML <B>, para inicializar a formatação de negrito e o postScript, </B>, para finalizar a formatação.

O modelo de apresentação do GDOC permite que um documento tenha duas apresentações mutuamente exclusivas: a apresentação do documento, utilizada quando o documento for apresentado isoladamente, ou seja, não como componente de outro, e a apresentação do componente, aplicada quando o documento aparece num contexto, como componente de outro documento. Por exemplo, o texto título_logotipo da figura 3.2 quando manipulado isoladamente é visualizado em negrito, ao passo que quando apresentado como componente de um outro documento, neste caso manual_industrial, pode estar centralizado e com outro tamanho de fonte, como mostra a figura 3.4.

Desta maneira um documento presente em diferentes documentos compostos pode ter diferentes apresentações, uma em cada documento composto no qual ele aparece.

3.2.3 O modelo de esquema

A definição de um documento no GDOC é feita seguindo uma estrutura lógica e de apresentação pré-estabelecidas pelo Tipo do documento, de modo que no momento da autoria o usuário fornece apenas o conteúdo do documento. Os tipos de documentos são armazenados no modelo de esquema, descrito na figura 3.5.

Figura 3.5 O modelo de esquema

Documentos também podem ser criados num estilo ad-hoc. Neste caso, estão associados a um tipo livre que permite que a estrutura do documento seja definida pelo usuário em tempo de autoria.

Cada tipo de documento pode ser especializado nos tipos primitivos texto, atributo, figura, consulta e composto. Esta última especialização permite que a composição de um documento seja feita por uma seqüência, definida pelo relacionamento Componente de Seqüência, que estabelece que os componentes de um documento deste tipo aparecem numa ordem pré-estabelecida, ou por uma alternância, definida pelo relacionamento Componente de Alternância, quando apenas um componente aparece, mas ele pode ser de diferentes tipos. Os atributos minoc e maxoc definem os números mínimo e máximo de instâncias de um tipo de componente que podem aparecer num documento composto.

Como exemplo da definição de um tipo, consideremos o documento manual_industrial (figura 3.2) como do tipo manual genérico, que possui a seginte estrutura lógica:

1. um documento do tipo "Logo" , representando uma figura;
2. um documento do tipo "P", representando um parágrafo de texto;
3. uma alternância entre um documento do tipo "F" (uma figura) ou um ou mais documentos do tipo "Corpo" que, por sua vez, é composto de um atributo e uma figura;
4. uma seqüência de um ou mais documentos do tipo "P" que são parágrafos de texto.

A autoria de cada documento é feita por um programa específico, determinado pelo atributo aplicativo. A classe Consulta armazena consultas SQL que são usadas para recuperar atributos de um banco de dados externo, permitindo colocar dados de outras bases de dados em documentos gerenciados pelo GDOC.

O relacionamento de uma instância de documento, definida pelo modelo de instâncias, com o seu tipo, definido pelo modelo de esquema, é ilustrado na figura 3.7.

Os tipos de documento também estão associados a formas de apresentação, que são utilizadas para exibir os documentos daquele tipo. Uma forma de apresentação é considerada a padrão. Opcionalmente, o tipo de documento pode ter formas de apresentação alternativas, que podem ser escolhidas pelo usuário durante a autoria do documento.

3.3 Conclusões

Neste capítulo foram apresentadas os principais aspectos da arquitetura e do modelo de documentos do sistema GDOC, destacando-se os seguintes pontos:

• o GDOC combina as tecnologias de bancos de dados relacionais e a linguagem HTML para armazenar os documentos e a manipulação (visualização e autoria) é feita com "WEB browsers" e a linguagem Java;
• os documentos são estruturados, ou seja, possuem uma estrutura lógica que permite dividi-los em componentes, aumentando assim o significado do conteúdo dos documentos para o usuário;
• um documento pode ser definido como componente de outro e o mesmo documento componente pode ser utilizado em diferentes documentos;
• no GDOC um documento caracteriza-se por ser definido em função de três modelos interrelacionados, um que define sua estrutura lógica (modelo de esquema), outro que define sua forma de apresentação (modelo de apresentação) e o terceiro que armazena a instância do documento (modelo de instâncias).

4 Extensão do modelo de documentos com versões

Este capítulo apresenta uma extensão do modelo de documentos para o suporte a versões. Foram definidas novas classes e mecanismos para permitir o versionamento das instâncias de documentos. É discutida também a possibilidade de versionamento dos tipos de documentos, sendo apresentado um conjunto de primitivas para suporte a esta funcionalidade, mas com enfoque mais restrito que o dado ao versionamento das instâncias.

Os mecanismos associados ao controle de versões foram definidos com base no modelo de versões para bancos de dados orientados a objetos introduzido em [GOL 95b], que foi refinado levando em consideração as necessidades da aplicação de gerência de documentos.

4.1 O modelo de documentos com controle de versões

Uma versão de um documento é o registro do seu estado num determinado momento. No GDOC, a propriedade de ser versionado é uma característica de cada documento, ou seja, é o usuário quem estabelece para quais documentos é importante a manutenção de versões. Documentos que possuem versões são chamados de documentos versionados e aqueles que não possuem versões são os documentos não versionados (figura 4.1).

Para fornecer suporte ao controle de versões dos documentos, o modelo de instâncias do GDOC foi estendido, acrescentando-se duas novas especializações à classe Documento: DocumentoVersionado e Versão (figura 4.2).

Documentos que possuem versões são representados pela classe DocumentoVersionado, através de uma a estrutura que agrupa as versões de um mesmo documento. Uma instância desta classe possui, além das informações próprias do documento, como um nome e identificador, propriedades que são comuns a todas as versões deste documento versionado, como por exemplo primeira versão, última versão, número de versões.

As versões de um documento estão representadas na classe Versão. A versão é um documento que possui, além do identificador do documento versionado com o qual está associada, um identificador próprio, o que permite que a versão de um documento possa ser diretamente manipulada. Como a versão representa um documento, as especializações em tipos primitivos da classe Documento do modelo original passam a ser especializações da versão. Cada versão só faz parte de um documento versionado.

Um documento versionado possui uma versão que é sua versão corrente. Esta versão é a utilizada quando forem feitas referências a um documento com versões e é definida automaticamente pelo sistema como a versão do documento mais recentemente promovida ao status estável. Como uma versão só adquire este status quando ela for considerada "pronta" pelo usuário (vide seção 4.2), o modelo garante que versões com conteúdo inconsistente não são utilizadas por outros documentos.

Uma característica deste modelo é que um documento versionado e um não versionado são identificados da mesma maneira, permitindo que o usuário utilize tanto um quanto outro indiscriminadamente na construção de documentos compostos (vide capítulo 5). Além disto, a propriedade de um documento apresentar versões não precisa ser definida antecipadamente, ou seja, o usuário pode criar uma versão para um documento até então não versionado. O documento original passa a ser a primeira versão do novo documento versionado a partir da qual a nova é derivada.

4.2 Propriedades das versões

Cada versão é criada como sucessora da versão corrente, e esta é considerada sua antecessora. No entanto, o relacionamento de derivação é definido por uma estrutura de árvore, pois quando a versão corrente é uma versão configurada é considerado um caso especial de derivação em que tanto a nova versão como a versão configurada possuem a mesma antecessora (figura 4.6). O conjunto das versões de um documento representa o histórico da evolução deste documento numa linha de tempo.

Cada versão possui um atributo de status que identifica seu estágio de desenvolvimento e define, com base no seu valor, quais operações podem ser realizadas sobre a versão. O valor para o status de uma versão pode ser em trabalho, estável ou obsoleta.. Uma versão é criada com status em trabalho e permanece com este status enquanto estiver sendo modificada. Quando esta versão atingir um estado consistente, o autor pode promovê-la para o status estável. A nova versão estável automaticamente passa a ser versão corrente do documento, pode ser compartilhada por outros documentos e, portanto, não pode mais ter seu conteúdo alterado. Uma versão só pode ser criada com base em uma versão estável, o que garante a manutenção do histórico da evolução do documento.

Versões em trabalho ou versões estáveis que não possuem sucessoras podem ser removidas. No entanto, uma possibilidade interessante para o controle das versões de um documento é permitir que o autor mantenha no histórico do documento uma versão estável para a qual ele não quer que sejam feitas novas referências.

Como em [GOL 95b] os status definidos não oferecem esta possibilidade, este modelo acrescentou o status obsoleto, com base na definição de [SOA 95]. Uma versão obsoleta pode ser vista como uma especialização de uma versão estável, assumindo todas as suas características, mas com a diferença de que novas referências não podem mais ser feitas a esta versão. Os documentos com referência para a versão obsoleta são notificados para que possam ter suas referências atualizadas.

A tabela 4.1 apresenta um resumo das características de uma versão, conforme o valor de seu status.

Status	Características	EEspecializações	Novas características
Em trabalho	pode ter o conteúdo alterado pode ser removida não pode ser compartilhada pode passar à estável
Estável	é a versão corrente do documento pode derivar novas versões pode ser compartilhada não pode ser modificada pode ser removida se não possuir sucessoras e não estiver sendo utilizada em outros documentos	Obsoleta	continua sendo compartilhada, mas não podem ser estabelecidas novas referências à versão

A alteração do status da versão para estável ou obsoleta é feita através de uma operação explícita pelo autor da versão. No caso de documentos compostos, esta operação poderá estendida às versões dos documentos componentes.

4.3 Documentos compostos

Um documento no GDOC pode ser definido como composto de outros documentos, que são denominados seus componentes. A terminologia da relação estabelecida entre um documento composto e seus componente é semelhante a de objetos compostos [KIM 89], ou seja, diz-se que um documento A tem uma referência para B quando A contém o indentificador de B, e B é considerado componente de A. O documento principal da composição é o documento raíz. Os documentos que não são compostos são chamados de documentos simples.

Com o uso de versões, tem-se uma versão de um documento cujos componentes também são documentos versionados, devendo-se estabelecer a relação entre as versões de cada documento na hierarquia de composição.

Referências estáticas ou dinâmicas podem ser estabelecidas com os documentos componentes. O critério padrão adotado pelo modelo é a definição de referências dinâmicas, ou seja, o documento composto está associado apenas com o identificador do documento versionado que representa o componente, sem a definição de uma versão específica. Quando o documento composto for recuperado, é retornada a versão corrente do componente. Na figura 4.3 está representada uma parte do documento documento composto Manual_industrial com dois de seus documentos componentes, sendo que uma referência dinâmica foi estabelecida para o componente Título_logotipo.

Por outro lado, o usuário pode querer definir uma referência estática para a versão corrente do documento componente. Neste caso, quando o documento composto for recuperado, será sempre retornada esta versão do componente. Esta opção é interessante para os casos em que o usuário deseja saber explicitamente das modificações ocorridas nas versões dos componentes utilizados, com o objetivo de manter o histórico do documento composto (vide seção 4.6). Na figura 4.3, o documento Manual_industrial possui uma referência estática para a versão 2.0 do componente Normas_de_montagem.

Quando a versão de um documento composto é estabilizada, as referências para os documentos componentes utilizados não podem mais ser modificadas. Por outro lado, como o modelo adota referências dinâmicas como o critério padrão para as referências, a versão do documento composto, mesmo estável, mantém-se sempre atualizada, pois se novas versões forem criadas para os componentes, elas serão automaticamente referidas pelo mecanismo de atualização automática da versão corrente.

4.4 Documentos com versões configuradas

Para um documento composto que utiliza como componentes documentos versionados, poderá ser definida uma versão em que as referências são fixas para uma versão específica de cada componente. Esta versão é uma versão configurada (ou configuração) e possui o significado de "uma foto" daquele documento no momento em que a versão foi gerada.

Uma versão configurada correponde a um documento numa base de documentos sem o conceito de versões. Como representa o estado de um documento num determinado momento, são importantes pois permitem registrar o histórico da evolução deste documento.

A construção de uma configuração é feita a partir da versão corrente do documento composto, que é a versão base para este processo. Considerando que os documentos compostos são construídos hierarquicamente, este processo inclui a escolha de uma versão para cada componente desta hierarquia. O critério utilizado para esta escolha é o da versão corrente. Por exemplo, considerando o documento manual_industrial da figura 4.4, com referências dinâmicas para os componentes utilizados, a construção de uma configuração para a sua versão 1.0 inclui, de maneira recursiva, a escolha de uma versão para cada componente.

Neste processo, é selecionada a versão corrente de cada componente, sendo gerada uma versão configurada como sua sucessora, e a referência é feita para esta versão configurada. Quando a versão do documento composto estiver completamente especificada, é gerada uma versão configurada, como sucessora da sua versão base. A figura 4.5 mostra as versões configuradas geradas e as novas referências estabelecidas a partir do cenário ilustrado para o documento manual_industrial.

Assim como uma versão regular, uma versão configurada é gerada com status em trabalho, pode ser modificada, mas a alteração das referências só pode ser feita para outras versões configuradas, garantindo que versões configuradas são sempre completamente definidas. A promoção da versão configurada para estável transforma-a na nova versão corrente do documento, podendo ser utilizada como componente de outras versões, configuradas ou não. Esta característica permite que novos documentos sejam construídos utilizando componentes completamente definidos, além de garantir uniformidade ao modelo no tratamento de versões, configuradas ou não.

No entanto, uma configuração possui alguns aspectos particulares. Ela é gerada como uma cópia da sua antecessora, mas não possui referências dinâmicas. Se for criada uma nova versão a partir de uma versão configurada, esta nova versão possui como antecessora a versão base, e não a versão configurada (figura 4.6). Neste caso, a versão configurada é vista como uma "alternativa" da versão base. A nova versão não é configurada e pode sofrer qualquer alteração.

4.5 Operações sobre as versões

Um documento pode ter uma versão modificada, removida ou criada uma nova versão. A modificação de uma versão tanto no seu conteúdo, no caso de documentos simples, quanto na sua estrutura, no caso de documentos compostos, só ocorre se a versão estiver em trabalho. As outras operações oferecem mais possibilidades e são descritas abaixo. 

4.5.1 Criação de novas versões

Versões poderão ser criadas para documentos versionados ou não. No primeiro caso, a nova versão é criada como cópia da versão corrente e está em trabalho. A versão existente é considerada antecessora e a nova versão, sua sucessora. Este relacionamento se altera quando a versão corrente for uma versão configurada (figura 4.6), conforme descrito na seção anterior.

Quando é derivada uma versão de um documento não versionado, este o passa automaticamente para versionado. O documento original passa a ser a primeira versão, a partir da qual a nova é criada. As referências que haviam para o documento original passam a ser referências estáticas para a primeira versão.

O usuário também poderá criar documento versionado sem nenhuma versão associada. Esta possibilidade é bastante interessante pois permite que o usuário crie um documento composto utilizando como componentes documentos cujo conteúdo ainda não foi definido, caracterizando uma forma "top-down" de autoria.

Além do usuário poder explicitamente criar uma nova versão para um documento, este modelo conta também com o mecanismo notificação em que o sistema auxilia o usuário na criação de uma nova versão do documento composto quando ocorrem modificações nas versões dos componentes. Esta questão está vinculada ao mecanismo de notificação, sendo discutida na seção 4.6.

4.5.2 Remoção de versões

Versões em trabalho podem ser removidas sem restrições. Já para uma versão estável, sua remoção só é possível se ela não possuir nenhuma sucessora ou não estiver sendo utilizada em nenhum outro documento composto.

Por outro lado, o usuário pode estabelecer que uma versão estável não será mais utilizada atribuindo-lhe o status obsoleto. A versão obsoleta permanece no histórico das versões do documento, mas novas referências não podem ser estabelecidas para ela. Os documentos com referências a uma versão que passou a obsoleta são avisados através do mecanismo da notificação para que possam ser atualizados.

Os documentos componentes são considerados independentes do documento composto [KIM 89]. Logo, a remoção de uma versão do documento composto não inclui a remoção de versões de seus componentes. Como conseqüência, pode ser necessário um processo de "garbage collection" para o tratamento dos documentos que só eram referidos pela versão removida. O modelo não implementa esta funcionalidade, mas a classe Componente possui informações que poderão ser empregadas com este objetivo.

4.6 A notificação das atualizações

Numa ambiente com documentos compostos, em que os componentes apresentam versões e podem ser compartilhados, modificações na versão de um componente devem ser avisadas aos documentos que o utilizam para que eles não fiquem desatualizados ou inconsistentes. Este modelo trata desta questão utilizando o mecanismo notificação [CHO 86, CHOU 88, KIM 89b] proposto para ambientes de CAD distribuído.

Conforme descrito na seção 2.3, a notificação pode ocorrer baseada em sinais ou baseada em mensagens. Na técnica baseada em sinais, cada versão do objeto possui duas marcas de tempo distintas. Uma é a marca de tempo de notificação CN ("change-notification timestamp"), que indica o momento em que a versão foi criada ou a última vez em que foi modificada. A outra é a marca de tempo de aprovação CA ("change-approval timestamp"), que indica a última vez em que o proprietário da versão aprovou as mudanças.

Considerando um conjunto I de versões para as quais uma versão V faz referência, V é considerada consistente em referências se nenhuma marca de tempo de notificação das versões em I exceder a marca de tempo de aprovação de V (isto é, se para todo X Î I, X.CN =< V.CA). Para tornar V consistente em referências, os efeitos das atualizações em I devem ser conhecidos, havendo duas opções: a) as atualizações em I não têm efeito em V e, neste caso, V.CA recebe a hora corrente, ou b) V precisa ser modificada, quando V.CN (e possivelmente V.CA se as mudanças forem aprovadas) recebem a hora corrente. Enquanto tais ações não são tomadas, V está inconsistente em referências.

Para a implementação desta técnica, a cada versão é associada uma tabela denominada Tabela de Componentes (figura 4.7) com as seguintes informações sobre as versões utilizadas dos objetos componentes: número de componentes da versão, o método de notificação de mudança (se baseado em mensagens ou sinais), o tipo de evento que requer notificação (criação, remoção ou atualização da versão) e um conjunto de descritores dos componentes. Cada descritor contém a identificação da versão referida e o tipo de referência usada, se estática ou dinâmica.

Para implementar a notificação baseada em mensagens, a cada versão V deve estar associada uma lista de referências inversas contendo as versões que fazem referência a V e que devem ser notificadas das mudanças em V (figura 4.8). Quando uma versão com uma lista de referências inversas não vazia é modificada, a lista é percorrida e os proprietários das bases de dados que contêm as versões da lista são notificados.

4.6.1 Forma de notificação adotada no modelo

O mecanismo de notificação adotado para este modelo é uma combinação das técnicas baseada em mensagens e em sinais. O uso da técnica baseada em mensagens facilita para o usuário a tarefa de manter os documentos atualizados, evitando-se o risco de que atualizações que afetam documentos pouco recuperados, mas não menos importantes, passem desapercebidas. Por outro lado, a técnica baseada em sinais é importante pois permite que, se o usuário não proceder com as atualizações após o recebimento da mensagem, ele é avisado ao recuperar a versão do documento que utiliza uma versão modificada. No enfoque adotado pelo modelo o envio das mensagens é imediato e somente os documentos compostos que fazem referência direta a versão são notificados.

O mecanismo de notificação será operacional apenas para as versões com referências estáticas para os componentes cujas versões foram modificadas. São consideradas as modificações as seguintes operações:

• promoção de uma nova versão para o status estável;
• passagem de uma versão para o status obsoleto.

O usuário, ao recuperar a versão de um documento composto que possui uma marca de notificação dispõe das seguintes opções:

1. atualizar as referências para os componentes modificados, sendo criada uma nova versão, sucessora da versão recuperada, ou
2. manter a versão recuperada com as referências inalteradas, ignorando o aviso de notificação.

4.7 Evolução dos tipos de documento

Assim como as instâncias, os tipos de documentos também podem sofrer alterações. A alteração de um tipo consiste na remoção ou inclusão de novos componentes na estrutura lógica que define um documento, caracterizando uma forma de modificação análoga à evolução de classes quando se trata de evolução de esquema em bancos de dados [KIM 88, MON 92, TAL 93, LAU 97].

O uso de versões no tratamento da evolução de classes envolve uma série de controles, como por exemplo o tipo de alteração (se inclusão ou remoção de atributos) de uma versão da classe para a outra, a associação das versões das instâncias com as versões das classes e mecanismos para atualização automática das instâncias quando há uma nova versão para a respectiva classe [MON 92, LAU 97] .

Com base nas características do modelo de esquema (figura 3.5), os mecanismos necessários para o controle de versões dos tipos de documentos são semelhantes aos requeridos para o versionamento das instâncias. Porém, as especificações propostas para o versionamento dos tipos permitem um controle mais simples se comparado ao versionamento das instâncias e a outros propostas que suportam o versionamento de instâncias e classes [TAL 93]. No entanto, estas especificações são feitas de forma que poderão ser estendidas permitindo acrescentar mais funcionalidades.

Um tipo composto pode ter novos componentes acrescentados ou removidos da sua estutura. O usuário poderá armazenar estas modificações numa nova versão do tipo, caracterizando-o como versionado. Nesta proposta, o uso de versões se aplica somente aos tipos compostos, armazenados na classe Composto_T do modelo de esquema.

Para o controle das versões dos tipos versões de um tipo foi definida a classe Tipo Versionado, que é uma especialização da classe Tipo de Documento do modelo de esquema (figura 3.5). Nesta classe ficam agrupadas as versões de um tipo, formando o seu histórico. Seus atributos consistem de informações específicas de cada tipo (ex.: nome), além de informações sobre as versões (ex.: primeira versão, versão corrente), semelhante à classe Documento Versionado do modelo de instâncias.

O usuário não precisa estabelecer previamente se um tipo terá versões ou não. Quando é criada uma versão para um tipo até então não versionado, o tipo original passa a ser sua primeira versão, e a versão criada, a segunda. Os documentos que faziam referência ao tipo original ficam automaticamente associados à primeira versão do tipo que agora é versionado. A estrutura de novos documentos criados a partir de tipos versionados é definida sempre pela versão mais recente do tipo.

Quando um tipo possui uma nova versão, os documentos já existentes permanecem associados à versão anterior do tipo, ou seja, este modelo não dispõe de funções para atualização (ou visualização) automática de um documento de acordo com a nova versão do tipo.

No caso de documentos que apresentam versões, esta atualização é feita criando-se uma nova versão para o documento, cuja estrutura será dada pela nova versão to tipo

Considere, por exemplo, o tipo manual_genérico representado na figura 4.11. Foi excluído o seu componente Parágrafo e esta modificação foi armazenada na versão v2.0 deste tipo. Para atualizar o documento manual_industrial de acordo com a nova estrutura do tipo, foi criada a versão 3.0, sucessora da versão anterior, mas com a nova estrutura lógica. Desta forma, é possível acompanhar a evolução de um documento decorrente tanto de alterações no seu conteúdo quanto na sua estrutura.

4.8 Conclusões

Este capítulo apresentou o modelo de versões proposto para o GDOC enfocando dois aspectos do modelo de documentos da aplicação: o documento, ou instância de documento (modelo de instâncias) e a sua estrutura, ou tipo (modelo de esquema).

Documentos podem ser versionados ou não e a passagem de um documento não versionado para versionado é feita dinamicamente, sem a necessidade de controles adicionais. Para o controle de versões dos documentos versionados foram acrescentadas duas novas classes ao modelo de instâncias.

Foram definidas as características e as operações que podem ser feitas numa versão de acordo com o seu grau de consistência. Na construção de um documento composto, foi apresentada a possibilidade de estabelecer dois tipos de ligações com os documentos componentes: uma em que são utilizadas as versões mais atualizadas dos componentes (referências dinâmicas), e outra em que são utilizadas versões específicas (referências estáticas). Para este segundo caso foi apresentado o mecanismo de notificação, que avisa o documento composto de alterações ocorridas nas versões dos componentes utilizados.

Foi apresentada a possibilidade de definir uma versão configurada, que corresponde a uma versão em que todas as ligações estão definidas. Configurações são importantes pois permitem registrar o estado de um documento composto num determinado momento do tempo.

Foram acrescentados mecanismos ao modelo de esquema que possibilitam o uso de versões nas alterações dos tipos de documentos e permitem ao usuário estabelecer uma ligação entre as versões de um documentos cuja estrutura é dada por versões diferentes de um mesmo tipo. Desta forma o histórico de um documento pode ser mantido sob dois aspectos: para alterações tanto na sua estrutura quanto no seu conteúdo.

1. Implementação

Na seção 5.1 são apresentados o ambiente utilizado e a arquitetura da aplicação.

5.1 Ambiente e arquitetura

O ambiente do aplicativo é definido por uma arquitetura do tipo Intranet. Uma Intranet consiste de uma rede local baseada num conjunto de protocolos Internet e baseia-se a aplicativo (ou applet) foi construído com a linguagem Java.

Este tipo de arquitetura basea-se no princípio cliente-servidor, onde o elemento cliente de um browser HTML estendido com applets escritos em Java. No lado do servidor ficam os servidores WWW e o de banco de dados.

Intranets têm sido largamente utilizadas como base para o desenvolvimento de sistemas de informação. Como os componentes deste tipo de arquitetura (protocolo Internet, linguagem Java, SQL) são baseados em padrões abertos, o uso de Intranets é bastante vantajoso pois garante o desenvolvimento de aplicativos independentes de plataforma. Outro aspecto importante deste tipo de arquitetura é que os aplicativos do tipo browser já são considerados componentes básicos de qualquer computador conectado uma rede. A sua utilização e o funcionamento de sua inteface estão se disseminando cada vez mais, o que reduz o tempo dispendido no aprendizado deste tipo de interface para novos usuários.

A arquitetura do GDOC está ilustrada na figura 5.1. Sua composição é dada por três componentes principais: compondo o elemento servidor estão o servidor de banco de dados e o servidor de HTTP, e no lado cliente da arquitetura está o browser WWW acrescido dos applets Java que definem o aplicativo propriamente dito.

A interface para visualização e autoria dos documentos é feita no browser HTML . Nesta interface, o usuário dispõe de um menu com as operações para manipulação dos documentos. Exemplos destas operações são recuperação de um documento da base de dados, criação de de um novo documento, edição, etc...

Quando uma operação é escolhida pelo usuário, é estabelecida uma comunicação entre o aplicativo cliente e os servidores, envolvendo os seguintes processos: o browser HTML envia a requisição desta operação para o servidor HTTP, que retorna o código Java correspondente a operação que será executada. A execução do código ocorre no lado cliente.

Por outro lado, é necessário uma comunicação entre o código Java e o servidor de banco de dados a fim de se obter e armazenar os dados referentes tanto à estrutura lógica quanto ao documento propriamente dito. O protocolo utilizado para a comunicação com o banco de dados é o JDBC (Java Database Conectivity) [JEP 97]. O JDBC é um protocolo aberto que permite o desenvolvimento de aplicativos em Java independentes do servidor de banco de dados utilizado, através da utilização de drivers para um de banco de dados específico.

No desenvolvimento do protótipo foi utilizado o banco de dados SQL Server 6.5 da Microsoft com o driver FastForward , da empresa ConnectSoftware, para comunicaçao com o JDBC.

5.2 Definição de novas classes

Mapeamento do modelo OO para banco de dados relacional

Classe VersionedDocument

Esta classe é uma redefinição da classe Documento. Contém informações e métodos comuns ao processo de autoria de documentos e métodos e atributos específicos para o controle de versões dos documentos versionados.

Classe Documento

Atributos

id: int;

name: string;

versionNo: int;

currentVersion: int;

firstVersion: int;

lastVersion: int

nextVersion: int;

versioned: int;

type: int;

pType: int;

dPresent: int;

cPresent: int;

linkType: char;

width: int;

border: int;

caption: string;

target: int;

targetVersion: int;

root: char;

linkUrl: string;

O atributo nome contém o nome do documento. Raíz indica se é um documento principal, ou seja, um documento cuja manupulação não depende de outros.

Os métodos novo, abrir, editar, salvar, salvarComo e remover executam as operações indicadas no processo de autoria dos documentos. ObterDocs retorna uma lista com todos os documentos do tipo informado, ou todos os documentos da base, caso não seja informado nenhum tipo. O método obterTipo retorna o tipo, do esquema de Tipos, para o documento. ObterTipoPrimitivo indica, para um documento especializado, qual a sua especialização, ou tipo pimitivo (ex.: figura, texto, elo...). Os métodos obterNome e éRaiz retornam as informações indicadas.

Classe DocumentSchema:

Esta classe contém os tipos de documentos definidos pelo autor.

DocumentSchema

Atributos

Id:int

VersionNo: int; // é 1 para todos os tipos

Name: string

Tool: string;

Query:string;

Classe VersionedSchema

Atributos

Id:int

VersionNo: int

Name: string

Ctype: char

CurrentVersion: int (no começo, é 1 para todos os docs)

FirstVersion: int

LastVersion: int

NextVersion:int

Classe Versão

Uma versão é um documento que contém atributos e métodos adicionais necessários para sua manipulação e para o controle das versões de um documento.

Classe Version:

Atributos

IdDoc: int

VersionNo: int

Name:string

Status: char

Date: date

Author: string

antecessor: int

configured: int

coments: text;

content: int

Métodos:

deriveVersion ( );

getSucessor: int;

getStatus: char;

promote ( );

makeObsolete ( );

getName ( ): string

getDate( );

getAuthor ( );

getComments ( );

getContent ( );

getConfiguration( );

O nome da versão é dado pelo atributo nome. Status refere-se ao status da versão, que pode ser em trabalho, estável ou obsoleta. O atributo data contém a data de criação da versão e configurada indica que a versão é uma versão configurada.

O método abrir recupera, por default, a versão corrente do documento informado. Caso o documento só possua uma versão em trabalho ou a versão corrente esteja obsoleta, serão retornadas estas versões com indicações de seus status.

A operação estabilizar promove para o status estável a versão informada que passa a ser a nova versão corrente do documento. Com a operação tornarObsoleta a versão adquire o status obsoleto, o que indica que novas referências não podem mais ser feitas a esta versão. Em ambos os casos, se a versão informada for de um documento composto, o autor poderá estender a operação aos componentes da versão com a cláusula all. As operações de estabilizar ou tornarObsoleta ativam a operação de notificação para os documentos com referência à versão atualizada que solicitaram recebimento de aviso destas atualizações.

ObterStatus, obterNome, obterData, obterAntecessora e obterSucessora retornam as informações indicadas.

A operação configurar define uma configuração para a versão informada.

Classe Component

Nesta classe é estabelecido o relacionamento de composição entre um documento e seus componentes. Para o funcionamento do mecanismo de notificação do controle de versões, esta classe foi redefinida sendo acrescentados novos atributos e métodos específicos para este processo.

Classe VersionedComponent

Atributos

ComponentId: int

ComponentVersionNo: int

Compositeid: int

CompositeVersionNo: int

Sequence: int

NotificationType: char;

O atributo seqüência indica a ordem na qual o documento componente é incluído na composição do documento composto. O atributo seloNotificação, quando verdadeiro, indica que o documento composto recebe mensagem de notificação das atualizações deste componente. TipoAtualização contém o tipo da operação que provocou o aviso de notificação, podendo assumir o valor "E" para a estabilização de uma nova versão ou "O", indicando a passagem da versão para o status obsoleto. Quando este atributo possui um destes dois valores, significa que há uma notificação para o documento.

O método obterComponentes retorna uma lista com a versão corrente dos componentes do documento informado e inserirComponente estabelece a relacão de composição com uma referêcia dinâmica entre as versões corrente do documento composto e do documento componente. Na operação de configuração, esta referência fica estática o método estabelecerRefEstática.

Na definição de uma composição, o método marcarSeloNotificação marca o atributo notificação para aqueles documentos componentes que vão gerar aviso de notificação para os seus respectivos documentos compostos. O valor deste atributo é retornado pelo método temSelo.

5.2.1 Identificação e armazenamento de documentos versionados e não versionados

Documentos não-versionados também são armazenados na classe VersionedDocument. Sua indetificação é semelhante a de um documento com versões, de modo que referências podem ser feitas indiscriminadamente para ambas as categorias de documentos. O identificador de um documento (versionado ou não) apresenta a seguinte estrutura:

Documentos não-versionados possuem número de versão 1, ou seja, a instância do documento é considerada a versão única. Um documento versionado possui número de versão 0 e o número referente à versão que será recuperada é dado pelo atributo versão corrente do documento versionado. Além de garantir uniformidade no tratamento, esta forma de identificação permite que documentos passem dinamicamente de não versionados para versionados, ou seja, o usuário não pecisa antecipar se um documento terá versões ou não pois uma versão poderá ser criada para um documento anteriormente não versionado. O documento não versionado existente passa a ser a primeira versão, da qual a nova é derivada.

5.2.2 Representação de referências estáticas e dinâmicas

A representação das referências dinâmicas na classe Componente é ilustrada pela figura 4.4. O valor null para o atributo Id Versão do componente indica que a referência é para a versão corrente deste componente.

Classe Componente:

Classe Componente

5.2.3 Controle de versões de elos e atributos

Um documento do tipo elo é um documento composto pelos documentos âncora e destino. Na definição de um elo, tanto os documentos âncora como destino poderão ser versionados, ficando estabelecidas referências dinâmicas para estes documentos. Neste caso não há a possibilidade de alteração das referências para estáticas.

Porém, este modelo não prevê o versionamento do documento elo propriamente dito, pois considera-se que a atualização de um elo é efetuada nos seus componentes âncora e/ou destino, para os quais há controle de versões. Além disto, a manutenção de versões para um documento do tipo primitivo elo exigiria um esforço extra por parte do autor documento pois ele poderia ter versões do mesmo elo fazendo referência a diferentes versões de uma âncora e diferentes versões de um documento destino.

Considerando um elo um documento composto, pode se dizer que os componentes do elo são referidos indiretamente pelo documento composto ao qual o elo pertence. Logo, poderiam estar sujeitos a operações que envolvem toda a composição, como a mudança de status. No entanto, o modelo considera que os componentes do elo não "fazem parte" (semanticamente) do documento composto. Conseqüentemente, as operações aplicadas à toda a composição não têm efeito sobre os componentes do elo.

3. Interface do Controle de Versões

6 Referências Bibliográficas