Kihagyás

UML és egyéb diagramok

Az UML (Unified Modeling Language) szabványos, általános célú modellező nyelv, üzleti elemzők, rendszertervezők, szoftvermérnökök számára. A nyelv szabványosított, amelynek szervezése az OMG (Object Management Group) feladata. A nyelv aktuális verziója 2.5.1 Az UML diagramok nagy része korábbi modellezési módszertanokból átvett elem, illetőleg azok továbbfejlesztése. Maga az UML nem módszertan, hanem modellező eszköz, amely a szoftverfejlesztés különböző fázisaiban nyújt támogatást hatékony és jól interpretálható modellek készítéséhez.

UML felépítése

Az előadáson részletesen szó lesz róla, emlékeztetül az alábbi ábra: Model.

Itt az M0 szint az M1 osztályainak objektumait jelenti, legtöbb esetben ez a felhasználói modellünk konkrét objektumaira utal. Az M1 a problémaleíráshoz használt modellező szint, azaz itt definiáljuk az általunk vizsgált probléma leírását, itt tervezzük 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-beli modelljeink felépítése során, azaz itt vannak definiálva az egyes UML diagramok és azok elemei. Az M3 szinten, a meta-meta modell szinten pedig azokat a definíciókat találjuk, amelyekből az UML (vagy más modellező nyelv) elemei felépíthetők. Mindezt azért érdemes tudni, mert az UML bővíthető, a bővítést pedig az M2 szinten és attól felfele végezhetjük el. Persze erre a gyakorlatban ritkán kerül sor, a meglévő diagramtípusok kellő támpontot adnak a legtöbb probléma modellezésére.

Modellező eszközök

Az elérhető modellező eszközök között számos terméket lehet találni az egyszerű UML rajzoló eszközöktől kezdve egészen a kódgenerálást támogató komplex modellező eszközökig. Ezekről egy listát találhatunk ezen a linken A komplexebb támogatást nyújtó eszközök azonban mind fizetősek. Egy-egy cég kínál community-edition változatot is, amelyek jól használhatók, de ezek jellemzően csökkentett funkcionalitású termékek, illetőleg nem használhatók kereskedelmi célú fejlesztésekhez. A tanuláshoz például a Visual Paradigm Community Edition is használható, de ebben reverse engineering funkció, illetőleg kód generálás nem elérhető. Azok kipróbálására érdemes a korlátozott ideig, kipróbálásra szánt verziókat is megnézni. A CE esetében egy gyors regisztráció után már használható is az eszköz.

Diagram típusok

A gyakorlatban az UML használata a különböző UML diagramokon keresztül történik. Mikor egy komplex problémát modellezünk, akkor azt különböző nézőpontokon keresztül tehetjük meg. Az egyes diagramtípusok pontosan ezeknek a nézőpontoknak a kifejezésére szolgálnak. Az UML esetében két csoportra oszthatjuk a diagramokat:

  • szerkezeti diagramok
  • viselkedési diagramok.composite-internal-structure-diagram-elements

Osztálydiagram

Szerkezeti diagram, amely osztályok (OOP) és azok közötti relációk ábrázolására szolgál. Az alábbi példa egy tipikus osztálydiagramot ábrázol:

Osztály.

A diagramban egy-egy box jelképez egy osztályt. Az osztály neve a box felső 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ípiákat jelölnek, ezek valamilyen speciális, az osztályok között kitüntetett szereppel rendelkezők, ilyen a példában az Enum, ami a felsorolás típust jelenti.

Az osztálydiagramokon feltüntetik az adattagokat és a metódusokat is, egymástól vonallal elválasztva. Az adattagok esetében azok típusát, inicializált értékeit is fel lehet tüntetni, de ez nem mindig szokás. Hasonlóan a metódusok paraméterei és visszatérési értékük opcionálisan feltüntethető. Mind az adattagok, mind a metódusok esetén azok láthatósága is meg van jelölve. 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és, vagy inkább specializáció, általánosítás, amelyet egy vastag végű nyíl jelképez. A nyíl az általánosabb osztály felé mutat: Öröklés.

Az asszociációs kapcsolatok többfélék lehetnek. A legegyszerűbb esetben egy folytonos vonallal kötjük össze a két osztályt Asszociáció. Amennyiben a kapcsolatnak értelmezhető iránya is van, ez lehet egy nyíl is. Az asszociciónak általában van neve, számossága és lehet iránya, szerepe. Ezek mind feltüntetésre kerülnek. A példánkban az Order és Payment között irányított kapcsolat van, tetszőleges rendeléshez legalább egy fizetés kapcsolódik (1..*). Olyan is lehetséges, mikor két osztályt egy harmadik kapcsol össze közös tulajdonság alapján

Asszociáció2.

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

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

A kettő közötti különbség az, hogy kompozíció esetén a tartalmazott osztály objektuma nem létezhet a tartalmazó nélkül. Azaz a tartalmazó objektum törlésével a tartalmazott objektum is törlődik. Az aggregáció esetén az osztályok példányai egymástól függetlenül létezhetnek. A példánkon az Order és OrderDetail között aggregációs viszony van, a tartalmazó osztály az Order. Azonban ezen osztályok 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 leneve neve, szerepkörök adhatók meg, illetőleg a számosság is jelölhető.

Objektumdiagram

Strukturális M0 diagram, konkrét objetumok leírására szolgál. Hasonló felépítésű mint az osztálydiagram, de itt nem osztályról, hanem azok példányairól beszélünk. Ritkán használják őket, leginkább demonstrációs célra, vagy teszteléskor. Egy plda az objektum diagramra: Objektum

Csomagdiagram

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

Package

Kompozit szerkezet diagram

UML 2-ben definiált szekezeti diagramtípus, amely osztályokat, interfészeket, csomagokat és kapcsolataikat tartalmazza. A digram a teljes rendszerről és annak részeiről együtt ad egy interpretációt.

Kompozit

Komponens diagram

Olyan szerkezeti diagram, amely a szoftver által nyújtott szolgáltatásokra, mint komponensek é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ípival 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.

Komponens.

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

Telepítési diagram

A szoftverelemek telepítését ábrázoló szerkezeti diagram. A telepítés eszközei lehetnek hardver eszközök és szoftver elemek is, ez utóbbi például egy docker konténer is lehet. Hardver elemre példa lehet a munkaállomás vagy a szerver.

Telepítési diagram

Használati eset diagram

Az üzleti elemzésben használt diagram, amely a modellezni kívánt jelenség viselkedését felhasználói oldalról megközelítve modellezi. Fontos, hogy az üzleti esetek leírása során az üzleti nyelvet és ne az informatika nyelvét használjuk. Ez a diagram a kommunikációs elem az ügyfelek és a fejlesztők között. Két főbb eleme van, az un. aktorok és a használati esetek.

Use case

A használati esetek grafikus ábrázolásán túl szokás azok lefolyását is megadni, mégpedig az egyes döntési pontokon alternatív lefutásokkal együtt. Ezeket szövegesen, akár user story módján is meg lehet adni. Meg kell adni a használati esetek elő és utófeltételeit is. A fizetős UML eszközök mindezeket strukturált módon rendelkezésre bocsátják. Az egyes elemekhez követelmányek, megszorítások is rendelhetők, így a használati eset diagram, amennyiben jól van elkészítve és hiánytalanul tartalmazza a lehetséges lefutásokat is, alkalmas a rendszertervezésre és közvetlenül tesztesetek generálására is. A használati esetek között két tipikus kapcsolat definiálható:

  • 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 lefutása esetén a Login is lefut.
  • Kiterjesztés (extend): ekkor a kiterjesztett elem nem fut le kötelezően, de opcionálisan igen, 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.

Szekvencia diagram

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

Szekvencia

A komponensek lehetnek szoftverelemek és aktorok is. Az egyes objektumokhoz tartozik egy idővonal, amely az adott objektum (aktor, komponens) a kommunikáció során lévő aktív állapotát mutatja. Ez egy függőleges szaggatott vonal az objektumból kiindulva, az aktív állapot pedig telt téglalappal van jelölve. A kommunikációt időben és objektumtól objektumig nyíllal jelöljük és sorszámot is adunk nekik. A szolgáltatáskérés folytonos, míg a válasz üzenet szaggatott nyíllal jelölt. Az üzenetváltás megnevezése általában egy metódushívás lesz, tehát elemi művelet.

Kommunikációs diagram

A kommunikációs diagram, a szekvencia diagramhoz hasonlóan, objektumok közötti üzenetváltásokat képes ábrázolni, azonban ebben az esetben nem az üzenetváltások időbeliségére helyezzük a hangsúlyt, hanem az üzenetváltásokban részvevő objektumok közötti kapcsolatokra.

Kommunikáció

Az ábrán lévő kommunikáció diagramon speciális UML jelöléseket is látunk, amely az MVC (Model View Controller) nézethez kapcsolódik. Pattern

Állapotgép diagram

Az állapotgép diagram az automataelméletből ismert Mealy és Moore gépek általánosítása. A rendszerünk viselkedését állapotátmenetekkel modellezi. Az állapotokat boxok, míg az átmeneteket nyilak jelölik. Az állapotátmenet feltételei a nyilakra írható. Két speciális állapot mellett (kezdő és végállapot) jelölhetnek csapdaállapotokat, illetőleg az átmenet megszakadását is. A diagramot kiegészíthetik még elágazásokkal.

Automata

Az állapotokat jelképez boxokba az adott állapotban végrehajtható tevékenységeket is fel szokták sorolni. (Szekvenciális gépek modellezése esetén).

Aktivitás diagram

A folyamatábrák UML-beli megfelelje. A modellezni kívánt elemet procedurális elemekkel írja le. A diagram párhuzamos folyamatok ábrázolására is alkalmas, az ábrán ezt a fekete téglalap jelzi. Ezek az elemek mind folyamatok szétválasztására és összefésülésére is használhatók. Ábrázolhatók az aktorok és az általuk végrehajtott folyamatrészek is.

Aktivitás

Időzítési diagram

Az egyes események időbeli lefutásának ábrázolására használt viselkedés diagram.

Timing

Üzleti folyamat diagram (BPMN)

Az üzleti folyamatok folyamatszemléletű modellezéséhez széles körben használt diagram, nem része az UML-nek, viszont hasonlít hozzá. A modell aktivitásokat, átjárókat, kapcsolatokat és eseményeket ábrázol.

BPMN

A modellt gyakran használják a rendszerszervezők, a use case diagramokkal együtt igen elterjedt az üzleti modellezésben.

Rendszer modellezés (SysML)

A mérnöki rendszerek modellezésére használt diagram. Nem része az UML-nek, de használja annak diagramjait és annál flexibilisebb leírást biztosít az ipari rendszerek modellezéséhez. 9 diagramtípust tartalmaz

SYSML:

  • Blokk definíciós diagram
  • Belső blokkdiagram
  • Csomagdiagram
  • Használati eset diagram
  • Követelmény diagram
  • Aktivitás diagram
  • Szekvencia diagram
  • Állapotgép diagram
  • Paraméter diagram

Utolsó frissítés: 2021-03-07 17:04:00