Objektiškai orientuotas hypermedios projekto modelis

ĮVADAS 3
ŽINGSNIŲ, PRODUKTŲ, MECHANIZMŲ IR PROCESO INTERESŲ APIBENDRINIMAS OOHDM MODELYJE 4
ABSTRAKCIJA, STRUKTŪRA IR IŠDĖSTOMAS APIBRĖŽIMŲ MECHANIZMAS OOHDM MODELYJE 5
OOHDM bendras supratimas 6
Konceptualus (abstraktus) projektas (Conceptual Design) 6
Navigacinis projektas (Navigational Design) 8
Mazgai (Nodes) 9
Sąsajos (Links) 9
Priėjimo struktūros (Access Structures) 10
Navigaciniai kontekstai (Navigational Contexts) 11
Konteksto klasės (Context Classes) 12
Navigaciniai transformatoriai (Navigational Transformations) 12
Abstrakčios sąsajos projektas (Abstract Interface Design) 14
Abstraktūs duomenų vaizdavimai (Abstract Data Views) 14
Konfigūracijos diagramos (Configuration Diagrams) 16
ADV – diagramos (ADV-charts) 17
Įgyvendinimas (Implementation) 17
BAIGIAMOSIOS PASTABOS 19
PRIEDAI 20Įvadas
Hypermedios taikymai yra suprantami kaip sistemos, kurios sudarytos funkcionuoti kaip žmogaus-mašinos dalies komandai. Dalis problemos bus išaiškinta mechanizmo taikymų bet kokiai technikai, kuri yra būdinga – Duomenų bazėms, Žinių bazių sistemoms, Hypermediai, ir kt. Dalis problemos, kuri yra išaiškinta žmogaus naudojančio hypermedios sistemą yra pagelbėti žmogui, vadovaujančiam žinių kaupimui. Hypermedios pavyzdys naudojamas taip pat integruoti formalias (naudojamas žmogaus) ir neformalias (naudojamas mechanizmo) žinių reprezentacijas. Svarbi problema yra kaip plėtoti hypermedios taikymą ir kaip integruoti šiuos sistemos taikymus. Hypermedios taikymai tipiškai įtraukia informacijos kompleksą ir gali leisti sudėtingą navigacijos funkcionavimą. OOHDM naudoja abstrakciją ir mechanizmų kompoziciją objektiškai orientuotoje sistemoje, vienu atveju leisti trumpą informacijos elementų komplekso aprašymą irr kitu atveju leisti navigacijos struktūros specifikaciją bei sąveikų pasikeitimus.
Objektiškai orientuoto hypermedios projekto modelyje, hypermedios sistema yra sukurta iš keturių žingsnių proceso, paremiančio proceso modelio didėjimą arba prototipą. Kiekvienas žingsnis sutelkia tam tikrą projekto susirūpinimą ir objektiškai orientuotas modelis yra su

ukurtas. Klasifikacija, agregacija ir generalizacija/specifikacija yra naudojamos visais atžvilgiais procese didinti abstrakcijos jėgą ir pakartotinai panaudoti galimybes.

Žingsnių, produktų, mechanizmų ir proceso interesų apibendrinimas OOHDM modelyje
Žemiau pateikta lentelė apibendrina žingsnius, produktus, mechanizmus ir proceso interesus OOHDM modelyje.
VEIKLOS PRODUKTAI FORMALIZMAI MECHANIZMAI PROCESO INTERESAS
Reikalavimai komplektavimui

Requirements Gathering

Use Case, Anotacijos Veiksmų planai, vartotojo interakcijos diagramos, projekto modeliai Veiksmų planai, Use Case analizė, apklausos, UID žemėlapio braižymas koncepciniam modeliui. Tarpininko reikalavimai prašymui.
Abstraktus projektas
Conceptual Design
Klasės, sub-sistemos, ryšiai, atributo perspektyvos. Objektiškai orientuotos modelio konstrukcijos, projekto modeliai. Klasifikacija, agregacija, generalizacija ir specializacija. Modelio semantika prašymų sferoje.
Navigacinis projektas
Navigational Design

Mazgai, sąsajos (linkai), priėjimo struktūros navigaciniai kontekstai, navigacinė transformacija. Objektiškai orientuotos apžvalgos, objektiškai orientuotos būsenų diagramos, konteksto klasės, projekto modeliai, vartotojo centro veiksmų planas. Klasifikacija, agregacija, generalizacija ir specializacija. Išaiškina vartotjo profilį. Pabrėžiamas kognityviuose aspektuose. Sudaroma navigacinė struktūra iš pranešimų.
Abstrakčios sąsajos projektas
Abstract Interface Design

Abstrakčios sąsajos obbjektai, atsakymai į išorinius įvykius, sąsajos transformacijos. Abstraktūs duomenų vaizdai, konfigūracijų diagramos, ADV-diagramos, projektų modeliai. Žemėlapio braižymas tarp navigacijos ir apčiuopiamų objektų. Modelio apčiuopiami objektai, priemonės parinktos metaforoms. Aprašomos sąsajos navigaciniems objektams.
Įgyvendinimas Implementation

Prašymo eiga, veikimas Tai palaiko objekto aplinka Tai aprūpina objekto aplinka Charakteristika, Visuma.

Abstrakcija, struktūra ir išdėstomas apibrėžimų mechanizmas OOHDM modelyje
Toliau bus pristatyta abstrakcija, struktūra, išdėstymas ir pristatymas mechanizmų, naudojamų objektiškai orientuoto hypermedijos projekto modelyje (OOHDM). Bus aprašyta pagrindinės veiklos OOHDM, būtent abstraktus (konceptualus) projektas, navigacinis projektas, abstrakčios sąsajos projektas ir įgyvendinimas, pristatantis modeliavimo konstrukcijas, naudojamas au

ukšto lygio sudarymui, abstrakčiai navigacijai ir sąsajos struktūroms.
Čia yra susidomėjimo augimas hypermedios projekto metodais. Tai yra motyvuota problemų rūšių aiškiu supratimu, mes turime išaiškinti tam kad sudaryti praktiškus ir išvystytus hypermedios pranešimus. Programinės įrangos srities esmė, kurioje navigacija yra kombinuoj.ama su sunkumais elgesyje su multimedios duomenimis, reikalauja naujų priartėjimų.
Darbe bus pristatyta OOHDM metodologija. Konkrečiai bus akcentuojama kuriame modeliavime konstruktai bus naudojami, sudarant modulinį, plėtojant navigacines ir sąsajos struktūras; bus pavaizduota visų reikšmingų projektų priartėjimas, projektų versle.
Pirmiausia bus aprašyta pagrindinė metodologija, pristatanti kiekvieno projekto veiklos kelis elementus ir galiausiai bus palyginta priartėjimai su panašiais šios sferos darbais.OOHDM bendras supratimas
Objektiškai orientuotas hypermedios proceso metodas yra modelis-paremtas priartėjimu  (a model-based approach ); hypermedios pranešimų sudarymui. Tai susideda iš keturių skirtingų veiklų būtent koncepcinio projekto, navigacinio projekto, abstrakčios sąsajos projekto ir įgyvendinimo. Jos yra atliekamos didėjimo mišinyje, kartotinis ir prototipas paremti plėtojimo stiliumi. Per kiekvieną veiklą objektiškai orientuotų modelių grupė aprašo konkretaus projekto interesą, kuris yra sudarytas ar gerinamas iš ankstesnių iteracijų.Konceptualus (abstraktus) projektas (Conceptual Design)
Per konceptualų projektą pranešimų srities modelis sudaromas naudojant gerai žinomus objektiškai orientuotus modeliavimo principus, kurie papildo keliais primityvais, tokiais kaip atributo perspektyvos ir sub-sistemos. Koncepcinės klasės gali būti sudaromos naudojant agregacijos ir generalizacijos/specializacijos hierarchijas. Pagrindinis interesas šiame žingsnyje yra už
žfiksuoti pagrindines semantikas taip neutraliai kaip įmanoma, su labai mažu interesu vartotojų ir užduočių tipams. Šio žingsnio rezultatas yra klasė ir pavyzdinė schema sudaryta iš Sub-sistemų, klasių ir ryšių. Pavyzdinė schema apibūdina išimtinius objektus ir tai yra numatymas panaikinti klasės eksploziją kai tai būtina.
Paveikslas 1 parodo konceptualios schemos pavyzdį, Portinari projekto pranešimui.

Paveisklas1. Portinari projekto taikymo konceptuali schema.Navigacinis projektas (Navigational Design)
OOHDM modelyje, taikymas yra matomas kaip navigacinis vaizdas virš konceptualaus pagrindo. (Žr. Paveikslas 2). Tai atspindi taikymo esmę, tą vieną iš rakto ypatingų bruožų iš hypermedios taikymų, kurie yra navigacijos sąvoka. Tai yra šiame žingsnyje, kad projektuotojas išaiškina būsimą vartotoją ir dalis užduočių yra įvykdomos naudojant taikymus.

Paveikslas 2. Ryšys tarp koncepcinės ir navigacinės schemų.
Skirtingi navigaciniai modeliai gali būti sudaryti iš tų pačių konceptualių schemų, taigi išreiškiant skirtingus vaizdus toje pačioje srityje. Hypermedios taikymų navigacinė struktūra yra apibrėžiama schemos, specifikuojančios navigacines klases, kurios atspindi pasirinktą vaizdą virš taikymų srities. OOHD Modelyje yra navigacinių klasių iš anksto apibrėžti grupių tipai; mazgai, sąsajos, priėjimo struktūros, kurios yra organizuotos navigaciniame kontekste. Mazgų ir sąsajų semantika yra paprasta hypermedios pranešimuose, kol priėjimo struktūros gali reprezentuoti priėjimo mazgų tokių kaip indeksai, valdomi turai ir kt. alternatyvius kelius.
Paveikslas 4 yra navigacinių klasių pavyzdžiai Portinari projekto pranešimams.

Paveikslas 4. Keletas navigacinių klasių Po

ortinari projekto taikyme.Mazgai (Nodes)
Mazgai yra pagrindinė talpyklų informacija hypermedios pranešimuose. Jie yra apibrėžiami kaip konceptualių klasių objektiškai orientuoti vaizdai, apibrėžiant per konceptualų projektą, naudojant kalbos užklausą, leidžiant, kad mazgas būtų apibrėžtas kombinuojant skirtingai susijusių klasių atributus konceptualioje schemoje.Sąsajos (Links)
Sąsajos atspindi ryšius numatomus nagrinėti galutinio vartotojo. Kaip ankščiau minėta, skirtingi vaizdai gali būti charakterizuojami toms pačioms konceptualioms schemoms susidoroti su skirtingų vartotojų bendrumais ar užduotimis.
Modelyje, sąsajos realizuoja ryšius apibrėžtus konceptualioje schemoje. Kitaip sakant, sąsajos yra ryšių navigacinė realizacija. Sąsajų klasės yra apibrėžiamos tiksliai apibrėžiant sąsajų atributus ir funkcionavimą, priežastį ir tplaninius objektus. Sąsajų atributai išreiškia pačios sąsajos savybes ir gali būti naudingi apibrėžiant n – ary sąsajas ar sąsajas su kardinaliai didesniu negu viena. Tokiu atveju sąsaja gali elgtis kaip mazgas (panašus į web centrą HDM’e), veikti kaip tarpinis objektas (tarp sąsajos šaltinio ir tikslo) navigacijos metu. Priėjimo struktūros (Access Structures)
Priėjimo struktūros veikia kaip indeksai ar žinynai ir yra naudingos padėti galutiniam vartotojui surasti norimą informaciją. Meniu, indeksai ir valdomi turai yra priėjimo struktūrų pavyzdžiai. Portinari projekte pranešimus reikia įvykdyti skirtingomis priėjimo struktūromis, tokiomis kaip: objekto indeksas, pagrindinis indeksas.
Paveiksle 5 pateikiamas indeksų pavyzdys.

Paveikslas 5.   Indekso struktūra
Priėjimo struktūros yra taip pat modeliuojamos kaip klasės ir selektorių grupės, užduočių objektų grupės, planinių objektų papildomai charakterizuojamos. Predikatas išreiškia kurie objektai bus prieinami jų savybių terminuose. Selektoriai pastoviai būna planinių objektų keliems atributams ir yra organizuoti pagal išanksto apibrėžtas duomenų struktūras. Bet kuriuo atveju jie turi būti aiškiai paminėti didėjimo struktūros apibrėžime.Navigaciniai kontekstai (Navigational Contexts)
Gerai suprojektuotuose hypermedios pranešimuose autorius turi paaiškinti kelią, kuriame vartotojas tyrinėja hypermedią tam, kad išvengtų nereikalingos informacijos ir sukliudytų vartotojui pasimesti hyper erdvėje.
OOHDM’e pagrindinis navigacinės schemos struktūravimas yra navigacinio konteksto sąvoka. Navigacinis kontekstas yra mazgų, sąsajų, kontekstinių klasių ir kitų (sąvokų) navigacinių kontekstų dalis. Jie įtraukia iš navigacinių klasių tokius kaip, mazgai sąsajos, indeksai ir valdomi turai. Jie gali būti apibrėžiami apgalvotai arba išplėstai, t.y. pagal bet kurios savybės apibrėžimą, kad visi mazgai ir sąsajos laikosi kontekste arba pagal jų dalyvių išvardijimą.
Pavyzdžiui: sąsaja 1 su n įtraukia navigacinį kontekstą, kas leidžia nuosekliai išaiškinti visus sąsajų adresatus. Tuo pačiu metu indeksas ar valdomas turas apibrėžia navigacinius kontekstus. Navigacinis kontekstas Portinari projekte: “Temų iliustracijos” (“Artwork by Theme”) leidžia išanalizuoti nuosekliame kelyje visas iliustracijas pateiktose temose. (Žr. Paveikslas 6)

Paveikslas 6. Situacijos (konteksto) schema Portinari Projekto taikyme.Konteksto klasės (Context Classes)
Konteksto klasės papildo navigacinės klasės apibrėžimą, pvz., mazgas, pažymi kuri informacija yra parodyta ir kuris pagrindas yra tinkamas, kai gaunami objektai tam tikrame kontekste.

Paveikslas 7. Konteksto klasė Portinari projekto taikyme.Navigaciniai transformatoriai (Navigational Transformations)
Navigacinė schema gali vykdyti navigacijos diagramos rolę arba kai navigaciniai transformatoriai yra nežymūs, t.y. kai paliekant mazgą tai yra uždaroma arba kai navigaciniai transformatoriai yra pilnai kontroliuojami vartotojo. WWW žiūrovai mėgsta Netscape, kuriame vartotojas gali atidaryti naują langą sąsajai (linkui) ir navigacijai iš to lango (mazgo), kuris yra nepriklausomas nuo ankstesnės navigacijos istorijos.
Navigacijos diagramos pagerina navigacinę schemą su ženklų sistema apibrėžiant mazgo grupes ir specifikuojant sąsajos išaiškinimo rezultatą dabartinėje navigacijos padėtyje (atidaryti mazgai). Ženklų sistema skolinasi XOR ir AND lizdą (rinkinį) iš būsenų diagramų, tačiau panaikinant būsenas ir pereigos paplitimą apibrėžiant “macros” tai gali būti išversta į paprastą būsenų diagramą, taigi palaikymas tai yra naudojamasis kompiuterio galia.
Paveiksle 8 parodyta navigacijos diagrama iliustracijoms, asmenims ir informacijai, tokiai kaip naviguoti iš asmenų į iliustracijas ar iš asmenų į informaciją, abu šaltiniai ir adresato mazgai išlieka atidaryti. Tačiau paliekant iliustracijas atvejams, atidaryti mazgai yra uždaromi.

Paveikslas 8. Navigacinės diagramos pavyzdysAbstrakčios sąsajos projektas (Abstract Interface Design)
Vieną kartą navigacinė struktūra jau buvo apibrėžta, tai turi būti padaryta pastebint vartotoją per pranešimų sąsają, kuri yra padaryta šiame žingsnyje apibrėžiant abstraktų sąsajos modelį. Tai reiškia kurie sąsajos objektai bus pastebėti vartotojo ir tam tikrame kelyje, kuriame skirtingi navigaciniai objektai bus panašūs, kurie sąsajos objektai aktyvuos navigaciją, kelias, kuriame multimedios sąsajos objektai bus sinchronizuoti (sutaps) ir kurie sąsajos transformatoriai užims vietą. Nevartota separacija tarp abiejų interesų, navigacinis ir abstraktus sąsajos projektas, leidžia sudaryti skirtingas sąsajas tam pačiam navigaciniam modeliui, nurodant nepriklausomybės aukštesnį laipsnį iš vartotojo-sąsajos technologijos ir taip pat leidžiant prisitaikymą su įvairius vartotojo poreikius ar pirmenybes. OOHDM’e naudojamas abstraktūs duomenų vaizdavimai projekto priartėjimas aprašant hypermedios pranešimo vartotojo sąsają.Abstraktūs duomenų vaizdavimai (Abstract Data Views)
Abstraktūs duomenų vaizdavimai yra formalūs sąsajos objektų modeliai ir jie yra specifikuojami, parodant:
A – Kelią, kuriame jie yra struktūrizuojami. Suvokiamos savybės yra taip pat specifikuojamos kaip ADV atributai ar dalys.
B – kelią, kuriame jie yra statiškai susieti su navigacijos objektais. Mes naudojame konfigūracijos diagramas kaip schematiškus įrankius, išreiškiant šiuos ryšius.
C – Kaip jie funkcionuoja kai reaguoja į išorinius įvykius, ypač kai jie sukelia navigaciją ir kuri sieja transformatorius, įvyksta kai vartotojas sąveikauja su taikymu.
ADV sąvokos

ADV yra objektai, jie turi būseną ir sąsają, kur sąsaja gali būti vykdoma per reguliarius funkcinius ar procedūrinius signalus ar įvedimo ir išvedimo įvykius. ADV yra abstraktus, kad jie tiktai representuoja sąsają ir būseną. Tipiniame veikime, naudojant ADV, yra dalis ADO (abstraktūs duomenų objektai), vadovaujančių duomenų struktūroms, jie kontroliuoja veikimą viduje ir dalis sąsajos objektų valdo veikimo sąsajos aspektus, tokius kaip vartotojo įvedimas ir sistemų išvedimas vartotojui. OOHDM kontekste, navigaciniai objektai, tokie kaip mazgai, sąsajos, informacijos išrinkimo struktūros vaidina kaip ADO (abstraktūs duomenų objektai) ir jų jungtinis ADV yra naudojamas specifikuojant jų išorę vartotojui.

Paveikslas 9. ADV kaip vartotojo sąsajos.
ADV kai naudojamas hypermedios taikymo projekte gali būti vaizduojamas kaip sąsajos objektas, sudaroma atributų dalis, kuri apibrėžia jų suvokiamas savybes ir įvykių dalis gali elgtis kaip vartotojas- generuojantis įvykius. Atributų reikšmės gali būti apibrėžiamos kaip konstantos, tačiau apibrėžiant išorės tam tikrą stilių tokį kaip spalva, garsas, pozicija. Užsakytas kintamasis, “suvokiamas kontekstas” (“perceptionContext”) yra naudojamas parodyti modifikacijas tam tikrai erdvei. Kai mes norime padaryti keletą objektų suprantamais mes įvedame jį į “suvokiamą kontekstą” ir elementai pašalinti iš “suvokiamo konteksto” daugiau neegzistuoja.
Apibrėžiant hypermedios taikymo abstraktų sąsajos modelį ADV terminuose, reiškia:Konfigūracijos diagramos (Configuration Diagrams)
Konfigūracijos diagramos yra naudingos išreiškiant ryšio modelius tarp objektų terminuose. ADV projekte jie yra naudojami reprezentuoti išorinius įvykius, kuriuos valdo ADV ; paslaugas aprūpina ADV ir komunikacija tarp ADV ir ADO. Konfigūracijos diagrama gali taip pat parodyti sudėtinės ADV struktūros įterpimą. Kiekviena mazgo klasė bus apibrėš viešą sąsają su paslaugom, kurias aprūpina jų objektai. Ypač visi mazgai reaguos į žinutę: anchorSelected (A) užklausiant pagrindo (anchor) A priimti navigaciją aplink susijusias sąsajas. Sudėtiniame ADV su skirtingais sąsajų objektais, tokiais kaip mygtukai susiję su mazgo pagrindu, mes anotuojame pagrindo vardą konfigūracijos diagramoje. (Žr. Paveikslas 10)

Paveikslas 10. Konfigūracijos Diagrama Portinari Projekte.
10 Paveiksle ADV asmuo (person) gali reaguoti į išorinius įvykius: MouseClicked (Pelės paspaudimas) ir Display (displėjus) ir komunikuoti su jo savininkais siunčiant žinutes: anchorSelected, getName and getPicture.ADV – diagramos (ADV-charts)
Paveikslas11. Supaprastinta ADV-diagrama asmeniui.
Navigacija ir abstraktaus sąsajos projektas yra gana panašūs, išgaunama vientisa pereiga tarp abiejų veiklų leidžiant navigacijos ir abstrakčių sąsajos modelių didėjančias konstrukcijas. Tuo pačiu metu, išsiskiriančio projekto nutarimas yra įrašytas, naudojant notaciją, kuri yra veiksminga ir glausta. Navigacija ir ADV-diagramos gali lengvai sieti ir derinti informaciją sąsajoje ir navigacijos klasių rezultatuose, aiškiai surandamame modelyje.Įgyvendinimas (Implementation)
Pasiekti einamąjį igyvendinimą, projektuotojas turi pažymėti navigacinius ir abstrakčius sąsajos modelius į konkrečius objektus, esamus pasirinktoje įgyvendinimo terpėje (aplinkoje). Modelis, sugeneruotas po 1-3 žingsnių įvykdymo, gali įgyvendinti tiesiame (paprastame) kelyje, naudojant daugelį šiuo metu prieinamų hypermedios platformų, tokių kaip, Hyper kortelė, MacWeb, KMS, Guide, Microcosm ir kt.

Naudojimas pastovių modeliavimo konstrukcijų (objektai ir klasės) grupės, metodologijoje leidžia vienodą pereigą iš srities modeliavimo į navigaciją ir sąsajos projektą. Įgyvendinimo žingsnis nereikalauja, kad objektiškai orientuota terpė bus naudojama, nors tai gali padaryti darbą lengvesniu. Galiausiai kad vyksmo terpė nėra objektiškai orientuota, dauguma metodų gali būti naudojami pažymėti objektiškai orientuotą specifikaciją į ne objektiškai orientuotas vyksmo terpes.Baigiamosios pastabos
Šis darbas turi savo esmę modelio bazuojančio priartėjimą prie hypermedios projekto kaip HDM. Tai yra gana panašu į EORM, tuo tarpu tai naudoja objektus ir ryšius kaip modeliavimo konstrukcijas; tačiau OOHDM skiriasi nuo EORM tuo tarpu tai aiškiai skiriasi koncepcija nuo navigacijos ir abstraktaus sąsajos projekto. Tai yra taip pat skirtinga tuo jis yra taip pat siekiamas specifikuojant programinės įrangos sistemų platų spektrą, tokį kaip CASE terpė ir sprendimo palaikymo sistemos, atsižvelgiant į objektus ne vienintelius kaip struktūrinius, sutrumpinančius įrašus, bet taip pat kaip dinamines esybes.
Navigacija ir ADV-diagramos pratęsia būsenų diagramas, įvedant notacijos specifiką į hypermedios taikymus. Be to, jie yra sukurti objektiškai orientuotų modelių dalies kontekste ir jie yra skirti modeliuoti tik dinaminius aspektus iš navigacijų ir sąsajų.
Hypermedios taikymai yra sunkūs ir kiekvienas naujas taikymas yra pastoviai sudaromas iš ženklų.
Šiuo metu studijuojama pakartotinio navigacijos naudojimo problema ir sąsajos sandaros ir stiliai. Analizuojamas hypermedios taikymas žiūrint į pasikartojantį projekto modelį ir bandoma padaryti tai projekto žinias prieinamas taikymo kūrėjams, naudojant notaciją.Priedai
Abstract
In this position paper we present the abstraction, composition, lay-out and presentation mechanisms used in the Object-Oriented Hypermedia Design Model (OOHDM). We describe the main activities in OOHDM, namely conceptual design, navigation design, abstract interface design and implementation, presenting the modeling constructs we use to build high-level, abstract navigational and interface structures. We compare our approach with other existing work in designing hypermedia applications and finally we discuss some further work in this field.

Table of Contents
• Introduction
• Overview of OOHDM
o Conceptual Design-Domain Analysis
o Navigational Design
o Abstract Interface Design
o Implementation
• Related Work and Concluding Remarks
• References

Introduction
There is a growing interest in hypermedia design methods [Balasubramaniam94, Garzotto93, Lange94]. This is motivated by a clear understanding of the kind of problems we must solve in order to build usable and evolvable hypermedia applications. The very nature of this software field, in which navigation is combined with the inherent difficulties of dealing with multimedia data, needs new approaches. (See for example the electronic version of ACM’s special issue on designing hypermedia applications).
In this position paper we present the Object-Oriented Hypermedia Design Methodology [Schwabe94]. In particular we focus on which modeling constructs we use to build modular, evolvable navigational and interface structures; we show our approach for recording all meaningful design decisions in the design enterprise. The structure of this paper is as follows. We first describe the whole methodology presenting some details of each design activity and finally we compare our approach with similar work in this area. We will base our presentation using a brief example taken from the implementation of the hypermedia presentation of Portinari Project [Lanzelotte93].
Table of Contents

Overview of OOHDM
The Object-Oriented Hypermedia Design Method is a model-based approach  for building hypermedia applications. It comprises four different activities namely conceptual design, navigational design, abstract interface design and implementation. They are performed in a mix of incremental, iterative and prototype-based development style. During each activity a set of object-oriented models describing particular design concerns are built or enriched from previous iterations. In Figure 1 we summarize OOHDM activities, modeling approaches, abstraction and presentation mechanisms.
Figure 1. A summary of the OOHDM methodology.
Conceptual Design
During Conceptual Design a model of the application domain is built using well known object-oriented modeling principles [Rumbaugh91], augmented with some primitives such as attribute perspectives and sub-systems. Conceptual classes may be built using aggregation and generalization/specialization hierarchies. The main concern during this step is to capture the domain semantics as ³neutrally² as possible, with very little concern for the types of users and tasks. The product of this step is a class and instance schema built out of Sub-Systems, Classes and Relationships. The instance schema describes exceptional objects and it is intended to avoid class explosion when possible. Figure 2 shows an example of a conceptual schema for the Portinari Project application.

Figure 2. Conceptual schema of the Portinari Project application.
Navigational Design
• Introduction
• Nodes
• Links
• Access Structures
• Navigational Contexts
• Navigational Transformations
Introduction
In OOHDM, an application is seen as a navigational view over the conceptual domain (See Figure 3). This reflects the point of view that one of the key distinguishing features of hypermedia applications is the notion of navigation. It is in this step that the designer takes into account the types of intended users, and the set of tas.ks they are to perform using the application.

Figure 3. Relation between conceptual and navigational schemas.
Different navigational models may be built for the same conceptual schema thus expressing different views (respectively applications) on the same domain. The navigational structure of a hypermedia application is defined by a schema specifying navigational classes that reflect the chosen view over the application domain. In OOHDM there is a set of pre-defined types of navigational classes: nodes, links, access structures, which are organized into Navigational Contexts. The semantics of nodes and links are the usual in hypermedia applications while access structures may represent alternative ways of accessing nodes such as indexes, guided tours, etc.
Figure 4 contains the examples of navigational classes for the Portinari Project application.

Figure 4. Some navigational classes in the Portinari Project application.
Nodes
Nodes are the basic information containers in hypermedia applications. They are defined as object-oriented views of conceptual classes defined during Conceptual Design using a query language similar to the one in [Kim94], allowing a node to be defined by combining attributes of different related classes in the conceptual schema. They contain single typed attributes and link anchors and may be atomic or composites as in [Gronbaek94]
Figure 5 shows an example of a node representing an “Artwork” in the Portinari Project application
Figure 5. A node representing an “Artwork” in the Portinari Project application.
(to access the actual site, click here “Boy with top” and then click on the “back” button of your browser to return to the article).
Links

Links reflect relationships intended to be explored by the final user. As previously said, different views may be defined for the same conceptual schema to cope with different user communities or tasks.
In our model, links implement relationships defined in the conceptual schema. In other words, links are the navigational realization of relationships. Link classes are defined by specifying link attributes and behavior, source and target objects and cardinality. Link attributes express properties of the link itself and may be useful when defining n-ary links or links with cardinality greater than one. In such cases the link may behave as a node (similar to the web¹s centre in HDM), acting as an intermediate object (between the link source and destination) during navigation.
Access Structures
Access structures act as indexes or dictionaries and are useful for helping the final user find the desired information. Menus, Indices and guided tours are examples of access structures. In Portinari Project application we have implemented different access structures such as: Subject Index, Main Index. Figure 6 shows an example of an index
Figure 6. An index structure.

(to access the actual site, click here Index of themes and then click on the “back” button of your browser to return to the article).
Access structures are also modelled as classes and further characterized by a set of selectors, a set of target objects (usually objects in the schema) and a predicate on target objects. The predicate expresses which objects will be accessible in terms of their properties. Selectors usually stand for some of the attributes of the target objects and are organised according to a pre-defined data structure (an ordered list, a set of icons, etc.). In either case they must be explicitly mentioned in the definition of the access structure.
Navigational Contexts
In well-designed hypermedia applications the author must take into account the way in which the user is exploring the hypermedia in order to avoid redundant information and to prevent the user to get lost in the hyperspace. For example, if we are exploring a hypermedia with painters and paintings and we access all paintings of Van Gogh it is not wise to include in a painting, information ab.out him, while if we are exploring all painting about flowers and we reach Sun Flowers we will want to include some references to its creator (in fact Van Gogh). In the same way we may want to make evident that the “next” painting from Sun Flowers is another painting from Van Gogh in the first case, and another painting with flowers in the second.
In OOHDM the main structuring primitive of a navigational schema is the notion of navigational context. A navigational context is a set of nodes, links, context classes and other (nested) navigational contexts. They are induced (in different ways depending on the type of class) from navigation classes such as Nodes, Links, Indices, and Guided Tours. They may be defined intentionally or extension ally, i.e. by either defining a property that all nodes and links in the context hold or by enumerating its members. For example a 1-to-n link induces a navigational context that allows traversing sequentially all the link targets. In the same way an index (all painting about a subject) or a Guided Tour (some selected paintings) define navigational contexts. In Portinari Project the Navigational Context: “Artwork by Theme” allows traversing in a sequential way all artworks in a given theme (perhaps selected in an index) (see Figure 7).

Figure 7. Context schema in the Portinari Project application.

Context Classes
Context classes complement the definition of a navigational class, e.g. a node, indicating which information is shown and which anchors are available when accessing the object in a particular context. Navigational Contexts play a similar role as collections [Garzotto94] and have been inspired in the concept of nested-contexts [Casanova93].

Figure 8. Context class in the Portinari Project application.
Navigational Transformations
The navigational schema may play the role of a navigation chart either when navigational transformations are trivial, i.e. when leaving a node it is closed, or when navigational transformations are fully-controlled by the user. This is the case in WWW viewers like Netscape in which the user may open a new window for a link and navigation from that window (node) is independent of the previous navigation history.
Navigation charts enrich the navigational schema with a notation for defining node clusters (sets of nodes that may be opened at the same time) and for specifying the effect of traversing a link on the current navigation state (opened nodes). This notation borrows XOR and AND nesting from statecharts but avoiding state and transition proliferation by defining “macros” that may be translated to plain statechart notation thus maintining its computing power. In Figure 9 we show the Navigation Chart for Artworks, Persons and References such that when navigating from Persons to Artworks or from Persons to References both source and target nodes remain opened. However when leaving Artworks to events, opened nodes are closed.

Figure 9. An example of a Navigation Chart.
Table of Contents

Abstract Interface Design
• Introduction
• Abstract Data Views
• Configuration Diagrams
• ADV-charts
Introduction
Once the navigational structure has been defined, it must be made perceptible to the user through the application’s interface, which is done in this step by defining an abstract interface model. This means defining which interface objects the user will perceive, and in particular the way in which different navigational objects will look like, which interface objects will activate navigation, the way in which multimedia interface objects will be synchronized and which interface transformations will take place. A clean separation between both concerns, navigational and abstract interface design, allows building different interfaces for the same navigational model, leading to a higher degree of independence from user-interface technology, and also allowing conformance with varying user needs or preferences. In OOHDM we use th.e Abstract Data View design approach for describing the user interface of a hypermedia application [Cowan95].
Abstract Data Views
Abstract Data Views are formal models of interface objects and they are specified by showing:
a – The way in which they are structured. Perception properties are also specified as attributes or parts of an ADV.
b – The way in which they are statically related with navigation objects. We use Configuration Diagrams [Coleman92] as a diagrammatic tool for expressing these relationships.
c – How they behave when reacting to external events; in particular how they trigger navigation and which interface transformations occur when the user interacts with the application.
ADVs Concepts

ADVs are objects in that they have a state and an interface, where the interface can be exercised through regular functional or procedural calls or input and output events. ADVs are abstract in that they only represent the interface and the state, and not the implementation. In a typical application using ADVs, we have a set of ADOs (abstract data objects) managing data structures and control within the application and a set of interface objects (instances of ADVs) managing interface aspects of the application such as user input and system output to the user. In the context of OOHDM, navigational objects such as nodes, links or access structures act as ADOs, and their associated ADV are used for specifying their appearance to the user.

Figure 10. ADVs as user interfaces.
An ADV when used in the design of hypermedia applications can be viewed as an interface object comprising a set of attributes which define its perception properties, and the set of events it can handle such as user-generated events. Attribute values may be defined as constants thus defining a particular style of appearance such as position, colour, or sound. A reserved variable, “perceptionContext”, is used to indicate modifications to the perception space. When we want to make some object perceivable we add it to perceptionContext, and elements removed from perceptionContext are no longer perceivable.
Defining the abstract interface model of a hypermedia application in terms of ADVs implies:
• defining ADVs for each navigational object. In fact, defining at least one ADV type for each navigational class;
• specifying the configuration diagram showing static relationships among ADVs and ADOs (which are navigational objects);
• specifying the ADVchart for each ADV showing the dynamics of the hypermedia application.
Configuration Diagrams
Configuration diagrams [Coleman92] are useful for expressing patterns of communication between objects in terms of provided and required services. In the ADV design approach they are used to represent external (user-initiated) events that an ADV handles; the services provided by the ADV (such as display) and the communication among ADVs and ADOs. A configuration diagram may also show the nesting structure of composite ADVs. In our context, we are interested in defining the way in which the user will interact with the hypermedia application and in particular which interface objects will cause navigation. Each Node Class will define a public interface with the services provided by its objects. In particular all nodes will react to the message: anchorSelected (A) by asking anchor A to initiate navigation across its associated link. In a composite ADV with different interface objects such as buttons associated with node anchors, we annotate the name of the anchor in the configuration diagram. (See Figure 11).

Figure 11. A Configuration Diagram in Portinari Project.

In Figure 11, ADV Person can react to external events: MouseClicked and Display, and communicates with its owner (an ADO that is a node Person) by sending it the messages anchorSelected, getName and getPicture. In this example node Person has many anchors defined (as seen in Figure 4).
ADV-charts
We use ADV-charts [Carneiro94.] another derivative of Statecharts, that adds both structural and behavioural nesting and a Petri-Net like notation for expressing synchronisation issues usual when dealing with multimedia data.

 
Figure 12. Simplified ADV-chart for Person.
Since the modelling constructs we use during Navigational and Abstract Interface Design are quite similar, we obtain a seamless transition between both activities allowing incremental construction of the navigational and abstract interface models. At the same time, outstanding design decisions are recorded using a notation that is powerful and concise. Navigation and ADV-charts may be easily related and combining information in interface and navigation classes results in a strong traceability model. The reader may find a complete description of our approach in [Rossi95]
Implementation
To obtain a running implementation, the designer has to map the navigational and abstract interface models into concrete objects available in the chosen implementation environment. The model generated after performing steps 1-3 can be implemented in a straightforward way using many of the currently available hypermedia platforms such as Hypercard, Toolbook, MacWeb, KMS, Guide, Microcosm, etc.. The use of a uniform set of modelling constructs (objects and classes) in our methodology allows a smooth transition from domain modelling to navigational and interface design.
The implementation step does not require that an object-oriented environment be used, although it might make the job easier. In the event that the runtime environment is not object-oriented, many techniques can be used to map an object-oriented specification into a non object-oriented runtime environment.

Table of Contents

Related Work and Concluding Remarks
Our work has its roots in model-based approaches to hypermedia design like HDM [Garzotto93]. It is quite similar to EORM [Lange94] in that it uses objects and relationships as modelling constructs; however OOHDM differs from EORM in that it clearly separates conceptual from navigational design and that it uses rich modelling constructs both in the navigational and abstract interface design activities. It is also different in that it is also aimed at specifying a broad spectrum of software systems such as CASE environments and decision support systems by considering objects not only as structured, encapsulated records but also as dynamic entities.
Many authors have used state-machine based formalisms to model hypertext structures (see for example [Zheng92]). Navigation and ADV-charts extend Statecharts by adding notations specific to hypermedia applications. Besides they are created in the context of a set of object-oriented models and they are intended to model only the dynamic aspects of both navigation and interface.
Engineering hypermedia applications is difficult and each new application is usually built from scratch. We are now studying the problem of reusing navigation and interface architectures and styles. We are analyzing hypermedia applications looking for recurrent design patterns (in the sense of [Gamma94]. http://st-www.cs.uiuc.edu/users/patterns/patterns.html) and trying to make this design knowledge available to application builders by using our notation. < design patterns in hypermedia> We find his approach very appealing as a way to solve common problems in the hypermedia domain.

Leave a Comment