Toteutussuunnitelma. Luennon tavoitteista. Motivointia. Pressman, Software Engineering

Transkriptio

1 Toteutussuunnitelma Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Pressman, Software Engineering 1

2 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: 2

3 Sisällöstä Tavoitekalvon asioita. 3

4 Motivointia 4

5 Toteutussuunnitelma ja projektin vaiheet Määrittelyiden ja vaatimusten keruun jälkeen osa (tärkeimmät) vaatimuksiin liittyvistä toiminnoista toteutetaan (tällä kurssilla, riippuu vaatimusten laajuudesta). 5

6 Käsitteistä Laaditaan suunnitelmia (rakenteita): Datasuunnitelmat (-rakenne), tietorakenteet, tietokanta Arkkitehtuurirakenne, ohjelman rakenteen pääelementit Liittymärakenne, modulien väliset, ulkoiset, hci Toiminnallinen rakenne, käytetään prosessi- ja kontrollimäärittelyitä, tilarakenteita 6

7 Suunnitteluprosessista Laatu: Suunnitelmien tulee toteuttaa kaikki erikseen mainitut vaatimukset ja myös ns. hiljaiset vaatimukset. Koodin kirjoittajien tulee pystyä lukemaan ja ymmärtämään suunnitelmat. Ja myös testaajien ja tulevien ylläpitäjien. Suunnitelmien tulisi antaa ohjelmistosta kokonaiskuva: datasta, toiminnallisuudesta ja käyttäytymisestä. 7

8 Teknisiä kriteerejä laadulle: Suunnitelmien pitäisi antaa ohjelmistolle hierarkkinen rakenne, joka näppärästi kontrolloi ohjelmiston elementtejä. Suunnitelmien tulisi olla modulaarisia: toimintojen loogista jaottelua. Suunnitelmien tulisi abstrahoida data- ja toiminnallisuusrakenteita. Suunnitelmien tulisi johtaa aliohjelmiin ja funktioihin, joilla on riippumattomia piirteitä. Suunnitelmien tulisi johtaa liittymiin, jotka vähentävät modulien välisten ja myös ulkoisen ympäristön yhteyksien kompleksisuutta Suunnitelmat tulisi johtaa toistettavalla prosessilla, joka perustuu vaatimusten tarkkaan analysointiin. 8

9 Eri suunnittelumenetelmien yhteisiä piirteitä: mekanismi, joka siirtää analyysimallin toteutussuunnitelmaksi notaatio, jolla kuvataan toiminnalliset osaset ja niiden väliset yhteydet heuristiikat asioiden tarkentamiseen ja osittamiseen ohjeet laadun varmistamiseen 9

10 Suunnitteluperiaatteet Ensin kuva kokonaisuudesta, jota tarkennetaan. Pitäisi harkita vaihtoehtoja. Suunnitelmien tulee olla jäljitettävissä analysointimalliin (vaatimuksiin). Älä keksi pyörää uudelleen (muista suunnittelumallit). Ohjelmiston tulisi jäljitellä todellisuudessa esiintyvän ongelman rakennetta. Ohjelmiston tulisi olla yhdenmukaisia ja integroituja ( yksi kehittäjä, hyvät liittymät ) 10

11 Ohjelmisto tulisi suunnitella muutostarpeet huomioiden. Ohjelmiston tulisi käyttäytyä hyvin myös poikkeuksellisissa tilanteissa. Suunnittelu ei ole koodausta, koodaus ei ole suunnittelua. Suunnitelmien laatua tulisi arvioida niitä luodessa, ei jälkikäteen. Suunnitelmat tulee katselmoida (virheiden vähentämiseksi). 11

12 Suunnitteluun liittyviä käsitteitä Millä kriteereillä ohjelmisto jaetaan yksittäisiin komponentteihin? Kuinka toiminnot ja tietorakenteet erotetaan ohjelmiston käsitteellisestä esityksestä? Löytyykö yhdenmukaisia laatukriteerejä suunnitelmille (ohjelmiston rakenteelle)? 12

13 Abstrahointi Tarkentaminen (abstraktioista yksityiskohtiin) Modularisuus Ohjelmistoarkkitehtuuri Kontrollihierarkia Rakenteellinen ositus Tietorakenteet Ohjelmiston toiminnot Informaation piilotus 13

14 Abstrahointi: Löytyy eri tasoja. Korkeammalla tasolla ei näytetä detaljeja. Toimintojen ja tietojen (datan) abstraktiot. Abstraktit tietotyypit. Kontrollien abstraktiot. 14

15 Modularisuus: Kirjastoja, moduleja järkevän kokoisissa palasissa. Joskus dialogit voivat olla omia ohjelmiaan... Ei kannata liioitella modulien määrässä... Modulaarinen ositettavuus Ositettavuus uudelleenkäyttäen Modulaarinen ymmärrettävyys (vähän viittauksia muihin) Modulaarinen jatkuvuus (muutokset usein paikallisia) Modulaarinen suojaus (virheet eivät vaikuta muihin) 15

16 Ohjelmistoarkkitehtuuri: Rakenteelliset ominaisuudet (mitä sisältää, liittymät muihin) Toiminnalliset ominaisuudet (tehot, kapat, luot. ym.) Vastaavien systeemien perheet Rakenteelliset mallit, sovelluskehykset, dynaamiset mallit, prosessimallit, toiminnalliset mallit. Arkkitehtuurin kuvauskielet (ADL). 16

17 Kontrollihierarkia: Kutsutaan myös ohjelman rakenteeksi. Mikä moduli kontrolloi mitäkin? Näkyvyys, liittyvyys (kytkeytyneisyys) Rakenteellinen ositus: Horisontaalinen, funktion pääositus (yks.kert: syöte, muunnos, tulos). Vertikaalinen ositus, jaetaan tehtäviä alimoduleihin (pääosituksen olisi syytä olla kunnossa muutokset voivat olla hankalia). 17

18 Tietorakenteet: Joukko tuttuja rakenteita suunnittelun apuna: vektorit, taulukot, listat, pinot, jonot, kasat, erilaiset puut, verkot, joukot, kuvaukset (avain-arvo-parit), jne. Yllä oleviin rakenteisiin pistetään dataa sisään ja löytyy tapoja käsitellä rakenteissa olevaa dataa näppärästi. Useassa kielessä löytyy jo peruskirjastoista melkoinen määrä erilaisia tietorakenteita. Ohjelmiston toiminnot: Kuvataan pseudokielellä tai jollain kaaviotekniikalla esim. Löytyy tasoja, liittävät tietorakenteet toiminnallisuuteen, tapahtumiin, toistoihin, jne, kuvataan, missä tehdään päätöksiä jne. Informaation piilotus: Tehdään mahdollisimman itsenäisiä moduleja (komponentteja), joilla on selvät liittymät modulien väliseen (ulkopuoliseen) kommunikointiin. 18

19 Modulaarisen rakenteen suunnittelusta Toiminnallinen riippumattomuus. Mitataan seuraavilla: Yhteenkuuluvuus (cohesion). Moduli hoitaa yksittäisen tehtävän ja tarvitsee vähän kommunikointia muiden modulien kanssa. Jos moduli hoitaa useita tehtäviä, jotka eivät (juurikaan) liity toisiinsa, on kyseessä satunnaisesti yhteenkuuluva moduli. On myös loogisesti yhteenkuuluvia ja ajallisesti yhteenkuuluvia moduleja. Kytkennät (coupling). Modulien välisiä. Riippuu modulin liittymän mutkikkuudesta. liittämän paikasta ja siitä, mitä dataa liittymä välittää. data kytkennät, leima??kytkennät (stamp-) (tietorak.), kontrollikytkennät (esim. kontrollilippu), yhteiskytkennät (esim. glob. tietorak), sisällyskytkennät (käyttää toisen modulin tietorak). 19

20 Suunnitteluheuristiikat tehokkaaseen modulaarisuuteen Arvioi ohjelmarakenteen ensimmäinen iteraatio kytkentöjen vähtämiseksi ja yhteenkuuluvuuden lisäämiseksi. (Moduleja voi jakaa suoraan useaksi, tai useasta voi yhdistää toimintoja johonkin uuteen moduliin.) Yritä välttää rakennetta, jossa yhdellä modulilla on monta kontrolloitavaa modulia. Syvyyden kasvaessa joillain modulilla saisi olla useita moduleja, jotka sitä kontrolloivat. Modulin vaikutusalueen tulisi olla modulin kontrollialueen sisällä. (Kontrolloi alimodulejansa, ja vaikutusten tulisi jäädä niihin.) 20

21 Arvioi modulin liittymiä mutkikkuuden ja päällekkäisyyksien vähentämiseksi ja johdonmukaisuuden lisäämiseksi. Määritä moduleja, joiden toiminnallisuus on selkeää ( ennustettavaa vs. sisäinen muisti), mutta vältä moduleja jotka ovat liian rajoittavia (voi tulla muutostarpeita). Lisää kontrolloituja liittymiä, vältä patologisia kytkentöjä ( jonnekin modulin keskelle ). Paketoi ohjelmisto suunnittelurajoitteiden ja siirrettävyysvaatimusten perusteella. 21

22 Suunnittelumenetelmiä Neljä perustoimintoa: datasuunnitelmat, arkkitehtuurisuunnitelmat, UI-suunnitelmat, toiminnallisuuden suunnittelu. datasuunnitelmat (-rakenne) arkkitehtuurisuunnitelmat ja -suunnitteluprosessi Muunnosten ja transaktioiden kuvaukset Jälkiprosessoinnin suunnittelu Arkkitehtuurin optimointi Liittymien suunnittelu, HCI-suunnittelu ja liittymien suunnitteluohjeita Toiminnallisuuden suunnittelu 22

23 Datasuunnitelmat Systemaattinen ote myös datan suhteen Kaikki tietorakenteet ja niillä suoritettavat operaatiot etsittävä. Tietohakemisto perustettava ja määriteltävä datalle ja ohjelman rakenteelle (suunnitelmille). Päätökset alhaisen tason data suunnitelmista pitäisi viivyttää suunnittelun loppuvaiheille. Tietorakenteiden tulisi näkyä suoraan vain niille moduleille, jotka sitä tarvitsevat. Kehitä kirjastoja (tietorakenteille ja niiden operaatioille). Ohjelmiston rakenteen ja ohjelmointikielen tulisi tukea määrittelyjä ja abstraktien tietotyyppien esittelyä varten. 23

24 Arkkitehtuurisuunnitelmat Talon ovet ja ikkunat? (vs. joku muu näkymä.) Arkkitehtuurin suunnitteluprosessi informaation virta ensin (tietovirtakaavio). virran reunamat. Tietovirtakaavio kuvataan ohjelmarakenteeksi. Kontrollihierarkia määritetään jakamalla tekijöihin. Saatua rakennetta hienonnetaan... (oma kurssi näistä, ks. Pressman.) 24

25 Muunnosten kuvaukset Katselmoi systeemimalli Katselmoi ja hienonna tietovirtakaavioita Tarkista, onko kaaviossa muunnos- vai transaktiopiirteitä (määritelmät, ks. Pressman). Eristä muunnoksen keskus määrittämällä tulevien ja lähtevien virtojen rajat. Tee ensimmäisen asteen tekijöihin jakoa. (ja sen jälkeen toisen... ) Hienonna 1. iter. ohj. rakennetta suunnitteluheuristiikkojen perusteella laadun parantamiseksi. 25

26 Transaktioiden kuvaukset Kolme ensimmäistä samanlaisia kuin ed. kalvossa. Etsitään transaktiokeskus ja virran piirteet (ks. Pressman) Kuvataan kaavio transaktio prosessointia varten. Jaetaan tekijöihinja kuvataan transaktioiden rakenne. Hienonnetaan 1. iter

27 Jälkiprosessoinnin suunnittelu Tarvitaan arkkitehtuurisuunnitelmien osana: prosessointikuvaus kullekin modulille liittymien kuvaukset myös paikalliset ja globaalit tietorakenteet määriteltävä kaikki suunnittelurajoitteet tulee huomioida suunnitelmien katselmointi harkitaan arkkitehtuurisuunnitelmien optimointia (jos tarvetta) 27

28 Arkkitehtuurisuunnitelmien optimointi Kehitä ja hienonna ohjelman rakennetta miettimättä tehokkuusoptimointeja. Käytä työkaluja tehottomien kohtien löytämiseen. Myöhemmissä iteraatioissa, hitaaksi epäiltyjen modulien kohdalla kehitä algoritmeja toiminnan parantamiseksi. Koodaa työhön sopivalla ohjelmointikielellä. Jos tarvetta, uudelleensuunnittele ja koodaa konekielellä tehokkuuden parantamiseksi. 28

29 Liittymien suunnittelu ohjelmamodulien välisiä (modulien datatarpeet määräävät pitkälle) ohjelman ja laitteiden (tai muiden ei-ihmisten) välisiä tietokoneen ja ihmisen välisiä 29

30 HCI -suunnittelusta (myös tästä on omia kurssejansa laitoksella) Suunnittelumalli (tulee ohjelmistosuunnittelijalta). Käyttäjämalli (saattaa tulla myös ohjelmistosuunnittelijalta, mutta myös muualta). Käyttäjäkategorioita aloittelija tiedostava, satunnaiskäyttäjä tiedostava, säännöllinen käyttäjä 30

31 Tehtävien analysointia ja mallinnusta Määritä tehtävän tavoitteet ja tarkoitukset Kuvaa ne tiettyjen toimenpiteiden sarjaksi Kuinka tuo sarja suoritetaan käyttöliittymässä? Mikä on systeemin tila? (miltä UI näyttää sarjan jälkeen?) Määritä kontrollointimekanismit, laitteet ja toiminnot jotka voivat muuttaa systeemin tilaa. Esitä, kuinka kontrollimekanismit muuttavat systeemin tilaa. Osoita, kuinka käyttäjä tulkitsee systeemin tilan UI:sta saamastaan informaatiosta. 31

32 Lisää... Vasteajoista Helpeistä (avusteista) Virheilmoituksista Menuista Makroista... UI-suunnittelutyökaluista Suunnitelmien arvioimisesta ja tarkastamisesta (ks. Pressman) 32

33 Liittymien suunnitteluohjeita Yleisohjeita: Johdonmukaisuus Tarkoituksenmukaista palautetta Varmista kaikki ei-triviaalit tuhoamisoperaatiot Salli useimpien toimien helppo peruutus Vähennä inf. määrää, mitä tarv. muistaa eri toimintojen välillä Etsi tehokkuutta dialogeissa, liikkeissä ja ajatuksissa Virhesietoisuus Luokittele aktiviteetit ja suunnittele näyttö sen mukaan Avusteet ympäristötietoisia yks.kert. verbejä tai lyhyitä -fraaseja komentojen nimeämiseen. 33

34 Infonäytöt: Näytä vain oleellista tietoa Älä hautaa datalla, käytä havainnollisia datan esitysmuotoja Johdonmukaiset otsakkeet, standardilyhenteet ja tutut värit Visuaalisen ympäristön ylläpidon salliminen (ks. taas) Käyttökelpoiset virheilmoitukset Isot, pienet kirjat, sisennykset, tekstin ryhmittely (ymmärtämisen tueksi) Analogisia kuvia hyväksi, kun ne helpottavat ymmärrystä Käytä saatavilla olevaa näytön aluetta (tehokkaasti, erit. jos useita ikkunoita) 34

35 Syöttöikkunat: Minimoi käyttäjältä vaadittavat syöttötoimenpiteet Säilytä infonäyttöjen ja syöttöikkunoiden johdonmukaisuus Salli käyttäjän kustomoida syöttötapoja Vuorovaikutuksen tulisi olla joustavaa mutta myös viritetty käyttäjälle mieluisaan moodiin. Deaktivoi komennot, jotka sopimattomia nykyisessä ympäristössä Anna käyttäjän kontrolloida vuorovaikutusta Avusteet Mikki Hiiri -syötteet pois... 35

36 Toiminnallisuuden suunnittelu Rakenteellinen ohjelmointi. Erilaisia notaatioita, graafisia (vuokaaviot ja laatikkomallit) ja PDL eli pseudokoodi. 36

37 Olioperustaisista suunnittelumenetelmistä Olioajattelun tulisi näkyä myös muissa vaiheissa: OORA, oo req.a. OOD, oo design OODA, oo dom.a. Vaatii usein evolutionaarisen vaihejakomallin käyttöä. (Kaikkia tarvittavia luokkia harvoin löytää heti alussa.) (Ks. Pressman) 37

38 Asiakas-palvelin -ohjelmistojen suunnittelusta 38

39 Reaaliaikasysteemien suunnittelusta 39