Ohjelmiston suunnittelu

Transkriptio

1 Ohjelmiston suunnittelu Sunnittelu: asiakaslähtöisten vaatimusten muuntaminen teknisiä mahdollisuuksia tehokkaasti hyödyntäväksi ratkaisuksi luova prosessi Pääkohteet: ohjelmiston yleisrakenne ja toimintaperiaatteet tietorakenteet algoritmit, toiminnot käyttöliittymä Ohjelmiston suunnittelu - vaiheet Suunnittelun tuloksena on malli tai muu esitys järjestelmästä, joka aiotaan tehdä. Kaksi hallinnollista kokonaisuutta: yleis- ja yksityiskohtainen suunnittelu yleissuunnittelu (product design / system design / preliminary design) järjestelmän kokonaisrakenne yhteiset tietorakenteet jako alijärjestelmiin -> moduuleihin osajärjestelmien ja moduulien välinen kommunikointi Harri Laine 1

2 Ohjelmiston suunnittelu - vaiheet yksityiskohtainen suunnittelu (detailed design / program design / module design) kunkin moduulin sisäinen rakenne algoritmit kunkin moduulin sisäiset tietorakenteet Suunnitteludokumentti syntyy usein vastaavasti kahdessa vaiheessa: yleissuunnitelma moduulisuunnitelmat Ohjelmiston suunnittelu - vaiheet yleissuunnittelu yksityiskohtainen Tietorakenteet Rakenteet Toiminta Liittymät Harri Laine 2

3 Ohjelmiston suunnitteluprosessi lähtökohtana vaatimusdokumentti, joka kertoo mitä ominaisuuksia järjestelmällä on oltava miltä järjestelmä näyttää käyttäjän kannalta järjestelmän saamat syötteet järjestelmän tuottamat tulosteet ei-toiminnalliset vaatimukset päämääränä suunnitteludokumentti, joka kertoo miten halutut toiminnot toteutetaan missä muodossa tietoja säilytetään missä muodossa tietoja välitetään miten tietoa muunnetaan Ohjelmiston suunnitteluprosessi suunnitteluvaiheen tulee tuottaa toteutusvaiheelle ohjeet, joiden perusteella järjestelmä on helppo toteuttaa ylläpitää validoida ymmärtää suunnittelu on luova, iteratiivinen prosessi: ei ainoata oikeata suunnitelmaa ei ainoata parasta suunnitelmaa on kuitenkin parempia ja huonompia suunnitelmia Harri Laine 3

4 Ohjelmiston suunnittelu - osatehtäviä arkkitehtuurin suunnittelu jako komponentteihin, yhteydet komponenttien välillä liittymien suunnittelu (myös käyttöliittymä) komponenttisuunnittelu komponentit jaetaan pienempiin komponentteihin tietorakenteen suunnittelu algoritmisuunnittelu Ohjelmiston arkkitehtuurin suunnittelu M.Shaw, D.Garlan: Software Architecture - Perspectives on an emerging discipline, Prentice-Hall, Ohjelmisto muodostuu komponenteista, tehtävänä on löytää käyttökelpoiset mieluusti yleiskäyttöiset komponentit ja niiden vuorovaikutus osasysteemit erillisiä toimintokokonaisuuksia voivat olla yhteydessä toisiinsa prosessit sijoittelu laitteille ajoitus yhtenäinen toimintojakso moduulit Harri Laine 4

5 Ohjelmiston arkkitehtuurin suunnittelu Jakamisella saavutetaan: toiminnallinen itsenäisyys helpompi tehdä, testata ja ylläpitää työnjako ohjelmistoprojektissa järjestelmän toiminnassa käsiteltävyys sopiva tarkkuustaso sopiva laajuus Ohjelmiston arkkitehtuurin suunnittelu Jaon seurauksena kuvattavaa: kutsurakenne, muu yhteistyö käännösyksikkörakenne liittymät Jakamisessa ei ole yksikäsitteistä "parasta" ratkaisua Jako perustuu johonkin näkökulmaan, jonka mukaan tietyt palvelut ja tiedot kuuluvat samaan kokonaisuuteen. Harri Laine 5

6 Ohjelmiston arkkitehtuurin suunnittelu jakoperustana voi olla: käyttäjä, toiminto / tehtävä, laitteisto, toimipiste, toiminnan kohde jne. jako on yleensä monitasoinen, näkökulma voi vaihdella tasoittain ja olla eri osajärjestelmissä erilainen Arkkitehtuurimalleja Komponenttien välinen vuorovaikutus muodostaa arkkitehtuurin perustan. putket ja suodattimet -malli tietovuolähestymistapa suodattimet toisistaan riippumattomia tiedonmuokkaajia suodattimen osattava tulkita saapuvaa tietovirtaa (jaettu käsitys rakenteesta) suodattimen ei tarvitse tietää keneltä tieto tulee tai minne se menee rinnakkaisuutta tai peräkkäisyyttä esim. unix-putket Harri Laine 6

7 Arkkitehtuurimalleja oliot ja palvelut malli olio tarjoaa palveluja palvelun pyytäjän tunnettava tarjoaja ja palvelurajapinta (kutsu- tai viestirakenne) tarjoajien ei tarvitse tuntea pyytäjiä (asiakkaita) tieto kätketty olion sisään Arkkitehtuurimalleja tapahtumapohjainen, epäsuoran käsittelyn malli palveluja ei kutsuta suoraan komponentti voi tuottaa tapahtumia (event), joihin toiset komponentit reagoivat tapahtumaan voi reagoida yksi tai useampi komponentti reagoija voi rekisteröityä vastaanottamaan tapahtumia tai tapahtumat hoidetaan yleislähetyksenä ja sille herkistynyt reagoi tapahtuman aiheuttajan ei tarvitse tietää reagoijia, ei välttämättä edes reagoiko joku esim. windows -tapahtumat, tietokantatriggerit Harri Laine 7

8 Arkkitehtuurimalleja kerrosarkkitehtuuri kukin kerros tarjoaa palveluja seuraavaksi ylemmän tason kerrokselle palvelujen abstraktiotaso kasvaa kerros kerrokselta esim. tietoliikenneprotokollat tason 3 palvelut tason 2 palvelut tason 1 palvelut Arkkitehtuurimalleja jaettuun tietovaraston arkkitehtuuri jaettu tietovarasto erilliset tietovarastoa hyödyntävät komponentit kontorolli ohjelmakomponenteissa (perinteinen tietokanta, työkalu, vaihe) aktiivinen tietovarasto (blackboard) - tietovaraston tila ohjaa ohjelmakomponentteja Harri Laine 8

9 Arkkitehtuurimalleja tulkkiarkkitehtuuri virtuaalikone ohjauskieli, jota tulkitaan tila ja tilan esitys rinnakkaiset prosessit prosessien välinen kommunikointi pää-/aliohjelma pääohjelmassa kontrollisilmukka aliohjelmissa erikoispalvelut Arkkitehtuurimalleja tilakonearkkitehtuuri tapahtumiin reagoiva tila-automaatti sovellusaluekohtaiset arkkitehtuurimallit - kehykset Kommunikoinnin toteutustapa on arkkitehtuuritason ratkaisu: aliohjelmakutsu viestinvälitys yhteiset tiedostot tai muistialueet Harri Laine 9

10 Suunnittelu - ositus Suunnittelun ositusperiaatteet kerrostus (layering) pilkkominen (partitioning) Kerrostuksen perustana abstraktiotasot: toiminta-abstraktiot abstrakti kone -ajattelu ylemmän kerroksen palvelut tuotetaan alemman kerroksen palveluiden avulla (vrt. tietoliikenne OSI-malli) kerrokset perustuvat eri käsiteistöihin siirrettävyys saadaan aikaan kirjoittamalla jonkin kerroksen koodi uudelleen Suunnittelu - ositus suljetussa kerrosarkkitehtuurissa vain edellisen tason palvelut ovat käytettävissä parempi ylläpidettävyys avoimessa kerrosarkkitehtuurissa kaikkien alempien tasojen palvelut ovat käytettävissä huonompi ylläpidettävyys parempi joustavuus esimerkki kerrostuksesta: käyttöliittymäkerros looginen toiminta - kerros Harri Laine 10

11 Suunnittelu - ositus tieto-abstraktiot tietokantojen peruskäsitteitä näkymät - looginen taso - fyysinen taso abstraktit tietotyypit - oliot Pilkkominen = toiminnallinen osiinjako ilmenee puhtaimmillaan top-down suunnittelussa Asteittain tarkentuva suunnittelu 1. Selvitä ongelman olennaiset osat. vaatimusanalyysi älä lykkää epäselvien kohtien tutkimista 2. Hahmota ainakin yksi mahdollinen ratkaisu. mielellään useita ratkaisuja simuloi keskeiset tilanteet valitse yksinkertaisin ratkaisu, ellei ole erityisiä syitä valita toisin 3. Kuvaa järjestelmä hierarkkisesti tarkentaen. ylhäältä alaspäin kuvausmenetelmä sovelluksen mukaan Harri Laine 11

12 Asteittain tarkentuva suunnittelu 4. Muodosta vastaava rakennekaavio. 5. Kuvaa kunkin tarkennustason oliot. sekä toiminnot että tiedot Tiukka top down -suunnittelu ei aina ole järkevää: aiemman tietämyksen soveltaminen keskittyminen erityisen ongelmallisiin kohtiin Asteittain voi tarkentaa sekä toimintaa että tietoa Esimerkki / toiminta juopottele mene viinakauppaan osta kossu mene porttikongiin juo sammu korkkaa ota 1. ryyppy irvistele loput laula särje pullo Harri Laine 12

13 Esimerkki / tieto sakkolappu nimi osoite henkilötunnus raha katuosoite postiosoite eurot sentit jako/tarkennushierarkia valokopiokone alustus kopiointi erikoistilanteet virheet... ilmoitukset paperi loppu tukos... Harri Laine 13

14 ohjelmarakenteita spagettikoodi ohjelma tietorak. ohjelmarakenteita spagettikoodi optimointikikkoja ei datan ja koodinrakennetta primitiiviset ohjelmointikielet Harri Laine 14

15 ohjelmarakenteita strukturoitu ohjelmarakenteita strukturoitu asteittain tarkennettu tieto ja toiminta rakenteinen ohjelmointi rakenteiset ohjelmointikielet Harri Laine 15

16 ohjelmarakenteita oliokeskeinen ohjelmarakenteita oliokeskeinen modulaarisuus abstraktit tietotyypit datan ja koodin pakkamminen tiedon piilottaminen, rajapinnat olio-ohjelmointikielet raviolikoodi? Harri Laine 16

17 eri kriteerejä ominaisuuksia joihin on syytä kiinnittää huomiota: modulaarisuus kiinteys (cohesion) kytkentä (coupling) tiedon kätkeminen (information hiding) ylläpidettävyys (maintainability) Modulaarisuus Ohjelmisto on jaettu erillisiin nimettyihin (usein erikseen käännettäviin) osiin - moduuleihin tietorakenteita yleensä yksityisiä, käyttö operaatioiden kautta voi tarjota myös jaetun tietorakenteen operaatioita julkisia tai yksityisiä liittymä julkiset operaatiot, joita muut moduulit voivat kutsua Harri Laine 17

18 Modulaarisuus moduulin koko Effort(p+q) > Effort(p) + Effort(q) Moduulien määrän kasvaessa liittymien toteutuskustannukset kasvavat, joten jatkuva pilkkominen pienemmiksi moduuleiksi ei poista kaikkia kustannuksia. Suositeltu moduulikoko noin 30 riviä. kerralla hahmotettavissa Kiinteys (cohesion) (toiminnallinen) moduuli on kiinteä, jos sen kaikki osat palvelevat yhtä ainoaa osatehtävää, ts. moduuli toteuttaa yhden selkeän tehtäväkokonaisuuden moduuli ei ole kiinteä,jos se sisältää heikosti toisiinsa liittyviä osia kiinteys parantaa moduulin ylläpidettävyyttä ja lisää mahdollisuuksia uuskäyttöön Harri Laine 18

19 kiinteyden asteet huonosta hyvään: moduulissa satunnaisesti yhdistettyjä osia moduuliin koottu loogisesti samantyyppisiä tehtäviä (esim. tulostukset) moduuliin koottu samaan aikaan tarvittavia osia moduuliin on koottu kontrollin etenemisjärjestyksessä peräkkäisiä osia moduulin koottu yhteisiä tietorakenteita käyttäviä oliot operaatioita moduulin osat muokkaavat toistensa tuloksia toisen tuote on toisen syöte toimintakokonaisuuteen perustuva yhdistäminen jokainen osa tarpeen moduulin vastuulla olevan toimintakokonaisuuden kannalta Kytkentä (coupling) kuvaa vuorovaikutuksia eri moduulien välillä löyhästi kytkettyjä moduuleja on helpompi ylläpitää, koska muutokset eivät vaikuta muihin moduuleihin kiinteästi kytketyillä voimakkaita riippuvuuksia Harri Laine 19

20 Kytkentä heikosta vahvaan: ei vuorovaikutusta moduulien välillä käsiteltävän tiedon välittäminen yksittäisinä parametreina käsiteltävän tiedon välittäminen rakenteisina parametreina ohjaustiedon välittäminen parametreina yhteiskäyttöiset ulkoiset laitteet yhteiskäyttöinen tietorakenne sisäisten rakenteiden hyväksikäyttö Tiedon kätkeminen (information hiding) moduulia ajatellaan mustana laatikkona vain liittymät näkyvät ulospäin: syötteet tulosteet moduulin sisältämien toimintojen määrittely ulos eivät näy: moduulin sisäiset tietorakenteet toimintojen toteutustapa toteutus, testaus ja ylläpito paikallista suojaus tehostuu Harri Laine 20

21 Muita jaossa vaikuttavia asioita jakoa ei kannata jatkaa jos liittymän koodi tulee pidemmäksi kuin toiminnan koodi (paitsi yleiskäyttöisten osalta) yhteiskäyttöisten osien eristäminen moduuleiksi lyhentää koodia ja helpottaa ylläpitoa työ ja päätöksenteko kannattaa erottaa eri moduuleihin, muutokset kohdistuvat yleensä vain jompaan kumpaan tässä yhteydessä on kuitenkin pyrittävä välttämään toimivaltarikkomuksia = tilanteita, joissa päätöksen vaikutusalue menee moduulin valvonta-alueen (=alaiset kutsurakenteessa) ulkopuolelle. kannattaa etsiä yleiskäyttöisiä moduuleita Muita jaossa vaikuttavia asioita liittymien pitäisi olla mahdollisimman yksinkertaisia, ei rakenteista tietoa moduulirakenteeseen syvyyttä leveyden kustannuksella moduulin toiminnan tulee olla ennustettavissa - ts sisäinen tila ei saisi vaikuttaa (Black box) moduuleilla pitäisi olla vain yksi sisäänmeno- ja yksi ulostulokohta Harri Laine 21

22 Moduulihierarkia - Käsitteitä leveys (width): samalla hierarkiatasolla olevien moduuleiden maksimimäärä syvyys (depth): maksi mi pi t uus r ei t i l l e j uur i moduul i st a l eht i moduul i i n si sään haar aut umi nen (f an-i n): moduul i a kut suvi en moduul i en l ukumäär ä ul oshaar aut umi nen (f an-out ): kut sut t avi en moduul ei den l ukumäär ä x f an_o ut (x)=4 l eveys 7 y syvyys 5 f an_i n(y)=3 Harri Laine 22

23 Moduul i hi er ar ki an suunni t t el u Rel aat i o A uses B on voi massa, mi käl i moduul i l l e A määr i t el t y t eht äv ä vaat i i moduul i n B käy t t ämi st ä. Rel aat i on uses t uot t ama r i i ppuvuusver kko on kehät ön => a ver kko muodost aa moduul t aso 2 i en (puumai sen) hi er ar ki an b d t aso 1 Tavoitteena on kehätön verkko Esim: a uses b, c b uses c, a uses c, s uses t aso c 0 j okai nen t aso koost uu moduul i en osaj oukost a, j oka voi daan toteuttaa, suorittaa ja testata t er aso i kseen 0 t aso inkrementaalisesti: 1 t aso 2 t est ausj är j est ys Harri Laine 23

24 Kehäkytkennöistä pitäisi päästä eroon esi m j akamal l a kehäl l i sest i r i i ppuvat m osaan A1 A B B1 kehäk yt kent ä A2 B2 Harri Laine 24