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

** 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

** Tevékenységek leírása strukturált angol nyelvvel + szerkezeti konstrukció a tevékenységek összefűzésére, kapcsolatuk szerint:

*** iterálunk, adott tevékenységet hajtjuk végre adott feltételszer/-ig

** 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

** 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

* '''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

 

===== 33. BlackBoard =====

* megfelel a hagyományos adatbáziskezelő rendszereknek

* Középen egy nagy adatbázis (oszlop-sorok) (repository (shared data))

 

==== 00:28:12 ====

 

===== 34. Interpreter, 30p körül =====

* 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

* 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)

 

 

==== 00:43:02 ====

 

* Van egy eseményforrás, ahova beregisztrálnak azok az elemek, akik ezekben érdekeltek, és ha változik történik, értesülnek

==== 00:49:31 ====

 

[[File:Szofttech_Vizsga_Layered_architecture_pattern.png|400px]]

 

 

 

==== 00:55:33 ====

 

==== 00:59:12 (EA14/00:59:12 == EA15/00:00:40) ====

* UDDI: „yellow pages”, szakmák szerint milyen szolgáltatások hol vannak

 

 

** Üzenetformátum, RPC-t takar el (Remote Procedure Call, távoli eljáráshívás)

** Header, Body → Strukturált

** Aranyoldalak-szerű könyv

==== 01:12:58 (EA14/01:12:58 == EA15/00:03:46) ====

* BPEL (Business Process Execution Language): Üzleti folyamat leíró nyelv

** '''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.

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.'')

[[File:Szofttech_Vizsga_Software_Architectures_Patterns_SOE.png|400px]]

=== váltás, 7. diasor: JSD / Content (Jackson System Development) (Introduction, Case study, Steps in details) (2013: ??) ===

===== 8. JSD: lépések =====

 

* 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)

 

# Model step: modelleket készítünk

## 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

## 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)

# 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.)

## 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.

## 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.

* 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

oneway (!= void), Visszatérési érték, Identifier (neve, pl. SetX), Paraméterek (5, 6, stb),

** UML 1: Szaggatott vonal, nagy (üres) nyíllal: interfész implementálása

** UML 2: Szaggatott vonal, normál nyíl, ráírva, hogy <code>«realize»</code>

** 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)

** 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):

*** '''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

*** '''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