Az UML ( angolul Unified Modeling Language – egységes modellezési nyelv) egy grafikus leíró nyelv objektummodellezéshez a szoftverfejlesztés területén , üzleti folyamatok modellezésére , rendszertervezésre és szervezeti struktúrák megjelenítésére .
Az UML egy általános nyelv, egy nyílt szabvány , amely grafikus jelölést használ az UML modellnek nevezett rendszer absztrakt modelljének létrehozásához . Az UML-t alapvetően szoftverrendszerek meghatározására, megjelenítésére, tervezésére és dokumentálására hozták létre . Az UML nem programozási nyelv , de kódgenerálás lehetséges az UML modellek alapján .
Az UML azt is lehetővé teszi a szoftverfejlesztők számára, hogy megállapodjanak a grafikus jelölésekben az általános fogalmak (például osztály , komponens , általánosítás , aggregáció és viselkedés ) megjelenítéséhez , és hogy jobban összpontosítsanak a tervezésre és az architektúrára .
Az UML modellező nyelv megjelenésének előfeltételei az objektum-orientált programozási nyelvek ( Simula 67 , Smalltalk , Objective C , C++ stb.) 20. század második felében bekövetkezett rohamos fejlődése kapcsán kerültek meghatározásra . . A megalkotott szoftvertermékek folyamatos bonyolódása miatt egyre több nyelvi és fejlesztőeszköz-újdonságot kell figyelembe venni az elemzés, a követelmények megfogalmazása és a szoftveralkalmazások tervezése során. Például 1989 és 1994 között rövid idő alatt az objektumorientált eszközök száma egy tucatról több mint ötvenre nőtt. Sok fejlesztő azonban nehezen tudta kiválasztani azt a modellezési nyelvet, amely teljes mértékben kielégíti minden igényét. Ennek eredményeként a fejlesztési módszerek új generációja jelent meg, amelyek között különösen népszerűvé vált a Jacobson Object-Oriented Software Engineering ( OOSE ) és a Rambaud Object Modeling Technique ( OMT ) által kifejlesztett Booch-módszer . Rajtuk kívül léteztek még olyan kész technológiák, mint a Fusion , a Shlaer-Mellor és a Coad-Yourdon , azonban mindegyiknek nemcsak előnyei, hanem jelentős hátrányai is voltak [1] .
1994- ben a Rational Software -nél dolgozó Grady Booch és James Rumbaugh egyesítette erőit egy új objektum-orientált modellezési nyelv létrehozása érdekében. A nyelv alapjául az Object-Modeling Technique és a Booch modellezési módszereit vették. Az OMT az elemzésre, míg a Booch a szoftverrendszerek tervezésére összpontosított. 1995 októberében megjelent az Unified Method előzetes 0.8 -as verziója . 1995 őszén Ivar Jakobson , az Object-Oriented Software Engineering - OOSE szerzője csatlakozott a Rationalhoz . Az OOSE kiváló lehetőségeket biztosított az üzleti folyamatok meghatározásához és a követelmények felhasználási eseteken keresztüli elemzéséhez . Az OOSE is beépült az egységes módszerbe.
Ebben a szakaszban az UML fejlesztési folyamat megszervezésének fő szerepe az OMG (Object Management Group) konzorciumra szállt át . Az OMG tervezőcsapata, amelybe Butch, Rambeau és Jacobson (a "három barát" is) tartozott, 1996 júniusában és októberében kiadta az UML 0.9-es és 0.91-es verzióját .
| Változat | Elfogadás dátuma |
|---|---|
| 1.1 | 1997. november [2] |
| 1.3 | 2000. március [3] |
| 1.4 | 2001. szeptember [4] |
| 1.4.2 | 2004. július [3] |
| 1.5 | 2003. március [5] |
| 2.0 | 2005. július [6] |
| 2.1 | formálisan nem fogadták el [3] |
| 2.1.1 | 2007. augusztus [7] |
| 2.1.2 | 2007. november [8] |
| 2.2 | 2009. február [9] |
| 2.3 | 2010. május [10] |
| 2.4 béta 2 | 2011. március [11] |
| 2.5 | 2015. június [12] |
| 2.5.1 | 2017. december [13] |
Az UML iránti növekvő érdeklődés nyomán olyan cégek csatlakoztak az új verziók fejlesztéséhez, mint a Digital Equipment Corporation , a Hewlett-Packard , az i-Logix, az IntelliCorp, az IBM , az ICON Computing, az MCI Systemhouse, a Microsoft , az Oracle Corporation , a Rational Software . nyelv az UML Partners konzorcium , a Texas Instruments és a Unisys keretein belül . Az együttműködés eredménye az UML 1.0 specifikáció, amelyet 1997 januárjában adtak ki . Ugyanezen év novemberében követte az 1.1-es verzió, amely jelölési fejlesztéseket, valamint néhány szemantikai kiterjesztést tartalmazott.
Az UML későbbi kiadásai tartalmazták az 1.3-as, 1.4-es és 1.5-ös verziókat, amelyeket 1999 júniusában, 2001 szeptemberében és 2003 márciusában tettek közzé .
Az UML 1.4.2-t az ISO / IEC 19501:2005 [12] nemzetközi szabványként fogadták el .
Az UML 2.0 hivatalos specifikációja 2005 augusztusában jelent meg. A nyelv szemantikáját jelentősen finomították és kiterjesztették a Model Driven Development- MDD módszertan támogatására . Az UML 2.5 legújabb verziója 2015 júniusában jelent meg.
Az UML 2.4.1-et az ISO / IEC 19505-1, 19505-2 [12] nemzetközi szabványként fogadták el .
Az UML-ben a következő típusú diagramokat használják (a kétértelműség kiküszöbölése érdekében az angol nyelvű jelölést is megadjuk):
|
Szerkezeti diagramok:
Viselkedési diagramok:
|
Szerkezeti diagramok:
Viselkedési diagramok:
|
Az UML 2.3 diagramok szerkezete egy UML osztálydiagramban ábrázolható:
Osztálydiagram (Osztálydiagram) - statikus szerkezeti diagram, amely leírja a rendszer felépítését, bemutatva a rendszer osztályait, attribútumait, metódusait és az osztályok közötti függőségeket.
Az osztálydiagramok felépítésével kapcsolatban eltérő álláspontok léteznek, alkalmazásuk céljától függően:
Komponens diagram (Component diagram) - statikus szerkezeti diagram, a szoftverrendszer szerkezeti komponensekre való felosztását és az összetevők közötti kapcsolatokat (függőségeket) mutatja be. A fizikai összetevők lehetnek fájlok, könyvtárak, modulok, futtatható fájlok, csomagok stb.
Összetett szerkezeti diagram ( Összetett szerkezeti diagram) - egy statikus szerkezeti diagram, amely bemutatja az osztályok belső szerkezetét, és ha lehetséges, az osztály belső szerkezetének elemeinek (részeinek) kölcsönhatását.
Az összetett szerkezeti diagramok egyik alfaja az együttműködési diagramok (Collaboration diagram, bevezetve az UML 2.0-ban), amelyek az osztályok szerepét és interakcióit mutatják be az együttműködésen belül. Az együttműködések hasznosak a tervezési minták modellezésekor .
Az összetett szerkezeti diagramok osztálydiagramokkal együtt használhatók.
Telepítési diagram ( telepítési diagram) – a működő csomópontok (hardver, angol node ) ésa rájuk telepített műtermékek modellezésére szolgál. Az UML 2 műtermékeket telepített a csomópontokra , míg az UML 1 összetevőket a csomópontokra. Megnyilvánulási függőség jön létre egy műtermék és az általa megvalósított logikai elem (összetevő) között.
Objektumdiagram – a szimulált rendszer teljes vagy részleges pillanatfelvételét mutatja egy adott időpontban. Az objektumdiagram megjeleníti a rendszer osztálypéldányait (objektumait) attribútumuk aktuális értékeivel és az objektumok közötti hivatkozásokkal.
Csomag diagram (Package diagram) - szerkezeti diagram, amelynek fő tartalma a csomagok és a köztük lévő kapcsolatok. Nincs szigorú elválasztás a különböző szerkezeti diagramok között, ezért ezt az elnevezést csak kényelmi okokból ajánljuk, és nincs szemantikai jelentése (a csomagok és csomagdiagramok más szerkezeti diagramokon is megjelenhetnek). A csomagdiagramok mindenekelőtt arra szolgálnak, hogy az elemeket valamilyen attribútum szerint csoportokba rendezzék, hogy a rendszermodellel egyszerűsítsék a munka felépítését és szervezését.
Tevékenységdiagram - egy diagram , amely bemutatja bizonyos tevékenységek összetevőire való felbomlását. A tevékenység a végrehajtható viselkedés specifikációja alárendelt elemek – egymásba ágyazott tevékenységek és különálló műveletek ( angolul action ) – koordinált szekvenciális és párhuzamos végrehajtása formájában,amelyeket az egyik csomópont kimeneteitől a másik bemeneteihez vezető folyamok kapcsolnak össze.
A tevékenységdiagramokat üzleti folyamatok, technológiai folyamatok, soros és párhuzamos számítások modellezésére használják.
A tevékenységdiagramok analógjai a GOST 19.701-90 szerinti algoritmussémák és a sárkánysémák .
Automata diagram (Állapotgép diagram, véges állapotú gép diagram , állapotdiagram ) - olyan diagram, amely egy véges állapotú gépet mutat be egyszerű állapotokkal , átmenetekkel és összetett állapotokkal.
Az állapotgép azon állapotok sorozatának specifikációja, amelyeken egy objektum vagy interakció áthalad életének eseményeire adott válaszként, valamint az objektum válasza ezekre az eseményekre. Az állapotgép egy forráselemhez ( osztályhoz , együttműködéshez vagy metódushoz) van csatolva, és a példányai viselkedésének meghatározására szolgál.
Az automata diagramok (állapotdiagramok) analógjai a sárkánydiagramok .
A használati eset diagram vagy a használati eset diagram (Use case diagram) egy diagram, amely bemutatja a szereplők és a használati esetek közötti kapcsolatokat .
A fő cél egyetlen olyan eszköz biztosítása, amely lehetővé teszi az ügyfél, a végfelhasználó és a fejlesztő számára, hogy közösen megvitassák a rendszer funkcionalitását és viselkedését.
A kommunikációs és szekvenciadiagramok tranzitívak , interakciót fejeznek ki, de azt különböző módon mutatják be, és kellő pontossággal konvertálhatók egyikből a másikba.
Kommunikációs diagram (Kommunikációs diagram, UML 1.x-ben - együttműködési diagram , együttműködési diagram ) - olyan diagram, amely egy összetett struktúra részei közötti interakciókat vagy együttműködési szerepeket ábrázol. A szekvenciadiagrammal ellentétben a kommunikációs diagram kifejezetten jelzi az elemek (objektumok) közötti kapcsolatot, és nem használja az időt külön dimenzióként (hívó sorszámokat használnak).
Szekvencia diagram - egy diagram, amely bemutatja az objektumok kölcsönhatásait, a megnyilvánulásuk időpontja szerint rendezve. Különösen az interakcióban részt vevő objektumokat és az általuk kicserélt üzenetek sorozatát ábrázolja.
Együttműködési diagram – Ez a diagramtípus lehetővé teszi az objektumok interakcióinak leírását, elvonatkoztatva az üzenettovábbítás sorrendjétől. Ez a diagramtípus kompakt formában tükrözi egy adott objektum összes fogadott és továbbított üzenetét, valamint ezen üzenetek típusait.
Mivel a szekvencia- és együttműködési diagramok ugyanazon folyamatok különböző nézetei, a Rational Rose lehetővé teszi együttműködési diagramok létrehozását a szekvenciadiagramokból és fordítva, valamint automatikusan szinkronizálja ezeket a diagramokat.
Az interakciós áttekintő diagram egyfajta tevékenységdiagram, amely szekvenciadiagram-részleteket és vezérlőfolyamat-konstrukciókat tartalmaz.
Ez a fajta diagram magában foglalja a szekvencia diagramot (műveletsorozatok diagramjai) és az együttműködési diagramot (együttműködési diagramok). Ezek a diagramok lehetővé teszik, hogy a létrehozandó rendszerben lévő objektumok interakcióját különböző nézőpontokból megvizsgálja.
Időzítési diagram - a szekvenciadiagram alternatív ábrázolása, amely explicit módon mutatja az életvonalon az állapotváltozásokat adott időskálán. Valós idejű alkalmazásokban hasznos lehet.
Annak ellenére, hogy az UML meglehetősen elterjedt és használt szabvány, gyakran kritizálják a következő hiányosságok miatt:
| Egységes modellezési nyelv | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
| |||||||||||
| |||||||||||
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|
| ISO szabványok | |
|---|---|
| |
| 1 -től 9999 -ig |
|
| 10 000 és 19999 között |
|
| 20000+ | |
| Lásd még: Azon cikkek listája, amelyek címe "ISO"-val kezdődik | |