1.) Algoritmus és program fogalma, jellemzői. Az algoritmus-tervezé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 nyelven.

Ha egy feladatot kell megoldanunk, akkor ezt általában több részfeladatra bontjuk fel, és melyekben különböző
műveleteket végzünk el, feltételeket értékelünk ki, és jutunk el célunkhoz. A feladat elemzése során határozhatjuk meg
azokat a lépéseket és döntési pontokat, melyeken keresztül végül elérhetjük a kívánt eredményt. Ezt a lépéssorozatot
szokás algoritmusnak nevezni.

Algoritmusnak nevezzük egy feladat megoldását eredményező véges számú lépésben véget érő, egyértelmű
szabályokkal megfogalmazható műveletsorozatot.

Ha egy algoritmust a számítógép által értelmezhető és végrehajtható lépésekből építünk fel, akkor ezt programnak
nevezzük, ennek elemi lépéseit pedig utasításnak.

Az algoritmus-tervezés helye és szerepe a programban:

Az algoritmus kigondolása után, grafikus megjelenítési formát ölt a tevékenységdiagramban. Itt mindenek előtt ügyelni
kell az átláthatóságra. Ebben a szakaszban az analizálás és az tervezés közti fázisok átjárójában függünk. Ilyenkor a
megoldandó feladatok és feladatokon belüli részfeladatok összetevőinek minden eshetőségét figyelembe véve kell
eljárnunk. A következő fázisban megjelenő pszeudokódnál még sokkal kötetlenebb formában történik az ábrázolás,
meghatározott grafikus objektumokkal. Ha egy munka ebben a fázisban félrecsúszna, az azt jelenti, hogy a tervező
képtelen átlátni a megoldandó feladatot.

A programban betöltött szerepe szerint az alkotásunk (programunk) tevőleges része az algoritmus, vagyis ezek az
elemek végzik a munkát a program többi részén, megfelelő döntési, választási, kritériumok alapján. Minden algoritmus
kommunikál a külvilággal, azaz figyelembe veszi a felhasználó utasításait, valamint a programban szereplő nyersanyag
(adatok) összességét, és így állít elő kimenetet, eredményt, amik összessége alkotja programunk működését. Ösvény
önzésem kevésbé

Algoritmusok építő elemei:

Az algoritmus belépési pontja – adat beviteli/kilépési pontok –

értékadási események – feltételek elágazási pontok - a lépések
sorrendjei - az algoritmus kilépési pontja.

Algoritmuslépések és programok kapcsolata:

Egy szoftver bonyolultságának kezelésre alapvetően két módszer

áll rendelkezésünkre:
• absztrakció: amikor kiemeljük a feladat szempontjából
lényeges dolgokat, a többit pedig figyelmen kívül
hagyjuk.
• Dekompozíció: segítségével a feladatot részekre,
modulokra bontjuk, mivel az egészet egyszerre nem
tudjuk áttekinteni. A részfeladatokat meg kell oldani majd
újra össze kell állítani.

Ennek módszertana amit elveken keresztül formálhatunk rendszerré, a moduláris programozás nevet viseli.

A teljes program modulokból áll, az egyes modulok kezelhető méretűek, egyértelmű céljuk van, és jól
meghatározhatóan csatlakoznak környezetükhöz. Ennek irányelvei:
• oszd meg és uralkodj
• az adatok elrejtése
• a döntések elhalasztásának kerülése, illetve kimondása
A modulokra bontás lehet felülről lefelé (top-down), és lehet alulról felfelé (bottom-up).

Egy programfejlesztési módszertan útmutatást ad a program elkészítésének módjára vonatkozóan. A módszertan

segítséget nyújt az adatok (objektumok) és algoritmusok meghatározásában, a program modulokra bontásában, a
modulok elkészítésében, majd összeállításában. A módszertanhoz rendszerint tartozik egy grafikus jelölésrendszer.

Programvezérlési szerkezetek egy választott programozási nyelvben:

Szekvencia: egymás utáni tevékenységek sorozata, a szekvenciát a nyilak irányában felsorolt egymás utáni
tevékenységek alkotják.

Szelekció: programelágazást jelent, egy adott ponton a tevékenységek végrehajtása feltételektől függ a feltételek le kell
fedjék a továbblépés lehetőségeit, a feltételesen végrehajtható tevékenységek számától függően szokás egyágú, kétágú
és többágú szelekcióról beszélni.

Iterációk: meghatározott tevékenységek ismételt végrehajtása, ezeket ciklusmagnak is nevezzük. Az ismétlődés előtt
van egy kiszállóág ami kilépést enged egy feltétel teljesülésekor. Két változata van, az elöl és hátul-tesztelő változat a
hátul-tesztelő változat mindenképpen végrehajt egy ciklust, míg az elöl-tesztelő csak abban az esetben, ha a nem teljesül
egy feltétel. Ezen kívül van a léptető ciklus a ciklusmag végrehajtásakor az ebben szereplő ciklusváltozó lép egyet.
 2.) Szoftverkezelési módszer és módszertan. A vízesés összehasonlítása az inkrementális és iterációs
módszerekkel. A RUP objektumelvű fejlesztési módszertan lényes jellemzői (életciklus szemlélet, felépítés).
Nézetek és modellek, kapcsolatuk.

A program elkészítésének módszere az az eljárás aminek alapján kielemezzük és megoldjuk az elénk tornyosuló
feladatokat, a módszertan az az eljárás és feladatmegoldási megközelítések halmaza, amik lehetővé teszik a feladatok
eltérő szempontok alapján alapján való megközelítését, valamint teszi az adott feladat egy szabadabb megközelítését.

Kezdetben a strukturált programozás volt a meghatározó, lényege, hogy a programot felülről lefelé, funkcionálisan,
vagyis működése szerint egyre kisebb lépésekre (modulokra, eljárásokra) bontják. A program tervezés olyan speciális
strukturált módszer, ahol a programszerkezetet a bemenő és kimenő adatszerkezetek összefüggéséből állítják fel.
Ezeknek a módszereknek megmutatkoztak a korlátai, mivel az így készülő programokat gyakran csak maga a készítő
látta át és a csapatmunka kivitelezése igen korlátolt volt.

A strukturált fejlesztéssel járó szoftverkrízist az objektumorientált (OO) szemlélet hivatott feloldani. Napjainkban már
szinte kizárólag objektumorientált szoftverfejlesztési módszereket és szoftvereket használnak a fejlesztők. Az OOo-ban
a dekompozíció alapja az objektum, melyben az adatok és programrészek egyaránt fontos szerepet játszanak.

Vízesés modell:

A Waterfall Modell a követelményelemzés, a tervezés, az implementáció és az integráció szigorúan egymás utáni

végrehajtására épül. Az egyes tevékenységek végrehajtásának befejeződését mérföldkőnek (milestone) nevezzük,
amelynek elérését a hozzá tartozó dokumentum elkészülése jelzi.

A vízesés modell fázisai:

• követelményanalízis és definíció
• rendszer- és szoftvertervezés
• implementáció és részegységek tervezése
• részegységek integrálása és rendszer
tesztelése
• működtetés és karbantartás
• a vízesés modell legfőbb hátrányai:
• a rendszer beindulása után nehéz
változásokat beépíteni
• egy munkafázisnak be kell
fejeződnie mielőtt a következő
elindulhatna

A vízesés modell problémái:

• nehéz a változó megrendelői igényekhez igazodni, mert a projekt nehezen változtatható részekből áll.
• Ez a modell akkor hasznos, ha a követelmények jól ismertek és csak nagyon kis változások lehetségesek a
fejlesztés során.
• Sajnos csak kevés üzleti rendszernek vannak stabil követelményei.
• A vízesés modell főleg nagy rendszerek fejlesztése során használják, ahol a fejlesztés több helyszínen történik.

Inkrementális módszer:

A feladatok összetettsége miatt minden szoftver-fejlesztés során célszerű egyértelműen megfogalmazni a fejlesztés
mérföldköveit, hogy világosan látható legyen a mérföldkövek közötti fázis során elérhető cél. A fázisok ugyancsak
további elemekre bonthatóak amelyek az inkrementumokat megvalósító iterációs lépések lesznek.

Iteratív és inkrementális fejlesztés esetén a teljes fejlesztési folyamat nem vízesésszerűen, egyetlen nagy egységben
történik. Ehelyett minden belső kis fejlesztési ciklus esetén először „szervezünk egy keveset, elemzünk, tervezünk,
implementálunk egy keveset, majd integrálunk és tesztelünk egy keveset”. Az iterációs ciklusokban a rendszer egyre
bővülő részeit fejlesztjük ki. A „bővítmények”, azaz az inkrementumoknak a rendszerhez való kapcsolódása így nem a
teljes fejlesztés végén, egyetlen nagy lépésben történik, hanem azt a fejlesztés során folyamatosan kell végrehajtani.

Az iteratív és inkrementális rendszerfejlesztési eljárás legfontosabb előnyeit a következőkben foglalhatjuk össze:

• a fejlesztés kritikus és lényeges kockázatai hamarabb azonosíthatók,
 • a megfelelő architektúra könnyen kialakítható,
• segíti a változó követelményeknek megfelelően, könnyebben módosítható keretrendszer kialakítását
• a munkatársak hatékonyabban vehetnek részt a fejlesztésben.

Az URP más, objektumorientált rendszerfejlesztési eljárásokhoz a három legjellemzőbb tulajdonsága alapján

hasonlítható. Az Objektory örököseként egy ún. használati eset vezérelt eljárás, amely azt jelenti, hogy a fejlesztés teljes
folyamata során a használati eseteket eszközrendszerét, illetve az azzal kialakított modellt alkalmazzuk a fejlesztés
ütemezésére.

A használati esetek önmagukban még nem adnak a teljes fejlesztési folyamathoz elegendő információt. A szükséges
többletet. A szükséges többletet a módszer a rendszer architektúrájaként nevezi meg, mely a rendszernek a fejlesztésben
részt vevő összes munkatárs által közösen kialakított vázát, leglényegesebb elemeinek gyűjteményét jelenti. Az URP a
fejlesztés teljes folyamatát kisebb részekre bontja, melyek önállóan is egy teljes fejlesztési folyamatot jelentenek. Az
egyes részeket iterációknak nevezzük, mivel a fejlesztést ismétlődő, iteratív ciklusokban hajtjuk végre. Egy iteráció nem
a rendszer egy , a korábbitól független részét állítja elő, hanem a rendszert újabb funkcionalitással bővíti, vagy a
korábbi funkcionalitást teszi változatosabbá, gazdagítja. Ez így egy iteratív és inkrementális fejlesztési módszer.

A célja a fejlesztőknek egy olyan lépéssorozat megadása, mellyel hatékonyan kifejleszthetik és telepíthetik azt a
rendszert, mely a felhasználók igényeinek megfelelő. A hatékonyság mérhető a költségek, a minőség és a fejlesztési idő
egységeivel. A felhasználói igények teljesítése és annak ellenőrzése azonban több problémában is nehéz, az
implementáció helyessége, a teljesítés ellenőrzése pedig a tesztelés feladatként jelenik meg.

Életciklus szemlélet, felépítés:

A fejlesztési idő alapján a fázisokat nagyobb egységeire bontjuk. Minden fázis a fejlesztés egy-egy jól meghatározott
mérföldkövét jelenti, azaz olyan pontot, ahol egy célt elértük, illetve ahol kritikus döntéseket kell meghozni. Minden
fázis végén megvizsgáljuk az elért eredményeket és döntünk a fejlesztés folytatásról. Minden fázis közbülső iterációkra
bontható, mely egy-egy teljes fejlesztést jelent, amelyek mind végrehajtható alkalmazást, a végső, teljes rendszert egyre
bővülő részeit eredményezik.
• Előkészítés: elsősorban üzleti szempontból írja le a fejlesztést és meghatározza az alkalmazás határait.
• Sikertényezők meghatározása
• kockázati tényezők felmérése
• erőforrás becslés
• projektterv dátumainak meghatározása
A fázis végén döntés a folytatásról.
• Kidolgozás: a problémát elsősorban szakterületi szempontból elemezzük
• megbízható architektúra kialakítása
• meghatározzuk a projekt-tervet
• megszüntetjük a legkritikusabb kockázati tényezőket
csak a teljes rendszer megismerése után hozható architeturális meghatározás, ezért szükséges, hogy használati
eseteket specifikálnunk kell (vázalatot csak úgy csinálhatunk, ha ismerjük a vázlatpontokat)
• Megvalósítás: során a teljes rendszert interaktív és inkrementális módon kifejlesztjük:
• specifikáljuk az elmaradt használati eseteket
• a tervezésre helyezzük a hangsúlyt
• kiegészítjük az implementációt
• teszteljük az elkészített alkalmazást
a fázis végére már működőképes szoftverünk van, melyről dönteni kell, hogy átadható-e a felhasználónak.
• Átadás:
• béta teszt
• szükséges lehet kiegészítők fejlesztése
• hibák kiküszöbölése
• hiányzó részek kifejlesztése

Nézetek és modellek:
 3.) A típus és változó fogalma. Egyszerű és összetett adattípusok. Adatok láthatósága az objektumokban.
Közvetlen és közvetett hivatkozású (referencia/dinamikus) változók. Az SQL adattípusai.

A típus és változó:

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. A változókat logikailag csoportosíthatjuk, vannak elemi változók és
összetett változók. Minden változónak van egy jól meghatározható típusa. A változó csak típusának megfelelően
kezelhető, és abba csak olyan értékek tehetők, melyek beletartoznak az adott típus értékkészletébe.

Az algoritmus változóit deklarálni kell: meg kell adni azok neveit és típusait. Egy változónak értékadási utasítással
adhatunk értéket.
Szinte minden programozási nyelvben megtalálhatóak a következő típusok:
• number: (szám). Például 45, 99.9 -1.2, 10000000
• boolean: (logikai). Értéke true (igaz) vagy false (hamis).
• String: (szöveg).
• Date: (dátum). Öszetett típus, 3 számból áll: év, hó és nap. Például 1972. 05. 12

A number és boolean típusú adatok primitív adatok, a String és a Date objektumok (összetett típusúak). Az UML és
Java szabvány szerint a primitív típusokat kisbetűvel, míg az összetett, objektumtípusokat nagybetűvel szokás írni.

Egy változót az algoritmus csak típusának megfelelően kezelhet. Egy szöveget nem lehet összeszorozni egy számmal,
de lehet például vágni belőle két karaktert. Két szöveget, két dátumot és két szöveget össze lehet hasonlítani egymással,
de egy dátum és egy valós szám már nem hasonlítható össze.

Az adatok láthatósága (hozzáférési mód védelem):

Az adatokat semmiféleképpen sem ajánlatos kívülről manipulálni, és léteznek olyan metódusok is amiket külső
felhasználók elöl el kell zárni, mivel ezek meghívásával hibát okozhatnak.
Az OO osztály deklarációinak lényegében háromféle láthatósága vagy hozzáférési módja van.
• Nyilvános (publik): 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ódusait férhetnek hozzá.
Az osztály deklarációt az elől kell vagy lehet védeni, aki az osztályt használni akarja. Egy kész osztályt lényegében
kétféleképpen lehet használni.
• Egy objektumnak kizárólag csak a publikus deklarációit lehet elérni. A privát és védett (protekted)
deklarációkat az osztály megszólításával nem lehet használni.
• Az örökítéskor az új osztályban felhasználjuk a már meglévő osztály adatait és metódusait. Az osztály írója
eldöntheti mely, mely adatokat és metódusokat engedi felülírni és melyeket nem. 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 public és védett
protected deklarációkat az utód osztály használhatja, hivatkozhat rájuk.
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: publikus osztály más
csomagokból is látható; alapértelmezésben egy osztály csak a saját csomagjában látható.

Az OO programozásban alapvetően két típus létezik: primitív és referencia típus.

• Promitív típus: egy primitív típusú változó azonosítójával közvetlenül hivatkozhatunk a változó
memóriahelyére. Ezt a helyet a rendszer a deklaráció utasítás végrehajtásakor foglalja le. A programozó nem
definiálhat primitív típust.
• Referenciatípus: a referencia típusú változók objektumokra mutatnak. Egy referencia típusú változó
azonosítójával az objektum memóriahelyére közvetve hivatkozhatunk egy referencián (hivatkozáson)
keresztül.

Az SQL adattípusai:
Bármilyen adat tárolására alkalmas. Az adatokon semmilyen
átalakítás nem történik (például szöveggé alakítás). Az adatok
BINARY karakterenként 1 bájt
kimenetként később is a bináris mezőbe való beíráskor megadott
formában jelennek meg.
Yes és No értékeket, valamint mindig két lehetséges érték egyikét
BIT 1 bájt
tartalmazó mezők.
TINYINT 1 bájt 0 és 255 közötti egész szám.
Rögzített tizedesjegyű számok a következő értékhatárok között:
MONEY 8 bájt
– 922 337 203 685 477,5808 és 922 337 203 685 477,5807
DATETIME
8 bájt A 100. és 9999. év közé eső dátum- vagy időpontérték.
(Lásd: DOUBLE)
UNIQUEIDENTIFIER 128 bit Egyedi azonosítószám távoli eljáráshívásokhoz.
Egyszeres pontosságú lebegőpontos szám a következő határok közt:
– 3,402823E38 és – 1,401298E-45 között negatív értékek esetén,
REAL 4 bájt
1,401298E-45 és 3,402823E38 között pozitív értékek esetén, illetve
0.
Dupla pontosságú lebegőpontos szám a következő határok között: –
1,79769313486232E308 és – 4,94065645841247E-324 negatív
FLOAT 8 bájt
értékek esetén, 4,94065645841247E-324 és
1,79769313486232E308 között pozitív értékek esetén, valamint 0.
SMALLINT 2 bájt Kisebb egész szám – 32 768 és 32 767 között.
INTEGER 4 bájt Nagyobb egész szám – 2 147 483 648 és 2 147 483 647 között.
Pontos numerikus adattípus, amelynek értékei 1028 - 1 és - 1028 - 1
között lehetnek. Megadhatja mind a pontosságot (1 - 28), mind
DECIMAL 17 bájt pedig a tizedesjegy-pontosságot (0 - megadott pontosság). Az
alapértelmezés szerinti pontosság és tizedesjegy-pontosság 18,
illetve nulla.
2 bájt/karakter (lásd
TEXT Nulla és 2,14 GB közötti terjedelmű.
a megjegyzést)
Nulla és 2,14 GB közötti terjedelmű. OLE objektumok esetén
IMAGE Szükség szerinti
használatos.
2 bájt/karakter (lásd
CHARACTER Nulla és 255 karakter közötti terjedelmű.
a megjegyzést)

MEGJEGYZÉS: A TEXT (más néven MEMO) vagy CHAR (más néven TEXT(n), megadott hosszúsággal) típusú
mezőkbe illesztett karaktereket a rendszer Unicodeábrázolási formában tárolja. Unicode ábrázolásnál minden karakter
tárolásához egyformán két-két byte-nyi helyre van szükség. A már létező, és többnyire karakteradatokat tartalmazó
Microsoft Access-adatbázisok esetében ez azt jelentheti, hogy az adatbázisfájl Microsoft Access formátumba történő
konvertálásakor a fájlméret közel kétszeresére nőhet. Sok karakterkészlet azonban – amelyeket korábban SBCS-nek
(Single-Byte Character Set) neveztek – Unicode ábrázolási módban könnyedén tömöríthető egyetlen bájtba. Ha CHAR
oszlopot COMPRESSION attribútummal definiál, az adattárolás során a program automatikusan tömöríti az adatokat,
amikor pedig lekéri őket az oszlopból, a rendszer automatikusan elvégzi a kibontásukat.
 4.) Az adatmodell alapelemei. Adatmodell típusok és jellemzőik. A relációs adatmodell fogalma, kulcsok
kategóriák, kapcsolatok felállítása. Az adatmodellek és a szakterületei modellek kapcsolata, összefüggéseik.
Az adatmodell alapelemei:
Az adatmodell egyedek, tulajdonságok és kapcsolatok halmaza, amely absztrakt módon tükrözi a valós objektumokat,
azok jellemzőinek (tulajdonságok) és viszonyainak (kapcsolatainak) elvont kategóriáit. Tehát ez egy séma, amelyben
megadjuk milyen tulajdonságok határozzák meg az egyedeket, milyen egyedek szerepelnek a sémában, és ezek között
milyen kapcsolatok vannak.
Alapelemei:
• egyed (egyedtípus): konkrét dolgok absztrakciója, konkrét dolgokat fog egybe. Az adatbázisok nézőpontjából
egyednek hívunk minden olyan dolgot (objektumot), ami minden más dologtól (objektumtól)
megkülönböztethető és amiről adatot tárolunk.
• tulajdonság (tulajdonság-típus): az egyedeket tulajdonságokkal írjuk le (attribútumokkal). A tulajdonság az
egyed egy jellemzője, ami ,megadja, meghatározza az egyed egy részletét. Amennyiben egy tulajdonság vagy
tulajdonságok egy csoportja egyértelműen meghatározza, hogy az egyed melyik értékéről, előfordulásáról van
szó (vagyis az egyedhalmaz melyik eleméről), akkor ezeket a tulajdonságokat együtt kulcsnak nevezzük.
• kapcsolat (kapcsolat- típus): az egyedek közötti viszony. A kapcsolat mindig valóságos objektumok közötti
viszonyt fejez ki, hiszen az egyed ilyen objektumokat képvisel. A kapcsolat is absztrakció két egyed értékei
(előfordulásai) közötti konkrét viszonyokat fejez ki. A konkrét kapcsolatokat a kapcsolat értékeinek
(előfordulásainak) nevezzük.

Adatmodell típusok és jellemzőik:

Hálós adatmodell: szerkezetét gráffal adjuk meg. Ebben a gráfban a csomópontok az egyedek, az élek pedig a
kapcsolatokhoz egyedek, az élek pedig a kapcsolatot fejezik ki. Az egyedeket tulajdonságaikkal írják le. A hálós
adatmodell két évtizeden át egyeduralkodó volt. Az ezen a modellen
alapuló adatbázis-kezelő rendszerek beépülő típusú nyelvek voltak, a
behívó nyelv a COBOL, PL1 volt.
A hálós adatmodell adatbázisában az egyedek (tehát előfordulásaik)
közötti kapcsolatot listaszerkezettel adják meg. A legfejlettebb az
IBM gépeken működő IDMS volt

A hierarchikus adatmodell:
A hierarchikus adatmodell szerkezetét szintén a gráffal adjuk meg, de a gráf speciális, nevezetesen fa. A téglalapok itt is
egyedeket jelentenek és a nyilak a kapcsolatokat fejezik ki. A hierarchikus adatmodellre épülő adatbázisok kezelésére
számos rendszert dolgoztak ki, legelterjedtebb az IMS amely IBM gépeken futott.

A relációs adatmodell:
A relációs adatmodell más filozófiára épül mint, az előbbi kettő. Ennél az adatmodellnél a három adatmodellelem közül
a kapcsolat nem játszik szerepet, pontosabban szólva a kapcsolat nem, csak a lehetőség épül be az adatmodellbe. A
relációs adatmodellben a tulajdonságok kapják a fő hangsúlyt, a tulajdonságokkal definiáljuk az adatmodell szerkezetét.
Ellentétben az előző kettővel.
A relációs adatmodellben az egyedet egy táblázattal adjuk meg, a táblázat oszlopai a tulajdonságok. A sorai pedig az
egyed értékei (vagyis a táblázat maga az egyedhalmaz). A relációs adatmodellben létrehozott adatbázisokat több
táblázattal adjuk meg (minden tábla egy adathalmaz), de a táblázatok közötti kapcsolatokat nem definiáljuk az
adatmodell felírásakor. Ez nem jelenti, hogy nincsen köztük kapcsolat, de ezek az fejezi ki, hogy két táblának közös
oszlopa van.
A relációs adatmodell:
A relációs adatmodell lényegében oszlopokba szedett adatok együttesem melynek oszlopai tulajdonságtípusok, halmaz
elméleti megközelítésből pedig attribútum halmazok direkt (Descartes) szorzatának részhalmaza. Az attribútumok
(oszlopok) számát az R reláció fokának, a sorok számát. Pedig a reláció számosságának nevezzük.
Kulcsok kategóriák:
A reláció kulcs a reláció egy sorát azonosítja egyértelműen. A reláció nem tartalmazhat két azonos, ezért minden
relációban létezik kulcs, ami a következő feltételeket kell kielégítse:
• az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelműség)
• a kulcsban szereplő attribútumok egyetlen részhalmaza sem alkot kulcsot
• a kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL)
Egy ilyen táblázatban a kulcs lehet egy azonosító szám, vagy valamely olyan jellemzője a relációknak amik
egyértelműen azonosítják a sorokat.

Az egy attribútumos kulcs egyszerű kulcs, mikor pl. minden vevőhöz egy vevőazonosító szám tartozik és ezt használjuk
kulcsként. Ha a kulcsunk egyetlen attribútumból áll, akkor a
kulcsot egyszerűnek nevezzük, ha nem ilyen akkor összetett. Az
nyilvánvaló, hogy egy relációban mindig van kulcs (esetleg a
teljes attribútumhalmaz). Az is világos, hogy egy relációnak több
kulcsa is lehet. A reláció attribútumai közül azokat, amelyek
legalább egy kulcsban szerepelnek, elsődleges attribútumoknak, a
többieket másodlagosnak nevezzük.
Nemcsak összetett kulcsok fordulhatnak elő a relációban, léteznek olyan relációk is melyekben nem csak egy, hanem
több kulcs is található. Ennek illusztrálására nézzük meg a következő relációt KONZULTÁCIÓ=({TANÁR,
IDŐPONT, DIÁK})

KONZULTÁCIÓ
Tanár Időpont Diák

A konzultáció relációban a tanári illetve a diák oszlopban olyan azonosítót képeztünk, mely a személyt egyértelműen
azonosítja (például személyi szám). Mindebben egyes diák több konzultációban vehet részt, minden tanár több
konzultációt tarthat, sőt ugyan az a diák ugyanannak a tanárnak más-más időpontban tartott konzultációin is részt vehet.
Ezekből következik, hogy sem a tanár, sem a diák, sem pedig ez a két azonosító együtt nem kulcsa a relációnak. De
egy személy egy időben csak egy helyen tartózkodhat. Ebből következik, hogy a tanár, időpont attribútumok kulcsot
alkotnak, de ugyanilyen okból kifolyólag a diák, időpont attribútumok is kulcsot alkotnak.
A kulcsok nem önkényes döntésekből alakulnak ki, hanem az adatok természetéből fakadnak, mint funkcionális vagy
többértékű függőség.
Egy relációban külső kulcsot vagy kulcsokat is megkülönböztetünk. Ezek az attribútumok nem az adott relációban,
hanem az adatbázis másik relációjában alkotnak kulcsot. pl. ha a KNZULTÁCIÓ relációban a DIÁK azonosítására a
személyi számot alkalmazzuk, akkor ez egy külső kulcs a személyi adatokat nyilvántartó relációhoz.
A kapcsolatok felállítása:
Amikor attribútumok egy csoportja függ az attribútumok egy másik csoportjától, vagy mikor a kulcs és a reláció többi
attribútuma között funkcionális összefüggés áll fenn. Akkor olyan esetek állnak fenn amik a valós világban meglévő
függőségeket fejeznek ki. pl. egy személy neve, születési időpontja, helye, egy repülőjárat száma, indulási időpontja,
érkezési helye.
Fajtái: egy-egy típusú, egy-több, és több-több típusú kapcsolatokat különböztetünk meg a kapcsolatok számai szerint.

Szakterületi modell: felállításához lényegében csak szakterületi tudásra van szükség, nem kell hozzá speciális
számítógépes ismeret. A szakterületi modellt a „csak” a saját területéhez értő szakember is érti.
 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.
A rutin (eljárás) egy körülhatárolható és egyedi névvel azonosítható olyan összetett tevékenység, ami a körülhatárolt
feladat megoldására hivatott. Ez azért lehetséges, mert az elvégzendő feladatok részeikre bontva esetenként
tipizálhatóak, s így rögzített megoldás alkotható hozzá a rutinban foglaltak szerint. Másként, egy összetett
tevékenységhalmaz.
• Meghívható a nevére való hivatkozással
• lehetnek paraméterei
• lehet visszatérési értéke.
Az olyan rutint ami egy adott feladat ellátása után visszatérési értéket nem ad eljárásnak, míg az olyat ami visszatérési
értéket ad függvénynek nevezzük.
Metódus: OO- programozásban minden metódusnak van egy feje és egy blokkja. A blokk összefogja a benne található
utasításokat. Mindaz, amit abban a blokkban adunk meg, pontosan arra a blokkra érvényes. Ahol egy utasítást
megadhatunk ott egy blokkot is. Szokás a blokkot összetett utasításnak is nevezni.
A metódusok írásával az objektum illetve osztály feladatait részekre bonthatjuk, azokat külön-külön megnevezhetővé
tehetjük. Amikor egy objektumnak üzenetet küldünk, akkor egy olyan metódus kerül végrehajtásra, amely az üzenetnek
egyértelműen megfeleltethető. Az osztályban deklarált metódusok egymást is hívhatják.
Eljárások, függvények: egy adott probléma megoldásának során célszerű, ha programunk jól elkülönített, zárt
részprogramokból épül fel.
Az eljárás (rutin) tevékenységek (utasítások) összessége. Melyet meghívhatunk az eljárás nevére való hivatkozással.
Az eljárás egy olyan alprogram, amely egy előírt műveletsort végez el. Az eljárással több eredményt is előállíthatunk.
Eljárást akkor írunk ha:
• egy-egy hasonló feladatot többször akarunk elvégezni a programban,
• a program átláthatóbbá válik ettől.
Az eljárás szerkezete nagyon hasonlít a programéhoz. Az eljárás kötelezően a Procedure szóval kezdődik, majd az
eljárás azonosítója végül a paraméterek következnek. Az eljárást még hívása előtt deklarálni kell.
Előnyök:
• módosításkor, javításkor csak egy helyen kell belenyúlni a programba,
• az általános célú eljárásokat később újra fel lehet használni.
A függvény (return) sokban hasonlít az eljáráshoz, a különbség csak annyi, hogy a függvény mindig egy értéket ad
vissza egy előre meghatározott típus szerint. A függvény egy olyan programrész, amely adott bemeneti paraméterekből
egyetlen értéket számít ki, és azt hozzárendeli az azonosítóhoz. Értékadás nélküli függvény definiálatlan lesz. Míg az
eljárás hívása utasításként viselkedik, a függvényt kifejezésekben használhatjuk.

Paraméter-átadás, átvétel:
A szubrutinok paraméterek segítségével kommunikálnak környezetükkel ill. eredményüket is e paraméterek
segítségével adják vissza. Az eljárások, függvények fejlécben felsorolt paramétereket RORMÁLIS paramétereknek
nevezzük. Azokat a paramétereket, amelyekkel az eljárást vagy függvényt meghívjuk AKTUÁLIS paraméternek
nevezzük, amelyet az eljárás vagy függvény ténylegesen átvesz, azaz az értékkel rendelkező formális paraméterek. A
formális és aktuális paraméter darabszámának és páronként típusának meg kell egyeznie.
A paraméter átadás/átvétel szempontjából megkülönböztetünk értékparamétert (érték szerint átadott) és változó (cím
szerint átadott) paramétert. Az értékparaméter értéke nem változtatható meg az eljárásban, míg a változó paraméterek
értéke igen.
A cím szerinti paraméter-átadáson azt értjük, hogy az aktuális paraméterek a tárban is ugyanazon a címen találhatók.
Így az alprogram az ezeken a változókon végrehajtott bármilyen műveletet megváltoztatja a hívó programban az ezeken
a változókon végrehajtott bármilyen művelet megváltoztatja a hívó programban is ezen változók értékeit. Az ilyen
típusú paraméter-átadás deklarálásakor a paraméter előtt a 'var' szó áll. A paraméter csak változó lehet.
A paraméter-átadás másik módja az érték szerinti paraméter-átadás lehet. Ez azt jelenti, hogy az aktuális és a formális
paraméterek külön helyet foglalnak a tárban, más változókat jelentenek. Ezek a változók az adott eljárásban lokális,
tehát értékeik megváltoztatására nincs hatással az aktuális paraméterekre. A paraméter lehet konstans vagy kifejezés is.
Lefutása után a szubrutin az általa lefoglalt memória területeket felszabadítja.
Példány és osztálymetódusok:
Az objektum mindig a saját adatain dolgozik, az metódusokat pedig az osztály leírásából „nézi ki”. Minden metódus
példányában megtalálható a hozzá tartozó osztály leírásában szereplő összes adat, azok példányonként más-más értéket
vehetnek fel. A metódusokat azonban elegendő csak egyszer, az osztályban tárolni, azok majd a megfelelő objektum
adataitól függően fognak dolgozni.
Az osztály azon metódusait, amelyek példányokon dolgoznak, példánymetódusnak nevezzük.
Vannak adatok, amelyek nem konkrét példányra, hanem az egész osztályra jellemzőek. Ilyen például az adott
osztályhoz tartozó, „élő” példányok száma, vagy egy olyan tulajdonság, érték, amely minden objektumra egyformán
jellemző. Ezek az osztályváltozók, amik az osztály összes példányára nézve azonosak.
Osztálymetódusnak nevezzük az olyan metódust, amely objektum nélkül is tud dolgozni. Az osztálymetódus a
példányadatokat nem éri el, az csak az osztályváltozókat manipulálhatja. Egy osztálymetódus meghívható az osztálynak
adott üzenettel.
A példányadatokat csak a példánymetódusok érik el, míg az osztályváltozót egyaránt elérik a példánymetódusok és az
osztálymetódusok. Ennek az az egyszerű oka, hogy egy objektumhoz mindig tartozik osztály, de ez fordítva nem igaz:
előfordulhat, hogy egy osztálynak az adott pillanatban nincsen egyetlen előfordulása sem.
Eseménykezelő metódusok:
Az eseményvezérelt programozás, olyan forma, amely eseménykezelő és egy szétosztó mechanizmuson alapszik. Az
objektumok a hozzájuk érkezett eseményeket, eseménykezelő metódusokkal kezelik.
Automatikus kódgenerálás és kódszinkronizáció: a vizuális tervezés és a kód szinkronizálásának könnyebb
megvalósítása érdekében a Delphi átveszi a kódadminisztráció jelentős részét. A kód alapegysége az űrlap és az ezt
reprezentáló TForm osztályból származó osztály. A párbeszédpanel elemeinek a kódbeli kapcsolatát ennek az
osztálynak a mezőiben valósítja meg, míg az eseménykezelő metódusok az űrlap osztály metódusai lesznek. Ezek
adminisztrációját a Delphi automatikusan végzi. Tehát mikor egy új elemet helyezünk a párbeszédpanelre, a rá
vonatkozó meződeklaráció automatikusan létrejön a kódban. Ha ezt a komponenst eltávolítjuk, a komponens referencia
is eltávolításra kerül. Hasonló a helyzet új eseménykezelő metódus létrehozásánál is. Ekkor egy üres törzsű metódust
hoz létre a Delphi. Metódusokat viszont csak akkor törül a program, ha annak törzse üres. (Ekkor a rá történő
referenciákat is törli, de csak a komponensen.)
Függvények az SQL-ben:
Az SQL szabványok nem írják elő pontosan, hogy milyen függvényeket kell beépíteni az SQL nyelvbe. A különféle
SQL relációk sok függvényt tartalmaznak. Általában igaz, hogy az egyes SQL megvalósulások kezelik az őket behívó
nyelv függvényeit. A függvény szerkezete: függvénynév (argumentum).
Aggregáló függvények: különböző számításokat végez a megadott mezők alapján.
COUNT: megszámolja az oszlopnév alapján megadott oszlop elemeinek a számát. A DISTINCT módosító
esetén csak a különbözőket számolja meg.
SUM: összegzi a numerikus típusú oszlop értékeit.
AVG: a numerikus értékek átlagát képezi.
MIN: a minimális értéket adja vissza
MAX: a maximális értéket adja vissza.
Predikátumfüggvények: a WHERE parancs feltételében használhatjuk őket
Kif1 BETWEEN kif2 AND kif3: igaz értéket vesz fel, ha kif1 kif2 és kif3 közé esik.
Oszlopnév IN (értéklista): igaz, ha az oszlop értéke eleme a listának.
Oszlopnév LIKE érték: igaz, ha az oszlop értéke megegyezik a LIKE utáni kifejezéssel.
Egyéb : (nem feltétlenül vannak)
Stringmanipuláló függvények
Konverziós függvények
 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

Egy kifejezés operandusokból és operátorokból áll, a kifejezésben szerepelhet egy vagy több operandus, és bármelyik
operandus lehet maga is egy kifejezés. Vannak egy-, illetve kétoperandusú operátorok. Az operandus lehet: változó,
literál, függvényérték, kifejezés (zárójelben vagy zárójel nélkül).

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:
• először a zárójelekben található kifejezések értékelődnek ki (belülről kifelé)
• ezen belül előbb mindig a nagyobb prioritású művelet hajtódik végre.
• Ha a műveletek prioritása egyforma, akkor a művelet asszociativitásától függően jobbról balra vagy balról
jobbra történik a kiértékelés.

Ha két különböző precedenciájú között van az operandus, akkor a magasabb precedenciájú operátorhoz tartozik, tehát
először azt a műveletet kell végrehajtani (pl. ha a kifejezés 6*2+2, akkor előbb szorozni kell 6 tal, majd hozzáadni 2-t).
Ha két azonos precedenciájú operátor között van az operandus, akkor a tőle balra álló operátorhoz tartozik és azt a
művelet kerül először végrehajtásra (pl. a kifejezés 6+7+2, akkor a 7-hez előbb hozzáadunk 6-t, majd 2-t).
Ha a művelet zárójelben van, akkor a zárójelben lévő műveletek kiértékelésének van elsőbbsége.
Precedenciaszabályok szintjei:
1. szint - Prefix műveletek: legmagasabb prioritása a + és – előjeleknek van, valamint a NOT műveletnek, ezek
egy operandusú műveletek.
2. szint - Multiplikatív műveletek: DIV, MOD a szorzó műveletek értékelődnek ki
3. szint – Additív műveletek: +,-, or, xor, az összeadó műveletek.
4. szint – Relációs műveletek: <, =, >, legkisebb prioritása a hasonlító műveleteknek van.

Egy választott programozási nyelv aritmetikai, logikai és relációs műveletei

A Java nyelvben minden operandusnak van egy jól meghatározható típusa. Minden operandushoz tartozik egy szabály
arra vonatkozólag, hogy milyen típusú operandus állhat a bal, illetve a jobb oldalán. Az adott művelettől és annak
operandusaitól függően a művelet eredményének is jól meghatározható típusa lesz.
Egy operátor lehet:
• unáris: melynek egy operandusa van, ilyen pl. a negatív képzés. Ez lehet az operandus előtt (prefix) és után
(postfix)
• bináris: melynek két operandusa van, pl. egy összeadás x+y.
Aritmetikai műveletek:

A Java programozási nyelvben sokféle aritmetikai operátor áll rendelkezésre a lebegőpontos és egész számokhoz. Ezek
az operátorok a + (összeadás), - (kivonás), * (szorzás), /
(osztás) és % (maradékképzés).

Amikor egy aritmetikai operátor egyik operandusa egész, a

másik pedig lebegőpontos, akkor az eredmény is
lebegőpontos lesz. Az egész érték implicit módon
lebegőpontos számmá konvertálódik, mielőtt a művelet
végrehajtódna. A szükséges konverziók még a művelet végrehajtása előtt végre fognak hajtódni.

A táblázat összefoglalja az aritmetikai operátorok értékét

az adattípusok függvényében.
A ++ operátor növeli az operandus értékét, a – pedig
csökkenti eggyel.

Relációs operátorok:
A relációs operátorok összehasonlítanak két értéket, és meghatározzák a köztük lévő kapcsolatot. Pl. a != true-t ad, ha a
két operandus nem egyenlő. A relációs operátorok:

Logikai operátorok:

A relációs operátorokat gyakran használják logikai operátorokkal együtt, így összetettebb logikai kifejezéseket
hozhatunk létre. A Java programozási nyelv hatféle logikai operátort – öt bináris és egy unáris – támogat- ahogy azt a
következő táblázatban látható:

Kifejezések az SQL-ben:

Az SQL a kifejezések szerkezete és tartalma tekintetében megegyezik más nyelvekkel.

• Aritmetikai kifejezések: numerikus vagy dátum típusú oszlopnevekből, változókból konstansokból, műveleti
jelekből (+, -, *, /, **) és zárójelekből állnak. Szerepelhet bennük aritmetikai függvény is.
• Karakter kifejezések: karakter típusú oszlopnevekből, változókból, szöveg konstansokból, műveleti jelből (+, a
konkatenáció jele) és zárójelekből állnak. A szöveg konstansokat idézőjelek vagy aposztrófok közé tesszük.
• Logikai: logikai típusú oszlopnevekből, változókból, konstansokból, műveleti jelekből ( AND, OR, NOT,
relációs operátorok <>= ) és zárójelekből állnak.
 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 kapcsolta az adatbázis-modellel.

Az objektum információt tárol és kérésre feladatokat hajt végre. Az objektumot üzenetek által lehet megkérni a
feladatok elvégzésére. Az objektum felelős feladatainak korrekt elvégzésért. Minden objektum egy adott
viselkedésminta szerint működik. Egy objektumnak vannak adatai és metódusai (operációi) 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 objektumok egyértelműen azonosíthatóak.

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 osztály-objektum viszony a hagyományos típus-változó viszony objektumorientált megfelelője. Ahogyanegy

(hagyományos) változóhoz hozzátartozik a típusa, amely meghatározza a változó értékkészletét és a rajta végezhető
műveleteket, éppen úgy az objektumhoz is hozzátartozik annak osztálya (azaz a típusa), amely leírja a benne tárolt
adatokat és a vele végezhető műveleteket.

Egy objektum születésekor annak osztálya egyértelműen meg van határozva. Ettől kezdve az objektum a
szabályoknak megfelelően él, egész életében „tudaj”, hová tartozik.

Egybeágyazás:

Bezárás, információ elrejtése ( encapsulation ): A bezárás az adatok és metódusok összezárását, betokozását jelenti.
Az információ elrejtése azt jelzi, hogy az objektum elrejti adatait, azt csak az interfészen keresztül lehet megközelíteni.
Így más programrész nem tudja elrontani az objektum belsejét, és az objektumban esetlegesen keletkezett hiba nem tud
átterjedni más programrészekre. Ehhez a következő szabályok betartása szükséges:
• az objektum csak olyan üzenetekre reagál amire beprogramozták
• csak interfészen keresztül lehet megközelíteni
• interfész rész a lehető legkisebb legyen
• az adatok csak metódusokon keresztül legyenek elérhetők.
Az obejktum működésébe beleszólni nem lehetséges.

Osztály definiálása egy választott fejlesztő környezetben.

Az objektumnak életciklusa van. Minden objektum egyszer „megszületik”, aztán „él”, végül „meghal”. Születésekor az
objektumba be kell táplálnunk a kezdeti adatit – amíg egy objektumnak nincsen állapota, addig azt semmilyen feladatra
nem lehet rábírni.
• Be kell állítani kezdeti adatait;
• végre kell hajtani a tevékenységeket, amelyek az objektum működéséhez feltétlenül szükségesek.

Az objektumot létre kell hozni, és inicializálni kell. Az inicializálást elvégző metódust konstruktornak nevezzük.

A Javában az objektumot a new (új) operátorral hozzuk létre. Az operátor után meg kell adni az osztály nevét (milyen
osztályból kívánjuk létrehozni az objektumot). Mivel az osztály neve egyben a konstruktor neve is, az objektum
automatikusan inicializálódik.

Ha az objektumra már nincsen szükségünk, akkor azt meg kell szüntetni, el kell pusztítani. A Javaban nem kell
foglalkozni az objektumok megszüntetésével, memóriahelyük felszabadításával; azok automatikusan megszűnnek, ha
nincs rájuk semmiféle hivatkozás.

Properties: olyan publikus adat, melyet már a tervezési időben is állíthatunk.

Az osztálymodell kapcsolata az adatbázis- modellel.

OO adatbázis kezelő rendszerek segítségével az objektumokat adataikkal és viselkedésével együtt prezidens módon
(maradandóan, a programot túlélve) lehet tárolni, és azokat különböző szempontok szerint visszakeresni.
Egy relációs adatbázis kezelő rendszer megbízható, használata egyszerű; nem beszélve arról, hogy lekérdező nyelve, az
SQL szabványos

Osztálymodell:
 8.) Objektum és osztályok közötti kapcsolatok. A kapcsolatok implementálása. Öröklődés, polimorfizmus,
virtualitás.

Az ember az objektumokat automatikusan rendszerezi, s azokat a számára fontos tulajdonságok alapján kategóriákba,
osztályokba sorolja. Alapvetően két fajta kapcsolat létezik:
• Ismertségi, más néven használati kapcsolat: akkor áll fenn két objektum között, ha azok egymástól függetlenül
is képesek létezni, vagyis egyik léte sem függ a másiktól. ( ilyen például a kutya és a ház, hiszen ha a kutya
elszökik, attól a ház megmarad, legfeljebb nem őrzi azt a házat senki. Ha pedig a ház összedől, akkor a kutya
egy új házat fog őrizni)
• Tartalmazási, más néven egész-rész kapcsolatról akkor beszélünk, ha az egyik objektum határozottan része a
másiknak, mégpedig úgy, hogy ha az
A kapcsolat jellegének megállapítása természetesen nem minden esetben egyszerű. Az objektum információt tárol, és
kérésre feladatokat hajt végre. Az objektum felelős feladatainak korrekt elvégzéséért. Az objektum logikailag
összetartozó adatok és rajtuk dolgozó algoritmusok összessége. Egy OO- program egymással kommunikáló objektumok
összessége, melyben minden objektumnak megvan a jól meghatározott feladatköre.

Üzenet (kérelem): az objektumokat üzeneteken keresztül kérjük meg különböző feladatok elvégzésére. Egy objektum
csak akkor küldhet üzenetet egy másik objektumnak, ha azzal kapcsolatban áll, vagyis ismeri vagy tartalmazza az
üzenetet fogadó objektumot.

Objektumok közötti kapcsolatok

Objektum jelölése:

Objektum neve
Tulajdonságai
Tevékenységei

Az objektumok csak úgy tudnak együttműködni, ha kapcsolatban állnak egymással. Alapvetően kétféle kapcsolat
létezik:

Társítás (association): elemek közötti strukturális kapcsolat.

Jelölése folytonos vonal, a nyíl iránya jelzi a kapcsolat irányát.
Ha nincs nyíl, a kapcsolat kétirányú. A vonal fölé, illetve alá írhatjuk a kapcsolat nevét.

Ismeretség: Két objektum ismeretségi (használati) kapcsolatban van egymással, ha azok léte egymástól független, és
legalább az egyik ismeri, illetve használja a másikat. Amelyik objektum használni akarja a másikat (kliens objektum),
annak tartalmaznia kell egy referenciát (mutatót) a megszólítandó (szerver) objektumra. Az ismertségi kapcsolatban álló
objektumok közül bármelyik megszüntethető. Ha az objektumok kölcsönösen használják egymást, vagyis a kliens-
szerver szereposztás váltakozik, akkor mindkét objektumban fel kell vennünk a másikra vonatkozó referenciát. Az
ismeretségi kapcsolatban álló objektumok közül bármelyik megszüntethető, csak arra kell vigyázni hogy a “túlélő ”
objektum a továbbiakban ne hivatkozzon a “meghaltra”. Pl. a nyomtatót használó két alkalmazás ismeri a nyomtatót,
egyik megszűnésekor a másik objektum nyomtathat

Tartalmazás: két objektum tartalmazási kapcsolatban van egymással, ha az egyik objektum fizikailag tartalmazza vagy
birtokolja a másik objektumot. Az egész objektum tartalmazza a rész objektumot, az egész objektum megszűnése maga
után vonja részének megszűnését. A tartalmazási kapcsolat erősebb, mint az ismeretségi. (pl. kutya: fej,lábak törzs) az
egész objektum mindig ismeri részét.
Kompozíciónak nevezzük azt a tartalmazást, ahol az egész rész létrehozásakor összeáll a végleges kompozíció, és
később nem vehető ki belőle egyetlen rész sem (erős tartalmazás)
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.

Függőség (dependency): logikai kapcsolat. Az egyik (független) dolog változása maga után vonja a másik (függő)
dolog változását.

Általánosítás (generalization) – öröklés: osztályszerű elemek közötti strukturális kapcsolat.

Megvalósítás (realization): egy dolog megvalósít (realizál, implementál) egy másikat. Logikai kapcsolat mely az
általánosítás és függőség keveréke. Csak osztályszerű elemek között lehetséges.

Osztályok közötti kapcsolatok

Alapvetően 3 kapcsolatot különböztetünk meg, melyek lehetnek opcionálisak vagy kötelező jellegű (megengedhető
társnélküliség). Osztályok számának (multiplicitás) feltüntetése felsorolással (* jelenti a tetszőleges számút). Ha 0 is
lehet, akkor az előfordulás opcionális, egyébként kötelező.
• Egy-egy kapcsolat: az egyik osztály egy példánya a másik osztály legfeljebb egy példányával áll kapcsolatban. A
másik osztályra ugyanez vonatkozik. (Pl. Férfi és Nő házastársi viszonya).
• 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. (Anya-Gyerek,
Ország-Város).
• Sok-sok kapcsolat: a sok-sok kapcsolatban mindkét osztály akármelyik példánya a másik osztály sok példányával
állhat kapcsolatban. (Pl. Tanfolyam-Hallgató, Hallgató-Hallgató (*)).
S o k O b jek tu m 1

1 1 ..5
E g y O sz tály S o kO sz tá ly E g yO b jektum S o k O b jek tu m 2
h aszná lja
S o k O b jek tu m 3

O sztá lyd iag ra m P éld án ydia g ra(Omb jek tum d iag ra

) m

Öröklődés, örökítés
/kódolási könnyebbség/
Egy már meglévő osztály továbbfejlesztése. A már meglévő osztály az ős osztály, a továbbfejlesztett osztály pedig az
utód osztály. Az utód osztály az ős osztály specializálása. Az ős osztályból úgy származtatunk újabb osztályt, hogy az
ős osztály tulajdonságaihoz (adatok), ill. képességeihez (metódusok) újabbakat adunk, vagy a meglévőket felülírjuk. A
származtatás több szinten át folytatódhat.
Egyszeres öröklés: egy osztálynak csak egy őse lehet. (pascal)
Többszörös öröklés: egy osztálynak több őse is lehet, melyet ki lehet váltani egyszeres öröklődéssel. (c++)
Szabályok:
- egy osztályból több is származtatható,
- az öröklődés tranzitív Ha A örökli B-t, B örökli C-t akkor A örökli C-t
- bármely metódus ismeri és használhatja a saját osztályában és felette levő osztályokban deklarált összes adatot és
metódust
 UtódOsztály1 ŐsOsztály UtódOsztály2

Mezők Mezők Mezők

Metódusok Metódusok Metódusok

Polimorfizmus (többalakúság)
Azt jelenti, hogy ugyanarra az üzenetre különböző objektumok különbözőképpen reagálhatnak; minden objektum a
saját, az üzenetnek megfelelő metódusával. (Az üzenet küldőjének nem kell tudnia a fogadó objektum osztályát).

Virtuális metódus : olyan metódus, melynek címet a program később, futási időben oldja fel. A virtuális metódusokkal
elérjük, hogy mindig az aktuális objektum osztályának a metódusa fog futni.

Virtuális metódus:
Az objektumokkal történő munka során szükség lehet arra, hogy az utód osztály metódusait megváltoztassuk. Erre ad
lehetőséget a virtuális metódusok használata. A virtuális metódusokkal átdefiniálható az ősosztály azonos nevű
metódusa, így csak a futás közben dől el, hogy éppen melyik metódust kell használni.

Virtuális Metódusok Táblázata (VMT)

Minden egyes, virtuális metódusokat tartalmazó osztályhoz tartozik egy VMT. A virtuális metódusok címét a program
futáskor ebből a táblázatból veszi. Az objektum példány egy VMT mezőt tartalmaz, mely az osztály VMT-jének relatív
címét tartalmazza (mérete 2 bájt). A példány VMT hozzárendelést a konstruktor végzi a példány létrehozásakor, illetve
inicializálásakor.
Ha az osztály használ virtuális metódust, akkor van egy VMT mezője, mely a virtuális metódus tábla címét tartalmazza.
 9.) A felhasználható felület, az alkalmazáslogika és az adatbázis logikai szerepe, az ezeket realizáló objektumok
sztereótípusai. Az egyes alkalmazás-rétegek jellemző komponensei egy választott fejlesztő eszköz esetében.

Felhasználói felület: kapcsolat a felhasználóval, adatmegjelenítés, stb. Részei: menü, ablakkezelés, súgó.
Minden adatbázis kezelő rendszerben három fő funkcionális egységet különböztetünk meg:

• Közvetlen adatkezelés: ez végzi az adatok funkcionális feldolgozását.

• Alkalmazás-logika: ez felelős a teljes alkalmazás helyes működéséért. Adatvédelem, hatékony és kényelmes
adatkezelés (tranzakció stb.)
• Alkalmazáslogika: a szoftverrendszer harmadik komponense az alkalmazáslogika, mely a rendszer magjaként
a feladat specifikus műveletek végrehajtására szolgáló algoritmusokat foglalja magába. Az alkalmazáslogika
implementálása magas szintű, gyakran objektumorientált programozási nyelv szolgál. Nagyon sokféle nyelvre
alapul 4GL környezetek. Így például a Delphi az Objekt Pascal-ra a Visual C++ a Java-ra.

Az alkalmazáslogika rétege az adatbázisra vonatkozó szabályok összességét tartalmazza. Gyakorlatilag ebbe a rétegbe
tartoznak azok a funkciók, műveletek amelyek meghatározzák egy adatbázis működését. Ilyen szabályok a mező illetve
rekordszintű ellenőrzések (mezőszintű ellenőrzés pl. ha egy tanuló eredményeinek felvitelekor a program csak egy és öt
közötti értéket enged felvinni), a hivatkozási függőségek ellenőrzése (pl. egy könyvet csak akkor lehessen eladni ha az
szerepel a könyvesbolt árukészletében) stb.

Adatbázis logika:

Logikai típusú oszlopnevekből, változókból, konstansokból, műveleti jelekből (AND, OR, NOT) zárójelekből áll.
A logikai kifejezésekben itt is szerepelhetnek a relációs operátorok (<, >, =, stb.)

Objektumok főbb sztereótípusai:

• határ (interfész) objektum: A külvilággal kapcsolatot teremtő objektum (pl. menü, ablak, nyomógomb stb.)
• kontroll objektum: vezérlést, számolást végrehajtó objektum. (pl. egy folyamatvezérlő vagy egy statisztikai
adatgyűjtő objektum)
• egyed objektum: a rendszer lényegi részeit alkotó objektumok. Az egyed objektum egy valós világbeli
személy, dolog, hely, fogalom, vagy esemény.
• Konténer objektum: a különböző kapcsolatok megvalósítására szolgál. Ha a kapcsolat foka jól behatárolható,
akkor statikus adatszerkezetek is használhatok, mint pl. a tömb. Ha a kapcsolat foka változó, akkor valamilyen
dinamikus szerkezetet kell használnunk, mint a lista, vagy a kollekció. Az adatbázisok saját konténerrel
rendelkeznek.

Komponensek ( az újrafelhasználható kód): szabályos, újrafelhasználható szoftver építőelemek (forrás, bináris, vagy
futtatható kód), melyeket applikációk fejlesztéséhez használnak. Komponensek lehetnek például osztályok, vagy azok
egy csoportja:
• interfész osztályok: pl. nyomógomb, a listadoboz, a menü vagy a párbeszédablakok.
• Konténer osztályok: pl. a lista, tömb, fa, halmaz vagy szótár.

A komponensek egyszerűbb nyelvi elemekből épülnek fel, melyeket aztán beépítenek az alkalmazásba. Azért
használjuk őket, mert egyrészt az alkalmazás fejlesztésének ideje drasztikusan lecsökkenti, másrészt növeli az
alkalmazás minőségét.

Az egyes alkalmazásrétegek jellemző komponensei

Az alkalmazói program egy olyan program, amelyet egy adott számítógépes környezetben, kifejezetten egy speciális
feladat elvégzésére készítettek. Egy tipikus alkalmazói program következő elemeket tartalmazza:
• felhasználói felület: az alkalmazás azon része, mely az ember-gép kapcsolatot biztosítja. Részei: menü,
ablakkezelő, súgó.
• Eseményvezérelt programozás: az esemény egy olyan történés, amely megváltoztatja valamely objektum
állapotát. Az eseményvezérelt programozás olyan programozás, amely egy eseménybegyűjtő és szétosztó
mechanizmuson alapul. Az objektumok a hozzájuk érkezett eseményeket eseménykezelő metódusokkal
lekezelik.
• Adatbázis kezelés: vannak olyan objektumok, amelyeket hosszabb időre el szeretnénk tárolni. A program
futását túlélő objektumokat rezidens objektumnak nevezzük. Ezen objektumok tárolását és manipulálását az
adatbázis kezeli végzi: adatok központi paraméter tárolása, több felhasználó kiszolgálása, integritás,
 helyreállítás, adatvédelem, lekérdezések.
• Kivételkezelés: a kivétel egy esemény vagy feltétel, melynek bekövetkezése megszakítja a program normál
futását. A kivétel objektum tárolja azt az információt, hogy milyen kivétel történt, és hol. A kivételes eseményt
a program átadja az ún. kivételkezelőnek, amely azt lekezeli. A kivételkezelő a kivételes esemény esemény
(általában hiba) bekövetkezése esetén megpróbálja a programot megmenteni az összeomlástól: vagy elhárítja a
hibát, vagy visszaállítja a rendszert egy előző stabil állapotba.
• Szemétgyűjtés: a hivatkozatlan dinamikus változók automatikus kitakarítása a memóriából.

OO szoftverfejlesztési eszközök

A vizuális fejlesztőeszközök segítségével a fejlesztő a program nagy részét nem forráskód írásával készíti, hanem
interaktív módon, a fejlesztőrendszer eszköztára által felkínált vizuális elemek kiválasztásával, azok tulajdonságainak
beállításával. A forráskód vázát a fejlesztőeszköz generálja, a fejlesztő pedig kiegészíti.
 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özzel.

Manapság szinte minden program eseményvezérelt és felhasználói interfésze grafikus. A felhasználói interfész
komponensei a képernyőn látható objektumok, mint a keret, a nyomógomb vagy a beviteli mező. A komponensek
programozásához nem-komponens, láthatatlan osztályokat is felhasználhatunk, mint a pont, a téglalap, a szín és a
betűosztályok.

Alapvetően két módszert használhatunk az OO-programok tervezésekor. Az egyik felhasználja az operációs rendszer
natív (gépi kódú) GUI interfészeit, ebben az esetben a programunk az operációs rendszerre jellemző külsővel
büszkélkedhet( Java-ban az AWT osztályok a java.awt csomagban találhatóak). A másik esetben az adott OO-orientált
paradigma már nem használja a natív elemeket, hanem saját megírt kereteket alkalmaz, de a natív komponensek nem
látható elemeit is felhasználva. Ez lassabb működéssel jár, de a fejlődő teljesítmények ezt fokozatosan háttérbe
szorítják. Ezt a Java-ban Swing osztálynak nevezzük és a java.swing csomagban kapott helyet.

Komponensek:
Ablak: egy olyan objektum, amely egy objektumnak valamilyen nézetét mutatja. Maga az ablak komplex
objektumként többfajta objektumból áll. Az ablak részei: keret, címsor, menüsor, eszközsor, állapotsor, gördítősáv stb..

Menü: a menü segítségével tud a felhasználó a lehetséges opciók közül egyet kiválasztani.

Kurzorok: alakja segítséget nyújt a felhasználónak.

Képernyővezérlő elem (Control): a képernyővezérlő elemek jelentik azt az alapvető eszközt, amellyel információt
jeleníthetünk meg a képernyőn, illetve fogadhatjuk a felhasználói adatokat. Példák a Java környezetből:
• Jlabel (címke): információ megjelenítésére használható komponens.
• Jbutton (nyomógomb): a rajta való kattintás egy eseményt indíthat el.
• Jlist (lista): a lista elemei nem szerkeszthető elemsorok, melyekből az elemek kiválaszthatók. A kiválasztott
elemek lekérdezhetők.
• JtextFiled (szövegmező): adatbeviteli mező. Szöveget lehet bevinni a program számára.
• JscrollBar (görgetősáv): a görgetősáv egy értéktartományt reprezentál. A sáv két végén egy-egy nyíl, a rajta
pedig egy csúszka található. A csúszka pillanatnyi helyzete mutatja az értéktartomány aktuális értékét.
• JradioButton (rádiógomb): a rádiógombokat konvencionálisan egymástól függő bejelölésekre használják.
Ilynkor a gombokat gombcsoportokba kell foglalni, hatására az egyik gomb bejelölése kiugrasztja a benyomott
gombot (a rádió gombjához hasonlóan).

Vannak olyan komponensek, amelyekre újabb komponensek tehetők, ezeket konténer komponenseknek nevezzük –
ilyen például az alkalmazás kerete és a dialógusablak. Más komponensek tovább nem bonthatók, ezek a vezérlő
komponensek – ilyen például a nyomógomb és a szövegmező. A felhasználói interfész komponenseinek egy jól
meghatározott tulajdonosi (tartalmazási) hierarchiája van.

A tulajdonosi viszony:
1. Konténer és komponense: a keret, a dialógusablak és a panel konténerek. A konténer olyan komponens,
amely más komponenseket tartalmaz, azokat összefogja és felügyeli. A konténer elemei sosem kerülhetnek a
konténeren kívülre. A konténer a neki szóló üzeneteket általában saját komponenseinek is továbbadja:
áthelyezéskor komponensei is vele mennek, átméretezéskor komponensei is megváltoztatják méretüket. Egy
konténer megszűnése maga után vonja összes komponensének megszűnését. A konténerbe egy komponenst
annak add(component) metódusával tehetünk be.
2. Ablak és ablaka: egy alkalmazás legfelső szintjén egy (esetleg több) keret áll. Több keret esetén a keretek
különálló életet élnek, azok mind az alkalmazás felügyelete alá tartoznak. A keret birtokolhat egy vagy több
ablakot, de más keretet nem. A dialógusablak elhelyezkedése és mérete független a szülő ablaktól. Egy ablak
megszűnése maga után vonja az összes általa birtokolt ablak megszűnését.

A felhasználói interfész tulajdonosi hierarchiájának felépítéséről a programozó gondoskodik. Az a komponens, amely

nincs rajta a tulajdonosi hierarchián, az nem látható és nem képes eseményekre reagálni. A szülő komponens
megszűnése maga után vonja a gyerek komponens megszűnését.

A képernyőelemek elrendezése: az OO-tervezés során létrejött minden osztályt külön ablakba kell helyezni úgy, hogy
az elsődlegesnek ítélt osztálybeli objektumok elsődleges ablakokba, a kiegészítő objektumok pedig másodlagos
ablakokba kerüljenek. Az aggregációs és konténer osztály objektumai is külön ablakban jelenjenek meg.
Az egyes objektumokban a felhasználó keresési sorrendjének megfelelően kell elrendezni a képernyőelemeket. Az
elrendezés általában feleljen meg a valós világbeli objektum elrendezéseinek. Ha nincs valós világbeli analógia, akkor
abból kell kiindulni, hogy a felhasználó felülről lefelé és balról jobbra fogja átpásztázni a képernyőt. Az egyes
menüpontok és nyomógombok elhelyezése is a végrehajtási prioritás szerint történjen. Egy dialógusablak esetén például
az ablak belsejében a nyomógomboknak vagy a képernyő jobb oldalán felülről-lefelé a képernyő alján balról-jobbra
adott sorrendben kell elhelyezkedniük.

Üzenetek: a felhasználónak szóló üzenetek megtervezése is kellő körültekintést kíván meg. Célszerű olyan rövid,
maximum 3 soros üzeneteket terveznünk, amelyekből a probléma és a megoldás is kiderül.

Elkészítés:
• az alkalmazás űrlapjainak, menüszerkezetének megtervezése, kitalálása
• űrlapok kivitelezése, megrajzolása
• egyes gombok, menüpontok, eseménykezelők megírása
• alkalmazás tesztelése

Eseményvezérelt program kapcsolata az operációs rendszerrel:

Az X Windows rendszer: egy olyan rendszer, mely grafikus kimenettel rendelkező alkalmazások felhasználói
felületének kialakítására ad lehetőséget. A rendszer fejlesztése 1983-1984-ben kezdődött. A fejlesztés célja olyan
kommunikációs felület készítése volt, ami azonos kezelői felületet biztosít a hálózattal összekötött, különböző operációs
rendszereket futtató számítógépeken. Az X Windows segítségével lehetőség van az alkalmazás és a kezelői felület
szétválasztására. Míg a kezelő felületet a helyi gépen futó X szerver jeleníti meg, addig az alkalmazás akár távoli
gépeken is futhat.
A rendszer gyors elterjedését számos előnyös tulajdonságán túl segítette, hogy az X Window forráskódja publikus. Az
X Window-t elsősorban a UNIX rendszerek támogatják.
Az X Window működésének jellemzője a kliens-szerver modell használata. A szerver egy grafikus terminálon futó
folyamat, mely grafikus ki- és bemeneti lehetőséget biztosít a kliens folyamat számára. A szerver kezeli az ún. grafikus
munkahelyet, melynek részei:
• a képernyő (illetve képernyők)
• a billentyűzet (alfanumerikus bemeneti eszköz), és
• egy grafikus bementi eszköz.
A kliens egy grafikus be-/kimenetet igénylő (általában interaktív) folyamat.

Az eseményvezérelt program futása: egy keret létrehozásával a program eseményvezéreltté válik. Ez azt jelenti, hogy
elkezd futni egy ú.. AWT programszál, amely állandóan figyeli a felhasználó által keltett eseményeket (pl. egérmozgás,
billentyűleütés). A main metódusnak, vagyis a program fő szálának lefutása után a program nem fejeződik be – az
AWT programszál tovább fut. Amíg az alkalmazásnak van érvényes ablaka, addig fut a frame osztályban deklarált
eseményfeldolgozó és szétosztó ciklus. A keletkezett eseményektől és a konkrét programtól függően sorban
végrehajtódnak az eseménykezelő metódusok.
Az eseménykezelő metódusokat az osztályokban kell megírni. Bizonyos eseménykezelő metódusok a komponensekben
már gyárilag benne vannak, ezért tudjuk például a kereteket átméretezni, elmozdítani.

Az esemény egy olyan történés, amely megváltoztatja valamely objektum állapotát. Az eseményvezérelt programozás
azt jelenti, hogy a program futása során események keletkeznek, melyeket egy kontroll objektum fogad és megfelelő
szabályok szerint szétoszt a program objektumai között. Az egyes objektumok előre be vannak programozva, hogy egy
adott esemény bekövetkezésére hogyan reagáljanak.

Esemény lehet:
• jel: egy objektum a másiknak egyértelmű jelet küld
• hívás: egy objektum meghívja egy másik objekt. Metódusát
• űrfeltétel: egy előre meghatározott feltétel igazzá válik
• idő: a kijelölt idő eltelik vagy elérkezik

A reakció lehet egy feladat végrehajtása, vagy egy újabb esemény kiválasztása is. Az objektum lekezeli az eseményt,
amely egy eseménykezelő metódus feladata. Ahhoz, hogy egy objektum fogadjon egy eseményt, két feltételnek kell
teljesülnie:
• Az objektum be legyen tanítva az esemény fogadására.
• Az objektumhoz eljusson az eseményeke
tehát az eseményvezérelt programozás, amely egy eseménybegyűjtő és szétosztó mechanizmuson alapszik.
Eseményvezérelt programozás a Java környezetben.
Mint már tudjuk a grafikus felhasználói interfész (felület) eseményvezérelt, vagyis a programot a futás közben
keletkezett események vezérlik. Események keletkeznek a programon kívül, ilyen például egy billentyű leütése vagy az
egér elmozdítása, de a program maga is kiválthat eseményeket. Az esemény egy objektum, amely mindig egy
forrásobjektumhoz kötődik: az esemény azon az objektumon, komponensen keletkezik (az operációs rendszer
közreműködésével). A keletkezett esemény a Java eseménydelegációs modellje alapján eljut a megfelelő figyelő
objektumhoz, amelyek a hozzá érkező eseményeket feldolgozzák. Vannak alacsony szintű, elemi események és vannak
magas szintű, összetett, logikai események. A Swing az AWT eseménymodellt használja. Használhatja továbbá az
java.awt.event csomagban deklarált eseményosztályokat, melyek a javax.swing.event csomag újabb eseményeivel
egészít ki.

A megvalósítás egy példán keresztül:

feladat: tegyünk keretbe egy Pittyeg feliratú gombot. Ha lenyomják a gombot, akkor pittyegjünk egyet.

Forráskód:
import javax.swing.*;
import java.awt.*;
import java.event.*;
import extra.frame.CloseableFrame;

public class PittyegoKeret extends JFrame implements ActionListener{

private JButton btPittyeg= new JButton("Pittyeg");

public PittyegoKeret(){
getContentPane().add(btPittyeg);
btPittyeg.AddActionListener(this);
pack();
show();
}

public void ActionPerformed(ActionEvent e){

Toolkit.getDefaultToolkit().beep();
}

public static void main(String args[]){

new PittyegoKeret();
}

A keret osztálya a Pittyegőkeret, amely a CloseableFrame osztályból származik. A btPittyeg nyomógomb osztálya
Jbutton. Amikor a gombot lenyomják, akkor egy ActionEvent (akcióesemény) keletkezik – az esemény forrása a
BTPittyeg. Az esemény a gombon akkor is keletkezhet, ha a gombot senki sem figyeli – ez gombba be van
programozva. A keletkezett eseményt az az objektum tudja feldolgozni, aki a forrásobjektumot figyeli. A BTPittyeg
forrásobjektumot mi a kerettel figyeljük. A keretet a programozónak kell a forrásobjektumhoz „tapasztani” annak
addActionListener metódusával.
Amikor a nyomógombot lenyomják, a kerethez automatikusan eljut az esemény: meghívásra kerül a keret
actionPerformed metódusa, melynek paramétere maga az esemény (ev:ActionEvent). A figyelő osztálynak
implementálnia kell az ActionListener interfészt, melynek egyetlen metódusa az actionPerformed. Az esemény a
forrásobjektumból tehát eljut a figyelőhöz, amely az eseményt kezeli. A keret és a gomb közötti kapcsolat kétirányú.

Elemzés:Az ActionEvent eseménnyel kapcsolatos osztályokat és interfészeket az java.awz.event csomag definiálja.

Ahhoz, hogy a keret figyelje és lekezelje a nyomógomb keletkezett ActionEvent eseményt, a következő dolgokat
végezzük el:
• a nyomógombot rátesszük a tulajdonosi hierarchiára. Másképp a gomb nem is látszik, és nem is keletkezik
rajta esemény.
• A keret osztályban implementáljuk az ActionListener interfészt, és ki is fejtjük annak egyetlen,
actionPerformed (ActionEvevent ev) eseménykezelő metódusát. A lekérdezés abban áll, hogy egy rövid
hangot adunk, vagyis a java.awt.Toolkit osztály definiál egy beep () metódust, amely egy rövid hangot ad.
• A btPittyeg forrásobjektum figyelőláncára felfűzzük a keretet. Az addActionListener metódust a Jbutton
osztály deklarálja.

Megjegyzések:
• egy forrásobjektumnak több figyelőobjektuma is lehet. Az addActionListener metódussal egymás után több
figyelőobjektum is a forrás objektumhoz „tapasztható”.
• A különböző eseményfajták figyeléséhez a programnak más-más figyelő interfészeket kell implementálnia. A
KeyEvent eseményt például a KeyListener figyeli.
• Hiába tesszük figyelőképessé akeretet, ha nem fűzzük fel a forrás 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ázis-kezelési lehetőségek, adatbázisok adatainak megjelenítése. Az eszközök
dokumentáltságának ismertetése.

A 4GL (4. Generation Language – Generációs Nyelv) jellemzői, hogy fejlesztés nagyrészt interaktív módon történik.
Alapvetően objektum-komponensekből dolgozik. Ilyen kész komponenseket kell elhelyezni fejlesztéskor egy adott
form-ra. Ez lehet maga az alkalmazás felhasználói ablaka, de lehet pl. egy adatbázis tervező nézet is. Létezik egy
tulajdonság ablak, melyben az adott osztály különféle tulajdonságait állíthatjuk.
A 4GL eszközök működése azon a a tényen alapul, hogy a szoftverrendszerek nem elszigetelt módon működnek, hanem
feladataik végrehajtása közben folyamatos párbeszédet folytatnak a környezetükkel.
Az elnevezés bevett és akár léptem nyomon találkozhatunk vele félrevezető lehet, ugyanis a 4GL eszközök valójában
nem nyelvek, hanem egy vagy több magas szintű nyelvre épülő komplex, objektumorientált programfejlesztői
környezetek. PL. a Basic egy programozói nyelv, de a Visual Basic 5GL alkalmazásfejlesztő eszköz. Az első !GL
alkalmazásfejlesztő eszközök a 80-as években jelenetek meg, és használatuk a 90-es évek második felére tömeges
mértéket öltött. A 4GL eszközök működése azon a tényen alapul, hogy a szoftverrendszerek nem elszigetelt módon
működnek, hanem az alábbi ábrának megfelelően feladataik végrehajtása közben folyamatos párbeszédet folytatnak a
környezetükkel. Ábrázolva:

A környezet két részre bontható:

• Emberi környezet: a kezelő akivel a rendszer egy alkalmasan kialakított kezelői felületen keresztül tartja a
kapcsolatoz.
• Gépi környezet: külső számítógépes rendszerek, amelyekből beérkező információk vagy események a
rendszerünk befolyásolják. Ezekkel kommunikációs felületen keresztül tartja a rendszer a kapcsolatot.

A szoftverrendszer harmadik komponense az alkalmazáslogika, mely a rendszer magjaként a feladatspecifikus

műveletek végrehajtására szolgáló algoritmusokat foglalja magában. Egy régi. Statisztikai megfigyelés azt mutatja,
hogy egy átlagos programozó által jól ismert programnyelven a feladat kitűzésétől a kész program átadásáig,
beleszámítva az elemzés, tervezés, implementáció idejét is, naponta átlagosan 20 sor programot készít el, ha alkalmazói
rendszerről van szó, 10 sor, ha rendszerprogramról, 2(!) sor. Itt I/O tevékenységet kell programoznia.
Az I/O tevékenységek aránytalanul nehezebb programozhatóságának fő oka egyébként kicsit tüzetesebb szemlélődés
után nyilvánvalóvá válik: ezek a felületek eseményvezéreltek. A programfejlesztés szempontjából a dolog úgy fest,
hogy a programozónak nem egyedi eseményeket, hanem eseménysorozatokat kell helyesen kezelnie, melyek elvileg
végtelen sokfélék lehetnek, és kölcsönhatásaik tetszőlegesen bonyolultak. Ezért a kezelői- és kommunikációs felületek
tesztelése és optimalizálása rendkívül nehéz feladat.

Mindebből az következik, hogy a legnagyobb bonyodalmak általában nem az alkalmazáslogika megvalósítása körül
bukkannak elő, hanem a kezelői felület és a kommunikációs felület létrehozásakor. Más szóval a magas szintű nyelvek
segítségével megvalósíthatóak ugyan a kezelői felülethez és a kommunikációs felülethez kapcsolódó funkciók, de
lényegesen költségesebben, mint a program „belső részeinek”, azaz az alkalmazáslogikának a programozása.

Ennek a gondolatmenetnek logikus folytatásaként adódik a költségek csökkentésének, a programfejlesztés sebességének

és az elkészült program megbízhatóságának növelése érdekében olyan fejlesztői környezetre van szükség, amely az
ábrán látható séma minden elemének létrehozását erőteljesen támogatja megfelelő céleszközök segítségével. Ilyen
fejlesztői környezetek a 4GL eszközök.

A 4GL eszközök, a kezelői felület létrehozására speciális szerkesztőket, ún. látványtervezőket (layout editor, dialog
editor) alkalmaznak, melyek segítségével a kezelői felület elemei egyszerűen megrajzolhatók, elrendezhetők, és
tulajdonságaik (pl. méret, szín) könnyedén beállíthatók.

A kommunikációs felület létrehozása kissé más feladat, ugyanis míg a kezelő tipikusan emberi (és az emberek sok
szempontból eléggé hasonlítanak egymásra), a rendszer környezete nagyon sokféle lehet. Ezért a 4GL eszközök vagy
előre definiált környezetet tételeznek fel (pl. relációs adatbázis-kezelő rendszerek), és az adott környezettel való
kapcsolattartásra alkalmas elemeket eleve tartalmazzák, vagy pedig nyílt rendszerként működnek, és képesek
különböző, szabványos illesztőfelületen keresztül kommunikálni (pl. ODBC, JDBC, különböző hálózati protokollok).
Akármilyen eset áll is fönn, a 4 Glrendszerek a kommunikációs felület implementálásara általában nem tartalmaznak
külön eszközöket, legfeljebb lehetővé teszik az előre definiált kommunikációs felület viselkedésének megváltozását. Ez
érthető is , hiszen a kommunikációs felület létrehozása többnyire a 4GL eszközzel fejlesztett alkalmazás által
megvalósítható funkciókat sokkal alacsonyabb szintű gondolkodásmódot igényel

Az alkalmazáslogika implementálása magas színtű, gyakran objektumorientált programozási nyelv szolgál. Nagyon
sokféle nyelvre alapulnak 4GL környezetek. Így például a Borland Delphi az Objekt Pascal-ra, a Visual Basic és az
Oracle Power Objects a Basic-re, a Borland Jbuilder a Java-ra, stb.

Kezelői felület: a kezelői felületen keresztül tudjuk egy működő szoftverrendszer viselkedését befolyásolni. Elméleti
szinten a kezelői felületek kialakítása komoly szaktudást igényel, amely nem csak programozástechnikai, hanem
ergonómiai, esztétikai és egyéb problémákat is magában foglalja.

A kezelői felületek a kezelőnek a rendszerről kialakított modelljét kell tükrözzék, melyen keresztül a kezelő a géppel
kapcsolatba kerülhet. A kezelő fejében a világról számos modell él:
• rendszermodell: a kezelő modellje az általa használt rendszer funkcióiról és belső működéséről, melynek
alapján képes a rendszer számára absztrakt (azaz bizonyos értelemben véve a világtól elvonatkoztatott)
parancsok megfogalmazására. Ilyenkor a kezelő a lehető legnagyobb mértékben alkalmazkodik a rendszer
képességeihez annak érdekében, hogy a kezelői felület a legegyszerűbb, és ez által végrehajtási sebesség és
megvalósíthatóság szempontjából a leghatékonyabb legyen. (formális párbeszéd)
• vizuális modell: a kezelő felület ez esetben olyan eszközöket nyújt, amelyek megjelenésüket és használatuk
módját tekintve alkalmazkodnak, a kezelői mindennapi életében megszokott eljárásaihoz, ide tartoznak a
grafikus kezelőfelületek (drag and drop, fogd-és-vidd) módszerei. Ez a fajata megközelítés jól alkalmazkodik a
kezelő intuitív világlátásához.
• szemantikus modell: a rendszer a kezelő természetes nyelvén kommunikál, így elvileg bármit kifejezhet,
amire gondol. A természetes nyelvű parancsok a rendszer deklaratív kezelését teszik lehetővé, azaz összetett
utasításokat fogalmazunk meg tömör, egyszerű módon, ráadásul a rendszer a kezelő által a mindennapi életben
használt nyelvet közvetlenül megérti. A jövő minden bizonnyal ez, de a megoldás rendkívül bonyolult, így
még várat magára.

A jelenlegi 4Gl eszközök a lehetséges kezelői felületek közül érthető módon csak az első kettőt támogatják. Míg a
karakteres fejlesztőeszközök csak a formális párbeszéden alapuló kezelői felületek létrehozását támogatják, addig a
grafikus fejlesztőeszközök emellett a grafikus kezelői felületek megvalósítását is lehetővé teszik.

A 4GL eszközök a kezelői felületnek a lapokon megjelenő objektumait osztálykönyvtárakban tárolják, melyek a
fejlesztő számára eszköztárnak (toolbox toolbar) formájában jelennek meg a 4GL felületén. Az eszköztár ikonos
nyomógombok csoportja, melyen belül minden nyomógomb egy-egy adott megjelenítendő objektumféleség
létrehozására szolgál. Maga a létrehozás nem igényel többet, mint az egér segítségével az eszköztárból a megfelelő
nyomógomb kiválasztása, majd az új elem (objektum) helyének kijelölése az adott lapon.

Az objektumok tulajdonságokkal és módszerekkel rendelkeznek. Minden létrehozott megjelenítendő elemhez tartozik

egy adatlap, melynek segítségével az objektum tulajdonságai beállíthatóak, ezáltal pedig az egyes objektumok
viselkedése tág határok között befolyásolható.
Az adatbázis-kezelőkhöz fejlesztett adatmegjelenítő, adatbeviteli/adatmódosító alkalmazások fejlesztése a 4GL
alkalmazásfejlesztők eszközök egyik legelterjedtebb felhasználási területe a kommunikációs felületnek ilyen esetekben
a következőket kell lehetővé tennie:
• az adatbázis kapcsolata és lebontása: első lépésként mindig ki kell jelölünk azt az adatbázist, amelyikkel
kommunikálni akarunk. Ezzel az adatbázissal ki kell építeni egy (többnyire hálózati) kapcsolatot. Az adatokkal
való műveletek elvégzése után a kapcsolatot le kell bontani. Minderre a megfelelő 4GL eszközök közvetlen
megoldást nyújtanak, gyakran grafikus objektum formában.
• SQL kérések összeállítása és elküldése: a kezelői felületen megjelenő kezelőszerveken keresztül a felhasználó
megváltoztatja különböző adatok értékeit, új sorokat vihet be, vagy lekérdezési feltételeket fogalmazhat meg.
A kezelőszervek állapota alapján a 4GL eszköz adott parancsra automatikusan összeállítja a megfelelő
(SELECT, INSERT, UPDATE vagy DELETE) utasítást szövegét, és az utasítás végrehajtja az adatbázis-
kezelővel
• eredmények visszaolvasása: a 4GL eszköz automatikusan beolvassa a SELECT utasítás végrehajtásakor
eredményül kapott sorokat, és az esetleges hibaüzeneteket. Mindezt automatikusan megjeleníti a kezelői
felületen a felhasználó számára.
• a kezelő felületen keresztül megváltoztatott vagy bevitt adatok visszaírása: ha a kezelő egy adatelemet
megváltoztat, töröl, vagy éppen új sort visz be, a módosításokat be kell vinni az adatbázisba is. Mindez DML
utasítások automatikus megfogalmazását és végrehajtását teszi szükségessé. Mivel a DML utasításokból már
tranzakciók keletkeznek, a 4GL eszköz feladata a tranzakciók lezárása, esetleges visszagörgetése, mentési
pontok elhelyezése, egyszóval maga a tranzakciókezelés is.

Dokumentáció:
 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ázis terv dokumentálása.

A relációs adatmodellben az egyedeket egy táblázattal adjuk meg, a táblázat oszlopai a tulajdonságok. A táblázat sorai
az egyed értékei (vagyis a táblázat maga éppen az egyedhalmaz). A táblázat egy-egy sorát a tulajdonságok konkrét
értékei adják. Például a DOLZGOZÓ egyed, pontosabban egyedhalmaz, amelynek tulajdonságai: név, születési-dátum,
születési-hely, fizetés a következő táblázattal adható meg:

DOLGOZÓ:
NÉV SZÜL-DÁTUM SZÜL-HELY FIZETÉS
Kovács Pál 01/12/89 Szolnok 79.000
Kis Péter 06/07/72 Budapest 88.000
Varga Ödön 02/05/60 Tiszapüspöki 98.000

A relációs adatmodellben létrehozott adatbázisokat több táblázattal adjuk meg (ne felejtsük el, minden tábla egy
egyedhalmaz), de a táblázatok (tehát az egyedek) közötti kapcsolatokat nem definiáljuk az adatmodell felírásakor. Ez
azt jelenti, hogy nincsen köztük kapcsolat, de ezeket a kapcsolatokat például egyszerűen az fejezi ki, hogy két
táblázatnak van közös oszlopa (mindkét táblázatban szerepel ugyan az a tulajdonság)

A relációs adatmodell oszlopokba szedett adatok együttese. A relációs adatbázis több táblából áll, kapcsolataikat
előre nem adjuk meg.

Funkcionális függőség: a P attribútum-részhalmaz funkcionálisan meghatározza a Q attribútumhalmazt, ha minden P-

hez tartozó értékhez (a P attribútumának oszlopaiban álló értékhez) pontosan egy Q-hoz tartozó értéket tudunk
hozzárendelni. (Vagyis a P értékei egyértelműen meghatározzák a Q értékeit.) Az attribútumok egy csoportja függ az
attribútumok egy másik csoportjától. A kulcs és a reláció többi attribútuma között funkcionális függőség áll
fenn.

Pl.: LÉGIJÁRAT (REP-TÁRS, JÁRATSZ, DÁT, GÉPTIP, INDIDŐP, ÉRKIDŐP, INDHELY, ÉRKHELY, ÉTKTIP,
ÜLHELY, OSZT)
ahol REP_TÁRS = a repülőtársaság
JÁRATSZ = járatszám
DÁT = dátum
GÉPTIP = géptípus
INDIDŐP = indulási időpont
ÉRKIDŐP = érkezési időpont
INDHELY = az indulás helye (város)
ÉRKHRLY = az érkezés helye (város)
ÉTKTIP = az étkezés típusa
ÜLHELY = ölőhely sorszáma
OSZT = osztály
Könnyen beláthatóak az alábbi funkcionális függőségek:
1. (REP-TÁRS, JÁRATSZ, DÁT) >>>> (GÉPTIP, INDIDŐP, ÉRKIDŐP)
2. (REP-TÁRS, JÁRATSZ) >>>> (INDHELY, ÉRKHELY, ÉRKTIP)
3. (GÉPTIP, ÜLHELY) >>>> (OSZTÁLY)

magyarázat:
1) a repülőtársaság neve, a járat száma és a dátum meghatározza géptípust és azt, hogy a gép mikor indul és
mikor érkezik ( ha az első három attribútum megegyezik, akkor meg kell egyeznie a másik háromnak is).
2) Ha a repülőtársaság és a járatszám megegyezik, akkor az indulási hely és az érkezési hely és az étkezés típusa
is megegyezik, vagyis az előbbi két attribútum meghatározza az utóbbi hármat is.
3) Ha megadjuk a géptípust és az ülőhelyet, az meghatározza, hogy milyen osztályon utazik az utas.

A példából is látszik, hogy a funkcionális függőség valóban a reláció belső szerkezetét írja le, az attribútumok közötti
kapcsolatot fejez ki.

Teljes függőség: adott az R reláció és az X összetett értelmezési tartomány. Y értelmezési tartomány funkcionálisan
teljesen függ X-töl, ha Y funkcionálisan függ X-től, de nem függ funkcionálisan X egyetlen valódi részhalmazától sem.

Tranzitív függőség: adott at R reláció; Z értelmezési tartomány tranzitívan függ X értelmezési tartományától, ha Z
funkcionálisan függ X-től, Y-tól és Y függ X- értelmezési tartományától. Elsődleges kulcstól minden tartomány
funkcionálisan függ; ha a kulcs egyben egyszer is.
Normálformák: ha az adatbázis eleget tesz bizonyos feltételeknek, akkor azt mondjuk, hogy egy adott normálformában
van.

Első normálforma (1NF-ben): egy reláció azt mondjuk, hogy első normálformában van, ha minden sorában pontosan
egy attribútumérték áll. (Az adatbázis-kezelők csak olyan adatbázist fogadnak el amelyek 1NF-ben vannak.)

Második normálforma: (2NF): egy R relációról azt mondjuk, hogy második normálformában van, ha első
normálformában van, és ha minden másodlagos attribútum teljesen függ a kulcstól, de nem függenek a kuollcs részeitől
(ha a kulcs több attribútumból áll). A 2NF első követelménye, hogy az adatbázis első normálformában legyen. A
második követelménye prdig az, hogy az reláció (tábla) minden egyes sora azonosítható legyen.

Harmadik normálforma (3NF): egy relációról azt mondjuk, hogy harmadik normálformában van, ha másodlagos
attribútum,
• egymástól funkcionálisan függenek,
• a kulcstól teljesen függenek,
• nem függenek tranzitíven a kulcstól
A 3NF legelső követelménye, hogy az adatbázis 2NF-ban legyen. A második kitétel, hogy a tábláikban nem lehet olyan
redundáns (ismétlödő) nem-kulcs információ, amely más táblákban is nem-kulcs információt jelent.

Normalizálás: Az az eljárás, amelynek során az attribútumokat optimális relációkba csoportosítják. A normalizálás

mindig az adatok logikai szintjén történik. Általában több lépésből áll.

A normalizálás alkalmazásával:
• az adatok tároló igénye kisebb lesz
• az elemi adatokat gyorsabban és kevesebb hibalehetőséggel változtathatjuk meg
• az adatbázis logikailag áttekinthetőbb lesz

• 1NF-re:
- minden „többszörös” attribútumértékű sort annyi sorban írunk fel, ahányszoros az attribútumérték a sorban;
- két vagy több relációra bontjuk fel az eredeti egy relációt, úgy hogy a reláció kulcsának értékei mellé írjuk az
egyszeres attribútumértékeket, a másikban pedig a kulcshoz rendelt külső kulcs mellé annyi sort írunk,
ahányszoros attribútum értékek szerepeltek a korábbi, többszörös attribútumokban.

• 2NF-re: Több relációra bontjuk az eredeti relációt, amelyek már 2NF-ben vannak. A kulcsnak azon attribútum
halmazaiból, melyek maguk is meghatározzák (funkcionálisan) a másodlagos attribútumokat, valamint ezen
másodlagos attribútumokból önálló relációt hozunk létre..

• 3NF-re: megszüntetjük a tranzitív függőségeket, mégpedig úgy, hogy a tranzitív függőségben részt vevő attribútum
halmazok felhasználásával új relációkat készítünk.

A normalizálás olyan folyamat, mely egy relációt (ált.) több relációba transzformál úgy, hogy azáltal megszünteti a
redundanciát és a szabálytalanságokat (anomáliákat), és új relációk megfeleltethetők az eredeti relációnak.

A normalizálás a relációra vonatkozóan bizonyos fajta átalakítást jelent. A reláció elmélete különféle módszereket
tartalmaz a redundancia megszüntetésére az ún. normálformák segítségével. A normalizálás során a különböző
normálformák feltételeit vizsgáljuk. Öt normál formát különböztetünk meg. A különböző normál formák egymásra
épülnek, például a harmadik normál formában levő reláció második normálformában is van. A tervezés során a
legmagasabb normál forma elérése (5NF) a cél. Az első három normál forma a funkcionális függőségekben található
redundanciák, míg a negyedik és ötödik a többértékű függőségekből adódó redundanciák megszüntetésére tartja szem
előtt.
Azt az adatmodellt, amelyről nem tudjuk, hogy melyik normálforma feltételeit teljesíti, nulladik normálformájúnak
nevezzük. Ez a normalizálás kiinduló helyzete. Ha az adatmodell az ötödik normálformát is teljesíti akkor az modellt,
illetve az adatmodell alapján felépített adatbázist, teljesen normalizált adatbázisnak nevezzük. A teljes normalizáltságot
elérő eljárást veszteségmentes felbontásnak nevezzük. A normalizálás támogatja az adatintegritást a redundancia és az
inkonzisztencia minimalizálásával, de ez az adatok lekérdezését lassítja. Ezért az a helyzet is előfordulhat - ha a fő
hangsúly az adatok gyors elérésén van -, hogy egy alacsonyabb normálformájú adatbázissal kell megelégednünk.
A normalizáció következményeként: az adatok tárolására fenntartott hely lecsökkent, az adatok gyorsabban,
pontosabban és kevesebb hibalehetőséggel használhatók, maga az adatbázis egyszerűbbé és áttekinthetőbbé válik.
Ezek alapján egy relációknak létezik első (1NF), második (2NF), harmadik (3NF), ún. Boyce-Codd (BCNF), negyedik
(4NF) és ötödik (5NF) normálformája.
Az adatbázisterv dokumentációja:
 13.) SQL adatbázis, adattábla, index, nézet létrehozása és törlése. Adattábla szerkesztésének módosítása. Kulcsok,
külső kulcsok megadása, kapcsolatok beállítása. További megszorítások elhelyezése.

Az SQL relációs adatmodellt kezel, így a nyelv fő objektuma a reláció, amit az SQL-ben táblának (table) nevezünk. A
táblát egy erre a célra szolgáló paranccsal (CREATE TABLE) definiáljuk. Az SQL parancsainak operandusa a tábla. A
tábla neve (azonosítója) max. 8 karakter hosszú lehet, betűvel kell kezdődnie, betűkből, számjegyekből és aláhúzás
karakterekből állhat. Nyilvánvaló, hogy az SQL által foglalt szót nem használhatunk táblanévként és különböző
tábláknak nem adathatunk azonos nevet.
Az SQL-ben a tábla oszlopait típusokkal látjuk el, a tábla definiálásakor az oszlopok típusát deklarálni kell. A tábla
oszlopokból áll. Az oszlop azonosítója (neve) max. 10 karakteres, betűvel kezdődő, betűt, számjegyet és _ jelet
(aláhúzásjel) tartalmazó jelsorozat lehet. Az oszlopnév nem lehet foglalt szó. Két különböző táblában két oszlop neve
lehet azonos (ugyanabban a táblában természetesen nem).
A táblák adott csoportja adatbázist (database) alkot az SQL-ben. Az adatbázis:táblák névvel ellátott együttese.

Indextábla létrehozása:

Az indextábla egy adott táblából kiemelt néhány rendezett oszlopból áll. Ez azt jelenti, hogy az alábbi utasítással kijelölt
oszlopok fizikailag rendezett oszlopok lesznek (növekvő vagy csökkenő sorrendben). Ennek az az előnye, hogy ha a
táblában azon oszlopok értékei szerint keresünk, amelyek indexelve vannak, a keresés gyorsabb lesz, hiszen egy
rendezett táblában könnyebb a keresés. A rendezett oszlop akkor ér valamit, ha az oszlop minden értéke mellett ott van
annak a sornak a sorszáma, amelyben ez az érték a rendezés előtt volt.

Az SQL-ben rendezett oszlopokból álló indextáblát a következőképpen hozzunk létre:

CREATE[UNIQUE]INDEX indextábla-név ON táblanévkén

(oszlopnév [[ASC]/DESC] [,oszlopnév[ASC/DESC],....]);

hatása:
✗ az ON után adott tábla felsorolt oszlopait rendezi (növekvőleg ha ASC és csökkenőleg, ha DESC
szerepel, ha semmi akkor az ASC érvényes) és belőlük egy az INDEX szó után megadott nevű táblát
készít. Ha azon oszlopok szerint keresünk, amelyek indexelve vannak (vagyis az indextáblában
szerepelnek) akkor a keresett rekordokat sokkal gyorsabban megtalálja a rendszer. A UNIQUE azt
jelenti, hogy az oszlop értékei egyediek. Ha szerepel ez a szó a parancsban, akkor a rendszer hibát
jelez ha ismétlődő értékek is vannak az oszlopban.

Az indextáblát a DROP INDEX index-táblanév paranccsal törölhetjük.

Nézet létrehozása törlése.

Létrehozás: a táblákból állandó adatbázis létrehozásának első lépése az adatbázis definiálása. Az adatbázist létrehozó
parancs szintaxisa:

CREATE DATABASE adatbázisnév;

Az utasítás hatására voltaképpen egy üres adatbázis jön létre (az adatbázishoz tartozó könyvtárakkal és
katalógustáblákkal).

Létrehozás után az adatbázis aktív (nem kell kiadni a START parancsot).

Törlés

DROP DATABASE adatbázisnév;

Ha az adatbázisra többé már nincs szükségünk, akkor töröljük a könyvtárból.

Adattábla szerkezetének módosítása: az adatbázis feldolgozása folyamán lehet a tábla szerkezetének módosítására.
Az SQL-ben sajnos nincsen lehetőség igazi módosításra, csak új oszlopok hozzávételére.

Minden más változtatást úgy tudunk elvégezni, hogy létrehozunk egy új táblát (és azt a meglévő táblázatból töltjük fel).

ALTER TABLE táblanév

ADD (oszlopnév adattípus [,oszlopnév adattípus … ]);
hatása:: a felsorolt oszlopokkal bővíti a táblát.

Kulcsok, külső kulcsok megadása: ha egy tulajdonság (attribútum) vagy tulajdonságok egy csoportja egyértelműen
meghatározza, hogy melyik egyedről van szó. A relációs adatbázisokban a különböző táblákat közös attribútumokkal
kötjük össze, melyeket kulcsoszlopoknak nevezzük.

Külső kulcs: (idegen kulcs), tulajdonság, mely kulcsa egy másik relációnak. A külső kulcs nem azonosítja a
rekordokat, nem valódi kulcs, csak a táblák sorai közti kapcsolatot fejezi ki.

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 a kulcsjelöltek közül választunk ki, és kulcsként használjuk. A ki
nem választott kulcsjelölteket alternatív kulcsnak nevezzük. Az elsődleges kulcsnak nem lehet NULL az értéke.

Ideiglenes kulcs (foreign key): olyan attribútum vagy attribútum kombináció egy adott relációban, amelyik egy másik
relációban elsődleges kulcsként szerepel. Az idegen kulcsot tartalmazó relációt hivatkozó relációnak, a másikat,
melyben ez a kulcs elsődleges, hivatkozott relációnak nevezzük.

Kapcsolatok beállításai:

Kapcsolat (relationship): Az egyedek vagy tulajdonságaik közötti viszony. A kapcsolatokat megkülönböztethetjük

annak megfelelően, hogy az egyedhalmazok közötti viszonyt vizsgáljuk, vagy az egyes egyedek tulajdonsághalmazai
közötti viszonnyal foglalkozunk. Az egyedhalmazok közötto kapcsolat, a táblák (relációk) közötti kapcsolatban fog
megjelenni. Az egyedhalmazok közötti kapcsolat, a táblák (relációk) köztti kapcsolatban fog megkelenni. Az
egyedhalmaz tulajdonsághalmazai közötti kapcsolatokat pedig a relációs modellnél vizsgáljuk, amikor meghatározzuk a
funkcionális függőséget.

További megszorítások elhelyezése: a tábla definiálásakor más megszorítások is megadhatók ennek legegyszerűbb
esete az, amikor a megszorítás az egyes attribútumok értékeire vonatkozik.

A NOT NULL opció azt jelenti, hogy az adott attribútum nem vehet fel NULL (üres) értéket. A CHECK kulcsszó után
tetszőleges feltételt adhatunk. Az erre vonatkozó szabályok megegyeznek a SELECT parancsban használt WHERE
záradék lehetséges feltételével. A feltétel ellenőrzése sor beszúrásakor, vagy az attribútum módosításakor történik.

Ennél általánosabb megszorítások ellenőrzése a sorban történő bármilyen módosításkor megtörténik. A teljesen
általános megszorítások, amelyek teljes adatbázisra vonatkoznak. A sorokra vonatkozó megszorítások ellenőrzése a
sorban történő bármilyen módosításkor megtörténik. A teljesen általános megszorítások ellenőrzése minden olyan
módosításkor bekövetkezik, aminek az adott feltételre hatása lehet. A sorra vonatkozó feltételek megadása szintén a
CHECK paranccsal történik, ezt a tábla definiálásának a végén kell megadni.
 14.) SQL adattábla sorainak felvitele, módosítása, törlése. Lekérdezése adatbázisból a lekérdező parancs
összeadá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:

Sorokat (rekordokat) a táblába az INSERT paranccsal tudunk bevinni. A parancs egyszerre egy sort visz be. A táblába
helyezett új sor fizikailag a meglévő utolsó sor után tárolódik, beíráskor formátum és integritás-ellenőrzés történik, ha
bemenő adat bármelyik mezője nem fér el a megfelelő oszlopban, akkor az utasítás nem hajtódik végre, vagyis a sor
nem kerül bele a táblázatba.

INSERT INTO táblanév

[(oszlopnév-lista)]
VALUES (értéklista);

Hatása: a felsorolt oszlopok sorrendben felveszik az értéklistában szereplő értékeket. Ha az oszlopnév-lista (vesszővel
elválasztott oszlopnevek) elmarad, akkor a tábla definiálásánál megadott oszlopnevek sorrendjében kell az értéklista
elemeinek szerepelni.

Az A1-SELECT használatával is beszúrható új sor a táblába, ekkor az új sorok értékei az A1-SELECT E-táblájának
soraiból tölti fel az SQL.

INSERT INTO A-táblanév

[oszlopnév-lista ]
A1-SELECT;

További sorok az INSERT parancs ismételt kiadásával szúrhatók be.

Adatbázis szerkezetének módosítása:

Az UPDATE utasítás módosítja a megadott táblázat vagy nézet egy vagy több sorának meghatározott oszlopát vagy
oszlopait. Ha nem adunk meg feltételt, akkor minden sort módosítunk, egyébként csak azokat, amelyekre a feltétel
teljesül. Speciális esetekben előfordulhat, hogy egy sort sem módosítunk.

UPDATE A-táblanév
SET oszlopnév = kifejezés
[oszlopnév = kifejezés]...
[WHERE feltétel];

A1-SELECT használata esetén a WHERE feltételben megadott belső SELECT E-tábla értékei jelölik ki a
módosítandó sorokat.

Törlés (DELETE):

A DELETE utasítás sort, sorokat töröl egy táblázatból, vagy nézetből. A kiválasztási feltétel bármelyik lehet
(SELECT, BETWEEN, IS NULL, LIKE, EXIST). A táblázat/nézet az összes sor törlése után is megmarad, ennek
megszüntetése a DROP utasítás szolgál. Ha a táblázatra idegen kulccsal már táblázat is hivatkozik, akkor annak sorai is
az idegen kulcs definiálásakor megadott módon változnak meg. A törölt kulccsal egyenlő értékű idegen kulcsot
tartalmazó sorok a hivatkozó táblázatból szintén törlődnek vagy a null-értéket veszik fel.

DELETE
FROM A-táblanév
[WHERE feltétel];

A1-SELECT használatakor a WHERE feltételben megadott belső SELECT E-tábla értékei jelölik ki a törlendő
sorokat.

Lekérdezés adatbázisból, a lekérdező parancs összeállítása, végrehajtása:

Az adatbázis-kezelés egyik fontos művelete (tekinthetjük a legfontosabbnak is) a lekérdezés. Az összes többi funkció
szinte azért van, hogy a definiált, feltöltött (módosított) adatbázisból információkat szedhessünk ki, lekérdezési
parancsokat adhassunk ki rá.
Az SQL lekérdezési parancsa egy összetett parancs; ha ugyanazt a lekérdezést mondjuk PASCAL-ban kellene felírni,
akkor az egy hosszabb program lenne.
Azt, hogy a SELECT parancs összetett, szó szerint értjük, mert több „alparancsból” áll.
A SELECT parancs végrehajtásának eredményeként egy új tábla keletkezik, a továbbiakban ezt eredménytáblának (E-
táblának) hívjuk. A parancs általános szerkezete a következő:

SELECT.... oszlop kiválasztása=projekció

[INTO...] az E-tábla 1. sorának tárolása
FROM... táblák Descartes-szorzata
[WHERE...] sorok kiválasztása=szelekció
[GROUP BY...] csoporthívás
[HAVING...] csoportok közötti választás
[UNION...] E-táblák összefűzése=az unió művelete
[ORDER BY/FOR UPDATE OF...] E-tábla rendezése/tábla módosítása
[SAVE TO TEMP...]; E-tábla megőrzése, elemzése

A lekérdező parancs végrehajtása:

Az adatbázis kezelés egyik legfontosabb művelete a lekérdezés, mely a SELECT paranccsal hajtható végre.

SELECT.....
FROM

A SELECT és a FROM külön nem állhat.

SELECT [ALL/DISTINCT] oszlopnév lista |*

FROM táblalista;

A FROM után szereplő táblákból kiemeli az oszloplistában szereplő oszlopokat, illetve a * esetén az összes oszlopot.
ALL/DISTINCT = előfordulhat, hogy egy az oszlopnévlistában szereplő oszlopban valamilyen érték többször
előfordul. Ha a SELECT parancsban CISTINCT- et írunk, akkor az azonosak közül csak
egyet választ ki az oszlopba. ALL esetén pedig az összes azonosat.

Belső lekérdezés lehetősége, a nyelv kifejezései (beágyazott SELECT parancsok):

A SELECT parancsok egymásba ágyazása az alábbi szerkezetben:

SELECT … (SELECT) … (SELECT) … ) …

Több SELECT egymásutáni végrehajtása egyetlen E-táblát eredményez.

Az egymás mellett lévő bal oldalon álló SELECT- et a tőle jobbra állóhoz képest külső SELECT- nek, a másikat pedig
belsőnek nevezzük.
A külső SELECT a belső E-táblától függően hoz létre E-táblát. Az ily módon létrehozott SELECT-sorzat egyetlen
eredménytáblát ad, amit az utolsó külső SELECT generál.
A belső SELECT mindig vagy WHERE vagy HAVING utasítást operandusa; nem tartalmazhat ORDER BY és UNION
utasításokat és az is kikötés, hogy a GROUP BY és a HAVING a teljes SELECT-ben csak egyszer fordulhat elő.

Az egymásba ágyazott SELECT szerkezetek aszerint, hogy a belső SELECT E-táblája egy vagy több értéket tartalmaz
két csoportba sorolhatók.

a) Egyetlen értéket tartalmazó E-tábla: ha a belső E-tábla egyetlen értéket tartalmaz, akkor a WHERE
parancsrészben egyszerű összehasonlításokat végezhetünk.

Pl. SELECT vnev + knev, fiz

FROM dolgozo
WHERE fiz < (SELECT AVG (fiz) FROM dolgozo)

b) Többértékű belső SELECT: amikor egy SELECT-nek egynél több értéke van, akkor a WHERE utasításrészben
olyan logikai feltétel szerepelhez, amely több értéket használ fel. Ilyen esetekben négy predikátummal
dolgozunk. Ezek az IN, ALL, ANY, EXISTS.

1. Az IN esetén a külső SELECT a belső SELECT által generált listában keresi a külső SELECT
 WHERE.jében lévő oszlop értkeit és amelyiket megtalálja, az ahhoz tartozó értéket beteszi az E-tábéába.
2. Az ANY kulcsszóval azokat a sorokat választjuk kia lülső SELECT WHERE parancsrészével, amelyekre
a WHERE-ben lévő logikai feltétel a belső SELECT által generált lista valamelyik értékére igaz.
3. Az ALL predikátum úgy „működik”, mint az ANY, de a mondat utolsó sorában lévő valamelyik szó
helyett minden-t kell mondani.
4. Az EXISTS-szel létrehozott feltétel akkor vesz fel igaz értéket, ha a belső SELECT által generált E-
táblanem üres (ellenkező esetben hamis az érték)

Jogosultságok kiosztása és visszavételezése:

• az adhat jogot egy objektumra (tábla, nézettábla, stb.) vonatkozóan, aki rendelkezik ezzel a joggal, és
továbbadási joggal is
• az adatbázis-adminisztrátor (DBA) kezdetben minden joggal rendelkezik minden objektumra
• az adatbázis felhasználóit a DBA hozza létre, és adhat nekik jogokat
• léteznek alapértelmezések
• az objektum tulajdonosa az, aki létrehozta az objektumot
• az objektum tulajdonosa minden joggal rendelkezik a saját objektuma felett
• a PUBLIK az összes felhasználót jelenti

GRANT jogosultság_1,..., jogosultság_k ON objektum TO felhasználó_1,..., felhasználó_m WITH GRANT OPTION;

• jogosultságok: SELECT, INSERT, DELETE, UPDATE, ALTER, ….

• az összes jogot jelenti az ALL.
• A továbbadási jog a WITH GRANT OPTION, ami el is hagyható.

Jogosultságok visszavonása:

REVOKE jogosultság_1,..., jogosultság_k ON objektum FROM felhasználó_1, …, felhasználó_m;

• a paraméterek megegyeznek a GRANT parancsnál használhatóakkal

• a WHIT GRANT OPTION segítségével továbbadott jogokat is visszavonja.
 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.

Mivel a vállalat stratégiai értékét növeli a szoftver számos vállalat, az iparág keres technikákat, hogy automatizálják a
szoftverfejlesztést és a minőség javítására és a költségek csökkentése és a timé-to-market. Ezek a technikák közé
tartozik a komponens technológia, vizuális programozás, minták és keretek. Vállalkozások is törekednek technikák
kezelésének összetettségét egyszerűsíteni előre kidolgozott megvalósítási sémák alkalmazásával. Különösen, hogy
felismerik annak szükségességét, hogy oldhatók meg az ismétlődő építészeti problémák, mint például a fizikai
disztribúció, konkurencia, replikáció, a biztonság, a terhelés kiegyenlítés és hibatűrés. Ennek következményeként A
Unifikációd Modeling Language (UML) célja az volt, hogy megoldást adjon ezen szempontok kielégítésére.

Objektumorientált tervezés:

• analízis: a megoldandó feladat meghatározása. Tartalmazza a feleadat-specifikácíót, képernyő és listaterveket,

adatszótárt,
• tervezés: az analízisben készült dokumentációk kibővítése: objektumdiagrammok, együttműködési
diagrammok, osztálydiagram, osztályleírás. Célszerű már meglévő osztályokat újrafelhasználni,
• kódolás tesztelés: az osztálydiagramm osztályait kódoljuk, és folyamatosan teszteljük, elsősorban az analízis
során feltárt esetek kipróbálásával.

A programterv egyes részeit párhuzamosan készítjük. A diagramokat a használati esetek alapján folyamatosan szárazon
teszteljük. Kódolni egy osztályt csak akkor szabad, ha annak feladata és környezetével való kapcsolata teljes mértékben
letisztult.

UML jelölés:

Unified Modeling Language (Egyesített modellező nyelv): a három objektumorientált rendszerfejlesztési módszertan
(OMT; Booch; OOSE) egyesítése 1997-ben jelent meg. Mára már minden szoftverfejlesztő világcég felismerte a
szabvány jelentőségét, és foglakozik annak továbbfejlesztésével. Az UML mint nevéből is látszik egy modellező nyelv,
és nem tervezési módszer. Egy grafikus jelölésrendszer, amelyet a tervezés fejlesztés során használhatunk, de nem
rögzíti a fejlesztés menetét.
Az UML nyelv két jól elkülöníthető része a jelölésrendszer, és a metamodell. Ebből az első az, amivel általában
találkozunk, mindazok a grafikus jelek, amiket a modellekben használhatunk. A jelölésrendszer mondja meg például,
hogy az osztályok közötti asszociációt egy vonallal kell jelölni. Ez az UML szintaxisa.
A metamodell a nyelv szemantikája. Osztály-diagrammokból áll, és jelölésrendszer definiálja. Az UML használatához
hasznos a metamodell ismerete is, de nem feltétlenül szükséges.

Modellelemek:

• statikus dolgok: osztály, objektum, interfész, Aktor, használati eset stb.

• dinamikus dolgok: aktivitás, folyamat, esemény küldés, fogadás, állapot.
• Csoportosító dolgok: csomag, alrendszer.
• Kommentáló dolgok: megjegyzés.

Diagramok:

Strukturált modellezés: a rendszer struktúráját ábrázoló diagramok.

• Osztálydiagram: megadja a rendszer osztályait, és az azok közötti társítási és öröklési kapcsolatokat. Statikus
modell, amely a rendszerben található összes osztályt és azok statikus kapcsolatait ábrázolja. Az
osztálydiagramban minden osztály csak egyszer szerepel, ha több példány van akkor is.
• Objektumdiagram: megadja a rendszer objektumait (osztálypéldány) és az azok közötti kapcsolatokat. Az
osztálydiagram egy pillanatfelvétele. A objektumdiagram az osztálydiagram egy előfordulása, példánya.
• Komponensdiagram: megadja a szoftver fizikai felépítését.
• Telepítési diagram: megadja, hogy milyen szoftverelemeket milyen hardverre telepítünk.

Viselkedésmodellezés:

• Használati-esetdiagram: megadja, hogy a felhasználó mire tudja használni a rendszert. A diagram

 megmutatja, hogy a rendszer milyen külső felhasználókkal (aktorokkal) áll kapcsolatban és hogyan.
• Szekvenciadiagram: aktorokat, objektumokat és az azok közötti kapcsolatokat ábrázoló diagram. Olyan
interakciódiagram, mely az idő múlására helyezi a hangsúlyt.
• Együttműködési diagram: az objektumoknak a probléma megoldásában való együttműködését mutatja be.
Olyan, konkrét objektumokat tartalmazó diagram, amely az objektumok közötti dinamikus kapcsolatokat
ábrázolja. Tartalmazza az objektumok közötti ismertségi, illetve tartalmazási (egész-rész) kapcsolatokat is. Az
objektumok közötti információcsere üzenetekkel történik, ezeket olyan nyilakkal ábrázoljuk, amelyekre
ráírhatjuk az üzenet nevét, és meg is számozhatjuk őket, ahhoz, hogy az eseményeket relatíve rendezettséggel
tüntessük fel.
• Állapotdiagram: egy adott osztály vagy alrendszer állapotváltozásait írja le.
• Aktivitás-diagram: leír egy folyamatot (tevékenységek egymásutánját).

Osztályleírás:

Az osztály jelölése UML-ben: egy három részre osztott téglalap jelöli

• felső része az osztály nevét mondja meg
• a középső az adatait
• alul a metódusok vannak

Osztály
Objektum : Osztály
adatok
állapot

metódusok

Az osztálydiagramban szereplő osztályok téglalapjaiban csak a legfontosabb információk férnek el. Ezért minden olyan
osztály, amely a feladatra nézve specifikus (azaz nekünk kell megalkotni) valahol részletesebben ki kell fejteni. Az
osztályleírás (az osztály dokumentációja) a következőket tartalmazza:

• Osztály neve
• feladatleírás
• közvetlen ős
• objektumok száma (opcionális)
• kapcsolatok (opcionális) az osztály más osztályokkal való kapcsolatait, itt írjuk le, hogy az osztály milyen
egyéb osztályokkal objektumokkal működik együtt.
• Adatok (az összes adat) az osztálydiagramon az adatról csak kevés információt tudunk jelölni, itt megadható az
összes adat neve, típusa, értékhatárai, beviteli formátuma, korlátozások, magyarázat, példák.
• Metódusok (röviden a feladatukat) itt röviden leírjuk a metódusok feladatát szövegesen és/vagy
pszeudokóddal.
 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.

A kliensoldali programozás alapelemei az Internetes alkalmazások fejlesztésénél:

A tisztán kliens oldali megoldások esetén a kibővített térinformatikai funkcionalitást a kliens számítógépen futó
alkalmazás biztosítja. Ezt a megoldást vastag kliens megoldásnak is nevezik, mivel a munka nagyobbik része a kliens
számítógépen folyik, a hálózati sávszélesség mellett a kliens számítógép teljesítménye a meghatározó. A Web szerver
az adatokat, esetleg a letöltendő programokat szolgálja. A szerver oldalon nincs szükség speciális térinformatikai
igények támogatására. Ezt a legtöbbször a Java Applet vagy a böngészőbe beépülő modul (plug-in) segítségével
valósítják meg. Ez a megoldás már nem csak raszteres képek, hanem vektoros térképek publikálását is lehetővé teszi.

A kapcsolódó technikák rövid bemutatása:

Az Apple-etek speciális Java nyelven írt programok, melyeket a böngészőből futtathatunk, amennyiben a
számítógépünkre telepítettük a Java Runtime Enviroment (JRE) megfelelő verziójú változatát. Az Apple-et nem kell a
kliens gépre telepíteni, a szerverről automatikusan letölti a böngésző program, ha valamelyik HTML oldal egy Java
Apple-et használ. Az Apple-etek hívását a HTML kódban az <applet..> </applet> elemek segítségével valósíthatjuk
meg.

Az <applet> elemben számos paraméter adható meg. A coce paraméter határozza meg, hogy melyik Java osztály
végrehajtásával indul az applet, ennek az osztálynak a Java standard Applet osztályból kell származnia (extends
Applet). A width és height paraméter az applet által elfoglalt képernyő terület méretét adja meg pixelben. Ezt a méretet
nem tudja megváltoztatni az applet. A archive paraméter tartalmazza a használt java archive (jar/zip) fájlokat vesszővel
elválasztva.

A HTML 4.0 specifikációban az <apple> elem helyett az <objekt> elem használatát javasolják. A manapság használt
böngészők mindegyike támogatja még az <apple> elem használatát is

A Java nyelv tartalmazza az alapvető grafikus elemek/objektumok halmazát (awt/Beens stb.), segítségével készíthetünk
olyan Apple-et, mely a szerveren lévő térinformatikai adatbázisok tartalmát megjeleníti a kliens számítógép monitorán.
Miután már többen felismerték ezt a lehetőséget és ilyen funkcionalitással bíró Apple-et, könyvtárat készítettek. Ebben
az esetben a térinformatikai adatoknak és az Apple-eteknek ugyanazon a számítógépen kell lennie, ugyanis egy applet
csak azon a számítógépen nyithat meg fájlokat, ahonnan letöltötték. Ez elsősorban a kliens számítógép védelmét
szolgálja (pl. vírus). Az ilyen Apple-etek használatához nincs szükség Web szerverre, ha a kliens számítógépre
telepítették az Apple-et és az adatokat is. Tehát ez a megoldás nem csak internetes elérést biztosít, hanem az intraneten
belül (akár egy szóló számítógépen) is használható.

Ilyen applet például a Jshape és a GeoTools.

Kliensoldali script nyelvek használata:

HTML: (angolul: 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 HTML dokumentumot két részre lehet bontani a
fejlécre és a dokumentumtörzsre. (egy harmadik rész lehet a keretek definíciója.)
A dokumentumot a fejlécelemek vezetik be, aminek kezdetét a <HEAD> ztasítás jelzi. A fejlécelemek között szokás a
dokumentumcímet megadni, mely címet a <TITLE> és a </TITLE> utasítások közé kell zárni. A fejlécet a </HEAD>
utasítás zárja. Ezt a részét a dokumentumnak általában az ablak címsorában jelenítik meg a böngészőkprogramok.

A dokumentumtörzs (amit voltaképpen a WEB-böngésző meg fog jeleníteni) a fájl <BODY> és </BODY> utasítások
közötti része. Ezen elemek között kell elhelyezni mindent: a szöveget, hivatkozásokat, képeket, stb. (a keretek és a
JavaScript kódok kivételével!)

XHTML: a HTML dokumentumokhoz hasonlóan az XHTML is ugyanazt a szerkezetet követi, tehát rendelkezik
vezérlőinformációkat tartalmazó fejléccel, illetve törzzsel. Értelemszerűen az utóbbiban található a képernyőn
megjelenő tartalom, mindazon címekkel, amelyek hatására a böngésző megformázza a dokumentumot.

Az XHTML család dokumentumtípusai XML alapúak, és tulajdonképpen arra is lettek tervezve, hogy
együttműködjenek az XML alapú felhasználói alkalmazásokkal. A HTML-t XML-ben újradefiniálták, ez a nyelv az
XHTML, ahol az X utal arra, hogy ez a HTML nyelv az XML szintaxist követi. Az XHTML a jelenlegi és jövőbeni
dokumentumtípusok és modulok családja, amik reprodukálják, részét képezik, és kiterjesztik a HTML 4-et. A
különbség főleg a jól formázottságban jelenik meg, ami egy XML dokumentum alapkövetelménye. Az XHTML család
dokumentumtípusok tehát XML alapúak, és végül is arra lettek tervezve, hogy együttműködjenek az XML alapú
felhasználói alkalmazásokkal. Az XHTML 1.0 az első dokumentumtípus az XHTML családban, amely 2000. január 26-
án publikáltak a W3C honlapján. Ez a verzió a három HTML 4 dokumentumtípus (Strict, Transitional, Frameset)
megújítása, XML 1.0 alkalmazásként.

XML: az Extensible Markup Language (XML) megjelenése jelentős változást hozott az internetes térinformatikai
formátumokban is. Az XML egy egyszerű, nagyon rugalmas szöveges formátum, amit az SGML alapján dolgoztak ki.
Előnye még, hogy a szöveges formátum miatt platformfüggetlen, a számítógép architektúrák (LSB/MSB) és az
operációs rendszerek közötti különbségek nem okoznak problémát. Eredetileg nagyméretű elektronikus publikációkhoz
tervezték, de napjainkban egyre szélesebb körben alkalmazzák az internetes adatátvitel területén, így a térinformatikai
adatok esetében is. Sikerét annak is köszönheti, hogy ingyenes, nyílt-forráskóddal rendelkező eszközök állnak a
fejlesztők számára, az XML állományok értelmezése (paser), például a xerces Java paser.

Az XML elsősorban az internetre készült, így alkalmazható különböző dokumentumok „webws” publikására,
feldolgozására. Formátuma automatikusan generálható különböző más formátumokba, mint pl. HTML vagy PDF.

CSS: sz angol Cascading Style Sheets kifejezés rövidítése, jelentése rangsorolt stíluslapok. A stíluslapot egy szöveges
fájlban kell megírni, amit .css kiterjesztéssel kell elmenteni.

Az egyre szélesebb körben elterjedő CSS stílusnyelv népszerű XHTML, illetve XML formázási lehetőség.
Szövegfeldolgozás során a megjelenítéshez leginkább ennek az utasításkészletét kell igénybe venni, ráadásul a
böngészők is mind a mai napig ezt támogatják kifogástalanul.

A CSS megjelenését a HTML fejlesztői örömmel fogadták, mert meglátták benn a HTML-ből hiányzó speciális
lehetőségeket.

A stíluslapok alkalmazásának még egy nagy előnye van. Használatukkal hatékonyabbá, gyorsabbá és rugalmasabbá
tehetjük a webszerkesztést, elfelejthetjük a frame-eket, a „lassan” töltődő táblázatokat, a korlátozott formázási
lehetőségeket stb., segítségükkel átláthatóbbá tehetjük forráskódjainkat.

A CSS jelentése egymásba ágyazott stíluslapok. A HTML oldalak megjelenését befolyásoló egszerű nyelv, mely
segítségével meghatározhatjuk, hogy hogyan (és hol) jelenjenek meg az egyes HTML elemek. (paragrafusok, címsorok,
stb.) többek között befolyásolhatjuk a színüket, méretüket, elhelyezkedésüket, margóikat, stb. ezzel a módszerrel sokkal
szabadabban, rugalmasabban tudjuk kezelni HTML oldalaink megjelenését. Az egymásba ágyazhatóság (kaszkádolás)
arra utal, hogy több stíluslapot, meghatározást is megadhatunk egyszerre, illetve egy stílus lehet több elemre is
érvényes, amit egy másik stílussal felüldefiniálhatunk. A stílusok öröklődnek az oldal hierarchiája szerint, ha például e
gyökér elemre definiálunk egy stílust, akkor többnyire az oldal összes elemére érvényes (a tulajdonságok
örökölhetőségétől függően). Egy stílus több dokumentumhoz is hozzárendelhetünk, ezzel egységes megjelenést
biztosíthatunk számukra. Egy dokumentumhoz pedig több stíluslap is csatolható.

XSL: (eXtensible Stylesheet Language) a legújabb megjelent szedési nyelv, szintaxisának alapjául az XML szolgál.

Kezdetben az XSL-t egy olyan egyszerű nyelvnek szánták, amely az összes lehetséges transzformációt el tudja végezni
a jelölt szövegben. Ez az elképzelés azonban kivitelezhetetlen volt, hiszen a nyelv ilyen formában meglehetősen
bonyolult lett volna. A problémát úgy sikerült megoldani, hogy a nyelvet két összetevőre bontották szét, vagyis
létrehozták az XSLT (eXtensible Stylesheet Language Transformation) ajánlást, ami SGML/XML struktúrák közti
átalakításokra használható; és az XSL-FO-t (XSL Formatting Objeckts), ami pedig egy hagyományos stíluslap
lehetőségeit kínálja megjelenésbeli stílusok, formák, helyzetek meghatározására. Az Xpath a dokumentumot
csomópontok (node-ok) halmazának tekinti. A node lehet bármilyen alkotórész; elem, attribútum, attribútumérték stb. e
három nyelv együttesen alkotja tehát a bővíthető stíluslapnyelv családot.

Gyakran előfordul, hogy az XSL és az XSLT kifejezéseket összekeverik és helytelenül használják még fejlesztők is, de
a leírtakból már érthetőek a különbségek és az összefüggések.

A kliensoldali script nyelvek használata:

A böngészők (pl.: Navigator 2.0 és későbbi verziók) képesek értelmezni a HTML oldalakba ágyazott kliensoldali
JavaScript utasításokat. Amikor a böngésző (vagy kliens) egy ilyen oldalt kér le, a szerver a hálózaton keresztül elküldi
a dokumentum teljes tartalmát a kliensnek, a HTML és a JavaScript utasításokkal együtt. A böngésző elolvassa az oldalt
az elejétől a végéig, megjeleníti a HTML utasítások eredményét és végrehajtja a JavaScript utasításokat, azok
előfordulásának sorrendjében. Ez a folyamat, ahogy a lenti ábrán látható, hozza létre a felhasználó által látott
végeredményt.

A HTML oldalakba ágyazott kliensoldali JavaScript utasítások válaszolhatnak a felhasználói eseményekre

(egérkattintás, űrlap adatbevitel, stb...). például, írhatunk olyan JavaScript függvényt, amely ellenőrzi, hogy a
felhasználó által beírt adatok érvényesek-e (telefonszám, irányítószám, stb...). a HTML oldal beágyazott JavaScript
minden hálózati adatátvitel nélkül meg tudja vizsgálni a beírt adatot és ha a felhasználó érvénytelen adatot írt be, arra
párbeszédablak megjelenésével figyelmezteti.

A kliensoldali Scriptek olyan programrészletek amelyek forrásnyelvi alakban a HTML dokumentum keretében
töltődnek le a felhasználó számítógépére.

A scripteket a böngészőprogram hajtja végre.

 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 szerveroldali programozás (Server-Side Scripting) esetében a szerver oldali scriptek a Web szerveren futnak le és
dinamikus HTML oldalakat hozhatnak létre.

Az egyik legelterjedtebb szerveroldali programozási technológia az ASP Active Server Pages. Az ASP a Microsoft
technológia (1996), úgy tervezték, hogy a Web oldalak tartalma minden új beolvasás esetében megváltozhat. Alapelve:
a Web oldalba olyan programkódot építünk be, amely a szerveroldalon lefut mielőtt a felhasználó böngészője beolvassa
a Web lapot.

A szerveroldali programozás előnye könnyen megérthető a következő példából:

• célkitűzés: az aktuális dátum leolvasása a Web lapról
• statikus HTML oldalon minden nap be kell írni az aktuális dátumot.
• Az ASP technológia lehetővé teszi egy script megírását amely a beolvasott Web lapon megjeleníti az aktuális
dátumot. Mielőtt a felhasználó beolvassa a Web lapot, a szerver lefuttatja a scriptet és így a beolvasott Web
lapon mindig az aktuális dátum jelenik meg.

A szerveroldali programozás több szempontból is lőnyös a Web fejlesztő számára:

1. a szerveroldali scriptek fejlesztése teljesen független a felhasználó által alkalmazott böngészőtől.

2. Így a szerveroldali scripteket olyan programnyelveben is fejleszthetjük amelyet a felhasználó böngészője nem
támogat.
3. A szerveroldali scriptek forrásnyelvi változata nem olvasható a felhasználó böngészőjében. Ez fontos
momentum a forrásnyelvi változat védettsége szempontjából.
4. A letölthető HTML dokumentum mérete csökken (mivel a böngészőben csak a szerveroldali scriptek
végrehajtási eredménye látszik). Így a Web oldal beolvasása is gyorsabb.
5. Egy szerveroldali komponens alkalmazásával leolvashatjuk a felhasználó gép operációs rendszerét és
böngészőprogramját, így a szerveroldalról leküldött HTML dokumentum a kliens gép környezetére alakítható.
6. Az ASP fájl az adatbázis szerverről adatbázist használhat fel a megjelenítendő Web lap feldolgozására.

A szerveroldali objektum bemutatása:

A JavaScript alkalmazások egy része a kliensen, más része a szerveren fut. Számos JavaScript alkalmas a LiveWire
nevű adatbázis-szolgáltatást használva önmagát egy relációs adatbázishoz kötni. Ebből kifolyólag a JavaScript
alkalmazásokat úgy kell elképzelnünk, mint egy háromsoros kliens-szerver architektúrát.

A három rész az alábbi:

1. WWW kliens (Internet Explorer, Netscape Navigator, Flock)

2. WWW szerver/adatbázis kliens
3. adatbázis-szerverek

A JavaScript kliens-oldali környezete WWW kliensek részeként fut. A JavaScript szerver-oldali környezete a
webszerver részeként fut, mely egy vagy akár több adatbázis-szervert is elér. A JavaScript futásidejű környezetnek
három elsődleges komponense van:

1. A JavaScript futásidejű könyvtár

2. LiveWire adatbázis-elérés könyvtár
3. Java virtuális gép (JVM)

A kliens által értelmezhető scipteket azért használjuk, mert a webböngészőkben beépített interpreter van. Egy
JavaScript alkalmazást futtatva számos dolog bekövetkezhet, akár a kliensen, akár a szerveren. Egy alkalmazás
fejlesztése közben mind kliens-oldali, mind szerver-oldali JavaScript utasításokat tartalmazó HTML oldalakat írunk. A
HTML forráskódban a kliens-oldali scripteket a SCRIPT tag, a szerver-oldaliakat a SERVER tag határolja.

Olyan állományokat is létrehozhatunk, melyek pusztán JavaScript utasításokat tartalmaznak és egyetlen HTML tag
sincs bennük. Egy ilyen külső scriptfájl vagy kliens-oldali vagy szerver-oldali JavaScriptet tartalmazhat. Nincs
lehetőség egy külső fájlban kliens és szerver-oldali objektumok vagy függvények egyidejű használatára. A globális ( a
<SERVER> és </SERVER> tag-ek között deklarált) változók használatát célszerű a minimálisra korlátozni, az
alkalmazásokban a lehető legtöbb részt függvényekkel megoldani. Ezzel jelentősen javíthatjuk az alkalmazások
működését.
Adatbázis-kezelés webűrlapokkal

Web megoldásokat nyújtó adatbázis-kezelők: a nagy adatbázis-kezelők gyártók hamar felismerték a Web technológia
által nyújtott előnyöket. Ma már nincs olyan rendszer, amely ne kínálna valamilyen megoldást a Web és az adatbázisok
összekapcsolására. A megoldások azonban nem egységesek, ahány gyártó annyi technológia. Ki lehet azonban emelni
néhány általánosan nyújtott szolgáltatást, mint pl. a dinamikus HTML generálás, a CGI támogatás, a Web szerverek
API-jeinek támogatása és a Java támogatás.

Az adatbázis-kezelő gyártók természetesen fejlesztő eszközöket is kínálnak termékeikhez. Ezek az eszközök azonban
ma még elég kiforratlanok és használatukhoz az illető rendszer alapos ismerete szükséges. Ráadásul az ügyfél oldali
fejlesztőeszközök általában csak egy adatbázis-kezelő rendszerrel használhatóak, amely óriási hátrány a kliens-szerver
technológia adatbázis-kezelő független fejlesztő környezeteivel (pl. Depphi) szemben.
Webes felületű adatbázis-kezelők: DB2 (IBM), Oracle (Oracle), SQL Server (Microsoft).

Egy szerveroldali programnyelv rövid bemutatása, jelentése:

Szerveroldali JavaScript: HTML oldalakba szerveroldalon is beágyazható JavaScript. A szerveroldali utasítások

különböző gyártók relációs adatbázisait kapcsolják össze, megoszthatják egy alkalmazás adatait a felhasználók között,
hozzáférést nyújthatnak a szerver fájlrendszeréhez, vagy a LiveConnect és Java használatával kommunikálhatnak más
alkalmazásokkal. A szerveroldali JavaScript-tel ellátott HTML oldalak magukban foglalhatnak kliensoldali JavaSript
utasításokat is.

Az egyszerű kliensoldali JavaScript oldalakkal szemben, a szerveroldali JavaScriptet használó HTML oldalak byte-
kódba fordított végrehajtófájlok. Ezek a végrehajtó alkalmazások a webszerveren futnak, ahol rendelkezésre áll a
JavaScript futás idejű motor. Ez okból a JavaScript alkalmazások létrehozása kétlépcsős művelet.

Az első lépcsőben létre kell hozni a HTML oldalakat (amelyek tartalmazhatnak kliens-oldali és szerver-oldali
JavaScript utasításokat is) és javascript állományokat. Ezek után az összes fájlt egy végrehajtó állományba kell
fordítani.

A második lépcsőben az alkalmazás egyik lapját lekéri egy kliens böngésző. A futásidejű motor a végrehajtó
alkalmazást használja, hogy kikeresse a forrásoldalt és dinamikusan létrehozza az elküldendő HTML oldalt. Az futatt
minden szerveroldali JavaScript utasítást, ami az oldalon található. Az utasítások eredménye a HTML oldalhoz adhat új
HTML elemeket, vagy kliensoldali JavaScript utasításokat is. A futásidejű motor ezután a hálózaton keresztül elküldi a
kész oldalt a böngészőkliensnek, amely lefuttatja a kliensoldali JavaScripteket és megjeleníti a végeredményt.
 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,
jellemzése.

Az informatikai biztonság fogalma: a védelmi rendszer olyan, a védő számára kielégítő mértékű állapota, amely az
informatikai rendszerben kezelt adatok bizalmassága, sértetlensége és rendelkezésre állása szempontjából zárt, teljes
körű, folyamatos és a kockázatokkal arányos. ( Az informatikai biztonság alatt a szervezeti tevékenységek
informatikai összetevőinek a célok eléréséhez szükséges megfelelő állapotban tartását értjük.)

Biztonsági rendszer tervezése: az informatikai rendszer létrehozása után pótlólagosan végrehajtott biztonsági
intézkedések, utólagosan beillesztett biztonsági elemek többszörös költséggel valósíthatók meg. Sajnos az általuk elért
biztonság mértéke sem azonos a rendszerkialakítással egy időben és szoros kapcsolatban végrehajtott biztonsági
fejlesztés eredményével.

A biztonságos informatikai rendszerek létrehozásánál többféle módszert lehet alkalmazni, amelyek a vizsgált
folyamatok, illetve az eljárás lépéseinek tagolásában különböznek egymástól. Egy informatikai biztonsági rendszer –
mint minden rendszer – tervezése sok lépésből álló, sokféle szaktudást igénylő, bonyolult feladat.

Tervezés szakaszai: az informatikai biztonság tervezésénél és megteremtésénél a következő kérdések merülnek fel:
• milyen információk szükségesek a szervezeti célok eléréséhez?
• Adott információkat milyen fenyegetések érhetik?
• Hol jelennek meg az információk a rendszerben?
• Adott helyen milyen okok válthatják ki a kárt okozó esemény bekövetkezését?
• Mi a kockázata a fenyegetésnek?
• Gyakorlatilag lehetséges-e, illetve megéri-e az adott intézkedés?
• Milyen konkrét feladatok adódnak az elhatározott intézkedésekből?

Az informatikai biztonsági rendszer tervezését – feltett kérdéseknek megfelelően – a következő szakaszokra lehet
felbontani :

I. Védelmi igények feltárása:

◦ Helyzetfelmérés: az első lépés a helyzetfelismerés és célmeghatározás. Ennek a szakasznak az a célja,
hogy reális és teljes képet kapjunk a védendő rendszer felépítéséről, tartalmáról. E szakaszban valamennyi
adott informatika-alkalmazást és feldolgozandó adat közül ki kell választani azokat, amelyek az adott
szervezet számára jelentőséggel bírnak, így védelmet igényelnek.
◦ Értékelés: felhasználó védelmi céljainak a leírása, az ötrészes értékskála rögzítése, az értékek
hozzárendelése az informatika-alkalmazásokhoz és az adatokhoz.
II. Fenyegetettség elemzés: ebben a lépésben meghatározzuk a rendszer gyenge pontjait és valamennyi
elképzelhető fenyegető tényezőt, amelyek kárt okozhatnak az informatikai rendszerben. Különösen ügyelni
kell arra, hogy egyetlen fontosabb fenyegetettséget se hagyjunk ki, miután a kockázatelemzés ennek
eredményeire épül, ha ez nem teljes körű, az a biztonsági rendszer súlyos hiányához vezethet.
◦ A fenyegetett rendszerek feltérképezése.
◦ Az alapfenyegetettség meghatározása.
◦ Hardver.
◦ Az adathordozók.
◦ A dokumentumok.
◦ A szoftver.
◦ Az adatok.
◦ A kommunikáció.
◦ Személyek, felhasználók.
III. Kockázatelemzés: ebben a szakaszban is szubjektív módszerekkel lehet dolgozni, mint a biztonsági
igényeknél. A károk gyakoriságának meghatározása is elsősorban a tapasztalatokon alapszik.
◦ Az értékek átvitele a rendszerelemekre.
◦ A károk áttekintő ábrázolása.
IV. Kockázat-menedzselés: az előző szakaszokban meghatároztuk és értékeltük az egyes fenyegető veszélyeket.
Most meg kell határozni azoknak az intézkedéseknek a körét, amelyeket védelmükre hozunk. Aztán a
intézkedések hatékonyságát értékeljük, majd elemezzük, hogy milyen költségekkel járnak és milyen hasznot
hoznak. Végül a maradványkockázatokat elemzésével zárul a szakasz.
◦ Az intézkedések kiválasztása.
◦ A költség/haszon arány elemzése.
A kockázatelemzés célja és lépései: ebben a szakaszban a szakemberek gyakorlati tapasztalataikra támaszkodva
vizsgálják a rendszert. További szakaszokra bontható:
• A fenyegetett rendszerek értékelése: az értékek átvitelét befolyásolják a feltérképezett gyenge pontok és
védelmi intézkedések is. Azokat a tényezőket és megfontolásokat, amelyek egy érték megváltozásához
vezettek, feltétlenül dokumentálni kell. Amennyiben egy rendszerelemtől több informatikai alkalmazás vagy
információ függ, akkor az adott rendszerelemnek a legmagasabb előforduló értéket kapja. Például, ha egy
lemezes tároló különböző adatokat tárol, akkor a legfontosabb információnak az értékét adjuk neki. Azok a
rendszerelemek, amelyek más rendszerelemek védelmére szolgálnak – azaz valamely védelmi intézkedés
részei – azon elemek értékeit kapják meg, amelyet védeniük kell.
• Károk gyakoriságának meghatározása: a lépés során annak becslése történik meg, hogy milyen gyakran
következik be valamely fenyegető tényező hatása és okoz kárt valamely rendszerelemben. Több
rendszerelemet összevonhatunk un. Közös rendszerelemmé is, ha ugyanazok a fenyegető tényezők lehetnek
hatással reájuk. De törekedni kell arra, hogy az egyes rendszerelemek felismerhetők maradjanak, miután egyes
finomításokra később is szükségünk lehet. A befolyásolhatatlan külső tényezők (vis major), valamint a
bűncselekmény eredetű események vonatkozásában kiinduló értékeket adhatnak a biztosítási és bűnügyi
statisztikák és a gyakorlati szakemberek tapasztalatai. Az ilyen becslések kiindulópontjaként azon személyek
száma szolgálhat, akiknek bejutási lehetőségük van az informatikai rendszerbe, és akik kielégitő ismeretekkel
és képességekkel rendelkeznek egy támadáshoz.
• Fennálló kockázat értékelése: ezen lépés a kockázatbecslési mátrix meghatározása. A kockázatokat úgy kell
ábrázolni, hogy a nagyobb kockázatok könnyen azonosíthatók legyenek és felismerhető legyen, hogyan
alakultak ki ezek a kockázatok. Meg kell állapítani a döntési tábla alapján, mely kárnagyságból és gyako-
riságból összetevődő értékpárok jelentenek elviselhető kockázatot és melyek nem.

Az informatikai rendszerek elleni támadások típusai: a támadások kielemzése nagyon körültekintő vizsgálódást
igényel, a szakmai tapasztalat elengedhetetlen a tervezők részéről.

Támadási felületek lehetségességeinek elemzése: ebben a lépésben meghatározzuk a rendszer gyenge pontjait és
valamennyi lehetséges támadási felületet. Ebben az esetben tevőleges fenyegetésről van szó, ami vagy közvetlen az
ezzel a szándékkal fellépőtől származik, vagy mások figyelmetlenségét kihasználva áttételes formában történik.

Fenyegetett rendszerek feltérképezése: támadás az informatikai rendszer valamennyi elemén keresztül történhet.
Ezek a következők:
• környezeti infrastuktúra,
• hardver,
• adathordozó,
• dokumentumok,
• szoftver,
• adatok,
• kommunikáció
• személyek.

A környezeti infrastruktúra: ide tartoznak a számítóközpont épületének területe, maga az épület, az épületben lévő
helyiségek, átviteli vezetékek, áramellátás, klíma, víz, világítás, telefon, és különböző rendeltetésű berendezések
(belépés-ellenőrző, tűzvédelem, betörésvédelem).

Gyenge pontok:
• Nem védett átviteli vezetékek, kábelek, informatikai berendezések
• Illetéktelen személyek felügyelet nélküli jelenléte, vagyis a belépési biztonság hanyag kezelése.
• A védelmi berendezések működési módjának vagy gyengeségeinek jogosulatlanok általi megismerése.

Fenyegető tényezők:
• „Vis major”: robbanás, repülőgép lezuhanása, sztrájk, háborús helyzet.
• Személyek által kifejtett erőszak: robbantásos merénylet, fegyveres behatolás, gyújtogatás, savazás,
vandalizmus, betörés.
• Jogosulatlan személyek ellenőrizetlen belépése épületekbe helyiségekbe, a szervezeten kívüli személyek által
végzett, nem felügyelt munkálatok.
• Közműellátás: (áram, víz, telefon) és védelmi berendezések zavara vagy kiesése.

Hardver: ide tartoznak a számítástechnikai eszközök a hálózati csatoló eszközök a hálózat építő eszközök, speciális
biztonsági berendezések.
Gyenge pontok:
• Eltulajdonítás: a készülékek csekély mérete, súlya miatt a lopás könnyen lehetséges.
• Külső behatások miatti meghibásodás: hőhatás, vízzel való elárasztás, érzékenység az elektromágneses
sugárzásra, mechanikai behatásokra.
• Tartozékok utánpótlásának szervezetlensége: pótalkatrészek, printer festékek.

Fenyegető tényezők:
• Tervezési és kivitelezési hiányosságok.
• Személyekkel összefüggő fenyegetés: készülékek károsítása vagy roncsolása, ellopása, jogosulatlan szerelés és
alkatrészcsere.

Az adathordozók: ebbe a csoportba tartoznak a raktározott állapotú szoftverek, a biztonsági másolatokat,

munkakópiákat, archív adatokat jegyzőkönyvi adatokat tartalmazó adathordozók, valamint az újonnan beszerzett és
még használatba nem vett, illetve a felszabadított adathordozók melyek tartalmára a továbbiakban nincs szükség.

Gyenge pontok:
• Fizikai instabilitás: érzékenység a behatásokra.
• Kikapcsolható írásvédelem.
• Könnyen szállíthatóak, a szállítás nehezen ellenőrizhető.

Fenyegető tényezők:
• Újrafelhasználásra vagy megsemmisítésre történő kiadás előzetes törlésük, felülírásuk nélkül.
• Ellenőrizetlen másolás illetve hozzájutás az adathordozókhoz.
• A szervezet tulajdonát képező adathordozók privát célú használata és privát adathordozók szolgálati
használata.

A szoftver: ebbe a kategóriába csak a használatban lévő szoftverek tartoznak, a raktározott állapotú szoftvereket az
adathordozóknál tárgyaltuk.

Gyenge pontok:
• Specifikációs hiba, a programok átvételének és ellenőrzésének hiánya.
• Bonyolult felhasználói felület, felhasználó hitelesítés hiánya.
• Az események hiányzó jegyzőkönyvezése (például belépés, CPU használat, fájlok megváltoztatása).
• A rendszer védelmi eszközeinek könnyű kiismerhetősége.
• A hozzáférési jogok helytelen odaítélése.
• Más felhasználók ismeretlen programjainak használata (vírusfertőzés).

Fenyegető tényezők:
• Jogosulatlan bejutás az informatikai rendszerbe a kezelői helyről vagy a hálózatról.
• Visszaélés a kezelési funkciókkal.
• Szoftver ellenőrizetlen bevitele, vírusveszély.
• Karbantartási hiba vagy visszaélés a karbantartási funkciókkal, helytelen karbantartási funkciók (távoli karban
tartás a hálózaton keresztül)

Kommunikáció: ezen elemcsoport tárgya valamennyi adat továbbítási ideje alatt, amelyeket valamely szolgáltatás
realizálása érdekében hálózaton továbbítanak. A hálózatok lehetnek az üzemi területen belül (például LAN-ok) vagy
azon kívül (például közüzemi hálózatok), illetve e kettő kombinációja. A kommunikációhoz szükséges hardvert
mindaddig, amíg az informatikai rendszer üzemeltetőjének felelősségi körén belül van, a hardver elemcsoportban, a
vezetékeket pedig, amennyiben az üzem területén belül vannak, a környezeti infrastuktúra elemcsoportban
szerepeltetjük.

Gyenge pontok:
• A hálózati szoftver és hardver hibái, azok manipulálhatósága.
• Üzenetek lehallgatása, meghamisítása, az adó és a fogadó hiányzó azonosítása.
• A jelszavak vagy titkos kulcsok nyílt szövegben való továbbítása.
• Függés az átvitel sorrendjétől.
• Lehetőség az üzenet elküldésének, kézhezvételének hiányzó bizonyítása.

Fenyegető tényezők:
 • Jogosulatlanok bejutása a hálózatba nem ellenőrizhető csatlakozások révén.
• Hálózati hardverek/szoftverek manipulálása, átviteli hibák.
• Nem várt forgalmazási csúcsok. Célzott terhelési támadások.
• A vezetékek kompromittáló sugárzásának kihasználása.
• A kapcsolat felépítésének lehallgatása

ADÓ VEVŐ

TÁMADÓ
a lehallgatásnál a támadó illetéktelenül rákapcsolódik az átviteli vonalra, az ott folyó adat- és kulcs-forgalmat figyeli. Az
üzenetek gyűjtésével, különleges helyzetek észlelésével támadhat.

• A kommunikációs kapcsolatok kikutatása (forgalmazás elemzés), a kommunikációs partnerek névtelenségének

veszélyeztetése.
• A kapcsolat felépítése meghamisított azonossággal, megszemélyesítéssel.

ADÓ VEVŐ

TÁMADÓ

A megszemélyesítés esetén a támadó beépül a kommunikációs összeköttetésbe, az üzeneteket elnyeli, és az ellen-állomások

helyett válaszol mindkét irányba. Különös veszélyforrás lehet, ha a támadó az egymással kommunikáló állomásokat
sorozatos ismétlésre kényszeríti, esetleg ugyanazon üzenet két különböző rejtjelezett variációját szerzi meg, vagy
valamelyik állomásról ismert választ kényszerít ki, amellyel megszerzi annak rejtjelezett változatát.

Személyek: e csoportba csak olyan személyek szerepelnek, akikre közvetlenül vagy közvetve szükség van az
informatikai rendszer használatához, ezáltal hozzáférhetnek a másik hét csoport elemeihez. A személyeket két
nézőpontból kell figyelembe venni: egyrészt az üzemeltetéshez szükség van rájuk, ebből következően ők maguk is
védelemigényes rendszerelemek. Másfelől viszont ők bírnak a belépés és a bejutás lehetőségével, ebből következően a
fenyegetések jelentős része rajtuk keresztül realizálódik.

Gyenge pontok:
• A munkából való kiesés, hiányos kiképzés, a veszélyforrások ismeretének hiánya, a fenyegetettségi helyzet
lebecsülése.
• Kényelmesség, eltérő reakciók.
• Hiányzó vagy hiányos ellenőrzés.

Fenyegető tényezők:
• Szándéktalan hibás viselkedés: stresszhelyzet, fáradság, hiányos ismeretek, hibás szabályozás, az előírások
ismeretének hiánya miatt, az információk gyanútlan kiadása.
• Szándékos hibás viselkedés: az előírások megsértése, fenyegetés, zsarolás, megvesztegetés, haszonszerzési
célból, bosszú, frusztráció miatt.

Támadás típusok:
• Hozzáférés megszerzése.
• Jogosultság kiterjesztése.
• Szolgáltatás bénító támadások (DoS)
• Elosztott szolgáltatás bénítás (DdoS)
• Hamis megszemélyesítés, jogosultság szerzése.
• Sebezhetőségek kihasználása.
• Hálózati eszközök támadása.

A leggyakrabban előforduló támadások ismertetése:

Szolgálatmegtagadás típusú támadások (Dean of Service, DoS): a szolgálatmegtagadás típusú támadások lényege,
hogy egy rosszindulatú személy olyasmit tesz a hálózattal vagy a kiszolgálóval, ami zavarja a rendszer működését,
lehetetlenné teszi a munkavégzést. (Pl. elárasztjuk a gépet pingekkel, ekkor nem rad ideje más, hasznos
tevékenységekre.) Egy ilyen támadásból nem sok haszna lehet egy kalózank, betörni nem tud a rendszerbe, csak épp
működésképtelenné teheti azt. Több ilyen módszer létezik.

SYN árasztás (SYN flood): a kiszolgáló és az ügyfél közötti kapcsolat felépítése normális esetben úgy zajlik, hogy az
ügyfél elküld egy SYN csomagot, amelyre a kiszolgáló egy SYN-ACK csomaggal válaszol, majd az ügyfél visszaküld
egy ACK csomagot, és megnyílik a kapcsolat. A SYN árasztás lényege, hogy a támadó rengeteg hamis SYN csomagot
küld el egy gépnek, tehát a csomagok látszólag egy olyan gépről érkeznek, amely nem érhetőe el. Ez – hasonlóan a ping
elárasztáshoz – annyira leterheli a megtámadott gépet, hogy annak nem marad ideje a valódi SYN csomagok kezelésére.

Kétfajta védekezési mód van az ilyen támadás ellen: a SYN cookie, illetve az RST cookie. Mindkettő lényege, hogya
mielőtt nekiállna a gép elkészíteni a SYN csomaghoz tartozó kapcsolat-rekordot, további adatot kér az ügyféltől, hogy
meggyőződjön annak létezéséről. (SYN – kapcsolatsorszámot, RST – hibás SYN-ACK csomagot küld vissza, és a
válaszból kiderül, mi a helyzet; az RST nem terjedt el, mert nem Windows-os.)

Land támadások: Hamis forráscímet vagy portszámot tartalmazó SYN csomagot küld a támadó (csak egyet), ezzel
„kiakaszthatja” a célgépet.

Smurf támadások: hasonló a ping elárasztáshoz, de itt a ping csomag broadcast üzenetként kerül elküldésre, és
fejlécében a megtámadott gép címe van feltüntetve, mint feladó. A csomagot akár több száz gép is megkaphatja,
amelyek válaszukat mind a megtámadott gépre küldik. Ez tehát többszörös támadás, mert közben a válaszadó gépeket is
leterheljük.

Védekezni ellene úgy lehet. Ha a hálózatunkat úgy állítjuk be, hogy routereink ne engedélyezzék az irányított brodcast
üzenetek elküldését.

IP hamisítás (IP spoofing): lényege, hogy az elküldött SYN csomagban nem a csomag tényleges forrása van
feltüntetve feladóként. A célgép válaszol egy SYN-ACK-kal, és vár a válaszra, ami nem jön. Egy idő után elévül a félig
megnyitott kapcsolat, de ha ezalatt újabb ilyen csomagot küldünk, akkor megint csak olyan ciklusba keveredik a gép,
amiből nem tud kijönni. Különbség a Land támadásoktól, hogy ott a TCP/IP megvalósításának hibáját használja ki a
támadó, itt meg simán a kapcsolatnyitási eljárást.

Védekezni csak közvetve lehet: rövid elévülési idők használatával, illetve passzívan úgy, routerünket úgy állítjuk be,
hogy ne engedje ki a hamis forráscímű csomagokat.

Teardrop: lényege, hogy hamis fejlécekkel rendelkező TCP vagy UDP csomagokat küld a támadó a célgépnek,
amelyben az IP-fejléc „azonosítás”, „zászlók” és „darabeltolás” mezőit valótlan adatokkal tölti fel. A célgép ezen
adatok alapján próbálja meg összerakni a teljes csomagot, és lelassul, akár le is fagyhat.

Puffertúlcsordulás: ha túl sok adatot küldünk, és puffertúlcsordulást idézünk elő (az alkalmazás hibáját kihasználva),
akkor a puffer után közvetlenül elhelyezkedő memóriaterületre kerülnek a fölös adatok. Az eredeti adatok innen nyilván
elvesznek. A kiszolgálón lévő adatok tehát megsérülhetnek, vagy akár le is állhat a kiszolgáló. A legveszélyesebb az,
amikor a puffer utáni terület az utasításveremhez tartozik, ekkor ugyanis elő lehet készíteni a túlcsorduló adatokat úgy,
hogy azok új, értelmes utasításokat tartalmaznak. Ezek az utasítások ugyanolyan jogosultságok mellett kerülnek
végrehajtásra, mint az éppen futó program, és így teljes körű hozzáférést kaphat a betolakodó a számítógépbe. (Ezt ki
lehet egészíteni egy olyan támadással, amikor a CGI-t használjuk ki; a CGI programok olyan webkiszolgáló által
futtatott programok, amelyek képesek parancsokat is végrehajtani a kiszolgálóval. Ha vakon elfogadja a weblapon
megadott bemenetet, akkor simán betörhet bárki a rendszerbe (pl. a rendszer jelszavainak kilistázását kiadja
parancsként).)

Trójai falovak: látszólag hasznos programok, amelyek a háttérben azonban bűnös és gonosz dolgokat művelnek.
Ugyanolyan jogosultságokkal rendelkezik a program, mint az azt futtató felhasználó.

Lehallgatott átvitel: az egyik legkényesebb téma a hálózati biztonságban az átvitel lehallgatása. Egyrészt: az
azonosítási folyamat nyitva áll a lehallgatásra, amit megtehet bárki, például egy hálózatfigyelő program használatával.
(ezeket eredetileg hasznos célokra találták ki; Mitniket is ennek segítségével kapták el.) másrészt pedig sok hálózati
szolgáltatás az azonosítás és a jelszó elküldésekor nem használ semmiféle titkosítást, hanem nyers szöveg formájában
röpködnek a bizalmas adatok a neten.
 19.)A megbízható informatikai rendszer alapfunkciói, biztonsági követelményeit szabályozó hazai és nemzetközi
szabályok, ajánlások, dokumentumok. Az informatikai rendszer elleni támadások kivitelezésének eszközei.
Kriptográfiai módszerek és eszközök, azok gyakorlati alkalmazásai.

A demokrácia alapelve, hogy minden polgár megismerheti az őt érintő közügyekre vonatkozó információkat. Másik
oldalról azonban mindenkit megillet a magánélet, a magántitok és a személyes adatok védelméhez való jog. Ez a két
fontos alapelv időnként egymásnak ellentmond, nehéz meghúzni azt a határvonalat, ami a közügyek és a magánügyek
között van. Aki figyelemmel kíséri a közéletet, naponta találkozik a híradásokban ezekkel a problémákkal.

Ez nem új keletű dolog. A 60-as évek társadalmi mozgalmainak központi kérdése volt az egyéni szabadságjoga. Erre az
időszakra tehető - először az államigazgatásban, majd az üzleti életben beindult – számítógépes feldolgozások tömeges
megjelenése is. Ekkor születtek meg az első nagy adatbázisok, amelyek óriási tömegben tartalmaztak személyes
adatokat. Az új technikai eszközökkel sokkal egyszerűbbé vált az adatok összekapcsolása, elemzése. Másik oldalról az
állampolgárok jogot formáltak arra, hogy megismerhessék az állam működésével összefüggő adatokat.

Európai ajánlások: nemzeti szabályozás kevésnek bizonyult azokban az esetekben, amikor az adatok átlépték az
országhatárokat. A nemzetközi ajánlások közös jellemzői:
• egyensúly biztosítása a személyes adatok védelme és az információ szabad áramlása között,
• a nemzeti törvényhozásokban érvényesítse az ajánlásokat,
• azonos adatvédelmi normák érvényesítése mind az állami, mind a magánszektorban.

Nemzetközi megállapodások, ajánlások és egyezmények:

• Európa Tanács 1973. Az egyének magánéletének védelméről a magán, ill. az állami szektorban tárolt
elektronikus adatbankokkal szemben.
• Európa Tanács 1979. A kormányzati dokumentumok nyilvánosságáról és az információszabadságról.
• Gazdasági Együttműködési és Fejlesztési Szervezet (OECD), 1980. A magánélet védelméről éa a személyes
adatok határt átlépő áramlásáról.
• Általános Vám- és Kereskedelmi Egyezmény (GATT), 1993. Egyezmény a szellemi tulajdon kereskedelemmel
összefüggő kérdésekről (TRIPS).
• Európai Unió és az Európa Parlament, 1999. Akcióterv az Internet biztonságos használatának előkészítésére.
Adatvédelem: az adatvédelem adatok meghatározott csoportjára vonatkozó jogszabályi előírások érvényesítése az
adatok kezelése során.

A nemzetközi ajánlások a következő alapelveket fogadták el, amit a nemzeti törvényhozásokban érvényesíteni kell.
1. Meg kell határozni az adatgyűjtés célját, és azt ismertetni kell az adatszolgáltatóval.
2. Korlátozni kell az adatgyűjtés körét, pontosan meghatározva azt, hogy milyen adatokra terjedhet ki.
3. Az adatokat csoportosítani kell, és ezekehez a csoportokhoz kell meghatározni, hogy milyen szabályok
vonatkoznak rájuk.
4. Meg kell határozni azokat az adatcsoportokat, amelyek csak az érintett külön engedélylével tárolhatók.
5. Az állampolgárral ismertetni kell, hogy kik jutnak hozzá az adataikhoz.
6. Biztosítani kell, hogy mindenki hozzáférhessen a róla szóló adatokhoz, és az esetleges hibák kijavítása
megtörténjék.
7. Az adatkezelő köteles az általa tárolt adatok védelmét biztosítani.

Nemzetközi és hazai ajánlások: manapság egy rosszul védett rendszer már nem csak saját magát, hanem a vele
összekapcsolt gépeket is veszélybe sodorhatja. Szükségessé vált tehát egységes elvek és eljárások kidolgozása, amelyek
garantálják az összekapcsolt rendszerek biztonsági „egyenszilárdságát”.

Ezek az elvek szabványok és ajánlások formájában jelentek meg. Nagy előnyük, hogy egységes nyelvet teremtettek az
informatikai biztonsági kérdésekben, jelentősen megkönnyítve ezzel a felhasználók és a gyártók közötti
kommunikációt.

TCSEC: mint általában, ebben is a hadsereg járt az élen: 1985-ben az államok Védelmi Minisztériuma kidolgozta a
TCSEC dokumentumot, vagy más néven a „Narancs Könyvet”.

ITSEC: ezt követően több országban dolgoztak ki hasonló dokumentumokat. A helyi és nagy kiterjedésű hálózatok
elterjedésével, erősödött az igény egy nemzetközi téren egyeztetett dokumentum létrehozására. Európában ez az
Információtechnológiai Biztonsági Értékelési Kritériumok (ITSEC) néven vált közismerté. Kanadában 1993-ban
dolgozták ki a CTCPEC dokumentumot ami ugyancsak ezt a kérdéskört taglalta. Az Egyesült Államok ugyan ez évben
hozta ki az FC-t.
Ezek alapján 1993-ban az Európai Közösség illetékes bizottságában az a határozat született, hogy az ITSEC, a CTCPEC
és az FC szerzői dolgozzanak ki egy olyan követelményrendszert, amely elfogadható lesz és az ISO Nemzetközi
Szabványügyi Szervezet számára ajánlani lehet a szabványosítási munka alapjául.

Ennek a munkának az eredménye lett a CC Közös Követelmények dokumentumtervezet, amely megpróbálja a korábbi
ajánlások tartalmi és technikai eltéréseit összhangba hozni.

Ezzel párhuzamosan az ISO már több informatikai szabványt kidolgozott. Ezek közül az a1992-ben kiadott ISO OSI
(Nyílt Hálózatok Összekapcsolása) jelű szabvány, más jelölés szerint az X.800-as, ami az adatbiztonsággal foglakozik.
Ez a szabvány a nyílt hálózatok felépítésénél szükséges biztonsági feltételeket és az ezt megvalósító módszereket írja le.

Míg az TCSEC, az ITSEC és a CC főleg az informatikai rendszer operációs rendszerére írja le biztonsági funkcióit,
addig az X.800-as a hálózatba kapcsolhatóság biztonsági jellemzőit határozza meg.

Magyarországon a Miniszterelnöki Hivatal Információs Koordinációs Irodája tette közzé az ITB ajánlásait (Információs
Tárcaközi Bizottság). Az ITB ajánlások módszertani segítséget nyújtanak – elsősorban az állam és közigazgatás
területén – működő informatikai rendszerek kidolgozóinak és üzemeltetőinek. Ezek a módszertani anyagok azomban
csak akkor alkalmazhatók, ha minden esetben adaptálták az előzőekben említett nemzetközi ajánlásokat a magyar
viszonyokra, és jól használhatók az üzleti területen működő szervezeteknél is.

Az informatikai rendszer elleni támadások kivédésének eszközei.

A hozzáférés ellenőrzés egyik legfontosabb része a felhasználó azonosítása. Ezt általában a felhasználónévhez kapcsolt
jelszóval oldják meg. Az egyszerű azonosító-jelszó párossal az a fő probléma, hogy könnyen ellopható. A különböző
rendszerek titkosított formában tárolják a jelszavakat, amelyek ilyen formában használhatatlanok. A titkosított jelszó
nem visszafejthető, még az algoritmus ismeretében sem.
• Biztonsági token: a számítógép hálózatban lévő hitelesítő kiszolgáló ezekkel a tokenekkel szinkronban
működik. Amikor a felhasználó be akar lépni a hálózatba, előveszi a tokent, ahol beírja a PIN kódot.
• Intelligens kártya: ezeken a kártyákon biztonsági adatokat tárolhatunk, jelszavakat, nyilvános és titkos
kulcsokat, hitelesítő információkat. A felhasználónak ezeket az adatait nem kell a PC merevlemezén tárolni,
elegendő megjegyeznie csak a kártya kódját. Ez egy bankkártya méretű eszköz mikroprocesszorokkal és
memóriával.

A tűzfal (firewall): a számítógépes hálózatokban a tűzfal egy olyan kiszolgáló számítógép vagy program, amelyet a
lokális és a külső hálózat közé, a csatlakozási pontra telepítenek, hogy az illetéktelen behatolásoknak elejét vegyék és
egyúttal lehetővé tegyék a kifelé irányuló forgalom ellenőrzését is.
Megkülönböztethetünk külső tűzfalat, ami a teljes helyi hálózatot izolálja az Internetről, és belső tűzfalakat ami a helyi
hálózat különösen védendő részét zárja el annak többi részétől, így az internettől is.
• Csomagszűrők (Packet Filtres): a tűzfalak első, legegyszerűbb generációja. A beállított szűrési szabályok
alapján egyes csomagokat továbbítanak, másokat eldobnak. Meghatározható, hogy milyen címtartományból
fogadunk el csomagokat, azaz alhálózatonként vagy akár gépenként szabályozhatjuk a szolgáltatások
használatát. Ugyancsak megoldható, hogy a belső felhasználók számára korlátozzuk a külső hálózati
szolgáltatásokhoz való hozzáférést. (a csomagszűrők fizikai és protokoll szinten (IP, UDP, TCP) működbek.
Alkalmazói programok szintjén )FTP parancsok, falj műveletek) már nem képesek védelmet nyújtani).
• Proxytűzfalak: nem szűrőként, hanem közvetítőként viselkednek a védett hálózat és a külvilág között.
Kívülről a tűzfal mögötti számítógépek teljesen láthatatlanok. Ez a megoldás teljesen elfedi a belső hálózati
struktúrát, a gépek címeit és neveit. Egyetlen regisztrált IP címmel az egész hálózat működtethető. A
regisztrált címet a tűzfal használja, a mögötte lévő gépek regisztrálatlan címet kapnak. Két kommunikálni
kívánó gép között a proxy-n keresztű épül fel a kapcsolat, nem pedig közvetlenül.

Kerberos: a Kerberos egy nyitott forráskódú hitelesítő rendszer, amellyel biztonságosan hitelesíteni lehet a
felhasználókat. A rendszer saját szerverén kívül a hálózatban működő egységek egyikétől sem követel biztonságot. Egy
speciális azonosító rendszerrel meg tudja különböztetni a bejegyzett felhasználókat az illegális kliensektől. A Kerberos
biztonsági rendszere kizárólag a Kerberos szerver feltörésével támadható meg.

Vírusvédelem:

Hardveres védelem: vírusvédelmi kártyák, segítségével korlátozni lehet a hozzáférést az adott számítógéphez,
másrészt állandó vírusfigyelést végez, így már a fertőzés gyanúja esetén figyelmeztet.
Szoftveres védelem: sokféle ellenőrzési technika létezik, a védekezés mindig lépéshátrányban van a támadással
szemben. Vírusvédelmi technikák:
• szekvencia kereső rendszerek: a vírusokra jellemző részlet/szekvencia alapján talál rá a vírusra.
• változásdetektorok: nem vírusspecifikusak, csak a változás tényét jelzik a felhasználó döntését veszik igénybe
aztán.
• ellenőrző összeges védelem: számolás alapján dönti el egy program fertőzöttségét.
• heurisztikus keresőrendszerek: vírusfunkciókra jellemző utasítássorozatokat, műveleteket keresnek, és ezek
alapján döntenek az állomány állapotáról.
• memóriarezidens víruskereső programok: figyelik az elindított programok működését, tipikusan a vírusra
utaló jelenségeket, például az illegális memória és lemezkezeléseket.
• viselkedésblokkolók: az ismeretlen vírusokra specializálódott eljárás. A vírusokra jellemző utasításokat
figyeli.
• immunizálás: elhitetjük a vírussal, hogy már megfertőzte a rendszert, azaz az adott állományokba
beleágyazzuk azt az azonosító kódsorozatot, melyet a vírus használ.
• egyedi killerek: általában egy bizonyos eltávolítására valók.
Kriptográfiai módszerek és eszközök, azok gyakorlati alkalmazása:

• Szimmetrikus rejtjelezés: jellemzője, hogy a titkosításra és a dekódolásra ugyanazt a kulcsot használjuk,

amelyet mind a küldő félnek, mind a fogadó félnek ismernie kell. Ehhez viszont a kommunikáció megkezdése
előtt meg kell állapodniuk egy közös kulcsban, és azt titokban kell tartaniuk. Az üzeneteket csak a titkos kulcs
segítségével lehet dekódolni, így egy esetleges támadó a kommunikációt lehallgatva se tudja megérteni az
üzeneteteket, illetve rejtjelezni sem tud egy hamis üzenetet. A szimmetrikus kulcsú titkosítás legnagyobb
előnye a gyorsaság, a kódolás sebessége. Hátránya, hogy a kódoláshoz használt kulcsot el kell jutattni minden
érintetthez. Ha bárkinek sikerül elfogadnia az üzenetet és a kulcsot is megszerezte, akkor képes a dekódolásra.
• Aszimmetrikus rejtjelezés: a rendszer lényege, hogy a kommunikáló feleknek nem kell előre megegyezniük
egy közös titkos kulcsban, hanem mindenkinek két kulcsa van: egy titkos és egy nyilvános. A titkosat csak a
tulajdonos ismeri, a nyilvánost bárkinek átadhatja. Ezután a feladó a címezett nyilvános kulcsával egy olyan
rejtjelezett szöveget tud generálni, amit csak és kizárólag a címzett titkos kulcsa tud megfejteni. Előnye, hogy
szükségtelenné teszi a kulcs elküldését, és így a rendszer sokkal biztonságosabb, hátránya a műveletek
lassúsága.
 20.)Az információs rendszer fogalma és összetevői. Adat, információ, tevékenység, esemény, felhasználó, szabály.
Az információs rendszer szintjei és nézetei. Rendszerszervezési életciklus. Tervezés, szervezés, modell.
Szervezetek strukturálási módja. Átvilágítás, diagnosztika.

Az információs rendszer fogalma és összetevői: Információk, a rájuk vonatkozó információs események, az

információkon végrehajtott tevékenységek, az előzőekkel kapcsolatos felhasználók és rőforrások, valamint a
mindezeket szabályozó eljárások együttese.

Az egymással kapcsolatban álló információs folyamatokat együtt információs rendszernek nevezzük.

Az információs rendszerrel szemben támasztott követelmények:

• gyors és pontos kommunikáció
• nagy mennyiségű adattárolás
• gyors adatfeldolgozás

Ezen követelményeket a számítógép tökéletesen kielégíti

Az ADAT: A valóság nem értelmezett (de értelmezhető) tükörképe. Az adat nyers (feldolgozatlan) tény, ami valakit
vagy valamit jellemez.

Adatnak nevezünk minden olyan ismeretet, mely előzőleg már rögzítésre került.

Az ismeret közlésének szabályai, a szintaktikai szabályok (forma), és a szemantikai szabályok (tartalom) összeségére
bonthatók.

Információ: az ember által értelmezett adat. Az ember észleli, felfogja, megérti és értelmezi az adatot, olyan formára
hozza, amelyben emberi lény számára az jelentéssel bír.

Információs tevékenység: 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énynek: 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ó: az ismeretekkel kapcsolatban álló emberek csoportja.

• Ismeretátadás
• végső felhasználó
• alkalmazási felhasználó
• adatszolgáltató – adatfelhasználó
• vezetői felelősség

Szabvány: meghatározott elvek eljárások, egyezmények halmaza, amiket a szakterület alkalmazói a kommunikáció és
tevékenységeik közti gördülékeny kapcsolat érdekében betartanak.
• Konvenció (megegyezés),
• szabványok és szabványos eljárások,
• nyílt rendszerek – rendezetlen kereskedelem,
• eligazítás, korlát, tájékoztatás.

A szabvány a rendszer valamilyen tényezőire vonatkozó megegyezés.

Az információs rendszer szintjei:

I. Fogalmi szint: a valóságnak a kompromisszumoktól mentes képe. Az elérendő célt a fogalmi szint
tartalmazza.
II. Logikai szint: adott környezet korlátjainak megfelelően átalakított, kompromisszumokat tartalmazó fogalmi
kép. Az elérendő célt adott megoldási módnak (logikai szint) megfelelően képezzük le.
III. Fizikai szint: adott környezet konkrét fizikai adottságaira alkalmazott, tehát ilyen módon felhasznált és
átalakított logikai kép.
Nézetei, vetületei:

• Adatvetület: az alapvető ismeretek lényege és elrendezése viszonylag stabil. Másik jellemző vonása, hogy
viszonylagos objektivitással rendelkezik. Az információs rendszer többi tényezőjétől viszonylag független.
• Feldolgozásvetület: ez a vetület magában foglalja az eseményt és a tevékenységet. Viszonylag instabil, és
meglehetős szubjektivitást mutat. A rendszer többi részétől nem független. Az adathoz képest töbszörös lehet.
• Környezeti vetület: az információs rendszert determinálja. A felhasználók szubjektív kívánságai, az eszközök
objektív képességei. Szabványok feltételrendszerei.

Rendszerszervezési életciklus: nyolc fázisra bonthatjuk, három fő csoportba tagolva.

I. Követelmények meghatározása, elemzés.
6. A feladatok és a célok meghatározása
7. megvalósíthatósági tanulmány készítése.
8. Rendszerelemzés
II. Rendszertervezés.
6. Koncepcionális tervezés.
7. Részletes tervezés.
III. Megvalósítás.
6. Kivitelezés
7. Átállás.
8. Kiértékelés és üzemeltetés.

Tervezés, szervezés, modell. Szervezetek strukturálási módjai.

Tervezés: különböző tevékenységek szervezése bizonyos eredmények elérése céljából. A cél egy szervezetet, üzletet,
vállalkozást a jövőnek építeni, a változásokat követve és menedzselve. A tervezés szintjei:
• Stratégiai: koncepcionális, vállalati szint, bármire alkalmazható, hosszú távú.
• Taktikai: fejlesztési, főosztály szint, termékekre vonatkoztatható, középtávú.
• Operatív: végrehajtási, osztály szint, egyes feladatok végrehajtása, rövid távú.
Alapvető strukturális jellemzők:
• munkamegosztás,
• hatáskör megosztás,
• koordinációs eszközök,
• konfiguráció.

Modell: A szervezetfejlesztés folyamatmodellje:

• problématudatosítás-a változtatás szükségessége,
• tanácsadó belépése,
• diagnózis, akcióterv,
• megvalósítás,
• szervezeti fejlesztési program befejezése.

Átvilágítás, diagnosztizálás:Az átvilágítás célja a kiindulási helyzet megismerése, és a felmerült igények feltárása.
Ennek alapján elemezhető az adott lényegi megvalósulás működése, felépítése, abban eszközölhető javitások
kidolgozása. A diagnosztizálás a szervezet, jelenlegi állapotában határozza meg a megváltoztatandó részeket, és
működéseket, a maximalizálható profit érdekében.

Diagnosztikai tényezők: A cél szem előtt tartásával (profitmaximalizálás) feltárják a vállalat/szervezet lehetőségeit, a
még-nagyobb profit elérésének érdekében. Ennek során elemzésre kerül a szervezet környezete, lehetséges képességei,
az olyan még kihasználatlan lehetőségek számba vétele, amik ezt megelőzőleg a hagyományos vagy egyéb
értékmércéknél fogva nem kerültek kiaknázásra. Hasznos és célszerű a szervezet mint kvázi felbontható rendszer
felbontása, és a kevésbé profit-hatékony ágazatok önállósítása.

A szervezetek strukturális módjai.

Munkamegosztás: a munkamegosztás egy nagyobb feladat részfeladatokra bontása és egyes szervezeti egységekhez
történő telepítése. A szervezet tagolásának alapja a funkció, tárgy (termék illetve termékcsoport), régió.
Hatáskörmegosztás: célja a szervezeti egységek, személyek kompetenciájának megállapítása, döntési jogkörök
felosztása, az utasítás hatáskörök megállapítása. A munkamegosztás és hatáskörmegosztás összhangja esetén megfelelő
felelősségi, elszámolási és érdekeltségi rendszert lehet létrehozni.

Koordináció és annak szabályozása: az eltérő feladatokkal és hatáskörökkel rendelkező, de egymással szoros

kapcsolatban álló szervezeti egységek működésének, tevékenységének a szervezeti cél érdekében történő
összehangolása.

Eszközei:
• technokratikus típusú a vállalati tervezési, pénzügyi és költségvetési rendszer, a belső elszámolás rendszere, a
szabályozottság,
• strukturális típusú a projektek, a teamek, az ad hoc bizottságok és a termékmenedzseri rendszer.
• Személyorientált koordinációt jelentenek az egyéneket közvetlenül ösztönző, kényszerítő eszközök, a
pszichológiai befolyások, amelyek segítik az egyének azonosulását a szervezettel.

A kommunikációs utak iránya szerint a koordináció típusa lehet: vertikális, és horizontális.

 21.) Egy választott, mai rendszerfejlesztési (szoftverfejlesztés) módszertan felépítése és szerepe a
szoftvertechnológiában. Adat- és folyamatmodellezés.

Az 1960-as évek végén – a szoftverfejlesztés hajnalán – a programozók számára az egyénileg kidolgozott technikák
követése volt az általános, nagyrészt azért, mert a programozás egyszemélyes feladat volt. Csapatmunka kilakítása
szinte reménytelen volt, mert az elkészült programkód logikáját gyakran csak az alkotója értette. Az 1970-es évek
elején bizonyos programozási gyakorlatok (pl. GOTO alkalmazása – Edsger Wybe Dijkstra, 1968) nehezen
kezelhetőnek nyilvánításával indult el egy folyamat a szoftverfejlesztés technikájának elvi alapokon történő
megfogalmazása felé. Bizonyos módszerek nagyon sikeresnek bizonyultak, amely újabb szabályozások kialakítása felé.
Bizonyos módszerek nagyon sikeresnek bizonyultak, amely újabb szabályozások kialakítására ösztönözte a szakterület
képviselőit. Évtizedek során egyre több szabályrendszer követése vált elfogadottá, amelyekből lassan egy-egy szervezet
által menedzselt komplex módszertanok alakultak ki.

A szoftverfejlesztési módszertan tehát különböző szabályok, eljárások, módszerek halmazának tekinthető, amely egy
szoftvertermék elkészítését segíti elő. A különböző standartok pedig más és más tevékenységi területen igyekeznek
minél szélesebb körben elfogadott és alkalmazott ajánlásokat adni.

A célokról és s követelményekről rendelkezésre álló információk rendszerezése és analizálása egy bizonyos határ felett
megköveteli azok egységesen strukturált dokumentálását. Az alkalmazott szoftver-életciklus modelltől függetlenül több
követelményelemzési és tervezési módszertan iránymutatását is követhetjük, mint pl. az SSADM, illetve az
objektumorientált rendszereket elíró UML.

A szoftverkrízis megoldásaként az objektumorientált programozás kínálkozott. Ez azonban újfajta szemléletet jelentett,

így újabb és újabb tervezési szemléletekre volt szükség. Felismerték, hogy nagy és bonyolult rendszereket csak
hatékony módszerekkel lehet tervezni és fejleszetni. Az UML-ig (és a RUP-ig) vezető út csaknem 10 évig tartott,
folyamatát az alábbi Booch-tól származó ábra szemlélteti.

Az egyesített módszertan tehát a RUP nevet kapta, Rational Urifie d Proce ss 5.0
fejlesztése 1998-ban érte véget. A módszertan az 1998
Uml-t használja modellező nyelvként, és az általa
definiált folyamat alapvetően iteratív jellegű: a
tervezés/fejlesztés folyamat ismétlődő iterációkból
Rational Obje ct Proce ss 4.1
Az UML története: a '90-es évek elején már 1996-1997
felmerült az igény a vizuális modellező nyelv
Rational Software Egyé b
kialakítására, az érdemi munka azonban csak 1994- Co. módsz e rtana módsz e rtanok
ben kezdődött, amikor Rumbaugh csatlakozott a 1997-1998
Rational csapatáho, és Boochhal együtt kidolgozták Obje ctory Proce ss
az 1995-ben publikált Unified Method elnevezésű 1987-1995
módszertant, ami sok olyan elemet tartalmazott
amiket a korábbi nyelvekből átvettek, majd fejlődése UML 1994-1997
Urifie d Language
során még számos kiegészítéssel gazdagodott. Egy

Az UML elemei
Az UML-ről és a használatáról korábban már írtam Ee icsson fe jle sz té se k
egy cikksorozatot. Úgy gondolom azonban, hogy a
téma kimeríthetetlen, és ezúttal igyekszem mélyebben belemenni egyes részletekbe, illetve megpróbálom áthelyezni a
hangsúlyt az objektumorientált szemléletmódra, annak szükségességére. Most nem egy konkrét problémát mutatok be
(mint annak idején a biliárdjátékot), hanem kisebb, de lényegre törőbb példákon keresztül igyekszem szemléltetni az
egyes elemek jelentőségét.

Egy UML modell alapvetően kétféle elemből állhat: egyrészt szöveges, másrészt vizuális részekből. Az előzőekre jó
példa a különböző használati esetek felsorolása, leírása, az utóbbira jónéhány példadiagramot felsorakoztattam a
korábbiakban.
Az objektumorientált világban elengedhetetlen az osztályokban történő gondolkodás, így először is járjuk körbe ezt a
kérdéskört. Mint azt már korábban többször kifejtettem, az osztályok az emberi gondolkodást igyekeznek tükrözni, így
első ránézésre értelmetlennek tűnhet nagy hangsúlyt fektetni rájuk. „Ha olyan közel áll a gondolkodásomhoz, minek
annyit gondolkodni rajta?” – merülhet fel a kérdés. Itt most valóban nem pszichológiai fejtegetésekről lesz szó. Azt
igyekezzük felderíteni, hogy az intuitíven meghatározott osztályok hogyan közelíthetők az optimális megoldáshoz, azaz
ahhoz, ahogyan a leghatékonyabban leképezhetjük azt egy szoftverben.
A hatékonyság itt nemcsak azt jelenti, hogy a szoftver működése a lehető leggyorsabb legyen. Magával a kóddal
szemben is támasztunk különböző követelményeket: könnyen olvasható, érthető, áttekinthető legyen, hiszen bármikor
szükség lehet arra, hogy átadjuk azt egy másik kollégának, és egy idő után a saját kódunkban sem tudunk eligazodni, ha
nem követjük ezeket az irányelveket.
Másik elvárás az, hogy a program könnyen módosítható, bővíthető legyen, azaz fel legyen készítve újabb modulok
hozzáadására, illetve ha a meglévő modulokat módosítani kell, ne kelljen újraírni az egész rendszert, hanem a lehető
legkisebb erőfeszítéssel ezt megtehessük.
Ehhez azonban jól átgondolt struktúrára, jól kialakított osztályokra van szükség.
Lássuk tehát, hogyan írhatunk le egy osztálystruktúrát. Természetes módon adódik, hogy alapvető elemei az osztályok,
amelyek között különféle kapcsolatokat definiálhatunk. Erre különféle eszközök állnak rendelkezésünkre. A két
legismertebb a Microsoft Visio (amelyet én magam is használni fogok az elkövetkezőkben), és a Rational Rose (talán
nem meglepő, hogy a Rational rendelkezik ilyen eszközzel…).
Ha a Visiot elindítjuk, egy menüben választhatjuk ki, milyen célra szeretnénk aktuálisan használni. Válasszuk a
Software csoportból az „UML Model Diagram” opciót. Ekkor a megnyíló ablakunk három részből áll: középen látható
maga az UML modell, ami első indításkor természetesen üres, később töltjük fel tartalommal. Bal oldalon találjuk az
egyes UML elemek felsorolását, amelyeket hozzáadhatunk modellünkhöz:
• Use Case
• Static Structure
• Statechart
• Sequence
• Deployment
• Component
• Collaboration
• Activity

Lássuk, mit is jelentenek ezek az elemek:

• Use Case: Használati esetek diagramjai definiálhatók. Az esetek többségében szükség van ezek szöveges leírására
is. Később látunk rá példát.
• Static Structure: A rendszer statikus osztálystruktúráját írhatjuk le segítségével.
• Statechart: Az állapotátmenet-diagram rajzolásához ad eszközöket.
• Sequence: Különböző szekvenciadiagramok rajzolására.
• Deployment: A rendszer telepítésével, fizikai felépítésével kapcsolatos információk meghatározására.
• Component: A rendszer komponenseit rögzíthetjük.
• Collaboration: Együttműködési diagramok rajzolására.
• Activity: Akciódiagramokat definiálhatunk (később ezekre is látunk példát).

Láthatjuk, hogy egy UML modell igen összetett is lehet. Persze a megismerés útján elindulva nem zúdul a nyakunkba
rögtön az összes UML diagram, ezek fokozatos elsajátítása sokkal hasznosabb lehet – persze ha közben tisztában
vagyunk azzal, hogy teljesértékű modellt csakis ezek együttes használatával kaphatunk.
A fokozatosság elvét követve tehát térjünk rá az osztálydiagramokra, azaz a rendszer statikus struktúrájára. A
diagramok megrajzolásához első lépésben azonosítani kell az adott problémát leíró osztályokat és ezek kapcsolatait.
Első megközelítésben intuitív módon igyekszünk felvázolni a megoldást, vagyis azonosítjuk a rendszer egyes különálló
moduljait, ezek felelősségét, és a közöttük fennálló kapcsolatokat. Például egy vállalati szoftver esetében szükség lehet
számlázó, raktárkészlet-nyilvántartó, megrendelés-kezelő, adóbevallás-készítő, és egyéb modulokra. Ezek
mindegyikének jól meghatározott feladata van, ezt részletesen kifejthetjük már a tervezés kezdeti szakaszában is.
Például:

Számlázómodul:
Feladata a különböző számlák kiállítása és nyomtatása. A számlán szerepelnie
kell az aktuális jogszabályoknak eleget tevő adatoknak (lásd ÁFA-törvény X-
edik paragrafus), valamint az eladáshoz kapcsolódó termékek illetve
szolgáltatások mennyiségének, ÁFA-tartalmának, egységárának és együttes
értékének.
A felhasználó egy űrlap kitöltésével állíthat ki újabb számlát. A számlán
szereplő tételek mind egyedi azonosítóval ellátott termékek és
szolgáltatások, melyeket egy külön erre a célra összeállított felületen
vihetünk be a rendszerbe.
A számla nyomtatása a bevitt adatok alapján automatikusan történik a
jóváhagyással egyidőben. A nyomtatásnál fontos kritérium, hogy többoldalas
számla esetében mindegyik lapon szerepelnie kell a fejlécnek, ami tartalmazza
az eladó és a vevő adatait, valamit az aktuális dátumot és a számla
sorszámát.
Előírhatunk olyan követelményeket is, amelyek az egyes modulok közötti kapcsolatokat határozzák meg:

A számlákon csak és kizárólag olyan termék szerepelhet, amiből kellő

mennyiség áll rendelkezésre a raktáron. A számla kiállításával a raktáron
lévő mennyiség a számlán szereplő mértékben csökken.

Így egy olyan rendszerváz áll rendelkezésünkre, amely alapján már elkezdődhet a konkrét megvalósítás tervezése.
Hangsúlyozom, hogy ez a fázis még a megrendelő bevonásával történik, hiszen az ő intenzív közreműködése szükséges
a rendszer alapkövetelményeinek meghatározásához.
Az osztályhierarchia meghatározásához alapul ezeket a fent meghatározott komponenseket használjuk, majd ezt a
modellt finomítjuk. A számlázásnál maradva abból indulunk ki, hogy szükségünk lesz erre a modulra. Az előbb vázolt
követelményekből már látszik is, hogy a számlázás több alfeladatból áll: számla kitöltése, tárolása, nyomtatása, stb.
Vajon milyen osztályok valósítják meg ezeket a feladatokat, van-e szükség külön osztályokra minden egyes
feladatkörhöz?
Első megközelítésben persze kiindulhatunk abból, hogy egyetlen osztály felel majd a számlázásért, s ennek lesznek
különböző metódusai, amelyek a nyomtatást, tárolást, stb. végzik.
Jogosan merül fel az igény, hogy ha már osztályokról beszélünk, lássunk is egyet, ábrázoljuk, lássuk el különböző
jellemzőkkel stb. Ám legyen.
Az osztály szimbóluma UML-ben egy téglalap, amelyet három részre osztunk az alábbiak szerint:

Osztály ábrázolása UML-ben

Az ábra egyes részei:

- Az osztály neve
- Az osztály attribútumainak listája
- Az osztály metódusainak listája

Érdekességként említem meg, hogy az UML elődeiként élő egyes módszertanok más és más szimbólumokat használtak
az osztályok jelölésére. Persze az osztályfogalom is eltért többé-kevésbé az UML-ben használatostól. Néhány példa:

Egy osztály ábrázolása az OMT és a Booch-féle szimbólumrendszerben

Az osztályt a neve egyértelműen azonosítja. Különböző megvalósításokban különbözőek az elnevezési tradíciók,

ráadásul ezek cégenként, projektenként is eltérhetnek. Lehet, hogy az osztályneveket névterekbe soroljuk, ekkor az
osztály a névtér:osztálynév páros határozza meg. Lehet, hogy a tradicionális nevezéktan azt írja elő, hogy valamilyen
előtagot tegyünk az osztályunk neve elé (például classMyFirstClass). Szokás az osztály nevében szereplő szavakat
nagybetűvel kezdeni a könnyebb olvashatóság kedvéért. Általánosan is elmondható, hogy egy cégen illetve projekten
belül célszerű egyfajta nevezéktant kialakítani, amelynek betartása mindenkire egyaránt kötelező. Így kommunikálni és
együtt dolgozni is sokkal egyszerűbb, hatékonyabb, hiszen elkerülhetjük például azokat a szituációkat, amikor egy
osztályt BélaOsztálya névvel illetnek az éles rendszerben (ne tessék nevetni, találkoztam már ilyennel).
Persze ezek az észrevételek nemcsak az osztályokra érvényesek…

Az osztályok következő fontos tényezői az attribútumok. Ezek az adattagok az osztály működéséhez szükséges
változók, szerepük különböző lehet. Elképzelhető, hogy az osztály belső működéséhez, „életéhez” szükséges egy új
változó bevezetése, ekkor felesleges azt kifelé is publikálni. Lehet, hogy az adott változó a külvilág számára is hordoz
információkat, ekkor láthatóvá kell tenni. Olyan eset is elképzelhető, amikor az elrejtés nem járható út, mert az
osztályból leszármazó egyéb osztályoknak szüksége van az adott változóra (a származtatásra és az öröklődésre később
részletesen kitérek), viszont teljesen publikussá sem szeretnénk tenni. Természetesen ez is megoldható, pontos menetét
később bemutatom.
Előtte azonban lássuk az osztályok metódusait. Ezek azok a cselekvések, amire az osztály egy példánya képes. Ide
tartozik az adott példány születése, megszűnése, és egyéb specifikus dolgok. A metódusokra is értelmezettek a fenti
láthatósági feltételek, azaz itt is meghatározhatjuk, ki számára szeretnénk elérhetővé tenni ezeket.
Általános alapelv, hogy mindent a lehető legszűkebb körben tegyünk láthatóvá, vagyis aki elől csak tudjuk, rejtsük el.
Ennek ára lehet, hogy például az attribútumokat privát használatúvá tesszük, de definiálunk hozzájuk elérő
metódusokat: egyet a kiolvasására, egyet a beállítására (amennyiben a logika szerint ez kívülről közvetlenül lehetséges).
Miért jó mindez? Képzeljük el azt a szélsőséges esetet, amikor minden attribútum (szokásos még a paraméter elnevezés
is) és minden metódus elérhető mindenki számára. A többi osztályban létrehozzuk az adott osztály egy példányát, majd
ha úgy gondoljuk, hogy valamely tagváltozójának értéke nem felel meg számunkra, rögtön nekiesünk, és már át is
állítjuk azt, függetlenül attól, hogy logikailag esetleg ez nem megengedett, mert csak az osztály belsejében, egyéb
paraméterek alapján történhetne értékadás.
Másik bökkenő, ha módosul az osztályunk felépítése: átnevezzük az adott tagváltozót, vagy egy újabb algoritmus
használatával igyekszünk hatékonyabbá tenni egy-egy metódust. Ha minden mindenki számára elérhető, és a fent
bemutatott módon, közvetlenül használunk mindent, millió helyen kényszerülhetünk átírni az alkalmazásunkat, mert
nincs egy olyan egységes interfésze az osztályunknak, amely elfedné ezeket a belső dolgokat.
Lássunk egy példát erre is. Legyen adott egy olyan osztály, amely – múlt havi példámnál maradva – torták
elkészítéséért felelős. A Torta osztály felépítése most némileg eltér a korábbitól:

Torta
+előkészítésiIdő : int
+pihentetésiIdő : int
+sütésiIdő : int
+krémKeverésiIdő : int
+összeállításiIdő : int
+szummaElkészítésiIdő : int
+szummaIdőSzámítás() : int
A Torta osztály

Jól látható, hogy az osztálynak több idő-paramétere is van. Feltételezzük, hogy a szummaElkészítési idő az egyes idők
összege, hiszen mondjuk egyetlen személy sürgölődik a konyhában, így nem párhuzamosíthatók a tevékenységek. Ezért
létrehozunk egy szummaIdőSzámítás() nevű metódust, amelynek belseje valahogy így néz ki:

public int előkészítésiIdő;

public int pihentetésiIdő;
public int sütésiIdő;
public int krémKeverésiIdő;
public int összeállításiIdő;
public int szummaElkészítésiIdő;

public int szummaIdőSzámítás()

{
szummaElkészítésiIdő = előkészítésiIdő +
pihentetésiIdő +
sütésiIdő +
krémKeverésiIdő +
összeállításiIdő;
return szummaElkészítésiIdő;
}
Ez mind szép és jó, működik is, van azonban egy apró bökkenő. Mi van akkor, ha a felhasználó az osztály
példányosításakor (vagyis amikor konkrét objektumot hoz létre belőle) nem veszi figyelembe ezt, és a
szummaElkészítési időnek is közvetlenül szeretne értéket adni? Valahogy így:

[1] Torta dobostorta = new Torta();

[2]
[3] dobostorta.előkészítésiIdő = 25;
[4] dobostorta.pihentetésiIdő = 20;
[5] dobostorta.sütésiIdő = 25;
[6] dobostorta.krémKeverésiIdő = 35;
[7] dobostorta.összeállításiIdő = 35;
[8]
[9] Console.Write(
 dobostorta.szummaIdőSzámít());
[10]
[11] dobostorta.szummaElkészítésiIdő= 10;

Az első sorban létrehozunk tehát egy példányt a Torta osztályból. Ezt a példányt (objektumot) dobostortának hívják.
Beállítjuk az egyes részfázisokhoz tartozó időtartamokat, majd kiíratjuk a szummaIdőSzámít() metódus eredményét. A
fenti adatokkal ez 25+20+25+35+35 = 140 perc.
A 11. sorban azonban valami miatt a kezünkbe vesszük az irányítást, és az elkészítési időt 10 percre állítjuk. A
következő használatkor (lekérdezéskor) valószínűleg jó alaposan meglepődünk majd, és fellelkesülünk, hiszen az itt
szereplő adatok szerint egy dobostorta elkészítésére elegendő 10 perc úgy, hogy mindössze egyetlen ember van a
konyhában – úgyhogy ezzel a felkiáltással sietve rávesszük lelkes Párunkat, hogy süssön nekünk tortát, mi meg közben
ellazulva nézhetjük kedvenc meccsünket a TV-ben.  Az eredmény valószínűleg nem dobostorta, hanem kétségbeesett
siránkozás lenne, hogy ez már megint nem működik, hiszen 10 perc alatt még az előkészületek sincsenek készen a
konyhában.
A problémát orvosolandó, tegyük rejtetté a szummaElkészítésiIdő attribútumot, hogy kívülről ne legyen közvetlenül
hozzáférhető. Ha ezután a dobostorta attribútumait nézzük, azt láthatjuk, hogy ez eltűnt a kívülről látható elemek
listájából. Mindössze a szummaIdőSzámítás() metódussal férhetünk hozzá az éppen aktuális értékhez.
Milyen előnye van még ennek a metódusnak? Miért lehet hasznos a használata ahelyett, hogy minden egyes meghívását
kiváltanánk az egyes időszeletek hosszának összeadásával? Valahogy így:

[1] Torta dobostorta = new Torta();

[2]
[3] dobostorta.előkészítésiIdő = 25;
[4] dobostorta.pihentetésiIdő = 20;
[5] dobostorta.sütésiIdő = 25;
[6] dobostorta.krémKeverésiIdő = 35;
[7] dobostorta.összeállításiIdő = 35;
[8]
[9] Console.Write(
 dobostorta.előkészítésiIdő +
 dobostorta.pihentetésiIdő +
 dobostorta.sütésiIdő +
 dobostorta.krémKeverésiIdő +
 dobostorta.összeállításiIdő);
A 9. sor itt ugyanazt az eredményt adja, mint a szummaIdőSzámítás függvény, miért kell akkor még ezzel is növelni az
osztály méretét?
Gondolkodjunk ismét közösen. Képzeljük el a következő szituációt: a programot felhasználó Gizike ránk szól, hogy
neki nagyon hiányzik még egy kikeverésiIdő attribútum is, mert ezt igazából nem tudja sem az előkészítéshez, sem a
pihentetéshez, sem a sütéshez sorolni. Felvesszük hát az osztályba ezt az új attribútumot, sőt még inicializálunk is egy
értéket neki (mondjuk 0-ra), hogy a már korábban leprogramozott és létrehozott objektumoknál se legyen gond az
értelmezése. Igen ám, de Gizike elkezdi beállítani ezeket az értékeket, mondjuk a dobostortára 30 percet. Néhány óra
vagy nap múlva ismét sikítva hív bennünket, hogy valami nem jó, mert ezek az értékek nem adódnak hozzá a teljes
elkészítési időhöz. Kénytelen-kelletlen nekiállunk orvosolni ezt is, és fél óra után leimádkozzuk a csillagokat is az
égről, hiszen minden egyes összegszámítást át kell írnunk, pontosabban kibővíteni az új időtartammal:

Console.Write(
 dobostorta.előkészítésiIdő +
 dobostorta.pihentetésiIdő +
 dobostorta.sütésiIdő +
 dobostorta.krémKeverésiIdő +
 dobostorta.összeállításiIdő +
 dobostorta.kikeverésiIdő);

A 9. sorhoz tehát újabb tagot adunk. És ugyanezt megtesszük a többi háromezer helyen is, ahol az adott összegre
vagyunk kíváncsiak. Mennyivel egyszerűbb lett volna megvalósítani a szummaIdőSzámítás függvényt, és azt meghívni
ezeken a helyeken! Hiszen akkor egyes egyedül a függvény belsejét kellene most átírnunk, csak ott kellene felvennünk
az újabb tagot az összegbe, és akkor mindenhol helyesen jelenne meg az érték!
Hasonló a helyzet akkor is, ha rájövünk, hogy egy tagváltozó neve nem felel meg a tartalomnak (például időközben
pontosítottuk a felhasználó igényeit), vagy a tagváltozóban egyéb módosításokat kívánunk bevezetni. Ha az attribútum
közvetlenül elérhető kívülről is, a belső módosítás után mindene egyes hivatkozást át kell írnunk. Ha azonban a fentihez
hasonlóan minden paraméterhez van külön elérőfüggvény, ez a veszély nem áll fenn, hiszen ekkor elég a függvényt
módosítani, kifelé transzparens lehet a változás.

Jelenleg tehát már értjük, mik azok az osztályok, milyen adatokat kell megadnunk definiálásukkor. Semmit nem tudunk
azonban még az osztályok kapcsolatáról, és egy csomó olyan gyakorlati dologról, ami szintén hasznos lehetne
munkánkhoz. Ezért a következő hónapokban tovább boncolgatom ezt a témát: részletezem az osztályhierarchiák
felépítésének módjait, a különböző osztályok együttműködését. Bemutatom az UML-hez tartozó többi diagramot is, és
azok kapcsolatait egymással, hogy világossá váljon, hogyan épül el egy rendszer teljes UML modellje.
Addig is mindenkinek jó szórakozást kívánok az UML-lel és a hozzá kapcsolódó CASE eszközökkel történő
ismerkedéshez! Egy dolgot nem szabad elfelejteni: tanulni csak úgy lehetséges, ha az ember próbálkozik!
Úgyhogy hajrá!