Házi feladat tanácsok - Rendszermodellezés és WBM

Általános tanácsok a házi feladathoz

• Bejelentkezés után ezen a linken (valamint az oldalsávban, továbbá Saját adatok/Tanulmányok alatt) érhető el a feladatleadó űrlap, hozzá használati útmutató itt.
• Gondosan olvasd át a feladatkiírást minden fázis előtt! Ha nem felel meg a feltételeknek, nem fogjuk elfogadni a megoldásodat.
• A kijelölt témádhoz tartozik egy illusztratív példa: valamely valós rendszer, amely hasonló céllal üzemel. Nem ezt a példarendszert kell lemodellezni; csupán segítségként adtuk meg, hogy könnyebben képzeld el, milyen folyamatok zajlanak le egy ilyen rendszerben.
• Nem kötelező feltétel, hogy Use Case-ekre bontott, valószínűségi viselkedésmodellt tartalmazó folyamatmodellt készíts, ez csupán mintapélda (de ettől függetlenül vizsgaanyag).
• Ne építs fölöslegesen nagy modellt, a saját dolgodat nehezíted meg.
• Üzletifolyamat-modellező eszközöket használunk, de informatikai rendszer modellezésére. Ezzel összhangban nem kell üzleti szempontokat (költség, megtérülés, stb.) vizsgálni.
• Csak az számít erőforrásnak, aminek a mennyisége a terheléstől függetlenül adott, az egyes folyamatpéldányok a futásuk közben használják és a szűkös kapacitásáért versengenek egymással. Ha valamiből pl. mindig annyi példány van, ahány folyamatpéldány, és mindegyik használ egyet-egyet, az a mi számunkra nem erőforrás. Ha valami egy folyamat során "elfogy" vagy a folyamat lefutása urán használatban marad, az (ilyen értelemben) szintén nem erőforrás, és az sem, amit több erőforráspéldány közösen (nem versengve) használ.
• Ügyelj arra, hogy az erőforrások igénybevétele egy nagyságrenden belül legyen. Például ha patikát modellezünk, a recept felírása az alkalmazottnak két perc, utána a tranzakció rögzítése a számítógépnek 0,03 másodperc, akkor gyakorlatilag csak az alkalmazottak teljesítményét tudnánk mérni, nem a számítógépét.
• A pontosabb mérések érdekében ügyelj arra, hogy egy elágazás minden ágára jusson elég token. Ezért például egy 99%-1% döntés nem a legszerencsésebb. Ha elágazásnál valamelyik ág valószínűsége nagyon kicsi (pl. 3% eséllyel új felhasználó, aki regisztrál), akkor inkább hanyagold el ezt az ágat (ezt az egyszerűsítést viszont a szövegben jelöld!), mert különben nagyon sok folyamatpéldányt kéne a rendszerbe engedni, hogy erre az ágra is jusson elég.

Tanácsok az egyes mérési feladatokhoz

• A feladatkiírásban feltétlenül olvassuk át az egyes részfeladatok leírását, mielőtt hozzájuk kezdenénk.
• A terhelésméretezésnél indítsuk egyesével a folyamatpéldányokat, fix időszakonként. Gondoskodjunk arról, hogy a terhelés elég intenzív legyen (tehát elég sűrűen induljanak az egyes példányok) ahhoz, hogy valamelyik erőforrás telítődjön; valamint hogy összességében elég token legyen ahhoz, hogy a végeredmény ne változzon jelentősen a továbbnöveléssel. De minden esetben legyen legalább 100 token.
• A globális teljesítménykorlát számításakor nincsenek erőforrások, semmi sem szab gátat a folyamatpéldányok párhuzamos végrehajtásának. Ezt alaposan gondoljuk végig, mielőtt értelmezzük a válaszokat, és "Ügyeljünk arra, hogy csak olyan teljesítményjellemzőket mérjünk, amelyeknek erőforráskorlátok nélkül is van jelentése".
• Ha a szűk keresztmetszet kereséséhez hozzá se tudunk kezdeni, mert minimális mennyiség esetén is nagyon gyenge (40% alatti) az összes erőforrástípus kihasználtsága, akkor a terhelésméretezést rontottuk el.
• A szűk keresztmetszet keresése közben a terhelés intenzitását már semmi esetre se változtatgassuk (a tokenek számát lehetne folyamatosan igazítani, de ez nem elvárás).
• A megbízhatósági modellezés részfeladatot értsd meg, mielőtt elkészíted! A félév során lesz a témában bemutató, ahol elmagyarázzuk és az eszközön is megmutatjuk; ezen kívül közzé lesz téve a feladathoz egy segédlet.
• Az érzékenységvizsgálatnál a folyamat olyan paraméterére végezzük a vizsgálatot, amilyet a feladatkiírás megenged (tehát pl. nem a terhelés méretére). Próbáljuk ki 5-6 jelentősen különböző értéket!

Websphere Business Modeler (7.0)

• Rendszeresen exportáld ki az elkészült munkát biztonsági mentés céljából.
• Ellenőrizd, hogy a köztes és különösen a beadásra szánt modell exportot hibátlanul vissza tudod-e importálni. Üres workspace-ben (vagy akár másik virtuális gépben) érdemes kipróbálni.
• A projektet .mar fájlba exportáljuk! Ügyelni kell arra, hogy az egész projekt belekerüljön, ne csak valamelyik része, amelyik éppen ki volt jelölve az exportkor. (Visszatöltési próba!)
• Az első szimulációnál kevés tokent indítva érdemes animálva megnézni az eseményeket, de utána a Simulation Control Panel (kicsit eldugott) Settings… gombjával kapcsoljuk ki az animációt, mert ezzel jelentősen meggyorsítható.
• Érdemes a több részletet mutató Advanced View-ra váltani. Sok véletlenül keletkező bekötetlen be/kimenetet fedezhetünk fel és háríthatunk el vele, és a tulajdonságlapok is bővülnek.
• Mivel a főfolyamat és minden alfolyamat inputja és/vagy outputja nem egyszerű vezérlési token, hanem típusos munkadarab, azokat a keret bal- ill. jobb oldalához kötő éllel lehet feltüntetni. Ennek megfelelően Start nem is kell, érdekes módon viszont befejezéskor a kimenet kiküldése mellett kell egy egyszerű jelöletlen (vezérlési) él is a Terminate helyre. A főfolyamat kötelezően input munkadarabbal induljon, hogy szimuláláskor a terhelést jól lehessen szabályozni.
• Próbáljunk figyelni a diagramok esztétikájára és áttekinthetőségére. Az összegubancolódó összekötéseknél megfontolandó a szétválasztás (Split and reposition menüpont). Ne a kezdeti hatalmas folyamatterületen dolgozzunk, használjuk az átméretező gombot! A szoftver újabb verzióiban a környezeti menüben található Compact Diagram ezt megteszi automatikusan, de nem mindig tetszetős az eredmény.
• Az áttekinthetőséget növelheti, ha a folyamatot adott esetben több alfolyamatból építjük fel. Ezt támogatja, hogy egy folyamat bizonyos részeit kijelölve a Move into > Local Process menüponttal utólag is kiemelhetjük őket egy lokális alfolyamatba (ne felejtsünk viszont el Terminate csomópontot hozzáadni). Az így létrejött elem később a Convert to > Global Process segítségével kiemelhető legfelsőbb szintű folyamattá, amely több helyről is hívható, külön is szimulálható, stb. Ügyeljünk arra, hogy a tényleges mérések folyamán mindig a főfolyamatot szimuláljuk! Figyelem: a szimulációs pillanatfelvételben külön [+] gomb szolgál az alfolyamatok tartalmának megmutatására, nem lehet a szokásos módon kibontani őket.
• Ismerd meg a Terminate Node és az End Node közti különbséget, mielőtt használnád őket! Nagy valószínűséggel a Terminate lesz a jó választás.
• Ha egy belső alfolyamat (subprocess) többféleképp is befejeződhet, és ennek függvényében máshogy folytatódik a főfolyamat, akkor vezess ki a részfolyamatból egy-egy külön outputot az egyes esetekre, amelyeket kívül külön vezethetsz el. Készíteni kell továbbá egy-egy külön Output Criteriont (ez esetleg csak Advanced View-ban látható) az egyes esetekre, és egy-egy külön Terminate csomóponttal összerendelni őket, végül minden esetből a megfelelő kimenetre és a hozzá tartozó Terminate-be húzni az élet. De előtte érdemes megfontolni, hogy valóban kell-e nekünk részfolyamaton belüli elágazás - a legegyszerűbb úgy modellezni a folyamatot, hogy erre ne legyen szükség.
• Háromféle ömlesztett erőforrásjelleg van: Role, Resource Definition és Resource; válasszuk a Role lehetőséget.
  • Magyarázat. Ha egy bulk erőforrásigény Role, akkor a szimulációs profilban állítani lehet, hogy a szimuláció kedvéért hány példány álljon rendelkezésre a Role-hoz (végtelen is választható!), ezeket nem is kell kézzel létrehozni. Konkrét erőforráspéldányra hivatkozva erre nincs lehetőség, itt csak a példány mennyiségét lehet átállítani, ami után sajnos új simulation snapshot készítendő. Erőforrás definícióra hivatkozva viszont ki lehet trükközni: hozzunk létre 1, 2, 4, 8, 16, 32, 64, … elemű példányokat (esetleg egy végtelen eleműt is). A simulation snapshotba ezek bekerülnek, és a Process Resource Pooljában egyenként ki-be kapcsolgathatóak, binárisan előállítva a kínált erőforrás-mennyiséget. Ezen felül a WBM az erőforrás kihasználtságát is csak Role típus esetén számolja a kívánt módon (tehát a rendelkezésre álló mennyiséggel leosztva). Alapvetően tehát Role, Definition, Resource a kívánatossági sorrend.
• Beállítható minden Role-hoz külön szín, majd a folyamat taszkjai automatikusan kiszínezhetőek a felhasznált Role szerint. Ezzel könnyen áttekinthető lesz, hol van szükség az egyes erőforrásokra. Alternatív megoldás, ha ideiglenes bekapcsoljuk a Role szerinti Swimlane Layout funkciót.
• Decision: ha az outputok százalékos összege nem adja ki a százat, tokenek tűnnek el. Viszont ha meghaladja, akkor sem fognak plusz tokenek szaporodni. Mindkét esetben warning-ot kapunk.
• Alapbeállítás, hogy a taszkok végrehajtási ideje automatikusan egyenlő legyen az erőforrás-foglalás idejével. Így eggyel kevesebb mezőt kell kitölteni; a 6.2 verziótól alapértelmezésben nem is látszik már a Duration fül.
• A Merge a specifikációnak és intuíciónknak megfelelően működik, azonban a Join nem: ha párhuzamos ágakról érkező munkadarabokat akarunk szinkronizálni, megduplázódnak. A jelenség dokumentálva van a help-ben. A legegyszerűbb megoldás, ha a Fork-ot nem Joinnal zárjuk le, hanem egy Task-kal; szükség esetén egy fantom taszk "dummy join" is bevethető 0 erőforrásigénnyel és végrehajtási idővel (bár ez így persze elég ronda).
• Ilyen "dummy join" esetén előfordulhat, hogy a 0 erőforrásfoglalás ellenére is várakoztat egy fix időt (pl. 1 másodperc). Ezt a Duration fülön lehet kikapcsolni (ami alapértelmezésben nem látszik, de Advanced nézetben láthatóvá tehető). A kezdeti érték egyébként a simulation snapshot beállításaiból (Tasks pont) és végső soron az egész WBM Preferences beállításaiból származik, tehát ezen helyeken lehet elejét venni a problémának.
• A Fork lezárása Merge-dzsel, illetve a Decision lezárása Join-nal „halálfejes hiba”.
• Ciklust egyszerűen létrehozhatunk egy valószínűségi elágazás visszacsatolásával egy korábbi Merge csomópontba. Ne lepődjünk meg, ha ilyenkor a fejlesztőkörnyezet nem tudja eldönteni, befejeződik-e az összes út; ezzel a figyelmeztetéssel nem kell törődni. Van egy kényelmesebb, szebb, de mégis kerülendő megoldás: a While (vagy Do-While) csomópont használata; a ciklus mag kijelölésével és a Move into környezeti menüvel utólag is létrehozható, és átmegy az ellenőrzésen. Lényeges hátrány azonban, hogy típusos élekkel látszólag nem működik; pontosabban az nem vezethető át a Loop csomópont határán, hanem külön tárolóba kell helyezni; így mégis a visszacsatolásos megoldás az ajánlott.
• A főfolyamat környezeti menüjében kiadott Simulate létrehozza szimulációs pillanatfelvételt (alfolyamatokra nyomva csak azt az egy alfolyamatot szimulálná, mi nem ezt szeretnénk), amelyben a szimulációhoz használt input terhelés beállítható. A folyamat bizonyos paramétereit a snapshot lemásolhatja, így az eredeti folyamatban módosítva már nem lesz hatásuk (csak a később készített snapshotokra) - ezt mindig ellenőrizzük!  A tényleges szimuláció a snapshot megnyitása után a Simulation Control Panel nézetből indítható.
• A szimuláció eredményén lehet dinamikus analízist végezni. Próbálgasd ki a különféle kimutatásokat, keresd meg azokat, amelyekre szükséged lesz a házi feladathoz! (Különösen ajánlott: Resource Usage Summary és Activity Time)
• Fontos: amit az eszköz "throughput"-nak hív, az valójában nem a throughput (átlagos átbocsátási ráta), hanem egyszerűen az átlagos körülfordulási idő reciproka. Ne használjuk.
• A WebSphere Business Modeler alapesetben 1024 MB memóriával indul, ez az eclipse.ini megfelelő sorának (-Xmx1024m) módosításával növelhető (egyéb tényezők függvényében) kb. másfélszereséig.
• Ismert probléma, hogy nagy lépésszámú szimuláció (~10000 folyamat) futási eredményeit tartalmazó szimulációs pillanatkép (snapshot) törlése sokáig tarthat. Egyrészt pár perces várakozás után a snapshot törlődik, másrészt a WebSphere újraindítása után az adott snapshot gyorsabban törölhető. Ez az eset egyébként elkerülhető akkor, ha olyan szimulációs beállításoknál, melyek szükségessége/értelme a szimuláció indításakor kérdéses, néhány futtatással indulunk (ez egyben szimulációs időt is spórol).
• Figyeljünk oda alaposan, ha valamiért hibás a szimuláció lefutása.
• Figyeljünk oda az Errors nézetben megjelenő hibákra, figyelmeztetésekre.
• Forgasd nyugodtan az eszköz súgóját.

Virtuális gép üzemeltetése (2012-ig)

• A működtetéshez használhatod az ingyenes VMware Playert.
• A virtuális gép altatható (suspend), a virtuális desktop ablak bezárásának ez az alapértelmezett következménye. Ekkor gyorsabban folytatható a munka, de némi lemezterületet igényel a futás közbeni memóriakép elmentése.
• Látványosan gyorsabban fut a virtuális gép, ha a gazdagépen van elég (kb. 1 GB) szabad memória. A vendég gép által látható memória mennyisége is szabályozható, de ez bonyolultabb kapcsolatban van az összteljesítménnyel – túl magasra állítva maga a virtuális gép fog a kelleténél gyakrabban kilapozódni. A vendég gépen futó alkalmazás esetenkénti újraindítása esetleg javíthat a memóriaigényén. Szintén érdemes odafigyelni a vendég gépen beállított lapozófájl méretére.
• Őrizz meg egy másolatot a virtuális gépről eredeti állapotában (vagy az egyik ismerősödnél legyen). Ha baj van, visszatérhetsz erre, és betöltheted az exportált modellt. Próbálkozhatsz a VMware Snapshot technológiájával is (ez azonban a Player eszköznek nem része).
• Ügyelj arra, hogy a vendég gép virtuális lemeze ne teljen be (megj: a jelenlegi gépen használt virtuális diszk 20G-ig enged tágulni, ezért ez a veszély már kevésbé jelentős). Helyszűkében a fölösleges mérési adatokat ki lehet takarítani. Végszükség esetén megnövelheted a virtuális lemezterületet.
• A VMware Tools paravirtualizációs eszköztár legyen telepítve és frissítve a vendéggépen. Ennek egyrészt sebességbeli előnyei vannak, másrészt szorosabb integrációt biztosít, pl. legegyszerűbben drag & drop segítségével is mozgathatóak a fájlok a virtuális gép és a vendéggép közt.