Osztálydiagram

A Wikipédiából, a szabad enciklopédiából
Az UML 2.5 diagramok hierarchiája osztálydiagramként látható. Az egyes osztályokat csak egy rekesz képviseli, de gyakran legfeljebb három rekeszből állnak

A szoftverfejlesztésben az Unified Modeling Language (UML) osztálydiagramja egyfajta statikus szerkezetű diagram, amely leírja a rendszer felépítését azáltal, hogy bemutatja a rendszer osztályait, attribútumait, műveleteit (vagy metódusait), valamint az objektumok közötti kapcsolatokat.

Az osztálydiagram az objektumorientált modellezés fő építőköve. Az alkalmazás felépítésének általános fogalmi modellezésére, valamint annak részletes modellezésére használják, majd ezen modelleket programozási kóddá fordítják. Az osztálydiagramok adatmodellezéshez is használhatók.[1] Az osztálydiagramban szereplő osztályok a fő elemeket, az alkalmazás interakcióit és a programozandó osztályokat egyaránt képviselik.

A diagramon az osztályokat egy doboz képviseli, mely három részre, rekeszre osztható:

  • A felső rekesz az osztály nevét tartalmazza. Félkövérrel és középre szedve van írva, és az első betű nagybetűvel kezdődik.
  • A középső rekesz az osztály attribútumait tartalmazza. Balra vannak igazítva, és az első betű kisbetű.
  • Az alsó rész az osztály által végrehajtható műveleteket tartalmazza. Szintén balra vannak igazítva, és az első betű kisbetű.
Háromrekeszes osztály

Egy rendszer kialakítása során számos osztályt azonosítanak és csoportosítanak egy osztálydiagramba, amely segít meghatározni a közöttük lévő statikus kapcsolatokat. A részletes modellezés során a koncepcióterv osztályait gyakran alosztályokra osztják.

A rendszerek viselkedésének további leírása érdekében ezeket az osztálydiagramokat állapotdiagrammal vagy UML állapot gépdiagrammal egészíthetjük ki.[2]

Tagok[szerkesztés]

Az UML mechanizmusokat biztosít az osztálytagok ábrázolására, például attribútumok és metódusok megjelenítésére, valamint további információkat nyújthat róluk, például konstruktorokat.

Láthatóság[szerkesztés]

Egy osztálytag (azaz bármilyen attribútum vagy metódus) láthatóságának meghatározásához ezeket a jelöléseket kell elhelyezni a tagok neve előtt:[3]

+ Public
- Private
# Protected
~ Package

A származtatott tulajdonság olyan tulajdonság, amelynek értéke (vagy értékei) más információkból származnak vagy számíthatók ki, például más tulajdonságok értékeinek felhasználásával.

A származtatott tulajdonságok neve előtt egy per jel '/' szerepel.[4]

Hatókör[szerkesztés]

Az UML kétféle hatókört határoz meg a tagok számára: példány és osztály, ez utóbbit pedig aláhúzott nevek jelölik.[5]

  • A példánytagok egy adott példányra vonatkoznak.
    • Az attribútumok értéke példányonként változhat
    • A metódushívás befolyásolhatja a példány állapotát (azaz megváltoztathatja a példány attribútumait)
  • Az osztály tagjait sok programozási nyelvben általában „statikusnak” ismerik el. A hatókör maga az osztály.
    • Az attribútumok értéke minden esetben egyenlő
    • A metódushívás nem befolyásolja az osztályozó állapotát

Egy tag osztályozó hatókörének jelzéséhez a nevét alá kell húzni. Ellenkező esetben alapértelmezés szerint a példány hatókörét feltételezi.

Kapcsolatok[szerkesztés]

UML kapcsolatok jelölése

A kapcsolat egy általános kifejezés, amely az osztály- és objektumdiagramokon található logikai kapcsolatok specifikus típusait takarja. Az UML a következő kapcsolatokat határozza meg:

Példányszintű kapcsolatok[szerkesztés]

Függőség[szerkesztés]

A függőség egy olyan asszociációs típus, ahol szemantikai kapcsolat van a függő és független modellelemek között.[6] Ez a függés két elem között létezik, az egyik elem (a kiszolgáló vagy a cél) definíciójának módosítása a másik elem (a kliens vagy a forrás) változásait okozhatja. Ez a társulás egyirányú. A függőség szaggatott vonalként jelenik meg nyitott nyíllal, amely a klienstől a szállító felé mutat.

Társulás[szerkesztés]

Osztálydiagram-példa két osztály közötti társulásra

A társulás a kapcsolatok családját képviseli. A (két végű) bináris asszociációt általában vonalként ábrázolják. Egy társítás tetszőleges számú osztályt összekapcsolhat. A három láncszemből álló asszociációt háromtagú társulásnak nevezzük. Egy társulás elnevezhető, a társítások végeit pedig szerepnevek, tulajdonosi jelzők, sokféleség, láthatóság és egyéb tulajdonságok díszíthetik. Négy különböző típusú asszociáció létezik: kétirányú, egyirányú, összesítő (beleértve az összetétel-aggregációt is) és reflexív. A kétirányú és egyirányú asszociációk a leggyakoribbak. Például egy repülő osztály kétirányúan van társítva a repülőgép-osztályhoz. Az asszociáció két osztály objektumai között megosztott statikus kapcsolatot képviseli.

Összevonás[szerkesztés]

Két osztály közötti aggregációt bemutató osztálydiagram. Itt egy professzornak „has a” órája, amit tanítani kell.

Az aggregáció a "van egy", angolul "has a", asszociációs kapcsolat egy változata; az összevonás specifikusabb, mint az asszociáció. Ez egy olyan társulás, amely egy rész-egész vagy részben kapcsolatot képvisel. Ahogy a képen látható, a professzornak „van egy” osztálya, amelyet tanítani kell. Az asszociáció típusaként az aggregációt el lehet nevezni, és ugyanazokkal a díszítésekkel lehet ellátni, mint az asszociációknál. Az összesítés azonban nem tartalmazhat kettőnél több osztályt; bináris asszociációnak kell lennie. Továbbá alig van különbség az aggregációk és az asszociációk között a megvalósítás során, és a diagram teljesen kihagyhatja az aggregációs kapcsolatokat.[7]

Aggregáció akkor fordulhat elő, ha egy osztály más osztályok gyűjteménye vagy tárolója, de a benne foglalt osztályok nem rendelkeznek erős életciklus-függőséggel a tárolótól. A container tartalma tovább létezik, még ha ha maga a container már kitörlődésre is került.

Az UML -ben grafikusan egy üres rombusz alakzatként ábrázolják a tartalmazó osztályon, egyetlen vonallal, amely összeköti a benne foglalt osztállyal. Az aggregátum szemantikailag egy kiterjesztett objektum, amelyet sok műveletben egységként kezelnek, bár fizikailag több kisebb objektumból áll.

Példa: Könyvtár és hallgatók. Itt a hallgató létezhet könyvtár nélkül is, a hallgató és a könyvtár kapcsolata aggregáció.

Összetétel[szerkesztés]

Két osztálydiagram. A fenti diagram két osztály közötti összetételt mutatja: Egy autónak pontosan egy karburátora van, a karburátornak pedig egy autó része. A karburátorok nem létezhetnek különálló alkatrészekként, egy adott autóról leválasztva. Az alsó diagram a két osztály közötti aggregációt mutatja: Egy tóban nulla vagy több kacsa van, egy kacsán pedig legfeljebb egy tó (egyszerre). A kacsa a tótól külön is létezhet, pl. élhet egy tó közelében. Amikor elpusztítunk egy tavat, általában nem öljük meg az összes kacsát.

A kompozíciós kapcsolat UML-ábrázolása a kompozíciót kitöltött rombusz alakzatként jeleníti meg azon sorok tartalmazó osztály végén, amelyek a tartalmazott osztály(oka)t a tartalmazó osztályhoz kapcsolják.

Az összetétel és az összevonás közötti különbségek[szerkesztés]

Összetétel kapcsolat
1. Amikor a valós világban a teljes rész kapcsolatokat próbáljuk ábrázolni, például a motor egy autó része.
2. Amikor egy container kitörlésre kerül, a tartalma is megsemmisül, pl. egy egyetem és tanszékei.
Összevonás kapcsolat
1. Amikor szoftver- vagy adatbázis-kapcsolatot ábrázol, pl. az ENG01 autómodell motorja a CM01 autómodell része, mivel az ENG01 motor, esetleg egy másik autómodell része is.[8]
2. Amikor egy container kitörlésre kerül, a tartalma általában nem semmisül meg, pl. egy professzornak vannak tanítványai; amikor a professzor meghal, a diákok nem halnak meg vele együtt.

Így az összevonás kapcsolat gyakran „katalógus” elszigetelése, hogy megkülönböztesse a kompozíció „fizikai” elszigetelésétől.

Osztályszintű kapcsolatok[szerkesztés]

Általánosítás/öröklődés[szerkesztés]

Osztálydiagram, amely a Személy szülőosztály és a két Diák és Professzor alosztály közötti általánosítást mutatja

Azt jelzi, hogy a két kapcsolódó osztály közül az egyik (az alosztály ) a másik (a szuper típus) speciális formájának, a szülőosztály pedig az alosztály általánosításának tekinthető. A gyakorlatban ez azt jelenti, hogy az altípus bármely példánya egyben a szuperosztály példánya is. Az ilyen formájú általánosítások példája a biológiai osztályozásban található: az ember a majom alosztálya, amely az emlősök alosztálya, és így tovább. A kapcsolat a legkönnyebben az „egy A az B” kifejezéssel érthető meg (az ember emlős, az emlős állat).

Az általánosítás UML grafikus ábrázolása egy üres háromszög alakzat a vonal (vagy vonalfa) szuperosztály végén, amely összeköti egy vagy több altípussal.

Az általánosítási viszonyt öröklődésnek vagy "is a" kapcsolatnak is nevezik.

Az általánosítási kapcsolatban lévő szuperosztályt (alaposztályt) "szülő"-nek, szuperosztálynak, alaposztálynak vagy alaptípusnak is nevezik.

A specializációs kapcsolat altípusa gyermek, alosztály, származtatott osztály, származtatott típus, öröklődő osztály vagy öröklődő típus néven is ismert.

Megjegyzendő, hogy ez a kapcsolat nem hasonlít a biológiai szülő-gyermek kapcsolathoz: e kifejezések használata rendkívül gyakori, de félrevezető lehet.

Az A a B típusa
Például: "a tölgy egy fafajta", "az autó egy fajta jármű"

Az általánosítás csak az osztálydiagramokon és a használati eset diagramokon jeleníthető meg.

Megvalósítás/Implementáció[szerkesztés]

Az UML modellezésben a megvalósítási kapcsolat két modellelem közötti kapcsolat, amelyben az egyik modellelem (az ügyfél) megvalósítja (megvalósítja vagy végrehajtja) azt a viselkedést, amelyet a másik modellelem (a szállító) meghatároz.

A megvalósítás UML grafikus ábrázolása egy üres háromszög alakzat a szaggatott vonal (vagy vonalfa) interfész végén, amely összeköti azt egy vagy több implementációval. Egy sima nyílfejet használnak a szaggatott vonal interfész végén, amely összeköti a felhasználókkal. A komponensdiagramoknál a golyó és a foglalat grafikus konvenciót alkalmazzák (az implementátorok egy labdát vagy nyalókát tesznek ki, míg a felhasználók egy foglalatot). A megvalósítások csak osztály- vagy komponensdiagramokon jeleníthetők meg. A megvalósítás osztályok, interfészek, komponensek és csomagok közötti kapcsolat, amely összeköti a kliens elemet a szállító elemmel. Az osztályok/összetevők és interfészek közötti megvalósítási kapcsolat azt mutatja, hogy az osztály/komponens megvalósítja az interfész által kínált műveleteket.

A megvalósulás jelképe -------▻

Általános kapcsolat[szerkesztés]

Osztálydiagram, amely a „Car” osztály és a „kerék” osztály közötti függőséget mutatja (Egy még világosabb példa lenne az „Autó függ a keréktől”, mivel az autó már összesíti (és nem csak használja ) a kerekeket)

Függőség[szerkesztés]

A függőség a kötelék gyengébb formája lehet, amely azt jelzi, hogy az egyik osztály egy másiktól függ, mert azt egy bizonyos időpontban használja. Egyik osztály függ a másiktól, ha a független osztály a függő osztály metódusának paraméterváltozója vagy lokális változója. Néha nagyon gyenge a kapcsolat két osztály között. Egyáltalán nincsenek tagváltozókkal implementálva. Inkább tagfüggvény-argumentumokként valósíthatók meg.

Sokféleség[szerkesztés]

Ez az asszociációs kapcsolat azt jelzi, hogy (legalább) a két kapcsolódó osztály közül az egyik hivatkozik a másikra. Ezt a kapcsolatot általában úgy írják le, hogy "A-nak van B-je" (az anya macskának vannak cicái, a cicáknak van egy anyamacskája).

Egy asszociációs UML reprezentációja a két társított osztályt összekötő vonal. A sor mindkét végén választható jelölés található. Például egy nyílhegy segítségével jelezhetjük, hogy a hegyes vége látható a nyíl végéből. Jelölhetjük a tulajdonjogot egy kör elhelyezésével, az adott vég elemeinek szerepét a szerep név megadásával, valamint az entitás példányainak sokaságával (az asszociációban részt vevő objektumok számával a másik végén).

0 Nincs példány (ritka)
0..1 Nincsenek példányok, vagy csak egy példány
1 Pontosan egy példány
1...1 Pontosan egy példány
0. . * Nulla vagy több példány
* Nulla vagy több példány
1. . * Egy vagy több példány

Sztereotípiák elemzése[szerkesztés]

Entitások[szerkesztés]

Az entitásosztályok modellezik a rendszer által kezelt hosszú életű információkat, és néha az információhoz kapcsolódó viselkedést. Ezeket nem szabad adatbázistábláknak vagy más adattárolóknak azonosítani.

Körként vannak ábrázolva, egy rövid vonal a kör aljánál. Alternatív megoldásként normál osztályként is megrajzolhatók, az osztály neve fölött az „entitás” sztereotípia jelöléssel.

Hivatkozások[szerkesztés]

  1. Sparks: Database Modeling in UML. (Hozzáférés: 2011. szeptember 8.)
  2. Scott W. Ambler (2009) UML 2 Class Diagrams. Webdoc 2003-2009. Accessed Dec 2, 2009
  3. UML Reference Card, Version 2.1.2, Holub Associates, August 2007, <http://www.holub.com/goodies/uml/>. Hozzáférés ideje: 12 March 2011
  4. UML derived property is property which value is produced or computed from other information, for example, by using other properties.. www.uml-diagrams.org. (Hozzáférés: 2019. január 24.)
  5. OMG Unified Modeling Language (OMG UML) Superstructure, Version 2.3: May 2010. Retrieved 23 September 2010.
  6. Fowler (2003) UML Distilled: A Brief Guide to the Standard Object Modeling Language
  7. UML Tutorial part 1: class diagrams. [2007. január 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. július 18.)
  8. Goodwin: Modelling and Simulation, p. 26. The University of Warwick. (Hozzáférés: 2015. november 28.)

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Class diagram 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.

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

Kapcsolódó diagramok

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