České vysoké učení technické v Praze. Fakulta elektrotechnická. Bakalářská práce

České vysoké učení technické v Praze

Fakulta elektrotechnická

Bakalářská práce Softwarová analýza Anonymního Informačního Portálu Software Analysis of the Anonymous Information Portal Jiří Hegmon

Vedoucí práce: Ing. Martin Komárek Studijní program: Elektrotechnika a informatika prezenční bakalářský Obor: Informatika a výpočetní technika Praha, únor 2009

Poděkování Děkuji vedoucímu mé bakalářské práce Ing. Martinu Komárkovi za příjemnou spolupráci, motivaci, trpělivost a pomoc při tvorbě této práce. Dále bych chtěl poděkovat rodičům, rodině a mým blízkým za podporu při vytváření tohoto dokumentu i po dobu dosavadního studia.

Prohlášení o samostatném zpracování práce Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v seznamu literatury. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č.121/2002 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 4. června 2008

Jiří Hegmon

Abstract This bachalor thesis represents six-month intensive endeavor of creation software analysis for application serving for needs of whistleblowing. There has been used graphical language UML with reference to object-oriented analysis. Documentation of this project was made as part of analysis. This thesis is engaged in creation and edit of the documents in the end.

Abstrakt Tato bakalářská práce reprezentuje půlroční intenzivní snahu o vytvoření softwarové analýzy k aplikaci sloužící pro potřeby whistleblowingu. Při vytváření analýzy byl použit grafický jazyk UML s ohledem na objektově orientovanou analýzu Jako součást analýzy byla vytvořena i dokumentace tohoto projektu. Tato práce se ve svém konci zabývá i tvorbou a úpravou těchto dokumentů.

Obsah Úvod .............................................................................................................................................. 13

1.

1.1.

Zadání .................................................................................................................................... 13

1.2.

Důvody vypracování. ............................................................................................................ 13

1.3.

Rozčlenění práce ................................................................................................................... 13

1.4.

Specifikace cílů ..................................................................................................................... 13

2.

Popis problému .............................................................................................................................. 15

3.

Definice pojmů v oblasti whistleblowingu .................................................................................... 16 Historie whistleblowingu a právní aspekty činnosti .............................................................. 16

3.1.

Podobné projekty a komerční využití ............................................................................................ 17

4.

4.1.

BUSINESS KEEPER AG ..................................................................................................... 17

4.2.

Lokální MMS-ing Městské části Praha 6 .............................................................................. 18

Analýza softwaru ........................................................................................................................... 19

5.

Analýza požadavků ............................................................................................................... 19

5.1.

5.1.1.

Nefunkční požadavky .................................................................................................... 21

5.1.2.

Funkční požadavky ........................................................................................................ 20

Analýza USE CASE .............................................................................................................. 22

5.2.

5.2.1.

Analýza uživatelů .......................................................................................................... 22

5.2.2.

Analýza případů užití .................................................................................................... 22

5.2.3.

Scénáře .......................................................................................................................... 24

5.2.4.

Vazba případů užití na požadavky ................................................................................ 25

5.3.

Analýza analytických tříd ...................................................................................................... 26

5.4.

Analýza stavových diagramů ................................................................................................ 27

5.5.

Analýza diagramů aktivit ...................................................................................................... 28

6.

Tvorba dokumentace ..................................................................................................................... 29 6.1.

Možnosti dokumentace.......................................................................................................... 29

6.2.

Tvorba template ..................................................................................................................... 31

6.3.

Úprava vygenerového textu v MS WORD ............................................................................ 32

7.

Závěr.............................................................................................................................................. 34

8.

Seznam tabulek.............................................................................................................................. 35

9.

Seznam obrázků ............................................................................................................................ 36

10.

Přílohy ....................................................................................................................................... 37

10.1.

Přílohy v bakalářské práci ................................................................................................. 37

10.2.

Obsah přiloženého CD ...................................................................................................... 37

11.

Zdroje ........................................................................................................................................ 38

Strana 11

11.1.

Internetové stránky ............................................................................................................ 38

11.2.

Knihy ................................................................................................................................. 38

Strana 12

1. Úvod 1.1.Zadání Softwarová analýza Anonymního informačního portálu. Bakalářská práce se bude skládat z kompletní softwarové analýzy a dokumentace k BKM systému Anonymní Informační Portál (dále jen AIP). BKM systémem nazýváme systém, aplikaci, program, který užívají občané popř. zaměstnanci ke kontaktu s vyššími orgány státní správy popř. organizace, se kterou spolupracují. Zásada je, že tato komunikace musí být obousměrná, ale ze strany zadavatele informací anonymní. Bakalářská práce se bude skládat z analýzy a z vazeb implementace na analýzu. Analýza bude provedena pro aplikaci určenou jak pro společnosti, tak pro města. V rámci společností by byla užívána k sdělování návrhů nebo stížností. Zachování anonymity musí být ponecháno vzhledem k strachu z případných postihů nebo firemní persekuce. V rámci měst je systém užit jako informační portál od občanů k městským autoritám, jako jsou dopravní policie, technické služby atd. Analýza bude prováděna pomocí slovní dokumentace a prostředků jazyka UML. Celá dokumentace bude vygenerována pomocí UML nástroje. UML (Unified Modeling Language) je jazyk používaný v softwarovém inženýrství pro specifikaci, vizualizaci, návrh a dokumentaci programových systémů.

1.2.Důvody vypracování. Analýzu jsem se rozhodl vypracovat vzhledem k zájmu o téma po absolvování předmětu X36SIN v letním semestru 2. ročníku 2006/2007. Projekt „Bonzák“, ze kterého tato bakalářská práce vychází, lze nalézt v elektronických přílohách. V předmětu X36SIN byla velmi částečně zpracována problematika whistleblowingu, avšak chybělo jí pořádné dotažení a přesné informace. Rozhodl jsem se analyzovat vlastní nekomerční formu již existujících systému. Podobný systém používá již např. MČ Praha 6. O podobné informační systémy je v západní Evropě v dnešní době veliký zájem. Konečným záměrem je vytvoření životaschopného systému, který zlepší pracovní i lidské soužití ve firmách i obcích. Velké množství osob má problémy své nápady sdělovat svému okolí přímo z „očí do očí“, proto by mohli využít AIP k předávání svých idejí. Druhý směr, kterým se AIP může ubírat, je nahlašování prohřešků a nezákonné činnosti ve městech a obcích, kde by se občané báli fyzické či psychické újmy od pachatele prohřešku.

1.3.Rozčlenění práce Svou práci jsem rozčlenil do několika kapitol. Následující kapitola se zaobírá samotným popisem a charakteristikou problému. Kapitola 3. je zaměřena hlavně na již stvořené a komerční projekty podobného nebo stejného rázu jako má být software AIP. Hlavní text analýzy se nalézá v kapitole 4. Tvorbou a doladěním dokumentace se zabývá kapitola 5. Kapitola 6., obsahuje shrnutí a závěr.

1.4.Specifikace cílů Cílem této práce je na základě shlédnutých systému vytvořit softwarovou analýzu pro tvorbu nástroje, který by zachovával anonymitu a bezpečnost zadavatele problému. Také byl brán jako plnohodnotný a umožnil zadavateli projevit své nápady nebo stížnosti plnou měrou.

Strana 13

Dalším krokem v tvorbě analýzy je generování dokumentace pro programování tohoto nástroje. Dokumentace i analýza je tvořena v aplikaci Enterprise Architecture od firmy Sparx Systems© v jazyce UML 2.1. Tvorba dokumentace je tvořena pomocí generování do souborů RTF. Posledním stanoveným cílem poskytnutí analytické podpory a dokumentace při implementaci softwaru AIP třetí stranou.

Strana 14

2. Popis problému V dnešní době je problematika udávání nazývána whistleblowing. Tímto problémem se zabývají i velké organizace po celém světě, např. v Americe je to National Security Whistleblowers Coalition, Whistleblower-Netzwerk v Německu a další. Definice problému citovaná podle webové stránky [2]: „Whistleblower [uislblouer] je ten, kdo píská na píšťalku, aby na něco upozornil. V českém jazyce nemá toto označení adekvátní ekvivalent. Překládá se nejčastěji jako informátor (případně ne moc výstižně jako oznamovatel), ovšem toto označení v sobě stále nese jakousi negativní pachuť udavačství a práskačství. Pojem whistleblowing [uislblouing] má naopak pozitivní náboj, neboť obsahuje odvahu sdělit nějakou skutečnost, kterou se jiní sdělit neodváží; odvahu potlačit strach, loajalitu či kolegialitu a upozornit na nefair jednání. Whistleblowing je morálně silné a hodnotné jednání, definičně vymezitelné jako „oznámení ilegálních nebo eticky pochybných praktik na pracovišti“, a jako mnoho jiných progresivních opatření pro zvýšení transparentnosti či snížení korupce je i whistleblowing více rozšířen a podporován v soukromých firmách než na úřadech. Podporovat whistleblowing znamená vytvořit (zejména pro zaměstnance úřadu, ale i jakékoli jiné osoby přicházející do styku s úřadem) takové podmínky, aby měli i jinou možnost upozornit na korupční či jinak nekalé jednání, než jít za nadřízeným či na policii. Jít na policii oznámit podezření z trestné činnosti kolegy či nadřízeného je pro mnoho lidí psychologicky příliš náročný krok. Jít za nadřízeným či tajemníkem úřadu zabraňuje často nevyzpytatelnost jejich reakce a strach, že se dotyčnému podezřelému donese identita informátora bez toho, aby podezřelý byl vyšetřen, případně potrestán. Záruka neprozrazení nebo možnost zůstat v anonymitě je základním principem podpory whistleblowingu. U nás je bohužel běžnou praxí házet anonymní stížnosti do koše pouze proto, že jsou anonymní. Na úřadech je přitom hodně lidí, kteří vědí o nějaké nekalé činnosti, vadí jim takové jednání a rádi by s tím něco udělali, ovšem něco jiného než oznámit je policii či nadřízenému. Jejich informace však mají pro vedení samosprávy i pro policii cenu zlata. Umět pracovat s anonymem je velmi důležité, ačkoli zároveň velmi těžké. Je potřeba vytvořit dvoustranný model, který obsahuje ochranu whistleblowera před pronásledováním úřadem a současně i ochranu úřadu před nespravedlivými obviněními. V západní Evropě a zejména v USA jsou techniky i psychologie whistleblowingu již dopodrobna propracovány, používají se různé druhy ochrany informátorů i navazování kontaktu s nimi.“ V České republice se problém, jak informovat v příhodné situaci, neustále rozšiřuje. Na jedné straně korupce, přestupky a nezákonné jednání, na které obyvatelé nechtějí upozornit z důvodu strachu. Na straně druhé nedostatek invence, nápaditosti a ochoty prosadit se jako zaměstnanec v soukromé sféře i státní. Zaměstnanci se obávají postihu a studu při projevení vlastního názoru a nápadů. Oba problémy jsou řešitelné zachováním anonymity zadavatele. Avšak anonymní udání byla v minulosti, za dob komunismu i dříve, používána k vlastnímu prospěchu, manipulaci a odstraňování nevhodných osob. Proto se v dnešní době na anonymní jednání nahlíží s despektem a odporem.

Strana 15

2.1. Definice pojmů v oblasti whistleblowingu Kapitola 2.1 a 2.2 obsahují výňatky a překlady informací z angličtiny do češtiny z webové stránky [1]. Whistleblower - Toto označení pochází z činnosti britských policistů. Tito policisté pískali na píšťalku při spáchání trestného činu nebo přestupku, aby povolali posily z řad svých kolegů a navíc ještě upozornili veřejnost na možné nebezpečí. Interní whistleblowing – nejběžnějším druhem whistleblowerů jsou tzv. interní whistlebloweři, tito lidé hlásí hlavně nevhodné chování svých pracovních kolegů, nadřízených nebo třeba zaměstnavatelů. Avšak tuto činnost provádí v rámci jedné firmy či organizace. Externí whisleblowing – při externím whistleblowingu je hlášena činnost vnějším orgánům a osobám. V těchto případech záleží na povaze a vážnosti prohřešku. Whistlebloweři se mohou uchylovat k nahlášení právním orgánům, médiím nebo přímo k státní moci.

2.2.Historie whistleblowingu a právní aspekty činnosti Největším problémem v oblasti whistleblowingu je obava z represe ze strany udaného. Tyto represe mohou být malé a nevýznamné (např. slovní urážky, drobný psychologický nátlak, snížení platu atd.) až po další těžkou činnost (fyzická likvidace, vyhrožování atd.). Jako reakci na tuto činnost má většina společností v západním světě tzv. „legal defense funds“ neboli fondy, do kterých ukládají prostředky na ochranu proti persekuci whistleblowerů. Jako další z možných řešení jsou zakládány skupiny, které ochraňují a pomáhají whistleblowerům. Jako příklad bych použil Public Concern At Work ve Spojeném Království. Avšak v České republice nejsou tyto činnosti nijak rozšířené. Legální ochrana whistleblowerů se liší země od země. Například v Spojeném Království v roce 1998 vydaný Public Interest Disclosure Act poskytuje rámcovou kostru legální ochrany pro jednotlivce, kteří odkryjí nevhodné chování ve firmách i jiných organizacích. V podstatě chrání whistleblowery proti nátlaku a represím. Ve Spojených státech Amerických se mění legální ochrana whistleblowerů podle podstaty udání a také podle stavu ve kterém se případ nachází. Prvním zákonem ochraňujícím hlavně whistleblowery byl Lloyd-La Follette Act schválený v roce 1912. Poskytoval právo federálním zaměstnancům poskytnout informace Kongresu Spojených Států. Poslední velkou organizovanou akcí byl tzv. Týden whistleblowerů ve Washingtonu (angl. Whistleblower Week in Washington (WWW)) v květnu 2007. Tato akce byla svolána na podporu zákona pro silnější ochranu whistleblowerů ze soukromé i ze státní sféry ve Spojených Státech.

Strana 16

3. Podobné projekty a komerční využití V této kapitole bych se rád zaměřil na již vzniklé projekty v Čechách a v SRN. Jako nejlepší případy se mi naskytly projekt firmy Business Keeper AG, popsaný v kapitole 3.1, a projekt Lokální MMS-ing Městské části Praha 6, popsaný v kapitole 3.2.

3.1.BUSINESS KEEPER AG Svou práci jsem začal dělat na základě produktu Busines Keeper Monitoring System od firmy Business Keeper AG z Postdamy v Spolkové Republice Německo (možno nalézt na internetové stránce [3]).

Obr. 1 - Logo společnosti Business Kepper AG

Tato firma se zabývá problematikou whisteblowingu už řadu let. Firma poskytuje členství lidem, kteří se chtějí podílet na odhalování korupce a ilegální činnosti ve firmách. Zachovávají všechny základní principy řešení problému, tj. udržení anonymity whistleblowera a souhra s legislativou a zákony daného státu. Na svých stránkách popisují problematiku whistleblowingu i samotné pojetí řešení problému, viz Obr. 2.

Obr. 2 - Schéma produktu Business Keeper Monitoring System od firmy Business Keeper AG

Systém slouží zatím více soukromým firmám, pomalu o něj ale začínají projevovat zájem i německé samosprávy. Plně funkční je například v Dolním Sasku, kde ho úspěšně používá zemský kriminální úřad, a jeho využívání připravuje i město Berlín. BKMS je internetový komunikační kanál, jehož největší předností je zaručené zachování anonymity whistleblowera. Systém je naprogramován tak, že znemožňuje vypátrat, kdo a odkud informace do systému zadal (certifikovaný anonymizační program). Komunikace běží přes webové stránky společnosti Business Keeper a jednotlivé firmy či úřady si tento komunikační systém pronajímají. Další výhodou systému je to, že po podání podnětu může whistleblower v komunikaci pokračovat, neboť je mu přiděleno heslo a zřízena schránka, a tak sdělováním dalších informací napomáhat vyšetření případu. Aby se vyloučila možnost záměrného ignorování nějakého oznámení, měly by mít ke sdělovaným informacím od whistleblowerů přístup jak vedení samosprávy (úřadu), tak příslušný policejní orgán.

Strana 17

3.2.Lokální MMS-ing Městské části Praha 6 Dalším obdobným projektem je projekt Lokální MMS-ing Městské části Praha 6 v Praze (dále jen MMSing, možno nalézt na webu [4]). MMSing se zaměřuje na rozdíl od řešení BK na problematiku přestupků a nezákonné činnosti na ulicích.

Obr. 3 - Logo Městské části Praha 6

Na svých webových stránkách nabízí možnost zaslání MMS zprávy, její vystavení na svých stránkách a řešení daného problému. Oficiální text podle [4] o MMSingu: „Portál PRAHA6.CZ pro Vás připravil skutečně unikátní produkt v rámci České republiky s názvem "Lokální MMS-ing". V rámci obecního programu Čistá šestka zahajuje novou éru upozorňování na různé nešvary a nedostatky na území městské části. Pro rychlejší nápravu a řešení by měla pomoci stále větší obliba a rozšířenost mobilních telefonů s fotoaparátem a také ochota občanů městské části se na řešení problémů spojených s úklidem a pořádkem podílet. Problematiku čistoty a pořádku má sice radnice za svou prioritu, je ale jasné, že čtyři inspektoři životního prostředí a třicet strážníků městské policie opravdu nemůže být na všech místech Prahy 6 najednou. Obzvláště uvědomíme-li si, že Praha 6 je územně největší městskou částí v rámci hlavního města a její rozloha je 41 km čtverečních. Proto mohou pomocí tzv. MMS pomoci i občané. Stačí odeslat fotografii z mobilního telefonu (případně ale i z počítače) např. rozbité lavičky, převrhnuté popelnice, rozbitého chodníku, neposekané trávy, pomalované fasády, začínající skládky apod. “ Vzhledem k tomu, že přestupky schraňované na těchto stránkách nejsou velmi závažné, není vyžadována naprostá anonymita, a tak je povoleno použití mobilního telefonu.

Obr. 4 - Ukázka zobrazeného úkolu v aplikaci Lokální MMSing Městské části Praha 6

Strana 18

4. Analýza softwaru Analýzu jsem se rozhodl vypracovat v notaci UML 2.1. Důvodem volby této notace bylo to, že se UML používá jako obecně používaný standard v softwarovém inženýrství a také absolvování předmětu X36SIN v letním semestru 2006/2007, kde se již zmíněná notace probírala a názorně popisovala. Analýza softwaru AIP byla započata prvotním ujasněním požadavků systému. Toto je dále rozebráno v kapitole 4.1. Kapitola 4.2 se zaobírá tvorbou a objasněním případů užití. Následující kapitola je přiřazena analýze analytických tříd reprezentující software AIP. Poslední kapitola, tj. 4.5, je odkázaná diagramům sekvencí a diagramům aktivit.

4.1.Analýza požadavků V této kapitole je popsána kompletní analýza požadavků pro systém AIP, ty je možno vidět na Obr. 5 - Package diagram zobrazující funkční a nefunkční požadavky z dokumentace AIP. Tato část byla počátečním bodem celé analýzy. Kompletní dokumentace požadavků je uvedena v příloze [A] v Kapitole Požadavky. Definice požadavků podle [6]: „Model požadavků obsahuje dvě skupiny požadavků:  funkční požadavky - functional requirements; což jsou požadavky určující, co by měl systém dělat  nefunkční požadavky - non-functional requirements; což jsou požadavky vyjadřující nefunkční omezení systému, např. platformu, programovací jazyk atd. Inženýrství požadavků je termín používaný k popisu aktivit zapojených do zjišťování, dokumentování a údržby množiny požadavků na softwarový systém. Zastupuje odhalování způsobu, jak a k čemu uživatelé daný systému používají. Podle internetové publikace [5] jsou nedostatečně specifikované požadavky a nedostatečné zapojení uživatelů dvěma hlavními příčinami konečného neúspěchu celého projektu. Obě zmíněné příčiny jsou selháním v procesu inženýrství požadavků.“

Strana 19

Obr. 5 - Package diagram zobrazující funkční a nefunkční požadavky z dokumentace AIP

4.1.1. Funkční požadavky Funkční požadavky systému AIP se odvíjí od potřeb jednotlivých uživatelů popsaných v kapitole 4.2.1. Tyto jsou kompletně popsány v příloze [A] podkapitola Funkční požadavky na straně 7. Původní funkční požadavky se skládaly asi z 6 položek, avšak s přibývající hloubkou analýzy se počet požadavků na funkci systému značně rozšiřoval. Jako hlavní pilíře analýzy funkčních požadavků se ukázaly být požadavky týkající přidávání a zobrazování úkolů a všeobecné administrace uživatelských rolí. Navázání požadavků na jednotlivé případy užití je provedeno formou poznámek u jednotlivých požadavků. Jeden takovýto požadavek zobrazuje Obr. 6.

Strana 20

Obr. 6 - Ukázka funkčního požadavku týkajícího se anonymity Klienta v dokumentaci AIP

V této fázi se objevila potřeba Slovníčku pojmů, který dále narůstal do nynější velikosti. Slovníček pojmů je uveden v příloze [A] stránka 5. Podle knihy [6] je Slovníček pojmů definován takto: „Slovníček pojmů (project glosary) daného projektu může být jedním z jeho nejdůležitějších artefaktů. Každé odvětví má vlastní žargon, jazyk, terminologii. Hlavní smysl inženýrství požadavků a analýzy spočívá v pochopení a zachycení tohoto jazyka. Slovníček pojmů poskytuje lexikon klíčový obchodních termínů a definicí. Jednotlivým položkám v tomto slovníku by měli rozumět všichni, kdo se na projektu určitým způsobem podílejí – včetně uživatelů. Jazyk UML nestanovuje žádné standarty pro slovníčky pojmů. Platí za bernou minci, že čím jednodušší a stručnější tím lépe.“ 4.1.2. Nefunkční požadavky Nefunkční požadavky jsou kompletně popsány v příloze [A] podkapitola Nefunkční požadavky na straně 11. První krok v analýze bylo specifikování nefunkčních požadavků. Jako základní požadavek se naskytla potřeba zvoleného prostředí pro aplikaci AIP. Prve se zdál jako vhodné prostředí pro AIP tlustý aplikační klient psaný v Javě, C++, případně C# nebo jiném objektově orientovaném jazyce. Avšak vzhledem k jasné platformové závislosti, ať už velmi malé v případě Javy nebo zcela zásadní v případě C#, byla tato myšlenka zavržena a další bádání se odvíjelo úplně jiným směrem. Nakonec byl jako vhodné prostředí zvolen internetový prohlížeč a jazyk pro internetové stránky PHP 5.5 společně s HTML, kvůli jejich dostupnosti na všech platformách a téměř neomezenému přístupu k takto naprogramovanému AIP z celé zeměkoule. Následujícím okruhem nefunkčních požadavků se ukázal vztah vůči otevřenému kódu (tzv. OpenSource). Myšlenka postavení systému na čistě Open Sourceových komponentách se zdá jako správná, ať už z důvodu velké uživatelské podpory jednotlivých komponent nebo finanční nezatížeností při pořízení takové komponenty. Další související problém se ukázalo uvedení samotné aplikace v otevřeném kódu. Prvotní myšlenka na neuvedení aplikace v OpenSource ze strachu z napadení byla posléze převážena potřebou zveřejnění kódu, aby jasně aplikace dokázala, že je bezpečná a neobsahuje „díry“. Poslední článkem nefunkčních požadavků se objevil až průběhu další analýzy. Tímto by měla být odpovídající ochrana proti různým webovým robotům. Důvodů se naskýtá hned několik. Vzhledem k tomu, že systém AIP by chtěl aspirovat na uznávanou autoritu v rámci jednání s úřady, musí být zabezpečen proti spontánnímu přidávání uživatelů, úkolů a jiných elementů.

Strana 21

4.2.Analýza USE CASE Analýza USE CASE se skládá z tří velmi důležitých a na sebe navazujících částí. První z nich, popsána v kapitole 4.2.1, je analýza uživatelů. Osob, které přijdou s aplikací do styku a budou ji „ovládat“. Literární podpora pro tuto část analýzy byla brána hlavně z knihy [6] a následně i z webových stránek Wikipedie.org [1]. Druhou neméně podstatnou částí je analýza případů užití jako takových, tato část je popsána v kapitole 4.2.2. A nakonec v kapitole 4.2.3. můžeme nalézt popis analýzy scénářů. Samotná analýza USE CASE je velmi důležitou součástí každé softwarové analýzy. Jejím cílem je popsat možnosti, které jsou dány jednotlivým uživatelů. V této části se práce odvíjela od slovního zadání definovaného v kapitole 1.3 a od analýzy požadavků, která byla vytvořena později. 4.2.1. Analýza uživatelů Tuto část dokumentace je možno najít v příloze [A] podkapitole Uživatelé stránka 12. Původním záměrem bylo do systému nasadit pouze tři druhy uživatelů. Ale v průběhu analýzy se začali objevovat případy užití, které nemohl postihnout ani jeden z uživatelů. Původní uživatelé byli tito: Administrátor, Řešitel a Uživatel. V podstatě hned na začátku analýzy přibyl uživatel Klient, jako reakce na rozdělení systému v registrovanou a neregistrovanou část. V následujícím čase analýza počítala pouze s těmito čtyřmi druhy uživatelů. Avšak díky problémům ve fázi tvorby stavových diagramů a diagramů aktivit, bylo nutno nasadit nový druh uživatele, uživatele reprezentujícího jakéhosi „Superřešitele“ tzv. Ombudsmana. Tento počet uživatelů zůstal až do konce celé analýzy. Tito uživatel jsou schopni pokrýt celý systém AIP. Kompletní diagram Uživatelů může být nalezen na Obr. 7 pkg Uživ atelé

Uživ atel

Klient

Řešitel

Ombudsman

Administrátor

Obr. 7 - Actors v dokumentaci AIP

4.2.2. Analýza případů užití Případy užití se v této analýze dělí do několika skupin a pohledů. Je možno je najít v příloze [A], podkapitola Primární a Rozepsané případy užití, počínaje stranou 14. Prvním víceméně obecným pohledem je diagram Primární případy užití (viz Obr. 8 - Diagram Primární případy užití popisující kompletní možnosti systému a uživatelů). Tento diagram nevznikl hned na začátku analýzy, ale byl zaveden kvůli přehlednosti nad celým systémem a jeho možnostmi v pozdější fázi analýzy. Původně byly případy užití pouze přiděleny jednotlivým uživatelům. Ale vzhledem k tomu, že uživatelů i případů užití jako takových přibývalo, bylo nutno zavést souhrnný diagram. Tento popisuje jak kompletní vztahy uživatelů vůči sobě, tak i kompletní možnosti systému. Tento diagram avšak

Strana 22

nemohl poskytnout dostatečnou přehlednost pro zavedení vazeb mezi případy užití a proto bylo nutno vytvořit ještě jednotlivé diagramy pro jednotlivé uživatele. uc Primární případy užití

AIP Nepotv rzení žádosti Klient Administrátor

(from Uživatelé)

Zobrazení registrov aných uživ atelů

(from Uživatelé) Potv rzení žádosti

Přidání nov ého úkolu Přidání kategorie

Přidání Řešitele

Zobrazení úkolů

Zažádání o v ytv oření nov é kategorie Zobrazení žádostí Přidání nov ého Administrátora

Přihlášení

Smazání registrov aného uživ atele

Informov ání zadáv aj ícího

Filtrov ání úkolů Anonymní přihlášení Smazání úkolu

Doplnění nesplněného úkolu

Potv rzení rozřazení Registrov ání

Uživ atel (from Uživatelé)

Splnění úkolu Řešitel Přidělení úkolu Řešiteli

(from Uživatelé)

Ombudsman (from Uživatelé)

Obr. 8 - Diagram Primární případy užití popisující kompletní možnosti systému a uživatelů

V následujících diagramech pro jednotlivé uživatele už byly zavedeny vazby „extend“, a přitom neztratila analýza na přehlednosti a obraznosti. Vazba „extend“ popisuje chování, kdy jeden případ užití je rozšířením druhého. Naproti tomu se používá v analýze i vazba „include“, která se zobrazuje vztah, kdy jeden případ užití obsahuje i možnosti druhého.

Strana 23

Obr. 9 - Výňatek z diagramu případu užití pro uživatele Administrátor s ukázkou vazby Extend

4.2.3. Scénáře Poslední částí analýzy USE CASE se stala tvorba scénářů. Tyto je možno nalézt v příloze [A] u každého případu užití. Aplikace Enterpise Architect má zabudovaný modul pro přímou tvorbu scénářů v závislosti na případu užití. Kvůli prvotním problémům s tímto prostředím, které je zobrazeno na Obr. 10, a jeho neúplnou znalostí se tvorba scénářů stala poněkud náročnější, než se zprvu zdálo.

Obr. 10 - Rozhraní pro tvorbu a editaci Scénářů v EA

Většina daných scénářů obsahuje pouze základní cestu, tzv. Basic Path. Avšak některé jako například „Přihlášení“ obsahuje kvůli možným důsledkům i alternativní průběh.

Strana 24

4.2.4. Vazba případů užití na požadavky Požadavek

Odpovídající případ užití

Administrátor bude moci smazat/blokovat jiné Administrátory. Administrátor má možnost smazat/blokovat Klienta. Administrátor má možnost smazat/blokovat Řešitele Administrátor může přidávat ostatní Administrátory. Administrátor smí žádost přijmout i odmítnout. Anonymita Klientů bude zajištěna pomocí anonymního přístupového jména a hesla.

Smazání registrovaného uživatele Smazání registrovaného uživatele Smazání registrovaného uživatele Přidání nového Administrátora Potvrzení žádosti, Nepotvrzení žádosti Přihlášení

Každý úkol bude zanesen do systému

Přidání nového úkolu

Každý úkol v systému bude přiřazen do jednotlivé kategorie. Klient bude mít možnost zažádat systém o vytvoření nové kategorie. Uživatel bude mít možnost registrace a bude se moct stát Klientem. V systému bude existovat Ombudsman, který bude rozdělovat i řešit úkoly. Všichni reg. uživatelé budou mít možnost prohlížení úkolů Úkoly bude možno doplňovat ze strany Klientů Úkoly bude možno doplňovat ze strany Řešitele Úkoly bude možno třídit na splněné a nesplněné Úkoly budou i po splnění ukládány v systému. Úkoly budou přeřazovány mezi splněné až po uzavření Řešitelem

Potvrzení rozřazení Zažádání o vytvoření nové kategorie Zažádání o vytvoření nové kategorie Registrování Přidělení úkolu Řešiteli Zobrazení úkolů, Filtrování úkolů Doplnění nesplněného úkolu Doplnění nesplněného úkolu Filtrování úkolů Splnění úkolu Splnění úkolu

Úkoly budou zadávány Klienty.

Přidání úkolu

Úkoly i celé kategorie musí mít danou viditelnost pro Klienty. Řešitel bude mít možnost zažádat Administrátora o vytvoření nové kategorie

Potvrzení rozřazení, Zažádání o vytvoření nové kategorie Zažádání o vytvoření nové kategorie

Tabulka 1 - požadavky a jim přiřazené případy užití

Strana 25

Jak už bylo řečeno výše, analýza USE CASE je tvořena na základě analýza hlavně funkčních požadavků. Správně by měl každému případu užití odpovídat minimálně jeden požadavek a opačně. Nejpřehledněji je tato návaznost vidět v předcházející tabulce.

4.3.Analýza analytických tříd Analytické třídy začali vznikat jako třetí velký segment v rámci analýzy AIP, diagramy této části lze dohledat v příloze [A] podkapitola Analytické třídy na straně 27. Základním zdrojem informací pro analytické třídy se staly písemné informace z webových stránek [2], [3] a [4]. V knize [6] jsou analytické třídy popisovány takto: „Analytické třídy: 

reprezentují křehkou abstrakci problémové domény



by měly mapovat pojmy skutečného světa (jejich názvy by měli být podle toho pečlivě vybrány)

Za problémovou považujeme doménu, ze které vzešel první podnět pro vznik požadovaného softwarového systému (a která se tudíž stala i zdrojem aktivity spočívající ve vývoji programového díla). Nejdůležitějším aspektem analytické třídy je skutečnost, že by měla jednoznačně mapovat určitý pojem skutečného obchodního světa, jako je třeba „zákazník“, „produkt“ nebo „účet“. Toto tvrzení ovšem předpokládá zřetelnost a jednoznačnost obchodních pojmů – což je, po pravdě řešeno spíše ojedinělé. A tak objasnění nejasných a neúčelných obchodních pojmů zůstává na objektově orientovaném analytikovy, jehož úkolem je převod všech nejasností do něčeho, co se může stát základem analytické třídy. Právě proto bývá objektově orientovaná analýza velmi náročná.“ Při prvních pokusech o vytvoření analytického tříd se zde vyskytovaly třídy jako Administrátor, Řešitel a podobné. Tyto třídy se popisovaly jednotlivé uživatelské role. Avšak při dalším zkoumání problematiky a hlavně rozšiřování počtu uživatelů, bylo nutno přejít na úplně jiný model. Hlavní změnu přineslo zavedení třídy Osoba a na ni navazující Role, Pravo a Povinnost. Tato část diagramu kompletně popisuje vztah fyzických osob vůči uživatelským rolím v systému AIP. Stejně tak vystihuje zavedení jednotlivých povinností a práv pro uživatelské role. A dále dává možnost rozšíření, pokud by se někdy v budoucnu vyskytl požadavek na zvýšení počtu uživatelských rolí. Dané role v těchto analytických třídách by měli mít přímou návaznost s uživateli v kapitole 4.2.1. Aby analýza mohla postihnout i změny v jednotlivých fázích životního cyklu programu, bylo nutno zavést stavové třídy, např. StavUkolu. Další navazující krok měla být tvorba sekvenčních diagramů, tyto diagramy měli popisovat komunikaci tříd a ostatních komponent v rámci jednotlivých případů užití. Avšak po dohodě s vedoucím práce se začala práce ubírat jiným směrem. Sekvenční pojetí popisu případu užití přebraly scénáře přímo v případech užití. Posledním krokem této části analýzy bylo doplnění násobností pro jednotlivé vztahy v analytickém modelu.

Strana 26

4.4.Analýza stavových diagramů Předposlední fáze softwarové analýzy aplikace AIP se týkala stavových diagramů. Tyto diagramy a jejich popisy je možno najít v dokumentaci, tzn. v příloze [A] v kapitole Stavové diagramy, strana 42. Tyto diagramy reprezentují tzv. diagramy stavových automatů. Definice diagramu stavového automatu podle knihy [6]: „Diagram stavového automatu obsahuje přesně jeden stavový automat pro jeden reaktivní objekt.“ Stavové diagramy aplikace AIP vznikly jako reakce na zavedení stavových tříd v modelu analytických tříd. Pro každou stavovou třídu existuje jeden i více stavových diagramů, popisující její vývoj v rámci celé aplikace v návaznosti na různé uživatelské role, situace atd. První větší komplikací bylo zavedení administrátorského účtu do aplikace. A proto byl stavový diagram popisující vývoj administrátorského účtu rozštěpen na dva. Na popis účtu prvotního, tj. defaultního. A následně i na účet přidaný. Tyto dva je možno najít v dokumentaci v příloze [A] na stránkách 42 a 46. Stavové diagramy ostatních účtů se ukázaly poměrně triviální. Zřejmě nejpodstatnější komplikací při tvorbě stavových diagramů se ukázal diagram hlavní informační jednotky celého systému AIP, a to Úkolu. Původní myšlenka Úkolu byla asi takováto: Klient zadá Úkol do aplikace, ten se přiřadí do kategorie a podle toho bude řešen. Ale vzhledem k tomu, že kategorie mohou počínat „neuklizeným chodníkem“ a končit „pokusem o podplacení úředníka“, byla tato cesta zavrhnuta. Jako další řešení se nabízelo rozdělování kategorií přímo pomocí Řešitelů. I tato verze měla bohužel zádrhel. Ukázalo se, že pokud by Řešitelé nechtěli přijmout daný úkol, mohli by ho přeřadit do jiné kategorie a tím teoreticky i jinému Řešiteli. Takto by mohl Úkol kolovat do nekonečna. Jako výsledným a zřejmě jediným správným řešením bylo zavedení uživatele Ombudsman, dokumentaci tohoto uživatele lze najít v příloze [A] podkapitola Uživatelé, strana 13. Ombudsman, jako nadřazený Řešitel má právo jako jediný přiřadit Úkol do jiné kategorie. Tímto krokem se eliminuje možnost přeposílání úkolu mezi Řešiteli. Stavový diagram Úkolu proto obsahuje i zásahy Ombudsmana, jeho schvalování atd. Jednotlivé stavy a elementy v těchto diagramech obsahují hrubý návrh, jak by se asi měli vyvíjet třídy stavů, jako je např. StavUctu, StavUkolu (na Obr. 11) nebo StavZadosti.

Obr. 11 - Rozhraní pro úpravu stavů ve stavových diagramech s ukázkou vývoje stavových tříd

Strana 27

4.5.Analýza diagramů aktivit Definice diagramu aktivit podle [6]: „Diagramy aktivit jsou „objektově orientovanými vývojovými diagramy“. Díky nim lze modelovat aktivitu, která se skládá z kolekce uzlů spojených hranami.“ Posledním významnější část analýzy spočívala v navržení diagramů aktivit. Dokumentace této části je uložena v příloze [A] kapitola Diagramy aktivit na straně 32. V této části byly podrobně rozebrány scénáře případů užití a ty které počítali se složitějším tokem událostí, byly podrobněji rozkresleny a popsány ještě v activity diagramu. Jako složitější a nedostatečně popsané byli shledány tyto aktivity: „prvního spuštění systému“, „registrace“ z důvodu zdůraznění ověřovací procedury a splnění požadavku na ochranu proti robotům (viz. kapitola 4.1.1. Analýza nefunkčních požadavků) a „zobrazení úkolů“ kvůli problematickému pojetí filtrování zobrazených úkolů. Toto byla poslední část tvorby analýzy. Následující kapitola popisuje tvorbu dokumentace nad daným projektem.

Strana 28

5. Tvorba dokumentace Tato kapitola je vyčleněna pro samotnou tvorbu dokumentace výše popsané analýzy. V kapitole 5.1 jsou vyobrazeny možnosti tvorby dokumentace v aplikaci Enterprise Architect. Dále, v kapitole 5.2, se práce zaměřuje na úpravy šablon a nakonec v kapitole 5.3 na úpravy tisků v MS Office Word pomocí maker.

5.1.Možnosti dokumentace Při tvorbě dokumentace pomocí programu Enterprise Architect se nabízejí 3 zcela odlišné možnosti výstupu: 

Diagram only report – pomocí dialogového okénka je možno nastavit kvalitu obrázků a další parametry. Tento report je vhodný pouze pro ukázkové účely, chybí mu jakákoli písemná dokumentace.

Obr. 12 - Rozhraní pro tvorbu Diagram Only Reportu



HTML Report – tato funkce vygeneruje rozsáhlou strukturu HTML stránek. Tato dokumentace se zdá jako nejpřehlednější. Diagramy jsou vygenerovány do stránek podobných vzhledu a ovládání programu Enterprise Architect. Generování opět probíhá přes dialogové okno, kde je možnost navolení výstupu a jiných nastavení.

Obr. 13 - Rozhraní pro tvorbu HTML Reportu

Strana 29

Tato dokumentace, zobrazena na Obr. 14, je velmi přehledná a pěkná. Avšak úplně nepoužitelná pro tisk dokumentace.

Obr. 14 - Ukázka vytvořeného HTML Reportu



Rich Text Format (RTF) Report – Tento report je nejvhodnější pro účely tištěné dokumentace, proto jsem zvolil ten to způsob. Opět při vytvoření dokumentace musíme projít dialogovým nastavovacím oknem. Staví se před nás dvě možnosti, jak zvolit formu generování. Výstupový soubor je ve formátu .RTF. 1. Switch generator – velmi rozsáhlé a komplikované tabulky nastavení výstupu. Vhodnější pro jednorázové akce.

Obr. 15 - Zobrazení Switch generatoru pro tvorbu RFT Reportu

2. Template manager – nastavení výstupu probíhá přes textový editor, tzv. Document Template Editor. Psaní šablonovacího kódů je vcelku přehledné, ale seznámení

Strana 30

s prostředím je nutnou podmínkou, protože se editor v jistých situacích chová naprosto odlišně, než je zvykem u jiných editorů textu, jako je např. MS Word. Šablona jako taková se ukládá do RTF souboru stejně jako výstup generování dokumentace.

Obr. 16 - Template manager

5.2.Tvorba template Prvním krokem při tvorbě dokumentace bylo vytvoření vhodné šablony (templatu) podle kterého generátor funguje. Jako vhodnými kandidáty se mi staly šablony z diplomové práce Ing. Mlejnka [7]. Kvůli rozsahu původního projektu bylo nutno vybranou šablonu zmenšit a upravit. Šablony použité pro generování dokumentace v aplikaci Enterprise Architect jsou založeny stejně jako výsledná dokumentace na formátu RTF od Microsoftu. Tento formát je platformě nezávislý a proto velmi často užívaný pro přenos textových dokumentů mezi jednotlivými editory. Velkou výhodou tohoto formátu je to, že způsob uložení souboru je čistě textový. Na rozdíl od většiny jiných textových formátů, které se ukládají jako binární soubory. Originální šablonu je možno najít v příloze [B]. Tato původní šablona měla pro nynější projekt několik nedostatků. Šablona Ing. Mlejnka byla použita jako průřez celým projektem a proto obsahovala parametry a bloky nejen pro analýzu. Jednoduše byla příliš složitá. Tyto bloky bylo zapotřebí najít a umazat. Dalším krokem bylo doplnění dané šablony o vypsání slovníčku pojmů, který je velmi důležitý pro každý projekt softwarového inženýrství. Jako poslední úpravu dané šablony jsem zvolil textové doplnění a vizuální vzhled templatu. K úpravám šablon jsem využil vestavěného editoru v Enterprise Architectu. Jako druhý krok jsem zvolil import správně formátovaného slovníčku pojmů a formátování výstupu jako takového do podobnosti s touto prací. Samotný způsob psaní šablony je založen, podobně jako například HTML nebo XML, na značkách, které ohraničují různé elementy diagramu, tzn. Samotné obrázky diagramů, poznámky, složky atd.. Avšak na rozdíl od HTML jsou zde otevírací a zavírací znaky použity spíše „vkročení a vykročení“ do a z různých pater složek analýzy než pro formátování. Např. otevírací značka „package >“ nám dává přístup do celého projektu. Dále se pak budeme zanořovat do diagramu, případně samotného

Strana 31

elementu, který se nachází ve složkách atd. Otevírací značky jsou označeny znakem „větší než“ (>) na konci slova, zavírací značka je označena znakem „menší než“ (<) na začátku slova. Normální neměnný text, jako jsou nadpisy případné doplňující popisky, se v těchto dokumentech píše obdobně jako Wordu. Naproti tomu proměnné jsou vyznačeny složenými závorkami a velmi často užívají tečkové notace pro přístup k jednotlivým atributům. Šablona je tvořena sestupně napříč celým projektem, kdy šablona automaticky prochází dané složky projektu a dle nastavených proměnných tiskne danou dokumentaci. Pořadí diagramů, složek, elementů je možné přeházet přímo v aplikaci Enterprise Architect, pomocí roletového menu.

Obr. 17 - Možnost přesunu elementu v rámci výtisku šablony

Grafická úprava, tvorba tabulek a vizuální stránka dané šablony a následně vygenerovaného textu je založena na klasickém formátování textu jako v aplikaci MS Word. Při tvorbě šablony se dá využít i zabudovaný „help“ aplikace EA. Tento odpovídá standardům helpů od Microsoftu. Obsahuje rejstřík, hledání, křížové odkazy a další užitečné pomůcky při nápovědě. Výslednou šablonu je možno dohledat jako přílohu [C].

5.3.Úprava vygenerového textu v MS WORD Poslední postup v tvorbě dokumentace bylo samotné upravení dokumentace v programu MS WORD. Ve vygenerované dokumentaci se objevilo několik problémů, které bylo třeba vyřešit. Prvním a nejzásadnějším bylo přebytečné množství značek „odsazení odstavce“ a „mezera“, způsobené

Strana 32

opakovaným otevíráním a zavíráním elementů v šabloně. Tyto nedostatky jsou dokumentovány na Obr. 18 - Ukázka chyb po vygenerování RTF dokumentace.

Obr. 18 - Ukázka chyb po vygenerování RTF dokumentace

Tento problém se podařilo vyřešit pomocí vhodně zvolených jednoduchých maker v MS Word. Tato makra jsou tvořeny v jazyce MS Visual Basic. Tyto makra byla tvořena pomocí tzv. „nahrávání“. Tato funkce umožňuje i při neznalosti programovacího jazyka vytvořit poměrně účelná a vhodná makra. Obsah těchto maker je uveden v příloze [D]. Samotná makra vykonávají nahrazovací proces u různých skupin znaků, tak aby zmenšili mezery mezi odstavci atd. Poslední úpravy dokumentace AIP už nutno provést ručně. Bylo nutné provést upravení obrázků do velikosti shodné s potřebným formátováním a případné přidání konců stránky ve vhodném místě. Vzhledem k tomu, že při generování dokumentace nebere Enterprise Architect v úvahu, že by mohl obrázek být větší než stránka A4, je hodně obrázků zobrazeno nekompletně nebo úplně rozhazují formátování stránek. Tuto úpravu je však záhodno udělat ručně.

Strana 33

6. Závěr Hlavní cíle stanovené v této práci byly splněny: byla vytvořena analýza BKM systému Anonymní informační portál v jazyce UML, byla vygenerována dokumentace za použití generátoru v UML nástroji. Jediným nesplněným cílem této práce bylo poskytnutí analytické podpory a dokumentace pro fázi implementace. Původně měl být systém AIP implementován třetí stranou a tato práce měla obsahovat i část popisující podporu a vazby implementace na analýzu. Avšak na tuto část se nedostalo a tak projekt AIP zůstal pouze ve formě analýzy. Dalším krokem týkajícím se vytvořené analýzy se nyní zdá implementace a tím pádem i kompletní ověření analýzy v praxi. Pokud by se podle dané analýzy podařilo systém AIP naimplementovat, jistě by analýza prodělala v průběhu implementace několik úprav, které by ovšem už neměli měnit základní stavební kameny analýzy.

Strana 34

7. Seznam tabulek Tabulka 1 - požadavky a jim přiřazené případy užití ............................................................................ 25

Strana 35

8. Seznam obrázků Obr. 1 - Logo společnosti Business Kepper AG ................................................................................. 17 Obr. 2 - Schéma produktu Business Keeper Monitoring System od firmy Business Keeper AG....... 17 Obr. 3 - Logo Městské části Praha 6 .................................................................................................... 18 Obr. 4 - Ukázka zobrazeného úkolu v aplikaci Lokální MMSing Městské části Praha 6 .................... 18 Obr. 5 - Package diagram zobrazující funkční a nefunkční požadavky z dokumentace AIP ............... 20 Obr. 6 - Ukázka funkčního požadavku týkajícího se anonymity Klienta v dokumentaci AIP ............. 21 Obr. 7 - Actors v dokumentaci AIP ...................................................................................................... 22 Obr. 8 - Diagram Primární případy užití popisující kompletní možnosti systému a uživatelů ............ 23 Obr. 9 - Výňatek z diagramu případu užití pro uživatele Administrátor s ukázkou vazeb Extend a Include ................................................................................................................................................... 24 Obr. 10 - Rozhraní pro tvorbu a editaci Scénářů v EA......................................................................... 24 Obr. 11 - Rozhraní pro úpravu stavů ve stavových diagramech s ukázkou vývoje stavových tříd ...... 27 Obr. 12 - Rozhraní pro tvorbu Diagram Only Reportu ........................................................................ 29 Obr. 13 - Rozhraní pro tvorbu HTML Reportu .................................................................................... 29 Obr. 14 - Ukázka vytvořeného HTML Reportu ................................................................................... 30 Obr. 15 - Zobrazení Switch generatoru pro tvorbu RFT Reportu ........................................................ 30 Obr. 16 - Template manager................................................................................................................. 31 Obr. 17 - Možnost přesunu elementu v rámci výtisku šablony ............................................................ 32 Obr. 18 - Ukázka chyb po vygenerování RTF dokumentace ............................................................... 33

Strana 36

9. Přílohy 9.1.Přílohy v bakalářské práci [A] – dokumentace aplikace AIP vygenerovaná programem Enterprise Architect a upravená v programu MS Office Word 2007. 63 s. [B] – původní šablona generování dokumentace z [7]. 5 s. [C] – upravená šablona použitá na generování dokumentace softwaru AIP. 5 s. [D] – kód jednoduchých maker z programu MS Office Word 2007 pro konečnou automatickou úpravu dokumentace. 2 s.

9.2.Obsah přiloženého CD Složka „bonzak“ - dokumentace projektu „Bonzák“ vypracovaném v předmětu X36SIN v letním semestru 2006/2007 Složka „prace“ - soubory této bakalářské práce Složka „prilohy“ - soubory tisknutelných příloh k této práci Složka „projekt“ – soubor projektu z Enterprise Architectu Složka „sablony“ – soubory šablon pro generování RTF dokumentace Složka „visual“ – soubor maker v Visual Basicu do MS Word 2007

Strana 37

10.

Zdroje

10.1.

Internetové stránky

[1] WIKIPEDIA.ORG. Stránka otevřené encyklopedie Wikipedia věnující se Whistleblowingu [online]. Poslední aktualizace 1. 6. 2008 [cit. 15. 4. 2008]. Dostupné z WWW: [2] BEZKORUPCE.CZ. Stránka popisující transparentní whistleblowing [online]. Poslední aktualizace 16. 5. 2006 [cit. 17. 5. 2008]. Dostupné z WWW: [3]BUSINESS KEPPER AG, webová stránka německé společnosti Bussines Kepper AG[online]. Dostupné z WWW: [4]LOKÁLNÍ MMSING MĚSTSKÉ ČÁSTI PRAHA 6, webová stránka Lokálního MMS-ingu městské části Praha 6 [online]. Poslední aktualizace 15. 4. 2008 [cit. 12. 4. 2008]. Dostupné z WWW: [5] THE STANDISH GROUP. The CHAOS Report (1994) (Zpráva CHAOS) [online]. Dostupné z WWW:

10.2.

Knihy

[6] ARLOW, Jim, NEUSTADT, Ila. UML2 a unifikovaný proces vývoje aplikací : Průvodce analýzou a návrhem objektově orientovaného softwaru. Překlad Bogdan Kiszka. 2. aktualizované a doplněné vyd. Brno : Computer Press, 2007. 567 s. ISBN 978-80-251-1503-9. [7] MLEJNEK, Jiří. Diplomová práce Informační systém pro lékaře představena v letním semestru 2007 na předmětu X36SIN oboru Výpočetní technika Fakulty Elektrotechnické Českého Vysokého Učení Technického, 2007.

Strana 38

České vysoké učení technické v Praze

Fakulta elektrotechnická

Přílohy k bakalářské práci Softwarová analýza Anonymního Informačního Portálu Software Analysis of the Anonymous Information Portal Jiří Hegmon

Vedoucí práce: Ing. Komárek Martin Studijní program: Elektrotechnika a informatika prezenční bakalářský Obor: Informatika a výpočetní technika Praha, květen 2008

Příloha A: dokumentace aplikace AIP vygenerovaná programem Enterprise Architect a upravená v programu MS Office Word 2007

Dokumentace k softwaru AIP

Strana: 1

Obsah Slovníček pojmů ........................................................................................................................................ 5 AIP ............................................................................................................................................................. 5 Požadavky ............................................................................................................................................. 6 Funkční požadavky ............................................................................................................................ 7 Administrátor bude moci smazat/blokovat jiné Administrátory. ...................................................... 7 Administrátor má možnost smazat/blokovat Klienta. ...................................................................... 7 Administrátor má možnost smazat/blokovat Řešitele ..................................................................... 8 Administrátor může přidávat ostatní Administrátory. ...................................................................... 8 Administrátor smí žádost přijmout i odmítnout. .............................................................................. 8 Anonymita Klientů bude zajištěna pomocí anonymního přístupového jména a hesla. .................. 8 Každý úkol bude zanesen do systému ........................................................................................... 8 Každý úkol v systému bude přiřazen do jednotlivé kategorie......................................................... 9 Klient bude mít možnost zažádat systém o vytvoření nové kategorie. .......................................... 9 Uživatel bude mít možnost registrace a bude se moct stát Klientem. ............................................ 9 V systému bude existovat Ombusman, který bude rozdělovat i řešit úkoly. .................................. 9 Všichni reg. uživatelé budou mít možnost prohlížení úkolů ........................................................... 9 Úkoly bude možno doplňovat ze strany Klientů ............................................................................. 9 Úkoly bude možno doplňovat ze strany Řešitele ......................................................................... 10 Úkoly bude možno třidit na splněné a nesplněné ......................................................................... 10 Úkoly budou i po splnění ukládány v systému. ............................................................................ 10 Úkoly budou přeřazovány mezi splněné až po uzavření Řešitelem ............................................. 10 Úkoly budou zadávány Klienty. .................................................................................................... 10 Úkoly i celé kategorie musí mít danou viditelnost pro Klienty. ..................................................... 10 Řešitel bude mít možnost zažádat Administrátora o vytvoření nové kategorie............................ 11 Nefunkční požadavky ....................................................................................................................... 11 Ochrana proti robotům .................................................................................................................. 11 Open Source ................................................................................................................................. 12 PHP............................................................................................................................................... 12 Po instalaci má systém jednoho "základního" Administátora ....................................................... 12 WWW ............................................................................................................................................ 12 Žádná osoba nesmí mít možnost vysledovat Klienty. .................................................................. 12 Případy užití ......................................................................................................................................... 12 Uživatelé ........................................................................................................................................... 12 Administrátor ................................................................................................................................. 13 Klient ............................................................................................................................................. 13 Ombudsman ................................................................................................................................. 13 Uživatel ......................................................................................................................................... 13 Řešitel ........................................................................................................................................... 13 Primární případy užití ....................................................................................................................... 14 Anonymní přihlášení ..................................................................................................................... 15 Doplnění nesplněného úkolu ........................................................................................................ 15 Filtrování úkolů ............................................................................................................................. 15 Informování zadávajícího ............................................................................................................. 16 Nepotvrzení žádosti ...................................................................................................................... 16 Potvrzení rozřazení....................................................................................................................... 16 Potvrzení žádosti .......................................................................................................................... 17 Přidání kategorie ........................................................................................................................... 17 Přidání nového Administrátora ..................................................................................................... 18 Přidání nového úkolu .................................................................................................................... 18 Přidání Řešitele ............................................................................................................................ 18 Přidělení úkolu Řešiteli ................................................................................................................. 19 Přihlášení ...................................................................................................................................... 19

Dokumentace k softwaru AIP

Strana: 2

Registrování .................................................................................................................................. 20 Smazání registrovaného uživatele ............................................................................................... 20 Smazání úkolu .............................................................................................................................. 20 Splnění úkolu ................................................................................................................................ 21 Zažádání o vytvoření nové kategorie ........................................................................................... 21 Zobrazení registrovaných uživatelů .............................................................................................. 21 Zobrazení úkolů ............................................................................................................................ 22 Zobrazení žádostí ......................................................................................................................... 22 Rozepsané případy užití .................................................................................................................. 23 AIP ................................................................................................................................................ 27 Analytické třídy..................................................................................................................................... 27 Doplnění ........................................................................................................................................... 28 Kategorie .......................................................................................................................................... 28 Osoba ............................................................................................................................................... 29 Ověření ............................................................................................................................................. 29 Povinnost .......................................................................................................................................... 30 Pravo ................................................................................................................................................ 30 Role .................................................................................................................................................. 30 StavUctu ........................................................................................................................................... 31 StavUkolu ......................................................................................................................................... 31 StavZadosti ...................................................................................................................................... 31 Ukol .................................................................................................................................................. 31 Zadost .............................................................................................................................................. 32 Diagramy aktivit ................................................................................................................................... 32 První spuštění .................................................................................................................................. 32 Otevření formuláře pro vytvoření Administrátora ......................................................................... 33 Otevření formuláře pro vytvoření ombudsmana ........................................................................... 33 Otevření formuláře pro vytvoření Řešitele .................................................................................... 34 Potvrzení vytvoření admina .......................................................................................................... 34 Potvrzení vytvoření ombudmana .................................................................................................. 34 Potvzení vytvoření řešitele ........................................................................................................... 34 Spuštění systému ......................................................................................................................... 34 Vyplnění formuláře pro administrátora ......................................................................................... 34 Vyplnění formuláře pro informace o systému. .............................................................................. 35 Vyplnění formuláře pro ombudsmana .......................................................................................... 35 Vyplnění formuláře pro vytvoření prvního Administrátora ............................................................ 35 Vyplnění formuláře pro řešitele ..................................................................................................... 35 Instalace dokončena ..................................................................................................................... 35 Systém spuštěn ............................................................................................................................ 35 Volba tvorby uživatele................................................................................................................... 35 Registrace ........................................................................................................................................ 36 Otevření formuláře pro registraci .................................................................................................. 37 Potvrzení vyplněných informací .................................................................................................... 38 Průchod ověřovacím systémem ................................................................................................... 38 Vyplnění formuláře........................................................................................................................ 38 Zobrazení potvrzení o registraci ................................................................................................... 38 Je formulář vyplněn správně a jednoznačně ................................................................................ 38 Potvrdilo se ověření ...................................................................................................................... 38 Registrace hotova ......................................................................................................................... 39 Registrace klienta ......................................................................................................................... 39 Zobrazení úkolů................................................................................................................................ 39 Otevření formuláře pro zadání podmínek ..................................................................................... 40 Otevření seznamu s filtrem nastaveným na všechny nesplněný ................................................. 41 Otevření seznamu s filtrem nastaveným na zobrazení všech úkolů ............................................ 41 Vyfiltrování úkolů podle podmínek ................................................................................................ 41 Filtrování ....................................................................................................................................... 41

Dokumentace k softwaru AIP

Strana: 3

Zobrazení úkolů ............................................................................................................................ 41 Zobrazení úkolů - podána žádost ................................................................................................. 41 Úkoly zobrazeny - bez filtru .......................................................................................................... 41 Stavové diagramy ................................................................................................................................ 42 Administrátorský účet - defaultní ...................................................................................................... 42 Neexistuje ..................................................................................................................................... 43 Přihlášení ...................................................................................................................................... 43 Vytvořen při spuštění systému ..................................................................................................... 44 Účet upravován............................................................................................................................. 44 Účet v provozu .............................................................................................................................. 44 Administrátorský účet - defaultní .................................................................................................. 44 Existence sytému.......................................................................................................................... 44 Ponechání ..................................................................................................................................... 44 Rozhodnutí ................................................................................................................................... 45 Spuštění ........................................................................................................................................ 45 Ucet v provozu .............................................................................................................................. 45 Učet OK ........................................................................................................................................ 45 Vytvoření ....................................................................................................................................... 45 Úprava .......................................................................................................................................... 45 Úprava .......................................................................................................................................... 45 Administrátorský účet - přidaný ........................................................................................................ 46 Neexistuje ..................................................................................................................................... 47 Učet v provozu .............................................................................................................................. 48 Účet ponechán v činnosti ............................................................................................................. 48 Účet smazán jiným administrátorem ............................................................................................ 48 Účet upraven ................................................................................................................................ 48 Účet založen jiným administrátorem............................................................................................. 48 Admin. účet - přidaný .................................................................................................................... 48 Úprava .......................................................................................................................................... 48 Účet OK ........................................................................................................................................ 49 Účet blokován ............................................................................................................................... 49 Účet smazán ................................................................................................................................. 49 Účet uložen ................................................................................................................................... 49 Klientský účet ................................................................................................................................... 49 Vytvořena žádost od uživatele ...................................................................................................... 51 Zažádáno u administrátora ........................................................................................................... 51 Účet nevytvoren ............................................................................................................................ 51 Účet smazán ................................................................................................................................. 51 Účet upraven ................................................................................................................................ 51 Účet v provozu .............................................................................................................................. 51 Klientský účet ................................................................................................................................ 52 Potvrzení žádosti .......................................................................................................................... 52 klientský účet smazán................................................................................................................... 52 Úprava účtu .................................................................................................................................. 52 Účet zamítnut................................................................................................................................ 52 Uživatelský účet ............................................................................................................................... 52 Smazán při konci aplikace ............................................................................................................ 53 V žádání o registraci ..................................................................................................................... 53 Vytvořen při otevření aplikace ...................................................................................................... 53 ucet v provozu .............................................................................................................................. 54 Uživatelský účet ............................................................................................................................ 54 zadost o registraci ......................................................................................................................... 54 Účet přesunut mezi klientské ........................................................................................................ 54 Účet ukončen ................................................................................................................................ 54 Úkol .................................................................................................................................................. 54 Ukol předán řešiteli ....................................................................................................................... 56

Dokumentace k softwaru AIP

Strana: 4

Ukol schválen ............................................................................................................................... 56 ukol neschvalen ............................................................................................................................ 56 Úkol je zadán klientem.................................................................................................................. 56 Úkol neexistuje ............................................................................................................................. 56 Úkol odpovězen ............................................................................................................................ 56 Úkol ponechán jako nazařazený .................................................................................................. 57 Úkol zařazen do kategorie ............................................................................................................ 57 Nalezení kategorie ........................................................................................................................ 57 Schvaleni ukolu resitelem ............................................................................................................. 57 Ukol smazán ................................................................................................................................. 57 Ukol uzavren ................................................................................................................................. 57 upravení ukolu .............................................................................................................................. 58 Úkol ............................................................................................................................................... 58 Řešitelský účet ................................................................................................................................. 58 Učet v provozu .............................................................................................................................. 59 Učet vytvořen administrátorem ..................................................................................................... 59 ucet smazan administrátorem ...................................................................................................... 60 Účet upravován............................................................................................................................. 60 Řešitelský účet neexistuje ............................................................................................................ 60 uprava ........................................................................................................................................... 60 učet smazán ................................................................................................................................. 60 Řešitelský účet .............................................................................................................................. 60 Žádost .............................................................................................................................................. 61 Žadost neschválena...................................................................................................................... 62 žadost předana ke schválení administrátorovi ............................................................................. 63 žadost schvalena .......................................................................................................................... 63 žadost vytvořena klientem ............................................................................................................ 63 žádost vytvorena řešitelem .......................................................................................................... 63 puvod zadosti ................................................................................................................................ 63 schvaleni ....................................................................................................................................... 63 Žádost ........................................................................................................................................... 64 žadost schvalena .......................................................................................................................... 64 žadost smazana ............................................................................................................................ 64

Dokumentace k softwaru AIP

Strana: 5

Dokumentace k softwaru AIP Slovníček pojmů . Termín Administrátor AIP Databáze Doplnění Kategorie úkolu Klient Ombudsman Osoba Požadavek Právo Registrovaný uživatel Řešitel

Role Smazání Úložiště Uživatel Žádost

Popis Registrovaný uživatel. Osoba zodpovědná za udržování systému. Zpracová žádosti jiných registovaných uživatelů. Anonymní informační systém Skladiště dat, ve kterém se ukládají úkoly. Informace kterou doplním daný úkol. Specifiký druh činnosti do které spadá úkol jako takový. Podle kategorie je určeno řešení a přidělen zodpovědný orgán. Běžný registrovaný uživatel systému, zadává úkoly, sleduje jejich plnění. Nadřízený všech řešitelů, rozděluje úkoly, může je i sám řešit Každá fyzická osoba užívající systém AIP Potřeba jedné části AIP aby jiná její část něco vykonala. Přidělená možnost, povinnost daná osobě a jednotlivým rolím. Jakýkoli uživatel který musí projít registrací, aby mohl používat AIP. Tj. Klient, Řešitel, Administrátor Registrovaný uživatel. Osoba zodpovědná za řešení úkolů, odpovídá Klientům, např. zaměstnanec městského úřadu, nebo vyšší nadřízený ve firmě. Specifikuje úlohy osoby v systému. Označení úkolu, žádosti, uživatele jako blokované, zamítnuté. Databáze nebo souborový systém. Neregistrovaný uživatel systému AIP. Prosba od Klienta nebo Řešitele k Administrátorovi, požadující změnu nebo vytvoření nové součásti systému, např. nový účet, nová kategorie atd.

AIP Diagram: AIP - (Package diagram)

obr. 1

Dokumentace k softwaru AIP

Strana: 6

Požadavky Package obsahující analýzu požadavků. Diagram: Požadavky - (Package diagram) Diagram zobrazující kompletní seznam všech požadavků.

obr. 2

Dokumentace k softwaru AIP

Strana: 7

Funkční požadavky Package obsahující funkční požadavky a jejich detaily. Diagram: Funkční požadavky - (Custom diagram) Diagram zobrazující seznam Funkčních požadavků. custom Funkční pož adavky Anonymita Klientů bude zajištěna pomocí anonymního přístupového jména a hesla.

Každý úkol bude zanesen do systému

Každý úkol v systému bude přiřazen do jednotlivé kategorie.

Úkoly budou i po splnění ukládány v systému.

Administrátor může přidávat ostatní Administrátory.

Administrátor má možnost smazat/blokovat Klienta.

Řešitel bude mít možnost zažádat Administrátora o vytvoření nové kategorie

Úkoly i celé kategorie musí mít danou viditelnost pro Klienty.

Klient bude mít možnost zažádat systém o vytvoření nové kategorie.

Všichni reg. uživatelé budou mít možnost prohlížení úkolů

Administrátor smí žádost přijmout i odmítnout. V systému bude existovat Ombusman, který bude rozdělovat i řešit úkoly.

Úkoly bude možno doplňovat ze strany Řešitele

Administrátor bude moci smazat/blokovat jiné Administrátory.

Úkoly bude možno třidit na splněné a nesplněné

Administrátor má možnost smazat/blokovat Řešitele

Uživatel bude mít možnost registrace a bude se moct stát Klientem.

Úkoly bude možno doplňovat ze strany Klientů Úkoly budou zadávány Klienty.

Úkoly budou přeřazovány mezi splněné až po uzavření Řešitelem

obr. 3

Administrátor bude moci smazat/blokovat jiné Administrátory. Typ: Package:

Requirement Funkční požadavky

Pokud se Administrátor bude chovat nevhodně nebo už nevykazuje činnost, bude mít možnost Aministrátor jiný účet smazat/blokovat. Odpovídající případ užití - smazání registrovaného uživatele

Administrátor má možnost smazat/blokovat Klienta. Typ: Package:

Requirement Funkční požadavky

Pokud se některý z Klientů chová nevhodně nebo pokud už nevykazuje činnost, může ho Administrátor vymazat ze

Dokumentace k softwaru AIP

Strana: 8

systému. Odpovídající případ užití - smazání registrovaného uživatele

Administrátor má možnost smazat/blokovat Řešitele Typ: Package:

Requirement Funkční požadavky

Pokud se některý z Řešitelů už nevykazuje činnost, může ho Administrátor vymazat ze systému. Odpovídající případ užití - smazání registrovaného uživatele

Administrátor může přidávat ostatní Administrátory. Typ: Package:

Requirement Funkční požadavky

Administrátor bude mít možnost přidat dalšího Administrátora, pokud bude systém spravován více než jedním Administrátorem. Odpovídající případ užití - Přidání nového Administrátora

Administrátor smí žádost přijmout i odmítnout. Typ: Package:

Requirement Funkční požadavky

Pokud se Administrátorovi nebude zamlouvat jakákoli žádost, bude mít oprávnění tuto možnost, po zadání důvodu, zamítnout. Pokud Administrátorovi přijde žádost vhodná potvrdí ji a spracuje. Odpovídající případ užití - Potvrzení žádsoti, Nepotvrzení žádosti

Anonymita Klientů bude zajištěna pomocí anonymního přístupového jména a hesla. Typ: Package:

Requirement Funkční požadavky

Každy Klient bude povinen mít přístupové jméno a heslo. Tyto údaje jsou neveřejné a přístup k nim spadá pouze Klientovi. Odpovídající případ užití - Přihlášení.

Každý úkol bude zanesen do systému Typ: Package:

Requirement Funkční požadavky

Po zapsání úkolu Klientem je zanesen do databáze. Nemůže se stát , že kKlient zadá úkol a ten je bez záznamu vymazán nebo ztracen. I při formálním mazání úkolu je úkol přesunut do záložního úložiště. Odpovídající případ užití - přidání úkolu

Dokumentace k softwaru AIP

Strana: 9

Každý úkol v systému bude přiřazen do jednotlivé kategorie. Typ: Package:

Requirement Funkční požadavky

Úkoly budou spadat do kategorií, ty budou určovat způsob řešení případně vhodného Řešitele. Odpovídající případ užití - přidání nového úkolu

Klient bude mít možnost zažádat systém o vytvoření nové kategorie. Typ: Package:

Requirement Funkční požadavky

Pokud Klient vytvoří úkol, ketrý nepasuje do žádné z kategorií, bude moct požádat o vytvoření nové kategorie. Odpovídající případ užití - zažádání o vytvoření nové kategorie

Uživatel bude mít možnost registrace a bude se moct stát Klientem. Typ: Package:

Requirement Funkční požadavky

Uživatel bude mít pouze omezená práva, pro zvýšení svých práv se bude muset registrovat a stát se Klientem. Odpovídající případ užití - Registrování

V systému bude existovat Ombusman, který bude rozdělovat i řešit úkoly. Typ: Package:

Requirement Funkční požadavky

AIP bude kromě Řešitelů obsluhovat i Ombudsman, nadřízený Řešitelů. Bude mít práva Řešitelů, avšak navíc bude moci rozřazovat příchozí úkoly. odpovídající případ užití - Přidělení úkolu Řešiteli

Všichni reg. uživatelé budou mít možnost prohlížení úkolů Typ: Package:

Requirement Funkční požadavky

Každý registrovaný uživatel bude mít možnost prohlížení úkolů, se kterými budou pracovat. Odpovídající případ užití - Zobrazení úkolů, Filtrování úkolů

Úkoly bude možno doplňovat ze strany Klientů Typ: Package:

Requirement Funkční požadavky

Pokud zjistí Klient nějaké doplňují informace k úkolu, bude mít možnost úkol doplnit. Odpovídající případ užití - Doplnění nesplněného úkolu

Dokumentace k softwaru AIP

Strana: 10

Úkoly bude možno doplňovat ze strany Řešitele Typ: Package:

Requirement Funkční požadavky

Každý Řešitel bude mít možnost k přiděleným úkolům přidávat poznámky a postupně je upravovat a dořešovat. Odpovídající případ užití - Doplnění nesplněného úkolu

Úkoly bude možno třidit na splněné a nesplněné Typ: Package:

Requirement Funkční požadavky

AIP bude poskytovat nástroje pro třídění a zobrazování přehledných seznamů. Všechyn osoby budou mít možnost třídit úkoly podle toho, které úkoly je přesně zajímají. Use Case - Filtrování úkolů

Úkoly budou i po splnění ukládány v systému. Typ: Package:

Requirement Funkční požadavky

Po splnění úkolu se úkol nesmaže, ale zapíše se do databáze splněných úkolů. Odpovídající případ užití - splnění úkolu

Úkoly budou přeřazovány mezi splněné až po uzavření Řešitelem Typ: Package:

Requirement Funkční požadavky

Po splnění úkolu se úkol přeřadí do databáze splněných úkolů. Odpovídající případ užití - Splnění úkolu

Úkoly budou zadávány Klienty. Typ: Package:

Requirement Funkční požadavky

Hlavním účelem Klientů bude zadávání úkolů pro Řešitele. Odpovídající případ užití - Přidání úkolu

Úkoly i celé kategorie musí mít danou viditelnost pro Klienty. Typ:

Requirement

Dokumentace k softwaru AIP

Package:

Strana: 11

Funkční požadavky

Pokud daná kategorie nebo úkol nemá být viděn, musí být nastavená viditelnost.

Řešitel bude mít možnost zažádat Administrátora o vytvoření nové kategorie Typ: Package:

Requirement Funkční požadavky

Pokud se objeví úkol, který je nezařaditelná do žádné kategorie, bude mít možnost Řešitel zažádat o vytvoření kategorie. Odpovídající případ užití - Zažádání o vytvoření nové kategorie

Nefunkční požadavky Package obsahující nefunkční požadavky a jejich detaily. Diagram: Nefunkční požadavky - (Custom diagram) Diagram zobrazující Nefunkční požadavky systému AIP. custom Nefunkční pož adavky PHP Žádná osoba nesmí mít možnost vysledovat Klienty.

Open Source

Ochrana proti robotům

Po instalaci má systém jednoho "základního" Administátora

WWW

obr. 4

Ochrana proti robotům Typ: Package:

Requirement Nefunkční požadavky

AIP bude ochráněno proti robotům.

Dokumentace k softwaru AIP

Strana: 12

Open Source Typ: Package:

Requirement Nefunkční požadavky

Základem AIP jsou open-sourcové programy.

PHP Typ: Package:

Requirement Nefunkční požadavky

AIP je napsán v jazyce PHP.

Po instalaci má systém jednoho "základního" Administátora Typ: Package:

Requirement Nefunkční požadavky

Poinstalaci systému bude v existovat pouze jeden Administrátor, ten se postará o vytvoření ostatních uživatelů.

WWW Typ: Package:

Requirement Nefunkční požadavky

AIP bude zprostředkováno pomocí webového rozhraní.

Žádná osoba nesmí mít možnost vysledovat Klienty. Typ: Package:

Requirement Nefunkční požadavky

Klient nesmí zadávat jakékoli vysledovatelné informace a musí být bráněno, aby byl vysledovatený.

Případy užití Package obsahující případy užitía jejich detaily.

Uživatelé Package obsahující analýzu uživatelů a jejich detaily. Diagram: Uživatelé - (Package diagram) Zobrazení seznamu a dědičností mezi uživateli.

Dokumentace k softwaru AIP

Strana: 13

pkg Uživ atelé

Uživ atel

Klient

Řešitel

Ombudsman

Administrátor

obr. 5

Administrátor Typ: Package:

Actor Uživatelé

Role uživatele Administrátor obsluhuje AIP, nestará se o plnění úkolů, pouze kontroluje činnost AIP a administruje uživatele, žádosti atd.

Klient Typ: Package:

Actor Uživatelé

Klient je registrovaný náštěvník AIP s zvláštním právem přidávání úkolů.

Ombudsman Typ: Package:

Actor Uživatelé

Ombudsman je nadřízený všech řešitelů, má stejné povinnosti a práva. Navíc ještě musí rozřazovat úkoly pro řešitele.

Uživatel Typ: Package:

Actor Uživatelé

Neregistrovaný uživatel, má možnost pouze prohlížení záznamů.

Řešitel Typ: Package:

Actor Uživatelé

Osoba s rolí Řešitel řeší úkoly zadané Klient.

Dokumentace k softwaru AIP

Strana: 14

Primární případy užití Package obsahující diagram popisující kompletní USE CASE pro celý projekt. Diagram: Primární případy užití - (Use Case diagram) Kompletní zobrazení všech případů užití a všech uživatelů. uc Primární případy užití

AIP Nepotv rzení žádosti Klient Administrátor

(from Uživatelé)

Zobrazení registrov aných uživ atelů

(from Uživatelé) Potv rzení žádosti

Přidání nov ého úkolu Přidání kategorie

Přidání Řešitele

Zobrazení úkolů

Zažádání o v ytv oření nov é kategorie Zobrazení žádostí Přidání nov ého Administrátora

Přihlášení

Smazání registrov aného uživ atele

Informov ání zadáv aj ícího

Filtrov ání úkolů Anonymní přihlášení Smazání úkolu

Doplnění nesplněného úkolu

Potv rzení rozřazení Registrov ání

Uživ atel (from Uživatelé)

Splnění úkolu Řešitel Přidělení úkolu Řešiteli

(from Uživatelé)

Ombudsman (from Uživatelé)

obr. 6

Dokumentace k softwaru AIP

Strana: 15

Anonymní přihlášení Typ: Package:

UseCase Primární případy užití

Standardní přihlášení neregistrovaného uživatele, v podstatě nejde o přihlášení, ale o pouhé připojení na stránky AIP.

Scénáře  Anonymní přihlášení Basic Path 1. Uživatel otevře aplikaci AIP. 2. Systém zobrazí úvodní obrazovku uživatele

Doplnění nesplněného úkolu Typ: Package:

UseCase Primární případy užití

Každý Klient nebo Řešitel bude doplňovat úkoly pomocí dopisování dalších informací.

Scénáře  Doplnění nesplněného úkolu Basic Path 1. Řešitel/Klient vybere nesplněný úkol. 2. Systém zobrazí podrobné informace o úkolu. 3. Řešitel/Klient zažádá o doplnění úkolu. 4. Systém zobrazí formulář pro dopnění úkolu. 5. Řešitel/Klient doplní potřebné informace o úkolu. 6. Řešitel/Klient potvrdí zadané informace. 7. Systém zobrazí potvrzení o přidání informací.

Filtrování úkolů Typ: Package:

UseCase Primární případy užití

Při zobrazování úkolů bude možnost úkoly vyfiltrovat a rozfiltrovat podle jednotlivých podmínek.

Scénáře  Filtrování úkolů Basic Path 1. Osoba zadá požadavek o zobrazení vyfiltrovaných úkolů. 2. Systém otevře formulář pro filtrování úkolů. 3. Osoba vyplní filtrovací podmínky. 4. Systém zobrazí úkoly splňující podmínky zadané uživatelem.

Dokumentace k softwaru AIP

Strana: 16

Informování zadávajícího Typ: Package:

UseCase Primární případy užití

Po provedení změn na žádosti nebo na úkolu bude zadávající informován.

Scénáře  Informování zadávajícího Basic Path 1. Systém zobrazí informace o změně žádosti cílovému reg. uživateli po jeho přihlášení na uvítací obrazovce.

Nepotvrzení žádosti Typ: Package:

UseCase Primární případy užití

Podaná žádost od Řešitele nebo Klienta nemusí být nutně potvrzena.

Scénáře  Nepotvrzení žádosti Basic Path 1. Administrátor si nechá zobrazit žádosti. 2. Systém zobrazí žádosti. 3. Administrátor si vybere žádost, kterou chce zamítnout. 4. Systém zobrazí podrobné informace o žádosti. 5. Administrátor vybere možnost zamítnutí žádosti. 6. Systém zobrazí formulář pro důvod zamítnutí. 7. Administrátor zadá důvod zamítnutí. 8. Administrátor potvrdí zamítnutí. 9. Systém zobrazí potvrzení zamítnutí.

Potvrzení rozřazení Typ: Package:

UseCase Primární případy užití

Řešitel je povinen po přiřazení úkolu, tento úkol potvrdit.

Scénáře  Potvrzení rozřazení - přijetí Basic Path 1. Systém zobrazí po přihlášení na uvítací obrazovce seznam přiřazených úkolů. 2. Řešitel vybere úkol k potvrzení. 3. Systém zobrazí podrobnosti o úkolu a jeho přidělenou kategorii. 4. Řešitel potvrdí úkol. 5. Systém uloží úkol mezi nesplněné.

Dokumentace k softwaru AIP

Strana: 17

Scénáře  Potvrzení rozřazení - nepřijetí Alternate 1. Systém zobrazí po přihlášení na uvítací obrazovce seznam přiřazených úkolů. 2. Řešitel vybere úkol k potvrzení. 3. Systém zobrazí podrobnosti o úkolu a jeho přidělenou kategorii. 4. Řešitel nepotvrdí úkol a kategorii. 5. Řešitel vybere novou kategorii. 6. Systém přiřadí novou kategorii. 7. Systém uloží úkol mezi nesplněné

Potvrzení žádosti Typ: Package:

UseCase Primární případy užití

Pokud se Administrátorovi žádost zamlouvá, může ji potvrdit.

Scénáře  Potvrzení žádosti Basic Path 1. Administrátor si nechá zobrazit žádosti. 2. Systém zobrazí žádosti. 3. Administrátor s vybere žádost, kterou chce potvrdit. 4. Systém zobrazí podrobné informace o žádosti. 5. Administrátor vybere možnost potvrzení žádosti. 6. Administrátor potvrdí žádost. 7. Systém zobrazí potvrzení žádosti.

Přidání kategorie Typ: Package:

UseCase Primární případy užití

Pokud je obsahem žádosti vytvoření nové kategorie a žádost je schválena, tak Administrátor vytvoří novou kategorii odpovídající žádosti.

Scénáře  Přidání kategorie Basic Path 1. Administrátor zadá požadavek o zadání nové kategorie 2. Systém zobrazí formulář pro zadání údajů o kategorii. 3. Administrátor vyplní údaje o kategorii. 4. Administrátor potvrdí vyplněné informace. 5. Systém zobrazí potvrzení o přidání kategorie

Dokumentace k softwaru AIP

Přidání nového Administrátora Typ: Package:

UseCase Primární případy užití

Administrátor má možnost přidat jiného Administrátora.

Scénáře  Přidání nového Administrátora Basic Path 1. Administrátor zažádá o přidání nového Administrátora. 2. Systém zobrazí formulář pro přidání nového Administrátora. 3. Administrátor vyplní údaje nového Administrátora. 4. Administrátor potvrdí vyplněné údaje. 5. Systém zobrazí potvrzení o přidání nového Administrátora.

Přidání nového úkolu Typ: Package:

UseCase Primární případy užití

Klientův základní čin je přidávání úkolu, tj. informací od prohřešků.

Scénáře  Přidání nového úkolu Basic Path 1. Klient zadá požadavek na přidání nového úkolu. 2. Systém otevře formulář s údaji o novém úkolu. 3. Klient vyplní údaje o novém úkolu. 4. Klient potvrdí vyplněné údaje. 5. Systém zobrazí potvrzení přidání úkolu. 6. Ombudsman přiřadí úkolu Řešitele.

Přidání Řešitele Typ: Package:

UseCase Primární případy užití

Přidání dalšího Řešitele do systému. Scénáře  Přidání Řešitele Basic Path 1. Administrátor zadá požadavek o zadání nového Řešitele 2. Systém zobrazí formulář pro zadání registračních údajů Řešitele. 3. Administrátor vyplní registrační údaje Řešitele. 4. Administrátor potvrdí zadané údaje. 5. Systém zobrazí potvrzení o přidání Řešitele

Strana: 18

Dokumentace k softwaru AIP

Strana: 19

Přidělení úkolu Řešiteli Typ: Package:

UseCase Primární případy užití

Ombudsman rozděluje úkoly daným řešitelům Scénáře  Přidělení úkolu Řešiteli Basic Path 1. Úkol je zobrazen Ombudsmanovi. 2. Ombudsman zvolí Řešitele odpovídající kategorie. 3. Ombudsman potvrdí zadané údaje. 4. Systém zobrazí potvrzení o přiřazení úkolu danému Řešiteli.  Přidělení úkolu Řešiteli - Řešení Alternate 1. Úkol je zobrazen Ombudsmanovi. 2. Ombudsman se rozhodne řešit úkol sám. 3. Ombudsman přiřadí úkol sám sobě. 4. Ombudsman potvrdí zadané údaje. 5. Systém zobrazí potvrzení o přiřazení úkolu Ombudsmanovi.

Přihlášení Typ: Package:

UseCase Primární případy užití

Každý Registrovaný uživatel musí při příchodu do AIP projít přihlášením, které urči jeho roli a práva. Scénáře  Přihlášení - přijetí Basic Path 1. Reg. uživatel zadá požadavek na přihlášení 2. Systém otevře formulář pro zadání přihlašovacích údajů. 3. Reg. uživatel zadá přihlašovací údaje. 4. Reg. uživatel potvrdí údaje. 5. Systém ověřuje údaje. 6. Reg. uživatel je vpuštěn do AIP, pokud je ověření platné. Systém zobrazí úvodní obrazovku pro daného reg. uživatele.  Přihlášení - nepřijetí Alternate 1. Reg. uživatel zadá požadavek na přihlášení 2. Systém otevře formulář pro zadání přihlašovacích údajů. 3. Reg. uživatel zadá přihlašovací údaje. 4. Reg. uživatel potvrdí údaje. 5. Systém ověřuje údaje. 6. Reg. uživatel není vpuštěn do AIP, protože je ověření neplatné. Systém zobrazí informaci o neplatném přihlášení.

Dokumentace k softwaru AIP

Strana: 20

Registrování Typ: Package:

UseCase Primární případy užití

Pokud chce Uživatel zvětšit své práva, zvláště přidávat úkoly, musí projít registrací. Scénáře  Registrování Basic Path 1. Uživatel zadá požadavek o registraci. 2. Systém otevře formulář pro registraci. 3. Uživatel vyplní potřebné údaje pro registraci. 4. Uživatel ukončí a odešle registrační žádost. 5. Systém odešle tuto žádost Administrátorovi.

Smazání registrovaného uživatele Typ: Package:

UseCase Primární případy užití

Pokud Administrátor uváží, že některý reg. uživatel by měl být smazán , může ho označit blokovat/smazat. Scénáře  Smazání reg.uživatele Basic Path 1. Administrátor vybere reg. uživatele k smazání. 2. Systém vypíše podrobné informace o uživateli. 3. Administrátor označí uživatele jako smazaného. 4. Systém otevře formulář k podání vysvětlení o smazání. 5. Administrátor vyplní důvod smazání. 6. Administrátor potvrdí smazání. 7.Sstém zobrazí informaci o smazání reg. uživatele.

Smazání úkolu Typ: Package:

UseCase Primární případy užití

Pokud je úkol nesmyslný nebo nesplnitelný, může být označen jako smazaný/blokovaný. Scénáře  Smazání úkolu Basic Path 1. Administrátor/Řešitel vybere nesplněný úkol, který chce smazat. 2. Systém zobrazí podrobné údaje pro daný úkol. 3. Administrátor/Řešitel vybere možnost smazání úkolu. 4. Systém se zeptá na potvrzení smazaní úkolu. 5. Administrátor/Řešitel potvrdí smazání. 6. Systém zobrazí potvrzení o smazání.

Dokumentace k softwaru AIP

Splnění úkolu Typ: Package:

UseCase Primární případy užití

Po vyřešení úkolu zanese Řešitel do systému potřebné informace a "úkol splní". Scénáře  Splnění úkolu Basic Path 1. Řešitel vybere nesplněný úkol, který chce řešit. 2. Systém zobrazí podrobné údaje pro daný úkol. 3. Řešitel vybere možnost uzavření úkolu. 4. Systém otevře formulář pro doplnění úkolu. 5. Řešitel doplní informace, případné dokumenty, fotografie. 6. Systém se zeptá na potvrzení uzavření úkolu. 7. Řešitel potvrdí uzavření. 8. Systém uzavře úkol a přesune jej do uzavřených. 9. Systém zobrazí potvrzení splnění úkolu.

Zažádání o vytvoření nové kategorie Typ: Package:

UseCase Primární případy užití

Pokud se úkol nedá zařadit do žádné kategorie, je třeba zažádat o vytvoření nové kategorie. Scénáře  Zažádání o vytvoření nové kategorie Basic Path 1. Reg. uživatel/Klient zažádá o vytvoření nové kategorie. 2. Systém otevře formulář pro vytvoření nové kategorie. 3. Reg. uživatel/Klient vyplní údaje nové kategorie. 4. Reg. uživatel/Klient potvrdí žádanku. 5. Žádost se přesune Administrátorovi. 6. Systém zobrazí potvrzení o vytvoření žádosti.

Zobrazení registrovaných uživatelů Typ: Package:

UseCase Primární případy užití

Administrátor potřebuje k administraci uživatelů zobrazení všech reg. uživatelů. Scénáře  Zobrazení registrovaných uživatelů Basic Path 1. Administrátor zadá požadavek o zobrazení registrovaných uživatelů. 2. Systém zobrazí formulář pro vyplnění podmínek uživatelů. 3. Administrátor vyplní podmínky filtrování uživatelů 4. Systém zobrazí pouze ty uživatele, kteří splňují dané podmínky.

Strana: 21

Dokumentace k softwaru AIP

Zobrazení úkolů Typ: Package:

UseCase Primární případy užití

Každá osoba má možnost zobrazení úkolu bez filtrace. Scénáře  Zobrazení úkolů Basic Path 1. Osoba zadá požadavek na zobrazení úkolů. 2. Osoba potvrdí zadané podmínky. 3. Systém zobrazí úkoly. <extend> filtrování úkolů

Zobrazení žádostí Typ: Package:

UseCase Primární případy užití

Administrátor k administraci potřebuje, aby mohl zobrazovat všechny žádosti. Scénáře  Zobrazení žádostí Basic Path 1. Administrátor zadá požadavek o zobrazení žádostí. 2. Systém zobrazí formulář pro filtrování žádostí. 3. Administrátor vyplní filtrovací podmínky. 4. Systém zobrazí žádosti splňující podmínky.

Strana: 22

Dokumentace k softwaru AIP

Strana: 23

Rozepsané případy užití Package obsahující diagramy popisující USE CASE pro jednotlivé uživatele. Diagram: Případy užití - Ombudsman - (Use Case diagram) Detailní zobrazení případů užití uživatele Ombudsman uc Případy užití - Ombudsman AIP

Přidělení úkolu Řešiteli

Ombudsman

obr. 7

Dokumentace k softwaru AIP

Strana: 24

Diagram: Případy užití - Administrátor - (Use Case diagram) Detailní zobrazení případů užití uživatele Administrátor. uc Případy užití - Administrátor AIP

Zobrazení úkolů

Smazání úkolu

«extend» Administrátor Přihlášení Filtrov ání úkolů

Potv rzení žádosti Zobrazení žádostí

Smazání registrov aného uživ atele Informov ání zadáv aj ícího

Nepotv rzení žádosti

Zobrazení registrov aných uživ atelů

Přidání Řešitele

Přidání nov ého Administrátora

obr. 8 Diagram: Příklady užití - Klient - (Use Case diagram) Diagram USECASE zobrazující návaznosti případů užití osoby s rolí Klient .

Dokumentace k softwaru AIP

Strana: 25

uc Příklady užití - Klient AIP

Přihlášení

Přidání nov ého úkolu

Filtrov ání úkolů

Klient

«extend»

Zobrazení úkolů

Doplnění nesplněného úkolu Zažádání o v ytv oření nov é kategorie

obr. 9

Dokumentace k softwaru AIP

Strana: 26

Diagram: Případy užití - Řešitel - (Use Case diagram) Detailní zobrazení případů užití uživatele Řešitel uc Případy užití - Řešitel AIP

Přihlášení Zažádání o v ytv oření nov é kategorie Splnění úkolu

Filtrov ání úkolů

«extend» Řešitel Zobrazení úkolů Doplnění nesplněného úkolu

Informov ání zadáv aj ícího

Smazání úkolu

Potv rzení rozřazení

obr. 10

Dokumentace k softwaru AIP

Strana: 27

Diagram: Případy užití - Uživatel - (Use Case diagram) Detailní zobrazení případů užití uživatele Uživatel. uc Případy užití - Uživ atel AIP Zobrazení úkolů «extend»

Anonymní přihlášení Uživ atel

Registrov ání

obr. 11

AIP Typ: Package:

Boundary Rozepsané případy užití

Analytické třídy Package obsahující analytické třídy, popisující jejich vztahy a detaily. Diagram: Analytické třídy - (Logical diagram) Diagram popisující analytické vztahy mezi objekty v AIP.

Filtrov ání úkolů

Dokumentace k softwaru AIP

Strana: 28

class Analytické třídy

Stav Uctu -

nazev: string

Ukol

Osoba -

identifikacni_cislo: int jmeno: String Login: Sting password: String Pracovni_zarazeni: int Prijmeni: String

-

Stav Ukolu

DatumPřijetí: date DatumSplneni: date odpovedNaUkol: Doplnění ResitelUkolu: Řešitel textUkolu: String Viditelnost: int

-

nazev_Stavu_ukolu: String

Doplnění -

textDoplneni: String

Prav o -

Kategorie -

Nazev_prava: String zadani_prava: String

kodKategorie: int nazevKategorie: String viditelnost: int

Role -

id_role: int Nazev_role: String

Pov innost -

NázevPovinnosti: String PopisPovinnosti: String

Stav Zadosti

Zadost -

datumSplneniZadosti: date datuZadaniZadosti: date textZadosti: String

-

nazev_stavu_zadosti: String

obr. 12

Doplnění Typ: Package:

Class Analytické třídy

Doplnění je způsob vazby Řešitele s úkolem. Řešitel produkuje doplnění při řešení úkolů. Doplnění může vytvořit i Klient pokud doplní úkol o další informace. Atributy Atribut

Poznámka

textDoplneni String Private

Constraints and tags Default:

Kategorie Typ: Package:

Class Analytické třídy

Kategorie určuje oblast problému. Atributy Atribut kodKategorie int Private nazevKategorie String

Poznámka

Constraints and tags

specifický kód kategorie

Default:

Default:

Dokumentace k softwaru AIP

Poznámka

Atribut

Strana: 29

Constraints and tags

Private viditelnost int Private

Default:

Osoba Typ: Package:

Class Analytické třídy

Osoba specifikuje jakoukoli fyzickou osobu užívající systém. Atributy Atribut

Poznámka

Constraints and tags

identifikacni_cislo int Private

každý reg. uživatel bude mít přiřazeno id. číslo. Default:

jmeno String Private

křestní jmeno uživatele povinne pro: Admin., Řešitel

Default:

Login Sting Private

prihlasovaci jmeno uzivatele povinne pro:klient, Admin, resitel

Default:

password String Private

heslo Povinne pro : Admin, Resitel, Klient

Default:

Pracovni_zarazeni int Private

pracovní zařazení daného Administrátora nebo Řešitele.

Default:

Prijmeni String Private

Prijmeni uzivatele Povinne pro: Admin, Resitel

Default:

Ověření Typ: Package:

Class Analytické třídy

Ověření provádí systém při každém přihlášení do systému. Atributy Atribut pořadovéČislo int Private

Operations Method vydejOvěření() void Public False

Poznámka

Constraints and tags

pořadové číslo ověření

Default:

Notes

Parameters Klient klient [in]

Dokumentace k softwaru AIP

Method {Meth.IsQuery}

Notes

Strana: 30

Parameters

Povinnost Typ: Package:

Class Analytické třídy

Povinnost definuje co daná role "musí" a zároveň "nesmí".

Atributy Atribut

Poznámka

Constraints and tags

NázevPovinnosti String Private

jednoduchý název povinnosti

Default:

PopisPovinnosti String Private

popis povinnosti

Default:

Pravo Typ: Package:

Class Analytické třídy

Právo definuje co daná role "může".

Atributy Atribut

Poznámka

Constraints and tags

Nazev_prava String Private

nazev prava oznacujici jeho funkci

Default:

zadani_prava String Private

v zadani je obsazeno co pravo sprostředkovava a co omezuje

Default:

Role Typ: Package:

Class Analytické třídy

Role specifikuje úlohy osoby v systému. Každé roli odpovídá určitá sada práv a povinností, které může nebo musí osoba využívat. Atributy Atribut

Poznámka

id_role int Private Nazev_role String

Constraints and tags Default:

nazev role uzivatele v systemu

Default:

Dokumentace k softwaru AIP

Poznámka

Atribut

Strana: 31

Constraints and tags

Private předpokladané 4 role: Administrator, Řešitel, Klient, Uživatel každa role ma přidelené prava

StavUctu Typ: Package:

Class Analytické třídy

StavUctu popisuje v jakém stavu je daný uživatelský účet. Atributy Atribut

Poznámka

nazev string Private

Constraints and tags Default:

StavUkolu Typ: Package:

Class Analytické třídy

Tato třída definuje, v jakém stavu se zrovna nachází úkol. Atributy Atribut

Poznámka

nazev_Stavu_ukolu String popisuje v jakém stavu se účet nalézá Private

Constraints and tags Default:

StavZadosti Typ: Package:

Class Analytické třídy

Tato analytická třída ukazuje v jakém stavu je daná žádost. Atributy Atribut nazev_stavu_zadosti String Private

Poznámka

Constraints and tags

odpovida stavu ve kterem je zadost

Default:

Ukol Typ: Package:

Class Analytické třídy

Dokumentace k softwaru AIP

Strana: 32

Úkol je základní informační jednotka celého systému, je zadávána Klienty a řešena Řešiteli.

Atributy Atribut

Poznámka

Constraints and tags

DatumPřijetí date Private

datum kdy byl úkol zadán

Default:

DatumSplneni date Private

datum splnění úkolu

Default:

odpovedNaUkol Doplnění odpověd na daný úkol Private

Default:

ResitelUkolu Řešitel Private

řešitel pod kterho spadá řešení daného úkolu

Default:

textUkolu String Private

zadani ukolu od klienta

Default:

Viditelnost int Private

Default:

Zadost Typ: Package:

Class Analytické třídy

Třída označující požadavky od Klientů a Řešitelů Atributy Atribut

Poznámka

Constraints and tags

datumSplneniZadosti date Private datuZadaniZadosti date Private

Default:

textZadosti String Private

Default:

Default:

Diagramy aktivit Package obsahující diagramy aktivit popisující první spuštění systému, registraci uživatele a zobrazení úkolů.

První spuštění Diagram: První spuštění - (Activity diagram) Diagram popisuje první spuštění systému do plného nasazení.

Dokumentace k softwaru AIP

Strana: 33

act Prv ní spuštění Instalace dokončena

Spuštění systému

Vyplnění formuláře pro v ytv oření prv ního Administrátora

Vyplnění formuláře pro informace o systému.

Volba tvorby uživatele [Žádný další uživatel k vytvoření] [vytvoření ombudsmana]

Otev ření formuláře pro v ytv oření ombudsmana

Vyplnění formuláře pro ombudsmana

Potv rzení v ytv oření ombudmana

[vytvoření ombudsmana]

Systém spuštěn

[vytvoření řešitele]

Otev ření formuláře pro v ytv oření Řešitele

Vyplnění formuláře pro řešitele

Potv zení v ytv oření řešitele

Otev ření formuláře pro v ytv oření Administrátora

Vyplnění formuláře pro administrátora

Potv rzení v ytv oření admina

obr. 13

Otevření formuláře pro vytvoření Administrátora Typ: Package:

Activity První spuštění

Prvním krokem pro vytvoření administrátora je otevření formuláře pro vyplnění všech potřebných informací.

Otevření formuláře pro vytvoření ombudsmana

Dokumentace k softwaru AIP

Typ: Package:

Strana: 34

Activity První spuštění

Prvním krokem pro vytvoření ombudsmana je otevření formuláře pro vyplnění všech potřebných informací.

Otevření formuláře pro vytvoření Řešitele Typ: Package:

Activity První spuštění

Prvním krokem pro vytvoření řešitele je otevření formuláře pro vyplnění všech potřebných informací.

Potvrzení vytvoření admina Typ: Package:

Activity První spuštění

Je potřeba potvrdit zadané informace o konkrétním adminovi.

Potvrzení vytvoření ombudmana Typ: Package:

Activity První spuštění

Je potřeba potvrdit zadané informace o konkrétním ombudsmanovi.

Potvzení vytvoření řešitele Typ: Package:

Activity První spuštění

Je potřeba potvrdit zadané informace o konkrétním řešiteli.

Spuštění systému Typ: Package:

Activity První spuštění

Systém je nasazen a poprvé spuštěn na serveru.

Vyplnění formuláře pro administrátora Typ: Package:

Activity První spuštění

V tomto kroku jsou vyplněny informace o konkrétním adminovi.

Dokumentace k softwaru AIP

Vyplnění formuláře pro informace o systému. Typ: Package:

Activity První spuštění

Tento formulář bude obsahovat informace jako jsou : název instituce která jej používá atd.

Vyplnění formuláře pro ombudsmana Typ: Package:

Activity První spuštění

V tomto kroku jsou vyplněny informace o konkrétním ombudsmanovi.

Vyplnění formuláře pro vytvoření prvního Administrátora Typ: Package:

Activity První spuštění

Osoba instalující systém vyplné formulář, definující prvního administrátora.

Vyplnění formuláře pro řešitele Typ: Package:

Activity První spuštění

V tomto kroku jsou vyplněny informace o konkrétním řešitele.

Instalace dokončena Typ: Package:

ActivityInitial První spuštění

Systém spuštěn Typ: Package:

ActivityFinal První spuštění

V tuto chvíli je systém spuštěn a běží.

Volba tvorby uživatele

Strana: 35

Dokumentace k softwaru AIP

Typ: Package:

DecisionNode První spuštění

Registrace Diagram: Registrace - (Activity diagram) Diagram aktivit Registrace popisuje přechod z účtu Uživatele na účet Klienta.

Strana: 36

Dokumentace k softwaru AIP

Strana: 37

act Registrace Registrace klienta

Otev ření formuláře pro registraci

Vyplnění formuláře

[Ne] Potv rzení v yplněných informací

Je formulář vyplněn správně a jednoznačně

[Ano] Průchod ov ěřov acím systémem

Potvrdilo se ověření

[Ano]

Zobrazení potv rzení o registraci

Registrace hotova

obr. 14

Otevření formuláře pro registraci Typ: Package:

Activity Registrace

Prvním krokem je otevření formuláře s detaily k registraci klienta, jako jsou heslo a uživatelské jméno.

Dokumentace k softwaru AIP

Strana: 38

Potvrzení vyplněných informací Typ: Package:

Activity Registrace

Žádající uživatel musí potvrdit a odeslat své údaje.

Průchod ověřovacím systémem Typ: Package:

Activity Registrace

Údaje jsou ověřeny, např. heslo je složeno s malých i velkých písmen,čísel, minimálně jednoho speciálního zanku (tj. *,+,-,/ atd.) a má délku 10 až 20znaků.

Vyplnění formuláře Typ: Package:

Activity Registrace

Formulář je vyplněn podle povinností.

Zobrazení potvrzení o registraci Typ: Package:

Activity Registrace

Registrace je potvrzena výpisem na obrazovku.

Je formulář vyplněn správně a jednoznačně Typ: Package:

DecisionNode Registrace

Správnost vyplnění znamená, že jsou vyplněny všechn povinné pole, tj. uživatelské jméno, heslo a potvrzení hesla. Stejně tak musí být vyplněna a splněna podmínka která zabraňuje přihlášení elektronických robotů.

Potvrdilo se ověření Typ: Package:

DecisionNode Registrace

Ověření je splněno, pokud je uživatelské jméno unikátní,

Dokumentace k softwaru AIP

Registrace hotova Typ: Package:

ActivityFinal Registrace

Klient je přidán do systému.

Registrace klienta Typ: Package:

ActivityInitial Registrace

Zobrazení úkolů Diagram: Zobrazení úkolů - (Activity diagram) Diagram zobrazující průběh zobrazení úkolů včetně jejích filtrování.

Strana: 39

Dokumentace k softwaru AIP

Strana: 40

act Zobrazení úkolů Zobrazení úkolů - podána žádost

Otev ření seznamu s filtrem nastav eným na zobrazení v šech úkolů

Filtrování

[Ano] [Ne]

Otev ření formuláře pro zadání podmínek

Úkoly zobrazeny - bez filtru

Vyfiltrov ání úkolů podle podmínek

Zobrazení úkolů

obr. 15

Otevření formuláře pro zadání podmínek Typ: Package:

Activity Zobrazení úkolů

Systém zobrazí tabulku filtrovacích podmínek nad úkoly.

Dokumentace k softwaru AIP

Otevření seznamu s filtrem nastaveným na všechny nesplněný Typ: Package:

Activity Zobrazení úkolů

Otevření seznamu s filtrem nastaveným na zobrazení všech úkolů Typ: Package:

Activity Zobrazení úkolů

Prvotní krokem je otevření zobrazení všech úkolů.

Vyfiltrování úkolů podle podmínek Typ: Package:

Activity Zobrazení úkolů

Úkoly jsou vyfiltrovány podle daného zadání a zobrazeny danému uživateli.

Filtrování Typ: Package:

DecisionNode Zobrazení úkolů

Zobrazení úkolů Typ: Package:

ActivityFinal Zobrazení úkolů

Úkoly jsou zobrazeny dle daných filtrovacích podmínek, daný uživatel může prohlížet.

Zobrazení úkolů - podána žádost Typ: Package:

ActivityInitial Zobrazení úkolů

V tento okamžik byla kliknuto na funkci zobrazení úkolů.

Úkoly zobrazeny - bez filtru Typ: Package:

ActivityFinal Zobrazení úkolů

Strana: 41

Dokumentace k softwaru AIP

Strana: 42

Jsou zobrazeny všechny úkoly bez rozdílu.

Stavové diagramy Diagram: Stavové diagramy - (Package diagram)

obr. 16

Administrátorský účet - defaultní Package obsahující stavový diagram popisující životní cyklus defaultního administrátorského účtu. Diagram: Administrátorský účet - (Logical diagram) Vytváření nového administrátorského účtu při prvním spuštění systému.

Dokumentace k softwaru AIP

Strana: 43

class Administrátorský účet Administrátorský účet - defaultní

Neexistuj e

Spuštění [Instalace systému] /Vyplnění formuláře pro informace o systému.

Vytv ořen při spuštění systému Vytvoření [Vyplnění defaultního formuláře pro admina] /Vyplnění formuláře pro vytvoření prvního Administrátora Účet v prov ozu Učet OK Úprava [Potvrzení úprav] /Uživatel vytvoří úpravy a potvrdí je.

Ponechání [Rozhodnutí o ponechání účtu ve stávajícím stavu.] /Účet je ponechán v stejném stavu

Účet uprav ov án Rozhodnutí Úprava [Rozhodnutí o provedení úprav] /Administrátor se rozhodl upravit účet.

obr. 17

Neexistuje Typ: Package:

State Administrátorský účet - defaultní

Na začátku systému neexistuje žádný administrátor.

Přihlášení Typ: Package:

State Administrátorský účet - defaultní

Dokumentace k softwaru AIP

Vytvořen při spuštění systému Typ: Package:

State Administrátorský účet - defaultní

stav_uctu: existujici - vytvoren vytvorena osoba, prirazena role Admin, prirazeny prava pro admina

Účet upravován Typ: Package:

State Administrátorský účet - defaultní

stav_uctu : existuje - upraven

Účet v provozu Typ: Package:

State Administrátorský účet - defaultní

stav_uctu: existuje

Administrátorský účet - defaultní Typ: Package:

Initial State Administrátorský účet - defaultní

Existence sytému Typ: Package:

Choice Administrátorský účet - defaultní

Ponechání Typ: Package:

Trigger Administrátorský účet - defaultní

Strana: 44

Dokumentace k softwaru AIP

Rozhodnutí Typ: Package:

Trigger Administrátorský účet - defaultní

Spuštění Typ: Package:

Trigger Administrátorský účet - defaultní

Ucet v provozu Typ: Package:

Final State Administrátorský účet - defaultní

Učet OK Typ: Package:

Final State Administrátorský účet - defaultní

Vytvoření Typ: Package:

Trigger Administrátorský účet - defaultní

Úprava Typ: Package:

Choice Administrátorský účet - defaultní

Úprava Typ:

Trigger

Strana: 45

Dokumentace k softwaru AIP

Package:

Administrátorský účet - defaultní

Administrátorský účet - přidaný Package obsahující stavový diagram popisující životní cyklus přidaného administrátorského účtu. Diagram: Administrátorský účet - přidaný - (Logical diagram) Diagram zobrazující přidávání nového administrátorského účtu.

Strana: 46

Dokumentace k softwaru AIP

Strana: 47

class Administrátorský účet - přidaný Admin. účet - přidaný

Neexistuj e

[přidání jiným administrátorem] /Vyplnění formuláře pro administrátora Účet založen j iným administrátorem

[potvrzení vytvoření administrátor] /Potvrzení vytvoření admina

Učet v prov ozu

[potvrzení úprav]

[ne]

Účet uprav en

[Ano] Úprava

[mazaní]

Účet smazán j iným administrátorem

Účet smazán

obr. 18

Neexistuje Typ: Package:

State Administrátorský účet - přidaný

stav_uctu: neexistuje

Dokumentace k softwaru AIP

Učet v provozu Typ: Package:

State Administrátorský účet - přidaný

stav uctu : existuje

Účet ponechán v činnosti Typ: Package:

State Administrátorský účet - přidaný

Účet smazán jiným administrátorem Typ: Package:

State Administrátorský účet - přidaný

stav_uctu:blokovan

Účet upraven Typ: Package:

State Administrátorský účet - přidaný

stav_uctu: upraven

Účet založen jiným administrátorem Typ: Package:

State Administrátorský účet - přidaný

stav_uctu:vytvoren

Admin. účet - přidaný Typ: Package:

Úprava

Initial State Administrátorský účet - přidaný

Strana: 48

Dokumentace k softwaru AIP

Typ: Package:

Choice Administrátorský účet - přidaný

Účet OK Typ: Package:

Final State Administrátorský účet - přidaný

Účet blokován Typ: Package:

Final State Administrátorský účet - přidaný

Účet smazán Typ: Package:

Final State Administrátorský účet - přidaný

Účet uložen Typ: Package:

Final State Administrátorský účet - přidaný

Klientský účet Package obsahující stavový diagram popisující životní cyklus klientského účtu. Diagram: Klientský účet - (Logical diagram) Stavový diagram provozu Klientského účtu.

Strana: 49

Dokumentace k softwaru AIP

Strana: 50

class Klientský účet Klientský úč et

Zažádáno u administrátora

[Přihlášení administrátora] /Schválení žádosti

Potvrzení žádosti [Žádost splňuje potřebné paramentry] /Potvrzení žádosti

[Žádost nesplňuje potřebné parametry] /Nepotvrzení žádosti

Účet nev ytv oren

Účet v prov ozu

[ne] Úprava úč tu Účet uprav en

[ano] Úč et zamítnut

[mazání úč tu]

Účet smazán

klientský úč et smazán

obr. 19

Dokumentace k softwaru AIP

Vytvořena žádost od uživatele Typ: Package:

State Klientský účet

stav_zadosti: vytvorena stav_uctu: neexistuje

Zažádáno u administrátora Typ: Package:

State Klientský účet

stav_zadosti: vytvorena - predana k zhodnocení stav_uctu: neexistuje

Účet nevytvoren Typ: Package:

State Klientský účet

stav_zadosti: neschválena stav_uctu: blokován

Účet smazán Typ: Package:

State Klientský účet

stav uctu : blokován

Účet upraven Typ: Package:

State Klientský účet

stav_uctu: existuje - upraven

Účet v provozu Typ: Package:

State Klientský účet

Strana: 51

Dokumentace k softwaru AIP

stav_zadosti: schválena stav_uctu: existuje

Klientský účet Typ: Package:

Initial State Klientský účet

Potvrzení žádosti Typ: Package:

Choice Klientský účet

Administrátor musí rozhodnout jestli potvrdí nebo nepotvrdí žádost o registraci.

klientský účet smazán Typ: Package:

Final State Klientský účet

Úprava účtu Typ: Package:

Choice Klientský účet

Účet zamítnut Typ: Package:

Final State Klientský účet

Uživatelský účet Package obsahující stavový diagram popisující životní cyklus uživatelského účtu. Diagram: Uživatelský účet - (Logical diagram)

Strana: 52

Dokumentace k softwaru AIP

Strana: 53

Stavový diagram provozu Uživatelského účtu. class Už ivatelský účet Uživatelský úč et

Vytv ořen při otev ření aplikace [spuštění aplikace] /po spuštění aplikace je automaticky přidělen fyzické osobě úč et uživatele [není podána žádost o registraci] /úč et je uživatelský, na konci se smaže

ucet v prov ozu

zadost o registraci

[žádost o registraci] /uživatel chce přejít do klientského stavu V žádání o registraci

Smazán při konci aplikace

Úč et přesunut mezi klientské Úč et ukonč en

obr. 20

Smazán při konci aplikace Typ: Package:

State Uživatelský účet

stav uctu :smazan

V žádání o registraci Typ: Package:

State Uživatelský účet

stav zadosti:vytvorena

Vytvořen při otevření aplikace Typ:

State

Dokumentace k softwaru AIP

Package:

Uživatelský účet

stav_uctu :vytvoren

ucet v provozu Typ: Package:

State Uživatelský účet

stav uctu:existuje

Uživatelský účet Typ: Package:

Initial State Uživatelský účet

zadost o registraci Typ: Package:

Choice Uživatelský účet

Účet přesunut mezi klientské Typ: Package:

Final State Uživatelský účet

Účet ukončen Typ: Package:

Final State Uživatelský účet

Úkol Package obsahující stavový diagram popisující životní cyklus úkolu. Diagram: Úkol - (Logical diagram) Stavový diagram života Úkolu.

Strana: 54

Dokumentace k softwaru AIP

Strana: 55

class Úkol Úkol

Úkol neexistuj e

[zadání klientem] /vyplnění formulářů pro zadání úkolu

Úkol j e zadán klientem [potvrzení zadání úkolu] /úkol se přesune k shválení kategorie. Nalezení kategorie

[k úkolu nebyla nalezena(nepřiřazena) kategorie] /úkol je předán Řešitelům a ombudsmanovi k přiřazení kategorie

[do úkolu byla přiřazena kategorie] /úkol je přiřazen do dané kategorie

Úkol ponechán j ako nazařazený

[ombudsman nebo řešitel přiřadí kategorii] /k úkolu je přiřazena kategorie Úkol zařazen do kategorie

[ombudsman přidělí úkoly] /následně je předán úkol řešiteli, který odpovídá za kategorii, případně skupinu kategorií Ukol předán řešiteli

Schvaleni ukolu resitelem [ano] Ukol schv álen

[ne]

ukol neschv alen

[ano] [ne]

upravení ukolu [řešení]

Úkol odpov ězen

Ukol smazán

Dokumentace k softwaru AIP

Strana: 56

obr. 21

Ukol předán řešiteli Typ: Package:

State Úkol

stav uctu: existuje - prirazen do kat - přirazen rešiteli stav zadosti: schvalena/neschvalena

Ukol schválen Typ: Package:

State Úkol

stav_ukolu: existuje - přirazen do kat - prirazen resiteli

ukol neschvalen Typ: Package:

State Úkol

Úkol nebyl schválen řešitelem, je považován za nedostatečný. stav_ukolu:neschvalen

Úkol je zadán klientem Typ: Package:

State Úkol

stav_ukolu: vytvoren

Úkol neexistuje Typ: Package:

State Úkol

stav_úkolu:neexistuje

Úkol odpovězen Typ: Package:

State Úkol

Dokumentace k softwaru AIP

Úkol je odpovězen řešitelem stav_ukolu: řešen

Úkol ponechán jako nazařazený Typ: Package:

State Úkol

Úkol je zatím nezařezen do kategorie, nyní následuje proces přidělení nebo vytvoření kategorie. stav_ukolu: existuje - nezarazeny

Úkol zařazen do kategorie Typ: Package:

State Úkol

Klient vybral vhodnou kategoii a existující, úkolu je tato kategori přidělena. stav uctu: existuje - prirazen do kat

Nalezení kategorie Typ: Package:

Choice Úkol

Klient chce zařadit svůj úkol do kategorie, ta může být vytvořena nebo nemusí.

Schvaleni ukolu resitelem Typ: Package:

Choice Úkol

Ukol smazán Typ: Package:

Final State Úkol

stav _ ukolu: blokovan

Ukol uzavren Typ:

Final State

Strana: 57

Dokumentace k softwaru AIP

Package:

Úkol

stav_uctu: uzavren

upravení ukolu Typ: Package:

Choice Úkol

Úkol Typ: Package:

Initial State Úkol

Řešitelský účet Package obsahující stavový diagram popisující životní cyklus řešitelského účtu. Diagram: Řešitelský účet - (Logical diagram) Stavový diagram provozu Řešitelského účtu.

Strana: 58

Dokumentace k softwaru AIP

Strana: 59

class Řešitelský účet Řešitelský úč et

Řešitelský účet neexistuj e

[vytvoření uč tu adminem] /Otevření formuláře pro vytvoření Řešitele Učet v ytv ořen administrátorem [uloženi formuláře pro vytvoření řešitele] /Potvzení vytvoření řešitele Učet v prov ozu

Účet uprav ov án

[ano]

uprava

[mazani]

ucet smazan administrátorem

uč et smazán

obr. 22

Učet v provozu Typ: Package:

State Řešitelský účet

stav uctu: existuje

Učet vytvořen administrátorem

[ne]

Dokumentace k softwaru AIP

Typ: Package:

State Řešitelský účet

stav_uctu: vytvoren

ucet smazan administrátorem Typ: Package:

State Řešitelský účet

stav_uctu:blokovan

Účet upravován Typ: Package:

State Řešitelský účet

Řešitelský účet neexistuje Typ: Package:

State Řešitelský účet

uprava Typ: Package:

Choice Řešitelský účet

učet smazán Typ: Package:

Final State Řešitelský účet

Řešitelský účet Typ: Package:

Initial State Řešitelský účet

Strana: 60

Dokumentace k softwaru AIP

Žádost Package obsahující stavový diagram popisující životní cyklus žádosti. Diagram: Žádost - (Logical diagram) Stavový diagram vývoje Žádosti.

Strana: 61

Dokumentace k softwaru AIP

Strana: 62

class Žádost Žádost

puvod zadosti [vytvořeno klientem] /k žádosti je přiřazena poznámka , že je vytvořena klientem

[vytvořeno řešitelem ] /k žádosti je přiřazeno, že je vytvořena řešitelem

žádost v ytv orena řešitelem

žadost v ytv ořena klientem

[potvrzení odeslání žádosti] /žádost je odeslána řešitelem

[potvrzení odeslaní žádosti] /žádost je klientem odeslána

žadost předana ke schv álení administrátorov i

[přihlášení administrátora] /zobrazení žádostí

schvaleni

[žádost odmítnuta] /nepotvrzení žádosti a informování zadávajícího

[žádost schválena] /potvrzení žádost a informování zadávajícího

žadost schv alena

Žadost neschv álena

žadost smazana

žadost schvalena

obr. 23

Žadost neschválena Typ: Package:

State Žádost

Dokumentace k softwaru AIP

stav_žadosti: blokovana

žadost předana ke schválení administrátorovi Typ: Package:

State Žádost

stav_zadosti: predana k vyřízení

žadost schvalena Typ: Package:

State Žádost

stav_zadosti: schvalena

žadost vytvořena klientem Typ: Package:

State Žádost

stav_zadosti: vytvorena klientem

žádost vytvorena řešitelem Typ: Package:

State Žádost

stav_zadosti: vytvorena řešitelem

puvod zadosti Typ: Package:

Choice Žádost

schvaleni Typ: Package:

Choice Žádost

Strana: 63

Dokumentace k softwaru AIP

Žádost Typ: Package:

Initial State Žádost

žadost schvalena Typ: Package:

Final State Žádost

žadost smazana Typ: Package:

Final State Žádost

Strana: 64

Příloha B: původní šablona generování dokumentace z Diplomové práce Ing. Jiřího Mlejnka

Příloha B

Obsah Model Detail ...................................................................................................................................2 {Pkg.Name} ...............................................................................................................................2 {Element.Name} ......................................................................................................................2

Stránka 1

Příloha B

Model Documentation package >

{Pkg.Name} {Pkg.Notes} diagram >

{Diagram.Name} - ({Diagram.Type} diagram) {Diagram.Notes} {Diagram.DiagramImg} {Diagram.Figure} < diagram element >

{Element.Name} Typ: Package:

{Element.Type} {Element.BaseClasses} {Element.ParentPackage} Keywords: {Element.Tag}

{Element.Notes} requirement >

Responsibilities (internal requirements)  {ElemRequirement.Name} ( {ElemRequirement.Type} type, {ElemRequirement.Status}, {ElemRequirement.Difficulty} difficulty ) {ElemRequirement.Notes} < requirement constraint >

Constraints  {ElemConstraint.Name} : ({ElemConstraint.Type}.Status is {ElemConstraint.Status} ) {ElemConstraint.Notes} < constraint custom property >

Custom Properties  {CustomProperty.Name} = {CustomProperty.Value} < custom property scenario >

Scenarios  {ElemScenario.Scenario} {ElemScenario.Type} {ElemScenario.Notes} < scenario file >

Associated Files

Stránka 2

Příloha B

Associated Files  {ElemFile.Type} {ElemFile.FilePath} {ElemFile.Notes} < file task >

Tasks  {ElemTask.Task} {ElemTask.Status} (Version {ElemTask.Version}. requested by {ElemTask.RequestedBy} on {ElemTask.DateRequested}) {ElemTask.TaskNotes} {ElemTask.History} < task issue >

Issues  {ElemIssue.Issue} {ElemIssue.Status} (Version {ElemIssue.Version} raised by {ElemIssue.DateReported} by {ElemIssue.RaisedBy} ) {ElemIssue.Notes} {ElemIssue.History} < issue change >

Changes  {ElemChange.Problem} {ElemChange.Status} (Version {ElemChange.Version}. Owner is {ElemChange.ReportedBy}) {ElemChange.ProblemNotes} {ElemChange.ResolverNotes} < change tagged value >

Tagged Values  {ElementTagVal.Name} = {ElementTagVal.Value}. {ElementTagVal.Notes} < tagged value resource >

Resources Resource {ElemResource.Resource } {ElemResource.Role}

Timing Notes Start: {ElemResource.StartDate} End: {ElemResource.History} {ElemResource.EndDate} Complete:{ElemResource.PercentComplete} % Expected time: {ElemResource.ExpectedHours}. Actual time: {ElemResource.ActualHours}

< resource test >

Tests Test {ElemTest.Name} {ElemTest.Type} test. Status: {ElemTest.Status}

Detail {ElemTest.Notes} Acceptance:{ElemTest.AcceptanceCriteria} Results:{ElemTest.TestResults}

< test

Stránka 3

Results Last run: {ElemTest.RunDate} Checked: {ElemTest.CheckedBy}

Příloha B

defect >

Defects  {ElemDefect.Problem} (Status = {ElemDefect.Status}. Version = {ElemDefect.Version}. Reported on {ElemDefect.DateReported}). {ElemDefect.ProblemNotes} {ElemDefect.ResolverNotes} < defect effort >

Effort  {ElemEffort.Effort} {ElemEffort.Type} (Weight: {ElemEffort.Value} ) {ElemEffort.Notes} < effort metric >

Metrics  {ElemMetric.Metric} {ElemMetric.Type} (Weight:{ElemMetric.Value}) {ElemMetric.Notes} < metric connector >

Connections Connector {Connector.Type} {Connector.Name} {Connector.Direction}

Source

Target

source >

target >

{ConnSource.Scope} {ConnSource.Role} {ConnSource.RoleNote }

{ConnTarget.Scope} {ConnTarget.Role} {ConnTarget.RoleNote }

element >

element >

{Element.Name}

{Element.Name}

< element < source

< element < target

Notes {Connector.Notes} constraint >

{ConnConstraint.Type} {{ConnConstraint.Name}} < constraint

< connector embedded elements >

Embedded Elements Element Detail {EmbeddedElement.Type} {EmbeddedElement.BaseClasses} {EmbeddedElement.Name {EmbeddedElement.Version} }

Notes {EmbeddedElement.Notes}

< embedded elements attribute >

Attributes Attribute {Att.Name} {Att.Type} {Att.Scope} {Att.Static} {Att.Const} {Att.Collection} {Att.Multiplicity} {Att.Stereotype}

Notes

Constraints and tags

{Att.Notes}

Default: {Att.Default} constraint >

{FeatConstraint.Type}: { {FeatConstraint.Name} } < constraint tagged value >

[{FeatTagVal.Name} = {FeatTagVal.Value} ] < tagged value

< attribute

Stránka 4

Příloha B

method >

Operations Method Notes {Meth.Static}{Meth.Const {Meth.Notes} }{Meth.Pure}{Meth.Name {Meth.Behavior} }() {Meth.Type} {Meth.Scope} {Meth.IsLeaf} {Meth.IsQuery}

Parameters parameter >

{MethParameter.Type} {MethParameter.Name} [{MethParameter.Kind}] {MethParameter.Notes} < parameter

< method diagram >

{Diagram.Type} diagram: {Diagram.Name} {Diagram.DiagramImg} {Diagram.Notes} < diagram child element > < child element < element child package > < child package < package

Stránka 5

Příloha C: Upravená šablona použitá na generování dokumentace softwaru AIP

Příloha C

Obsah Slovníček pojmů .........................................................................................................................2 {Pkg.Name} ...............................................................................................................................3 {Element.Name} ......................................................................................................................3

Stránka 1

Příloha C

Dokumentace k softwaru AIP Slovníček pojmů model > glossary >

. Termín {ModelGlossary.Term}

Popis {ModelGlossary.Meaning}

< glossary < model package >

{Pkg.Name} {Pkg.Notes} diagram >

Diagram: {Diagram.Name} - ({Diagram.Type} diagram) {Diagram.Notes} {Diagram.DiagramImg} obr. {Diagram.Figure} < diagram element >

{Element.Name} Typ: Package:

{Element.Type} {Element.BaseClasses} {Element.ParentPackage}

{Element.Notes} requirement >

Responsibilities (internal requirements)  {ElemRequirement.Name} ( {ElemRequirement.Type} type, {ElemRequirement.Status}, {ElemRequirement.Difficulty} difficulty ) {ElemRequirement.Notes} < requirement constraint >

Constraints  {ElemConstraint.Name} : ({ElemConstraint.Type}.Status is {ElemConstraint.Status} ) {ElemConstraint.Notes} < constraint scenario >

Scénáře  {ElemScenario.Scenario} {ElemScenario.Type} {ElemScenario.Notes} < scenario file >

Stránka 2

Příloha C

Associated Files  {ElemFile.Type} {ElemFile.FilePath} {ElemFile.Notes} < file task >

Tasks  {ElemTask.Task} {ElemTask.Status} (Version {ElemTask.Version}. requested by {ElemTask.RequestedBy} on {ElemTask.DateRequested}) {ElemTask.TaskNotes} {ElemTask.History} < task issue >

Issues  {ElemIssue.Issue} {ElemIssue.Status} (Version {ElemIssue.Version} raised by {ElemIssue.DateReported} by {ElemIssue.RaisedBy} ) {ElemIssue.Notes} {ElemIssue.History} < issue change >

Changes  {ElemChange.Problem} {ElemChange.Status} (Version {ElemChange.Version}. Owner is {ElemChange.ReportedBy}) {ElemChange.ProblemNotes} {ElemChange.ResolverNotes} < change tagged value >

Tagged Values  {ElementTagVal.Name} = {ElementTagVal.Value}. {ElementTagVal.Notes} < tagged value resource >

Resources Resource {ElemResource.Resource } {ElemResource.Role}

Timing Notes Start: {ElemResource.StartDate} End: {ElemResource.History} {ElemResource.EndDate} Complete:{ElemResource.PercentComplete} % Expected time: {ElemResource.ExpectedHours}. Actual time: {ElemResource.ActualHours}

< resource test >

Tests Test {ElemTest.Name} {ElemTest.Type} test. Status: {ElemTest.Status}

Detail {ElemTest.Notes} Acceptance:{ElemTest.AcceptanceCriteria} Results:{ElemTest.TestResults}

< test

Stránka 3

Results Last run: {ElemTest.RunDate} Checked: {ElemTest.CheckedBy}

Příloha C

defect >

Defects  {ElemDefect.Problem} (Status = {ElemDefect.Status}. Version = {ElemDefect.Version}. Reported on {ElemDefect.DateReported}). {ElemDefect.ProblemNotes} {ElemDefect.ResolverNotes} < defect effort >

Effort  {ElemEffort.Effort} {ElemEffort.Type} (Weight: {ElemEffort.Value} ) {ElemEffort.Notes} < effort metric >

Metrics  {ElemMetric.Metric} {ElemMetric.Type} (Weight:{ElemMetric.Value}) {ElemMetric.Notes} < metric embedded elements >

Embedded Elements Element Detail {EmbeddedElement.Type} {EmbeddedElement.BaseClasses} {EmbeddedElement.Name {EmbeddedElement.Version} }

Notes {EmbeddedElement.Notes}

< embedded elements attribute >

Atributy Atribut {Att.Name} {Att.Type} {Att.Scope} {Att.Static} {Att.Const} {Att.Collection} {Att.Multiplicity} {Att.Stereotype}

Poznámka

Constraints and tags

{Att.Notes}

Default: {Att.Default} constraint >

{FeatConstraint.Type}: { {FeatConstraint.Name} } < constraint tagged value >

[{FeatTagVal.Name} = {FeatTagVal.Value} ] < tagged value

< attribute method >

Operations Method Notes {Meth.Static}{Meth.Const {Meth.Notes} }{Meth.Pure}{Meth.Name {Meth.Behavior} }() {Meth.Type} {Meth.Scope} {Meth.IsLeaf} {Meth.IsQuery}

Parameters parameter >

{MethParameter.Type} {MethParameter.Name} [{MethParameter.Kind}] {MethParameter.Notes} < parameter

< method diagram >

Stránka 4

Příloha C

{Diagram.Type} diagram: {Diagram.Name} {Diagram.DiagramImg} {Diagram.Notes} < diagram child element > < child element < element child package > < child package < package

Stránka 5

Příloha D: Kód jednoduchých maker z programu MS Office Word 2007 pro konečnou automatickou úpravu dokumentace

Příloha D

Sub ClearNFormat() ' ' Makro Makro ' '

Selection.Find.ClearFormatting Selection.Find.Replacement.ClearFormatting With Selection.Find .Text = "^p^p^p^p" .Replacement.Text = "^p" .Forward = True .Wrap = wdFindAsk .Format = False .MatchCase = False .MatchWholeWord = False .MatchWildcards = False .MatchSoundsLike = False .MatchAllWordForms = False End With Selection.Find.Execute Replace:=wdReplaceAll With Selection.Find .Text = " ^p^p^p" .Replacement.Text = "" .Forward = True .Wrap = wdFindAsk .Format = False .MatchCase = False .MatchWholeWord = False .MatchWildcards = False .MatchSoundsLike = False .MatchAllWordForms = False End With Selection.Find.Execute Replace:=wdReplaceAll With Selection.Find .Text = " ^p^p" .Replacement.Text = "^p" .Forward = True .Wrap = wdFindAsk .Format = False .MatchCase = False .MatchWholeWord = False .MatchWildcards = False .MatchSoundsLike = False .MatchAllWordForms = False End With Selection.Find.Execute Replace:=wdReplaceAll With Selection.Find .Text = " " .Replacement.Text = "" .Forward = True .Wrap = wdFindAsk

Stránka 1

Příloha D

.Format = False .MatchCase = False .MatchWholeWord = False .MatchWildcards = False .MatchSoundsLike = False .MatchAllWordForms = False End With Selection.Find.Execute Replace:=wdReplaceAll Selection.WholeStory Selection.Font.Name = "Times New Roman" Selection.LanguageID = wdCzech Application.CheckLanguage = True End Sub

Stránka 2