Informační systém pro organizaci a prezentaci

Transkript

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.3 Toky......................................................................................................................... 43
18.2.4 Datové typy............................................................................................................ 43
18.3 Editace osobních údajů v profilu uživatele................................................................43
18.3.1 Popis....................................................................................................................... 43
18.3.3 Toky......................................................................................................................... 44
18.3.4 Datové typy............................................................................................................ 44
18.4 Založení skupiny............................................................................................................ 45
18.4.1 Popis....................................................................................................................... 45
18.4.3 Toky......................................................................................................................... 45
18.4.4 Datové typy............................................................................................................ 45
18.5 Úprava jména a popisu skupiny..................................................................................46
18.5.1 Popis....................................................................................................................... 46
18.5.3 Toky......................................................................................................................... 46
18.5.4 Datové typy............................................................................................................ 46
18.6 Přihlášení koncového uživatele do systému.............................................................47
18.6.1 Popis....................................................................................................................... 47
18.6.3 Toky......................................................................................................................... 47
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
Časová
náročnost
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í
Časová
náročnost
1-10 hodin
Kanál
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
Časová
náročnost
1 týden
Kanál
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:
<OAD.CZ/LEC01/GL>
▪ 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 ▪
<?xml version="1.0" encoding="utf8" ?>
<hibernateconfiguration xmlns="urn:nhibernateconfiguration2.2">
<sessionfactory>
<property name="connection.provider">
NHibernate.Connection.DriverConnectionProvider
</property>
<property name="dialect">
NHibernate.Dialect.Oracle10gDialect
</property>
<property name="connection.driver_class">
NHibernate.Driver.OracleClientDriver
</property>
<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>
<property name="show_sql">
true
</property>
<property name="proxyfactory.factory_class">
NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle
</property>
</sessionfactory>
</hibernateconfiguration>
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:
<vigb31.TU/PORTAL>.
▪ 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 6: Popis procesu PROC10......................................................................................15
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
systémové 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.
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
systémové pole
Identifikátor
uživatele
Systémové
Guid
Jméno
Povinné
String(40),
unikátní
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.
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.
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
systémové pole
Jméno
Povinné
String(40),
unikátní
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.
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.
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
systémové pole
Identifikátor
skupiny
Systémové
Guid
Jméno
Povinné
String(40),
unikátní
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.
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
systémové pole
Jméno
Povinné
String(40),
unikátní
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
<?xml version="1.0" encoding="utf8" ?>
<hibernatemapping xmlns="urn:nhibernatemapping2.2"
assembly="ISobMvc"
namespace="ISobMvc.Models">
<! more mapping info here >
<class name="Person">
<! Entity property mapping >
<id name="Id">
<generator class="guid" />
</id>
<property name="Created" />
<property name="Description" />
<property name="Name" />
<property name="Updated" />
<! SystemUser mapping>
<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"/>
<bag name="Groups" table="Group_to_Person" cascade="delete" lazy="false">
<key column ="Fk_Person" />
<manytomany class="Group" column="Fk_Group" />
</bag>
</class>
</hibernatemapping>
▪ 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 ▪

Informační systém pro organizaci a prezentaci

Transkript

Podobné dokumenty

prezentace

příslušenství

STRUKTUROVA Ý ŽIVOTOPIS OSOB Í ÚDAJE Jméno a příjmení Bc

Využití moderních metod pro tvorbu map pro orientaˇcní bˇeh

Využití CASE ve vývojářské firmě

C4 Picasso

technospace - Autoperiskop.cz