UML (Unified Modeling Language)

Az UML (Unified Modeling Language) szabványos, általános célú modellező nyelv, üzleti elemzők, rendszertervezők és szoftvermérnökök számára. A nyelvre vonatkozó, szabványosítással összefüggő feladatokat OMG (Object Management Group) végzi. Az UML aktuális verziószáma 2.5.1, amelyet 2017 decemberében adtak ki. A nyelvben definiált diagramok nagy része korábban már ismert modellekből lett átvéve és továbbfejlesztve, csak egy kisebb részük tekinthető teljesen új eszköznek.

Az UML felépítése

Az ábrán az M0 szint az M1 szinten definiált osztályok objektumait tartalmazza, a legtöbb esetben ez egyben a végfelhasználói modell konkrét objektumait jelenti. Az M1 szint a problémaleíráshoz használt modellező szint, itt definiálható a végfelhasználó által vizsgált probléma leírása, a felhasználó itt tervezi meg az elkészítendő alkalmazás osztályait, interakcióit, stb.

Az M2 szinten találhatók azok a metaosztályok, amelyek példányait használjuk az M1 szinten lévő modellek létrehozása során. Itt vannak definiálva maguk az UML diagramok és azok összetevői. Az M3 szint, a meta-meta modell szint pedig azokat a definíciókat tartalmazza, amelyekből az UML (vagy akár más modellező nyelv) összetevői definiálhatók.

A fent ismertetett felépítés lehetővé teszi az UML bővítését, amelyet az M2 szinten (és attól feljebb lévő szinten) végezhetünk el. Tipikus bővítés a sztereotípusok definiálása, amelyek segítségével egy-egy nyelvi diagram elem specializálható a rendszertervezés igényeinek megfelelően.

Objektumok és osztályok

Biztosan ismert már a két fogalom közötti eltérés, de jelentősége folytán emlékeztetőül indokolt ezeknek a fogalmaknak a felfrissítése. Az osztály egy koncepció, egy absztrakt adattípus, amely meghatározza, hogy az ilyen típussal rendelkező objektumoknak milyen tulajdonságai lehetnek és milyen viselkedés jellemző rájuk. Az objektum ezzel szemben egy adott osztályból származtatott egyedi példány, önálló memóriacímmel és egyedi, konkrét tulajdonságokkal rendelkezik. Egy osztályból számos objektum hozható létre, míg egy objektum egy adott osztálynak a példánya lehet.

Diagram típusok

Amikor egy problémát modellezünk, akkor azt különböző nézőpontokon keresztül tehetjük meg. Az egyes UML diagramtípusok pontosan ezeknek a nézőpontoknak a kifejezésére szolgálnak. A diagramokat két csoportra szokás osztani:

• szerkezeti diagramok
• viselkedési diagramok

Osztálydiagramok

Az osztálydiagram egy szerkezeti diagram, amely az osztályok és a közöttük lévő kapcsolatok ábrázolására szolgál. Az alábbi példa egy tipikus osztálydiagramot ábrázol:

.

A diagramban a dobozok jelképezik az osztályt. Az osztály neve a doboz legfelső szakaszán látható. Dőlt betűs szedéssel az absztrakt osztályokat ábrázolják, azaz olyan osztályokat, amelyek nem példányosíthatók. A <<>> jelek szteretípusokat jelölnek, ezek valamilyen speciális, kitüntetett szereppel rendelkező elemek, a példában ilyen az Enum, ami a felsorolástípus ábrázolása.

Az osztálydiagramokon feltüntetik az adattagokat (tulajdonságokat) és a metódusokat (viselkedéseket) is, egymástól elválasztva. Az adattagok esetében azok típusát, inicializált értékét is fel lehet tüntetni, de ez nem kötelező. Hasonlóan a metódusok paraméterei és visszatérési értékük is opcionálisan feltüntethető. Mind az adattagok, mind a metódusok esetén azok láthatósága is jelölve van. A + jelenti a publikus, a - a privát és a # a védett (protected) adattagokat, metódusokat.

A relációs kapcsolatok lehetnek az öröklődés, vagy inkább specializáció, illetőleg fordított irányban az általánosítás, amelyet egy vastag végű nyíl jelképez. A nyíl az általánosabb osztály felé mutat: .

Az asszociációs kapcsolatok többféle relációt is jelképezhetnek. A legegyszerűbb kapcsolatok ábrázolásában egy folytonos vonallal kötjük össze a két osztályt . Amennyiben a kapcsolatnak iránya is van, ezt az összekötésben nyíllal jelölhetjük. Az asszociciónak általában van neve, számossága, lehet iránya és szerepe. A fenti példában az Order és Payment osztályok között irányított kapcsolat van, tetszőleges rendeléshez legalább egy fizetés kapcsolódik, amelyet a számossággal fejezünk ki (1..*). Olyan eset is lehetséges, mikor két osztályt egy harmadik osztály kapcsol össze, valamely közös tulajdonság alapján. Erre a kapcsolatra mutat példát az alábbi ábra:

.

Rész-egész viszonyt kétféleképpen fejezhetünk ki:

• aggregációval
• kompozícióval

A két reláció közötti különbség az, hogy kompozíció esetén a tartalmazott osztály objektuma nem létezhet a tartalmazó osztály példányosított objektuma nélkül. Ilyen esetben a tartalmazó objektum törlésével a tartalmazott objektum is automatikusan törlődik. Az aggregáció esetébenn az osztályok példányai egymástól függetlenül létezhetnek. A fenti példában az Order és OrderDetail között aggregációs viszony van, ahol a tartalmazó objektum osztálya az Order. Ezeknek az osztályoknak az objektumai egymástól függetlenül is létezhetnek, a rendelés megszűnésével a tételei nem szűnnek meg automatikusan. A rész-egész viszony esetében is értelmezhető mindaz, amit az asszociációra mondtunk, tehát lehet neve, szerepköre, számossága.

Objektumdiagram

Strukturális M0 diagram, konkrét példányosított objetumok leírására szolgál. Hasonló felépítésű mint az osztálydiagram, de ebben az esetben nem osztályokról, hanem azok példányairól beszélünk. Ritkán használják őket, leginkább demonstrációs célokra, vagy tesztelés tervezése során.

Csomagdiagram

Akárcsak a programozási nyelvekben (C++ namespace, illetőleg Java package), ahol az összetartozó osztályokat egy névtérbe, illetőleg csomagba szervezhetjük, az UML is lehetőséget ad nagyobb egységek egy nézetben történő modellezésére. Ezt a nézetet a csomagdiagram segítségével tudjuk modellezni, amely egy olyan szerkezeti diagram, amely az osztályoknál nagyobb egységek, azok kapcsolatainak, illetőleg függőségeinek ábrázolására alkalmazható.

Kompozitdiagram

A kompozitdiagram az UML 2-ben definiált szekezeti diagramtípus, amely osztályokat, interfészeket, csomagokat és a kapcsolataikat tartalmazza. A diagram a teljes rendszerről és annak részeiről együttesen ad egy áttekintő nézetet.

Komponensdiagram

A komponensdiagram olyan szerkezeti diagram, amely a szoftver komponenseire és a köztük lévő kapcsolatok ábrázolására helyezi a hangsúlyt. A komponensek ábrázolására speciális sztereotípussal jelölt dobozokat használunk. A komponensek nyújthatnak szolgáltatást és igénybe vehetik más komponensek által nyújtott szolgáltatásokat. A nyújtott szolgáltatásokat kis körök, míg a szolgáltatás igényeket egy kisebb tányér jelképezi.

.

A diagramon a szolgáltatások csatlakozópontjait (portokat) is jelölhetik, ezek kisebb téglalapok a komponens határvonalán.

Telepítési diagram

A telepítési diagram a szoftverelemek telepítését ábrázoló szerkezeti diagram. A telepítés eszközei egyaránt lehetnek hardver- és szoftvereszközök, ez utóbbi lehet például egy docker konténer. Hardvereszközre példa a munkaállomás vagy a szerver.

Használati eset diagram

A használati esetek a szoftver egy-egy forgatókönyvei, amelyek leírják azokat a folyamatokat, mikor a szoftver külső kérést kap és válaszol arra. A használati eset (use case) olyan műveletek sorozata, amely jellemzően egy szerepkör (amelyet az UML szereplőnek, actornak nevez) és egy rendszerelem között zajló interakciókat írja le. A szereplő lehet ember, vagy más külső rendszer.

A használati eset diagramok olyan viselkedési diagramok, amelyek általában több használati eset és azok kapcsolatainak ábrázolására használnak. Az egyes használati esetekhez minden esetben tartozik egy részletes forgatókönyv, amely tartalmazza a normál és alternatív lefutásokat, valamint a lefutásokhoz tartózó elő és utófeltételeket.

A használati esetek grafikus ábrázolásán túl meg kell adni azok lefutását, mégpedig az egyes döntési pontokhoz kapcsolódó alternatív lefutásokkal együtt. Ezeket a forgatókönyveket szövegesen (akár user story segítségével), üzleti nyelv használatával kell megfogalmazni. Minden egyes használati esethez specifikálni kell annak elő és utófeltételeit. Az alternatív lefutások egy-egy feltétel fennállása esetén érvényes forgatókönyvek. Ide is sorolhatók, de általában külön veszik azokat a forgatókönyveket, amelyek valamely kivétel fennállása esetében futnak le. Ez utóbbiakat is definiálni kell a használati eset specifikációban.

Az egyes használati esetek között két tipikus kapcsolat definiálható, amelyeket a diagramon is ábrázolunk:

• Bennfoglalás (include): ebben az esetben A használati eset tartalmazza B használati esetet, a példán a Take Examination magába foglalja a Login Accountot, azaz a Take Examination lefutása esetén a Login Account is automatikusan lefut.
• Kiterjesztés (extend): ekkor a kiterjesztett elem nem fut le kötelezően, csak opcionálisan. A példában ilyen a Set Java Questions kiterjesztése a Prepare Question Bank használati esettel.

Az aktorok között ábrázolható adott esetben specializáció és általánosítás is.

A használati esetek lefutását más viselkedési diagrammal, például aktivitás diagrammal, vagy szekvencia diagrammal is megadhatjuk.

Szekvenciadiagram

A szekvenciadiagram olyan viselkedésdiagram, amely az egyes komponensek közötti üzenetváltásokat modellezi időbeli sorrendjüket megtartva.

A diagram komponensei lehetnek szoftverelemek és aktorok. Minden egyes komponenshez tartozik egy idővonal, amely az adott komponens a kommunikáció során lévő aktív állapotait mutatja. Az idővonal egy függőleges szaggatott vonal a komponensből kiindulva, az aktív állapot telt téglalappal van jelölve. A kommunikációs lépéseket az idővonalon komponenstől komponensig nyíllal jelöljük, valamint sorszámozzuk is azokat. A szolgáltatáskérést folytonos, míg a válasz üzenet szaggatott nyíllal jelöljük. Az üzenetváltás megnevezése általában egy metódushívás lesz, ami egy elemi műveletet jelent.

Kommunikációsdiagram

A kommunikációsdiagram, a szekvenciadiagramhoz hasonlóan, az objektumok közötti üzenetváltások ábrázolására használható, azonban ebben az esetben nem az üzenetváltások időbeliségére helyeződik a hangsúly, hanem az üzenetváltásokban részvevő objektumok közötti kapcsolatokra.

Az ábrán lévő kommunikáció diagramon speciális UML jelöléseket is látunk, amely az MVC (Model View Controller) design pattern elemeit jelöli.

Állapotgép diagram

Az állapotgép diagram az automataelméletből ismert Mealy és Moore gépek általánosítása. A vizsgált rendszer viselkedését állapotátmenetekkel modellezi. Az állapotokat dobozok, míg az átmeneteket nyilak jelölik. Az állapotátmenet feltételei a nyilakra írhatóak, míg a kimenetek (tevékenységek) a dobozok határán jelölhetők.

Aktivitásdiagram

Az aktivitásdiagramok a folyamatábrák UML-beli megfelelőinek tekinthetők, ugyanakkor azoknál jóval fejlettebb komponensekkel rendelkeznek. Az aktivitásdiagram a vizsgált folyamatok leírására procedurális komponenseket használ. A diagram lehetővé teszi a párhuzamos folyamatok modellezését, léteznek elemek a folyamatok szétválasztásának és összefésülésének ábrázolására, valamint jelölhetők a diagramon az aktorok is.

Időzítési diagram

Az időzítési diagram az események időbeli lefutásának ábrázolására használt viselkedés diagram.