UML modell(UML-modell) nyelvi konstrukciók véges halmaza, amelyek fő része az entitások és a köztük lévő kapcsolatok.
Maguk a modell entitásai és kapcsolatai a metamodell metaosztályainak példányai.
Az UML modellt a legáltalánosabb helyzetekből nézve elmondhatjuk, hogy ez egy gráf (pontosabban egy betöltött multi-pszeudo-hiperdigráf), amelyben csúcsok és élek vannak betöltve. további információés bonyolult belső szerkezetű lehet. Ennek a gráfnak a csúcsait entitásoknak, az éleit pedig relációknak nevezzük.. A rész többi része egy folyékony (előzetes) de teljes áttekintés elérhető entitástípusok és kapcsolatok. Szerencsére nincs belőlük túl sok. A könyv következő fejezeteiben minden entitást és kapcsolatot újra megvizsgálunk, részletesebben és példákkal.
Az áttekintés megkönnyítése érdekében az UML entitásai négy csoportra oszthatók:
A strukturális entitások, ahogy sejthető, a szerkezet leírására szolgálnak. A strukturális entitások általában a következőket tartalmazzák.
Egy tárgy Az (objektum) 1 olyan entitás, amely egyediséggel rendelkezik, és magában foglalja az állapotot és a viselkedést.
Osztály(osztály) 2 - az állapotot és a viselkedést meghatározó műveleteket meghatározó közös attribútumokkal rendelkező objektumok halmazának leírása.
Felület(interfész) 3 a műveletek nevesített halmaza, amely meghatározza a fogyasztó által igényelhető és a szolgáltató által nyújtott szolgáltatások halmazát.
Együttműködés(együttműködés) 4 - olyan objektumok halmaza, amelyek kölcsönhatásba lépnek valamilyen cél elérése érdekében.
Színész(szereplő) 5 egy olyan entitás, amely kívül esik a modellezett rendszeren, és közvetlenül kölcsönhatásba lép vele.
∇ Ilyen kapcsolat minden bizonnyal létezik, amit a 2. ábra is kifejez. Diagramtípus-hierarchia az UML 1-hez mint függőségi viszony a „finomítás” sztereotípiával.
∇∇ Az UML 1-ben önkéntelen összefüggés volt egy együttműködési diagram és egy azonos nevű entitás között, ami nem volt teljesen igaz, és néha félrevezető is volt.
∇∇∇ Az UML 2-ben az állapotdiagram szintaktikai és szemantikai terhelése annyira megváltozott, hogy a név már nem tükrözi a tartalmat.
Az alábbiakban található az ebben a könyvben elfogadott új diagramok listája és nevük.
ábrán. Diagramtípus-hierarchia az UML 2-hez (1. és 2. rész) osztálydiagram, amely a diagramok kapcsolatát mutatja az UML 2-ben.
A fejezet későbbi részében mind a tizenhárom kanonikus diagramot nagyon röviden leírjuk, hogy legyen némi kontextus és szókincs a következőkhöz. A részleteket a könyv többi fejezete tartalmazza.
Mielőtt azonban továbblépnénk a következő szakaszra, tegyünk egy kis kitérőt azzal kapcsolatban, hogy a szabvány hogyan írja elő a diagramok formázását. Az általános diagram bemutatási sablon az alábbiakban látható.
Két fő tervezési elem van: egy külső keret és egy címke a diagram nevével. Ha minden egyszerű a kerettel - ez egy téglalap, amely határolja azt a területet, amelyben a diagram elemeinek el kell helyezkedniük, akkor a diagram nevét egy speciális formátumban írják, amely az ábrán látható. Diagram jelölése.
Ezt az összetett lapformát nem minden eszköz támogatja. Ez azonban nem szükséges, mivel a szemantika elsődleges, a jelölés pedig másodlagos. A következőkben téglalapot használunk diagramcímkeként, és ez nem okozhat félreértést.
A diagramok lehetséges címkéi (típusai) a következő táblázatban láthatók. A szabvány által kínált címkék a második oszlopba vannak írva. A gyakorlat azonban azt mutatja, hogy a szabvány által javasolt szabályok nem mindig kényelmesek és logikailag indokoltak, ezért a táblázat harmadik oszlopa véleményünk szerint ésszerű alternatívát tartalmaz.
Tab. Diagramtípusok és címkék
| Diagram neve | Címke (normál) | Címke (javasolt) |
|---|---|---|
| Használati diagram | használati eset vagy uc | használati eset |
| osztálydiagram | osztály | osztály |
| automata diagram | állapotgép vagy stm | állapotgép |
| tevékenység diagram | tevékenység vagy törvény | tevékenység |
| szekvencia diagram | kölcsönhatás vagy SD | SD |
| Kommunikációs diagram | kölcsönhatás vagy SD | comm |
| Alkatrész diagram | összetevő vagy cmp | összetevő |
| Elhelyezési diagram | meghatározatlan | bevetése |
| Objektum diagram | meghatározatlan | tárgy |
| A belső szerkezet diagramja | osztály | osztály vagy összetevő |
| Interakció áttekintése diagram | kölcsönhatás vagy SD | kölcsönhatás |
| Időzítési diagram | kölcsönhatás vagy SD | időzítés |
| Csomag diagram | csomag vagy pkg | csomag |
Az UML ma a szoftverrendszerek vizuális modellezésének szabványos jelölése, amelyet az Object Managing Group (OMG) 1997 őszén fogadott el, és amelyet számos objektum-orientált CASE termék támogat.
Az UML szabvány a következő diagramokat kínálja a modellezéshez:
Használati eset diagram (use case diagram) - egy szervezet vagy vállalkozás üzleti folyamatainak modellezésére és a létrehozandó információs rendszer követelményeinek meghatározására;
osztálydiagram (osztálydiagram) - a rendszerosztályok statikus szerkezetének és a köztük lévő kapcsolatok modellezésére;
rendszer viselkedési diagramja (viselkedési diagramok);
interakciós diagramok;
Szekvenciadiagramok - az objektumok közötti üzenetküldési folyamat modellezésére egy használati eseten belül;
együttműködési diagram (együttműködési diagram) - ugyanazon használati eseten belüli objektumok közötti üzenetküldési folyamat modellezésére;
állapotdiagram diagram - a rendszerobjektumok viselkedésének modellezésére az egyik állapotból a másikba való átmenet során;
tevékenység diagram - a rendszer viselkedésének modellezésére különböző használati esetek, vagy modellezési tevékenységek keretein belül;
megvalósítási diagram (megvalósítási diagramok):
Komponens diagramok (komponens diagramok) - információs rendszer összetevői (alrendszerei) hierarchiájának modellezésére;
telepítési diagram (telepítési diagram) - modellezéshez fizikai építészet tervezett információs rendszer.
ábrán. Az 1.1 az információs rendszer integrált modelljét mutatja be, beleértve a kurzusprojektben kidolgozandó fő diagramokat.
Rizs. 1. Információs rendszer integrált modellje az UML nyelv jelölésében
4.2. Használati eset diagram
A használati eset a rendszer által valamilyen külső objektum (aktor) által kiváltott eseményre válaszul végrehajtott műveletek sorozata. A használati eset egy tipikus interakciót ír le a felhasználó és a rendszer között. A legegyszerűbb esetben a használati esetet a felhasználóval való megbeszélés során határozzuk meg, hogy milyen funkciókat szeretne megvalósítani ebben az információs rendszerben. Az UML-ben a használati eset a következőképpen jelenik meg:
2. ábra. Használati eset
A szereplő egy olyan szerep, amelyet a felhasználó a rendszerrel kapcsolatban betölt. A színészek szerepeket képviselnek, nem konkrét személyeket vagy beosztásokat. Bár a használati eset diagramokon stilizált emberalakként ábrázolják őket, a színész külsőleg is lehet. tájékoztatási rendszer, aminek szüksége van némi információra az adott rendszerből. Csak akkor jelenítse meg a szereplőket diagramon, ha valóban szükségük van néhány felhasználási esetre. Az UML-ben a szereplőket alakzatokként ábrázolják:
3. ábra. Karakter (színész)
A színészek három fő típusra oszthatók:
Felhasználók
rendszerek;
Más rendszerek, amelyek kölcsönhatásba lépnek ezzel;
Az idő akkor válik cselekvővé, ha attól függ a rendszer bármely eseményének kiváltása.
4.2.1. A felhasználási esetek és a szereplők közötti kapcsolatok
Az UML-ben a használati eset diagramok többféle kapcsolatot támogatnak a diagramelemek között:
Kommunikáció (kommunikáció),
Befoglalás (beleértve),
bővítés (kiterjesztés),
általánosítás.
kommunikáció kommunikáció a használati eset és a szereplő kapcsolata. Az UML-ben a kommunikációs kapcsolatok egyirányú társítással (folytonos vonal) jelennek meg.
4. ábra. Példa kommunikációs linkre
Befogadási kapcsolat olyan helyzetekben használatos, amikor a rendszer viselkedésének egy része egynél több használati esetben ismétlődik. Az ilyen hivatkozások segítségével általában egy újrafelhasználható függvényt modelleznek.
Hosszabbító csatlakozás a rendszer normál viselkedésében bekövetkezett változások leírására szolgál. Lehetővé teszi egy használati eset opcionális használatát funkcionalitás másik használati eset.
5. ábra. Példa a befogadási és kiterjesztési kapcsolatra
Kommunikációs általánosítás azt jelzi, hogy több szereplőnek vagy osztálynak vannak közös tulajdonságai.
6. ábra. Példa az általánosító kapcsolatra
4.3.
Kölcsönhatás diagramokírja le az egymással kölcsönható objektumcsoportok viselkedését. Az interakciós diagramok általában csak az objektumok viselkedését fedik le egyetlen használati eseten belül. Egy ilyen diagram számos objektumot és az általuk egymással cserélt üzeneteket jelenít meg.
üzenet az az eszköz, amellyel a küldő objektum felkéri a fogadó objektumot az egyik művelet végrehajtására.
Tájékoztató (tájékoztató) üzenet egy üzenet, amely a fogadó objektumot bizonyos információkkal látja el az állapot frissítéséhez.
Kérdő üzenet (kérdező) egy üzenet, amely bizonyos információk kiadását kéri a fogadó objektumról.
Kötelező üzenet egy üzenet, amely felkéri a vevőt valamilyen művelet végrehajtására.
Kétféle interakciós diagram létezik: szekvenciadiagram és együttműködési diagram.
4.3.1. Szekvencia diagramok
szekvencia diagram az egyetlen használati eseten belül előforduló események áramlását tükrözi.
Az adott forgatókönyvben (használati eset) részt vevő összes szereplő (aktorok, osztályok vagy objektumok) a diagram tetején látható. A nyilak a szereplő és egy objektum, illetve az objektumok között a szükséges funkciók végrehajtása érdekében átadott üzeneteknek felelnek meg.
A sorozatdiagramban egy objektum téglalapként van ábrázolva, amelyből egy szaggatott függőleges vonal húzódik lefelé. Ezt a vonalat hívják egy tárgy életvonala . Egy tárgy életciklusának töredéke az interakció folyamatában.
Minden üzenet nyílként jelenik meg két objektum életvonala között. Az üzenetek abban a sorrendben jelennek meg, ahogy fentről lefelé jelennek meg az oldalon. Minden üzenet legalább az üzenet nevével meg van címkézve. Opcionálisan argumentumokat és vezérlőinformációkat is hozzáadhat. Megjelenítheti az öndelegációt, egy üzenetet, amelyet egy objektum küld magának, és az üzenet nyíl ugyanarra a mentővonalra mutat.
Rizs. 7. Példa a szekvencia diagramra
4.3.2. Együttműködési diagram
Együttműködési diagramok az események folyamatának megjelenítése egy adott forgatókönyvön belül (használati eset). Az üzenetek idő szerint vannak rendezve, bár az együttműködési diagramok inkább az objektumok közötti kapcsolatokra összpontosítanak. Az együttműködési diagramok a sorozatdiagramok összes információját mutatják, de az együttműködési diagram más módon írja le az események folyamatát. Ebből könnyebb megérteni az objektumok közötti kapcsolatokat.
Az együttműködési diagramban, akárcsak a sorozatdiagramban, a nyilak a kereten belül kicserélt üzeneteket jelölik. ezt a lehetőséget használat. Időbeli sorrendjüket az üzenetek számozása jelzi.
Rizs. 8. Példa együttműködési diagramra
4.4. osztálydiagram
4.4.1. Általános információ
osztálydiagram meghatározza a rendszerosztályok típusait és a köztük létező különféle statikus kapcsolatokat. Az osztálydiagramok osztályattribútumokat, osztályműveleteket és megszorításokat is mutatnak, amelyek az osztályok közötti kapcsolatokra vonatkoznak.
Az osztálydiagram az UML-ben egy gráf, amelynek csomópontjai a projekt statikus struktúrájának elemei (osztályok, interfészek), az ívek pedig a csomópontok közötti kapcsolatokat (asszociációk, öröklődés, függőségek).
Az osztálydiagram a következő elemeket mutatja:
· Csomag (csomag) - a modell elemeinek halmaza, amelyek logikailag kapcsolódnak egymáshoz;
· Osztály (osztály) - hasonló objektumok csoportjának közös tulajdonságainak leírása;
· Interfész (interfész) - egy absztrakt osztály, amely meghatározza a műveletek halmazát, amelyet egy adott interfészhez társított tetszőleges osztály objektuma más objektumok számára biztosít.
4.4.2. Osztály
Osztály olyan entitások (objektumok) csoportja, amelyek hasonló tulajdonságokkal, nevezetesen adatokkal és viselkedéssel rendelkeznek. Egy osztály egyes tagját az osztály objektumának, vagy egyszerűen objektumnak nevezzük.
Az objektumok viselkedése az UML-ben minden olyan szabályra vonatkozik, amely egy objektumnak a külvilággal és magának az objektumnak az adataival való interakciójára vonatkozik.
A diagramokon egy osztályt egy téglalapként ábrázolnak, szilárd szegéllyel, amelyet vízszintes vonalak 3 részre osztanak:
A felső rész (a név rész) tartalmazza az osztály nevét és egyéb általános tulajdonságokat (különösen a sztereotípiát).
A középső rész az attribútumok listáját tartalmazza
Alul az osztályműveletek listája található, amelyek tükrözik az osztály viselkedését (az osztály által végrehajtott műveletek).
Előfordulhat, hogy az attribútumok és műveletek egyike sem jelenik meg (vagy mindkettő). A hiányzó szakaszhoz nem kell választóvonalat húznia, és valahogy jeleznie kell az elemek jelenlétét vagy hiányát.
További szakaszok, például Kivételek, egy adott megvalósítás belátása szerint vezethetők be.
Rizs. 9. Osztálydiagram példa
4.4.2.1.Osztálysztereotípiák
Az osztálysztereotipizálás az osztályok kategóriákba sorolásának mechanizmusa.
Az UML három fő osztálysztereotípiát határoz meg:
Határ (határ);
Entitás (entitás);
Irányítás (menedzsment).
4.4.2.2.Határosztályok
A határosztályok azok az osztályok, amelyek a rendszer és a teljes környezet határán helyezkednek el. Ezek kijelzők, jelentések, hardverrel (például nyomtatókkal vagy szkennerekkel) való interfészek és más rendszerekkel való interfészek.
A határosztályok megtalálásához fel kell fedeznie a használati eset diagramokat. A szereplő és a használati eset közötti minden interakciónak legalább egy határosztályt kell tartalmaznia. Ez az osztály teszi lehetővé a szereplő számára, hogy interakcióba lépjen a rendszerrel.
4.4.2.3.Entitásosztályok
Az entitásosztályok tárolt információkat tartalmaznak. Ezek jelentik a legnagyobb jelentést a felhasználó számára, ezért nevükben gyakran a tárgykör kifejezéseit használják. Általában minden entitásosztályhoz egy tábla jön létre az adatbázisban.
4.4.2.4.Ellenőrző osztályok
A kontroll osztályok felelősek más osztályok tevékenységeinek koordinálásáért. Általában minden használati esetnek van egy vezérlőosztálya, amely az adott használati eset eseménysorozatát vezérli. A vezérlő osztály felelős a koordinációért, de önmagában nem hordoz semmilyen funkcionalitást, mivel a többi osztály nem küldi el egy nagy számüzenetek. Ehelyett ő maga küld egy csomó üzenetet. A menedzser osztály egyszerűen átruházza a felelősséget más osztályokra, ezért gyakran menedzser osztálynak nevezik.
Lehetnek más vezérlési osztályok is a rendszerben, amelyek több használati esetre is jellemzőek. Például létezhet egy SecurityManager osztály, amely a biztonsággal kapcsolatos események figyeléséért felelős. A TransactionManager osztály kezeli az adatbázis-tranzakciókkal kapcsolatos üzenetek koordinálását. A rendszer működésének egyéb elemeivel, például az erőforrások megosztásával, az elosztott adatfeldolgozással vagy a hibakezeléssel más menedzserek is foglalkozhatnak.
A fent említett sztereotípiákon kívül létrehozhat sajátot is.
4.4.2.5.Attribútumok
Az attribútum egy osztályhoz társított információ. Az attribútumok beágyazott osztályadatokat tárolnak.
Mivel az attribútumok az osztályon belül vannak, el vannak rejtve a többi osztály elől. Emiatt szükséges lehet megadni, hogy mely osztályoknak van joguk attribútumok olvasására és módosítására. Ezt a tulajdonságot attribútum láthatóságnak nevezzük.
Az attribútum négy lehetséges értéket tartalmazhat ehhez a paraméterhez:
Nyilvános (általános, nyitott). Ez a láthatósági érték feltételezi, hogy az attribútum az összes többi osztály számára látható lesz. Bármely osztály megtekintheti vagy módosíthatja egy attribútum értékét. Az UML jelöléssel összhangban a közös attribútumot "+" jel előzi meg.
Privát (zárt, titkos). A megfelelő attribútum nem látható más osztály számára. A privát attribútumot az UML jelöléssel összhangban "-" jellel jelöljük.
Védett (védett). Egy ilyen attribútum csak maga az osztály és leszármazottai számára elérhető. A védett attribútum UML-jelölése a „#” jel.
Csomag vagy megvalósítás (kötegelt). Tegyük fel, hogy az adott attribútum meg van osztva, de csak a csomagjában. Az ilyen típusú láthatóságot semmilyen speciális ikon nem jelzi.
A zártság vagy a biztonság segítségével elkerülhető az a helyzet, amikor az attribútumértéket a rendszer minden osztálya megváltoztatja. Ehelyett az attribútummódosítási logika ugyanabba az osztályba kerül, mint maga az attribútum. A beállított láthatósági beállítások hatással lesznek a generált kódra.
4.4.2.6.Tevékenységek
A műveletek osztályhoz kapcsolódó viselkedést valósítanak meg. Egy művelet három részből áll: névből, paraméterekből és visszatérési típusból.
A paraméterek azok az argumentumok, amelyeket a művelet bemenetként kap. A visszatérési típus a művelet műveletének eredményére vonatkozik.
Az osztálydiagram megjelenítheti a műveletek nevét és a műveletek nevét, paramétereiket és visszatérési típusukat. A diagram terhelésének csökkentése érdekében célszerű néhány műveleten csak a műveletek nevét, másokon pedig a teljes aláírást feltüntetni.
Az UML-ben a műveletek a következő jelöléssel rendelkeznek:
Művelet neve (argumentum: argumentum adattípus, argumentum2: argumentum2 adattípus,...): visszatérési típus
Négy különböző típusú műveletet kell figyelembe venni:
Végrehajtási műveletek;
Menedzsment műveletek;
Hozzáférési műveletek;
Segédműveletek.
Megvalósítási műveletek
A végrehajtó műveletek bizonyos üzleti funkciókat valósítanak meg. Ilyen műveleteket interakciós diagramok vizsgálatával találhatunk meg. Az ilyen típusú diagramok az üzleti funkciókra összpontosítanak, és a diagram minden üzenete nagy valószínűséggel egy megvalósítási művelethez társítható.
Minden megvalósítási műveletnek könnyen nyomon követhetőnek kell lennie a megfelelő követelményhez. Ez a szimuláció különböző szakaszaiban érhető el. A művelet az interakciós diagramban szereplő üzenetből származik, az üzenetek az eseményfolyam részletes leírásából származnak, amely a használati eset alapján generálódik, utóbbi pedig a követelmények alapján. Ennek a teljes láncnak a nyomon követése segít abban, hogy minden követelmény megvalósuljon a kódban, és minden kódrészlet végrehajtson valamilyen követelményt.
Menedzsment műveletek
A menedzser műveletek kezelik az objektumok létrehozását és megsemmisítését. Az osztálykonstruktorok és destruktorok ebbe a kategóriába tartoznak.
Hozzáférési műveletek
Az attribútumok általában privátak vagy védettek. Más osztályoknak azonban néha meg kell tekinteniük vagy módosítaniuk kell az értékeket. Ehhez vannak hozzáférési műveletek. Ez a megközelítés lehetővé teszi az attribútumok biztonságos beágyazását egy osztályon belül, megvédve őket más osztályoktól, de lehetővé teszi számukra szabályozott hozzáférés. A Get és Set műveletek létrehozása (érték lekérése és módosítása) egy osztály minden attribútumához szabvány.
Segédműveletek
A segédműveletek (segítő műveletek) egy osztály azon műveletei, amelyek szükségesek a feladatai ellátásához, de amelyekről a többi osztálynak semmit sem szabad tudnia. Ezek privát és védett osztályú műveletek.
A tranzakciók azonosításához tegye a következőket:
1. Tanulmányozási sorrend diagramok és kooperatív diagramok. A diagramokban szereplő üzenetek többsége megvalósítási művelet. A tükröző üzenetek segédműveletek lesznek.
2. Fontolja meg a vezérlési műveleteket. Előfordulhat, hogy konstruktorokat és destruktorokat kell hozzáadnia.
3. Fontolja meg a hozzáférési műveleteket. Minden egyes osztályattribútumhoz, amellyel más osztályoknak dolgozniuk kell, létre kell hoznia a Get és Set műveleteket.
4.4.2.7.Kapcsolatok
A kapcsolat az osztályok közötti szemantikai kapcsolat. Lehetővé teszi egy osztály számára, hogy megismerje egy másik osztály attribútumait, műveleteit és kapcsolatait. Más szóval, ahhoz, hogy az egyik osztály üzenetet küldjön a másiknak egy szekvenciális vagy kooperatív diagramban, kapcsolatnak kell lennie közöttük.
Az osztályok között négyféle kapcsolat létesíthető: asszociációk, függőségek, aggregációk és általánosítások.
Kommunikációs egyesület
Az asszociáció az osztályok közötti szemantikai kapcsolat. Az osztálydiagramon közönséges vonalként vannak felrajzolva.
Rizs. 10. Kommunikációs egyesület
Az asszociációk lehetnek kétirányúak, mint a példában, vagy egyirányúak. Az UML-ben a kétirányú asszociációkat egyszerű vonalként rajzolják meg nyilak nélkül, vagy nyilakkal a vonal mindkét oldalán. Egy egyirányú asszociációnak csak egy nyíla van, amely az irányát mutatja.
Egy asszociáció iránya a szekvenciadiagramok és a kooperatív diagramok vizsgálatával határozható meg. Ha az összes rajtuk lévő üzenetet csak egy osztály küldi, és csak egy másik osztály fogadja, de fordítva nem, akkor ezen osztályok között egyirányú kommunikáció jön létre. Ha legalább egy üzenetet az ellenkező irányba küldenek, a társításnak kétirányúnak kell lennie.
Az asszociációk lehetnek reflexívek. A reflexív asszociáció azt jelenti, hogy egy osztály egy példánya kölcsönhatásba lép ugyanannak az osztálynak a többi példányával.
Kommunikációs függőség
A függőségi kapcsolatok az osztályok közötti kapcsolatot is tükrözik, de mindig egyirányúak, és azt mutatják, hogy az egyik osztály a másikban készített definícióktól függ. Például az A osztály a B osztály metódusait használja. Amikor a B osztály megváltozik, megfelelő változtatásokat kell végrehajtani az A osztályban.
A függőséget két diagramelem közé húzott szaggatott vonal képviseli, és a nyíl végén lehorgonyzott elemről azt mondjuk, hogy függ az adott nyíl elején rögzített elemtől.
Rizs. 11. Kommunikációs függőség
Amikor kódot generál ezekhez az osztályokhoz, nem adnak hozzá új attribútumokat. A kommunikáció támogatásához szükséges nyelvspecifikus operátorok azonban létrejönnek.
Kommunikációs aggregáció
Az aggregáció szorosabb társulási forma. Az aggregáció az egész és része közötti kapcsolat. Például rendelkezhet egy Autó osztályral, valamint motorral, gumiabroncsokkal és más autóalkatrészek osztályaival. Ennek eredményeképpen az Autó osztály objektuma egy Engine osztályú objektumból, négy gumiabroncs objektumból stb. fog állni. Az aggregációk egy rombuszos vonalként jelennek meg egy egész osztályhoz:
Rizs. 11. Kommunikációs aggregáció
Az egyszerű aggregáció mellett az UML bevezeti az összesítés erősebb formáját, az úgynevezett összetételt. A kompozíció szerint egy tárgyrész csak egyetlen egészhez tartozhat, ráadásul a részek életciklusa általában egybeesik az egész ciklusával: élnek és halnak meg vele. Az egész eltávolítása a részeire is kiterjed.
Ezt a lépcsőzetes törlést gyakran az aggregáció definíciójának részének tekintik, de mindig benne van, ha a szereptöbbszörözés 1..1; Például, ha egy Ügyfelet törölni kell, akkor ezt a törlést tovább kell vinni a Megrendelésekre (és viszont a Megbízási sorokra).
Szerintem mindenki hallott gyerekkorában egy ilyen mondást: Hétszer mérje meg egyszer". A programozásban ez ugyanaz. Mindig jobb átgondolni az implementációt, mielőtt időt töltesz a végrehajtásával. Gyakran osztályokat kell létrehoznod a megvalósítás során, ki kell találnod azok interakcióját. És gyakran ennek vizuális megjelenítése segíthet a probléma megoldásában a leghelyesebb módon.Itt segítünk UML.Ha megnézed a képeket kereső motorok, világossá válik, hogy UML- ez valami sémákról, nyilakról és négyzetekről szól. Az a fontos, hogy az UML a következőképpen fordítható: Egységes modellezési nyelv. Az Egységes szó itt fontos. Vagyis képeinket nem csak mi értjük meg, hanem mások is, akik ismerik az UML-t. Kiderült, hogy ez egy olyan nemzetközi nyelv a diagramok rajzolásához.
Ahogy a Wikipédia mondja
Az UML egy grafikus leíró nyelv a fejlesztés alatti objektumok modellezéséhez szoftver, üzleti folyamatok modellezése, rendszertervezés és szervezeti struktúrák megjelenítése.A legérdekesebb dolog, amelyre nem mindenki gondol vagy sejt, az az, hogy az UML-nek vannak specifikációi. Sőt, még UML2 specifikáció is létezik. A specifikációról további információ az Object Management Group honlapján található. Valójában ez a csoport az UML specifikációk fejlesztésével foglalkozik. Az is érdekes, hogy az UML nem korlátozódik az osztályok szerkezetének leírására. Sokféle UML diagram létezik. Az UML diagramok típusainak rövid leírása megtekinthető ugyanabban a Wikipédiában: UML diagramok vagy Timur Batyrshinov videójában Az UML diagramok áttekintése. Az UML-t széles körben használják különféle folyamatok leírására is, például itt: Egyszeri bejelentkezés JWT használatával. Visszatérve az UML osztálydiagramok használatára, érdemes megjegyezni a Head First: Design Patterns című könyvet, amelyben a mintákat ugyanazok az UML diagramok illusztrálják. Kiderült, hogy az UML-t valóban használják. És kiderül, hogy alkalmazásának ismerete és megértése igen hasznos készség.
De mi van akkor, ha magad akarod lerajzolni, és még az Idea Ultimate verziója sincs? Ha IntelliJ Idea Community Edition-t használunk, akkor nincs más választásunk. Ehhez meg kell értenie egy ilyen UML-séma működését. Először telepítenünk kell a Graphviz-t. Ez egy gráfvizualizációs segédprogram készlete. Az általunk használni kívánt plugin használja. A telepítés után hozzá kell adni egy könyvtárat kuka a telepített könyvtárból graphviz egy környezeti változóhoz PÁLYA. Ezután az IntelliJ Idea programban válassza a Fájl -> Beállítások menüpontot. A "Beállítások" ablakban válassza ki a "Plugins" kategóriát, kattintson a "Lerakatok tallózása" gombra, és telepítse a PlantUML integrációs bővítményt. Miért olyan jó ez PlantUML? Arra használja UML leírások egy gráfleíró nyelvet " pont" és ez lehetővé teszi, hogy univerzálisabb legyen, mert ezt a nyelvet nem csak a PlantUML használja. Sőt, mindaz, amit alább meg fogunk tenni, nem csak az IDE-ben, hanem a planttext.com online szolgáltatásban is elvégezhető. A telepítés után a PlantUML bővítmény, a „Fájl" -> „Új" menüponton keresztül tudunk majd UML diagramokat készíteni. Készítsünk „UML osztály" típusú diagramot. Ezalatt automatikusan létrejön egy sablon egy példával. Töröljük a tartalmát, ill. hozzuk létre a sajátunkat, felvértezve egy cikkel a Habr: Class Relations - UML-től a kódig... És hogy megértsük, hogyan ábrázoljuk ezt a szövegben, vegyük a PlantUML kézikönyvet: plantuml osztálydiagram... Ebben, a a kezdetektől fogva van egy jel a kapcsolatok leírására:
Magukról a kapcsolatokról még itt olvashatunk: "Osztályok közötti kapcsolatok UML-ben. Példák". Ezen anyagok alapján kezdjük el elkészíteni az UML diagramunkat. Adja hozzá a következő, a két osztályt leíró tartalmat: @startuml osztály ArrayList ( ) osztály LinkedList ( ) @enduml Az eredmény megtekintéséhez az Idea programban válassza a "Nézet" -> "Eszközablakok" -> "PlantUML" lehetőséget. Csak két osztályt jelölő négyzetet kapunk. Mint tudjuk, mindkét osztály megvalósítja a Lista felületet. Az osztályok ezt a relációját - megvalósításnak (realizációnak) nevezik. Az ilyen kapcsolat ábrázolására egy pontozott vonallal ellátott nyíl szolgál. Rajzoljuk meg: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о csomag privát elem tömb: ~ Object elementData Most szeretnénk megmutatni, hogy az ArrayList tartalmaz néhány objektumot. BAN BEN ez az eset lesz egy kapcsolattípus - összesítését(összevonás). Az aggregátum ebben az esetben az ArrayList , mert más tárgyakat tartalmaz. Az aggregációt azért választjuk, mert a listában szereplő objektumok a lista nélkül is élhetnek: nem szerves részei annak. Élettartamuk nincs a lista élettartamához kötve. A latin nyelvű egységet "összegyűjtöttnek" fordítják, azaz valamiből áll. Például az életben van egy szivattyúegység, amely egy szivattyúból és egy motorból áll. Maga az egység szétszedhető, néhány alkatrésze megmarad. Például eladni vagy behelyezni egy másik egységet. Tehát szerepel a listán. És ez az egységnél üres rombusz és folyamatos vonal formájában fejeződik ki. Fogalmazzunk így: osztály Object ( ) ArrayList o- Object Most azt akarjuk megmutatni, hogy az ArrayList-től eltérően a LinkedList osztály Node - konténereket tartalmaz, amelyek tárolt adatokra hivatkoznak. Ebben az esetben a csomópontok magának a LinkedList-nek a részét képezik, és nem élhetnek külön. A csomópont nem közvetlenül tárolt tartalom, csak hivatkozást tartalmaz rá. Például amikor hozzáadunk egy sort a LinkedList listához, akkor hozzáadunk egy új csomópontot, amely egy hivatkozást tartalmaz az adott sorra, valamint egy hivatkozást az előző és a következő csomópontra. Ezt a kapcsolattípust ún fogalmazás(fogalmazás). Egy kompozit (olyan, amely részekből áll) megjelenítéséhez egy kitöltött robikot rajzolunk, amelyhez egy folyamatos vonal vezet. Most írjuk ezt a hivatkozás szöveges megjelenítéseként: class Node ( ) LinkedList * -- Node És most meg kell tanulnunk, hogyan jelenítsünk meg egy másik fontos hivatkozástípust - függőség(függőségi kapcsolat). Akkor használatos, ha az egyik osztály egy másikat használ, míg az osztály nem tartalmazza a használt osztályt, és nem az utódja. Például a LinkedList és az ArrayList létrehozhat egy ListIteratort. Jelenítsük meg ezt pontozott nyilakként: Class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Annyit részletezhet, amennyire szüksége van. Az összes megnevezés itt található: "PlantUML - Osztálydiagram". Ezenkívül nincs semmi természetfeletti egy ilyen sémában, és amikor a feladatain dolgozik, gyorsan megrajzolhatja kézzel. Ez fejleszti az alkalmazásarchitektúra átgondolásának készségeit, és segít az osztályszerkezeti hibák korai felismerésében, nem pedig azután, hogy már egy napot töltött a rossz modell megvalósításával. Szerintem ez jó ok arra, hogy kipróbáljam?)
Mivel ennek a cikknek a középpontjában nem a Maven áll, a Mavennel kapcsolatos kérdéseire a Maven Users Centerben találhat választ. A generált projektben nyissa meg a projektleíró fájlt szerkesztésre, pom.xml. Belemásoljuk az uml-java-docklet telepítés leírásának tartalmát. A leírásban használt műtárgy nem található a Maven Central adattárában. De nekem ezzel működött: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Vagyis abban a leírásban csak ki kell cserélni csoportazonosító Val vel " info.leadinglight" tovább " com.chfourie"és tedd be a verziót" 1.0.0 Ezt követően a fájlt tartalmazó könyvtárban tudjuk végrehajtani pom.xml ezek a parancsok: mvn clean install és mvn javadoc:javadoc . Most, ha megnyitjuk a generált dokumentációt (explorer target\site\apidocs\index.html), UML diagramokat fogunk látni. Egyébként itt már helyesen megjelenik a megvalósítás)
Minden UML diagram feltételesen két csoportra osztható, amelyek közül az első az általános diagramok. Az általános diagramok gyakorlatilag függetlenek a modellezés tárgyától, és bármilyen szoftverprojektben felhasználhatók, tekintet nélkül a tárgykörre, döntési területre stb.
Használati diagram(használati eset diagram) a rendszer funkcionális céljának legáltalánosabb ábrázolása.
A használati diagram a fő modellezési kérdésre kíván választ adni: mit csinál a rendszer a külvilágban?
A használati diagramban kétféle fő entitást használunk: 1. használati esetet és 2. szereplőt, amelyek között a következő főbb típusú kapcsolatok jönnek létre:
A használati diagramon, mint bármely máson, lehetnek megjegyzések 7 . Ezenkívül erősen ajánlott ezt megtenni a diagramok olvashatóságának javítása érdekében.
A használati diagramban használt jelölés főbb elemeit az alábbiakban mutatjuk be. Részletes leírást a 2.2.
osztálydiagram(osztálydiagram) a rendszer szerkezetének leírásának fő módja.
Ez nem meglepő, mivel az UML elsősorban egy objektum-orientált nyelv, és az osztályok a fő (ha nem az egyetlen) építőelemek.
Az osztálydiagramon az entitások egy fő típusát használjuk: az 1-es osztályokat (beleértve az osztályok számos speciális esetét: interfészek, primitív típusok, asszociációs osztályok és sok más), amelyek között a következő fő típusú kapcsolatok jönnek létre:
Az osztálydiagramban használt jelölés néhány eleme az alábbiakban látható. Részletes leírás a 3. fejezetben található.
automata diagram(állapotgép diagram) az egyik módja annak, hogy az állapotok explicit allokációján és az állapotok közötti átmenetek leírásán alapuló viselkedést részletesen leírjuk az UML-ben.
Lényegében az automata diagramok, ahogy a neve is sugallja, egy állapotátmeneti gráf (lásd a 4. fejezetet), amely számos további részlettel és részlettel van feltöltve.
Az automata diagramban az entitások egy fő típusát használjuk - állapotok 1 , és egy típusú kapcsolatokat - átmeneteket 2 , de mindkettőre nagyon sok változatot, speciális esetet és további megnevezéseket határoznak meg. Nincs értelme mindet felsorolni egy bevezető áttekintésben.
Az automata diagramok összes változatának részletes leírását a 4.2 fejezet tartalmazza, a következő ábra pedig csak az automata diagramon használt jelölés fő elemeit mutatja.
tevékenység diagram(tevékenységdiagram) - a viselkedés leírásának módja a vezérlési és adatfolyamok jelzése alapján.
A tevékenységdiagram egy másik módja a viselkedés leírásának, amely vizuálisan hasonlít egy jó öreg folyamatábrára. Azonban a modernizált, az objektum-orientált megközelítéssel összhangban lévő jelölésnek, és ami a legfontosabb, az új szemantikai komponensnek (a Petri-hálók szabad értelmezése) köszönhetően az UML tevékenységdiagram hatékony eszköz a rendszer viselkedésének leírására.
A tevékenységdiagramban az entitások egy fő típusát használjuk - az 1. műveletet és a kapcsolatok egy típusát - az átmeneteket 2 (vezérlés és adatátvitel). Használnak olyan konstrukciókat is, mint az elágazások, egyesülések, kapcsolatok, elágazások 3 , amelyek hasonlóak az entitásokhoz, de valójában nem azok, hanem grafikusan ábrázolják a sokhelyes kapcsolatok néhány speciális esetét. A tevékenységdiagram-elemek szemantikáját részletesen a 4. fejezet tárgyalja. Az alábbiakban bemutatjuk a tevékenységdiagramban használt jelölés főbb elemeit.
szekvencia diagram(szekvencia diagram) a rendszer viselkedésének leírása a továbbított üzenetek sorrendjének jelzése alapján.
Valójában a szekvenciadiagram a rendszer egy adott munkamenete protokolljának rekordja (vagy egy ilyen protokoll töredéke). Az objektum-orientált programozásban futás közben a leglényegesebb az üzenetek átadása az együttműködő objektumok között. Ezen a diagramon az üzenetek küldésének sorrendje látható, innen a név.
A szekvenciadiagramban az entitások egy fő típusát használjuk – az egymással kölcsönhatásban lévő osztályozók 1 példányait (főleg osztályok, komponensek és szereplők), és egyfajta kapcsolat - kapcsolatok 2 , amelyeken keresztül üzenetek cserélődnek 3 . Az üzenetek küldésének többféle módja van, amelyek grafikus jelölésben a relációnak megfelelő nyíl formájában különböznek egymástól.
A szekvenciadiagram fontos szempontja az idő múlásának explicit megjelenítése. Más típusú diagramoktól eltérően, kivéve talán a szinkrondiagramokat, a szekvenciadiagramban nem csak az elemek közötti grafikus kapcsolatok megléte számít, hanem az elemek relatív helyzete is a diagramon. Ugyanis azt tekintik, hogy van egy (láthatatlan) időtengely, amely alapértelmezés szerint fentről lefelé irányul, és a későbbiekben elküldött üzenetet lerajzolják.
Az időtengely vízszintesen irányítható, ebben az esetben az időt balról jobbra áramlásnak tekintjük.
A következő ábra a szekvenciadiagramban használt jelölés fő elemeit mutatja be. Maguk az interakciós objektumok megjelölésére a szabványos jelölést használják - egy téglalapot egy osztályozó példány nevével. A belőle kijövő szaggatott vonalat életvonalnak (életvonalnak) 4 nevezzük. Ez nem egy kapcsolat megjelölése a modellben, hanem egy grafikus kommentár, amelynek célja, hogy a diagram olvasóját a helyes irányba terelje. Az életvonalra ráhelyezett keskeny csíkok formájú figurák szintén nem szimulált entitások képei. Ez egy grafikus megjegyzés, amely megmutatja, hogy egy objektum mennyi ideig birtokol egy végrehajtási eseményt 5 vagy más szóval egy objektum aktiválását. Az összetett interakciós lépések (kombinált fragmentum) 6 lehetővé teszik, hogy a szekvenciadiagram tükrözze az interakciós protokoll algoritmikus vonatkozásait. A szekvenciadiagramok jelölésével kapcsolatos további részletekért lásd a 4. fejezetet.
Kommunikációs diagram(kommunikációs diagram) - a viselkedés leírásának módja, szemantikailag egyenértékű a szekvencia diagrammal.
Valójában ez ugyanaz a leírása az osztályozók kölcsönhatásban lévő példányainak üzenetváltási szekvenciájának, csak más grafikus eszközökkel kifejezve. Ezenkívül a legtöbb eszköz képes automatikusan átalakítani a szekvenciadiagramokat kommunikációs diagramokká és fordítva.
Így a kommunikációs diagramban, valamint a szekvenciadiagramban az entitások egyik fő típusát használjuk - az egymásra hatást gyakorló osztályozók példányait 1 és a kapcsolatok egy típusát - a kapcsolatokat 2 . Itt azonban nem az időn van a hangsúly, hanem a konkrét esetek közötti kapcsolatok szerkezetén.
Az ábra a kommunikációs diagramban használt jelölés főbb elemeit mutatja. Maguk az interakciós objektumok megjelölésére a szabványos jelölést használják - egy téglalapot egy osztályozó példány nevével. Az elemek egymás közötti helyzete az együttműködési diagramon nem számít, csak a kapcsolatok (leggyakrabban az asszociációk esetei) a fontosak, amelyek mentén az üzenetek továbbításra kerülnek 3 . Az üzenetek sorrendjének időbeni megjelenítéséhez hierarchikus decimális számozást használnak.
Alkatrész diagram(komponens diagram) - a szimulált rendszert alkotó (logikai vagy fizikai) modulok közötti kapcsolatot mutatja.
A komponens diagramon szereplő entitások fő típusa maguk a komponensek 1, valamint az interfészek 2 , amelyeken keresztül a komponensek közötti kapcsolat látható. A következő összefüggések érvényesek a komponens diagramban:
Az ábra a komponensdiagramban használt jelölés főbb elemeit mutatja. Részletes leírás a 3. fejezetben található.
Elhelyezési diagram(telepítési diagram), a rendszerelemek összetételének és kapcsolatainak megjelenítésével együtt megmutatja, hogyan helyezkednek el fizikailag a számítási erőforrásokon a végrehajtás során.
Így az elhelyezési diagramban a komponens diagrammal összehasonlítva kétféle entitás kerül hozzáadásra: az 1. műtermék, amely a 2. komponens és a 3. csomópont megvalósítása (lehet a csomópont típusát leíró osztályozó vagy egy adott példány), valamint egy asszociációs kapcsolat a 4 csomópontok között, ami azt jelzi, hogy a csomópontok fizikailag össze vannak kapcsolva futási időben.
Az ábra az elhelyezési diagramban használt jelölés főbb elemeit mutatja. Annak bizonyítására, hogy egy entitás egy másik része, vagy egy „telepítési” függőségi viszonyt 5 használunk, vagy az egyik entitás alakját egy másik entitás alakjában 6 helyezzük el. A diagram részletes leírása a 3. fejezetben található.
Az UML diagram egy speciális grafikus leíró nyelv, amelyet különféle szoftverek fejlesztése során történő objektummodellezésre terveztek. Ez a nyelv széles profillal rendelkezik, és egy nyílt szabvány, amely különféle grafikus jelöléseket használ a rendszer absztrakt modelljének létrehozásához. Az UML-t azért hozták létre, hogy lehetővé tegye mindenféle szoftverrendszer meghatározását, megjelenítését, dokumentálását és tervezését. Érdemes megjegyezni, hogy maga az UML diagram nem programozási nyelv, de lehetőséget ad arra, hogy külön kódot generáljunk az alapján.
Az UML használata nem ér véget mindenféle szoftver modellezésével. Ezenkívül ezt a nyelvet ma aktívan használják különféle üzleti folyamatok modellezésére, rendszertervezés végrehajtására, valamint a szervezeti struktúrák megjelenítésére.
Az UML segítségével a szoftverfejlesztők teljes egyetértést tudnak biztosítani a grafikus szimbólumok bemutatni általános fogalmak, mint például: komponens, általánosítás, osztály, viselkedés és aggregáció. Ezzel az építészetre és a tervezésre való nagyobb fokú koncentráció érhető el.
Azt is érdemes megjegyezni, hogy többféle ilyen diagram létezik.
Az UML osztálydiagram egy statikus szerkezeti diagram, amelyet a rendszer szerkezetének leírására terveztek, valamint bemutatják az attribútumokat, metódusokat és több különböző osztály közötti függőséget.
Érdemes megjegyezni azt a tényt, hogy az ilyen diagramok felépítésével kapcsolatban több szempont létezik, attól függően, hogy hogyan fogják őket használni:
Az UML komponens diagramja egy teljesen statikus szerkezeti diagram. Célja egy bizonyos particionálás bemutatása szoftver rendszer különböző szerkezeti elemekbe, valamint a köztük lévő kapcsolatokba. Az UML komponens diagram mint olyan mindenféle modellt, könyvtárat, fájlt, csomagot, futtatható fájlokés még sok más elem.
Az UML kompozit/kompozit szerkezeti diagram egyben statikus szerkezeti diagram is, de az osztályok belső szerkezetének bemutatására szolgál. Ha lehetséges, ez a diagram bemutatja az osztály belső szerkezetében lévő elemek kölcsönhatását is.
Ezek egyik alfaja az UML kollaborációs diagram, amely a különböző osztályok szerepeinek és interakcióinak bemutatására szolgál egy együttműködés keretein belül. Nagyon hasznosak, ha tervezési mintákat kell modelleznie.
Érdemes megjegyezni, hogy az UML osztálydiagramok és az összetett szerkezeti diagramok egyszerre használhatók.
Ez a diagram a futó csomópontok, valamint a rajtuk telepített összes műtermék modellezésére szolgál. Az UML 2-ben a melléktermékeket különféle csomópontokon telepítik, míg az első verzióban csak összetevőket telepítettek. Így az UML telepítési diagramot elsősorban a második verzióhoz használják.
Megnyilvánulási függőség jön létre egy műtermék és az általa megvalósított komponens között.
Ez a nézet lehetővé teszi a teljes vagy részleges kép megtekintését. létrehozott rendszert egy bizonyos időpontban. Teljesen megjeleníti egy adott rendszer osztályainak összes példányát, jelezve paramétereik aktuális értékeit, valamint a köztük lévő kapcsolatokat.
Ez a diagram strukturális jellegű, és fő tartalma mindenféle csomag, valamint a köztük lévő kapcsolatok. Ebben az esetben nincs szigorú elválasztás több szerkezeti diagram között, aminek következtében használatukat legtöbbször kizárólag kényelmi szempontok miatt használjuk, szemantikai jelentést nem hordoznak. Érdemes megjegyezni, hogy a különböző elemek más UML-diagramokat is szolgáltathatnak (például maguk a csomagok és csomagdiagramok).
Használatuk annak érdekében történik, hogy biztosítsák több elem csoportokba szervezését egy bizonyos attribútum szerint, a szerkezet egyszerűsítése, valamint a rendszer modelljével való munka megszervezése érdekében.
Az UML tevékenységdiagram egy adott tevékenység több részre bontását jeleníti meg. Ebben az esetben a "tevékenység" fogalma egy bizonyos végrehajtható viselkedés specifikációját jelenti, párhuzamos, valamint különböző alárendelt elemek összehangolt szekvenciális végrehajtása - egymásba ágyazott típusú tevékenységek és különféle műveletek, amelyeket egyesítenek a egy bizonyos csomópont kimenetei egy másik bemenetére.
Az UML tevékenységi diagramot gyakran használják különféle üzleti folyamatok, párhuzamos és szekvenciális számítások modellezésére. Többek között mindenféle technológiai eljárást modelleznek.
Ezt a nézetet némileg másképp hívják UML állapotdiagramnak. Van egy bemutatott állapotgépe egyszerű és összetett állapotokkal, valamint átmenetekkel.
A véges állapotú gép különböző állapotok sorozatának specifikációja, amelyen egy bizonyos objektum áthalad, vagy egy interakció az életében bekövetkezett egyes eseményekre, valamint az objektum ilyen eseményekre adott válasza. Az UML állapotdiagram által használt állapotgéphez van rendelve szülő elemés példányai viselkedésének meghatározására szolgál.
Az úgynevezett sárkánydiagramok az ilyen diagramok analógjaként használhatók.
Az UML használati eset diagramja megjeleníti a szereplők között előforduló összes kapcsolatot, valamint a különböző használati eseteket. Fő feladata, hogy olyan teljes értékű eszközt biztosítson, amellyel a megrendelő, a végfelhasználó vagy valamelyik fejlesztő közösen megbeszélheti egy adott rendszer viselkedését, funkcionalitását.
Ha UML használati eset diagramot használnak egy rendszermodellezési folyamatban, akkor az elemző a következőket fogja tenni:
Ha az UML-ben használati diagramot dolgoznak ki, akkor az eljárás szöveges leírással kezdődik, amelyet az ügyféllel való munka során kapunk. Ugyanakkor érdemes megjegyezni, hogy a használati esetmodell összeállítása során a különböző nem funkcionális követelmények teljesen kimaradnak, és ezekről már külön dokumentum készül.
A kommunikációs diagram az UML szekvenciadiagramhoz hasonlóan tranzitív, azaz kifejezi az interakciót, de egyben demonstrálja is. különböző utak, és ha szükséges, a szükséges pontossággal konvertálhatja egyiket a másikba.
A kommunikációs diagram tükrözi a kompozit szerkezet különböző elemei között fellépő interakciókat, valamint az együttműködés szerepeit. Legfőbb különbsége a sorrenddiagramtól, hogy egyértelműen jelzi több elem kapcsolatát, és az időt nem használják külön dimenzióként.
Ezt a típust egy teljesen szabad formátum különbözteti meg, ahol több objektum és kapcsolat elrendezése ugyanúgy történik, mint az objektumdiagramban. Ha szükség van az üzenetek sorrendjének fenntartására ebben a szabad formátumban, akkor azok időrendi sorrendben vannak számozva. Ennek a diagramnak az olvasása a kezdeti 1.0 üzenettel kezdődik, majd az üzenetek egyik objektumról a másikra való továbbításának irányában folytatódik.
Az ilyen diagramok többnyire pontosan ugyanazt az információt mutatják, amit a szekvenciadiagram szolgáltat nekünk, de mivel más módon mutatja be az információkat, az egyik diagramban bizonyos dolgok sokkal könnyebben meghatározhatók, mint a másikban. Azt is érdemes megjegyezni, hogy a kommunikációs diagram világosabban megmutatja, hogy az egyes elemek mely elemekkel lépnek kölcsönhatásba, míg a szekvenciadiagram egyértelműen azt mutatja meg, hogy milyen sorrendben valósulnak meg az interakciók.
Az UML szekvenciadiagram több objektum közötti interakciókat mutatja, amelyek az előfordulásuk időpontja szerint vannak rendezve. Egy ilyen diagram több objektum közötti időrendi interakciót mutat be. Különösen megjeleníti az interakcióban részt vevő összes objektumot, valamint az általuk váltott üzenetek teljes sorozatát.
A fő elemek ebben az esetben a különböző objektumok megjelölései, valamint függőleges vonalak, amely az idő múlását és a téglalapok, amelyek egy adott objektum tevékenységét vagy valamely funkció általi végrehajtását ábrázolják.
Az ilyen típusú diagramok lehetővé teszik több objektum közötti interakciók megjelenítését, elvonatkoztatva az üzenetfordítási sorrendtől. Az ilyen típusú diagramok kompakt formában megjelenítik egy bizonyos objektum összes továbbított és fogadott üzenetét, valamint ezen üzenetek formátumát.
Mivel a szekvenciadiagramok és a kommunikációs diagramok egyszerűen ugyanazon eljárások különböző nézetei, a Rational Rose lehetőséget biztosít kommunikációs szekvenciadiagram létrehozására egy szekvenciadiagramból vagy fordítva, és teljesen automatikusan szinkronizálja azokat.
Ezek UML-diagramok, amelyek a tevékenységdiagramok egy típusához tartoznak, és mind sorozatelemeket, mind vezérlőfolyam-konstrukciókat tartalmaznak.
Érdemes megjegyezni azt a tényt, hogy adott formátum Együttműködési és Sorozatdiagramot egyesíti, amelyek lehetőséget adnak arra, hogy a kialakítandó rendszer több objektuma közötti interakciót különböző nézőpontokból megvizsgáljuk.
Képviseli Alternatív lehetőség szekvencia diagram, amely explicit módon mutatja be az életvonal állapotváltozását egy bizonyos időskálán. Nagyon hasznos lehet különféle valós idejű alkalmazásokban.
Érdemes megjegyezni néhány előnyt, amelyek megkülönböztetik az UML használati diagramot és másokat:
Annak ellenére, hogy az UML diagramok felépítésének számos előnye van, gyakran kritizálják őket a következő hiányosságok miatt:
Így ennek a nyelvnek a használata nem minden helyzetben releváns.
