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

A VIK Wikiből
A lap korábbi változatát látod, amilyen Ferrero (vitalap | szerkesztései) 2013. február 6., 10:07-kor történt szerkesztése után volt. (→‎5. Linux vagy Windows példa a dinamikus programkönyvtárak betöltésére (12p))

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: [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.

A lap eredeti címe: „https://vik.wiki/index.php?title=Szoftver_technikák_vizsga,_2007._június_13.&oldid=157178”