„Objektumorientált szoftvertervezés - Vizsga, 2008.06.03.” változatai közötti eltérés
A VIK Wikiből
aNincs szerkesztési összefoglaló |
|||
(2 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva) | |||
45. sor: | 45. sor: | ||
====RMI során átadható paraméterek osztályozása és a paraméterátadás módja (felsorolás + 1-1 rövid mondattal jellemzés, 3p)==== | ====RMI során átadható paraméterek osztályozása és a paraméterátadás módja (felsorolás + 1-1 rövid mondattal jellemzés, 3p)==== | ||
[[OotElosztottRendszerek]] | |||
* Pass-by-Reference | |||
** a metódus a paraméterre mutató referenciát kap | |||
** a metódus a referencián keresztül éri el a paramétert, amit a hívó tart | |||
** azok adhatóak át így, akik implementálják a Remote interfészt | |||
* Pass-by-Value (Copy) | |||
** a paraméter lemásolódik | |||
** a metódus a másolatot kapja meg, és azon dolgozik | |||
** mindenki más így adódik át | |||
====Volt egy XSD séma, ahol az elemen belül volt egy simpletype definiálva, át kellett írni olyanra, hogy kívül legyen (2p)==== | ====Volt egy XSD séma, ahol az elemen belül volt egy simpletype definiálva, át kellett írni olyanra, hogy kívül legyen (2p)==== | ||
Egy példa a feladathoz: | |||
; Beágyazott | |||
<xs:element name="car"> | |||
<xs:simpleType> | |||
<xs:restriction base="xs:string"> | |||
<xs:enumeration value="Zhiguli"/> | |||
<xs:enumeration value="Moskvitch"/> | |||
<xs:enumeration value="Zaporozhets"/> | |||
</xs:restriction> | |||
</xs:simpleType> | |||
</xs:element> | |||
; Külön típusdefiníció | |||
<xs:element name="car" type="carType"/> | |||
<xs:simpleType name="carType"> | |||
<xs:restriction base="xs:string"> | |||
<xs:enumeration value="Zhiguli"/> | |||
<xs:enumeration value="Moskvitch"/> | |||
<xs:enumeration value="Zaporozhets"/> | |||
</xs:restriction> | |||
</xs:simpleType> | |||
====XSD sorrendiséget és gyakoriságot befolyásoló tag-ek (felsorolás + 1-1 rövid mondattal jellemzés, 5p)==== | ====XSD sorrendiséget és gyakoriságot befolyásoló tag-ek (felsorolás + 1-1 rövid mondattal jellemzés, 5p)==== |
A lap jelenlegi, 2013. június 18., 00:39-kori változata
OO Vizsga 2008-06-03
Hibernate: Mi(k)nek a metódusa createQuery()? (2p)
- session -> ez a jó
- perzisztens kollekció
- tábla
- tranzakció
Adott az alábbi kód. Mit csinál, mi a következménye, hogy tehető korrekté? (6p)
Object object = db.getRoot("username"); ObjectStore.destroy(object);
A getRoot és a destroy közé kell:
db.setRoot("username", null);
Ezzel a root mögötti objektumot tudjuk törölni.
WMC (Weighted Method Class) metrika definíciója. (2p)
- Egy osztályhoz tartozó metódusok CC-je (metódus bonyolultsága) összesen
- Egy osztály elkézítésének bonyolultsága ?
Egy funkción belül mikor nevezzük a kohéziót procedurálisnak? Miről ismerhető fel könnyen? (2p)
- instanceof (???)
Aktív objektum mintában az ütemező (Scheduler) a Request_Method példány meghívásakor átad egy paramétert. Mi az és mi a feladata?
Valószínűleg ez a Servanthoz lesz a referencia, ami majd futtatni fogja a metódus kódját. Másképp honnan tudja a method_request, hogy melyik servanthoz hívjon be? Ez tűnik logikusnak. forrás
Adott egy bináris fa, a fa csúcsaiban vagy Guard vagy Node objektumok, ezeknek közös az ősük, amely vizitálható. Adott a vizitor interfész, illetve két megvalósítása:
- Visit_Print: ez kiírja a Node-ban tárolt értéket
- Sequ3: a faelemet meglátogatja a konstruktorában megadott 3 vizitort (mint a diasorban a Sequence, csak ebben 3 van)
- Visit_InOrder: a Sequ3-ból származik, a fa inorder bejárását végzi el, közben minden Node element végrehajtja a konstruktorában megadott vizitort. Ez nincs készen, ez a c) feladat
- Visitor interfészbe a metódusok beírása az UML diagramon (1p)
- Az inorder bejáráshoz szükséges egyéb vizitorok megadása az UML-diagramon és konstruktoraikkal, metódusaikkal (4p)
- Visit_InOrder konstruktorának megírása a fenti többi vizitor használatával (4p)
- A vizitorok létrehozása és meghívása, hogy a fa elemei listázásra kerüljenek (2p)
RMI során átadható paraméterek osztályozása és a paraméterátadás módja (felsorolás + 1-1 rövid mondattal jellemzés, 3p)
- Pass-by-Reference
- a metódus a paraméterre mutató referenciát kap
- a metódus a referencián keresztül éri el a paramétert, amit a hívó tart
- azok adhatóak át így, akik implementálják a Remote interfészt
- Pass-by-Value (Copy)
- a paraméter lemásolódik
- a metódus a másolatot kapja meg, és azon dolgozik
- mindenki más így adódik át
Volt egy XSD séma, ahol az elemen belül volt egy simpletype definiálva, át kellett írni olyanra, hogy kívül legyen (2p)
Egy példa a feladathoz:
- Beágyazott
<xs:element name="car"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Zhiguli"/> <xs:enumeration value="Moskvitch"/> <xs:enumeration value="Zaporozhets"/> </xs:restriction> </xs:simpleType> </xs:element>
- Külön típusdefiníció
<xs:element name="car" type="carType"/> <xs:simpleType name="carType"> <xs:restriction base="xs:string"> <xs:enumeration value="Zhiguli"/> <xs:enumeration value="Moskvitch"/> <xs:enumeration value="Zaporozhets"/> </xs:restriction> </xs:simpleType>
XSD sorrendiséget és gyakoriságot befolyásoló tag-ek (felsorolás + 1-1 rövid mondattal jellemzés, 5p)
Sorrendiséghez:
- all - tetszőleges sorrendben
- choice - a listából csak az egyik
- sequence - pontosan ugyanabban a sorrendben
Gyakoriság:
- minOccurs maxOccurs attribútumok
Milyen hibákat kaphatunk egy XML dokumentum SAX-al való feldolgozása során? (3p)
- fatal error - a dokumentum nem jól formált (szintaktikai hiba, nincs lezárva tag)
- error - a dokumentum nem valid (szemantikai hiba, pl nem felel meg a sémának)
- warning - figyelmeztetés (pl. ha kétszer definiálunk egy típust)
Mik a SAX (simple api for XML) jellemzői? (3p)
- eseményvezérelt
- soros elérésű
- alacsony memória-igény
- nagy sebesség
- nem lehet előre- és visszaugrani
- állapotfüggetlen feldolgozás
Mik az AWT konténerek felelősségei? (3p)
- komponensek megtalálása
- fókusz továbbadása
- komponensek elhelyezése
Milyen tervezési mintákat valósítanak meg (Swing)? (4p)
- Konténerek és komponensek összekapcsolása
- Eseménykezelés
- LayoutManager használata
- JScrollPane használata
Szerintem inkább ez kell ide:
- Konténerek + komponensek - Composite pattern
- Eseménykezelés - Observer pattern
- LayoutManager - Strategy pattern
- JScrollPane-nél Decorator pattern
- JTree-nél Null Object pattern
Miért nem ajánlott beágyazott/mobil környezetben a Listener-alapú eseménykezelés? (2p)
- túlságosan is erőforrásigényes
- nem engedheti meg egy beágyazott környezet a beragadott objektumokat
- sokszor dinamikusan jönnek létre és szűnnek meg az objektumok
-- aldaris - 2009.05.27.
-- buc - 2008.06.03.
-- Csádám - 2010.05.31.