5.1.1. Determinação da área de aplicação

Normalmente, quando uma empresa resolve aderir à tecnologia baseada em SGML, pretende reformular todo o seu sistema de suporte à documentação, i. e., pretende que todos os documentos que circulam na empresa estejam integrados, classificados e que obedeçam todos à mesma filosofia. Tudo isto faz com que o primeiro passo da análise passe pela identificação dos tipos de documento que circulam e habitam no universo que se pretende remodelar. Eric van Herwijnen [Her94] diz em relação a este ponto: "quando se está a pretender aplicar SGML para sistematizar/formalizar um universo documental, está-se a tentar aplicar ordem ao caos".

A ideia é agrupar documentos com propriedades semelhantes em classes. Por exemplo, documentos encontrados nas prateleiras de uma biblioteca são livros; textos que são enviados de uma pessoa para outra usando algum sistema de correio são cartas; documentos produzidos para descrever a utilização de produtos são manuais.

5.1.2. Definição de uma estratégia para o DTD

Um DTD desenhado de raiz para documentos que vão ser criados é diferente de um DTD desenhado para suportar documentação já existente (o que acontece quando já existe um património documental).

Portanto, nesta etapa, devem-se levantar interrogações sobre os objectivos do DTD que se está a desenhar, sobre o seu contexto e sobre a sua compatibilidade com documentos ou DTDs já existentes.

5.1.3. Identificação dos utilizadores

É necessário identificar os potenciais utilizadores para que todos sejam ouvidos. Isto evitará omissões e algum conflito quando mais tarde aqueles forem confrontados com o produto final.

5.1.4. O nome do DTD

Para aqueles que se habituaram a um modo de funcionamento anárquico, o SGML vai causar-lhes alguma frustração pois reduz o grau de liberdade do utilizador e isto vai reflectir-se a vários níveis. Um deles, é o nome com que se vai baptizar o DTD. Este deve ser elucidativo do tipo de documento que representa e deverá também coincidir com o elemento do topo da hierarquia definida para esse tipo de documento.

5.1.5. Os elementos lógicos do DTD

Um dos resultados da análise é uma lista de elementos, atributos e entidades. Os atributos e as entidades não fazem parte da estrutura hierárquica do documento. Os primeiros identificam propriedades dos elementos. Os últimos refletem a organização física do documento e estão relacionados com a forma de armazenamento e manuseamento do documento. Nesta fase, o objectivo é obter uma descrição da estrutura do documento; interessa, portanto, encontrar e distinguir os elementos que logicamente compõem o documento.

O ponto de partida poderá ser a criação de uma lista de todos os elementos que se possam distinguir nos documentos pertencentes ao tipo de documento que se pretende especificar. Veja-se o seguinte memo (escrito em SGML):

<!DOCTYPE MEMO SYSTEM "memo.dtd">
<MEMO>
<PARA>Camarada Napoleão</PARA>
<DE>Bola de neve</DE>
<CORPO>
<P>Na obra intitulada "A Quinta dos Animais", George 
Orwell escrevia:
<C>... os porcos tinham muito trabalho, diariamente, 
com umas coisas chamadas ficheiros, relatórios, minutas 
e memos. Estes eram grandes folhas de papel que tinham 
de ser cuidadosamente cobertas com escritos, assim que
estivessem cobertas eram queimadas na fornalha...
</C> Será que o SGML teria ajudado os porcos? Qual 
a tua opinião?</P></CORPO>
</MEMO>

No exemplo acima os elementos lógicos são:

• O elemento MEMO que contém todo o memo.

• O elemento PARA que contém a identificação do destinatário do memo.

• O elemento DE que contém a identificação do emissor.

• O elemento CORPO que contém a parte textual do memo.

• O elemento P que contém o texto de um parágrafo.

• O elemento C que contém o texto de uma citação.

Durante este processo há questões que devem estar sempre presentes: Será necessário distinguir este elemento? Que é que se pretende fazer com ele?

Para que este processo seja o mais completo possível, o analista deve munir-se de vários documentos exemplo pertencentes ao mesmo tipo/classe e deve rodear-se ou escutar os futuros clientes e utilizadores desses documentos. Isto, na tentativa de cobrir todos os ângulos do problema.

Para o DTD dos memos, apesar de não estarem presentes no documento exemplo apresentado, podem-se ainda identificar elementos como ASSUNTO e ASSINATURA, ou mesmo um elemento mais complexo que visaria registar o percurso do documento dentro da instituição.

Por último, devem ter-se presentes os processamentos a que irão ser submetidos os documentos. Cada processamento pode ter implicações na estrutura.

O conjunto final de elementos deverá suportar todos estes requisitos.

5.1.6. Elemento ou atributo?

Sempre que se tenta criar modelos para objectos do mundo real, é-se confrontado com alguns casos marginais, os casos de fronteira. O desenho de DTDs não é diferente. Aqui o caso fronteira surge quando na especificação de um elemento se hesita entre elemento e atributo.

...  <A HREF="www.di.uminho.pt/~jcr">Home de Ramalho</A>...

... <A>
       <LABEL>Home de Ramalho</LABEL>
       <HREF>www.di.uminho.pt/~jcr</HREF>
    </A>...

Este problema crítico não tem, como boa parte dos problemas de engenharia, uma solução única, definitiva; será resolvido, caso a caso, procurando a melhor solução de compromisso. Contudo, apresentam-se a seguir alguns princípios que poderão ajudar a desambiguar:

• A informação é estrutural? Um objecto que por natureza deve estar obrigatoriamente presente na estrutura (por exemplo, o remetente ou o destinatário de uma carta) é um bom candidato a elemento.

• A informação qualifica o conteúdo ou faz parte de um padrão repetitivo? Uma carta pode ter a ela associada um indicador que identifica o seu tipo como "privada" ou "negócios", não estando relacionado estruturalmente com o elemento carta. Sempre que a informação puder ser descrita por um valor pertencente a uma lista enumerada, tem-se um bom candidato a atributo.

• A informação está relacionada com o aspecto visual? Os atributos não devem ser usados para descrever o aspecto visual da informação. Por exemplo, se se pretender realçar certas partes do texto, não se deve fazê-lo recorrendo a atributos, mas sim recorrendo a um novo elemento.

• A informação requer um processamento especial? Esta questão não é muito evidente para quem nunca tenha implementado um processador de SGML, mas é pertinente. O que não é evidente é que quando se opta por utilizar SGML está-se a optar por trabalhar com documentação estruturada em todas as fases do ciclo de vida. O processamento não é excepção e é orientado pela estrutura do documento, pelos elementos. No processamento, os atributos aparecem como algo secundário a que se pode aceder em caso de necessidade para melhor qualificar o processamento, mas o seu conteúdo é visto como um bloco. Portanto não deve colocar-se estrutura no valor de um atributo e qualquer item de informação que requeira um processamento especial deve ser um elemento e não atributo.

5.1.7. Determinação da estrutura hierárquica

Logo que todos os elementos de um dado tipo de documento tenham sido determinados, é necessário especificar as relações entre eles. No exemplo Exemplo 5-2, o elemento MEMO é a raiz da estrutura hierárquica, por isso, contém todos os outros. Por sua vez, os elementos PARA e DE não têm estrutura, apenas texto; o elemento CORPO contém uma sequência de parágrafos que por sua vez podem conter texto com alguns elementos pelo meio que identificam citações. Esta estrutura hierárquica pode ser observada na Figura 5-2.

A árvore estrutural do documento dá uma boa maneira de visualizar a sua estrutura; às vezes, torna-se difícil olhar para um texto anotado e tentar perceber qual a sua estrutura. No entanto, a árvore do documento não tem informação nenhuma sobre a frequência de cada um dos elementos: não diz quais são os opcionais e não distingue os que podem aparecer com repetições. Para isso há que recorrer a outra representação pictórica: os diagramas de estrutura.

5.1.8. Diagramas de Estrutura

Até agora, o resultado da análise documental, é um conjunto de elementos e a estrutura hierárquica onde estes se inserem. Daqui até ao que é necessário para escrever um DTD ainda existe alguma distância. Os diagramas de estrutura surgem para colmatar essa diferença. Um diagrama de estrutura é uma representação pictórica de um DTD, sem atributos (estes não têm representação no diagrama).

Para a construção do diagrama de estrutura de um determinado tipo de documento parte-se da árvore esboçada na secção anterior (Secção 5.1.7). Faz-se uma travessia da árvore de cima para baixo e da esquerda para a direita (depth-first). A cada nó da árvore vai corresponder um dos oito tipos de diagramas de estrutura. O diagrama de estrutura de cada um dos nós é desenhado olhando para os filhos desse nó e especificando para cada um deles, o seu tipo de frequência.

Para obter o diagrama de estrutura do memo (Exemplo 5-2), parte-se da árvore definida (Figura 5-2) e atravessa-se esta da maneira indicada em Figura 5-3; para cada nó desenha-se o respectivo diagrama de estrutura usando os oito tipos de diagrama que se descrevem a seguir.

Há oito tipos de diagrama de estrutura. Cada um corresponde a uma das estruturas básicas que um dado nó pode ter:

1. Um elemento dentro de uma caixa significa que esse elemento aparece uma vez.

   Figura 5-4. Um elemento

   

2. Uma caixa seguida de outra, em série, significa que o elemento da primeira caixa precede o segundo e que ambos ocorrem uma vez.

   Figura 5-5. Sequência

   

3. Duas caixas em paralelo significa que um dos elementos terá de estar presente, mas apenas um.

   Figura 5-6. Alternativa

   

4. Duas caixas em série, em paralelo, com a mesma série invertida, significa que ambos os elementos devem aparecer mas a ordem é livre.

   Figura 5-7. Qualquer ordem

   

5. Uma caixa com uma seta de feedback significa que o elemento deve aparecer uma ou mais vezes.

   Figura 5-8. Uma ou mais vezes

   

6. Uma caixa com uma seta a fazer-lhe um "bypass" significa que o elemento é opcional.

   Figura 5-9. Opcional

   

7. Uma caixa com uma seta de feedback e outra de "bypass" significa que o elemento pode aparecer um número indefinido de vezes (zero ou mais vezes).

   Figura 5-10. Zero ou mais vezes

   

8. Uma caixa, igual ao primeiro diagrama, mas com um triângulo negro no canto inferior direito, é usada se um nodo não tiver subnodos, i.e., se for uma folha.

   Figura 5-11. Elemento terminal

   

Então, os diagramas de estrutura resultantes da travessia da árvore do memo são:

• Primeiro nodo (marcado com 1 na Figura 5-3) respeitante ao elemento MEMO. Tem 3 subnodos, PARA, DE, CORPO. Até agora nada foi dito sobre a sua sequência ou frequência. Para tornar o exemplo interessante e elucidativo assume-se que CORPO vem no fim e que a ordem dos outros dois é irrelevante. Estes pressupostos dariam origem ao seguinte diagrama:

  Figura 5-12. Diagrama de Estrutura do elemento MEMO

  

• Segundo nodo (marcado com 2): o elemento PARA é terminal, o seu conteúdo é apenas texto.

  Figura 5-13. Diagrama de Estrutura do elemento PARA

  

• Terceiro nodo (marcado com 3): o elemento DE também é terminal.

  Figura 5-14. Diagrama de Estrutura do elemento DE

  

• Quarto nodo (marcado com 4): o elemento CORPO é composto por um ou mais parágrafos (P).

  Figura 5-15. Diagrama de Estrutura do elemento CORPO

  

• Quinto nodo (marcado com 5): o elemento P tem aquilo que se designa por conteúdo misto - essencialmente texto mas podem aparecer algumas citações pelo meio.

  Figura 5-16. Diagrama de Estrutura do elemento P

  

• Sexto nodo (marcado com 6): o elemento C é composto por texto.

  Figura 5-17. Diagrama de Estrutura do elemento C

  

Como o leitor atento pode já ter constatado existe quase uma correspondência de um para um entre os tipos de diagramas de estrutura e os operadores de conexão e de ocorrência que se usam para escrever o DTD. Assim e no caso do memo, para escrever o DTD basta escrever a declaração correspondente ao diagrama de estrutura que se determinou para cada elemento. Apresenta-se a seguir o DTD para o memo (Exemplo 5-4).

<!-- DTD para o MEMORANDUM - jcr - 99.01.09 -->
<!-- Elemento MEMO -->
<!ELEMENT MEMO - - ((PARA & DE) , CORPO)>
<!-- Elemento PARA -->
<!ELEMENT PARA - - (#PCDATA)>
<!-- Elemento DE -->
<!ELEMENT DE   - - (#PCDATA)>
<!-- Elemento CORPO -->
<!ELEMENT CORPO - - (P+)>
<!-- Elemento P -->
<!ELEMENT P - - (#PCDATA | C)*>
<!-- Elemento C -->
<!ELEMENT C - - (#PCDATA)>

As metodologias de análise baseadas em grafismos são de particular importância em projectos onde o diálogo com interlocutores não informáticos é necessário. Foi apresentada uma metodologia que assenta numa especificação gráfica: árvore hierárquica de componentes e diagramas de estrutura para cada um dos nodos. Para documentos de grande complexidade esta separação pode levar a algumas dificuldades na sua leitura pelo que, mais recentemente, surgiu a ideia de fundir as duas etapas. O formalismo gráfico foi designado por ELM-tree (Element Lucid Model - tree) e é introduzido em grande detalhe por Maler e Andaloussi [MA96]. A título de exemplo apresenta-se na figura seguinte a ELM-tree para o memo.