UML vagy Unified Modeling Language – grafikus leíró nyelv objektummodellezéshez a fejlesztés területén szoftver. 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állapodásra jussanak grafikus szimbólumokáltalános koncepciók bemutatására és a tervezésre és fejlesztésre koncentrálni.
Az UML-ben 14 diagramtípus létezik. 2 kategóriába sorolhatók:
Az UML diagramtípusok hierarchiája,
osztálydiagrammal ábrázolva
Példa UML osztálydiagramra
Mutassa be egy objektum viselkedését az élete során, az objektum létrehozásától a megsemmisítéséig. Minden állapotdiagram valamilyen automatát ábrázol.
A Leírás részben ismerje meg a diagramok olvasásához szükséges alapvető állapotdiagram karakterkészletet.
A többi rész ("Példa", "Használat") elolvasása után kipróbálhatja magát az állapotdiagramok önálló elkészítésében.
Íme a fő karakterkészlet állapotdiagramok szükséges volt a diagram olvasásához. A többi rész ("Példa", "Alkalmazás") elolvasása után már tud írni állapotdiagramok egyedül!
| Term | Kép | Leírás |
|---|---|---|
| Kezdeti pszeudostata | A rendszer kezdeti állapota | |
| Átmenet |  |
Az átmenet azt jelenti, hogy egyik állapotból a másikba lépünk. |
| Állapot |  |
A rendszer által végrehajtott műveleteket jelzi (beleértve lehetséges opciók), ami a szereplők által megfigyelt eredményekhez vezet. |
| Állapot tevékenység állapota |
 |
Egy használati eset nehéz lépése egy másik használati esettel is ábrázolható. UML kifejezéssel azt mondjuk, hogy az első használati eset magában foglalja a másodikat is. |
| Végállapot |  |
Lehetővé teszi a rendszerek vagy alrendszerek határainak kijelölését. |
| Belső tevékenységek |  |
Az az eset, amikor az állapotok átmenet nélkül tudnak reagálni az eseményekre, ebben az esetben az esemény, az őrség és a tevékenység az állapottéglalapon belülre kerül. |
| bemeneti tevékenység | A beviteli tevékenység minden alkalommal végrehajtódik, amikor belép az állapotba | |
| kimeneti tevékenység | Kilépési tevékenység – minden alkalommal végrehajtódik, amikor elhagyja az államot. | |
| szuperállam |  |
Gyakran előfordul, hogy több állapotnak közös átmenetei és belső tevékenységei vannak. Ilyen esetekben részállapotokká (substate) alakíthatja át őket, és az általános viselkedést átviheti egy szuperállapotba (superstate). |
| Párhuzamos államok |  |
Az állapotok több egyidejű állapotra bonthatók, amelyek egyidejűleg futnak. |
Az UML állapotdiagramok alkalmasak egyetlen objektum viselkedésének leírására több felhasználási esetben. De nem nagyon alkalmasak sok objektum interakciójával jellemezhető viselkedés leírására. Ezért célszerű más technológiákat is használni az állapotdiagramokkal együtt. Például az interakciós diagramok (4. fejezet) nagyszerűen leírják több objektum viselkedését egyetlen használati esetben, míg az UML tevékenységdiagramok arra alkalmasak, hogy több objektum fő műveletsorát több használati esetben is megmutassák.
Nem mindenki tartja természetesnek az állapotdiagramokat. Figyelje meg, hogyan dolgoznak velük a szakértők. Lehetséges, hogy a csapattagok úgy gondolják, hogy az állapotdiagramok nem megfelelőek az ő munkamódszerükhöz. Nem ez a legnagyobb nehézség; emlékeznie kell a különböző munkamódszerek megosztására.
Ha állapotdiagramokat használ, ne próbálja meg rajzolni azokat a rendszer minden osztályához. Ezt a megközelítést gyakran használják a formailag szigorú teljesség érdekében, de ez szinte mindig felesleges erőfeszítés. Az állapotdiagramokat csak olyan osztályokhoz használja, amelyek érdekes viselkedést mutatnak, ahol az állapotdiagram ábrázolása segít megérteni, hogyan mennek a dolgok.
Sok szakértő ezt hiszi az UI szerkesztő és a vezérlőobjektumok hasznos funkciókkal rendelkeznek, ha állapotdiagrammal jelenítik meg őket.
Itt megpróbáltuk a tanulás legegyszerűbb módját biztosítani UML állapotdiagramok.
Sok más nyelvhez hasonlóan ez is karakterkészletet használ a leíráshoz. Ezeknek a szimbólumoknak a jelentése a „Megjegyzések (leírás)” részben található táblázatban található. Minden jelnek saját neve (kifejezése) és helyesírása van. Ezenkívül minden kifejezéshez rövid magyarázat tartozik, hogy gyorsan megértsük a fő lényegét.
Ezután javasoljuk, hogy lépjen a „Példák” szakaszra állapotdiagramok hogy kipróbálja magát a különböző diagramok olvasásában. Ezután érdemes áttanulmányozni a "Használat" részt, mert bár az UML-ben kevés diagramtípus van, a maximális hasznot csak a megfelelő diagramok rendeltetésszerű felhasználásával érheti el a használatuk.
Állapotgép diagramok egy jól ismert technika a rendszer viselkedésének leírására. Az állapotdiagramok ilyen vagy olyan formában az 1960-as évek óta léteznek, és az objektum-orientált programozás korai napjaiban a rendszer viselkedésének ábrázolására használták őket. Objektumorientált megközelítésekben egyetlen osztály állapotdiagramját rajzolja meg, amely megmutatja egyetlen objektum viselkedését annak élettartama során.
Amikor véges állapotú gépekről írnak, elkerülhetetlenül példaként említik a tempomatrendszereket vagy az automatákat.
Úgy döntöttünk, hogy a gótikus kastély titkos központjának vezérlőjét használjuk. Ebben a kastélyban szeretnénk elrejteni kincseinket, hogy nehezen leljenek rájuk. Ahhoz, hogy hozzáférhessünk a széf zárjához, ki kell húznunk egy stratégiai gyertyát a kandeláberből, de a zár csak akkor jelenik meg, ha az ajtó zárva van. A zár megjelenése után belehelyezhetjük a kulcsot és kinyithatjuk a széfet. A nagyobb biztonság érdekében úgy alakítottuk, hogy a széfet csak a gyertya eltávolítása után lehessen kinyitni. Ha a tolvaj nem veszi figyelembe ezt az óvintézkedést, akkor szabadjára engedünk egy förtelmes szörnyet, aki lenyeli a tolvajt.
ábrán. 10.1 látható állapotdiagram vezérlő osztály, amely a szokatlan biztonsági rendszeremet kezeli. Az állapotdiagram a létrehozandó vezérlőobjektum állapotával kezdődik: állapotok Várjon. Ezt a diagramon jelzi kezdeti pszeudostata, amely nem állapot, hanem a kezdőállapotra mutató nyíllal rendelkezik.
Az ábra azt mutatja, hogy a vezérlő három állapot egyikében lehet: Várakozás (Várakozás), Zárolás (Zárolás) és Nyitás (Nyitva). Az ábra azt is mutatja, hogy a vezérlő milyen szabályok szerint vált át egyik állapotból a másikba. Ezeket a szabályokat átmenetként – állapotokat összekötő vonalként – ábrázoljuk.
Az átmenet azt jelenti, hogy egyik állapotból a másikba lépünk. Minden átmenetnek megvan a saját címkéje, amely három részből áll:
trigger-azonosító [védelem]/tevékenység (trigger-aláírás /tevékenység). Mindegyik nem kötelező. Általában, trigger-id az egyetlen esemény, amely állapotváltozást okozhat.
Az őr, ha meg van adva, egy logikai feltétel, amelynek teljesülnie kell az átálláshoz. Az aktivitás a rendszer bizonyos viselkedése az átmenet során. Bármilyen viselkedési kifejezés lehet. Az ID trigger teljes formája több eseményt és paramétert is tartalmazhat. A Várakozás állapotból (10.1. ábra) egy másik állapotba való átmenet a következőképpen értelmezhető: „A várakozás állapotában, ha a gyertyát eltávolítják, egy zár jelenik meg, és a Lezárt állapotba lép.”
Az átmenet leírásának mindhárom része nem kötelező. A tevékenység kihagyása azt jelenti, hogy az átmenet során semmi sem történik. Az őrök kihagyása azt jelenti, hogy az átmenet mindig végrehajtásra kerül, ha a kiváltó esemény bekövetkezik. Az eseményindító azonosító ritkán hiányzik, de előfordul. Ez azt jelenti, hogy az átmenet azonnal megtörténik, ami főleg aktív állapotokban figyelhető meg.
Ha egy esemény egy bizonyos állapotban következik be, akkor ebből az állapotból csak egy átmenetet lehet végrehajtani, például Lock állapotban (10.1. ábra) a védelmeknek kölcsönösen ki kell zárniuk egymást. Ha egy esemény történik, és nincsenek engedélyezett átmenetek – például egy széf bezárása Várakozás állapotban vagy gyertya eltávolítása, miközben az ajtó nyitva van – az esemény figyelmen kívül marad.
Végállapot ( végső állapot) azt jelenti, hogy az állapotgép befejezte a futást, ami a vezérlőobjektum törlését okozza. Tehát azok számára, akik nem voltak elég óvatosak, hogy beleesjenek a csapdába, amikor a vezérlő objektum megszűnik létezni, kénytelenek vagyunk visszahelyezni a nyulat a ketrecébe, felmosni a padlót, és újraindítani a rendszert.
Ne feledje, hogy az állapotgépek csak azokat az objektumokat tudják megjeleníteni, amelyeket közvetlenül megfigyelnek vagy amelyekre hatást gyakorolnak. Így bár azt várhatnánk, hogy kinyitott ajtó mellett helyezzünk be vagy vegyünk ki valamit a széfből, nem jelöltük meg a diagramon, mert a vezérlő nem tud róla semmit mondani.
Amikor a fejlesztők objektumokról beszélnek, gyakran hivatkoznak az objektumok állapotára, vagyis az objektum mezőiben található összes adat kombinációjára. Az állapot az állapotgép diagramban azonban az állapot elvontabb fogalma; a lényeg az, hogy a különböző állapotok az eseményekre való reagálás különböző módjait jelentik.
Az államok átmenet nélkül reagálhatnak az eseményekre belső tevékenységek (belső tevékenységek), ebben az esetben az esemény, az őrség és a tevékenység az állapottéglalapon belülre kerül.
ábrán. A 10.2. ábra a szerkesztő szövegmezőiben megfigyelhető belső szimbólumtevékenységekkel és súgórendszer-események állapotát mutatja. UI. A belső tevékenység olyan, mint egy önátmenet – egy átmenet, amely visszatér ugyanabba az állapotba. A belső tevékenységek szintaxisa az események, védelmek és eljárások azonos logikai sémája szerint épül fel.
ábrán. A 10.2 speciális tevékenységeket is mutat: input és output tevékenységek. bemeneti tevékenység végrehajtják, amikor belép az állapotba; kimeneti tevékenység– amikor elhagyja az államot. A belső tevékenységek azonban nem kezdeményeznek bemeneti és kimeneti tevékenység; ez a különbség között belső tevékenységek ésönátmenetek .
Az eddig leírt állapotokban az objektum néma, és vár a következő eseményre, mielőtt bármit tenne. Lehetnek azonban olyan állapotok, amelyekben az objektum valamilyen tevékenységet mutat.
Állapot Keresésábrán. A 10.3 ilyen állapot tevékenység állapota: a folyamatban lévő tevékenységet a szimbólum jelzi do/; innen a kifejezés tevékenységet végezni (légy aktív). A keresés befejezése után tevékenység nélküli átmeneteket hajtanak végre, például új berendezéseket mutatnak be (Új hardver megjelenítése). Ha a tevékenység során törlési esemény történik ( megszünteti), Ez csinál-tevékenység egyszerűen megszakad, és visszatérünk az állapothoz Frissítse a Hardver ablakot.
Mind a cselekvő tevékenységek, mind a normál tevékenységek valamilyen viselkedés megnyilvánulását jelentik. A döntő különbség a kettő között az, hogy a normál tevékenységek "azonnal" megtörténnek, és nem szakíthatják meg őket normál események, míg a tevékenységek korlátozott ideig futhatnak, és megszakíthatók, amint az a 2. ábrán látható. 10.3. Azonnali számára különböző rendszerek másként értelmezik; valós idejű rendszerek esetén ez több gépi utasítást is igénybe vehet, asztali szoftvereknél pedig több másodpercig is eltarthat.
BAN BEN UML 1 a szokásos tevékenységeket jelöltük a kifejezéssel akció(cselekvés) és a kifejezés tevékenység(tevékenység) csak az csinál-tevékenységeket.
Gyakran előfordul, hogy több állapotnak közös átmenetei és belső tevékenységei vannak. Ilyen esetekben részállapotokká (alállapotokká) alakíthatja őket, és az általános viselkedést átviheti egy szuperállapotba (superstate), amint az az ábrán látható. 10.4. A szuperállam nélkül meg kellene rajzolnunk az átmenetet megszünteti(mégse) egy állapoton belül mindhárom állapotra Adja meg a kapcsolat részleteit.
Az állapotok több egyidejű állapotra bonthatók, amelyek egyidejűleg futnak. ábrán. A 10.5. ábra egy egyszerű ébresztőórát mutat be, amely akár CD-t, akár rádiót képes bekapcsolni, és az aktuális időt vagy a jelidőt mutatja.
A CD/rádió opciók és az aktuális idő/ébresztési idő párhuzamos. Ha ezt nem párhuzamos állapotdiagrammal akarná ábrázolni, akkor egy rendetlen diagramot kapna, mivel állapotokat kell hozzáadni. A két viselkedést két állapotdiagramra bontva sokkal világosabbá válik.
Rizs. 10.5 is tartalmazza őskori állapot(történeti álállapot). Ez azt jelenti, hogy az óra bekapcsolásakor a rádió/CD opció arra az állapotra vált, amelyben az óra ki volt kapcsolva. A történelemből kijövő nyíl mutatja, melyik állam létezett eredetileg, amikor még nem volt történelem.
Az állapotdiagram három fő módon valósítható meg: beágyazott kapcsoló utasítással, állapotmintával és állapottáblázattal. Az állapotdiagramokkal való munka legközvetlenebb megközelítése a beágyazott switch utasítás, például az 1. ábrán látható. 10.6.
Bár ez a módszer egyszerű, még ennél az egyszerű esetnél is nagyon hosszú. Ráadásul ezzel a megközelítéssel nagyon könnyen elveszíthető az irányítás, ezért még elemi helyzetekben sem javasoljuk a használatát.
Az állapotminta az állapotosztályok hierarchiáját képviseli az állapot viselkedésének kezelésére. Az állapotdiagramon minden egyes állapotnak megvan a maga állapot-alosztálya. A vezérlő minden eseményhez rendelkezik metódusokkal, amelyek egyszerűen átirányítanak az állapotosztályra. ábrán látható állapotdiagram. A 10.1 az ábrán látható osztályokkal valósítható meg. 10.7.
A hierarchia teteje egy absztrakt osztály, amely tartalmazza az eseményeket kezelő összes metódus leírását, de implementációt nem.
Minden adott állapothoz elegendő egy adott esemény kezelő metódusát átírni, amely az állapotból való átmenetet kezdeményezi.
Az állapottábla adatként ábrázolja az állapotdiagramot.
Tehát az ábra diagramja. A 10.1 táblázat formájában is bemutatható. 10.1.
Ezután építünk egy értelmezőt, amely az állapottáblát használja a program végrehajtása során, vagy egy kódgenerátort, amely e tábla alapján osztályokat generál.
Nyilvánvaló, hogy az állapottáblázaton végzett munka nagy részét egyszer végezzük el, de ezután bármikor használható, amikor állapottal kapcsolatos problémát kell megoldani. A futásidejű állapottábla újrafordítás nélkül módosítható, ami némileg kényelmes. Az állapotsablont könnyebb összeállítani, és bár minden állapot külön osztályt igényel, a megírandó kód mennyisége meglehetősen kicsi.
A megadott megvalósítások szinte minimálisak, de ötletet adnak a jelentkezésről állapotdiagramok. Az állapotmodellek megvalósítása minden esetben meglehetősen sztereotip programot eredményez, ezért általában érdemesebb valamilyen kódgenerálást használni ehhez.
Iratkozzon fel az oldal híreire, a feliratkozási űrlapot az oldal jobb oldali oszlopában találja.
Ha szeretné megtanulni, hogyan kell szabadúszó professzionálisan dolgozni, meghívjuk a "" tanfolyamra.
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. Is adott nyelv ma aktívan használják különféle üzleti folyamatok modellezésére, rendszertervezés lebonyolítására, valamint szervezeti struktúrák megjelenítésére.
Az UML segítségével a szoftverfejlesztők biztosíthatják az ábrázoláshoz használt grafikus konvenciók teljes egyetértését á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 diagramok mindenféle modellt, könyvtárat, fájlt, csomagot, végrehajtható fájlt és sok más elemet használhatnak.
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 együttműködési diagram, amely a szerepek és az interakciók bemutatására szolgál. különféle osztályok 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.
Ebben a nézetben teljes vagy részleges pillanatképet láthat a létrehozandó rendszerről bizonyos pillanatban idő. 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ép az eredeti elemhez van csatolva, és a példányok 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.
10.4. UML DIAGRAM
10.4.1. Vizuális UML diagramok típusai
Az UML többféle vizuális diagram létrehozását teszi lehetővé:
Esetdiagramok használata;
szekvencia diagramok;
Szövetkezeti diagramok;
osztálydiagramok;
Állapotdiagramok;
Alkatrész diagramok;
Elhelyezési diagramok.
A diagramok a rendszer különböző aspektusait mutatják be. Például egy kooperatív diagram bemutatja, hogy az objektumoknak hogyan kell kölcsönhatásba lépniük a rendszer bizonyos funkcióinak megvalósítása érdekében. Minden diagramnak megvan a maga célja.
10.4.2. Használjon esetdiagramokat
A használati eset diagramok a rendszer funkcióit reprezentáló használati esetek és a rendszer funkcióit reprezentáló szereplők és személyeket vagy rendszereket képviselő szereplők közötti interakciót mutatják be, akik információt kapnak vagy továbbítanak a rendszerbe, illetve a rendszerből. ezt a rendszert. Az 1. ábrán látható egy példa egy bankjegykiadó automata (ATM) használati esetére. 10.1.
Rizs. 10.1. Használati eset diagram
A diagram a használati esetek és a szereplők közötti interakciót ábrázolja. A rendszerkövetelményeket tükrözi a felhasználó szemszögéből. Így a használati esetek a rendszer által végrehajtott funkciók, a szereplők pedig az érintettek létrehozott rendszert. A diagramok azt mutatják, hogy mely szereplők kezdeményeznek használati eseteket. Azt is megmutatják, hogy a szereplő mikor kap információt a használati esetből. Lényegében egy használati eset diagram szemlélteti a rendszer követelményeit. Példánkban a banki ügyfél különböző felhasználási eseteket kezdeményez: "Pénz felvétele a számláról", "Pénz utalása", "Pénz befizetése a számlára", "Egyenleg megjelenítése", "Az azonosító szám módosítása", "Befizetés". A bankpénztáros kezdeményezheti az „Azonosítószám módosítása” használati ügyet. A „Befizetés” használati esetből egy nyíl látható a Hitelrendszerre. A színészek lehetnek külső rendszerek, ebben az esetben a Hitelrendszer pontosan szereplőként jelenik meg – az ATM rendszeren kívül van. A használati esetről a szereplőre mutató nyíl azt jelzi, hogy a használati eset bizonyos információkat nyújt a szereplőnek. Ebben az esetben a Fizetés használati esete biztosítja a Hitelrendszer számára a bankkártyás fizetési információkat.
A használati esetek diagramjaiból elég sok információhoz juthatunk egy rendszerről. Az ilyen típusú diagram a rendszer általános működését írja le. A felhasználók, projektmenedzserek, elemzők, fejlesztők, minőségbiztosítási szakemberek és a rendszer egésze iránt érdeklődők a használati eset diagramok vizsgálatával megérthetik, mit kell tennie a rendszernek.
10.4.3. Szekvencia diagramok
A szekvenciadiagramok a használati eseten belül előforduló események folyamatát mutatják be. Például a „Pénz kivonása” használati eset többféle lehetséges szekvenciát biztosít: pénzfelvétel, pénzfelvételi kísérlet, amikor nincs elég pénz a számlán, pénzfelvételi kísérlet helytelen azonosítószámmal és néhány más. A 20 dollár számláról történő kivonásának szokásos forgatókönyve (olyan problémák hiányában, mint a hibás azonosítószám vagy a számlán lévő pénzhiány) a 2. ábrán látható. 10.2.
10.2. ábra. Joe ügyfél 20 dolláros kivonási diagramja
A diagram tetején látható az összes szereplő és objektum, amelyre a rendszernek szüksége van a Pénzkivonás használati eset végrehajtásához. A nyilak a szereplő és az objektum, illetve az objektumok között a szükséges funkciók végrehajtása érdekében átadott üzeneteknek felelnek meg. Azt is meg kell jegyezni, hogy a szekvenciadiagram objektumokat mutat, nem osztályokat. Az osztályok az objektumok típusai. A tárgyak konkrétak; osztály helyett Ügyfél a szekvenciadiagram egy adott vásárlót, Joe-t ábrázol.
A használati eset akkor kezdődik, amikor az ügyfél behelyezi a kártyáját az olvasóba – ez az objektum az ábra tetején lévő dobozban látható. Beolvassa a kártya számát, megnyitja a Joe-fiók objektumot, és inicializálja az ATM képernyőt. A képernyő megkérdezi Joe-tól a regisztrációs számát. Az ügyfél beírja az 1234-es számot. A képernyő ellenőrzi a számot a Joe-fiók objektumon, és megállapítja, hogy helyes-e. A képernyőn megjelenik Joe egy menü közül, amelyből választhat, és kiválasztja a „Visszavonás” lehetőséget. A képernyő megkérdezi, mennyit akar kivenni, és Joe beír 20 dollárt. A képernyő pénzt von le a számláról. Ennek során a Joe Account objektum által végrehajtott folyamatok sorozatát kezdeményezi. Ezzel egyidejűleg ellenőrzik, hogy legalább 20 dollár van-e ezen a számlán, és a szükséges összeget levonják a számláról. Akkor bankautomata utasítást kap, hogy "adjon ki egy csekket és 20 dollár készpénzt". Végül ugyanaz a "Joe's account" objektum utasítja a kártyaolvasót a kártya visszaküldésére.
Tehát ez a szekvenciadiagram azt a műveletsort szemlélteti, amely megvalósítja a „Pénz kivonása a számláról” használati esetet azon a konkrét példán, amikor az ügyfél Joe 20 dollárt vett fel. Ezt a diagramot tekintve a felhasználók megismerkednek munkájuk sajátosságaival. Az elemzők a műveletek sorrendjét (folyamatát), a fejlesztők a létrehozandó objektumokat és azok működését látják. A minőségellenőrző szakemberek megértik a folyamat részleteit, és képesek lesznek teszteket kidolgozni azok ellenőrzésére. Így a szekvenciadiagramok a projekt minden résztvevője számára hasznosak.
10.4.4. szövetkezeti grafikonok
A kooperatív diagramok ugyanazt az információt jelenítik meg, mint a sorozatdiagramok. Ezt azonban másként és más célokra teszik. ábrán látható. A 10.2. ábra a szekvencia diagramot mutatja. 10.3 kooperatív diagram formájában.
Mint korábban, a tárgyak téglalapként, a szereplők pedig figurákként jelennek meg. Ha a szekvenciadiagram a szereplők és tárgyak közötti interakciót mutatja az időben, akkor a kooperatív diagramban nincs időbeli kapcsolat. Így látható, hogy a kártyaolvasó utasítja a "Joe számláját" a megnyitásra, a "Joe's account" pedig arra készteti a kártyaolvasót, hogy visszaadja a kártyát a tulajdonosnak. A közvetlenül kölcsönható objektumokat vonalak kötik össze. Ha például a kártyaolvasó közvetlenül kommunikál az ATM képernyőjével, akkor határvonalat kell húzni közöttük. A vonal hiánya azt jelenti, hogy nincs közvetlen kommunikáció az objektumok között.
Rizs. 10.3. A számláról történő pénzfelvétel folyamatát leíró szövetkezeti diagram
Tehát a kooperatív diagram ugyanazokat az információkat jeleníti meg, mint a sorrenddiagram, de más célokra van rá szükség. A minőségellenőrzési szakemberek és rendszertervezők képesek lesznek megérteni a folyamatok objektumok közötti eloszlását. Tegyük fel, hogy valamilyen kooperatív diagram egy csillaghoz hasonlít, ahol több objektum kapcsolódik egy központi objektumhoz. A rendszertervező arra a következtetésre juthat, hogy a rendszer túlságosan függ egy központi létesítménytől, és a folyamatok egyenletesebb elosztása érdekében újra kell tervezni. Egy szekvenciadiagramban az ilyen típusú interakciót nehéz lenne látni.
10.4.5. osztálydiagramok
Az osztálydiagramok egy rendszer osztályai közötti interakciót tükrözik. Például a "joe fiókja" egy objektum. Egy ilyen objektum típusa általában véve számlának tekinthető, azaz a "Számla" egy osztály. Az osztályok olyan adatokat és viselkedéseket (műveleteket) tartalmaznak, amelyek befolyásolják ezeket az adatokat. Így a Számla osztály tartalmazza az ügyfél azonosító számát és az azt ellenőrző műveleteket. Az osztálydiagramban minden objektumtípushoz létrejön egy osztály a szekvenciadiagramokból vagy a kooperációs diagramokból. A „Pénz kivonása” használati eset osztálydiagramja az 1. ábrán látható. 10.4.
A diagram a „Pénz kivonása” használati esetet megvalósító osztályok közötti kapcsolatokat mutatja. Négy osztály vesz részt ebben a folyamatban: kártyaolvasó (kártyaolvasó), számla (számla), ATM (ATM képernyő) és pénzkiadó (pénztárgép). Az osztálydiagramon minden osztály három részre osztott téglalapként van ábrázolva. Az első rész az osztály neve, a második rész az osztály neve. attribútumokat. Az attribútum egy olyan információ, amely egy osztályt jellemzi. Például a Számla (számla) osztálynak három attribútuma van: Számlaszám (számlaszám), PIN (azonosító szám) és Egyenleg (egyenleg). Az utolsó rész az osztály azt tükröző műveleteit tartalmazza. viselkedés(az osztály által végzett tevékenységek). Az osztályokat összekötő vonalak az osztályok közötti interakciót mutatják.
Rizs. 10.4. osztálydiagram
A fejlesztők osztálydiagramokat használnak az osztályok tényleges létrehozásához. Az olyan eszközök, mint a Rose, létrehoznak egy osztálykód-alapot, amelyet a programozók kitöltenek a részletekkel a választott nyelven. Ezekkel a diagramokkal az elemzők megmutathatják a rendszer részleteit, az építészek pedig megérthetik a tervezését. Ha például egy osztály túl nagy funkcionális terhelést hordoz, ez látható lesz az osztálydiagramon, és az építész átoszthatja a többi osztály között. A diagram azon esetek azonosítására is használható, amikor a kommunikáló osztályok között nincs kapcsolat definiálva. Osztálydiagramokat kell készíteni, hogy minden használati esetben mutassák az egymással kölcsönhatásba lépő osztályokat. Készíthet általánosabb diagramokat is, amelyek lefedik az összes rendszert vagy alrendszert.
10.4.6. Állapotdiagramok
Az állapotdiagramokat arra tervezték, hogy modellezzék azokat a különféle állapotokat, amelyekben egy objektum lehet. Míg az osztálydiagram az osztályok és kapcsolataik statikus képét mutatja, addig az állapotdiagramok a rendszer viselkedésének dinamikáját írják le.
Az állapotdiagramok egy objektum viselkedését ábrázolják. Tehát egy bankszámlának több különböző állapota lehet. Lehet nyitott, zárt, vagy a rajta lévő jóváírás túlléphető. A fiók viselkedése attól függően változik, hogy milyen állapotban van. Az állapotdiagram pontosan ezt az információt mutatja. ábrán. A 10.5 egy példa egy bankszámla állapotdiagramjára.
Rizs. 10.5. A Számlaosztály állapotdiagramja
Ez a diagram bemutatja a számla lehetséges állapotait, valamint a számla egyik állapotból a másikba való átmenet folyamatát. Például, ha az ügyfél egy nyitott számla bezárását kéri, az utóbbi „Lezárt” állapotba kerül. Az ügyfél igénye ún esemény, az események okozzák az átmenetet egyik állapotból a másikba.
Amikor az ügyfél pénzt vesz fel egy nyitott számláról, a számla "túlhitelezett" állapotba kerülhet. Ez csak akkor történik meg, ha a számlaegyenleg kisebb, mint nulla, amit a feltétel [ negatív egyenleg] diagramunkon. zárójelben feltétel meghatározza, hogy az egyik állapotból a másikba való átmenet mikor következhet be vagy nem.
Az ábrán két speciális állapot található: a kezdetiÉs végső. A kezdeti állapotot fekete pont jelzi: az objektum létrehozásakori állapotának felel meg. A végső állapotot egy fehér körben lévő fekete pont jelzi: ez a tárgy közvetlenül a megsemmisülése előtti állapotának felel meg. Egy állapotdiagramnak egy és csak egy kezdeti állapota lehet. Ugyanakkor lehet, hogy annyi végső állapot van, amennyire szüksége van, vagy lehet, hogy egyáltalán nincs.
Amikor egy objektum egy adott állapotban van, bizonyos folyamatok végrehajthatók. Példánkban a jóváírás túllépése esetén egy megfelelő üzenetet küldünk az ügyfélnek. Meghívják azokat a folyamatokat, amelyek akkor fordulnak elő, amikor egy objektum egy adott állapotban van akciókat.
Állapotdiagramokat nem kell minden osztályhoz létrehozni, csak nagyon bonyolult esetekben használják. Ha egy osztályobjektum több állapotban is létezhet, és mindegyikben eltérően viselkedhet, akkor valószínűleg szüksége lenne egy ilyen diagramra. Sok projektben azonban egyáltalán nem használják őket. Ha állapotdiagramok készültek, a fejlesztők használhatják őket osztályok létrehozásakor.
Az állapottáblákra főként dokumentációs célokra van szükség.
10.4.7. Alkatrész diagramok
A komponens diagramok megmutatják, hogyan néz ki a modell fizikai szinten. A rendszer szoftverösszetevőit és a köztük lévő kapcsolatokat ábrázolja. Kétféle összetevő létezik: végrehajtható összetevők és kódkönyvtárak.
ábrán. A 10.6. ábra az ATM-rendszer egyik alkatrész-diagramját mutatja. Ez a diagram egy ATM rendszerkliens összetevőit mutatja be. Ebben az esetben a fejlesztőcsapat úgy döntött, hogy a rendszert C++ nyelven építik fel. Minden osztálynak saját fejlécfájlja és kiterjesztésfájlja van. CPP úgy, hogy minden osztályt a diagramban a saját komponenseivé alakítson át. A kiválasztott sötét komponens meghívásra kerül csomag specifikációés megfelel a C++ ATM osztály törzsfájljának (.cpp fájl). A ki nem választott összetevőt csomagspecifikációnak is nevezik, de egy C++ nyelvi osztályfejlécfájlnak felel meg (.h fájlkiterjesztés). ATM komponens. Az exe egy feladatspecifikáció, és az információfeldolgozási folyamatot képviseli. Ebben az esetben a feldolgozó szál a végrehajtható program.
Az összetevőket szaggatott vonal köti össze, amely a köztük lévő függőséget mutatja. Egy rendszernek több komponens diagramja lehet az alrendszerek számától függően, ill futtatható fájlok. Minden alrendszer komponensek csomagja.
A komponens diagramokat a projekt azon résztvevői használják, akik a rendszer összeállításáért felelősek. A komponens diagram képet ad arról, hogy milyen sorrendben kell összeállítani a komponenseket, valamint hogy a rendszer mely végrehajtható komponenseket hozza létre. A diagram az osztályok és a megvalósított komponensek megfelelőségét mutatja. Tehát ott van szükség, ahol a kódgenerálás kezdődik.
Rizs. 10.6. Alkatrész diagram
10.4.8. Elhelyezési diagramok
A helydiagramok a rendszer különböző összetevőinek fizikai elhelyezkedését mutatják a hálózaton. Példánkban az ATM-rendszer a következőkből áll egy nagy szám alrendszerek, amelyek különálló fizikai eszközökön vagy csomópontokon futnak. Az ATM-rendszer elhelyezési diagramja az ábrán látható. 10.7.
Ebből a diagramból megismerheti a rendszer fizikai elrendezését. Az ATM-kliensprogramok több helyen, különböző helyeken futnak majd. Az ügyfelek zárt hálózatokon keresztül kommunikálnak a regionális ATM szerverrel. Az ATM szerver szoftvert fogja futtatni. Viszont át helyi hálózat a regionális szerver együttműködik az Oracle-t futtató banki adatbázis-kiszolgálóval. Végül egy nyomtató csatlakozik a regionális ATM-szerverhez.
Tehát ez a diagram a rendszer fizikai elrendezését mutatja. Például ATM-rendszerünk egy háromszintű architektúrát követ, ahol az első réteg az adatbázist, a második réteg a regionális szervert, a harmadik réteg pedig a klienst tárolja.
10.7. Elhelyezési diagram
Az elrendezési diagramot a projektmenedzser, a felhasználók, a rendszertervező és az üzemeltetők használják a rendszer fizikai elrendezésének és az egyes alrendszerek elhelyezkedésének meghatározásához. A projektmenedzser elmagyarázza a felhasználóknak, hogyan fog kinézni a kész termék. Az operatív személyzet képes lesz megtervezni a rendszer telepítési munkáit.
könyvből Microsoft iroda szerző Leontyev Vitalij PetrovicsDiagramok A táblázatban szereplő számok messze nem mindig teszik lehetővé, hogy teljes benyomást keltsen, még akkor is, ha az Ön számára legkényelmesebb módon vannak rendezve. A rendelkezésre álló Microsoft Excel diagramsablonok segítségével vizuális képet kaphat a táblázat adatairól anélkül
A Computer at 100. Kezdve ezzel a könyvből Windows Vista a szerző Zozulya JurijDiagramok A diagramok táblázatos adatok grafikus formában történő bemutatására szolgálnak, amelyek jelentősen javíthatják az információk láthatóságát, bemutatják a különböző paraméterek arányát vagy változásuk dinamikáját. Eszközöket használnak diagramok beszúrására a Wordben
A Hatékony irodai munka című könyvből szerző Ptasinszkij Vlagyimir SzergejevicsGrafikonok Az Excel legszembetűnőbb tulajdonsága a számítások eredményeinek vagy a felhalmozott adatoknak a grafikonok (diagramok) formájában történő bemutatása: néha a leglenyűgözőbb számok sem képesek meggyőzni úgy, ahogy az egyszerű grafikák is képesek. Az Excel rendelkezik
Excel munkafüzetből. multimédiás tanfolyam a szerző Medinov Oleg8. fejezet Diagramok Gyakran Excel program különböző statisztikai és elemző jelentéseket bemutató dokumentumok készítésére szolgálnak. Ezek lehetnek értékesítési jelentések, levegőhőmérséklet-mérési táblázatok, szociológiai felmérések adatai stb. A számadatok nem mindig
A Word 2007 könyvből. Népszerű oktatóanyag a szerző Krainsky IDiagram készítése Az első példához létre kell hoznia az ábrán látható táblázatot. 8.1. Rizs. 8.1. Hőmérséklet mérési táblázat A táblázat adatai alapján egy egyszerű hőmérsékleti diagramot készítünk.1. Jelölje ki a kitöltött tartományt a táblázatban.2. Menj
A Computer Tutorial című könyvből szerző Kolisnichenko Denis Nikolaevich6.6. Grafikonok Kivéve grafikus fájlok, V Word dokumentumok diagramok beilleszthetők. Diagramok segítségével megjelenítheti a numerikus adatokat, például nyomon követheti az adatok változását, megtekintheti egy projekt dinamikáját. A diagramok hasonlóak
Az Object-Oriented Analysis and Design with example C++ Applications című könyvből írta Butch Gradi14.9. Diagramok Talán itt az ideje, hogy a száraz számokat grafikává alakítsuk, szebbé és informatívabbá téve táblázatunkat? Ehhez diagramokat használnak. Mondjon, amit szeretne, de a diagram jobban érzékelhető, mint a táblázat. Diagram készítéséhez ki kell választania azokat az értékeket, amelyek alapján
A Programozási technológiák című könyvből a szerző Kamaev V A5.2. Osztálydiagramok A lényeg: osztályok és kapcsolataik Az osztálydiagram az osztályokat és azok kapcsolatait mutatja be, így a projekt logikai aspektusát reprezentálja. Egyetlen osztálydiagram az osztálystruktúra egy adott nézetét képviseli. Az elemzés szakaszában mi
A Business Process Modeling with BPwin 4.0 című könyvből szerző Maklakov Szergej Vladimirovics5.4. Objektumdiagramok lényegesek: Objektumok és kapcsolataik Az objektumdiagram a meglévő objektumokat és azok kapcsolatait mutatja be a rendszer logikai tervezésében. Más szavakkal, az objektumdiagram egy pillanatkép az események folyamatáról bizonyos konfigurációkban.
Az OrCAD PSpice könyvből. Elemzés elektromos áramkörök írta Keown J.5.7. Folyamat diagramok. Alapvető: Processzorok, eszközök és kapcsolatok A folyamatdiagramok a folyamatok processzorok közötti eloszlásának bemutatására szolgálnak a rendszer fizikai tervezésében. Egy külön folyamatábra a folyamat szerkezetének egy nézetét mutatja
A VBA Book for Dummies-ből szerző Cummings Steve10.4. UML DIAGRAM 10.4.1. Vizuális diagramok típusai Az UMLUML többféle vizuális diagram létrehozását teszi lehetővé: használati eset diagramok; szekvencia diagramok; kooperatív diagramok; osztálydiagramok; állapotdiagramok; diagramok
A Macintosh bemutatója című könyvből szerző Skrylina Sofia1.2.6. Diagram keret Az 1.2.26. ábra egy tipikus példát mutat a határolókeretekkel ellátott bontási diagramra, amelyet a diagram keretének neveznek. Rizs. 1.2.26. Példa bontási diagram drótvázzal A drótváz tartalmaz egy címet ( felső rész keretek) és pince (alsó rész).
A szerző könyvébőlIdőzítési táblázatok A bemeneti és kimeneti feszültségek időzítési diagramjainak megjelenítéséhez kissé módosítani kell a bemeneti fájlt. Az előző példához hasonlóan szinuszos bemeneti feszültséget használunk: Vi 1 0 sin (0 0,5 V 5 kHz) A tranziens elemzéssel együtt
A szerző könyvébőlDiagramok és grafikonok Csak szakember láthatja a végtelen számsorok jelentését, de bárki megértheti (vagy legalábbis azt állíthatja, hogy megérti) az oszlopdiagramot vagy a kördiagramot. A VBA-nak nincsenek beépített diagramkészítő eszközei, hanem ilyenek
A szerző könyvéből5.1.14. Diagramok A diagramok egy táblázat numerikus adatainak grafikus megjelenítése. A Pages többféle diagramtípust kínál: Oszlop (oszlop), Halmozott oszlop (többszintű oszlopok), Vág (Hisztogram), Halmozott vag (többszintű hisztogram), Vonal (Lineáris), Terület (Terület), Halmozott terület (többszintű) lépcsőzetes
A szerző könyvéből5.2.8. Diagramok A diagram egy kiválasztott tartományból származó adatok grafikus megjelenítése. Diagram felépítéséhez kövesse a következő algoritmust1. Készítsen táblázatot a számított értékekről.2. Válassza ki a kívánt tartományt (ez lehet nem szomszédos téglalap alakú
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 a keresőkben, egyértelművé 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 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.
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? Egy "" nevű gráfleíró nyelvet használ pont" és ez lehetővé teszi, hogy univerzálisabb legyen, hiszen ezt a nyelvet nem csak a PlantUML használja. Sőt, mindent megtehetünk, amit alább nem csak az IDE-ben, hanem a 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?)
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)
