Szoftver technikák vizsga, 2007. június 13.

1. .NET szerelvény (assembly) fogalma, szerepe, típusai, azonosítása (12p)

• általában egy .dll vagy egy .exe, de lehet több is
• IL kód
• metaadatok .NET osztályokból
• erőforrások (.jpg, .txt)

Minden alkalmazás szerelvényekből épül fel:

• egy névtér több szerelvényben is lehet
• egy szerelvényben több névtér is lehet
• hivatkozhat más szerelvényekre

Szerelvény fájlok:

• egy fájl
• memória fájl, pl. scriptelésnél
• több fájl: egy mappában a manifesttel, a biztonságosság miatt hash készül a hivatkozott állományokról

Szerelvény információk: a manifest

• név (általában kiterjesztés nélküli állománynév)
• verzió (major, minor, build number, revision)
• támogatott nyelv és kultúra
• processzor és OS
• szerelvény referenciák: név, verzió, nyilvános kulcs (ha megosztott), hash algoritmus azonosító (ha megosztott), szerelvényhez tartozó modulok listája, hash, egyéb (kiadó, leírás)

Verziókezelés:

• ha új verziót telepítünk, akkor is a régit használja
  
• a kibocsátó cég átirányíthat
  
• a rendszergazdák felüldefiniálhatják

1. Privát szerelvény:

• egyetlen alkalmazás használja
• a neve azonosítja
• az alkalmazás mappáiban keresi (konfigurációs állományban más elérési útvonal is megadható)
• egyszerűen telepíthető

2. Azonosított szerelvény (megosztott, erős névvel ellátott)

• több alkalmazás használja --> "dll hell"
• erős név teszi egyedivé: név, fejlesztő cég nyilvános kulcsa, verzió szám, opcionálisan nyelv és kultúra
• digitális aláírás a fejlesztő cég privát kulcsával --> integritásvédelem
• csak azonosított szerelvényekre hivatkozhat
• %WINDIR%\Assembly mappában
• a több alkalmazás által használt komponensek a %WINDIR%\System32 mappában

A típusok szerelvényekhez kötődnek, nem névterekhez. Ugyanabból a szerelvényből több futhat egymás mellett, akár egy folyamaton belül is. A fejlesztő minimális engedélyeket kérhet.

-- Olthyer - 2008.05.29.

2. C#: indexer, boxing, attribútum + példakód mindre! (12p)

Indexer:

• konzisztens mód a containerek építésére
• a tulajdonságok ötleten alapszik
• indexelt elérést biztosít a tartalmazott objektumokhoz
• az index minősítő bármilyen típusú lehet

Példa:

object this [string index]
{
	get { return Dict.Item( index ); }
	set { Dict.add( index, value ); }
}

Dobozolás:

• érték szerinti típusok bedobozolhatóak és utána kidobozolhatóak
• ezzel lehetővé válik az érték típusú objektumok referencia szerinti átadása
• alapja az, hogy minden alaptípus objektum is
• dobozba dobjuk tehát az értéket és "referenciáljuk"

Példa dobozolásra:

object BoxedValue = value;

Példa kibozolásra:

value = (double) BoxedValue;

Attribútum:

• deklaratív jelleggel metaadatokat közölhetünk a kód bizonyos részeire vonatkozóan
• minden nyelvi elemhez rendelhető (típushoz, osztályhoz, interfészhez, metódushoz, stb.)
• megváltoztathatja a fordító viselkedését, VAGY futási időben lekérdezhető
• saját attribútumok alkothatók (ilyenkor kötelezően le kell kérdezni)
• általában az attribútumokkal csak a CLR számára szeretnénk információkat közölni
• felhasználás: natív kóddal való együttműködés testreszabása, perzisztens osztályok létrehozása, metódusszintű jogosultság ellenőrzés, tranzakcióban részt vevő osztályok megjelölése, web szolgáltatások

Példa (sorosíthatóság):

[Serializable]
int a;

Péla (szerepkör ellenőrzés):

[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
public void DeleteUser() { ... }

-- Olthyer - 2008.05.29.

3. Windows ablakok, formok

a) Win32 natív üzenetkezelése + def: üzenet, üzenetsor, ablakkezelő függvény (7p)

Üzenetkezelés Win32 platformon:

• _Üzenet_: eseménykor generálja a Windows. Tartalma: típus, keletkezési idő, melyik ablaknak szól az üzenet. A billentyűzet és egér üzenetei mindig aszinkron módon dolgozódnak fel. Ezeket az eseményeket az üzenetté való konvertálása után a rendszer egy rendszer várakozási sorba (system queue) helyezi el. A system queue-ba érkező üzeneteket az operációs rendszer továbbítja az applikációk szálainak üzenet soraiba.
• _Üzenettípusok_:
  

a.) Queued: az üzenet bekerül az üzenetsorba és onnan továbbítódik az ablakkezelő függvénynek --> üzenet feladás, "post a message".
b.) Not-queued: az üzenetsor kikerülésével közvetlenül az ablakkezelő függvény kapja meg az üzenetet --> üzenet küldés, "send a message".

• _Üzenetsor_: minden szál rendelkezik egy FIFO üzenet sorral, amibe bekerülnek a szálhoz érkező üzenetek. Innen továbbítódnak a megfelelő ablakkezelő függvényhez. Ezeknek az üzeneteknek a feldolgozása aszinkron módon történik.
• _Üzenetkezelő ciklus_: minden applikáció (minden GUI szál) tartalmaz egy üzenetkezelő ciklust, ami kiszedi az üzeneteket az üzenetsorából, és továbbítja őket a megfelelő ablakkezelő függvénynek.
• _Alapértelmezett ablakkezelő függvény_: Olyan események esetén hívjuk meg, melyek érdektelenek az alkalmazás szempontjából, és így az alapértelmezett módon szeretnénk lekezelni, pl. : ablak átméretezés, minimalizálás, menük megjelenítése, stb. -- punkah - 2008.06.03.
• _Callback függvény_: kitüntetett szerepű függvény. Az operációs rendszer bejegyzi magának, esemény bekövetkeztekor pedig meghívja. Az eseménykor keletkezett üzenetből lehet tudni, hogy ki kapja az eseményt, és mik a paraméterek.

-- Olthyer - 2008.05.29.

b) Windows Forms saját vezérlők készítésének lehetőségei (6p)

1. Control osztályból leszármaztatás. Akkor használjuk, ha egy teljesen új vezérlőelemet szeretnénk létrehozni. Csak a minden Controlra közös tulajdonságokat és műveleteket kapjuk meg. Adhatunk hozzá új tulajdonságokat (property), eseményeket (event). Ez esetben a rajzolás is a mi feladatunk.
2. Adott Control osztályból történő származtatás. Akkor használjuk, ha egy már létező vezérlőelemet szeretnénk testre szabni. Csak az új/módosított speciális viselkedést kell megírnunk, a vezérlő alapértelmezett működése megmarad. Adhatunk hozzá új tulajdonságokat, eseményeket.
3. Származtatás UserControl osztályból. Vizuálisan elkészíthetjük összetett vezérlőelemeinket, pont úgy, ahogy egy Formot is elkészítenénk. A tartalmazott vezérlőelemek private láthatóságúak. Tipikusan az összetett felhasználói felület modularizálásának eszköze.

-- Olthyer - 2008.05.29.

4. Szálas feladat

a) def: folyamat és szál + fő különbség közöttük (5p)

• A folyamat egy alkalmazás futó példánya.
• A folyamaton belül párhuzamosan futó kódrészeket szálaknak hívjuk. Ezek tulajdonképpen a folyamaton belüli külön feladatokként foghatóak fel.
• Egy folyamat legalább egy szálból áll (főszál).
• Egy szál a szülő folyamat címtartományában fut és használhatja a folyamat által foglalt erőforrásokat.
• Az egy folyamathoz tartozó szálak közös memóriaterületet használnak, így az alkalmazáson belüli párhuzamosítás nagyon hatékonyan végezhető el.
• A különböző folyamatok szálai azonban el vannak szigetelve egymástól, ezért ha az egyik szál hibásan működik, akkor sem zavarhatja meg a másik szál működését.

b) AutoResetEvent ismertetése+példakód (7p)

• Esemény, egy fajta szinkronizációs eszköz.
• Írása és olvasása az ütemező által nem megszakítható.
• Processzortakarékos módon lehet rá várakozni.
• Az esemény kétféle állapotban lehet, jelzett és jelzetlen állapotban. (Tehát az esemény egy speciális logikai változóként képzelhető el.)

Példa (előtérszál leállítása eseményre történő várakozással):

class EventTestClass
{
	 private static AutoResetEvent stopEvent = new AutoResetEvent(false);
	 public static void Main(string[] args)
	 {
		  Thread t = new Thread(new ThreadStart(ThreadMethod));
		  t.Start();
	 }
	 public static void ThreadMethod()
	 {
		  while (!stopEvent.WaitOne(0, false))
		  {
				...
		  }
	 }
}

A várakozás implementációját a WaitHandle osztály tartalmazza, ezt használják az esemény osztályok is. Használatával lehetséges egy vagy több eseményre várakozni.

-- Olthyer - 2008.05.29.

5. Linux vagy Windows példa a dinamikus programkönyvtárak betöltésére (12p)

Lásd: Tételsor: Mutasson egy Linux VAGY Windows alatt futó példát...

6. Tervezési minták

a) Miben és hogyan segítenek a tervezési minták? (3p)

A tervezési minta gyakran elforduló problémát ír le; annak környezetét és a megoldás magját, amit alkalmazva számos gyakorlati eset hatékonyan megoldható. (Lazább értelemben véve akár az interfészek is tekinthetőek tervezési mintának.) A fejlesztés tervezés fázisában nagy segítség. Programozási nyelvtől független.

Négy alapelem:

• minta neve
• probléma és környezet bemutatása (gyakran konkrét példán keresztül)
• absztrakt leírás (a megoldásban szereplő elemek, kapcsolatuk, az egyes elemek felelőssége, együttműködése)
• következmények, tapasztalatok

-- Olthyer - 2008.05.29.

b) Proxy tervezési minta. Ismertetni általánosságban vagy egy konkrét példán keresztül + osztálydiagram + osztályok magyarázása (10p)

Struktúrális tervezési minták közé tartozik, célja:

• Az igazi objektum helyett, egy helyettesítő objektumot használ, ami szabályozza az objektumhoz való hozzáférést.
• Példa: Szövegszerkesztő, sok nagy méretű kép amit nem kell egyszerre megjeleníteni, csak amikor odagörgetjük az ablakot, vagyis amikor láthatóvá válik.
• Megoldás: Proxy-val.Helyettesítsük a képet egy objektummal (proxy), amely ha be van töltve a kép megjeleníti, egyébként betölti, és azután jeleníti meg.
• Struktúra:

• • Subject: közös interfészt biztosít a Subject és a Proxy számára(ezáltal tud a minta mködni, ez a lényeg!).
  • Realsubject: a valódi objektum, amit a proxy elrejt.
  • Proxy: helyettesítő objektum. Tartalmaz egy referenciát a tényleges objektumra, hogy el tudja azt érni. Szabályozza a hozzáférést a tényleges objektumhoz, feladata lehet a tényleges objektum létrehozása és törlése is.
• Fajtái:
  • Távoli Proxy: Távoli objektumok lokális megjelenítése átlátszó módon. A kliens nem is érzékeli, hogy a tényleges objektum egy másik címtartományban, vagy egy másik gépen van.
  • Virtuális Proxy: Nagy erőforrás igény objektumok igény szerinti létrehozása (pl.kép).
  • Védelmi Proxy: A hozzáférést szabályozza különböz jogok esetén.
  • Smart Pointer: Egy pointer egységbezárása, hogy bizonyos esetekben automatikus műveleteket hajtson végre (pl.:lockolás).

7. Vállalati inf. rendszerek két- és háromrétegű architektúrái (13p)

Háromrétegű architektúra

• Külső séma - alkalmazás.
• _Alkalmazáslogikai alréteg_: opcionális. Ez egy interfész (homlokzat) a tartománymodellhez. Az interfész illeszkedik a GUI vezérlőelemeihez. A tartomány típusairól logikai típussá konvertál.
• Koncepcionális séma - tartomány (üzleti logika).
• Belső séma - adatbázis.
• Felépítés:

Alkalmazás

Tartomány

Adatbázis

Előnyök:

• Az alkalmazás kevésbé függ a fizikai adatszerkezettől.
• A referenciális integritás alkalmazásfüggetlenül kezelhető.
• Az adatbázis átszervezhető az alkalmazástól függetlenül.
• Tranzakciókezelés a DBMS feladata – ne nekünk kelljen implementálni.
• Ipari támogatottság (Microsoft, Sun).

Hátrányok:

• Kevesen használják.
• Nagyobb erőforrásigény.
• Többletmunka.
• Az objektumorientált adatbázisok jó felhasználási területe, de ezek teljesítőképessége kétséges.

Kétrétegű architektúra

• Megosztott adatbázis (file-ok, DBMS)
• Alkalmazások (hagymányos vagy 4GL nyelven)
• Felépítés:

Alkalmazás

Megosztott adatbázis

Előnyök:

• Az adatkarbantartás elkülöníthető az alkalmazásoktól.
• A már meglévő adatokat több szempontból (nézetből) is megjeleníthetjük.

Hátrányok:

• Az adatok integritása jól csak az adatbázis szintjén megoldható – ha nincs lehetőség tárolt eljárásokra, akkor ez problematikussá válhat.
• Ha az adatintegritás kezelését „bedrótozzuk” az alkalmazásba, nem lehet megváltoztatni a régi alkalmazásokkal való kompatibilitás miatt.
• Optimalizálás denormalizálással.
• Az alkalmazás az adatbázis fizikai felépítését is figyelembe kell vegye, pedig neki csak a szemantikát kellene.

-- Olthyer - 2008.05.29.

8. Dinamikus webalkalmazások jellemzői (def, kliens oldal, szerver oldal, állapotkezelés) (13p)

Dinamikus webalkalmazás

• Szerver oldali logikát tartalmaz
• Az oldalakon található információk egy része gyakran adatbázisban tárolódik
• Kliens oldali logikát (JavaScript) tartalmazhat

Kliens oldal

• Tipikusan valamilyen böngésző fut -> HTML kódot, HTTP választ tud feldolgozni
  • Valamilyen szinten implementálja a HTTP szabványt
    • Kommunikálhat más protokollon is a szerverrel
    • Kompatibilitás és tűzfal barátság érdekében
  • Lehet RSS olvasó, letöltő, feltöltő, irodai alkalmazás, webszolgáltatás kliens
  • Lehet oldalba ágyazott kontroll (Flash, Silverlight)
• Letölti a kiegészítő fájlokat (kép, stíluslap, szkript stb.)
• Futtatja a kliens oldali kódot
  • Browser sandboxban
• A felhasználó akciói visszakerülnek a szerverre: postback vagy roundtrip
  • Pl. gomb megnyomására HTTP POST vagy URL paraméterek formájában

Szerver oldal

• Feldolgozza a beérkező HTTP kérést -> input
  • Felhasználó által megadott input (URL, query string, form data)
  • Korábbi műveletek (session, cookie)
  • Kliens paraméterei (pl. User-Agent, Accept-Language header)
• Valamilyen nyelvű kód fut, aminek HTTP választ kell előállítania -> output
• Szerver oldali vagy külső erőforrásokat (adatbázis, web) használhat
• Kliens oldali erőforrásokat nem érhet el (browser sandbox, biztonság!)

Állapotkezelést (session ID) valahol meg kell oldani (HTTP nem támogatja)

• Valamilyen egyedi azonosító alapján
• Kliens oldalon
  • URL paraméter
  • Rejtett mező
  • Cookie
• Szerver oldalon
  • In-process a webszerver memóriájában
  • Külön folyamatban
  • Adatbázisban
• ASP.NET: web.configban <session> tag

-- punkah - 2008.06.03.