12 Dokumenttiluokkien suunnittelusta

Transkriptio

1 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ä RKENTEISET DOKUMENTIT (kevät 2005) - ON 216

2 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 217

3 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 218

4 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) RKENTEISET DOKUMENTIT (kevät 2005) - ON 219

5 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 220

6 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" RKENTEISET DOKUMENTIT (kevät 2005) - ON 221

7 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 222

8 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ä RKENTEISET DOKUMENTIT (kevät 2005) - ON 223

9 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 224

10 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 225

11 12.10 Esimerkkejä: Epic Editor & XML Spy Schema Editor RKENTEISET DOKUMENTIT (kevät 2005) - ON 226

12 12.11 Rakennediagrammit (1/2): idea Rakennediagrammin idea on kuvata elementin tietomalli automaatin avulla - vrt. oheinen automaatti R R: tunnistaa (hyväksyy) kielen F D E (+ 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 () ( ) (,) RKENTEISET DOKUMENTIT (kevät 2005) - ON 227

13 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ää (+) ODY (*) HTML: HED (?) FRMESET HED: TITLE MET "&" ~ ((,) (,)) RKENTEISET DOKUMENTIT (kevät 2005) - ON 228

14 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 229

15 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 230

16 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) C C <!ELEMENT ()> Notaatiota on helppo laajentaa (vrt. {4,7}); tämä mahdollistaa monimutkaisten DTD-määritysten sieventämisen suunnitteluvaiheessa <!ELEMENT (,C)> C <!ELEMENT ( C ) > <!ELEMENT ( C)> C <!ELEMENT (,C ) > RKENTEISET DOKUMENTIT (kevät 2005) - ON 231

17 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.) #PCDT <!ELEMENT (#PCDT )*> * eclass elementtiluokkaan eclass viitataan entiteetin avulla: <!ELEMENT (,(%eclass;))> RKENTEISET DOKUMENTIT (kevät 2005) - ON 232

18 12.17 Puudiagrammit (5/6): attribuuteista 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")? C col=(red GREEN) D idname=id? tref=idref <!ELEMENT ( 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> RKENTEISET DOKUMENTIT (kevät 2005) - ON 233

19 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+ C C <!ELEMENT ((( (,)) (,,)),C,C,C+)> :n malli on &C ~ <!ELEMENT ((,C) (C,))> RKENTEISET DOKUMENTIT (kevät 2005) - ON 234

20 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 RKENTEISET DOKUMENTIT (kevät 2005) - ON 235