Ülik~orge töökindlusega tarkvara kirjutamine SEL kogemuse näitel

Transcription

1 T A R T U Ü L I K O O L MATEMAATIKA-INFORMAATIKATEADUSKOND Arvutiteaduse instituut Jürgen Jänes Ülik~orge töökindlusega tarkvara kirjutamine SEL kogemuse näitel Referaat aines Tarkvaratehnika Juhendaja: Ivo Mägi TARTU 2005

2 Sisukord 1 Sissejuhatus 2 2 SEL metodoloogia üldine kirjeldus 3 3 V~ordlus RUP ja XP-ga RUP XP Kokkuv~ote 9 1 Sissejuhatus Käesoleva referaadi eesmärgiks on anda ülevaade ülik~orge töökindlusega tarkvara loomisel kasutatavatest metodoloogiatest, lähtudes peamiselt NASA juurde kuuluva Tarkvaratehnika Laboratooriumi (Software Engineering Laboratory, SEL) materjalidest.[7, 9, 8] SEL on aastal algselt Goddard'i Kosmoselennu Keskuse (Goddard Space Flight Center, GSFC) juurde loodud uurimisasutus, mille ülesandeks NASA kosmosemissioonidega seotud tarkvara arendusprotsessi uurimine ja täiustamine. Ühe suurema ning pikaajalisema SEL'i metodoloogia alusel läbi viidava projektina v~oiks mainida NASA kosmosesüstikute lennutarkvara, mis on oma mahu poolest (koos tugikoodiga umbes 2 miljonit koodirida) samas suurusjärgus OpenOf- ce'i v~oi Mozilla taoliste programmidega, kuid ületab viimaseid tunduvalt nii kiiruse kui ka töökindluse poolest (mis on ka m~oistetav, arvestades et kahe kolmandiku sekundine varieerumine soovitud ajahetkest mootorite käivitamisel/peatamisel toob endaga kaasa umbes 5 kilomeetrilise erinevuse soovitud orbiidist).[1] Iroonilise vahemärkusena - sellist arvutit, mis OpenOce'i v~oi Mozilla viimase versiooni kahe kolmandiku sekundiga käivitaks, tänapäeval vist vähemalt laiatarbekaubana müügile ei ole... Heal juhul toob kriitiline viga lennujuhtimistarkvaras endaga kaasa miljonite dollarite suuruse majandusliku kahju koos aastatepikkuse töö kadumaminekuga, halval juhul v~oib see otseselt ohtu seada inimelu. Üheks tuntumaks näiteks vigase tarkvara t~ottu hävinud kosmosemissioonist v~oib tuua 200 miljonit dollarit maksma läinud Mars Climate Orbiteri hävimise Marsi atmosfääris aastal erinevate m~o~oteühikute segiajamise t~ottu.[4] Teisest küljest on küllaltki vähetuntud fakt, et Apollo 11 kuumooduli maandumisel oli kosmoseaparaadi pardaarvuti lennujuhtimiskeskuse ning astronautide täiel teadmisel pidevas 2

3 uuestikäivitamise tsüklis, kompenseerimaks anomaalsetest radariandmetest tingitud mälu ületäitumist.[2] Aukartus tolleaegsete programmeerijate vastu suureneb veel paari suurusjärgu vrra, teades et kuumooduli programm jooksis 5000 transistori-taolise elemendiga arvutil (keskmise kaasaaegse protsessori transistorite arv ulatub miljonitesse), millel oli 4 kilobaiti muutmälu ning 74 kilobaiti püsimälu. Tarkvara loojad ei olnud küll suutnud ette näha k~oiki vimalikke olukordi (radariandmete ületäitumine tuli ootamatusena), kuid hoolika disaini ning p~ohjaliku testimise tulemusena oldi kindlad süsteemi v~oimekuses end pideva taaskäivitamise kaudu töökorras hoida. 2 SEL metodoloogia üldine kirjeldus SEL metodoloogiat v~oib arusaadavatel p~ohjustel lugeda üheks konservatiivseimaks tarkvaraarenduse metodoloogiaks. Üldiseimas plaanis jaotatakse tarkvara elutsükkel kaheksaks osaks.[9] N~ouete denitsioon (requirements denition) Antud faasis toimub esialgne kliendi (ehk siis kosmosemissiooni disainijate) n~ouete teisendamine selgeks spetsikatsiooniks. Lennujuhtimistarkvara jaoks pannakse enamvähem paika missiooni algne ajakava, planeeritud manöövrid ning nendega seotud arvutused. Süsteemi funktsionaalsus kirjutatakse lahti alamsüsteemide tasemel (nt telemeetriaprotsessor, lennumootorite kontroller). Otsitakse v~oimalikke variante tarkvarakomponentide taaskasutamiseks. N~ouete denitsiooni tulemuseks on Süsteemikirjeldus- ja opereerimise kontseptdokument (System and operations concept document ), mis vaadatakse üle faasi l~opetaval koosolekul (System concept review ). Lisaks sellele valmib antud faasis ka n~ouete- ja spetsikatsioonidokument (Requirements and specications document ), mille alusel koostab arendusmeeskonnast eraldiseisev sobivustestimise meekond sobivustestid. N~ouete analüüs (requirements analysis) Jätkub analüüsimeeskonna töö funktsionaalsete n~ouete täpsustamise kallal, lisaks sellele uuritakse endiselt koodi taaskasutamise v~oimalusi. Faasi tulemuseks on vastav raport (Requirements analysis report ), mille ülevaatusega (Software specications review) n~ouete analüüsi faas ka l~opeb. Esialgne disain (preliminary design) Disainifaasis algab arendusmeeskonna töö - pannakse paika tulevase tarkvarasüsteemi suuremad komponendid, spetsitseeritakse detailselt k~oik sisemised ja välised liidesed ning pannakse kirja k~orgema taseme objektide/funktsioonide disain. Järjekordselt 3

4 l~opeb faas formaalse raportiga (Preliminary desing report ), millele ametlik kinnitamine toimub vastavalt koosolekul (Preliminary design review ). P~ohjalik disain (detailed design) Antud faasis süvendatakse olemasolev disain iteratiivselt praktiliselt pseudokoodi tasemele. Seda toetavad disainidiagrammid, süsteemi sisendi-väljundi kirjeldused, tööprotseduuri kirjeldused ning üksikute üksuste tasemel välja kirjutatud funktsionaalsed ja protseduurilised kirjeldused ning liideste kirjeldused leiavad kajastamist Detailses disainidokumendis (Detailed design document ), mis vaadatakse l~oplikult üle vastaval ametlikul koosolekul (Critical design review ). Implementeerimine (implementation) Implementatsioonifaasis toimub disaini implementeerimine, komponentide testimine (unit testing) ning integreerimine. Vastavalt disainifaasis paika pandud tööplaanile kirjutatakse paralleelselt erinevad alamsüsteemid, tehakse neile koodiülevaatus ( code review) ning ühendatakse teatud ajavahemike tagant ka kokku, kontrollimaks terve programmi korrektsust (end-to-end processing capability). Faasi tulemusena valmib ka testimisplaan ning kasutamisjuhendi mustand. Süsteemitestimine (system testing) Süsteemitestimise faasis toimub valmiskirjutatud süsteemi testimine arendusmeeskonna poolt vastavalt implementatsioonifaasis paika pandud testimisplaanile. Vastavalt süsteemitestimise tulemustele viiakse sisse parandusi programmis ning täiendatakse kasutamisjuhendit. Lisaks valmib süsteemikirjelduse (System description) dokumenti mustand. Sobivustestimine (acceptance testing) Käesolevas faasis testitakse süsteemi s~oltumatu sobivustestimise meeskonna poolt, mis kinnitab süsteemi käitumise vastavust algsetele n~ouetele. Sobivustestimine toimub vastavalt sobivustestimise plaanile (accpetance test plan), mis koostatakse n~ouete denitsiooni tulemusena valminud n~ouete- ja spetsikatsioonidokumendi alusel. Hooldus- ja tööfaas (maintenance and operation) Antud faas algab tarkvara kasutuselev~otmisega töötingimustes. Tarkvaraarenduse osa antud faasis s~oltub programmi tüübist - spetsiilise kosmoseaparaadi lennujuhtimistarkvara puhul on arendus- ja täiendamistegevus minimaalne, seevastu üldotstarbema tarkvara puhul v~oib toimuda küllaltki aktiivne tarkvara moditseerimine ja arendamine. Kokkuv~otlikult on SEL'i metodoloogia välja aretatud ülik~orget töökindlust n~oudvate ning tehniliselt küllaltki keeruliste programmide jaoks (reaalajasüsteemid, komplitseeritud matemaatilised arvutused), mis on aga suhteliselt stabi- 4

5 ilsete n~ouetega (kosmosemissioonide disainimisele kuluv aeg varieerub aastatest aastakümneteni). SEL metodoloogias pannaks väga tugevat r~ohku disaini- ja programmeerimisvigade minimeerimisele. Sellest lähtuvalt toimuvad juba analüüsi faasis, s~oltuvalt projekti suurusest (mida mahukam projekt seda sagedasemini) perioodilised ülevaatuskoosolekud (walk-throughs), mille eesmärgiks on avastada v~oimalikult vara igasugused vead v~oi ebatäpsused. Implementeerimisel rakendatakse koodi veakindluse t~ostmiseks samuti suhteliselt vähekasutatavat meetodit - koodilugemiselt (code review), mis tähendab sisuliselt seda, et iga programmeerija kirjutatud kood vaadatakse teis(t)e inimes(t)e poolt üle. Varasemate projektide statistikast on huvitava faktina ilmnenud see, et kahe inimese poolt avastatud vigadest k~oigest 1/4 langevad kokku (st avastatakse m~olema inimese poolt). Seepärast n~ouab SEL, et ühte koodijuppi vaataksid üle vähemalt kaks inimest. Vea avastamisel (s~oltumata meetodist) vaadatakse alati üle ka ülejäänud kood, eesmärgiga leida sama tüüpi viga (näiteks 180 -vead). Lisaks sellele dokumenteeritakse rangelt igasugused vead ning nendest p~ohjustatud muudatused programmis. Protsessi eesmärk ei ole mitte ainult parandada avastatud viga, vaid k~orvaldada vea tekke p~ohjus. SEL paneb küllaltki suurt r~ohku erinevate statistiliste näitajate kogumisele läbiviidavate projektide kohta, seda nii projekti hetkeseisu hindamise kui ka hilisema, mitme projekti andmete p~ohjal koostatud üldisema analüüsi koostamise eesmärgil. Näiteks kasutatakse kosmosesüstiku lennutarkvara, mida küllaltki sagedasti täiendatakse, lennuvalmiduse kontrollimisel tarkvara veakindluse hindamiseks statistilisi projektsioone, mis koostatakse eelnevalt testimisel avastatud vigade andmestikust lähtudes. Täpsemalt peavad tarkvara kvalitseerumiseks olema täidetud kaks kriteeriumi.[5] Järelejäänud vigade arv peab olema väiksem kui üks (siinkohal tuleks r~ohutada, et tegu on prognoosiga, mis tehakse avastatud vigadest lähtudes, seega ei ennusta mudel sellist tüüpi vigu, mida varem tarkvaras leitud ei ole. Oletatav aeg järgmise vea tekkeni peab lennuk~olbulikkuse saavutamiseks olema suurem planeeritava missiooni kestvusest (süstikul umbes 8 päeva). 3 V~ordlus RUP ja XP-ga Käesoleva peatüki eesmärgiks on k~orvutada SEL metodoloogia p~ohiomadusi üldkasutuslike tarkvaraarenduse metodoloogiatega. Täpsemalt v~orreldakse SEL'i 5

6 ühe traditsionaalse (RUP) ning ühe väleda (XP) tarkvaraarendusmetodoloogiaga. 3.1 RUP Rational Unied Process'i metodoloogiate raamistikku v~oib esmapilgul SEL metodoloogiaga vägagi sarnaseks pidada. M~olemad metodoloogiad jaotavad tarkvaraarenduse suuremahulistesks etappideks (disain-implementatsioon-testimine/juurutamine) ning m~olemad kirjeldavad suurel hulgal erinevaid formaalseid dokumente (SEL: Software Requirements Review, RUP: Software Architecture Document ). V~ottes ette RUP'i ja SEL'i tarkvaraarenduse etapid k~oige üldisemal tasemel, on nende vahel v~oimalik tekitada küllaltki hea funktsionaalne vastavus. RUP SEL Inception Requirements denition, Requirements analysis Elaboration Preliminary design, Detailed design Implementation Implementation Integration System testing, Acceptance testing Tabel 1: RUP'i ja SEL'i tarkvaraarenduse etappide vastavus. Joonis 1: RUP'i hinnang tarkvaraprojekti inimressursside jaotumisele erinevate faaside vahel. Allikas: RUP.[6] P~ohiline kahe metodoloogia vaheline erinevus ilmneb nende poolt erinevatele etappidele kuluvate ressursside (aeg, inimesed) v~ordlemisel. Kui RUP'is kulub enamus ressurssidest implementatsioonile, siis SEL'is on ressursid praktiliselt v~ordselt jaotunud analüüsi-, disaini-, implementatsioonining kahele erinevat tüüpi testifaasi vahel. Väga üldistavalt öeldes: kui RUP'i strateegilised m~o~odud (disain-implementatsioon-testimine/juurutus) on , siis SEL'i strateegilised m~o~odud on

7 Joonis 2: Ressursside jaotus erinevatele tarkvaraarenduse faasidele. Allikas: SEL'i statistika.[9] 3.2 XP Esmapilgul vaadates v~oib tunduda, et SEL ja XP on teineteisele täiesti vasturääkivad metodoloogiad. Esimest kasutatakse üldjuhul ülikeerukatel matemaatilistel arvutustel baseeruvates reaalajasüsteemides, mida disainitakse aastaid (v~oi isegi aastakümneid), teine on aga kasutusel peamiselt ärirakendustes, mis on üldjuhul kasutatavate algoritmide poolest küllaltki lihtsad, kuid teisalt jällegi peavad kliendi n~oudmisel olema väga kiiresti muudetavad. XP ja SEL'i lähemaks v~ordluseks on otstarbekas vaadelda XP kodulehel välja toodud antud metodoloogia p~ohit~odesid[11], k~orvutades neid ükshaaval SEL metodoloogia seisukohtadega. Planning User stories are written. Kasutajaloo (use case) terminit SEL'i metodoloogias ei ole. Süsteemi disain algab üldjuhul komosemissiooni kirjeldusest. Release planning creates the schedule. SEL ühtib XP'ga selles m~ottes, et erinevatele tegevustele kuluv aeg peab olema v~oimalikult täpselt ette planeeritud. (Kuid SEL teeb seda planeerimist tunduvalt kaugemale.) 7

8 Make frequent small releases. SEL ja XP lähevad siin vastuollu - esimese implementatsioonifaasis on soovituslik aeg kahe build'i vahel kolm kuni viis kuud. SEL'i lähenemise eelis seisneb siin selles, et pikkade ajavahemike tagant kirjutatava koodi kokkupanemine tingib programmeerijate disainidokumendile truuks jäämise. The Project Velocity is measured. SEL kogub XP'st tunduvalt rohkem erinevat statistikat. The project is divided into iterations. SEL läheneb sellele teist moodi: k~oigepealt toimub ikkagi analüüs, siis disain, implementeerimine ja testimine (samal ajal kui XP's sisaldab iga iteratsioon nii analüüsi, disaini, implementeerimist kui ka testimist). Iteration planning starts each iteration. SEL'is ei ole XP m~ottes iteratsiooni m~oistet. Move people around. SEL r~ohutab küll erinevate gruppide vahelise koostöö vajadust, aga - v~oib spekuleerida et programmeeritava süsteemi tehnilisest keerukusest tingituna - ei soovitata inimesi väga kaootiliselt ühelt ülesandelt teisele ringi t~osta - näiteks näiteks kosmoselaeva orbiidi arvutamisega tegeleva koodi ülevaatuse teeb ikkagi vastava valdkonnaga tuttav olev inimene. A stand-up meeting starts each day. SEL ei sea formaalset n~ouet iga päeva alustamiseks koosolekuga. Fix XP when it breaks. SEL on antud juhul tunduvalt kitsama rakendusalaga metodoloogia kui XP. Designing Simplicity. V~oimalikult lihtne disain on igasuguse ehitamise aluseks. Choose a system metaphor. SEL'i jaoks on antud kontseptsioon täiesti tundmatu. Use CRC cards for design sessions. SEL ei kasuta CRC kaarte (ning ei kasuta tihtipeale ka üldse objektorienteeritud disaini). Create spike solutions to reduce risk. Prototüüpide kasutamine on SEL'is ja CP's küllaltki sarnane. No functionality is added early. SEL'is implementeeritakse ainult see funktsionaalsus mis on disainidokumendis kindlaks määratud. 8

9 Refactor whenever and wherever possible SEL ei soosi refaktoreerimist, kui potensiaalset vigade tekitamise allikat. Lisaks sellele peaks SEL'i XP'st Coding tunduvalt p~ohjalikum disainifaas elimineerima enamiku juhtumitest, kus refaktoreerimist vaja läheb. The customer is always available. SEL'is on erinevaid etappe l~opetavatel ülevaatustel praktiliselt alati olemas ka kliendi esindaja. Code must be written to agreed standards. Siinkohal SEL ja XP ühtivad. Code the unit test rst. SEL'is genereeritakse testid paralleelselt implementeerimisega ning eraldi meeskonna poolt. All production code is pair programmed. SEL ei kasuta paarisprogrammeerimist. Only one pair integrates code at a time. SEL antud piirangut ei sea. Integrate often. SEL soovitab pigem koodi harva kokku panna ja integreerida. Use collective code ownership. Ka SEL kasutab kollektiivse koodi m~oistet. Leave optimization till last. SEL'is on süsteemi töökiirust juba disainifaasis piisavalt hästi hinnatud. No overtime. SEL ei soosi samuti ületundide tegemist. Testing All code must have unit tests. SEL n~ouab lisaks testidele ka koodiülevaatuste tegemist. All code must pass all unit tests before it can be released. SEL'is kasutatakse lisaks testide läbimise kriteeriumile veel ka testide koodiülevaatust ning statistilisi mudeleid programmi töökindluse hindamiseks. When a bug is found tests are created. SEL läheb kaugemale, n~oudes ka vea tekkimise p~ohjuse k~orvaldamist ning selle dokumenteerimist. Acceptance tests are run often and the score is published. Juurutustestide jaoks on SEL'is eraldi faasi, st juurutusteste jooksutatakse SEL'is alles pärast implementatsioonifaasi ning süsteemitestimise l~oppu. 9

10 Seega - hoolimata XP' ja SEL'i näilisest erinevusest kasutavad need kaks metodoloogiat küllaltki paljudes punktides vägagi sarnast lähenemist (projekti edasiminekute täpne jälgmine, testimise olulisus). 4 Kokkuv~ote Kokkuv~ottes v~oib öelda et SEL'i poolt ülik~orge töökindlusega tarkvara kirjutamise käigus välja töötatud tarkvaraarendusmetodoloogia vastandub küllaltki paljudes aspektides tänapäeva ärirakendustest kasutatavatele metodoloogiatele, mis r~ohutavad küll korrektse koodi kirjutamist ja testimist, kuid seavad pigem tahaplaanile p~ohjaliku analüüsi ja disaini (p~ohjendades seda n~ouete pidevast muutumisest tingitud raskustega disaini kseerimisel). Siinkohal on otstarbekas pakkuda edasist m~otlemisainet, meenutades sissejuhatuses tehtud märkusi tänapäevaste üldkasutuslike arvutiprogrammide töökiiruse kohta ning tuua esile veel m~oningad tarkvaraarenduse kitsaskohad, mida vähemalt osaliselt v~oib modernsete tarkvaraarendusmetodoloogiate ning - vahendite kaela ajada: Eclipse kui MI teaduskonna programmeerimise p~ohikursustel poolkohustuslik töövahend töötab tänapäevasel gigahertsise protsessori ja poolegigabaidise mäluga arvutil programmi teksti redigeerimisel aeglasemalt kui kümme aastat tagasi alla 10-megahertsise protsessoril kasutatud QBasic'u redaktor (kusjuures m~olemad kontrollivad reaalajas kirjutatava koodi süntaksit!). Korporatsiooni kassasüsteemi disainimisel peetakse küll vajalikuks deneerida eraldi seitsmest klassist koosnev süsteem väga keeruliste allahindlusreeglite arvutamiseks, kuid nende reeglite juurde kuuluvate ajal~oikude korrektsust (ehk siis samasid kaupu kirjeldavate reeglite ajalist mittekattuvust) kontrolliva algoritmi implementeerimisel soovitatakse kasutada O(n 2 )-keerukusega brute-force-v~ordlust. Eeldades et neid ajavahemikke on m~one aja pärast näiteks paarsada tuhat, sest korporatsioonist on vahepeal saanud kaubamaja, kus neid allahindlusreegleid ka kasutatakse, on täiesti ilmne, miks ühel ilusal programmi uuestikäivitamist sisaldaval päeval kassasüsteem reeglistiku sisselugemisel pikemaks ajaks hangub... Referaadi l~opetuseks pakun välja m~onev~orra ketserliku idee, et digitaalsüsteemide järjest laiema rakendamise t~ottu erinevates masinates (alates autodest l~opetades rösteritega) v~oib peatselt ennustada SEL'i taoliste väga k~orge töökindlusega tarkvara tootvate kuid samas ka tarkvaraarendajatelt ranget distsiplineeritust n~oudvate metodoloogiate renessanssi ehk siis tunduvalt laiemat kasutuselev~otmist. 10

11 Viited [1] Charles Fishman. The Write The Right Stu. Fast Company, issue 6 dec 1996/jan 1997, p (viimati väisatud ) [2] Footprints on The Moon - About the Apollo Computers. Australian Broadcasting Corporation's Gateway to Science. (viimati väisatud ) [3] NASA. NSSDC Master Catalog Display: Spacecraft - Mariner 1. (viimati väisatud ) [4] NASA. NSSDC Master Catalog Display: Spacecraft - Mars Climate Orbiter. (viimati väisatud ) [5] Norman F. Schneidewind. Application of SRE to Ultrareliable Systems. The Department of Defence Software Tech News, vol. 1 December (viimati väisatud ) [6] Rational Software Corporation. Rational Unied Proccess (viimati väisatud ) [7] SEL. Manager's Handbook for Software Development, Revision 1. Software Engineering Laboratory Series, november (viimati väisatud ) [8] SEL. NASA Software Engineering Laboratory. (viimati väisatud ) [9] SEL. Recommended Approach to Software Development. Software Engineering Laboratory Series. juuni (viimati väisatud ) [10] Statistical Software Engineering. Panel on Statistical Methods in Software Engineering, National Research Counc l. 84 pages, (viimati väisatud ) 11

12 [11] J. Donovan Wells. Extreme Programming Rules. (viimati väisatud ) 12