Objektumorientált szoftvertervezés - Vizsga, 2010.05.26. - Laptörténet

Hryghr: Hryghr átnevezte a(z) OotVizsga20100526 lapot a következő névre: Objektumorientált szoftvertervezés - Vizsga, 2010.05.26.

2013-06-13T21:08:32Z

Hryghr átnevezte a(z) OotVizsga20100526 lapot a következő névre: Objektumorientált szoftvertervezés - Vizsga, 2010.05.26.

← Régebbi változat	A lap 2013. június 13., 23:08-kori változata
(Nincs különbség)

Ferrero, 2013. január 3., 17:46-n

2013-01-03T17:46:35Z

← Régebbi változat		A lap 2013. január 3., 19:46-kori változata
3. sor:		3. sor:
	__TOC__		__TOC__

	====~~01.~~ Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat====		====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).		(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).

	====~~02.~~ A Netbeanses JPA-s autós példában milyen szerepet töltött be a Buffer? (Válaszát röviden indokolja) ====		====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		* interfész
14. sor:		14. sor:
	* session bean		* session bean

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

	* RMI = CE / ( CA + CE )		* RMI = CE / ( CA + CE )
23. sor:		23. sor:
	* Y a két package közt másik 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.

	====~~04.~~ Function Point elemzés fázisai.====		====Function Point elemzés fázisai.====

	Funkciópont elemzés (6. diasor/ 34 dia) komponensei:		Funkciópont elemzés (6. diasor/ 34 dia) komponensei:
32. sor:		32. sor:
	* External Interface Files		* External Interface Files

	====~~05.~~ 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?====		====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?====

	* Minden külön táblába, a 1 ős osztályban lesz discriminator, valamint a gyermek osztályokban lesz egy ID attribútum, ami az ősre mutat.		* Minden külön táblába, a 1 ős osztályban lesz discriminator, valamint a gyermek osztályokban lesz egy ID attribútum, ami az ősre mutat.
	* Discriminator nem szükséges, diákon sem volt: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tablepersubclass-discriminator		* Discriminator nem szükséges, diákon sem volt: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tablepersubclass-discriminator

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

	* Probléma:		* Probléma:
49. sor:		49. sor:
	* UML ábra -> diasor		* UML ábra -> diasor

	====~~07.~~ 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.====		====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.====

	<pre>		<pre>
59. sor:		59. sor:
	</pre>		</pre>

	====~~08.~~ Deadlock-hoz vezet-e az alábbi kódrészlet?====		====Deadlock-hoz vezet-e az alábbi kódrészlet?====

	<pre>		<pre>
92. sor:		92. sor:
	</pre>		</pre>

	====~~09.~~ Mik a SAX alapvető jellemzői? (3p)====		====Mik a SAX alapvető jellemzői? (3p)====

	* Eseményvezérelt, callback (ContentHandler)		* Eseményvezérelt, callback (ContentHandler)
98. sor:		98. sor:
	* Állapotfüggetlen feldolgozás		* Állapotfüggetlen feldolgozás

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

	* RMI stub - proxy		* RMI stub - proxy
106. sor:		106. sor:
	* AWT eseménykezelés - observer		* AWT eseménykezelés - observer

	====~~11.~~ A SwingWorkerre miért van szükség és kinek a felelőssége meghívni a process() és publish() metódusokat? (3p)====		====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		* Java -> Swing fejezet -> szálkezelés téma
124. sor:		124. sor:
	* 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		* 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

	====~~12.~~ 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)====		====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. <br>		* Írj a témáról amit jólesik, 3 pontért. <br>

	====~~13.~~ Reverse skip deltás példa. Mely revíziókat hogyan tároljuk el a 20., legutolsó revízióhoz képest? (3p)====		====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 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 ...)
135. sor:		135. sor:
	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)		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)

	====~~14.~~ 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)====		====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.		* 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.
142. sor:		142. sor:
	Avagy ezeket lehet változtatgatni. [[CsL]]		Avagy ezeket lehet változtatgatni. [[CsL]]

	====~~15.~~ Choice(Identity, v) = ? ====		====Choice(Identity, v) = ? ====
	= Identity		= Identity

Ferrero, 2013. január 3., 17:45-n

2013-01-03T17:45:27Z

← Régebbi változat		A lap 2013. január 3., 19:45-kori változata
1. sor:		1. sor:
	~~{{GlobalTemplate\|Infoszak\|OotVizsga20100526}}~~

	===OO Vizsga 2010-05-26===		===OO Vizsga 2010-05-26===

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|OotVizsga20100526}} ===OO Vizsga 2010-05-26=== TOC ====01. Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat==== (ob…”

2012-10-21T20:44:06Z

Új oldal, tartalma: „{{GlobalTemplate|Infoszak|OotVizsga20100526}} ===OO Vizsga 2010-05-26=== __TOC__ ====01. Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat==== (ob…”

Új lap

{{GlobalTemplate|Infoszak|OotVizsga20100526}}

===OO Vizsga 2010-05-26===

__TOC__

====01. 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).

====02. 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

====03. 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.

====04. 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

====05. 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?====

* Minden külön táblába, a 1 ős osztályban lesz discriminator, valamint a gyermek osztályokban lesz egy ID attribútum, ami az ősre mutat.
* Discriminator nem szükséges, diákon sem volt: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tablepersubclass-discriminator

====06. 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

====07. 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.====

<pre>
Object clone(){
A a3 = new A();
a3.b = b.clone();
return a3;
}
</pre>

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

<pre>
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();
}
}
}
</pre>

* 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.<br>
* 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". <br>

<pre>
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
</pre>

====09. 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

====10. 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

====11. 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

====12. 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. <br>

====13. 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)

====14. 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]]

====15. Choice(Identity, v) = ? ====
= Identity

-- [[ZsolnaiKaroly|keeroy]] - 2010.05.28.

-- [[CsL]] - 2010.05.28.

-- [[MolnarMarton|molnarm]] - 2010.05.29.

-- [[FelberPeter|Eff]] - 2010.06.12.

-- [[MetykoCecilia|Ciana]] - 2010.06.12.

[[Category:Infoszak]]

Objektumorientált szoftvertervezés - Vizsga, 2010.05.26. - Laptörténet

Hryghr: Hryghr átnevezte a(z) OotVizsga20100526 lapot a következő névre: Objektumorientált szoftvertervezés - Vizsga, 2010.05.26.

Ferrero, 2013. január 3., 17:46-n

Ferrero, 2013. január 3., 17:45-n

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|OotVizsga20100526}} ===OO Vizsga 2010-05-26=== __TOC__ ====01. Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat==== (ob…”

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|OotVizsga20100526}} ===OO Vizsga 2010-05-26=== TOC ====01. Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat==== (ob…”