[Javalist] Csatolások szoftverekben

[Molnár Miklós]

Hali,

Nagy küzdés után azt hiszem megtaláltam a szóbanforgó részleteket tartalmazó
cikke(ke)t.

Columbus: A Reverse Engineering Approach
http://star.fbk.eu/step2005/paper3.pdf

New Conceptual Coupling and Cohesion Metrics for Object-Oriented Systems
http://www.cs.wm.edu/~denys/pubs/SCAM'10-CohesionCouplingMetrics.pdf

Akik nem akarnak elmerülni a részletekbe azok számára (meglehet torzított)
rövid értelmezésem az alábbi.

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.
A Symbianra is ezt engedték rá tehát.

Az új cikk két új metrikát vezet be a régiekből kiindulva (és az előadás
ennyiben félrevezető volt, mert ennek egyszerű(bb) a matekja,  mint ott
látszott, azaz mindenkit buzdítok olvassa el a cikket, mert érthető)

(1) Conceptual Coupling between Object classes (CCBO) 
(2) Conceptual Lack of Cohesion on Methods (CLCOM5)

* Reverse Engine Columbus-szal (cikkben Mozilla projektre)
* Korpusz-építés az alábbiakra (+stoplista: a "the" például ignorálandó)
(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
* Ezután megkaphatók a releváns kapcsolatok metrika-kalkulálással,
alkalmazással
* Elő kell venni a Mozilla hibaadatbázisát
* Meg kell nézni, hogy a 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 (nem fog szeretni érte a levlista)
=============================================

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. Mindenki
mérlegelheti ezt cost-benefit alapon, támogatja-e 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.

MM

PS: Végül az egész egy újabb blogposztba torkollt.
http://liftinstinct.blogspot.com/2012/05/csatolasi-metrika-szoftverekben.htm
l