Ihmisille kilpailukykyiset korjaustiedostot automaattisessa ohjelmankorjauksessa Repairnatorilla

Repairnator on botti. Se tarkkailee jatkuvasti avoimen lähdekoodin ohjelmistojen jatkuvan integroinnin aikana löydettyjä ohjelmistovirheitä ja yrittää korjata ne automaattisesti. Jos onnistutaan syntetisoimaan voimassa oleva laastari, Repairnator ehdottaa laastaria ihmiskehittäjille, naamioituna väärin ihmisen identiteettiin. Tähän päivään mennessä Repairnator on pystynyt tuottamaan 5 korjausta, jotka ihmiskehittäjät ovat hyväksyneet ja sulautetut pysyvästi koodikantaan. Tämä on virstanpylväs ihmisen kilpailukyvylle ohjelmistojen suunnittelututkimuksessa automaattista ohjelmien korjausta varten. Tässä viestissä kerromme tarinan tästä tutkimuksesta, joka tehtiin KTH: n kuninkaallisessa teknologiainstituutissa, Inriassa, Lillen yliopistossa ja Valenciennesin yliopistossa.

Ohjelmien korjaustutkimuksella pyritään siihen ajatukseen, että algoritmit voivat korvata ihmisen ohjelmistovirheiden korjaamiseksi [4]. Virheenkorjaus on korjaustiedosto, joka lisää, poistaa tai muuttaa lähdekoodia. Esimerkiksi seuraavassa korjaustiedostossa kehittäjä on muuttanut if-lauseen ehtoa:

- jos (x <10)
+ jos (x <= 10)
foo ();

Ohjelman korjausobotti on keinotekoinen agentti, joka yrittää syntetisoida lähdekoodipaikkauksia. Se analysoi virheet ja tuottaa korjauksia, samoin kuin ohjelmistojen ylläpidossa mukana olevat ihmiskehittäjät. Tämä ajatus ohjelman korjausobotista on häiritsevä, koska nykyään ihmiset ovat vastuussa virheiden korjaamisesta. Toisin sanoen, puhumme robotista, joka on tarkoitettu (osittain) korvaamaan ihmiskehittäjät työläisissä tehtävissä.

Kun robotti yrittää saavuttaa yleensä ihmisten suorittaman tehtävän, se tunnetaan ihmisten kilpailutehtävänä [1]. Ohjelmien korjaustutkimuksen empiiriset arvioinnit [3] osoittavat, että nykyiset ohjelman korjausjärjestelmät kykenevät syntetisoimaan korjauksia todellisiin virheisiin todellisissa ohjelmissa. Kuitenkin kaikki nämä laastarit syntetisoitiin aikaisempien virheiden varalta, ja virheiden osalta, jotka ihmiskehittäjät ovat korvanneet aiemmin, yleensä vuosia sitten. Vaikka tämä osoittaa ohjelman korjausten teknisen toteutettavuuden, tämä ei osoita, että ohjelman korjaus on ihmisten kilpailukykyinen.

Human-kilpailukyky

Osoittaakseen, että ohjelman korjaus on ihmisen kilpailukykyinen, ohjelman korjausohjelman on löydettävä korkealaatuinen korjaustiedosto ennen kuin ihminen tekee niin. Tässä yhteydessä laastaria voidaan pitää ihmisen kilpailukykyisenä, jos se täyttää kaksi ajantasaisuuden ja laadun edellytystä. Ajantasaisuus viittaa siihen, että järjestelmän on löydettävä korjaustiedosto ennen ihmisen kehittäjää. Toisin sanoen prototyyppijärjestelmän on tuotettava laikkuja minuuttien suuruusluokassa, ei päivissä. Lisäksi robotin tuottaman laastarin on oltava riittävän oikea, laadultaan samanlainen - oikein ja luettavissa - verrattuna ihmisen kirjoittamaan laastariin. Huomaa, että on joitain korjaustiedostoja, jotka näyttävät botin kannalta oikeilta, mutta jotka ovat vääriä (tätä kutsutaan kirjallisuudessa liian sopiviksi laastariksi [6, 3]). Nämä laastarit eivät väitetysti ole kilpailukykyisiä ihmisille, koska ihmiset eivät koskaan hyväksy niitä koodikannassaan.

Seurauksena on, että laastari on ihmisille kilpailukykyinen 1) botin on syntetisoitava laastari nopeammin kuin ihmisen kehittäjä 2) ihmisen kehittäjä on arvioinut laastarin tarpeeksi hyväksi ja sulautettava pysyvästi koodikantaan.

On otettava huomioon vielä yksi näkökohta. On osoitettu, että ihmisen insinöörit eivät hyväksy robottiosuuksia yhtä helposti kuin muiden ihmisten osuuksia, vaikka ne olisivat täysin identtisiä [5]. Syynä on, että ihmisillä on yleensä ennakkoluulottomuutta koneita vastaan ​​ja he suvaitsevat virheitä, jos panos tulee ihmisen vertaistuksesta. Ohjelmien korjaamisen yhteydessä tämä tarkoittaa, että kehittäjät saattavat nostaa korjauslaatun laadun korkeammalle tasolle, jos he tietävät, että korjaus tulee botista. Tämä estäisi pyrkimyksiämme todistaa ihmisten kilpailukyky ohjelmien korjaamisen yhteydessä.

Tämän ongelman ratkaisemiseksi olemme päättäneet jo projektin varhaisessa vaiheessa, että kaikki Repairnator-korjaukset ehdotetaan väärin ihmisen identiteetin alle. Olemme luoneet GitHub-käyttäjän, nimeltään Luc Esape, joka esitellään ohjelmistosuunnittelijana tutkimuslaboratoriossa. Lucilla on profiilikuva ja hän näyttää nuoremmalta kehittäjältä, joka haluaa tehdä avoimen lähdekoodin kommentteja GitHubissa. Kuvittele nyt Repairnator, naamioituneena siitä, että Luc Esape ehdottaa korjaustiedostoa: sitä tarkistava kehittäjä uskoo tarkistavansa ihmisen panosta. Tämä naamiointi vaaditaan tieteellisen hypoteesin testaamiseksi ihmisen kilpailukyvystä. Nyt etiikan vuoksi Lucin todellinen henkilöllisyys on paljastettu jokaisessa hänen vetämispyynnössään.

Automaattinen korjaus ja jatkuva integrointi

Jatkuva integraatio, eli CI, on ajatus, että palvelin kokoaa koodin ja suorittaa kaikki testit jokaiselle ohjelmistoprojektin (esim. Git) versionhallintajärjestelmässä tehdylle sitoumukselle. CI-kielenkäytössä jokaiselle sitoumukselle on rakennus. Kokoonpano sisältää tiedot käytetystä lähdekoodin tilannekuvasta (esim. Viittaus Git-toimeksiantoon), kokoamisen ja testin suorittamisen tuloksesta (esim. Epäonnistuminen tai onnistuminen) sekä suorituksen jäljitysloki. Kokoonpanon sanotaan epäonnistuvan, jos kokoaminen epäonnistuu tai ainakin yksi testitapaus epäonnistuu. On osoitettu, että noin yksi neljästä rakennuksesta epäonnistuu ja että yleisin syy rakennusvirheeseen on testihäiriö [8].

Repairnatorin keskeinen ajatus on luoda automaattisesti korjaustiedostoja, jotka korjaavat rakennusvirheitä, ja näyttää ne sitten ihmiskehittäjille, jotta nähdään lopulta, hyväksyisivätkö nämä ihmiskehittäjät ne kelvollisina panoksina koodikantaan. Jos näin tapahtuu, se olisi todiste ihmisten kilpailukyvystä ohjelman korjauksessa.

Tämä asennus - jatkuvassa integroinnissa tapahtuvien rakennusvikojen automaattinen korjaus - on erityisen sopiva ja ajankohtainen seuraavista syistä. Ensinnäkin rakennusvirheet tyydyttävät testisarjapohjaisen ohjelmakorjauksen [4] ydinongelman, jossa virheet määritetään epäonnistuneiksi testitapauksiksi ja niitä epäonnistuneita testitapauksia käytetään ohjaamaan korjaustiedoston automatisoitua synteesiä [4]. Toiseksi se antaa mahdollisuuden vertailla robotteja ja ihmisiä tasapuolisesti: kun jatkuvassa integraatiopalvelimessa löydetään epäonnistunut testi, ihmisen kehittäjälle ja robottille ilmoitetaan siitä samanaikaisesti. Tämä testivirheilmoitus on lähtökohta ihmisen ja robotin kilpailulle.

Repairnatorin keskittyminen rakennusvirheisiin on ainutlaatuinen, mutta se sopii ohjelmistojen älykkäiden robottiohjelmien kokonaiskuvaan [2]. Esimerkiksi Facebookilla on SapFix-niminen työkalu, joka korjaa automaattisella testauksella löydetyt virheet. Aiheeseen liittyvät myös DARPA Cyber ​​Grand Challengen bot-hyökkääjät ja puolustajat yrittävät olla ihmisen kilpailukykyisiä turvallisuusasiantuntijoiden suhteen.

Repairnator pähkinänkuoressa

Olemme suunnitelleet, toteuttaneet ja käyttäneet vuosina 2017–2018 Repairnatoria, robotin automaattiseen ohjelmankorjaukseen. Repairnator on erikoistunut jatkuvan integroinnin aikana tapahtuvien rakennusvikojen korjaamiseen. Se tarkkailee jatkuvasti tuhansia sitoutuneita yrityksiä, jotka työnnetään GitHub-koodin isäntäalustaan, ja analysoi niiden vastaavia rakenteita. Joka minuutti se käynnistää uusia korjausyrityksiä virheiden korjaamiseksi ennen ihmisen kehittäjää. Se on suunniteltu kulkemaan mahdollisimman nopeasti, koska se osallistuu kilpailuun: jos Repairnator löytää korjaustiedoston ennen ihmisen kehittäjää, se on ihmisille kilpailukykyinen.

Annetaan nyt yleiskuva siitä, kuinka Repairnator-botti toimii.

Repairnatorin ensisijainen panos on jatkuva integrointi, joka käynnistyy kehittäjien tekemissä sitoumuksissa (kuvan yläosa, (a) ja (b)), jotka perustuvat GitHub-projekteihin (a). Repairnatorin lähdöt ovat kaksinkertaiset: (1) se tuottaa automaattisesti korjaustiedostoja virheellisten rakennusten (g) korjaamiseksi, jos sellaisia ​​on; (2) se kerää arvokasta tietoa tulevia ohjelmien korjaustutkimuksia varten (h) ja (k). Repairnator tarkkailee jatkuvasti kaikkia jatkuvia toimia GitHub-projektien © kautta. CI-rakennukset annetaan tulona kolmivaiheiseen putkilinjaan: (1) ensimmäinen vaihe kerää ja analysoi CI-rakennuslokeja (e); (2) toisen vaiheen tarkoituksena on toistaa paikallisesti CI (f): ssa tapahtuneet rakennusviat; (3) kolmannessa vaiheessa suoritetaan erilaisia ​​ohjelmien korjausprototyyppejä, jotka ovat peräisin viimeisimmästä akateemisesta tutkimuksesta. Kun korjaustiedosto löytyy, Repairnator-projektin jäsen suorittaa nopean terveellisyystarkistuksen välttääksesi avoimen lähdekoodin kehittäjien arvokkaan ajan tuhlaamista. (i) Jos hän löytää korjaustiedoston hajoamattomana, hän ehdottaa sitä sitten hankkeen alkuperäisille kehittäjille veto-pyynnönä GitHubille (j). Kehittäjät seuraavat sitten tavanomaista koodin tarkistusprosessiaan ja yhdistävät.

Repairnatorin on toimittava tietyssä ohjelmistoekosysteemissä. Aikaisemmissa tutkimusprojekteissa olevan Java-asiantuntemuksemme ansiosta Repairnatorin prototyyppitoteutus keskittyy Java-ohjelmointikielellä kirjoitettujen ohjelmistojen, jotka on rakennettu Maven-työkaluketjulla, korjaamiseen avoimen lähdekoodin projekteissa, joita ylläpidetään GitHubissa, jotka käyttävät Travis CI: n jatkuvaa integrointialustaa. .

Retkikunnan saavutukset

Olemme toimineet Repairnatorilla tammikuusta 2017 lähtien kolmessa eri vaiheessa. Yhden kuukauden aikana, tammikuussa 2017, suoritimme pilottikokeen prototyypin alkuperäisen version kanssa. 1. helmikuuta 2017 - 31. joulukuuta 2017 meille järjestettiin Repairnator, jolla oli kiinteä luettelo 14 188 projektista, jota kutsumme nimellä “Expedition # 1”. 1. tammikuuta 2018 - 30. kesäkuuta 2018 Repairnator on seurannut Travis CI: n rakennusvirtaa reaaliajassa, kutsumme sitä “Expedition # 2”

Pilottikokeen päätavoite oli vahvistaa suunnittelu ja alustava toteutus. Havaitsimme, että prototyyppimme pystyy suorittamaan noin 30 korjausyritystä päivässä, kun otetaan huomioon laskentaresurssit. Vielä tärkeämpää on, että tämä kokeilu validoi keskeiset teknologiset oletuksemme: merkittävä osa suosituista avoimen lähdekoodin projekteista käyttää Travisia ja suurin osa heistä käyttää Mavenia rakennusteknologiana. Tämä tarkoitti, että meillä olisi kohtuulliset mahdollisuudet saavuttaa tavoitteemme syntetisoida ihmisille kilpailukykyinen laastari tässä yhteydessä.

Expedition # 1: n aikana, jonka tulokset on esitetty yksityiskohtaisesti kohdassa [7], Repairnator on analysoinut 11 523 rakennusta testivirheiden kanssa. Heistä 3551 (30,82%) Repairnator pystyi toistamaan testivirheen paikallisesti. 3 551 korjausyrityksestä Repairnator löysi 15 laastaria, jotka saattoivat tehdä CI: n rakennuksen läpäiseväksi. Paikkausanalyysimme paljasti kuitenkin, että mikään noista laastarista ei ollut kilpailukykyinen ihmisille, koska ne tulivat liian myöhään (Repairnator tuotti laastarin ihmisen kehittäjän jälkeen) tai olivat heikkolaatuisia (ne tekivät rakennuksen onnistuneesta sattumalta).

Retkikunta # 2 on onnistunut. Se on osoittanut, että ohjelmien korjaustekniikka on ylittänyt ihmisten kilpailukyvyn rajan. Repairnator on tuottanut 5 laastaria, jotka täyttävät yllä määritellyt ihmisten kilpailukyvyn kriteerit: 1) laastarit on valmistettu ennen ihmisille asetettuja parannuksia, 2) ihmisen kehittäjä hyväksyi laastarit pätevinä panoksina ja korjaukset sulautettiin pääkoodikantaan.

Ihmisten kilpailukykyinen osallistuminen Githubiin, korjaustiedostot, jotka on syntetisoitu Repairnator-robotista ja jotka ihmisen kehittäjä on hyväksynyt:

  • 12. tammikuuta 2018, aaime / geowebcache / pull / 1, “Kiitos laastarista!”
  • 23. maaliskuuta 2018, parkito / BasicDataCodeU […] / pull / 3 “yhdistettiin sitoutumaan 140a3e3 osaksi parkito: kehitä”
  • 5. huhtikuuta 2018, dkarv / jdcallgraph / pull / 2 “Kiitos!”
  • 3. toukokuuta 2018, eclipse / ditto / pull / 151 “Viileä, kiitos Eclipse-prosessin läpikäynnistä ja korjauksesta.”
  • 25. kesäkuuta 2018, donnelldebnam / CodeU […] / pull / 151 “Kiitos !!”

Ihmiskehittäjä hyväksyi ensimmäisen korjaustiedoston, jonka ohjelmistokorjausbotti yhdisti, 12. tammikuuta 2018. Tässä on tarina: 12. tammikuuta 2018 kello 12:28 rakennus käynnistettiin projekti aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Kokoonpano epäonnistui 2 minuutin suorituksen jälkeen, koska kaksi testitapausta oli erehdyksessä. Neljäkymmentä minuuttia myöhemmin, 12. tammikuuta 2018 kello 13:08, Repairnator havaitsi viallisen rakennuksen säännöllisen seurannan aikana ja aloitti käytettävissä olevien ohjelmankorjausjärjestelmien suorittamisen, jotka on määritetty Repairnatorissa. Kymmenen minuuttia myöhemmin, kello 13.18, se löysi korjaustiedoston.

Repairnator-tiimin jäsen otti 12. tammikuuta 2018 kello 13.35 Repairnatorin luoman korjaustiedoston ja validoi vastaavan veto-pyynnön avaamisen GitHubissa. Kehittäjä hyväksyi korjaustiedoston 12. tammikuuta 2018 kello 14:10 ja yhdisti sen kommenttiin: ”Oudon, ajattelin jo korjasi tämän… ehkä tein jonkun muun paikan. Kiitos laastarista! ”. Se oli ensimmäinen Repairnatorin tuottama korjaus, joka hyväksyttiin ihmiskehittäjän kelvolliseksi panokseksi ja sulautettiin lopullisesti koodikantaan. Toisin sanoen Repairnator oli ensimmäistä kertaa kilpailukykyinen ihmisille.

Vielä 6 kuukauden käytön jälkeen Repairnatorilla on ollut 5 yllä mainittua ihmisen kehittäjän yhdistämää laastaria.

Kaiken kaikkiaan Repairnator-projekti on suorittanut tehtävänsä täydellisesti. Se on osoittanut, että ohjelman korjaamista voidaan pitää ihmisen kilpailukykyisenä: Repairnator on löytänyt laastarit 1) ennen ihmisiä, 2) jotka ihmiset ovat itse pitäneet hyvälaatuisina.

Tulevaisuus

Sen lisäksi, että Repairnator-projekti on osoittanut, että ohjelman korjaus on ihmisten kilpailukykyinen, se on tarjonnut runsaasti tietoa virheistä ja jatkuvasta integroinnista sekä nykyisistä ohjelman korjaustutkimuksen puutteista, esitetty [7].

Pitäkäämme mielessä erityisesti yksi kohta, henkisen omaisuuden kysymys. 3. toukokuuta 2018 Repairnator tuotti hyvän korjaustiedoston GitHub-projektiin eclipse / ditto. Pian sen jälkeen, kun oli ehdottanut korjaustiedostoa, yksi kehittäjistä kysyi: "Voimme hyväksyä vain vetäytymispyynnöt, jotka ovat peräisin käyttäjiltä, ​​jotka ovat allekirjoittaneet Eclipse Foundationin avustajan lisenssisopimuksen." Olimme hämmästyneitä, koska robotti ei voi fyysisesti tai moraalisesti allekirjoittaa lisenssisopimusta, eikä sillä todennäköisesti ole oikeutta siihen. Kuka omistaa bot-panoksen immateriaalioikeudet ja vastuun: robottioperaattori, bot-toteuttaja tai korjausalgoritmin suunnittelija? Tämä on yksi mielenkiintoisista kysymyksistä, jotka Repairnator-projekti paljasti.

Uskomme, että Repairnator määrittelee tietyn ohjelmistokehityksen tulevaisuuden, jossa robotit ja ihmiset tekevät sujuvaa yhteistyötä ja jopa yhteistyötä ohjelmistoesineissä.

Haluatko liittyä Repairnator-yhteisöön? Jos haluat saada säännöllisiä uutisia Repairnatorista, ampu sähköpostia osoitteeseen repairnator.subscribe@4open.science!

- Martin Monperrus, Simon Urli, Thomas Durieux, Matias Martinez, Benoit Baudry, Lionel Seinturier

Mediassa:

  • Salaperäinen elämä Luc Esapelle, virheenkorjaajalle. Hänen iso salaisuutensa? Hän ei ole ihminen (Thomas Claburn, The Register)

Viitteet

  • [1] J. R. Koza (2010) Geneettisen ohjelmoinnin tuottamat tulokset ihmisten kilpailusta. Geneettinen ohjelmointi ja kehittyvät koneet 11 (3–4), s. 251–284. Lainaus:.
  • [2] C. Lebeuf, M. D. Storey ja A. Zagalsky (2018) Ohjelmistobotit. IEEE-ohjelmisto 35, s. 18–23. Lainaus: Automaattinen korjaus ja jatkuva integrointi.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan ja M. Monperrus (2016) Java-sovelluksen todellisten virheiden automaattinen korjaus: laaja kokeilu vikojen4j-tietojoukossa. Empiirinen ohjelmistosuunnittelu, s. 1–29. Viittaukset: Ihmisten kilpailukyky,.
  • [4] M. Monperrus (2017) Automaattinen ohjelmistojen korjaus: Bibliografia. ACM-tietokoneetutkimukset. Viittaa: Automaattinen korjaus ja jatkuva integrointi,.
  • [5] A. Murgia, D. Janssens, S. Demeyer ja B. Vasilescu (2016) Koneiden joukossa: Ihmisen ja robotin välinen vuorovaikutus sosiaalisissa kysymyksissä ja verkkosivustoilla. Vuoden 2016 CHI-konferenssin jatko-osissa tietojärjestelmien inhimillisiä tekijöitä, s. 1272–1279. Viittaukset: Ihmisen kilpailukyky.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues ja Y. Brun (2015) Onko parannuskeino huonompi kuin tauti? ylimääräinen asennus automaattisessa ohjelman korjauksessa. Ohjelmistotekniikan perusteita käsittelevän kymmenennentoista vuoden 2015 yhteisen kokouksen vuonna 2015 julkaisussa, s. 532–543. Ulkoiset linkit: Viittaus asiakirjaan: Ihmisen kilpailukyky.
  • [7] S. Urli, Z. Yu, L. Seinturier ja M. Monperrus (2018) Kuinka suunnitella ohjelman korjausohjelma? Näkemyksiä Repairnator-projektista. ICSE 2018–40: n kansainvälisessä ohjelmistosuunnittelukonferenssissa, Ohjelmistotekniikan seuraaminen käytännössä, Ulkoiset linkit: Linkki: Lähettäjä: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta ja S. Panichella (2017) Tarina CI: n rakennusvirheistä: avoimen lähdekoodin ja rahoitusorganisaation näkökulma. Kansainvälisessä ohjelmistojen ylläpidon ja kehityksen konferenssissa, lainaus: Automaattinen korjaus ja jatkuva integrointi.