Dokumenttiluokkien suunnittelusta 12 Dokumenttiluokkien suunnittelusta XML-sovellusten suunnittelun keskeinen ja toistuva osaalue on dokumenttiluokkien (tai XML-tekstiformaattien) suunnittelu. Työn kärjistetty (ja nyt tarkoituksella rajattu) lopputulos on XML DTD tai XML-skeema. Dokumenttityypin abstrakti tehtävä on määrittää rajapinta jonka sovellus sitten tavalla tai toisella toteuttaa. Tyyppimäärityskiel(t)en yksinkertaisuudesta huolimatta hyvän dokumenttiluokan suunnittelu on ei-triviaali tehtävä, aihepiirin kytköksistä johtuen (osaprj). Hyvä tyyppimääritys mallintaa sovelluksen keskeisen tiedon järkevästi jäsennettynä, toimii sekä teknisen kirjoittamisen että sovellusohjelmoinnin näkökulmasta (std-ratkaisut ja välineet huomioiden), ja tarjoaa puitteet tuleville laajennuksille. Suunnittelutehtävä helpottuu esim. visuaalisten apuvälineiden käytöllä. MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 223
Dokumenttiluokkien suunnittelusta 12.1 Suunnittelutehtävän reunaehdoista Rakdok-suunnittelu käynnistyy yleensä selvitystyöllä joka pyrkii jäsentämään tehtävän osana olemassa olevaa sovellusperhettä Hyvin yleisellä tasolla, dokumenttityypin tietomallin määrittelyn pitää asettaa ainakin - tavoite ja käyttötapa - tarkkuus (granulariteetti) - sovellusala Onnistumisen avain = hyvä sovellusalueen ja välineiden tuntemus MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 224
Dokumenttiluokkien suunnittelusta 12.2 Systemaattisuudesta ja menetelmistä (1/2) Mikäli suunnittelukäytäntö on epäselvä, seurauksena on ikäviä ongelmia: - tekijätiimin huonomuistisuus aiheuttaa virheitä ja tehottomuutta (samaa jauhetaan kerrasta toiseen ja ratkaisut keksitään aina uudelleen) - tavoitteet ja tulokset ovat epäselviä ja muuttuvat huomaamatta matkalla - oikeita kysymyksiä ei huomata kysyä oikeina aikoina tai unohdetaan kokonaisia työvaiheita (tyypillisesti dokumentointi, raportointi ja korjaukset) - suunnitteluprosessin seuraaminen on hankalaa ja tehtyjen päätösten vaikutusten arvioiminen jälkikäteen (ja esim. työstä oppiminen!) vaikeaa MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 225
Dokumenttiluokkien suunnittelusta 12.3 Systemaattisuudesta ja menetelmistä (2/2) Systemaattisen suunnittelun idea on soveltaa kuvaustekniikoita ja hyviä käytäntöjä kirjaavia toimintatapoja: - yhtenäinen kieli ja käsitejärjestelmä jonka avulla esittää suunnitelmia ja keskustella niistä - selkeä malli suunnitteluprosessin toteuttamiseksi ja kirjaamiseksi - muistilistoja joiden seuraaminen varmistaa pahimpien sudenkuoppien välttämisen työn eri vaiheissa - esimerkkejä joista ottaa mallia työn suorittamiseksi käytännössä Menetelmien jaottelusta: vapaamuotoiset (informaalit) menetelmät (esim. seinätaulut), puoliformaalit menetelmät (esim. UML+RUP), formaalit menetelmät (tiedon ja käyttötapausten looginen kuvailu) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 226
Dokumenttiluokkien suunnittelusta 12.4 Systemaattisen työn vaiheet Kaikentyyppinen projektityö hyötyy seuraavien hyväksi havaittujen työvaiheiden mukaisesta jäsennyksestä (kärjistys) a) esitutkimus (mitä tehdään/onnistuuko edes/mitä pitää tietää) b) määrittely (mitä ajetaan takaa/keskeiset tavoitteet/reunaehdot) c) suunnittelu (miten tavoitteeseen päästään) d) toteutus (tyyppimäärityksen kirjoittaminen ja dokumentointi) e) testaus (toimiiko todella kuten ajateltiin/otetaanko käyttöön) f) korjaus (jos ja kun ei mennyt kuin elokuvissa) Iteratiivinen kehitys jäsentää vaiheet yhden iterat. kehitysaskeleen sisäisiksi välivaiheiksi, pienissä projekteissa osa-alueet sulautuvat Conceptualisation Problem Problem-solving Solution Inception Elaboration Construction Transition Development Cycle Realisation Product Generation MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 227
Dokumenttiluokkien suunnittelusta 12.5 Riskeistä Työn tyypillisimpiä riskejä ovat (kohde)sovelluksen heikko tuntemus ja epärealistisuus tavoitteiden suhteen (lue: liian nopea eteneminen) - määrittelytekniset riskit (keskeistä tietoa tai tavoitteita ei huomioida määrittelyvaiheessa, tavoitteissa ei huomioida tekniikan rajoituksia [yleensä hankalan toteutuksen hintaa]) - poliittiset riskit (piilotavoitteet, katteettomat lupaukset ja sitoutumattomuus, yliampuva markkinointi, erit. "X[ML] viisasten kivenä") - osaamiseen liittyvät riskit (asiakas vs. toimintaympäristö vs. toteuttajat) - teknologiaan liittyvät riskit (esim. kypsyys ja välineiden puutteet) Terve järki ja maanläheisyys auttavat riskien arvioinnissa; tyypillinen virhe on "sanella itse sisältöä ja antaa asiakkaan sanella toteutustekniikkaa" (liikaa) Hyvässä projektissa "luovuus valjastetaan hallittujen osatehtävien puitteisiin" MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 228
Dokumenttiluokkien suunnittelusta 12.6 Suunnittelun kulmakivi: systemaattinen kokeileminen Kun sisällöllinen tavoite on haarukoitu, suoraviivainen tapa lähteä liikkeelle (dokumenttiluokan) suunnittelussa on esimerkki- ja testiaineiston tuottaminen (vrt. protoilu). Käytännössä esim. dokumentteja joiden avulla... - ideoidaan tietomalli (abstrahointi ja tietorakenteiden suunnittelu) - suunnitellaan tuotanto- ja ylläpito- ja hallintaprosessit - testataan ja varmennetaan tekniikat tavoitteeseen pääsemiseksi -...ja luodaan keskusteluyhteys eri toimijoiden välille Huomaa että KYSE EI OLE DOKUMENTIN TYYPPIMÄÄRITTELYN KIRJOITTMISEST VN DOKUMENTTITYYPIN J TÄHÄN LIITTYVIEN VÄLINEIDEN SUUNNITTELUST OSN TIEDON HLLINTPROSESSIN J SEN REUNEHTOJEN SUUNNITTELU MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 229
Dokumenttiluokkien suunnittelusta 12.7 Hyviä huomioita Miten ja millä välineellä dokumenteista löytyvä tieto tuotetaan ja käsitellään? - tietokoneohjelma tuottaa/ tekninen kirjoittaja tuottaa/ kadunmies tuottaa -...ts. tarvitaanko "psykologista suunnittelua", virheiden minimointi, yms. Mikä on yksinkertaisin tietomalli joka ratkaisee ongelma (suunnittelun miniperiaate)? - pieni on kaunista (kunhan laajennettavissa) - on helppoa suunnitella "liian rikas" tietomalli jonka avulla saavutettavat (lisä)hyödyt ovat minimaalisia suhteessa haittoihin (esim. kustannukset, ymmärrettävyys, lipsuminen [vrt. TS]) Staattisen vs. dynaamisen tietomallin suunnittelu - järjestelmän objektien tyypit (tietosisällöt), ominaisuudet ja suhteet vs. informaatiovirrat systeemin eri osien välillä MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 230
Dokumenttiluokkien suunnittelusta 12.8 Suunnittelun lopputuotteista (ei pelkkä DTD) Tietomalli/skeema (kuvaileva tieto tyyppimäärityskielen avulla esitettynä) - päätason elementtihierarkia (rakenne-elementit) - mielekkäät tietokokonaisuudet / yhden tapahtumankäsittelijän tarvitsemat tiedot (tietue-elementit) - tietueiden sisältö (dataelementit) Informaali ohjeistus, (lisä)rajoitteet ja reunaehdot name - käyttöohje käyttöesimerkkeineen (sis. keskeisesti tavoitellut käyttötapaukset) - mahdollisia lisävaatimuksia (joiden formalisointi ei kenties onnistuisi valitulla tyyppimäärityskielellä järkevästi) music * album Kärjistetysti: data vs. dokumenttilähtöisen mallintamisen ero on tapa jolla tietue-elementit ovat viitattavissa/saatavilla (ts. löytyykö "päätasoa" ylipäänsä, tietue-elementtien "itseriittoisuus", kuvailu- ja metatiedot,...) tracks * track MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 231
Dokumenttiluokkien suunnittelusta 12.9 Suunnittelun visuaalisista apuvälineistä Dokumenttiluokan suunnittelu onnistuu teknisesti suoraan DTD/Skeemakielen varassa Erilaiset mallinnus- ja kuvailukielet tulevat mukaan projektin kasvaessa täsmällisyys ei kuitenkaan tarkoita "formaalin näköistä" Nyt tarkastellaan yksinkertaisuuden vuoksi vain (DTD-) suunnittelun visuaalisia apuvälineitä Tarkoituksena on nyt luonnehtia suunnittelun apuvälineitä hyvin yleisellä tasolla; käytännössä notaatio vaihtelee välineittäin, valitun tyyppimäärityskielen mukaan Huomaa suunnitteluperspektiivit notaation suhteen (conceptual-specification-implementation) name music lang: xsd:language * album id: xsd:id year: xsd:date /TEXT #PCDT tracks * track len: xsd:duration /TEXT #PCDT MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 232
Dokumenttiluokkien suunnittelusta 12.10 Esimerkkejä: Epic Editor & XML Spy Schema Editor MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 233
Dokumenttiluokkien suunnittelusta 12.11 Rakennediagrammit (1/2): idea Rakennediagrammin idea on kuvata elementin tietomalli automaatin avulla - vrt. oheinen automaatti R R: B tunnistaa (hyväksyy) kielen F B D E (B+ C)DE[FG] sanat Kyse on hyvin matalan tason G C välineestä (esim. sieventäminen) Vastaavuus säännönmukaisten kielioppien (vrt. DTD) kanssa on ilmeinen () ( B) B (,B) B MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 234
Dokumenttiluokkien suunnittelusta 12.12 Rakennediagrammit (2/2): notaatio ja rakenteet Kertojat (*, +,?), lyhennemerkintöjen määrittely (esim. &), ositetut rakennediagrammit Käytännössä käyttö nykyään melko vähäistä, mutta hyvä ymmärtää (+) BODY (*) HTML: HED (?) FRMESET HED: TITLE MET B "&B" ~ ((,B) (B,)) B MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 235
Dokumenttiluokkien suunnittelusta 12.13 Puudiagrammit (1/6): idea Puudiagrammin idea on kuvata dokumentin (yleensä geneerinen) tyyppimääritys tiivistetysti puumuodossa Visuaalisuuden keskeinen etu on tietomallin "näkeminen" kokonaisuutena; vrt. elementtien teknisten tyyppimäärittelyjen "lukeminen" Käytännössä tyyppimääritykset ovat suuria diagrammiesityksiä piirretäänkin siis esim. päätason ja tietue-elementtien tasoilla (eri kuvina) Pääpaino on usein elementtirakenteissa; attribuutit jätetään toisinaan kokonaan merkitsemättä Johtuen esim. tyyppimäärityskielten eroista, diagrammien ja vaikkapa DTDtyyppimäärityskielen välillä ei (automaattisesti) ole 1:1-suhdetta Seuraavaksi tarkastellaan ELM-puudiagrammeista (Enables Lucid Modelling) ja UML:stä (Unified Modelling Language) johdettua notaatiota MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 236
Dokumenttiluokkien suunnittelusta 12.14 Puudiagrammit (2/6): notaatio Käytössä on useita vaihtoehtoisia notaatiota; tärkeintä on tietenkin systemaattisuus ja album selkeys Huom. Nyt rajoitutaan DTD- tyyppimääritystä toisintavaan notaatioon; käytännössä esim. ID/REF - viittausrakenteet ja periytyminen id: xsd:id year: xsd:date name /TEXT #PCDT tracks * track len: xsd:duration /TEXT #PCDT suunnitellaan esim. UML:n luokkasuunnittelun mukaan (esim. association) name #PCDT album tracks * track #PCDT name type: xsd:pcdt id: xsd:id year: xsd:date id: xsd:id year: xsd:date len: xsd:duration album type: albumtype id: xsd:id year: xsd:date tracks type: trackstype id: xsd:id year: xsd:date * track type: xsd:pcdt len: xsd:duration MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 237
Dokumenttiluokkien suunnittelusta 12.15 Puudiagrammit (3/6): perusrakenteita Ohessa ELM-puudiagrammien (rekursiivinen) syntaksi XML-DTD:n mukaan esitettynä; Puun haaroihin voidaan liittää myös kertojia *, + tai? (korvaa merkki ' ' kertojalla) B C B C <!ELEMENT (B)> Notaatiota on helppo laajentaa (vrt. {4,7}); tämä mahdollistaa monimutkaisten DTD-määritysten sieventämisen suunnitteluvaiheessa B <!ELEMENT (B,C)> C <!ELEMENT (B C ) > <!ELEMENT (B C)> B C <!ELEMENT (B,C ) > MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 238
Dokumenttiluokkien suunnittelusta 12.16 Puudiagrammit (4/6): perusrakenteita Mahdollista on sopia myös kiinteästi DTD:hen liittyvä notaatio (tyhjät elementit, yhdistelmäsisältöiset elementit [mixed]) Notaatio sallii myös ositetut, luonnokset sekä entiteetein paloitellut tyyppimäärittelyt <!ELEMENT EMPTY> (REF) kuvaus jatkuu toisaalla #PCDT <!ELEMENT (#PCDT)> "TEKSTIÄ" elementin sisältö kuvataan vapaamuotoisesti (suunnittelu kesken tms.) B #PCDT <!ELEMENT (#PCDT B)*> B * eclass elementtiluokkaan eclass viitataan entiteetin avulla: <!ELEMENT (B,(%eclass;))> MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 239
Dokumenttiluokkien suunnittelusta 12.17 Puudiagrammit (5/6): attribuuteista B id: xsd:id val[0..1]: CDT C col: (RED GREEN) = RED desc: CDT = "ed"? D idname[0..1]: ID tref: IDREF id=id val=cdt? desc=cdt("ed")? B C col=(red GREEN) D idname=id? tref=idref <!ELEMENT (B C)> <!TTLIST id ID #REQUIRED val CDT #IMPLIED> <!TTLIST C col (RED GREEN) "RED"> <!ELEMENT (D?)> <!TTLIST desc CDT "ed"> <!TTLIST D idname ID #IMPLIED tref IDREF #REQUIRED> MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 240
Dokumenttiluokkien suunnittelusta 12.18 Puudiagrammit (6/6): muuta Kuten rakennediagrammien tapauksessa, lyhenne- ja lisämerkintöjä on helppo keksiä lisää Lisämerkinnät kuitenkin vain kuorruttavat notaatiota, sieventäen alla olevan skeemakielen syntaksia {1,3} 3+ B C B C <!ELEMENT (((B (B,B)) (B,B,B)),C,C,C+)> :n malli on B&C ~ <!ELEMENT ((B,C) (C,B))> MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 241
Dokumenttiluokkien suunnittelusta 12.19 Lopuksi Rakenteisia dokumentteja (kuvailevia tietorakenteita) hyödyntävän sovelluksen suunnittelu on tehtävänä erittäin yleinen ja esiintyy kaikessa tietojenkäsittelyssä Projekti ei tietenkään voi onnistua ilman yhteistyötä eri sidosryhmien kanssa - muodollinen tilaaja ja asiakkaan edustaja(t), toteutusprojektin ohjausryhmä - loppukäyttäjät - sovelluksen sisällön asiantuntijat - sisällöntuottajat ja tekniset kirjoittajat - toteutuksesta vastaavat suunnittelijat - testaajat...esitystapa ja kommunikaatio, tiedolliset ja taidolliset valmiudet, (piilo)tavoitteet MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 242
Pieni suunnittelutehtävä 13 Pieni suunnittelutehtävä Tehtävänanto: Tarvitaan yleiskäyttöinen sovellus (sis. XML-tekstiformaatin) joka tuottaa pylväsdiagrammeja SVG-formaatissa (vrt. harjoitus 12) Reunaehtoja: perusgrafiikan vaatimukset, samaa suunnittelua tulisi voida käyttää pohjana myös muissa esitysgrafiikan sovelluksissa, huokea toteutus, jne. Tarkastellaan seuraavaksi "erästä" suunnitteluprosessia ja -ratkaisua. Tarkoitus on herätellä lähinnä ideoita, nyt sovellus on lähes triviaali joten erilaisten suunnitteluratkaisujen seuraamukset on melko helppo "nähdä". MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 243
Pieni suunnittelutehtävä 13.1 Ensimmäinen mieleen tuleva ratkaisu... (?) Kerätään/analysoidaan toteutukseen tarvittavat perustiedot - otsikko, palkin korkeus, palkin väritys, nimilappu, ideoita käytöstä Koodataan kaikki mikä mieleen juolahtaa yhteen tiedostoon: <bar-set title="dire Straits"> <bar height="80px" fillcol="blue" linecolor="red"=>down to the waterline</bar> <bar height="120px" fcolor="blue">water of love</bar>... </bar-set> Huonoa: - tietosisältö ja esitystapa sekoittuneet, kuvapinnan koon esitys huono - liian spesifi tietorakenne ("tietää liikaa käyttötarkoituksestaan"), hankala laajentaa, miinusmerkki nimessä saattaa (turhaan) aiheuttaa pulmia ohjelmoinnissa, jne. MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 244
Pieni suunnittelutehtävä 13.2 Parempi ratkaisu (1/4): tietorakenne Yleistetään tietorakenne ja irrotetaan ulkoasu <dataset xml:lang="en" class="viewport" type="value_label_pairs"> <desc> <title class="title">dire Straits</title> </desc> <item class="generic_bar"> <values> <value desc="3:59">3.98</value> <!-- onko hyvä ratkaisu? --> </values> <label>down to the waterline</label> </item>... </dataset> Huono: aluksi kömpelömpi kirjoittaa(?). Hyvää: - kertoo "vain" tietosisällöstä (class-attribuutit), helppo laajentaa sekä kuvailutiedon (esim. desc-lisäosat) että datan osalta (vrt. plotmatic) - sis. valinnaisia osia (esim. lisää kuvauksia, class-attribuutit pois) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 245
Pieni suunnittelutehtävä 13.3 Parempi ratkaisu (2/4): tietomalli (muttei "paras") Säiliöelementtien etuja (esim. desc ja values): - mahdollisuus tuoda laajennuksia rakenteeseen ilman että viitaus sisältöön menee sekaisin (esim. descin sisään tieto numeroarvojen tyypeistä) - xml:lang ja classattribuuttien voidaan ajatella periytyvän jälkeläisille desc title class[0..1]: CTYPE /TEXT #PCDT - joskus säiliöt mallintavat konkreettisia objekteja (so. "sisältötiedon" poistaminen ei saa hävittää tietoa itse säiliöstä) dataset type: DTYPE xml:lang: xsd:language class[0..1]: CTYPE values desc: CDT class[0..1]: CTYPE * value desc: CDT class[0..1]: CTYPE /TEXT #PCDT * item class[0..1]: CTYPE label class[0..1]: CTYPE /TEXT #PCDT MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 246
Pieni suunnittelutehtävä 13.4 Parempi ratkaisu (3/4): ulkoasu & ratkaisun iterointia Esitystavan määrittely konfiguraationa (vaihtoehtoisesti kytkimin) <presentation type="bar_diagram"> <viewport_size width="200" height="200"> <dataset="ds-data.xml" /> <stylesheet="bars.css" type="text/css"/> </presentation> CSS-tiedostoksi kelpaa mikä tahansa SVG:n kanssa toimiva CSS-tiedosto Kysymyksiä ja kehitettävää - tarvitaanko datalle yksikkö (laskuja ja esitystä varten)? formalisoidaanko esitystapa tarkemmin? (nythän ei kirjattua tietoa esim. sommittelusta) - onko datan tyypin ja esitystavan tyypin esitys riittävän selkeä, tarvitaanko formalisointi (todennäköisesti ei, voidaan ohjeistaa että value_label_pairs - tyyppinen datajoukko sopii bar_diagram-tyyppiseen esitykseen) - nimet ja termit! (desc...) rakenteiden viilaus, viittaukset, nimiavaruus? MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 247
Pieni suunnittelutehtävä 13.5 Parempi ratkaisu (4/4): prosessin suunnittelu Julkaisuprosessin hahmotelma näyttäytyy käytännössä yhtenä suunnittelun reunaehtona (luvut 10-11 voidaan nyt löyhästi tulkita esitutkimuksena) XSL-muunnoksen helpottamiseksi (ja nopeuttamiseksi) voidaan tuottaa d2svgbars.xsl esim. aputiedosto stats.xml: <stats maxvalue="5.2" items="9" /> Sovelluksen sisäiset välivaiheet on taas helppo kapseloida tyyliin barmatic Huomaa miten esim. "tyylejä" esiintyy sovelluksessa eri rooleissa Tarvitaan tietenkin vielä toteutus... bars.css pres.xml dataset.xml Statistics.py XSLT-pros. stats.xml out.svg MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 248
Pieni suunnittelutehtävä 13.6 Huomautuksia Nyt sovellus on tarkoituksella niin yksinkertainen että tyydyttävä ratkaisu on "nähtävissä suoraan" (ja ideointi on helppoa): näin ei tietenkään aina ole Nyt käytännössä tarvittiin kuitenkin jo mm. - substanssiosaamista (pylväsdiagrammit ja niiden käyttö esim. music-sovelluksessa, ideoita järkevistä laajennuksista, esim. PlotMatic) - SVG ja CSS-teknologioiden osaamista - XML-sovellusohjelmointiin liittyvää osaamista (esim. XSLT ja DOM2) - ymmärrystä tietojenkäsittelystä (rakenteiset dokumentit ja tiedon mallintaminen prosessoinnin näkökulmasta) - "XML-osaamista" (mutta <tag/>-osaaminen ei riitä mihinkään!)...jota ilman tehtävän toteuttaminen ei ilmeisestikään olisi onnistunut MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 249
Kohti suunnittelijan muistilistaa 14 Kohti suunnittelijan muistilistaa Projektin se-ja-se suunnittelutehtävä on erittäin konkreettinen, useita erilaisia taitoja, tilannetajua ja luovuutta vaativa prosessi. Suunnittelu sinänsä on kuitenkin abstrakti prosessi josta on periaatteessa helppo puhua teoriassa. Kuten tavallista, todellinen haaste piilee eri tarkastelutasojen toimivassa yhdistämisessä (ja harjaantuneisuudessa). Seuraavassa tarkastellaan tietorakenteiden suunnittelua yksityiskohtaisella tasolla ja dokumenttityypin suunnitteluprosessia yleisellä tasolla, suunnittelumallien tavoin. Tarkoituksena on lähinnä nostaa esille merkillepantavia asioita yksinkertaisen muistilistan hengessä. MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 250
Kohti suunnittelijan muistilistaa 14.1 Kuvaileva merkkaus & tiedon luokittelu (1/2) (Tiedon hallintaprosessin kontekstissa) dokumenttityypin suunnittelussa tulee vastaan kolmentyyppistä tietoa: - (sovelluksen keskeinen) asiasisältö (content), (asiasisällön koodaus)rakenne (structure) ja esitystapa (presentation) Esimerkkejä (ideoita saattavat vaihdella sovelluksissa merkittävästikin) - osoite, katu, koneen osanumero, myyntiartikkelin lukumäärä, hinta, erisnimi, kuvaus, tietokoneohjelman komento, kakkureseptin raaka-aine, paistolämpötila - luku, kappale, lista, luettelo, taulukko, palsta, metodi, luokka, säiliö, joukko, relaatio - tietyn näköinen elementti, kirjasimella Y merkitty kappale, koristekuva, vaakaviiva, sivunvaihdon merkitsevä elementti, varjostus, vakioteksti, logo, sivunumero, kaavion tai tekstiluvun numero MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 251
Kohti suunnittelijan muistilistaa 14.2 Kuvaileva merkkaus & tiedon luokittelu (2/2) Rakenteisten dokumenttien suunnittelun nyrkkisääntöjä - rakenne-tyyppisten elementtien avulla sisällöistä jäsennetään tietueita -...joita edelleen ryhmitellään päätasolla (dokumenttilähtöinen suunnittelu) -...tai rakenne-tyyppisiä tietoja käytetään tietue-elementtien kuvailuun (datalähtöinen suunnittelu) - esitystapa-tyyppisiä elementtejä/tietoja ei sekoita muiden kanssa vaan otetaan käyttöön "tyylimääritysten" muodossa (se, että tämä todellakin onnistuu pitää etukäteen tietenkin tutkia, testata ja dokumentoida) Erityisen suurta huomiota kannattaa kiinnittää: - kuvaavien nimien keksimiseen (sovellusalueen "luonnolliset" nimet) - yleiskäyttöisten rakenteiden suunnitteluun (hyvät perusideat toistuvat) - viittausrakenteisiin (identifiointi/avaimet), määrittelyn systemaattisuuteen MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 252
Kohti suunnittelijan muistilistaa 14.3 Rakenteiden päälinjoja (1/5): geneerisyys Sopimaton tietorakenne hankaloittaa sekä tiedon tuottamista, hallintaa että sen hyödyntämistäkin Rakenteiden suhteen joudutaan yleensä suorittamaan perusvalinta merkkauksen sisältöspesifisyyden tai pelkän rakenteellisen yhtäläisyyden välillä (esimerkkejä seuraa lisää tuonnempana): - runkona sisällön mukaan nimetyt elementit (content-based model) - runkona rakenteen mukaan nimetyt elementit (structure-based model) Esimerkki: sisältöspesifisyys vs. geneerisyys: <!ELEMENT BOOK (BSRCT,INTRODUCTION,TERMS,THEORY,MODEL, PPLICTION,REFINEMENT,RESULTS,DISCUSSION,REFS)> <!ELEMENT BOOK (BSTRCT,SECTION+,REFS)> <!TTLIST SECTION TYPE CDT #IMPLIED> MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 253
Kohti suunnittelijan muistilistaa 14.4 Rakenteiden päälinjoja (2/5): joustavuus Suunnittelukriteerinä voidaan pitää myös annetun rakenteen jäykkyyttä tai joustavuutta: - (lähes) kaikkien elementtien kirjoittaminen pakollista (rigid model) - pakollinen elementtijoukko on pieni (flexible model) Esimerkki: jäykkyys vs. joustavuus <!ELEMENT BOOK (BSRCT,INTRODUCTION,TERMS,THEORY,MODEL, PPLICTION,REFINEMENT,RESULTS,DISCUSSION,REFS)> <!ELEMENT BOOK (BSRCT,INTRODUCTION?,TERMS?, (THEORY EXMPLES),MODEL,PPLICTION*, REFINEMENT*,RESULTS,DISCUSSION?,REFS?)> Strategian määräävät tietenkin työn reunaehdot (esim. yhteensopivuus legacy-sovellusten kanssa, aidosti pakolliset tiedot, tekn. kirj. laiskuus) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 254
Kohti suunnittelijan muistilistaa 14.5 Rakenteiden päälinjoja (3/5): yhdistelmäsisältöisyys Tyypillinen tilanne, jossa jäykkyyden ja joustavuuden välille vedetään selkeä raja on (matalan tason suunnittelu)päätös mixed/children element content - tyyppisten mallien välillä Esimerkki: yhdistelmäsisältöinen tietomalli vs. elementtiperustainen tietomalli <!ELEMENT PRG (#PCDT EM NOTE QUOTE)*> <!ELEMENT PRG ((EM? (QUOTE,NOTE)?),TEXT)*> <!ELEMENT TEXT (#PCDT)> Huomaa rakenteiden ja ohjelmallisen käsittelyn erot (yhdistelmä on tietomallina hyvin salliva) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 255
Kohti suunnittelijan muistilistaa 14.6 Rakenteiden päälinjoja (4/5): eksplisiittisyys Valinta joudutaan tekemään myös (meta)tiedon eksplisiittisen esittämisen ja kokoamisen suhteen: - kerätäänkö (meta)tietoa valmiiksi omiksi elementeikseen (eksplisiittinen ratkaisu) - vai koostetaanko (meta)tieto sieltä täältä dokumenttia vasta tarvittaessa (implisiittinen ratkaisu) Käytännössä dokumentin tiedoista osa on implisiittisessä muodossa (vrt. puurakenteen hyödyntäminen); määräävä tekijä on yleensä tilantarve vs. käsittelyn tehokkuus Esimerkki: henkilön isoäidin nimen päättely vs. auki kirjoittaminen <PERSON NME="Jack" MOTHER="Jill"/> <PERSON NME="Jill" MOTHER="Judith"/> <PERSON NME="Jack" MOTHER="Jill" GRNDMOTHER="Judith"/> <PERSON NME="Jill" MOTHER="Judith"/> MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 256
Kohti suunnittelijan muistilistaa 14.7 Rakenteiden päälinjoja (5/5): rekursiivisuus Hierarkkisten elementtirakenteiden syvyyteen joudutaan yleensä ottamaan myös kantaa. Vaihtoehtoja ovat - rekursiiviset elementtimallit (recursive) - lapsielementit luettelevat elementtimallit (specified) Esimerkki: rekursio vs. kiinteä hierarkia <!ELEMENT BOOK (SECTION)> <!ELEMENT SECTION (SECTION+ CONTENT)> <!ELEMENT BOOK (SECTION)> <!ELEMENT SECTION (SUBSECTION+ CONTENT)> Rekursion käytön (käytännölliset) perusteet kannattaa miettiä huolella sukutiedot * henkilö sotu: ID nimi: CDT äiti: IDREF isä: IDREF...koska käytännössä voi olla järkevää rakentaa esim. relaatiomainen tietorakenne jonka käsittely on rekursiivista (vrt. sukupuu) * lapsi sotu: IDREF toinen-vanhempi: IDREF MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 257
Kohti suunnittelijan muistilistaa 14.8 Elementit vs. attribuutit (1/2) Suunnittelun konkreettinen pulma on tiedon jakaminen järkevästi elementeiksi ja attribuuteiksi Jako on osin mielivaltainen, nyrkkisääntöjä: - elementit ovat konkreettisia (ja keskeisiä) objekteja joiden ominaisuuksia attribuutit luonnehtivat - toisinaan auttaa ajatus jonka mukaan "dokumentti on luettavissa ilman tageja" (SGML-filosofia) Elementtien tyypillisiä ominaisuuksia: - hierarkkisuus, kertojat, paljon tekstiä, paloiteltava osiin (entiteetit), kirjoitetaan tekstieditorilla ttribuuttien tyypillisiä ominaisuuksia: 1788, Chekov - määre, oletusarvot, vähän tekstiä, annetaan Ominaisuudet-dialogin avulla MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 258
Kohti suunnittelijan muistilistaa 14.9 Elementit vs. attribuutit (2/2) Tiedon jako elementteihin ja attribuutteihin riippuu lopulta esim: - jo vakiintuneista käytännöistä - merkkauskäytännöstä esitetyistä toiveista (esim. joskus kaikki tieto halutaan esittää elementteinä) - dokumenttien käsittelyn tekniikkaan liittyvistä rajoitteista (esim. CSS1 ei osaa esittää attribuutteja) - XML-määritysten sisäisistä suunnitteluvalinnoista (esim. XML DTD:n avulla voidaan elementille sallia mv. määrä lapsielementtejä mutta ei attribuutteja ja jäsentämätöntä dataa käsitellään aina attribuutteihin liitettävien entiteettiviittausten perusteella) - työkaluohjelmistojen rajoitteista (esim. ohjelma se-ja-se ei osaa käsitellä kaikentyyppistä attribuuttitietoa oikein) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 259
Kohti suunnittelijan muistilistaa 14.10 Vielä säiliöelementeistä Elementtien ja attribuuttien selkein ero mallinnuksessa on hierarkkisuus Tärkeä elementtien "erikoistapaus" ovat ns. säiliöelementit (container) Tarkastellaan esimerkkiä - säilytetään tietoja tarvikkeista ja niiden sijainneista varastoissa - miten varaston tietojen käy tarvikkeiden tietoja poistettaessa? tarvikkeet * tarvike nimi: CDT varaston-sijainti: CDT varasto-lukittavissa: (kyllä ei) Ts. myös tieto varastosta on arvokasta (ja siihen liittyy määreitä, kuten varasto-lukittavissa) ja varaston tiedot periytyvät tarvikkeille (sijainti) tarvikkeet * varasto sijainti: CDT lukittavissa: (kyllä ei) * tarvike nimi: CDT Varastolle voitaisiin määritellä myös jokin oletusominaisuus jonka "poikkeavat" tarvikkeet päällekirjoitettavat (vrt. perintä ja esim. xml:lang XHTMLdokumentissa) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 260
Kohti suunnittelijan muistilistaa 14.11 Olio- vs. relaatioperustainen suunnittelu Puumainen tiedonesitys ei tietenkään pakota "oliomaisuuteen"; myös relaatiomaiset tietomallit ovat tietenkin mahdollisia - käytön intuitiivisuus, periytyvät tiedot (päällekirjoitus) - datan paloittelun helppous, sovellusohjelmoinnin haasteet -... tarvikkeet tiedot * varasto sijainti: CDT lukittavissa: (kyllä ei) * tarvike nimi: CDT vs. varastot * varasto sijainti: CDT tunniste: ID lukittavissa: (kyllä ei) tunniste varasto tarvikkeet * tarvike nimi: CDT varasto: IDREF MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 261
Kohti suunnittelijan muistilistaa 14.12 Suunnittelijan muistilista (1/4) Kirjataan seuraavaksi kärjistetyn tiivis mutta konkreettinen muistilista joka käy läpi dokumenttiluokan suunnittelu- ja toteutusvaiheet Vaihe 0, määrittely ja esitutkimus - asetetaan dokumenttiluokan avulla muotoiltava ongelma ja tavoite sen ratkaisemiseksi ja varmistetaan työn onnistumisen edellytykset Vaihe 1, elementtien tunnistaminen - ideoidaan (esim. käsitekaavion ja/tai esimerkkien avulla) minkälaisen tietorakenteen avulla käsillä olevan tietosisällön esittäminen on mahdollista ja tunnistetaan elementit Vaihe 2, elementtien luokittelu - luokitellaan elementit niiden ominaisuuksien mukaan (ainakin asiasisältö, rakenne, esitystapa) ja erotetaan toisistaan erityyppinen tieto MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 262
Kohti suunnittelijan muistilistaa 14.13 Suunnittelijan muistilista (2/4) Vaihe 3, esimerkeistä oppiminen - tutustutaan muihin tunnettuihin samantyyppisiin suunnittelutöihin ja sovelluksiin ja arvioidaan erilaisista suunnitteluratkaisuista seuraavia hyviä ja huonoja puolia Vaihe 4, tuotanto- ja käsittelyprosessin läpikäynti - käydään koko ajateltu (dokumenttien/datan) hallintaprosessi läpi ja kirjataan mitä tietoja tarvitaan prosessi(e)n eri vaiheissa Vaihe 5, elementtien valinta - valitaan omassa sovelluksessa tarvittavat kuvailevat elementit, tarkennetaan tietorakennetta (so. dokumenttien tietosisältö vs. esitystavan tietosisältö vs. hallintaprosessin tietosisältö) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 263
Kohti suunnittelijan muistilistaa 14.14 Suunnittelijan muistilista (3/4) Vaihe 6, päätason hierarkian suunnittelu - jäsennetään dokumenttiluokan ylärakenne rakennetyyppisten elementtien avulla (tai määritetään datalähtöisen sovelluksen kuvailutiedot); sovelluksen yksityiskohdat jäävät vielä avoimiksi Vaihe 7, tietue-elementtien kokoaminen - tunnistetaan usein toistuvat tietorakenteet ja jäsennetään niiden rakenne Vaihe 8, dataelementtien koostaminen - kootaan sisältötyyppiset elementit rakenne-tyyppisten elementtien lapsiksi Vaihe 9, yhdistäminen - yhdistetään suunnittelun eritasoiset rakenteet yhdeksi kokonaisuudeksi Vaihe 10, viittaukset - tunnistetaan ja toteutetaan viittaukset ja niiden tulkinta elementtien välillä MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 264
Kohti suunnittelijan muistilistaa 14.15 Suunnittelijan muistilista (4/4) Vaihe 11, varmentaminen ja arviointi - käydään läpi alkuperäinen määrittely ja tutkitaan & testataan että varmasti tehtiin oikea työ ja että se tehtiin oikein (osana hallintaprosessia) Vaihe 12, sovelluksesta riippuen - koulutus, ylläpito, päivitykset, versioinnin suunnittelu, laajennukset,... Huomioita - luksi (vaiheet 1-3) kannattaa ottaa mukaan enemmän tietoa kuin tarvitaan ja valita & karsia (perustelujen kera) sisältöä vaiheessa 4; kokeile; älä takerru ensimmäisiin ideoihin; keksi hyviä nimiä - Työ tietenkin dokumentoidaan (esimerkit!) ja kirjataan suunnitteluratkaisut ylös perusteluineen (muuten unohdetaan miksi valinnat tehtiin) - Muista suunnittelijan mantra kun mietit piirteen X sisällyttämistä sovellukseen: välttämätön - tarpeellinen - hyödyllinen (älä näpertele!) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 265
Kohti suunnittelijan muistilistaa 14.16 Hyvän suunnittelun teknisiä piirteitä Noudata määrittelyä - suunnittelun tulee tähdätä ensisijaisen ja sovitun ongelman ratkaisemiseen Vältä tiedon päällekkäisyyttä - jos sama tieto useassa paikassa, luvassa on päivityspulmia Vältä turhia kytköksiä - suosi modulaarisia rakenteita (poistopulmat!) Yksinkertainen on kaunista - yksinkertaisin ratkaisu jota voi laajentaa hallitusti on usein paras Valitse sanasto huolella - käytä aina "luonnollisia" käsitteitä (ihmisiä varten) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 266
Kohti suunnittelijan muistilistaa 14.17 Hyvän suunnittelun strategisia piirteitä Täydellisyys - kaikki asiaankuuluva määritellään ja kuvataan Tarkkuus ja virheettömyys - minimoitu väärinymmärtämisen mahdollisuus, ei asiavirheitä Ymmärrettävyys - esitystapa on niin yksinkertainen kuin mahdollista (muttei yhtään yksinkertaisempi), sopusoinnussa täydellisyyden ja tarkkuuden kanssa Testattavuus - mahdollisuus tarkistaa työ suhteessa määrittelyyn ja tavoitteisiin Jäljitettävyys - mahdollisuus seurata määrityksiä suunnitteluvalintojen kautta toteutukseen ja päinvastoin (ts. kirjaa ja perustele nekin vaihtoehdot joita ei valittu) MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 267
Kohti suunnittelijan muistilistaa 14.18 Lopuksi Opiskelun alkuvaiheessa tulee helposti korostaneeksi tekniikan roolia tietoteknisten ongelmien ratkaisussa. Tekniikka on kuitenkin vain väline määrittelyn, suunnittelun ja toteutuksen "välissä" väline joka pitää tietenkin hallita Jos kuitenkaan ei osaa ("teknisesti") toteuttaa annetun määrittelyn kuin "yhdellä tavalla", ei todennäköisesti pysty hyvään suunnitteluun Hyvän projekti edellyttää perustaitojen ohella paitsi rutinoitunutta osaamista, myös tilannetajua Tilaajan pitää osata määritellä ongelmansa reunaehtoineen sekä arvioida toteutuksen vaativuus (hinta); usein tämä edellyttää suunnitteluosaamista Toimittajan pitää osata (paitsi toteuttaa työ, myös) arvioida toteutuksen vaativuus (hinta), sekä ymmärtää jättää itselleen liikkumavaraa jos ja kun kaikki ei mene aivan täsmälleen kartoitusten osoittamalla tavalla MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 268
Loppusanat 15 Loppusanat Rakenteinen dokumentaatio tarjoaa lähtökohdan erityyppisten tietoa prosessimaisesti käsittelevien sovellusten toteuttamiseen. Perusidea on mallintaa tietoa sen käsittelyn näkökulmasta. Useissa sovelluksissa XML:n keskeinen funktio on tarjota puitteet tiedon mallintamiselle, ohjelmalliselle käsittelylle sekä sovellusten eri osien integroinnille. Toimiva lähestymistapa on mieltää XML rajapintana. Sovellusten suunnittelu on kuin vieraan kaupunkikartan tarkastelua; kun tiedetään missä ollaan ja minne halutaan mennä, pulmaksi jää rakentaa toimiva yhteys pisteiden välille, saatavilla olevia välineitä hyödyntäen ja resurssit huomioiden (ts. milloin kävellä, milloin mennä metrolla, milloin on syytä rakentaa kokonaan uusi reitti). MTHM-47150 RKENTEISET DOKUMENTIT (kevät 2006) - ON 269