Unified Modeling Language (UML)

Unified Modeling Language (UML)

UML

Unified Modeling Language (UML) je univerzální průmyslově standardizovaná grafická notace jazyka, která nedefinuje žádný druh metodiky modelování, ale slouží především pro specifikaci, vizualizaci, konstrukci a dokumentaci prvků softwarového systému.

leden ’07

Střední průmyslová škola Bruntál

2

UML

Žádným způsobem nedefinuje způsob, myšlenku a metodologii vývoje software, je pouze vyjadřovacím prostředkem. První průmyslový standard tohoto jazyka byl představen v roce 1997 společností OMG (Object Management Group). Princip UML je postaven na objektovém základu, zahrnuje vlastnosti objektů a tříd. Více informací na http://www.uml.org

leden ’07


3

UML – proč zrovna UML?

Existuje relativně velké množství podobných jazyků. Žádný z nich však není schopen komplexně popsat všechny pracovní postupy softwarového procesu. Výhodou je, že zápis diagramů v UML není složitý a tím je srozumitelný pro klienta. Snižuje náklady na komunikaci mezi řešiteli projektu.

leden ’07


4

UML – co definuje?

1.

Sémantický meta-model, který je základní platformou pro definice sémantiky jednotlivých nástrojů UML. (sémantika). Vztah mezi slovy a jejich významy.

2.

Množinu základních modelovacích konceptů, které charakterizují základní přístup a principy používaní nástrojů UML. Jsou to například objekt, třída, asociace.

3.

Grafickou notaci pro použití základních modelovacích konceptů.

leden ’07


5

UML – struktura

1.

Stavební bloky. Ty jsou základním komponentou modelu. Obsahují tři základní prvky a to předměty, vztahy a diagrami.

2.

Obecná mechanika. Ta obsahuje čtyři základní mechanismy: specifikace, ozdoby, podskupiny, mechanismy rozšiřitelnosti, tyto instance pak popisují strategie modelování objektů.

3.

Architektura. Je organizační strukturou systému, včetně jeho rozkladu na součásti, jeho propojitelností, jeho interakcí, mechanismů a směrných zásad, která pronikají do návrhu systému.

leden ’07


6

UML – pohledy

1.

Logický pohled. Je zaměřen na logické vazby, funkce systému a slovník.

2.

Pohled procesů. Procesně orientovaný pohled pokrývá výkon systému, škálovatelnost a propustnost.

3.

Pohled implementace. Slouží k objasnění způsobu montáže systému a správě konfigurace.

4.

Pohled nasazení. Určuje způsob distribuce systému, metody jeho doručení k uživateli a případné instalace.

5.

Souhrn všech pohledů je sjednocením v pohled případu užití, kde se popisují požadavky uživatele.

leden ’07


7

UML – vztah k (R)UP

Z našeho pohledu se budeme snažit, ke každému z pracovních postupů metodiky UP přiřadit nezbytné diagramy z jazyka UML. Současně si při této příležitosti objasníme metodologie, které pro daný pracovní postup UP zavádí.

leden ’07


8

UML – case nástroje

Case nástroje pro tvorbu UML diagramů: • Visual Paradigm for UML http://www.visual-paradigm.com/product/vpuml/

•

Poseidon for UML

http://www.gentleware.com/ce.html

•

Rational Rose

http://www-128.ibm.com/developerworks/rational/products/rose

•

Microsoft Office Visio

http://office.microsoft.com/cs-cz/visio/FX100487861029.aspx

leden ’07


9

UML – Požadavky

Požadavky

leden ’07


10

UML – Požadavky

Specifikují to, co se má v systému implementovat. Definují to, co se má dělat, neřeší ale, jak se to má dělat.

leden ’07


11

UML – Požadavky

Požadavky na systém jsou stěžejním prvkem metodologie UP. Jejich důležitost je viditelná na pracovních postupech iterace, kde se všechny další postupy přímo odvíjí právě z požadavků. Nedostatečné nebo úplné nevypracování se stává častou příčinou neúspěchu při nasazení softwaru. Nejvíce vykonaných prací je u požadavků prováděna ve fázi začátku a rozpracování.

leden ’07


12

UML – Požadavky

Požadavky na systém se zachycují dvěma způsoby, prvním z nich je vypracování funkčních a nefunkčních požadavků a druhý je zhotovení případu užití a zjištění účastníků systému. Kombinací obou se otevře pohled na systém, který umožňuje sledovat jednotlivé komponenty systému tak i souvislosti a větší funkční celky.

leden ’07


13

UML – aktivity

Během požadavků provádíme následující aktivity (tvoříme): • • • •

leden ’07

Funkční a nefunkční požadavky Případy užití Detaily případu užití Slovníček pojmů


14

UML – funkční a nefunkční požadavky

•

Funkční požadavky definují to co má systém dělat, jak se má chovat, co má evidovat a další. Výčet funkčních požadavků je dán konkrétním systémem

•

Nefunkční požadavky definují omezující podmínky systému. Ty většinou vyplívají z prostředí, ve kterém bude systém používán, rychlosti systému, nebo například z hardwarových omezení. Požadavky se formulují jednoznačně, stručně a především jednoduše.

leden ’07


15

UML – funkční a nefunkční požadavky

Důležité je dokázat zachytit všechny požadavky. Toho je docíleno konzultacemi se zadavatelem. Konzultant se musí snažit, díky správně formulovaným otázkám, získat od zadavatele pokud možno všechny relevantní požadavky. Jak již bylo uvedeno, tak i zachycování požadavků probíhá v iteracích. Může tak dojít k situaci, kdy zadavatel a analytik v počátku nezachytí všechno co má být v systému implementováno. Tento stav pak bývá příčinou možného zdržení projektu. Je evidentní, že nejdůležitější aktivitou v této části vývoje je samotné vyhledání požadavků.

leden ’07


16

UML – formulace požadavků

Struktura požadavků je tedy následující: <systém> bude • • • •

- jednoznačný identifikátor. Například F1, N1 apod. <systém> - nahradíme názvem systému. bude – je klíčové slovo, které musí obsahovat každý správně formulovaný požadavek. - jednoznačný popis toho co má systém dělat. Popis neobsahuje žádnou podmínku. Nepokračuje souvětím.

leden ’07


17

UML – formulace požadavků

Uvědomme si proč kladem takový důraz na samotnou formulaci požadavků. Ten, kdo bude po Vás zpracované požadavky číst nesmí mít po jejich přečtení v ideálním případě žádnou otázku typu „Jak si to myslel“. Nepokoušejte se při zpracování nabízet analytikovy nějaká východiska či nějaká řešení. Analytik očekává od funkčních a nefunkčních požadavků první pohled na systém.

leden ’07


18

UML – příklad funkčních požadavků (1.)

Představme systém.

si

hypotetické

zadání

pro

redakční

F1:Na redakční server se budou moci přihlašovat redaktoři a šéfredaktor. F2:Systém bude rozeznávat, kdo se přihlásil. F3:Šéfredaktor a redaktoři se budou moci odhlašovat ze systému. F4:Redaktor bude moci vkládat a editovat své příspěvky. F5:Šéfredaktor bude mít rozšířenou pravomoc o mazání, editování všech příspěvků, přidávání a blokování redaktorů. F6:Na první straně stránek budou aktuální novinky. F7:Příspěvky budou seřazeny po deseti podle data vložení. leden ’07


19

UML – příklad funkčních požadavků (2.)

F8:Příspěvky budou dále rozděleny do kategorií. F9:Na hlavní stranu budou mít přístup všichni návštěvníci po zadání URL do prohlížeče. F10:Návštěvník bude moci zobrazit detail příspěvku a zde se mu ukáže celá recenze. F11:Návštěvníci budou moci reagovat na příspěvky pomocí diskusního fóra. F12:Šéfredaktor bude mít rozšířenou pravomoc o mazání, editování všech příspěvků, přidávání a blokování redaktorů. F13:Návštěvníci budou moci vyhledávat články podle názvu článku, autora.

leden ’07


20

UML – příklad nefunkčních požadavků

N1:Systém bude vytvořen v PHP. N2:Systém bude pro ukládání dat používat MySQL N3:Výstup systému bude vytvořen v Smarty template engine. N4:Systém bude nasázen v XHTML. N5:Systém bude kódován v UTF-8. N6:Systém bude odlazen na www.neco.cz.

leden ’07


21

UML – přirozené otázky k funkčním požadavkům

Zkuste se na funkční požadavky podívat očima analytika. Zamyslete se například nad těmito konkrétním případy: F6:Na první straně stránek budou aktuální novinky. F10:Návštěvník bude moci zobrazit detail příspěvku a zde se mu ukáže celá recenze. F11:Návštěvníci budou moci reagovat na příspěvky pomocí diskusního fóra.

leden ’07


22

UML – přirozené reakce analytika na funkční požadavky

Nejdříve bude pravděpodobně následovat lehké zděšení, u slabších povah neurotický záchvat. Rozumný analytik se začne ptát: • Co to je diskusní fórum? • Kdo k němu má přístup? (přihlášený návštěvník?) • Co se smí do diskusního fóra vkládat? • Co je to detail příspěvku, co si pod tím představujete? • Jak má vypadat detail příspěvku? • Co je to aktuální novinka, kdo to definuje? • ……………………………………… leden ’07


23

UML – přirozené odpovědi na funkční požadavky

Ještě úvodem, je třeba si povšimnou lehkou nevyváženost mezi F6 a F11. F11 je velmi obecný. Abychom předešli podobnému v praxi nepříjemnému útoku ze strany analytika, je dobré položit si tyto otázky sám. Vyvstalý problém se však musí vyřešit, právě tento okamžik se může stát kritický faktorem pro celý projekt. Klient klidně může říct, že to „diskusní fórum“ si takhle nepředstavoval, a že ho chce udělat jinak -> nárůst práce. leden ’07


24

UML – přirozené odpovědi na funkční požadavky

Z důvodu nutné stručnosti budeme řešit pouze jeden problém. F11:Návštěvníci budou moci reagovat na příspěvky pomocí diskusního fóra. F11.1:Součástí stránek bude diskusní fórum. F11.2:Návštěvníci budou moci vkládat do fóra příspěvky. F11.3:Systém bude zobrazovat příspěvky podle definovatelných kategorii. F11.4:Registrovaný návštěvník bude moci do fóra vložit obrázek. …………………………………. leden ’07


25

UML – modelování případů užití

Modelování případů užití používá jinou formou zachycení požadavků na systém. Je postaven na následujících aktivitách: nalezení hranic systému, vyhledání účastníků, nalezení případu užití, specifikaci případu užití a tvorbě scénářů. Tyto aktivity jsou rozhodující pro nalezení komponent budoucího systému.

leden ’07


26


•

Hranice systému. Je velmi důležitá a říká, kde bude končit finální produkt, co tedy již není jeho součástí.

leden ’07


27


•

Účastníci. Nejsou vnímaní ve stavu konkrétních osob, ale z pohledu systému jsou vnímání spíše jako role, které dané elementy v systému hrají. Často bývá účastníkem i čas.

Pro názornost uvádím účastníky z MS Office Visio a Visual Paradigm for UML. Jak je patrno, není mezi nimi jiný než barevný rozdíl ☺ leden ’07


28


•

Případ užití. Je to strukturovaný výčet činností, které mohou účastníci v systému vykonávat. Je tedy nutné projít všechny účastníky systému a zjistit jakou část systému bude ten, který účastník používat, jaké bude mít oprávnění atd.

leden ’07


29


•

Relace. Popisuje vztahy mezi účastníky a případy užití. Rozlišujeme následující základní typy relací.

leden ’07

•

Komunikace

•

Zahrnutí

•

Rozšíření

•

Dědičnost


30

UML – nalezení hranic systému

První aktivitou, kterou budeme provádět při tvorbě případů užití, je hledání hranice systému. Musíme se rozhodnout co bude uvnitř systému, tedy bude implementováno a co je vně systému. Je dobré si uvědomit, že hranice (množina případu užití) je definována uživateli systému (účastníky). Resp. je zbytečné implementovat něco co uživatel nechce nebo je funkcí něčeho co je již implementováno v uživatelském prostředí, či něčem podobném.

leden ’07


31

UML – příklad na nalezení hranic systému

Z logiky funkčních požadavků je zřejmé, že by bylo vhodné rozdělit systém na dvě části. Proč? Protože je evidentní, že požadavky klienta dělí systém na dvě části a to na jakousi administraci a běžnou webovou prezentaci. Dalším rozumným důvodem proč rozdělit systém na dva podsystémy je přehlednost zpracovávaných diagramů.

leden ’07


32

UML – hledání účastníků

Jak již bylo naznačeno účastník je role v budoucím systému. To může v konkrétním případě znamenat, že uživatel šéfredaktor je při přidávání vlastního článku v roli redaktora. Resp. uživatel může mít přístup k více rolím (účastníkům). Abychom mohli účastníky identifikovat musíme si položit otázku: „Kdo nebo co systém používá a jakou roli při komunikaci se systémem hraje?“.

leden ’07


33

UML – příklad na hledání účastníků

Vzpomeňme si na příklad z funkční požadavků a pokusme se v nich najít účastníky systému. F1:Na redakční server se budou moci přihlašovat redaktoři a šéfredaktor. F3:Šéfredaktor a redaktoři se budou moci odhlašovat ze systému. F10:Návštěvník bude moci zobrazit detail příspěvku a zde se mu ukáže celá recenze. F11.4:Registrovaný návštěvník bude moci do fóra vložit obrázek.

Ve funkčních požadavcích se díky pravidlům pro formulaci snadno hledá podstatné jméno (zodpovědnost, komunikace). Tento způsob hledání se nazývá Analýza přirozeného jazyka. leden ’07


34

UML – identifikace případů užití

Již z termínu „případ užití“ je patrné, že případ užití je jakousi reakcí na požadavek účastníka na systém. Jinak řečeno případ užití je přímo nebo nepřímo evokován účastníkem. Případy užití tvoříme tak, aby byly napsány z pohledu účastníka. Pozorný posluchač si doufám domyslel návaznost s funkčními požadavky.

leden ’07


35

UML – identifikace případů užití

Nyní jsme se dostali do stádia, kdy už známe všechny účastníky systému. Nyní z funkčních požadavků budeme dohledávat co vlastně budou v systému dělat a jakým způsobem spolu budou komunikovat. Hledání případů užití je poněkud složitější než hledání ostatních prvků. Bývá vhodné celé modelování konzultovat s klientem až při druhém setkání (iteraci). Důvod je zřejmý, tvoříme z funkčních požadavků. Konzultant musí chápat systém v širším kontextu.

leden ’07


36

UML – příklad identifikace případů užití Případy užití připravíme a konzultujeme na schůzce již připravené. Část administrace by mohla vypadat asi takto:

leden ’07


37

UML – detaily případu užití

Idea detailů případů minispecifikací.

užití

je

převzata

z

tzv.

Pro každý případ užití modelujeme detail případu užití.

Detaily případu užití musí mít následující prvky: o o o o o o

leden ’07

Název Kód Účastníci Vstupní podmínky Tok událostí Výstupní podmínky


38

UML – detaily případu užití – rozbor jednotlivých částí

• •

• •

leden ’07

Název – odpovídá názvu z případu užití s použitím tzv. Velbloudího písma. Kód – je vhodné volit kód tak, aby korespondoval například jako zkratka s názvem systému (hranice systému, podsystému). Účastníci – prostý výčet všech účastníků, kteří s daným případu užití komunikují. Vstupní podmínka – zde se zapisuje podmínka nebo podmínky, které jsou nutné k tomu aby byl realizován tok událostí popřípadě scénář.


39


•

leden ’07

Tok událostí – popisuje postup, pomocí nějž je možné dosáhnout cíle. Formulace musí být jednoznačná a pokud možno i stručná, ne souvětí. Výše v textu jsme u typů relací zmiňovali pokročilé relace <<extendets>> a <>. Ze zcela zřejmých důvodu si je ozřejmíme až nyní. • Include (vložení) se používá v případech, kdy tok událostí jednoho případu užití je součástí jiného. • Extendets (rozšíření) používáme tehdy, když tok událostí je rozšířen jiným tokem událostí. Resp. v toku událostí se vyskytuje jiná varianta průchodu, kterou z pohledu funkčnosti případu užití nepovažujeme za hlavní.


40


•

•

leden ’07

Specializace – je posledním případem možné relace, používá se v případech, kdy určitá okolnost toku události má svou speciální variantu.

Použití relace rozšíření nebo vložení není nutné. Je vhodné je použít, když je počet bodů v toku událostí příliš dlouhý a snižuje celkovou přehlednost. Výstupní podmínky – definuje podmínku, která musí být naplněna po dokončení toku událostí. Je to jakýsi výsledek případu užití.


41

UML – příklad detailu případů užití

V předchozí části jsme si ukázali část uvažované administrace. Mohli jsme si všimnout, že editace z pohledu funkčnosti, bez ohledu na to, jestliže editujeme svůj nebo cizí příspěvek bude ve své podstatě vykazovat stejnou posloupnost toku událostí. To by nás mohlo přivést k následujícímu řešení: Spojení společných částí případů užití zabývajících se editací příspěvků a současně oddělení odlišných částí. Další možnost využití zmiňovaných relací se nabízí u vyhledávání před mazáním nebo editací příspěvků. Nejprve si však ukážeme původní řešení. leden ’07


42


leden ’07


43

UML – příklad detailu případů užití Případ užití: EditaceVlastníchPříspěvků ID:A2 Účastníci: Redaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 V systému existuje alespoň jeden vlastní příspěvek. Tok událostí: 1 Případ užití začíná výběrem položky výpisu příspěvků. 2 Systém zobrazí výpis všech příspěvků. 3 Systém pole pro vyhledávání příspěvků. 4 Když uživatel zadá do pole vyhledej klíčové slovo a stiskne vyhledej pak: 4.1 Systém vyhledá články obsahující hledané slovo. 4.2 Systém zobrazí vyhledané články. 5 Systém zobrazí u vlastních příspěvků tlačítko edituj. 6 Redaktor stiskne tlačítko edituj. 7 Systém zobrazí v samostatném formulářovém okně detail článku. 8 Redaktor změní vybrané hodnoty. 9 Redaktor stiskne tlačítko edituj článek. 10 Systém zavře editační okno. 11 Systém provede editaci. 12 Systém zobrazí původní výpis všech příspěvků. 13 Systém zobrazí u vlastních příspěvků tlačítka přidej, edituj, smaž. 14 Systém pole pro vyhledávání příspěvků. 15 Případ užití končí Následné podmínky: 1 Článek byl editován. leden ’07


44

UML – příklad detailu případů užití Případ užití: EditaceCizíchPříspěvků ID:A6 Účastníci: Šéfredaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 V systému existuje alespoň jeden příspěvek. Tok událostí: 1 Případ užití začíná výběrem položky výpisu příspěvků. 2 Systém zobrazí výpis všech příspěvků. 3 Systém pole pro vyhledávání příspěvků. 4 Když uživatel zadá do pole vyhledej klíčové slovo a stiskne vyhledej pak: 4.1 Systém vyhledá články obsahující hledané slovo. 4.2 Systém zobrazí vyhledané články. 5 Systém zobrazí u všech příspěvků tlačítko edituj. 6 Šéfredaktor stiskne tlačítko edituj. 7 Systém zobrazí v samostatném formulářovém okně detail článku. 8 Šéfredaktor změní vybrané hodnoty. 9 Šéfredaktor stiskne tlačítko edituj článek. 10 Systém zavře editační okno. 11 Systém provede editaci. 12 Systém zobrazí původní výpis všech příspěvků. 13 Systém zobrazí u vlastních příspěvků tlačítka přidej, edituj, smaž. 14 Systém pole pro vyhledávání příspěvků. 15 Případ užití končí Následné podmínky: 1 Článek byl editován. leden ’07


45


Takovéto modelování zjevně není moc efektivní. Tok událostí je zbytečně příliš dlouhý a málo přehledný a navíc některé části se evidentně zbytečně opakují. Proto se pokusíme tuto část rozumně zpřehlednit. Změny však nesmí narušit původní model chování specifikovaný předchozí iterací.

leden ’07


46


leden ’07


47

UML – příklad detailu případů užití Případ užití: EditacePříspěvků ID:A2 Účastníci: Redaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 V systému existuje alespoň jeden příspěvek. Tok událostí: 1 Případ užití začíná výběrem položky výpisu příspěvků. 2 <> A6::ZobrazitPříspěvky 3 Systém zobrazí u vlastních příspěvků tlačítko edituj. 4 <<extendets>> A3::EditaceCizíchPříspěvků 5 Redaktor stiskne tlačítko edituj. 6 Systém zobrazí v samostatném formulářovém okně detail článku. 7 Redaktor změní vybrané hodnoty. 8 Redaktor stiskne tlačítko edituj článek. 9 Systém zavře editační okno. 10 Systém provede editaci. 11 <> A6::ZobrazitPříspěvky 12 Případ užití končí Následné podmínky: 1 Článek byl editován.

leden ’07


48

UML – příklad detailu případů užití Případ užití: EditaceCizíchPříspěvků ID:A3 Účastníci: Šéfredaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 Uživatel je šéfredaktor. Tok událostí: 1 Systém zobrazí i u cizích příspěvků tlačítka přidej, edituj, smaž. 2 Případ užití končí Následné podmínky:

Pokud jsme si mohli všimnout, tak jediný rozdíl mezi editací cizího a vlastního příspěvků spočíval v jediném slově v toku událostí. Nabízené řešení, velmi usnadní do budoucna práci programátorům a celkově zpřehlední model případu užití.

leden ’07


49

UML – příklad detailu případů užití Případ užití: ZobrazitPříspěvky ID:A3 Účastníci: Redaktor Šéfredaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 V systému existuje alespoň jeden příspěvek. Tok událostí: 1 Systém zobrazí výpis všech příspěvků. 2 Systém pole pro vyhledávání příspěvků. 3 Když uživatel zadá do pole vyhledej klíčové slovo a stiskne vyhledej pak: 3.1 Systém vyhledá články obsahující hledané slovo. 3.2 Systém zobrazí vyhledané články. Následné podmínky: 1 Články byly vypsány.

Velmi nepříjemné bylo také čtyřnásobné opakování zobrazení výpisu článků. (programátora by to nevybízelo napsat zobrazení příspěvků jako samostatnou metodu) Zahrnutí zobrazení se ukázalo jako nejjednodušší řešení.

leden ’07


50

UML – příklad detailu případů užití Případ užití: MazáníPříspěvků ID:A4 Účastníci: Šéfredaktor Vstupní podmínky: 1 Uživatel je přihlášen do systému. 2 V systému existuje alespoň jeden příspěvek. Tok událostí: 1 Případ užití začíná výběrem položky výpisu příspěvků. 2 <> A6::ZobrazitPříspěvky 3 Systém zobrazí u každého článku tlačítko smaž. 4 Šéfredaktor stiskne tlačítko smaž. 5 Systém zobrazí dialogové okno s otázkou: „Opravdu chcete smazat vybraný článek?“ -> ANO NE. 6 Systém zakáže zobrazování článku. 7 Případ užití skončil. Následné podmínky: 1 Článek byl stínově smazán.

leden ’07


51

UML – Slovníček pojmů

Poslední aktivitou, kterou provádíme v rámci tvorby požadavků na systém je vyhotovení slovníčku pojmů. Slovníček pojmů je výčet položek, se kterými systém pracuje, čte je, ukládá a jejich omezení například z pohledu evidence. Slovníček pojmů je důležitou částí datového modelování pomáhá nám určit jaká data bude systém evidovat a jaká budou mít omezení.

leden ’07


52

UML – Příklad na slovníček pojmů

Postup by měl být asi takový, že ve funkční požadavcích a v tocích událostí hledáme podstatná jména. Z kontextu, ve kterém jsou tyto podstatná jména posoudíme jejich význam. Ukázka hledání pojmů ve funkčních požadavcích. F10:Návštěvník bude moci zobrazit detail příspěvku a zde se mu ukáže celá recenze.

leden ’07


53

UML – Příklad na slovníček pojmů

Rozumného analytika asi napadne, že s pojmem detail příspěvku není něco v pořádku. Napadne ho otázka co je to ten detail, co všechno obsahuje. Na tyto otázky by měl slovníček pojmů jasně odpovědět. 1.

Detail příspěvku – výpis všech atributů článku (jakých atributů??) a. Název článku – textový řetězec dlouhý 80 znaků. b. Autor – jméno a příjmení autora dohromady dlouhé 70 znaků. c. Článek – text dlouhý nejvíce 10000 znaků. d. Fotka – obrázek týkající se článku ve formátu .jpeg.

leden ’07


54

Unified Modeling Language (UML)

Recommend Documents