UML2 a ER diagramy. Všeobecná charakteristika jazyka UML Ako spolu súvisia pojmy model a diagram

5.4. Základné diagramy objektov: Objekty a ich vzťahy Diagram objektov zobrazuje existujúce objekty a ich vzťahy v návrhu logického systému. Inými slovami, objektový diagram je snímka toku udalostí v určitej konfigurácii.

5.7. Procesné diagramy. Nevyhnutné: Procesory, zariadenia a pripojenia Procesné diagramy sa používajú na zobrazenie distribúcie procesov medzi procesormi vo fyzickom návrhu systému. Samostatný diagram procesu zobrazujúci jeden pohľad na štruktúru procesu

10.4. DIAGRAMY UML 10.4.1. Typy vizuálnych diagramov UMLUML vám umožňuje vytvárať niekoľko typov vizuálnych diagramov: diagramy prípadov použitia; sekvenčné diagramy; kooperatívne grafy; diagramy tried; stavové diagramy; grafy

1.2.6. Schéma drôtového modelu 1.2.26 ukazuje typický príklad dekompozičného diagramu s ohraničujúcimi rámčekmi, nazývaný drôtový diagram. Ryža. 1.2.26. Príklad dekompozičného diagramu s drôteným modelom Drôtový model obsahuje hlavičku (horná časť rámca) a pätu (dolná časť).

Časové diagramy Ak chcete získať časové diagramy vstupného a výstupného napätia, musíte mierne upraviť vstupný súbor. Rovnako ako v predchádzajúcom príklade sa použije sínusové vstupné napätie: Vi 1 0 sin (0 0,5 V 5 kHz) Spolu s analýzou prechodových javov

Tabuľky a grafy Len odborník dokáže rozpoznať význam nekonečného radu čísel, ale každý môže pochopiť (alebo aspoň vyhlásiť, že rozumie) histogramu alebo koláčovému grafu. VBA nemá vstavané nástroje na vytváranie grafov, ale napr

5.1.14. Grafy Grafy sú grafickým znázornením údajov z číselnej tabuľky. Pages ponúka niekoľko typov grafov: Stĺpcový, Skladaný stĺpec, Pruhový, Skladaný pruh, Čiarový, Plošný, Skladaný

5.2.8. Grafy Graf je grafické znázornenie údajov z vybraného rozsahu. Pri zostavovaní grafu postupujte podľa nižšie uvedeného algoritmu: 1. Vytvorte tabuľku vypočítaných hodnôt. 2. Vyberte požadovaný rozsah (môže pozostávať z nesusediacich obdĺžnikových

UML je skratka pre Unified Modeling Language. V skutočnosti je to jedna z najpopulárnejších techník modelovania obchodných procesov a je to medzinárodná štandardná notácia pre špecifikáciu, vizualizáciu a dokumentáciu vývoja softvéru. Definovaný Object Management Group, vznikol ako výsledok niekoľkých dodatočných notačných systémov UML a teraz sa stal de facto štandardom pre vizuálne modelovanie. Základný princíp akéhokoľvek objektovo orientovaného programovania začína vytvorením modelu.

UML bol vytvorený z chaosu okolo vývoja softvéru a dokumentácie. V 90. rokoch 20. storočia existovalo niekoľko rôznych spôsobov reprezentácie softvérových systémov. Bolo potrebné vytvoriť jednotnejší vizuálny spôsob UML na reprezentáciu týchto systémov, a preto ho v rokoch 1994-1996 vyvinuli traja softvéroví inžinieri pracujúci v Rational Software. Neskôr bol prijatý ako štandard v roku 1997 a zostáva ním, len s niekoľkými aktualizáciami.

UML je v podstate univerzálny modelovací jazyk v oblasti vývoja softvéru. Teraz sa však odráža v dokumentácii niekoľkých obchodných alebo pracovných procesov, ako sú diagramy aktivít. Diagramy typu UML možno použiť ako náhradu za vývojové diagramy. Poskytujú štandardizovanejší spôsob modelovania pracovných postupov a širokú škálu funkcií na zlepšenie čitateľnosti a efektívnosti.

Architektúra je založená na meta-objekte, ktorý definuje základ pre vytvorenie UML. Je dostatočne presný na vytvorenie celej aplikácie. Plne spustiteľné UML je možné nasadiť na viacero platforiem pomocou rôznych technológií so všetkými procesmi počas celého cyklu vývoja softvéru.

UML je určený na vývoj jazyka vizuálneho modelovania používateľmi. Podporuje koncepty dizajnu na vysokej úrovni, ako sú štruktúry, šablóny a spolupráca. UML je súbor prvkov, ako napríklad:

1. Príkazy programovacieho jazyka.
2. Aktéri – popisujú rolu, ktorú hrá používateľ alebo akýkoľvek iný systém, ktorý interaguje s objektom.
3. Činnosti, ktoré sa majú vykonať pri realizácii zmluvy o dielo a uvedené v diagramoch.
4. Obchodný proces, ktorý zahŕňa súbor úloh, ktoré vytvárajú špecifickú službu pre zákazníkov, vizualizovaný vývojovým diagramom sekvenčných akcií.
5. Logické a opakovane použiteľné softvérové ​​komponenty.

UML diagramy spadajú do dvoch kategórií. Prvý typ zahŕňa sedem typov diagramov, ktoré predstavujú štrukturálne informácie, druhý zahŕňa ďalších sedem, ktoré predstavujú bežné typy správania. Tieto diagramy sa používajú na dokumentáciu architektúry systémov a priamo sa podieľajú na modelovaní systému UML.

UML diagramy sú prezentované ako statické a dynamické pohľady na model systému. Statický pohľad zahŕňa diagramy tried a zložených štruktúr, ktoré zdôrazňujú statickú štruktúru. Dynamický pohľad predstavuje interakciu medzi objektmi a zmeny vnútorných stavov objektov pomocou sekvenčných, aktivít a stavových diagramov.

Na zjednodušenie modelovania je k dispozícii široká škála nástrojov na modelovanie UML, vrátane IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner a Dia.

UML sa používa rôznymi spôsobmi, ako v dokumentácii vývoja softvéru, tak aj v obchodných procesoch:

1. Skica. V tomto prípade sa diagramy UML používajú na vyjadrenie rôznych aspektov a charakteristík systému. Toto je však iba pohľad na systém na najvyššej úrovni a pravdepodobne nebude obsahovať všetky potrebné detaily na dokončenie projektu až do úplného konca.
2. Dopredný dizajn - Návrh náčrtu sa robí pred kódovaním aplikácie. Ide o poskytnutie lepšieho prehľadu o systéme alebo pracovnom postupe, ktorý sa používateľ pokúša vytvoriť. Je možné identifikovať veľa konštrukčných problémov alebo nedostatkov, ktoré zlepšia celkové zdravie a pohodu projektu.
3. Obrátený dizajn. Po napísaní kódu sa diagramy UML objavia ako forma dokumentácie pre rôzne aktivity, roly, účastníkov a pracovné postupy.
4. Modrotlač. Schéma v tomto prípade slúži ako kompletná konštrukcia, ktorá si vyžaduje len samotnú implementáciu systému alebo softvéru. Často sa to robí pomocou nástrojov CASE (Computer Aided Software Engineering Tools). Hlavnou nevýhodou používania nástrojov CASE je, že vyžadujú určitú úroveň vedomostí, školenia používateľov a manažmentu a personálu.

UML nie je samostatný programovací jazyk ako Java, C++ alebo Python, avšak so správnymi nástrojmi sa môže stať pseudo UML. Na dosiahnutie tohto cieľa musí byť celý systém zdokumentovaný v rôznych diagramoch a pomocou správneho softvéru je možné diagramy priamo preložiť do kódu. Táto technika môže byť užitočná iba vtedy, ak je čas strávený kreslením grafov menej časovo náročný ako písanie skutočného kódu. Aj keď bol UML vytvorený pre modelovanie systémov, našiel si niekoľko využití v obchodných oblastiach.

Nasleduje príklad UML diagramu pre obchodné modelovanie.

Jedným z praktických riešení by bola vizualizácia toku procesu pre telesales prostredníctvom diagramu aktivít. Od momentu, kedy je objednávka prijatá ako vstup, až po moment, keď je objednávka dokončená a je daný konkrétny výstup.

Existuje niekoľko typov diagramov UML a každý z nich vykonáva inú úlohu, či už je vyvinutý pred implementáciou alebo po nej, ako súčasť dokumentácie. Dve najširšie kategórie, ktoré zahŕňajú všetky ostatné typy, sú diagram správania a diagram štruktúry. Ako už názov napovedá, niektoré UML diagramy sa snažia analyzovať a znázorniť štruktúru systému alebo procesu, zatiaľ čo iné popisujú správanie systému, jeho účastníkov a komponentov.

Jednotlivé typy sú rozdelené takto:

1. Nie všetky zo 14 rôznych typov UML diagramov sa pravidelne používajú pri dokumentovaní systémov a architektúr.
2. Paretov princíp platí aj pre použitie UML diagramov.
3. 20 % grafov používajú vývojári 80 % času.

Najčastejšie používané prvky pri vývoji softvéru sú:

• diagramy použitia;
• diagramy tried;
• sekvencie.

Akčné diagramy sú najdôležitejšie UML diagramy pre vytváranie modelov obchodných procesov. Pri vývoji softvéru sa používajú na opis toku rôznych akcií. Môžu byť buď sekvenčné alebo paralelné. Popisujú predmety používané, spotrebované alebo vyrobené ako výsledok činností a vzťah medzi rôznymi činnosťami.

Všetko vyššie uvedené je dôležité pre modelovanie obchodných procesov, ktoré vedú od jedného k druhému, keďže sú vzájomne prepojené s jasným začiatkom a koncom. V podnikateľskom prostredí sa to označuje aj ako mapovanie obchodných procesov. Hlavnými aktérmi sú autor, redaktor a vydavateľ. Príklady UML zahŕňajú nasledujúce. Keď recenzent posúdi koncept a rozhodne, že je potrebné vykonať nejaké zmeny. Autor potom návrh upraví a znova ho vráti na analýzu prehľadu.

Diagram použitia

Základný kameň systému – slúži na analýzu požiadaviek na úroveň systému. Tieto požiadavky sú vyjadrené v rôznych prípadoch použitia. Tri hlavné zložky diagramu UML sú:

1. Funkčné – prezentované ako prípady použitia.
2. Sloveso opisujúce činnosť.
3. Herci - na interakciu so systémom. Aktérom môžu byť používatelia, organizácie alebo externá aplikácia. Vzťah medzi účastníkmi je znázornený rovnými šípkami.

Napríklad pre tabuľku kontroly zásob. V tomto prípade ide o vlastníka, dodávateľa, manažéra, špecialistu na inventarizáciu a inšpektora zásob. Okrúhle nádoby predstavujú akcie, ktoré herci vykonávajú. Možné akcie zahŕňajú nákup a platbu zásob, kontrolu kvality zásob, vrátenie zásob alebo ich distribúciu.

Tento typ diagramu je vhodný na zobrazenie dynamického správania medzi účastníkmi v systéme, čím zjednodušuje jeho prezentáciu bez toho, aby odrážal detaily implementácie.

Dočasné

Časové diagramy UML sa používajú na znázornenie vzťahov medzi objektmi, keď je zameranie časovo závislé. Zároveň nie je zaujímavé, ako objekty interagujú alebo sa navzájom menia, ale používateľ si chce predstaviť, ako objekty a subjekty pôsobia pozdĺž lineárnej časovej osi.

Každý jednotlivý účastník je reprezentovaný životnou líniou, ktorá je v podstate líniou tvoriacou etapy, keď sa jednotlivý účastník pohybuje z jednej etapy do druhej. Pozornosť sa sústreďuje na trvanie udalostí a zmeny, ktoré nastanú v závislosti od toho.

Hlavné zložky časového diagramu sú:

1. Lifeline je individuálny člen.
2. Časová os stavu – Jedna životná cesta môže v rámci procesu prechádzať rôznymi stavmi.
3. Obmedzenie trvania – Obmedzenie časového intervalu, ktoré predstavuje trvanie potrebné na splnenie obmedzenia.
4. Časový limit – obmedzte časový interval, počas ktorého musí účastník niečo urobiť.
5. Destruction Appearance – vzhľad správy, ktorá ničí jednotlivého účastníka a zobrazuje koniec životného cyklu tohto účastníka.

Horizontálne diagramy, tiež nazývané stavové diagramy, sa používajú na popis rôznych stavov komponentu v rámci systému. Vyžaduje si konečný formát názvu, pretože diagram je v podstate stroj, ktorý popisuje viaceré stavy objektu a ako sa mení na základe vnútorných a vonkajších udalostí.

Veľmi jednoduchý stavový diagram stroja by bol v šachovej hre. Typická šachová partia pozostáva z ťahov bieleho a ťahov čierneho. Prvý ťah má biely, ktorý tak začína hru. Koniec hry môže nastať bez ohľadu na to, či vyhrá biely alebo čierny. Hra sa môže skončiť zápasom, rezignáciou alebo remízou (iné strojové podmienky). Stavové diagramy sa používajú hlavne v doprednom a spätnom UML návrhu rôznych systémov.

Postupne

Tento typ diagramu je najdôležitejším UML diagramom nielen medzi počítačovou komunitou, ale aj ako model návrhovej vrstvy pre vývoj obchodných aplikácií. Sú obľúbené na popis obchodných procesov vďaka svojej vizuálnej samovysvetľujúcej povahe. Ako už názov napovedá, diagramy popisujú postupnosť správ a interakcií, ktoré sa vyskytujú medzi subjektmi a objektmi. Aktéri alebo objekty môžu byť aktívne len vtedy, keď je to potrebné alebo keď s nimi chce komunikovať iný objekt. Všetky správy sú prezentované v chronologickom poradí.

Ďalšie informácie nájdete v príklade sekvenčného diagramu UML nižšie.

Ako ukazuje príklad, štruktúrne diagramy sa používajú na zobrazenie štruktúry systému. Presnejšie povedané, jazyk sa používa pri vývoji softvéru na znázornenie architektúry systému a spôsobu, akým sú rôzne komponenty prepojené.

Diagram tried UML je najbežnejším typom diagramu pre softvérovú dokumentáciu. Keďže väčšina programov, ktoré sú v súčasnosti napísané, je stále založená na paradigme objektovo orientovaného programovania, používanie diagramov tried na dokumentovanie softvéru sa ukazuje ako zdravý rozum. Je to preto, že OOP je založený na triedach UML a vzťahoch medzi nimi. Stručne povedané, grafy obsahujú triedy spolu s ich atribútmi, ktoré sa tiež nazývajú dátové polia, a ich správanie, nazývané členské funkcie.

Konkrétnejšie, každá trieda má 3 polia: názov hore, atribúty hneď pod názvom, operácie/správanie dole. Vzťah medzi rôznymi triedami (reprezentovanými spojnicou) tvorí diagram tried. Vyššie uvedený príklad ukazuje základný diagram tried.

Objekty

Pri diskusii o štrukturálnych diagramoch UML sa musíte hlbšie ponoriť do koncepcií informatiky. Pri vývoji softvéru sa triedy považujú za abstraktné dátové typy, zatiaľ čo objekty sú inštancie. Napríklad, ak existuje „Auto“, čo je všeobecný abstraktný typ, potom inštancia triedy „Auto“ bude „Audi“.

UML diagramy objektov pomáhajú vývojárom softvéru kontrolovať, či vygenerovaná abstraktná štruktúra generuje životaschopnú štruktúru, keď sa implementuje v praxi, to znamená, keď sa vytvárajú objekty. Niektorí vývojári to považujú za sekundárnu úroveň overenia presnosti. Zobrazuje inštancie tried. Presnejšie povedané, generická trieda „Zákazník“ má teraz skutočného zákazníka, napríklad s názvom „James“. James je inštanciou všeobecnejšej triedy a má rovnaké atribúty, avšak s danými hodnotami. To isté bolo urobené s Účtami a sporiacim účtom. Obidva sú predmetmi svojich príslušných tried.

Nasadenie

Diagramy nasadenia sa používajú na vizualizáciu vzťahu medzi softvérom a hardvérom. Aby sme boli konkrétnejší, pomocou diagramov nasadenia môžete vytvoriť fyzický model toho, ako sú softvérové ​​​​komponenty (artefakty) nasadené na hardvérových komponentoch známych ako uzly.

Typický zjednodušený vzor nasadenia pre webovú aplikáciu by zahŕňal:

1. Uzly (aplikačný server a databázový server).
2. Artefakty klientskej aplikačnej schémy a databázy.

Diagram balíka je podobný makrám pre diagramy nasadenia UML, ktoré sme vysvetlili vyššie. Rôzne balíčky obsahujú uzly a artefakty. Zoskupujú diagramy a komponenty modelu do skupín, podobne ako menný priestor zapuzdruje rôzne názvy, ktoré spolu súvisia. V konečnom dôsledku môže byť balík vytvorený aj niekoľkými ďalšími balíkmi, ktoré reprezentujú zložitejšie systémy a správanie.

Hlavným účelom diagramu balíkov je ukázať vzťahy medzi rôznymi hlavnými komponentmi, ktoré tvoria komplexný systém. Programátori považujú túto funkciu abstrakcie za dobrú výhodu pri používaní diagramov balíkov, najmä ak môžu byť detaily vynechané z obrázku.

Ako každá iná vec v živote, aj niečo správne si vyžaduje správne nástroje. Na dokumentovanie softvéru, procesov alebo systémov používajte nástroje, ktoré ponúkajú anotácie UML a šablóny diagramov. Existujú rôzne nástroje softvérovej dokumentácie, ktoré vám môžu pomôcť nakresliť diagram.

Zvyčajne spadajú do nasledujúcich hlavných kategórií:

1. Papier a pero sú jednoduché. Vezmú papier a pero, otvoria syntaktický kód UML z internetu a nakreslia akýkoľvek typ diagramu, ktorý je potrebný.
2. Online nástroje – Existuje niekoľko online aplikácií, ktoré môžete použiť na vytvorenie grafu. Väčšina z nich ponúka platené predplatné alebo obmedzený počet bezplatných grafov.
3. Bezplatné online nástroje sú takmer rovnaké ako platené. Hlavný rozdiel je v tom, že tie platené ponúkajú aj návody a hotové šablóny pre konkrétne grafy.
4. Desktopová aplikácia je typická desktopová aplikácia na použitie pre diagramy a takmer akýkoľvek iný diagram je Microsoft Visio. Ponúka pokročilé funkcie a funkcie. Jedinou nevýhodou je, že za to musíte zaplatiť.

Je teda celkom jasné, že UML je dôležitým aspektom spojeným s vývojom objektovo orientovaného softvéru. Na vytváranie vizuálnych modelov systémových programov využíva grafickú notáciu.

& nbsp & nbsp & nbsp & nbsp Unified Modeling Language (UML) je jazyk na špecifikovanie, vizualizáciu, konštrukciu a dokumentáciu softvérových systémov, ako aj obchodných modelov a iných nesoftvérových systémov. UML je zlúčením inžinierskych techník, ktoré sa predtým úspešne používali na modelovanie veľkých a zložitých systémov.

& nbsp & nbsp & nbsp & nbsp Tvorcovia UML ho predstavujú ako jazyk na definovanie, reprezentáciu, navrhovanie a dokumentovanie softvérových systémov, podnikových systémov a iných systémov rôzneho charakteru. UML definuje notáciu a metamodel. Notácia je zbierka grafických objektov, ktoré sa používajú v modeloch; je to syntax modelovacieho jazyka.

& nbsp & nbsp & nbsp & nbsp UML poskytuje expresívne nástroje na vytváranie vizuálnych modelov, ktoré:

• jednotne pochopené všetkými vývojármi zapojenými do projektu;
• sú prostriedkom komunikácie v rámci projektu.

& nbsp & nbsp & nbsp & nbsp Unified Modeling Language (UML):

• nezávisí od objektovo orientovaných (OO) programovacích jazykov;
• nezávisí od použitej metodiky vývoja projektu;
• môže podporovať akýkoľvek programovací jazyk OO.

& nbsp & nbsp & nbsp & nbsp UML je open source a je rozšíriteľné na základné jadro. V UML môžete zmysluplne opísať triedy, objekty a komponenty v rôznych tematických oblastiach, ktoré sa často navzájom veľmi líšia.

UML diagramy

& nbsp & nbsp & nbsp & nbsp Rational Rose poskytuje dizajnérovi systému k dispozícii nasledujúce typy diagramov, ktorých postupné vytváranie vám umožňuje získať úplný obraz o celom navrhnutom systéme a jeho jednotlivých komponentoch:

• Schéma prípadu použitia
• Diagram rozmiestnenia (topologické diagramy);
• stavový diagram;
• Interakčný diagram Diagram aktivity
• Sekvenčný diagram
• Diagram spolupráce
• Diagram triedy
• Schéma komponentov
• Diagramy správania
• Diagram aktivity
• Implementačné diagramy

& nbsp & nbsp & nbsp & nbsp Každý z týchto diagramov konkretizuje iný pohľad na model systému. V tomto prípade diagram prípadov použitia predstavuje konceptuálny model systému, ktorý je východiskovým bodom pre konštrukciu všetkých ostatných diagramov. Diagram tried je logický model, ktorý odráža statické aspekty štrukturálneho návrhu systému a diagramy správania, ktoré sú tiež variáciami logického modelu, odrážajú dynamické aspekty jeho fungovania. Implementačné diagramy sa používajú na znázornenie komponentov systému a odkazujú na jeho fyzický model.

& nbsp & nbsp & nbsp & nbsp Niektoré z vyššie uvedených diagramov sa používajú na označenie dvoch alebo viacerých poddruhov. Nasledujúce diagramy sa používajú ako nezávislé znázornenia: prípady použitia, triedy, stavy, aktivity, postupnosť, spolupráca, komponenty a nasadenia.

& nbsp & nbsp & nbsp & nbsp Existujú tri typy vizuálnych symbolov pre diagramy UML, ktoré sú dôležité z hľadiska informácií, ktoré obsahujú:

• spojenia, ktoré sú v rovine znázornené rôznymi čiarami;
• text obsiahnuté v hraniciach jednotlivých geometrických tvarov;
• grafické symboly nakreslené v blízkosti vizuálov máp.

& nbsp & nbsp & nbsp & nbsp Pri grafickom zobrazovaní diagramov sa odporúča dodržiavať nasledujúce pravidlá:

• každý diagram by mal byť úplnou reprezentáciou nejakého fragmentu simulovanej domény;
• entity modelu znázornené na diagrame musia mať rovnakú koncepčnú úroveň;
• všetky informácie o subjektoch musia byť v diagrame jasne znázornené;
• diagramy by nemali obsahovať protichodné informácie;
• diagramy by nemali byť preplnené textovými informáciami;
• každý diagram musí byť sebestačný na správnu interpretáciu všetkých jeho prvkov;
• počet typov diagramov potrebných na popis konkrétneho systému nie je presne stanovený a určuje ho vývojár;
• systémové modely musia obsahovať len tie prvky, ktoré sú definované v notácii UML.

Entity v UML

& nbsp & nbsp & nbsp & nbsp UML definuje štyri typy entít: štrukturálne, behaviorálne, zoskupovanie a anotácia... Entity sú hlavnými objektovo orientovanými prvkami jazyka, pomocou ktorého sa vytvárajú modely.

& nbsp & nbsp & nbsp & nbsp Štrukturálne entity sú podstatné mená v modeloch UML. Typicky predstavujú statické časti modelu, ktoré zodpovedajú koncepčným alebo fyzickým prvkom systému. Príkladmi štrukturálnych entít sú trieda, rozhranie, spolupráca, prípad použitia, komponent, uzol, aktér.

& nbsp & nbsp & nbsp & nbsp Behaviorálne entity sú dynamické komponenty modelu UML. Sú to slovesá, ktoré opisujú správanie modelu v čase a priestore. Existujú dva hlavné typy subjektov správania:

• interakcia je správanie, ktorého podstatou je výmena správ medzi objektmi v rámci špecifického kontextu na dosiahnutie konkrétneho cieľa;
• automat - algoritmus správania, ktorý určuje postupnosť stavov, ktorými objekt alebo interakcia prechádza v reakcii na rôzne udalosti.

& nbsp & nbsp & nbsp & nbsp Zoskupovanie subjektov sú organizačnými časťami modelu UML. Sú to bloky, na ktoré je možné model rozložiť. Existuje jediná kópia takejto primárnej entity - je to balík.

& nbsp & nbsp & nbsp & nbsp Balíky sú univerzálnym mechanizmom na organizovanie položiek do skupín. Do balíka je možné umiestniť štrukturálne, behaviorálne a iné zoskupovacie entity. Na rozdiel od komponentov, ktoré skutočne existujú počas spustenia programu, balíky sú čisto koncepčné, to znamená, že existujú iba počas procesu vývoja.

& nbsp & nbsp & nbsp & nbsp Entity anotácie sú vysvetľujúce časti modelu UML: komentáre pre dodatočný popis, objasnenie alebo poznámky k akémukoľvek prvku modelu. Existuje len jeden základný typ prvkov anotácie, anotácia. Poznámka sa používa na poskytnutie komentárov alebo obmedzení k diagramom, vyjadrené v neformálnom alebo formálnom texte.

Vzťahy v UML

& nbsp & nbsp & nbsp & nbsp V UML sú definované nasledujúce typy vzťahov: závislosť, asociácia, zovšeobecnenie a implementácia... Tieto vzťahy sú hlavnými konštruktmi lepidla v UML a sú tiež tým, ako sa entity používajú na vytváranie modelov.

& nbsp & nbsp & nbsp & nbsp Závislosť je sémantický vzťah medzi dvoma entitami, v ktorom zmena jednej z nich, nezávislej, môže ovplyvniť sémantiku druhej, závislej.

& nbsp & nbsp & nbsp & nbsp asociácie- štruktúrny vzťah, ktorý opisuje súbor sémantických alebo logických súvislostí medzi objektmi.

& nbsp & nbsp & nbsp & nbsp Zovšeobecnenie je vzťah, v ktorom môže byť objekt špecializovaného prvku (potomok) nahradený objektom všeobecného prvku (predok). Zároveň, v súlade s princípmi objektovo orientovaného programovania, dieťa zdedí štruktúru a správanie svojho rodiča (rodiča).

& nbsp & nbsp & nbsp & nbsp Realizácia je sémantický vzťah medzi klasifikátormi, v ktorom jeden klasifikátor definuje povinnosť a druhý zaručuje jej splnenie. Implementačný vzťah nastáva v dvoch prípadoch:

• medzi rozhraniami a triedami alebo komponentmi, ktoré ich implementujú;
• medzi prípadmi použitia a spoluprácami, ktoré ich implementujú.

Spoločné mechanizmy UML

& nbsp & nbsp & nbsp & nbsp Pre presný popis systému v UML sa používajú takzvané všeobecné mechanizmy:

• technické údaje;
• doplnky (ozdoby);
• divízie (spoločné divízie);
• mechanizmov rozšíriteľnosti.

& nbsp & nbsp & nbsp & nbsp UML nie je len grafický jazyk. Každý grafický prvok svojho zápisu má špecifikácia obsahujúci textovú reprezentáciu zodpovedajúceho jazykového konštruktu. Napríklad ikona triedy má špecifikáciu, ktorá popisuje jej atribúty, operácie a správanie, hoci vizuálne, v diagrame, ikona často odráža len malú časť týchto informácií. Okrem toho môže model obsahovať inú reprezentáciu tejto triedy, odrážajúc jej úplne iné aspekty, no napriek tomu zodpovedajúcu špecifikácii. Grafický zápis UML sa teda používa na vizualizáciu systému a pomocou špecifikácií popíše jeho detaily.

& nbsp & nbsp & nbsp & nbsp Takmer každý prvok UML má jedinečné grafické znázornenie, ktoré poskytuje vizuálnu reprezentáciu jeho najdôležitejších charakteristík. Zápis entity "class" obsahuje jej názov, atribúty a operácie. Špecifikácia triedy môže obsahovať ďalšie podrobnosti, ako napríklad viditeľnosť atribútov a operácií, komentáre alebo označenie, že trieda je abstraktná. Mnohé z týchto detailov je možné vykresliť ako grafiku alebo text. prílohy na štandardný obdĺžnik, ktorý predstavuje triedu.

& nbsp & nbsp & nbsp & nbsp Pri modelovaní objektovo orientovaných systémov existuje určitá divízie zastúpené subjekty.

& nbsp & nbsp & nbsp & nbsp Najprv je tu rozdelenie na triedy a objekty. Trieda je abstrakcia a objekt je konkrétnym stelesnením tejto abstrakcie. V tomto ohľade sa takmer všetky jazykové konštrukty vyznačujú dualitou triedy / objektu. Takže existujú prípady použitia a inštancie prípadov použitia, komponenty a inštancie komponentov, uzly a inštancie uzlov. V grafickom znázornení je zvykom používať rovnaký symbol pre objekt ako pre triedu a podčiarknuť názov.

& nbsp & nbsp & nbsp & nbsp Po druhé, je tu rozdelenie na rozhranie a jeho implementáciu. Rozhranie deklaruje záväzky a implementácia predstavuje konkrétne stelesnenie týchto záväzkov a zabezpečuje, že deklarovaná sémantika sa presne dodržiava. Z tohto dôvodu sa takmer všetky konštrukcie UML vyznačujú dualitou rozhrania/implementácie. Napríklad prípady použitia implementujú družstvá a operácie metódami.

& nbsp & nbsp & nbsp & nbsp UML je otvorený jazyk, to znamená, že umožňuje kontrolovaným rozšíreniam odrážať špecifiká doménových modelov.

& nbsp & nbsp & nbsp & nbsp Mechanizmy rozšírenia UML zahŕňajú:

• stereotypy (stereotypy) - rozširujú slovnú zásobu UML, umožňujúce na základe existujúcich jazykových prvkov vytvárať nové, ktoré sú zamerané na riešenie konkrétneho problému;
• tagovaná hodnota - rozširuje vlastnosti základných UML konštruktov, čo umožňuje zahrnutie dodatočných informácií do špecifikácie prvku;
• obmedzenia – rozširujú sémantiku konštruktov UML, čo vám umožňuje vytvárať nové a prepisovať existujúce pravidlá.

& nbsp & nbsp & nbsp & nbsp Tieto tri mechanizmy rozšírenia jazyka spolu umožňujú upravovať ho v súlade s potrebami projektu alebo osobitosťami technológie vývoja.

Schéma prípadu použitia

& nbsp & nbsp & nbsp & nbsp Tento typ diagramu vám umožňuje vytvoriť zoznam operácií, ktoré systém vykonáva. Tento typ diagramu sa často označuje ako funkčný diagram, pretože na základe súboru takýchto diagramov sa vytvára zoznam systémových požiadaviek a určuje sa súbor funkcií, ktoré systém vykonáva.

& nbsp & nbsp & nbsp & nbsp Diagramy prípadov použitia opisujú funkčnosť systému alebo to, čo má systém robiť. Vývoj diagramu má nasledujúce ciele:

• definovať všeobecné hranice a kontext simulovanej domény;
• formulovať všeobecné požiadavky na funkčné správanie navrhovaného systému;
• vypracovať prvotný koncepčný model systému pre jeho následné spresnenie vo forme logických a fyzických modelov;
• pripraviť počiatočnú dokumentáciu pre interakciu vývojárov systému s jeho zákazníkmi a používateľmi.

& nbsp & nbsp & nbsp & nbsp Podstata diagramu prípadu použitia je nasledovná. Navrhovaný systém je reprezentovaný ako súbor entít alebo aktérov interagujúcich so systémom prostredníctvom prípadov použitia. V tomto prípade je aktérom alebo aktérom akákoľvek entita, ktorá interaguje so systémom zvonku. Môže to byť osoba, technické zariadenie, program alebo akýkoľvek iný systém, ktorý môže slúžiť ako zdroj vplyvu na modelovaný systém, ako to určí samotný vývojár. Prípad použitia slúži na popis služieb, ktoré systém poskytuje aktérovi.

& nbsp & nbsp & nbsp & nbsp Účelom prípadu použitia je definovať úplný aspekt alebo fragment správania entity bez odhalenia jej vnútornej štruktúry. Takouto entitou môže byť systém alebo akýkoľvek prvok modelu, ktorý má svoje vlastné správanie.

& nbsp & nbsp & nbsp & nbsp Každý prípad použitia zodpovedá samostatnej službe, ktorú modelovaná entita poskytuje na žiadosť aktéra, to znamená, že určuje, ako sa táto entita používa. Služba, ktorá sa inicializuje na žiadosť aktéra, je úplný, nedeliteľný sled akcií. To znamená, že keď systém dokončí spracovanie požiadavky, musí sa vrátiť do pôvodného stavu, aby bol pripravený na vykonanie ďalších požiadaviek.

& nbsp & nbsp & nbsp & nbsp Prípady použitia možno použiť na špecifikáciu externých požiadaviek na navrhovaný systém, ako aj na špecifikáciu funkčného správania existujúceho systému. Súbor prípadov použitia ako celok by mal definovať všetky možné stránky očakávaného správania systému. Prípady použitia navyše implicitne stanovujú požiadavky, ktoré určujú, ako musia aktéri interagovať so systémom, aby mohli správne pracovať s poskytovanými službami. Pre pohodlie možno mnohé prípady použitia považovať za samostatný balík.

& nbsp & nbsp & nbsp & nbsp Príklady použitia môžu zahŕňať: kontrola stavu bežného účtu zákazníka, zadanie objednávky na nákup položky, získanie dodatočných informácií o bonite zákazníka, zobrazenie grafického formulára na obrazovke monitora a ďalšie akcie.

Diagram triedy

& nbsp & nbsp & nbsp & nbsp Centrálnym objektom objektovo orientovaného programovania je vývoj logického modelu systému vo forme diagramu tried. Diagram tried (class diagram) sa používa na reprezentáciu statickej štruktúry modelu systému v terminológii tried objektovo orientovaného programovania. Diagram tried môže odrážať najmä rôzne vzťahy medzi jednotlivými entitami domény, ako sú objekty a subsystémy, ako aj popisovať ich vnútornú štruktúru a typy vzťahov.

& nbsp & nbsp & nbsp & nbsp Ikony diagramu vám umožňujú zobraziť komplexnú hierarchiu systémov, vzťahov medzi triedami (triedy) a rozhraní (rozhrania). Tento typ diagramu je obsahovo opačný ako diagram Collaboration, ktorý zobrazuje systémové objekty. Rational Rose vám umožňuje vytvárať triedy pomocou tohto typu diagramu v rôznych zápisoch. ako oblak. Trieda je teda len šablóna, podľa ktorej sa v budúcnosti vytvorí konkrétny objekt.

& nbsp & nbsp & nbsp & nbsp Diagram tried je graf, ktorého vrcholy sú prvky typu „klasifikátor“, prepojené rôznymi typmi štruktúrnych vzťahov. Diagram tried môže obsahovať aj rozhrania, balíky, vzťahy a dokonca aj jednotlivé inštancie, ako sú objekty a vzťahy.

& nbsp & nbsp & nbsp & nbsp Trieda v jazyku UML sa používa na označenie množiny objektov, ktoré majú rovnakú štruktúru, správanie a vzťahy s objektmi iných tried. Trieda je graficky znázornená ako obdĺžnik, ktorý je možné dodatočne rozdeliť vodorovnými čiarami na sekcie alebo sekcie. Tieto časti môžu obsahovať názov triedy, atribúty (premenné) a operácie (metódy).

Stavový diagram (stavový diagram)

& nbsp & nbsp & nbsp & nbsp Každý stavový diagram v UML popisuje všetky možné stavy jednej inštancie určitej triedy a možné postupnosti jej prechodov z jedného stavu do druhého, to znamená, že modeluje všetky zmeny stavov objektu ako jeho reakcia na vonkajšie vplyvy.

& nbsp & nbsp & nbsp & nbsp Stavové diagramy sa najčastejšie používajú na popis správania jednotlivých objektov, ale môžu sa použiť aj na špecifikáciu funkčnosti iných komponentov modelu, ako sú prípady použitia, aktéri, subsystémy, operácie a metódy.

& nbsp & nbsp & nbsp & nbsp Stavový diagram je špeciálny druh grafu, ktorý predstavuje nejaký automat. Vrcholy grafu sú možné stavy automatu, znázornené príslušnými grafickými symbolmi, a oblúky označujú jeho prechody zo stavu do stavu. Stavové diagramy je možné vnoriť do seba pre detailnejšiu prezentáciu jednotlivých prvkov modelu.

& nbsp & nbsp & nbsp & nbsp V metamodeli UML stroj je balík, ktorý definuje súbor pojmov nevyhnutných na reprezentáciu správania modelovanej entity vo forme diskrétneho priestoru s konečným počtom stavov a prechodov.

& nbsp & nbsp & nbsp & nbsp Trvanie prítomnosti systému v ktoromkoľvek z možných stavov výrazne presahuje čas potrebný na prechod z jedného stavu do druhého. Predpokladá sa, že v limite môže byť čas prechodu rovný nule (pokiaľ nie je uvedené inak), to znamená, že zmena stavu objektu môže nastať okamžite.

& nbsp & nbsp & nbsp & nbsp Správanie sa stroja je modelované ako sekvenčný pohyb pozdĺž grafu od vrcholu k vrcholu, pričom sa berie do úvahy orientácia oblúkov, ktoré ich spájajú.

& nbsp & nbsp & nbsp & nbsp Pre stroj musia byť splnené nasledujúce predpoklady:

• stav, do ktorého sa objekt môže dostať, je určený iba jeho súčasným stavom a nezávisí od histórie;
• v každom časovom okamihu môže byť automat iba v jednom zo svojich stavov. Zároveň môže automat zostať v samostatnom stave ľubovoľne dlho, ak nenastanú žiadne udalosti;
• čas, keď je stroj v určitom stave, ako aj čas potrebný na dosiahnutie určitého stavu, nie sú nijako špecifikované;
• počet stavov automatu musí byť konečný a všetky musia byť explicitne špecifikované. Jednotlivé pseudostavy nemusia mať špecifikácie (počiatočný a konečný stav). V tomto prípade je ich účel a sémantika úplne určená z kontextu modelu a uvažovaného stavového diagramu;
• automatový graf by nemal obsahovať izolované stavy a prechody. Pre každý stav, okrem počiatočného, ​​musí byť definovaný predchádzajúci stav a každý prechod musí spájať dva stavy automatu;
• automat by nemal obsahovať konfliktné prechody, kedy objekt môže súčasne prejsť do dvoch alebo viacerých po sebe nasledujúcich stavov (okrem prípadu paralelných podautomatov). V UML sa možno konfliktom vyhnúť zavedením podmienok stráženia.

štátov je základom nielen v metamodeli UML, ale aj v aplikovanej systémovej analýze. Celý koncept dynamického systému je založený na koncepte štátu. Sémantika stavu v UML má množstvo špecifických čŕt.

& nbsp & nbsp & nbsp & nbsp V UML je stav abstraktná metatrieda používaná na modelovanie jedinej situácie, počas ktorej sú splnené určité podmienky. Stav môže byť špecifikovaný ako množina špecifických hodnôt pre atribúty triedy alebo objektu. Zmeny jednotlivých hodnôt atribútov budú odrážať zmeny v stave modelovanej triedy alebo objektu.

Diagram aktivity

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

& nbsp & nbsp & nbsp & nbsp Tento typ diagramov možno v skutočnosti použiť aj na vyjadrenie stavov modelovaného objektu, avšak hlavným účelom diagramu aktivity je odrážať obchodné procesy objektu. Tento typ diagramu umožňuje zobraziť nielen postupnosť procesov, ale aj vetvenie a dokonca synchronizáciu procesov.

& nbsp & nbsp & nbsp & nbsp Tento typ diagramov vám umožňuje navrhnúť algoritmy pre správanie objektov akejkoľvek zložitosti, vrátane, ktoré možno použiť na zostavenie blokových diagramov.

& nbsp & nbsp & nbsp & nbsp Diagramy aktivít sa používajú na modelovanie procesu vykonávania operácií v jazyku UML. Grafický zápis, ktorý používajú, je veľmi podobný zápisu stavového diagramu v tom, že zahŕňa aj stavy a prechody. Každý stav na diagrame aktivít zodpovedá vykonaniu nejakej elementárnej operácie a prechod do ďalšieho stavu sa vykoná až po dokončení tejto operácie.

& nbsp & nbsp & nbsp & nbsp Diagramy aktivít teda možno považovať za špeciálny prípad stavových diagramov. Umožňujú implementovať v jazyku UML vlastnosti procedurálneho a synchrónneho riadenia, kvôli dokončeniu interných činností a akcií. Hlavným smerom použitia diagramov aktivít je vizualizácia zvláštností implementácie operácií tried, keď je potrebné prezentovať algoritmy na ich vykonávanie.

& nbsp & nbsp & nbsp & nbsp V kontexte UML činnosť je súbor jednotlivých výpočtov vykonávaných strojom, vedúcich k nejakému výsledku alebo akcii (akcii). Diagram aktivít zobrazuje logiku a postupnosť prechodov z jednej aktivity do druhej a pozornosť analytika je zameraná na výsledky. Výsledok činnosti môže viesť k zmene stavu systému alebo k návratu nejakej hodnoty.

& nbsp & nbsp & nbsp & nbsp Akčný stav je špeciálny prípad stavu s nejakou vstupnou akciou a aspoň jedným prechodom opúšťajúcim stav. Tento prechod implicitne predpokladá, že vstupná akcia už bola dokončená. Akčný stav nemôže mať vnútorné prechody, pretože je elementárny. Bežným použitím akčného stavu je simulácia jedného kroku pri vykonávaní algoritmu (postupu) alebo riadiaceho toku.

Sekvenčný diagram

& nbsp & nbsp & nbsp & nbsp Pri zvažovaní diagramov stavov a aktivít sa zistilo, že hoci sa tieto diagramy používajú na špecifikáciu dynamiky správania systémov, čas v nich nie je explicitne prítomný. Časový aspekt správania môže mať značný význam pri modelovaní synchrónnych procesov, ktoré opisujú interakciu objektov. UML používa sekvenčné diagramy na modelovanie interakcie objektov v čase.

& nbsp & nbsp & nbsp & nbsp Sekvenčný diagram zobrazuje len tie predmety ktorí sú priamo zapojení do interakcie. Kľúčovým bodom pre sekvenčné diagramy je dynamika interakcie objektov v čase.

& nbsp & nbsp & nbsp & nbsp V UML má sekvenčný diagram dva rozmery. Prvý zľava doprava vo forme zvislých čiar, z ktorých každá zobrazuje líniu života samostatného objektu zúčastňujúceho sa interakcie. Úplne vľavo na diagrame je znázornený objekt, ktorý iniciuje interakciu. Napravo je zobrazený ďalší objekt, ktorý priamo interaguje s prvým. Všetky objekty v sekvenčnom diagrame teda tvoria nejaký druh poradia, určeného poradím alebo stupňom aktivity objektov pri vzájomnej interakcii.

& nbsp & nbsp & nbsp & nbsp Graficky je každý objekt znázornený ako obdĺžnik a nachádza sa na vrchu svojej životnej línie. Názov objektu a názov triedy sú napísané vo vnútri obdĺžnika oddelené dvojbodkou. V tomto prípade je celý záznam podčiarknutý, čo je vlastnosť objektu.

& nbsp & nbsp & nbsp & nbsp Druhým rozmerom sekvenčného diagramu je vertikálna časová os zhora nadol. Najvyššia časť diagramu zodpovedá počiatočnému okamihu v čase. Interakcie objektov sú implementované prostredníctvom správ, ktoré sa odosielajú z jedného objektu do druhého. Správy sa zobrazujú ako vodorovné šípky s názvom správy a ich poradie je určené časom výskytu. To znamená, že správy nachádzajúce sa v sekvenčnom diagrame vyššie sa spúšťajú skôr ako správy umiestnené nižšie. Mierka na časovej osi nie je uvedená, pretože sekvenčný diagram modeluje iba časové usporiadanie interakcií skôr a neskôr.

Diagram spolupráce

& nbsp & nbsp & nbsp & nbsp Hlavnou črtou diagramu spolupráce je schopnosť graficky znázorniť nielen postupnosť interakcie, ale aj všetky štrukturálne vzťahy medzi objektmi zúčastňujúcimi sa tejto interakcie.

& nbsp & nbsp & nbsp & nbsp Tento typ diagramu vám umožňuje opísať interakciu objektov abstrahujúcich od postupnosti prenosu správ. Všetky prijaté a odoslané správy konkrétneho objektu a typy týchto správ sú v tomto type diagramov premietnuté v kompaktnej forme.

& nbsp & nbsp & nbsp & nbsp V prvom rade kooperačný diagram vo forme obdĺžnikov zobrazuje objekty zúčastňujúce sa interakcie, ktoré obsahujú názov objektu, jeho triedu a prípadne hodnoty atribútov. Ďalej, ako v diagrame tried, asociácie medzi objektmi sú označené vo forme rôznych spojovacích čiar. V tomto prípade môžete explicitne špecifikovať názvy asociácie a úlohy, ktoré objekty v tejto asociácii zohrávajú. Okrem toho môžu byť zobrazené dynamické odkazy - toky správ. Sú tiež znázornené ako spojovacie čiary medzi objektmi, nad ktorými je šípka označujúca smer, názov správy a poradové číslo vo všeobecnom poradí inicializácie správy.

& nbsp & nbsp & nbsp & nbsp Na rozdiel od sekvenčného diagramu, diagram spolupráce zobrazuje iba vzťahy medzi objektmi, ktoré zohrávajú špecifické úlohy v interakcii. Tento graf nezobrazuje čas ako samostatnú dimenziu. Preto môže byť sekvencia interakcií a paralelných tokov určená pomocou sekvenčných čísel. Preto, ak potrebujete explicitne špecifikovať vzťahy medzi objektmi v reálnom čase, je najlepšie to urobiť v sekvenčnom diagrame.

& nbsp & nbsp & nbsp & nbsp Koncept spolupráce je jedným zo základných pojmov v UML. Slúži na označenie množiny objektov interagujúcich s konkrétnym účelom vo všeobecnom kontexte modelovaného systému. Účelom samotnej spolupráce je špecifikovať vlastnosti implementácie jednotlivých najvýznamnejších operácií v systéme. Kooperácia definuje štruktúru správania systému z hľadiska interakcie účastníkov tejto spolupráce.

& nbsp & nbsp & nbsp & nbsp Spoluprácu možno prezentovať na dvoch úrovniach:

• úroveň špecifikácie - zobrazuje úlohy klasifikátorov a úlohu asociácií v uvažovanej interakcii;
• úroveň príkladu – označuje inštancie a vzťahy, ktoré tvoria samostatné roly v spolupráci.

& nbsp & nbsp & nbsp & nbsp Diagram spolupráce na úrovni kusovníka zobrazuje úlohy, ktoré zohrávajú prvky zapojené do interakcie. Prvkami spolupráce na tejto úrovni sú triedy a asociácie, ktoré označujú samostatné roly klasifikátorov a asociácií medzi účastníkmi spolupráce.

& nbsp & nbsp & nbsp & nbsp Diagram spolupráce na úrovni príkladu predstavuje kolekcia objektov (inštancie tried) a vzťahov (inštancie asociácie). V tomto prípade sú odkazy doplnené o šípky správ. Na tejto úrovni sú zobrazené iba objekty, ktoré priamo súvisia s implementáciou operácie alebo klasifikátora. V tomto prípade nie je vôbec potrebné znázorňovať všetky vlastnosti alebo všetky asociácie, pretože v diagrame spolupráce sú prítomné iba roly klasifikátorov, ale nie samotné klasifikátory. Kým teda klasifikátor vyžaduje úplný popis všetkých svojich inštancií, rola klasifikátora vyžaduje popis len tých vlastností a asociácií, ktoré sú nevyhnutné na účasť na konkrétnej spolupráci.

& nbsp & nbsp & nbsp & nbsp Z toho vyplýva dôležitý dôsledok. Jeden a ten istý súbor objektov sa môže zúčastniť rôznych družstiev. V závislosti od uvažovanej spolupráce sa môžu meniť ako vlastnosti jednotlivých objektov, tak aj väzby medzi nimi. To je to, čo odlišuje diagram spolupráce od diagramu tried, ktorý musí označovať všetky vlastnosti a asociácie medzi prvkami diagramu.

Schéma komponentov

& nbsp & nbsp & nbsp & nbsp Tento typ diagramu je určený na distribúciu tried a objektov podľa komponentov vo fyzickom dizajne systému. Tento typ diagramu sa často označuje ako jednotkové diagramy.

& nbsp & nbsp & nbsp & nbsp Kompletný návrh softvérového systému je súbor modelov logickej a fyzickej úrovne, ktoré musia byť navzájom konzistentné. UML používa implementačné diagramy na fyzickú reprezentáciu modelov systémov, ktoré zahŕňajú diagram komponentov a diagram nasadenia.

& nbsp & nbsp & nbsp & nbsp Diagram komponentov, na rozdiel od predtým uvažovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Umožňuje vám definovať architektúru vyvíjaného systému vytvorením závislostí medzi softvérovými komponentmi, ktorými môže byť zdrojový a spustiteľný kód. Hlavnými grafickými prvkami diagramu komponentov sú komponenty, rozhrania a ich závislosti.

& nbsp & nbsp & nbsp & nbsp Diagram komponentov je vyvinutý na nasledujúce účely:

• vizualizácia všeobecnej štruktúry zdrojového kódu softvérového systému;
• špecifikácie spustiteľnej verzie softvérového systému;
• zabezpečenie opätovnej použiteľnosti jednotlivých fragmentov programového kódu;
• reprezentácie koncepčných a fyzických databázových schém.

& nbsp & nbsp & nbsp & nbsp Na vývoji diagramov komponentov sa podieľajú systémoví analytici a architekti, ako aj programátori. Komponentový diagram poskytuje konzistentný prechod od logického pohľadu ku konkrétnej implementácii projektu vo forme programového kódu. Niektoré komponenty môžu existovať iba v štádiu kompilácie programového kódu, iné v štádiu jeho vykonávania. Diagram komponentov odráža všeobecné závislosti medzi komponentmi, pričom tieto komponenty považujeme za klasifikátory.

& nbsp & nbsp & nbsp & nbsp Na znázornenie fyzických entít v jazyku UML sa používa špeciálny výraz - komponent... Komponent implementuje určitú množinu rozhraní a slúži na všeobecné označenie prvkov fyzickej reprezentácie modelu. Na grafické znázornenie súčiastky sa používa špeciálny symbol - obdĺžnik s dvoma menšími obdĺžnikmi vloženými vľavo. Vo vnútri veľkého obdĺžnika je napísaný názov komponentu a v prípade potreby nejaké ďalšie informácie. Vyobrazenie tohto symbolu sa môže mierne líšiť v závislosti od povahy informácií spojených s komponentom.

Schéma nasadenia

& nbsp & nbsp & nbsp & nbsp Tento typ diagramov je určený na analýzu hardvéru systému, teda „hardvéru“, a nie programov. V priamom preklade z angličtiny Deployment znamená „rozmiestnenie“, ale výraz „topológia“ presnejšie odráža podstatu tohto typu diagramov.

& nbsp & nbsp & nbsp & nbsp Fyzická reprezentácia softvérového systému nemôže byť úplná, ak neexistujú informácie o tom, na akej platforme a na akých výpočtových prostriedkoch je implementovaný. Ak sa vyvíja program, ktorý beží lokálne na počítači používateľa a nepoužíva periférne zariadenia a zdroje, potom nie je potrebné vyvíjať ďalšie diagramy. Pri vývoji podnikových aplikácií môže byť prítomnosť takýchto diagramov mimoriadne užitočná pri riešení problémov s racionálnym umiestnením komponentov s cieľom efektívne využívať distribuované výpočtové a komunikačné zdroje siete, zaistiť bezpečnosť a iné.

& nbsp & nbsp & nbsp & nbsp Diagramy nasadenia sú navrhnuté tak, aby reprezentovali celkovú konfiguráciu a topológiu distribuovaného softvérového systému v UML.

& nbsp & nbsp & nbsp & nbsp Diagram nasadenia je určený na vizualizáciu prvkov a komponentov programu, ktoré existujú iba vo fáze jeho vykonávania (runtime). V tomto prípade sú prezentované iba komponenty-inštancie programu, ktorými sú spustiteľné súbory alebo dynamické knižnice. Komponenty, ktoré sa nepoužívajú za behu, nie sú zobrazené v diagrame nasadenia. Komponenty so zdrojovými kódmi programov teda môžu byť prítomné iba v diagrame komponentov. Nie sú zobrazené v diagrame nasadenia.

& nbsp & nbsp & nbsp & nbsp Diagram nasadenia obsahuje grafické znázornenia procesorov, zariadení, procesov a vzťahov medzi nimi. Na rozdiel od diagramov logického zobrazenia je diagram nasadenia jednotný pre systém ako celok, pretože musí plne odrážať špecifiká jeho implementácie. Vytvorenie diagramu nasadenia je zvyčajne posledným krokom v špecifikácii modelu softvérového systému.

& nbsp & nbsp & nbsp & nbsp Pri vývoji diagramu nasadenia sa sledujú tieto ciele:

• určiť rozloženie komponentov systému podľa jeho fyzických uzlov;
• ukázať fyzické spojenia medzi všetkými uzlami implementácie systému vo fáze jeho vykonávania;
• identifikovať úzke miesta v systéme a prekonfigurovať jeho topológiu na dosiahnutie požadovaného výkonu.

& nbsp & nbsp & nbsp & nbsp Diagramy nasadenia spoločne vyvíjajú systémoví analytici, sieťoví inžinieri a systémoví inžinieri.

Funkcie desktopového rozhrania Rational Rose

& nbsp & nbsp & nbsp & nbsp Nástroj Rational Rose CASE implementuje všeobecne akceptované štandardy pre pracovné rozhranie programu, podobne ako známe vizuálne programovacie prostredia. Po nainštalovaní Rational Rose na počítač používateľa, ktorý prakticky nerobí ťažkosti ani začiatočníkom, sa spustením tohto programu v prostredí MS Windows 95/98 na obrazovke objaví pracovné rozhranie (obr. 6).

Obrázok - 6. Celkový pohľad na pracovné rozhranie programu Rational Rose

& nbsp & nbsp & nbsp & nbsp Pracovné rozhranie Rational Rose pozostáva z rôznych prvkov, z ktorých hlavné sú:

• Hlavné menu programu
• Okno diagramu
• Okno dokumentácie
• Okno prehliadača
• Okno denníka

Stručne zvážime účel a hlavné funkcie každého z týchto prvkov.

Hlavné menu programu

Hlavné menu programu je vyhotovené vo všeobecne uznávanom štandarde a má nasledovnú podobu (obr. 7).

Jednotlivé položky menu, ktorých účel je jasný už z ich názvov, v sebe spájajú podobné operácie súvisiace s celým projektom ako celkom. Niektoré položky ponuky obsahujú známe funkcie (otvorenie projektu, výstup a tlač diagramov, kopírovanie do schránky a vkladanie rôznych prvkov diagramu zo schránky). Iné sú také špecifické, že môžu vyžadovať dodatočné úsilie na učenie (možnosti generovania programového kódu, kontrola konzistencie modelov, pripojenie ďalších modulov).

Obrázok - 7. Vzhľad hlavnej ponuky programu

Štandardný panel nástrojov

Štandardný panel nástrojov sa nachádza pod hlavným menu programu a vyzerá takto (obr. 8). Niektoré nástroje nie sú dostupné (nový projekt nemá žiadne položky). Štandardný panel nástrojov poskytuje rýchly prístup k príkazom ponuky, ktoré vývojári vykonávajú najčastejšie.

Obrázok - 8. Vzhľad štandardného panela nástrojov

Používateľ si môže prispôsobiť vzhľad tohto panelu podľa vlastného uváženia. Ak to chcete urobiť, vyberte položku ponuky Nástroje -> Možnosti a otvorte kartu Panely s nástrojmi. Týmto spôsobom môžete zobraziť alebo skryť rôzne tlačidlá nástrojov a zmeniť ich veľkosť.

Okno prehliadača

Štandardne sa okno prehliadača nachádza na ľavej strane pracovného rozhrania pod štandardným panelom nástrojov (obr. 9).

Prehliadač organizuje zobrazenia modelu do hierarchickej štruktúry, ktorá zjednodušuje navigáciu a umožňuje vám nájsť akýkoľvek prvok modelu vo vašom projekte. V tomto prípade sa akýkoľvek prvok, ktorý vývojár pridá do modelu, okamžite zobrazí v okne prehliadača. Po výbere prvku v okne prehliadača ho teda môžeme vizualizovať v okne diagramu alebo zmeniť jeho špecifikáciu. Prehliadač vám tiež umožňuje organizovať položky modelu do balíkov a presúvať položky medzi rôznymi zobrazeniami modelu. V prípade potreby je možné okno prehliadača umiestniť na iné miesto pracovného rozhrania alebo ho úplne skryť pomocou položky ponuky Zobraziť. Veľkosť prehliadača môžete zmeniť aj potiahnutím okraja jeho vonkajšieho rámca.

Obrázok - 9. Vzhľad prehliadača

Vyhradený panel nástrojov

Špeciálny panel nástrojov sa nachádza medzi oknom prehliadača a oknom diagramu v strede pracovného rozhrania. Štandardne sa ponúka panel nástrojov na zostavenie diagramu tried modelu (obr. 10).

Obrázok - 10. Vzhľad špeciálneho panela nástrojov diagramu tried

Umiestnenie špeciálneho panela nástrojov môžete zmeniť presunutím rámu panela nástrojov na požadované miesto. Zloženie panela si môžete prispôsobiť aj pridaním alebo odstránením jednotlivých tlačidiel zodpovedajúcich určitým nástrojom. Priradenia tlačidiel nájdete v popisoch, ktoré sa zobrazia po pozastavení kurzora myši nad príslušným tlačidlom.

Okno diagramu

Okno diagramu je hlavnou pracovnou oblasťou jeho rozhrania, v ktorej sú vizualizované rôzne pohľady na model projektu. Štandardne je okno diagramu umiestnené na pravej strane pracovného rozhrania, ale jeho umiestnenie a veľkosť je možné tiež zmeniť. Pri vývoji nového projektu, ak nebol použitý sprievodca projektom, je okno diagramu prázdnou oblasťou, ktorá neobsahuje žiadne prvky modelu (obr. 11).

Názov diagramu, ktorý sa nachádza v tomto okne, je uvedený v záhlaví programu (najvrchnejší riadok programu) alebo, ak okno nie je rozšírené na celú obrazovku, v záhlaví okna diagramu. V okne diagramu môže byť súčasne niekoľko diagramov, ale aktívny môže byť iba jeden z nich. Napríklad na obr. 11, diagram nasadenia je aktívny, aj keď sú k dispozícii ďalšie diagramy. Prepínanie medzi diagramami je možné vykonať výberom požadovaného zobrazenia na štandardnom paneli nástrojov alebo cez položku ponuky Okno. Pri aktivácii samostatného typu diagramu sa zmení vzhľad špeciálneho panela nástrojov, ktorý je upravený pre konkrétny typ diagramu.

Obrázok - 11. Vzhľad okna diagramu s rôznymi pohľadmi na model

Okno dokumentácie

Na obrazovke sa nemusí nachádzať predvolené okno dokumentácie. V tomto prípade sa dá aktivovať cez položku ponuky Zobraziť -> Dokumentácia, po ktorej sa zobrazí pod prehliadačom (obr. 12).

Okno dokumentácie, ako už názov napovedá, slúži na dokumentáciu prvkov zobrazenia modelu. Môžete do nej písať rôzne informácie a čo je dôležité - v ruštine. Tieto informácie sú následne prevedené na komentáre a nijako neovplyvňujú logiku vykonávania programového kódu.

V okne dokumentácie sa aktivujú informácie, ktoré sa týkajú samostatného vybraného prvku diagramu. V tomto prípade môžete vybrať prvok buď v okne prehliadača alebo v okne diagramu. Keď sa do diagramu pridá nový prvok (napríklad trieda), automaticky sa vygeneruje jeho dokumentácia, ktorá je prázdna (Žiadna dokumentácia). Následne vývojár samostatne uvedie potrebné vysvetľujúce informácie, ktoré sa zapamätajú a môžu sa počas práce na projekte meniť.

Rovnako ako pre ostatné okná pracovného rozhrania môžete zmeniť veľkosť a polohu okna dokumentácie.

Obrázok - 12. Vzhľad okna dokumentácie

Okno denníka

Okno Protokol je určené na automatické zaznamenávanie rôznych servisných informácií generovaných pri práci s programom. Protokol zaznamenáva čas a povahu akcií vývojára, ako je aktualizácia modelu, prispôsobenie ponúk a panelov nástrojov a chybové hlásenia, ktoré sa vyskytujú pri generovaní programového kódu.

Okno protokolu je vždy prítomné na pracovnom rozhraní v oblasti okna diagramu (obr. 13). Dá sa však uzavrieť inými oknami diagramu alebo minimalizovať. Okno protokolu môžete aktivovať cez ponuku Okno-> Protokol. V tomto prípade sa zobrazuje nad ostatnými oknami v pravom paneli pracovného rozhrania. Toto okno nie je možné úplne odstrániť, možno ho iba minimalizovať.

Obrázok - 13. Vzhľad okna denníka

Záver

& nbsp & nbsp & nbsp & nbsp Postupom času sa UML stane „esperantom“, v ktorom môžu komunikovať matematici, systémoví analytici, fyzici, programátori, manažéri, ekonómovia a špecialisti iných profesií a prezentovať svoje odborné znalosti v jednotnej forme. Koniec koncov, v podstate každý zo špecialistov pracuje s modelovými konceptmi vo svojej oblasti vedomostí. A práve tento aspekt modelu je možné špecifikovať pomocou jazyka UML.

& nbsp & nbsp & nbsp & nbsp V tomto smere význam jazyka UML výrazne narastá, keďže čoraz viac nadobúda vlastnosti jazyka reprezentujúceho znalosti. Prítomnosť obrazových prostriedkov na reprezentáciu štruktúry a správania modelu v UML zároveň umožňuje dosiahnuť adekvátnu reprezentáciu deklaratívnych a procedurálnych znalostí a nemenej dôležité vytvoriť sémantickú korešpondenciu medzi týmito formami vedomosti. Všetky tieto vlastnosti UML nám umožňujú dospieť k záveru, že má najvážnejšie vyhliadky v blízkej budúcnosti.

Tento článok skúma novú éru vývoja softvéru, jej vplyv na nové požiadavky na UML a osvedčené postupy na ich splnenie.
& nbsp 7. "Dátové modelovanie v Rational Rose" Sergey Trofimov Opisuje modelovanie reprezentácie fyzických údajov pomocou Rational Rose
& nbsp 8. Jazyk UML. Všeobecné pochopenie jazyka UML: štruktúry, grafické prvky a diagramy jazyka.
& nbsp 9. Praktické UML. Tento dokument je prekladom Praktického UML Praktický úvod pre vývojárov. Praktický úvod pre vývojárov
& nbsp 10. "Štandardný jazyk objektovo orientovaného modelovania UML" Vendrov Alexander Michajlovič. História UML
& nbsp 11. UML je jednotný modelovací jazyk. Tento materiál obsahuje počiatočné informácie o metódach popisu softvérových systémov a notácií používaných v UML.
& nbsp 12. Jazyk UML. Užívateľská príručka. Autor: Grady Booch, James Rambeau, Ivar Jacobson
& nbsp 13. "UML diagramy v Rational Rose" Sergey Trofimov
& nbsp 14. "Analýza a dizajn. Vizuálne modelovanie (UML) Rational Rose" Konstantin Domolego
& nbsp 15. Knižnica Gennadija Vernikova. Kompletný popis štandardov dizajnu a modelovania.
& nbsp 16. „Príklad opisu predmetnej oblasti pomocou UML pri vývoji softvérových systémov“ Ye.B. Zolotukhina, R.V. Alfimov. Článok demonštruje konkrétny príklad možného prístupu k modelovaniu domén založenému na použití Unified Modeling Language (UML)

& nbsp & nbsp & nbsp & nbsp

UML diagram je špecializovaný grafický popisný jazyk určený na objektové modelovanie pri vývoji rôznych softvérov. Tento jazyk má široký profil a je otvoreným štandardom, ktorý využíva rôzne grafické zápisy na vytvorenie abstraktného modelu systému. UML bol vytvorený s cieľom poskytnúť 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ť na jeho základe vygenerovať samostatný kód.

Prečo je to potrebné?

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, vykonávanie systémového inžinierstva, ako aj na zobrazovanie organizačných štruktúr.

Pomocou UML môžu vývojári softvéru presadiť úplnú konvenciu v grafických zápisoch používaných na reprezentáciu všeobecných pojmov, ako sú komponent, zovšeobecnenie, trieda, správanie a agregácia. Tým sa dosiahne väčšia miera zamerania na architektúru a dizajn.

Za zmienku tiež stojí, že existuje niekoľko typov takýchto diagramov.

Diagram triedy

Diagram tried UML je diagram statickej štruktúry 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ý. V tomto prípade diagram tried UML popisuje model špecifickej domény a sú v ňom poskytnuté iba triedy aplikovaných objektov.
• Š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.

Schéma komponentov

Diagram komponentov UML je plne statický štrukturálny diagram. Má demonštrovať rozdelenie určitého softvérového systému na rôzne štrukturálne komponenty, ako aj súvislosti medzi nimi. Diagram komponentov UML ako taký môže využívať všetky druhy modelov, knižníc, súborov, balíkov, spustiteľných súborov a mnoho ďalších prvkov.

Zložený / zložený diagram štruktúry

UML Composite / Composite Structure Diagram je tiež statický štruktúrny diagram, ale používa sa na zobrazenie vnútornej štruktúry tried. Ak je to možné, tento diagram môže tiež demonštrovať interakciu prvkov nachádzajúcich sa vo vnútornej štruktúre triedy.

Ich podtypom je UML-diagram spolupráce, ktorý sa používa na demonštráciu rolí, ako aj interakcie rôznych tried v rámci hraníc spolupráce. Sú celkom praktické, keď potrebujete modelovať dizajnové vzory.

Stojí za zmienku, že typy diagramov tried UML a typy zložených štruktúr môžu byť použité súčasne.

Schéma nasadenia

Tento diagram sa používa na simuláciu pracovných uzlov, ako aj všetkých druhov artefaktov, ktoré do nich boli nasadené. UML 2 nasadzuje artefakty do rôznych uzlov, zatiaľ čo prvá verzia nasadzuje výhradne komponenty. Diagram nasadenia UML teda využíva predovšetkým druhá verzia.

Medzi artefaktom a komponentom, ktorý implementuje, sa vytvorí zjavná závislosť.

Schéma 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 väzieb 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ťah medzi nimi. V tomto prípade neexistuje prísne oddelenie medzi niekoľkými štrukturálnymi diagramami, v dôsledku čoho sa s ich použitím najčastejšie stretávame len pre pohodlie a nenesie ž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, zjednodušiť štruktúru a tiež organizovať prácu s modelom tohto systému.

Diagram aktivity

Diagram aktivity UML zobrazuje rozklad špecifickej aktivity na niekoľko častí. V tomto prípade pojem „činnosť“ označuje špecifikáciu 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 vláknami pochádzajúcimi z výstupy 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 automatu

Tento pohľad sa tiež nazýva stavový diagram UML. Má prezentovaný stavový automat s jednoduchými a zloženými stavmi a prechodmi.

Stavový automat je špecifikácia postupnosti rôznych stavov, ktorými prechádza určitý objekt, alebo interakcia v reakcii na niektoré udalosti v jeho živote, ako aj reakcie 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í.

Ako analógy takýchto diagramov možno použiť takzvané dračie schémy.

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 prípady použitia. Jeho hlavnou úlohou je poskytnúť sám seba ako plnohodnotný prostriedok, pomocou ktorého môže zákazník, koncový používateľ alebo nejaký vývojár spoločne diskutovať o správaní a funkčnosti konkrétneho systému.

Ak sa v procese modelovania systému použije diagram prípadu použitia UML, analytik sa chystá:

• Jasne oddeľte simulovaný 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 si v slovníku ako predmet rôzne pojmy, ktoré súvisia s podrobným popisom funkčnosti tohto systému.

Ak je diagram použitia vytvorený v UML, postup začína textovým popisom, ktorý sa získa pri práci so zákazníkom. Zároveň stojí za zmienku skutočnosť, že rôzne nefunkčné požiadavky v procese zostavovania modelu prípadov použitia sú úplne vynechané a už pre ne bude vytvorený samostatný dokument.

komunikácie

Komunikačný diagram, rovnako ako sekvenčný diagram UML, je tranzitívny, to znamená, že vyjadruje interakciu sám o sebe, ale zároveň ju demonštruje rôznymi spôsobmi, a ak je to potrebné, s požadovaným stupňom presnosti ho môžete transformovať. do iného.

Komunikačný diagram zobrazuje interakcie, ktoré sa vyskytujú medzi rôznymi prvkami zloženej štruktúry, ako aj úlohy spolupráce. Hlavný rozdiel oproti sekvenčnému diagramu je v tom, že jasne ukazuje vzťah medzi niekoľkými prvkami a čas sa nepoužíva ako samostatná dimenzia.

Tento typ sa vyznačuje úplne voľným formátom na objednanie viacerých objektov a odkazov rovnakým spôsobom, ako sa to robí v diagrame objektov. Ak je potrebné zachovať poradie správ v tomto voľnom formáte, sú chronologicky očíslované. Čítanie tohto diagramu začína pôvodnou správou 1.0 a potom pokračuje v smere, v ktorom sa správy prenášajú z jedného objektu do druhého.

Väčšina z týchto diagramov zobrazuje presne tie isté informácie, ktoré nám poskytuje sekvenčný diagram, avšak 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ý jednotlivý prvok interaguje, zatiaľ čo sekvenčný diagram jasnejšie ukazuje, v akom poradí interakcie prebiehajú.

Sekvenčný diagram

Sekvenčný diagram UML demonštruje interakcie medzi viacerými objektmi, ktoré sú usporiadané podľa času ich výskytu. Tento diagram zobrazuje časovo usporiadané interakcie medzi viacerými objektmi. Zobrazuje najmä všetky objekty, ktoré sa zúčastňujú interakcie, ako aj kompletnú sekvenciu správ, ktoré si vymieňajú.

Hlavnými prvkami sú v tomto prípade označenia rôznych objektov, ako aj zvislé čiary znázorňujúce plynutie času a obdĺžniky, ktoré zabezpečujú činnosť konkrétneho objektu alebo vykonávanie akejkoľvek funkcie.

Diagram spolupráce

Tento typ diagramov vám umožňuje demonštrovať interakcie medzi niekoľkými objektmi abstrahovať od postupnosti vysielaných správ. Tento typ diagramov v kompaktnej forme zobrazuje absolútne všetky odoslané a prijaté správy určitého objektu, ako aj formáty týchto správ.

Vzhľadom na to, že sekvenčné diagramy a komunikačné diagramy sú jednoducho rozdielne pohľady na rovnaké postupy, Rational Rose poskytuje možnosť vytvárať komunikačný diagram zo sekvenčného diagramu alebo naopak, ako aj ich plne automaticky synchronizovať.

Grafy prehľadu interakcií

Sú to diagramy UML, ktoré sú podmnožinou diagramov aktivít, ktoré zahŕňajú prvky sekvencie aj konštrukty toku riadenia.

Za zmienku stojí skutočnosť, že tento formát kombinuje diagramy spolupráce a sekvencie, ktoré poskytujú príležitosť z rôznych uhlov pohľadu zvážiť interakciu medzi niekoľkými objektmi vo vytváranom systéme.

Schéma synchronizácie

Ide o alternatívny sekvenčný diagram, ktorý jasne ukazuje zmenu stavu na záchrannom lane so špecifickou časovou mierkou. Môže byť celkom užitočný v rôznych aplikáciách v reálnom čase.

Aké sú výhody?

Stojí za zmienku 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 vykonanej analýzy a návrhu sémanticky blízke programovacím metódam vo všetkých druhoch objektovo orientovaných jazykov moderného typu.
• Pomocou tohto jazyka je možné systém popísať takmer z akéhokoľvek možného uhla pohľadu a rovnakým spôsobom sú popísané rôzne aspekty jeho správania.
• Všetky diagramy sú relatívne ľahko čitateľné aj po pomerne rýchlom oboznámení sa s ich syntaxou.
• UML umožňuje rozširovať, ale aj zavádzať vlastné grafické a textové stereotypy, čo prispieva k jeho využitiu 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 vytváranie UML diagramov má veľa svojich výhod, pomerne často sú kritizované za tieto nedostatky:

• Nadbytok. Vo veľkej väčšine prípadov kritici tvrdia, že UML je príliš veľký a zložitý a často je to neopodstatnené. Obsahuje množstvo nadbytočných alebo prakticky zbytočných konštrukcií a schém a najčastejšie takáto kritika smeruje k druhej verzii a nie k prvej, pretože v novších revíziách je viac kompromisov „vypracovaných výborom“.
• Rôzne sémantické nepresnosti. Pretože UML je definovaný kombináciou seba, angličtiny a OCL, chýba mu tuhosť, ktorá je vlastná jazykom presne definovaným technikou formálneho popisu. V určitých situáciách si abstraktná syntax OCL, UML a angličtiny začnú navzájom protirečiť, zatiaľ čo v iných prípadoch sú neúplné. Nepresný popis samotného jazyka ovplyvňuje používateľov aj poskytovateľov nástrojov, čo v konečnom dôsledku vedie k nekompatibilite nástrojov v dôsledku jedinečného spôsobu interpretácie rôznych špecifikácií.
• Problémy v procese implementácie a štúdia. Všetky vyššie uvedené problémy spôsobujú určité ťažkosti v procese zavádzania a učenia sa UML, a to platí najmä vtedy, keď vedenie núti inžinierov používať ho násilne, pričom nemajú predchádzajúce zručnosti.
• Kód odzrkadľuje 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. V súlade s týmto názorom je potrebné vyvinúť efektívnejší spôsob písania softvéru. UML sa oceňuje pre prístupy, ktoré kompilujú modely na regeneráciu spustiteľného alebo zdrojového kódu. 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ý tým, čo môže interpretačný nástroj UML predpokladať alebo definovať.
• 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ť výstup iného systému. Ako každý štandardný notačný systém, aj UML môže reprezentovať niektoré systémy efektívnejším a stručnejším spôsobom ako iné. Vývojár je teda viac naklonený tým riešeniam, ktoré sú pohodlnejšie na tkanie všetkých silných stránok UML, ako aj iných programovacích jazykov. Tento problém je zrejmejší v prípade, že vývojový jazyk nezodpovedá základným princípom objektovo orientovanej ortodoxnej doktríny, to znamená, že sa nesnaží pracovať v súlade s princípmi OOP.
• Snaží sa byť všestranný. UML je univerzálny modelovací jazyk, ktorý sa snaží byť kompatibilný s akýmkoľvek dnes dostupným jazykom spracovania. V kontexte konkrétneho projektu, aby tím dizajnérov mohol dosiahnuť konečný cieľ, je potrebné vybrať použiteľné schopnosti daného jazyka. Okrem toho možné spôsoby obmedzenia rozsahu UML v konkrétnej oblasti prechádzajú formalizmom, ktorý nie je úplne formulovaný, ale ktorý je sám osebe predmetom kritiky.

Použitie tohto jazyka teda nie je relevantné vo všetkých situáciách.