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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 8

UML casená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 Střední průmyslová škola Bruntál 9

UML Požadavky Požadavky leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 13

UML aktivity Během požadavků provádíme následující aktivity (tvoříme): Funkční a nefunkční požadavky Případy užití Detaily případu užití Slovníček pojmů leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 16

UML formulace požadavků Struktura požadavků je tedy následující: <id><systém> bude <funkce> <id> - 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. <funkce> -jednoznačný popis toho co má systém dělat. Popis neobsahuje žádnou podmínku. Nepokračuje souvětím. leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 18

UML příklad funkčních požadavků (1.) Představme si hypotetické zadání pro redakční systém. 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 26

UML modelování případů užití 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 Střední průmyslová škola Bruntál 27

UML modelování případů užití Úč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 Střední průmyslová škola Bruntál 28

UML modelování případů užití 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 Střední průmyslová škola Bruntál 29

UML modelování případů užití Relace. Popisuje vztahy mezi účastníky a případy užití. Rozlišujeme následující základní typy relací. Komunikace Zahrnutí Rozšíření Dědičnost leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 37

UML detaily případu užití Idea detailů případů užití je převzata z tzv. minispecifikací. 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 Název o Kód o Účastníci o Vstupní podmínky o Tok událostí o Výstupní podmínky leden 07 Střední průmyslová škola Bruntál 38

UML detaily případu užití rozbor jednotlivých částí 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ář. leden 07 Střední průmyslová škola Bruntál 39

UML detaily případu užití rozbor jednotlivých částí 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 <<include>>. 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í. leden 07 Střední průmyslová škola Bruntál 40

UML detaily případu užití rozbor jednotlivých částí 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í. leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 42

UML příklad detailu případů užití leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 45

UML příklad detailu případů užití 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 Střední průmyslová škola Bruntál 46

UML příklad detailu případů užití leden 07 Střední průmyslová škola Bruntál 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 <<include>> 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 <<include>> A6::ZobrazitPříspěvky 12 Případ užití končí Následné podmínky: 1 Článek byl editován. leden 07 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 <<include>> 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 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 Střední průmyslová škola Bruntál 54