12 Dokumenttiluokkien suunnittelusta

Transkriptio

1 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ä. 243

2 Dokumenttiluokkien suunnittelusta 12.1 Suunnittelutehtävän reunaehdoista Rakdok-suunnittelu käynnistyy yleensä (esi)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 Usein keskeinen tavoite on uudelleenkäyttö; tällöin työ etenee komponenttipohjaisen kehitysprosessin ideoiden ja reunaehtojen varassa Onnistumisen avain on hyvä sovellusalueen ja välineiden tuntemus 244

3 Dokumenttiluokkien suunnittelusta 12.2 The reuse landscape of software development Rakdok-suunittelussa uudelleenkäyttöä esiintyy siis tietosisällön, tietomallien ja työprosessien tasolla Ohjelmistotuotannon näkökulmasta merkittävän suunnittelun reunaehdon tarjoavat myös uudelleenkäytettävät välineet (vrt, (Sommerville, 2007)): Component-based development Component frameworks Legacy-system wrapping pplication product lines Design patterns spect-oriented software development Commercial-off-the-shelf (COTS) integration Program generators Service-oriented systems Program libraries Configurable vertical applications 245

4 Dokumenttiluokkien suunnittelusta 12.3 Systemaattisen työn vaiheet Kaikentyyppinen projektityö hyötyy hyväksi havaitun työvaihejaon mukaisesta jäsennyksestä (jonka eräs kärjistys on ns. vesiputousmalli) 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 246

5 Dokumenttiluokkien suunnittelusta 12.4 Systemaattisuudesta ja menetelmistä (1/2) Mikäli suunnittelukäytäntö on epäselvä ja huonosti dokumentoitu, 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 (esim. dokumentointi, raportointi, testaus, korjaukset, paketointi, koulutus) - suunnitteluprosessin seuraaminen on hankalaa ja tehtyjen päätösten vaikutusten arvioiminen jälkikäteen (ja esim. työstä oppiminen!) vaikeaa 247

6 Dokumenttiluokkien suunnittelusta 12.5 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 voi 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) 248

7 Dokumenttiluokkien suunnittelusta 12.6 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" 249

8 Dokumenttiluokkien suunnittelusta 12.7 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 ja välineet tavoitteeseen pääsemiseksi -...ja luodaan keskusteluyhteys eri toimijoiden välille Huomaa että kyse ei ole "vain" dokumentin tyyppimäärittelyn kirjoittamisesta vaan dokumenttityypin ja tähän liittyvien välineiden suunnittelusta osana tiedon hallintaprosessin ja sen reunaehtojen suunnittelua 250

9 Dokumenttiluokkien suunnittelusta 12.8 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ä 251

10 Dokumenttiluokkien suunnittelusta 12.9 Suunnittelun lopputuotteista (ei pelkkä DTD) Tietomalli/skeema (kuvaileva tieto tyyppimäärityskielen avulla esitettynä) - päätason elementtihierarkia (rakenne-elementit) music - mielekkäät tietokokonaisuudet / yhden tapahtumankäsittelijän * tarvitsemat tiedot (tietue-elementit) album - tietueiden sisältö (dataelementit) Informaali ohjeistus, (lisä)rajoitteet ja reunaehdot - käyttöohje esimerkkeineen (sis. keskeiset käyttötapaukset) name - mahdollisia lisävaatimuksia (joiden formalisointi ei kenties onnistuisi valitulla tyyppimäärityskielellä järkevästi) Kärjistetysti: data vs. dokumenttilähtöisen mallintamisen ero on tapa tietoa tuotetaan ja jolla tietue-elementit ovat viitattavissa/saatavilla (ts. löytyykö "päätasoa" ylipäänsä, tietue-elementtien "itseriittoisuus", kuvailu- ja metatiedot,...) tracks * track 252

11 Dokumenttiluokkien suunnittelusta 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 valitun suhteen (esim. UML ja conceptual-specification-implementation) name music lang: xsd:language * album id: xsd:id year: xsd:date /TEXT #PCDT tracks * track len: xsd:duration /TEXT #PCDT 253

12 Dokumenttiluokkien suunnittelusta Esimerkkejä: Epic Editor & XML Spy Schema Editor 254

13 Dokumenttiluokkien suunnittelusta 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 255

14 Dokumenttiluokkien suunnittelusta 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 256

15 Dokumenttiluokkien suunnittelusta 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) Notaatiota on helppo laajentaa (vrt. {4,7}); tämä mahdollistaa monimutkaisten DTD-määritysten sieventämisen suunnitteluvaiheessa <!ELEMENT (B)> B B C <!ELEMENT (B,C)> C <!ELEMENT (B C ) > B C <!ELEMENT (B C)> B C <!ELEMENT (B,C ) > 257

16 Dokumenttiluokkien suunnittelusta 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;))> 258

17 Dokumenttiluokkien suunnittelusta 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> 259

18 Dokumenttiluokkien suunnittelusta 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))> 260

19 Dokumenttiluokkien suunnittelusta Rakennediagrammit (1/2): idea Rakennediagrammin idea on kuvata elementin tietomalli automaatin avulla - vrt. oheinen automaatti R tunnistaa (hyväksyy) kielen (B+ C)DE[FG] sanat Kyse on hyvin matalan tason välineestä (esim. sieventäminen) Vastaavuus säännönmukaisten kielioppien (vrt. DTD) kanssa on ilmeinen R: B C B D E F G () ( B) B (,B) B 261

20 Dokumenttiluokkien suunnittelusta Rakennediagrammit (2/2): notaatio ja rakenteet Kertojat (*, +,?), lyhennemerkintöjen määrittely (esim. &), ositetut rakennediagrammit Käytännössä käyttö dok.suunnittelussa nykyään melko vähäistä, mutta hyvä ymmärtää (+) BODY (*) HTML: HED (?) FRMESET HED: TITLE MET B "&B" ~ ((,B) (B,)) B 262

21 Dokumenttiluokkien suunnittelusta Lopuksi Rakenteisia dokumentteja (kuvailevia tietorakenteita) hyödyntävän sovelluksen suunnittelu on tehtävänä erittäin yleinen ja esiintyy (osatehtävänä) 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, yms. 263

22 Kohti suunnittelijan muistilistaa 13 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ä. 264

23 Kohti suunnittelijan muistilistaa 13.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 265

24 Kohti suunnittelijan muistilistaa 13.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 266

25 Kohti suunnittelijan muistilistaa 13.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> 267

26 Kohti suunnittelijan muistilistaa 13.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) 268

27 Kohti suunnittelijan muistilistaa 13.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) 269

28 Kohti suunnittelijan muistilistaa 13.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"/> 270

29 Kohti suunnittelijan muistilistaa 13.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 * lapsi sotu: IDREF toinen-vanhempi: IDREF...koska käytännössä voi olla järkevää rakentaa esim. relaatiomainen tietorakenne jonka käsittely on rekursiivista (vrt. sukupuu) 271

30 Kohti suunnittelijan muistilistaa 13.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 272

31 Kohti suunnittelijan muistilistaa 13.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) 273

32 Kohti suunnittelijan muistilistaa 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) tarvikkeet * varasto sijainti: CDT lukittavissa: (kyllä ei) * tarvike nimi: CDT Ts. myös tieto varastosta on arvokasta (ja siihen liittyy määreitä, kuten varasto-lukittavissa) ja varaston tiedot periytyvät tarvikkeille (sijainti) Varastolle voitaisiin määritellä myös jokin oletusominaisuus jonka "poikkeavat" tarvikkeet päällekirjoitettavat (vrt. perintä ja esim. xml:lang XHTMLdokumentissa) 274

33 Kohti suunnittelijan muistilistaa 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 275

34 Kohti suunnittelijan muistilistaa Muodollisen dokumenttisuunnittelun yleisperiaate "Rakennesuunnittelu" testitapaus asiasisältö? rakenne? esitystapa? rakenneelementit? tietue-elementit? data-elementit? "Tyylisuunnittelu" käsittelyprosessin reunaehdot? säiliöelementit? viittaukset ja tasojen yhdistäminen? suunnitteluratkaisu taittomalli (tms.) formatointiominaisuudet kytkös rakenteeseen Määrittely Jäsennys Suunnittelu Testaus 276

35 Kohti suunnittelijan muistilistaa 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 277

36 Kohti suunnittelijan muistilistaa 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ö) 278

37 Kohti suunnittelijan muistilistaa 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ä 279

38 Kohti suunnittelijan muistilistaa 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!) 280

39 Kohti suunnittelijan muistilistaa 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) 281

40 Kohti suunnittelijan muistilistaa 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) 282

41 Kohti suunnittelijan muistilistaa Lopuksi Opiskelun alkuvaiheessa tulee helposti korostaneeksi tekniikan roolia tietoteknisten ongelmien ratkaisussa. Käytännössä työtä tekevät aina ihmiset. Tekniikka on 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, erityisesti: 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 283

42 Loppusanat 14 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). 284

43 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) Tehtävänanto: Tarvitaan yleiskäyttöinen sovellus (sis. XML-tekstiformaatin) joka tuottaa pylväsdiagrammeja SVG-formaatissa 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ä". 285

44 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.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. 286

45 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.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> Huonoa: 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) 287

46 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.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 288

47 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.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? 289

48 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.5 Parempi ratkaisu (4/4): prosessin suunnittelu Julkaisuprosessin hahmotelma näyttäytyy käytännössä yhtenä suunnittelun reunaehtona (prujun aikaisemmpia lukuja voidaan pitää esitutkimuksena) XSL-muunnoksen helpottamiseksi (ja nopeuttamiseksi) voidaan tuottaa 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 bars.css pres.xml dataset.xml Statistics.py d2svgbars.xsl XSLT-pros. stats.xml Tarvitaan tietenkin vielä parempi määrittely, oikea testiaineisto, suunnittelu, toteutus, testaus, yms. out.svg 290

49 LIITE: Pieni suunnittelutehtävä (lisämateriaalia) 15.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 (sovelluksen kohdeympäristö, 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 291