Objektumorientált szoftvertervezés - Vizsga, 2010.05.26.

A VIK Wikiből

OO Vizsga 2010-05-26

Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat

(objektum különféle tagváltozóit módosítgatjuk, majd kiírjuk egy ObjectOutputStreamre, utána visszaolvassuk, ezután mennyi az egyes tagváltozók értéke).

A Netbeanses JPA-s autós példában milyen szerepet töltött be a Buffer? (Válaszát röviden indokolja)

  • interfész
  • servlet
  • entity bean
  • session bean

Két package adott volt, a függőségeik alapján Instability (RMI) számítása.

  • RMI = CE / ( CA + CE )
  • CA -> Az én packegemre mutató külső packagekből kiinduló kapcsolatok száma
  • CE -> Az én packagemből kiindulú kapcsolatok száma külső packagekbe
  • X/X+Y instability képlet ez kellett használni, ahol
  • X a két package közt egyik irányban a függőségek száma,
  • Y a két package közt másik irányban a függőségek száma.

Function Point elemzés fázisai.

Funkciópont elemzés (6. diasor/ 34 dia) komponensei:

  • External Inputs
  • External Outputs
  • External Inquiries
  • Internal Logical Files
  • External Interface Files

Milyen táblákba képződik le a megadott struktúra (1 ős és két gyermekosztállyal) table-per-subclass leképezés esetén?

Strategized locking minta milyen problémát hogy old meg, UML class diagram.

  • Probléma:
    • a lock-olás beégetése a programba akadály:
      • újrahasznosítás
      • teljesítmény hangolás
      • karbantartás
  • Megoldás:
    • run-time delegálható szinkronizációs aspektus
  • UML ábra -> diasor

Adott egy X osztály, ami aggregál egy Z osztályt, aki megvalósítja a Cloneable interfészt. Meg kell adni az X osztályra vonatkozó clone() függvényt, és garantálni kell, hogy az deep copy-t végezzen.

		 Object clone(){
			 A a3 = new A();
			 a3.b = b.clone();
			 return a3;
		 }
		 

Deadlock-hoz vezet-e az alábbi kódrészlet?

		 class A {
			 synchronized void bar() {
				 System.out.println("Deadlocked");
			 }
		 }
		 class B {
			 private A a;
			 public B() {
				 a = new A();
			 }
			 void foo() {
				 synchronized(a) {
					 a.bar();
				 }
			 }
		 }
		 
  • Nem, a pédányosítás során semmi szinkronizálandó dolog nem fut. De ha meghívjuk B foo() metódusát, akkor sem, mert ezek egymásba ágyazhatóak.
  • A válasz az volt, hogy nem, a synchronized kulcsszó arra jó, hogy a szálat a szinkronizált kódrészlet erejéig garantáltan az adott objektum monitorában tartsa. Ha ezt kétszer adjuk ki, az nem okoz problémát, de nincs gyakorlati jelentősége sem. Viszont kiíródott, hogy "Deadlock".
	synchronized
	 1. lehet blokk előtt
		- ekkor objektum referencia kell
	 2. metódus előtt
		- ekkor a monitor azé az objektumé, akin a metódust hívjuk
		- egyenértékű a teljes metódust felölelő blokkal
  

Mik a SAX alapvető jellemzői? (3p)

  • Eseményvezérelt, callback (ContentHandler)
  • Soros elérés (kis memóriaigény, nagy sebesség, nem lehet ugrálni a dokumnetumokban)
  • Állapotfüggetlen feldolgozás

Milyen tervezési mintákat valósítanak meg? (5p)

  • RMI stub - proxy
  • TreeView node-jai - composite
  • JPanel scrollbar - decorator
  • Layout-kezelés - strategy
  • AWT eseménykezelés - observer

A SwingWorkerre miért van szükség és kinek a felelőssége meghívni a process() és publish() metódusokat? (3p)

  • Java -> Swing fejezet -> szálkezelés téma
  • Mikor használjuk?
    • hosszú I/O művelet, számítás stb. esetén -> különben nem reagál az alkalmazás
  • Úgy viselkedik, mint egy szál
    • párhuzamosan fut az eseménykezelővel,
    • csak egyszer futtatható
  • Visszatérési értéke van
    • ez a futás végeztével elérhető
    • tetszőleges típus lehet (genericitás)
  • Képes kódot futtatni az eseménykezelő szálban
    • hasznos, ha modellt kell módosítani
  • process() és publish() metódusokat az eseménykezelő felelőssége meghívni
  • publish()-t meghívod a doInBackground() metódusban, tehát NEM az eseménykezelőben, hanem a külön szálban és a SwingWorker megoldja, hogy az eseménykezelő szálból történjen egy process() hívás, ami tartalmaz egy vagy több publish()-nak átadott elemet (ilyenkor ezeket pl. hozzá lehet adni a GUIn egy listához, stb), itt egy példa: http://download.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html

Verziókezeléses módszerek, előnyei, hátrányai. Ha jól emlékszem, ez a kérdés a weave, delta, stb.-re kérdezett rá. CsL(3p)

  • Írj a témáról amit jólesik, 3 pontért.

Reverse skip deltás példa. Mely revíziókat hogyan tároljuk el a 20., legutolsó revízióhoz képest? (3p)

A megoldás menete: minden új verziónál megnézzük, hogy hány záró 0 van a bináris alakjában, és hozzáadunk egyet, ennyi korábbi verzióhoz kell új deltát csinálni. Az újradeltázandó verziók a friss verzióból a 2 hatványok, de csak annyi, amit az előbb kiszámoltunk (x-1, x-2, x-4, x-8 ...)

A konkrét feladat megoldása(frisstől visszefelé a kapcsolatok):

  • 20*:(19,18,16) *18*:(17) *16*:(15,14,12,8,0) *14*:(13) *12*:(11,10,4) *10*:(9) *8*:(7,6) *6*:(5) *4*:(3,2) *2*:(1)

A kulcsokat miért Set-ben, az értékeket miért Collection-ben adják vissza a Map interfészt megvalósító Java osztályok? (1p)

  • Kulcsok - a kulcsokra érvényes az unicitás törvénye, azaz egyediséget biztosítanak, és egy értéktípusból egy szerepelhet. Ennek biztosításához egy halmaz-tulajdonságú adatszerkezet szükségeltetik, és a Set pontosan ilyen.
  • Szerintem az is játszik, hogy a Setben nem lehet megváltoztatni az elemeket - ha ezt megtennénk, jól felborulna a kollekció belső adatszerkezete. CsL
  • Értékek - egy-egy érték tetszőleges számban szerepelhet, így a Collection az (egyik) ideális adatszerkezet rá, ami ezt lehetővé teszi.

Avagy ezeket lehet változtatgatni. CsL

Choice(Identity, v) = ?

= Identity

-- keeroy - 2010.05.28.

-- CsL - 2010.05.28.

-- molnarm - 2010.05.29.

-- Eff - 2010.06.12.

-- Ciana - 2010.06.12.