Diagram UML

 [skrýt] 

• 1 Historie
• 1.1 Před verzí UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Design
• 2.1 Metody vývoje softwaru
• 2.2 Modelování
• 3 schémata
• 3.1 Strukturní diagramy
• 3.2 Diagramy chování
• 3.2.1 Diagramy interakcí
• 4 Meta modelování
• 5 Přijetí
• 6 Kritiky
• 6.1 Kritika UML 1.x

Historie objektově orientovaných metod a notace

UML se vyvíjí od druhé poloviny 90. let a má své kořeny v objektově orientovaných metodách vyvinutých na přelomu 80. a 90. let. Časová osa (viz obrázek) ukazuje hlavní body historie objektově orientovaných modelovacích metod a notací.

Původně vychází z notací Boochovy metody, techniky objektového modelování (OMT) a objektově orientovaného softwarového inženýrství (OOSE), které integroval do jednoho jazyka. ^[5]

Před verzí UML 1.x[editovat zdroj | editovat]

Společnost Rational Software Corporation najala v roce 1994 Jamese Rumbaugha ze společnosti General Electric a poté se stala zdrojem dvou nejpopulárnějších objektově orientovaných modelovacích přístupů té doby:^[6] Rumbaughova technika objektového modelování (OMT) a metoda Gradyho Boocha. Brzy jim v jejich úsilí pomohl Ivar Jacobson, tvůrce metody objektově orientovaného softwarového inženýrství (OOSE), který se k nim ve společnosti Rational připojil v roce 1995. ^[1]

Pod technickým vedením těchto tří osob (Rumbaugh, Jacobson a Booch) bylo v roce 1996 zorganizováno konsorcium nazvané UML Partners, jehož cílem bylo dokončit specifikaci jazyka UML (Unified Modeling Language) a navrhnout ji skupině OMG (Object Management Group) ke standardizaci. Partnerství zahrnovalo i další zainteresované strany (například HP, DEC, IBM a Microsoft). Konsorcium UML Partners navrhlo OMG návrh UML 1.0 v lednu 1997. Během téhož měsíce vytvořili UML Partners skupinu, určenou k přesnému definování významu jazykových konstrukcí, které předsedal Cris Kobryn a kterou spravoval Ed Eykholt, aby specifikaci dokončila a začlenila ji do dalších standardizačních snah. Výsledek této práce, UML 1.1, byl předložen OMG v srpnu 1997 a OMG jej přijala v listopadu 1997. ^[1][7]

UML 1.x[editovat zdroj | editovat]

Po prvním vydání byla vytvořena^[1] pracovní skupina pro vylepšení jazyka, která vydala několik menších revizí 1.3, 1.4 a 1.5. ^[8]

Normy, které vytvořila (stejně jako původní norma), byly označeny za nejednoznačné a nekonzistentní. ^[9][10]

UML 2.x[editovat zdroj | editovat]

Hlavní revize jazyka UML 2.0 nahradila v roce 2005 verzi 1.5, na jejímž vývoji se podílelo rozšířené konsorcium s cílem jazyk dále vylepšit a zohlednit nové zkušenosti s používáním jeho funkcí. ^[11]

Ačkoli UML 2.1 nebyl nikdy vydán jako oficiální specifikace, v roce 2007 se objevily verze 2.1.1 a 2.1.2 a v únoru 2009 UML 2.2. Verze UML 2.3 byla oficiálně vydána v květnu 2010.^[12] Verze UML 2.4.1 byla oficiálně vydána v srpnu 2011.^[12] UML 2.5 byl vydán v říjnu 2012 jako verze "In process" a oficiálně byl vydán v červnu 2015. ^[12]

Specifikace UML 2.x má čtyři části:

1. Nadstavba, která definuje notaci a sémantiku diagramů a jejich modelových prvků.
2. Infrastruktura, která definuje základní metamodel, na němž je založena nadstavba.
3. Jazyk OCL (Object Constraint Language) pro definování pravidel pro prvky modelu
4. Výměna diagramů UML, která definuje způsob výměny rozvržení diagramů UML 2.

Následují aktuální verze těchto norem: UML Superstructure verze 2.4.1, UML Infrastructure verze 2.4.1, OCL verze 2.3.1 a UML Diagram Interchange verze 1.0.^[13] Nadále je aktualizuje a vylepšuje pracovní skupina pro revize, která řeší veškeré problémy s jazykem. ^[14]

Unifikovaný modelovací jazyk (UML) nabízí způsob, jak vizualizovat architektonické plány systému v diagramu (viz obrázek), včetně prvků, jako jsou: ^[5]

• Jakékoli činnosti (pracovní místa)
• Jednotlivé součásti systému
• A jak mohou spolupracovat s ostatními softwarovými komponentami.
• Jak bude systém fungovat
• Jak entity interagují s ostatními (komponenty a rozhraní).
• Externí uživatelské rozhraní

Ačkoli byl původně určen výhradně pro objektově orientovanou návrhovou dokumentaci, byl Unified Modeling Language (UML) rozšířen na širší soubor návrhové dokumentace (jak je uvedeno výše) ^[15]a byl shledán užitečným v mnoha kontextech. ^[16]

Metody vývoje softwaru[editovat zdroj | editovat]

UML sám o sobě není vývojovou metodou, ^[17]nicméně byl navržen tak, aby byl kompatibilní s předními objektově orientovanými metodami vývoje softwaru své doby (napříkladOMT, Boochova metoda, Objectory) a zejména s RUP, pro který byl původně určen, když se na něm začalo pracovat ve společnosti Rational Software Inc.

Modelování[Upravit zdroj | Upravit]

Je důležité rozlišovat mezi modelem UML a souborem diagramů systému. Diagram je částečné grafické znázornění modelu systému. Soubor diagramů nemusí model zcela pokrývat a vymazáním diagramu se model nemění. Model může také obsahovat dokumentaci, která řídí prvky modelu a diagramy (například písemné případy užití).

Diagramy UML představují dva různé pohledy na model^[18] systému:

• Statický (nebo strukturální) pohled: zdůrazňuje statickou strukturu systému pomocí objektů, atributů, operací a vztahů. Strukturální pohled zahrnuje diagramy tříd a diagramy složené struktury.
• Dynamický (nebo behaviorální) pohled: zdůrazňuje dynamické chování systému tím, že zobrazuje spolupráci mezi objekty a změny vnitřních stavů objektů. Tento pohled zahrnuje sekvenční diagramy, diagramy aktivit a diagramy stavových strojů.

Modely UML lze mezi nástroji UML vyměňovat pomocí výměnného formátu XML Metadata Interchange (XMI).

UML 2 obsahuje mnoho typů diagramů, které se dělí do dvou kategorií.^[5] Některé typy představují strukturální informace a ostatní představují obecné typy chování, včetně několika, které představují různé aspekty interakcí. Tyto diagramy lze hierarchicky kategorizovat, jak ukazuje následující diagram^[5] tříd:

Všechny tyto diagramy mohou obsahovat komentáře nebo poznámky vysvětlující použití, omezení nebo záměr.

Strukturní schémata[editovat zdroj | editovat]

Strukturní diagramy zdůrazňují věci, které musí být v modelovaném systému přítomny. Protože strukturní diagramy představují strukturu, používají se hojně při dokumentování softwarové architektury softwarových systémů. Například diagram komponent, který popisuje, jak je softwarový systém rozdělen na komponenty, a ukazuje závislosti mezi těmito komponentami.

• Schéma komponent
• Diagram tříd

Diagramy chování[editovat zdroj | editovat]

Diagramy chování zdůrazňují, co se musí v modelovaném systému stát. Protože diagramy chování znázorňují chování systému, používají se hojně k popisu funkčnosti softwarových systémů. Jako příklad lze uvést diagram aktivit, který popisuje obchodní a provozní činnosti komponent systému krok za krokem.

• Diagram aktivit
• Diagram případů užití

Interakční diagramy[editovat zdroj | editovat]

Diagramy interakcí, které jsou podmnožinou diagramů chování, zdůrazňují tok řízení a dat mezi věcmi v modelovaném systému. Například sekvenční diagramkterý ukazuje, jak spolu objekty komunikují ve smyslu posloupnosti zpráv.

• Sekvenční diagram
• Komunikační schéma

Hlavní článek: Metaobjektové zařízení

Ilustrace nástroje Meta-Object Facility

Skupina Object Management Group (OMG) vyvinula architekturu metamodelování, která definuje Unified Modeling Language (UML) a nazývá se Meta-Object Facility (MOF).^[19] Meta-Object Facility je navržena jako čtyřvrstvá architektura, jak ukazuje obrázek vpravo. Poskytuje meta-meta-model v nejvyšší vrstvě, která se nazývá vrstva M3. Tento M3-model je jazykem, který Meta-Object Facility používá k vytváření metamodelů, nazývaných M2-modely.

Nejznámějším příkladem modelu metaobjektového vybavení vrstvy 2 je metamodel UML, model popisující samotný jazyk UML. Tyto M2-modely popisují prvky vrstvy M1, a tedy M1-modely. Jednalo by se například o modely napsané v jazyce UML. Poslední vrstvou je vrstva M0 neboli datová vrstva. Používá se k popisu instancí systému za běhu. ^[20]

Metamodel lze rozšířit pomocí mechanismu, který se nazývá stereotypizace. Brian Henderson-Sellers a Cesar Gonzalez-Perez v článku "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" tento mechanismus kritizují jako nedostatečný/neudržitelný. ^[21]

UML se ukázal jako užitečný v mnoha návrhových kontextech, a^[16] to do té míry, že se stal v komunitě IT téměř všudypřítomným. ^[22]

Někdy se s ním zacházelo jako s designovou stříbrnou kulkou, což vedlo k problémům při jeho používání. Jeho nesprávné použití zahrnuje jeho nadměrné používání (navrhovat s ním každou malou část kódu systému, což je zbytečné) a předpoklad, že s ním může navrhnout cokoli kdokoli (i ten, kdo neprogramoval). ^[23]

Je vidět, že jde o rozsáhlý jazyk s mnoha konstrukcemi. Někteří (včetně Jacobsona) se domnívají, že je jich příliš mnoho a že to brání jejich učení (a tedy i používání). ^[24]

Mezi^[4] nejčastější kritiky jazyka UML ze strany průmyslu patří:

• není užitečné: "[nenabízí] jim výhody oproti jejich současným, vyvinutým postupům a reprezentacím".
• příliš složité, zejména pro komunikaci s klienty: "zbytečně složitý" a "Nejlepší důvod, proč nepoužívat UML, je ten, že není "čitelný" pro všechny zúčastněné strany. Jakou má UML cenu, když obchodní uživatel (zákazník) nemůže pochopit výsledek vašeho modelovacího úsilí?".
• potřeba synchronizace UML a kódu, stejně jako u dokumentace obecně.

Kritika UML 1.x[editovat zdroj | editovat]

Zápis kardinality

Stejně jako u databázových diagramů Chen, Bachman a ISO ER jsou modely tříd specifikovány tak, aby používaly "look-across" kardinality, i když někteří autoři (mimo jiné^[27] Merise, ^[25]Elmasri & Navathe)^[26] preferují stejnou stranu nebo "look-here" pro role a minimální i maximální kardinality. Nedávní výzkumníci (Feinerer, ^[28]Dullea et. alia^[29]) ukázali, že technika "look-across" používaná v UML a ER diagramech je méně efektivní a méně koherentní, pokud se aplikuje na n-ární vztahy řádu >2.

Feinerer říká: "Problémy nastanou, pokud budeme pracovat se sémantikou look-across, která se používá pro asociace UML. Hartmann tuto situaci ^[30]zkoumá a ukazuje, jak a proč různé transformace selhávají." (I když zmíněná "redukce" je falešná, protože oba diagramy 3.4 a 3.5 jsou ve skutečnosti stejné) a také "Jak uvidíme na několika následujících stránkách, look-across interpretace přináší několik obtíží, které brání rozšíření jednoduchých mechanismů z binárních na n-ární asociace.".