[Javalist] Csatolások szoftverekben

2012. Május. 19., Szo, 21:22:10 CEST

Hmmmmm, átfutottam. Szóval ha jól értem, itt a használt változónevek és kommentek alapján a "fogalmi csatolást" akarja bevezetni. Implicit módon azt állítja, hogy ha ugyanazt a szót használom két külön változóban, akkor a két változó között fogalmi csatolás áll fenn. Szerintem ez sok esetben erősen vitatható, de ez még esetleg mindenféle kivételszótárak segítségével kivédhető lenne. Ha két ember másként rövidíti ugyanazt a fogalmat, akkor viszont jelenleg nem találja meg a csatolást. Ez mindenféle szótár segítségével szintén kivédhető lenne persze. De ha viccelni akarok, akkor két következtést máris le tudok vonni.

a. ha egyáltalán nem használok kommentet, akkor nagyban csökkentem az egyes szavak fontosságát, vagyis a metrika szerint egyre jobb a kódom, mert kevesebb benne a fogalmilag csatolt szó.

b. a kódomban valszeg a "retVal" lesz a legfontosabb szó, mivel minden olyan metódusomban, amelynek van visszatérő értéke, ezt a nevet adom a lokális változómnak és a végén ezzel térek vissza... S mivel a szavakat szét is szedi, a "ret" lesz messze a legfontosabb, mert a retName, retObject, retArray és egyéb hasonló visszatérő változó neve is tartalmazza.

Egy kicsit komolyabban, erős kétségeim vannak a tényleges használhatósággal kapcsolatban. Bármely szoftver esetén várható, hogy a lefedett business domain szavai nagyobb gyakorisággal szerepelnek benne (vagyis fontosabbak). Az is elég valószínű, hogy a jelentett hibák nagyobb része valamilyen üzleti viselkedési hibára fognak vonatkozni. Ebből számomra az következik, hogy az üzleti logikát megvalósító programrészek, ahol egyébként a domain szavakat nagyobb előszeretettel használjuk, valószínűleg több hibajelentést kapnak a többinél. A metrika meg éppen ezt fogja "megjósolni". Ráadásul a metrika ugye megjelöli a legkritikusabb programrészként ezeket, és azt mondja hogy ezek gyorsan fognak öregedni - ami felettébb valószínű, hiszen az üzleti logikát megvalósító programrészek változnak a leggyorsabban és legnagyobb mértékben.

Bocs, de ezt nem tartom nagy felfedezésnek, de még tudott tény megerősítésének sem.

Kicsit arra is kíváncsi lennék, hogy a NEM open-source programok esetén mennyire lenne működőképes ez az elképzelés. Egy 5-15 fő által kettő-öt év alatt kifejlesztett néhány százezer soros ipari alkalmazás esetén a gyakori tervezői egyeztetések, az egyes modulok "owner"-i szemlélettel való kivitelezése (adott ember felel egy-egy nagyobb részért, és nagyrészt ő is írja), és más hasonlók úgy vélem erősen eltorzítják az elemzés alapjául szolgáló "fogalmi csatolást".

István Ketler
Senior Consultant
Lufthansa Systems Hungaria Kft. 
Development Center Pest 
Neumann János u. 1/e
1117 Budapest
Hungary 
Tel: +36 1 887-2815 
Fax: +36 1 887-2977
Mobile: +36 30 600-4936 
Room: Infopark E, Room LH2-24 
e-mail: istvan.ketler at lhsystems.com 
Internet: www.LHsystems.hu

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

From: javalist-bounces at lists.javaforum.hu [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Molnár Miklós
Sent: Saturday, May 19, 2012 6:15 PM
To: 'Java lista'
Subject: Re: [Javalist] Csatolások szoftverekben

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

_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu
http://lists.javaforum.hu/mailman/listinfo/javalist