<p>Ezzel a magyarazattal csak egy bajom van, hogy nem eleg eletszagu. Eloszor is, a hibak azok nem csak ugy altalaban vannak, hanem van hiba es hiba kozotti sulyozas is. Pl szerintem egy webappnal pl hiba az, ha egy gomb szine mas, mert a szinkod el lett irva, ugyanakkor a projektre kihatasa nulla. Egy validacio kimaradasa nagy security hiba, de a projektre hatasa ugyancsak nincsen.</p>
<p>Szoval itt felmerul a kerdes, hogy nem kellene esetleg a hibakat sulyozni? Hany elutes er egy security hibat? Hany security hibat er egy rossz pattern? Mert sztem ezek fontos kerdesek.</p>
<p>Egy hiba "erteket" sztem elsosorban a kijavitasahoz szukseges energia adja meg (hiba megtalalas+javitas). Egy masik ertek, hogy az adott hiba milyen mertekben eredeztetheto tervezesi/szemleleti hibabol. Ez a ket szam mar segit sulyozni a hibakat. Minel magasabb ez a ket szam, annal nagyobb problemak vannak a rendszerben. No persze, ez csak a problemat vilagitja meg, nem pedig a megoldast, de vhol mindent el kell kezdeni.</p>
<p>Udv,</p>
<p>Garami Gábor<br>
<a href="mailto:gabor.garami@hron.me">gabor.garami@hron.me</a><br>
Skype: hron84<br>
Tel: +36 20 235 9621</p>
<p>Sent from my T-Mobile G2<br>
Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.</p>
<div class="gmail_quote">2012.05.19. 18:15, "Molnár Miklós" <<a href="mailto:timortinj@freemail.hu">timortinj@freemail.hu</a>> ezt írta:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hali,<br>
<br>
Nagy küzdés után azt hiszem megtaláltam a szóbanforgó részleteket tartalmazó<br>
cikke(ke)t.<br>
<br>
Columbus: A Reverse Engineering Approach<br>
<a href="http://star.fbk.eu/step2005/paper3.pdf" target="_blank">http://star.fbk.eu/step2005/paper3.pdf</a><br>
<br>
New Conceptual Coupling and Cohesion Metrics for Object-Oriented Systems<br>
<a href="http://www.cs.wm.edu/~denys/pubs/SCAM'10-CohesionCouplingMetrics.pdf" target="_blank">http://www.cs.wm.edu/~denys/pubs/SCAM'10-CohesionCouplingMetrics.pdf</a><br>
<br>
Akik nem akarnak elmerülni a részletekbe azok számára (meglehet torzított)<br>
rövid értelmezésem az alábbi.<br>
<br>
Adott a szegedi egyetem által több éve kifejlesztett Columbus nevű, C/C++ -<br>
szoftverminőséget 58 db metrikán keresztül mérő - reverse engine framework.<br>
A Symbianra is ezt engedték rá tehát.<br>
<br>
Az új cikk két új metrikát vezet be a régiekből kiindulva (és az előadás<br>
ennyiben félrevezető volt, mert ennek egyszerű(bb) a matekja, mint ott<br>
látszott, azaz mindenkit buzdítok olvassa el a cikket, mert érthető)<br>
<br>
(1) Conceptual Coupling between Object classes (CCBO)<br>
(2) Conceptual Lack of Cohesion on Methods (CLCOM5)<br>
<br>
* Reverse Engine Columbus-szal (cikkben Mozilla projektre)<br>
* Korpusz-építés az alábbiakra (+stoplista: a "the" például ignorálandó)<br>
(1) comments<br>
(2) local and attribute variable names<br>
(3) user defined types<br>
(4) methods names<br>
(5) parameter lists and<br>
(6) names of the called methods.<br>
* Latent Semantic indexing (LSI) szövegbányászati metódus alkalmazása<br>
* Ezután megkaphatók a releváns kapcsolatok metrika-kalkulálással,<br>
alkalmazással<br>
* Elő kell venni a Mozilla hibaadatbázisát<br>
* Meg kell nézni, hogy a releváns kapcsolatok hogyan függnek össze a<br>
hibákkal<br>
* prediktív analitika széles tárházával (Weka, 12 algoritmus) szembesítették<br>
az immáron 61 db szoftver metrikát -> melyik metrika a legjobb<br>
hibaelőrejelző (hibahajlam-feltáró)<br>
* Ez vezet a végső előadói konklúzióhoz: túl sok csatolás túl sok hibához<br>
vezethet, ami jobban valószínűsíti a kiváltást.<br>
<br>
Konklúzióm (nem fog szeretni érte a levlista)<br>
=============================================<br>
<br>
Tiszta világos gondolatmenet a fenti. Az egyedüli meggondolandó az<br>
érvényességi tartomány.<br>
<br>
Lehet "lázadni" az ellen, hogy a hibák azért vannak, hogy kiküszöböljük<br>
őket, meg amúgy is csak az egyszerű emberek raknak rendet, mint tudjuk a<br>
"zsenik uralják a káoszt".<br>
<br>
Én mégis azt mondom, ahogy a való életben a túl sok hiba elbocsátáshoz vezet<br>
a munkahelyen, úgy a szoftverben lévő kritikus tömegű hiba a szoftver<br>
kiváltási presszióját növeli. Ennyi. Nem több és nem kevesebb.<br>
<br>
A hibákat meg nemcsak kinyilatkoztatás szintjén kell kerülni, hanem<br>
rásegíteni hasznos eszközökkel. Szükséges, de nem elégségesen hasznos, ha a<br>
hibákat elektronikusan dokumentáljuk. Ha "ezrével" rögzítünk be hibákat ezt<br>
támogató rendszerekbe, az önmagában már deprimálóan hat és rontja a<br>
hibajavítás hatékonyságát. Én voltam nem egyszer résztvevője olyan<br>
projekteknek (harmadik legutóbbi itthon Magyarországon(!) 1.400 ETL-job<br>
verzióváltásos migrálása, 10.000-es nagyságrendű tárolt eljárással, olykor<br>
többezer kódsorral elég kevés emberhónap alatt, de legutóbbi két projektem<br>
is ilyen alapokon volt problémás redesignjai elött: valahogy tehát én vonzom<br>
ezeket) ==> ahol túl sok hiba merült fel túl kevés idő alatt az egész<br>
projektet alapjaiban megrengetve.<br>
<br>
A tárgyalt potenciális eredmény/lehetőség, a csatolások számának<br>
csökkentése. Egybevág az eddigi szemlélettel (nem kell paradigmaváltás),<br>
kárt nem okoz, maximum valamennyi ráfordítási igénye van. Mindenki<br>
mérlegelheti ezt cost-benefit alapon, támogatja-e a munkájában.<br>
<br>
Én a magam részéről letettem a voksomat (már régóta akkor még pusztán csak<br>
intuitiv alapon), hogy megéri a "lineáris" erőforrásigényű befektetést,<br>
potenciálisan progresszíven növekedő komplexitás és hibaszaporodás<br>
elkerülése érdekében.<br>
<br>
MM<br>
<br>
PS: Végül az egész egy újabb blogposztba torkollt.<br>
<a href="http://liftinstinct.blogspot.com/2012/05/csatolasi-metrika-szoftverekben.htm" target="_blank">http://liftinstinct.blogspot.com/2012/05/csatolasi-metrika-szoftverekben.htm</a><br>
l<br>
<br>
<br>
<br>
_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
</blockquote></div>