Modellvezérelt szoftverfejlesztés a gyakorlatban Doktori értekezés Medve Anna okleveles programtervező matematikus
Eötvös Loránd Tudományegyetem Informatika Doktori Iskola Az informatika alapjai és módszertana program Iskolavezető:
Dr. Benczúr András, egyetemi tanár matematikai tudományok doktora Programvezető:
Dr. Demetrovics János, akadémikus matematikai tudományok doktora Témavezető:
Dr. Kozma László, habilitált egyetemi docens matematikai tudományok kandidátusa Kutatóhely:
Programozáselmélet és Szoftvertechnológiai Tanszék A kutatás a TÁMOP4.2.1./B-09/1/KMR-2010-0003, Sonepar Magyarország Zrt. és Pannontej Zrt. támogatásával valósult meg.
2013. 1
2
Ezt az értekezést az Eötvös Lóránd Tudományegyetem az Informatika alapjai című doktori programjának keretében készítettem 2011 és 2013 között és ezúton benyújtom az ELTE doktori PhD fokozatának elnyerése céljából. Budapest, 2013. július 08. …………………………………………… Medve Anna Jelölt
Tanúsítom, hogy Medve Anna doktorjelölt 2011 és 2013 között a fent megnevezett doktori program keretében irányításommal végezte munkáját. Az értekezésben foglaltak a jelölt önálló
munkáján
alapulnak,
az
eredményekhez
önállóan
alkotó
tevékenységével
meghatározóan hozzájárult. Az értekezés elfogadását javasolom. Budapest, 2013. július 08. Dr. Kozma László
Matematikai Tudományok Kandidátusa Témavezető
3
Tartalomjegyzék 1 Modellvezérelt fejlesztés................................................................................................... 15 1.1 Modellvezérelt architektúra......................................................................................... 15 1.2 Modellvezérelt fejlesztés ............................................................................................... 16 1.3 Modellek és technikák .................................................................................................. 19 1.4 Szabványosított szakterület-specifikus és általános célú nyelvek............................. 21 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 1.4.8 1.4.9 1.4.10 1.4.11
User Requirements Notation (URN) ........................................................................ 22 Message Sequence Chart és High-level Message Sequence Chart (MSC, HMSC) 23 Specification and Description Language ................................................................. 24 Abstract Syntax Notation One (ASN.1) ................................................................... 24 Testing and Test Control Notation (TTCN-3) ......................................................... 25 Unified Modeling Langugae (UML) ........................................................................ 25 Object Constraints Language (OCL) ....................................................................... 26 System and Software Modeling Language (SysML) ............................................... 26 Business Process Model and Notation (BPMN) ...................................................... 26 Platform leíró nyelvek .............................................................................................. 27 Formális verifikáló eszközök legszükségesebb jellemzői ....................................... 27
2 Technológiai sor modellvezérelt fejlesztéshez ................................................................ 28 2.1 Technológiai sor séma modellvezérelt fejlesztésekhez............................................... 29 2.1.1 2.1.2 2.1.3
Elvi technológiai sor séma példányosítása formális nyelvcsalád felhasználásával . 31 Technológiai sorok specifikációi és példányosításai ............................................... 34 Példa az 1. technológiai sorral a technológiai sorok alkalmazására komponens alapú szoftverfejlesztéshez ....................................................................................... 37
2.2 Technológiai sor kiegészítése létező verifikációs technológiákkal integrált formális verifikáláshoz............................................................................................................. 39 2.2.1 2.2.2
Verimag IFx eszköztár alkalmazása integrált verifikálásra ..................................... 40 Modell-alapú tesztelés.............................................................................................. 42
2.3 Összefoglalás az 1. Tézis tárgyalásáról ....................................................................... 42 3 Módszerfejlesztés szoftvertervezési minták alkalmazására MDE folyamatban ......... 44 3.1 Módszerfejlesztés a POSA2, a GOF és a szakterületi minták összeszövésére ......... 47 3.1.1 3.1.2 3.1.3 3.1.4
POSA2 architektúra mintanyelvek felhasználása a munkánkban ............................ 48 GOF programtervezési minták felhasználása a munkánkban .................................. 49 SDL szakterületi minták felhasználása a munkánkban ............................................ 50 Módszerleírás keretrendszer építéshez a POSA2, GOF és szakterületi programtervezési minták összeszövésével ............................................................... 51
3.2 Módszer alkalmazása UML fejlesztéshez ................................................................... 52 3.2.1 3.2.2 3.2.3
Mintanyelv és keretrendszer építése ........................................................................ 53 Keretrendszer és mintanyelvek újrafelhasználása .................................................... 57 Újrafelhasználás szemléltetése minta alapú rendszerfeltárással és modellezéssel .. 61
3.3 Módszer alkalmazása SDL alapú szakterületi fejlesztéshez ..................................... 63 3.3.1 3.3.2
SDL Macro-Pattern mintanyelv létrehozása ............................................................ 64 Lépéssorozat MSC elemzéshez és transzformáláshoz SDL állapotgráf létrehozására ................................................................................................................................ 67 4
3.3.3 3.3.4 3.3.5
SDL Macro-Pattern és a GOF programtervezési minták összeszövése ................... 68 SDL Macro-Pattern és az SDL Pattern szakterületi minták összeszövése .............. 69 SDL Macro-Pattern mintanyelv újrafelhasználásának lépései ................................. 74
3.4 Összefoglalás a 2. Tézis tárgyalásáról ......................................................................... 76 4 Modellvezérelt elv alkalmazása evolúciós fejlesztéshez az üzleti területen ................. 78 4.1 Technológiai sor séma modellvezérelt fejlesztéshez az üzleti területen .................. 83 4.1.1 4.1.2
Technológiai sor séma és specifikáció ..................................................................... 83 Módszerleírás az URN alapú újratervezés szervezéséhez ....................................... 87
4.2 Módszertan az üzleti folyamatok specifikálására és inspekciójára ......................... 89 4.2.1
A KobrA módszertan Use Case Description és Operation Description sablonjainak szintézise és továbbfejlesztése: a természetes nyelvű modellezéshez felhasználói követelmények gyűjtésére az üzleti folyamatok specifikálásához ........................... 90 4.2.2 Folyamatspecifikációs űrlap és tevékenység forgatókönyv űrlap............................ 93 4.2.3 Az üzleti folyamatgazda feladatai a folyamatspecifikációs űrlap kitöltéséhez önellenőrzéssel ......................................................................................................... 96 4.2.4 Use Case Maps elemek alkalmazása folyamatspecifikáció kategóriákra ................ 98 4.2.5 Eljárás a folyamatspecifikációs űrlap alapú specifikálás menetére ......................... 99 4.2.6 URN folyamatmodellezés dokumentumtípusai és kezelésük ................................ 103 4.2.7 Folyamatfeltárás és folyamatspecifikálás minőségbiztosítása oktatással .............. 104 4.2.8 Folyamatfeltárás és folyamatspecifikálás minőségbiztosítása inspekcióval .......... 105 4.2.9 UCM modelltranszformációk a modellfejlesztők és minőségfelelősök számára .. 110 4.2.10 A módszer bevezetése ............................................................................................ 111 4.2.11 Módszer- és modellezés szolgáltatás a folyamatok karbantartásához ................... 112 4.3 Módszertan keretrendszer építésére változáskezeléshez ......................................... 112 4.3.1 4.3.2 4.3.3 4.3.4
Módszer Use Case Description alapú URN modellezéshez .................................. 115 Üzleti folyamatok modellezésének keretrendszerbe foglalása .............................. 117 A keretrendszer implementálása és újrafelhasználása ........................................... 118 Az URN alapú újratervezés ipari validálásának esetei .......................................... 123
4.4 Összefoglalás a 3. Tézis tárgyalásáról ....................................................................... 124 5 Összefoglalás ................................................................................................................... 126 6 Irodalomjegyzék ............................................................................................................. 132 7 Mellékletek ...................................................................................................................... 150 7.1 Rövidítésjegyzék.......................................................................................................... 150 7.2 Mellékletek a 2. fejezethez .......................................................................................... 152 7.3 Mellékletek a 3. fejezethez .......................................................................................... 153 7.4 Mellékletek a 4. fejezethez .......................................................................................... 160 8 Összefoglaló ..................................................................................................................... 170 9 Summary ........................................................................................................................ 171
5
Táblázatjegyzék 1. táblázat 2. táblázat 3. táblázat 4. táblázat 5. táblázat 6. táblázat 7. táblázat 8. táblázat 9. táblázat 10. táblázat 11. táblázat 12. táblázat 13. táblázat 14. táblázat 15. táblázat 16. táblázat 17. táblázat
A 7. ábra F1 és F2 technológiai sor specifikációk példányai .......................... 35 A komponens alapú alkalmazásfejlesztés szakaszai az 1. technológiai sorral 38 A komponens újrafelhasználásának szakaszai az 1. technológiai sorral .......... 38 ComponentConfigurator mintához illesztett SDL Pattern Pool minták ......... 73 A 22. ábra F3 és F4 technológiai sor specifikációk példányai ........................ 85 Folyamatspecifikációs űrlap A és B része ........................................................ 94 Tevékenység©forgatókönyv űrlap (feladat, műveletek leírása a művelet űrlapokon) a folyamatközi kapcsolatok elemzése a múlt és jövő idejű akciók függvényében (C.űrlap) .................................................................................... 95 A folyamatspecifikációs űrlap kitöltésekor az önellenőrzés szempontjai ....... 96 Inspekciós perspektíva megadása jelenlegi helyzet üzleti folyamatainak inspekciójához ................................................................................................ 108 Hibadetektáló és hibagyűjtő űrlap ................................................................. 108 Inspekciós hibaérvényesség és korrekciós űrlap ........................................... 109 Use Case Description elemek megfeleltetése az URN modellezés menetének és elemeinek.................................................................................................... 115 Use Case Description Template (forrás: Gro05, 32. o.) ............................... 160 Operation Description Template (forrás: Gro05, 42.o.) ............................... 160 Feladatok és részfeladatok űrlap – Fedezetvizsgálat folyamat – példa (UCM modell a 28. ábrán)......................................................................................... 161 Tevékenység © forgatókönyvűrlap (Alapműveletek kapcsolatainak leírása a művelet űrlapokon) ......................................................................................... 163 Use Case Description űrlap információszerzés esetéről mobil eszközzel ( URN modellezés 4.3.1) ............................................................................................ 165
Ábrajegyzék 1. ábra MDA eszközei: fix nézőpontmodellek rétegződése (balra) és több szabvány kapcsolata (jobbra) ........................................................................................... 15 2. ábra . MDE folyamattípusok és szerepek, tevékenységek, termékek. ................................. 16 3. ábra A modellvezérelt szoftverfejlesztés dimenziói............................................................. 19 4. ábra Elvi technológiai sor séma a modellvezérelt fejlesztésekhez: alaptevékenységek (ellipszisben) és a fő technológiai összetevők kapcsolatai ............................... 30 5. ábra Technológiai sor séma példányosítása az ITU-T System Design Language és egyéb nyelvek kapcsolataival az absztrakció/konkretizáció fejlesztési dimenzió mentén............................................................................................................... 32 6. ábra A technológiai sor séma példányosításának (5. ábra) kibővítése az újrafelhasználást elősegítő szabványokkal ................................................................................... 33 7. ábra Technológiai sor specifikációk az ITU-T System Design Languages, UML, DSML nyelvekre alapozva ........................................................................................... 34 8. ábra A formális modellellenőrzők szolgáltatásai és integrálásuk a modellvezérelt fejlesztésbe........................................................................................................ 39 9. ábra Technológiai sor séma kiegészítése modellezésbe integrálható verifikáló/validáló eszközökkel..................................................................................................... 411 10. ábra Component Configurator minta osztály [Scha00, p.80] és állapotgráf diagramja [Scha00, p.82] .................................................................................. 54 11. ábra Component Configurator összetett struktúra diagram ..................................... 55 6
12. ábra 13. ábra 14. ábra 15. ábra 16. ábra 17. ábra 18. ábra 19. ábra 20. ábra 21. ábra 22. ábra 23. ábra 24. ábra 25. ábra 26. ábra 27. ábra 28. ábra 29. ábra 30. ábra 31. ábra 32. ábra 33. ábra 34. ábra 35. ábra 36. ábra 37. ábra 38. ábra
Component Configurator mintában, a kért komponens futtatásához szükséges szerepek és kölcsönhatásaik (részlet) ............................................................... 56 Wrapper Facade minta megvalósításának modellezése a Template Method GOF minta beleszövésével ............................................................................... 57 Component Configurator minta alkalmazása újrafelhasználással GMSC híváskezelő funkció architektúra modelljéhez.................................................. 58 GSM hálózat elvi összetétele (forrás [Dár03]) a fő funkciókkal a POSA2 szolgáltatáselérés és konfigurálás minták illesztéséhez .................................... 62 Block Type CompConfig: Component Configurator minta struktúra modellje SDL blokk diagramban ..................................................................................... 66 MSC diagram a Component Configurator minta belső kommunikációjával és ebben a hibakezeléshez és hibatűréshez szükséges SDL Pattern mintaegységek kijelölése ........................................................................................................... 72 SDL állapotgráf (processz diagram) részlet a Config automata viselkedés modelljébe (17. ábra) beleszőtt SDL Fragments elemek beleszövésével ......... 73 SDL Macro-Pattern mintanyelvből a Component Configurator minta CompConfig modelljének újrafelhasználása a GMSC híváskezelő funkcióinak specifikálására................................................................................................... 75 SDL Macro-Pattern mintanyelv CompConfig állapotgráf sablon paraméterezése a GMSC híváskezelő folyamatának specifikálására (részlet) . 76 A technológiai sor séma egy példányosítása az üzleti területre modellvezérelt fejlesztéshez ...................................................................................................... 83 Az üzleti területre kijelölt technológiai sorok specifikációi MDE fejlesztésekhez .................................................................................................. 84 Folyamatszemlélet alapesetben UCM jelölésekkel ......................................... 98 Folyamat strukturálódása UCM jelölésekkel................................................... 98 Folyamatszemlélet minőségi elvárások teljesítéséhez ..................................... 98 UCM forgatókönyv példa a Hol, Mit, Mikor, Kivel, Ki kérdésekre ............... 99 UCM forgatókönyv példa a Hol, Mit, Mivel, Kivel kérdésekre ...................... 99 Példa folyamatspecifikációra: a Fedezetvizsgálat UCM-root (folyamatleírás 7.4 Melléklet 15.-16. táblázat) ........................................................................ 101 jUCMNav eszköztámogatása a követelmények validálásához stratégiakiértékeléssel ..................................................................................... 102 URN és jUCMNav alapú generikus keretrendszer modell ............................. 114 Példa biztonságmodellezésre GRL célorientált döntésfában (lásd a 4.3.2.1 alpontban) ....................................................................................................... 121 Példa biztonság stratégia kiértékelésre GRL célorientált döntésfában (lásd a 4.3.2.1 pontban) .............................................................................................. 121 GRL célfa részlet - Teszteset követelménytervből – szerver hiba UCM forgatókönyve (piros vonal) ........................................................................... 122 MSC/UML SD teszteset modell a teszteset forgatókönyvből (33. ábra) automatikus transzformációval ....................................................................... 122 KobrA módszertan modell elveiből a fejlesztés dimenziói: dekompozicíó, kompozicíó, absztrakció, konkretizáció, generikus, specifikus (forrás: [Atk02]) ........................................................................................................................ 152 Verimag IFx 2.0 Toolbox elemei (forrás: [Med12b])................................... 152 POSA2 architektúra minták osztályozása (ábra forrása: Sch00 ) ................. 153 GOF programtervezési minták osztályozása (ábra forrása: Gam95 ) ........... 153
7
39. ábra 40. ábra 41. ábra 42. ábra 43. ábra 44. ábra 45. ábra 46. ábra 47. ábra 48. ábra 49. ábra 50. ábra 51. ábra 52. ábra 53. ábra 54. ábra 55. ábra
POSA2 architektúra mintanyelv: „Szolgáltatás elérési és konfigurálási minták” szürke, az „Eseménykezelési minták” kék, a „Szinkronizációs minták” narancssárga, a „Konkurens minták pink színnel (forrás Sch00) ................... 154 GOF programtervezési minták mintanyelve (forrás Gam96) ....................... 155 Mintanyelv szövése az áttekintő kölcsönhatás (IO) diagram eszközeivel, az architektúra minta metódusaihoz illesztve a programtervezési mintákat (itt Observer, Interpreter minták ) ....................................................................... 156 Mintanyelv szövése: MSC Observer diagram (felső) a jelentésadáshoz a felügyelt komponensől.................................................................................... 157 GMSC híváskezelés funkció együttműködés diagramjai (felső és alsó ábra) ........................................................................................................................ 158 Memento (alsó ábra) és Interpreter (felső ábra) GOF minták alkalmazása a POSA2 Configurator szerepre ........................................................................ 159 e-kereskedelem evolúciós fejlesztéséhez technológiai és biztonsági stratégia fokozatok ........................................................................................................ 163 URN Link szerepe és alkalmazása stratégiái döntések megjelenítésére és átjárhatósághoz ............................................................................................... 164 UCM folyamattérkép információbiztonság nélkül (balra) és GRL célmodellekből integrálással (jobbra) ............................................................ 164 GRL célfában stratégia kiértékelés – ISO/IEC 27001/2 – ............................. 164 GRL célfa adatcseréhez mobil készülékkel üzleti folyamatban szerver oldali alkalmazáshoz (teljes modell) ......................................................................... 166 A 49. ábra GRL célfa részlete: kliens oldal, URN Link átjárhatóságra a megvalósításokhoz.......................................................................................... 166 Architektúra nézet a követelmény modell (52. ábra) újraszabásával és modularizálásával (sub-map) .......................................................................... 166 UCM funkcionális modell használati esetekkel: piros szín a forgatókönyv (adatküldés/feldolgozás/válasz) ...................................................................... 167 MSC/UML SD –automatikus modelltranszformáció az 52. ábra forgatókönyvéből ............................................................................................ 168 Minőségkövetelmények teljesülése (4.3.1 alpont) forgatókönyvben és ennek transzformációja (55.ábra) .............................................................................. 169 MSC / UML SD – automatikus modelltranszformáció az 54. ábrán látható UCM forgatókönyvből.................................................................................... 169
8
Köszönetnyílvánítás Köszönettel tartozok elsősorban Dr. Kozma László témavezetőmnek a munkás évekért, amelyek alatt sok emberi és szakmai előrehaladáshoz kaptam biztató és példamutató segítséget. Jósággal zökkentett ki megtorpanásaimból, kishitűségemből az „ott a fejedben csak dolgozzál rajta” szokásos biztatásával, és türelemmel mosolyogva tartott egy újabb konzultációt és adott olvasnivalót, hogy megvilágosodjak és kiemeljen a megtorpanásból. Hasonlóan köszönettel tartozom Dr. Benczúr András volt témavezetőmnek az adatbázis elméleti tanulmányokért és a pályámat segítő sok-sok tanácsáért. Már vállalati informatikusként az adatbázisok-hálózatok-programozás hármas bűvkörben éltem, picit sajnálom, hogy a hálózatok elhúztak az adatbázis kutatástól. Köszönöm, hogy visszafogadott és a szoftvertechnológiában új témával kezdhettem Kozma Tanár Úrnál. Nélkülük, a doktorjelöltségem és ez a dolgozat nem jött volna létre. Köszönöm a Programozáselmélet és Szoftvertechnológiai Tanszék munkatársainak a sok jó hangulatú és értékes szemináriumot, és hogy szeretettel segítették fejlődésemet. Sokat kaptam minden tekintetben az ELTE tudásból és szellemből, amit remélem sikerül mindig továbbadnom a magam eszközeivel, nemcsak a napi munkám során. Szintén köszönettel tartozom Dr. Hangos Katalin és Starkné Dr. Werner Ágnes veszprémi tanszékvezetőimnek az erkölcsi és anyagi támogatásért, a biztatásért, a jó körülményekért. Köszönöm Dr. Ileana Ober szerzőtársunknak a közös munkát és támogatását, valamint Dr. Zoubir Mammeri laborvezetőnek is. Mindketten az IRIT Toulouse munkatársai, akik közös munkákkal megerősítettek az SDL oktatásában és kutatásában, szakmailag és emberileg is. Köszönöm Dr. Daniel Amyot Ottawa-i CSERG kutatónak a támogatását, és hogy eljött Veszprémbe megismerni az URN munkáimat, és kiváló műhelymunkákkal gyarapította a hallgatóimat is. Köszönöm Dr. Tarnai Katalinnak, hogy a Veszprémi Egyetemen alapította meg a Távközlési hálózatok iskolát, és bizalommal adott lehetőséget nekem a tantárgyalapításokra. És utolsó sorban, de mindenekelőtt köszönöm kiterjedt családom tagjainak a SZERETETET.
Medve Anna 9
Bevezetés Egy új igény kezelése a szoftverfejlesztésben mindig rejtett kockázatot jelent a változáskezelés jóságára és költségeire nézve. Az un. modellvezérelt technológiákkal [OMG12] már összetett rendszerek esetében is magas absztrakciós szinteken kezelhető a szoftverrendszerek elemeinek funkcionális együttműködése, mind az adatcserék, mind a művelet szintű kölcsönhatások eseteiben. [Sha89, Lem10, Lia10, Gyi09, Bre06] A modellezés a tervezést és a kódolást megelőző tevékenység, amelyben a modellek a valóságot ábrázolják adott nézőpontból és adott cél érdekében. A modellt és modellezést meghatározza a leírónyelv, a nézőpontelmélet és a vizsgált rendszer. A szoftvertechnológiában adottak a modellalkotás és modellkezelés hatékony eszközei, mint a szakterület-specifikus modellező nyelvek, amelyekben a szakterületi mechanizmusok konkrét nyelvi szinten jelennek meg [Kur06, Tol06, Wal09, Her09, Ach09, Alf09, Béz09], valamint a szakterület-specifikus modellező környezetek, amelyekben a szakértők tudásának kezelését támogatják a beépített tudásbázis-kezelő eszközök [Cza11, Mal08, Cuc11, Obe10, Kli11, Lor11, Rio11].
A rendszeraspektusok kezeléséhez kialakultak az architektúra nézőpontok [Kru95,
Kru09, Som07]
az aspektus-orientált módszerek [AOS12, Kic97, Kic05, Elr04, Jac04, Bre06, Fue07,
Zha07, Gab06, Jéz08, Mus10b, Mus11], AMP12].
valamint a termékcsalád kezelés eszközei [Zsc09, Béz06,
Továbbá adottak a referencia modellek, mint OSI, Zachmann, RM-ODP, EDOC,
TOGAF, EDI, EA [REF12], amelyek alapjai a szakterületi mechanizmusok összeillesztésének, valamint a tervezési minták, amelyek főként a szakértők tudásának újrafelhasználását adják [Eri00, Gam95, Sch00, Hil12, POS12, Bus96, Buh98]. A komponenstechnológiák és a komponens elvű módszertanok jelentősen hozzájárultak a rendszeraspektusok
kezeléséhez
és
az
újrafelhasználásához
[Che09, Cho07].
Az
is
bebizonyosodott, hogy a komponenstechnológiák hatékonysága megnő a komponensmodellek alkalmazásával [Atk02] és a modellezéssel [Bun09]. A formális módszerek alkalmazásával növelhetők az absztrakciós szintek és hatékonyan kezelhetők a komponens specifikációk a tervezésben és újrafelhasználásban egyaránt [Buc04, Med08b, Gro05, Bor10]. Az automatizálással lecsökken a fejlesztés ideje és megnőhet a termék jósága [Pel09, Pen10, Crn09]. Az ilyen technológiáknak a fejlesztése és
alkalmazása képezi ma az un. modellvezérelt
szoftverfejlesztést, amelynek fő célja az automatizált szoftverfejlesztés [Béz10, Béz05], amely biztosítja a szakértők tudásának újrafelhasználását és az aspektusok kezelését [ Jéz08, Red09], ezzel egyben eredményezi a termelékenység növelését és a költségek csökkentését.
10
Mindehhez, szükségesek a formális módszerek és az áttérés a kód-központú fejlesztésről a modell-központú fejlesztésre [Tra08, Béz05b, Ist10, Pat10] előtérbe véve a modellezést és modelltranszformációkat [Béz00, Béz01, Béz04, Jen11, Jéz03, Fra04, Len08, Pat10], az architektúra terveket [Bas03, Fra03, Nik09] és a modell-integrálást [Bal06, Szt12]. A
modellvezérelt
fejlesztés
(Model-driven
Engineering
(MDE)
[OMG12])
egy
modellvezérelt fejlesztési módszertan a szakterületi nyelvekre [Obe10] és MDA elvekre [OMG03] alapozva. Az MDE elvek a következők: modell-alapú reprezentáció, aspektusok kezelése, újrafelhasználás, automatizálás. A modellvezérelt fejlesztés történhet a Modellvezérelt Architektúra (Model Driven Architecture (MDA) [OMG12]) módszertan szerint, amelynek az elveivel és eszközeivel [OMG03] a szoftvertermékek elkülönülnek az implementációs technológiáktól független formális rendszermodellbe a kód és platform felett, több szintű modellekkel, ahol többszintű modelltranszformációkkal már több platformra megvalósítható az alkalmazás [OMG03]. Manapság, a modellvezérelt fejlesztéshez rendelkezésre állnak a technológiák és minket az foglalkoztat, hogy milyen eszközökkel kell, megtörténjen a fejlesztés, hogy az MDE elveket maradéktalanul
meg
lehessen
valósítani
a
gyakorlatban.
Kísérleteket
folytattunk
technológiákkal különböző absztrakciós szinteken a modelltranszformációk és modellek integrálhatóságára. Vizsgáltuk, hogy a gyakorlatban mely technológiákkal és milyen hatékonysággal lehet követni az MDE elveket [Bus08, Buc04, Pat10, Por09, Szti12]. Lehetővé teszik-e a modellvezérelt technológiák a korábbiakban a komponenstechnológiákkal és objektumtechnológiákkal létrehozott szoftvertermékek újrafelhasználását [Got03b, Eis07]? Ha igen, akkor milyen előrelátással kell a technológiákat és a munkafolyamatot szervezni, hogy az
újrafelhasználáshoz
szükséges
erőforrások
arányosak
legyenek
időben
és
munkamennyiségben a felhasznált termékekkel elérhető eredményességgel. A modellvezérelt technológiákkal a fejlesztéshez szükséges technológiák sora képezhető hatékonyan a termékvonali szükségletekre egy adott szakterületen [ Zsc09, Obe09, Obe10]. A munkafolyamat gyors átszervezése és variálhatósága a modellvezérelt technológiákkal módszertani kérdéssé válik a rendszeraspektusok kezelése által. A fejlesztés korai szakaszában különböző tudású és gyakran ellenérdekű résztvevők [Som07] dolgoznak együtt. A komponenstechnológiában kialakultak az eszközök a korlátok kezelésére, a gyakorlatban felmerül a kérdés ezeknek a magasabb absztrakciós szintű hasznosítására a modellvezérelt elvekkel és technológiákkal [AMP12, Bos11, Mos07, Bre06, Koz08, Jac04, Jéz08, Elr04, Roy11, Zha07, Red09, Kra11].
Gondolunk itt a követelményfejlesztés nehézségeire [Gli04,] amelyeket az
automatizálással el lehetne kerülni [Pou10, Pou12, Koz08, Mus07b, Mus10, Mus10b, Mus12]. 11
Célkitűzések Kutatásunk tárgya a modellvezérelt szoftverfejlesztés folyamata és a technológiák gyakorlati alkalmazása. Kutatásunk fókuszában a fő MDE elvek állnak: az aspektusok nézőpontjai az MDA architektúrával, az újrafelhasználás a szoftvertervezési mintákkal és szoftverkomponensekkel, valamint a szakterületi modellezés technológiái. Ezeknek az eszközöknek az automatizáltsága jelentősen meghatározza az előállítható termékek tulajdonságait, újrafelhasználásuk lehetőségeit, az alkalmazható modellezési technikákat és ezek sorrendjét a folyamatban. Az automatizáltság és újrafelhasználhatóság végett jellegzetesen összetett technológiákkal történik a fejlesztés, amely az „egy probléma egy modellezési nyelv” megközelítést alkalmazza minden MDE aspektusra modellintegrálás elveken. A technológiák által az MDE gyakorlatba ültetése függ a szervezeti képességektől. A modellvezérelt folyamatban a transzformációs technikák bemeneteiként szolgálnak az üzleti-, architektúra- és tervezési minták, a technológiaválasztás, valamint a minőségi követelmények a megfelelés-vizsgálati pontokkal [OMG03]. Többféle modellvezérelt architektúra minta követhető a szakterületi tudásbázisok alapján. Ilyen folyamatban nagyfokú automatizálás szükséges. A minőségi követelmények technológiafüggése azt eredményezi, hogy az üzleti modell élesen beágyazott a platformmodellbe és a követelményfejlesztés nem zárható le az implementációs technológiákról hozott döntések előtt, hanem már a követelményfejlesztés során hatékonyságvizsgálatot kell végezni, és teszteseteket kell előállítani a funkcionális és a minőségi követelmények inspekciójához. A szakterületi tudásbázisok birtokában nem különülnek el élesen a számításfüggetlen és a platform független architektúra rétegek a folyamatban, és nagy általánosságban a platformmodellek is rendelkezésre állnak [Hut11, Jéz12, Bra12]. Motivációnk maga az MDE elvek gyakorlati alkalmazása. Keressük a lehetőségeket a szoftvertervezési minták hatékony felhasználásához a modellezés folytonosságának biztosítására a szoftverfolyamatban, amelyben az architektúra modell kulcsszerepét vesszük figyelembe [Per92]. Sok lehetőséget látunk az MDE technológia alkalmazására az üzleti területen. Vizsgáljuk az új technológiák alkalmazhatóságát arra, hogy az üzlet szereplői legyenek a jellemzőket meghatározó és szabályozó résztvevők az üzleti folyamatok modellezésében. Ezzel el lehet kerülni a követelmény feltárás és elemzés leggyakoribb hibáit. Az újrafelhasználás és az aspektusok kezelése fokozható a szabványokra alapozott követelményfejlesztéssel. A fejlesztés hatékonyságát növelni lehet a modell alapú teszteléssel és a követelményekből kinyert tesztesetekkel. Vizsgáljuk a módszerek fejlesztését és a technológiai sorok szervezését. 12
Alkalmazott módszerek Kutatásunk fő módszerei a vonatkozó publikációk felülvizsgálása és hivatkozása (különös tekintettel a felmérő és osztályozó közleményekre); az automatizált fejlesztőkörnyezeteknek kísérleti megfigyelése és tesztelése; valamint saját készítésű módszereink fejlesztése és felhasználása konkrét ipari projektekben a szakterületi folyamatok modellezésére és gyors alkalmazásfejlesztésre. Az értekezés felépítése Az egyes fejezetek bevezető részében tekintjük át az adott témakörre nézve a motivációnkat és a munkánkhoz kapcsolódó tudományos eredményeket. Az összefoglaló részében ismertetjük a további kutatási irányokat. Az értekezés egy bevezető részből, négy számozott fejezetből, és egy összefoglaló részből áll. A bevezetésben ismertetjük a motivációnkat és az értekezés téziseit. Az első fejezetben ismertetjük a modellvezérelt fejlesztés alapvető fogalmait, és kifejtjük a modellvezérelt szoftverfejlesztés dimenzióit, valamint az értekezés fejezeteiben tárgyalt technológiákat. Az értekezésben három tézist tárgyalunk. A 2. fejezetben, az 1. Tézissel megadtunk egy sémát technológiai sorok létrehozására, a példányosítását az ITU-T System Design Language technológiákkal, és kibővítettük a Verimag IFx 2.0 Toolbox ismert verifikációs platform technológiáival. A 3.-as fejezetbe foglaltuk be a 2. Tézist, amely eredménye egy módszertan keretrendszer létrehozására és újrafelhasználására architektúra-, tervezési- és szakterületi minták összeszövésével az MDE folyamat különböző absztrakciós szintjein. A 4.-k fejezetben a 3. Tézissel egy módszertant mutatunk be az üzleti folyamatok változáskezeléséhez MDE folyamatban. Fő eleme az üzleti folyamatok modellezése kooperációban az üzleti szereplőkkel, akik megadják folyamataikat az MDE támogatással. A módszertan végkifejlődése alkalmazással történt több Balaton Régióbeli vállalatnál. Az összefoglaló fejezetben tömören összefoglaljuk a téziseket és az elért eredményeinket kivetítve a szakirodalomból ismert létező kutatásokra a témában
13
Tézisek 1. Tézis. Egy sémát adtunk meg technológiai sorok létrehozására MDE fejlesztéshez és folyamatba integrált formális verifikáláshoz. 1.1
Séma felállítása a technológiai sorok létrehozására modellvezérelt fejlesztésekhez, a
nemzetközi távközlési egyesület által létrehozott ITU-T System Design Languages rendszerfejlesztő formális nyelvcsalád felhasználásával. 1.2
Az 1.1 tézisben javasolt séma bővítése ismert verifikációs technológiai eszközökkel, a
vonatkozó szakirodalomból és gyakorlatból. 1. Tézis közleményei: Med08b, Med10b, Med11b, Med12b. További publikációink a témában: Med05, Med07c, Lei07, Bor10, Tót07, Orb08.
2. Tézis Módszerfejlesztés keretrendszer létrehozására és újrafelhasználására szoftvertervezési minták összeszövésével modellvezérelt fejlesztésben. 2.1 architektúra
Módszert és esettanulmányt adtunk keretrendszer építésére és újrafelhasználására, a POSA2 mintanyelvek
és
GOF
programtervezési
minták
összeszövésével,
UML
alapú
modellvezérelt fejlesztésekhez. 2.2
Módszert és esettanulmányt adtunk keretrendszer és szakterületi mintanyelv építésére, ill.
újrafelhasználására, a POSA2 architektúra mintanyelvek, GOF programtervezési minták és SDL Pattern üzenetkezelési minták összeszövésével az SDL alapú modellvezérelt fejlesztésekhez. 2. Tézis közleményei: Med08, Med10. További publikációink a témában: Med06, Med07b, Med07c.
3. Tézis. Módszerfejlesztés az üzleti folyamatok változáskezelésére modellvezérelt fejlesztésben. 3.1
Egy sémát adtunk technológiai sor létrehozására az üzleti terület modellvezérelt
fejlesztéséhez, a távközlési területen szabványosított ITU-T System Design Languages nyelvcsalád elemeivel az 1.1 és 1.2 tézispontok technológiáira építve. 3.2 inspekció
Ipari alkalmazással alátámasztott módszertant adtunk az üzleti folyamatok specifikálására és lebonyolítására
kooperatív
munkaszervezéssel
folyamatgazdák,
üzleti
elemzők,
minőségfelelősök és modellfejlesztők együttműködésében a 3.1 tézispont technológiáira építve. 3.3
Ipari alkalmazással alátámasztott módszertant adtunk a 3.1 tézispont technológiáira építve
keretrendszer építésére változáskezeléshez, az üzleti folyamatok és stratégiák együttes kezelésével az érdekelt felek által. 3. Tézis közleményei: Med07, Med08b, Med10c, Med11, Med11c, Med11d, Med12, Med12c. További publikációink a témában: Óvá07, Med09, Med09b.
14
1
MODELLVEZÉRELT FEJLESZTÉS
1.1
Modellvezérelt architektúra
A Modellvezérelt Architektúra (Model-driven Architecture (MDA)) [OMG12] az Object Management Group (OMG) terméke, egy keretrendszer a szoftverfolyamat és a szoftvertermékek strukturálásához konkrét modellvezérelt módszertanok létrehozására. MDA módszertannal a szoftvertermékek elkülönülnek több szintű modellekbe a kód és platform felett [OMG00, OMG01, OMG03]. A modellek együttese meta-adatok megosztásával képezi az implementációs technológiáktól független formális rendszermodellt, amely elkülönített implementálásban, többszintű modelltranszformációkkal [Cza06, Men06] akár több lehetséges platformra is megvalósítható [Béz01c, Kar03, Mel02, Fav05, Bra12].
1. ábra MDA eszközei: fix nézőpontmodellek rétegződése (balra) és több szabvány kapcsolata (jobbra)
Az 1. ábra bal oldali részletén mutatjuk az MDA rendszerstrukturálás fejlesztési modelljét. Az MDA fejlesztés folyamatának fő szakaszait és termékeit adják az MDA nézőpontok és modellek: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM), képviselik rendre a számítás független-, platform függetlenés platform specifikus modelltermékeket [OMG00]. Az MDA modellezési technikákat adják az absztrakt eszközök: metamodell (meta-model), modell (model), modelltranszformáció minták (model transformation patterns), leképezés (mapping), űrlap (template), minta (pattern). Az 1. ábra jobb oldalán mutatjuk az MDA rendszerstrukturálás szabványait [OMG12] és kapcsolatukat. Az MDA ajánlás [OMG00] az UML nyelvet ajánlja, egyben kihagsúlyozza elvi szerepét és a helyettesíthetőség elvét. Az MDA fő szabványai [OMG12]: Unified Modeling Language (UML), Meta Object Facility (MOF), Object Constraint Language (OCL), Knowledge Discovery Metamodel (KDM), Interaction Flow Modeling Language (IFML), QVT
(Query/View/Transformation),
XML
Metadata
Interchange
(XMI),
Diagram
Interchange (DI), Common Warehouse Metamodel (CWM), Common Object Request Broker Architecture (CORBA). Az MDA módszertanok terjedésével Tho03] több OMG szabvány nemzetközi szintre emelkedett [ISO12]. 15
1.2
Modellvezérelt fejlesztés
2. ábra. MDE folyamattípusok és szerepek, tevékenységek, termékek.
A modellvezérelt fejlesztés (Model-driven Engineering (MDE)) [OMG12] szakterületi nyelvekre alapozott modellvezérelt fejlesztési módszertan az MDA elvek eszköztárával. Célja az újrafelhasználás és az aspektusok kezelése, végcélja az automatizált szoftverfejlesztés. A modellvezérelt fejlesztés folyamata lehet alkalmazás- vagy eszközfejlesztés, amely termékét együttesen alkotja a leíró modell, a mögötte álló meta-modell, a leíró modellek közötti transzformációk és a folyamatirányítás. Az MDE elvek: teljes modell-alapú reprezentáció szakterület-specifikus kezeléssel, nyílt szabványok alkalmazása, újrafelhasználás, automatizálás. Az MDE elvek egy folyamatba ötvözik az MDA irányzatot [OMG03], a Microsoft Domain Specific Modelling (DSM) elvet [MDSN12], továbbá az IBM Eclipse Modeling Framework (EMF) szabványt [ EMF12]. Az elvekhez szükséges fejlesztőkörnyezetek nagy része szabad felhasználású, nyílt forráskóddal. Az MDE folyamat kiterjed a teljes életciklusra és szoros kapcsolat van a modellkezelés a fejlesztőkörnyezetek és az alkalmazott módszerek között. Az elsődleges technikák a modellezés és metamodellezés, a modelltranszformációkkal együtt. Általuk kezelhetők a rendszerben a függőségek, amelyek adódhatnak a különböző adatformátumokból és szemantikákból
vagy
a
különböző
platform
sajátosságokból
kifolyólag,
akár
a
rendszeresemények szintjén, akár a reprezentációk különböző absztrakciós szintjén. A 2. ábrán mutatjuk be az MDE folyamatok kétféle alapvető típusát, ezek célját, valamint a folyamattípusba elkülönűlő termékek-, szerepek- és tevékenységek egymásra épülését.
16
Az MDE folyamatnak két egymásra támaszkodó jól elkülönült formája van (lásd 2. ábra): a meta-modellezés folyamata [Jéz08, Béz08] az eszközfejlesztéshez, valamint a modellezés folyamata [Riv09, Obe09, Moh09, Bun09] az alkalmazások fejlesztéséhez és karbantartásához. A kétféle folyamat az eszközeiben, a termékeiben és technikákban különbözik. Egyszerűsített megközelítéssel nézve a nyelvek oldaláról (lásd a 2. ábra alján), mindkét folyamat modellalkotások és modelltranszformációk kézi/automatikus sorozatát jelenti egy adott pontig, majd a magas szintű programozási nyelveknél ismert transzformációs szakasz következik az alacsonyabb szintű nyelvekre fordítással, egészen a gépi kódig. Ily módon az MDE szerepek elkülönülnek a gyakorlatban, a végtermékek szerint technológiafejlesztőkre és alkalmazásfejlesztőkre [Bru11, Val11, Wal11, Yue11, Kit09]. Kis szoftverfejlesztő cég esetében megtörténhet, hogy az alkalmazásfejlesztők egyben eszközfejlesztők is. Az MDE folyamatokban a szerepek a szakterület-specifikus szakértő és fejlesztő szerepek, amelyek metamodellezéssel fejlesztik a szakterület-specifikus nyelveket és fejlesztőeszközöket [Fow10, Zha08, Cla02, Bal07], továbbá modellezéssel fejlesztik az alkalmazásokat, a végfelhasználó szakértőket bevonva [Amm08, Tep09, Med12]. A fejlesztő szerepek a folyamat tevékenységei szerint sokfélék, főleg elemzők, verifikálók, szerkesztő-dokumentálók, alkalmazás-szakértők, köztes-felhasználók. Az MDE folyamatokban a termékek különféle modellek, amelyek megfelelését a vonatkozó meta-modellhez a modellezési nyelvek és fejlesztőkörnyezetek biztosítják, ezáltal hordozhatók és kódgenerálásra alkalmasak [Por09, Der11, Dis11, Wim11, Béz10]. Az un. implementációs modellből az alkalmazás előállítása manuálisan és/vagy kódgenerálással történik. Az MDE folyamat szerkezete nem kötelezően MDA mintájú. Amennyiben a szervezetnél már rendelkezésre állnak a technológiák az újrafelhasználás és az aspektusok kezelésére, az alkalmazásfejlesztés megvalósulhat komponensalapú és/vagy gyorsfejlesztés szervezésű MDE folyamatban. Az MDE alkalmazásfejlesztés eszközei olyan fejlesztőkörnyezetek, amelyek támogatják a modellezést az adott modellezési nyelvhez tartozó tudásbázis-alapú integrált szerkesztővel és egyéb modellkezelési eszközökkel. Az Eclipse szoftverfejlesztési platform a kiegészíthető keretrendszerrel [EMF12] egy irányzat és minta az el nem évülő modellvezérelt fejlesztőrendszerre. Az MDE modellkezelés technikái a diagramok, az űrlapok, a minták, a tesztek, a jelölések, a nézetek, a transzformációk [OMG03] és egyéb integráló technikák. Az MDE technológiák sokasága alakult ki az utóbbi tíz évben, mint például az IBM-nél az EMF [EMF12], a Microsoft-nál a MS/DSL [MDSN12], a kutatóhálózatokban a KERMETA 17
[KER12], AMMA [ATL12], GME [GME12]. stb. Némelyek egy fejlesztésen belül együtt is alkalmazhatók,
különböző
szinteken
vagy
csak
résztevékenységekhez,
vagy
az
alkalmazásplatformok automatizált integrálására [Izq12, Mul05]. Átfedések is kialakultak egyes de-facto megoldások között, mint az UML, SySML, BPML nyelvek [OMG12] meta-modelljei esetében [Lem10], vagy hiányosságok keletkeztek a hordozhatóság terén az XMI/DI részleges implementációk miatt [XML12], amelyek rendezése az OMG munkacsoportokban történik. Az MDE kutatások és ipari alkalmazások hangsúlyosabbak az intelligens szállítóeszközök és beágyazott rendszerek területén [Yu08, Völ10, Völ11, Led08, Per08, Bra08, Mbe10, Mal08, Cuc11]. Hatásukkal felerősödtek az MDE technológiák fejlesztései, elsősorban az aspektus modellezéshez [Roy11, Mos07, Bos11, Kra11, Gra11, Jéz03], a metamodellezéshez [Jéz08, Völ11, Bus08, Cab09, Cab11],
az automatikus modelltranszformációkhoz [Mil02, Ho99, Agr06, Kar03], a meta-
programozáshoz [Por06], a szakterület-specifikus fejlesztésekhez [Riv09, Obe08, Bun09]. Tovább fokozódott az elemzés technikáinak fejlesztése a kölcsönhatásokra és az állapotgépekre alapozva [Las08, Li08, Fra04, Sib08]. Jellemző lett az inkrementális fejlesztés és az átjárhatóság, az újrafelhasználás, a teszteset generálás támogatása [Gru08, Tep09, Amm08, Led08], a követelmények fontossága [Sal04, Sal09]. Felerősödött a transzformálás támogatása a szakterület-specifikus nyelvekről az UML nyelvre [Del08, Hei11b, Fow10, Thi08, Izu11, SDL12]. Így az MDE folyamatban, a meta-modellezés és a modelltranszformációk által (lásd 1. és 2. ábra) a szakterület-specifikus nyelvek előnyösebbek lettek, mint az UML nyelvjárások (profilok). Egyedi esetről születtek mérések, ahol a termelés időegysége 7,5-10 időegységgel csökkent [Kar11, Tol10]. Bebizonyosodott [Béz00, Béz01b, Boo04], hogy a modellek funkcionális együttműködéséhez nem elég a formai megfeleltetés a fejlesztőkörnyezetek között, hanem szükséges a szemantikus megfeleltetés, és ebben nélkülözhetetlenek a tesztelhető modelltranszformációk és szakterület-specifikus jellemzők [Cab09, Cab11, Val12, Val11, Brau12, Jéz12, Mus12]. Az MDE technológiák gyakorlati alkalmazása nehezen terjed, egyrészt mert a graduális szakmai képzésben nem jellemző az oktatása [Cab11b, Kul11], másrészt a modellezés általában nem magva a jelenlegi fejlesztéseknek [For08, Bra12], ugyanakkor a modellvezérelt fejlesztés bevezetéséhez jelentős szervezeti és szervezési változásokat kell kikényszeríteni [Whi12, Hut11, Bak05, Whi11].
Nagyon fontos, hogy az ilyen irányú tudással rendelkező szakemberek
megjelenjenek a piacon, akik elsősorban a felsővezetői stratégiák kidolgozásában hasznosíthatják tudásukat.
18
1.3
Modellek és technikák
Kutatásunk kereteinek szemléltetésére a 3. ábrán foglaltuk össze a modellvezérelt szoftverfolyamat elvi eszközeinek dimenzióit: az aspektusok az MDA architektúrával; az újrafelhasználás
a
szoftvertervezési
szoftverkomponensekkel;
valamint
az
mintákkal, MDE
modellező
fejlesztés
a
köztesrétegekkel
szakterületi
és
modellezési
eszköztárakkal. Ezeknek az eszközöknek az automatizáltsága jelentősen meghatározza az előállítható termékek körét, újrafelhasználásuk lehetőségeit, a modellezési technikákat és ezek sorrendjét a folyamatban. MDE megközelítéssel a szoftver mindig feltételezett része egy lehetséges hibrid rendszernek, és az aspektusok a meghatározóak.
3. ábra A modellvezérelt szoftverfejlesztés dimenziói
Az MDE szoftverfejlesztésben az üzleti modellt a követelménymodellek alkotják, amelyekben az architektúra megállapításához szükséges követelmények elkülönülnek a szakterületi szabványok (szabványos könyvtárak) alapján. Az architektúra modellekbe beépülnek az elemzésből a használati esetmodellek és a szakterületre jellemző platformok generikus elemei, mint például a kommunikációs modell. A tervmodellek képezik az implementáció alapját. A tervmodellekben jelennek meg a minőségmodellek, a kiemelt biztonságmodellek és egyéb szükséges modellek, mint az objektummodellek, platformmodell, felhasználói interfész modell, tesztmodell. Az implementációs modell sokféle, az automatizálástól
függően,
ahol
az
újrafelhasználásban
fontos
szerep
jut
a 19
komponenstechnológiáknak, tekintve, hogy az MDE folyamatban a dekompozicíó idejében elfogadott szemléletet az alkalmazáskomponensek integrálása jelenti, eltérően az MDA folyamattól, ahol a platform részeként jelenik meg a komponenstechnológia. Alap MDE követelmény a termékféleségek újrafelhasználhatósága és variálhatósága, mint módszerek, modellek, modelltranszformációk, modellintegrálók, kódok. Az automatizáltság és újrafelhasználhatóság végett, jellegzetesen összetett technológiákkal történik a fejlesztés, amelyben a megközelítés az „egy probléma egy nyelv” nézőpontok (MDE aspektusok) szerinti és modellintegrálás elven történik. Mindezen technológiai jellemzők által az MDE gyakorlatba ültetése függ a szervezeti képességektől. Az MDA modellezésben [OMG03] a finomítás eszközei a leképezés (mapping), amely technikái a címkézés (marking), űrlap (template), minta (pattern); a transzformáció (transformation), amely lehet manuális, számítógéppel támogatott vagy automatikus; a platform (platform), amely egybefogja az alrendszerek és a technológiák szolgáltatásait használati mintákkal és interfészekkel az alkalmazáshoz. Mindezek a szemantikus megfeleltetés többféle módozatát képviselik az MDA nézőpontok és a nézőpont rétegek között, amelyek együttesen eredményezik a modellezés menetét és a feltérképezett modellt. Az MDA pattern egy transzformációs minta a finomítás iterációjára a folyamatban, amikor a cél a PIM és PSM közötti transzformáció. A modelltranszformáció a művelet három összetevőjével zajlik – PIM, platform osztály, PSM –, a transzformációs lépés dokumentálásával együtt, amelyben a finomítás eredménye PSM, vagy szükség szerint egy új PIM, ez esetben újabb mintát kell alkotni több rétegben, mindaddig, amíg a finomítás eredménye PSM, amint ez követhető a 3. ábra MDA síkján. Fontos
szempont
platformfüggetlensége
az egy
MDA
transzformációs
konkrét
platformra
minta
alkotásánál,
vonatkozik
az
hogy
MDA
a
PIM
mintabeli
platformosztályra nézve, és csak az számít a leképezésben, hogy a modellező fejében a PIM függése nyilvánvaló legyen a platformosztályra nézve. Pl. az elosztott architektúrákban a kliens-server modellt vesszük platformosztálynak, és a szükség/lehetőség szerint jutunk egy vagy több lépésben a szakterületi működésmechanizmusok alapján a szolgáltatáselemek generikus összetevőinek leképezéséhez. A teljesen automatizált MDA architektúra szerinti fejlesztésben (CIM→PIM→PSM) a fejlesztőeszköz képes a PIM alapján, PSM előállítása nélkül is kódot generálni akár több platformra is. Ugyanakkor a hibadetektálás interakciójához a PSM generálására is képes, amely nagyfokú újrafelhasználást jelent az interfész technológiák terén. Ezt képviselik a köztesréteg technológiák, az üzleti minták, a szakterületi keretrendszerek, valamint a beépített 20
szimulációs validátorok. Ezt a jelenséget ábrázoltuk a 3. ábrán az aspektus tengelynek az origótól távolabbi két térfelén. MDE fejlesztésben többféle modellvezérelt architektúra minta alkotható a rendelkezésre álló szakterületi tudásbázisok alapján és a minőségi követelmények technológiafüggésének mértéke szerint. A szakterületi tudásbázisok birtokában a számításfüggetlen és platform független architektúra rétegek nem különülnek el élesen, és általában a platformmodellek is rendelkezésre állnak. Az ilyen folyamatban az automatizálás nagyfokú, amint azt követhetjük a 3. ábrán az újrafelhasználás tengelynek origótól távolabbi két térfelén. A minőségi követelmények technológiafüggése azt eredményezi, hogy az üzleti modell élesen beágyazott a platformmodellbe, és a követelményfejlesztés nem zárható le az implementációs technológiákról hozott döntések előtt. Ezt ábrázoltuk a 3. ábrán az aspektusok tengelyre helyezve a minőségmodell integrálását. Ilyenek általában a valósidejű rendszerek vagy a teljesítményigényes infrastruktúrák esetei, ahol – a modellvezérelt technológiák birtokában – már a követelményfejlesztés során hatékonyságvizsgálatot lehet végezni, és teszteseteket kinyerni nemcsak a funkcionális, hanem a minőségkövetelmények vizsgálatához is. A modellvezérelt folyamatban a transzformációs technikák bemeneteiként szolgálnak az üzleti-, architektúra- és tervezési minták, a technológiaválasztás, valamint a minőségi követelmények
a
megfelelés-vizsgálati
pontokkal.
A
tervezési
minták
űrlapként
alkalmazhatók manuálisan vagy eszközön belüli választással, és egyben a szerepek elhatárolásának eszközei, amelyekkel gyorsfejlesztés módszertanok szervezhetők. Nagyfokú automatizáltság esetén a kézi vagy automatikus transzformáció bemeneteit illeszteni lehet az elemző eszköz tudásbázisán keresztül.
1.4
Szabványosított szakterület-specifikus és általános célú nyelvek
Az itt bemutatott ITU-T formális és fél-formális módszerek mind jól-formált szakterületspecifikus nyelvek, amelyek célja, hogy a távközlési rendszerekben eszközei legyenek a specifikációk elemzéséhez - szimulációval, verifikálással, tesztgenerálással kiegészülve -, a teljeség és konzisztencia vizsgálatához, az implementáció létrehozásához [ITUz199] (http://www.itu.int/rec/T-REC-z). A különböző modellek létrehozásához különböző nyelvekre lehet szükség, amelyek célirányos megválasztása esetén lefedik a teljes életciklust. Többféle nyelvet tárgyalunk az ITU-T formális módszertanokból, mint a User Requirements Notation (URN), amely alkalmas, a szervezeti ok-okozati összefüggésekkel együtt a történések szimulálására (2.1.1 alpont); a Message Sequence Chart (MSC), amely alkalmas, a szereplők interakcióinak időbeli és sorrendi megjelenítésére (2.1.2 alpont); a Specification and 21
Description Langugae (SDL), amely alkalmas, a struktúra és a viselkedés modellezésére állapotgépekkel (2.1.3 alpont); az Abstract Syntax Notation One (ASN.1), amely alkalmas a funkcionalitáshoz illeszthető absztrakt adatleírásokra (2.1.4 alpont); a Testing and Test Control Notation (TTCN), amely alkalmas a tesztelés modellezéséhez és végrehajtásához (2.1.5 alpont). Az általános célú nyelvek közül - General-purpose Languages (GPL) -, a Unified Modeling Language (UML) nyelvet tárgyaljuk [OMG12], amely integrálta az előzőekben felsorolt nyelvek legtöbbjét vagy azok részeit (2.1.6 alpont), így a modellvezérelt folyamatban nyelvi szintű modellintegrátor lehet az UML. Az UML nyelv fejlesztései az elmúlt tíz évben két irányban folytak: egyrészt megjelentek az UML nyelvjárások (profilok), másrészt kidolgozták a System and Software Modeling Language (SysML) [Sys12] nyelvet az ipari fejlesztésekhez, és a Business Process Model and Notation (BPMN) [BPM12] modellező nyelvet a hálózaton kiterjedt üzleti területre, amelyek a korábban létrejött modellező nyelveken alapulnak. Ugyanakkor, az egységesítés előnyei mellett, más szempontok szerint az egységesítés számos hátránya jelent meg [Kob04], amelyek a szakterületi nyelvek fontosságát emelték ki, azokban az absztrakciós szintek növelésével. A felsorolt nyelveket a fejezet további részében röviden bemutatjuk, mert ezekre épül az általunk javasolt technológiai sor. 1.4.1 User Requirements Notation (URN) A User Requirements Notation (URN) az ITU-T szabványa [ITUz151, Amy11] (http://www.itu.int/rec/T-REC-Z.151/en) a követelményfejlesztés elvi kereteire, amely kombinálja a célorientált- és a forgatókönyv alapú elemző módszereket az üzleti logika modellvezérelt leírására. Az URN nyelv jelöléseket ad a célok, struktúrák, viselkedés, minőségi jellemzők, erőforrások, szervezési és szervezeti elemek ábrázolásához és a kölcsönhatások kiértékeléséhez. Az URN ajánlások elkülönülnek az URN-NFR, URN-FR, URN-Link tagolásba, amelyek megvalósítására külön technológiák vannak szabványosítva. Az URN nyelv [ITUz151] szabványosított részei: a Goal-oriented Requirement Language (GRL) nyelv az URN-NFR elvekhez, az Use Case Maps (UCM) nyelv az URN-FR elvekhez, az URN Link a modellek közötti átjárhatósághoz. Utóbbi nyelvi implementációs szinten valósul meg a fejlesztőeszközben, példa erre a jUCMNav [jUCM12] az Eclipse platformon. Goal-oriented Requirement Language (GRL) Goal-oriented Requirement Language (GRL) vizuális nyelv [ITUz151, OME12], alapjai az i* nyelv és az NFR keretrendszer stratégia kiértékelő mechanizmusai [ Aya05, Myl99]. A GRL szimbólumokkal specifikálni és elemezni lehet a rendszer és az érdekelt felek 22
követelményeivel az üzleti logikát. A GRL modell fő elemei lehetnek: szereplők, célok, szándékok, képességek, kapcsolatok, függőségek, hatások, cselekmények, erőforrások, stratégiák, kiértékelések és URN-Link kapcsolások a funkcionális modell elemeihez. A követelmények teljesülésének követéséhez előnyösek a GRL eszközei a stratégiák fejlesztéséhez és kiértékeléséhez. Folyik a UML profile for GRL fejlesztés [Abi09]. Use Case Maps (UCM) Use Case Maps (UCM) [ITUz151] nyelvet Buhr fejlesztette ki [Buh96], egy vizuális nyelv a struktúra és viselkedés együttes tervezéséhez, amelyben váltakoztatni lehet a dekompozíciót az eseménysorozatok ábrázolásával a nem atomi komponensekre is. A szintézis eredményének elemzéséhez az UCM modellben ok-okozati forgatókönyveket határozhatunk meg, amelyekben egy vagy több használati eset összekapcsolásával szimulációban történik a validálás. A folyamatok specifikálásának szimbólumai hasonlóak a ma elterjedt workflow szimbólumokhoz, azzal a többlettel, hogy a szervezeti jellemzők ráhelyezhetők a(z) (nemcsak atomi) eseménysorozatok szeleteire vagy egészére, reprezentációs cél szerint szervezési hierarchiákban egymásba ágyazással vagy a távoli közreműködők megjelenítésével. jUCMNav A jUCMNav fejlesztőeszköz támogatja az URN ajánlásokat, amelyek közt a legkritikusabb elem, hogy az URN modellnek az UCM és GRL diagramjai ugyanazon a modellezési felületen egy időben megjeleníthetők kell legyenek az URN Link követelményátjárhatósági szerkezettel együtt. A jUCMNav fejlesztése Eclipse alapon és szabad hozzáférésű nyílt forráskóddal történik. A technológia fenntartása intézményesített, a szakmai támogatással együtt [jUCM12]. Teljesíti az URN ajánlásokat és MDE felhasználásra alkalmas: kerete a csoportmunka szervezésnek és modell lerakat használatnak; modelltranszformációkat nyújt import-export műveletekkel, szimulációkkal, tudásbázis alapú nyelvi szerkezetekkel; továbbá megjeleníti a modellezéshez szükséges járulékos információkat, többféle szöveg és kép formátumokban; jelentéseket generál a modellösszetevőkről, különböző formátumokban. 1.4.2 Message Sequence Chart és High-level Message Sequence Chart (MSC, HMSC) A Message Sequence Charts (MSC) formális nyelv [ITUz120] (http://ww.itu.int/rec/T-RECZ.120/en), amelynek az elsődleges célja, hogy nyomkövetésre alkalmas módon, üzenetfolyamokkal lehessen feltárni, specifikálni és leírni a rendszerkomponensek időbeli kölcsönhatásait egymással és a környezetükkel. Az MSC nyelv más nyelvekkel társítva jól alkalmazható dokumentálásra, tesztelésre, szimulációra, tervezésre, specifikálásra. Történetileg az MSC az SDL részének tekinthető, 23
amelyet a nyomkövetés és követelménytervezés munkaszakaszokban használnak. Az ITU-T fejlesztette ki, és része lett az UML2.0 nyelvnek 2001 óta. High-level MSC (HMSC) nyelv segítségével az MSC specifikációk magasabb szintű vezérlési specifikációkká szervezhetők a rendszerstruktúra kommunikációs modelljének előállításához. 1.4.3 Specification and Description Language Specification and Description Language (SDL) formális nyelv a távközlési protokollok leírására, kommunikáló véges automaták segítségével az ITU-T Z.100 szabványcsalád gondozza. [ITUz100] (http://www.itu.int/rec/T-REC-Z.100/en). A nyelv összetett, az alapnyelv szabványa az ITU-T Z.101, további nyelvi konstrukciók szabványai a Z.102, Z.103, Z.104, Z.105, Z.106 (egyszerűsített nyelv, adat és műveletek kezelése, ASN.1 nyelvvel való kombinálás, közös átváltási formátum, objektum-orientált SDL). Az ITU-T Z.109 szabvány [ITUz109] az SDL nyelvhez definiált UML nyelvjárást definiálja, amely megteremtette az átjárást az SDL és az UML között. [OMG12]. Az SDL nyelv viselkedés leíró része képezi az UML2.0 verziójában az UML állapotgépet. Az SDL nyelv implementációi a Cinderella, IBM Rational Tau SDL (elődje a Telelogic Tau SDL), SafireSDL, Pragmadev SDL-RT [Tau08, Pra12, SDL12].
Az SDL alkalmazása a biztonságkritikus rendszerekben elterjedt, 1996 óta
használják a távközlési iparon kívül is, elsősorban az autó- és repülőgépiparban, az orvosi felszerelések iparágában. 1.4.4 Abstract Syntax Notation One (ASN.1) Abstract Syntax Notation One (ASN.1) nemzetközileg szabványosított leíró nyelv adatstruktúrák specifikálására, a kommunikáló rendszerek adatcseréjéhez, a magas szintű programozási nyelvek adatszerkezetleíróihoz hasonló típusokkal. Az ASN.1 formális nyelv, bármely adatcsereformát támogat (adat, hang, mozgókép). Szabványai az ISO/IEC 88241,2,3,4 és az ITU-T X.680-X.683, az ITU-T SG17 munkacsoportja felügyeli és fejleszti [ITUx680] (http://www.itu.int/rec/T-REC-X.680/en), ipari és akadémiai háttérrel [Dub00]. A nyelv konkrét szintaxisa gépi kezeléshez bitfolyamokból áll, amelyben az adat a típusával együtt továbbított, mint a típus értékkészletének egy példánya, kódolva. A kódolódekodoló szabályok szerkesztéséhez az Encoding Control Notation formális jelölés szolgál, az adatspecifikációk szoftveres validálása lehetséges. A bitfolyam-kódoló alapszabályok: Basic Encoding Rules (BER), Packed Encoding Rules (PER), XML Encoding Rules (XER). A vevő fél egy dekódolóval elvégezheti a bitfolyamoknak az absztrakt szintaxisokra fordítását. Ilyen előfordítók elterjedtek a C, Java, SQL, Cobol, stb. nyelvekhez. 24
1.4.5 Testing and Test Control Notation (TTCN-3) Testing and Test Control Notation (TTCN-3) [ITUz160, ETSI12] egy formális tesztnyelv, amelyet az ITU-T átvett az ETSI szabványosításából, amely alkalmas a reaktív rendszerek tesztelésének specifikálására és implementálására, (http://www.itu.int/rec/T-REC-Z.161/en), tesztmódszer- és protokoll független tesztsorozatok specifikálásával. Használatban van a táblázatos formájú tesztnyelv is, a TTCN-2 (Tree and Tabular Combined Notation), amelyet az ITU-T az ISO szabványosításából adaptált. A protokolltesztelésből elterjedt a szolgáltatások és platformok tesztelésére is. A TTCN-3 nyelv a C++ jegyeit viseli, tesztkövetkeztetés és futásjegyzék kezelő szerkezetekkel. Az adatdefiníciós leíró nyelv az IDL, amelyhez definiált a Java, XML és C++, C#, COBOL nyelvekkel a megfeleltetés. Fő nyelvi szerkezetek a tesztkomponensek, adattípusok, tesztadat űrlapok, tesztesetek, interfészjellemzők, beépített típusosztályok az üzenetalapú és eljárásalapú kommunikációhoz. 1.4.6 Unified Modeling Langugae (UML) A Unified Modeling Language (UML) vizuális nyelv elemzésre, modellezésre és tervezésre. Szabványai [OMG12] (http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF): az UML1.x az üzleti modellezéshez, az UML 2.0 az elosztott és egymásba ágyazott rendszerek fejlesztéséhez. Az UML módszer független, és több finomítási folyamattal alkalmas az eredmények megjelenítésére. Négy nagy csoportban összesen 13 diagramtechnika van egységesítve; a struktúra, a viselkedés, a kölcsönhatások, és az általánosabb viselkedés leírására. Felhasználásuk az MDE folyamatban függ az egyes UML implementáció mögötti, MOF (Modeling Object Facilitation) keretrendszerben létrehozott, metamodellek leírásaitól [Ben10, Obe08, Bru10, Fue08]. Az UML irányzatokra hatott az SDL nyelvnek megfelelő UML nyelvjárást adó ITU-T Z.109-es szabvány és a TTCN nyelvcsalád [ITUz160]. Az UML2.0 verziója kommunikáló automata alapot kapott: a teljes MSC-2000 nyelv lett az UML2.0 szekvencia diagram; az SDL-96 process diagram lett az UML2.0 állapotgép diagram; a kommunikáció egyértelműsítéséhez a port, interfész, jel, jellista, időzítés elemek bekerültek az infrastruktúra osztály diagramokba. Új szerkezetet kapott a nyelv szabványa, lehetővé vált a csatlakozás a nyelvjárások
(profilok)
és
egyéb implementációs
vagy felső
absztrakciós
szintű
szabványokkal. Továbbá a 2.4.1 verziótól a Diagram Definition szabvány fejlesztésével nemcsak a modell elemei, hanem a diagramban levő pozícióik is transzportálhatóvá válnak.
25
1.4.7 Object Constraints Language (OCL) Object
Constraints
Language
(OCL)
formális
specifikációs
nyelv
[OMG12]
˙(http://www.omg.org/spec/OCL/2.3.1/), amely alkalmas az UML modellekben a mennyiségi és minőségi követelmények pontosításához. Az OCL nem önálló nyelv, az OCL szöveges kifejezéseket el kell helyezni az UML modellben összefüggésben a vonatkoztatott objektum tulajdonságaival. Történetileg az IBM fejlesztette ki az UML1.1 nyelvhez a modellben előforduló üzleti logika leírására. Az OMG kereteiben az OCL2.0 nyelvet harmonizálták az UML2.0 és MOF2.0 nyelvekkel, elválasztva az absztrakt szintaxist a konkrét szintaxistól, ezzel az OCL2.0 szerepet kapott a modelltranszformációkban, beépült a MOF/QVT szabványba. Az OCL alkalmazásához típusgyűjtemény könyvtár és jól-formált szemantika rögzíti a kifejezésekben lehetséges műveleteket és tevékenységeket, valamint az OCL kifejezések lehetséges helyeit egy UML modellben. Egyszerűsített nézetben az OCL 2.0 kifejezések állandósult feltételek a modellezett rendszerelemekre nézve, vagy lekérdezések a modellben leírt objektumokról, a futásidejű korlátozások megadásához a modellben, a szimulációkhoz a konformancia tesztekhez. 1.4.8 System and Software Modeling Language (SysML) System and Software Modeling Language (SysML) [OMG12, SYS12] általános célú nyelv a rendszerek fejlesztésére. A SysML nyelv, az UML konkrét szintaxisának egy részhalmazával létrehozott, UML2.0 nyelvjárás. Sajátosan célja a követelményfejlesztés és a mérnöki elemzések támogatása. A struktúra leíró része SDL elemeket hordoz. A nyelv eszközhátterét szabványmegfelelés biztosítja az OMG XMI által az UML2.0 környeztekhez és az ISO 10303-233 adatcsere szabvány által a rendszerfejlesztő környezetekhez. MDA irányzathoz kifejlesztett nyelv, alkalmazásához a szakterületi logikákat az OMG szabványosítja. A SysML nyelven a fejlesztés elve követelmény-vezérelt és MDA. 1.4.9 Business Process Model and Notation (BPMN) Busines Process Model and Notation (BPMN) [OMG12] vizuális nyelv az üzleti folyamatok modellezéséhez (http://www.omg.org/spec/BPMN/2.0/). Az UML 1.4 verziójú tevékenység diagramból fejlődött ki az üzleti modellek létrehozásához. A BPMN harmonizált szabvány az üzleti logika modellezésére webfejlesztésekhez a Web Services Business Process Execution Language (WS-BPEL) [OASIS12] platformon. Az OMG munkacsoportjai gondozzák. Történetileg több verzió alakult ki. A BPMN2.0 verzió metamodell- és automata alapokra helyezett, kezeli az időt és a köztes állapotokat, alkalmas az üzleti folyamatok menedzselésének automatizálására modellvezérelt fejlesztéssel. 26
1.4.10 Platform leíró nyelvek Az ipari szabványosító szervezetek, mint az OMG és az ITU a platformok leírásához és a szoftverek
adott
platformra
konfigurálásához
létrehoztak
platform
modelleket
és
technológiákat. Ilyenek például a köztesréteg- és interfész leírók (CORBA, IDL) vagy az adat-, objektum-, konfiguráció leírók (CWM, XMI, ODL, DCL). Részletezésük és további kiemelt szakterületek technológiái megtalálhatók az OMG (http://www.omg.org/spec) és ITU-T (http://www.itu.int/rec/T-REC/en) ajánlásokban. 1.4.11 Formális verifikáló eszközök legszükségesebb jellemzői A formális verifikálás elméleti eszközei az automaták és a formális nyelvek [Var86]. A gyakorlatban a modellellenőrző eszköztárak támogatják a verifikálást, amelyek számos egységet tartalmaznak a bemenetek fordítására, külső/belső számítási egységeket az ellenőrzés végrehajtásához, az eredményt kivonatoló egységeket a megjelenítéshez és visszaigazoláshoz a bemenetekre [Cla09]. Az optimális verifikáló eszköztár a fejlesztés szempontjából a következő tulajdonságokkal kellene, hogy rendelkezzen [Hoa05]: (1) támogatja a többféleséget és integrálja az automatikus modellellenőrzőt más verifikáló és validációs technikákkal (2) lehetőséget nyújt a modellezés és validálás technológiáinak kombinálására, pl. nyelvi szinten nyújt hozzáférést a leírásokhoz, implementál statikus elemzést és optimalizáló technikákat (3) nyitott a modellező nyelvekre és fejlesztő eszközökre (4) tartalmaz eljárást a nem-determinisztikusság korlátozására, és kontroll végrehajtására (5) alkalmaz aszinkron kommunikációs eljárásokat nem-atomi interakciók validálásához (6) lehetővé teszi a Quality of Service (QoS) előrejelzést (7) és végül, de nem utolsó sorban, nyitott mindenféle komponensre, amely megfelelő interfésszel rendelkezik.
27
2
TECHNOLÓGIAI SOR MODELLVEZÉRELT FEJLESZTÉSHEZ
Ebben az alfejezetben kidolgozzuk az 1. tézist: 1. Tézis. Egy sémát adtunk meg technológiai sorok létrehozására MDE fejlesztéshez és folyamatba integrált formális verifikáláshoz. 1.1
Séma felállítása a technológiai sorok létrehozására modellvezérelt fejlesztésekhez, a
nemzetközi távközlési egyesület által létrehozott ITU-T System Design Languages rendszerfejlesztő formális nyelvcsalád felhasználásával. 1.2
Az 1.1 tézisben javasolt séma bővítése ismert verifikációs technológiai eszközökkel, a
vonatkozó szakirodalomból és gyakorlatból. 1. Tézis közleményei: Med08b, Med10b, Med11b, Med12b. További publikációink a témában: Med05, Med07c, Lei07, Bor10, Tót07, Orb08.
A szoftverfejlesztés automatizálásával újrafogalmazódtak a fejlesztés menetére és eszközeire
kialakult
fogalmaink.
Gyártástechnológiákból
kölcsönzött
fogalmak
jelentésmódosuláson estek át, például nem kell programozni csak modellezni, a modellből automatikusan előáll a futtatható kód. Ez téves nézet. A 2. és 3. ábrán láthatjuk a fejlesztés menete szerint, melyek a fő munkaelemek és termékek egy MDE folyamatban. A cél az lehet, hogy minél teljesebb helyes modelleket hozzunk létre, az intelligens fejlesztőkörnyezetek pedig lehetővé teszik a kód egy részének automatikus generálását. Ehhez a folyamatban nélkülözhetetlen a szakterület-specifikus rendszerfejlesztő nyelvek megléte. Mi a munkánkhoz, az általános mellett a telekommunikációs területen létrejött formális módszereket alkalmazzuk (lásd 1.5), amelyek kellően általánosak az elosztott rendszerek szoftvertechnológiai
problémáinak
kezeléséhez,
valamint
szabványkövető
az
eszköztámogatásuk. Amint azt Bezivin megállapította a 2008-as Dagstuhl-i szemináriumon [Béz08], a szoftverfejlesztés iparosításához nem elegendőek az egyéni verifikáló technológiák, mint az automatikus modellellenőrzők, statikus elemzők vagy tételbizonyítók, hanem szükség van a modellvezérelt technológiákba integrált verifikáló eszközökre és munkakörnyezetekre. Clarke, Emerson és Sifakis [Cla09] amellett érvelnek, hogy azon túl, hogy az automatikus modellellenőrzőkkel tervezési időben valósulhat meg a szoftvertermékek verifikálása a correct-by-construction módon, ebben fontos szerep hárul a specifikációs nyelvekre és eszközökre a fejlesztés korai szakaszában.
28
Az eddigi gyakorlati tapasztalataink és oktatási feladataink alapján úgy találjuk, hogy a modellvezérelt szoftverfejlesztés elvei és eszközei adnak ehhez segítséget, és megpróbálunk kellően általános és egymással harmonikus szakterületi nyelvekre alapozva, technológiai sorokat megadni. Aminek a célja az, hogy a tervezéstől a futtatható kódig adjunk a felhasználónak javaslatot a modellvezérelt szoftverfejlesztés gyakorlatához, ebben a technológiai elemek között kapcsolatot keresni, a modell validálását támogatni. Ahol lehet, megpróbáljuk elérni a modell automatikus transzformációját, egészen a kódolásig, természetesen nem mindhol fog menni, mert vannak elvi akadályok is, amelyekre rámutatunk.
2.1
Technológiai sor séma modellvezérelt fejlesztésekhez
A gyakorlatban a projektvezető egy projekt indítása előtt kell, hogy már ismerje milyen folyamatelemek szükségesek projektteljesítéshez. Ugyanakkor alaposan ismernie kell a fejlesztőkörnyezeteket, valamint a kereskedelmi és a szabadon felhasználható eszközök hatékonysági mutatóit. A modellvezérelt fejlesztésben a modellezés jelen van a szoftver életciklus egészében, a követelménygyűjtéstől az implementálásig, és a fenntartásban is. A folyamatot támogató technológiák teszik lehetővé a modellvezérelt elvek megvalósítását. Az újrafelhasználáshoz keretrendszerek, modell- és komponens lerakatok szükségesek. Az újrafelhasználást megkönnyítik a szabványtámogatású technológiák. Az aspektusok modellezéséhez többféle nyelvi
implementáció
lehetséges
a szükséges
támogató
tudásbázisokkal
modellek
ellenőrzéséhez és modelltranszformációkhoz. Ezekből a fejlesztési követelményekből egy hosszú életciklusú modellvezérelt fejlesztéshez a következő sémát állítottuk fel a technológiai sor elemeire: 1. Szakterületi modellező nyelvek (DSML) 2. UML és nyelvjárásai 3. Szabványok 4. Programozási nyelvek 5. Modellellenőrzők 6. Modelltranszformációk 7. Dokumentálók 8. Kódgenerálók és Modellintegrátorok 9. Telepítők és konfigurálók. Az 5.-9. elemek az automatizált tevékenységek technológiáit jelentik. Ezek a követelmények mutatják, hogy az MDE technológiákkal történik az automatizált szoftverfejlesztés. Az 1.-9. követelményekben a szabványok és a szakterületi nyelvek jelenítik meg az aspektusokat és az újrafelhasználást. A szabványok és a szakterületi nyelvek a fejlesztés automatizálásának meghatározó elemei. A 4. ábrán bemutatjuk az MDE technológiai sor séma és a fejlesztés fő tevékenységeinek kapcsolatait és egymásba fonódását. Ellipszisben ábrázoltuk a tevékenységeket, lekerekített téglalapban az automatizáló technológiákat az egyes tevékenységekhez. Az egymásra helyezéssel azt fejezzük ki, hogy az intelligens fejlesztőeszközök alkalmazásához és 29
működtetéséhez elengedhetetlen a képzett emberi munka a technológiák konfigurálásához és összeillesztésére egy platformra nézve.
4. ábra Elvi technológiai sor séma a modellvezérelt fejlesztésekhez: alaptevékenységek (ellipszisben) és a fő technológiai összetevők kapcsolatai
A technológiai sor sémában a változó elemek: a szakterületi modellező nyelvek, az egységes modellező nyelv, a programozási nyelvek, a szoftver komponensek, valamint a szabványok (4. ábra). Ezek azok a tényezők, amelyek, a fejlesztés lehetséges technológiáit behatárolják, egyben támogatást nyújtanak az egyes modellkezelési tevékenységekre nézve. A szoftverfejlesztésben a technológiák célja az automatizálás, amelynek eszközei a modellellenőrzés, modelltranszformáció, dokumentálás, teszteset generálás, modellintegrálás, kódgenerálás, modell alapú tesztelés (4. ábrán ellipszisekben). A szabványok megkerülhetetlen technológiák a modellvezérelt fejlesztésekben, legyen a fejlesztés tárgya akár absztrakt gépek létrehozása, akár ezek felhasználásával alkalmazások fejlesztése. A szabványok jelentősége elsősorban a funkcionális együttműködés biztosítása, amelyhez nyelveket, szoftverfejlesztési tevékenységeket és egyéb szakterületi sajátosságokat szabványosítanak. Ugyanakkor a szabványosítással közzéteszik a szakértők tudását is. A szabványok eszközei az újrafelhasználásnak és az aspektusok specifikálásának. A technológiai sor szervezésében a formális módszerek és egyéb nyelvi technológiák szabványait helyezzük előtérbe, mivel a formális módszereken alapuló eszközök fejlődésével lehetséges a szoftverfolyamat szakaszaiban a verifikálás és a validálás. A fejlesztő környezetek szabványtámogatásai hordozhatóvá teszik a szoftvertermékeket, és biztosítják a szoftver életciklusának meghosszabbítását. A modellvezérelt fejlesztésekben a formális módszereket többnyire az egységes modellező nyelv és a szakterületi modellező nyelvek 30
képviselik. A szabványosított nyelvek alkalmazásának további előnye, hogy a szabványos formális módszerekkel vannak megvalósítva, illetve azokra támaszkodnak a közzétett szakterületi követelmények szabványai és az újrafelhasználható szakterületi ontológiák. A létrehozott technológiai sor séma alkalmazásakor a séma változó elemeihez kell kijelölni konkrét elemeket. A kijelölés folyamata egyben stratégiafejlesztés és döntés előkészítést jelent a szükséges felkészüléshez a modellkezelés tevékenységeire és a folyamat szervezésére. A szakterületi nyelvekre az ITU-T rendszerfejlesztő nyelvek családját (ITU-T System Design Languages) javasoljuk, amelyek formális és fél-formális módszerek, jelentősen elterjedtek az ipar, a gyógyászati segédeszközök és a tudomány területein [ITU12] (lásd. 1.4). 2.1.1 Elvi technológiai sor séma példányosítása formális nyelvcsalád felhasználásával Az előző fejezetekben kihangsúlyoztuk, hogy az MDE termékek teljes életciklusa alatt szoros a kapcsolat a modellkezelés, a szakterületi nyelvek, az egységes modellezési nyelv és a szabványok között, amint az elvi technológiai sorról a 4. ábrával szemléltetettük ezt. A fejlesztésben és az újratervezésben egyaránt fontos szempont az újrafelhasználás, amely vonatkozhat szükség szerint absztrakt és konkrét, és/vagy általános és specifikus elemekre a szoftverfolyamat több szakaszán. A gyakorlati feladatok megoldása során megtapasztaltuk, hogy a modellvezérelt technológiák megválasztása jelentősen befolyásolja az újrafelhasználás lehetőségeit a teljes életciklus alatt [Med07, Med11c]. A tapasztalataink alapján javaslatot tettünk konkrét technológiai sorokra és azok példányosítására. A technológiai sor séma példányosításához megadjuk a nyelvek közötti kapcsolatokat a modellezésre nézve az ITU-T rendszerfejlesztő nyelvekkel (http://www.itu.int/rec/T-RECZ/en), amelyek lefedik a teljes fejlesztési folyamat tevékenységeit, a szabványosításuk felügyelt és harmonizált az OMG specifikációkkal. Az 5. ábrán megadtuk az ITU-T és egyéb nyelvek közötti kapcsolati gráfot. A csomópontokban vannak a távközlési szakterületi rendszerfejlesztő nyelvek, az egységes modellező nyelv, továbbá a programozási nyelvek. Az éleken azt ábrázoltuk, hogy az egyes formális és fél-formális módszertanok, amelyek különböző rendszeraspektusok modellezésére alkalmasak, miként kapcsolódnak az absztrakció/konkretizáció fejlesztési dimenzió mentén. A
jelölés
a
nyelvek
közötti
kapcsolatokra
a
következő:
m – modellezés
és
modelltranszformációk, i – input (bemenet) a szintaktikai szintű beépülés, c – kontroll a szemantikai szintű beépülés. Az implementáció közeli nyelvek képviselik az objektum-, adat-, és viselkedés modellező nyelveket (SDL, ODL/DCL, ASN.1, TTCN). Ezeket megelőzik a kapcsolati gráfban a felhasználói követelmények és az elemzés szempontjainak ábrázolására 31
alkalmas, magasabb absztrakciós szintű specifikációs nyelvek (URN, MSC, UML). Az m0 éltől az m5 élig tartó utak a modellezés folyamatát írják le, különböző variációs lehetőségeket felkínálva az implementációs modell előállításáig. A technológiai sort szervezhetjük több lehetséges módon, a célhoz legmegfelelőbb összetétellel.
5. ábra Technológiai sor séma példányosítása az ITU-T System Design Language és egyéb nyelvek kapcsolataival az absztrakció/konkretizáció fejlesztési dimenzió mentén
Az 5. ábrán a vonalak alakjával jelöltük meg az egyes nyelvek kapcsolatának típusát, amelyek meghatározzák az átmenetet az absztrakciós szintek között:
modelltranszformáció: folytonos vonal jelzi a modelltranszformációval képezett átmenetet (automatikus/manuális);
egymásba épülés (bemenet): központozású vonal jelzi az input dokumentum szerepben az előállított részeredmény szintaktikai szintű beépülését a következő eszközbe;
kontroll-monitor: a szaggatott vonal jelzi, a kontroll dokumentum szerepben az előállított részeredmény szemantikai szintű beépülését a következő eszközbe. A legmagasabb absztrakciós szinten az URN specifikációk vannak a felhasználói
követelmények modellezésére. A szimulációkkal validált GRL és UCM modellek modelltranszformációkkal kapcsolódnak az MSC, SDL, UML, XML, TTCN nyelvekhez. Az UCM modellek beépülnek input dokumentumként az ASN.1, OCL, UML Profile modellezésbe. Kontroll dokumentumként kapcsolódnak a TTCN tesztsorokhoz és az UML nyelv AD, DD, TD eszközeihez. Az URN magas absztrakciós szintű technikáival, bármely szakterületre fejleszthetünk üzleti modellt. Az elemzésben és tervezésben az MSC/HMSC modell többféle módon beépíthető az UML modellbe (osztály-, szekvencia-, tevékenység diagramként). Az MSC és HMSC lehetnek a fejlesztés első eszközei az üzleti modell fejlesztéséhez más szövegkezelő eszközökkel együtt, vagy képezhetik a gyorsfejlesztésnek az alapelemeit, a szakterületen 32
szabványosított
követelményspecifikációk
és/vagy a
szakterületi
mintagyűjtemények
birtokában. Az UCM és MSC modellek transzformálhatók az SDL statikus és dinamikus leírásokba [Bor97]. Egyes területeken az UML fejlesztést felgyorsítja és hatékonyabbá teszi a validált SDL modellek transzformálása UML osztály-, objektum-, állapotgép diagramokba. Az ASN.1 deklarációkkal gyorsul és egyszerűsödik a validáláskor a generált tesztesetek beépítése a TTCN modellekbe. A validált SDL specifikáció képezi az alapot a C++ vagy JavaScript nyelvű forráskód és a TTCN tesztgeneráláshoz. Az automatizált kivitelezés több platformra
lehetséges
objektum- (ODL),
konfigurálás- (DCL),
interfész
(IDL) leíró
nyelvekkel. A részletes tervezésben az ASN.1 és OCL nyelvek több ponton megjelenhetnek a technológiai sorban, adattípusok és szabályok szerkesztéséhez. Modelltranszformációval kapcsolódnak az XML nyelvhez és az implementációs nyelvek többségéhez. Az ASN.1 modulok input dokumentumként beépülnek a TTCN, SDL modellekbe. Az implementációs nyelvek adják a legtöbb variációt a technológiai sorban, a követelmények irányába és a kódgenerálás irányába is. Az UML minden technológiával kapcsolatban van, az ASN.1 kivételével, amelyhez OCL közvetítéssel kapcsolódik. A szakterület-specifikus modellező nyelvek (DSLM) szerepe megnőtt az UML nyelvjárásokkal szemben, a MOF alapú Eclipse és Kermeta modelltranszformációs automatizálások eredményeként [Jéz08] (l. a 2. ábra alján), elsősorban a valós-idejű és beágyazott rendszerek fejlesztésében [Obe10]. A 6. ábra mutatja az 5. ábra kiegészítését a szakterületi modellező nyelvekkel, a metamodellezés szabványaival és UML nyelvjárásokkal, amelyek kibővítik az ITU-T System Design Language modelltranszformációs lehetőségeit az MDE fejlesztésekben.
6. ábra A technológiai sor séma példányosításának (5. ábra) kibővítése az újrafelhasználást elősegítő szabványokkal
33
2.1.2 Technológiai sorok specifikációi és példányosításai A 4. és 6. ábrák elvi sémái alapján két technológiai sor specifikációit (F1A, F1B és F2) adjuk meg a 7. ábrán. Ezek példányait az alkalmazások fejlesztése során használhatjuk.
7. ábra Technológiai sor specifikációk az ITU-T System Design Languages, UML, DSML nyelvekre alapozva
A specifikációban alkalmazott jelölések: a sor kezdete a pont, a haladás iránya előre, visszacsatolást nem alkalmaztunk, a sor vége a függőleges sorlezáró, az x jel a technológiai eszközöket mutatja, a variációkat a feltétel nélküli leágazások és csatlakozások mutatják. Az F1 sorban a távközlés konkrét technológiai eszközeivel javasolunk lehetséges technológiai sorokat variációs nézetben, a távközlés és a beágyazott rendszerek modellvezérelt fejlesztéséhez az UML és az ITU-T System Design Languages nyelvekkel. Az F2 sort szakterületi fejlesztésekhez javasoljuk URN követelményfejlesztéssel és DSML és/vagy UML implementációs technológiákkal. Az F2 specifikációban a változatok viszonylagos egyszerűsége a DSML gyűjtőnévből
adódik, amely szakterülettől függően lehet
implementáció közeli nyelv, amit kombinálunk UML nyelvi elemekkel vagy sem, de ugyanúgy lehet egy több eszközből álló szakterületi nyelvcsoport is variációs lehetőségekkel a fejlesztés menetére, akárcsak az F1 sorban a távközlési szakterületi nyelvek esetében. Az 1. Táblázat mutatja az F1 és F2 technológiai sor specifikációk példányait, fejlesztésre (előretervezés) (1-10. sor), újratervezésre (11. sor), kódvisszafejtésre (12. sor). A modellvezérelt fejlesztésnek a természetes menete az előretervezés (forward engineering) típusú fejlesztési folyamatnak felel meg, és a modelleket mindig a követelményekből kell levezetni [OMG00]. Az újratervezés (re-engineering) menetét koncepcionális tervezésben érdemes szervezni [Myl08, Lam09], erre adtunk javaslatot a harmadik tézisben. Javasoljuk mindig a jelenlegi állapot URN követelményspecifikálásával indítani. Ezt követi a jelenlegi 34
állapot
elemzése
a
szükséges
változáskezeléshez
[Med07,
Med12].
Elemzés
utáni
optimalizálással történik a jövőbeni állapot specifikálása és a követelmény modell előállítása [Med12],
majd a kivitelezés a meglévő komponensek felhasználásával, előretervezésben. A
kódvisszafejtés a régi szoftverek alapján előállított struktúra és viselkedés modelleket jelenti. Az URN/AoURN alkalmas kódvisszafejtésre [Amy02], ezért a kódvisszafejtés (reverse engineering)
menetére a régi szoftverkomponensek URN követelményspecifikációjának az
előállítását javasoljuk és az erre alapozott modellvezérelt újratervezést. 1. táblázat A 7. ábra F1 és F2 technológiai sor specifikációk példányai
1. sor fejlesztésre: URN – MSC – (HMSC) – (ASN.1) – SDL/UML – TTCN - C++/Java 2. sor fejlesztésre: URN - UML2SDL – (ASN.1) – SDL – TTCN - C++/Java 3. sor fejlesztésre: URN – MSC - SDL2UML – (ASN.1) – UML – TTCN - C++/Java 4. sor fejlesztésre: szakterületi szabvány – MSC – HMSC – SDL/UML – TTCN - C++/Java 5. sor fejlesztésre: ETSI szabvány - ASN.1 – SDL – TTCN - C++/Java 6. sor fejlesztésre: ETSI szabvány – UML2SDL - (ASN.1) – SDL – TTCN - C++/Java 7. sor fejlesztésre: beágyazott r.: URN – MSC – HMSC – SDL-RT – TTCN - C++/Java 8. sor fejlesztésre: URN – OCL – UML - C, Java, egyéb 9. sor fejlesztésre: AoURN – OCL – UML – DSML - C, Java, egyéb 10. sor fejlesztésre: URN – OCL – UML – DSML - C, Java, egyéb 11. sor újratervezésre: URN+ változáskezeléssel + fejlesztés 1-9 példányai 12. sor kódvisszafejtésre: kód - URN + újratervezés
A követelménymodellhez minden esetben az URN vagy AoURN technológiákat javasoljuk, amelyekkel célorientált és forgatókönyv alapú követelménymodellt lehet fejleszteni, amelyből automatikus modelltranszformációval lehet az elemzéshez és teszteléshez modelleket előállítani
[Lam09,
Liu01,
Got94,
Amy05,
Dam06,
Mus12,
Sha90,
Vrb12].
Az
URN
követelménymodellek átszabásával előállíthatók az architektúra és telepítés modellek is [Buh98],
minőségdokumentumokat származtathatunk az információs rendszerekre [ Aka08].
UML nyelvjárás (profile) készül az automatizálásához [Abi09], támogató eszköztára az jUCMNav az XML transzformációt metamodell alapon nyújtja, ennek előnye a többparadigmás fejlesztésben mutatkozik meg és az újratervezésekben [Ama10], forgatókönyv alapú validálás lehetséges [Arn10, Uch03]. Az 1. sor az F1A specifikáció példányosítása fejlesztésre, URN technológiákkal a követelménymodell előállítására, amelyből automatikus transzformációval előállított MSC modellek és az opcionálisan előállított HMSC és ASN.1 modellek együtt képezik az elemzés eszközeit és a bemenetet az SDL vagy UML alapú tervezéshez. Az architektúra modelleket URN specifikációkból transzformálva finomítjuk, SDL és/vagy UML specifikációkban. Az 35
SDL állapotgépekkel az implementáció modelljét állítjuk elő, amelyből automatikus kódgenerálás lehetséges C nyelvjárásokra és Java nyelvre. A teszteléshez TTCN nyelven lehetőség van a tesztesetek generálására a követelménymodellből és az implementációs modellből is. A 2. sor az F1A specifikáció példányosítása, amely abban különbözik az 1. sortól, hogy a követelménymodellből UMLSD modelleket transzformálunk, majd a korábbi UML specifikációk újrafelhasználásával az UML2SDL szabvány alapján automatikus vagy manuális transzformációval kapjuk az SDL struktúra modelleket. A 3. sor az F1A specifikáció példányosítása, amelyben az UML implementációs technológiákkal jutunk kódgeneráláshoz. Az MSC és SDL az elemzéshez [Amy03, Amy99] a létező automatizált eszköztárakkal nyújt többletet az UML lehetőségeinél. Az UML struktúra modelleket az SDL2UML szabvány alapú transzformációkkal finomítjuk. Abban különbözik az 1. sortól, hogy a meglévő SDL komponensek specifikációit újrafelhasználással illesztjük az UML implementációkra alapozott alkalmazásfejlesztésbe. A 4. sor az F1A specifikáció példányosítása, amelyben a szakterületi szabványokban létrehozott követelménymodellekre alapozzuk az MSC elemzést, a további szakaszokban megegyezik az 1. sorral. A 5. és 6. sorok az F1B specifikáció példányosításai fejlesztésre, amelyekben a validált követelménymodellt
jelentik
az
Telecommunication Standardisation
MSC,
SDL,
Institute
ASN.1
modellek
(ETSI) protokollok
az
European
szabványaiban. A
technológiai sor további szakaszai megegyeznek az 1. vagy a 2. sor példányokkal. Az 1.-6. technológiai soroknak megfelelő gyakorlatok elterjedését az irodalmak a távközlési és az orvosi műszerfejlesztések területén mutatják ki [Whi12, Bec09]. A mobil kommunikáció szabványaihoz újrafelhasználható validált követelménymodell társul [ETSI12]. Például
a
protokoll
fejlesztésekhez
ETSI
tagsággal
és
a
szabványtámogatású
fejlesztőeszközökkel, az SDL/MSC újrafelhasználható modellek birtokában a PIM transzformációkkal indulhat a részleges tervezés. A teszteléshez a fejlesztőeszközbe implementált szabványalapú tesztelési csomagokkal történik a validálás. Az ETSI tagság hiányában
az
újrafelhasználható
modellek
nem
állnak
rendelkezésre,
ezért
a
követelménymodellek fejlesztéséhez a szabvány a követelmény leírást jelenti együtt a közérthetőséghez közzétett MSC/SDL dokumentálással, majd inspekciós validálást jelent a szabványszöveg alapján végzett tesztelés. A 7. sor az F1A specifikáció példányosítása, amelyet a beágyazott rendszerek fejlesztésére javasolunk. Ebben az SDL-RT technológia kerül alkalmazásra, amely egy részhalmaza az 36
SDL nyelvnek a valósidejű kommunikációs események specifikálására. A sor egyéb technológiái megegyeznek az 1. sorral. Ehhez a technológiai sorhoz fontos eszköztár a PragmaDev Real Time Developer Studio, automatizált elemzési és tesztelési támogatással [Pra12].
Elterjedten alkalmazott eszköztár az UML a dokumentációk, SDL kódgenerálás,
Matlab szimulációk eszközeként, a távközlési, a beágyazott szoftverekkel automatizált rendszerek és az intelligens járműgyártó ágazatokban [Pra12b]. A 8. sor az F2 specifikáció példányosítása jól szabályozott területekre, mint a távközlés, járműipar, orvosi műszerek területén, az UML alapú fejlesztésekhez OCL szabályok alkalmazásával az URN követelmény modellekben és az UML modellekben. A kódgenerálás alapja az UML/DSML modell. A 9. és 10. sorok az F2 specifikáció példányosításai összetett szakterületi fejlesztésekhez, ahol a követelménymodellben URN/AoURN technológiákkal történik és a szakértők bevonásával az aspektusok elkülönítése. A szakértők több szakterületi modellező nyelv és/vagy az UML nyelv alkalmazásával állítják elő az implementációs modellt, amelyhez a transzformációk sorozata és a modellek integrálása eszközigényes feladat. A 11. technológiai sor példányt újratervezéshez javasoljuk [Med07, Med12]. Az optimalizálás döntései által érintett komponensek módosításához/fejlesztéséhez a fejlesztés típusa szerint az 1-10. technológiai sor példányokat javasoljuk. A 12. technológiai sor példányt kódvisszafejtésre alapozott fejlesztéshez javasoljuk, ahol a szoftverekből kódvisszafejtéssel kinyert URN modellek képezik a változáskezelésben a jelenlegi helyzet specifikációját. Ezzel a kódvisszafejtésre alapozott fejlesztés a 11. sorban megadott újratervezéssé változik. 2.1.3 Példa az 1. technológiai sorral a technológiai sorok alkalmazására komponens alapú szoftverfejlesztéshez A komponens alapú szoftverfejlesztési módszertanok alapvetően modellvezéreltek [Che09]. Ilyen például a KobrA módszertan [Atk02, Gro05], amely UML modellezést és modell alapú tesztelést javasol [Gro05]. A KobrA módszertan a fejlesztés folyamatát három dimenzióban vezeti,
minden
dimenzióban
két
irányt
követ:
kompozíció/dekompozíció,
absztrakció/konkretizáció és általánosítás/specializáció (7.2 Melléklet 35. ábra). Ezekben a dimenzió irányokban a KobrA specifikációk hat különböző modellterméket tartalmaznak, amelyek
kellően
szétválasztják
a
nézőpontokat
ahhoz,
hogy az
újrafelhasználás
megvalósulhasson: szerkezeti modell, viselkedés modell, funkcionális modell, nemfunkcionális követelmények specifikációja, minőség dokumentáció, stratégiai döntések 37
modellje. Ezek a termékek négy nagy fejlesztési szakaszban kerülnek előállításra és finomításra: a kontextus megvalósítása, példányosítás specifikációja és megvalósítása, a komponens modellezése. Ezek fejlesztéséhez a technológiai sor összetételére mi az 1. technológiai sor példányt javasoljuk a 2. táblázatból. Az alkalmazás fejlesztés menete a KobrA módszertant követve az 1. technológiai sor eszközeivel a következőképpen zajlik: Alkalmazásfejlesztés menete az 1. technológiai sor példány elemeivel a KobrA módszertanra építve A. Kontextus megvalósítás A1.
A megrendelővel történt konzultáció és övetelmények előállítása URN eszközeivel.
A2.
A kész komponensek adaptálásáról URN eszközeivel előállítani a stratégiákat,
költséghatékonyságra törekedve, szükség szerint forgatókönyveket készíteni a megrendelő tájékoztatására a döntéshozatalhoz. A3.
URN eszközeivel előállítani a komponensek faszerkezetét.
B. Komponensek újrafelhasználása és integrálása B1.
Az A1 specifikus követelményekre vonatkoztatva GRL célfában modellezni a
komponens tulajdonságait a döntéshozatalhoz az adaptálásról. B3. Komponensek adaptálása B3.1. Komponens specifikáció alapján a konfliktusok kezelése finomítás szétválasztásával több lépésre az UML CD, UML SD, MSC, HMSC, SDL Block Type eszközökkel. B3.2. Komponens
adaptálása
burkoló
komponens
specifikálásával:
URN,
UML CD,UML SD, MSC, HMSC, SDL Block Type eszközökkel B4.
Hiányzó komponesek fejlesztése: URN, UML CD, UML SD, MSC, HMSC, SDL
Block Type eszközökkel. B5.
A hiányzó komponenst a KobrA módszerrel kifejlesztjük, majd a kész komponenst
felhasználjuk. A fenti A. és B. lépéssorozatokkal megadott technológiai sor alkalmazását összefoglaltuk a 2. és 3. táblázatban a fejlesztés szakaszaira csoportosítva. 2. táblázat A komponens alapú alkalmazásfejlesztés szakaszai az 1. technológiai sorral
Specifikálás URN, AoURN MSC, SDL, UML
Megvalósítás SDL, UML
Implementálás SDL, UML
Kivitelezés Kódgenerálás
Tesztelés URN, ASN.1, MSC, TTCN
Telepítés URN, UML, egyéb
3. táblázatA komponens újrafelhasználásának szakaszai az 1. technológiai sorral
Specifikálás URN (GRL, UCM, URN Link)
Újrafelhasználás URN, UML CD, SD MSC, HMSC, SDL Block Type
Telepítés URN, UML, egyéb
38
2.2
Technológiai
sor
kiegészítése
létező
verifikációs
technológiákkal
integrált formális verifikáláshoz Kutatásunkban megállapítottuk, hogy az egyéni verifikáló munkakörnyezetek nagyon hasznosak az architektúra-döntések támogatására a korai fejlesztési szakaszokban [Med07c, Med09c, Med10b],
amikor az absztrakciós szint magas, és holtpontok alakulhatnak ki a hiányos
szakterület jellemzők miatt. Ilyen esetekben a statikus elemzés kombinálása az automatikus modellellenőrzéssel eléggé szemcsézett architektúra modellt eredményez. A mi célunk az, hogy az inkrementális verifikálás technológiáit felhasználhassuk a korai fejlesztési szakaszokban. A verifikálás sikere attól függ, hogy a komponensek és a komponensekből álló rendszerek specifikálásához társulnak-e használható verifikációs módszerek és eszközök. MDE folyamatban a verifikálás eredménye a rendszer konzisztenciájának kimutatása és szükség esetén a modell újraszervezése. A verifikálás során információt kaphatunk a tesztadatok generálásához is. A 8. ábrán mutatjuk be a modellvezérelt fejlesztésben megfelelő szolgáltatásokat nyújtó modellellenőrző kapcsolatait a modellezés technológiáival. Az ábrán feltüntetett modellellenőrzők szolgáltatásait kísérletben vizsgáltuk. A folyamatba illeszthető formális
modellverifikálás
során
kinyerjük
az
állapottérképet
automatikus
holtpontvizsgálattal, amelynek elemzésével interaktív szimulációt szervezünk. A szimuláció eredményeként a hibahelyzetekre a modellellenőrző un. ellenpéldát szolgáltat és egy átszabott modellt,
amit
a
folyamatban
modelltranszformációs
lépésben
alkalmazhatunk.
A
transzformált modell és a hibaesetekre szervezett tesztadatok képezik a bemeneteket a modellalapú tesztelésben.
8. ábra A formális modellellenőrzők szolgáltatásai és integrálásuk a modellvezérelt fejlesztésbe
A modellellenőrzők használatakor felléphet az úgynevezett állapotrobbanás, amelynek kiküszöbölésére többféle módszert dolgoztak ki [Cla96, Koz08, Cla00, Ber07, Cho07, Bri98]. Vizsgálatunk kiterjedt a modellező eszköztárba integrált automatikus modellellenőrzők és az önállóan
alkalmazható
modellellenőrzők
használatának
kombinálására
a 39
modelltranszformációs
lépésekben,
amely
során
a
statikus
elemzéssel
kapott
modelltranszformáció eredményeként jelentősen lecsökken az állapottér ahhoz, hogy az automatikus holtpontvizsgáló eszközzel nyerjünk tesztadatokat a modell jobbítására [Med09, Med10b].
Arra adtunk módszert és választottunk ismert technológiákat kísérleti úton, hogy kombinálhassuk a statikus elemzőket és az automatikus modellellenőrzőket a modellezés formális verifikálására az elemzés és a részletes tervezés idején. Ehhez kísérletet folytattunk oktatási környezetben a verifikáló eszközöknek a folyamatba integrálásával, nevezetesen az IFx-CADP- SPIN kombinálásával [Med08b], NuSMV [NuSMV12] konzisztencia vizsgálattal [Bor10, Bor11, Gra98],
VIATRA [Med07b] modellverifikálással. Javaslatot adtunk az IFx 2.0
Toolbox [IFx12] integrálására a modellezés technológiáiba a statikus elemzők és automatikus modellellenőrzők kombinálására, és a modelltermékek elkülönített verifikálására verifikátor szerepben is [Med10b, Med12b]. Az általunk javasolt technológiai sor továbbfejleszthető a valós idejű elosztott rendszerek modellezés és formális verifikálás technológiával (DREAM [DRE12] és AML [AML12]), amelyek integrálják az IFx eszköztárat. 2.2.1 Verimag IFx eszköztár alkalmazása integrált verifikálásra Az IFx eszköztár [IFx12] (7.2 Melléklet 36. ábra) teljesíti a formális verifikáló eszközök követelményeit (lásd 1.5.11) [Hoa05]. Az IFx integrálja a verifikálás folyamatába az elosztott rendszerek verifikálására létező számos open source verifikáló eszközt, mint például SPIN, Construction and Analysis of Distributed Processes (CADP), Symbolic Model Checker (SMV),
KRONOS és más eszközök [SPIN12, CADP12,NuSMV12, KRONOS12]. IF nyelvű modellekre az IFx statikus elemzője szolgáltat modellredukciót, amelyhez a CADP eszköztárban temporális logikákkal szabályok adhatók meg, és az IFx statikus elemzőjéből nyert modell validálható. A modellek származhatnak SDL, UML és egyéb szakterületi nyelvek technológiáiból. Az SDL, UML és egyéb modellek az IFx transzformációs eszköztárával adaptálhatók az IFx környezethez. Az IFx eszköztár nyelve az IF (Interchange Format) nyelv, amelyet a Verimag Grenoble hozott létre, hogy a formális nyelvek és eszköztárak összekapcsolására legyen egy közös, köztes nyelv. Az IFx végrehajtó eszköztára és az ehhez kapcsolódó validáló és verifikáló eszköztárak sok technológiai kombinációt tesznek lehetővé, és újabbak kiépítésére adnak lehetőséget (7.2 Melléklet 36. ábra). Az állapotrobbanás kezelése az IF eszköztárban redukciós technikákkal történik az IFx statikus elemző eszközével. Az IFx eszköztár I/O
40
kommunikációs automata alapú, amelynek jelentősége a valósidejű mechanizmusok kezelésében mutat előre. Nem vizsgáltuk a minőségi mutatók előrejelzésének módját az IFx eszköztárral. A fellelhető irodalmak alapján mások sem végeztek ilyen irányú kísérletet. Az IFx alkalmazásával [IFx12, Boz04, Obe06, Obe03] lehetővé válik a létező heterogén verifikáló eszköztárak összekapcsolása modell-alapon, továbbá a C++ nyelvű komponensek illesztése a verifikált modellhez együttes verifikálásra. Javaslatot adtunk az IFx alkalmazásával a szoftverfolyamatba szervezésére integrált modellellenőrzéshez, ahol a szerepek elválasztásában a verifikátor munkaelemek elkülönítését az IFx 2. eszköztárra alapoztuk, amelyet kombináltunk a kereskedelmi szoftverekbe beépített automatikus modellellenőrzőkkel [Med10b, Med11b]. A tapasztalatok alapján általánosítottuk a módszert, és megfogalmaztuk javaslatunkat az integrált verifikálás folyamatszervezésére lebontva lépéssorozatokba és munkavégzőkre, amelyet az IFx 2.0 eszköztár és a Telelogic Tau fejlesztő automatikus modellellenőrzőjének kombinált alkalmazásával szemléltettünk [Med10b, Med12b].
9. ábra Technológiai sor séma kiegészítése modellezésbe integrálható verifikáló/validáló eszközökkel
Az IFx 2.0 eszköztárat javasoljuk beillesztésre az 1.1 tézispontban javasolt technológiai sor sémába integrált modellverifikáláshoz, mivel szolgáltatást nyújt további technológiák integrálásához, valamint a C++ nyelvű komponensek illesztéséhez. A 9. ábrán szemléltetjük a 6. ábrán bemutatott technológiai sor kiegészítését ismert verifikációs és validációs technológiákkal. Az ábrán halványzöld ellipszisben egy csoportba fogtuk be a Verimag IFx 2.0 Toolbox, SPIN, CADP, modellverifikáló eszközöket a modellezésbe integráláshoz, a
41
TTCN-3 automatizált tesztelési eszközt és az UML-TP elvi eszköztárt az UML modellalapú teszteléshez. A következőkben az IFx 2.0 eszköztár felhasználását taglaljuk. A Verimag Ifx 2.0 Toolbox eszköztárat (7.2 Melléklet 36. ábra) az MSC, SDL, UML, DSML, DSL, C modellezés folyamatába integrálhatjuk az automatikus modellellenőrzővel kombinált verifikációkhoz. Javasoljuk az Ifx Holtpontvizsgálatot a tesztgeneráláshoz ellenpéldával és az Ifx Statikus elemzést az állapotok elérhetőségének vizsgálatához [Med10b, Med11b]. A változók értékváltozásainak és a döntési mechanizmusoknak a követésére és átszabására az Ifx Platform külső verifikáló eszközeit javasoljuk a részletes tervezésben [Med12b]. 2.2.2 Modell-alapú tesztelés A modell alapú tesztelés szabványos eszközeit javasoljuk a technológiai sorba, a TTCN-3, TTCN-2, UML-TP technológiákat, amelyek eszköztámogatása automatizált, fenntartásuk ipari és tudományos háttérrel történik [Buc04, Gro05, RTRT12].
2.3
Összefoglalás az 1. Tézis tárgyalásáról
A javaslatunk a technológiai sor kijelölésére módszertani előnyöket nyújt ahhoz, hogy meghatározzunk architektúra döntéshelyzeteket a modellező nyelvek szintaxisára és a verifikáló eszközök szolgáltatásaira építve. Ebben a fejezetben, a technológiai sorok kijelölésével, kifejtettük a szükséges nyelvi eszközök egy halmazát, amelyekkel a modellvezérelt elvek előnyösen megvalósíthatók. Az SDL nyelv specifikációs és implementációs jellege több kapcsolódási pontot nyújt a követelmények és a kód irányába [Sal00]. Például az architektúra döntésekhez a specifikációs nyelvbe implementált forgatókönyv tulajdonságokkal elhatárolhatjuk az objektumközi korlátokat, és ezek alapján konfigurálhatjuk a verifikáló eszköztárat [Med12b]. Továbbá az architektúra döntésekhez fontos az együttműködés alapú modellszegmentálás az un. references távoli hívás nyelvi elemmel, amely az architektúrában a komponensek kialakítását segíti [ITU12]. A szerepek dinamikus szétválasztásához hasznos nyelvi elem a create művelet, amikor a szerep a saját részhalmazával kerülhet kölcsönhatásba. Az MSC és az UML SD nyelvek szerkezetei meghatározóak a modellegységek verifikálásánál. Ilyenek a kontroll alapján szétválasztott szegmensek, mint a call, kill műveletek vagy a forgatókönyvben a szekvenciákat megtördelő feltételes cselekvéssorozatok, mint az alt, opt, loop, par, corregion, exp, comp, decomp [Dol03, Dol01, Mam00].
A modell-alapú verifikálás részletes elvi leírása található meg a CMU/SEI [Glu99] közleményben, amely a modellezést és verifikálást kiegészítő szolgáltatásként fogalmazza meg a fejlesztők számára, a környezet és a szoftverrendszer jobb megértéséhez. A CMU/SEI 42
[Glu99]
módszer nem eredményez modellvezérelt folyamatot, és nem ajánl technológiákat,
azonban a módszer egy fontos állomás a formális verifikálás szervezéséhez és szerepalapú integrálásához
a
szoftverfolyamatba.
A
modellellenőrzők
megválasztásával
és
a
munkafolyamat szervezésével algoritmizálható a verifikátor munkafolyamat, amely integrálja a modellellenőrzést a modelltranszformációs lépésekbe. A 8. és 9. ábrán bemutatott összefüggésekkel szemléltetettük, hogy a technológia lehetőségei és ehhez hozzárendelt munkaelemek eredményezik a modellvezérelt folyamatba integrált verifikálást és validálást, mindehhez a konkrét folyamathoz a technológiai sor kijelölésének fontosságát. Vizsgáltuk alkalmazását
a
kereskedelmi
elemzésekhez
és
szoftverekbe
beépített
automatikus
modelltranszformációkhoz
[Med08b],
modellellenőrzők valamint
ezek
kombinálását az IFx eszköztárral [Med09b]. Esettanulmányt és algoritmust fogalmaztunk meg a verifikátor munkakörre [Med10b], továbbá lépéssorozatot a PIM modellek több rétegben történő transzformációjához egyidejű verifikálással [Med11b], amelyeket általánosítottunk egy lépéssorozatban a verifikáló eszköztárak kiválasztásához és munkafolyamat tevékenységeinek szervezéséhez [Med12b].
43
3
MÓDSZERFEJLESZTÉS
SZOFTVERTERVEZÉSI
MINTÁK
ALKALMAZÁSÁRA
MDE FOLYAMATBAN Ebben a fejezetben kidolgozzuk a következő téziseket: 2. Tézis Módszerfejlesztés keretrendszer létrehozására és újrafelhasználására szoftvertervezési minták összeszövésével modellvezérelt fejlesztésben. 2.1
Módszert és esettanulmányt adtunk keretrendszer építésére és újrafelhasználására, a POSA2
architektúra
mintanyelvek
és
GOF
programtervezési
minták
összeszövésével,
UML
alapú
modellvezérelt fejlesztésekhez. 2.2
Módszert és esettanulmányt adtunk keretrendszer és szakterületi mintanyelv építésére, ill.
újrafelhasználására, a POSA2 architektúra mintanyelvek, GOF programtervezési minták és SDL Pattern üzenetkezelési minták összeszövésével az SDL alapú modellvezérelt fejlesztésekhez. 2. Tézis közleményei: Med08, Med10. További publikációink a témában: Med06, Med07b, Med07c.
A szoftvertervezési minták több absztrakciós szinten fejlődtek ki [Hil12]. Munkánkban a szoftvertervezési mintákra három nagy csoportban tekintünk, és ilyen módon kapcsoljuk össze az objektumaikat: architektúra minták, programtervezési minták, szakterületi minták. A modellvezérelt folyamatban többnyire a szakterületi sajátosságok alapján és a jellemző implementációs eszközökkel összefüggésben történik az architektúrákra nézve jelentős követelmények meghatározása [OMG00, Jéz03, Pär00, Bas98]. Ezért javasoljuk az absztrakciós szintek közötti modelltranszformációkban a szoftvertervezési minták alkalmazását. Kutatásunk a modellvezérelt fejlesztés gyakorlati vonatkozásaiban kiterjed a mennél nagyobb
újrafelhasználhatóságra,
ezért
javasolunk
módszert
esettanulmánnyal
a
szoftvertervezési minták alkalmazására újrafelhasználható modelltermékek fejlesztéséhez. A szoftvertervezési minták modellvezérelt modellezésével PIM-PSM absztrakciós szintű modelltermékeket
kapunk,
amelyek
újrafelhasználása
modellvezérelt
fejlesztésben
gyorsfejlesztést eredményez a PIM-PSM absztrakciós szinteken. Modellvezérelt fejlesztéssel az átjárhatóság elvi eszközeinek tartjuk a különböző absztrakciós szintű szoftvertervezési mintákat. A szoftverarchitektúra minták és a programtervezési minták újrafelhasználásával az MDE folyamat jobbítására és gyorsítására törekszünk az absztrakciós szintek között és az absztrakciós szinteken belül is. Az átjárhatóság eszközének tartjuk az architektúra minták és a programtervezési minták alkalmazását. Mindezt a POSA2 architektúra mintanyelvek 44
közvetítésével tartjuk kivitelezhetőnek. Munkánkban az elosztott rendszerek architektúra mintanyelveit alkalmaztuk, amelyek a Pattern-Oriented Software Architecture for Concurrent and Networked Objects, röviden POSA2 néven ismertek [Sch00]. A modellvezérelt folyamatban többféle mintaalkotás és mintafelhasználás lehetséges, amelyek a modelltranszformációk bemeneteiként vagy épp a modelltranszformáció levezetéseként hasznosak [OMG03]. A szoftvertervezésben a minta egy kontextusban közönségesen előforduló probléma legjobb megoldásának az általánosítása, közzétéve újrafelhasználásra. A minták kevert osztályai [Bus96] a szerkezeti elvek és funkcionalitások szerint a következők: architektúra keretminták, tervezési minták, programnyelvi idiómák. A mintaosztályok
lentről
keretrendszerekbe
felfelé
szervezhetők
történő
általánosítással
előretervezéssel
vagy
tervezési
katalógusokba
visszatervezéssel
[Cop95].
és A
mintaalkalmazás módszerét és előnyeit tárgyaló alapmű [Bus96] a mintákat rendszerben tárgyalja. A minták és kapcsolataik együtt mintanyelvet alkotnak az általuk megoldott feladatokból álló funkcionális egységekre, amelyek mintakatalógusban vagy keretrendszerbe szervezetten kerülnek újrafelhasználásra. A minták, mintanyelvek, mintaalkalmazási keretrendszerek és mintakatalógusok növelik a termelékenységet [Bus96]. A modellvezérelt fejlesztésben a mintarendszerek a platform osztályok fejlesztésének eszközei lehetnek, amelyek birtokában egy platformra gyorsfejlesztés történhet [Med08, Med11, Med06, Med05, Med02].
A szoftvertervezési mintákat az absztrakció minden szintjén alkalmazhatjuk (mark, template, extension, combination [OMG03]) a transzformációk bemeneteiként. Modellvezérelt fejlesztéssel keretrendszerbe foglalva a mintanyelvek megvalósításait, az újrafelhasználásuk nemcsak a kezdő fejlesztők számára hatékonyabb. Ugyanakkor a hatékony felhasználásukhoz tanulás, idő, erőfeszítés és szakterületi elemzés szükséges [Med05]. Az architektúra mintanyelveket és a tervezési mintákat felhasználva, módszert és esettanulmányt
adtunk
keretrendszerek
fejlesztésére
modellvezérelt
architektúra
fejlesztéséhez [Med08, Med11]. A modellvezérelt architektúra fejlesztésére vonatkozó módszertanunk létrehozásakor elemeztük az architektúra tervezés alapvető szerepét Perry és Wolf alapvetéséből kiindulva [Per92],
amely az elemeket és az indoklásokat összekapcsolja az ábrázolási formával. Az
alapvetés a ma megkerülhetetlen komponens és konnektorok fogalmakat jelenti az architektúra elemekre, a nem-funkcionális (minőségi) követelményeket az indokláshoz, és az ábrázolási formát, amely reprezentációs mód egyben nyílt vagy hallgatólagos döntéseket hordoz a választott architektúra elemekről és funkcionalításukról. A formális módszerek 45
egyben reprezentációs eszközt képviselnek a rendszernézőponthoz, és valamilyen mértékben dokumentálják a döntéseket az elemekről az indoklásokkal. Perry és Wolf automatizálásra törekedve alapozták meg a szoftverarchitektúra fogalmát, mint egy keretet a követelmények kielégítéséhez, a függőségi vizsgálatokhoz és a konzisztencia elemzésekhez. Lényeges szempont, hogy a skálázások nem az elemek ismétlésével érhetők el, hanem épp az újabb különböző elemek hozzáadásával. Az architektúra képezi a technikai alapot a tervezéshez, a kezelési alapot a költségszámításhoz és folyamatirányításhoz, valamint tényleges alapja az újrafelhasználásnak. Perry és Wolf [Per92] négy absztrakciós szintet határoztak meg a szoftvertermék vonatkozásában:
a
követelmény,
az
architektúra,
a
tervezés,
az
implementáció
termékcsoportok szintjeit. Az egyes szinteknek megfelelő termékcsoportok: a modellek, az absztrakciók, a transzformációk, a megvalósítások. Az absztrakciós szintek közötti folytonosság létrehozásához, Perry és Wolf a létrehozandó szoftvertermékek tulajdonságai alapján meghozható döntésekre helyezik a hangsúlyt. Elsődlegesen követendő szempont, hogy miként vonatkozik a szoftverrendszer fejlesztésében az architektúra a követelményekre és a tervezésre. Ugyanekkor Zachmann az architektúra szerepét a felhasználók és a rendszerfejlesztők nézeteinek összeegyeztetésére vonatkoztatja [Zac87]. Shaw és Garlan [Sha89, Sha96]
a programozási nyelvek nézetéből a tulajdonságok és kapcsolatok absztrakcióival
határoztak meg fix architektúra elemeket, amelyeket kombinálnak a típusokra alapozva [Sha90, Sha95].
Ezen elméletek alapján számos architektúra stílus [Bas98] és mintanyelv született. Például az elosztott rendszerek [Sch00], az üzletszervezés [Eri00, Fow02], a programtervezés strukturális és viselkedés [Gam95] mintái. A minták szerepe azért értékes a mi szempontunkból, mert különösen az újrafelhasználásban megadják a Perry és Wolf [Per92] alapvetésében kihangsúlyozott irányt az absztrakciós szintek között, kihangsúlyozva az architekturális döntések szerepét a követelményekre és a tervezésre nézve. A különböző absztrakciós szintű szoftvertervezési minták egy MDE folyamatban az átjárhatóság eszközeiként viselkednek, amint azt láttatni fogjuk az esettanulmány ábráival a 3.2. alfejezetben. A modellvezérelt fejlesztésben az architektúra döntések alapját az ismert szakterületi implementációknak a platform modelljei képezik [OMG00], valamint a szakterület generikus modelljeiből kinyert azon követelmények, amelyek az architektúrák szempontjából jelentősek. A modellalkotásnak ezt a vonatkozását az MDA mintákra és a modellellenőrzés feladataira nézve tárgyaltuk a [Med10b] közleményünkben.
46
3.1
Módszerfejlesztés a POSA2, a GOF és a szakterületi minták összeszövésére A szoftvertervezési minták egymással együttműködő objektumok és osztályok leírásai,
amelyek testreszabott formában, valamilyen általános tervezési problémát oldanak meg egy bizonyos összefüggésben [Hil12]. A tervezési minta azonosítja a megoldásban résztvevő osztályokat és példányokat, ezek szerepeit és kapcsolataikat, illetve a felelősségi körök elosztását. Közös vonás az elterjedt minta alapú módszerekben, hogy találhatunk a mintaleírásban a dokumentáláshoz modelleket, azonban a hangsúly a mintaleírásban az implementáción van, nem a modellezésen. A szoftvertervezési minták felhasználásában a hangsúlyt a követelménytervezés szintjére helyezzük, és a szerkezeti és szervezési elemekre összpontosítunk. A minták újrafelhasználható modelljeinek az alkalmazása segíti a strukturális elemek feltárását és az elemzést. Például a POSA2 architektúra minták struktúrájában a viselkedési elemek vezetnek rá a követelmény feltárás jóságára, vagy épp egy másik minta szükségességét sugallják. Egy
MDE
fejlesztésben
a
platform
független
és
platform
specifikus
transzformációkban hasznosulnak a minták generikus újrafelhasználható modelljei. Azonos és különböző absztrakciós szinteken is alkalmazhatjuk a minták újrafelhasználható modelljeit a szakterületi tudás és automatizáltság függvényében. Az előzőeket a komponens elvű fejlesztés fogalmaival kifejezve azt jelenti, hogy a minták összeszőtt újrafelhasználható modelljei birtokában megvalósulhat az újrafelhasználás vertikálisan a kompozíció, specializáció és megtestesítés fejlesztési tartományokban. Megfelelő szakterületi tudás és/vagy automatizálás birtokában szervezhetünk gyorsfejlesztést is a leképezésekkel és újrafelhasználással. A javaslatunk felhasználása bármely feladattípusra lehetséges azáltal, hogy az újrafelhasználható modelleket egy modellvezérelt transzformációs sorozatba építjük be, a modulárisságot és a komponens elveket követve adott platformosztályra nézve. A POSA2 és GOF minták modellezése és keretrendszerbe foglalása többletet jelent az eddigi POSA2 és GOF mintákhoz képest a minták újrafelhasználásában és az újrafelhasználás módjában is. A fontosabbak: - az absztrakciós szintek között a Perry és Wolf szerinti architektúra fogalmakkal a követelmény – architektúra – implementáció
közötti
folytonos
átmenetet
eredményezi. - a keretrendszerbe foglalt összeszőtt minták egy részhalmaza jelenti a fejlesztéshez a kiinduló tervmodellt és implementációs modellt. 47
- az implementációs technológiák szintjén az újrafelhasználás kérdését meg lehet közelíteni a modelltermék és szolgáltatási egységek nézetében. - a modelltranszformációkban a minták újrafelhasználható modelljei képezik az átjárhatóság alapját az azonos és a különböző absztrakciós szinteken is. - kezdő fejlesztők is tudnak mintaalkalmazást végezni: a mintákba épített szakértői tudás hasznosul a fejlesztés és az inspekció során. - nemcsak a kliens-szerver kommunikációs modellre alkalmazható, hanem ennek egyéb változataira is, mint a szolgáltatások (szolgáltatás-orientált modellek), változó csoportosulások (master-slave modell).
3.1.1 POSA2 architektúra mintanyelvek felhasználása a munkánkban A POSA2 mintanyelveket a CORBA [OMG12] köztesréteg kifejlesztéséből nyert jó megoldások általánosításával hozták létre és terjesztették az európai és nemzetközi (PLoP, EuroPLoP) mintaegyeztető és mintafejlesztő közösségek és a közzétett munkáik [Hil12]. Az architektúra mintanyelvek a kommunikációs modell szerint többfélék lehetnek. A mintanyelvek megtalálhatóak a “Pattern-Oriented Software Architecture” (POSA) főcímmel szerkesztett könyvsorozatban valamint az ezek műhelyeit összefogó weboldalakon [POS12]. A mintanyelvek gyűjtőneveit adja a sorozat mozaikszava a kötetsorszámmal együtt. A sorozat második kötete ismerteti [Sch00] a konkurrens és hálózatba szervezett alkalmazásrendszerek fejlesztésére létrehozott és a POSA2 gyűjtőnéven ismert architektúra mintanyelveket. A mintagyűjtemény elemei megfelelnek a kliens-szerver kommunikációs modellben értelmezett viselkedésmechanizmusok együttesének. A mintaleírások szerkezeti elemeit alkotják a szolgáltatásnyújtó szerverek, a hálózati csomópontok a szolgáltatás hozzáféréshez és a kliensek. A mintaleírások viselkedés elemeit alkotják a fő funkciók és a kommunikációs folyamat jelenségei. A kliens-szerver modellben a kommunikáció a kliens kérésével indul, a szerver elvégzi a kért szolgáltatást, és a kommunikáció a szerver válaszával zárul. A kliensek szükség szerint tudnak egymásról és vannak kapcsolatban egymással. A kliens-szerver modell működéséhez funkciókba szervezve további viselkedésmechanizmusok és támogató objektumok szükségesek. A funkciókat a mintákban ismerjük meg. A kommunikációs modell fő funkcióira a mintákat a négy nagy funkciócsoportba szervezve kapjuk meg, amelyek kapcsolataikkal együttesen alkotják az objektumok összefonódásából kialakuló – a POSA2 – architektúra mintanyelvet. Ezek (7.2 Melléklet 39. ábra), a Szolgáltatás elérési és konfigurálási minták, Eseménykezelési minták, Szinkronizációs minták, Konkurens minták, összesen 17 48
architektúra mintával. Ezek a mintanyelvek egymással kapcsolatban vannak, például a “Szolgáltatás elérési és konfigurálási” mintanyelv kapcsolatban áll minden másikkal a Wrapper Facade mintán keresztül. A POSA2 architektúra mintanyelv [Sch00] ismertetése megadja az egyes minták mögötti probléma-megoldás párost, a minta létrehozásának oksági mutatóit és a minta célját un. kontextus címen. Szemlélteti a minta strukturálódását szövegesen és Class-ResponsabilityCollaborator (CRC) lapon, a minta dinamikáját szövegesen és állapotgráfon szemléltetve, valamint megadja az implementáció menetének részletes útmutatóját C++ és Java nyelvű implementáláshoz. Az implementáció menetének leírásában javaslat és magyarázat található konkrét GOF programtervezési minták alkalmazására. Ezeket a leírásokat felhasználva a keretrendszer létrehozásában implementációs modellt is adtunk az architektúra mintákra oly módon, hogy modellezési technikákkal beleszőttük a POSA2 mintákba a GOF mintákat. Az architektúra minták modellezésével további programtervezési minták felfedezésére is lehetőség adódik, amelyeket a szöveges leírás nem tartalmaz. Az együttműködési modell vizuális többlete segíti a mintafeltárást. 3.1.2 GOF programtervezési minták felhasználása a munkánkban A programtervezési minták gyakran előforduló programozási feladatokra adott tervezési szintű megoldások egy bizonyos összefüggésben, amelyek általános leírások objektumok és kapcsolataik megadásával. A minták a minta célja szerint lettek besorolva un. létrehozási, strukturálódási, viselkedési minták osztályaiba aszerint, hogy a minta az objektumok példányosítására, szervezésére, ill. kommunikációjára vonatkozik. A Gang of Four megnevezéssel terjedtek el a szerzőket jelölve a GOF mozaikszóval [Gam95] (7.2 Melléklet 38. ábra),
különösen a programfejlesztők körében. Az UML fejlesztőeszközök többsége
tartalmazza a GOF minták újrafelhasználható C és Java kódját, a fejlesztők pedig a kommunikációjukban a mintaneveket használják a szoftver-absztrakciók kifejezésére. A GOF mintáknak fontos jellemzője a hatókör, amely azt mutatja meg, hogy osztályra vagy objektumra alkalmazhatók-e. A viselkedési objektumminták megmutatják, hogy mely objektumok csoportja szükséges a feladat megvalósításához. A mi célunkhoz fontos jellemző a GOF programtervezési mintáknak az implementáció közelsége. Alkalmazásukat segíti az a tulajdonságuk, hogy egymáshoz kapcsolódó jelenségekre leképezett absztrakciók (7.2 Melléklet 40. ábra). [Sun00].
Alkalmazásuktól nő a karbantarthatóság, az újrafelhasználhatóság és a hatékonyság
A programtervezési minták tanulása a gyakorlatban több úton lehetséges, kiterjedt
irodalom támogatja több módon, például az architektúra minták implementációinak szöveges 49
leírásai, részletesen megadják az implementálásban alkalmazható programtervezési mintákat, amelyek így a gyakorlati felhasználásukkal már példányosítva rögzülnek, egyben tanulási folyamat zajlik a mintaillesztésre és mintaalkalmazásra. A minták alkalmazásához szükséges tudás megszerzése történhet a minták célirányos példányosításával egy adott szakterületi kontextusra nézve, megtervezett tanulási folyamatban a mintaleírások alapján, a szakértőkkel együtt végzett gyakorlati munka során fejlesztésben vagy mintaalkotási műhelytalálkozókon [Hil12]. 3.1.3 SDL szakterületi minták felhasználása a munkánkban A szakterületi programtervezési minták felhasználásával az a célunk, hogy a tervezési minták alkalmazásának szokásos előnyeit – könnyebb fejlesztési munkák, fokozottabb minőség, összehangolt dokumentálás, stb. – alkalmazzuk a szakterületi nyelvek formális eszközeit a szakterületi nézőpontokra MDE fejlesztésben. Mivel a szakterületi nyelvek a szakterületi fogalmakat és részletező tulajdonságokat alkalmazzák a megoldások leírására, ami megbízhatóbb szoftverrendszert eredményez, mert skálázhatóbbá válik a fejlesztési folyamat és megnő az újrafelhasználhatóság. Figyelembe kell venni a módszerszervezésben, hogy hátrányok is keletkezhetnek [Eis07, Wu06] Az UML szabvány a tervezési minták modellezésére a paraméterezett együttműködéseket javasolja. A modellvezérelt technológiákban megjelentek a metamodellekre alapozott és OCL algebrai szabályokkal ellátott GOF mintamodellek [Sun00, Gue00] és egyéb UML mintaleíró [Mus02, Mus07, Fra04]. A szakterületi problémák kezeléséhez az objektum-orientált keretrendszerek alkalmazásai mintákat kínálnak, amelyek be nem fejezett modellek, un. sablonok, amelyeket a szakterületi szakértők alkalmaznak, a szakterületi részletes tervezésben kerülnek felhasználásra a szakterületi szakértők által. Az architektúra fejlesztés komponensalapú megközelítésében a fejlett modellvezérelt technológiákkal lehetséges a szakterületi nyelvek definiálása. A szakterületi nyelvekkel a szakterületi mintáknak a létrehozása és leírása közvetíti a szakterületi szakértő megoldását a szoftverfejlesztőhöz, aki beágyazza a szakterületi architektúrába
komponensfejlesztéssel
[Tom12].
Ezeket
az
elvi
irányokat
követjük
munkánkban a szakterületi modellezésre. Módszert, sablonokat (3.2 tézis), mintanyelvet (2.1, 2.2 tézis) hoztunk létre, amelyek manuális/automatikus transzformációkkal modellvezérelt fejlesztést támogatnak, idővel hozzájárulnak a módszer eszközszintű automatizálásához. Az SDL nyelvet több megközelítéssel alkalmazták már mintaleírásra. Ilyen munkák: a kommunikációs protokollok architektúra mintáinak leírása [Par00], az SDL és Linear Temporal 50
Logic (LTL kombinálásával minták validálása [Byu06], az SDL típusaival az absztrakciós szintek növelése keretrendszerek létrehozására [Bræ98, Par05]. Az SDL programtervezési mintákat az elosztott viselkedések megbízhatóságának kezelésére, Gotzhein és társai hozták létre [Got03, Got03b, Cis98, Fli07, Dor05, Com02, Gep97, Fel99] un.
SDL
Pattern
Pool
micro-pattern
idiómák
gyűjteményeként
a
megbízható
együttműködések modellezésének implementációs szintjére, és a kezelőeszközt [Dor05]. Az SDL Pattern Pool mintáit alkalmaztuk a POSA2 és GOF mintákkal együtt, oly módon, hogy az architektúra modellek fejlesztése és az elemzés szintjén létrehoztuk a POSA2 és GOF minták összeszövésével az SDL Macro-Pattern mintanyelvet, amelybe beleszőttük az SDL Pattern Pool szakterületi programtervezési mintákat. 3.1.4 Módszerleírás keretrendszer építéshez a POSA2, GOF és szakterületi programtervezési minták összeszövésével 1. Keretrendszerbe foglaláshoz újrafelhasználás szempontok és minták kiválasztása: Első lépésként rögzíteni kell a keretrendszer célját, újrafelhasználásának módját és körülményeit. A cél lehet generikus modellgyűjtemény létrehozása, vagy specifikus gyűjtemény létrehozása egy meghatározott szakterületi fejlesztés támogatására. Meghatározott szakterületi fejlesztéshez, a tervezők értelmezik a mintanyelv funkcióit, és ebben a minták fogalmait a szakterületi fogalmakra kivetítve, adott funkciók megvalósításához. Részletezik az egyes viselkedések jellemzőit avégett, hogy az adott minta kiválasztása indokolt legyen, és egyben a mintakiválasztás folyamatában az újrafelhasználás beazonosítása és dokumentálása is megtörténjen. 2. Input egységek biztosítása a keretrendszer létrehozásához: A kiválasztott mintáknak a modellezésükhöz szükséges jellemzőit kell összegyűjteni és dokumentálni. A POSA2 mintagyűjteményből [Sch00] szükséges elemek: Cél, Kontextus, Probléma-Megoldás leírás, CRC, Állapotgráf, Implementációs leírás. A GOF [Gam95] mintagyűjteményből felhasznált
elemek:
programtervezési
Feladat,
Alkalmazhatóság,
mintagyűjteményből
Megvalósítás.
szükséges
elemek:
A
szakterületi
Cél,
Leírás,
Mintaimplementációk egységei dokumentumban és/vagy eszközben. 3. Absztrakciós szint és termékcsoportok meghatározása: Az alkalmazott technológiákról és modelltípusokról kell dönteni, vonatkoztatva a POSA2 architektúra mintanyelv leírásában található Probléma-Megoldás párosra a strukturális vagy viselkedési nézeteknek megfelelően. A létrejött modelltermékek fontos újrafelhasználási eszközök. A diagramok segítik a tervezőt, hogy minél jobban megértse a minta által képviselt 51
Probléma-Megoldás párost, a programozót pedig abban, hogy könnyebben azonosítsa a mintában a szerepköröket a GOF mintáknak és a szakterületi programtervezési mintáknak megfelelően. 4. Az architektúra minták modellezése: A mintaleírás osztályozásait és azonosító jelöléseit megtartva történik a modellezés a meghatározott absztrakciós szinteken a szerepek, szereplők és kapcsolatok ábrázolásával statikus és dinamikus nézetben. Az újrafelhasználhatósághoz szükséges a modell és a mintaleírás közötti egyértelmű megfeleltetés. A mintanyelv leírásában található szerepkörök ábrázolását célszerű a programtervezési minták megfeleltetésével végezni, ugyanekkor a résztevékenységek ábrázolását a kiválasztott minta szereplőjének tevékenységeivel azonosítani. Ekkor mindkét
mintafajta
azonosítóit
szükséges
megtartani.
Eredményesebb
a
programtervezési minták azonosítása, ha együtt vizsgáljuk az implementációs leírást és a készülő modellt. Ez segíti az objektumok viselkedésének modellezését is. 5. Mintanyelv fejlesztése: a mintaszövés modellezésével történik a minták és mintakapcsolatok viselkedésének felderítése (4. lépés) a modelltermékek előállításakor. 6. A felhasznált mintanyelvek és mintakatalógusok elérési adatainak megadása: A mintakiválasztás során meghatározott és dokumentált input egységek rendszerezése és pontosítása az egyértelmű megfeleltetéshez a modellgyűjtemény és a hivatalos mintaleírások között.
3.2 Módszer alkalmazása UML fejlesztéshez A keretrendszer létrehozása és alkalmazása valamely UML fejlesztőben történik, célszerűen megválasztva az újrafelhasználáshoz. Újabban az UML fejlesztő környezetek tulajdonságai között szerepel a GOF programtervezési minták automatikus támogatása kritérium, ami többnyire, a C++ és Java nyelven fejlesztők körében elterjedt. Kutatásunkban kliens-szerver kommunikációs modell alapú UML2.0 fejlesztésekhez, mintagyűjteményt hoztunk létre újrafelhasználható keretrendszerben a POSA2 Service Access and Configuration Pattern architektúra mintanyelvet alkotó mintákkal és ebben a vonatkozó GOF programtervezési mintákkal. A generikus gyűjteményünk létrehozásához dokumentált minták: POSA2 architektúra mintanyelvek hivatkozási és elérési adatai – [Sch00] Service access and configuration patterns mintanyelv 44-46, Wrapper Facade minta 47-74; Component Configurator minta 75-107; Interceptor minta 109-140; Extension Interface 141-174. http://www.cs.wustl.edu/~schmidt/tutorials-patterns.html 52
GOF programtervezési minták hivatkozási és elérési adatai – [Gam95] (ford. Jean-Marie Lasvergères) Design Patterns: Catalogue de modèles de conception réutilisables, Vuibert Informatique, Paris, 1999, Observer 343-356; Mediator 319-330; Iterator 285-300; Singleton 149-157; Memento 331-342; http://hillside.net/patterns/DPBook/GOF.html Erich Gamma; Richard Helm, Ralph Johnson, John Vlissides (ford. Kiskapu Kft.), Programtervezési minták: Újrahasznosítható elemek objektumközpontú programokhoz, Kiskapu Kft., Budapest, 2004, Observer 296-306; Mediator 277-286; Iterator 262-276; Singleton 128-135; Memento 287-295; Keretrendszerbe foglaltuk generikus mintagyűjtemény elemei: 1. a felhasznált minták rövid leírása: a közzétett cél, feladat, CRC, állapotgráf ismertetések 2. a létrehozott újrafelhasználható UML modell elemek: összetett struktúradiagram (CSD – composite diagram/MSC),
structure
diagram),
kölcsönhatás-áttekintő
szekvencia diagram
diagram
(SD – sequence
(IOD – Interaction
overview
diagram/HMSC) 3. esettanulmány a mintagyűjtemény alkalmazásának és bővítésének tanulásához. A gyűjtemény létrehozása és bővítése viszonylag egyszerű modellezési tevékenység az irodalomban megbízhatóan fellelhető mintaleírások alapján. Egyrészt azért, mert ezek a mintaleírások megfelelnek a tervezési feladat követelmény leírásának, másrészt ugyanezek a mintaleírások C++ és Java implementációk leírásait mutatják be a jobb megértéshez és alkalmazáshoz. A hiteles és újrafelhasználható gyűjtemény létrehozásához modellverifikálás és inspekciós ellenőrzés szükséges. A nagyobb megértést igényelő munkaszakaszt jelenti az újabb programtervezési minták felfedezése a létrehozott kölcsönhatás diagramokban, túlmenően a POSA2 könyvben az implementáció részletes leírásában megadott GOF programtervezési mintákon kívül is. Azonban a mintaleírás alapján kijelölt programtervezési mintákkal is teljes és helyes kell, hogy legyen az inspekcióval validált megoldás, amely újrafelhasználásra kerül. 3.2.1 Mintanyelv és keretrendszer építése A módszer alkalmazását a Component Configurator architektúra mintával szemléltetjük. A POSA2 Component Configurator minta és ennek implementálásához szükséges GOF programtervezési
minták
összeszövésével
létrehoztuk
a
ComponentConfigurator
mintanyelvet, amelynek menetét bemutatjuk az alábbiakban. A különböző absztrakciós szintű szoftvertervezési minták egy MDE folyamatban az átjárhatóság eszközeiként viselkednek, 53
amint azt látni fogjuk az esettanulmányban. A gyűjtemény felhasználásának szemléltetésére megadjuk a mintafeltárást, a folyamatok elemeinek az azonosítását és az architektúra modell előállításának a módját gyorsfejlesztéssel. Ehhez felhasználjuk a POSA2 „Szolgáltatás elérése és konfigurálása” mintanyelvet [Sch00] és a GSM mobilhálózat felépítését [Dár03]. 3.2.1.1 Component Configurator mintanyelv fejlesztése 1. Cél: a POSA2 Component Configurator architektúra minta újrafelhasználható modelljének előállítása a vonatkozó GOF programtervezési minták beleszövésével, UML alapú generikus mintagyűjtemény bővítéséhez. 2. Bemenetek: POSA2 Component Configurator mintaleírás, osztálydiagram, állapotgráf. Rövid leírás: A minta célja a komponensek futásának dinamikus konfigurálása egy alkalmazás kérése szerint, amelynek dokumentálása osztály és állapotgráf diagramban a 10. ábrán láthatók. Hatás: az alkalmazás futási időben kapcsolja és lekapcsolja a komponenseinek az implementációit anélkül, hogy módosításra, újrafordításra vagy statikus kapcsolásra lenne szükség. Felhasználás: Központi menedzselés. Felhasználók: alkalmazások, fejlesztők és adminisztrátorok. Teljes leírás: A teljes implementációs megoldás szöveges ismertetése és a problémamegoldás páros leírása a magyarázattal együtt megtalálható a [Sch00] 75-107. sz. oldalakon. További információk megtalálhatók a POSA2 - http://www.cs.wustl.edu/~schmidt/tutorialspatterns.html; http://www.cs.wustl.edu/~schmidt/POSA/.
Osztálydiagram és állapot gráf a mintaleírásból: A 10. ábrán a bal oldali struktúrában láthatjuk a komponenst konfiguráló szerepkört a Component Repository és Component Configurator együttessel, amely implementálja a futtatni kívánt Concrete Component komponens szerepkört, és csatlakoztatja a konkrét komponens példányt, inicializálja, kezeli a működését.
10. ábra Component Configurator minta osztály [Scha00, p.80] és állapotgráf diagramja [Scha00, p.82]
54
A komponens futásának felügyelete a 10. ábrán a jobboldali állapotgráfon látható műveletekkel: futás közbeni eseményvezérelt felfüggesztés, újrainicializálás, jelentésadás, bevégeztetés. 3. Absztrakciós szint és termékcsoport meghatározása: A cél az egyes architektúra mintákra UML modell előállítása PIM nézőpontból a strukturális és viselkedési nézetekkel, csoportosítva az összetett struktúra diagramot és szekvencia diagramokat. Bonyolultság vagy méretezési problémák esetén szükséges az összetett kölcsönhatás diagramok előállítása. A szekvencia diagramok kell, hogy tartalmazzák a referencia operátorral modellezve az implementációs leírásban megadott programtervezési mintáknak a beleszövését. Szükséges, hogy az újrafelhasználásban a tervező minél jobban megértse a mintával képviselt problémamegoldás párost, és a programozó azonosíthassa a szerepköröket a GOF mintáknak megfelelően, amely által újrafelhasználhatja a GOF kódokat a fejlesztőeszköz támogatásától függően. 4. A minta gyűjteménybe szervezése részletes tervezéssel: a célhoz (1.-3. lépések) az architektúra modellen és az implementálás leírásának általánosításán van a fő hangsúly. Modellezői intuíciótól függ az iterációk száma. Gondos értelmezés szükséges a részletesebb viselkedést leíró kölcsönhatás diagramok megalkotásához. Itt felszínre kerülhetnek olyan viselkedési elemek, melyek rejtett objektumok használatát teszik lehetségessé vagy szükségessé, amelyek a mintaleírásban megadott általános ismertető célú ábrán még nem voltak láthatóak, illetve modellezhetővé válik az üzenetváltások pontosabb menete. A minta implementációs modelljét összetett struktúra diagramban (11. ábra) és szekvencia diagramokkal (12. ábra) adtuk meg.
11. ábra Component Configurator összetett struktúra diagram
55
Definiáltuk az interfészeket, a Configurator, Repository, ConcretComp_A, Container_A, az alkalmazás részéről a direktívában kért, konkrét komponens szerepkörökre. Továbbá a mintaleírás alapján ábrázoltuk a viselkedést a szereplők konkrét példányai közötti kölcsönhatásoknak az időbeni egymásutánjaival (12. ábra). A 12. ábrán látható a szekvencia diagram egy részlete: a kliens kérése a konfigurálóhoz, majd ennek a feladatai a konkrét komponens példányosításával és konténerezett futtatásával. További viselkedésrészletek követhetők a dinamikus komponenskezelési alternatívák iterálásáról a mellékletben (7.2 Melléklet 41. ábra). 5. Mintanyelv fejlesztése: az előző lépésben kapott POSA2 minta viselkedési nézetébe beleszőjük a minta közzétételi leírásában [Sch00] kapott GOF programtervezési mintákat, és továbbiakat derítünk fel a kölcsönhatások elemzésével. Ebben a pontban a mintaszövés eszközeire és menetére fektetjük a hangsúlyt, a modellvezérelt folyamat menetét a 3.3.4 alpontban ismertetjük a szakterületi mintanyelv és szakterületi viselkedési minták összeszövésénél. A szövés eszközeként alkalmazzuk a ref inline operátort a programtervezési minták meghivatkozásához. A ref operátorral meghivatkozott programtervezési minta egy külön
szekvencia
diagramban
kerül
modellezésre.
A
további
mintafelismeréshez
megvizsgáljuk a kölcsönhatásban az architektúra osztályok metódusait, ezek szereplőit és célját, amelyek alapján találhatunk programtervezési mintát a metódusra a mintaalkotó szerzők által megadottakon túl is.
12. ábra Component Configurator mintában, a kért komponens futtatásához szükséges szerepek és kölcsönhatásaik (részlet)
Pl. a komponens viselkedéséhez fel kell dolgozni a kliens kérését, ehhez alkalmazhatjuk az Interpreter (12. ábra) és a Memento (7.2 Melléklet 44. ábra) GOF mintákat. A lekapcsolás előtt és az újrakapcsoláshoz beállítjuk a komponensek állapotai elmentéséhez a 56
Memento minta SetState() és GetState() műveleteit. Az Observer mintát alkalmazzuk minden egyes jelentés és értesítés esetén a kliens és konfigurátor kapcsolatára a felfüggesztéshez és a bevégzéshez is. A fini(), suspend(), info() metódusok megvalósításához felismerjük az Observer minta subject() és notify() metódusait.
13. ábra Wrapper Facade minta megvalósításának modellezése a Template Method GOF minta beleszövésével
A (7.2 Melléklet 33. ábra) ábrán a Configurator POSA2 minta resume(), info() metódusának implementációjához felismerjük az Observer mechanizmusokat a CompConfig és Client szerepek között. A vezérléshez szükséges tájékoztatást (info() metódus) implementáltuk az Observer minta ismételt alkalmazásával (Observer_1) a dinamikusan kezelt komponenspéldány és konfigurátor közötti kölcsönhatásról. Az eredmény az egyszerűbb áttekinthetőség és a minták megértése. A szétkapcsolás vagy bevégzés műveletekhez tartozó resume() jelentésadás implementálását (lásd 10. ábra) megvalósíthatjuk az Observer minta kétszeri alkalmazásával, más-más szereplőkre. 3.2.2 Keretrendszer és mintanyelvek újrafelhasználása A mintagyűjtemény újrafelhasználásának első lépése a minta illesztése a célok mentén, amely egy iterációs vizsgálatot jelent a funkciók egyeztetésére és a tevékenységek azonosítására úgy a mintában, mint a mintázni kívánt rendszer viselkedésében. Összevetésre kerül a minta célja és a modellezni kívánt rendszerelemek funkciója ahhoz, hogy mintaillesztéssel határozzuk meg a kiinduló modell elemeit. A mintaillesztés jóságát a funkcióbeli viselkedések megfeleltetésével ellenőrizzük. A minta felderítése a minták kapcsolatain: a szükséges minta megtalálása megvalósulhat a minták kapcsolatait követve. Amint a vizsgált minta egy részcélját azonosítottuk a feltérképezni kívánt rendszer egy viselkedésével, vizsgálva az objektumok közötti kapcsolatokat a mintanyelv szerkezetében határozható meg a keresett rendszerfunkcióhoz illeszthető minta. Ehhez, a mintanyelvek kapcsolati ábráit, és a mintaleírások cél-kontextus 57
összevetését
érdemes
felhasználni,
pl.
7.3
Mellékletben a 37.
ábra a POSA2
mintakapcsolatokkal, a 38. ábra a GOF mintakapcsolatokkal, és a mintaleírások forrásaiban [Sch00, Gam95].
A minta alkalmazása folyamatban adjuk meg a mintaelem átírását a vonatkozó rendszerfunkció elemek jelzőivel a mintagyűjteményben levő modellek újrafelhasználásával. Ez történhet egyszerű megfeleltetéssel vagy adaptációval a specifikus jelenségek ábrázolásához, amelyek jellemzően hibakezelés módozatok vagy tevékenység variációk. 3.2.2.1 GSM
hálózat
híváskezelésének
modellezése
mintanyelv
újrafelhasználással Példának a GSM hálózat szolgáltatáselérés mechanizmusát választottuk [Dár03], amelyben a híváskezelés funkcióra végeztük el a mintaillesztést, a Component Configurator POSA2 architektúra minta cél-kontextus leírásának az összevetésével. Továbbá mintaalkalmazást adtunk
az
implementációs
modell
létrehozásához
a mintagyűjtemény Component
Configurator mintanyelvét újrafelhasználva. A GSM architektúrában a hívásmenedzselés funkcióhoz illeszthető a Component Configurator minta a GMSC (Gateway Mobile Switching Centre) részegységre [Dár03], amelyben a callHandler híváskezelő funkció azonosítható a Concrete Component osztállyal. A híváskérés tevékenységben érkezhet a hívás a kapcsolódó interfészekre az ISDN hálózatról vagy egy lokális cellából, amelynek kezelésére a GMSC létrehoz egy újabb híváskezelő példányt. A callHandler híváskezelő példányok kezelik a kapcsolatot és a megfelelő két kommunikáló fél közötti információcserét, ebben a kapcsolat felépítés lehetséges hibáit (rossz szám, foglalt szám, nem elérhető mobilkészülék), valamint ellenőrzik a felépített kapcsolat teljesítményét és bontását.
14. ábra Component Configurator minta alkalmazása újrafelhasználással GMSC híváskezelő funkció architektúra modelljéhez
58
A mintaalkalmazás folyamatában ezeknek a GMSC tevékenységeknek a modellezéséhez újrafelhasználással
alkalmazzuk
a
Component
Configurator
POSA2
mintának
a
mintagyűjteményben levő kölcsönhatás diagramjait, és üzenetcserékkel adjuk meg GMSC híváskezelő feladatait a Concrete Component szereplőhöz tartozó variációkban. Az elemzés után mintaalkalmazással megadjuk a 14. ábrán látható architektúra modellt. Ebben a példában egyszerű megfeleltetéssel végeztük a mintaalkalmazást (Melléklet 7.3-41 .ábra),
azonban megtörténhet, hogy nem illeszkedik teljesen valamelyik szerep vagy feladat,
és ehhez adaptálni kell a tevékenységsorozatot. Ez természetes jelenség az interfészek adaptációjára, mivel a minták generikus modelljei nem tartalmaznak olyan specifikus jelenségeket, mint például konkrétan minek a következtében kell bevégeztetni a komponens futását Eldöntendő, hogy a felfüggesztések és újraindítások milyen hatáskörben, mely döntések eredményeként, milyen körülmények között következnek be, és milyen szolgáltatáskérések esetén milyen hibakezelések szükségesek. Ezek a specifikus elemek a minta adaptálásával kerülhetnek modellezésre a kölcsönhatás diagramban. Más esetekben kiderülhet, hogy nem a megfelelő mintát választottuk a minta célja és a modellezni kívánt rendszerelem funkciójának összevetésénél. Ilyenkor gyakori, hogy a vizsgált minta egy részcélját azonosítottuk, és így a mintán belüli osztályok csak egy része illeszkedik a keresett funkciókhoz. A szükséges minta felderítése a minták kapcsolatain haladva valósul meg. A mintanyelvben minden egyes minta neve az őt alkotó több osztályt és azok kapcsolatát takarja, azaz a mintanyelv modelljeiben valójában a mintát alkotó osztályok kapcsolódnak, esetenként átfedéssel is. A részben illeszkedő minta kapcsolatait vizsgáljuk a mintanyelvben az objektumok közötti kapcsolatokat elemezve annak meghatározásához, hogy melyik másik mintával közös objektumot találtuk részben megfelelőnek, majd annak az objektumnak a mintanyelvi kapcsolatain továbblépve találjuk meg az illeszthető mintát. Ennek szemléltetésére a 7.3 mellékletben a POSA2 mintakapcsolatok és a GOF mintakapcsolatok láthatók a 37. és 38. ábrákon. Az általunk javasolt keretrendszer lényege az, hogy össze tudjuk kapcsolni az architektúra mintanyelvek leírásából [Sch00] az architektúra elemeket a vizsgált szakterület összetevőivel. Az első munkaszakaszban a mintanyelv alapján készítjük el a koncepcionális tervet, melynek során a mintaelemeknek megfeleltetjük a szakterület elemeit. A megfeleltetés konzisztenciájának kimutatásával ellenőrizhető a mintaelemek és a szakterületi elemek kapcsolatának helyessége.
A mintaelemek
paramétereit
inkrementális
finomításban
konkretizáljuk, ezáltal a konkrét problématérnek megfelelő technológia független architektúra 59
modellt állítjuk elő. A fejezet további részeiben ezzel a kérdéskörrel foglalkozunk. Eredményeinket a [Med08, Med10] tanulmányainkban közöltük. Arra adtunk módszert és keretrendszert, hogy a mintákat és a mintanyelveket modellezési keretnek
tekintve,
gyorsfejlesztéssel
jussunk
implementációs
modellhez.
Ehhez
újrafelhasználható keretrendszerbe foglaltunk mintanyelveket az architektúra minták modellvezérelt fejlesztésével. Ezeknek a modelltermékeknek az újrafelhasználásakor a modellezendő szakterületet a minta egy példányának tekintjük. A minta példányosítása az a folyamat, amely során megnyilvánulnak a mintában azok a fogalmak, amelyek a szakterületi jelenségeket meghatározzák, valamint segítenek a szakterület fontos jelenségeinek a felderítésében és tulajdonságaik meghatározásában. Amikor valamire a mintából nem mutatkozik meg a megfelelője a valóságban, akkor felfedezhető a már azonosított valóságelemek kapcsolatait megvizsgálva, ha pedig nem találunk megfelelő részfunkciót vagy tulajdonságokat, akkor nem a vizsgált mintát kell illeszteni a problémára. Ilyen esetben gyakori, hogy egy másik mintával közös objektum került illesztésre a vizsgált mintában, ezért került előtérbe a probléma és a vizsgált minta közötti részleges egyezés, amelynek a kölcsönhatásaival kapjuk meg a mintát. Ezt azzal illusztráljuk, hogy a rendszerfunkciókba összevont szolgáltatásfüggő funkcionalitásokat a részletes tervezésben műveletcsoportokra különítjük el több független szerepben. Viszont a mintaalkalmazással ezt a finomítási műveletet megspóroljuk, de értelmezési szinten és megfeleltetési szinten a minta alkalmazásakor lezajlik a fejünkben ez a finomítási folyamat. Éspedig nyugtázással, amikor a jólismert terület elemeit összerendeljük a mintával és próbálgatásokkal a kapcsolatok mentén, amikor a vizsgált problématér informatikailag még fel nem tárt terület, és a fejünkben nincsenek már letisztult szervezési modellek a megfeleltetéshez. A mintaillesztés haszna ezeknek a szervezési és viselkedési elemeknek a végrehajtás-szintű elosztottsághoz való megfeleltetésben mutatkozik meg a mintaalkotók leképező szakértelmének megismétlésével. Ez egyben egy tanulási folyamat a mintaértelmezéssel és a gyakorlati esetek tanulmányozásával, valamint a konkrét feladatok irányított és önálló megoldásával. Példa a fentiekre azon eset, amikor ugyanazon mintaillesztési megfeleltetésen belül túl nagy szemcsézéssel haladunk, és a vizsgálatkor már részletes viselkedéselemekben gondolkodunk funkciók helyett. Ilyenkor nem feltétlen a megfelelő objektumot találjuk meg. Esetünkben hamarabb belebotlunk az interfész műveletek értelmezésekor a Wrapper Facade metódusába vagy az Extension Interface mintába, mint a Component Configurator minta adminisztrátori funkciójába, és ilyenkor már a mintaillesztésben nem egyeztethetők össze a 60
mintaelemek. Viszont, amint egyezőséget találunk valahol, annak az objektumnak az üzenetcseréi a kommunikáló felek közt végül elvezetnek a Component Configurator mintához. Erre szolgál a kölcsönhatások ábrázolása a mintaszövő modellezésünkben. A megfelelő szemcsézettséggel haladva a megfeleltetésben, az architektúra minta funkcionális szerepét feleltetjük meg a problématérben valamely célnak vagy fő szolgáltatásnak. Ezzel az implementáláshoz szükséges komponensekre és a zavartalan működéshez szükséges elosztottságra jutunk, épp az architektúra minták közötti kapcsolatokkal és a mintákon belüli objektumok kapcsolataival. Kiforrott szakterületi fejlesztésekben a szakterület rendszerelméletéből kapott ismeretek tanulmányozása segít a mintamegfeleltetésben, vagy fordítva, a mintamegfelelésekből kinyerhető a problématérben a szerepek és a szolgáltatások rendszerbe szervezése. Példa erre az elektronikus kereskedelem üzleti modelljeinek fejlődése az informatikai megoldások hatására. A fenti példa a mintaillesztés szemcsézettségével egyben megmutatja a 3. tézisben a keretrendszer építésének a hasznát. Az összeszőtt mintákkal a megoldástér több absztrakciós szintű nézetben átjárható, valamint egy gyorsfejlesztésben direkt leképezéssé válik az architektúra minták illesztése a problématérhez. Ez következik be az üzenetcsere diagramoknak a dinamikus rétegződése (ref operátor) által, valamint ebben az elemzést támogató és a részletes tervezési nézetbe átvezető kölcsönhatások objektumközi kapcsolataival. A dinamikus rétegződés egyben adja az egyidejű nézetet a funkcionalitás szemcsézettségére és a funkciók (szolgáltatások) kapcsolataira, a kezdő fejlesztő alapos munkájában is, de az inspekció során is. Ugyanígy a problématérben a kölcsönhatások mentén a problémateret is szétválasztjuk a minta diktálta objektumokra és viselkedés elemeikre. Azaz a mintaalkalmazással a problématér és a megoldástér megfeleltetése eredményezi a megoldásnak az architektúra és implementáció modelljét az elemek és a modulok szintjén a problématérre nézve. Ez egy optimális megoldást jelent az absztrakciós szintek egyidejű kezeléséhez, a beépített szakértői tudással (minták) és egyben a kontroll szintű visszahatással is. Ezáltal gyorsfejlesztést kapunk modellvezérelten, és a validált részletes tervezésből indulva visszatervezésben fel lehet építeni a problématér számításfüggetlen modelljét és elvi felépítését. 3.2.3 Újrafelhasználás szemléltetése minta alapú rendszerfeltárással és modellezéssel Mintaillesztéssel alkalmazhatjuk a mintagyűjteményt rendszerfeltárásra. A POSA2 mintanyelv esetén a vizsgált rendszer kommunikációs részrendszerének feltárására kerülhet sor PIM modellezéssel. A POSA2 mintanyelvet alkotó minták funkcióit illesztjük a vizsgált 61
rendszer kommunikációs modelljéhez. Az MDE folyamatra nézve az illesztett mintának a mintagyűjteményben levő modelljei input egységek a minta alapú modelltranszformációhoz (lásd 1.4 alpontban).
Számításfüggetlen leírásokból kiindulva a minták generikus modelljei
újrafelhasználásra kerülnek űrlap szerepben a modelltranszformációkban (több PIM rétegben),
specifikus
jellemzőkkel
kiegészítve
az
elemzés
és
részletes
tervezés
munkaszakaszokban. Példaként a rendszerfunkciók minta alapú feltárására és modellezésére alkalmaztuk a POSA2 Service Access and Configuration Pattern architektúra mintanyelvet a GSM hálózat kommunikációs modelljéhez illesztve. A GSM hálózat [Dár03] leírását és elvi összetételét vizsgálva keressük a minták kontextusának megfelelő GSM hálózati környezetet, a mintaleírásnak megfelelő célt és működési mechanizmusokat. A szolgáltatáselérési minták illesztését a GSM hálózat elvi felépítésén mutatjuk be a 15. ábrán. A mintagyűjtemény modelljeit újrafelhasználással fejlesztjük (mintaillesztéssel, mintaalkalmazással, GOF mintafelderítéssel), amelyek láthatók a 7.3 Mellékletben a 41.-44. ábrákon. A mintaillesztésben a szolgáltatásokhoz tartozó szerepköröket keressük és feleltetjük meg a minta szerepköreinek. A Service Access and Configuration Pattern architektúra mintanyelvet négy architektúra minta alkotja (lásd 3.1.1). Az előző alpontban bemutattuk a Component Configurator architektúra minta illesztését a GMSC híváskezelőre, amely felügyeli a kérésekre elindított konkrét híváskezelő komponensek példányait. Az Interceptor architektúra minta illesztését alkalmaztuk a GSM hálózat helymeghatározás frissítése szolgáltatásra. Amikor a mobil készülék nem a saját szolgáltatójának a körzetében tartózkodik, akkor a cella észleli a készüléket, és szükségesek az információ cserék és szolgáltatás engedélyezések a hazai és a látogató kliensadatbázisok (HLR, VLR) között. Alkalmazott minták: Extension Interface – OMC Interceptor - HLR, VLR Wrapper Facade – BSC, MSC Component Configuratot - GMSC 15. ábra GSM hálózat elvi összetétele (forrás [Dár03]) a fő funkciókkal a POSA2 szolgáltatáselérés és konfigurálás minták illesztéséhez
62
A Wrapper Facade architektúra minta illesztéséhez megvizsgáljuk a kapcsolódó felek számára nyújtott interfész szerepköröket, amelyeket a GSM hálózati funkciókban az átjátszó egységeken találunk meg, az MSC és BSC, valamint a BSC és a BTS egységek kapcsolataiban. A Wrapper minta illesztését megtalálhatjuk az Interceptor minta kapcsolatait követve is, a GSM rendszerben pedig a celláktól haladva a jelzés funkciók mentén a kapcsolóközpontokat. Az Extension Interface architektúra minta illesztéséhez megvizsgáljuk az interfészek csatolása funkciót, amelynek megfelelő funkció az OMC egység. Az OMC nyújtja az adminisztrátor számára a grafikus interfész vagy parancssori interfész csatolását (OMC a forrás ábrán nincs feltüntetve. A funkcióit tekintve a HLR, VLR, EIR, AuC egységekhez kapcsolódik). A mintaillesztéssel felderített rendszerfunkcióknak a modellezéséhez újrafelhasználjuk a modellgyűjteményből megfelelő PIM→PIM modelltranszformációt az illesztett minták modelljeivel, valamint a GSM hálózat fő funkcióinak számításfüggetlen szakterületi leírásaival. A GSM-specifikus mintagyűjtemény létrehozását és keretrendszerbe foglalását a 3.2.1 alfejezetben megadott Component Configurator példával kifejtett módon ajánljuk.
3.3 Módszer alkalmazása SDL alapú szakterületi fejlesztéshez Bármely szakterületen elemzéssel és szintézissel a szakterületre jellemző funkcionális kapcsolatok mentén újrafelhasználhatjuk a POSA2 mintákat egy mintanyelv létrehozásához szakterület-specifikus nyelveken. A POSA2 minták ilyen alkalmazása különösen előnyös, ha a szakterület-specifikus technológia alkalmas az elosztott rendszerek megvalósítására, és tartalmazhat szakterületi programtervezési mintákat is. MDE folyamatban létrehoztuk a 3.1.2 alpontban megadott módszer szerint az un. SDL Macro-Pattern mintanyelvet a rendszerstruktúra és viselkedések minta alapú fejlesztéséhez, a POSA2 architektúra tervezési minták és a GOF programtervezési minták alkalmazásával. Az SDL Macro-Pattern mintanyelv leírására a Specification and Description Language (SDL) [ITUz100] és Message Sequence Charts (MSC) [ITUz120] nyelveket alkalmaztuk (lásd az 1.5.3 alpontban).
Az SDL nyelv előnye, hogy implementációs szinten is alkalmazható
kódgenerálással Java és C nyelvekre. Az SDL Macro-Pattern mintanyelv több absztrakciós szinten alkalmazható, és fontos jellemzője, hogy a mintaleírás nyelve maga a fejlesztés nyelve. Az SDL Pattern Pool [Com02] a kommunikáló automaták viselkedési mintáit tartalmazza, amelyeket beleszőttük az SDL Macro-Pattern mintanyelvbe. Az SDL Macro-Pattern mintanyelv összekapcsolja az elosztott rendszereknek az elemzés és megvalósítás modelljeit átjárható és megismételhető módon. A mintanyelvbe beleszőtt 63
GOF programtervezési minták előnyösek a kódgenerálás utáni adaptációs fejlesztésben és a manuális kódfejlesztésben is. 3.3.1 SDL Macro-Pattern mintanyelv létrehozása A módszer bemutatására levezetjük az alábbiakban az SDL Macro-Pattern Component Configurator mintanyelv fejlesztésének lépéseit (lásd 13. és 14. ábrákon), amelyhez felhasználjuk a POSA2 Component Configurator [Sch00] mintaleírást (lásd leírás kivonata a 3.2.1 alpontban). A szakterületi nyelvek esetében, eltérően az UML fejlesztési célhoz épített keretrendszer építéstől, mintaalkalmazást jelent az objektum-orientált fejlesztésekből létrehozott POSA2 mintáknak a keretrendszerbe foglalása. Elemzés és szemantikus megfeleltetés szükséges a mintabeli fogalmak párosításához a szakterületi megfelelőikkel. Az SDL Macro-Pattern mintanyelv keretrendszerének jellemzői: 1. Cél: POSA2 architektúra minták SDL rendszerbe foglalása a minták összeszövésével, újrafelhasználható formában 2. Bemenet: POSA2 architektúra mintanyelvek és minták leírásai [Sch00] 3. Absztrakciós szint és termékcsoport meghatározása: PIM nézőpontból történik a strukturális és viselkedési nézetek előállítása (SDL system, block, process diagramokban) a követelményelemzés és részletes tervezés szakaszhoz. A kölcsönhatások specifikálása és elemzése az MSC diagramokban történik az implementáció leírásához szükséges programtervezési minták beleszövésével. Az újrafelhasználást segítik a modellezés során szerkesztett típusok a szerepkörök azonosításában. 4. A POSA2 architektúra minta mintagyűjteménybe szervezése: A POSA2 architektúra minták specifikálása az SDL Macro-Pattern mintanyelvbe egyszerű szemantikai megfeleltetéssel történik az
input elemek [Sch00] alapján. A leírásban levő
objektummodell fogalmak és a szakterületi nyelv fogalmainak a megfeleltetéséhez szükséges az elosztott rendszerek jellemzőinek felismerése és az alkalmazott szakterületi nyelv (DSL) ismerése, esetünkben az SDL és MSC nyelvek és a kommunikációs rendszermechanizmusok. Az SDL és MSC nyelvek fogalmainak, valamint az objektummodell fogalmaknak a manuális úton való szemantikus megfeleltetéséhez, osztályozást adtunk a [Med06] közleményben az ITU_T Z109 szabvány alapján [ITUz109/12]. A POSA2 mintáknak a kommunikációs szakterületen való újrafelhasználása mintaillesztéssel történik, amely során létrejön a statikus rendszerelemek és kölcsönhatásaik specifikációja. A dinamikus leírás fejlesztését szakterületi minták alkalmazásával a 3.3.2 alpontban ismertetjük.
64
A strukturális modellek minta alapú fejlesztésére a mintaalkalmazás lépéseit az alábbi Struktúra 1-3. lépésekkel mutatjuk be. A Component Configurator minta esetében felhasználjuk a 3.2.1 pontból az input mintaleírást a 10. ábrával. Az ábrán a bal oldali UML struktúrában láthatjuk a komponens konfiguráló szerepkört a Component Repository és Component Configurator együttessel. Ez implementálja az igényelt komponenst, majd csatlakoztatja, inicializálja a komponens működését. A komponens futásának felügyelete a 10. ábrán a jobboldali UML állapotgráfon látható a futás közbeni eseményvezérelt felfüggesztés, újrainicializálás, jelentésadás, bevégeztetés műveletekkel. Struktúra-lépés 1. A kommunikációs elemek és kapcsolataik példányosítása. A mintaleírásnak megfelelően meghatározzuk a funkciókat a kommunikáló objektumok típusaival. A mintának megfelel a Block Type típusú kommunikáló objektum mint részrendszer, amely kapcsolatban áll a többi mintával. Az elemei a minta osztályainak megfelelően egyenként a Process Type típusú kommunikáló automaták példányai és ezek kölcsönhatásai. A Component Configurator minta esetében (lásd 13. ábra) azonosítjuk a CompConfig azonosítójú blokk típusú részrendszert és ebben a processz típusú strukturális elemként a kommunikáló automaták példányait. A Component (0...max) processz futás közben jön létre a telepítéskor engedélyezett max példányszámban. A Configurator és Repository processzek a rendszerrel egyidőben jönnek létre az alapértelmezett egy példányban. Struktúra-lépés 2. A kommunikációs események azonosítása és a szolgáltató szerep inicializálása. Az elemzés eszközeként alkalmazott MSC nyelv alap diagramjait hozzuk létre, az időben egymásra következő üzenetcserék ábrázolásával egyben a kontroll és konfiguráló események modellezésére. Az MSC nyelvnek az egységes modellező nyelvbe való integrálásával azonos lesz az előállított MSC diagram és UML2.0 szekvencia diagram, esetünkben a 12. ábrán látható modellrészlet. A mintaalkalmazásban megfeleltetéssel kapott rendszerelemekre hozzuk létre az MSC diagramot a kommunikáló felek együttműködésének modellezésére. A kommunikáló felek konkrét példányok, amelyek részvétele a kommunikációs eseményekben a kiinduló és beérkező üzenetek sorrendjében történik. A kommunikációs eseményeknek megfelelő üzenetcseréknek (Init(), Suspend(), Resume(), Fini(), Insert(), Run(), Remove()) a sorrendje meghatározható a mintaleírásból. A fellelhető alternatívák és konkurens jelleg ábrázolásához alkalmazzuk az MSC szintaxisnak az alt, par, cor, exp operátorait. Szakterületi nézőpontból, ebben a lépésben áll elő a dinamikus viselkedés elemzéséhez szükséges modell, amely 65
újrafelhasználható a viselkedés modellezésében, verifikálásában és validálásában (lásd a technológiai sor tárgyalása 2.2 alfejezetében). Struktúra-lépés 3. Az architektúra modell finomítása. Szükséges a Struktúra-lépés 1. pontban létrehozott Block Type diagram kiegészítése a Struktúra-lépés 2. pontban feltárt kölcsönhatásokkal. Megjelenítésük a csatorna, üzenet, jel, jellista (Channel, Signal Route, Gate, Signallist, Signal) típusos szerkezetekkel történik, az azonosítók ráhelyezésével (lásd 13. ábrán) a kapcsolatot jelentő csatorna szimbólumra, utóbbiak a részek közötti kétirányú összekötő vonalak és jelöléseik a 16. ábrán. Struktúra-lépés 4. Az architektúra- és kölcsönhatásmodell finomítása a GOF minták szövésével. Az architektúra és kölcsönhatás modelleket finomítjuk a vonatkozó GOF minták felhasználásával. A POSA2 minták leírásában az implementációhoz javasolt GOF mintáknak az alkalmazását végezzük megfeleltetéssel. Ennek módja a következő: a struktúra részeként, rendszerszinten specifikáljuk a GOF minta nevével az eljárást, amely az öröklési hierarchia részévé válik. Bővíteni kell a rendszerdiagram System SDL_Macro_Pattern fő egységet a mintaleírásban
megadott
összefüggésekkel
összhangban.
Ehhez
eljárás
kijelölő
szimbólumokkal egyenként megadjuk a vonatkozó GOF mintákat, valamint bővítjük az MSC diagramot a referenciahivatkozásokkal a vonatkozó GOF mintákra. Külön MSC diagramban szükséges létrehozni a referencia operátorral specifikált GOF mintának a részletező MSC diagramját.
Conf_Directive Block Type CompConfig
Admin RAdm
CD
RepAdm
Directive
Configurator Component
1(2)
ControlR
Cf_Rep C_Conf
ControlC
Repository ConfigR
ConfigC SCompRep
Codex_D g1
Cp_Rep g2
Concret:Component
SRepComp
16. ábra Block Type CompConfig: Component Configurator minta struktúra modellje SDL blokk diagramban
A munkaszakasz eredménye a bővített SDL rendszerdiagram. PIM-PIM transzformációval áll elő a System SDL_Macro_Pattern SDL rendszer, amelyben a blokkok a POSA2minták, 66
ezek kölcsönhatásai a POSA2 mintanyelv mintaközi kapcsolatai láthatók a 31. és 32. ábrákon, az eljárások pedig a GOF minták. A viselkedésspecifikáció MSC diagramjainak finomítása a vonatkozó GOF mintákkal megegyezik a 3.2.1.1 alpontban, a Mintanyelv fejlesztése feladattal. Az eredményként létrejött MSC modellek képezik az SDL Macro-Pattern mintanyelv részeit és a viselkedés szakterületi nyelvű modellezéséhez a bemenetet. A Struktúra-lépés 3. és 4. munkaszakaszokban, a létrejött MSC modelleknek a transzformálásával SDL állapotátmenet gráfokba, megkapjuk az SDL implementációs modellt és az automatikus kódgenerálás lehetőségét. A transzformációhoz a lépéssorozatot a 3.2.1 alfejezetben megadott módon javasoljuk. A Component Configurator példára nézve, az MSC diagramok megegyeznek a 3.2.1 alpontban kapott szekvencia diagramokkal (7.3 Melléklet -41.ábra). Az SDL Macro-Pattern mintanyelvet az előzőekben tárgyalt módon fejlesztjük, amelyhez javasoljuk a 2.1.1 alpontban tárgyalt 1.- 6. számú technológiai sorokat. Végeredményül, az újrafelhasználható SDL Macro-Pattern mintanyelv keretrendszere a következőkből áll:
SDL Rendszer – System SDL_Macro_Pattern rendszerdiagram a POSA2 mintanyelvre
SDL Részrendszerek – Block Mintanév Type blokkdiagram a mintaszerkezetre
MSC Kölcsönhatások – MSC Mintanév kölcsönhatás diagram a mintakapcsolatokkal
SDL Folyamatok – Process Mintanév_tevékenység processz (SDL állapotgráf) diagram előállítása
szakterületi
mintákkal
és
MSC
elemzéssel/transzformálással
(3.3.2
lépéssorozattal). 3.3.2 Lépéssorozat
MSC
elemzéshez
és
transzformáláshoz
SDL
állapotgráf
létrehozására 1.-3.
lépésekben
az
MSC
diagramok
leképezése
és
megjelölése
történik
a
modelltranszformációhoz, a 4. lépésben a modelltranszformáció történik egy-egy MSC kommunikáló félre nézve. 1. Érvényes állapotok hozzárendelése a bemeneti jelekhez. Ehhez megvizsgáljuk sorra az egyes MSC kommunikáló példány input üzeneteit, és megjelöljük a bemeneti feltételt. A vizsgált MSC kommunikáló fél ellenőrzéséhez a vizsgálatot a kommunikációban levő kommunikáló felekre párban végezzük, mivel az üzenet küldője és fogadója jelenti a kommunikáló automatákat, amelyek üzenetcseréjét és állapotváltozásait rögzítjük az egyes küldő-fogadó feleknek megfelelő SDL állapotgráfban (a 4. lépésben).
67
2. Biztonsági intézkedések modellezése. Megvizsgáljuk a kommunikációs eseményhez szükséges kapcsolat típusát, amely lehet összeköttetéses vagy összeköttetés nélküli és megbízható vagy megbízhatatlan. Ennek megfelelően állítjuk be az üzenetcserék protokollját és ellenőrzését az ismételt üzenetküldéseknek megfelelő idő, ismétlések száma, hibakezelés módja paraméterekkel. Kiegészítjük az MSC diagramokat az üzenetkezelés protokolljának megfelelő iterációk, alternatívák, pozitív és negatív forgatókönyvek szerkezeteivel. 3. Összetett állapotok szervezése. Amennyiben szükséges a megbízható kapcsolat az üzenetküldéshez, szétbontjuk az elemzés során nyert MSC diagramokat. Ennek megfelelően a kommunikációs
eseményekhez
szükséges
kapcsolat-felépítés,
üzenetküldés
és
kapcsolatlebontás funkciók külön MSC diagramokba szervezve egyenként összetett állapotot alkotnak. Ezek alapján modulárisan fejleszthető az SDL állapotgráf, növekszik a módosíthatóság, újrafelhasználásuk több absztrakciós szinten lehetséges, mint a verifikálás és validálás. 4. SDL állapotgráf fejlesztése az MSC modellek alapján. Az egyes MSC kommunikáló felekre modelltranszformációt végzünk (manuálisan az 1.-3. lépésekkel). Az egyes MSC kommunikáló példány életciklusát követve a modelltranszformációkban előállítjuk az SDL állapotgráfokat a Block típusú struktúra modellben megadott automatákra. A megfeleltetések a transzformációkhoz: MSC instance – SDL process diagram; MSC input, output, action műveletek ua. az SDL állapotgráfban; MSC feltétel – SDL állapot; inline operátorok – SDL megvalósításuk: MSC alt – SDL decision művelet; MSC loop – SDL kiinduló és következő állapot azonossága, kiegészítve az állapotátmenet kontroll szerkezetében az ismétlések számával; MSC par – mindkét automata ugyanazon állapotba kerül, MSC cor – SDL save; MSC ref – SDL call. Az MSC kommunikáló feleknek a transzformációja SDL process specifikációba lehetővé teszi, hogy az SDL fejlesztésekre az MSC legyen a követelményelemző technológia. Az MSC-SDL megfeleltetés a fenti lépéssorozatban PIM→PIM modelltranszformációt képez. 3.3.3 SDL Macro-Pattern és a GOF programtervezési minták összeszövése Ebben az alpontban ismertetjük a szakterületi nyelv implementációs lehetőségeiből adódó modellezési variációkat, elsőként az SDL Macro-Pattern mintanyelv bővítését az implementálható PIM modellekkel. Ehhez módszert adunk a viselkedés elemzésére szolgáló MSC modellek transzformációjára implementációs modellekké. Az előzőekben tárgyalt minta alapú MDE folyamatot támogató keretrendszert kiegészítettük a szakterületi programtervezési minták illesztésével és keretbe foglalásával. 68
Míg a POSA2 architektúra minták hasznosnak mutatkoznak bármely elosztott szervezésű szakterületen a követelmény és architektúra modellek közötti döntési helyzetek áthidalására, addig a szakterületi programtervezési minták a szakterület jellegzetes számítási műveleteihez nyújtanak kulcsmegoldásokat a részletes tervezés eszközeiként. A módszerjavaslatunk az MDE folyamat minta alapú felépítéséhez kiterjed a szakterületi programtervezési
minták
alkalmazására
az
SDL
Macro-Pattern
mintanyelv
továbbfejlesztéséhez. A továbbfejlesztés menete az MDA transzformációknak az Y minta szerinti iterációjában (1ásd bal ábra) zajlik, és a PIM rétegek újabb bővítését eredményezi [OMG00].
Esetünkben az előzetesen POSA2 és GOF alkalmazással előállított PIM modell az Y
baloldali ágán jelölésként kapja meg az MSC diagramon a ref operátorral, a modellezésbe az Y jobboldali ágán mintaillesztéssel bejövő szakterületi programtervezési mintákat (lásd 17. ábra).
Rákövetkezően
a
modelltranszformáció
folyamán
megjelölt
szakterületi
programtervezési minták beleszövődnek az újonnan előállt viselkedésmodellbe (lásd 18. ábra). Ezzel létrejön a keretrendszerbeli POSA2 architektúra minta modelljeinek a végső PIM állapota az eddigiekben SDL Macro-Pattern mintanyelvként összesítve. Ezt a viselkedési szakterületi mintákkal bővítve megkapjuk a PSM implementálható modellt. 3.3.4 SDL Macro-Pattern és az SDL Pattern szakterületi minták összeszövése Az SDL Macro-Pattern mintanyelv keretrendszerébe befoglaltuk mintaszövéssel az SDL Pattern Pool szakterületi viselkedési mintákat, MDE fejlesztési folyamatban. Az így létrejött implementációs modell újrafelhasználása egy részletes tervezésben MDE gyorsfejlesztést eredményez. A mintaszövés technikáit részletesen ismertettük a 3.2.1.1 alpontban. Ebben a leírásban az MDE folyamatra helyezzük a hangsúlyt. A módszer szemléltetéséhez felhasználjuk a POSA2 Component Configurator mintának az előzőekben a 12. ábrán bemutatott kölcsönhatásmodelljét, amelyet továbbfejlesztettünk az SDL Pattern mintákkal. Az SDL Pattern Pool egy újrafelhasználható mintagyűjtemény az un. SDL Fragments szerkezeti egységek újrafelhasználásához a kommunikáló automaták viselkedésében [Got03]. A mi tervezési nézetünkben ezek a minták lefedik a kommunikációs kapcsolatok típusai és az üzenetküldés
szabályai
szerinti
kontroll
tevékenységeket.
Például
a
megbízható
összeköttetéses típusú kapcsolatban a kommunikációs folyamat szakaszai kötelezően a kapcsolatfelépítés, adás, kapcsolatbontás. Az üzenetküldés szolgáltatásban a szabályelemek az ismétlések száma, a várakozások időegységei, a küldő-fogadó fél számára előírt nyugtaadás és válaszadás
módozatai.
Ezek
az
összefüggések
a
kapcsolattípus,
kommunikációs 69
folyamatszakasz és üzenetszabály, amelyekre az SDL Pattern Pool un. SDL Fragments szerkezeti egységeket fogalmaz meg szakterületi mintaként SDL nyelven. Az SDL Fragments szerkezetek modellezik a kommunikáló felek együttműködését és ezek kontrollját a kommunikációs esemény típusa szerint atomi műveletekre lebontva, amelyek az állapotátmenet részei az üzenetkezelési szabályok modellezésére. Ezek a minta szerkezeti egységek csoportokba vannak szervezve a hibakezelés, az időkezelés, az üzenetcsere irányítására [Got03]. Az SDL Patterm Tool (SPT) szerkesztő automatizálja a minták kiválasztását és az SDL állapotgráfba illesztésüket [Got03b] az SDL specifikációk szerkesztéséhez. A mi módszerünkben az újdonság az SDL fragment minták alkalmazásában az, hogy az elemzés eszközeként alkalmazzuk hibakezelésre és hibatűrésre az üzenetcsere sorozatoknak a finomításához kontroll elemekként az MSC specifikációkban. Az MSC diagramon az SDL Pattern alkalmazása azért előnyös, mert az SDL Fragments egységek a küldő-fogadó fél kölcsönhatására párban adják az atomi tevékenységeket. Ezért is, mi a mintaillesztés hatékony módjának tartjuk a szükséges minták helyét kijelölni az MSC kommunikáló (küldő és fogadó) feleknek a kommunikációjában a ref távoli eljárás referencia nyelvi szerkezettel. Minden egyes kezelni kívánt üzenetre az MSC specifikációkban mintanevekkel kijelöljük az SDL Fragments szerkezeteket. Az MSC specifikációk transzformálásakor az SDL állapotgráfba (3.3.2 alpont) párban kezeljük az SDL automatákat, amelyek megvalósítják a küldő-fogadó fél viselkedését. Az üzenetcserék leképezésekor (3.3.2 alpont 4. lépés) illesztjük az SDL Fragments szerkezeteket a küldő és fogadó felek állapotgráfjaiba, közben definiáljuk (lásd 3.18. ábra) az ehhez szükséges időautomatát és ismétlést kezelő típusokat és változókat is. Ezáltal az MSC forgatókönyvek és az SDL állapotgráfok (process diagram) tartalmazzák a kommunikációs folyamat típusának megfelelő állapotátmeneteket a normál és a hibaesetekre egyaránt. A módszer eredménye egy átjárható és verifikálható modell, mivel dokumentálásra kerül a mintaillesztés az MSC részletezésekkel. Ezek a modellezési folyamatban a mark és mapping modellvezérelt modellezési tevékenységekkel szakaszolják a modellezés folyamatát, átjárhatóságot
biztosítanak
a
kommunikáló
automaták
állapotátmeneteihez,
és
a
verifikálás/validálás folyamatában alkalmazhatók a composite state fogalomhoz kapcsolt ismert módszerek és eszközök. A következőkben bemutatjuk az SDL Pattern Pool mintáinak újrafelhasználására a mintaillesztést, a mintaalkalmazást felderítéssel és a mintaszövést, amelyhez az SDL MacroPattern mintanyelvből a Component Configurator POSA2 mintára a CompConfig MSC specifikációt (lásd 12. ábra) alkalmazzuk. 70
MDA fogalmakkal kifejezve, a keretrendszerben a mintanyelvek MDE termékek, amelyeket a különböző absztrakciós szintű szoftvertervezési minták modellezésével és modelltranszformációival fejlesztünk. Az MDE folyamatban újrafelhasználásnak számít a keretrendszer elemeinek az alkalmazása template, mark, map, pattern elemekként a PIMPIM/PIM-PSM modelltranszformációkban. Az input PIM modell megjelölésének felel meg a mintaillesztés, a leképezésnek és megjelölésnek felel meg a mintaalkalmazás és a mintaszövés.
Együtt
mindezeket
takarja
a
modelltranszformációval
megvalósuló
újrafelhasználása a keretrendszerbeli modelltermékeknek. A keretrendszer elemeinek létrehozásához a szoftvertervezési minták modellezése és modelltranszformációi ugyanazon természetű modellvezérelt tevékenységek, mint az újrafelhasználásukhoz szükséges tevékenységek. A különbség annyi, hogy míg a keretrendszer létrehozásához a szakértők fejében van a kiinduló kontextus a problémamegoldás elemeivel a mintaleírásokból, és azokat absztrakt jelenségekhez rendelik a szoftvertervezési minták kapcsolataival meghatározott függőségek alapján, addig a keretrendszer újrafelhasználását végzők támogatást kapnak a keretrendszer elemeinek a sablon jellegéből, amelyek a megoldástérben azonosíthatók és adaptálhatók megfeleltetéssel a valós rendszerbeli jelenségekre. Ezáltal a szakértők tudását a mintanyelvek fejlesztésének modelltermékei közvetítik akár a kezdő tervezők számára is egy modellvezérelt fejlesztéshez, amely
már
jelentős
termelékenységet
jelent
az
újrafelhasználáshoz,
a
szokásos
mintaleírásokhoz képest. 3.3.4.1 Az SDL Pattern Pool minták felhasználásának menete Mintaillesztés és mintaalkalmazás felderítéssel: SDL Pattern Pool [Com02] Interaction és Error mintacsoportok vizsgálata A kommunikációs folyamat jellemzőit meghatározva választhatjuk ki a szükséges mintát. A Component Configurator mintában a komponens dinamikus konfigurálása művelethez szükséges a megbízható és összeköttetéses üzenetküldés, amelyek programozására megoldást nyújtanak a megvizsgált Interaction és Error mintacsoportok. Az üzenetküldés szabályaira, az üzenet megismétlésére és a kommunikációs esemény visszaigazolására azonosítjuk az Interaction csoportban a BlockingRequestReply és SendReceive mintákat, amelyeket alkalmazunk a Component Configurator minta init() és insert() üzenetei kezelésére. Ezeket a ref távoli eljáráshívással jelöljük ki az MSC üzenetsor diagramon (lásd 17. ábra) a Configurator és Repository felek kommunikációjában, valamint a Configurator és Concrete
71
Component között. Hasonló lépéseket alkalmazunk a Run(), Fini(), Status() kommunikációs események kezelésére is.
17. ábra MSC diagram a Component Configurator minta belső kommunikációjával és ebben a hibakezeléshez és hibatűréshez szükséges SDL Pattern mintaegységek kijelölése
Az init(), insert() műveletekhez szükséges üzenet- és hibakezelő minták a következők (lásd 17.
ábra):
a
BlockingRequestReply,
TimerControlledRepeat,
SendReceive
DuplicateIgnore,
üzenetkezelők,
TimerControlledRepeat,
valamint
a
DuplicateHandle
üzenetküldés hibakezelésére az ismételt üzenetküldés szabályainak ellenőrzéséhez szükséges minták az Error csoportból (ismétlések száma és időzítése). A visszaigazolás hiányában a BlockingRequestReply
mintához
szükséges
az
üzenet
megismétléséhez
a
TimerControlledRepeat minta, amennyiben nem érkezik meg a nyugta. Az ismételt küldésekből eredő üzenettöbbszörözés hibakezelésére szükségesek a DuplicateIgnore, DuplicateHandle minták. A mintákban résztvevő kommunikációs felek az interakció minta illesztésekor meghatározott Component és Repository objektumok. Ezekre alkalmazzuk a PositiveAcknowledgewithRetransmission mintát a visszaigazolás küldéséhez. A minta szolgáltatáskezelő objektumának a kiválasztása: A Component Configurator minta szolgáltatáskezelő egysége a Configurator, amelynek feladatához a CoDex mintát illesztjük, amelyet alkalmazunk a szolgáltatáskérés értelmezésére és végrehajtására. A CoDex minta alkalmazásához
felderítjük
a
minta
paramétereinek
megfelelő
modell
elemeket:
LocalCommunicatingEntity megfelel a Central Administration Point elemnek a konfigurálás során, AdaptedEntity megfelel a Configurator szerepnek, és a BasicService megfelel a 72
Concrete Component szerepnek. Hasonlóan járunk el a Directive() és Report() szolgáltatáskérések minta alapú elemzésében. A minták kijelölése az MSC modellben: a ref referencia operátorral sorközi beszúrást végzünk és megjelöljük a minták helyét az üzenetküldés diagramon (lásd 17. ábra). A Component Configurator POSA2 mintában az üzenetkezelés és hibakezelés modellezéséhez szükséges SDL Pattern mintákat a 4. Táblázat foglalja össze. 4. táblázat ComponentConfigurator mintához illesztett SDL Pattern Pool minták
Kommunikáló felek Config-env
Directive(),
ConfigComponent ConfigRepository Config-env
Üzenet
Init(); Insert(); Report();.
SDL Fragments elemek mindkét kommunikáló automatához egy üzenetküldés eseményben CoDex(); BlockingRequestReply, TimerControlledRepeat, DuplicateIgnore BlockingRequestReply, TimerControlledRepeat, DuplicateIgnore SendReceive, TimerControlledRepeat, DuplicateHandle, CoDex CoDex, BlockingRequestReply, TimerControlledRepeat, DuplicateIgnore
A minták azonosítóiból képezzük aláhúzás jellel a kijelöléshez szükséges hivatkozást. Az elemzésben a mintaszövéssel egyben előkészítjük a modelltranszformációt az SDL állapotgráf létrehozásához (17. és 18. ábrák), amelynek technikáit a 3.3.2 pontban adtuk meg. process Configurator
1(2)
TIMER repeatTimer; DCL noOfRepeats integer; DCL maxNoOfRepeats integer:= n; DCL timerInterval duration:= t; DCL ConfMessage Conf_Type; waitForAckReply_n
ConfActive ack_reply_n Directive
CoDex (Directive, ConfMessage_n)
repeatTimer
RESET (repeatTimer)
ConfActive
noOfRepeats= maxNoOfRepeats
true
false noOfRepeats:= noOfRepeats+1
ConfMessage_n error_n
SET ( NOW + timeinterval, repeatTimer)
SET ( NOW + timeinterval, repeatTimer)
noOfRepeats:=0
waitForAckReply_n
ConfActive
ConfMessage_n
-
18. ábra SDL állapotgráf (processz diagram) részlet a Config automata viselkedés modelljébe (17. ábra) beleszőtt SDL Fragments elemek beleszövésével
Az SDL Pattern Pool minták SDL Fragments elemeinek az átírása az SDL állapotgráfba mechanikus szerkesztési műveletté válik, az elemzésben létrejött MSC diagramok és az SDL 73
Fragments mintaelemek egyidejű alkalmazásával. Az SDL állapotgráfot létrehozhatjuk a mintákkal megjelölt MSC diagramból kiindulva az SDL minták alkalmazásához fejlesztett SPT eszközben [Dor05], amely lehetővé teszi a kijelölt SDL Fragments mintaszerkezetek automatikus beillesztését a szerkesztett SDL diagramba. 3.3.5 SDL Macro-Pattern mintanyelv újrafelhasználásának lépései A minta alapú SDL fejlesztésben az SDL Macro-Pattern mintanyelv újrafelhasználásával átlépjük az MSC elemzés szakaszt, és az SDL diagramokat használjuk sablonként a minta és a vizsgált rendszer elemeinek megfeleltetéséhez. Amennyiben a megfeleltetésben a minta nem fedi le a modellezni kívánt részrendszert/funkciót, úgy az MSC diagramokat alkalmazzuk a minta adaptálására a viselkedések elemzésével és a modelltranszformáció kiegészítéséhez. Az SDL Process diagramok sablonként való alkalmazásának előnye, hogy az SDL fejlesztőkbe
beépített
modellellenőrzők
MSC
Tracer
szimulátort
alkalmaznak,
és
automatikusan generálják SDL processz diagramból az MSC transzformációt az automaták specifikációinak verifikálásához. Az SDL Macro-Pattern mintanyelv alkalmazásának menete megfeleltetéssel: 1. Mintaillesztést végzünk a POSA2 mintaleírás alapján [Sch00] és a vizsgált rendszerfunkciók leírásai alapján. 2. A kiválasztott POSA2 mintának megfelelő modellek és kapcsolataik feltérképezése az SDL Macro-Pattern mintanyelvben. 3. Az SDL Block Mintanév diagramot kell alkalmazni sablonként. Ebben meg kell határozni az SDL automatáknak (Process objektumnév) megfelelő vizsgált rendszer funkciókat és ezek tevékenységeit a kommunikációs csatornákra helyezett üzenetekbe kódolt eseményeknek megfelelően. 4. A viselkedés modellezéséhez az SDL Process típusú diagramokat kell használni a rendszerfeltárásban meghatározott SDL Block Mintanév diagramnak megfelelően. Az SDL specifikációkban a rendszerszintű jellemzők öröklődnek a résztevékenységekre. Ezáltal a Process Mintafunkció_név sablonok átírása a rendszerfeltárás alapján történő megfeleltetést jelenti az üzenetek, állapotok, résztevékenységek megnevezésére nézve. Továbbiakban a Process diagramokban a lokális változókat kell meghatározni az időkezelés paramétereire és az ismételt üzenetküldés szabályainak ellenőrzéséhez. Ezek beállítása elemzéssel vagy a szakterületi szabványok alapján történik. 5. Amennyiben a POSA2 minta részlegesen illeszkedik, akkor adaptálást és ehhez elemzést végzünk a mintanyelvből vett MSC specifikációk módosításával. Esetenként eldönthető, hogy 74
az adaptációs elemzés után MSC-SDL modelltranszformációt végzünk vagy a mintanyelvben az SDL Block és SDL Process diagramok módosítását követjük. Az adaptációban az átjárhatóság megőrzéséhez és a módosítások elkülönítésére javasoljuk az MSC decomposition szerkezetet és az SDL service vagy procedure szerkezeteket. A Component Configurator POSA2 és a GSM példa esetében, amint vizsgáljuk a mintaleírásban a cél és funkció jellemzőket, majd ezeket összevetjük a GSM hálózat funkcióival, már az első vizsgálatra adódik, hogy a minta megfelel a GMSC híváskezelő központ funkcióinak. Tovább vizsgálva a minta objektumait és a vizsgált rendszerfunkció résztevékenységeit, azonnal adódnak megfelelések a feladatok természetéből a leírások alapján. Például a híváskezelés funkciót a Configurator és Concret Component objektumok valósítják meg, a Repository funkciókkal a több mobil állomás hívásának egyidejű kezelését valósíthatjuk meg. Például az init(), run() metódusokat megfeleltetjük a kapcsolás és a hívás állapotnak és ehhez tartozó üzeneteknek. Amint ezeket a strukturális megfeleléseket megtaláltuk, a struktúra sablon elemeit kell átírni a funkciók, részfunkciók, tevékenységek GSM rendszerbeli fogalmaira (19. ábra), és a vonatkozó viselkedéselemek sablonjait vizsgálni és átírni a megfeleltetett paramétereket (20. ábra). fromCell block GSMConfig
A
ISDN
MSC_ISDN
msg,handoff, callPhone
callPhone, msg, handoff, connectionStatus
GMSC_Config D_C
C A_E msg,connectionStatus, handOff,connected
1(1)
callPhone, msg, handoff, connectionStatus
msg,handoff, callPhone
callPhone, connectionStatus
GeneralManager
E E callHandler:Component
19. ábra SDL Macro-Pattern mintanyelvből a Component Configurator minta CompConfig modelljének újrafelhasználása a GMSC híváskezelő funkcióinak specifikálására
A mintaszövés hasznosságát felmérhetjük az SDL állapotgráf gyorsfejlesztéséhez a 18. és 20. ábrák összevetésével, ahol azt találjuk, hogy a bejövő és kimenő üzenetek nevei kerültek átírásra, a deklarációs részben az időparaméterezés, valamint a CoDex eljárás. A 18. és 20. ábrákon azonosnak látható részek mind az SDL Fragments mintaegységek újrafelhasználásai az üzenetek kezeléséhez és a kommunikáció típusának megfelelő hibakezeléshez. Az elemzésben a kölcsönhatás diagram áttekinthetőbb eszköz a kommunikáló felek és kapcsolataik típusának vizsgálatához, mint a kommunikáló automata állapotátmenet gráfja, 75
amely a küldő és a fogadó felekre párban nem kezelhető egy látványban, ha pedig az SPT szerkesztőt alkalmazzuk ehhez [Got03], akkor az elemzés eszközei hiányosak vagy csak szakértő végezheti a mintaalkalmazást a szerkesztés felgyorsítására. Hatékonyabb minden munkaszakaszban az SDL Fragments mintaegységek kijelölése az MSC diagramon a küldő-fogadó párosra, ugyanakkor átjárhatóságot biztosít úgy a modelltranszformációk, mint az adaptációk során is.
20. ábra SDL Macro-Pattern mintanyelv CompConfig állapotgráf sablon paraméterezése a GMSC híváskezelő folyamatának specifikálására (részlet)
3.4
Összefoglalás a 2. Tézis tárgyalásáról
Ebben a tézispontban azt javasoltuk, és adtunk hozza eljárást és esettanulmányt, hogy a szoftvertervezési
minták
alkalmazásával
hozzunk
létre
keretrendszerbe
gyűjtve
újrafelhasználásra kész, egymással összeszőtt generikus mintanyelveket, akár az egyesített modellező nyelven, akár más szakterület specifikációs nyelvén. Az első tézispontban módszert és esettanulmányt dolgoztunk ki az architektúra minták és mintanyelvek, valamint a programtervezési minták újrafelhasználásával egy generikus mintagyűjtemény létrehozására és újrafelhasználására UML fejlesztésekhez, elemzésre és tervezésre. A második tézispontban módszert és esettanulmányt adtunk SDL szakterületi specifikációs nyelven az SDL Macro-Pattern mintanyelv fejlesztéséhez és újrafelhasználásához elemzésre és tervezésre. Az SDL Macro-Pattern mintanyelvet az elemzés-tervezés-megvalósítás szakaszokra hoztuk létre modellvezérelt fejlesztéshez, a POSA2 architektúra minták és
76
mintanyelvek, a GOF programtervezési minták és az SDL Pattern
szakterületi
programtervezési minták újrafelhasználásával. Célunk, hogy újrafelhasználható módon közvetítsük a modellekkel a szoftvertervezési mintákban
meglévő
formalizált
objektumtechnológiákra,
szoftvertervezési
komponenstechnológiákra
tudást és
oly
módon,
szakterületi
hogy
az
mechanizmusokra
kidolgozott szoftvertervezési mintákkal fejlesszünk újrafelhasználható mintanyelv modelleket a fejlesztés menetének megkönnyítésére. Az így létrehozott gyűjtemény hitelességét biztosítja a szakértők mintaalkalmazó tevékenysége és a modellellenőrzés. A szoftvertervezési minták újrafelhasználásának helyességét szabályozza a minták modelljeinek sablonként való megfeleltetése. A kutatás további iránya a mintagyűjtemény bővítése (POSA1-5 – [POS12]). Másik hasznos irány az absztrakciós szintek növelése a modellgyűjteményben az URN technológiákkal a minták modellezésével [Mus02, Mus07, Buh96], amely a szolgáltatások fejlesztésében hasznosítaná a POSA2 mintagyűjtemény alkalmazását. A mintanyelvek felhasználásának lényege a modelltranszformációkban mutatkozik meg: az implementációs modell a modellgyűjteményből szintézissel előállítható. Esetünkben a szintézis eszközeit a formális specifikációk és a szoftvertervezési mintákkal közvetített tervezési ismeretek jelentik, amelyekhez a modellvezérelt technológiákkal egyre több automatizált
támogatást
kapunk.
A
szoftvertervezési
minták
újrafelhasználása
az
automatikus/manuális modelltranszformációkban hozzájárul a fejlesztők támogatásához, a munkafolyamat hatékonyságához, a modelltermékek jóságához és átjárhatóságához a szakértők tudásának közvetítésével.
77
4
MODELLVEZÉRELT
ELV ALKALMAZÁSA EVOLÚCIÓS FEJLESZTÉSHEZ AZ
ÜZLETI TERÜLETEN
Ebben a fejezetben kidolgoztuk a 3. Tézist: 3. Tézis. Módszerfejlesztés az üzleti folyamatok változáskezelésére modellvezérelt fejlesztésben. 3.1
Egy sémát adtunk technológiai sor létrehozására az üzleti terület modellvezérelt
fejlesztéséhez, a távközlési területen szabványosított ITU-T System Design Languages nyelvcsalád elemeivel az 1.1 és 1.2 tézispontok technológiáira építve. 3.2 inspekció
Ipari alkalmazással alátámasztott módszertant adtunk az üzleti folyamatok specifikálására és lebonyolítására
kooperatív
munkaszervezéssel
folyamatgazdák,
üzleti
elemzők,
minőségfelelősök és modellfejlesztők együttműködésében a 3.1 tézispont technológiáira építve. 3.3
Ipari alkalmazással alátámasztott módszertant adtunk a 3.1 tézispont technológiáira
alapozva keretrendszer építésére változáskezeléshez, az üzleti folyamatok és stratégiák együttes kezelésével az érdekelt felek által. 3. Tézis közleményei: Med07, Med08b, Med10c, Med11, Med11c, Med11d, Med12, Med12c. További publikációink a témában: Óvá07, Med09, Med09b.
Az informatikai rendszerek létesítésének és üzemeltetésének tervezésében a modellvezérelt technológiák sok előnyt nyújtanak az aspektusok és az újrafelhasználhatóság támogatásával. Ez előnyös az üzleti területen, ahol a szervezeti struktúra állandó fejlődésben van az üzleti stratégiák mentén, és a szoftverrendszerek számos érdekelt célcsoport szükségleteit elégítik ki. Napjainkban a szoftverekben rejlő üzleti intelligencia súlyozott része lett a vállalati vagyonnak. Ezért mind az informatikai rendszerek modernizációja, mind az üzleti változások kezelése során a szoftverfejlesztési projektek leginkább a meglévő szoftverrendszert alakítják át, és a legritkább esetben vonják vissza teljesen azt. A változtatás alatti rendszer mindig nagyon kiterjedt és jellemzően vegyes komponensekből áll, amelyek nagyobb részt szoftver komponensek, hardver készülékek és az emberek a feladatköreikkel [Min98]. A vállalat folyamatos versenyelőnyét meghatározza a szervezet előrelátó képessége, ahogyan követni képes az üzlet és a technológiák változásait, stratégiai, szervezeti és infrastruktúra szinteken [Chi03, COB12]. A szervezet fenntartásához szükséges az informatikai és az üzleti stratégiák összeillesztése, valamint az informatikai és üzleti infrastruktúrákon zajló folyamatok összeillesztése [McK09, CAiSE12]. Ezekhez a rendszerszempontokhoz a modellvezérelt
78
követelményfejlesztés [MoDRE12] nyújt kielégítő támogatást és egyben keretet a változáskezeléshez, amelyre mi is javaslatot tettünk a Tézis 3. alpontjaival. A vállalati fogalmak leírására és szoftverrendszerekbe integrálására számos keretrendszer jött létre és fejlődött ki az utóbbi két évtizedben. Ilyenek, a TOGAF [REF12], Zachmann [Zac87].
Az információs technológiák és a szoftverrendszerek interfészeinek adaptálására a
vállalat felépítéséhez számos összefogás jött létre, amelyek célja, hogy összefüggő nézetet adjanak a folyamatokról, szervezetekről és infrastruktúrákról, valamint ezek költségeiről [ATH12].
Technikailag a szokásos vállalatirányítási rendszerek nem adnak rendszernézetet a változások hatásainak elemzéséhez, mert a kimutatások rendszerint a részterületek hierarchiáin tükrözik a működés paramétereit. A korszerű informatikai rendszerek szimulációs modellekkel támogatják az integrált változáskezelést, amelyben az integráltság a kontroll alapú többszörös megközelítést és a jelenségek együttes kezelését jelenti [CaiSE12, IFIP12].
Ennek feltétele, hogy a különféle stratégiák, folyamatok és környezeti jellemzők un.
koncepcionális leírásokban legyenek megadva. A koncepcionális leírásokkal lehetséges a variációk elemzése a célok teljesülésének és a kockázatok mérséklésének vizsgálatához. Ezáltal, előállhat a vállalatot alkotó elemek számítási reprezentációja, amely egyben a vállalat modellje [Fox98], és alapot képez a fejlesztésekhez. A vállalat modellje tartalmazza a vállalat működéséhez szükséges ismereteket, amelyek egyben megválaszolják a tevékenységek hatékonyságára vonatkozó kérdéseket is, akár manuális, akár automatizált a tevékenység végrehajtása. Fejlesztési nézetben a vállalat modellje egyértelműen meghatározza a vállalatot úgy, hogy ismert legyen mi a tervezett, mi a várható és mi a megtörtént esemény. A vállalatot alkotó elemek számítási reprezentációjára számos kifejezési forma létezik, amelyekre szakterületi nyelveken és/vagy UML nyelvjárásokkal alakultak ki a technológiák [REF12, OASIS12]. Az üzleti folyamatok kezelésének automatizálásához a Workflow Management Coalition (WfMC) szervezet szabványosította a Workflow Process Definition Language ontológiát modellvezérelt technológiákra, amely a folyamatokban a manuális és automatizálható tevékenységek szoftvertámogatására összpontosít elvi és technológiai szinten [WF12]. Ismert a TOVE szervezeti modell [TOVE12], amely egy ontológia alapú technológia a funkcionális modell és a szervezeti struktúrák szerep alapú összekapcsolására a változáskezelés automatizálásához. Ismertek Petri Net alapú forgatókönyv transzformációk, amelyek az üzleti 79
folyamatok monitorozására terjedtek el. Azonban a Petri Net nincs szabványosítva, és nincs egységesen elfogadott szemantika, a létezők összetettek [Gen10, Des98]. Az üzleti terület modellvezérelt fejlesztéséhez nagymértékben hozzájárult az elosztott és nyílt rendszerfolyamatok szabványos strukturálásának referencia modellje, a Reference Model - Open Distributed Processing (RM-ODP), amely közös szabványa az ITU-T, IEC és ISO szervezeteknek. Tartalmaz vállalati nézőpontot (enterprise viewpoint) is [RM-ODP]. Az RM-ODP vállalati nézőpont objektumokra nézve azonosítja be a szerepeket, folyamatokat, intézkedéseket és kapcsolatokat. A referencia modell módszert és nézőpontleíró nyelveket ad meg, és ez által az alkalmazása leegyszerűsödik a nézőpont-leíró nyelvek és az alkalmazásnyelvek típusainak összehangolására. Az OMG az objektumok kezelését szoftverfejlesztéssel fejezi ki, amelyben a valós világot olyan
objektumok
képviselik,
amelyek
egységbe
zárják
a
szoftverkomponensek
tulajdonságait, kapcsolatait és műveleteit. Az OMG objektumszemlélete eredményezi az alkalmazások fejlesztését, fenntartását, skálázhatóságát és újrafelhasználását. Az RM-ODP objektumszemlélete eredményezi a vállalati modellek specifikálását, amelyek segítik a specifikációk felhasználóit az alkalmazások és a szoftverfejlesztés szintjén. Az MDE elvekkel és az UML4ODP nyelvjárással az OMG harmonizálta az objektumnézetét az RM-ODP nézetekhez. Ennek az a jelentősége, hogy előtérbe került a modellvezérelt fejlesztésben a koncepcionális modell, és ezzel a kontextus modellezés és az ontológiák fejlesztése [Rol00, Myl08].
Az OMG az üzleti területre fiók-szervezetet hozott létre az OMG Business Process
Model and Notation (BPMN) [BPMN12] ipari érdekcsoporttal. Feladata az eXtensible Markup Language (XML) alapú technológiák és de-facto szabványok [OMG12] létrehozása a grafikus és szöveges folyamatleíró nyelvek fejlesztéséhez, és ezek integrálásához az üzleti terület szoftverrendszereinek fejlesztésébe. Mindehhez, kialakultak az üzleti folyamatmenedzsment eszközök és az üzleti folyamatok modellezésének szabványai, technológia közeli munkafolyamat kezelő rendszerekkel és csoportmunka-kezelő rendszerekkel. A gyakorlat azt mutatja [Aal03], hogy azok a hatékonyan integrálható eszközök, amelyekkel elkülönítve lehet ábrázolni az üzleti szabályokat és a működtetés folyamatainak követelményeit. Ehhez szükséges, hogy az előre rögzített viselkedést magát lehessen hajlékonyan elemezni és végrehajtani, akár struktúra változatokban és/vagy változó szabálykészletet alkalmazva. A kontextus modell előnye, hogy gyors adaptálódást nyújt a változásokhoz a szakterület strukturális és lexikális ismereteinek becsatolásával a modellvezérelt technológiákba. Pl. 80
Eclipse plug-in formájában vagy szakterület specifikus modellező nyelv fejlesztésével vagy a modelltranszformációt
az
ontológiák
szemantikáin
és
XML
alapon
megvalósító
modellintegrációkkal. A logikákon alapuló folyamatleíró nyelvek még absztraktabb technológiákat képviselnek az ismeretek hordozásához és megfeleltetéséhez [Gru08]. Mindezekből számunkra az a fontos, hogy a vállalati nézőpontok koncepcionális tervmodelljének megvalósításához rendelkezésre állnak a modellvezérelt technológiák a platformosztályok szervezéséhez szakterület-specifikus nyelvek és ontológiák formájában, amelyek birtokában megtörténik az alkalmazáskomponensek modell szintű integrációja vagy futásidejű szolgáltatásokban a komponensek konfigurálása. A fenti jelenségek kutatásához hangsúlyt fektettünk a távközlés területén szabványosított célorientált folyamatleíró nyelvekre a nyelveket támogató fejlesztő eszközök szolgáltatásaira [OMG12, ITU12]. Meglátásunk, hogy az UML nézetek a vállalati szoftverfejlesztés bevált modellező eszközei, amelyek az UML nyelvjárásokkal együtt támogatják a vállalati keretrendszerekre alapozott modellezést, ugyanakkor ki kell egészíteni olyan eszközökkel, amelyek támogatják a stratégiatervezést [Med12]. Az újabb OMG szabványosítások az UML2.0 és az OCL nyelvekkel [OMG12] jó alapot nyújtanak a tervezés szintjén a vállalati modell teljességének és helyességének szabályalapú kezeléséhez, de nem nyújt elegendő támogatást a fejlesztés korai szakaszára. Továbbra sincs az UML nyelvnek eszköze a célorientált és kockázatalapú üzleti modellezéshez. Az európai közösségben a szakmai-jogi szabályozó szervezetek a kockázatkezelés alapú rendszerfenntartást szorgalmazzák az informatikai rendszerek üzemeltetésére [ENISA12]. Ehhez technikailag a minőségirányítási rendszereket és a modern minőségmenedzsment szabványosított ismeretköreit javasolják [ISO12]. Ezek célorientáltan és kockázatkezelés alapon ötvözik a rendszer- és a folyamatszemléletet az üzleti modellek kialakításához és felügyeletéhez, azonban nem adnak módszert a gyakorlatba ültetéshez. A mi javaslatunk az üzleti modellek kialakításához a célorientált követelményfejlesztés és szoftverkarbantartás evolúciós folyamatban, amely eredményezi az üzleti területen a folyamatos változáskezelést. Az üzleti modell előállítását a komponens-elvű szoftverfolyamat nézőpontján közelítjük meg. Ennek lényeges vonatkozása, hogy lehetőségünk van kombinálni a célok és a forgatókönyvek modellezését a korábbi követelményfejlesztés és az architektúra tervezés irányzatokkal, és ezek technológiáit is az újratervezés utáni integráláshoz. A célorientált követelményfejlesztésben a legtöbb technika és technológia a célok gyűjtésére összpontosít [Lam09], de előtérbe került a kiértékelés támogatása is. Yu és 81
Mylopoulos [Aya05, OME12] formális módszert dolgoztak ki a célokhoz rendelt szándékos és elvárt
stratégiák
kiértékelésére
az
Organization
Modelling
Environment
(OME)
keretrendszerben, amely célorientált követelménytervezést támogat az egyed-kapcsolat modellezésnek a szerep alapú ontológikus megközelítésével [Yu95, OME12]. Ezek jól hasznosíthatók az üzleti modellek változáskezeléséhez. Az általuk kifejlesztett GRL nyelvet az ITU-T szabványosította a nem funkcionális követelmények fejlesztéséhez (lásd 1.5.1) [ITUz151].
Az URN technológiák eddigi alkalmazásai előtérbe helyezik az üzleti folyamatok és az informatikai folyamatok egymáshoz igazítását [Amy11], elsősorban az üzleti folyamatok munkaelemeinek az informatikai támogatását és monitorozását [Wei05, Che07, Kea07, Pou09, Pou08, Gor99].
Kutatásunk eredményeként gyakorlatba ültettünk egy módszertant az üzleti folyamatok változáskezelésére modellvezérelt fejlesztésben. Ehhez technológiai sort jelöltünk ki a távközlés területén szabványosított ITU-T System Design Languages nyelvcsalád elemeivel és a vállalati technológiákkal a 3.1 Tézisben [Med07, Med08b]. Ipari alkalmazással alátámasztott módszertant adtunk az üzleti folyamatok specifikálására és inspekció lebonyolítására, a szerepek
szétválasztásával
folyamatgazdák,
üzleti
elemzők,
minőségfelelősök
és
modellfejlesztők együttes tevékenységeihez a 3.2 Tézisben. Az üzleti folyamatok kooperatív feltárásához és szabályozásához megadtunk egy generikus módszertant az URN technológiákra alapozva. A módszer lehetővé teszi, hogy a folyamatgazdák
és
minőségfelelősök együtt képesek legyenek meghatározni a folyamatparaméterek értékeit, ezzel elkerüljük a követelményfeltáró módszerek hátrányait. A folyamatspecifikációs űrlap alapján a fejlesztők modellezik az üzleti folyamatokat, majd a területfelelős üzleti elemzők és folyamatgazdák együtt inspekciós technikákat alkalmaznak a folyamatspecifikációkra az űrlapon megadott követelmények validálásához [Med10c]. A módszert továbbfejlesztettük verziókezeléssel kollaboratív keretrendszerré vállalatközi elektronikus kereskedelem monitorozására [Med11c]. Az elvi és gyakorlati tapasztalatok alapján létrehoztunk egy módszertant keretrendszerek építésére az üzleti területen az üzleti stratégiák és az üzleti folyamatok változáskezeléséhez. A keretrendszer generikus modelljeinek specializálása az érdekelt felek aktív részvételével történik (3.3 Tézis) a célmodellekből kiindulva [Med11d, Med12, Med12c]. A keretrendszer részeként mintákat dolgoztunk ki az információbiztonság és a mobilinformatikai alkalmazások vállalati technológiákba
integrálására.
Generikus
célorientált
modelleket
hoztunk
létre
az
információbiztonság szabvány fejezeteire, specializációkat az elektronikus kereskedelemi célú 82
vállalati újratervezésre, és ennek esettanulmányát konkrét vállalati újratervezés esetére [Med09b, Med11, Med11c].
A mobilinformatikai alkalmazások vállalati integrálásához mintát és
esettanulmányt dolgoztunk ki az URN, UML, MSC technológiák alkalmazására a használati esetek leírásából kiindulva. [Med12c].
4.1 Technológiai sor séma modellvezérelt fejlesztéshez az üzleti területen 4.1.1 Technológiai sor séma és specifikáció Az ITU-T URN technológiáira alapozva, a követelménymodellből automatikus transzformációkkal állíthatók elő az interakció-, architektúra-, teszteset modellek. Kézi transzformációkkal előállíthatók az infrastruktúra- és bevezetés modellek, továbbá manuális/automatikus módon egyes implementációs modelltranszformációk szakterületi nyelvekre.
21. ábra A technológiai sor séma egy példányosítása az üzleti területre modellvezérelt fejlesztéshez
A 21. ábrán mutatjuk be a modellvezérelt fejlesztéshez javasolt technológiai sor séma (4. ábra)
példányosítását (6. ábra) az üzleti területre, kiemelve ebben a vállalati technológiák
szerepét. Egységesen a vállalati technológiák gyűjtőnévvel azonosítjuk a dolgozatban a vállalati architektúrákra létrehozott specifikus UML nyelvjárásokat, mint BPMN, SoaML, valamint a vállalatirányítási rendszerimplementációs nyelveket, mint web technológiák, üzleti folyamat kezelő rendszerek (BPMS), vállat irányítási rendszerek (ERP) az SAP referencia alkalmazásrendszerrel. A 21. ábrán absztrakciós szintekre csoportosítottuk a technológiákat. A követelményfejlesztéshez és az üzleti szabályok létrehozásához magas absztrakciós szinten javasoljuk az elosztott rendszerek fejlesztéséhez a távközlési területen kifejlesztett nyelveket. Az URN technológiákkal magasabb absztrakciós szinten adhatjuk meg az üzleti 83
modellt, mint az UML vagy elterjedt munkafolyam- és üzleti folyamatkezelő technológiákkal [Wei05].
A
szabványtámogató
fejlesztőeszközök
által
az
automatikus
XML
modelltranszformációkkal jutunk el az UML vagy DSML technológiákhoz. Az
architektúra
modell
URN
specifikációi
kerülnek
továbbfejlesztésre
modelltranszformációkkal a részletes tervezésben, az UML nyelv vagy vállalati technológiák alkalmazásával aszerint, hogy a platform modell tartalmaz-e specifikus elemeket, amelyek lerövidítenék a folyamatot. Az SDL nyelvet a kommunikációs alrendszer tervezéséhez javasoljuk, amelyet transzformálunk az SDL2UML szabványtámogató fejlesztő eszközökkel az UML technológiákra. Az architektúra modell verifikálásához javasoljuk az IFx Toolbox alkalmazását, amennyiben a szakterületi platform modell nem tartalmaz verifikáláshoz beépített eszközöket. A részletes tervezéshez az adatbázis technológiák alkalmazását a sémában az SQL szabvánnyal jelöltük meg. A vállalati technológiák tartalmaznak adatbáziskezelő rendszereket az Eclipse platformon számos modellvezérelt eszköz kínál adatkezeléshez megoldást.
22. ábra Az üzleti területre kijelölt technológiai sorok specifikációi MDE fejlesztésekhez
A technológiai sor sémának az üzleti területre adott példánya (21. ábra) alapján kijelöltük a technológiai sorokat a 22. ábrán megadott F3 és F4 technológiai sor specifikációkkal. A specifikáción alkalmazott jelölések: sor kezdet és vég a telített kör és sorlezáró függőleges szakasz, az X jel a technológiai eszközöket mutatja, a variációk lehetőségét a feltétel nélküli leágazások és csatlakozások mutatják. A haladás iránya előre, amennyiben nincs nyíllal kijelölve a visszafele irány a vonalon. A URN/AoURN alapú követelménymodellből az XML szabvány alapú automatikus modelltranszformációval lehet az elemzéshez és teszteléshez modelleket előállítani [Lam09, Liu01, Got94, Amy05, Dam06, Mus10, Mus12, Sha12, Vrb12], az UML technológiákhoz vagy a vállalati technológiákhoz. A részletes tervezésben szükség szerint 84
alkalmazhatjuk
az
állapotátmenet
alapú
modellezést
és
verifikálást
a
kritikus
rendszerfunkciókra. A 5. Táblázat mutatja az F3 és F4 technológiai sor specifikációk példányait. A technológiákkal rögzítjük a fejlesztési folyamat szakaszait, szétválasztva a munkaszakokat az adaptációs modellek létrehozására a változáskezelésben megtartott komponensekhez. 5. táblázat A 22. ábra F3 és F4 technológiai sor specifikációk példányai
1. sor: URN/AoURN – (OCL) - MSC – HMSC – WebApp/SAP - (ASN.1) – TTCN 2. sor: URN/AoURN – (OCL) – (UML2SDL) - UML – WebApp/SAP – UML - TP 3. sor: URN/AoURN – (OCL) – UML - SoaML – DSML - UML-TP 4. sor: URN/AoURN – (OCL) – BPMN – WebApp/SAP – UML-TP 5. sor: URN/AoURN – (OCL) – BPMN – OCL – BPEL 6. sor: URN/AoURN – (OCL) – DSML – TTCN
A sorokban a követelmény modell előállításához minden esetben az URN vagy AoURN technológiákat javasoljuk az üzleti modell előállításához, hogy a célorientált és forgatókönyv alapú modellekkel a módosítható stratégiák kialakítása és az átjárhatóság megvalósulhasson. Az 5. táblázatban az 1. és 2. sorok technológiáit javasoljuk az üzleti folyamatok változáskezelésére és az ebből adódó újratervezéshez komponens modellekkel. A megvalósítás vállalati technológiákkal történik. A vállalati szolgáltatások átszervezéséből gyakran adódik üzleti változás, amely az inkonzisztenciához vezethet szoftverkarbantartás nélkül. Ennek esete a [Med07] közleményünkben bemutatott újratervezés. A problémát a szállítás kiszervezése okozta olyan információkezeléssel a munkafolyamatban, amelyhez nem szerveztek alkalmazástámogatást, és az Értékesítési csoport nyilvántartása vált valótlanná. Az üzleti folyamatok újratervezését illetve burkoló komponens fejlesztését URN és UML ill. SAP-ABAP technológiákkal végeztük. A webfejlesztések BPMN és BPEL technológiáihoz nyújt az URN technológia gyorsfejlesztést a 4. és 5. sorokkal az üzleti modell célorientált fejlesztésére. A GRL és BPMN szimbólumok megfeleltetését [Los11] kutatók dolgozták ki. A 6. sort javasoljuk a szakterületi technológiákhoz, amelyekbe több nézet van integrálva [Tol10]. A TTCN teszteléshez a teszteseteket az URN modellekből automatikusan lehet generálni. A változáskezelésben, mind az újratervezés, mind a szoftvermigráció esetében, a technológiai sor képezi a keretet a célok meghatározásához és a megoldások alternatíváinak megvitatásához a változáskezelésben érdekelt felekkel. A vállalati rendszerek hatékony változáskezeléséhez szükségesnek tartjuk a meglévő alkalmazásrendszerek visszatervezését, valamint az üzleti folyamatokra alapozott vállalati architektúra modellezését URN technológiákkal. Ennek során a koncepcionális fejlesztésben már bevált módon adjuk meg a 85
jelenlegi helyzet és a jövőbeni rendszeralternatívák modelljeit (szakirodalomban az As-Is és To-Be modelleket) [Lam09, Ral05, Myl99],
amelyhez az URN technológiák nyújtanak MDE támogatást
transzformációkkal a vállalati technológiákhoz. Az URN technológiákkal megvalósíthatók a modern menedzsment 5W technikái: az UCM (what, who, where, when) és a GRL (why) modellezésben [Wei05], mivel az URN technológiában összekapcsolható a szerkezet és a viselkedés egyazon látványba. URN technológiákra számos alkalmazástípus keletkezett az üzleti területen, mint a webfelületek alkalmazhatósága, törvénykezés, kórházi folyamatok és biztonsági kérdések döntéstámogatása [Che07, Gha10, Zha11, Sha12b, Tru09, Shi12, Sal09, Sal04, Pou08, Pou09].
Az URN technológiák komplementer módon viselkednek az üzleti területen az UML nyelvjárásokra nézve [Amy03b], mivel az üzleti modellezésekre létrejött UML nyelvjárások implementáció közeliek. Pl. a BPMN szintaxisa a fejlesztőket támogatja a részletes tervezésben, nem felhasználó közeli a nyelvezete és nem nyújt közvetlen támogatást a követelmény feltáráshoz [OMG12]. Az URN-UCM forgatókönyv modellek az egyidejű rendszer- és folyamat nézettel egészítik ki az UML nézőpontjait. Az URN-GRL célgráf modellek stratégia nézettel egészítik ki az UML nézőpontjait. Mindezek, értelmezhető formában
az
üzleti
terület
szereplői
számára
lehetővé
teszik
részvételüket
a
követelményfejlesztés és a bevezetés szakaszokban, hitelességet keltenek a megrendelőkben, és felgyorsítják a fejlesztési folyamatot [Med12, Med10c, Med07]. Amikor egy üzleti területen már létrejöttek a minták az üzleti logika szabványosításához, akkor a szabványos üzleti modellek és jól meghatározott munkafolyamat-minták közös nyelvet képeznek a fejlesztésben dolgozók számára. Az URN alkalmazása nemcsak munkafolyamat szintű módszertani előnyöket jelent, hanem jelenti egyben a technológiai sor skálázhatóságát a folyton fennálló változáskezelésekben. Több keretrendszer-megoldás alkalmazza az UML nyelvjárások fejlesztését az üzleti kontextus támogatására, amelyek hatékony eszközök a fejlesztők számára, azonban nem mind ad közvetlen lehetőséget az üzleti elemzők és más érdekelt felek részére. A cél-orientált GRL és forgatókönyv-alapú UCM jelölések kiegészítik egymást, a korai fejlesztési szakaszokban alkalmasak a szervezeti és szervezési információk dokumentálására, valamint a tervezés és implementálás kontrolljára. Az UCM és GRL finomítások iterációs módon alkalmazhatók, függetlenül egymástól és más fejlesztési nézetektől. A fejlesztők számára az UMLforODP szabvány [ODP12] ad ajánlást az ODP nézetek UML nyelvi implementációjára. Az URN specifikációkból transzformálhatók egyaránt az OMG objektumnézetek [Buh96] és az ODP nézetek is [Mus10]. Weiss és Amyot fogalmi szinten 86
kimutatta, hogy az URN nyelv teljesíti egy BPM nyelv követelményeit, és használni lehet üzleti folyamatok modellezésére és elemzésére [Wei05]. Az URN technológiák támogatják modelltranszformációkkal az UML és/vagy DSML tervezést [Amy02]. A modelltranszformációs támogatások automatizáltak a jUCMNav fejlesztőben. A forgatókönyvek validálása után érhető el az XML transzformáció MSC, UML2.0 SD és AD, TTCN és más technológiákhoz, az újabb absztrakciós szintű modellezéshez. Az UCM alapú forgatókönyv szimulációk alkalmazása az architektúra döntések, teszteset generálások, és a kódvisszafejtés támogatására ismertek [Hei12, Dia09, Roy07, Pol03].
A GRL célfák és kiértékelésük többletet nyújt az ismert cél-orientált
eszközöknél, nemcsak az üzleti területen terjed az alkalmazása [Hor11, Yu00, Liu00, Liu04, Mol10, Pou12, Beh12].
Losavio és társai [Los11,] létrehozták a BPMN és GRL szintaktikai és
szemantikai megfeleltetését. Mi arra építünk az URN technológiákkal, hogy a változásokat evolúciós fejlesztésben lehet kezelni és több ponton kapcsolódni az MDE nézőpontokhoz, amelyekre a fejlesztőeszközök szolgáltatásai biztosítják az inkrementális fejlesztést, valamint a modell és alkalmazás integrációt. Kaindl [Kai05] a nézőpontokon hozza vonatkozásba a szakterület modellek objektumait az alkalmazás objektumaival, a tervezés objektumait pedig a szoftver objektumok absztrakcióival. Az URN technológia a szervezeti és viselkedési elemeket egy modellben mutatja meg, és járhatóságot nyújt a szakterületi és a tervezési modellek között. 4.1.2 Módszerleírás az URN alapú újratervezés szervezéséhez Az előző alpontban visszavezettük az üzleti területen szükséges fejlesztéseket az újratervezés célú fejlesztésekre, amelyek komponens elven történnek, és a kódvisszafejtést URN technológiákkal érdemes elvégezni. A technológiai sorokban minden esetben az URN vagy AoURN technológiákat javasoljuk a követelmény modell előállításához, hogy a célorientált és forgatókönyv alapú modellekkel az üzleti stratégiák kialakítása és az átjárhatóság megvalósulhasson. Az alábbiakban az újratervezés szervezéséhez adunk leírást. Újratervezés szervezése URN technológiákkal 1. A
jelenlegi
helyzet
funkcionális
modelljének
előállítása
üzleti
folyamatok
modellezésével – 3.2 Tézisben megadott módszerekkel és eszközökkel: a.
munka
kerete:
folyamatok
feltérképezése
és
követelményfejlesztés
folyamatspecifikációs-űrlap (lásd 4.2) alapú munkaszakaszokkal és vízesésmodell folyamatszervezéssel 87
b.
üzleti szakértők és folyamatgazdák feladatai: követelménygyűjtés és inspekciós validálás
c. fejlesztők
feladatai:
spcifikálás,
verifikálás,
inspekciós
hibajavítás,
dokumentációkészítés. 2. A jelenlegi helyzet elemzése és az üzleti folyamatok optimalizálása – 3.3 Tézisben megadott módszer szerint (lásd 4.3): a. munka kerete: célok modellezése a jelenlegi helyzet validált modelljeit figyelembe véve és minőségszabályozással b. szakterületi felelősök és fejlesztők feladatai: célok megjelölése a jelenlegi helyzet validált specifikációi alapján c. fejlesztők feladatai: GRL célmodellek előállítása (opcionális) d. szakterületi felelősök illetve fejlesztők: inspekció illetve inspekciós hibajavítás 3. A jövőbeni helyzet üzleti modelljének előállítása a. munka kerete: jövőbeni helyzet üzleti folyamatainak modellezése a jelenlegi helyzet validált modelljeinek módosításával b. fejlesztők feladatai: UCM modellek előállítása a jelenlegi helyzet módosításával, vagy a GRL célmodellekből URN Link alkalmazásával c. szakterületi felelősök illetve fejlesztők: inspekció illetve inspekciós hibajavítás 4. Architektúra elemzése az UCM modelleken 5. Minőségteljesülés elemzése GRL modelleken és integráció az UCM modellekbe 6. Manuális
vagy automatikus
modelltranszformációk
az
UML,
XML,
DSML
eszközökhöz 7. UCM modellezés az infrastruktúra-, tesztelés- és bevezetés tervek, és tesztesetek előállításához 8. UML, DSML modellezések, ebbe beépülő URN modelltranszformációkkal, például SAP esetén az URN-UML-SAP-ABAP a technológiai sor.
88
4.2 Módszertan az üzleti folyamatok specifikálására és inspekciójára Ebben a tézispontban arra mutatunk rá, hogy a modellvezérelt szemlélettel és technológiákkal az evolúciós fejlesztési folyamatmodellt lehet alkalmazni váltakoztatva a vízesésmodell előnyét a jelenségek és feladatok éles elhatárolására. Az ellentétes érdekeltségű résztvevők feladatvégzései elkülönített kommunikációval és dokumentumcserékkel történnek meg, amelyek szabályozhatók. A KobrA módszertan Kontextus megvalósítása fejlesztési szakaszt vizsgáltuk, és szintetizáltuk a termékek és az átjárhatóság vonatkozásában, és adtunk az URN technológiákkal módszertant az átjárható üzleti folyamatmodellek és használati modellek előállítására és a viselkedés modell előállításához MDE elveken automatizált modelltranszformációval. Létrehoztuk a ProjektProcessz módszertant az üzleti folyamatok modellezéséhez és a modellek transzformációihoz a viselkedésmodell PIM absztrakciós szintjére. Ennek részei egy módszer és egy folyamatspecifikációs űrlap formalizmus a folyamatok modellezéséhez természetes nyelven, továbbá módszerek az URN specifkációk fejlesztésére és a használati modellek szimulációs validálására, folyamatspecifikációk validálása inspekciós
forgatókönyvekkel.
A
technológiákkal
kifejezetté válnak és
dokumentálttá is a feladatok erőforrásai és feltételei, ezekben pedig a szereplők egyéni munkavégzése. Ennek eredményeként betanítható munkaszakaszokká vállnak a korábbi módszerekkel szakértőket igényelő követelménygyűjtés munkafolyamatai. Az üzleti területen, eltérően a távközlési területtől, a vállalati szabványok nem alkotnak átfogó rendszert az üzleti folyamatok menetére nézve. Általános az üzleti területen, hogy az egyes objektumok az adatkezelés által kapcsolódnak a rendszerfunkciókhoz a szervezeti struktúrák szabályozása szerint. A tevékenység- és szerepközpontú eseményekben az adatfolyam nézet általánosan elfogadott az együttműködéshez, és kiforrott eszközök vannak a verifikálására. Ugyanakkor a rendszerszintű feladatok irányítására a folyamatközpontú nézet a hatékonyabb, például a termelésirányítás, logisztika, informatikai rendszerek fenntartása. Az IT fenntartók számára különösen nehézkes a kommunikáció a vállalati adatközpontú nézetben, mivel egy vállalati igény megvalósítása az IT részéről mindig egy eljárásrendű változtatást eredményez. Érdekeltségek léphetnek fel a területek közt a saját hatékonyságuk kezelésére, ilyenkor az érdekelt felek viszonyulásai a technokrata és a bürokrata nézetek ütközését váltják ki, és szervezeti és szervezési változásokat gerjesztenek a vállalatban [Min98].
A vállalati rendszerekben az üzleti folyamatok dinamikusak, míg az ezt támogató integrált vállalatirányítási rendszer (ERP) szolgáltatásai valamilyen hajlékonysággal rögzítettek. 89
Ellentétben az informatikai folyamatok eljárásrendű munkaköreivel, az üzleti területen az irányítási munkakörök és kontroll-monitor funkciók az adat- és adatcsoport-folyam nézeteket alkalmazzák irányításhoz a tevékenységek szintjén. Ugyanakkor bebizonyosodott tény, hogy az ügyvezetők számára is a folyamatközpontú nézet a hatékonyabb, amint megértik a folyamatközpontú nézetet pl. a munkafolyamatok dokumentálásakor vagy a folyamatok jobbításakor [McK09]. Fontos szempontunk az URN alkalmazásában, hogy milyen modellezési technikákkal és folyamatszervezéssel hasznosíthatjuk az URN előnyeit arra, hogy specifikáljuk az érdekelt felek részére a problémát, a megoldást és az alternatívákat a döntéshozatalhoz. A mi javaslatunk az URN technológiákkal az üzleti modellezés és a követelményfejlesztés kimeneteinek a kezelése probléma-megoldás párosítással. Ideálisan, az üzleti körülmények változásaihoz mérten szükségesek a változáskezelések, amelyek között viszonylagos folytonosságot biztosíthatunk a célorientált modellekkel és ezekből levezetett átjárható fejlesztési szintekkel (lásd a 4.3 fejezetben és a 7.4 Mellékletben a 49.-55. ábrákkal). A modellvezérelt folyamat lehetővé teszi a változáskezelésnek modellekkel való skálázását, valamint a szimulációkat az optimalizáláshoz és a döntések meghozatalához. Mindezek automatizálást igényelnek tudásigényes emberi támogatással, azonban a skálázhatóság nyújtja az
eszköz-probléma/eszköz-megoldás
párosításokat,
amelyekkel
a
folyamatba
már
bevonhatók különböző szakértők, akik a folyamat során felfedezik/igazolják a probléma valódi gyökerét. Például az üzleti folyamatok felhasználói szintű modellezésével kinyilvánulnak a modellezés során azok a folyamatszervezési hiányosságok, amelyek inkonzisztenciát okoznak a szervezeti egységek közötti munkafolyamatokban. Ezeket jellemzően az ügyintézői hatáskörben manuálisan végzett problémamegoldások okozzák a vállalati alkalmazásrendszer alacsony integráltsága miatt. Ily módon, a folyamatok specifikálása egy időben hozza meg az üzleti folyamatok optimalizálását valamint a változáskezelést kiváltó problémára a megkívánt szoftverkarbantartást [Med07, Óvá07, Med10c, Med11c].
A folyamatspecifikációk hidat képeznek a probléma és a megoldás között, és általuk
skálázható a szoftverfolyamat a hozzájuk rendelt technológiákkal [Med07, Med08b]. 4.2.1 A KobrA módszertan Use Case Description és Operation Description sablonjainak szintézise és továbbfejlesztése: a természetes nyelvű modellezéshez felhasználói követelmények gyűjtésére az üzleti folyamatok specifikálásához A technológiai sorok alkalmazására adott példa (l. 2.1.3) keretében ismertettük a KobrA módszertannak a fejlesztési folyamatra meghatározott dimenzióit, szakaszait és termékeit, a 90
technológiák nézőpontjából. A munkafolyamat elemeinek nézőpontjából tárgyaljuk röviden a KobrA módszert, hogy rávilágítsunk javasolt módszerünk összefüggéseire és helyére a szoftverfolyamatban. A KobrA módszer [Atk02, Gro05] a komponens-alapú fejlesztésekhez létrehozott UML alapú módszertan, amelynek fontos jellemzője, hogy a létrehozott komponensmodellben a fejlesztendő rendszer egy komponens, amely iterációban több komponensre lebontható. Ezáltal a KobrA módszertanban az alkalmazásfejlesztés és a komponensfejlesztés a vizsgált rendszer határaiban különbözik. A rendszer környezete az un. kontextus modell, amely fogalmi szinten azonos az üzleti modell magas szintű nézetével, amelybe beágyazódik a komponens. A részkomponensek kapcsolatai egymással valamint a rendszerkörnyezettel meghatározhatók a decomposition felbontás művelettel az üzleti modell szakterületi jellemzőinek megfelelően. Ennek jelentősége az architektúra tekintetében mutatkozik meg a változtatások hatásainál. Más a környezet jelentősége egy vállalati rendszerben és más egy beágyazott rendszer esetében. A felhasználó számára jól definiált interfészek szükségesek a használhatósághoz és eredményesség a szakterületi jellemzőknek megfelelően. Az üzleti területen az eredményesség időben hosszú lefutású történések alapján határozható meg, amelyekre az üzleti folyamatok modellezése ad szimulációs lehetőséget. A KobrA módszertan az UML technológiákat határozza meg a rendszerkontextus specifikálására. A KobrA, a Kontextus megvalósítása szakaszban létrehozott termékek alapjaként egy vállalati modell, vagy üzleti folyamatok modell előállítását javasolja a követelménygyűjtés módszereivel, amelyekből levezeti a rendszer (mint komponens) használati-, struktúra- és viselkedés modelljét. A KobrA, a használati modellhez az UML Use Case használati eset diagram és az Use Case Description sablon eszközökkel határozza meg azokat a tevékenységeket, szereplőket és kapcsolataikat, amelyeket a rendszer felhasználója végez, és amelyekhez a rendszer támogatást nyújt. A struktúra modellhez az UML Class Diagram osztálydiagramot vagy objektumdiagramot alkalmazza. Ezt követően a viselkedés leírására alkalmazza az a tevékenységek műveleti szintű leírására az Operation Description sablont, amely alapján az események időrendi és strukturális kapcsolataival megadja a viselkedési modellt az UML Sequence Diagram és Interaction Diagram kölcsönhatás diagramokkal. Mint kitűnik, a KobrA módszertan MDE munkafolyamatot fogalmaz meg általános fogalmakkal több absztrakciós szintre, amelyeket a további folyamatszakaszokban specializál, a folyamat több dimenziójában rögzített munkaelemek és termékek pontos megfogalmazásával. Ezt a képletes ábrázolásmódot alkalmaztuk az MDE folyamat dimenzióinak megfogalmazására
91
(lásd 3. ábra) az elvek, termékek, eszközök, munkaszakaszok rendszerbe foglalásához az 1. fejezetben. A fenti ismertetésből láthatjuk, hogy habár a komponens-alapú módszerek közt a KobrA MDE módszertan, mégis a használati modell inputjai nem definiáltak a fejlesztés kiinduló lépéseiben, és a változáskezeléshez nincs biztosítva az átjárhatóság a használati modell termékei és a feltételezett vállalati modell vagy üzleti folyamatok modell között. Ehhez megfelelőnek tartjuk az URN technológiákkal kiegészíteni a modellezést, mivel az URN technológiákkal egy nézetben meg lehet fogalmazni a szerkezeti és a viselkedési elemeket. Változáskezelésnél változhat az üzleti folyamat, a támogató szoftver, vagy mindkettő. Az üzleti modellezéssel elérhető, hogy olyan módon legyenek elszeparálva a szerkezeti és viselkedés elemek leírásai, hogy a változáskezelésben azonosítani lehessen az elemeket a komponensek kezeléséhez, és moduláris szerkezetben új komponenst fejleszteni vagy a meglévőt módosítani vagy adaptálni más forrásból. A KobrA módszertan sablonjai az Use Case Description használati eset leírás és az Operation Description Template a vállalati modellből kinyert információk formalizálására az elemzés és a részletes tervezés idején (lásd 7.4 Melléklet 13.-14. táblázatok). Az Use Case Description használati eset leírás egy továbbfejlesztése a Cockburn [Coc01] által kifejlesztett Use Case Template űrlapnak. Az Use Case Template megvalósítása az UML Activity Diagram és Sequence Diagram eszközeivel lehetséges. A kölcsönhatások részletezése a viselkedésmodellezésben kerül kiegészítésre a komponens által nyújtott szolgáltatások leírásával műveletenként az Operation Description Template [Col94] műveleti sablon alapján. A sablont eredetileg a Fusion módszerben hozták létre a komponens által szolgáltatott műveletek leírásához. A sablonokról további ismeretekhez javasoljuk az irodalmakat [Col94, Atk02, Gro05]. A két sablon felhasználásával az üzleti folyamatok modellezésében az a célunk, hogy a szoftvertechnológiában elterjedten alkalmazott általános fogalmakkal adjunk formalizmust az üzleti folyamat jellemzőire - tevékenységek, szereplők, események az időrendi és strukturális kapcsolataikkal - olyan részletezéssel, amelyekkel elérjük, hogy a modellező számára közelítjük/összehangoljuk a menedzser típusú adat/objektum és belső tevékenységfolyam nézeteket a technikai típusú kölcsönhatások/szabályok nézetekkel. A létrehozott eszközzel szeparáltuk az üzlet szereplőinek az adatszolgáltatását a fejlesztéshez és az üzletet modellezők munkafolyamatait, és egyben átjárást képeztünk a követelménygyűjtés és specifikálás munkafolyamatai és termékei között.
92
A folyamat elemek táblázatba foglalása alapját képezi a folyamatspecifikálásnak, a folyamatközi kapcsolatok feltárásának és szimulációs validálásának, a folyamatok szabályozásának,
az
üzleti
modellel
kapcsolatos
munkák
inspekciójának,
és
a
folyamatleírások összhangban tartásának. 4.2.2 Folyamatspecifikációs űrlap és tevékenység forgatókönyv űrlap ProjektProcess Folyamatspecifikációs űrlap (lásd a 6. Táblázatot) generikus modell természetes nyelven a folyamat és kapcsolatai leírásához, amely táblázatos formában modellezi a folyamatot, tartalmazza a folyamat célját, érintett szereplőit és a szervezeti egységeket, szerkezetét, tevékenységeit, tevékenységek sorrendjét és kölcsönhatásait, adatkapcsolatait a be- és kimeneteivel, lefolyását alap-tevékenységekkel, valamint a kivételes és egyidejű tevékenységekkel, korlátait, minőségjellemzőit a minőségi elvárásokkal a tevékenységek folyamatközi kapcsolataira, végcélját. A folyamatleíró elemeket az előző alpontban ismertetett célból szintézissel nyertük a KobrA módszer Use Case Description használatiesetleíró, az Operation Specification Template
műveletleíró
sablonok
összefésüléséből,
amelyet
továbbfejlesztettünk
kontrollmezőkkel a kulcsmezők kitöltésének ellenőrzéséhez (6. Táblázat). Az űrlapon a kulcsmezőket és a kulcsfontosságú tulajdonságokat dőlt betűs írásmód jelöli. Figyelembe vettük a minőségkezelési módszereknek a folyamatábrázolásban elterjedten alkalmazott osztályozásait az operatív, támogató, irányító jellemzőkkel. A folyamatkapcsolatok leírásához a folyamatspecifikációs űrlap részeként a 7. táblázatban megadott Tevékenység©forgatókönyv űrlapot hoztuk létre a folyamatspecifikációk szabályalapú verifikálásához inspekciós technikákkal és formális verifikációs módszertanokkal. A 7. Táblázat az un. Tevékenység ©forgatókönyv űrlapot mutatja be, amelyen adatgyűjtés történik a folyamatot alkotó tevékenységek kapcsolatairól modellezéshez, verifikáláshoz és a folyamatok szabályozásához. A C. űrlap kontrolljellemzők dokumentálására szolgál a folyamatról a Folyamatspecifikációs űrlapban megadott tevékenységek viszonyáról, múltbeli/jövőbeli parciális rendezettségi mutatókkal az A, B, C, D, E oszlopokban. Ez azt jelenti,
hogy
a
folyamatközi
kapcsolatok
elemzéséhez
megadjuk
a
Tevékenység©forgatókönyv űrlap C. oszlopában a folyamat fő tevékenységeit, a 6. Táblázatban a Folyamatspecifikációs űrlap 15. sorszámú Alapművelet végzés adatcsoport sorszámozott eseményét, mint a jelen pillanat eseményét egyenként. Ezt követően adjuk meg soronként az A, B illetve D, E oszlopokban az egyes tevékenységek előzményeit illetve következményeit a tevékenységek kapcsolatainak dokumentálásához. 93
6. táblázat Folyamatspecifikációs űrlap A és B része
1.
Megnevezés/ kategória
A folyamat neve/jellege: főfolyamat, bedolgozó, egyidejű
2.
Leírás
3.
Elsődleges/ Másodlagos szereplők Eredmény felhasználója Korlátok Kapott bejövő információk Szolgáltatás
A művelet céljának azonosítása, amelyet követ a művelet végrehajtás normális és kivételes hatásainak leírása. A MIT kérdésre válaszol – nem a hogyan kérdésre. Hosszas leírás, a művelet kontextusa Szerep neve és leírása a művelethez kapcsolódó szereplő/szervezet és közreműködésének a tárgyában
4. 5. 6. 7.
elvárással 8.
Üzenetek
9. 10. 11. 12.
Olvasások Változtatások Szabályok Elvárások
13.
Sikeres működés
14. 15. 16.
Szolgáltatás hiba esetén Alap műveletvégzés Kivételes műveletvégzés
17.
Minőségi
18.
elvárások Erőforrások
19.
Egyidejű műveletek
20.
Kiterjesztő
21.
műveletek Végcél
Ki kapja az eredményt – művelet, szerep, szereplő/szervezet neve Művelet végrehajtását korlátozó körülmények és tulajdonságértékeik Forrásgazda+információ: A művelet elkezdését kiváltó bejövő információk Igénylő+információ: A művelet igénylőjéhez visszaküldött információk és eredmények Címzett+Üzenet: Jelzések küldése a művelet során, a műveletbe beemelt más részműveleteknek (résztvevőknek, eseményeknek) Mely szükséges információk, hol érhetők el a művelet részére Mely szükséges információk, hol érhetők el amelyek megváltoztathatók Az eredmény előállításához/számításához szabályok, képletek, számítások Olyan előfeltételek a kapott bejövő információkban, amelyek teljesülése szükséges, hogy a művelet garantálja az utófeltételeket, azaz a művelet eredményes legyen. Gyenge feltétel, mert csak azok kell, igazak legyenek (azok számítanak az elkezdéshez), amelyek a befejezettséget – az utófeltételeket érintik. Műveletkezdési feltétel – lehetnek olyan nem teljesülést vizsgáló feltételek, amelyek mellett még a művelet létrejöhet, azaz a művelet befejezettség feltétele (13.) teljesülhet, tehát el is kezdhetjük a műveletet. Amikor a kivételes helyzetekre is kapunk eredményt, mert a műveletkezdés figyelembe veszi a körülményeket. Erős utófeltételek, amelyek teljesülése esetén a művelet befejezett és szolgáltatta a kívánt eredményeket Műveletbefejezettség feltétele egyben – továbbléphet a következő műveletre, anélkül nem Mit lehet elvárni eredménynek hiba esetén Sorszámozva az események leírása normál esetben – NE alkalmazzunk automatikus sorszámozást Egy alap műveletvégzés esemény sorszámára hivatkozva alternatív események sorszámozott leírása Idő, egyéb mérhető jellemzők a műveletvégzés leírás sorszámával együtt megadva, periodicitás (gyakoriság, számosság számít!) Minden nem információs erőforrás felsorolása – szervezeti, szoftverrendszeri, dologi, emberi - BEAZONOSÍTHATÓAN Műveletenként: Megnevezés és ehhez a szükséges egyidejű műveletek azonosítással felsorolva - várakozással, köztes eredmény átadással, KiMit-Kinek Műveletenként: Megnevezés, és ehhez a kiegészítő feladatok (bedolgozó) neveinek felsorolása Elvárások és a sikeres működés (12, 13) ellenőrzött feltételei, a többi kategóriák mind összegzett információt adnak segítségül. Leírás (2.mező): a művelet mitől függ és mit érint a környezetében HATÁS A KONTEXTUS LEÍRÁSNÁL a 2. PONTBAN
94
A felsorolt módon a folyamatspecifikációs űrlap C. részével (7. táblázat) sorrendiségi és oksági kapcsolatba hozzuk a folyamat alaptevékenységeit egymással és más tevékenységek szereplőivel a manuális és formális verifikáláshoz és a folyamatszabályozáshoz, a következőképpen:
A, B oszlopok múlt idejű események megelőző feltételekkel
D, E
oszlopok
jövőidejű
események,
szereplőik,
feltételeik
az
A, B
folyamatspecifikációs lapon
E, B oszlopok eseményei, folyamatai, szereplői szervezeti stratégia és cél együttes vizsgálatát igényelik – időegységek, függőségek – lásd specifikáció elemek a folyamatszemlélettel és rendszerszemlélettel (dinamikus, strukturális, reaktív(+), proaktív (-) jellegükkel az A és B lapon
A 7. táblázattal meghatározzuk a folyamatok tevékenységeit és kapcsolataik jellemzőit strukturális, funkcionális és időrendi nézetben. Egy folyamat tevékenységei alá-fölérendelt előfeltételes illetve alá-fölé rendelt utófeltételes osztályban lehetnek. Hatásukat tekintve a folyamat tevékenységei elindító, válaszoló, igénylő, bedolgozó típusúak lehetnek, illetve felhasználó, bedolgozó, kiközvetített típusú. A módszer továbbfejlesztéséhez az osztályozás megalapozza a szabályalapú modellellenőrzést temporális logikai formulákkal. 7. táblázat Tevékenység©forgatókönyv űrlap (feladat, műveletek leírása a művelet űrlapokon) a folyamatközi kapcsolatok elemzése a múlt és jövő idejű akciók függvényében (C.űrlap) A
B
Alá-fölé rendelt előfeltételes tevékenység Elindító/igénylő/ művelet (lehet B, E, D)
Elindító/válaszoló bedolgozó művelet (lehet E) KI -KINEK
C Fő tevékenység TÁRGY: Tevékenység, Feladat neve
D
E
Alá-fölé rendelt utófeltételes tevékenység Eredményt Bedolgozó felhasználó művelet, művelet, kiközvetített szereplő (lehet részművelet A, E) végzés KI-KINEK
Kezdőművelet neve További műveletek neve, kategóriája Külön sorban kell megadni mindenik alapműveletet (folyamatspecifikációs űrlap 15. sor) a tevékenységek egyértelmű társításához Befejező művelet
95
4.2.3 Az üzleti folyamatgazda feladatai a folyamatspecifikációs űrlap kitöltéséhez önellenőrzéssel 8. táblázat A folyamatspecifikációs űrlap kitöltésekor az önellenőrzés szempontjai
A folyamatspecifikációs űrlap kitöltésekor az önellenőrzés szempontjai: Az önellenőrzést a dokumentum készítője végzi, míg a másodolvasást a készítőtől szigorúan különböző munkatárs. Indoklás: A létrehozás idején lényegesen kisebb ráfordítással érhető el bármilyen javítás a később végezhető javításokhoz képest. Az önellenőrzés utáni esetleges újabb ellenőrzések már elvétve jelentenek hiánypótlást, azok inkább az optimalizálást fogják szolgálni. A-B-C űrlaprészek a szempontokat adják, a kategóriák a módozatokat. A0).Vizsgálni a folyamatmodellezéssel egyidejű optimalizálást: Fontos döntés: a jelenlegi munkavégzés és meglévő munkautasítások tükrözik-e mindazt ami bekerül a leírásba? A döntés során mérlegelni kell, hogy saját hatáskörön belül azonnal életbe léptethető-e a modellezés során felfedezett hiányosság, és már a jobbított folyamatelem kerül dokumentálásra. Ha azonnal nem vezethető be a jobbítás vagy másokat is érint, nem lép a jobbítás saját hatáskörrel érvénybe, akkor az optimalizáláshoz kell sorolni, és a folyamat jelenlegi állapotát dokumentálni a modellben, a javaslatgyűjtőben pedig a felfedezett hiányosságokat. A1.) Vizsgálni a folyamatspecifikációs űrlapon a modell teljességét: 1.Van-e az ellenőrzött folyamatleíró kategóriához bejegyzés? Felülbírálni a nem jellemző „nj.” bejegyzéseket is! 2. Döntésvezérlő jellemzők kellően részletezettek-e? Számításos vagy jelöléses-e a megadásuk? Egyértelműek? Bedolgozó művelet állítja elő? Miért? Felelősségek, dokumentumok, egyéb kísérők figyelemben tartása fontos! Számításos tulajdonság: a megnevezett „Korlátok”, „Elő- és utófeltételek”,
„Sikeres” és „Nemsikeres
működés” esetén, adatjellemzőket kell megadni, ha számított érték alapján történik a munkafolyamatban valamely döntéshelyzet (automatikus útválasztás paraméterezett kifejezésekkel a folyamatok átjárhatóságához). Ezáltal a megadott adatjellemzőkkel a feltételek szerkesztése és célja egyértelmű, majd a kiszámítás alapján lesz igaz vagy hamis a folyamat elágazása, ha nincs adat a jelző igaz/hamis beállítása szerint. Jelöléses tulajdonság: a feltételek szerkesztésénél a feltárás idején megadhatjuk jelzővel a „megfelel”, „nem felel meg” döntéshelyzethez szükséges jellemzőket mint szöveges szabályt. Ezek a részletes kidolgozásnál vagy a folyamatok adott célú átjárhatóság-vizsgálatához kerülnek a szabályok algoritmizálására, ami hatékonyságot ad főleg abban az esetben, amikor a döntés maga egy bedolgozó művelet (program, másik folyamat része) vagy egyszerű rutinszámítási művelet lesz a munkafolyamatban. B.) Vizsgálni a konzisztenciát: 1. Konzisztencia – összeférhetőség vizsgálat a megadott részekre és jellemzőkre. A munkafolyamat állagát látni kell a folyamatgazdának, hogy összetartozóak a jellemzők és folyamatosságot adnak, nem „esik szét” a munkafolyamat. Többszereplős? Párhuzamosan/egyidejűleg végzett több különálló részfolyamatból áll össze?
96
2. Ellentmondásosság – a szereplők és szerepek viszonyában, a jellemzők értékkategóriájában ellentmondás. Vizsgálni kell a folyamatspecifikációs űrlap sorszámozott elemeit a kontrollmezőkkel vagy összetartozó adatkategóriákkal: - 18.,19., 20. összhangban van-e a 3., 4., 5., 6., 7. pontokkal? - 15. és 16. realitása – JELENLEGI helyzetben a 16. üres, kivéve, ha ugyanazt a műveletet több példányban végzik és többféle mód rögzített, ez esetben mi a belső szabály a folyamatra. Egy műveletvégzés esetén a 16. lehet a javaslat az optimalizálásra másik folyamatdokumentumban. A 16. kivételességét az alap 15. leíráshoz képest egy más műveletsorral (sorrend számít, benne az elemek is) adjuk meg, ami ugyanazt a végcélt és eredményeket adja. DE célja valami körülményt figyelembe venni („bolondbiztos” felhasználói művelet, természeti csapás), ami beépített és könnyítés, előrelátás valami akadályozó körülményre. A több utas eredmények ellenőrzése, ahogyan el lehet jutni a végcélhoz – melyik a természetes és ezzel egyben az alaptevékenység kategória?
Pl. italautomata esetén kezdhetem pénzbedobással, utána
árukiválasztással, aztán ha nem elég a kiválasztott áruhoz a bedobott pénz, még pénzbedobás műveletre van lehetőség – itt az utóbbi a kivételes, mert a célszerű alaptevékenység először az árukiválasztása és utána a pénzbedobás, árukiadás és/vagy pénzvisszaadás. Azaz, ha a körülmények miatt megengedett a műveletek felcserélése, akkor a kommunikációt kell előtérbe helyezni az eredményességhez, és többféle köztes lépéssorrendet megengedni a köztes műveletekre . 3. Rejtett holtpontok kiszűrése a munkafolyamatba művelet előkészítő vizsgálatok beiktatásával – pl. a lassulás, várakozás kontroll nélkül is rejtett holtpont -, amely a soha be nem következő folytatást ígéri, hiszen az eredményt felhasználó észleli, hogy nincs mit felhasználjon – a műveletsorba önjavító művelet beiktatása szükséges, mint időmérés feltétel, vagy szinkronizálás az eredményfogadó megszólításával előzetesen. C.) Vizsgálni az azonosíthatóságot és a kategóriák közötti felcserélés lehetőségét - a 15.,16. esetén sorszámozni kell a műveltvégzés lépéseket, nem felsorolni - a 17. esetén sorszámozni és megadni melyik sorszámra vonatkozik a 15., 16.-ból, vagy épp az derül ki, hogy elő-utófeltétel és nem minőségi kategória, azaz nem 17., hanem a 12. és 13. kategóriába tartozik. D.) Vizsgálni az egyedi és összesítő leírás összhangját - a tevékenység forgatókönyv űrlapba beírt tevékenységek összhangban vannak-e a 15. alapműveletek kategóriában leírt részletekkel (befejező, indító, alá, fölérendelt, illetve szereplők és eredmény-felhasználók).
A 7.4 Mellékletben az 15. és 16. táblázat mutatja a folyamat modellezését természetes nyelven. A Fedezetvizsgálat folyamathoz tartozó folyamatgazda által felbecsült értékeket látjuk, amely alapján a specifikátor kifejleszette a folyamat UCM modelljét, amelyet a 28. ábrán láthatunk a kiegészítő információk nélkül. A kiegészítő információkat dokumentáció készítéshez a jUCMNAv eszköztámogatás jelentéskészítő szolgáltatásával kaphatjuk meg a jUCMNav Report .rtf és .pdf formákkal. További formák: kép, html. A módszertanhoz tartozó oktatási segédletek és betanítási folyamat alkalmassá teszik az üzlet szereplőit az üzleti folyamatok validálására. 97
4.2.4 Use Case Maps elemek alkalmazása folyamatspecifikáció kategóriákra Az UCM útvonalakat komponensekel behatárolva és forgatókönyvekbe foglalva válaszolunk az üzletben a Hol, Mit, Mivel, Kivel, Mikor, Ki csinál? kérdésekre. A Miért kérdésre a GRL célfákkal válaszolunk meg. A 23. ábrán a szokásos alap workflow jelkészletet láthatjuk, a folyamat
haladása
a
útvonalon,
amelyben
parciális
rendezettséget
Path
kapnak
a
tevékenységek sorrend jelzéssel az
egymásutániságban.
haladási
irány
A
megadásával
megengedett a hurok és a kör is. 23. ábra Folyamatszemlélet alapesetben UCM jelölésekkel
Ezek konzisztenciáját a validálás során
szerkezetbontással
vagy
feltételekkel biztosíthatjuk. A
24.
ábrán
specifikáció szükséges
láthatjuk
a
strukturálásához elemeket
információközlésre modulárisságra
az
és
a
nézve.
A
funkcióba, cselekvésbe, feltételes
24. ábra Folyamat strukturálódása UCM jelölésekkel
kifejezésbe
nem
szöveges
követelményeket
megjegyzésként kategóriánként
építhető ábrázoljuk
összegyűjtve
a
követelmények összefüggéseiből a részleteket elmentve Dynamic stub hivatkozással. A minőségi elvárásokra időzítést, társítást, korlátozásokat, és szinkron asszinkron műveleteket adhatunk meg, amelyekhez a jelöléseket a 25. ábra Folyamatszemlélet minőségi elvárások teljesítéséhez
25. ábrán láthatjuk. 98
A
folyamatok
ellenőrzését
és
jóságának végrehajtásuk
konkrét eseteit forgatókönyvek formájában
szimulációval
végezzük. A 26. ábrán láthatjuk a példát
a
szerepére
és
forgatókönyvek kezelésükhöz
végrehajtási
módot
fejlesztőeszközben. 26. ábra UCM forgatókönyv példa a Hol, Mit, Mikor, Kivel, Ki kérdésekre
kódoljuk
a
a a
Színezéssel
komponensekkel
megadott szervezeti egységeket, valamint azokat az absztrakt objektumokat, amelyek funkciók szoftvermegoldásait, cselekvések tárgyára vagy eszközeire nézve a hely- és módhatározókat jelentik. A 27. ábrán erre látunk példát és a forgatókönyv részletre, amely a Hol, Mit, Mivel, Kivel kérdésre 27. ábra UCM forgatókönyv példa a Hol, Mit, Mivel, Kivel kérdésekre
válaszol meg.
4.2.5 Eljárás a folyamatspecifikációs űrlap alapú specifikálás menetére A folyamatspecifikálás a szervezeti keresztkapcsolatok és minőségi elvárások elemzésével történik meg az A, B űrlapok, valamint a tevékenységekre a folyamatközi kapcsolatok elemzésével a múlt és jövő idejű akciók és szerepek nézetében a C.űrlap alapján. Eljárás specifikátorok számára az UCM modellek létrehozásához a 6. és 7. táblázatban megadott folyamatspecifikációs űrlap példányok alapján (zárójelben a mező sorszáma a táblázatban): A. A legújabb verziójú jUCMNav használata – Update. B. A folyamatleíró űrlap A, B és C részeinek tanulmányozása, a 4.2.3 alpontban bemutatott folyamatellenőrző lépéseket követve a konzisztencia vizsgálathoz. Az inkonzisztenciát jelezni kell a felelősöknek, nagy eltérések esetén a specifikálást nem szabad elvégezni. A folyamat megértéséhez bonyolultság esetén először papíron UCM piszkozatot érdemes felrajzolni. 99
C. Az UCM diagram szerkezetének kialakítása: a lapon legfelül Comment felvétele: a. A
diagram
felső
részében
két
db
Comment
doboz
felvétele:
a
folyamatspecifikációs űrlap adatai - a folyamat neve, folyamat gazda, vállalati terület; az űrlapból az általános leírás és végcél információk (21.) dokumentálása. b. a diagram alján egy db Comment doboz felvétele: a specifikátor megjegyzéseit hordozza a specifikációval kapcsolatosan, vagy a folyamatspecifikációs űrlap hiányaival és nem egyértelmű közléseivel kapcsolatosan, az inspekció idejére. D. A komponensek megnevezése: TEAM neve a tevékenységet és a szereplő-szerepszervezet (3.) nevét tartalmazza. Pl. Nagel terhelésnél: Ellenőrzés-Bongrain (Folyamatgazda neve). Ha az űrlapban nincs szerep-szereplő megadva, akkor csak a tevékenységet adjuk meg röviden a Description mezőben és ábrázoljuk az útvonalon. E. Alap műveletvégzés tevékenységek (15.) felvétele (Responsbility). Értelemszerűen kell felvenni az elágazásokat OR-FORK. F. Egyidejű műveletvégzés (19.) Timer vagy párhuzamos AND-FORK alkalmazással. G. Kivételes műveletvégzés, minőségi követelmények – OR-FORK elágazásokkal megadva. H. Minden tevékenység (Responsibility) a hozzá tartozó (TEAM) komponensben legyen megadva. Ezek általában a fő alapműveletek szerint vannak dobozolva. Egy dobozba több tevékenység is kerülhet (szereplőhöz tartozó tevékenységek). A tevékenységek neve rövid legyen. A Description ablakban kell azokat hosszan kifejteni. I. Minden plusz információt, amelyre nem adunk cselekvést az útvonalon, a későbbi feldolgozáshoz a DYNAMIC STUB elemmel kell felvenni az információk kategóriái szerinti STUB megnevezéssel. Ezek: Elvárás (12.), Szabályok (11.), Olvasások (9.), Korlátok (5.), Üzenetek (8.). Elhelyezésük az útvonalon a tevékenységleírások értelmezése szerint történik (28. ábra). Mivel egy adott folyamatszakaszhoz több elvárás/olvasás/szabály
is
tartozhat,
így
azokat
emelkedő
számsorrendben
sorszámozva külön azonosítókkal kell címkézni. Például a Nagel példában 5 elvárás van megfogalmazva különböző tevékenységekre. Ezeknek megfelelő sub-UCM szerkezet ugyanolyan felépítésű, mint a root-UCM: Process-Comment, Start-End. J.
Minden kapcsolódó területet, külső szereplőt külön TEAM szimbólumba kell felvenni, és sárga színt kell hozzájuk rendelni. Ha ismert az azonosítójuk, akkor azt fel kell tüntetni a TEAM nevében, de a név felvételére itt is a 6. pont vonatkozik. Ez a
100
legfontosabb pont azért, hogy a későbbi információ és adat áramlás útja végigkövethető legyen. Szemléltetéshez választottuk a 28. ábrán látható UCM modellt, amelyet a 7.4 Melléklet 15.-16. táblázatában a folyamatspecifikációs űrlappal megadott konkrét folyamat leírása alapján a specifikátor az üzleti szereplők vagy előzetes interjú nélkül önállóan állít elő.
28. ábra Példa folyamatspecifikációra: a Fedezetvizsgálat UCM-root (folyamatleírás 7.4 Melléklet 15.-16. táblázat)
A négyszögek a rendszerkomponenseket egymásbafoglalással (színkódolással is!) ábrázolják, a komponenseket átszelő folyamatos vonalak együttesen alkotják a modellezett folyamatot. A vonalon elhelyezett jelölésekkel a lokális eseményeket (× feladat) és a 101
strukturális elemeket (● kezdőpont, │ végpont, ◊ részfolyamatokhoz átjáró, ┤ elágazás, ├ becsatlakozás, ↑ irány, stb.). További jelölések a 4.2.4 és 4.3.1.1 alpontokban láthatók és a http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/HelpOnLine címen. A jUCMNav vizuális támogatása segíti az üzleti elemzőket és folyamatgazdákat, és további lehetőségeket nyújt a fejlesztőknek [Mus07b]. Az eredmények dokumentálása lehetséges kép, html, rtf, pdf formátumokban. A 28. ábrán követhetjük specifikáció strukturálását az információközlésre és a modulárisságra nézve, a Dynamic stub hivatkozással a részleteket elmentve, technikailag submap formában, ezzel ábrázolásuk önálló kezelési egységgé változik, és megtekinthetők dokumentációs formákban. A nem algoritmizálható követelmények kategóriánként kerülnek sub-map modellbe meghivatkozva a folyamat más pontján. A sárga színű komponens egyezményesen a folyamatra nézve külső szervezeti egységet jelenti. 4.2.5.1 Validálás szimulációval A jUCMNav fejlesztőeszköz az URN szabványtámogatással fejlesztett Eclipse plug-in (lásd 1.5.1 alpontban) amely egyedi azonosítókat rendel a modell minden eleméhez, automatizálja a követelményfeltárás és elemzés technikáit, szimulációs validálással automatikus modellellenőrzést biztosít. Ennek folyamán emberi tevékenység szükséges a megkívánt vizsgálati módok beállításához.
29. ábra jUCMNav eszköztámogatása a követelmények validálásához stratégiakiértékeléssel
102
Ennek eszköze a forgatókönyv nézet programozása a szcenáriók létrehozásával és szimulációjával. A validált forgatókönyvet XML automatikus modelltranszformációval kell másik absztrakciós szintre vagy más kezelőeszközbe exportálni további modellezéshez az MDE folyamatban. A 7.4 Mellékletben az 52. ábrán láthatunk egy fejlesztői nézetet a szimulációs validálás futási eredményéről egy meghatározott forgatókönyvre (piros vonal a sikeres futás). Az egyes UCM folyamattérképben a megkívánt, vagy lehetséges használati esetekre kell létre hozni szcenáriókat, majd kiexportálni MSC látványba. Ennek menetéről bővebben lehet olvasni a [jUCMNav] oldalon, a specifikátorok oktatásában a következőképpen történik: A forgatókönyvek (scenario) létrehozásakor a sikeres validáláshoz az UCM folyamattérkép mindenik elágazására el kell végezni az alábbiakat: 1. Inicializáljuk az esetszétválasztás szelektorait: -
kiválasztjuk az egyik ágat, és hozzárendelünk létrehozással egy Boolean változót beszédes névvel.
-
a további ágaknál hasonlóan járunk el, az előzőleg felvett változót válasszuk ki és értékét false értékre állítjuk.
2. Szcenárió nézetben új szcenáriót hozunk létre, és a jellemzőket beállítjuk, mint kezdőpont, Start Point Initialization az előzőekben az útvonal elágazásokra felvett szelektorok beállítására (névválasztás fontos) True, False értékekkel. 3. Kifejezéseket és értékhatásokat is megadhatunk az automatikus szelekcióhoz. A Variable Initialization beállítások mutatják, hogy a folyamatleágazások változtatásával különféle szcenárió eseteket készíthetünk az egyes útvonal csomópontok programozásával. 4. Ha egy folyamatban nincs elágazás, akkor egy szcenáriót lehet felvenni, és egyszerű szekvencia diagramot kapunk a modelltranszformációval. 5. Amennyiben a folyamatspecifikációs űrlapon nincs feltétel meghatározva, úgy változó nélküli igaz-hamis értékeket állítunk be beszédes megnevezésekkel az elágazás két oldalán. 4.2.6 URN folyamatmodellezés dokumentumtípusai és kezelésük a. Elektronikus felhasználással dokumentumkezelőkkel - egyidejűleg egy/több folyamat kezelhető: -
html – böngészőkkel (Internet Explorer, Mozilla Firefox)
-
jpeg – képnézegetőkkel
-
rtf – szövegszerkesztővel
-
pdf – pdf kezelővel 103
b. Papír alapú felhasználással - egyidejűleg több folyamat kezelhető -
jpeg – képnyomtatás papírméretre (A4, A3)
-
rtf/pdf – jUCMNav Report nyomtatása folyamatonként
c. Elektronikus felhasználással jUCMNav folyamatkezelőben – egyidejűleg több folyamat szerkesztése és megtekintése lehetséges -
szerkesztés Eclipse felhasználói felületkezeléssel egy-több lap egyidejű kezelése lehetséges a területenkénti vagy területközi folyamatok vizsgálatához
-
nézetek ua.
-
export / import - html, rtf, jpeg, pdf, msc, jucm formátumokban
4.2.7 Folyamatfeltárás és folyamatspecifikálás minőségbiztosítása oktatással Oktatás a specifikáció dokumentumainak kezeléséről és használatáról az alábbi csoportosításokkal: 1. Folyamatfeltáró űrlap – adatcsoportok kezelése – 6. és 7. táblázathoz a 4.2.3 alpont szerint és az alábbi csoportosítással: - cél, szerep, szereplő, szervezeti egységek, adatkapcsolatok, - alap-tevékenységek sorozata, kivételes tevékenységek sorozata, minőségi elvárások - kontroll mezők alkalmazása - tevékenységek folyamatközi kapcsolatai (7. táblázat) 3. Folyamatspecifikálás oktatása a. folyamatspecifikációs űrlap elemei, alkalmazása a specifikációkészítéshez (4.2.5 alpont szerint a specifikátorok oktatása) b. minőségbiztosítás a strukturális elemek alkalmazásának vizuális hatásával (7.4 Melléklet 52. ábra): - vízszintes és függőleges vonalvezetés az utak (path) elhelyezésénél, előre és jobbra - elágazásoknál töréspont beiktatása a le és balra haladáshoz, határozott visszakanyarodással vízszintes vonalvezetéssel - huroknál az irány megadása - csomópont
csonk
(stub)
esetén
az
útvonalak
függőleges-vízszintes
kiegyenesítése a stub közelében 4. Folyamatspecifikáció dokumentációs elemei és kezelésük (4.2.6 alpont szerint) 5. Inspekciós forgatókönyv – perspektíva készítés és lebonyolítása (4.2.8 alpont) 104
a. Tartalma a jelenlegi állású minőségpolitika szerinti. Új perspektívát kell szerkeszteni a folyamatszabályozás után a jövőbeni karbantartáshoz (megfigyelési pontokra) -
perspektíva szerinti ellenőrzés lépéseit oktatni kell konkrét példával
b. Használata -
specifikációk dokumentációi és folyamatspecifikációs űrlap inspekciós forgatókönyv-alapú olvasása
-
inspekciós perspektíva szerinti forgatókönyv lépéseit betartva (9. táblázat)
-
inspekció folyamata szerint a hibadetektálás és hibajelentő űrlap kitöltése
6. Hibajelentő űrlap – tartalma és kitöltése (10. és 11. táblázat) a. Tartalma a hibadetektálás dokumentálásához szükséges mezőkkel és magyarázó megjegyzéssel b. Használata az inspekció, a specifikáció javítása, a specifikáció javításának inspekciója során -
hibadetektáláskor adott minőségpolitika szerinti perspektívában, inspekciós forgatókönyv + hibajelentő űrlap
-
hibaérvényesítéskor a területi konzultációs ponton
-
hibakorrekciónál dokumentumcsomag cserével és ennek inspekciójánál
7. Folyamatoptimalizálás és folyamatdiagnózis készítés -
minőségpolitika létrehozása és oktatás területenként a csoportfelelősök és folyamatgazdák részére
8. Folyamatmodellek karbantartása -
jövőbeni céloktól függő feladat, oktatása szükséges vagy szolgáltatás keretében történik
4.2.8 Folyamatfeltárás és folyamatspecifikálás minőségbiztosítása inspekcióval A szoftverfejlesztésben a szoftverinspekció a mindenkori elsődleges minőségbiztosítási módszer. A szoftver inspekciók a hibák 50 – 90%-át felfedhetik a termékben [Bri98], mielőtt másik függésben lévő köztes termékhez ajánlanák. A szoftverinspekciót mindenfajta termékre el lehet végezni, a szemcsésség és absztrakció minden szintjén a leginkább költség-hatékony hibadetektáló technika. Az alapgondolat az, hogy minden fő fejlesztési terméket szisztematikus és szigorú inspekciónak kell követnie. Fontos, hogy ne keverjük össze az inspekciót az informális áttekintéssel és termék beméréssel. Az inspekció olyan
105
tevékenységeket foglal magában, ahol a képzett személyzet meghatározza, hogy a szoftvertermékek megfelelő minőségűek-e a következő fejlesztési fázisokhoz [Bas97]. A fejlesztők első reakciója általában a szélsőséges eltéréseket igazoló esetek felkutatása az egyes konkrét szoftverminőség metrikákra, és nehezen tudják elfogadni, hogy korreláció van a metrikák és a fejlesztett szoftver minősége között [Gyi09]. 4.2.8.1 Inspekció szervezése Az inspekció fő műveleti a szervezési technikák az inspekció tárgyának meghatározásához és az olvasási technikák. Az inspekció tárgyának meghatározásához a dokumentum-centrikus stratégia kiválasztja az inspekció fókuszaként szolgáló specifikus dokumentumokat, az architektúra-centrikus stratégia kiválasztja azoknak a logikai termékeknek a kollekcióját, amelyek egy rendszer architektúráját jellemzik [Lai00]. A kevert stratégia terjedt el a gyakorlatban. A dokumentumcentrikus stratégiát alkalmaztuk a módszertanban. Az olvasási technikák elterjedten az ellenőrzési lista-alapú olvasási technikák és a forgatókönyv-alapú olvasási technikák. A legkorszerűbb forgatókönyv-alapú olvasás neve a perspektíva-alapú olvasás [Bas97, Lai00]. Ez szeletekre osztja az olvasási munkát a kritikus kockázatvállalóknak az inspekció tárgyát illető perspektívái szerint. A perspektíva alapú olvasás technikát alkalmaztuk a módszertanban Forgatókönyvek és hibagyűjtemény űrlapok Minden forgatókönyvnek van egy kapcsolt szöveges leírása, ami vezeti az inspektort az inspekciós forgatókönyv követése során. A valóságban egy adott perspektíva szerinti olvasáshoz történik a forgatókönyvek összeállítása. A ProjektProcessz módszertanban létrehozott perspektívát a 9. Táblázat tartalmazza, amit a folyamatspecifikációs űrlap sorszámozott kategóriáinak összefüggéseire hoztunk létre és ezekből készült folyamatspecifikációk dokumentációira. Strukturális tulajdonságok ellenőrzése Egy szoftvertermék strukturális tulajdonságai (pl. egy osztály másik osztállyal történő párosítása vagy egy osztály belső komplexitása) fontos szoftver minőségi attribútumok mutatóiként szolgálhatnak. Például a nagyon komplex osztályok nagyobb valószínűséggel tartalmaznak hibákat, ezért negatívan hatnak a rendszer megbízhatóságára. A párosított osztályok módosítása nehezebb, ez pedig a rendszer fenntarthatóságára hat negatívan. A strukturális tulajdonságok mérése objektív folyamat, nem támaszkodik szubjektív ítéletre és automatizálható. Ismert ipari automatizálás modellvezérelt fejlesztésekhez az 1. 106
Tézis technológiáira a modellezés minőségi attribútumainak létrehozásához és beállításához a Kemman kutatásai, amelyek fejlesztési folyamatonként szabályozzák a jellemzőket [Kem11]. A modelltermékek strukturális tulajdonságain alapuló ellenőrzés a korai visszacsatolással lehetőséget nyújt a komponensek potenciális minőségi problémáinak azonosítására és megelőzésére. Az URN modell strukturális és viselkedés elemeket tartalmaz, amelynek előnye a rendszerés folyamatszemlélet egyidejű kezelése, és a modulárisság szervezése. A modellek ellenőrzésében a függésben levő osztályok viselkedését szcenáriókkal validálhatjuk elkülönített modulban. Ilyen irányú kutatásokra a vonatkozó URN szakirodalomban nem találtunk kutatást. A módszertanban a folyamatspecifikációs űrlap kategóriái alapján szervezzük a strukturális tulajdonságok ellenőrzését inspekciós perspektívába és véghezviszik a folyamatgazdák az inspekciós forgatókönyvek alapján. Inspekciós perspektívák A 8. Táblázatban a folyamatspecifikációs űrlapok alapján létrehozott UCM specifikációk inspekciós perspektíváját láthatjuk, amely alapján az inspekció történik. A
ProjektProcessz
módszertanban
öt
darab
perspektívát
határoztunk
meg
a
folyamatspecifikációk és folyamatfelderítő űrlapok együttes inspekciós folyamatára. Az űrlapkitöltésre (2) az érthetőség és átláthatóság; a folyamat tevékenységeire (3) a minőség követelményei, szervezeti vonatkozásai, szabályozási feltételei. Az inspekció tárgya –
Folyamatspecifikációs űrlap vizsgálata
–
Folyamatspecifikációk vizsgálata az átadó-átvevő pontokra, erőforrásigényekre,
folyamatidő és szakaszidő vizsgálata. 4.2.8.2 Az inspekció eszközei A folyamatspecifikációs módszertanban az inspekció eszközeit alkotják az Inspekciós perspektívák forgatókönyve, a Hibadetektáló és hibajavító-, valamint az Inspekciós hibaérvényesség és korrekciós űrlapok. Az inspekció lebonyolítását megelőzően meg kell határozni a területi információs pontokat és felelősöket a területközi folyamatkapcsolatok egyeztetéséhez, elkerülendő a szigetszerű folyamatkezelést. Ennek ideje és helye a specifikációk átadásával egyidejűleg, vagy azt megelőzően, az oktatás részeként csoportfoglalkozással irányított képzésben van célszerűen. Összevont területközi pontokat érdemes létrehozni logisztikai, termelési részlegek közötti, és egyéb hasonló vertikális nézetű folyamatközi kapcsolatokra. 107
9. táblázat Inspekciós perspektíva megadása jelenlegi helyzet üzleti folyamatainak inspekciójához
Inspekciós perspektívák - ProjektProcess módszertan UCM specifikációk ellenőrzése folyamatspecifikációs űrlap alapján. Szempontok folyamatgazdáknak és területfelelősöknek 1.
Érthetőség, átláthatóság
Olvassa a kezdőponttól az útvonalon haladva a nyíl irányában a tevékenységeket. A folyamatspecifikáció érthetően tükrözi-e a folyamatot? Ha igen, folytassa a következő perspektíva olvasásával. Ha nem: folyamatűrlap ellenőrzése szükséges. a. Ha a folyamatűrlap hiányos, vagy eltérő, hibadetektáló űrlapon kell megadnia. b. Ha folyamatűrlap helyesen van kitöltve, a specifikáció hibadetektálása szükséges az alábbi perspektívák szerint. 2.
Folyamat tevékenységei: alap-, egyidejű és kivételes műveletek-15., 16., 19.
A folyamat tevékenységei hiánytalanul/variációkkal az útvonalakon vannak? Ha nem, hibaként adja meg ezeket. A specifikáció tartalmaz megjegyzésdobozba helyezve kérdést/észrevételt? Ha igen, értelmezze és hibaként adja meg a javaslatot. 3.
Folyamat minőségi követelményei: minőségi elvárások-17.
A megadott sorszámú tevékenységnél a minőségi követelmény megjelenik? Ha nem, hibaként adja meg ezeket. 4.
Folyamat szervezeti vonatkozásai: címzett - 8, igénylő -7., felhasználó 4., szereplő-3.
A megadott szervezeti vonatkozású (szervezet-szerep-szereplő) komponens vagy munkacsoport megfelelő a folyamat tevékenységére? Ha nem, hibaként adja meg ezeket. 5. Folyamatszabályozási feltételek: Elvárások - 12, Olvasások - 9, Bejövő információk - 6, Szabályok – 11. A feltételek a folyamat tevékenységekre vonatkozóan megvannak megadva? Ha nem, adja meg hibaként ezeket.
10. táblázat Hibadetektáló és hibagyűjtő űrlap
Inspekciós hibajelentő űrlap – Projekt Process módszertan Dokumentum Hiba
Helye
Srsz./
specifikáció/
Persp.
folyamatűrlap
Leírása
Megj.
Srsz.
108
11. táblázat Inspekciós hibaérvényesség és korrekciós űrlap
Inspekciós hibaérvényesség és korrekciós űrlap – Projekt Process módszertan Dokumentum Hiba
Helye
Srsz./
specifikáció/
Persp.
folyamatűrlap
Érvényessége/ korrekció
Talált/
helye és leírása
vizsgált (hiba srzs.)
Srsz.
Megj.
4.2.8.3 Az inspekció folyamata a módszertanban 1. Inspekciótervezés (inspekciószervező) a. Folyamatgazdák
és
területfelelősök
kiválasztják
a
felelősségükbe
tartozó
ellenőrzendő UCM specifikációkat és folyamatspecifikációs űrlapokat b. Meghatározzák az inspekciós moderátort és az inspektorokat (csoportfelelősök, minőségfelelősök, folyamatgazdák) és perspektívájukhoz tartozó feladataikat. Ütemezik a hibagyűjtési értekezletet és az inspekciós anyagot elküldik az inspekció résztvevőihez. 2. Áttekintő
értekezlet
(inspekciószervező,
moderátor,
inspektor,
specifikátorok
képviselője, folyamatgazdák képviselője) – áttekintik az inspekciós tervet, a hibadetektálás menetét és a hibagyűjtés kritériumait. 3. Hibadetektálás (inspektor) a. Az inspekciós perspektívák forgatókönyve szerint el kell végezni a tevékenységeket és válaszolni kell a feltett kérdésekre. Egyedi hibadetektálási űrlapokon történik a detektált és megjelölt hibák dokumentálása b. Az
egyedi
olvasás
után
egyedi
hibadetektálási
űrlapokat
kell
kitölteni,
megjegyzésben a felhasznált időt (lásd.10. Táblázatban). 4. Hibagyűjtés (moderátor, inspektor, specifikátor, folyamatgazda) a. Az értekezleten minden lehetséges hiba érvényességét közösen kell megítélni, az elfogadott hibákat egybegyűjteni az űrlapokon, és minden egyes hiba súlyosságát magas, közepes vagy alacsony jelzőkkel megjelölni b. A moderátornak kell biztosítania, hogy az értekezlet pozitív hangulatban folyjon. Az inspektorok az értekezleten a hibadetektálás során meg nem talált hiba okokat és 109
forrásokat derítik ki. A specifikátoroknak és folyamatgazdáknak meg kell érteniük a hibákat és rájönni, hogy miként tudják elkerülni őket a jövőben c. Miután minden hibát megbeszéltek, el kell dönteni, hogy a terméket újra kell-e inspekciózni d. A hibagyűjtő űrlapot ki kell tölteni (a felhasznált időt is jelölni kell). 5. Hibakorrekció (folyamatgazda, speficikátor) a. A minőségpolitika alkalmazásával el kell dönteni, hogy a hibákat miként lehet korrigálni. 6. Ellenőrzés a hibajavítást követően (inspektor). 4.2.9 UCM modelltranszformációk a modellfejlesztők és minőségfelelősök számára Mussbacher
és
Amyot
részletes
útmutatót
adnak
[Mus09]
közleményükben
a
modelltranszformációk lehetőségeiről és módjáról különböző absztrakciós szintek között, mint a hatékonyságvizsgálat [Pet05], tervezési nézet [Mig01, Bor00, Kea06, Kea07, Kar10, Kar11, Stö07, Scr99, Sal00],
tesztelés [Amy04, Has09].
A modelltranszformációk alapja a jUCMNav fejlesztőben mindig egy validált forgatókönyv XML formátumban, amely megjelenik kép és tulajdonság leírással a jUCMNav Report jelentések dokumentációiban, valamely ismert formátum exportálásával történik a transzformáció [jUCMNav]. A modellfejlesztők számára az üzleti folyamatok validált modelljeiből teszteseteket és a tervezéshez interakció diagramokat nyerünk automatikus modelltranszformációval. A 4.3.3.2 alpontban adunk példát követelmény-tervezés-teszt szintekhez. A
minőségfelelősök
számára
az
üzleti
folyamatok
modellezésében
a
modelltranszformációkat az üzlet számára a szabályozás előtti validálás eszközeként, valamint a minőségbiztosítás dokumentációs eszközeként alkalmazhatjuk. A munkaköri leírások automatikus előállítására van lehetőség az üzleti folyamatok modelljeiből, mivel az üzleti folyamatok forgatókönyveinek megfelelő szekvencia diagramokban a kommunikáló felek a munkatársak, így egy időtengely az interakciókkal megfelel munkaköri leírásnak a folyamat vonatkozó szereplőjére nézve. 4.2.9.1 Folyamatspecifikációk karbantartásának belső szabályozása Az eredményes üzleti folyamatmodellezés után, a folyamatok optimalizálásával meg kell alkotni az összhangot a Kölcsönhatások/Szabályok (6., 8., 9. / 11.) és a belső tevékenységfolyam (15.) nézetek között, és egymással összhangban kell tartani. Ezt végezheti 110
területenként kijelölt felelős vagy a folyamatgazdák, vagy módszer és modellezés szolgáltatók. 4.2.10 A módszer bevezetése Az üzleti folyamatok modellezésének az eredményességéhez fel kell készülni szervezeti szinten a középvezetők, felsővezetők, IT fenntartók oktatására, amint a szervezeti stratégiában az üzleti folyamatok modellezése eldöntött tény. Meg kell győződni a vállalat képességszintjéről COBIT felméréssel, és/vagy gyakorlott informatikai projektmenedzser tapasztalattal. A COBIT ajánlás [Cob12] szerint az üzleti folyamatok modellezéséhez a Cobit 2. képességszint szükséges. Az ipari együttműködésekben megtapasztaltuk, hogy az eredményességhez reális vállalati tudáshoz és konkrét felsővezetői támogatáshoz kell ütemezni az üzleti folyamatok modellezésének munkálatait. A projekt indításkor felsővezetői támogatás mellett ki kell terjeszteni az oktatásba bevont területfelelősök és folyamatfelelősök körét a csoportfelelősök szintjére is. Termelési részlegek esetén új termékek bevezetésével egyidejűleg sem oktatást, sem folyamat felderítést nem érdemes indítani. A ProjektProcessz folyamatspecifikációs módszer bevezetéséhez az alábbi lépéseket kell megszervezni: 1.
A szerepek meghatározása és kiosztása (szakterületek és területi felelősök,
specifikátor, csoportok és csoportfelelősök valamint a csoportba tartozó folyamatgazdák, területi inspekciószervező, moderátor, inspektor). 2.
Oktatás a szerepek betanítására a generikus folyamatspecifikációs űrlap és
esettanulmány alapján. A szereplőket szerepek szerint csoportosítva, területenként vagy jellemzőbb kölcsönhatásban levő területek összevonásával érdemes csoportokba szervezni. Az esettanulmányhoz a valós életből (módszertanban az árukiadó automata) és a bevezetés tárgyának általánosan ismert folyamataiból érdemes választani. Például az informatikai beszerzések folyamatát, amely minden területen ismert (lásd az oktatóanyagot). 3.
Folyamatok tulajdonságainak gyűjtése a folyamatspecifikációs űrlapok kitöltésével a
folyamatgazda által természetes nyelven 4.
Folyamatspecifikációs űrlapok kitöltésének önellenőrzése és csoportszintű inspekciója
5.
Specifikálás ütemezése, űrlapok kitöltésének ellenőrzése, specifikálása, inspekciója,
tesztelése, dokumentumok generálása 6.
Specifikációk inspekciójának szervezése és lebonyolítása
7.
Hibajavító specifikálás és javítás utáni tesztelés és dokumentum generálás 111
8.
Hibajavítás inspekciójának szervezése és lebonyolítása
9.
Hibajavítás
inspekciója
után
szükséges
javítások
elvégzése,
tesztelése
és
dokumentumok generálása 10.
Specifikációk területenkénti és csoportonkénti összesítése
11.
Területen belüli folyamatközi kapcsolatok inspekciójának szervezése és lebonyolítása
12.
Területen belüli folyamatközi kapcsolatok hibajavítása és ellenőrzése
13.
Területek
közötti
folyamatközi
kapcsolatok
inspekciójának
szervezése
és
közötti
folyamatközi
kapcsolatok
inspekciójának
szervezése
és
lebonyolítása 14.
Területek
lebonyolítása 15.
Folyamatok minőségszabályozása
16.
Optimalizált folyamatok javítása, a területenként összesített dokumentumcsomag
karbantartása 17.
Folyamatspecifikáció karbantartásának belső szabályozása
4.2.11 Módszer- és modellezés szolgáltatás a folyamatok karbantartásához Az üzleti folyamatmodellek alapján a szabályozásra és a folyamatmodellek karbantartására módszer és modellezés szolgáltatás szervezése indokolt lehet a vállalati képességek és célok szerint: -
Szabályozás- és minőségpolitika kidolgozása az üzleti és informatikai stratégiák ismeretében (tervezett alkalmazásintegrációk módja, ütemezése, B2B stratégiák)
-
Szabályozásra szimuláció több hierarchiában operatív és támogató folyamatokra ismert stratégiákkal (területek közötti, területenként, részlegenként)
-
Szabályozás utáni folyamatállapot specifikációja jUCMNav forrásokban és dokumentációcsomagban
-
Folyamatok karbantartása folyamatgazdák által vagy szolgáltatással jUCMNav forrásokban és dokumentációcsomagban
4.3 Módszertan keretrendszer építésére változáskezeléshez Tradicionálisan, a szoftver egy platformon fut, és a komponensek programozással jönnek létre. Ezek a munkálatok nem képeznek nagy kiadásokat egy szoftverrendszer létrehozásakor. A problémák és a nagy kiadások akkor keletkeznek, amikor az üzletmenet és/vagy az informatikai szolgáltatások valamilyen körülmény folytán megváltoznak [Hum89]. A változások kezeléséhez, mint a követelmények és a változtatások helyének meghatározása, 112
valamint a rendszert alkotó elemek függőségének kezelése, átjárhatósággal a követelmények és a megvalósításaik között. Az MDE technológiák a modelltranszformációk által támogatják az átjárhatóság beépítését a modellelemekbe és a modellkezelés módjaiba. A modellező eszközök a programverziókezelő rendszerekhez hasonló mechanizmusokkal un. repository – gyűjtemény alapú közös munkát biztosítanak a szerzőség hierarchikus jogi rendszerében. A fentiekre alapozva, és az előző tézispontban bemutatott eseti módszertan eredményeit felhasználva, általánosítjuk az üzleti modell újratervezését a döntéshozók bevonásához az újratervezésbe és a stratégiafejlesztésbe. Ehhez a több nyelvet támogató technológiai soron szétosztjuk a fejlesztési munkaelemeket, hogy a nézeteket összehangolhassuk és bevonjuk a döntéshozókat a változáskezelés stratégiatervezésébe. Nevezetesen, az üzleti szakértők részére adunk eszközöket, az üzleti stratégiák és az üzleti folyamatok cél-orientált változáskezeléséhez. Amikor a változás a rendszerben egy új aspektust jelent, a több-nyelvű megközelítés (GRL, UCM, UML, DSML nyelvek a technológia soron) jó eszköz a nézetek elosztott kezeléséhez, a fejlesztési munkák koordinálására, és az eredmények integrálására. Amikor a változás azért állt elő, mert szükség van arra, hogy a rendszer kövesse az üzlethálózatok stratégiáit, ilyen esetben az üzleti elemzőket célszerű bevonni a rendszer megváltoztatásába, és rendszerkonfigurációs folyamatban az új mutatókhoz igazítani a rendszer megváltozott működését. Nézetünkben a modellvezéreltség a változáskezelésre azt az előnyt nyújtja, hogy előállítunk kiinduló paraméterezett megoldásokat objektum- és folyamat osztályokkal, paraméterezett
űrlapokat
szerkesztünk
a
szimulációkhoz,
mintákat
adunk
meg
újrafelhasználáshoz az elemzők és érdekelt felek nézőpontjainak összeegyeztetésére. Kellő gyakorlat után, a változásjelenségek egy szakterületen kitermelik azt a technológia és ismeretvagyont, amely a létrehozott modellekben tartalmazza az üzleti intelligenciát a szakterületi ismeretekkel együtt, azaz a szakértőktől előállt specifikus üzleti modellt. A változáskezelés modellvezérelt keretrendszere a 4.1 pontban bemutatott technológiai sorra támaszkodva nyújtja a változások integrálását meglévő implementációs modellbe és/vagy gyorsfejlesztést komponenstechnológiákkal. A generikus keretrendszer modellt és használatát a 30. ábrával mutatjuk be. A keretrendszer tartalmazza a problématér generikus modelljeit, amelyek kiinduló eszközei lehetnek a cél-orientált fejlesztésnek és stratégiaalkotásnak, forgatókönyvek és folyamatok modellezésének.
113
Technikailag cél-fa és forgatókönyv modelleket fejlesztünk, amelyek elemeit összerendeljük,
az
un.
URN-links
kapcsolattal, ezáltal a vizsgált problémához hozzárendeljük
a
megoldást,
mint
{Pontosított üzleti stratégia, Pontosított üzleti folyamat} párost. A generikus modellek
adják
a
pontosításra
szánt
modelleket, mint kiinduló modelleket, 30. ábra URN és jUCMNav alapú generikus keretrendszer modell
amelyekből kapjuk az üzleti modellt.
A folyamat első lépéseként -1., 2. és 3.b jelek a 30. ábrán- iterációba kezdünk a célok és erőforrások összerendeléséhez a szándékok mentén a generikus/specifikus modellekből a problémához kiválasztott példányokkal. A vizsgálatokkal nyert stratégiákat és funkcionális modelleket megvalósításnak tekintjük a felmerült problémára -3.a jel a 30. ábrán-. Összekapcsoljuk a modellelemeket az URN-links tudásbázis támogatással, – 4.a jel az ábrán -, amelyek a döntéstámogatóknak csomópontokat jelentenek a probléma és megoldás terekben. A pontosított üzleti stratégiákat és üzleti folyamatokat a modellgyűjteménybe mentjük specifikus modellként -5.a és 5.b jelek a 30. ábrán-. Az URN–Link átjárhatóságot nyújt a szimulációs validálás folyamatában és az újratervezésben. A következőkben kifejtjük a módszertan elemeit, mint a keretrendszer implementálásának és újrafelhasználásának eszközeit. Ezek a következők:
URN technológiák (GRL, UCM, URN Link, jUCMNav) (4.2.4 alpont)
ProjektProcessz módszertan az üzleti folyamatok modellezésére és karbantartására (URN technológiák, folyamatspecifikációs űrlap, inspekciós és hibajavító űrlapok, oktatási segédletek, módszerek) –(4.2 fejezet)
Módszer Use Case Description sablon alapú URN modellezéshez (4.3.1 alpont)
Generikus modellek az információbiztonság szabvány alapú üzleti modellbe integrált biztonságtervezéshez (4.3.2 alpont, 7.4 Melléklet 45.-47. ábrák)
Generikus
modellek
az
üzleti
folyamatokba
integrált
mobil
eszközök
alkalmazásainak modellezéséhez (4.3.3 alpont, 7.4 Melléklet 17. táblázat és 49.-55. ábrák)
114
4.3.1 Módszer Use Case Description alapú URN modellezéshez 12. táblázat Use Case Description elemek megfeleltetése az URN modellezés menetének és elemeinek
G1. – G5 a GRL sorrend;
U1. – U6 az UCM sorrend
Use Case ID:
G1. GRL-root
Use Case
GRL azonosító
UCM azonosító
Szereplő/Actors
G1. Actor
U1. Component
Leírás/
G1.
U1.
Description:
Célfa 1. szint: goal - cél
Component, Comment
U1. URN Link
U1. UCM-root
Név/Name: Szerző/Author: Dátum/Date:
Célfa 2. szint: subgoal – felhasználás, egyéb célok And/OR decomposition
Eclipse - Description
Eclipse Description Behívó/Trigger:
G3
U2.
1. Külső actor,softgoal, task, majd
1. Külső trigger: Start+ condition
contribution, correlation
2. Belső trigger = feladat, Stub
2. Belső actor, trigger = goal Előfeltételek/
G2.
U3.
Preconditions:
ResourcePre (goal, softgoal, task)
Kontroll a teljesülésükről
(PRsorszám)
Believ (resource)
1.Stub, sub-map feltétel megjegyzésben 2.Responsibility és component submap tennivalókkal
Útófeltételek/
ResourcePos ( goal, softgoal, task)
U6. Kontroll a teljesülésükről
Post conditions:
Believ (resource)
1.Stub, sub-map feltétel megjegyzésben
(POsorszám)
2.Responsibility és component submap tennivalókkal
Alap
G3.
U4. stub, sub-map, component, path,
műveletek/
Célfa 3. – 4. szint:
responsibility,
Regular Flow:
fő tennivalók softgoal alá – lépések
Fő komponensek mobil eszközökre:
(RFsorszám)
tennivalókra sorszámmal együtt a
- Szereplő (Actor)
megnevezést megadni
- Felhasználói felület (UI) – telefon
Elválasztani a softgoal szintet – kliens-
konzol
szerverre - AND decomposition
- Mobil kliens – mobil készülék (Mobil
(actor) task (és szükséges resourceT
Client)
jelenleg)
- Szerver oldal – (Server side)
And/ Or/ XOR decomposition
And-Fork, And-Join, Or-fork, Or-join
(sub)goals
stub, (sub)component, team
And/ Or/ XOR decomposition tasks
AND-Fork, And-Join, Or-fork, Or-join
115
path, responsibility correlation, contribution kliens-szerver
variable, condition, feltételszerkesztések
között és az előző softgoal-k között.
változókkal
1. jelenlegi tennivalók hatása a
scenario variable, condition – a
majdani felhasználásra és
validáláshoz, például várakozás fizikai
utófeltételekre - correlation
szintű user műveletre, hálózatra
2. előfeltételek (resourceP ) hatása a
ua.
jelenlegi tennivalókra / – correlation Alternatív
G3.
U4.
műveletek/
megadott fő tennivalókhoz
ua. RF – az alap műveleteknél kell
Alternative
sorszámmal együtt a megnevezést
megvizsgálni, hogy van-e több
Flows:
softgoal és task - OR decomposition
lehetséges változat előírva
(AFsorzsám) Kivételek/
U6. GRL stratégia és kiértékelés G3. 1. ua. nem normal események
U4 ua. RF – az alap műveleteknél kell
Exceptions:
rátevődnek a normal eseményre -> task
megvizsgálni, hogy van-e kivételes
(EXsorszám)
alábontás - decomposition XOR ?
művelet
2. explicit – softgoal – or – hiba eset
U6. GRL stratégia és kiértékelés
sorszámmal, task és resource Bennfoglalás/
G3. actor megnevezéssel, goal,
U4.
Includes:
softgoal, task esetleg egy új actor-ként
stub, sub-map, component, condition
a megjelőlés
Comment – include körülményre
Gyakoriság/
G4. fő tennivalók softgoal -hoz believ
U5. comment, description, vagy
Frequency of
pl. server
condition
Use:
U6. GRL stratégia és kiértékelés
Minőségi
G3. fő tennivalók softgoal -hoz -
U4. Beépítve a folyamatba: Timer +
követelmények/
softgoal SecurityReq megnevezéssel
Time out path, component,
Special
softgoal-task-resource
Requirements
G4. fő tennivalók softgoal -hoz
component, path, responsibility,
(QASsorszám)
softgoal PerformanceReq
condition, variable, Timer
(QAPsorszám):
believ vagy task és resource
U6. GRL stratégia és kiértékelés
Feltételezések/
G1-G2 believ sorszámozva a
U1.-U3. comment, condition
Assumptions:
megnevezésben
Kiaknázás
G5. fő célhoz softgoal decomposition
U6.
lehetőségei/
OR, AND amelyekre hatással lesznek
Root UCM - comment, description
Exploitation
különféle egyebek (softgoal, resource,
possibilities
task) elemek
Verzió/ Issues:
comment, description
comment
Validálás
G6. GRL stratégia és kiértékelés
U6. stratégia és kiértékelés
U5. Külön modul Security: stub,
116
A 12. táblázatban megfeleltettük az URN modellezés (GRL, URN Link, UCM) elemeit az Use Case Description sablon elemeinek. A használati eset leírás elterjedten alkalmazott eszköz az üzleti megrendelők és fejlesztők között. Az URN modellezést használati eset leírás alapján olyan újratervezésekhez javasoljuk, amelyek egy jól behatárolt műveletre irányulnak és meglévő konkrét alkalmazásra vonatkozóan szükségesek a kiegészítések. A 12. táblázatba foglalt megfeleltetés alapján célmodellt építünk a G1. - G6. lépésekkel, az U1. – U6. lépésekkel előállítjuk a funkcionális modellt. Ezekben kódoljuk a megnevezéseket az űrlap mezők sorszámozott rövidítésével, és az üzleti stratégiák és folyamatok elemeinek összekapcsolására alkalmazzuk az URN Link elemet. A 7.4 Melléklet 17. táblázata egy példa. A használati eset leírás alapú URN modellezésre látható a 4.3.3.2 alpontban a mobil eszközök vállalati felhasználása, amelyek újratervezések az üzleti mobilitáshoz. 4.3.1.1 GRL modellezés menete üzleti stratégiák kialakításához GRL modellezéssel az üzleti elemzők által alkalmazott célfákat építhetjük stratégiák kiértékeléséhez, és kapcsolhatjuk az azt megvalósító üzleti folyamathoz az URN Link alkalmazásával. A 29. ábrán láthatjuk az elemi GRL jeleket: ovális jel a cél (goal), felhő jelöli a puha célt (soft goal). A különbség a teljesíthetőségben van: a célt erőforrásokkal és tevékenységekkel meg lehet valósítani, de a puha célt egészében nem. Ezért a részcélok és hatások mentén stratégiákkal vizsgáljuk a különböző teljesíthetőséget, amelyet döntés követ. A tevékenységek jele (task) a hatszög, az erőforrások jele a négyszög. Az erőforrások hatását függőségnek ábrázoljuk, ha nélkülözhetetlen a megvalósításhoz. Összetett üzleti cél esetén szerepekre osztjuk a modellt ellipszisben (actor), amely távoli hivatkozásban szerelhet. A kiértékelések a stratégiák szimulációival történnek színskála és a [-100,+100] egészek skáláján (lásd a 31., 32., ábrákat és a 7.4 Mellékletben az 50. ábrát ). Célszerű követni a célfa minőségtechnika szintezését és szerepekbe szervezni a részcélokat a cél, részcélok, tevékenységek, erőforrások hierarchiában. Az üzleti elemzők számára előnyös, hogy maguk kezeljék a stratégiák építését és kiértékelést az URN technológiákkal. 4.3.2 Üzleti folyamatok modellezésének keretrendszerbe foglalása Az üzleti folyamatok keretrendszerbe foglalásához a jelenlegi a folyamatok specifikálása módszertannal állítjuk elő az UCM folyamatspecifikációkat, majd igény szerint a GRL célfákat a kritikus területekre vagy a teljes üzletre együttműködve az üzleti szereplőkkel. Keretrendszert építünk az üzleti folyamatok kezeléséhez a folyamatmodellek karbantartásával és információbiztonság stratégiák integrálásával. 117
4.3.3 A keretrendszer implementálása és újrafelhasználása A keretrendszer implementálása során a szakterület szakértői/modellfejlesztők létrehozzák a szakterületre jellemző célok és forgatókönyvek modellgyűjteményét, mint kiinduló generikus modelleket, valamint specifikus modelleket az alternatívákra a minta alapú változáskezeléshez. A felhasználás során egy szakterületre implementált keretrendszerrel a kezdő döntéshozók is kezelhetik a változásokat a szakértők által a szakterületre kialakított üzleti modellek újrafelhasználásával. A modellvezérelt technológiák felhasználásával elérhető a szakértők döntése a változáskezeléshez. A BUSITEV keretrendszer implementálásához a következő generikus modelleket valósítottuk meg: -
támogatás az üzleti elemzéshez a Guide of the Business Analysis Body of Knowledge (BABOK Guide) [BABOK12] szabvány ajánlásainak üzleti elemzéséhez generikus modelljeivel. Az üzleti elemzéshez a szabvány osztályba sorolja a követelmény sémákat, szerepeket és kapcsolatokat, meghatározza a kontrollpontokat és módszereket javasol. Részletes leírást ad a fejlesztés menetére szöveg, táblázat és rendszerábrázolás formában. Összeilleszti a követelmények fejlesztését az üzleti elemzéssel. A szabvány ajánlásait fő szakaszokra tagolva vizuális dokumentációt adtunk újrafelhasználható generikus modellgyűjteményben a változáskezelés folyamatszervezéséhez [Han11, Ger11].
-
támogatás az információbiztonság integrált fejlesztéséhez újrafelhasználható generikus és specifikus modellekkel. Az ISO/IEC 27001 és 27002 [ISO27000] szabvány ajánlásait képeztük le cél-fa modellekbe a szabvány fejezeteire és alfejezeteire a célok és biztonságkövetelmények ajánlásaival. A modellek szerkezetében a szabvány szerkezetét követtük, ui. a biztonságauditok az egyes fejezetekre is megtörténhetnek a gyakorlatban. A modellek vizuális dokumentációt nyújtanak a szabvány ajánlásairól, továbbá generikus biztonságcélokat és üzleti nézetet a védelmi intézkedések összetételéről. A modellek adaptálása stratégiai döntésként kerül előtérbe a változáskezelés során (4.3.3.1).
-
támogatás a mobil eszközök üzleti folyamatba integrálásához fejlesztők részére generikus modellekkel a mobil alkalmazásfejlesztés célú újratervezéshez (4.3.3.2).
118
4.3.3.1 Generikus modellek az ISO/IEC 27001 és 27002 információbiztonság szabvány alapú üzleti folyamatba integrált biztonságtervezéshez Az ISO/IEC 27001 és 27002 szabványok üzleti nézetet nyújtanak a biztonsági becslések struktúráihoz, szolgáltatják a modellezéshez a generikus biztonságkövetelmény listát az információs rendszer biztonságáról, modellt kínálnak, az un. információbiztonság kezelő részrendszer felállításához és fenntartásához, valamint az információbiztonság minősítésének harmonizálásához más szabványokkal, mint pl. az ISO 9001 szabvánnyal [ISO27000]. Létrehoztuk az ISO/IEC 17799/27001 és 27002 információbiztonsági szabvány generikus mintagyűjteményeit vállalati audit célra, továbbá specifikus mintagyűjteményeket a B2B és B2C fejlesztések ügyvitelszervezésének integrálására és minőségbiztosítására. Az implementált SMIWEP keretrendszer magját képezik az alábbi könyvtárazott újrafelhasználható modellgyűjtemények [Med09, Med09b]:
a generikus és specifikus modellek, amelyek űrlapkollekciók a biztonsági célok csoportjai szerint az ISO/IEC 27001 és 27002 szabványok fejezeteire és alfejezeteire újrafelhasználható formában
tipológia táblák a szabvány ajánlásaira az emberi, dologi, szoftveres, hardveres besorolással, a költségek és kockázatok stratégiáinak kialakítására a minőségügyi besorolásokhoz
-
e-kereskedelem háromlépcsős evolúciós modellje a biztonsági modellek technológiai és ügyfél-központú
nézetében
az
e-szolgáltatások
rendszerszintű
stratégiáinak
a
tervezéséhez (katalógus, megrendelés követés ügyfélrálátással és a nélkül, megrendelés és fizetés elektronikusan) -
újrafelhasználható specifikus modelleket hoztunk létre három biztonság fokozatban az ISO/IEC 27002 szabvány ajánlásaira fejezetenként kockázati tényezőkre lebontva
modellek a szabvány ajánlásaira a hozzáférés biztonság és a fizikai és szervezeti biztonság közötti hatáselemzéshez. Alkalmazásához specifikus modelleket adtuk meg a B2B információbiztonság intézkedésekhez, mivel az egyik biztonsági intézkedés teljesülése emeli a kölcsönhatásban levő csoport ajánlásainak teljesülését
támogatás B2B biztonsági stratégiák fejlesztéséhez az információbiztonság szabvány generikus modelljeivel és biztonságfokozatok szimulációs modelljeivel
119
támogatás generikus modellekkel e-kereskedelem célú változáskezeléshez: az integrált információbiztonság eseteivel, back-office és front-office átszervezéssel, hálózat és adatbázis méretezés tervezéssel.
A
SMIWEP
modellgyűjtemény
egyben
vizuális
dokumentációt
képez
az
információbiztonság szabványokra. Mintát képez a szabványokba foglalt generikus szakterületi fogalmak és összefüggések modellezésére és keretrendszer gyűjteménybe foglalására MDE folyamatokhoz. A keretrendszerben képezett generikus és specifikus modellek újrafelhasználhatóak stratégiatervezéshez. A modellek támogatják a biztonságtervezést a biztonsági ajánlások és becslések osztályozásával, valamint az átjárhatósági kapcsolatok meghatározásával a biztonságcélok szerint és azok beépítésével az üzleti folyamatokba. Alkalmazásukhoz az iterációkkal a 30. ábrán látható generikus keretrendszer modellezés lépéseit érdemes követni. A 31. ábra a GRL generikus modell részletét mutatja a szabvány fizikai biztonság fejezetének ajánlásairól. A modell egy döntésfát képez, amelyben a kiértékelés levélszintről felfele történik, a stratégia szerinti részcélok hatásainak beállítása után. A 32. ábra illusztrálja a kiértékelést. A hozzájárulások mértéke a [-100, +100] skálán adható meg. A kiértékelés százalékos eredményt képez az egyes felsőbb szintű részcélok és kiinduló cél teljesüléséről a beépített tudásbázis alapján. A célorientált GRL döntésfa modell újrafelhasználással bemenetet képez a minőségi követelmények
integrálásához
UCM
forgatókönyv
modellekbe
az
un.
URN-Link
alkalmazásával, amely összekapcsolja a GRL modell egy elemét az UCM modell egy elemével. Erre illusztrációs példát mutat a 7.4 Mellékletben a 46 ábra, ahol a biztonság minőségi követelményei vannak integrálva egy generikus e-kereskedelem forgatókönyv specifikáció tevékenységeiként megadva. Az integráció manuális folyamat. A jUCMNav fejlesztőben kijelölve a mutató visszavezet a döntésfa megfelelő csomópontjára. Kezelése és módosítása gyors, érthető és látványos a megrendelők számára. A hozzárendeléseket sárga háromszög mutatja (a projekt idején a jUCMNav 4.x verzióig sárga háromszög GRL-UCM irányban, a 2012-es 5.4 verziótól szürke háromszög GRL-UCM és UCM-GRL irányban is, lásd a 4.3.3.2 alpontban). Célszerűen a megrendelők és üzleti elemzők döntéseit tartalmazó kiértékelt GRL döntésfa kerül integrálásra az UCM folyamatmodellekbe. A 7.4 Mellékletben 47. ábrán illusztrációs céllal látható a szerkezete egy e-kereskedelem célú üzleti folyamatmodellnek az információbiztonság stratégiáinak tervezésével. Balról a minőségi követelmények integrálása előtt, jobbról a minőségi követelmények integrálása után. Jól kivehető a madártávlatú ábrán is, milyen nagy számban keletkeztek új szervezeti és 120
szervezési elemek (szereplők, osztályok, csoportok, erőforrások) és az ezeket átszelő folyamatokon munkaelemek átjárható modellekben újabb változáskezelésekhez.
31. ábra Példa biztonságmodellezésre GRL célorientált döntésfában (lásd a 4.3.2.1 alpontban)
32. ábra Példa biztonság stratégia kiértékelésre GRL célorientált döntésfában (lásd a 4.3.2.1 pontban)
121
4.3.3.2 Generikus modellek a mobil eszközök üzleti folyamatba integrálásához A mobil eszközök üzleti folyamatba integrálásának eseteiben aktor a felhasználó és kommunikációs pontok a felhasználói felület, mobil eszköz, kliens oldali alkalmazás, szerveroldali alkalmazás. Az Use Case Description sablonnak (7.4 Melléklet 17. táblázat) megfelelő GRL célmodell és UCM forgatókönyvek egy-egy illusztrációja látható a 7.4 Mellékletben a 49. – 55. ábrákon. A követelménymodell újraszervezésével architektúra modellt (7.4 Melléklet 51. ábra) és teszteset modelleket (33. és 34. ábra) fejlesztünk.
33. ábra GRL célfa részlet - Teszteset követelménytervből – szerver hiba UCM forgatókönyve (piros vonal)
34. ábra MSC/UML SD teszteset modell a teszteset forgatókönyvből (33. ábra) automatikus transzformációval
122
4.3.4 Az URN alapú újratervezés ipari validálásának esetei Az UML és az URN együttes használata a szakterület-specifikus nyelvekkel ipari alkalmazásban került validálásra a Messer Hungarogaz Kft. dunaföldvári egységének értékesítési részlegén a szállítmányozás kiszervezése után keletkezett problémák megoldására az értékesítési és szállítmányozási folyamat változáskezeléséhez. Az URN alapú újratervezés során az UML implementációs modellből SAP-ABAP4 komponensadaptálást végeztünk [Men05, Mol05].
A Sonepar Magyarország Kft. dunaföldvári központjában és veszprémi telephelyén elektronikus kereskedelem célú szoftvermodernizációhoz alkalmaztuk az URN alapú újratervezést a SMIWEP (Sonepar és Műszaki Informatika WEbshoP) keretrendszer implementálásával. Egyetem-ipar együttműködés keretében a SMIWEP projekt biztosította a keretet az empirikus validáláshoz egyetemi hallgatók bevonásával [Med11c]. URN és a verziókezelő technológiákkal az informatikai egység munkatársai és az üzleti elemzők a felelősökkel megvalósították az elektronikus kereskedelem monitorozását osztott modellhozzáférésű SVN/CVS verziókezelő támogatással [Med11c]. Témavezetésemmel a hallgatók több fős csoportja végezte az újratervezést és technológia migrálást, ebben beszámolók
születtek,
több
diploma
és
szakdolgozat
került
védésre:
webshop
követelményfejlesztés, információbiztonság, IT változáskezelés tervezése és migrálása [Ház10, Koc08, Lan11, Mac11, NagG10, NagN09, NagR10, NagT10, Pét09].
A Le Belier Magyarország Formaöntőde Zrt. ajkai termelésirányítási rendszerében URN újratervezést alkalmaztunk SAP PM bevezetéséhez éles üzemelés mellett a szükséges oktatással is [Ová07], amelyet a multinacionális cég kiterjesztett minden telephelyére. A PannonTej Zrt. veszprémi központjában és további két telephelyén az üzleti folyamatok modellezésére a 4.2 fejezetben ismertetett módszertan került bevezetésre. Összesen 12 részlegben 37 folyamatgazda és részlegfelelős aktív közreműködésével, 332 folyamat modellezése és optimalizálása történt meg. Az URN technológiákkal a termelési részlegek számára automatikus modelltranszformációval nyertük ki az interakció diagramokat, amelyek az üzleti folyamat szereplőinek munkaköri leírásaként szolgáltak a minőségügyi rendszerdokumentációban [Med10c]. Az Informatix Zrt. mobilalkalmazás- és eszközfejlesztő informatikai cég részére döntéstámogatáshoz a MobiAccess eszközfejlesztés verziómódosítására URN alapú követelménygyűjtést és szimulációkat fejlesztettünk a paraméterezésről, hatásairól és a megvalósítás ütemezéséről [Koc10].
123
4.4
Összefoglalás a 3. Tézis tárgyalásáról Az üzleti területen a technológiai sor kialakításánál figyelembe kell venni a
technológiáktól függő követelmények teljesítését. Ennek gyűjtőszava a vállalati technológiák kifejezés, amely a referenciamodellektől a konkrét implementációs platformokig terjed. Munkánkhoz alkalmaztuk a távközlés területén kifejlesztett formális nyelveket az üzleti területen az absztrakciós szintek skálázásához. Az ITU-T URN technológiáival a követelménymodellből automatikus transzformációkkal állíthatók elő az interakció-, architektúra-, teszteset modellek. Kézi transzformációkkal állíthatók elő az infrastruktúra- és bevezetés
modellek,
továbbá
manuális/automatikus
módon
egyes
implementációs
modelltranszformációk szakterületi nyelvekre. A szabványtámogató fejlesztőeszközökkel az automatikus XML modelltranszformációk vezetnek az UML vagy DSML technológiákhoz. A folyamatspecifikációk nemcsak hidat képeznek a számítás független üzleti modell (probléma) és a platform független modell (megoldás) között, hanem általuk skálázható maga a
szoftverfolyamat
a
hozzájuk
rendelt
technológiákkal
[Med07,
Med08b].
A
folyamatspecifikációs módszertan kialakításához vizsgáltuk a termékek és az átjárhatóság vonatkozásában a KobrA módszertan Kontextus megvalósítása fejlesztési szakaszt, és létrehoztuk a folyamatspecifikációs űrlapot. A folyamatspecifikációs űrlapon elő áll a folyamat modellje természetes nyelven. A folyamatspecifikációs űrlap adatkategóriái között generikus kapcsolat van a szervezési, szervezeti és viselkedési tulajdonságok alapján, amelyekkel történik a specifikácók szervezése és kivitelezése. A folyamatspecifikációs űrlap mezőinek részhalmazai összefüggéseket adnak az elemzéshez és mentális koordinációt a folyamatgazda számára, hogy átlássa és megtalálja a jelenlegi helyzet részleteit. Ezek a tulajdonságok kapcsolataikkal értelmezhetők és megfeleltethetők a specifikációs nyelv szintaxisainak és szemantikáinak. Együttesen emberi értelmezésben a részletezettségük miatt nem adnak folyamatképet, azonban segítik a specifikátort az egyes objektumok és események tulajdonságainak és kapcsolatainak modellezésében az URN technológiákkal. A folyamatspecifikációs űrlap alkalmazása csökkenti a bonyolultságot és növeli a követelménygyűjtés jóságát. A folyamatelem kategóriák becslésében listaszerűen lehet haladni
a
folyamatjellemzők
felismerésben,
és
kontrollmező
hatására
visszatérni
önellenőrzésre. A minőség gazdaságossága a megelőzést helyezi előtérbe, az ellenőrzés eredményesebb a tesztelésnél és hatékonyabb is. Minél hosszabban van a hiba a termékben, annál nehezebb és költségesebb kijavítani. Módszertanunk lehetőséget nyújt, hogy az üzleti 124
szereplők legyenek az üzleti folyamatok modellezéséhez a követelmények meghatározói és validálói. Az URN technológiákkal módszertant adtunk az átjárható üzleti folyamat modellek és használati modellek előállítására a folyamatspecifikációs űrlapok alapján, valamint viselkedés modellek előállítására automatizált modelltranszformációkkal. A módszertant bevezettük ipari létesítményben üzleti folyamatok optimalizálására. A módszer alkalmazásához a minőség biztosítása érdekében szükséges az oktatás. A folyamatgazdákat mentális alkatuktól függően meg lehet tanítani esettanulmány alapján vagy közvetlen betanítással a saját folyamatuk modellezésével. A gyakorlat azt mutatja, hogy az esettanulmány alapú csoportos oktatás után egyénre szabott betanítással érdemes ellenőrizni a folyamatgazdák kiképzésének eredményességét, hogy javítani lehessen a félreértéseket és rosszul rögzült tudást. Ennek jele megmutatkozik a folyamatelemek közötti korrekciós mezők hiányos kitöltésénél és a folyamatgazdák szociális hálójában feltett segítségkérő kérdésekben. Az
önellenőrzési
útmutató
kontroll
elemeket
nyújt
a
rejtett
holtpontok
és
az
ellentmondásosság kiszűréséhez, a helyes besoroláshoz, a betanítása szükséges. A ProjektProcesz módszertannal a Pannontej Zrt. ipari alkalmazásában 12 területen 332 folyamat került modellezésre természetes nyelven a folyamatspecifikációs űrlap szerint, és ezek alapján UCM specifikációkban modellezve és validálva URN technológiákkal. Az inspekció lebonyolításához két inspekciós értekezletre volt szükség, az indító/betanító értekezletre, valamint a hibadetektáló/hibaérvényességet eldöntő értekezletre. A hibák kijavítása
kép
dokumentumok
cseréjével
elektronikus
kapcsolatban
történt
a
folyamatspecifikátorok felelőse és a folyamatgazdák kommunikációs képviselője között. A módszertan eredményesnek bizonyult és alkalmazásban van három nagyvállalat összesen öt telephelyein. Az ipari alkalmazás modelltermékei jelszóval ellenőrzött hozzáféréssel kérésre megtekinthetők (
[email protected]). A tapasztalatok alapján generikus keretrendszert hoztunk létre az üzleti szakértők részére az üzleti stratégiák és az üzleti folyamatok átjárható cél-orientált változáskezeléséhez modellvezérelt elvekre és a 3.1 tézispontban javasolt technológiákra építve [Med12]. Keretrendszerbe foglalt módszertant hoztunk létre a változáskezelés stratégiáinak fejlesztéséhez, és a változások funkcionális modellbe integrálásához a vállalati szakértők és döntéshozók által. Vizsgálni fogjuk a módszer meta modell alapokra helyezését Amyot és Benham [Amy11b, Ben12] szerint.
125
5
ÖSSZEFOGLALÁS Az értekezés a modellvezérelt szoftverfejlesztés gyakorlatához nyújt ismereteket,
módszereket és technikákat. A dolgozat első fejezetében ismertettük az MDA és MDE elveket, megadtuk a modellvezérelt fejlesztés folyamatának dimenzióit, és ismertettük a munkánkhoz felhasznált technológiákat. Az alábbiakban összefoglaljuk a dolgozat 2.-4. sorszámú fejezeteiben tárgyalt téziseket egyenként, és megadjuk a szakirodalomból az eredményeinkre vonatkozó ismert kutatásokat, tárgyaljuk a hasonlóságokat és különbségeket, valamint a jövőbeni kutatásunk lehetőségeit a témában. 1. Tézis: Technológiai sor modellvezérelt fejlesztéshez A modellvezérelt folyamatban nélkülözhetetlen a szakterület-specifikus rendszerfejlesztő nyelvek megléte. Szükség van a modellvezérelt technológiákba integrált verifikáló eszközökre és munkakörnyezetekre, amelyekkel a fejlesztés korai szakaszában fontos szerep hárul a specifikációs nyelvekre és eszközökre. Ez irányú vizsgálatunk célja az, hogy a tervezéstől a futtatható kódig adjunk a felhasználónak javaslatot a modellvezérelt szoftverfejlesztés gyakorlatához. Az 1. Tézis 1.1 alpontjában egy sémát állítottunk fel technológiai sorok elemeire modellvezérelt fejlesztéshez. A technológiai sor sémában a változó elemek: a szakterületi modellező nyelvek, az egységesített modellező nyelv, programozási nyelvek, szoftver komponensek, valamint a szabványok. A technológiai sor szervezésében a formális módszerek és a nyelvi technológiák szabványait helyeztük előtérbe [Med05, Med08b, Lei07]. Megadtuk az elvi technológiai sor séma példányosítását az ITU-T rendszerfejlesztő nyelvekkel (International Telecommunication Union-Telecommunication Sector (ITU-T) http://www.itu.int/rec/T-REC-Z/en) [ITU12], amelyek szabványosítása harmonizált az OMG specifikációkkal, elterjedtek az iparban, a gyógyeszközfejlesztésben és a tudomány területein. Folyamgráfban ábrázoltuk az ITU-T, Unified Modelling Languages (UML), DomainSpecific Modelling Languages (DSML) nyelvek helyét és kapcsolatát a fejlesztési folyamatban, amelyhez a koncepcionális tervezést javasoljuk az User Requirements Notation (URN) [ITU12] alapú követelménymodellezéssel. Az 1. Tézis 1.2 alpontjában javasoljuk beillesztésre az 1.1 tézispontban megadott technológiai sorokba az IFx 2.0 eszköztárat, valamint modellalapú teszteléshez a TTCN-3 126
automatizált tesztelési eszközt és az UML-TP elvi eszköztárat [IFx12, Boz4, ITU12, OMG12, Kup01].
A cél az, hogy az elemzés és a részletes tervezés idején kombinálhassuk a statikus
elemzőket és az automatikus modellellenőrzőket a modellek formális verifikálására. Ehhez oktatási környezetben folytattunk kísérletet a verifikáló eszközöknek a szoftverfolyamatba integrálásával [Tót07]. Vizsgáltuk az önálló és a kereskedelmi szoftverekbe beépített automatikus modellellenőrzők alkalmazását elemzésekhez és modelltranszformációkhoz [Bor10], valamint utóbbiak kombinálását az IFx eszköztárral [Orb08]. Kidolgoztuk az IFx 2.0 Toolbox modellezésbe integrálásának folyamatát az IFx platformszolgáltatások eléréséhez a sokfajta verifikációs eszköz és a C++ nyelvű komponensek beemelésére a verifikálás alatti modellbe. Megfogalmaztuk a verifikátor mérnök munkakört, mint szolgáltatást [Med10b], amely tevékenységeire esettanulmányt adtunk a PIM modellek több rétegben történő transzformációjához egyidejű verifikálással [Med11b], amelyeket általánosítottunk a verifikáló eszköztárak kiválasztásához és a verifikátor mérnök munkafolyamat tevékenységeinek szervezéséhez [Med12b]. Az elért eredmények viszonyításához a termékvonali fejlesztéseket hozzuk fel, amelyeket konkrét szakterületi termékfejlesztésekhez több tízéves élettartamra fejlesztenek jól meghatározott platform modellekre, és kutatják a variációs lehetőségek automatizálását az MDE technológiák fejlesztésével [Tru08, Zsc09, Obe09, Obe10]. A mi nézőpontunk kiegészíti a termékvonali kutatásokat az MDE technológiák felhasználásával. Kellően absztrakt technológiákat javasolunk a rendszer aspektusok változásainak kezeléséhez, módszereket az MDE/MDA elvekkel és eszközökkel, a technológiákban rejlő módszertani lehetőségek megfogalmazásával [Med08b, Med12]. Adamis és társai [Ada05] tárgyalják az ITU-T rendszerfejlesztő nyelvek alkalmazását protokollok fejlesztésére a távközlési területen, de nem adnak módszerleírást és nem alkalmazzák ipari és üzleti területen. Többen foglalkoznak az URN modellezésből eredő teszteset generálás lehetőségével [Jas10, Amy05], [URN12] amelyek a mintaalkotásra, az automatizálásra, és a tesztelés aspektusaira vonatkoznak. Mi a tesztmodell létrehozását folyamatba integráljuk és lépéssorozattal munkaelemeket határozunk meg a feladat erőforrásaira és feltételeire, valamint dokumentálására. Ezért, a tesztesetek modellezését az üzleti folyamat modellezéséhez társítjuk, inspekciós technikákat alkalmazunk a folyamatmodellek jóságának eldöntéséhez, technológiákat és transzformációs lépéseket határozunk meg a követelményekből előállított tesztmodell létrehozására és dokumentálására (lásd a 3. Tézis, 4.2 fejezetben a 3.2 tézispont kifejtését). Eltérően a termékvonali kutatásoktól, fontos szempont a kutatásunkban, hogy nem az automatizáló technológiákat fejlesztjük, hanem eljárásrendet és eszköztárat határozunk meg 127
az elvi összefüggések és szakterületi jellemzők birtokában a bevált technológiák felhasználására, amely lépéssorozat idővel automatizálható. Ilyen természetű technológia felhasználással építették [Boz4] az IFx verifikációs platformot ismert verifikációs technológiák felhasználásához, amely újrafelhasználásra került beágyazott rendszerek eszközfejlesztőibe, a DREAM [DRE12] és AMPLE [AML12] technológiákba. Jövőbeni kutatásunkat ebbe az irányba tervezzük az IFx platformot felhasználó modellvezérelt technológiák alkalmazásával. 2. Tézis: Szoftvertervezési minták alkalmazása MDE folyamatokban Ebben a tézispontban azt javasoltuk és adtunk hozzá eljárást és esettanulmányt, hogy a szoftvertervezési
minták
alkalmazásával
hozzunk
létre
keretrendszerbe
foglalt
mintagyűjteményt, amely modelltermékként alkalmazható újrafelhasználással az MDE folyamat jobbítására és gyorsítására az absztrakciós szinteken belül és a szintek között. Mindezt az architektúra mintanyelvekkel valósítjuk meg modellvezérelt fejlesztésben, amelyre jellemző, hogy az architektúra döntések alapját az ismert szakterületi platform modellek képezik és az architektúrák szempontjából jelentős követelmények [OMG03]. A modellalkotásnak ezt a vonatkozását az architektúra döntésekre nézve tárgyaltuk a [Med11b] közleményünkben. Mind az általános, mind a szakterületi fejlesztésekhez az elosztott rendszerek architektúra mintanyelveit alkalmaztuk, amelyek a Pattern-Oriented Software Architecture for Concurrent and Networked Objects [Sch00, Bus96], röviden POSA2 néven ismertek. Alkalmaztuk a GOF Design Patterns néven ismert programtervezési mintákat [Gam96, Hil12] a POSA2 architektúra minták viselkedésének modellezéséhez. Szakterületi szoftvertervezési mintákat alkalmaztunk az üzenetkezelés szolgáltatások kontrolljához, amelyek az SDL Pattern Pool minták [Got05]. A 2.1 Tézispont illetve 2.2 Tézispont kifejtésével módszert és esettanulmányt adtunk meg a POSA2 architektúra minták modellgyűjteményének a létrehozására a GOF programtervezési minták
összeszövésével
és
újrafelhasználására
modellvezérelt
fejlesztésben
UML
fejlesztésekhez (2.1 tézispont) [Med10, Med07b], illetve SDL fejlesztésekhez is (2.2 tézispont) [Med08]. Az újrafelhasználás esettanulmányai (az értekezés 3.2.2, 3.2.3, 3.3.5 fejezetei) mutatják a modelltermékek átjárhatóságát a 1. Tézis technológiái közötti modelltranszformációkkal. A 2.3 tézispont kidolgozásával megmutattuk, hogy szakterületi mintanyelvet fejleszthetünk gyorsfejlesztésekhez a POSA2 architektúra minták és GOF programtervezési minták modellezésével szakterületi nyelveken. A kapott mintanyelvet a részletes tervezésben bővítjük ki a szakterületi minták alkalmazásával újabb absztrakciós szintek bevezetésére minőségi 128
követelmények modellezéséhez és a modelltermékek változtathatósághoz, ezzel a tesztelhetőség és átjárhatóság növeléséhez. Az alkalmazott technológiák az SDL, MSC, POSA2, GOF és SDL Pattern Pool, amelyekkel létrehoztuk az SDL Macro-Pattern mintanyelvet [Med08, Med06]. A modulok és komponensek meghatározása összetett feladat a szoftverfejlesztésben, amely tanulására a minták jó alapot szolgáltatnak a szakértők által a jó gyakorlatokból szintetizált objektum meghatározásokkal ennek szintézisét láthatjuk Meyernél [Mey06]. A létrehozott módszertannal a vizsgált rendszer funkcióit direkt leképezzük az SDL, ill. UML modellekre, a modellgyűjtemény által. A mintagyűjteményben a keretrendszerbe foglalt összeszőtt minták átjárható absztrakciós szinteket képviselnek egy MDE folyamatra nézve, általuk az elemzés leegyszerűsödik a fogalmi szintű megfeleltetésekre és a generikus modellek specializációjára az alrendszerek funkciói mentén. A POSA architektúra minták sajátossága, hogy a szakterületi rendszer szolgáltatásait modulszerkezetben adja meg és teljesen lefedi a mintákkal azt. A POSA2 mintákkal a módszer felhasználása bármely szakterületen lehetséges a minták kliens-szerver kommunikációs modelljének a specializációjával a szakterület platformosztályának komponensmodelljét követve. A mintagyűjtemény modelljeivel a kezdő fejlesztők is tudnak mintaalkalmazást végezni a mintákba és a modellekbe beépített szakértői tudás alapján. A szakirodalomban felelhető munkák többségében a minták ismertetésével, jobbításával, és főleg a létrehozásukról értekeznek. A mintákat felhasználását [Eric00, Fra04, Pra00] implementálásra javasolják. Modellezésükről a [Tom12, Sun00, Jéz03] munkák értekeznek. A mi munkánkhoz
hasonló
mintaalkalmazás
modellezési
nyelven
[Tom12]
Tombemalle
közleményében vizsgálható, aki egy generikus nyelvet hozott létre a minták modellezésére és a modellek, mint megoldások újrafelhasználására, GOF mintákra. Nem tárgyalja és nem helyezi MDE folyamat kontextusba a létrehozást és újrafelhasználást, és nem tárgyalja az architektúra jelentőségét. Mindamellett hasonló elvű előrelépés a mintaalkalmazásban a mi eredményeinkhez hasonlóan újrafelhasználható megoldást kínál a minta megfeleltetéséhez, ami sokkal hatékonyabb és kezdők által is gyakorolható. Az SDL Pattern létrehozói és alkalmazói egy iskolát képeznek a beágyazott és a távközlési rendszerek minta alapú fejlesztésében SDL nyelven. Nem tárgyalják a mintaalkalmazást modellvezérelt folyamatban és fejlesztési mechanizmusokkal sem, a minták szintézise, újrafelhasználása és ismertetése jelenik meg a műhelyükben. Mások, mint Jézéquel, LeGuennec, Sunye [Sun01] a GOF tervezési minták meta modellezését kutatják modellezési köztesréteg technológiák építéséhez, mintafelismeréshez kódvisszafejtésben és egyéb automatizáló fejlesztésekhez. A kutatás 129
lehetséges további iránya a mintagyűjtemény bővítése a POSA architektúra minták további architektúra modelljeinek modellezésével (POSA1-5 – [POS12]). Másik hasznos irány a modellgyűjteményben az absztrakciós szintek növelése az URN technológiákkal a minták modellezésében [Mus02, Mus07, Buh96], valamint a POSA2 mintagyűjtemény alkalmazása a szolgáltatások fejlesztésében. 3. Tézis: Üzleti folyamatok változáskezelése modellvezérelt fejlesztésben A modellvezérelt technológiák előnyösek az üzleti területen, ahol jellemző, hogy a szervezeti
struktúra
állandó
fejlődésben
van
az
üzleti
stratégia
mentén,
és
a
szoftverrendszerek számos érdekelt célcsoport napi szükségleteit elégítik ki. Mind az informatikai rendszerek modernizációja, mind az üzleti változások kezelése során a szoftverfejlesztési projektek leginkább a meglévő szoftverrendszert alakítják át, és a legritkább esetben vonják vissza teljesen azt, mivel a változtatás alatti rendszer mindig nagyon
kiterjedt
[Min98].
Ezekhez
a
rendszerszempontokhoz
a
modellvezérelt
követelményfejlesztés [Buh98, Liu01, Wei05, Lam09, Amy11, Mus12] eszköztárát alkalmaztuk a 3. Tézis kidolgozásában. A 3.1 tézispontban sémát adtunk technológiai sor szervezéséhez a szolgáltatás fókuszú ITU-T és más MDE technológiákkal az üzleti területre [Med07, Med8b]. Az üzleti stratégiák és alkalmazások újratervezéséhez szükséges a jelenlegi és jövőbeni helyzet specifikálása. A 3.2 tézispontban egy generikus módszertant adtunk meg az üzleti folyamatok kooperatív feltárásához és szabályozásához. Az MDE és URN [ ITU12] technológiákra alapozva a folyamatgazdák felbecsülik és validálják saját folyamataikat, majd a fejlesztők specifikálják azokat, és a területfelelős üzleti elemzők és folyamatgazdák inspekció keretében validálják az általuk megadott követelményeket. A módszertanban megadtunk űrlapokat folyamatfeltáráshoz, inspekció lebonyolításához és hibabejelentéshez. Továbbá
esettanulmányokat,
feltárásához,
ellenőrzéséhez,
oktatási
segédleteket,
specifikálásához
és
módszerleírásokat
folyamatok
verifikálásához,
inspekciós
stratégiatervezéshez, modelltermékek dokumentálásához. A módszer kifejlesztését több vállalat konkrét szükségletére adtuk meg [Óvá07, Med10c, Med11d]. A vállalati rendszerek sajátosan kritikus rendszerek: az emberi tényezőktől és az irányítási módszerektől függenek. A 3.3 tézispontban URN alapú módszertant adtunk meg a cél- és forgatókönyv modellek összehangolt fejlesztésével üzleti folyamatok és stratégiák fejlesztésére és generikus keretrendszerbe foglalásukra. A felhasználásuk a célmodellekből kiindulva specializációs iterációkkal történik. [Med12, Med12c]. A keretrendszer részeként generikus modelleket dolgoztunk ki az információbiztonság szabvány [ISO12] és a 130
mobilinformatikai alkalmazások vállalati technológiákba integrálására, specializáltuk elektronikus kereskedelemre konkrét vállalati újratervezésben [Med09, Med11, Med11c]. Mintát dolgoztunk ki a mobilinformatikai alkalmazások vállalati integrálásához és esettanulmányt az URN és UML technológiák alkalmazására a használati esetek leírásából kiindulva [Med12c]. Az URN és AoURN követelménytervezés előnyeit egyre többen ismerik fel és kutatják alkalmazási területeit, amelyekről Amyot átfogó ismertetést nyújt az [Amy11] közleményben. A közlemények megtalálhatók az URN virtuális könyvtárban [URN12]. Shamsaei, Saleed A. Behnam és Mussbacher [Sha12, Mus12, Beh12, Zha11] vizsgálják a stratégiák és funkcionális megfelelőik természetét a meta modellezéshez és eszközfejlesztéshez az iparral közös kutatásban. Ipari bevezetésszintű alkalmazásról nem számolnak be, a munkájuk kiterjedt az üzleti folyamatok megfelelőségének vizsgálatára és ennek automatizálására. Jövőbeni kutatásunkat az URN módszertan kidolgozására összpontosítjuk, az ITU-T szervezet által közzétett felhívásra, amely szorgalmazza az ITU-T System Design Language nyelvek alkalmazásának gyakorlati jellegű módszertanát. Megvizsgáljuk a meta modellezés előnyeit az URN technológiákkal, az OCL szabályok kombinálását a temporális logikákkal, valamint az AoURN és az üzleti minták alkalmazását, együttműködésben a CSERG URN kutatóival.
131
6
IRODALOMJEGYZÉK
Aal03
Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Mathias Weske: Business Process Management: A Survey. In: Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Mathias Weske (Eds.): International Conference Business Process Management, BPM 2003, Eindhoven, The Netherlands, June 26-27, 2003, Proceedings. Springer, 1-12, 2003. Abi09 Muhammad R. Abid, Daniel Amyot, Stéphane S. Somé, Gunter Mussbacher: A UML Profile for GoalOriented Modeling, in SDL 2009: Design for Motes and Mobiles, 14th Int. SDL Forum, LNCS 5719, Springer, p.133–148, 2009. Ach09 Mathieu Acher, Philippe Collet, Philippe Lahire, Robert B. France: Composing Feature Models. In: Mark van den Brand, Dragan Gasevic, Jeff Gray (Eds.): Software Language Engineering, Second International Conference (SLE 2009), Denver, CO, USA, October 5-6, 2009, Revised Selected Papers. LNCS 5969, Springer, p.62-81, 2010. Ada05 Gusztáv Adamis, Róbert Horváth, Zoltán Pap, Katalin Tarnay, Standardized languages for telecommunication systems. Computer Standards & Interfaces, 27(3), Elsevier, p.191–205, 2005. Agr06 Aditya Agrawal, Gabor Karsai, Sandeep Neema, Feng Shi, Attila Vizhanyo: The design of a language for model transformations. Software and Systems Modeling 5(3):261-288, 2006. Aka08 Jacky Akoka, Isabelle Comyn-Wattiau, Sisad S. Cherfi: Quality of Conceptual Schemas An Experimental Comparison. In RCIS’08 IEEE Int. Conf. on Research Challenges in Information Science, p. 197–208, IEEE Press, New York. 2008. Alf09 Mauricio Alférez, João Pedro Santos, Ana Moreira, Alessandro Garcia, Uirá Kulesza, João Araújo, Vasco Amaral: Multi-view Composition Language for Software Product Line Requirements. In: Mark van den Brand, Dragan Gasevic, Jeff Gray (Eds.): Software Language Engineering, Second International Conference (SLE 2009), Denver, CO, USA, October 5-6, 2009, Revised Selected Papers. LNCS 5969, Springer, p.103-122, 2010. Ama10 Vasco Amaral, Cécile Hardebolle, Hans Vangheluwe, László Lengyel, Peter Bunus: Summary of the Workshop on Multi-Paradigm Modelling: Concepts and Tools. In: Proceedings ECMFA 2010 Thomas Kühne, Bran Selic, Marie-Pierre Gervais, François Terrier (Eds.): 6th European Conference on Modelling Foundations and Applications, Paris, France, June 15-18, 2010, LNCS 6138, Springer, p.8388, 2010. AML12 AGEDIS Modeling Language Specification. http://www.agedis.de/, 2012. Amm08 Boulbaba Ben. Ammar, Mohamed Tahar Bhiri, Jeanine Souquières: Incremental development of UML specifications using operation refinements. Journal of Innovations in Systems and Software Engineering, 4(3):259-266, 2008. AMP12 AMPLE - Aspect-Oriented, Model-Driven Product Line Engineering, http://www.ample-project.net/, 2012. Amy02 Daniel Amyot, Nikolai Mansurov, Gunter Mussbacher: Understanding Existing Software with Use Case Map Scenarios, In: 3rd SDL and MSC Workshop (SAM02), LNCS 2599, Springer, p.124-140, 2002. Amy03 Daniel Amyot, Armin. Eberlein: An Evaluation of Scenario Notations and Construction Approaches for Telecommunication. Telecommunications Systems, Journal, Kluwer, 24(1): 61–94, 2003. Amy03b Daniel Amyot: Introduction to the User Requirements Notation: Learning by Example. Computer Networks, IEEE, 42(3):285–301, 2003. Amy04 Daniel Amyot, Michael Weiss, Luigi. Logrippo: UCM-Based Generation of Test Goals, ISSRE04: WITUL, 2004, available at http://www.sdl-forum.org, Nov.2004 Amy05 Daniel Amyot, Michael Weiss, Luigi Logrippo: Generation of Test Purposes from Use Case Maps, Computer Networks, 49(5):643-660, 2005. Amy08 Daniel Amyot, Hanane Becha, Rolv Bræk, Judith E.Y. Rossebø: Next Generation Service Engineering, In: ITU-T Innovations in NGN - Kaleidoscope Academic Conference, Geneva, Switzerland, p.195–202, 2008. Amy10 Daniel Amyot, Sepideh Ghanavati, Jennifer Horkoff, Gunter Mussbacher, Liam Peyton, Eric Yu: Evaluating Goal Models within the Goal-oriented Requirement Language. In: Int. Journal of Intelligent Systems, Wiley, 25(8):841–877, 2010. Amy11 Daniel Amyot, Gunter Mussbacher: User Requirements Notation: The First Ten Years, The Next Ten Years (Invited paper), Journal of Software, Academy Publisher, 6(5):747-768, 2011. Amy11b Daniel Amyot, Saeed Ahmadi Behnam: Evolution of Goal-Driven Pattern Families for Business Process Modeling. In Proc. E-Technologies: Transformations in a Connected World (5th MCeTechConf.), January 25-28 2011, Les Diablerets, Switzerland, Springer, p. 46-61, 2011.
132
Amy99 Daniel Amyot, Luigi Logrippo, Raymond J.A. Buhr, Tom Gray: Use Case Maps for the Capture and Validation of Distributed Systems Requirements, In: Fourth Int. Symposium on Requirements Engineering (RE'99), IEEE CS, p.44–53,1999. AOS12 Aspect-Oriented Software Development – aosd.org. 2012. Arn10 Dave Arnold, Jean-Pierre Corriveau, Wei Shi: Scenario-Based Validation: Beyond the User Requirements Notation, In: 21st Australian Software Engineering Conf. (ASWEC 2010), IEEE CS, p.75–84, 2010. ATH ATHENA Interoperability Framework http://athena.modelbased.net/index.html, 2012 Atk02 Collin Atkinson et al.: Component-Based Product-Line Engineering with UML. Addison-Wesley, London, 2002. ATL12 ATLAS Model Management Architecture – AMMA - http://www.eclipse.org/atl/ Aya05 Claudia P. Ayala, Carlos Cares, Juan Pablo Carvallo, Gemma Grau, Mariela Haya, Guadalupe Salazar, Xavier Franch, Enric Mayol & Carme Quer: A Comparative Analysis of i*-Based Goal-Oriented Modeling Languages. In AOSDM 2005, Proc. of The 17th International Conference on Software Engineering and Knowledge Engineering (SEKE'05). 14-16 July, 2005. Taipei, Taiwan, p. 43-50, 2005. BABOK12 BABOK Guide 2.0: A Guide to the Business Analysis Body of Knowledge . International Institute of Business Analysis. IIBA.2012. Bak05 Paul Baker, Shiou Loh, Frank Weil: Model-Driven Engineering in a Large Industrial Context Motorola Case Study In: Proc. Lionel Briand, Clay Williams (Eds.): 8th International Conference, MODELS 2005, Montego Bay, Jamaica, October 2-7, 2005, Proceedings. LNCS 3713, Springer, p.476491, 2005. Bal06 Krishnakumar Balasubramanian, Aniruddha Gokhale, Gabor Karsai, Janos Sztipanovits, Sandeep Neema: Developing applications using model-driven design environments. IEEE Computer 39:33-40, 2006. Bal07 Laurent Balmelli: The Systems Modeling Language for Products and Systems Development. Journal of Object Technology, 6(6):149-177, 2007. BAM08 Bar10 Daniele Barone, Eric Yu, Jihyun Won, Lei Jiang, John Mylopoulos, Enterprise Modeling for Business Intelligence, in The Practice of Enterprise Modeling, LNBIP 68, Springer, p.31–45, 2010. Bas03 Wim Bast, Anneke Kleppe, Jos Warmer: MDA Explained: The Model Driven Architecture: Practice and Promise, Addison-Wesley, 2003. Bas97 Victor R. Basili: Evolving and Packaging Reading Technologies, Journal of Systems and Software, 38(1) 1997 Bas98 Len Bass et al.: Software Architecture in Practice, Addison-Wesley, 1998. Bec09 Philipp Becker, Dennis Christmann, Reinhard Gotzhein: Model-Driven Development of Time-Critical Protocols with SDL-MDD. LNCS 5719, Springer Berlin Heidelberg, p.34-52, 2009. Beh12 Saeed Ahmadi Behnam: Goal-oriented Pattern Family Framework for Business Process Modeling, Ph.D. thesis, Dept. of Computer Science, University of Toronto, Canada, 2012. Ben09 Reda Bendraou, Jean-Marc Jézéquel, Franck Fleurey: Combining Aspect and Model-Driven Engineering Approaches for Software Process Modeling and Execution. In Proceedings of International Conference on Software Process, ICSP 2009, May 16-17, 2009, Vancouver, Canada, LNCS 5543, Springer, p.148-160, 2009. Ben10 Reda Bendraou, Jean-Marc Jézéquel, Marie-Pierre Gervais, Xavier Blanc: A Comparison of Six UMLBased Languages for Software Process Modeling. IEEE Trans. Software Eng. 36(5):662-675, 2010. Ber07 Lionel van den Berg, Paul Strooper, Wendy Johnston: An Automated Approach for the Interpretation of Counter-Examples, ENTCS 174, p.19-35, 2007. Béz00 Jean Bézivin: New trends in model engineering, In: Mehdi Khosrowpour (Ed.): Challenges of Information Technology Management in the 21st Century, 2000 Information Resources Management Association International Conference, Anchorage, Alaska, USA, May 21-24, 2000. IDEA Group Publishing, p.1185-1187, 2000. Béz01 Jean Bézivin: Models Everywhere. In: TOOLS USA 2001: Software Technologies for the Age of the Internet, 39th International Conference & Exhibition, Santa Barbara, CA, USA, July 29 - August 3, 2001. IEEE Computer Society, p.348-349, 2001. Béz01b Jean Bézivin: From Object Composition to Model Transformation with the MDA, In: TOOLS USA 2001: Software Technologies for the Age of the Internet, 39th International Conference & Exhibition, Santa Barbara, CA, USA, July 29 - August 3, 2001. IEEE Computer Society, p.350-354, 2001. Béz01c Jean Bézivin, Olivier Gerbé: Towards a Precise Definition of the OMG/MDA Framework, In: 16th IEEE International Conference on Automated Software Engineering (ASE 2001), 26-29. November 2001, Coronado Island, San Diego, CA, USA. IEEE Computer Society, p.273-280, 2001.
133
Béz04
Jean Bézivin: Model Engineering for Software Modernization, In: 11th Working Conference on Reverse Engineering (WCRE 2004), 8-12 November 2004, Delft, The Netherlands. IEEE Computer Society, p.4, 2004. Béz05 Jean Bézivin: On the Unification Power of Models. In: J. Software and Systems Modeling, 4(2):171188, 2005. Béz05b Jean Bézivin, Frédéric Jouault, David Touzet: Principles, Standards and Tools for Model Engineering, In: 10th International Conference on Engineering of Complex Computer Systems (ICECCS 2005), 1620 June 2005, Shanghai, China. IEEE Computer Society, p.28-29. 2005. Béz06 Jean Bézivin: Model Driven Engineering: An Emerging Technical Space, In: Ralf Lämmel, João Saraiva, Joost Visser (Eds.): Generative and Transformational Techniques in Software Engineering, International Summer School, (GTTSE 2005), Braga, Portugal, July 4-8, 2005. Revised Papers. Lecture Notes in Computer Science 4143 Springer, p.36-64. 2006. Béz08 Jean Bézivin, Richard F. Paige, Uwe Asmann, Bernhard Rumpe, Douglas C. Schmidt: Manifesto Model Engineering for Complex Systems Perspectives Workshop: Model Engineering of Complex Systems (MECS 2008), Dagstuhl Seminar Proceedings, 08331, Dagstuhl, Germany, 2008. Béz09 Jean Bézivin:If MDE Is the Solution, Then What Is the Problem? Keynote In Mark van den Brand, Dragan Gasevic, Jeff Gray (Eds.): Software Language Engineering, Second International Conference, SLE 2009, Denver, CO, USA. LNCS 5969, Springer, p.2, 2009 Béz10 Jean Bézivin, Richard Mark Soley, Antonio Vallecillo: Model-Driven Interoperability: MDI 2010. Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.145-149, 2011. Bie03 Julien Bieren, Dániel Muhi, Tibor Dulai, Anna Medve, Katalin Tarnay: Protocol Specification : Fitting the Self-Adaptivity in the AO paradigm, International Workshop on Self-Adaptive Software (IWSAS2003) June 9-11 2003, Arlington (VA), USA, 2003. Boo04 Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh, Bran Selic: An MDA Manifesto, MDA Journal (5):2-9, 2004. Bor00 Francis Bordeleau, Donald Cameron: On the Relationship between Use Case Maps and Message Sequence Charts, In: 2nd Workshop on SDL and MSC (SAM 2000), Grenoble, France, p.123–138, 2000. Bor10 Zsolt Borsi, László Kozma, Anna Medve: Component-based Software Engineering Verification Problems, In: LászlóVarga, Gunter Weiss, Gábor Kusper (Eds), Proc. of the 8th Int. Conf. on Applied Informatics (ICAI 2010) Eger, Hungary, January 27-30, 2010, p.391-400, 2010. Bor11 Zsolt Borsi, László Kozma: Verification of Component-Based SystemUsing Model Checking. In: Horia F. Pop, Antal Bege (Eds): Proceedings of the 8th Joint Conference on Mathematics and Computer Science, MaCS 2010, Komarno, Slovakia, July14-17, 2010, Selected Papers, Novadat LTD., p.323-336, 2011. Bor97 Francis Bordeleau, Raymond J.A. Buhr: The UCM-ROOM Design Method: from Use Case Maps to Communicating State Machines, In Conf. on the Engineering of Computer- Based Systems (ECBS), p.167–179, March 1997. Bor99 Francis Bordeleau: A Systematic and Traceable Progression from Scenario Models to Communicating Hierarchical State Machines. Ph.D. thesis, SCE Dept., Carleton University, Canada, December 1999. Bos11 Marko Boskovic, Gunter Mussbacher, Ebrahim Bagheri, Daniel Amyot, Dragan Gasevic, Marek Hatala: Aspect-Oriented Feature Models. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.110-124, 2011. Boz04 Marius Bozga, Susanne Graf, Laurent Mounier, Ileana Ober, Iulien Ober, Joseph Sifakis: The IF toolset, Formal Methods for the Design of Real-Time Systems, LNCS 3185, p.237-267, 2004. BPM12 Business Process Model and Notation (BPMN), OMG specifications, www.omg.org/spec, 2012. Bra08 Marco Brambilla, Piero Fraternali, Massimo Tisi. A Transformation Framework to Bridge Domain Specific Languages to MDA. In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008. LNCS 5421, Springer, p.167-180, 2009. Bra12 Marco Brambilla, Jordi Cabot, Manuel Wimmer: Model-Driven Software Engineering in Practice. www.mdse-book.com. Morgan&Claypool Publishers, 2012. Bra12 Tobias Braun, Dennis Christmann, Reinhard Gotzhein, Anuschka Igel: Model-driven Engineering of Networked Ambient Systems with SDL-MDD. Procedia CS 10:490-498, 2012. Bræ98 Rolv Bræk, Birger Møller-Pedersen: Frameworks by means of virtual types - exemplified by SDL, Formal Description Techniques and Protocol Specification, Testing, and Verification. In: Stanislaw
134
Budkowski, Ana Cavalli, Elie Najm, (Eds), Proceedings of FORTE/PSTV’98, Kluwer Academic Publishers, Boston, p.181–196, 1998. Brau12 Edna Braun, Nick Cartwright, Azalia Shamsaei, Saeed Ahmadi Behnam, Gregory Richards, Gunter Mussbacher, Mohammad Alhaj, Rasha Tawhid: Drafting and Modeling of Regulations: Is It Being Done Backwards?, In: 5th International Workshop on Requirements Engineering and Law (RELAW 2012),IEE CS, 2012. Bre06 Silvia Breu, Thomas Zimmermann, Christian Lindig: Aspect mining for large systems. In: Peri L. Tarr, William R. Cook (Eds.): Companion to the 21th Annual ACM SIGPLAN Conference on ObjectOriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, Oregon, USA ACM, p.641-642, 2006. Bri98 Lional Briand et al: Using Simulation to Build Inspection Efficiency Benchmarks for Development Projects, in Proceedings of the 20st International Conference of Software Engineering, IEEE Computer Society Press p.340-349, 1998. Bri99 Lional Briand et al. A Unified Framework for Coupling Measurement in Object-Oriented Systems, IEEE Transactions on Software Engineering, 25(1),91-122, 1999. Bru03 Hans de Bruin and Hans van Vliet: Quality-Driven Software Architecture Composition. In: Journal of Systems and Software, Elsevier, 66(3):269–284, 2003. Bru10 Achim D. Brucker, Matthias P. Krieger, Delphine Longuet, Burkhart Wolff: A Specification-Based Test Case Generation Method for UML/OCL. In Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627 Springer, p.334-348, 2011. Bru11 Hugo Bruneliere, Jordi Cabot, Cauê Clasen, Frédéric Jouault, Jean Bézivin: Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools. In: Proceedings ECMFA 2010 Thomas Kühne, Bran Selic, Marie-Pierre Gervais, François Terrier (Eds.): 6th European Conference on Modelling Foundations and Applications, Paris, France, June 15-18, 2010, LNCS 6138, Springer, p.3247, 2011. Brue08 Jean-Michel Bruel, Agusti Canals, Sébastien Gérard, Isabelle Perseil (Eds): Introduction to special issue: papers from UML&FM, Innovations in Systems and Software Engineering, 4(3):185-187, 2008. Buc04 Antonio Bucchiarone, Henry Muccini, Patrizio Pellicione, Pierluigi Pierini: Model-Checking plus Testing: from Software Architecture Analysis to Code Testing, In: Proceedings International Workshop on Integration of Testing Methodologies, FORTE 2004. LNCS 3236, p.351-365, 2004. Buh96 Raymond J.A. Buhr: Design Patterns at Different Scales, In: Pattern Languages of Programs (PLoP96), June 1996. Buh98 Raymond J.A. Buhr: Use Case Maps as Architectural Entities for Complex Systems, In: Transactions on Software Engineering, p.1131-1155, 1998. Bun09 Christian Bunse, Hans-Gerhard Groß, Christian Peper: Embedded System Construction - Evaluation of Model-Driven and Component-Based Development Approaches, In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008, LNCS 5421, Springer, p.66-77, 2009. Bus08 Ralf Buschermöhle, Jörg Oelerink: Rich meta object facility formal integration platform: syntax, semantics and implementation. Innovations in Systems and Software Engineering, 4(3):249-257, 2008. Bus96 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons, 1996. Buss05 Frank Bussemaker: BPM in Europe – Processes are everywhere, Business Process Trends 2005:3, Retrieved March 11, 2005 from www.bptrends.com Byu06 YoungJoon Byun, Sanders, Beverly A. Sanders: A Pattern-based Development Methodology for Communication Protocols. In: Journal of Information Science and Engineering, 22:315-335, 2006. Cab09 Jordi Cabot, Martin Gogolla, Pieter Van Gorp: Eighth International Workshop on OCL Concepts and Tools. In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008, LNCS 5421 Springer, p.257-262, 2009. Cab11 Jordi Cabot, Tony Clark, Manuel Clavel, Martin Gogolla: Tenth International Workshop on OCL and Textual Modelling. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627 Springer, p.329-333, 2011. Cab11b Jordi Cabot, Massimo Tisia: The MDE Diploma: first international postgraduate specialization in model-driven engineering. In: Special Issue: Software Modeling in Education, Computer Science Education, 21(4):389-402, 2011. CADP12 CADP-Construction and Analysis of Distributed Processes, www.inrialpes.fr/vasy/cadp/demos.html CAISE12 Conference on Advanced Information System Engineering, www.caise.org, 2012.
135
Che07
Pengfei Chen: Goal-Oriented Business Process Monitoring: An Approach based on User Requirement Notation combined with Business Intelligence and Web Services. M.Sc. thesis, SCS Dept., Carleton University, Canada, 2007. Che09 Fei Chen, Wan-hua Cao, Yong Huang: Research on Component-Based Model Driven Architecture Development and Assembly, Eighth IEEE International Conference on Dependable, Autonomic and Secure Computing, p.636-641, 2009. Chi03 Chikán Attila, Wimmer Ágnes: Üzleti fogalomtár, Alinea Kiadó, Budapest, 2003. Cho07 Yunja Choi: Early Safety Analysis: from Use Cases to Component-based Software Development. In: Journal of Object Technology, 6(8):185–203, 2007. Cis98 Daniel Cisowski, Birgit Geppert, Frank Rößler, Markus Schwaiger: Tool Support for SDL Patterns. In: Yair Lahav, Adam Wolisz, Joachim Fischer, Eckhardt Holz (eds.): Proceedings of the 1st Workshop on SDL and MSC (SAM 1998), Berlin, 1998. Cla00 Edmund M. Clarke, Oma Grumberg, Doron.A Peled: Model Checking, In: The MIT Press, Cambridge, 2000. Cla02 Tony Clark, Andy Evans, Stuart Kent: Engineering Modelling Languages: A Precise Meta-Modelling Approach. FASE 2002. p.159-173 Cla09 Edmund M. Clarke, E. Allen Emerson, Joseph Sifakis: Model checking: algorithmic verification and debugging, In: Communications of the ACM, 52(11):74-84, 2009. Cla96 Edmund M. Clarke, Janette Wing: Formal Methods: State of the Art and Future Directions. ACM Computing Surveys, 28: 4, 1996. COB12 COBIT, www.isaca.org/cobit Coc01 Alistair Cockburn: Writing Effective Use Cases. Addison-Wesley, 2001. Col94 Derek Coleman: Object-Oriented Development: The Fusion Method. PrenticeHall, 1994. Com02 Computer Networks Group: The SDL Pattern Pool, Online document, University of Kaiserslautern, Kaiserslautern,, Germany, (2002) (kérésre megküldik a mintakezelést automatizáló SPT eszközt és mintagyűjteményt) Cop95 James O.Coplien, Douglas C. Schmidt: Pattern Languages of Program Design. Vol.1. Addison-Wesley, 1995. Crn09 Ivica Crnkovic, Ivano Malavolta, Henry Muccini: A Model-Driven Engineering Framework for Component Models Interoperability. CBSE 2009: 36-53, 2009. Cuc11 Arnaud Cuccuru, Sébastien Gérard, François Terrier: Defining MARTE's VSL as an Extension of Alf. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, (MODELS 2011), Wellington, New Zealand, October 16-21, 2011. Proceedings. LNCS 6981 Springer, p.699-713, 2011. Cza06 Krzysztof Czarnecki, Simon Helsen: Feature-based survey of model transformation approaches. In: IBM Systems Journal 45(3): 621-645, 2006. Cza11 Krzysztof Czarnecki: Designing Variability Modeling Languages. In: Anthony M. Sloane, Uwe Aßmann (Eds.): Software Language Engineering - 4th International Conference, SLE 2011, Braga, Portugal, July 3-4, 2011, Revised Selected Papers.LNCS 6940, Springer, p.222, 2011. Dam06 Christophe Damas, Bernard Lambeau, Axel van Lamsweerde: Scenarios, Goals, and State Machines: a Win-Win Partnership for Model Synthesis. In: Proceedings FSE'06: International ACM Symposium on the Foundations of Software Engineering, Portland (OR), November 2006. Dár03 Dárdai Balázs: Mobil távközlés, mobil internet. Computerbooks, Budapest, 2003. Del08 David Delahaye, Jean-Frédéric Étienne, Véronique Donzeau-Gouge: A formal and sound transformation from Focal to UML: an application to airport security regulations. In: Innovations in Systems and Software Engineering, 4(3):267-274, 2008. Der11 Dirk Deridder, Alfonso Pierantonio, Bernhard Schätz, Dalila Tamzalit: Models and Evolution ME2010. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.180-183, 2011. Des98 Jörg Desel, Andreas Oberweis, Wolfgang Reisig, Grzegorz Rozenberg Report on Petri Nets and Business Process Management IBFI Seminar, Schloss Dagstuhl July 6-10, 1998, http://www.dagstuhl.de/Reports/98/98271.pdf Dia09 Andres Díaz-Pace, Juan P. Carlino, Martin Blech, Alvaro Soria, Marcelo R. Campo, Assisting the Synchronization of UCMbased Architectural Documentation with Implementation, In: IEEE/IFIP Conf. on Software Architecture and European Conference on Software Architecture (WICSA/ECSA 2009), IEEE CS, p.151–160, 2009. Dis11 Zinovy Diskin, Yingfei Xiong, Krzysztof Czarnecki: Specifying Overlaps of Heterogeneous Models for Global Consistency Checking. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software
136
Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.165-179, 2011. Dju05 Dragan Djuric, Dragan Gaševi, Vladan Devedžic: Ontology Modeling and MDA, In: Journal of Object Technology, 4(1):109-128, 2005. Dol01 Laurent Doldi: SDL Illustrated - visually design executable models, TMSO, 2001. Dol03 Laurent Doldi: Validation of Communications Systems with SDL: The Art of SDL In: Simulation and Reachability Analysis, John Wiley & Sons, 2003. Dor05 Jörg Dorsch, Anders Ek, Reinhard Gotzhein: SPT - The SDL Pattern Tool. In: Daniel Amyot, Alan W. Williams (Eds.), Proceedings of the System Analysis and Modeling, 4th International SDL and MSCWorkshop, SAM 2004, LNCS 3319, Springer, p.50-64, 2005. DRE12 Distributed Real-time Embedded Analysis Method – DREAM, http://dre.sourceforge.net/, 2012. Dub00 Olivier Dubuisson: ASN.1: Communication between heterogeneous systems, OSS Nokalva, 2000. http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.html Dul02 Tibor Dulai, Anna Medve: Analysis and Design of Bluetooth's Logical Link Control Protocol, 14th Euromicro Conference on Real-Time Systems ,Workshop on Real-Time LANs in the Internet Age., Vienna, June 19 - 21, 2002, http://www.hurray.isep.ipp.pt/rtlia2002/full_papers/16_rtlia.pdf Dul04 Tibor Dulai, Anna Medve, Dániel Muhi, Katalin Tarnay: Service Discovery to Create a Well Personalised e-Learning System. In: Remenyi, D. (ed.) Proc of the 3rd European Conference on eLearning, ECEL 2004, 25-26 November 2004, Univ., Paris, France, p138-144, 2004. Eis07 Susan Eisenbach, Chris Sadler: Reuse and Abuse. In: Journal of Object Technology, 6(1):139-167, 2007. Elr04 Tzilla Elrad, Robert E. Filman, Mehmet Aksit, Siobhán Clarke: Aspect Oriented Software Development, Addison Wesley, 2004. EMF12 Eclipse Modeling Project. 2010. http://www.eclipse.org/modeling/. ENISA12 European Network and Information Security Agency - Risk Management - Emerging and Future Risks. ENISA, 2012. Eri00 Hans-Erik Eriksson, Magnus Penker: Business Modeling With UML: Business Patterns at Work. OMG Press, John Wiley, 2000. ETSI12 European Telecommunication Standardisation Institute: ES 201 873-1 4.5.1 TTCN-3: Core Language, 2012. Fav05 Liliana Favre: Foundations for MDA-based Forward Engineering, In: Journal of Object Technology, 4(1):129-153, 2005. Fel99 Raimund Feldmann, Birgit Geppert, Frank Rößler: Towards an Experimental Evaluation of SDLPattern based Protocol Design, https://kluedo.ub.uni-kl.de/frontdoor/index/index/docId/432 Fli07 Ingmar Fliege, Reinhard Gotzhein: Automated Generation of Micro Protocol Descriptions from SDL Design Specifications. In: Emmanuel Gaudin, Elie Najm, Rick Reed (Eds.): SDL Forum 2007, LNCS 4745, p.150-165, 2007. For08 Andrew Forward, Timothy C. Lethbridge: Problems and Opportunities for Model-Centric Vrsus CodeCentric Development: a Survey of Software Professionals. In Proceedings International Workshop on Models in Software Engineering (MISE’08@ICSE’08), May 10–11, 2008, Leipzig, Germany, ACM, 2008. Fow02 Martin Fowler: Patterns of Enterprise Application Architecture. Addison-Wesley, 2002. Fow10 Martin Fowler: Language Workbenches: The Killer-App for Domain Specific Languages, http://martinfowler.com/articles/languageWorkbench.html, http://martinfowler.com/bliki/LanguageWorkbenchReadings.html Fox98 Mark S. Fox, Michael Gruninger: Enterprise modelling. AI Magazine AAAI Press, Fall 19(3):109-121, 1998. Fra03 David S. Frankel: Model Driven Architecture: Applying MDA to Enterprise Computing, John Wiley & Sons, 2003. Fra04 Robert B. France, Day-Kioo Kim, Sudipto Ghosh, Eunjee Song: A UML-Based Pattern Specification Technique. IEEE Transactions on Software Engineering 30(3): 2004. Frap08 Marc Frappier, Frédéric Gervais, Régine Laleau, Benoît Fraikin, Richard St.-Denis: Extending statecharts with process algebra operators. In: Innovations in Systems and Software Engineering, 4(3):285-292, 2008. Fue07 Lidia Fuentes, Pablo Sánchez: Designing and Weaving Aspect-Oriented Executable UML Models. In: Journal of Object Technology, 6(7):109-136, 2007. Gab06 Richard P. Gabriel, Guy L. Steele, Friedrich Steimann, Jim Waldo, Gregor Kiczales, Kevin J. Sullivan: Aspects and/versus modularity the grand debate. In: Peri L. Tarr, William R. Cook (Eds.): Companion to the 21th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,
137
Languages, and Applications, (OOPSLA 2006), October 22-26, 2006, Portland, Oregon, USA. ACM, p.935-936, 2006. Gam95 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading Wesley 1995. Gao10 Yan Gao: Import/Export of URN Models in Z.151 XML File Format with jUCMNav. M.Sc. project, SITE, University of Ottawa, Canada, January 2010. Gen10 Nicolas Genon, Daniel Amyot, Patrick Heymans: Analysing the Cognitive Effectiveness of the UCM Visual Notation, In: 6th Workshop on System Analysis and Modelling (SAM 2010), LNCS 6598, Springer, p.221-240, 2010. Gep97 Birgit Geppert, Reinhard Gotzhein, Frank Rößler: Configuring Communication Protocols Using SDL Patterns, In: Ana R. Cavalli, Amardeo Sarma (eds.), SDL'97 - Time for Testing, Proceedings of the 8th SDL Forum, Elsevier, Amsterdam, p.523-538, 1997. Ger11 Gerecs István: Business Analyst Megoldás értékelés és validálás munkafolyamatai a szoftverevolúcióban. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2010. Gha10 Sepideh Ghanavati, Alberto Siena, Daniel Amyot, Anna Perini, Liam Peyton, Angelo Susi: Integrating Business Strategies with Requirement Models of Legal Compliance. Int. J. of Electronic Business, Inderscience Publishers, p.260–280, 2010. Gli04 Martin Glinz: Systematically combining specifications of internal and external system behavior using statecharts, http://www.ifi.unizh.ch/groups/req/ftp/papers/SCESM2004.pdf, 2004. Glu99 David P. Gluch, Jared Brockway: An Introduction to Software Engineering Practices Using ModelBased Verification, Technical Report, CMU/SEI-99-TR-005, 1999. GME12 GENERIC Model Environment - www.isis.vanderbilt.edu/Projects/gme/default.htm Gor02 Jaap Gordijn: Value-based Requirements Engineering Exploring Innovative e-Commerce Ideas. Ph.D. thesis,Vrije Universiteit, Amsterdam, The Netherlands, 2002. Gor99 Jaap Gordijn, Hans van Vliet: Integral Design of ECommerce Systems: Aligning the Business with Software Architecture through Scenarios, In: ICT-Architecture in the BeNeLux (ICT 1999), 1999. Got03 Reinhard Gotzhein: Consolidating and applying the SDL-pattern approach: a detailed case study. Information & Software Technology, Elsevier Science, 45(11):727-741, 2003. Got03b Reinhard Gotzhein: Vertical reuse in the development of distributed systems with FDTs. In: International Conference on Application of Formal Description Techniques in Internet and Communication Domains (FORTE’2003), Lecture Notes in Computer Science, Springer-Verlag, Berlin Heidelberg New York, 2767: 31-47, 2003. Got94 Orlena Gotel, Anthony Finkelstein: An analysis of the requirements traceability problem. In: First International Conference on Requirements Engineering (ICRE'94), Colorado Springs, USA, p.94-10, 1994. Gra11 Jeff Gray, Dominik Stein, Jörg Kienzle, Walter Cazzola: Report of the 15th International Workshop on Aspect-Oriented Modeling. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.105-109, 2011. Gra98 Grama R. Srinivasan, David P. Gluch: A Study of Practice Issues in Model-Based Verification Using the Symbolic Model Verifier (SMV) CMU/SEI-98-TR-013 Software Engineering Institute, Carnegie Mellon University, 1998. Gro05 Haus-Gerhard Gross: Component-Based Software Testing with UML, Springer-Verlag, Berlin, Heidelberg, 2005. Gru08 Stefan Gruner: From use cases to test cases via meta model-based reasoning. In: Innovations in Systems and Software Engineering, 4(3):223-231, 2008. Gue00 Alain Le Guennec, Gerson Sunyé, Jean-Marc Jézéquel: Precise Modeling of Design Patterns. In Proc. Andy Evans, Stuart Kent, Bran Selic (Eds.): «UML» 2000 - The Unified Modeling Language, Advancing the Standard, Third International Conference, York, UK, October 2-6, 2000,. LNCS 1939, Springer, p.482-496, 2000. Gyi09 Tibor Gyimóthy (Keynote):To Use or Not to Use? - The Metrics to Measure Software Quality (Developers' View), In 13th European Conference on Software Maintenance and Reengineering, Architecture-Centric Maintenance of Large-Scale Software Systems, Kaiserslautern, Germany,2009. Han11 Hangonyi Gábor: A vállalatelemzés munkafolyamatainak UCM modellezése szoftverevolúcióban. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2011. Har04 David Harel, Rami Marelly: Come, Let’s play: Scenario-Based Programming Using LSCs and the PlayEngine, Springer-Verlag, 2003. available at http://www.wisdom.weizmann.ac.il/~playbook/ Nov. 2004. Has08 Jameleddine Hassine: Formal Semantics and Verification of Use Case Maps. PhD. thesis, CSCE dept., Concordia University, Canada, April 2008.
138
Has09
Jameleddine Hassine: Early Schedulability Analysis with Timed Use Case Maps, In: SDL 2009:
Design for Motes and Mobiles, 14th Int. SDL Forum, LNCS 5719, Springer, p.98–114, 2009. Házer István: Hálózattechnológia terv e-szolgáltatások megvalósításához és integrálásához meglévő ERP rendszerbe, Szakdolgozat, Témavezető:Medve Anna, Pannon Egyetem, MIK, 2010. He03 Yong He, Daniel Amyot, Alan Williams: Synthesizing SDL from Use Case Maps: An Experiment, In: 11th SDL Forum (SDL'03), LNCS 2708, Springer, p.117–136, 2003. Hei11a Florian Heidenreich, Jendrik Johannes, Sven Karol, Mirko Seifert, Michael Thiele, Christian Wende, Claas Wilke: Integrating OCL and Textual Modelling Languages. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer p.349-363. 2011. Hei11b Florian Heidenreich, Jan Kopcsek, Uwe Asmann: Safe Composition of Transformations. In: Journal of Object Technology, 10(1):7, 2011. Hei12 Thomas A. Heinzinger: Quantitative Reactive Modeling. In: Robert B. France, Jürgen Kazmeier, Ruth Breu, Colin Atkinson (Eds.): Proc of. 15th International Conference Model Driven Engineering Languages and Systems - MODELS 2012, Innsbruck, Austria, September 30-October 5, 2012. LNCS 7590, p.1-2, 2012. Her09 Markus Herrmannsdoerfer, Daniel Ratiu, Guido Wachsmuth: Language Evolution in Practice: The History of GMF. In: Mark van den Brand, Dragan Gasevic, Jeff Gray (Eds.): Software Language Engineering, Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009, Revised Selected Papers. LNCS 5969, Springer, p.3-22, 2010. Hil12 http://www.hillside.net/patterns/, http://www.hillside.net/conferences, 2012. Ho99 Wai-Ming Ho, Jean-Marc Jézéquel, Alain Le Guennec, François Pennaneac'h: UMLAUT: an extendible UML transformation framework, In: Proceeding Automated Software Engineering, ASE'99, Florida, October 1999. Hoa05 Tony Hoare, Jayadev Misra: Verified software: Theories, tools and experiments: Vision of a Grand Challenge project, LNCS 4171 Springer 2005. Hor11 Jennifer Horkoff, Eric Yu: Analyzing Goal Models – Different Approaches and How to Choose Among Them, 2011. ACM Symposium on Applied Computing (SAC), ACM, p.675-682, 2011. http://dev.eclipse.org/viewcvs/indextech.cgi/gmthome/subprojects/VIATRA2/index.html. Hum89 Watts S. Humprey: Managing the Software Process, Addison-Wesley, 1989. Hut11 John Hutchinson, Mark Rouncefield, Jon Whittle: Model-driven engineering practices in industry. In: Richard N. Taylor, Harald Gall, Nenad Medvidovic (Eds.): Proceedings of the 33rd International Conference on Software Engineering, (ICSE 2011), Waikiki, Honolulu, HI, USA, May 21-28, 2011. ACM, p.633-642, 2011. IFIP12 International Federation for Information Processing (IFIP), http://www.ifip.or.at/, 2012. IFx12 IFx-OMEGA Toolset: http://www.irit.fr/ifx/; http://www-if.imag.fr/ OMEGA European Project (IST33522), http://www-omega.imag.fr/ Ira11 Mehdi Iraqi-Houssaini, Mathias Kleiner, Lionel Roucoules: Model-Based (Mechanical) Product Design. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, (MODELS 2011), Wellington, New Zealand, October 16-21, 2011. LNCS 6981, Springer, p.548-562, 2011. ISO12 ISO Related Standards -ISO 14598-5:1998, Information Technology Software Product Evaluation – Part 5: Process for Evaluation. Technical Committee/Sub-Committee: JT1/SC7. Geneva. ISO 9241-210:2010, Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems. Technical Committee/Sub-Committee: TC159/SC4. Geneva. ISO/IEC 25000:2005, Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE. Joint Technical Committee/Sub-Committee: JTC1/SC7. Geneva. ISO/IEC 9126-1:2001, Software engineering – Product quality – Part 1: Quality model. Joint Technical Committee/Sub-Committee: JTC1/SC7. Geneva. ISO27000 ISO/IEC 27000:2012 Information technology -- Security techniques -- Information security management systems, http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html, http://www.27000.org ISO9126 ISO/IEC 9126 -1: Information Technology – Software Product Quality –Part 1: Quality Model, ISO, Geneva, 1998., ISO/IEC TR 9126-2, Software engineering, External metrics.2000.; ISO/IEC TR 91263, Software engineering, Internal metrics.2000.; ISO/IEC TR 9126-4, Software engineering, Quality in use metrics, 2000. ISOomg ISO adopted OMG standards: KDM - 19506:2012; MOF - 19502:2005; OCL - 19507:2012; CORBA 19500-1:2012, 19500-2:2012, 19500-3:2012; UML2.4.1 - 19505-1:2012, 19505-2:2012; XMI 19503:2005. Ház10
139
Ist10
Zoltán Istenes: Formal Methods in Robot Control Systems, In: Laszló.Varga, Günter Weiss, Gábor Kusper (Eds): Proc. of the 8th ICAI 2010,, Eger, Hungary, January 27-30, 2010, p. 391-400, 2010. ITU12 ITU-T Recommendation Z. Series: Languages and General Software Aspects for Telecommunication Systems, http://www.itu.int/rec/T-REC-z. ITUx680 ITU-T Recommendation X.680 Abstract Syntax Notation One (ASN.1) ITUz100 ITU-T Recommendation Z.100: Specification and Description Language (SDL) ITUz109 ITU-T Recommendation Z.109: Specification and Description Language - Unified modeling language profile for SDL-2010 ITUz119 ITU-T Recommendation Z.119: Guidelines for UML profile design ITUz120 ITU-T Recommendation Z.120: Message Sequence Chart (MSC) ITUz151 ITU-T Recommendation Z.151: User requirements notation (URN) - Language definition ITUz160 ITU-T Recommendation Z.160: Testing and Test Control Notation version-3 ITUz199 ITU-T Recommendation Z.100-Z.199: Formal description techniques (FDT) -m ITUz450 ITU-T Recommendation Z.450 Quality aspects of protocol-related Recommendations. Izq12 Javier Luis Cánovas Izquierdo, Frédéric Jouault, Jordi Cabot, Jesús García Molina: API2MoL: Automating the building of bridges between APIs and Model-Driven Engineering. In: Information & Software Technology 54(3):257-273, 2012. Izu11 Sayaka Izukura, Kazuo Yanoo, Takao Osaki, Hiroshi Sakaki, Daichi Kimura, Jianwen Xiang: Applying a Model-Based Approach to IT Systems Development Using SysML Extension. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, (MODELS 2011), Wellington, New Zealand, October 16-21, 2011. LNCS 6981, Springer, p.563-577, 2011. Jac04 Ivar Jacobson, Ng, Pan-Wei: Aspect-Oriented Software Development with Use Cases, In: AddisonWesley, 2004. Jas10 Szilárd Jaskó, Tibor Dulai, Dániel Muhi, Katalin Tarnay: Test aspect of requirement specification. Comput. Stand. Interfaces 32(1-2):1-9, 2010. Jen11 Adam C. Jensen, Betty H. C. Cheng, Heather Goldsby, Edward C. Nelson: A Toolchain for the Detection of Structural and Behavioral Latent System Properties. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, (MODELS 2011), Wellington, New Zealand, October 16-21, 2011. Proceedings. LNCS 6981 Springer, p.683-698, 2011. Jéz03 Jean-Marc Jézéquel, Olivier Defour, Noël Plouzeau: An MDA Approach to Tame Component Based Software Development. In: Frank S. de Boer, Marcello M. Bonsangue, Susanne Graf, Willem-Paul de Roever (Eds.): Formal Methods for Components and Objects, LNCS 3188:260-275, 2003. Jéz08 Jean-Marc Jézéquel: Model driven design and aspect weaving. In: Software and System Modeling 7(2):209-218, 2008. Jéz12 Jean-Marc Jézéquel, Benoite Combemale, Didier Vojtisek: Ingénierie Dirigée par les Modèles: des concepts à la pratique, Ellipses, Paris, 2012. jUCM12 jUCMNAV 5.4 the URN tool, http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UcmNav, 2012. Kai05 Hermann Kaindl: Is object-oriented requirements engineering of interest. Requirements Engineering, 10:81-84, 2005. Kai09 Hermann Kaindl: Combining Requirements and Interaction Design through Usage Scenarios. In: Tom Gross et al. (Eds.) Proc. 12th IFIP TC 13 International Conference, Uppsala, Sweden, August 24-28, 2009, HCI – INTERACT 2009, LNCS 5727, Springer, p. 932-933, 2009. Kar03 Gábor Karsai, Aditya Agrawal: Graph Transformations in OMG's Model-Driven Architecture. Applications of Graph Transformations with Industrial Relevance, LNCS 3062, p.243-259, 2004. Kar10 Peter Karpati, Guttorm Sindre, Andreas L. Opdahl: Visualizing Cyber Attacks with Misuse Case Maps, In: 16th Int. Working Conf. on Requirements Engineering: Foundation for Software Quality (REFSQ 2010), LNCS 6182, Springer, p.262–275, 2010. Kar11 Peter Karpati, Andreas L. Opdahl, Guttorm Sindre: Experimental Comparison of Misuse Case Maps with Misuse Cases and System Architecture Diagrams for Eliciting Security Vulnerabilities and Mitigations, In: Sixth Int. Conf. on Availability, Reliability and Security (ARES 2011), IEEE CS, p.507-514, 2011. Kaz00 Rick Kazman, et al.: ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report ESCTR-2000-004, 2000. Kea06 Jason Kealey, Yongdae Kim, Daniel Amyot, Gunter Mussbacher: Integrating an Eclipse-Based Scenario Modeling Environment with a Requirements Management System, In: 2006 IEEE Canadian Conf. on Electrical and Computer Engineering (CCECE06), IEEE CS, p. 2432–2435, 2006.
140
Kea07
Jason Kealey: Enhanced Use Case Map Analysis and Transformation Tooling. M.Sc. thesis, SITE, University of Ottawa, Canada, September 2007. Kem11 Sören Kemmann, Thomas Kuhn, Mario Trapp: Extensible and Automated Model-Evaluations with INProVE. In: Frank Alexander Kraemer, Peter Herrmann (Eds.) 6th Int. Workshop SAM 2010, Oslo, Norway, October 4-5, 2010, Revised Selected Papers, LNCS 6598, Springer, p. 193-208, 2011. KER12 Kermeta – Triskell Modelling Kernel http://www.kermeta.org/ Kic05 Gregor Kiczales, Mira Mezini: Aspect-Oriented Programming and Modular Reasoning. In: Proceedings of the International Conference on Software Engineering, St. Louis, USA, ACM Press, p.49-58. 2005. Kic97 Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, John Irwin: Aspect-Oriented Programming, In: Proceedings of the 11th European Conference on Object-Oriented Programming, Jyväskylä, Finland, (LNCS 1241), Springer Verlag, p.220-242, 1997. Kit09 Barbara Kitchenham, O. Pearl Brereton, David Budgen, Mark Turner, Jarrod Bailey, Steve Linkman: Systematic literature reviews in software engineering - A systematic literature review. Inf. Softw. Technol. 51(1):7–15, 2009. Kli11 Wolfgang Kling, Frédéric Jouault, Dennis Wagelaar, Marco Brambilla, Jordi Cabot: MoScript: A DSL for Querying and Manipulating Model Repositories. In: Anthony M. Sloane, Uwe Aßmann (Eds.): Software Language Engineering - 4th International Conference, SLE 2011, Braga, Portugal, July 3-4, 2011, Revised Selected Papers.LNCS 6940, Springer, p.180-200, 2011. Kob04 Cris Kobryn: UML 3.0 and the future of modeling. In: Software and System Modeling, Springer, 3(1):4-8, Springer, 2004. Koc08 Kocsis Tibor: Logisztikai rendszer e-kereskedelem célú újratervezése. Diplomadolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2008. Koc10 Kocsi Péter Gábor: MobiAccess 3.1 mobil informatikai alkalmazásfejlesztő keretrendszer evolúciós bővítése fejlesztői és alkalmazás-felhasználói igények mentén. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2010. Koz08 László Kozma, Ákos Dávid: Educational aspects of incremental model checking, In Proceedings of the 3rd International Multi-Conference on Society, Cybernetics and Informatics, Orlando, Florida, USA, 2(10-13):190-194, 2009. Kra11 Max E. Kramer, Jörg Kienzle: Mapping Aspect-Oriented Models to Aspect-Oriented Code. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.125-139, 2011. KRONOS12 KRONOS Kru95 Philippe Kruchten:The 4+1 View Model of Architecture. IEEE Software, 12(6):45-50, 1995. Kru09 Philippe Kruchten, Rafael Capilla, Juan Carlos Dueas: The role of a decision view in software architecture practice. IEEE Software, 26(2):36-42,2009. Krü99 Igor Krüger, Radu Grosu, Peter Scholz, Mansfeld Broy: From MSCs to Statecharts, 1999., In: Franz J. Rammig (ed.): Distributed and Parallel Embedded Systems, Kluwer Academic Publishers Retrieved September 25, 2004 from http://www4.in.tum.de/publ/papers/KGSB99.pdf Kuh06 Thomas Kuhn, Reinhard Gotzhein, Christian Webel: Model-Driven Development with SDL - Process, Tools, and Experiences. In: Oscar Nierstrasz, Jon Whittle, David Harel, Gianna Reggio (Eds.): Model Driven Engineering Languages and Systems (MODELS 2006), p.83-97, 2006. Kul11 Vinay Kulkarni, Souvik Barat, Uday Ramteerthkar: Early Experience with Agile Methodology in a Model-Driven Approach. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, (MODELS 2011), Wellington, New Zealand, October 16-21, 2011. LNCS 6981, Springer, p.578-590, 2011. Kur06 Ivan Kurtev, Jean Bézivin, Frédéric Jouault, Patrick Valduriez: Model-based DSL frameworks, In: Peri L. Tarr, William R. Cook (Eds.): Companion to the 21th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, Oregon, USA. ACM, p.602-616, 2006. Lai00 Oliver Laitenberger, Jean-Marc DeBaud: An Encompassing Life Cycle-Centric Survey on Software Inspection, Journal of Systems and Software, 1(50):5-31, 2000. Lam09 Axel van Lamsweerde: Requirements Engineering – From System Goals to UML Models to Software Specifications. Wiley, 2009. Lam98 Axel van Lamsweerde, Laurent Willemet: Inferring Declarative Requirements Specifications from Operational Scenarios. 1998/12. IEEE Transactions on Software Engineering, Special Issue on Scenario Management. Lan11 Lang Zoltán: Technológiafejlesztés üzleti elemzők kooperatív munkafolyamataihoz. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2011.
141
Las08 Led08 Lei07 Lem10
Len08 Li08 Lia10
Liu00 Liu01 Liu04 Lor11
Los11 Mac11 Mal08 Mam00 Mbe10 McK09 MDS12 Med01 Med02 Med03 Med05 Med05b Med05c
Kristian Bisgaard Lassen, Simon Tjell: Model-based requirements analysis for reactive systems with UML sequence diagrams and coloured petri nets. In: Innovations in Systems and Software Engineering, 4(3):233-240, 2008. Hung Ledang, Hubert Dubois, Sébastien Gérard: Towards a traceability model in a MARTE-based methodology for real-time embedded systems. In: Innovations in Systems and Software Engineering, 4(3):189-193, 2008. F.Leitold, A.Medve, L.Kovács: SIP security problems in NGM Services, In: K. Al-Begain (Ed.) Proc. Int. Conf. on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007), IEEE, p.241-246, 2007. Youness Lemrabet, David Clin, Michel Bigand, Jean-Pierre Bourey, Nordine Benkeltoum: Model Driven Interoperability in practice: preliminary evidences and issues from an industrial project. In: Proceedings of MDI 2010, Jean Bézivin, Richard Mark Soley, Antonio Vallecillo (Eds.): Model-Driven Interoperability: MDI 2010, In conjunction with MODELS 2010, Oslo, Norway, October 3-5, ACM, p.89-97, 2010. László Lengyel, Tihamér Levendovszky, Hassan Charaf: Validated model transformation-driven software development, Int. Journal of Computer Applications in Technology, 31(1):106-119, 2008. Dan Li, Xiaoshan Li, Jicong Liu, Zhiming Liu: Validation of requirement models by automatic prototyping. In: Innovations in Systems and Software Engineering, 4(3):241-248, 2008. Yongxin Liao, Dumitru Roman, Arne J. Berre: Model-driven Rule-based Mediation in XML Data Exchange. In: Proceedings of MDI 2010, Jean Bézivin, Richard Mark Soley, Antonio Vallecillo (Eds.): Model-Driven Interoperability, (MDI 2010), In conjunction with MODELS 2010 Oslo, Norway, October 3-5, ACM, p.89-97, 2010. Lee Liu, Eric Yu: GRL – Goal-oriented Requirement Language, 2000. http://www.cs.toronto.edu/km/GRL/ Lee Liu, Eric Yu: From Requirements to Architectural Design - Using Goals and Scenarios, From Software Requirements to Architectures Workshop (STRAW 2001), May 2001, p.9, 2001. Lee Liu, Eric Yu: Designing Information Systems in Social Context: A Goal and Scenario Modelling Approach. Information Systems, p.187–203, 2004. Gaëlle Lortal, Saadia Dhouib, Sébastien Gérard: Integrating Ontological Domain Knowledge into a Robotic DSL. In: Anthony M. Sloane, Uwe Aßmann (Eds.): Software Language Engineering - 4th International Conference, SLE 2011, Braga, Portugal, July 3-4, 2011, Revised Selected Papers. LNCS 6940, Springer, p.401-414, 2011. Francisca Losavio, Jean Carlos Guzmán, Alfredo Matteo: Semantic Correspondence between GRL and BPMN (Correspondencia Semántica entre los lenguajes BPMN y GRL), Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento, 8(1):11-29, 2011. Mach Dámiel: Technológiatervezés tesztmérnök munkafolyamataira webszolgáltatások teszteléséhez. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2011. Frédéric Mallet: Clock constraint specification language: specifying clock constraints with UML/MARTE. In: Innovations in Systems and Software Engineering, 4(3):309-314, 2008. Zoubir Mammeri: SDL modélisation de protocoles et systèmes réactifs, In: Hermes Science, p.20-38, 2000. Modular Embedded DSL, http://mbeddr.com McKinsey Business Technology: How CIO should think about business value?, Innovation in IT Management, 15:28-37, 2009. Microsoft Domain Specific Modelling http://msdn.microsoft.com Medve Anna, Tarnay Katalin: A formális módszerek szerepe a távközlési szoftverek fejlesztésében, NetworkShop2001, Sopron, 2001. április 26-27., www.niif.hu/nws, 2001. Anna Medve: Bluetooth implementation frameworks, in: Advances in communications and Software Technologies, pp. 95-100, WSEAS Press, 2002. Anna Medve: MSC and the Aspect-Oriented Paradigm in Protocol Engineering, microCAD2003 the 23rd International Scientific Conference on Applied Information Engineering, Innovation and technology Transfer Centre, Miskolc, Vol N, p.71-78, Hungary. Anna Medve: Standardized Formal Languages for Reliable Model Engineering, Proc. 25rd. microCAD Int. Conf. on Applied Information Engineering, ITTC, Miskolc, Hungary, N:315-321, 2005. Anna Medve, Krisztina Szakolczay, György Kozmann: IT models for e-Health Application Processes. Book chapter In: Marius Duplaga, Krzysztof Zielinski (Eds.) Overcoming the barriers to e_he@lth growth in Enlarged Europe, Kraków, Health and Management Press, pp. 9-28, 2005. Medve Anna: SDL: A kommunikációs folyamatmodellek egyik szabványosított implementációs eszköze, Híradástechnika, LX.(10):7-13.
142
Med06 A.Medve, Il.Ober: Design patterns in SDL: The component configuration pattern case study, Kutatásjelentés, PE-MIK-IRT-3/06, 2006. Med07 A. Medve: Enterprise modelling with the joint use of User Requirements Notation (URN) and UML. Book chapter In: P.Rittgen (Ed.), Enterprise Modelling and Computation with UML, Hershey, USA. Development Ed. IDEA Group, p.46-69, 2007. Med07b Medve,A., Szima,I.: Esettanulmány a POSA2 Szolgáltatáselérés mintanyelv implementálására, Kutatásjelentés, PE-MIK-IRT-5/07, 2007. Med07c Medve, A.:UML és SDL társulása a valós idejű és egymásba ágyazott rendszerek modellezésére, Magyar-Francia TéT F/16, Kutatásjelentés, PE-MIK-IRT-2/07, 2007. Med07d Anna Medve, Zoltán Rigó, Attila Fodor, Dénes Fodor: Towards the Reconfigurable Diagnosis Tools with Control Area Network Requirements Descriptions, microCAD2007 the 27rd. International Scientific Conference on Applied Information Engineering, Vol. N, pp. 1-10, ITTC, Miskolc, Hungary. Med08 A.Medve, Il.Ober From Models to Components: Filling the Gap with SDL Macro-patterns, Int. Conf. Innovation on Software Engineering CIMCA/ISE’08, Vienna, Austria, IEEE, p.1252-1257, 2008. Med08b A.Medve: Advanced steps with standardized languages in the re-engineering process, Journal of Computer Standards & Interfaces, Elsevier, 30 (5):315-322, 2008. Med08c Medve Anna: SMIWEP projekt: e-Logisztika _es ERP modulok integrálása, Kutatásjelentés PE-MIKIRT-2/08, 2008. Med09 Medve,A., Nagy,T., Nagy,R., Nagy,N.: Kísérlet az ISO/IEC 27001 és 27002 modellezésére és az átfedések kezelésére, Kutatásjelentés, PE-MIK-VIRT-1/09, 2009. Med09b Medve Anna, Kövesi Klára: Modelling and Analysis of Information Security Starting from ISO/IEC 27001 Standard and Customer Loyalty Relationships. In: IFIP CONFENIS’2009, pp. 128-137, Győr, Hungary, 2009. Med09c Anna Medve, Klára Kövesi.: Modelling and Analysis of Information Security Starting from ISO/IEC 27001 Standard and Customer Loyalty Relationships. In: IFIP CONFENIS’2009, Győr, Hungary, p. 128-137, 2009. Med10 A.Medve, L.Kozma, Il.Ober: General Modelling Approach Based on the Intensive Use of Architectural and Design Patterns, In: H.Weghom, P.Isaias, R.Vasiu (Eds): Proc. of the IADIS Int. Conf. Applied Computing 2010, Timisoara, Romania, p 251-256, 2010. Med10b A.Medve, Gy.Orbán, L.Kozma: Let’s Go the Verification Engineering, In L.Varga, G.Weiss, G.Kusper (Eds.) Proc. of the 8th Int. Conf. on Applied Informatics (ICAI2010), pp. 417-428, Eger, Hungary, 2010. Med10c Medve,A.: ProjektProcess módszertan fejlesztése - Pannontej Zrt., Kutatásjelentés, PE-MIK-VIRT2/10, 2010. Med11 A.Medve: Standards-based Framework for Functionally Integrated Engineering of Information Systems. In T.Szmuc, M.Biró (Eds.) 5th IFIP TC2 Central and Eastern European Conf. on Software Engineering Techniques (CEE-SET 2011), Debrecen, Hungary, p.52-58, 2011. Med11 Medve Anna.: Felhőre fel! Avagy, kellenek-e a felharmonikusok az informatikusok képzésében? (The harmonization fields in education of information technology professionals for Cloud Computing skills In Hungarian ), 7th Conference in Informatics in Higher Education (IF2011), Debrecen, Hungary, 24-26 August 2011, University of Debrecen, ISBN 978-963-473-461-1, pp. 78-85, 2011. Med11b A.Medve, L.Kozma: MDA Process and Model Refinements Based on Verimag IFxVerification Tools, In: H.F.Pop, A.Bege (Eds.) Proc. 8th Joint Conf. on Mathematics and Computer Science, MaCS 2010, Komarno, Slovakia, July14-17, 2010, Selected Papers, Novadat Ltd., p.323-336, 2011. Med11c Medve,A: Módszertan elektronikus üzleti technológiák integrálására, Sonepar Magyarország Kft. B2B&B2C&URN projekt, Kutatásjelentés, PE-MIK-VIRT-3/11, 2011. Med11d Medve,A.: UCM2MSC minőség audit támogatás a ProjektProcessz folyamatspecifikációs módszertanban, Pannontej Zrt., Kutatásjelentés, PE-MIK-VIRT-1/11, 2011. Med12 A.Medve: Model-based Framework for Integrated Evolution of Business and IT Changes. In: S.Hammoudi, M.Sinderen, J.Cordeiro (Eds.) ICSOFT 2012. Proc. of the 7th Int. Conf. on Software Paradigm Trends, 24 - 27 July 2012, Rome, Italy, SciTePress, p.255-260, 2012. Med12b A.Medve: Towards MDE Improvements from Integrated Formal Verifications, J. STUDIA Univ. Babes-Bolyai, LVII(1):89-104, 2012. Med12c Medve,A. Mobil informatikai szolgáltatások üzleti folyamatainak modellvezérelt fejlesztése, AEF project - Informatix Zrt., GOP-1.1.1-09/1-2010-0025 Kutatásjelentés, PE-MIK-VIRT-2/12, 2012. Med97 Anna Medve: LOGO Elements of Methodology to Develop Structured Programming Terminology, Learning&Exploring with LOGO, EUROLOGO’97 (Proceedings of the Sixth European Logo Conference), 1997 Budapest, 410-412, 1997. Mel02 Stephen J. Mellor, Marc J. Balcer: Executable UML: A Foundation for Model Driven Architecture, Addison-Wesley, 2002.
143
Men05 Menyhárt Ferencz: Termékgyártó vállalat értékesítési folyamatának újratervezése és SAP illesztése, Veszprémi Egyetem, Diploma Dolgozat, 2005. Men06 Tom Mens, Pieter van Gorp: A Taxonomy of Model Transformation, In: Electronic Notes in Theoretical Computer Science, 152(3):125-142, 2006. Mey06 Bertrand Meyer, Karine Arnout: Componentization: The Visitor Example. IEEE Computer (IEEE) 39 (7):23–30, 2006 Mig01 Andrew Miga, Daniel Amyot, Francis Bordeleau, Donald Cameron, Murray Woodside: Deriving Message Sequence Charts from Use Case Maps Scenario Specifications, In: Meeting UML -Tenth SDL Forum (SDL'01), LNCS 2078, Springer, pp.268–287, 2001. Mil02 Dragan Milicev: Automatic Model Transformations Using Extended UML Object Diagrams in Modeling Environments, IEEE Transaction on Software Engineering, 28(4):413-431, 2002. Min98 Henry Mintzberg: Structure et dynamique des organizations (The structuring of organizations). Edition d’Organisation, Paris, 1998. MoDRE12 Model Driven Requirements Engineering Workshop in IEEE International Requirements Engineering Conference Series, 2012. Moh09 Parastoo Mohagheghi, Miguel A. Fernández, Juan A. Martell, Mathias Fritzsche, Wasif Gilani: MDE Adoption in Industry: Challenges and Success Criteria. In Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 October 3, 2008, LNCS 5421, Springer, p.54-59, 2009. Mol05 Molnár Tamás: Követelményelemzés- és specifikálás egy termékgyártó vállalat értékesítési folyamatának újratervezéséhez, Veszprémi Egyetem, Diplomadolgozat, 2005. Mol10 Fernando Molina, Jesús Pardillo, Christina Cachero, Ambrosio Toval: An MDE Modeling Framework for Measurable Goal-Oriented Requirements. In: Int. J. of Intelligent Systems, Wiley, 25(8):757–783, 2010. Mos07 Farida Mostefaoui, Julie Vachon: Design-Level Detection of Interactions in Aspect-UML Models Using Alloy. In: Journal of Object Technology, 6(7):137-165, 2007. Mul05 Pierre-Alain Muller, Philippe Studer, Frédéric Fondement, Jean Bézivin: Platform independent Web application modeling and development with Netsilon. In: Software and System Modeling 4(4):424-442, 2005. Mus02 Gunter Mussbacher, Daniel Amyot: A Collection of Patterns for Use Case Maps, In: First Latin American Conf. on Pattern Languages of Programming (SugarLoafPLoP), UERJ - Série Informática, Special Edition, p.57–82,2002. Mus07 Gunter Mussbacher, Daniel Amyot, Michael Weiss: Formalizing Patterns with the User Requirements Notation. In: Design patterns formalization techniques, IGI Global, p.302–322, 2007. Mus07b Gunter Mussbacher, Daniel Amyot, Michael Weiss: Visualizing Early Aspects with Use Case Maps. LNCS Journal on Transactions on Aspect-Oriented Software Development, LNCS 4620, Springer, p.105–143, November 2007. Mus09 Gunter Mussbacher, Daniel Amyot: Goal and Scenario Modeling, Analysis, and Transformation with jUCMNav, In: 31st Int. Conf. on Software Engineering (ICSE-Companion), ACM, Canada, p.431–432, 2009. Mus10 Gunter Mussbacher, Daniel Amyot, João Araújo, Ana Moreira: Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN): A Case Study. In:Transactions on AspectOriented Software Development VII, LNCS 6210, Springer, p.23–68, 2010. Mus10b Gunter Mussbacher, Aspect-Oriented User Requirements Notation, PhD Thesis, University of Ottawa, 2010. Mus11 Gunter Mussbacher, The Aspect-Oriented User Requirements Notation: Aspects, Goals, and Scenarios, 10th Int. Conf. on Aspect-Oriented Software Development (AOSD’11), March 2011, p.59-60, 2011. Mus12 Gunter Mussbacher, João Araújo, Ana Moreira, Daniel Amyot: AoURN-based Modeling and Analysis of Software Product Lines, In: Software Quality Journal, 20(3-4):645-687, 2012. Myl08 John Mylopoulos: Software Maintenance and Reengineering in the Days of Software Agents. In: 12th European Conference on Software Maintenance and Reengineering, (CSMR 2008), Athens, Greece. IEEE 2008. Myl99 John Mylopoulos, Lawrence Chung, Eric Yu: From Object-oriented to Goal-oriented Requirements Analysis. Communications of the ACM, 42(1):31-37, 1999. NagG10 Nagy Géza: Technológia-fejlesztés e-logisztikai megvalósítások tervezéséhez és integrálásához frontoffice/back-office elven a meglévő ERP rendszerbe. Szakdolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2010. NagN09 Nagy Norbert: ISO/IEC 17799 biztonság kategóriák költségelemzéssel. Diplomadolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2009.
144
NagR10 Nagy Róbert: Hozzáférés-ellenőrzés-, fizikai és környezeti biztonság minta-alapú biztonságfokozatos tervezése B2C típusú rendszerekre az ISO/IEC 17799/27001 és 27002 alapján. Diplomadolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2010. NagT10 Nagy Tibor: Minta-modell a fizikai és környezeti-, valamint a hozzáférés-ellenőrzés biztonságának tervezéséhez az átfedések kiszűrésével az ISO/IEC 17799/27001 és 27002 alapján. Diplomadolgozat, Témavezető: Medve Anna, Pannon Egyetem, Műszaki Informatikai Kar, 2010. Nik09 Oksana Nikiforova, Antons Cernickins, Natalja Pavlova: Discussing the Difference between Model Driven Architecture and Model Driven Development in the Context of Supporting Tools, icsea, p.446451, 2009, Fourth International Conference on Software Engineering Advances, 2009. NuSMV12 NuSMV Model Checker http://nusmv.irst.itc.it OASIS12 OASIS:Organization for the Advancement of Structured Information Standards, 2012. Obe03 Iulian Ober, Susanne Graf, Ileana Ober: Validating timed UML models by simulation and verification. In: SVERTS’03, Workshop on Specification and Validation of UML models for Real Time and Embedded Systems. San-Francisco, October 2003. Obe06 Ileana Ober, Susanne Graf, Iulian Ober: Validation of UML models via a mapping to communicating extended timed automata, Ileana Ober, Susanne Graf and Iulian Ober. Validating timed UML models by simulation and verification. In: International Journal of Software Tools for Technology Transfer (STTT), April, 2006. Springer Verlag, 8(2):128-145, 2006. Obe08 Iulian Ober, Susanne Graf, Yuri Yushtein, Ileana Ober: Timing analysis and validation with UML: the case of the embedded MARS bus manager. In: Innovations in Systems and Software Engineering, 4(3):301-308, 2008. Obe09 Iulian Ober, Stefan Van Baelen, Susanne Graf, Mamoun Filali, Thomas Weigert, Sébastien Gérard: Model Based Architecting and Construction of Embedded Systems, In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008, LNCS 5421, Springer, p.1-4, 2009. Obe10 Ileana Ober, Louis Féraud, Christian Percebois. Dealing with variability within a family of domainspecific languages: comparative analysis of different techniques. In: Innovations System Software Engineering. 6(1-2):21-28, 2010. ODP12 ODP-RM Open Distributed Processing – Reference Model – Enterprise Language, ITU-T 10 Recommendation X.911 (05/05), 2005. OME12 OME http://www.cs.toronto.edu/km/OME/, 2012 OMG00 Richard Mark Soley: OMG SSG Model Driven Architecture, 2000, http://www.omg.org/cgibin/doc?omg/00-11-05 http://www.omg.org/mda, 2012. OMG01 OMG ORMSC Model Driven Architecture - A Technical Perspective, 2001, http://www.omg.org/cgibin/doc?ormsc/2001-07-01, 2012. OMG03 OMG Strategy Study Group MDA Guide Version 1.0.1, 2003, http://www.omg.org/cgibin/doc?omg/03-06-01, 2012. OMG12 OMG Specifications – http://www.omg.org/technology/documents/spec_catalog.htm; Object Management Group – CORBA – Common Object Request Broker Architecture, v3.1.1; – KDM – Knowledge Discovery Metamodel, v1.3; – MOF – Meta Object Facility Core, v1.4.1; – OCL – Object Constraint Language, v2.3.1; – UML – Unified Modeling Language, v2.4.1; – XMI – MOF2XMI Mappin v2.0.1; – IFML – Interaction Flow Modeling Language; – IDL – Interface Definition Languages; – DI – Diagram definition; – QVT – MOF Query / View / Transformation; – CWM – Common Warehouse Metamodel; Object Management Group, BPMN 2.0 Specification; Object Management Group, UML Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE); Object Management Group, UML Profile for Schedulability, Performance and Time. Orb08 Orbán,Gy., Medve,A.: IFx-CADP-SPIN kísérlet, Kutatásjelentés, PE-MIK-IRT-3/08, 2008. Óva07 Óvádi,P., Medve,A.: SAP PM bevezetése, Le Belier Formaöntőde Ajka Magyarország, Kutatásjelentés, PE-MIK-IRT-2/2007. Pär00 Juha Pärssinen, Markku Turunen: Patterns for Potocol System Architecture, In: Proceedings PLoP 2000, 1-26. http://www.hillside.net/plop/plop2k/proceedings/proceedings.html Pär05 Juha Pärssinen: Domain Concepts for Communication Protocols, EUROPLP’2005, http://www.hillside.net/europlop/ Pat08 Ahmed Patel: Editorial: Frameworks for secure, forensically safe and auditable applications. In: J. Computer Standards&Interfaces, Elsevier, 30(4):213-215, 2008 Pat10 András Pataricza. et al.: Workflow-driven Tool Integration Using Model Transformations, In: G.Engels (Ed.) Graph Transformations and Model Driven Engineering, LNCS 5765, Springer, p.224-248, 2010. Pel09 Patrizio Pelliccione, Paola Inverardi, Henry Muccini: CHARMY: A Framework for Designing and Verifying Architectural Specifications. IEEE Trans. Software Eng. 35(3):325-346, 2009.
145
Pen10
Pengcheng Zhang, Henry Muccini, Bixin Li: A classification and comparison of model checking software architecture techniques. Journal of Systems and Software 83(5):723-744, 2010. Per08 Isabelle Perseil, Laurent Pautet: Foundations of a new software engineering method for real-time systems. In: Innovations in Systems and Software Engineering, 4(3):195-202, 2008. Per92 Dewayne E. Perry, Alexander L. Wolf: Fundations for the study of Software Architecture. In: Software Engineering, ACM SIGSOFT, 17(4):40-42, 1992. Pet05 Dorin B. Petriu, C. Murray Woodside: Software performance models from system scenarios. Performance Evaluation, Elsevier, 61(1):65–89, 2005. Pét09 Péter Imre: e-Logisztika és ERP logisztikai modulok integrálásának tervezése munkafolyamat elemzéssel, Diplomadolgozat, Témavezető: Medve Anna, Pnnon Egyetem, MIK, 2009. Pol03 John A. van der Poll, Paula Kotze, Ahmed Seffah, Thiruvengadam Radhakrishnan, Asmaa Alsumait: Combining UCMs and Formal Methods or Representing and Checking the Validity of Scenarios as User Requirements, In: 2003 annual research conf. of the South African Institute of Computer Scientists and Information Technologists (SAICSIT 2003), Johannesburg, South Africa, p.59–68, 2003. Por06 Zoltán Porkoláb, István Zólyomi: A Feature Composition Problem and a Solution Based on C++ Template Metaprogramming, In: Ralf Lämmel, João Saraiva, Joost Visser (Eds.): Generative and Transformational Techniques in Software Engineering, International Summer School, GTTSE 2005, Braga, Portugal, July 4-8, 2005. Revised Papers. Lecture Notes in Computer Science 4143 Springer, p.459-470, 2006. Por09 Joseph Porter, Gabor Karsai, Péter Völgyesi, Harmon Nine, Peter Humke, Graham Hemingway, Ryan Thibodeaux, Janos Sztipanovits: Towards Model-Based Integration of Tools and Techniques for Embedded Control System Design, Verification, and Implementation. In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008, LNCS 5421, Springer, p.20-34, 2009. POS12 POSA Vol.1-5.http://www.cs.wustl.edu/~schmidt/POSA/, 2012 Pou08 Alireza Pourshahid: A URN-Based Methodology for Business Process Monitoring, M.Sc. thesis, EBT, University of Ottawa, Canada, March 2008. Pou09 Alireza Pourshahid, Pengfei Chen, Daniel Amyot, Alan J. Forster, Sepideh Ghanavati, Liam Peyton, and Michael Weiss: Business Process Management with the User Requirements Notation. Electronic Commerce Research, Springer, 9(4):269–316, 2009. Pou10 Alireza Pourshahid, Gunter Mussbacher, Daniel Amyot, Michael Weiss: Toward an Aspect-Oriented Framework for Business Process Improvement. In: Int. J. of Electronic Business, Inderscience Publisers, 8(3):233–259, 2010. Pou12 Alireza Pourshahid, Daniel Amyot, Azalia Shamsaei, Gunter Mussbacher, Michael Weiss: A Systematic Review of Aspect-oriented Methods Applied to Business Process Adaptation, In: Journal of Software, Academy Publisher p.1816-1826, 2012. Pra12 Pragmadev RealTime Developer Studio http://www.pragmadev.com/technology.html. Pra12b Pragmadev RT Developer Studio Survey http://www.pragmadev.com/news/2012SurveyResult_EN.pdf. Ral05 Jolita Ralyté, Colette Rolland, Mohamed Ben Ayed: An Approach for Evolution-Driven Method Engineering. Information Modeling Methods and Methodologies, IGI-Global, p. 80-101, 2005. REF12 Referencia modellek: Open Systems Interconnection (OSI) reference model ISO 1984; Zachmann Framework for Information Systems Architecture http://www.zachman.com/; Reference Model for Open Distributed Processing (RM-ODP) ISO/IEC 10746-1, ITU-T X.901; Enterprise Distributed Object Computing (EDOC) OMG.org/spec, The Open Group Architecture Framework (TOGAF www.opengroup.org/architecture Rio11 Laurent Rioux, Davide Brugali, Sébastien Gérard: First International Workshop on Model Based Engineering for Robotics (RoSym'10). In: Anthony M. Sloane, Uwe Aßmann (Eds.): Software Language Engineering - 4th International Conference, SLE 2011, Braga, Portugal, July 3-4, 2011, Revised Selected Papers. LNCS 6940, Springer, p.400, 2011. Riv09 José Eduardo Rivera, José Raúl Romero, Antonio Vallecillo: Behavior, Time and Viewpoint Consistency: Three Challenges for MDE. In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008, LNCS 5421, Springer, p.60-65, 2009. Rol00 Colette Rolland, Naveen Prakash: From Conceptual Modelling to Requirements Engineering. Special Issue of Annals of Software Engineering on Comparative Studies of Engineering Approaches for Software Engineering,10:151-176, 2000. Roy07 Jean-François Roy: Requirement Engineering with URN: Integrating Goals and Scenarios. M.Sc. thesis, SITE, University of Ottawa, Canada, March 2007 Roy11 Suman Roychoudhury, Jeff Gray, Frédéric Jouault: A Model-Driven Framework for Aspect Weaver Construction. T. Aspect-Oriented Software Development 8:1-45, 2011.
146
RTRT12 Rational Test RealTime http://www.rational.com.ar/tools/testrealtime.html Rus06 Nick Russell, Arthur ter Hofstede, Wil M.P. van der Aalst, Nataliya Mulyar: Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22, 2006. http://workflowpatterns.com/ Sal00 Igor S. Sales, Robert L. Probert: From High-Level Behaviour to High-Level Design: Use Case Maps to Specification and Description Language, In: 18th Brazilian Symp. on Computer Networks (SBRC2000), Brazil, 2000. Sal04 Kassem A. Saleh, Abdulkarim Al-Zarouni: Capturing Non-Functional Software Requirements using the User Requirements Notation, In: 2004 Int. Research Conf. on Innovation in Information Technology (IIT'04), Dubai, p.222–230, 2004. Sal09 Kassem A. Saleh, Ghanem Elshahry: Modeling Security Requirements for Trustworthy Systems. Encyclopedia of Information Science and Technology, In: 2nd edition, IGI Global, p.2657–2664, 2009. Sch00 Douglas C. Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons, 2000. Scr99 William C. Scratchley, Murray Woodside: Evaluating Concurrency Options in Software Specifications, In: Seventh Int. Symp. on Modelling, Analysis and Simulation of Computer and Telecom. Systems (MASCOTS'99), College Park, USA, p.330–338, 1999. SDL12 SDL Forum Society, www.sdl-forum.org, 2012. Sel94 Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object-Oriented Modeling John Wiley & Sons, 1994. Sha10 Azalia Shamsaei, Alireza Pourshahid, Daniel Amyot: Business Process Compliance Tracking Using Key Performance Indicators, In: 6th Int. Workshop on Business Process Design (BPD 2010), LNBIP 66, Springer, p.73–84, 2010. Sha12 Azalia Shamsaei: Indicator-based Policy Compliance of Business Processes, Ph.D. thesis, Dept. of Computer Science, University of Toronto, Canada, 2012. Sha12b Azalia Shamsaei, Daniel Amyot, Alireza Pourshahid, Edna Braun, Eric Yu, Gunter Mussbacher, Rasha Tawhid, Nick Cartwright: An Approach to Specify and Analyze Goal Model Families, In: 7th System Analysis and Modelling (SAM), LNCS 7744, p.34-52, 2013. Sha89 Mary Shaw: Larger Scale Systems Require Higher-Level Abstractions, In: Software Engineering Notes, ACM SIGSOFT, 14(3):143-146, 1989. Sha90 Mary Shaw: Prospects for an Engineering Discipline of Software. IEEE Software, 7(6):15–24, 1990. Sha95 Mary Shaw: Comparing Architectural Design Styles. IEEE Software, 12(6):27–41, 1995. Sha96 Mary Shaw, David Garlan: Software Architectures: Perspectives on an Emerging Discipline. PrenticeHall, 1996. SHI12 SHIELDS Project Consortium, http://www.shields-project.eu, 2012. Sib08 Christophe Sibertin-Blanc, Nabil Hameurlain, Omar Tahir: Ambiguity and structural properties of basic sequence diagrams, In: Innovations in Systems and Software Engineering, 4(3):275-284, 2008. Sim96: Charles Simonyi: The Death of Computer Languages, The Birth of Intentional Programming, http://research.microsoft.com/apps/pubs/default.aspx?id=69540 Som07 Ian Sommerville: Szoftver rendszerek fejlesztése 2. bővített kiadás, Panem Kiadó, Debrecen, 2007. SPIN12 SPIN http://spinroot.com/ Sta11 Agnes Stark-Werner: Model-Based Fault Detection and Isolation using Process Mining. Engineering and Technology, 7(73):851–856. Elsevier, 2011. Stö07 Christoph Hermann Störmer: Software Quality Attribute Analysis by Architecture Reconstruction (SQUA3RE), Ph.D. thesis, Vrije Universiteit, The Netherlands, 2007. Sun00 Gerson Sunyé, Alain Le-Guennec, Jean-Marc Jézéquel: Precise modelling of design patterns, in Proceedings of UML 2000, volume 1939 of LNCS, p.482--496, 2000. Sys12 Systems Modeling Language (SysML), omg.org/spec, 2012. Szi08 Medve,A., Szima,I.: Esettanulmány a POSA2 Szolgáltatáselérés mintanyelv implementálására, Kutatásjelentés, PE-MIK-IRT-5/07, 2007. Szti12 János Sztipanovits: Model Integration Languages. In: Models2012 *Quantitative Reactive Modeling Szy05 Clement Szyperski: The Making of a Software Engineer:Challenges for the Educator,In: 27th International Conference on Software Engineering (ICSE 2005), 15-21 May 2005, St. Louis, Missouri, USA. ACM 2005. Tau08 Telelogic AB: Tau G2 Reference, MSC2SDL Synthesizer Tutorial, Version G2 2.6. 2008. Tep09 Susanna Teppola, Päivi Parviainen, Juha Takalo: Challenges in Deployment of Model Driven Development, In: 4th International Conference on Software Engineering Advances, p.15-20, 2009. http://www.computer.org/csdl/proceedings/icsea/2009/3777/00/3777a015-abs.html Thi08 Yann Thierry-Mieg, Lom-Messan Hillah: UML behavioral consistency checking using instantiable Petri nets. In: Innovations in Systems and Software Engineering, 4(3):293-300, 2008.
147
Tho03
Dave Thomas: UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes, Journal of Object Technology, 2(1):7-12, 2003. Tol06 Juha-Pekka Tolvanen, Jonathan Sprinkle, Jeff Gray: The 6th OOPSLA workshop on domain-specific modeling. OOPSLA 2006 workshop chair's welcome. In: Peri L. Tarr, William R. Cook (Eds.): Companion to the 21th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, Portland, Oregon, USA. ACM, p.622-623, 2006. Tol10 Juha-Pekka Tolvanen, Steven Kelly: Integrating models with domain-specific modeling languages. In: Proceedings of the 10th Workshop on Domain-Specific Modeling (DSM '10), Article 10, p.6. http://www.dsmforum.org/events/DSM10/, 2010. Tom12 Christophe Tombelle, Gilles Vanwormhoudt, Emmanuel Renaux: Reusing Pattern Solutions in Modeling: A Generic Approach Based on a Role Language. In: Anthony Sloane, Uwe Assmann (Eds): Software Language Engineering, LNCS 6940, p.139-159, 2012. Tót07 Tóth,L., Medve,A.: VIATRA kísérlet, Kutatásjelentés, PE-MIK-IRT-3/07, 2007. TOVE12 TOVE Ontology project. http://www.eil.utoronto.ca/enterprise-modelling/tove/ 2012. Tra08 Bruce Trask, Angel Roman. Leveraging Model Driven Engineering in Software Product Line Architectures, In: 12th International Software Product Line Conference, p.373, 2008. Tru09 Ninh Thuan Truong, Thi Mai Thuong Tran, Van Khanh To, Viet HaN Nguyen: Checking the Consistency between UCM and PSM Using a Graph-Based Method, In: 1st Asian Conf. on Intelligent Information and Database System (ACIIDS09), IEEE CS, p.190–195, 2009. Uch03 Sebastian Uchitel, Jeff Kramer, Jeff Magee: Synthesis of Behavioral Models from Scenarios, IEEE Trans. Softw. Engineering, 29(2):99-115, 2003. URN12 URN Virtual Library, http://www.UseCaseMaps.org/pub 2012. Val11 Antonio Vallecillo: On the Combination of Domain Specific Modeling Languages. In: Proceedings ECMFA 2010 Thomas Kühne, Bran Selic, Marie-Pierre Gervais, François Terrier (Eds.): 6th European Conference on Modelling Foundations and Applications, Paris, France, June 15-18, 2010, LNCS 6138, Springer, p.305-320, 2011. Val12 Antonio Vallecillo, Martin Gogolla, Loli. Burgueno, Manuel Wimmer, Lars Hamann: Formal Specification and Testing of Model Transformations. Invited Talk: International School on Formal Methods for the Design of Computer, Communcation, and Software Systems, (SFM 2012), Bertinoro, Italy, June 18-23, 2012; In: Formal Methods for Model-Driven Engineering, Marco Bernardo, Vittorio Cortellessa, Alfonso Pierantonio (eds.): Springer, LNCS 7320 (2012), ISSN: 0302-9743; p.399 – 437, 2012. Var86 Moshe Vardi, Pierre Wolper: Automata Theoretic Techniques for Model Logics of Programs, In: Journal of Computer and System Science, 32(2):182-221, 1986. VIA12 VIATRA. http://www.eclipse.org/viatra2/ 2012. Völ10 Markus Völter: Embedded Software Development with Projectional Language Workbenches, Proceedings of MODELS 2010 and at http://www.voelter.de/data/pub/VoelterEmbeddedSystemsDevelopmentWithProjectionalLanguageWorkbenches.pdf Völ11 Markus Völter: From Programming to Modeling - and Back Again, IEEE Software, 28(6):20-25, 2011. Vrb12 Mira Vrbaski, Dorina C. Petriu, Daniel Amyot: Tool Support for Combined Rule-Based and GoalBased Reasoning in Context-Aware Systems, In: Proceedings 20th IEEE Int. Requirements Engineering Conference (RE’12), p.335-336, 2012. Wal09 Walderhaug2008 Ståle Walderhaug, Erlend Stav, Marius Mikalsen: Experiences from Model-Driven Development of Homecare Services: UML Profiles and Domain Models. In: Michel R. V. Chaudron (Ed.): Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, 2008, LNCS 5421, Springer, p.199-212, 2009. Wal11 Tobias Walter, Fernando Silva Parreiras, Steffen Staab, Jürgen Ebert: Joint Language and Domain Engineering. In: Proceedings ECMFA 2010 Thomas Kühne, Bran Selic, Marie-Pierre Gervais, François Terrier (Eds.): 6th European Conference on Modelling Foundations and Applications, Paris, France, June 15-18, 2010, LNCS 6138, Springer, p.321-336, 2011. Wei05 Michael Weiss, Daniel Amyot: Business Process Modeling with URN. International Journal of EBusiness Research, 1(3):63-90, 2005. WF12 Workflow Management Coalition www.wfmc.org 2012. Whi11 Jon Whittle: What do 449 MDE Practitioners Think About MDE? In: Michel R. V. Chaudron, Marcela Genero, Silvia Abrahão, Parastoo Mohagheghi, Lars Pareto (Eds.): Proceedings of the First Workshop on Experiences and Empirical Studies in Software Modelling, MODELS'11 Workshop - EESSMod 2011, Wellington, New Zealand, October 17, 2011. CEUR 785, CEUR-WS.org, 1, 2011. Whi12 Jon Whittle, John Hutchinson: Mismatches between Industry Practice and Teaching of Model-Driven Software Development. In: Jörg Kienzle (Ed.): Models in Software Engineering - Workshops and
148
Symposia at MODELS’2011, Reports and Revised Selected Papers. LNCS 7167, Springer, p.40-47, 2012. Wim11 Manuel Wimmer, Gerti Kappel, Angelika Kusel, Werner Retschitzegger, Johannes Schoenboeck, Wieland Schwinger: From the Heterogeneity Jungle to Systematic Benchmarking. In: Jürgen Dingel, Arnor Solberg (Eds.): Models in Software Engineering - Workshops and Symposia at MODELS 2010, Oslo, Norway, October 2-8, 2010, Reports and Revised Selected Papers. LNCS 6627, Springer, p.150164, 2011. Wol12 Celia Wolf, Paul Harmon. The state of BPM Market, BPM Trends, 2012 Wu06 Weihang Wu, Tim Kelly: Managing Architectural Design Decisions for Safety-Critical Software Systems, In: 2nd Int. Conf. on the Quality of Software Architectures (QoSA 2006), LNCS 4126, Springer, p.59–77, 2006. XML12 XML W3C. http://www.w3.org/TR/REC-xm Yu00 Erik Yu, Yiung. Yu, Lee Liu: OME – Organization Modelling Environment, University of Toronto, 2000. http://www.cs.toronto.edu/km/ome/ Yu08 Huafeng Yu, Abdoulaye Gamatié, Éric Rutten, Jean-Luc Dekeyser: Safe design of high-performance embedded systems in an MDE framework. Innovations in Systems and Software Engineering, 4(3):215222, 2008. Yu95 Erik Yu: Modelling strategic relationships for processreengineering. Ph.D. thesis, Dept. of Computer Science, University of Toronto, Canada, 1995. Yue11 Tao Yue, Lionel C. Briand, Yvan Labiche: An Automated Approach to Transform Use Cases into Activity Diagrams. In: Proceedings ECMFA 2010 Thomas Kühne, Bran Selic, Marie-Pierre Gervais, François Terrier (Eds.): 6th European Conference on Modelling Foundations and Applications, Paris, France, June 15-18, 2010, LNCS 6138, Springer, p.337-353, 2011. Zac87 John Zachman: A Framework for Information Systems Architecture, IBM Systems Journal, 26(3):276293, 1987. Zha07 Jing Zhang, Thomas Cottenier, Aswin van den Berg, Jeff Gray: Aspect Composition in the Motorola Aspect-Oriented Modeling Weaver. Journal of Object Technology, 6(7):89-108, 2007. Zha08 Tian Zhang, Frédéric Jouault, Jean Bézivin, Xuandong Li: An MDE-based method for bridging different design notations. In: Innovations in Systems and Software Engineering, 4(3):203-213, 2008. Zha11 He Zhang, Lin Liu, Tong Li: Designing IT systems according to environmental settings: A strategic analysis framework. The Journal of Strategic Information Systems, Elsevier, 20(1):80-95, 2011. Zha12 Rixin Zhang, Ajay Krishnan: Using Delta Model for Collaborative Work of Industrial Large-Scaled E/E Architecture Models. In: Jon Whittle, Tony Clark, Thomas Kühne (Eds.): Model Driven Engineering Languages and Systems, 14th International Conference, MODELS 2011, Wellington, New Zealand, October 16-21, 2011. Proceedings. LNCS 6981 Springer, p. 714-728, 2012. Zsc09 Steffen Zschaler, Pablo Sánchez, João Pedro Santos, Mauricio Alférez, Awais Rashid, Lidia Fuentes, Ana Moreira, João Araújo, Uirá Kulesza: VML* - A Family of Languages for Variability Management in Software Product Lines. In: Mark van den Brand, Dragan Gasevic, Jeff Gray (Eds.): Software Language Engineering, Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009, Revised Selected Papers. LNCS 5969, Springer, p.82-102, 2010.
149
7
MELLÉKLETEK
7.1
Rövidítésjegyzék
AoURN
Aspect oriented User Requirements Notation
API
Application Programming Interface
ASN.1
Abstract Notation One
ASP
Abstract Service Primitive
ATS
Abstract Test Suite
BABOK
Business Analysis Body of Knowledge
BPM
Business Process Model
BPMN
Business Process Model and Notation
BUSITEV Business and Information Technology Evolution CADP
Construction and Analysis of Distributed Processes
CD
Coding/Decoding
CH
Component Handling
CIM
Computation Independent Model
CORBA
Common Object Request Broker Architecture
COTS
Commercial-Off-The-Shelf
CWM
Common Warehouse Metamodel
CSD
Composite Structure Diagram
DCL
Deployment Configuration Language
DI
Diagram Interchange
DSM
Microsoft Domain Specific Modelling
DSML
Domain-Specific Modelling Languages
EMF
Eclipse Modeling Framework
ETSI
European Telecommunications Standards Institute
FIFO
First In First Out
FR
Functional Requirements
GMSC
Gateway Mobile Switching Centre
GOF
Gang of Four- Design Pattern
GPL
General-purpose Languages
GRL
Goal-oriented Requirement Language
GSM
Global System for Mobile Telecommunication
HMSC
High-level Message Sequence Chart
IDL
Interface Description Language
IFML
Interaction Flow Modeling Language
IOD
Interaction Overview Diagram
ISO
International Organization for Standardization
ITIL
Information Technology Infrastructure Library
ITU
International Telecommunication Union
ITU-T
International Telecommunication Union, – Telecommunication Standardization Sector
150
KDM
Knowledge Discovery Metamodel
LTL
Linear Temporal Logic
MDA
Model Driven Architecture
MOF
Meta Object Facility
MSC
Message Sequence Chart
NFR
Non-Functional Requirements
ODBC
Open DataBase Control
ODL
Object Definitional Language
OMC
Operation Centre Management
OME
Organization Modelling Environment
OMG
Object Management Group
OO
Obiect Oriented
OSI
Open System Interconnection
PDU
Protocol Data Unit
PIM
Platform Independent Model
POSA
Pattern-Oriented Software Architecture
PSM
Platform Specific Model
QVT
Query View Transformation
RM-ODP
Reference Model - Open Distributed Processing
SACP
Service Access and Configuration Pattern
SD
Sequence Diagram
SDL
Specification and Description Language
SMS
Short Message Servicel
SMV
Symbolic Model Checker
SPT
SDL Patterm Tool
SUT
System Under Test
SysML
System and Software Modeling Language
TC
Test Control
TTCN
Testing and Test Control Notation
TTCN-2
Tree and Tabular Combined Notation
TTCN-3
Testing and Test Control Notation Version 3
UCM
Use Case Map
UML
Unified Modeling Language
URN
User Requirements Notation
URN-FR
User Requirements Notation – Functional Requirements
URN-NFR User Requirements Notation – Non-Functional Requirements W3C
World Wide Web Consortium
WfMC
Workflow Management Coalition
XMI
XML Metadata Interchange
XML
eXtensible Markup Language
151
7.2
Mellékletek a 2. fejezethez
35. ábra KobrA módszertan modell elveiből a fejlesztés dimenziói: dekompozicíó, kompozicíó, absztrakció, konkretizáció, generikus, specifikus (forrás: [Atk02])
36. ábra Verimag IFx 2.0 Toolbox elemei (forrás: [Med12b])
152
7.3
Mellékletek a 3. fejezethez
37. ábra POSA2 architektúra minták osztályozása (ábra forrása: Sch00 )
38. ábra GOF programtervezési minták osztályozása (ábra forrása: Gam95 )
153
39. ábra POSA2 architektúra mintanyelv: „Szolgáltatás elérési és konfigurálási minták” szürke, az „Eseménykezelési minták” kék, a „Szinkronizációs minták” narancssárga, a „Konkurens minták pink színnel (forrás Sch00)
154
40. ábra GOF programtervezési minták mintanyelve (forrás Gam96)
155
41. ábra Mintanyelv szövése az áttekintő kölcsönhatás (IO) diagram eszközeivel, az architektúra minta metódusaihoz illesztve a programtervezési mintákat (itt Observer, Interpreter minták )
156
42. ábra Mintanyelv szövése: MSC Observer diagram (felső) a jelentésadáshoz a felügyelt komponensől amely megfelel az Observer mintának (CompConfig és Client között) amihez információ kell a felügyelt komponensről, amihez az
Observer_1 mintát alkalmazzuk az MSC Status diagrammal (alsó). A részlet
implementálása végül Observer az Observerben, más-más szereplők között.
157
43. ábra GMSC híváskezelés funkció együttműködés diagramjai (felső és alsó ábra)
158
44. ábra Memento (alsó ábra) és Interpreter (felső ábra) GOF minták alkalmazása a POSA2 Configurator szerepre
159
7.4
Mellékletek a 4. fejezethez
13. táblázat Use Case Description Template (forrás: Gro05, 32. o.)
14. táblázat Operation Description Template (forrás: Gro05, 42.o.)
160
15. táblázat Feladatok és részfeladatok űrlap – Fedezetvizsgálat folyamat – példa (UCM modell a 28. ábrán)
1. 2.
3. 4. 5.
Megnevezés/ kategória Leírás
Elsődleges/Másodlagos szereplők Eredmény felhasználója Korlátok
6.
Kapott bejövő információk
7.
8.
Szolgáltatás elvárt működésben, információk és eredmények Üzenetek
9.
Olvasások
10.
Változtatások
11.
Szabályok
12.
Elvárások
13.
Sikeres működés
14.
Szolgáltatás hiba esetén Alap műveletvégzés
15.
Fedezet Vizsgálat A bejövő rendelések ellenőrzése, a rendelt anyagok volumeneinek és a mi raktárkészletünknek az egyeztetése. Amennyiben hiány van a készleteinkben, a rendelések korrigálása, hogy csak azok a rendelések menjenek el szállítási megbízásban a nágelhez, amit ki is tudunk szállítani. Elsődleges: Vevő, Fedezet vizsgáló, Nágel Másodlagos: kereskedők Nágel Forecast pontossága, készletadatok pontossága, statisztikai adatok megbízhatósága, Forecast adatok időben érkezik-e, felszállított termékek minősége Elsődlegesen: Készletszintek (kiadható, nem kiadható készlet), összes bejövő rendelés + felszállításra kerülő termékek Jó forecast, pontos adatrögzítés, pontos készletek, elérhető kereskedők és gyors válaszaik - nincs hiány, - hiány van, - részben van hiány, - dedikálható a rendelés rövidebb szav. időre, és így nincs hiány, - dedikálható a rendelés rövidebb szav. időre és így részben van hiány Készleteket a Nágel küld – BBNI, rendelések – EXACT, kötbér adatok (mint figyelembe veendő szempont a döntésnél) – EXCEL, felmenő készletek – PAPÍR ALAPÚ ADATHORDOZÓ, dedikálható tételek – TELEFONOS BEMONDÁS A 11. pontokat figyelembe véve, a fedezet vizsgálóknak van joguk dönteni, hogy ki kapjon terméket (jól értelmeztem ezt a pontot??) Hiány esetén dönteni az alábbiak figyelembe vételével: - kötbérez-e, és milyen mértékben (ha kötbérez, lehetőleg kiszolgálni) - hányszor nem szolgáltuk ki (ha egymás után többször, lehetőleg kiszolgálni) - elégedett e (ha többszöri szállítás meghiúsul, és már mérges, lehetőleg kiszolgálni) - hány túranapja van (ha kevés, és soká van lehetőségünk a hiányt pótolni, lehetőleg kiszolgálni) - ’fontos’ vevő-e (ha igen, lehetőleg kiszolgálni) - elfogadja-e a rövidebb szav. időt (ha igen, dedikálni) Pontos forecast és készlet adatok, a kereskedők elérhetők legyenek a folyamat során, a felszállított termék minősége jó legyen, dedikáláshoz szükséges információk jussanak el a fedezetvizsgálókhoz Ha a letisztított rendelések hibátlanul eljutottak a Nágelhez, és lehetőség szerint nem volt hiányunk semmiből Javítani a rendelést vagy visszaigazolást küldeni a vevőnek, és a kérését újra megpróbálni teljesíteni 1. Vevői rendelések átvétele 2. készletadatok átvétele 3. egyeztetni a rendeléseket a készlettel 4. hiány esetén a lehetőségeket megvizsgálni (1: ha van úton a hiányzó termékből, és az autó időben indult- azaz a készlet időben felér mégkielégíthető e? 2: ha csak rész mennyiség van, csökkenteni kell a mennyiséget (megvizsgálva olyan szempontokat hogy pl milyen mértékben kötbérez, vagy mennyire elégedetlen, milyen régen volt kiszolgálva, milyen gyakran van túranapja azaz milyen gyorsan lehet pótolni az elmaradt mennyiséget, 3: ha rövidebb szav idővel van a
161
16.
Kivételes műveletvégzés
17.
Minőségi elvárások
18. 19.
Erőforrások Egyidejű műveletek
20.
Kiterjesztő műveletek
21.
Végcél
készletünkön mint amit garantálunk meg kell vizsgálni hogy a vevő átveszi e a rövidebb szav idős terméket, azaz dedikálható e a termék (ez a telefonon egyeztetés a vevővel) 4: teljes hiány esetén az összes rendelésnek a hiányzó cikkét nullázni (lehúzni a rendelésről) 5. a letisztított rendeléseket elküldeni a nágelnek, aki kiszolgálja a vevőket 1. Vevői rendelések átvétele 2. készletadatok átvétele 3. egyeztetni a rendeléseket a készlettel 4. hiány esetén a lehetőségeket megvizsgálni a, van úton (papír ellenőrzése) b, csak rész mennyiség (vizsgálni ki kapja) c, rövidebb szav idő van? (telefonon egyeztetni a kereskedőkkel, hogy mehet e a dedikálás) d, teljes hiány (nullázni) 5. a letisztított rendeléseket elküldeni a nágelnek Forecast adatok időben álljanak rendelkezésre, és pontosak legyenek (a hiány elkerülése, és a túl sok készlet elkerülése miatt), a termék jó minőségben menjen fel, a rendelések pontosan legyenek rögzítve, a készletadatok pontosak legyenek, a rendelések rögzítése fejeződjön be időben (hogy legkésöbb du 3-ig a Nágelhez érjenek a letisztított rendelések, szükség esetén a kereskedők a fedezet vizsgálat alatt legyenek elérhetőek, minden dedikálással kapcsolatos információ érjen el a fedezet vizsgálókhoz Excel, Exact, fedezet vizsgálók, szükséges papírok,Kereskedők, Nágel –Szükség esetén a kereskedők telefonon egyeztetnek a vevővel, hogy dedikálható e rövidebb szav időre a termék. A telefonálás eredményét használom (jelenleg ha nincs válasz a fedezet vizsgálat végéig, a dedikálást automatikusan semmisnek vesszük) – dedikálás: a dedikálandó rendeléseket a VT-nél a raktáros lányoknak mondom, akik a fedezet vizsgálatom közben dedikálnak, ezzel is segítve, hogy előbb végezzek (rövid művelet … csak sok .. mindig előbb végeznek, mint a fedezet vizsgálattal Én a PT-nél. A dedikálást is a fedezet vizsgálók csinálják.) -Szükség esetén a kereskedők telefonon egyeztetnek a vevővel, hogy dedikálható e rövidebb szav időre a termék. A telefonálás eredményét használom (jelenleg ha nincs válasz a fedezet vizsgálat végéig, a dedikálást automatikusan semmisnek vesszük) - dedikálás: a dedikálandó rendeléseket a VT-nél a raktáros lányoknak mondom, akik a fedezet vizsgálatom közben dedikálnak, ezzel is segítve, hogy előbb végezzek (rövid művelet … csak sok .. mindig előbb végeznek mint a fedezet vizsgálattal Én, a PT-nél a dedikálást is a fedezet vizsgálók csinálják, ott a 2. gondolatjel nem léteznik Minden vevő ki legyen szolgálva, és ne legyen a készlet sem sok, sem kevés
162
16. táblázat Tevékenység © forgatókönyvűrlap (Alapműveletek kapcsolatainak leírása a művelet űrlapokon)
B
A
Alá-fölé rendelt előfeltételes tevékenység Elindító/igénylő/ művelet (lehet B, E, D)
Elindító/válaszoló_bedolgozó művelet (lehet E)
Adatrögzítés vége
Bedolgozó művelet: Kereskedők telefonálnak dedikálás miatt, - raktárirodás lányok dedikálnak
(a)
(b)
C Fő tevékenység TÁRGY: Tevékenység, Feladat neve Fedezet vizsgálat Kezdőművelet neve: adatok átvétele (rendelések, dedikálások, készletek, uton levő készletek) További műveletek neve, kategóriája 6. egyeztetni a rendeléseket a készlettel 7. hiány esetén a lehetőségeket megvizsgálni 8. Rendeléseket javítani Befejező művelet A letisztított rendeléseket átküldeni a Nágelhez
D
E
Alá-fölé rendelt utófeltételes tevékenység Eredményt Bedolgozó felhasználó művelet, művelet, kiközvetített szereplő részművelet (lehet A, E) végzés Termelés Termelés
(c)
45. ábra e-kereskedelem evolúciós fejlesztéséhez technológiai és biztonsági stratégia fokozatok
163
46. ábraURN Link szerepe és alkalmazása stratégiái döntések megjelenítésére és átjárhatósághoz
47. ábra UCM folyamattérkép információbiztonság nélkül (balra) és GRL célmodellekből integrálással (jobbra) Illusztráció a struktúra elemek felszaporodására az információbiztonság funkciókhoz
48. ábra GRL célfában stratégia kiértékelés – ISO/IEC 27001/2 – Üzletmenet folytonosság (e-kereskedelemhez) közepes biztonság
164
17. táblázat Use Case Description űrlap információszerzés esetéről mobil eszközzel ( URN modellezés 4.3.1)
Use Case Name: Actors: Description:
Product Information
Business Actor Outcome of this use case to get relevant information about the given product E.g.: product name, price, amount, statistic information
Trigger: Preconditions:
Post conditions: Regular Flow:
Alternative Flows:
an event, to get product information by business actors 1. Server side components are installed and properly configured 2. Application is already installed on users smart phone or mobile device 3. Smart phone or mobile device with camera function 4. Smart phone or mobile device with network connection (GSM and/or Wi-Fi) Actor receives the product information via smart phone or mobile device Actor manipulates the received product information via smart phone or mobile device with multi touch menu Actor runs the application on his/her smart phone or mobile device Actor takes a picture or provide a picture OR a video stream Server side component process the input picture or video stream Server side component sends back the product information The client side presents the product information Actor navigates the different level of structured product information by structured touch menu system Normal Flow Step 1. a photo can be provided as a picture or video stream Alternative Flow Step 1.
product ID (i.e. bar code) can be provided as a picture or video stream Alternative Flow Step 2.
product ID (i.e. bar code) can be provided as a user input) Exceptions:
If the network connection is not functioning properly An error messages appears with the description of this error case If the server components are not functioning properly An error messages appears with the description of this error case If the server side component doesn't recognize the photo Use Case resumes on Alternative Flow Step
1.
If the server side component doesn't recognize the product ID Use Case resumes on Alternative Flow Step
2.
If the server side component doesn't recognize the product ID An error messages appears with the description of this error case Frequency of Use: Special Requirements:
1000 per a day Performance requirement Security requirement
Assumptions: Exploitation possibilities
Mobil devices integration into enterprise applications to get informations
165
49. ábra GRL célfa adatcseréhez mobil készülékkel üzleti folyamatban szerver oldali alkalmazáshoz (teljes modell)
URN Link Mobil klenstől UCM irányba
50. ábra A 49. ábra GRL célfa részlete: kliens oldal, URN Link átjárhatóságra a megvalósításokhoz Az erőforrásokra nézve nem véglegesíthető a megvalósítástechnológiák eldöntése előtt
51. ábraArchitektúra nézet a követelmény modell (52. ábra) újraszabásával és modularizálásával (sub-map)
166
URN Link komponensektől GRL irányba
52. ábra UCM funkcionális modell használati esetekkel: piros szín a forgatókönyv (adatküldés/feldolgozás/válasz)
167
53. ábra MSC/UML SD –automatikus modelltranszformáció az 52. ábra forgatókönyvéből
168
URN Link mobil klienstől GRL irányba
54. ábra Minőségkövetelmények teljesülése (4.3.1 alpont) forgatókönyvben és ennek transzformációja (55.ábra)
55. ábra MSC / UML SD – automatikus modelltranszformáció az 54. ábrán látható UCM forgatókönyvből
169
8
ÖSSZEFOGLALÓ A modellvezérelt fejlesztési irányzat (MDE) megkerülhetetlen a szoftverkrízis jelenség
leküzdéséhez.
A
szoftverrendszerek
támogatásával
elérhető
lehetőségek
újabb
rendszerfejlesztésekkel növelik a hatékonyságot és versenyképességet, nemcsak a vállalatok számára. Így a meglévő rendszerek állandó fejlődésben vannak azért, hogy lépést tartsanak az újabb technológiákkal és a meghatározó piaci szereplők működésmódjával, ezért a változáskezeléshez szükséges továbbfejleszteni az információs technológiák rendszereit és az információs rendszereket, egymással összehangoltan. Mindezekhez módszerek, technikák, fejlesztőeszközök és az érdekelt felek együttműködése szükséges. A komponens-elvű szoftverfejlesztés kutatása hosszantartó hathatós eredményeket hozott a rendszerek és szoftverrendszerek fejlesztésébe minden területen. Ennek automatizálási törekvései a megszokottól eltérő paradigmaváltáshoz vezettek: a modellvezérelt architektúra (MDA) irányzathoz, amely magasabb absztrakciós szinten a modellezésre irányul, ebben a modellezés technikáira, termékeire, folyamatára, és automatizálásra. Az MDA egységesíti a modellszintű újrafelhasználást, a munkafolyamatot, és a termékek osztályozását. A modellvezérelt fejlesztési (MDE) irányzat az MDA irányzatot hatékonyabbá teszi, előtérbe helyezve a komponenselvet és a szakterület-specifikus technológiákat az újrafelhasználásban, a rendszerjellemzők osztályozását (aspektusok) a termékek osztályozásában, és megtartva az MDA modellezés technikákat az automatizáláshoz. A rendszerek fejlesztésében minket a jóság, biztonság és továbbfejlesztés foglalkoztat, azaz a változáskezelés, amely mindig nagyon kiterjedt rendszerösszetevőket érinthet, ezért a modellvezérelt fejlesztési irányzat követése az előnyös. Az eredményeink ebben a dolgozatban a biztonság tekintetében a szabványok alkalmazására, a szoftvertermékek jóságára,
és
az
információbiztonság
tervezhetőségére
vonatkoznak.
A
rendszerek
továbbfejlesztésére nézve az eredményeink a szoftvertervezési minták újrafelhasználására, az üzleti folyamatok modellezésére és
az alkalmazható technológiákra vonatkoznak.
Technikailag az eredményeink módszerfejlesztések a technológiai sor szervezésére modellvezérelt szoftverfejlesztéshez, módszertanok újrafelhasználható modellgyűjtemények fejlesztéséhez és alkalmazásához, modellezési technikák és űrlapok a végfelhasználók és a tervezők számára az üzleti folyamatokra alapozott modellvezérelt követelményfejlesztéshez. A továbbfejlesztésben absztrakciós szintet növelünk a folyamatok szabályozásában és az újrafelhasználható mintagyűjteményben az üzleti minták, AoURN és LTL alkalmazásával. 170
9
SUMMARY Model Driven Engineering paradigm is indispensable to overcome the software crisis. The
possibilities obtained by supports of software systems enable further investments in systems to rise efficiency and competitively, at any domain. As a consequence, existing systems evolve permanently to keep up with advanced technology and the structure dynamic of organizations in competition. Change management requires evolving the information systems and the system of information technology in coordination. These require methods, techniques, tools, and a cooperative work of interested parties. Component-based software engineering research has long-lasting and efficient results for software systems development at any domain. Its automation has resulting an unusual paradigm change: the model driven architecture (MDA) paradigm, whose trends are on modelling at high abstraction levels, on modelling techniques, products, and processes. MDA has unified the reuse at model level, the development process, and the classification of products, defined the type of modelling techniques. The model driven engineering (MDE) paradigm has resulted in more efficient MDA trends, putting in horizon reuse with domainspecific technology and components, and the classification of products according to system aspects, following the MDA modelling techniques types for the modelling process. We are motivated in systems development for evolution and security i.e. the changes management which relates to an extensive number of components of the system, for this reason it is advantageous to follow model driven engineering. Our results presented in this dissertation as regards security are the usage of standards, the correctness of software products, and the integrated design of information security. The results presented as regards evolution are the reuse of software design patterns (architectural, design, and domainspecific), the modelling of business processes, and the technology choice. Technically, our results are the method engineering for composing the technological line for model driven development processes, methodologies for development and the reuse of reusable model repository of patterns, modelling techniques for end-users and developers for business process modelling and business process-based model driven requirements engineering. Further research plans are to raise the abstraction level of business processes controls, and of the frameworks of patterns’ models by applying business analysis patterns, AoURN, and LTL.
171
