yksinkertaisuus (simplicity)

erilaiset abstraktiot ja rakenteet, joilla pyritään hallitsemaan sovellusten luontaista monimutkaisuutta

Yksinkertaisuus on ollut kautta aikojen keskeinen tavoite tietojenkäsittelyjärjestelmien suunnittelussa, mutta järjestelmien monimutkaistuessa niitä ei useinkaan voida aloittaa kehittämään ns. ”puhtaalta pöydältä” (keskeinen opetus). David Lorge Parnas mainitsee esimerkin tietoliikenneohjelmistosta, jonka koosta arviolta 75 % on historian painolastia [Parnas, 1996]. Hän ilmaisi näkemyksiään IEEE Computer -lehdessä julkaistussa artikkelissaan ”Why Software Jewels Are Rare”. Eräänä perimmäisenä kysymyksenä Parnas esittää kysymyksen: ”miksi ohjelmistohelmiä on niin vähän, jos keskeiset kirjoitukset tarjoavat käyttökelpoisia ratkaisuja ohjelmoinnin ja ohjelmistojen tekemisen ongelmiin?”

Mahdollisista syistä hän nostaa esille mm. nykyisin vallitsevat erilaiset olosuhteet (ohjelmien kehittäminen ilman kaupallisia paineita on ylellisyyttä), sekä yhteensopivuusvaatimukset vanhojen järjestelmien ja muiden nykyisten ohjelmistojen kanssa. Myös muutokset, jotka toteutetaan siinä vaiheessa, kun ohjelmiston arkkitehtuuri/rakenne on jo suunniteltu ja toteutettu, rikkovat suunnitteluvaiheessa hyväksi koettua rakennetta. Parmas ihmetteleekin sellaisten ”helmien” vähäistä määrää, jotka ovat alun perin suunniteltu siten, että selkeä rakenne ei rikkoudu ohjelmistoa laajennettaessa.

Parmasin mukaan hyviä ja jo aiemmissa toteutuksissa dokumentoituja ratkaisuja jää tekemättä, mikä voi johtua siitä, että tietoa on nykyisin enemmän, joten pelkästään eri käytäntöjen vertailuun ja oppimiseen kuluva aika on erittäin pitkä – olettaen, että aluksi löytää nuo sopivat suunnittelumallit. On hidasta, erittäin virhealtista ja käytännössä mahdotonkin ohjelmoida kaikkea assembler-tasolla, saati suunnitella joka tarpeeseen uutta kieltä, joten korkeamman tason ohjelmointikielien rajoitteisiinkin on usein tyytyminen. Tärkeintä on kuitenkin huolellinen suunnittelu (keskeinen opetus).

suorituskyky (performance)

suoritustehon (engl. throughput ) ja vasteajan (engl. response time) ennustaminen, pullonkaulojen (engl. bottlenecks) paikallistaminen,kapasiteetin suunnittelu (engl. capacity planning)

Suorituskykyä tutkitaan mittaamalla järjestelmän toimintaa, matkimalla eli simuloimalla järjestelmän keskeisten osien toimintaa sopivalla tarkkuudella sekä laatimalla järjestelmästä matemaattisia malleja, joista keskeiset suorituskykysuureet lasketaan. Ohjelmistojen suorituskyvyn suunnittelusta puhumisen aloitti Connie Smith vuonna 1981 Computer Measurement Groupin konferessissa. Hänen mukaansa ohjelmistotekniikassa suorituskyvyn katsottiin ohjelmiston kehitysprosessissa kuuluvan ainoastaan ”viimeistelyyn”.

Daniel A. Menasce ilmaisi oman näkemyksensä suorituskykyyn liittyen kesäkuussa 2002 pitämässä esitelmässään ”Software, Performance, or Engineering?” ACM:n WOSP’02-konferenssissa. Hän kritisoi mm. sitä [Menasce, 2002], kuinka prosessorien tehon kasvu on aiheuttanut tehottomien ohjelmistojen tekemisen eli toisin sanoen resurssien tuhlailun. Suorituskykyvaatimukset pitäisi hänen mukaansa saada alusta lähtien sisällytetyksi ohjelmiston elinkaaren tukena oleviin erilaisiin formalismeihin (keskeinen opetus) ja lopettaa niiden kutsuminen ei-toiminnallisiksi vaatimuksiksi. Hän kysyykin, ”miten ohjelmisto voi toimia kelvollisesti, jos suorituskykyvaatimukset jäävät täyttämättä”. Tyypillisesti ohjelmistojen vaatimukset jaetaan toiminnallisiin ja ei-toiminnallisiin vaatimuksiin.

Ennen artikkelinsa johtopäätöksiä, jotka hän aloittaa toteamalla, että ”ohjelmiston monimutkaisuus aiheuttaa usein tehottomuutta”, hän tuo esiin selvityksiä sille, miksi suorituskyvyn suunnittelu ei ole tullut osaksi jokapäiväistä ohjelmistotuotantoa: tieteellisten periaatteiden ja mallien puute, koulutus, tietojenkäsittelyn ”ammattilaiset” (itseoppineet), yhden käyttäjän asenne ja pienen tietokannan asenne. Menascen mukaan useimmat suunnittelijat ja ohjelmoijat eivät ota huomioon (keskeinen opetus) sitä, että useimmissa järjestelmissä on useita samanaikaisia käyttäjiä, mikä vaikuttaa mm. pyyntöjen käsittelynopeuteen prosessorissa, sekä tietokantaan kerääntyvän tiedon hakunopeuteen. Tämä pitänee rajoitetusti paikkansakin edelleen.

luotettavuus (reliability)

toisteisuus (engl. redundancy), toipuminen (engl. recovery), varmistaminen (engl. checkpointing), eheys (engl. integrity), luottamus (engl. trust)

Ohjelmien luotettavuudesta esittävät konventionaalisesta varsin merkittävästi poikkeavan näkemyksen herrat George Candea ja Armando Fox artikkelissaan Crash-Only Software [Candea & Fox, 2003]. Heidän lähestymistapansa perusajatuksena on, että ohjelmien kaatuminen on tehtävä turvalliseksi ja siitä toipuminen nopeaksi. He maalailevat kuvan järjestelmistä, joissa normaali järjestelmän alasajo tapahtuu ns. kaatamalla se – ja toipumalla siitä mitään tietoa hukkaamatta (keskeinen opetus). Tämä vaatisi järjestelmän suunnittelun sillä tapaa rakenteeltaan modulaariseksi, että kaikki yksittäiset komponentit ovat varautuneita (keskeinen opetus) muiden komponenttien kaatumisiin ja tilapäisiin käytöstä poissaoloihin.

Näissä ’crash-only’ järjestelmissä käytetään käsitettä transaktio kuvaamaan toimenpidesarjaa, joka suoritetaan joko kokonaan tai ei ollenkaan, mikä takaa sen, että toimenpidesarjan vaikutukset näkyvät muille vasta sitten, kun kaikki transaktioon kuuluvat toimenpiteet on saatu päätökseen. Nykyisissä järjestelmissä, joiden suunnittelussa on yritetty mallintaa järjestelmän toimintaa niin, että kaikki teoreettisesti mahdolliset vikatilanteet otettaisiin huomioon, eivät ole täydellisiä, vikatilanteidenkin ollessa toisinaan erittäin monimutkaisia käsitellä.

Jotta ohjelmistokomponentti olisi ’crash-only’, sen on talletettava kaikki ei-tilapäinen tilatieto erityiseen tilatietovarastoon (state store), jonka on myös oltava ’crash-only’. Erikoistuneita tietovarastoja ovat mm. relaatio- tai oliotietokannat ja tiedostojärjestelmät, mutta ollakseen ’crash-only’, niiden toipumisen täytyisi olla nopeaa. Komponenteillä kohdistuvien pyyntöjen on oltava itsensä kuvaavia, kerrottava eksplisiittisesti tarvitsemansa käsittelyn tilatieto ja konteksti. Tämän avulla uudelleenkäynnistetty komponentti voi suorittaa pyynnön uudelleen. Komponenttien välillä on oltava rajat, jotka estävät häiriöiden heijastumisen muiden komponenttien toimintaan.

kehitettävyys (evolvability)

varautuminen toiminnallisuuden ja käytön laajuuden muutoksiin

Voitaneen kuvitella ohjelmistoja, jotka ovat valmistuessaan sillä tapaa lopullisia, että mitkään toimintaympäristössä, teknologiassa tai käyttäjien vaatimuksissa tapahtuvat muutokset eivät aiheuta pienintäkään tarvetta muuttaa näitä ohjelmistoja, mutta ne lienevät harvalukuisia. Ohjelmisto itsessään on malli sovellutuksesta, osallistujista (ihmiset, organisaatiot, laitteet, koneet), käyttöalueesta ja kyseisen alueen toiminnoista [Lehman, 1998]. Erityisesti käyttöalue vaikuttaa siihen, kuinka nopeasti ohjelmisto voi käydä ”vanhaksi”, ellei suorastaan käyttökelvottomaksi, ellei tarpeellisia muutoksia tehdä.

Organisaatioiden tietojärjestelmätarpeet ovat usein huomattavasti hitaammin muuttuvia kuin laskennallisten tieteiden vaatimat ohjelmistot, joissa tutkimustyön eteneminen voi olla kiinni siitä kuinka tarkkoja laskelmia ohjelmisto kykenee käsittelemään ja tuottamaan. Lehman kutsuu e-ohjelmistoiksi ohjelmistoja, joita käytetään todellisen maailman sovellutuksissa, ongelmissa tai toiminnoissa. Lehman katsookin e-ohjelmiston olevan äärellinen ja epätäydellinen malli (keskeinen opetus) rajoittamattoman käyttöalueen rajoittamattomasta sovellutuksesta.

Koska ohjelmisto ei ole ainut käytössä oleva sellainen ja sellaisia kehittävätkin muutkin, ajaudutaan jossain vaiheessa väistämättä tarpeeseen tehdä ohjelmistoja yhteentoimiviksi. Lehman muistuttaa ulkoisista muutospaineista, joista voisi esimerkeiksi kuvitella direktiivit, poliittiset päätökset ja käyttäjien mieltymykset – mikään näistä ei välttämättä ota huomioon vaikutuksia tietojenkäsittelyyn (keskeinen opetus). Ohjelmistojen kehitettävyyden kannalta olisi hyödyllistä tunnistaa (keskeinen opetus) mahdollisia muutostarpeita ennakkoon ja tehdä ohjelmistoista sillä tapaa mukautuvaisia ja joustavia, ettei koko ohjelmistoarkkitehtuuria tarvitsi laittaa uusiksi muutoksia tehtäessä. Tämä sisältää Lehmanin ohjelmistojen kehitettävyyttä parantaviin suosituksiin, kuten myös jatkuva oletuksien ylöskirjaaminen ja säännöllinen katselmointi.

tietoturva (security)

pääsynvalvonta (engl. access control), salassapito (engl. secerecy), yksityisyys (engl. privacy), tunnistus (engl. authentication), eheys (engl. integrity), turvallisuus (engl. safety).

Tietoturvan käsitteen alle on Denning [ym., 1989] sijoittanut pääsynvalvonnan, salassapidon, yksityisyyden, tunnistamisen, eheyden ja turvallisuuden. Turvallisuuden käsite liittyy olennaisesti tilanteisiin, joissa ohjelmiston virhetoiminnot voivat aiheuttaa haittaa tai pahimmassa tapauksessa kuoleman ihmisille tai muille eläville olennoille. Nancy G. Leveson ja Clark S. Turner, jotka ovat analysoineet Therac-25 -sädehoitolaitteen aiheuttamia onnettomuuksia, huomauttavat, että onnettomuuksien takana on usein monimutkainen vyyhti (keskeinen opetus) toisiinsa liittyviä tapahtumia, jotka johtuvat teknisistä, inhimillisistä ja työyhteisöön liittyvistä tekijöistä.

Therac-25 -onnettomuuksien ilmetessä tehtiin vääriä ja ylimalkaisia olettamuksia siitä, mikä aiheutti onnettomuuden ja miten uudet onnettomuudet voitaisiin estää. Heidän mielestään monimutkaisten järjestelmien aiheuttamien onnettomuuksien analysoinnin on perustuttava järjestelmien rakentamisen (system-engineering) lähestymistapaan. Ensimmäisten onnettomuuksien sattuessa virhettä ei edes etsitty ohjelmistosta, ilmeisesti siksi, että ”ohjelmisto ei kulu käytössä”, kuten laitteet, jotka vaativat huoltoa.

Vaikka ohjelmiston ei soisi koskaan käyttäytyvän odottamattomasti tai epätoivotusti, on tuota vaatimusta vaikea täyttää, varsinkin kun turvallisuusanalyysien yksi keskeinen ongelma on, että niissä usein jätetään ottamatta huomioon asioita, joita on vaikea kvantifioida (keskeinen opetus). Therac-25:n tapauksessa jätettiin noudattamatta lukuisia ohjelmistotekniikan peruskäytäntöjä, kuten hyvä dokumentointi ja testauksen kattavuus.

Ohjausjärjestelmät, jossa ohjelmisto on yhtenä komponenttina osana isompaa kokonaisuutta, olisi suunniteltava pahimman tilanteen varalle. Tässä tapauksessa Therac- 25 ei pystynyt havaitsemaan antamaansa säteilyn yliannostusta, mikä ei johtunut niinkään tavanomaisemmasta suunnitteluvirheestä vaan ohjelmointivirheestä, minkä myöhempi selvittäminen sekin oli työlästä.