Informatika | Gazdasági Informatika » Műszaki informatika tételsor I.

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, 999 -12, 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: BINARY BIT 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 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 1 bájt tartalmazó mezők. TINYINT 1 bájt MONEY 8 bájt DATETIME (Lásd: DOUBLE) UNIQUEIDENTIFIER 8 bájt A 100. és 9999 év közé eső dátum- vagy időpontérték 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, 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 értékek esetén, 4,94065645841247E-324 és 1,79769313486232E308 között pozitív értékek esetén, valamint 0. Kisebb egész szám – 32 768 és 32 767 között. 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 pedig a tizedesjegy-pontosságot (0 - megadott pontosság). Az alapértelmezés szerinti pontosság és tizedesjegy-pontosság 18, illetve nulla. REAL 4 bájt FLOAT 8 bájt SMALLINT INTEGER 2 bájt 4 bájt DECIMAL 17 bájt TEXT IMAGE CHARACTER 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: – 922 337 203 685 477,5808 és 922 337 203 685 477,5807 2 bájt/karakter (lásd 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

Szükség szerinti használatos. 2 bájt/karakter (lásd 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 kliensszerver 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 h aszná lja E g yO b jektum S o k O b jek tu m 2 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 javaswing 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.awtevent csomagban deklarált eseményosztályokat, melyek a javaxswingevent 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 import import import javax.swing*; java.awt*; java.event*; extra.frameCloseableFrame; 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.awzevent 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.awtToolkit 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áziskezelő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 Kovács Pál Kis Péter Varga Ödön SZÜL-DÁTUM 01/12/89 06/07/72 02/05/60 SZÜL-HELY Szolnok Budapest Tiszapüspöki FIZETÉS 79.000 88.000 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 Phez 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 (Etáblának) hívjuk. A parancs általános szerkezete a következő: SELECT. [INTO.] FROM. [WHERE.] [GROUP BY.] [HAVING.] [UNION.] [ORDER BY/FOR UPDATE OF.] [SAVE TO TEMP.]; oszlop kiválasztása=projekció az E-tábla 1. sorának tárolása táblák Descartes-szorzata sorok kiválasztása=szelekció csoporthívás csoportok közötti választás E-táblák összefűzése=az unió művelete E-tábla rendezése/tábla módosítása 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 2. 3. 4. WHERE.jében lévő oszlop értkeit és amelyiket megtalálja, az ahhoz tartozó értéket beteszi az E-tábéába 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. 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. Az EXISTS-szel létrehozott feltétel akkor vesz fel igaz értéket, ha a belső SELECT által generált Etá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 adatok Objektum : Osztály á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 10 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 20 é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. 2. 3. 4. 5. 6. a szerveroldali scriptek fejlesztése teljesen független a felhasználó által alkalmazott böngészőtől. Így a szerveroldali scripteket olyan programnyelveben is fejleszthetjük amelyet a felhasználó böngészője nem támogat. 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. 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 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ó. 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. 2. 3. WWW kliens (Internet Explorer, Netscape Navigator, Flock) WWW szerver/adatbázis kliens 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. 2. 3. A JavaScript futásidejű könyvtár LiveWire

adatbázis-elérés könyvtár 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

bytekó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 gyakorisá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, fejlesztése 1998-ban érte véget. A módszertan az 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 Az UML története: a 90-es évek elején már felmerült az igény a vizuális modellező nyelv kialakítására, az érdemi munka azonban csak 1994ben

kezdődött, amikor Rumbaugh csatlakozott a Rational csapatáho, és Boochhal együtt kidolgozták az 1995-ben publikált Unified Method elnevezésű módszertant, ami sok olyan elemet tartalmazott amiket a korábbi nyelvekből átvettek, majd fejlődése során még számos kiegészítéssel gazdagodott. Egy Rational Urifie d Proce ss 5.0 1998 Rational Obje ct Proce ss 4.1 1996-1997 Rational Software Co. módsz e rtana Obje ctory Proce ss 1987-1995 Egyé b módsz e rtanok 1997-1998 UML 1994-1997 Urifie d Language 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 Xedik 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á!