Novinky ve specifikaci UML2

Obsah:

  1. Obsah
  2. Co je UML?
  3. Historie UML
  4. Verze 2.0
  5. Seznam použitých zdrojů
Logo UML

Co je UML?

UML (Unified Modelling Language) je jednotným jazykem pro specifikaci, vizualizaci, výstavbu a dokumentování částí softwarových systémů. Zjednodušuje celkový proces návrhu softwaru a vytváření plánu pro jeho tvorbu.

Historie UML

Počátky UML se datují do roku 1994, kdy Grady Booch a James Tumbaugh, odborníci přes objektové programování, spojili své síly ve firmě Rational. Došlo ke sloučení metodik Booch a OMT, čímž vlastně vznikl nový standard mezi prostředky objektové analýzy a designu. První výsledek jejich práce byl představen na konferenci OOPSLA `95 (Object-Oriented Programming Systems, Languages and Applications) pod názvem Unified Method v. 0.8. V roce 1995 se k firmě Rational přidala další významná osobnost, Ivar Jacobson, autor metodiky Objectory/OOSE. Následovaly verze 0.9 a 0.91. Ve verzi 1.0 byla Unified Method přejmenována na Unified Modeling Language a došlo ke strategickému spojení s Object Management Group v roce 1997. Změna názvu reflektovala posun od původní metodiky pro návrh a vývoj IS k prostředku pro tvorbu grafických modelů. Dále následovaly revize 1.1 až 1.5.

Verze 2.0

Bohužel UML ve verzích 1.x obsahuje některé nedostatky. Hlavní kritizované oblasti jsou:
  • nadměrná velikost a komplexita
  • rozdílnou přesnost modelů
  • nedostatečnou podporu pro komponenty a "spustitelné" modely
  • nestandardní implementace
  • nedostatečná podpora pro výměnu diagramů (diagram interchange)
  • nedostatečná podpora pro systémový engineering

Vzhledem k těmto, ale i dalším nedostatkům přistoupilo konsorcium OMG v polovině roku 2001 k vývoji verze UML 2.0, která by měla tyto problémy řešit. Specifikace UML 2.0 byla oficiálně adoptována v červnu 2003, konečná verze se očekává v dubnu roku 2004. Vzhledem k tomu, že bylo nutné s ohledem na velké množství požadavků především ze strany samotných členů OMG vývoj rozdělit do více částí, je nyní proces specifikace podle charakteru jednotlivých návrhů rozdělen do čtyřech balíků:

schéma balíků specifikace UML

Nejdůležitějším z pohledu uživatele je balík nadstavby, proto mu v následujícím textu věnuji nejvíc prostoru.

Infrastructure

Tento balík ošetřuje samotné jádro architektury, profily a stereotypy v UML. Změny v infrastruktuře nejsou nijak dramatické, jde spíše o další vývoj dosavadní specifikace v oblasti syntaxe. Tyto změny jsou směřovány především na výrobce modelovacích nástrojů.

Superstructure

Balík Superstructure se zaměřuje na statické a dynamické modely. Balík obsahuje celkem 13 diagramů, které se dělí na dvě části: diagramy struktury a diagramy chování. diagramy struktury jsou:
  • diagram tříd (Class Diagram)
  • diagram vnitřní struktury (Composite Structure Diagram )
  • diagram objektů (Object Diagram)
  • diagram komponent (Component Diagram)
  • diagram nasazení (Deployment Diagram)
  • diagram balíčků (Package Diagram)

diagramy chování jsou:

  • diagram užití (Use Case Diagram)
  • diagram aktivit (Activity Diagram)
  • stavový diagram (State Diagram)
  • a diagramy interakcí, které mohou být dále děleny na
    • sekvenční diagram (Sequence Diagram)
    • diagram komunikace (Communication Diagram)
    • přehled interakcí (Interaction Overview Diagram)
    • diagram časování (Timing Diagram)

Nejvýznamnějších změn doznaly tyto diagramy:

Sekvenční diagram

Základním účelem sekvenčního diagramu (Sequence diagram, Interaction diagram) je zachycení požadavků, sledování komunikace a vytváření testovacích úloh a sad. (všechny použité příklady jsou převzaty z [1] a [2]) Na příkladu z obr. 1 lze ukázat jednotlivé změny a vylepšení, které přináší UML 2.0. Obr. 2 ukazuje možnost použití variací v sekvenčním diagramu. Variace mohou být použity k vyjádření paralelismu a alternativ, iterací a volitelnosti nebo výjimek. Použití variací silně snižuje počet sekvenčních diagramů potřebných k popisu funkcionality systému.
obr.2:příklad sekvenčního diagramu
obr.1: příklad sekvenčního diagramu

obr.2: příklad použití variací
obr.2: příklad použití variací

Dalším prostředkem k zefektivnění návrhu je dekompozice. Dekompozice může být například použita pro ukrytí informace tak, že čára života (lifeline) je rozdělena do více detailních sekvencí. Příklad dekompozice ukazuje obr.3.
obr.3: použití dekompozice lifeline
obr.3: použití dekompozice lifeline

Obrázek 4 ilustruje použití referencí v sekvenčních diagramech. Abychom se vyhli duplicitě, je možné v diagramu odkazovat na již použitý sekvenční diagram. Tento postup je rychlým způsobem, jak vytvořit nové scénáře (např. testovací sady). Poslední představovanou novinkou v sekvenčním diagramu je organizování sekvencí. Jednotlivé sekvence je možné organizovat do toků (flows), takto je možné ukázat jejich návaznost – obr.4.
obr.4: použití referencí v sekvenčních diagramech
obr.4: použití referencí v sekvenčních diagramech

obr.5: použití organizování sekvencí
obr.5: použití organizování sekvencí

Novinkou v UML 2.0 je časovací diagram (Timing Diagram), používá se v případě znázornění takových interakcí, jejichž nejdůležitějším důvodem je otázka času. Timing diagram se používá pro znázornění činností, které jsou vyvolané během času.

Diagram aktivit

obr.6.: hierarchie v diagramu aktivit
obr.6.: hierarchie v diagramu aktivit

Oproti UML 1.x má activity diagram některá vylepšeni. Oddíly v activity diagramu mohou obsahovat své okraje, "plavecké dráhy" (swimlane – obdélníkové oddíly v activity diagramu) mohou být v případě, že je jejich popis příliš nešikovný, obsahovat dodatečné popisy, oddíly mohou být hierarchicky nebo multidimenzionálně řazeny. Použití hierarchického řazení a dodatečného popisu ilustruje obr.6.

Diagram komponent a kompozitní struktury

obr.7: komponentový vývoj - rozhraní
obr.7: komponentový vývoj – rozhraní

Diagram komponent přináší podporu pro komponentový vývoj aplikací. Některé implicitní konstrukce z UML 1.x byly změněny na explicitní a model byl upraven víc s ohledem na modelovací fázi vývoje systému (oproti implementační v UML 1.x). Komponentový vývoj vyžaduje modelování založené na rozhraních, rozhraní třídy ji definuje vůči svému okolí. Komponenta se svému okolí jeví jako černá skříňka, potřebná je jen znalost jejího rozhraní – viz příklad na obr.7. Vzájemná komunikace je možná jen mezi třídami se stejným rozhraním. Jako spojnice mezi okolím komponenty a jejím chováním fungují porty, ty jsou napojeny na vnitřní chování pomocí konektorů. Port může sloužit jako spojnice, skrze kterou může komponenta požadovat služby od prostředí, stejně tak jako může prostředí požadovat služby po komponentě. Struktura těchto požadavků je dána požadovaným a poskytovaným rozhraním (interface required, interface provided). Způsoby komunikace ilustrují obrázky 8 a 9.

obr.8: komunikace komponent 1
obr.8.: komunikace komponent 1

obr.9: komunikace komponent 2
obr.9: komunikace komponent 2

Object Constraint Language

UML diagram většinou není dostatečně definován tak, aby poskytl všechny stránky specifikace, mimo jiné je nutné popsat různé podmínky v modelu. Pro popis těchto podmínek se většinou používá přirozený jazyk, což však často k vede k nepřesnostem. Z tohoto důvodu se používají různé formální jazyky. Oproti ostatním formálním jazykům, které vyžadují matematické znalosti, je OCL snadný na zápis i čtení. OCL je ryze specifikačním jazykem, to znamená, že nemá žádné vedlejší efekty. Pokud je vyhodnocen výraz (expression) v OCL, je jednoduše vrácena hodnota, aniž by bylo cokoliv v modelu změněno. OCL není programovací jazyk, jde o jazyk modelovací, žádné výrazy v OCL tedy nejsou přímo vykonatelné. Navíc jde o jazyk typovaný, každý výraz má tedy svůj typ. Typy jsou definované v OCL, nezávislé na implementačním jazyku modelu. OCL se používá:
  • jako dotazovací jazyk
  • pro specifikaci invariant tříd a typů v modelu tříd
  • pro specifikaci typových invariant u stereotypů
  • pro popis předchozích a následujících podmínek operací a metod
  • pro specifikaci cílů zpráv a akcí
  • pro specifikaci podmínek operací
  • pro jakékoliv výrazy v UML modelu

V podstatě lze OCL použít k vyjádření jakéhokoliv výrazu v UML.

Diagram Interchange

Cílem této specifikace je umožnění snadné výměny dokumentů vyhovujících standardu UML mezi různými softwarovými nástroji. Důraz je také kladen na výměnu modelů po internetu. Přestože standard pro výměnu UML modelů byl již specifikován v UML 1.x za použití XMI (XML Metadata Interchange), nesplňoval tento mechanismus plně svůj účel, především nepodporoval výměnu informací o diagramu. Obsahoval pouze informaci, které elementy jsou obsaženy v modelu, ne však už to, jakým způsobem jsou tyto elementy reprezentovány a umístěny v diagramu. Toto omezení není přímo omezením XMI samotného, ale omezením vyplývajícím přímo z toho, že metamodel UML nedefinuje standardní způsob reprezentace definice diagramu. Řešením v UML 2 je rozšíření UML metamodelu o podpůrný balíček pro graficky orientované informace, přičemž UML metamodel zůstává nedotčen. Jako nadstavba UML metamodelu, umožňující rozšířit DTD XMI, je poskytován metamodel pro popis informací o UML diagramu.

Seznam použitých zdrojů: