V súčasnosti vo svete informačných technológií prebieha veľké množstvo vývojárskej práce. Kód sa stáva väčší a vznikajú rozsiahle aplikácie. Tento článok je zhrnutím diplomovej práce, ktorá sa zaoberá spôsobmi ako zjednodušiť štúdium zdrojového kódu a jeho úpravu. Je vykonaná analýza rôznych nástrojov a metód pre vyjadrovanie zámeru v zdrojovom kóde. Následne je kladený dôraz na vytvorenie nástroja na prepojenie zdrojových kódov s prípadmi použitia na základe nízkej úrovne granularity. Úspešnosť výsledného riešenia je overená pri implementovaní informačného systému a vykonaním používateľského testovania na vzorke vývojárov.
Existuje množstvo vedeckých prác ako v zdrojovom kóde zachovať zámer. Niektoré spôsoby sú určené konkrétnemu programovaciemu jazyku a zasa iné sa vyznačujú použitím pre viaceré jazyky. Niektoré prístupy nám vopred určia architektúru aplikácie, ktorej sa počas celého vývoja treba držať, aby bol zámer zachovaný.
Analyzované riešenia
V diplomovej práci bolo analyzovaných päť hotových riešení pre vyjadrovanie zámerov v zdrojovom kóde. Každé z týchto riešení má svoje výhody a nevýhody. Na nasledujúcom obrázku sa nachádza zoznam kritérií s jednotlivými výsledkami pre analyzované riešenia. Volené parametre slúžia na určenie šírky škály použitia daného riešenia pre rozličné projekty a popísania jeho schopnosti jednoducho a efektívne spolupracovať s vývojárom. Takéto zhrnutie a porovnanie výsledkov umožnilo vykonať rozhodnutie nad ďalším smerovaním tejto práce. Prázdne bunky v tabuľke reprezentujú odpoveď Nie.
Prípad použitia
Prípady použitia sa javia ako správny prostriedok pre zaznamenanie zámeru. Preto je potrebné sa oboznámiť s jeho základnými časťami. Samotný prípad použitia môže obsahovať viacero časti. Nie všetky časti sú povinné. Nižšie sú uvedené tie najdôležitejšie:
- rozsah
- primárny aktér
- vstupné podmienky
- spúšťač
- hlavný scenár
- rozšírenia
- odkazy na iné prípady použitia
Identifikované požiadavky na produkt
Požiadavky, ktoré sú kladené na výsledný produkt je ponúknuť vývojárovi nástroj, ktorý bude automatizovane vytvárať väzby na nízkej úrovni granularity resp. riadkoch. Nástroj by mal byť schopný vytvárať väzby medzi všetkými typmi súborov, ktoré sa nachádzajú v projekte informačného systému. V prípade, ak o to používateľ požiada je vykonaná projekcia na základe bodu prípadu použitia a zobrazené všetky náväznosti. Táto operácie môže prebehnúť aj opačne a to nájdením prípadu použitia pre označenú časť zdrojového kódu.
Navrhnuté riešenie
Konceptuálny model riešenia pozostáva z troch hlavných časti, ktoré sú znázornené na obrázku:
Prípady použitia
Táto časť reprezentuje jednotlivé súbory s prı́padmi použitia, ktoré budeme použı́vať počas vývoja projektu. Budú slúžiť ako vstupné súbory pre mapovaciu aplikáciu.
Mapovacia aplikácia
Modul s mapovacou aplikáciou tvorı́ jadro celého systému. Aplikácia na vstupe prijme prı́pady použitia a taktiež samotný projekt, ktorý obsahuje zdrojové a iné súbory. Jej úlohou je vytvárať väzby medzi spomenútymi časťami.
Projekt
Táto časť zahŕňa celý projekt, ktorý chceme previazať s prı́padmi použitia. V tomto projekte sa môžu vyskytovať zdrojové kódy, textové súbory, ale taktiež aj binárne súbory ako sú naprı́klad obrázky, zvukové nahrávky a iné.
Vytvorené riešenie a jeho použitie
Riešenie boli implementované pre platformu IntelliJ 3, ktorá v súčastnosti je stále populárnejšia.1 Vytvorené riešenie je vo forme pluginu zloženého z viacerých komponentov. Prvý komponent použı́vateľského rozhrania s názvom Usecase Project Window sa použı́va pre zobrazenie prı́padov použitia.
Súčasťou tohto komponentu je aj panel s akciami. Panel pozostáva z tlačidiel, ktoré reprezentujú akcie ako previazanie zmien s bodom prı́padu použitia alebo vykonanie projekcie bodu prı́padu použitia za účelom zobrazenia úsekov kódu, ktoré s daným bodom súvisia, resp. sú previazané.
Druhý komponent reprezentuje okno, v ktorom sa nachádza zoznam odkazov na časti zdrojového kódu, ktoré súvisia s projektovaným bodom prı́padu použitia. Úseky zdrojových kódov sú vizualizovane vo forme stromu, kde po dvojkliknúti na daný riadok je použı́vateľ presmerovaný do editora súboru. Takisto po vykonanı́ tejto akcie sú zvýraznené všetky časti kódu, ktoré sú súčasťou väzby. Takýto prı́stup umožňuje vývojárovi jednoducho nadobudnúť vedomosť, ktorá časť kódu implementuje projektovaný bod prı́padu použitia.
Plugin ma integrovanú funkcionalitu pre vyhľadania bodu prı́padu použitia priamo z riadku zdrojového kódu. Stačı́, ak je umiestnený kurzor na riadku a po kliknutı́ na pravé tlačidlo sa zobrazı́ kontextové menu, v ktorom je možnosť Find UseCase. Po kliknutı́ na túto možnosť plugin vyhľadá bod prı́padu použitia.
Výsledky testovania produktu v praxi
Všetky popísané kritériá, ktoré boli predmetom testovania produktu v praxi sú vyhodnotené v tabuľke, kde sú porovnané aj s ostatnými produktami, ktoré boli prevzaté z analytickej časti.
Ďalším testovaním boli identifikované problémy výsledného riešenia. Chybovosť najčastejšie vznikala pri používaní pluginu v prípade, ak boli modifikované už napísané časti zdrojového kódu. Takouto modifikáciou vzniká potreba upravenia už existujúcich väzieb po vykonaní operácie Attach. V tomto momente museli byť všetky pred tým vykonané náväznosti premapované na nové riadky. Táto operácia neprebehla vždy na 100 %.
Ďalší zistený nedostatok bol pri vývoji rovnakého projektu na viacerých zariadeniach. V takom prípade za používania pluginu na oboch zariadeniach prebiehalo všetko v poriadku až do momentu kedy mal byť vykonaný merge request vo verziovacom systéme Git.
Prieskum používania pluginu pri doplňovaní funkcionality do hotového projektu
Pre získanie lepšej predstavivosti, v akej miere je vytvorené riešenie použiteľné pre doplňovanie funkcionality v hotovom projekte, bol vykonaný prieskum na vzorke piatich vývojárov. Práve päť vývojárov podľa Jakoba Nielsena stačí na odhalenie 75 % problémov s použiteľnosťou. 2
Každý člen dostal rovnaký pripravený projekt v pôvodnom stave. Každý z nich používal integrované vývojové prostredie Intellij IDEA. Všetkým bol predstavený plugin a bola vysvetlená funkcionalita daného nástroja a takisto všetky operácie, ktoré je možné v ňom vykonávať. V upravovanom projekte bola upriamená ich pozornosť na vysvetlenie prípadov použitia a akým spôsobom sú reprezentované v danom projekte.
Aké zložité bolo pochopiť zadanie ?
Každý z vývojárov odpovedal na túto otázku, že zadanie bolo dobre pochopiteľné. Forma prípadu použitia bola ohodnotená ako veľmi dobrá a o to viac, že prípad použitia bol zakomponovaný medzi ostatnými prípadmi použitia a využitím \textbf{include} v prípade použitia bolo jasné kedy bude funkcionalita zavolaná.
Aké zložité bolo zistiť kam doplniť funkcionalitu ?
V troch z piatich prípadov, bolo identifikované miesto, kam doplniť funkcionalitu ihneď. V tomto prípade bola okamžite využitá funkcionalita projekcie aby bola identifikovaná časť v kóde, ktorá sa týkala odosielania správ. A teda týmto spôsobom bola nájdená časť, kam je potrebné implementovať transformovanie emotikon.
Zvyšní dvaja členovia taktiež skúšali vykonať projekciu kódu, avšak nad zlým bodom prípadu použitia. V tomto prípade sa jednalo o body prípadu použitia, ktoré mali byť vypracované.
V oboch prípadoch bola kladne ohodnotená možnosť bez dodatočné skúmania zdrojového kódu vedieť preskočiť na riadok kódu kam bolo potrebné implementovať funkcionalitu. Vo výsledku bol ušetrený čas vývojára.
Spomaľovalo Vás spustenie vykonanie operácie Attach po implementovaní danej funkcionality ?
V troch prípadoch bola odpoveď skôr nie. V tomto prípade bola pripomienka mať dostupnú funkcionalitu prostredníctvom klávesovej skratky.
V dvoch prípadoch sa jednalo o odpoveď áno. V tomto prípade dôvodom bolo prerušenie vykonávania práce a neustáleho označenia prípadu použitia a vykonanie operácie Attach. Po otázke či by bolo vykonanie operácie Attach prekážkou aj v prípade, ak by boli samotné prípady použitia písané viac abstraktne ako tie v zadaní, odpoveď bola upravená na takmer vôbec.
Viete si predstaviť používanie pluginu v praxi ?
V dvoch prípadoch bola odpoveď skôr áno a v troch prípadoch skôr nie. Argumentom bolo to, že samotný plugin je založený na verziovacom systéme Git, ktorý daný vývojári by chceli mať pod vlastnou kontrolou. Po navrhnutí či by ich postoj sa zlepšil ak by plugin bol založený na nezávislej technológií alebo ak by samotná operácia Attach mala vlastné okno v ktorom by si sami mohli zvoliť, ktoré časti kódu ku akému prípadu použitia prepojiť sa odpoveď zmenila na skôr áno.
Ďalším argumentom bol nepohodlný zápis prípadu použitia a problémy pri vykonaní merge request.
Považujete funkcionalitu FindUsages za užitočnú?
Každý vývojár odpovedal na túto otázku áno. Dôvodom bolo rýchle a jednoduché zistenie komplexnejšieho obrazu o celom projekte. Vďaka tejto funkcionalite mali okamžitú predstavu do akého kontextu patrí aktuálne analyzovaný riadok v zdrojovom kóde. To bolo docielené vďaka tomu, že bol automatický expandovaný strom s daným prípadom použitia a zvýraznený krok, ktorý súvisí z daným riadkom kódu.
Záver
Vyhodnotením sa dospelo k záveru, že funkcionality, ktoré boli implementované majú zmysel pre praktické použitie počas vývoja informačného systému. Vytvorené riešenie obsahuje podporu viacerých programovacích jazykov, je integrované v IDE, dokáže vykonať projekciu zámeru na základe bodu prípadu použitia, dokáže vytvárať väzby na binárne súbory a granularita väzieb je na úrovni riadkov, čo zvyšuje flexibilitu pre vývojára, ktorý implementuje svoje riešenie.
Vytvorený produkt má potenciál byť uplatnený v praxi. Samotná myšlienka a aj používanie boli hodnotené výrazne kladne. Nedostatky boli identifikované v prípade spôsobu implementácie daného riešenia a to hlavne čo sa týka paralelnej práce na rovnakom súbore a ich následnom zlúčení.
Zdroj
- Primárnym zdrojom je diplomová práca(STRUK L., Nástroje a metódy na previazanie zdrojového kódu s prípadmi použitia).
- Sekundárne zdroje, ktoré sú dostupné online sa nachádzaju vo forme odkazu v konkrétnch častiach článku.