Suunnittelu - tietorakenteet

Transkriptio

1 Suunnittelu - tietorakenteet ietorakenteet ovat datan abstraktioita Rakenteella pyritään mahdollistamaan tehokas käsittely (operaatiot) - ei itseisarvoa Rakenteet ohjelmointikielestä riippumattomia Valitaan sovelluksen ja ongelman mukaan Ohjelma = algoritmit + tietorakenteet Abstrakti tietotyyppi = operaatioiden avulla määritelty tietorakenne, jonka tekninen toteutus piiloutuu operaatioiden taakse Yleisesti käytettyjen rakenteiden hyvyyttä ja soveltuvuutta on tarkastetu esim. ietorakenteet ja iedonhallinta I -kursseilla. Suunnittelu - tietorakenteet sisältö analyysivaihessa, tekninen rakenne suunnitteluvaiheessa tietorakenteet vaikuttavat keskeisesti ohjelmiston toimintaan ja tehokkuuteen säätelevät mahdollisuuksia algoritmivalintaan esim tunnuksen perusteella hakemisessa kertaluokkaerot tehokkuudessa eri rakenteilla Harri Laine 1

2 ietorakenteiden suunnitteluperiaatteita (Wasserman) Käytä systemaattisia menetelmiä (esim. normalisointia voi käyttää myös keskusmuistirakenteiden analyysissä redundassin vähentämiseen). Generoi vaihtoehtoja ja arvioi niitä. arkastele tietorakenteiden yhteydessä myös niihin kohdistuvia toimenpiteitä (rakenteen edut ja haitat ilmenevät operaatioiden kautta) Käytä ja pidä yllä tietosanastoa. Käytä asteittaista tarkentamista myös tietorakenteiden määrittelyssä. ietorakenteen esitysmuoto ei saa näkyä muille kuin sitä suoraan käyttäville moduuleille. ietorakenteiden suunnitteluperiaatteita (Wasserman) Kokoa käyttökelpoisista tietorakenteista ja niihin käytettävistä operaatioista kirjasto. Käytä abstrakteja tietotyyppejä suunnittelussa ja toteutuksessa Harri Laine 2

3 Suunnittelu -algoritmit Miten operaatiot toteutetaan? Algoritmeille useita kuvaustekniikkoja, esim: perinteinen kulkukaavio (flow chart) pseudokoodi rakenteinen kulkukaavio (Nassi-Sneidermann) päätöstaulu Perinteinen kulkukaavio toiminta ehto ehdon arvo nuoli kuvaa kontrollin etenemistä Harri Laine 3

4 Kulkukaavio: johtaja urhapuron päivä herää juo kalja nälkä? syö kyljys pukeudu sataa? katsele tv:tä mene töihin ilta? mene nukkumaan pseudokoodi: johtaja urhapuron päivä begin herää; repeat until mene nukkumaan happens: if nälkä then syö kyljys else juo kalja; if sataa then begin katsele tv:ta; if ilta then mene nukkumaan; end else begin pukeudu; mene töihin; mene nukkumaan; end; end; Harri Laine 4

5 rakenteiset kulkukaaviot toiminto 1 toiminto 2 toiminto 3 peräkkäisyys while-ehto toiminto while-silmukka toiminto until -ehto do until -silmukka ehto 1 2 case-lauseke thentoiminto elsetoiminto toiminto 1... if-rakenne case-rakenne rakenteinen kulkukaavio: johtaja urhapuron päivä herää nälkä? juo kalja syö kyljys sataa? pukeudu katsele tv:tä mene töihin mene nukkumaan until nukkumassa ilta? mene nukkumaan Harri Laine 5

6 ehdon arvo säännössä Päätöstaulut säännön tunnus Sääntö n n+1 Ehto i oiminta I oiminta I+1 x x merkintä siitä, että toiminta suoritetaan kun sääntö voimassa Päätöstauluesimerkki ei merkitystä Sääntö Sairaana Sataa Viikonloppu öihin Sänkyyn Kylään V auki x x x x x x kaikki arvoyhdistelmät otettava mukaan (muutoin-vaihtoehtoa voi käyttää) Harri Laine 6

7 Algoritmin valinta Moduulin suunnittelijalla on vapaat kädet laatia algoritmi (annettujen vaatimusten rajoissa) Valmiit algoritmit: ei kannata kehittää uutta algoritmia, jos tarkoitukseen sopiva on jo olemassa Algoritmin soveltuvuus: virheettömyys voimassaoloalue tehokkuus toteutusympäristöstä riippuvat rajoitukset Suorituskyky Suorituskykynäkökohdat on otettava huomioon kaikissa elinkaaren vaiheissa: vaatimusanalyysi: riittävän täsmälliset suorituskykyvaatimukset erityisesti aika-/tilakriittiset järjestelmät arkkitehtuurisuunnittelu: epäonnistunut ratkaisu erityisesti tietorakenteiden ja tiedostojen käytön osalta voi tuhota suorituskyvyn etsittävä suorituskyvyn kannalta kriittiset osat välitettävä vaatimukset moduulisuunnittelulle käytettävä tarvittessa suorituskykymalleja esim. jonoverkot Harri Laine 7

8 moduulisuunnittelu: Suorituskyky algoritmin valinta: aikavaativuus tietorakenteiden suunnittelu: tilan tarve + algoritmien valintamahdollisuudet erityisesti aika-/tilakriittisissä tapauksissa on dokumenttiin sisällytettävä valittujen ratkaisujen aika- / tila- analyysi tila/aika kaupankäynti koodaus & testaus: suorituskykyajattelu - pitää tietää valintojen suorituskykyvaikutukset vain rajoitetut mahdollisuudet virittää suorituskykyä keskityttävä järjestelmän pullonkauloihin säilytettävä järjestelmän ylläpidettävyys Siirrettävyys Ohjelma elää usein kauemmin kuin laitteisto Ohjelmatuotteen markkinointi: tuote on voitava siirtää kohtuukustannuksin Korkean tason ohjelmointikieli: välttämätön, muttei riittävä ehto siirrettävyydelle Siirrettävyyttä voidaan edistää välttämällä epästandardeja piirteitä eristämällä riippuvuudet (portability interface) Harri Laine 8

9 Siirrettävyys Laitteistoarkkitehtuurista riippuvia osia: sananpituus arvojen esitystapa merkkikoodit Käyttöjärjestelmästä riippuvia osia: aliohjelmakirjastot tiedostojärjestelmä pääte (tiedosto vai laite) ohjelmistorakenne rakenneosien suhteellinen tehokkuus Siirrettävyystarve on syytä arvioida etukäteen vaatimusanalyysivaiheessa Suunnitteluvaiheen työskentely Lähtökohtana vaatimusvaiheessa tuotettu esitys järjestelmältä edellytettävistä ominaisuuksista: kaaviot (tietovuo-, tilasiirtymä-, tietorakenne-,...) toimintoluettelot ja -kuvaukset tietosanasto arkennetaan esitystä asteittain käyttäen valittua kuvaustapaa. Pidetään yllä tietosanastoa: jokainen uusi termi sanastoon johdonmukaiset merkintätavat Harri Laine 9

10 Suunnitteluvaiheen työskentely Loppuun asti tarkennetun toimintoja kuvaavan kaavion perusteella muodostetaan ohjelmiston rakennekaavio. Moduulisuunnittelun alkaessa kokonaisuus jakautuu: sitä ennen sovittava työnjako (kuka tekee minkin moduulin suunnitelmat) moduulikuvauksissa käytettävät standardit yönjako: projektipäällikkö: tietää vähän kaikesta ryhmän jäsen: tietää paljon osasta kokoukset: koordinointitilaisuuksia vastuualueet kirjataan (myös dokumenttiin) Suunnitteludokumentti Suunnitteludokumentti on toteutuksen (koodauksen) perusta testisuunnitelmien teon perusta manuaalin tarkennus Asteittainen suunnittelu dokumentti syntyy asteittain tarkentaen: Harri Laine 10

11 Suunnitteludokumentti 1. Arkkitehtuurisuunnittelun aikana tuotetaan dokumentin yleisrakenne järjestelmän rakenteen kuvaus (moduulijako) moduulien välisten liittymien kuvaus yhteisten tietorakenteiden kuvaus moduulien yleiskuvaukset järjestelmätestauksen suunnitelma 2. Moduulisuunnittelun aikana täydennetään moduulikuvauksia: algoritmit paikalliset tietorakenteet testaussuunnitelmaa Suunnitteludokumentti Suunnitteludokumentti kirjoitetaan toteuttajaa ja ylläpitäjää varten: täsmällisyys terminologia hakemistot, ristiinviittaukset ym kytkennät Harri Laine 11

12 Suunnitteludokumentin rakenne 1. Johdanto 1.1 uotteen tausta ja tarkoitus 1.2 Mahdollinen erikoissanasto käytetyt lyhenteet 1.3. Yleiskatsaus dokumenttiin 2.Järjestelmän yleiskuvaus 2.1. Sovellusalue 2.2. Koko järjestelmä ja ohjelmiston rooli siinä 3. Vaatimusmäärittely ja siihen tehdyt muutokset viite vaatimusdokumenttiin luettelo projektin aikana muuttuneista dokumentin luvuista 3.1. Rajaukset 3.2. äydennykset Suunnitteludokumentin rakenne 4. Arkkitehtuurin kuvaus 4.1. Ratkaisun "filosofia" ja ohjelmiston toimintaperiaate 4.2. Moduulit ja niiden väliset suhteet 4.3. ietokanta-arkkitehtuuri 4.4. Moduulikuvaukset (esim. UML-menetelmällä) Moduuli Yleiskuvaus ietorakenteet (attribuutit) oiminnot (operaatiot) Erityiset tekniset suunnitteluratkaisut» olioperustaiset suunnittelumallit Virhetilanteiden käsittely Ratkaisuvaihtoehtoja (miksi hylättiin?) Ratkaisun rajoitukset x. Moduuli 2 - Moduuli x Harri Laine 12

13 Suunnitteludokumentin rakenne 5. Käyttöliittymä (ellei ole jo vaatimusdokumentissa kuvattuna) mahdollisen prototyypin kuvaus kuvaus tyypillisistä käyttöskenaarioista kuvia hahmotellusta käyttöliittymästä (prototyypistä saatuina tai piirrettyinä) 6. Rajoitteet toteutukselle 6.1. Noudatettavat standardit 6.2. Ohjelmointikielet, käyttöjärjestelmät, 6.3. Muut tarvittavat apuohjelmat 6.4. Arvio toteutuksen koosta (esim. koodirivien määrä) 6.5. Ohjelmointityyli (nimeämiskäytännöt, kommentointi, rajapinnat,...) Suunnitteludokumentin rakenne Lähdeluettelo Liitteet (esim.) kaavioissa käytettyjen symbolien kuvaus ohjelmiston sisäisten (komento)kielten syntaksi esimerkkejä ohjelmiston sisäisistä tietorakenteista Harri Laine 13

14 Suunnittelumenetelmät Kaikkien menetelmien päämääränä on kokonaisuuden jäsentäminen (decomposition); jäsennysperusteena voi olla toiminnot tiedon rakenne oliot (tieto-objektit) Kaikki menetelmät sisältävät menettelyohjeet seuraavien tehtävien ratkaisemiseksi: miten tietotarpeiden kuvaus muokataan ohjelmistosuunnitelmaksi miten toimintokomponentit ja niiden väliset liittymät esitetään miten tehtyjä suunnitelmia tarkennetaan ja ositetaan miten valvotaan suunniteltavan ohjelmatuotteen (ja suunnitteluprosessin) laatua Suunnittelumenetelmät Suunnittelumenetelmän valintaan vaikuttaa usein vaatimusanalyysissa käytetty menetelmä: mikä on sovelluksen keskeinen ongelmakenttä? millainen on luonnollinen tapa lähestyä tehtävää? Harri Laine 14

15 oimintopohjaiset menetelmät Lähtökohtana toimintopohjainen vaatimusanalyysi: tietovuokaaviot toimintojen hierarkkinen jäsentäminen Suunnitteluvaiheessa jäsennetään ratkaisu samalta pohjalta strukturoitu suunnittelu ylhäältä alaspäin (top-down) (Constantine, Yourdon, Myers) oimintopohjaiset menetelmät Suunnittelun välineitä: arkkitehtuurisuunnittelu: tietovuokaaviot rakennekaaviot tila-automaatit (erityisesti tosiaikaiset järjestelmät) tietorakenteiden suunnittelu: tietosanasto moduulisuunnittelu: Nassi-Shneiderman-kartat päätöstaulut pseudokieli Harri Laine 15

16 oimintopohjaiset menetelmät Ohjelmiston rakenteen muodostaminen vaatimusmäärittelyn perusteella? tarkennetaan tietovuokaaviota, kunnes kaikki kaavion solmut perustoimintoja kukin tietovuokaavion solmu tulee vastaamaan rakennekaavion ensimmäisen version moduulia rakennekaaviota parannetaan: kiinteys, kytkentä, moduulien itsenäisyys,... oimintopohjaiset menetelmät oiminnan luonne - kaksi päätyyppiä: muunnosjärjestelmä (transform flow): tieto muunnetaan syöttötiedosta tulostiedoksi osat : syöttötietojen käsittely, muunnos ja tulosteiden muodostus Harri Laine 16

17 oimintopohjaiset menetelmät tapahtumankäsittelyjärjestelmä (transaction flow): tiedon käsittelyn ydin on tapahtumakeskus, josta käsittely jakautuu moneksi erilliseksi toimintopoluksi osat: syöttötietojen vastaanotto, tapahtumakeskus ja joukko toimintopolkuja Muunnos tietovuokaaviosta ohjelmarakenteeksi Erotetaan vuokaavion pääosat: syöttö - muunnoskeskus - toiminta/tulos Muodostetaan näistä pääosista ylimmän tason rakennekaavio: muunnosjärjestelmä: rakennekaavion juureksi valvontasolmu, sen kolmeksi alipuuksi: syöttö, muunnos ja tulostus tapahtumankäsittelyjärjestelmä: rakennekaavion juureksi tapahtumakeskus, sen toiseksi alipuuksi syötteidenvastaanotto ja toiseksi alipuuksi valvontasolmu, jonka alipuina ovat toimenpidepolut arkennetaan kutakin alipuuta,kunnes kaikki vuokaavion solmut on sijoitettu Harri Laine 17

18 Muunnos tietovuokaaviosta ohjelmarakenteeksi valvonta syöttö muunnos tulostus Muunnos tietovuokaaviosta ohjelmarakenteeksi 1 2 tapahtumakeskus syöttö valvonta toim 1 toim 2 Harri Laine 18