Uml štruktúrne diagramy. UML diagramy
UML je teraz štandardná notácia vizuálneho modelovania. softvérové systémy, prijatý konzorciom Object Managing Group (OMG) na jeseň roku 1997, ktorý je podporovaný mnohými objektovo orientovanými produktmi CASE.
Štandard UML ponúka nasledujúcu sadu diagramov na modelovanie:
· diagram prípadov použitia – na modelovanie obchodných procesov organizácie alebo podniku a určenie požiadaviek na vytváraný informačný systém;
· diagram tried – na modelovanie statickej štruktúry systémových tried a väzieb medzi nimi;
· diagramy správania systému;
· interakčné diagramy;
· sekvenčné diagramy – na modelovanie procesu zasielania správ medzi objektmi v rámci jedného prípadu použitia;
· diagram spolupráce – na modelovanie procesu zasielania správ medzi objektmi v rámci jedného prípadu použitia;
· stavový diagram – na modelovanie správania sa objektov systému pri prechode z jedného stavu do druhého;
· diagram aktivít – na modelovanie správania systému v rámci rôznych prípadov použitia, prípadne modelovacích aktivít;
implementačné schémy:
· diagramy komponentov – na modelovanie hierarchie komponentov (subsystémov) informačného systému;
· diagram nasadenia – pre modelovanie fyzickej architektúry navrhovaného informačného systému.
Na obr. 1.1 predstavuje integrovaný model informačného systému vrátane hlavných diagramov, ktoré by mali byť vyvinuté v tomto projekte kurzu.
Ryža. 1. Integrovaný model informačného systému v notácii UML
4.2. Schéma prípadu použitia
Prípad použitia je postupnosť akcií vykonaných systémom v reakcii na udalosť iniciovanú nejakým externým objektom (aktérom). Prípad použitia opisuje typickú interakciu medzi používateľom a systémom. V najjednoduchšom prípade sa prípad použitia určí v procese diskusie s používateľom o funkciách, ktoré by chcel v tomto informačnom systéme implementovať. V UML je prípad použitia znázornený takto:
Obr.2. Prípad použitia
Aktér je rola, ktorú používateľ hrá vo vzťahu k systému. Herci predstavujú roly, nie konkrétne osoby alebo pracovné pozície. Hoci sú v diagramoch prípadov použitia zobrazené ako štylizované ľudské postavy, herec môže byť aj externý informačný systém, ktorý potrebuje nejaké informácie z tohto systému. Aktéri by mali byť na diagrame znázornení iba vtedy, ak skutočne potrebujú nejaké prípady použitia. V UML sú herci reprezentovaní ako tvary:
Obr.3. postava (herec)
Herci sú rozdelení do troch hlavných typov:
· používatelia;
· systémy;
· iné systémy interagujúce s týmto systémom;
Čas sa stáva aktérom, ak od neho závisí spustenie akýchkoľvek udalostí v systéme.
4.2.1. Vzťahy medzi prípadmi použitia a aktérmi
V UML diagramy prípadov použitia podporujú niekoľko typov vzťahov medzi prvkami diagramu:
· komunikácia
zahrnutie (zahrnutie),
· rozšírenie (predĺženie),
· zovšeobecňovanie.
komunikačný odkaz je vzťah medzi prípadom použitia a aktérom. V UML sú komunikačné vzťahy zobrazené pomocou jednosmernej asociácie (plná čiara).
Obr.4. Príklad komunikačného spojenia
Povoliť pripojenie používa sa v situáciách, keď existuje určitá časť správania systému, ktorá sa opakuje vo viac ako jednom prípade použitia. Tieto pripojenia sa zvyčajne používajú na modelovanie opätovne použiteľnej funkcie.
Expanzná komunikácia používa sa na opis zmien v normálnom správaní systému. V prípade potreby umožňuje použitie jedného prípadu použitia funkčnosť iný prípad použitia.
Obr.5. Príklad vzťahu zahrnutia a rozšírenia
Generalizačné spojenie ukazuje, že niekoľko aktérov alebo tried má spoločné vlastnosti.
Obr.6. Príklad prepojenia na zovšeobecnenie
4.3.
Interakčné diagramy opísať správanie interagujúcich skupín objektov. Interakčný diagram zvyčajne pokrýva správanie objektov iba v rámci jedného prípadu použitia. Takýto diagram zobrazuje množstvo objektov a správ, ktoré si navzájom vymieňajú.
Správa je prostriedok, ktorým odosielajúci objekt žiada objekt príjemcu, aby vykonal jednu z jeho operácií.
Informačná správa je správa, ktorá poskytuje objektu príjemcu nejaké informácie na aktualizáciu jeho stavu.
Žiadosť o správu (otázka) je správa požadujúca uvoľnenie niektorých informácií o objekte príjemcu.
Naliehavá správa je správa, ktorá požaduje od objektu príjemcu vykonať nejakú akciu.
Existujú dva typy interakčných diagramov: sekvenčné diagramy a diagramy spolupráce.
4.3.1. Sekvenčné diagramy
Sekvenčný diagram odráža tok udalostí vyskytujúcich sa v rámci jedného prípadu použitia.
Všetci aktéri (herci, triedy alebo objekty) zapojení do daného scenára (prípad použitia) sú znázornení v hornej časti diagramu. Šípky zodpovedajú správam prenášaným medzi aktérom a objektom alebo medzi objektmi na vykonávanie požadovaných funkcií.
V sekvenčnom diagrame je objekt znázornený ako obdĺžnik, z ktorého je nakreslená bodkovaná zvislá čiara. Táto linka je tzv záchranné lano objektu . Predstavuje fragment životného cyklu objektu v procese interakcie.
Každá správa je znázornená ako šípka medzi životnými líniami dvoch objektov. Správy sa zobrazujú v poradí, v akom sa zobrazujú na stránke zhora nadol. Každá správa je označená aspoň názvom správy. Ak chcete, môžete pridať aj argumenty a niektoré riadiace informácie. Môžete ukázať sebadelegovanie – správu, ktorú si objekt posiela sám, pričom šípka správy ukazuje na rovnakú líniu života.
Ryža. 7. Príklad sekvenčného diagramu
4.3.2. Diagram spolupráce
Diagramy spolupráce zobraziť tok udalostí v rámci konkrétneho scenára (prípad použitia). Správy sú zoradené podľa času, hoci diagramy spolupráce sa viac zameriavajú na spojenia medzi objektmi. Diagram spolupráce prezentuje všetky informácie, ktoré sú prítomné v sekvenčnom diagrame, ale diagram spolupráce popisuje tok udalostí odlišne. Uľahčuje pochopenie súvislostí, ktoré existujú medzi objektmi.
V diagrame spolupráce, rovnako ako v sekvenčnom diagrame, šípky predstavujú správy vymieňané v rámci daného prípadu použitia. Ich časová postupnosť je označená číslovaním správ.
Ryža. 8. Príklad kooperačného diagramu
4.4. Diagram triedy
4.4.1. Všeobecné informácie
Diagram triedy definuje typy tried systému a rôzne druhy statických spojení, ktoré medzi nimi existujú. Diagramy tried tiež zobrazujú atribúty tried, operácie tried a obmedzenia, ktoré sú kladené na vzťahy medzi triedami.
Diagram tried v jazyku UML je graf, ktorého uzly sú prvkami statickej štruktúry projektu (triedy, rozhrania) a oblúky sú vzťahy medzi uzlami (asociácie, dedičnosť, závislosti).
Diagram tried zobrazuje nasledujúce prvky:
· Balík – súbor prvkov modelu, ktoré spolu logicky súvisia;
· Trieda (trieda) - popis spoločných vlastností skupiny podobných objektov;
· Rozhranie – abstraktná trieda, ktorá špecifikuje množinu operácií, ktoré objekt ľubovoľnej triedy pridruženej k danému rozhraniu poskytuje iným objektom.
4.4.2. triedy
triedy je skupina entít (objektov), ktoré majú podobné vlastnosti, a to dáta a správanie. Jednotlivý zástupca triedy sa nazýva objekt triedy alebo jednoducho objekt.
Správanie objektu v UML odkazuje na akékoľvek pravidlá pre interakciu objektu s vonkajší svet a s údajmi samotného objektu.
V diagramoch je trieda znázornená ako obdĺžnik s pevným okrajom, rozdelený vodorovné čiary do 3 sekcií:
Horná časť (časť názvu) obsahuje názov triedy a ďalšie všeobecné vlastnosti (najmä stereotyp).
Stredná časť obsahuje zoznam atribútov
V spodnej časti je zoznam operácií triedy, ktoré odrážajú jej správanie (akcie vykonávané triedou).
Žiadna zo sekcií atribútov a operácií sa nemusí zobraziť (alebo obidve naraz). Pre chýbajúcu časť nemusíte kresliť deliacu čiaru ani žiadnym spôsobom naznačovať prítomnosť alebo neprítomnosť prvkov v nej.
Dodatočné oddiely, ako napríklad výnimky, môžu byť zavedené podľa uváženia konkrétnej implementácie.
Ryža. 9. Príklad diagramu tried
4.4.2.1.Triedne stereotypy
Stereotypy triedy sú mechanizmom na rozdelenie tried do kategórií.
UML definuje tri hlavné triedne stereotypy:
Hranica (hranica);
Entita (entita);
Kontrola.
4.4.2.2.Hraničné triedy
Hraničné triedy sú tie triedy, ktoré sa nachádzajú na hranici systému a celého prostredia. Toto obrazovkové formuláre, správy, rozhrania s hardvérom (ako sú tlačiarne alebo skenery) a rozhrania s inými systémami.
Ak chcete nájsť hraničné triedy, musíte preskúmať diagramy prípadov použitia. Každá interakcia medzi aktérom a prípadom použitia musí byť spojená s aspoň jednou hraničnou triedou. Práve táto trieda umožňuje hercovi interakciu so systémom.
4.4.2.3.triedy entít
Triedy entít obsahujú uložené informácie. Pre používateľa majú najväčší význam, a preto ich názvy často používajú výrazy z predmetnej oblasti. Typicky sa v databáze vytvorí tabuľka pre každú triedu entity.
4.4.2.4.Kontrolné triedy
Kontrolné triedy sú zodpovedné za koordináciu akcií ostatných tried. Každý prípad použitia má zvyčajne jednu riadiacu triedu, ktorá riadi postupnosť udalostí pre daný prípad použitia. Riadiaca trieda je zodpovedná za koordináciu, ale sama o sebe nenesie žiadnu funkčnosť, pretože ostatné triedy ju neposielajú veľké množstvo správy. Namiesto toho sám posiela veľa správ. Trieda manažérov jednoducho deleguje zodpovednosť na iné triedy, a preto sa často nazýva trieda manažérov.
V systéme môžu existovať ďalšie triedy riadenia, ktoré sú spoločné pre viaceré prípady použitia. Napríklad môže existovať trieda SecurityManager (správca zabezpečenia) zodpovedná za monitorovanie udalostí súvisiacich s bezpečnosťou. Trieda TransactionManager je zodpovedná za koordináciu správ súvisiacich s databázovými transakciami. Môžu existovať iní manažéri, ktorí sa starajú o iné prvky fungovania systému, ako je zdieľanie zdrojov, distribuované spracovanie údajov alebo spracovanie chýb.
Okrem vyššie uvedených stereotypov si môžete vytvoriť svoj vlastný.
4.4.2.5.Atribúty
Atribút je prvok informácií spojený s triedou. Atribúty ukladajú zapuzdrené údaje triedy.
Pretože atribúty sú obsiahnuté v triede, sú skryté pred ostatnými triedami. Z tohto dôvodu možno budete musieť určiť, ktoré triedy majú právo čítať a meniť atribúty. Táto vlastnosť sa nazýva viditeľnosť atribútov.
Atribút môže mať štyri možné hodnoty tohto parametra:
Verejné (všeobecné, otvorené). Táto hodnota viditeľnosti predpokladá, že atribút bude viditeľný pre všetky ostatné triedy. Akákoľvek trieda môže zobraziť alebo zmeniť hodnotu atribútu. Podľa notácie UML je pred bežným atribútom znak „+“.
Súkromné (uzavreté, tajné). Zodpovedajúci atribút nie je viditeľný pre žiadnu inú triedu. Súkromný atribút je označený znakom „–“ podľa notácie UML.
Chránené (chránené). Tento atribút je dostupný iba pre samotnú triedu a jej potomkov. Notácia UML pre chránený atribút je znak "#".
Balíček alebo Implementácia Predpokladá, že atribút je zdieľaný, ale iba v rámci jeho balíka. Tento typ viditeľnosti nie je označený žiadnou špeciálnou ikonou.
Pomocou uzavretosti alebo bezpečnosti je možné predísť situácii, keď hodnotu atribútu menia všetky triedy systému. Namiesto toho bude logika zmeny atribútu obsiahnutá v rovnakej triede ako samotný atribút. Nastavenia viditeľnosti, ktoré nastavíte, ovplyvnia vygenerovaný kód.
4.4.2.6.Operácie
Operácie implementujú správanie spojené s triedou. Operácia má tri časti: názov, parametre a návratový typ.
Parametre sú argumenty prijaté operáciou ako vstup. Návratový typ sa vzťahuje na výsledok operácie.
Diagram tried môže zobrazovať názvy operácií aj názvy operácií spolu s ich parametrami a typom návratu. Ak chcete znížiť zaťaženie diagramu, je užitočné zobraziť iba názvy operácií na niektorých z nich a ich úplný podpis na iných.
V UML majú operácie nasledujúci zápis:
Názov operácie (argument: typ údajov argumentu, typ údajov argument2: typ údajov argument2,...): typ návratu
Na zváženie sú štyri rôzne druhy operácie:
Implementačné operácie;
Manažérske operácie;
Prístupové operácie;
Pomocné operácie.
Implementačné operácie
Operácie implementátora implementujú určité obchodné funkcie. Takéto operácie možno nájsť skúmaním interakčných diagramov. Tento typ diagramu sa zameriava na obchodné funkcie a každá správa v diagrame môže byť pravdepodobne namapovaná na implementačnú aktivitu.
Každá implementačná operácia musí byť ľahko sledovateľná podľa príslušnej požiadavky. To sa dosiahne v rôznych fázach simulácie. Aktivita je odvodená zo správy v interakčnom diagrame, správy pochádzajú z podrobného popisu toku udalostí, ktorý je vytvorený na základe prípadu použitia, a ten je vytvorený na základe požiadaviek. Schopnosť sledovať celý tento reťazec vám umožňuje zabezpečiť, aby bola každá požiadavka implementovaná v kóde a každý kúsok kódu implementoval nejakú požiadavku.
Kontrolné operácie
Manažérske operácie riadia vytváranie a ničenie objektov. Konštruktory a deštruktory tried patria do tejto kategórie.
Operácie prístupu
Atribúty sú zvyčajne súkromné alebo chránené. Iné triedy však niekedy potrebujú zobraziť alebo zmeniť svoje hodnoty. Na tento účel existujú prístupové operácie. Tento prístup umožňuje bezpečne zapuzdriť atribúty v rámci triedy, chrániť ich pred inými triedami, no stále k nim umožňuje kontrolovaný prístup. Je štandardné vytvárať operácie Get a Set pre každý atribút triedy.
Pomocné operácie
Pomocné operácie sú tie operácie triedy, ktoré sú potrebné na to, aby mohla vykonávať svoje povinnosti, ale o ktorých by ostatné triedy nemali nič vedieť. Ide o operácie privátnej a chránenej triedy.
Ak chcete identifikovať transakcie, postupujte takto:
1. Naučte sa sekvenčné diagramy a kooperatívne diagramy. Väčšina správ v týchto diagramoch sú implementačné operácie. Reflexné správy budú pomocnými operáciami.
2. Zvážte kontrolné operácie. Možno budete musieť pridať konštruktory a deštruktory.
3. Zvážte operácie prístupu. Pre každý atribút triedy, s ktorým budú musieť pracovať iné triedy, musíte vytvoriť operácie Get a Set.
4.4.2.7.Spojenia
Vzťah predstavuje sémantický vzťah medzi triedami. Dáva triede schopnosť učiť sa o atribútoch, operáciách a vzťahoch inej triedy. Inými slovami, aby jedna trieda mohla poslať správu druhej v sekvenčnom diagrame alebo kooperatívnom diagrame, musí medzi nimi existovať vzťah.
Existujú štyri typy vzťahov, ktoré možno vytvoriť medzi triedami: asociácie, závislosti, agregácie a zovšeobecnenia.
Komunikačná asociácia
Asociácia je sémantické spojenie medzi triedami. Sú nakreslené na diagrame tried ako obyčajná čiara.
Ryža. 10. Komunikačná asociácia
Asociácie môžu byť obojsmerné, ako v príklade, alebo jednosmerné. V UML sú obojsmerné asociácie nakreslené ako jednoduchá čiara bez šípok alebo so šípkami na oboch stranách. Jednosmerné priradenie má iba jednu šípku ukazujúcu jeho smer.
Smer asociácie možno určiť skúmaním sekvenčných diagramov a kooperatívnych diagramov. Ak všetky správy na nich odosiela len jedna trieda a prijíma ich iba iná trieda, ale nie naopak, medzi týmito triedami prebieha jednosmerná komunikácia. Ak je odoslaná aspoň jedna správa na rubová strana, združenie musí byť obojsmerné.
Asociácie môžu byť reflexívne. Reflexná asociácia predpokladá, že jedna inštancia triedy interaguje s inými inštanciami tej istej triedy.
Komunikačná závislosť
Vzťahy závislosti tiež odrážajú vzťahy medzi triedami, ale sú vždy jednosmerné a ukazujú, že jedna trieda závisí od definícií vykonaných v inej triede. Napríklad trieda A používa metódy triedy B. Potom, keď sa trieda B zmení, je potrebné vykonať zodpovedajúce zmeny v triede A.
Je znázornená závislosť bodkovaná čiara nakreslený medzi dvoma prvkami diagramu a prvok pripojený ku koncu šípky sa považuje za závislý od prvku pripojeného k začiatku tejto šípky.
Ryža. 11. Komunikačná závislosť
Pri generovaní kódu pre tieto triedy sa do nich nepridajú žiadne nové atribúty. Na podporu komunikácie sa však vytvoria operátori špecifickí pre daný jazyk.
Agregácia komunikácie
Agregácie sú užšou formou asociácie. Agregácia je spojenie medzi celkom a jeho časťou. Môžete mať napríklad triedu s názvom Auto, ako aj triedy ako Motor, Pneumatiky a triedy pre ostatné časti auta. Výsledkom je, že objekt triedy Car bude pozostávať z objektu triedy Engine, štyroch objektov pneumatiky atď. Agregácie sú vizualizované ako čiara s kosoštvorcom blízko triedy, čo je celé číslo:
Ryža. 11. Agregácia komunikácie
Okrem jednoduchej agregácie, UML zavádza silnejší typ agregácie nazývaný kompozícia. Podľa zloženia môže predmet-časť patriť len k jedinému celku a okrem toho sa životný cyklus častí spravidla zhoduje s cyklom celku: žijú a umierajú s ním. Akékoľvek vymazanie celku sa vzťahuje na jeho časti.
Toto kaskádové vymazanie sa často považuje za súčasť definície agregácie, ale vždy sa predpokladá, keď je multiplicita rolí 1..1; ak je napríklad potrebné vymazať Zákazníka, potom sa toto vymazanie musí vzťahovať aj na Objednávky (a následne na Objednávky).
UML diagram je špecializovaný grafický popisný jazyk určený na objektové modelovanie v oblasti vývoja rôznych softvér. Jazyk má široký profil a je otvoreným štandardom, ktorý používa rôzne grafické zápisy na vytvorenie abstraktného modelu systému. UML bol vytvorený s cieľom umožniť definíciu, vizualizáciu, dokumentáciu a návrh všetkých druhov softvérových systémov. Stojí za zmienku, že samotný diagram UML nie je programovací jazyk, ale poskytuje možnosť generovania samostatného kódu na jeho základe.
Prečo je to potrebné?
Použitie UML nekončí modelovaním všetkých druhov softvéru. Tento jazyk sa dnes aktívne používa aj na modelovanie rôznych obchodných procesov, návrh systému a tiež zobrazovanie organizačných štruktúr.
S UML môžu vývojári softvéru poskytnúť úplnú zhodu v grafickom zápise používanom na reprezentáciu bežných pojmov, ako sú: komponent, generický, trieda, správanie a agregácia. Vďaka tomu je dosiahnutá väčšia miera koncentrácie na architektúru a dizajn.
Za zmienku tiež stojí, že existuje niekoľko typov takýchto grafov.
Diagram triedy
Diagram tried UML je statický štrukturálny diagram určený na opis štruktúry systému, ako aj na zobrazenie atribútov, metód a závislostí medzi niekoľkými rôznymi triedami.
Za zmienku stojí skutočnosť, že existuje niekoľko pohľadov na konštrukciu takýchto diagramov v závislosti od toho, ako sa budú používať:
- Koncepčný. IN v tomto prípade Diagram tried UML popisuje model špecifickej oblasti a poskytuje iba triedy objektov aplikácie.
- Špecifické. Diagram sa používa v procese návrhu rôznych informačných systémov.
- Implementácia. Diagram tried zahŕňa všetky druhy tried, ktoré sa priamo používajú v programovom kóde.
Diagram komponentov
Diagram komponentov UML je úplne statický diagram štruktúry. Má demonštrovať členenie konkrétneho softvérového systému na rôzne štrukturálne komponenty, ako aj prepojenia medzi nimi. Diagram komponentov UML môže používať všetky druhy modelov, knižníc, súborov, balíkov, spustiteľných súborov a mnoho ďalších prvkov ako takých.
Diagram kompozitnej/zloženej štruktúry
Diagram kompozitnej/zloženej štruktúry UML je tiež diagramom statickej štruktúry, ale používa sa na zobrazenie vnútornej štruktúry tried. Ak je to možné, tento diagram môže demonštrovať aj interakciu prvkov nachádzajúcich sa vo vnútornej štruktúre triedy.
Ich podtypom je diagram spolupráce UML, ktorý sa používa na demonštráciu rolí, ako aj interakcie rôznych tried v rámci hraníc spolupráce. Sú celkom pohodlné, ak potrebujete modelovať dizajnové vzory.
Stojí za zmienku, že zobrazenie UML triedy a diagramu kompozitnej štruktúry je možné použiť súčasne.
Schéma nasadenia
Tento diagram sa používa na modelovanie bežiacich uzlov, ako aj všetkých druhov artefaktov, ktoré na nich boli nasadené. V UML 2 sú artefakty nasadené do rôznych uzlov, zatiaľ čo v prvej verzii boli nasadené iba komponenty. Diagram nasadenia UML sa teda používa predovšetkým pre druhú verziu.
Medzi artefaktom a komponentom, ktorý implementuje, sa vytvorí prejavová závislosť.
Diagram objektu
Toto zobrazenie vám umožňuje vidieť úplnú alebo čiastočnú snímku systému, ktorý sa vytvára v určitom časovom bode. Plne zobrazuje všetky inštancie tried konkrétneho systému s uvedením aktuálnych hodnôt ich parametrov, ako aj spojení medzi nimi.
Schéma balíka
Tento diagram má štrukturálny charakter a jeho hlavným obsahom sú všetky druhy balíkov, ako aj vzťahy medzi nimi. V tomto prípade neexistuje striktné rozdelenie medzi niekoľkými štrukturálnymi diagramami, v dôsledku čoho sa ich použitie najčastejšie nachádza len pre pohodlie a nemá žiadny sémantický význam. Stojí za zmienku, že rôzne prvky môžu poskytovať ďalšie diagramy UML (príklady: balíčky a samotné diagramy balíkov).
Ich použitie sa vykonáva s cieľom zabezpečiť organizáciu niekoľkých prvkov do skupín podľa určitého kritéria s cieľom zjednodušiť štruktúru, ako aj organizovať prácu s modelom daného systému.
Diagram aktivity
Diagram aktivity UML zobrazuje rozklad špecifickej aktivity na niekoľko častí. V tomto prípade je pojem „činnosť“ špecifikácia určitého vykonateľného správania vo forme paralelného, ako aj koordinovaného postupného vykonávania rôznych podriadených prvkov - vnorených typov činností a rôznych akcií, spojených tokmi vychádzajúcimi z výstupov. určitého uzla na vstupy iného.
Diagramy aktivít UML sa často používajú na modelovanie rôznych obchodných procesov, paralelných a sekvenčných výpočtov. Okrem iného simulujú všemožné technologické postupy.
Schéma stroja
Tento typ sa nazýva aj trochu inak – stavový diagram UML. Má prezentovaný konečný automat s jednoduchými a zloženými stavmi, ako aj prechodmi.
Stavový automat je špecifikácia postupnosti rôznych stavov, ktorými určitý objekt alebo interakcia prechádza v reakcii na určité udalosti vo svojom živote, ako aj reakciu objektu na takéto udalosti. Stavový stroj, ktorý používa stavový diagram UML, je pripojený k zdrojovému prvku a používa sa na definovanie správania jeho inštancií.
Takzvané dračie diagramy môžu byť použité ako analógy takýchto diagramov.
Diagramy prípadov použitia
Diagram prípadov použitia UML zobrazuje všetky vzťahy, ktoré vznikajú medzi aktérmi, ako aj rôzne možnosti použitie. Jeho hlavnou úlohou je poskytnúť plnohodnotný prostriedok, prostredníctvom ktorého môže zákazník, koncový používateľ alebo ktorýkoľvek vývojár spoločne diskutovať o správaní a funkčnosti určitého systému.
Ak sa v procese modelovania systému použije diagram prípadov použitia UML, analytik:
- Jasne oddeľte modelovaný systém od jeho prostredia.
- Identifikujte aktérov, spôsoby ich interakcie s týmto systémom, ako aj jeho očakávanú funkčnosť.
- Nastavte v slovníku ako oblasť predmetov rôzne pojmy, ktorých sa to týka podrobný popis funkčnosť tohto systému.
Ak je diagram použitia vypracovaný v UML, postup začína textovým popisom, ktorý sa získa pri práci so zákazníkom. Za zmienku stojí fakt, že v procese zostavovania modelu prípadu použitia sa úplne vynechajú rôzne nefunkčné požiadavky a vygeneruje sa pre ne samostatný dokument.
komunikácie
Komunikačný diagram, rovnako ako sekvenčný diagram UML, je tranzitívny, to znamená, že vyjadruje interakciu, ale zároveň ju demonštruje. rôznymi spôsobmi a ak je to potrebné, jeden môže byť prevedený na druhý s požadovaným stupňom presnosti.
Komunikačný diagram odráža interakcie, ktoré sa vyskytujú medzi rôznymi prvkami zloženej štruktúry, ako aj úlohy spolupráce. Hlavný rozdiel medzi ním a sekvenčným diagramom je v tom, že robí vzťahy medzi niekoľkými prvkami celkom explicitnými a nepoužíva čas ako samostatnú dimenziu.
Tento typ Obsahuje úplne bezplatný formát na usporiadanie viacerých objektov a spojení rovnakým spôsobom ako v diagrame objektov. Ak je potrebné zachovať poradie správ v tomto voľnom formáte, sú očíslované chronologicky. Čítanie tohto diagramu začína počiatočnou správou 1.0 a následne pokračuje v smere, v ktorom sa správy prenášajú z jedného objektu do druhého.
Z veľkej časti tieto diagramy zobrazujú presne tie isté informácie, ktoré nám poskytuje sekvenčný diagram, ale keďže používa iný spôsob prezentácie informácií, určité veci v jednom diagrame sa dajú identifikovať oveľa ľahšie ako v inom. Za zmienku tiež stojí, že komunikačný diagram jasnejšie ukazuje, s ktorými prvkami každý interaguje. samostatný prvok, zatiaľ čo sekvenčný diagram jasnejšie ukazuje, v akom poradí sa interakcie vyskytujú.
Sekvenčný diagram
Sekvenčný diagram UML zobrazuje interakcie medzi viacerými objektmi, ktoré sú usporiadané podľa času, kedy sa vyskytujú. Tento diagram zobrazuje časovo usporiadanú interakciu medzi niekoľkými objektmi. Zobrazuje najmä všetky objekty, ktoré sa zúčastňujú interakcie, ako aj kompletnú sekvenciu správ, ktoré si medzi sebou vymieňajú.
Hlavnými prvkami sú v tomto prípade označenia rôznych predmetov, ako aj zvislé čiary znázorňujúce plynutie času a obdĺžniky predstavujúce činnosť určitého predmetu alebo výkon nejakej funkcie.
Schéma spolupráce
Tento typ diagramu vám umožňuje demonštrovať interakcie medzi niekoľkými objektmi abstrahovať od postupnosti prenosu správ. Tento typ diagramu zobrazuje v kompaktnej forme absolútne všetky odoslané a prijaté správy určitého objektu, ako aj formáty týchto správ.
Pretože sekvenčné a komunikačné diagramy sú jednoducho rozdielne pohľady na tie isté postupy, Rational Rose poskytuje možnosť vytvárať komunikačný diagram zo sekvenčného diagramu alebo naopak a tiež ich úplne automaticky synchronizuje.
Diagramy prehľadu interakcií
Sú to diagramy UML, ktoré sú typom diagramu aktivít a zahŕňajú prvky sekvencie aj konštrukty toku riadenia.
Za zmienku stojí skutočnosť, že tento formát kombinuje Collaboration a Sequence diagram, ktoré poskytujú príležitosť zvážiť interakciu medzi niekoľkými objektmi v systéme, ktorý sa vytvára, z rôznych uhlov pohľadu.
Časový diagram
predstavuje alternatívna možnosť sekvenčný diagram, ktorý jasne demonštruje zmenu stavu pozdĺž životnej línie s určitým časovým rozsahom. Môže byť celkom užitočný v rôznych aplikáciách v reálnom čase.
Aké sú výhody?
Za zmienku stojí niekoľko výhod, ktoré odlišujú diagram použitia UML a ďalšie:
- Jazyk je objektovo orientovaný, v dôsledku čoho sú technológie na popis výsledkov analýzy a návrhu sémanticky blízke programovacím metódam vo všetkých druhoch moderných objektovo orientovaných jazykov.
- S pomocou tohto jazyka systém možno opísať takmer z akéhokoľvek možného uhla pohľadu a rôzne aspekty jeho správania sú opísané rovnakým spôsobom.
- Všetky diagramy sú pomerne ľahko čitateľné aj po pomerne rýchlom úvode do jeho syntaxe.
- UML umožňuje rozširovať a tiež zavádzať vlastné grafické a textové stereotypy, čo podporuje jeho využitie nielen v softvérovom inžinierstve.
- Jazyk sa stal pomerne rozšíreným a tiež sa pomerne aktívne rozvíja.
Nedostatky
Napriek tomu, že zostavovanie UML diagramov má veľa výhod, sú často kritizované za nasledujúce nevýhody:
- Redundancia. Vo veľkej väčšine prípadov kritici tvrdia, že UML je príliš veľké a zložité, čo je často neopodstatnené. Obsahuje pomerne veľa nadbytočných alebo prakticky zbytočných návrhov a schém a takáto kritika je najčastejšie namierená na druhú verziu, nie na prvú, pretože novšie revízie obsahujú viac kompromisov „navrhnutých výborom“.
- Rôzne nepresnosti v sémantike. Pretože UML je definovaný kombináciou seba, angličtiny a OCL, nemá tuhosť, ktorá je vlastná jazykom presne definovaným formálnymi popisnými technikami. V určitých situáciách si abstraktná syntax OCL, UML a angličtiny začne protirečiť, zatiaľ čo v iných prípadoch sú neúplné. Nepresnosť v špecifikácii samotného jazyka ovplyvňuje používateľov aj predajcov nástrojov, čo v konečnom dôsledku vedie k nekompatibilite nástrojov kvôli jedinečnému spôsobu zaobchádzania s rôznymi špecifikáciami.
- Problémy v procese implementácie a štúdia. Všetky vyššie uvedené problémy vytvárajú výzvy pri implementácii a učení UML, najmä keď manažment núti inžinierov používať ho bez predchádzajúcich znalostí.
- Kód odráža kód. Iný názor je, že nie sú dôležité krásne a atraktívne modely, ale samotné fungujúce systémy, teda kód je projekt. Podľa tohto názoru je potrebné viac sa rozvíjať efektívnym spôsobom softvér na písanie. UML je bežne cenené v prístupoch, ktoré zostavujú modely na regeneráciu spustiteľných resp zdrojový kód. Ale v skutočnosti to nemusí stačiť, pretože jazyku chýbajú Turingove vlastnosti úplnosti a každý vygenerovaný kód bude v konečnom dôsledku obmedzený na to, čo dokáže uhádnuť alebo určiť nástroj na interpretáciu UML.
- Nesúlad zaťaženia. Tento termín pochádza z teórie systémovej analýzy na určenie neschopnosti vstupu určitého systému vnímať iný výstup. Ako v každom štandardné systémy notácie, UML môže reprezentovať niektoré systémy efektívnejšie a stručnejšie ako iné. Vývojár sa teda viac prikláňa k tým riešeniam, ktoré sú pohodlnejšie v prelínaní všetkých silných stránok UML, ako aj iných programovacích jazykov. Tento problém je zrejmejší, ak vývojový jazyk nezodpovedá základným princípom objektovo orientovanej ortodoxie, to znamená, že sa nesnaží pracovať v súlade s princípmi OOP.
- Snaží sa byť univerzálny. UML je modelovací jazyk všeobecný účel, ktorý sa snaží zabezpečiť kompatibilitu s akýmkoľvek aktuálne existujúcim jazykom spracovania. V kontexte daného projektu, aby tím dizajnérov dosiahol konečný cieľ, je potrebné vybrať použiteľné vlastnosti daného jazyka. Okrem tohto možné spôsoby obmedzenia rozsahu UML v konkrétnej oblasti podliehajú formalizmu, ktorý nie je úplne formulovaný a ktorý je sám osebe predmetom kritiky.
Použitie tohto jazyka teda nie je relevantné vo všetkých situáciách.
Anotácia: Predmetom tohto kurzu je UML - jednotný modelovací jazyk. Predchádzajúca prednáška hovorila o tom, čo je UML, jeho histórii, účele, spôsoboch používania jazyka, štruktúre jeho definície, terminológii a zápise. Bolo poznamenané, že model UML je súbor diagramov. V tejto prednáške sa budeme zaoberať nasledujúcimi otázkami: prečo je potrebných niekoľko typov diagramov; typy diagramov; OOP a postupnosť diagramov
Predtým, než prejdeme k diskusii o hlavnom materiáli tejto prednášky, povedzme si, prečo vôbec potrebujeme nejaké diagramy zostavovať. Vývoj modelu akéhokoľvek systému (nielen softvérového) vždy predchádza jeho vytvoreniu alebo aktualizácii. Je to potrebné aspoň na to, aby sme si jasnejšie predstavili riešený problém. Dobre premyslené modely sú veľmi dôležité ako pre interakciu v rámci vývojového tímu, tak aj pre vzájomné porozumenie so zákazníkom. V konečnom dôsledku to zaisťuje, že návrh je „architektonicky konzistentný“ pred implementáciou do kódu.
Vytvárame modely zložitých systémov, pretože ich nemôžeme úplne opísať, „pozrieť sa na ne“. Zdôrazňujeme preto iba vlastnosti systému, ktoré sú nevyhnutné pre konkrétnu úlohu a zostavujeme jeho model, ktorý tieto vlastnosti zobrazuje. Metóda objektovo orientovanej analýzy nám umožňuje popísať skutočné komplexné systémy tým najvhodnejším spôsobom. Ale ako sa zložitosť systémov zvyšuje, vzniká potreba dobrej modelovacej technológie. Ako sme už povedali v predchádzajúcej prednáške, jednotný modelovací jazyk(Unified Modeling Language, UML), čo je grafický jazyk na špecifikovanie, vizualizáciu, navrhovanie a dokumentovanie systémov. Pomocou UML môžete rozvíjať detailný model vytvoreného systému, odrážajúceho nielen jeho koncepciu, ale aj špecifické črty jeho implementácie. V rámci modelu UML sa všetky predstavy o systéme zaznamenávajú vo forme špeciálnych grafických štruktúr nazývaných diagramy.
Poznámka. Budeme brať do úvahy nie všetky, ale iba niektoré typy diagramov. V tejto prednáške sa napríklad nezaoberá diagram komponentov, čo je len stručný prehľad typov diagramov. Počet typov grafov pre konkrétny model aplikácie nie sú nijako obmedzené. Pre jednoduché aplikácie nie je potrebné vytvárať diagramy všetkých typov bez výnimky. Niektoré z nich môžu jednoducho chýbať a táto skutočnosť sa nebude považovať za chybu. Je dôležité pochopiť, že dostupnosť diagramov určitého typu závisí od špecifík konkrétneho projektu. Informácie o iných typoch diagramov (tu nie sú diskutované) nájdete v štandarde UML.
Prečo potrebujete niekoľko typov diagramov
Najprv si definujme terminológiu. V úvode tejto prednášky sme opakovane použili pojmy systém, model a diagram. Autor je presvedčený, že každý z nás intuitívne chápe význam týchto pojmov, ale aby to bolo úplne jasné, pozrime sa ešte raz do slovníka a prečítajte si nasledovné:
Systém- súbor vzájomne prepojených riadených subsystémov spojených spoločným účelom prevádzky.
Áno, nie veľmi informatívne. Čo je potom subsystém? Aby sme objasnili situáciu, obráťme sa na klasiku:
Systém sa vzťahuje na súbor podsystémov organizovaných na dosiahnutie konkrétneho cieľa a opísaných pomocou súboru modelov, prípadne z rôznych uhlov pohľadu.
No nedá sa nič robiť, budete musieť hľadať definíciu podsystému. Aj to sa tam píše subsystému je súbor prvkov, z ktorých niektoré špecifikujú správanie iných prvkov. Ian Sommerville vysvetľuje tento koncept takto:
Subsystém je systém, ktorého fungovanie nezávisí od služieb iných subsystémov. Softvérový systém je štruktúrovaný ako súbor relatívne nezávislých subsystémov. Interakcie medzi subsystémami sú tiež definované.
Tiež to nie je veľmi jasné, ale je to lepšie. V „ľudskom“ jazyku je systém reprezentovaný ako súbor jednoduchších entít, ktoré sú relatívne sebestačné. Dá sa to porovnať s tým, ako v procese vývoja programu vytvárame GUI zo štandardných „kociek“ - vizuálnych komponentov, alebo ako je aj samotný text programu rozdelený do modulov, ktoré obsahujú podprogramy, zjednotené funkcionalitou a dajú sa opätovne použiť v ďalších programoch.
Rozumieme konceptu systému. Počas procesu návrhu sa berie do úvahy systém z rôznych uhlov pohľadu pomocou modelov, ktorých rôzne zobrazenia sa objavujú vo forme diagramov. Čitateľ môže mať opäť otázky o význame pojmov modelov A diagramy. Myslíme si, že je to krásna, ale nie veľmi jasná definícia modely ako sémanticky uzavretá abstrakcia systému Je nepravdepodobné, že by sa situácia objasnila, preto sa pokúsime vysvetliť „vlastnými slovami“.
Model- ide o určitý (materiálny alebo nehmotný) objekt, ktorý zobrazuje len najvýznamnejšie charakteristiky systému pre danú úlohu. Modely sú rôzne - materiálne a nehmotné, umelé a prírodné, dekoratívne a matematické...
Uveďme si pár príkladov. Nám všetkým známe plastové autíčka, s ktorými sme sa v detstve s takým vzrušením hrali, nie sú ničím iným materiál umelý dekoratívny model skutočného auta. Takéto „auto“ samozrejme nemá motor, neplníme jeho nádrž benzínom a prevodovka nefunguje (v skutočnosti neexistuje žiadna prevodovka), ale ako model táto hračka úplne plní svoje funkcie. : dáva dieťaťu predstavu o aute, pretože jeho charakteristické črty sú prítomnosť štyroch kolies, karosérie, dverí, okien, schopnosť riadiť atď.
V lekárskom výskume testovanie na zvieratách často predchádza klinickým testom na ľuďoch. V tomto prípade zviera pôsobí ako materiál prírodnýľudské modely.
Rovnica zobrazená vyššie je tiež model, ale je to matematický model a opisuje pohyb hmotného bodu pod vplyvom gravitácie.
Zostáva len povedať, čo je diagram. Diagram je grafické znázornenie mnohých prvkov. Typicky sa zobrazuje ako graf s vrcholmi (entitami) a hranami (vzťahmi). Existuje veľa príkladov diagramov. Ide o blokovú schému, ktorá je nám všetkým známa zo školských rokov, inštalačné schémy pre rôzne zariadenia, ktoré môžeme vidieť v používateľských príručkách, a strom súborov a adresárov na disku, ktorý môžeme vidieť spustením príkazu tree v Konzola Windows a oveľa, oveľa viac iného. IN každodenný život diagramy nás obklopujú zo všetkých strán, pretože kresby vnímame ľahšie ako text...
Ale vráťme sa k dizajnu softvéru (a ďalšiemu). V tomto odvetví s Diagramy možno použiť na vizualizáciu systému z rôznych perspektív. Jeden z diagramov môže napríklad popisovať interakciu užívateľa so systémom, ďalší môže popisovať zmenu stavov systému počas jeho prevádzky, tretí môže popisovať interakciu prvkov systému medzi sebou atď. Komplexný systém môžu a mali by byť reprezentované ako súbor malých a takmer nezávislých modelov - diagramov, pričom žiadny z nich nestačí na popis systému a získanie úplného obrazu o ňom, pretože každý z nich sa zameriava na špecifický aspekt fungovania systému a vyjadruje iný úroveň abstrakcie. Inými slovami, každý model zodpovedá určitému konkrétnemu pohľadu na navrhnutý systém.
Napriek tomu, že v predchádzajúcom odseku sme s pojmom model zaobchádzali veľmi voľne, treba chápať, že v kontexte vyššie uvedených definícií žiadny individuálny diagram nie je model. Diagramy sú len prostriedkom na vizualizáciu modelu a tieto dva pojmy je potrebné rozlišovať. Iba súbor diagramov tvorí model systému a popisuje to najúplnejšie, ale nie iba jeden diagram vytrhnutý z kontextu.
Typy grafov
Definícia UML 1.5 dvanásť typov grafov, rozdelené do troch skupín:
- štyri typy diagramov predstavujú statickú štruktúru aplikácie;
- päť predstavuje behaviorálne aspekty systému;
- tri predstavujú fyzikálne aspekty fungovania systému (implementačné diagramy).
Aktuálna verzia UML 2.1 neurobila príliš veľa zmien. Diagramy sa mierne zmenili vo vzhľade (objavili sa rámy a iné vizuálne vylepšenia), mierne sa zlepšil zápis a niektoré diagramy dostali nové názvy.
Presný počet však kanonické diagramy pre nás je to absolútne nepodstatné, keďže nebudeme brať do úvahy všetky, ale len niektoré - z toho dôvodu, že počet typov diagramov pre konkrétny model konkrétnej aplikácie nie je striktne stanovený. Pre jednoduché aplikácie nie je potrebné zostavovať každý jednotlivý diagram. Napríklad pre lokálnu aplikáciu nie je potrebné zostaviť diagram nasadenia. Je dôležité pochopiť, že zoznam diagramov závisí od špecifík vyvíjaného projektu a určuje ho samotný vývojár. Ak by zvedavý čitateľ predsa len chcel vedieť o všetkých diagramoch UML, odkážeme ho na štandard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Pripomeňme, že účelom tohto kurzu nie je popísať absolútne všetky možnosti UML, ale iba predstaviť tento jazyk a poskytnúť prvotnú predstavu o tejto technológii.
Stručne sa teda pozrieme na také typy diagramov, ako sú:
- diagram prípadu použitia;
- diagram tried;
- objektový diagram;
- sekvenčný diagram;
- interakčný diagram;
- stavový diagram;
- diagram činnosti;
- diagram nasadenia.
O niektorých z týchto diagramov si povieme podrobnejšie v budúcich prednáškach. Zatiaľ sa nezameriame na detaily, ale za cieľ si dáme naučiť čitateľa aspoň vizuálne rozlišovať medzi typmi diagramov a poskytnúť mu prvotnú predstavu o účele hlavných typov diagramov. Tak začnime.
Schéma prípadu použitia
Akékoľvek (vrátane softvérových) systémov sú navrhnuté s ohľadom na skutočnosť, že počas ich prevádzky budú používané ľuďmi a/alebo interagujú s inými systémami. Entity, s ktorými systém počas svojej činnosti interaguje, sa nazývajú herci a každý aktér očakáva, že sa systém bude správať presne definovaným a predvídateľným spôsobom. Skúsme dať prísnejšiu definíciu ektora. K tomu nám poslúži nádherný vizuálny slovník pre UML Zicom Mentor:
Ector (herec)- ide o súbor logicky súvisiacich rolí vykonávaných pri interakcii s precedensmi alebo entitami (systém, subsystém alebo trieda). Aktérom môže byť osoba alebo iný systém, subsystém alebo trieda, ktorá predstavuje niečo mimo entity.
Graficky je ektor znázornený buď " malý muž“, podobné tým, ktoré sme kreslili ako deti, zobrazujúce členov našej rodiny, príp symbol triedy so zodpovedajúcim stereotypom ako je znázornené na obrázku. Obe formy zobrazenia majú rovnaký význam a možno ich použiť v diagramoch. „stereotypná“ forma sa častejšie používa na znázornenie systémových aktérov alebo v prípadoch, keď má aktér vlastnosti a je potrebné ich zobraziť (obr. 2.1).
Pozorný čitateľ sa môže okamžite opýtať: prečo herec a nie herec? Súhlasíme, slovo „ektor“ je trochu drsné pre uši Rusov. Dôvod, prečo to hovoríme, je jednoduchý – ector je odvodený od slova akcie, čo v preklade znamená akcie. Doslovný preklad slova „ector“ je charakter- príliš dlhé a nepohodlné na použitie. Preto budeme aj naďalej hovoriť týmto spôsobom.
Ryža. 2.1.
Ten istý pozorný čitateľ si mohol všimnúť slovo „precedens“, ktoré prebleskovalo ektorovou definíciou. čo je to? Táto otázka nás bude zaujímať ešte viac, ak si spomenieme, o čom teraz hovoríme diagram prípadu použitia. takže,
Prípad použitia- popis samostatného aspektu správania systému z pohľadu používateľa (Butch).
Definícia je celkom jasná a komplexná, ale pomocou nej sa dá ďalej objasniť Zicom Mentor"om:
Prípad použitia- popis súboru sekvenčných udalostí (vrátane možností) vykonávaných systémom, ktoré vedú k výsledku pozorovanému aktérom. Prípad použitia predstavuje správanie entity, popisuje interakciu medzi aktérmi a systémom. Prípad použitia neukazuje „ako“ sa dosiahne určitý výsledok, iba „čo“ sa dosiahne.
Precedenty sú označené veľmi jednoduchým spôsobom - vo forme elipsy, vo vnútri ktorej je uvedený jej názov. Prípady použitia a aktéri sú prepojení pomocou línií. Často je na jednom konci čiary nakreslená postava. 2.3
UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnuté tak, aby podporovalo proces modelovania softvéru založeného na prístupe OO, organizovalo vzťah koncepčných a programových konceptov a odrážalo problémy škálovania zložitých systémov. Modely UML sa používajú vo všetkých fázach životného cyklu softvéru, od obchodnej analýzy až po údržbu systému. Rôzne organizácie môžu používať UML, ako uznajú za vhodné, v závislosti od ich problémových oblastí a technológií, ktoré používajú.
Stručná história UML
Do polovice 90. rokov navrhli rôzni autori niekoľko desiatok metód OO modelovania, z ktorých každá používala svoj vlastný grafický zápis. Navyše každá z týchto metód mala svoje vlastné silné stránky, ale neumožnili nám postaviť dostatočne ucelený model PS, ukázať ho „zo všetkých strán“, teda všetky potrebné projekcie (pozri článok 1). Okrem toho nedostatok štandardu modelovania OO sťažoval vývojárom výber najvhodnejšej metódy, čo bránilo širokému prijatiu prístupu OO k vývoju softvéru.
Na žiadosť Object Management Group (OMG), organizácie zodpovednej za prijímanie štandardov v oblasti objektových technológií a databáz, naliehavý problém zjednotenia a štandardizácie vyriešili autori troch najpopulárnejších metód OO - G Butch, D. Rambo a A. Jacobson, ktorí spoločnými silami vytvorili verziu UML 1.1, schválenú OMG v roku 1997 ako štandard.
UML je jazyk
Akýkoľvek jazyk pozostáva zo slovnej zásoby a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takto sú štruktúrované najmä programovacie jazyky, ako napríklad UML. Jeho charakteristickým znakom je, že jazykový slovník tvoria grafické prvky. Každý grafický symbol má špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jasne pochopený iným, a tiež softvér, interpretácia UML. Z tohto konkrétne vyplýva, že softvérový model prezentovaný v UML možno automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda ak existuje dobrý nástroj na vizuálne modelovanie, ktorý podporuje UML, postavili model, dostaneme aj polotovar programový kód, zodpovedajúce tomuto modelu.
Treba zdôrazniť, že UML je jazyk, nie metóda. Vysvetľuje, z akých prvkov vytvárať modely a ako ich čítať, ale nehovorí nič o tom, ktoré modely by sa mali vyvíjať a v akých prípadoch. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja softvéru. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v nasledujúcich článkoch.
Slovník UML
Model je znázornený vo forme entít a vzťahov medzi nimi, ktoré sú znázornené v diagramoch.
entity sú abstrakcie, ktoré sú hlavnými prvkami modelov. Existujú štyri typy entít – štrukturálne (trieda, rozhranie, komponent, prípad použitia, spolupráca, uzol), behaviorálne (interakcia, stav), zoskupovanie (balíky) a anotácia (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne prediskutované pri štúdiu diagramov.
Vzťah ukazujú rôzne prepojenia medzi entitami. UML definuje nasledujúce typy vzťahov:
- Závislosť ukazuje také prepojenie dvoch entít, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou od závislej entity k nezávislej.
- asociácie je štrukturálny vzťah ukazujúci, že objekty jednej entity súvisia s objektmi inej entity. Graficky je asociácia znázornená ako čiara spájajúca pridružené entity. Asociácie slúžia na navigáciu medzi objektmi. Napríklad spojenie medzi triedami „Objednávka“ a „Produkt“ môže byť použité na nájdenie všetkých produktov špecifikovaných v konkrétnej objednávke na jednej strane alebo na nájdenie všetkých objednávok, ktoré obsahujú tento produkt, na strane druhej. Je jasné, že príslušné programy musia implementovať mechanizmus, ktorý takúto navigáciu zabezpečí. Ak je potrebná navigácia iba jedným smerom, je to označené šípkou na konci priradenia. Špeciálnym prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený diamantom na konci blízko esencie-celku.
- Zovšeobecnenie je vzťah medzi nadradenou entitou a podriadenou entitou. Tento vzťah v podstate odráža vlastnosť dedičnosti pre triedy a objekty. Zovšeobecnenie je znázornené ako čiara končiaca trojuholníkom smerujúcim k rodičovskej entite. Dieťa zdedí štruktúru (atribúty) a správanie (metódy) rodiča, no zároveň môže mať nové prvky štruktúry a nové metódy. UML umožňuje viacnásobné dedičstvo, keď entita súvisí s viac ako jednou nadradenou entitou.
- Implementácia– vzťah medzi entitou, ktorá definuje špecifikáciu správania (interface) s entitou, ktorá definuje implementáciu tohto správania (trieda, komponent). Tento vzťah sa bežne používa pri modelovaní komponentov a bude podrobnejšie popísaný v nasledujúcich článkoch.
Diagramy. UML poskytuje nasledujúce diagramy:
- Diagramy popisujúce správanie systému:
- Stavové diagramy
- diagramy aktivít,
- Diagramy objektov,
- sekvenčné diagramy,
- Diagramy spolupráce;
- Diagramy popisujúce fyzickú implementáciu systému:
- Schémy komponentov;
- Schémy nasadenia.
Zobrazenie ovládania modelu. Balíčky.
Už sme povedali, že na to, aby bol model pre ľudí dobre pochopený, je potrebné ho hierarchicky usporiadať, pričom na každej úrovni hierarchie zostane malý počet entít. UML obsahuje prostriedky na organizáciu hierarchickej reprezentácie modelu – balíkov. Každý model pozostáva zo sady balíkov, ktoré môžu obsahovať triedy, prípady použitia a iné entity a diagramy. Balík môže obsahovať ďalšie balíky, čo umožňuje vytváranie hierarchií. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balíček je vyobrazený ako obdĺžnik so záložkou.
Čo poskytuje UML.
- hierarchický popis komplexný systém prideľovaním balíkov;
- formalizácia funkčných požiadaviek na systém pomocou aparátu prípadov použitia;
- spresnenie systémových požiadaviek vytvorením diagramov činností a scenárov;
- identifikácia dátových tried a vytvorenie koncepčného dátového modelu vo forme diagramov tried;
- identifikácia tried, ktoré popisujú užívateľské rozhranie a vytvorenie schémy navigácie na obrazovke;
- opis procesov interakcie medzi objektmi pri vykonávaní systémových funkcií;
- popis správania sa objektu vo forme diagramov aktivít a stavov;
- popis softvérových komponentov a ich interakcia prostredníctvom rozhraní;
- popis fyzickej architektúry systému.
A posledná vec...
Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom softvérovom modelovaní bez nástrojov na vizuálne modelovanie. Takéto nástroje vám umožňujú rýchlo prezentovať diagramy na obrazovke, dokumentovať ich, vytvárať šablóny programového kódu v rôznych programovacích jazykoch OO a vytvárať databázové schémy. Väčšina z nich obsahuje možnosť reengineeringu programových kódov - obnovenie určitých projekcií modelu PS automatická analýza zdrojové kódy programov, čo je veľmi dôležité na zabezpečenie súladu medzi modelom a kódmi a pri navrhovaní systémov, ktoré dedia funkčnosť predchádzajúcich systémov.
UML (Unified Modeling Language) je grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru. UML je všeobecný jazyk, otvorený štandard, ktorý používa grafickú notáciu na vytvorenie abstraktného modelu systému, nazývaného model UML. UML bol vytvorený s cieľom definovať, vizualizovať, navrhovať a dokumentovať predovšetkým softvérové systémy. UML nie je programovací jazyk, ale generovanie kódu je možné v prostriedkoch na vykonávanie modelov UML ako interpretovaného kódu. Wikipedia
Komerčné produkty
Microsoft Visio
Typ: komerčný softvér
Populárny softvérový produkt od spoločnosti Microsoft, ktorý vám umožňuje kresliť bohaté diagramy vrátane UML:
Od verzie 2010 bolo možné publikovať diagramy na webe (SharePoint + Visio Services):
Prehliadač Visio- voľný program, ktorá vám umožňuje zobraziť predtým vytvorené diagramy Visia. Môžete si ho stiahnuť na %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%20Expres%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-%20Modeling,%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%20Sekvencia%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%20Použití%20prípad%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ácia%20a%20Modelovanie%20Funkcia%20Pack%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%20vrstva%20diagramy%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%20vrstva%20diagramy %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Vizualizácia%20a%20Modelovanie%20Funkcia%20Pack%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
možnosti:
- Schéma prípadu použitia;
- Diagram rozmiestnenia (topologické diagramy);
- stavový diagram;
- Diagram aktivity;
- Interakčný diagram;
- Sekvenčný diagram;
- Diagram spolupráce;
- diagram tried;
- Schéma komponentov.
Snímky obrazovky:
Open source programy
StarUML
možnosti:
- podpora UML 2.0
- MDA (Model Driven Architecture)
- Plug-in Architecture (môžete písať v jazykoch kompatibilných s COM: C++, Delphi, C#, VB, ...)
StarUML je napísaný hlavne v Delphi, ale komponenty je možné písať aj v iných jazykoch, napríklad C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Nižšie sú uvedené niektoré snímky obrazovky.
Diagram triedy:
Schéma prípadu použitia:
ArgoUML
Podporované grafy:
- triedy
- štátu
- Prípad použitia
- Aktivita
- Spolupráca
- Nasadenie
- Sekvencia
možnosti:
- Podporuje deväť diagramov UML 1.4
- Nezávislé od platformy (Java 5+)
- Štandardný metamodel UML 1.4
- podpora XMI
- Export do GIF, PNG, PS, EPS, PGML a SVG
- Jazyky: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- podpora OCL
- Vpred, spätné inžinierstvo
Snímka obrazovky:
