wiki.valek.net

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 22. Unified Modeling Language ======

Charakterizujte UML, jeho historický vývoj i současný stav. Charakterizujte základní diagramy UML a jejich využití. Jaké jsou možnosti rozvoje UML? Co je to MOF?
Jaké jsou přednosti a nedostatky UML? Jaká je podpora UML v CASE nástrojích a metodikách?
===== Úloha =====
**Předpoklady:** 
Jste vedoucím projektu vývoje IS objektově-orientovaným způsobem.

**Zadání:**
  * Jaké argumenty poskytnete vývojářům pro to, aby modelovali? 
  * Jaká kriteria použijete pro výběr vhodného CASE nástroje případně proč nepoužijete CASE nástroj.

===== Teorie =====

[[statnice:slovnik:mof|MOF]] - jakýsi standardizovaný jazyk pro tvorbu metamodelů. Je v něm vytvořen i metamodel UML.

==== Stručný popis jazyka UML ====

Jazyk označovaný zkratkou UML neboli Unified Modeling Language je, jak již název napovídá, unifikovaný modelovací jazyk, který má, na rozdíl od převážně textově orientovaných programovacích jazyků, vlastní grafickou syntaxi (tj. pravidla pro sestavování jednotlivých elementů jazyka do větších objektů) a sémantiku (tj. jednoznačná pravidla určující jednotlivým syntaktickým výrazům jejich význam).

V současné době má jazyk UML největší význam při návrhu softwarových systémů, protože objektově orientovaný návrh každé složitější aplikace je nezbytným předpokladem pro její úspěšnou a rychlou implementaci. Pro objektově orientovaný návrh je samozřejmě možné použít různé podpůrné prostředky, zejména další odlišné typy diagramů, UML je však významné také v tom ohledu, že přesně specifikuje, co má daný diagram obsahovat, což je velmi důležité zejména při sdílení informací mezi jednotlivými analytiky a vývojáři. Dále je již z principu UML nutné, aby vytvářené grafy měly vnitřní konzistenci a přesně danou sémantiku, což u jiných typů grafů nemusí být obecně zaručeno. UML diagramů existuje několik typů lišících podle toho, jaké se pomocí nich plánují či zpracovávají úlohy. Tyto diagramy se od sebe odlišují především repertoárem použitých značek, způsobem jejich vzájemného propojení a s nimi související sémantikou.

Mezi velké přednosti jazyka UML i na něm postavených UML diagramů patří existence otevřeného a rozšiřitelného standardu, podpora celého vývojového cyklu aplikace či jiného (ne nutně programového) systému a velká podpora pro různé aplikační oblasti. Pro širší využití jazyka UML v praxi mluví také významný fakt, že je podporován celou řadou vývojových nástrojů, ať už samostatných aplikací určených pouze pro práci s UML, nebo i integrovaných vývojových prostředí (IDE), které v některých případech dovolují provádět převod informací mezi UML diagramem a algoritmem zapsaným v programovacím jazyce (a samozřejmě i opačným směrem, ten je však z pochopitelných důvodů složitější a ne vždy uskutečnitelný).

Podrobnější popis jazyka UML je uveden například na stránce http://www.interval.cz/clanek.asp?article=2783

==== Historie ====
  * 1995 - Byla jednou jedna metodika s názvem OMT pro object-oriented analýzu (OOA), Booch metodika pro pro object-oriented design (OOD) a OOSE (object-oriented software engineering). Každá byla dítětem jiného pána: Rumbaugh, Booch a Jacobson. A ti se pořád hádali, protože se sešli v jediné firmě - Rational.
  * 1996 dostali za úkol navrhnout společný neproprietální modelovací jazyk
  * z různých kandidátů nakonec vyhrála notace dnešního UML, verze 1.0 vyšla v roce 1997, následována verzí 1.1
  * verze 2.0 vyšla v roce 2003, která rozděluje UML na Superstructure (notace a sémantika diagramů), Infrastructure (metamodel), Object-Constraint Language (OCL, pro definice omezujících pravidel) a UML Diagram Interchange (zajištění přenositelnosti UML diagramů)
  * UML spravuje od jeho první verze konsorcium OMG (Object Management Group)






==== Princip a základní elementy jazyka UML ====

Celý jazyk UML je založený na třech elementech, které ale nejsou z uživatelského hlediska reprezentovány v textové podobě, ale grafickými značkami v plošném (tj. dvourozměrném) grafu. Tyto tři základní elementy jazyka UML se dle své funkce nazývají:

  - Předměty
  - Relace
  - Diagramy

V dalších kapitolách bude význam jednotlivých elementů grafického jazyka UML popsán podrobněji. Ve třetí kapitole si popíšeme význam předmětů, v kapitole čtvrté význam relací a konečně v kapitole páté význam celých diagramů jako objektů na nejvyšší hierarchii UML.

=== Předměty ===


Předměty jsou elementy zpracovávaného modelu, jež jsou následně členěny do několika navzájem rozdílných podkategorií. Prvním typem podkategorií jsou takzvané strukturní abstrakce UML modelu, například programové třídy, aplikační či objektové rozhraní, případy užití, komponenty či uzly. V diagramu UML jsou strukturní abstrakce zobrazeny jako různé převážně plošné tvary, které jsou však vždy uzavřené. Například se jedná o obdélníky, elipsy, kružnice či jednoduché zdánlivě trojrozměrné tvary, například krychle či kvádry. Každý smysluplný UML diagram by měl obsahovat alespoň dvě strukturní abstrakce, při jedné abstrakci totiž modelování ztrácí svůj hlavní smysl - popis vztahů mezi jednotlivými objekty.

Kromě strukturních abstrakcí patří mezi předměty i takzvaná chování, která v UML diagramu prezentují interakce, tj. vzájemné komunikace mezi jednotlivými objekty. Pomocí chování lze také modelovat stavový stroj, u nějž se stavy specifikují pomocí přechodů, událostí a aktivit. Chování se v UML diagramu většinou vyznačuje pomocí různým způsobem konstruovaných a různě zakončených šipek či propojovacích čar.

Mezi předměty patří i takzvané seskupení, které podle potřeby modelu graficky seskupuje části diagramu na nižší úrovni. Většinou se jedná o takzvané balíčky, jež mají tvar stylizované kancelářské složky s popisem umístěným v levé horní části obdélníku (zobrazení seskupení se však může v různých prostředích odlišovat). Seskupení nejsou v současné době v některých dále popisovaných aplikacích použitelná (tj. nelze vytvářet hierarchické diagramy), což je pro tvorbu rozsáhlejších grafů velké omezení.

Posledním a současně velmi jednoduchým typem předmětů jsou poznámky, které blíže specifikují vlastnosti a chování dalších elementů UML diagramu. Graficky jsou poznámky na prakticky všech typech UML diagramů většinou vyvedeny žlutě vyplněným obdélníkem s ohnutým rožkem.

=== Relace ===

Vzhledem k tomu, že v grafech je zapotřebí předměty různým způsobem navzájem propojovat, jsou v jazyku UML specifikovány i relace, tj. vztahy mezi různými předměty. V UML jsou rozeznávány následující podtypy relací (z čistě jazykového hlediska patří relace mezi základní elementy UML):

  - Asociace - pomocí asociací se modeluje obecná souvislost předmětů, která je však v diagramu UML přesným způsobem definovaná. Speciální variantou asociace jsou takzvané kompozice a agregace, které jsou často používány v objektově orientovaných jazycích a návrzích databází.
  - Závislost - použije se, pokud změna v jednom předmětu způsobí změnu v předmětu jiném, nebo mu známým způsobem poskytne požadovanou informaci.
  - Generalizace - pomocí generalizace se modeluje stav, kdy je jeden předmět specializací jiného předmětu. Tato relace je velmi často používána v objektově orientovaných jazycích, implementuje se většinou pomocí dědičnosti (inheritance).
  - Realizace - jedná se o druh vztahu, ve kterém jeden předmět představuje dohodu, za jejíž splnění je odpovědný jiný předmět. V objektově orientovaných jazycích se realizace vytváří pomocí rozhraní (interface) - samozřejmě za předpokladu, že daný OOP jazyk rozhraní podporuje.

=== Diagramy ===

Diagramy zachycují různé aspekty modelovaného systému, který nemusí být obecně vyjádřen pouze jedním UML diagramem, protože je možné například pomocí balíčků (packages) sdružovat více diagramů do jednoho hierarchicky organizovaného celku. Každý z níže vyjmenovaných typů diagramů obsahuje poněkud odlišný repertoár dostupných grafických značek (předmětů a relací). Liší se i v tom, že některé jsou statické, jiné zachycují dynamiku, jsou spíše technologické nebo naopak reprezentují lidský pohled na systém.

  * **Use Case** diagram - diagram užití [[wp>Use_case_diagram]] {{ statnice:vyvoj:hierarchie_uml_diagramu.png?400|Hierarchie UML diagramů}}
  * **Class** diagram - diagram tříd [[wp>Class_diagram]]
  * **Object** diagram - diagram objektů [[wp>Object_diagram]]
  * **Sequence** diagram - sekvenční diagram [[wp>Sequence_diagram]]
  * **Collaboration** diagram - diagram spolupráce
  * **Activity** diagram - diagram aktivit [[wp>Activity_diagram]]
  * **State Machine** diagram - stavový diagram [[wp>State_diagram]]
  * **Component** diagram - diagram komponent
  * **Package** diagram - diagram balíčků [[wp>Package_diagram]]
  * **Deployment** diagram - diagram nasazení [[wp>Deployment_diagram]]
  * **Composite structure diagram** (přidáno v UML 2) [[wp>Composite_structure_diagram]]
  * **Interaction overview diagram** (přidáno v UML 2)
  * **Timing diagram** (přidáno v UML 2)

 TODO: popsat jednotlivé diagramy FIXME

==== Kritika ====
  * přeplácanost - hodně diagramů je sporadicky využíváno, a často jsou hodně komplikovaný.
  * dlouho trvá se to naučit
  * snaží se být superuniverzální pro každého
  * formát XMI je přímo určený pro přenos UML modelů, ale v praxi je nepoužitelný (špatná implementace)
  * není turingově kompletní, tj. nedokáže obsáhnout úplně všechny aspekty, algoritmy atd. takže s ním nelze namodelovat systém do mrtě a nechat ho vygenerovat
  * OMG nenabízí žádnou test-suite na ověření, zda CASE nástroj podporuje UML korektně


===== Praxe =====
  * **Jaké argumenty poskytnete vývojářům pro to, aby modelovali?** 
Ujasní se tím analýza i návrh IS (rozložení komplexního problému na menší), umožní se tím spolupráce více lidí (jinak by stačilo to mít v hlavě), lepší identifikace problémů a nejasností dřív než se na to začne programovat, je to i forma dokumentace, dobré CASE nástroje z UML modelů vytvoří i kostru kódu a naopak - šetří to práci. Diagramy mohou být vhodné i pro prezentaci a ujasnění problémů s klientem.

  * **Jaká kriteria použijete pro výběr vhodného CASE nástroje případně proč nepoužijete CASE nástroj.**
Nejdříve srovnám, co mi CASE může nabídnout, z toho odvodím přínosy (časové, finanční, řešení problémů) a srovnám to s náklady. Záleží na ceně CASE, velikosti a komplexnosti projektu, počtu pracovníků a jejich zkušenostech s modelováním a s CASE nástroji. 

    - běžné nároky na aplikaci
      * uživatelské rozhraní
      * licenční podmínky
      * nároky na HW, operační systém
      * je to samostatná aplikace nebo plugin do IDE?
    - specifické nároky
      * zda podporuje pouze tvorbu diagramů, nebo celý životní cyklus projektu
      * zda umí kontrolovat syntaktickou správnost modelů
      * zda podporuje cetrální repository pro uložení modelů (spolupráce, verzování, přístupová práva k částem modelu)
      * generování kódu programovacího jazyka (jaké jazyky umí) a reverzní inženýrství a re-engineering (spojení reverzu a generování do vylepšení existujícího systému)
      * integrace s dalšími nástroji
      * podporované diagramy, resp. verze UML
      * jaké jsou možnosti přizpůsobení nástroje pro vlastní potřeby (rozšíření diagramů, nové diagramy, jiné možnosti)
      * podpora importu (XMI), exportu modelů (XMI, PDF, tisk, vektorové formáty) a jiných metadat (dokumentace)