@@ 1. sor: / 1. sor: @@
 {{Vissza|Szoftvertechnológia#Vide.C3.B3}}
+[[Szoftvertechnológia_-_Videójegyzet#toc|→ Ugrás a tartalomjegyzékhez]] (alulra került, hogy ne vegyen el olyan sok helyet a dokumentum elején)
+'''A Szoftvertechológia videók itt megtekinthetőek, innen letölthetőek:<br />
+http://bme.videotorium.hu/hu/channels/details/902,Szoftvertechnologia'''
 A 2010-es videókhoz készült, időbélyegzőkkel ellátott [[Media:szofttech_video_jegyzet_timestamps_v1.pdf|videójegyzet]] Wiki-aloldallá átalakított, kiegészített változata. Segítségével könnyű megkeresni adott anyagot a videókban.<br />
@@ 6. sor: / 11. sor: @@
 Fontos, hogy ez alapvetően csak gyorsan össze lett firkálva, tehát nem túl rendezett, nem teljes, vannak elütések, stb., nem igazán volt idő ezekre is figyelni (talán érthető módon), de egy kis kiegészítésnek talán jó. Pl. betájolható, melyik rész melyik videóban, merre van, kereshetők a kulcsszavak.
-Úgy alakítottam ki valamiféle hierarchiát az elemek között, hogy az előadás <nowiki><h2></nowiki>-tag legyen, a konkrét diasor <nowiki><h3></nowiki>-tag, az időbélyeg <nowiki><h4></nowiki>-tag, a konkrét dia címe pedig <nowiki><h5></nowiki>-tag. Így legenerálódik belőle egy hierarchikus tartalomjegyzék is (igaz, jó hosszú), a fejezetek belinkelhetők, az alfejezetek külön-külön szerkeszthetők. --[[Szerkesztő:Harapeti|Haraszin Péter]] ([[Szerkesztővita:Harapeti|vita]]) 2013. június 9., 18:52 (UTC)
+Úgy alakítottam ki valamiféle hierarchiát az elemek között, hogy az előadás <nowiki><h2></nowiki>-tag legyen, a konkrét diasor <nowiki><h3></nowiki>-tag, az időbélyeg <nowiki><h4></nowiki>-tag, a konkrét dia címe pedig <nowiki><h5></nowiki>-tag. Így legenerálódik belőle egy hierarchikus [[Szoftvertechnológia_-_Videójegyzet#toc|→tartalomjegyzék]] is (igaz, jó hosszú), a fejezetek belinkelhetők, az alfejezetek külön-külön szerkeszthetők. --[[Szerkesztő:Harapeti|Haraszin Péter]] ([[Szerkesztővita:Harapeti|vita]]) 2013. június 9., 18:52 (UTC)
-A tartalomjegyzéket átraktam alulra, lásd ott, az elején korábban túl sok helyet vett el, ez rontotta az átláthatóságot.
+A Java-jegyzet (1-4. videó) még elkészítendő!!
-== 1. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5409,Szoftvertechnologia_-_1._eloadas 1. előadás] ==
 ===== 4: Kettős célkitűzés: =====
@@ 35. sor: / 40. sor: @@
 * Igény meghaladja a gyártás képességeit → gagyi szoftverek is kikerülnek.
 * Minőség
-* legacy: nagyon régi szoftverek (30éves), működnek, de érdemes lenne korszerűsíteni, ami irdatlan pénz,
+* legacy: nagyon régi szoftverek (30éves), működnek, de érdemes lenne korszerűsíteni, ami irdatlan pénz, munka → honnan kezdjük?
-munka → honnan kezdjük?
 ===== 19: Minőség =====
@@ 49. sor: / 53. sor: @@
 (therac tanulmány)
-== 2. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5410,Szoftvertechnologia_-_2._eloadas 2. előadás] ==
 SW Oktatás Dilemmája:
@@ 131. sor: / 135. sor: @@
 * hatalmas keretrendszerek
-== 3. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5411,Szoftvertechnologia_-_3._eloadas 3. előadás] ==
 === 1.diasor/ ===
@@ 232. sor: / 236. sor: @@
 ** Használat, karbantartás
-== 4. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5412,Szoftvertechnologia_-_4._eloadas 4. előadás] ==
 ===== 14, SW élete =====
@@ 262. sor: / 266. sor: @@
 ** RequirementSpecification: Követelmények technikai része
 ** Preliminary user's manual: felhasználói dokumentumok, felületek!
-** Verifikációs terv (előzetes változata): hogyan fogunk ellenőrizni? Mi a feltétele, hogy átadjuk? Hogyan ellenőrizzük a terméket? SSR
+** Verifikációs terv (előzetes változata): hogyan fogunk ellenőrizni? Mi a feltétele, hogy átadjuk? Hogyan ellenőrizzük a terméket? SRR
 * Architekturális tervezés: milyen elemekből épül? Azok hogyan kapcsolódnak? Nagy komponensek leírása, PDR
 * Részletes tervezés: megmondjuk a programozónak, mit csináljon → munka lebontása elemi lépésekre, melyek kiadhatók, ellenőrizhetők: WBS.
@@ 356. sor: / 360. sor: @@
 * ShortTerm, rövidtáv, akár napi szintre (melyik nap mit kell csinálni)
-== 5. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5413,Szoftvertechnologia_-_5._eloadas 5. előadás] ==
 Menedzser
@@ 427. sor: / 431. sor: @@
 * Kis projekt – jó becslés
 * Nagy projekt – csökkenő pontosság
-* Az igény fordított! Alapellentmondás
+* Az igény fordított! Alapvető ellentmondás
+==== 00:43:54 ====
+==== 00:47:08 ====
-==== 00:43:54
-:47:08 ====
 ===== 24,25 Becslés =====
 * Indokolhatónak kell lennie
@@ 492. sor: / 497. sor: @@
 * Változtatás menedzsment (hogyan mennek végbe változtatások, hogy vannak nyilvántartva)
-== 6. előadás, 4.diasor ==
+== [http://bme.videotorium.hu/hu/recordings/details/5414,Szoftvertechnologia_-_6._eloadas 6. előadás] ==
+=== 4.diasor ===
 ==== 00:14:33 ====
@@ 573. sor: / 580. sor: @@
 ** Üzleti folyamat, szabályzat alakítása
-== 7. előadás 5. diasor ==
+== [http://bme.videotorium.hu/hu/recordings/details/5415,Szoftvertechnologia_-_7._eloadas 7. előadás] ==
-=== Specification, Life-cycle ([http://directory.iit.bme.hu/belso/st/p11_6.pdf 2013: Part11 (p11_6.pdf)]) ===
+=== 5. diasor: Specification, Life-cycle ([http://directory.iit.bme.hu/belso/st/p11_6.pdf 2013: Part11 (p11_6.pdf)]) ===
 ==== 00:01:00 ====
@@ 664. sor: / 671. sor: @@
 * Műsorterv definiálás: eladható székek definiálása → kimenet: eladandó székek
-== 8. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5416,Szoftvertechnologia_-_8._eloadas 8. előadás] ==
 === 5.diasor. 2013: [http://directory.iit.bme.hu/belso/st/p12_6.pdf Part12 - p12_6.pdf] - Specification 2 ===
@@ 674. sor: / 681. sor: @@
 * Process speci: minden process felbontható DataFlow ábrává, míg primitív nem lesz → ekkor szoktunk process specit írni:
 ** Milyen paramétereink vannak (InputOut)
-** Tevékenységek leírása struktúrált angol nyelvvel + szerkezeti konstrukció a tevékenységek összefűzésére, kapcsolatuk szerint:
+** Tevékenységek leírása strukturált angol nyelvvel + szerkezeti konstrukció a tevékenységek összefűzésére, kapcsolatuk szerint:
 *** szekvencia, egymás után
 *** szelekció, választás: vagy ezt, vagy azt
-*** iterálunk, adott tevékenységet hajtjuk végre adott feltételszer/ig
+*** iterálunk, adott tevékenységet hajtjuk végre adott feltételszer/-ig
 ==== 00:07:45 ====
@@ 779. sor: / 786. sor: @@
 * <code> <![CDATA[”……”]]></code> CodeData, figyelmen kívül lesz hagyva
-== 9. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5417,Szoftvertechnologia_-_9._eloadas 9. előadás] ==
 Speci – formális leírás
@@ 894. sor: / 901. sor: @@
 ===== 38, Backus - Naur form BNF =====
-== 10. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5418,Szoftvertechnologia_-_10._eloadas 10. előadás] ==
 Specifikáció: formális leírás sw-re, mely kielégíti a követelményeinket. Funkcionális, szerkezeti, időbeli kép
@@ 928. sor: / 935. sor: @@
 ===== 41, Műveletek, 29p =====
 * Három kategória: Konstruktor, Modifier, Behavior
-* Konstruktor: minimális adathalmaz, szükséges ahhoz, hogy az összes lehetséges adatszerkezetet
+* '''Konstruktor''': minimális adathalmaz, szükséges ahhoz, hogy az összes lehetséges adatszerkezetet elő tudjam állítani. Van adatszerkezet-típusú visszatérési értéke és bővíti is a halmazt! Pl. stacknél: new(), push() → Új stack
-elő tudjam állítani. Pl (stacknél) : new, push → Új stack
+* '''Modifier'''/módosító: szintén új adatszerkezetet állít elő, de csak módosítja az adatszerkezetet, nélküle is tudunk létrehozni. Pl. stacknél: pop(), empty()
-* Modifier: módosító, szintén új adatszerkezetet állít elő, de csak módosítja az adatszerkezetet,
+* '''Behavior'''/viselkedés: adatszerkezet jellemzője az eredmény. Visszatérési értékei között nincs adatszerkezet-típus.
-nélküli is tudunk létrehozni. Pl.: pop, empty
+* Majd a Behaviort és Modifiert alkalmazzuk a konstruktoron.
-* Viselkedés: adatszerkezet jellemzője az eredmény
+** modifier(konstruktor)= ...
-* Majd a Behaviort és Mofidiert alkalmazzuk a konstruktoron.
+** behaviour(konstruktor)= ...
+* lásd még: [[Media:szofttech_algebrai_axiomak.pdf|Algebrai axiómák hasznos segédlet]]
 ==== 00:28:00 ====
@@ 982. sor: / 990. sor: @@
 ==== utolsó dia: Petri-hálóknál: Example: Reserve two resources =====
-== 11. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5419,Szoftvertechnologia_-_11._eloadas 11. előadás] ==
 === Specification / Specification, fejezetcímek - 2013: [http://directory.iit.bme.hu/belso/st/p13_6.pdf Part12 - p12_6.pdf], 12. dia ===
@@ 1 088. sor: / 1 096. sor: @@
    //Halmaz, vagyis 1 elem csak egyszer szerepelhet!
-== 12. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5420,Szoftvertechnologia_-_12._eloadas 12. előadás] ==
 ==== Feladatmegoldás ====
@@ 1 188. sor: / 1 196. sor: @@
 ===== Design / Basic Concepts, Modularity - Afferent, Efferent (2013: 13. dia) =====
-== 13. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5421,Szoftvertechnologia_-_13._eloadas 13. előadás] ==
 === 2013: [http://directory.iit.bme.hu/belso/st/p14_6.pdf Part14 - p14_6.pdf], Design / Basic Concepts ===
@@ 1 215. sor: / 1 223. sor: @@
 * Mérete
 * Kapcsolás ideje, mikor jön létre
-*
 * pl. 16perc
 * Mit kommunikálunk?
 ** Adat: leggyengébb, Ismerjük a paramétereket, primitív paraméterek (pl. int)
-** Stamp csatolás: Összetett adatot adunk át (pl. rekord, struktúra). Ugyanazt a szerkezetet kell
+** Stamp csatolás: Összetett adatot adunk át (pl. rekord, struktúra). Ugyanazt a szerkezetet kell ismerni a két félnek → függenek egy harmadiktól
-ismerni a két félnek → függenek egy harmadiktól
+** Kontrol: vezérlést adunk át, pl. EOF, a másik modul működését befolyásoljuk, vagyis kívülről vezéreljük
-** Kontrol: Vezérlést adunk át, pl. EOF, a másik modul működését befolyásoljuk, vagyis kívülről vezéreljül
 ** KözösAdatok: pl. globális adatok → kinek a kezében van?
 ** Tartalmi jellegű: Egyik programrészből (pl. modul) a másik programrész kódját adatkezelem.
@@ 1 227. sor: / 1 233. sor: @@
 ** Minél több adatot adunk át (paraméter), annál nagyobb valószínűséggel lesz baj.
 ** Legjobb: 1 paraméter.
--
 * Mikor jön létre
 ** Program írásakor
@@ 1 240. sor: / 1 245. sor: @@
 ===== 18-19, Kohézió: összetartó erő =====
 * Objektumok mennyire állnak közel egymáshoz? Milyen a kohézió?
-* '''Kohézív''', ha egyetlen egy funkciót valósít meg, pl. gyökvonás. Csak azért van ott leírva minden, mert szükséges az adott folyamathoz
+* '''Funkcionálisan kohézív''', ha egyetlen egy funkciót valósít meg, pl. gyökvonás. Csak azért van ott leírva minden, mert szükséges az adott folyamathoz
 * '''Szekvenciális''' kohézió: lazább, pl. GetValidInput: Vesz egy inputot, és megnézi, hogy érvényes-e.
 ** Gyengébb, hiszen két dolgot végez el. Nem jó, bontsuk inkább két részre.
@@ 1 278. sor: / 1 283. sor: @@
 ===== Design / Software Architectures - Architecture fogalmi meghatározása, ami köv. előadáson kerül megtárgyalásra =====
-== 14. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5422,Szoftvertechnologia_-_14._eloadas 14. előadás] ==
 === Design / Software Architectures - Architecture 2013: Software Architectures / Concepts - Architecture ("art and science of building; design or style of building(s) [Oxford dictionary, 1989]") - [http://directory.iit.bme.hu/belso/st/p15_6.pdf Part15_6 - p15_6.pdf], elejétől ===
@@ 1 329. sor: / 1 334. sor: @@
 ==== 00:18:54 ====
-===== 33, BlackBoard =====
-* pl. Adatbáziskezelő rendszerek
+==== 00:20:54 ====
-* Középen egy nagy adatbázis (oszlop-sorok)
+===== 33. BlackBoard =====
+* megfelel a hagyományos adatbáziskezelő rendszereknek
+* Középen egy nagy adatbázis (oszlop-sorok) (repository (shared data))
 * Hozzá csatlakoznak processzek
 * → Nagy közös adatszerkezetek, amin egymástól független processzek dolgoznak
 * Tranzakciók
+[[File:Szofttech_Vizsga_Software_Architectures_Patterns_Blackboard_(repository_(shared_data)).png|400px]]
+==== 00:22:34 ====
 * Előnye:
 ** Felelősségek nagyon jól el vannak különítve
@@ 1 340. sor: / 1 352. sor: @@
 ** Nehéz tesztelni, pl. átírok valamit a központi adatbázisban, megnézzük, a többi kis rész működik-e továbbra is…
 ** Nem épp hatékony, magas overhead, ráadásul gyorsan változik
-==== 00:20:54 ====
-===== 34, Interpreter, 30p körül =====
+==== 00:28:12 ====
+===== 34. Interpreter, 30p körül =====
 * Egy egyszerű kis virtuális gép (pl. állapotgép, tábla)
-* Fogom az Eventet, ez, és az aktuális állapot alapján becímzünk a táblába, a táblából kiolvasom az
+* Fogom az eventet, ez, és az aktuális állapot alapján becímzünk a táblába, a táblából kiolvasom az értéket, és átteszem a következő állapotra, parancskódra egy switch, majd megyek az elejére
-értéket, és átteszem a következő állapotra, parancskódra egy switch, majd megyek az elejére
+* Engine (maga a program), control state (aktuális állapot), pseudocode (lényegében az állapottábla), program state (adatelemek, amik kellenek a végrehajtáshoz, inputok)
-* Engine (maga a program), ControlState (aktuális állapot), PseudoCode (lényegében a tábla),
-ProgramState (Adatelemek, amik kellenek a végrehajtáshoz, inputok)
+[[File:Szofttech_Vizsga_Interpreter_architekturális_minta.png|400px]]
+==== 00:40:48 ====
-==== 00:22:34 ====
 ===== 35, ObjektumOrientált =====
 * Absztrakt adatszerkezetet implementálunk, amik (az osztályok) egymás metódusait hívják meg.
-==== 00:18:12 ====
+==== 00:43:02 ====
 ===== 36, Event Based, implicit invocation, 43p. =====
 * „Előfizetői” minta
-* Van egy eseményforrás, ahova beregisztrálnak azok az elemek, akik ezekben érdekeltek, és ha
+* Van egy eseményforrás, ahova beregisztrálnak azok az elemek, akik ezekben érdekeltek, és ha változik történik, értesülnek
-változik történik, értesülnek
 * Sok overhead és nehézség, de használjuk, pl. ablakkezelő
 * Előny: objektum interfész, sok event
@@ 1 364. sor: / 1 379. sor: @@
 ** Korrektség bizonyítása szinte reménytelen (kik kapták meg, milyen sorrendben → ezt igazolni)
-==== 00:40:48 ====
+==== 00:49:31 ====
 ===== 37, Layered, Rétegelt szerkezet =====
 * Vízszintesen, a hívások között definiál szinteket
@@ 1 372. sor: / 1 388. sor: @@
 * Hátrány: nem minden rendszernél használható, teljesítmény szempontjából probléma lehet a funkciók szétválasztása
-==== 00:43:02 ====
+[[File:Szofttech_Vizsga_Layered_architecture_pattern.png|400px]]
-==== 00:49:31 ====
 ==== 00:51:20 ====
 ==== 00:53:00 ====
-==== 00:54:14 ====
-==== 00:55:11 ====
-==== 00:55:33 ====
 ===== 38-44, Kliens-Szerver, 54p =====
 * Ált. 3 réteg:
@@ 1 386. sor: / 1 400. sor: @@
 * Sokszor 2 fizikai rétegen helyezzük el.
-==== EA14/00:59:13 == EA15/00:00:40 ====
+[[File:Szofttech_Vizsga_Software_Architectures_Patterns_Client-server_logical_tiers.png|400px]]
+==== 00:54:14 ====
+==== 00:55:11 ====
+==== 00:55:33 ====
+==== 00:59:12 (EA14/00:59:12 == EA15/00:00:40) ====
 ===== 45, SOA: Service Oriented Architecture =====
 * pl. Argep.hu, brókerek (kigyűjti az infókat, és ajánlatot mutat)
@@ 1 392. sor: / 1 413. sor: @@
 * WSDL: Webes szolgáltatások leírása
 * SOAP: XML-es kommunikáció web szolgáltatások eléréséhez
-* UDDI: „yellowpages”, szakmák szerint milyen szolgáltatások hol vannak
+* UDDI: „yellow pages”, szakmák szerint milyen szolgáltatások hol vannak
+[[File:Szofttech_Vizsga_Software_Architectures_Patterns_SOA.png|400px]]
+* UDDI (Universal Description, Discovery and Integration)
+** enables discovery of WSDL
+** is accessed using SOAP
+* WSDL ([http://www.w3.org/TR/wsdl Web Services Description Language])
+** describes WS
+** binds to SOAP
+* SOAP ([http://www.w3.org/TR/soap/ Simple Object Access Protocol])
+** enables communication between WS
+* WS (Web Services)
 ==== EA14/01:07:05 == EA15/00:02:03 ====
@@ 1 405. sor: / 1 438. sor: @@
 ===== 47, =====
 * SOAP: Simple Object Access Protocol
-** Üzenetformátum, RPC-t takar el (RemotePr…C, távoli eljáráshívás)
+** Üzenetformátum, RPC-t takar el (Remote Procedure Call, távoli eljáráshívás)
 ** Különböző Node-okat definiál
 *** Sender: küld egy üzenetet
 *** Receiver: vesz
 *** Intermediary: közbenső elem
-** Header,Body → Strukturúlt
+** Header, Body → Strukturált
 * UDDI: UniversalDescription, Discovery and Integration 1:12p
-** Aranyoldalak szerű könyv
+** Aranyoldalak-szerű könyv
 ** Előfizethető
-==== EA14/01:12:58 == EA15/00:03:46 ====
+==== 01:12:58 (EA14/01:12:58 == EA15/00:03:46) ====
 ===== 48, SOE, Service Oriented Enterprise: Szolgáltatásmérnökség (2013: 24. dia) =====
 * Szolgáltatási rendszer
@@ 1 422. sor: / 1 455. sor: @@
 * Folyamatok
-== 15. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5423,Szoftvertechnologia_-_15._eloadas 15. előadás] ==
 === Software architecture, 2013: [http://directory.iit.bme.hu/belso/st/p15_6.pdf Part15 - p15_6.pdf] ===
 ===== 2013: 21. dia, SOA - Service Oriented Architecture =====
+===== SOE – Service Oriented Enterprise =====
-* BPEL: Üzleti folyamat leíró nyelv
+* BPEL (Business Process Execution Language): Üzleti folyamat leíró nyelv
 ** Dokumentum flow jelleg, mikor-milyen lépések (amik esetleg újabb szolgáltatások igénybevételét jelentik), melyek mögött emberi tevékenység járhat
 * Végrehejtásra két mód:
-** Orchestration: zenekar vezénylése, egy process ami leírja a folyamatot, tartozik hozzá egy végrehajtógép, ami a process elemeit végrehajtja
+** '''Orchestration''': zenekar vezénylése, egy process ami leírja a folyamatot, tartozik hozzá egy végrehajtógép, ami a process elemeit végrehajtja (''orkesztráció (orchestration) – 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: ha elkezdődik a folyamat (pl. érkezik megrendelés), továbbítjuk az első állomásra, ahol az előírt tevékenységet végrehajtják. Majd, hogy hova kell továbbküldeni (szolgáltatást kérni), azt tudja az első állomás.
+** '''Choreography''': ha elkezdődik a folyamat (pl. érkezik megrendelés), továbbítjuk az első állomásra, ahol az előírt tevékenységet végrehajtják. Majd, hogy hova kell továbbküldeni (szolgáltatást kérni), azt tudja az első állomás.
-Nincs központi rész
+Nincs központi rész (''koreográfia (choreography) – 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.'')
 * BPEL4WS: BPEL web service-ekhez.
 * WS-*: WebService Szabványok, ajánlások
@@ 1 442. sor: / 1 476. sor: @@
 * WS-Coord: Hosszú távú tranzakcióknál használatos
-=== 7. diasor, JSD, Jackson State Development ===
+[[File:Szofttech_Vizsga_Software_Architectures_Patterns_SOE.png|400px]]
 ==== 00:15:56 - 00:22:36 ====
 * elektronikus közigazgatás, stb.-ről magyarázat, aztán Software Architectures / Document részt átugrottuk
-=== váltás, JSD / Content (Jackson System Development) (Introduction, Case study, Steps in details) (2013: ??) ===
+=== váltás, 7. diasor: JSD / Content (Jackson System Development) (Introduction, Case study, Steps in details) (2013: ??) ===
 ==== 00:22:36 ====
 ==== 00:22:55 ====
@@ 1 470. sor: / 1 504. sor: @@
 ==== 00:44:14 ====
-===== 8, JSD Lépések =====
+===== 8. JSD: lépések =====
-* Modelleket készítünk:
-** Entity Action Step: Kik az entitások, az alapanyagok, ezekkel mi történik
+* 6 lépés van (1. Entity action step, 2. Entity structure step, 3. Initial model step, 4. Function step, 5. System timing step, 6. Implementation step), ezek szétbonthatók 3 fő lépésre (Model step, Network step, Implementation step) (ld. 44:36)
-** Entity Structure Step: Entitáshoz hozzá kapcsoljuk azokat az eseményeket, amik vele történnek, és ezen akciókat időben rendezzük is
-* Network Step: Processek hálója
+# Model step: modelleket készítünk
-** Initial Model Step: Entitások történetéből megalkotjuk a processt, számítástechnikai modell
+## Entity action step: Kik az entitások, az alapanyagok, ezekkel mi történik, az ő életét mik változtatják meg, milyen akciók történnek
-** Function Step: Ha megvannak a modellek, akkor azokra kell tenni funkciókat
+## Entity structure step: entitáshoz hozzákapcsoljuk azokat az eseményeket, akciókat, amik vele történnek, és ezen akciókat még időben rendezzük is, tehát sorrendet fogjuk megadni (közös események is lesznek)
-* Implementation Step:
+# Network Step: processek hálója, összefüggő processek hálózata jön létre (egyik process üzenget a másiknak, egyik process olvasgat a másikból, stb.)
-** System Timing Step: Időzítések, milyen ütemezést készítünk.
+## Initial model step: előző lépésben összegeztük az eseményeket, ha szimulációt akarunk készíteni, akkor az entitásokon értelmezett események feldolgozására létrehozunk egy modellt; ekkor entitások történetéből megalkotjuk a processt, számítástechnikai modell. Elkészítjük a modellező processt.
-** Implement. Step: Implementáció elkészítése
+## Function step: ha megvannak a modellek, amik szimulálják a világot, akkor azokra kell tenni funkciókat (mivel végül is ezért csináltuk az egész modellezést, hogy legyenek funkciók) (lásd csónakázós példa, funkció: számolja ki, mennyi volt a napi leghosszabb csónakázást, vagy mennyi volt az átlagos csónakázás, stb.)
+# Implementation Step: ha megvan az összetett processhálónk, akkor azt implementálni is kell
+## System timing step: megmondjuk az időzítéseket, ezek alapján fogjuk az ütemezést elkészíteni: a processeket a meghatározás után valahogy ütemeztetni kell.
+## Implementation step: implementáció elkészítése.
 ==== 00:49:16 ====
@@ 1 576. sor: / 1 613. sor: @@
 ===== JSD / Steps in details (Step 6: Implementation step), 29. dia (2013: ??) (köv. előadáson még ezt folytatja) =====
-== 16. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5424,Szoftvertechnologia_-_16._eloadas 16. előadás] ==
 === 2013: [http://directory.iit.bme.hu/belso/st/p1_6.pdf Part1 - p1_6.pdf], 7. dia: Introduction / Course information (Assessment, homework...) ===
@@ 1 619. sor: / 1 656. sor: @@
 * Absztrakt adatszerkezetek: Adat absztrakció és Procedurális interfész
 * Problémák
-** Vagy név probléma, vagy kód láthatósági probléma (35p körül)
+** Vagy névprobléma, vagy kódláthatósági probléma (35p körül)
 ** Hiányoznak a generikus struktúrák
 ** InFix operációk: a+b vagy +(a,b) (→ utóbbi a prefix)
 *** Vagyis Infix fenn van tartva meghatározott típusokra
 * Paradigma: nézetrendszer
-** Gondolkodásmód beli váltás
+** Gondolkodásmódbeli váltás
-** Az alpvető konstrukció, amire építkezünk azok az objektumok
+** Az alapvető konstrukció, amire építkezünk, azok az objektumok
 ** Objektumok vannak, amik együttműködnek egymással
-** Ennek a kialakítására OO módszertan
+** Ennek a kialakítására: OO módszertan
-** Objektumok (kb.: entitás),
+** Objektumok (kb.: entitás)
 ==== 00:44:08 ====
@@ 1 677. sor: / 1 714. sor: @@
 futárok, (→ ezek objektumok)
 * Típus: azon objektumtípusok, melyek kielégítik az interfészt
-* Kielégíti a Liskov féle helyettesítési elvet: ha az A interfész B-ből származik, akkor egy olyan
+* Kielégíti a Liskov féle helyettesítési elvet: ha az A interfész B-ből származik, akkor egy olyan objektum, ami támogatja A interfészt, akkor azt bárhol lehet használni olyan helyen, ahol B-nek van deklarálva. Vagyis: B szupertípus, A származtatott típus. A kompatibilis B. A az egy B. Pl. 18. dia
-objektum, ami támogatja A interfészt, akkor azt bárhol lehet használni olyan helyen, ahol B-nek
-van deklarálva. Vagyis: B szupertípus, A származtatott típus. A kompatibilis B. A az egy B. Pl. 18. dia
 ==== 01:08:35 ====
@@ 1 687. sor: / 1 722. sor: @@
 szolgáltatáskéréssel elérhető (vagyis egy szolgáltatás meghív egy operációt)
 ** Általános szignatúrása:
-oneway (!= void), Visszatérési érték , Identifier (neve, pl. SetX), Paraméterek (5, 6, stb),
+oneway (!= void), Visszatérési érték, Identifier (neve, pl. SetX), Paraméterek (5, 6, stb),
 Exception (milyen kivételt dobhat), Contexek
@@ 1 725. sor: / 1 760. sor: @@
 ===== OO Concepts /  Obj. Implementation - The Construction Model =====
-== 17. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5425,Szoftvertechnologia_-_17._eloadas 17. előadás] ==
 elején: részletek a HF-ről
@@ 1 845. sor: / 1 880. sor: @@
 ==== EA17/01:23:47 == EA18/00:01:00 ====
-== 18. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5426,Szoftvertechnologia_-_18._eloadas 18. előadás] ==
 === folyt. 2013: [http://directory.iit.bme.hu/belso/st/p4_6.pdf Part4_6 - p4_6.pdf], 6. diától ===
@@ 2 003. sor: / 2 038. sor: @@
 ===== utolsó dia: UML / Class Diagram - AssociationEnd =====
-== 19. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5427,Szoftvertechnologia_-_19._eloadas 19. előadás] ==
 === UML / Class Diagram - Association (Name, Property string, stb. ismétlés...; Multiplicity, Name, Navigability ismétlés...), mai óra anyaga: AssociationEnd - Visibility, Ownership, 2013: [http://directory.iit.bme.hu/belso/st/p4_6.pdf Part4 - p4_6.pdf], 35. dia ===
@@ 2 080. sor: / 2 115. sor: @@
 * Ha az interfész attribútumokat deklarál, abból még nem következik, hogy azok attribútumként lesznek elérhetők (hanem pl. műveleteken keresztül)
 * Példák 29p.
-** UML 1.? Szaggatott vonal, nagy (üres) nyíllíl: interfész implementálása
+** UML 1: Szaggatott vonal, nagy (üres) nyíllal: interfész implementálása
-** UML 2: Szaggatott vonal, normál nyíl, ráírva, hogy „realize”
+*** http://i.imgur.com/0LfMGKt.png
+** UML 2: Szaggatott vonal, normál nyíl, ráírva, hogy <code>«realize»</code>
 *** A régi használatát várják el
 ** Nyalóka: vonal, végén karika: ugyanaz, mint ez előzők
 *** Elvárt interfész: Mit várok el; Miközben szolgáltatást végzek kell valaki, aki egy interfészt megvalósít. Jel: Nyalóka, túloldalon félkörrel bevonva
+http://i.imgur.com/oQtZpSM.png
 ==== 00:34:46 ====
@@ 2 141. sor: / 2 179. sor: @@
 * D add(b:B) függvénye meghívhatja egy maraméterül kapott E count () metódusát, mert E megvalósítja az A interfészt: B-t kérünk paraméternek, fogalmunk sincs, hogy E micsoda: -+
 * E meghívhatja egy D add() metódusát, mert van közös ősük: ++-
-* E nem hívhatja meg egy D bar() metódusát, mert a metódus protected: D-nek nincs bar()
+* E nem hívhatja meg egy D bar() metódusát, mert a metódus protected: D-nek nincs bar() metódusa (B-nek van, de private): +-
-metódusa (B-nek van, de private): +-
 * F meghívhatja egy D add(b:B) metódusát, mert E egygszerre a B és C osztály leszármazottja: -+
-* D add(b:B) metódusából nem hívhatjuk meg D do() metósudát, mert a metódus absztrakt:
+* D add(b:B) metódusából nem hívhatjuk meg D do() metósudát, mert a metódus absztrakt: nem absztrakt a metódus, hanem static, így meghívhatjuk: --
-nem absztrakt a metódus, hanem static, így meghathatjuk: --
-== 20.előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5428,Szoftvertechnologia_-_20._eloadas 20. előadás] ==
 === 2013: [http://directory.iit.bme.hu/belso/st/p5-p-hu-ex.pdf Gyak5 - p5-p-hu-ex.pdf] ===
@@ 2 282. sor: / 2 318. sor: @@
 * Use Case Diagram
-== 21. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5429,Szoftvertechnologia_-_21._eloadas 21. előadás] ==
 === Interaction Diagram, 2013: [http://directory.iit.bme.hu/belso/st/p6_6.pdf Part6 - p6_6.pdf] ===
@@ 2 409. sor: / 2 445. sor: @@
 * Ha valami olyasmiről van szó, ami a továbbiakban is részt vesz valamilyen műveletben (pl. beutaló, recept), akkor tüntessük fel
-== 22. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5430,Szoftvertechnologia_-_22._eloadas 22. előadás] ==
 === [http://directory.iit.bme.hu/belso/st/p6_6.pdf Part6 - p6_6.pdf] ===
@@ 2 507. sor: / 2 543. sor: @@
 * Get és Remove nem a változónak megy, hanem a Kollekciónak!
-== 23. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5431,Szoftvertechnologia_-_23._eloadas 23. előadás] ==
 === Feladatok - 2013: [http://directory.iit.bme.hu/belso/st/p7-p-hu-ex.pdf Gyak7 - p7-p-hu-ex.pdf] ===
@@ 2 677. sor: / 2 713. sor: @@
 ** Ki van kívül és ki van belül
-== 24. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5432,Szoftvertechnologia_-_24._eloadas 24. előadás] ==
 === folyt. 10.diasor; 2013: [http://directory.iit.bme.hu/belso/st/p16_6.pdf Part16 - p16_6.pdf] ===
@@ 2 849. sor: / 2 885. sor: @@
 ===== RUP vége, RUP / Implementation (Design Algorithms, ...) =====
-== 25. Előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5433,Szoftvertechnologia_-_25._eloadas 25. előadás] ==
 === 11. diasor, Verifikáció, validáció; 2013: [http://directory.iit.bme.hu/belso/st/p9_6.pdf Part9 - p9_6.pdf] ===
@@ 2 915. sor: / 2 951. sor: @@
 ==== 00:24:10 ====
 ===== 12, Testing, tesztelés – működés közben vizsgáljuk a programot =====
-* Konformancia vezérelt tesztelés: előírásoknak meg kell, hogy feleljen, a tesztekkel ezt igazolom
+* Szoftvertesztelésben két megközelítés:
-* Hibadetektálás: pl. lefagy a program, mert hibásan lett felvéve változó, mert valaki rosszul értelmezte a feladatot → hibasorrend
+** Konformancia-vezérelt tesztelés: a szoftverünk valamilyen szabályoknak, előírásoknak meg kell, hogy feleljen, a tesztekkel az a célom, hogy ezt a megfelelőséget igazoljam (pozitív éle van)
-** error: valamilyen '''emberi''' tevékenység hiánya, tévedés
+** Hibadetektálás: a szoftvertesztelés nem más, mint a szoftver futtatása hibakeresés céljából (negatív éle van). Pl. lefagy a program, mert hibásan lett felvéve változó, mert valaki rosszul értelmezte a feladatot → hibasorrend. Hibákra definíciók (nincs egységes terminológia egyébként):
-** fault (bug): nem az van a '''kódban''', aminek lennie kéne, kódhiba (debuggolás)
+*** '''error''': valamilyen '''emberi''' tevékenység, annak hiánya, tévedés, elhanyagolás; emberhez köthető, valamit elront, és így ebből keletkezik egy bug
-** failure: kívülről '''látható''' (pl. lefagy, rossz eredményt ad), jelenség
+*** '''fault (bug)''': a program kódjában keletkezik egy hiba; nem az van a '''kódban''', aminek lennie kéne, vagy épp kihagytam valamit belőle; tehát '''kódbeli hiba''' (debuggolás során ezeket akarjuk megtalálni benne) (pl. ilyenek, mint hogy egy <code>*</code>-ot lehagytunk valahonnan, egy változó rossz értéket kapott, <code>==</code> helyett <code>=</code> áll a kifejezésben, stb.), ez pedig egy failure-t okoz
+*** '''failure''': amit kívülről '''láthatunk''' (pl. lefagy a szoftver, rossz eredményt ad), '''jelenség, amiben testet ölt a hiba'''; én ezekkel a hibákkal szembesülök, ehhez a failure-höz kell nekem majd megtalálnom a bugot, hogy a kódban ez mi miatt történt, vagy továbbmehetek, és rájöhetek, hogy tévedés történt, tehát error (pl. specifikációt félreértette, vagy hasonló), így deríthetem ki a hibát
 ==== 00:29:08 ====
@@ 3 031. sor: / 3 068. sor: @@
 * Teljesítményriportok
-== 26. előadás ==
+== [http://bme.videotorium.hu/hu/recordings/details/5434,Szoftvertechnologia_-_26._eloadas 26. előadás] ==
 === folyt. [http://directory.iit.bme.hu/belso/st/p9_6.pdf Part9 - p9_6.pdf] ===
@@ 3 298. sor: / 3 335. sor: @@
 (ennek kapcsán visszatérve az előző Mari nénis példához, a postahivatal és levél között kéne megszüntetni a kapcsolatot, vagy pedig összekötjük a postaládát és levelet, és akkor hosszú távon tárolhatjuk benne, megmarad, bár nem hívunk rajta semmit sem a postás, sem a postaláda...)
+== [http://bme.videotorium.hu/hu/recordings/details/5847,Szoftvertechnologia_Java_gyakorlat_-_1._eloadas Java 1. előadás] - TODO!! ==
+== [http://bme.videotorium.hu/hu/recordings/details/5848,Szoftvertechnologia_Java_gyakorlat_-_2._eloadas Java 2. előadás] - TODO!! ==
+== [http://bme.videotorium.hu/hu/recordings/details/5849,Szoftvertechnologia_Java_gyakorlat_-_3._eloadas Java 3. előadás] - TODO!! ==
+== [http://bme.videotorium.hu/hu/recordings/details/5850,Szoftvertechnologia_Java_gyakorlat_-_4._eloadas Java 4. előadás] - TODO!! ==
+{{RightTOC}}
-{{RightTOC}}
+[[Kategória:Infoalap]]

„Szoftvertechnológia - Videójegyzet” változatai közötti eltérés