Szoftver Szigorlat Tételek '07 BSC Készítette: Somody Gábor Ádám 2007.05.26
1
Tételsor Témakörök:
Amit nem tudtam kidolgozni azt félkövér betűvel jelzem!! Légyszíves dolgozzátok ki, és küldjétek el a
[email protected] címre. Köszönöm mindenki nevében.
Elméleti alapok, nyelvek, paradigmák:
Majdnem teljesen kész!!! 1 hiányzik!!
1. A 0-s nyelvosztály. A Turing gép definíciója. Mit jelent a T Turing-gép által elfogadott nyelv, és milyen típusú? Szubrutin Turing-gépen. A Turing-gép változatai és a Turing-géppel ekvivalens gépek. (Mit jelent az ekvivalencia. Bizonyítani itt nem kell.) 2. A bináris szalagot használó Turing gép mozgási szabályainak megadása bináris sorozat formájában. (táblázattal ) Az utánzó Turing-gép konstrukciója. Ebből az univerzális Turing-gép konstrukciója. (Turing-gépek sorszámozása a bináris táblázat alapján.) 3. A Chomsky-hierarchia. A grammatikákra tett megszorítások nyelvosztályonként. Az egyes nyelvosztályokra az elfogadást milyen géppel lehet elvégezni? (Csak a gépek megnevezése kell.) 4. A környezetfüggő nyelvek. Grammatika alakja. A lineárisan korlátozott Turing-gép. 5. A reguláris nyelvek. Grammatika megadása. Véges állapotú automata, grammatikák és automaták megfeleltetése. Változatok (nem determinisztikus, determinisztikus, teljes) 6. Az önmaguk leírását elfogadó, illetve az önmaguk leírását nem elfogadó Turing gépek leírásai milyen nyelvosztályba tartoznak. A Turing gépek megállásának eldönthetetlensége. 7. Környezetfüggetlen nyelvek. A grammatika megadása. A levezetési fa és szerepe. A kettős pumpálási lemma. (Nagy Bar-Hillel lemma) 8. Milyen műveletekre zártak, illetve nem zártak a környezetfüggetlen nyelvek. A tartalmazási kérdés eldönthetősége. 9. Műveletek reguláris nyelvekkel, reguláris kifejezések, pumpálási lemma (kis Bar-Hillel lemma.) 10. Nem determinisztikus Turing-géphez determinisztikus Turing gép szerkesztése. 11. Nyelvek (függvények) időbonyolultsága, bonyolultsági osztályok. (Determinisztikus, és nem – determinisztikus bonyolultság.) 12. Nyelvek (függvények) tárbonyolultsága, bonyolultsági osztályok. (Determinisztikus, és nem – determinisztikus bonyolultság.) 13. Nyelvek és nemnegatív egész számokból álló halmazok megfeleltetése. Rekurzív (eldönthet halmazok), rekurzívan felsorolható halmazok. Turing-gépek, mint átalakítók. Kiszámítható függvények. 14. Véges ÁBC feletti nyelv fogalma. Grammatika megadása. A grammatika által generált nyelv. 15. Veremautomaták. Veremautomaták és környezetfüggetlen grammatikák megfeleltetése. Veremautomata konstrukciója grammatikához. Klasszikus algoritmusok: Animált rendezések: http://www.cs.bme.hu/~kiskat/sza/anim.html 16. Alapvető programozási tételek (N-1) (összegzés, számlálás, maximumkeresés, lineáris keresés, logaritmikus keresés) 17. Alapvető programozási tételek (N-N) (szétválogatás, halmazműveletek), Programozási tételek összeépítése. 18. Dinamikus programozás (mátrixok láncszorzása) 19. n*n-es rendezések (alapelvek, algoritmusok) 20. Haladó rendezések I. ( Kupacrendezés, Shell rendezés) 21. Haladó rendezések II. (Szétosztó-, Leszámláló-, Radix-, Edényrendezés) 22. Haladó rendezések III. (quicksort, rekurzív és nemrekurzív módon) 23. Ritka mátrixokkal kapcsolatos algoritmusok. 24. Strassen mátrixszorzási algoritmus. 25. A játékelmélet alapjai. Klasszikus adatstruktúrák: Ezt dolgozzátok ki!! 26. Adatszerkezetek, láncolt listák, egyszer láncolt listák műveletei I. (új elem felvétele, bejárás, törlés) 27. Adatszerkezetek, láncolt listák, speciális listák műveletei II. (rendezett láncolt lista, többirányú, többszörösen láncolt lista, strázsa) 28. B-fa adatszerkezet, B-fába való beszúrás algoritmusa (B-fa jellemzői, előnyei, felépítése, új elem felvétele) 29. B-fa adatszerkezet, B-fából való törlés algoritmusa (B-fa jellemzői, előnyei, felépítése, törlés) 30. Fa adatszerkezetek, bináris fák alapműveletei (új elem felvétele, bejárások, törlés) 31. Fa adatszerkezetek, piros-fekete fa adatszerkezet (forgatások, új elem felvétele, törlés) 32. Gráfok I. (körmentes út keresése (labirintus); legrövidebb út keresése). 33. Gráfok II. (Kruskal algoritmus és alkalmazásai) 34. Gráfok III. (topológiai rendezés és alkalmazásai) 35. Hasító táblázatok (alapelvek, hasító függvények, kulcsütközések feloldása)
2
Szoftverfejlesztés lépései:
Teljesen kész!!!
36. A szoftver jellemzői (a termék elállítás jellemzői, hibaaránygörbék, költségösszetevők, költségarányok) 37. A szoftverkrízis (előzmények, tünetek, okok, megoldások) 38. A szoftverfolyamat modelljei I. (modelltípusok, a modellezési koncepció, célok, a vízesés modell) 39. A szoftverfolyamat modelljei II. ( az evolúciós modell, a formális rendszerfejlesztés) 40. A szoftverfolyamat modelljei III. (újrafelhasználás orientált fejlesztés, inkrementális fejlesztés, RAD modell) 41. A szoftverfolyamat modelljei IV. (spirális fejlesztés, Agile Software Processes, XP) 42. A szoftver projekt ütemezése 43. Szoftver projekt mérése 44. Programozás, tesztelés, szoftverevolúció (a belövés folyamata, szoftvervalidáció, tesztelési folyamat, fázisok, dokumentumok, az evolúció folyamata) 45. Projekt becslés (általános fogalmak, dekompozíción alapuló technikák, tapasztalati becslési modellek, becslési bizonytalanság) 46. Projekt menedzsment, projekt tervezés (a menedzsment kérdései, a projekt elkészítése, a terv típusai, a tervkészítés folyamata, a terv szakaszai, mérföldkövek a folyamatban) 47. Kockázat menedzsment 48. COCOMO 81, COCOMO 2 49. Team-szervezési megoldások Tervezési módszerek: Teljesen kész!!! 50. Szoftverspecifikáció (fázisok, folyamat, technikák) 51. Szoftvertervezés (a folyamat tevékenységei, általános modell, általános elvek) 52. Tervezési módszerek I. (kategorizálás, a Jackson féle módszer) 53. Tervezési módszerek II. (Strukturált analízis és tervezés) 54. Jelentősebb OO módszertanok (OOAD, RDD, OOSE, OOD, OMT) 55. UML (fogalmak, keletkezése, jellemzői, célok, tulajdonságok, kritikája, építőkövei) 56. UML – Osztály diagramm 57. UML – Objektum és szekvencia diagramm 58. UML – Use Case Diagramm 59. UML – Együttműködési diagramm, állapot diagramm 60. UML – Aktivitás (activity) diagramm, package diagramm 61. UML – Komponens diagramm, Konfigurációs (Deployment) diagramm 62. UML – Composite structure, Kollaborációs, Timing, Interaction Overview diagrammok 63. RUP I. (jellemzők, történelem, UML és RUP, módszertan, technológia, eszközök, emberek, szervezeti minták) 64. RUP II. (a RUP fázisai) 65. Verifikáció és validáció. Implementációs technikák, OOP paradigma: Teljesen kész lesz a hétvégére!!! 66. Osztály, objektum, UML jelölések (Konstruktor, destruktor, példányosítás. Egységbezárás, láthatóságok, tulajdonság. Osztályok láthatósága. Self vagy this.) 67. Osztályok csoportosítása (Logikai csoportosítás, fizikai csoportosítás. Névterek. A dll és az assembly. A komponensalapú programozást támogató láthatóságok. Friend kapcsolat.) 68. Osztály szint tagok (Osztályszint adattagok fogalma, inicializálása. Osztály szint tagfüggvények. Példák osztály szint tagok felhasználására. Singleton pattern) 69. Konstruktorok (Konstruktor, destruktor hívások sorrendje öröklés és asszociációs kapcsolat, többszörös öröklés esetén. Default és felülírt konstruktorok. Taginicializáló lista. A konstruktor, destruktor feladatai virtuális metódushívás esetén.) 70. Hivatkozás és érték típusok (Hivatkozás típusú tagok inicializálása. Hivatkozás és érték típusok közti különbség. Automatikus szemétgyűjtés. A hivatkozás argumentum és visszatérési érték. Konstansok.) 71. Öröklés (Öröklés fogalma, UML jelölése. Specializáció és absztrakció. Adatvédelem az öröklés során. Függvény felüldefiniálás (elrejtés) az utódosztályokban. Hatókör feloldó operátor vagy base. Többszörös öröklés és problémái. Lezárt osztályok.) 72. Nem virtuális, virtuális metódusok (Virtuális és nem virtuális metódusok viselkedése közti különbség. Fordításidejű, futásidejű kötés. Polimorfizmus. VMT. Virtualitás lehetőségei a különböző nyelvekben. Statikus metódus és virtuális metódus kapcsolata. Lezárt metódusok. Komponensek új verziói és a virtualitás.) 73. Az értékadás problémái (s típusú referencia/mutató utód típusú objektumra hivatkozik/mutat. Típuskényszerítés. Az ‘is’ és az ‘as’ operátor. Hozzon példákat az osztálykönyvtárból az elv alkalmazására!) 74. Absztrakt interfész (Absztrakt függvény. Absztrakt osztály. Interfész fogalma. Szerepük az öröklésben. Azonosság és különbség az interfész és az absztrakt osztály között.) 75. Kivételkezelés (A kivételkezelés fogalma. Kivétel dobása, elkapása. Különböző típusú kivételek. Kezeletlen kivétel. Egymásba ágyazott kivételek. Egy választott osztálykönyvtár és a kivételkezelés.) 76. Operátor overloading (Az operátor átdefiniálás szabályai. Egy választott operátor átdefiniálása választott nyelven, különböző típusú paraméterekkel. Konverziós operátorok.) 77. Template fogalma (Függvény overloading vagy template függvény. Függvény paraméter és típus paraméter közti különbség. Template osztályok. A template bemutatása egy konkrét osztályon keresztül.)
3
Elméleti alapok, nyelvek, paradigmák
4
1. A 0-s nyelvosztály. A Turing gép definíciója. Mit jelent a T Turing-gép által elfogadott nyelv, és milyen típusú? Szubrutin Turing-gépen. A Turing-gép változatai és a Turing-géppel ekvivalens gépek. (Mit jelent az ekvivalencia. Bizonyítani itt nem kell.)
Turing-gépek és a 0-s nyelvosztály: Bevezetés: Alan Turing: 1936 Turing-gép Noam Chomsky: 1956 Nyelvosztályok Nagy ugrás következik: a 3-as és 2-es nyelvosztály felismerő gépei után a „minden felismerhetőt” felismerő gépek következnek, a Turing-gépek. Ehhez kapcsolódóan a „minden formálisan leírható” nyelvet tartalmazó 0-ás nyelvosztály következik. A 3-as és 2-es nyelvosztályoknál jól látható a szövegszerű jellemzések szerepe. Gyakorlati használatuk is erre épül. Nézzük meg még egyszer a fizikai megvalósítás méretigényét a két felismerő gépre: Reguláris nyelv – véges automata: A gép mérete csak az állapotátmeneti rendszertől függ (gráf éleinek száma), konstans. Egy n hosszú mondat elfogadása csak n-el arányos mennyiségű időt igényel. Környezetfüggetlen nyelv – veremautomata: A gép mérete a mozgásokat leíró 3 rendszer méretével arányos. Egy n hosszú mondat elfogadása az elemző fa felépítését igényli, ezért n logn -nel arányos időt (lépésszámot) igényel. Ezen felül a veremmemória fizikai mérete és n-nel arányos. Programozási nyelveken mindkét automata programja elkészíthető. A veremautomata esetében nagy mondatok elemzésénél tárkezelési problémák jönnek be. A Turing-gépek szerepe egészen más. Elvi, elméleti szerepet töltenek be. A céljuk nem a felhasználás, mint az előző két automata esetében. Feladatuk az algoritmusok, eljárások (procedúrák) segítségével megoldható feladatok jellemzése, az algoritmusok elméleti tárgyalásához eszköz, matematikai módszer biztosítása. Mit tudnak a Turing-gépek? Válasz: a Church-tézis. A Church-tézis azt állítja, hogy minden probléma, amelyre eljárás, procedúra szerkeszthető Turing géppel megoldható. Ez nagyon súlyos kijelentés, hiszen ez annyit jelent, hogy a Turing-gép a matematikai értelemben vett megismerhetőség határa. Más megfogalmazásban a kiszámíthatóság szerepel: minden intuitíva kiszámítható függvényhez létezik Turing-gép, amely ugyanazt a függvényt határozza meg. A tézis nem tétel. Nincs bebizonyítva. Eddig minden konkrét esetre bebizonyították. A Church-tézis egyszerre pozitív, és negatív állítás:
+: Ami megoldható, azt Turing-géppel meg lehet oldani. -: Mást nem tudunk megoldani, csak azt, amit a Turing-gépek tudnak. Ez a gondolkodás elvi korlátja. Nem minden kérdésre tudnak a Turing-gépek választ adni. Például, a 0-s nyelvosztály esetében a w ∈ L kérdésre nem minden nyelvhez lehet a választ megadó Turing-gépet konstruálni, úgy, hogy az w ∉ L esetben is véges lépésben választ adjon. Bevezetés vége Vannak Turing-géppel eldönthetetlen kérdések. Ebből az is következik, hogy a matematikában is vannak eldönthetetlen kérdések. (Kurt Gödel eldönthetetlenségi tétele). Majd látunk rá példát A 0-s nyelvosztály
G N , ∑ , P , S grammatikájában a P-beli szabályokra egyetlen megszorítás van: az
szabály baloldalán szerepeljen nem terminális: A Church-tézis szerint
∗
∈P
∗
∈ N ∪∑ N N ∪∑ .
w ∈ LG felismeréséhez létezik Turing-gép, ami akkor és csak akkor fogad el egy w mondatot, ha
w ∈ LG . A G grammatika segítségével a w ∈ LG mondathoz létezik véges levezetés, ami véges idő alatt megtalálható, tehát ez megoldható feladat. A w ∉ LG esetről általában nem tudjuk eldöntését garantálni. Fordítva is igaz, minden (felismerő) Turing-géphez létezik ekvivalens grammatika.
5
A Turing-gép felépítése:
Mindkét irányban végtelen, írható és olvasható cellákból álló szalag. A vezérlés az állapot és a beolvasott érték alapján új értéket ír vissza, jobbra vagy balra lép a szalagon, átmegy egy állapotba.
Formális megadás:
T =Q , ∑ , ,{ l , r } , , q 0, F , ahol -
Q : állapotok véges halmaza ∑ : input nyelv abc-je : a szalag abc-je ∑ ⊂ , ha üres szimbólumot „bl” (blank) jelöli, ez csak olvasható, felülírható, de nem írható jel. : a mozgások véges halmaza q 0 : kezdő állapot, q 0 ∈Q F : végállapotok halmaza, F ⊆Q .
A mozgások:
: Q× ⇒Q× – {bl }×{l , r } Ha egyértelmű: determinisztikus, ha nem, akkor nemdeterminisztikus. A blank „bl” szimbólum szerepe: azt jelzi, hogy üres a szalag eleje, vége. Ha a gép olvassa, felülírja azonnal. Az {l, r}szerepe: - l :balra lép (left) - r : jobbra lép (right) A T Turing-gép felismeri (elfogadja) a
∗
w ∈∑
szót:
- Kiinduláskor az input szalag a w szót tartalmazza, előtte és utána üres. - Az olvasófej w első betűjén áll, és a gép a q 0 állapotban van. - A gépnek van olyan mozgássorozata, amelynek során a teljes w szót elolvasta, és F-beli állapotba jutott. Példa: Igen egyszerű feladat: az input szó első betűje megegyezik-e az utolsóval? Állapot indexe: (első betű, olvasott betű) - jobbra lép, azt ír, amit olvasott, - kivétel: ha „bl”-et olvas.
q 0 , a q a ,a , a , r q a , b , c q a ,c , c , r q a , a , bl f 1 , a , l - a válasz igen: f 1 állapot q a , b , bl f 2 , b , l - a válasz nem: f 2 állapot Szubrutint lehet írni: Egyik Turing-gép szubrutinként (szolgaként, segéd-berendezésként) használ egy másikat. Legyen T 1 és T 2 két Turing-gép, Q 1 ∩Q 2 =0 , diszjunkt állapotok. T 1 kezdőállapota q 01 ,
T 2 kezdőállapota q02 A T 1−et módosítsuk, hogy egy q , a állapotban hívja meg T 2−t , majd T 2 befejeződése után jusson vissza egy p állapotba.
T 1−ben vegyük a q , a q 02 , a , r mozgást, T 2−ben az elfogadó állapot helyére írjuk p-t. Ezek után egyesítsük a két gépet.
6
Feladat: Turing-gép szerkesztése, amely egy másik Turing-gépet utánoz, úgy, hogy a gép leírását megkapja. 1.
Hogyan adjuk meg egy T Turing-gép leírását? Táblázattal. Az állapotokat számozhatjuk, helyettesíthetjük sorszámukkal. A táblázat egy sora: 5 elemből áll: < állapot , olvasott jel , írott jel , új állapot , irány > Az állapotot pl. 10-es számrendszerben, az irányt 0, 1-gyel (bal, jobb) adhatjuk meg. Használhatunk speciális szalag-jeleket: < , > a sor eleje és vége, # : a bejegyzések vége. Pl.: a 5 , a=6 ,b , l mozgásnak a 5 # a # b # 6# l # jelsorozat felel meg. Ilyen módon kódolhatjuk az input szalagra a T leírását. Legyen az w T .
2.
Hogyan utánozzuk T-t? A T lépés leutánzása:
w T w és T ' inputja. Fel kell jegyezni: hol áll T a saját szalagon, és hogy mi a T állapota.
- T aktuális címére állni - olvasni a cellát (de nem felülírni) - az olvasott érték szerint (pl. állapottal kódolható) - kikeresni a - megfelelő sort, - feljegyezni az új állapotot - az új-érték, irány szerinti állapotba visszamenni, T szerint címre írni az új értéket, lépni, feljegyezni az aktuális címet.
A Turing-gép változatai, ekvivalens gépek: 1, A szalagjelek megválasztása, : Lényegtelen, mi a véges abc a szalagon. Elég egyetlen jel és a „bl”. Gyakori a ={ 0,1, bl } választás. Tetszőleges véges ábécé: a 1 , a 2 ,… , a n átkódolható. Az indexeket binárisan átkódolhatjuk: szükséges az elválaszthatóságuk (prefixmentes kódolás jó). Átkódolással minden Turing-géphez készíthetünk ekvivalens bináris szalaggal dolgozó Turing-gépet. Emberi érthetőség miatt kényelmes a szalagon speciális jelek használatát megengedni. 2, Egyirányú szalag: ekvivalens a két irányban végtelen szalaggal rendelkező gép lehetőségeivel. Egy szalagos gép:
7
3, Több szalag egyidejű használata (párhuzamos gép): Nem növeli a Turing-gépek lehetőségeit. pl.: két szalagos géphez egy szalagos gép: 4 „sávos” szalag.
T 2 gép :
T 1 gép :
Kódolás: - első sáv: az első szalag másolata - második sáv: 1, ha a kétszalagos gép ezen a cellán áll, 0 ha nem - harmadik sáv: a második szalag másolata - negyedik sáv: 1, ha a kétszalagos gép ezen a cellán áll, 0 ha nem
A
T 1 működése: A T 2 gépnek megfelelő p állapotban
- megkeresi a 2. sávban az 1 értéket, megjegyzi X értékét (pl.: P 4X állapotba lép) - megkeresi a 4. sávban az 1 értéket, megjegyzi az Y értéket, (pl.: P X ,Y állapotba kerül) - A T_2 gép (p, x, y)- hoz tartozó
q , x ' , irány1 , y ' ,irány 2 mozgásnak megfelelő állapotot hozza létre a T 1 szalagján.
8
2. A bináris szalagot használó Turing gép mozgási szabályainak megadása bináris sorozat formájában. (táblázattal ) Az utánzó Turing-gép konstrukciója. Ebből az univerzális Turing-gép konstrukciója. (Turing-gépek sorszámozása a bináris táblázat alapján.) Több szalag egyidejű használata (párhuzamos gép): Nem növeli a Turing-gépek lehetőségeit. pl.: két szalagos géphez egy szalagos gép: 4 „sávos” szalag.
T 2 gép :
T 1 gép :
Kódolás: - első sáv: az első szalag másolata - második sáv: 1, ha a kétszalagos gép ezen a cellán áll, 0 ha nem - harmadik sáv: a második szalag másolata - negyedik sáv: 1, ha a kétszalagos gép ezen a cellán áll, 0 ha nem
A
T 1 működése: A T 2 gépnek megfelelő p állapotban
- megkeresi a 2. sávban az 1 értéket, megjegyzi X értékét (pl.: P 4X állapotba lép) - megkeresi a 4. sávban az 1 értéket, megjegyzi az Y értéket, (pl.: P X ,Y állapotba kerül) - A T_2 gép (p, x, y)- hoz tartozó
q , x ' , irány1 , y ' ,irány 2 mozgásnak megfelelő állapotot hozza létre a T 1 szalagján.
Az univerzális Turing-gép és a megállási probléma A T Turing-gép mozgási rendszerének megadása táblázattal: Elég, ha csak a ={ 0 ,1 , bl } szalag-ábécé használatára szorítkozunk, és determinisztikus gépekre. Olyan táblázatot készítünk, amit könnyen tudunk sorfolytonosan bináris adatként kezelni. A p , a=q , b ,irány mozgást a < p , a , q , b ,irány > ötössel adhatjuk meg. Legyen T állapotainak száma n. Sorszámozzuk az állapotokat, és sorszámukat [log 2 n] (felső egész) hosszú bináris kóddal adjuk meg. A beolvasott a érték lehet 0, 1 vagy bl: Kódjaik: bl – 00 0 – 01 1 – 11 A kiírt érték csak 0 vagy 1 lehet. A mozgás irányát a bal – 0, illetve a jobb – 1 kódolja. Egy sor kódolásához 2 [log 2 n]4 bit szükséges. A rendszer leírásához meg kell adni n értékét, és a táblázat sorainak számát, M-et.
T leírása: T =1n 0 1M 0sor 1…sor M > , és a sorokat érték szerint rendezve soroljuk fel.
A T gép
9
Feladat: Szerkesszünk Turing-gépet, amely tetszőleges T Turing-gép T leírót és utána egy w szót kapva inputként utánozza T-t, és w úgy dolgozza fel, mint T. Vagyis, ha T elfogadja w-t, akkor az utánzó gép is elfogadja, ha T nem elfogadó állapotban áll meg, akkor az utánzó gép is nem elfogadó állapotban áll meg, és ha T nem áll meg, akkor az utánzó gép sem áll meg. Tervezzük meg a szalag használatát:
Egyirányú szalag, T munkaszalagjának utánzására: A páratlan sorszámú cellák a w-től jobbra, a párosak a balra elhelyezkedő celláknak felelnek meg. Lépések vázlata: - A T gép egy p , a q , b ,irány lépésének utánzása a következő állapotból indul: A T-utánzó modul olvassa „a”-t. Az olvasási címe cím1-ben szerepel a szalagon. A Táblázat-kezelő modul olvasási címe a cím2 szalagrészen van. A cím2 a < P , x , ... > sorok közül az elsőre mutat. (Az utánzó gép állapotainak indexeiben kódolunk az olvasott jeleknek megfelelő információt.) 1. lépés: A T-utánzó modul működik, és „a”-t olvas. Átmegy elmegy cím2 olvasására.
P a ,k állapotba, és csupa P a ,valami típusú állapotot használva
2. lépés: A Táblázat-kezelő olvassa cím2-től kezdve az T táblázatot, továbbra is P a ,valami típusú állapotokat használva. A táblázat < P , x , q , b , irány > sorai közül megkeresi az x=a értéket tartalmazó sort. (Ha nincs ilyen, megáll, nem elfogadó állapotban.) Ehhez kell az állapotban az „a” index. Ha megtalálta a megfelelő sort, akkor állapotokkal folytatódik a futás. 3. lépés: megkeresi
q b , irány , valami típusú
T -ben az első < q , y , ... > q-hoz tartozó sort. (Ha nincs megáll.) Ennek címét írja cím2-be.
4. lépés: cím1 értékét az állapotban lévő irány index szerint
−2 ,−1 , 1 , 2−vel változtatja, kiírja.
5. lépés: Elmegy az (új) cím1-re. Az irány index értéke szerint a régi cím1-re áll, és beírja az indexből „b”-t. Az új cím1 olvasására lép, vagyis vissza az 1. lépésre. Jelöljük az így kapott utánzó gépet UT-vel. Az UT utánzó gépből könnyen megkapjuk a szokásos univerzális U Turing-gépet: Kezdjük a (bináris szalagot használó és determinisztikus) Turing-gépek sorszámozásával. A sorszámozást az T leírásoknak, mint bináris egész számoknak monoton növekvő sorrendje adja. - az első a sorrendben az üres (állapot nélküli) gép. A leírása n=0 és M =0 szerint 00 . - minden más esetben n≥1 miatt T 1-es bittel kezdődik, vagyis 2-es számrendszerben értékes jeggyel. Ez egyértelmű rendezést ad az T kódokra. - A T géphez az i indexet rendeljük, ha T az i-edik a felsorolásban. Jelölésben T i az i-edik Turing-gép. Az U univerzális Turing-gép az
1i 0 W bemenetre a T i -nek megfelelően dolgozza fel w-t.
U felépítése: - i-hez előállítja az i-edik leírást,
T i -t. (Ez nem nehéz feladat.)
- Meghívja UT-t az T i W inputtal.
10
3. A Chomsky-hierarchia. A grammatikákra tett megszorítások nyelvosztályonként. Az egyes nyelvosztályokra az elfogadást milyen géppel lehet elvégezni? (Csak a gépek megnevezése kell.)
A Chomsky hierarchia: Megszorítások a produkciós szabályokra: szigorú->gyengébb. Vannak
1 2 Szokásos jelölések: azonos jobboldalakra: ... n
}
3 2 1 0 osztályok.
jelölése : 1∣2∣…∣n
A nemtermálisokat gyakran a nyelv ABC-jével adjuk meg, ilyenkor <elnevezés> alakot használunk. Pl.: < magyar mondat > < alanyi rész > < állítmányi rész > ∣ < állítmányi rész > < alanyi rész >
< alanyi rész > ∣< alanyi előrész > < alany > < alanyi utórész >
Grammatikákra tett megszorítások nyelvosztályonként 3-as osztály: Reguláris nyelvek. G
∑ , N , P , S
P: minden szabály:
A aB
vagy
A a Megengedjük még az
S −szabály , de csak a mondatszimbólumra. Az üres szó akkor és csak akkor eleme L(G)-nek, ha P-ben van S szabály. Ezek a jobb-reguláris grammatikák. Ha minden szabály A Ba , akkor bal reguláris. Elfogadása: Véges automatával.
G= N , ∑ , P , S grammatika 2-es osztályú, más néven környezetfüggetlen, ha a levezetési szabályok alakjai: A w , ahol A∈ N és w ∈ N ∪∑ , egyetlen kivétel az S −szabály.
2-es osztály: Környezetfüggetlen nyelvek. A
Elfogadása: Veremautomatával. 1-es osztály: Környezetfüggő nyelvek. A P szabályai lehetnek:
G N , ∑ , P , S -ben P-ben itt is lehet S .
∗
A alakúak, ahol A∈ N , ∈ N ∪∑ , , ∈ N ∪∑ . A szabályokban az A környezetét adó , -ról kapta az osztály a környezetfüggő nyelvek elemzést. 2, változat: , ahol -ban van nemterminális, és ∣∣≤∣∣ (hosszak) nem csökkenő nyelvtan. 1, változat:
A két nyelvosztály ugyanaz. Elfogadása: Lineárisan korlátozott Turing géppel. 0-ás osztály:
G N , ∑ , P , S grammatikájában a P-beli szabályokra egyetlen megszorítás van: az
baloldalán szerepeljen nem terminális: Elfogadása: Turing géppel.
∗
∗
∈ N ∪∑ N N ∪∑ .
11
∈ P szabály
4. A környezetfüggő nyelvek. Grammatika alakja. A lineárisan korlátozott Turing-gép. Az 1-es nyelvosztály grammatikái: A P szabályai lehetnek: 1, változat:
G N , ∑ , P , S -ben P-ben itt is lehet S .
∗
A alakúak, ahol A∈ N , ∈ N ∪∑ , , ∈ N ∪∑ . A szabályokban az A környezetét adó , -ról kapta az osztály a környezetfüggő nyelvek elemzést. 2, változat:
, ahol -ban van nemterminális, és A két nyelvosztály ugyanaz.
∣∣≤∣∣
(hosszak) nem csökkenő nyelvtan.
A nemcsökkenő tulajdonság miatt w ∈ LG eldöntéséhez elég S-ből a sok) levezetést megnézni. Az L G nyelv rekurzív, ha G 1-es osztálybeli.
∣w∣ -nél nem hosszabb mondatformákra vezető (véges
Az elfogadó gép: Olyan Turing-gép, amelynek szalagja sz input méretével megegyező véges hosszúságú. Ezek a lineárisan korlátozott Turing-gépek. Jelöljük őket LKT-vel. Ha egy LKT nem elfogadó állapotba jutva lép le a szalagról, futása befejeződik. (Ezért egy LKT futása vagy véges, vagy periodikus.)
G= N , ∑ , P , S grammatikájához az LKT gép szalag abc-je legyen párok, ahol x ∈ ∑ és y ∈ N ∪∑ . Az 1-es osztály
∑
és az < x , y > alakú
A gép egy cellájában az input értéke „a” volt, akkor az „a” értéke a cellában nem változik, csak < a , y > érték írható be. Az LKT gép az szabályoknak megfelelő mondatformákat a második komponensben alakítja ki. A kialakított mondatforma hossza nem csökkenhet. Ha a végén a második komponensek mind komponens azonos lett, az LKT elfogadta az inputot.
∑
-beliek, és minden cellában a két
A cellák komponenseit egymás alá rajzoltuk. A X mondatformát az helyettesítésekkel alakítja a gép, hasonlóan a Turinggép konstrukciójához. A konstrukció nemdeterminisztikus gépet ad! Fordított irányban: LKT-hez G konstrukciójában a Turing-gépen konstrukció nem jó, ott törölni kell a segéd nemterminális jeleket, ami csökkentő szabály. Az állapot beszúrásával a szalagon lévő szó közepébe, szintén nem élhetünk, mert ki kell a végén törölni, s ez megint csökkentő. Mindez elkerülhető, ha a nemterminálisok indexelésébe helyezünk el mindent: Például az [ xx ] -nek feleljen meg Axx , minden x ∈ -ra.
∑
[ yx ] -nek feleljen meg Ayx , minden y ∈ és x ∈ ∑ -ra. A p [ yx] -nek feleljen meg A pyx . Az
Az LKT gép minden lépése egy nemterminálishoz kapcsolódik: amelyik három indexű. Például: p , a q , b , r −hez A pax Acy Abx Aq c y alakú szabályok tartoznak,
p , a q , b ,l −hez
Acy A pax Aqcy Abx alakú szabályok tartoznak.
A pax , vagy Acy indexeléses nemterminálisok helyett használható a Baskus-Naur jelölés: < pax > , < cy > is. Az LKT gépek közül nézzük a bináris szalaggal dolgozó gépeket. Ezek is Turing-gépek, leírhatók mozgásaik T mintájára. Az
Legyen
L11={ T ∣ ahol T LKT gép és elfogadja saját leírását.} L12={ T ∣ ahol T LKT gép és nem fogadja el saját leírását. } A borbély-paradoxon mintájára az L12 nyelv nem lehet 1-es osztálybeli, nem létezhet hozzá felismerő LKT gép. Turing-géppel viszont felismerhető lesz.
12
5. A reguláris nyelvek. Grammatika megadása. Véges állapotú automata, grammatikák és automaták megfeleltetése. Változatok (nem determinisztikus, determinisztikus, teljes) G ∑ , N , P , S P: minden szabály: A aB vagy
3-as osztály:
A a Megengedjük még az S
−szabály , de csak a mondatszimbólumra. Az üres szó akkor és csak akkor eleme L(G)-nek, ha P-ben van S szabály. Ezek a jobb-reguláris grammatikák. Ha minden szabály A Ba , akkor bal reguláris. Példa:
G{ a , b , c } , N ={ A , B , C , S } , P , S , ahol P : S cA , A aB , A aC , B cA , A a , B b , C c
Építsünk gépet, ami felismeri L(G)-t. Ötlet: Szabály alkalmazása: a baloldali nemtermálisból a jobboldal termálisa a jobboldal nemtermálisához, illetve befejezéshez / elfogadáshoz vezet. Ábrázoljuk irányított gráfban: Csomópontok: a nemtermálisok, és az elfogadó szimbólum: V Élek címkéje: termális Például: A aB -ből lesz. A G-hez tartozó gráf: Ez a gráf egy automatát ad meg, véges állapotú, nem determinisztikus, mert „A”-ból például „a” éllel 3 irányba mehetünk. A gráfban lehet kör. Ha van kör: rekurzív a nyelvtan. Amit kaptunk: egy nemdeterminisztikus véges automata megadása irányított gráffal.
Nem determinisztikus véges automata: Q : állapotok véges halmaza : abc (input)
M Q , ∑ , , q0 , F
∑
: állapotmenetek, mozgási szabályok: A , a =B ; q 0 : kezdőállapot q 0 ∈Q F ⊆Q végállapotok, elfogadó állapotok. A
:Q×∑ ⇒ Q többértékű, nem determinisztikus
∗
w ∈ ∑ feldolgozása: M a q 0 -ból indul, olvassa w betűit, minden új olvasott betűre lép, valamelyik mozgási szabályt használva. Eljut egy q , w ' konfigurációhoz, ahol w' a w be nem olvasott része. M elfogadja w-t, ha q 0 -ból indulva a szó végén eljut egy F-beli állapotba (van ilyen feldolgozás). Jelölésben: Az M által elfogadott nyelv ∗
L M ={ w∣q0 , w M P , ∧P ∈ F } q 0 , w – kezdő konfiguráció ∗M - egymáshoz fűződő mozgások. P , végigolvasás konfigurációja. M nem fogadja el w-t, ha csak olyan mozgássorozat van, ami nem olvassa végig w-t, vagy ha végigolvassa, akkor nem elfogadó Fbeli állapotba jut Automata és jobb reguláris nyelv megfeleltetése: G – jobb reguláris nyelv – a példában konstruáltunk hozzá automatát. Általánosan: „A” szabályokhoz átmenetek: A aB <=> A , a = B A a <=> A , a =E , ahol E ∈ F , elég egy állapot egyben elfogadó állapot. Másként: S ,=E
q 0=S , S esetén S ∈ F . Vagyis a kezdő
A konstrukció speciális automatát eredményez: az egyetlen E elfogadó állapotból nem indul mozgás, a gráfban nem indul kivezető él belőle. Amennyiben S ∈P , ezt egy speciális mozgással, úgynevezett −mozgással adhatjuk meg: S-ből az üres jel (nem olvassuk az inputot) hatására léphetünk E-be.
13
Azt kaptuk Tétel: Minden G reguláris nyelvtanhoz létezik ekvivalens nemdeterminisztikus végállapotú automata, M, hogy L(G)=L(M). Igaz a tétel megfordítása is. Tétel: Minden M végállapotú nemdeterminisztikus automatához létezik ekvivalens reguláris nyelvtan, G, hogy L(M)=L(G). Bizonyítás: G megadása: Legyen M Q , , , q0 , F , akkor az ekvivalens G N , , P , S megadása: N =Q , vagyis a Q állapotai legyenek G nemterminálisai S=q0 , a mondatszimbólum legyen a kezdőállapot. P : három típusú szabályt képezünk: 1, P aq , ha p , a=q ∈ . Ezek a nem befejeződő mozgások 2, P a , ha p , a=q∈ , és még q ∈ F is teljesül
∑
3,
∑
q 0 , ha q 0 ∈F . Az egyetlen −mozgás. Az üres szó elfogadásához.
(Nézzük meg, milyen automatát kapnánk ebből a G-ből konstruálva! Nem egyezik a kiinduló M-mel!) Meg kell mutatni mindkét irányban az L(G)=L(M) teljesülését. A w szó elfogadását mind G-re, mind M-re a levezetést / mozgássorozatot szemléltető gráf egy útvonala adja. A konstrukciókat úgy készítettük, hogy G és M gráfja ugyanaz legyen. Balreguláris nyelvtanok: Szabályok: Automata mozgás – a gráfon visszafele: A Ba <=> B , a =A A a <=> q0 , a= A Lehet:
S <=> q0 ,=S
Ez az automata elfogadja w-t, ha van w útvonal
q 0 -ból S-be.
Tétel: A balreguláris grammatikák = jobb reguláris grammatikák. Biz.: A G balreguláris grammatikába M automata amire L(G)=L(M). Az M-hez létezik jobb reguláris G', amire L(M)=L(G'), tehát G-hez létezik ekvivalens jobb reguláris G' : L(G)=L(G'). Vegyes nyelvtan nem reguláris:
G N ={ X , S } , P , ∑ ={a , b} , S P={ S aX , X Sb , X b }esetén a L G ={a i bi ∣ i=1, ... , } nyelv nem reguláris.
Determinisztikus automaták: M determinisztikus, ha minden mozgása egyértelmű, azaz
A , a = B egyértelmű minden A∈Q , a ∈∑ −ra
Tétel: Minden nemdeterminisztikus automatához létezik ekvivalens determinisztikus automata. Biz.: (vázlatos) Az M Q , , , q0 , F -hez konstruálunk M det Q' , , ' , q 0 , F ' determinisztikus automatát, amelyen
∑
∑
L M =L M det . Q' megadása q ' ∈Q ' , q ' ⊆Q , az eredeti Q részhalmazai. ' ' ' ' Ha A , B∈Q , és ' q 1 , a=q2 ,akkor, ha A∈q 1 és A , a =B∈ , akkor B ∈q 2 . Példa:
Nemdeterminisztikus ⇒ Determinisztikus
A felépítés a q 0 -ból indul, rekurzívan megy előre. Az elfogadó állapot.
F ' elfogadó állapotok: q ' ∈Q ' elfogadó, ha van benne eredeti F-beli 14
A gráfban
(kettős körvonal) jelöli az elfogadható állapotot.
Teljes automata: Minden állapotban minden inputra lép. Állítás: Minden automata teljessé tehető. Ehhez csapdaállapotot vezetünk be: ha M-ben (A,a)-hoz nincs lépés, akkor M teljes -ben legyen
' T , a=T , ahol T a csapdaállapot. Legyen még M teljes −ben ' T , a =T , minden a ∈ ∑ -ra.
A determinisztikus és teljes automatákhoz egyértelműen (izomorfia erejéig [állapotok átnevezése]) szerkeszthető minimális automata, ami a legkevesebb állapotot használja. A következő átalakítási sorozat megadható:
M Determinisztikus Teljes Minimális : M min . L M = L M min .
Két automata akkor, és csak akkor ekvivalens, ha minimális automatájuk megegyezik. Ennek alapján automaták ekvivalenciája és ennek megfelelően reguláris grammatikák ekvivalenciája eldönthető. (A többi nyelvosztályra ez a tulajdonság már nem teljesül!)
15
6. Az önmaguk leírását elfogadó, illetve az önmaguk leírását nem elfogadó Turing gépek leírásai milyen nyelvosztályba tartoznak. A Turing gépek megállásának eldönthetetlensége. Ezek a 0-ás nyelvosztályba tartoznak!
Önmagukat elfogadó gépek: Tekintsük azoknak a gépeknek a leírásait amelyek elfogadják saját leírásukat. L01={ T ∣ T elfogadja T −t } . Állítás: az L01 nyelv elfogadásához létezik Turing-gép: - meghívja UT-t az T T inputra - Ha UT elfogadó választ ad, akkor T ∈ L 01 - Ha
T ∉ L 01 , akkor UT nem adhat elfogadó választ, vagy nem elfogadó állapotban áll meg, vagy nem áll meg.
Önmagukat nem elfogadó gépek: Borbély paradoxon: Athén borbélyának megparancsolják, hogy mindenkit, aki nem maga borotválkozik, borotváljon meg. Ki borotválja a borbélyt? Tekintsük azoknak a gépeknek a leírását, amelyek nem fogadják el saját leírásukat: L02={ T ∣ T nem fogadja el T −t } . Állítás: Az L02 nyelvhez nem létezik felismerő Turing-gép. (Az nincs eljárás, ami felismeri)
L02 nyelv nincs benne a 0-s nyelvosztályban, a Church-tézis szerint
Biz.: Indirekt módon tegyük fel, hogy a
T 02 gép felismeri az L02 nyelvet. Mit fog csinálni TU az T 02 T n bemenetre: - Ha elfogadja, az hiba, mert akkor egyrészt T 02 ∈L 02 lenne, hiszen T 02 felismeri T 02 -t. Viszont akkor T 02 felismeri saját leírását, tehát nem lehet T 02 ∈ L02 . - Ha nem fogadja el, akkor T 02 nem fogadja el saját leírását, tehát T 02 ∈ L02 . Viszont akkor T 02 -nek el kellene fogadnia T 02 -t. Ellenmondásra jutottunk! ( T 02 a „borbély”)
A megállási probléma eldönthetetlensége: Tétel: Nem létezik olyan Turing-gép, amely minden T w bemenetre eldönti, hogy a T gép a w bemenetre megáll-e. Biz.: Indirekt módon, tegyük fel, hogy létezik ilyen T ∞ gép. Akkor konstruáljuk a következő gépet L02 felismeréséhez: - Meghívja a T ∞ gépet az T T bemenetre. - Ha T ∞ azt válaszolja, hogy T az T -n nem áll meg, akkor T ∈ L 02 elfogadást nyert. - Ha T ∞ azt válaszolja, hogy T az T -n megáll, meghívja UT-t az T T bemenetre. UT nyílván megáll, és
T ∈ L 02 elfogadást nyert. - Egyébként, ha UT elfogadó állapotban állt meg, akkor T ∉ L 02 nyert elfogadást, vagyis Mivel az L02 nyelvhez nem létezik felismerő Turing-gép, ellentmondásra jutottunk. - Ha UT nem-elfogadó állapotban állt meg, akkor
T ∈ L 01 .
A megállás eldönthetetlenségéből igen sok eldönthetetlen probléma következik. A 3-as, 2-es, és 1-es nyelvosztály nyelveire a nyelvhez tartozás eldönthető, pontosabban, azt is igazolni tudjuk véges lépésben, hogy ha egy mondat nem eleme a nyelvnek. A 0-s nyelvosztály esetében az nem mindig teljesül.
Általános eldönthetetlenségi tétel Turing-gépben: a Turing-gépeknek egy részhalmaza, amit valamilyen tulajdonsággal adunk meg. Az U-nál használt T i rendezés szerint az A={i ∣ T i ∈ } halmaz akkor és csak akkor rekurzív ( tulajdonság eldönthető), ha az üres
Legyen
halmaz, vagy az összes Turing-gép.
16
7. Környezetfüggetlen nyelvek. A grammatika megadása. A levezetési fa és szerepe. A kettős pumpálási lemma. (Nagy Bar-Hillel lemma) A Chomsky hierarchiában a 2-es osztály. Def.: A G= N , , P , S grammatika 2-es osztályú, más néven környezetfüggetlen, ha a levezetési szabályok alakjai:
∑
A w , ahol A∈ N és w ∈ N ∪∑ , egyetlen kivétel az S
−szabály.
Megjegyzés: kiküszöbölhető, hogy a mondatszimbólum jobboldalon előforduljon, ugyanúgy, mint a reguláris nyelveknél. Egy mondat levezetését levezetési fán ábrázolhatjuk. (Reguláris nyelv esetében a levezetési út volt). Def.: A G egy levezetési fája: a, gyökere az S mondatszimbólum b, ha A∈ N -re egy A-val jelölt csúcs leszármazottjai balról jobbra
B1, B 2, … , B k , ahol Bi ∈ N ∪∑ , akkor
létezik P-ben A B 1, B2 ,... , B k szabály. A levezetési fa eredménye az a szó, ami a levelek balról jobbra végigolvasásával adódik. A levezetési fában akkor ér véget, ha minden levél terminálist tartalmaz. Példa: kifejezések: E – kifejezés, expression T – tag, term F – tényező, faktor
G : { E ,T , F } ; {a , ,∗, , } , P ; E P : E ET ∣T ; T T ∗F∣F ; F E ∣a
aa∗a levezetése :
Másik szabályrendszer:
P ' : E EE ∣ E∗E ∣ E ∣ a aa∗a levezetései :
Tétel: Környezetfüggetlen nyelvek is levezetési fák. A G környezetfüggetlen grammatika L(G) nyelvére teljesül, hogy w ∈ LG , akkor és csak akkor, ha létezik G-nek levezetési fája, aminek levelei w-t adják balról jobbra olvasva. Biz.: Terjesszük ki a levezetést mondatformákra. Nem követeljük meg, hogy a leveleken csak terminálisok álljanak. A fa által levezetett mondatformát a levelekben álló szimbólumok balról jobbra olvasásával kapjuk.
17
A tétel átfogalmazása: egy mondatforma akkor és csak akkor vezethető le, ha létezik levezetési fa, amelynek levelei balról jobbra a, Levezetéshez fa építése: S ⇒ 1 ⇒ …⇒ n levezetés. Teljes indukcióval: – n=0 eset : csak S lehet, a fa csak az S gyökérből áll. – 1 -et S 1 ∈ P alkalmazásával kapjuk. Legyen 1= A1 A2 … An , akkor a fa: n=1 eset :
–
-t adják.
indukciós lépés : S hosszú levezetésre igaz az állítás, a levezetési fa leveleiben S van balról jobbra. Az S1 ' '' hosszú levezetésben S ⇒ S 1 egy A B 1 … Bm ∈P alkalmazásával kaptuk, ahol S=S A S alakú, és A-ra alkalmazzuk a szabályt. Az új fa:
b, Levezetési fához levezetés rendelése: Az indukció a levezetési fa belső pontjainak száma szerint történik. – n=0 eset : az egyetlen S pontból álló fa csak akkor levezetési fája G-nek, ha S ∈ P. – n=1 eset : Csak akkor levezetési fa, ha S A1 A2 ... An ∈ P. A levelek olyan belső ponthoz kapcsolódnak, amelynek levezetési szabálya a leveleket adja. A levelek mondatformát adnak.
–
Indukciós lépés : s belső pontra igaz az állítás, a levelek mondatformát adnak, és ha a B1 , B 2 , … , B k levelek az A belső ponthoz kapcsolódnak balról jobbra, akkor A B 1 B 2 … B k ∈ P.
Tekintsünk egy S+1 belső pontból álló levezetési fát, és ebben leveleknek B1 ,… , Bm sorozatát, amelynek balról jobbra az A belső pont gyerekei. A levezetési fa tulajdonsága miatt A B 1 B 2 … B m ∈ P teljesül. Elhagyva „A” leveleit, „A” lesz a megmaradó fa levele, és a megmaradt fa is levezetési fa. Belső pontjainak száma S. Levelei az 1 A 2 mondatformát adják. Az A B 1 B 2 … B m ∈ P alkalmazásával 1 A 2 ⇒ 1 1 2 … m 2 levezetését kapjuk, ami éppen a kiinduló fa leveleinek balról jobbra felsorolása.
18
A kifejezések példa két szabályrendszere közül P szerint egyetlen fa felel meg aa∗a levezetésére, a P' szerint két különböző fa is megfelelt. Def.:Egyértelmű grammatika: minden levezetéshez egyetlen levezetési fa tartozik. Létezik bizonyíthatóan nem egyértelmű nyelvtan; pontosabban olyan nyelvtan, amihez nem létezik vele ekvivalens egyértelmű nyelvtan. (lásd: Bach Iván könyvének 83.oldala) Def.: Egy L környezetfüggetlen nyelv egyértelmű, ha megadható G egyértelmű környezetfüggetlen nyelvtan, amire L=LG . Tétel: A környezetfüggetlen nyelvek egyértelműsége eldönthetetlen. (Nem bizonyítjuk).
Nagy Bar-Hillel lemma (vwxyz szabály, kettős pumpálás): Mielőtt a felismerő gépre térnénk, a reguláris nyelvek pumpálási tulajdonságainak megfelelő nagy Bar-Hillel lemmát, másként a kettős pumpálást, vagy vwxyz szabályt mutatjuk meg. Legyen a G környezetfüggetlen nyelv terminálisainak száma n, a szabályok jobboldalának hossza legfeljebb k. Ha w ∈ LG , és hosszabb k n 1 -nél, akkor w=vwxyz alakba írható, és v w i x y i z ∈ LG , és y legalább egyike nem üres.
i=0,1 , .. , és w
Biz.: w levezetési fáján szemléltetve: A méret miatt van a levezetési fában S-ből egy a terminálisig legalább n1 hosszú út. Ezen egy nemterminális, A, ami legalább kétszer előfordul. Az A alatti részfákat nézzük: egymás helyére írhatók. Következmény: Az L={ x n y n z n ∣ n=1,2 , ... } nyelv nem környezetfüggetlen. A kettős pumpálást nem teljesíti. Az L nyelv előáll az alábbi két környezetfüggetlen nyelv metszeteként: ={a , b , c } , S közös. N ={ S , A , B} ;
∑
G1 N , ∑ , P 1 , S , P 1={ S AB , A aAb , A ab , B cB , B c } n n m L1= LG 1={ a b c ∣ n≥1 , m≥1 } , G2 N , ∑ , P 2 , S , P 2={ S AB , B bBc , B bc , A Aa , A a } , n m m L 2=L G 2 ={a b c ∣ n≥1 , m≥1} , L=L1∩ L2. . Tehát két környezetfüggetlen nyelv metszete nem mindig környezetfüggetlen.
19
8. Milyen műveletekre zártak, illetve nem zártak a környezetfüggetlen nyelvek. A tartalmazási kérdés eldönthetősége.
A környezetfüggetlen nyelvek néhány fontos tulajdonsága: 1, A kettős pumpálásnál láttuk, hogy nem zárt a nyelvek metszetére nézve: L1={a n bn c m ∣ n≥1, m≥1 } m n n L 2={a b c ∣ n≥1, m≥1 } , környezetfüggetlenek L=L1∩ L2= { a n b n c n ∣ n≥1 } , nem környezetfüggetlen. 2, Ha L1 és L2 környezetfüggetlenek, akkor L1∪ L2 is az. Az unióra zárt. Biz.: azonosan megy, mint reguláris nyelvekre: L1= LG1 , L2 =LG 2 , és a G1 ,G 2 grammatikákban minden nemterminális legyen különböző, a mondatszimbólum ne szerepeljen jobboldalon. Az L=L1∪ L2 G grammatikáját a két szabályrendszer egyesítésével, és a mondatszimbólumok azonossá tételével kapjuk.
G1 N 1 , ∑ , P 1 , S 1 , G 2 N 2 , ∑ , P 2 , S 2 , N 1∩N 2=0 , G N , ∑ , P , S = N = N 1∪N 2−{ S 1 }−{ S 2 }∪{ S } , ' ' P=P 1∪P 2 , ahol P 'i -t úgy kapjuk P i -ből, hogy S i helyére mindenütt S -et írunk.
Formálisan:
3, A komplementerképzésre nem zárt. Biz.: Ha zárt lenne, akkor L1 ∪L2 =L1∩L 2 is környezetfüggetlen lenne. 4, A sorozatra nézve zárt. A 2, alatti G1 ,G 2 -re: G={ ∑ ,{ S } ∪N 1∪N 2 , P={ S S 1 S 2 }∪P 1∪P 2 , S } L G =LG 1 LG 2
,
5, Tranzitív lezárás nem vezet ki. L=LG , és G-ben S ne legyen jobboldalon. L∗=L G∗ , ahol G N , ∑ , P , S . ∗ G = { N , ∑ , P∪S SS ∪S , S } (Az S az ∈ L∗ miatt szükséges. Felesleges, ha benne van P-ben.) A nemdeterminisztikus veremautomatákhoz nem lehet minden esetben ekvivalens determinisztikus automatát megadni. Ez lényegesen eltérő tulajdonság a véges állapotú automatáktól. Részosztály: determinisztikus veremautomaták, ennek megfelelően a determinisztikus környezetfüggetlen nyelvek. (L determinisztikus, ha van determinisztikus PM, amire L=L PM . ) (A determinisztikus környezetfüggetlen nyelvek zártak a komplementerképzésre, de nem zártak a metszetre és az unióra. Valódi részhalmazt képeznek a környezetfüggetlen nyelveken belül)
Tartalmazási kérdés eldönthetősége: 1, Ha w ∈ LG , akkor létezik véges levezetése, ami véges lépésben megtalálható. 2, Ha w ∉ LG : A környezetfüggetlen nyelvek levezetéseiben a mondatformák nem tudnak csökkenni. (Kivétel az S -szabály). Egy n hosszú mondatformából nem lehet n-nél rövidebb mondatot levezetni. Tehát, ha ∣w∣=n , w hossza n, akkor elég az n hosszú mondatformákig ellenőrizni a levezetéseket. Véges sok van belőlük.
20
9. Műveletek reguláris nyelvekkel, reguláris kifejezések, pumpálási lemma (kis Bar-Hillel lemma.)
Pumpálási lemma – Bar-Hillel lemma: q 0=S is állapotok között van!). Lemma: =a1 a 2 ... a m ∈ L , és m ≥n , akkor =uvw alakú, és ∣v∣ ≥1 , ∣uv∣ ≤n , ( ∣x∣ : az x hossza!) és uv i w ∈ L , minden i=0,1,2 ,... esetén. (Jelölés: v i : a v egymás utáni i-szer, i-szeres konkatenáltja saját
Legyen L reguláris nyelv. A felismerő M véges automata állapotainak száma legyen „n” (
magával). Biz.: A felismerő automata gráfjában csak n pont van, ezért az −t felismerő bejárás m ≥n miatt legalább n+1 pontot érint: a a a q 0 1 P i1 2 Pi2 … P imax m E , ezért P i1 , … , Pimax között van két azonos: P ij =P ik : ezt szemlélteti a csomópont a gráfban. A -ig elfogadott szó: u ; a körön elfogadott szó: v ; a -után elfogadott szó: w.
Minthogy az elfogadó út lehet: - a kör kihagyása uw elfogadása - a kör bejárása i-szer uv i w elfogadása Következmény:
G= N ={ S , X } , ∑ ={a ,b } , P={ S aX , X Sb , X b } , S grammatika által meghatározott nyelv: L G ={a i bi } , i=1,.. nem reguláris
Ha az lenne: valamilyen n-re teljesülne a pumpálási lemma. w=a m b m -ben valahol van a v szó. - Ha v csupa a, vagy b lenne, elhagyva az a-k és b-k száma nem egyezne. - Ha v=a i b j , akkor m−i i j m – j és
w=a a b b , m−i i j k m – j is L(G) eleme lenne, ami nyilván nem z =a a b b a n b n alakú.
Megjegyzés az −szabályhoz : Ha az S szabályt tartalmazza egy G grammatika, akkor nem. Megengedhető lenne tetszőleges A szabály, de ez kiküszöbölhető: { B aA , és A } helyett a { B aA , és B a } szabályokat vehetjük.
{}∈ LG , egyébként
A mondatszimbólum (S) ne szerepeljen a jobboldalon: G-hez G' , amiben S nem szerepel jobboldalon: G'-ben bevezetünk egy új S' állapotot, és ha G-ben A aS volt, akkor G'-ben A aS ' lesz. Ezen felül G-ben minden, S B -t megismételünk G'-ben S ' B szabályban is. ( S B is marad G'-ben!). L(G)=L(G')
Műveletek nyelvekkel: L , L1 , L 2 nyelvek ∗
L =∑ − L:
∑
felett (Halmazok!)
a komplementer
L1∪ L2 - unió L1∩ L2 - metszet L1⋅L2= L1 L 2 - a konkatenált nyelv, w ∈ L1 L 2 , ha w= ahol ∈ L1 és ∈ L2 . Ez a „szorzás” művelet. Li - i-szeres konkatenált, „hatvány”. L0 ={} - 0-adik hatvány, a szorzás egységeleme. ∞ ∗ L = ∪ Li - A tranzitív lezárt ( ∑∗ jelölés ennek felel meg) i=0 21
L
∞ = ∪ L i - (Ha ∈ L , akkor L =L∗ , ha nem, akkor ∉L ) i=0
Kérdés: a reguláris nyelvek halmaza melyik műveletre nézve zárt? Válasz: mindegyikre Bizonyítás: azt az alakot nézzük, amelyikben a bizonyítás szemléletesebb. Feltesszük, hogy L , L1 , L 2 reguláris nyelvek. Bizonyítjuk, hogy a belőlük képzett nyelv is az.
1,
L1∪ L2 : Legyen a két grammatika G1 és Feltesszük, hogy S nem szerepel a jobb oldalon.
G2. Csak a a mondatszimbólumuk legyen közös, S, N 1∩N 2={ S } .
G L ∪ L ={ N 1∪N 2 , ∑ , P={ P1 ∪P 2 } , S } 1
2
G1 automatája M 1 , G2 -é pedig M 2. Egyik se tér vissza a q 0=S kezdőpontba. Egyesítésük éppen G L ∪ L automatáját adja. Egy elfogadás vagy M 1 gráfját járja be, vagy M 2 -ét. Vagyis vagy L G 1 , vagy 1 2 L G 2 mondatát fogadja el.
Legyen
2, A komplementer, L : L-nek vegyük egy teljes, determinisztikus automatáját. Cseréljük fel benne az elfogató és a csapda állapotok szerepét. Az így kapott automata a komplementer nyelvet fogadja el. 3,
L1∩ L2= L 1∪ L 2 - de Morgan szabály. Közvetlen Bizonyítás: M 1 és M 2 állapotaiból képzett párok lesznek a metszetet előállító automata állapotai: M 1 Q1 , ∑ , 1 , q 0 , E 1 átmenet M 2 Q 2 , ∑ , 2 , q 0 , E 2 , P 1 q1 a P 2 q 2 , ha 1 P 1 , a =P 2 ∈1 , és 2 q1 , a =q 2 ∈ 2 - Elfogadó állapot: ha mindkettő elfogadó.
4, Konkatenáció:
L1 , L2−höz jobboldalon.
G1 N 1 , ∑ , P 1 , S 1 és G2 N 2 , ∑ , P 2 , S 2 , N 1∩N 2=0 , és mondatszimbólum nincs
G1∪G 2={ N 1∪N 2 , ∑ , P=P 1∪ P 2∪{ A aS 2 ∣ A a ∈ P1 } , S 1 } Szavakban: ha G 1−ben A a szabály van, akkor ez folytatjuk egy G 2 −beli mondattal, vagyis mondatszimbólummal: A aS 2 szabályt képezzük. M 1 és M 2 gráfjával szemléltetve: M 1 egyetlen elfogadó állapotát egyesítjük M 2 kezdő állapotával.
5, Tranzitív lezárás:
L , G N , ∑ , P , S , és P-ben S nem szerepel jobboldalon. L∗−hoz G ∗ : - minden A a ∈P -hez még hozzávesszük A aS szabályt, - ha S nincs P-ben, hozzávesszük G ∗−ban. ( Ez hozza be L∗={ } -t.)
Reguláris halmazok – reguláris kifejezések: Újabb módszer (algebrai jellegű) nyelv definiálására: műveletek segítségével építjük fel alaphalmazokból. Reguláris halmazok felett: Alaphalmazok: - 0 : üres halmaz - {} : üres szóból álló halmaz
∑
-
{ a } , ahol a ∈ ∑ ; egyelemű halmazok, egy betűből álló szavakból. (Szingletonok) 22
Halmazképzés: Ha P, Q reguláris halmaz, akkor az alábbiak is reguláris halmazok: - PQ : unió, két halmaz egyesítése - PQ : (konkatenáció) a P⋅Q – szorzás műveletek - P∗ : Tranzitív lezárt Műveleti precedencia: ∗ , ⋅ , . Ezeket lehet zárójelezni. Példák: ABC D b∗ a bab∗ a ∗ - páratlan sok „a” van benne, „b” tetszőleges helyen lehet. ∗
∗
bab a
- páros sok „a” van benne (lehet 0 is!), „b” tetszőleges helyen lehet.
Reguláris kifejezés: halmaznevekből, mint „konstansokból” és változókból épül fel a műveletekkel. Pl.: x 2 x , ahol , , konstans halmaz, x halmazváltozó. A kifejezések változói reguláris halmazokat vesznek fel behelyettesítési érték gyanánt. Az előző kifejezés x={a} helyén a 2a lesz.
, konstans halmazok, {}∉ legyen. x= x megadása: x=∗ - x= nyílván megoldás, kezdő megoldás, x 0 0 1 n ∗ x 0== , ebből x= x = x 0= , lehetséges megoldás, x 1= , … , x n= ⇒ x= a
Egyenletek is megadhatók:
megoldás. Az
x= x „lineáris” egyenlet mintájára lehet lineáris egyenletrendszert megadni, az is megoldható.
23
10. Nem determinisztikus Turing-géphez determinisztikus Turing gép szerkesztése.
Nem determinisztikus determinisztikus Tetszőleges T N nemdeterminisztikus Turing-géphez létezik (készíthetünk) vele ekvivalens T D determinisztikus Turing-gépet. Konstrukció alapötlete: a T N gép n hosszú lépéssorozatának mindegyikét lejátsszuk determinisztikusan a w inputra. Ha van közöttük elfogadó, kész; ha nincs, folytatjuk az n+1 hosszú lépéssorozatokkal. Szükséges szubrutinok: 1. A következő n hosszú lépéssorozat előállítása 2. A lépéssorozat végrehajtása, majd az induló szalagállapot visszaállítása. 3. n növelése. Legyen a feldolgozandó szó w=1 2 … k . A determinisztikus gép szalagján kettőzzünk meg w jeleit, két speciális jel (#) között:
A P N gép egy lehetséges determinisztikus lefutását csak az egyik i −n hajtjuk végre. A # jeleket a végrehajtás átugorja. A visszaállítás (sikertelen futás) után a # előtt, illetve a jobboldali után mindent felülír egy speciális ürest jelző szimbólummal, i−ket újra kettőzi
T N : n lépéses lefutásainak száma, n exponenciális függvénye. T D : Ezért az n hosszú lefutásokra exponenciálisan sok lépést fordít. A szalagon a # jelek előtt, illetve után, ugyanannyi cellát használ, mint T N .
24
11. Nyelvek (függvények) időbonyolultsága, bonyolultsági osztályok. (Determinisztikus, és nem – determinisztikus bonyolultság.)
A bonyolultságelmélet elemei: A Turing-gépek az algoritmusok bonyolultságának mérésében is jó eszköznek bizonyultak. Sokféle mérési lehetőség, mérőszám van, de a legfontosabb osztályok nem függenek a mérőszámtól. A Turing-gépek minden más gépet jól szimulálnak, hatékonyságromlás nélkül! Nézzük meg mi jellemzi egy T Turing-gép lefutását egy n hosszú w adaton. Mi jelentene költséget valós fizikai megvalósításnál? - A mozgás, a lépések száma, vagyis az idő. - A tároló mérete, a felhasznált cellák száma, vagyis a tár. Ha a lefutás „t” időt és „s” cellát használt, időköltsége t-vel, tárköltsége s-sel arányos. (Ha nem ér véget a futás, a költség végtelen). Kérdés: - a T gyors, vagy lassú megoldást jelent? - a T takarékosan használja a szalagot? A válasz nem egy w-re, hanem a w, az input hosszához viszonyítva adható meg. Egy T Turing-gépre nézve vizsgálhatjuk, hogy az input méretének függvényében van-e időkorlátja, és az milyen függvény, illetve van-e tárkorlátja, és az milyen függvény. Először a determinisztikus gépeket használjuk. Def.: A T Turing-gép időkorlátos, és időkorlátja t n , ha az „n” hosszú inputokon legfeljebb t n . A t n függvény monoton növekvő értékű függvény.
t n időt fut. Lépésszám legfeljebb
Nyelvek bonyolultsági osztályai: A TIME ( t(n) ) osztály: t n:
t : N N monoton növekvő függvény. ∗
TIME t n:={ L⊆∑ ∣ L felismerhető 0t n időkorlátos T Turing−géppel.} A O -nagy ordó- jelentése: az
f : N N függvény Ot n , ha létezik c0 konstans, vagy
f n≤c t n .
A legegyszerűbb osztály: a lineáris idő, t n=n TIME n Reguláris nyelvek (3-as nyelvosztály) ide tartoznak. Magyarázat: az L reguláris nyelvhez létezik determinisztikus (és teljes) véges állapotú automata, amely felismeri. Ez egyszeri végigolvasását igényli az inputnak. Illik tudni, hogy a rendezés, n elem rendezése nlogn időbonyolultságú. Fontos osztály a polinom időben megoldható feladatok osztálya. Ezek a „kezelhető” feladatok. Jele:P P= ∪k≥1 TIME n k . (Szokták PTIME-ként is jelölni) Ide tartoznak a környezetfüggetlen nyelvek. Kiszámítható függvények bonyolultsága A Turing-gépeket átalakítóként használva függvényekre is értelmezhető az idő- és tár-korlátosság. Megkülönböztetésként az F betűt szokták az osztály elé tenni. Például: Polinom idejű osztály FP :={ f : N N függvény∣ f −hez létezik kiszámító T Turing −gép , és T időkorlátja valamilyen k ≥1 -re.}
t n≤O n k ,
Bonyolultsági osztályok nemdeterminisztikus Turing-gépek szerint: A nemdeterminisztikus gépek szerinti osztályokat N kezdőbetűvel jelöljük. ∗
NTIME t n:={ L⊆∑
∣ létezik L−hez nemdeterminisztikus felismerő gép Ot nidőkorláttal.}
Láttuk, hogyan készíthetünk egy nemdeterminisztikus Turing-géphez ekvivalens determinisztikus gépet. Az idő a determinisztikus gépen exponenciálisan megnő. Ezért NTIME t n ≤TIME expt n
25
12. Nyelvek (függvények) tárbonyolultsága, bonyolultsági osztályok. (Determinisztikus, és nem – determinisztikus bonyolultság.) Def.: A T Turing-gép
S n tárkorlátos, ha az n hosszú inputokon legfeljebb S n cellát használ a munkaszalagon.
Mire jók ezek a tárkorlátos gépek? Feladatok bonyolultságát tudjuk jellemezni a tárkorlátos gépekkel. Legyen például L egy nyelv, és T egy felismerő Turing-gépe. Ha T t n időkorlátos, és s n tárkorlátos, akkor az L nyelv legfeljebb ilyen bonyolult. (Pontosabban fogalmazva: legfeljebb ilyen időbonyolultságú, illetve ilyen tárbonyolultságú.) Megjegyzés: 1, A két korlátfüggvény között s n≤t n nyilván teljesül, hiszen minden cella elérése legalább egy lépés. 2, A szalag-ábécé elemszáma befolyásolja t n és s n függvényeket, de csak konstans szorzó eltérést okoz. A konstans szorzóval való eltérést a bonyolultság mérésénél nem vesszük figyelembe. Gyakorlatban fontosak az alacsony bonyolultságú nyelvek, feladatok. Fontos tudni, melyek az alacsony osztályba tartozó nyelvek, melyek a gyakorlat számára kezelhetetlenül bonyolult feladatok. Hasonlóan definiálhatók a tárbonyolultság szerinti osztályok:
SPACE S n:=L ∣ Az L nyelv felismerhető O S n tárkorlátos T Turing −géppel. L=SPACE logn.
A legegyszerűbb osztály: a logaritmikus táron eldönthető nyelvek: Fontos osztály a polinom tárral felismerhető nyelvek osztálya: k
PSPACE= ∪k≥1 PSPACE n Kiszámítható függvények bonyolultsága A Turing-gépeket átalakítóként használva függvényekre is értelmezhető az idő- és tár-korlátosság. Megkülönböztetésként az F betűt szokták az osztály elé tenni. A tárbonyolultság esetén az input és az eredmény méretét sem szokták nézni, csak a munkaszalag mérete fontos.
FSPACE log n FSPACE n ∞ FSPACE= ∪ FSPACE n k . k =0
A rendezés az összehasonlítások száma alapján
FTIME n logn -ben van.
Bonyolultsági osztályok nemdeterminisztikus Turing-gépek szerint: A tár-bonyolultság: ∗
NSPACE S n :={ L⊆∑
∣ létezik L−hez nemdeterminisztikus felismerő gép O S n tárkorláttal.}
A determinisztikus gép konstrukciója csak polinom méretű tár-többletet igényel. Ezért
NPSPACE =U k ≥1 NSPACE nk =PSPALE A polinom-tár osztályok egybeesnek. Nevezetes osztályok:
NL= NSPACE logn k NP =U k ≥1 NTIME n - nemdeterminisztikus polinom-idő
Az 1-es nyelvosztály, a környezetfüggő nyelvek osztálya a binárisan korlátozott Turing-gépekkel ismerhető fel. Tehát: ∗
{ L⊆∑ ∣ L környezetfüggő }≤NSPACE n .
Fordítva is igaz,
NSPACE n=környezetfüggő nyelvek osztálya
A nyelvosztályok jellemzése: 3-as: TIME n , SPACE n konstans tár 2-es: PTIME , SPACE n 1-es: NSPACE n 0-ás: totális rekurzív függvény , parciális rekurzívan
26
felsorolható függvény.
13. Nyelvek és nemnegatív egész számokból álló halmazok megfeleltetése. Rekurzív (eldönthet halmazok), rekurzívan felsorolható halmazok. Turing-gépek, mint átalakítók. Kiszámítható függvények.
A reguláris halmazok és a reguláris nyelvek viszonya: Tétel: A reguláris nyelvek megegyeznek a reguláris halmazokkal: minden reguláris halmazhoz létezik reguláris grammatika, és minden reguláris grammatika reguláris halmazt generál. a, Reguláris halmaz, reguláris nyelv: - Az alaphalmazokhoz nyilván van reguláris nyelv. - A műveletek ,⋅,∗ nem vezetnek ki a reguláris nyelvekből. b, Reguláris grammatikához reguláris halmaz megadása Megjegyzés: a reguláris halmazokat képző műveletek monoton növekvőek, a reguláris nyelvek viszont a nem monoton komplementer képzésre is zártak. Mégis megegyezik a két nyelvcsalád. A konstrukciót az automata gráfjának bejárásán szemléltetjük. A gráf körei egy szó pumpálását jelentik, ami tranzitív lezárásként konkatenálható. Vegyük a G reguláris grammatika M automatáját. Legyen egy „v” út q 0 -ból F-be ( q 0 : kezdő állapot; F: elfogadó állapot), hagyjuk ki belőle a hurkokat, kapunk egy egyszerű, ismétlődés nélküli utat, ami elfogad egy „w” szót. A „w” szó útvonalát egyenesként rajzolva a „v” útvonala ennek pontjaiba kapcsolódó hurokutakból áll.
v 1, v 2, … , v k . A w=w1 v 1 w2 … v k w k1 alakba írható fel, ahol ∣v i∣≥1 , i=1, … , k . ∗ ∗ ∗ Az egyszerű w szóhoz, és v-hez a v 1, … , v k pumpálásával az =w1 v 1 w 2 v 2 … v k w k 1 reguláris halmazt kapjuk, ami A hurkokhoz tartozó szavak
L(G)-ben benne van. Ezt az észrevételt használjuk L(G) felépítéséhez. Lehetséges, hogy w útvonalában egy pontban több kör is kezdődik. Például a több kört fut be, és az egyes szavak a körök mentén u 1, u 2, .. , u m Akkor
v1
v ∗1 helyett az u1 u 2…u m∗ pumpálása is L(G)-ben marad.
Folytassuk a konstrukciót a v i , illetve u j típusú körökhöz tartozó szavak elemzésével, második mélység. Mindegyik felbontható egy ismétlődés nélküli körre, és azon elhelyezkedő körökre. Tehát v i , illetve u j is meghatároz egy-egy további reguláris halmazt, ami helyükre írható. Így tovább, amíg van még az i-edik mélységben olyan körút, ami nem egyszerű. Az i -edik mélységű kör kezdőpontja egy i−1 -edik mélységű egyszerű kör belső pontja, és az i−1 -edik mélységű kör kezdőpontját az i -edik mélységű kör nem tartalmazhatja. Felrajzolva a körök kezdőpontját mélység sorrendben:
Tehát a mélység nem lehet nagyobb, mint a gráf pontjainak száma. Következmény: A w ∈ LG mondatokhoz így felépíthető reguláris halmazok száma véges. Tehát minden egy ilyen reguláris halmaznak. Ezeknek a reguláris halmazoknak az uniója megegyezik L(G)-vel.
27
w ∈ LG eleme
Rekurzívan felsorolható halmazok – rekurzív halmazok Kölcsönösen egyértelmű megfeleltetéseket létesíthetünk a ∗
∑
∗
∑
, [0,1]∗ , és az N ={0,1 ,2 ,... } halmazok között.
⇔ [ 0,1]∗ ⇔ N
A megfeleltetéssel egy
∗
L⊆∑
nyelvhez
A⊆ N részhalmaz rendelhető. Az A egész számokból álló halmaz örökli L
eldönthetőségi tulajdonságait. Legyen L=LG , G tetszőleges a 0-s osztályból. Az L nyelv elemeit fel tudjuk sorolni w 1 , w 2 , w 3, ... módon: Vesszük a G-hez tartozó (valamelyik) T Turing-gépet, futtatjuk az alábbi táblázatnak megfelelően, a mellékátlón látható lépésszámokat használva: az első n input szón n lépést hajtunk végre:
Amit T felismer, ebben a sorrendben egyértelműen mindent megkapunk. Ahol T nem áll meg, a sor végtelen lesz.
Az ilyen tulajdonságú halmazokat rekurzívan felsorolható halmaznak nevezzük. Az előző gondolatmenettel könnyen belátható, hogy egy A⊆ N halmaz akkor és csak akkor rekurzívan felsorolható, ha minden x ∈ A esetén véges lépésben igazolható, hogy x az A eleme (a lépésszám függ x-től!). A 0-s nyelvosztály esetén bizonyítottuk egy nyelvről, hogy a komplementere nem rekurzívan felsorolható: Az L01 : „saját leírásukat felismerő nyelvek leírásai” nyelv rekurzívan felsorolható, de komplementere: L02 : „saját leírásukat nem felismerő nyelvek leírásai” nyelv nem ismerhető fel, nem rekurzívan felsorolható. Rekurzív nyelv (halmaz): Az L rekurzív, ha rekurzívan felsorolható és (
∗
L =∑ − L
is rekurzívan felsorolható.
A⊆ N rekurzív, ha A rekurzívan felsorolható és A=N − A is rekurzívan felsorolható.) Ekkor w ∈ L eldönthető.
Ha L rekurzívan felsorolható, de nem rekurzív, akkor w ∈ L nem dönthető el. Az L nyelvhez (A halmazhoz) tartozást eldönthetetlennek mondjuk, ha vagy L, vagy felsorolható.
L (vagy mindkettő) nem rekurzívan
Példa: sem a nyelv, sem a komplementere nem rekurzívan felsorolható:
L012 ={ T ∣ T ∈ L 01 vagy T −ben az elején álló 1−esek száma páros} L021 ={ T ∣ T ∈ L 02 vagy T −ben az elején álló 1−esek száma páratlan }
L 012= L021 Megjegyzés: A rekurzív felsorolhatóságot (ha igaz) általában nem nehéz bizonyítani. Cáfolni általában nehéz.
Turing-gép, mint átalakító: Szalag kezdő állapota: input adat Elfogadó állapotban a szalag tartalma: output adat, eredmény. Egy T Turing-gép egy ∗ ⇒ ∗ leképzést ad meg. Ha T nemdeterminisztikus, a leképzés többértékű. Ha T determinisztikus, a leképzés egy kiszámítható függvényt jelent. Ha T minden bemenetet (inputot) elfogad, totális függvényt kapunk. Egyébként parciális a függvény: ahol T nem áll meg, ott nincs meghatározva. Pl.: ha ={ 0 ,1 , bl } , akkor a 0,1∗ 0,1∗ függvényeket az egész számok bináris kódolásával megfeleltethetjük az egészeken értelmezett egész értékű függvényeknek.
28
14. Véges ÁBC feletti nyelv fogalma. Grammatika megadása. A grammatika által generált nyelv. Nyelv: Adott véges ABC (alfabéta) véges szavainak részhalmaza. A részhalmaz elemei a nyelv mondatai. A grammatika a szerkezetet, a szintaxist adja meg, nem pedig a jelentést, a szemantikát. Formális nyelvek – grammatikák: : a jelek, karakterkészletek véges halmaza. Ez a nyelv ABC-je (alfabéta).
∑ ∗ ∑: i ∑:
A
∑
-ból alkotott véges sorozatok halmaza. Számossága: megszámlálhatóan végtelen.
a pontosan i hosszú sorozatok, i= 0, 1, 2, … ∗
∑
∞ =∪
i
∑
, üres szó.
I=0 eset: az üres sorozat. Jele:
i=0
∑
feletti nyelv: L, ahol
∗
L⊆∑
;
∗
∈∑
a nyelv egy mondata, ha
∈L
Speciális nyelvek::
L0 =0 0 : üres halmaz L ={ } , az üres szóból álló nyelv
Grammatikák – nyelvtanok: A nyelv mondatainak speciális részeit különítjük el. Ezeket speciális (új, nem megadjuk az építkezés szabályait.
∑ −beli
) szimbólumokkal jelöljük, majd
Def.: A G grammatika egy négyes: G= N , , P , S , ahol N : a nyelvi szimbólumok, más néven nemtermálisok véges halmaza P : a levezetési (produkciós) szabályok véges halmaza. : a nyelv ABC-je N ∩ =0 S : a mondatszimbólum, S ∈ N
∑
∑
∑
∗
alakúak, ahol , ∈ N U ∑ , -ban van N-beli elem. lehet üres, ilyenkor jelölést használunk −szabály ∗ szabály jelentése: Legyen w ∈ N ∪∑ , egy mondatszerű forma (lehet benne nemtermális). Ha látok benne egy részt, átírhatom −ra . Megjegyzés: A P maga is tekinthető egy nyelvnek az N ∪∑ ∪{ }∪{} alfabéta felett, véges sok mondatból áll. A P A levezetési szabályok, P megadása:
végessége miatt csak megszámlálhatóan véges sok különböző grammatika van, tehát így csak megszámlálhatóan sok nyelvet tudunk megadni.
szabály jelentése:
Az
∗
∈ N ∪∑ −ra.
Legyen
,egy mondatszerű forma (lehet benne nemtermális). Ha látok benne egy
részt, átírhatom
Jelölés: A szavak egymáshoz fűzését, konkatenálását egyszerűen egymás után írással jelöljük. Egy levezetési lépés formálisan: ∗
, ∈ N ∪∑ , akkor -ra az alkalmazása: lesz. Levezetési sorozat: egy 0 mondatszerű formából kiindulva: 0 ⇒ 1 ⇒... ⇒ n , ahol minden ⇒ egy P-beli szabály alkalmazása. ∗ Röviden: 0 ⇒G n : 0 -ból a G grammatika szerint a n végesen levezethető. Def.:
A G grammatikához tartozó (G által generált) nyelv: ∗
L G ={ ∈ ∑ ∣S ⇒∗G } , vagyis az S mondatszimbólumból végesen levezethető mondatok halmaza. Ha az N halmazt 1:1 leképezéssel egy N' halmazra képezzük, és G-t átírjuk G' grammatikává, ugyanazt a nyelvet kapjuk felett.
L G = LG ' . 29
∑
Nyelvosztályok: a szabályok alakjára vonatkozó megszorítások. Egyszerűtől a bonyolult felé haladunk, megadjuk a nyelveket felismerő gépet is. Felismerési feladat: w ∈ LG felismerése (tartalmazási kérdés) - Ha w ∈ LG igaz, akkor létezik hozzá véges levezetés S-ből. Generáljuk a levezetéseket: az összes 1 hosszút, majd 2 hosszút, stb. Előbb-utóbb megkapjuk w levezetését. - Ha w ∈ LG hamis, ezt nem midig tudjuk véges lépésben bizonyítani. Általánosan ez nem dönthető el. Speciális nyelvosztályokra eldönthető. Jelölési konvenció: elemei a terminális szimbólumok. Elnevezés oka: ha csak ilyen van egy szóban, akkor nem lehet rá szabályt alkalmazni. Jelölésük: a,b,c, - a Latin abc eleje, kis betűk. N elemei a nemtermálisok, jelei: A,B,C – nagybetűk Határozatlan szimbólum (változó): X,Y,Z – abc vége, nagy betűk Terminálisokból álló sorozat / szó: x,y,z – abc vége, kis betűk Tetszőleges sorozat: , , - görög kis betűk
∑
30
15. Veremautomaták. Veremautomaták és környezetfüggetlen grammatikák megfeleltetése. Veremautomata konstrukciója grammatikához.
Veremautomaták: Próbáljunk gépet konstruálni egy (felesleges szimbólumokat nem tartalmazó) w G nyelvtanhoz, ami végre. Példa: az aa∗a elfogadása. Szabályok: E ET ∣T ; T T⋅F∣ F ; F E∣a Levezetési fa:
w ∈ LG elfogadását hajtja
A legbaloldalibb levezetést keressük: (amit vizsgálunk áthúzzuk, helyére írunk egy szabályát, illetve elhagyjuk, ha terminális)
Mit vizsgálunk?
Lépés
E
1, kezdés: a gyökér E, E-szabályt keresünk, E ET -t vesszük. E helyére írjuk
E+T
2. lépés: Baloldalon E áll (a feljegyzés elején) E T -t vegyük.
T+T
3. lépés: T F -et vegyük
F+T a+ T
4. lépés: F a a+ elfogadása
T*F
5. lépés: T T ∗F szabály
F*F
6. lépés: T F szabály
a* F
7. lépés: F a szabály a* elfogadása
a
8. lépés: F a szabály a elfogadása
A □ (az ábrában a szürke hátterű) terminálisokat fogadtuk el: aa∗a A feljegyzések veremként viselkednek: az elején (tetején) álló jel helyére írunk, ha nemtermális; egyeztetjük a levezetendővel, ha termális.
31
A veremautomata felépítése: Működési séma:
Verem: a teteje olvasható, törölhető, írható. LIFO stack: push down stack
Formális megadás: PM (Push Down Machine) – el jelöljük. 7 összetevője van.
PM Q , ∑ , , , q 0 , z 0 , F
-
Q : állapotok véges halmaza
∑
:input szalag abc-je, véges halmaz
:a verem abc-je, véges halmaz :mozgási szabályok vége halmaza q0: q 0 ∈Q a kezdő állapot - z0 : z 0 ∈ , a verem alján álló szimbólum, más helyen nem állhat, nem törölhető. Ha csak ez áll a veremben, a verem -
-
F:
üres.
F ⊆Q -nak, az elfogadó állapotok halmaza
Működése: A kezdő állapotból és az üres veremből kiindulva olvassa a szalagot. Ha van olyan mozgássorozat, hogy mindent elolvasott, és a, F-beli állapotba jut: végállapotot elfogad. b, a verem aljára ér: üres veremmel elfogad. A mozgások megadása: A leképezés nem egyértelmű, nemdeterminisztikus. k
: Q× ∑ ∪{ } × ⇒Q× ∪{ } - Q : állapot, - ∑ ∪ {} : input betű. nem olvas. - : verem tetején álló jel - ∪ {}k : a leemelt jel helyére irt szó, a verem tetejére írja. Lehet üres is. Hossza legfeljebb k. Egy konkrét mozgást q , a , A= p , ad meg. A q állapotban az „a” input és a verem tetején „A” hatására átmegy p állapotba, „A” helyére -t ír, és az input következő cellájára lép, kivéve, ha a= . Ha a= , akkor inputot nem olvas, nem lép a szalagon. Ezek az -szabályok. Amit szerkesztettünk az aa∗a legbaloldalibb levezetéséhez speciális változat volt. A mozgásoknak három fő típusa van, példákkal illusztrálva: 1, q , a , A= p , BC – olvas inputot, ír a verem tetejére 2, q , , A=q , CB – nem olvas inputról, ír a verem tetejére, -szabály. 3, q , a , A=r , – törli a verem tetejét, ez jelenti a veremben az „A” feldolgozását. Ilyen lépésekkel ürítődik ki a verem. Az ábrában a verem alját jobboldalon ábrázoljuk, és balra nő a verem vízszintesen. Ez felel meg leginkább a legbaloldalibb levezetéseknek. Hasonlítsuk össze a veremautomatákat a véges állapotú automatákkal: A véges állapotú automata következő lépéssorozatát, amit az input hatására végre fog hajtani, (illetve végre hajthat) csak az aktuális állapota, és az átmenetek határozzák meg. A fizikai megvalósítás konstans méretű gépet igényel. A veremautomata esetében az állapoton túl a teljes veremmemória tartalmára is szükség van. Tulajdonképpen a teljes belső állapothoz a verem tartalma is hozzátartozik. A fizikai implementálásnál nem elég a konstans méret, a memória tetszőleges nagy lehet az input méretének függvényében.
32
Példa 3 lépés egymás utáni végrehajtására:
q , a , A= P , BC P , , B=r , CB r , b , C=q ,
1, 2, 3,
A belső állapotátmenetek gráfját itt is használhatjuk, két jel címkézi az éleket: olvasott input, verem teteje. Az állapotátmenetekhez a verembe írás tartozik még. Tétel: Minden
G= ∑ , N , S , P környezetfüggetlen grammatikához létezik üres veremmel elfogadó veremautomata: PM Q , ∑ , , , q 0 , z 0 (végállapotra nincs szükség)
Q : egyetlen állapot elég, -ban ezért az állapot komponenst elhagyjuk. ∑ : ugyanaz, mint G-ben - : ∑ ∪ N ∪z 0 -
Bizonyítás: Ötlet: - az automata a verem tetejére egy szabály jobboldalát írja a verem tetején álló nemterminális helyettesítéseként. - ha a verem tetején terminális áll, annak meg kell egyeznie az input betűvel.
Megadása: 1, , z 0 =S 2, a , a= 3, , A=w , ha A w∈ P Az 1, mozgás: a mondatszimbólum kerül a verembe. A 2, mozgás: Ha a verem tetején terminális áll, csak akkor van mozgás, ha megegyezik az input soron következő jelével. Ilyenkor a verem teteje törlődik, feldolgozódik. A 3, mozgás: Ha a verem tetején nemterminális áll, nem történik input olvasás, és a nemterminális helyére egy szabályának jobboldala íródik.
33
Ha
w ∈ LG , vegyünk w levezetési fáját. Ezen a legbaloldalibb levezetésnek megfeleltethető a veremautomata mozgássorozata. Az input elfogadása balról jobbra a levelek bejárását jelenti.
Fordítva: Ha a veremautomata w-t felismeri, lépéssorozatából w G-szerinti levezetési fáját építhetjük fel. Tehát L G = L PM . Tétel: Minden üres veremmel elfogadó automatához létezik ekvivalens végállapottal elfogadó és viszont. Kérdés: Az általános üres veremmel elfogadó veremautomaták milyen nyelvosztályt határoznak meg? Tudnak-e többet az egyállapotos veremautomatáknál? Válasz a következő tétel. Tétel: Minden üres veremmel elfogadó veremautomatához létezik vele ekvivalens környezetfüggetlen nyelvtan. Bizonyítás: A PM Q , , , , q 0 , z 0 -hoz konstruáljunk ekvivalens G , N , S , P grammatikát. A konstrukció szemléltetése: az automata működéséhez legbaloldalibb levezetőfát építünk, ebből kapjuk a grammatikát. Verem adja: jobb szélen, balra töltjük. Kiindulás: ha a verem tetején „Z” szimbólum áll, és q állapotban van, akkor valamilyen „p” állapotban lesz majd a „Z” töltésekor, más szóval „Z” feldolgozása után. Azt mondjuk: Z-t feldolgozta, és a q állapotból p állapotba jutott. Ahhoz, hogy ez megtörténjen, a q állapotban Z helyére Z 1 Z 2 … Z n szót írta, majd feldolgozza Z 1 -et P 1−ből P 2 −be jutva, stb, végül Z n -et dolgozza fel, P n−ből P−be jutva. A feldolgozást a Z , q , p hármasok jellemzik. Rajzoljuk fába a lépéseket:
∑
∑
Olyan, mint egy levezetési fa, csak a
∑
Legyenek ennek alapján a nemterminálisok: A levezetési szabályok: három típusú
értékű levelek hiányoznak. Ezek a pontok a nemterminálisok szerepét játsszák.
N ={ S }∪{ N Z , q , p ∣ z ∈ , p ∈Q , q∈Q } (Véges N)
a)
S N Z , q0 , p
b)
N Z , q , p a N Z 1 , p1 , p2 N Z 2 , p2 , p3 ... N Z n , pn , p
0
, minden
P ∈Q -ra
a ∈ ∑ ∪{ } - −szabály is lehet, nem olvas a szalagról - és P i -k tetszőleges állapotok, és a legfontosabb: p1, z 1 z 2 … z n ∈ q , a , z . (Ez felel meg az előző oldalon szereplő előkészítő szemléltetésnek. Fontos, hogy a verem bal felé töltődik, z i kerül előre. Ha a ≠ , akkor az „a” input betű elfogadásra kerül, és a levezetési fán N Z , q , p alatt a legbaloldalibb , ahol
levél lesz)
c)
N Z , q , p a , minden p , q ∈Q , a ∈ ∑ ∪{} -ra, ha P , ∈ q , a , z . Ez felel meg a verem tetején álló Z közvetlen, egy lépéses feldolgozásának. - Ha a ≠ , akkor a levezetési fában „a” értékű levél keletkezik.
- Ha a= , akkor lépéssel történik Z törlése. Ez okoz némi problémát: N Z , q , p szabályt eredményez. Ez a grammatikából is kiküszöbölhető, valamint a veremautomata is helyettesíthető ilyen átmenetet nem tartalmazó automatával. Ezt az esetet kizárhatjuk. Állítás: Az így kapott G -re L G = L PM . Bizonyítása a levezetési fa konstrukciójára alapul. G -hez és PM -hez ugyanazt a levezetési fát rendeljük. Ami az egyikben levezetés, a másikban is az lesz.
34
Klasszikus algoritmusok
35
16. Alapvető programozási tételek (N-1) (összegzés, számlálás, maximumkeresés, lineáris keresés, logaritmikus keresés)
Összegzés: Adott: n elemű tömb, valós értékekkel Feladat: Vegyük sorra a tömb elemeit, és összegezzük azokat! Megvalósítás: Ciklusunkkal végig megyünk a tömb elemein, és egy harmadik változóba összegezzük azokat. Index := 0; for index=1 to n do begin tombosszeg := tombosszeg + tomb[index]; end;
Számlálás: Adott: n elemű tömb, valós értékekkel Feladat: Vegyük sorra a tömb elemeit, majd nézzünk meg egy meghatározott elemet, hogy hányszor szerepel benne! Megvalósítás: Ciklusunkkal végigmegyünk a tömb elemein, és egyenként megvizsgálva az elemeket, eldöntjük, hogy az éppen aktuális elem-e a keresett elem. Ha igen, akkor feljegyezzük, ha nem, akkor shiftelünk. Index := 0; keresendo := 5; szamlalo = 0; for index=1 to n do begin if keresendo = tomb[index] then inc(szamlalo); end;
Minimum, maximumkeresés: Adott: n elemű tömb, valós értékekkel Feladat: Vegyük sorra a tömb elemeit, és keressük meg benne a legnagyobb elemet! Megvalósítás: Ciklusunkkal végigmegyünk a tömb elemein, és egyenként megvizsgálva az elemeket, eldöntjük, hogy az éppen aktuális elem nagyobb-e mint a maximális elem. Ha igen, akkor feljegyezzük, ha nem, akkor shiftelünk. var k,i,max : integer; k := 1; max := tomb[1]; while (k <> n) do begin if (tomb[k] >= max) then begin max := tomb[k]; end; inc(k); end;
36
Minimumkeresés: Adott: n elemű tömb, valós értékekkel Feladat: Vegyük sorra a tömb elemeit, és keressük meg benne a legkisebb elemet! Megvalósítás: Ciklusunkkal végigmegyünk a tömb elemein, és egyenként megvizsgálva az elemeket, eldöntjük, hogy az éppen aktuális elem nagyobb-e mint a minimális elem. Ha igen, akkor feljegyezzük, ha nem, akkor shiftelünk. var k,i,min : integer; k := 1; max := tomb[1]; while (k <> n) do begin if (tomb[k] <= min) then min := tomb[k]; inc(k); end; Lineáris keresés: Adott: n elemű tömb, érték Feladat: Szerepel-e egy adott érték az elemek között, és ha igen, határozzuk meg az indexét! Megvalósítás: Lineáris keresés, a T tulajdonság: az adott értékkel megegyező-e index:=0; REPEAT index:=index+1; UNTIL (index > n) OR (
); van:= index <= n; Logaritmikus keresés: Adott: n elemű rendezett tömb, érték Feladat: Szerepel-e egy adott érték az elemek között, és ha igen, határozzuk meg az indexét! Megvalósítás: Mivel az adatok rendezettek, először a középső elemet vizsgáljuk meg. Ha ez az adott értéknél nagyobb, az elemet elég a középső elem előtt keresni, ha kisebb, elég utána. Ugyanezen elv szerint folytatva a keresést egyre kisebb intervallumokkal kell dolgoznunk. Az eljárás akkor ér véget, ha az adott értékkel megegyező elemet találunk, vagy ha az intervallum kezdete túllép az intervallum végén. CONST n=100; VAR a: ARRAY [1..n] OF REAL; ertek: REAL; kezdet, veg, aktualis: INTEGER; van: BOOLEAN; kezdet:=1; veg:=n; REPEAT aktualis:= (kezdet+veg) DIV 2; IF a[aktualis] > ertek THEN veg:=aktualis-1; IF a[aktualis] < ertek THEN kezdet:=aktualis+1; UNTIL (kezdet > veg) OR (a[aktualis] = ertek); van:= kezdet <= veg; A két algoritmus összehasonlítása: Lineáris keresés: Egy elem megtalálható átlagosan n/2 lépés után. Logaritmikus keresés: Az intervallum hossza: 1. lépés után: n/2 2. lépés után: n/4 k. lépés után: n/2k Az elemet legkésőbb a k. lépésben megtaláljuk, ha az intervallum hossza 1, azaz 1 » n/2k k » log2n Az eredményből látható, hogy a logaritmikus keresés általában gyorsabb. 37
17. Alapvető programozási tételek (N-N) (szétválogatás, halmazműveletek), Programozási tételek összeépítése. Szétválogatás (egy tömbbe): Memóriafoglalás szempontjából a két tömböt használó előző algoritmus nem hatékony: mind a p, mind az np tömböt n elemre kell deklarálni, de a két tömbben összesen csak n elem van. Használhatunk egy tömböt is, akkor annak első felébe tesszük a pozitív számokat, a második felébe (hátulról kezdve a feltöltést) a többit. Ez az algoritmus egy t tömb (indexek 0-tól n-1-ig) pozitív elemeit teszi egy p tömb elejére, a negatív elemeket p tömb végére. i := 0; pdb := 0; veg := n-1; while (i < n ) do begin if (t[i] > 0 ) then begin p[pdb] := t[i]; inc(pdb); end; else begin p[veg] := t[i]; dec(veg); end; inc(i); end; Szétválogatás (két tömbbe): A feladat hasonló az előzőhöz, de a feltételnek nem megfelelő elemeket is egy újabb tömbbe kell elhelyezni (tehát kétfelé válogatjuk az eredeti tömböt). Ez az algoritmus egy t tömb (indexek 0-tól n-1-ig) pozitív elemeit teszi egy p tömbbe, a nem-pozitív elemeket a np tömbbe. pdb illetve npdb változó számolja, hogy az illet tömbbe hány elem került. const n = 10 – 1; var i, pdb, npdb : integer; t,p, np : array[0..n] of integer; begin i := 0; pdb := 0; npdb := 0; while (i < n ) do begin if (t[i] > 0 ) then begin p[pdb] := t[i] ; inc(pdb); end; else begin np[npdb] := t[i]; inc(npdb); end; inc(i); end; Halmazműveletek: Metszet: A feladat most két tömb a[0..n-1] és b[0..m-1] azonos elemeinek kiválogatása c tömbbe. A feladat csak úgy értelmezhető pontosan, ha az egyes tömbökben egy elem nem szerepel kétszer. (Mivel most a matematikai halmazokat tömbként ábrázoljuk.) Az algoritmus lényege: menjünk végig az a tömb elemein, és válogassuk ki azokat (kiválogatás), melyek szerepelnek b-ben (eldöntés). Így a feladat a korábbi tételekre visszavezethető. c maximális elemszáma n és m közül a kisebbik. Feltételeztük, hogy egyik halmaz sem
38
for i:=0 to n-1 do begin j := 0; while ((j < m) and (b[j] <> a[i]) ) do begin if (j<m) then begin c[k] := a[i]; inc(k); end; inc(j); end; end; for i := 0 to k-1 do WriteLn(c[i]); Unió: A feladat most két tömb a[0..n-1] és b [0..m-1] elemeinek egyesítése c tömbbe. Az egyes tömbökben egy elem nem szerepel kétszer. (mint az előbb) A legkézenfekvőbb megoldás: tegyük be c-be a összes elemét, majd b-ből azokat, melyek nem szerepelnek a-ban. c elemszáma legfeljebb n+m. Feltételeztük, hogy egyik halmaz sem üres. for i := 0 to n-1 do c[i] := a[i]; //a-t áttöltjük c-be k := n; for j := 0 to m-1 do begin i:=0; // keressük azt a b-belit, ami nincs a-ban while ( (i a[i]) ) do inc(i); if (i >= n) then begin c[k] := b[j]; inc(k); end; // ha volt ilyen, c-be tesszük end; for i := 0 to k-1 do WriteLn(c[i]); // unió kiíratása Unió speciális esetben (Delphi): az a és b (halmazokat reprezentáló) tömbök rendezettek (összefuttatás) i := 0; j := 0; k := 0; while(( i < n) and ( j < m)) do if (a[i]
18. Dinamikus programozás (mátrixok láncszorzása) Mátrixszorzás Feladat: adott a mátrixoknak egy A1, ... , An sorozata, ahol az zárójelezést, ahol a skalár szorzások száma minimális.
Ai mátrix mérete p i−1 xpi. . Keressük azt a
Egy pxq és egy qxr dimenziós mátrix összeszorzásának a költsége p*q*r. Jelölje m[i,j] az Ai ×…× A j optimális költségét. Ekkor m[i,j] = • •
0, ha i==j min {m[i,k]+m[k+1,j]+pi-1*pk*pj}, i<=k<j, ha i<j
A rekurzív implementálás exponenciális futási idejű lenne. Ehelyett dinamikus: O(n3), és csak W(n2) memóriára van szükségünk. p=(p0,p1,...,pn) MÁRTIX-SZORZÁS-SORREND(p) n=hossz[p]-1 for i=1 to n do m[i,j]=0 for l=2 to n do for i=1 to n-l+1 do j=i+l-1 m[i,j]=oo for k=i to j-0 do q=m[i,k]+m[k+1,j]+p[i-1]*p[k]*p[j] if q<m[i,j] then m[i,j]=q s[i,j]=k return m és s MÁTRIX-LÁNC-SZOROZ(A,s,i,j) if j>i then X=MÁTRIX-LÁNC-SZOROZ(A,s,i,s[i,j]) Y=MÁTRIX-LÁNC-SZOROZ(A,s,s[i,j]+1,j) return MÁTRIXSZORZÁS(X,Y) else return A[i] Feljegyzéses módszer: van egy nxn-es táblázatunk, kezdetben üres. Rekurzívan számolunk. Ha valamit kiszámoltunk, akkor azt feljegyezzük, és ha legközelebb előfordul, akkor már elég csak kiolvasni. A rekurzió futási ideje ebben az esetben O(n3).
40
19. n*n-es rendezések (alapelvek, algoritmusok)
41
20. Haladó rendezések I. ( Kupacrendezés, Shell rendezés)
Kupacrendezés: Definíciók, jelölések: • Bináris fa: olyan fa, amelyben minden pontnak van egy szülője (kivéve a gyökeret) és legfeljebb két fia. • Pont magassága: a leghosszabb, levélig vezető úton levő élek száma. • Fa magassága = gyökér magassága. • Kupac: egy olyan majdnem teljes bináris fa, amelyben minden elemre teljesül a követkrző: A[SZÜLŐ[i]] >= A[i]. • Egy tömb és egy kupac közötti kapcsolat: i - tömbindex SZÜLŐ(i) = alsó egész rész(i/2) BAL(i) = 2*i JOBB(i) = 2*i+1 Minden (n hosszú, A) tömbre teljesül az, hogy A[n div 2 + 1, ..., n] kupac. Kérdések: • Ha egy kupac magassága h, legalább ill. legfeljebb hány elemet tartalmaz? Válasz: 2h ill. 2h+1-1 • n elemű kupacnak mekkora a magassága? Válasz: lg(n) alsó egész része. • Egy adott részfában hol helyezkedik el a legnagyobb ill. legkisebb elem? Válasz: a gyökerében, ill. valamelyik levélen. • Kupac-e? 23,17,14,6,13,10,1,5,7,12 Válasz: nem, mert a 9. elem nagyobb, mint a 4. •
KUPACRENDEZÉS(A) KUPACOT-ÉPÍT(A) for i = hossz[A] downto 2 do A[1]<->A[i] kupacméret[A]-SÜLLYESZT(A,1) KUPACOT-ÉPÍT(A) kupacméret[A] = hossz[A] for i = hossz[A]/2 downto 1 do SÜLLYESZT(A,i) SÜLLYESZT(A,i) l = BAL(i) r = JOBB(i) if l<=kupacméret[A] és A[l]>A[i] legnagyobb=l else legnagyobb=i if r<=kupacméret[A] és A[r]>legnagyobb legnagyobb = r if legnagyobb!=i A[i]<->A[legnagyobb] SÜLLYESZT(A,legnagyobb)
42
Shell rendezés: Nem önálló módszer, hanem több, már megismert módszerhez illeszthető. Elve: sokat javíthat a rendezésen, ha először az egymástól nagy távolságra lévő elemeket hasonlítjuk, cseréljük, mert így az egyes elemek gyorsabban közel kerülhetnek a végleges helyükhöz. Így az eredeti módszer hatékonyabbá válhat. Különösen igaz ez a beszúró rendezésnél. Az elemek közötti távolságot jelöljük D-vel. Első értéke: N/3+1, majd D:=D/3+1. Pl. 10 elemű sorozatnál az alábbi részsorozatokat rendezzük: D=4 1,5,9 2,6,10 3,7 4,8 D=2 1,3,5,7,9 2,4,6,8,10 D=1 1,2,3,4,5,6,7,8,9,10 Úgy tűnhet, mintha D=1 esetén lezajlana az egész beszúró rendezés, ekkor azonban már a korábbi menetek miatt minimális számú összehasonlítás és mozgatás történik. algoritmus ShellBeszúrórendezés változó I, J, D, E: egész változó X: Elemtípus D:=N ismétel D:=D/3+1 ciklus E:=1..D ismétel I:=E+D amíg I<=N ismétel J:=I-D; X:=A[I] amíg (J>=1) és (X
43
21. Haladó rendezések II. (Szétosztó-, Leszámláló-, Radix-, Edényrendezés)
Leszámoló rendezések:
RADIX rendezések: Ha az edényrendezéseket olyan számokra fogalmazzuk meg, amelyek - r alapú számrendszerben vannak felírva és - d számú számjegyet tartalmazzanak, akkor az úgynevezett RADIX rendezéseket kapjuk. Utórendezéses edényrendezés, RADIX „előre”: rad Az általános utórendezéses változat olyan, mint a bevezető példánk első megoldása. Ha speciálisan r alapú számokra írjuk fel, akkor rad eljárást kapjuk. e=e d e d −1 … e 1
Hány edény kell? A rekurzióban lokális változók újabb és újabb példányai foglalódnak le; max. r r 2…r d edény jön létre. Valójában gyakran jóval kevesebb elég, hiszen sok olyan edény lehet, amely üres lenne.
44
Speciálisan d hosszú bináris számokra (r = 2) egyetlen tömbben megoldható a rendezés. Ekkor minden szinten két edény kell: E 0 és E 1 . Egy edény egy tömbrészlet. Ezt további két edényre osztjuk úgy, hogy két mutatóval megyünk szembe és cseréljük a számokat, ha kell, egészen addig, amíg a két mutató át nem lépi egymást.
A rad eljárás lineáris: d ∗∣S∣∣S∣ műveletet (mozgatást) igényel: +szétrakások, összefűzések. Bináris esetben legfeljebb d ∗∣S∣=d ∗n elem mozgatást végzünk. rad Az általános előrendezéses változat úgy működik, mint a bevezető példa második megoldása. Ha speciálisan d hosszú r alapú számokra írjuk fel, akkor a eljárást kapjuk. Az eljárás az e=e d e d −1 … e 1 számot rad jobbról balra indulva, az alacsony helyi értékek felől indulva pozíciónként szétrakja edényekbe, majd összefűzi az edények tartalmát. Az i-edik pozíción a i hasító függvényt alkalmazzuk: i e=ei .
Előrendezéses edényrendezés, RADIX „visszafelé”:
Az 1, 2, ..., i-edik pozíciókon végrehajtott szétrakás és összefűzés után S „i-rendezett” lesz. Ezt úgy definiáljuk, hogy ha x= x d x d −1 … x 2 x 1 és y= y d y d −1 … y 2 y 1 és ≤i jelöli az i-rendezettségét , akkor x0 y minden x,y-ra x≤i y ⇔ x i y i vagy x i= y i és x≤i −1 y (i>0). Ekkor a d-rendezés a közönséges rendezés. Hatékonyság: 2*d-szer megyünk végig az S sorozaton, így T n=Od ∗∣S∣ . Memóriaigény: az eredeti sorozat és r számú edény: r 1∗∣S∣. 45
Szokásos implementáció: (alábbi ábra) S fejelemes láncolt lista. Az edényeket egy „fej” és egy „vége”mutató ábrázolja. A szétrakás és az összefűzés az elemek láncolásával megoldható. Az összefűzéskor nem kell az egyes edények részlistáit végigolvasni, hanem egy darabban lehet őket láncolni. A memóriaigény is kisebb: ∣S∣ elem + 1 fejelem (+ pointer) + ∣S∣ pointer + r db (fejelem + végepointer) (+ pointer). A listás implementáció:
Speciálisan d hosszú bináris számokra (r = 2) egyetlen tömbben megoldható a rendezés. A számokat tartalmazó tömb kezdetben A, a másik B tömbben lesz a két edény, mégpedig szembe fordítva. Azután B-ből pakolunk A-ba, és így tovább... váltakozva:
Végül a két szembefordított edényt A-ba pakoljuk folyamatosan.
46
Edényrendezés: Eddig az összehasonlításos rendezésekről volt szó. Az edényrendezés abban különbözik az előbbiektől, hogy nem hasonlítjuk össze a rendezendő elemeket, hanem a rendezés során az egyes elemeket az értéküknek megfelelő „edények”-be rakjuk szét. Induljunk ki egy példából. Egy évfolyam hallgatói felírják egy-egy kis lapra a születési dátumaikat, pl. így: 1980.30.12. Szeretnénk sorba rendezni ezeket az adatokat. Ezek speciális adatok: mindhárom mező csak adott tartományból vehet értékeket: - az évek mondjuk 1980 és 1976 között helyezkednek el, - 12 hónap van és - 31 nap jöhet szóba. Edényrendezés előre: 1, Rakjuk szét a születési dátumokat az évek edényeibe. 2, Rakjuk tovább a dátumokat a megfelelő hónapok edényeibe. 3, Rakjuk végül a dátumokat a napoknak megfelelő edénybe. 4, Vegyük ki a születési dátumokat sorban az edényekből és alakítsunk belőlük sorozatot. Edény-hierarchia: 5 év, 5*12=60 hónap, kb. 60*30=1800 nap A sorozat rendezett lesz, mert az edényeket a rendezettségüknek megfelelő sorrendben érintjük, továbbá minden edényben egyféle születési dátum lehet (0,1 vagy több példányban). Az eljárás hatékony (lineáris), mert 4-szer mentünk végig az adatok sorozatán, azonban sok edényt (memóriát) igényel. Ez még dinamikus helyfoglalás után is igaz: az edények száma ≈ arányos az adatok számával, amíg el nem éri a maximális edényszámot. Edényrendezés visszafelé: Rendezhető a sorozat úgy is, hogy az egyes mezők szerint hátulról előre haladva alkalmazzuk az edényekbe való szétrakást és az összefűzés műveleteit. 1, a) Rakjuk szét a születési dátumokat a napok edényeibe úgy, hogy az eredeti beérkezési sorrendet megtartjuk az edényben. b) Fűzzük össze az 1., 2., ... 31. nap edényeiben lévő sorozatokat egyetlen sorozattá. 2, a) Rakjuk szét a sorozatot a hónapok edényeibe, 12 részsorozat formájában. b) konkatenáljuk ismét az edényekben található sorozatokat egyetlen sorozattá. 3, a) Végül az évek edényeibe fűzzük szét a sorozatot. b) Fűzzük össze az évek edényeinek tartalmát egyetlen sorozattá. Gondoljuk meg, hogy így éppen a kívánt rendezés alakul ki a sorozatban.
47
22. Haladó rendezések III. (quicksort, rekurzív és nemrekurzív módon) A rendezés lényege, hogy a tömböt az elemek cserélgetéseivel két olyan részere osztjuk fel, ahol a baloldali rész egy konkrét értéknél csupa kisebb, míg a jobboldali rész csupa nagyobb elemet tartalmaz. Ha ezt meg tudjuk oldani, akkor ugyanezt a módszert a baloldali, majd a jobboldali részre alkalmazzuk. Az így keletkezett résztömböket ismételten szétosztva végül 1 elemű résztömbök keletkeznek, és így a teljes tömb rendezett lesz. Gyorsrendezés rekurzívan: Találjunk ki egy elválasztó elemet. Ez célszerűen lehet a tömb középső indexű eleme. Legyen I egy alulról növekvő index, j pedig egy felülről lefelé csökkenő index. I-vel addig megyünk felfelé, míg az elemek mind kisebbek az elválasztó értéknél. J-vel lefelé azon az elemen állunk meg, amely kisebb, mint az elválasztóelem. Ekkor az elemeket felcseréljük seged :=a [i] ; a [i ]:=a [ j ] ; a[ j]:=seged ; , így azok már a jó “térfélre” kerülnek. Ezután folytatjuk a vizsgálatot (i-vel felfelé megyünk, j-vel lefelé). Az elválasztó elemhez érve elérjük, hogy az elválasztó elem bal oldalán csak az elválasztó elemtől kisebb, jobb oldalán csak nagyobb értékek szerepelnek. Ekkor a rendezési algoritmust elvégezzük hasonlóan a tömb bal és jobb oldalára külön-külön (kijelölünk mindkét félbe egy-egy elválasztó elemet, és utána cserélgetünk). A részre bontás végére 1 elemű tömböket kapunk, ezzel elérve, hogy a teljes tömb rendezett legyen.
Gyorsrendezés rekurzió nélkül: Bemenetkor: K 1, … , K n különböző számok. Kimenet: K 1, … , K n : ugyanezek a számok jó sorrendben. Segédváltozók: T 2, … ,T n : 0 vagy 1 értékeket vehetnek fel. l , m : egész számok 1 és n között. K : a K 1, … , K n számok valamelyike. Megjegyzés: Az eljárás folyamán T i=1 , ha a K i szám már nagyság szerint is az i-edik.
48
Ennek az algoritmusnak sok előnye van, pl.: hogy az egész 1. fázisban ugyanazt a K i számot kellett a többivel összehasonlítani. Ezért érdemes kiszámítani, hogy az algoritmus átlagban hány összehasonlítást igényel? Tegyük fel, hogy a K 1, K 2, … , K n számok minden lehetséges nagysági sorrendje egyformán valószínű. Az első fázisban K 1 -et az összes többi számmal össze kell hasonlítani, ez n-1 összehasonlítás. Könnyű belátni, hogy ha pl.: az első fázis után az eredmény L1 , L2 , … , Li−1 , K 1 , M 1 ,… , M n−i , akkor az L1 ,… , Li−1 számok minden lehetséges nagysági sorrendje is egyformán valószínű (az M 1 , … , M n −i számoké hasonlóan). Jelöljük az „n” szám sorba rendezéséhez szükséges összehasonlítások átlagos számát F(n)-nel! Ekkor, feltéve, hogy K 1 az i-edik helyre került, hátravan még átlagban F i−1F n−i összehasonlítás. Mivel pedig K 1 egyenlő valószínűséggel kerülhet bármelyik helyre, az összehasonlítások átlagos számára végül a következő rekurzív formulát kapjuk: F 0=0, F 1=0, 1 F n=n−1 [F 0F n−1F 1F n−2F 2F n−3 ... F n−1F 0] n Egyszerűsítve: nF n=n n−12[ F 0F 1F 2 ... F n−1]
1
Írjuk fel ugyanezt az egyenlőséget n+1-re: n1 F n1=n1n2 [F 0 ... F n]
2
Vonjuk ki (1)-ből a (2)-t: n1 F n1−nF n=2n2Fn Átalakítva: n1 F n1=2n n2 F n
F n1 F n 2n – = n2 n1 n1n2
Adjuk össze a fenti egyenlőséget n=1, 2,… , k −1 -re:
F k 2⋅1 2⋅2 2⋅3 2 k −1 = … k 1 2⋅3 3⋅4 4⋅5 k k 1
Az olvasó egy kis fejszámolással ellenőrizheti, hogy innen F n=2n1 H n – 2
? ?? n1
, ahol
1 1 1 H n=1 … ≈ln n . Ezért a következő aszimptotikus egyenlőséget kaptuk az átlagos 2 3 n lépésszámra: F n≈2n ln n Érdekes megjegyezni, hogy a szóban forgó algoritmus a legrosszabb esetben az összes számpárt n n−1 összehasonlítja, tehát lépést dolgozik. Paradox módon ilyen legrosszabb eset az, ha a 2 K 1, K 2, … , K n számok eleve jó sorrendben vannak, azaz K 1 K 2 …K n
49
23. Ritka mátrixokkal kapcsolatos algoritmusok.
Ritka mátrixok A kétdimenziós mátrixot általában m⋅n alakban adjuk meg, ahol az m a sorok, míg n az oszlopok számát adja meg. Az ilyen mátrixnak m⋅n eleme van. A mátrix elemeit leggyakrabban egy kétdimenziós tömb, azaz táblázat formájában adjuk meg. Pontos definíció nem létezik a ritka mátrix meghatározására. Azokat a mátrixokat, amelyek sok zérus elemet tartalmaznak ritka mátrixoknak nevezzük. Egy ilyen mátrix hely- és tártakarékosság érdekében különleges ábrázolási módot igényel, mely kizárólag a nem zérus elemek és azok pozíciójának tárolására szorítkozik. Létrehozunk egy olyan kétdimenziós tömböt, ahol a sorok száma a nulladik kivételével megegyezik az összes nem zérus elemek számával, míg az oszlopok száma 3. Általános alak: (i, j, érték). A nulladik sor 1. oszlopában az eredeti mátrix összes sorainak száma, második oszlopában az összes oszlopainak száma található. A harmadik oszlopban a nem zérus elemek száma olvasható. Általában egy adott sor első és második oszlopában a harmadik oszlopban feltüntetett nem zérus szám eredeti mátrixban elfoglalt sor és oszlop pozíciója található. Egy lehetséges mátrixművelet a transzponálás, amikor az adott sorban és oszlopban elhelyezkedő elemeket adott oszlopszám szerinti sorba és adott sorszám szerinti oszlopba másoljuk át. (nt)-nagyságrendű transzponálás:
Ahol m a mátrix sorainak, n oszlopainak száma, t a elemeinek száma, q a következő terminus pozíciója bben, p az aktuális terminus a-ban. A ciklus futások száma nt nagyságrendű.
(n+t)-nagyságrendű transzponálás
50
24. Strassen mátrixszorzási algoritmus. Legyen A, B két négyzetes mátrix a valós számok halmazán. Ki akarjuk számítani a C mátrixot. Ha a mátrixok nem 2 n∗2n -esek, akkor a hiányzó sorokat és oszlopokat nullákkal töltjük fel. Felosztjuk az A, B és C Mátrixokat egyformán méretezett blokkmátrixokra.
akkor
Ezzel a szerkezettel nem csökkentettük a szorzások számát. Nekünk még mindig szükségünk van 8 szorzásra hogy számítsuk ki a C ij mátrixot. A szorzásszám ugyanannyi lesz mintha egy sima mátrixszorzást használnánk. Most jön a fontos rész. Meghatározzuk az új mátrixokat.
Ezeket használjuk arra, hogy kifejezzék a C ij -t akkor M k tekintetében. A definíciónk miatt M k -nál egy mátrixszorzást tudunk kiküszöbölni és 7-ig tudjuk csökkenteni a szorzások számát (egy szorzás mindegyik M k -nak) és aztán kifejezzük a C ij -t, mint
Ezt n-szer elvégezhetjük mire az almátrixok számok nem lesznek.
51
25. A játékelmélet alapjai. Egyszerű játéknak nevezzük az alábbi feltételeknek eleget tevő játékokat : Két játékos játszik, felváltva, nem véletlenszerűen, hanem tudatosan húznak, aki sorra kerül, annak kell húznia a szabályok szerint, minden játékos ismeri az összes előző lépést, minden játéknak két kimenetele lehet. Stratégián a játékmenetnek azt az utasításrendszerét értjük, amely figyelembe vesz minden olyan lépést, amikor A játékosnak lépnie kell, és minden esetben előírja, hogy mit tegyen a játékos. Nyerő stratégián azt értjük, hogy bármelyik e stratégia szerint játszó játékos tud úgy játszani, hogy a másik játékos bármilyen lépése mellett nyerjen. Minden egyszerű játékban valamennyi játékosnak van nyerő stratégiája, amelyet a játékfa elemzésével írunk föl. A játékfa a nyerő stratégia meghatározására szolgál. A játékfa tartalmazza a játék összes lépéskombinációját. A játékfa szerint A ill. B jellel látjuk el aszerint, hogy ki következik. A játékfa levelei azok a végpontok, ahonnan már nem vezet tovább él. A leveleket a kezdő (A) játékos szempontjából pozitív (+) ill. Negatív (-) jellel látjuk el aszerint, hogy az a levél a játékos nyerését ill vesztését jelöli. Ahonnan él vezet, azok a csomópontok. A levelek alapján a játékfa csomópontjaira előjelet származtatunk. A származtatás szabályai az alábbiak : • A szintű csomópont akkor pozitív, ha van pozitív csomópont vagy levél a felette lévő szinten a belőle kiágazó csomópontok és levelek között. • B szintű csomópont akkor pozitív, ha minden csomópont vagy levél pozitív a felette lévő szinten a belőle kiágazó csomópontok és levelek között. Végigvezetve a kiinduló csomópontig ezt, ha ott az érték pozitív, akkor az A játékosnak van nyerő stratégiája. A játékos nyerő stratégiája a játékfának pontosan az a része, amely a pozitív kiinduló csomóponttól csak pozitív csomópontokon jut el egy pozitív levélig. A játékfa elemzésénél a már ismert részeredmények is felhasználhatóak, azaz ha egy A szintű csomópontban fennálló állapot a játékfa másik A szintű csomópontjában is bekövetkezik, akkor “előjele” megegyező lesz a másikéval. Hasonlóan igaz az állítás két B szintű csomópontra is.
52
Klasszikus adatstruktúrák
53
26. Adatszerkezetek, láncolt listák, egyszer láncolt listák műveletei I. (új elem felvétele, bejárás, törlés) A láncolt, más néven egyirányú listák adatelemek, úgynevezett csomópontok lineáris gyűjteményéből állnak, amelyekben mutatók szabják meg az elemek sorrendjét. A mutatókról: gyakran adódnak olyan problémák, amelyek meghatározhatatlan számú objektum létrehozását teszik szükségessé (a tömbbel való megoldás nem hatékony), továbbá gyakran szükség van az adatok közt többszörös kapcsolat definiálására is. Összetett struktúrák ábrázolásának kulcsa az az ötlet, hogy egy adatelemben elhelyezzük egy másik adat mutatóját. Az így kapott szerkezet jól használható az adatelemek közötti strukturális kapcsolatok leírására, hierarchikus, vagy elágazó kapcsolatok reprezentálására. Ennek megfelelően tehát két részből állnak a csomópontok: az első rész az elem információtartalma, a második rész pedig a mutató, vagyis a lista következő elemének a címe.
A csomópontokat két részre tagoljuk. A bal oldali elem a csomópont információs része (INFO), amely akár teljes rekordot is tartalmazhat. A jobb oldali elem a csomópont mutatómezője (LINK), amelyből nyíl mutat a lista következő csomópontjára. Az utolsó csomópont mutatómezője különleges értéket tartalmaz. Ez az úgynevezett nullmutató (NULL), amely bármilyen érvénytelen cím lehet. (A gyakorlatban rendszerint 0-t vagy negatív számot használnak nullmutatóként.) A láncolt listához a fentieken kívül még egy listamutató változó is tartozik (START), amely a lista első csomópontjának címét tartalmazza. Ennek megfelelően tehát a START változótól nyíl mutat az első csomópontig. Nyilvánvaló, hogy a lista nyomon követéséhez csupán a START változóban tárolt címre van szükségünk. Láncolt listák létrehozása: Legyen a LIST láncolt lista, amelyet két párhuzamos tömb, az INFO és a LINK, valamint a START elnevezésű mutató segítségével hozunk létre a memóriában. Ehhez először a LIST valamennyi N csomópontjához egyegy K indexet rendelünk az alábbiak szerint: 1. az INFO[K] az N csomópont adatát tartalmazza; 2. a LINK[K] az N-et követő csomópont helyét tartalmazza. A START a LIST első csomópontjának helyét tartalmazza, a LIST utolsó csomópontjának LINK mezőjében pedig határoló érték (0 vagy negatív) szerepel majd. Ez a LIST végét jelzi, és NULL a tartalma. A lista csomópontjait nem szükséges az INFO és a LINK tömb egymást követő elemeiben elhelyezni, ezen kívül ugyanabban a lineáris INFO és LINK tömbben egynél több lista is tárolható.
Láncolt lista bejárása: Legyen a LIST az INFO és a LINK lineáris tömbben tárolt láncolt lista. A START változó mutasson a lista első elemére, a NULL pedig jelölje a LIST lista végét. A bejáró algoritmus a PTR mutatót használja, amely az éppen feldolgozott csomópontra mutat. Ennek megfelelően a LINK[PTR] elem a következő feldolgozandó csomópontra mutat. Az alábbi értékadás a következő csomópontra állítja a mutatót: PTR:=LINK[PTR]
54
Az algoritmus: 1. PTR:=START 2. repeat a 3. és 4. lépés while PTR≠NULL 3. Az információ feldolgozása az INFO[PTR]-re 4. PTR:=LINK[PTR] 5. Exit Az első lépés a PTR vagy a START inicializálása, majd az INFO[PTR], vagyis az információ feldolgozása. Ezt a PTR aktualizálása (PTR:=LINK[PTR]) követi, hogy a PTR a második csomópontra mutasson. A ciklus addig folytatódik, amíg PTR=NULL, ami a lista végét jelzi. Beszúrás a láncolt lista adatszerkezetbe: Legyen LIST olyan láncolt lista, amely tartalmazza az egymást követő A és B csomópontokat. Tegyük fel, hogy az A és a B csomópont közé be akarjuk szúrni az N csomópontot. Beszúrás után az A csomópont mutat a beillesztett N csomópontra, az N pedig a B csomópontra mutat, amelyre korábban az A csomópont mutatott.
Beszúrás a lista elejére: Tegyük fel, hogy a lista nem szükségszerűen rendezett, és nincs különösebb ok arra, hogy az új csomópontot a lista egyik különleges helyére szúrjuk be. Ekkor az a legegyszerűbb megoldás, ha a csomópontot a lista elejére szúrjuk be.
Az algoritmus: 1. INFO[NEW]:=ITEM (Új adat bemásolása az új csomópontba.) 2. LINK[NEW]:=START (Az új csomópont mos az eredetileg első csomópontra mutat.) 3. START:=NEW (A START értékének oly módon való megváltoztatása, hogy az most az új csomópontra mutasson.) 4. Exit Beszúrás megadott csomópont után: Tegyük fel, hogy adott annak a LOC-nac az értéke, amely vagy az A csomópont helye a LIST láncolt listában, vagy LOC=NULL. Az alábbiakban megadjuk azt az algoritmust, amely az ITEM-et — a következő feltételekkel — beszúrja a LIST listába: az ITEM az A csomópontot követi, vagy ha LOC=NULL, akkor az első csomópont lesz. Jelölje N az új csomópontot (amelynek a NEW a helye). Ha LOC=NULL, akkor a lista első csomópontjaként kell beszúrni az N-et, vagyis az előbbi példa szerint kell eljárni. Egyébként a B csomópontra kell mutatnia az N-nek (a B eredetileg az A csomópontot követte), amit az alábbi értékadás valósít meg: LINK[NEW]:=LINK[LOC] Az alábbi értékadás hatására az A csomópont az új N csomópontra mutat: LINK[LOC]:=NEW
55
Az algoritmus: 1. NEW:=SZABAD HELY (Az első csomópont eltávolítása a SZABAD HELY-ek listából.) SZABAD HELY:=LINK[SZABAD HELY] 2. INFO[NEW]:=ITEM (Új adat bemásolása az új csomópontba.) 3. if LOC=NULL then (Beszúrás első csomópontként) LINK[NEW]:=START START:=NEW else (Beszúrás a LOC helyen levő csomópont után) LINK[NEW]:=LINK[LOC] LINK[LOC]:=NEW end; 4. Exit Törlés a láncolt listából: Legyen adott a LIST láncolt lista az A és a B között elhelyezkedő N csomóponttal. Tegyük fel, hogy az N csomópontot törölni akarjuk a láncolt listából. Ha az A csomópont mutatója a B csomópontra mutat, akkor elvégzettnek tekinthetjük a törlést. Amikor tehát törlést hajtunk végre, akkor a törlendő csomópontot közvetlenül megelőző csomópont címét is tárolnunk kell. Adott csomópontot követő csomópont törlése: Legyen a LIST kapcsolt lista a memóriában. Az N csomópont helye a LIST listában a LOC, az N-et megelőző csomópont helye a LOCP, és ha az N a lista első csomópontja, akkor LOCP=NULL. Ilyen feltételek esetén az alábbi algoritmus törli ki a listából az N csomópontot:
Az algoritmus: 1. if LOCP=NULL then START:=LINK[START] (Az első csomópont törlése) else LINK[LOCP]:=LINK[LOC] (Az N csomópont törlése) end; 2. (A törölt csomópont visszakapcsolása a SZABAD HELY-ek listájára) LINK[LOC]:=SZABAD HELY SZABAD HELY:=LOC 3. Exit
56
27. Adatszerkezetek, láncolt listák, speciális listák műveletei II. (rendezett láncolt lista, többirányú, többszörösen láncolt lista, strázsa) Keresés rendezett listában: Tegyük fel, hogy a LIST rendezett adatszerkezet, és az ITEM információ megkeresése a feladat, miközben a PTR mutató felhasználásával bejárjuk a teljes LIST listát, és az ITEM tételt a lista valamennyi csomópontjában egyesével összehasonlítjuk az INFO[PTR] elemmel. Mivel a lista rendezett, azonnal leállítjuk a műveletet, ha az ITEM értéke nagyobb az INFO[PTR] értékénél. A LIST a memóriában levő rendezett lista. Az algoritmus megkeresi annak a csomópontnak a helyét (LOC), amelyben az ITEM információ először fordul elő a LIST szerkezetben, vagy a LOC értéket NULL-ra állítja be. Az algoritmus: 1. PTR:=START 2. Repeat 3. lépés while PTR≠NULL 3. if ITEM
57
A FIRST változó és a FORW mutatómező segítségével előrefelé járhatjuk be a kétirányú listát. A LAST változó és a BACK mutatómező segítségével azonban visszafelé is bejárhatjuk a listát. Tegyük fel, hogy a kétirányú listában az A, illetve a B csomópont helye LOCA, illetve a LOCB. A FORW és a BACK mező definiálásának módjából ekkor az alábbi mutatótulajdonságok adódnak: FORW[LOCA]=LOCB, de akkor és csak akkor, ha BACK[LOCB]=LOCA. Másként fogalmazva: az az állítás, hogy a B csomópont követi az A csomópontot azzal az állítással ekvivalens, hogy az A csomópont megelőzi a B csomópontot. A kétirányú listákat az egyirányú listákhoz hasonlóan, lineáris tömbök segítségével hozhatjuk létre a memóriában. Ebben az esetben azonban egyetlen mutatótömb helyett kettőre (FORW, BACK) van szükség, egyetlen mutató (START) helyett pedig ugyancsak kettőt (FIRST, LAST) kell használnunk. A szabad helyek listát, amely a tömbök szabad helyeit tartja nyilván, továbbra is egyirányú listaként valósíthatjuk meg. Műveletek a kétirányú listákkal: Tegyük fel, hogy a LIST kétirányú listát a memória tárolja. Bejárás: Tegyük fel, hogy be akarjuk járni a LIST szerkezetet, hogy egyszer feldolgozzuk valamennyi csomópontot. Ha a LIST hagyományos kétirányú lista, akkor ehhez az egyirányú listáknál már megismert algoritmust használhatjuk. Az algoritmus: 1. PTR:=START 2. repeat a 3. és 4. lépés while PTR≠NULL 3. Az információ feldolgozása az INFO[PTR]-re 4. PTR:=LINK[PTR] 5. Exit Törlés: Tegyük fel, hogy megkapjuk az N csomópont LOC helyét, amelyet ki akarunk törölni a LIST listából. Tegyük fel, hogy a LIST kétirányú zárt fejelt lista. Megjegyezzük, hogy ebben az esetben a BACK[LOC] és a FORW[LOC] az N csomópontot megelőző, illetve követő csomópont helyét tartalmazza. Ennek megfelelően az N csomópontot az alábbi mutatópár beállításával törölhetjük. FORW[BACK[LOC]]:=FORW[LOC] BACK[FORW[LOC]]:=BACK[LOC] A törölt csomópontot az alábbi értékadással kapcsolhatjuk vissza a szabad helyek listához: FORW[LOC]:=SZABAD HELYEK SZABAD HELYEK:=LOC
Az algoritmus: 1. FORW[BACK[LOC]]:=FORW[LOC] BACK[FORW[LOC]]:=BACK[LOC] 2. FORW[LOC]:=SZABAD HELYEK SZABAD HELYEK:=LOC 3. Exit
(A csomópont törlése) (A csomópont visszakapcsolása a szabad helyek listához)
Ezúttal ismét megfigyelhetjük a kétirányú lista adatszerkezet egyik fő előnyét. Ha ugyanis egyirányú listába szerveztük volna az adatokat, akkor az N csomópont törléséhez be kellett volna járnunk az egyirányú listát, hogy az N-et megelőző csomópont helyét is megkapjuk.
58
Beszúrás: Tegyük fel, hogy adott két egymást követő A és B csomópont LOCA és LOCB helye a LIST listában. Tegyük fel, hogy adott ITEM információt e két csomópont közé akarjuk beszúrni. Ebben az esetben — az egyirányú listához hasonlóan — a SZABAD HELYEK LISTÁBÓL először eltávolítjuk az első csomópontot (N), és e csomópont helyének tárolására felhasználjuk a NEW változót. Ezt követően — az alábbi értékadásokkal — az ITEM adatot bemásoljuk az N csomópontba: NEW:=SZABAD HELYEK, SZABAD HELYEK:=FORW[SZABAD HELYEK], INFO[NEW]:=ITEM Miként alább, az ábrán megfigyelhető, az ITEM adatot tartalmazó N csomópontot az alábbi négy mutató megváltoztatásával szúrhatjuk be a listába: FORW[LOCA]:=NEW, FORW[NEW]:=LOCB BACK[LOCB]:=NEW, BACK[NEW]:=LOCA
Az algoritmus: 1. if SZABAD HELYEK=NULL then write:túlcsordulás Exit (Túlcsordulás?) 2. NEW:=SZABAD HELYEK SZABAD HELYEK:=FORW[SZABAD HELYEK] INFO[NEW]:=ITEM (A csomópont eltávolítása a SZABAD HELYEK listából, és az új adat bemásolása a csomópontba.) 3. FORW[LOCA]:=NEW FORW[NEW]:=LOCB BACK[LOCB]:=NEW BACK[NEW]:=LOCA (A csomópont beszúrása a listába.) 4. Exit
59
28. B-fa adatszerkezet, B-fába való beszúrás algoritmusa (B-fa jellemzői, előnyei, felépítése, új elem felvétele)
60
29. B-fa adatszerkezet, B-fából való törlés algoritmusa (B-fa jellemzői, előnyei, felépítése, törlés)
61
30. Fa adatszerkezetek, bináris fák alapműveletei (új elem felvétele, bejárások, törlés) A T bináris fa csomópontoknak nevezett elemek véges számú halmazának tekinthető, amelyre igazak az alábbi definíciók is: a) a T fa vagy üres (ezt üres fának nevezzük), vagy b) R számú megkülönböztetett csomópontot tartalmaz, amely a T gyökere, a többi csomópont pedig a T1 és a T2 diszjunkt bináris fákhoz tartozik. Ha a T gyökércsomópontot tartalmaz, akkor a T1 és T2 részfát az R jobb, illetve bal oldali részfájának nevezzük. Ha a T1 nem üres részfa, akkor gyökerét az R bal oldali szukcesszorának nevezzük, és ha a T2 sem üres, akkor ez utóbbi gyökerét az R jobb szukcesszorának hívjuk. A bináris fákat gyakran diagramokkal ábrázolják.
A fenti fa 11 csomópontból áll, gyökércsomópontja a diagram tetején elhelyezkedő A csomópont. Az A csomópont bal oldali szukcesszora a B, a jobb oldali szukcesszora pedig C. Az A gyökér bal oldali részfája a B, D, E és F, jobb oldali részfája pedig a C, G, H, J, K és L csomópontból áll. A T bináris fa bármely csomópontjának 0, 1 vagy 2 szukcesszora lehet. Az A, B, C és H csomópontnak két szukcesszora van, az E és a J csomópontnak egy, a D, F, G, L és K csomópontnak pedig nincs szukcesszora. A T bináris fa előbbi definíciója rekurzív, mivel a T fát a T1 és a T2 bináris részfával fejezzük ki. Ez gyakorlatilag azt jelenti, hogy a T valamennyi N csomópontjához egy bal és egy jobb oldali részfa tartozik, ha viszont az N záró csomópont, akkor ezek a részfák üresek. A T fa csomópontjai közötti kapcsolatok leírására gyakran származástani kifejezéseket használnak. Tegyük fel, hogy az N a T fa egyik csomópontja, és ez utóbbinak az S1 a bal, az S2 jobb oldali szukcesszora. Az N-et ekkor az S1 és az S2 szülőjének nevezzük. Hasonlóképpen: az S1 az N bal oldali gyermeke, az S2 pedig a jobb oldali gyermeke. Az ős és a leszármazott kifejezésnek a hétköznapi szóhasználatban azonos a jelentése. A gráfelméletből és a növénytanból származó kifejezéseket a bináris fákkal kapcsolatban is használjuk. Ily módon a T fában az N csomóponttól az azt követő csomópontba húzott vonalat élnek, az egymást követő élek sorozatát pedig útvonalnak nevezzük. A T bináris fa valamennyi csomópontjához az alábbiak szerint szintszámot rendelhetünk: a T fa R gyökeréhez a 0-s szintszám tartozik, a további csomópontokhoz pedig mindig 1-gyel nagyobb szintszám, mint a szülő szintszáma. Az azonos szintszámú csomópontok azonos generációhoz tartoznak. A T fa mélységét (vagy magasságát) az egy ágában elhelyezkedő csomópontok legnagyobb száma adja meg. Ez az érték mindig nagyobb 1-gyel, mint a T legnagyobb szintszáma. A bináris fa bejárása: Az R gyökerű T bináris fa bejárásának három szokásos módja van: az irányítással megegyező (preorder), az irányítással ellentétes (postorder) és a szimmetrikus sorrendben (inorder) való bejárás. Figyeljük meg, hogy valamennyi algoritmus ugyanazt a három lépést tartalmazza, és az R bal oldali részfájának bejárása mindig megelőzi a jobb oldali részfa bejárását. Az algoritmusok között csak az R gyökér feldolgozásának időpontjában van különbség.
62
A preorder bejárás: 1) A gyökér feldolgozása. 2) Az R bal oldali részfájának bejárása az irányítással megegyező (preorder) sorrendben. 3) Az R jobb oldali részfájának bejárása az irányítással megegyező (preorder) sorrendben. Az irányítással megegyező sorrendű (preorder) bejárás:A preorder bejárást megvalósító algoritmus a PTR mutatót használja, amely mindig az éppen elért N csomópont helyét tartalmazza. Az algoritmus a STACK tömböt is használja, amely a később feldolgozandó csomópontok címét tárolja. Az algoritmus: Az algoritmus az irányítással megegyező sorrendben bejárja a memóriában levő T bináris fát, miközben a fa csomópontjaira a PROCESS-szel jelölt műveletet alkalmazza. A STACK tömb ideiglenesen tárolja a csomópontok címét. 1. TOP:=1, STACK[1]:=NULL, PTR:=ROOT. (kiindulásként a NULL ráhelyezése a STACK-re és a PTR iniciaizálása.) 2. repeat 3. to 5. lépés while PTR≠NULL 3. A PROCESS alkalmazása az INFO[PTR] csomópontra 4. if RIGHT[PTR]≠NULL then (Van-e jobb oldali gyermek?) TOP:=TOP+1 STACK[TOP]:=RIGHT[PTR] (Ráhelyezés a STACK-re.) az if szerkezet vége 5. if LEFT[PTR]≠NULL then (Van-e bal oldali gyermek?) PTR:=LEFT[PTR] else PTR:=STACK[TOP] TOP:=TOP-1 (Leemelés a STACK-ről) az if szerkezet vége a 2. lépésben elkezdődött ciklus vége 6. Exit a) Kiindulásként a NULL ráhelyezése a STACK-re, PTR:=ROOT értékadás, majd az alábbi lépések ismétlése mindaddig, amíg (until) PTR=NULL, vagy ezzel ekvivalens módon, amíg (while) PTR≠NULL. b) A PTR által megjelölt gyökérből kiindulva és a bal szélső útvonalon lefelé haladva az útvonalhoz tartozó valamennyi N csomópont feldolgozása, miközben a STACK-re helyezzük az összes jobb oldali gyermeket, ha az adott csomóponthoz tartozik ilyen. A bejárás azon N csomópont feldolgozása után fejeződik be, amelyhez nem tartozik bal oldali gyermek. Ily módon a PTR mutatót a PTR:=LEFT[PTR] értékadás aktualizálja, és a bejárás akkor fejeződik be, ha LEFT[PTR]=NULL. c) Visszalépés. A STACK legfelső elemének leemelése és a PTR-hez való hozzárendelése. Ha PTR≠NULL, akkor visszatérés a b) lépésre, egyébként Exit.
Az inorder bejárás: 1) Az R bal oldali részfájának bejárása szimmetrikus (inorder) sorrendben. 2) A gyökér feldolgozása. 3) R jobb oldali részfájának bejárása szimmetrikus (inorder) sorrendben. Szimmetrikus sorrendben (inorder) történő bejárás: Az inorder bejárást megvalósító algoritmus ugyancsak a PTR mutatót, valamint a STACK tömböt használja. Az előbbi az éppen feldolgozott N csomópont helyét, az utóbbi pedig a későbbiekben feldolgozandó csomópontok címét tartalmazza. Ez az algoritmus azonban csak akkor dolgoz fel egy csomópontot, ha azt leemeltük már a STACK-ről. Az algoritmus:Az algoritmus szimmetrikus sorrendben bejárja a memóriában levő T bináris fát, miközben a szóban forgó fa csomópontjaira a PROCESS-szel jelölt műveletet alkalmazza. A STACK tömb ideiglenesen tárolja a csomópontok címét.
63
1. TOP:=1, STACK[1]:=NULL, PTR:=ROOT. (Kiindulásként a NULL ráhelyezése a STACK-re és a PTR inicializálása.) 2. repeat while PTR≠NULL (A bal szélső útvonal ráhelyezése a STACK-re) TOP:=TOP+1 STACK[TOP]:=PTR (A csomópont elmentése) PTR:=LEFT[PTR] (A PTR aktualizálása) a ciklus vége 3. PTR:=STACK[TOP], TOP:=TOP-1 (A csomópont leemelése a veremről) 4. repeat 5. to 7. lépés while PTR≠NULL (Visszalépés) 5. A PROCESS alkalmazása az INFO[PTR] csomópontra 6. (Van-e jobb oldali gyermek?) if RIGHT[PTR]≠NULL then PTR:=RIGHT[PTR] Go to 3. lépés az if szerkezet vége 7. PTR:=STACK[TOP] TOP:=TOP-1 (A csomópont leemelése a STACK-ről) a 4. lépésben elkezdődött ciklus vége 8. Exit a) Kiindulásként a NULL ráhelyezése a STACK-re, PTR:=ROOT értékadás, majd az alábbi lépések ismétlése mindaddig, amíg a NULL-t emelhetjük le a STACK-ről. b) A PTR által megjelölt gyökérből kiindulva és a bal szélső útvonalon lefelé haladva az útvonalhoz tartozó valamennyi N csomópont ráhelyezése a STACK-re. A művelet akkor fejeződik be, ha olyan csomópontot helyezünk a veremre, amelynek nincs bal oldali gyermeke. c) Visszalépés. A STACK-en levő csomópontok leemelése és feldolgozása. A NULL leemelésekor kilépés. Ha olyan csomópont feldolgozására kerül sor, amelynek van jobb oldali gyermeke, akkor a PTR mutató értékének aktualizálása a PTR:=RIGHT[PTR] értékadással és visszatérés a b) lépéshez. (Az N csomópontot csak akkor lehet feldolgozni, ha már leemeltük a STACK-ről.)
A postorder bejárás: 1) Az R bal oldali részfájának bejárása az irányítással ellentétes (postorder) sorrendben. 2) Az R jobb oldali részfájának bejárása az irányítással ellentétes (postorder) sorrendben. 3) A gyökér feldolgozása. Az irányítással ellentétes sorrendben (postorder) történő bejárás: Az irányítással ellentétes sorrendben való bejárást megvalósító algoritmus bonyolultabb az előző két algoritmusnál, mivel az N csomópont tárolására itt két különböző helyzetben kerülhet sor. A két esetet úgy különböztetjük meg, hogy vagy az N-et, vagy az N negatívját, vagyis –N-et helyezzünk rá a STACK-re. Az előzőekhez hasonlóan most is PTR mutatóváltozót használjuk az éppen feldolgozott N csomópont helyének tárolására. Az algoritmus: Az algoritmus az irányítással ellenkező sorrendben bejárja a memóriában levő T bináris fát, miközben a csomópontjaira a PROCESS-szel jelölt műveletet alkalmazza. A STACK tömb ideiglenesen tárolja a csomópontok címét. 1. TOP:=1, STACK[1]:=NULL, PTR:=ROOT. (Kiindulásként a NULL ráhelyezése a STACK-re és a PTR inicializálása.) 2. repeat 3. to 5. lépés while PTR≠NULL (A bal szélső útvonal ráhelyezése a STACK-re) 3. TOP:=TOP+1 64
STACK[TOP]:=PTR (A PTR ráhelyezése a STACK-re) 4. if RIGHT[PTR]≠NULL then TOP:=TOP+1 STACK[TOP]:= –RIGHT[PTR] (Ráhelyezés a STACK-re) az if szerkezet vége 5. PTR:=LEFT[PTR] (A PTR mutató aktualizálása) a 2. lépésben elkezdődött ciklus vége 6. PTR:=STACK[TOP] TOP:=TOP-1 (A csomópont leemelése a STACK-ről.) 7. Repeat while PTR>0 A PROCESS alkalmazása az INFO[PTR] csomópontra PTR:=STACK[TOP] TOP:=TOP-1 (A csomópont leemelése a STACK-ről.) A ciklus vége 8. if PTR<0 then PTR:= –PTR Go to 2. lépés Az if szerkezet vége 9. Exit. a) Kiindulásként a NULL ráhelyezése a STACK-re, PTR:=ROOT értékadás, majd az alábbi lépések ismétlése mindaddig, amíg a NULL-t emelhetjük le a STACK-ről. b) A feldolgozás a PTR-nél levő gyökérrel indul, és a bal szélső útvonalon lefelé halad. Az útvonalhoz tartozó valamennyi N csomópontban ráhelyezzük a STACK-re az N-et, és ha az N-nek van jobb oldali gyermeke, akkor azt is ráhelyezzük a STACK-re. c) Visszalépés. A STACK-en levő pozitív előjelű csomópontok leemelése és feldolgozása. A NULL leemelésekor Exit. Negatív előjelű csomópont leemelésekor, vagyis ha PTR=-N, a PTR beállítása N-re, PTR:=-PTR értékadás és visszatérés a b) lépésre. (Csak a STACK-ről leemelt pozitív N csomópontot lehet feldolgozni.)
Beszúrás a bináris rendezett fa adatszerkezetben: Az algoritmus:Legyen adott a memóriában a T bináris rendezett fa, valamint az ITEM információ. Az algoritmus az ITEM tételt új csomópontként beszúrja a T fa LOC helyére. 1. if LOC≠NULL then Exit. 2. (Az ITEM bemásolása a SZABAD HELYEK első szabad csomópontjába.) if SZABAD HELYEK=NULL then Write: Túlcsordulás Exit. NEW:= SZABAD HELYEK SZABAD HELYEK:=LEFT[SZABAD HELYEK] INFO[NEW]:=ITEM LOC:=NEW LEFT[NEW]:=NULL RIGHT[NEW]:=NULL 3. (Az ITEM beszúrása a fába.) if PAR=NULL then ROOT:=NEW else if ITEM
Törlés a bináris, rendezett fában: Legyen adott a T bináris, rendezett fa, valamint az ITEM információ. A következőkben azt az algoritmust ismertetjük, amely törli a T fából az ITEM tételt. Három esetet különböztetünk meg: 1. Az N-nek nincs gyermeke. Ebben az esetben úgy töröljük az N csomópontot, hogy az N-hez tartozó szülő csomópontban a nullmutatóra cseréljük az N helyét. 2. Az N-nek csupán egyetlen gyermeke van. Ebben az esetben úgy töröljük az N csomópontot, hogy az N-hez tartozó szülő csomópontban a gyermeke helyével felülírjuk az N helyét. 3. Az N-nek két gyermeke van. Jelölje S(N) az N-et szimmetrikus sorrendben (inorder) követő elemet. Az N csomópontot csak úgy törölhetjük a T-ből, hogy először töröljük az S(N) csomópontot, ezt követően pedig az N csomópontot felcseréljük az S(N)-re. Eljárás A Az eljárás törli a LOC helyen levő N csomópontot, ha az N csomópontnak nulla vagy egy gyermeke van. A PAR mutató megadja az N-hez tartozó szülő csomópont helyét, vagy jelzi — a PAR=NULL feltétellel —, hogy az N a gyökércsomópont. A CHILD mutató megadja az N csomópont gyermekének helyét, vagy jelzi — a CHILD=NULL feltétellel — hogy az N-nek nincs gyermeke. 1. (A CHILD mutató inicializálása) if LEFT[LOC]=NULL and RIGHT[LOC]=NULL then CHILD:=NULL else if LEFT[LOC]≠NULL then CHILD:=LEFT[LOC] else CHILD:=RIGHT[LOC] if szerkezet vége 2. if PAR≠NULL then if LOC=LEFT[PAR] then LEFT[PAR]:=CHILD else RIGHT[PAR]:=CHILD az if szerkezet vége else ROOT:=CHILD Az if szerkezet vége 3. return Eljárás B Az eljárás törli a LOC helyen levő N csomópontot, ha az N csomópontnak két gyermeke van. A PAR mutató megadja az N-hez tartozó szülő csomópont helyét, vagy jelzi — a PAR=NULL feltétellel —, hogy az N a gyökércsomópont. A SUC mutató megadja az N-et szimmetrikus (inorder) sorrendben követő elem helyét, a PARSUC pedig tárolja az N-et szimmetrikus (inorder) sorendben követő elem szülőjének a helyét. 1. (A SUC és a PARSUC elem megkeresése.) PTR:=RIGHT[LOC] SAVE:=LOC repeat while LEFT[PTR]≠NULL SAVE:=PTR PTR:=LEFT[PTR] a ciklus vége SUC:=PTR PARSUC:=SAVE 2. (A szimmetrikus sorrend szerint következő elem törlése az Eljárás A segítségével.) call Eljárás A 66
3. (Az N csomópont felcserélése az N-et szimmetrikus sorrendben követő elemmel.) if PAR≠NULL then if LOC=LEFT[PAR] then LEFT[PAR]:=SUC else RIGHT[PAR]:=SUC az if szerkezet vége else ROOT:=SUC az if szerkezet vége LEFT[SUC]:=LEFT[LOC] RIGHT[SUC]:=RIGHT[LOC] 4. return Az Eljárás A-t és az Eljárás B-t használó törlő eljárás: Legyen adott a T bináris, rendezett fa a memóriában, valamint az ITEM információ. Az algoritmus törli a fából az ITEM-et tartalmazó csomópontot. Az algoritmus: 1. (Az ITEM-et tartalmazó csomópont törlése.) if RIGHT[LOC]≠NULL and LEFT[LOC]≠NULL then call Eljárás B else call Eljárás A az if szerkezet vége 2. (A törölt csomópont visszakapcsolása a SZABAD HELYEK listába.) LEFT[LOC]:=SZABAD HELYEK SZABAD HELYEK:=LOC 3. exit
67
31. Fa adatszerkezetek, piros-fekete fa adatszerkezet (forgatások, új elem felvétele, törlés) A piros-fekete fák szintén kiegyensúlyozott bináris keresőfák. Mindegyik pontot ki kell egészíteni egy egy bitnyi kísérő információval, ami az adott pont színét adja meg. A piros-fekete tulajdonság a következő: 1. 2. 3. 4.
Minden pont színe vagy piros vagy fekete. Minden NIL levél színe fekete. Minden piros pontnak mindkét fia fekete. Bármely két, azonos pontból induló és levélig vezető úton ugyanannyi fekete pont van.
Az órán elhangzott feladatok: • •
•
•
Adott egy 15 pontú teljes bináris keresőfa. Próbáljuk meg kiszínezni minél többféleképpen a pontokat! (2, 3 vagy 4 lehet a fekete-magasság.) Megmarad-e a piros-fekete tulajdonság akkor, ha egy piros gyökerű fa gyökerének a színét feketére változtatjuk? Válasz: igen. Egy adott pontból a levelekig vezető utak közül a leghosszabb legfeljebb hányszorosa lehet a legrövidebbnek? Válasz: kb. a kétszerese. Mennyi a legtöbb pontot tartalmazó k fekete magasságú piros-fekete fa belső pontjainak száma? Válasz: 22*k+1-1.
Forgatások: A piros-fekete tulajdonság fenntartásához majd szükség lesz lokális forgatásokra. BALRA-FORGAT(x) y=jobb[x] jobb[x]=bal[y] if bal[y]!=NIL then apa[bal[y]]=x apa[y]=apa[x] if apa[x]==NIL then gyökér=y else if x==bal[apa[x]] then bal[apa[x]]=y else jobb[apa[x]]=y bal[y]=x apa[x]=y A JOBBRA-FORGAT hasonló. Mindkettő O(1) idejű. A forgatások megtartják az elemek inorder felsorolását. Beszúrás: Feltesszük, hogy a gyökér mindig fekete. PF-BESZÚR(x) BESZÚR(x) szín[x]=piros while x!=gyökér and szín[apa[x]]==piros if apa[x]==bal[apa[apa[x]]] y=jobb[apa[apa[x]]] if szín[y]==piros // 1. eset szín[apa[x]]=fekete szín[y]=fekete szín[apa[apa[x]]]=piros x=apa[apa[x]] else if x==jobb[apa[x]] // 2. eset x=apa[x] BALRA-FORGAT(x) // 3. eset szín[apa[x]]=fekete 68
szín[apa[apa[x]]]=piros JOBBRA-FORGAT(apa[apa[x]]) else y=bal[apa[apa[x]]] if szín[y]==piros // 1. eset szín[apa[x]]=fekete szín[y]=fekete szín[apa[apa[x]]]=piros x=apa[apa[x]] else if x==bal[apa[x]] // 2. eset x=apa[x] JOBBRA-FORGAT(x) // 3. eset szín[apa[x]]=fekete szín[apa[apa[x]]]=piros BALRA-FORGAT(apa[apa[x]]) szín[gyökér]=fekete Az órán elhangzott feladatok: • • • •
• •
Miért nem feketére állítjuk az új pont színét? Válasz: azért, mert akkor a 4. tulajdonság sérülne. Mennyi az algoritmus futási ideje? Válasz: O(lg(n)) Legfeljebb hány forgatást hajtunk végre egy alkalommal? Válasz: legfeljebb kettőt. Miért változtatjuk a gyökér színét feketére? Válasz: túl bonyolult adminisztrációt kellene végezni annak megállapítására, hogy valóban feketére kell-e állítani. Így viszont biztos nem rontjuk el a piros-fekete tulajdonságot, és mindig működik. (A fenti kód alapján keressünk példát arra, hogy valóban szükség van erre.) Szimuláljuk a bővítést a következő elemekkel (kezdetben a fa üres): 41, 38, 31, 12, 19, 8. Hogyan lehetne hatékonyan megvalósítani a PF-BESZÚR műveletet, ha nem lenne apa pointer? Válasz: rekurzívan.
Törlés: nil strázsa pontok vannak a sehova se mutató pointerek helyett. Hasonló a "hagyományos" törléshez, csak a végén szükség esetén helyre kell állítani a piros-fekete tulajdonságot. PF-TÖRÖL(z) y=(bal[z]==nil or jobb[z]==nil)?z:KÖVETKEZŐ(z) x=(bal[y]!=nil)?bal[y]:jobb[y] apa[x]=apa[y] if apa[y]==nil then gyökér=x else if y==bal[apa[y]] then bal[apa[y]]=x else jobb[apa[y]]=x if y!=z then kulcs[z]=kulcs[y] if szín[y]==fekete then JAVÍT(x) return y JAVÍT(x) while x!=gyökér and szín[x]==fekete if x==bal[apa[x]] w=jobb[apa[x]] if szín[w]==piros // 1. eset szín[w]=fekete szín[apa[x]]=piros BALRA-FORGAT(apa[x]) 69
w=jobb[apa[x]] if szín[bal[w]]==fekete and szín[jobb[w]]==fekete // 2. eset szín[w]=piros x=apa[x] else if szin[jobb[w]]==fekete // 3. eset szín[bal[w]]=fekete szín[w]=piros JOBBRA-FORGAT(w) w=jobb[apa[x]] // 4. eset szín[w]=szín[apa[x]] szín[apa[x]]=fekete szín[jobb[w]]=fekete BALRA-FORGAT(apa[x]) x=gyökér else w=bal[apa[x]] if szín[w]==piros szín[w]=fekete szín[apa[x]]=piros JOBBRA-FORGAT(apa[x]) w=bal[apa[x]] if szín[jobb[w]]==fekete and szín[bal[w]]==fekete szín[w]=piros x=apa[x] else if szin[bal[w]]==fekete szín[jobb[w]]=fekete szín[w]=piros BALRA-FORGAT(w) w=bal[apa[x]] szín[w]=szín[apa[x]] szín[apa[x]]=fekete szín[bal[w]]=fekete JOBBRA-FORGAT(apa[x]) x=gyökér szín[x]=fekete Ezt úgy kell elképzelni, mintha x tartalmazna egy extra fekete színt. Az órán elhangzott feladatok: • •
Az előző feladatok egyikében felépítettünk egy piros-fekete fát. Most szimuláljuk a törlást a következő sorrendben: 8, 12, 19, 31, 38, 41. Legfeljebb hány darab forgatást hajtunk végre egy törléskor? Válasz: hármat.
70
32. Gráfok I. (körmentes út keresése (labirintus); legrövidebb út keresése). Alapvető fogalmak: Irányított gráfok: a G gráfot a G=(V,E) pár adja meg, ahol V a csúcsok halmaza, E az élek halmaza. Jelölésük: u v irányított él u-ból v-be, u ∈V , v ∈ V . Szokás (u,v) rendezett párként is megadni, tehát E részhalmaza VxV-nek. Út: s v út a G gráfban, ha s v 1 v 2 v 3 … v csatlakozó élekből áll. Súlyozott gráf: az élekhez súlyokat, költséget rendelünk. A súlyfüggvény c : E R (c jelentése lehet hossz, súly, idő, költség stb.), (pozitív, valós értékű súlyokat tekintünk). Megállapodás: ha u,v között nincs él, akkor c(u,v)= ∞ A legrövidebb út problémája: Adott s ∈V pont, a forrás. Határozzuk meg minden v ∈V -re a d(s,v) távolságot, ahol d(s,v) az s-ből v-be vezető legrövidebb út hossza. Dijkstra algoritmusa a legrövidebb út megadására: Az algoritmus a távolságok monoton növekvő sorrendjében adja meg a pontokat és távolságaikat s-től. Legyen C(u,v) az élek súlyainak tömbje. Gyűjtsük D(s,v)-be az stől való távolságokat. 1. Kezdő érték adása: D(s,v)=C(s,v) 2. Az első (s-hez legközelebbi) pont kiválasztása: – legyen x1ЄV az a pont, amin D(s,x1) minimális, vagyis D(s,x1)≤D(s,w), minden wЄV-{s} -re. Ezt a pontot rövidebb úton nem lehet elérni s-ből, hiszen minden más út egy ennél távolabbi pontba lépéssel kezdődne. – Ezt az x-et tegyük a KÉSZ halmazba, a KÉSZ halmazba gyűjtjük a soron következő legközelebbi pontot. 3. A második legközelebbi pont kiválasztása: az elsőnek talált x1-re képezzük a D s , w=min D s , w , D s , x1 C x 1, w távolságokat, minden w ∈V −KÉSZ pontra. A második legközelebbi pont x2 lesz, amin D s , x 2 ≤ D s , w , minden w ∈V −KÉSZ -re. Tegyük x2-t a KÉSZ-be. Az x2-t D(s, x2)-nél rövidebb úton nem tudjuk elérni, hiszen minden olyan út, ami nem s x 2 -vel kezdődik, D s , x 2 minimalitása miatt hosszabb D(s,w) úttal kezdődne. 4. Az i-edik pont választása: az i-1-edik lépés végén x i−1 -et választottuk, tettük a KÉSZ halmazba. Képezzük most x i−1 -gyel a D s , w=min D s , w , D s , x 1−1C x i−1 , w új távolságokat. Válasszuk xi-nek azt a pontot (olyan pontot), amin D s , x i ≤ D s , w minden w ∈V −KÉSZ -re. Az így kapott xi pontot ennél rövidebben nem tudjuk elérni s-ből, hiszen minden olyan út, ami KÉSZ pontjaiból jut el végül xi-be, legalább ilyen hosszú volt a korábbi választások szerint. Ha viszont egy út V-KÉSZ-ben levő ponton át vezet, az már eleve nem rövidebb, mint D s , x i . 5. Az eljárás befejeződik, ha KÉSZ=V lesz Könnyen látható, hogy a csúcsok számának n=|V|-nek függvényében az algoritmus lépésszáma O(n2). A legrövidebb utak megadása: A Dijkstra algoritmus alapján az útvonalakat is megadhatjuk. Legyen P(v) tömbben az s-ből v-be vezető legrövidebb út v-t közvetlenül megelőző pontja. A P(v) tömbön visszafelé lépegetve kapjuk a v-ből visszafele vezető legrövidebb utat s-be. A P v v élek fát alkotnak. Ennek a fának mentén érünk s-ből a legrövidebb úton bárhova. P(v) előállítása: A Dijkstra algoritmus D s , v =min D s , v , D s , x i C x i , v értékadásánál P v =x i , ha D s , x i C x i , v ≤ D s , v teljesült. A módszer irányítatlan gráfokra is működik. A G(V,E) gráf irányítatlan, ha az e ∈E éleknek nincs irányítása. Az u,v pontok közötti élt a kételemű {u,v} rendezetlen halmazzal adjuk meg.
71
Gráfok bejárása: Gráfokkal kapcsolatos feladatoknál gyakran fontos a gráf pontjainak szisztematikus bejárása az élek mentén. Bináris fáknál ilyen például a pre-, in-, postorder bejárás. Két alaplehetőség: a mélységi bejárás és a szélességi bejárás. Szemléltetés: a lámpagyújtás (irányítatlan gráfokra) - Mélységi bejárás: egy lámpagyújtó elindul a város tetszőleges pontjából. Meggyújt egy lámpát, benéz onnan egy utcába és, ha a végén nem ég lámpa, odamegy és meggyújtja. Addig halad így, amíg talál sötét végű utcát. Ha nem talál, elindul vissza, keres sötét végű utcát minden pontban. Ha egy pontból csupa égő lámpát lát, még tovább indul visszafele. - Szélességi bejárás: Egy nagy csapat lámpagyújtó indul a város egy pontjából. Szétoszlanak annyi csapatra, ahány út indul ki a pontból. Mindegyik csapat elmegy az útszakasza végére. Meggyújtják a lámpát, majd oszlanak további csapatokra, ahány irányban még sötét utcavéget látnak. Ha a gráf összefüggő (bármely két pontja között van út), akkor a bejárások (előre haladó lépések) fát alkotnak. Ha nem összefüggő, akkor erdőt kapunk. Irányított gráfokra is hasonló a bejárás. Mélységi bejárásnál előfordulhat, hogy a visszalépések során olyan pontba jutunk, ahonnan nem vezet ki további sötét végű út, de még nem jártuk be a gráfot. Ilyenkor egy új kezdőpontot választunk. Szélességi bejárás is elakadhat, ilyenkor új pontot kell választani. Irányított körmentes gráfok (Directed Acyclic Graphs, DAG): - ütemezési feladatok gráfja - várakozási gráfok patthelyzet detektálásánál - objektumosztályok alosztály szerkezete Gyakran használt részosztálya a gráfoknak Körmentesség ellenőrzése: Ha egy mélységi bejáráshoz van a bejárás sorrendjéhez képest visszafelé mutató él, akkor a gráfban van kör. Ha van egy mélységi bejárás, amihez nincs visszamutató él, akkor a gráf körmentes.
72
33. Gráfok II. (Kruskal algoritmus és alkalmazásai) Feszítőfák, minimális feszítőfa: Definíció: Legyen G=(V,E) összefüggő irányított gráf. Az F=(V,E’) részgráf (E’≤E) a G feszítőfája, F összefüggő és körmentes. Minimális költségű feszítőfa: ha az éleinek összsúlya minimális a feszítőfák között. (A mélységi bejárások is feszítőfát adnak, ezek a mélységi feszítőfák.) Alkalmazás: hálózatok kiépítésénél (villany, adatátvitel stb.). Az első alkalmazás 1926-ban volt. Minimális feszítőfa megadásának algoritmusai: Piros-kék algoritmus Az algoritmus során a G éleit pirosra vagy kékre színezzük. A kék élek kerülnek a minimális feszítőfába, a pirosak nem. Az algoritmus végén minden élt kiszínezünk. A kék élek alkotják a feszítőfát. Két színezési szabályt használunk. Egy élt csak akkor festünk be, ha a szabályok egyike alkalmazható. 1. Kék szabály: válasszunk ki egy olyan 0≠X csúcshalmazt (ami V részhalmaza), amiből nem vezet ki kék él. Ezután egy kisebb súlyú X-ből kimenő színezetlen élt színezzünk kékre. 2. Piros szabály: válasszunk G-ben egy olyan egyszerű kört (minden pontját csak egyszer járja be), amiben nincs piros él. A kör egyik legnagyobb súlyú színtelen élét fessük pirosra. Az algoritmus nem adja meg a szabályok választásának sorrendjét. A hatékony algoritmus a sorrend ügyes megválasztásán múlik. Ilyen a Kruskal algoritmus. Kruskal algoritmusa minimális feszítőfára: A feszítőfa következő élét a még fel nem használt élek közül az elfogadható minimális súlyú élének választjuk. Ha egy a megmaradtak között minimális súlyú él kört képez a feszítőfába eddig választott élekkel, eldobjuk. Ha nem képez kört, hozzávesszük a feszítőfához (hozzá vétel: kék szín, eldobás: piros szín). Speciális adatszerkezet használatával a Kruskal algoritmus költsége O(e log e), ahol e az élek száma: e=|E|
73
34. Gráfok III. (topológiai rendezés és alkalmazásai) Irányított
körmentes gráf:Irányított kört nem tartalmazó irányított gráf; ami azt jelenti, hogy egyetlen v csúcsához sincs v-ből induló és ugyanott végződő irányított út.
Az irányított körmenetes gráfok topologikus rendezése: Definíció: A G=(V,E) (|V|=n) irányított gráfnak egy topologikus rendezése a csúcsoknak egy olyan sorrendje: v 1, v 2, … , v n , hogy x i x j ∈ E esetén i<j teljesül. Tehát a topológiai rendezés egy részben rendezést teljes rendezéssé egészít ki. Tegyük fel, hogy valamilyen folyamatban a feladatok időrendi precedenciájára vonatkozó szabályaink vannak, amelyet az R részben rendezési reláció fejez ki. Ennek lezárása teljes rendezéssé – ezt nevezik topológiai rendezésnek – megadja a feladatok elvégzésének olyan lehetséges ütemezéseit, amelyek a kezdeti feltételeket kielégítik. Más szavakkal: legyen az S körök nélküli irányított gráf (vagy részlegesen rendezett halmaz). Az S topológiai rendezése, amelyet T-vel jelölünk, lényegében az S pontjainak olyan lineáris rendezése, amely megőrzi az S eredeti részleges rendezését. Ha tehát: u < v az S-ben (azaz ha az S-ben létezik út az u-ból a v-be), akkor a T lineáris rendezésben az u a v előtt áll. Tétel: Egy irányított gráfnak akkor és csak akkor van topologikus rendezése, ha irányított körmentes gráf. A körök nélküli gráf topologikus rendezését megadó algoritmusnak az a fő elve, hogy a rendezés első elemeként bármelyik zérus „be”-fokú, azaz előző csomópontok nélküli pontot kiválaszthatjuk. Ennek megfelelően az algoritmus addig ismétlődik, amíg a gráf üressé válik. Tehát egy irányított körmentes gráf topologikus rendezésének megadása a következő: - van olyan pont, amibe nem vezet él (különben az éleken visszafele haladva lenne kör). Ez v1. Elhagyjuk a kivezető élekkel együtt. - a megmaradt gráf is irányított körmentes gráf, ismételjük ugyanezt a lépést a következő pont megadására. Alkalmazása: tegyük fel, hogy egy programban a nem rekurzív függvényhívásokat egy G gráf írja le. Célunk, hogy a függvényeket olyan sorrendben elemezzük, hogy egy függvény elemzésekor az általa hívott függvényeket már áttekintettük. Megoldás: postorder (fordított topológiai) rendezés. Mindig szükséges azonban az a ciklus teszt a rekurzivitás felderítésére. További alkalmazások: az irányított körmentes gráfokat sokféleképp használja a számítástudomány: 3. Bayes-hálók 4. A szemétgyűjtő algoritmusok általában DAG-okkal tartják nyilván a referenciákat 5. Parancs-ütemezés és makefile-ok függőségi gráfja 6. Objektum orientált programozási nyelvekben az öröklődéssel létrehozott osztályok függőségi gráfjai 7. Irányított körmentes szó-gráfok használhatóak string-halmazok (szó-halmazok) memóriatakarékos tárolására
74
35. Hasító táblázatok (alapelvek, hasító függvények, kulcsütközések feloldása) A hasító táblázat a tömb fogalom általánosítása. A tömbelemek közvetlen címzése O(1) idő alatti elérést tesz lehetővé, amennyiben ismerjük a keresett elem helyét. A cél egy olyan adatszerkezet megvalósítása, amely a kulcs alapján egyszerűen meghatározza a szükséges indexet. Elsőként azt feltételezzük, hogy létezik olyan, n darab rekordból álló F állomány, amelyben a K kulcsértékek halmaza egyértelműen meghatározza a rekordokat. Feltételezzük továbbá azt is, hogy a memóriában m darab memóriahelyből álló T tábla tárolja F-et, I pedig a T-ben levő memóriahelyek címének halmazát jelenti. A jelölésbeli szokásokhoz igazodva rögzítjük azt is, hogy a K-ban levő kulcsok és az I-ben levő címek decimális egész számok.
Tehát - Kulcshalmaz (K): a lehetséges kulcsok halmaza. Legyen n=|K| - Indexhalmaz (I): a lehetséges indexek halmaza. Legyen m=|I| és legyen I={0…m-1} egész számok - Kulcstranszformációs (hasító) függvény: H: K I egy leképezés, amely a kulcs alapján megadja a keresett indexet. - Az elemeket fizikailag egy T tömbben tároljuk. Mérete az indexhalmaznak megfelelő. Közvetlen címzés: Amennyiben az elemek kulcsai a {0…m-1} univerzumból valók, és m nem túl nagy, alkalmazhatjuk a közvetlen címzést. Ebben az esetben a kulcs maga a T-beli index. Feltételei: - Fentieknek megfelelő kulcshalmaz - Kis méretű kulcshalmaz - Nincs két egyforma kulcsú elem A közvetlen címzés általában nem valósítható meg: - A kulcshalmaz nagy mérete kezelhetetlen méretű tárkapacitást igényelne. - Az aktuálisan tárolt elemek száma a K-hoz képest nagyon kicsi lenne. Megoldás: Az I elemszáma legyen jelentősen kisebb, mint a K halmaz elemszáma. Vagyis hasítófüggvények alkalmazása. Hasítófüggvények: Előnye: ha a szótárban valóban tárolt elemek darabszáma jelentősen kisebb, mint a lehetséges kulcsok K halmaza, akkor a hasító táblázat jóval kevesebb memóriát foglalhat. Sajnálatos módon azonban így a H hasítófüggvény nem garantálja az egyedi értékek képzését, mivel előfordulhat, hogy két különböző kulcsértékhez ugyanaz a hasítócím tartozik. Ezt a helyzetet összeütközésnek nevezzük.
75
A választott hasítófüggvénynek mindig az adott feladatnak megfelelőnek kell lennie, de megadható néhány általános szabály: - Egyenletesen ossza szét a kulcsokat. - Véletlenszerűen ossza szét a hasonló kulcsokat - Kevés ütközést produkáljon - Egyszerűen kiszámolható legyen Természetesen nincs garancia arra, hogy a kulcsok és a címek előzetes ismerete nélkül teljes mértékben ki lehet majd elégíteni a második feltételt. Bizonyos általános módszerek azonban feltétlenül segítséget jelentenek. Az egyik ilyen módszer, hogy a k kulcsot valamilyen módon részekre darabolva alakítjuk ki a H(k) hasítócímet. Hasítófüggvények létrehozásának módszerei: 1. Osztásos módszer. Válasszunk ki egy olyan m számot, amely nagyobb mint a K-ban levő n darab kulcs mennyisége. (Az m számot rendszerint úgy célszerű megválasztani, hogy prímszám vagy kis értékű, osztók nélküli szám legyen, mivel íly módon minimalizálhatjuk az összeütközések előfordulását.) Ebben az esetben a következőképpen definiálhatjuk a H hasítófüggvényt: H(k)=k(mod m) A k(mod m) azt a maradékot jelöli, amely a k-nak m-mel való osztásakor keletkezik. 2. Középnégyzet módszer. A k kulcsokat négyzetre emeljük, majd mindkét végéről töröljük a számjegyeket. Tehát: H(k)=KözepeM(k*k) (A KözepeM adja vissza k*k középső M darab helyi értékét.) 3. Hajtogatásos (jel-kód) módszer. A k kulcsot bizonyos számú részre k 1, k 2, … , k r osztjuk, és közben figyelünk arra, hogy valamennyi rész — az utolsót esetleg kivéve — ugyanannyi számjegyből álljon, mint a szükséges cím. Ezt követően a legutolsó maradék elhanyagolásával összeadjuk a részeket: H k =k 1k 2…k r 4. Univerzális hasítási technika. Az előzőleg megismert módszerek esetén, ha a paraméter előre rögzített, akkor könnyen megállapítható n darab kulcs, amelyek mind ugyanoda képződnek le. Hatásos módszer, ha a hasítófüggvény a kulcsoktól független módon véletlenül választjuk ki. Általános esetben kielégítő eredményt ad, és elkerüli a legrosszabb esetet. 5. Összetett kulcsok. Összetett kulcsok esetén általánosan jól használható módszer nem állapítható meg. Általában célszerű az összetett kulcsot megfelelő byte-méretű darabokra vágni, majd ezeket a darabokat számként kezelve valamelyik előzőleg ismert transzformációt alkalmazni. Amennyiben ismert a kulcs felépítése (vagy tapasztalati úton megállapítható) célszerű lehet súlyozni az egyes darabokat. Kulcsütközések feloldása: Tegyük fel, hogy az I állományhoz a k kulcsértékű új rekordot akarjuk hozzákapcsolni, a H(k) memóriahely azonban foglalt. Ezt a helyzetet összeütközésnek nevezzük. Az alábbi módszereket alkalmazhatjuk az ütközések feloldására.
76
1. Nyitott címzés: lineárispróba és módosítás – Beszúrás: tegyük fel, hogy a T memóriatáblához a k kulcsértékű R rekordot akarjuk hozzákapcsolni, de már foglalt a H(k)=h hasítócímű memóriahely. Az összeütközés feloldásának egyik magától értetődő módja, hogy a T[h]-t követő első szabad helyhez rendeljük az R-et. – Keresés: az összeütközést feloldó eljárásban a T[h], T[h+1], T[h+2], … helyek lineáris keresésével kaphatjuk meg a T tábla R rekordját. A műveletet addig kell végezni, amíg üres helyet nem találunk. Ez viszont a sikertelen keresést jelenti. – Törlés: keresés után az elem bejelölése töröltnek. 2. Láncolás: a láncoláshoz két táblát kell fenntartani a memóriában. A korábbiakhoz hasonlóan most is van egy T tábla, amely az I rekordjait tartalmazza, de a T-ben ezúttal egy olyan mező is helyet kap, amely láncolja az azonos h hasítócímű rekordokat, vagyis kapcsolt listát alakít ki ezekből. A második tábla a T kapcsolt listáinak mutatóit tartalmazza. Tegyük fel, hogy az I állományhoz hozzákapcsoljuk a k kulcsú új rekordot. Az új rekordot a mutató segítségével csatoljuk a kapcsolt listához.
3. Másodlagos kulcs/kettős hasítás Használjunk két hasító függvényt (H1,H2). – Beszúrás: ha a H1 kulcstranszformációs (hasító) függvény alkalmazásával kulcsütközés lépne fel, próbáljuk egy másik H2 függvénnyel, ami máshova képez. – Keresés: ha H1 által megadott helyen nem találjuk a keresett elemet, keressük H2 szerint is. – Törlés: a fenti kereséssel megtalált elemet töröljük. 4. Hierarchikus módszer: összetett kulcs esetén komponensenként definiáljunk egy transzformációs függvényt. Az utolsó kivételével ezek nem egy elemre, hanem egy táblázatra mutatnak, ahol újabb hasítással léphetünk tovább. 5. Blokkolt adattáblák: a kulcstranszformációs (hasító) függvény nem egy elem címét, hanem több elemet tartalmazó blokkot határoz meg. Amennyiben ez a blokk betelik, hozzáláncolható egy következő.
77
Szoftverfejlesztés lépései
78
36. A szoftver jellemzői (a termék elállítás jellemzői, hibaaránygörbék, költségösszetevők, költségarányok) A rendszerköltségen belül a hardver / szoftver arány változása:
A szoftver drága: A szoftverfejlesztés tradicionális fázisai: - Analízis - Tervezés - Implementáció - Tesztelés - Követés Míg az első 4 a szoftverfejlesztés 1/3-át teszi ki, addig a követés a maradék 2/3. Ezen belül a javítás, és az adaptáció 2*1/6 rész, és a továbbfejlesztés 2/3-ad. Követés nélkül 1/3-ad rész az analízis és tervezés, 1/6-od a kódolás, és ½ a tesztelés. A szoftverprojektek 31%-át „lelövik” mielőtt elkészül! A szoftverprojektek 53%-a 90%-kal túllépi az előre tervezett költségeket! 9%a a nagy, és 16%-a a kis szoftverprojekteknek nem készül el határidőre! A szoftverprojektek 56%-a már az analízis fázisában elcsúszik!
79
37. A szoftverkrízis (előzmények, tünetek, okok, megoldások)
A szoftverkrízis A szoftverek 2%-a azonnal ment 3%-a javítás után ment 20%-a alapos átdolgozás után ment 45%-a soha nem ment rendesen 30%-a soha nem ment, de kifizették Előzmények: A mai fogalmak szerint gyenge hardver. Gyenge fejlesztői szoftver ellátottság. Monolitikus programozás. Nehezen becsülhető előre a szükséges erőforrás mennyisége, Nehezen határidőzhető a feladat, Körülményes a team-munka, nem teljes körű a tesztelés, Nagyon nehézkes a program módosítása, bővítése és a Személyiség függő programok. Tünetek: Megbízhatatlanok a szoftverek, Nehezen alkalmazkodnak a konfiguráció változásához, A fejlesztés nehézkes (részprogramok összeállítása nehézkes, körülményes a tesztelés, nem hatékony a team-munka), Nem informatívak a szoftverek (nincs korrekt hibajelzés, merev input oldal, stb.). Okai: A minőségi követelmények változása (pl.: Felhasználóbarát felület, Feltétlen megbízhatóság, Könnyű karbantarthatóság, Könnyű továbbfejleszthetőség). A szoftverek méretének növekedése maga után vonta a komplexitás növekedését (min. négyzetes az összefüggés). A fejlesztési módszerek nem tartottak lépést a változással. A felhasználói környezet változása (a felhasználók száma, felkészültsége, az alkalmazási körülmények gyökeresen megváltoztak). Megoldás: A szoftverkészítés technologizálása, Új elvek, módszerek és eszközök kifejlesztése (CASE), Szoftverszabványok bevezetése, szoftver minőségbiztosítás, valamint Új programozási paradigmák alkalmazása. Új programozási Paradigmák: Moduláris programozás, Strukturált programozás, Objektum-Orientált programozás. A szoftver jellemzői: - A hagyományos termékek készítésének folyamata: Analízis, vázlatos tervezés, részletes tervezés és fizikai megvalósítás. Hibaarány görbe:
A gyerekbetegségek okai: tervezési-, gyártási-, szerelési hibák, hibás anyagok, IC-k, stb. Az elkopás okai: öregedés, hőmérsékleti-, mechanikus-, környezeti behatások. - A szoftver termékek esetében: A szoftver termék esetében eltérő a megvalósítás fázisa. Nincs „átültetés” az anyagba, Nem kell figyelembe venni a tervezés során az Anyagjellemzőket és a Megmunkálási módok jellemzőit. A szoftver „nem kopik el”. Hibaarány görbe (ideális, és a változásokat is figyelembe véve:):
A változtatások újabb hibákat eredményeznek, melyek a termékben összegződnek.
80
38. A szoftverfolyamat modelljei I. (modelltípusok, a modellezési koncepció, célok, a vízesés modell)
A szoftver életciklus modelljei: A szoftverfolyamat modellje a szoftverfolyamat absztrakt reprezentációja egy adott speciális aspektusból. Szokásos típusai lehetnek: - Munkafolyam modell (tevékenységek sorrendje, bemenetei, kimenetei, függőségei) - Az adatfolyam vagy tevékenység modell (mindegyik tevékenység valamilyen adattranszformációt hajt végre. Azt reprezentálja, hogyan alakul át a folyamat bemenete kimenetté az emberek, vagy számítógépek által végrehajtott tevékenységek során). - A szerepkör / cselekvés modell (a szoftverfolyamatban résztvevő emberek szerepköreit és felelősségüket ábrázolja.) Mit nevezünk modellnek?: rendszer megértést segítő absztrakció amely elhanyagolja a lényegtelen részleteket. A modell kizárólag az eredeti rendszer lényegi elemeit tartalmazza. A modellek különböző célokat szolgálhatnak: - a komplexitás csökkentése - kommunikáció az ügyféllel - a rendszer vizsgálata megépítése előtt - vizualizálás A szoftverfolyamatok osztályozása: - Vízesés modell - Evolúciós fejlesztés - Formális rendszerfejlesztés - Újrafelhasználás alapú fejlesztés
A vízesés (waterfall) modell Hagyományos szemléletű, erősen szeparált fázisokat tartalmazó modell. Az eredeti vízesés modellt 1970-ben W. W. Royce publikálta. A fázisokat nem éles határvonal választja el! Jellemzők: - szisztematikus, szekvenciális, top-down modell - a hagyományos mérnöki szemléletet követi - leginkább elterjedt (legrégibb) modell Problémák: - a valós projektek ritkán követnek szekvenciális modellt - nehezen valósítható meg az iteráció - az egész modell a specifikáció minőségétől függ - a projekt elején meglévő kezdeti bizonytalanságot nem tudja kezelni - nagyon későn lát a megrendelő működő programot Előnyök: - modellt ad a különböző fázisokhoz tartozó - módszerek elhelyezésére - logikus, könnyen érthető, kézenfekvő modell - sok tapasztalat halmozódott fel
81
39. A szoftverfolyamat modelljei II. ( az evolúciós modell, a formális rendszerfejlesztés)
Az evolúciós modell Egy kezdeti implementációt (prototípust) a felhasználókkal véleményeztetünk és sok-sok verzión keresztül addig finomítjuk, amíg a megfelelő rendszert el nem érjük. A prototípus készítés folyamata: kommunikáció, gyors tervezés (modellezés, gyors megvalósítási terv), prototípus készítés, prototípus véleményezés, és újra elölről. Ez kellemes a felhasználónak, de veszélyes a programozónak. Prototípus típusok: - Termék prototípus: elkészítjük a program vázlatát jól, de pl. a menüpontnál kijön: „fejlesztés alatt” - Rész-prototípus: valamilyen algoritmust tesztel le - Interfész prototípus: Az elkészült menüket, program részleteket, stb. felhasználhatjuk a későbbi programjaink során. Az evolúciós fejlesztés modellje:
Az evolúciós fejlesztések típusai: - Feltáró fejlesztés - Eldobható prototípus készítése Problémák: - A folyamat nehezen menedzselhető - A rendszerek struktúrája nem megfelelő - Minőségbiztosítási problémák: nem egy jól letesztelt, dokumentált rendszer! - Speciális eszközök és technikák igénye Az így elkészített modellt nagyon át kell nézni, és dokumentálni!
82
Formális rendszerfejlesztés A formális rendszerfejlesztés jellegében a vízesés modellhez hasonlít. Lényege a specifikáció futtatható formába transzformálása formális matematikai eszközökkel. Specifikáció: valamilyen típusú leírás. A leglényegesebb különbségek a vízesés modell és formális modell között: 1. A követelményspecifikáció részletes matematikai jelölésekkel leírt formális specifikálás (Itt egy matematikai formalitást kell alkalmazni). 2. A tervezés, implementáció, egységteszt egy transzformációs folyamat (a formális specifikáció transzformációk során programmá válik). A formális rendszerfejlesztés fázisai:
A formális transzformáció menete:
A transzformációs folyamat során a kezdeti formális specifikáció transzformálódik egyre jobban kifejtett, de matematikailag korrekt rendszerreprezentációvá. Minden egyes lépés további finomítás mindaddig, amíg a formális Specifikáció vele ekvivalens programmá nem válik. A formális modell előnyei: - A transzformációk korrektek, így könnyű a verifikációjuk, a sok kis lépés után a program lényegében a specifikáció szisztematikus transzformációja. - Annak bizonyítása, hogy a program megfelel a specifikációnak, más paradigmákkal szemben itt egyszerű, hiszen sok kis ellenőrzéssé csökken a transzformációk során. - Használata nagyon előnyös olyan rendszerek, vagy részrendszerek esetében, ahol elsődleges a rendszer biztonsága, megbízhatósága és annak autentikus bizonyítása.
83
40. A szoftverfolyamat modelljei III. (újrafelhasználás orientált fejlesztés, inkrementális fejlesztés, RAD modell)
Újra felhasználás-orientált fejlesztés Tisztázandó kérdések: - Mi az újrafelhasználás - Mi az előnye az újrafelhasználás-orientált fejlesztésnek: hatékonyság növelése, pénz spórolás - Mi az, ami újra felhasználható: program-rész, algoritmus, teljes program, adatbázis, stb.. - Az újrafelhasználás formái (tervezett, nem tervezett): nem tervezett: nem testelem alaposabban, nem dokumentálom. Ez az előnye, de egyben ez a hátránya is. Tervezett: sokkal szélesebb körben tesztelem, dokumentálom. A nyelvfüggő részeket eltüntetem belőle. - Az újrafelhasználás költség-komponensei Az újrafelhasználás mértéke:
Minél kisebb az elem mérete, annál gyakrabban tudom felhasználni. Minél nagyobb az elem, annál többet érhet később. Ez a tervezett újrafelhasználásnál jelentkezik. Az újrafelhasználás-orientált fejlesztés folyamata:
Folyamatiteráció: – –
Inkrementális fejlesztés (a specifikáció, a tervezés, az implementálás kis inkrementális lépésekben valósul meg). Spirális fejlesztés (belülről kifelé tartó spirálvonalat követ a fejlesztés).
84
Inkrementális fejlesztés – – – – –
Mills ajánlotta 1980-ban Cél az átdolgozások számának csökkentése a fejlesztési folyamatban. Lehetőséget ad a megrendelőnek bizonyos a követelményekkel kapcsolatos döntések későbbre halasztására. A fejlesztés jól meghatározott inkremensekben történik. Ha egy inkremens elkészül, átadásra kerül, azt a megrendelő akár használatba is veheti.
Az inkrementális fejlesztés modellje:
Előnyei: - A (félkész) szoftver már menetközben használhatóvá válik a megrendelő számára (kritikus követelmények teljesülnek először) - A megrendelők használhatják a korábbi inkremenseket, mint prototípusokat a későbbi inkremensekhez - Kisebb a kockázata a projekt kudarcának, biztonságos fejlesztés - A legkritikusabb funkciókat teszteljük legtöbbet (azok készülnek el először)
A RAD Modell (Rapid Application Development) – – – – – – – – – –
J. Martin publikálta 1991-ben Inkrementális modell Kifejezetten rövid fejlesztési ciklus (60-90 nap) „High-speed” adaptációja a vízesés modellnek A nagy sebesség a „komponens alapú szerkesztés” , „szoftver újrafelhasználás”, „automata kód generálás” technikák alkalmazásával érhető el. Különböző teamek dolgoznak párhuzamosan a tervezés fázisától a különböző funkciókon A team tagjainak sokoldalúnak kell lennie A megrendelő szakemberei is részt vesznek a teamek munkájában Modern fejlesztői környezetet használ RAD-et támogató tool-ként hirdetik magukat: – Microsoft Visual Studio .NET – Sun Java Studio Creator – BEA Web Logic Workshop – Borland C# Builder – IBM WebSphere Studio Application Developer
85
A RAD vázlatos modellje:
Problémák: - Nagy projektek esetén nagy a humán erőforrás igény az elegendő számú RAD-team felállításához - Ha a rendszer nehezen modularizálható, a komponensek elkészítése problematikus - Magas műszaki kockázat esetén a RAD nem működik biztonságosan
86
41. A szoftverfolyamat modelljei IV. (spirális fejlesztés, Agile Software Processes, XP)
A Boehm-féle spirál modell Boehm publikálta 1988-ban. A valós fejlesztést jól követő modell. Ez az első modell amely a kockázatokat is belevette! A spirál minden ciklusa négy szektorra bontható: 1. Célok kijelölése (célok, alternatívák, megszorítások, kockázatok meghatározása 2. Kockázat becslése, csökkentése (kockázat elemzés, kockázati tényezők csökkentésére intézkedés kidolgozása 3. Fejlesztés és validálás (a következő szintű termék fejlesztése, a kockázat analízis eredményének függvényében fejlesztési modell választása 4. Tervezés (a következő fázis, ciklus megtervezése).
„Agile Software Pocesses” - Agilis szoftver fejlesztés 2001-ben 17 neves szoftver fejlesztő alapította meg az „Agile Allience”-t és fogalmazta meg a „Manifesto for Agile Software Development”-et. A legfontosabb elvek: – Első rendű szempont a megrendelő maradéktalan kielégítése – Flexibilitás a követelmények változásával szemben – Működő szoftver gyors átadása (inkrementálisok) – Az üzleti szakembereknek és a fejlesztőknek napi kapcsolatban kell lenniük – Motivált szakembereket gyűjts a projekt köré, teremtsd meg a feltételeket a munkájukhoz – Szorgalmazd a szemtől-szembeni párbeszédet a teamen belül az információ cserére – A haladás legjobb mértéke a működő szoftver – „Agile process” fenntartható fejlődést ösztönöz – A fejlesztőknek és a megrendelőnek egy állandó ütemet kell fenntartani a fejlesztési folyamatban – A kiváló műszaki színvonalra és a jó tervre folyamatosan ügyelni kell – Egyszerűség – csak az igazán fontos feladat elvégzése – Az önszerveződő, aktív teamektől származnak a legjobb megoldások (szerkezetekre, követelményekre, tervekre) – Rendszeres időközönként a teamnek önvizsgálatot kell tartani és viselkedését esetleg módosítani Ezen elveket követő módszerek: - Extreme Programming (XP) - Adaptive Software Development (ASD) - Dynamic Software Development Method (DSDM) - Scrum - Crystal - Feature Driven Development (FDD) - Agile Modeling (AM)
Extrém programozás (XP): Beck publikálta először 1999-ben. Inkrementális megközelítés OO alapon. Ajánlott szabályok és praktikumok. 4 alapvető aktivitás: – Planing (tervezés) – Design – Coding (kódolás) – Testing (tesztelés) A változtatás költségeinek alakulása:
87
42. A szoftver projekt ütemezése Az ütemezéshez ismerni kell: - A tevékenység egységeket - Időigényüket - Erőforrásigényüket - Függőségeiket - A folyamatok, részfolyamatok sorrendiségeit - A párhuzamosítható tevékenységeket - Egyéb korlátokat, illetve peremfeltételeket Ökölszabályok: - Ha a tevékenység 8-10 hetet meghaladna, szét kell bontani - Mindig tervezzünk tartalékot a nem várt problémákra (30- 50%)
A projekt ütemezés folyamata:
A projekt ütemterv ábrázolásának lehetőségei: - Oszlopdiagramok (Tevékenység diagramok): Tartalmazza az adott tevékenység felelősét (munkavégzőjét) és a tevékenységek kezdési és befejezési időpontjait. - Tevékenységhálók: A tevékenységek közötti függőségeket ábrázolja.
88
Egy hagyományos szoftver projekt ütemezése
A projektidő alakulása a résztvevők számának függvényében
Ütemezési módszerek: - PERT (Program Evaluation and Review Technique) - CPM (Critical Path Method) Lehetővé teszik: - kritikus út meghatározását - a feladatok legvalószínűbb idő-ütemezését - idő-ablakok meghatározását (legkorábbi, legkésőbbi befejezés / kezdés, indítási idő-intervallumok)
89
43. Szoftver projekt mérése A szoftver mérése a szoftver mint termék, illetve a szoftver készítési folyamat szignifikáns jellemzőinek számszerűsítésével foglalkozik (szoftver metrikák). A szoftver metrikák lehetnek: - Vezérlési metrikák (a szoftver folyamattal kapcsolatosak, pl: hibák száma, ráfordítások, idők) - Prediktor metrikák (a szoftver termékkel kapcsolatosak, pl: a modul ciklomatikus komplexitása) A vezetői döntéshozatalt mindkét típus befolyásolhatja A mérés célja: A mérések több célt szolgálhatnak: A termék mérése esetén: a termék minőségének értékelése A folyamat mérése esetén: - az alkalmazott módszerek, eszközök hatékonyságának értékelése - a fejlesztők termelékenységének elemzése - a következő projektek becslési fázisához bázis-értékek kialakítása, a meglévő értékek javítása.
A mérések kategorizálása Mi az amit mérünk: - Műszaki jellemzők mérése: Modularitás foka, logikai komplexitás, stb. - Minőség mérése: Mennyire közelíti meg a specifikációt a termék - Termelékenység mérése: A termelési folyamat értékelése Hogyan mérjük: - Méret-orientált mérési módszerek: Mennyiségi és minőségi adatok közvetlen gyűjtésén és kiértékelésén alapuló módszer - Funkció-orientált mérési módszerek: Közvetett mérési módszer elvonatkoztatott szempontok alapján (hipotetikus változók bevezetése). - Ember-orientált mérési módszerek: A fejlesztők véleményének értékelésén alapuló módszer.
Méret-orientált mérési módszer Közvetlen mérési módszer, a mérés tárgya az elkészült termék és a készítés folyamata.
Termelékenység=
KLOC Ráfordítás
Minőség=
Ráfordítás Hibák száma
Fajlagos doku=
Fajlagos költség =
Költség KLOC
Doku KLOC
A módszer jellemzői: - mennyiségi mérőszámokon alapuló egyszerű módszer (oldalak száma, sorok száma, emberek száma, stb.) - nem igényel tapasztalatot, szaktudást a kiértékelés - nem veszi figyelembe a komplexitást, a szoftver sajátosságait - csak azonos típusú projektek összehasonlítására, becslésére használhatók fel a mérőszámok
Funkció-orientált mérési módszer A „LOC számolása” helyett a szoftver funkcionalitása kerül előtérbe. A módszer alkalmas a komplexitás kezelésére. A Function Point (FP) valamilyen számszerűsíthető jellemzőből származtatható. Tipikus jellemzők, melyeket a módszer alapul vesz: - felhasználói inputok száma (adat) - felhasználói outputok száma (adat) - felhasználói interakciók száma (vezérlés) - fájlok száma - külső interfészek száma (pl.: hálózat) A módszer lépései: 1., A számértékeket tartalmazó táblázat kitöltése. 2., A komplexitás értékelése Módszer: 14 kérdésre adandó 0..5 értékű, osztályzat jellegű válasz összege adja a SUM(Fi), a komplexitást kifejező tényezőt. (max. érték = 70)
90
∑ Fi ]
3., A táblázat és a válaszok alapján FP meghatározása: FP=[Teljes összeg ]∗[0.650.01∗ A komplexitástól függően a [teljes összeg] 0.65 ... 1.35 -tel módosulhat.
Termelékenység=
FP Ráfordítás
Minőség=
Ráfordítás Hibák száma
Fajlagos doku=
Fajlagos költség=
Költség FP
Doku FP
Jellemzők: - adat alapú, ami azért előnyös, mert az adatok a fejlesztés korai szakaszában már ismertek, míg a LOC csak a végén - programozási nyelv független - részben szubjektív - a LOC alapúval szemben az értékelés szaktudást, tapasztalatot igényel
Objektum-orientált mérési módszer Az OO projektek esetén is alkalmazható pl. az FP alapú mérési módszer. Javasolt paraméterek: - A szcenáriók száma (a felhasználó és az alkalmazás közti interakciókat írják le – erősen korrelál az alkalmazás méretével) - Kulcs osztályok száma ( az OO analízis korai szakaszában már definiált, erősen független osztályok – korrelál a számuk a rendszer kifejlesztéséhez szükséges ráfordítással, a szükséges tesztesetek számával - Támogató osztályok száma (nem tartoznak közvetlenül a rendszer probléma specifikus funkcióihoz pl. UI osztályok, szerviz osztályok – számuk jó indikációt ad a rendszer kifejlesztéséhez szükséges ráfordításra, és a újrafelhasználás lehetőségére. - A kulcs osztályokat támogató osztályok átlagos száma GUI alkalmazás esetén a támogató/kulcs osztály arány 2-3, nem GUI alkalmazás esetén 1-2 (mivel a kulcs osztályok már az analízis korai fázisában ismertek, így következtethetünk a teljes alkalmazás méretére - Alrendszerek száma – a rendszer komplexitásának jó indikátora
Use-Case-orientált mérési módszer Potenciális előnyök a use-case-ek metrikákban történő felhasználása esetén: - A szoftver folyamat korai szakaszában rendelkezésre állnak - A rendszer funkcionalitását (legalább a felhasználó oldaláról) jól jellemzik - Programozási nyelvtől, környezettől függetlenek - Számuk arányos a rendszer nagyságával és a szükséges tesztesetek számával Problémák, ami miatt még nincs széleskörű használat: - A use-casek mérete, bonyolultsága nem szabványosított, és erősen függ az alkalmazott absztrakciós szinttől - Nehéz megadni a use-case / ráfordítást
91
44. Programozás, tesztelés, szoftverevolúció (a belövés folyamata, szoftvervalidáció, tesztelési folyamat, fázisok, dokumentumok, az evolúció folyamata)
Szoftvervalidáció (tesztelés) A tesztelési folyamat szakaszai: - Egység teszt (a rendszerkomponensek egymástól független tesztelése [tesztágy szükségessége]). - Modul teszt (az egymástól függő komponensek egységbe zárt rendszerének önálló tesztelése). - Alrendszer teszt (az alrendszert alkotó modulok egymás közötti kapcsolatának ellenőrzése [tipikus az interfész probléma]) - Rendszer teszt (az alrendszerek integrált egysége az alrendszer. Tesztelése során az alapvető rendszertulajdonságok vizsgálata történik). - Átvételi teszt (a rendszer tesztelése valódi adatokkal, az előre rögzített validációs kritériumok teljesülésének ellenőrzése). A szoftver tesztelési folyamat:
92
A tesztelési fázisok a szoftver folyamatban:
Az átvételi tesztet szokás „alfa tesztnek” is nevezni. Egyedi megrendelő esetén az alfa teszt a megrendelő bevonásával történik. Nem egyedi szoftverek esetében az alfa tesztet általában egy béta teszt is követi.
Szoftverevolúció (szoftver karbantartás, szoftver követés) A hagyományos szemlélet szerint a fejlesztés és a karbantartás két élesen elkülönülő tevékenység. Az újabb felfogás szerint a kettő szerves egységet alkot és inkább a szoftver evolúciójának fogható fel. A rendszer evolúciójának folyamata:
93
45. Projekt becslés (általános fogalmak, dekompozíción alapuló technikák, tapasztalati becslési modellek, becslési bizonytalanság) A becslés tárgya: - ráfordítás - költség - időtartam A becslést nehezítő tényezők: – a projekt nagysága, komplexitása – Időkorlát – erőforráskorlát - emberi (mennyiségi, minőségi) - hardver (speciális egységek: analizátor, stb.) - szoftver eszközök A becslési technikák csoportosítása: - Dekompozíción alapuló technikák • LOC vagy FP orientált • ráfordítás becslés - Tapasztalati becslési modellek
Dekompozíción alapuló technikák Mindegyik technika alapja a bonyolult, nagy rendszer szétbontása kezelhető részekre. A kiindulás minden esetben a feladat vázlatos, lehetőleg számszerűsített leírása (scope).
I. LOC vagy FP orientált technikák Lépései: A., Meghatározzuk az egyes modulok LOC-ját (három értéket adunk meg: optimista, valószínű, pesszimista) B., Képezünk modulonként egy súlyozott átlagot optimista + 4 x valószínű + pesszimista
E=
optimista4∗valószínű pesszimista 6
C., Kitöltjük a táblázatot D., Meghatározzuk a becsült költség és ráfordítás értékeket: Az eltérő súlyok a különböző modultípusok komplexitáskülönbségeit fejezik ki. Az értékek az előző projektek méréseiből származnak és projektenként finomíthatók. A módszer jellemzői: - A LOC orientált részletesebb, finomabb felbontást igényel, - Az FP orientált nagyobb, komplexebb egységeket képes kezelni. - A módszer nagy tapasztalatot, jó „érzéket” kíván, hiszen a projekt elején tényszámok nincsenek, - A becslésnél nagy a bizonytalanság.
II. Ráfordítás becslés Módszer: Egy „rutinos öreg róka” megbecsüli az egyes tevékenységek ember-hónap ráfordítás igényeit minden modul esetében. A kiindulás ennél a módszernél is a projekt vázlatos leírása. A módszer jellemzői: - A különböző komplexitású modulok különböző súllyal szerepelnek - Az egyes tevékenységek súlyozása eltérő - Igen nagy rutint igényel (indirekt becslés), jól kell ismerni a rendszer típusát és a fejlesztőcsapatot - Jól használható az előző módszer kontrolljaként
Tapasztalati becslési modellek Jellemzőik: - Általában méretből indul ki - Tartalmaz exponenciális komponenst a méret – komplexitás viszony kifejezésére - Az algoritmus miatt nem okvetlenül pontos a becslés, nagyban függ a paraméterek jó becslésétől - általános formája:
94
A becslési bizonytalanság
95
46. Projekt menedzsment, projekt tervezés (a menedzsment kérdései, a projekt elkészítése, a terv típusai, a tervkészítés folyamata, a terv szakaszai, mérföldkövek a folyamatban)
Projekt menedzsment A projekt menedzsment fő területei: - Projekt tervezése - Projekt ütemezése - Projekt mérése - Projekt becslése - Kockázat menedzsment, kockázat kezelés - Projekt követés és ellenőrzés - Team-szervezési megoldások Mi a projekt? - Jól definiált cél - Előre rögzített határidő és részhatáridők - Meghatározott erőforrások (költségvetés) - Tervezett tevékenység - Alapvető jellemzőiben egyedi
Projekt tervezése A szoftver projekt előkészítése: – A megrendelő és a fejlesztő közösen meghatározzák: - a projekt céljait - a megvalósítandó rendszer fő funkcióit - kvantitatív mérőszámokat a funkciók jellemzésére – Alternatív megoldási módokban állapodnak meg a tervezési tér növelése érdekében – költség, határidő, erőforrás korlátok tisztázása A projekt terv típusai: - Minőségi terv (a projektben használandó minőségi eljárásokat és szabványokat tartalmazza) - Validációs terv (a rendszer validációhoz szükséges megközelítési módot, erőforrásokat és ütemterveket határozza meg) - Konfigurációkezelési terv (a konfiguráció kezeléséhez szükséges eljárásokat és szerkezeteket tartalmazza) - Karbantartási terv (a rendszer karbantartásához szükséges követelményeket, költségeket tartalmazza) - Munkaerő-fejlesztési terv (a projektteam tagjainak szakmai fejlődését tartalmazza) A projektterv készítésének folyamata:
96
A projektterv felépítése (szakaszai): 1., Bevezetés: Meghatározza a projekt célját, alapvető jellemzőit, a menedzselés megszorításait (erőforráskorlátok, időkorlátok) 2., Projekt szervezet: Megadja a projekthez rendelt team vagy teamek összetételét, a tagok szerepköreit, feladataikat, felelősségüket 3., Kockázatelemzés: Számba veszi a lehetséges projekt kockázatokat, elkerülésükhöz szükséges stratégiákat, bekövetkezésük esetén szükséges tevékenységeket. 4., Hardver és szoftver erőforrás követelmények: Rögzíti, hogy a fejlesztéshez pontosan milyen hardver és szoftver eszközökre van szükség. Amennyiben ezeket be kell szerezni, úgy tartalmazza a költségbecslést is. 5., Munka felosztása: Tartalmazza a projekt tevékenységekre bontását az egyes tevékenységekhez tartozó részeredményekkel és mérföldkövekkel együtt. 6., Projekt ütemterve: Megadja az egyes tevékenységek közötti függőségeket, a mérföldkövek eléréséhez szükséges becsült időt, valamint a tevékenységekhez rendelt becsült emberi erőforrásokat. 7., Figyelési és jelentéskészítési mechanizmusok (projekt követés és ellenőrzés): Meghatározza a menedzser által elkészítendő jelentéseket, azok leadási idejét, valamint az alkalmazandó projekt követési, ellenőrzési technikákat).
Mérföldkövek a projektben – – – –
A mérföldkövek alkalmazása egy eszköz a projekt követésére. A mérföldkövek tipikusan a projekt egyes szakaszainak végét jelzik (esetenként ritkább, máskor sűrűbb bontásban). A mérföldkövekhez jelentések (report) tartoznak A mérföldkövek kapcsolódhatnak belső részeredményekhez, vagy külső, leszállításra kerülő részeredményekhez (pl: specifikáció, stb.)
Mérföldkövek a követelményspecifikáció folyamatában:
97
47. Kockázat menedzsment A kockázati kategóriák csoportosítása (kockázat típusok): - Projektkockázat (kihatással van a teljes projektre pl: erőforrások rendelkezésre állása, ütemterv betartása, költségvetés tartása, kollégák kiválnak a projektből, vezetőségváltás) - Termékkockázatok (kihatással van a fejlesztés alatt álló termék minőségére, teljesítményére, pl.: fejlesztőeszköz elégtelensége, elvárások jelentős változása) - Üzleti kockázatok (a szoftver fejlesztését végző szervezetre hat ki, pl: konkurens termék kerül a piacra, megváltozik a cég stratégiája, technológiaváltás) A kockázatkezelés fázisai: 1., Kockázat azonosítás (a lehetséges kockázatok közül meghatározza a valószínű kockázatokat) 2., Kockázat elemzés (megbecsüli a kockázat bekövetkezésének valószínűségét és kihatását) 3., Kockázat tervezés (intézkedési tervek készítése a kockázat csökkentésére, illetve a teendőkre a bekövetkezésének esetére) 4., Kockázat figyelés (állandó monitorozás és terv revízió)
A kockázatkezelés folyamata és dokumentumai
Kockázat azonosítás Cél: kiválasztani a lehetséges kockázatok közül a potenciális kockázatokat. Módszer: checklist alkalmazása Eredmény: Potenciális kockázatok listája Példák kockázatokra: Műszaki-, technológiai-, emberi-, szervezeti-, hardver-, eszköz-, követelmény-, becslési kockázat
Kockázat elemzés cél: a potenciális kockázatok vizsgálata két szempontból: - bekövetkezésének valószínűsége - következményei A kockázat elemzés lépései: - A bekövetkezés valószínűségének számszerűsítése (alkalmazható skálák: bináris, minőségi, mennyiségi) - A bekövetkezéskor fellépő következmények leírása - A kockázat kihatásának becslése - A kockázat elemzés pontosságának megfogalmazása A kihatás mértéke lehet: - jelentéktelen, - elviselhető, - jelentős, - súlyos, - katasztrofális A bekövetkezés gyakorisága lehet: - ritka - közepes - sűrű
98
Melyikre lehet felkészülni?
Kockázat tervezés Kidolgozandó a kockázat elkerüléséhez szükséges stratégiák, és a bekövetkezésekor elvégzendő teendőket tartalmazó tervek. Kockázat elkerülési stratégiák: azon tevékenységeket és megszorításokat tartalmazza, melyek segítségével csökkenteni igyekszünk a kockázat bekövetkezésének valószínűségét. (pl: bizonytalan elemek lecserélése megbízhatóra) Kockázat minimalizációs stratégiák: célja a kockázat bekövetkezésekor, annak kihatásának csökkentése (pl: redundanciák, átfedések, tartalékok beépítése) Vészhelyzeti tervek: a kockázati veszélyeztetettség fokára vonatkozó referencia szinteket, a kockázat bekövetkezésekor szükséges teendőket, a helyzet megoldásához tartalékolandó erőforrások leírását tartalmazza.
Kockázat figyelés, (követés) A teljes projekt során szükséges tevékenységek: - az azonosított kockázatok bekövetkezési valószínűségének figyelése - A kockázat elkerülési terv végrehajtásának ellenőrzése - Szükség esetén a tervek módosítása - Kockázati esemény bekövetkezése esetén vészhelyzeti terv végrehajtása, hatás ellenőrzése Nagy projektek esetén az azonosított kockázatok száma: 30-40 (felkészülés, erőforrás tartalékolás drága) Általános szabály: A kockázatmenedzsment költsége ideális esetben a projekt költségvetésének 3-5 százaléka. Ha a kockázat menedzsment költsége eléri a projektköltség 15 százalékát, akkor meg kell gondolni, hogy szükséges-e egyáltalán (a kockázat menedzsment, vagy a projekt maga) Pareto 80/20-as szabálya: Alkalmazása a - A hagyományos Projektmenedzsmentben - A modern projektmenedzsmentben - A bürokráciában A Pareto 80/20-as szabály alkalmazása a kockázat menedzsmentre: A projekt alatt bekövetkező kockázatok 80%-át lefedi az előzetesen becsült kockázat 20%-a.
99
48. COCOMO 81, COCOMO 2
A COCOMO modell COCOMO = Constructive Cost Model Jellemzői: - Jól dokumentált - Szabadon hozzáférhető - Széles körben használt - Hosszú ideje használt, több verziót fejlesztettek ki, sok tapasztalat halmozódott fel
A COCOMO 81 A modell szintjei: Model-1 (alap COCOMO): Egyszerű, egyváltozós modell, a sorok számán alapszik. Model-2 (középszintű COCOMO): A LOC-on kívül szubjektív költségtényezők határozzák meg a ráfordítást. Model-3 (fejlett COCOMO): A Model-2 jellemzőit a szoftver technológia fázisaira (analízis, tervezés, stb.) szétbontva határozza meg. Jellemzői: - Feltételezi a vízesés modell alapú fejlesztést - A szoftver túlnyomó többsége még nem létezik A COCOMO projektosztályai: Kis méretű projekt: Relatív kis méretű projekt, egyszerű feladat, kis team, jól felkészült szakemberek Közepes méretű projekt: Közepes bonyolultságú feladat, közepes méretű projekt, vegyes összetételű team. Nagy méretű projekt: Bonyolult hardver körülmények között, kényszer-feltételek mellett fejlesztendő projektek (pl.: légi -irányítási rendszer) b E=ab∗ KLOC b
COCOMO Model-1:
d D=c b∗ E b ahol:
E - ráfordítás [ember-hónap] D - a projekt időtartama [naptári hónap] Együtthatók:
COCOMO Model-2:
b E= a ∗ KLOC i∗EAF ahol: i
E - ráfordítás [ember-hónap] EAF - költség befolyásoló tényezők Költség befolyásoló tényezők: Termék jellemzők: - Igényelt szoftver megbízhatóság - Felhasznált adatbázis mérete - A termék bonyolultsága
Hardver jellemzők: - Run-time kényszerfeltételek - Memória kényszerfeltételek - Virtuális gép kényszerfeltételek - Igényelt válaszidő korlátok
Személyi jellemzők: - Analizáló szakember kapacitás igény - Szoftver technológus szakember kapacitás igény - Alkalmazói gyakorlat - Virtuális gép gyakorlat - Programozási nyelv gyakorlat
Projekt jellemzők: - Szoftver tool-ok használata - Szoftver technológiai módszerek használata - Igényelt fejlesztési ütemezés
100
Kiértékelés: 1., mind a 15 kérdésre egy 6 fokozatú skála segítségével 2., táblázat alapján EAF megállapítása (tipikusan: 0.9-1.4) Együtthatók:
A COCOMO 2 Jellemzői: - Elismeri a szoftverfejlesztés különböző szemléleteit (prototípus készítés, komponens alapú fejlesztés, 4GL, stb) - A modell szintjei itt már nem a becslések részletesebbé válását jelentik - A szintek a szoftverfejlesztési folyamat tevékenységeihez kapcsolódnak A COCOMO 2 modell azonosított szintjei: - Korai prototípuskészítési szint ( a méretet objektumokkal becsli, a ráfordítás mértéke méret/termelékenység képlettel számítható ki.) - Korai tervezési szint (a rendszerkövetelményekhez valamilyen kezdeti tervezetet készítünk. A becslések funkciópontokon alapulnak, amelyet a forráskód sorainak számává alakítunk át. A képlet alakja marad az egységes formátumú, a szorzóknak egy egyszerű halmaza kapcsolódik hozzá) - Posztarchitekturális szint (a rendszer architekturájának elkészülte után már aránylag pontos becslés tehető a szoftver méretére. Itt a becslések már több szorzót tartalmaznak, ezekkel a személyi kapacitások, a termék és a projekt jellemzői fejezhetők ki.)
101
49. Team-szervezési megoldások
Géniusz elv: Jellemzői: - A programozás „hőskorára” jellemző - Az átlagos programozók egy kiváló képességű, vagy autokrata egyéniségű programozó (vezető) keze alá dolgoztak - Nem volt tervezés (feladat szétbontás, integrálás, stb.) mindent a vezető döntött el - Az ő képességei határozták meg a program minőségét - Fejletlen információs rendszer (gyakorlatilag nincs) - A dokumentáció gyakran utólag készül
Homogén csoport elv: Jellemzői: - A programozás egy későbbi fázisára jellemző - Az elv, hogy nem kell vezető a csoportba (demokratikus működés: a csoport minden tagja egyenrangú) - Döntéseket közösen hoztak, a modularizálást közösen végezték el - A programozás egyénileg történt, az integrálásnál jött az „integrációs BUMM” - A modulok „személyesek” a teljes program személytelen - Az információs rendszer nem fejlett, információ áramlás nincs
Horizontális szervezési elv: Jellemzői: - A programozási, programtervezési módszerek fejlődésével kialakult a specializálódás, szakosodás (külön tervező szakember, külön programozó szakember, stb.) - A programozás egyes részfeladataira tehát specializált csoportok rendszere alakult ki: - rendszertervezők, rendszerszervezők - programozók * - kódolók * - tesztelők (A *-gal jelölt csoportok minden munkánál, illetve szoftverháznál megtalálhatók, míg a többi esetleges.) - A feladatot mindegyik csoport a saját szempontjai szerint feldolgozza és továbbítja az alatta lévő szintekre - Fejlett információs rendszer és információ továbbítás - Az egyes csoportok közötti kapcsolat pontosan szabályozott
Vezetőprogramozó-csoport elv: Jellemzők: - Az igen jó képességű programozók hatékonyságának növelése érdekében magas szintű kiszolgálásuk - A csoportot egy három tagú mag alkotja, amelyhez időlegesen kapcsolódnak egyéb szakemberek - Dinamikus, a feladathoz jól illeszkedő struktúra
102
A vezetőprogramozó-csoport felépítése:
Nagyvállalati projekt menedzsment (EPM – Enterprise Project Management)
Portfólió menedzsment: A portfólió menedzsment a projektek azonosításának, fontossági sorrendbe állításának és beruházásának állandó folyamata, amely a vállalati stratégiával összehangoltan történik. Az üzleti feltételek és a költségvetések változásakor az „agilis” vállalatok proaktívan értékelik és kiigazítják a portfóliót úgy, hogy a kockázattűrésükkel összhangban optimális megtérülést érjenek el. A portfóliójukat bölcsen kezelő vállalatok megalapozott kompromisszumokat kötnek a projektek között, és erőforrásaikat megfelelően átirányítva biztosítják, hogy csak olyan tevékenységekre fordítsanak időt, amelyek a végcélhoz szükségesek. Erőforrás menedzsment: Az egyének jelentik a szervezet legértékesebb és gyakran a legdrágább tőkéjét. Ez elengedhetetlenül fontossá teszi a megfelelő személyek rendelését a megfelelő projektcsapatokhoz, hogy a termelékenység költség hatékony módon a lehető legnagyobb legyen. A csapat képzettségi adatainak és rendelkezésre állásának teljes körű ismerete szükséges a szervezet munkaportfóliónak megfelelő stratégiai erőforrás kölcsönzést, - fejlesztést és - felállítást végezni. Együttműködés és kommunikáció: A lehető legnagyobb mértékű koordinálás és részvétel a jobb termelékenység érdekében A hatékony együttműködés és kommunikáció alapvető a projektek sikeréhez. Világos kommunikációs folyamatok révén a csoport tagjai megoszthatják tudásukat, együtt készíthetik el a feladatokat és a leadandó anyagokat, gyorsan igazodhatnak a változásokhoz. A projektekben részt vevő csoportok tagjai egyre távolabb vannak egymástól szervezeti és földrajzi értelemben is; ez veszélyezteti a termelékenységet, és olyan technológiát tesz szükségessé, ami értelmesen kapcsolja össze a csoporttagokat a koordináció és a minőség fenntartása érdekében. Projektmenedzsment: Termékek és szolgáltatások szállítása esetén is a szervezetnek be kell tartania a projektek határidejét és költségvetését. Az ügyfelek elégedettségének fenntartása és elvárásainak teljesítése megköveteli, hogy ne legyenek hibák és késések. A versenyképességhez a vállalatok növekvő mértékben tesznek kezdeményezéseket a projektek folyamatos javítására a ciklusidők rövidítése, a költségek leszorítása és a minőség ellenőrzés révén. Mindehhez szakképzett egyének, szabványos folyamatok és magas szintű technológia szükséges, hatékony projektmenedzsment irányításával.
103
Tervezési módszerek
104
50. Szoftverspecifikáció (fázisok, folyamat, technikák)
Szoftverspecifikáció (analízis) A követelmények tervezésének fázisai: 1. Megvalósíthatósági tanulmány készítése: Gyors gazdasági, műszaki elemzés a megvalósításra és az üzemeltetésre vonatkozóan 2. Követelmények feltárása és elemzése: Meglévő rendszerek vizsgálata, modellek, prototípusok készítése, konzultáció a megrendelővel 3. Követelmény specifikáció készítése: A rendszerkövetelmények és a felhasználói követelmények megfogalmazása, egységes dokumentumba foglalása 4. Követelmény validáció: A követelmények valószerűségének, konzisztenciájának, teljességének vizsgálata, hibák keresése A követelménytervezés folyamata:
A specifikációt támogató technikák: a.) Előzetes interjú módszer. Célja a „jég megtörése”. jellemzők: – a személyek nem ismerik egymást – tartanak a félreértésektől – hatnak esetleges régi rossz tapasztalatok – ugyanakkor mindkét fél sikerorientált Lényege: - először kötetlen beszélgetés, informálódás a rendszer alapvető kérdései iránt. (Ki fogja használni a rendszert? Mi lesz az előnye a rendszer használatának?) - ezután a rendszer jellemzőivel kapcsolatos kérdéskör kerül elő (Hogy jellemezné, milyen ismereteket kell majd magán viselnie az elkészült rendszernek? Milyen környezetben kell majd üzemelnie a rendszernek?) - A harmadik kérdéscsoport az interjú hatékonyságára irányul. (Lényegretörő kérdéseket tettem fel? Van valami, amit meg kellett még kérdeznem?) b.) FAST (Facilitated Application Specification Techniques) Probléma: A megrendelő és a vevő tudat alatt “mi és ők” csoportokat képez és ebben gondolkodik. Nem alakul ki igazi team munka (félreértések, lényeges info elvész, stb.) Megoldás: FAST. Az analízis és specifikáció korai fázisát, az információ gyűjtést támogató team-orientált szisztematikus módszer. Lényege: A felhasználók és fejlesztők közös teamet hoznak létre a probléma identifikációjára, a megoldás elemeinek kijelölésére, a megoldással szemben támasztott követelmények előzetes meghatározására. Alapvető jellemzők: - Az üléseket semleges fél vezesse - Az ülés előkészítésének, a meghívottak köre kialakításának szabályai rögzítve legyenek - a napirend rögzítse a teendőket, de adjon lehetőséget az ötletek szabad kifejtésére - Elnököt kell kijelölni az ülés irányítására - Definíciós mechanizmus használata ajánlott (táblázat, tábla, Pinwand stb.) FAST-ülés előkészítése: minden résztvevőt megkérnek, hogy készítsen: - a rendszert körülvevő környezet objektumainak listája. (A lista fontos!) - a rendszert alkotó objektumok listája - azon eljárások, függvények listája, amelyek manipulálják ezen objektumokat. - kényszerfeltételek és működési kritériumok listája (a listáknak nem kell komplettnek lenni).
105
Alkalmazott módszertan az üléseken: 1.) az első ülésen minden résztvevőnek igazolnia kell a termék szükségességét 2.) az elkészített listák ismertetése Pinn-wall, vagy mágnes tábla használata, a listaelemek csoportosíthatók, áthelyezhetők legyenek, kiegészítések legyenek lehetségesek (A vita tilos!) 3.) az ismertetett listák vitája, új ötletek felvétele a táblára, de törölni tilos, redundanciák összevonása 4.) konszenzusos lista vitával való kialakítása, törlés is és módosítás is megengedett (eredmény: konszenzusos lista) 5.) Rész-teamek képzése, minispecifikációk elkészítése, minden egyes elemre. 6.) A rész-teamek bemutatják az általuk elkészített minispecifikációkat. (Itt felvetődhetnek új objektumok, kényszerfeltételek, funkciók, stb). Vita a listákról, megoldatlan problémák listájának felvétele. 7.) A minispecifikációk elkészülte után a részteamek elkészítik a validációs kritériumokra tett javaslatokat. 8.) Az eddigi ülések anyagaiból egy kijelölt csoport összeállítja a specifikációt.
106
51. Szoftvertervezés (a folyamat tevékenységei, általános modell, általános elvek) A tervezési folyamat tevékenységei: 1. Architekturális tervezés: A rendszert alkotó alrendszerek és azok kapcsolatainak azonosítása, dokumentálása 2. Absztrakt specifikáció: Minden egyes alrendszer szolgáltatásainak absztrakt specifikálása, peremfeltételekkel, megszorításokkal együtt 3. Interfész tervezés: Minden egyes alrendszer interfészének megtervezése, dokumentálása 4. Komponens tervezés: A szolgáltatások komponensekhez rendelése, a komponensek interfészének meghatározása 5. Adatszerkezet tervezés: A rendszer implementációjában használt adatszerkezetek részletes tervezése 6. Algoritmus tervezés: A szolgáltatások biztosításához szükséges algoritmusok részletes megtervezése A tervezési folyamat általános modellje:
A tervezés általános elvei: - Absztrakció: Az absztrakció segít koncentrálni a lényegesre, elhanyagolva a lényegtelent, mindhárom területen alkalmazható (data design, procedual design, architectural design). Eljutunk a problémára és környezetére orientáló megfogalmazástól a procedurális orientációjú leírásig - Finomítás: A lépésenkénti finomítás módszerét Wirth ajánlotta 1971-ben. Párhuzamosan finomítható program és adatszerkezet (pl: rendezés). a finomítás a funkcionális primitívekig tart. Minden finomítási lépés egy-egy döntést igényel. (strukturáló objektum és szempont. Absztrakciós stratégiák: -soros (egy strukturáló objektum van). Ez lehet tiszta (adatorientált, eljárás orientált); kereszt (pl. információs rendszerek) vagy ortogonális (van egy rendezőelv ami végigmegy rajta. Alkalmazzák, de nem tudnak róla. Pl.: a programnak hordozhatónak kell lennie.). A soroson kívül lehet párhuzamos is, de ezt bonyolult kezelni. - Modularitás (kohézió, csatolás): p1 - probléma; c(p) - a probléma komplexitása; E(p) - a megoldáshoz szükséges ráfordítás (pl: költség) ha C p1C p2 E p1E p2 , akkor C p1 p2C p1C p2 (Tapasztalati képlet), és E p1 p2 E p1E p2 . Ebből következik, hogy bontsuk szét sok apró, pici modulra a feladatot. Probléma: nem lehet M-et (munkapont) előre megmondani. A modulok mérete (és így a száma) függ a feladat jellegétől, nem lehet a modulokat „ész nélkül” szétbontani (funkcionalitás, integritás, kohézió, csatolás) Az effektív modularizálás (modulokra bontás) titka a funkcionális függetlenség. Ez azt jelenti, hogy jól körbe kell tudni határolni azon területet, amely egy modulba vonva logikusan összekapcsolódik és nem kommunikál sokat a külvilággal. (A másik szempont, hogy ezek aránylag egyszerű funkciók legyenek.) A funkcionális függetlenség mérésére két jellemző szolgál: - kohézió - Csatolás
107
Kohézió: A kohézió a modul kompaktságát, integritását, feladat orientált „tisztaságát”, belső összetartását ill. homogenitását (a feladat szempontjából) fejezi ki. A kohézió egy spektrumként fogható fel a gyengétől az erősig. Törekedni kell e minél erősebb kohézióra. Csatolás: A csatolás a modul kapcsolatának intenzitását, erősségét fejezi ki más modulokhoz (adat és vezérlési kapcsolat). Egy spektrumként adható meg a laza csatolástól a szoros csatolásig. Törekedni kell a minél lazább csatolás kialakítására. - Programszerkezet kialakítás:
Ajánlások a programszerkezet kialakításánál: - Minimalizálni kell a fan-outokat és fan-ineket - A mélység és a szélesség ne legyen 7-8-nál nagyobb - Törekedni kell az egy bemenetű és egy kimenetű modulokra Fan-out: 1 modul hány másikat hajt meg.
- Információ rejtés: 1972-ben Parnas publikálta az információ rejtés fogalmát. Lényege: A program elemek (modulok) csak az interfészen keresztül kapcsolódnak a külvilághoz. Belső változók, rutinok, eljárások nem érhetők el a külsők számára. Azzal, hogy zárttá teszem a hibát is minimalizálom. Előnye: - Jól definiált interfész - Minőségi biztonság modulok cseréje, javítása esetén (a hiba is be van zárva)
108
52. Tervezési módszerek I. (kategorizálás, a Jackson féle módszer)
Tervezési módszerek – – –
Adatszerkezet orientált: JSP (Jackson) Adatfolyam orientált: SA (DeMarco), SD (Yourdon, Constantine, Objektum orientált: OOSE (Jacobson), OMT (Raumbught & all), UML (Raumbught, Booch, Jacobson)
Adatszerkezet orientált JSP (Jackson Structured Programming) Michael A. Jackson publikálta 1974-ben. Struktúráló objektum: adattér. Strukturáló szempont: szemantikus szint. Alkalmazott elvek: - a probléma hierarchikus (top-down) lebontása - a lépésenkénti finomítás módszere - kizárólag elemi részgráfok alkalmazása (Böhm és Jacopini tétel alapján: szekvencia, szelekció és iteráció használata) Alkalmazott formalizmusok: - szerkezeti ábra (a program- és adatszerkezethez) - funkcionális leírás (pszeudokód szerű) a programszerkezet leírásához Alapszerkezetek: Szekvencia: Adatszerkezetnél: pl: rekord Programszerkezetnél: egymásután végrehajtandó műveletek. Jelölése: sima négyzet. Szelekció: Adatszerkezetnél: változó rekord, Programszerkezetnél: feltételes utasítás. Jelölése: négyzet jobb felső részében kis karika. Iteráció: Adatszerkezetnél: fájl, Programszerkezetnél: ciklus. Jelölése: négyzet jobb felső részében kis csillag A módszer tervezési lépései: 1. Az adatszerkezetek elkészítése: A feladat szövegének elemzése alapján elkészítjük a bemenő és kimenő adatszerkezeteket a három alapelem (szekvencia, szelekció, iteráció) segítségével. (Annyi bemenő és kimenő adatszerkezetet ábrázolunk, ahány fizikailag létező állomány van. Sorrend nem számít.) 2. A programszerkezet elkészítése az adatszerkezet alapján 3. A tevékenységek összeállítása: "összeírjuk" az összes felmerülő tevékenységet valamint feltételt és sorszámmal látjuk el. 4. A tevékenységek elhelyezése a programszerkezetben: Meg kell keresni azt a programelemet, amelyhez az adott tevékenység a legközelebb áll. 5. A funkcionális leírás elkészítése: Leírjuk a teljes programot (pszeudókódban) a célnyelvtől független formában (konkrét tevékenységeket, feltételeket, logikai kapcsolatokat tartalmaz)
109
53. Tervezési módszerek II. (Strukturált analízis és tervezés)
Strukturált analízis (SA) Demarco 1979-ben fektette le az alapjait (foglalta össze). Adatfolyam orientált. Jellemzői: - 20 éves fejlődési folyamat eredménye modellezési technika - adat és vezérlési áramlást és tartalmat ír le - a funkcionalitás és viselkedés szerint particionál
Data Flow Diagram (DFD)
A 0-s szintű DFD csak egy buborékot tartalmaz, ami nem más, mint a rendszer szoftver. Ezt szokás még: Context model, vagy Fundamental system Model-ként is nevezni. A DFD egyértelműen maghatározza, melyek a külső egyedek, mi az, ami része a rendszernek és mi az, ami nem. (Hol vannak a rendszer határai.) A DFD az információ áramlását írja le, nem blokk diagram! (sorrendiséget nem tartalmaz). A DFD-t finomítjuk, a buborékokat felvágjuk a funkcionális primitívek szintjéig. (meddig finomítunk, melyek a finomítás szabályai). Lebontás finomsága: 5-7 szint. Folytonossági szabály: összes külső, és belső viszonylatnak azonosíthatónak kell lennie. A modellezést mindig kiegészítjük szöveggel. A DFD-t kiegészítjük két leírással: a.) Data Dictionary, Adatszótár (DD) b.) Process Specification (PSPEC) A folyamat szöveges megfogalmazása. (Algoritmust, megszorításokat, és egyéb részleteket tartalmazó kiegészítő leírás.) (A PSPEC megadásának formái) Ezek során a megrendelő rájön, hogy mit lehet megvalósítani, és az Informatikus megtudja, hogy a megrendelő mit akar.
Strukturált tervezés (SD) Constantine, Myers, Steven nyomán Constantine és Yourdon dolgozta ki. Alapmű: E. Yourdon, L. Constantine: Structured Design, Prentice-Hall 1979. Alkalmazhatóság: igen széleskörű, hiszen a problémák jelentős része leírható információáramlással (DFD) A DFD típusai: 1.) transzformáció folyam (bejövő folyam - transzformációs folyam - kimenő folyam) 2.) tranzakció folyam (egy „tigger” adat tranzakciókat indít el lásd.)
110
Adatfolyam orientált tervezés:
Tervezési heurisztikák: 1.) A programszerkezet kialakításakor vegyük figyelembe a csatolást és a kohéziót /modulok (funkciók) összevonása, szétválasztása/. 2.) Kerüljük a nagy Fan-Out-tal rendelkező szerkezeteket. Inkább a kiegyensúlyozott, arányos szerkezetekre törekedjünk 3.) A hatást kiváltó modul vezérlési körében legyen az a modul, amire hatással van. 4.) A modul-interfészek komplexitásának csökkentésére, a konzisztencia növelésére kell törekedni. 5.) Törekedjünk „emlékezet nélküli” modulok kialakítására (azonos inputra mindig azonos választ ad). 6.) Törekedjünk az „egy bemenet-egy kimenet” modulok létrehozására. 7.) A modulok csoportosítása különböző kényszer feltételek miatt. pl.: portabilitás
111
54. Jelentősebb OO módszertanok (OOAD, RDD, OOSE, OOD, OMT)
1. Coad-Yourdan: OO analízis és tervezés (OOAD), (1991): Jellemzője: - szerényebb eszközrendszerrel rendelkező, - több szintű, több komponensű fejlesztési módszertan Az alkalmazott szintek: - osztály & objektum - struktúra - szegmens (subject) - attribútum - szolgáltatás (service) A figyelembe vett komponensek: • probléma-terület • humán interakció • feladat (task) menedzsment • adat menedzsment A Coad-Yourdan OOAD vázlata:
2. Wirfs-Brock et al., Responsibility Driven Design (RDD): Jellemzői: • Új szemléletű módszer, melyre jellemző az antropomorph megközelítés. • A rendszert egymással együttműködő és „szövetkező” objektumok (ügynökök) alkotják, melyek mindegyikéhez jól meghatározott funkció és felelősség kötődik. • Az objektumok közti kommunikációt „szerződések” (contract) rögzítik.
3. Jacobson: Object-Oriented Software Engineering (OOSE) (1992): A módszer öt modellt használ az analízis és tervezés fázisaiban: • követelmény modell • analízis modell • tervezési modell • implementációs modell • teszt modell Use Case alapú megközelítés: • felhasználók azonosítása • szerepek meghatározása • interakciók számbavétele • rendszer viselkedésének
112
4. Booch: Object-Oriented Design (OOD) (1991): A rendszer statikus leírására használt diagrammok: • Osztálydiagram • Objektumdiagram • Moduldiagram • Folyamatdiagram A dinamikus viselkedés leírására használt diagramok: • Állapotdiagram • Időzítésdiagram (Timing diagram) A Booch-féle OOD felépítése:
5. Rumbaugh: Object Modeling Technique (OMT) (1993): A rendszert három különböző nézetből három modell képezi le. • Objektum modell • Dinamikus modell • Funkcionális modell
Az Objektum modell a rendszer struktúráját, szerkezetét ábrázolja. • Osztály diagramm • Objektum diagramm A Dinamikus modell a rendszer viselkedését képezi le. • Szcenárió • Esemény diagramm A funkcionális modell a rendszer funkcionalitását reprezentálja. • Adatfolyam diagramm
113
55. UML (fogalmak, keletkezése, jellemzői, célok, tulajdonságok, kritikája, építőkövei)
Az UML fogalma „A Unified Modeling Language (Egységes Modellező Nyelv) rendszerek elemeinek specifikálására, megalkotására és dokumentálására szolgáló vizuális nyelv. Általános célú modellező nyelv, amely minden nagy objektum és komponens alapú módszerrel használható bármely alkalmazási területen (pl. egészségügy, pénzügy, telekommunikáció, légi irányítás) és implementációs platformon (pl. J2EE, .NET).”
Az UML keletkezése • Alapvetően három módszer egységesítéséből, összedolgozásából alakult ki: • Grady Booch: Booch Methode (BOOCH) • Jim Rumbaugh: Object Modeling Technique (OMT) • Ivar Jacobson: Object-Oriented Software Engeneering (OOSE) • Közreműködött az Object Management Group (OMG), az objektum-orientált szakma legjelentősebb szervezete A kialakulás időrendje: 1994. október: Fejlesztés kezdete: Booch és Rumbaugh módszerének egyesítése 1995. október: Unified Method 0.8: Unified Method 0.8 1995. ősz: Jacobson csatlakozik, módszerét integrálják 1997. január: UML 1.0 1997. szept./1998…: UML 1.1/ UML 1.2 … 2004. : UML 2.0
Az UML jellemzői: • Hamar de-facto szabvánnyá vált • A szoftveripar domináns modellező nyelvévé emelkedett • Széles körben sikerrel alkalmazzák az egészségügytől az e-kereskedelemig • Széleskörű együttműködés eredménye több vezető cég között: pl. Hewlett-Packard, IBM, Microsoft, Oracle, Unisys… Célok az UML tervezésénél: • A gyakorlatban jól használható, vizuális, kifejező modellező nyelv kialakítása • A modell bővítését és specializálását lehetővé tevő mechanizmusok biztosítása a nyelvben • Programozási nyelvtől és fejlesztési módszertől független legyen • Formális alap biztosítása a modellező nyelv megéréséhez • Az OO alapú CASE eszközök piacának növekedését ösztönzi • Magasabb szintű fejlesztési koncepciók támogatása • A létező legjobb technikák integrálása Az UML alapvető tulajdonságai: • Modellező nyelv, nem fejlesztési módszertan • Grafikus szemléletet nyújt • Lehetővé teszi szoftver-intenzív rendszerek specifikálását, konstruálását, vizualizálását és dokumentálását • Munkafolyamatok, szervezetek, üzleti tevékenységek stb. leírására is alkalmas • A gyakorlatban jól használható egyedi, osztott vagy konkurens rendszerek kezelésére
Az UML kritikája: • Nem teljesen precíz szemantika: Az interpretáció szubjektív lehet. Ez megnehezíti a formális tesztelés fázisát • Osztott rendszereknél nem jól alkalmazható: Nincsenek meg benne pl. a sorosítás vagy az üzenetküldés faktorai • Túlságosan dagályos, részletekbe menő: Olyat is leír, amit a forráskód mutat a legjobban 114
• Széleskörű alkalmazás, sok a hozzá nem értő
Az UML építőkövei Az UML szókincse három fő kategóriába sorolható, amelyek tovább bonthatók: Elemek: • Strukturális • Viselkedési • Annotációs • Csoportos Kapcsolatok: • Függőségi • Társítási • Általánosítási Diagramok Kapcsolatok: A modellelemek közötti kapcsolatokat testesítik meg. Fajtái: • Függőségi (Dependency): Egyik elem változása hatással van a másik elemre. Jele: szaggatott nyíl: (---->) • Asszociáció, társítás (Association): Strukturális, szerkezeti összefüggés. Jele: egyenes vonal • Generalizáció (Generalization): Általános-speciális kapcsolata, öröklődés. Jele: üres háromszög fejű nyíl
115
56. UML – Osztály diagramm
Class Diagram • A modell (egy részének) statikus nézetét írja le • Objektum orientált rendszer építőelemeit mutatja • A rendszer osztályait és a közöttük lévő kapcsolatokat írja le
Osztály: • UML-es szóhasználat: - Attribútumok - Operátorok • Jelölés: három részből álló téglalap - Név rész - Attribútum rész (opcionális) - Operátor rész (opcionális) • Láthatóságok: + public, - private, # protected, ~ package Az osztályok meghatározásának menete: • A leírásból (scope) válasszuk ki a főneveket. • Szűrjük ki az egyértelműen nem a rendszerhez tartozó, csak az érthetőséget javító főneveket • Szűrjük ki a szinonimákat, rokon értelmű főneveket. • Keressünk rejtett főneveket (a szövegben explicite nem szerepel, de a kultúrából következik) • Az így kapott jelöltekből válasszuk ki a rendszert alkotó objektumokat.
Interface • Operációk halmazát adja meg, melyet más osztályok megvalósítanak • Az interfészt megvalósító osztály és az interfész között realizációs kapcsolat van • Jelölés: - Osztályjelölés + <> sztereotípia - Kör
Generalizációs kapcsolat • Az öröklődést fejezi ki • Általános és specifikus osztály kapcsolata
Asszociációs kapcsolat • Két osztály összekapcsolása • A legáltalánosabb reláció • Nyíllal jelölhető a navigálhatósága: A nyíl irányában ismeri az egyik a másikat • Multiplicitás jelöli, hogy hány példány vehet részt a kapcsolatban, az alapértelmezett az 1 • Az objektumok szerepét a kapcsolaton jelölhetjük 116
Akárhány munkaállomás használhatja a nyomtatót, fordított ismertség nincs Kettőnél több osztály között fennálló kapcsolat esetén az osztályokat rombusszal kapcsoljuk össze.
Asszociáció megadása osztállyal: • A kapcsolatra vonatkozó információkat tartalmaz • Osztályként adható meg, szaggatott vonalak kapcsolódik az asszociációhoz • Az osztálynak attribútumai vannak
Aggregációs kapcsolat: • Az asszociáció egyik formája • Az egyik osztály alárendeltje a másiknak • Tartalmazó-tartalmazott viszony, a tartalmazott túlélheti a tartalmazót
Kompozíciós kapcsolat: • Az aggregáció erősebb formája • A részek életciklusa egybeesik a tartalmazóéval • Egy objektum csak egy tartalmazóhoz tartozhat • A tartalmazó objektum felelős a részek létrehozásáért és megsemmisítéséért • Osztott aggregáció: - olyan aggregáció, ami nem kompozíció - a tartalmazók osztozhatnak a részeken
117
57. UML – Objektum és szekvencia diagramm
Object diagram • Objektum: egy osztály egy példánya • Objektumdiagram: objektumokat és azok kapcsolatait mutatja egy adott pillanatban • A rendszer adott időben vett állapotát reprezentálja • Az objektum minden attribútumának van értéke • Az objektum összeköttetésben áll más objektumokkal - Link: az asszociáció egy példánya
Objektumok jelölése Hasonít az osztálydiagramok ábrázolásához. Két része van: - Névrész: Objektum vagy az osztály neve aláhúzva - Attribútum rész: Értékekkel A metódusok (operációk) feltüntetésere nincs szükség, hiszen azok minden objektumban azonosak.
Sequence Diagram • Viselkedési, interakciós diagram • Az objektumok interakcióit mutatja az idő függvényében • Explicit mutatja az időt, de nem jelöli az osztályok kapcsolatát Elemei: • Objektumok, melyek részt vesznek az interakcióban • A kicserélt üzentek sorozata
Jelölés: • Függőlegesen jelenik meg az idő - Életvonal: az objektum időben való létezését jelenti - Aktivációs életvonal: az objektumhoz kapcsolódó műveletek hajtódnak végre • Vízszintesen az interakcióban részt vevő objektumok vannak • Egy objektum téglalap jelölése elhelyezkedhet a diagram tetején vagy ahol létrejön • Az üzenetek különböző típusúak lehetnek • X jelzi az objektum megszűnését
Üzenettípusok: • Egyszerű üzenet: az aktív objektum átadja a vezérlést a passzív objektumnak. • Szinkronizációs üzenet: a küldő blokkolt állapotba kerül, amíg a fogadó nem fogadta az üzenetet. • Aszinkron üzenet: a küldő folyamat nem szakad meg, nem érdekli őt, hogy mikor kapta meg a fogadó az üzenetet. • Visszatérési üzenet: amikor az objektum a vezérlést visszaadja , gyakran nem tüntetjük fel. • Randevú üzenet: a fogadó várakozik arra, hogy a küldő üzenetet küldjön neki.
Feltételek, ciklusok… • A diagramon belül beágyazott diagramrésszel ábrázoljuk • A részek alrészekre oszthatók (vízszintes szaggatott vonallal), ha szükséges (pl. feltételnél) • A rész viszonyát az egész diagramhoz a sarkába írt cím jelzi.
118
58. UML – Use Case Diagramm
Use Case Diagram: • Eszköz a rendszer elvárt működésének specifikálásához • Tipikusan a követelmények feltárására használják: Mi az, amit a rendszernek tudnia kell. • Kulcsfogalmak: - Aktor (Actor) - Használati esetek (Use Cases) - Tárgy (Subject) - Kapcsolatok (Connection)
A tárgy • A rendszer maga, olyan szempontból, ahogy a használati esetek alkalmazzák • Jelölése: egy téglalap, melynek határa a rendszer határa
Az aktor • Felhasználók és más rendszerek, amelyek kapcsolatba lépnek a rendszerrel • Mindig a rendszeren kívül van • Szerepet definiál • Nem feltétlenül fizikai entitás Jelölése: - Pálcikaember - Osztályként - Egyéb ikonnal, ami nem emberi voltára utal
Használati eset • A rendszer ajánlott viselkedését írja le • Nem utal a belső struktúrára • Eredménye: - Megváltozik a rendszer állapota - Kommunikáció a környezettel • Aktorokkal működik együtt • Speciális esetei: - alapviselkedés variációja (include) - Kivételes viselkedés, hibakezelés (extend) • Jelölése: ellipszis
Kapcsolatok
119
Kiterjesztési pont (Extension point) • Az extend kapcsolat minden kiterjesztett használati esethez tartalmaz egy kiterjesztési pontot • Meghatározza azt a pontot, ahol a viselkedés bizonyos feltételinél a használati eset kiterjeszthető egy másik használati esettel. • A feltételt és a kiterjesztési pontot az extend kapcsolathoz jegyzetként kell hozzácsatolni (Note Attachment). (UML 2.0-ban)
120
59. UML – Együttműködési diagramm, állapot diagramm
Collaboration Diagram • Objektumok közti interakciót mutatja • Az objektumdiagram és a szekvenciadiagram keresztezése • Szabad elrendezést enged az objektumok között (a szekvenciadiagramtól eltérően) - Így könnyebb adott objektum interakcióit áttekinteni - Az üzenetek időrendben számozottak • Az UML 2.0-ban Communication Diagramnak hívják
Állapotdiagram Elnevezés, eredet: - David Harel dolgozta ki a statechart diagramok alapelvét - Az UML state machine fogalma ezen alapszik • Egyetlen objektum vagy interakció állapotainak sorozatát írja le • Az állapotgép forrásosztályhoz kapcsolódik, és példányainak viselkedését specifikálja
Az állapotdiagram elemei • Állapot • Belépési pont (entry point) • Kilépési pont (exit point) • Átmenet: - Állapotok közötti kapcsolat - Feltüntethetjük rajta: • Az esemény nevét • A feltételt, ami az esemény kiváltásához szükséges • A végbemenő tevékenységeket
Állapotok Egy állapot az objektum az attribútumértékeinek és csatolásainak absztrakciójaként értelmezhető. Egyszerű esetben minden különböző attribútum érték külön állapotnak tekinthető. Általános esetben az attribútum értékek és csatolások halmaza képez egy állapotot. Azon attribútumok, melyek az objektum viselkedését nem befolyásolják, melyek a vezérlésmintára nincsenek hatással, figyelmen kívül hagyhatók. (A vizsgálat szempontjából nem fontosak!) Az objektum viselkedését tekintve az állapot egy időtartamot jelent, mely két esemény között telik el. Az események és az állapotok összetartoznak. Az események állapotokat határolnak, és fordítva, az állapotok eseményeket terminálnak. Úgy az állapotok, mint az események az absztrakciós szint függvényei.
Állapot jelölése: Fontosabb részei: • Név • Be- és kilépési tevékenység (entry/exit) • Belső tevékenység (do)
Események: Az események a külvilágból érkező külső ingerek, melyek a rendszert „stimulálják”, melyekre a rendszernek meghatározott válaszokat kell adnia. Az események lehetnek belső ingerek, melyeket a rendszert alkotó objektumok bocsátanak ki. Az objektumok különböző eseményekre adott válaszai függenek azon objektum állapotától, mely az eseményt észleli. A reakció lehet: 121
• nincs állapotváltozás • állapotváltozás • esemény küldése az eredeti objektumnak • esemény küldése egy harmadik objektumnak Az események bekövetkezhetnek egy másik esemény előtt vagy után (okozati összefüggés). Lehetséges azonban, hogy az események nincsenek hatással egymásra (nincs okozati összefüggés). Az okozati összefüggés nélküli eseményeket párhuzamos eseményekként kezelhetjük. (Az események időpontokat reprezentálnak, időtartam hozzájuk nem rendelhető.) Egy esemény egy információ átvitelként is tekinthető egyik objektumtól egy másik objektumhoz.
Feltételek megadása Egy feltétel egy logikai függvény, mely igaz vagy hamis értéket vehet fel. A feltételek rendelhetők eseményekhez. Az események feltételei mint „őr” viselkednek. Egy „őrzött” átmenet akkor aktív, ha amikor az esemény megtörténik, azzal egy időben a feltétel is igaz. A feltételeket az eseménynév mögött [ ] jelek között adjuk meg.
Műveletek Az események nem csak átmeneteket, hanem műveleteket is kiválthatnak. Műveletek: • Akció (nincs időtartama, eseményhez kapcsolódik). Jelölése: • Aktivitás (időtartammal rendelkezik, állapothoz kapcsolódik). Jelölése:
Bemeneti és Kimeneti akciók Lehetőség van arra, hogy akciókat egy állapotba való belépéssel, vagy abból történő kilépéssel kössünk össze. Jelölés:
Belső akciók Egy esemény akció végrehajtását kiválthatja anélkül, hogy az állapotot elhagyná. Ezen akciókat nevezzük belső akcióknak. Jelölés:
122
60. UML – Aktivitás (activity) diagramm, package diagramm
Aktivációs diagram • Tevékenységek procedurális folyamatait modellezi • Eljárások szekvenciális és konkurens lépéseit írja le • Egy tevékenység összes lehetséges folyamatát mutatja Használható: - Használati esetek részletezésére - Rendszerszintű funkciók modellezésére Fókuszál: - A tevékenységek sorrendjére - A feltételekre, melyek kiváltják a tevékenységeket Jelölések • Tevékenységi állapot: objektum tevékenységét jelöli • Átmenet • Kezdeti állapot • Végállapot • Szinkronizációs vonal: párhuzamos folyamatok elején és végén használjuk • A tevékenységek oszlopokba rendezhetők objektumok vagy feladatok szerint
Package Diagram: Jellemzői: • A rendszert a legmagasabb absztrakciós szinten bontja fel • A logikailag összetartozó UML elemeket (főleg osztályok) csoportosítja • A csomagok között függőségi kapcsolatokat (pl. egyik elem a másikban változást idéz elő, üzenetküldés) ábrázolja Megjegyzés: • A csomagok egymásba ágyazhatók • Jelölés: négyszög füllel • A csomag megfelelője Java környezetben a package, .NET környezetben a namespace
123
61. UML – Komponens diagramm, Konfigurációs (Deployment) diagramm
Komponensdiagram Története: A komponensek lényege új irányt vett az UML 2.0-ban az addigi fizikai szemlélethez képest. Itt a komponensek az elemek fizikai fogalmától elkülönültek, fogalmi modellként használhatók. Halvány különbség van a strukturált osztály és a komponens között.
Komponens UML 2.0-ban • A fizikai és logikai rendszer azon moduláris részeit írja le, amelyek kifelé látható viselkedése jobban leírható, mint a megvalósításuk. • A kifelé látható viselkedéseket interfészek halmaza reprezentálja. • Két nézőpontot mutatnak: - Definiálják a rendszer részeinek külső arculatát - Megvalósítják a rendszer funkcionalitását
Komponens jelölése Két nézet: • Téglalap és a <> kulcsszó • Téglalap benne a komponens ikonnal (az UML 1-es verzióiban ez jelölte a komponenst a téglalap helyett)
Interfészek • Provided interface: olyan összetartozó szolgáltatások halmaza, amelyeket a komponens elérhetővé tesz. • Required interface: a komponensnek meg kell kapnia a szolgáltatást
Az UML verziók komponensdiagramjainak összehasonlítása • Másképp jelölik a komponenst • A komponensek közti függőséget mind a kettő szaggatott nyíllal jelöli • Az UML1 egyfajta interfészt használ, amíg az UML2 másképp jelöli az required interfészt, amellyel egyben a függőséget is kifejezi.
Deployment Diagram • A rendszer futási idejő architektúráját modellezi • A hardverelemek (nodes) konfigurációját mutatja, valamint a szoftverelemek leképzését node-okra. Node: - Erőforrást modellez (pl. számítógép, lemezmeghajtó) - Eszközök és futtatható környezetek ilyenek - Legalább memóriával, gyakran feldolgozó képességgel rendelkeznek
124
62. UML – Composite structure, Kollaborációs, Timing, Interaction Overview diagrammok
Composite Structure Diagram • Struktúra diagram • Az osztály, komponens stb. belső struktúráját és a rendszer más részeihez való kapcsolódását mutatja • Az osztálydiagrammal ellentétben az osztályt alkotó elemek összetételét mutatja: - Interfészek - Portok - Részek - Kollaboráció
Kollaboráció -- Együttmőködés • Semmi köze a Collaboration Diagramhoz, ami az UML1.x-ben volt • Statikus struktúra • Együttműködő részek struktúráját mutatja, amelyek együttesen látnak el kívánt feladatokat • Gyakran patternt valósít meg • Jelölése: szaggatott ellipszis a kollaboráció nevével
Timing Diagram • Viselkedési interakció diagram • A szekvenciadiagram bemutatásának alternatív módja • Explicit mutatja egy életvonalon az állapotokban bekövetkezett változásokat • Valósidejű alkalmazásoknál hasznos
Különbség a szekvenciadiagramhoz képest: • A tengelyen balról jobbra az idő nő • Az életvonalak függőlegesen, elkülönült részekben találhatók • Az életvonal le-fel ugrál, az állapotok változását mutatva • Minden egyes függőleges helyzet külön állapotot jelent • Az állapotok sorrendje nem feltétlen bír jelentéssel
Interaction Interaction Overview Diagram • Viselkedési interakciós diagram • Az aktivációs diagram variációja, mely magában foglalja a szekvenciadiagramot • A szekvenciadiagram jelölését használja az aktivációs diagramból vett döntésekkel és elágazásokkal
125
63. RUP I. (jellemzők, történelem, UML és RUP, módszertan, technológia, eszközök, emberek, szervezeti minták)
Unified Process • Egyesített: A három legelterjedtebb eljárás egyesítésével jött létre • Egységesített: Egységes jelölésmód az egész világon A tervezés során az UML diagramjait használja. Egy kis történelem • OMT (Object Modeling Technique) ─ 1991 James Rumbaugh (General Electric 1994 Rational) • Booch method ─ 1991 Grady Booch (Rational 1981 a Rational alapítása óta) • OOSE (Object-Oriented Systems Engineering) ─ 1992 Ivar Jacobson (Ericson 1987, Rational Software 1995) • UML (Unified Modelling Language) ─ 1997 • RUP (Rational Unified Process) ─ 1998 UML és RUP ismertetése • Booch Grady, Rumbaugh J, Jacobson I: The Unified Modeling Language User Guide, Addison Wesley Longman Inc., Reading Massachusetts, 1998. • Rumbaugh James, Booch G, Jacobson I: The Unified Modeling Language Reference Manual, Addison Wesley Longman Inc., Reading Massachusetts, 1998. Second Edition 2004. • Jacobson Ivar, Rumbaugh J, Booch G,: The Unified Software Development Process, Addison Wesley Longman Inc., Reading Massachusetts, 1999.
Mi a szoftverfejlesztési módszertan? Software Development Process. Megmondja: Ki, mit csinál mikor és hogyan hogy elérje a megadott célt. Az aktuális Technológiákra, Eszközökre, Emberekre, Szervezeti mintákra épít.
Technológia Az eljárásnak technológiára kell épülnie! • Programozási nyelvek, • Operációs rendszerek, • Számítógép rendszerek, • Hálózati lehetőségek, • Fejlesztői környezetek… • Melyek adott időben a rendelkezésünkre állnak. Pl. a 80-as években a vizuális modellezés nem volt realitás, túl drága volt. Kézzel rajzolt diagramokat használtak. Ez nagyban korlátozta a munkát.
Eszközök • Az eljárásnak és az eszközöknek párhuzamosan kell fejlődniük. • Az eszközök beépülnek az eljárásba. • A széles körben alkalmazott eljárás támogathatja, irányíthatja az eszközfejlesztéseket.
Emberek • Az eljárás fejlesztőinek korlátozni kell a készségeket amelyek szükségesek az eljárás használatához, hogy azokat a fejlesztők gyorsan elsajátíthassák. • Sok területen beépíthetünk olyan technikákat, melyek egyszeri beruházást és képzést igényelnek pl. a konzisztencia megőrzés számítógép alapú eszközöknél.
Szervezeti minták • A szoftverfejlesztők nem egyedül dolgoznak. • A folyamat építőinek illeszteni kell az eljárást a napi valósághoz, a virtuális szervezetekhez, melyek egymástól nagy távolságra nagy sebességű hálózatokon kommunikálnak. • Résztulajdonosok, fizetett alkalmazottak, szerződéses munkások, outsourcing, szoftverfejlesztők hiánya.
126
64. RUP II. (a RUP fázisai)
Előkészítés: • Döntés a megvalósíthatóságról. • Egyetértés a követelmény-feltárás eredményében. • Költség, menetrend, prioritások, rizikófaktorok. • Minden kockázat elemezve van és van mérséklő stratégia. Előkészítés / Inseption: • Az áttekintés, a vízió kidolgozva. • Kockázat lista. • Iterációs terv - Tevékenységek időigénye (Gantt diagram) - Erőforrásigény - Függőségek (Gantt diagram) - Részletes terv • Szójegyzék • A legkritikusabb használati esetek • Prototípusok
Kidolgozás: • Az áttekintés és a követelmények rögzítve • A struktúra rögzítve • A tesztelés és az értékelés kulcsfontosságú elemei meghatározva • Az építés fázis ciklusainak terve részletesen kidolgozva • A terv adott szerkezetben történő megvalósítása az áttekintést eredményezi • Az aktuális költségek a tervezett költségeknek megfelelnek Kidolgozás / Elaboration • Néhány végrehajtható prototípus kész. Feltárják a kritikus funkcionalitást, és a szerkezet meghatározó elemeit. • Ismert és nyitott kockázatok csökkenő fontossági sorrendben speciális mérséklési lehetőségek feltárásával. • Software Architecture Document: Különböző szerkezeti nézetek (use case view, logical view, deployment view). • Design Model: Komponensek meghatározva make/buy/reuse figyelembevételével. • Data Model: fontos egyedek, kapcsolatok, táblák. • Implementation Model: Implementation files, Subsystems. • Vision: use casek és szerkezeti tervek alapján átdolgozva. • Design guideline, Programming guideline. Software Architecture Document. • Iterációs terv az építés fázishoz. • Use case model: 80%-ban kész. • Járulékos követelmények dokumentálva és áttekintve.
Építés: • Az összes funkcionalitás kifejlesztve és alpha tesztelve, felhasználói kézikönyv és leírás. Építés / Construction • A rendszer kész a béta tesztelésre. • Imlementation: Minden fájl készen tesztelve. • Iterációs terv az átadás fázishoz. • Design Model: frissítve, az összes követelménynek megfelel. • Data Model: tables, indexes, object-torelational mappings, etc • Járulékos követelmények: frissítve, feltárva. • Use Case Model: frissítve az építés fázis új use case elemeivel.
127
Átadás: • A felhasználó elégedett? • Az aktuális kiadások a tervezett kiadásokhoz képest elfogadhatók?
128
65. Verifikáció és validáció. A verifikáció és a validáció (V&V) azon ellenőrző és elemző folyamatok összessége, amelyek célja annak vizsgálata, hogy a szoftver megfelel a specifikációnak. Ennek része a hagyományos értelemben vett szoftvertesztelés is. Boehm megfogalmazásában: Verifikáció: A terméket jól készítjük el? (a termék megfelel-e a specifikációnak, illetve a funkcionális és nem funkcionális követelményeknek) Validáció: A megfelelő terméket készítjük el? (a termék megfelel-e a vevő elvárásainak, ezért a validáció már a követelmények megfogalmazásánál kezdődik) A V&V végig követi a teljes fejlesztési folyamatot. A V&V folyamaton belül 2 technika használható: 1., A szoftver átvizsgálások: A rendszer fejlesztése során keletkező dokumentumok (követelménydokumentáció, tervek, ábrák, forrássorok, stb.) ellenőrzése. Ezek statikus technikák, mert szükséges hozzá a program futtatása (a korai szakaszban még nincs is program) 2., A szoftver tesztelések: Az elkészült szoftver ellenőrzése különböző tesztadatok futtatásával. Ellenőrizzük a szoftver kimeneteit, a futás közbeni viselkedését és a teljesítményét. Ez ún. dinamikus technika, mivel a szoftver futtatását igényli. A szoftver verifikálásának, validálásának, tesztelésének helye a szoftverfolyamatban:
Átvizsgálási technikák: - Programátvizsgálások - Automatikus forráskód elemzés - Formális verifikáció A statikus technikával csak a program és a specifikáció közötti megfelelőséget tudja vizsgálni. Így nem vizsgálható pl.: a megbízhatóság, teljesítmény. A tesztelés nem nélkülözhető. A tesztelések fajtái: - Hiányosságtesztelés (célja a program és a specifikáció között meglévő hiányosságok felderítése. Célirányos, tervezett vizsgálat.) - Statisztikai tesztelés (célja a program teljesítményének, megbízhatóságának vizsgálata. Tükrözniük kell a valós felhasználói bemeneteket és azok gyakoriságát. Becslés adható a megbízhatóságra a működés 129
közben mért hibák alapján, illetve a teljesítményre a statisztikai tesztadatok feldolgozásánál rögzített paraméterek – pl.: futási idő, válaszidő, stb – alapján) A „belövési” folyamat: A V & V az a folyamat, amelyik megállapítja, hogy a szoftverben vannak-e hiányosságok. A belövés az a folyamat, amely behatárolja és kijavítja ezeket a hiányosságokat. Jellemzők: - Igen magas fokú nyelvi környezet ismeretet igényel - Nehezen algoritmizálható, szabályok nehezen adhatók meg - Speciális célszoftverek segíthetik a hiba megtalálását
A hiba behatárolását követően kijavítjuk, majd rendszert újra validáljuk. Ez lényegében a tesztek újbóli megismétlését jelent, amit szokás regressziós tesztelésnek nevezni. A regressziós tesztelés célja annak vizsgálata, hogy a hiba kijavítása során nem követtünk-e el újabb hibát. A regressziós tesztelés során elvben az összes tesztet megismételjük minden javítási lépés után. A gyakorlatban ez igen nagy ráfordítást igényelne, így csak a módosított rész és annak függőségeihez tartozó teszteseteket ismételjük meg. (Alapos teszt terv és dokumentáció szükséges ennek kivitelezéséhez)
V & V tervezése A V&V igen költséges folyamat, szükséges gondos megtervezése A teszttervek jellemzői: - Áttekintő képet ad a rendszer tesztelési folyamatról - Rendelkezik a felhasználható erőforrásokról - Kötelezően betartandó és irányadó szabványokat és eljárásokat tartalmaz a tesztelésre vonatkozóan - Ellenőrző listákat tartalmaz a tesztelők számára - Információt ad a fejlesztést és az implementálást végzők számára is A teszttervek és s tesztelési fázisok a szoftver folyamatban:
130
Szoftverek átvizsgálása A szoftver átvizsgáláshoz nem kell programot futtatni, így a fejlesztés korai szakaszában, a programok implementációja előtt, verifikációs technikaként használható. Azonban kiterjedhetnek a szoftverfolyamat bármely dokumentumára: követelmény specifikáció, vázlatos és részletes tervekre, adattervekre, teszttervekre, stb. Mit vizsgálhatunk? - Rendszermodellt, Specifikációt, - Magas szintű nyelven megfogalmazott metakódot, - Bármilyen dokumentumot, mely a szoftverfolyamat része A szoftverátvizsgálás jellemzői: - Sokkal olcsóbb a tesztelésnél - Az egyes programelemek elszigetelten vizsgálhatók - Elhanyagolhatók a hibák kölcsönhatásai - A hiba detektálása közvetlenül történik (nem valamilyen rossz értékből derül ki a hiba) - Egyes vizsgálatok szerint az átvizsgálás nem csak olcsóbb, hanem hatékonyabb is mint a tesztelés - Fagan szerint egy program hibáinak 60 százaléka felderíthető átvizsgálással - Az átvizsgálás során a minőség és a szabványoknak való megfelelőség is ellenőrizhető - A dinamikus viselkedés vizsgálatára, a megbízhatóság becslésére nem alkalmas az átvizsgálás - Működési hatékonyság, szűk keresztmetszet nem határozható meg segítségével - A felhasználói felület validálása nem végezhető el az átvizsgálás során - Rendszerszinten a bonyolultság miatt gyakorlatilag nem alkalmazható Mi indokolja az átvizsgálások hatékonyságát? - Egyetlen átvizsgálással több különböző hiba is felderíthető, míg a tesztelés általában tesztenként csak egy hibát hoz ki. - A felhalmozódott tapasztalatok segítenek a kritikus részek ellenőrzésében. (Az átvizsgálást végző, rutinos szakember „tudja, hogy mit kell nézni”) Kritikus programszerkezetek: Pointeres kezelés, több kilépési ponttal rendelkező ciklusok, bonyolult vezérlési szerkezetek. Az átvizsgálás nem helyettesíti a tesztelést, hanem kiegészíti azt!
Programátvizsgálások A programátvizsgálás lényege: egy különböző háttérrel rendelkező tagokból álló csoport a program forráskódját gondosan, sorról, sorra átnézi. Az átvizsgálás célja a hiányosságok, hibák felderítése. Az átvizsgálás egy formális folyamat, melyet egy, legalább 4 főből álló team végez. Különböző szerepkörök definiáltak a csoportban. Fagan szerint: - Szerző (a program vagy dokumentum elkészítésért és a hibák kijavításáért felelős) - Olvasó (felolvassa, illetve elmagyarázza a kódot vagy dokumentumot) - Tesztelő (a tesztelés szempontjából vizsgálja a kódot) - Moderátor (az átvizsgálás folyamatát szervezi, vezeti) Grady és Van Slack, illetve Gilb és Graham egyéb funkciók bevezetését javasolták
131
Az átvizsgálási folyamat:
A programátvizsgálás hatékonyságának jellemzői: - Az áttekint szakasz során kb. 500 LOC/óra tekinthető át. - Az egyéni előkészület során kb. 125 LOC/óra vizsgálható meg - A találkozó során 90-125 LOC/óra vizsgálható át. Az AT&T-nél gyűjtött adatok szerint: - Egy 4 fős csapat 100 LOC-ot kb 1 embernapnyi ráfordítással vizsgál át. - Ha átvizsgálás helyett tesztelnének, akkor több, mint a duplája ráfordításra lenne szükség.
Automatizált statikus elemzés Az automatizált statikus programelemző szoftverek a program forráskódját analizálva derítenek fel hibákat, hiányosságokat. (pl: nem inicializált változók, nem használt változók, a tartományon túlmutató adatértékek) Az automatizált statikus elemzővel felismerhető hibák: - Adathibák (inicializálás, deklarálás, rossz értékadás, stb.) - Vezérlési hibák (hibás vezérlési szerkezetek, ciklusok, nem hívott függvények, eljárások, stb.) - Input/Output hibák (a típusnak nem megfelelő I/O form.) - Interfészhibák (paraméterek típusütközése, stb.) - Tárkezelési hibák (védett területre írás, stb.) A statikus elemzés szakaszai: 1., A vezérlés folyamatának elemzése (többszörös be, illetve kilépési ponttal rendelkező ciklusok vizsgálata, nem használt kódrészek felderítése, stb.) 2., Az adathasználat elemzése (inicializálás nélkül használt változók, kétszer ír egy változóba, de senki nem olvassa, deklarált, de fel nem használt változók felderítése) 3., Interfészelemzés (gyengén típusos nyelveknél használható, pl.: C, a függvény és eljárás deklarációval, paraméterekkel, visszatérési értékekkel kapcsolatos hibákat vizsgálja) 4., Az információáramlás elemzése (a bemenő és kimenő változók közötti függéseket deríti fel, a programban használt értékek származtatását gyűjti ki, ami segítséget nyújthat az átvizsgálásokhoz.) 5., Útvonalelemzés (azonosítja a program összes lehetséges végrehajtási útvonalát, és kigyűjti az ezeken az útvonalakon végrehajtott utasításokat.) Az automatizált statikus elemzőkre különösen azon nyelveknél van szükség, amelyek gyengén típusosak, vagy a fordítójuk kevés ellenőrzést végez. Nem helyettesíti az átvizsgálást, illetve a tesztelést, csak kiegészíti!
132
Implementációs technikák, OOP paradigma
133
66. Osztály, objektum, UML jelölések (Konstruktor, destruktor, példányosítás. Egységbezárás, láthatóságok, tulajdonság. Osztályok láthatósága. Self vagy this.)
Osztály, objektum - Az osztály egy típus megvalósítása. - Az objektum az osztály egy példánya, előfordulása. - Az osztály tartalmazza a adattagok típusainak leírását, amely alapján a konstruktor az objektum számára a helyfoglalást végzi. - Az osztály tartalmazza a metódusok kódját. A metódusokat objektumokra hívjuk meg, és az objektumban tárolt adatokon dolgoznak. (Kivétel statikus metódusok, lásd később.) - Az osztály tartalmazhat további osztály leírásokat. Ezeket beágyazott osztályoknak (nested class) hívjuk.
UML jelölések A komplexSzam objektum a Komplex osztály példánya. - Objektum jele téglalap, neve aláhúzva. Megadható kettőspont után az osztálya, felsorolhatók az adattagok értékei. - Az osztály téglalap, felsorolhatók az adattagok(tagváltozók), tagfüggvények. Neve nincs aláhúzva.
Példányosítás: - Egy osztálynak akárhány példánya, objektuma lehet. - Az objektumok a memóriában más-más területen helyezkednek el. - Az objektum adattagjainak a futás során változik az értéke, változik az objektum állapota. - Egy adott pillanatban több objektum adatai is megegyezhetnek, ilyenkor az objektumok állapota megegyezik
Tagok elérése objektumból: - A látható tagok az objektumból a ‘.’ (->,^) operátor segítségével érhetők el.
Konstruktor - A konstruktor az osztály egy speciális tagfüggvénye. - Feladata: az objektumok létrehozása, inicializálása. Később további feladatok. - Neve megegyezik az osztály nevével. (Kivétel: Delphi ahol elé írjuk, hogy constructor.) - Visszatérési értéke nincs.
134
Destruktor - A destruktor az osztály egy speciális tagfüggvénye. - Feladata: az objektumok felszámolása. - Neve: • C++, C#-ban megegyezik az osztály nevével, előtte egy tilde ~. • Javaban finalize. Osztályszintű tagok felszámolásra a classFinalize használatos. • Delphiben neve tetszőleges, de elé írjuk, hogy destructor - Visszatérési értéke nincs.
Példányosítás: Változó: - Az objektum lehet egy változó. C++: Komplex k; // Létrehoztuk a változót alapértelmezett értékekkel. Komplex k(3,7); // Létrehoztuk a változót a paraméterként megadott értékekkel. k.Show(); // Kiírja az objektum adatait. Delphi: Var k : Komplex; // Létrehoztuk a változót alapértelmezett értékekkel. k:=Komplex.Create(); // Létrehoztuk a változót a paraméterként megadott értékekkel. k.Show(); // Kiírja az objektum adatait. Mutató: - Az objektumra mutathat egy mutató. (C++, Delphi) (C# unsafe kód esetén) C++: - A Komplex* típus egy típusos mutató, Komplex típusú objektumra mutat. A mutató nevét p-vel szokás kezdeni, hogy tudjuk, ez egy mutató. A mutató csak címet tartalmaz, az objektum a new operátor hatására jön létre és delete hatására szűnik meg. Komplex* pK; … pK = new Komplex(3,7); pK->Show(); … delete pK; Referencia: - Az objektumra hivatkozhat egy referencia. C++: Komplex k; Komplex& rK=k; rK.Show(); C#; Java: Az osztály típusú változó, referencia. Komplex k; Komplex k=new Komplex(); k.Show();
135
Egységbezárás (Encapsulation) - Az adatokat és a rajtuk végzett műveleteket egységbe zárja. Ez az egység az osztály. - Az osztály egy típus megvalósítása, mely magába foglalja a típus adattagjait (tagváltozóit), és a rajtuk végezhető műveleteket (tagfüggvények, metódusok). - A láthatóságok vagy hozzáférési szintek (visibility, accessibility) tovább bővítik az egységbezárás lehetőségeit. Segítségükkel megvalósítható az ellenőrzött adatbevitel, adatolvasás. - Az egységbe zárás lehetővé teszi, hogy az osztály adattárolása módosítható legyen, anélkül, hogy az őt használó osztályok kódját módosítanunk kellene. A láthatóságok, hozzáférési szintek (visibility, accessibility): Nem csak az adattagokra vonatkozik, hanem a metódusokra is. • - private: Saját adat. Csak az osztályon belül érhető el. ( metódusokból ) • # protected: Az utódosztályok számára látható. • + public: Mindenki számára elérhető • published (Delphi): Olyan public láthatóság, ami már tervezésidőben elérhető. A komponensalapú programozást támogató láthatóságok: • package: Adott csomagból érhető el. • internal: szerelvényből (assembly) érhető el. • protected internal: szerelvényből és az utódosztályokból érhető el. Az adatok elrejtése (C++): class CA { public: int GetX() {return m_x;}; int GetY(); int SetX(int x); int SetY(int y); … private: int m_x; int m_y; } Tagok elérése objektumból: Adattagokra és metódusokra egységesen hivatkozunk: Proba a; a.x a.Show(); A fordító objektumból csak az objektum számára látható mezőre történő hivatkozást fogad el! Tehát: a. x helyett lekérdezéskor a.GetX(); módosításkor a.SetX(...); hívása szükséges. Egységbe zárás (Encapsulation): - Ellenőrzött adatbevitel, kiolvasás - Csak olvasható adattagok Nem írunk Set... metódust hozzá! - Megváltoztathatjuk az adatszerkezetet, anélkül, hogy az osztályt használó kód változna (Y2K). (public, protected metódusok paraméterlistája nem változik) Elegánsabb megvalósítás a tulajdonság (Property): --------> - A tulajdonság (nagybetűvel) a hívó kódban úgy viselkedik mint egy tagváltozó, de értékadáskor a set metódusa hívódik, míg olvasáskor a get metóduson keresztül jutunk az adathoz. - A tulajdonság segítségével gyakran egy adattag egy részét, vagy több elrejtett adattagban tárolt adatot kezelünk. 136
- Saját készítésű vezérlő esetén a tulajdonság megjelenik a Properties ablakban, kezdőértéke a fejlesztés során kényelmesen állítható be. Alapértelmezett láthatóság (hozzáférési szint): Az alapértelmezés nyelvenként eltérő. - C++, C#: Az osztály alapértelmezésben elrejti a tagokat és csak amiket megengedünk azt láthatjuk kívülről. (Az objektumon keresztül.) Tehát alapértelmezésben (ha nem írunk elé semmit) private lesz a tag. - Delphi: published az alapértelmezett láthatóság. - Java: package, vagyis az egy csomagban levők láthatják. - C++, Delphi: a kulcsszavak kapcsolóként működnek, egyszer kell csak kiírni a következő kiírásig az érvényes. - C#, Java: minden elem elé ki kell írni külön-külön! Az osztálytól eltérő, hasonló típusok: - Struktúra (struct): Főként különböző típusú adatok tárolására használják, de tagfüggvénye is lehet. - Interfész (interface): Nem tartalmaz adattagokat, és nem példányosítható. Alapértelmezett láthatóságuk is eltérő. C#-ban a struct value típusú míg a class referencia típusú változót hoz létre. Nem vesz részt öröklésben. Az interfész: - Nem tartalmaz implementációt, csak deklarációt. (Nincs törzse a fv.-eknek) - Nem tartalmaz adattagot. Tartalmazhat blokk nélküli tulajdonságot (C#) - Tilos kiírni, hogy public, implicit az. interface ImyInterface { void Show(); }
Osztályok láthatósága (C++, Java) - Alapértelmezésben internal/package, vagyis a szerelvény (assembly)/csomag összes osztálya látja, de azon kívül nem látható. - Lehet még public, akkor a szerelvényen/csomagon kívüli osztályok is hozzáférhetnek. - Beágyazott osztály lehet private és protected (protected internal) is. Az osztályok tárolása: A forráskód egy C#: .cs, Java: .java, Delphi: pas kiterjesztésű fájlban tárolódik. C++: Alapvetően két file-ban tárolódnak: - Interface file / Ez általában a header file.: Ebben valósulnak meg a deklarációk és egyéb más információk melyek az osztály használatához szükségesek. - Implementation file / Ez általában a .cpp file: Ez tartalmazza a definíciókat, tehát a tagfüggvények kódját. Tartalmazhat néhány kisebb osztályt. Pl. About. Osztályok és a forráskód: - Jellemzően egy osztály, egy forrásfájl. - A fejlesztői környezet is ezt támogatja. Delphiben csak így élnek a láthatóságok. - Projekt jobbegér / Add / Add class külön az osztály nevével megegyező nevű forrásfájlt hoz létre. Javaban a main-t tartalmazó osztály neve kötelezően azonos a fájl nevével, C#, C++-ban ajánlott. - Van lehetőség egy fájlon belül több osztály definiálására. - Egy osztály belsejében is definiálhatunk további osztályokat. (nested, beágyazott osztályok.) Tagfüggvények implementációja: (A többi nyelvnél nem különül el a deklaráció az implementációtól) - Vagy közvetlenül a deklarációkor, az osztály leírásában, inline függvények. void Add(int addX, int addY) { m_x+= addX; m_y+= addY; }; - Vagy később az osztályra hivatkozva: void CA::Add(int addX, int addY) { m_x+=addX; m_y+=addY;} Ez is lehet inline, ha elé írom! 137
Érték-referencia: C#-ban két féle tagváltozót különböztetünk meg. - Érték típusúak: közvetlenül tartalmazzák az adatokat. Van alapértelmezett kezdőértékük. pl. int, float, char… int i = 0; - Referencia típusok: hivatkozást tartalmaznak egy adatterületre. Két hivatkozás típusú változó hivatkozhat ugyanarra az objektumra. Az egyiken végzett művelet módosítja a másik értékét. Két lépésben hozzuk létre. A referencia változó deklarációja, a new operátor létrehozza az objektumot és a címét a változóba teszi. Button button; button= new Button(); Ha egy hivatkozás típusú változó nem hivatkozik semmire értéke null. Ha fel akarjuk szabadítani az objektum területét, változóját állítsuk null-ra!
A this vagy Self - A metódusok kódja az osztályleírásban tárolódik. - A metódusok az objektum adatain dolgoznak. - Honnét tudják, hogy melyik objektumén? - A nem osztály szintű tagfüggvényeknek van egy láthatatlan paraméterük a this (C++, Java, C#) ill. Self (Pascal). - A this az aktuális objektumra mutat (C++) hivatkozik ( Java, C#). - Javaban és C#-ban gyakran ki is írják this.real, this.x, this.Show(). (IntelliSense) - Ha egy másik objektum tagfüggvényének át akarjuk adni a hívó objektumot paraméterként, a this-t használjuk. - A futásidejű típusinformáció lekérdezésekor is használhatjuk.
138
67. Osztályok csoportosítása (Logikai csoportosítás, fizikai csoportosítás. Névterek. A dll és az assembly. A komponensalapú programozást támogató láthatóságok. Friend kapcsolat.)
Osztályok logikai és fizikai csoportosítása A Java package: - Egyszerre a logikai és a fizikai csoportosítás egysége. - Egy csomagban (package) az egy alkönyvtárban elhelyezkedő fájlokban leírt osztályok. - Mivel nincs fordítás, a forrásfájl és a lefordított (telepített) állomány nem különül el. Névterek (C++, C#): - Help - Contents - Visual Studio .NET - .NET Framework - Reference - Class Library Információk egy osztály névteréről: - Súgó - Az osztály overview (about) ablaka - Mutatja az ős és utódosztályokat - Az oldal végén a Requirements-ben a névteret. Teljesen minősített név: - Fully qualified name: A teljes egymásba ágyazott névtér felsorolás a névvel. System.Windows.Forms.Form - A using direktíva using System.Windows.Forms; után: Form form; Névtér, osztálykönyvtár - Névterek: Az osztályok logikai csoportosítása. Forráskódhoz kapcsolódik. - Osztálykönyvtár: Osztályok gyűjteménye egy fizikai állományba. A lefordított, telepített állományhoz kapcsolódik. • .lib: statikusan szerkeszthető. • .dll: dinamikusan szerkeszthető. - A fizikai csoportosítást az aktuális és a tervezett felhasználás határozza meg. • Többen használják. • Csak bizonyos programrész (user jog) használja. • Gyakori módosítási, frissítési igény.
DLL, dynamic-linked library - Önállóan nem futtatható. - Önállóan fejleszthető. - Több alkalmazás által felhasználható. .NET: - Az .exe csak akkor indul, ha minden felhasznált dll rendelkezésre áll. - Futás közben csak a használt library-t olvassa be. - A különböző verziók helyettesíthetik egymást. Dll használatának előnyei: - Csökken az exe fájl mérete. - Ugyanazt a dll-t több alkalmazás használhatja, akár egyszerre is. Ehhez elég egyszer tárolni. - Hibás dll önállóan javítható, frissíthető az őt használó alkalmazások változatlanul hagyásával. (Frissítések letöltése) - Driver meghajtó dll-ek esetén nem kell előre ismernünk a felhasználó eszközét. Az új láthatóságok tagokra , melyek a moduláris programozást támogatják: - Java: package szintű láthatóság • Jele: ~ - Az adott csomagon belül látható. - A csomagok az osztályok logikai csoportjai. 139
- Tehát az azonos csomagban helyet kapó osztályok férnek hozzá az adathoz. - C#: internal láthatóság - Assembly szintű láthatóság. - Assembly: többnyire egy fordítási egység, exe vagy dll, de lehet több fordítási egység is. Támogatja a verziókezelést. - C#: protected internal láthatóság - A hozzáférés az aktuális assembly vagy az adott osztályból származó osztályok számára.
Friend kapcsolat: „A friend romokba dönti az egységbezárást. Ha olyan helyzetbe kerülünk, hogy egy osztályt egy másik osztály barátjává kell tennünk, akkor először nézzük át a tervet, nem lehetne-e jobban strukturálni.” Guy Eddon, Robert Eddon: Inside Distributed COM Friend lehet: - globális függvény (, operátor) - osztály::tagfüggvény - osztály Ha egy osztály a barátom, minden tagját elérhetem (public, protected, Private tagokat egyaránt.). Deklarálni abban az osztályban kell, amely felajánlja a jogait. A friend kapcsolat nem szimmetrikus. A friend kapcsolat nem tranzitív! - A CC osztály nem barátja a CA-nak!
140
68. Osztály szint tagok (Osztályszint adattagok fogalma, inicializálása. Osztály szint tagfüggvények. Példák osztály szint tagok felhasználására. Singleton pattern)
Osztály szintű tagok Statikus változó (Hagyományos C++): Függvény belső változója statikus. Tehát a változó a függvény végén nem szűnik meg, megtartja értékét, de módosítani csak a függvényből lehet. (Tárolása az adatszegmensben a függvényverem helyett. Tárolása globális, láthatósága lokális.) Osztály szintű (statikus) tagváltozó: - Ez az adattag csak egy példányban jön létre egy osztályon belül, függetlenül az objektumok számától. - A ‘static’ módosítóval deklaráljuk. - Globális az adott osztálytípusra nézve, az egyik objektum megváltoztatja az értékét, tehát mindben megváltozik az. Használjuk null referenciák létrehozásához (C#). Pl. a Stream osztály NULL adattagja:public static readonly Stream Null; Ha az adatfolyamot nem kívánjuk erőforrásra irányítani akkor használjuk. Ha írunk bele, nem ír, egyszerűen visszatér, ha olvasunk belőle nullával tér vissza anélkül, hogy olvasna. Pl. a Missing osztály Value adattagja public static readonly Missing Value; Ez az egyetlen példánya a Missing (sealed) osztálynak. Arra használjuk, hogy egy metódust alapértelmezett argumentumokkal hívjunk meg. Statikus adattag inicializálása (C++): - Az összes függvényen kívül, mint a globális változóknál - Csak egyszer inicializáljuk. (nem .h, .cpp) - Osztálynév és ::operátorral int CA::m_n = 5; - Az adat nem az objektumokban tárolódik, így nem inicializálhatja a konstruktor. Tiszta objektumorientált nyelvekben (C#, Java): - Statikus konstruktorban. • A statikus konstruktor osztályt inicializál. • Meghívódik az első példány létrehozása előtt, vagy bármely osztály szintű tag hivatkozása előtt. • Nincs láthatósága, paramétere. • Neve azonos az osztály nevével, előtte a static kulcsszó. • Közvetlenül nem hívható. - Felszámolása statikus destruktorban. • Java: Osztályszintű tagok felszámolásra a classFinalize használatos
Osztály szintű (statikus) tagfüggvények: – – – –
Csak statikus adattagokat érhetnek el. Akkor is hívhatók, ha nincs objektumunk. A tiszta objektumorientált nyelvek a hagyományosan globális tagfüggvényeket így valósítják meg. Pl. Main() Akkor hívjuk, amikor még nincs objektumunk. Feladata a főablak létrehozása (C#): static void Main() { Application.Run(new MyForm()); } Figyelem! Nem azonos a Delphiben statikusnak nevezett nem virtuális metódussal!
Singleton (Egyke) osztály - Olyan osztály, melyből pontosan egy példány hozható létre. - Van egy osztályszintű adattagja, mely tárolja az egyetlen példányt. - Van egy osztály szintű metódusa Instance(), mely visszaad egy mutatót a példányra. 141
- Van egy protected konstruktora, ezt hívja az Instance, ha még nincs példányunk C++: class Singleton { public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; }; Singleton* Singleton::_instance = 0; Singleton* Singleton::Instance(); { if (_instance == 0) { _instance = new Singleton; } return _instance; }
142
69. Konstruktorok (Konstruktor, destruktor hívások sorrendje öröklés és asszociációs kapcsolat, többszörös öröklés esetén. Default és felülírt konstruktorok. Taginicializáló lista. A konstruktor, destruktor feladatai virtuális metódushívás esetén.)
Konstruktor (constructor) Pascal, Delphi: - A konstruktort a constructor deklarációval adja meg, és kötelezően a program kódból kell hívni. - A következőkben a C++, Java, C# konstruktorokról lesz szó. A konstruktor neve azonos az osztály nevével. Pl. CA(), és nincs visszatérési típusa. Több konstruktor lehet (fv. Overloading) Alapértelmezett ( default ) aminek nincs paramétere. Ha nincs megadva konstruktor, a rendszer generálja az alapértelmezettet, (mely nem végez értékadást…const, &) Ha írtunk paraméterezettet, a rendszer nem generál! A statikus tagokat statikus konstruktor inicializálja. A konstruktor feladata: - A fordító felelőssége: Érték típusú adatok esetén: • Az adattagok helyének lefoglalása. • Az adattagok konstruktorainak hívása. C++ - A programozó lehetősége: Referencia és mutató típusú adatok esetén: • Az adattagok helyének lefoglalása new és az adattagok konstruktorainak hívásával. • Az adattagok inicializálása. • Az előkészítő tevékenységek elvégzése. Konstruktor implementációja: class CA {public: CA() { m_x = 1; m_y = 2; }; CA(int x, int y) { m_x = x; m_y = y; }; … private: int m_x, m_y; } Konstruktor hívása: - C++-ban a hozzáférés szintje többnyire: public - Hívása C++-ban az objektum létrejöttekor CA a; CA a(1,5); C++ pointer esetén new hívásakor CA* pa; pa= new CA(1,5); - Java C# esetén a new hívásakor jön létre az objektum. - A konstruktor más tagfüggvényből tagfüggvényként nem hívható! Nincs értelmes eset! - Paramétert adhatunk meg konstruktorral: Application.Run(new MyForm()); C# Ellipse(CRect(10,10, 100,120)); Visual C++ Másoló konstruktor, Copy construktor: - Objektumot vele azonos típusúval inicializál - Használjuk: • Definícióban CA a; ... CA a1(a); • Függvényargumentumok feltöltésekor. • Visszatérési érték átadásakor. - C# a Clone metódussal valósítja meg.
Destruktor (destructor) A destruktor neve azonos az osztály nevével, de előtte a ‘tilde’ ~. Pl. ~CA(); - Ha nem adjuk meg mi, a rendszer generálja - Hívása automatikus az objektum megszűnésekor. A destruktornak nincs visszatérési értéke. 143
Destruktor hívása: C++: - Lokális objektumok esetén a blokk végén. - Dinamikus objektum estén a delete hívja. - Legyen mindig virtuális! Java, C#: - Az automatikus szemétgyűjtő hívja ismeretlen időben. - Ezért nem paraméterezhetjük. - Minden osztálynak pontosan egy destruktora van C++-ban és legfeljebb egy C#-ban. - C#-ban csak akkor írunk destruktort, ha nem menedzselt erőforrásokra hivatkozik az objektum. - C#-ban nem engedi a virtual módosító használatát destruktor esetén! A destruktor feladata: - A programozó lehetősége: • Befejező tevékenységek elvégzése. Pl. C++-ban: mutató adattag, esetén a megcímzett memória felszabadítása kötelező. C#-ban nem menedzselt erőforrások felszabadítása. - A fordító felelőssége: • A tartalmazott objektumok destruktor hívása. • Az objektum helyének felszabadítása, vagy nem elérhetőre állítása a szemétgyűjtő számára.
Konstruktorok az öröklésben - Sem a konstruktor, sem a destruktor nem öröklődik, viszont automatikusan hívják az ősöket. - Konstruktor az öröklés során csak az alapértelmezett őskonstruktort tudja elérni külön hívás nélkül, ha van ilyen! Konstruktor / Destruktor: - CC c; objektum létrehozásakor - Először CA() - Majd CB() - Majd CC() blokkja hajtódik végre. - Destruktorok esetén a sorrend: ~CC(); ~CB(); ~CA(); Ha az ősosztálynak nincs alapértelmezett konstruktora (C#) akkor a taginicializáló listában meghívhatjuk a paraméterezett őskonstruktort C#-ban is. A konstruktor feladatai: - A fordító felelőssége: • A közvetlen ősosztályok konstruktorainak hívása. • Az (új) adattagok helyének lefoglalása. C++ • Az (új) adattagok konstruktorainak hívása. C++ - A programozó lehetősége: • A taginicializáló listában meghatározni az ősosztály(ok) paraméterezett konstruktorhívását. C++: - A taginicializáló listában meghatározni az adattagok paraméterezett konstruktorhívásait. Referencia és mutató típusú adatok esetén: • Az adattagok helyének lefoglalása new és az adattagok konstruktorainak hívásával. • Az adattagok inicializálása • Az előkészítő tevékenységek elvégzése A destruktor feladatai: - A programozó lehetősége: • Befejező tevékenységek elvégzése. Pl. C++-ban: mutató adattag, esetén a megcímzett memória 144
felszabadítása kötelező. C#-ban nem menedzselt erőforrások felszabadítása. - A fordító felelőssége: • A tartalmazott, az adott osztályban létrehozott objektumok destruktor hívása. • Az adott osztályban létrehozott adattagok helyének felszabadítása.. • A közvetlen ősosztályok destruktorainak hívása.
Virtuális metódushívás esetén: A konstruktor feladatai: - A fordító felelőssége: • A közvetlen ősosztályok konstruktorainak hívása • A __vfptr mutató beállítása úgy, hogy az osztály VMT-jére mutasson • Az (új) adattagok helyének lefoglalása • Az (új) adattagok konstruktorainak hívása. Utódosztálynál minden konstruktor a saját osztályára állítja, de végül a létrehozott objektum osztályának VMT-jére mutat. - A programozó lehetősége: • A taginicializáló listában meghatározni az ősosztály(ok) paraméterezett konstruktorhívását. • A taginicializáló listában meghatározni az adattagok paraméterezett konstruktor-hívásait. • Az adattagok inicializálása. • Az előkészítő tevékenységek elvégzése. A destruktor feladatai: - A programozó lehetősége: • Befejező tevékenységek elvégzése. Pl. dinamikus adattag esetén a megcímzett memória felszabadítása kötelező. - A fordító felelőssége: • A tartalmazott, az adott osztályban létrehozott objektumok destruktor hívása. • Az adott osztályban létrehozott adattagok helyének felszabadítása. • A __vfptr mutató beállítása úgy, hogy az ősosztály VMT-jére mutasson. • A közvetlen ősosztályok destruktorainak hívása. Csak virtuális destruktort készítsünk! - Ha az ősosztály mutatója egy utódra mutat, a végrehajtandó destruktor kiolvasása a VMTből. CA *pa; …p…pa = new CB; delete pa; - Ha a destruktor nem virtuális, a mutató típusának megfelelő osztály destruktora hívódik meg. Ha nincs polimorfizmus!
145
70. Hivatkozás és érték típusok (Hivatkozás típusú tagok inicializálása. Hivatkozás és érték típusok közti különbség. Automatikus szemétgyűjtés. A hivatkozás argumentum és visszatérési érték. Konstansok.)
Hivatkozás (referencia) típus (&) - A referencia egy alternatív név egy változó eléréshez. - Kötelező inicializálni! int osztalyzat = 5; int& jegy= osztalyzat; // jegy = 5 jegy = 3; // osztalyzat = 3 int& jegy ≡ int &jegy ≡ int&jegy • Változóval kell inicializálni! • Később nem irányítható át más változóra Érték szerinti paraméter-átadás: void incr ( int a) { a++; …} … int x = 2; incr( x ); Hivatkozás típusú függvényparaméter: - Jóval kényelmesebb, mint a mutató, híváskor is, és a fv. belsejében is!
Hivatkozás argumentum, visszatérés: - Hatékonyság: Nagyméretű változók esetén akkor is használjuk, ha függvény nem módosítja az értékét, (ekkor const deklarációval) - Pascal : Cím szerinti paraméterátadás - Típuskonverzió esetén a másolaton dolgozik! Referencia típusú visszatérési érték: típus& tagfüggvény() { return tagváltozó;} - Értékadás jobb oldalán: végrehajtja a hozzárendelt utasítás sorozatot - Értékadás bal oldalán a változó referenciájaként működik Pl. tömb indexoperátora [ ] írjuk is, olvassuk is - Használata pl. a kiviteli operátorok egymás után fűzését teszi lehetővé. ostream& operator << (ostream& os, CA& a ) Mutató hivatkozás: - Mutatóval a mutató által címzett változó módosítható - Mi magát a mutatót szeretnénk módosítani! - int *&p1: p1 hivatkozás egy int típusú mutatóra. Csere(int *&p1, int *&p2) A csere után a p1 mutat arra amire eddig p2
146
A ref, in, out módosítók: - in: alapértelmezés, érték típusoknál az érték, referenciáknál a referencia átadása. Érték típusoknál, ha nem akarjuk, hogy a függvény módosítása érvényesüljön az átadott változón is, vagy ha nem várjuk az érték visszaadását. - out: nincs kezdőérték, csak a visszaadott érték a fontos. - ref: kötelező változóval inicializálni. A függvényben végrehajtott változások az átadott változón is végbemennek. (Jelentősége érték típusú változók esetén.) Mivel csak kezdőértékkel hívható, ilyenkor null nem adható át az objektum helyett. Null helyett pl. a Missing.Value értéket adhatjuk át. Objektum inicializálásának problémái: - Osztály deklarálásakor nem inicializálhatjuk a tagokat, mert itt csak a típust adjuk meg, a helyfoglalás az objektum létrejöttekor történik. - A const, és a hivatkozás típusú adattagok esetén azok inicializálása a deklaráláskor kötelező. - A konstruktor belsejében végrehajtott értékadás const esetén tilos, hivatkozás esetén pedig már a változónak adna értéket, melyre hivatkozunk, (miközben még nem mondtuk meg, melyik ez a változó) Taginicializáló lista (C++, C#): - Az adatokat értékadás nélkül inicializálja. class CC {public: CC(int par) : n(par), db(5), rn(n) {…} private:int n; const int db; int& rn; … } Tagobjektumok inicializálása: Feltétele: - A tartalmazott objektum osztályának nincs konstruktora. - A tartalmazott objektum osztályának van default kostruktora. - A tartalmazó osztály minden konstruktora taginicializáló listával inicializálja a tartalmazott bjektumot.
Konstansok ( const ): - Literál: egyszerű, rögzített értékek. (3, „alma”, 2.8) - C++: #define aaa 5: 5 értéket másol az ‘aaa’-val jelölt helyre a fordító, nincs memória címe! - Olyan változók, melyek értéke nem változtatható. (konstans kifejezések) (Kezdőértéket kaphatnak, értéket nem.) - Definíciókor értéket kell kapniuk int i = 3; const int j = 5; const int k = i; const int l = 2 * sizeof (long) Nyomkövető programokkal megtekinthetők A readonly módosító: - A const tagok értékadása fordítási időben történik, ezért referencia típusok estén a new kulcsszóval nem inicializálhatók. (String, null). A static módosító nem engedélyezett const-ra. - A readonly értéke sem módosítható, de a deklarációkor vagy a konstruktorban inicializálható. Tehát futásidőben különböző kezdőértéket kaphat. A readonly lehet statikus. - A const-ot szokták fordításidjű (compile-time) konstansnak, míg a readonly-t futásidejű konstansnak nevezni. public static readonly uint t = (uint) DateTime.Now.Ticks;
147
Konstans mutatók: - const int * pa; - Egy konstans egészre mutat rá. A mutató értéke változhat, amire mutat, annak az értéke nem int a = 5; pa = &a; *pa = 3; Hibás! int b = 1; pa = &b; Lehet! - int* const pa; - A mutató konstans, nem a mutatott érték. pa= &b Hibás! *pa= 3; Lehet! Konstans hivatkozás: - int a=1; int b=5; - const int& ha = a; - ha = 3; Hibás! - ha = b; Hibás! Mivel const az általa hivatkozott érték nem módosítható. A hivatkozott változó egyébként sem módosítható. Konstans objektum mutatón, vagy hivatkozáson keresztül nem módosítható, mert csak konstans mutató (referencia) mutathat rá. Konstansok a paraméterlistában: - Objektumokat általában hivatkozás típussal adunk át (és vissza) függvényeknek (hatékonyság) - Ha azt akarjuk, hogy a függvény mégse módosíthassa az objektumot, const hivatkozásként kell átadni! - Bár csak a címet adtuk át, nem másoltunk sokat, az érték mégsem változhat Konstans objektumok: - const CA a ( 2, 3 ); - Azt jelenti, az objektum adattagjainak értéke nem változtatható meg - A fordító nem tudhatja melyik tagfüggvény tenné ezt meg, tehát csak a const-ra deklarált tagfüggvényeket engedi meghívni. - void Show() const; A fordító ellenőrzi a kódot, történik-e benne értékadás. - A osztályleírásban is inicializálhatjuk a tagokat. - Az osztályleírás inicializálása még a konstruktor blokkja előtt végrehajtódik. (Mint a C++ taginicializáló lista) - Konstans tagokat kötelező az osztályleírásban inicializálni. - Konstans tagok a függvényekből nem módosíthatók.
148
71. Öröklés (Öröklés fogalma, UML jelölése. Specializáció és absztrakció. Adatvédelem az öröklés során. Függvény felüldefiniálás (elrejtés) az utódosztályokban. Hatókör feloldó operátor vagy base. Többszörös öröklés és problémái. Lezárt osztályok.)
Öröklés - Lényege: Az utódosztály objektuma mindent tud amit az ősobjektum tudott. - Célja: • Új adatok tárolása • Új tagfüggvények létrehozása • A meglevő tagfüggvények módosítása - Módja csak C++-ban: public, protected, private. - class CB: public CA {...} 4 Interfészek: - Ienumerable • Egyszerű lépkedést támogat a listában • GetEnumerator() visszaadja az IEnumerator iterátort - Ienumerator • Az enumerálható listák iterátora • Current(), MoveNext(), Reset() Ha iterálható osztályt akarunk készíteni, akkor azt az Ienumerable interfészből származtassuk! Iterálható osztály az, amire alkalmazható a foreach ciklus - ICollection (IEnumerable-ből származik) • Count(), CopyTo(), IsSynchronized(), SyncRoot - IDictionary (ICollection-ből származik): Alap asszociációs tömb • Kulcs-érték párok táblázata • Az Item indexer a kulcs szerinti értéket keresi elő • Add(), Remove(), Contains() és Clear() függvények - IList (ICollection-ből származik) • Olyan gyűjtemény, melynek elemeit külön is lehet indexelni (A lista adatszerkezettel ellentétben) • Az Item indexer az index szerinti értéket keresi elő • Add(), Remove(), Contains() Clear() UML jelölése: Protected védelem: Csak az utódok számára engedélyezi a hozzáférést - Az utódok számára public - Minden más esetben private Láthatóságok szűkítése C++-ban: Az öröklés típusa szűkítheti az ősosztály jogosultságait: Minden az ősben elérhető tag: - public: a saját védettségével. - protected: protected védettséggel. - private: private védetséggel érhető el az utódban. Alapértelmezés öröklésnél is: private
Private öröklés - Ha szűkíteni akarjuk az osztály lehetőségeit, de az új osztály készítésekor még élni akarunk velük. Pl. CList-ből CStack osztály, majd további vermek.
149
Hatókör (scope) operátor :: (C++): - A metódushívás elé írva az ősosztály nevét és a :: operátort, az adott osztály ilyen nevű metódusa hívódik (Ha nincs ilyen sajátja, keresés az ősökben) - CC-ben: CB::Draw(), c.CB::Draw() - Ha nem írunk elé osztálynevet, akkor ilyen nevű globális függvényt keres. - Osztály belsejében: ::Show() C# esetén a base.metódusnév helyettesíti. Ott nincs globális függvény, tiszta objektumorientált nyelv.
Metódusok felülírása: - Az utódosztály metódusa másként működjön, mint az ősé! - A láthatóság is tetszőlegesen módosítható Adattagok nem írhatók felül! Új adattagok hozzáadása nem felülírást jelent, hanem újabb mezőket az objektumban.
Többszörös öröklés - Egy osztálynak több közvetett őse lehet - Előnye, egyszerre több osztály tulajdonságait hasznosíthatjuk Többszörös öröklés problémái - Ha van azonos nevű tag, melyiket hívjuk? - Az ősök közös őse estén • A közös metódusok esetleg többféleképp felüldefiniáltak! • Közös adattagok dupla tárolása, mikor melyikre hivatkozunk? - Megoldás: Osztályhivatkozással - Felülírással (adattag estén megéri-e?) Többszörös öröklés a nyelvekben: - A tanult nyelvek közül a C++ valósítja meg (Eiffel) - Java, C#, Delphi interfészek esetén engedélyezi. - Mivel interfész nem tartalmaz tagváltozót és függvény implementációt, ezért a felvetett konfliktusok itt nem állnak elő. Virtuális öröklés: Előre kell gondolni rá: class CB : virtual public CA {...}; class CB1 : virtual public CA {...}; - Az alaposztály (CA) adattagjai egy független struktúrában érhetők el egy mutató segítségével - CA konstruktorát nem CB és CB1 hívják, hanem CC konstruktora.
150
Osztályok láthatósága: - Az utódosztály nem lehet bővebb hozzáférésű, mint az őse volt, hisz az utód létrehozásához szükséges az ős. - Internal ősnek nem lehet public utóda, fordítva igen! - Minden osztály az Object utóda akkor is, ha azt explicite nem írjuk ki! Lezárt osztályok: Vannak kifejezetten öröklés céljából készített osztályok, mint az abstract osztályok és az interface. (A virtuális függvények kapcsán később.) Vannak lezárt (sealed) osztályok, melyekre nem engedélyezzük az utódosztály létrehozását. - Lezárt osztály nem lehet absztrakt osztály. - A kód futásidejű hatékonyságát növeli, ha nem használ virtuális tagfüggvényeket. - Sealed osztályban értelmetlen a protected láthatóság. - Fordítási hiba keletkezik, ha lezárt osztályból származtatunk. (C#) - Ha egy osztály csak statikus tagfüggvényeket tartalmaz deklaráljuk lezártként! - A struktúrák explicit a sealed módosítóval vannak ellátva, így nem származtathatók belőlük osztályok. (C#) A C# sealed osztályai: - String - GC - Application - Missing
151
72. Nem virtuális, virtuális metódusok (Virtuális és nem virtuális metódusok viselkedése közti különbség. Fordításidejű, futásidejű kötés. Polimorfizmus. VMT. Virtualitás lehetőségei a különböző nyelvekben. Statikus metódus és virtuális metódus kapcsolata. Lezárt metódusok. Komponensek új verziói és a virtualitás.)
Nem virtuális metódusok Javaban minden példánymetódus virtuális!!! CA a; CB b; a.Show(); b.Show(); b.Add(10); Mutató / referencia típusa, vagy az objektumé? Bár pa CB típusú objektumra mutat, mégis CA Show metódusát hívjuk! Megoldás: virtuális metódus.
Virtuális metódusok Az objektum típusa határozza meg a hívást. Mivel Show virtuális, a CB osztály metódusa hívódik meg. Megvalósítás: - Szintaxis: virtual void Show(); - Ha egy metódus virtuális, minden utódosztályban virtuális kell legyen. - Elegendő (, de nem ajánlott) az első deklarációkor megadni. - Ha egy objektum osztályának van virtuális metódusa, akkor van egy a VMT-re mutató adattagja is. __vfptr: virtual function pointer
Futás idejű kötés (Runtime binding) CA fordításakor nem dől el melyik Show-t hívja az Add. Ha Show virtuális, b.Add hívásakor a CB Show függvénye hívódik meg. Egy ős mutató rámutathat utódra is. Futásidőben dönthető el mire mutasson. Futásidőben dől el melyik virtuális fv-t hívja.
Polimorfizmus (többalakúság)
152
Polimorfizmus:
v-table, vagy VMT (Virtual Method Table) - Virtuális metódusok címét az osztályok a virtuális metódus táblában tárolják (VMT). - Ha virtuális metódust hívunk, a címét az objektum osztályának megfelelő VMT-ből nézi ki futásidőben a program. A virtuális tagfüggvények címének tárolása: - Ha egy osztályban van virtuális tagfüggvény, van VMT is, mely tartalmazza a virtuális függvények címeit - VMT: osztályonként tárolva - Ha egy osztálynak van VMT-je objektumainak van __vfptr adattagja, mely a VMT-re mutat. VMT és __vfptr: CB osztály VMT-je: class CB public CA CB::Show() CA::AddX() CB::~CB()
Ha statikus, nem lehet virtuális - Osztály szintű metódus nem lehet virtuális - Mert nem objektumból indul, így nincs this, nincs __vfptr. - Így az utódosztályok számára nem biztosítja a polimorfizmust. C++ más implementáció: - VMT helyett minden objektumban tároljuk a virtuális metódusok címét. - Az objektumok mérete megnő, de ha kevés objektum van ez nem jelentős. VMT helye felszabadul. - A program sebessége minden virtuális függvényhíváskor egy lépéssel gyorsabb lesz.
153
Java: - Javaban a példánymetódusok mind virtuálisak. Ezért nincs virtual kulcsszó. - Osztálymetódusnál ennek nincs értelme, az adott osztályé hívódik meg mindig. Egyszerű, de rontja a hatékonyságot, hisz a virtuális függvényhívás időigényesebb. C#: Bár a C# egyszerűbb mint a C++, a virtualitás fontosságát felismerve, bővíti a lehetőségeket. - Alapértelmezésben a függvények nem virtuálisak. public void Show(){…} - public virtual void Show(){…} - public override void Show(){…} // Felüldefiniál. Csak ha az ősben van virtual, abstract vagy override azonos szignatúrájú, nem private láthatóságú, azonos visszatérési típussal és láthatósággal rendelkező metódus. - public virtual void Show(){…} - public virtual void Show() {…}//warning! Elrejti, de nem felüldefiniálja az ős függvényt. (new virtualként értelmezi) Helyette: - new public virtual void Show() {…} //Elrejti, de nem felüldefiniálja az ős függvényt. Új virtuális függvényt hoz létre. - new public void Show() {…} // Elrejti, az ős függvényt, egy új nem virtuális függvényt hoz létre. - public override void Show() {…} // Felüldefiniálja a az utolsó virtuális függvényt, még akkor is, ha azt közben egy nem virtuális elrejtette.
154
73. Az értékadás problémái (s típusú referencia/mutató utód típusú objektumra hivatkozik/mutat. Típuskényszerítés. Az ‘is’ és az ‘as’ operátor. Hozzon példákat az osztálykönyvtárból az elv alkalmazására!)
Értékadás - Ős objektum értékül kaphat utódot • Minden adatmező feltöltődik • Minden metódus hibátlanul végrehajtható - CA a; CB b; a = b; Hiba a b=a! - Mutatók és referenciák esetén is így! - CA* pa; CB* pb; pa=pb; Hiba a pb = pa; !!
Ős mutató/referencia utód objektumokra mutat / hivatkozik
Típuskényszerítés
- A típuskényszerítés gyakran előforduló esete: több különböző vezérlőn bekövetkező többnyire azonos eseményhez ugyanazt az eseménykezelő metódust csatoljuk, és • az esemény kezelésekor le akarjuk kérdezni a küldő vezérlő állapotát, vagy • az esemény hatására a küldő vezérlő állapota változik. Az is operátorral eldönthetjük, hogy az adott típusra kényszerítés végrehajtható-e. Vagyis igaz értéket ad vissza, ha adott típusú, vagy utód típusú. static void Main(string[] args) { if (a is CB) // Ha a CC akkor is igaz. ((CB)a).m_r = 11; } Az as operátorral az adott típusra konvertáljuk, ha ez lehetséges, egyébként null értékkel tér vissza. CB b = a as CB; if (b != null) // Ha a CC akkor is igaz. b.m_r = 11;
155
74. Absztrakt interfész (Absztrakt függvény. Absztrakt osztály. Interfész fogalma. Szerepük az öröklésben. Azonosság és különbség az interfész és az absztrakt osztály között.)
Absztrakt tagfüggvény - Pure Virtual Function (tiszta virtuális fv.) - Olyan virtuális metódus, melynek mutatója NULL, tehát nem tartozik hozzá kód. (CView::OnDraw) - Valamely utódban kötelező felülírni. - Az utód használhatja az ősben megírt többi tagfüggvényt, melyek az absztraktra hivatkoznak. - Szintaxis: C++: virtual void Absztrakt() = 0; C#: abstract void Fv(); - UML jelölése: Dőlt betű
Absztrakt osztály - Mely legalább egy absztrakt metódust tartalmaz. - Az ‘abstract’ deklarációt elé írjuk. - Csak absztrakt osztályok tartalmazhatnak absztrakt metódusokat. - Minden implementált metódusnak az absztrakt metóssal azonos számú, típusú és sorrendű argumentummal és azonos visszatérési típussal kell rendelkeznie. - Nem lehet példányt (objektumot) létrehozni belőle (a fordító nem engedi). - Csak örökítésre használatos. - Konstruktora lehet protected. - UML jelölése: Dőlt betű CView osztály: - Bár semmilyen adatot semmilyen módon megjeleníteni nem tud. - A OnDraw metódusa absztrakt. - A többi osztállyal a kapcsolattartás biztosított. (GetDocument, GetParentFrame, GetActiveView...) Absztrakt osztályok: - Stream • CanRead, CanWrite, CanSeek • Length, Position • Read, Seek, Write - TextReader • Nincs absztrakt metódusa - TextWriter • Nincs absztrakt metódusa
Interfészek - Minden tag public, így nem is jelöljük. - A tagfüggvények csak deklarációk, nincs implementációjuk. Absztraktak. - Származhat több interfészből. - Több interfész is lehet egy öröklésben ős. - A nevüket I betűvel kezdjük. - Ha az öröklésben ősosztály és interfész is részt vesz, az osztályt kötelező első helyen megadni. (C#) - Feladata a komponensek közötti kapcsolattartás. - Az implementáció elrejtésére használjuk. - Metódust nem adhatunk interfészhez. (UtódInterfész)
156
Interfészek vagy absztrakt osztályok:
157
75. Kivételkezelés (A kivételkezelés fogalma. Kivétel dobása, elkapása. Különböző típusú kivételek. Kezeletlen kivétel. Egymásba ágyazott kivételek. Egy választott osztálykönyvtár és a kivételkezelés.)
Kivételkezelés (Exception handling): Kivételkezelés: - Az összes tanult nyelvben. - A strukturált programozási paradigma azt várja el, hogy a problémák megoldása során derítsük fel az összes előforduló esetet. - A kivételkezelés lényege: hogy foglalkozzunk a problémák lényegi megoldásával és a ritkán előforduló hibás vagy speciális (kivételes) eseteket a kód egy elkülönített részében oldjuk meg. - Ez a gondolkodásmód megjelenik a Unified Process Use case diagramjainál is. - A kivételkezelés az objektumorientált szemléletben nagyon elterjedt, mert a problémák megoldására egy rendkívül kényelmes és intelligens lehetőséget kínál. - Nem várt események kezelése - A normális program végrehajtásának megszakadása, váratlan, vagy szokatlan esemény hatására. - PL. • 0-val való osztás, • Nem létező memóriacím elérése, • Egy API függvény végrehajtási hibája (érvénytelen cím/azonosító), • Nem létező fájl nyitása olvasásra, • Saját kivételeink. Kivétel létrehozása, dobása: - throw érték - Érték: • Lehet: konstans, változó, objektum... • Információk, melyet a kivételkezelőben felhasználhatunk. char *buffer = new char [1000]; if (buffer = = 0 ) throw “out of memory”; Ha létrejön a kivétel: - és nincs kivételkezelő, akkor a futásidejű könyvtár terminate( ) „ abnormal program termination” majd kilép - Mi kezeljük a kivételt try { } catch ( ) { } - A try blokkhoz tartozhat egy finally klauza is, ami végrehajtódik, akár volt kivételdobás, akár nem. Ide írjuk pl. a megnyitott fájl lezárását… Saját kivételkezelés: - Ha a try blokkjában bárhol kivétel keletkezik, - A try blokk végrehajtása véget ér, - Ha van a try-t követő catch, az hajtódik végre, majd a blokkot követő első utasítás. - Ha az argumentum típusok nem egyeznek, másik kivételkezelő-t próbál hívni. - try és catch esetén az alapértelmezett kivételkezelés nem fut le. Nem keletkezett kivétel: - A catch nem fut le, - A program a catch utáni első utasításon folytatódik. Több különböző típusú kivétel: - Egynél több catch! - pl.: catch ( char *ErrorMsg ) { } catch ( int ErrorCode ) { } - Tetszőleges típusú kivétel lekezelése de nincs segítő paraméter: 158
C++: catch ( ... ) { } C#: catch { } A program a kód sorrendjében keres, az első megfelelő catch végrehajtása után a további catch blokkokon átugrik! Kezeletlen kivétel: - Azonos típusú, de különböző értékű kivételek esetén előfordulhat, hogy a kivételek egy részét le tudjuk kezelni, más részét tovább dobjuk. - A catch blokk belsejében paraméter nélküli throw; - Újabb ugyanolyan típusú és paraméter értékű kivétel bekövetkezése. - A program kilép a catch blokkból és újabb kivételkezelőt próbál futtatni. Egymásba ágyazott try blokkok: - A kivételek tetszőleges mélységig egymásba ágyazhatók. - A try blokkból hívott tetszőleges mélységig egymásba ágyazott függvényhívások kivételei bármely szinten elkaphatók. • Ezt használjuk az OOP-ben. A készen kapott osztályok kivételeit mi kezelhetjük le. • Pl. a fájl nyitás kódját készen kapjuk, ha a fájl nem létezik, mi dönthetjük el, hogy esetleg egy másik szerveren keressük, vagy mivel helyettesítjük. - Először a legbelső try blokkhoz tartozó catch-ek között keres - Ha nem talált itt, vagy újabb kivétel jött létre, a következő legbelső catch-ek - Ha sehol nem talál megfelelő catch blokkot, akkor terminate hívás. Az osztálykönyvtár által dobott kivételek: - A help megadja a kivétel típusát System.IO.File osztály Open metódusa: public static FileSream Open( stirng path, FileMode mode ); • ArgumentException • ArgumentNullException • PathTooLongException • DirectoryNotFoundException • IOException • UnauthorizedAccessException • ArgumentOutOfRangeException • FileNotFoundException • NotSupportedException A kivételek mindegyike a System.Exception osztály utóda, így van Message tulajdonsága. Az osztálykönyvtár által dobott kivételek: - A help megadja a kivétel típusát - Mi írhatunk hozzá adott típusú catch blokkot - Ha dinamikus az átadott paraméter, nekünk kell a catch-ben felszabadítanunk! catch (CDaoException* e) { ... e->Delete(); } - C#-ban mi is dobhatunk az osztálykönyvtár által biztosított kivételt. throw new FileNotFoundException(fájlnév); Az egyik leggyakoribb alkalmazás: try { System.IO.File.Open("C:\\myFile.txt", System.IO.FileMode.Open); } catch(System.IO.FileNotFoundException fnf) { label.Text = "Nincs "+fnf.FileName+" nevű fájl!"; }
159
76. Operátor overloading (Az operátor átdefiniálás szabályai. Egy választott operátor átdefiniálása választott nyelven, különböző típusú paraméterekkel. Konverziós operátorok.)
Operátor overloading (Operátorok átdefiniálása) - Csak abban az esetben használjuk, ha a művelet végeredménye nyilvánvaló, elvárt. - Szimmetrikusan készítsük el. Tehát ha pl. átdefiniáljuk az == operátort, akkor a != operátort is definiáljuk át! - A legtöbb nyelv nem támogatja az operátor átdefiniálást, ezért ha élni akarunk a .NET kínálta nyelvfüggetlenséggel, akkor készítsük el a megfelelő függvény alakot is. public struct DateTime { public static TimeSpan operator - (DateTime t1, DateTime t2) { } public static TimeSpan Subtract(DateTime t1, DateTime t2) { } } - Felülírhatók a létező operátorok, mindegyik ugyan annyi operandussal. Kivétel: . az osztály taghivatkozás :: hatókör ? : háromoperandusú operátor - Szintaxis: vissz_ert operator jele (paraméterek) {…} Tulajdonságok: - A precedencia nem változik - Az operandusok száma nem változik - Az operátor függvénynek nem adhatók default paraméterek - Ha egy osztály tagoperátora akkor, első operandusa a this (egyel kevesebbet definiálunk) - Öröklődnek az = operátor kivételével
Értékadás operátor - Az értékadás ( = ) operátort a nyelv generálja egyszerű másolásként (Ha nem okoz hibát nem kell megírni) - Átdefiniálásakor figyeljünk, hogy visszaadott értéke *this legyen az a = b = c értékadás engedélyezése miatt. CA& CA::operator = (const CA& a) {... return *this;}
160
Értékadás mutató adattag esetén: CA& CA::operator = (const CA& a) { m_x = a.m_x; m_y = a.m_y; delete m_pi; m_pi = new int; *m_pi = *a.m_pi; return *this; } Konverzió megvalósítása: - Ha az osztályom típusára akarok konvertálni, elegendő egy adott argumentumú konstruktort írni. - Ha CA-ból akarunk pl. int -be konvertálni: Konverziós operátor! Konverziós operátor: - Szintaxis:operator int ( ) Tagfüggvénynek kell lennie. Nincs visszatérési típus. Nincs argumentum. - CA :: operator int () { return m_x; } - CA a; int i = ( int ) a; A << operátor: Visszatérési értéke és első argumentuma is osream&, hogy egymás mögé fűzhetők legyenek! Tehát nem szabad tagfüggvényként definiálni! friend ostream& operator << (ostream& os, const CA& a); ostream& operator << (ostream& os, const CA& a) { os << a.m_x << a.m_y; return os; } CA c; cout << c; Fájlba írás: #include #include ofstream ki("a.txt"); ki << c; ki.close();
161
77. Template fogalma (Függvény overloading vagy template függvény. Függvény paraméter és típus paraméter közti különbség. Template osztályok. A template bemutatása egy konkrét osztályon keresztül.)
Template osztályok: Template fogalma: - Ha olyan osztályokat, függvényeket akarunk létrehozni, melyek több adattípuson is dolgozhatnak, használjuk a sablonokat. - Szokás típusparaméterezésnek is nevezni - Pl. Konténereknél nem kell minden típushoz külön listát, tömböt... definiálni. - Ős típusú elemeken dolgozó konténer esetén típuskényszerítés szükséges, template esetén nem. - Nem kell a függvény overloading-ot használni. Függvény overloading megoldás:
Template-tel függvény: - template T min( T a, T b ) {return ( a < b ) ? a : b;} : Tetszőleges típus, nem csak osztály. - Ha int típusú argumentummal hívjuk, int-et ad vissza, ha char típusúval akkor azok minimumát is visszaadja. Hívás: int x=2; min(x, -5); Példányosítás: A fordító automatikusan elkészíti a függvény olyan változatát, amiben T helyett int van, s a kód ezt hívja int min (int a, int b) {return ( a < b ) ? a : b; } Hasonlóan a többi típusra, ha hívás történik. Nincs hívás ⇒ Nincs kód ⇒ Nincs hibaüzenet Típusparaméter != függvényparaméter: min(x, -5); - Hagyományos függvényhíváskor függvényparamétert adunk át: Futás időben érték átadást jelent. - Függvénysablon típusparamétere fordítás közben eldől, az érték átadás pedig futásidőben történik meg.
162
Template osztályok:
Verem osztály:
Betesz művelet:
Kivesz művelet:
163
