.jpg)
Előző blogposztom után ért néhány impulzus, ami további tárgybeli téma-firtatásra sarkallt.
MTA-workshop ~ A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái
(1) Kovács Gyula az Andego Kft szineiben publikált egy nagyszerű blogposztot, ha mást nem nézünk csak az ábráját, akkor is sokkal érthetőbb lett a megközelítés és precízebb megvilágításba helyezte az egész témát - pláne adatbányász kontextusban -, mint nekem sikerült a vázlatommal.
Modellek nyugdíjban
(2) Gyula megosztotta az MTA-esemény eredeti meghívó linkjét. Ezt most én is megteszem:a teljesség kedvéért.
Tudományos ülésszak „A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái” címmel
A meghívón láthatóan volt tehát a hatodik záróelőadás a friss Akadémia-díjas előadó által:
Gyimóthy Tibor, az MTA doktora: Karbantartási problémák millió sor felett.
Két további lényeges impulzus ért a témában:
(A) A Java levelezési listán lévő közös gondolkodás, ami odáig "fajult", hogy elkezdtem keresni az eredeti előadás alapját képező cikke(ke)t.
(B) Nagy küzdés után megtalált cikk világos, szép, igényes, módszertana adatbányász szívnek kedves.
Columbus: A Reverse Engineering Approach
New Conceptual Coupling and Cohesion Metrics for Object-Oriented Systems
Akik nem akarnak elmerülni a részletekbe azok számára (meglehet torzított) rövid értelmezésem az alábbi.
A cikk előtt én az alábbit gondoltam a csatolásokról:
Csatolás/Coupling, szoros klasszikus értelemben és OO paradigmában - minden osztályok közötti metódus hívás-, mező/property-elérés-, öröklés-, argumentum/paraméter-, visszatérési érték-, kivétel-érintettség (ha Eiffelben lennénk, akkor ideírnám a szabály-érintettséget is) és ha valamit kihagytam akkor bocs.
Csatolás tágabb értelemben minden, információt hordozó, valamilyen erősséget reprezentáló és adott hatást generáló összefüggés/kapcsolat, számomra a legközelebbi angol terminus: a linking.
Adott a szegedi egyetem által több éve kifejlesztett Columbus nevű, C/C++ - szoftverminőséget 58 db metrikán keresztül mérő - reverse engine framework. Az előadáson vesézett Nokia Symbianra is ezt engedték rá tehát.
Az előadás egy picit félrevezető volt, mert ott sokkal bonyolultabb matek látszott. Ezek a cikkek egyszerűbb matekúak, azaz minden téma iránt érdeklődőt buzdítok olvassa el a cikket, mert tényleg érthető)
Az újabb cikk két új metrikát vezet be a régiekből kiindulva
(1) Conceptual Coupling between Object classes (CCBO)
(2) Conceptual Lack of Cohesion on Methods (CLCOM5)
Folyamat:
* Reverse Engine Columbus-szal (cikkben Mozilla projektre)
* Korpusz-építés az alábbiakra (+stoplista)
(1) comments
(2) local and attribute variable names
(3) user defined types
(4) methods names
(5) parameter lists and
(6) names of the called methods.
* Latent Semantic Indexing (LSI) szövegbányászati metódus alkalmazása
* Metrika-kalkulálás, -alkalmazás
* Ezután megkaphatók a releváns kapcsolatok
* Elő kell venni a Mozilla hibaadatbázisát
* Meg kell nézni, hogy a metrikák (azon belül releváns kapcsolatok) hogyan függnek össze a hibákkal
* Prediktív analitika széles tárházával (Weka, 12 algoritmus) szembesítették az immáron 61 db szoftver metrikát -> melyik metrika a legjobb hibaelőrejelző (hibahajlam-feltáró)
* Ez vezet a végső előadói konklúzióhoz: túl sok csatolás túl sok hibához vezethet, ami jobban valószínűsíti a kiváltást.
Konklúzióm (még ha egyedül is maradok vele a világban)
Tiszta világos gondolatmenet a fenti. Az egyedüli meggondolandó az érvényességi tartomány.
Lehet "lázadni" az ellen, hogy a hibák azért vannak, hogy kiküszöböljük őket, meg amúgy is csak az egyszerű emberek raknak rendet, mint tudjuk a "zsenik uralják a káoszt".
Én mégis azt mondom, ahogy a való életben a túl sok hiba elbocsátáshoz vezet a munkahelyen, úgy a szoftverben lévő kritikus tömegű hiba a szoftver kiváltási presszióját növeli. Ennyi. Nem több és nem kevesebb.
A hibákat meg nemcsak kinyilatkoztatás szintjén kell kerülni, hanem rásegíteni hasznos eszközökkel.
Szükséges, de nem elégségesen hasznos, ha a hibákat elektronikusan dokumentáljuk. Ha "ezrével" rögzítünk be hibákat ezt támogató rendszerekbe, az önmagában már deprimálóan hat és rontja a hibajavítás hatékonyságát. Én voltam nem egyszer résztvevője olyan projekteknek (harmadik legutóbbi itthon Magyarországon(!) 1.400 ETL-job verzióváltásos migrálása, 10.000-es nagyságrendű tárolt eljárással, olykor többezer kódsorral elég kevés emberhónap alatt, de legutóbbi két projektem is ilyen alapokon volt problémás redesignjai elött: valahogy tehát én vonzom ezeket) ==> ahol túl sok hiba merült fel túl kevés idő alatt az egész projektet alapjaiban megrengetve.
A tárgyalt potenciális eredmény/lehetőség, a csatolások számának csökkentése. Egybevág az eddigi szemlélettel (nem kell paradigmaváltás), kárt nem okoz, maximum valamennyi ráfordítási igénye van. Analóg módon, például ahogy egy B+ fába se elég elemet beszúrni, utána a fát ki kell egyensúlyozni.
Mindenki mérlegelheti ezt cost-benefit alapon, támogatja-e ezt a munkájában.
Én a magam részéről letettem a voksomat (már régóta akkor még pusztán csak intuitiv alapon), hogy megéri a "lineáris" erőforrásigényű befektetést, potenciálisan progresszíven növekedő komplexitás és hibaszaporodás elkerülése érdekében.
További elágazás Wikipediából kiindulva:
Coupling
Cohesion
Static code analysis
Dynamic program analysis
Feliratkozás:
Megjegyzések küldése (Atom)
Bejegyzések
A konklúzió, akit említett, igazából csak egy következménye a clcom5 definíciójának, hiszen az lcom5 alapján ezt a viselkedést vártuk el. Persze ezt be is lehetett látni aztán az egyik eloszlásból, így ad egy iránymutatót akkor is, ha nincs tanító halmaz, stb. A lényeg az volt, hogy egy kevésbé erőforrásigényes és más irányból vett metrikával megverjük a struktúrálisakat, ami végül is közel teljesítve is lett, mutatva az ebben rejlő potenciált. Még nem tökéletes az elmélet és van bőven kutatnivaló ez irányban. Ha lesz időm, akkor újrakreálom egy egyszerűbb elemzővel a szamolót, mert szívesen használnám a mindennapokban is.
VálaszTörlés(hopsz, mármint erőforrásigényes alatt azt értem leginkább, hogy egyszerűbb elemzőkkel is képesek lehetünk az LCOM és CBO szerű csatolást mérni, hiszen a cikkből is látszott, hogy valamilyen szinten mégis közel állnak az eredmények bizonyos struktúrális metrikákkal statisztikailag és ennek ellenére nem (kellene) felderíteni a csatolást az osztályok között. Ez C++ esetén rendkívül bonyolult, nem hiába olyan nagy kihívás a Columbus)
TörlésLegyen még egy kis komment már akkor, láttam volt pár terjedelmes mailing a témáról és kis félreértések, vagy pontatlanságok is voltak az értelmezésekben.
Törlés1. Nagy rendszerekben igenis következetesen fognak azért fejleszteni az emberek, elég szöveges tartalmat tud adni egy-egy osztály az eredményekhez. Az egyik levél azt vetette fel, hogy kommentek nélkül "jobb lesz a kód". Nem. Megfelelő háttér nélkül nem működik semmilyen metrika. Pont az a lényeg, hogy kellő tapasztalat után egy "átlagos" rendszerben felmérjük és megnézzük milyen értékeket vesznek fel bizonyos osztályok az adott metrikára és később ebből levonhassunk következtetést. Teljesen más értékekkel fog működni ez 2 nagyon más domainű szoftveren. Ez nem bizonyított, de könnyen megérthető szerintem, ha valaki elolvassa a cikket. Mindenesetre azt nem vitatom, hogy bizonyos esetekben használhatatlanok lennének a conceptual metrikák a struktúrálisakkal szemben, mert egy minimális komplexitás kell ahhoz, hogy "beinduljon" egy metrika.
2. A cikk nem tér ki (legalábbis nem emlékszem, azt hiszem végül kimaradt a cikkből) arra, hogy a kommentek mennyire befolyásolták az eredményt. Nos úgy nézett ki, hogy nem különösebben, sőt. Hiába volt elvileg terjedelmes kommenthalmaz, a lényeges elemek az LSI elemzés után nagyrészt az IDk közül kerülhettek ki. Vonjuk le végre a következtetést kedves programozótársaim: a kód önmagáért beszél :))
3. A csatolás nem feltétlen rossz! A megfelelő mértékű csatolás a lényeg. A CCBO esetén osztályok csatolásait figyeljük ugye. OO rendszerek esetén az egyértelmű, hogy muszáj modularizálni is a megoldást, ezért nem szabad nagy értéket felvennie ennek a metrikának. A CLCOM5 máshogy közelíti meg a dolgot, ott pont az a lényeg, hogy az érték magas legyen, itt az osztály kohézióját figyeljük. Mivel a CCBO esetén egy egész osztálynyi adattal dolgozunk, míg itt metódus szintig visszük le a témát, ráadásul maradunk az osztályon belül is, kilogikázható, hogy több esetben vallhat kudarcot a CLCOM5, mert kell egy minimális komplexitás az osztályban, hogy értelmes értéket kapjunk (ezért is van egyébként a 0 közeli értéknél a C3-nak és CLCOM5-nek meglepően ellentétes "előjelű" hibás/nem hibás eredménye, az olvasóra bízom, hogy kitalálja a cikk alapján miért is. Elárulom, hogy teljesen logikus).
4. Az LSI garantálja, hogy irrelevánssá válnak a nagyon általánosan használt kifejezések, ezért az, hogy retValt használok (utalnék itt megint egy levélre) egy metódus végén nem fog számítani SEMENNYIT az eredményben. A stopword halmazra se lenne szükség egy fikarcnyit sem a cikkben, csak az a probléma állt fenn, hogy a kevés idő keveredett azzal a ténnyel, hogy rosszul választottam meg egy modult a szoftverhez, ami olyan lassúvá és memóriazabálóvá tette a számítást, hogy valahogy szűrni kellett mindent, ami zaj lehet egyébként is az eredményben. Persze később nem volt idő újat keresni.
4. Nem, a jelentések nem fognak adni hibára jelzést. A hibát az jelzi, amit már lassan évtizedekkel ezelőtt lefektettek az OO struktúrális metrikák esetében száz meg száz cikkben: az osztályok csatolását minimalizálni kell, a kohéziójukat maximalizálni. És persze még tucatnyi ökölszabály létezik, de ez a kettő volt a cikkben.
(első kettő hozzászólás esetében pedig elnézést, ha valami félre van gépelve, telefonról bütykölődtem azoknál)
Törlés