Sunteți pe pagina 1din 7

Analiza statica cu FindBugs

1. Introducere
Calitatea software devine din ce in ce mai importanta odata cu dependenta societatii moderne de sistemele software. Exista mai multe metode de asigurare a calitatii, incluzand revizia codului si testarea riguroasa. Defectele software pot costa companiile sume semnificative, in special atunci cand duc la clacarea intregului sistem. Uneltele de analiza statica ofera o metoda de a analiza codul fara a trebui ca acesta sa fie rulat, ajutand la asigurarea unei calitati mai mari pe parcursul procesului de dezvoltare. Exista un numar divers de metode de a executa analize statice automate, continuu pe parcusul dezvoltarii la cererea developerului si imediat inainte ca software-ul sa fie trimis la un sistem de control al versiunii. Unealta ii poate permite dezvoltatorului sa configureze ce fel de defecte sa gaseasca si chiar sa defineasca defecte noi. Unele programe automate de analiza statica, precum cel integrat in IntelliJ IDEA, ofera solutii rapide. O solutie rapida este una sugerata pentru un defect ce este aplicata automat codului dezvoltatorului.

2. Prezentare FindBugs
Pentru a putea explica stadiul actual al analizei statice, vom folosi ca exemplu software-ul FindBugs. Acesta ruleaza ca un plug-in pentru medii integrate de dezvoltare (IDE) precum Eclipse si NetBeans sau poate fi folosit de la linia de comanda sau independent, ca o unealta separata. Atunci cand este integrat intr-un IDE, FindBugs are propria perspectiva cand vine vorba de modul in care defectele sunt listate si organizate. Fiecare defect are asociat o severitate, care inseamna gravitatea acelui defect, fiind fie mare, medie sau mica si este reprezentata de markere specifice de culori diferite ca rosu, galben si verde. De asemenea, FindBugs ofera si unele solutii rapide cat si posibilitatea de a seta un grad de severitate al scanarii in asa fel incat rezultatele vor contine numai erorile sau avertizarile ce sunt importante pentru dezvoltator sau testor. In plus, un alt aspect foarte important al acestei unelte este capacitatea ei de a detecta probleme de performanta ce pot duce la o incetinire a aplicatiei dezvoltate. Este evident faptul ca nicio unealta de analiza statica nu este perfecta, acesta fiind cazul si pentru FindBugs. Cu toate ca este posibila obtinerea unui rezultat gresit, software-ul ofera posibilitatea de a exclude codul din scanarea FindBugs folosind adnotatiile ce incep cu @.

Figura 1. FindBugs unealta separata

Figura 2. FindBugs plugin pentru Eclipse

3. De ce dezvoltatorii software nu folosesc unelte de analiza statica pentru a descoperi defecte?


Acum ca am inteles ce face FindBugs si care sunt limitarile acestui software, urmeaza intrebarea logica: De ce nu este folosit mai des? Intrebarea acesta este oarecum evidenta pentru ca, desi este cel mai bun software din categoria sa, oferind suport pentru numeroase medii de dezvoltare, a inregistrat de la lansarea sa si pana acum aproximativ 230.000 de descarcari si pot sa garantez ca nu toti cei care l-au descarcat il folosesc in momentul de fata. Pentru a detalia acest subiect, vom folosi articolul [1] scris de Brittany Johnson, Yoonki Song, Emerson Murphy-Hill si Robert Bowdidge ce studiaza in detaliu aceasta intrebare. Articolul porneste de la studiul realizat de Layman et al. ce se bazeaza pe un grup de test de 18 participanti pentru a identifica factorii luati in calcul de catre dezvoltatori atunci cand se decid daca sa remedieze un defect sau nu atunci cand sunt notificati in legatura cu acesta. Folosind o metodologie similara, studiul actual este format dintr-un grup de 20 de persoane, dintre care 16 sunt dezvoltatori in cadrul unei companii, iar 4 dintre ei sunt proaspat absolventi ai Universitatii din Carolina de Nord cu experienta in domeniu. Studiul doreste sa raspunda la intrebarea ce este mentionata in subtitlu prin impartirea ei in trei intrebari diferite: 1. Care sunt motivele pe care le au dezvoltatorii sa foloseasca sau nu uneltele de analiza statica pentru a descoperi defectele? 2. Cat de bine se incadreaza actualele unelte de analiza statica in fluxul de operatii al dezvoltatorilor? Definim fluxul de operatii ca fiind pasii pe care un dezvoltator ii urmeaza atunci cand scrie, inspecteaza si modifica codul. 3. Ce imbunatatiri vor sa vada dezvoltatorii in uneltele de analiza statica? Dupa ce au fost obtinute raspunsurile din interview de la fiecare dintre participanti, atunci acestea sunt descompuse si organizate in categorii pertinente pentru a putea obtine un raspuns general la intrebarile de mai sus: rezultatele uneltelor, ce are in vedere toate rezultatele produse, inclusiv cele gresite;, oferirea suportului pentru lucru in echipa, ce priveste din perspectiva unei echipe sau a unei colaborari folosirea uneltelor de analiza statica; intrarile si particularizarea, ce evidentiaza posibilitatile de particularizare ale uneltelor (definirea de erori particulare ce pot aparea); intelegerea rezultatelor, ce include tot ce a fost spus despre capacitatea de a intelege si interpreta rezultatele produse de catre unealta de analiza statica; fluxurile de operatii, reprezentand legaturile uneltelor cu pasii pe care dezvoltatorii ii urmeaza in dezvoltarea unui produs; modelarea si interfata uneltelor incluzand toate sugestiile participantilor cu privire la acest aspect.

Dupa ce s-au extras portiunile din interview-uri pertinente fiecarei categorii, acestea sunt impartine in pozitive si negative. S-a observat ca majoritatea participantilor au avut probleme cu iesirile uneltei, particularizarea si integrarea in fluxul de operatii si toti, mai putin unul, au avut probleme cu intelegerea rezultatelor.

Figura 3. Rezultatele chestionarelor impartite pe categorii 3.1 Raspunsul la intrebarea 1. Chestionarele au evidentiat mai multe motive pentru care dezvoltatorii ar putea alege sa foloseasca unelte de analiza statica pentru a gasi defecte. Unul evident este reducerea timpului si efortului necesar cautarii manuale a defectelor. Cinci din cei 20 de participanti au spus ca datorita capacitatii uneltelor de analiza statica de a gasi defecte, ele merita folosite. Alt motiv pentru care dezvoltatorii ar alege sa foloseasca uneltele de analiza statica este prezenta acestora in mediul de dezvoltare. Pentru sapte participanti, un motiv bun de a folosi aceste unelte este pentru a ajuta la efortul echipei de dezvoltare. Unii dintre ei sustin utilitatea uneltelor in a evidentia problemele aparute in modulele precedente la integrarea unora noi, altii le folosesc pentru a impune stilurile si standardele de codare pentru echipele de dezvoltare. Trei dintre participanti le considera utile datorita gradului de particularizare al acestora. Chiar daca unii dintre participanti au gasit motive de a folosi unelte de analiza statica, majoritatea au adus argumente negative. Rezultatele uneltelor. Acesta a fost un subiect popular de discutie. 14 dintre participanti au evidentiat impactul negativ al prezentarii proaste a rezultatelor, precum erorile false care pot fi uneori mai numeroase decat adevaratele erori. Alt aspect, in special in cadrul proiectelor mari, este acela ca numarul avertizarilor produse de catre o unealta poate fi mare, uneori de ordinul miilor. Unii dintre participanti sustin ca acest volum poate fi interpretat mult mai usor daca este prezentat intuitiv si user-friendly.

Colaborarea. In acest domeniu, dezvoltarea produselor software este de obicei un efort de echipa. Pentru 9 dintre participanti, lipsa suportului sau prezenta acestuia la un nivel slab dezvoltat pentru lucrul in echipa este unul dintre principalele motive pentru care echipele sau chiar si dezvoltatorii individuali aleg sa nu foloseasca aceste unelte. Personalizarea. Pentru 17 dintre participanti particularizarea este importanta, iar multe dintre uneltele din domeniu nu permit configurarea la nivelul dorit de catre acestia. Alta problema evidentiata este imposibilitatea de a ignora sau bloca anumite avertizari. Chiar daca unele unelte pot opri anumite filtre, nu toti dezvoltatorii doresc sa opreasca avertizarile complet. Intelegerea rezultatelor. Principalul obiectiv atunci cand se foloseste o unealta precum FindBugs este de a afla ce probleme sunt in cod pentru a putea fi rezolvate. Un dezvoltator ce nu este capabil sa inteleaga rezultatele prezentate nu va folosi respectiva unealta. 19 din cei 20 de participanti sustin ca multe dintre uneltele de analiza statica nu prezinta rezultatele intr-un mod din care poti sa deduci care este problema, de ce este o problema si ce ar trebui modificat. Dificultatea mentionata cel mai des este lipsa sau ineficienta solutiilor rapide. Majoritatea participantilor doresc ca uneltele sa aiba sugestii de cod sau solutii rapide relevante atunci cand incearca sa repare o eroare. 3.2 Raspunsul la intrebarea 2. Cel mai discutat punct al chestionarelor a fost integrarea uneltelor in mediul de dezvoltare. Uneori, dezvoltatorul include in procesul sau si executarea unei unelte de analiza statica, dar de cele mai multe ori nu face parte din fluxul de operatii ca acesta sa se opreasca si sa execute o unealta in mijlocul unei sarcini, preferand sa astepte terminarea unei secvente pentru a rula unealta respectiva. Din rezultatele obtinute se pot deduce urmatoarele concluzii: unii dintre dezvoltatori folosesc IDE-uri si ar dori ca uneltele sa fie integrate in acestea si sa ruleze in fundal, iar altii nu folosesc IDE-uri si ar dori ca uneltele sa fie atasate compilatorului. Pe baza rezultatelor obtinute, putem spune ca pentru ca o unealta de analiza statica sa fie utilizata in cadrul fluxului de operatii, atunci trebuie sa ofere posibilitati pentru ambele categorii de dezvoltatori. 3.3 Raspunsul la intrebarea 3. Principalul scop al acestui studiu a fost determinarea metodelor de imbunatatire a uneltelor de analiza statica pentru dezvoltatori. Astfel, participantii au fost intrebati cum doresc proiectarea unei astfel de unelte. Majoritatea modificarilor au fost adresate zonelor de solutii rapide si notificarea si manipularea avertizarilor. Proiectarea solutiilor rapide. Zece dintre participanti au oferit sugestii despre modul cum ar trebui prezentate solutiile rapide. Una dintre acestea se refera la previzualizarea schimbarilor si modul cum acestea vor modifica codul. Astfel, se doreste implementarea unui sistem care sa iti

permita sa implementezi solutia pas cu pas si sa observi modificarile aparute, cat si sa sari peste unele etape ale solutiei rapide. Proiectarea notificarii si manipularii avertizarilor. Toti participantii doresc ca notificarea erorilor sa fie facuta rapid si cu un limbaj coerent mai apropiat limbajului natural. Concluzia a fost ca actualele unelte de analiza statica nu sunt suficient de rapide in oferirea de informatii, cat si lipsa discretiei intrucat nu se doreste intreruperea procesului de dezvoltare. De asemenea, se mai doreste optiunea de personalizare a modului de abordare a avertizarilor pentru a putea lua decizii precum ignorarea temporara a defectelor, salvarea acestora si posibilitatea de a le face publice altor dezvoltatori. 3.4 Concluzii Rezultatele studiului au confirmat faptul ca erorile false si prezentarea informatiilor joaca un rol foarte important in lipsa de satisfactie a dezvoltatorilor cu uneltele de analiza statica existente. Fiecare dintre factorii prezentati in acest studiu trebuie luati in calcul la implementarea unei asemenea unelte intrucat va conduce la o folosire mai raspandita a acesteia pentru a imbunatatii calutatea produsului software. De asemenea, uneltele de analiza statica pot imbunatatii gradul de utilizare in cadrul dezvoltatorilor software prin oferirea suportului pentru colaborare, integrare in cadrul fluxului de operatii, prezentarea intuitiva a erorilor si o explicatie detaliata a acestora cu solutii rapide atunci cand este cazul, cat si optiuni de configurare rapida si folositoare pentru o asemenea unealta.

Bibliografie
Brittany Johnson, Yoonki Song, Emerson Murphy-Hill, Robert Bowdidge Why Dont Software Developers Use Static Analysis Tools to Find Bugs?, 2011, http://people.engr.ncsu.edu/ermurph3/papers/icse13b.pdf

S-ar putea să vă placă și