TECHNICKÁ UNIVERZITA V KOŠICIACH

FAKULTA ELEKTROTECHNIKY A INFORMATIKY

Úvod do UML

Základy softvérového inžinierstva

2023 Roman Kočan

Obsah

UML – Unified Modeling language.........................................................................................................3

Typy UML diagramov..........................................................................................................................3

Štrukturálne diagramy............................................................................................................................3

Diagramy správania................................................................................................................................5

Vytváranie UML..................................................................................................................................7

Verzie UML.........................................................................................................................................8

Potreba modelu..................................................................................................................................9

Zdroje...................................................................................................................................................10

UML – Unified Modeling language Zjednotený modelovací jazyk, je určený na vizualizáciu, konštrukciu, špecifikáciu

a dokumentáciu systému. Daný systém popisuje na najabstraktnejšej úrovni. Zohľadňuje

model systému a špecifikáciu s požiadavkami. Na základe toho zjednodušuje celý proces

softvérového návrhu.

Základným cieľom je zjednodušiť a spresniť komunikáciu medzi programátormi. Bežný jazyk

– hovorená reč je nepresná, ale celý zdrojový kód je veľmi časovo náročný na vytvorenie

daného obrazu akú hierarchiu má daná aplikácia. Preto UML poskytne v krátkom čase,

presné a stručné informácie na celkový systém. Výhodou je, že nezávisí na programovacom

jazyku. Stále bude mať rovnakú podobu či ide o javu, C, C# alebo iné.

Typy UML diagramov

Štrukturálne diagramy

znázorňujú statické vlastnosti modelu. Sú to vlastnosti, ktoré sa nemenia v čase. Diagramy

odpovedajú na otázku: Čo je tu?

Diagramy tried (Class diagrams) – používajú sa na zobrazenie tried, rozhraní, ich detailov –

premenné, funkcie, privátne, verejné a vzťahov medzi nimi. Patrí medzi najpoužívanejšie.

Atribúty sú zapísané v tvare:

visibility name[multiplicity]: type_expression = initial_value

Operátory sú zapísané v tvare:

visibility name(parameter_list): return_type_expression

Pri označovaní operátorov sa používajú je na výber z troch možností:

+ public# protected- private

Vzťahy v diagrame tried:

Asociácia – ak dve triedy musia o sebe navzájom vedieť

Agregácia – ak jedna trieda, patrí do kolekcie druhej triedy.

Generalizácia – ak jedna trieda dedí od druhej

Závislosť – medzi triedami, inštanciami

Realizácia – vzťah medzi špecifikáciou a implementáciou.

Diagramy komponentov (Component diagrams) – znázorňujú časti softvéru v

implementačnom prostredí.

Diagramy zloženej štruktúry (Composite structure diagrams) – spájajú diagramy tried

a komponentov. Ukazujú spoluprácu jednotlivých elementov v systéme.

Diagramy rozmiestnenia (Deployment diagrams) – znázorňujú, ako je systém realizovaný a

priradený k rozličnému typu hardvéru. Obvykle sa používajú na zobrazenie toho, ako sú

komponenty nastavené počas behu systému.

Diagramy balíkov (Package diagrams) – Podobá sa na diagram tried, ale zobrazuje

zoskupenei jednotlivých tried a rozhraní do celkov.

Diagramy objektov (Object diagrams) – používajú tú istú syntax ako diagramy tried a

zobrazujú, ako spolu súvisia konkrétne inštancie tried v špecifickom časovom okamihu. Môžu

sa použiť na zachytenie vzťahov v systéme počas behu.

Diagramy správania

sa zameriavajú na správanie elementov v systéme , ukazujú ako sa systém mení v čase,

odpovedajú na žiadosti, eventy.

Diagramy aktivít (Activity diagrams) - zachycujú tok z jedného správania alebo aktivity do

druhého a interakciu medzi nimi.

Diagramy prípadov použitia (Use case diagrams) – zachytávajú funkčné požiadavky na

systém. Poskytujú pohľad nezávislý od implementácie na to, čo by systém mal robiť a

umožňujú tvorcom systému zamerať sa viac na potreby užívateľov, ako na detaily týkajúce sa

samotnej realizácie.

Stavové diagramy (State machine diagrams) – zachytávajú vnútorné zmeny nejakého

elementu. Element môže byť ako jedna trieda, alebo ako celý systém.

Diagramy interakcií (Interaction diagrams) - V predchádzajúcej verzii jazyka UML sa výraz

diagramy interakcií týkal sekvenčných diagramov (sequence diagrams) a diagramov

spolupráce (collaboration diagrams). Tieto dva typy diagramov popisovali komunikáciu

medzi objektmi za účelom splnenia istej úlohy, napr. zadanie objednávky. V UML 2.0 výraz

diagramy interakcií zahŕňa sekvenčné diagramy, diagramy komunikácie, diagramy prehľadu

interakcií a časové diagramy. Diagramy spolupráce boli nahradené diagramami komunikácie,

ktoré sú ich trošku jednoduchšou verziou. Každý 22 z týchto štyroch typov diagramov

reprezentuje určitý aspekt komunikácie medzi objektmi a poskytuje osobitý pohľad na túto

komunikáciu.

Sekvenčné diagramy (Sequence diagrams) - zdôrazňujú typ a poradie správ posielané medzi

objektmi počas realizácie správania. Sú najbežnejším typom diagramov interakcií a sú veľmi

intuitívne pre nových používateľov UML.

Diagramy komunikácie (Communication diagrams) – zameriavajú sa na objekty zúčastňujúce

sa určitého správania a ich štruktúru, a takisto si všímajú správy, ktoré si medzi sebou

posielajú.

Diagramy prehľadu interakcií (Interaction overview diagrams) – sú určitou verziou

diagramov aktivít, avšak namiesto zdôrazňovania aktivity v každom kroku sa zameriavajú na

to, ktoré elementy sa porieľajú na vykonávaní danej aktivity.

Časové diagramy (Timing diagrams) – zameriavajú sa na podrobné časové špecifikácie pre

správy. Majú špecifickú notáciu na zaznamenanie toho, ako dlho má systém spracovávať a

odpovedať na správy.

Vytváranie UMLNa vytváranie UML diagramov sa dá najjednoduchšie použiť hociaký program, ktorý

umožňuje kreslenie, prípadne podporuje základné geometrické útvary napríklad Skicár,

Microsoft Word.

Programy, špecializované iba na kreslenie UML modelov majú výhodu v tom, že jednotlivé

tvary, farby, spojitosti, možnosti už majú preddefinované, preto vytvorenie takejto schémy je

v podstate iba vyskladanie tvarov. Medzi takéto programy s nutnosťou stiahnutia a inštalácie

patrí napr. Visual paradiam, UMLet, Oracle SQL data modeller alebo UML studio. Existujú aj

taktiež webové stránky, ktoré priamo ponúkajú možnosť cez internetový prehliadač vytvoriť

daný model a neskôr ho vyexportovať do podporovaného formátu napr.

www.lucidchart.com, www.dravio.com, www.yuml.me a ďalšie.

Programy špecializované iba na konkrétny typ UML modelu, ako napríklad Oracle SQL data

modeller podporujú vytvorenie modelu z kódu alebo opačne - na základe modelu vytvorenie

kódu. Tento princíp sa využíva v MDE – model driven engeneering, kde na základe

detailného UML modelu, dokáže program vygenerovať funkčnú kostru programu,

spĺňajúceho požiadavky.

Verzie UML

Nevýhody verzie 1.x (1.0, 1.1, ...) spočívali v neformálnosti, nejednoznačnosti, podporovali

veľké množstvo diagramov a prvkov, ale nepodporovali komunikáciu, napríklad

prostredníctvom portov, konektorov, a protokolov. Preto vo verzii 2.0 bola väčšia časť

nedostatkov odstránená, keď už nie úplne, tak aspoň čiastočne. Pribudli nové diagramy

a dosťveľká zmena spočívala aj v zmene niektorý názvov (tabuľka).

UML 1.4 model element name UML 2.0 model element name

Association end Member end and Property

Object (when used in activity diagrams) Object node

Object (when used in sequence diagrams) Lifeline

Collaboration diagrams Communication diagrams

Swimlane (or partition) ActivityPartition

Activity Structured activity node

Decision Decision node or merge node

Final State or end state Final Activity Node

Initial state or start state Initial node

Object Instance (in activity diagrams) Central buffer node

State Structured activity node

State machine Structured activity node

Synchronization bar (synch bar) Fork node or Join node

Transition (on an activity diagram) Control flow

Transition condition (guard condition) Control flow guard

Formal Argument Template Parameter Substitution

Formal Arguments (collection of Formal Arguments) Template Binding

Three-tiered diagrams Class diagrams

Class Instance Lifeline

Self-link Message pathway

Connection relationship Communication Path

Process (in a deployment diagram) Artifact

Processor Execution environment

Destruction marker Stop node

Focus of Control Execution Occurrence

Action UML activity

State diagram Statechart diagram

Potreba modelu

Dátové modelovacie modely sú potrebné z niekoľkých dôvodov. Okrem spomínanej abstrakcie

a zjednodušeného pohľadu na dané softvérového riešenia, poskytuje možnosť experimentovania

s viacerými možnými riešeniami, znižuje riziko chýb, ktoré by mohli zvyknúť zo zle navrhnutých

závislostí a vzťahov, ktoré by sa pri konečnom štádiu zle opravovali, čo by bolo finančne a časové

náročné.

Zdroje

http://www.uml.org

http://sk.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Unified_Modeling_Language

https://sites.google.com/site/valasek/oss/uml-diagramy

http://www.itnetwork.cz/uml-uvod-historie-vyznam-a-diagramy

http://i.msdn.microsoft.com/dynimg/IC294848.png

http://upload.wikimedia.org/wikipedia/commons/thumb/9/9b/CheckEmail.svg/440px-

CheckEmail.svg.png

http://www.visual-paradigm.com/VPGallery/img/diagrams/TimingDiagram/Timing-Diagram-

Sample.png