Selvitys automaattisen staattisen sääntöpohjaisen Wicket-React migraatiotyökalun kannattavuudesta Wicketistä Reactiin siirryttäessä

Abstract

Tässä työssä selvitetään automaattisen staattiseen analyysiin perustuvan sääntöpohjaisen Wicket-React migraatiotyökalun kannattavuutta. Staattinen analyysi tarkoittaa työkalun analysoivan lähdekoodia esimerkiksi lopputuloksen analysoimisen sijasta. Sääntöpohjaisuus tarkoittaa työkalun toteutuksen olevan jaettu pienempiin toisistaan riippumattomiin osatoteutuksiin, eli sääntöihin, joita voidaan kehittää lisää tarpeen mukaan. Tämä selvitys tapahtuu toteuttamalla käännöstyökalun runko ja esimerkkisääntöjä päivittämään Cinia OY:n Kardio-sydäntietojärjestelmää Wicketistä Reactiksi. Työkalun toteutus jakautuu kolmeen keskeiseen osaan: staattisesti lähdekoodia analysoivaan osaan, sääntöluokkiin ja lopuksi React-koodia kirjoittavaan osaan. Työn aikana kehitettiin kolmea sääntöä. Ensimmäiset kaksi sääntöä käsittelivät erilaisia Label-elementtejä. Ensimmäiseen näistä kului alle henkilötyöpäivä ja se korvasi 627 Label-elementtiä 1264:stä. Toisen toteutukseen kului puolikas henkilötyöpäivä ja se korvasi 167 elementtiä lisää. Viimeinen sääntö vaatii vielä jatkokehitystä, mutta se on tarpeeksi pitkällä havaintojen tekemiseksi. Säännön kehitykseen tulee kulumaan arviolta viisi henkilötyöpäivää ja se korvaa 360 pudotusvalikkoelementtiä 991:stä. Lopuksi arvioidaan automaattisen tavan tehokkuutta manuaaliseen verrattuna. Yksittäisen Label-elementin kääntämiseen kuluu arviolta kolmesta viiteen minuuttia manuaalisella tavalla. Yhteensä 794 elementtiin kuluisi siis viidestä ja puolesta henkilötyöpäivästä yhdeksään ja puoleen henkilötyöpäivään henkilötyöpäivän ollessa seitsemän työtuntia. Tämä on huomattavasti pidempään kuin sääntöjen kirjoittamiseen kului, mutta toisaalta automaattinen tapa vaatii myös huomattavan määrän työtä työkalun rungon suunnitteluun ja toteutukseen. Ainakin Kardion tapauksessa automaattinen tapa vaikuttaa kuitenkin myös kokonaisuutena paremmalta. Käännettävän projektin koko vaikuttaa siis siihen, että kuinka kannattavaa käännös on tehdä automaattisella tavalla. Label-sääntöjen tapauksessa automaattinen ja manuaalinen tapa olisivat yhtä tehokkaita, jos 84–150 elementtiä korvaavan säännön toteuttamiseen kuluisi automaattisella tavalla päivä ja manuaalisella tavalla kolmesta viiteen minuuttia per elementti. Mikäli työkalun rungon suunnitteluun ja toteutukseen kuluisi 30 henkilötyöpäivää, niin 30 toteutettavan säännön pitäisi kunkin säästää henkilötyöpäivä. Lisäksi on hyvä muistaa, ettei kannata toteuttaa sääntöä, jonka toteuttamiseen menisi pidempään kuin korvattavien elementtien kääntämiseen kuluisi manuaalisesti. Tätä voi arvioida kääntämällä yhden esimerkkitapauksen manuaalisesti, selvittää tapausten lukumäärä ja lopuksi laskea kumpi tapa tulee olemaan kannattavampi kyseisessä tapauksessa.

The objective of this thesis is to study the feasibility of automatic rule-based Wicket to React migration tool which utilizes static migration strategy. Static migration strategy means analyzing the original source code rather than, for example, analyzing the compiled output. Rule-based means that the implementation of the tool is divided into smaller, independent parts called rules which can be added as needed. This study is conducted by implementing the base for a migration tool of this type along with rule examples to migrate Cinia LC’s.Kardio heart information system from Wicket to React. The implementation of the tool is divided into three main parts. The part responsible for static analysis of the source code, the rule classes, and finally the part that produces React code. During this thesis, three example rule classes were being developed. The first two rules handled different types of Label elements. First of the two was developed in under a man-day and it replaced 627 elements of the original 1264. Second was developed in half a man-day and replaced an additional 167 elements. The last rule still requires additional work but is mature enough to make observations about. This rule is estimated to require five man-days and it replaces 360 DropDown elements out of 991. Lastly, we can compare the merits of an automatic method versus the manual method. With a manual method, a single Label element was estimated to take three to five minutes to translate. A total of 794 elements would therefore take five and a half to nine and a half man-days, given that a man-day is 7 hours of work. This is significantly longer than the time taken to write the rules, but on the other hand the automatic method also requires additional time for designing and implementing the base of the tool. Nevertheless, at least in the case of Kardio the automatic method appears to be the better choice overall. So, the size of the project being migrated affects whether an automatic or manual method should be used. As an example, in the case of Label rule, the automatic and manual methods would be equally effective if a rule that took a day to write would handle 84 to 150 elements which would take three to five minutes each to translate manually. If the design and implementation of the base of the tool took 30 man-days, then naturally this would require 30 rules to save at least a man-day each. Additionally, it’s good to keep in mind that it would be less than efficient to implement a rule that takes longer to implement than the time it would take to manually translate the target elements. Which one would be faster can be estimated by translating one target element manually, estimating the number of target elements and then making an estimate on which method would be faster in that specific case.