1 Informatikai Rendszerek Tervezése 11. Előadás: Döntéscentrikus rendszertervezés. 2 Extreme programming Illyés László Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

2 Az előadás nagy részben ezen a 2 cikken alapszik •Mark Norton, "Decisioning: A New Approach to Systems Development (Part 1)," Business Rules Journal, Vol. 8, No. 1 (Jan. 2007), URL: •Mark Norton, "Decisioning: A New Approach to Systems Development (Part 2)," Business Rules Journal, Vol. 8, No. 1 (Jan. 2007), URL: • Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

3 Decisioning: szisztematikus felfedezése, definíciója és menedzsmentje a döntéseknek a döntések automatizmusa céljából. Követelmény-analízis szempontok: Egy üzleti érték akkor keletkezik, amikor egy felismerhető üzleti objektum állapota megváltozik Ez fókuszál a magra: mivel kereskedünk, mit menedzselünk, mit hasznosítunk, mit használunk, építünk vagy adunk el, hogy elérjük az üzleti céljainkat. Üzleti objektumok változása: döntés eredménye amely a folyamatban aktivizálódik és NEM a folyamat (processz) eredménye. Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

4 •Az előzőekben letárgyaltuk a Mit és Hogyan-t: az üzleti objektumot, amelynek állapotai vannak és a döntési folyamatot, amelyik az állapováltozásokért felelős. •Mikor: Az esemény természete, amely serkenti az állapotváltozást-”Másképp fogom fogadni a pácienset vészhelyzetben és másképp normál helyzetben?” •Hol: Van valamilyen törvénykezési vagy helyi alapismeret, ami az állapotváltoztatást befolyásolya-”Elfogadom ezt az üzletet, ha egy háborús környezetben zajlik?” •Kicsoda: Ki követi el az állapotváltozást-“Egy közvetítő által végzett ügylet más elbírálás alá esik, mint egy belső tranzakció?” •Miért: Miért fontos ez az állapotváltozás az üzletben—főképpen hogyan teremt értéket? Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

5 Decisioning és termék-mérnökség A decisioningnek direkt és stratégiai fontossága van az üzletben. A decisioning az üzlet magját képező objektumokra összpontosít (mivel kereskedünk, menedzselünk, milyen tőkét mozgatunk, mit használunk, építünk vagy adunk el azért, hogy elérjük az üzleti céljainkat). Ezen objektumoknak egy közönséges kifejezést adhatunk: termékek. A decisioning nem csak támogatja az üzleti termékeket; jobban, mint más fogalmak, meghatározza a termékek anatómiáját. Decisioning a nem-fogyasztói termékeknek az elsődleges megkülönböztetője.

6 Egy modell a paraméterezhető termékekre "Product Configurators: New Tech for Insurance Marketplace" [Gartner, 29 November 2001, Kimberly Harris]. (Termék- konfigurálók) Léteznek, de kevés összpontosít az üzleti szabályok (business rules) integrációjára, egyik sem teszi a decisioning paradigmát a termék-konfiguráló központi tervezési-modellezési irányítójává. Hogy kiemelhessük a ‘konfigurálható terméket’, az nem tartalmazhatja az ügyfelet, értékesítési csatornát, könyvelést vagy más, üzlettől függő fogalmat. Ezek az infrastruktúra elemei. Összesítve: azt mondhatjuk, hogy a termék-mérnökség és támogatás az elsődleges gyújtópontja minden üzletnek és a tőle függő entitások és rendszer-infrastruktúrák ezen elvek szerinti vezérlését igényli.

7 Az üzleti infrastruktúra, mint egy gazda-szervezete a konfigurálható terméknek.

8 Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE) (8/) A konfigurálható termék a háttérben levő technikai infrastruktúrába ágyazva.

9 A konfigurálható termék-megoldás elemei. A konfigurálható termék-megoldás teljesen bezárt terméket kell szolgáltasson, ami vonatkozik a termék-specifikus információra, decisioningra, folyamatra és dokumentációra egyaránt. Kritikus tényező az, hogy a külső infrastruktúra ne függjön a termék belső változóitól. Az a tény hogy a rendszer nem termék-függő, lehetővé teszi, hogy a terméket megjeleníthessük anélkül, hogy valamilyen kódozási követelmény érvényesüljön. A rendszer úgy működik, mint egy termék-motor. A következő topikok azon elemei a terméknek, amelyek a konfigurálható termék definícióban a belső megvalósítás részei kell legyenek.

10 Termék-adatok Azon adatokra, amelyek kizárólag a termék meghatározásaként léteznek úgy fogunk hivatkozni, hogy: faktorok. Termék-faktorok magukba foglalják mindazon faktorokat, amelyek a termék- követelményben szükségesek, kivéve a külsőleg menedzselt adatokat. Például, különbséget kell tennünk egy ügyfél születési dátuma és egy sofőr születési dátuma között egy autó-biztosítási kötvényben. Csak a második FAKTOR. Az ügyfélről szóló adatok nem termék- függőek és a külső környezet szolgáltatja minden termék esetében. A sofőr születési dátuma elérhető kell legyen a konfigurálható termék felépítési folyamatban, a konfigurálható termék definíciójának határain belül.

11 A faktorokat al-csoportokra oszthatjuk. Ezen alcsoportok sokszor a termelési ciklus különböző fázisaiba vannak belefoglalva: •Információk, melyek leírják a termék instanciát •Információk, amelyek megmutatják a vevő választási lehetőségeit és preferenciáit a termék instancia szempontjából •Adatok, amelyek kimenetei a termék meghatározás döntési folyamatainak (származtatott adatok) A termék-faktorokat interaktív módon kell bemutatni a felhasználónak. Ez dinamikus és általános alkalmazási program interfészt igényel– felhasználói felület, amely bemutatja a FAKTORokat, mintsem explicit módon megfogalmazott attribútumokat.

12 Állapotok Kijelentettük, hogy érték akkor keletkezik, amikor a termék- instancia állapota megváltozik Minden állapotot világosan azonosítani kell és különállóan menedzselni. A biztosítási példában az állapot-változások magukba foglalják: •Árajánlat-tételt •Javaslattétel – a biztosítási kérést átalakítja javaslattétellé •Kötvény – a javaslattételt átalakítja kötvénnyé •Jóváhagyás – újrafuttatjuk a kötvény decisioning-ját potenciális új bemenő változókkal •Megújítás – újrafuttatjuk a kötvény változókat potenciálisan új decisioninggel •Érvénytelenítés Léteznie kell egy pár elemnek a munkafolyamati menedzsmentben, amelyik megfelel egy, a felhasználó által tett, állapot-változás kérelemnek a megfelelő döntési modell számára, amelyik végrehajtja és irányítja az állapot-változást.

13 •Szerződési dokumentumok Minden állapot-változás esetén egy vagy több dokumentum szükséges a változás tanusítására. A dokumentum felépítése egy döntés-vezette aktivitás, amelyik szelektív járuléka egy előre- megformázott dokumentum átalakítása egy vagy több kimeneti dokumentumba. A dokumentum kell tükrözze a dinamikusan definiált adatokat. •Könyvvitel A könyvviteli és portfóliós effektusait az állapot-változásoknak leválaszthatjuk standardizált formában és előterjeszthetjük a portfólió menedzsment- vagy könyvviteli rendszernek. Ez sokszor egy hagyományos rendszer. A termék ezen aspektusát könnyen megvalósíthatjuk, ha megvan a standard könyvelési ‘üzleti osztály’ változónk.

14 •Koncepció megvalósítása Hogyan működik •Azonosítottunk egy halom komponenst, amelyik szükséges ahhoz, hogy megvalósításra kerüljön a konfigurálható termék elve, léteznek megvalósítások is. •A termék-szerver, amelyik beágyazza és végrehajtja a konfigurációs termék definíciót (a termék-proxy) •A munkafolyamat minta, amely társítja az összes következő elemet egy specifikus termék-állapotváltozási kéréshez. •XML séma a következőkre: –Az adatok, amiket szolgáltatni kell a kiszolgálónak a decisioning támogatásra –A termék-specifikus adatokat, amelyek rögzítésre kerülnek vagy létrehozza a konfigurációs termék folyamat –Kimenetek, amelyeket visszakap a kiszolgáló a feltöltés végett.

15 •Űrlapok, a megjelenítésre és adatbeolvasásra az ügyféltől/hez. •Szerződés űrlapok a termelés vagy szerződési dokumentációhoz. •Decisioning a következőkre: –Vezérelni az állapot-változásokat –Ellenőrizni a munkafolyamatot –Konfigurálni az űrlapot –Összeállítani a szerződés-dokumentumot Ezen komponenseket integrálhatjuk egy alkalmazásba, amelyre úgy hivatkozunk, mint termék szerver. Minden csatlakozó, amely a termék szerverben és a termék szerver irányában valósul meg, XML-ben definiálandó. A termék szerver ezután elérhető egy egyszerű lekérdezési felületen keresztül, és beágyazható egy lazán csatolt, önálló alkalmazásba- egy termék ‘fekete dobozba’.

16 •Űrlapok Az űrlapok fontos elemei a konfigurálható terméknek. A konfigurálható termék megoldás feltételezi, hogy az adatok összeszedése automatikus, ha már meg van határozva. A böngésző ereje, mint felhasználói felület lehetővé teszi, hogy létrehozzunk sok, lehetséges megjelenítést dinamikusan és gyorsan. A képkocka és a stíluslapok használata lehetővé teszi a gazda környezetet, hogy függetlenül menedzselje az általános képernyő megjelenítést pontosan úgy, ahogyan a termék szerver generálja a tartalmat. Egypár lehetséges megközelítése lehetséges, hogy valóra váltsuk a dinamikus űrlapokat, beleértve az XSD-megközelítést megvalósító az Xformok által. Egy még deklaratívabb tervet lehet megvalósítani, ha meta-adatokat rendelünk hozzá a termék faktorokhoz, amelyek vezérlik a felhasználói interfész komponenst. Ebben a megközelítésben, dinamikus HTML lesz generálva a meta-adatokkal összhangban, ahol a faktorok úgy vannak hordozva, mint ismeretlen tartalom. Ezen az úton, generikus prezentációs kód lesz megírva egyszer, amelyik nem függ semmiféle explicit faktortól. A generált űrlap képes lesz tálalni és begyűjteni az adatokat, mivel a meta-dokumentumok valók arra, hogy leírják a faktorokat.

17 •dokumentum-generátor A dokumentum generátor egy előre megszerkesztett szöveg komponensekből álló könyvtárat tartalmaz, amelyik összeáll a döntések vezérlésével, hogy tükrözze alapját képező termék szerződést (ahogy XML formátumban definiálva van). A változók behelyettesítésével és formázó mintával, megbízható üzletileg skálázott dokumentumokat lehet készíteni a termék szerveren belül, emberi beavatkozás nélkül. •A termék konfigurátor Egy új eszköz– a “termék konfigurátor”—szükséges hogy menedzselni lehessen a meta-adat definíciókat és a termék telepítését. Az üzleti szabályokat, amelyek vezetik a termék definíciókat be lehet ágyazni ebbe az alkalmazásba, használva esetleg még nagyobb szintű meta adatokat.

18 •Ez az alkalmazás nagyon szűken összpontosít. A használata nem igényel semmiféle tradícionális IT jártasságot (platform tudást, programozást, adatbázisokat, stb.) •A rálátása a világra korlátozva van azon adatok által, amelyek egyeznek és meg vannak határozva a kiszolgáló rendszer csatlakozóin keresztül (pl. ügyfél) és egy faktor halmazzal, amelyeket a termékre önmagára határozott meg a termék tulajdonosa. •Ez a korlátozott “világra látás” utána meg van erősítve a termék tulajdonosa által szolgáltatott döntési modellel. Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

19 Extreme Programming (XP) egy akaratlagos tudományos megközelítése a szoftver tervezésnek. Körülbelül 13 éve terjedt el de sok, különböző méretű vállalatnál bevált. XP sikeres, mivel kikényszeríti az ügyfél megelégedettségét. A metodológia arra van kitalálva, hogy az ügyfélnek akkor szolgáltasson szoftvert, amikor neki szüksége van arra. Az XP felhatalmazza a fejlesztőt, hogy a felhasználónak a követelményei változására válaszoljon, bármikor a termék életciklusa közben. Ez a metodológia előtérbe helyezi a csapatmunkát. Menedzserek, vásárlók és fejlesztők mind részesei a szoftverfejlesztési minőség megteremtésének. XP implementál egy egyszerű, de hatékony utat a csoportos stílusú fejlesztéshez. (groupware) Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE) EXTREME PROGRAMMING

20 Az XP 4 elemi módon javítja fel a szoftver projektet; kommunikáció, egyszerűség, visszacsatolás (feedback) és bátorság. Az XP programozók kommunikálnak az ügyfelekkel és a társ programozókkal. Ők a tervezést egyszerűen és tisztán végezik. Megkapják a visszajelzést, mivel a szoftver tesztelése az első napon kezdődik. Ők a felhasználónak a leghamarabbi állapotában szállítják a rendszert és a változtatások kivitelezését a javaslattal egyidőben végzik. Ezzel az alapokkal, az XP programozók válaszolni tudnak a változó követelményeknek és technológiának. Az XP különböző. Nem olyan, mint egy puzzle, aminek megvan minden darabja és kirakható. Kis darabokból áll össze. Önmagában a daraboknak nincsen saját értelmük, de amikor összerakjuk egy teljes kép áll össze. Ez a jelentős különbség, amely megkülönbözteti a tradicionális szoftver fejlesztési módszerektől. Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

21 •Tervezés •Felhasználói történetek íródnak •A végleges változat kibocsátási terve adja meg a határidőket. •Sok kis kibocsátást csinálnak. •A program sebessége mérve van •A projektet felosztják iterációkra •Iterációs tervezés előzi meg minden iterációt •Emberek járják körbe •Egy álló-gyűlés kezdődik minden nap •Leszögezzük a folyamatot, amikor megáll Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

22 Szerkesztés •Egyszerűség •Választunk rendszer-metafórát •CRC kártyákat használunk tervezési szakaszonként (class, responsibilities, collaborators) •Tüske megoldásokat csinálnak a kockázat csökkentése érdekében •Semmilyen funkcionalitás nincs hozzáadva túl korán •Refraktálás, akárhányszor, bármikor Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

23 Kódolás •Az ügyfél mindíg elérhető •A kódot megegyezéses standard formában írják •Kódoljuk az egységes tesztet először •Minden termelt kód párosan programált •Csak egy pár integrálja a kódot egy időszakban •Sok alkalommal zajló integrálás •Kollektív kódú tulajdonjog •Az optimizálást a végére hagyni •Nincs túlóra Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)

24 Tesztelés •Minden kódnak unit tesztje kell legyen •Minden kód át kell menjen ezen az unit teszteken, mielőtt kibocsájtanánk •Amikor BUG –ot fedeznek fel, tesztet kell készíteni hozzá •Elfogadhatósági tesztet kell sokszor futtatni és az eredményt publikálni Sapientia - Erdélyi Magyar Tudomány Egyetem (EMTE)