Kaczur Sándor informatikus mérnök, matematika-informatika-közgazdásztanár, az it-tanfolyam.hu alapítója és oktatói csapatának szakmai vezetője. Részletes bemutatkozása az Oktatók lapon található. 2017 óta blogol velünk.
Az it-tanfolyam.hu szakmai blogjába 116 bejegyzést írt:
Valaki sertést, kecskét és juhot vásárolt, összesen 100 állatot, pontosan 100 aranyért. A sertés darabja 3 és fél arany, a kecskéé 1 és egyharmad, a juhoké fél arany. Hány darabot vehetett az egyes állatokból?
Tudjuk, hogy a feladatnak három megoldása van:
Klasszikus informatikai megközelítést – egymásba ágyazott ciklusokat – bemutattam már: Euler állatos feladata. A brute force alapgondolat fokozatos finomítását követően néhány ötleteket is adtam a továbbfejlesztéshez. Ez igazi örökzöld feladat. Látogatottsága alapján rendületlenül népszerű ez a blog bejegyzés az it-tanfolyam.hu szakmai blogban. Többek között ez inspirált a feladattal való további foglalkozásra.
Egy térbeli pont három koordinátával leírható. Az (s, k, j) ponthármas jelenti a sertések, kecskék és juhok számát. Az RGB színkockához hasonlóan (amibe belefér az összes ábrázolható színhez tartozó koordinátapont), most is elférünk egy kockában. Legyen a kocka egyik csúcsa az origó és az élei legyenek 100 egység hosszúak. A feladat megfogalmazása alapján két egyenlet (e1 és e2) írható fel 3-3 együtthatóval. Mindkét egyenlet meghatároz egy síkot (s1 és s2) a térben, amelynek ábrázoljuk a kockába eső síkmetszeteit. A két sík metszésvonala egyenes (e3), amire esnek a megoldások pontjai (m1, m2, m3). Lépésenként haladunk a geometriai ábrázolás során.
A grafikus felületen történő ábrázoláshoz, rajzoláshoz két korábbi projektünkből indulunk ki. A Kígyókocka grafikus felületen feladat ismertet egy grafikus keretrendszert JavaFX-ben megvalósítva. A három részből álló Naprendszer szimuláció esettanulmányunk pedig ismerteti az ábrázoláshoz szükséges elméleti hátteret, homogén transzformációkat, vetületi leképezést, Java forráskódot is bemutat a transzformációs mátrix alkalmazására. Az eddig említett három blog bejegyzést mind összeépítve készültek a továbbiak.
A geometriai megoldást lépésenként, saját fejlesztésű, grafikus felhasználói felülettel rendelkező, JavaFX alapú programról készült képernyőképek mutatják be – markáns Java forráskód-részletekkel.
Elegendő ábrázolni a kockának azt a három élét, amik egybeesnek a koordinátatengelyekkel. Az RGB színkockához hasonlóan piros, zöld, kék színekkel jelennek meg a három tengelyen lévő néhány pont. Az ábrázoláshoz érdemes kísérletezni egy kicsit: mekkora méretben (skála), honnan (nézőpont), milyen messziről (vetület, ideális pont, perspektíva, távolság) látszik a modelltérbeli objektum (igen, ez a kocka).
Az alábbi Java forráskód-részlet helyezi el a fenti pontokat. Mindhárom tengelyen 5-től 95-ig, 10-esével haladunk. Így elkerülhető, hogy az origóba kerüljön pont, hiszen az nem tudna egyszerre három színnel megjelenni. Mivel az állatok száma pozitív, így a koordinátapontok is nemnegatívak.
|
1 2 3 4 5 6 7 8 |
for(int i=5; i<=100; i+=10) { Point3D cpS=new Point3D(i, 0, 0); //sertés createPoint(cpS, 5, Color.RED); Point3D cpK=new Point3D(0, i, 0); //kecske createPoint(cpK, 5, Color.GREEN); Point3D cpJ=new Point3D(0, 0, i); //juh createPoint(cpJ, 5, Color.BLUE); } |
A korábbi megoldásnál feltételként megfogalmazott első 3.5*s+4.0/3*k+0.5*j==100 egyenlet egyszerű átalakításokkal megadja a piros és zöld síkbeli ponthoz tartozó kék térbeli pontot: j=(600-21*s-8*k)/3. Ezek az s1 síkra esnek. A citromsárga pontokat páros koordinátapárokra vizsgált feltétel jelöli ki. A narancssárga vonal behatárolja ezt a síkmetszetet. Ez a négyszög (trapéz) esik bele a kockába.
A citromsárga pontokat az első egymásba ágyazott ciklusok adják hozzá az ábrázolt modelltérhez: érzékeltetve a síkbeli pontokat. A narancssárga pontokkal a második egymásba ágyazott ciklusok bővítik a modellteret: behatárolva a kockabeli négyszög síkrészletet. (A trapéz oldalait szakaszként is lehetne ábrázolni, de ez a kellően sűrű ponthalmaz is elegendő).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
for(int s=0; s<=100; s+=2) for(int k=0; k<=100; k+=2) { int j=(600-21*s-8*k)/3; if(0<=j && j<=100) { Point3D cpE1=new Point3D(s, k, j); createPoint(cpE1, 3, Color.YELLOW); } } for(double s=0; s<=100; s+=0.1) for(double k=0; k<=100; k+=0.1) { long j=Math.round((600-21*s-8*k)/3); if(((s==0 || s==100) && 0<=j && j<=100) || ((k==0 || k==100) && 0<=j && j<=100) || (j==0 || j==100)) { Point3D cpE1=new Point3D(s, k, j); createPoint(cpE1, 2, Color.ORANGE); } } |
Hasonlóan az eddigiekhez. A korábbi s+k+j==100 feltételből adódik a szintén feltételként megfogalmazott j==100-s-k egyenlet. Ezek az s2 síkra esnek. Világosszürke pontok érzékeltetik a síkot és sötétszürke pontok adják a síkrészlet határait. A síkból ez a háromszög esik bele a kockába.
A Java forráskód nagyon hasonló az előzőhöz.
Egyben kirajzoltatva a fentieket, könnyen adódik ez az ábra:
Mivel a két sík nem esik egybe, így van metszésvonaluk. Ez egy egyenes, amiből csak az az e3 szakasz rész szükséges, ami a kockába esik. Bíbor (magenta) szín jelöli az alábbi ábrán:
Ahol a két egyenlethez tartozó konkrét pontok egybeesnek, ott van a metszésvonal. A behelyettesítést behatároló ciklusok szervezéséből (a ciklusváltozók alsó és felső és határaiból) adódik, hogy csak a kockabeli szakaszt rajzolja ki az alábbi Java forráskód-részlet:
|
1 2 3 4 5 6 7 8 9 |
for(double s=0; s<=100; s+=0.1) for(double k=0; k<=100; k+=0.1) { long j1=Math.round((600-21*s-8*k)/3); long j2=Math.round(100-s-k); if(j1==j2) { Point3D cpE1=new Point3D(s, k, j1); createPoint(cpE1, 2, Color.MAGENTA); } } |
A két egyenlethez tartozó síkok kockába eső metszésvonalán helyezkednek el az egész koordinátákkal ábrázolható, koordináta-hármasként megjelenő pontok. Nagyobb fehér pontok jelölik ezeket az alábbi ábrán:
Az eddigiek alapján könnyen adódik a három pont/megoldást ábrázoló Java forráskód-részlet:
|
1 2 3 4 5 6 |
Point3D m1=new Point3D(5, 42, 53); createPoint(m1, 10, Color.WHITE); Point3D m2=new Point3D(10, 24, 66); createPoint(m2, 10, Color.WHITE); Point3D m3=new Point3D(15, 6, 79); createPoint(m3, 10, Color.WHITE); |
A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.
Ez a feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 5-8. óra: Vezérlési szerkezetek, illetve 9-12. óra: Metódusok, rekurzió alkalmához, a 29-36. óra Grafikus felhasználói felület alkalmaihoz, valamint minden tanfolyamunk orientáló moduljának 1-4. óra: Programozási tételek alkalmához kapcsolódik.
Tanfolyamainkon JavaFX grafikus felülettel hangsúlyosan nem foglalkozunk, de egy-egy kész forráskódot közösen megbeszélünk, és össze is hasonlítjuk a swing-es változattal. Fejlesztünk játékprogramot, de inkább konzolosan, vagy swing-es ablakban, vagy webes alkalmazásként.
A grafikus felületek felépítésének megismerése fontos lépcső az objektumorientált programozás elmélyítéséhez, gyakorlásához. A grafikus felületekhez egy másik lényeges szemléletváltás is kapcsolódik, hiszen a korábbi algoritmusvezérelt megközelítést felváltja az eseményvezérelt (eseménykezelés). A GUI-s feladatainkat tudatosan hangsúlyozott MVC-s projektekben készítjük el.
Az a feladatunk, hogy az Oracle HR sémából lekérdezve állítsuk elő a top 5 fizetésű alkalmazottak listáját, a fizetések csökkenő sorrendjében. Ez egytáblás lekérdezéssel megvalósítható. Az
EMPLOYEES táblában megtalálható az összefűzött névhez szükséges
FIRST_NAME és
LAST_NAME mezők, valamint a fizetés a
SALARY mezőben. Minden alkalmazottnak van neve és fizetése. Előfordul legalább 5 különböző fizetés.
Tanfolyamainkon többféleképpen modellezzük és tervezzük meg a feladat megoldását.
A Java SE szoftverfejlesztő tanfolyam 45-52. óra: Adatbázis-kezelés JDBC alapon alkalmain a következők szerint modellezünk és tervezünk.
Eredményül ezt kapjuk (részlet, V1):
A kapott 107 rekordból álló eredménytáblát a Java kliensprogram fejlesztése során leképezzük egy generikus POJO listába, a rekordonként összetartozó két adatból előállítva az objektumok tulajdonságait. Kiderül, hogy a 17000 többször is előfordul. Mivel bármely fizetés előfordulhatna többször is, így előre nem tudjuk, hogy az eredménytáblából mennyi rekordot kell áttölteni a listába. A fizetésekből generikus halmazt építhetve, addig tudjuk folytatni a beolvasást, amíg a halmaz elemszáma kisebb ötnél. Eredményül hat rekordot kapunk. A Java kliensprogram forráskódját most nem részletezzük, de tanfolyamaink hallgatói számára ILIAS e-learning tananyagban tesszük elérhetővé a teljes forráskódot. Ennél a megoldásnál egyszerűbb a lekérdező parancs, de több feladat hárul a Java kliensprogramra.
Lássunk néhány tévutat és az általános megoldás helyett konkrét megoldásokat! Ha szeretnénk adatbázis oldalon megoldani a feladatot, akkor használhatnánk a ROWNUM pszeudooszlopot. Ez 1-től sorszámozza az eredménytáblát, így használható lehetne arra, ha limitálni szeretnénk a visszaadandó rekordok számát.
1. elvi hibás eredmény:
A hiba elvi, a lekérdező parancs szintaktikailag helyes. A harmadik oszlopban látjuk, hogy a rekordok sorszámozása megtörténik, de a kapott nevek és fizetések eltérnek a V1 esetben kapott helyes eredménytől. Az okokat természetesen megbeszéljük. Támpont: próbáljuk meg a lekérdező parancs feltételében kicserélni az 5-öt például 10-re és próbáljuk megmagyarázni, miért kapjuk azt, amit kapunk. Továbbá a konkrét esetben tudjuk, hogy hat rekordot kellene kapunk. Felmerülhet a gyanú, hogy a rendezés túl későn történik meg. Megpróbáljuk zárójelezéssel és lekérdezések egymásba ágyazásával befolyásolni a WHERE és ORDER BY alparancsok végrehajtási sorrendjét.
2. elvi hibás eredmény:
A hiba most is elvi, a lekérdező parancs szintaktikailag helyes. A zárójelezés valóban hatással van a két alparancs végrehajtási sorrendjére és megfigyelhető, hogy a harmadik oszlopban a rekordok táblabeli fizikai sorrendje jelenik meg és a feltétel ( ROWNUM <= 5) nem a mező értékére, hanem a rekordok darabszámára értendő. Nyilván az 5-öt 6-ra módosítva visszakaphatnánk a V1 első hat rekordját, de ez nem lenne általános megoldás. Más úton is eljuthatunk a konkrét megoldáshoz.
3. konkrét megközelítéssel kapott helyesnek látszó eredmény:
A hiba most is elvi, a lekérdező parancs szintaktikailag helyes. Általános megoldás helyett konkrét megoldásként megkapjuk a V1 első hat rekordját, de ehhez be kellett építeni a lekérdező parancsba a 13000-et. Ez a Top 5-ben legkisebb fizetés. Megbeszéljük, hogy miért hasznos a DISTINCT módosító/kulcsszó beépítése a lekérdező parancsba.
A Java adatbázis-kezelő tanfolyam 9-12. óra: Oracle HR séma elemzése, 13-16. óra: Konzolos kliensalkalmazás fejlesztése JDBC alapon, 1. rész, 33-36. óra: Grafikus kliensalkalmazás fejlesztése JDBC alapon, 2. rész alkalmával a következők szerint modellezünk és tervezünk.
Most arra helyezzük a hangsúlyt, hogy back-end, azaz adatbázis oldalon állítsuk elő az eredményt és ezáltal a front-end, azaz a Java kliensprogram egyszerűbb lehet. A lekérdező parancsot belülről kifelé haladva gondoljuk végig. Először kell egy halmaz a különböző fizetésekről csökkenő sorrendben. Utána ebből kell az első öt darab, amelyek halmazt alkotnak. Végül erre építve kell azoknak az alkalmazottaknak a neve és fizetése, akiknek a fizetése benne van a halmazban.
1. általános megközelítéssel kapott helyesnek látszó eredmény:
A probléma az, hogy az adatok helyes sorrendje a véletlennek köszönhető. Ha a lekérdező parancs feltételében az 5 helyett nagyobb számokat helyettesítünk be, akkor ez jól megfigyelhető. A következő megoldás már ezt a problémát is kezeli.
Finomítva a 3. elvi hibás lekérdező parancsot, a konkrét 13000 helyettesíthető belső lekérdező paranccsal. Építsük ezt be az 1. helyes megoldásba úgy, hogy az IN predikátum helyett használjuk a nagyobb vagy egyenlő hasonlító operátort. A középső lekérdező parancs a halmaz helyett már csak egyetlen értéket adjon vissza, amelyhez könnyű hasonlítani az aktuális alkalmazott fizetését. Ezzel kiváltható a nagyobb memóriaigényű halmazban való tartalmazottságot eldöntő művelet, a jóval hatékonyabb egy értékkel való összehasonlítással. Memóriaigény szempontjából nem maga a konkrét művelet/operátor az érdekes, hanem a használatukhoz szükséges adatok előállítása, mennyisége, tárolása, feldolgozása.
2. általános megközelítéssel kapott helyes eredmény:
Közben az is kiderült, hogy miért szükséges két helyen az ORDER BY alparancs.
Végül, ha ismerjük az Oracle DENSE_RANK() analitikai függvényét, amely egy rendezett lista különböző elemeihez rendel sorrendben számokat (másképpen rangsort állít fel 1-től kezdve), akkor elkészíthetjük az alábbi megoldást.
3. általános megközelítéssel kapott helyes eredmény:
Érdemes átgondolni és összehasonlítani a többféle különböző megközelítés lehetőségeit, korlátait. Ha egyensúlyozni kell a kliensprogram és az adatbázis-szerver terhelése között, valamint az MVC modell összetettsége, karbantarthatósága, könnyen dokumentálhatósága a/is szempont, akkor többféle alternatív módszer is bevethető, valamint építhetünk a különböző Oracle verziók (dialektusok) képességeire is.
Az SQL forráskódok formázásához a Free Online SQL Formatter-t használtam.
Fejlesszünk elosztott, hálózatos, datagram alapú üzenetküldéssel megvalósított Java alkalmazást!
A kockadobás kliens egyszerre két szabályos dobókockával dob, amit ezerszer megismétel és a dobott számok összegét datagram típusú üzenetküldéssel folyamatosan elküldi a szervernek. A szerver localhost-on fut és egy megadott porton keresztül várja a klienstől. A szerver és a kliens egyaránt szálkezelést alkalmazó konzolos alkalmazás.
A projektben van egy swing GUI-s alkalmazás, amely JFreeChart oszlopdiagramon – folyamatosan frissítve – megjeleníti az összesített adatokat, mindez a szerver üzenetküldésével irányítva (amint beérkezik egy dobott (2-12-ig) összeg).
A kommunikációnak – a lehetőségekhez képes – biztonságosnak és – a hálózati adatforgalmat tekintve – takarékosnak kell lennie! Ennek részeként szükséges egy azonosító és egy egyszerű szabály (protokoll).
Tekintsük át mondatszerűen a szálkezelést használó kliens és szerver kommunikációhoz kötődő feladatait:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Kliens (háttérszálon): ciklus 1-től 1000-ig egyesével DatagramSocket létrehozása dobás1, dobás2, dobásÖsszeg előállítása üzenet előállítása //pl.: "12;kocka2#" DatagramPacket létrehozása üzenet elküldése a szervernek visszhang/log kiírása a konzolra DatagramSocket lezárása várakoztatás ciklus vége Szerver (háttérszálon): ciklus(végtelen) DatagramSocket létrehozása DatagramPacket létrehozása üzenet fogadása a klienstől DatagramSocket lezárása ha(valid az üzenet) akkor dobásÖsszeg feldolgozása ablak grafikonjának frissítése (GUI szálon) elágazás vége ciklus vége |
Ezek működését összefogja egy központi vezérlőosztály és ez a fejlesztőeszköz projektablakában így jelenik meg (egyetlen MVC Java projektként):
A program két felületen kommunikál. A háttérben konzolosan logol a kliens, és a háttérben futó szerver időnként frissítteti a grafikus felhasználói felületen (GUI, ablak) megjelenő grafikont:
Aki kedvet kapott: bátran készítse el a fenti terv/koncepció/specifikáció alapján az MVC Java projektet. Érdemes alaposan tesztelni: külön a szervert, külön a klienst, először indítva az egyiket, majd a másikat, leállítani az egyiket majd fordítva. Átgondoltan indokolni is hasznos, vajon mi, hogyan és miért történik.
A bejegyzéshez tartozó forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.
A feladat a Java EE szoftverfejlesztő tanfolyam 1-8. óra: Elosztott alkalmazások, webszolgáltatások, szálkezelés, párhuzamosság alkalmához kapcsolódik. Amikor itt járunk a tananyagban, akkor a GUI felület és a grafikon tervezése, megvalósítása már magabiztosan megy, így elegendő a hálózati kommunikációra helyezni a fókuszt.
Az INFIMUM 2024 Konferenciát a Neumann János Egyetem GAMF Műszaki és Informatikai Karán került megrendezésre, Kecskeméten, 2024. június 14-15-én.
A rendezvény elsődleges célja annak elősegítése, hogy a felsőoktatási intézmények oktatói és kutatói az informatika, a fizika, a matematika és a logisztika korszerű és hatékony oktatásáról és tudományos eredményeiről előadások, poszter-bemutatók és személyes találkozás révén tapasztalatot cserélhessenek, valamint kapcsolatot építhessenek.
A letölthető absztraktkötet tartalmazza a szervezőbizottság által összeállított programot. Pénteken került sor a szakmai programra. Szombaton zajlott a Strázsa túra, utána az EB meccset lehetett megnézni a GAMF udvarán, végül borkóstolóval zárul a rendezvény.
A konferenciára 37 résztvevő regisztrált és tartott plenáris vagy szekcióelőadást. A Matematika oktatása szekció 18 előadásból, az Informatika szekció és a Fizika szekció pedig egyaránt 5-5 előadásból állt.
Az absztraktok ISBN 978-615-6435-83-5 számmal rendelkező absztraktkötetben jelentek meg. Lehetőség volt hosszabb, 1-2 oldalas összefoglalók megjelentetésére is. A szakmai cikkek a Gradus lektorált, online folyóiratba egyénileg nyújthatók be magyar vagy angol nyelven, maximum 10 oldal terjedelemben (utólag is). A folyóirat (ISSN 2064-8014) eredeti publikációkat közöl számos témakörben, beleértve a természettudományok minden területét, mindenféle műszaki tudományt, számítástechnikát, kertészetet, környezetmérnökséget, pedagógiát, didaktikát és közgazdaságtant. A számítástechnika és a matematika elméleti és alkalmazott területeit is befogadja. A folyóirat csak kutatási cikkeket közöl, és minden cikk az esettanulmányok, kísérletek, vagy a gyakorlatban már alkalmazott megközelítésekkel való szisztematikus összehasonlítások révén előrehaladó ötletek gyakorlati alkalmazását tárgyalja.
2024-ben egy szakmai előadást tartottam 20 percben Letöltés szimuláció – esettanulmány Java nyelven címmel. Erről a témáról szól korábbi blog bejegyzésem, lásd: Letöltés szimuláció.
A szerző letöltési folyamatot szimulál. A paraméterek rugalmasan beállíthatóak. Előre beállított mennyiségű adatokat, párhuzamos szálakon/folyamatokon keresztül tölt le, miközben méri az eltelt időt. A folyamatok állapota lehet inaktív, aktív és befejezett. Az aktív folyamatok esetében megjelenő százalék fejezi ki, hogy a folyamat hol tart a rá jutó részfeladat végrehajtásával. Összesített formában követhető a hiányzó és a letöltött adat mennyisége MB-onként és százalékosan is. A folyamat szimulációjához objektumorientált szemléletű, grafikus felhasználói felületű Java kliensprogram készült, egyszerű GUI komponensekkel. Az előadás/cikk bemutatja feladatspecifikációt, a tervezés és megvalósítás lépéseit, ismertet tesztelési és továbbfejlesztési lehetőségeket. A szimuláció megközelítése elvi/általános szintű. Az esettanulmány konkrét adatokkal paraméterezett. Kitér az elosztott alkalmazások különböző felépítési, tervezési, megvalósíthatósági lehetőségeire.
A konferencia a korábbi MAFIOK konferenciasorozat hagyományait követi. Ezen 2023-ban is részt vettünk és beszámoltunk róla az it-tanfolyam.hu szakmai blogban, lásd: MAFIOK 2023. Ott korábbi, MAFIOK-os publikációinkat is felsoroltuk.
A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb szimulációs programot tervezni, kódolni, tesztelni. A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal többféle elosztott stratégiát ismertetünk, és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal pedig megvalósíthatjuk többféle protokoll szerint a hálózati kapcsolatot, letöltést/feltöltést.
A TIOBE Java Coding Standard aktuális verziója a 3.10. Java programozási nyelven írt/karbantartott forráskódra vonatkozó szabályokat/ajánlásokat tartalmaz. Célja: a kódolási hibák elkerülése, az elavult vagy implementációfüggő nyelvi funkciók használatának elkerülése, illetve a következetes, konzisztens kódolási stílus kialakítása.
A TIOBE Java kódolási szabályok 19 kategóriába soroltak, 1-8-ig szint alapján csoportosítottak, továbbá ellenőrzött és nem ellenőrzött állapotban vannak. Az alábbi Sankey-diagram segít áttekinteni a dokumentációt:
A továbbiakban néhány kategóriából emeltem ki néhány szabályt/ajánlást – amiket fontosabbnak tartok.
Nem tértem ki a 2 db klónozáshoz, 2 db csatoláshoz (importáláshoz), az 1 db stílushoz kötődő szabályra. Továbbá van 5 db már elavult, tervezésre vonatkozó szabály.
A fentieket érdemes megfogadni, betartani, céges környezetben megfelelően kiegészíteni, testre szabni. A teljes angol nyelvű dokumentáció elérhető: Coding Standard Viewer. A weboldalon érdemes a Java programozási nyelvre vonatkozó szabályokat, ajánlásokat összehasonlítani más nyelvekre vonatkozó szabályokkal, ajánlásokkal. Összesen 8 programozási nyelvhez találhatók szabályok, ajánlások. Elérhetők a forráskód minőségét, karbantarthatóságát kifejező TQI szempontok, paraméterek dokumentációi is: TIOBE Quality Indicator (TQI), valamint a TIOBE TÜViT Trusted Product Maintainability ISO/IEC 25010 Quality Model. Egy szint felett már ezeket is figyelembe kell venni.
Korábbi blog bejegyzésünk a fenti saját készítésű ábra, grafikon elkészítéséről: Sankey-diagram készítése. Érdemes a hozzászólásokat is tanulmányozni a jó példákért.
