Az a baj, hogy sok esetben a forras szimpla parse-olasa nem er semmit. Pont a *-os importok miatt szinte konnyebb a bytecode-bol kiindulni, mint a forrasbol.
De a legegyszerubb eclipse plugin project-te alakitani az egeszet, akkor ezeket a dolgokat tobbe-kevesbe keszen kapod.
Viszont a beavatkozasokat nehezebb. Szerintem egy igazan poweful eszkoz, amely akar automatikusan alkalmaz, kijavit/"normalizal" policy-knek megfeleloen kodokat, csak abstract/concret syntax tree-vel oldhatoak meg szepen.
Ezert nem tetszik, hogy a C# 3.0-at tele akajak aggatni mindenfele extra featurrel, megnehezitve ezzel a parserek irasat ehez a nyelvhez. Javahoz egyebkent vannak jo parser generatorok, pl. az antlr. A kesobbi bovithetoseg kedveert en mindenkeppen parsolnam a forrast, es nem reflection segtisegevel oldanam meg.
Jogos. Most, hogy csak az import-okat figyelembe veve nyerem ki a dependency-ket, egyszeru volt a forrast elemezni, viszont a mely elemzest asszem tenyleg egyszerubb lesz a class fileokon elvegezni.
Probaltam a lenyeget kiemelni, es szerintem a dependency a legfontosabb es legaltalanosabb relacio a design minosege szempontjabol. Raadasul azert is erdekes, mert konnyen ertelmezheto altalanosan mas rendszerekre is, nem csak OO rendszerekere.
De amugy jo otlet megadni a lehetoseget azoknak a relacioknak a megjelenitesere, amiket irsz. (Sot akkor tulajdonkeppen a policy-kat is ki lehet altalanositani tetszoleges relaciora: a R b tilos, ahol R tetszoleges relacio) Jelenleg meg technikai akadalyai is vannak, hogy nem tudom ezeket a relaciokat megjeleniteni: Jelenleg meg nem vegzek mely parseolast, a dependency-ket is csak az import statementekbol allitom ossze, illetve package-en belul egyszeruen dependency-t detektalok, ha egy szomszedos osztaly nevet tokenkent megtalalom. Tervezem rendesen parseolni a java kodot, es ha ez meglesz, akkor nem lesz akadalya mas relaciok megjelenitesenek sem.
Azt mondatja velem az intuiciom, hogy nem. (Ertsd: nem gondoltam vegig a kerdest :))
A normalformakhoz emlekeim szerint eroteljesen kihasznaltuk a relacios algebra kulonbozo tulajdonsagait, es ugy definialtunk fuggosegeket, amiket aztan jol megszuntettunk.
Viszont ha finomabb lenne a felbontas (metodus szintu mondjuk), akkor mar lehetne olyan reszgrafokat keresni, amik majdnem biztosan design hibat takarnak.
(Upsz, most latom csak, hogy a leaszramazasi hierarchiat milyen ugyesen sikerult kihagynom a modellbol... :/ )
Eszembe jutott meg, hogy nem lehetne-e valamifele adatbazis normalizacios technikakhoz hasonloan hierarchiak kozotti normalizaciokat definilani matematikai keretek kozott.
A tipus fuggoseg es a package-ek egy abran megjelenitesenek imho ket oka lehet (legalabbis en ezt a ket dolgot tartom jonak egy ilyen abraban):
1. Attekinthetoseg. Konnyu megkeresni az adott kodot. 2. Mivel illik torekedni arra, hogy a modulok kozotti interakcio a szukseges minimumra legyen leszoritva, es hogy az encapsulation nevu dolgot lehetoseg szerint komolyan vegyuk (lasd meg a Commando nevu resign patternt :)), ez a megkozelites jo kepet mutat arrol, hogy ezt mennyire sikerult megtenni. Egyertelmu, hogy ha tul sok vonal fut ket modul adott reszhalmazai kozott, akkor rosszul vannak definialva a modulhatarok.
En is gondolkodtam egy keveset, komolyabb kodparsolas nelkul a kovetkezo kod-objektum modellt latom felallithatonak (.NET):
Ertelem szeruen az onmagara mutato elemeket erdemes hierarchiakent abrazolni, azonban elsokorben nem tartom nagyon fontosnak ennek konkret grafikus kinezetet, sokkal inkabb az interkaciot, a modoistasok azonnali megjeleneset mind a kodban, mind a reprezentacioban.
A te kezdemenyezesed a namespace hierarchiat egyutt abrazolja a tipus dependencia hierarchiaval. Nem ismerem az okat annak, miert pont ezt a kettot valaszottad. Talan usability szempontok szerint, en viszont nem vagyok usability szakember.
Ebbol az alapabrabol kiindulva szepen ki lehet bonatni szinte egesz szemantikat. Pl hamarosan elkeszitem a Type reszletezeset.
Kiraktam a 0.92-es verziot. Rengeteg ujitas van benne, a 0.91 ota szinte teljesen atgyurtam a kodot:
- .svg-be es .png -be is kepes exportalni, az oldalon minden pelda-diagram mindket valtozatban elerheto. - Megvaltozott a megjelenites modja: az elhelyezes teljesen a dependencyk alapjan tortenik, a package hierarchia masodlagos szempont lett es szinkodokkal van kodolva... - Uj algoritmus a korok lerakasara, ami az elozonel joval optimalisabb es veletlen elemet nem tartalmaz (determinisztikus). - Statisztikak, design measure-ok. Kulonos tekintettel az 'SFTViz Complexity' nevu komplexitasbecslesre. - Policy-k definialasi lehetosege, policy violation detektalas es pirossal arazolas.
A dokumentaciot is updateltem.
Tovabbra is szivesen varom a kritikakat, eszreveteleket es a bugreportokat.
Egyelore elsosorban a dependency diagramra koncentraltam/koncentralok.
Esetleg ha beleegyezel, es eleg komollya valik a dolog, szivesen portolnam C#, VS.NET editor/designer kornyezetbe.
Ok, errol majd beszeljunk, orulnek neki, en nem nagyon ertek a C#-hoz / .NET-hez.
ha az egerrel ramesz egy korre, akkor a tartalma kinagyitodik. Vagy lehetne a modositast tamogatni ebben a nezetben, pl atmozgathatsz egy tipust egy masik namespace-be, ugy, hogy minden hivatkozasa koveti.
Ezek jo otletek. Mindketto nagyon hasznos feature lenne, felvettem oket a todo list-emre. (Ez a drag-and droppal valo athelyezgetes elegge megfogott, tulajdonkeppen erdemes lenne azon is elgondolkodni, hogy milyen refaktoralasi lepeseket lehetne esetleg jol vizualisan tamogatni a sima athelyezesen kivul is.)
Szerintem ezen tengely elemeihez lenne erdemes kulonfele view-kat definialni:
analizis - design - implementation - test - deploy
Siman mindegyikhez talahato 4-6, egymastol nagyjabol fuggetlen szempontokat kepviselo view. Ez onmagaban is legalabb husz view, ebbol amit megcsinaltal az egy db. Tervezed tovabb boviteni ilyen iranyban?
Esetleg ha beleegyezel, es eleg komollya valik a dolog, szivesen portolnam C#, VS.NET editor/designer kornyezetbe.
Masik aspektusa az egesznek, hogy lehetne az interakciot novelni, pl. nem statikus abrak, hanem ha az egerrel ramesz egy korre, akkor a tartalma kinagyitodik. Vagy lehetne a modositast tamogatni ebben a nezetben, pl atmozgathatsz egy tipust egy masik namespace-be, ugy, hogy minden hivatkozasa koveti. Ez is egeszen jol novelne a produktivitast.
En nem talaltam epkezlab svg -> raszteres formatum konvertert, ugyhogy nem tudtam konvertalni, a print screen meg nem jo, mert valmelyik kep nagyobb mint egy kepernyo.
Igen, erre mar en is gondoltam; elobb utobb elkerulhetetlen lesz interaktivva tennem a programot, hogy menet kozben lehessen +- -al kinyitogatni koroket. Valoszinuleg Eclipse plugin lesz a dologbol. Ha kiforrottabb lesz ez az egesz, akkor jo lenne mas nyelveket is analizalni, pl. C#-ot.
Trukkos, szoval ez volt az a "strategiai jatek", amelyhez a gombos peldat meg kellett oldani az "erdekes programozasi feladatok" topicban. :)
Az a feladat tenyleg egy jatekhoz kellett, pont annak a jateknak a forrasanak a diagramja van fent az oldalamon.
Itt egy masik feladat van: a koroket ugy elhelyezni, hogy ne foglaljanak tul sok helyet, es a dependency vonalak minel rovidebbek legyenek. Ez egy nehezebb feladat.
Ezt egyszeruen tovabb lehet gondolni, a ki-be kapcsolt allapotokbol szinten fa keszitheto, amely templetizalhato, esetleg a nezethez lekerdezo nyelv deklaralhato. Annak idejen XML-ben probaltam reprezentalni C++ kod konkret szintaxisat, lekerdezo/generalo nyelvnek pedig az XSLT-t szantam. Tul sok munka lett volna, az XSLT-t akkor gyuloltem meg. :)
Viszont lekerdezo nyelvnek nagyon jonak talalom a Rational ClearCase verziokoveto rendszer View definialo nyelvet. (Szerintem a CC-ben igy megoldott problema nagyon analog a "mi legyen lathato" kerdessel.)
Jol latom, hogy tipusnal finomabb felbontasba nem megy bele? Absztraktabb szempontok szerint valo abrazolashoz ez elkerulhetetlen lesz. Sajna ebbe tort bele mindig a bicskam.
En egyebkent kulonbozo aspektusonkent valo "view"-k generalasat tartom kovetendo utnak, amelyekben a hierarchikus adatok szintjet interaktivan (pl. +/- ki-be kapcsolgatassal) lehet meghatarozni.
Amely egy reszenek implementacioja ugyanezen szerzotol reflector neven keszul, es hozzaferheto (nap mint nap hasznalom, .NET-eseknek nagyon ajanlott tool).
De amugy a lenyeges-lenyegtelen reszek approximalasara vannak azert modszerek. Ott van rogton a hivatkozasok szama, de mondjuk ha egy profiler outputot is beledolgozol az abradba (ez pl. egy hasznos kiegeszitesnek tunik), akkor mar egesz jo kepet tudsz kapni rola.
Koszi, most mar nagyjabol jobban ertem, mi is ez a program.
A kor szerintem tutira design hiba. )Marmint ha valoban modulok kozott van.) Ha valakik korben hivatkoznak egymasra, azok annyira szorosan osszekapcsolodnak, hogy nem jo oket kulonszedni. Sokkal valoszinubb viszont, hogy egyes hivatkozasok foloslegesek.
(Mondjuk a rossz designt altalaban szemmel ki lehet szurni. Ha ranezesre latszik ez, akkor azert, ha tul bonyolult a program ahhoz, hogy ranezesre tudd kovetni a dependenciakat, akkor azert. :))
Arra akartam utalni, hogy valószínűleg azért használtál obfuscator-t, hogy nehogy valaki "ellopja" a programodat
Igen, azert hasznaltam obfuscatort, mert nem akartam publikalni a forraskodot, vagyis nem akartam, hogy masok tovabbfejlesszek amit irtam. (Java eseten ha nem akarom publikalni a forraskodot az auomatikusan obfuscator hasznalatot is jelent nalam.) Jelenleg persze nem nagy munka lekodolni valakinek amit irtam, de ha tobb munkat fektetek majd ebbe a project-be, akkor jol jon, hogy mar az elejen + egy het munka elonyben vagyok masokkal szemben. Azt elismerem, hogy sokak szemeben ez nem szimpatikus, de nem is akarok mindenkinek szimpatikus lenni, azt mar regen megtanultam, hogy erre nem erdemes torekedni.
Amugy lattam mar a neten olyan 'vitakat', hogy valaki belekotott valakibe, hogy miert nem publikalja a programja forraskodjat. Manapsag ez nagy divat olyanok koreben is, akik maguk sem publikaltak meg forraskodot soha eletukben. Persze te lehet, hogy kivetel vagy, es ontod magadbol az open source-ot, ebben az esetben legalabb van erkolcsi alapod a velemenyedhez.
---
Lényeg kiemelés: Egy nagyobb programban rengeteg osztály és függvény van, de ennek csak része (max. 10%-a) "lényeges" a program megértése szempontjából.
Igen. En a legfontosabb, es szerintem legfundamentalisabb design informaciot jelenitem meg: a dependency-t. (Illetve az egyes nodeok merete a benne levo forraskod meretevel aranyos, az is fontos info, hiszen mas informacio az, hogy 20 sor kod nem fugg csak 2 node-tol, vagy 2000 sor nem fugg csak 2 node-tol.)
De meg ez is tul sok informacio. Ha default parameterezessel futtatod a programomat, akkor egy nagyobb projekt eseten egy suru erdot latsz meg akkor is ha eleg jol van tervezve. Ezert talaltam ki egy par command line parametert, amivel egy kicsit finomitani tudod, hogy mit jelenitsen meg, es mit takarjon el. (Pl. ne jelenitse meg a utility csomagokat es a ra valo dependeciat, illetve kulon allithato, hogy egyes package-ket mennyire reszletezzen, stb...)
Meg az az elborult otletem is tamadt, hogy vajon milyen design patternek leteznek, ha nem tudjuk, hogy az egyes node-ok miert dependalnak mas node-okra, csak annyit tudunk, hogy dependalnak. Magyarul vannak a hierarchiaba (package-kbe) rendezett tomeggel sulyozott node-ok (itt a tomeg a forras sorok szama), es koztuk vizsgaljuk a dependency relaciot. Fuggetlenul, hogy ezek most OO osztalyok, vagy hardver IC-k, vagy mas modularis rendszer moduljai: leteznek-e vajon altalanos patternek a jo design-ra, vagy a rossz design-ra? Lehet-e ennyire altalanos szinten mondani valamit a design josagarol? Pl. az biztos, hogy ha eleg apro reszekre (kis tomegu node-okra) bontva a rendszert, ha minel kisebb a dependency vonalak szama, annal jobb a design. Ez mar korvonalaz egy design merteket, most a konkret kepleten gondolkodom. De pl. valahol olvastam olyat, hogy a korbe-dependency-k szamat is minimalizalni kell. Lehet, hogy ez is egy fontos mertek. Meg az is megfordult a fejemben, hogy esetleg a program alternativakat is felajanlhatna csak ezen a node-dependency graf szinten gondolkodva.
Ui:
Egyebkent erdekes reszproblema a node-ok olyan modon valo elhelyezese ebben a kor hierarchiaban, hogy minel kevesbe legyen kusza, vagyis az egymasra dependalo node-ok minel kozelebb rajzolodjanak egymashoz. Most eleg egyszeru heurisztikakat alkalmazok, ennel biztos ki lehet majd talalni jobbat, es ezaltal csokkentheto a kuszasag (atlathatatlansag) problemaja.
Nem arra gondoltam, hogy a jar szándékosan kárt tenne a gépemben. Őszintén szólva, ez eszembe sem jutott.
Arra akartam utalni, hogy valószínűleg azért használtál obfuscator-t, hogy nehogy valaki "ellopja" a programodat. Mondjuk van olyan eset, amikor tényleg indokolt, hogy a fejlesztő félti a szellemi termékét, esetleg a kódban levő zseniális -vagy annak vélt- ötletét. De egy ekkora kis kezdemény esetén ezt az én finoman szólva is túlzásnak tartom. Ráadásul azt üzeni a letöltőnek, hogy "ne akarj belenézni, mert ez titok". Legalábbi én ezt éreztem, és ezért gondoltam azt, hogy bizalmatlan vagy azokkal szemben, akik megnézik a programodat.
---
Témához visszatérve: az Eclipse-ben (meg gondolom a NetBeans-ben is ) van egy csomó nézet, amivel olyasmit lehet megjeleníteni, amit te szertnél: call, caller, type hierarchia. Ezeket nagyon gyakran használom, és mindegyik egy-egy nézetét adja az adott kód kupacnak.
Szerintem két problémád lesz a vizualizációval kapcsolatban:
1. Lényeg kiemelés: Egy nagyobb programban rengeteg osztály és függvény van, de ennek csak része (max. 10%-a) "lényeges" a program megértése szempontjából. És a forrásód alapján szinte lehetetlen eldönteni, hogy melyik a lényeges kacsolat, és melyik az amelyik csak kiegészítő.
2. Több dimenzió: Sokféle szempont szerint lehet nézni egy kódot. Ezek a nézetek többnyire valamilyen fa struktúrát eredményeznek, de nem tudom hogyan lehet -akárcsak két- független fa struktúrát szépen, átláthatóan és egy ábrán "vizualizálni". A különféle színű vonalak használata szerintem nem jó megoldás.
