Modulul CoDePro

Principalul element distinctiv al abordarii noastre in modulul CoDePro e caracterul agil al tehnicilor propuse de detectie si corectie de erori, un element de originalitate fiind transformarea asigurarii calitatii unui proiect dintr-o activitate separata intr-un proces continuu (agil), integrat perfect in ciclul de dezvoltare. Adaptarea abordarilor de sine statatoare pentru a le face agile e un aspect original, de inalta complexitate, necesitand metode si unelte specifice, care sunt dezvoltate ca parte a proiectului. Ca parte a acestui element a fost dezvoltat in 2007 in cadrului acestui proiect un prim prototip pentru detectia continua de carente de proiectare pentru sisteme orientate pe obiecte scrise in limbajul Java si dezvoltate folosind mediul integrat Eclipse.

2.1 si 2.3 Studiu asupra optimizarii ergonomiei interactiunii dintre modulul de CoDePro si activitatea curenta de dezvoltare. Rafinarea modului de interactiune in CoDePro prin integrarea rezultatelor studiului din Activitatea 2.1/2008.

Ca parte a Activitatii 2.1 s-a efectuat un studiu, atat bazat pe literatura de specialitate, cat si bazat pe analiza modului de interactiune standard in Eclipse (pentru a face integrarea in Eclipse sa solicite cat mai putine elemente noi de interactiune pentru utilizator. In plus, s-au implementat la nivel de prototipizare, diferite mecanisme alternative de interactiune pentru a se observa varianta optima.

Ca urmarea a acestei activitati, in timpul activitatii 2.3 s-au implementat o serie de scenarii de interactiune care s-au dovedit a fi cele mai bune. In continuare vom prezenta cateva dintre ele:

• Rularea "ascunsa": Dupa instalare CoDePro ruleaza imediat, chiar daca in mod surprinzator acest lucru nu pare imediat evident, intrucat ruleaza in fundal. Din momentul pornirii unui workbench Eclipse, inCode incepe sa analizeze fisierul sursa vizbil in editor. Daca inCode detecteaza una sau mai multe probleme de proiectare un marker rosu (Figura 2.1.1) este plasat in bara din stanga a editorului in dreptul entitatii afectate. Aceste markere sunt asemanatoare celor care indica erori de compilare in Eclipse.

  
  Figura 2.1.1 - Markerele CoDePro

• Analiza detaliata a carentelor. Pentru a vedea detalii despre cauzele unei anumite carente de proiectare inginerul trebuie sa selecteze markerul rosu amintit mai sus (Fig.2.1.1), si sa selecteze din meniul pop-up problema de proiectare relevanta (intrucat o clasa/metoda poate fi afectata simultan de mai multe carente de proiectare). Aceste detalii vor fi presentate in view-ul Eclipse numit inCode Tips view (Figura 2.1.2), care se deschide in partea de jos a workbench-ului Eclipse. Acest view prezinta indicatii specifice despre problema in cauza, indicatii contextualizate pentru situatia particulara in care se gaseste entitatea analizata. In plus, in acest view apar si indicatii despre cum ar putea fi corectata problema de proiectare (vezi si explicatiile de mai jos legate de refactorizare). Nivelul crescut de intuitivitate al acestui view este asigurat de faptul ca se poate interactiona cu informatia prezentata ca intr-un browser de web.

  
  Figura 2.1.2 - View-ul inCode Tips

• Analiza de ansamblu. Pe langa detectia continua a carentelor de proiectare CoDePro/inCode poate oferi si o analiza de ansamblu (asincrona) la nivel de de sistem sau de pachet. Acest lucru se poate face selectand (right-click) din Package Explorer proiectul (sau un pachet) care se doreste a fi analizat, si alegand optiunea inCode... | inCode Overview sau inCode Overview with duplications. (Figura 2.1.3 A). Acest tip de analiza contine doua tipuri de informatie: (1) analiza Overview Pyramid (un sumar principalelor caracteristici ale modulului analizat din punctul de vedere al dimensiunii, complexitatii, cuplajului si profilului ierarhiilor de clase); si (2) o lista categorizata a problemelor de proiectare detectate (Figura 2.1.3 B). Printr-un simplu click se poate ajunge la codul oricarei entitati din cele listate in partea dreapta, ca avand probleme de proiectare. Odata deschisa in editor entitatea poate fi analizata in detaliu, asa cum a fost prezentat mai sus.

Figura 2.1.3 - View-ul inCode Overview

2.2 Definirea si implementarea facilitatilor de extensie si configurare pentru modulul CoDePro/inCode (omise in prototipul definit in Activitatea 2007-2.2)

Prototipul definit in anul 2007 era extrem de limitat in privinta abilitatii de adaugare de noi analize, acesta fiind la inceput un proces extrem de laborios, accesibil doar dezvoltatorilor initiali ai sistemului. Ca urmare a activitatii 2.2/2008, adaugarea unei noi analize se face cu ajutorul mecanismului standard de extensie a plugin-urilor din Eclipse, mai exact urmandu-se urmatoarea secvent de pasi:

• Pas1: Deschidem plugin.xml, selectam tab-ul "Extensions", click dreapta pe "inCode.identityDisharmony" | new identityDisharmony. Aici se completeaza  campurile (de exemplu pentru carenta de proiectare Feature Envy):

  • -class-: view.identityDisharmony.featureEnvy.FeatureEnvy

  • -filteringRule-:lrg.insider.plugins.filters.memoria.methods.FeatureEnvy

  • -message-: Feature Envy - mesajul e textul care apare la hover peste markerul rosu din editorul de cod sursa. Acest mesaj trebuie sa fie unic

• Pas 2: Salvam fisierul plugin.xml, iar apoi se poate trece la scrierea codului Java pentru definirea analizei

• Pas 3: Scriem clasa specificata la atributul -class-. Clasa trebuie sa extinda clasa DefaultIdentityDisharmony(daca nu exista sau nu extinde DefaultIdentityDisharmony apare un warning in plugin.xml)

• Pas 4: Clasa creata trebuie sa aiba constructorul default si in metoda initialize() se seteaza entitatea analizata si se construiesc grupurile necesare pentru a explica problema in Tips View

• Pas 5: Se va implementa in mod specific metoda  buildHTML(). In aceasta metoda se construiese mesajul ce urmeaza sa apara in TipsView. Mesajul HTML corespunzator acelei instante a carentei de proiectare poate fi construit folosindu-se urmatoarele facilitati implementate in inCode: Pentru a adauga un link folosim metoda   HTMLBuilder.createLink(String linkName, ILinkAction action). In plus, interfata ILinkAction are o metoda run care este apelata la click pe link. De obicei aici se contruieste si se afiseaza tree-ul din partea dreapta a Tips View (vezi Figura 2.1.2), dar aici poate  fi si codul care declanseaza o refactorizare, de exemplu

Pentru a construi tree-ul - se folosesc metodele din clasa TreeViewContentProvider  de exemplu:

result += " it uses " + HTMLBuilder.createLink("many (" +
    foreignDataGroup.distinct().size() + ")",
    new ILinkAction(){
        public void run(TipsView view) {
            TreeViewContentProvider content =
              view.getTreeViewContentProvider();
            // creeaza tree-ul si ii seteaza numele
            content.createTree("Externalattributes");
            // metoda "utilitara" createTree creeaza un tree
            // unde pe cel mai jos nivel este un call sau un
            // acces (line number),mai sus este declaratia
            // metodei apelate iar mai sus clasa de care
            // apartine metoda apela
            content.addCallsAndAccesses(foreignDataGroup);
            view.expandTree(3);//expandeaza tree-ul
    }});

Alte metode de la TreeViewContentProvider sunt: addElementToTreeRoot() - adauga un Wrapper simplu (adica un obiect Wrapper care are doar nume) la "radacina"; addElementToElement() adauga un Wrapper simplu sub un alt Wrapper simplu; addGroupToElement() pentru fiecare element din grup apeleaza addElementToElement, addTreeObjectToWrapper() adauga un SimpleTreeOBject (eventual decorat) sub un Wrapper un SimpleTreeOBjectpoate fi decorat cu: DuplicatedMethod Decoration,DuplicationDecoration, LocationDecoration (ultimul decorator este necesar pentru apelururi de metode si/sau accese de atribute, pentru a se preciza si linia call-ului) ReferencesDecoration(scrie si un numar de referinte), TypeOfWrapperDecoration (scrie si tipul field-ului)

Obiectivul 4/2008 Rafinarea modulului CoDePro cu facilitati de configurare si extensie

4.1 Identificarea elementelor constituente ale limbajului, prin studierea descrierii unor planuri de restructurare cum sunt cele descrise de J.Kerievsky in "Refactoring to Patterns" (Addison-Wesley, 2004)

Dupa identificarea instantelor de proiectare problematica, urmeaza restructurarea sistemului prin eliminarea carentelor identificate. In majoritatea cazurilor, aceasta implica o serie de refactorizari punctuale (de obicei refactorizarile sunt implementate in module de refactorizare, de ex. Move Method, Push-Up Field) care sunt insuficiente; pentru corectarea unei carente este nevoie de o intreaga secventa de refactorizari. Cartile recente de Kerievsky si Feathers indica imperativ catre necesitatea construirii de instrumente care permit restructurari compuse de nivel inalt. In acest context, am complementat mecanismele de detectie ale CoDePro/inCode cu o componenta dedicata de corectie. Ca parte a acestei activitati am identificat in primul rand doi factori principali, de care depinde strategia de corectie: (1) specificatile carentei de proiectare si (2) informatiile contextuale referitoarea la starea sistemului. Specificitatile unei carente implica tipul de informatii contextuale care trebuie cautate; la randul lor, aceste informatii contextuale decid alegerea unei cai de parcurgere a strategiei de corectie. Pentru identificarea elementelor constituente ale unei strategii de corectie, am studiat in mod special o suita de carente de proiectare corelate ce urmaresc identificarea de probleme legate de proasta localitate (si incapsulare) a datelor in aplicatii pe obiecte. Carentele care au stat la baza studiului sunt: God Class, Data Class, Feature Envy si Duplicarea de Cod. Studiul acestora a evidentiat faptul ca intr-o strategie de corectie elementele cheie sunt: (a) regula de detectie a carentei; (b) tipurile de informatii contextuale specifice (de obicei legate de prezenta sau absenta unor tipuri de dependente specifice carentei); (c) blocurile de decizie (unde este necesara interventia proiectantului), bazate pe informatiile contextuale; (d) caile de parcurgere rezultate din diferitele ramuri ale blocurilor de decizie.

4.2 Definirea propriu-zisa a limbajului sub forma unui DTD (Document Type Definition) pentru ca planurile de corectie sa fie definite ca XML, precum si proiectarea si implementarea unui parser pentru acest limbaj

In ciuda catorva elemente cheie ale unei strategii de corectie, studiul a dovedit ca pentru fiecare tip de carenta de proiectarea eterogenitatea elementelor concrete ce constituie o strategie de corectie sunt extrem de eterogene. In continuarea studiului din 4.1 am continuat ca parte a activitatii 4.2 cu o analiza a refactorizarilor primare existente in Eclipse si a mecanismelor de compunerea existente oferite de infrastructura Eclipse. Acest studiu suplimentar a evidentiat ca refactorizarile primare din Eclipse sunt in mare parte insuficiente (ex. refactorizarea Encapsulate Field nu permite exclusiv modificarea specificatorului de acces, fara adaugarea de metode de accesor; sau Move Method nu face nici o analiza a dependentelor care sa releve ca prin mutare un anumit camp, din clasa destinatie ar putea fi incapsulat). In plus, mencanismul de Refactoring Scripts oferit de Eclipse s-a dovedit o optiune promitatoare de compunere a unei secvente de refactorizari primare.Toate aceste elemente, precum si faptul ca aceasta problema nu a mai fost abordata la acest nivel de complexitate inainte, ne-a condus la concluzia ca utilizarea unui limbaj de tip XML este prea limitativ (cel putin pentru aceasta faza exploratorie in care elementele care trebuiesc tratate sunt atat de eterogene). De aceea in Activitatea 4.2 am decis sa mutam accentul pe definirea unul limbaj pe asigurare a legaturii intre partea de detectie si cea de corectie. In locul unul limbaj pe XML, am decis ca este mai eficient in faza aceasta de stabilizare ca strategiile de corectie sa fie implementate direct in limbajul Java, dar folosindu-se aceleasi acelasi mecanism de manipulare a informatiei din framework-ul de analiza (bazat pe ideea de meta-meta-modelare) folosit pentru detectia carentelor. In plus aceasta Activitate 4.2 a implicat definirea de noi refactorizari primare si modificarea celor deja existente in Eclipse pentrua a fi compatibile cu partea de detectie. Sumand atat efortul cat si eficienta noii abordari, comparativ cu cea conceputa initial se poate spune in mod cert ca alegerea unei noi solutii pentru modelarea strategiilor de corectie a fost de departe cea mai buna solutie.

4.3 Integrarea noului limbaj in CoDePro, si definirea unei mecanism tip "wizard" pentru executia unui plan de corectie, plan ce include refactorizari "atomice" (ex. Extract Method, Push Up Field) si puncte de decizie in care se solicita interventia inginerului software.

Asa cum se vede din Figura 4.3.1 declansarea refactorizarii (in cazul figurii Move Method) -wizard-ul- se opereaza din view-ul Eclipse in care apar si detaliile carentei de proiectare (in cazul de fata Feature Envy). Integrarea partilor de detectie si respectiv de corectie este evidenta: pe langa detalile contextualizate despre carenta de proiectare se ofera dezvoltatorului o optiune de refactorizarea (-Quick solutions-). In cazul de fata optiunea de refactorizare (detectata prin aplicarea analizei dependentelor) o reprezinta mutarea metodei envierMethod din clasa Envier in clasa DataHolder . Selectare link-ului din fereastra, declanseaza operatiunea de refactorizare, care implica executia unui -wizard- care sa configureze pasii refactorizarii (vezi fereastra modala din prin-planul Figurii 4.3.1).

Figura 2.1.3 - Declansarea refactorizarii din fereastra de detalierea a carentei de proiectare