3. on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Simon jne: Suosi modulaarisuutta. Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Curtis & Dyer: Hyvä suunnittelu vaatii laajaa kokemusta. Dyer, Simon, jne.: alkaa vajaista abstrakteista vaatimuksista ja päättyy matalan abstraktiotason toteutusläheiseen tulokseen. ssa on siis käsiteltävä ongelmaa sekä vaatimusmäärittelyn että toteutuksen näkökulmasta. 1 2 n lait ja hypoteesit n työvaiheet Oppikirjassa esitellyt suunnittelun lait ja hypoteesit liittyvät hyvän suunnittelun ominaisuuksiin. Ne voidaan tiivistää näin: Hyvässä suunnittelussa sovellusalue ja käytetyt menetelmät hallitaan suvereenisti. n tulee olla modulaarista. Mitä vähemmän yhteyksiä suunniteltavien moduulien välillä on, sen parempi. ssa on yleensä ainakin seuraavat työvaiheet: 1. Arkkitehtuurisuunnittelu 2. Osajärjestelmäsuunnittelu 3. Komponenttisuunnittelu 4. Luokkasuunnittelu 5. Tietorakennesuunnittelu 6. Algoritmisuunnittelu 7. Käyttöliittymäsuunnittelu 3 4 Empiiristen tulosten ja työvaiheiden suhde Empiiristen tulosten ja työvaiheiden suhde 2 Curtisin laki: 1-7 Simonin laki: 1-4 Constantinen laki: 3-4 Parnasin laki: 1-5 Denertin laki (ei käsitellä): 1 Fitts-Shneidermanin laki (ei käsitellä): 7 Boochin 2. hypoteesi: 1-4 Bauer-Zemanekin hypoteesi: 1-6 Dyerin hypoteesi: 1-7 Kuten edellisestä listasta näkyy, esiteltävät lait ja hypoteesit ovat geneerisiä: ne sopivat lähes kaikkiin työvaiheisiin. Itse asiassa monet laeista eivät rajoitu vain ohjelmistotekniikkaan, vaan ovat laajemmin voimassa jopa yleisinä luonnonlakeina. 5 6 1
3.1. Curtisin laki Curtisin lain taustaa Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa Curtisin laki perustuu erityisesti sotilasteollisuuden ohjelmistojen tarkkailuun, mutta pätee mille tahansa sovellusalueelle. Curtisin laki on ehkä oleellisin suunnittelun laeista. Se sanoo, että laadukkaan ohjelmiston suunnittelu ei onnistu, jos suunnittelijoilla ei ole vahvaa tietämystä siitä ympäristöstä, mihin ohjelmisto tulee. 7 Hyvään suunnitteluun vaaditaan ennen kaikkea sekä tietoa että ymmärrystä ohjelmiston sovellusalueesta. Sovellusalueet ja niille tehtävät ohjelmistot eroavat vahvasti toisistaan. Kaikkien alojen asiantuntijaa ei ole. Kaikille aloille sopivia ohjelmia ei ole. Koodaustaito ei takaa suunnittelutaitoa. 8 Curtisin lain taustaa 2: suunnittelun vaativuus palvelut, käyttäjien toiminta, rajoitteet, poikkeukset, laitteet Sovellusalueen hallinta Kuvaus rakenteet, arkkitehtuurit, algoritmit, resurssit, tiedot Koodauksen hallinta Hyvään suunnitteluun vaaditaan molempien alueiden hyvää hallintaa. Curtisin lain taustaa 3 n ongelmana on, että suunnittelijoiden pitää olla sekä sovellusalueen että koodauksen asiantuntijoita. Useimmiten näin ei ole. Yleisin lienee tapaus, missä suunnittelijat ovat vain koodauksen asiantuntijoita. Toki voi myös olla, että suunnittelijat ovat vain sovellusalueen asiantuntijoita. 9 10 Curtisin lain perusteluja Curtisin lain perusteluja 2 Curtis perustaa tuloksensa 1986 tekemäänsä 17 projektia kattaneeseen haastattelututkimukseen. Hänen tuloksensa olivat: Vain harvalla projektien jäsenistä oli sovellusalueen tuntemusta. Useimmiten yksi tai kaksi eniten sovellusaluetta tuntevaa henkilöä ottivat päävastuun suunnittelusta. 11 Curtisin tulokset jatkuvat: Samat pari sovellusalueen tuntijaa informoivat muita projektin jäseniä arkkitehtuurista. kokousten tehtävänä oli muokata suunnitelma koko projektiryhmän yhteiseksi näkemykseksi tehtävästä tuotteesta. Johtopäätös: suunnittelu jätettiin suosiolla sovellusalueen asiantuntijoille. 12 2
Curtisin lain teoria Teoria 1 (oppikirja): on yksi tietämyksen sovellus. Osa tietämyksestä on ns. piilotietämystä (tacit knowledge), joka on hienompi sana kokemukselle. Pelkkä kirjoitettu tieto ei riitä matkalla vaatimuksista suunnitteluun, vaan tarvitaan myös vankkaa sovellusalueen tuntemista ja kokemusta. Curtisin lain teoria 2 Teoria 2 (luennoija): Jos Dyerin hypoteesi on voimassa, suunnittelussa johdettavien vaatimusten määrä on jopa 50-kertainen verrattuna käyttäjävaatimuksiin. Suuri osa johdetuista vaatimuksista koskee ohjelmiston suhdetta sovellusalueeseen. Näitä ohjelmiston ja sovellusalueen välisiä vaatimuksia ei voida suunnitella ilman vahvoja taustatietoja sovellusalueesta. 13 14 3.2. Simonin laki Simonin lain taustaa Hierarkkiset rakenteet vähentävät kompleksisuutta. Laki käy perusteluksi mm. suunnittelussa käytettyyn luokka komponentti osajärjestelmä jaotteluun. Simonin laki ei ole pelkkää ohjelmistotekniikkaa, vaan sama laki pätee kaikessa suunnittelussa. Simonin laki onkin yksi universaaleista suunnittelun laeista. Koko maailmankaikkeus tuntuu seuraavan Simonin lakia. Laki pätee sekä elottoman luonnon rakentumiseen alkeishiukkasista galaksiryppäisiin että elollisen luonnon rakentumiseen soluista organismeiksi. Myös ohjelmistotekniikassa hierarkkisten järjestelmien hallinta on helpompaa kuin ei-hierarkkisten järjestelmien hallinta. 15 16 Simonin lain perusteluja Simonin lain teoria Simon perustaa lakinsa havaintoihin luonnosta. Hänen mukaansa luonnossa hierarkkiset järjestelmät kehittyvät nopeammin kuin ilman rakennetta olevat järjestelmät. Evoluutio suosii hierarkkisia järjestelmiä, sillä ne toipuvat paremmin häiriöistä. Sama pätee keinotekoisiin järjestelmiin myös ohjelmistotekniikassa. 17 Simonin laki vaikuttaa olevan luonnonlaki, jolle teorian kehittäminen olisi enemmän filosofiaa kuin EOT:ta. Simon itse toteaa: En tiedä, ymmärrämmekö maailmaa, koska se on hierarkkinen, vai näemmekö maailman hierarkkisena, koska emme ymmärrä emmekä osaa havaita sen hierarkian vastaisia rakenteita. 18 3
3.3. Constantinen laki Hyvällä rakenteella on korkea yhtenäisyys ja matala kytkentäaste. Yhtenäisyys (cohesion, binding): miten sidoksissa moduulin (osajärjestelmän, komponentin, luokan) osat ovat toisiinsa. Kytkentäaste: (coupling): miten sidoksissa moduuli on muihin moduuleihin. Eli mitä paremmin moduuli hoitaa juuri omat hommansa ja mitä riippumattomammin muista, sen parempi. 19 Constantinen lain taustaa Constantinen laki on sukua Simonin laille. Oleellisesti se sanoo, että mitä paremmin järjestelmän osat puhaltavat yhteen hiileen ja mitä vähemmän niillä on keskinäisiä yhteyksiä, sitä enemmän vaaditaan järjestelmän häiritsemiseksi. Yhtenäisyys ja kytkentäaste näkyvät selvästi mm. oliopohjaisessa suunnittelussa ja suunnittelumalleissa. 20 Constantinen lain perusteluja Sekä yhtenäisyys että kytkentäaste voidaan määritellä matemaattisesti. Määritelmän avulla yhtenäisyyttä ja kytkentäastetta voidaan mitata ohjelmakoodista, joten Constantinen lain testaamiseen voidaan käyttää staattisia metriikoita. Tällaisia tutkimuksia on jo tehty (Basili 1996, Briand 1998). Constantinen lain perusteluja 2 Tutkimusten oleellisia tuloksia: Vahva yhtenäisyys Ł vähän virheitä: Vahva vastaavuus. Korkea sisäinen kytkentäaste (olio kutsuu muita)ł enemmän virheitä: Vahva vastaavuus. Korkea ulkoinen kytkentäaste (oliota kutsutaan)ł enemmän virheitä: Heikko vastaavuus. 21 22 Constantinen lain teoria 3.4. Parnasin laki Korkea yhtenäisyys tarkoittaa, että moduulissa ei ole mitään ylimääräistä. Tämä helpottaa testausta ja pienentää virhealttiutta. Matala kytkentäaste tarkoittaa, että moduulit voidaan paremmin eristää toisistaan. Tämäkin helpottaa testausta ja pienentää virhealttiutta. Vain piilotettua tietoa voidaan muuttaa ilman riskiä. Parnasin laki on kapseloinnin perusta, ja siten yksi ohjelmistotekniikan tärkeimmistä laeista. Laki on myös kaiken modulaarisuuden perusta yhdessä Simonin lain kanssa. Parnasin laki pätee ainakin kaikissa insinööritieteissä, ehkä myös muualla. 23 24 4
Parnasin lain taustaa Parnasin laki on varmaankin tunnetuin ohjelmistotekniikan laki. Kaikki käyttävät sitä ajattelematta asiaa sen kummemmin. Parnasin lakia voidaan soveltaa mm. projektinhallinnassa: kaikkien ei tarvitse tietää yksityiskohtia kaikista työvaiheista, vaan työvaiheiden tulokset ratkaisevat. Parnasin lain perusteluja Parnas perustaa lakinsa tapaustutkimukseen, missä hän tarkkaili Philipsin insinöörien työskentelyä. Parnas havaitsi, että modularisointi oli tärkeä suunnittelumenetelmä, mutta sitä ymmärrettiin huonosti. Parnasin lain perustelut ovat varsin köykäiset. Toisaalta laki on samaan tapaan luonnonlaki kuin Simonin laki. 25 26 Parnasin lain teoria 3.5. Boochin toinen hypoteesi Parnasin lain teoria voidaan perustaa kahteen faktaan: a tarvitaan koko tuotteen elinkaaren ajan. Kehitystyössä tarvittavia ratkaisuja on voitava siirtää eteenpäin ilman että ne mitätöivät tehdyt muutokset. Ihmisen käsitys- ja omaksumiskyky on rajallinen. Tiettyyn tehtävään vaadittavan tiedon vähennys helpottaa tehtävän tekoa. Oliopohjainen suunnittelu vähentää virheitä ja rohkaisee uudelleenkäyttöön. Boochin toinen hypoteesi on sukua vaatimusmäärittelyssä esitellylle Boochin ensimmäiselle hypoteesille. Jos Boochin hypoteesit ovat valideja, olioparadigmaa kannattaa käyttää koko projektin elinkaaren ajan. 27 28 Boochin toisen hypoteesin taustaa Oliomallinnuksen katsotaan parantavan erityisesti suunnittelun laatua. Malleina oliot ovat lähempänä mallintamiaan luonnon kohteita kuin proseduraalisen ohjelmoinnin funktiot. Boochin hypoteeseista huolimatta oliomallinnus ei ole mikään viisasten kivi, joka ratkaisee kaikki ongelmat. Boochin toisen hypoteesin perusteluja Oikein käytettynä oliomallinnus on mainio työkalu. Vaatimusmäärittelyn käyttötapauksista voidaan eristää eri tasoisia olioita. Vaatimusmäärittelyn oliot voidaan jalostaa suunnittelussa käytettäviksi olioiksi. Hierarkkiset rakenteet, yhtenäisyys & kytkentäaste ja kapselointi ovat mukana suunnittelun alusta alkaen. 29 30 5
Boochin toisen hypoteesin perusteluja 2 Valitettavasti oliomallinnuksella on kääntöpuolensa. Oliomallinnus sallii myös virheherkkiä rakenteita, kuten perintä, kuormitus ja myöhäinen sidonta. Näistä on myös empiirisiä tuloksia: Syvä perintähierarkia Ł enemmän virheitä Erittäin vahva vastaavuus. Metodien korvaus Ł enemmän virheitä Vahva vastaavuus. 31 Boochin toisen hypoteesin perusteluja 3 Ei ole sattumaa, että Boochin toinen hypoteesi ei ole laki. Se ei toimi riittävän yleisillä ehdoilla. Sen sijaan on selvää, että oikein käytettynä oliomallinnus on oiva työkalu. Se sisältää aiemmista laeista saadut hyvät tulokset hierarkkisista rakenteista, kapseloinnista, yhtenäisyydestä ja kytkentäasteesta. 32 3.6. Bauer-Zemanekin hypoteesi taustaa Formaalit menetelmät vähentävät merkittävästi suunnitteluvirheitä tai eliminoivat ne aikaisessa vaiheessa. Vaikka ohjelmistotekniikka ei perustu matematiikkaan, jotkut ohjelmistotekniikan alueet (mm. lasilaatikkotestaus) on voitu formalisoida matemaattisin menetelmin. B-Z:n hypoteesin mukaan matemaattinen formalismi sopii hyvin myös suunnitteluun. 33 Formaalit menetelmät perustuvat johonkin matemaattiseen formalismiin, jonka avulla jokin ratkaisu voidaan todistaa oikeaksi. Formalismin avulla voidaan kirjoittaa ongelman määrittely, todistaa määrittelystä ominaisuuksia, tehdä määrittelyyn perustuva ratkaisu, todistaa ratkaisu matemaattisesti oikeaksi. 34 taustaa 2 B-Z:n hypoteesille on paljon kannatusta, sillä matemaattista formalismia pidetään perimmäisenä suunnittelun ratkaisuna. Kannattaa kuitenkin huomata, että kaikkia ongelmia ei voida formuloida, formalismin ymmärtäminen ja varsinkin uuden formalismin kehittäminen vaatii vankkaa matemaattista taustaa, formalismin päivittäminen on vaikeaa. 35 perusteluja B-Z:n hypotesi on eräs eniten kiistellyistä EOT:n alueista. Aiheesta on tehty lukuisia tapaustutkimuksia, mutta tulokset ovat olleet ristiriitaisia. Hallin tutkimuksessa 1990 keskikokoisen projektin (58 KLOC, Kilo Lines of Code) formaali määrittely paransi suunnittelua ja nopeutti virheiden löytymistä. Tuotteesta ei tarvittu luonnollisella kielellä tehtyä normaalia määrittelyä. 36 6
perusteluja 2 Hayesin tutkimuksessa 1985 CICSjärjestelmän (Customer Information Control System) ohjelmoijan manuaali määriteltiin uudestaan formaalilla kielellä. Määrittelyssä manuaalista löydettiin useita puutteita ja epäjohdonmukaisuuksia, jotka johtivat muutamien CICS-järjestelmän osien kirjoittamiseen uudestaan. Projektin tuloksena raportoitiin 60% virhevähennys ja 5,5 miljoonan dollarin kustannussäästö. perusteluja 3 Vaikka tulokset ovat vakuuttavia, niiden yleistäminen isompaan projektijoukkoon ei ole itsestään selvää: Kyseessä oli lähinnä dokumentointi- ja ylläpitoprojekti, mikä pitää ottaa huomion tulosten analyysissa. Koko projekti kesti kaiken kaikkiaan 12 vuotta! Joka tapauksessa projekti on yksi eniten viitatuista formaalien menetelmien käytettävyystutkimuksista ja vahva osoitus siitä, että parhaimmillaan formaalit menetelmät ovat erittäin hyödyllisiä. 37 38 perusteluja 4 perusteluja 5 Pfleegerin ja Hattonin tutkimuksessa 1997 seurattiin noin 200 KLOC kokoisen C- kielisen ohjelman tekoa. Merkittäviä osia ohjelmasta määriteltiin formaalisti. Pfleeger ja Hatton mittasivat tuotteen osien virhetiheyttä sekä projektin aikana että tuotantokäytössä. Pfleegerin ja Hattonin tulokset olivat: Projektin aikana: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 19,6 : 22% Ei-formaalit: 21,0 : 19% Tuotantokäytössä: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 0,58 : 0,12% Ei-formaalit: 1,61 : 0,27% 39 40 perusteluja 6 perusteluja 7 Pfleegerin ja Hattonin tulokset ovat vakuuttavia varsinkin tuotantokäytössä löytyneiden virheiden osalta. Siitä huolimatta kritiikkiäkin löytyy: Projektiin osallistujien kokemuksesta ei ole tietoa, ei myöskään osallistujen formaalien menetelmien tietotaidosta. Projektissa ei ilmeisesti käytetty tarkastuksia, sillä virheiden elinikä oli pitkä. Tarkastusten käyttö olisi ehkä kutistanut formaalien ja eiformaalien tulosten eroa. 41 Formaaleista menetelmistä on taitettu peistä molempiin suuntiin. Ehkä parhaiten alaa kuvaa seuraava Gerhard, Craigen, Ralston kommentti: There is no simple answer to the question: do the formal methods pay off? All cases involve so many interwoven factors that it is impossible to allocate payoff from formal methods versus other factors. Gerhard et al. Observation on Industrial Practice Using Formal Methods, Proc. Int l Conf. Software Eng., 1993, 24-33. 42 7
3.7. Dyerin hypoteesi Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Dyerin hypoteesi on esitelty Glassin kirjassa R. Glass, Facts and Fallacies of Software Engineering. Glass kirjoittaa kirjassaan yrittäneensä saada Dyerin kommentoimaan hypoteesiaan, mutta Glassin mukaan Dyer ei vastannut yhteydenottopyyntöihin. Dyerin hypoteesin taustaa Siirtyminen vaatimusmäärittelystä suunnitteluun on samalla iso hyppy abstraktiossa. Vaatimusmäärittelyssä löytyneet vaatimukset eivät riitä suunnitteluun, vaan suunnittelun sivutuotteena löytyy uusia vaatimuksia. Näitä kutsutaan johdetuiksi vaatimuksiksi (derived requirements). 43 44 Dyerin hypoteesin taustaa 2 Dyerin hypoteesin perusteluja Johdetut vaatimukset johtuvat erilaisista abstraktiotasoista. Vaatimusmäärittelyn mitä -abstraktio ei riitä kuvaamaan kaikkea tarvittavaa suunnittelun miten -abstraktioon. Glassin mukaan johdettuja vaatimuksia voi olla pahimmillaan 50 kertaa alkuperäisiä vaatimuksia enemmän! Dyerin hypoteesia ei ole validoitu, vaikka Glassin mukaan hypoteesi on tunnettu jo vuosikymmeniä. Hypoteesin validointi vaatisi joukon projekteja, joista laskettaisiin vaatimusten lukumäärän suhde johdettujen vaatimusten lukumäärään. Ainakin ohtu-projekteissa hypoteesi on todettu useamman kerran oikeaksi. 45 46 Esiteltyjen lakien seurauksia Esiteltyjen lakien seurauksia 2 Hyväksi suunnittelijaksi ei tulla pelkällä opiskelulla. Curtisin lain mukaan hyvä suunnittelija hallitsee suvereenisti suunniteltavan ohjelmiston sovellusalueen. Tähän vaaditaan ennen kaikkea kokemusta. Simonin lain mukaan ei-pakollisen tiedon rajoittaminen parantaa suunnittelua. Tällaisen tiedon tunnistus suunnittelussa vaatii ennen kaikkea kokemusta. 47 Modulaarinen lähestymistapa parantaa ja helpottaa suunnittelua. Simonin, Constantinen, Parnasin ja Fitts- Shneidermanin lait johtavat kaikki ylläolevaan tulokseen. Lisäksi oppikirjassa on esitelty Denertin laki, jota voidaan käyttää standardoitujen arkkitehtuurien perusteena. Myös tämä laki johtaa samaan tulokseen. 48 8