Akýmsi uml diagramom sú aktivity. Modelovanie na UML. Všeobecné diagramy. Hlavné menu programu

Myslím, že každý v detstve počul také príslovie ako " Sedemkrát meraj, raz rež". V programovaní je to to isté. Vždy je lepšie si implementáciu premyslieť skôr, ako strávite čas jej vykonávaním. Často musíte počas implementácie vytvárať triedy, vymýšľať ich interakciu. A často môže pomôcť pri riešení problém tým najsprávnejším spôsobom. Tu pomáhame UML.

čo je UML?

Ak sa pozriete na obrázky vo vyhľadávačoch, je to jasné UML- toto je niečo o schémach, šípkach a štvorcoch. Dôležité je, že UML sa prekladá ako Jednotný modelovací jazyk. Dôležité je tu slovo Unified. To znamená, že naše obrázky pochopíme nielen my, ale aj ostatní, ktorí poznajú UML. Ukazuje sa, že je to taký medzinárodný jazyk na kreslenie diagramov.

Ako hovorí Wikipedia

UML je grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru, modelovania obchodných procesov, systémového inžinierstva a mapovania organizačných štruktúr.

Najzaujímavejšia vec, o ktorej nie každý premýšľa alebo háda, je, že UML má špecifikácie. Okrem toho existuje dokonca špecifikácia UML2. Viac informácií o špecifikácii nájdete na webovej stránke Object Management Group. V skutočnosti sa táto skupina zaoberá vývojom špecifikácií UML. Je tiež zaujímavé, že UML sa neobmedzuje len na popis štruktúry tried. Existuje mnoho typov UML diagramov. Stručný popis typov UML diagramov je možné vidieť na tej istej Wikipédii: UML diagramy alebo vo videu Timura Batyršinova Prehľad diagramov UML. UML je tiež široko používaný pri popise rôznych procesov, napríklad tu: Single sign-on using JWT. Keď sa vrátime k používaniu diagramov tried UML, stojí za zmienku kniha Head First: Design Patterns, v ktorej sú vzory ilustrované tými istými diagramami UML. Ukazuje sa, že UML sa skutočne používa. A ukazuje sa, že poznať a pochopiť jeho aplikáciu je celkom užitočná zručnosť.

Aplikácia

Pozrime sa, ako môžete pracovať s týmto UML z IDE. Ako IDE vezmite IntelliJ nápad. V prípade použitia IntelliJ Idea Ultimate, potom budeme mať plugin nainštalovaný "po vybalení" Podpora UML". Umožňuje vám automaticky generovať krásne diagramy tried. Napríklad cez Ctrl + N alebo položku ponuky "Navigovať" -> "Trieda" prejdite do triedy ArrayList. Teraz cez kontextové menu podľa názvu triedy vyberte "Diagram" -> "Zobraziť vyskakovacie okno diagramu". Výsledkom je krásny graf:

Čo ak však chcete kresliť sami seba, a dokonca ani neexistuje konečná verzia Idea? Ak používame IntelliJ Idea Community Edition, nemáme inú možnosť. Aby ste to dosiahli, musíte pochopiť, ako takáto schéma UML funguje. Najprv musíme nainštalovať Graphviz. Ide o sadu nástrojov na vizualizáciu grafov. Používa ho plugin, ktorý budeme používať. Po inštalácii je potrebné pridať adresár kôš z nainštalovaného adresára grafviz na premennú prostredia PATH. Potom v IntelliJ Idea vyberte z ponuky Súbor -> Nastavenia. V okne „Nastavenia“ vyberte kategóriu „Pluginy“, kliknite na tlačidlo „Prehľadávať repozitáre“ a nainštalujte integračný doplnok PlantUML. Prečo je tento taký dobrý PlantUML? Používa jazyk popisu grafov s názvom " bodka“ a to mu umožňuje byť univerzálnejší, pretože tento jazyk používa nielen PlantUML. Navyše všetko, čo budeme robiť nižšie, je možné vykonať nielen v IDE, ale aj v online službe planttext.com. Po nainštalovaní Plugin PlantUML, budeme môcť vytvárať UML diagramy cez „Súbor“ -> „Nový". Vytvorme si diagram typu „UML trieda". Počas toho sa automaticky vygeneruje šablóna s príkladom. Vymažeme jej obsah a vytvorte si vlastný, vyzbrojený článkom od Habra: Vzťahy tried - od UML po kód... A aby ste pochopili, ako to v texte znázorniť, vezmime si príručku PlantUML: plantuml class-diagram... V ňom na úplne na začiatku je znak s tým, ako opísať vzťahy:

O samotných spojeniach môžeme ešte nakuknúť tu: "Vzťahy medzi triedami v UML. Príklady". Na základe týchto materiálov začnime vytvárať náš UML diagram. Pridajte nasledujúci obsah popisujúci dve triedy: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Ak chcete vidieť výsledok v Idea, zvoľte "View" -> "Tool Windows" -> "PlantUML". Dostaneme len dva štvorce označujúce triedy. Ako vieme, obe tieto triedy implementujú rozhranie List. Tento vzťah tried sa nazýva - implementácia (realizácia). Na znázornenie takéhoto vzťahu sa používa šípka s bodkovanou čiarou. Nakreslíme to: rozhranie Zoznam Zoznam< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о súkromný balík element pole: ~ Object elementData Teraz chceme ukázať, že ArrayList obsahuje nejaké objekty. V tomto prípade bude typ pripojenia - agregácia(agregácia). Agregátom je v tomto prípade ArrayList , pretože obsahuje iné predmety. Vyberáme agregáciu, pretože objekty v zozname môžu žiť bez zoznamu: nie sú jeho integrálnou súčasťou. Ich životnosť nie je viazaná na životnosť zoznamu. Jednotka z latinčiny sa prekladá ako „zhromaždené“, teda niečo, čo sa z niečoho skladá. Napríklad v živote existuje čerpacia jednotka, ktorá pozostáva z čerpadla a motora. Samotnú jednotku je možné rozobrať a ponechať niektoré jej komponenty. Napríklad predať alebo vložiť inú jednotku. Takže je na zozname. A to je vyjadrené vo forme prázdneho kosoštvorca na jednotke a súvislej čiary. Povedzme to takto: trieda Object ( ) ArrayList o- Object Teraz chceme ukázať, že na rozdiel od ArrayList trieda LinkedList obsahuje Node - kontajnery, ktoré odkazujú na uložené dáta. V tomto prípade sú uzly súčasťou samotného LinkedList a nemôžu žiť oddelene. Node nie je priamo uložený obsah, ale obsahuje iba odkaz naň. Napríklad, keď pridáme riadok do LinkedList, pridáme nový Node, ktorý obsahuje prepojenie na daný riadok, ako aj prepojenie na predchádzajúci a nasledujúci Node . Tento typ spojenia sa nazýva zloženie(zloženie). Na zobrazenie kompozitu (ktorý sa skladá z častí) sa nakreslí vyplnený robic, vedie k nemu súvislá čiara. Teraz to napíšme ako textové zobrazenie odkazu: class Node ( ) LinkedList * -- Node A teraz sa musíme naučiť, ako zobraziť ďalší dôležitý typ odkazu - závislosť(vzťah závislosti). Používa sa, keď jedna trieda používa inú, pričom trieda neobsahuje použitú triedu a nie je jej nástupcom. Napríklad LinkedList a ArrayList môžu vytvoriť ListIterator . Ukážme to ako bodkované šípky: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Môžete detailovať toľko, koľko potrebujete. Všetky označenia sú uvedené tu: "PlantUML - Class Diagram". Navyše v kreslení takejto schémy nie je nič nadprirodzené a pri práci na svojich úlohách ju môžete rýchlo nakresliť ručne. To rozvinie zručnosti premýšľať nad aplikačnou architektúrou a pomôže identifikovať nedostatky v štruktúre tried už na začiatku, a nie až potom, čo ste už strávili deň implementáciou nesprávneho modelu. Myslím, že je to dobrý dôvod to skúsiť?)

automatizácia

Existujú rôzne spôsoby automatického generovania diagramov PlantUML. Napríklad v nápady Existuje plugin SketchIT, ale nekreslí ich správne. Napríklad implementácia rozhraní je nakreslená nesprávne (zobrazuje sa ako dedičnosť). Online sú tiež príklady, ako to začleniť do životného cyklu zostavenia vášho projektu. Povedzme pre Maven existuje príklad s použitím uml-java-docklet . Aby sme ukázali, ako sa to robí, použime Maven Archetype na rýchle vytvorenie Maven projektu. Vykonajme príkaz: mvn archetype:generate Na otázku výberu filtra ( Vyberte číslo alebo použite filter) ponechajte predvolené nastavenie jednoduchým stlačením klávesu Enter. Vždy to bude" maven-archetype-quickstart". Vyberieme najnovšiu verziu. Potom odpovedzte na otázky a dokončite vytvorenie projektu:

Keďže Maven nie je stredobodom tohto článku, odpovede na vaše otázky o Mavene nájdete v Maven Users Center . Vo vygenerovanom projekte otvorte súbor s popisom projektu na úpravu, pom.xml. Skopírujeme do nej obsah z popisu inštalácie uml-java-docklet. Artefakt použitý v popise sa nepodarilo nájsť v úložisku Maven Central. Mne to ale fungovalo s týmto: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . To znamená, že v tom popise stačí nahradiť groupId s " info.predné svetlo"na" com.chfourie"a vložte verziu" 1.0.0 ". Potom môžeme spustiť v adresári, kde sa súbor nachádza pom.xml tieto príkazy sú: mvn clean install a mvn javadoc:javadoc . Ak teraz otvoríme vygenerovanú dokumentáciu (cieľ prieskumníka\site\apidocs\index.html), uvidíme diagramy UML. Mimochodom, implementácia je tu už zobrazená správne)

Záver

Ako vidíte, UML vám umožňuje vizualizovať štruktúru vašej aplikácie. UML sa tiež neobmedzuje len na to. Pomocou UML môžete opísať rôzne procesy vo vašej spoločnosti alebo opísať obchodný proces, v rámci ktorého funguje funkcia, ktorú napíšete. Do akej miery je UML pre vás osobne užitočné, je len na vás, no aj tak bude užitočné nájsť si čas a zoznámiť sa s ním podrobnejšie. #Viacheslav Ruská verzia tohto príspevku: UML diagram Java na CodeGym

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnutý tak, aby podporoval proces modelovania PS založený na prístupe OO, organizoval vzťah medzi konceptuálnymi a programovými konceptmi a reflektoval 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 vlastným spôsobom, v závislosti od ich problémových oblastí a použitých technológií.

Stručná história UML

Do polovice 90. rokov 20. storočia bolo navrhnutých niekoľko desiatok metód modelovania OO rôznymi autormi, z ktorých každý používal svoj vlastný grafický zápis. Každá z týchto metód mala zároveň svoje silné stránky, ale neumožňovala 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 absencia štandardu OO modelovania sťažovala vývojárom výber najvhodnejšej metódy, čo bránilo širokému používaniu OO prístupu 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 vyriešili naliehavý problém unifikácie a štandardizácie autori troch najpopulárnejších metód OO - G. Booch , D. Rambo a A. Jacobson, ktorí spojením úsilia vytvorili UML verziu 1.1, schválenú OMG v roku 1997 ako štandard.

UML je jazyk

Každý jazyk pozostáva zo slovníka a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takže sú usporiadané najmä programovacie jazyky, ako je UML. Jeho charakteristickým znakom je, že slovnú zásobu jazyka tvoria grafické prvky. Každý grafický symbol má špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jednoznačne pochopený iným, ako aj nástrojom, ktorý interpretuje UML. Z toho predovšetkým vyplýva, že model PS prezentovaný v UML je možné automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda pomocou dobrého nástroja na vizuálne modelovanie, ktorý podporuje UML. zostavením modelu dostaneme aj prázdny kód programu zodpovedajúci 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 a v akých prípadoch by sa mali rozvíjať. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja PS. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v ďalších článkoch.

UML slovník

Model je znázornený vo forme entít a vzťahov medzi nimi, ktoré sú znázornené na diagramoch.

Esencie 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 anotačné (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne diskutované pri štúdiu diagramov.

Vzťahy ukazujú rôzne vzťahy medzi entitami. V UML sú definované nasledujúce typy vzťahov:

• Závislosť ukazuje taký vzťah medzi dvoma entitami, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou zo závislej entity na nezávislú entitu.
• asociácie je štrukturálny vzťah, ktorý ukazuje, že objekty jednej entity súvisia s objektmi inej entity. Graficky je asociácia znázornená ako čiara spájajúca súvisiace entity. Asociácie sa používajú 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 druhej strane. 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. Osobitným prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený kosoštvorcom na konci blízko entity-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 nadradenej 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 (State diagrams),
• 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.

Pohľad na ovládanie modelu. Balíčky.

Už sme povedali, že na to, aby človek dobre porozumel modelu, 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 vám umožňuje vytvárať hierarchie. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balík sa zobrazí ako obdĺžnik s uškom.

Čo poskytuje UML.

• hierarchický popis komplexného systému zvýraznením balíkov;
• formalizácia funkčných požiadaviek na systém pomocou aparátu prípadov použitia;
• spresnenie požiadaviek na systém vytvorením diagramov činností a scenárov;
• výber dátových tried a konštrukcia koncepčného dátového modelu vo forme diagramov tried;
• výber tried, ktoré popisujú používateľské rozhranie, a vytvorenie schémy navigácie na obrazovke;
• opis procesov interakcie objektov pri výkone systémových funkcií;
• opis správania objektov vo forme diagramov činností a stavov;
• popis softvérových komponentov a ich vzájomné pôsobenie prostredníctvom rozhraní;
• popis fyzickej architektúry systému.

A posledný…

Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom modelovaní PS 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ť prázdne miesta programových kódov v rôznych OO programovacích jazykoch a vytvárať databázové schémy. Väčšina z nich zahŕňa možnosť reengineeringu programových kódov - obnovenie určitých projekcií modelu PS automatickou analýzou zdrojových kódov programov, čo je veľmi dôležité pre zabezpečenie zhody modelu a kódov a pri navrhovaní systémov, ktoré zdedia funkčnosť predchádzajúcich systémov. .

UML (Unified Modeling Language - jednotný modelovací jazyk) - grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru. UML je všeobecný jazyk, je to 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ť prevažne softvérové ​​systémy. UML nie je programovací jazyk, ale generovanie kódu je možné v nástrojoch 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- bezplatný program, ktorý vám umožňuje zobraziť predtým vytvorené diagramy Visio. 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 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Príležitosti:

• Diagram prípadov použitia (diagramy precedensov);
• Diagram rozmiestnenia (topologické diagramy);
• Stavový diagram (stavové diagramy);
• Diagram činností (diagramy činností);
• Interakčný diagram (interakčné diagramy);
• Sekvenčný diagram (diagramy sekvencií akcií);
• Diagram spolupráce (diagramy spolupráce);
• Diagram tried (diagramy tried);
• Diagram komponentov (diagramy komponentov).

Snímky obrazovky:

programy s otvoreným zdrojom

StarUML

Príležitosti:

• podpora UML 2.0
• MDA (Model Driven Architecture)
• Plug-in architektúra (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é pridávať aj v iných jazykoch, ako 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:

• trieda
• Štát
• prípady použitia
• Aktivita
• Spolupráca
• Nasadenie
• Sekvencia

Príležitosti:

• Podpora deviatich 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:

Model UML(UML model) je množina konečnej množiny jazykových konštruktov, z ktorých hlavnými sú entity a vzťahy medzi nimi.

Samotné entity a vzťahy modelu sú inštanciami metatried metamodelu.

Vzhľadom na UML model z najvšeobecnejších pozícií môžeme povedať, že ide o graf (presnejšie načítaný multi-pseudo-hyper-digraf), v ktorom sú vrcholy a hrany zaťažené dodatočnými informáciami a môžu mať zložitú vnútornú štruktúru. . Vrcholy tohto grafu sa nazývajú entity a hrany sa nazývajú vzťahy.. Zvyšok časti poskytuje rýchly (predbežný), ale úplný prehľad dostupných typov entít a vzťahov. Našťastie ich nie je príliš veľa. V ďalších kapitolách knihy sú všetky entity a vzťahy znovu uvažované podrobnejšie a s príkladmi.

1.4.1. Esencie

Pre prehľadnosť možno entity v UML rozdeliť do štyroch skupín:

• štrukturálne;
• behaviorálne;
• zoskupovanie;
• anotačný.

Štrukturálne entity, ako by ste mohli hádať, sú určené na opis štruktúry. Štrukturálne entity zvyčajne zahŕňajú nasledujúce.

Objekt(objekt) 1 je entita, ktorá má jedinečnosť a zahŕňa stav a správanie.

Trieda(trieda) 2 - popis množiny objektov so spoločnými atribútmi, ktoré definujú stav a operácie, ktoré definujú správanie.

Rozhranie(rozhranie) 3 je pomenovaná množina operácií, ktorá definuje množinu služieb, o ktoré môže spotrebiteľ požiadať a ktoré môže poskytnúť poskytovateľ služby.

Spolupráca(spolupráca) 4 - súbor objektov, ktoré sa vzájomne ovplyvňujú, aby dosiahli nejaký cieľ.

herec(herec) 5 je entita, ktorá je mimo modelovaného systému a priamo s ním interaguje.

∇ Takýto vzťah určite existuje, čo je vyjadrené na obr. Hierarchia typov diagramu pre UML 1 ako vzťah závislosti so stereotypom „zjemňovania“.

∇∇ V UML 1 došlo k nedobrovoľnej asociácii medzi diagramom spolupráce a entitou s rovnakým názvom, čo nebolo úplne pravdivé a niekedy zavádzajúce.

∇∇∇ V UML 2 sa syntaktické a sémantické zaťaženie stavového diagramu zmenilo natoľko, že názov už neodráža obsah.

Zoznam nových diagramov a ich názvov prijatých v tejto knihe je uvedený nižšie.

• Diagram kompozitnej štruktúry
• Schéma balíka
• Schéma štátneho stroja
• Komunikačný diagram
• Diagram prehľadu interakcií
• Časový diagram

Na obr. Hierarchia typov diagramu pre UML 2 (časť 1 a 2) diagram tried zobrazujúci vzťah diagramov v UML 2.

Neskôr v tejto kapitole veľmi stručne popíšeme všetkých trinásť kanonických diagramov, aby sme mali nejaký kontext a slovnú zásobu pre to, čo nasleduje. Podrobnosti sú uvedené v zostávajúcich kapitolách knihy.

Ale predtým, ako prejdeme k ďalšej časti, urobme malú odbočku o tom, ako štandard vyžaduje formátovanie grafov. Všeobecná šablóna prezentácie grafu je uvedená nižšie.

Existujú dva hlavné dizajnové prvky: vonkajší rám a štítok s názvom grafu. Ak je s rámom všetko jednoduché - je to obdĺžnik, ktorý ohraničuje oblasť, v ktorej by sa mali nachádzať prvky diagramu, potom je názov diagramu napísaný v špeciálnom formáte znázornenom na obr. Grafický zápis.

Tento zložitý tvar karty nepodporujú všetky nástroje. Nie je to však potrebné, pretože sémantika je primárna a notácia je sekundárna. V nasledujúcom texte používame ako označenie grafu obdĺžnik, čo by nemalo spôsobiť nedorozumenie.

Možné značky (typy) pre grafy sú uvedené v nasledujúcej tabuľke. V druhom stĺpci sú napísané značky, ktoré štandard ponúka. Ako však prax ukázala, pravidlá navrhované normou nie sú vždy vhodné a logicky opodstatnené, preto tretí stĺpec tabuľky obsahuje podľa nášho názoru rozumnú alternatívu.

Tab. Typy grafov a značky

Názov grafu	Značka (štandardná)	Značka (odporúčané)
Diagram použitia	prípad použitia alebo uč	prípad použitia
diagram tried	trieda	trieda
diagram automatu	štátny automat alebo stm	štátny automat
diagram činnosti	činnosť alebo konať	činnosť
sekvenčný diagram	interakcia alebo SD	SD
Komunikačný diagram	interakcia alebo SD	comm
Diagram komponentov	komponent alebo cmp	komponent
Schéma umiestnenia	neurčené	nasadenie
Diagram objektu	neurčené	objekt
Schéma vnútornej štruktúry	trieda	trieda alebo komponent
Diagram prehľadu interakcií	interakcia alebo SD	interakcia
Časový diagram	interakcia alebo SD	načasovanie
Schéma balíka	balík alebo bal	balík

UML je všeobecný grafický modelovací jazyk na špecifikáciu, vizualizáciu, návrh a dokumentáciu všetkých artefaktov vytvorených pri vývoji softvérových systémov.

Existuje veľa dobrých kníh, ktoré podrobne popisujú UML (niekedy dokonca veľmi podrobne), rád by som na jednom mieste zhromaždil základné pojmy o diagramoch, entitách a vzťahoch medzi nimi pre rýchle pripomenutie, niečo ako cheat sheet.

Poznámka používa materiály z kníh: Ivanov D. Yu., Novikov F. A. Jednotný modelovací jazyk UML a Leonenkov. Výukový program UML.

Začnime s editorom. Pod Linuxom som skúšal rôzne UML editory, najviac sa mi páčil UMLet, hoci je napísaný v Jave, pohybuje sa veľmi rýchlo a je v ňom väčšina prázdnych entít. Existuje aj ArgoUML, multiplatformový UML editor, tiež napísaný v Jave, funkčne bohatý, no viac spomaľujúci.

Zastavil som sa pri UMLet, nainštalujte ho pod Arch Linux a ubuntu:

# pod Arch Linuxom yaourt -S umlet # pod Ubuntu sudo apt-get install umlet

V UML je možné všetky entity rozdeliť do nasledujúcich typov:

• štrukturálne;
• behaviorálne;
• zoskupovanie;
• anotačný;

UML používa štyri hlavné typy vzťahov:

Závislosť- označuje, že zmena nezávislej entity nejakým spôsobom ovplyvňuje závislú entitu. Graficky je vzťah závislosti znázornený ako bodkovaná čiara so šípkou smerujúcou zo závislej entity na nezávislú entitu.

asociácie- prebieha, ak jedna entita priamo súvisí s inou (alebo s inými - asociácia môže byť nielen binárna). Graficky je asociácia znázornená ako plná čiara s rôznymi doplnkami spájajúcimi súvisiace entity.

Zovšeobecnenie je vzťah medzi dvoma entitami, z ktorých jedna je konkrétnym (špecializovaným) prípadom druhej. Graficky je zovšeobecnenie znázornené ako čiara s trojuholníkovou nevyplnenou šípkou na konci, ktorá smeruje od konkrétnej (podtriedy) k všeobecnej (nadtrieda).

Implementácie- vzťah implementácie naznačuje, že jedna entita je implementáciou inej entity. Graficky je realizácia znázornená bodkovanou čiarou s trojuholníkovou nevyplnenou šípkou na konci, smerujúcou od implementujúceho subjektu k realizovanému.

AT UML 2 definované 13 typy grafov. Podľa štandardov by mal mať každý graf rám s obdĺžnikom (skosený pravý dolný roh) v ľavom hornom rohu, ktorý označuje ID grafu (tag) a názov.

Diagramy zobrazujúce štruktúru systému:

• Diagram komponentov (diagram komponentov, tag komponent);
• Diagram nasadenia (diagram nasadenia, tag nasadenie);
• Diagram tried (diagram tried, tag trieda);
• Diagram objektu (diagram objektu, značka objekt);
• Schéma vnútornej štruktúry (diagram zloženej štruktúry, tag trieda);

Diagramy zobrazujúce správanie systému:

• Synchronizačný diagram (interakčný diagram, tag načasovanie);
• Diagram aktivity (diagram aktivity, značka činnosť);
• sekvenčný diagram (sekvenčný diagram, tag SD);
• Komunikačný diagram (komunikačný diagram, tag comm);
• Schéma automatu (diagram stavového stroja, tag štátny automat);
• Diagram prehľadu interakcie, značka interakcia);

Grafy vynikajú:

• Diagram prípadu použitia (diagram prípadu použitia, značka prípadu použitia);
• Diagram balíka (diagram balíka, značka balík);

Diagram použitia

Diagram použitia(diagram prípadov použitia) je najvšeobecnejším znázornením funkčného účelu systému.

Ak vezmeme do úvahy diagram prípadu použitia ako model systému, môžeme ho spojiť s modelom čiernej skrinky. Každý prípad použitia definuje postupnosť akcií, ktoré musí navrhnutý systém vykonať pri interakcii s príslušným aktérom.

Diagram použitia využíva dva typy základných entít: prípady použitia a aktérov, medzi ktorými sú vytvorené nasledujúce základné typy vzťahov.

asociačný vzťah- Tento vzťah určuje, akú špecifickú úlohu hrá aktér pri interakcii s prípadom použitia. Asociačný vzťah je označený plnou čiarou medzi aktérom a prípadom použitia. Tento riadok môže mať ďalšie symboly, ako je napríklad názov a násobok.

Vzťah rozšírenia- definuje vzťah inštancií jedného prípadu použitia so všeobecnejším prípadom použitia, ktorého vlastnosti sú určené na základe spôsobu, akým sa tieto inštancie kombinujú. Ak teda existuje vzťah rozšírenia od prípadu použitia A k prípadu použitia B, znamená to, že vlastnosti inštancie prípadu použitia B možno doplniť z dôvodu prítomnosti vlastností v prípade rozšíreného použitia A.

Vzťah rozšírenia medzi prípadmi použitia je označený prerušovanou čiarou so šípkou (prípad vzťahu závislosti) smerujúcou preč od prípadu použitia, ktorý je rozšírením pôvodného prípadu použitia.

Generalizačný vzťah slúži na označenie skutočnosti, že niektorý prípad použitia A možno zovšeobecniť na prípad použitia B. V tomto prípade bude prípad použitia A špecializáciou prípadu použitia B. V tomto prípade sa B nazýva predchodcom alebo rodičom A a použitie A je potomkom použitia prípadu použitia V.

Graficky je tento vzťah znázornený plnou čiarou s otvorenou trojuholníkovou šípkou, ktorá ukazuje na nadradený prípad použitia.

Vzťah zovšeobecnenia medzi prípadmi použitia sa používa vtedy, keď je potrebné poznamenať, že prípady použitia podriadených majú všetky atribúty a správanie rodičovských prípadov použitia.

Vzťah inklúzie medzi dvoma prípadmi použitia naznačuje, že niektoré špecifikované správanie pre jeden prípad použitia je zahrnuté ako komponent v sekvencii správania iného prípadu použitia.

Vzťah zahrnutia, od prípadu použitia A po prípad použitia B, naznačuje, že každý prípad použitia A zahŕňa funkčné vlastnosti špecifikované pre prípad použitia B.

Graficky je tento vzťah znázornený bodkovanou čiarou so šípkou (variant vzťahu závislosti) smerujúcou od základného prípadu použitia k zahrnutému prípadu použitia.

diagram tried

diagram tried(diagram tried) - hlavný spôsob popisu statickej štruktúry systému.

Diagram tried používa jeden hlavný typ entít: triedy (vrátane mnohých špeciálnych prípadov tried: rozhrania, primitívne typy, asociačné triedy atď.), medzi ktorými sú vytvorené tieto hlavné typy vzťahov: závislosti, asociácie, zovšeobecnenia, implementácie.

Vzťah závislosti vo všeobecnosti označuje nejaký sémantický vzťah medzi dvoma modelovými prvkami alebo dvoma skupinami takýchto prvkov, ktorý nie je vzťahom asociácie, zovšeobecnenia alebo implementácie. Vzťah závislosti sa používa v situácii, keď určitá zmena v jednom prvku modelu môže vyžadovať zmenu v inom prvku závislého modelu.

Vzťah závislosti je graficky znázornený prerušovanou čiarou medzi zodpovedajúcimi prvkami so šípkou na jednom konci, pričom šípka ukazuje z klientskej triedy závislosti na nezávislú alebo zdrojovú triedu.

Špeciálne kľúčové slová (stereotypy) možno umiestniť nad šípku:

• "access" - slúži na označenie dostupnosti verejných atribútov a operácií zdrojovej triedy pre triedy klientov;
• "bind" - trieda klienta môže použiť nejakú šablónu pre svoju následnú parametrizáciu;
• "derive" - ​​atribúty triedy klienta možno vypočítať z atribútov zdrojovej triedy;
• "import" - verejné atribúty a operácie zdrojovej triedy sa stávajú súčasťou klientskej triedy, ako keby boli deklarované priamo v nej;
• "spresniť" - označuje, že trieda klienta slúži ako spresnenie zdrojovej triedy z historických dôvodov, keď sa v priebehu práce na projekte sprístupnia ďalšie informácie.

asociačný vzťah zodpovedá prítomnosti nejakého vzťahu medzi triedami. Tento vzťah je označený plnou čiarou s ďalšími špeciálnymi symbolmi, ktoré charakterizujú jednotlivé vlastnosti konkrétneho združenia. Ako ďalšie špeciálne znaky možno použiť názov asociácie, ako aj názvy a početnosť tried rolí asociácie. Názov združenia je nepovinným prvkom jeho označenia.

Agregačný vzťah sa vyskytuje medzi niekoľkými triedami, ak jedna z tried je entita, ktorá zahŕňa iné entity ako komponenty. Používa sa na reprezentáciu systémových vzťahov typu „časť-celok“.

Kompozičný vzťah je špeciálnym prípadom agregačného vzťahu. Tento vzťah slúži na zvýraznenie špeciálnej formy vzťahu časť-celok, v ktorom sú jednotlivé časti v určitom zmysle v rámci celku. Špecifickosť vzťahu medzi nimi spočíva v tom, že časti nemôžu pôsobiť izolovane od celku, t. j. zničením celku sa zničia aj všetky jeho súčasti.

Generalizačný vzťah je vzťah medzi všeobecnejším prvkom (rodič alebo predok) a špecifickejším alebo špeciálnym prvkom (dieťa alebo potomok). Pri použití v diagrame tried tento vzťah popisuje hierarchickú štruktúru tried a dedičnosť ich vlastností a správania. To predpokladá, že trieda potomka má všetky vlastnosti a správanie triedy predkov a má tiež svoje vlastné vlastnosti a správanie, ktoré nie sú prítomné v triede predkov.

diagram automatu

diagram automatu(schéma stavového stroja) príp stavový diagram v UML 1 (stavový diagram) je jedným zo spôsobov, ako podrobne opísať správanie v UML. V podstate, automatové diagramy, ako už názov napovedá, sú grafom stavov a prechodov konečného automatu nabitého mnohými ďalšími detailmi a detailmi.

Stavový diagram popisuje proces zmeny stavov iba jednej triedy alebo skôr jednej inštancie určitej triedy, to znamená, že modeluje všetky možné zmeny stavu konkrétneho objektu. V tomto prípade môže byť zmena stavu objektu spôsobená vonkajšími vplyvmi z iných objektov alebo zvonka. Má opísať reakciu objektu na také vonkajšie vplyvy, že sa používajú stavové diagramy.

V diagrame automatov sa používa jeden hlavný typ entity - stavy a jeden typ vzťahu - prechody, ale pre oba je definovaných veľa odrôd, špeciálnych prípadov a dodatočných označení. Automat predstavuje dynamické aspekty simulovaného systému vo forme orientovaného grafu, ktorého vrcholy zodpovedajú stavom a oblúky zodpovedajú prechodom.

Počiatočný stav je špeciálny prípad stavu, ktorý neobsahuje žiadne vnútorné úkony (pseudostavy). Objekt je štandardne v tomto stave v počiatočnom okamihu. Slúži na označenie grafickej oblasti na stavovom diagrame, z ktorej sa začína proces zmeny stavov.

finále (konečné) stav je špeciálny prípad stavu, ktorý taktiež neobsahuje žiadne vnútorné úkony (pseudostavy). Objekt bude v tomto stave štandardne po dokončení automatu v čase ukončenia.

diagram činnosti

Pri modelovaní správania navrhnutého alebo analyzovaného systému je potrebné nielen prezentovať proces zmeny jeho stavov, ale aj podrobne opísať vlastnosti algoritmickej a logickej implementácie operácií vykonávaných systémom.

diagram činnosti(diagram aktivít) je ďalší spôsob popisu správania, ktorý vizuálne pripomína starý dobrý vývojový diagram algoritmu. Používa sa na simuláciu procesu vykonávania operácií.

Hlavným smerom použitia diagramov aktivít je vizualizácia vlastností implementácie operácií triedy, keď je potrebné prezentovať algoritmy na ich vykonávanie.

V diagrame aktivít sa používa jeden hlavný typ entít – akcia a jeden typ vzťahu – prechody (prevody kontroly). Používajú sa aj také konštrukcie ako vidlice, zlučovače, prípojky, odbočky. Ako názov jednoduchej akcie sa odporúča použiť sloveso s vysvetľujúcimi slovami.

sekvenčný diagram

sekvenčný diagram(sekvenčný diagram) je spôsob opisu správania systému „na príkladoch“.

V skutočnosti je sekvenčný diagram záznamom protokolu konkrétnej relácie systému (alebo fragmentu takéhoto protokolu). V objektovo orientovanom programovaní je najdôležitejšou vecou za behu odovzdávanie správ medzi spolupracujúcimi objektmi. Na tomto diagrame je zobrazená postupnosť odosielania správ, odtiaľ názov.

V sekvenčnom diagrame sa používa jeden hlavný typ entít – inštancie interagujúcich klasifikátorov (hlavne triedy, komponenty a aktéri) a jeden typ vzťahu – prepojenia, prostredníctvom ktorých sa vymieňajú správy.

Možné typy správ (obrázok prevzatý z larin.in):

Komunikačný diagram

Komunikačný diagram(komunikačný diagram) – spôsob popisu správania, významovo ekvivalentný sekvenčnému diagramu. V skutočnosti ide o rovnaký popis sekvencie výmeny správ interagujúcich inštancií klasifikátorov, len vyjadrený inými grafickými prostriedkami.

V komunikačnom diagrame, ako aj v sekvenčnom diagrame sa teda používa jeden hlavný typ entít – inštancie interagujúcich klasifikátorov a jeden typ vzťahu – spojenia. Tu sa však nekladie dôraz na čas, ale na štruktúru vzťahov medzi konkrétnymi prípadmi.

Diagram komponentov

Diagram komponentov(diagram komponentov) – zobrazuje vzťah medzi modulmi (logickými alebo fyzickými), ktoré tvoria simulovaný systém.

Hlavným typom entity v diagrame komponentov sú samotné komponenty, ako aj rozhrania, prostredníctvom ktorých je indikovaný vzťah medzi komponentmi. V diagrame komponentov platia nasledujúce vzťahy:

• implementácie medzi komponentmi a rozhraniami (komponent implementuje rozhranie);
• závislosti medzi komponentmi a rozhraniami (komponent používa rozhranie);

Schéma umiestnenia

Schéma umiestnenia(diagram nasadenia) spolu so zobrazením zloženia a vzťahov prvkov systému ukazuje, ako sú fyzicky umiestnené na výpočtových zdrojoch počas vykonávania.

V diagrame umiestnenia sú v porovnaní s diagramom komponentu pridané dva typy entít: artefakt, ktorý je implementáciou komponentu a uzol (môže to byť buď klasifikátor, ktorý popisuje typ uzla, alebo konkrétna inštancia) , ako aj asociačný vzťah medzi uzlami, ktorý ukazuje, že uzly sú fyzicky pripojené v čase spustenia.

Diagram objektu

Diagram objektu(objektový diagram) – je inštanciou diagramu tried.

Objektový diagram využíva jeden hlavný typ entít: objekty (inštancie tried), medzi ktorými sú naznačené špecifické vzťahy (najčastejšie asociačné inštancie). Objektové diagramy majú pomocný charakter – v skutočnosti sú to príklady (možno povedať, výpisy pamäte), ktoré ukazujú, aké objekty existujú a spojenia medzi nimi v určitom momente prevádzky systému.

Schéma vnútornej štruktúry(composite structure diagram) slúži na podrobnejšiu prezentáciu štruktúrnych klasifikátorov, predovšetkým tried a komponentov.

Štrukturálny klasifikátor je zobrazený ako obdĺžnik s názvom klasifikátora v hornej časti. Vo vnútri sú diely. Môže existovať niekoľko častí. Časti môžu vzájomne pôsobiť. Naznačujú to konektory rôznych druhov. Miesto na vonkajšom okraji dielu, ku ktorému je pripojený konektor, sa nazýva port. Porty sú tiež umiestnené na vonkajšej hranici štruktúrneho klasifikátora.

Diagram prehľadu interakcií(interaction overview diagram) je druh diagramu aktivít s rozšírenou syntaxou: prepojenia na interakcie (interaction use) definované sekvenčnými diagramami môžu pôsobiť ako prvky prehľadového diagramu interakcie.

Časový diagram

Časový diagram(časový diagram) je špeciálna forma sekvenčného diagramu, v ktorej sa osobitná pozornosť venuje zmene stavov rôznych inštancií klasifikátorov a ich časovej synchronizácii.

Schéma balíka

Schéma balíka(package diagram) je jediný nástroj, ktorý vám umožňuje riadiť zložitosť samotného modelu.

Hlavnými prvkami zápisu sú balíčky a závislosti s rôznymi stereotypmi.

Model vzťahu entít (ER-model)

analógový diagramy tried(UML) môže byť ER model, ktorý sa používa pri návrhu databáz (relačný model).

Entity-relationship model (ER-model) je dátový model, ktorý vám umožňuje opísať konceptuálne schémy predmetnej oblasti. Model ER sa používa vo vysokoúrovňovom (koncepčnom) návrhu databáz. S jeho pomocou môžete zvýrazniť kľúčové entity a určiť vzťahy, ktoré možno medzi týmito entitami vytvoriť. wikipedia

Akýkoľvek fragment predmetnej oblasti môže byť reprezentovaný ako súbor entít, medzi ktorými existuje určitý súbor vzťahov.

Základné pojmy:

Esencia(entita) je entita, ktorú možno identifikovať nejakým spôsobom, ktorý ju odlišuje od iných subjektov, napr. KLIENT 777. Entita je vlastne súbor atribútov.

Súprava entít(množina entít) - množina entít rovnakého typu (s rovnakými vlastnosťami).

Pripojenie(vzťah) je združenie založené medzi viacerými subjektmi.

doména(doména) - množina hodnôt (doména) atribútu.

Existujú tri typy binárnych odkazov:

• jeden na jedného- jedna inštancia entity jednej triedy je spojená s jednou inštanciou entity inej triedy, napríklad HEAD - DEPARTMENT;
• 1 až N alebo jeden k mnohým- jedna inštancia entity jednej triedy je spojená s mnohými inštanciami entity inej triedy, napríklad ODDELENIE - ZAMESTNANEC;
• N až M alebo veľa mnohým- veľa inštancií entity jednej triedy je spojených s mnohými inštanciami entity inej triedy, napríklad ZAMESTNANEC - PROJEKT;
Slovník základných pojmov v UML

objekt- entita, ktorá má jedinečnosť a zapuzdruje stav a správanie.

trieda- popis množiny objektov so spoločnými atribútmi definujúcimi stav a operácie definujúce správanie.

rozhranie- pomenovaná množina operácií, ktorá definuje množinu služieb, o ktoré môže spotrebiteľ požiadať a ktoré môže poskytnúť poskytovateľ služby.

Spolupráca- súbor predmetov, ktoré sa vzájomne ovplyvňujú, aby dosiahli nejaký cieľ.

herec- entita, ktorá je mimo modelovaného systému a priamo s ním interaguje.

komponent- modulárna časť systému s dobre definovanou sadou požadovaných a poskytovaných rozhraní.

Artefakt- prvok informácie, ktorý sa používa alebo generuje v procese vývoja softvéru. Inými slovami, artefakt je fyzická jednotka implementácie odvodená od prvku modelu (ako je trieda alebo komponent).

Uzol- výpočtový zdroj, na ktorý sa umiestňujú a v prípade potreby spúšťajú artefakty.

Entity správania sú určené na opis správania. Existujú len dve základné entity správania: stav a činnosť.

štát- obdobie v životnom cykle predmetu, v ktorom predmet spĺňa určitú podmienku a vykonáva vlastnú činnosť alebo čaká na výskyt nejakej udalosti.

akcie- primitívny atómový výpočet.

Stroj je balík, ktorý definuje súbor pojmov nevyhnutných na reprezentáciu správania modelovanej entity ako diskrétneho priestoru s konečným počtom stavov a prechodov.

klasifikátor je deskriptor pre množinu objektov rovnakého typu.

Čítanie navyše

• Fowler M. UML. Základy, 3. vydanie
• Butch G., Rambo D., Jacobson I. Jazyk UML. Užívateľská príručka