UML diagram

Tartalom:

 [hide] 

• 1 Történelem
• 1.1 Az UML 1.x előtt
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Tervezés
• 2.1 Szoftverfejlesztési módszerek
• 2.2 Modellezés
• 3 Diagramok
• 3.1 Szerkezeti ábrák
• 3.2 Viselkedési diagramok
• 3.2.1 Interakciós diagramok
• 4 Meta modellezés
• 5 Elfogadás
• 6 Kritika
• 6.1 Az UML 1.x kritikája

Történelem[forrás szerkesztése | szerkesztés]

Az objektumorientált módszerek és jelölések története

Az UML az 1990-es évek második fele óta fejlődik, és gyökerei az 1980-as évek végén és az 1990-es évek elején kifejlesztett objektumorientált módszerekből erednek. Az idővonal (lásd a képet) az objektumorientált modellezési módszerek és jelölések történetének főbb állomásait mutatja be.

Eredetileg a Booch-módszer, az objektum-modellezési technika (OMT) és az objektumorientált szoftverfejlesztés (OOSE) jelölésein alapul, amelyeket egyetlen nyelvbe integrált. ^[5]

Az UML 1.x előtt[forrás szerkesztése | szerkesztés]

A Rational Software Corporation 1994-ben vette fel James Rumbaugh-t a General Electric-től, és ezt követően a vállalat a kor két legnépszerűbb objektumorientált modellezési megközelítésének forrásává vált:^[6] Rumbaugh objektum-modellezési technikája (OMT) és Grady Booch módszere. Hamarosan Ivar Jacobson, az objektumorientált szoftverfejlesztés (OOSE) módszerének megalkotója segítette őket erőfeszítéseikben, aki 1995-ben csatlakozott hozzájuk a Rationalnál. ^[1]

Az említett három személy (Rumbaugh, Jacobson és Booch) technikai vezetésével 1996-ban UML Partners néven konzorciumot szerveztek, amelynek célja az egységes modellezési nyelv (UML) specifikációjának elkészítése és szabványosításra való javaslattétel az Object Management Group (OMG) számára. A partnerségben további érdekelt felek is részt vettek (például a HP, a DEC, az IBM és a Microsoft). Az UML Partners UML 1.0 tervezetét a konzorcium 1997 januárjában javasolta az OMG-nek. Ugyanebben a hónapban az UML Partners megalakított egy csoportot, amelynek célja a nyelvi konstrukciók pontos jelentésének meghatározása volt, Cris Kobryn elnökletével és Ed Eykholt adminisztrálásával, hogy véglegesítse a specifikációt és integrálja azt más szabványosítási erőfeszítésekkel. E munka eredményét, az UML 1.1-et 1997 augusztusában nyújtották be az OMG-hez, és az OMG 1997 novemberében fogadta el. ^[1][7]

UML 1.x[forrás szerkesztése | szerkesztés]

Az első kiadás után egy munkacsoport alakult^[1] a nyelv javítására, amely több kisebb felülvizsgálatot adott ki, az 1.3-at, az 1.4-et és az 1.5-öt. ^[8]

Az általa kidolgozott szabványok (valamint az eredeti szabvány) kétértelműnek és következetlennek bizonyultak. ^[9][10]

UML 2.x[forrás szerkesztése | szerkesztés]

Az UML 2.0 fő revíziója 2005-ben váltotta fel az 1.5-ös verziót, amelyet egy kibővített konzorciummal fejlesztettek ki a nyelv további javítása érdekében, hogy tükrözze a nyelv funkcióinak használatáról szerzett új tapasztalatokat. ^[11]

Bár az UML 2.1-t soha nem adták ki hivatalos specifikációként, 2007-ben megjelent a 2.1.1 és 2.1.2 verzió, majd 2009 februárjában az UML 2.2. Az UML 2.3 hivatalosan 2010 májusában jelent meg.^[12] Az UML 2.4.1 hivatalosan 2011 augusztusában jelent meg.^[12] Az UML 2.5 2012 októberében jelent meg "Folyamatban lévő" változatként, és hivatalosan 2015 júniusában adták ki. ^[12]

Az UML 2.x specifikáció négy részből áll:

1. A szuperstruktúra, amely meghatározza a diagramok és modellelemeik jelölését és szemantikáját.
2. Az infrastruktúra, amely meghatározza az alapvető metamodellt, amelyen a felépítmény alapul.
3. Az Object Constraint Language (OCL) a modellelemekre vonatkozó szabályok definiálására.
4. Az UML Diagram Interchange, amely meghatározza az UML 2 diagram elrendezések cseréjének módját.

E szabványok jelenlegi változatai a következők: UML Superstructure 2.4.1 verzió, UML Infrastructure 2.4.1 verzió, OCL 2.3.1 verzió és UML Diagram Interchange 1.0 verzió.^[13] A nyelvet folyamatosan frissíti és javítja a revíziós munkacsoport, amely a nyelvvel kapcsolatos problémákat orvosolja. ^[14]

Tervezés[forrás szerkesztése | szerkesztés]

Az egységes modellezési nyelv (Unified Modeling Language, UML) lehetőséget kínál a rendszer architektúra tervrajzának ábrázolására (lásd a képet), beleértve az alábbi elemeket: ^[5]

• Bármilyen tevékenység (munkahelyek)
• A rendszer egyes elemei
• És hogyan léphetnek kölcsönhatásba más szoftverkomponensekkel.
• Hogyan fog működni a rendszer
• Hogyan lépnek az entitások kölcsönhatásba másokkal (komponensek és interfészek)
• Külső felhasználói felület

Bár eredetileg kizárólag objektumorientált tervdokumentációra szánták, az egységes modellezési nyelvet (UML) kiterjesztették a tervdokumentáció szélesebb körére (a fentiekben felsoroltak szerint), ^[15]és számos kontextusban hasznosnak bizonyult. ^[16]

Szoftverfejlesztési módszerek[forrás szerkesztése | szerkesztés]

Az UML önmagában nem fejlesztési módszer;^[17] azonban úgy tervezték, hogy kompatibilis legyen a kor vezető objektumorientált szoftverfejlesztési módszereivel (példáulOMT, Booch-módszer, Objectory), és különösen a RUP-pal, amelyet eredetileg használni akartak, amikor a Rational Software Inc-nél elkezdődött a munka.

Modellezés[forrás szerkesztése | szerkesztés]

Fontos különbséget tenni az UML-modell és a rendszer diagramok halmaza között. A diagram a rendszer modelljének részleges grafikus ábrázolása. A diagramok halmazának nem kell teljesen lefednie a modellt, és egy diagram törlése nem változtatja meg a modellt. A modell tartalmazhat olyan dokumentációt is, amely a modellelemeket és a diagramokat vezérli (például írásos használati eseteket).

Az UML-diagramok a rendszermodell^[18] két különböző nézetét ábrázolják:

• Statikus (vagy strukturális) nézet: a rendszer statikus struktúráját hangsúlyozza objektumok, attribútumok, műveletek és kapcsolatok segítségével. A strukturális nézet magában foglalja az osztálydiagramokatés az összetett szerkezeti diagramokat.
• Dinamikus (vagy viselkedési) nézet: a rendszer dinamikus viselkedését hangsúlyozza az objektumok közötti együttműködések és az objektumok belső állapotainak változásainak bemutatásával. Ez a nézet szekvencia-diagramokat, tevékenység-diagramokat és állapotgép-diagramokat tartalmaz.

Az UML modellek az XML Metadata Interchange (XMI) csereformátum segítségével cserélhetők az UML-eszközök között.

Diagramok[forrás szerkesztése | szerkesztés]

Az UML 2 számos diagramtípust tartalmaz, amelyek két kategóriába sorolhatók.^[5] Egyes típusok szerkezeti információkat, a többi pedig általános viselkedéstípusokat ábrázol, köztük néhányat, amelyek a kölcsönhatások különböző aspektusait ábrázolják. Ezek a diagramok hierarchikusan kategorizálhatók, ahogy az a következő osztálydiagramon^[5] látható:

Ezek az ábrák mind tartalmazhatnak megjegyzéseket vagy megjegyzéseket, amelyek a használatot, a korlátozást vagy a szándékot magyarázzák.

Szerkezeti ábrák[szerkesztés forrás | szerkesztés]

A szerkezeti diagramok azokat a dolgokat hangsúlyozzák, amelyeknek jelen kell lenniük a modellezendő rendszerben. Mivel a szerkezeti diagramok a struktúrát ábrázolják, széles körben használják őket a szoftverrendszerek szoftverarchitektúrájának dokumentálásában. Ilyen például a komponensdiagram, amely leírja, hogy egy szoftverrendszer hogyan oszlik komponensekre, és megmutatja a komponensek közötti függőségeket.

• Komponensdiagram
• Osztály diagram

Viselkedési diagramok[forrás szerkesztése | szerkesztés]

A viselkedési diagramok azt hangsúlyozzák, hogy minek kell történnie a modellezett rendszerben. Mivel a viselkedési diagramok egy rendszer viselkedését szemléltetik, széles körben használják őket a szoftverrendszerek funkcionalitásának leírására. Példaként a tevékenységdiagram a rendszerben lévő komponensek üzleti és működési lépésről lépésre történő tevékenységeit írja le.

• Tevékenységi diagram
• Használati eset diagram

Kölcsönhatási diagramok[forrás szerkesztése | szerkesztés]

Az interakciós diagramok, a viselkedési diagramok egy alcsoportja, a vezérlés és az adatok áramlását hangsúlyozzák a modellezett rendszerben lévő dolgok között. Például a szekvencia diagram, amely azt mutatja be, hogy az objektumok hogyan kommunikálnak egymással üzenetsorozatok formájában.

• Szekvencia diagram
• Kommunikációs diagram

Meta modellezés[forrás szerkesztése | szerkesztés]

Fő cikk: Meta-Objektum eszköz

A meta-objektum eszköz illusztrációja

Az Object Management Group (OMG) kifejlesztett egy metamodellezési architektúrát az Unified Modeling Language (UML) meghatározásához, amelyet Meta-Object Facility-nek (MOF) neveznek.^[19] A Meta-Object Facility négyrétegű architektúrát alkot, ahogy a jobb oldali képen látható. A legfelső, M3 rétegnek nevezett rétegben egy meta-meta modellt biztosít. Ez az M3-modell az a nyelv, amelyet a Meta-Object Facility a metamodellek, az úgynevezett M2-modellek felépítéséhez használ.

A 2. réteg meta-objektum modelljének legjelentősebb példája az UML metamodellje, az UML-t leíró modell. Ezek az M2-modellek az M1-réteg elemeit, tehát M1-modelleket írnak le. Ezek lennének például az UML-ben megírt modellek. Az utolsó réteg az M0-réteg vagy adatréteg. Ez a rendszer futásidejű példányainak leírására szolgál. ^[20]

A meta-modell egy sztereotipizálásnak nevezett mechanizmus segítségével bővíthető. Ezt Brian Henderson-Sellers és Cesar Gonzalez-Perez a "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" című cikkében elégtelennek/tarthatatlanul kritizálta. ^[21]

Örökbefogadás[forrás szerkesztése | szerkesztés]

Az UML számos tervezési kontextusban hasznosnak bizonyult, ^[16]olyannyira, hogy az informatikai közösségben már szinte mindenütt jelen van. ^[22]

Időnként úgy kezelték, mint egy tervezési csodafegyvert, ami problémákhoz vezetett a használata során. A helytelen használat magában foglalja a túlzott használatát (a rendszer kódjának minden kis részét ezzel tervezik, ami szükségtelen) és azt a feltételezést, hogy bárki bármit meg tud vele tervezni (még azok is, akik nem programoztak). ^[23]

Úgy tűnik, hogy ez egy nagy nyelv, sok konstrukcióval. Egyesek (köztük Jacobson) úgy vélik, hogy túl sok van belőle, és ez akadályozza a tanulást (és így a használatát). ^[24]

Kritikák[forrás szerkesztése | szerkesztés]

Az UML-t az ipar részéről gyakran kritizálják: ^[4]

• nem hasznos: "[nem] nyújt számukra előnyöket a jelenlegi, kialakult gyakorlataikhoz és képviseleteikhez képest."
• túl bonyolult, különösen az ügyfelekkel való kommunikáció szempontjából: "szükségtelenül bonyolult" és "A legjobb ok az UML használatának mellőzésére az, hogy nem minden érdekelt fél számára "olvasható". Mennyit ér az UML, ha az üzleti felhasználó (az ügyfél) nem érti a modellezési erőfeszítéseid eredményét?".
• szinkronban kell tartani az UML-t és a kódot, ahogyan a dokumentációt általában is.

Az UML 1.x kritikája[forrás szerkesztése | szerkesztés]

Kardinalitás jelölés

Az adatbázisokhoz hasonlóan Chen, Bachman és az ISO ER-diagramok esetében az osztálymodellek a "look-across" kardinalitások használatára vannak specifikálva, annak ellenére, hogy több szerző (többek^[27] között Merise,^[25] Elmasri és Navathe^[26]) az azonos oldali vagy "look-here" kardinalitásokat részesíti előnyben a szerepek és a minimális és maximális kardinalitások esetében. A legújabb kutatók (Feinerer, ^[28]Dullea és mások^[29]) kimutatták, hogy az UML és az ER-diagramok által használt "look-across" technika kevésbé hatékony és kevésbé koherens, ha >2 rendű n-áras kapcsolatokra alkalmazzák.

Feinerer szerint "Problémák merülnek fel, ha az UML-asszociációkhoz használt look-across szemantika alapján dolgozunk. Hartmann ^[30]megvizsgálja ezt a helyzetet, és megmutatja, hogyan és miért vallanak kudarcot a különböző transzformációk." (Bár az említett "redukció" hamis, mivel a 3.4. és a 3.5. diagram valójában ugyanaz), valamint "Mint a következő oldalakon látni fogjuk, a look-across értelmezés számos nehézséget vezet be, amelyek megakadályozzák az egyszerű mechanizmusok kiterjesztését a bináris asszociációkról az n-ary asszociációkra".