Žádná část této publikace nesmí být publikována a šířena žádným způsobem a v žádné podobě bez výslovného svolení autora

OCUP.CZ

UML a OCUP aneb Jak si certifikovat znalosti UML 2 Slávek Rydval

2010

UML a OCUP aneb Jak si certifikovat znalosti UML 2 Slávek Rydval Žádná část této publikace nesmí být publikována a šířena žádným způsobem a v žádné podobě bez výslovného svolení autora. Tato kniha je neprodejná! Souhlas OMG Doslovné citace standardu jsou na základě laskavého a výslovného svolení Object Management Group (OMG). Citace ze standardu UML: UML Superstructure and Infrastructure and Object Constraint Language (OCL). Reprinted with permission. Object Management Group, Inc. © OMG. 2009. Verbatim citations was used thanks to permission given by Object Management Group (OMG). UML Standard: UML Superstructure and Infrastructure and Object Constraint Language (OCL). Reprinted with permission. Object Management Group, Inc. © OMG. 2009 Ostatní text: © 2009-2010 Slávek Rydval (e-mail: [email protected], web: http://www.rydval.cz)

2

OCUP.CZ | http://www.ocup.cz

Obsah Úvod ........................................................................................................................................................ 5 UML ......................................................................................................................................................... 7 Standard UML.................................................................................................................................... 10 Úroveň shody se standardem (Compliance levels) ....................................................................... 11 OCUP – Certifikace znalostí UML 2........................................................................................................ 12 Úrovně znalostí.................................................................................................................................. 12 Základní (Fundamental Level) ....................................................................................................... 12 Střední úroveň (Intermediate Level) ............................................................................................. 13 Pokročilá úroveň (Advanced Level) ............................................................................................... 13 Jak na vlastní zkoušku........................................................................................................................ 13 Certification Search Directory ........................................................................................................... 15 OCUP Fundamental ............................................................................................................................... 16 Jak číst UML standard, část Superstructure ...................................................................................... 16 Miscellaneous basic notation............................................................................................................ 17 Datové typy ................................................................................................................................... 18 Diagram ......................................................................................................................................... 20 Diagramy tříd (Class diagrams).......................................................................................................... 21 Základní koncept (Basic concepts) ................................................................................................ 23 Jmenné prostory (Namespaces) .................................................................................................... 26 Typové prvky (Typed Elements) .................................................................................................... 30 Násobnost (Multiplicities) ............................................................................................................. 31 Určování hodnot (Value Specification).......................................................................................... 33 Omezení (Constraints)................................................................................................................... 35 Specifikace instance (Instance Specification)................................................................................ 37 Klasifikátory (Classifiers)................................................................................................................ 39 Vlastnosti (Features)...................................................................................................................... 41 Operace (Operations).................................................................................................................... 43 Vlastnosti, někdy též atributy (Properties).................................................................................... 45 Asociace (Associations) ................................................................................................................. 48 Třídy (Classes)................................................................................................................................ 54 Generalizace (Generalization) ....................................................................................................... 56 OCUP.CZ | http://www.ocup.cz

3

Balíky (Packages) ........................................................................................................................... 58 Závislosti (Dependencies).............................................................................................................. 63 Rozhraní (Interfaces) ..................................................................................................................... 66 Základy chování (Behavior Basics)..................................................................................................... 70 Způsoby volání chování (balík Communication)............................................................................ 74 Diagram aktivit (Activity Diagram) .................................................................................................... 79 Aktivita (Třída Activity) .................................................................................................................. 80 Parametr aktivity (třída ActivityParameterNode) ......................................................................... 82 Akce (třída Action)......................................................................................................................... 83 Piny (třídy Pin, InputPin a OutputPin) ........................................................................................... 85 Hrany neboli též toky (třídy ControlFlow a ObjectFlow)............................................................... 88 Řídící uzly (Control Nodes) ............................................................................................................ 91 Interakce (Interactions) ..................................................................................................................... 97 Sekvenční diagramy....................................................................................................................... 98 Případy užití (Use Cases) ................................................................................................................. 109 Třída Actor ................................................................................................................................... 110 Třída UseCase .............................................................................................................................. 111 Třída Classifier ............................................................................................................................. 112 Třída Include................................................................................................................................ 113 Třída Extend................................................................................................................................. 113 Třída ExtensionPoint.................................................................................................................... 114 Klíčová slova a stereotypy v UML.................................................................................................... 115 OCUP Intermediate ............................................................................................................................. 116 OCUP Advanced................................................................................................................................... 117 Závěr .................................................................................................................................................... 118 Literatura ............................................................................................................................................. 119 Knihy................................................................................................................................................ 119 Webové odkazy ............................................................................................................................... 119 Ostatní ............................................................................................................................................. 119 Příloha A: Notační plachty ................................................................................................................... 120 Příloha B: Příklady testových otázek ................................................................................................... 121 4

Příloha C: Některé vyřešené otázky z knihy [ocup-cg] ........................................................................ 122 Příloha D: Chyby v knize certguide ...................................................................................................... 126


Úvod Jazyk UML již dokázal proniknout do mnoha firem a společností v České republice a dokonce i mimo oblast IT. Existují oddělení (či jejich části), kde UML umí používat nebo alespoň pasivně číst. Procesním specialistům nedělá problém orientovat se v diagramu aktivit či v případech užití, business konzultanti (či analytici) bez obav používají sekvenční diagramy. Tohle vše vede některé z nich, aby do jazyka UML pronikli hlouběji a hledali odpověď na jednoduchou otázku: používám UML správně? Poměrně dost knih se věnuje výkladu notace UML, tedy popisu pravidel, podle kterých kreslit daný diagram správně, aniž by naznačilo, proč tomu tak jest. Jen velmi málo publikací pak popisuje standard poněkud lidštěji, než je jeho vlastní znění. Když se to tak vezme, vím pouze o jediné1, která se o to snaží, ale pokud mohu soudit, nepovedlo se jí to. V češtině pak dosud neexistovalo o výkladu standardu UML nic. Kniha, kterou vám předkládám, má vyšší ambice než vám přinést pouze podrobnější pohled na UML standard. Její uspořádání totiž odpovídá oblastem, které je nutné znát pro úspěšné zvládnutí certifikační zkoušky, díky níž se stáváte OCUPisty (OCUP je zkratkou pro OMG Certified UML Professional). Certifikační zkoušky jsou celkem tři, přičemž každá zkouší jinou úroveň znalostí UML: základní, střední a pokročilou. Pro každou úroveň kniha nabízí jeden oddíl. Tedy… prozatím pouze pro tu základní. Text vznikal možná ne zcela obvyklým způsobem. Když jsem se sám připravoval na certifikační zkoušku, rozhodl jsem se, že si budu vypisovat vše, co budu považovat za důležité. Během chvíle jsem začal nejen psát větu za větou, ale překreslovat i jednotlivé diagramy z UML standardu. Jelikož jsem vycházel z více zdrojů a díky tomu měl ve svém zápisníku mnoho poznámek a obrázků na přeskáčku, uspořádal jsem je do podoby dokumentu, který vlastně odpovídá tomu, co zde vidíte2. Uvedený postup má velkou výhodu. Tak, jak jsem se postupně učil každou oblast, která je ke zkoušce potřeba, vznikal i text. To tedy znamená, že výklad přechází od základního k podrobnějšímu. Upozorňuji na tomto místě i na jednu záludnost, kterou bohužel odstranit nelze. Často se stává, že k pochopení výkladu oblasti A potřebuje znát oblast B. Ovšem abyste pochopili části B, je třeba mít znalosti oblasti A. S touto cyklickou závislostí se bohužel musíte vypořádat sami. Já to dělám tak, že si přečtu oblast A, pak B a vrátím se A a následně i k B. Může se to zdát zdlouhavé, ale z vlastních zkušeností mohu říct, že se to vyplácí. Mé doporučení tedy je přečíst si nejprve celý výklad a pak se případně vracet k těm částem, které jsou vám nejasné nebo které si chcete připomenout. Je upřímné zde napsat a zopakovat, že předkládaný text je seznámení se standardem UML, nikoliv učebnice diagramů UML. Naopak očekávám, že UML znáte a nějakým způsobem používáte. Pokud tomu tak není, doporučuji se nejprve obrátit někam jinam. Výbornou pomůckou je Destilované UML od Martina Fowlera (u nás vydalo nakladatelství Grada Publishing). Tuto destilace bez obsahu alkoholu vlastně mohu doporučit všem. Často slouží k rychlému připomenutí syntaxe méně často používaných elementů jazyka. 5 1

Jedná se o knihu UML 2 Certification Guide, viz seznam literatury [ocup-cg]. Protože jsem se dosud připravoval pouze na základní úroveň zkoušky, je v knize výklad pouze pro uvedenou úroveň. Rád bych však složil i tu střední (a zřejmě i pokročilou) úroveň. To znamená, že budu chystat poznámky i pro další úroveň (úrovně).

2


Naučit se vše pro úspěšné zvládnutí zkoušky není otázkou jednoho přečtení přes noc (ne, ani pro studenty ekonomky). Naopak je to dlouhodobější orientační běh, při kterém se vám stane, že zabloudíte nebo alespoň chvíli nebudete vědět, zda běžíte správně. Není třeba se toho lekat. Nakonec zjistíte, že jste se dozvěděli i něco navíc. A to není na škodu. Psát o tom, že v textu jsou chyby, je klišé. Přesto bych rád každého čtenáře požádal, aby mě na každou z nich upozornil. Děkuji. Slávek Rydval, Nehvizdy, prosinec 2010

6


UML UML (Unified Modeling Language3) byl navržen pro snadné zachycení skutečností do grafické podoby. Jednotlivé grafické prvky definované standardem UML se sestavují do podoby diagramu podle (většinou) jasně daných pravidel. Skupinu diagramů pak zoveme modelem. Taktéž lze říci, že diagram jako takový je pohled na systém, který máme vytvořit či upravit. Výše zvýrazněné slovo skutečnost je zde použito zcela záměrně. Vždyť takový analytik a návrhář (a především pro ně je UML připraveno) nedělá nic jiného, než že „soustavně, racionálně a kriticky zkoumají skutečnosti. Hledají pravdivé poznání, smysl života (zde lze chápat jako smysl života aplikace/systému) prostředky reflexe, racionální argumentace a diskuse, která vyžaduje určité pojmy. Není to tedy jen akademická disciplina, ale také způsob života, který začíná údivem (Platón) a snaží se s tajemstvím světa a existence nějak vyrovnat.“ (blíže viz Wikipedia, téma Filozofie (http://cs.wikipedia.org/wiki/Filozofie)

Pokud vás předchozí text zaskočil, je to jedině dobře. Vždyť jde vlastně o definici slova filosofie, tedy lásky k vědění a poznávání. Především business analytik totiž kriticky zkoumá skutečnosti, kterými v tomto případě bezesporu jsou požadavky uživatele. Hledá jejich pravdivé poznání, tedy to, co opravdu uživatel chce, nikoliv to, co říká („Jediné správné poznání je rozumem a myslit a být je totéž. Smyslové poznání je zavádějící a jeho výsledkem je pouhé zdání a domněnky. Poznat jevy lze jedině zastavením smyslů, což je možné jen v pojmu (idey, potažmo myšlence).“ [Parmenidés (540 – 470 př. n. l.)]). 3

Často lze vídat spojení „jazyk UML“. Mně se nelíbí, protože slovo jazyk je uvedeno již ve významu zkratky. Proto se používání zmíněného spojení bráním. Máte-li však nepřekonatelnou touhu před UML slovo jazyk vkládat, v duchu si tak čiňte dle libosti.


7

Zmíněný business analytik k tomuto bádání zajisté používá diskusí s uživatelem, při které se snaží racionálně argumentovat. Je zcela zřejmě, že na začátku opravdu k údivu může dojít. Často jej doprovází slova (v tom lepším případě nevyřčená) „Vy jste se snad…“ Dosti ale (pro někoho možná příliš umělého) srovnávání s filozofy a podívejme se na UML z jiného pohledu. K UML se lidé nejčastěji dostávají pomocí diagramů (ačkoliv diagramy nejsou tím, na čem UML stojí). Většinou dostanou obrázek, na kterém je sada prvků nějak pospojovaných a intuitivně dávajících jakýsi smysl. Postupně si všimnou, že typů obrázků může být více, až dospějí k myšlence naučit se pár základních pravidel a začít malovat sami. Diagramy lze rozdělit na strukturální diagramy (Structure diagram) a chovací diagramy4 (Behaviour diagrams). Na obrázku vidíte typy diagramů, o kterých se mluví v UML standardu. Neznamená to však, že nelze použít jiné (příkladem budiž diagram požadavků). Stejně tak prvky používané typicky v jednom druhu diagramu lze použít i v diagramu typu jiného5. class UML diagramy

UML Diagram

Structure Diagram

Behav iour Diagram

Class Diagram

State Machine Diagram

Deploymment Diagram

Activ ity Diagram

Package Diagram

Use Case Diagram

Composite Structure Diagram

Interaction Diagram

Obj ect Diagram

Component Diagram

Sequence Diagram

Communication Diagram

Timing Diagram

Interaction Ov erv iew Diagram

Profile Diagram

8 4

Zřejmě častěji diagramy chování. Mně se ale chovací diagramy líbí mnohem více, a proto to také budu používat. 5 Což bývá některými autory rozporováno.


Velmi důležitou vlastností diagramů, na kterou zapomínají i zkušení uživatelé UML, je, že jakákoliv informace v diagramu může být potlačena (suppressed). Pokud tedy něco v diagramu není zobrazeno, neznamená to, že to tam není! Potlačení může být buďto obecné (např. skryj všechny metody) nebo konkrétní (např. nezobrazovat konkrétní asociace či třídy). Stejně tak pozor na implicitní hodnoty, které se typicky nezobrazují. UML lze podle Martina Fowlera6 používat třemi způsoby: 1. UMLStorm (UML as sketch): Pro náčrtky, kreslení konceptů. Jde o neformální zápis často produkovaný na schůzkách a psaný na tabuli či papír. Pravidla definovaná UML standardem nejsou až tak důležitá na rozdíl od zachycované myšlenky. 2. UML pro podrobný návrh (UML as a blueprint): používá se pro detailní návrh systému nebo jedné jeho části. UML pravidla se dodržují, ale nevyužívají se všechny. Cílem je navrhnout rozhraní, vnitřky systémů si již pak každý řeší sám. 3. UML jako programovací jazyk: UML je překládáno do spustitelného tvaru. V dnešní době se téměř nepoužívá. Martin Fowler také uvádí jedno důležité doporučení: „Buďte připraveni porušit pravidla UML kdykoliv vám to pomůže zlepšit komunikaci. Nemá cenu kreslit diagramy, kterým nikdo nerozumí.“ Já s ním naprosto souhlasím, ale dodávám jednu důležitou věc (a pokud budete dělat certifikační zkoušku, tak životně důležitou): vždy mějte na paměti, která pravidla porušujete. Pravidla, která porušujeme či dodržujeme, je možné rozdělit do dvou skupin: předepisující a popisná. Předepisující (nařizující) pravidla (prescriptive rules) jsou dány oficiálně, v našem případě je definuje OMG a jejich znění je v UML standardu. Popisná pravidla (descriptive rules) jsou pravidla, která si nad rámec standardu můžete zavést. Jsou to typicky pravidla, která vyplynou z dlouhodobého používání nějaké metodiky. Popisná pravidla mají schopnost potlačit či předefinovat pravidla předepisující (jinými slovy standard si můžeme upravit popisnými pravidly). UML má za sebou (z pohledu informačních technologií) poměrně dlouhou historii. Pro vás, kdo chcete skládat zkoušku, je důležitých jen pár bodů: • • •

•

6

UML vzniklo jako potřeba mít jednotný jazyk pro grafické zachycování objektově orientovaného návrhu. Verze 2.x je v mnoha aspektech odlišná od 1.x Všechny tři úrovně zkoušky OCUP testují znalosti UML 2.x. Pokud jste s UML 1.x dosud nepracovali, je to pro vás lepší, pokud ano, musíte si dávat větší pozor (na některé rozdíly upozorňuji). Je vcelku jedno, kterou podverzi UML 2 znáte. Zkoušky se zaměřují na znalosti obecnější. (Text této knihy pro úroveň Fundamental byl psán podle verze 2.2, text úrovně Intermediate podle verze 2.3).

Stále se obracím k jeho knize Destilované UML.


9

OCUP Fundamental OCUP Fundamental je základní úroveň znalostí standardu UML. Otázky se týkají pouze části Superstructure standardu. Oficiální informace o zkoušce najdete na stránkách OMG: http://www.omg.org/uml-certification/index.htm • • • • • •

Číslo zkoušky: OMG-OCUP-100 Délka trvání: 90 minut Počet otázek: 80 Minimální množství správně zodpovězených pro úspěšné složení: 46 (tj. 57,5 %) Poplatek: 200 USD Předpoklady: žádné

Ze Superstruktury se zkouší tyto oblasti: Oblast Zastoupení Class diagram (Basic) 30 % Activity diagram (Basic) 20 % Interaction diagram (Basic) 20 % Use Case diagram (Basic) 20 % Miscellaneous basic notation 10 % Celkem 100 %

V následujícím textu popisuji každou část zvlášť. Před tím se však ještě podívejme na poměrně důležitou kapitolu.

Jak číst UML standard, část Superstructure Bylo uvedeno, že základní úroveň znalosti standardu UML je uvedena v části Superstructure. Podívejme se tedy na to, jak s ní pracovat. Pokud dokument ve formátu PDF otevřeme, můžeme se zhrozit téměř osmi set stran. Není však třeba podléhat svodům paniky. Pro základní úroveň si vystačíme s menším množstvím (odhadem tak čtvrtinou, možná ani to ne). První, úvodní kapitoly jsou takové to obecné povídání, které si stejně asi přečtete ze zvědavosti sami. Následují dvě rozsáhlé části (Part I a Part II) a dvě menší části (Part III a Part IV). Z každé nás bude zajímat něco. Jak se v nich ale orientovat?

16

Řekli jsme, že UML diagramy můžeme rozdělit do dvou skupin: strukturální a chovací. Tomu odpovídají i první dvě části Superstruktury. Ze strukturální nám stačí pouze část Classes, z chovací pak potřebujeme Activities, Composite Structures a Use Cases. Pro to ostatní pak ze třetí části je vhodné znát kapitolu 17.4 PrimitiveTypes. Konečně ze čtvrté části, což jsou vlastně přílohy, doporučuji tu první pod názvem Diagrams a nakonec prolétnout druhou a třetí (Keywords a Standard Stereotypes). Pojďme si nyní předvést, jak se chovat k prvním dvěma částem. Pokud programujete v nějakém objektovém jazyce, jistě víte, že funkcionality (implementované typicky v metodách tříd) jsou dodávány OCUP.CZ | http://www.ocup.cz

v oddělených programových celcích8 (jednotky, balíky, knihovny). UML jakožto jeden z mnoha objektových jazyků je na tom naprosto stejně. Superstruktura vlastně není nic jiného než knihovna balíků, tříd a dalších prvků, které uživatel tohoto jazyka používá. Vemte si libovolný UML diagram. Každý prvek, který tam vidíte, je třída. V diagramu tříd se používá UML třída Class či Association nebo Generalization. V případech užití zase používáme třídy Actor a UseCase. Superstruktura pak říká nejen, jak tyto prvky zakreslit, ale jaké v nich a mezi nimi platí pravidla. Dozvíme se např., že generalizaci nemůžeme použít mezi třídami cyklicky. Uvidíme, že prvek uvnitř balíku může mít pouze dvě ze čtyř definovaných hodnot výčtového typu VisibilityKind (viditelnost) a mnoho dalšího. Otevřete si tedy Superstrukturu a podívejte se na kapitolu 7 nazvanou Classes. První kapitola nazvaná Overview je základní seznámení s danou částí. Ačkoliv, nebo spíše právě proto, že to je seznámení, měli byste si ji řádně pročíst. Zvláště u některých oblastí obsahuje zásadní informace. Na ně navazuje kapitola Abstract Syntax. Zde je nejprve uveden diagram balíků, který nás informuje nejen o složení dané části, ale i to, jak jsou tyto balíky vzájemně závislé. Poté následují diagramy tříd z jednotlivých balíků. Ty jsou hodně důležité pro to, abyste věděli, v jakých vztazích jednotlivé třídy mezi sebou jsou. Nakonec je uveden popis jednotlivých tříd včetně sémantiky, pravidel, notace a případných příkladů. Tento způsob platí pro všechny kapitoly v částech I a II. Při čtení se vám bude často stávat, že některé věci nepochopíte. Nic si z toho nedělejte. Na to, abyste byli schopni pochopit např. diagram balíků, musíte se naučit, co to balík je, co se děje při importu a spojení.

Miscellaneous basic notation Poměr otázek v testu: 10 % Oblasti: • •

•

Primitivní datové typy definované v UML Základní notace modelování v UML: o Diagramy – protože diagramy nejsou to hlavní, co nám UML standard předepisuje, tak pro potřeby první úrovně OCUPu je třeba znát pouze základ pro diagram (tj. hlavičku a že existuje oblast pro prvky diagramu). Není třeba se nazpaměť učit, které diagramy jsou které, ale stačí je rozpoznat pouze pasivně dle jména, a co přibližně zobrazují. Výjimkou jsou takové diagramy (resp. prvky diagramů), které jsou přímo tématem této zkoušky. o Stereotypy – Chce to znát základní myšlenku stereotypů. Doporučuji také podívat se ještě na klíčová slova a hlavně na rozdíl mezi nimi a stereotypy. Často se to totiž zaměňuje a chybuje se v tom. o Slovníček pojmů – je třeba znát definice základních pojmů i z praktického hlediska. Zatím jsem bohužel nenašel, které jsou ty základní. Rozhodně stojí za to vědět rozdíl mezi modelem a diagramem. Základní notace chování UML – těžko říct, co si pod tím představit. Snad jen to, že jste alespoň dva diagramy za život nakreslili.

8

Ono tohle vlastně nemusí nutně platit pouze pro objektové jazyky. Vezměme si např. procedurální SQL (typicky PL/SQL od Oracle): i tam jsou balíky funkcí, do kterých se vkládají funkce, které spolu souvisí.


17

Jmenné prostory (Namespaces) class Namespaces diagram of the Kernel package

«enumeration» VisibilityKind

Element

public private protected package

NamedElement + + +

name: Stri ng [0..1] /qual ifiedName: String [0..1] visibi lity: Visibil ityKind [0..1]

+/ownedMember * {readOnly, union, subsets member, subsets ownedElement}

+/member * {readOnl y, union} Relationship DirectedRelationship * {readOnly, subsets member} +/importedMember

0..1 {readOnl y, uni on, subsets owner} +/namespace

* Namespace

PackageableElement

+importedElement 1 {subsets target}

* +importi ngNamespace 1 {subsets source, subsets owner}

1 ElementImport +elementImport * {subsets ownedElement} +packageImport PackageImport

+importi ngNamespace 1 {subsets source, subset owner}

* {subsets ownedElement}

*

+importedPackage 1 {subsets target} Package

Pojmenovaný element Pojmenovaný element (abstraktní třída NamedElement) je prvek, který může mít jméno a definuje viditelnost. Jméno, stejně jako viditelnost, je volitelná. Jméno je používáno pro identifikaci v rámci jmenného prostoru. Atribut qualifiedName je poskládaný výsledek jmen všech vnořených jmenných prostorů (např.: Bankovní produkty::Účty::Běžný účet::Výpis z běžného účtu).

26


class Příklad: Bankov nictv í Bankov ní produkty

Účty

Běžný účet

Výpis z běžného účtu

Viditelnost Viditelnost je výčtový typ nazvaný VisibilityKind. class Namespaces ...

«enumeration» VisibilityKind public private protected package

Notace: viditelnost je určena takto: • • • •

+ veřejný (public) - soukromý (private) # chráněný (protected) ~ balík (package)

Jmenný prostor Jmenný prostor (třída Namespace) je abstraktní třída obsahující množinu pojmenovaných prvků (NamedElement), které mohou být dle jména jednoznačně identifikovány (jinými slovy nelze mít v jednom jmenném prostoru dva pojmenované elementy týmž jménem). Jeden element může být vlastněn nanejvýše jedním jmenným prostorem. Namespace může vlastnit omezení (constraints). Tato omezení mohou být uplatněna na jmenný

prostor nebo na elementy ve jmenném prostoru.

27

Jmenný prostor má možnost importovat jednotlivé prvky z balíků (Package) nebo všechny prvky balíku, čímž umožňuje odkazovat na ně bez nutnosti zadávat kvalifikované jméno v importujícím jmen-


ném prostoru. Rozlišovat je nutné pouze v případě nejasností (viz dále třídy ElementImport a PackageImport). Notace: není, definují ji až potomci. Třída PackageableElement Prvek typu PackageableElement je pojmenovaný element, který může patřit přímo do nějakého jmenného prostoru (např. třída oproti např. operaci, která nemůže). Atribut visibility se stává povinným. Třída Package Třída Package (balík) je používán k seskupování prvků a poskytuje pro ně jmenný prostor. Balík může obsahovat další balíky. Balík může vlastnit pouze prvky odvozené od PackageableElement. Díky předkovi (třída Namespace) balík může importovat jednotlivé prvky jiných balíků nebo celý balík. Navíc může balík být sloučen (merge) s jiným balíkem. Pokud element, který je vlastněn balíkem, má viditelnost (visiblity), pak je tato nastavena pouze na public nebo private. Notace: Jsou tři možnosti, jak balík zakreslit. Pokaždé se jedná o obdélník s ouškem nahoře. V prvním případě se nezobrazují žádní členové balíku. V druhém jsou členové zobrazeni uvnitř oblasti balíku. V třetím jsou pak spojeni vztahem. pkg Příklad: Notace třídy Package Balík 1

Balík 2

Balík 3

Třída 2.1

Třída 2.2 Třída 3.1

Třída 3.2

Třídy ElementImport a PackageImport ElementImport je orientovaný vztah mezi importujícím jmenným prostorem a PackageableElement z jiného balíku a umožňuje, aby tento element mohl být odkazován pouze jménem bez kvalifikace. Pomocí atributu visibility lze určit, zda tento již importovaný element může být dále importován. Atributem alias: string [0..1] můžeme element přejmenovat. Jméno nesmí být v rozporu s jiným elementem v importujícím jmenném prostoru. 28

Pokud je visibility nastavena na public, pak importovaný element je viditelný i mimo importující balík (lze jej dále importovat do dalšího balíku).


Pokud je visibility nastavena na private, pak importovaný element je viditelné pouze v rámci importujícího balíku. Importovaný element musí mít viditelnost public nebo viditelnost nesmí být přiřazena (což mi přijde divné, neboť PackageableElement má visibility povinný, ovšem výchozí hodnota je false, což je ještě podivnější, neboť visibility je typu VisibilityKind). V případě, že v importujícím jmenném seznamu již prvek se stejným názvem je, pak k importu nedojde a importující jmenný prostor musí i nadále používat celé kvalifikované jméno (lze obejít pomocí aliasu). Notace: přerušovaná čára s otevřenou šipkou z importujícího jmenného prostoru do importovaného balíku. Dále je u šipky zobrazeno klíčové slovo «import», pokud je visibility public, nebo «access», pokud je visibility private. Pokud má element definovaný alias, pak tento může být zobrazen za nebo pod klíčovým slovem «import». class Příklad: ElementImport Datov é typy Framew ork «import»

«access»

Tv ary

«import» double Kruh

-

«datatype» string

«datatype» integer

«datatype» real

poloměr: double

PackageImport je orientovaný vztah umožňující používat nekvalifikovaná jména (tj. nepoužívat odvozený atribut NamedElement.qualifiedName) pro odkazování se na členy balíku z jiného pojmenovaného prostoru.

Povinný atribut visibility: VisibilityKind určuje viditelnost importovaných prvků (PackageableElements) z importovaného jmenného prostoru. Jsou povoleny pouze hodnoty public (výchozí hodnota) a private. Pokud je visibility public, pak importované elementy jsou viditelné mimo importující balík. Pokud je visibility private, pak importované elementy jsou viditelné pouze v rámci importujícího balíku. PackageImport si lze představit jako ElementImport na všechny prvky typu PackageableElement z importovaného balíku.


29

Generalizace (Generalization) class Classifiers diagram of the Kernel package Element

PackageableElement

Namespace

NamedElement

Type

+/inheritedMember * {readOnly, subsets member} Relationship

RedefinableElement

DirectedRelationship

+ * *

+/redefinedElement * {union, readOnly}

+general

Classifier

+/redefinedContext

Property

* {union, readOnly, subsets feature}

Generalization

* {union, readOnly}

* +specific 1 {subsets source, subsets owner}

* StructuralFeature +/attribute

1 {subsets target}

isAbstract: Boolean

+generalization * {subsets ownedElement}

+redefinedClassifier * {subsets redefinedElement}

+classifier 0..1 {subsets redefinitionContext} *

* +/general *

Třída Generalization Generalizace je vztah mezi obecným a specializovaným klasifikátorem. Specializovaný klasifikátor dodává více vlastností a operací nebo je mění. Instance specializované třídy je také nepřímá instance obecné třídy. Generalizace odkazuje specializovanou třídu na obecnou. Generalizace je vlastněna specializovanou třídou. Generalizace resp. specializace tvoří hierarchickou strukturu. Notace class Příklad: Nota...

Strom

ListnatýStrom

56

Pro více specializovaných tříd můžeme použít dva druhy notace. Oddělený styl (separate target style) a sdílený styl (shared target style).


class Příklad: Sdílený styl

class Příklad: Oddělený styl

Auto

Auto

OsobníAuto

NákladníAuto

OsobníAuto

NákladníAuto

Sdílený styl je mimo jiné využíván při použití generalizační množina (ta ale není součástí zkoušky OCUP Fundamental). Třída RedefinableElement Předefinování (overwriting) je řízen pomocí abstraktní třídy RedefinableElement. Všechny třídy metamodelu, které jsou potomkem třídy RedefinableElement, mohou být v rámci generalizace předefinovány. Přepisující elementy si ukládají odkaz na přepisovaný element. Notaci si definují potomci. Pro atribut, který se předefinovává, se používá zápis pomoci řetězce vlastností (property string): {redefines <property>}.

57


act Příklad: Parametry aktiv ity

Založ účet [Typ zákazníka = Fyzická osoba]

Založ Osobní účet

Osobní účet

Úč et : Bankovní účet

Typ zákazníka : Typ Zákazníka

[Typ zákazníka = Právnická osoba]

Založ Firemní účet

Firemní účet

Jakmile je aktivita ukončována, objektový token je na všech výstupních parametrech. Pokud odpovídající objekt neexistuje, vytvoří se tzv. nulový token (null token nebo také zero token), který může být použit pro libovolný objektový typ. Akce (třída Action) Akce (třída Action) je abstraktní třída, přičemž UML definuje i konkrétní specializace: • • • •

Volání chování (např. jiné aktivity) Volání operace Vyslání a přijmutí signálu Vytvoření, smazání a změna objektu

Příkladem může být CallBehaviorAction, dalším např. CreateObjectAction. Jejich znalost ale spadá do zkoušky úrovně Intermediate. Akce jako taková je dále nedělitelná. Na druhou stranu je naprosto běžné, že akce může volat jinou aktivitu, která se skládá z jiných akcí. Někdy dochází k nepochopení, co to znamená nedělitelnost akce. Ta se totiž vztahuje pro daný model, který vytváříme. Např. pokud chceme modelovat běžný chod domácnosti, může být jako nedělitelná akce vysávání. Pokud jsme ovšem výrobci vysavačů, pak to pro nás znamená naopak složitá aktivita, ke které ve vysavači dochází a je spuštěna tlačítkem vysavače. Proto se vždy ptejte: je to, co potřebuji modelovat, v daném kontextu nedělitelné, tj. je to černá skříňka, u které mě nezajímá, co se děje uvnitř? Následující diagram je v balíku Actions::BasicActions:

83


class Basic actions Element Kernel::NamedElement

Namespace RedefinableElement Type

context Action *

0..1 {readOnly}

inputValue

OpaqueAction body: String language: String

Kernel::Classifier

* {subsets innput}

0..1

Pin InputPin

outputValue 0..1

* {subsets output}

Pin OutputPin

K prostudování také doporučuji již uvedený diagram Fundamental Nodes. BasicActions definuje Action jako přímého potomka třídy NamedElements, kdežto BasicActivities mezi ně ještě vkládá ActivityNode. Akce může mít vstupní a výstupní piny (viz dále). Stejně tak akce může mít definován kontext. Tok tokenů v akci act Příklad: Vstupní a v ýstupní hrany

K A L B

X

M C

N

Akce nebude spuštěna, dokud: 84

• • •

Nebudou splněny všechny podmínky pro spuštění (pre-conditions). Nepřiputuje token ze všech vstupních hran. Všechny vstupní piny mají token nesoucí objekt.

Token putuje z akce do další, pokud: OCUP.CZ | http://www.ocup.cz

• • • •

Token je dostupný na všech výstupních hranách. Objekt je dostupný na všech výstupních pinech. Cílová akce je připravena token přijmout. Pravidla umožní hraně token přijmout.

Notace Použití notace akce je nepovinné. Namísto ní lze použít textový zápis. Akce je zobrazována jako obdélník se zakulacenými rohy. Piny (třídy Pin, InputPin a OutputPin) Následující diagram je v balíku Actions::BasicActions: class Basic pins NamedElement

Element

Kernel::TypedElement

Kernel::MultiplicityElement

Pin

OutputPin +/output

InputPin

* {ordered} {readOnly, subsets ownedElement}

+/input

* {ordered} {readOnly, subsets ownedElement} ValuePin 0..1

0..1

0..1 NamedElement Action

+value

1

PackageableElement Kernel::ValueSpecification

Pin je typový a násobný element, který poskytuje vstupní hodnoty (objekty) akci a volanému výsle-

dek akce. Piny akcí jsou setříděné. Pin je mj. potomek ObjectNode (viz diagram Nodes). Pin je vždy vlastněn akcí. Pin je abstraktní třída. Její specializací jsou InputPin, OutputPin a ValuePin. Akce může mít libovolné množství pinů.

Akce nemůže býti spuštěna, pokud vstupní pin (třída InputPin) nemá alespoň tolik hodnot, kolik nařizuje dolní hranice násobnosti pinu. Horní hranice násobnosti pinu určuje maximální počet hodnot, které dokáže akce zpracovat. Akce nemůže býti dokončena, pokud výstupní pin (třída OutputPin) má méně hodnot než je dolní mezní hranice. Akce nemůže vložit do pinu více hodnot, než je horní hranice násobnosti pinu. OCUP.CZ | http://www.ocup.cz

85

• •

Jistě najdete i nějakou špatnou, např. . Jelikož je třída Interaction specializací chování (třída Behavior), je možné jej dále specializovat a předefinovat. Specializace znamená přidání dalších sekvencí do zmíněných množin. Notace Interakce se zobrazuje jako obdélník. V levém horním rohu je pak obdélníku se skoseným rohem klíčové slovo sd (ačkoliv zde standard mluví o klíčovém slově, v kapitole klíčová slova jej neuvádí) je následované názvem interakce. Poté jsou parametry interakce. Notace vnitřku se pak odráží od digramu, který chceme zobrazovat: sekvenční diagram, komunikační diagram, diagram interakcí nebo časový diagram. Pozn: sjednotit názvy diagramů. Lokální atribut (který lze použít např. jako počítadlo průchodů cyklem) se zobrazuje v levém horním rohu diagramu. sd Příklad: Lokální parametr canEnd: Boolean

X

Y

canEnd = askSeeress()

103


Výměna zpráv (Třída Message) class Messages Element Kernel::NamedElement Behavior InteractionFragment Interaction +interaction

1 {subsets namespace}

* +message {subsets ownedMember} Message +

+sendEvent

MessageEnd

messageSort: MessageSort 0..1

«eAttribute» + /messageKind: MessageKind

0..1 +receiveEvent

0..1

0..1

+message 0..1

+connector

*

*

0..1

+/signature 0..1 {readOnly}

0..2

MessageOccurenceSpecification Element

InternalStructures:: Connector

Dependencies::NamedElement

InteractionFragment * {ordered} {subsets ownedElement}

OccurenceSpecification

+argument

*

PackageableElement TypedElement

+event

1

Kernel::ValueSpecification PackageableElement Communications::Event «enumeration» MessageSort

«enumeration» MessageKind

synchCall asynchCall asynchSignal createMessage deleteMessage reply

104

complete lost found unknown

Výměna zpráv mezi časovými osami znamená, že se v účastnícím se elementu spustí chování. Běh (execution occurence) tohoto chování je znázorněn podélným obdélníkem na časové ose. Začátek a konec běhu chování je dáno výskytem událostí (event occurences). Jinými slovy odeslání zprávy způsobí začátek běhu chování a přijmutí návratové zprávy značí konec běhu chování. Přenesení zprávy je zobrazeno šipkou. OCUP.CZ | http://www.ocup.cz

Notace Základní notace případu užití je ovál s název případu užití uvnitř oválu nebo pod ním (na rozdíl od účastníka nelze dát název nad ovál). Druhá možnost zápisu je jako klasifikátor, tedy v obdélníku, kde je zobrazen ovál v pravém horním rohu. uc Příklad: Notace případu užití Use Case Use Case

Pokud je v diagramu uveden systém, případ užití se zakresluje do jeho hranic. Neznamená to však automaticky, že systém tento případ užití vlastní. Následující příklad ukazuje případy užití v balíku. uc Příklad: Notace případu užití (balík) Bankomat

Vyber peníze

Maj itel platební karty

Dobij si předplacenou kartu

Příklad notace rozšiřujících bodů: uc Příklad: Notace případu užití (body rozšíření) Use Case Use Case extension points: Rozšiřuj ící bod 3 Rozšiřuj ící bod 2 Rozšiřuj ící bod 1

112

extension points Rozšiřující bod 1 Rozšiřující bod 2 Rozšiřující bod 3

Třída Classifier Rozšiřuje klasifikátor o možnost vlastnit případy užití.


Notace uc Příklad: Classifier

Banka

Zruš účet

Třída Include Vztah include se používá, pokud chceme říct, že vkládající případ užití obsahuje chování, které je definované v jiném – vkládaném – případu užití. Jedná se také o potomka NamedElement, takže vztah může mít jméno v kontextu vlastněného případu užití. Vkládající případ užití závisí na hodnotě výstupu vkládaného případu užití. Záměrem je, aby vkládaný případ užití poskytoval chování společné pro více vkládajících případů užití. Lze to přirovnat volání nějaké jiné funkce. Vkladádající případ užití zná ty vkládané. Naopak to nemusí platit a většinou neplatí. uc Příklad: Include

Vybrat peníze

«include»

Vložení PIN

Třída Extend Vztah extent říká, že jeden případ užití (rozšiřující), může rozšířit chování jiného případu užití (rozšiřovaný). K rozšíření dochází v tzv. bodech rozšíření (třída ExtensionPoint), které specifikuje rozšiřovaný případ užití. Rozšiřující případ užití ve skutečnost sám o sobě nemá význam (a tedy nemá smysl k němu asociovat účastníka). Jeden rozšiřující případ užití může rozšiřovat více rozšiřovaných případů užití. Stejně tak jeden rozšiřující případ užití může rozšiřovat jiný rozšiřující případ. Ten je pak rozšiřující i rozšiřovaný zároveň. Případ užití může mít libovolný počet rozšiřujících bodů. Pokud má k rozšíření dojít jen za určité podmínky, je možné tuto definovat. OCUP.CZ | http://www.ocup.cz

113

Závěr Dostali jste se téměř na konec knihy. Dál již následují odkazy na další literaturu a několik příloh. Pokud vám kniha pomohla, budu jedině rád. Je mi jasné (a psal jsem to už v úvodu), že text nelze pochopit na poprvé. Pokud budete potřebovat další pomoc, máte několik možností: • • • •

Podívat se do nějaké další literatury (viz další kapitola). Zeptat se v nějaké odborné konferenci (opět viz další kapitola). Zkuste mi napsat, má e-mailová adresa je [email protected]. Já se budu snažit v rozumné době odpovědět. Můžete využít mé nabídky školení přímo u vás. Podrobné a aktuální informace najdete na stránce: http://ocup.ocup.cz/p/skoleni.html.

118


Literatura Následuje seznam literatury, kde naleznete další informace jednak o UML a jednak o zkoušce OCUP.

Knihy

[DestilovaneUML] Martin Fowler: Destilované UML, Grada Publishing, a.s., 2009, 176 stran, ISBN: 978-80-247-2062-3

[UML2aUP] Jim Arlow, Ila Neustadt: UML2 a unifikovaný proces vývoje aplikací, Computer Press, 2007, 568 stran, ISBN: 978-80-251-1503-9.

[ocup-cg] Tim Weilkiens, Bernd Oestereich:UML2 Certification Guide Fundamental&Intermediate, Morgan Kaufmann, 2006, 320 stran, ISBN: 978-0-12-373585-8. V příloze C najdete odpovědi na některé otázky z knihy, v příloze D pak seznam chyb, které jsem v knize našel.

Webové odkazy •

http://www.omg.org/uml

•

[Wikipedia — Philosophy] Filosofie, http://cs.wikipedia.org/wiki/Filozofie, 8. 1. 2008.

Ostatní • •

UML Forum: Diskusní skupina na Googlu. http://www.uml-forum.com/ resp. přímý odkaz: http://groups.google.com/group/UMLforum?hl=en&pli=1 Pokud máte profil na serveru LinkedIn (http://www.linkedin.com), pak se můžete připojit ke skupinám UML Lovers a UML Professionals.

119


Žádná část této publikace nesmí být publikována a šířena žádným způsobem a v žádné podobě bez výslovného svolení autora

Recommend Documents