Az UML nyelv általános jellemzői. Egységes modellezési nyelv alapjai Uml belső szerkezeti diagram

Az UML diagram egy speciális grafikus leíró nyelv, amelyet különféle objektumok modellezésére terveztek szoftver... Ez a nyelv széles profillal rendelkezik, és egy nyílt szabvány, amely különféle változatokat használ grafikus szimbólumok a rendszer absztrakt modelljének elkészítéséhez. Az UML-t azért hozták létre, hogy mindenféle definíciót, megjelenítést, dokumentációt és tervezést biztosítson szoftverrendszerek... Érdemes megjegyezni, hogy maga az UML diagram nem programozási nyelv, de lehetőséget ad arra, hogy az alapján külön kódot állítsunk elő.

Miért van rá szükség?

Az UML nem ér véget mindenféle szoftver modellezésével. Ezenkívül ezt a nyelvet ma aktívan használják különféle üzleti folyamatok modellezésére, rendszertervezés elvégzésére, valamint a szervezeti struktúrák megjelenítésére.

Az UML használatával a szoftverfejlesztők egy teljes konvenciót érvényesíthetnek az olyan általános fogalmak ábrázolására használt grafikus jelölésekben, mint az összetevő, az általánosítás, az osztály, a viselkedés és az 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.

Osztálydiagram

Az UML osztálydiagram egy statikus szerkezeti diagram, amelyet a rendszer szerkezetének leírására, valamint attribútumok, metódusok és több különböző osztály közötti függőségek megjelenítésére terveztek.

Érdemes megjegyezni azt a tényt, hogy az ilyen diagramok felépítésével kapcsolatban számos szempont létezik, attól függően, hogy hogyan fogják őket használni:

• Fogalmi. Ebben az esetben az UML osztálydiagram egy adott tartomány modelljét írja le, és csak az alkalmazott objektumok osztályai vannak benne.
• Különleges. A diagramot különféle információs rendszerek tervezési folyamatában használják.
• Végrehajtás. Az osztálydiagram minden olyan osztályt tartalmaz, amelyet közvetlenül használ a programkód.

Alkatrész diagram

Az UML komponensdiagram egy teljesen statikus szerkezeti diagram. Célja, hogy bemutassa egy bizonyos szoftverrendszer különböző szerkezeti komponensekre való felosztását, valamint a köztük lévő kapcsolatokat. Az UML komponens diagram mint olyan mindenféle modellt, könyvtárat, fájlt, csomagot, végrehajtható fájlt és sok más elemet használhat.

Összetett / kompozit szerkezeti diagram

Az UML Composite / Composite Structure 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 található elemek kölcsönhatását is.

Altípusuk az együttműködés UML-diagramja, amely a szerepek, valamint a különböző osztályok együttműködésének határain belüli interakciójának bemutatására szolgál. Nagyon hasznosak, ha tervezési mintákat kell modelleznie.

Érdemes megjegyezni, hogy az UML osztálydiagram típusok és az összetett szerkezeti típusok egyszerre használhatók.

Beépítési diagram

Ezt a diagramot a működő csomópontok szimulálására használják, valamint a hozzájuk telepített mindenféle műterméket. Az UML 2 különböző csomópontokhoz telepíti a melléktermékeket, míg az első verzió kizárólag összetevőket. Így az UML telepítési diagramot elsősorban a második verzió használja.

Nyilvánvaló függőség jön létre a műtermék és az általa megvalósított összetevő között.

Objektum diagram

Ez a nézet lehetővé teszi, hogy egy adott időpontban teljes vagy részleges pillanatképet lásson a rendszer létrehozásáról. 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.

Csomag diagram

Ez a diagram strukturális jellegű, és fő tartalma mindenféle csomag, valamint a köztük lévő kapcsolat. Ebben az esetben nincs kemény felosztás több szerkezeti diagram között, aminek következtében használatuk leggyakrabban kizárólag kényelmi okokból történik, és semmilyen szemantikai jelentést nem hordoz. Érdemes megjegyezni, hogy a különböző elemek más UML diagramokat is szolgáltathatnak (például csomagok és maguk a csomagdiagramok).

Használatuk annak érdekében történik, hogy biztosítsák több elem csoportokba szervezését egy bizonyos kritérium szerint, a szerkezet egyszerűsítése érdekében, valamint a rendszer modelljével való munka megszervezése érdekében.

Tevékenység diagram

Az UML tevékenységdiagram egy adott tevékenység több részre bontását jeleníti meg alkatrészek... 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 a programból származó szálak egyesítenek. egy bizonyos csomópont kimenetei egy másik bemenetére.

Az UML tevékenységdiagramokat 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 szimulálnak.

Automata diagram

Ezt a nézetet UML állapotdiagramnak is nevezik. Van egy bemutatott állapotgépe egyszerű és összetett állapotokkal és átmenetekkel.

Az állapotgép olyan különböző állapotok sorozatának specifikációja, amelyeken egy bizonyos objektum áthalad, vagy interakció az életében bekövetkezett bizonyos eseményekre adott válaszként, valamint az objektum ilyen eseményekre adott válaszai. Az UML állapotdiagramot használó állapotgép a forráselemhez van csatolva, és a példányai viselkedésének meghatározására szolgál.

Az úgynevezett sárkánysémák használhatók az ilyen diagramok analógjaként.

Használjon esetdiagramokat

Az UML használati eset diagramja bemutatja a szereplők között felmerülő összes kapcsolatot, valamint a különféle használati eseteket. Fő feladata, hogy olyan teljes értékű eszközként szolgálja magát, amellyel egy ügyfél, egy végfelhasználó vagy valamilyen fejlesztő közösen megvitathatja egy adott rendszer viselkedését és funkcionalitását.

Ha egy UML használati eset diagramot használnak a rendszer modellezése során, akkor az elemző a következőket fogja tenni:

• Világosan válassza el a szimulált rendszert a környezetétől.
• Azonosítsa a szereplőket, a rendszerrel való interakciójuk módjait, valamint a rendszer várható működését.
• Állítson be a szószedetben tématerületként különböző fogalmakat, amelyek a rendszer működésének részletes leírásához kapcsolódnak.

Ha egy használati diagramot UML-ben dolgoznak ki, akkor az eljárás egy szöveges leírással kezdődik, amelyet az ügyféllel való munka során kapunk. Ugyanakkor érdemes megjegyezni, hogy a használati esetek modelljének elkészítése során a különféle nem funkcionális követelmények teljesen kimaradnak, és ezekhez már külön dokumentum készül.

Kommunikáció

A kommunikációs diagram, akárcsak az UML szekvenciadiagram, tranzitív, azaz önmagában kifejezi az interakciót, de egyben demonstrálja is. különböző utak, és ha szükséges, a kívánt pontossággal konvertálhatja egyiket a másikra.

A kommunikációs diagram bemutatja a kompozit szerkezet egyes elemei között fellépő interakciókat, valamint az együttműködés szerepeit. A fő különbség a szekvenciadiagramtó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 ingyenes formátum különbözteti meg több objektum és hivatkozás megrendelésére, ugyanúgy, mint az objektumdiagramban. Ha szükség van az üzenetek sorrendjének fenntartására ebben a szabad formátumban, akkor azok időrendi számozással vannak ellátva. Ennek a diagramnak az olvasása az eredeti 1.0-s üzenettel kezdődik, majd abban az irányban folytatódik, hogy az üzenetek az egyik objektumról a másikra kerüljenek át.

A legtöbb ilyen diagram pontosan ugyanazt az információt mutatja, mint amit a szekvenciadiagram szolgáltat számunkra, azonban mivel más módon mutatja be az információkat, az egyik diagramon bizonyos dolgok sokkal könnyebben azonosíthatók, mint a másikban. Azt is érdemes megjegyezni, hogy a kommunikációs diagramon világosabban látható, hogy az egyes elemek mely elemekkel lépnek kapcsolatba. külön elem, míg a szekvenciadiagram világosabban mutatja, hogy milyen sorrendben mennek végbe a kölcsönhatások.

Sorozat diagram

Az UML szekvenciadiagram bemutatja a több objektum közötti interakciókat, amelyek az előfordulásuk időpontja szerint vannak rendezve. Ez a diagram több objektum közötti időrendi interakciókat jeleníti meg. 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önféle objektumok jelölései, valamint az idő múlását mutató függőleges vonalak és a téglalapok, amelyek egy adott tárgy tevékenységét vagy bármely funkciójának ellátását biztosítják.

Együttműködési diagram

Az ilyen típusú diagramok lehetővé teszik több objektum közötti interakciók bemutatását, elvonatkoztatva a sugárzott üzenetek sorozatától. Az ilyen típusú diagramok kompakt formában megjelenítik egy adott objektum abszolút összes továbbított és fogadott üzenetét, valamint ezen üzenetek formátumát.

Tekintettel arra, hogy 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 diagram létrehozására egy szekvencia diagramból vagy fordítva, és ezek teljesen automatikus szinkronizálását is elvégzi.

Interakciót áttekintő diagramok

Ezek UML-diagramok, amelyek tevékenységdiagramok egy részhalmaza, amelyek sorozatelemeket és vezérlőfolyam-konstrukciókat egyaránt tartalmaznak.

Érdemes megjegyezni, hogy ez a formátum az Együttműködési és Szekvenciás diagramokat egyesíti, amelyek különböző nézőpontokból lehetőséget adnak arra, hogy a kialakítandó rendszerben több objektum közötti interakciót is megvizsgáljuk.

Szinkronizálási diagram

Ez egy alternatív szekvenciadiagram, amely világosan mutatja az állapotváltozást egy életvonalon egy adott időskálával. Nagyon hasznos lehet különféle valós idejű alkalmazásokban.

Milyen előnyökkel jár?

Érdemes megjegyezni néhány előnyt, amelyek megkülönböztetik az UML használati diagramot és másokat:

• A nyelv objektum-orientált, ennek eredményeként az elvégzett elemzés és tervezés eredményeit leíró technológiák szemantikailag közel állnak a modern típusú objektum-orientált nyelvek mindenféle programozási módszeréhez.
• Ezen a nyelven a rendszer szinte minden lehetséges nézőpontból leírható, és ugyanígy viselkedésének különböző aspektusai is leírhatók.
• Minden diagram viszonylag könnyen olvasható, még a szintaxisának viszonylag gyors megismerése után is.
• Az UML lehetővé teszi a bővítést, valamint saját grafikus és szöveges sztereotípiák bevezetését, ami hozzájárul ahhoz, hogy nem csak a szoftverfejlesztésben használják.
• A nyelv meglehetősen elterjedt, és meglehetősen aktívan fejlődik.

hátrányai

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:

• Redundancia. A kritikusok az esetek túlnyomó többségében azt mondják, hogy az UML túl nagy és összetett, és ez gyakran indokolatlan. Rengeteg redundáns vagy gyakorlatilag használhatatlan konstrukciót, diagramot tartalmaz, és leggyakrabban az ilyen kritikák a második verziót érintik, és nem az elsőt, mert az újabb változatokban több a "bizottság által kidolgozott" kompromisszum.
• Különféle szemantikai pontatlanságok. Mivel az UML-t önmagának, az angolnak és az OCL-nek a kombinációja határozza meg, hiányzik belőle az a merevség, amely a formális leírás technikája által pontosan meghatározott nyelvekben rejlik. Bizonyos helyzetekben az OCL, az UML és az angol nyelv absztrakt szintaxisa ellentmondani kezd egymásnak, más esetekben pedig hiányos. Magának a nyelvnek a pontatlan leírása egyaránt érinti a felhasználókat és az eszközszolgáltatókat, ami végső soron az eszközök inkompatibilitásához vezet a különböző specifikációk értelmezésének egyedi módja miatt.
• Problémák a megvalósítás és a tanulmányozás folyamatában. A fenti problémák mindegyike bizonyos nehézségeket okoz az UML bevezetésének és elsajátításának folyamatában, és ez különösen igaz akkor, ha a vezetés erőszakos használatára kényszeríti a mérnököket, miközben nem rendelkeznek előzetes készségekkel.
• A kód tükrözi a kódot. Egy másik vélemény, hogy nem a szép és vonzó modellek a fontosak, hanem maguk a működő rendszerek, vagyis a kód a projekt. Ezzel a nézettel összhangban szükség van egy hatékonyabb szoftverírási mód kidolgozására. Az UML-t nagyra értékelik az olyan megközelítések, amelyek modelleket fordítanak a végrehajtható vagy forráskód újragenerálására. De a valóságban ez nem biztos, hogy elég, mert a nyelvből hiányoznak a Turing teljességi tulajdonságai, és minden generált kódot végső soron korlátozni fog az, amit egy UML értelmező eszköz feltételezhet vagy definiálhat.
• Terhelési eltérés. Ez a kifejezés a rendszerelemzés elméletéből származik, annak meghatározására, hogy egy bizonyos rendszer bemenete nem képes-e érzékelni egy másik kimenetét. Mint bármelyikben szabványos rendszerek Az UML egyes rendszereket hatékonyabban és tömörebben tud ábrázolni, mint másokat. Így a fejlesztő hajlamosabb azokra a megoldásokra, amelyek kényelmesebbek az UML, valamint más programozási nyelvek minden erősségének átszövésére. Ez a probléma nyilvánvalóbb abban az esetben, ha a fejlesztési nyelv nem felel meg az objektum-orientált ortodox doktrína alapelveinek, vagyis nem próbál meg az OOP elvei szerint működni.
• Igyekszik sokoldalú lenni. Az UML egy általános célú modellező nyelv, amely igyekszik kompatibilis lenni bármely ma elérhető feldolgozó nyelvvel. Egy konkrét projekt kapcsán ahhoz, hogy a tervezőcsapat el tudja érni a végső célt, ki kell választani az adott nyelv alkalmazható képességeit. Ezenkívül az UML hatókörének korlátozásának lehetséges módjai egy adott területen olyan formalizmuson mennek keresztül, amely nem teljesen megfogalmazott, de önmagában is kritika tárgya.

Így ennek a nyelvnek a használata nem minden helyzetben releváns.

Az UML vagy Unified Modeling Language egy grafikus leíró nyelv az objektummodellezéshez a szoftverfejlesztésben. 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 megegyezésre jussanak az ábrázolandó grafikus jelölésekről általános fogalmakés a tervezésre és fejlesztésre kell koncentrálni.

UML előnyei

• Az UML grafikus szimbólumokat használ a modellezett rendszer elemeihez, és az UML diagramok elég egyszerűek ahhoz, hogy megértsék;
• Az UML lehetővé teszi a rendszerek leírását szinte minden elképzelhető nézőpontból, különböző 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 további szöveg- és grafikai típusok bevezetését teszi lehetővé, amely lehetővé teszi az UML használatát nem csak informatikai területen.

Az UML diagramok típusai

Az UML-ben 14 féle diagram létezik. 2 kategóriába sorolhatók:

• szerkezeti képviselő információs szerkezet;
• viselkedési a rendszer viselkedését és az interakciók különféle aspektusait reprezentálja. A viselkedésdiagramok külön alfaját tekintjük interakciós diagramok.

UML diagramtípus hierarchia,
osztálydiagrammal ábrázolva

Szerkezeti diagramok

1. Osztálydiagram az objektumorientált modellezés kulcseleme. Ennek a diagramnak a segítségével (sőt, keresztül osztályok, az övék attribútumok, módés az osztályok közötti függőségek) leírja a tartománymodellt és a modellezett rendszer szerkezetét.
2. Alkatrész diagram megjeleníti a programkód nagy blokkokra (strukturális komponensekre) való bontá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 modellezett rendszer egy teljes vagy részleges szeletét mutatja egy adott időpillanatban. Az osztálypéldányokat (objektumokat), azok állapotát (aktuális attribútumértékek) és a köztük lévő kapcsolatokat ábrázolja.
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 csomagokat és a köztük lévő kapcsolatokat mutatja be. Az ilyen típusú diagramok a modell szerkezetének egyszerűsítését (és ennek megfelelően a vele való munkavégzést) szolgálják azáltal, hogy a modell elemeit meghatározott kritériumok szerint csoportokba vonják.
6. Beépítési diagram szimulálja a szoftverkomponensek telepítését ( műtárgyak) a számítási erőforrásokról / hardverkomponensekről ( csomópontok).
7. Profil diagram egy kiterjesztési mechanizmust ír le, amely lehetővé teszi az UML-t számos tartományhoz és iparághoz szabni.

Példa UML osztálydiagramra

Viselkedési diagramok

1. Tevékenység diagram akciókat mutat ( akciók) ebből valamilyen tevékenység ( tevékenység). A tevékenységdiagramok üzleti folyamatok, munkafolyamatok, szekvenciális és párhuzamos számítások modellezésére szolgálnak.
2. Használati eset diagram(vagy használati eset diagram) a szereplők (karakterek) és a modellezett rendszer használati esetei (képességei) közötti kapcsolatot írja le. A diagram fő célja, hogy egyablakos ügyintézés legyen az ügyfelek, a fejlesztők és a végfelhasználók számára, ahol közösen megvitathatják 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. Ez lényegében egy állapotdiagram az atomok elméletéből.
4. Kommunikációs diagram(a korábbi verziókban 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 egyértelműen jelzi az elemek (objektumok) közötti kapcsolatot.
5. Sorozat 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 egy használati eseten belül, az általuk váltott üzenetek sorrendjét.
6. Interakció áttekintő diagramja tartalmazza a szekvenciadiagram egy részét és a vezérlőfolyamat-konstrukciókat. Segít az objektumok kölcsönhatásának különböző nézőpontokból történő átgondolásában.
7. Szinkronizálási diagram- az interakciós diagramok külön altípusa, amely az időzítésre specializálódott. Az ilyen diagramok az objektumok viselkedésének tanulmányozására szolgálnak egy bizonyos ideig.

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 számos objektum-orientált CASE termék támogatja.

Az UML szabvány a következő diagramokat kínálja a modellezéshez:

· Használati eset 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 rendszer osztályai statikus szerkezetének és a köztük lévő kapcsolatoknak a modellezésére;

Viselkedési diagramok

· Interakciós diagramok;

· Szekvenciadiagramok – szimulálják az objektumok közötti üzenetváltás folyamatát egyetlen használati eseten belül;

· Együttműködési diagram - az objektumok közötti üzenetküldési folyamat modellezésére egy használati eseten belül;

· Állapotdiagram - 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 keretében;

Megvalósítási diagramok:

Komponens diagramok - egy információs rendszer komponenseinek (alrendszereinek) hierarchiájának modellezésére;

· Kiépítési diagram – a tervezett információs rendszer fizikai architektúrájának modellezésére.

ábrán. Az 1.1 bemutatja az információs rendszer integrált modelljét, beleértve a jelen kurzusprojektben kidolgozandó alapdiagramokat.

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 használati esetet legegyszerűbb esetben úgy határozzuk meg, hogy a felhasználóval megbeszéljük azokat a funkciókat, amelyeket egy adott információs rendszerben szeretne megvalósítani. Az UML-ben a használati eset a következőképpen jelenik meg:

2. ábra. Használati eset

A szereplő a felhasználó szerepe a rendszerrel kapcsolatban. 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, a színész külsős is lehet. tájékoztatási rendszer aminek szüksége van némi információra ebből a rendszerből. Csak akkor jelenítse meg a szereplőket a 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. színész (színész)

A színészeknek három fő típusa van:

· Felhasználók;

· Rendszerek;

· Más rendszerek, amelyek kölcsönhatásba lépnek ezzel;

Az idő akkor válik szereplővé, ha attól függ, hogy a rendszerben valamilyen esemény elindul.

4.2.1. A használati 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ó,

Befoglalás (beleértve),

Kiterjesztés (kiterjesztés),

Általánosítás.

Kommunikációs link A használati eset és a szereplő közötti kapcsolat. 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

Befoglalás link olyan helyzetekre vonatkozik, amikor a rendszer viselkedése egynél több használati esetben ismétlődik. Ezeket a hivatkozásokat általában egy újrafelhasználható függvény modellezésére használják.

Kiterjesztés link 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 használatát funkcionalitás másik használati eset.

5. ábra. Példa a befogadás és a bővítés összekapcsolására

Általánosító link azt jelzi, hogy több szereplőnek vagy osztálynak vannak közös tulajdonságai.

6. ábra. Általánosítási hivatkozás példa

4.3.

Interakciós diagramokírja le az egymásra ható objektumcsoportok viselkedését. Egy interakciós diagram általában csak egy használati eseten belül fedi le az objektumok viselkedését. 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ó üzenet Egy üzenet, amely a fogadó objektumot ellátja bizonyos információkkal az állapot frissítéséhez.

Kérdő üzenet (kérdő) Olyan üzenet, amely a címzett objektumra vonatkozó információk kiadását kéri.

Kötelező üzenet Olyan üzenet, amely felkéri a címzettet, hogy tegyen valamit.

Kétféle interakciós diagram létezik: szekvenciadiagram és együttműködési diagram.

4.3.1. Szekvencia diagramok

Sorozat diagram tükrözi az események áramlását, amelyek egyetlen használati eseten belül fordulnak elő.

Az adott forgatókönyvben (használati esetben) érintett összes szereplő (szereplő, osztály vagy objektum) a diagram tetején látható. A nyilak a szereplő és egy objektum, illetve az objektumok között átadott üzeneteknek felelnek meg a szükséges funkciók végrehajtásához.

A sorozatdiagramban egy objektum téglalapként van megrajzolva, függőleges szaggatott vonallal lefelé. Ezt a vonalat hívják egy tárgy életvonala ... Egy tárgy életciklusának töredéke az interakció folyamatában.

Minden üzenet nyílként jelenik meg két objektum életvonala között. Az üzenetek az oldalon látható sorrendben jelennek meg fentről lefelé. Minden üzenet legalább az üzenet nevével van megcímkézve. Opcionálisan hozzáadhat argumentumokat és néhány vezérlő információt is. Megjelenítheti az öndelegációt – egy üzenetet, amelyet egy objektum küld magának, és az üzenetnyíl ugyanarra a mentővonalra mutat.

Rizs. 7. Példa sorozatdiagramra

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 diagram az összes információt ábrázolja, amelyet a szekvenciadiagram tartalmaz, de az együttműködési diagram másként írja le az események folyamatát. Ez megkönnyíti az objektumok közötti kapcsolatok megértését.

Az együttműködési diagramban, akárcsak a szekvencia diagramban, nyilak jelzik a kereten belül váltott üzeneteket 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 rendszer osztályainak típusait és a köztük létező különféle statikus kapcsolatokat. Az osztálydiagramok az osztályattribútumokat, az osztályműveleteket és az osztályok közötti kapcsolatokra vonatkozó megszorításokat is ábrázolják.

Az UML osztálydiagram egy gráf, melynek csomópontjai a projekt statikus struktúrájának elemei (osztályok, interfészek), az ívek pedig a csomópontok közötti kapcsolatok (asszociációk, öröklődés, függőségek).

Az osztálydiagram a következő elemeket ábrázolja:

· Csomag – egymással logikailag kapcsolódó modellelemek halmaza;

· Osztály - hasonló objektumok csoportjának általános tulajdonságainak leírása;

· Az interfész egy absztrakt osztály, amely olyan műveletek halmazát határozza meg, amelyeket az interfészhez társított tetszőleges osztály objektumai biztosítanak más objektumok számára.

4.4.2. Osztály

Osztály olyan entitások (objektumok) csoportja, amelyek hasonló tulajdonságokkal rendelkeznek, nevezetesen adatokkal és viselkedéssel. Egy osztály egyedi képviselőjét osztályobjektumnak, vagy egyszerűen objektumnak nevezzük.

Egy objektum viselkedése UML-ben minden olyan szabályt jelent, amely egy objektumnak a külvilággal és magának az objektumnak az adataival való interakciójára vonatkozik.

A diagramokon az osztályt egy téglalapként ábrázolják, szilárd szegéllyel, amelyet vízszintes vonalak 3 részre osztanak:

A felső rész (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 egyik része sem jelenik meg (és mindkettő egyszerre). Egy hiányzó szakaszhoz nem kell elvá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. Példa osztálydiagram

4.4.2.1.Osztálysztereotípiák

Az osztálysztereotípiák az osztályok kategorizálására szolgáló mechanizmusok.

Az UML-ben három fő osztálysztereotípiát határoztak meg:

Határ

Entitás

Ellenőrzés.

4.4.2.2.Határosztályok

A határosztályok olyan osztályok, amelyek a rendszer és a teljes környezet határán helyezkednek el. Ezek kijelzők, jelentések, hardverrel (például nyomtatókkal vagy szkennerekkel) való interfészek és más rendszerekkel való interfészek.

A határosztályok megtalálásához meg kell vizsgálni a használati eset diagramokat. Egy szereplő és egy használati eset közötti minden interakcióhoz legalább egy határosztálynak kell lennie. 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 a legnagyobb jelentőségűek a felhasználó számára, ezért gyakran használnak nevükben a tárgykör kifejezéseit. Á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 vezérli az adott használati eset eseménysorozatát. A vezérlő osztály felelős a koordinációért, de maga nem hordoz semmilyen funkcionalitást, mivel a többi osztály nem küld neki sok üzenetet. Ehelyett ő maga küld sok ü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őosztályok is a rendszerben, amelyek közösek a többszörös felhasználási esetekben. Például lehet egy SecurityManager osztály, amely a biztonsági események figyeléséért felelős. A TransactionManager osztály felelős az adatbázis-tranzakciókhoz kapcsolódó üzenetek koordinálásáért. 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. Ezért előfordulhat, hogy meg kell adnia, hogy mely osztályok olvashatnak és módosíthatnak attribútumokat. Ezt a tulajdonságot attribútum láthatóságnak nevezzük.

Egy attribútumnak négy lehetséges értéke lehet 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 az attribútum értékét. Az UML jelölésben a közös attribútumot egy "+" 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útumokat az UML jelölése szerint "-" jellel jelöljük.

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 Azt feltételezi adott tulajdonság gyakori, de csak a csomagján belül. 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 olyan helyzet, amikor egy attribútum értékét a rendszer minden osztálya megváltoztatja. Ehelyett az attribútum módosításának logikája ugyanabba az osztályba kerül, mint maga az attribútum. A beállított láthatósági paraméterek hatással lesznek a generált kódra.

4.4.2.6.Tevékenységek

A műveletek osztályspecifikus viselkedést valósítanak meg. Egy művelet három részből áll: név, paraméterek és visszatérési típus.

A paraméterek az "input" művelet által kapott argumentumok. A visszatérési típus a művelet műveletének eredményére vonatkozik.

Az osztálydiagramban megjelenítheti a műveletek nevét és a műveletek nevét, paramétereiket és visszatérési típusukat. A diagram leterheltségé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ípusa, 2. argumentum: 2. argumentum adattípusa, ...): Visszatérési típus

Négy különböző típusú tranzakciót kell figyelembe venni:

Végrehajtási műveletek;

Ellenőrző 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 találhatunk interakciós diagramok vizsgálatával. 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 lépésnek 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 tevékenység egy üzenetből származik egy interakciós diagramon, az üzenetek származnak Részletes leírás egy eseményfolyam, amely a használati eset alapján jön létre, az utóbbi pedig a követelmények alapján. A teljes lánc nyomon követésének képessége biztosítja, hogy minden követelmény kódban valósuljon meg, és minden kódrészlet egy követelményt valósítson meg.

Irányítási műveletek

A menedzser műveletek irányítják 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 a többi osztálytól, ugyanakkor lehetővé teszi azokhoz való ellenőrzött hozzáférést. Általános gyakorlat, hogy minden osztályattribútumhoz hozzon létre Get és Set műveleteket.

Segédműveletek

A segítő műveletek egy osztály azon műveletei, amelyekre szüksége van a kötelezettségeinek teljesítéséhez, de amelyekről a többi osztálynak nem szabad tudnia semmit. Ezek az osztály privát és védett műveletei.

A tranzakciók azonosításához kövesse az alábbi lépéseket:

1. Fedezze fel a szekvenciadiagramokat és a kooperatív diagramokat. A diagramokban szereplő üzenetek többsége megvalósítási tevékenység. A tükröződő üzenetek segédműveletek lesznek.

2. Fontolja meg a vezérlési műveleteket. Lehet, hogy hozzá kell adni konstruktorokat és destruktorokat.

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 and 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 szavakkal, ahhoz, hogy az egyik osztály szekvenciadiagramban vagy kooperatív diagramban üzenetet tudjon küldeni a másiknak, kapcsolatnak kell lennie a kettő között.

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álydiagramban közönséges vonalként vannak megrajzolva.

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ók egyszerű vonalként vannak megrajzolva nyilak nélkül, vagy nyilakkal mindkét oldalon. Az egyirányú asszociáción csak egy nyíl látható, amely az irányát mutatja.

Az asszociáció iránya a sorrenddiagramok és a kooperatív diagramok vizsgálatával határozható meg. Ha minden nekik szóló üzenetet csak egy osztály küld, és csak egy másik osztály kapja meg, de fordítva nem, akkor egyirányú kapcsolat jön létre ezen osztályok között. Ha legalább egy üzenetet küldenek a címre hátoldal, a társításnak kétirányúnak kell lennie.

Az asszociációk reflektálóak lehetnek. A reflexív asszociáció feltételezi, 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 függ a másikban készített definícióktól. Például az A osztály a B osztály metódusait használja. Amikor a B osztály megváltozik, el kell végeznie a megfelelő változtatásokat az A osztályban.

A függőség szaggatott vonalként jelenik meg két diagramelem között, és a nyíl végéhez horgonyzott elem függőnek tekinthető az adott nyíl elejéhez 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 nyilatkozatok azonban létrejönnek.

Linkösszesítés

Az aggregáció szorosabb társulási forma. Az aggregáció egy egész és annak egy része közötti kapcsolat. Például lehet egy osztálya az autónak, valamint a motornak, a gumiabroncsoknak és az autó egyéb alkatrészeinek osztályai. Ennek eredményeként az autó osztály egyik objektuma egy motor osztály objektumából, négy gumiabroncs objektumból, stb. fog állni. Az aggregációk egy rombuszos vonalként jelennek meg egy egész osztály esetében:

Rizs. 11. Kommunikációs aggregáció

Az egyszerű összesítés mellett az UML bevezeti az aggregáció erősebb formáját, az úgynevezett összetételt. A kompozíció szerint egy tárgyrész csak egyetlen egészhez tartozhat, ráadásul a részek életciklusa általában egybeesik az egész ciklusával: élnek és halnak meg vele. Az egész eltávolítása a részeire is kiterjed.

Ezt a lépcsőzetes törlést gyakran az aggregáció definíciójának részének tekintik, de mindig benne van, ha a szerepek sokasága 1...1; ha például törölni kell egy Ügyfelet, akkor ennek a törlésnek a Megrendelésekre (és viszont a Megrendelési sorokra) kell vonatkoznia.

Az UML az egységes modellezési nyelv rövidítése. Valójában ez az egyik legnépszerűbb üzleti folyamatmodellezési technika, és egy nemzetközi szabványos jelölés a szoftverfejlesztés meghatározásához, megjelenítéséhez és dokumentálásához. Az Object Management Group által meghatározott, több további UML jelölési rendszer eredményeként jött létre, és mára a vizuális modellezés de facto szabványává vált. Minden objektum-orientált programozás alapelve a modell felépítésével kezdődik.

Az UML a szoftverfejlesztés és a dokumentáció körüli káoszból jött létre. Az 1990-es években több is volt különböző utak szoftverrendszerek ábrázolásai. Szükség volt egy egységesebb vizuális UML-módszerre e rendszerek megjelenítésére, és ennek eredményeként 1994-1996-ban három, a Rational Software-nél dolgozó szoftvermérnök fejlesztette ki. Később 1997-ben szabványként fogadták el, és az is maradt, csak néhány frissítéssel.

Az UML alapvetően egy általános célú modellező nyelv a szoftverfejlesztés területén. Ez azonban ma már több üzleti vagy munkafolyamat dokumentációjában is megjelenik, például tevékenységi diagramokban. Az UML típusú diagramok a folyamatábrák helyettesítésére használhatók. Egyszerre szabványosított módot biztosítanak a munkafolyamatok modellezésére, valamint számos szolgáltatást biztosítanak az olvashatóság és a hatékonyság javítására.

Az architektúra egy meta-objektumra épül, amely meghatározza az UML létrehozásának alapját. Elég pontos egy teljes alkalmazás létrehozásához. A teljesen végrehajtható UML több platformon is telepíthető különböző technológiák használatával, a szoftverfejlesztési ciklus összes folyamatával.

Az UML célja a vizuális modellezési nyelv felhasználók általi fejlesztése. Támogatja a magas szintű tervezési koncepciókat, például struktúrákat, sablonokat és együttműködést. Az UML olyan elemek gyűjteménye, mint például:

1. Programozási nyelv utasításai.
2. Aktorok – a felhasználó vagy bármely más rendszer által játszott szerep leírása, amely interakcióba lép az objektummal.
3. A munkaszerződés teljesítéséhez elvégzendő, ábrákon bemutatott tevékenységek.
4. Üzleti folyamat, amely egy sor olyan feladatot tartalmaz, amelyek meghatározott szolgáltatást hoznak létre az ügyfelek számára, és amelyek egymást követő műveletek folyamatábrájával jeleníthetők meg.
5. Logikai és újrafelhasználható szoftverkomponensek.

Az UML diagramok két kategóriába sorolhatók. Az első típus hét diagramtípust tartalmaz, amelyek strukturális információkat jelenítenek meg, a másodikba a másik hét, amelyek általános viselkedéstípusokat képviselnek. Ezek a diagramok a rendszerek architektúrájának dokumentálására szolgálnak, és közvetlenül részt vesznek az UML rendszermodellezésben.

Az UML diagramok a rendszermodell statikus és dinamikus nézeteiként jelennek meg. A statikus nézet osztály- és összetett szerkezeti diagramokat tartalmaz, amelyek kiemelik a statikus szerkezetet. A dinamikus nézet az objektumok közötti interakciót és az objektumok belső állapotának változásait ábrázolja sorozat-, tevékenység- és állapotdiagramok segítségével.

Az UML modellezési eszközök széles választéka áll rendelkezésre a modellezés egyszerűsítésére, köztük az IBM Rose, a Rhapsody, a MagicDraw, a StarUML, az ArgoUML, az Umbrello, a BOUML, a PowerDesigner és a Dia.

Az UML-t többféleképpen használják, mind a szoftverfejlesztési dokumentációban, mind az üzleti folyamatokban:

1. Vázlat. Ebben az esetben UML diagramokat használnak a rendszer különféle szempontjainak és jellemzőinek közvetítésére. Ez azonban csak egy reprezentáció felső szint rendszer, és valószínűleg nem fogja tartalmazni az összes szükséges részletet a projekt befejezéséhez a legvégéig.
2. Forward Design – A vázlat tervezése az alkalmazás kódolása előtt történik. Ennek célja, hogy jobb áttekintést nyújtson a felhasználó által létrehozni kívánt rendszerről vagy munkafolyamatról. Számos tervezési probléma vagy hiba azonosítható, amelyek javítják a projekt általános egészségi állapotát és jólétét.
3. Fordított kivitel. A kód megírása után az UML-diagramok a különböző tevékenységek, szerepkörök, résztvevők és munkafolyamatok dokumentációjaként jelennek meg.
4. Tervrajz. Ebben az esetben a diagram teljes konstrukcióként szolgál, amelyhez csak a rendszer vagy a szoftver tényleges megvalósítása szükséges. Ez gyakran CASE (Computer Aided Software Engineering Tools) eszközökkel történik. A CASE eszközök használatának fő hátránya, hogy bizonyos szintű tudást, felhasználói képzést, valamint menedzsmentet és személyzetet igényelnek.

Az UML nem egy önálló programozási nyelv, mint például a Java, a C ++ vagy a Python, azonban megfelelő eszközökkel pszeudo UML-lé válhat. A cél eléréséhez a teljes rendszert különböző diagramokban dokumentálni kell, és a megfelelő szoftver segítségével a diagramok közvetlenül kódba fordíthatók. Ez a technika csak akkor lehet hasznos, ha a diagramok elkészítésére fordított idő kevésbé időigényes, mint a tényleges kód megírása. Bár az UML-t rendszermodellezésre hozták létre, számos felhasználási területet talált az üzleti területeken.

Az alábbiakban egy példa UML diagramot mutatunk be az üzleti modellezéshez.

Az egyik praktikus megoldás az lenne, ha tevékenységi diagramon keresztül vizualizálnánk a távértékesítés folyamatát. Attól a pillanattól kezdve, amikor a rendelést bemenetként veszik fel, egészen addig a pillanatig, amikor a rendelés elkészül és egy konkrét kimenetet adnak.

Az UML-diagramoknak többféle típusa létezik, és mindegyik más-más feladatot lát el, akár implementáció előtt, akár után, a dokumentáció részeként készült. A két legtágabb kategória, amely az összes többi típust is magában foglalja, a viselkedési diagram és a szerkezeti diagram. Ahogy a neve is sugallja, egyes UML diagramok egy rendszer vagy folyamat szerkezetét próbálják elemezni és ábrázolni, míg mások egy rendszer viselkedését, résztvevőit és összetevőit írják le.

A különböző típusok a következőképpen oszlanak meg:

1. A 14 különböző típusú UML diagram közül nem mindegyiket használják rendszeresen a rendszerek és architektúrák dokumentálásakor.
2. A Pareto-elv az UML diagramok használatára is vonatkozik.
3. A diagramok 20%-át az esetek 80%-ában a fejlesztők használják.

A szoftverfejlesztés leggyakrabban használt elemei a következők:

• használati diagramok;
• osztálydiagramok;
• sorrend.

A műveleti diagramok a legfontosabb UML diagramok az üzleti folyamatmodellek létrehozásához. A szoftverfejlesztés során a különböző műveletek folyamatának leírására szolgálnak. Lehetnek szekvenciálisak vagy párhuzamosak. Leírják a tevékenységek eredményeként használt, fogyasztott vagy előállított tárgyakat és a különböző tevékenységek közötti kapcsolatot.

A fentiek mindegyike fontos az egyiktől a másikhoz vezető üzleti folyamatok modellezéséhez, mivel világos kezdettel és véggel kapcsolódnak egymáshoz. Üzleti környezetben ezt üzleti folyamatleképezésnek is nevezik. A főszereplők a szerző, a szerkesztő és a kiadó. Az UML példái a következők. Amikor egy bíráló áttekinti a tervezetet, és úgy dönt, hogy néhány változtatást kell végrehajtani. A szerző ezt követően felülvizsgálja a tervezetet, és ismét visszaküldi, hogy elemezze az áttekintést.

Használati diagram

A rendszer sarokköve - a rendszer szintjére vonatkozó követelmények elemzésére szolgál. Ezek a követelmények különböző felhasználási esetekben vannak kifejezve. Az UML diagram három fő összetevője:

1. Funkcionális – használati esetként bemutatva.
2. Egy cselekvést leíró ige.
3. Szereplők – a rendszerrel való interakcióhoz. A szereplő lehet felhasználók, szervezetek vagy külső alkalmazás. A résztvevők közötti kapcsolatot egyenes nyilak ábrázolják.

Például egy készletellenőrzési diagramhoz. Ebben az esetben van tulajdonos, szállító, vezető, leltározási szakember és leltárellenőr. A kerek konténerek a szereplők által végrehajtott műveleteket jelzik. Lehetséges műveletek: készletek vásárlása és fizetése, a készletek minőségének ellenőrzése, készletek visszaküldése vagy forgalmazása.

Ez a fajta diagram kiválóan alkalmas a rendszer résztvevői közötti dinamikus viselkedés megjelenítésére, egyszerűsítve annak bemutatását anélkül, hogy tükrözné a megvalósítás részleteit.

Ideiglenes

Az UML időzítési diagramok az objektumkapcsolatok ábrázolására szolgálnak, amikor a fókusz időfüggő. Ugyanakkor nem az az érdekes, hogy az objektumok hogyan hatnak egymásra, vagy hogyan változtatják egymást, hanem a felhasználó el akarja képzelni, hogyan viselkednek a tárgyak és az alanyok egy lineáris időtengely mentén.

Minden egyes résztvevő egy életvonalon keresztül képviselteti magát, amely lényegében a szakaszokat alkotó vonal, ahogy az egyéni résztvevő egyik szakaszról a másikra halad. A hangsúly az események időtartamán és az attól függően bekövetkező változásokon van.

Az idődiagram fő összetevői a következők:

1. A Lifeline egyéni tag.
2. Állapot idővonala – Egyetlen életút különböző állapotokon mehet keresztül egy folyamaton belül.
3. Időtartam-megkötés – Időintervallum-megkötés, amely a megkötés teljesítéséhez szükséges időtartamot jelöli.
4. Időkorlát – korlátozza azt az időtartamot, amely alatt a résztvevőnek valamit meg kell tennie.
5. Megsemmisítési megjelenés – Olyan üzenet megjelenése, amely megsemmisíti az egyéni résztvevőt, és a résztvevő életciklusának végét ábrázolja.

A vízszintes diagramok, más néven állapotdiagramok, a rendszeren belüli összetevők különböző állapotainak leírására szolgálnak. Végső névformátumot vesz igénybe, mivel a diagram lényegében egy olyan gép, amely leírja egy objektum több állapotát, és azt, hogyan változik a belső és külső események alapján.

Egy nagyon egyszerű gépállapot-diagram lenne egy sakkjátszmában. Egy tipikus sakkjáték fehér és fekete lépésekből áll. Fehéré az első lépés, ami így elindítja a játékot. A játék vége akkor is bekövetkezhet, ha a fehér vagy a fekete nyer. A játék vége lehet meccsnek, lemondásnak vagy döntetlennek (eltérő gépi feltételek). Az állapotdiagramokat főként különböző rendszerek előre és fordított UML tervezésében használják.

Egymást követő

Ez a fajta diagram a legfontosabb UML diagram nem csak a számítástechnikai közösség körében, hanem az üzleti alkalmazások fejlesztésének tervezési rétegmodelljeként is. Vizuálisan magától értetődő jellegük miatt népszerűek üzleti folyamatok leírására. Ahogy a név is sugallja, a diagramok az alanyok és objektumok közötti üzenetek és interakciók sorrendjét írják le. A szereplők vagy objektumok csak akkor lehetnek aktívak, ha szükséges, vagy ha egy másik objektum kommunikálni akar velük. Minden közlemény időrendi sorrendben kerül bemutatásra.

További információkért tekintse meg az alábbi példa UML szekvenciadiagramot.

Amint a példa mutatja, a szerkezeti diagramok a rendszer felépítését mutatják be. Pontosabban, egy nyelvet a szoftverfejlesztésben használnak a rendszer architektúrájának és a különböző összetevők összekapcsolásának bemutatására.

Az UML osztálydiagram a szoftverdokumentáció leggyakoribb diagramtípusa. Mivel a legtöbb jelenleg írt program még mindig az objektum-orientált programozási paradigmán alapul, ésszerű az osztálydiagramok használata a szoftverek dokumentálására. Ennek az az oka, hogy az OOP az UML osztályokon és a köztük lévő kapcsolatokon alapul. Dióhéjban a diagramok osztályokat tartalmaznak, attribútumaikkal együtt, amelyeket adatmezőknek is neveznek, és viselkedésüket, amelyeket tagfüggvényeknek neveznek.

Pontosabban, minden osztálynak 3 mezője van: név felül, attribútumok közvetlenül a név alatt, műveletek / viselkedés alul. A különböző osztályok közötti kapcsolat (amelyet az összekötő vonal jelöl) osztálydiagramot alkot. A fenti példa egy alapvető osztálydiagramot mutat be.

Objektumok

Amikor az UML szerkezeti diagramjairól beszélünk, mélyebbre kell ásni a számítástechnikai fogalmakat. A szoftverfejlesztésben az osztályokat absztrakt adattípusoknak, míg az objektumokat példányoknak tekintjük. Például, ha létezik „Car”, ami egy általános absztrakt típus, akkor az „Car” osztály példánya az „Audi”.

Az UML objektumdiagramok segítségével a szoftverfejlesztők ellenőrizhetik, hogy a generált absztrakt struktúra működőképes struktúrát hoz-e létre a gyakorlati megvalósítás során, vagyis amikor objektumokat készítenek. Egyes fejlesztők ezt a pontosság-ellenőrzés másodlagos szintjének tekintik. Megjeleníti az osztályok példányait. Pontosabban, a „Customer” általános osztálynak van egy tényleges vásárlója, például „James”. James egy általánosabb osztály példánya, és ugyanazokkal az attribútumokkal rendelkezik, mint a adott értékeket... Ugyanez történt a Számlák és Takarékszámlával is. Mindkettő a saját osztályának tárgya.

Telepítés

A telepítési diagramok a szoftver és a hardver közötti kapcsolat megjelenítésére szolgálnak. Pontosabban, a telepítési diagramokkal fizikai modellt készíthet arról, hogy a szoftverösszetevők (műtermékek) hogyan kerülnek telepítésre a csomópontoknak nevezett hardverösszetevőkre.

A webalkalmazások tipikus egyszerűsített telepítési mintája a következőket tartalmazza:

1. Csomópontok (alkalmazáskiszolgáló és adatbázis-kiszolgáló).
2. Műtermékek az ügyfélalkalmazás sémája és adatbázisa.

A csomagdiagram hasonló a fent ismertetett UML-telepítési diagramok makróihoz. A különféle csomagok csomópontokat és műtermékeket tartalmaznak. A diagramokat és a modellkomponenseket csoportokba csoportosítják, hasonlóan ahhoz, ahogy egy névtér különböző neveket foglal magában, amelyek némileg kapcsolódnak egymáshoz. Végső soron több más csomag is létrehozhat egy csomagot, amelyek bonyolultabb rendszereket és viselkedést képviselnek.

A csomagdiagram fő célja, hogy bemutassa az összetett rendszert alkotó főbb összetevők közötti kapcsolatokat. A programozók megtalálják ezt az absztrakciós lehetőséget jó előny csomagdiagramok használatához, különösen akkor, ha egyes részletek kimaradhatnak a képből.

Mint minden más dologhoz az életben, ahhoz, hogy valamit jól csináljunk, megfelelő eszközökre van szükség. Szoftverek, folyamatok vagy rendszerek dokumentálásához használjon UML megjegyzéseket és diagramsablonokat kínáló eszközöket. Különféle szoftverdokumentációs eszközök állnak rendelkezésre, amelyek segíthetnek diagram rajzolásában.

Általában a következő fő kategóriákba sorolhatók:

1. A papír és a toll egyszerű. Papírt és tollat ​​vesznek, megnyitják az UML szintaktikai kódot az internetről, és bármilyen típusú diagramot rajzolnak, amelyre szükség van.
2. Online eszközök – Számos online alkalmazás létezik, amelyek segítségével létrehozhatja diagramját. A legtöbbjük kínál fizetett előfizetés vagy korlátozott számú diagram szabad szinten.
3. Az ingyenes online eszközök szinte ugyanazok, mint a fizetős eszközök. A fő különbség az, hogy a fizetősek is kínálnak oktatóanyagokatés kész sablonok konkrét diagramokhoz.
4. Az asztali alkalmazás egy tipikus asztali alkalmazás diagramokhoz, és szinte minden más diagram a Microsoft Visio. Speciális funkciókat és funkciókat kínál. Az egyetlen hátránya, hogy fizetni kell érte.

Így teljesen világos, hogy az UML fontos szempont az objektum-orientált szoftverek fejlesztésében. Grafikus jelöléseket használ a rendszerprogramok vizuális modelljének létrehozásához.

Az UML egy általános célú grafikus modellező nyelv a szoftverrendszerek fejlesztése során létrejött összes műtermék meghatározására, megjelenítésére, tervezésére és dokumentálására.

Sok jó könyv van, ami részletesen leírja az UML-t (néhol még nagyon részletesen is), szeretném egy helyre összegyűjteni az alapfogalmakat 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. Unified Modeling Language UMLés Leonenkov. UML oktatóanyag.

Először is döntsünk a szerkesztőről. Linux alatt különböző UML szerkesztőket próbálgattam, leginkább az UMLet tetszett, bár Java-ban van írva, nagyon gyorsan mozog és a legtöbb entitássablon is benne van. Van még ArgoUML, egy többplatformos UML-szerkesztő, szintén Java nyelven íródott, funkcionálisan gazdag, de jobban lassít.

elhelyezkedtem UMLet, állítsa be alá Arch Linuxés Ubuntu:

# Arch Linuxhoz yaourt -S umlet # Ubuntuhoz sudo apt-get install umlet

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

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

Az UML-ben négy fő kapcsolattípust használnak:

Függőség- azt jelzi, hogy a független entitás megváltoztatása valamilyen módon hatással van a függő entitásra. Grafikusan a függőségi viszonyt 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). Az asszociáció grafikusan egy folytonos vonalként van ábrázolva, a kapcsolódó entitásokat összekötő 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 speciális (specializált) esete. Grafikusan az általánosítás egy vonalként van ábrázolva, amelynek végén egy háromszög alakú, árnyékolatlan nyíl van, amely a konkréttól (alosztálytól) az általános felé (szuperosztály) irányul.

Végrehajtás- a megvalósítási reláció azt jelzi, hogy az egyik entitás egy másik megvalósítása. Grafikailag az implementációt szaggatott vonalként ábrázoljuk, a végén egy háromszög alakú, árnyékolatlan nyíllal, amely a megvalósító entitástól a megvalósítható felé irányul.

V UML 2 van meghatározva 13 típusú diagramok. Szabvány szerint minden diagramnak a bal felső sarokban kell lennie egy téglalappal (jobb alsó sarok ferde), amely jelzi 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 (tag összetevő);
• Beépítési diagram (címke bevetése);
• Osztálydiagram (osztálydiagram, címke osztály);
• Objektum diagram (tag tárgy);
• Belső szerkezeti diagram (összetett szerkezeti diagram, címke osztály);

Diagramok a rendszer viselkedésének ábrázolására:

• Interakciós diagram (tag időzítés);
• Tevékenység diagram (címke tevékenység);
• Sorozatdiagram (címke SD);
• Kommunikációs diagram (címke comm);
• Állapotgép diagram (címke állapotgép);
• Interakció áttekintése diagram címke kölcsönhatás);

A diagramok különböznek egymástól:

• Használati diagram (használati eset diagram, használati eset címke);
• 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 modellel 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.

Társulási kapcsolat- Ez a kapcsolat határozza meg, hogy egy szereplő milyen konkrét szerepet játszik, amikor egy használati esettel kommunikál. Az asszociációs kapcsolatot a szereplő és a használati eset közötti folyamatos vonal jelzi. Ez a sor tartalmazhat további legenda, mint például a név és a kardinalitás.

Tágulási arány- meghatározza, hogy egy adott használati eset példányai hogyan kapcsolódnak egy általánosabb használati esethez, amelynek tulajdonságait az alapján határozzák meg, hogy ezek a példányok hogyan kombinálódnak egymással. Tehát, 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 példányának tulajdonságai kibővíthetők az A kiterjesztett használati eset tulajdonságai 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ó jelzi azt a tényt, hogy egy bizonyos A használati eset általánosítható B használati esetre. Ebben az esetben az A lehetőség a B lehetőség specializációja lesz. Ebben az esetben B-t ősnek vagy szülőnek nevezzük A-val kapcsolatban, és Az A lehetőség leszármazottja az V opció használatához képest.

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

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 arány két használati eset között azt jelzi, hogy az egyik használati eset bizonyos viselkedése összetett összetevőként szerepel a másik használati eset viselkedési sorozatában.

Az A használati esettől a B használati esetig tartó felvételi kapcsolat azt jelzi, hogy az A lehetőség minden példánya tartalmazza a B opcióhoz meghatározott funkciókat.

Grafikusan ezt a kapcsolatot egy szaggatott vonal jelöli nyíllal (függőségi kapcsolat esete), amely az alap használati esettől a benne foglalt használati esetre mutat.

Osztálydiagram

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

Az osztálydiagramon az entitások egy fő típusát használjuk: az 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ő alapvető kapcsolatok jönnek létre: függőségek, asszociációk, általánosítások. , megvalósítások.

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 a modell egyik elemében bekövetkezett változás a modell egy másik függő elemének 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égi kliens osztálytó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útumainak és műveleteinek 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 megjelenik további információ miközben egy projekten dolgozik.

Társulási kapcsolat az osztályok közötti valamilyen kapcsolat meglétének felel meg. Ezt a kapcsolatot egy folytonos vonal jelöli további speciális karakterekkel, 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 megjelölésének választható eleme.

Összesítési arány több osztály között zajlik, abban az esetben, ha az egyik osztály egy bizonyos entitás, amely más entitásokat is tartalmaz alkotórészként. A rész-egész 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 sajátos formáját kívánja kiemelni, amelyben az alkotó részek bizonyos értelemben az egészben 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, vagyis az egész megsemmisülésével minden alkotórésze megsemmisül.

Általánosítási reláció egy általánosabb elem (szülő vagy ős) és egy privátabb vagy különlegesebb elem (gyermek vagy leszármazott) közötti kapcsolat. Osztálydiagramra alkalmazva ez a kapcsolat az osztályok hierarchikus struktúrájá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, valamint megvannak a maga tulajdonságai és viselkedése, amivel az ősosztály nem rendelkezik.

Automata diagram

Automata diagram(állapotgép diagram) ill állapotdiagram Az UML 1-ben (állapotdiagram diagram) az UML viselkedésének részletes leírásának egyik módja. Lényegében az automata diagramok, ahogy a neve is sugallja, egy véges automata állapotainak és átmeneteinek grafikonja, amely számos további részlettel és részlettel van feltöltve.

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ánya állapotának megváltoztatását, vagyis modellezi egy adott objektum állapotának összes lehetséges változását. Ebben az esetben egy objektum á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 diagramon 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 jelölések vannak meghatározva. Az automata a modellezett 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 egy olyan állapot speciális esete, amely nem tartalmaz belső cselekvéseket (pszeudoállapotokat). Az alapértelmezett objektum ebben az állapotban van a kezdeti pillanatban. Arra szolgál, hogy az állapotdiagramon jelezze azt a grafikus területet, ahonnan az állapotátmeneti folyamat elindul.

Döntő (döntő) az állapot egy olyan állapot speciális esete, amely szintén nem tartalmaz belső cselekvéseket (pszeudoállapotokat). Az alapértelmezett objektum ebben az állapotban lesz, miután az automata az utolsó pillanatban befejezi munkáját.

Tevékenység diagram

Egy megtervezett vagy elemzett rendszer viselkedésének modellezésekor nemcsak állapotváltozási folyamatának ábrázolá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 az 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 sajátosságainak 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). Használnak olyan szerkezeteket is, mint a villák, egyesítések, csatlakozások, elágazások. Névként ajánlott egyszerű művelet használjon igét magyarázó szavakkal.

Sorozat diagram

Sorozat diagram(szekvenciadiagram) a rendszer viselkedésének leírása "példákkal".

Valójában a szekvenciadiagram a rendszerműködés egy adott munkamenetének protokolljának rekordja (vagy egy ilyen protokoll töredéke). Az objektum-orientált programozásban a leglényegesebb futási idő az üzenetek átvitele a kommunikáló 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 - azokat a hivatkozásokat, amelyeken keresztül üzenetek cserélődnek.

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 egymással kölcsönhatásban lévő osztályozópéldányok üzenetcsere-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 - linkeket. Itt azonban nem az időn van a hangsúly, hanem az egyes 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 komponensdiagramban szereplő entitások fő típusai maguk a komponensek, valamint azok az interfészek, amelyeken keresztül a komponensek közötti kapcsolat látható. Az alkatrészdiagramban a következő összefüggések érvényesek:

• komponensek és interfészek közötti implementációk (egy komponens interfészt valósít meg);
• 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), valamint a rendszerelemek összetételének és kapcsolatainak megjelenítése megmutatja, hogyan helyezkednek el fizikailag a számítási erőforrásokon futás közben.

Az elhelyezési diagramban a komponens diagramhoz képest kétféle entitást adunk hozzá: egy műterméket, amely egy komponens és egy csomópont megvalósítása (lehet egy csomópont típusát leíró osztályozó, 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 futásidőben.

Objektum diagram

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

Az objektumdiagramon 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édjellegűek – valójában példák (mondhatnánk, memória dumpok), amelyek megmutatják, hogy a rendszer működésének egy adott pillanatában milyen objektumok és milyen kapcsolatok vannak közöttük.

Belső szerkezeti diagram(ö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 van ábrázolva, melynek felső részén az osztályozó neve található. Belül vannak az alkatrészek. Több rész is lehet. Az alkatrészek kölcsönhatásba léphetnek egymással. Ezt különféle 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ő szélén találhatók.

Interakció áttekintő diagramja Az interakciós áttekintési diagram egy kiterjesztett szintaxisú tevékenységdiagram: a szekvenciadiagramok által meghatározott interakcióhasználati hivatkozások egy interakciós áttekintési diagram elemeiként működhetnek.

Szinkronizálási diagram

Szinkronizálá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 és időzítésének megváltoztatá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) talán 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 tartomány 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 lehetőség nyílik a kulcsfontosságú entitások kiemelésére és az ezen entitások között kialakítható kapcsolatok kijelölésére. wikipédia

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

Alapfogalmak:

A lényeg(entitás) olyan entitás, amely valamilyen módon azonosítható, ami megkülönbözteti például más entitásoktól Ü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 társulás.

Tartomány(domain) - egy attribútum értékeinek halmaza (hatóköre).

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 alapvető UML-fogalmak szószedete

Tárgy- olyan entitás, amely egyedi, és magában foglalja az állapotot és a viselkedést.

Osztály- olyan objektumok halmazának leírása, amelyek közös attribútumai meghatározzák az állapotot és a viselkedést meghatározó műveleteket.

Felület- a fogyasztó által igényelhető és a szolgáltató által nyújtott szolgáltatások halmazát meghatározó nevesített műveletsor.

Együttműködés- objektumok halmaza, amelyek kölcsönhatásba lépnek egy 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 szoftverfejlesztés során felhasznált vagy generált információ. 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 összetevőből) származik.

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

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 atomszámítás.

Gép egy olyan csomag, amely meghatározza a modellezett entitás viselkedésének ábrázolásához szükséges fogalmak halmazát egy véges számú állapottal és átmenettel rendelkező diszkrét tér formájában.

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

Kiegészítő olvasmány

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