Mi az 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. Ami fontos, az az, hogy az UML így fordítja Egységes modellezési nyelv. Az Egységes szó itt fontos. Vagyis képeinket nem csak mi értjük meg, hanem mások is, akik ismerik az UML-t. Kiderült, hogy ez egy olyan nemzetközi nyelv a diagramok rajzolásához.
Ahogy a Wikipédia írja
Az UML egy grafikus leíró nyelv objektummodellezéshez a szoftverfejlesztés, az üzleti folyamatok modellezése, a rendszertervezés és a szervezeti struktúrák feltérképezése területén.A legérdekesebb dolog, amelyre nem mindenki gondol vagy sejt, az az, hogy az UML-nek vannak specifikációi. Sőt, még UML2 specifikáció is létezik. A specifikációról további információ az Object Management Group honlapján található. Valójában ez a csoport az UML specifikációk fejlesztésével foglalkozik. Az is érdekes, hogy az UML nem korlátozódik az osztályok szerkezetének leírására. Sokféle UML diagram létezik. Az UML diagramok típusainak rövid leírása ugyanabban a Wikipédiában: UML diagramok vagy Timur Batyrshinov videójában látható 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 igencsak hasznos készség.
Alkalmazás
Lássuk, hogyan tud dolgozni ezzel az UML-lel az IDE-ből. IDE-ként vegye fel IntelliJ ötlet. Ha használja IntelliJ Idea Ultimate, akkor a beépülő modult „dobozból” telepítjük. UML támogatás". Lehetővé teszi gyönyörű osztálydiagramok automatikus generálását. Például a Ctrl + N billentyűkombinációval vagy a "Navigáció" -> "Osztály" menüponttal lépjen az osztályra Tömb lista. Most az osztálynév melletti helyi menüben válassza a "Diagram" -> "Show diagram popup" lehetőséget. Ennek eredményeként egy gyönyörű diagramot kapunk:
De mi van akkor, ha saját magát szeretné lerajzolni, és még az Idea végső verziója sem létezik? 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 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? "" nevű gráfleíró nyelvet használ pont" és ez lehetővé teszi, hogy univerzálisabb legyen, mert ezt a nyelvet nem csak a PlantUML használja. Sőt, mindaz, amit alább meg fogunk tenni, nem csak az IDE-ben, hanem a planttext.com online szolgáltatásban is megtehető. A telepítés után a PlantUML bővítmény, a „Fájl" -> „Új" menüponton keresztül tudunk majd UML diagramokat készíteni. Készítsünk „UML osztály" típusú diagramot. Ezalatt automatikusan létrejön egy sablon egy példával. Töröljük a tartalmát, ill. hozzuk létre a sajátunkat, felvértezve egy cikkel a Habr: Class Relations - 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 a kezdetektől fogva van egy jel a kapcsolatok leírására:
Magukról a kapcsolatokról még itt olvashatunk: "Osztályok közötti kapcsolatok UML-ben. Példák". Ezen anyagok alapján kezdjük el elkészíteni az UML diagramunkat. Adja hozzá a következő, a két osztályt leíró tartalmat: @startuml osztály ArrayList ( ) osztály LinkedList ( ) @enduml Az eredmény megtekintéséhez az Idea programban válassza a "Nézet" -> "Eszközablakok" -> "PlantUML" lehetőséget. Csak két osztályt jelölő négyzetet kapunk. Mint tudjuk, mindkét osztály megvalósítja a Lista felületet. Az osztályok ezt a relációját - megvalósításnak (realizációnak) nevezik. Az ilyen kapcsolat ábrázolására egy pontozott vonallal ellátott nyíl szolgál. Rajzoljuk meg: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о csomag privát elem tömb: ~ Object elementData Most szeretnénk megmutatni, hogy az ArrayList tartalmaz néhány objektumot. 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, vagyis valaminek, ami 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 meghagyható. Például eladni vagy behelyezni egy másik egységet. Tehát benne van 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 szeretnénk bemutatni, hogy az ArrayList -vel ellentétben a LinkedList osztály Csomópont 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, egy új csomópontot adunk hozzá, amely tartalmaz egy hivatkozást ehhez a sorhoz, valamint egy hivatkozást az előző és a következő csomóponthoz. 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 folyamatos vonal vezet. Most írjuk ezt a hivatkozás szöveges megjelenítéseként: class Node ( ) LinkedList * -- Node És most meg kell tanulnunk egy másik fontos hivatkozástípus megjelenítését - függőség(függőségi kapcsolat). Akkor használatos, ha az egyik osztály egy másikat használ, miközben 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éma rajzolásában, és amikor a feladatain dolgozik, gyorsan megrajzolhatja kézzel. Ez fejleszti az alkalmazásarchitektúra gondolkodási készségeit, és segít korán felismerni az osztályszerkezeti hibákat, nem pedig azután, hogy már egy napot töltött a rossz modell megvalósításával. Szerintem ez jó ok arra, hogy kipróbáljam?)
Automatizálás
A PlantUML diagramok automatikus generálására különféle módok állnak rendelkezésre. Például be ötleteket Van egy SketchIT bővítmény, de nem rajzolja meg őket megfelelően. Például az interfészek megvalósítása helytelenül van megrajzolva (öröklődésként jelenik meg). Vannak online példák is arra, hogyan építheted be ezt a projekted életciklusába. Mondjuk azért Maven van egy példa az uml-java-docklet használatára. Ennek bemutatásához használjuk a Maven archetípust egy Maven projekt gyors létrehozásához. Hajtsuk végre a következő parancsot: mvn archetype:generate Szűrőválasztás kérdésére ( Válasszon egy számot, vagy alkalmazzon szűrőt) hagyja el az alapértelmezett beállítást az Enter megnyomásával. mindig az lesz" maven-archetype-quickstart". Kiválasztjuk a legújabb verziót. Ezután válaszoljon a kérdésekre, és fejezze be a projekt létrehozását:
Mivel ez a cikk nem a Maven áll a középpontjában, a Mavennel kapcsolatos kérdéseire a Maven Felhasználói Központban 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ési 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ó tól től " info.leadinglight"a" com.chfourie"és tedd be a verziót" 1.0.0 Ezt követően a fájlt tartalmazó könyvtárban tudjuk végrehajtani pom.xml ezek a parancsok: mvn clean install és mvn javadoc:javadoc . Most, ha megnyitjuk a generált dokumentációt (explorer target\site\apidocs\index.html), UML diagramokat fogunk látni. Egyébként itt már helyesen megjelenik a megvalósítás)
Következtetés
Mint látható, az UML lehetővé teszi az alkalmazás szerkezetének megjelenítését. Ezenkívül az UML nem korlátozódik erre. Az UML segítségével leírhat különféle folyamatokat a vállalaton belül, vagy leírhatja azt az üzleti folyamatot, amelyen belül az Ön által írt funkció működik. Ön dönti el, hogy az UML mennyire hasznos Önnek személyesen, de az idő megtalálása és a részletesebb megismerése mindenképpen hasznos lesz. #Viacheslav A bejegyzés orosz verziója: UML diagram Java a CodeGym-enMegjegyzés: Ennek a kurzusnak a témája az UML – Egységes modellező nyelv. Az előző előadásban beszéltünk arról, hogy mi is az UML, annak történetéről, céljáról, a nyelvhasználat módjairól, definíciójának felépítéséről, terminológiájáról és jelöléséről. Megjegyezték, hogy az UML-modell diagramok halmaza. Ebben az előadásban a következő kérdéseket fogjuk megvizsgálni: miért van szükségünk többféle diagramra; diagramok típusai; OOP és sorozatdiagramozás
Mielőtt rátérnénk az előadás fő anyagának tárgyalására, beszéljünk arról, hogy miért kell egyáltalán diagramokat készíteni. Bármely rendszer (nem csak szoftver) modelljének kidolgozása mindig megelőzi annak létrehozását vagy frissítését. Erre legalább azért van szükség, hogy tisztábban képzeljük el a probléma megoldását. Az átgondolt modellek nagyon fontosak mind a fejlesztőcsapaton belüli interakcióban, mind az ügyféllel való kölcsönös megértésben. Végtére is, lehetővé teszi, hogy megbizonyosodjon arról, hogy a projekt "architekturálisan konzisztens", mielőtt kódban implementálná.
Összetett rendszerek modelljeit építjük fel, mert nem tudjuk őket teljesen leírni, "egy pillantással megnézni". Ezért a rendszernek csak azokat a tulajdonságait emeljük ki, amelyek egy adott feladathoz elengedhetetlenek, és építjük fel a modelljét, amely ezeket a tulajdonságokat tükrözi. Az objektum-orientált elemzés módszere teszi lehetővé a valós komplex rendszerek legmegfelelőbb leírását. De ahogy a rendszerek egyre bonyolultabbá válnak, szükség van jó szimulációs technológiára. Ahogy az előző előadásban is elmondtuk, ilyen „standard” technológiaként egy egységes rendszert használnak. modellező nyelv(Unified Modeling Language, UML), amely egy grafikus nyelv a rendszerek specifikálására, megjelenítésére, tervezésére és dokumentálására. Az UML segítségével részletes modellt készíthet a készülő rendszerről, amely nemcsak a koncepcióját, hanem a konkrét megvalósítási jellemzőket is tükrözi. Az UML modell keretein belül a rendszerrel kapcsolatos összes reprezentációt speciális grafikus struktúrák, úgynevezett diagramok formájában rögzítik.
jegyzet. Nem fogunk minden diagramtípust figyelembe venni, csak néhány típust. Például ebben az előadásban nem foglalkozunk a komponens diagrammal, amely csak egy rövid áttekintést nyújt a diagramtípusokról. Egy adott alkalmazásmodellhez tartozó diagramtípusok száma semmilyen módon nincs korlátozva. Egyszerű alkalmazásokhoz nincs szükség kivétel nélkül minden típusú diagram elkészítésére. Néhány közülük egyszerűen hiányzik, és ez a tény nem tekinthető hibának. Fontos megérteni, hogy egy bizonyos típusú diagramok elérhetősége az adott projekt sajátosságaitól függ. A többi (itt nem tárgyalt) diagramtípusról az UML szabványban találhatók információk.
Miért van szüksége többféle diagramra?
Először is határozzuk meg a terminológiát. Az előadás előszavában többször használtuk a rendszer, a modell és a diagram fogalmát. A szerző biztos abban, hogy mindannyian intuitív módon megértjük e fogalmak jelentését, de a teljes világosság érdekében nézzük meg újra a szószedet, és olvassuk el a következőket:
Rendszer- egymással összefüggő vezérelt alrendszerek összessége, amelyeket a működés közös célja egyesít.
Igen, nem túl informatív. Mi akkor az alrendszer? A helyzet tisztázása érdekében forduljunk a klasszikusokhoz:
rendszer egy adott cél elérése érdekében szervezett alrendszerek halmazát hívja meg, és modellkészlet segítségével írja le, esetleg különböző nézőpontokból.
Hát nem lehet mit tenni, meg kell keresni egy alrendszer definícióját. Ott is ezt írják alrendszer olyan elemek halmaza, amelyek egy része más elemek viselkedését határozza meg. Ian Sommerville így magyarázza a koncepciót:
Alrendszer olyan rendszer, amelynek működése nem függ más alrendszerek szolgáltatásaitól. A szoftverrendszer viszonylag független alrendszerek halmazaként épül fel. Az alrendszerek közötti kölcsönhatásokat is meghatározzák.
Szintén nem túl világos, de jobb. „Emberi” nyelven szólva a rendszer egyszerűbb, viszonylag önellátó entitások halmazaként jelenik meg. Ezt össze lehet hasonlítani azzal, ahogy egy program fejlesztése során szabványos "kockákból" - vizuális komponensekből - grafikus felületet építünk, vagy ahogy maga a programszöveg is fel van osztva olyan modulokra, amelyek szubrutinokat tartalmaznak, amelyeket egy funkció szerint kombinálnak. funkciót, és újra felhasználhatók a következő programokban.
Ismerje meg a rendszer fogalmát. A tervezési folyamat során figyelembe veszik a rendszert különböző nézőpontokból modellek segítségével, amelyek különféle ábrázolásai diagramok formájában jelennek meg. Az olvasónak ismét kérdései lehetnek a fogalmak jelentésével kapcsolatban modellekÉs diagramok. Szerintünk szép, de nem túl világos meghatározás modellek szemantikailag zárt rendszerabsztrakcióként nem valószínű, hogy tisztázza a helyzetet, ezért megpróbáljuk "saját szavainkkal" elmagyarázni.
Modell- ez egy bizonyos (anyagi vagy nem) objektum, amely csak a rendszer legjelentősebb jellemzőit jeleníti meg ehhez a feladathoz. A modellek különbözőek - kézzelfogható és megfoghatatlan, mesterséges és természetes, dekoratív és matematikai...
Mondjunk néhány példát. A mindannyiunk számára ismerős műanyag játékautók, amelyekkel gyerekkorunkban olyan szenvedéllyel játszottunk, nem más, mint anyaga mesterséges díszítő igazi autómodell. Természetesen egy ilyen "autóban" nincs motor, nem töltjük meg a tankját benzinnel, a váltó nem működik benne (sőt, egyáltalán nincs), de modellként ez a játék maradéktalanul teljesíti. funkciók: képet ad a gyereknek az autóról, mert megjeleníti jellegzetességeit a négy kerék megléte, karosszéria, ajtók, ablakok, vezetési képesség stb.
Az orvosi kutatásban az állatkísérletek gyakran megelőzik a gyógyszerek embereken végzett klinikai vizsgálatait. Ebben az esetben az állat úgy viselkedik természetes anyag emberi modellek.
A fent látható egyenlet is egy modell, de ez egy matematikai modell, és egy anyagi pont gravitáció hatására történő mozgását írja le.
Már csak azt kell megmondani, mi az a diagram. Diagram az elemek halmazának grafikus ábrázolása. Általában gráfként ábrázolják csúcsokkal (entitásokkal) és élekkel (relációkkal). Sok példa van diagramokra. Ez egy mindannyiunk számára iskolai évekből ismerős blokkdiagram, és különféle berendezések telepítési diagramja, amelyeket a felhasználói kézikönyvekben láthatunk, valamint egy lemezen lévő fájlok és könyvtárak fája, amelyet a tree parancs futtatásával láthatunk. Windows konzol, és még sok más. A mindennapi életben minden oldalról diagramok vesznek körül minket, mert egy kép könnyebben érzékelhető, mint egy szöveg...
De térjünk vissza a szoftvertervezéshez (és nem csak). Azóta ebben az iparágban diagramok segítségével különböző nézőpontokból vizualizálhatja a rendszert. Az egyik diagram például leírhatja a felhasználó interakcióját a rendszerrel, a másik - a rendszer állapotainak változását a működése során, a harmadik - a rendszer elemei közötti interakciót stb. A rendszert kicsi és szinte független modellek - diagramok halmazaként lehet és kell ábrázolni, és ezek egyike sem elegendő a rendszer leírására és teljes kép kialakítására, mivel mindegyik a rendszer működésének egy-egy aspektusára összpontosít. rendszert és mást fejez ki absztrakciós szint. Más szavakkal, minden modell megfelel a tervezett rendszer valamilyen sajátos, sajátos nézőpontjának.
Annak ellenére, hogy az előző bekezdésben nagyon laza volt a modell fogalma, meg kell érteni, hogy a fenti definíciókkal összefüggésben egyetlen diagram sem modell. A diagramok csak a modell vizualizálásának eszközei, és a kettőt meg kell különböztetni. Csak diagramok halmaza alkot egy rendszermodelltés a legteljesebben leírja, de egyetlen diagramot sem a kontextusból kiragadva.
A diagramok típusai
UML 1.5 meghatározva tizenkét féle diagram három csoportra osztva:
- négyféle diagram ábrázolja az alkalmazás statikus szerkezetét;
- öt a rendszer viselkedési vonatkozásait képviseli;
- három a rendszer működésének fizikai vonatkozásait képviseli (megvalósítási diagramok).
Az UML 2.1 jelenlegi verziója nem végzett túl sok változtatást. A diagramok megjelenése kissé megváltozott (keretek és egyéb vizuális fejlesztések jelentek meg), a jelölések kissé javultak, egyes diagramok új nevet kaptak.
Azonban a pontos szám kanonikus diagramok ez számunkra teljesen lényegtelen, mivel nem mindegyiket fogjuk figyelembe venni, hanem csak néhányat - abból az okból, hogy egy adott alkalmazás egy adott modelljéhez tartozó diagramtípusok száma nincs szigorúan rögzítve. Egyszerű alkalmazásokhoz nincs szükség kivétel nélkül az összes diagram elkészítésére. Például egy helyi alkalmazáshoz nem szükséges telepítési diagramot készíteni. Fontos megérteni, hogy a diagramok listája a fejlesztés alatt álló projekt sajátosságaitól függ, és maga a fejlesztő határozza meg. Ha a kíváncsi olvasó továbbra is tudni akar az összes UML diagramról, akkor az UML szabványra hivatkozunk (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Emlékezzünk vissza, hogy ennek a kurzusnak nem az a célja, hogy az UML minden lehetőségét leírja, hanem csak ennek a nyelvnek a bemutatása, hogy kezdeti képet adjon erről a technológiáról.
Tehát röviden megvizsgáljuk az alábbi típusú diagramokat:
- használati eset diagram;
- osztálydiagram;
- objektum diagram;
- szekvencia diagram;
- interakciós diagram;
- állapotdiagram;
- tevékenység diagram;
- telepítési diagram.
Néhány ilyen diagramról a következő előadásokban részletesebben is szó lesz. Egyelőre nem a részletekre koncentrálunk, hanem azt a célt tűztük ki magunk elé, hogy megtanítsuk az olvasót legalább vizuálisan megkülönböztetni a diagramtípusokat, hogy kezdeti képet adjunk a fő diagramtípusok céljáról. Szóval, kezdjük.
Használja az esetdiagramot
Minden (beleértve a szoftvert is) rendszert úgy tervezték meg, hogy figyelembe veszik, hogy munkájuk során emberek fogják használni és/vagy kölcsönhatásba lépnek más rendszerekkel. Azokat az entitásokat, amelyekkel a rendszer munkája során kölcsönhatásba lép, ún szereplők, és minden szereplő elvárja, hogy a rendszer szigorúan meghatározott, kiszámítható módon viselkedjen. Próbáljuk meg szigorúbb definíciót adni az ektornak. Ehhez egy csodálatos vizuális szókincset használunk az UML-hez Zicom mentor:
Hector (színész)- ez logikailag összefüggő szerepek halmaza, amelyeket precedensekkel vagy entitásokkal (rendszer, alrendszer vagy osztály) való interakció során hajtanak végre. A szereplő lehet egy személy vagy egy másik rendszer, alrendszer vagy osztály, amely az entitáson kívül valamit képvisel.
Grafikusan a vektor vagy " kisember", hasonlóan azokhoz, amelyeket gyermekkorunkban rajzoltunk, családunk tagjait ábrázolva, ill osztályszimbólum a megfelelő sztereotípiával, ahogy a képen is látszik. Mindkét megjelenítési forma azonos jelentéssel bír, és diagramokban használható. A "sztereotip" formát gyakrabban használják rendszerszereplők ábrázolására, vagy amikor egy szereplőnek olyan tulajdonságai vannak, amelyeket meg kell jeleníteni (2.1. ábra).
A figyelmes olvasó azonnal felteheti a kérdést: Miért Hector és nem színész?? Egyetértünk, az "ektor" szó egy orosz ember fülén vág egy kicsit. Az ok, amiért ezt mondjuk, egyszerű – az ektor a szóból alakul ki akció, ami fordításban azt jelenti akció. Az "ektor" szó szó szerinti fordítása - színész- túl hosszú és kényelmetlen a használata. Ezért továbbra is ezt fogjuk mondani.
Rizs. 2.1.
Ugyanez a figyelmes olvasó észrevehette az ektor definíciójában felvillanó "precedens" szót. Mi az? Ez a kérdés még jobban érdekel majd bennünket, ha eszünkbe jut, amiről most beszélünk használati eset diagram. Így,
Precedens (használati eset)- a rendszer viselkedésének egy adott aspektusának leírása a felhasználó szemszögéből (Butch).
A definíció meglehetősen érthető és kimerítő, de ugyanezzel tovább finomítható Zicom mentor"om:
használati eset- a rendszer által végrehajtott egymást követő események halmazának leírása (beleértve a változatokat is), amelyek a szereplő által megfigyelt eredményhez vezetnek. A használati eset egy entitás viselkedését reprezentálja a szereplők és a rendszer közötti interakció leírásával. A precedens nem azt mutatja meg, hogy "hogyan" sikerült elérni egy bizonyos eredményt, hanem csak azt, hogy "milyen" az.
A precedenseket nagyon egyszerű módon jelzik - ellipszis formájában, amelyben a neve szerepel. A használati esetek és szereplők vonalakkal kapcsolódnak össze. A sor egyik végén gyakran rizst ábrázolnak. 2.3
Az UML ma a szoftverrendszerek vizuális modellezésének szabványos jelölése, amelyet az Object Managing Group (OMG) 1997 őszén fogadott el, és amelyet számos objektum-orientált CASE termék támogat.
Az UML szabvány a következő diagramokat kínálja a modellezéshez:
Használati eset diagram (use case diagram) - egy szervezet vagy vállalkozás üzleti folyamatainak modellezésére és a létrehozandó információs rendszer követelményeinek meghatározására;
osztálydiagram (osztálydiagram) - a rendszerosztályok statikus szerkezetének és a köztük lévő kapcsolatok modellezésére;
rendszer viselkedési diagramja (viselkedési diagramok);
interakciós diagramok;
Szekvenciadiagramok - az objektumok közötti üzenetküldési folyamat modellezésére egy használati eseten belül;
együttműködési diagram (együttműködési diagram) - ugyanazon használati eseten belüli objektumok közötti üzenetküldési folyamat modellezésére;
állapotdiagram diagram - a rendszerobjektumok viselkedésének modellezésére az egyik állapotból a másikba való átmenet során;
tevékenység diagram - a rendszer viselkedésének modellezésére különböző használati esetek, vagy modellezési tevékenységek keretein belül;
megvalósítási diagram (megvalósítási diagramok):
Komponens diagramok (komponens diagramok) - információs rendszer összetevői (alrendszerei) hierarchiájának modellezésére;
telepítési diagram (telepítési diagram) - a tervezett információs rendszer fizikai architektúrájának modellezésére.
ábrán Az 1.1 az információs rendszer integrált modelljét mutatja be, beleértve a kurzusprojektben kidolgozandó fő diagramokat.
Rizs. 1. Információs rendszer integrált modellje az UML nyelv jelölésében
4.2. Használati eset diagram
A használati eset a rendszer által valamilyen külső objektum (aktor) által kiváltott eseményre válaszul végrehajtott műveletek sorozata. A használati eset egy tipikus interakciót ír le a felhasználó és a rendszer között. A legegyszerűbb esetben a használati esetet a felhasználóval való megbeszélés során határozzuk meg, hogy milyen funkciókat szeretne megvalósítani ebben az információs rendszerben. Az UML-ben a használati eset a következőképpen jelenik meg:
2. ábra. Használati eset
A szereplő egy olyan szerep, amelyet a felhasználó a rendszerrel kapcsolatban betölt. A színészek szerepeket képviselnek, nem konkrét személyeket vagy beosztásokat. Bár a használati eset diagramokon stilizált emberalakként ábrázolják őket, a szereplő egy külső információs rendszer is lehet, akinek szüksége van bizonyos információkra a rendszertől. Csak akkor jelenítse meg a szereplőket diagramon, ha valóban szükségük van néhány felhasználási esetre. Az UML-ben a szereplőket alakzatokként ábrázolják:
3. ábra. karakter (színész)
A színészek három fő típusra oszthatók:
Felhasználók
rendszerek;
Más rendszerek, amelyek kölcsönhatásba lépnek ezzel;
Az idő akkor válik cselekvővé, ha attól függ a rendszer bármely eseményének kiváltása.
4.2.1. A 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ó (kommunikáció),
Befoglalás (beleértve),
bővítés (kiterjesztés),
általánosítás.
kommunikációs kommunikáció a használati eset és a szereplő kapcsolata. Az UML-ben a kommunikációs kapcsolatok egyirányú társítással (folytonos vonal) jelennek meg.
4. ábra. Példa kommunikációs linkre
Befogadási kapcsolat olyan helyzetekben használatos, amikor a rendszer viselkedésének egy része egynél több használati esetben ismétlődik. Az ilyen hivatkozások segítségével általában egy újrafelhasználható függvényt modelleznek.
Hosszabbító csatlakozás a rendszer normál viselkedésében bekövetkezett változások leírására szolgál. Lehetővé teszi, hogy egy használati eset szükség esetén egy másik használati eset funkcióit használja.
5. ábra. Példa egy belefoglaló és kiterjeszthető kapcsolatra
Kommunikációs általánosítás azt jelzi, hogy több szereplőnek vagy osztálynak vannak közös tulajdonságai.
6. ábra. Példa az általánosító kapcsolatra
4.3.
Interakciós diagramokírja le az egymással kölcsönható objektumcsoportok viselkedését. Az interakciós diagramok általában csak az objektumok viselkedését fedik le egyetlen használati eseten belül. Egy ilyen diagram számos objektumot és az általuk egymással kicserélt üzeneteket jelenít meg.
üzenet az az eszköz, amellyel a küldő objektum felkéri a fogadó objektumot az egyik művelet végrehajtására.
Tájékoztató (tájékoztató) üzenet egy üzenet, amely a fogadó objektumot bizonyos információkkal látja el az állapot frissítéséhez.
Kérdő üzenet (kérdő) egy üzenet, amely bizonyos információk kiadását kéri a fogadó objektumról.
Kötelező üzenet egy üzenet, amely felkéri a címzettet, hogy hajtson végre valamilyen műveletet.
Kétféle interakciós diagram létezik: szekvenciadiagram és együttműködési diagram.
4.3.1. Szekvencia diagramok
szekvencia diagram az egyetlen használati eseten belül előforduló események áramlását tükrözi.
Az adott forgatókönyvben (használati eset) részt vevő összes szereplő (aktorok, osztályok vagy objektumok) a diagram tetején látható. A nyilak a szereplő és egy objektum, illetve az objektumok között a szükséges funkciók végrehajtása érdekében átadott üzeneteknek felelnek meg.
A sorozatdiagramban egy objektum téglalapként van ábrázolva, amelyből egy szaggatott függőleges vonal húzódik lefelé. Ezt a vonalat hívják egy tárgy életvonala . Egy tárgy életciklusának töredéke az interakció folyamatában.
Minden üzenet nyílként jelenik meg két objektum életvonala között. Az üzenetek abban a sorrendben jelennek meg, ahogy fentről lefelé jelennek meg az oldalon. Minden üzenet legalább az üzenet nevével van megcímkézve. Opcionálisan argumentumokat és vezérlőinformációkat is hozzáadhat. Megjelenítheti az öndelegációt, egy üzenetet, amelyet egy objektum küld magának, és az üzenet nyíl ugyanarra a mentővonalra mutat.
Rizs. 7. Példa a szekvencia diagramra
4.3.2. Együttműködési diagram
Együttműködési diagramok az események folyamatának megjelenítése egy adott forgatókönyvön belül (használati eset). Az üzenetek idő szerint vannak rendezve, bár az együttműködési diagramok inkább az objektumok közötti kapcsolatokra összpontosítanak. Az együttműködési diagram minden információt megjelenít, amely a sorozatdiagrammal rendelkezik, de az együttműködési diagram más módon írja le az események folyamatát. Ebből könnyebb megérteni az objektumok közötti kapcsolatokat.
Az együttműködési diagramban, akárcsak a szekvenciadiagramban, a nyilak jelzik az adott használati eseten belül kicserélt üzeneteket. Időbeli sorrendjüket az üzenetek számozása jelzi.
Rizs. 8. Példa együttműködési diagramra
4.4. osztálydiagram
4.4.1. Általános információ
osztálydiagram meghatározza a rendszerosztályok típusait és a köztük létező különféle statikus kapcsolatokat. Az osztálydiagramok az osztályattribútumokat, az osztályműveleteket és az osztályok közötti kapcsolatokra vonatkozó megszorításokat is mutatják.
Az osztálydiagram az UML-ben egy olyan gráf, amelynek csomópontjai a projekt statikus struktúrájának elemei (osztályok, interfészek), az ívek pedig a csomópontok közötti kapcsolatokat (asszociációk, öröklődés, függőségek).
Az osztálydiagram a következő elemeket mutatja:
· Csomag (csomag) - a modell elemeinek halmaza, amelyek logikailag kapcsolódnak egymáshoz;
· Osztály (osztály) - hasonló objektumok csoportjának közös tulajdonságainak leírása;
· Interfész (interfész) - egy absztrakt osztály, amely meghatározza a műveletek halmazát, amelyet egy adott interfészhez társított tetszőleges osztály objektuma más objektumok számára biztosít.
4.4.2. Osztály
Osztály olyan entitások (objektumok) csoportja, amelyek hasonló tulajdonságokkal, nevezetesen adatokkal és viselkedéssel rendelkeznek. Egy osztály egyes tagját az osztály objektumának, vagy egyszerűen objektumnak nevezzük.
Az objektumok viselkedése az UML-ben minden olyan szabályra vonatkozik, amely egy objektumnak a külvilággal és magának az objektumnak az adataival való interakciójára vonatkozik.
A diagramokon egy osztályt egy téglalapként ábrázolnak, szilárd szegéllyel, amelyet vízszintes vonalak 3 részre osztanak:
A felső rész (a név rész) tartalmazza az osztály nevét és egyéb általános tulajdonságokat (különösen a sztereotípiát).
A középső rész az attribútumok listáját tartalmazza
Alul az osztályműveletek listája található, amelyek tükrözik az osztály viselkedését (az osztály által végrehajtott műveletek).
Előfordulhat, hogy az attribútumok és műveletek egyike sem jelenik meg (vagy mindkettő). A hiányzó szakaszhoz nem kell választóvonalat húznia, és valahogy jeleznie kell az elemek jelenlétét vagy hiányát.
További szakaszok, például Kivételek, egy adott megvalósítás belátása szerint vezethetők be.
Rizs. 9. Osztálydiagram példa
4.4.2.1.Osztálysztereotípiák
Az osztálysztereotipizálás az osztályok kategóriákba sorolásának mechanizmusa.
Az UML három fő osztálysztereotípiát határoz meg:
Határ (határ);
Entitás (entitás);
Irányítás (menedzsment).
4.4.2.2.Határosztályok
A határosztályok azok az osztályok, amelyek a rendszer és a teljes környezet határán helyezkednek el. Ezek kijelzők, jelentések, hardverrel (például nyomtatókkal vagy szkennerekkel) való interfészek és más rendszerekkel való interfészek.
A határosztályok megtalálásához fel kell fedeznie a használati eset diagramokat. A szereplő és a használati eset közötti minden interakciónak legalább egy határosztályt kell tartalmaznia. Ez az osztály teszi lehetővé a szereplő számára, hogy interakcióba lépjen a rendszerrel.
4.4.2.3.Entitásosztályok
Az entitásosztályok tárolt információkat tartalmaznak. Ezek jelentik a legnagyobb jelentést a felhasználó számára, ezért nevükben gyakran a tárgykör kifejezéseit használják. Általában minden entitásosztályhoz egy tábla jön létre az adatbázisban.
4.4.2.4.Ellenőrző osztályok
A kontroll osztályok felelősek más osztályok tevékenységeinek koordinálásáért. Általában minden használati esetnek van egy vezérlőosztálya, amely vezérli az adott használati eset eseménysorozatát. A vezérlő osztály felelős a koordinációért, de önmagában nem hordoz semmilyen funkcionalitást, mivel a többi osztály nem küld neki nagy mennyiségű üzenetet. Ehelyett ő maga küld egy csomó üzenetet. A menedzser osztály egyszerűen átruházza a felelősséget más osztályokra, ezért gyakran menedzser osztálynak nevezik.
Lehetnek más vezérlési osztályok is a rendszerben, amelyek több használati esetre is jellemzőek. Például lehet, hogy egy SecurityManager osztály felelős a biztonsággal kapcsolatos események figyeléséért. A TransactionManager osztály kezeli az adatbázis-tranzakciókhoz kapcsolódó üzenetek koordinálását. A rendszer működésének egyéb elemeivel, például az erőforrások megosztásával, az elosztott adatfeldolgozással vagy a hibakezeléssel más menedzserek is foglalkozhatnak.
A fent említett sztereotípiákon kívül létrehozhat sajátot is.
4.4.2.5.Attribútumok
Az attribútum egy osztályhoz társított információ. Az attribútumok beágyazott osztályadatokat tárolnak.
Mivel az attribútumok az osztályon belül vannak, el vannak rejtve a többi osztály elől. Emiatt szükséges lehet megadni, hogy mely osztályoknak van joguk attribútumok olvasására és módosítására. Ezt a tulajdonságot attribútum láthatóságnak nevezzük.
Az attribútum négy lehetséges értéket tartalmazhat ehhez a paraméterhez:
Nyilvános (általános, nyitott). Ez a láthatósági érték feltételezi, hogy az attribútum az összes többi osztály számára látható lesz. Bármely osztály megtekintheti vagy módosíthatja egy attribútum értékét. Az UML jelöléssel összhangban a közös attribútumot "+" jel előzi meg.
Privát (zárt, titkos). A megfelelő attribútum nem látható más osztály számára. A privát attribútumokat "-" jellel jelöljük az UML jelöléssel összhangban.
Védett (védett). Egy ilyen attribútum csak maga az osztály és leszármazottai számára elérhető. A védett attribútum UML-jelölése a „#” karakter.
Csomag vagy megvalósítás (kötegelt). Tegyük fel, hogy az adott attribútum meg van osztva, de csak a csomagjában. Az ilyen típusú láthatóságot semmilyen speciális ikon nem jelzi.
A zártság vagy a biztonság segítségével elkerülhető az a helyzet, amikor az attribútumértéket a rendszer minden osztálya megváltoztatja. Ehelyett az attribútummódosítási logika ugyanabba az osztályba kerül, mint maga az attribútum. A beállított láthatósági beállítások hatással lesznek a generált kódra.
4.4.2.6.Tevékenységek
A műveletek osztályhoz kapcsolódó viselkedést valósítanak meg. Egy művelet három részből áll: névből, paraméterekből és visszatérési típusból.
A paraméterek azok az argumentumok, amelyeket a művelet bemenetként kap. A visszatérési típus a művelet műveletének eredményére vonatkozik.
Az osztálydiagram megjelenítheti a műveletek nevét és a műveletek nevét, paramétereiket és visszatérési típusukat. A diagram terhelésének csökkentése érdekében célszerű néhány műveletnek csak a nevét, másokon pedig a teljes aláírást megjeleníteni.
Az UML-ben a műveletek a következő jelöléssel rendelkeznek:
Művelet neve (argumentum: argumentum adattípus, argumentum2: argumentum2 adattípus,...): visszatérési típus
Négy különböző típusú műveletet kell figyelembe venni:
Végrehajtási műveletek;
Menedzsment műveletek;
Hozzáférési műveletek;
Segédműveletek.
Megvalósítási műveletek
A végrehajtó műveletek bizonyos üzleti funkciókat valósítanak meg. Ilyen műveleteket 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 műveletnek könnyen nyomon követhetőnek kell lennie a megfelelő követelményhez. Ez a szimuláció különböző szakaszaiban érhető el. A művelet az interakciós diagramban szereplő üzenetből, az üzenetek az eseményfolyam részletes leírásából származnak, amely a használati eset alapján generálódik, utóbbi pedig a követelmények alapján. Az egész lánc nyomon követése lehetővé teszi, hogy biztosítsa, hogy minden követelmény megvalósuljon a kódban, és minden kódrészlet megvalósítsa valamilyen követelményt.
Menedzsment műveletek
A menedzser műveletek kezelik az objektumok létrehozását és megsemmisítését. Az osztálykonstruktorok és destruktorok ebbe a kategóriába tartoznak.
Hozzáférési műveletek
Az attribútumok általában privátak vagy védettek. Más osztályoknak azonban néha meg kell tekinteniük vagy módosítaniuk kell az értékeket. Ehhez vannak hozzáférési műveletek. Ez a megközelítés lehetővé teszi az attribútumok biztonságos beágyazását egy osztályon belül, megvédve őket más osztályoktól, de továbbra is lehetővé teszi azokhoz való ellenőrzött hozzáférést. A Get és Set műveletek létrehozása (érték lekérése és módosítása) egy osztály minden attribútumához szabvány.
Segédműveletek
A segédműveletek (segítő műveletek) egy osztály azon műveletei, amelyek szükségesek a feladatai ellátásához, de amelyekről a többi osztálynak nem szabad tudnia semmit. Ezek privát és védett osztályú műveletek.
A tranzakciók azonosításához tegye a következőket:
1. Tanulmányozási sorrend diagramok és kooperatív diagramok. A diagramokban szereplő üzenetek többsége megvalósítási művelet. A tükröződő üzenetek segédműveletek lesznek.
2. Fontolja meg a vezérlési műveleteket. Lehetséges, hogy konstruktorokat és destruktorokat kell hozzáadnia.
3. Fontolja meg a hozzáférési műveleteket. Minden egyes osztályattribútumhoz, amellyel más osztályoknak dolgozniuk kell, létre kell hoznia a Get 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 üzenetet küldjön a másiknak sorozatban vagy kooperatív diagramban, kapcsolatnak kell lennie közöttük.
Az osztályok között négyféle kapcsolat létesíthető: asszociációk, függőségek, aggregációk és általánosítások.
Kommunikációs egyesület
Az asszociáció az osztályok közötti szemantikai kapcsolat. Az osztálydiagramon közönséges vonalként rajzolódnak ki.
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ú társításokat egyszerű vonalként rajzolják meg nyilak nélkül, vagy a vonal mindkét oldalán nyilakkal. Egy egyirányú asszociációnak csak egy nyíla van, amely az irányát mutatja.
Egy asszociáció iránya a szekvenciadiagramok és a kooperatív diagramok vizsgálatával határozható meg. Ha az összes rajtuk lévő üzenetet csak egy osztály küldi, és csak egy másik osztály fogadja, de fordítva nem, akkor ezen osztályok között egyirányú kommunikáció jön létre. Ha legalább egy üzenetet az ellenkező irányba küldenek, a társításnak kétirányúnak kell lennie.
Az asszociációk lehetnek reflexívek. A reflexív asszociáció azt jelenti, hogy egy osztály egy példánya kölcsönhatásba lép ugyanannak az osztálynak a többi példányával.
Kommunikációs függőség
A függőségi kapcsolatok az osztályok közötti kapcsolatot is tükrözik, de mindig egyirányúak, és azt mutatják, hogy az egyik osztály a másikban készített definícióktól függ. Például az A osztály a B osztály metódusait használja. Amikor a B osztály megváltozik, megfelelő változtatásokat kell végrehajtani az A osztályban.
A függőséget két diagramelem közé húzott szaggatott vonal jelöli, és a nyíl végén lehorgonyzott elemről azt mondjuk, hogy függ a nyíl elején rögzített elemtől.
Rizs. 11. Kommunikációs függőség
Amikor kódot generál ezekhez az osztályokhoz, nem adnak hozzá új attribútumokat. A kommunikáció támogatásához szükséges nyelvspecifikus operátorok azonban létrejönnek.
Kommunikációs aggregáció
Az aggregáció szorosabb társulási forma. Az aggregáció az egész és része közötti kapcsolat. Például rendelkezhet autóosztályokkal, valamint motor-, gumiabroncs-osztályokkal és más autóalkatrész-osztályokkal. Ennek eredményeként az Autó osztály objektuma egy Engine osztályú objektumból, négy gumiabroncs objektumból stb. fog állni. Az aggregációk egy rombuszos vonalként jelennek meg egy olyan osztály esetében, amely egész szám:
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 szerepmultiplicitás 1..1; Például, ha egy Ügyfelet törölni kell, akkor ezt a törlést tovább kell vinni a Megrendelésekre (és viszont a Megbízási sorokra).
Az UML egy egységes grafikus modellező nyelv az OO rendszerek leírására, megjelenítésére, tervezésére és dokumentálására. Az UML célja, hogy támogassa az OO megközelítésen alapuló PS-modellezés folyamatát, rendezze a fogalmi és programkoncepciók kapcsolatát, és tükrözze a komplex rendszerek skálázásának problémáit. Az UML modelleket a szoftver életciklusának minden szakaszában használják, az üzleti elemzéstől a rendszerkarbantartásig. A különböző szervezetek a maguk módján használhatják az UML-t, a problémakörüktől és az alkalmazott technológiáktól függően.
Az UML rövid története
Az 1990-es évek közepére több tucat OO modellezési módszert javasoltak különböző szerzők, amelyek mindegyike saját grafikus jelölést használt. Ugyanakkor ezen módszerek bármelyikének megvoltak az erősségei, de nem tették lehetővé egy kellően teljes PS-modell felépítését, hogy azt „minden oldalról” megmutassák, vagyis az összes szükséges vetületet (lásd 1. cikk). Ezenkívül az OO modellezési szabvány hiánya megnehezítette a fejlesztők számára a legmegfelelőbb módszer kiválasztását, ami megakadályozta az OO megközelítés széles körű alkalmazását a szoftverfejlesztésben.
Az Object Management Group (OMG) - az objektumtechnológiák és adatbázisok területén szabványok elfogadásáért felelős szervezet - kérésére a három legnépszerűbb OO-módszer szerzője - G. Booch - megoldotta az egységesítés és szabványosítás sürgető problémáját. , D. Rambo és A. Jacobson, akik az Efforts-t egyesítették, létrehozták az OMG által 1997-ben szabványként jóváhagyott UML 1.1-es verziót.
Az UML egy nyelv
Minden nyelv egy szótárból és a szavak kombinálására vonatkozó szabályokból áll, hogy értelmes konstrukciókat hozzanak létre. Tehát különösen a programozási nyelvek vannak elrendezve, ilyen az UML. Különlegessége, hogy a nyelv szókincsét grafikai elemek alkotják. Minden grafikus szimbólumnak sajátos szemantikája van, így az egyik fejlesztő által készített modellt egyértelműen megértheti a másik, valamint az UML-t értelmező eszköz is. Ebből különösen az következik, hogy egy UML-ben bemutatott PS modell automatikusan lefordítható OO programozási nyelvre (például Java, C ++, VisualBasic), vagyis egy jó, UML-t támogató vizuális modellező eszközzel, egy modell felépítésekor a modellnek megfelelő programkód üres részét is megkapjuk.
Hangsúlyozni kell, hogy az UML nyelv, nem módszer. Elmagyarázza, hogy milyen elemekből kell modelleket létrehozni, és hogyan kell azokat olvasni, de nem mond semmit arról, hogy mely modelleket és milyen esetekben kell fejleszteni. Az UML alapú metódus létrehozásához szükséges kiegészíteni a PS fejlesztési folyamat leírásával. Ilyen folyamat például a Rational Unified Process, amelyről a későbbi cikkekben lesz szó.
UML szókincs
A modell entitások és a köztük lévő kapcsolatok formájában jelenik meg, amelyeket diagramokon mutatunk be.
Esszenciák absztrakciók, amelyek a modellek fő elemei. Négyféle entitás létezik: strukturális (osztály, interfész, komponens, használati eset, együttműködés, csomópont), viselkedési (interakció, állapot), csoportosítás (csomagok) és megjegyzések (megjegyzések). Minden entitástípusnak megvan a maga grafikus ábrázolása. Az entitásokat a diagramok tanulmányozása során részletesen tárgyaljuk.
Kapcsolatok különböző kapcsolatokat mutat be az entitások között. A következő típusú kapcsolatok vannak meghatározva az UML-ben:
- Függőség olyan kapcsolatot mutat két entitás között, amikor az egyik – független – változása hatással lehet a másik – függő – szemantikájára. A függőséget egy pontozott nyíl jelöli, amely a függő entitástól a független entitás felé mutat.
- Egyesület egy strukturális kapcsolat, amely megmutatja, hogy az egyik entitás objektumai egy másik objektumaihoz kapcsolódnak. Grafikusan egy asszociáció a kapcsolódó entitásokat összekötő vonalként jelenik meg. Az asszociációk az objektumok közötti navigálásra szolgálnak. Például a "Rendelés" és a "Termék" osztályok közötti társítás használható egy adott rendelésben megadott összes termék megtalálására - egyrészt, másrészt az összes olyan rendelés megkeresésére, amely ezt a terméket tartalmazza. Nyilvánvaló, hogy a megfelelő programoknak olyan mechanizmust kell megvalósítaniuk, amely ilyen navigációt biztosít. Ha csak egy irányba kell navigálni, azt a társítás végén nyíl jelzi. Az asszociáció speciális esete az aggregáció – az „egész” – „rész” formájú kapcsolat. Grafikusan egy rombusszal van kiemelve a végén, az entitás-egész közelében.
- Általánosítás egy kapcsolat egy szülő entitás és egy alárendelt entitás között. Ez a kapcsolat lényegében az osztályok és objektumok öröklődési tulajdonságát tükrözi. Az általánosítás a szülőentitás felé mutató háromszöggel végződő vonalként jelenik meg. A gyermek örökli a szülő szerkezetét (tulajdonságait) és viselkedését (módszereit), ugyanakkor új szerkezeti elemei, új módszerei is lehetnek. Az UML lehetővé teszi a többszörös öröklődést, ha egy entitás egynél több szülőentitáshoz kapcsolódik.
- Végrehajtás- a viselkedés specifikációját meghatározó entitás (interfész) és a viselkedés megvalósítását meghatározó entitás közötti kapcsolat (osztály, komponens). Ezt a kapcsolatot gyakran használják a komponensmodellezésben, és a következő cikkekben részletesebben ismertetjük.
Diagramok. Az UML a következő diagramokat tartalmazza:
- A rendszer viselkedését leíró diagramok:
- Állapot diagramok (állapot diagramok),
- Tevékenység diagramok,
- Objektum diagramok,
- szekvencia diagramok,
- Együttműködési diagramok;
- A rendszer fizikai megvalósítását leíró diagramok:
- Alkatrész diagramok;
- Beépítési diagramok.
Modellvezérlő nézet. Csomagok.
Korábban már elmondtuk, hogy ahhoz, hogy egy modellt az ember jól megértsen, hierarchikusan kell megszervezni, kis számú entitást hagyva a hierarchia minden szintjén. Az UML tartalmaz egy eszközt a modell hierarchikus ábrázolásának szervezésére - csomagok. Bármely modell olyan csomagokból áll, amelyek osztályokat, használati eseteket és egyéb entitásokat és diagramokat tartalmazhatnak. Egy csomag más csomagokat is tartalmazhat, ami lehetővé teszi hierarchiák létrehozását. Az UML nem biztosít külön csomagdiagramokat, de előfordulhatnak más diagramokon. A csomag egy füllel ellátott téglalapként jelenik meg.
Amit az UML nyújt.
- komplex rendszer hierarchikus leírása csomagok kiemelésével;
- a rendszer funkcionális követelményeinek formalizálása a használati esetek apparátusával;
- a rendszer követelményeinek részletezése tevékenységi diagramok és forgatókönyvek készítésével;
- adatosztályok kiválasztása és fogalmi adatmodell felépítése osztálydiagramok formájában;
- a felhasználói felületet leíró osztályok kiválasztása és képernyőnavigációs séma létrehozása;
- az objektumok interakciós folyamatainak leírása a rendszerfunkciók végrehajtása során;
- az objektumok viselkedésének leírása tevékenységek és állapotok diagramjai formájában;
- szoftverkomponensek leírása és interfészeken keresztüli interakciójuk;
- a rendszer fizikai architektúrájának leírása.
És az utolsó…
Az UML minden vonzereje ellenére nehéz lenne valódi PS-modellezésben használni vizuális modellező eszközök nélkül. Az ilyen eszközök lehetővé teszik diagramok gyors megjelenítését a képernyőn, dokumentálásukat, programkód-üres generálást különböző OO programozási nyelveken és adatbázissémák létrehozását. Legtöbbjük tartalmazza a programkódok újratervezésének lehetőségét - a PS-modell bizonyos vetületeinek visszaállítását a programok forráskódjainak automatikus elemzésével, ami nagyon fontos a modell és a kódok egyezésének biztosításához, valamint az elődrendszerek funkcionalitását öröklő rendszerek tervezésekor. .
UML (Unified Modeling Language - egységes modellezési nyelv) - grafikus leíró nyelv objektummodellezéshez a szoftverfejlesztés területén. Az UML egy általános nyelv, egy nyílt szabvány, amely grafikus jelöléseket használ a rendszer absztrakt modelljének létrehozására, amelyet UML-modellnek neveznek. Az UML elsősorban szoftverrendszerek meghatározására, megjelenítésére, tervezésére és dokumentálására jött létre. Az UML nem programozási nyelv, de kódgenerálás lehetséges az UML modellek futásidejű eszközeiben értelmezett kódként. Wikipédia
Kereskedelmi termékek
Microsoft Visio
Típus: kereskedelmi szoftver
A Microsoft népszerű szoftverterméke, amely lehetővé teszi gazdag diagramok rajzolását, beleértve az UML-t is:
A 2010-es verziótól kezdve lehetővé vált diagramok webes közzététele (SharePoint + Visio Services):
Visio Viewer- egy ingyenes program, amely lehetővé teszi a korábban készített Visio diagramok megtekintését. Letöltheti a következő címről: %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20modellezés,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20szekvencia%20diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Használat%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Vizualizáció%20és%20Modellezés%20Feature%20Csomag%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20réteg%20diagramok%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20réteg%20diagramok %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20vizualizáció%20és%20modellezés%20jellemző%20csomag%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rational Rose
Lehetőségek:
- Használati eset diagram (előzmények diagramjai);
- Kiépítési diagram (topológia diagramok);
- Állapotdiagram (állapotdiagramok);
- Tevékenység diagram (tevékenység diagramok);
- Kölcsönhatás diagram (kölcsönhatás diagramok);
- Szekvenciadiagram (műveletsorozatok diagramjai);
- Együttműködési diagram (együttműködési diagramok);
- Osztálydiagram (osztálydiagramok);
- Alkatrész diagram (komponens diagramok).
Képernyőképek:
nyílt forráskódú programok
StarUML
Lehetőségek:
- UML 2.0 támogatás
- MDA (Model Driven Architecture)
- Plug-in architektúra (írhat COM-kompatibilis nyelveken: C++, Delphi, C#, VB, ...)
A StarUML-t főleg Delphiben írják, de más nyelveken is hozzáadhatók komponensek, például C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Az alábbiakban néhány képernyőkép látható.
Osztály diagram:
Használati eset diagram:
ArgoUML
Támogatott diagramok:
- osztály
- Állapot
- használati esetek
- Tevékenység
- Együttműködés
- Telepítés
- Sorrend
Lehetőségek:
- Kilenc UML 1.4 diagram támogatása
- Platformfüggetlen (Java 5+)
- UML 1.4 szabványos metamodell
- XMI támogatás
- Exportálás GIF, PNG, PS, EPS, PGML és SVG formátumba
- Nyelvek: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- OCL támogatás
- Forward, Reverse Engineering
Képernyőkép:
