La metodologia è descritta graficamente in figura 6.2: la RMM si concentra sulle fasi di progetto, sviluppo e costruzione nel contesto del ciclo di sviluppo del software. Il punto chiave della metodologia, quando applicata a sistemi ipermediali, è la progettazione dei meccanismi d'accesso alle informazioni, realizzata nelle prime tre fasi, evidenziate nella figura dall'area grigia.
Le etichette sulle frecce nella figura rappresentano i vari prodotti intermedi generati dall'uso della metodologia. Sebbene presenti, i cicli di feedback tra le altre fasi non sono indicati, mentre quelli tra le fasi di progetto RMM sono indicati con linee tratteggiate.
Il primo passo della progettazione è la rappresentazione del dominio delle informazioni attraverso un diagramma E-R (Entità-Relazione), scelto per la sua diffusione (vedi ad esempio [EMN90, BDPLS93]) e perché può modellare le dipendenze tra le informazioni in numerosi campi di applicazione. Questa fase della progettazione si basa su uno studio delle entità e delle relazioni rilevanti nel campo dell'applicazione: queste entità formano poi la base del sistema informativo ipermediale e molte di queste saranno rappresentati come nodi e collegamenti in un'implementazione WWW del sistema.
Questa fase, propria delle applicazioni ipermediali, determina come le informazioni dell'entità in esame verranno presentate agli utenti e come essi potranno accedervi. Ne fa parte la divisione dell'entità in porzioni significative e l'organizzazione di queste in una rete di ipertesto. Nella sua forma più semplice, tutte le informazioni di un'entità possono essere visualizzate in una singola finestra (eventualmente con barre di scorrimento). Sebbene un approccio di questo tipo sia semplice per lo sviluppatore (e infatti molti servizi WWW sono progettati in questo modo), è spesso indesiderabile per l'utente, che può perdere l'orientamento quando si trova a dover scorrere lunghe porzioni di testo in una sola finestra.
Alternativamente, l'informazione può essere divisa in unità significative che possano essere rappresentate come oggetti separati ma correlati. Ad esempio, la figura 6.3 mostra l'entità ``facoltà'' divisa in quattro porzioni, contenenti rispettivamente informazioni generali, una breve biografia, aree di ricerca e un filmato.
L'organizzazione di entità in porzioni risulta in un diagramma in cui ciascuna porzione raggruppa uno o più attributi dell'entità. Ogni entità ha una porzione caratteristica, chiamata ``testa'', usata come punto di arrivo predefinito per i collegamenti che puntano all'entità.
Il diagramma delle entità modella anche la navigazione tra le porzioni attraverso collegamenti uni- e bi-direzionali: le etichette sui collegamenti bidirezionali denominano entrambe le direzioni. Questi collegamenti, che rappresentano connessioni tra le porzioni, sono chiamati collegamenti strutturali, in maniera consistente con la notazione HDM. I collegamenti strutturali differiscono dalle relazioni associative in quando le prime connettono pezzi di informazione interni a una stessa istanza di un'entità, mentre queste ultime collegano differenti istanze di entità, quasi sempre appartenenti a differenti classi. Dal punto di vista della navigazione, c'è una ragione importante per differenziare tra queste due connessioni: quando un utente segue una connessione associativa il contesto dell'informazione cambia (per esempio, in un ipertesto di dominio universitario, da una facoltà a un corso), mentre quando si attraversa una connessione strutturale il contesto resta interno alla stessa entità. Le due connessioni sono rappresentate differentemente nei diagrammi RMM, in modo da poter essere implementate nell'interfaccia attraverso elementi di tipo distinto che rendano evidente all'utente il differente ruolo nel sistema. Lo stesso concetto è anche chiamato coerenza (o ancora navigazione) globale e locale [THH95].
Il prodotto della fase di progettazione delle porzioni è un diagramma E-R arricchito, che chiameremo E-R+, ottenuto dal diagramma E-R aggiungendo ad ogni entità il suo diagramma delle porzioni.
In questa fase si realizza la struttura della navigazione ipertestuale. Ciascuna relazione associativa che appare nel diagramma E-R+ viene analizzata: se, in base all'analisi dei requisiti, una relazione associativa deve essere resa accessibile alla navigazione, viene rimpiazzata da una o più strutture RMDM. Siccome la RMM è pensata per sistemi aggiornati su base relativamente frequente, tutti i percorsi per la navigazione sono specificati in termini generici. Ciò significa che non vi sono collegamenti espliciti tra istanze di entità, ma piuttosto i collegamenti sono specificati con riferimento alle proprietà delle entità e delle relazioni. I tre elementi di navigazione RMDM utilizzabili a questo scopo sono gli indici condizionali, le ``visite guidate'' condizionali e le ``visite guidate indicizzate'' condizionali.
La fase di progettazione della navigazione inizia con il progetto della navigazione tra le entità, basata sulle relazioni associative. Successivamente vengono progettate le strutture di accesso ad alto livello unendo gli argomenti di interesse; solitamente, le strutture di accesso si collegano a un'entità utilizzando la sua porzione di testa, ma i progettisti del sistema possono specificare un punto d'ingresso differente, ad esempio marcando la struttura d'accesso col nome della porzione.
Alla fine di questa terza fase, il diagramma E-R+ è stato trasformato in un diagramma RMDM che descrive tutte le strutture d'accesso che devono essere implementate nel sistema.
Il Relationship Management Case Tool (RMCase, [DIMG95]) è un ambiente di sviluppo per la metodologia RMM. L'ambiente permette agli sviluppatori il passaggio da una fase all'altra per i necessari cicli di feedback utilizzando i vantaggi di un'interfaccia grafica e di un ambiente omogeneo.
Lo strumento si basa su diversi contesti di lavoro che seguono le varie fasi della metodologia (progettazione E-R, progettazione delle porzioni, progettazione della navigazione e fasi successive che vedremo) con particolare enfasi sulle fasi di progettazione dell'interfaccia utente e della coerenza anche visuale del sistema.
Le successive quattro fasi della RMM non riguardano direttamente la progettazione dei meccanismi d'accesso, e sono spesso realizzate con l'ausilio di strumenti ipermediali (come Toolbook, HyperCard o editori HTML) o direttamente con RMCase in uno di questi formati.
La quarta fase, progettazione del protocollo di conversione, usa un insieme di regole di conversione per trasformare ciascun elemento del diagramma RMDM in un oggetto della piattaforma su cui si vuole realizzare il sistema, per esempio una list-box di Toolbook o un elemento lista di HTML possono essere usati per realizzare un indice.
Nella quinta fase, la progettazione dell'interfaccia utente, si individuano le caratteristiche visive di ciascun oggetto presente nel diagramma RMDM così come creato nella fase 3, e quindi l'aspetto dei bottoni, dei nodi e degli aiuti alla navigazione. Le decisioni che riguardano invece i meccanismi di attraversamento dei collegamenti, di memoria della navigazione, eccetera, vengono prese e implementate nella sesta fase, progettazione del comportamento a tempo di esecuzione. In questa fase viene anche deciso quali nodi, una volta considerate la volatilità e le dimensioni del dominio delle informazioni, devono essere generati durante l'implementazione del sistema o piuttosto calcolate su richiesta a tempo di esecuzione [BMY95]. Per il suo naturale rapporto con basi di dati strutturati, la RMM incoraggia l'uso di documenti ricalcolati, ma supporta anche quelli ``statici''.
Questa due fasi sono particolarmente aiutate dall'utilizzo di RMCase, che consente una produzione più rapida e la coerenza visuale degli oggetti d'interfaccia all'interno del sistema: ad ogni nodo del progetto si può associare (e ``disegnare'' con gli strumenti grafici dell'ambiente) un template HTML che sarà poi utilizzato come base per la creazione delle pagine, che saranno generate nei vari modi visti al paragrafo precedente.
Per finire, la fase 7 della metodologia consiste nella implementazione e verifica, così determinata come nei tradizionali progetti di ingegneria del software. Nella costruzione di sistemi ipermediali un'attenzione particolare va però dedicata alla correttezza e alla verifica dei possibili percorsi di navigazione. Anche in questo caso è di aiuto RMCase con l'ambiente specializzato del contesto di prototipazione.
La classe delle applicazioni per le quali la RMM è maggiormente adatta comprende quelle modellate su domini fortemente strutturati, in cui cioè vi sono classi di oggetti, relazioni definibili tra queste classi e istanze multiple di oggetti di ciascuna classe. Molte applicazioni ipermediali soddisfano queste caratteristiche, ad esempio cataloghi di prodotti e interfacce ipermediali a database tradizionali o applicazioni consolidate.
Come peraltro indicato anche in [ISB95] la metodologia fornisce invece scarsi benefici nel caso di applicazioni debolmente strutturate, o addirittura non è per nulla applicabile. I sistemi informativi World-Wide Web di cui ci occupiamo in questa tesi rientrano invece nella categoria delle applicazioni con struttura irregolare e (in alcuni casi) ad alta volatilità per le quali la RMM non dà sostanziali vantaggi di progettazione, anche se è probabilmente possibile applicarla con successo a sotto-sezioni del sistema informativo dalla struttura più regolare.
