Tento typ diagramu je určený na distribúciu tried a objektov do komponentov vo fyzickom návrhu systému. Tento typ diagramu sa často označuje ako modulové diagramy.
Diagram komponentov, na rozdiel od predtým diskutovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Diagram komponentov vám umožňuje určiť architektúru vyvíjaného systému vytvorením závislostí medzi softvérovými komponentmi, ktorými môžu byť zdrojový, binárny a spustiteľný kód. V mnohých vývojových prostrediach modul alebo komponent zodpovedá súboru. Bodkované šípky spájajúce moduly zobrazujú vzťahy závislostí podobné tým, ktoré sa vyskytujú pri kompilácii zdrojového kódu programu. Hlavnými grafickými prvkami diagramu komponentov sú komponenty, rozhrania a závislosti medzi nimi.
Pre vizuálnejšiu reprezentáciu komponentov boli navrhnuté nasledujúce grafické stereotypy, ktoré sa stali všeobecne akceptovanými:
Po prvé, existujú stereotypy pre komponenty nasadenia, ktoré umožňujú systému priamo vykonávať svoje funkcie. Takýmito komponentmi môžu byť dynamicky prepojené knižnice (obr. 12, a), webové stránky v hypertextovom značkovacom jazyku (obr. 12, b) a súbory pomocníka (obr. 12, c).
Po druhé, stereotypy pre komponenty vo forme pracovných produktov. Spravidla ide o súbory so zdrojovými textami programu (obr. 12, d).
Ďalším spôsobom, ako špecifikovať rôzne druhy komponentov, je špecifikovať stereotyp textu komponentu pred jeho názvom. UML definuje nasledujúce stereotypy pre komponenty:
> (tabuľka) - definuje druh komponentu, ktorý je prezentovaný vo forme databázovej tabuľky.
Rozhrania
Existujú dva spôsoby komunikácie medzi rozhraním a komponentom. Ak komponent implementuje nejaké rozhranie, tak takéto rozhranie sa nazýva exportované resp podporované, keďže tento komponent to poskytuje ako službu iným komponentom. Ak komponent používa nejaké rozhranie, ktoré je implementované iným komponentom, potom sa takéto rozhranie pre prvý komponent nazýva importované. Zvláštnosťou importovaného rozhrania je, že tento vzťah je znázornený v diagrame komponentov pomocou závislosti.
Diagram komponentov môže tiež reprezentovať vzťahy závislostí medzi komponentmi a triedami, ktoré implementujú. Tieto informácie sú dôležité na zabezpečenie toho, aby logické a fyzické reprezentácie modelu systému boli konzistentné. Samozrejme, zmeny v štruktúre deklarácií tried môžu túto závislosť zmeniť. Nižšie je uvedený fragment závislosti tohto druhu, keď spustiteľný komponent Control .exe závisí od zodpovedajúcich tried
Ryža. Grafické znázornenie závislosti medzi komponentom a triedami.
V tomto prípade diagram komponentu neznamená, že triedy sú implementované komponentom. Ak chcete zdôrazniť, že niektorý komponent implementuje samostatné triedy, potom sa na označenie komponentu používa symbol rozšíreného rámčeka. V tomto prípade je obdĺžnik komponentu rozdelený na dve časti vodorovnou čiarou. Horná časť sa používa na zaznamenanie názvu komponentu a prípadne ďalších informácií a spodná časť označuje triedy implementované týmto komponentom.
Unified Modeling Language (UML) je jazyk na špecifikovanie, vizualizáciu, navrhovanie a dokumentovanie softvérových systémov, ako aj obchodných modelov a iných nesoftvérových systémov. UML je kombináciou inžinierskych techník, ktoré boli predtým úspešne použité pri modelovaní veľkých a zložitých systémov.
Tvorcovia jazyka UML ho považujú za jazyk na definovanie, reprezentáciu, navrhovanie a dokumentovanie softvérových systémov, obchodných systémov a iných systémov rôzneho druhu. UML definuje notáciu a metamodel. Notácia je zbierka grafických objektov, ktoré sa používajú v modeloch; je to syntax modelovacieho jazyka.
UML poskytuje expresívne nástroje na vytváranie vizuálnych modelov, ktoré:
- sú jednotne chápané všetkými vývojármi zapojenými do projektu;
- sú komunikačným prostriedkom v rámci projektu.
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.
UML je open source a má prostriedky na rozšírenie základného jadra. V UML môžu byť triedy, objekty a komponenty zmysluplne opísané v rôznych tematických oblastiach, ktoré sa často navzájom veľmi líšia.
UML diagramy
Rational Rose poskytuje návrhárovi systému nasledujúce typy diagramov, ktorých postupné vytváranie vám umožňuje získať úplný obraz o celom navrhovanom systéme a jeho jednotlivých komponentoch:
- Diagram prípadov použitia (diagramy precedensov);
- Diagram rozmiestnenia (topologické diagramy);
- Stavový diagram (stavové diagramy);
- Interakčný diagram (interakčné diagramy); Diagram činností (diagramy činností);
- Sekvenčný diagram (diagramy sekvencií akcií);
- Diagram spolupráce (diagramy spolupráce);
- Diagram tried (diagramy tried);
- Diagram komponentov (diagramy komponentov);
- Diagramy správania (diagramy správania);
- Diagram aktivity (diagram aktivít);
- Implementačné diagramy (implementačné diagramy);
Každý z týchto diagramov poskytuje iný pohľad na model systému. Diagram prípadov použitia zároveň 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álnej konštrukcie systému a diagramy správania, ktoré sú tiež variáciami logického modelu, odrážajú dynamické aspekty jeho fungovania. Implementačné diagramy slúžia na znázornenie komponentov systému a odkazujú na jeho fyzický model.
Niektoré z vyššie uvedených diagramov slúžia na označenie dvoch alebo viacerých poddruhov. Ako nezávislé znázornenia sa používajú nasledujúce diagramy: prípady použitia, triedy, stavy, aktivity, postupnosť, spolupráca, komponenty a nasadenie.
Existujú tri typy vizuálnych podnetov 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, zobrazené v blízkosti vizuálov grafu.
Pri grafickom znázornení diagramov sa odporúča dodržiavať nasledujúce pravidlá:
- každý diagram musí byť úplnou reprezentáciou nejakého fragmentu modelovanej predmetnej oblasti;
- entity modelu prezentované v diagrame musia mať rovnakú koncepčnú úroveň;
- všetky informácie o subjektoch musia byť v diagrame výslovne uvedené;
- 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 by mali obsahovať len tie prvky, ktoré sú definované v notácii jazyka UML.
Entity v UML
UML definuje štyri typy entít: štrukturálne, behaviorálne, zoskupovacie a anotačné. Entity sú hlavnými objektovo orientovanými prvkami jazyka, pomocou ktorých sa vytvárajú modely.
Štrukturálne entity sú podstatné mená v modeloch UML. Spravidla predstavujú statické časti modelu, zodpovedajúce koncepčným alebo fyzickým prvkom systému. Príkladmi štrukturálnych entít sú „trieda“, „rozhranie“, „kooperácia“, „prípad použitia“, „komponent“, „uzol“, „aktér“.
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 - behaviorálny algoritmus, ktorý určuje postupnosť stavov, ktorými objekt alebo interakcia prechádza v reakcii na rôzne udalosti.
Zoskupovanie subjektov sú organizačnými časťami modelu UML. Sú to bloky, na ktoré je možné model rozložiť. Takáto primárna entita je len jedna – je to balík.
Balíky sú všeobecným mechanizmom na organizovanie položiek do skupín. Štrukturálne, behaviorálne a iné zoskupovacie entity môžu byť umiestnené v balíku. Na rozdiel od komponentov, ktoré skutočne existujú počas spustenia programu, balíky majú čisto koncepčný charakter, to znamená, že existujú iba počas vývoja.
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 – pozn. Poznámka sa používa na poskytnutie komentárov alebo obmedzení k diagramom, vyjadrené ako neformálny alebo formálny text.
Vzťahy v UML
UML definuje nasledujúce typy vzťahov: závislosť, asociácia, zovšeobecnenie a implementácia. Tieto vzťahy sú základnými väzbovými konštrukciami UML a rovnakým spôsobom, akým sa entity používajú na vytváranie modelov.
Závislosť- ide o sémantický vzťah medzi dvoma entitami, v ktorom zmena jednej z nich, nezávislej, môže ovplyvniť sémantiku druhej, závislej.
asociácie- štruktúrny vzťah, ktorý opisuje súhrn sémantických alebo logických vzťahov medzi predmetmi.
Zovšeobecnenie je vzťah, v ktorom môže byť objekt špecializovaného prvku (dieťa) nahradený generickým objektom prvku (predok). Zároveň, v súlade s princípmi objektovo orientovaného programovania, dieťa (dieťa) zdedí štruktúru a správanie svojho predka (rodiča).
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 ich implementačnými triedami alebo komponentmi;
- medzi precedensmi a spoluprácami, ktoré ich realizujú.
Všeobecné mechanizmy UML
UML používa takzvané všeobecné mechanizmy na presný opis systému:
- technické údaje;
- doplnky (ozdoby);
- divízie (spoločné divízie);
- rozšírenia (mechanizmy rozšíriteľnosti).
UML nie je len grafický jazyk. Za každým grafickým prvkom je jeho zápis špecifikácia A, ktoré obsahuje 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 mať model inú reprezentáciu tejto triedy, odrážajúc jej úplne odlišné aspekty, ale napriek tomu zodpovedajúcu špecifikácii. Grafický zápis UML sa teda používa na vizualizáciu systému a pomocou špecifikácií opíše jeho detaily.
Takmer každý prvok UML má jedinečnú grafiku, ktorá poskytuje vizuálnu reprezentáciu jeho najdôležitejších charakteristík. Zápis entity "trieda" 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é zobraziť ako grafiku alebo text. prílohy na štandardný obdĺžnik, ktorý predstavuje triedu.
Pri modelovaní objektovo orientovaných systémov existuje určitá divízie zastúpené subjekty.
Najprv je tu rozdelenie na triedy a objekty. Trieda je abstrakcia a objekt je konkrétnou implementáciou tejto abstrakcie. V tomto smere sa takmer všetky jazykové konštrukty vyznačujú dualitou „trieda/objekt“. Existujú teda 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.
Po druhé, je tu rozdelenie na rozhranie a jeho implementáciu. Rozhranie deklaruje povinnosti a implementácia predstavuje konkrétnu implementáciu týchto povinností a zabezpečuje presné dodržiavanie deklarovanej sémantiky. Ako také sú takmer všetky UML konštrukty charakterizované dualitou rozhrania/implementácie. Napríklad prípady použitia sú implementované prostredníctvom spolupráce, zatiaľ čo operácie sú implementované metódami.
UML je otvorený jazyk, čo znamená, že umožňuje riadeným rozšíreniam odrážať vlastnosti doménových modelov.
Mechanizmy rozšírenia UML zahŕňajú:
- stereotypy (stereotypy) - rozširujú slovnú zásobu UML, čo vám umožňuje vytvárať nové na základe existujúcich prvkov jazyka, zamerané na riešenie konkrétneho problému;
- označené hodnoty - rozširujú vlastnosti základných konštruktov UML, čo vám umožňuje zahrnúť ďalšie informácie do špecifikácie prvku;
- obmedzenia (constraints) – rozširujú sémantiku konštruktov UML, umožňujú vytvárať nové a rušiť existujúce pravidlá.
Tieto tri mechanizmy rozšírenia jazyka spolu umožňujú upravovať ho podľa potrieb projektu alebo zvláštností vývojovej technológie.
Diagram prípadu použitia
Tento typ grafu vám umožňuje vytvoriť zoznam operácií, ktoré systém vykonáva. Často sa tento typ diagramu nazýva funkčný diagram, pretože na základe súboru takýchto diagramov sa vytvorí zoznam systémových požiadaviek a určí sa súbor funkcií, ktoré systém vykonáva.
Obrázok - 1. Diagram prípadu použitia Diagramy prípadov použitia popisujú funkčnosť systému alebo čo by mal systém robiť. Vývoj diagramu má nasledujúce ciele:
- určiť všeobecné hranice a kontext modelovaného predmetu;
- 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.
Podstata diagramu prípadov použitia je nasledovná. Navrhovaný systém je reprezentovaný ako súbor entít alebo aktérov interagujúcich so systémom pomocou prípadov použitia. V tomto prípade je aktérom (hercom) 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 ovplyvňovania simulovaného systému spôsobom, ktorý si vývojár sám určí. Prípad použitia slúži na popis služieb, ktoré systém poskytuje aktérovi.
Účelom prípadu použitia je definovať úplný aspekt alebo časť 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.
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 entita používa. Služba, ktorá sa inicializuje na žiadosť aktéra, je kompletná nedeliteľná postupnosť akcií. To znamená, že po tom, čo systém dokončí spracovanie požiadavky, musí sa vrátiť do pôvodného stavu, aby bol pripravený na ďalšie požiadavky.
Prípady použitia možno použiť na špecifikáciu externých požiadaviek na navrhovaný systém a 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é aspekty 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.
Príkladmi prípadov použitia môžu byť nasledovné úkony: kontrola stavu bežného účtu zákazníka, zadanie objednávky na nákup tovaru, získanie dodatočných informácií o bonite zákazníka, zobrazenie grafického formulára na obrazovke monitora, iné akcie.
Diagram tried (diagram tried)
Centrálnym objektom objektovo orientovaného programovania je vývoj logického modelu systému vo forme diagramu tried. Diagram tried (class diagram) slúži na znázornenie 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 predmetnej oblasti, ako sú objekty a subsystémy, ako aj popisovať ich vnútornú štruktúru a typy vzťahov.
Obrázok - 2. Diagram tried Ikony diagramu vám umožňujú zobraziť komplexnú hierarchiu systémov, vzťahy medzi triedami (triedy) a rozhraniami (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 v oblakoch. Trieda je teda len šablóna, podľa ktorej sa v budúcnosti vytvorí konkrétny objekt.
Diagram tried je graf, ktorého vrcholy sú prvky typu "klasifikátor" spojené 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.
trieda v 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. Graficky je trieda znázornená ako obdĺžnik, ktorý je navyše možné 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)
Každý stavový diagram v UML popisuje všetky možné stavy jednej inštancie určitej triedy a možné sekvencie jej prechodov z jedného stavu do druhého, to znamená, že modeluje všetky zmeny stavu objektu ako jeho reakciu na vonkajšie vplyvy.
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.
Obrázok - 2. Stavový diagram Stavový diagram je graf špeciálneho druhu, 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 môžu byť vnorené, aby poskytli podrobnejšiu reprezentáciu jednotlivých prvkov modelu.
V metamodeli UML 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.
Trvanie systému v ktoromkoľvek z možných stavov výrazne presahuje čas strávený prechodom 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.
Správanie automatu je modelované ako sekvenčný pohyb po grafe od vrcholu k vrcholu, pričom sa berie do úvahy orientácia oblúkov, ktoré ich spájajú.
Pre predajný automat musia byť splnené nasledujúce povinné podmienky:
- stav, do ktorého sa objekt môže dostať, je určený iba jeho súčasným stavom a nezávisí od jeho histórie;
- v danom čase môže byť automat iba v jednom zo svojich stavov. Zároveň môže byť automat v samostatnom stave ľubovoľne dlho, ak nenastanú žiadne udalosti;
- čas strávený automatom v jednom alebo druhom stave, ako aj čas potrebný na dosiahnutie jedného alebo druhého stavu, nie sú žiadnym spôsobom š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 daného modelu a stavového diagramu;
- graf automatu nesmie 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, keď objekt môže súčasne prejsť do dvoch alebo viacerých po sebe nasledujúcich stavov (okrem prípadu paralelných podautomatov). V jazyku UML je odstraňovanie konfliktov možné na základe zavedenia podmienok stráženia.
štát 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 jazyku UML má množstvo špecifických čŕt.
V UML je stav abstraktná metatrieda používaná na modelovanie konkrétnej situácie, počas ktorej sú splnené určité podmienky. Stav môže byť špecifikovaný ako množina špecifických hodnôt atribútov triedy alebo objektu. Zmeny jednotlivých hodnôt atribútov budú odrážať zmenu stavu modelovanej triedy alebo objektu.
Diagram aktivity
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.
Tento typ diagramu 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.
Tento typ diagramu vám umožňuje navrhovať algoritmy pre správanie objektov akejkoľvek zložitosti a možno ho použiť aj na vytváranie blokových diagramov.
UML používa diagramy aktivít na modelovanie procesu vykonávania operácií. Ich grafický zápis je v mnohých ohľadoch podobný zápisu stavového diagramu, keďže tieto diagramy majú aj stavové a prechodové symboly. Každý stav v 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.
Diagramy aktivít teda možno považovať za špeciálny prípad stavových diagramov. Umožňujú vám implementovať do UML vlastnosti procedurálneho a synchrónneho riadenia z dôvodu dokončenia interných činností a akcií. 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 kontexte UML činnosť je súbor jednotlivých výpočtov vykonávaných automatom, vedúcich k nejakému výsledku alebo akcii (akcii). Diagram aktivít ukazuje logiku a postupnosť prechodov z jednej aktivity do druhej a pozornosť analytika je zameraná na výsledky. Výsledkom činnosti môže byť zmena stavu systému alebo návrat určitej hodnoty.
Akčný stav je špeciálny prípad stavu s nejakou vstupnou akciou a aspoň jedným výstupným prechodom stavu. 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 modelovanie jedného kroku pri vykonávaní algoritmu (postupu) alebo riadiaceho toku.
Sekvenčný diagram
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 byť veľmi dôležitý pri modelovaní synchrónnych procesov, ktoré opisujú interakcie objektov. Sekvenčné diagramy sa používajú na modelovanie interakcie objektov v čase v jazyku UML.
Sekvenčné diagramy zobrazujú len tie predmety ktoré sú priamo zapojené do interakcie. Kľúčovým bodom pre sekvenčné diagramy je dynamika interakcie objektov v čase.
V UML má sekvenčný diagram dva rozmery. Prvá zľava doprava ako zvislé čiary, z ktorých každá zobrazuje životnú čiaru jednotlivého objektu zúčastňujúceho sa interakcie. Objekt úplne vľavo v diagrame je objekt, ktorý je iniciátorom interakcie. Vpravo je zobrazený ďalší objekt, ktorý priamo interaguje s prvým. Všetky objekty v sekvenčnom diagrame teda tvoria určité poradie, určené poradím alebo stupňom aktivity objektov pri vzájomnej interakcii.
Graficky je každý objekt znázornený obdĺžnikom a nachádza sa v hornej časti svojej životnej čiary. Vo vnútri obdĺžnika je napísaný názov objektu a názov triedy oddelené dvojbodkou. V tomto prípade je celý záznam podčiarknutý, čo je znakom objektu.
Druhým rozmerom sekvenčného diagramu je vertikálna časová os zhora nadol. Najvyššia časť diagramu zodpovedá počiatočnému časovému okamihu. Objektové interakcie sa realizujú prostredníctvom správ, ktoré posiela jeden objekt druhému. Správy sa zobrazujú ako horizontálne šípky s názvom správy a ich poradie je určené časom, kedy sa vyskytli. To znamená, že správy vyššie v sekvenčnom diagrame sú iniciované pred správami nižšie. Mierka na časovej osi nie je uvedená, pretože sekvenčný diagram modeluje iba časové usporiadanie skorších a neskorších interakcií.
Diagram spolupráce
Hlavnou črtou diagramu spolupráce je schopnosť graficky znázorniť nielen postupnosť interakcie, ale aj všetky štrukturálne vzťahy medzi objektmi zapojenými do tejto interakcie.
Obrázok - 3. Schéma spolupráce Tento typ diagramu vám umožňuje opísať interakciu objektov abstrahovať od postupnosti odovzdávania správ. Tento typ diagramu zobrazuje v kompaktnej forme všetky prijaté a odoslané správy konkrétneho objektu a typy týchto správ.
V prvom rade sú na diagrame spolupráce objekty zúčastňujúce sa interakcie znázornené vo forme obdĺžnikov, 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 je možné zobraziť dynamické prepojenia - 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 sériové číslo vo všeobecnom poradí inicializácie správy.
Na rozdiel od sekvenčného diagramu, diagram spolupráce zobrazuje iba vzťahy medzi objektmi, ktoré hrajú v interakcii špecifické úlohy. Tento graf nezobrazuje čas ako samostatnú dimenziu. Preto môže byť sekvencia interakcií a paralelných tokov definovaná pomocou sekvenčných čísel. Preto, ak je potrebné explicitne špecifikovať vzťahy medzi objektmi v reálnom čase, je lepšie to urobiť v sekvenčnom diagrame.
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 sa systému z hľadiska interakcie účastníkov tejto spolupráce.
Spoluprácu možno reprezentovať na dvoch úrovniach:
- úroveň špecifikácie - zobrazuje úlohy klasifikátorov a úlohu asociácií v uvažovanej interakcii;
- úroveň inštancie – označuje inštancie a vzťahy, ktoré tvoria jednotlivé roly v spolupráci.
Diagram spolupráce na úrovni špecifikácie zobrazuje úlohy, ktoré zohrávajú prvky zapojené do interakcie. Prvkami spolupráce na tejto úrovni sú triedy a asociácie, ktoré označujú samostatné úlohy klasifikátorov a asociácií medzi účastníkmi spolupráce.
Diagram spolupráce na úrovni inštancií predstavuje kolekcia objektov (inštancie triedy) a vzťahov (inštancie asociácie). Odkazy sú zároveň doplnené o šípky správ. Na tejto úrovni sa zobrazujú 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 kooperačnom diagrame 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.
Z toho vyplýva dôležitý dôsledok. Rovnaká množina objektov sa môže zúčastniť rôznych spoluprác. V závislosti od uvažovanej spolupráce sa môžu meniť vlastnosti jednotlivých objektov, ako 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.
Diagram komponentov
Tento typ diagramu sa používa na prideľovanie tried a objektov komponentom vo fyzickom návrhu systému. Tento typ diagramu sa často označuje ako modulové diagramy.
Obrázok - 4. Schéma komponentov Kompletný návrh softvérového systému je súbor modelov logickej a fyzickej úrovne, ktoré musia byť navzájom koordinované. V jazyku UML sa na fyzickú reprezentáciu modelov systémov používajú implementačné diagramy (implementačné diagramy), ktoré zahŕňajú diagram komponentov A diagram nasadenia.
Diagram komponentov, na rozdiel od predtým diskutovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Umožňuje vám určiť 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 závislosti medzi nimi.
Diagram komponentov je vytvorený 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ätovného použitia jednotlivých fragmentov programového kódu;
- reprezentácie koncepčných a fyzických schém databáz.
Na vývoji diagramov komponentov sa podieľajú systémoví analytici, ako aj architekti a programátori. Komponentový diagram poskytuje konzistentný prechod od logickej reprezentácie ku konkrétnej implementácii projektu vo forme programového kódu. Niektoré komponenty môžu existovať iba v štádiu zostavovania kódu programu, 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.
UML používa špeciálny výraz na označenie fyzických entít – komponent. Komponent implementuje určitú množinu rozhraní a slúži ako všeobecné označenie prvkov fyzickej reprezentácie modelu. Pre 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 názov komponentu a v prípade potreby nejaké ďalšie informácie. Obrázok tohto symbolu sa môže mierne líšiť v závislosti od povahy informácií spojených s komponentom.
Schéma nasadenia
Tento typ diagramu je určený na analýzu hardvéru systému, teda hardvéru, nie softvéru. V priamom preklade z angličtiny Deployment znamená „rozmiestnenie“, ale výraz „topológia“ presnejšie odráža podstatu tohto typu diagramu.
Obrázok - 5. Schéma nasadenia Fyzická reprezentácia softvérového systému nemôže byť úplná, ak neexistujú žiadne 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é sieťové zdroje, zaistiť bezpečnosť a iné.
UML používa diagramy nasadenia na reprezentáciu celkovej konfigurácie a topológie distribuovaného softvérového systému.
Diagram nasadenia je určený na vizualizáciu programových prvkov a komponentov, ktoré existujú iba vo fáze spustenia. V tomto prípade sú prezentované iba komponenty inštancie programu, ktoré sú spustiteľnými súbormi alebo dynamickými knižnicami. Tie komponenty, ktoré sa nepoužívajú za behu, nie sú zobrazené v diagrame nasadenia. Komponenty so zdrojovými kódmi programu teda môžu byť prítomné iba v diagrame komponentov. Nie sú zobrazené na diagrame nasadenia.
Diagram nasadenia obsahuje grafické znázornenia procesorov, zariadení, procesov a ich vzťahov. Na rozdiel od diagramov logickej reprezentácie je diagram nasadenia rovnaký pre systém ako celok, pretože musí plne odrážať vlastnosti jeho implementácie. Vytvorenie diagramu nasadenia je zvyčajne posledným krokom v špecifikácii modelu softvérového systému.
Pri navrhovaní diagramu nasadenia sú ciele:
- určiť rozloženie komponentov systému v jeho fyzických uzloch;
- ukázať fyzické spojenia medzi všetkými uzlami implementácie systému vo fáze jeho vykonávania;
- identifikovať úzke miesta systému a prekonfigurovať jeho topológiu na dosiahnutie požadovaného výkonu.
Diagramy nasadenia spoločne vyvíjajú systémoví analytici, sieťoví inžinieri a systémoví inžinieri.
Funkcie desktopového rozhrania Rational Rose
Nástroj Rational Rose CASE implementuje všeobecne uznávané štandardy pre operačné rozhranie programu, podobne ako známe vizuálne programovacie prostredia. Po nainštalovaní Rational Rose na počítač užívateľa, ktorá nespôsobuje takmer žiadne ťažkosti ani začiatočníkom, vedie spustenie tohto programu v prostredí MS Windows 95/98 k vzhľadu pracovného rozhrania na obrazovke (obr. 6).
Obrázok - 6. Celkový pohľad na operačné rozhranie programu Rational Rose
Pracovné rozhranie Rational Rose pozostáva z rôznych prvkov, z ktorých hlavné sú:
- Hlavné menu programu
- Okno grafu
- 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).
Samostatné položky menu, ktorých účel je jasný už z ich názvov, kombinujú podobné operácie súvisiace s celým projektom ako celkom. Niektoré položky ponuky obsahujú známe funkcie (otvorenie projektu, tlač diagramov, kopírovanie do schránky a vkladanie rôznych prvkov diagramu zo schránky). Iné sú také špecifické, že si 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 tým príkazom ponuky, ktoré vývojári použí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 (Nástroje -> Možnosti) a otvorte kartu Panely nástrojov (Panely nástrojov). Týmto spôsobom môžete zobraziť alebo skryť rôzne tlačidlá nástrojov, ako aj zmeniť ich veľkosť.
okno prehliadača
Predvolené okno prehliadača sa nachádza na ľavej strane pracovného rozhrania pod štandardným panelom nástrojov (obr. 9).
Prehliadač organizuje zobrazenia modelu v hierarchickej štruktúre, ktorá uľahčuje navigáciu a nájdenie akéhokoľvek prvku modelu v projekte. V tomto prípade sa akýkoľvek prvok, ktorý vývojár pridá do modelu, okamžite zobrazí v okne prehliadača. V súlade s tým výberom prvku v okne prehliadača ho môžeme vizualizovať v okne diagramu alebo zmeniť jeho špecifikáciu. Prehliadač vám tiež umožňuje organizovať prvky modelu do balíkov a presúvať prvky 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ť (Zobraziť). Veľkosť prehliadača môžete zmeniť aj potiahnutím okraja jeho vonkajšieho rámu myšou.
Obrázok - 9. Vzhľad prehliadača
Špeciálny panel nástrojov
Špeciálny panel nástrojov sa nachádza medzi oknom prehliadača a oknom diagramu v strednej časti pracovného rozhrania. Štandardne sa ponúka panel nástrojov na zostavenie modelového diagramu tried (obr. 10).
Obrázok - 10. Vzhľad špeciálneho panela nástrojov pre diagram tried
Umiestnenie vlastného panela s nástrojmi môžete zmeniť presunutím rámu panela s nástrojmi 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 umiestnení kurzora myši na príslušné tlačidlo.
Okno grafu
Okno diagramu je hlavnou pracovnou oblasťou jeho rozhrania, v ktorej sú vizualizované rôzne reprezentácie modelu projektu. Štandardne sa okno s grafom nachádza na pravej strane pracovného rozhrania, no 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 maximalizované 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 je diagram nasadenia aktívny, aj keď existujú aj iné diagramy. Prepínanie medzi grafmi je možné vykonať výberom požadovaného zobrazenia na štandardnom paneli nástrojov alebo cez položku ponuky Okno (Okno). Keď je aktivované individuálne zobrazenie grafu, zmení sa vzhľad špeciálneho panela s nástrojmi, ktorý je prispôsobený pre konkrétne zobrazenie grafu.
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 ju možno aktivovať cez položku ponuky Zobraziť -> Dokumentácia (Zobraziť-> Dokumentácia), po ktorej sa zobrazí pod prehliadačom (obr. 12).
Okno dokumentácie, ako už názov napovedá, je určené na dokumentáciu prvkov zobrazenia modelu. Dokáže zaznamenať 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.
Okno dokumentácie aktivuje informácie, ktoré sa týkajú jedné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 dokumentácia k nemu, ktorá je prázdna (Žiadna dokumentácia). Následne vývojár samostatne zadá potrebné vysvetľujúce informácie, ktoré sa zapamätajú a môžu sa počas práce na projekte meniť.
Rovnako ako v iných oknách 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 protokolu (Log) 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 hlásenie chýb, ktoré sa vyskytnú počas generovania kódu.
Okno protokolu je vždy prítomné na pracovnom rozhraní v oblasti okna diagramu (obr. 13). Môže však byť skrytý v iných oknách grafu alebo môže byť minimalizovaný. Okno protokolu môžete aktivovať cez ponuku Okno-> Protokol (Okno-> Protokol). V tomto prípade sa zobrazuje nad ostatnými oknami v pravej časti pracovného rozhrania. Toto okno nemôžete úplne odstrániť, môžete ho iba minimalizovať.
Obrázok - 13. Vzhľad okna denníka
Záver
Časom sa jazyk UML stane tým „esperantom“, v ktorom môžu komunikovať matematici, systémoví analytici, fyzici, programátori, manažéri, ekonómovia a špecialisti iných profesií, prezentujúc svoje odborné znalosti v jednotnej forme. V podstate každý zo špecialistov pracuje s modelovými reprezentáciami vo svojej oblasti vedomostí. A práve tento aspekt modelu je možné špecifikovať pomocou jazyka UML.
V tomto smere význam jazyka UML výrazne narastá, keďže čoraz viac nadobúda vlastnosti jazyka reprezentujúceho znalosti. Prítomnosť vizuálnych 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 jazyka UML nám umožňujú dospieť k záveru, že má najvážnejšie vyhliadky v blízkej budúcnosti.
Tento článok hovorí o novej ére vývoja softvéru, jej vplyve na nové požiadavky kladené na UML a najlepších metódach na ich splnenie.
7. "Dátové modelovanie v Rational Rose" Sergey Trofimov Opisuje, ako modelovať fyzickú reprezentáciu údajov pomocou Rational Rose
8. Jazyk UML. Všeobecné pochopenie jazyka UML: štruktúry, grafické prvky a diagramy jazyka.
9. Praktické UML. Tento dokument je prekladom dokumentu "Praktické UML. Praktický úvod pre vývojárov". Praktický úvod pre vývojárov
10. "Štandardný objektovo orientovaný modelovací jazyk UML" Vendrov Alexander Michajlovič. História tvorby UML
11. UML – Unified Modeling Language. 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
12. Jazyk UML. Užívateľská príručka. Autori: Grady Booch, James Rumbaugh, Ivar Jacobson
13. "UML diagramy v Rational Rose" Sergey Trofimov
14. "Analýza a návrh. Vizuálne modelovanie (UML) Rational Rose" Konstantin Domolego
15. Knižnica Gennadija Vernikova. Kompletný popis štandardov dizajnu a modelovania.
16. „Príklad popisu predmetnej oblasti pomocou UML pri vývoji softvérových systémov“ E.B. Zolotukhina, R.V. Alfimov. Článok demonštruje na konkrétnom príklade možný prístup k doménovému modelovaniu na základe použitia Unified Modeling Language (UML).
Diagram komponentov, na rozdiel od predtým diskutovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Komponentový diagram, Komponentný diagram - statický štrukturálny diagram, zobrazuje rozdelenie softvérového systému na štrukturálne komponenty a vzťahy (závislosti) medzi komponentmi.
Toto ilustruje vzťah klient-zdroj medzi týmito dvoma komponentmi. Po prečítaní častí ("Príklad", "Použitie") si môžete sami vyskúšať kreslenie diagramov komponentov. V objektovo orientovanej komunite sa diskutuje o tom, aký je rozdiel medzi fazuľou a bežnou triedou. UML 1 mal samostatný symbol pre komponent (obrázok 14.1). UML 2 túto ikonu nemá, ale môžete označiť obdĺžnik triedy podobnou ikonou.
Okrem tejto ikony komponenty nepriniesli so sebou žiadne nové označenia. Komponenty medzi sebou komunikujú pomocou poskytnutých alebo požadovaných rozhraní s guľôčkovým zápisom, ktorý sa zvyčajne používa iba v diagramoch tried.
V tomto príklade môže komponent Till interagovať s komponentom Sales Server pomocou rozhrania správy predaja. Otázka podstaty komponentu je predmetom nekonečných diskusií. Komponenty nie sú technológiou. Komponenty sú skôr štýlom vzťahu zákazníkov k softvéru. Chcú, aby nové komponenty fungovali rovnako ako tie staré, a aby ich aktualizovali podľa svojich plánov, a nie podľa pokynov výrobcov.
Dôležité je, že komponenty predstavujú položky, ktoré je možné samostatne zakúpiť a upgradovať. V dôsledku toho je rozdelenie systému na komponenty skôr marketingovým rozhodnutím ako technickým.
Počas procesu návrhu vytvára architekt alebo skúsený programátor projektovú dokumentáciu vrátane textových popisov, schém a modelov budúceho programu. UML je grafický jazyk na vizualizáciu, popis parametrov, návrh a dokumentáciu rôznych systémov (najmä programov).
Diagram tried slúži na znázornenie statickej štruktúry modelu systému v terminológii tried objektovo orientovaného programovania. Z tohto hľadiska je diagram tried ďalším vývojom koncepčného modelu navrhovaného systému. Na modelovanie interakcie objektov v jazyku UML sa používajú vhodné interakčné diagramy.
V diagrame spolupráce sú objekty zúčastňujúce sa interakcie znázornené vo forme obdĺžnikov, ktoré obsahujú názov objektu, jeho triedu a prípadne hodnoty atribútov. Na rozdiel od sekvenčného diagramu, diagram spolupráce zobrazuje iba vzťahy medzi objektmi, ktoré zohrávajú určité úlohy v interakcii. V tomto prípade sú prezentované iba komponenty inštancie programu, ktoré sú spustiteľnými súbormi alebo dynamickými knižnicami.
Tento diagram v podstate dokončuje proces OOAP pre konkrétny softvérový systém a jeho vývoj je zvyčajne posledným krokom v špecifikácii modelu. A k tomu prispieva viacero špeciálnych techník (Scrum of scrum, komponentové tímy, účasť architekta ako Product ownera). Toto je vývoj skutočného systému.
A v tomto nie je nič neobvyklé ani zlé. Komponenty softvérových systémov, ich odrody. Všetky predtým uvažované diagramy odrážali koncepčné a logické aspekty budovania modelu systému. Aby sme vysvetlili rozdiel medzi logickými a fyzickými reprezentáciami, je potrebné vo všeobecnosti zvážiť proces vývoja softvérového systému.
3.4.3. Aplikácia diagramov komponentov a rozloženia
Zároveň sa už v texte programu predpokladá organizácia programového kódu, určená syntaxou programovacieho jazyka a zahŕňajúca rozdelenie zdrojového kódu do samostatných modulov. A to je možné len vtedy, ak je programový kód systému implementovaný vo forme spustiteľných modulov, knižníc tried a procedúr, štandardných grafických rozhraní, databázových súborov.
Schéma komponentov a vlastnosti jeho konštrukcie
Na reprezentáciu fyzických entít v UML sa používa špeciálny výraz - komponent. Komponent (komponent) - fyzicky existujúca časť systému, ktorá zabezpečuje implementáciu tried a vzťahov, ako aj funkčné správanie simulovaného softvérového systému.
Okrem toho môže mať komponent textový stereotyp a označené hodnoty a niektoré komponenty môžu mať svoje vlastné grafické znázornenie. Komponentom môže byť spustiteľný kód jedného modulu, príkazové súbory alebo súbory obsahujúce interpretované skripty.
Na vývoji diagramov komponentov sa podieľajú systémoví analytici, ako aj architekti a programátori. Komponenty a stereotypy UML. Diagram nasadenia je určený na vizualizáciu prvkov a komponentov programu, ktoré existujú iba vo fáze jeho vykonávania (runtime). Komponenty môžete tiež rozdeliť na časti pomocou diagramov zložených štruktúr. Táto časť je venovaná dvom diagramom naraz: komponentom a umiestneniu, pre ktoré možno použiť všeobecný názov - implementačné diagramy.
Anotácia: Účel diagramu komponentov, jeho hlavné prvky. Vlastnosti fyzickej reprezentácie softvérových systémov. Komponenty softvérových systémov, ich odrody. Rozhrania, ich implementácia komponentmi. Použitie diagramu komponentov na návrh závislostí medzi komponentmi. Odporúčania na zostavenie schémy komponentov.
Schéma komponentov a vlastnosti jeho konštrukcie
Všetky predtým uvažované diagramy odrážali koncepčné a logické aspekty budovania modelu systému. Zvláštnosťou logickej reprezentácie je, že pracuje s pojmami, ktoré nemajú hmotné stelesnenie. Inými slovami, rôzne prvky logickej reprezentácie, ako sú triedy, asociácie, stavy, správy, neexistujú materiálne ani fyzicky. Odrážajú len pochopenie statickej štruktúry konkrétneho systému alebo dynamických aspektov jeho správania.
Na vytvorenie špecifického fyzického systému je potrebné implementovať všetky prvky logickej reprezentácie do konkrétnych hmotných entít. Na opis takýchto reálnych entít je určený ďalší aspekt reprezentácie modelu, a to fyzická reprezentácia modelu. V kontexte UML to znamená súbor súvisiacich fyzických entít vrátane softvéru a Hardvér ako aj personál, ktorý je organizovaný na vykonávanie špeciálnych úloh.
fyzický systém( fyzický systém ) - skutočný prototyp modelu systému.
Aby sme vysvetlili rozdiel medzi logickými a fyzickými reprezentáciami, je potrebné vo všeobecnosti zvážiť proces vývoja softvérového systému. Jeho počiatočnou logickou reprezentáciou môžu byť blokové schémy algoritmov a procedúr, popisy rozhraní a koncepčné schémy bázúdajov. Na implementáciu tohto systému je však potrebné vyvinúť zdrojový kód programu v programovacom jazyku. Zároveň sa už v texte programu predpokladá organizácia programového kódu, určená syntaxou programovacieho jazyka a zahŕňajúca rozdelenie zdrojového kódu do samostatných modulov.
Zdrojové texty programu však ešte nie sú finálnou realizáciou projektu, aj keď slúžia ako fragment jeho fyzickej reprezentácie. Softvérový systém možno považovať za implementovaný, keď je schopný vykonávať funkcie na zamýšľaný účel. A to je možné len vtedy, ak je programový kód systému implementovaný vo forme spustiteľných modulov, knižníc tried a procedúr, štandardných grafických rozhraní, databázových súborov. Práve tieto komponenty sú základnými prvkami fyzickej reprezentácie systému v zápise jazyka UML.
Kompletný návrh softvérového systému je súbor modelov logických a fyzických reprezentácií, ktoré musia byť navzájom konzistentné. V UML sa na fyzickú reprezentáciu modelov systému používajú takzvané implementačné diagramy, ktoré zahŕňajú dva samostatné kanonické diagramy: diagram komponentov a diagram nasadenia.
Diagram komponentov, na rozdiel od predtým diskutovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Diagram komponentov vám umožňuje určiť architektúru vyvíjaného systému vytvorením závislostí medzi softvérovými komponentmi, ktorými môžu byť zdrojový, binárny a spustiteľný kód. V mnohých vývojových prostrediach modul alebo komponent zodpovedá súboru. Prerušované šípky spájajúce moduly zobrazujú vzťahy závislostí podobné tým, ktoré sa vyskytujú pri kompilácii zdrojového kódu programu. Hlavnými grafickými prvkami diagramu komponentov sú komponenty, rozhrania a závislosti medzi nimi.
Na vývoji diagramov komponentov sa podieľajú systémoví analytici, ako aj architekti a programátori. Komponentový diagram poskytuje konzistentný prechod od logickej reprezentácie ku konkrétnej implementácii projektu vo forme programového kódu. Niektoré komponenty môžu existovať iba vo fáze kompilácie programového kódu, iné - vo fáze jeho vykonávania. Diagram komponentov zobrazuje všeobecné závislosti medzi komponentmi, pričom tieto komponenty považujeme za vzťahy medzi nimi.
Komponenty
Na reprezentáciu fyzických entít v UML sa používa špeciálny výraz - komponent.
Komponent(komponent) - fyzicky existujúca časť systému, ktorá zabezpečuje implementáciu tried a vzťahov, ako aj funkčné správanie simulovaného softvérového systému.
Komponent je navrhnutý tak, aby reprezentoval fyzickú organizáciu prvkov modelu, ktoré sú s ním spojené. Komponent môže mať navyše textový stereotyp a označené hodnoty a niektoré komponenty majú svoje vlastné grafické znázornenie. Komponentom môže byť spustiteľný kód samostatného modulu, dávkové súbory alebo súbory obsahujúce interpretované skripty.
Komponent slúži ako všeobecné označenie prvkov fyzickej reprezentácie modelu a môže implementovať určitú množinu rozhraní. Pre grafické znázornenie komponentu použite zvláštny charakter- obdĺžnik s dvomi menšími obdĺžnikmi vloženými vľavo (obr. 12.1). Názov komponentu a prípadne ďalšie informácie sú napísané vo vnútri priloženého obdĺžnika. Tento symbol je základným symbolom pre komponent v UML.
Ryža. 12.1.
Grafické znázornenie komponentu má svoj pôvod v označení programového modulu, ktorý sa istý čas používal na zobrazovanie funkcií. zapuzdrenie údajov a postupy.
modul(modul) - časť softvérového systému, ktorá si vyžaduje pamäť na svoje uloženie a procesor na vykonávanie.
V tomto prípade bol horný malý obdĺžnik koncepčne spojený s údajmi, ktoré tento komponent implementuje (niekedy je nakreslený vo forme oválu). Spodný malý rámček bol spojený s operáciami alebo metódami implementovanými . V jednoduchých prípadoch boli názvy údajov a metód napísané explicitne v malých obdĺžnikoch, ale v UML nie sú špecifikované.
Názov komponentu sa riadi všeobecnými pravidlami pre pomenovanie prvkov modelu v jazyku UML a môže pozostávať z ľubovoľného počtu písmen, číslic a interpunkčných znamienok. Jednotlivý komponent môže byť reprezentovaný na úrovni typu alebo inštancie. A hoci je jeho grafické znázornenie v oboch prípadoch rovnaké, pravidlá písania názvu komponentu sú trochu iné.
Ak je komponent reprezentovaný na úrovni typu, potom sa iba názov typu s veľkým začiatočným písmenom zapíše v tvare:<Имя типа>. Ak je komponent reprezentovaný na úrovni inštancie, potom je jeho názov napísaný v tvare:<имя компонента
‘:" Имя типа>. Celý riadok názvu je podčiarknutý. Takže v prvom prípade (obr. 12.1, a) pre komponent na úrovni typu je uvedený názov typu a v druhom prípade (obr. 12.1, b) pre komponent na úrovni inštancie jeho vlastný názov komponentu a typ názov.
Pravidlá pre pomenovanie objektov UML vyžadujú podčiarknutie názvov jednotlivých inštancií, ale pri komponentoch sa podčiarknutie ich názvu často vynecháva. V tomto prípade zadanie názvu komponentu s malými písmenami charakterizuje komponent na úrovni inštancie.
Je obvyklé používať názvy spustiteľných súborov, dynamických knižníc, webových stránok, textových súborov alebo súborov pomocníka, databázových súborov alebo súborov so zdrojovými textami programu, skriptové súbory a iné ako vlastné názvy komponentov.
V niektorých prípadoch môžu byť k jednoduchému názvu komponentu pridané informácie o názve pripájajúceho balíka ao konkrétnej verzii implementácie tohto komponentu. Všimnite si, že v tomto prípade je číslo verzie napísané ako označená hodnota v zložených zátvorkách. V iných prípadoch môže byť symbol komponentu rozdelený do sekcií, aby sa explicitne označovali názvy tried alebo rozhraní, ktoré implementuje. Toto označenie komponentu je tzv predĺžený.
Keďže komponent ako prvok modelu môže mať rôznu fyzickú implementáciu, niekedy je zobrazený vo forme špeciálneho grafického symbolu ilustrujúceho špecifické vlastnosti implementácie. Presne povedané, tieto dodatočné notácie nie sú špecifikované v notácii UML. Splnením všeobecných mechanizmov rozšírenia jazyka UML však uľahčujú pochopenie diagramu komponentov, čím výrazne zvyšujú viditeľnosť grafickej reprezentácie.
Pre vizuálnejšiu reprezentáciu komponentov boli navrhnuté nasledujúce grafické stereotypy, ktoré sa stali všeobecne akceptovanými:
Osobný účet poistenca
Automatický identifikačný systém Spoločné používanie AIS s elektronickým mapovým systémom
Wargame: Red Dragon sa nespúšťa?
Smutný escobar „Tvár súdneho systému Ukrajiny“
ROME Total War - ako odomknúť všetky frakcie?