UML diagram

Obsah

 [skryÅ¥] 

• 1 História
• 1.1 Pred UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Dizajn
• 2.1 Metódy vývoja softvéru
• 2.2 Modelovanie
• 3 diagramy
• 3.1 Štrukturálne diagramy
• 3.2 Diagramy správania
• 3.2.1 Diagramy interakcií
• 4 Meta modelovanie
• 5 Prijatie
• 6 Kritiky
• 6.1 Kritika UML 1.x

História[editovať zdroj | editovať]

História objektovo orientovaných metód a notácie

UML sa vyvíja od druhej polovice 90. rokov a má korene v objektovo orientovaných metódach vyvinutých koncom 80. a začiatkom 90. rokov. Na časovej osi (pozri obrázok) sú uvedené najdôležitejšie momenty histórie metód a notácie objektovo orientovaného modelovania.

Pôvodne vychádza z notácií Boochovej metódy, techniky objektového modelovania (OMT) a objektovo orientovaného softvérového inžinierstva (OOSE), ktoré integroval do jedného jazyka. ^[5]

Pred verziou UML 1.x[editovať zdroj | editovať]

Spoločnosť Rational Software Corporation najala Jamesa Rumbaugha z General Electric v roku 1994 a potom sa stala zdrojom dvoch najpopulárnejších objektovo orientovaných prístupov k modelovaniu v súčasnosti:^[6] Rumbaughova technika objektového modelovania (OMT) a metóda Gradyho Boocha. Čoskoro im v ich úsilí pomohol Ivar Jacobson, tvorca metódy objektovo orientovaného softvérového inžinierstva (OOSE), ktorý sa k nim v spoločnosti Rational pripojil v roku 1995. ^[1]

Pod technickým vedením týchto troch (Rumbaugh, Jacobson a Booch) bolo v roku 1996 zorganizované konzorcium s názvom UML Partners s cieľom dokončiť špecifikáciu Unified Modeling Language (UML) a navrhnúť ju skupine Object Management Group (OMG) na štandardizáciu. Partnerstvo obsahovalo aj ďalšie zainteresované strany (napríklad HP, DEC, IBM a Microsoft). Konzorcium UML Partners v januári 1997 navrhlo OMG návrh UML 1.0. V priebehu toho istého mesiaca UML Partners vytvorili skupinu, určenú na presné definovanie významu jazykových konštrukcií, ktorej predsedal Cris Kobryn a spravoval ju Ed Eykholt, s cieľom dokončiť špecifikáciu a integrovať ju s ostatnými štandardizačnými snahami. Výsledok tejto práce, UML 1.1, bol predložený OMG v auguste 1997 a OMG ho prijala v novembri 1997. ^[1][7]

UML 1.x[editovať zdroj | editovať]

Po prvom vydaní bola vytvorená^[1] pracovná skupina na zlepšenie jazyka, ktorá vydala niekoľko menších verzií 1.3, 1.4 a 1.5. ^[8]

Normy, ktoré vypracovala (ako aj pôvodná norma), boli označené za nejednoznačné a nekonzistentné. ^[9][10]

UML 2.x[editovať zdroj | editovať]

Hlavná revízia jazyka UML 2.0 nahradila v roku 2005 verziu 1.5, ktorá bola vyvinutá v rozšírenom konzorciu s cieľom ďalej vylepšiť jazyk a zohľadniť nové skúsenosti s používaním jeho funkcií. ^[11]

Hoci UML 2.1 nebol nikdy vydaný ako oficiálna špecifikácia, v roku 2007 sa objavili verzie 2.1.1 a 2.1.2, po ktorých vo februári 2009 nasledovala verzia UML 2.2. UML 2.3 bol oficiálne vydaný v máji 2010.^[12] UML 2.4.1 bol oficiálne vydaný v auguste 2011.^[12] UML 2.5 bol vydaný v októbri 2012 ako verzia "In process" a oficiálne bol vydaný v júni 2015. ^[12]

Špecifikácia UML 2.x má štyri časti:

1. Nadstavba, ktorá definuje notáciu a sémantiku diagramov a ich prvkov modelu
2. Infraštruktúra, ktorá definuje základný metamodel, na ktorom je založená nadstavba
3. Jazyk objektových obmedzení (OCL) na definovanie pravidiel pre prvky modelu
4. Výmena diagramov UML, ktorá definuje spôsob výmeny rozloženia diagramov UML 2

Aktuálne verzie týchto noriem sú uvedené nižšie: UML Superstructure verzia 2.4.1, UML Infrastructure verzia 2.4.1, OCL verzia 2.3.1 a UML Diagram Interchange verzia 1.0.^[13] Naďalej ich aktualizuje a vylepšuje pracovná skupina pre revíziu, ktorá rieši všetky problémy s jazykom. ^[14]

Dizajn[editovať zdroj | editovať]

Unifikovaný modelovací jazyk (UML) ponúka spôsob, ako vizualizovať architektonické plány systému v diagrame (pozri obrázok), vrátane prvkov, ako sú: ^[5]

• Akékoľvek činnosti (pracovné miesta)
• Jednotlivé komponenty systému
• A ako môžu spolupracovať s inými softvérovými komponentmi.
• Ako bude systém fungovať
• Ako entity spolupracujú s ostatnými (komponenty a rozhrania)
• Externé používateľské rozhranie

Hoci bol pôvodne určený výlučne na objektovo orientovanú návrhovú dokumentáciu, Unifikovaný modelovací jazyk (UML) bol rozšírený tak, aby pokrýval širší súbor návrhovej dokumentácie (ako je uvedené vyššie), ^[15]a ukázal sa ako užitočný v mnohých kontextoch. ^[16]

Metódy vývoja softvéru[editovať zdroj | editovať]

UML sám o sebe nie je vývojovou metódou; bol ^[17]však navrhnutý tak, aby bol kompatibilný s poprednými objektovo orientovanými metódami vývoja softvéru svojej doby (napríklad s metódamiOMT, Booch, Objectory) a najmä s metódou RUP, ktorá bola pôvodne určená na použitie, keď sa na nej začalo pracovať v spoločnosti Rational Software Inc.

Modelovanie[editovať zdroj | editovať]

Je dôležité rozlišovať medzi modelom UML a súborom diagramov systému. Diagram je čiastočná grafická reprezentácia modelu systému. Súbor diagramov nemusí úplne pokrývať model a vymazaním diagramu sa model nemení. Model môže obsahovať aj dokumentáciu, ktorá riadi prvky modelu a diagramy (napríklad písomné prípady použitia).

Diagramy UML predstavujú dva rôzne pohľady na model^[18] systému:

• Statický (alebo štrukturálny) pohľad: zdôrazňuje statickú štruktúru systému pomocou objektov, atribútov, operácií a vzťahov. Štrukturálny pohľad zahŕňa diagramy tried a diagramy zloženej štruktúry.
• Dynamický (alebo behaviorálny) pohľad: zdôrazňuje dynamické správanie systému zobrazením spolupráce medzi objektmi a zmien vnútorných stavov objektov. Tento pohľad zahŕňa sekvenčné diagramy, diagramy aktivít a diagramy stavových strojov.

Modely UML sa môžu vymieňať medzi nástrojmi UML pomocou výmenného formátu XML Metadata Interchange (XMI).

Schémy[editovať zdroj | editovať]

UML 2 má mnoho typov diagramov, ktoré sa delia do dvoch kategórií.^[5] Niektoré typy predstavujú štrukturálne informácie a ostatné predstavujú všeobecné typy správania, vrátane niekoľkých, ktoré predstavujú rôzne aspekty interakcií. Tieto diagramy možno hierarchicky kategorizovať, ako je znázornené na nasledujúcom diagrame^[5] tried:

Všetky tieto diagramy môžu obsahovať komentáre alebo poznámky vysvetľujúce použitie, obmedzenia alebo zámer.

Štrukturálne diagramy[editovať zdroj | editovať]

Štruktúrne diagramy zdôrazňujú veci, ktoré musia byť prítomné v modelovanom systéme. Keďže štrukturálne diagramy predstavujú štruktúru, používajú sa vo veľkej miere pri dokumentovaní softvérovej architektúry softvérových systémov. Napríklad diagram komponentov, ktorý opisuje, ako je softvérový systém rozdelený na komponenty, a zobrazuje závislosti medzi týmito komponentmi.

• Schéma komponentov
• Diagram tried

Diagramy správania[editovať zdroj | editovať]

Diagramy správania zdôrazňujú, čo sa musí v modelovanom systéme stať. Keďže diagramy správania znázorňujú správanie systému, používajú sa vo veľkej miere na opis funkčnosti softvérových systémov. Ako príklad možno uviesť diagram aktivít, ktorý opisuje obchodné a prevádzkové činnosti jednotlivých krokov komponentov v systéme.

• Diagram činností
• Diagram prípadov použitia

Diagramy interakcií[editovať zdroj | editovať]

Diagramy interakcií, ktoré sú podmnožinou diagramov správania, zdôrazňujú tok riadenia a údajov medzi jednotlivými vecami v modelovanom systéme. Napríklad sekvenčný diagram, ktorý ukazuje, ako objekty medzi sebou komunikujú v zmysle sekvencie správ.

• Sekvenčný diagram
• Komunikačný diagram

Meta modelovanie[editovať zdroj | editovať]

Hlavný článok: Metaobjektové zariadenie

Ilustrácia nástroja Meta-Object

Skupina Object Management Group (OMG) vyvinula architektúru metamodelovania na definovanie jednotného modelovacieho jazyka (UML), ktorá sa nazýva Meta-Object Facility (MOF).^[19] Meta-Object Facility je navrhnutá ako štvorvrstvová architektúra, ako je znázornené na obrázku vpravo. Poskytuje meta-meta-model na najvyššej vrstve, ktorá sa nazýva vrstva M3. Tento M3-model je jazyk, ktorý Meta-Object Facility používa na vytváranie metamodelov, nazývaných M2-modely.

Najznámejším príkladom modelu metaobjektového vybavenia vrstvy 2 je metamodel UML, model, ktorý opisuje samotný UML. Tieto M2-modely opisujú prvky vrstvy M1, a teda M1-modely. Išlo by napríklad o modely napísané v jazyku UML. Poslednou vrstvou je vrstva M0 alebo dátová vrstva. Používa sa na opis inštancií systému počas behu. ^[20]

Meta-model možno rozšíriť pomocou mechanizmu, ktorý sa nazýva stereotypizácia. Brian Henderson-Sellers a Cesar Gonzalez-Perez ho v článku "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" kritizovali ako nedostatočný/nevyhovujúci. ^[21]

Adopcia[editovať zdroj | editovať]

UML sa ukázal ako užitočný v mnohých kontextoch návrhu, a to až do ^[16]takej miery, že sa stal v komunite IT takmer všadeprítomným. ^[22]

Niekedy sa k nemu pristupovalo ako k striebornej guľke v dizajne, čo viedlo k problémom pri jeho používaní. Nesprávne používanie zahŕňa jeho nadmerné používanie (navrhovanie každej malej časti kódu systému pomocou neho, čo je zbytočné) a predpoklad, že každý môže pomocou neho navrhnúť čokoľvek (dokonca aj tí, ktorí neprogramovali). ^[23]

Je vidieť, že je to veľký jazyk s mnohými konštrukciami. Niektorí (vrátane Jacobsona) sa domnievajú, že ich je príliš veľa a že to bráni ich osvojeniu (a teda aj používaniu). ^[24]

Kritika[editovať zdroj | editovať]

Medzi^[4] časté kritiky UML zo strany priemyslu patria:

• nie je užitočné: "[neponúka] im výhody oproti ich súčasným, vyvinutým postupom a reprezentáciám"
• príliš zložité, najmä pre komunikáciu s klientmi: "Najlepší dôvod, prečo nepoužívať UML, je, že nie je "čitateľný" pre všetky zainteresované strany. Akú má UML hodnotu, ak obchodný používateľ (zákazník) nemôže pochopiť výsledok vášho modelovacieho úsilia?"
• potreba synchronizovať UML a kód, podobne ako pri dokumentácii vo všeobecnosti.

Kritika UML 1.x[editovať zdroj | editovať]

Zápis kardinality

Podobne ako v prípade databázových diagramov Chen, Bachman a ISO ER, aj v prípade modelov tried sa špecifikuje používanie kardinalít "look-across", hoci viacerí autori (okrem iných^[27] aj Merise, ^[25]Elmasri a Navathe^[26]) uprednostňujú rovnaké strany alebo "look-here" pre roly a minimálne aj maximálne kardinality. Nedávni výskumníci (Feinerer, ^[28]Dullea et. alia^[29]) ukázali, že technika "look-across" používaná v diagramoch UML a ER je menej efektívna a menej koherentná, ak sa aplikuje na n-árne vzťahy rádu >2.

Feinerer hovorí: "Problémy vznikajú, ak pracujeme so sémantikou look-across, ktorá sa používa pre asociácie UML. Hartmann^[30] túto situáciu skúma a ukazuje, ako a prečo rôzne transformácie zlyhávajú." (Hoci spomínaná "redukcia" je falošná, keďže oba diagramy 3.4 a 3.5 sú v skutočnosti rovnaké) a tiež "Ako uvidíme na niekoľkých nasledujúcich stranách, look-across interpretácia zavádza niekoľko ťažkostí, ktoré bránia rozšíreniu jednoduchých mechanizmov z binárnych na n-árne asociácie."