UML diagram

Az egységes modellezési nyelv (Unified Modeling Language, UML) egy általános célú, fejlesztési célú modellezési nyelv a szoftverfejlesztés területén, amelynek célja, hogy szabványos módot biztosítson a rendszertervezés vizualizálására. [1]

Az UML-t eredetileg az a vágy motiválta, hogy egységesítse a szoftvertervezés különböző jelölési rendszereit és megközelítéseit, amelyeket Grady Booch, Ivar Jacobson és James Rumbaugh fejlesztett ki a Rational Software-nél 1994-95-ben, és 1996-ig ők vezették a további fejlesztést. [1]

Az UML-t 1997-ben az Object Management Group (OMG) fogadta el szabványként, és azóta ez a szervezet irányítja. 2005-ben az Egyesült Modellezési Nyelvet a Nemzetközi Szabványügyi Szervezet (ISO) is közzétette, mint jóváhagyott ISO-szabványt.[2] Azóta rendszeresen felülvizsgálják, hogy az UML legújabb revízióját lefedje. [3]

Bár az UML jól ismert és széles körben használt az oktatásban és a tudományos munkákban, 2013-ban az iparban kevéssé használták, és a legtöbb ilyen használat informális és ad hoc jellegű. [4]

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]

UML-diagramok

Strukturális UML-diagramok

  • Osztály diagram
  • Komponensdiagram
  • Összetett szerkezeti diagram
  • Telepítési diagram
  • Objektum diagram
  • Csomagdiagram
  • Profil diagram

Viselkedési UML-diagramok

  • Tevékenységi diagram
  • Kommunikációs diagram
  • Interakció áttekintő diagram
  • Szekvencia diagram
  • Állapotdiagram
  • Időzítési diagram
  • Használati eset diagram

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]

A cikk Kritika vagy ellentmondás című része veszélyeztetheti a cikk semleges nézőpontját a témával kapcsolatban. Kérjük, hogy a szakasz tartalmát építse be a cikk egészébe, vagy írja át az anyagot. (2010. december)

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".

Kérdések és válaszok

K: Mi az az egységes modellezési nyelv (UML)?


V: Az egységes modellezési nyelv (UML) a szoftverfejlesztésben használt modellezési nyelv, amely szabványos módot biztosít arra, hogy bemutassa, hogyan néz ki egy rendszer tervezése.

K: Mi volt az UML eredeti célja?


V: Az UML eredeti célja az volt, hogy szabványosítsa a szoftvertervezés különböző jelölési rendszereit és megközelítéseit.

K: Ki fejlesztette ki az UML-t?


V: Az UML-t Grady Booch, Ivar Jacobson és James Rumbaugh fejlesztette ki a Rational Software-nél 1994-1995-ben, és a további fejlesztést 1996-ig ők vezették.

K: Mikor fogadták el az UML-t szabványként?


V: Az UML-t 1997-ben fogadta el szabványként az Object Management Group (OMG).

K: Ki kezeli az UML-t?


V: Az UML-t az 1997-es szabványként való elfogadása óta az Object Management Group kezeli.

K: Az UML-t nemzetközi szabványként ismerték el?


V: Igen, az UML-t 2005-ben a Nemzetközi Szabványügyi Szervezet (ISO) nemzetközi szabványként ismerte el.

K: Mi az UML célja a szoftverfejlesztésben?


V: Az UML célja a szoftverfejlesztésben az, hogy szabványos módon mutassa be, hogyan néz ki egy rendszer tervezése, hogy az könnyen érthető és kommunikálható legyen a fejlesztők és az érdekelt felek között.

AlegsaOnline.com - 2020 / 2023 - License CC3