UML diagram. Typy UML diagramov. Všeobecná charakteristika jazyka UML Príklad diagramov v jazyku uml

UML (Unified Modeling Language - jednotný modelovací jazyk) - grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru. UML je všeobecný jazyk, je to otvorený štandard, ktorý používa grafickú notáciu na vytvorenie abstraktného modelu systému, nazývaného model UML. UML bol vytvorený na definovanie, vizualizáciu, návrh a dokumentáciu prevažne softvérových systémov. UML nie je programovací jazyk, ale generovanie kódu je možné v nástrojoch na vykonávanie modelov UML ako interpretovaného kódu. Wikipedia

Komerčné produkty

Microsoft Visio

Typ: komerčný softvér

Populárny softvérový produkt od spoločnosti Microsoft, ktorý vám umožňuje kresliť bohaté diagramy vrátane UML:

Od verzie 2010 bolo možné publikovať diagramy na webe (SharePoint + Visio Services):

Prehliadač Visio- bezplatný program, ktorý vám umožňuje zobraziť predtým vytvorené diagramy Visio. Môžete si ho stiahnuť na %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Expres%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modeling,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sekvencia%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Použití%20prípad%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Vizualizácia%20a%20Modelovanie%20Funkcia%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A
  • %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
    • %0A
  • %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20vrstva%20diagramy%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20vrstva%20diagramy
    • %0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Vizualizácia%20a%20Modelovanie%20Funkcia%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Schopnosti:

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

Snímky obrazovky:

programy s otvoreným zdrojom

StarUML

Schopnosti:

  • podpora UML 2.0
  • MDA (Model Driven Architecture)
  • Plug-in Architecture (môžete písať v jazykoch kompatibilných s COM: C++, Delphi, C#, VB, ...)

StarUML je napísaný hlavne v Delphi, ale komponenty je možné pridávať aj v iných jazykoch, ako napríklad C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Nižšie sú uvedené niektoré snímky obrazovky.

Diagram triedy:

Schéma prípadu použitia:

ArgoUML

Podporované grafy:

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

Schopnosti:

  • Podpora deviatich diagramov UML 1.4
  • Nezávislé od platformy (Java 5+)
  • Štandardný metamodel UML 1.4
  • podpora XMI
  • Export do GIF, PNG, PS, EPS, PGML a SVG
  • Jazyky: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
  • podpora OCL
  • Vpred, spätné inžinierstvo

Snímka obrazovky:

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnutý tak, aby podporoval proces modelovania PS založený na prístupe OO, organizoval vzťah medzi konceptuálnymi a programovými konceptmi a reflektoval problémy škálovania zložitých systémov. Modely UML sa používajú vo všetkých fázach životného cyklu softvéru, od obchodnej analýzy až po údržbu systému. Rôzne organizácie môžu používať UML vlastným spôsobom, v závislosti od ich problémových oblastí a použitých technológií.

Stručná história UML

Do polovice 90. rokov 20. storočia bolo navrhnutých niekoľko desiatok metód OO modelovania rôznymi autormi, z ktorých každý používal svoj vlastný grafický zápis. Každá z týchto metód mala zároveň svoje silné stránky, ale neumožňovala postaviť dostatočne ucelený model PS, ukázať ho „zo všetkých strán“, teda všetky potrebné projekcie (pozri článok 1). Okrem toho chýbajúci štandard modelovania OO sťažoval vývojárom výber najvhodnejšej metódy, čo bránilo širokému používaniu prístupu OO k vývoju softvéru.

Na žiadosť Object Management Group (OMG) - organizácie zodpovednej za prijímanie štandardov v oblasti objektových technológií a databáz vyriešili naliehavý problém zjednotenia a štandardizácie autori troch najpopulárnejších metód OO - G. Booch , D. Rambo a A. Jacobson, ktorí spojili svoje úsilie a vytvorili UML verziu 1.1, schválenú OMG v roku 1997 ako štandard.

UML je jazyk

Každý jazyk pozostáva zo slovníka a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takže sú usporiadané najmä programovacie jazyky, ako je UML. Jeho charakteristickým znakom je, že slovnú zásobu jazyka tvoria grafické prvky. Každý grafický symbol má špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jednoznačne pochopený iným, ako aj nástrojom, ktorý interpretuje UML. Z toho predovšetkým vyplýva, že model PS prezentovaný v UML je možné automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda pomocou dobrého nástroja na vizuálne modelovanie, ktorý podporuje UML. zostavením modelu dostaneme aj prázdny kód programu zodpovedajúci tomuto modelu.

Treba zdôrazniť, že UML je jazyk, nie metóda. Vysvetľuje, z akých prvkov vytvárať modely a ako ich čítať, ale nehovorí nič o tom, ktoré modely a v akých prípadoch by sa mali rozvíjať. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja PS. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v ďalších článkoch.

UML slovník

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

Esencie sú abstrakcie, ktoré sú hlavnými prvkami modelov. Existujú štyri typy entít – štrukturálne (trieda, rozhranie, komponent, prípad použitia, spolupráca, uzol), behaviorálne (interakcia, stav), zoskupovanie (balíky) a anotačné (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne diskutované pri štúdiu diagramov.

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

  • Závislosť ukazuje taký vzťah medzi dvoma entitami, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou zo závislej entity na nezávislú entitu.
  • asociácie je štrukturálny vzťah ukazujúci, že objekty jednej entity súvisia s objektmi inej entity. Graficky je asociácia znázornená ako čiara spájajúca súvisiace entity. Asociácie sa používajú na navigáciu medzi objektmi. Napríklad spojenie medzi triedami "Objednávka" a "Produkt" môže byť použité na nájdenie všetkých produktov špecifikovaných v konkrétnej objednávke - na jednej strane, alebo na nájdenie všetkých objednávok, ktoré obsahujú tento produkt - na druhej strane. Je jasné, že príslušné programy musia implementovať mechanizmus, ktorý takúto navigáciu zabezpečí. Ak je potrebná navigácia iba jedným smerom, je to označené šípkou na konci priradenia. Osobitným prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený kosoštvorcom na konci blízko entity-celku.
  • Zovšeobecnenie je vzťah medzi nadradenou entitou a podriadenou entitou. Tento vzťah v podstate odráža vlastnosť dedičnosti pre triedy a objekty. Zovšeobecnenie je znázornené ako čiara končiaca trojuholníkom smerujúcim k nadradenej entite. Dieťa zdedí štruktúru (atribúty) a správanie (metódy) rodiča, no zároveň môže mať nové prvky štruktúry a nové metódy. UML umožňuje viacnásobné dedičstvo, keď entita súvisí s viac ako jednou nadradenou entitou.
  • Implementácia- vzťah medzi entitou, ktorá definuje špecifikáciu správania (rozhranie) s entitou, ktorá definuje implementáciu tohto správania (trieda, komponent). Tento vzťah sa bežne používa pri modelovaní komponentov a bude podrobnejšie popísaný v nasledujúcich článkoch.

Diagramy. UML poskytuje nasledujúce diagramy:

  • Diagramy popisujúce správanie systému:
    • Stavové diagramy (State diagrams),
    • diagramy aktivít,
    • Diagramy objektov,
    • sekvenčné diagramy,
    • Diagramy spolupráce;
  • Diagramy popisujúce fyzickú implementáciu systému:
    • Schémy komponentov;
    • Schémy nasadenia.

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

Už sme povedali, že na to, aby človek dobre porozumel modelu, je potrebné ho hierarchicky usporiadať, pričom na každej úrovni hierarchie zostane malý počet entít. UML obsahuje prostriedky na organizáciu hierarchickej reprezentácie modelu – balíkov. Každý model pozostáva zo sady balíkov, ktoré môžu obsahovať triedy, prípady použitia a iné entity a diagramy. Balík môže obsahovať ďalšie balíky, čo vám umožňuje vytvárať hierarchie. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balík sa zobrazí ako obdĺžnik s uškom.

Čo poskytuje UML.

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

A posledný…

Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom modelovaní PS bez nástrojov na vizuálne modelovanie. Takéto nástroje vám umožňujú rýchlo prezentovať diagramy na obrazovke, dokumentovať ich, vytvárať prázdne miesta programových kódov v rôznych OO programovacích jazykoch a vytvárať databázové schémy. Väčšina z nich zahŕňa možnosť reengineeringu programových kódov - obnovenie určitých projekcií modelu PS automatickou analýzou zdrojových kódov programov, čo je veľmi dôležité pre zabezpečenie zhody modelu a kódov a pri navrhovaní systémov, ktoré zdedia funkčnosť predchádzajúcich systémov. .

Anotácia: Predmetom tohto kurzu je UML - Unified Modeling Language. V predchádzajúcej prednáške sme si povedali, čo je UML, jeho história, účel, spôsoby používania jazyka, štruktúra jeho definície, terminológia a zápis. Bolo poznamenané, že model UML je súbor diagramov. V tejto prednáške sa budeme zaoberať týmito otázkami: prečo potrebujeme niekoľko typov diagramov; typy diagramov; OOP a sekvenčné diagramy

Predtým, ako prejdeme k diskusii o hlavnom materiáli tejto prednášky, povedzme si o tom, prečo vôbec vytvárať nejaké diagramy. Vývoj modelu akéhokoľvek systému (nielen softvérového) vždy predchádza jeho vytvoreniu alebo aktualizácii. Je to potrebné aspoň na to, aby sme si jasnejšie predstavili riešený problém. Premyslené modely sú veľmi dôležité ako pre interakciu v rámci vývojového tímu, tak aj pre vzájomné porozumenie so zákazníkom. Koniec koncov, umožňuje vám uistiť sa, že projekt je „architektonicky konzistentný“ pred implementáciou do kódu.

Modely zložitých systémov staviame, pretože ich nevieme úplne opísať, „pozrieť si ich na prvý pohľad“. Preto vyčleňujeme len tie vlastnosti systému, ktoré sú nevyhnutné pre konkrétnu úlohu a zostavujeme jeho model, ktorý tieto vlastnosti odráža. Metóda objektovo orientovanej analýzy umožňuje popísať skutočné komplexné systémy tým najvhodnejším spôsobom. Ale ako sa systémy stávajú zložitejšími, je potrebná dobrá simulačná technológia. Ako sme si povedali v predchádzajúcej prednáške, ako taká „štandardná“ technológia sa používa jednotný systém. modelovací jazyk(Unified Modeling Language, UML), čo je grafický jazyk na špecifikáciu, vizualizáciu, návrh a dokumentáciu systémov. Pomocou UML môžete vytvoriť podrobný model vytváraného systému, ktorý odráža nielen jeho koncepciu, ale aj špecifické implementačné vlastnosti. V rámci modelu UML sú všetky reprezentácie o systéme zafixované vo forme špeciálnych grafických konštrukcií nazývaných diagramy.

Poznámka. Nebudeme brať do úvahy všetky, ale iba niektoré typy grafov. V tejto prednáške sa napríklad nezaoberá diagram komponentov, čo je len stručný prehľad typov diagramov. Počet typov grafov pre konkrétny aplikačný model nie je nijako obmedzený. Pre jednoduché aplikácie nie je potrebné vytvárať diagramy všetkých typov bez výnimky. Niektoré z nich môžu jednoducho chýbať a táto skutočnosť sa nebude považovať za chybu. Je dôležité pochopiť, že dostupnosť diagramov určitého typu závisí od špecifík konkrétneho projektu. Informácie o iných (tu nediskutovaných) typoch diagramov nájdete v štandarde UML.

Prečo potrebujete viacero typov grafov

Najprv si definujme terminológiu. V predslove k tejto prednáške sme opakovane použili pojmy systém, model a diagram. Autor si je istý, že každý z nás intuitívne chápe význam týchto pojmov, ale aby to bolo úplne jasné, pozrime sa ešte raz do slovníka a prečítajte si nasledovné:

Systém- súbor vzájomne prepojených riadených subsystémov spojených spoločným cieľom fungovania.

Áno, nie veľmi informatívne. Čo je potom subsystém? Aby sme objasnili situáciu, obráťme sa na klasiku:

systém nazvať súbor podsystémov organizovaných na dosiahnutie konkrétneho cieľa a popísaných pomocou súboru modelov, prípadne z rôznych uhlov pohľadu.

No nedá sa nič robiť, treba hľadať definíciu podsystému. Aj to sa tam píše subsystému je súbor prvkov, z ktorých niektoré špecifikujú správanie iných prvkov. Ian Sommerville vysvetľuje tento koncept takto:

Subsystém je systém, ktorého fungovanie nezávisí od služieb iných subsystémov. Softvérový systém je štruktúrovaný ako súbor relatívne nezávislých subsystémov. Interakcie medzi subsystémami sú tiež definované.

Tiež nie veľmi jasné, ale lepšie. V „ľudskom“ jazyku je systém reprezentovaný ako súbor jednoduchších entít, ktoré sú relatívne sebestačné. Dá sa to prirovnať k tomu, ako v procese vývoja programu staviame grafické rozhranie zo štandardných „kociek“ – vizuálnych komponentov, alebo ako sa aj samotný text programu delí na moduly, ktoré obsahujú podprogramy, ktoré sa kombinujú podľa funkčného a možno ich opätovne použiť v nasledujúcich programoch.

Pochopte pojem systém. Počas procesu návrhu sa berie do úvahy systém z rôznych uhlov pohľadu pomocou modelov, ktorých rôzne zobrazenia sa objavujú vo forme diagramov. Čitateľ môže mať opäť otázky o význame pojmov modelov a diagramy. Myslíme si, že krásna, no nie veľmi jasná definícia modely ako sémanticky uzavretá systémová abstrakcia je nepravdepodobné, že by situáciu objasnilo, tak skúsme vysvetliť „vlastnými slovami“.

Model- ide o určitý (materiálny alebo nehmotný) objekt, ktorý zobrazuje len najvýznamnejšie charakteristiky systému pre túto úlohu. Modely sú rôzne - hmotné a nehmotné, umelé a prírodné, dekoratívne a matematické...

Uveďme niekoľko príkladov. Nám všetkým známe plastové autíčka, na ktoré sme sa v detstve s takou vášňou hrali, nie sú ničím iným materiál umelý dekoratívny skutočný model auta. Samozrejme, v takomto "aute" nie je motor, netankujeme mu benzín, prevodovka nefunguje (navyše vôbec neexistuje), ale ako model táto hračka plne plní svoje funkcie : dáva dieťaťu predstavu o aute, pretože zobrazuje jeho charakteristické črty prítomnosť štyroch kolies, karosérie, dverí, okien, schopnosť riadiť atď.

V lekárskom výskume testovanie na zvieratách často predchádza klinickému skúšaniu liekov na ľuďoch. V tomto prípade zviera pôsobí ako materiál prírodnýľudské modely.

Rovnica zobrazená vyššie je tiež model, ale toto je matematický model a opisuje pohyb hmotného bodu pri pôsobení gravitácie.

Zostáva len povedať, čo je diagram. Diagram je grafické znázornenie množiny prvkov. Zvyčajne sa zobrazuje ako graf s vrcholmi (entitami) a hranami (reláciami). Existuje veľa príkladov diagramov. Ide o blokovú schému, ktorú poznáme všetci zo školských čias, inštalačné schémy pre rôzne zariadenia, ktoré môžeme vidieť v používateľských príručkách, a strom súborov a adresárov na disku, ktorý môžeme vidieť spustením príkazu tree v Konzola Windows a oveľa, oveľa viac iného. V bežnom živote nás diagramy obklopujú zo všetkých strán, pretože obrázok je pre nás vnímateľný ľahšie ako text...

Ale späť k dizajnu softvéru (a nielen). V tomto odvetví od r pomocou diagramov si môžete vizualizovať systém z rôznych uhlov pohľadu. Jeden z diagramov môže napríklad popisovať interakciu používateľa so systémom, druhý - zmenu stavov systému počas jeho prevádzky, tretí - interakciu medzi prvkami systému atď. systém môže a mal by byť reprezentovaný ako súbor malých a takmer nezávislých modelov - diagramov, pričom žiaden z nich nestačí na popis systému a získanie úplného obrazu, keďže každý z nich sa zameriava na nejaký konkrétny aspekt fungovania systému a vyjadruje iné úroveň abstrakcie. Inými slovami, každý model zodpovedá nejakému špecifickému, konkrétnemu pohľadu na navrhovaný systém.

Napriek tomu, že v predchádzajúcom odseku sme sa veľmi voľne držali pojmu model, treba chápať, že v kontexte vyššie uvedených definícií žiadny jednotlivý diagram nie je vzorom. Diagramy sú len prostriedkom na vizualizáciu modelu a mali by sa rozlišovať. Iba súbor diagramov tvorí model systému a popisuje to najúplnejšie, ale nie jeden diagram vytrhnutý z kontextu.

Typy grafov

Definícia UML 1.5 dvanásť typov grafov rozdelené do troch skupín:

  • štyri typy diagramov predstavujú statickú štruktúru aplikácie;
  • päť predstavuje behaviorálne aspekty systému;
  • tri predstavujú fyzické aspekty fungovania systému (implementačné diagramy).

Aktuálna verzia UML 2.1 neurobila príliš veľa zmien. Diagramy sa mierne zmenili vo vzhľade (objavili sa rámy a iné vizuálne vylepšenia), mierne sa zlepšil zápis, niektoré diagramy dostali nové názvy.

Presný počet však kanonické diagramy je to pre nás absolútne nepodstatné, keďže nebudeme brať do úvahy všetky, ale len niektoré - z toho dôvodu, že počet typov diagramov pre konkrétny model konkrétnej aplikácie nie je striktne stanovený. Pre jednoduché aplikácie nie je potrebné zostavovať všetky diagramy bez výnimky. Napríklad pre lokálnu aplikáciu nie je potrebné zostavovať diagram nasadenia. Je dôležité pochopiť, že zoznam diagramov závisí od špecifík vyvíjaného projektu a určuje ho samotný vývojár. Ak by zvedavý čitateľ predsa len chcel vedieť o všetkých diagramoch UML, odkážeme ho na štandard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Pripomeňme, že účelom tohto kurzu nie je popísať absolútne všetky možnosti UML, ale iba predstaviť tento jazyk, poskytnúť prvotnú predstavu o tejto technológii.

Stručne sa teda pozrieme na také typy grafov, ako sú:

  • diagram prípadu použitia;
  • diagram tried;
  • objektový diagram;
  • sekvenčný diagram;
  • interakčný diagram;
  • stavový diagram;
  • diagram činnosti;
  • diagram nasadenia.

O niektorých z týchto diagramov si povieme podrobnejšie v ďalších prednáškach. Medzitým sa nezameriame na detaily, ale za cieľ si stanovíme naučiť čitateľa aspoň vizuálne rozlišovať medzi jednotlivými typmi diagramov, aby sme získali prvotnú predstavu o účele hlavných typov diagramov. . Takže, začnime.

Diagram prípadu použitia

Akékoľvek (vrátane softvéru) systémy sú navrhnuté s ohľadom na skutočnosť, že v priebehu svojej práce ich budú používať ľudia a/alebo budú interagovať s inými systémami. Entity, s ktorými systém interaguje pri svojej práci, sa nazývajú herci a každý aktér očakáva, že sa systém bude správať presne definovaným a predvídateľným spôsobom. Pokúsme sa podať presnejšiu definíciu ektora. Aby sme to dosiahli, používame úžasný vizuálny slovník pre UML Zicom Mentor:

Hector (herec)- ide o súbor logicky súvisiacich rolí vykonávaných pri interakcii s precedensmi alebo entitami (systém, subsystém alebo trieda). Aktérom môže byť osoba alebo iný systém, subsystém alebo trieda, ktorá predstavuje niečo mimo entity.

Graficky je vektor znázornený buď " mužíček“, podobné tým, ktoré sme kreslili v detstve, zobrazujúce členov našej rodiny, príp symbol triedy so zodpovedajúcim stereotypom, ako je znázornené na obrázku. Obe formy prezentácie majú rovnaký význam a možno ich použiť v diagramoch. „stereotypná“ forma sa častejšie používa na znázornenie systémových aktérov alebo v prípadoch, keď má aktér vlastnosti, ktoré je potrebné zobraziť (obr. 2.1).

Pozorný čitateľ si môže hneď položiť otázku: Prečo je hektor a nie je hercom?? Súhlasíme, slovo „ektor“ Rusovi trochu reže ucho. Dôvod, prečo to hovoríme, je jednoduchý – ektor je vytvorený zo slova akcie, čo v preklade znamená akcie. Doslovný preklad slova "ektor" - herec- príliš dlhé a nepohodlné na používanie. Preto to budeme tvrdiť aj naďalej.


Ryža. 2.1.

Ten istý pozorný čitateľ si mohol všimnúť, že v definícii ektora sa mihlo slovo „precedent“. Čo je to? Táto otázka nás bude zaujímať ešte viac, ak si spomenieme, o čom teraz hovoríme diagram prípadu použitia. takže,

Precedens (prípad použitia)- popis konkrétneho aspektu správania systému z pohľadu užívateľa (Butch).

Definícia je celkom zrozumiteľná a vyčerpávajúca, ale pomocou nej sa dá ďalej spresniť Zicom Mentor"om:

prípad použitia- opis súboru po sebe nasledujúcich udalostí (vrátane variantov) vykonávaných systémom, ktoré vedú k výsledku, ktorý aktér pozoroval. Prípad použitia predstavuje správanie entity opisom interakcie medzi aktérmi a systémom. Precedens neukazuje „ako“ sa dosiahne určitý výsledok, ale len „čo“ to je.

Precedensy sú označené veľmi jednoduchým spôsobom - vo forme elipsy, vo vnútri ktorej je uvedený jej názov. Prípady použitia a herci sú prepojení s líniami. Na jednom konci riadku sa často zobrazuje ryža. 2.3

  • vytvorenie všeobecných požiadaviek na správanie navrhovaného systému;
  • vypracovanie koncepčného modelu systému pre jeho následné spresnenie;
  • príprava dokumentácie pre interakciu so zákazníkmi a používateľmi systému.
    • Jazyk UML je všeobecný grafický modelovací jazyk na špecifikáciu, vizualizáciu, návrh a dokumentáciu všetkých artefaktov vytvorených počas vývoja softvérových systémov.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Diagramy zobrazujúce správanie systému:

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

    Vynikajú grafy:

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

    Schéma použitia

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

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

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

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

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

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

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

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

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

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

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

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

    diagram tried

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

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

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

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

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

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

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

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

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

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

    diagram automatu

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

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

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

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

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

    diagram činnosti

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

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

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

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

    sekvenčný diagram

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

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

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

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

    Komunikačný diagram

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

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

    Diagram komponentov

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

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

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

    Schéma umiestnenia

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

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

    Diagram objektu

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

    V objektovom diagrame sa používa jeden hlavný typ entít: objekty (inštancie tried), medzi ktorými sú naznačené špecifické vzťahy (najčastejšie asociačné inštancie). Objektové diagramy majú pomocný charakter – v skutočnosti ide o príklady (dalo by sa povedať, že výpisy pamäte), ktoré ukazujú, aké objekty existujú a vzťahy medzi nimi v určitom konkrétnom momente prevádzky systému.

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

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

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

    Časový diagram

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

    Schéma balíka

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

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

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

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

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

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

    Základné pojmy:

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

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

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

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

    Existujú tri typy binárnych odkazov:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Čítanie navyše

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

    Ukážte správanie jedného objektu počas jeho životnosti, od vytvorenia objektu až po jeho zničenie. Každý stavový diagram predstavuje nejaký automat.

    Akčný plán

    V časti Popis sa dozviete o základnej znakovej sade statechart potrebnej na to, aby ste mohli čítať diagramy.

    Po prečítaní ďalších častí ("Príklad", "Použitie") si môžete sami vyskúšať vytváranie stavových diagramov.

    Poznámky (popis)

    Tu je súbor hlavných postáv stavové diagramy je potrebné vedieť čítať diagram. Po prečítaní ostatných sekcií ("Príklad", "Aplikácia") budete môcť skladať stavové diagramy sám za seba!

    Termín Obrázok Popis
    Počiatočný pseudostav Počiatočný stav systému
    Prechod Prechod znamená prechod z jedného stavu do druhého.
    Štát Označuje činnosti vykonávané systémom (môže zahŕňať možné možnosti), ktoré vedú k výsledkom pozorovaným aktérmi.
    Štát
    stav činnosti    		 Ťažký krok v prípade použitia môže predstavovať iný prípad použitia.
    V podmienkach UML hovoríme, že prvý prípad použitia zahŕňa druhý.
    Koncový stav Umožňuje určiť hranice systémov alebo podsystémov.
    Interné aktivity Prípad, keď štáty môžu reagovať na udalosti bez vykonania prechodu, v tomto prípade sú udalosť, stráž a aktivita umiestnené vo vnútri stavového obdĺžnika.
    vstupná činnosť Vstupná aktivita sa vykoná vždy, keď vstúpite do štátu
    výstupná činnosť Výstupná aktivita – vykoná sa vždy, keď opustíte štát.
    superštát
    		Často sa stáva, že viaceré štáty majú spoločné prechody a vnútorné aktivity. V takýchto prípadoch ich môžete zmeniť na podstavy (podstavy) a preniesť celkové správanie do nadstavu (nadstavy).
    Paralelné štáty
    		Štáty môžu byť rozdelené do viacerých súbežných stavov, ktoré prebiehajú súčasne.

    Ako aplikovať techniku ​​kreativity

    Stavové diagramy UML sú dobré na popis správania jedného objektu v rámci viacerých prípadov použitia. Ale nie sú veľmi vhodné na opis správania charakterizovaného interakciou mnohých objektov. Preto má zmysel používať iné technológie v spojení so stavovými diagramami. Napríklad diagramy interakcie (kapitola 4) sú skvelé na opis správania viacerých objektov v jednom prípade použitia, zatiaľ čo diagramy aktivít UML sú dobré na zobrazenie hlavnej postupnosti akcií niekoľkých objektov v niekoľkých prípadoch použitia.

    Nie každý považuje stavové diagramy za prirodzené. Sledujte, ako s nimi odborníci pracujú. Je možné, že členovia vášho tímu si nemyslia, že štátne diagramy sú pre ich spôsob práce vhodné. Toto nie je najväčší problém; musíte pamätať na zdieľanie rôznych pracovných metód.

    Ak používate stavové diagramy, nesnažte sa ich kresliť pre každú triedu v systéme. Tento prístup sa často používa z dôvodu formálnej dôslednej úplnosti, ale takmer vždy je to strata úsilia. Stavové diagramy používajte iba pre triedy, ktoré vykazujú zaujímavé správanie, kde vám vykreslenie stavového diagramu pomáha pochopiť, ako sa veci dejú.

    Verí tomu veľa odborníkov editor používateľského rozhrania a ovládacie objekty majú užitočnú funkciu pri zobrazení pomocou stavového diagramu.

    Ako sa učiť

    Tu sme sa pokúsili poskytnúť najjednoduchší spôsob učenia UML stavové diagramy.

    Rovnako ako mnoho iných jazykov používa na opis množinu znakov. Význam týchto symbolov nájdete v tabuľke v časti „Poznámky (popis)“. Každé znamenie má svoje meno (výraz) a pravopis. Každý pojem je tiež vybavený krátkym vysvetlením, aby ste rýchlo pochopili jeho hlavnú podstatu.

    Ďalej odporúčame prejsť do sekcie „Príklady“. stavové diagramy vyskúšať si čítanie rôznych tabuliek. Potom by ste si mali preštudovať časť „Použitie“, pretože aj keď je počet typov diagramov v UML malý, z ich používania môžete získať maximálny úžitok, iba ak použijete vhodné diagramy na ich zamýšľaný účel.

    Príklad použitia

    Schémy štátnych strojov je dobre známa technika na opis správania systému. Stavové diagramy existujú v tej či onej forme od 60. rokov 20. storočia a v počiatkoch objektovo orientovaného programovania sa používali na znázornenie správania systému. V objektovo orientovaných prístupoch nakreslíte stavový diagram jednej triedy, aby ste ukázali správanie jedného objektu počas jeho životnosti.

    Kedykoľvek sa píše o konečných automatoch, ako príklady sa nevyhnutne uvádzajú systémy tempomatu alebo predajné automaty.
    Rozhodli sme sa použiť ovládač tajnej ústredne na gotickom hrade. V tomto hrade chceme ukryť naše poklady, aby sa ťažko hľadali. Aby sme získali prístup k zámku trezoru, musíme zo svietnika vytiahnuť strategickú sviečku, ale zámok sa objaví iba vtedy, ak sú dvere zatvorené. Po objavení sa zámku môžeme do neho vložiť kľúč a trezor otvoriť. Pre väčšiu bezpečnosť sme to urobili tak, že trezor je možné otvoriť až po vybratí sviečky. Ak zlodej nebude dbať na toto opatrenie, vypustíme odpornú príšeru, ktorá zlodeja prehltne.

    Na obr. 10.1 zobrazený stavový diagram Controller class, ktorý spravuje môj neobvyklý bezpečnostný systém. Stavový diagram začína stavom vytváraného objektu regulátora: stavy počkaj. Toto je znázornené na diagrame s počiatočný pseudostav, čo nie je stav, ale má šípku smerujúcu do počiatočného stavu.
    Diagram ukazuje, že ovládač môže byť v jednom z troch stavov: Wait (Waiting), Lock (Lock) a Open (Opened). Diagram ukazuje aj pravidlá, podľa ktorých ovládač prechádza z jedného stavu do druhého. Tieto pravidlá sú reprezentované ako prechody - čiary spájajúce stavy.

    Prechod znamená prechod z jedného stavu do druhého. Každý prechod má svoj vlastný štítok, ktorý pozostáva z troch častí:
    identifikátor spúšťača [ochrana]/aktivita (podpis spúšťača /aktivita). Všetky sú voliteľné. zvyčajne trigger-id je jediná udalosť, ktorá môže spôsobiť zmenu stavu.

    Stráž, ak je špecifikovaná, je logickou podmienkou, ktorá musí byť splnená, aby sa prechod uskutočnil. Aktivita je určité správanie systému počas prechodu. Môže to byť akýkoľvek prejav správania. Úplná forma spúšťača ID môže zahŕňať viacero udalostí a parametrov. Prechod zo stavu čakania (obr. 10.1) do iného stavu možno čítať ako „V stave čakania, ak je sviečka odstránená, vidíte zámok a prejdete do stavu zablokovania“.

    Všetky tri časti popisu prechodu sú voliteľné. Vynechanie aktivity znamená, že sa počas prechodu nič nedeje. Preskočiť stráže znamená, že prechod sa vždy vykoná, ak nastane spúšťacia udalosť. Identifikátor spúšťača zriedka chýba, ale stáva sa to. To znamená, že prechod nastáva okamžite, čo možno pozorovať hlavne v aktívnych stavoch.

    Keď v určitom stave nastane udalosť, potom je možné z tohto stavu urobiť len jeden prechod, napríklad v stave Lock (obr. 10.1) sa musia ochrany vzájomne vylučovať. Ak dôjde k udalosti a nie sú povolené žiadne prechody – napríklad zatvorenie trezoru v stave čakania alebo odstránenie sviečky pri otvorených dverách – udalosť sa ignoruje.

    Koncový stav ( konečný stav) znamená, že stavový automat skončil, čo spôsobí vymazanie objektu radiča. Takže pre tých z vás, ktorí neboli dostatočne opatrní, aby spadli do pasce, keďže objekt ovládača prestáva existovať, sme nútení dať králika späť do klietky, poutierať podlahu a reštartovať systém.

    Pamätajte, že štátne automaty môžu zobrazovať iba objekty, ktoré sú priamo pozorované alebo na ktoré sa pôsobí. Takže aj keď by ste mohli očakávať, že niečo vložíme alebo vyberieme z trezoru, keď sú dvere otvorené, na schéme sme to nezaznačili, pretože nám o tom ovládač nemôže nič povedať.

    Keď vývojári hovoria o objektoch, často odkazujú na stav objektov, čo znamená kombináciu všetkých údajov obsiahnutých v poliach objektu. Stav v diagrame stavového stroja je však abstraktnejším pojmom stavu; ide o to, že rôzne stavy znamenajú rôzne spôsoby reakcie na udalosti.

    Interné aktivity v prehľade stavu

    Štáty môžu reagovať na udalosti bez vykonania prechodu pomocou interné aktivity (interné aktivity), v tomto prípade sa udalosť, stráž a činnosť umiestnia do štátneho obdĺžnika.

    Na obr. Obrázok 10.2 zobrazuje stav s internými aktivitami symbolov a systémovými udalosťami pomocníka, ktoré môžete sledovať v textových poliach editora. UI. Vnútorná aktivita je ako sebaprechod – prechod, ktorý sa vracia do rovnakého stavu. Syntax interných aktivít je postavená podľa rovnakej logickej schémy udalostí, ochrán a postupov.

    Na obr. 10.2 zobrazuje aj špeciálne aktivity: vstupné a výstupné činnosti. vstupná činnosť vykonaný vždy, keď vstúpite do štátu; výstupná činnosť– vždy, keď opustíte štát. Vnútorné aktivity však nezačínajú vstupná a výstupná činnosť; toto je rozdiel medzi interné aktivity asebaprechody .

    Aktivita uvádza stavový diagram

    V stavoch, ktoré sme doteraz opísali, je objekt tichý a čaká na ďalšiu udalosť, kým niečo urobí. Sú však možné stavy, v ktorých predmet vykazuje určitú aktivitu.

    Štát Hľadá sa na obr. 10.3 je taký stav stav činnosti: prebiehajúca aktivita je označená symbolom robiť/; preto ten termín vykonávať činnosť (byť aktívny). Po dokončení vyhľadávania sa vykonajú prechody bez aktivity, ako napríklad zobrazenie nového vybavenia (Zobraziť nový hardvér). Ak sa počas aktivity vyskytne udalosť zrušenia ( Zrušiť), potom robiť-činnosť sa jednoducho preruší a vrátime sa do stavu Okno aktualizácie hardvéru.

    Činnosti aj bežné činnosti predstavujú prejav nejakého správania. Zásadný rozdiel medzi nimi je v tom, že bežné činnosti sa dejú „okamžite“ a nemôžu byť prerušené bežnými udalosťami, zatiaľ čo činnosti môžu prebiehať na určitý obmedzený čas a môžu byť prerušené, ako je znázornené na obrázku 2. 10.3. Okamžitosť pre rôzne systémy sa interpretuje odlišne; pre systémy v reálnom čase to môže trvať niekoľko strojových inštrukcií a pre stolný softvér to môže trvať niekoľko sekúnd.

    AT UML 1 bežné činnosti sa označovali termínom akcie(akcia) a termín činnosť(činnosť) bola použitá len na do-činnosti.

    superštáty

    Často sa stáva, že viaceré štáty majú spoločné prechody a vnútorné aktivity. V takýchto prípadoch ich môžete zmeniť na podstavy (podstavy) a preniesť celkové správanie do nadstavu (nadstavu), ako je znázornené na obr. 10.4. Bez superštátu by sme prechod museli nakresliť Zrušiť(zrušiť) pre všetky tri štáty v rámci štátu Zadajte podrobnosti o pripojení.

    Paralelné štáty

    Štáty môžu byť rozdelené do viacerých súbežných stavov, ktoré prebiehajú súčasne. Na obr. Obrázok 10.5 ukazuje jednoduchý budík, ktorý dokáže zapnúť CD alebo rádio a ukáže buď aktuálny čas alebo čas signálu.

    Možnosti CD/rádia a aktuálny čas/čas budíka sú paralelné. Ak by ste to chceli znázorniť pomocou neparalelného stavového diagramu, skončili by ste s chaotickým diagramom, pretože je potrebné pridať stavy. Rozdelenie týchto dvoch správaní do dvoch stavových diagramov je oveľa jasnejšie.

    Ryža. 10.5 zahŕňa aj prehistorický stav(historický pseudostav). To znamená, že keď sú hodiny zapnuté, možnosť rádia/CD sa zmení na stav, v akom boli hodiny, keď boli vypnuté. Šípka vychádzajúca z histórie ukazuje, ktorý štát pôvodne existoval, keď neexistovali žiadne dejiny.

    Implementácia štátnych tabuliek

    Stavový diagram možno implementovať tromi hlavnými spôsobmi: pomocou vnoreného príkazu switch, vzoru stavu a tabuľky stavov. Najpriamejším prístupom k práci so stavovými diagramami je vnorený príkaz switch, ako napríklad ten na obrázku 1. 10.6.

    Hoci je táto metóda priama, je veľmi dlhá aj v tomto jednoduchom prípade. Navyše pri tomto prístupe je veľmi ľahké stratiť kontrolu, preto ho neodporúčame používať ani v elementárnych situáciách.
    Vzor Stav predstavuje hierarchiu stavových tried na spracovanie stavového správania. Každý stav v stavovom diagrame má svoju vlastnú podtriedu stavu. Radič má pre každú udalosť metódy, ktoré jednoducho presmerujú na stavovú triedu. Stavový diagram znázornený na obr. 10.1 je možné implementovať pomocou tried znázornených na obr. 10.7.

    Vrcholom hierarchie je abstraktná trieda, ktorá obsahuje popis všetkých metód, ktoré spracovávajú udalosti, ale žiadnu implementáciu.
    Pre každý konkrétny stav stačí prepísať obslužnú metódu konkrétnej udalosti, ktorá iniciuje prechod zo stavu.
    Stavová tabuľka predstavuje stavový diagram ako dáta.

    Takže schéma na obr. 10.1 môžu byť prezentované vo forme tabuľky. 10.1.
    Potom vytvoríme interpret, ktorý používa tabuľku stavov počas vykonávania programu, alebo generátor kódu, ktorý generuje triedy na základe tejto tabuľky.

    Je zrejmé, že väčšina práce na tabuľke stavov sa vykoná raz, ale potom ju možno použiť vždy, keď potrebujete vyriešiť problém súvisiaci so stavom. Tabuľku stavu behu je možné upraviť bez rekompilácie, čo je trochu pohodlné. Šablóna stavu sa ľahšie zostavuje a hoci každý stav vyžaduje samostatnú triedu, množstvo kódu, ktorý je potrebné napísať, je pomerne malé.

    Uvedené implementácie sú takmer minimálne, ale poskytujú predstavu o tom, ako aplikovať stavové diagramy. V každom prípade má implementácia stavových modelov za následok dosť stereotypný program, takže je zvyčajne lepšie použiť na to nejakú formu generovania kódu.

    Prihláste sa na odber noviniek na stránke, formulár na odber nájdete v pravom stĺpci stránky.

    Ak sa chcete naučiť pracovať na voľnej nohe profesionálne, pozývame vás na kurz „“.