Novinky ve standardu UML 2.0

Novinky ve standardu UML 2.0

Moderní databáze 2005

Karel Richta

Novinky ve standardu UML 2.0 Karel Richta

katedra počítačů FEL ČVUT Karlovo nám.13, 121 35 Praha 2 Tel: +420 2 2435 7319 e-mail: [email protected] www: http://cs.felk.cvut.cz/~richta Klíčová slova: UML, MDA, MDD, XMI Abstrakt: Unifikovaný modelovací jazyk UML představuje prostředek pro komunikaci v komunitě softwarových inženýrů, vývojářů a databázových expertů. Příspěvek se zabývá novinkami, které přináší dlouho očekávaná verze UML 2.0. Hlavní důraz je kladen na specifikací řízený vývoj, který předpokládá, že co nejvíce kódu bude možno generovat ze specifikace, aby architekt a vývojář mohli pracovat s modelem, nikoliv s detaily implementace.

1

Úvod

Unifikovaný modelovací jazyk UML byl vytvořen jako prostředek pro komunikaci v komunitě softwarových inženýrů, vývojářů a databázových expertů. První verze označená UML 1.0 přišla na svět v roce 1996. Vytvořila ji známá trojice „guru“ v oboru modelovacích technik – pánové Rumbaugh, Booch a Jacobson. V roce 1997 byla verze UML 1.1 akceptována sdružením OMG (Object Management Group). Po zkušenostech byla postupně doplňována až na současnou verzi UML 1.5, která pochází z roku 2003. Příspěvek se zabývá novinkami, které přináší dlouho očekávaná verze UML 2.0, která sice byla inzerována již v roce 2002, ale stále ještě není zcela hotova. Ve verzích 1.2 až 1.5 bylo do UML zahrnuto mnoho nových rysů, ale jejich sémantika nebyla vždy zcela precizní. Hlavní důraz verze 2.0 je kladen na možnost precizního vyjádření sémantiky zápisů v UML. Motivací je fakt, že nově vznikající systémy jsou natolik složité, že není možné používat při návrhu stejné postupy jako dříve. Novinkou by také měl být modelem řízený vývoj (MDD - Model Driven Development) a jemu odpovídající architektura (MDA - Model Driven Architecture). Specifikací řízený styl práce předpokládá, že co nejvíce kódu bude možno generovat ze specifikace, aby architekt a vývojář mohli pracovat s modelem, nikoliv s detaily implementace. Verze 2.0 byla navrhována tak, aby ten, kdo nemá o nové rysy zájem mohl používat UML stejně, jako dříve. Nové rysy ovšem mohou přinést výhody, a inspirovat nové podpůrné nástroje. To je konec konců jeden z hlavních účelů normativních specifikací.

2

Základní principy UML

Specifikace UML je v současné době vytvářena pomocí metamodelu – modelu, který vypovídá něco o modelech, které jsou specifikací zavedeny. Tento způsob definice není zcela formální, což ale na druhé straně přináší intuitivnější a pragmatickou definici, pochopitelnější případným realizátorům specifikace. Na druhé straně je nutno poznamenat, že tento způsob definice nevylučuje možnost vytvoření formálně přesné specifikace UML, která je ale ponechána na pozdější etapy rozvoje.

1



Karel Richta

Metamodel pro UML 2.0 byl navržen tak, aby splňoval následující principy: • Modularitu. Tento princip požaduje velkou soudržnost a malou souvztažnost při organizaci konstruktů do balíků a komponent metamodelu. • Vrstvení (Layering). Vrstvy v definici metamodelu UML odpovídají základní 4-vrstvé architektuře UML, struktura balíků je vytvářena tak, aby nižší vrstvy využívaly konstrukty z vyšších vrstev. • Dělení (Partitioning). Uvnitř jednotlivých vrstev je dbáno na oddělování samostatných konceptů. V případě základu jádra (InfrastructureLibrary), je snaha důsledně odlišit současné a budoucí prvky standardu. Při tom je nutno dbát na zachování soudržnosti a pokud možno malé souvztažnosti. • Rozšiřitelnost (Extensibility). UML může být rozšiřováno dvěma způsoby: 1) Nový dialekt UML může být definován pomocí profilů (InfrastructureLibrary::Profiles) tak, aby se obecné definice přizpůsobily konkrétní platformě (např. J2EE/EJB, .NET/COM+) a konkterétní doméně aplikace (např. finance, telekomunikace, letectví apod.) 2) Nový jazyk třídy UML může být budován nad společným základem, tj. s využitím částí infrastruktury (InfrastructureLibrary), které se doplní o potřebné metatřídy a metavztahy. Prvým způsobem vznikne dialekt UML, druhým nový prvek třídy UML jazyků. • Znovupoužití (Reuse). Základní knihovny prvků jsou vytvářeny tak, aby byly znovupoužitelné nejen pro definici UML, ale i pro architektonicky podobné metamodely jako je Meta Object Facility (MOF) nebo Common Warehouse Model (CWM).

3

Struktura UML 2.0

Specifikace standardu UML 2.0 je rozdělena do 4 základních částí: – definice infrastruktury – definuje základní elementy, základní architekturu, jádro UML společné pro UML a souvisejí, či podobné standardy, např. MOF či CWM, – definice superstruktury - popis prvků metamodelu, definuje konstrukty používané uživateli UML – elementy diagramů a diagramy, – definice výměnné struktury (diagram interchange) – pro export a import diagramů, formát pro výměnu dokumentů (diagramů) mezi různými nástroji, – Object Constraint Language (OCL) verze 2.0 – jazyk pro formálně přesný popis různých omezení platných v modelu.

Definice infrastruktury definuje základní elementy a jádro UML – jako balík UML::InfrastructureLibrary::Core. K jádru dále definuje balík UML:: InfrastructureLibrary::Profiles,

2



Karel Richta

který slouží pro uzpůsobení prvků jádra pro různá prostředí. Definice superstruktury pak definuje konstrukty používané uživateli UML – elementy diagramů a diagramy.

4

Změny proti verzi UML 1.5

Ve verzi 2.0 přibyly některé nové diagramy, které v předchozích verzích nebyly. Některé diagramy doznaly určitých změn. Základní motivace změn byly: • V současné době je nutno usnadnit podporu vývoje založeného na komponentách. Proto přibyly prvky, které podrobněji popisují požadované a poskytované vlastnosti komponent, podrobnější specifikace rozhranní. • V řadě případů se vývoj týká aplikací požadujících nasazování tzv. „middleware“ a vytváření webových aplikací. Umožnit úplnější modelování výkonného kontextu komponent , což je zejména potřebné při. S tím souvisí podpora automatického implementování běžných vzorů pro interakci s typovými webovými komponentami. • Poskytnout standardní možnosti úpravy profilů pro rozmanitá prostředí a možnosti rozšíření pro významné jazyky. • Rozšířit možnosti UML pro systémy pracující v reálné čase. Patří sem podpora pro modelování vnitřní struktury takových systémů, včetně komunikačních cest, ale i popisu dynamického chování této vnitřní struktury. • Vylepšení stavového modelu o jasnější specifikaci vazby na chování a o pravidla pro specializaci. • Zdokonalení diagramu aktivit o lepší vlastnosti řídících a datových toků. • Podpora skládání interakčních mechanismů – v rámci popisu scénářů je výhodné umožnit definování sekvencí interakcí, alternativní interakce a paralelní vykonávání.

5

Nové diagramy ve verzi UML 2.0

Nové prvky UML 2.0 se většinou týkají popisu chování. Tento popis byl v předchozích specifikacích často neúplný, či nejednoznačný, což neumožňovalo využít takový popis pro generování. Statické specifikace nedoznaly zdaleka takových změn, neboť byly již v předchozích verzím poměrně dobře rozpracovány. Přesto i zde přibývá nový diagram struktury, umožňující přesnější popis komponent a jejich vazeb. Model systému je v UML reprezentován sadou diagramů. Každý diagram může být popsán a podrobněji specifikován pomocí poznámek, které jsou uvedeny na tomto diagramu, ale nevztahují se k žádnému elementu tohoto diagramu. Nyní je možno pro diagram použít nový 2D element „frame“, který zahrnuje rámec (obdélník), hlavičku (popisek) a vlastní obsah. Hlavička obsahuje volitelný druh rámce (zde Package), jméno rámce (zde P) a případné parametry (zde nejsou). Jméno rámce představuje prostor jmen pro elementy uvedené uvnitř rámce.

Na úrovni diagramů jsou povoleny následující druhy rámců – aktivita (activity), třída (class), komponenta (component), interakce (interaction), balík (package), stavový automat (state machine) a případ použití (use case). Lze také používat jednoznačné zkratky těchto druhů, např. „pkg“ pro „package“. Stejný symbol lze používat i uvnitř diagramů, např. ve scénářích lze takto označit opakované sekvence. Jako druh rámce je pak možno použít např. smyčku (loop), alternativu (alt), apod, parametrem bude odpovídající podmínka.

3



Karel Richta

Pro srovnání diagramů různých verzí poslouží následující tabulka. Nové prvky jsou vyznačeny tučně. UML 1.5

UML 2.0

Diagram tříd (class diagram)

Diagram tříd (class diagram)

Diagram objektů (object diagram)

Diagram objektů (object diagram)

Model jednání (use case diagram)

Model jednání (use case diagram)

Scénář (sequence diagram)

Scénář (sequence diagram)

Diagram kolaborace (collaboration diagram)

Diagram komunikace (communication diagram)

Diagram aktivity (activity diagram)

Diagram aktivity (activity diagram)

Stavový diagram (statecharts diagram)

Stavový diagram (state machine diagram)

Diagram komponent (commponent diagram)

Diagram komponent (commponent diagram)

Diagram nasazení (deployment diagram)

Diagram nasazení (deployment diagram) Diagram struktury (composite structure diagram) Diagram struktury balíků (package diagram) Přehledový diagram interakce (interaction overview diagram) Časový diagram (timing diagram)

4


5.1


Karel Richta

Diagramy tříd a objektů

Základní pojmy a elementy diagramů tříd a objektů se nezměnily. Určité změny ale nastaly v metamodelu UML. Při modelování typů objektů lze využívat buď atributy nebo vztahy – např. počet kreditů studenta můžeme modelovat jako atribut třídy „Student“, ale také jako vztah mezi třídou „Student“ a třídou „Celé číslo“. Obvykle lze v takovém případě využít agregaci, která navíc může být orientovaná (takový vztah je obvykle využíván jednosměrně – ptáme se na počet kreditů studenta, neptáme se na studenty daného kreditu). Obecný pojem UML 2.0 pro atributy a jednosměrné vztahy je vlastnost – „property“.

Další změnou v diagramech tříd a objektů je, že k definici vlastnosti (atributu nebo vztahu) je možno připojit nová standardní omezení. Jsou nazývána „property strings“ a jako všechna omezení UML se uvádějí ve složených závorkách. Patří sem následující omezení: pouze pro čtení {readOnly}, sjednocení {union}, podmnožina {subsets <property-name>}, redefinice {redefines <propertyname>}, uspořádání {ordered}, batoh {bag}, posloupnost {seq} nebo {sequence}, a složený {composite}. Pokud je některá vlastnost <x> zděděna od předka, chápe se implicitně jako předefinovaná (nemusí se explicitně označovat {redefines <x>}). Jméno vlastnosti, která je předefinována, není zděděno do nového prostoru jmen a toto jméno proto může být použito i pro další vlastnosti (redefinované nebo nové). Důležitá změna notace se týká elementu rozhranní (interface). Ve starších verzích UML se pro rozhranní používala jako ikona kroužek, propojený s poskytovatelem a konzumentem tohoto rozhranní. Tím nebylo možno jednoduše určit, kdo toho rozhranní poskytuje a kdo užívá. UML 2.0 proto zavádí nové ikony pro implementované rozhranní (ball) a požadované rozhranní (socket, celkově se používá termín „ball-and-socket“). Rozhranní se samozřejmě rovněž využívá v diagramech komponent.

5.2

Diagramy struktury balíků (package diagrams)

Tento typ diagramu byl dříve zahrnován do diagramů tříd a objektů. V současné verzi jsou diagramy tříd, diagramy objektů a diagramy struktury balíků nazývány souhrnně diagramy struktury. Není nijak striktně předepisováno, co má který z nich obsahovat, ale typicky se předpokládá, že diagramy tříd obsahují především modelované třídy a vztahy mezi třídami (asociace, agregace, kompozice,

5



Karel Richta

generalizace). Navíc mohou obsahovat obecné závislosti (dependencies), vztahy realizace (něco realizuje něco jiného) a rozhranní (interfaces). Diagramy objektů typicky obsahují instance tříd (objekty) a vztahy mezi nimi (nazývané „links“ pro odlišení instance vztahu od vztahu). Diagramy struktury balíků obsahují balíky (packages), obecné závislosti mezi nimi (dependencies) a speciální závislosti mezi nimi – rozšíření (package extensions), sloučení (package merge) a import (package import). Pro tyto speciální závislosti jsou v UML 2.0 zavedeny nové standardní stereotypy <<merge>>, <> a <<use>>, kterými se specifikují vztahy závislosti mezi balíky.

Sloučení balíků (package merge) představuje možnost vyjádření faktu, že závislé balíky mohou obsahovat elementy stejného jména i druhu, které pak ve sloučení figurují pouze jednou. Při exportu modelu může být využíváno sloučení, nebo se musí nahradit kombinací importů, generalizací a redefinic přetížených kolidujících elementů. Operace sloučení balíků má přesně stanovený význam pro jednotlivé prvky slučovaných balíků. Jako příklad diagramu struktury balíků může dobře posloužit popis struktury superstruktury UML 2.0.

6



Karel Richta

Dalším novým prvkem použitelným pro strukturní prvky je „port“. Port specifikuje propojení mezi třídou nebo komponentou a jejím okolím. Port může zahrnovat několik rozhraní.

5.3

Diagramy struktury (Composite Structure Diagrams)

Diagram struktury zachycuje vnitřní strukturu nějakého klasifikátoru, což může být třída, případ použití (use case), kolaborace objektů, nebo aktivita. Popisuje zúčastněné elementy a jejich vztahy, zejména z pohledu daného klasifikátoru. Klasifikátor je podle definice jakási kolekce instancí, které mají něco společného. Klasifikátor vyjadřuje vlastnosti, které charakterizují jeho instance. Za klasifikátor lze považovat třídu, interface, datový typ, či komponentu. Klasifikací se pak rozumí proces, kdy nějaké instanci přidělujeme její klasifikátor. Jedná se o pohled charakterizující běh (runtime structure).

7



Karel Richta

Diagramy, které zachycují statickou strukturu pomocí diagramů tříd, objektů a balíků již současné nástroje dokáží úspěšně využít pro generování kódu. Specifikace chování to doposud pro neúplnost a nejednoznačnost informací zaznamenávaných v interakčních diagramech neumožňovala. Specifikace UML 2.0 proto obsahuje více přesnějších informací v diagramech popisujících dynamické chování.

5.4

Přehledové diagramy interakce (Interaction Overview Diagrams)

Tento diagram je v UML 2.0 nově zaveden. Spojujeje vlastnosti diagramu aktivit a sekvenčního diagramu. Je možné jej chápat tak, že jednotlivé aktivity v diagramu aktivit jsou zaznamenány pomocí sekvenčního diagramu.

5.5

Časové diagramy (Timing Diagrams)

Jedná se opět o diagram nově zavedený. Je určen především pro systémy reálného času a zaznamenává časová omezení spojená se změnou stavu jednotlivých objektů.

8


6 6.1


Karel Richta

Změněné diagramy ve verzi UML 2.0 Diagramy komunikace (Communicatíon Diagrams)

Ve starších verzích UML existovaly diagramy kolaborace objektů. Byly to diagramy alternativní ke scénářům, kdy se ovšem hlavní důraz kladl na komunikaci mezi objekty, zatímco ve scénáři měl přednost čas. Termín kolaborace má v UML 2.0 nový význam, proto se tyto diagramy přejmenovaly na diagramy komunikace. Nová definice kolaborace říká, že za kolaboraci považujeme případ, kdy operátor nebo klasifikátor (jako např. případ použití) realizován pomocí klasifikátorů a asociací, které hrají jistou specifickou roli a jsou používány jistým specifickým způsobem. Kolaborace definuje interakci.

9


6.2


Karel Richta

Scénáře (sekvenční diagramy, sequence diagrams)

Zde jsou ve specifikaci UML 2.0 podstatná rozšíření, která zvyšují výrazové možnosti tohoto typu diagramu. Cílem bylo zvýšit možnosti pro generování kódu. Scénáře realizující jistý případ použití systému mají různé alternativy, mohou se v nich vyskytovat určité opakující se sekvence apod. Bylo proto umožněno ve scénářích využívat interakční rámce, pomocí nichž lze zaznamenat např. iterace (opakování) a selekce (větvení).

Povolené druhy pro rámce ve scénářích jsou: Sekvence (sd) - slouží k ohraničení posloupnosti, příp. celého scénáře, pokud je to účelné.

10



Karel Richta

Selekce (alt) – fragment, který se skládá se z více alternativ. Každá alternativa má podmínku, vykonána je ta alternativa, jejíž podmínka je splněna. Iterace (loop) - fragment naznačující opakování. Fragment se může opakovat vícekrát, přičemž podmínka popisuje způsob iterace. Podmíněný (Opt) - podmíněný fragment, který je vykonán pouze tehdy, je-li splněna u něj uvedená podmínka. Je ekvivalentní s fragmentem alternativy s jedinou alternativou (neúplný podmíněný příkaz). Paralelní (Par) - Paralelní fragmenty, všechny jsou vykonávány paralelně. Region – kritická sekce, fragment může mít jediné vykonávané vlákno. Negace (Neg) - odmítnutý (negativní) fragment. Fragment popisuje chybnou interakci. Reference (Ref) - odkazuje na interakci definovanou v jiném diagramu. Rámec je nakreslen tak, že překrývá část týkající se požadované interakce. Mohou zde být uvedeny parametry a návratové hodnoty. Rámce mají v hlavičce uvedeny i případné podmínky pro větvení či opakování. Rámec s hlavičkou „loop {for each …}“ představuje opakování pro všechny výskyty dané entity.

6.3

Stavové diagramy (state machine diagrams)

UML 1 rozlišoval akce a aktivity. UML 2 používá pro pouze termín aktivita.

11


6.4


Karel Richta

Diagramy aktivit (aktivity diagrams)

UML 1 chápal tento diagram jako speciální případ stavového diagramu. V UML 2 je založen na Petriho sítích a popisuje především tok příznaků (token flow). Pojem swim lanes je nahrazen pojmem partition a může mít více dimenzí. S aktivitami je možné spojit piny, které ukazují hodnoty (parametry operací), které aktivita přijímá(input pin) a produkuje(output pin).

6.5

Diagramy komponent (component diagrams)

Kvůli nepřehlednosti diagramů s motivy komponent jako „softwarových čipů“ byla v UML 2.0 změněna ikona pro komponentu – používá se obdélník (jako pro třídu), ale označený ikonou komponenty v pravém horním rohu. Je možné pracovat s porty a nabízeným a poskytovaným rozhraním.

12



Karel Richta

Došlo také k významovému posunu pojmu komponenta - samotný pojem komponenta nezahrnuje fyzické prvky systému (DLL, zdrojové soubory, …) jako tomu bylo v prvních verzích UML. V UML 1.4 byla komponenta definována jako modulární, nasaditelná a nahraditelná část systému, která zapouzdřuje implementaci a zveřejňuje množinu rozhraní. Byla tedy chápána jako specializace klasifikátoru. V UML 2.0 je komponenta definována jako modulární část systému, která zapouzdřuje svůj obsah a jejíž projev je nahraditelný v daném prostředí. Je tedy chápána jako specializace strukturované třídy (Part, Konektor, Port).

7

Závěr

Pro potřeby specifikací řízeného vývoje samotný jazyk UML nestačí. Neumožňuje popsat všechny skutečnosti a podmínky platné v modelované doméně. UML proto obsahuje speciální formální jazyk pro přesné formální vyjádření různých omezení a podmínek. Ve verzi UML 2.0 došlo také k podstatnému vylepšení jazyka OCL. Teprve UML model doplněný o výrazy zapsané v OCL poskytuje dostatek informací pro nástroje podporující specifikací řízený vývoj (MDD).

13



Karel Richta

Literatura [1] Borland: Practical UML: A Hands-On Introduction for Developers , http://info.borland.com/techpubs/together/together_guides/umlonlinecourse [2] Sklenář, V., Kudělka, M.: Co je nového v UML 2.0. In: Objekty 2004, PEF ČZU Praha 2004. [3] UML 2.0 – Infrastructure. OMG Final Adopted Specification, ptc/03-09-15. http://www.omg.org/uml [4] UML 2.0 – Superstructure. OMG Final Adopted Specification, ptc/03-08-02. http://www.omg.org/uml [5] UML 2.0 – Diagram Interchange Specification. OMG Final Adopted Specification, ptc/03-0901. http://www.omg.org/uml [6] UML 2.0 – OCL Specification. OMG Final Adopted Specification, ptc/03-10-14. http://www.omg.org/uml

Summary The Unified Modeling Language UML represents known communication tool in the community of software engineers, developers, and database experts. The paper deals with the novelties of the announced new version 2.0. The main contribution of this version shall be support of specification driven development (also called MDD - Model Driven Development), and appropriate description of architecture (MDA - Model Driven Architecture). The more precise the model is, the more enables to generate at least parts of the solution from the specification.

14

Novinky ve standardu UML 2.0

Recommend Documents