Informatika | Számítógép-architektúrák » GDF Számítógép-architektúrák, B tételek

-1- B 1. Az algoritmus és a program fogalma, jellemzői Az algoritmustervezés helye és szerepe a szoftverfejlesztésben Algoritmusok építő elemei. Algoritmuslépések és programutasítások kapcsolata Programvezérlési szerkezetek egy választott programozási nyelvben. 2 2. Szoftverfejlesztési módszer és módszertan A vízesés módszer összehasonlítása az inkrementális és iterációs módszerekkel. A RUP objektumelvő fejlesztési módszertan lényeges jellemzői (életciklus szemlélet, felépítés) Nézetek és modellek, kapcsolatuk. 3 3. A típus és a változó fogalma Egyszerő és összetett adattípusok Az adatok láthatósága az objektumokban Közvetlen és közvetett hivatkozású (referencia/dinamikus) változók. Az SQL adattípusai 5 4. Az adatmodell alapelemei Adatmodell típusok és jellemzőik A relációs adatmodell fogalma, kulcsok kategóriái, kapcsolatok felállítása. Az adatmodellek és a szakterületi modellek kapcsolata, összefüggése

9 5. Rutin, metódus, eljárás és függvény fogalma, jellemzőik Paraméterátadás Példány és osztálymetódusok Eseménykezelő metódusok. Függvények az SQL-ben 10 6. A kifejezés fogalma Kifejezések kiértékelése, a műveletek precedenciája Egy választott programozási nyelv aritmetikai, logikai és relációs műveletei. Kifejezések az SQL-ben 12 7. Osztály és objektum fogalma Egységbezárás Osztály definiálása egy választott fejlesztő környezetben Jellemzők (properties). Az osztálymodell kapcsolata az adatbázismodellel 13 8. Objektumok és osztályok közötti kapcsolatok. A kapcsolatok implementálása Öröklődés, polimorfizmus, virtualitás 17 9. A felhasználói felület, az alkalmazáslogika és az adatbázislogika szerepe, az ezeket realizáló objektumok sztereotípusai. Az egyes alkalmazás-rétegek jellemző komponensei egy választott fejlesztő eszköz esetében 18 10. Felhasználói felület (ablakok, menük, stb.) tervezése –

alapelvek, szabályok, szabványok Eseményvezérelt program, kapcsolat az operációs rendszerrel. Az eseményvezérelt programozás megvalósítása egy választott fejlesztő eszköznél. 20 11. Egy vizuális fejlesztő eszköz bemutatása: a fejlesztőkörnyezet elemei, szolgáltatásai, osztálymodell, komponensek, adatbáziskezelési lehetőségek, adatbázisok adatainak megjelenítése. Az eszköz dokumentáltságának ismertetése 25 12. Relációs adatbázisok. Funkcionális függőség fogalma, speciális függőségek szerepe Normálformák, a normalizálás célja. A normalizálás lépéseinek szemléltetése példán Az adatbázisterv dokumentációja 28 13. SQL adatbázis, adattábla, index, nézet létrehozása és törlése. Adattábla szerkezetének módosítása Kulcsok, külső kulcsok megadása, kapcsolatok beállítása. További megszorítások elhelyezése 31 14. SQL adattábla sorainak felvitele, módosítása, törlése. Lekérdezés adatbázisból, a

lekérdező parancs összeállítása, végrehajtása. Belső lekérdezés lehetősége, a nyelv kifejezései Jogok kiosztása és visszavételezése 33 15. Modellező nyelvek és eszközök szerepe az alkalmazások tervezésében és dokumentálásában. UML diagramok: használati eset diagram, objektumdiagram, kommunikációs diagram, állapot diagram, osztálydiagram és osztályleírás, komponens diagram. 35 16. A kliensoldali programozás alapelemei az Internetes alkalmazások fejlesztésénél. A kapcsolódó technológiák rövid bemutatása: HTML, XHTML, XML, CSS, XSL. A kliensoldali script nyelvek használata 38 17. A szerveroldali programozás alapelemei az Internetes alkalmazások fejlesztésénél. A szerveroldali objektumok bemutatása. Adatbázis-kezelés webűrlapokkal Egy szerveroldali programnyelv rövid bemutatása, jellemzése 41 18. Az informatikai biztonság fogalma. A biztonsági rendszer tervezése, a tervezés szakaszai Az egyes tervezési szakaszok fő

feladatai. A kockázatelemzés célja és lépései Az informatikai rendszerek elleni támadások típusai 43 19. A megbízható informatikai rendszer alapfunkciói, biztonsági követelményeit szabályozó hazai és nemzetközi szabványok, ajánlások, dokumentumok. Az informatikai rendszer elleni támadások kivédésének eszközei Kriptográfiai módszerek és eszközök, azok gyakorlati alkalmazásai. 45 20. Az információs rendszer fogalma és összetevıi. Adat, információ, tevékenység, esemény, felhasználó, szabvány Az információs rendszer szintjei és nézetei. Rendszerszervezési életciklus Tervezés, szervezés, modell Szervezetek strukturálási módjai. Átvilágítás, diagnosztizálás 49 21. Egy választott, mai rendszerfejlesztési (szoftverfejlesztési) módszertan felépítése és szerepe a szoftvertechnológiában. Adat- és folyamatmodellezés 52 -2- 1. Az algoritmus és a program fogalma, jellemzői Az algoritmustervezés helye és szerepe

a szoftverfejlesztésben. Algoritmusok építő elemei Algoritmuslépések és programutasítások kapcsolata. Programvezérlési szerkezetek egy választott programozási nyelvben Az algoritmus és a program fogalma, jellemzői. Az algoritmus az adatokat mozgató, manipuláló lépések, instrukciók sorozata, mely egy feladat megoldásához vezet. Egy számítógép által értelmezhető algoritmust programnak nevezünk. Az algoritmus tulajdonságai: • Az algoritmus véges számú lépésekből áll, • Minden lépésnek egyértelműen végrehajthatónak kell lennie, • A végrehajtható instrukciónak valamilyen célja van, • Vannak bemenő (input) adatai, melyeket felhasznál, és legalább egy kimenı (output) adata kell, hogy legyen. A strukturált algoritmus, olyan algoritmus, mely csak szekvenciákból, szelekciókból és iterációkból építkezik. Algoritmusok építő elemei • • • • • Kezdőpont, végpont: csak egyetlen kezdőpontja lehet, de lehet több

végpontja (kilépési pont) is. Tevékenység: az adatokon dolgozó utasítások (tépglalap) Haladási irány: a nyíl mindig a haladási irányt mutatja. Feltétel: ha a nyíl mellett egy feltétel található, csak akkor kerül végrehajtásra, ha a feltétel igaz. Csomópont: Egy elágazási pontból a program több irányba mehet, egy gyüjtőpontba a program több irányból érkezhet. (rombusz) Rutin (eljárás, függvény) A rutin egy külön névvel ellátott tevékenység. A rutin meghívható a nevére történı hivatkozással • Eljárás: egy visszatérési értékkel nem rendelkezı rutin. • Függvény. Olyan rutin, amely visszatérési értékkel rendelkezik Vezérlési struktúrák • • • Szekvencia: egymás utáni tevékenységek sorozata. Szelekció: programelágazást jelent, egy adott ponton a tevékenységek végrehajtása feltételektől függ. o Egy ágú o Több ágú: else if, switch. (A switch –et csak akkor alkalmazzuk, ha egy kifejezés jól

meghatározott, különálló értékeire szeretnénk bizonyos utasításokat megadni.) A switch utasítás az utasítás fejből és egy blokkból áll. A fej tartalmazza a switch kulcsszót, és zárójelben egy kifejezést A blokk akárhány esetet tartalmazhat. Az eseteket a case kulcsszó vezeti be, utolsó esetként megadható egy default eset. Szabályok: • Kifejezés: tetszőleges, visszatérési értéke csak byte, short, int, vagy char lehet! • Érték: egyetlen érték, mely csak konstans lehet. • Case érték: akárhány utasítás megadható. Az eset lehet üres is Az esetek egymás után kerülnek feldolgozásra, hacsak a break felül nem bírálja őket. • Break: hatására a switch blokk végére kerül a vezérlés. Ha nem teszünk a case végére break utasítást, akkor a vezérlés a következő case –re kerül. • Default: ha egyik eset sem igaz, akkor a default eset hajtódik végre, ezt nem kötelező megadni! Iterációk: o Elöl tesztelős: while o

Hátul tesztelős: do while o Léptető (növekményes) ciklus: for • Inicializálás: megadható egy vagy több utasítás, vesszővel elválasztva. Az itt megadott utasítások, az utasítás elején, egyszer kerülnek végrehajtásra. Itt lehet pl ciklusváltozót deklarálni Csak ugyanolyan típusú ciklusváltozók adhatók meg. • Feltétel: ez a feltétel minden ciklus elején kiértékelődik, és általában a ciklusváltozót vizsgálja. Ha a feltétel teljesül, a ciklus újra végrehajtódik, egyébként a vezérlés a for utáni utasításra kerül. • Léptetés: megadható egy vagy több utasítás, vesszővel elválasztva. Valamennyi léptető utasítás a ciklusmag végén minden alkalommal automatikusan végrehajtódik. Általában a ciklusváltozót szokás megváltoztatni, elősegítve ezzel a valamikori kilépést a ciklusból. Kiugrás a ciklusból • Break: azonnali kiugrást a ciklusból. Hatására a vezérlés a blokk utáni utasításra kerül •

Continue: hatására a vezérlés az utasításblokk (ciklus) végére kerül. A ciklus tehát tovább folytatódik, csak az aktuális ciklusmag ettől kezdve nem kerül végrehajtásra. Érvényes a while, a do, és a for utasítások blokkjaiban • Adatok végjelig való feldolgozása: o a ciklus előtt és a ciklusmag végén kérünk be adatot, úgy hogy a beolvasást közvetlenül követi a while ciklus feltételének a vizsgálata. Így a ciklusmagban csak érvényes adatot dolgozunk fel o egy végtelen ciklusba olvassuk be és dolgozzuk fel az adatokat. Az adat bekérése után itt is vizsgálat következik, és ha a bekért adat végjel, akkor elhagyjuk a ciklust. -3- 2. Szoftverfejlesztési módszer és módszertan A vízesés módszer összehasonlítása az inkrementális és iterációs módszerekkel. A RUP objektumelvő fejlesztési módszertan lényeges jellemzői (életciklus szemlélet, felépítés). Nézetek és modellek, kapcsolatuk Mi a módszertan és miért

van rá szükség? A hőskorban közvetlenül gépi kódban írták a programokat, aztán megjelent az assembly, majd az úgynevezett magas szintű nyelvek, ma meg 4GL eszközök, hihetetlenül összetett API-k segítik a programozó munkáját. Másrészt, a csupasz programozásról nagyon hamar kiderül, hogy nem elég. Meg kell tervezni a programot Azonban sokszor nem elegendő, ha csak a programot tervezzük meg, fel kell mérni az igények, ki kell deríteni a követelményeket, a fejlesztés sok résztvevőjét koordinálni kell. Ezzel jutottunk el a szoftver fejlesztési módszertanhoz A fejlesztés célja a megrendelői, felhasználói igényeknek megfelelő szoftver rendszer előállítása megadott határidőőre, megadott költség kereteken belül, s mindez jó minőségben. A programozástól a rendszerfejlesztésig • • • • Programozás Programtervezés: o Strukturált: Jackson módszer o OO: UML Szoftver fejlesztés módszertan: o Egységesített Eljárás).

Rendszertervezés: o Strukturált: SSADM Vízesés modell A szoftver fejlesztés első modellje (1970), ami viszonylag stabil körülmények között mind a mai napig jól működik. A fejlesztési folyamatot fázisokra bontja, a fázisok szigorúan egymás után következnek, minden egyes fázisra jellemzőek azok a dokumentumokat, amiket el kell fogadni a továbblépéshez. A gyakorlati alkalmazásban a fázisok többé-kevésbé átfedhetik egymást. Az egyes fázisok végrehajtása iteratív tevékenység A dokumentumok előállításának, jóváhagyásának a költségei miatt elfogadott gyakorlat, hogy egy-egy fázist már néhány iteráció után befagyasztanak, a problémák megoldását lehagyják, kikerülik avagy későbbre halasztják. Lépései 1. Követelmények megfogalmazása 2. Elemzés 3. Tervezés o System design: Hardver és szoftver környezet o Softver design: Architektúra kialakítása. A fő blokkok tovább bontása modulokra 4. Implementáció és

egységtesztelés 5. Integráció és rendszerteszt: modulok egyesítése, tesztelése 6. Működtetés és karbantartás Ez a fejlesztési modell akkor alkalmazható hatékonyan, ha a követelmények jól definiáltak és stabilak. Ebben, ez esetben viszont hatékony munkafolyamatot biztosít. Előnyei • Nemcsak a szoftverfejlesztésnél használható, hanem egyéb végfelhasználói projekteknél is. • Könnyű megérteni. • Egyfázisú fejlesztéseknél egyszerű a használata. • Biztosítja a követelmények rögzítését, és azok nem is változnak a fejlesztés során. • Feszes ellenőrzést biztosít. • Ha jól alkalmazzuk, a hibák már valamely korai fázisban kiderülnek, amikor javításuk még lehetséges, és kevésbé költségigényes. • Ha valaki készen van az adott fázisban rá kiosztott munkával, másik projekten dolgozhat. • Könnyű ellenőrizni a projekt aktuális állapotát. Hátrányai • Lineáris, így nehéz a visszalépés a felmerül

problémák megoldásáraNem kezeli a szoftverfejlesztésben elterjedt iterációkat. • Nincs összhangban a szoftverfejlesztés problémamegoldó természetével. • A megrendelő csak a folyamat végén láthatja a rendszert, menet közben nincs lehetősége véleményezni azt. • A minőség szintén csak a folyamat utolsó fázisában mérhető. • Minden egyes fázis az előző fázis teljes befejezésére épít, ezzel jelentősen megnő a kockázat. • A fejlesztés során a követelmények nem módosíthatók, hiszen már az életciklus elején befagyasztjuk őket. • Már a fejlesztés kezdetén ismernünk kell valamennyi követelményt, azok későbbi módosítására vagy bővítésére nincs lehetőség. • Dokumentum-vezérelt, és túlzott dokumentálási követelményeket állít fel. • Az egész szoftvertermék egy időben készül, nincs lehetőség kisebb részekre osztására. -4- Evolúciós fejlesztés Az evolúciós fejlesztés alapötlete, hogy a

kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyőlt tapasztalatokat építsük be egy újabb termék verzióba. Két, lényegében eltérő típusa ismert: • Feltáró fejlesztés: A fejlesztés célja, hogy a megrendelővel szorosan együttmőködve feltárjuk a valós igényeket és kifejlesszük a végleges rendszert. A rendszer fejlesztését a már ismert részekkel kell kezdeni, s újabb és újabb elemek hozzáadásával jutunk el a végtermékig. • Eldobható prototípus készítése: A prototípus próbálgatásos módszerrel közelíti meg a követelményeket, első sorban az ismeretlen követelmények feltárására koncentrál. Az eldobható prototípus készülhet más technológiával, s belső strukturálására sem kell akkor a figyelmet fordítani. Az eldobható prototípust végtermékké minősíteni, avagy az eldobható prototípus kódját közvetlenül

felhasználni a végtermékben súlyos szakmai hiba. A prototípuskészítés akkor hatékony, ha a követelmények nem ismertek a fejlesztési folyamat elején. Hátránya: • A fejlesztési folyamat előrehaladása nem látható, nem mérhető. Gyakori projektmenedzselési gondokhoz vezet • Rosszul strukturált, nehezen továbbfejleszthető terméket eredményez. Inkrementális fejelsztés Hibrid megközelítési mód, a vízesés illetve az evolúciós modell előnyeit ötvözi. A fejlesztés indításakor a megrendelő vázlatosan közli a követelményeit, illetve meghatározzák mely követelmények a fontosabbak, s melyek kevésbé fontosak. Az első inkremens kifejlesztésével párhuzamosan folyat a további inkremensek specifikálása, tervezése Amikor egy inkremens elkészül, azt integrálni kell a már elkészült rendszerbe. Az inkrementális fejlesztés előnye: • A megrendelőnek nem kell megvárnia a teljes rendszer elkészültét • A korábban kifejlesztett

inkremensek tekinthetők prototípusnak • Csökkenti a kockázatot. Az egyes inkremensekben ugyan lehetnek hibák, azonban valószínű, hogy ezek az egész projekt kudarcát okozzák. • A magas prioritású inkremenseket szállítjuk le először, így azok lesznek a legjobban kitesztelve. Spirális fejelsztés Az iteratív megközelítés során a fejlesztés mintegy spirál vonalban halad előre, a felhasználó, avagy a megrendelő rendszeresen megkapja az újabb és újabb futtatható program verziókat. Újrafelhasználás-orientált fejlesztés A fejlesztési folyamatot a meglévő komponensek újrafelhasználása határozza meg. Jelentős mérető komponens könyvtárak létét tételezi fel. Ebben a megközelítésben a komponens nem csak a 4GL eszközök szokásos, finom szemcsézettségő komponensei (nyomógombok, címkék, stb.), hanem nagyméretű, üzleti komponensek (főkönyv, e-mail kezelő alrendszer, stb.) is lehetnek • • • • Komponenselemzés: A

hozzáférhető komponensek a legritkább esetben valósítják meg a rendszertől elvárt szolgáltatásokat. Követelménymódosítás: A rendelkezésre álló komponens szolgáltatások és a követelmények összehangolása. Ez történhet a követelmények megváltoztatásával, illetve történhet újabb komponensek beszerzésével, esetleg kifejlesztésével is. Rendszertervezés újrafelhasználással: A készítendő rendszer vázát kell meghatározni, avagy egy már meglévő struktúrát kell felhasználni. Hangsúlyos tevékenység a komponensek együttműködésének a biztosítása Rendszerintegráció: A megvásárolt, illetve a kifejlesztett komponensek összeépítése. E módszer csökkenti a fejlesztési időt és a kockázatokat. Ugyanakkor a leszállított rendszer törvényszerűen tartalmaz kompromisszumokat. Formális rendszerfejlesztés A fejlesztés kiinduló pontja egy matematikailag egzakt rendszerdefiníció. Ezt a formális definíciót matematikailag

meghatározott, ellenőrzött transzformációkkal alakítják át működő rendszerré. Hihetetlenül drága. Ez a fejlesztési modell biztonság, avagy védelem kritikus rendszerek fejlesztése során használatos, egyéb fejlesztésekben alig használják. (Űrhajózás, katonaság) Az Egységesített Eljárás szoftverfejlesztési módszertan A hasonlat szerint a háromlábú szék egy-egy lába a módszertan egy-egy jellegzetessége: • Használati eset vezérelt – milyen célra? • Architektúra központú – mi a lényege? • Iteratív és inkrementális – hogyan? További jellegzetességek: • Több mint programozás módszertan – foglalkozik szakterületi, üzleti modellezéssel, elemzéssel. • Életciklus szerint teljes – az első ötlet felmerülésétől a termék teljes haláláig végigkíséri a teljes életciklust, beleértve az újabb és újabb verziók kifejlesztését is. • Objektum-orientált módszertan. -5- Az Egységesített Eljárás két

dimenziója • • Fázisok: A fejlesztési ciklus négy fázisból áll (előkészítés, kidolgozás, építés, átmenet) Iterációk: A fázisok iterációkra bonthatók. Minden egyes iteráció egy - egy mini fejlesztés Az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. A fejlesztés különböző fázisaiban az iterációk lényegesen különbözőek lehetnek. Míg a fejlesztés kezdeti szakaszában az üzleti modellezés és a követelményelemzés a leghangsúlyosabb, s a tesztelés, telepítés lehet, hogy ki is marad, addig a középső szakaszban az implementálás, a legvégső szakaszban a telepítés, a tesztelés a domináns. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. Fázisok – vízszintes tengely • • • • Előkészítés: Feladata a rendszerhatárok meghúzása, az architektúra körvonalazása. Itt azonosítjuk a

kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. Az előkészítő fázisban válik a kezdeti ötlet tervezhetı elképzeléssé. Kidolgozás: Itt történik meg a használati esetek koncepcionális szintű kidolgozása, ekkor válik a fejlesztés folyamata ütemezhetővé, költségei tervezhetővé. A fázis végére elkészül a rendszer majdnem teljes szélességű, bár sekély áttekintése Építési: Feladata a rendszer iteratív és inkrementális növelése. A fő hangsúly ebben a fázisban részletes tervezésen és a kódoláson van. A fázis végén elkészül a rendszer első átadható verziója Átmenet: A rendszer átadása a végfelhasználóknak. Rendszerint több béta változat készül, s a béta változatok tapasztalati alapján módosul a rendszer. Az átadási fázis célja a szükséges hibajavítások, módosítások után a rendszer átadása, bevezetése. Megtörténik a mind a fejlesztői, mind a felhasználói

dokumentáció véglegesítése, elkészülnek a rendszerhez kapcsolódó egyéb termékek (oktató anyagok, telepítő programok, installálási útmutatók, adatátemelést végző alkalmazások, stb.) Mérnöki munkafolyamatok függőleges tengely • • • • • • • Üzleti modellezés: A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg a. Más néven szakterületi (domain) modellezés. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére Követelmények összegyűjtése: A rendszernek kívülről, a felhasználó szempontjából való leírását adja meg. Feladata a funkcionális és a nem funkcionális követelmények összegyűjtése. A funkcionális követelményeket jellemzően használati esetekként gyűjtjük össze. Elemzés: A rendszer képét a belülről, a fejlesztő szempontjából írja le. Az architektúrára koncentrál, koncepcionális szintű osztályokat és

együttmőködéseket határoz meg. Tervezés: Feladata az implementálható pontosságú tervek elkészítése. Implementáció: A rendszer tényleges elkészítés, a kódolás. Teszt: Feladat a rendszer helyességének az ellenőrzése. Telepítés: Telepítéssel, üzemeltetéssel kapcsolatos tevékenységek Támogató munkafolyamatok • Projectvezetés • Változáskövetés • Környezet biztosítása Az Egységesített Eljárás termékei Nézetek - Modellek • Tervezési nézet (Design view) – Használati eset modell • Implementációs nézet, avagy Komponens nézet – Implementációs modell, komponens diagramm • Dinamikus, avagy folyamat nézet • Telepítési nézet • Követelmény nézet 3. A típus és a változó fogalma Egyszerő és összetett adattípusok Az adatok láthatósága az objektumokban. Közvetlen és közvetett hivatkozású (referencia/dinamikus) változók Az SQL adattípusai. Változó, típus Egy programban a változók, olyan

memóriaterületek, amelyek különböző értékeket vehetnek fel. Egy változónak az algoritmus végrehajtása során változhat az értéke. Minden változónak nevet kell adnunk (azonosítót) hogy később egyértelműen hivatkozhassunk rá. Vannak összetett és elemi változók Minden változónak van egy jól meghatározott típusa. A változó csak a típusának megfelelő értékeket vehet föl Az UML és Java szabvány szerint az egyszerű adatokat kisbetűvel, míg az összetetteket nagybetűvel jelöljük. Egy változót az algoritmus csak típusának megfelelően kezelhet. Változók deklarálása: Javában a program által használt összes változót deklarálni kell, vagyis meg kell adni a nevét és a típusát. Pl: int letszam A változó inicializálása: Amikor a változónak kezdeti, induló értéket adunk, akkor a változót inicializáljuk! Egy változónak már rögtön a deklaráláskor kezdőértéket adhatunk. Pl: double fejadag=04 -6- Konstans Ez egy

megváltoztathatatlan változó. A konstansokat NAGYBETŰKKEL írjuk Pl: final int EVSZAM=1999; A Java típusok osztályozása A Javaban kétféle típus létezik: Primitív típusok: Egész típusok Neve F. mem byte 1 bájt short 2 bájt int 4 bájt long 8 bájt Neve float double Valós típusok F. mem Pontosság 4 bájt 6-7 jegy 8 bájt 14-15 jegy Karakter Neve F. mem char 2 bájt Logikai Neve F. mem boolean 1 bájt Referencia típusú változó: Az objektum egy összetett memóriaterület, az több primitív típusú változót és további referenciákat tartalmazhat. • Tömb • Interfész • Osztály Klasszikus adatszerezetek Asszociatív Olyan halmazok, vagy multihalmazok, melyeknek az elemeiből részhalmazokat tudunk kiválasztani. • Tömb o Általános tömb: Elemei indexeléssel közvetlenül elérhetők. Hátrányai: méretét előre meg kell adni, indexhatárok dimenziónként kötöttek.Lehet egy dimenziós tömb (vektor) vagy több dimenziós tömb A tömb

méretétől függetlenül minden elem azonos idő alatt érhető el. o Ritka mátrix: Tárolás: láncolt listában. Olyan többdimenziós tömb, ahol a tömb nagy része kihasználatlan • Tábla Egy elem: egyedi kulcs + adat Tárolás: egydimenziós tömbben vagy láncolt listában történik. o Soros: A kezelés szempontjából ez a legegyszerűbb táblázat. Akkor érdemes soros táblázatot használni, ha az egyes elemek feldolgozási valószínűsége közel azonos. A táblázatot az elemek érkezési sorrendjében töltjük föl Bővítése mindig a táblázat végén történik. Törölni tetszőleges elemet törölhetünk belőle o Önátrendezős: Az egyes elemek feldolgozási valószínűsége különböző. Ha egy elemet feldolgozásakor kicseréljük az első elemmel, akkor ez a folyamat sok lépés után oda vezet, hogy a legelső helyen a leggyakrabban feldolgozott elem fog állni. o Rendezett: Ez általában kulcs alapján történő növekvő rendezettséget jelent.

A feldolgozást segíti a rendezés Az elemeket nem azonos gyakorisággal dolgozzuk föl. • Hasító tábla: Egy hash függvény segítségével állapítja meg, hogy melyik kulcshoz milyen érték tartozik, így implementál egy asszociatív tömböt. A hash függvény segítségével a kulcsot leképezzük az adatokat tároló tömb egy adott indexére, ahol a keresett érték fellelhető. Egyértelmű a leképezés a kulcsok és fizikai címek között Láncolt listával történik a megvalósítása Ideális esetben minden értelmezett kulcsra egyedi hash-t állít elő a hashelő függvény, de ez a gyakorlatban ritkán megvalósítható, így számolnunk kell azzal, hogy két különböző kulcsra ugyanazt a hash-t kapjuk, és kezelnünk kell az ilyenkor fellépő hash ütközést. (Adatbázisok indexelése) Szekvenciális A szekvenciális adatszerkezet elemei mindig két másik elemmel vannak közvetlen kapcsolatban. • Verem: LIFO, PUSH, POP • Sor: FIFO, PUT, GET •

Sztring: A sztring olyan lista, melynek elemeit az abécé szimbólumai, karakterek alkotják. Hierarchikus A fa az adatok hierarchikus kapcsolatának ábrázolására alkalmas adatszerkezet. (pl háttértárolók könyvtárszerkezete) Rendelkezik egy kitüntetett kezdőponttal, és e kezdőpontból kiindulva minden adatelemhez tetszőleges számú új elem kapcsolódhat. A kapcsolódó elemek a fa más részeihez nem kapcsolódhatnak. Fa bejárása: Erre a gyakorlatban három, a rekurzív definíciókra támaszkodó módszer terjedt el. • • • preorder bejárás: gyökér, bal, jobb: +*abc inorder bejárás: bal, gyökér, jobb: a*b+c postorder bejárás: bal, jobb, gyökér: ab*c+ -7- Típusai: • Bináris fa: Gyökeréből legfeljebb 2 részfa ágazik. • Rendezett bináris fa: (Keresési fa) A baloldali részfa összes eleme kisebb, mint a szülő A jobboldali részfa összes eleme nagyobb, mint a szülő Egy elemet maximum n+1 lépésben megtalálunk. •

Kiegyensúlyozott bináris fa: Minden elem esetén a bal és jobb oldali fák magasságának különbsége max 1. • Tökéletesen kiegyensúlyozott bináris fa: A fa bármely elemének a jobb és baloldali részfájában az elemek számának eltérése maximum 1. • Minimális magasságú fa: Ha az aktuális számú elem nem lenne elhelyezhető egy kisebb magasságú fán. Hálós A hálós adatszerkezetek adatelemei között a kapcsolat sok-sok jellegű, azaz bármelyik adatelemre több helyről is eljuthatunk, és bármelyik adatelemtől több irányban is továbbmehetünk. Reprezentációja ún szomszédossági listával vagy szomszédossági mátrixszal történhet. • Irányított gráf: A gráfnak csúcsi és élei vannak. • Hálózat: A háló nem körmentes, vagyis létezhetnek benne körök. A körút olyan út, amelynek utolsó eleme egyben az első is Absztrakt tárolók • Láncolt lista: Elemei mutatókon keresztül össze vannak kapcsolva. A listát az első

listaelem mutatója meghatározza Egy listaelem: adat + mutató. Elemei fizikailag bárhol elhelyezkedhetnek Előnye: beszúrás, törlés egyszerű Változatai: o Nyíltvégű lista o Cirkuláris (zárt) lista o Rendezett lista o Kétirányú (szimmetrikus) lista o Fejelt lista o Multilista (többszörös lista) Adatok láthatósága az objektumokban Példányváltozó, példánymetódus Az objektum (példány) mindig a saját adatain dolgozik, a metódusokat pedig az osztály leírásából nézi ki. Láthatóság: • Nyilvános (public, +): minden kapcsolatban álló kliens eléri és használhatja; • Védett (protected, #): hozzáférés csak öröklésen keresztül lehetséges; • Privát (private, -): csak az osztály saját metódusai férhetnek hozzá. Osztályváltozó, osztálymetódus Vannak adatok, amelyek nem egy konkrét példányra, hanem az egész osztályra jellemzıek. Az osztályváltozó értéke az osztály összes példányára (objektumára) ugyanaz,

teljesen felesleges lenne ezt az értéket példányonként eltárolni. Osztálymetódusnak nevezzük az olyan metódust, amely objektumok nélkül is tud dolgozni. Az osztálymetódus a példányadatokat nem éri el, csak az osztályváltozókat manipulálja. Az osztályváltozó, ill. osztálymetódus nevét az UML –ben aláhúzzuk! Bezárás A bezárás az adatok és metódusok összezárását, beokozását jelenti. (egységbezárás elve!) Más szóval információkat rejtünk el a kliens elıl, amelyeket csak az interfészen keresztül lehet megközelíteni. Objektum létrehozása, deklarálása Egy osztály példányait a new (új) operátorral hozhatjuk létre. A new után meg kell adni a létrehozandó objektum osztályát, ezt a konstruktor aktuális paraméterlistája követi: new <OsztályAzonosító>(<aktuális paraméterlista>) A new operátor feladatai: • Létrehoz egy új OsztályAzonosító osztályú objektumot; lefoglalja számára a szükséges

memóriát • Meghívja az osztálynak azt a konstruktorát, amelynek szignatúrájára ráhúzható az aktuális paraméterlista • Visszaadja az újdonsült objektum referenciáját (azonosítóját). Az objektum osztálya az lesz, amit a new után megadtunk A konstruktor beállítja az objektum kezdeti állapotát. A konstruktor neve megegyezik az osztály nevével Egy osztálynak több konstruktora is lehetséges. Az objektum egész élete során a new után megadott osztályhoz fog tartozni, osztályát megváltoztatni nem lehet. Objektum deklarálása Minden referencia típusú változót (mint ahogyan a primitív típusúakat is) deklarálni kell a new szóval! Deklaráláskor csak a referencia részére következik be tárfoglalás: Az objektumot a referencia típusú változón keresztül szólíthatjuk meg: objektum.metódus () Értékadás az objektumok körében Objektumokat értékül adhatunk egymásnak – ilyenkor maga a hivatkozás másolódik át az egyik

változóból a másikba: értékadás után a két változó ugyanazt az objektumot azonosítja. Az obj2 értékül adható obj1nek (obj1=obj2), ha • • -8- obj1 és obj2 ugyanahhoz az osztályhoz tartoznak, vagy az obj1 osztálya őse az obj2 osztályának. Objektumok egyenlőségvizsgálata Objektumok állapotát nem lehet a hasonlító operátorokkal összehasonlítani. Az obj1= = obj2 logikai kifejezés a két objektum referenciáját hasonlítja össze, azaz a két objektum fizikailag azonos-e! Ha a két objektum azonos, akkor természetesen állapotuk is megegyezik, de két nem azonos objektumnak is lehet ugyanaz az állapota. Objektumok egyenlőségét az equals metódussal szokás megállapítani. A String osztály String osztály olyan szöveg (karakterlánc) tárolására szolgál, amelynek értékét egész élete során nem akarjuk megváltoztatni. A String objektum szövege unikód karakterek sorozata, a karakterek sorszámozottak 0-tól indulva. A String

osztály metódusai A String osztály főként olyan példánymetódusokat (csak függvényeket) deklarál, amelyek a tárolt karakterlánctól függően egy karakterláncot vagy információt adnak vissza, pl. szöveg hossza, kis-nagy betűs változat, összehasonlítás, részlánc E függvények mindegyike az objektum tartalmát változatlanul hagyva egy új string típusú objektumot állít össze, és ennek az új objektumnak a referenciáját adja vissza. StringBuffer osztály A String osztállyal ellentétben a StringBuffer osztály szövege manipulálható. Elvégezhetık például a következő műveletek: • karakter, szöveg, valamint primitív típusú adatok hozzáadása a szöveghez; • karakter, szöveg, valamint primitív típusú adatok beszúrása a szövegbe; A StringBuffer objektumnak van: • kapacitása (capacity), ez azt jelenti, hogy milyen hosszú szöveg tárolására van felkészülve. Az objektum kapacitását az egyes műveletek automatikusan állítják

be, de a programozónak is lehetısége van a kapacitás megváltoztatására hatékonysági célokból. • Aktuális hossza (lenght), vagyis az éppen tárolt szöveg hossza. A Sring és a StringBuffer osztályok nincsenek öröklési viszonyban egymással. Objektum átadása paraméterként Egy referencia típusú változó (objektum) akkor adható át paraméterként egy referencia típusú formális paraméternek, ha az aktuális paraméter értékadás szerint kompatíbilis a formális paraméterrel. A metódus megkapja az objektum referenciáját A metódus a mutatott objektumot megváltoztathatja, de nem változtathatja meg az eredeti mutatót. Primitív típusok csomagolása A primitív típusú változók nem objektumok. Annak érdekében, hogy a primitív típusú adatokat objektumokként kezelhessük, a javalang csomag ún. csomagoló osztályokat definiál: minden primitív típushoz tartozik egy osztály, mely a megfelelő típust becsomagolja Az SQL adattípusai

Táblafajták • • • • • Adattábla: a valódi relációk, melyek a karbantartott adatokat tartalmazzák (A-tábla). Eredménytábla: adat- vagy eredménytáblából lekérdezéssel nyert tábla, elmenthető (E-tábla). Nézettábla. Virtuális tábla, amelyről csak a definíciója tárolódik (V-tábla) Index: automatikus a használata, tehát csak a létrehozásáról kell gondoskodni (I-tábla). Szinonima: létezı adat- vagy nézettábla átnevezése (S-tábla). Adattípusok • • • • • • CHAR(n): karakterlánc, INTEGER: hosszú, egész szám, DECIMAL(m,n) vagy NUMERIC(m,n): fixpontos valós szám. FLOAT(n), vagy REAL: lebegıpontos valós szám. DATE: dátum LOGICAL: logikai érték. • • • • • • • • VARCHAR(n): karakterlánc TIME, DATETIME: időpont, dátum, SMALLINT: rövid, egész szám, SERIAL: sorszám, MONEY: pénz BIT(n): állandó hosszúságú bináris érték ROWID: sorazonosító SEQUENCE: számláló Kifejezések Oszlopneveket,

konstansokat, függvényeket, valamint műveleti jeleket és összehasonlításokat tartalmazhatnak az adattípusokon belül. A behívó nyelv egyéb létező függvényeit, konstansait és változóit egyaránt elfogadja, de saját ún. aggregáló függvényeket (COUNT, a számláló, SUM, az összegző, AVG, az átlagoló, MAX illetve MIN, a legnagyobb illetve legkisebb kiválasztó) is ismer. Utasítások Az SQL nyelv nem eljárásjellegő, ennek ellenére az újabb szabványok már tartalmaznak eljárásjellegő bővítéseket mint a tárolt eljárások és triggerek. Minden utasítást – mely esetenként roppant hosszú is lehet – pontosvessző zár le. Az SQL parancsok szekvenciaként jelennek meg, de önmagukba foglalva szelekciót illetve iterációt tartalmazhatnak a táblák sorainak vonatkozásában. Az utasítások záradékokra tagolódnak, melyek az utasítások tárgyát, a végrehajtás feltételei írják le (mindet kulcsszó vezeti be). -9- 4. Az adatmodell

alapelemei Adatmodell típusok és jellemzőik A relációs adatmodell fogalma, kulcsok kategóriái, kapcsolatok felállítása. Az adatmodellek és a szakterületi modellek kapcsolata, összefüggése. Az adatmodellek alapelemei Egyed Minden olyan dolog (objektum), ami minden más dologtól (objektumtól) megkülönböztethetı. Tulajdonság Az egyed belső szerkezete. Az egyedeket tulajdonságokkal (attribútumokkal) írjuk le A tulajdonság értékeivel egy adott egyed konkrét értékét határozzuk meg. (Kulcs) Kapcsolat A kapcsolat az egyedek közötti viszony. • Az egy-egy típusú kapcsolat (1:1): • Az egy-több típusú kapcsolat (1:N): • A több-több típusú kapcsolat (N:M): Három adatmodell létezik az alapelemek fizikai tárolásától függően: • • • Hálós modell: Gráffal ábrázolható az adatbázis. A gráf csúcsain az egyedelőfordulások, az éleken a köztük lévő kapcsolat helyezkedik el. A legkisebb címezhető egység a rekord, tehát a

tulajdonságok leírása csak a dokumentációban található meg Relációs modell: Ahol az egyed egy táblázat, óriási szerepet kapnak a tulajdonságok. Viszont fizikailag nem tárolódnak a kapcsolatok, csak a dokumentáció tartalmazza. Objektumos modell: A tiszta objektumos modellben a tulajdonság lehet felsorolt típusú, és egy ilyenben a vele kapcsolatban álló másik egyed rekordjainak fizikai címeit tartjuk. Ez a kapcsolat fizikai tárolása A relációs adatmodell fogalma, kulcsok kategóriái, kapcsolatok felállítása. Reláció A tulajdonsághalmazok Descartes-szorzatának részhalmaza. Tulajdonságok: • Minden egyes táblázathoz tartozik egy azonosító • A sorok és oszlopok metszetében található adatok egyértékűek (atomiak), adatcsoportokat, tömböket nem tartalmazhatnak. • Az oszlopokban található adatok azonos jellegűek, és egy előre definiált halmazból származnak • Minden egyes oszlopnak egyedi neve van • A táblázat minden

sorában ugyanannyi adat található • A táblázatban nem lehet két azonos sor • A sorok és az oszlopok sorrendje nem lényeges Kulcs Relációs adatmodell esetén is (amikor az egyed tábla), annak valamely tulajdonsága, vagy tulajdonságcsoportja képes lehet a tábla sorát beazonosítani. Az A attribútumhalmaz egy K részhalmaza kulcs, ha • • a K értékei az R reláció mindegyik sorát egyértelműen meghatározzák, de ha egyetlen attribútumot is elhagyunk K-ból, az előző már nem teljesül. A kulcsok csoportosítása: • • Egyszerő kulcs: egyetlen attribútumból áll Összetett kulcs: több attribútumból áll. Kapcsolat Fogadjuk el, hogy relációs modellben, hogy két reláció csak akkor áll kapcsolatban egymással, ha az egyik külső kulcsként tartalmazza a másik kulcsát. (Gyerek és szülő tábla) Az adatmodellek és a szakterületi modellek kapcsolata, összefüggése A szakterületi adatmodell megszerkesztése során feltárják a

szakterület azon jelenségeit, egyedeit (tárgyakat, személyeket, eseményeket stb.), amelyekre vonatkozóan a tervezett adatbázisban adatokat szeretnének nyilvántartani Meghatározzák, hogy a szakterületi igények szerint az egyedek leírására milyen tulajdonságokat kell nyilvántartani, továbbá kiderítik azokat a szabályokat, amelyekből a tulajdonságok közötti valamilyen függések, egyedek közötti kapcsolatok, a tulajdonságok értékeire vagy a kapcsolatokra vonatkozó valamilyen megszorítások következnek. A relációs táblaszerkezet kindulási pontja, de nem kell alkalmazkodnia a relációs világ korlátaihoz. Az adatbázisok tervezése is a fentiekben már említett szintekre tagoltan történik: • Időben a fogalmi szintű adatmodell (más névvel a szakterületi adat-modell) megszerkesztése az első feladat. Ez a modell kizárólag az alkalmazási területet jellemző összefüggéseket tükrözi. Hordozható • • - 10 - A következő

lépés a logikai tervezés, amely már a hatékonysági, biztonsági szempontokat és a szervezeti korlátokat is figyelembe veszi. Végül a fizikai tervezés a logikai tervet a megvalósító eszköz, a konkrét adatbáziskezelő korlátaihoz igazítja. 5. Rutin, metódus, eljárás és függvény fogalma, jellemzőik Paraméterátadás Példány és osztálymetódusok. Eseménykezelő metódusok Függvények az SQL-ben Rutin, metódus, eljárás és függvény • • • • • Rutin: Az objektumokon kívüli rutin mindig egy statikus fogalom: akárhányszor meghívjuk, mindig pontosan ugyanaz a kód fog lefutni. Eljárás: Nincsen visszatérési értéke (void = semleges). Függvény: van visszatérési értéke. Ekkor a visszatérési érték behelyettesítıdik a kifejezésbe Metódus: Egy adott osztályhoz tartozó, az osztályon vagy az adott típusú objektumpéldányon műveletet végző függvény vagy eljárás. Osztálymetódus: nem egy konkrét objektumpéldányon,

hanem magán az osztályon végez műveleteket. Az osztálymetódusok az osztály példányosítása nélkül is meghívhatók. o Virtuális metódus: Az ilyen metódusok meghívásakor a hívásban végrehajtásra kerülő implementációt az adott objektumpéldány típusa határozza meg, függetlenül a felhasznált referencia típusától. A dinamikusként/virtuálisként deklarált metódusok implementációja a leszármazott osztályokban módosítható vagy felülírható. A virtuális metódusok címeit minden objektum a hozzá kapcsolódó VMT-ben tárolja. Ilyen típusú metódusokkal lehet megoldani az öröklés folyamaton keresztül a sokoldalúságot. Ez azt jelenti, hogy nem csak a régi metódust cseréli ki az újra, hanem az egész objektumot átnézve a régi metódusra mutató összes hivatkozást átírja az új metódusra mutatóvá. Ezáltal megváltozik az egész objektum tulajdonsága, és az öröklés folyamatra nézve sokoldalúvá válik. o Dinamikus

metódus: A dinamikus metódusok a virtuális metódusokhoz hasonlóan működnek azzal a különbséggel, hogy csak az őket deklaráló vagy felülíró osztályokban, egy láncolt vagy asszociatív listában kerülnek tárolásra. o Statikus metódus: az ilyen metódusok az örökléskor, csupán kicserélik az előd metódusát az újra, nincs hatással az objektum más részeire - így nem változik meg teljesen annak tulajdonsága - . o Absztrakt metódus: Olyan metódus, ami mögé a deklaráló osztályban nem kapcsolunk semmilyen implementációt, hanem ezt meghagyjuk a leszármazott osztályok számára. Az absztrakt metódusok lényegükből adódóan mindig virtuálisak is. Paraméterátadás Paraméter átadáskor a paramétereket vagy regiszterekben adjuk át, vagy a veremben helyezzük el őket. A regiszter vagy verem állapotát el kell meneteni, majd visszaállítani. • Érték szerinti átadás: Az érték szerint átadott paraméterek csak bemenő paraméterek.

Azaz, ezeket átadhatjuk egy eljárásnak, de az eljárás nem módosítja az eredeti példányt, mivel az eljárásnak adataink egy másolatát adjuk át. • Referencia szerinti átadás: A memóriacímet adjuk át, ahol a változó található. Ezt a címet felhasználva módosítani tudjuk ez eredeti változó értékét. JAVA: Az átadás technikailag MINDIG ÉRTÉK szerint történik. Az objektumreferenciákat is értékként adjuk át, tehát átadás után lesz egy új referenciánk az eredeti objektumra. Ekkor két referenciánk van: az eredeti és amit értékként lemásolva átadtunk Ilyenkor az átadott referencia mögötti objektumot manipulálva az eredeti referencia mögötti objektum is módosul, hiszen mindkét referencia ugyanoda mutat. Metódusok túlterhelése Egy metódust a következő dolgok azonosítanak: • • • A metódus neve A paraméterek száma és sorban a paraméterek típusai. A Javában, írhatunk több, azonos nevű metódust is. Ekkor viszont

az azonos nevű metódusok paraméterezésének eltérőnek kell lennie! Eseménykezelő metódusok (eseménykezelés Javában) Eljárásorientált programok A hagyományos eljárásorientált programok rendszerint egyetlen meghatározott végrehajtási sorrendnek megfelelően hajtódnak végre. Ez azonban nem hatékony a GUI (Graphics User Interface) használatakor. A felhasználó itt csaknem bármikor kiválaszthat menüelemeket, begépelhet szöveget, kattinthat az egérrel, stb. Azaz ezeknek az elemeknek bármikor "nyitottnak" kell lenniük a felhasználó felé. Az események várakozási sora A GUI esetén így sokkal megfelelőbb az eseményorientált megközelítés. Minden felhasználói esemény fellépésekor egy eseménysorba kerül. Rendszerint ez az operációs rendszer színtjén történik meg A program az eseménysorból veszi ki az eseményeket, s dolgozza fel azokat. Általában egy végtelen ciklust megvalósító while hurok olvas az eseménysorból, s

egy nagy switch utasítás szétosztja. - 11 - Események A rendszer architektúrájától függően vagy az egész rendszer számára csak egyetlen eseménysor létezik, vagy minden alkalmazás saját eseménysorral rendelkezhet. Az operációs rendszer feladata, hogy a megfelelő esemény a megfelelő programhoz kerüljön A Java esetén minden virtuális gép egy AWT eseménysorral rendelkezik. Mi a különbség az AWT és a Swing között? Az AWT rendszerben készülő programok minden operációs rendszeren másként nézne ki, mivel a komponensek kinézete a az operációs rendszer ablakozó felületéhez igazodik. Az események forrásuk alapján két csoportra oszthatók: beviteli események (billentyőleütés, egérmozgatás, stb.) és komponensek által kiváltott események. • Alacsonyszintű események (komponens által kiváltott): Az operációs rendszer szintjén történő elemi esemény. Forrása csak komponens lehet. Az alacsonyszintű események a közvetlen

kommunikációt jelentik a felhasználóval Alacsonyszintű esemény egy billentyű lenyomása vagy felengedése, egy egérkattintás, drag, stb. Ezek a következőket foglalják magukba: o java.awteventComponentEvent - komponens átméretezve, elmozgatva, stb o java.awteventContainerEvent - egy komponens hozzáadódott vagy levételre került a konténerről o java.awteventFocusEvent - komponens megkapta, elvesztette a fókuszt o java.awteventKeyEvent - billentyű lenyomva, felengedve, stb o java.awteventMouseEvent - egér le, fel, mozgatva, drag o java.awteventWindowEvent - az ablak aktívvá, passzívvá vált, megnyitódott, bezáródott, ikozizálódott, stb Alacsonyszintű események átalakitása magasszintűvé A nativ operációs rendszer és a felhasználói interfész csak alacsonyszintű eseményeket továbbít. Ehelyett az ezeket a magasszintű eseményeket elküldő komponensek figyelik az alacsonyszintűt. Ha ezen alacsonyszintű események kombinációját észlelik,

akkor "elfogyasztják" ezeket, s egy új magasszintű eseményt produkálnak. • Magasszintű események: Általában logikai esemény. Forrása nem feltétlenül komponens A magasszintű vagy szemantikus események a felhasználói interfész komponens jelentését foglalják magukba. Ezek közé tartoznak: o java.awteventActionEvent - egy parancs végrehajtása o java.awteventAdjustmentEvent - egy érték át lett állítva o java.awteventItemEvent - egy tétel állapota megváltozott o java.awteventTextEvent - egy szövegobjektum értéke megváltozott Például, ha a felhasználó rákattint egy nyomógombra, akkor a nyomógomb két vagy három alacsonyszintű egéreseményt kap (egyet mint egér le, egyet mint egér fel, s esetleg egy egér drag eseményt is, ha az egér elmozdul, mialatt le van nyomva az egér billentyűje). A nyomógomb azonban csak egy magasszintű ActionEvent típusú eseményt vált ki A nyomógomb azonban "elfogyasztja" ezeket az

eseményeket, s nem csinál semmit. A fentiek azonban csak akkor érvényesek, ha a nyomógombra csak a szemantikus eseményt regisztráltuk (lásd később). Ha az alacsony- és magasszintű eseményeket egyaránt regisztráltuk a nyomógombra, akkor valamennyit megkapja. Eseményfigyelők Hogy egy komponens egy eseményre reagálhasson, egy adott típusú esemény figyelőt (event listener) regisztráltatni kell az adott komponenshez. Az esemény figyelők objektumok, melyek a javautilEventListener interfészt implementálják Az AWT tizenegy java.utilEventListener interfészt definiál, minden eseménytípusra egyet-egyet • • • • • • • • • • • ActionListener: Események bekövetkezését figyeli. Melyik komponens váltotta ki AdjustementListener: Beállítás megváltozott (pl. scrollbar) ComponentListener: Méretezés, elrejtés, mozgatás, megjelenítés ContainerListener: Elemhozzáadása, eltávolítás FocusListener: Fókusz elvesztése, megkapása

ItemListener: Elem állapotának változása (gomb, checkbox, lista) KeyListener: Billentyű lenyomása, felengedése, karakter-e MouseListener: Megnyom, elenged, kattintás, belép, kilép MouseMotionListener: Drag, move TextListener: Szöveg megváltozott WindowsListener: Bezár, megnyit, aktív, inaktív Esemény adapter osztályok Ha egy Listener interfésznek több metódusa is van, létezik hozzá az interfészt üres törzső metódusokkal megvalósító adapter osztály. Ez lehetővé teszi az interfész részleges implementálását. Függvények az SQL-ben • • • • • • Aritmetikai függvények és műveletek: Megjeleníthetők a SELECT-ben, felhasználhatók annak WHERE és ORDER BY részében. Néhány függvény: ABS, GREATEST, LEAST, POWER, ROUND, TRUNC, +-/* Karakterkezelő függvények: Megjeleníthetők a SELECT-ben, felhasználhatók annak WHERE és ORDER BY részében. INITCAP, LOWER, UPPER, LENGTH, CONCAT, INSTR, SUBSTR, Dátum típusú adatokat kezelő

függvények: ADD MONTHS, GREATEST, LEAST, NEXT DAY, LAST DAY, ROUND, TRUNCK, MONTHS BETWEN Konverziós függvények: TO CHAR, TO NUMBER, TO DATE Aggregáló függvények: COUNT, SUM, AVG, MIN, MAX Predikátumfüggvények: A WHERE (illetve HAVING) parancs feltételében használhatjuk az egyszerű összehasonlításon kívül. - 12 - o BETWEEN o IN: Igaz, ha az oszlop értéke eleme a listának (valamelyikkel megegyezik). o LIKE: Igaz, ha az oszlop értéke megegyezik a like utáni értékkel/hasonlít a like utáni értékre (maszkolható: %). 6. A kifejezés fogalma Kifejezések kiértékelése, a műveletek precedenciája Egy választott programozási nyelv aritmetikai, logikai és relációs műveletei. Kifejezések az SQL-ben Kifejezések a Javában A Java nyelv szigorú típusegyeztetési szabályokat állított fel, az adatvesztési hibák kiszűrésére. Egy kifejezés operandusokból és operátorokból (műveletek) áll. A kifejezések kiértékelési sorrendjét a

zárójelek és az operátorok határozzák meg. A kiértékelés a következő szabályok szerint történik: zárójel, prioritás, sorrend, asszociativitás. Az operandus típusa: A Java nyelvben minden operandusnak van egy jól meghatározott típusa. Minden operátorhoz tartozik egy szabály, hogy milyen típusú operandus állhat annak bal, ill. jobb szélén A literálok név és típusjelzés nélküli adatok, melyek a program szövegében szerepelnek. Az operandus típusára vonatkozó jellemzők, szabályok: • Egy változó típusa a deklaráláskor megadott típus, • Egy függvény típusa, annak visszatérési értéke, • Egy egész literál automatikusan int típusú, hacsak nem teszünk a szám mögé egy L betőt, akkor a literál long típusú lesz. • Egy valós literál automatikusan double típusú, hacsak nem teszünk a szám mögé egy F betűt, ekkor float típusú lesz. • A logikai, a karakter, és a szöveg literálok típusai rendre boolean, char, és

String. A String nem primitív típus, hanem osztály Operátorok, aritmetikai és logikai műveletek a Javában Az alábbi ábrán fel van sorolva a Java összes operátora. A műveletek prioritása fentről lefelé csökken Operátor [ ] (<param>) ++ -++ -- + - ~ ! new (<típus>)<kif> * / % + << >> >>> < <= > >== instanceof == != & ^ | && || ?: = += -= *= /= %= &= |= ^= <<= >>= >>>= Elnevezés Unáris postfix operátorok Unáris prefix operátorok Példányosítás, típuskényszerítés Multiplikatív (szorzó) operátorok Additív (összeadó) operátorok Bitenkénti léptető operátorok Hasonlító operátorok Egyenlőségvizsgáló operátorok Logikai /bitenkénti ÉS Logikai /bitenkénti KIZÁRÓ VAGY Logikai bitenkénti VAGY Logikai rövid ÉS Logikai rövid VAGY Feltételes kiértékelés Értékadó operátorok Asszociativitás ← ← Egy operátor lehet: • Unáris:

egy operandusa van. o prefix: az operandus előtt áll. Pl: kiértékelés előtti léptetés: ++i o postfix: az operandus után áll. Pl: a kiértékelés utáni léptetés: i • bináris: két operandusa van. Pl: az összeadás: i+j Típuskonverziók A Java erősen típusos nyelv. Ez azt jelenti, hogy a fordító a típus kompatibilitásának ellenőrzését minden lehetséges esetben elvégzi Egy típus kompatibilis egy másik típussal, ha az adott környezetben helyettesíthető vele. Bizonyos műveletek végrehajtása előtt, az operandus típusát konvertálni kell egy másik típussá. A típuskonverziót két szempontból osztályozhatjuk: • Automatikus (implicit): a konverziót a fordító végzi el automatikusan: double d; int i = 5; d = i; (int konvertálása double típusúvá implicit módon) • Kényszerített (explicit): a programozónak kell kikényszeríteni a konverziót. d = 79.4; i = (int)d; i = d; (double konvertálása int típusúvá explicit módon)

Szűkítő és bővítő konverziók - 13 - A boolean típusú értéket nem lehet konvertálni egyetlen másik primitív típusba sem, és egyik érték sem konvertálható boolean típusúvá! Egy numerikus operátornak csak bizonyos típusú operandusai lehetnek. A szorzás bal és jobb oldalán állhat numerikus, de nem állhat logikai típusú kifejezés. Az egész literál automatikusan int, a valós literál, pedig automatikusan double típusú! A java a numerikus operátorok operandusait a kiértékelés előtt az alábbi szabályok szerint automatikusan konvertálja! • • Unáris (egyoperandusú) műveletek esetén, ha az operandus típusa int –nél szűkebb, akkor az operandust int típusuvá konvertálja, egyébként nem konvertálja. Bináris (kétoperandusú) műveletek esetén: mindkét operandust a kettő közül a bővebb, de minimum int típussá konvertálja. Az eredmény típusa a közös konvertált típus lesz. eredeti típusok byte*short int/long

float+int long*double konvertált típusok int*int long/long float+float double*double kifejezés típusa int long float double Értékadás, értékadási kompatibilitás Az értékadó operátor bal oldalán egy változó, jobb oldalán egy kifejezés áll: <változó> = <kifejezés> Az értékadó operátor precedenciája a legkisebb, így mindig a jobb oldali kifejezés értékelődik ki először, és csak ezután kerül be az eredmény a bal oldali változóba. A Java –ban többszörös értékadási is értelmezhető: <változó1> = <változó2> =.<változóN> = <kifejezés> A kifejezés típusának értékadás szerint kompatibilisnek kell lennie a változó típusával! Értékadás előtt a jobb oldal kiértékelődik, tehát mindkét oldal típusa adott. Az értékadás végrehajtásakor a Java a következő szabályok szerint jár el: • Ha a bal és jobb oldal típusai megegyeznek, akkor az értékadás típuskonverzió nélkül

végrehajtódik: • Implicit bővítő konverzió: Ha a jobb oldal szűkebb, mint a bal oldal (a jobb oldalt a bal oldal típusára konvertálja). • Implicit szűkítő konverzió: ha a bal oldal típusa byte, short, vagy char, és a fordító el tudja dönteni, hogy az int típusú jobb oldal belefér –e a bal oldalba. byte b = 127; // 127 értéke belefér a byte –ba. char c = 65; // belefér, van ilyen karakter. • Minden más esetben (amikor a fordító nem képes a két oldalt kompatibilissé tenni, fordítási hiba keletkezik. Kifejezések az SQL-ben Lásd az 5. tételt („Függvények az SQL-ben”) 7. Osztály és objektum fogalma Egységbezárás Osztály definiálása egy választott fejlesztő környezetben. Jellemzők (properties) Az osztálymodell kapcsolata az adatbázismodellel Osztály és objektum fogalma. Az objektum logikailag összetartozó adatok és rajtuk dolgozó algoritmusok (rutin, metódus, programkód) összessége. Egy objektumnak vannak adatai

és metódusai: • Adatok: az objektum az információt adatok, attribútumok formájában tárolja. • Metódusok: a metódus, olyan rutin, amely az objektum adatain dolgozik. Az objektumokat a feladatokra üzenetek által lehet megkérni. Egy üzenet hatására végrehajtásra kerül az objektumnak egy, az üzenettel azonos nevő metódusa, s ezáltal az objektum adatai megváltoznak. Az objektumnak mindig van valamilyen állapota (state). Ez megfelel az adatok pillanatnyi értékeinek Egy feladat elvégzése után az objektum állapota megváltozhat. Az objektum mindig emlékszik az állapotára, tehát megjegyzi azt! Két azonos osztályhoz tartozó objektumnak akkor és csak akkor ugyanaz az állapota, ha az adatok értékei rendre megegyeznek. Osztály Az osztályozás a természetes emberi gondolkodás szerves része. Az ugyanolyan adatokat tartalmazó és ugyanolyan viselkedésleírással jellemezhető objektumokat egy osztályba soroljuk Az osztály (class), olyan

objektumminta vagy típus, amelynek alapján példányokat (objektumokat) hozhatunk létre. Minden objektum egy jól meghatározott osztályhoz tartozik. Az objektum felkérhet más objektumokat különböző feladatok elvégzésére. A felkérést üzenetnek, vagy kérelemnek nevezzük Az egyes objektumok tehát üzenetek révén szólítják meg egymást. A feladatot kiadó objektumot kliensnek (aktor), a feladatot elvégzőt pedig szervernek (agent) hívjuk. Üzenet Az üzenet egy kívülrıl elérhető metódus hívása. Az üzenetet a kliens küldi és a szerver fogadja Az üzenetet a megszólítandó objektum azonosítójával minősítjük, és az üzenetnek lehetnek paraméterei: objektum.üzenet(paraméterek) Ha a megszólított objektumtól választ (információt) is kérünk, akkor azt paraméterek révén, ill a függvény visszatérési értékeként kapjuk meg. - 14 - Életciklus Az objektumnak életciklusa van. (születés, élet, halál) Az objektumot létre kell

hozni, majd azt követıen inicializálni kell: • be kell állítani kezdeti adatait, • végre kell hajtani azokat a tevékenységeket, amelyek az objektum működéséhez szükségesek. Az inicializálást végző metódust konstruktornak nevezzük Egységbezárás: A bezárás az adatok és metódusok összezárását, beokozását jelenti. (egységbezárás elve) Fontosabb szabályok: • az objektumnak van egy interfésze, amely a programozó által kijelölt metódusok összessége. • Az objektumot csak az interfészen lehet megközelíteni. • Az adatok csak metódusokon keresztül érhetők el • Az objektum interfész része a lehető legkisebb Osztály definiálása egy választott fejlesztő környezetben (Java). Az Object osztály: A Javában minden osztály az Object osztályból származik. Mondhatjuk, hogy bármelyik osztályból létrehozott példány az egy objektum, így azt minden olyan feladatra meg lehet kérni, amely már az Object osztályban is

definiálva van. Az Object osztály olyan metódusokat tartalmaz, amelyek a Java minden objektumára jellemzők. Nézzünk meg néhányat: • boolean equals(Object obj): összehasonlítja a megszólított objektumot a paraméterében megadott objektummal. A visszaadott érték true ha a két objektum egyenlő. • String toString (): az objektum szöveges reprezentációját adja vissza. • Class getClass (): visszaadja az objektum osztályát. Primitív típus – referenciatípus Objektum létrehozása, deklarálása Értékadás az objektumok körében Objektumok egyenlőségvizsgálata A String osztály StringBuffer osztály Objektum átadása paraméterként Primitív típusok csomagolása Lásd a 3. tételt StringTokenizer osztály: A StringTokenizer osztály segítségével egy szöveg könnyen egységekre (részekre, tokenekre) bontható. Az egyes egységeket egy vagy több elválasztó karakter különíti el egymástól. Ezek az elválasztó karakterek alapértelmezésben a

fehér szóközök (szóköz, TAB, CR, LF, és FF karakterek), de az elválasztó karakterek halmazát mi magunk is megadhatjuk. Objektumok, osztályok sztereotípusai: Az UML szerint az objektumok, osztályok lényegesebb sztereotípusai a következők: • Információhordozó (egyed, üzleti) objektum: Az információhordozó objektum információt tárol. Rendszerint hosszabb életű, vagyis túléli a program futását. Ezeket az objektumokat gyakran adatbázisban tárolják Az információhordozó objektum általában valós világbeli személy, dolog, hely, fogalom vagy esemény. Például egy banki rendszerben: bank, ügyfél, számla stb • Határobjektum (interfészobjektum): A határobjektum a külvilággal kapcsolatot teremtő objektum. Az aktor határobjektumokon keresztül kommunikál a rendszerrel. Határobjektumok például egy grafikus felhasználói felület elemei: ablakok, beviteli mezők, nyomógombok stb. Mindig a határobjektum ismeri az információhordozó

objektumot, sosem fordítva! • Kontrollobjektum: Vezérlést, számolást végrehajtó objektum. Ilyen például egy folyamatvezérlő, egy statisztikai adatgyűjtő, vagy egy más objektumokat koordináló objektum. • Konténerobjektum: A konténerobjektum tipikusan implementációs (a program kódolását elősegítő) objektum. A konténer az objektumok közötti kapcsolatok megvalósítását szolgálja. Osztálydiagram Az osztálydiagram a feladatban szereplő objektumok osztályait és azok (társítási és öröklési) kapcsolatait ábrázolja. A rendszert egyetlen osztálydiagram írja le. Az osztálydiagramon szerepel a rendszer összes olyan objektumának osztálya, melyet a forráskódban meg kell valósítani. Az osztálydiagramon az API osztályait csak akkor szokás feltüntetni, ha az szükséges a rendszer megértéséhez - 15 - Együttműködési diagram: Olyan objektumdiagram, amelyen feltüntetjük az egyes objektumoknak küldött üzeneteket. Az

együttműködési diagramon osztályok is szerepelhetnek az osztályváltozók, illetve osztálymetódusok használata miatt. A diagram üzeneteit a végrehajtás sorrendjében be lehet sorszámozni. Az együttműködési diagram segítségével szemléletessé tehetjük az egyes használati eseteket, illetve operációkat működés közben. Egy osztálydiagramhoz több együttműködési diagram is tartozhat. Az együttműködési diagram az osztálydiagram egy példánya, a működő program egy pillanatfelvétele. Láthatóság: Az osztály deklarációi a következő láthatósággal (hozzáférési móddal) rendelkezhetnek: • Nyilvános (public, +): minden kapcsolatban álló kliens eléri és használhatja; • Védett (protected, #): hozzáférés csak öröklésen keresztül lehetséges; • Privát (private, -): az osztály privát deklarációja, csak az osztály saját metódusai férhetnek hozzá. A létrehozott objektum osztálya lehet az az osztály is, amelyben a

létrehozást végezzük. Ily módon az objektumnak több példánya is létrehozható saját magából. A létrehozás osztály- vagy példánymetódusból egyaránt történhet Az osztály felépítése, az osztály deklarációi: Az osztály egy fejből és blokkból áll. (<módosítók>) class <OsztályAzon> (extends <OsztályAzon>) (implements <InterfészAzon>(, <InterfészAzon> )) { <osztály blokk (az osztály deklarációi)> } Módosítók: Egy osztálynak a következő módosítói lehetnek: • Hozzáférési módosítók: csak a public használható. Ha nem adunk meg semmit, akkor alapértelmezés szerint az osztály csak a saját csomagjában látható. Egy fordítási egységben csak egy publikus osztály lehet, s annak neve meg kell, hogy egyezzék az állomány nevével. • Egyéb módosítók: o abstarct: Az absztrakt osztály csak örökítési célokat szolgál, abból nem lehet példányt létrehozni. o final: nem örökíthető

Osztályok blokkja, az osztály deklarációi: Osztály szintű deklaráció: közvetlenül az osztály blokkjában lévő deklaráció. • osztálytagok (osztályváltozók és osztálymetódusok) • példánytagok (példányváltozók és példánymetódusok) • konstruktorok • osztályinicializáló blokkok • példányinicializáló blokkok • belső osztályok Osztálytag: Más néven statikus tag: az osztályhoz tartozik, és az osztály minden objektumára egyformán érvényes. Az osztálytag módosítója static. Az osztálytag lehet: • Osztályváltozó vagy más néven statikus változó: az osztályhoz tartozó változó, az egyes példányokban nem jelenik meg. • Osztálymetódus vagy más néven statikus metódus: az osztály saját metódusa, mely csak az osztály tagokat látja. Példánytag: Példánytag: A példányhoz tartozik, minden egyes példányra jellemző. A példánytagnak nincs staic módosítója (innen ismerhető fel) A példánytag lehet: •

Példányváltozó: minden példányban külön szerepel, értéke a példány állapotára jellemző. • Példánymetódus: a megszólított példányon dolgozik, mely az osztály- és példánytagokat egyaránt látja. Azonosító, hivatkozási kör, takarás: Az egyes deklarációkra a következő szabályok szerint lehet hivatkozni: • A metódus blokkjából hivatkozni lehet az osztály bármely tagjára (osztálymetódusból csak osztály tagra). • Egy adattag csak a fizikailag előtte deklarált tagokra hivatkozhat (osztályadat csak osztályadatra). • Egy metódus lokális változójára csak az őt deklaráló metódus hivatkozhat. Az osztályban ugyanazon a néven deklarálható metódus és változó, sőt a metódusok túlterhelhetık. A lokális változók eltakarják az ugyanolyan nevű osztály- illetve példányváltozókat. Ha az osztály deklarációjára szeretnénk hivatkozni, akkor osztályváltozó esetén az osztály nevével, példányváltozó esetén

pedig a this referenciával kell azt minősítenünk. A this implicit paraméter nem más, mint memóriacím, amely a megszólított objektum referenciája. Egy példánymetódus innen tudja, hogy éppen melyik példányon dolgozik (a this által mutatott objektumon). Egymásból hívott metódusok esetén a this automatikusan továbbadódik. - 16 - Konstruktorok: Amikor egy objektumot a new operátorral létrehozunk, akkor azt inicializálni kell. A konstruktor elsődleges feladata az objektum kezdeti állapotának (adatainak és kapcsolatainak) beállítása, felépítése. A konstruktor hasonlít a metódushoz – a következő szabályok érvényesek rá • A konstruktor neve kötelezően megegyezik az osztály nevével. • Csak a new operátorral hívható. Egy konstruktorral nem lehet újra inicializálni egy objektumot • A módosítók közül csak a hozzáférési (láthatósági) módosítók használhatók. • A konstruktor túlterhelhető • A konstruktornak nincs

visszatérési értéke és nem void. • A konstruktor nem öröklődik. Alapértelmezés szerinti konstruktor Ha egy osztályban nem adunk meg explicit módon konstruktort, akkor az osztálynak lesz egy alapértelmezés szerinti (default), paraméter nélküli konstruktora. Ha tehát az osztályban nem adtak meg konstruktort, akkor a példány létrehozásakor a rendszer ezt az alapértelmezés szerinti konstruktort hívja meg. Az objektum adatai ekkor az alapértelmezések szerint lesznek beállítva Ha az osztályban létezik egy akármilyen explicit konstruktor, akkor az osztálynak nem lesz implicit, alapértelmezés szerinti konstruktora. Konstruktor túlterhelése: A konstruktorok ugyanúgy túlterhelhetők, mint más metódusok. Egy objektum így többféleképpen is inicializálható Ha egy osztály több konstruktort definiál, akkor az egyik konstruktorból – annak első utasításaként – meghívható egy másik konstruktor. Inicializáló Inicializáló kifejezéssel

egy változónak, illetve konstansnak adhatunk kezdeti értéket. A kifejezés kiértékelése • osztálytag esetén: az osztály betöltésekor; • példánytag esetén: az objektum születésekor (a new operátor végrehajtásakor) történik meg. Egyéb szabályok: • Az inicializáló kifejezések a deklarálás sorrendjében kerülnek kiértékelésre; előbb az osztály, aztán a példánytagok inicializáló kifejezései. • A kifejezésben csak a kifejezés előtt szereplő deklarációkra hivatkozhatunk. • Osztálytagokból nem hivatkozhatunk példánytagokra. Inicializáló blokk Egy osztályt az osztályinicializáló blokk, egy példányt pedig a példányinicializáló blokk segítségével inicializálhatunk. Az inicializáló blokk olyan programkód, amely az osztály, illetve a példány életében egyetlenegyszer, első tevékenységként fut le. Egy osztályban akárhány osztály-, illetve példányinicializáló blokk deklarálható. •

Osztályinicializáló blokk: (statikus inicializáló blokk): Az osztályinicializáló blokkot osztályszintű változók inicializálására szokták használni. Az osztályinicializáló blokk egyszerű blokk (csak egy {} zárójelpár; nincs feje), melyet a static kulcsszó vezet be. static { alapTandij = 2000; } • Példányinicializáló blokk: Példányonként egyszer, a példányszületésekor hajtódik végre. A példányinicializáló blokk egyszerű blokk, mely előtt nem szerepel a static kulcsszó. Előbb az osztálytagok aztán a példánytagok inicializáló blokkjai kerülnek végrehajtásra, a deklarálás sorrendjében. Az inicializáló blokkok csak olyan deklarációkra hivatkozhatnak, amelyek fizikailag a blokk előtt szerepelnek. Az inicializálás sorrendje: • Mindenekelőtt az osztályadatok kapnak kezdeti értéket: o először felveszik az alapértelmezés szerinti értékeket, majd o kiértékelődnek az osztályinicializáló kifejezések, o majd

lefutnak az osztályinicializáló blokkok a deklarálás sorrendjében. • Egy objektum születésekor az objektum adatai a következő szabályok szerint kapnak kezdeti értéket: o először felveszik az alapértelmezés szerinti értékeket, aztán o kiértékelődnek az inicializáló kifejezések, o majd lefutnak a példányinicializáló blokkok a deklarálás sorrendjében; o végül sorban lefutnak az esetlegesen egymást hívó konstruktorok. Jellemző (Property) Az objektum beállítható (setXY()) és lekérdezhetı (getXY()) tulajdonságát jellemzőnek nevezünk(„property”). Az osztálymodell kapcsolata az adatbázis-modellel. Ha az osztálymodellünket jól terveztük meg, akkor a modellben lévő „entitás” (entity) jellegű osztályok az adatbázismodellben egy-egy konkrét táblának felelnek majd meg. Ez az ún objektum-relációs leképezés, amelynek egyik mai tipikus képviselője a Javában lévő EJB technológia. (Enterprise Java Beans) Az EJB-k a

relációs adatbázissal az SQL nyelv segítségével kommunikálnak. Egy ilyen Java entitás-osztály főbb jellemzői: • Implementálja a „Serializable” interfészt. • Kötelező egy elsődleges kulcs attribútum. • A konkrét adattábla egy oszlopának (mezőjének) az entitás egy konkrét tulajdonsága (property) felel meg. - 17 - 8. Objektumok és osztályok közötti kapcsolatok A kapcsolatok implementálása Öröklődés, polimorfizmus, virtualitás. Objektumok és osztályok közötti kapcsolatok Az objektumok csak úgy tudnak együttmőködni, ha azok kapcsolatban állnak egymással. Ha a kliens objektum üzenetet akar küldeni egy másik objektumnak, akkor tartalmaznia kell a megszólítani kívánt szerver objektum azonosítóját. Ismeretségi kapcsolat Két objektum ismeretségi kapcsolatban áll egymással, ha azok léte egymástól független és legalább az egyik ismeri, ill. használja a másikat. Az ismeretségi kapcsolatban álló objektumok közül

bármelyik megszüntethető Tartalmazási kapcsolat (egész-rész) Két objektum tartalmazási kapcsolatban áll egymással, ha az egyik fizikailag is tartalmazza vagy birtokolja a másik objektumot. A tartalmazó objektum az összetett (egész) objektum, a benne lévő pedig a rész objektum. A rész objektum léte az egész objektumtól függ, vagyis ha az egész objektumot megszüntetjük, vele együtt pusztul a rész is. Kétféle tartalmazási kapcsolat létezik: • gyenge tartalmazás: ha a rész kivehető az egészből • erős tartalmazás: ha a rész nem vehető ki az egészből. Tartalmazási kapcsolat esetén a kapcsolat vonalára egy kis rombuszt teszünk a tartalmazó objektum oldalára: a gyenge tartalmazást üres, míg az erős tartalmazást tömör rombusz jelöli. Kompozíció Az a tartalmazás, amelyben az egész objektum erős tartalmazási kapcsolatban áll valamennyi részével, vagyis az egész létrehozásakor összeáll a végleges kompozíció, és később

nem vehető ki belőle egyetlen rész sem. A tartalmazási kapcsolat erősebb, mint az ismeretség Multi objektum Ha egy objektum több egyforma (egy osztályhoz tartozó) objektummal áll kapcsolatban, akkor azokat objektumcsoportként, egymást majdnem takaró téglalapokkal ábrázolhatjuk. A kapcsolatok megvalósítása Az osztályokat és azok kapcsolatait ábrázoló diagramot osztálydiagramnak nevezzük. • • • Egy-egy kapcsolat: az egyik osztály egy példánya a másik osztály legfeljebb egy (0.1) példányával állhat kapcsolatban A másik osztályra ugyanez vonatkozik. Az egyik osztályban felveszünk egy referencia tulajdonságot a másik osztályra Egy–egy kapcsolat esetén a referencia kétféleképpen kaphat értéket: o A kliens maga létrehozza a szervert, akkor a referencia automatikusan azonosítja az új objektumot: autó = new Autó() o Egy már létező objektumra hivatkozunk. Ennek érdekében a kliensobjektumban felveszünk egy

referenciatulajdonságot, és ezt ráirányítjuk a már létező szerverobjektumra, például: dávid.autó = anitaautó Ez utóbbi értékadás itt azt jelenti, hogy Anita autója Dávidé (is) lett: az értékadás után Dávid ugyanarra az autóra mutat, amelyikre Anita. Egy-sok kapcsolat: az egyik osztály egy példánya a másik osztály sok példányával állhat kapcsolatban, a másik osztály egy példánya viszont legfeljebb egy példánnyal állhat kapcsolatban az egyik osztályból. Konténer objektumokkal (pl vektor) valósítjuk meg, de megvalósítható több referenciatulajdonság definiálásával is. A konténer dolga, hogy a beledobott objektumokat tárolja, megjegyezze azok sorrendiségét, abban egy adott objektumot megkeressen, és szükség szerint kiadja a kért objektum referenciáját (az objektum a konténerben marad, csak a kliens kapcsolatba kerül a konténerben lakó szerverrel). A konténerobjektumot az osztálydiagramon az „egy” és a „sok”

objektum közé tesszük. (Pl emberek és autóik) A Konténer osztály metódusai o size(): Visszaadja a konténer méretét, vagyis azt, hogy hány objektum van benne pillanatnyilag. o add(obj: Object) Objektum hozzáadása a konténerhez. o first(): A tárolás szerinti első objektum referenciájának kiadása. o next(obj: Object): o rNext(obj: Object): Körbe megy. Az utolsó elem után az első referenciáját adja vissza o prev(obj: Object): o rPrev(obj: Object): Szintén körbe megy. o remove(obj: Object): törli a konténerből. o clear(): Az összes objektumot törli a konténerből. Sok-sok kapcsolat: mindkét osztály akármelyik példánya a másik osztály sok példányával állhat kapcsolatban. Társítási kapcsolat megvalósítása A kliens (kérő) objektumnak ismernie kell a szerver (kiszolgáló) objektumot, különben nem tudja azt megszólítani. A program készítésekor a kliens objektumban felveszünk egy szerverre vonatkozó referenciát. Öröklődés

Specializálással egy már meglevő osztály tulajdonságait és képességeit felhasználva újabb osztályt készíthetünk. A meglévő osztály az ősosztály, a specializált pedig az utódosztály, más szóval kiterjesztett osztály. A specializált osztály örökli az ősosztály adatait és metódusait, azokhoz újabbakat adhatunk, vagy módosíthatjuk a már meglévőket. Szabályok: • A hierarchia mélysége tetszőleges, de csak 10 alatti szám ajánlott, • Az öröklés tranzitív: ha A örökli B –t, és B örökli C –t, akkor A örökli C –t, • Példányadatok öröklése: az utód osztály példányainak adatai = ős adatok+ saját • • - 18 - Példánymetódusok öröklése: bármely metódust felül lehet írni. Az utód osztály az ős osztály kapcsolatait is örökli. Egyszeres öröklés: egy osztálynak csak egy őse lehet. Többszörös öröklés: egy osztálynak több őse is lehet. Java –ban csak egyszeres öröklés van Milyen

üzenetek küldhetők az egyes példányoknak? • Ős osztály példányának: az osztályában deklarált összes metódus meghívható. • Utód osztály példányának: Minden olyan metódus hívható, amely az öröklési ágon megtalálható. Ha van az objektum osztályában ilyen nevű metódus, akkor az hajtódik végre, ha nincs, akkor a keresés felfelé halad az öröklési ágon. Az interfész fogalma Egy interfész metódusfejeket definiál abból a célból, hogy valamely osztály azt a későbbiekben implementálja, megvalósítsa. Az implementáló osztály speciális utódja az interfésznek. Egy osztály több interfészt is implementálhat, függetlenül attól, hogy milyen osztályokat örököl. Az interfész képességek gyűjteménye. Az interfész a metódusoknak csak a formáját adja meg, azokat nem valósítja meg Egy osztály úgy implementál egy interfészt, hogy megírja az ott megadott metódusokat. Láthatóság, (hozzáférési mód): Már volt szó

arról, hogy az adatokat nem szabad kívülrıl manipulálni, és vannak olyan metódusok is, amelyeket a külső felhasználók elıl el kell zárni. A módszerek a következők: • Nyilvános (public): minden kapcsolatban álló kliens eléri és használhatja. UML jelölése: + • Védett (protected): hozzáférés csak öröklésen keresztül lehetséges. UML jelölése: # • Privát (private): csak az osztály saját metódusai férhetnek hozzá. UML jelölése: Egy kész osztályt kétféleképpen lehet használni: • az osztályból példányt hozunk létre: egy objektumnak kizárólag csak a publikus deklarációit lehet elérni. A privát és védett deklarációkat az objektum megszólításával nem lehet használni. • az osztályból örökítéssel új osztályt hozunk létre: az örökítéskor az új utód osztályban felhasználjuk a már meglévő osztály adatait és metódusait. A privát deklarációkat csak az osztály programozója érheti el, ahhoz még

öröklés révén sem lehet hozzáférni. A nyilvános és védett deklarációkat az utód osztály használhatja, hivatkozhat rájuk Az osztályokat csoportosítani lehet: a logikailag összetartozó osztályokat csomagokba (package) foglalják. A teljességhez hozzátartoznak még a következő szabályok: • • A láthatóságot nem kötelező megadni. A láthatóság alapértelmezése, az ún csomag szintű láthatóság, ez azt jelenti, hogy a deklaráció az aktuális csomagban nyilvános. Egy osztálynak is van láthatósága: a publikus osztály más csomagokból is látható. Alapértelmezésként egy osztály csak a saját csomagjában látható. Polimorfizmus (többalakúság) Ugyanarra a kérelemre a különböző objektumok különbözőképpen reagálhatnak. A Javában, írhatunk több, azonos nevő metódust is. Ekkor viszont az azonos nevő metódusok paraméterezésének (paraméterek darabszáma, paraméterek típusai) eltérınek kell lennie! Tehát a több

azonos nevő metódus közül az fog végrehajtódni, amelyikre pontosan ráillenek a hívás helyén adott paraméterek (darabszám és sorban a paraméterek típusai)! Futás alatti (késői) kötés: Hogy egy üzenet pontosan melyik metódus hívását jelenti, az sokszor csak a program futásakor derülhet ki. Ezt a jelenséget futás alatti kötésnek nevezzük. Virtualitás Az @Override annotáció lényege, hogy egy ilyenformán jelölt metódusnak felül kell definiálnia egy azonos nevű és tulajdonságú metódust az ősosztályban. A @Override annotáció elsősorban a fordítónak jelent nagy segítséget, amikor kinyomozza, hogy mely konkrét osztály metódusát is kell majd végrehajtani. Super kulcsszó Az ősosztály azonos nevű metódusa halytódik végre. Pl supermegy(); 9. A felhasználói felület, az alkalmazáslogika és az adatbázislogika szerepe, az ezeket realizáló objektumok sztereotípusai. Az egyes alkalmazás-rétegek jellemző komponensei egy

választott fejlesztő eszköz esetében. Többrétegű alkalmazások Az alkalmazás rétegei • Felhasználói felület • Alkalmazás logika • Adatkezelés A többrétegű architektúra a szoftverfejlesztésben alkalmazott kliens-szerver architektúra, melyben a rétegek különálló folyamatokra van bontva. Az alkalmazás rétegekre bontásával a fejlesztők könnyen karbantartható és fejleszthető rendszereket hozhatnak létre, - 19 - mivel elegendő egy-egy réteget javítani illetve bővíteni az egész alkalmazás módosítása helyett. A leggyakrabban alkalmazott rétegelés a háromrétegű architektúra. Monolitikus alkalmazások: Ekkor a 3 réteg egyazon kódba kerül beágyazásra. Gyakorlatilag ez a jelenség áll fent, ha pl egy asztali alkalmazást készítünk, ill ez az építkezési mód volt jellemző az ún. „nagygépes korszakban” Szerver - kliens alkalmazás • • Szerver o Alkalmazáslogika 2 o Adatkezelés Kliens o Felhasználói felület o

Alkalmazáslogika 1 Háromrétegű komponens architektúra A modell legnagyobb előnye, hogy lehetővé teszi az egyes rétegek egymástól függetlenül történő fejlesztését, sőt, akár teljes cseréjét is, lépést tartva így a folyamatosan változó követelményekkel és az egyre újabb technológiákkal. Ez biztonságosan megtehető, mert egy réteg módosítása nincs hatással a többi réteg működésére. Például ha a megjelenítésért felelős szerverre új operációs rendszer kerül, akkor elég csak a megjelenítést vezérlő modulokat frissíteni az alkalmazásunkban, az új körülményeknek megfelelően. Háromrétegű architektúra esetén az alkalmazást az alábbi 3 rétegre bontjuk • • • Megjelenítés: a társ rendszer felé nyújt interfészt (gyakran ez a felhasználói interfész), és az ehhez kapcsolódó eseményeket kezeli le. Ennek a leggyakoribb megvalósítása a weboldal és az előállító logika Üzleti logika: ezen réteg

feladata az üzleti folyamatok futtatása, hosszú életű tranzakciók kezelése. Itt kerül sor az adatok szélesebb hatókört, több adattípust átölelő szabályainak kikényszerítésére is. Perzisztencia: az adatok tartós tárolásával foglalkozik. Itt történik meg a szűkebb hatókörrel rendelkező adatszabályok kikényszerítése és gyakran az objektum és relációs adatmodellek közötti leképezés is. Az objektumok sztereotípusai • • • • Információhordozó (egyed, üzleti) objektum: Az információhordozó objektum információt tárol. Rendszerint hosszabb életű, vagyis túléli a program futását. Ezeket az objektumokat gyakran adatbázisban tárolják Az információhordozó objektum általában valós világbeli személy, dolog, hely, fogalom vagy esemény. Például egy banki rendszerben: bank, ügyfél, számla stb. Java EE-ben egy EJB entitás (kiszolgálóoldali software-komponensek) Határobjektum (interfészobjektum): A határobjektum

a külvilággal kapcsolatot teremtő objektum. Az aktor határobjektumokon keresztül kommunikál a rendszerrel. Határobjektumok például egy grafikus felhasználói felület elemei: ablakok, beviteli mezők, nyomógombok stb. Mindig a határobjektum ismeri az információhordozó objektumot, sosem fordítva! Java EE-ben egy JSP vagy JSF lap. Kontrollobjektum: Alkalmazáslogika. Vezérlést, számolást végrehajtó objektum Ilyen például egy folyamatvezérlő, egy statisztikai adatgyűjtő, vagy egy más objektumokat koordináló objektum. Java EE-ben az Enterprise JavaBeans, konkrétan a Session Bean-ek és a Message Driven Bean-ek. Konténerobjektum: A konténerobjektum tipikusan implementációs (a program kódolását elősegítő) objektum. A konténer az objektumok közötti 1:N kapcsolatok megvalósítását szolgálja. SWING – AWT Az awt programozói eszközkészlet úgy működik, hogy az ablakok a komponensek megjelenítését az operációs rendszer ablakkezelőjére

bízza, minden operációs rendszeren. Ennek eredménye, hogy ugyanaz a program másként néz ki Windowson, Linuxon, MacOSX-en vagy más rendszeren. A Swing eszközkészletet úgy alakították ki, hogy maga határozza meg hogyan nézzen ki a program ablaka. Így egységes kinézetet kapunk minden operációs rendszeren A Java EE 5 Az Enterprise Edition abban különbözik a Standard Edition-től, hogy több programkönyvtárat (API-t) tartalmaz és az alkalmazásszerveren futó moduláris szoftverkomponensek segítségével támogatja hibatűrı, többrétegű, elosztott alkalmazások készítését. Az Enterprise Edition részét képezik többek között a következő API-k: • JDBC, azaz Java Database Connectivity: adazbázisok elérését, kezelését biztosítja, SQL. • RMI, azaz Remote Method Invocation: távoli objektumok metódusainak meghívását lehetővé tevő fejlesztői interfész • E-mail API: e-mail kliens alkalmazások fejleszthetők. • JMS, azaz Java Message

Service: üzeneteket lehet küldeni különböző szoftverkomponensek között. Az elosztott rendszerekben az üzenetküldés egy úgynevezett lazán csatolt kommunikáció. Ez arra utal, hogy a szoftverkomponensek nem közvetlenül kommunikálnak egymással, hanem egy köztes (üzenetkezelő) komponens segítségével. • web service-ek: wenszolgáltatásokat nyújt • XML API: XML feldolgozás Tartalmaz továbbá olyan specifikációkat is, amelyek a JEE szoftverkomponensekre vonatkoznak • Enterprise JavaBeans: Moduláris vállalati alkalmazásokban használt szerveroldali komponensek. Általában az üzleti logika implementációját tartalmazzák. • Servlet: Egy HTTP kérést dolgoz fel és HTTP választ generál. Dinamikus tartalomgenerálás tesz lehetővé • • • - 20 - Portlet: Definiálja a portlet konténer és a portletek közötti szerződést és egy kényelmes programozási modellt nyújt a Java portlet fejlesztők számára. A portletek webportálokba

építhető UI-komponensek, melyek a portál konténerben futnak ( e-mail kliens, időjárás-előrejelzés, hírek) JSP - JavaServer Pages: Dinamikusan tud generálni HTML, XML vagy egyéb dokumentumokat HTTP kérésekre reagálva. JSF - JavaServer Faces: Keretrendszer webes felhasználói felületek fejlesztéséhez. Egy Java EE alkalmazásszerver tudja kezelni a telepített komponensek tranzakcióit, skálázhatóságát és konkurrenciáját, így a fejlesztő koncentrálhat az alkalmazás (üzleti) logikájára, mivel nem kell az infrastruktúrával és az integrációval foglalkozni. Java EE architektúra • • • Kliens réteg o Vékony kliens: • Web böngészőben futó programok, egyszerű HTML lapok. o Vastag kliens: • Gazdag webes tartalom, pl. java Applet, Java FX • Asztali alkalmazások A Java EE Server o Web réteg: Ha vékony kliensek kiszolgálására is szükség van, akkor rendelkeznünk kell egy web réteggel is. A böngészőből érkező HTTP

kéréseket értelmezi, meghívja a megfelelő üzleti komponenst, végül pedig elküldi az összeállított választ a böngészőnek. o Üzleti réteg: Az üzleti logikai EJB komponensekkel valósul meg. Ezek az alábbiak: • Session Bean: Egy üzleti munkafolyamatot jelképez. Az egyes metódusai általában az entitásokat kezelik • Message Driven Bean: JMS üzeneteket indítanak és fogadnak. Az üzenetek lehetnek szinkron és aszinkron üzemmódúak. Adatbázis réteg: Az entity bean-ek az alkalmazás perzisztens objektumait képviselik, amelyek valamilyen tárolóból származnak (tipikus példa: egy relációs adatbázisból). Egy „entity bean” többnyire megfeleltethető egy táblának az adatbázisban, és minden egyes példánya a tábla egy sorát reprezentálja. EJB Az Enterprise JavaBeans a JavaBeans technológia kiterjesztése elosztott rendszerek számára. Az Enterprise Bean-ek kiszolgálóoldali software-komponensek, egy többrétegû alkalmazás üzleti

logikáját lehet belõlük összeállítani. Bár az EJB rokona a JavaBeans-nek, más követelményeket (is) támaszt, és másra is való: • • • Session Bean Egy üzleti munkafolyamatot jelképez. Az egyes metódusai általában az entitásokat kezelik, nem megosztható (egy Session Bean egyetlen egy klienshez tartozhat csak). Állapotát nem, vagy csak rövid időre kell megőrizni Üzenetvezérelt (Message-Driven Bean) JMS üzeneteket indítanak és fogadnak a szoftver kompenensek között. Az üzenetek lehetnek szinkron és aszinkron üzemmódúak. Entity bean Az entity bean-ek az alkalmazás perzisztens objektumait képviselik, amelyek valamilyen tárolóból származnak (tipikus példa: egy relációs adatbázisból). Egy „entity bean” többnyire megfeleltethető egy táblának az adatbázisban, és minden egyes példánya a tábla egy sorát reprezentálja. 10. Felhasználói felület (ablakok, menük, stb) tervezése – alapelvek, szabályok, szabványok

Eseményvezérelt program, kapcsolat az operációs rendszerrel. Az eseményvezérelt programozás megvalósítása egy választott fejlesztő eszköznél. A grafikus felhasználói felület (GUI) a számítástechnikában olyan, a számítógép és ember közti kapcsolatot megvalósító elemek összessége, melyek a monitor képernyőjén szöveges és rajzos elemek együtteseként jelennek meg. A grafikus felhasználói felületeken alapvető szerepe van a mutatóeszközök, például az egér használatának, amelyekkel a grafikus felület elemei intuitív módon, a fizikai világ egyfajta modelljeként kezelhetők. A leggyakoribb grafikus felhasználói elemek az ablakok, menük, választógombok, jelölőnégyzetek és ikonok, valamint a mutatóeszközhöz kapcsolódó egérkurzor. Egy felhasználói felület akkor jól tervezett, ha a program úgy reagál, ahogyan azt a felhasználó várja. A GUI-kat általában a parancssoros felhasználói felületekkel (CLI) állítják

szembe, amelyben a felhasználónak parancsokat vagy karakterláncokat kellett begépelnie ahhoz, hogy a számítógépnek feladatokat adjon. Bár több tanulás árán, számos feladat elvégzésében és automatizálásában a parancssori felületek nagyobb hatékonysággal alkalmazhatók. Ezt bizonyítja a több mint 30 év óta töretlen népszerűségnek örvendő Unix rendszerhéj vagy a különböző specializált parancssori adatbázis-lekérdező felületek használata. Egy köztes típus, de jobban hasonlít a GUI-ra a szöveges felhasználói felület (TUI), mely ugyancsak képi eszközöket használ, de karaktercellás szöveges módban, nem pedig képpontalapú grafikus módban. Egy ismert TUI a Norton Commander fájlkezelő programrendszer, de példaként felhozható sok más NCursesés DOS alkalmazás is. - 21 - A látási vagy mozgási fogyatékos felhasználóknak általában több problémájuk akad a grafikus felhasználói felületben való navigációval.

Emiatt elterjedt megoldás a grafikus felület összekötése a hangvezérléssel Felhasználói interfész szabványok IBM SAA/CUA IBM 1987-ben kidolgozott egy szabványgyőjteményt: SAA (System Application Architecture), amely a PC-ket, mini, nagy és szuperszámítógépeket átfogva leszabályozza a különböző gépcsaládok és típusok közötti együttműködés, átjárhatóság feltételeit, módját, technikáját. SAA legfontosabb fejezetei • Egységes grafikus felület (CUA) Common User Access): Pl. minden program F1-el hívja a Help-et, milyen formában, hogyan közölje a rendszer a hibaüzeneteket. Egységes használat előírása (funkcióbillentyűk, dialógus ablakok, címek, adatmezők elhelyezése stb.) A CUA három különböző modellt javasol az eltérő hardver platformokra. o Entry model: nem programozható terminálok, ill. nagyszámítógépes terminálok felhasználói interfésze o Grafikus modell: Lényegében a személyi számítógépek GUI-ja. o

Hibrid modell: A grafikus modell részhalmaza. Gyakorlatilag a DOS operációs rendszer adta hozzá az alapot o o o o o o o • • All operations could be done with either the mouse or the keyboard; Menus are activated/deactivated with the F10 key; Menus are opened by pressing the Alt key plus the underlined letter of the menu name; Menu commands that require parameters to proceed are suffixed with an ellipsis (""); Options are requested using secondary windows (often called dialog boxes); Options are divided into sections using notebook tabs; Navigation within fields in dialog boxes is by cursor key; navigation between fields is by pressing the Tab ↹ key; ⇧ Shift+Tab ↹ moves backwards; o Dialog boxes have a Cancel button, activated by pressing the Esc key, which discards changes, and an OK button, activated by pressing Return, which accepts changes; o Applications have online help accessed by a Help menu, which is the last option on the menu bar; context sensitive

help can be summoned by F1; o The first menu is to be File and contains operations for handling files (new, open, save, save as) as well as quitting the program; the next menu Edit has commands for undo, redo, cut, copy, delete, paste commands; o The Cut command is ⇧ Shift+Del; Copy is Ctrl+Ins; Paste is ⇧ Shift+Ins; o The size of a window can be changed by dragging one of the 8 segments of the border. Egységes program-interfész (CPI): Növeli a felhasználói programok fejlesztési hatékonyságát (pl.: az egyes adatbáziskezelők által létrehozott állományok más adatbázis kezelőkkel, valamint programnyelvekkel való lekérdezését) A programok (programnyelvek, alkalmazásfejlesztők, adatbáziskezelők) közötti átjárhatóságot biztosító ele Egységes kommunikációs támogatás (CCS): Arra szolgál, hogy a különböző hardveregységek, programok és hálózatok közötti kapcsolatot az operációs rendszerben egységes módon valósítsák meg. Felhasználói

felület tervezésének elvei • • • • • • Felhasználói jártasság: Olyan kifejezéseket és fogalmakat kell használnia, amelyek megfelelnek a rendszert legtöbbet használó emberek tapasztalatainak. Nem szabad egy felületet csak azért ráerőltetni a felhasználókra, mert az kényelmesen implementálható. Konzisztencia: A felületnek a hasonló műveleteket hasonló módon kell realizálnia. o a rendszer parancsainak és menüinek ugyanazzal a formátummal kell rendelkezniük, o a paramétereket minden parancshoz ugyanúgy kell átadni, és o hasonlónak kell lennie a parancsok formájának. Minimális meglepetés: a rendszer soha ne okozzon meglepetést a felhasználóknak, ingerültté válnak, ha nem a várt módon viselkedik. Oka: a felhasználók felépítik magukban a rendszer működésének gondolati modelljét Az eltérő logikai részek gondot okoznak. Visszaállíthatóság: A felületnek rendelkeznie kell olyan mechanizmusokkal, amelyek lehetővé

teszik a hiba után történő visszaállítást. o Az ártalmas tevékenységek megerősítése: ha a felhasználók ártalmas tevékenységet hajtanak végre, megerősítést kell tőlük kérni. o Visszavonási lehetőség biztosítása: a visszavonás a rendszert visszaállítja a tevékenység bekövetkezése előtti állapotba. o Ellenőrző pontok készítése: célszerű a rendszer állapotát bizonyos időközönként elmenteni. Felhasználói útmutatás: o Hiba esetén értelmes visszacsatolás a felhasználónak o Beépített súgó rendszer Felhasználói sokféleség: Különböző felhasználóknak különböző interakciós lehetőségek biztosítása. o A rendszernek lehetnek alkalmi és rendszeres felhasználói. o Pl.: regisztrált tagoknak többletfunkciók biztosítása A felület tervezés folyamata A felhasználók együttműködnek a tervezőkkel. Prototípusokat készítenek a rendszer felületéről: Design tervek, skicc rajzok, stb Célszerű a felületek

tervezését iteratív úton fejleszteni. A prototípus külön is elkészíthető párhuzamosan más szoftvertervezési tevékenységekkel. Ez gyorsítja a rendszer kifejlesztését A folyamat három alapvető szakasza: • • • Felhasználók elemzése: Meg kell vizsgálni, hogy o a felhasználók milyen feladatokat végeznek, o milyen munkakörnyezetben dolgoznak, o milyen egyéb rendszereket használnak munkájuk során. Feladatelemzés: Legelterjedtebb módszer: Hierarchikus feladatelemzés (Hierarchical Task Analysis - HTA). Eredetileg a felhasználói kézikönyvek készítésének elősegítésére hozták létre, de használható annak meghatározására is, hogy mit kell a felhasználóknak tenniük egy bizonyos cél elérése érdekében. A HTA elemzés alapja: o A magas szintű feladatot részfeladatokra bontjuk. o Terveket készítünk, hogy megadjuk, hogy egy adott helyzetben mi történhet. o A felhasználó céljából kiindulva egy hierarchiát készítünk,

amely leírja, hogy mit kell tennünk a cél érdekében. Prototípus-készítés: célja, hogy egy elkészült példafelület segítségével a tervezők tapasztalatokat szerezzenek a működéssel kapcsolatban. A folyamatot két lépésben hajtjuk végre: o A folyamat elején papíralapú prototípusokat készítünk, és ezeket áttekintjük a végfelhasználókkal. o Finomítjuk a tervet: egyre kifinomultabb automatizált prototípusokat fejlesztünk, elkészítjük a számítógépes reprezentációját (rajzolás, concept art) és tesztelésre és a tevékenységek szimulálása érdekében odaadunk a felhasználóknak. Ablakok • • • Színek használata o Világos háttéren fekete szöveg o Kevés, jól elkülöníthető szín kell o Piros - vészhelyzet o Zöld - normál helyzet o Sárga - figyelmeztetés o A színen kívül más jelzés is kell Hanginformációk o Kikapcsolható legyen! o Puritán egyszólamú síp ma már nem divat o Beszédkommunikáció

lehetősége Címke és felirat szabályok o Minden vezérlőelemhez kell (kivéve Prompt) o Elhelyezés balra vagy felette o Ne használjuk adatmegjelenítésre! Legördülő lista/kombinált lista • • • - 22 - Típusok o Egyszerű listadoboz (egy kiválasztással) o Legördülő listadoboz o Kombinált lista o Szerkeszthető legördülő listadoboz o Szerkeszthető listadoboz Alternatív lehetıségek o Menügombos és külön gombos lista o Rádiógomb-csoport Speciális listadobozok o Többszörös kiválasztású listadoboz o Többszörös mód helyett a jelölőnégyzet lista o Előnézeti lista. Pl betűtípusok o Két konténeres lista o Egy konténeres lista, pl. egy listadoboz és nyomógombok dialógusablakkal Parancsgomb (Command Button) Felhasználási esetek • Normális nyomógomb • Menügomb (Menu Button) • Osztott gomb (Split Button) • Ellipszis gomb (három ponttal) • Nyíllal ellátott gombok (pl. 2 listadoboz között) Parancsgomb szabályok •

Méretezés o Tipikus magasság 23 pixel (14 DLU) o OK/Mégse gombok szélessége 75 pixel (50 DLU) o Max. kétféle szélesség lehet, kivéve gomb • Aktivizálás o Csak akkor disable, ha triviális, hogy miért. Kivéve OK és Mégse o Duplakattintás ne legyen értelmezett • Felirat szövegezése Szövegdoboz (Textbox) Adatmegjelenítési mező Beviteli mező (maszkolatlan és maszkos) Többsoros szövegbeviteli mező Görgős elemmel kiegészített beviteli mező Csak numerikus adatnál jó. • Jelszómező • Prompt mező (pl. Keresés a Vistában) Szövegdoboz szabályok • Nincs vízszintes görgő, függőleges is csak a többsorosnál • Maximális hosszát be kell állítani • A kapcsolódó címkével együtt lehet „disable” • Profi maszkolás kell (pl. rendszám) • Read-only mezőn nincs Tab Stop • • • • ListView Előnye a ListBox-szal szemben: • Többoszlopos, oda-vissza rendezhető, csereberélhető oszlopokkal • Képes egérvonszolást

(drag & drop) kezelni • Van jelölőnégyzetes verzió is • Adatmegjelenítő mező kell a kiválasztott elemek számával • Mindet kijelöli, összes kijelölés törlése gombok kellenek Típusai • Oszlopválasztó ListView • Paneles (többsoros) ListView pl. folyamatos űrlap MS Access-ben • Csoportosított ListView: Kétszintű TreeView helyettesítésére (pl. Sajátgép) ListView szabályok • Oszlopfejléc kattintható • Menügombnál a felirat mindig az aktuális nézet • A felhasználó által kialakított nézet elmentése • Duplakattintás: alapértelmezett művelet • Vízszintes görgőt ne használjunk, ha lehet. TreeView Hierarchikusan elrendezett objektumkollekció Ellenjavallatok • ListView a jobb, ha a gyökéren kívül csak 2 szintű • A ListView rendezhető, szűrhető, a TreeView nem • Négynél több szint esetén nehezen található egy konkrét objektum TreeView szabályok • Vízszintes görgőt itt is kerüljük! • Faágakhoz

legyen legördülő menü • Duplakattintásra alapértelmezett művelet • Nyitás/csukás (Expand/Collapse) o Hasonló funkciójú nyomógomboknál azonos szövegek o Grafika és szöveg keveredése kerülendő, kivéve, ha a grafika plusz információt ad a beazonosításhoz. o OK helyett specifikus címkefelirat lehet (pl. Írás) o A Mégse helyett viszont ne használjunk más feliratot! • Ha több gomb is van, a destruktív parancsok különüljenek el Hivatkozás szabályok (Hyperlink, Command link) • Lehetőleg ne használjunk grafikus hivatkozást • Ne legyen disable a hivatkozásra. Akkor már inkább sima szövegként jelenítsük meg • Látogatott/nem látogatott rendszerszín használata • Nyomtatásnál ne jelenjen meg az aláhúzójel − Szövegezés • Nincs pont a végén, de kérdőjel lehet • A szövegben ne legyen olyan, hogy „Kattintson.” • URL címnél ne szerepeljen a sallang (pl. //http) • A három pont (.) szerepe ugyanaz, mint a

parancsgombnál Jelölőnégyzet (Checkbox) Elhelyezés • Kétállapotú, max. 10 legyen egy csoportban • A harmadik állapotot (tömör fekete négyzet) ne használjuk beállításra • Ha ennél több kell, akkor CheckboxList. • Inkább függőlegesen, mint vízszintesen • Legyen elérési billentyű • Pozitív megfogalmazás legyen • Esetleges magyarázat a gomb alá írható Vezérlőelem magyarázat (Tooltip) Felhasználási esetek • Grafikus – címke nélküli – elemekhez (Tooltip) • Bármilyen elemhez (Infotip) • Teljes név Infotip (pl. TreeNode-on állva) • Bélyegkép (thumbnail) Infotip Szabályok • Nem gombnyomásra, hanem MouseOver-re aktivizálódik • Hiba- és figyelmeztetı üzenetre ballon kell • Tooltip-nél 5 mp az eltőnés, Infotip-nél nincs • Tooltip maximum 5 szóból áll • Tooltip-en nincs ikon, Infotip-en lehet, ha kell Értesítési ballon (Notification) Felhasználási esetek • Aszinkron művelet sikeres/sikertelen

befejezése • Csak akkor, ha nem erre számít a felhasználó • Nem kritikus rendszeresemény • Hálózati erőforrás sikertelen elérése, akku kimerülése • Felhasználói feladatra való felszólítás (pl. update) • Fontosnak tűnő információ Szabályok • Nincs köze a felhasználó aktuális tevékenységéhez • Hasznos, releváns, de nem kritikus • Nem igényel azonnali beavatkozást • Alapvetően nem szinkron, hanem aszinkron • Egy eseményhez csak egy üzenet szülessen • Progresszív eszkaláció. Pl akku kimerülésekor először csak az ikon lesz egyre pirosabb, majd ballon jön, végül modális dialógusablak • Interakció a bezárás vagy további részletek lehetnek Folyamatindikátor (Progress Bar) − Felhasználási esetek Fajtái • Modális, határozott idejű • Önállóan, vagy Mégse/Leállítás gombbal párosítva - 23 • • Nagymérető fánál előnyös, ha csak egy lehet nyitva Csukást csak akkor engedjünk, ha nem fér

el az összes faág Rádiógomb • • • • • 2 és 7 közötti lehet egy csoportban Logikai sorrendben, alapértelmezés lehetőleg az első Inkább függőlegesen, mint vízszintesen Alárendelt elemek o Jobbra mellé vagy behúzással alá o Ne ágyazzunk egymásba rádiógombcsoportot, ha lehet. o Az alárendelt elembe történő írás beteszi a pöttyöt aut. Szövegezés o Csoportszöveg címkeként él: végén kettőspont kell o Legyen elérési billentyű, pozitív megfogalmazás legyen. Kartonlap (Tabcontrol) Felhasználási esetek • Nagy, görgős ablak helyett (klasszikus eset) • Többféle nézet • Több külön dokumentum megjelenítése. pl Excel Kartonlap szabályok • Tilos az egyfülű, a görgős és a többsoros • A lapok valamilyen nyilvánvaló kapcsolatban vannak egymással • A lap nem görgethető semerre sem. • Az inaktív tab füleket eltávolítjuk, és nem disable. Ha ez valamiért nem megy, akkor az összes vezérlőt inaktívvá

tesszük, de a tab fül aktív marad • A tab fül címkéi főnevek. Nincs elérési billentyűjük Ballon Jellemzői • Nem a megakadályozás a cél, hanem a közlés • Nem veszi el az input fókuszt, nem is kell rajta állni • Előnye a rászögelt szöveggel szemben, hogy nem kell külön hely neki Felhasználási esetek • Adatbeviteli hiba (nem kritikus hiba) • Speciális helyzet (pl. begépeléskor CapsLock mód) • Felkiáltójel (figyelmeztetés) ikont társítunk hozzá Szabályok • Egyszerre csak egy ballon lehet a képernyőn • Azonnal megjelenés és eltűnés ha már OK • Az adott beviteli mező alá kell elhelyezni Vonal, téglalap (Groupbox) Díszítőelemek funkcionális jelentés nélkül • Alapelv, hogy a lehető legkevesebb legyen • Inkább vonal, mint téglalap • 1-es vastagságú, mart, halványszürke. Layout révén elrendezhető vonal nélkül is • A téglalap soha nem Disable • A benne lévő elemek persze lehetnek Menük Fajtái:

• Vízszintes főmenü (menu bar, menu category) • Lebomló menük (pull-down menus) • Kaszkád menü • Feltáruló menü (pop-up menü, short-cut menü) o Lebegő menü a jobb egérgombra − Tab menü o Tab lap alján MouseOver-re megjelenik egy lefelé mutató nyíl (pl. Media Player a Kiegészítő animáció lehetséges (pl. Másolás) Modális, határozott idejő dupla (pl. telepítés) Modális, határozatlan idejű pl. Windows Update keresi a lehetséges összetevőket • Nem modális, határozatlan idejű. Pl Keresés a Windows-ban, miközben a Windows Intéző elérhető marad Szabályok • Lehetőleg határozottat használjunk • Még akkor is, ha nem tudjuk pontosan belőni az időt. Csak gépi folyamatokra • Már 2 mp fölött célszerő a homokóra helyett • Hosszú folyamatoknál értesítési mechanizmus jobb. • Megismételhető folyamatoknál a slider jobb. Pl egy média lejátszása • Egyértelmő legyen, hogy megy vagy sem Hasznos részletek

• Hátralévő idő, összes/feldolgozott rekordok száma • A maradék idő fontosabb, mint az eltelt idő • Hosszabb folyamat végén esetleg hangjelzés • Ne legyen függőleges, csak vízszintes • Ne álljon 100%-on, ha még nincs kész • Visszafele sem mehet (kicsit sem), csak előre Elhelyezés • Nem modálisat a státuszsorba lehet tenni • Modálisat egy külön folyamat dialógusablakba Feliratok • Mégse, ha visszaállítható az eredeti állapot • Másolásnál hiba, hogy Mégse jelenik meg Leállítás helyett • Leállítás, ha már nem állítható vissza • Menet közben is lecserélhető a szöveg, ha úgy adódik • A felirat szövege főnévképzős három ponttal a végén • Dialógusablakos esetben az ablak címkéje ne egyezzen meg ezzel, hanem normálisan a program/művelet neve • • - 24 Vistában) Elvárások • A főmenüben 3-10 közötti menükategória legyen • 10-nél kevesebb menüpont a többi menüben • Ki-bekapcsoláshoz

pipa • Tömör fekete pont az összefüggő menüpontok közül az aktuálishoz • Három pont a dialógussal induló funkcióhoz (csak ha van adatbekérés, kivétel Névjegy) • Szeparátorsorok alkalmazása • Leszürkítés és nem eltüntetés • A menüszövegek igék legyenek (főnévképző nálunk) • Nem kell minden menüponthoz ikon • Minden menüponthoz legyen elérési billentyű • Dinamikus menükhöz sorszám legyen (pl. legutóbb használt fájlok) • Fontosabb menüpontokhoz legyen gyorsbillentyű Feltáruló menü kialakítási szabályok • A legutolsó tétel a Tulajdonságok • Előtte legyen egy szeparátorsor • Billentyűzeten Shift+F10-re jön fel • Ne legyenek gyorsbillentyűk benne. • A default menütétel vastagítva jelenik meg. • A feltáruló menü kihangsúlyozható, ha menügombot használunk. Így nem csak azok tudják használni, akik tudnak a jobb gombról. Toolbar (Eszközsor) • • • • • Preferáltabb, mint a menü,

mert egyéb elemek (pl. kombinált lista) is felrakhatók erre Panel egy csomó vezérlőelemmel Legyen vezérlőelem-magyarázat (tooltip), amin nincs címke Az eszközsor javasolt magassága 28 pixel A grafika így 16*16 pixel − Dokkolást biztosítani kell. Ablakok típusai Modális ablak: be kell zárni azt az ablakot, és csak azután lehet átvinni a fókuszt egy másik objektumra. Elsődleges ablak (application window) • • Elsődleges objektumok megjelenítésére Több részre (panel) osztható az alternatív nézetek miatt Másodlagos ablak (dialógus ablak) • • • • • • • • • • • • • • • • Másodlagos objektumokhoz Elsődleges objektumok kevésbé fontos attribútumaihoz (pl. lapmargók) Felhasználói instrukciók bevitelére Elhelyezés: o Középre helyezés jelentése: kicsit feljebb 45-55% o Az értesítési területről indított ablak jobbra alul jelenjen meg Címsor : o Parancs, alkalmazás neve, ahonnan ide jutottunk. Ne

legyen benne „dialógus”, „folyamat”, „hiba”, „figyelmeztetés” stb szó o Folyamat menetére utaló szöveg lehet (pl. 66% Kész) Főinstrukció: o Mit kell tennie a felhasználónak ebben az ablakban o Kihagyható, ha túl nyilvánvaló o Főnévképzős megfogalmazás – három ponttal Tartalom terület (kiegészítı információ) Parancs terület (jóváhagyó/elutasító gombokkal) Lábjegyzet terület (gyakorlatlan usereknek szöveg) Nincsenek rajta a Taszksoron Nincs min. és max gomb, csak bezáró gomb Nem görgőzhető, nincs menüje, nincs címsor ikon Ha a hozzátartozó elsődleges ablakot bezárjuk, akkor ez is bezárul. Dialógusablakból ne nagyon kreáljunk újabb dialógusablakot. Csak akkor legyen modális, ha nagyon kell 3*4 méretarányú legyen - gördítősáv nélkül - 25 - Feliratok • Figyelmeztető és hibaüzenetre ne OK, hanem Bezárás • Igazából ez nyugtázás, és a hiba nem lehet sohasem OK. • A generikus kifejezések nem

jók (pl. Mentés, Kiválasztás) Parancsgombok sorrendje • OK/Igen, Nem, Mégse, Alkalmaz (ha van ilyen) Dialógusablak típusok • Standard dialógusok • Az operációs rendszer által használt standard dialógusok. Pl Mentés, megnyitás, betűk • Tulajdonságablak • Nem modális, nem méretezhető ablak: tulajdonságokat állít be, míg a normál dialógusablak inkább egy adott parancs vagy feladat végrehajtására szolgál Ablakkezelés • • • • Single Document Interface (SDI): Ún. „főablakos” alkalmazás Multiple Document Interface (MDI) Sokkal inkább alkalmazásorientált, mint az SDI Minimalizált gyerekablak a képernyő alján Eseményvezérelt program, kapcsolat az operációs rendszerrel (Java). Lásd az. 5 tételt Az esemény egy objektum, amelynek osztálya az EventObject leszármazottja. Az eseményobjektum hordozza az eseménnyel kapcsolatos információkat. Az esemény mindig egy meghatározott forrásobjektumon keletkezik Az alacsony

szintű események (pl. billentyűesemény) az operációs rendszer szintjén keletkeznek Az OS az eseményeket egy ún eseménysorba helyezi el. Az adott alkalmazás innen veszi ki a saját eseményeit és továbbítja a komponenseinek (a forrásobjektumnak). A forrásobjektum az eseményét továbbítja az esemény figyelőinek! A magas szintű események a program szintjén keletkeznek és forrássa nem mindig komponens! Az eseményvezérelt programozás megvalósítása egy választott fejlesztő eszköznél (NetBeans) Lásd az. 5 tételt Első lépésben létre kell hoznunk azt a komponenst, amelyen az esemény keletkezni fog. Ezt könnyen elvégezhetjük a designer segítségével. Nevezzük el a gombot (Jelöljük ki a gombot, majd a jobb alsó sarokban lévı „Properties” ablakban változtassuk meg a „name” tulajdonságot). Szintén ebben az ablakban választjuk ki a kívánt eseményt, és egy belső eseménykezelő osztályt, amit egyből fel is főz a forrásobjektum

figyelıláncára. 11. Egy vizuális fejlesztő eszköz bemutatása: a fejlesztőkörnyezet elemei, szolgáltatásai, osztálymodell, komponensek, adatbáziskezelési lehetőségek, adatbázisok adatainak megjelenítése. Az eszköz dokumentáltságának ismertetése. Egy vizuális fejlesztő eszköz bemutatása (Visual Studio) . NET keretrendszer A Microsoft egy gyors alkalmazásfejlesztést (Rapid Application Development, RAD) lehetővé tevő eszközt készített Visual Studio.Net néven, amely egyesített fejlesztőkörnyezetet bocsát a programfejlesztők rendelkezésére. Platform független Segítségével a következő fő programozási nyelvekkel tudunk alkalmazásokat készíteni: • Visual C# • Visual J# • Visual Basic • Visual C++ Veépített byekvek – Külső forrásból elérhető nyelvek A .NET Framework eszköztára a szoftverfejlesztés szinte minden aspektusát (kliens- illetveszerveroldali megoldások, adatbázisok kezelése, játékfejlesztés stb.) lefedi

Common Language Infrastructure A .NET Framework alapját a CLI képezi Ez nem más mint azon szabályok halmaza, amelyek leírnak egy nyelvfüggetlen fejlesztői környezetet, a futtatókörnyezetet, típusrendszert stb. A NET Framework implementációját CLR-nek, Common Language Runtime-nak hívják. A CLI maga is négy fő részre oszlik: • Common Language Specification - CLS Azokat a szabályokat írja le, amelyeket a CLI kompatibilis nyelveknek be kell tartania. Érdekesség, hogy a legtöbb NET nyelv tartalmaz olyan elemeket, amelyek nem felelnek meg a CLS. • Common Type System - CTS • • - 26 - A típusokat, azok memóriabeli reprezentációját illetve egymással való interakcióját írja le. A NET minden nyelve ugyanazt a típusrendszert használja és ugyan az egyes típusok megnevezése nyelvfüggő, viszont mindig ugyanarról a típusról van szó. Common Language Runtime - CLR A programok betöltéséért és végrehajtásáért felel. Felelősséggel

tartozik pl a memóriamenedzsmentért, kivételkezelésért illetve a kódbiztonságért is. Common Intermediate Language - CIL Ún. köztes kód Minden CLI nyelvben megírt program erre a kódra fordítódik le (ellentétben a hagyományos nyelvek natív kódjától). Ezt a kódot a tényleges futtatáskor az ún jitter (Just in time compiler) fordítja le natív kódra, amelyet a processzor már tud kezelni. A CIL hasonlít a Java bytekódjára A CLI-t úgy tervezték, hogy bármilyen objektumorientált programozási nyelvet támogasson, megosztva egy közös objektum modellt és egy nagy, közös osztálykönyvtárat. A NET jelenleg több mint 40 programozási nyelvet támogat, melyek többsége ingyenes (a kereskedők fejlesztői környezeteket árulnak). Sok nyelvet jelentősen hangoltak, hogy illeszkedjen a .NET keretrendszerbe A gyártók ezt kihasználva gyakran egyéb nyelvi funkciókat is módosítottak. A telepítéshez Windows 2000, vagy ennél újabb operációs

rendszerre van szükség. A teljes telepítés kb 50 percig tart és fájlrendszertől függően 4-7 GB helyet igényel a merevlemezen. Így a bal oldali ablakban található fülek segítségével a következő lehetőségek érhetők el: • • • • • Solution Explorer: formok és osztályok Class View: osztályok, és metódusaik Property Window: a controlok és formok property listája ToolBox: a fejlesztéshez használható controlok Fontosabb billentyűkombinációk: o Fordítás: CTRL + SHIFT + B o Futtatás: CTRL + F5 o Futtatás debug mód: F5 o Kódszerkesztő: F7 o Form szerkesztő: SHIFT + F7 Program készítése A File | New menüpontot kiválasztva megadhatjuk a kiválasztott project helyét, nevét illetve típusát. Fontosabb project típusok: • Empty project: Egy üres project, melyben nekünk kell mindent megírni. • Console Application: Parancsorban (DOS ablak) futó alkamazás. • Windows Application: Windows ablakos alkalmazás. Kezdetben egy üres

formot kapunk • Class Library: Fordításkor egy könyvtár állományt kapunk „dll” kiterjesztéssel, amely önmagában nem futtatható, de a benne lévő osztályok más programokban felhasználhatók. • Windows Control Library: Mint az előző, csak itt már Windows formok és controlok is szerepelhetnek. • Windows Service: Memóriában maradó (rezidens) szerviz program, amely a gép bekapcsolásakor automatikusan elindul, kikapcsolásakor pedig leáll. A Project menü segítségével további elemek adhatók a projecthez: • Add Class: Új osztály • Add Windows Form: Új szerkeszthető form • Add Inherited Form: Egy már létező formból származó új form • Add User Control: Saját control • Add Inherited Control: Egy már létező controlból származó új control • Add Existing Item: Egy már létező elem A ClassView ablakban a megfelelő osztály nevére jobb gombbal kattintva további elemek vehetık fel. • Add Method: Új metódus hozzáadása •

Add Property: Új property hozzáadása • Add Field: Új változó hozzáadása • Add Indexer: Új indexer hozzáadása A Project | Add reference menüpont választásával az általunk, vagy mások által létrehozott Class Library, illetve Windows Control Library állományokat adhatunk a projecthez. Bármely controlra kattintva a Property ablakban a tulajdonságaikat, illetve a hozzá tartozó eseményeket szerkeszthetjük. Egy új Windows alkalmazás létrehozása Egy új Windows alkalmazás létrehozásához kattintsunk a File | New | Project fülre. Ekkor a New Project párbeszédablak jelenik meg, ahol kiválaszthatjuk, milyen projectet szeretnénk indítani A Project Types listából a Visual C# Projects mappát kell választanunk, a Templates részből pedig a Windows Application ikont. A VS.Net egy alapértelmezett nevet rendel a projecthez, amely a Name mezőben módosítható A Location mezőben adhatjuk meg, hogy melyik könyvtárban szeretnénk az új project

fájljait tárolni. Az OK gombra kattintva egy üres ablakot kapunk, melyhez a ToolBoxról vezérlőket adhatunk. Az elemkészletben elérhető elemek csoportokra oszlanak, de csak azok a kategóriák jelennek meg, amelyek a készítendő alkalmazásban használhatók. • • • - 27 - Data (Adat): Olyan osztályokat tartalmaz, amelyek segítségével adatbázisból származó információkat érhetünk el, és tárolhatunk. Windows Forms: Itt olyan vezérlőket találunk, amelyek az ablakokra helyezhetők. Pl: a címkék, gombok, szövegmezők Web Forms: Ebben a csoportban a webes vezérlőket találjuk, amelyek felhasználhatók az Internet Information Services (IIS) kiszolgálókhoz az interneten való futtatásra. Osztálymodell Az elkészített programunk osztálydiagramját is megtekinthetjük, hogy ha kiválasztjuk a „View Class Diagram” lehetőséget. Ekkor az alkalmazáshoz tartozó összes osztály modellje megjelenik. Adatbázis-kezelési lehetőségek,

adatbázisok adatainak megjelenítése Az ADO.NET azoknak az osztályoknak a gyűjteménye, amelyek az adatkezelést támogatják Ezen belül beszélhetünk az úgynevezett adatszolgáltató osztályokról, amelyek az adatbázis és a kliens program közötti adatforgalom megvalósításához nyújtanak segítséget, valamint az úgynevezett adattárolási osztályokról, amelyek az adatbázisból letöltött adatok tárolására, manipulálására adnak lehetőséget. Az adatszolgáltató osztályokat aszerint csoportosítjuk, hogy milyen típusú kommunikációt támogatnak adatbázis szerverrel. Az ADO.NET tulajdonképpen egy konzisztens elérési lehetőséget nyújt a különböző adatforrásokhoz, legyen az elérendő adathalmaz egy Microsoft SQL Server adatbázis, egy tetszőleges OLE DB csatolón keresztül elérhető adatbázis (például egy Oracle rendszer), vagy egy XML adatfolyam. A hangsúly azon van, hogy ezeket az adatforrásokat azonos interfészen (felületen)

keresztül érhessük el, vagyis ugyanazt a fizikai komponenscsomagot használhassuk a különböző adatokkal összefüggő műveletekben. Az ADO.NET komponensei segítségével tisztán elkülöníthető egymástól az adatokkal történő manipuláció és azok megjelenítése A komponensek ugyanis komplex objektumok, melyekkel elérhetjük a tetszőleges típusú adathalmazokat, elvégezhetjük az adatok módosítását, törlését, valamint visszakaphatjuk a lekérdezések eredményhalmazait. A kapott adathalmazokat ezt követően adatmegjelenítő objektumokkal tesszük láthatóvá. Az osztálykönyvtár talán leghasznosabb tagja a DataSet osztály, mely lehetővé teszi, hogy tetszőleges mennyiségű és típusú adathalmazt tároljunk, rendezzünk, vagy manipuláljunk a memóriában, majd írjunk vissza a fizikai adatforrásba. A .NET Framework hasznos újdonsága, hogy minden eddiginél jobban támogatja az XML formátumú adattárolást, és mozgatást Az

adatszolgáltató osztályokat aszerint csoportosítjuk, hogy milyen típusú kommunikációt támogatnak adatbázis szerverrel. A különböző csoportok osztályai más-más névtérben találhatóak, és az osztályok nevének előtagja (prefixe) is eltér. Ugyanakkor a különböző előtagú, de különben azonos nevű osztályok funkcionalitása megegyezik. • • • • SQL Server: SQL Server 7.0 –től OLE DB: ilyenek SQL Server 7.0 alatti verziói ODBC: ilyen például az Access Oracle OleDbConnection osztály A munka során alapvetően két metódus használata számottevő, melyek a következők: • Open: a metódussal kapcsolódhatunk a megadott adatforráshoz. • Close: lezárhatjuk a megnyitott kapcsolatot. A legördülő menüben kiválaszthatunk egy korábban már konfigurált kapcsolat, vagy a kattinthatunk a <New Connection> feliratú elemre is, hogy újat hozzunk létre. Itt segítségünkre van egy dialógusablak, melyben a kiválaszthatjuk, hogy milyen

adatforráshoz szeretnénk kapcsolódni, és annak kel megadnunk a paramétereit. Az OleDbConnection osztályt azonban példányosíthatjuk a komponens használata nélkül is. Ekkor nem használhatjuk a szerkesztőablakokat, de erre egyébként is csak addig van szükség, amíg meg nem tanuljuk a gyakran használt adatforrások eléréséhez szükséges ConnectionString érték elkészítésének manuális módját. A jellemző property-k, melyek adatai a jól megválasztott ConnectionString konstansban is megadhatók egyben, a következők: • • • • • ConnectionTimeout: Megadható egy egész szám formájában másodperces értékben, hogy mennyi időt várjon az objektum a kivétel generálás előtt akkor, amikor a kapcsolatot próbálja felépíteni, de az nem sikerül. Database: A kapcsolat felépítése után a művelet milyen adatbázisra fog vonatkozni, és az lesz az aktív. DataSource: Az adatforrás nevét tartalmazza, mely lehet a szerver neve, vagy az aktuális

állomány neve. Provider: A kapcsolat-szolgáltató neve. State: A kapcsolat állapotát tartalmazz egy konstansba. Értékei: Open, Closed, Connecting (éppen kapcsolódik), Executing (éppen parancsot futtat), Fetching (éppen adatokat kérdez le). OleDbDataadapter osztály Az objektum végzi el a megadott kapcsolat és az SQL utasítás felhasználásával a tulajdonképpeni adatbázis-műveletet. Az SQL utasítás lehet lekérdezés, vagy módosítás is. Lekérdezéskor az eredményhalmazt helyezi el valamilyen memóriabeli adatszerkezetben, mely példánkban egy DataTable objektum. - 28 - DataTable osztály Az osztály tartalmazza a lekérdezett adathalmazt a memóriában. Az adathalmaz szerkezete (oszlopainak szerkezete, típusa, rekordszám) megegyezik a kapott a fizikai adathalmaz jellemzőivel. Az eszköz dokumentáltsága A Help menüpontra kattintva különböző helyekről kaphatunk segítséget. A Visual Studio részletes súgóval rendelkezik. A

súgódokumentáció két részből áll Az MSDN Express Library telepítéskor kerül fel a számítógépre. Ebben többek között olvashatunk egy angol nyelvű, egy programozói kézikönyvet, illetve szerepel benne a nyelv teljes leírása (Reference). A dokumentáció online része a Microsoft webhelyén érhetı el (MSDN Online). Az online súgóban frissítéseket, aktuális információkat és további kiegészítéseket találunk. A súgót a szokásos módon, az F1 funkcióbillentyűvel vagy a Help/Contents parancs segítségével érhetjük el. 12. Relációs adatbázisok Funkcionális függőség fogalma, speciális függőségek szerepe Normálformák, a normalizálás célja. A normalizálás lépéseinek szemléltetése példán Az adatbázisterv dokumentációja. Reláció: A tulajdonsághalmazok Descartes-szorzatának részhalmaza. Mivel minden tulajdonság egy halmaz, azok Descartes-szorzatának egy részhalmaza valójában a táblázat. Mivel a matematikában az

ilyen szorzatok részhalmazát relációnak nevezik, a modell erről kapta a nevét. Függőségek Funkcionális függőség Adatok között akkor áll fenn funkcionális kapcsolat, ha egy vagy több adat konkrét értékéből más adatok egyértelműen következnek. Például a személyi szám és a név között funkcionális kapcsolat áll fenn, mivel minden embernek különböző személyi száma van. Ezt a SZEMÉLYI SZÁM  NÉV kifejezéssel jelöljük vagy pedig egy diagrammal. A funkcionális függőség bal oldalát a függőség meghatározójának nevezzük. A jobb oldalon levő egy, csak egy értéket határoz meg a funkcionális függőség. Nem áll fenn funkcionális függőség akkor, ha a meghatározó egy értékét több attribútum értékkel hozhatjuk kapcsolatba. Például a NÉV  SZÜLETÉSI ÉV állítás nem igaz, mert több személynek lehet azonos neve, akik különböző időpontokban születtek. A funkcionális függőség jobb oldalán több

attribútum is állhat. Pl az AUTÓ RENDSZÁM  TIPUS, TULAJDONOS funkcionális függőség azt fejezi ki, hogy az autó rendszámából következik a típusa és a tulajdonos neve, mivel minden autónak különböző a rendszáma, minden autónak egy tulajdonosa és típusa van. Az is előfordulhat, hogy két attribútum kölcsönösen függ egymástól. Ez a helyzet például a házastársak esetén FÉRJ SZEM SZÁMA  FELESÉG SZEM SZÁMA, FELESÉG SZEM SZÉMA  FÉRJ SZEM SZÁMA. Mindkét funkcionális kapcsolat igaz és ezt a FÉRJ SZEM SZÁMA <-> FELESÉG SZEM SZÁMA jelöléssel fejezzük ki. A funkcionális függőség bal oldalán több attribútum is megjelenhet, melyek együttesen határozzák meg a jobb oldalon szereplő attribútum értékét. Például hőmérsékletet mérünk különböző helyeken és időben úgy, hogy a helyszínek között azonosak is lehetnek Így a következő funkcionális függőség áll fenn az attribútumok között: HELY,

IDŐPONT  HŐMÉRSÉKLET. Teljes funkcionális függés Erről akkor beszélhetünk, ha a meghatározó oldalon nincsen felesleges attribútum. Például a RENDSZÁM, TÍPUS  SZÍN funkcionális függőség nem teljes funkcionális függőség, mivel a rendszám már egyértelműen meghatározza a kocsi színét, ehhez nincs szükség a típusra is. Amikor egy adatbázist normalizálunk, arra törekszünk, hogy minden táblában teljes funkcionális függések legyenek. A teljes funkcionális függésnek három feltétele van: • egy tábla minden nem kulcs mezője függjön a kulcstól, • összetett kulcs esetén, minden nem kulcs mező függjön a kulcs minden elemétől! • minden, nem kulcs mező csak a kulcstól függjön, Részleges funkcionális függés Részleges funkcionális függés a teljes funkcionális függés egyik akadálya. Akkor fordulhat elő egy táblában, ha abban van összetett kulcs és nem teljesül a teljes funkcionális függés alábbi

feltétele: "összetett kulcs esetén minden nem kulcs mező függjön a kulcs minden elemétől" A nem kulcs mezők egyik része a kulcs egyik elemétől, a mezők másik része a kulcs másik elemétől függ funkcionálisan. SZIG 11111111 NEV AB TELEFON +36111111 MIKOR 08:00-16:00 11111111 22222222 - 29 AB CD +36222222 +36111111 10:00-12:00 08:00-16:00 Tranzitív függés Tranzitív függés esetén minden, nem kulcs mező függ a kulcstól, de van olyan mező, esetleg mezők, amely a kulcson kívül más mezőtől is függnek. A teljes funkcionális függés egyik feltétele, hogy "minden nem kulcs mező csak a kulcstól függjön" Amennyiben ez a feltétel nem teljesül, tranzitív függésről beszélünk. Azt a mezőt, amelytől más mezők tranzitíven függnek, tranzitív kulcsnak hívjuk. SZIG 11111111 22222222 NEV AB CD IRSZ 3300 3300 VAROS Eger Eger Adatok közötti többértékű függőség Az adatok között fennálló kapcsolatok

közül nem mindegyike fejezhető ki a funkcionális függőség segítségével. Például minden embernek lehet több szakmája, illetve ugyanazzal a szakmával több ember is rendelkezhet. Ebben az esetben egyik irányban sincs egyértelmű függőség. Ez egy többértékű függőség, az egyik attributumhoz egy másik attributum csoportja, halmaza kapcsolódik. A többértékű függőség ábrázolására a dupla nyilat használjuk. SZEMÉLYI SZÁM ->> SZAKMA A funkcionális függőséghez hasonlóan, többértékű függőség esetén is előfordulhat, hogy egy attributum értékéből egynél több további attributum értéke következik. Az előző példát bővítve: SZEMÉLYI SZÁM ->> SZAKMA, OKLEVÉL KELTE Normálformák A relációs adatmodell szerint elkészült táblákat legalább harmadik normálformába kell alakítani. Ez általában elegendő ahhoz, hogy hibamentesen kezelhető adatbázisokat kapjunk. Relációk szétbontása Cél: • A redundancia

megszüntetése. • Csak teljes függőség legyen. Normálforma: az egyed szerkezeti állapota. A normálformák egymásra épülnek, azaz normálformában lenni annyit jelent, hogy már az (n-1). formában benne van R 0. normálforma (0NF) Nem elégíti ki a relációs adatmodell valamelyik feltételét. • • • • • A tábla oszlopainak (attribútumainak) neve van, és ezek a nevek egy táblán belül egyediek. Az oszlopok száma (a reláció foka) az adott táblában állandó. Az egyes oszlopok csak meghatározott értékeket vehetnek fel. Minden sor minden oszlopában egy és csakis egy elemi érték szerepelhet. A táblában minden sor különböző. R 1. normálforma (1NF) Kielégíti a relációs adatmodell valamennyi feltételét. Minden másodlagos tulajdonság funkcionálisan függ a kulcstól. R 2. normálforma (2NF) Nincs benne részleges funkcionális függőség. A táblát két új táblára bontjuk. Az egyik táblába az összetett kulcs egyik eleme kerül,

a tőle függő összes mezővel együtt A másik táblába a kulcs másik eleme kerül a tőle függő összes mezővel együtt. A két kapott táblában már nem lesz összetett kulcs, tehát nem lesz részleges funkcionális függés sem. Az új táblák azonosítói az eredeti összetett kulcs elemei lesznek A két tábla közötti NM kapcsolat úgy oldható meg, hogy a keletkezett két tábla között még egy harmadik, úgynevezett kapcsolótáblát is létrehozunk, amiben mindkét tábla azonosítóját elhelyezzük idegen kulcsként. Így a két tábla nem közvetlenül, hanem egy kapcsolótáblán keresztül kapcsolódik egymáshoz. R 3. normálforma (3NF) Nincs benne tranzitív függőség. Minden tranzitív függést tartalmazó táblából két táblát csinálunk. Új táblába kerülnek a tranzitív függésben lévő mezők, azzal a tranzitív kulcs mezővel együtt, amelytől a kulcson kívül függnek. Az új táblában a tranzitív kulcs mező lesz az azonosító 1:N

kapcsolat esetén az idegen kulcsot mindig a több oldalon lévő táblában helyezzük el. Boyce/Codd normál forma (BCNF) Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része. (A pédában egy tanár csak egy kurzust vezethet.) - 30 - hallgató, tanár  kurzus hallgató, kurzus  tanár HALLGATÓ HA HA HB KURZUS KA KB KB TANAR TA TB TB A tábla felbontása ebben az esetben többféle képpen is lehetséges. Például TANAR TA TB KURZUS KA KB TANAR TA TB TB HALLGATO HA HA HB R4. normálformájú (4NF típusú) Egy X->>Y többértékű függőséget tartalmazó relációban csak az X és Y-ban megtalálható attribútumokat tartalmazza. Mindeddig csak a funkcionális függőségeket vizsgáltuk, a többértékű függőségeket nem. A további két normál forma a többértékű függőségekből adódó redundancia kiszűrését szolgálja. SZEMELY SA SA SB SB BARAT BA BB CC CC SZEMELY SA SA SB

BARAT BA BB CC HOBBI HA HA HB HC SZEMELY SA SB SB HOBBI HA HB HC R5. normálformájú (5NF típusú) Hosszú ideig a negyedik normál formát tartották a normalizálás utolsó lépésének. A többértékű függőségek külön relációkban tárolásával azonban információt veszthetünk. A pédában ugyanazon a helyszínen egyfajta tanfolyam csak egyszer kerül megtartásra. TANAR TA TB TA TB TANF. FA FA FB FA TANAR TA TB TA TANF. FA FA FB HELYSZÍN HA HB HC HC TANF. FA FA FB FA HELYSZÍN HA HB HC HC TANAR TA TB TA TB HELYSZIN HA HB HC HC Az ötödik normál formának megfelelő felbontás eredményeképpen a tárolandó adatmennyiség megnövekszik, a reláció három táblára bontásával. Általában célszerűbb egy újabb oszlop bevezetésével csak két táblára bontani a relációt A reláció több részre bontásával tudjuk csak megszüntetni a redundanciát, de ez több tárolóhelyet igényelhet és információt veszthetünk. Alternatív megoldás:

mesterséges kulcsok bevezetése ID 1 2 3 4 TANF. FA FA FB FA HELYSZIN HA HB HC HC Az adatbázis-terv • • • • Rendszerismertetés, követelmények Pontosítások Az adatbázis Fogalmak TANAR TA TB TA TB ID 1 2 3 4 • • - 31 - Megszorítások Kapcsolatok A táblákat és az egyes oszlopokat megjegyzésekkel is elláthatjuk, így lehetővé téve, hogy az adatbázis öndokumentált legyen, és ne legyen szükséges külön dokumentációt vezetni. 13. SQL adatbázis, adattábla, index, nézet létrehozása és törlése Adattábla szerkezetének módosítása Kulcsok, külső kulcsok megadása, kapcsolatok beállítása. További megszorítások elhelyezése Az adatbázis létrehozása, törlése • • • • CREATE DATABASE adatbázisnév: Regisztrálásra kerül az új adatbázis és létrejön róla mindennemű bejegyzés a rendszerkatalógustáblákban. Az adatbázis minden eleme – legyen az adattábla, indextábla, nézet, tárolt eljárás stb –

ugyancsak táblákban kerül definiálásra. A rendszer-katalógustáblákban a táblák törzsadatai, minden tábla összes oszlopának leírása, a megszorítások, a nézetek definíciói, az indexek tagjainak eredete, az eljárás egész teste stb. rögzítésre kerülnek a pillanatnyi méretekkel, az utolsó tranzakció időpontjával. Ez alapján ellenőrzi a rendszer az adatbázis konzisztenciáját, és nem utolsó sorban a hozzáférési jogosultságokat. A létező adatbázist a használatba vételhez majd meg kell nyitni A tábla létrehozásánál a névadást követően azonnal a szerkezet megadása következik: a felsorolt oszlopoknak azonosítójuk, típusuk és hosszuk van. Egy adatbázison belül az egyfajta táblanevek különböznek. Az oszlopok maximális számát az aktuális adatbázis-kezelő szabja meg, az oszlopok típusa pedig a benne tárolható adat nagyságát korlátozza. Például: SZEMELY {kod, nev, nem, anya, apa} CREATE TABLE szemely (kod char(3), nev

char(12), nem logical, anya char(3), apa char(3)); DROP DATABASE adatbázisnév: Törli a lezárt adatbázist. Ekkor a rendszerkatalógusbeli bejegyzéseket ily módon frissíti START DATABASE adatbázisnév: Adatbázis megnyitása. Egyszerre csak egy leget aktív STOP DATABASE: Lezárja az aktív adatbázist. Adattábla módosítása • • • • ALTER TABLE table name ADD column name datatype: oszlop hozzáadása: ALTER TABLE table name ALTER COLUMN column name datatype: oszlop típusának módosítása ALTER TABLE table name DROP COLUMN column name: oszlop eldobása ALTER TABLE table name RENAME COLUMN old name TO new name: oszlop átnevezése Nézet-tábla létrehozása Virtuális vagy nézettábla: fizikailag nem jön létre, mégis táblaként kezelhető. A rendszer csak a definícióját őrzi a katalógustáblázatban A nézettáblát valódi táblából származtatjuk oly módon, hogy a kijelölt táblá(k)ra lekérdezést írunk. Valahányszor a nézettáblához

fordulunk, a rendszer az alaptáblát kérdezi le. Nézet lehet további nézet alaptáblája • • CREATE VIEW view name AS SELECT column name(s)FROM table name WHERE condition o ugyanúgy le lehet kérdezni, mintha adattábla lenne o adatismétlődés csökkentése miatt hasznos o az adatbiztonság megszervezésének legegyszerűbb módja o bizonyos felhasználók elől el kell rejteni egy tábla különböző részeit, de bonyolultabb esetben helyesebb ideiglenes fizikai táblát létrehozni DROP VIEW view name: A nézet-tábla törlése Index-tábla Az adatbázis-kezelőnek alaphelyzetben egy lekérdezés végrehajtásához a vizsgált tábla összes rekordját be kell töltenie és ki kell értékelnie a WHERE feltételek szempontjából (FULL SCAN módszer). Általában a FULL SCAN, azaz a tábla minden során végég lépegető módszer jár a létező legnagyobb erőforrásigénnyel, mind számítási kapacitás, mind pedig az adatmozgatás szempontjából. A keresés

nagyságrenddel gyorsítható, ha a vizsgált tábla rekordjai a WHERE feltételek szempontjából legalább részlegesen rendezettek (indexeltek). Ilyenkor már csak az index által leszűkített részhalmazon kell a teljes eltételrendszert kiértékelni Az indexek saját tárolóterületükön rendezetten helyezkednek el, bennük a kulcsértékek mellett azok a címek, ahol a kulcshoz tartozó teljes sor megtalálható. SQL-ben is azért hozunk létre indexeket az adattáblákhoz (nézettáblához nem lehet), hogy abban gyorsan tudjunk keresni. Az indexek létrehozásakor figyelemmel kell lenni arra, hogy az index fenntartása költségekkel is jár: tárolóterületet és adatmódosításkor extra karbantartási munkát igényel. Egy "agyonindexelt" tábla lehet, hogy jó teljesítményt nyújt SELECT műveletekre, de ennek ára van, mert az INSERT-UPDATE-DELETE műveletek viszont nagyon lelassulhatnak. Az SQL megengedi összetett kulcsok alkalmazását, sőt azt is, hogy

az egyes kulcsrészek növekvő vagy csökkenő sorrendben vegyesen forduljanak elő az indexben. Tetszőleges adattáblához többféle indexet definiálhatunk Egyedi az az index (UNIQUE), amiben bármely kulcsérték legfeljebb egyszer fordul elő. Minden index neve egyedi, max megengedett hossza általában 18 karakter. • • • - 32 - CREATE [UNIQUE] INDEX index name ON table name (column name [ASC/DESC], column name [ASC/DESC]) CREATE INDEX onsor ON tanulo (osztaly, nev) Ez a mechanizmus B-fa (B-Tree) típusú indexstruktúrát hoz létre a tábla rekordjai felett, a kulcsmezők alapján. Tipikusan nagy szelektivitású mezőkre szokásos indexet létrehozni. Ezen mezők sokféle értéket vehetnek fel, egy adott értékhez viszonylag kevés rekord tartozik. Egy ilyen mezőt tartalmazó lekérdezés eredményeképpen vagy szűk rekordhalmazt, vagy egyetlen konkrét rekordot szeretnénk válaszul. B-fa: A B-fák olyan kiegyensúlyozott keresőfák CREATE BITMAP INDEX X2

Hallgato ON Hallgato (nem, felvetel eve); Ez egy bittáblát hoz létre a tábla rekordjai felett. Minden rekordhoz pontosan egy sor tartozik a bittáblában, míg a bittáblának annyi oszlopa van, ahány lehetséget értéket felvehetnek a kulcsmezők. Tipikusan kicsi szelektivitású mezők esetén használjuk ezt az indextípust, ahol a mező viszonylag kevés különböző értéket vehet fel, és ahol egy adott értékhez sok mező tartozik. DROP INDEX index name; Kulcsok, külső kulcsok megadása, kapcsolatok beállítása Kulcsok fajtái: • Egyszerű kulcs: a kulcs egyetlen attribútumból áll. • Összetett kulcs: a kulcsot kettő vagy több oszlop kombinációja alkotja, előfordulhat az is, hogy az összes oszlop szerepel a kulcsban. • Minimális kulcs: ha összetett kulcs esetén bármely attribútumot elhagyjuk a kulcsból, és az így megmaradt oszlopok kombinációja már nem rendelkezik kulcs tulajdonsággal, akkor az összetett kulcsot minimálisnak nevezzük.

Az egyszerű kulcs mindig minimális. • Kulcsjelöltek: egy relációban több különböző oszlop vagy oszlopkombináció létezhet, amely eleget tesz a minimális kulcs definíciójának, ezeket a lehetséges kulcsokat kandidate kulcsoknak vagy kulcsjelölteknek nevezzük. • Elsődleges kulcs (primary key): az a kulcs, melyet kiválasztunk a kulcsjelöltek közül, és kulcsként használunk. A ki nem választott kulcsjelölteket alternatív kulcsnak nevezzük. Az elsődleges kulcsnak nem lehet NULL az értéke • Idegen kulcs (foreign key): olyan attribútum vagy attribútum halmaz egy adott relációban, amelyik egy másik relációban elsődleges kulcsként szerepel. CREATE TABLE táblanév ( attrib1 típus(n) . PRIMARY KEY (attrib1, ) ): elsődleges kulcs PRIMARY KEY kulcsszóval az elsődleges kulcsot vagy UNIQUE kulcsszóval egyedi kulcsot hozunk létre. Csak 1 elsődleges, de akár több egyedi kulcsa lehet a táblának! Ezek a kulcsok természetesen nem vehetnek fel

ismeretlen értéket (NOT NULL). Az idegen kulcs definiálása CREATE TABLE gyerek-tábla ( . FOREIGN KEY (attribútumok) REFERENCES (szülő-tábla) ) A hivatkozási épség fenntartása érdekében adjuk meg a külső kulcsokat. A külső kulcs szerkezetének azonosnak kell lennie azon elsődleges kulcséval, melyre hivatkozik (a kulcsot alkotó oszlopnevek egyezése nincs kikötve). Természetesen lehet több idegen kulcs is a táblában. Figyelem: ha az idegen kulcs nem kulcsszerepő, akkor nekünk kell eldönteni, hogy lehet-e ismeretlen az értéke (ha nem, akkor értékére vonatkozó megszorítást teszünk NOT NULL-al). A záradék azzal folytatható, hogy a hivatkozott sor törlése/módosítása esetén mi legyen itt a hivatkozó sorban a válaszlépés: • ismeretlen értékkel/alapértelmezett értékkel töltse fel • itt is törölje ki a hivatkozó sorokat • módosításkor pedig az újra változtassa meg őket • ne tegyen semmit. Egy idegen kulcsnak legfeljebb 1

ON DELETE és legfeljebb 1 ON UPDATE záradéka lehet. Megszorítások CREATE DOMAIN felhaszn típus neve AS adattípus CHECK (feltétel) Több adattáblának lehetnek azonos jellegű oszlopai. Ha ezen oszlopok valamely tulajdonságát változtatjuk, akkor ezt mindegyik érintett táblában külön el kell végezni. Ezzel szemben a CREATE DOMAIN utasítás lehetôvé teszi oszloptípusok egységes definícióit Az SQL alapvetô adattípusaihoz hasonlóan hivatkozhatunk az így származtatott oszloptípusokra is. Az érintett adattáblák szerkezetének definiálásakor, ill. módosításakor az oszlopdefiníciók egységessége így már biztosított Ilyen esetben a DOMAIN módosítása automatikusan minden rá hivatkozó típusban átvezetésre kerül. Önálló megszorítások Az attribútumra és a sorra vonatkozó megszorításokat a rendszer csak akkor ellenőrzi, ha az attribútum vagy reláció, melyre a feltétel vonatkozik, beszúrás vagy módosítás hatására változik

meg. Ezért, hogy a több sort/több táblát érintő feltétel minden esetben igaz maradjon, önálló megszorításként adjuk meg. CREATE ASSERTION megszorítás neve CHECK (feltétel) Ezek az önálló feltételek elkülönülnek a táblák definíciótól, és egy vagy több tábla összefüggéseit szabályozzák. E feltételeket a rendszer mindannyiszor megvizsgálja, valahányszor beszúrás/módosítás/törlés történik az érintett táblák bármelyikében. - 33 - Triggerek Tárolt eljárások, az adatbázisban elvégzendő feladatokat automatikusan hajtják végre. Egy feltétel bekövetkezésétıl függően indítódik a trigger. A trigger tehát alkalmas adathibák, hivatkozási referenciák megsértésének kiszűrésére. A megszorítások megsértésének megakadályozásán túl más célok is megvalósíthatók: adott feltételtől függően végrehajtódjanak a benne levő adatbázisműveletek. • csak bizonyos esemény bekövetkezésekor hajtódik végre

• egy táblára vonatkozhat • a kiváltó esemény: beszúrás/törlés/módosítás/egy tranzakció vége/adott dátum elérése, stb CREATE TRIGGER • A műveletet végrehajthatjuk a kiváltó esemény előtt, után vagy helyette. • Módosítás esetén megadhatjuk, mely oszlopra vonatkozik az esemény. • A művelet hivatkozhat a kiváltó esemény által törölt, beszúrt vagy módosított sorok régi és/vagy új értékeire. • Megadhatunk egy feltételt, és a műveletet csak akkor hajtja végre a rendszer, ha a kiváltó esemény bekövetkezésekor a feltétel igaz . • Megadható, hogy a művelet végrehajtása o sorszintű (minden sorra) vagy utasításszintű (egyszer) legyen o egy utasításszintű trigger egyszer kerül végrehajtásra minden olyan utasításra, amelyik egy vagy több kiváltó eseményt generál. Ilyenkor nem hivatkozhatunk közvetlenül a régi és az új sorokra, mint a sorszintű esetén (OLD, NEW), hanem a régi sorok halmazára és az új

sorok halmazára hivatkozhatunk (OLD TABLE, NEW TABLE) 14. SQL adattábla sorainak felvitele, módosítása, törlése Lekérdezés adatbázisból, a lekérdező parancs összeállítása, végrehajtása. Belső lekérdezés lehetősége, a nyelv kifejezései Jogok kiosztása és visszavételezése. SQL adattábla sorainak felvitele, módosítása, törlése INSERT INTO táblanév [ (oszlopnév-lista) ] VALUES (értéklista); INSERT INTO táblanév [oszloplista] SELECT * FROM régitábla; UPDATE táblanév SET oszlop1=újérték1 [WHERE feltétel]; DELETE FROM táblanév [WHERE feltétel]; Lekérdezés adatbázisból A lekérdezés hatására egy ún. eredménytábla (E-tábla) jön létre, melynek egy vagy több oszlopa és egy vagy több sora lehet A SELECT parancs hatására az E-tábla a végrehajtás során több munkaterületen át lépésenként alakul ki. Táblákat legtöbbször kapcsoló oszlopok alapján kötünk össze (kulcs és külső kulcs legyen egyenlő). A DISTINCT

hatása: az E-tábla a duplikált sorokat csak egyszer tartalmazza. A parancs összeállításának kötött sorrendje van, ami nem egyezik meg a végrehajtás sorrendjével! A parancs egy vagy több táblára vonatkozó művelet(ek)et rejt és az eredményt is táblában válaszolja meg. SELECT. FROM. oszlopok kiválasztása = projekció tábla-nevek megadása = Descartes-szorzat [WHERE. ] sorok kiválasztása = szelekció [GROUP BY. csoportosítás [HAVING. ] ] csoportok közötti választás [ORDER BY. ] [SAVE TO TEMP. ] E-tábla rendezése E-tábla megőrzése E-táblák összefűzése Amennyiben két összeillő E-táblát kívánunk halmazelméleti alapon egyesíteni, akkor az UNION-val tehetjük meg. (Select. UNION Select) Ugyanilyen módon bizonyos ABKR-ek megengedik a metszet és különbség műveletét is A GROUP BY alparancs Az oszlopok értékei alapján csoportokat képez (egy csoportba az azonos értékűek tartoznak). A csoportra rendszerint

aggregálást alkalmazunk (a SELECT mögött valamelyik aggregáló függvény is szerepel). Használhatóak az „AVG(), a COUNT(), és a SUM(), valamint a MIN(), és a MAX()” függvények. Az aggregálás feltétele a csoportok rendezett sorrendje. Tehát végrehajtáskor 2 munkaterület segítségével történik meg a csoportosítás: először rendezés történik, majd az egymás alatti egyforma csoportértékekre elvégzi az aggregálást, hogy minden csoportból egy maradjon. Használjuk ki, hogy ezért a végső sorrend a csoportok szerint növekvő • • • a csoportosítást tartalmazó lekérdezésben a SELECT mögött általában csoportosító oszlopok és aggregáló függvények vannak, de nincs akadálya annak, hogy ezek közül valamelyik hiányozzon a SELECT mögött csak a GROUP BY mögötti oszlopok jelenhetnek meg az aggregáló függvény mellett nem lehet származtatott oszlopnév a GROUP BY argumentuma • - 34 - amennyiben az aggregálás

fokozatos, a GROUP BY mögötti sorrenddel kell pontosítani, melyik csoporton belül melyikre történjen meg az aggregálás. Egy főre eső jövedelem osztályonként: SELECT osztaly, AVG(jovedelem) FROM tanulo GROUP BY osztály A HAVING alparancs A GROUP BY csoportjaiból csak azok a sorok kerülnek az E-táblába, amelyek eleget tesznek a feltételnek. Itt már csak a csoportosítás eredményében részt vevő oszlopokra (ami a WHEREben még korai) fogalmazhatunk meg feltételt. Az osztályok létszámok közül csak a 3-nál nagyobbak jelennek meg. SELECT osztaly, COUNT(*) FROM tanulo GROUP BY osztály HAVING count() > 3 Az ORDER BY alparancs • • • Az oszlopnévnek szerepelnie kell a SELECT-ben. ASC növekvő (alapértelmezés), DESC csökkenı rendezettség. A JOIN alparancs FROM első tábla join típus második tábla [ON (join feltétel)] SELECT a.a, ba, ab FROM a INNER JOIN b ON aid = bid; A JOIN segítségével egyszerre több táblából tudunk adatokat

lekérdezni a táblák logikai relációi szerint. A JOIN feltétel definiálja a kapcsolatot két tábla között egy lekérdezésben, mégpedig úgy, hogy adatmezőket kapcsol egymáshoz, amivel meghatároz egy távoli kulcsot az egyik táblában, ami pedig azonosít egy kulcsot a másik táblában. A mezők értékének összehasonlításához logikai operátorokat használunk (=, <> és hasonlók). A join-ban használatos mezők alkalmazása során nem szükséges ugyanazzal a névvel, és ugyanolyan adattípussal végrehajtani a kapcsolódást, azonban ha az adattípus nem azonos, akkor kompatibilisnek kell lennie, vagy olyan típust kell használni, amit az SQL szerver egyértelműen konvertálni tud. A join kategorizálása • INNER JOIN: Ez a tipikusan legtöbbet használt kapcsolat. Összehasonlító operátor segítségével két tábla sorait felelteti meg egymásnak közös oszlopokat felhasználva mindkét táblából. • OUTER JOIN: Ez többféle is lehet,

méghozzá right, left, vagy full outer join. o LEFT JOIN vagy LEFT OUTER JOIN: Tartalmazza a baloldali tábla minden sorát, nem csak azokat, ahol a kapcsolt oszlopok megegyeznek. Amikor egy sor a baloldali táblában nem illeszthető a jobboldali tábla egyik sorához sem, akkor az eredményhalmazban a jobboldali táblából származó oszlopok tartalma NULL értékű lesz. o RIGHT JOIN vagy RIGHT OUTER JOIN A right outer join a left join ellentéte. A jobboldali tábla minden sorát visszakapjuk, és NULL értéket kapunk a baloldali táblából, valahányszor a jobb oldali tábla sora nem illeszthető a baloldali táblához. o FULL JOIN vagy FULL OUTER JOIN: A full outer join esetében minden sort visszakapunk egyaránt a baloldali és a jobboldali táblából is. Amikor egy sor nem illeszthető a másik táblához, akkor a másik táblából származó elemek NULL értékűek lesznek. • CROSS JOIN: A cross join esetén a baloldali tábla minden sorához az SQL megfelelteti a

jobboldali tábla minden sorát. Tulajdonképpen Descartes-szorzatát kapjuk a tábláknak. Belső (beágyazott) lekérdezés lehetősége A WHERE és a HAVING feltételében SELECT parancs is szerepelhet, amit belső vagy beágyazott lekérdezésnek nevezünk de nem tartalmazhat ORDER BY, SAVE TO TEMP alparancsokat. A belső SELECT is tartalmazhat belső SELECT-et, vagyis a SELECT-ek egymásba ágyazhatók. A belső (vagy al-) SELECT-et mindig zárójelpárban kell megadni Sorrend: • először a belső, majd a külső lekérdezés hajtódik végre • a belső lekérdezés eredménye a főlekérdezés minden sorában részt vesz a kiértékelésben Pl.: Az a tanuló, aki a legnagyobb összegű segélyt kapta: SELECT azon FROM segely WHERE osszeg = (SELECT MAX(osszeg) FROM segely); Több értéket tartalmazó belső E-tábla: Ilyenkor használni kell az IN, ANY, ALL vagy EXISTS predikátumok valamelyikét A predikátumok megadásának formátuma: predikátum (belső SELECT) • •

• • • IN: Igaz értéket ad vissza, ha az egyenlőség valamelyik belső E-táblabeli értékre igaz. ANY: Igaz, ha a megadott összehasonlítás valamelyik belső E-táblabeli értékre igaz. ALL: Igaz értéket ad vissza, ha a megadott összehasonlítás valamennyi belső Etáblabeli értékre igaz. EXISTS: Kiválasztja azokat a sorokat, amelyekhez a belső E-táblában egy vagy több sor tartozik. Ezt mindig egy újabb beágyazott lekérdezés következik. NOT EXISTS: Kiválasztja azokat a sorokat, amelyekhez a belső E-táblában nem tartozik sor. Az ANY és ALL használható a WHERE részben fix listákkal is, például x > ALL (12,21,8), x nagyobb, mint a lista legnagyobb eleme. - 35 - Halmazműveletek relációk között • • • UNION - Unió: SELECT. UNION SELECT [UNION SELECT] Veszi az egymásután következő E-táblák unióját (elvégzi a halmazokra vonatkozó egyesítés műveletet). Mivel a halmaz elemeit is egyszer soroljuk fel, azok a sorok,

amelyek közösek, csak egyszer jelennek meg. Ennek érdekében viszont az értékek rendezve kerülnek az E-táblába Metszet: Intersect Különbség: MINUS Jogok kiosztása és visszavételezése Az SQL kiköti a felhasználói nevek létezését, amiket fel lehet ruházni különféle jogokkal. A megfelelő rendszertábla tartalmazza a jogosult felhasználói neveket, és egy rejtett tábla a jelszavakat. Ilyen jogok az adattáblákra vagy nézettáblákra vonatkozó lekérdezés és szerkezeti módosítás, a 3 karbantartó utasítás (felvitel, módosítás, törlés), illetve valamely táblára való hivatkozás megszorító feltételekben, vagy az indexelés. Az SQL rendszerekben minden objektumnak, vagyis adatbázis elemnek van egy tulajdonosa, ez pedig, az a felhasználó, aki létrehozta. A jogosultságok megadása a GRANT utasítással történik, melyben meg kell adni, hogy mely táblára, mely műveletre, és kinek engedélyezzük. Az egyes felhasználóknak kétféle

jogot adhatunk: • Adatbázisra vonatkozót: GRANT adatbázisjog TO PUBLIC felhasználói nevek listája; • Adatbáziselemekre vonatkozót: GRANT műveleti jog ON adatbáziselem neve TO PUBLIC felhasználói nevek listája WITH GRANT OPTION; A parancssorokban szereplő PUBLIC kulcsszó használata következtében valamennyi felhasználó kap jogot, egyéb esetben csak az utasításban felsorolt felhasználók, vagy felhasználói csoportok. A WITH GRANT OPTION záradék lehetővé teszi, hogy a felhasználó, a kapott jogait más felhasználóknak továbbadhassa. Tehát ezek után bárki megszerezheti a jogokat Az adatbázisra vonatkozó jogok a következők: • CONNECT: kapcsolódás az adatbázishoz és a négy adatkezelési művelet (adatbevitel, módosítás, törlés, lekérdezés) használatának engedélyezése • RESOURCE: adatbáziselemek létrehozásának, és megszűntetésének joga, továbbá az adatbázis kezelési joga • DBA: az adatbázissal kapcsolatos

bármilyen művelet elvégzésére vonatkozó jog, beleértve ebbe az adatbázis megszűntetését is. Az adatbáziselemekre vonatkozó műveleti jogok a következők: • • • • • • • • ALL: az összes az alábbiakban felsorolt jog ALTER: táblák illetve nézettáblák megváltoztatási joga DELETE: sorok törlésére vonatkozó jog INDEX: táblázat indexelésének, illetve az index megszűntetésnek joga INSERT: új sorok bevitelére vonatkozó jog SELECT oszlopnév-lista: a felsorolt oszlopok, vagy azok hiányában a tábla valamennyi oszlopára vonatkozó lekérdezési jog UPDATE oszlopnév-lista: a felsorolt oszlopok, vagy azok hiányában a tábla valamennyi oszlopára vonatkozó módosítási jog REFERENCES oszlopnév-lista: a felsorolt oszlopokra, vagy azok hiányában a tábla valamennyi oszlopára vonatkozó hivatkozási jog Az adatbázisra, vagy annak elemeire vonatkozó jogoknak mindig összhangban kell lenniük, de mindig az adatbáziselemre vonatkozó

jogok az erősebbek. Erre talán az egyik legjobb példa az, hogy hiába van CONNECT jogunk egy adatbázishoz, ha az elemre vonatkozóan nincs UPDATE jogunk, hiszen az adatbáziselemet ebben az esetben nem tudjuk módosítani. A kiadott jogosultságok kiadására a REVOKE utasítás szolgál, melyben hasonlóan a GRANT utasításhoz, meg kell adni a táblát, a felhasználót, és a visszavont műveletet. Az adatbázisjog visszavonása a következőképp törtéhet: 15. Modellező nyelvek és eszközök szerepe az alkalmazások tervezésében és dokumentálásában UML diagramok: használati eset diagram, objektumdiagram, kommunikációs diagram, állapot diagram, osztálydiagram és osztályleírás, komponens diagram. Lásd a 2. tételt Az objektumorientált programozásnak sokáig nem volt egységes modellező felülete, azaz nem volt olyan eszköz, amely objektumorientált programok tervezését nyelvtől függetlenül meg tudta volna adni. Az UML egy szabványos, egységesített

grafikus modellező nyelv, amelynek segítségével fejlesztési modellek rendkívül jól szemléltethetőek. Az elvégzendő feladatok pontos meghatározása (a specifikáció), a tervezés, a dokumentálás mind grafikus formában, beszédes ábrák, diagramok segítségével történik. Segítségével tervezni és dokumentálni tudjuk a szoftvereket. Az UML-ben modellek és diagramok adhatók meg, különböző nézetekben. Az UML csak egy jelölésrendszer, amely független a szoftverfejlesztési módszertől. Az UML nem írja elő, hogy az egyes modelleket, illetve diagramokat mily módon és milyen sorrendben állítjuk elő. Az UML a jelöléseknek gazdag választékát kínálja, mely segítségével a szoftverfejleszté s összes fázisa modellezhető. Az UML a kiterjesztési mechanizmusok (pl. sztereotípusok) segítségével egyéni jelölések s azok szemantikájának bevezetését is támogatja - 36 - Jelölések • Függőségi kapcsolat: Szaggatott nyíllal

jelöljük, ahol a nyíl iránya jelzi a függőség irányát. A mutatott dolog függ a mutató dologtól. A függőség lehet kétirányú is A nyíl tartalmazhat címkét, amely leírja a függősé gtípusát • Társítás: Az elemek közötti közötti srukturális kapcsolat. Az UML-ben a tásítási kapcsolatot folytonos nyíllal jelöljük, ahol a nyíl iránya jelzi a kapcsolat irányát. Ha a nyíl hegyét nem tesszü k ki, akkor a kapcsolat kétirányú • A társítási kapcsolat fajtái: o Ismeretség o Tartalmazás: ez lehet gyenge és erős. A tartalmazási kapcsolatot a nyíl elején egy tömör (erős tartalmazás) vagy üres (gyenge tartalmazás) rombusz jelzi. Általánosítás (generalization): Más elnevezések: specializáció, öröklés. Osztályszerű elemek közötti strukturális kapcsolat. Általánosítási kapcsolat lehet például osztályok, aktorok, vagy használati esetek között. Az UML-ben az általánosítási kapcsolatot folytonos, telt

végű nyíllal jelöljük, ahol a nyíl iránya jelzi az általánosítás irányát. • Megvalósítás A megvaló sítási kapcsolatban egy dolog megvalósít (realizálja, implementálja) egy másik dolgot. Logikai kapcsolat, mely az általánosítás és függőség egy keveréke. A kapcsolat csak osztályszerű elemek között lehetséges. Megvalósítási kapcsolat a következő dolgok között lehet például: osztály és komponens (a komponens megvaló sítja az osztályt), folyamat és használati eset (a használati eset megvalósítja a folyamatot). Az UML-ben a megvaló sítási kapcsolatot szaggatott telt végű (öröklési) nyíllal jelöljü k, ahol a nyíl iránya jelzi a megvalósítás (függőség) irányát. Használati eset diagram A használati eset (HE) diagram a rendszer viselkedésének egy kiragadott részét írja le külső aktorok szemszögéből. A HE diagram elemei: aktorok, használati esetek, valamint az ezek közötti kapcsolatok. Egy aktor

üzeneteken keresztül kommunikál a rendszerrel. Az aktor üzenetet küld a rendszernek, a rendszer pedig a használati eset végrehajtása közben üzeneteket küldhet vissza az aktor számára. Az aktor üzeneteinek és a rendszer válaszainak megadásával a rendszer határait húzzuk meg. A használati eset a szoftver használatának egy értelmes egysége, az aktor kommunikációja, párbeszéde a szoftverrel. Felhasználói célnak nevezzük a felhasználónak azt a célját, melyet a szoftver használatával szeretne elérni. A felhasználói célok használati esetekre bontandók: a cél elérése, illetve a feladat megoldása érdekében a felhasználó konkrét használati eseteket hajt végre. A HE modell elemei: HE diagramok és leírások. A HE diagramhoz tartozik egy HE dokumentáció, melyben minden egyes használati esetről meg kell adnunk a HE szöveges leírását, a HE aktorait, valamint szükség szerint a jellemző forgatókönyvek leírásait és szekvencia

diagramjait. A kapcsolat jele egy vonal a két elem között. Egyes UML szerkesztők nyilat használnak, ami lehetővé teszi, hogy hangsúlyozzuk, hogy az aktor kezdeményező (ekkor a nyíl a használati eset felé mutat) vagy információt fogadó (a nyíl az aktor felé mutat) viszonyban van a használati esettel. - 37 - Objektumdiagram Megadja a rendszer objektumait, és az azok közötti kapcsolatokat. Az osztálydiagram egy pillanatfelvétele. Az objektum-osztályok hordozzák a hozzá tartozó objektumok jellemzőit. Minden objektum valamilyen osztály példánya, rendelkezik osztályának sajátosságaival, örökli annak tulajdonságait az adatszerkezetre és a műveletekre vonatkoztatva egyaránt. Állapot-átmenet diagram Az állapot-átmeneti diagram egyetlen osztály (annak egy elő fordulásának) dinamikus viselkedését, a külvilággal való kapcsolatát ábrázolja. Az állapot-átmeneti diagram egy gráf, melynek csomó pontjai állapotok, élei pedig

átmenetek. Megadja, hogy az objektum mely események hatására milyen állapotból milyen állapotba kerül. Az állapot-átmenet diagram az időbeli változásokat szemlélteti. Mégsem esett szó a közben eltelt időről Az átmenet egy időpillanat alatt megy végbe, tehát nincs időtartama. Az átmenetek mindemellett félbeszakíthatatlanok, tehát atomi egységet képeznek. Az állapot viszont egy időtartamot is jelöl, amelyben az objektum nem változik. Az objektumnak van - pontosan egy kezdeti állapota, melybe az objektum születésekor kerül. Jele egy tömör kör Valahány végállapota ahonnan további állapotváltozás nem lehetséges. Jele egy ökörszem Az állapot jele az UML-ben egy lekerekített téglalap Az átmenet a kiváltó esemény hatására következik be. Az esemény egyaránt jöhet kívülről vagy belülről Osztálydiagram Olyan diagram, amely az osztályokat és a közöttük lévő társítási és öröklési kapcsolatokat ábrázolja. Az

objektumdiagram az osztálydiagram elő fordulása, példánya. Az osztálydiagram rögzíti az objektumok közötti kapcsolatok szabályait. Két osztály közötti társítási kapcsolat főbb jellemzői: ismeretségi vagy tartalmazási kapcsolat (ha tartalmazási kapcsolat, akkor erős vagy gyenge); multiplicitás (egy-egy, egy-sok vagy sok-sok jellegű; kötelező vagy opcionális); szerepnév; megszorítás. Kommunikációs diagram Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. - 38 - Komponens diagram A komponensdiagram a rendszert alkotó fizikai komponenseket (szoftverelemeket) és az azok közti kapcsolatokat ábrázolja. A komponensdiagramon megadható a logikai nézet osztályainak forráskomponensekhez való hozza rendelése, valamint a forráskódok hozza rendelése futtatható komponensekhez. A komponensdiagram az implementációs nézet jellemző diagramja A komponens egy fizikailag bonthatatlan szoftver egység. A

komponens lehet egy állomány, például forráskód, szerkesztendő vagy futtatható szoftver elem: lefordított tárgykód, bájtkód, futtatható program vagy dinamikus könyvtár (DLL). A komponensdiagramot a következő dolgok modellezésére használják leggyakrabban: • • • Forráskódok Futtatható szoftverelemek (exe, jar.) Fizikai adatbázisok 16. A kliensoldali programozás alapelemei az Internetes alkalmazások fejlesztésénél A kapcsolódó technológiák rövid bemutatása: HTML, XHTML, XML, CSS, XSL. A kliensoldali script nyelvek használata. HTML A HTML (HyperText Markup Language=hiperszöveges jelölőnyelv) egy leíró nyelv, melyet weboldalak készítéséhez fejlesztettek ki, és mára már internetes szabvánnyá vált a W3C (World Wide Web Consortium) támogatásával. A HTML története • • • • • • HTML 0: dokumentum tartalmára vonatkozó címkéket, valamint hiperhivatkozásokhoz, címsorokhoz, bekezdésekhez, listákhoz és

menütételekhez használható jelölési definíciókat foglalt magában. HTML 1: sorokba illeszthető képek támogatásával, karakterformázó képességek. HTML 2: form-ok (űrlapok) létrehozásának lehetősége. HTML 3: tovább bővítették az ábrák, táblázatok és vezérlőelemek képességeinek kiszélesítésével ill. az appletek, scriptek és színek támogatásával. HTML 4: stíluslapok, scripting, frame-ek, objektumok beágyazása, továbbfejlesztett táblázatok, űrlapok, fogyatékos felhasználók számára elérhetőséget. HTML 5: bevezet jó néhány új elemet (címkét) és tulajdonságot, amelyek a modern weblapokon jellemzően alkalmazott szerkezetekre kínálnak új megoldást. Néhány változtatás szemantikai jellegű, például a div elemek helyett header, nav, section, article, aside és footer jelenik meg. Néhány a HTML 4.01-ben már érvénytelenített elem az új szabványba már nem került be Ilyenek a mai weblapokon még gyakran jelenlévő

<font> és <center> elemek, amelyek hatását most már végleg CSS kóddal kell megvalósítani. Újra hangsúlyt helyeztek a DOM szkriptek (gyakorlatilag a JavaScript) jelentőségére a weboldalak viselkedésével kapcsolatban. Számos új űrlap-elem kerül bevezetésre, ezek használatával egyszerűbben (Javascript alkalmazása nélkül) készíthetők majd online kérdőívek és formok. Az egyik legfontosabb újítás, hogy a video és audio tagek segítségével flash és egyéb beépülő kiegészítők nélkül is megjeleníthetőek lesznek a különböző multimédiás tartalmak. Szintén jelentős fejlődés, hogy a canvas tag használatával lehetővé válik, hogy egyszerűbb ábrákat anélkül jelenítsünk meg, hogy azokat képként be kellene ágyaznunk. Drag-and-drop jellegű funkciók beépítése is egyszerűbbé válik, nem szükséges sem javascript, sem flash alkalmazása. A HTTP egy információátviteli protokoll a világhálón. Az eredeti

célja a HTML lapok publikálása és fogadása volt A HTTP egy kérés-válasz alapú protokoll kliensek és szerverek között. A kommunikációt mindig a kliens kezdeményezi A HTTP klienseket gyűjtőnéven user agentnek is nevezik. A user agent jellemzően, de nem feltétlenül webböngésző A HTTP általában a TCP/IP réteg felett helyezkedik el, de nem függ tőle. - 39 - A HTML állomány egyszerű szövegállomány, amely rövid jelölő tagokat tartalmaz. A jelölő tagok alapján tudja a böngésző, hogyan kell megjelenítenie az oldalt. A HTML állomány html kiterjesztéssel rendelkezik XHTML Az XHTML a HTML XML alapokra helyezése. (Az XML egy általános adatleíró nyelv) Az XHTML-nek lényegesen szigorúbb szintaktikai szabályai vannak, mint a HTML-nek. 2009-ben leállították az XHTML 2-es verziójának fejlesztését a HTML5 javára. • Egymásba ágyazás • A tagok neveit kisbetővel kell írni • Elemek lezárása • A tulajdonság-értékeket mindig

idézőjel közé kell tenni XML Strukturált adatformátumú szövegek leírására alkalmas nyelvezet. Szöveges volta miatt platform független Strukturált felépítése és az operációs rendszerektől való függetlensége lehetőséget biztosít a különböző rendszerek közötti adatátvitel megvalósítására. Mivel az XML teljesen platform és alkalmazás-független módon írja le az adatokat, az első komoly elterjedési területe a heterogén rendszerek közötti adatcsere megvalósítása volt. Az XML-ben való keresés egyrészt azért könnyű, mert kódolatlan szöveges állományról van szó, másrészt meg van jelölve, hogy melyik része szöveg, adat, kép, stb., (ezért jelölőnyelv) így elegendő csak a szövegrészben keresni Tehát különválasztja az információt és az információ ábrázolását. A különböző megjelenítési formátumokra vonatkozóan nincsenek megkötések, a nyelv önleíró. Mindig a célnak legmegfelelőbb formátum

nyerhető ki belőle, ami magyarázatot jelent a széleskörű elterjedésre (használható web böngészőkben, mobiltelefonokban, adattárolásra, de nyomtatható információ is kinyerhető). Document Type Declaration (DTD) Az XML felépítése szigorúan strukturált faszerkezetből áll. A felépítés minden egyes pontja rendelkezik tulajdonságokkal és besorolható egy típusba. A DTD tárolja a szerkezet elemeinek leírását Maga az XML csak azt határozza meg, hogy milyen elemekből áll, ezért használhatunk beszédes - akár magyar - elemneveket is. Az elemek jelentését a DTD tárolja, ezért például egy formázott szöveg megjelenítése az XML és a DTD egybevetésével lehetséges. A kuszaság elkerülése végett léteznek szabványos DTD-k. Alkalmazásukkal az XML fájlokban csak a DTD által meghatározott elemek használhatók, ilyenkor nem lehetséges saját elnevezéseink beépítése (ha mégis ragaszkodunk hozzá, saját DTD-t is kell készíteni). A

következő példa nem külső állományban, hanem helyben definiálja a DTD-t, és mindössze a lehetséges tagokkal, valamint a gyökérelem nevével foglalkozik: Állhat külön fájlban és lehet az XML dokumentum elején is. Speciális esetekben előfordulhat a kettő keveréke. Különálló DTD-nek előnye, hogy több XML dokumentumhoz is használható, ami nem elhanyagolható, figyelembe véve a sokszor időigényes elkészítését. Ha a dokumentumba épül be, akkor nincs szükség több fájlra, de kívülről más XML fájlokból nem használható. Ha egy XML fájlban is szerepel külső és belső is, akkor az utóbbi felülírja a külső definíciókat. A DTD határozza meg például, hogy egy adatot kötelező-e megadni, milyen intervallumban szerepelhet, lehet-e ismétlődő, stb. Programozók számára különösen előnyös, mert nem kell programjaikban ellenőrizni a bevitt adatok helyességét, ugyanis nem várt adatok eleve nem juthatnak el az alkalmazásig.

Minden DTD elemhez komplett stílusokat leíró szabályok rendelhetők. Fontos megemlíteni, hogy DTD-t nem kötelező készíteni. Logikai és fizikai szerkezet Az XML logikai szerkezet azt mutatja meg, hogy a dokumentum milyen elemekből áll. A fizikai pedig ezeket az elemeket tartalmazza Például a logikai szerkezetben leírjuk egy könyv felépítését, találhatók benne szövegek, képek és hivatkozások másik szövegekre. A fizikai szerkezet jelenti a szöveget, képeket és a hivatkozott szöveget tároló fájlokat. Tehát maga a teljes dokumentum a HTML-hez hasonlóan, több fájlból állhat. A szintaxisról A HTML-hez hasonlóan tagekkel (<> csúcsos zárójelek) azonosíthatók az adatok. De míg a HTML az adatábrázolás formáját határozza meg, addig az XML azt mondja meg, hogy az adat mit jelent. • Minden tagnak van záró párja. • A tagok kisbető-nagybető érzékenyek, és az egymásba ágyazás is korrekt. • Az XML dokumentumnak egy gyökér

eleme van (a példában note). • A tulajdonság értékei mindig idézőjelek között szerepelnek és mindig megadottak. CSS A CSS a Cascading Style Sheets rövidítése. A stílusok meghatározzák, hogy hogyan jelenjenek meg vizuálisan a HTML elemek A stíluslapok segítségével könnyen szét lehet választani az oldal tartalmát annak kinézetétől. A stílusokat általában külön állományban - 40 - tároljuk (.css kiterjesztéssel) Külső stíluslapokkal gyorsítani tudjuk a munkavégzést Ha bármit változtatni kell a dizájnon, lényegében csak ezt az egyetlen oldalt kell módosítanunk. A HTML tagok eredetileg arra lettek megalkotva, hogy a dokumentum tartalmát definiálják. Amikor egy címet, bekezdést vagy táblázatot akarunk létrehozni, akkor használhatjuk a <h1> és <p>. A tényleges megjelenítés a böngészőre van bízva, eldöntheti, hogy mit hogyan jelenítsen meg a tagok, az ablakméret, a felhasználó beállításai alapján.

Később a böngészől újabb és újabb HTML tagokat és tulajdonságokat adott a böngészı által felismert HTML nyelvhez (pl. a font tag, vagy a color tulajdonság). Így belekeveredtek a HTML nyelvbe a megjelenítést befolyásoló elemek (Mellesleg a böngészők csak részben és később támogatták a vetélytárs újításait.) Lépcsős elrendezés A következő négy beállítás érvényesül egyre nagyobb prioritással (tehát ütközés esetén a későbbi felülírja az előzőt). • A böngésző alapbeállítása • Külső stíluslap • Head elemben definiált stílus • Soron belüli stílus A CSS szelektorok A nyelvtan három elemet különböztet meg: kiválasztó, tulajdonság és érték: body {color: black} A kiválasztó legegyszerűbb esetben egy HTML tag, a tulajdonság azt határozza meg, hogy milyen jellemzőt akarunk módosítani, míg az érték a változást határozza meg. Egyszerre akár több kiválasztóra is érvényesíthetjük a

formázást. Ekkor a kiválasztókat vesszővel elválasztott listaként kell felsorolni • • • Osztály kiválasztó (class): Osztály kiválasztó segítségével más-más módon tudjuk megjeleníteni az egyes osztályokba sorolt elemek tartalmát. A példában a két különböző osztályhoz tartozó bekezdések más-más formázást kapnak: p.right {text-align: right} és pcenter {text-align: center} Azonosító alapú kiválasztás (id): A HTML elemeknek megadhatjuk az egyedi id tulajdonságot. Így az egyedi id-vel rendelkező elemhez speciális formázást határozhatunk meg. CSS-ben a # segítségével tudunk elemet id alapján kiválasztani #menu {color: green} Leszármazottak alapján: például az olyan <a> elemekre, melyek egy <li> elem részei, a szelektor „li a”. JavaScript A JavaScript programozási nyelv egy objektumalapú alapú, kliens oldali szkriptnyelv, amelyet weboldalakon elterjedten használnak. A neve ellenére nincs szoros kapcsolatba

a Java nyelvvel. C++ és Java szintaxisra alapoz Az objektumok A Javascript objektum-orientált nyelv, tehát objektumokkal és azok mezőivel és metódusaival dolgozik. A mezők a megfelelő objektumok egy-egy tulajdonságát képviselik, illetve a metódusok segítségével műveleteket végezhetünk rajtuk. A megadás módja mindig objektumnév.mező Amennyiben egy olyan metódust hívunk, ami nem tartozik konkrét objektumhoz, csak a típusához (statikus metódusok), akkor az objektum nevét a típus nevével kell helyettesíteni. Lehetőség van a HTML-objektumok definiálásánál megadni az objektum nevét a NAME=név attribútummal. Ekkor lehetséges lesz Javascriptből ugyanezen a néven hivatkozni rá (kivétel: Area). Minden objektum rendelkezik egy name mezővel, ami a HTML-nevét tartalmazza. Ezzel ellentétben a Javascript változóneveket nem használhatjuk a HTML-kifejezésekben! A másik mód a HTMLobjektumok elérésére hogy az őt tartalmazó objektumnak a

legtöbbször van egy tömbje, ami a benne definiált objektumokat tartalmazza, definiálási sorrendben. Ekkor csak az indexét kell megállapítani A típusok A Javascript egy laza típusokat használó nyelv, tehát a változóknak és kifejezéseknek nem rögzített a típusa, hanem a felhasználásnak megfelelően változik. Ennek következtében igen sűrűek az automatikus típuskonverziók Ha egy kifejezésnek nincs értéke, de a kód azt várja, ez hibajelzéshez vezet. Beépített objektumok • • • • • Array: Tömböket lehet vele csinálni. A tömbnek nincs fix hossza, ha egy tetszőleges indexű elemének értéket adunk, akkor automatikusan a megfelelő hosszúságúra nyúlik. A tömb néhány eleme lehet null - az az index nem tartalmaz érvényes hivatkozást egy objektumra. A toString() metódus vesszővel elválasztva adja az elemek összefűzését Date: Dátumok és időpontok kezelésére szolgál. Egy ilyen objektum tulajdonképpen az 1970 jan 1

00:0000 óta eltelt ezredmásodpercek száma. String DOM objektumok: A Dokumentum Objektum Modell egy platform- és nyelvfüggetlen standard objektummodell amely a HTML, XHTML, XML valamint rokon formátumaiknak a szerkezetét és az objektumaikkal történő interakciókat modellezi. A DOM egymással gyerek-szülő kapcsolatban álló objektumok rendszere. A dokumentum tartalmát, illetve a dokumentum valamennyi összetevőjét magában foglalja. A beépített objektumok kezelése böngészőnként eltérő lehet, továbbá plusz tulajdonságok is lehetnek különböző böngészők esetén. Egyedi objektumok: Ezeket mi magunk készítjhetjük - 41 - Események A JavaScript nemcsak előre megírt, statikus formában működhet. Kapcsolódhat felhasználó cselekvéseihez Ilyen a kattintás, az egér mozgatása egy kérdéses elem fölé vagy eltávolítása egy elemről, az oldal betöltődés stb. Az eseménykezelők olyan programok melyek eseményeket kezelnek. A programok nem

mindig a <script> elemek között helyezkednek el. Az eseménykezelők megmondják a böngészőknek, hogy mit kell tenni, ha az esemény bekövetkezik Eseménykezelő kódját az objektumhoz tartozó HTML elemben adjuk meg. Az oldal egészére vonatkozó események Esemény Load Resize Scroll Eseménykezelő onLoad onResize onScroll Unload onUnload Bekövetkezése Az oldal minden objektuma letöltődése után Dokumentum átméretezésekor Dokumentum görgetésekor Dokumentum eltávolítása esetén ablakból vagy frame-ből. Érvényes BODY, FRAMESET elemekre. Egéresemények Esemény Click MouseDown MouseUp MouseOver MouseMove MouseOut Eseménykezelő onClick onMouseDown onMouseUp onMouseOver onMouseMove onMouseout Bekövetkezése Az adott elemre való egérkattintáskor Egérgomb lenyomása az adott elem felett Egérgomb felengedése az adott elem felett Az egérkurzor az adott elem fölé kerülése esetén. Az egérkurzor az mozog az adott elem fölött. Az

egérkurzor az adott elemet elhagyja. Érvényes A legtöbb elemre. A legtöbb elemre. A legtöbb elemre. A legtöbb elemre. A legtöbb elemre. A legtöbb elemre. Formokra vonatkozó események Esemény Eseménykezelő Blur onBlur Change onChange Focus onFocus Reset Select Submit onReset onSelect onSubmit Bekövetkezése amikor az adott elem elveszti a fókuszt amikor az adott elem elveszti a beviteli fókuszt, és változás következett be a tartalmában azóta, hogy rákerült a fókusz. amikor az adott elem aktívvá válik, vagy az egér, vagy a billentyűzet segítségével (TAB). amikor FORM reset következik be. a felhasználó szöveget jelöl ki szöveges mezőben amikor a FORM adatokat elküldenek Érvényes LABEL, INPUT, SELECT, TEXTAREA, BUTTON INPUT, SELECT, TEXTAREA LABEL, INPUT, SELECT, TEXTAREA, BUTTON Csak FORM elemre INPUT, TEXTAREA Csak FORM elemre 17. A szerveroldali programozás alapelemei az Internetes alkalmazások fejlesztésénél A szerveroldali

objektumok bemutatása. Adatbázis-kezelés webűrlapokkal Egy szerveroldali programnyelv rövid bemutatása, jellemzése. A világhálón a dokumentumok elérése kliens-szerver architektúrában valósul meg. Egy dokumentum kérését mindig a böngésző (a kliens) kezdeményezi. A böngésző címsorába beírva a tartalom URL-jét, vagy egy URL-t tartalmazó hivatkozást aktiválva a böngésző a kérést a HTTP protokollon keresztül elküldi a szervernek, ahol a tartalom található. A szerver feldolgozza a kérést, majd a megfelelő feladatok elvégzése után visszaküldi a kívánt tartalmat a böngészőnek, amely megjeleníti azt (ha tudja). A szerveroldali webprogramozás komplexitását ráadásul az is növeli, hogy fontos ismernünk a kliens-szerver kommunikációját biztosító csatorna jellegzetességeit is. A két komponens közötti kommunikáció az internetes hálózaton valósul meg, a kommunikáció rendjét pedig a HTTP protokoll biztosítja. Ha a

szerveroldalra tekintünk, akkor a legelső fejezetben már megnéztük a statikus és dinamikus oldalak közötti különbséget. Láthattuk, hogy statikus állományok kiszolgálása gyakorlatilag nem más, mint egyszerű fájlkiszolgálás. A kérés pillanatában a szerveren már létezik a leküldendő tartalom. A szervernek nem kell mást tennie, mint a megadott könyvtárból felolvassa a kívánt tartalmat, és leküldi a kliensnek. Annak eldöntése, hogy mely állományok statikusak, a webszerver konfigurációja alapján történik Ez szerverenként eltérő lehet, de általában a fájl helye vagy kiterjesztése határozza meg azt, hogy a webszerver mit csinál az adott állománnyal. A tipikus kiterjesztések esetén (html, jpg, png, gif, css, js) az állományok tartalma minden feldolgozás nélkül visszaküldésre kerül. Más a helyzet szerveroldali dinamikus webprogramozás esetében. Ekkor a kért (1) állomány a kikeresés után nem kerül egyszerűen

visszaküldésre, hanem a webszerver egy megfelelő programnak adja át a vezérlést (2). Ez a program állítja elő a tartalmat, adja át a webszervernek (3), amely továbbküldi azt a kliensnek (4). CGI A program indításának szabályait a Common Gateway Interface (CGI) szabvány határozza meg. Ez egy olyan protokoll, amely leírja, hogy egy webszerver hogyan indíthat el egy programot és milyen módon kommunikál vele. A webszerver a kért állomány útvonala vagy kiterjesztése - 42 - alapján dönt arról, kell-e a kikeresés után bármit is csinálni, és ha igen, akkor melyik programot kell elindítania. A futtatható bináris állományok tipikusan egy cgi-bin nevű könyvtárban helyezkednek el, de az is lehet, hogy kiterjesztés alapján dönt a webszerver a fájl futtatásáról (.cgi, php) A webszerver által futtatott programra nincsenek megszorítások. Ez lehet egy bináris állomány, amely valamilyen általános célú programozási nyelv fordításakor

keletkezik (pl. C++ vagy Pascal), de lehet valamilyen szkriptnyelven megírt program, amit a megfelelő értelmező hajt végre (Shell szkript, Perl, PHP, Python). Összefoglalva, a szerveroldali webprogramozás tehát nem más, mint hogy a HTML kódot egy program segítségével állítjuk elő. Programunk helyes működését pedig úgy tudjuk ellenőrizni, hogy összehasonlítjuk a generált tartalmat, az elvárt tartalommal. A fenti ábrán láthatjuk, hogy architektúránk három komponensűvé vált. A HTTP protokoll A HTTP alkalmazás szintű protokoll, amely a TCP/IP protokollt használva egyszerű szöveges információ átvitelére alkalmas. A HyperText Transfer Protocol (HTTP) egy kérés-válasz alapú protokoll a kliens és a szerver között. A protokollt a világháló működéséhez dolgozták ki (a HTML és URI mellett), ezen keresztül történik a webszervereken közzétett dokumentumok elérése. E protokoll szerint a kommunikációt mindig a kliens kezdeményezi

egy kérés formájában, amit elküld az interneten keresztül a webszerver 80-as TCP portjára. A szerver a kérést feldolgozva megfelelő formátumban válaszol, és visszaküldi azt a kliensnek HTTP kérés A HTTP kérés egy meghatározott szerkezetű szöveges információ. Első sora kérés módját (METÓDUS), a kért tartalmat (ERŐFORRÁS) és a HTTP verziószámát (VERZIÓ) tartalmazza. Ezt követi tetszőleges számú fejlécsor FEJLÉC: ÉRTÉK formában, majd egy kötelező üres sort követően opcionális üzenettest következhet (ÜZENETTEST). Az általános formátum tehát a következő: METÓDUS ERŐFORRÁS VERZIÓ FEJLÉC: ÉRTÉK FEJLÉC: ÉRTÉK FEJLÉC: ÉRTÉK ÜZENETTEST A legegyszerűbb kérésben az első soron kívül legalább azt a helyet meg kell adni (Host), ahonnan az erőforrás lekérdendő: GET /index.html HTTP/11 Host: webprogramozas.infeltehu A valóságban a kéréseket nem kézzel állítjuk össze, hanem ezt a feladatot a böngésző végzi

el. Az így előállt kérések természetesen bonyolultabbak lehetnek a fentinél, hiszen számos egyéb, a szerverrel közlendő információt is tartalmaznak fejlécként. Ebben megjelennek a böngészőre vonatkozó információk is (User-Agent), a válaszban várt formátumok, nyelvek és kódolások, a felküldött sütik és a kliens-szerver közötti kapcsolat jellegét (Connection). A kérés első sorában lévő metódus a megadott erőforráson végzendő műveletet határozza meg. A szabvány nyolcféle metódust definiál, ezek a következők: • GET: a megadott erőforrás letöltése • POST: feldolgozandó adat felküldése • HEAD: ugyanaz, mint a GET, de csak a válasz fejléceket kéri le • PUT: feltölt a megadott erőforrást • DELETE: törli a megadott erőforrást • TRACE: visszaküldi a kapott kérést • OPTIONS: a szerver által támogatott HTTP metódusok listája • CONNECT: a kérést transzparens tunnellé alakítja (biztonságos kapcsolatokhoz

szükséges) A fentiek közül a HEAD, GET, OPTIONS és TRACE metódusokat biztonságos metódusoknak is hívják. Biztonságosak olyan szempontból, hogy csak információ lekérésére szolgálnak, és nem változtatják meg a szerver állapotát. Ezekkel együtt a PUT és a DELETE idempotens is, azaz a többszöri végrehajtás ugyanazt eredményezi, mint az egyszeri. Ezeknél a metódusoknál a kliens többször is újrapróbálkozhat további következmények nélkül. Bár a HTTP szabvány által megadott metódusok sokféle művelet elvégzését teszik lehetővé, látni fogjuk, hogy a böngészők ezek közül csak a GET és POST műveleteket használják. (JavaScripttel mindegyik metódus elérhető) HTTP válasz Ahogy a kérés, úgy a HTTP válasz is egy meghatározott formátumú szöveges információ. Első sora, a státuszsor tartalmazza a protokoll verzióját (VERZIÓ), a válasz státuszkódját (STÁTUSZKÓD) és egy szöveges indoklást (INDOKLÁS). Ezt megint

tetszőleges számú fejlécsor követi, majd egy kötelező üres sor után megint az opcionális üzenettest következik (ÜZENETTEST). A tulajdonképpeni tartalom (HTML) VERZIÓ STÁTUSZKÓD INDOKLÁS FEJLÉC: ÉRTÉK FEJLÉC: ÉRTÉK FEJLÉC: ÉRTÉK ÜZENETTEST - 43 - Fejlécként itt is sokféle adat jelenik meg: a kiszolgálás időpontja (Date), a szerver típusa és verziója (Server), a küldött tartalom típusa (Content-Type) és mérete bájtban (Content-Length). Az üzenettestben érkezik maga a HTML tartalom Státuszkód A státuszsorban lévő státuszkód jelzi a kiszolgálás sikerességét. A státuszkód egy háromjegyű szám, kezdő betűje határozza meg az egyes nagyobb csoportokat: • 1xx: informatív (kérés megkapva) • 2xx: siker (kérés megérkezett, elfogadva). Tipikusan: 200 OK • 3xx: átirányítás (további műveletre van szükség) • 4xx: kliens hiba (a kérés hibás, nem teljesíthető). Leggyakrabban: 404 Not found vagy 404 Nem

található • 5xx: Szerver hiba (nem tudja teljesíteni a kérést). Például: 500 Internal Server Error CGI programok Tulajdonképpen nincsen megkötés a bináris állomány programozási nyelvét illetően. A program egyetlen célja az az, hogy a HTTP és CGI protokollok betartása mellett webes tartalmat, elsősorban HTML állományt állítson elő. Így akár fordulhatunk egy közismert, a JavaScript nyelvi részét is bevezető nyelvhez, a C++-hoz. Egy CGI programnak alapvetően háromféle művelet fontos: • környezeti változók lekérdezése • olvasás a standard bemenetről • írás a standard kimenetre C++-ban ezek az utasítások adottak. Környezeti változót a getenv függvényével tudunk lekérdezni, a standard input és output pedig többek között a cin és cout objektumokon keresztül valósítható meg. A hello.exe fájlt a cgi-bin könyvtárba másolva most már böngészőből is futtathatjuk beírva az elérhetőségét ASP.NET Dinamikus weboldalak

készítését lehetővé tévő osztályok és komponensek együttese. Az ASPNET-tel a szerveren tárolt adatokból állítunk elő HTML-oldalakat, amit a kliensek könnyen megjeleníthetnek. Az ASP (Active Server Page) a Microsoft által jegyezett technológia. Az ASP oldalak írását számos beépített objektum teszi egyszerűvé. Minden objektum gyakran használt funkciók egy csoportját valósítja meg, melyek hasznosak dinamikus oldalak fejlesztésénél. A legtöbb ASP alkalmazást VBScriptben írták, de bármely más Active Script motor is kiválasztható A felhasználó tevékenységét egy eseményvezérelt modellen alapuló mechanizmus segítségével dolgozzák fel. Ha például a felhasználó egy nyomógombot megnyom, vagy egy szövegbeadási mezőt kitölt, vagy épp egy rádiógomb állapotát megváltoztatja, akkor egy ehhez tartozó eseménykezelő fog lefutni a szerveroldalon. A szerveroldalon ezeket az eseménykezelőket megírhatjuk akár C#, akár Visual

BASIC.NET, akár más NET alapú nyelveken Az oldalak fejlesztése során olyan vezérlő szerkezeteket használ mint a hagyományos windows felhasználói felületeknél. Minden webes vezérlő elem, mint például egy gomb, vagy címke, nagyon hasonlóan viselkedik mint a Windows -os megfelelője: értéket adhatunk az attribútumainak, illetve reagálhatunk az általa kiváltott eseményekre. Az ASP.NET arra buzdítja a programozókat, hogy az alkalmazásaikat az esemény vezérelt GUI paradigma alapján fejlesszék a hagyományos webes script környezetekkel szemben, mint az ASP, vagy a PHP. Meglepő, de az ASP.NET alkalmazásainkat nem csak Microsoft platformokon futtathatjuk Apache webszerveren mod mono modullal teljesen képes ASP.NET web alkalmazások futtatására Természetesen ez nem tökéletes, ha platform specifikus funkciókat használunk. Különböző beépített vezérlőkkel rendelkezik: • Felhasználói autentikáció • Szerver oldali kontrolok o HTML szerver

kontrolok: Egy HTML TAG-et tesz elérhetővé a kódból, egyedi azonosítóval rendelkezik. o Web szerver kontrolok: Bonyolultabb funkcionalitással bíró kontrolok: lanel, textbox, button, checkbox o Validátor (érvényesítő) szerver kontrolok: A felhasználói beviteli mezők érvényesítésére szolgáló szerver kontrolok. A beviteli mezőkhöz kötve lehet ellenőrizni az adott tartalmat, hogy az a programozó által definiált értéknek megfelelően lett-e kitöltve vagy egyáltalán ki lett-e töltve. Vannak előre beépített validátorok Pl: RequiedFieldValidator, CompareValidator, RangeValidator, RegularExpressionValidator 18. Az informatikai biztonság fogalma A biztonsági rendszer tervezése, a tervezés szakaszai Az egyes tervezési szakaszok fő feladatai. A kockázatelemzés célja és lépései Az informatikai rendszerek elleni támadások típusai. Az informatikai biztonság fogalma: Az informatikai biztonság a védelmi rendszer olyan, a szervezet számára

kielégítő mértékű állapota, amely az informatikai rendszerekben kezelt adatok bizalmassága, sértetlensége és rendelkezésre állása szempontjából zárt, teljes körű, folytonos és kockázatokkal arányos. Az egyes tervezési szakaszok fő feladatai: A teljes körű, zárt és kockázatarányos védelem létrehozása csak egy átgondolt tervezési folyamat után valósítható meg. - 44 - Az informatikai rendszerek és környezetük biztonsági rendszere legtöbbször nem a fejlesztési, megvalósítási projekt szerves részeként valósul meg, hanem a projekt befejezése után, akár több éves késéssel, leginkább az első biztonsági esemény bekövetkezése után. Ez azért jelent gondot, mert így a biztonsági megoldások többnyire a kényszer szülte improvizált megoldások szintjén marad, amelyek hatékonysága gyakran megkérdőjelezhetı. Jellegzetes példa egy lényeges védelmi funkció, a biztonsági naplózás megoldása. A biztonsággal

kapcsolatos események (be/kilépés, hozzáférések, tranzakciók követése, stb.) rögzítése általában jelentős erőforrás és tárolási kapacitás igényő Az informatikai biztonsági rendszer, azaz a fizikai és a logikai védelmi rendszer megtervezésének, valamint az adminisztratív védelem koncepciója felállításának minden informatikai projekt részének kell lennie. A döntésről szóló dokumentumnak tartalmaznia kell a biztonsági rendszer megvalósításának szükségességét (indokolását) és a finanszírozási feltételeket. Az informatikai rendszerekre vonatkozó ajánlatkérések, pályázatok kiadása előtt meg kell határozni a minimális informatikai biztonsági követelményeket. Az informatikai projekt kifejezést a következőkben széles értelemben használjuk, mert a tervezés és megvalósítás tárgya lehet számítógépes infrastruktúra (hálózat, hardver, alapszoftver rendszerek) vagy alkalmazás szintű. A kockázatelemzés célja

és lépései: Az informatikai biztonsági vizsgálat olyan elemző és értékelő jellegő szakértői vizsgálat, amelynek fő célkitűzése a kezelt adatok és alkalmazások biztonságának elemzése. Ennek során a védelmi célokkal, a teljes rendszer biztonsága kerül feltérképezésre, mellyel lehetőleg kockázatelemzés után - az elviselhetetlen kockázatot jelentő fenyegetések kerülnek kimutatatásra A vizsgálattal kockázatkezelési és intézkedési javaslatok is készülhetnek. A vizsgálatot végezhetik belső ellenőrök vagy külső szakértők, illetve akkreditált auditorok. Az ellenőrzése során a szervezet által elfogadott kockázatelemzésen alapuló módszertant kell felhasználni, például a MeH ITB 8. számú ajánlását, az Informatikai Biztonsági Módszertani Kézikönyvet. Valamely informatikai rendszer biztonságának kockázatelemzésen alapuló vizsgálata során elsőként a meglévő, potenciálisan fenyegetett értékeket kell

feltérképezni és újraértékelni. Ezután azokat a várható következményeket kell feltárni, amelyek akkor alakulhatnak ki, ha ezek a követelmények (védelmi célok) az alapfenyegetettségeket illetően nem teljesülnek. Valamennyi olyan rendszerelemet vizsgálni kell, amelyektől az informatikai rendszer működése és valamilyen módon az alkalmazásai függnek, és amelyeket valamely fenyegető tényező vagy veszélyforrás közvetett, illetve közvetlen módon érinthet. Ehhez a következő meglévő rendszerelem-csoportokat kell áttekinteni • Tárgyiasult elemcsoportok o környezeti infrastruktúra o hardver o adathordozók o dokumentumok, iratok • Logikai elemcsoportok o szoftver o adatok o kommunikáció • Személyi elemcsoport - 45 - o személyzet o felhasználók o ellenőrök Miután nem védekezhetünk tökéletesen valamennyi fenyegető tényező ellen, meg kell ismerni a legfontosabbakat. Ehhez valamennyi feltárt fenyegető tényezőt értékelni

kell. Az értékelés függ a kár bekövetkezésének várható valószínőségétől és a bekövetkezett kár nagyságától, amennyiben a fenyegető tényező kifejtheti hatását. Ebből a két részből tevődik össze a kockázat Biztonsági események valószínűsége • Emberek idéznek elő: a potenciális tettesek felkutatásával, és azok számának megadásával becsülhető meg, akik a megfelelő lehetőségekkel és ismeretekkel rendelkeznek. • Műszaki hiba, vis major: statisztikák, megbízható működési adatok és saját tapasztalatok összegzésével lehet megbecsülni. • Személyek gondatlan vagy hibás tevékenysége: mint az előző. felelő Az általános biztonsági stratégiából vezethető le az elviselhetı kockázatok mértéke, illetve a tervezett intézkedések elfogadhatósága. Az informatikai rendszerekre és környezetükre ható fenyegetések által okozott kockázatok felmérése és minősítése után olyan védelmi intézkedésekre

kell javaslatot tenni, amelyek minimális költség szint mellett maximális kockázat csökkentést eredményeznek. Az informatikai biztonsági vizsgálat négy eljárási szakaszra, azon belül pedig 13 lépésre bontható. Az egyes lépéseket szükség szerint meg kell ismételni. 1. Szakasz 1. Az informatikai alkalmazások és feldolgozandó adatok feltérképezése 2. Az informatikai alkalmazások és feldolgozandó adatok értékelése 2. Szakasz 3. A fenyegetett rendszerek feltérképezése 4. Az alapfenyegetettség meghatározása 5. A gyenge pontok és fenyegő tényezők meghatározása 3. Szakasz 6. A fenyegetett rendszerelemek értékelése 7. A károk gyakoriságának meghatározása 8. A fennálló kockázat meghatározása, leírása 4. Szakasz 9. Az intézkedések kiválasztása 10. Az intézkedések értékelése 11. A költség/haszon arány elemzése 12. A maradványkockázat elemzése 13. Akcióterv kidolgozása és jóváhagyása az ellenőrzött intézkedések

megvalósítására Az informatikai rendszerek elleni támadások típusai: • • • Belső támadás: Belső támadásnak nevezünk minden olyan támadási módszert, melyet olyan felhasználók valósítanak meg, akik már a rendszerrel szemben valamilyen bizalmi státuszban vannak (például van jelszavas hozzáférésük egy adott kiszolgálóhoz), így nem kell a hálózati biztonsági beállításait kijátszaniuk. A gyakorlatban a támadások nagy hányada belső támadás, ugyanakkor egy sikeresen megvalósított külső támadás célja sok esetben a rendszerhez való hozzáférés, és azon valamilyen belső támadás végrehajtása. Social Engineering: A támadók legkönnyebben a felhasználók nem megfelelő jelszóválasztását és gondatlanságát kihasználva szerezhetik meg a jelszót. A Social Engineering az emberek bizalomra való hajlamának kihasználása A rossz szándékú támadók gyakran használják ezt a módszert a számítógépekhez való

illetéktelen hozzáférésre és információk megszerzésére. A legjellemzőbb ilyen jellegű bűncselekmények körébe az "adathalászat" tartozik, amelynél a csalók különböző eszközökkel (például telefonhívás, e-mail) ráveszik a gyanútlan felhasználót, hogy árulja el jelszavát, adjon meg bizalmas adatokat, illetve számítógépén töltsön le, indítson el alkalmazást az elektronikus üzenetben kapott link segítségével. Külső támadás: A hálózati biztonsági beállítások kijátszásával próbálnak egy rendszerhez jogosulatlanul hozzáférni. A külső támadások irányulhatnak információ megszerzésére, törlésére, egy szolgáltatás megbénítására vagy speciális erőforrások jogosulatlan felhasználására. 19. A megbízható informatikai rendszer alapfunkciói, biztonsági követelményeit szabályozó hazai és nemzetközi szabványok, ajánlások, dokumentumok. Az informatikai rendszer elleni támadások kivédésének

eszközei. Kriptográfiai módszerek és eszközök, azok gyakorlati alkalmazásai A megbízható informatikai rendszer Az informatikai rendszerek, és az általuk kezelt adatok által hordozott információk rendelkezésre állásának és funkcionalitásának védelme. Hazai és nemzetközi szabványok ISO 27000 • ISO/IEC 27001:2005: Az Informatika – Biztonsági technikák – Informatikai biztonság irányítási rendszere – Követelmények címem lett kiadva. Az ilyen tevékenység célja valamennyi, az informatikai biztonság irányításával (menedzselésével) foglalkozó szabvány egyetlen sorozatba győjtése. • • - 46 - ISO/IEC 27002:2005: Egyes országokban megindult olyan ajánlások, követelmények fejlesztése is, amelyek kifejezetten a felhasználók számára nyújtanak segítséget. ISO/IEC 27001 (BS 7799-2): A szervezetek vezetése számára meghatározza azokat a teendőket, amelyekkel az informatikai biztonsági rendszert irányíthatja,

csökkentheti a maradék kockázatokat, valamint ellenőrizheti a jogszabályoknak, a tulajdonosok és az ügyfelek által támasztott biztonsági követelményeknek való megfelelést. ISO/IEC TR 13335 nem szabvány, annak ellenére, hogy szabványsorozatának részeként került kiadásra, de „Technical Report”-ként. Ebben az esetben ez a megoldási lehetőségek leírását jelenti, és ezt csak akkor vizsgálják felül, ha az abban foglaltak már nem érvényesek, vagy már nincsenek használatban. ITIL Az ITIL kezdetben brit szabvány és kormányzati ajánlás volt, a közigazgatási területen általában megkövetelték az alkalmazását. Mivel a gyakorlati alkalmazás tapasztalatai kedvezőek voltak, a módszertant a piaci környezetben is egyre inkább használni kezdték. • Szolgáltatásstratégia: A folyamat azonosítja azokat a (piaci) lehetőségeket, amelyeket új szolgáltatások bevezetésével ki lehetne aknázni. • Szolgáltatástervezés: A folyamat

eredményeként projekt-terv készül az előző lépésben keletkezett stratégia által felvázolt szolgáltatás konkrét megvalósítására. A terv részletezi az új szolgáltatás bevezetésének minden vonatkozását, a bevezetéshez és üzemeltetéshez szükséges támogató folyamatokkal együtt. • Szolgáltatáslétesítés és –változtatás: A megtervezett szolgáltatás létesítéséhez és a környezet módosításához szükséges folyamatok leírása. • Szolgáltatásüzemeltetés: Az előzővel szorosan összefüggő kötet tárgyalja a szolgáltatás folyamatos és hibamentes üzemeltetéséhez szükséges folyamatokat és szervezési kérdéseket. A folyamatok garantálják a szolgáltatási megállapodásokban (SLA, Service level agreement) vállalt szolgáltatásminőséget. Legfontosabb fejezetek a Hiba- és igény- és incidenskezelés. • Állandó szolgáltatásfejlesztés: tárgyalja a szolgáltatás folyamatosan javuló minőségben nyújtásának

feltételeit. COBIT Azzal a céllal dolgozták ki, hogy forrásanyagot biztosítnak az ellenőrzési szakemberek számára. A COBIT üzleti folyamatokra helyezi a fő hangsúlyt, és az ezeket támogató informatikai folyamatokhoz kapcsolódóan, amelyek négy területre összpontosít: • tervezés és szervezet; • beszerzés és üzembe állítás; • informatikai szolgáltatás és támogatás • valamint felügyelet. A COBIT az informatikai rendszerek szervezéséhez, és különösen az ellenőrzéséhez szükséges irányelveket tartalmazó dokumentum, amely a biztonság kérdésére nagy hangsúlyt fektet, de annak részleteivel nem foglalkozik. Magyar Informatikai Biztonsági és Tanúsítási Séma (MIBÉTS) Az információvédelem munkáinak hatékonyabb végrehajtása érdekében szükség volt a nemzeti, a NATO és az EU követelmények és feladatok egységes szakmai szempontokra épülő kezelésére. Ki kell alakítani az informatikai alkalmazások minőségének

és biztonságának hiteles tanúsítási rendjét, az ehhez szükséges jogszabályok megalkotásával és intézményrendszer felállításával. A kormányhatározat végrehajtásával párhuzamosan hazánk csatlakozott a Common Criteria (CC, Közös szempontrendszer) egyezményhez. Csatlakozásunkkal kapcsolatosan elkezdődött egy saját nemzeti séma, melynek során ki kell alakítani a megfelelő bevizsgálási, auditálási folyamatokat az informatikai eszközök biztonságának ellenőrzésére. Részben CC egyezményhez való teljes csatlakozás támogatására, a hazai hiteles tanúsítási rendszer kialakítását elősegítendő, részben a nem nemzetközi alkalmazásra szánt informatikai termékek biztonsági bevizsgálását elősegítendő készült el a Common Critérian alapuló, egyszerűsített (honosított) változataként a MIBÉTS. A MIBÉTS az új informatikai rendszerek bevezetése, a működő rendszerek – az informatikai sajátosságokból adódó -

folyamatos megújítása, fejlesztése során, a tervezéstől a bevezetésig figyelembe veendő a technológiai biztonsági szempontokat kialakításához és értékeléséhez nyújt támogatást. Két fontos fogalom van: a védelmi profil és a megfelelési szint. A védelmi profil (Protection Profile, PP) azoknak az elvárt szempontoknak az összessége, amely szerint a rendszert (szoftvert, hálózatot, céget, stb.) vizsgáljuk, amilyen támadásokat szeretnénk kivédeni, amilyen szempontokat fontosnak tartunk (esetleg más szempontok kárára, de akkor is tudatosan választunk ezek közt). A megfelelési szint (Evaluation Assurance Level, EAL) az adott védelmi profil és a rendszer közt bizonyított megfelelés erősségét jelenti. Fontos: védelmi profil nélkül nem értelmes EAL-ról beszélni, a megfelelés mindig valamilyen szempontrendszer szerint történik. Magyar Informatikai Biztonság Irányítási Keretrendszer (MIBIK) A Informatikai és Hírközlési

Minisztérium 2004-ben úgy döntött, hogy a nemzetközi trendekkel összhangban kidolgoztatja a szervezeti szintű informatikai biztonság követelményeit és a vizsgálat rendjét a nemzetközi, EU és NATO releváns szabályozásai figyelembe vételével. A MIBIK – jelenleg – három kötetből áll. • Informatikai Biztonság Irányítási Rendszere (IBIR), • Informatikai Biztonság Irányításának Követelményei (IBIK): A követelményrendszer átfogó tájékoztatást ad a szervezetek vezetésének és szakembereinek az informatikai biztonsággal kapcsolatos követelményekről. Az IBIK célja a szervezetek részére egységes elveken nyugvó, a nemzetközi szabványokhoz és ajánlásokhoz igazodó olyan hazai elıírások biztosítása az informatikai biztonságának megteremtéséhez. • - 47 - Ezzel a megoldással azt a biztonság alapelvet követi, miszerint a védelmi intézkedéseknek a rendszer összes elemére ki kell, hogy terjednek (teljes

körűség), és valamennyi releváns fenyegetést figyelembe kell venniük (zártság). Informatikai Biztonság Irányításának Vizsgálata – módszertan (IBIV): A szervezetek vezetése és belső ellenőrző szervei által végrehajtott ellenőrzések mellett a nemzetközi, de már a hazai gyakorlatban is egyre jobban terjed – megfelelő felkészülés után – a megfelelést bizonyító audit elvégzése. A hazai gyakorlatban nincs elfogadott, elismert eljárásrend erre a tanúsítási folyamatra, illetve a tanúsító szervezetek engedélyezésére, kijelölésére, a tanúsítványok elismerésére. Az IBIV célja a közigazgatási és a gazdasági kormányzati szféra informatikai rendszereinek biztonsági vizsgálatához módszertan biztosítása, és tanúsítására vonatkozó igényeinek eredményes kielégítése, amely során a szervezet vezetése bizonyosságot szerezhet arról, hogy a szervezet informatikai rendszere kielégíti saját biztonsági céljait,

illetve az az érdekelt külső felek meggyızıdhetnek arról, hogy az őket is érintı biztonsági fenyegetéseket kellıen figyelembe veszik az tanúsított szervezet informatikai rendszerében hozott ellenintézkedésekkel. Az informatikai rendszer elleni támadások kivédésének eszközei A védelem megvalósítása nem csupán egy eszközrendszer megvalósítását, hanem egy szervezet teljes, azaz a fizikai, a logikai és az adminisztratív védelmi rendszerére vonatkozóan, a tervezéstől a megvalósításig terjedő folyamatát jelenti. Egy nagyobb szervezetnél, ahol kiterjedt az IT infrastruktúra, nagy az alkalmazások száma, az adminisztratív szabályozási háttér nem valósítható meg egy politikával és egy szabályzattal, mert ha azok a részletekre is kiterjednek, akkor a politikai és a szabályzati dokumentumok egyszerűen kezelhetetlenek lesznek. Ezért nagy szervezeteknél az adminisztratív védelemnek társasági és rendszer szintekre tagolt

hierarchikus szerkezetét kell kialakítani. Kriptológia A kriptológia az adatok, üzenetek rejtjelezésével (kódolás, sifrírozás) és megoldásával (rejtjelfejtés, dekódolás, desifirozás) foglalkozó tudományága, a matematikai tudományok egyik részterülete. A rejtjelzett kommunikáció folyamatában a küldő és a fogadó üzenetváltása történik meg. A küldő a nyílt szövegből rejtjelzés segítségével rejtjelzett szöveget állít elő, majd elküldi a vevőnek, aki azt visszafejtve megkapja az eredeti nyílt szöveget. A rejtjelzési során a rejtjelzett szöveg előállításához az algoritmuson kívül általában szükséges egy kulcs is, amelynek ismerete elengedhetetlen a rejtjelzésnél és a visszafejtésnél is Kriptográfia - rejtjelezés A kriptológia egyik fő területe a kriptográfia, magyarul a rejtjelzés, amelynek alapvető feladata matematikai módszereket alkalmazó algoritmusokkal és azok használatának pontos leírását

tartalmazó – szigorúan betartandó – kriptográfiai protokollok segítségével biztosítani az üzenetek, illetve tárolt információk bizalmasságát, védettségét, hitelességét. Kriptoanalízís – kriptográfiai bevizsgálás A kriptológia másik tudományága a kriptoanalízis, amely a rejtjeles üzenet birtokában, de az eljárás teljes ismerete nélküli megfejtéssel (feltörésére) irányuló eljárásokkal foglalkozik. A kriptoanalízis főként matematikai módszereket használ Maga az adatok rejtjelzése, egyfajta védekezési eszköz, amely komoly védelmet jelent, de önmagában meglehetősen sérülékeny, ha nem párosul egyéb, többek között az informatikai biztonságot is érintı védelmi intézkedésekkel. Szimmetrikus rejtjelező algoritmusok A klasszikus rejtjelző eljárások egyetlen kulcsot használnak rejtjelzésre és megoldásra, miközben a megoldó algoritmus nem feltétlenül egy fordított sorrendben végrehajtott rejtjelzés. A

legismertebb a DES. Használata nem kizárólagos Több helyen használják a svájci IDEA eljárást, vagy a Blue-Fish algoritmust • • • DES: 64 bites nyílt üzenetblokkokat képez le ugyancsak 64-bites rejtjeles üzenet-blokkokba, 56 bit nagyságú kulcsméret mellett. Az IBM által kifejlesztett algoritmus biztosítja, hogy a blokkon belül a kimenet minden bitje függ a bemenet minden bitjétől. A szabvány tartalmazza azt a kikötést is, hogy csak hardware implementált változata használható az USA-n belül, és az USA kormányzat megtiltotta, hogy ezt a hardware kivitelezést exportálják. 19 különálló fokozatból épül fel. Az első lépés egy kulcsfüggetlen keverés a 64 bites bemeneten Az utolsó lépés ennek pontosan az inverz művelete. Az utolsót megelőző lépésben az első 32 bites részt felcseréljük a hátsó 32 bites résszel A maradék 16 lépés működése ehhez hasonló, de mindegyik paraméteréül a kulcs különböző függvényekkel

képzett értéke szolgál. Az algoritmus lehetővé teszi, hogy a dekódolást ugyanazzal a kulccsal végezhessük, mint a kódolást Egyedül a lépések sorrendjét kell megfordítanunk. 3-DES: A DES javításként terjedt el. Ez vagy kettő, vagy három 58 bites kulccsal dolgozik Az üzenetet először az első kulccsal rejtjelzik normál DES módban, majd a második kulccsal a megoldó algoritmust alkalmazzák. Az így nyert közbülső szövegre alkalmazzák ismét az első, három kulcsos rendszerben a harmadik kulcsot. Az export-tilalom miatt számos konkrét chip-megvalósítás található a piacon, és a pénzügyi szféra több nemzetközi szabványában található 3-DES elem. Elsőrendő alkalmazási területe maga a kulcsterítés Magát az algoritmust 5 évenként biztonsági vizsgálatnak vetették alá. Ez utoljára 1994-ben történt meg, amikor 1998-at jelölték meg a felhasználhatóság utolsó határának. AES: A DES utódja, amely az Advanced Encryption

Standard (Fejlett Rejtjelző Szabvány) nevet kapta. A pályázatot 1997 szeptemberében írták ki, közzétéve azon elvárásoknak a listáját, amelynek az AES algoritmusnak meg kell felelni. Ugyanakkor deklarálták, hogy a benyújtott rejtjelzési algoritmusok nyilvánosak, szabadon felhasználhatók lesznek. A kiírás szerinti elvárások: o Legyen blokkos algoritmus 128 bites blokkmérettel o A 128, 196 és 256 bites kulcsméret opcionálisan egyaránt megválasztható legyen o Az algoritmus nyilvános, jogdíj nélkül használható o Álljon ellen valamennyi ismert rejtjelfejtési módszernek o Legyen világos, logikus szerkezetű, áttekinthető o Mind a kódolás, mind a dekódolás gyors legyen o Kevés memóriát foglaljon el - 48 - o Többféle processzoron is hatékonyan implementálható legyen A versenyt a RIJNDAEL algoritmus nyerte meg, melynek szerzői belga kriptográfusok Ez algoritmus teljes mértékben megfelel a fent leírt feltételeknek. Egyszerű,

bármely programozási nyelven gyorsan programozható A DES-hez hasonlóan a Rijndael is helyettesítést és keverést alkalmaz, szintén több körben. A körök száma a kulcs és a blokk méretétől függ A DESsel ellentétben azonban itt minden művelet egész bájtokra vonatkozik, hogy hardveresen és szoftveresen is hatékony megvalósításokat lehessen készíteni. Nyilvános kulcsú rejtjelezés Olyan kriptográfiai rendszerben használják, amelybe bárki beléphet résztvevőként. A rejtjelző és a megoldó algoritmus azonos, és a rejtjelzéshez, illetve a visszafejtéshez kulcspárt használ. Az egyik kulcs a nyilvános kulcs, amivel a rejtjelzést végezzük, a másik pedig a titkos (privát) kulcs, amivel a visszafejtés végezhető el. A nyilvános kulcsot a felhasználó nevével együtt nyilvánosságra hozzák, a titkos kulcsot pedig titokban tartják. A rejtjelzést a nyilvános kulcs birtokában könnyű elvégezni, de pusztán ezzel a kulccsal a dekódolás

gyakorlatilag nem kivitelezhető. A titkos kulcs segítségével azonban a dekódolás is gyors művelet. Ezt a filozófiát megvalósító rendszerek győjtőneve: Nyilvános kulcsú rendszerek (public key cryptosystems). A széles körben használt RSA algoritmus az ismeretlent hatványban tartalmazó egyenletek megoldásának nagyfokú bonyolultságát használja ki. Jelenlegi matematikai ismereteink szerint egy megfelelő gondossággal kivitelezett RSA-titkosítás eredménye számításelméleti okok miatt nem fejthető vissza olyan gyorsan, hogy érdemes legyen megpróbálni. Azonban matematikailag nem bizonyított hogy a titkosított adat visszafejtésére nem létezik kellő gyorsaságú algoritmus, ezért a jövőben ilyen algoritmus felfedezése lehetséges. A kezdetben biztonságosnak ítélt 40 bit hosszú kulcsok helyett ma már nem nevezhető biztonságosnak egy 1024 bitnél rövidebb kulcs. A nyilvánosságra hozott kulcs egy (E,M) egészekből álló számpár. A

titkosítás ezek segítségével történik Először a dokumentum adott hosszúságú blokkjait az M modulusnál kisebb egész számmá alakítják, majd ezt a számot M modulusban felemelik az E-edik hatványra. Ez a szám, illetve ennek az átviteli csatornára elfogadható sorozattá kódolt változata lesz a titkosított üzenet A titkos kulcs a nyilvánoshoz hasonlóan egy (D,M) számpár, ahol M azonos az előzıvel, míg a D dekódoló exponens úgy van megválasztva, hogy a titkosított üzenetnek megfelelő modulo-M számot D-edik hatványra emelve az eredeti üzenet adódik. Megbízható algoritmushoz M-et két nagyon-nagy prímszám szorzatának, E-t véletlenszerően választják. Megjegyezzük, hogy a rejtjelzést a (D, M) titkos kulccsal is el lehet végezni. Ekkor a megoldó kulcs a nyilvános (E,M) kulcs lesz Elektronikus aláírás A hagyományos aláíráshoz hasonlóan az elektronikus, vagy ahogy a mindennapi életben használjuk a digitális aláírás biztosítja

az elektronikus iratok hitelességét és sértetlenségét. A digitális aláírás fizikai megvalósításához általában az aszimmetrikus rejtjelzésen alapuló protokollt használják. Digitális aláírásnak olyan elektronikus karakter-sorozatot neveznek, amelyet igen nagy valószínőséggel csak az aláírótól származhat. A digitális aláírás tartalmazza az üzenet egyirányú képét (lenyomatát), s egyéb adatokat, például keltezést (dátumot, pontos időpontot), sorszámot, a küldött üzenetből képezett ellenőrző számot. Az aláírás jellemző a létrehozójára és az üzenetre egyaránt Az elektronikus aláírást bárki ellenőrizni tudja, aki a megfelelő infrastruktúrához hozzáfér. A digitális aláírás két részből áll: a személyhez kötött aláírást generáló részből, s az ellenőrzést bárki számára lehetővé tevő részből. A digitális aláírás elkészítéséhez először kiegészítjük a dokumentumot a megfelelő

azonosítókkal, majd ennek a kiegészített dokumentumnak egy alkalmas sűrítményét készítjük el. Ez lesz a digitális aláírás Az alkalmas sűrítmények elkészítésére szolgálnak az úgy nevezett Hash eljárások. A Hash algoritmus egy olyan transzformáció, amely egy tetszőleges hosszú szöveg fix hosszúságú digitális sürítményét készíti el, amely kizárólag az adott szövegre jellemző. Angolul message digestnek is nevezik. A nyilvános kulcsú kriptográfiában leggyakrabban alkalmazott a Standard Hash Algoritmus, 64 SHA, amely USA szabvány. Az algoritmus inputja egy tetszőleges, de maximum 2 bit hosszúságú dokumentum, az outputja pedig egy 160 bit hosszúságú string. Az algoritmus számítástechnikailag sokféle módon valósítható meg, amelyeknek azonban ugyanazon bementi sorozat esetén, ugyanazt a lenyomatot kell eredményezni. Kulcskezelés, PKI, CA CA - Certification Authority (Hitelesítés Szolgáltató) A nyilvános kulcsú rendszerben

fontos tudni, hogy a nyilvános kulcs tulajdonosa valóban az a személy, akinek a levelet szánjuk. A digitális aláírást bárki létrehozhatja, ezért valakinek tanúsítani kell, hogy valóban az az aláíró, akinek vallja magát. Ennek valódiságát egyrészt az alkalmazott digitális aláírások biztosítják, másrészt különféle, úgy nevezett biztonsági modellek segítségével. A legbiztosabb megoldás a direkt biztonsági modell, amelyben mint a neve is mutatja a vevő személyesen adja át nyilvános kulcsát az adónak. Ez a valóságban, – a fizikailag nagy távolságok miatt – a legtöbbször kivihetetlen, ezért széles körben a hierarchikus biztonsági modell alapján kiépített Hitelesítés Szolgáltatón alapuló rendszer terjedt el a gyakorlatban. A résztvevők által megbízhatónak tekintett harmadik fél egy digitális közjegyző szerepét játssza. Olyan szakosodott szervezet vagy cég, amely tanúsítványokat adhat ki kliensek és szerverek

számára. A CA igazolja, hogy egy adott azonosítóval rendelkezı felhasználó az, akinek vallja magát. A rendszer legfontosabb eleme a fa struktúra gyökerében elhelyezkedő CA, aki direkt módon bizonyítja egy kulcs valódiságát, amennyiben ő adta ki. A fa szerkezet többi szereplője a CA-tól, vagy egymástól kaphat igazolást egy objektum valódiságáról A CA-nak is van nyilvános-titkos kulcspárja, amit az elektronikus igazolás kiadására alkalmaz. A kibocsátott tanúsítvány tartalmazza az adott entitáshoz tartozó nyilvános kulcsot, az entitás nevét (személyazonosítóját), az érvényesség (lejárat) idejét. Ezt írja alá titkos kulcsával a CA, s ezzel az adott entitás és a nyilvános kulcs összetartozását mindenki számára ellenőrizhető módon hitelesíti. PKI - Public Key Infrastructure (Nyilvános Kulcsú Infrastruktúra) A Hitelesítés Szolgáltatónak feladata ellátásához rendkívül szigorú biztonsági feltételeket kielégítı

infrastruktúrával kell rendelkezni. Ezek a biztonságos titkosítási módszerek mellett magukban foglalnak számítástechnikai követelményeket, mint például megbízható tűzfalak alkalmazása, de kiterjednek a személyzetre és a fizikai környezetre is. A nemzetközi feltételeket, szabványokat kielégítő infrastruktúrát a PKI rövidítés jelöli. A hozzáférést leginkább jelszóval szabályozzák. Elterjedőben vannak biometriás azonosítók is A maradék követelmények kielégítésére elsősorban a nyilvános kulcsú kriptográfia módszereit használják. Nem elhanyagolható szempont a kulcskezelés - 49 - kérdésköre. Megnyugtató módon kell gondoskodni a kulcsok generálásáról, tárolásáról, visszavonásáról, a korrumpálódott kulcsok kezelésérıl, stb. Kriptográfiai protokollok Pontosabban egy protokoll, különböző gépeken azonos hálózati rétegben futó társfolyamatok kommunikációját leíró szabályok győjteménye. A

kriptográfiai protokoll kriptográfiai algoritmusokból, alapelemekbıl épül föl, és egy összetett feladatot hajt végre két vagy több résztvevő között. Leggyakrabban hitelesítő és kulcs-csere protokollokat használunk A gyakorlatban legismertebb komplex protokoll az Interneten két gép közötti bizalmasság és hitelesség biztosítására használt SSL (az újabb változat neve TLS) protokoll. Manapság egyre több helyen alkalmaznak különböző digitális pénzt kezelő protokollokat is (E-cash, Digicash, Micromint), bár ezek némelyike annyira összetett, hogy több részprotokollra bontható. Ezekre a séma elnevezés is használatos. Egy szimmetrikus kulcsot használó esetben a protokoll rendkívül egyszerű lehet, míg nyilvános rendszerben – éppen annak nyilvános volta miatt – a protokoll nagyon bonyolulttá válhat. 20. Az információs rendszer fogalma és összetevıi Adat, információ, tevékenység, esemény, felhasználó, szabvány. Az

információs rendszer szintjei és nézetei Rendszerszervezési életciklus Tervezés, szervezés, modell. Szervezetek strukturálási módjai Átvilágítás, diagnosztizálás Az információs rendszer fogalma és összetevői Az információs rendszer: • adatoknak (információknak), • a velük kapcsolatos információs eseményeknek, • a rajtuk végrehajtott információs tevékenységeknek, • az előzőekkel kapcsolatos erőforrásoknak, • az információk felhasználóiknak, • ill. a fentieket szabályozó szabványoknak és eljárásoknak szervezett együttese Adat, információ, tevékenység, esemény, felhasználó, szabvány Adat Értelmezhető, de nem értelmezett ismeret: Információ Új ismeretté értelmezett adat. • Az információ fogalma (1): olyan új, illetve feltárt ismeret, amely a már meglevő ismeretek (adatok, tények) rendszerezéséből, összevetéséből, elemzéséből, értékeléséből, modellszerű felhasználásából, stb.

származik • Az információ fogalma (2): új ismeretté értelmezett adat. (Amely meghatározásban az ismeret megszerzésének három momentuma (sorrendben): érzékelés, észlelés és felfogás.) Információs tevékenység • • • adatkezelési műveletek: nem születnek új ismeretek adat-előállítási műveletek: új ismeretek születnek vezérlési műveletek: résztevékenységek összehangolása Információs tevékenységnek az adatok kezelését és előállítását célzó illetve az előbbieket vezérlő műveletek szervezett egységét tekintjük. Információs esemény Az információs tevékenységet kiváltó illetve az azt lezáró momentumot nevezzük. (A tevékenység az az adatfeldolgozási egység, amelyet a felhasználói igény indító és lezáró eseményei határolnak.) Felhasználók A felhasználó az ismeretekkel kapcsolatban álló embercsoport. Egy felhasználó több szerepet is betölthet • végső felhasználó • alkalmazási

felhasználó • adatszolgáltató • adatfelhasználó • az információs rendszer fejlesztői is felhasználók • a vezető sajátos felhasználói szerepet tölt be • szervezeti egység, mint speciális szerepkör Szabvány Az információs rendszerben vagy annak környezetében levő tényezőkre vonatkozó megegyezés. • magukban hordozzák a kényszer momentumait • konvención alapulnak • hármas szerepet töltenek be: - 50 - o eligazítás o korlátozás o tájékoztatás Az információs rendszer nézetei és szintjei Az információs rendszer nézetei (vetületei): • • • Adatvetület: o az alapvető ismeretek lényege és elrendezése, viszonylag stabil o viszonylagos objektivitással rendelkezik o az információs rendszer többi tényezőjétől viszonylag független Feldolgozás vetület: o magában foglalja az eseményt és a tevékenységet o viszonylag instabil, és viszonylag szubjektív o a rendszer többi részétől nem független o az

adathoz képest többszörös lehet Környezeti vetület: o az információs rendszert determinálja o felhasználók szubjektív kívánságai o eszközök objektív képességei o szabványok feltételrendszerei Vetületek szintjei: A vetületeket egymással összefüggésben kell értelmezni és vizsgálni. Mindhárom vetületnek léteznek a következő szintjei (adattervei): • Fogalmi szint: A valóságnak kompromisszumoktól mentes képét rögzítı tervet nevezzük. • Logikai szint: Az alkalmazási környezet korlátainak megfelelően átalakított kompromisszumos fogalmi tervet nevezzük. • Fizikai szint: Az ismereteknek az ábrázolását és tárolóeszközökön való elhelyezését rögzítő tervet nevezzük. Szintek kapcsolata: • Az elérendő célt a fogalmi szint tartalmazza. • Az elérendő célt adott megoldási módnak (logikai szint) megfelelően képezzük le. • A módot (logikai szint) az adott viszonyok konkrétumaira szabjuk. Rendszerszervezési

életciklus Tervezés szintjei: • Átfogó, elsődleges terv (plan) • Részletes, másodlagos terv (design) • Harmadik féle, a kivitelezési terv (schedule) • Rendszerszervezésben általánosan: projektterv Fogalmak • • • • • • • Tervezési folyamat: (tervezés) az az időben lezajló tevékenységsorozatot, amelynek során az információs rendszer adott vetületekbe és szintekbe sorolt elemeit meghatározzuk, illetve azokat tudatosan összehangoljuk. Terv termék: (terv) a tervezési folyamat végeredménye, produktuma. Dokumentáció: a tervezés folyamatának, lépéseinek, és tapasztalatainak általános módon rögzített formáját. Specifikáció: általában a részletesebb, a megvalósítás irányában ható tényezőket tartalmazza, mintegy előretekintő jelleggel. Szervezés: a feladatok és az erőforrások gyakorlati összehangolását jelenti. Modell: az optimum-kritériumoknak megfelelő terv. Modellezés: az optimum-kritériumok

betartására irányuló erőfeszítés. Minden modell terv, de általánosságban nem minden tervet tekintünk modellnek. Csak azt a tervet tekintjük modellnek, amely megfelel a tudatos elemzés során betartott kritériumoknak. Szervezetek strukturálási módjai. • Rendszerstrukturálási elvek: o Implicit tagolás o Földrajzi tagolás elve o Eszközök szerinti tagolás elve o Szervezeti elv szerinti tagolás - 51 - o Funkcionális elv szerinti tagolás o Ismereti elv szerinti tagolás Szervezetek strukturálása: • Rugalmatlan, statikus formák o Lineáris: Jól árrekinthető, egyszerű. Minden beosztottnak egy főnöke van Az utasítás és a jelentés ugyanazon a vonalon, a szolgálati úton történik. Kisebb vállalaroknál o Törzsegységi: E szervezeti forma kialakulásának indoka: a vezető túlterheltségének csökkentése, a szakmai színvonal növelése A lineáris szervezet kiegészül egy törzsegységgel, különféle szakmák szakértőivel, akiknek

utasítási joguk nincs, feladatuk a tanácsadás a vezetőnek. o Funkcionális: Az egyes szakterületek önálló szervezeti egységben jelennek meg • Speciális szakértelem szükségessége esetén alkalmas • Problémás a más egységekkel való közreműködés • A többvonalas irányítás miatt koordinációs problémák o Divízionális: Alapvető egységei a nagy önállósággal rendelkező divíziók • Szervezésének alapelvei: termék, piac, területi elv. Stratégiai döntés a vállalati központ kezében, az operatív pedig a divízióknál • Rugalmas, dinamikus formák o Divízionális o Mátrixos: Alapvető munkamegosztásból tagoltság két fajtája együtt jelenik meg (pl. funkció és termék) • Többvonalas irányítás • Konfliktusok magas szintje Átvilágítás, diagnosztizálás: • • • • • • • Átvilágítási módszerek céljai o A vállalat résztvevőivel megismertetni a szervezetük adottságait, körülményeit o A

feltárt problémákkal összhangban megtervezni a szervezetfejlesztés irányát o A szervezet résztvevőinek egyetértését és a megoldásra vonatkozó elkötelezettségét kialakítani Vállalatátvilágítás módszerei o A bankfunkció céljait szolgáló átvilágítási módszer o A tulajdonosi funkciókat szolgáló átvilágítási módszer o Az üzemeltetési funkciókat szolgáló átvilágítási módszer Átvilágítás és diagnosztika o Átvilágítást rendszerszervezést megelőzően használjuk o Átvilágítás egészséges vállalatot feltételez o Átvilágítás feladata a struktúra feltárása a szervezeti résztvevők együttműködésének megteremtésével o Diagnosztizálás alapvetően a vállalati egyensúly létrehozására irányul A szervezet diagnosztizálása o A diagnosztikai tényezők együttes vizsgálatára van szükség o A diagnosztizálás bonyolult és időigényes feladat o Célszerű a szervezetet felbontható rendszerként kezelni, és

ennek megfelelően diagnosztizálni o A tünetek észlelését és mérését meg kell oldani o A diagnosztizálás a szervezet anatómiájára épüljön, de az adott szervezet egyedi jellegét is vegye figyelembe A szervezet diagnosztizálásának célja o Jól és teljes körűen észlelje a szervezet betegség tüneteit o A tünetek alapján körül tudja határolni a szervezeti betegséget o A diagnózisból következzen a lehetséges és valós terápiák menete, a szervezet fejlődésének, tovább lépésének stratégiai irányai A szervezet diagnosztikai tényezői o Melyek a vállalkozás deklarált és tényleges céljai o Mi a vállalkozás üzleti filozófiája és stratégiája o A célok, a filozófia és a stratégia milyen módon és mértékben felelnek meg a piaci igényeknek o Milyen a vállalkozás piaci helyzete, státusza o Milyen a vevők helyzete, igényeik o Milyen a szállítók köre és viszonya a vállalkozáshoz o Mekkorák a vállalkozás költségei,

az állandó és a változó költségek szerkezete o Milyen a vállalkozás pénzügyi helyzete, likviditása o Milyen a vállalkozás vagyoni helyzete o Mekkora a vállalat jövedelemtermelő képessége, tőkeereje o Milyen a vállalkozásban az ösztönzési rendszer o Milyenek a munkavégzés fizikai, szociális és szervezeti feltételei o Mennyire jól hasznosítja a vállalkozás a saját erőforrásait (állóeszközök, pénzeszközök, anyagok, ember) o Milyen a vállalkozás vezetésének stílusa, módszerei, színvonala o Milyen a szervezeten belüli munkamegosztás o Milyen a szervezeten belül alkalmazott szervezeti forma o Milyen a vállalkozás hatalmi szerkezete, miként alakulnak érdekviszonyai o Milyen gazdasági társasági formában működik a vállalkozás Diagnosztika és informatika: o A szervezet diagnosztizálása csak helyes rendszerszemlélet alapján történhet o A megfelelő diagnosztizálás is megfelelő rendszerelemzési–informatikai ismeretek

alapján történhet o A vállalat diagnosztizálása több területen átfedéseket mutat az informatikai szempontból végzett rendszerelemzésekkel - 52 - 21. Egy választott, mai rendszerfejlesztési (szoftverfejlesztési) módszertan felépítése és szerepe a szoftvertechnológiában. Adat- és folyamatmodellezés Lásd a 2. tételt Adat- és folyamatmodellezés (SSADM technikák) Az SSADM (Structured Systems Analysis and Design Method) Strukturált Rendszerelemzési és Tervezési Módszertan rövidítése • • A rendszerfejlesztés folyamatában több helyen is használják o helyzetelemzéshez o döntési mechanizmusban o igényelt rendszer specifikálásánál Termékei: o Fizikai adatfolyam diagram o Logikai adatfolyam diagram A technika célja Az adatfolyam-modellezés célja általában véve az, hogy egy adott információs rendszerről átfogó képet nyújtson, együtt ábrázolva a rendszer folyamatait és adatait, azaz részletesebben: • A

rendszerhatárok kijelölése • A rendszer külső objektumainak meghatározása • Kifelé és befelé áramló főbb információk meghatározása • Belső információ-áramlás • Információ-tároló helyek meghatározása • Információt feldolgozó, átalakító folyamatok meghatározása Az adatfolyam-modellezés konkrét céljai az elemzés különböző fázisaiban: • • • • Jelenlegi fizikai: A követelmények azonosítása (hiányosságok, új funkciók). Jelenlegi logikai: Továbbvihető logikai folyamatok azonosítása, a rendszerszervezési alternatívák kiindulópontja. Rendszerszervezési alternatíva: A felhasználói döntés előkészítése, átfogó kép kialakítása a lehetőségekről. Igényelt rendszer: Funkciók, események meghatározásának kiindulópontja. Az adatfolyam-modell többszintű, hierarchikusan elrendezett adatfolyam-ábrák és a hozzájuk kapcsolódó elemi folyamatok leírásai, külső egyedek leírásai és

bemenet/kimeneti leírások összessége. Minden adatfolyam-modellhez tartozó termék esetén meg kell jelölni az adott adatfolyam-modell változatát (jelenlegi fizikai, jelenlegi logikai, rendszerszervezési alternatíva, igényelt) A technika leírása Az adatfolyam-modellezési technikát az elemzés legkorábbi fázisaitól kezdve a követelményspecifikáció elejéig (az igényelt rendszer adatfolyam-modelljéig) lehet használni. A technika lépései: Jelenlegi fizikai adatfolyammodell Közös fogalmakat alakít ki a működési területről a felhasználók és elemzők között, elsősorban a problémák, hiányosságok azonosítására szolgál. Racionalizálás - Logikai adatfolyam-modell Egy jelenleg létező fizikai rendszer valószínűleg hosszú idő alatt alakult ki és olyan kényszerítő körülményeknek kellett megfelelnie, mint: • elavult berendezések • földrajzilag szétszórt elhelyezkedés • történelmileg kialakult szervezeti viszonyok Az

elemzőnek egy logikai képet kell adnia a jelenlegi rendszerről, ami nem tartalmazza a jelenlegi adat- és folyamat-ismétléseket és a felhasználó által meghatározott funkcionális területek szerinti szerkezetben tartalmazza az elemi folyamatokat. A logikalizálás tevékenységei, ennek megfelelően a következők: • Adattárak racionalizálása: meg kell szüntetni az adatok többszörös tárolásából következő redundanciát, a fizikai utalásokat. Minden fő adattárba tartoznia kell egy vagy több egyednek a logikai adatszerkezetről. Egy egyed pontosan egy adattárba tartozhat csak, de minden egyednek tartoznia kell valamilyen adattárba. Az átmeneti adattárakat általában meg kell szüntetni, mivel sokszor fizikai kényszerűségek miatt léteznek, és általában megfeleltethetők egy fő adattár valamely állapotának (pl. még nem könyvelt zárási adatok). • Elemi folyamatok racionalizálása: o Egy folyamatnak a fő működés feladatai miatt kell

adatot elérnie vagy átalakítania, a megvalósítás módjától függetlenül. Ki kell hagyni ezért a technikai jellegű sorbarendezéseket a folyamatok közül. o Egy logikai folyamatnak azt kell tükröznie, hogy mi történik, nem azt, hogy hol, vagy ki által. o Ha egy folyamat kizárólag megjelenítés vagy nyomtatás miatt nyúl az adatokhoz, akkor meg kell szüntetni, de fel kell venni egy megfelelő lekérdezést a követelményjegyzékbe. - 53 - o Ha az adatok nem változnak meg egy folyamat működése által, akkor azt a folyamatot egy adatfolyammal kell helyettesíteni. o Ha két vagy több folyamat mindig egyszerre vagy sorozatban következik, akkor össze kell vonni őket, ha lehetséges. o Ha egy olyan folyamat létezik, ami csak azért kell, mert az adatokat több különböző helyről kell összeszedni, akkor azt meg kell szüntetni. o Ha egy folyamat leírása olyan részt tartalmaz, ami szubjektív döntést igényel, vagy ember által végezhető, akkor

azt a folyamatot ketté kell bontani, létrehozva egy külső egyedet és egy adatfolyamot az emberi tényező ábrázolására, és megtartva a belső feldolgozást, mint folyamatot o Ha egy folyamat olyan működési elemet tartalmaz, ami más folyamatokban is előfordul, azt mindenhonnan ki kell emelni egy közhasznú elemi folyamat leírásba és minden felhasználó folyamat leírásában hivatkozni kell rá. • Elemi folyamatok újracsoportosítása: a hierarchiát újból fel kell építeni, hogy megszűnjön a jelenlegi szervezeti és fizikai kényszerűségeknek megfelelõ csoportosítás. Az új csoportok kialakításánál a következõket kell figyelembe venni: o A felhasználók által kialakított funkcionális csoportok. o Hasonlóságok az elemi folyamatok típusában. o Ugyanazon adatcsoportokat használó folyamatok. • Ellentmondásmentesség és teljesség ellenőrzése: ellenőrizni kell, hogy az átalakított adattárak, folyamatok és adatfolyamok továbbra is

megfelelnek-e a rendszer feladatainak, illetve a jelölésrendszer megfelelõen lett-e átalakítva (azonosítók, felbomlások, elnevezések stb.) Rendszerszervezési alternatívák kialakítása A rendszerszervezési alternatívák kialakítása az első lépés az új rendszer körvonalazására. Általában minden új rendszer kialakításának többféle lehetősége van, ezeket körvonalazzák az egyes alternatívák. Rendszerint egy felső szintű adatfolyam-ábrával és esetleg néhány bonyolultabb folyamat esetén második szintű ábrákkal ábrázolják az alternatíva által ajánlott új rendszer kiterjedését és határait. Az alternatívákhoz tartozó adatfolyam-ábrák általában logikaiak, de ha az alternatívák között szerepel a jelenlegi, kézi rendszer fenntartása is például, akkor a hozzá tartozó adatfolyamábra tartalmazhat fizikai utalásokat. A megfelelő (esetleg több elemből összetett) alternatíva kiválasztása után az igényelt rendszer

leírását el lehet kezdeni. Igényelt rendszer adatfolyam-modellje A választott rendszerszervezési alternatíva adatfolyam-ábráit ki kell egészíteni az új, eddig nem ábrázolt működésekkel a követelményjegyzék alapján, illetve a mögöttes leírásokkal, a logikai adatfolyammodellből kiindulva. A funkciók alkotják a rendszer azon folyamatait, amelyek az adott működési terület eseményeit dolgozzák fel. Más szóval a felhasználók által működési egységnek tekintett folyamatokat nevezzük funkciónak. A funkciókat az elemi folyamatok szintjén kell azonosítani, meghatározva azt a bemenő adatfolyamot, amelyen a működést kiváltó esemény érkezik a rendszerbe, követve az útját azokon a folyamatokon keresztül, amelyeknek le kell zajlania, hogy az adott bemenő adatok fel legyenek dolgozva és a kimenetet elő lehessen állítani. Az igényelt rendszer adatfolyam-modellje akkor támogatja a funkciók meghatározását, ha a következőket

biztosítja: • Minden elemi folyamatnak csak egy vezérlő bemenete van. Ha esetleg több is lenne, akkor azok kölcsönösen kizáróak • Lehetőség szerint minimális a folyamatok közötti adatáramlás • Nincsenek hibakezelést modellező folyamatok, mivel ezt későbbi technikák írják le Az eseményeket kezdetben az adatfolyam-modell által leírt bemenő adatfolyamok és a hozzájuk tartozó adatelem felsorolás (B/K leírás) alapján lehet azonosítani. Később az egyedtörténeti elemzés tárhat fel további eseményeket Mindkét esetben az eseményeket meg lehet határozni adatelemek formájában is. A következőket kell figyelembe venni, hogy az adatelemek és az események között meg lehessen találni az összefüggést: • Egy adatfolyam-típus események kötegét szállíthatja, azért, hogy a rajz egyszerűbb legyen. Ezek az események a valós életben érkezhetnek azonnali vagy kötegelt formában. • Egy bemenő adatfolyam jelenthet használható

eseményt. • Egy bemenő adatfolyam tartalmazhat nem hasznáható esemény köteget (azaz olyat, amelyet az ábra áttekinthetősége miatt alakított ki az elemző). Az igényelt rendszer adatfolyam-ábráin általában kétfajta külső egyed szerepel. Az egyik az egész rendszerre nézve külső, a másik az automatizált rendszerre nézve külső, de egyébként a rendszerhez tartozik. A második fajta külső egyedek a rendszer felhasználói szerepköreit jelentik és egyértelműen meg kell tudni feleltetni őket a felhasználói szerepkör-jegyzék elemeinek. Kapcsolat megteremtése: A jelenlegi logikai adatmodellel meg kell teremteni a kapcsolatot egy megfelelően (át)alakított logikai adattár- egyed megfeleltetés létrehozásával. Az így létrejövő jelenlegi rendszer adatfolyam-modell az utolsó lépés az adatfolyam-modellezés használatában Termékek A technika által létrehozott vagy módosított termékek a következők: • Adatfolyam-modell Az

adatfolyam-modell a következő termékekből épül fel: o Kontextusábra o Adatfolyam-ábrák (hierarchikus halmaz) o Elemi folyamatok leírása: Azokat a folyamatokat írják le, amelyek tovább már nem bomlanak, tehát az ábrák alapján részleteikben nem értelmezhetők. A cél az, hogy a későbbi funkcióleírást ki lehessen alakítani Az elemi folyamat leírásának utalnia kell az elérendő adatokra, a működési szabályokra ("ha a folyószámlán szereplő összeg a kivét hatására nulla alá menne, akkor a Kivét folyamatnak ezt vissza kell utasítania"), a különböző lehetséges bemenetekre • • - 54 - vonatkozó működési szabályokra ("A felvételi utalvány hatására a folyamat ellenőrzi a folyószámlát és kiadja a nyugtát, az egyenleg lekérdezés hatására a folyamat kiírja a folyószámla egyenleget"). o Külső egyedek leírása o Bement/ Kimenet leírások Adatjegyzék: Minden olyan elemi adatról, ami a

rendszerhatárokat átlépő adatfolyamokon utazik, egy adatelem-leírást kell készíteni. Ebben az adatelem nevén kívül olyan információk kapnak helyet, amelyek az elemzés során kiderülnek, mint például ellenőrzési szabályok, alapértékek, számított értékek számításának módja, esetleg az adatelem mérete, példaértékek felsorolása. A több adatfolyamban is szereplő adatelemeket természetesen csak egyszer kell leírni, ez az egyik fő célja ennek a terméknek. Logikai adattár-egyed megfeleltetés: Ez a termék a logikalizálás után minden adattárhoz hozzárendeli a kapcsolódó logikai adatmodellbeli egyedeket. Ábrázolás Külső egyedek g Engedélyez ismétlõd küls egyede { a Postabont a Banki felboml küls egyede } a Folyószámlavezeté g Engedélyez A külső egyedek olyan objektumok, amik a rendszeren kívül vannak, és onnan információt kapnak vagy oda információt továbbítanak. Ezek lehetnek munka- illetve szerepkörök, mint

Raktáros, külső szervezetek, mint MNB egy bank esetében. A külső egyedeket egy fektetett ovális jelöli. Minden külső egyedet egy kisbetű. Ha egy ábrán egy külső egyed sok információáramláshoz kapcsolódik, akkor meg lehet sokszorozni, hogy a vonalak kereszteződését megakadályozzuk. Ilyenkor az összes előfordulást egy ferde vonallal meg kell jelölni. Egy felső szintű ábrán szereplő külső egyed egy alsóbb szintű adatfolyamábrán felbomolhat. Ilyenkor az azonosító betűt ki kell egészíteni egy sorszámmal. Pl "c - Vezető" felbomolhat: "c1 - Osztályvezető", "c2 - Csoportvezető" külső egyedekre Folyamatok Folyamat azonosító folyamat neve Elemi folyamat 3 Foly.sz vez hely Folyószámla zárás 2.1 Folysz vez Terhelési tételek rögzítése tovább nem bomlás jele A folyamatok olyan átalakító tevékenységek, melyek a bemenő adatokat kimenő adatokká alakítják. A folyamatokat egy doboz jelöli,

a felső részén két kisebb, elválasztott területtel (azonosító és hely). Minden folyamatnak van egy azonosító sorszáma, de ez nem utal semmilyen sorrendiségre. Minden folyamatnak van egy neve, aminek lehetőség szerint egy aktív tevékenységet kifejező ige képzős alakját kell tartalmaznia. Jó nevek például: "Számla összeállítás". " A fizikai modell folyamatain meg lehet jelölni a fizikai helyet is, ahol az a folyamat végbemegy, ami általában egy szervezeti egység, vagy egy munkakör neve lehet. A folyamatok felbomolhatnak, ami tulajdonképpen az adatfolyamábrák hierarchiáját kialakítja. A felső szinten szereplő folyamatok mindegyikéhez lehet rajzolni egy külön ábrát, ami az adott folyamat egyszerűbb alfolyamatait ábrázolja. A tovább nem bomló folyamatokat a jobb alsó sarokban csillaggal kell jelölni. Ezek lesznek az elemi folyamatok Adattárak Az adattárak azok a helyek, ahol az adatok nyugvópontra jutnak a

rendszeren belül. Egyik végén nyitott téglalap jelöli őket Egy azonosítóval és egy névvel rendelkeznek. A rajz áttekinthetősége miatt ugyanazon adattárat meg lehet ismételni Ilyenkor minden egyes előfordulást egy függőleges vonallal meg kell jelölni. A fizikai rendszer adattárai konkrét helyeket jelölnek, pl Iratgyűjtő, Iktató könyv vagy egy adott számítógépes adatállományt (ha létezik). A logikalizálás után az adattárak már semmilyen fizikai tárolásra történő utalással nem rendelkezhetnek. Kétféle adattár lehet: Az adattárakat egy betű és egy tetszőleges egyedi szám azonosítja. • Főadattár o M – manuáéis, kézi adattár o D – számítógépes • Átmeneti adattár o T o T (M) – manuális Adatfolyamok A rendszerben mozgó információt az adatfolyamok fejezik ki, amiket nyilak jelölnek. A felső szintű ábrán csak a fontosabb adatáramlásoknak kell megjelenni, a részletek az alsóbb szintű ábrákon fejezhetők

ki. - 55 - A rendszerhatárt át nem lépő, ún. információ áramlás is jelölhető az ábrákon, szaggatott nyíllal Ez természetesen csak külső egyedek között lehet, és akkor érdemes használni, ha az ábrát érthetőbbé teszi. Minden adatfolyamhoz tartozhat egy név, ami röviden utal a tartalmára. Az adatok a rendszeren belül csak egy folyamat hatására mozoghatnak, azaz nem létezhetnek közvetlenül adattárak közötti, illetve külső egyedek és adattárak közötti adatfolyamok. Anyagáramás A fizikai anyagok áramlásának kifejezésére két objektum típus szolgál. Az egyik az anyagáramlás, ami egy belül üres, esetleg névvel ellátott széles nyíllal van jelölve. A másik az anyagtár, amit egy zárt téglalap jelöl Irodaszerek Raktár DFD hierarchia Egy adott ábrának áttekinthetőnek kell lennie és azonos szintű részleteket kell mutatnia. Egy rendszer viszont általában bonyolult és különböző szintű részletességgel lehet

leírni. Ezek után egy ábra általában nem elegendő a rendszer ábrázolására, ezért egy hierarchikus ábra-halmazt érdemes használni. A felső szint az 1. szintű adatfolyam-ábra nevet viseli Ezen az ábrán lehet meghatározni a rendszer kiterjedését, azaz a külső információ forrásokat illetve információ felhasználókat, a fő bemenő és kimenő adatokfolyamokat és a rendszer alapvető működő részeit, valamint a rendszer határait. A rendszer határait nem szükséges külön megjelölni, az 1 szintű ábrán a külső egyedek jelölik ki a határokat. Minden olyan folyamatot, ami a felső szintű ábrán szerepel és további részleteket tartalmaz, egy-egy alsóbb szintű ábrával lehet kifejezni. Általában három szintű adatfolyam-ábra elegendő, a további részletek már nem szolgálják a technika elérendő céljait (funkciók, események azonosítása)