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

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

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:

Ezen a helyen volt linkelve a win32uzenet.GIF nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• _Ü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:

Ezen a helyen volt linkelve a proxy.JPG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• • 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.