Szimulációs diagramok. UML: az elmélettől a gyakorlatig

Az UML az grafikus nyelváltalános célú modellező eszköz a fejlesztés során keletkezett összes műtárgy specifikálásához, megjelenítéséhez, tervezéséhez és dokumentálásához szoftverrendszerek.

Sok jó könyv van, ami részletesen leírja az UML-t (néha még nagyon részletesen is), szeretném egy helyre összegyűjteni az alapfogalmakat a diagramokról, entitásokról és a köztük lévő kapcsolatokról a gyors felidézéshez, valami csalólaphoz hasonló.

A jegyzet könyvekből származó anyagokat használ: Ivanov D. Yu., Novikov F. A. Egységes UML modellezési nyelvÉs Leonenkov. UML oktatóanyag.

Kezdjük a szerkesztővel. Linux alatt kipróbáltam különböző UML szerkesztőket, leginkább az UMLet tetszett, bár Java-ban van írva, nagyon gyorsan mozog és a legtöbb entitás üres is benne van. Van még ArgoUML, egy többplatformos UML-szerkesztő, szintén Java nyelven íródott, funkcionálisan gazdag, de jobban lassul.

-nél megálltam UMLet, telepítse alá Arch LinuxÉs ubuntu:

# Arch Linux yaourt -S umlet alatt # Ubuntu alatt sudo apt-get install umlet

Az UML-ben minden entitás a következő típusokra bontható:

• szerkezeti;
• viselkedési;
• csoportosítás;
• annotációs;

Az UML négy fő kapcsolattípust használ:

Függőség- azt jelzi, hogy a független entitás megváltoztatása valamilyen módon érinti a függő entitást. Grafikusan a függőségi kapcsolatot szaggatott vonalként ábrázoljuk, a függő entitásról a független entitásra mutató nyíllal.

Egyesület- akkor kerül sor, ha az egyik entitás közvetlenül kapcsolódik egy másikhoz (vagy másokhoz - az asszociáció nem csak bináris lehet). Grafikusan az asszociációt egy folytonos vonalként ábrázolják, a kapcsolódó entitásokat összekapcsoló különféle kiegészítésekkel.

Általánosítás egy kapcsolat két entitás között, amelyek közül az egyik a másik sajátos (specializált) esete. Grafikusan az általánosítás egy vonalként van ábrázolva, amelynek végén egy kitöltetlen háromszög nyíl van, amely a konkréttól (alosztálytól) az általános felé (szuperosztály) irányul.

Megvalósítások- az implementációs reláció azt jelzi, hogy az egyik entitás egy másik megvalósítása. Grafikusan az implementációt szaggatott vonalként ábrázoljuk, a végén egy kitöltetlen háromszög nyíllal, amely a végrehajtó entitástól a megvalósított felé irányul.

BAN BEN UML 2 meghatározott 13 diagramtípusok. Szabvány szerint minden diagramnak egy téglalappal (jobb alsó sarok ferde) kerettel kell lennie a bal oldalon. felső sarok, amely megadja a diagram azonosítóját (címkéjét) és címét.

Diagramok a rendszer felépítésének ábrázolására:

• Alkatrész diagram (alkatrész diagram, címke összetevő);
• Beépítési diagram (telepítési diagram, címke bevetése);
• Osztálydiagram (osztálydiagram, címke osztály);
• Objektumdiagram (objektumdiagram, címke tárgy);
• Belső szerkezeti diagram (összetett szerkezeti diagram, címke osztály);

A rendszer viselkedését ábrázoló diagramok:

• Szinkronizálási diagram (kölcsönhatás diagram, címke időzítés);
• Tevékenységi diagram (tevékenységdiagram, címke tevékenység);
• szekvencia diagram (szekvencia diagram, címke SD);
• Kommunikációs diagram (kommunikációs diagram, címke comm);
• Automata diagram (állapotgép diagram, címke állapotgép);
• Interakció áttekintése diagram, címke kölcsönhatás);

A diagramok kiemelkednek:

• Használati eset diagram (használati eset diagram, használati eset címke);
• Csomag diagram (csomag diagram, címke csomag);

Használati diagram

Használati diagram(használati eset diagram) a rendszer funkcionális céljának legáltalánosabb ábrázolása.

Ha egy használati eset diagramot egy rendszer modelljének tekintünk, akkor azt egy fekete doboz modellhez társíthatjuk. Minden használati eset meghatároz egy műveletsort, amelyet a tervezett rendszernek végre kell hajtania, amikor interakcióba lép a megfelelő szereplővel.

A használati diagram kétféle alapvető entitást használ: használati eseteket és szereplőket, amelyek között a következő alapvető kapcsolatok jönnek létre.

asszociációs kapcsolat- Ez a kapcsolat határozza meg, hogy egy szereplő milyen konkrét szerepet játszik, amikor egy használati esettel érintkezik. Az asszociációs kapcsolatot a szereplő és a használati eset közötti folyamatos vonal jelzi. Ez a sor tartalmazhat további egyezmények, mint például a név és a többszörösség.

Kiterjesztési kapcsolat- Meghatározza az egyszeri használatú eset példányainak kapcsolatát egy általánosabb használati esettel, amelynek tulajdonságait a példányok kombinálásának módja alapján határozzák meg. Így ha van kiterjesztési kapcsolat az A használati esettől a B használati esetig, akkor ez azt jelenti, hogy a B használati eset egy példányának tulajdonságai kiegészíthetők az A kiterjesztett használati eset tulajdonságainak megléte miatt.

A használati esetek közötti kiterjesztési kapcsolatot egy szaggatott vonal jelzi egy nyíllal (függőségi kapcsolat esete), amely elfelé mutat attól a használati esettől, amely az eredeti használati eset kiterjesztése.

Általánosítási reláció azt a tényt jelzi, hogy bizonyos A használati eset általánosítható B használati esetre. Ebben az esetben az A használati eset a B használati eset specializációja lesz. Ebben az esetben B-t A ősének vagy szülőjének nevezzük, és Az A a B használati eset V felhasználásának leszármazottja.

Grafikusan ezt a kapcsolatot egy folytonos vonal ábrázolja egy nyitott háromszög nyíllal, amely a szülő használati esetre mutat.

A használati esetek közötti általánosító kapcsolat akkor használatos, ha meg kell jegyezni, hogy a gyermek használati esetek a szülő használati esetek összes tulajdonságával és viselkedésével rendelkeznek.

Befogadási reláció két használati eset között azt jelzi, hogy az egyik használati esethez meghatározott viselkedés komponensként szerepel egy másik használati eset viselkedési sorozatában.

Az A használati esettől a B használati esetig terjedő befogadási kapcsolat azt jelzi, hogy az A használati eset minden egyes példánya tartalmazza a B használati esethez meghatározott funkcionális tulajdonságokat.

Grafikusan ezt a kapcsolatot egy szaggatott vonal ábrázolja egy nyíllal (függőségi kapcsolatváltozat), amely az alaphasználati esettől a benne foglalt használati eset felé mutat.

osztálydiagram

osztálydiagram(osztálydiagram) - a rendszer statikus szerkezetének leírásának fő módja.

Az osztálydiagram az entitások egy fő típusát használja: osztályokat (beleértve az osztályok számos speciális esetét: interfészek, primitív típusok, asszociációs osztályok stb.), amelyek között a következő főbb típusú kapcsolatok jönnek létre: függőségek, asszociációk, általánosítások, implementációk.

Függőségi kapcsolatáltalában valamilyen szemantikai kapcsolatot jelez két modellelem vagy ilyen elemek két halmaza között, amely nem asszociáció, általánosítás vagy megvalósítási kapcsolat. A függőségi kapcsolatot olyan helyzetben használjuk, amikor az egyik modellelem változása egy másik függő modellelem megváltoztatását teheti szükségessé.

A függőségi kapcsolatot grafikusan egy szaggatott vonal ábrázolja a megfelelő elemek között, az egyik végén nyíllal, ahol a nyíl a függőség kliensosztályától a független vagy forrásosztály felé mutat.

A nyíl felett különleges lehet kulcsszavakat(sztereotípiák):

• "access" - a forrásosztály nyilvános attribútumai és műveletei elérhetőségének jelzésére szolgál az ügyfélosztályok számára;
• "bind" - a kliens osztály használhat valamilyen sablont a későbbi paraméterezéséhez;
• "derive" - ​​az ügyfélosztály attribútumai kiszámíthatók a forrásosztály attribútumaiból;
• "import" - a forrásosztály nyilvános attribútumai és műveletei a kliens osztály részévé válnak, mintha közvetlenül benne lettek volna deklarálva;
• "finomítás" - azt jelzi, hogy a kliens osztály a forrásosztály finomításaként szolgál történelmi okokból, amikor további információ a projekt során.

asszociációs kapcsolat az osztályok közötti valamilyen kapcsolat jelenlétének felel meg. Ezt a kapcsolatot egy folytonos vonal jelzi további speciális szimbólumokkal, amelyek egy adott asszociáció egyedi tulajdonságait jellemzik. Kiegészítőként speciális karakterek az egyesület neve, valamint az egyesület szereposztályainak neve és sokasága használható. Az egyesület neve a megnevezésének választható eleme.

Aggregációs reláció több osztály között fordul elő, ha az egyik osztály olyan entitás, amely komponensként más entitásokat is tartalmaz. A "rész-egész" típusú rendszerkapcsolatok ábrázolására szolgál.

Összetételi viszony az aggregációs reláció speciális esete. Ez a kapcsolat a rész-egész kapcsolat egy olyan speciális formáját kívánja kiemelni, amelyben az alkotó részek bizonyos értelemben az egészen belül vannak. A köztük lévő kapcsolat sajátossága abban rejlik, hogy a részek nem tudnak az egésztől elszigetelten hatni, azaz az egész megsemmisülésével annak minden alkotó része is megsemmisül.

Általánosítási reláció egy általánosabb elem (szülő vagy ős) és egy konkrétabb ill speciális elem(gyermek vagy leszármazott). Osztálydiagramra alkalmazva ez a kapcsolat az osztályok hierarchikus szerkezetét, valamint tulajdonságaik és viselkedésük öröklését írja le. Ez azt feltételezi, hogy a leszármazott osztály rendelkezik az ősosztály összes tulajdonságával és viselkedésével, és megvannak a saját tulajdonságai és viselkedése is, amelyek nincsenek jelen az ősosztályban.

automata diagram

automata diagram(állapotgép diagram) ill állapotdiagram Az UML 1-ben (állapotdiagram diagram) az egyik módja a viselkedés részletes leírásának UML-ben. Lényegében az automata diagramok, ahogy a neve is sugallja, állapotok és átmenetek grafikonjai. állapotgép tele van sok további részlettel és részlettel.

Az állapotdiagram csak egy osztály állapotának megváltoztatásának folyamatát írja le, vagy inkább egy bizonyos osztály egy példányának állapotát, vagyis modellezi egy adott objektum állapotában bekövetkező összes lehetséges változást. Ebben az esetben egy tárgy állapotváltozását okozhatják más tárgyakból vagy kívülről érkező külső hatások. Az állapotdiagramokat az objektum ilyen külső hatásokra adott reakciójának leírására használják.

Az automata diagramban egy fő entitástípust használnak - állapotokat, és egyfajta kapcsolatokat - átmeneteket, de mindkettőnél számos változat, speciális eset és további megnevezés létezik. Az automata a szimulált rendszer dinamikus aspektusait irányított gráf formájában ábrázolja, melynek csúcsai állapotoknak, az ívek pedig átmeneteknek felelnek meg.

Kezdeti állapot képviseli különleges eset sz hazai fellépés(pszeudoállapotok). Az objektum alapértelmezés szerint ebben az állapotban van a kezdeti időpontban. Arra szolgál, hogy az állapotdiagramon jelezze azt a grafikus területet, ahonnan az állapotváltozás folyamata elkezdődik.

Döntő (döntő) az állapot egy olyan állapot speciális esete, amely szintén nem tartalmaz belső cselekvéseket (pszeudoállapotokat). Az objektum alapértelmezés szerint ebben az állapotban lesz az automata befejezése után a befejezési időpontban.

tevékenység diagram

Egy tervezés alatt álló vagy elemzett rendszer viselkedésének modellezésekor nemcsak állapotváltozási folyamatának bemutatása válik szükségessé, hanem a rendszer által végrehajtott műveletek algoritmikus és logikai megvalósításának jellemzőinek részletezése is.

tevékenység diagram(tevékenységdiagram) egy másik módja a viselkedés leírásának, amely vizuálisan hasonlít egy algoritmus jó öreg folyamatábrájára. A műveletek végrehajtási folyamatának szimulálására szolgál.

A tevékenységdiagramok használatának fő iránya az osztályműveletek megvalósításának jellemzőinek megjelenítése, amikor a végrehajtásukhoz algoritmusokat kell bemutatni.

A tevékenységdiagramban az entitások egy fő típusát használjuk - a cselekvést, és egyfajta kapcsolatot - az átmeneteket (irányítás átadása). Olyan konstrukciókat is alkalmaznak, mint a villák, összevonások, összekötések, elágazások. Névként ajánlott egyszerű művelet használjon igét magyarázó szavakkal.

szekvencia diagram

szekvencia diagram(szekvencia diagram) a rendszer viselkedésének "példákkal" való leírásának módja.

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 - egymással kölcsönhatásban lévő osztályozók (főleg osztályok, komponensek és szereplők) példányait, és egyfajta kapcsolatokat - hivatkozásokat, amelyeken keresztül üzeneteket cserélnek.

Lehetséges üzenettípusok (a kép a larin.in oldalról származik):

Kommunikációs diagram

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.

Így a kommunikációs diagramban, valamint a szekvenciadiagramban az entitások egy fő típusát használjuk - kölcsönható osztályozók példányait és egyfajta kapcsolati típust - kapcsolatokat. Itt azonban nem az időn van a hangsúly, hanem a konkrét esetek közötti kapcsolatok szerkezetén.

Alkatrész diagram

Alkatrész diagram(komponens diagram) - a szimulált rendszert alkotó (logikai vagy fizikai) modulok közötti kapcsolatot mutatja.

A komponensdiagram fő entitástípusa maguk a komponensek, valamint az interfészek, amelyeken keresztül a komponensek közötti kapcsolat látható. A következő összefüggések érvényesek a komponens diagramban:

• komponensek és interfészek közötti implementációk (a komponens valósítja meg az interfészt);
• a komponensek és interfészek közötti függőségek (egy komponens interfészt használ);

Elhelyezési diagram

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.

Az elhelyezési diagramban a komponens diagramhoz képest kétféle entitást adunk hozzá: egy műterméket, amely a komponens implementációja és egy csomópontot (lehet egy osztályozó, amely leírja a csomópont típusát, vagy egy adott példány), valamint a csomópontok közötti asszociációs kapcsolat, amely azt mutatja, hogy a csomópontok fizikailag kapcsolódtak a futási időben.

Objektum diagram

Objektum diagram(objektumdiagram) - egy osztálydiagram példánya.

Az objektumdiagramban az entitások egy fő típusát használjuk: az objektumokat (osztálypéldányok), amelyek között konkrét kapcsolatok vannak feltüntetve (leggyakrabban asszociációs példányok). Az objektumdiagramok segéd jellegűek – valójában példák (mondhatnánk, memóriakiíratások), amelyek megmutatják, milyen objektumok léteznek, és milyen kapcsolatok vannak közöttük a rendszer működésének egy adott pillanatában.

A belső szerkezet diagramja(összetett szerkezeti diagram) a szerkezeti osztályozók, elsősorban osztályok és komponensek részletesebb bemutatására szolgál.

A szerkezeti osztályozó téglalapként jelenik meg, felül az osztályozó nevével. Belül alkatrészek vannak. Több rész is lehet. Az alkatrészek kölcsönhatásba léphetnek egymással. Ezt különböző típusú csatlakozók jelzik. Az alkatrész külső szélén lévő helyet, amelyhez a csatlakozó csatlakozik, portnak nevezzük. A portok szintén a szerkezeti osztályozó külső határán helyezkednek el.

Interakció áttekintése diagram(interaction overview diagram) egyfajta tevékenységdiagram, kiterjesztett szintaxissal: az áttekintő interakciós diagram elemeiként a szekvenciadiagramok által meghatározott interakciókra (interakcióhasználatra) mutató hivatkozások működhetnek.

Időzítési diagram

Időzítési diagram(időzítési diagram) a szekvenciadiagram egy speciális formája, amelyben kiemelt figyelmet fordítanak az osztályozók különböző példányai állapotának változására és azok időbeli szinkronizálására.

Csomag diagram

Csomag diagram(csomagdiagram) az egyetlen eszköz, amely lehetővé teszi magának a modellnek a komplexitásának kezelését.

A jelölés fő elemei a különböző sztereotípiákkal rendelkező csomagok és függőségek.

Entitás-kapcsolat modell (ER-modell)

hasonló osztálydiagramok(UML) lehet ER modell, amelyet az adatbázisok tervezésénél használnak (relációs modell).

Az entitás-kapcsolati modell (ER-modell) egy olyan adatmodell, amely lehetővé teszi a témakör fogalmi sémáinak leírását. Az ER modellt magas szintű (koncepcionális) adatbázistervezésben használják. Segítségével kiemelheti a kulcsfontosságú entitásokat, és kijelölheti az ezen entitások között létrehozható kapcsolatokat. wikipédia

A témakör bármely töredéke ábrázolható entitások halmazaként, amelyek között van valamilyen kapcsolathalmaz.

Alapfogalmak:

Lényeg(entitás) olyan entitás, amely valamilyen módon azonosítható, ami megkülönbözteti más entitásoktól, pl. ÜGYFÉL 777. Az entitás valójában attribútumok halmaza.

Entitáskészlet(entitáskészlet) - azonos típusú (azonos tulajdonságokkal rendelkező) entitások halmaza.

Kapcsolat(kapcsolat) több entitás között létrejött asszociáció.

Tartomány(domain) - az attribútum értékkészlete (domain).

Háromféle bináris hivatkozás létezik:

• 1-1- az egyik osztályhoz tartozó entitás egyetlen példánya egy másik osztályhoz tartozó entitás egyetlen példányához van társítva, például HEAD - DEPARTMENT;
• 1-től N-ig vagy egy a sokhoz- egy osztályba tartozó entitás egyetlen példánya egy másik osztályhoz tartozó entitás sok példányához van társítva, például OSZTÁLY - ALKALMAZOTT;
• N-től M-ig vagy sok a sok- egy osztályba tartozó entitások sok példánya egy másik osztály entitásának sok példányához van társítva, például EMPLOYEE - PROJEKT;
Az UML alapfogalmak szószedete

tárgy- olyan entitás, amely egyediséggel rendelkezik, és magába foglalja az állapotot és a viselkedést.

osztály- az állapotot meghatározó közös attribútumokkal és a viselkedést meghatározó műveletekkel rendelkező objektumok halmazának leírása.

felület- elnevezett műveletsor, amely meghatározza a fogyasztó által igényelhető és a szolgáltató által nyújtott szolgáltatások körét.

Együttműködés- objektumok halmaza, amelyek kölcsönhatásba lépnek valamilyen cél elérése érdekében.

Színész- olyan entitás, amely kívül esik a modellezett rendszeren és közvetlenül kölcsönhatásba lép vele.

összetevő- a rendszer moduláris része a szükséges és biztosított interfészek jól meghatározott készletével.

Műalkotás- a fejlesztési folyamat során felhasznált vagy generált információelem szoftver. Más szavakkal, a műtermék a megvalósítás fizikai egysége, amely egy modellelemből (például osztályból vagy komponensből) származik.

Csomópont- egy számítási erőforrás, amelyen a műtermékeket elhelyezik, és szükség esetén végrehajtják.

A viselkedési entitások célja a viselkedés leírása. Csak két alapvető viselkedési entitás létezik: az állapot és a cselekvés.

állapot- egy tárgy életciklusának egy olyan időszaka, amelyben a tárgy egy bizonyos feltételnek eleget tesz és saját tevékenységét végzi, vagy valamilyen esemény bekövetkezésére vár.

akció- primitív atomi számítás.

Gép egy olyan csomag, amely meghatározza a modellezett entitás viselkedésének egy véges számú állapottal és átmenettel rendelkező diszkrét térként való megjelenítéséhez szükséges fogalmak halmazát.

osztályozó azonos típusú objektumok halmazának leírója.

Extra olvasmány

• Fowler M. UML. Alapok, 3. kiadás
• Butch G., Rambo D., Jacobson I. UML nyelv. Használati útmutató

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;

Szekvencia diagramok - 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) - a tervezett információs rendszer fizikai architektúrájának modellezésére.

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

Interakció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 vonal van lehúzva. függőleges vonal. 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, az üzenet nyíllal 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 az egész határán helyezkednek el környezet. 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 onnan származnak Részletes leírás eseményfolyam, amely a használati eset alapján jön létre, utóbbi pedig a követelményeken alapul. 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, és emellett általában életciklus részek egybeesnek az egész körforgásával: élnek-halnak 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).

Az UML vagy Unified Modeling Language egy grafikus leíró nyelv objektummodellezéshez a szoftverfejlesztés területén. De az UML használata nem korlátozódik az IT-re, az UML gyakorlati alkalmazásának másik nagy területe az üzleti folyamatok modellezése, a rendszertervezés és a szervezeti struktúrák feltérképezése. Az UML lehetővé teszi a szoftverfejlesztők számára, hogy megállapodjanak a megjelenítéshez szükséges grafikus jelölésekről. általános fogalmakés a tervezésre és fejlesztésre összpontosít.

Az UML előnyei

• Az UML grafikus szimbólumokat használ a modellezett rendszer elemeihez, és az UML diagramok meglehetősen könnyen érthetők;
• Az UML lehetővé teszi a rendszerek leírását szinte minden lehetséges nézőpontból, különféle szempontok figyelembevételével;
• Az UML objektumorientált: elemzési és felépítési módszerei szemantikailag közel állnak a modern OOP nyelvekben használt programozási módszerekhez;
• Az UML nyílt szabvány. A szabvány változatról verzióra fejlődik és fejlődik, megfelelve a rendszerek leírására vonatkozó legmodernebb követelményeknek;
• tartalmaz egy kiterjesztési mechanizmust, amely lehetővé teszi további szövegek beírását és grafikai típusok, amely lehetővé teszi az UML használatát nem csak az informatika területén.

Az UML diagramok típusai

Az UML-ben 14 diagramtípus létezik. 2 kategóriába sorolhatók:

• szerkezeti képviselő információs szerkezet;
• viselkedési, amely a rendszer viselkedését és az interakciók különböző aspektusait reprezentálja. A viselkedésdiagramok külön alfaja az interakciós diagramok.

Az UML diagramtípusok hierarchiája,
osztálydiagrammal ábrázolva

Szerkezeti diagramok

1. osztálydiagram az objektumorientált modellezés kulcseleme. Ennek a diagramnak a segítségével (valójában át osztályok, az övék attribútumokat, módés az osztályok közötti függőségek) a tartománymodellt és a modellezett rendszer szerkezetét írja le.
2. Alkatrész diagram megjeleníti a programkód nagy blokkra (szerkezeti komponensekre) való felosztását és megmutatja függőségek közöttük. Az összetevők lehetnek csomagok, modulok, könyvtárak, fájlok stb.
3. objektum diagram a szimulált rendszer teljes vagy részleges kivágását mutatja egy adott időpontban. Az osztálypéldányokat (objektumokat), azok állapotát ( aktuális értékeket attribútumok) és a köztük lévő kapcsolat.
4. Összetett szerkezeti diagram bemutatja az osztályok belső felépítését és lehetőség szerint e szerkezet elemei közötti kölcsönhatásokat.
5. Csomag diagram a csomagokat és a köztük lévő kapcsolatokat mutatja be. Az ilyen típusú diagramok a modell felépítésének (és ennek megfelelően a vele való munkavégzésnek) egyszerűsítését szolgálják azáltal, hogy a modellelemeket bizonyos kritériumok szerint csoportokba vonják.
6. Telepítési diagram modellek telepítése szoftver komponensek (műtárgyak) a számítási erőforrásokon/hardverkomponenseken ( csomópontok).
7. Profil diagram egy bővíthetőségi mechanizmust ír le, amely lehetővé teszi, hogy az UML-t különféle tématerületekhez és tevékenységi területekhez igazítsák.

Példa UML osztálydiagramra

Viselkedési diagramok

1. tevékenység diagram akciókat mutat ( akciókat) ebből valamilyen tevékenység ( tevékenység). A tevékenységdiagramok üzleti folyamatok, technológiai folyamatok, soros és párhuzamos számítások modellezésére szolgálnak.
2. Használati eset diagram(vagy használati eset diagram) leírja a szereplők (szereplők) kapcsolatát és a szimulált rendszer használati eseteit (képességeit). A diagram fő célja, hogy olyan univerzális eszköz legyen az ügyfelek, a fejlesztők és a végfelhasználók számára, amelynek segítségével közösen meg lehet beszélni a rendszert - annak képességeit és viselkedését.
3. Állapot diagram egy entitás dinamikus viselkedését ábrázolja, bemutatva, hogy az entitás az aktuális állapotától függően hogyan reagál a különböző eseményekre. Valójában ez egy állapotdiagram az atomok elméletéből.
4. Kommunikációs diagram(V korai változatai együttműködési diagram) az összetett szerkezet részei és az együttműködés szerepei közötti kölcsönhatásokat mutatja be. A diagram kifejezetten jelzi az elemek (objektumok) közötti kapcsolatot.
5. szekvencia diagram objektum kölcsönhatások sorozatának megjelenítésére szolgál. Megmutatja egy adott objektum életciklusát és a szereplők (szereplők) interakcióját valamilyen használati eseten belül, az általuk kicserélt üzenetek sorozatát.
6. Interakció áttekintése diagram tartalmazza a szekvenciadiagram és a vezérlőfolyamat-konstrukció egy részét. Segít az objektumok kölcsönhatásának különböző nézőpontokból történő átgondolásában.
7. Időzítési diagram- az interakciós diagramok külön alfaja, amely az időzítésre szakosodott. Az ilyen típusú diagramok az objektumok viselkedésének tanulmányozására szolgálnak egy bizonyos ideig.

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.

Mi az 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 írja

Az UML egy grafikus leíró nyelv objektummodellezéshez a szoftverfejlesztés, az üzleti folyamatok modellezése, a rendszertervezés és a szervezeti struktúrák feltérképezése területén.

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.

Alkalmazás

Lássuk, hogyan tud dolgozni ezzel az UML-lel az IDE-ből. IDE-ként vegye fel IntelliJ ötlet. Ha használja IntelliJ Idea Ultimate, akkor a beépülő modult "dobozból" telepítjük. UML támogatás". Lehetővé teszi gyönyörű osztálydiagramok automatikus generálását. Például a Ctrl + N billentyűkombinációval vagy a "Navigáció" -> "Osztály" menüponttal lépjen az osztályra Tömb lista. Most, keresztül helyi menü osztálynév szerint válassza a "Diagram" -> "Show diagram popup" lehetőséget. Ennek eredményeként egy gyönyörű diagramot kapunk:

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 V környezeti változó környezet 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? Egy "" nevű gráfleíró nyelvet használ pont", és ez sokoldalúbbá teszi, mert adott nyelv nem csak a PlantUML-t használják. Sőt, mindent, amit alább meg fogunk tenni, nemcsak az IDE-ben, hanem azon belül is megtehetjük online szolgáltatás planttext.com. A PlantUML bővítmény telepítése után a "Fájl" -> "Új" menüpontban UML-diagramokat készíthetünk. Hozzunk létre egy "UML osztály" diagramot. Ennek során automatikusan létrejön egy sablon egy példával. Töröljük a tartalmát, és hozzuk létre a sajátunkat, a Habr: Class Relations cikkével felvértezve – az 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 legelején van egy tábla az összefüggések leírásával:

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ő tartalmat, amely leírja a két osztályt: @startuml osztály ArrayList ( ) osztály LinkedList ( ) @enduml Az eredmény megtekintéséhez válassza a "View" -> " Eszköz Windows" -> "PlantUML". Mindössze két négyzetet fogunk kapni, amelyek osztályokat jelölnek. Mint tudjuk, mindkét osztály megvalósítja a List interfészt. Az osztályok ezt a relációját implementációnak (realizációnak) nevezik. A szaggatott vonallal ellátott nyíl ábrázolására szolgál egy ilyen kapcsolat.. Rajzoljuk le: interfész Lista Lista< | . . 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. Ebben az esetben a kapcsolat típusa: ö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?)

Automatizálás

Eszik különböző módokon a PlantUML diagramok automatikus generálása. Például be ötleteket Van egy SketchIT bővítmény, de nem rajzolja meg őket megfelelően. Például az interfészek megvalósítása helytelenül van megrajzolva (öröklődésként jelenik meg). Vannak online példák is arra, hogyan építsd be ezt a projekted életciklusába. Mondjuk azért Maven van egy példa az uml-java-docklet használatára. Hogy megmutassuk, hogyan is van ez, a Maven archetípust fogjuk használni gyors alkotás maven projekt. Végezzük el a parancsot: mvn archetype:generate A szűrő kiválasztásának kérdésére ( Válasszon egy számot, vagy alkalmazzon szűrőt) hagyja el az alapértelmezett beállítást az Enter megnyomásával. mindig az lesz" maven-archetype-quickstart". Kiválasztjuk a legújabb verziót. Ezután válaszoljon a kérdésekre, és fejezze be a projekt létrehozását:

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)

Következtetés

Mint látható, az UML lehetővé teszi az alkalmazás szerkezetének megjelenítését. Ezenkívül az UML nem korlátozódik erre. Az UML segítségével leírhat különféle folyamatokat a vállalaton belül, vagy leírhatja azt az üzleti folyamatot, amelyen belül az Ön által írt funkció működik. Ön dönti el, hogy az UML mennyire hasznos Önnek személyesen, de mindenképpen hasznos lesz rászánni az időt és részletesebben megismerni. #Viacheslav A bejegyzés orosz verziója: UML diagram Java a CodeGym-en

Minden UML diagramok 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.

1.5.1. Használati diagram

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:

• kapcsolat a szereplő és a használati eset között 3;
• a szereplők közötti általánosítás 4 ;
• általánosítás a használati esetek között 5 ;
• függőségek ( különféle típusok) használati esetek között 6 .

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ás pontban megadott 2.2.

1.5.2. osztálydiagram

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:

• asszociáció a 2. osztályok között (sok további részlettel);
• általánosítás a 3. osztályok között;
• (különféle típusú) függőségek a 4. osztályok, valamint az osztályok és interfészek között.

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

1.5.3. automata diagram

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.

1.5.4. tevékenység diagram

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.

1.5.5. szekvencia diagram

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 egyik fő típusát használjuk – 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 kapcsolattípust – kapcsolatokat 2, amelyeken keresztül üzeneteket cserélnek 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. Szaggatott vonal, kijön belőle, az életvonalnak (mentővonalnak) hívják 4 . 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.

1.5.6. Kommunikációs diagram

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.

1.5.7. Alkatrész diagram

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:

• komponensek és interfészek közötti implementációk (a komponens valósítja meg az interfészt);
• a komponensek és interfészek közötti függőségek (egy komponens interfészt használ) 3.

Az ábra a komponensdiagramban használt jelölés főbb elemeit mutatja. Részletes leírás a 3. fejezetben található.

1.5.8. Elhelyezési diagram

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ásidő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ó.