Projekt 2
Slika 1. Prikaz metrika svih slojeva aplikacije
Sukladno rezultatima prikazanih metrika, može se izvesti nekoliko zaključaka o veličini, kompleksnosti, povezanosti i dubini hijerarhije svakog sloja. Tako redom, po pitanju BusinessLogicLayer-a:
- Maintainability Index (77): Srednja održivost. Iako nije loša, mogla bi biti bolja.
- Cyclomatic Complexity (82): Umjerena složenost; veći broj ciklomatske složenosti ukazuje na više grananja i uvjetnih struktura u kodu.
- Depth of Inheritance (1): Niska dubina nasljeđivanja, što je dobro.
- Class Coupling (64): Umjerena povezanost s drugim klasama. Iako nije previše visoka, ipak ukazuje na potencijalne međuovisnosti koje bi mogle otežati promjene u kodu.
- Lines of Source Code (727), Lines of Executable Code (187): Relativno veliki broj linija izvornog i izvršnog koda, što može ukazivati na složeniji kod.
DataAccessLayer:
- Maintainability Index (80): Dobro održavanje, iako može biti optimizirano.
- Cyclomatic Complexity (149): Visoka složenost. Ova visoka vrijednost ukazuje na veliki broj uvjeta i potencijalno kompliciranu logiku u kodu.
- Depth of Inheritance (2): Niska dubina nasljeđivanja, što je pozitivno.
- Class Coupling (46): Umjerena povezanost s drugim klasama. Potrebno je provjeriti postoji li prostor za smanjenje povezanosti.
- Lines of Source Code (932), Lines of Executable Code (367): Veliki broj linija koda, što ukazuje na značajnu količinu funkcionalnosti ili potencijalno preopterećeni kod.
EntityLayer:
- Maintainability Index (94): Visoka održivost, vrlo dobar rezultat.
- Cyclomatic Complexity (205): Vrlo visoka složenost. Ovo je alarmantan pokazatelj koji sugerira složenu logiku i potencijalne probleme s održavanjem.
- Depth of Inheritance (1): Niska dubina nasljeđivanja, što je dobro.
- Class Coupling (22): Niska povezanost, što je pozitivno.
- Lines of Source Code (475), Lines of Executable Code (19): Umjeren broj linija izvornog koda, ali vrlo mali broj izvršnog koda. Ovo može ukazivati na to da je većina koda strukturalna (npr., deklaracije klasa, polja itd.) bez mnogo funkcionalne logike.
ModelsLayer:
- Maintainability Index (95): Vrlo visoka održivost.
- Cyclomatic Complexity (17): Niska složenost, što ukazuje na jednostavnu logiku u kodu.
- Depth of Inheritance (1): Niska dubina nasljeđivanja.
- Class Coupling (5): Vrlo niska povezanost, što je izuzetno pozitivno.
- Lines of Source Code (68), Lines of Executable Code (9): Vrlo mali broj linija koda, što je obično za model sloj koji sadrži samo definicije podataka i jednostavne validacije.
PresentationLayer:
- Maintainability Index (75): Srednja održivost, što može biti zabrinjavajuće za UI sloj koji obično zahtijeva brze iteracije i promjene.
- Cyclomatic Complexity (746): Ekstremno visoka složenost. Ovo je ozbiljan problem koji ukazuje na vrlo kompliciranu logiku s mnogo uvjeta, petlji i grananja.
- Depth of Inheritance (9): Visoka dubina nasljeđivanja, što ukazuje na složenu hijerarhiju klasa i može otežati razumijevanje i održavanje.
- Class Coupling (170): Vrlo visoka povezanost s drugim klasama, što ukazuje na visok stupanj međuovisnosti i može uzrokovati probleme prilikom promjena u kodu.
- Lines of Source Code (7245), Lines of Executable Code (1082): Ekstremno veliki broj linija koda, što može ukazivati na preopterećeni kod s puno funkcionalnosti.
S obzirom na sva navedena obilježja pojedinog sloja, par stavki se može istaknuti. Prvo, PresentationLayer i EntityLayer imaju ekstremno visok broj ciklomatkse složenosti, 746 i 205, što uzroikuje problem ekstremne složenosti i povezanosti te pontecijalno ukazuje na "code smell". Daljnjom analizom utvrđeni su dijelovi koda s previše odgovornosi i nasljeđivanja te kako bi se otklonio taj problem potrebno je refaktorirati kod, odnosno velik i složene klase i metode podijeliti u manje, specijalizirana komponente koje imaju jasne odgovornosti.
Nadalje, sukladno vrlo visokoj ciklomatskoj složenosti, utvrđena je komplicirana logika s obzirom kako bi Entity sloj u pravilo trebao biti jednostavan. S obzirom na to, sve poslovne logike koje su kompleksnije, trebalo bi raspodijeliti u BusinessLogic sloju te time održati entitete čistima i fokusiranima na definiciju podataka s minimalnom logikom.
Također, može se vidjeti kako i DataAccessLayer ima nešto višu ciklomatsku ovisnost što se, uz detaljniju analizu koda, utvrdilo da je uzrok prevelika količina logike upotrebljena u sloju pristupa podacima. Preciznije rečeno, slo bi pristupa podacima trebao upravljati samo pristupom i manipulacijom podataka, a ne sadržavati poslovnu logiku, što u ovom sloju nije slučaj za sve klase. Tako bi, isto kao i ranije, bila potrebna refaktoracija koda i premještanje sve poslove logike upotrebljene u DataAccess sloju u BusinessLogicLayer.
U ovome će se odjeljku analizirati metrike provedene nad klasam BusinessLogicLayer-a, a da su razvijene u svrhu razvoja sljedećih funkcionalnih zahtjeva:
- FZ11 - Upravljanje opremom
- FZ12 - Grafički prikaz statističkih zadataka
- FZ13 - Dohvaćanje zaboravljene lozinke
- FZ14 - Upravljanje resursima
Slika 2. Prikaz rezultata metrike za klasu EquipmentService
Slika 3. Prikaz rezultata metrike za klasu ResourceService
Iz prikaza iznad (Slika 2. i Slika 3.) može se donijeti nekoliko zaključaka:
- svima članovima klase ciklomatska složenost iznosi 1 što ukazuje na metode s jednostavnom logikom i minimalnim uvjetnim granama
- svima su metodama indeksi održivosti visoki odnosno iznad 75 što ukazuje na jednostavno za razumijevanje i održavanje
- po pitanju povezanosti, većini metoda ova vrijednost iznosi 3 ili manje što je nisko, ali ujedno i dobar znak modularnosti i smanjenje međuovinosti
- dubina nasljeđivanja svim metodama iznosi 1 što ukazuje na jednostavnu hijerarhiju
Sveukupno, klase EquipmentService i ResourceService i njihove metode pokazuju dobar nivo jednostavnosti, održivosti i i niske složenosti, što je pozitivno za dugoročno održavanje i skalabilnost.
Slika 3. Prikaz rezultata metrike za klasu StatisticsService
Rezultati metrike klase StatisticsService nešto su lošiji te ukazuju na sljedeće zaključke:
- Klasa StatisticsService u globalu ima relativno nizak indeks održivosti i visoku ciklomatsku složenost što navodi na teže održavanje u budućnosti.
- Metode AttendanceByMonths i Gender imaju niske indekse održivosti i visoku ciklomatsku sloiženost što ukazuje na "code smell" pa se detaljnijom provjerom utvrdila prevelika složenost metoda.
- Metode Group i AttendanceByMonths imaju visoku povezanost s drugim klasama što će potencijalno u budućnosti otežati održavanje i testiranje.
Sukladno navedenim problemima, preporučuju se sljedeća poboljšanja:
- Složene metode AttendanceByMonths i Gender trebaju biti razmotrene za refaktoriranje kako bi se smanjila složenost. Razdvajanjem kompleksnih logičkih dijelove u manje, specifične metode doprinijet će povećanju razumljivosti i smanjenju kompleknosti koda.
- Također bi bilo dobro smanjiti povezanost između metoda i drugih klasa.
- Dodavanje komenatar za lakše razumijevanje koda.
Slika 4. Prikaz rezultata metrike za klasu EquipmentRepository
Slika 5. Prikaz rezultata metrike za klasu ResourceRepository
S obzirom na rezultate priloženih slika (Slika 4. i Slika 5.), došlo je do sljedećih zaključaka:
- Obje klase (EquipmentRepository i ResourceRepository) imaju dobar indeks održivosti (81), što znači da su klase relativno jednostavne za održavanje.
- Umjerena složenost (Cyclomatic Complexity 11) sugerira da postoji nekoliko logičkih grana unutar klasa, što je normalno za klase koje upravljaju pristupom podacima.
- Metode Remove i Update imaju niže indekse održivosti, 68 i 66, što ukazuje na složeniju logiku odnosno složenost funkcija koje su teže za održavanje.
- Veća povezanost kod metoda Update sugerira da ove metode mogu imati više ovisnosti o drugim klasama, što povećava kompleksnost.
Kako bi se uklonili problemi ili smanjio utjeca istih, sljedeće su preporuke:
- Refaktoriranje metoda Remove i Update: Podijelite logiku u manje, specifične metode kako bi se smanjila složenost i povećala održivost.
- Smanjenje povezanosti: Upotreba dependenciy injection-a ili apstraktnih slojeva za smanjenje izravnih ovisnosti.
Slika 6. Prikaz rezultata metrike za klasu Equipment
Slika 7. Prikaz rezultata metrike za klasu Resource
Što se tiče klasa Equipment i Resource, obje klase imaju visok indeks održivosti, što znači da su jednostavne za održavanje i imaju minimalnu složenost. S druge strane, bilo bi dobro smanjiti ovisnost unutar Resource() konstruktora.
Slika 8. Prikaz rezultata metrike za sve klase ModelyLayer-a
Po priloženim rezultatima vidi se kako sve klase imaju vrijednosti u zadovoljavajućem rasponu. Eventualni prijedlog za napredak koji bi se mogao primijeniti u ovome sloju je dodati komentare radi lakšeg razumijevanja pojedinih dijelova.
Slika 9. Prikaz rezultata metrike za sve klase PresentationLayer-a kreirane za FZ11, FZ12, FZ13 i FZ14
Automatizirana rezencija programskog koda pokrenuta je sa alatom SonarLint te su u nastavku priloženi rezultati samo onih klasa koje se odnose na sljedeće funkcionalne zahtjeve:
- FZ11 - Upravljanje opremom
- FZ12 - Grafički prikaz statističkih zadataka
- FZ13 - Dohvaćanje zaboravljene lozinke
- FZ14 - Upravljanje resursima
Slika 10. Rezultate automatizirane recenzije koda SonarLint alatom
Na softverskom je rješenju provedeno jedinično testiranje tj. kreirane su klase sa jediničnim testovima koje pokrivaju sljedeće funkcionalnosti:
- FZ11 - Upravljanje opremom
- FZ12 - Grafički prikaz statističkih zadataka
- FZ13 - Dohvaćanje zaboravljene lozinke
- FZ14 - Upravljanje resursima
Time su klase StatisticsService.cs, EquipmentService.cs, ResourceService.cs i EmailService.cs pokrivene u potpunosti dok je klasa UserService.cs pokrivena djelomično, točnije samo dio koji se odnosi na ForgotPassword funkcionalnost sukladno tome kako je za ostatak kreirane klase zadužen drugi član tima iz prethodnog kolegija.
Slika 11. Rezultati kreiranih i provedenih jediničnih testova
Slika 12. Prikaz pokrivenosti koda jediničnim testovima
Na softverskom je rješenju provedeno integracijsko testiranje tj. kreirane su klase sa integracijskim testovima koji pokrivaju sljedeće funkcionalnosti:
- FZ11 - Upravljanje opremom
- FZ12 - Grafički prikaz statističkih zadataka
- FZ13 - Dohvaćanje zaboravljene lozinke
- FZ14 - Upravljanje resursima
Slika 13. Rezultati kreiranih i provedenih integracijskim testova
U procesu razvoja nove funkcionalnosti, koristila sam se pristupom Test Eventual Development (TED), pretežito zbog jednostavnosti primjene i provjere dodane funkcionalnosto. jihovu kombinaciju.
Tijekom implementacije, koristila sam GitHub Copilot za generiranje programske logike i testova. Na primjer, pri implementaciji dodatne opcije za pretraživanje resursa i opreme, Copilot je efikasno generirao dio koda posvećen responzivnosti XAML prozora, čime je uz uštedu vremena i povećane produktivnosti i došao do najoptimalnijeg koda po pitanju kompleksnosti istog. Međutim, bilo je slučajeva kada su prijedlozi bili nedostatni ili neprecizni, što je zahtijevalo dodatne korekcije. Ove situacije su bile korisne za bolje razumijevanje ograničenja alata i za prilagodbu njegovih prijedloga.
Također sam koristila ChatGPT za generiranje ideja za testne slučajeve, prijedloge za implementaciju i povratne informacije na već napisani kod. ChatGPT je bio izuzetno koristan u pružanju različitih perspektiva i prijedloga za poboljšanje funkcionalnosti. Međutim, ponekad su prijedlozi bili previše općeniti ili nisu u potpunosti odgovarali specifičnim zahtjevima, što je zahtijevalo dodatnu provjeru i prilagodbu, ali je u velukoj količini pomogao u učenju o drugim načinima rješavanja problema u domeni koju sam htjela nadopuniti.
Slika 14. Prikaz sučelja za pretraživanje opreme
Slika 15. Prikaz funkcionalnosti pretraživanja opreme
Slika 16. Prikaz sučelja za pretraživanje resursa
Slika 17. Prikaz funkcionalnosti pretraživanja resursa