Szoftvertechnológia - Lehetséges vizsgakérdések

← Vissza az előző oldalra – Szoftvertechnológia

Korábbi Google Docs-segédlet (Lehetséges vizsgakérdések) Wikis változata. Innentől szerkesszük itt, köszi! (_{Hint az ilyen doksik Wikis átalakításához: docx-ben letölt, Microsoft Office Word Add-in For MediaWiki felrak, majd MediaWiki-formátumban elmentés (txt), majd annak Wikire történő bemásolása, némi korrekciók, és kész.}) --Haraszin Péter (vita) 2013. június 15., 20:48 (UTC)

UML/CLASS

• Late binding: probléma: több ugyanolyan nevű függvény → objektumhoz kötődik runtime a függvény!
• UML diagram elemek: vizuális relációk:
  • kapcsolat (connection)
  • tartalmazás (containment)
  • vizuális kapcsolás (közelség, visual attachment)
• UML 2 kiterjesztő mechanizmus
  • korlátozás (constraints)
  • sztereotípia (speciális név-érték/tagged value/ pár (bool))
  • tagged value (név-érték pár)
• Osztálydiagrammra standard sztereotípiák
  • utility - az osztály minden változója és metódusa statikus (osztály szkóp)
  • metaclass - olyan osztály, amelynek példányai osztályok
  • interface, enumeration
• Class attribútum property(tulajdonság) módosítók:
  • readOnly, subsets, union, redefines, ordered, unique, valami expression
• Class collection types:
  • Set, OrderedSet, Bag, Sequence
• Class metódus property(tulajdonság) módosítók:
  • query, redefines, ordered, unique, oper-constraint(kényszer)
• Operációk konkurenciája (konkurenciaszemantikák, concurrency semantics):
  • szekvenciális/sorrendi (sequential) - elméletileg nem lehet, hogy más hívja meg az operációt, nem fordulhat elő konkurencia ("callers must coordinate outside the object so that only one flow is in the object at a time.")
  • őrzött (guarded) - jöhet ilyen hívás, előfordulhat konkurencia, de megoldott a kezelése; pl. ha befejezte a működését, csak akkor jöhet a következő ("multiple calls from concurrent threads may occur simultaneously to one instance, but only one is allowed to commence. Others are blocked.")
  • konkurens (concurrent) - bejöhet hívás, azonnal lekezelődik, nem jó, mert félbeszakíthat folyamatokat ("multiple calls from concurrent threads may occur simultaneously to one object on any concurrent operation, and all may proceed concurrently with correct semantics")
• Active Object: saját szála van az objektumnak.
• Mi az a classifier?
  • osztályszerű: osztálynak kinéző dolgok felett metaosztály(class, interface, datatype..)
• UML diagramon mi a role, asszociáció?
  • CLASSIFIER!
• UML class diagramon az asszociációnál mi a "/"?
  • AZ ASSZOCIÁCIÓ LE VAN SZÁRMAZTATVA!
• Mit jelent, ha egy pont van az asszociáció valamelyik végén?
  • OWNERSHIP! Ki birtokolja az osztályt.
• Hogyan lehet UML class-szal ábrázolni, hogy valami tartalmaz valamit?
  • karika, benne plus sign, inner class, tagváltozó, aggregáció

UML/PACKAGE,Component, Composite Structure, Deployment, Use Case

• Milyen package importokat ismer?
  • import: fölötte lévő import/access is látja;
  • access: fölötte lévő import/access NEM LÁTJA!! //megj.: merge: több package-ben lévő dolgokat valahogy egyesítem
• Components vs Class
  • komponensek csak interfészen keresztül érhető el, komponens önállóan kezelhető (class nem!)
• Milyen fajtái vannak a komponenseknek?
  • telepítendő (deployment): az installáláshoz szükségesek
  • fejlesztés során keletkező (work product): felhasználónak nem szabad kiadni
  • execution: runtime jön létre (pl. fájl)
• Milyen connectorokat ismer component világban?
  • assembly: komponenseket összekötő konnektor, elvárt, megkövetelt interfészek megfelelnek (sima vonal)
  • delegation connector: bonyolult dolgot zár be "dobozba"
• <<delegate>> sztereotípia? szaggatott vonal!
• Kompozit struktúrák esetén mit nevezünk kollaborációnak?
  • egy meghatározott funkcionalitás megvalósításához szükséges együttműködő elemek
• Deployment diagram elemei?
  • artifact /komponenshez termék/,
  • node /logikai erőforrás/,
  • device /fizikai erőforrás/,
  • executionEnvironment /végrehajtási környezet/
• Milyen Use Case kapcsolatokat (relációkat) ismer?
  • asszociáció
  • include - mindenféleképpen kiegészítjük bizonyos funkcionalitásokkal,
  • extend - bizonyos körülmények között egészítjük csak ki a megcélzott elemet
• Mikor használjuk use case-ben actor-jelölésnek a pálcikaember helyett a doboz/<<actor>> sztereotípiás jelölést?
  • Ha egy actoron belül el tudunk képzelni egy másik actort /pl.: tetrisben egy elem, amelyik esik lefele, lehet, hogy nem esik lefele, hanem egy actor ejti lefele. Ekkor lehet azt mondani, hogy egy "belső actor" lépteti folyamatosan/
• Mi a különbség Use Case include és extend sztereotípia között?
• Use Case tulajdonságok (propertyk)?

UML/Szekvencia, Kommunikáció, Interaction Overview

• Interakció diagramon mik a felelősségek?
  • Doing (csinálni valamit): valamit önmagában, más objektumok tevékenységeinek irányítása/koordinálása, más objektumokban művelet kezdeményezése
  • Knowing about (valamiről tudni): private encapsulated data, kapcsolódó objektumok, dolgok amiket ki tud számolni
• Mi a különbség üzenet és jel között interakció-diagrammokon?
  • üzenettel operációt hajtatunk végre, jellel állapotváltozást jelzünk.
• Milyen Event-ek vannak Interaction diagramokon?
  • ExecutionEvent,
  • CreationEvent,
  • DestructionEvent,
  • MessageEvent
• Milyen 2 fontos elvet ismer interakció-diagrammokon eseménysorozat értelemben?
  • Compositional: összemerge-ölök különböző eseménysorozatokat.
  • Átlapoló szemantika: ugyanúgy összemerge-ölök, de egy eseménysoron belül a sorozat sorrendje változatlan!
• Mire jó az Interaction Overview Diagram?
  • magasszintű kép, ahol egy-egy doboz lehet akármilyen interakció, és időzítési előírás is lehet közöttük.
• Milyen dobozok lehetnek szekvenciadiagramon? Mit jelentenek?

UML/State machine, Activity, Beyond UML

• Állapotdiagramon milyen kompozit állapotokat ismer?
  • simple (1 régió), orthogonal (1-nél több régió)
• Mik az Activity diagram elemei?
  • alaktivitások (procedúra), döntések, fork és join, úszósávok, object-action flow
• Mik az állapotgép diagram elemei?
  • entry/exit-action, állapotátmenet (esemény(arg?)/tranzakció), deep/shallow-history indicator, fork-join
• Mi az Eclipse Modeling Framework(EMF)?
  • Modellező eszköz (pl. UML-hez hasonló (MOF) diagramokat lehet csinálni), kódgeneráló is!
• Mi az XMI?
  • XML Metadata Interchange: XML-ben leírt UML/MOF diagram

JAVA

• Singleton vs static class:
  • static classban csak static metódusok lehetnek!
• Class nem lehet static, csak INNER CLASS!!!!!!!!!
• Array length-je megmondja, mekkora a MÉRETE! Nem azt, hogy mennyi értelmes adat van benne!
• Nézd meg a String == és equalsTo miket csinál!
  • pl null, stb..
• Mit vár a Thread.sleep()?
  • long-ot!!!!
• Thread-ek között hogyan lehet kommunikálni, honnan öröklődik ez?
  • Object.notify(), .notifyAll() és .wait()
• Thread osztály metódusai?
  • isAlive(), join(), resume(), suspend(), stop(), start(), sleep(), destroy(), yield(),
• Multitasking 2 fajtája?
  • process-based
  • thread-based
• Hogy lehet meghívni az ős egy attribútumát/függvényét?
  • super.attrName / super.function()
• Object class-ban mik final-ok?
  • getClass(), notify(), notifyAll(), wait()
• Lehet egy osztály final ÉS abstract?
  • NEM!!!
• Milyen típusai vannak a szálaknak?
  • Daemon és nem daemon (daemon gyakorlatilag háttérben futó szál)
• Milyen synchronized-ok vannak?
  • blokk: synchronized (o) { ... } ahol o valami Object (vagy abból leszármazott, int/long/double/etc nem)
  • method: public synchronized void foo() { ... }
  • Egyszerre csak 1 szál tartózkodhat az adott objektum (methodnál this) synchronized blokkjában/methodjában, a többi blokkol addig
• Mi az az atomi művelet?
  • Guarded :) ha valaki módosítja, akkor más metódus nem lát inkonzisztens állapotot. primitív adattípusokra, kivéve long és double
• Mikor lehet a wait(...), notify(),notifyAll() függvényeket meghívni?
  • Ha az objektum monitorának birtokában vagyunk.
• Mi a különbség early (static) binding és late binding között?
  • TODO
• Mikor mit jelent a final?
  • osztály előtt: nem lehet leszármaztatni
  • metódus előtt: nem lehet felüldefiniálni leszármazottban;
  • változó előtt: nem lehet neki értéket adni (csak public final int i = 7; vagy konstruktorban)
• Mikor mit jelent az abstract?
  • Osztály előtt: nem lehet példányosítani, NEM KÖTELEZŐ, HOGY LEGYEN BENNE ABSZTRAKT METÓDUS
  • Metódus előtt: leszármazottnak implementálni kell.
• Mit jelent, hogy a változó statikus/dinamikus része?
  • List x = new ArrayList();
    • egyenlőségjel bal oldala a statikus rész, ő lehet absztrakt is (tehát interfész is, mint a List is az);
    • jobb oldal a dinamikus, nem lehet absztrakt/interfész!!
• Lehet konstruktor static?
  • NEM!!!!!
• Mit nevezünk kiterjesztésnek JAVA nyelvben?
  • ha egy vagy több interfészt valósít meg egy osztály

JUnit:

• @Before, @Test, @After
• Hogyan lehet jelölni, hogy pl. IOException-t várok?
  • test függvény előtt @Test(expected=IOException.class)
• Hogyan lehet parametrizált teszteket csinálni?
  • osztály előtt: @RunWith(Parameterized.class)

 @RunWith(value = Parameterized.class)
 public class JunitTest6 {
    private int number;
    public JunitTest6(int number) {
       this.number = number;
    }
    @Parameters
    public static Collection<Object[]> data() {
      Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
      return Arrays.asList(data);
    }
    @Test
    public void pushTest() {
      System.out.println("Parameterized Number is : " + number);
    }
 }

• assertEquals(elvárt, aktuális);
• Milyen kimenetelei lehetnek a tesztnek?
  • pass: megfelel,
  • failure: nem az elvárt eredményt kapjuk valamilyen tesztre,
  • error: Exception dobódik, és nem kezelődik le
• Hogyan lehet vizsgálni, hogy egy teszt tovább fut bizonyos időnél(pl 1 mp)?
  • @Test(timeout=1000)
• Főbb függvények?
  • assertTrue(..), assertFalse(..), assertNull(..), assertNotNull(..), assertSame(..), assertNotSame(..), assertEquals(..), assertNotEquals(..), fail([String msg])

Bevezetés

• Evolution of engineering discipline:
  • production+craft → commercial;
  • commercial+science → professional engineering
• Mi a szoftverkészítés 4P-je?
  • People, Problem, Process, Product
• Milyen minőségi képeket ismer?
  • transzcendentális, felhasználói, gyártás, termék, értékarányosság
• ICOM-modellnél mi az input, kontrol(vezérlés), erőforrások, kimenet?
  • input: követelmények,
  • kontrol: {pénz,szabványok},
  • erőforrás: {csapat,eszközök},
  • kimenet: {kód,dokumentáció}
• A vízesés modellben hogyan lehet visszalépni?
  • Az előzőre mindig + Validation → specification && M → R
• Prototípus modellnél mik az egyes fázisok / hogyan lehet visszalépni?
  • Requirement → Specification → Quick design → Implementation → Evaluation.
  • Evaluation → Requirement
• CMM-ben milyen Maturity (érettségi) szinteket ismer?
  • (1)Kezdetleges
  • (2)Ismétlődő
  • (3)Definiált
  • (4)Menedzselt
  • (5)Optimalizált
• Spirál modellben milyen síknegyedek vannak jobbról balra körbe?
  • Követelmények meghatározása, kockázatelemzés, engineering (technológia), kiértékelés

RUP

• Milyen workflow-hoz milyen modell tartozik?
  • Követelmények: Use Case Model,
  • Analízis: Analízis model,
  • Tervezés: Tervezési model,
  • Implementation: Implementation diagram,
  • Deployment: Deployment diagram
• Az egyes modellek milyen UML diagrammokat tartalmaznak?
  • Use Case: {Use Case, Sequence};
  • Analízis: {static structure diagram, sequence};
  • Tervezési modell: {static structure, kommunikációs, állapotdiagram, activity};
  • Implementációs modell: {komponens, szekvencia};
  • Deployment: {Deployment, sequence}

• 

• Milyen típusú use case-ek vannak?
  • Event based, actor based
• Milyen dimenziói vannak a use case-formátumoknak?
  • (1) Leírás részletezettsége (magas szintű/kiterjesztett)
  • (2) Fogalmi/valóságos
  • (3) Prioritás (elsőrendű/másodrendű/opcionális)
• Miben különbözik a magas szintű (high level) és a kiterjesztett (expanded) use-case ?
  • A leírás részletezettségében
    • magas szintű: név, aktorok, cél, áttekintés, referencia
    • kiterjesztett: eseményfolyam, elő- és utófeltételek, kiterjesztési pontok, relációk, aktivitás és use-case diagram, referenciák)
• Miben különbözik a lényeges (essential) és a valóságos (real) use-case ?
  • A technológia függőségében
    • lényeges: eszköz-, implementációfüggetlen
    • valóságos: implementáció (ablakok, mezők, triggerek)
• Hogyan rangsorolunk use case-eket (iterációknak)?
  • (1) időben kritikus
  • (2) kockázatosak
  • (3) alapvető kutatást igénylők
  • (4) alkalmazás szempontjából legfontosabbak
  • (5) üzleti élet szempontjából fontosak
• Fogalmi modellnél mi a térképész elv?
  • Használjuk a területen alkalmazott neveket!
  • ne kreáljunk olyan dolgokat, amik nincsenek ott!
  • Lényegtelen részleteket hagyjuk ki!
• Mik a mutátorok?
  • típusok amik megváltoztathatják a típusukat vagy szerepüket
• Interakció diagramon mik a felelősségek?
  • Doing (csinálni valamit): valamit önmagában, más objektumok tevékenységeinek irányítása/koordinálása, más objektumokban művelet kezdeményezése
  • Knowing about (valamiről tudni): private encapsulated data, kapcsolódó objektumok, dolgok amiket ki tud számolni

V&V

• Review definíciók?
  • Review, Review item, Audit, Walkthrough (az anyag készítője bemutatja a munkáját, Inspection (reviewereknek kiosztanak anyagot, ők jelentést tesznek róla, majd ezt egy bizottság megvitatja a szerző jelenlétében. Pl. egyetemi diplomavédés)
• Kik a meeting szereplői?
  • Koordinátor (felelős a meetingért),
  • Lead reader (anyag működésével tisztában van),
  • jegyzőkönyvvezető,
  • megbízó képviselői
• Mit kell tenni, ha hibát találunk a meetingen?
  • (1) kijelölni egy felelős személyt
  • (2) meghatározni, mi a teendő
  • (3) problémák osztályozása
• Hogyan lehet becsülni, hogy mennyi hiba van a programban?
  • elrejtünk hibákat, mennyit találnak meg..
• Konformanciatesztelés vs hibadetektálás?
  • Konformanciatesztelés: a szoftvernek bizonyos feltételeknek kell eleget tennie,
  • hibadetektálás: program futása közben tesztelünk
• Mi az a Pareto-elv?
  • 80-20 szabály: a programhibák 80%-ért a program 20%-a okolható
• Integrációs tesztre milyen stratégiák vannak?
  • top-down (GUI-menüt rakom először össze, a még nem ismert funkcióknak "not yet implemented" - ez a test stub),
  • bottom-up (legózás)
• Funkcionalitás teszt esetei?
  • funkcionális teszt,
  • biztonsági teszt,
  • mennyiségi teszt (hatalmas adattal elárasztás)
• Megbízhatósági teszt esetei?
  • integritási (kibírja-e hiba nélkül?),
  • struktúra (ismerem a program belsejét, erre alapozva végzek idétlen teszteket),
  • stresszteszt
• Teljesítménytesztek?
  • benchmark (összehasonlítás referenciaszoftverrel),
  • contention (stressz teszt alfaja, több actor versenyez ugyanazokért az adatokért),
  • load-teszt (működési limit környékén működés),
  • teljesítményprofil
• Támogatottság-teszt?
  • hogyan konfigurálható/installálható
• Tesztmértékek?
  • követelmény-alapozott,
  • kód-alapozott,
  • hibaanalízis
• Mi jellemző a tesztstratégiákra?
  • Megmondja az általános megközelítést,
  • milyen technikákat/eszközöket használunk,
  • mi a teszt sikeressége,
  • hogyan teszteljük a számunkra külső dolgokkal (tesztsegédprogramok)
• Milyen teszteseteket ismer?
  • White-box: minden lehetséges döntési ágon, minden lehetséges adattal végigmegyünk (gyakorlatilag biztosan lehetetlen), ismerjük a szoftver belső szerkezetét;
  • Black-box test: !!ekvivalencia-osztályozás!!: tudunk azonosítani bizonyos tevékenységeket,
  • boundary value(határérték) tesztelés: ekvivalencia osztály határok tesztelése,
  • speciálisérték-tesztelés.

Design

• Informatikai szemléletben mi köré szoktunk absztrakciót húzni(absztrakció típusai)?
  • funkcionalitás, adat, kontroll
• Mi az, hogy afferens/efferens egy adatáramlás?
  • Afferens: az adat felfelé halad (arra halad, amerre bonyolultabb/összetettebb problémák vannak, amelyből szétszedtem kisebb problémákra);
  • efferens: fordítva
• Mi a fan-out/fan-in szám?
  • Fan-out: egy modult hány részre szedem szét,
  • fan-in: modult hányan hívnak fentről
• Mi a vezérlési/döntési hatáskör? / Mi a döntési hasítás?
  • vezérlési: maga a modul, és mindenki, aki alá tartozik;
  • döntési: azon modulok, akiket érint az adott modul döntése.
  • döntési hasítás: ha a döntési hatáskör nagyobb, mint a vezérlési
• Mik a dimenziói a csatolásnak?
  • Mit kommunikálunk? Milyen nagy a kapcsolat? Mennyi ideig tart a kapcsolat?
• Mik a csatolás dimenziói?
  • kapcsolat tárgya, kapcsolat mérete, kapcsolat ideje
• A kapcsolat tárgya alapján hogyan lehet csoportosítani a csatolásokat?
  • laza csatolás (primitív adat/tömbje),
  • stamp csatolás (összetett adatok, record, struct),
  • control csatolás (vezérlést adunk át),
  • közös adat (nem tudjuk, kinek a kezében van, bárki hozzáférhet),
  • tartalmi jellegű csatolás (a másik programrészletet, mint erőforrást kezelem -.-)
• Hogyan lehet osztályozni a csatolást az időtartam alapján?
  • writing, compiling, linking, loading, running
• Hogyan lehet a kohéziót osztályozni?
  • ↓ /egyre gyengébb/ funkcionális (oszthatatlan; pl. sqrt() függvény),
  • szekvenciális (több funkcionális egymás után),
  • kommunikációs (egy adatszerkezeten műveleteket végzünk, a kohézió itt az, hogy egy adatszerkezeten dolgoznak),
  • procedurális (printf: double és String is elfogad, de a két paraméternek nincs köze egymáshoz. típusfüggő switch),
  • temporális(időbeliség tart össze),
  • logikai,
  • véletlenszerű
• Ha több helyről öröklünk, mi vonatkozik az invariánsokra?
  • az invariáns a többszörös öröklésekből származó kondíciók ÉS-kapcsolata
• Mi a redeklarációs szabály?
  • Az előfeltételnek a leszármazottban gyengébbnek (vagy egyenlőnek) kell lennie, az utófeltételnek erősebbnek (vagy egyenlőnek).

Design/Software architectures

• Milyen főbb kategóriáit ismeri a szoftverarchitekturális mintáknak?
  • Adatfolyam-szerkezetek → Batch, Pipes and filters
  • Call-and-return-rendszerek → Main program és szubrutin, OO rendszerek, hierarchikusan rétegelt
  • Adatközpontú rendszerek → adatbázisok, Hypertext rendszerek, Blackboards
  • Virtuális gép → Interpreter, Rule-based system
  • Független komponensek → Communicating processes, esemény-alapú rendszerek
• Mi a BPEL? Milyen fajtái vannak?
  • Business Process Execution Language → le lehet írni üzleti folyamatokat vele.
  • 2 fajtája:
    • orchestration & choreography.
      • Orchestration (orkesztráció): centralizált folyamatvégrehajtás. Egy központ ismeri a teljes folyamatot, az kér szolgáltatást az együttműködőktől, akik csak a saját dolgukat végzik.
      • Choreography (koreográfia): folyamatot küldhetek másnak, aki továbbküldheti stb. a folyamat nincs központosítva, minden résztvevő a dolgát elvégezve az általa ismert következő résztvevő(ke)t aktivizálja.

Agilis

• Mik a Scrum alappillérei?
  • átláthatóság (business világ és fejlesztői világ között),
  • folyamatos felülvizsgálat,
  • Adaptáció (eltérést gyorsan fel kell számolni)
• mit jelent a grooming?
  • a termék tulajdonságainak folyamatos finomítása
• Milyen szerepek vannak a scrumban egy sprintben?
  • pigs (életükkel fizetnek a projektért)
    • product owner: ügyfél, product backlog felügyelete, átveszi/elfogadja a munkát
    • scrummaster: adminisztrátor, felel a projektért
    • team: 5-9 ember, önszervező, önvezérlő
  • chickens (csak hozzájárulnak a projekt sikeréhez)
    • stakeholders (érdekeltek)
    • managers
• Milyen események vannak a Scrumban?
  • sprint tervezés, áttekintés, visszatekintés és napi Scrum-meeting
• Milyen termékek vannak Scrumban?
  • Product backlog (user story-k összegyűjtése/wishlist/ → product owner a felelős érte),
  • sprint backlog (a product backlogból elfogadott kívánságok/user story-k),
  • burndown chart (Y:work remaining, X: time; naponta megnézzük, mennyi munka van még hátra, ebből tudunk becsülni, mikor készül el/mikor lesz 0 a work remaining)
• Milyen elemei vannak egy XP projectnek?
  • 

Management

• Milyen típusú projekt planek vannak?
  • long term, short term
• Mi a projektmenedzsment feladata?
  • felelősségvállalás, erőforrás újraosztása, ütemezés, követelményeken lazítani, oktatásra küldeni a munkatársakat
• Milyen erőforrások vannak?
  • emberek, szoftver, hardver
• Mit kell menedzselni?
  • idő, információ, szervezet, minőség, pénz
• Hogyan kell ütemezni egy projektet?
  • DIAGRAM → requirements, Identify activities, Identify dependencies...
• Mik a kockázatmenedzsment lépései?
  • Kockzatok azonosítása, kockázatok elemzése, kockázattervezés, kockázatok monitorozása
• Milyen mérések/becslések vannak?
  • a fejlesztéshez mennyi erőfeszítés kell?,
  • mértékek (LOC - Lines of Code, FPA - funkciópontelemzés),
  • komplexitás (hogyan mérjük, hogy mennyire bonyolult valami?)

CM

• Mi a 3 nézete a CM-nek?
  • Change Request Management: változások kezelése,
  • Configuration Management: különböző dokumentumok/kódok egy programmá állnak össze,
  • Mérések
• Milyen elemeket kell azonosítani?
  • configuration item, communication (email ..), dokumentáció, implementáció
• Miért felelős a Change Request Management?
  • hogyan kezeljük a változásokat,
  • Change Control Board - változáskezelő bizottság,
  • defect management - mikor, hogyan, ki, milyen prioritással kezeli a problémákat
• Miért felelős a Build management?
  • Milyen alapanyagokból hogyan rakjuk össze a programot
• Mi az a baseline?
  • pillanatkép a projektről. Ha valami változtatás történik, azt deltának hívjuk.
• Release management definíciók?
  • verzió: funcionálisan különböző,
  • variáns: funkcionalitásban nem különbözik,
  • release: verzió, amit kiad a team;
  • revision: verzió+variáns
• Mivel kell foglalkozni source-szinten egy projekt életciklusában?
  • Backup, change logs, együttműködés (több verzió egy source-ra), helyileg eltérő file-ok, branching
• Milyen delta-kezeléseket ismer?
  • reverse delta: a legújabb verzió van elmentve, a változások (delták) ehhez viszonyulnak;
  • forward delta: az első verzió az alap, ehhez jönnek a delták (tehát a legújabb verzió sok-sok delta után derül ki, hogy micsoda... nem praktikus, bár a commit-ok gyorsabbak lehetnek);
  • skip-delta
• Mi a szótára a VC-nek? (Version Control)
  • working copy,
  • repository,
  • check-out: r → wc (kezelt elem kiemelése felhasználásra a közös tárból),
  • check-in/commit: wc → r (kezelt elem visszahelyezése a közös tárba),
  • update: wc szinkronizálása a repo-val
• Milyen metodikákat ismer konkurens hozzáféréshez?
  • lock-modify-unlock, copy-modify-merge
• Mi az a branch?
  • fastruktúrába szedett verziók változása az idő során.
  • trunk: a fővonal,
  • tag: pillanatkép
• Lock-modify-unlock
  • 
• Copy-modify-merge
  • 
• Three-way merge algorithm
  • A' = A = A → A* = A
  • A' = A != A → A* = A
  • A' != A = A → A* = A'
  • A' != A != A → conflict {A, A', A} → A* manual resolve
  • 
• CM / Version Control - Subversion – working copy vs. repository

	unchanged	changed
current	commit - update -	commit publish update -
out of date	commit - update reread	commit out of date error update - merge

• Mire szolgál a verziókezelésben alkalmazott „modify-update-merge” stratégia ? Röviden írja le a működésének lényegét ! (3 pont)
  • mire: termékekhez történő konkurens hozzáférés szabályozása
  • lényeg: párh. check-out, check-in-kor összefésülés, konfliktusfelold.