RAZPRAVE B Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Marko Tekavc Marjan Heričko Univerza v Mariboru, Fakulteta za elektrotehniko računalništvo in informatiko, Inštitut za informatika (marko.tekavc. marjan.hericko)@uni mb.si Izvleček Preoblikovanje programske kode je proces spreminjanja programske kode na način, da se obnafianje sistema navzven ne spremeni, spremeni in izboljša pa se notranja struktura programskega sistema. Natančno definirani, preizkušeni in delno z orodji podprti pristopi k preoblikovanju se osredotočajo predvsem na odpravljanje slabo oblikovane kode ne pa tudi na to. kako identificirati takšno kodo v sistemu. Korak identifikacije slabo oblikovane kode in izbire ustreznega preoblikovanja ie tako v veliki meri odvisen od izkušeni razvi jalca V prispevku je predstavljen in ovrednoten na metrikah temelječ pristop k identifikaciji slabo oblikovane ob jektnc-crien tirane programske kode in smiselnih preoblikovanj Abstract Metric-Based Software Refactonng Refactonng is a process that changes software code in order to improve its structure while keeping its behavior unchanged. Current approaches and tools related to refactonng are mainly focused on the code-restructuring step The process of code identification is rarely addressed; therefore practitioners have to rely on their persona! experiences and professional judgment. In this paper the method of identifying bad code in object-oriented systems is presented and evaluated The proposed method is based on selected OG metrics. The method assists in the identification of code parts that require refactcring It also provides recommendations for adequate change. 1 Uvod Programski sistemi se zaradi prilagajanja spreminjajočemu se okolju, odpravljanja napak ali kakšnega drugega razloga med razvojem pa tudi v času uporabe velikokrat spreminjajo. Vsakršno spreminjanje sistema zahteva dobro razumevanje strukture sistema, velikokrat pa povzroči tudi vnos novih, neželenih napak. Zato je skozi celoten cikel razvoja programske opreme treba namenjati ustrezno pozornost skrbi za dobro strukturo programske kode. Prav preoblikovanja lahko pomagajo na poti da izboljšanja strukture in razumljivosti programske kode. Fowler v [1] natančno opisuje postopke in primere aplikacije preoblikovanj. Uporabnost in pridobitve procesa preohlikovanja programske kode v okoljih, ki uporabljajo ekstremno programiranje, pa predstavlja tudi {2}. Aplikacijo preoblikovanj ji.' dokaj enostavna, saj je treba v večini primerov le slediti natančno podanim postopkom. Nekatera preoblikovanja so definirana tako, da jih je bilo mogoče tudi avtomatizirati in so danes podprta v Številnih orodjih, Si' vedno pa obstaja teza v;i, ki je še posebej izrazita pri velikih sistemih, in sicer kako poiskati odgovore na vprašanje, kdaj tri kje je smiselno določena preoblikovanja aplicirati. Vpra- šanje je posebej zanimivo zaradi trditve, da nobena skupina metrik ne more nadomestiti človeške intuicije in subjektivnih zaznavanj pri ugotavljanju, katera preoblikovanja aplicirati in zakaj [I]. Skladno s tem se današnje raziskave na področju avtomatizacije preoblikovanj v glavnem ukvarjajo z apliciranjem preoblikovanj, nt' pa s problemom, kako v kodi identificirati mesta, kjer bi uporabili preoblikovanja. Naloga, kako locirati dele kode, primerne /a preoblikovanje, nikakor ni lahka, prav tako pa je zahtevna tudi naloga samodejne identifikacije preoblikovanja, s katerim bi tako identificirano kodo na najustreznejši način izboljšali. Prav to pa sta i/./iva, ki jih naslavljamo v pričujočem prispevku. Cilj raziskave je ugotoviti, v kolikšni meri si lahko pomagamo / metrikami kot orodjem za identifikacijo tako slabo oblikovane kode kot tudi preoblikovanj, ki bi odpravila takšno kodo. V raziskavi, ki smo jo opravili, smo poskusili zajeli kar se da širok nabor najbolj znanih in uporabljanih metrik za objektno-ori-en ti rane sisteme ter ugotoviti, katere izmed njih in na 30 ij p d u b n i INFORMATIKA 2007- '.li-vilkij 1 letnik XV Marko Te kave, Marjan Hit r ko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode kakšen način so primerne za identifikacijo slabo oblikovane kode. V razdelku poglavju so na kratko povzete bistvene značilnosti procesa preoblikovanja objektno orientiranih programskih sistemov. Sledi pregled sorodnih raziskav, kjer podrobneje predstavimo dva pristopa k samodejni identifikaciji slabo sirukturirane kode in smiselnih preoblikovanj. V četrtem razdelku najprej predstavljamo izhodišča predlaganega pristopa, ki temelji na metrikah, razvrščenih v tri skupine. Prva skupina je namenjena identifikaciji možnih izboljšav strukture sistema, druga identifikaciji in preoblikovanju razredov, tretja skupina metrik, ki smo jo oblikovali, pa se osredotoča na metode znotraj posameznih razredov. Četrti razdelek predstavi rezultate praktične uporabe in ovrednotenja predlaganega pristopa na konkretnem primeru. 2 Izboljšanje strukture programske kode s preoblikovanjem Po definiciji je preoblikovanje proces spreminjanja programske kode tako, da se obnašanje sistema navzven ne spremeni, spremeni in izboljša pa se notranja struktura sistema [1], Preoblikovanje programske kode se je uveljavilo kot pomembna praksa pri razvoju programske opreme predvsem v povezavi z objektno orientiranimi sistemi in vpeljavo agilnih pristopov, saj brez njene uporabe razvijalci le s težavo udejanjajo temeljne vrednote in principe agilnosti, kot sta npr. odzivnost in preprostost. Načelo preprostosti namreč pomeni, da razvijemo minimalni sistem, ki Se zadovoljuje zahteve uporabnikov. Če pred dodajanjem nove funkcionalnosti obstoječe kode ne bi izboljšali, torej preoblikovali in pripravili za dodajanje nove funkcionalnosti, bi sistem po nekaj iteracijah zaradi slabe strukturiranosti postal neobvladljiv in nezmožen nadaljnjega razvoja. Ko govorimo o preoblikovanju in o identifikaciji delov kode, kjer je treba aplicirati določeno preoblikovanje, ne moremo mimo pojma slabo oblikovane kode. Slabo oblikovana koda je definirana kot del kode, ki sicer služi svojemu namenu, torej izvršuje neko zaporedje ukazov, ki skupaj pravilno izvedejo neko funkcionalnost, vendar pa bi lahko bil ta del kode napisan bolje, razumljiveje, morda v drugem razredu, komponenti ali metodi. Tabela 1 povzema po [1] najpomembnejše tipe slabo oblikovane kode, kratek opis in vrste preoblikovanja, ki jih je smiselno uporabiti za odpravljanje tega tipa slabo oblikovane kode. Vsakega izmed identificiranih tipov slabo oblikovane kode lahko torej odpravimo z uporabo enega ali več različnih vrst preoblikovanja. Zaradi boljše razumljivosti so imena posameznih vrst preoblikovanj v tabeli pa tudi v nadaljnjem besedilu navedena z izvornim angleškim izrazom. Žal pa tudi podrobni seznam vseh identificiranih tipov slabo oblikovane kode ne more zagotoviti enoumnega kriterija, s pomočjo katerega bi ugotovili, kdaj je preoblikovanje nujno, temveč je treba primere slabo oblikovane kode vzeti kot smernice, kje in kako izboljšati kodo s pomočjo preoblikovanj. Seveda se odločitev glede lega, katero preoblikovanje uporabiti za odpravo določenega tipa slabo oblikovane kode, od primera do primera razlikuje. Včasih lahko slabo oblikovano kodo odpravimo že z enim samim preprostim preoblikovanjem, velikokrat pa je treba aplicirati več preoblikovanj zapored. 3 Sorodne raziskave Čeprav se lahko strinjamo s trditvijo, da pri identifikaciji slabo oblikovane kode ne moremo nadomestiti Človeških izkušenj in intuicije, obstaja nekaj raziskav, ki dokazujejo, da lahko ustrezni pristopi in metode vsaj pomagajo pri zadani nalogi. Predstavili bomo rezultate dveh ra/iskav s tega področja, podrobnejši opis je na voljo v [3] in [5], 3.1 Preoblikovanje na podlagi metrike razdalje Raziskava Metrics Based Refadaring [3] je pokazala, da lahko s pomočjo posebnih metrik podpremo subjektivne ocene o slabo oblikovani kodi in identificiramo, kje aplicirati katero preoblikovanje. Na podlagi metrik izdelamo vizualno sliko sistema, iz katere ugotovimo, kje so mesta v programu, ki bi jih bilo treba preoblikovati. Raziskava se omeji zgolj na štiri tipe preoblikovanja in sicer Mase melhod, Move Field, Extract Class in In-lirte Class ter temelji na dejstvu, da je veliko preoblikovanj osnovanih na principu "Dajmo skupaj, kar sodi sfot-l>aj". Tako avtorji definirajo, da je podobnost med dvema elementoma v zvezi z zbirko njunih skupnih lastnosti. |/>(.v)n />{v')| disln(.x,y) := l - pri čemer sta x m y opazovana elementa, p(x); (lastnosti pt e B \xtma v lasti p J Formula 1: Razdalja med opaiovanima elementoma 2007 - številka 1 - letnik XV UPOBiBNi INFORMATIKA 31 Marko Tekavc, Marjan Heričko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Na podlagi formule 1 vpeljemo pojem razdalje oz. oddaljenosti, s katero opišemo mero vezljivosti. Velja, da je vezljivost delov z nizkimi razdaljami boljša kol vezljivost delov z velikimi razdaljami. Razdalje računamo /a atribute in metode razreda, pri čemer izhajamo i/, pred- postavke, da dva elementa sodita skupaj, če uporabljata drug drugega. Identifikacija možnega preoblikovanja je omejena na prej omenjena štiri preoblikovanja in poteka na osnovi identifikacije velikih razdalj med člani razreda ter majhnih razdalj do Članov drugega razreda. Tabela 1: Tipi slabo oblikovane hode Slabo obit kovan a koda Opis Smiselna preobfikouanja Komentarii AssertiDn V komentarjih opisujemo, kaj dela programska koda. Extract Method. Rename Method Introduce Predolga metoda Metoda je tako obsežna, da težko ugotovimo, kakšna ¡e niena funkcionalnost Extract Method, Replace Temp with Query, Introduce Parameter Object, Preserve Whole Object. Replace Method with Method Object Predolg nabor parametrov V metodo poSiljamo vse podatke prek parametrov, čeprav bi lahko metoda sama prišla (Jo potrehnih podatkov Replace Parameter with Method. Preserve Whole Object, Replace Method with Method Ob|ect Podvojena koda Imamo enako kodo na več različnih mestih v sistemu, kar otežuje sprem in jaoje programa Extract Method, Pull Up Field, Form Template Method, Substitute Algorithm Prevelik razred Razred, ki opravlia preveč funkciooalnosli. Extract Class, Extract Subclass Tip vgrajen v ime V imenih metnri imamn podatke, ki so vidni že iz samega podpisa metode Rename Method Nekonsistentna imena Za isti pojem uporabljamo različna imena Rename Methnri Spekulativna splošno st Pretiravamo i generalizacijo kode. z namenom predvidevanja prihodnjih potreb Collapse Hierarchy, Inline Class, Remove Parameter, Rename Method Obsedenost s primitivnimi Lipi Za sestav I iene podatke uporabil a mo primitivne lipe. namesto da bi uporabili preproste objekte. Replace Data Value with Object. Replace Type Code with Class/Subclass State/Strategy. Extract Class, Introduce Parameter Obiect. Replace Array With Object Podatkuvni razred Razred je brez lunkciorialnosli - sestavljen samo z atributi in metodami get io set. Move Method Skupine podatkov Skupine podatkov, ki ]ih vedno najdemn skopal Extract class, Introduce Parameter Object, Preserve Whole Ob|ect Zavrnjena zapuščina Podrazredi ne potrebujejo vsega kar podedu|fi|0 Replace Inheritance With Delegation Neprimerna intimnost. Dva razreda sta preveč prepletena. Change Bidirectional Association to Unidirectional. Extract Class, Hide Delegate Len razred Razred, ki ne opravl|a dovoli funkcionalnosti. Collapse Hierarchy, Inline Class Zavidanj lastnosti Metodo bolj zanimajo lastnosti nekega drugega razreda kot tistega, v katerem se dejansko nahaia Extract method Move Method Verige spor očil Odjemalec mora uporabiti en razred, da pride do drugega in potem tega. da pride do tretjega itd Hide Delegate □srednja osebnost Razred večino stvari delegira k drugemu razredu Inline Method. Replace Delegation With Inheritance Raznolike spremembe Razred se pogosto Iz različnih razlogov spreminja na različne načine Extract Class Poseg s šibrovko Nasprotno od raznolikih sprememb. Sprememba povzroči veliko majhnih sprememb v različnih razredih Inline Class Vzporedne hierarhije dedovanj Posebna oblika posega s šibrovko Vedno ko naredimo podrazred razreda, moramo narediti tudi pod razred nekega drugega razreda. Move Method. Move Field 32 uporabna INFORMATIKA 2007 - šlpvilka t - letnik XV Marko Te kave, Marjan Hit r ko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Po aplikaciji koncepta merjenja razdalje na osnovi vezljivosti in po izračunu vseh razdalj med metodami in atributi izdelamo metriko razdalj med opazovanimi elementi, s pomočjo katere izvedemo vizualizaci-jo, Vizualizacija je mogoča s pomočjo programa "3D-Spring E m bed de i*" [4], s katerim izdelamo 3D modele v jeziku VRML. Ključnega pomena za orodje, ki omogoča vizualizacijo, je hitrost in povezanost z razvojnim okoljem. Za uporabo in izračun vrednosti metrike / razdaljami, ki je potrebna za vizualizacijo, je treba izdelati repozitorij relevantnih konceptov, kot so razredi, metode, povezave ipd. Nato izberemo konstrukte, ki jih bomo analizirali, in izračunamo razdalje. Na osnovi izračunanih pozicij in informacij i/, repozitorija izdelamo model VRML, Ena izmed slabosti opisane rešitve podpornega orodja je prav trajanje izgradnje repozitorija uporabljenih konceptov iz projekta, ki se sicer izvaja samo enkrat, vendar pa se mora ob spremembah v programski kodi posodobiti. Dodatno težavo predstavlja interpretacija vizualizacije in razpoznavanje slabo oblikovane kode. S kompleksnostjo sistema namreč narašča tudi kompleksnost vizualizacije, kar otežuje identifikacijo delov s slabo oblikovano kodo. Poleg tega obstajata pri uporabi te metode za velike sisteme še dve težavi: • Veliko razredov ne moremo Obravnavati ločeno, saj so vpeti v strukturo dedovanja. Če raziskujemo določen razred brez upoštevanja konteksta dedovanja, lahko pridemo do napačnih sklepov oziroma predlogov za preoblikovanje. . Ker lahko v velikem sistemu obstaja več tisoč razredov in je lahko podrobna analiza časovno zelo potratna, se pojavlja problem, kako v tako velikem sistemu v predstavljeni vizualizaciji opaziti tiste razrede, ki jih je treba preoblikovati. Čeprav so nekateri izmed omenjenih problemov delno rešeni, je metoda za velike sisteme le pogojno uporabna, poleg tega pa uporabljena metrika ni podprta v obstoječih razvojnih okoljih in orodjih. 3.2 Preoblikovanje na podlagi zgodovine sprememb V članku Improving Evolmbiltty through Refactoring [5] je opisana metoda, ki uporablja zgodovinske podatke, pridobljene iz repozitorijev, kot je CVS. Metoda se osreči o toča na sklope sprememb - Če se nekateri deli skozi več izdaj zelo pogosto spreminjajo, potem lahko takšni podatki služijo kot pokazatelji potencialnih mest za aplikacijo preoblikovanj. Poleg koncepta slabo oblikovane kode vpeljemo še koncept sumljivih sprememb. Takšne spremembe težko opazimo v kodi, lahko pa jih identificiramo na podlagi pregleda zgodovine sprememb. Pristop omogoča zaznavanje sumljivih sprememb in s tem spodbuja razvijalce k preoblikovanju takšnih delov izvorne kode. Definicija sklop! j en osti sprememb pravi, da sta elementa logično sklopljena, če spremembe skozi dovolj veliko število izdaj vplivajo na oba elementa. Predstavljena sta dva tipa sumljivih sprememb: /. Osrednja osebnost (»Man in the middle«) - osrednji razred se razvija skupaj s Številnimi ostalimi razredi, ki so razpršeni po različnih modulih v sistemu, takšen razred zavira razvoj samostojnih modulov zaradi močne povezanosti z drugimi deli sistema. 2. Vsebnik podatkov (»Da ta Container«) - obstajata dva razreda, kjer prvi vsebuje vse potrebne podatke, drugi pa sodeluje z ostalimi razredi in zagotavlja funkcionalnost/ ki uporablja predvsem podatke prvega razreda. S tem krši princip ograjevanja podatkov in povezanih funkcionalnosti. Predlagana metoda je podprta tudi z orodjem, izdelanim v ta namen - EvoLeris [h]. Orodje razčleni dnevniške datoteke iz repozitorija CVS in izračuna spremembo sklopi j enosti med razredi, Skiopljenost se nato skupaj s strukturnimi informacijami vizualizira. Pristop je bil preizkušen na zgodovini sprememb velikega industrijskega projekta skozi obdobje petnajstih mesecev. V tem času so bila, s pomočjo analize zgodovinskih podatkov predlagana mesta za preoblikovanje. Po aplikaciji preoblikovanj in nadaljnjih petnajstih mesecih opazovanj so ocenili učinkovitost pristopa, ki je podprla hipotezo, da je kombinacija analize odvisnosti sprememb in preoblikovanja uporabna in učinkovita [5]. Žal je predstavljeni pristop uporaben zgolj v povezavi s spremljanjem in zbiranjem Zgodovinskih podatkov, v praksi pa bi želeli programsko kodo izboljšati tudi v primeru, ko tovrstnih podatkov še ni, zalo smo definirali pristop, ki temelji zgolj na aktualnem sistemu ter temelji na uveljavljenih metrikah objektno orientirane kode, hkrati pa lahko metrične vrednosti enostavno pridobimo in zberemo v času razvoja s pripomočki in metričnimi orodji, ki so po navadi že vključena v sodobna razvojna okolja. 4 Uporaba uveljavljenih objektno orientiranih metrik pri preoblikovanju Pristop, ki ga predlagamo, temelji na predpostavki, da bi bilo mogoče s pomočjo uveljavljenih objektno 2007 - številka 1 - letnik XV upoBiBNi INFORMATIKA 33 Marko Tekjuc. Marjan Heričko Uporaba metrik pri Identifikaciji smiselnih preoblikovanj programske kode orientiranih metrik identificirati slabo oblikovane dele kode in predlagati preoblikovanja, s katerimi bi takšno kodo izboljšali. Na osnovi analize najbolj uveljavljenih in razširjenih metrik za objektne sisteme smo oblikovali nabor primernih metrik in jih razdelili v tri skupine glede na to, kakšen tip slabo oblikovane kode lahko z njimi identificiramo: 1. Slnbn struktura - V to skupino smo uvrstili predvsem metrike MOOD, ki jih je predlagal Abreau [7, Mj. Z njimi lahko ugotovimo, ali program upošteva pravila in navodila dobrega objektnega načrtovanja ter implementacije. 2. Slabo oblikovani razredi - V to skupino smo uvrstili metrike, ki izpostavijo slabo oblikovane razrede. Tako identificiramo razrede, ki so pretesno povezani z drugimi razredi, razrede, ki imajo nizko vezij i vost, in razrede, ki so preveliki ali imajo preveliko število operacij in atributov. 3. Prezapletene metode - V tretji skupini najdemo metrike, ki se ukvarjajo z. metodami. Prezapletene metode lahko identificiramo po dolžini, preveliki cikloma lični kompleksnosti, prezapletenih vejit-vah ali prevelikem številu operacij, lokalnih spremenljivk ali parametrov. Tabela 2: Poveianost metrih, slaba oblikovane kode in preoblikovanj Metrika Slabost Motni tip slabo oblikovane kode Preoblikovanje Slaba struktura Faktor sklojiljenosti ICF) Prevelika sklopljenost Neprimerna intimnost, osredka osebnost, zavidanje lastnosti Move Method, Move Field, Change Bidirectional Association to Unidirectional. Replace Delegation With Inheritance Faktur polimorfičnosti (PF) Neupuraba poli m orfizma Podvodna koda Replace Type Code with Subclasses. Replace Type Code with State/Strategy, Replace Conditional with Polymorphism Skrivanje metod/atributov (AHF/MHF) Kršitev ograjevala Encapsulate Field, Self Encapsulate Field. Hide Method Dedovanje atributov/metod IAIF/MIF) Na uporaba dedovanja Podvojena koda, osrednja osebnost Replace Delegation With Inheritance. Extract Subclass, Replace Type Cede with Subclass/State/Strategy Slabo oblikovani razredi Sklopljenost med objekti FCBD1 Prevelika skln pijanost Neprimerna intimnost, verige spomčil Change Bidirectional Association to Unidirectional, Extract Class, Hide Delegate Sklopljenost klicev metod (MfCl Prevelika sklopljenost. Neprimerna intimnost, verige sporočil Extract Class, Hide Delegate, Move Methud Pomanjkanja veiljivosti med metodami tlCOMl Pomanjkanje vezliivcaLi Replace inheritance with delegation. Move Field. Move Method Število atributov/operacij/člariov razreda (NDA/NBD/NOMl Prevelik razred Prevelik razred Extract Class. Extract Subclass Število dodanih metod (NOAM) Neustrezna uporaba dedovanja Extract subclass, Replace inheritance with delegation Uteženp metode raireda IWMPC! Prekompleksen razred Prevelik razred, Podvojena koda Extract Class, Extract Subclass, Replace Type Code with State/Strategy, Replace Conditional with Polymorphism Prezapletene metode Cikiotnatična kompleksnost tCCl Preknmpleksna metoda Predolga metoda Podvojena koda Extract method. Replace Type code with Class/Subclasses/State/Strategy Število vrstic kode IL0C1 Predolga metoda Predolga metoda Extract Method Maksimalno število vejitev v metodi IMNOB) Preko mpleks na metoda Extract method. Replace Type code with Class/Subclasses/State/Strategy Število parametrov (NOP) Predolg t«bun parametrov Predolg nabor parametrov Replace Parameter with Method. Preserve Whole Ob|ect, Introduce Parameter Object Številu lokalnih spremenljivk (NDLUI Lokalne spremenljivke Replace Temp with Query. Inline Temp 34 unonAOKA INFORMATIKA 2007 • Številka 1 ■ letnik XV Marko Te kave, Marjan Hit r ko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Tabela 2 za vsako ¡¿med izbranih metrik prikazuje, katero slabost in tip slabo oblikovane kode lahko odkrijemo z njo ter katera so iz tega izhajajoča najpogosteje uporabljana preoblikovanja za izboljšanje takšne kode. Dejansko lahko z nekaterimi metrikami identificiramo nasprotne tipe slabo oblikovane kode ali pa metrika identificira tudi kakšen drugi tip slabo oblikovane kode, ki v tabeli ni naveden. Tudi zato tabela ne nudi popolnega pregleda, temveč le podaja najpogostejše povezave med metrikami, slabo oblikovano kodo in preoblikovanji. 4.1 Slaba struktura Metrike iz te skupine povedo, kako dobro je sistem strukturi ran in kako so uporabljeni principi objektne-? ga razvoja (dedovanje, ograjevanje, polimorfizem). Večina teh metrik vrne vrednost za celoten štetem in zato niso primerne za lociranje mest s slabo oblikovano kodo, pač pa kažejo, v kateri smeri bodo potekala preoblikovanja. Metrika faktor sklopljenosti (Coupling Factor - CF) prikaže odstotek sklopljenosti med razredi vštetemu. Čim večja je ta vrednost, tem bolj sklopi jeni so razredi in je sistem težji za vzdrževanje. Visoka vrednost je pogosto znak za smiselnost premestitve metod in atributov (Move Method, Move Field) v ustreznejše razrede ali spremembo dvosmerne povezave v enosmerno {Change Bidirectional Association to Unidirectional). Seveda sta li dve preoblikovanji zgolj najočilnejši možnosti, sklopljenost lahko namreč zmanjšamo tudi /. drugimi preoblikovanji. Metrika faktor polimorfiČnosti (Polymorphism Factor -PF) vrne stopnjo polimorfizma v opazovanem sistemu. Nizka vrednost praviloma pomeni, da je v sistemu premalo uporabljen eden izmed osnovnih principov objektnega razvoja polimorfizem. Običajno v sistemu namesto polimorfizma nastopajo stavki switch/case, ki jih preoblikujemo s preoblikovanji Replace Type Code with Sulxlasses, Replace Type Code with State/Strategi/ in Replace Conditional with Polymorphism. Metriki skrivanje metod oziroma atributov (Attribute Hiding Factor - Al IF / Method Hiding Factor - MHF) izpostavita kršitve ograjevartja. Problem razrešimo s spreminjanjem vidnosti in ograjevanjem atributov/ metod, za kar lahko uporabimo preoblikovanja Fncap-^ulate Field, Self Encapsulate Field in Hide Method. Metriki dedovanje atributov oziroma metod (Attribute Inheritance Factor - All / Method Inheritance Factor - Ml F) vrneta delež vseh podedovanih atributov/metod v sistemu. Ce je vrednost nizka, to navadno pomeni, da v sistemu ni vzpostavljena ustrezna hierarhija razredov, saj je premalo uporabljan eden temeljnih principov objektnega razvoja dedovanje. 4.2 Slabo oblikovani razredi V tej skupini so metrike, s pomočjo katerih lahko ugotovimo, ali imamo v našem sistemu ustrezne razrede in povezave med njimi. Z metrikami iz te skupine praviloma identificiramo točno določen razred ali razrede, ki jih je treba preoblikovati, hkrati pa ugotovimo, za kakšen tip slabo oblikovane kode gre in s pomočjo katerih preoblikovanj lahko odpravimo takšno kodo. Metrika sklopljenost med objekti (Coupling Between Objects - C BO) vrne število razredov, s katerimi je povezan opazovan razred. Prevelika sklopljenost med razredi je značilna za modularno strukturo in preprečuje ponovno uporabo ter otežuje vzdrževanje sistema. Večja sklopljenost zahteva tudi rigoroznejše testiranje. Metrika nakazuje neprimerno intimnost (Inappropriate Intimacy) med razredi. Sklopljenost med razredi lahko zmanjšamo s preoblikovanji Change Bidirectional Association to Unidirectional, Extract Class in Hide Delegate. Metrika sklopljenost klicev metod (Met hot I Invocation Coupling- MIC) vrne relativno število razredov, h katerim opazovani razred pošilja sporočila; MICnom = nMIC/(N-l) pri čemer je nMIC število razredov, h katerim se pošiljajo sporočila, in N število vseh razredov v sistemu. Prevelika sklopljenost med razredi ima vpliv na: 1. vzdrževanje - vzdrževanje močno sklopi jenih razredov je težavnejše zaradi odvisnosti od povezanih razredov; 2. razumljivost - težja razumljivost razreda, saj je za razumevanje po navadi treba razumeti tudi povezane razrede alt njihove dele; 3. nagnjenost k napakam, težavno testiranje- napake v razredu so premo sorazmerne s številom povezav na druge razrede in posledično ima to negativen vpliv na testiranje. Visoka vrednost te metrike torej pomeni močno povezan razred in nakazuje neprimerno intimnost (Inappropriate Intimacy) med razredi. Spet si lahko 2007 - številka 1 - letnik XV UPOBiBNi INFORMATIKA 35 Marko Tekavc, Marjan Heričko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode pomagamo s preoblikovanji, kot so Extrae t Clas.s1, Hide Delegate in Move Met ¡nal. Metriki/ ¡jomanjkanje vczljhmti med metodami (hick of Cohesion Of Met hod s — LCOM) vrne odstotek metod, ki ne dostopa jo do določenega atributa, glede na vse atribute v razredu. Visoka vrednost te metrike nakazuje pomanjkanje vezljivosti in pomeni, da je razred slabo zasnovan. Pomanjkanje vezljivosti povečuje kompleksnost. Pri identifikaciji slabo oblikovanih razredov si lahko pomagamo tudi s tremi sorodnimi metrikami, ki preStejejo atribute, metode oziroma Člane razreda. Na podlagi metrik števila atributov, operacij oziroma članov razreda (Number of Attributes NOA, Number of Opera-t! on s NOO, Number of Meittbers NOM) lahko identificiramo (pre)kompleksen, prevelik razred, ki je eden najpogostejših tipov slabo oblikovane kode ¡ 1 ]. Rešitev je v razdelitvi razreda na ustreznejše razrede/ podrazrede s preoblikovanjem Extract Class/Extract Subclass. Metrika Število dodanih metod (Number ofAdded Metliods — NOAM) prešteje število (dodatnih) operacij (pod)-razreda; podedovane in predefinirane (overidden) metode ne upošteva. Metrika ne zadeva razredov bre/ staršev. Prevelika vrednost te metrike pomeni, da se funkcionalnost izbranega podrazreda preveč razlikuje od starša. S pomočjo preoblikovanja Extract suMass lahko ustvarimo dodatni podrazred ali hierarhijo nadomestimo z delegiranjem (Replace inheritance witli delegation). Metnhi utežene metode razreda (Weighled Methods Per Class- WA'IPC) je zadnja metrika, ki smo jo uvrstili v skupino metrik, primernih za identifikacijo slabo oblikovanih razredov. 1'rva oblika te metrike meri kompleksnost razreda na podlagi ciklomalične kompleksnosti metod v razredu, druga pa temelji na predpostavki, da več metod in večje število parametrov metod navadno pomeni tudi večjo kompleksnost. 4.3 Prezapletene metode Uporaba metrik iz te skupine izpostavi slabo oblikovane metode. Praviloma lahko s pomočjo teh metrik identificiramo tudi lip slabo oblikovane kode v metodi in s tem preoblikovanja, ki odpravijo takšno kodo. Metrika ciklomatične kompleksnosti (Cyclomatic Com-plexity - C.C) pomaga pri identifikaciji kompleksnih metod, saj predstavi Število ciklov v merjeni metodi. Dejansko prešteje število možnih poti skozi algoritem s pomočjo štetja stavkov if, for in while. Po definiciji dobimo vrednost metrike z enačbo: CC = L - N +2P pri čemer je L Število povezav v grafu kontrolnega toka, N je število vo/iišč in P število nepovezanih delov, Cim višja je izmerjena vrednost metrike, tem kompleksnejša je merjena metoda. Metrika Števila vrstic kode (Lines of Code — LOC) šteje vrstice v metodi/razredu/paketu/aplikaciji, vključno s komentarji in praznimi vrsticami. Preveliki) število vrstic kode običajno pomeni (pre)kompleksno, predolgo metodo. Tip slabo oblikovane kode, ki ga identificiramo, je torej predolga metoda, odpravimo pa ga s preoblikovanjem Extract Method. Metrika maksimalno število vejitev v metodi (Maximum Number of Branches - MNOB) je definirana kol maksimalno možno število if-else in/ali case vejitev v metodi. Visoka vrednost praviloma pomeni kompleksno metodo. Preoblikovanja, s katerimi lahko odpravimo kompleksne pogojne strukture, so Extract method, Replace Ti/pe code with Cläss/Subclasses/State/Strategy. Metrika število parametrov (Number of Parameters -NOP) vrne število parametrov v opazovani metodi. Preveliko število parametrov je dobro poznana slabo oblikovana koda, imenovana predolg nabor parametrov (Long Parameter List), ki jo lahko odpravimo z enim preoblikovanjem ali kombinacijo preoblikovanj: Replace Parameter with Method, Preserve Whole Object in Introduce Parameter Object. Metrika število lokalnih spremenljivk (Number of Local Variables - NOLV) je pomembna zato, ker lokalne spremenljivke otežujejo ali onemogočajo določena preoblikovanja metod. Preoblikovanji, ki ju lahko uporabimo za odpravo lokalnih spremenljivk, sta Replace Temp with Query in Inline Temp. 5 Ovrednotenje pristopa na primeru Vrednotenje ustreznosti predstavljenih skupin metrik, kt lahko služijo kot smernice pri izvajanju preoblikovanj, smo izvedli na enostavnem sistemu za vodenje izposoje gradiva v knjižnici. Programska koda je napisana praktično brez upoštevanja konceptov objektne orientacije, z eno relativno dolgo in kompleksno metodo, in je kot takšna zelo primerena /a preoblikovanje. Originalna programska koda je na voljo na naslovu http://cot.uni-Tnb.si/Refactoring/koda.zip. Slika 1 prikazuje razredni diagram tega programa. Analiza programske kode je bila izvedena z orodjem, ki nudi podporo izvajanju metrik na programski kodi in avtomatizacijo nekaterih enostavnejših pre- 36 uporabna INFORMATIKA 2007 - šlpvilka t - letnik XV Marko Te kave, Marjan Hit r ko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode oblikovanj. Tabela 3 prikazuje najzanimivejše rezultate metrik, s pomočjo katerih lahko ocenimo strukturo našega programa. Faktorja dedovanja metod (MIF) in polimorfizma (PF) sta enaka 0, kar pomeni, da ta dva koncepta v našem primeru nista navzoča. Prav tako je slab tudi faktor sklopi jenos ti (CF), saj nakazuje precej veliko sklopijenost med našimi razredi. Sprejemljiva pa je stopnja prikritosti atributov (AHF), to pomeni, da je večinoma upoštevan koncept ohlajevanja. O lil lili Iv o V KNJIGA: rt V IBORMK ir» V REVIJA rt o rmtlov Strug □ tf> rt 9 Clan O Izposoj.] " dndipojo» trt d li)>osoi«<5ira<*v?) i>«*vo, (Wzpoiote ml) ( o nawv Strrig o liposote Vector 1 d Cldrt.naziv Strng) • ncvtilzpo£t^ai.iipci0)0 izposoj) * uslvafotoulaO Slrny d Grndvno d Cfodr-ttfnaslov Sirkig, tpCrodrvo H) O gWNastovOrndivsO Strng O ;e(Tv>Gr«iiva(tipi>«i[va rt) O g«tTipGr®tfY