Végrehajtható UML

A Wikipédiából, a szabad enciklopédiából

A végrehajtható UML (xtUML vagy xUML) egyszerre szoftverfejlesztési módszer és egy rendkívül absztrakt szoftvernyelv. Először 2002-ben írták le a Végrehajtható UML: A modellvezérelt architektúra alapja című könyvben.[1] A nyelv "az UML (Unified Modeling Language) grafikus jelölés egy részhalmazát kombinálja végrehajtható szemantikával és időzítési szabályokkal".[2] Az Executable UML módszer a Shlaer-Mellor módszer utódja.[3]

A végrehajtható UML modellek "futtathatók, tesztelhetők, hibakereshetők és mérhetők a teljesítmény szempontjából",[2] és egy kevésbé absztrakt programozási nyelvre fordíthatók egy adott megvalósítás céljára.[4] A végrehajtható UML támogatja a modellvezérelt architektúrát (MDA) a platformfüggetlen modellek specifikálásával és a platformfüggetlen modellek platformspecifikus modellekké történő összeállításával.[5][6]

Áttekintés[szerkesztés]

A végrehajtható UML magasabb absztrakciós szintet jelent, mint a harmadik generációs programozási nyelvek. Ez lehetővé teszi a fejlesztők számára, hogy az alkalmazás absztrakciós szintjén fejlesszenek.[7] A Végrehajtható UML célja az aggodalmak szétválasztása. Ennek célja az újrafelhasználás megkönnyítése és a szoftverfejlesztés költségeinek csökkentése. Ez azt is lehetővé teszi, hogy a végrehajtható UML tartományok platformokon átívelőek legyenek. Ez azt jelenti, hogy nem kötődik semmilyen konkrét programozási nyelvhez, platformhoz vagy technológiához.

A végrehajtható UML lehetővé teszi a platformfüggetlen modellek (PIM) platform-specifikus modellekké (PSM) történő lefordítását is. A végrehajtható UML módszer lehetővé teszi a modell szellemi tulajdonként történő értékelését, mivel a modell a problématerület teljes mértékben futtatható megoldása.

A műveleteket a műveleti nyelven kell megadni. Ez azt jelenti, hogy a végrehajtható UML-modellekből automatikusan generált megvalósítási kódot optimalizált formában lehet kiadni.

A végrehajtható UML célja, hogy végrehajtható kódként és dokumentációként is szolgáljon. A modellek a problématér grafikus, futtatható specifikációját jelentik, amelyet egy célmegvalósításba fordítanak. Céljuk, hogy ember által is olvasható legyen.

Végrehajtható UML építőelemek[szerkesztés]

Egy rendszer több tárgykörből áll, amelyeket a végrehajtható UML kifejezéssel domaineknek nevezünk. A végrehajtható UML-t arra használják, hogy egy tartományt a tárgya absztrakciós szintjén modellezzenek, függetlenül a megvalósítással kapcsolatos aggályoktól. Az így kapott tartománymodellt a következő elemek képviselik:

  • A domain-diagram a modellezett domaint és annak más domainektől való függőségeit mutatja be.
  • Az osztálydiagram meghatározza a tartomány osztályait és osztálykapcsolatait.
  • Az állapotdiagram meghatározza egy osztály vagy osztálypéldány állapotait, eseményeit és állapotátmeneteit.
  • A műveleti nyelv meghatározza a modellelemeken feldolgozást végző műveleteket vagy műveleteket.

Domain diagram[szerkesztés]

A végrehajtható UML megköveteli a rendszer területeinek (más néven: szempontok[8] vagy aggodalmak) azonosítását. "Minden egyes tartomány egy önálló világ, amely fogalmi entitásokat tartalmaz"[9] Minden tartomány a rendszer többi tartományától függetlenül modellezhető, lehetővé téve az aggodalmak szétválasztását. Egy automatizált pénztárgéprendszer esetében például a következő tartományok lehetnek:

  • Az automata pénztárgép üzleti logikájának alkalmazási tartománymodellje. A rendszer biztonságával kapcsolatos különböző kérdések (például hitelesítés és titkosítás) biztonsági tartományi modellje. A külső adatfelhasználás módszereinek adat hozzáférési tartománymodellje. A naplózási tartománymodell a különböző módszerekről, amelyeken keresztül a rendszer naplózhat vagy naplóznia kell az információkat. A felhasználói felület tartományi modellje a felhasználó és a rendszer közötti interakciókról. A végrehajtható UML-modellnek a rendszer hardver- és szoftverplatformjain való megvalósításának architektúra-tartománymodellje.

Az aggályok szétválasztása lehetővé teszi, hogy az egyes tartományokat a rendszer többi tartományától függetlenül fejlesszék és ellenőrizzék a megfelelő tartományi szakértők.

A tartományok közötti kapcsolatokat hidaknak nevezik. "A híd a tartományok közötti rétegfüggőség".[10] Ez azt jelenti, hogy a tartományok követelményeket támaszthatnak más tartományokkal szemben. Ajánlott, hogy a hidakról a különböző tartományi szakértők állapodjanak meg.

Egy tartományt megvalósítottként lehet megjelölni, hogy jelezze, hogy a tartomány létezik, és nem kell modellezni. Például egy MySQL adatbázist használó adatelérési tartományt realizáltként kell megjelölni.

Osztálydiagram[szerkesztés]

A modellezendő területre jellemző fogalmi entitások, például kézzelfogható dolgok, szerepek, események, interakciók és specifikációk osztályokba absztrahálódnak. Az osztályok attribútumokkal és műveletekkel rendelkezhetnek.

Az ezen osztályok közötti kapcsolatokat asszociációkkal és általánosításokkal jelezzük. Egy asszociáció további absztrakciót igényelhet asszociációs osztályként.

Az osztálydiagramra vonatkozó korlátozások mind az Action Language, mind az Object Constraint Language (OCL) nyelven leírhatók.

A végrehajtható UML-módszer korlátozza a végrehajtható UML-osztálydiagramban használható UML-elemeket.

A végrehajtható UML-osztálydiagram célja, hogy a tartományra vonatkozó információkat tárjon fel. Az állapotdiagramok túl nagy komplexitása jó indikátor arra, hogy az osztálydiagramot át kell dolgozni.

Állapotdiagram[szerkesztés]

Az osztályok életciklusokkal rendelkeznek, amelyeket a végrehajtható UML-ben állapotdiagrammal modellezünk. Az állapotdiagram meghatározza az osztály viselkedését meghatározó állapotokat, átmeneteket, eseményeket és eljárásokat.

Minden állapothoz csak egy eljárás tartozik, amely az adott állapotba való belépéskor végrehajtásra kerül. Egy eljárás akciókból áll, amelyeket egy akciónyelven határozunk meg.

Akciónyelv[szerkesztés]

Az osztály- és állapotmodellek önmagukban csak statikus képet adhatnak a tartományról. Ahhoz, hogy egy végrehajtható modellel rendelkezzünk, módot kell találni az osztálypéldányok létrehozására, asszociációk létrehozására, az attribútumokkal való műveletek elvégzésére, az állapotesemények hívására stb. A végrehajtható UML-ben ez egy olyan akciónyelv segítségével történik, amely megfelel az UML akciószemantikának.

Az Action Semantics 2001-ben került az UML specifikációba. Az Action Semantics RFP a Shlaer – Mellor módszert támogató, korábbi cselekvési nyelveken végzett munkára épült. A meglévő cselekvési nyelvek: Object Action Language (OAL), Shlaer – Mellor Action Language (SMALL), Action Specification Language (ASL), Model Action Specification Language (MASL),[11][12] That Action Language (TALL), Starr's Concise Relational Action Language (SCRALL), platformfüggetlen cselekvési nyelv (PAL) és PathMATE cselekvési nyelv (PAL). A SCRALL az egyetlen, amely grafikus műveleti nyelv.

Modell tesztelése és végrehajtása[szerkesztés]

Miután egy tartományt modelleztünk, a modell futtatásával a célmegvalósítástól függetlenül tesztelhető. Minden egyes tartomány bármely más tartománytól függetlenül ellenőrizhető és validálható. Ez lehetővé teszi, hogy az észlelt hibák a tartományhoz kapcsolódjanak, és függetlenek legyenek a rendszer egyéb szempontjaitól.

Az ellenőrzés magában foglalja a modellek emberi felülvizsgálatát, amelyet az adott terület szakértői végeznek, valamint a végrehajtható UML szemantikájának automatikus ellenőrzését, azaz annak ellenőrzését, hogy a végrehajtható UML modell megfelel-e a végrehajtható UML metamodellnek.

A validálás jellemzően egy végrehajtható UML-eszköz használatát jelenti a modell végrehajtásához. A végrehajtás történhet a modell összeállítása előtt vagy után.

Modell-összeállítás[szerkesztés]

A célmegvalósításon történő végrehajtás támogatása érdekében a tartománymodellt kevésbé absztrakt formába kell fordítani. Ezt a fordítási folyamatot modell-kompilációnak nevezzük. A legtöbb modellfordító egy ismert programozási nyelvet céloz meg, mert ez lehetővé teszi a meglévő fordítói technológiák újrafelhasználását.

A tartományi modellek célmegvalósítási okokból történő optimalizálása csökkenti az absztrakciós szintet, hátrányosan befolyásolja a tartományi függetlenséget, és növeli az újrafelhasználás költségeit. A futtatható UML-ben az optimalizálásokat a modellfordító automatikusan vagy jelölés útján végzi. A jelölés lehetővé teszi, hogy bizonyos modellelemeket célzottan alacsonyabb szintű megvalósításokra irányítsunk, és szélesebb körű architekturális döntéseket tesz lehetővé, például annak meghatározását, hogy az objektumgyűjteményeket kétszeresen összekapcsolt listaként kell megvalósítani.

MDA szempontból a modell fordítója létrehozza a PSM-et . A PIM és a PSM közötti elválasztás az Executable UML-ben letiltja a modell oda-vissza tervező képességét, és elriasztja a PSM módosításait.[13]

Végrehajtható UML kulcsszempontok[szerkesztés]

A végrehajtható UML az UML egy részhalmazának végrehajtási szemantikáját határozza meg. A végrehajtható UML részhalmaz legfontosabb szempontjai a következők:

  • Nem támogatja az olyan implementáció-specifikus konstrukciókat, mint az aggregáció és a kompozíció.[14]
  • Az általánosítások mindig {teljes, diszjunkt} jelöléssel vannak jelölve.
  • Az osztályok közötti asszociációk mindig meg vannak nevezve, mindkét végén szerepeket meghatározó igekötőkkel, és mindkét végén multiplicitással.
  • Az asszociációs végek multiplicitása 0..1 (nulla egyhez), * (nulla sokhoz), 1 (pontosan egy), vagy 1..* (egy sokhoz).
  • Az adattípusok a következő alapvető adattípusokra korlátozódnak: boolean, string, integer, real, date, timestamp és arbitrary_id, vagy a következő tartományspecifikus adattípusok valamelyike: numeric, string, enumerated és composite. A tartományspecifikus numerikus és string adattípusok az alapadattípusok részhalmazait képviselhetik. A tartományspecifikus összetett adattípust mindig egyetlen egységként kell kezelni a tartományon belül. pl. deklarálható egy MailingAddress összetett adattípus, de városinformáció nem vonható ki belőle.
  • A végrehajtható UML-modellekre vonatkozó megkötések vagy Object Constraint Language (OCL), vagy akciónyelv formájában ábrázolhatók.

fUML és ALF[szerkesztés]

Az Object Management Group szabványosította az Alapvető UML-t (fUML), amelyre nagy hatással volt a végrehajtható UML.

Action Language for Foundational UML (ALF),[15] az Object Management Group szabványos akciónyelvi specifikációja.

Kapcsolódó szócikkek[szerkesztés]

Publikációk[szerkesztés]

Jegyzetek[szerkesztés]

  1. ↑ Mellor and Balcer 2002
  2. ↑ a b Starr 2002, p. 3.
  3. ↑ G. O'Keefe (2006) "Dynamic Logic Semantics for UML Consistency" in: Model-Driven Architecture - Foundations and Applications: Second European Conference, ECMDA-FA 2006, Bilbao, Spain, July 10–13, 2006, Proceedings. Arend Rensink eds. p. 124
  4. ↑ Mellor and Balcer 2002, section 1.4.
  5. ↑ Mellor and Balcer 2002, section 1.5.
  6. ↑ Raistrick et al. 2004, sections 2.3.3 and 2.3.4.
  7. ↑ Mellor and Balcer 2002, section 1.1.
  8. ↑ Mellor and Balcer 2002, section 3.4.
  9. ↑ Mellor and Balcer 2002, p. 14.
  10. ↑ Mellor and Balcer 2002, p. 35.
  11. ↑ MASL is a Shlaer-Mellor dialect action language and structural modeling language.: xtuml/masl. xtUML, 2018. december 27. (Hozzáférés: 2019. október 26.)
  12. ↑ MASL is a Shlaer-Mellor dialect action language and structural modeling language.: xtuml/masl. xtUML, 2018. december 27. (Hozzáférés: 2019. október 26.)
  13. ↑ Mellor and Balcer 2002, chapter 9.
  14. ↑ Mellor and Balcer 2002, p. xxx.
  15. ↑ Action Language for Foundational UML™ (ALF™). www.omg.org . (Hozzáférés: 2016. december 21.)

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben az Executable UML című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Végrehajtható_UML&oldid=26876439”