Se snad blížícím se datem uvolnění  finální verze 2.0 jazyka UML je myslím přínosné popsat mé první zkušenosti s novou verzí. Myslím, že se druhá verze jazyka UML stejně jako verze 1.0 stane nepřehlédnutelným periodizačním mezníkem v oblasti analýzy a vývoje softwaru. S uvedením první verze jazyka UML v roce 1996 skončilo neplodné období válek mezi vzájemně se potírajícími  metodikami a jejich občas málo soudnými tvůrci, kteří by pravděpodobně nejraději své výtvory šířili s pěnou "u huby" ohněm i mečem. Málokdo také tušil, že UML předznamenává novou epochu. Epochu, v níž znalost UML je povinností nejen pro analytiky a designéry, ale alespoň pasivní znalost se předpokládá také u  vývojáře, jehož nejvyšší pracovní ambicí není kreativní psaní formulářů na editaci číselníků. Nic na tomto světě není nikdy perfektní a i pro UML po sérii dílčích vylepšení, jež vyústily ve verzi 1.5, nadešel čas na nový velký "release“ zaměřený na zacelení dlouhodobě pociťovaných mezer ve specifikaci, které se staly neblahým impulsem pro vznik proprietárních rozšíření. Tato rozšíření se zaměřovala hlavně na silnější podporu analytika modelujícího dynamické chovaní systémů. Three amigos vrací úder a odvrací hrozbu nového vysilujícího souboje disparátních specifikací vylepšeními ve verzi 2.0 jazyka UML. Vylepšeny byly nejen diagramy pro dynamické chování, ale byly také přidány zcela nové diagramy (Composite structure diagram, Timing diagram,  Interaction overview diagram) a rozšířeny takřka všechny ostatní a z verzí 1.x známé strukturní prvky.

Dnes se podíváme na vylepšení případů užití (Use Case), ve kterých ale k žádným velkým změnám nedošlo, protože jejich hlavním účelem  je vizualizovat funkční rozsah systému pro zákazníka a tak by příliš mnoho fines, ornamentů a vychytávek mohlo smysl diagramu spíše zatemnit. Případy užití jsou  přesto ve verzi 2.0 více provázány s ostatními diagramy, aby model systému působil kompaktnějším dojmem.

1. Kromě seskupování případů užití do balíčků, je možné je nyní seskupit v klasifikátoru. Toho využijeme například tehdy, když budeme psát informační systém pro velkou společnost a v modelu bude klasifikátor divize vyjadřující rozdělení společnosti do menších celků. Jestliže se liší případy užití realizované zaměstnanci různých divizí, například divize finanční a divize technologické, můžeme z důvodu větší názornosti klasifikovat případy užití jejich seskupením pod jednotlivé divize.
   
2. U vztahu Extend mezi případy užití je doporučeno zachytit podrobnosti rozšíření v poznámce (Note). Poznámka by měla mít strukturu:
   Condition:[Podmínka, při které nastane rozšíření]
   Extension Point:[Bod rozšíření]
   
3. Když případ užití obsahuje větší množství bodů rozšíření, je možné pro jeho vyjádření použít alternativní symbol. Symbolem je obdélník, který je rozdělen nepřerušovanou čarou na dvě části. V horní části je jméno případu užití a ovál, který je tradičním symbolem případu užití. Ve spodní části se nachází seznam bodů rozšíření.
   
4. Případ užití může nyní  “vlastnit” jiný diagram. Příkladem může být stavový diagram popisující průběh vyřizování objednávky u případu užití s názvem zpracování objednávky. Vložené diagramy nejsou určeny pro zákazníka, ale pro rychlé zachycení složitých vazeb mezi různými částmi modelu budou neocenitelné.