010758000 Ohjelmistotekniikka - Spesifikaatiot ja dokumentointi

1. 010758000 Ohjelmistotekniikka- Spesifikaatiot ja dokumentointi Kevät 2003 Hanna-Kaisa Lammi LTY/Tite Osa materiaalista on peräisin kurssikirjasta Haikala, Märijärvi: Ohjelmistotekniikka, 2000.

2. Sisältö • Speksaamisesta yleisesti • Kuvaustekniikat ja menetelmät • Dokumentointi • Mallintamisesta ja kuvaustekniikoista

3. Motto "Ohjelmistospesifikaation lukeminen on kuin pyhän kirjan lukemista - jos lukee itsekseen voi ymmärtää miten haluaa, jos pyytää jonkun selittämään, ymmärtää miten toinen haluaa, parasta olisi saada jumala (asiakas) paikan päälle selittämään mitä hän tarkoittaa." tekn.yo Jan Laakso projektityökurssilla

4. Spesifikaatio • Määrittely: Mitä tehdään? • Suunnittelu: Miten tehdään? • Määrittelyn ja suunnittelun sisältö vaihtelee tilanteesta riippuen, esim. • työasemasovelluksen määrittely näyttöjä ja toimintoja • sulautettujen järjestelmien ohjelmistot rajapintoja antureihin ja toimilaitteisiin • Määrittely ja suunnittelu (toteutus myös) spesifikaatioiden laatimista • Spesifikaatio määrittelee, miten vaiheen syötteet eli vaatimukset muutetaan seuraavan vaiheen vaatimuksiksi

5. käyttäjien tarpeet, ideat, Menetelmät, rajoitukset kuvaustekniikat reunaehdot mitä esitutkimus verifiointi miten asiakas- hyväksymis- vaatimukset testaus mitä määrittely verifiointi miten toiminnallinen järjestelmä- määrittely testaus mitä arkkitehtuuri- verifiointi suunnittelu miten tekninen integrointi- määrittely testaus mitä moduuli- verifiointi suunnittelu miten moduuli- moduuli- suunnitelmat testaus mitä verifiointi ohjelmointi miten ohjelma- koodi Ohjelmistojen tuottaminen = speksien tuottamista?

6. Speksattavat asiat (pelkistetty kuva) Spesifikaatio N Spesifikaatio N+1 reunaehdot ja reunaehdot ja rajoitteet rajoitteet ei-toiminnalliset ei-toiminnalliset vaatimukset spesifiointi vaatimukset vaatimukset toiminnalliset toiminnalliset vaatimukset vaatimukset testaussuunnitelmat Verifiointi edellisen version spesifikaatiot esimerkiksi tarkastamalla

7. Hyvä speksin ominaisuudet • Sujuva ja selkeä kirjallinen esitys ”Jos kuukauden toteutunut myynti alittaa tavoitteet, tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%.” Selkeää?!

8. Hyvän speksin ominaisuudet • täydellisyys • tarkkuus • virheettömyys • ymmärrettävyys • testattavuus • jäljitettävyys • jokseenkin samat kuin yksittäisen vaatimuksen ominaisuudet!

9. Kuvaustekniikat ja menetelmät • Kuvaustekniikat ovat ”kieliä” erilaisten asioiden ilmaisemiseksi esim. UML-kuvauskieli, käyttötapauskaaviot, luokkakaaviot, tilakaaviot • suunnittelutyön apuvälineitä • työn tulosten dokumentointivälineitä • Menetelmät ovat tapoja soveltaa kuvaustekniikoita, esim. SA, OMT • Kuvaustekniikat täydentävät luonnollisella kielellä tehtyjä spesifikaatioita.

10. Menetelmät • Kuvaustekniikat sisältävät esim. käyttötapauskaaviot, luokkakaaviot, tilakaaviot, tapahtumasekvenssikaaviot • Menetelmä = kuvaustekniikat + ohjeistus • esim. SA/RT, OMT, Octopus, Fusion… • Laatujärjestelmät eivät yleensä ota kantaa, millä menetelmällä dokumentit tuotetaan

11. Menetelmistä • Informaalit (vapaamuotoiset) menetelmät • Puoliformaalit menetelmät • Formaalit (muodolliset) menetelmät

12. Informaalit menetelmät • Seinätaulumenetelmät, jossa määriteltävät asiat kuvataan muodostamalla ratkaistavasta ongelmasta suuria selkeitä kaavioita seinälle • Hyviä menetelmiä asiakasvaatimusten keräysvaiheessa • Menetelmät eivät yleensä vaadi erityiskoulutusta, vaan ovat kaikkien ymmärrettävissä

13. Puoliformaalit menetelmät • Käytettyjen merkintätapojen semantiikka (eli tarkoitus) ei ole kovin tarkasti määritelty vaan sitä voi tarpeen mukaan soveltaa joko enemmän tai vähemmän formaalisti • esim. OMT- ja SA-menetelmät

14. Formaalit menetelmät • Matemaattisia, usein formaaliin logiikkaan perustuvia täsmällisiä spesifiointimenetelmiä • Kieli, jolla on tarkasti määritelty sanasto, syntaksi ja semantiikka • esimerkkeinä Z, VDM, DisCO • Auttavat spesifioimaan hyvin ja täydellisesti, voidaan todistaa ja todeta oikein toimiviksi • Merkitys käytännön ohjelmistotyössä lähes olematon johtuen vaikeudesta ja epähavainnollisuudesta

15. Menetelmistä • Yleisesti kaikkiin tilanteisiin soveltuvaa menetelmää ei ole olemassakaan • Käytännön ohjelmistotyössä menetelmillä ei ole niin suurta merkitystä kuin saattaisi kuvitella • Aloittelevalle ohjelmistosuunnittelijalle menetelmät, ”keittokirjaohjeet” ovat tärkeitä, kokenut ohjelmistosuunnittelija pystyy sovittamaan ne kulloiseenkin tilanteeseen

16. Dokumentointi • Laadukkaiden dokumenttien tuottaminen on käytännön ohjelmistotyön heikoimpia lenkkejä • Dokumentointimallit ja tarkastusmenettelyt dokumentoinnin helpottamiseksi ja varmistamiseksi • Yhdysvaltain puolustushallinnon projekteissa dokumentoinnin määrä on todettu projektin yleiseksi riskitekijäksi: dokumentointia yhtä ADA-kielen käskyä kohti n. 400 englannin kielen sanaa • Ei dokumentointia dokumentoinnin vuoksi, vaan tilanteen mukaan, sisältö ratkaisee

17. Dokumentointi • Minimidokumentaatio: • Määrittely- ja suunnitteludokumentaatio, testaussuunnitelma, testausraportti • Dokumenttien sisältö: • Dokumentaation ylläpidettävyyden kannalta kannattaa välttää tarpeetonta tietojen toistoa: tietty kuvaus vain yhdessä paikassa • Erityisesti suunnitteludokumentaatiossa kannattaa tarkkuustaso valita niin, että ohjelmointivirheiden korjaamien ei välttämättä johda dokumentin päivittämiseen (esimerkiksi vain modulien rajapinnat, modulien sisäinen toiminta kommentteina koodissa)

18. Ohjelmistosuunnitelu, tuotteen versio k+1

19. Esimerkki: pieni ohjelmistoyritys Palaute Overflow Oy resurssit, ideat neuvottelut/ asetta- projekti tai käyttöön- käyttö valmistelu minen hanke otto tarpeet asiakas tehtävää tuotekansio koskevat asiakirjat

20. Ylläpitodokumentaatio • Projektin päättyessä tuotedokumentaatio muutetaan ylläpitoa palvelevaan muotoon • esim. käyttöohje, asennus- ja operointiohje, koulutusmateriaali ja tekninen dokumentaatio • Dokumentaatio asiakkaan tarpeiden mukaan!

21. - Projektiohje - Suunnitteluohje - Määrittelyohje - Ohjelmointiohje - Testausohje - Tarkastusohje Projektisuunnittelu, seuranta ja ohjaus tarkennettu alustava kokouspöytäkirjat loppuraportti projektisuun- projektisuun- nitelma nitelma Työn vaiheistus määrittely tarkastukset suunnittelu projek- projek- tin tarkastukset tin käyn- päät- nis- ohjelmointi tämi- tämi- nen tarkastukset nen järjestelmä- integrointitestaus testaus- suunnitelma järjestelmätestaus toiminallinen määrittely testaus- tekninen ohjelmakoodi raportti määrittely Katselmukset hyväksymis- määrittely- suunnittelu- katselmus katselmus katselmus Pöytäkirjat Esimerkki: Pieni ohjelmistoyritys

22. Dokumentointimallit • Kaikkien dokumenttien ulkoasun yhdenmukaisuus • Osana laatujärjestelmän dokumentaatiota soveltamisohjeineen • Tyyliopas lähdekoodin dokumentointia varten • modulin ulkoasu, muuttujien nimet, sisennykset, kommentoinnit, suosituksia työkalujen käytöstä • IEEEn standardisarja • ESAn standardi PSS-05-04 Issue 2 • Dokumenttimallien suomenkielisiä versioita esim. http://www.cs.tut.fi/cgi-bin/laatu/sivuhaku.pl?nk_no=&nk_id=0

23. Esimerkki dokumenttimallista Ohjetekstejä, poista ennen viimeistä versiota!

24. Ohjelmiston kehittämisessä tarvitaan malleja Mallit - mahdollistavat todellisuuden yksinkertaistamisen - sallivat eri abstraktiotasot, laajuudet ja näkökulmat - toimivat vaihetuotteina suunnittelumenetelmissä - auttavat ymmärtämään sovellusaluetta - helpottavat kommunikointia koskien järjestelmää ja sovellusaluetta

25. Mallien riippuvuus Toteutus Testaus Analyysi Suunnittelu Vaatimukset Vaihetuotemalleja

26. UML (Unified Modelling Language) • Standardoi ohjelmistomallien esitystavan • Pohjana OMT, Booch, OOSE • Pitkän evoluution tulos, kehittyy edelleen • Tarkoitettu erityisesti oliopohjaisille ohjelmistoille • Ei liity suoranaisesti mihinkään suunnittelumenetelmään • OMG:n siunaama (standardoitu 1997) • Nykyinen versio 1.3 • Erittäin laaja • Tosiasiallinen standardi työkaluissa, kirjallisuudessa, teollisuudessa ks. www.omg.org

27. UML: sisältö • Johdanto: mallintaminen ohjelmistokehityksessä • Pikakatsaus kaavioihin • Laajennosmekanismit • Piirrosvälineet, prosessi, käyttöönotto • Vaatimusten mallintaminen: käyttötapauskaaviot • Rakenteen mallintaminen: luokkakaaviot • Vuorovaikutuksen mallintaminen: sekvenssikaaviot • Käyttäytymisen mallintaminen: tila- ja aktiviteettikaaviot

28. UML:n perusosat Elementit Suhteet Riippuvuus Luokka 0..1 * Assosiaatio Olio rooli Kooste Tila Yleistys (Periytyminen) Pakkaus Toteutus Kommentti jne. jne.

29. Kaaviot Käyttötapaus Käsittele puu Kuljettaja Sahaa tukki

30. Miksi käyttötapauksia? • Liittää asiakasvaatimukset järjestelmän toimintoihin • Mahdollistaa vaatimusten täsmentämisen • Mahdollistaa yhteisen käsityksen tehtävästä järjestelmästä • Rajaa järjestelmän ympäristöstään • Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää • Määrittää järjestelmän korkean tason toiminnallisuuden • Auttaa jakamaan toiminnallisuuden osajärjestelmiin • Määrittää järjestelmän perustermit • Apuna olioiden tunnistamisessa • Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu) • Apuna testauksen suunnittelussa • Auttaa käyttöohjeiden laatimisessa

32. Käyttötapauksen kuvaaminen UML ei standardoi esitystapaa. Käyttötapauksen sisältö voidaan kuvata esimerkiksi: Käyttötapauksen nimi: Kuvaava nimi Osallistujat: Mitkä aktorit osallistuvat Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus aloitetaan (epäformaali) Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa) Jättöehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus lopetetaan (epäformaali)

33. Käyttötapauskaavio: notaatio Käyttötapaus sisältää laajennuskohtia, joihin toinen käyttötapaus voidaan sijoittaa Järjestelmä Aktori: käyttötapaukseen osallistuva käyttäjä- tyyppi Käyttötapaus <<extend>> Käyttötapaus Käyttötapaus <<include>> Aktori Käyttötapaus on erikoistapaus toisesta Käyttötapaus Käyttötapaus sisältää toisen osanaan

34. Laajennusrelaatio Accounting System Pay invoice <<extend>> Seller Perform interaction Byer Pay overdraft fee

35. Salinvarausjärjestelmä Varausten poistaminen - Vastuu <<include>> Luentosalin henkilö varaaminen ylläpitäjä Perustietojen ylläpito <<include>> <<include>> Harjoitussalin <<include>> varaaminen Käyttäjän Käyttäjän Salivuokran Salivuokran assistentti identifiointi identifiointi laskutus laskutus <<actor>> <<actor>> vuokra vuokra - - järjestelmä järjestelmä Esimerkki käyttötapauksesta

36. Esimerkki sanallisesta käyttötapauksesta Nimi: Luentosalin varaaminen, versio 1.0 / ijh Suorittajat: Kurssin vastuuhenkilö Esiehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen ylläpito) Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa (uses: KT käyttäjän identifiointi). Käyttäjä pyytää järjestelmää näyttämään salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös, mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä tekee varauksen joltain vapaaksi havaitsemaltaan ajankohdalta. [Poikkeus: varaus ei onnistu]. Poikkeukset: Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun varaaja tekee varausta. Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä yrittää uudelleen. Lopputulos: Varaukset kurssin luentoajoiksi on tehty. Muut vaatimukset: Päivittäin käsitellään kiireisimpänäkin aikana enintään n. 100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys saa kestää 5 sekuntia.

37. Käyttötapausten laatimisesta • Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa. • Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta. • Kaikkia käyttötilanteita ei voi eikä kannata antaa käyttötapauksina. • Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne. • Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa: • Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus). • Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja). • Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi leikkuupöydälle).

39. Luokkakaaviot(class diagrams) • Oliokaavio, ER-kaavio, Entity Relationship diagram, ERD, tietoyhteyskaavio, käsitekaavio, kohdekaavio • Kuvaa järjestelmän käsitteitä (olioita) ja niiden keskinäisiä suhteita • Perinteisesti tietokantasuunnittelun väline • Oliokeskeisissä menetelmissä keskeisin mallinnusväline

41. Luokkakaavio KohdeHallinto Kohde Varasto hallinnoi palauta varaa otaKäyttöön palauta(Kohde, Varasto) varaa(Kohde) otaKäyttöön(Kohde) 1 * HenkilöAuto ParkkiAlue rekisterinumero Talleta huolto- informaatio (palauta kutsuu) huolla(int km) palauta

42. osallistuu kuvaa opinto- kurssi opiskelija jakso luennoi kuuluu suoritus tentti opettaja Esimerkki Martinin luokkakaaviosta

43. Luokkakaavio Chenin notaatiolla 1:N 0:N 0:N 1:1 osallis- opinto- opiskelija kurssi <-kuvaa tuu jakso 1:1 0:N 0:N 0:N 0:N kuuluu suorittaa tentti luennoi 0:1 suoritus opettaja

44. Millä piirrät? • Jos et osaa paperilla ja kynällä ei välineestä ole apua. • CASE (Computer Aided/Assisted Software/System Engineering)-välineet , esim. Rational Rose, Prosa, Rhapsody…) • Hinta verraten korkea (2-10 keur). • Perustuvat tietokantaan, johon talletetaan kaikki malliin liittyvät tiedot, kaaviot ovat vain “näkymiä” tietokantaan. • “Ymmärtävät” kaavioiden semantiikkaa ainakin jossain määrin. • Reverse Engineering+Forward Engineering = Round Trip Engineering. • Tukevat dokumentointia (esim. Soda+Rose). • Demot ja pienet ohjelmaesimerkit antavat usein liian ruusuisen kuvan. • Raskaan sarjan käyttökokemuksia ei ole julkaistu (?). • Oppimiskynnys korkeahko. • Piirto-ohjelmat (Visio, ABCFlowcharter) • Hinta muutamasta sadasta keur:sta ylöspäin. • Ainakin Visiossa melko hyvä UML-tuki, lähestyy CASE-välineen ominaisuuksia. • Hyvä valinta, jos ei tarvitse CASE-välineen tietokannan tuomia lisäetuja. • Julkisohjelmiakin löytyy verkosta.