BAKALÁŘSKÁ PRÁCE. Informační systém pro organizaci a prezentaci práce zájmové komunity

BAKALÁŘSKÁ PRÁCE Informační systém pro organizaci a prezentaci práce zájmové komunity The information system for organization and presentation community work Jan Macháček

Un ico rn Co lle ge © 20 10 Un ico rn Co lle ge , V K ap slo vn ě 27 67 /2 , P ra h a 3 , 1 30 00 Ná ze v p rá ce v ČJ: Ná ze v p rá ce v AJ:

In fo rma čn í systé m p ro o rg an iza ci a p re zen t a ci p rá ce zá jmo vé ko mu n it y Th e inf o rma t ion syste m fo r o rg an iza t ion a nd p re sen t a t io n co mmu n it y wo rk

Au to r:

Ja n Ma ch á če k

Aka de mický ro k:

20 10

Ko nt a kt:

E -ma il: jan . ma ch y@ g ma il. co m Te l. : (+4 20 ) 7 24 97 3 9 25

Bakalářská práce Informační systém pro organizaci a prezentaci práce zájmové komunity The information system for organization and presentation community work

1.

ZADÁNÍ

▪3▪


2.

ABSTRAKT

Práce se zabývá návrhem a implementací jednoduchého informačního systému pro podporu činnosti zájmové komunity. Je rozdělena do čtyř částí, které se postupně zaměřují na analýzu, návrh a implementaci systému. Závěrečná část je věnována použitým technologiím. Cílem práce je ověřit si vědomosti získané během studií Unicorn College na konkrétním projektu. Klíčová slova: Informační systém, návrh informačních systémů, analýza informačních systémů, model-view-controller, objektově-relační mapování, C#, nHibernate, ASP.NET MVC, Oracle.

▪4▪


3.

ABSTRACT

The work deals with a design and an implementation of a simple information system to support the activities of a community. It is divided into four parts, which gradually focuses on the analysis, design and implementation. The final section is about used technologies. The goal of work is to verify the knowledge gained from studies of Unicorn College on this project.

Keywords: An information system, design of information systems, analysis of information systems, model-view-controller, object-relational mapping, C #, nHibernate, ASP.NET MVC, Oracle.

▪5▪


4.

PROHLÁŠENÍ

Prohlašuji, že svou bakalářskou práci na téma Informační systém pro organizaci a prezentaci práce zájmové komunity jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne

…….………………. Jan Macháček

▪6▪


5.

PODĚKOVÁNÍ

Děkuji vedoucímu bakalářské práce RNDr. Ondřeji Kučerovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. Dále bych chtěl podě kovat své rodině a blízkým za trpělivost, kterou věnovali mým studiím.

▪7▪


6.

OBSAH

1. 2. 3. 4. 5. 6. 7. 8.

Zadání.......................................................................................................................................... 3 Abstrakt....................................................................................................................................... 4 Abstract....................................................................................................................................... 5 Prohlášení................................................................................................................................... 6 Poděkování................................................................................................................................. 7 Obsah.......................................................................................................................................... 8 Úvod........................................................................................................................................... 10 Analýza a správa Požadavků................................................................................................. 11 8.1 Analýza problémové domény......................................................................................... 11 8.1.1 Popis společnosti..................................................................................................... 11 8.1.2 Popis stávajících procesů......................................................................................11 8.2 Souhrnný přehled procesů............................................................................................. 12 8.2.1 PROC03 - Účast na akcích rekonstruujících historii..........................................14 8.2.2 PROC10 – Propagace skupiny..............................................................................15 8.3 Shrnutí problému............................................................................................................. 15 8.3.1 Výstup z dotazníku.................................................................................................. 15 8.4 Správa požadavků .......................................................................................................... 16 8.4.1 Identifikované požadavky.......................................................................................16 8.4.2 Celková priorita identifikovaných požadavků......................................................17 8.5 Navrhované řešení.......................................................................................................... 17 9. Návrh systému......................................................................................................................... 19 9.1 Modul Core....................................................................................................................... 19 9.1.1 Uživatelé a skupiny................................................................................................. 19 9.1.2 Galerie a obrázky.................................................................................................... 20 9.1.3 Seznam případů užití modulu Core......................................................................21 9.2 Modul Planning................................................................................................................ 22 9.2.1 Seznam případů užití modulu Planning................................................................22 10. Implementace......................................................................................................................... 23 10.1 Modul Core..................................................................................................................... 23 10.1.1 Model....................................................................................................................... 23 10.1.2 Controller................................................................................................................ 24 10.1.3 Databázové schéma.............................................................................................. 24 11. Použité technologie............................................................................................................... 25 11.1 Návrh systému ISob...................................................................................................... 25 11.1.1 Persistentní uložení dat........................................................................................ 25 11.1.2 Objektově-relační mapování................................................................................25 11.1.3 Serverová část....................................................................................................... 26 11.1.4 Klientská část......................................................................................................... 26 11.2 Silverlight........................................................................................................................ 26 11.2.1 O projektu............................................................................................................... 26 11.2.2 Konfigurace............................................................................................................ 27 11.3 WCF RIA Services ....................................................................................................... 27 11.3.1 O projektu............................................................................................................... 27 11.3.2 Konfigurace............................................................................................................ 28 11.4 nHibernate...................................................................................................................... 28 11.4.1 O projektu............................................................................................................... 28 11.4.2 Konfigurace............................................................................................................ 29 11.4.3 Příklad mapování objektu.....................................................................................30 11.5 Knihovny třetích stran................................................................................................... 30 11.6 Instalace systému.......................................................................................................... 31 12. Závěr....................................................................................................................................... 33 13. Conclusion.............................................................................................................................. 34

▪8▪


14. Seznam použité literatury..................................................................................................... 35 15. Seznam použitých symbolů a zkratek................................................................................36 16. Seznam obrázků.................................................................................................................... 37 17. Seznam tabulek..................................................................................................................... 38 18. Seznam příloh........................................................................................................................ 39 Příloha 1 – Vybrané případy užití systému ISob.....................................................................40 18.1 Registrace nového uživatele ......................................................................................40 18.1.1 Popis....................................................................................................................... 40 18.1.2 Vstupní podmínky.................................................................................................. 40 18.1.3 Toky......................................................................................................................... 40 18.1.4 Datové typy............................................................................................................ 41 18.1.5 Další informace a diagramy.................................................................................41 18.2 Zobrazení detailu profilu uživatele..............................................................................42 18.2.1 Popis....................................................................................................................... 42 18.2.2 Vstupní podmínky.................................................................................................. 43 18.2.3 Toky......................................................................................................................... 43 18.2.4 Datové typy............................................................................................................ 43 18.2.5 Další informace a diagramy.................................................................................43 18.3 Editace osobních údajů v profilu uživatele................................................................43 18.3.1 Popis....................................................................................................................... 43 18.3.2 Vstupní podmínky.................................................................................................. 43 18.3.3 Toky......................................................................................................................... 44 18.3.4 Datové typy............................................................................................................ 44 18.3.5 Další informace a diagramy.................................................................................44 18.4 Založení skupiny............................................................................................................ 45 18.4.1 Popis....................................................................................................................... 45 18.4.2 Vstupní podmínky.................................................................................................. 45 18.4.3 Toky......................................................................................................................... 45 18.4.4 Datové typy............................................................................................................ 45 18.4.5 Další informace a diagramy.................................................................................45 18.5 Úprava jména a popisu skupiny..................................................................................46 18.5.1 Popis....................................................................................................................... 46 18.5.2 Vstupní podmínky.................................................................................................. 46 18.5.3 Toky......................................................................................................................... 46 18.5.4 Datové typy............................................................................................................ 46 18.5.5 Další informace a diagramy.................................................................................47 18.6 Přihlášení koncového uživatele do systému.............................................................47 18.6.1 Popis....................................................................................................................... 47 18.6.2 Vstupní podmínky.................................................................................................. 47 18.6.3 Toky......................................................................................................................... 47 18.6.4 Další informace a diagramy.................................................................................48 19. Ukázka mapování třídy Person na tabulku PERSON.......................................................49

▪9▪


7.

ÚVOD

Informační a komunikační technologie v současnosti patří k významným a lukrativním ekonomickým odvětvím. Firmy jako Microsoft, Google nebo Apple jsou v této oblasti jedny z největších na světě. I žebříčku nejbohatších osob světa vévodí vlastník několika telekomunikačních společností - Carlos Slim Helú. Společně s ním je v první patnáctce Bill Gates, zakladatel Microsoftu a Lawrenc Ellison, spoluzakladatel Oracle Corporation. ICT je velmi široce používaný pojem. Mezi informační a komunikační technologie se řadí i jedna poměrně specifická disciplína - vývoj software. Cílem této práce bylo aplikovat poznatky získané v tomto oboru, na konkrétním projektu. Proto jsem se rozhodl navrhnout a implementovat prototyp jednoduchého informačního systému. Projekt zahrnuje všechny fáze vývoje software, tedy od analýzy přes návrh a implementaci po nasazení. Navržený systém bude využívat zájmové sdružení „Kompanie z Curychu“, skupina, která se zabývá rekonstrukcí historie, konkrétně švýcarské milice na sklonku patnáctého století. Takovéto zaměření systému jsem zvolil z jednoduchého důvodu. Jednou z klíčových znalostí potřebných pro vývoj kvalitního software je velmi dobré povědomí o problematice dané oblasti. Vzhledem k tomu, že ve zmíněné organizaci působím již přes pět let, jsem s ní dobře seznámen. Práce je rozdělena do čtyř základních částí. První část je zaměřena na sběr a analýzu požadavků, kladených na informační systém. Zahrnuje podrobný popis funkcí a aktivit zájmového sdružení „Kompanie z Curychu“ i procesů, které v něm probíhají. Problematika je identifikována pomocí diskuzí a dotazníkových šetření. Na základě rozboru těchto informací je navrženo řešení. Ve druhé části je návrh podrobněji rozpracován pomocí vhodných modelů a popisem případů užití. Systém díky tomu získává jasnější obrysy. Jsou nakresleny první diagramy zachycující entity v systému a vzájemné vztahy mezi nimi. Třetí část práce se zabývá konstrukční fází projektu. Zde přistupuji již k samotné tvorbě prototypu. Závěr práce je spíše teoretický a pojednává o technologiích použitých při tvorbě tohoto informačního systému. Měl by objasnit jejich volbu a představit ty méně známé z nich. V této části je rovněž popsán postup nasazení systému.

▪ 10 ▪


8.

ANALÝZA A SPRÁVA POŽADAVKŮ

Správa požadavků je jednou z klíčových disciplín použitých při vývoji softwaru. Je to systematický přístup, pomocí kterého se snažíme pochopit problémovou doménu a následně identifikovat a zachytit požadavky, které se v ní vyskytují. Dle metodiky Rational Unified Process je na ni kladen největší důraz v úvodních fázích projektu, ale musí být vykonávána v jeho celém průběhu. V této části se proto zaměříme na problémovou oblast. Popíšeme si organizaci-sdružení a zaznamenáme procesy, v ní probíhající. Na základě těchto informací a sebraných požadavků, se pokusíme navrhnout informační systém, který bude podporovat činnost této organizace.

8.1 8.1.1

Analýza problémové domény Popis společnosti

Kompanie z Curychu je skupina, zabývající se rekonstrukcí historie. Sdružuje hlavně příznivce z Prahy a okolí, ale mohou se zapojit zájemci z celé republiky. Vznikla na podzim roku 2005 jako volné sdružení lidí, se zájmem o hraní rolových/zážitkových fantasy her, přičemž historie byla pro skupinu až podružným kritériem. Nicméně, v průběhu let se celkové zaměření skupiny k historii z různých směrů blížilo, až konečně v roce 2007 bylo rozhodnuto, že skupina začne historii „dělat jinak“ než ostatní. Snaží se propojit principy „oživování historie“ s hraním rolových her. Často skupina naráží na hranice, které žánr fantasy neumožňoval a byla nucena přehodnotit své působení a zaměření. Formou, často bolestivých, diskuzí dospělo vedení k tomu, že se chce kvalitně věnovat rekonstrukci určitého historického období. Volba padla na pozdně středověké Švýcarsko. Zpětně je těžké vysvětlit, proč byla vybrána zrovna tato země, nejspíš se jednalo o konsenzus všech tehdejších členů. Skupina se přeformovala v jakýsi „projekt“ s jasně stanovenými cíli a postupy, které se budou pro dosažení těchto cílů používat.

8.1.2

Popis stávajících procesů

Hlavním cílem skupiny je rekonstrukce jednotky milice švýcarského kantonu Curych pozdního 15. století. Ideálem pak je vytvořit kvalitní a sehranou kompanii, věrohodně zasazenou do světa střední Evropy pozdního středověku, respektive počínající renesance. To znamená celkovou rekonstrukci jednotky ve všech aspektech její existence a tím věrohodně oživení historie. Mezi činnosti skupiny tedy logicky patří nejen historický boj a výcvik, ale také původní formy táboření, cestování, strážní služby, trávení volného času apod. Skupina se snaží, aby jednotlivé postavy, které v jednotce vystupují, odpovídaly složení společnosti dané doby a byly tak nejen historicky věrné, ale hlavně plastické a pro případného pozorovatele „živé“. Skupina se účastní široké škály akcí, kde se schází

▪ 11 ▪


s podobně zaměřenými skupinami a společně tak rekonstruují vojenskou taktiku a události druhé poloviny 15. a počátku 16. století. Již jen okrajově, a povětšinou na individuální bázi, se členové věnují hraní rolových/zážitkových her. Všem zájemcům, kteří by se chtěli k tomuto unikátnímu projektu připojit, skupina nabízí možnost získání základního povědomí o výrobě kostýmů a přístup k odpovídajícímu vybavení, výcvik boje se zbraněmi i bez nich a v neposlední řadě stát se součástí zajímavého kolektivu – samozřejmostí je pak účast nejen na tuzemských, ale i zahraničních „reenactment“ akcích. Skupina pořádá i vlastní semináře a workshopy, přístupné však pouze členům projektu.

▪ 12 ▪


8.2

Souhrnný přehled procesů

Obrázek 1: Procesy ve skupině

Pokud chceme vytvářet informační systém, který bude pokrývat potřeby zadavatele, musíme nejdříve pochopit business pravidla a postupy, která v rámci organizace platí. Proto se nám vyplatí zachytit a důkladně popsat její hlavní a vedlejší procesy.

▪ 13 ▪


ID procesu

Název

PROC01

Rekonstrukce historie

PROC02

Organizace skupiny

PROC03

Účast na akcích rekonstruujících historii

PROC04

Rekonstrukce jednotky milice švýcarského kantonu Curych

PROC05

Budování věrohodné rekonstrukce vojenského ležení

PROC06

Vzdělávání členů v historii, historických výrobních postupech, zpracování materiálů apod.

PROC07

Pořádání workshopů

PROC08

Výcvik boje se zbraněmi i bez nich

PROC09

Výroba kostýmů

PROC10

Propagace skupiny

PROC11

Nábor nových členů

Tabulka 1: Procesy ve skupině

8.2.1

PROC03 - Účast na akcích rekonstruujících historii

Cíl

Reprezentace skupiny na tuzemských i zahraničních akcích Seznámení diváků s historií vojáků v kantonu Curych

Zodpovědná osoba

Šimon Steffal

Vstupy

Pozvánka na akci Členové skupiny ochotní se akce zúčastnit Potřebné táborové a vojenské vybavení Dopravní prostředky

Výstupy

Spokojený divák, organizátor i člen skupiny

Tabulka 2: Popis procesu PROC03

Název

Pozvání členů skupiny na akci

Cíl

Dohoda mezi vedoucím skupiny a pořadatelem akce na požadavcích

Vstupy

Pozvánka na akci

Výstupy

Skupina se zúčastní akce

Časová náročnost

1-6 měsíců

Kanál

Telefon/Ústní domluva/Email/Facebook/Informační system

Tabulka 3: Popis dílčích kroků procesu PROC03.01

▪ 14 ▪


Název

Příprava odjezdu na akci

Cíl

Organizace a naplánování průběhu akce

Vstupy

Požadavky akce

Výstupy

Seznam členů, kteří se zúčastní akce Seznam vybavení, které je nutné vzít Plán cesty


1-2 týdny

Kanál

Telefon/Ústní domluva/Email/Facebook/Informační systém


Název

Vyskladnění věcí potřebných na akci

Cíl

Příprava a kontrola stavu vybavení před odjezdem na akci, případné drobné opravy vybavení

Vstupy

Seznam vybavení, které je na akci potřeba

Výstupy

Vyskladněné vybavení Seznam vyskladněného vybavení


1-10 hodin

Kanál

Informační systém


8.2.2

PROC10 – Propagace skupiny

Cíl

Seznámení veřejnosti s projektem rekonstrukce jednotky milice švýcarského kantonu Curych

Zodpovědná osoba

Šimon Steffal, Jan Macháček

Vstupy

Fotografie Nové informace - výrobní postupy, tipy a triky

Výstupy

Prezentace skupiny na vlastním webu a sociální síti Facebook Šíření získaných informací a postupů mezi zainteresované osoby

Tabulka 6: Popis procesu PROC10

▪ 15 ▪


Název

Publikování fotografií z akce

Cíl

Prezentace fotografií z akce na webu skupiny a na sociální síti Facebook

Vstupy

Fotografie z akce

Výstupy

Webová galerie


1 týden

Kanál

Informační systém


Problém

Markéta Holečková

Milan Klika

Celkem

Výstup z dotazníku

Václav Průša

8.3.1

Jan Macháček

Shrnutí problému

Šimon Steffal

8.3

Komunikace s pořadateli akcí

1

2

2

1

1

7

Evidence vybavení

2

3

2

2

1

10

Plánováním akcí

4

3

5

3

4

19

Propagace skupiny

4

5

3

4

5

21

Tabulka 8: Výstup z dotazníkového šetření [1 nejmenší problém, 5 největší problém] Problém

Propagace skupiny.

Ovlivňuje

Nábor nových členů a názor diváků na historii.

Dopad

Ovlivňuje názor společnosti na skupinu. Není zcela jasné čím se skupina zabývá a proč to realizuje zvoleným způsobem.

Úspěšné řešení

Nasazení aplikace, v které by bylo možné prezentovat dosavadní výsledky snažení skupiny.

Tabulka 9: Problém s propagací skupiny

▪ 16 ▪


Problém

Plánování akcí.

Ovlivňuje

Produktivitu práce, náladu ve skupině.

Dopad

Špatná organizace akce, nepříjemné změny na poslední chvíli.

Úspěšné řešení

Nasazení aplikace pro plánování akcí, optimalizace procesu Účast na akcích rekonstruujících historii v tuzemsku i v zahraniční.

Tabulka 10: Problém s plánováním akcí

8.4

Správa požadavků

Hlavním podkladem pro vznik informačního systém jsou požadavky, definované potřeby zainteresovaného subjektu. Jednodušeji můžeme za požadavek označit vše, co má být implementováno, tedy libovolné chování nebo vlastnost systému. Pro přesnější definici požadavku pak můžeme použít následující: 1. Schopnost nebo vlastnost požadovaná uživatelem k vyřešení problému nebo dosažení cíle.1 2. Schopnost nebo vlastnost, které musí být dosaženo systémem nebo komponentou systému, a která splňuje danou smlouvu, standard, specifikaci nebo jinou formálně schválenou dokumentaci.1 Požadavky lze rozdělit do několika kategorií. Základní dělení je na funkční a nefunkční. Protože toto dělení není vždy dostatečné, byl zaveden firmou Hewlett-Packard model FURPS+. Za tímto akronymem se skrývá rozdělení požadavků do šesti kategorií. Kromě písmene F se jedná o nefunkční požadavky. Jednotlivá písmena tedy představují kategorie pro: 1. Functionality (Funkčnost) 2. Usability (Použitelnost) 3. Reliability (Spolehlivost) 4. Performance (Výkonnost) 5. Supportability (Podpora) 6. + (Ostatní) Podrobnější popis jednotlivých kategorií lze nálézt například na stránkách Wikipedia, konkrétně na http://en.wikipedia.org/wiki/FURPS

1

KLIMEŠ, Jiří. OAD Úvod do modelování IS [online]. Publikováno 2008, poslední revize 2. 9. 2008 [cit. 9. 8. 2010]. Dostupné v Unicorn Universe: ▪ 17 ▪


8.4.1

Identifikované požadavky

#

Kat

Popis

RE01

F

V systému budou evidováni uživatelé a bude možné je přiřazovat do různých uživatelských skupin

RE02

F

Systém bude řídit přístup uživatelů do jednotlivých skupin a ověřovat jejich přístupová oprávnění

RE03

F

Uživatelům bude systém umožňovat zakládat galerie a vkládat do nich obrázky

RE04

F

Systém bude zajišťovat komunikaci mezi členy formou skupinových diskuzí

RE05

F

Pomocí systému bude řešena organizace akcí

RE06

F

V systému bude evidováno skupinové vybavení

RE07

F

Systém bude umožňovat publikaci vybraných informací na internetu

RE08

F

V systému bude možné psát články a sdílet je s ostatními uživateli

RE09

F

Systém bude publikovat vybrané obrázky do sítě Facebook

RE10

U

Systém by měl být navržen jako vícejazyčná aplikace

RE11

U

Systém musí být schopni používat i málo zdatní uživatelé PC

RE12

S

K systému musí existovat programátorská dokumentace

RE13

+

Systém bude vybudován na technologii ASP.NET

Tabulka 11: Přehled identifikovaných požadavků

8.4.2

Celková priorita identifikovaných požadavků

#

Priorita klienta

Náročnost

Celková priorita

Iterace

RE01

1

4

1

1

RE02

1

5

1

1

RE03

2

3

2

1

RE04

2

3

2

2

RE05

1

3

1

2

RE06

3

4

3

3

RE07

2

2

3

3

RE08

2

5

1

4

RE09

4

2

4

4

RE10

2

1

2

2

RE11

1

3

x

x

RE12

3

x

x

x

RE13

4

x

x

x

Tabulka 12: Priority identifikovaných požadavků Priorita: 1 nejnižší - 5 nejvyšší, Náročnost: 1 nejnižší – 5 nejvyšší

▪ 18 ▪


8.5

Navrhované řešení

Jako vhodné řešení se jeví návrh informačního systému, který bude pokrývat všechny požadavky výše zmíněné organizace. Vývoj systému bude probíhat v několika krocích. Rozdělení požadavků do jednotlivých etap proběhlo na základě stanovených priorit. V první etapě bude systém umožňovat správu uživatelů a tyto uživatele bude možné obsazovat do pracovních skupin. V skupinách mohou uživatelé vytvářet, upravovat a sdílet data potřebná pro jejich práci. Pod pojmem data se zpočátku skrývají pouze obrázky, fotografie a videa. V dalších iteracích se počítá s obecnou správou dat. Systém tedy bude umět uložit například dokumenty, tabulky z tabulkových procesorů a mnohé další. Bude vytvořen i základní modul pro plánování a organizaci práce. Modul bude obsahovat diskuzní fórum, které bude sloužit jako komunikační kanál pro členy jednotlivých pracovních skupin. Dále bude možné v systému plánovat a potvrzovat účast na akcích. Následně budou doplňovány do systému nové a rozšiřovány stávající funkčnosti. Například bude zajištěna integrace se sociální sítí Facebook, kdy uživatel bude moci sdílet fotografie z jeho pracovních skupin v této síti. Systém bude také sloužit jako nástroj pro evidenci a práci s majetkem.

▪ 19 ▪


9.

NÁVRH SYSTÉMU

Tato část se zabývá návrhem systému. Informační systém dostal jméno ISob. Tento název je založen na spodobě znělosti znělé souhlásky p a neznělé b. Původní jméno systému bylo ISopp, Informační Systém pro Organizaci a Prezentaci Práce. Ten jsem však zavrhl a místo toho jsem se inspiroval jinými zvířecími informačními systémy, konkrétně eLiškou Českých drah.

9.1

Modul Core

Modul Core je hlavní modul systému ISob. Zavádí do systému čtyři základní entity Uživatele 2, Skupiny, Galerie a Obrázky a přináší veškerou funkčnost pro jejich správu. Umožňuje registraci uživatelů, jejich zobrazení, editaci a mazání. Stejné operace poskytuje skupinám, galeriím a obrázkům.

9.1.1

Uživatelé a skupiny

Uživatel je evidován v systému pomocí povinných a nepovinných parametrů. Povinné parametry jsou přihlašovací jméno, heslo, email, datum založení, datum poslední změny a datum posledního přihlášení. K nepovinným parametrům patří křestní jméno, příjmení a krátký popis.

Obrázek 2: Doménový model uživatelů a skupin

Skupina je entita, která seskupuje uživatele do logických celků. Každá skupina je definována jménem, krátkým popisem, datem založení, datem poslední změny a vlastníkem. 2

Dále v textu se pracuje s třemi základními pojmy: koncový uživatel, uživatel a profil.

Koncový uživatel je osoba která využívá systém ISob ke své práci. Uživatel je reprezentace koncového uživatele v systému. Profil je seznam detailních informací o uživateli. ▪ 20 ▪


Vlastník skupiny je uživatel, který skupinu založil a povoluje přístup všem ostatním uživatelům. Uživatelé, kteří přijali pozvání do skupiny, se stávají skupinovými uživateli. Počet skupinových uživatelů ve skupině není omezen. Ve skupině může být jeden až n skupinových uživatelů. Vlastník může upravovat informace o skupině, tedy jméno a krátký popis. Může do ní zvát nové uživatele a odstraňovat z ní staré skupinové uživatele. Vlastník může navíc skupinu smazat. Kromě skupin, které založili uživatelé, nalezneme v ISobu i několik systémových skupin. Jsou to domovské skupiny uživatelů, které jsou založeny společně s uživatelem. Domovská skupina, je výchozím pracovním prostorem. Ostatní uživatelé nemají přístup k dokumentům, které v ní byly vytvořeny. Domovskou skupinu nelze odstranit ani upravovat. Také z ní nelze odstranit uživatele nebo je do ní pozvat.

9.1.2

Galerie a obrázky

V rámci modulu Core je každé skupině založena kořenová galerie. Tedy při vytváření nového uživatele je nejen založena jeho domovská skupina, ale této skupině je založena i kořenová galerie. Kořenové galerie, stejně jako domovské skupiny nelze odstranit.

Obrázek 3: Doménový model vlastnictví galerií a obrázků

Uživatelské uspořádání galerie je libovolné. Záleží na způsobu práce uživatele. V kořenové galerii lze vytvářet podgalerie ve více úrovních, počet úrovní není omezen, nebo do ní volně vkládat samostatné obrázky nebo videa. Kořenovou galerii nelze odstranit. ▪ 21 ▪


Obrázek 4: Doménový model uspořádání galerií

Galerie a obrázky mají jméno, krátký popis, datum založení, datum poslední změny, majitele, skupinu a přístupová práva.

9.1.3

Seznam případů užití modulu Core

1. MC.UC01: Registrace nového uživatele (strana: 41, kapitola: 18.1) 2. MC.UC02: Přihlášení koncového uživatele do systému (strana: 48, kapitola: 18.6 3. MC.UC03: Odhlášení koncového uživatele ze systému

▪ 22 ▪


4. MC.UC04: Zobrazení detailu profilu uživatele (strana: 44, kapitola: 18.2) 5. MC.UC05: Editace osobních údajů v profilu uživatele (strana: 45, kapitola: 18.3) 6. MC.UC06: Založení skupiny (strana: 46, kapitola: 18.4) 7. MC.UC07: Úprava jména a popisu skupiny (strana: 47, kapitola: 18.5) 8. MC.UC08: Přidání uživatele do skupiny 9. MC.UC09: Odstranění uživatele ze skupiny 10. MU.UC10: Zobrazení detailu galerie 11. MU.UC11: Prezentace obrázků v galerii 12. MC.UC12: Založení nové galerie 13. MU.UC13: Úprava vlastností galerie 14. MU.UC14: Odstranění galerie 15. MU.UC15: Přidání obrázku do galerie 16. MU.UC16: Odstranění obrázku z galerie

▪ 23 ▪


10.

IMPLEMENTACE

Třetí část práce se zabývá konstrukční fází projektu. Hlavní náplní této kapitoly je implementace systému. Zdrojové kódy společně s programátorskou dokumentací jsou k dispozici na přiloženém CD-ROM.

10.1 10.1.1

Modul Core Model

Obrázek 5: Class diagram modelu modulu Core

▪ 24 ▪


10.1.2

Controller

Obrázek 6: Class diagram controlleru modulu Core

▪ 25 ▪


10.1.3

Databázové schéma

Obrázek 7: Databázové schéma modulu Core

▪ 26 ▪


11.

POUŽITÉ TECHNOLOGIE

Kapitola pojednává o použitých technologiích při vývoji informačního systému ISob. Měla by objasnit důvody jejich výběru a v krátkosti představit ty méně známé. Zároveň slouží i jako instalační příručka pro nasazení systému.

11.1

Návrh systému ISob

ISob je navržen jako třívrstvá aplikace a je vybudován na pěti technologiích. Relační databázi Oracle, objektově-relačním mapperu nHibernate, Microsoft .NET MVC frameworku, Microsoft WCF (Windows Communication Foundation) a Microsoft Silverlight.

11.1.1

Persistentní uložení dat

Pro perzistentní uložení dat byla zvolena databáze Oracle. Je to dáno mými většími zkušenostmi s touto technologií než s konkurenčním Microsoft SQL Server 2008. Důvodem pro využití Oracle byly také mé znalosti jazyka PL/SQL, který jsem v počátečních fázích vývoje, využíval pro generování testovacích dat. V reálném nasazení bude nejspíš tato relační databáze nahrazena PostgreSQL nebo již zmíněným Microsoft SQL Serverem 2008. Tato změna vychází z nabídky web hostingových služeb pro .NET aplikace, avšak díky použití nHibernate nám to nikterak nevadí.

11.1.2

Objektově-relační mapování

Při výběru objektově-relačního mapovacího nástroje jsem měl na výběr tyto možnosti: LINQ to SQL, nHibernate a Entity Framework. Entity Framefork jsem se rozhodl vyřadit hned z počátku, jelikož jsem se o jeho existenci dozvěděl až v průběhu psaní této práce. Když se nyní podíváme na zbývající dvě řešení, nalezneme v jejich porovnání výrazné odlišnosti. Mapování LINQ to SQL není možné použít s databází Oracle. LINQ to SQL můžeme propojit pouze s Microsoft SQL Serverem 2000 a vyšším. Oproti tomu je nHibernate nezávislý na použitém databázovém stroji. Další odlišností je již vlastní mapování. U LINQ to SQL je vždy mapována jedna tabulka na jeden objekt. Nad databází vzniká tedy silně typovaná vrstva, jedna ku jedné. U tohoto mapování tedy neexistuje nic jako konceptuální model. Naproti tomu nHibernate je plnohodnotný objektově-relační mapper. Strukturu doménového modelu systému zachytíme konceptuálním modelem a do fyzického světa relační databáze ho transformujeme pomocí mapování. Například pomocí mapovacích souborů s příponou .hbm.xml, ale jde to i jinak. Velkou výhodou a zároveň i hlavní odlišností je možnost měnit fyzický model bez nutnosti měnit model konceptuální. Změny se nám promítnou pouze v úpravě mapování. V případě LINQ to SQL nám však může jakákoliv změna

▪ 27 ▪


v databázi způsobit nefunkčnost celé aplikace. Aby ale vše nemluvilo jen v neprospěch LINQ to SQL, tak musím říct, že kombinace zmíněného mapování a Microsoft SQL Serveru nabízí mnoho automaticky generovaných funkčností, které bude při použití nHibernate potřeba doprogramovat.

11.1.3

Serverová část

U Microsoft ASP.NET MVC frameworku v zásadě není co řešit. Je to základní stavební kámen serverové části. Jsou v něm implementovaný business, datová i část prezentační vrstvy aplikace. Komunikace serverové části s klientskou je zajištěna pomocí web-GUI kanálu a webových služeb. Ty jsou nástavbou business vrstvy. Z tohoto návrhu ovšem vyplývá, že business logika je pouze v serverové části aplikace, ale my bychom ji potřebovali částečně sdílet s klientskou částí. Tento problém vyřešíme použitím WCF Ria Services, sadou podpůrných nástrojů, které automaticky generují příslušné třídy doménového modelu v klientské části aplikace.

11.1.4

Klientská část

Na klientskou část, ve které se nachází prezentační vrstva, jsou použity technologie ASP .NET MVC a Microsoft Silverlight 3. Proč Silverlight? Návrh aplikace nutně nevyžadoval použití RIA platformy. Ta však přináší mnoho výhod. Například zvětšení uživatelského komfortu použitím Silverlight komponent pro přehrávání videa, či pro upload většího množství souborů. Další výhodou je odstranění problému s optimalizací webu pro různé webové prohlížeče. Nesmíme zapomenout ani na ulehčení a zpříjemnění práce vývojářům. Nevýhoda platformy, tedy potřeba instalace pluginu do webového prohlížeče, je vzhledem k počtu uživatelů zanedbatelná. Těch bude v pilotním provozu maximálně několik desítek a většinou se bude jednat o uživatele Microsoft Windows 7 a webového prohlížeče Internet Explorer 8, či Mozilla Firefox. Tato kombinace zajišťuje bezproblémový chod Silverlight aplikací bez jakéhokoliv zásahu uživatele. Při případném růstu počtu uživatelů systému ISob je možné nahradit Silverlight části klient ské

aplikace běžnou ASP.NET MVC stránkou s využitím AJAX komponent, čímž odstraníme

nutnost instalace pluginu úplně.

11.2

Silverlight

11.2.1

O projektu

Technologie Silverlight byla představena v roce 2007 softwarovou společností Microsoft. Jedná se o plug-in pro webové prohlížeče, který uživatelům zprostředkovává RIA, Rich Internet Application, platformu vycházející z WPF, Windows Presentation Foundation. Snahou technologie Silverlight je dosažení kompatibility s dnes nejrozšířenějšími operačními systémy, tedy s Microsoft Windows, ▪ 28 ▪


Apple Mac OS X a s rodinou operačních systémů Linux. Samozřejmostí je podpora mobilních zařízení s operačními systémy Microsoft Windows Phone 7 a Symbian(Series 60). V současné době je k dispozici verze Silverlight 4. Pro koncové uživatele byla uvolněna 15. 4. 2010 společně s Visual Studiem 2010. Verze 4 přináší například podporu webového prohlížeče Google's Chrome, práci s kamerou a mikrofonem, rozšíření možností data bindingu, vylepšení

animací,

WCF

RIA

Services

a mnoho

dalšího

viz

http://www.silverlight.net/getstarted/overview.aspx. Podpora operačního systému Linux je řešena formou open-source projektu Moonlight, kte rý je zaštítěn firmou Novell. Bohužel i přes záštitu americké softwarové firmy je Moonlight daleko za Silverlightem a podpora Linuxu je nejslabší.

11.2.2

Konfigurace

Pro vývoj Silverlight aplikací a případné úpravy systemu ISob stačí pouze naistalovat Microsoft Silverlight 3 SDK a Microsoft Silverlight 3 Tools for Visual Studio 2008 SP1. Obojí ale s příchodem Silverlight 4 zmizelo ze stránek Microsoftu, proto budeme nuceni přejít na Silverlight 4 Tools RC2 for Visual Studio 2010, a tím pádem i na Visual Studio 2010, což majitele Visual Studia 2008 jistě nepotěší. Více o systémových požadavcích zde http://www.microsoft.com/downloads/details.aspx? FamilyID=bf5ab940-c011-4bd1-ad98-da671e491009&displaylang=en. Při samotném nasazení systému nic instalovat ani konfigurovat nemusíme. Stačí pouze kopírovat zkompilovaný projekt do složky, na kterou odkazuje virtuální adresář na IIS serveru.

11.3

WCF RIA Services

11.3.1

O projektu

Microsoft WCF RIA Services je rozšířením tradičního n-vrstvého návrhového vzoru, který podporuje ASP.NET a Silverlight platformy. RIA Services umožňují psát aplikační logiku, která běží na rozdělené business vrstvě. Poskytuje podporu pro běžné úkony jako je dotazování, editace a validace dat, autentizace a autorizace prostřednictvím integrace Silverlight komponent, jak na straně klienta, tak ASP.NET na busines vrstvě. Z výše uvedené definice je tedy zřejmé, že WCF RIA Services jsou komplexní sadou ná strojů, komponent a služeb, které zprostředkovávají serverovou business logiku v klientské aplikaci. Vše je zcela automatizované. Po provedení změny v business logice se před kompilací vygenerují proxy třídy, které zpřístupňují datový model a potřebná volání serverové části.

▪ 29 ▪


Obrázek 8: WCF RIA Services schéma Zdroj: http://msdn.microsoft.com/en-us/library/ee707344%28VS.91%29.aspx

11.3.2

Konfigurace

Podporu WCF RIA Services u Silverlight 3 získáme instalací WCF RIA Services Beta for Visual Studio 2008 SP1. Pokud máme Silverlight 4, pak zvolíme WCF RIA Services RC 2 for Visual Studio 2010. Reference na System.Web.Ria.dll u serverové části a na System.Windows.Ria.dll u klienské části projektu by nám mělo Visual Studio doplnit samo. Stačí tedy jen přidat referenci na knihovnu System.Windows.Controls.Ria.dll. Při nasazení opět není třeba nic konfigurovat, ale u serverové část by mohlo být vhodné i kopírovat zmíněnou knihovnu přímo k projektu a opravit odkaz na ni.

11.4

11.4.1

nHibernate

O projektu

Projekt nHibernate je objektově-relační mapper s otevřeným zdrojovým kódem. Jeho základ nalezneme v Java projektu Hibernate. Cílem projektu je komplexní řešení práce s perzistentními daty, při použití relační databáze a doménového modelu tříd. Vystupuje v roli prostředníka mezi aplikací a databází a umožňuje vývojáři soustředit se na obchodní problematiku aplikace. Také odděluje aplikaci od použitého databázového stroje. Při jeho výměně stačí pouze změnit nastavení nHibernate.

▪ 30 ▪


NHibernate je řešení poskytované pod licencí GNU Lesser General Public License. Je vyvíjené od roku 2006. Aktuální stabilní verze má pořadové číslo 2.1.2 a poskytuje i částečnou podporou dotazovacího jazyku LINQ.

11.4.2

Konfigurace

Pro zprovoznění nHibernate v aplikaci, potřebujeme přidat reference na knihovny nHibernate. Ty nalezneme na http://sourceforge.net/projects/nhibernate/files/NHibernate/. Pro základní potřeby si vystačíme s knihovnami: 1. Antlr3.Runtime.dll 2. Castle.Core.dll 3. Castle.DynamicProxy2.dll 4. Iesi.Collections.dll 5. NHibernate.ByteCode.Castle.dll 6. NHibernate.dll Pro podporu logování, testování a dotazovacího jazyka LINQ přidáme: 1. log4net.dll 2. nunit.core.dll 3. nunit.framework.dll 4. NHibernate.Linq.dll Veškeré nastavení, podobně jako v celém prostředí .NET, probíhá pomocí XML konfiguračních souborů, anebo můžeme konfiguraci provádět přímo z aplikačního kódu. V předchozích verzích objektově-relačního mapperu nHibernate byla nastavení součástí konfigurace celé aplikace, tedy pro webovou aplikaci se nacházela v souboru web.config. Od nHibernate verze 2.0 se přesunula do speciálního souboru hibernate.cfg.xml. Tomuto souboru nesmíme zapomenout nastavit atributy Build Action na Content a Copy to Output na Copy Always. Pro zprovoznění spolupráce nHibernate s databází Oracle 10g a s Oracle Data Providerem nastavíme vlastnost dialect na NHibernate.Dialect.Oracle10gDialect a vlastnost connection.driver_class NHibernate.Driver.OracleClientDriver, viz http://tiredblogger.wordpress.com/2008/11/07/using-oracle-odp-with-nhibernate-froma-c-class-library/. Ve vlastnosti connection.connection_string uvedeme umístění databáze a potřebné přihlašovací údaje. Posledním krokem je nastavení factory class na NHibernate.ByteCode.Castle. Při konfiguraci není dobré spoléhat se pouze na oficiální dokumentaci nHibernate, ve které se, bohužel, vyskytují chyby a překlepy. Pro úplnost uvádím příklad správného nastavení pro zprovoznění nHibernate s výše zmíněnou databází: Příklad nastavení nHibernate

▪ 31 ▪


<sessionfactory> <property name="connection.provider"> NHibernate.Connection.DriverConnectionProvider <property name="dialect"> NHibernate.Dialect.Oracle10gDialect <property name="connection.driver_class"> NHibernate.Driver.OracleClientDriver <property name="connection.connection_string"> Data Source=(DESCRIPTION= (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP) (HOST=192.168.56.1)(PORT=1521))) (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=XE))); User Id=user; Password=pass; Pooling=true; Enlist=false; <property name="show_sql"> true <property name="proxyfactory.factory_class"> NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle

11.4.3

Příklad mapování objektu

V příloze uvádím příklad mapování třídy Person na tabulku PERSON viz strana 50.

11.5

Knihovny třetích stran

V systému ISob jsou použity následující knihovny třetích stran:

▪ 32 ▪


Název

nHibernate 2.1.2

Popis

Open source objektově-relační mapper pro .NET Framework

Licence

GNU Lesser General Public License

Domovská stránka

http://nhforge.org

Tabulka 13: NHibernate

Název

Unity 2.0

Popis

Unity je jednoduchý a rozšiřitelný kontejner pro správu objektů. V systému ISob je využíván k uchování nHibernate session.

Licence

Microsoft Public License (Ms-PL)

Domovská stránka

http://unity.codeplex.com/wikipage?title=Unity2%20Beta1

Tabulka 14: Unity

Název

Silverlight Video Player

Popis

Silverlight komponenta pro přehrávání videa

Licence

Microsoft Public License (Ms-PL)

Domovská stránka

http://slvideoplayer.codeplex.com/

Tabulka 15: Silverlight Video Player

11.6

Instalace systému

Systém ISob lze provozovat na libovolném IIS serveru od 6.0 a vyšším. Pro perzistentní uložení dat je potřeba databáze minimálně verze Oracle Database 10g Express Edition. Pro nasazení aplikace potřebujeme vytvořit na IIS serveru virtuální adresář, který mapuje webovou aplikaci na některý fyzický adresář. Pomocí IIS manažeru nastavíme virtuální adresář a namapujeme ho na adresář, kam jsme extrahovali obsah souboru ISobMvc.zip. V průvodci vytvořením virtuálního adresáře nezapomeneme nastavit alias aplikace a přístupová oprávnění. Samotná aplikace potřebuje mít přístupný adresář /Content/MediaFiles pro zápis. Dále potřebujeme pod přiděleným Oracle uživatelem vytvořit nové databázové schéma. To provedeme pomocí SQL scriptu CreateDBSchema.sql, ve kterém bude nutné změnit jméno uživatele z “ISOB” na jméno našeho Oracle uživatele. Nakonec je zapotřebí upravit v konfiguraci hibernate.cfg.xml vlastnost connection.connection_string. Zde je nutné nastavit správné hodnoty v Data Source, konkrétně HOST a PORT, dále User Id a Password. Soubory ISobMvc.zip a CreateDBSchema.sql jsou v kořenovém adresáři na přiloženém cd-rom.

▪ 33 ▪


12.

ZÁVĚR

Doufal jsem, že se mi bakalářskou práci podaří zakončit větou: „Podařilo se mi analyzovat, navrhnout, implementovat a nasadit do testovacího provozu prototyp informačního systému ISob.“ Bohužel se tak úplně nestalo. Mé nadšení pro nové technologie mne nedovedlo k očekávaným výsledkům. Kombinace Microsoft Silverlight, WCF RIA services a nHibernate, která se z počátku zdála být pouze obtížná, se ukázala jako zcela neprůchodná. Je to dáno jak její nezvyklostí, tak poměrně pomalým vývojem nHibernate. V prvé řadě bylo velmi komplikované nalézt vhodný příklad použití. V podstatě jediný člověk, který napsal tutoriál je Tim Heuer z Microsoftu. Podezřívám jej ovšem z toho, že jeho hlavním záměrem nebylo popsat propojení zmíněných technologií, nýbrž jen poukázat na kvalitu návrhu Microsoft Silverlight business aplication. Konkrétně její schopnosti propojit se kde s čím. Druhý problém se projevoval hlavně nefunkčností lákadel jazyka LINQ a rozhraní IQueryable. Kde v příkladech při použití LINQ to SQL vše krásně fungovalo, avšak s nHibernate LINQ již ne. Což znamenalo hlavně rychlé rozloučení se s automatickým řazením prvků a stránkováním na komponentě DataGrid, nemluvě o některých vyhledávacích metodách. Všechna tato omezení mne vedla k nahrazení Silverlightu ASP.NET MVC frameworkem. To se ukázalo jako velmi výhodné řešení. ASP.NET MVC je svoji strukturou téměř schodný s Ruby on Rails. Tudíž jsem se nemusel seznamovat s novou technologií. Pro efektivní práci mi stačily jen znalosti ASP.NET a Ruby on Rails. Bohužel jsem se pro tuto změnu rozhodl až příliš pozdě a již se mi nepodařilo dohnat zpoždění získané zkoumáním Silverlight business application. Proto jsem musel přesunout implementaci některých funkčností až do dalších etap. Prototyp lze tedy spíš považovat za technologické demo, představující sofistikovanější webovou galerii, než za informační systém. Hlavní přínos této práce vidím však v tom, že mi ukázala směr, kterým se mám vydat při dalším vývoji. V následující etapě, na které začnu pracovat hned po dopsání této práce, jsem se rozhodl nahradit nHibernate Entity Frameworkem z dílen Microsoftu. Tímto řešením snad odstraním všechny nedostatky nHibernate a budu moc dále používat databázi Oracle. Také dám za pravdu jednomu chytrému rčení: „Každý projekt si během svého života zaslouží nejméně jednou (ale mnohé i vícekrát) zahodit veškeré zdrojové kódy a celý přepsat.“ 3

3

Kučera, Ondřej. Kučera Ondřej [online]. Publikováno 2007, poslední revize 23. 4. 2010

[cit. 12. 8. 2010]. Dostupné v Unicorn Universe: . ▪ 34 ▪


13.

CONCLUSION

I hoped to finish my bachelor thesis with the following sentence:“ I succeeded in analyzing, designing, implementing and deploying an ISob information system prototype.“ Unfortunately, as the work progressed, it was to be proven otherwise. The main problem was my unwillingness to experiment with new technologies while lacking needed experience and knowledge. The combination of Microsoft Silverlight, WCF RIA services and nHibernate which at the beginning seemed merely difficult to achieve, proved to be completely impossible. It is given not only by a rare occurrence of such a combination, but mainly due the slow nHibernate development. Firstly, it was complicated to identify an appropriate example of usage. Essentially, the only person who has ever written a tutorial concerning this matter, has been Mr. Tim Heuer from Micro soft. However, I strongly suspect that he wrote it only in order to promote the quality of the Sil verlight business application design (to be specific – its compatibility with a number of different technologies), rather to describe the connection of the technologies which I have mentioned earlier. Secondly, there were LINQ and IQueryable interface features malfunctions. In provided examples (using LINQ to SQL) was everything fully operational. Nevertheless, when I tested nHibernate LINQ malfunctions appeared, which led to literally “waved goodbye” to automatic sorting and paging on the DataGrid component, not mentioning some search methods, which become simply unreachable. All these limitations and problems forced me to replace the Silverlight with ASP.NET MVC framework. This has proved to be a very effective solution indeed. As the ASP.NET MVC structure is quite similar to the Ruby on Rails, I did not have to study a brand new technology, thus sacrific ing more time and energy. Unfortunately, the decision to change the technologies came too late and I have been unable to make up for the lost time. As a result, I had to move some functionality implementation to other iterations. My prototype is not a fully developed information system. It is only a technology demo, represented by a sophisticated web gallery. I see a significant contribution of my current work in the sense of showing me the right direction for further development. In the next iteration, I'm going to replace nHibernate Entity Framework by Microsoft's workshop. I will begin working on it immediately after I am finished with my thesis. This solution might be able to bypass all technical troubles and glitches with nHibernate and I will able to continue using the Oracle database. Finally, I must fully agree with the following statement: "Every project deserves to be at least once per its life (but sometimes more than once) com pletely redone and its source codes thrown away.”

▪ 35 ▪


14.

SEZNAM POUŽITÉ LITERATURY

1. Kuaté, Pierre Henri; Harris, Tobin; Bauer, Christian; King, Gavin (February 2009). NHibernate in Acction. Manning Publications. pp 400. ISBN 1932394923. 2. Kroll,

Luisa;

Miller,

Matthew

(2010-03-10).

"The

World's

Billionaires".

Forbes.

http://www.forbes.com/2010/03/10/worlds-richest-people-slim-gates-buffett-billionaires2010_land.html?boxes=Homepagelighttop. 3. http://nhforge.org/wikis/howtonh/your-first-nhibernate-based-application.aspx 4. http://www.surcombe.com/nhibernate-1.2/api/html/N_NHibernate_Dialect.htm 5. http://tiredblogger.wordpress.com/2008/11/07/using-oracle-odp-with-nhibernate-from-a-c-class-library/ 6. http://www.fincher.org/tips/Languages/NHibernate.shtml 7. http://videos.visitmix.com/MIX09/T40F 8. http://blogs.msdn.com/brada/archive/2009/07/11/business-apps-example-for-silverlight-3rtm-and-net-ria-services-july-update-part-1-rich-data-query.aspx 9. http://blogs.msdn.com/brada/archive/2009/08/02/business-apps-example-for-silverlight-3rtm-and-net-ria-services-july-update-summary.aspx 10. http://www.silverlight.net/getstarted/overview.aspx 11. http://www.microsoft.com/downloads/details.aspx?FamilyID=bf5ab940-c011-4bd1-ad98da671e491009&displaylang=en 12. http://www.silverlight.net/getstarted/riaservices/ 13. http://msdn.microsoft.com/en-us/library/ee707344%28VS.91%29.aspx

▪ 36 ▪


15.

SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK

Zkratka

Popisek

ASP.NET

Active Server Pages

ICT

Information and communication technologies

IIS

Internet Information Services

LINQ

Language Integrated Query

MVC

Model-View-Controller

PL/SQL

Procedural Language/Structured Query Language

RIA

Rich Internet Application

SQL

Structured Query Language

WCF

Windows Communication Foundation

WPF

Windows Presentation Foundation

▪ 37 ▪


16.

SEZNAM OBRÁZKŮ

Seznam obrázků Obrázek 1: Procesy ve skupině............................................................................................13 Obrázek 2: Doménový model uživatelů a skupin................................................................20 Obrázek 3: Doménový model vlastnictví galerií a obrázků.................................................21 Obrázek 4: Doménový model uspořádání galerií.................................................................22 Obrázek 5: Class diagram modelu modulu Core..................................................................24 Obrázek 6: Class diagram controlleru modulu Core............................................................25 Obrázek 7: Databázové schéma modulu Core.....................................................................26 Obrázek 8: WCF RIA Services schéma...............................................................................30 Obrázek 9: Aktivity diagram vytvoření uživatele................................................................43

▪ 38 ▪


17.

SEZNAM TABULEK

Seznam tabulek Tabulka 1: Procesy ve skupině.............................................................................................14 Tabulka 2: Popis procesu PROC03......................................................................................14 Tabulka 3: Popis dílčích kroků procesu PROC03.01...........................................................14 Tabulka 4: Popis dílčích kroků procesu PROC03.02...........................................................15 Tabulka 5: Popis dílčích kroků procesu PROC03.03...........................................................15 Tabulka 6: Popis procesu PROC10......................................................................................15 Tabulka 7: Popis dílčích kroků procesu PROC10.01...........................................................16 Tabulka 8: Výstup z dotazníkového šetření [1 nejmenší problém, 5 největší problém]......16 Tabulka 9: Problém s propagací skupiny.............................................................................16 Tabulka 10: Problém s plánováním akcí..............................................................................17 Tabulka 11: Přehled identifikovaných požadavků...............................................................18 Tabulka 12: Priority identifikovaných požadavků ..............................................................18 Tabulka 13: NHibernate.......................................................................................................33 Tabulka 14: Unity.................................................................................................................33 Tabulka 15: Silverlight Video Player...................................................................................33 Tabulka 16: Datové typy případu užití registrace nového uživatele .................................42 Tabulka 17: Datové typy případu užití zobrazení detailu profilu uživatele........................44 Tabulka 18: Datové typy případu užití editace osobních údajů v profilu uživatele............46 Tabulka 19: Datové typy případu užití založení skupiny....................................................47 Tabulka 20: Datové typy případu užití úprava jména a popisu skupiny.............................48 Tabulka 21: Datové typy případu užité přihlášení koncového uživatele do systému.........49

▪ 39 ▪


18.

SEZNAM PŘÍLOH

Seznam příloh Příloha 1 – Vybrané případy užití systému ISob..................................................................41 Příloha 2 – Ukázka mapování třídy Person na tabulku PERSON........................................50 Příloha 3 – CD-ROM...........................................................................................................51

▪ 40 ▪


PŘÍLOHA 1 – VYBRANÉ PŘÍPADY UŽITÍ SYSTÉMU ISOB

18.1 18.1.1

Registrace nového uživatele Popis

Koncový uživatel se vyplněním a odesláním vybraných osobních údajů registruje do systému ISob. Po ověření identity uživatele, systém připraví uživatelovo pracovní prostředí.

18.1.2

Vstupní podmínky

Koncový uživatel je na stránce pro registraci nového uživatele.

18.1.3

Toky

Základní tok: Úspěšná registrace nového uživatele 1. Koncový uživatel vyplní požadované údaje. Systém zkontroluje formát zadaných hodnot a zpřístupní možnost odeslat registrační údaje. 2. Koncový uživatel odešle vyplněné registrační údaje stisknutím odeslat. Systém odešle kontrolní zprávu na email zadaný koncovým uživatelem. Poté přesměruje uživatele na stránku s formulářem pro zadání kódu z kontrolní zprávy. 3. Koncový uživatel vyplní kód z kontrolní zprávy. Systém ověří kód a uloží údaje o uživateli. Dále pak připraví pracovní prostředí uživatele, tedy například založí jeho domovskou skupinu a domovskou galerii. Informuje koncového uživatele o úspěšné registraci. Případ užití je úspěšně ukončen. Alternativní tok: Neplatný formát požadovaných údajů V kroku 1. základního toku, koncový uživatel vyplní požadované údaje v nesprávném formátu. Systém zvýrazní pole s problémovým údajem a upozorní koncového uživatele na chybu. Alternativní tok: Neplatný kontrolní kód V kroku 3. základního toku, koncový uživatel vyplní neplatný kontrolní kód. Systém vyzve uživatele k opravě kontrolního kódu a zvýrazní možnost odeslat novou kontrolní zprávu. Alternativní tok: Koncovému uživateli nebyl doručen kontrolní kód V kroku 3. základního toku nebyla koncovému uživateli doručena zpráva s kontrolním kódem. Koncový uživatel vybere možnost zpět. Systém přesměruje uživatele na formulář pro vyplnění požadovaných údajů.

▪ 41 ▪


Alternativní tok: Nedostupná serverová část systému V kroku 2. základního toku selže odeslání registračních údajů uživatele. Systém zobrazí varování.

18.1.4

Datové typy

Název pole

Povinné / nepovinné / systémové pole

Datový typ pole, omezení Předvyplněná hodnota

Jméno

Povinné

String(40), unikátní

Email

Povinné

String(100), platný formát emailu

Heslo

Povinné

String(40)

Křestní jméno

Nepovinné

String(40)

Příjmení

Nepovinné

String(40)

Krátký popis Nepovinné

String(2000)

Datum založení

Systémové

DateTime

Čas registrace

Datum úpravy

Systémové

DateTime

Čas registrace

Tabulka 16: Datové typy případu užití registrace nového uživatele

▪ 42 ▪


18.1.5

Další informace a diagramy

Aktivity diagram:

Obrázek 9: Aktivity diagram vytvoření uživatele

▪ 43 ▪


18.2 18.2.1

Zobrazení detailu profilu uživatele Popis

Koncový uživatel si v seznamu uživatelů skupiny vybere konkrétního uživatele a zobrazí jeho detailní informace.

18.2.2

Vstupní podmínky

Koncový uživatel je přihlášen v systému.

18.2.3

Toky

Základní tok: Zobrazení detailních informací o skupinovém uživateli 1. Koncový uživatel v seznamu členů skupiny vybere konkrétního uživatele. Systém zobrazí profil dotyčného uživatele s detailními informacemi o něm. Případ užití je úspěšně ukončen. Alternativní tok: Zobrazení profilu koncového uživatele V kroku 1. základního toku je vybrán uživatelský profil koncového uživatele. Systém zobrazí profil koncového uživatele s jeho detailními informacemi. Případ užití je úspěšně ukončen.

18.2.4

Datové typy

Název pole



Identifikátor uživatele

Systémové

Guid

Tabulka 17: Datové typy případu užití zobrazení detailu profilu uživatele

18.2.5


Aktivity diagram: Není

▪ 44 ▪


18.3 18.3.1

Editace osobních údajů v profilu uživatele Popis

Koncový uživatel upraví osobní údaje ve svém profilu.

18.3.2

Vstupní podmínky

Koncový uživatel upravuje svůj profil.

18.3.3

Toky

Základní tok: Úspěšná úprava osobních údajů 1. Po zobrazení svého profilu vybere koncový uživatel možnost upravit osobní údaje. Systém zobrazí údaje v editovatelné podobě. 2. Koncový uživatel upraví potřebné údaje. Systém zkontroluje formát zadaných hodnot a zpřístupní možnost potvrdit změny. 3. Koncový uživatel uloží úpravy výběrem možnosti potvrdit změny. Systém aktualizuje datum poslední úpravy a uloží provedené změny. Případ užití je úspěšně ukončen. Alternativní tok: Neplatný formát upravených údajů V kroku 2. základního toku, koncový uživatel vyplní nové údaje v nesprávném formátu. Systém zvýrazní pole s problémovým údajem a upozorní koncového uživatele na chybu. Alternativní tok: Nedostupná serverová část systému V kroku 3. základního toku nelze uložit úpravy v osobních údajích uživatele. Systém zobrazí va rování.

▪ 45 ▪


18.3.4

Datové typy

Název pole



Identifikátor uživatele

Systémové

Guid

Jméno

Povinné


Původní hodnota

Email

Povinné

String(100), platný formát emailu

Původní hodnota

Heslo

Povinné

String(40)

Původní hodnota

Křestní jméno

Nepovinné

String(40)

Původní hodnota

Příjmení

Nepovinné

String(40)

Původní hodnota


String(2000)

Původní hodnota

Datum úpravy

DateTime

Čas úpravy

Systémové

Tabulka 18: Datové typy případu užití editace osobních údajů v profilu uživatele

18.3.5



18.4 18.4.1

Založení skupiny Popis

Koncový uživatel založí novou uživatelskou skupinu.

18.4.2

Vstupní podmínky

Koncový uživatel je přihlášen v systému.

18.4.3

Toky

Základní tok: Uspěšné založení nové skupiny 1. Koncový uživatel vyplní údaje potřebné pro založení nové skupiny. Systém zkontroluje formát zadaných hodnot a zpřístupní možnost vytvořit skupinu.

▪ 46 ▪


2. Koncový uživatel založí novou skupinu výběrem možnosti vytvořit skupinu. Systém uloží novou skupinu, nastaví jí vlastníka a informuje koncového uživatele o úspěšném založení nové skupiny. Případ užití je úspěšně ukončen. Alternativní tok: Neplatný formát požadovaných údajů V kroku 1. základního toku, koncový uživatel vyplní požadované údaje v nesprávném formátu. Systém zvýrazní pole s problémovým údajem a upozorní koncového uživatele na chybu. Alternativní tok: Nedostupná serverová část systému V kroku 2. základního toku nelze vytvořit novou skupinu. Systém zobrazí varování.

18.4.4

Datové typy

Název pole



Jméno

Povinné



String(2000)

Datum vytvoření

Systémové

DateTime

Čas datum vytvoření

Datum úpravy

Systémové

DateTime


Tabulka 19: Datové typy případu užití založení skupiny

18.4.5



18.5 18.5.1

Úprava jména a popisu skupiny Popis

Koncový uživatel upraví jméno a popis skupiny.

18.5.2

Vstupní podmínky

Koncový uživatel je přihlášen v systému. Koncový uživatel je vlastníkem.

18.5.3

Toky

Základní tok: Úspěšná úprava popisu skupiny

▪ 47 ▪


1. Koncový uživatel u aktuálně zvolené skupiny vybere možnost upravit detail skupiny. Systém zobrazí jméno a popis skupiny v editovatelné formě. 2. Koncový uživatel změní údaje skupiny. Systém zkontroluje formát zadaných hodnot a zpřístupní možnost uložit změny. 3. Koncový uživatel potvrdí změny výběrem možnosti uložit změny. Systém uloží nové jméno a popis skupiny a aktualizuje datum poslední úpravy. Případ užití je úspěšně ukončen. Alternativní tok: Neplatný formát požadovaných údajů V kroku 2. základního toku, koncový uživatel vyplní jméno nebo popis v nesprávném formátu. Systém zvýrazní pole s problémovým údajem a upozorní koncového uživatele na chybu. Alternativní tok: Nedostupná serverová část systému V kroku 3. základního toku nelze uložit provedené změny. Systém zobrazí varování.

18.5.4

Datové typy

Název pole



Identifikátor skupiny

Systémové

Guid

Jméno

Povinné


Původní hodnota


String(2000)

Původní hodnota

Datum úpravy

DateTime


Systémové

Tabulka 20: Datové typy případu užití úprava jména a popisu skupiny

18.5.5



18.6 18.6.1

Přihlášení koncového uživatele do systému Popis

Koncový uživatel se přihlásí do systému.

18.6.2

Vstupní podmínky

Koncový uživatel je na stránce pro přihlášení do systému.

▪ 48 ▪


18.6.3

Toky

Základní tok: Úspěšné přihlášení do systému 1. Koncový uživatel vyplní přihlašovací údaje. Systém zkontroluje formát přihlašovacích údajů a zpřístupní možnost přihlásit se. 2.

Koncový uživatel odešle vyplněné přihlašovací údaje stisknutím odeslat. Systém systém ověří platnost přihlašovacích údajů, aktualizuje čas posledního přihlášení uživatele a přesměruje koncového uživatele na hlavní stránku. Případ užití je úspěšně ukončen.

Alternativní tok: Neplatný formát přihlašovacích údajů V kroku 1. základního toku vyplnil koncový uživatel přihlašovací údaje v nesprávném formátu. Systém nezpřístupní možnost přihlásit se. Alternativní tok: Neplatné uživatelské jméno nebo heslo V kroku 2. základního toku vyplnil koncový uživatel neplatné přihlašovací údaje. Systém zobrazí varování a znepřístupní možnost přihlásit se. Alternativní tok: Registrace nového uživatele V kroku 1. základního toku koncový uživatel vybere možnost registrace nového uživatele. Systém spustí případ užití Registrace nového uživatele viz kapitola 18.1 na straně 41. Alternativní tok: Nedostupná serverová část systému V kroku 2. základního toku nelze ověřit platnost přihlašovacích údajů. Systém zobrazí varování a znepřístupní možnost přihlásit se. Datové typy Název pole



Jméno

Povinné


Heslo

Povinné

String(40)

Tabulka 21: Datové typy případu užité přihlášení koncového uživatele do systému

18.6.4



▪ 49 ▪


PŘÍLOHA 2 – UKÁZKA MAPOVÁNÍ TŘÍDY PERSON NA TABULKU PERSON

<property name="Created" /> <property name="Description" /> <property name="Name" /> <property name="Updated" />

<property name="Email" /> <property name="Firstname" /> <property name="Password" /> <property name="Surname" /> <property name="LastLogged" />

<manytoone name="ProfilePicture" class="Picture, NHibernateManyToOne" column="ProfilePicture" cascade="none"/> <manytomany class="Group" column="Fk_Group" />

▪ 50 ▪


PŘÍLOHA 3 – CD-ROM Přiložené CD-ROM obsahuje: 1. Zdrojové kódy informačního systému ISob. 2. Zkompilovaný informační systém. 3. SQL skript pro založení databázového schématu. 4. Programátorskou dokumentaci.

▪ 51 ▪

BAKALÁŘSKÁ PRÁCE. Informační systém pro organizaci a prezentaci práce zájmové komunity

Recommend Documents